SATLIFE-IST-1-507675 D210 DVB-RCS regenerative … regenerative (and transparent) system services requirements report Contractual Date of Delivery to the CEC: ... 4.3 SOFTWARE DOWNLOAD

SATLIFE-IST-1-507675

D210

DVB-RCS regenerative (and transparent) system services requirements report

Contractual Date of Delivery to the CEC: 01/10/04

Actual Date of Delivery to the CEC: 01/10/04

Author(s): Juan R. López, Rafael Rey, Thier ry Filoche, José A. Torr ijos, Antonio Sánchez, Car los M iguel, Haitham Cruickshank

Par ticipant(s): AEO, HSA, THA, TID, UOS, UPM

Workpackage: WP2100

Est. person months: 37

Secur ity: Pub.

Nature: R

Version: 1.0

Total number of pages: 247

Abstract: This document provides a general description of the requirements for the services planned for SATLIFE. This includes audio, video, multimedia and streaming requirements, management tools requirements, other tools requirements and specific requirements for interactive applications, which will be described in depth. For this purpose, the requirements stated in those previous projects will be taken into account and further developed in order to adapt it to the new applications considered. As will be seen, services in both regenerative and transparent modes will apply, so the following requirements will cover these two cases of use. Throughout this document, an extensive compilation of requirements is done with the view to further enhance the results of the AMERHIS project and transparent RCS systems in their flexibility, security, quality of service, efficient multicast and integration with terrestrial networks. Furthermore, the views from a telecom operator have facilitated new scenarios and functionalities needed to widen the possibilities and reinforce the exploitation of DVB-RCS systems in the construction of the Information Society. Keyword list: DVB-RCS, Satellite network, Multimedia, Broadcasting, Interactive services, Video on Demand, QoS in satellite access

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

2 / 247

CHANGE RECORD

VERSION DATE AUTHOR CHANGE

1.0 01/10/2004 SATLIFE PARTNERS (AEO, HSA, THA, TID,

UOS, UPM)

First version

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

3 / 247

TABLE OF CONTENTS

1. EXECUTIVE SUMMARY............................................................................................................... 12

2. DOCUMENT OVERVIEW ............................................................................................................. 13

2.1 SCOPE OF THE DOCUMENT .................................................................................................. 13 2.2 FIELD OF APPLICATION ........................................................................................................ 14 2.3 DOCUMENTATION.................................................................................................................. 14

2.3.1 Related documents.............................................................................................................. 14 2.3.2 Applicable norms and standards......................................................................................... 14

2.4 TERMINOLOGY AND ABBREVIATIONS............................................................................. 18 2.5 ACTORS AND ROLES.............................................................................................................. 24

3. AMERHIS/IBIS SERVICE ENHANCEMENTS.......................................................................... 27

3.1 DIGITAL TV .............................................................................................................................. 28 3.1.1 General system characterization/QoS parameters............................................................. 28 3.1.2 Requirements For Remote Audio/Video Contributions ...................................................... 29

3.1.2.1 Audio contribution formats............................................................................................. 29 3.1.2.2 Video contribution formats............................................................................................. 30 3.1.2.3 System layer format ........................................................................................................ 31

3.1.3 Requirements for audio/video reception............................................................................. 34 3.1.4 Requirements for interactive TV applications.................................................................... 36

3.1.4.1 Broadcast channel ........................................................................................................... 38 3.1.4.2 Interaction channel .......................................................................................................... 39 3.1.4.3 Bit rates requirements..................................................................................................... 39

3.1.5 Requirements for interactive application reception............................................................ 39 3.1.6 Video service provider unit requirements........................................................................... 40

3.2 MULTICONFERENCE.............................................................................................................. 43 3.2.1 Service Functionality Requirements................................................................................... 45

3.2.1.1 Session Control ............................................................................................................... 45 3.2.1.2 Service Functionality ...................................................................................................... 46 3.2.1.3 Conference Control ......................................................................................................... 49

3.2.2 Interface Requirements....................................................................................................... 50 3.2.2.1 Equipment ....................................................................................................................... 50 3.2.2.2 VoIP Platform................................................................................................................. 50 3.2.2.3 Connectivity.................................................................................................................... 50

3.2.3 Scalability and availability Requirements.......................................................................... 52 3.2.3.1 Performance of the Conference Platform........................................................................ 52 3.2.3.2 Scalability of the Conference Platform........................................................................... 53 3.2.3.3 Availability...................................................................................................................... 54

3.2.4 Administration..................................................................................................................... 55 3.2.4.1 User installation and operation ....................................................................................... 55 3.2.4.2 Administration ................................................................................................................ 55

3.2.5 Quality of Service................................................................................................................ 56

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

4 / 247

3.2.6 Security Requirements......................................................................................................... 58

3.3 INTERNET ACCESS SERVICE................................................................................................ 60 3.3.1 Service requirements for Web browsing............................................................................. 62 3.3.2 Service requirements for Chat ............................................................................................ 63 3.3.3 Service requirements for Server Access.............................................................................. 64 3.3.4 Service requirements for Streaming.................................................................................... 65 3.3.5 Service requirements for File Transfer ............................................................................... 67 3.3.6 Service requirements for Email........................................................................................... 68 3.3.7 Service requirements for Newsgroup.................................................................................. 69 3.3.8 Service requirements for Interactive Games....................................................................... 70 3.3.9 Service requirements for Messenger ................................................................................... 71

3.4 LAN INTERCONNECTION SERVICE .................................................................................... 74 3.5 MULTICAST SERVICE ............................................................................................................ 78

4. NEW SERVICES AND FUNCTIONALITIES.............................................................................. 85

4.1 E-LEARNING ............................................................................................................................ 85 4.1.1 Introduction......................................................................................................................... 85 4.1.2 General requirements ......................................................................................................... 87 4.1.3 Quality of Service requirements.......................................................................................... 88 4.1.4 Security requirements ......................................................................................................... 90

4.2 VIDEO ON DEMAND ............................................................................................................... 91 4.3 SOFTWARE DOWNLOAD....................................................................................................... 96 4.4 NOMADIC ACCESS.................................................................................................................. 99

5. MULTIMEDIA REQUIREMENTS............................................................................................. 103

5.1 INTRODUCTION .................................................................................................................... 103 5.1.1 Proprietary Developments................................................................................................ 104 5.1.2 Standard formats............................................................................................................... 106

5.1.2.1 Standard formats up to MPEG-4................................................................................... 106 5.1.2.2 JVT/H.264 Standard...................................................................................................... 106

5.2 AUDIO AND VIDEO REQUIREMENTS............................................................................... 107 5.2.1 MPEG1.............................................................................................................................. 107

5.2.1.1 Fixed And Variable Bitrate coding............................................................................... 108 5.2.1.2 TV and PC contents...................................................................................................... 108 5.2.1.3 Audio And Video File Formats..................................................................................... 109

5.2.2 MPEG-2 ............................................................................................................................ 109 5.2.2.1 Levels And Profiles....................................................................................................... 110 5.2.2.2 Fixed And Variable Bitrate Coding.............................................................................. 111 5.2.2.3 Bitrate............................................................................................................................ 111 5.2.2.4 TV And PC Contents.................................................................................................... 111 5.2.2.5 Audio And Video File Formats..................................................................................... 112

5.2.3 MPEG-4 ............................................................................................................................ 112 5.2.3.1 Levels And Profiles....................................................................................................... 113 5.2.3.2 TV and PC contents...................................................................................................... 116 5.2.3.3 Audio and video file formats ........................................................................................ 116

5.2.4 H.264/AVC........................................................................................................................ 116

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

5 / 247

5.2.5 Windows Media................................................................................................................. 122

5.2.5.1 Windows Media Encoder.............................................................................................. 123 5.2.6 Real Media........................................................................................................................ 123

5.2.6.1 Real Video 10 Encoder ................................................................................................. 124 5.2.7 Quick Time........................................................................................................................ 124 5.2.8 DivX .................................................................................................................................. 125

5.3 STREAMING REQUIREMENTS............................................................................................ 127 5.3.1 Audio/Video Transport...................................................................................................... 128

5.3.1.1 MPEG2 Systems........................................................................................................... 128 5.3.1.2 Real Time Protocol: RTP.............................................................................................. 128 5.3.1.3 RTSP. Real Time Streaming Protocol .......................................................................... 129

5.3.2 Digital TV streaming......................................................................................................... 130 5.3.2.1 Encoders........................................................................................................................ 130 5.3.2.2 Multiplexers.................................................................................................................. 130

5.3.3 PC streaming..................................................................................................................... 131 5.3.3.1 Microsoft Windows Media, AVI Video (* .avid).......................................................... 132

5.3.3.1.1 Unicast Streaming................................................................................................... 132 5.3.3.1.2 Multicast Streaming................................................................................................ 132

5.3.3.2 Apple QuickTime, Darwin Streaming Server (* .move) ............................................... 134 5.3.3.3 Real Video..................................................................................................................... 134

6. MANAGEMENT TOOLS REQUIREMENTS............................................................................ 136

6.1 MANAGEMENT REQUIREMENTS...................................................................................... 137 6.1.1 Requirements for “ common enabling services” for the Network Provider ...................... 138 6.1.2 Requirements For Optional “ Common Enabling Services” For The Network Provider . 139 6.1.3 Requirements For End To End Service Provisioning....................................................... 141

6.1.3.1 Definition Of Type Of Service...................................................................................... 141 6.1.3.2 Subscribers.................................................................................................................... 141 6.1.3.3 Service Providers.......................................................................................................... 143

6.2 MONITORING REQUIREMENTS......................................................................................... 144 6.2.1 Levels And Uses Of Performance Measurement Information .......................................... 146 6.2.2 Recommended IT Customer Facing Performance Measures ........................................... 146 6.2.3 Multipurpose probes......................................................................................................... 148 6.2.4 QoS assurance................................................................................................................... 149 6.2.5 Service requirement for Monitoring unit .......................................................................... 150

6.3 OPERATION REQUIREMENTS............................................................................................ 151 6.3.1 Service Level Agreements................................................................................................. 152

6.3.1.1 Network Performance Metrics...................................................................................... 152 6.3.1.2 Operational Metrics....................................................................................................... 153

6.3.2 Procedures........................................................................................................................ 153

7. TOOLS REQUIREMENTS........................................................................................................... 158

7.1 MODELING TOOLS................................................................................................................ 159 7.1.1 End-to-End QoS model requirements............................................................................... 159 7.1.2 End-to-End Multicast model requirements....................................................................... 161 7.1.3 Conversational model requirements................................................................................. 163

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

6 / 247

7.1.4 User Traffic Models.......................................................................................................... 163

7.2 PERFORMANCE EVALUATION TOOLS............................................................................. 163 7.2.1 Requirements for system level measurement tools............................................................ 163 7.2.2 Requirements for Simulation tools.................................................................................... 168

7.3 BILLING TOOLS..................................................................................................................... 169 7.3.1 Billing................................................................................................................................ 170 7.3.2 Radius................................................................................................................................ 173 7.3.3 Reporting........................................................................................................................... 174

8. REQUIREMENTS SUMMARY ................................................................................................... 176

9. CONCLUSIONS............................................................................................................................. 191

A. ANNEX: SIMULATION TOOLS.................................................................................................... 192

A.1 PARALLEL/DISTRIBUTED NETWORK SIMULATOR (PDNS).............................................. 192 A.2 GEORGIA TECH NETWORK SIMULATOR (GTNETS) ........................................................... 192 A.3 SCALABLE SIMULATION FRAMEWORK (SSFNET)............................................................. 192 A.4 OPNET MODELER....................................................................................................................... 193 A.5 NETWORK SIMULATOR 2 (NS-2) ............................................................................................. 193 A.6 ANALYSIS OF THE SIMULATOR TOOLS ACCORDING TO THE IMPOSED

REQUIREMENTS................................................................................................................................ 194 A-6.1 PDNS....................................................................................................................................... 194 A-6.2 GTNetS.................................................................................................................................... 196 A-6.3 SSFNet..................................................................................................................................... 197 A-6.4 NS-2......................................................................................................................................... 198 A-6.5 OPNET.................................................................................................................................... 199

A.7 CONCLUSIONS............................................................................................................................ 200

B. ANNEX: EMULATION TOOLS...................................................................................................... 202

C. ANNEX: ANALYSIS OF THE CONFERENCE MODELS.......................................................... 203

C.1 REQUIRED MULTIPARTY CONFERENCING MODELS. SIGNALLING/MEDIA CONNECTIVITY ................ 203 C.2 TIGHTLY COUPLED CONFERENCE: END SYSTEM MIXING OR END POINT SERVER. ........................... 203

C-2.1 Suitability for SATLIFE .......................................................................................................... 203 C.3 LOOSELY COUPLED CONFERENCE: LARGE-SCALE MULTICAST CONFERENCES............................... 204

C-3.1 Suitability for SATLIFE .......................................................................................................... 204 C-3.2 Scalability................................................................................................................................ 204

C.4 TIGHTLY COUPLED CONFERENCE: CENTRALIZED CONFERENCE SERVER (MEDIA AND SIGNALLING

MAY BE DIFFERENT SERVERS)................................................................................................................. 204 C-4.1 Suitability for SATLIFE .......................................................................................................... 205

C.5 TIGHTLY COUPLED CONFERENCE: CENTRALIZED SIGNALLING, DISTRIBUTED M IXING MEDIA ....... 205 C-5.1 Suitability for SATLIFE .......................................................................................................... 206 C-5.2 Scalability................................................................................................................................ 206

C.6 TIGHTLY COUPLED CONFERENCE: MULTIPLE MEDIA SERVERS (MULTIPLE-MCUS OR CASCADED

MIXERS)................................................................................................................................................. 206 C-6.1 Suitability for SATLIFE .......................................................................................................... 206

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

7 / 247

C-6.2 Scalability................................................................................................................................ 207

D. ANNEX: DETAILED TRAFFIC MODELS................................................................................... 208

D.1 IBIS TRAFFIC MODELS.................................................................................................................... 208 D.2 APPLICATION TRAFFIC MODELS BUILT IN OPNET SIMULATOR...................................................... 208

D-2.1 Application Models configurability ........................................................................................ 209 D-2.1.1 File transfer (FTP) ........................................................................................................... 209 D-2.1.2 E-mail............................................................................................................................... 209 D-2.1.3 Remote Login .................................................................................................................. 210 D-2.1.4 Video Conferencing......................................................................................................... 210 D-2.1.5 Database........................................................................................................................... 210 D-2.1.6 Web browsing.................................................................................................................. 211 D-2.1.7 Printing............................................................................................................................. 211 D-2.1.8 Voice................................................................................................................................ 212 D-2.1.9 Custom application.......................................................................................................... 212

D-2.2 User Profiles........................................................................................................................... 214 D.3 APPLICATION TRAFFIC MODELS BUILT IN NS................................................................................. 215

D-3.1 Exponential On/Off traffic source........................................................................................... 215 D-3.2 Pareto On/Off traffic source................................................................................................... 215 D-3.3 CBR traffic source.................................................................................................................. 215 D-3.4 Traffic Trace driven traffic source.......................................................................................... 216 D-3.5 FTP ......................................................................................................................................... 216 D-3.6 Telnet ...................................................................................................................................... 216 D-3.7 Web cache............................................................................................................................... 216

E. ANNEX: METHODS FOR MEASURING SPEECH QUALITY ................................................. 218

F. ANNEX: IP MULTICAST PROTOCOLS...................................................................................... 220

F.1 IP MULTICAST CONCEPT .................................................................................................................. 220 F-1.1 Multicast Addressing............................................................................................................... 221 F-1.2 Multicast scoping .................................................................................................................... 221 F-1.3 Internet Group Management Protocol (IGMP) ...................................................................... 222

F.2 IP MULTICAST ROUTING.................................................................................................................. 222 F-2.1 Intra-domain protocols ........................................................................................................... 223 F-2.2 Inter-domain protocols............................................................................................................ 226

F-2.2.1 Near-term solutions.......................................................................................................... 227 F-2.2.2 Long-term solutions.......................................................................................................... 229

G. ANNEX: QUALITY OF SERVICE PROVISION ISSUES........................................................... 234

G.1 ITU B-ISDN QOS MODEL ............................................................................................................... 234 G.2 INTERNET INTEGRATED SERVICES QOS MODEL............................................................................... 235

G-2.1 RSVP....................................................................................................................................... 238 G.3 INTERNET DIFFERENTIATED SERVICES (DIFFSERV) QOS MODEL. ................................................... 240 G.4 PERFORMANCE PROBLEMS OF WINDOW BASED TRANSPORT PROTOCOLS OVER SATELLITE. ............. 242

G-4.1 Issues and Challenges............................................................................................................. 242 G-4.1.1 Channel Asymmetry ........................................................................................................ 242

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

8 / 247

G-4.1.2 Propagation Delays.......................................................................................................... 243

G-4.2 Solutions based on TCP modifications................................................................................... 243 G-4.2.1 Window size.................................................................................................................... 243 G-4.2.2 Sequence numbering........................................................................................................ 243 G-4.2.3 Round trip time measurements........................................................................................ 243 G-4.2.4 Path MTU discovery........................................................................................................ 244 G-4.2.5 Slow start phase. .............................................................................................................. 244 G-4.2.6 Selective Acknowledge.................................................................................................... 244 G-4.2.7 Asymmetry Considerations.............................................................................................. 245

G-4.3 Solutions based on Intelligent Interworking........................................................................... 245 G-4.3.1 Multiple TCP Sessions..................................................................................................... 245 G-4.3.2 Sharing TCP State Among Similar Connections............................................................. 245 G-4.3.3 Link-Layer Interworking ................................................................................................. 246 G-4.3.4 ACK Control Schemes..................................................................................................... 246

H. RELATED DOCUMENTS............................................................................................................... 247

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

9 / 247

TABLE INDEX

TABLE 1. TABLE_ID ASSIGNMENT VALUES................................................................................. 32

TABLE 2. STREAM TYPE ASSIGNMENTS....................................................................................... 33

TABLE 3. PROGRAM AND PROGRAM ELEMENT DESCRIPTORS........................................... 33

TABLE 4. APPROXIMATE MAXIMUM NUMBER OF SIMULTANEOUS TRANSMITTING USERS FOR DIFFERENT TYPES OF SATELLITE TERMINAL. .................................................. 54

TABLE 5. BANDWIDTH FOR VIDEO AND AUDIO......................................................................... 57

TABLE 6. MPEG-2 LEVELS................................................................................................................ 110

TABLE 7. MPEG-2 PROFILE DEFINITIONS .................................................................................. 110

TABLE 8. MPEG-4 PROFILE DEFINITION..................................................................................... 114

TABLE 9. H.264 ENCODER PERFORMANCE ................................................................................ 120

TABLE 10. H.264 DECODER PERFORMANCE .............................................................................. 120

TABLE 11. AUDIO QUALITY RATING VALUES REQUIREMENTS......................................... 164

TABLE 12. CATEGORIES OF SPEECH TRANSMISSION QUALITY ........................................ 164

TABLE 13. END-TO-END DELAY SPECS FOR TIPHON SPEECH QOS CLASSES................. 165

TABLE 14. MOS MEASURE RATING............................................................................................... 167

TABLE 15. MOS ACCEPTED VALUES............................................................................................. 167

TABLE 16. MOS RATES FOR VARIOUS CODECS........................................................................ 167

TABLE 17. REQUIREMENTS SUMMARY ....................................................................................... 190

TABLE 18. TCP AGENTS..................................................................................................................... 194

TABLE 19. SIMULATION TOOLS REQUIREMENTS SUPPORT................................................ 201

TABLE 20. ATM SERVICE CLASS PARAMETERS....................................................................... 235

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

10 / 247

FIGURE INDEX

FIGURE 1. RELATIONSHIP BETWEEN ROLES.............................................................................. 26

FIGURE 2. TRANSPARENT DIGITAL TV SCENARIO ................................................................... 35

FIGURE 3. REGENERATIVE DIGITAL TV SCENARIO................................................................. 35

FIGURE 4. INTERACTIVE TV SCENARIO ....................................................................................... 37

FIGURE 5. IBIS VIDEO SERVICE PROVISIONING........................................................................ 40

FIGURE 6. SATLIFE VIDEO SERVICE PROVISIONING............................................................... 41

FIGURE 7. TYPICAL SCENARIO OF CONFERENCE SERVICE.................................................. 43

FIGURE 8. INTERNET ACCESS SCENARIO. SERVICE PROVISIONING OUTSIDE THE SATELLITE NETWORK ........................................................................................................................ 60

FIGURE 9. INTERNET ACCESS SCENARIO. SERVICE PROVISIONING INSIDE THE SATELLITE NETWORK ........................................................................................................................ 61

FIGURE 10. LAN INTERCONNECTION SCENARIO ...................................................................... 74

FIGURE 11. MESH MULTICAST SCENARIO................................................................................... 79

FIGURE 12. STAR MULTICAST SCENARIO.................................................................................... 79

FIGURE 13. MULTICAST SCENARIO WITH MULTICAST TERMINAL USERS OUTSIDE OF THE SATELLITE NETWORK .............................................................................................................. 80

FIGURE 14. E-LEARNING SCENARIO .............................................................................................. 86

FIGURE 15. VIDEO ON DEMAND SCENARIO................................................................................. 91

FIGURE 16. SOFTWARE DOWNLOAD SCENARIO........................................................................ 96

FIGURE 17. NOMADIC ACCESS SCENARIO. APPLICATION PROVIDER INSIDE SATELLITE NETWORK ........................................................................................................................ 99

FIGURE 18. NOMADIC ACCESS SCENARIO. APPLICATION PROVIDER OUTSIDE THE SATELLITE NETWORK ...................................................................................................................... 100

FIGURE 19. CLASSICAL STANDARDS EVOLUTION .................................................................. 104

FIGURE 20. AN OVERVIEW OF THE PROFILE STRUCTURE IN MPEG-4 ............................ 114

FIGURE 21. ARCHITECTURE LAYERS.......................................................................................... 136

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

11 / 247

FIGURE 22. PROCESS FOR THE MODELLING OF SATLIFE.................................................... 159

FIGURE 23. MULTIPLE MCU ARCHITECTURE EXAMPLE...................................................... 206

FIGURE 24. BASIC MULTICAST TRANSMISSION MODULE.................................................... 220

FIGURE 25. IP MULTICAST PROTOCOL STACK ........................................................................ 221

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

12 / 247

1. EXECUTIVE SUMMARY This deliverable represents the essential set of service requirements needed for the effective provision and improvement of DVB-RCS regenerative and transparent systems. Their integration with terrestrial systems has been fully considered as a powerful way of complementing those terrestrial alternatives and have the possibility to offer broadband solutions in the marketplace. In this sense, most of the requirements come from the practical experience in the development and provisioning of services by telecom operators. It is important to mention that SATLIFE starts from previous successful projects. ESA- AMERHIS project which has derived in the first regenerative DVB-RCS system in the world on-board of Hispasat´s Amazonas satellite in orbit. In addition, SATLIFE will take full advantage of IST-IBIS results and demonstrator. Other projects considered have been IST-ICEBERGS or IST-GEOCAST. All that means that the background on advanced satellite solutions and successful projects have been fully considered particularly in the scenario of standard DVB-RCS in both regenerative and transparent systems. The document is structured covering all the relevant aspects related to the definition of requirements for digital TV, multiconference, VoIP, LAN-to-LAN connection, Internet access, multicast access, etc. that will facilitate the enhancement and optimisation of DVB-RCS. In addition, multimedia, streaming, VoD, nomadic, etc. have been studied in detail with the view to augment the number of future functionalities and options available. In summary, throughout this document an extensive compilation of requirements is done with the view to further enhance AMERHIS and transparent RCS systems in their flexibility, security, quality of service, efficient multicast and integration with terrestrial networks. Furthermore, the views from a telecom operator have facilitated new scenarios and functionalities needed to widen the possibilities and reinforce the exploitation of DVB-RCS systems in the construction of the Information Society.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

13 / 247

2. DOCUMENT OVERVIEW SATLIFE stands for Satellite Access Technologies: Leading Improvements For Europe. This project will be the first and unique R&D project in the world working with the AMERHIS system, the first multimedia on-board processor, based on DVB-RCS and DVB-S standards. The AMERHIS is embedded in Amazonas satellite. SATLIFE will strategically respond to the imperative need of facilitating the development of a broadband-for-all access by means of significantly enhancing the state of the art of DVB-RCS satellite standard solutions for both regenerative and transparent systems while integrating them with other terrestrial alternatives. SATLIFE is based on previous work, which includes projects from the Information Society Technologies program, such as GEOCAST, ICEBERGS and the aforementioned IBIS/AMERHIS. As has been said, the IBIS/AMERHIS project defined the first on-board multimedia processor for a satellite, making use of the recent DVB-RCS standard. The goal of SATLIFE is to take profit from the features of this on-board processor and develop applications and services for this system. The GEOCAST project has investigated technical issues associated with providing multicast support as a part of the next generation of Internet Service. In particular, the GEOCAST project has come up to a better definition of multicast satellite systems, making use of new generation satellites like Amazonas. This applies to multicast applications that are described in this document. Finally, the ICEBERGS project aimed to design and validate an integrated broadband communication infrastructure for IP-based multiparty, QoS-sensitive, conversational services, for fixed, mobile and portable terminals topologies, for both business and consumer reference service scenarios. These topics, in particular QoS issues, may be considered as a starting point for the requirements of SATLIFE. This document provides a general description of the requirements for the services planned for SATLIFE. This includes audio, video, multimedia and streaming requirements, management tools requirements, other tools requirements and specific requirements for interactive applications, which will be described in depth. For this purpose, the requirements stated in those previous projects will be taken into account and further developed in order to adapt it to the new applications considered. As will be seen, services in both regenerative and transparent modes will apply, so the following requirements will cover these two cases of use.

2.1 SCOPE OF THE DOCUMENT This document defines the requirements for DVB-RCS Regenerative (and Transparent) System Services to be supported in the frame of the SATLIFE Project.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

14 / 247

2.2 FIELD OF APPLICATION This document is applicable to DVB-RCS Network Aspects and Technology & Subsystems teams to define their implications and derived requirements in these two areas.

2.3 DOCUMENTATION

2.3.1 Related documents The related documents are not contractual but they may offer a better understanding of this document. .

Ref. Document Name Document Reference RD1 IBIS - Service & System Requirements (Iss. 01 -16/07/2001) 30006819/938 RD2 IBIS – Standards Analysis AEO-003687 RD3 AMERHIS – System Technical Requirement Document AMHIS-ASP I-SP -11 /07 RD4 GEOCAST – Security System Analysis GEOC-UOS-DD-2400-final RD5 GEOCAST – Multicast protocols and applications GEOCAST-UOA-1300 Report RD6 ICEBERGS - Multimedia conferencing over GEO satellites, a

system assessment ICEBERG IST project D1-1

RD7 ICEBERGS - EuroSkyWay Videoconference Support System Requirement

ICEBERG IST project D1-2

RD8 ICEBERGS - Requirements of ICEBERGS, v4.1, 7th April 2003 ICEBERG IST project Annex to Deliverables

2.3.2 Applicable norms and standards The level of applicability of these standards is described in this document. Ref IETF Doc Ref. Group [AN1] Internet Protocol RFC 791 IP [AN2] User Datagram Protocol RFC 768 UDP [AN3] Transmission Control Protocol RFC 793 TCP [AN4] Simple Mail Transport Protocol RFC 821 SMTP [AN5] Telnet Protocol Specification RFC 854 TELNET [AN6] File Transfer Protocol RFC 959 FTP [AN7] Network and News Transfer Protocol RFC 977 NNTP [AN7] TCP extensions for long-delay paths RFC 1072 TCPLW [AN8] TCP Extensions for High Performance RFC 1323 TCPLW [AN9] Type of Service in the Internet Protocol Suite RFC 1349 [AN10] Requirements for Multicast Protocols RFC 1458 [AN11] Internet Relay Chat RFC 1459 IRC [AN12] Multicast Extensions to OSPF RFC 1584 MOSPF [AN13] Integrated Services in the Internet Architecture: an Overview RFC 1633 [AN14] TCP Extensions for Transactions Functional Specification RFC 1644 [AN15] Post Office Protocol version 3 RFC 1725 POP3 [AN16] Internet Message Access Protocol RFC 1730 IMAP [AN17] RTP: A Transport Protocol for Real-Time Applications RFC 1889 AVT [AN18] RTP Profile for Audio and Video Conferences with Minimal Control RFC 1890 AVT

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

15 / 247

[AN19] TCP Selective Acknowledgement Options RFC 2018 [AN20] Remote Authentication Dial In User Service (RADIUS) RFC 2138 NASREQ [AN21] RADIUS Accounting RFC 2139 [AN22] Resource ReSerVation Protocol (RSVP) -- Version 1 Functional

Specification RFC 2205 RSVP

[AN23] The Use of RSVP with IETF Integrated Services RFC 2210 INTSERV [AN24] Specification of the Controlled-Load Network Element Service RFC 2211 INTSERV [AN25] Specification of Guaranteed Quality of Service RFC 2212 INTSERV [AN26] General Characterization Parameters for Integrated Service

Network Elements RFC 2215 INTSERV

[AN27] Multiprotocol Extensions for BGP-4 RFC 2283 IDR [AN28] Real Time Streaming Protocol RFC 2326 MMUSIC [AN29] Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol

Specification RFC 2362 IDMR

[AN30] Security Architecture for the Internet Protocol RFC 2401 IPSEC [AN31] Internet Protocol, Version 6 RFC 2460 IPv6 [AN32] IP Version 6 over PPP RFC 2472 IPv6 [AN33] Definition of the Differentiated Services Field (DS Field) in the IPv4

and IPv6 Headers RFC 2474 DIFFSERV

[AN34] An Architecture for Differentiated Service RFC 2475 DIFFSERV [AN35] Enhancing TCP Over Satellite Channels using Standard Mechanisms RFC 2488 [AN36] Extended Simple Mail Transport Protocol RFC 2554 ESMTP [AN37] Assured Forwarding PHB Group RFC 2597 DIFFSERV [AN38] An Expedited Forwarding PHB RFC 2598 DIFFSERV [AN39] HyperText Transfer Protocol 1.1 RFC 2616 HTTP [AN40] A Model for Presence and Instant Messaging RFC 2778 IMPP [AN41] Instant Messaging / Presence Protocol Requirements RFC 2779 IMPP [AN42] Call Processing Language Framework and Requirements RFC 2824 IPTEL [AN43] A Framework for Telephony Routing over IP RFC 2871 IPTEL [AN44] The Internet Multicast Address Allocation Architecture RFC 2908 MALLOC [AN45] Computing TCP's Retransmission Timer RFC 2988 TSVWG [AN46] Performance Enhancing Proxies Intended to Mitigate Link-Related

Degradations RFC 3135 PILC

[AN47] End-to-end Performance Implications of Links with Errors RFC 3155 PILC [AN48] IANA Guidelines for IPv4 Multicast Address Assignments RFC 3171 MBONED [AN49] Telephony Routing over IP (TRIP) RFC 3219 IPTEL [AN50] SIP: Session Initiation Protocol RFC 3261 SIP [AN51] Session Initiation Protocol Extension for Instant Messaging RFC 3428 SIP [AN52] TCP Performance Implications of Network Path Asymmetry RFC 3449 PILC [AN53] TCP over Second (2.5G) and Third (3G) Generation Wireless

Networks RFC 3481 PILC

[AN54] Real Time Protocol RFC 3550 AVT [AN55] RTP Profile for Audio and Video Conferences with Minimal Control RFC 3551 AVT [AN56] The Secure Real-time Transport Protocol RFC 3711 AVT Ref ETSI Doc Ref. Group ETS1 Digital broadcasting systems for television, sound and data services

- Framing structure, channel coding and modulation for 11/12 GHz satellite services

ETS 300 421 DVB-S

ETS2 Digital Video Broadcasting (DVB); interaction channel for satellite distribution system

EN 301 790 DVB-RCS

ETS3 Digital Video Broadcasting (DVB); specification for data broadcasting

EN 301 192 DVB-S

ETS4 Digital Video Broadcasting (DVB); implementation guidelines for data broadcasting

TR 101 202 DVB-S

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

16 / 247

ETS5 Digital Video Broadcasting (DVB) interaction channel for Satellite

Distribution Systems; guidelines for the use of EN301790 TR 101 790 DVB-RCS

ETS6 Digital Video Broadcasting (DVB); specification for Service Information (SI) in DVB systems

EN 300 408

DVB-SI

ETS7 Digital Video Broadcasting (DVB); implementation guidelines for the use of MPEG-2 Systems, Video and Audio in satellite, cable and terrestrial broadcasting applications

TR 101 154 DVB

ETS8 Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems

TR 101 290 DVB-M

ETS9 Multimedia Home Platform (MHP) Specification 1.1 ETSI TS 102 812 DVB-MHP ETS10 Videotelephony over NGN draft DES/TISPAN-

01001-NGN TISPAN

ETS11 End-to-end Quality of Service in TIPHON Systems;Part 1: General aspects of Quality of Service (QoS)

ETSI TR 102 024-1 TIPHON5

ETS12 End-to-end Quality of Service in TIPHON Systems; Part 2: Definition of Speech Quality of Service (QoS) Classes

ETSI TS 102 024-2 TIPHON5

ETS13 End-to-end Quality of Service in TIPHON Systems;Part 3: Signalling and Control of end-to-end Quality of Service


ETS14 End-to-end Quality of Service in TIPHON Systems;Part 4: Quality of Service Management


ETS15 End-to-end Quality of Service in TIPHON Systems;Part 5: Quality of Service (QoS) measurement methodologies


ETS16 End-to-end Quality of Service in TIPHON Systems;Part 6: Actual measurements of network and terminal characteristics and performance parameters in TIPHON networks and their influence on voice quality


ETS17 End-to-end Quality of Service in TIPHON Systems;Part 7: Design guide for elements of a TIPHON connection from an end-to-end speech transmission performance point of view


ETS18 End-to-End Quality of Service in TIPHON Systems;Part 9: Call performance Classification (Voice)


ETS19 End-to-end Quality of Service in TIPHON Systems;Part 12: IP Telephony Service Availability


ETS20 Application and enhancements of the E-Model (ETR 250);Overview of available documentation and ongoing work

ETSI TR 102 356 STQ

ETS21 Human Factors (HF);Guidelines for real-time person-to-person communication services

ETSI TR 102 274 HF

ETS22 Human Factors (HF); Human Factors in Videotelephony ETSI ETR 297 HF ETS23 Transmission and Multiplexing TM; Speech communication quality

from mouth to ear for 3,1 kHz handset telephony across networks ETSI ETR 250 TM5

Ref ITU Doc Ref. Group ITU1 The E-Model, a computational model for use in transmission

planning ITU-T G.107 SG12

ITU2 Application of the E-model: A planning guide ITU-T G.108 SG12 ITU3 Guidance for assessing conversational speech transmission quality

effects not covered by the E-model ITU-T G.108.1 SG12

ITU4 Definition of categories of speech transmission quality ITU-T G.109 SG12 ITU5 Transmission impairments due to speech processing ITU-T G.113 SG12 ITU6 Provisional planning values for the equipment impairment factor Ie

and packet-loss robustness factor Bpl (Transcoding) ITU-T G.113 Appendix I SG12

ITU7 One-way transmission time ITU-T G.114 SG12 ITU8 Guidance on one-way delay for Voice over IP ITU-T G.114 appendix

II SG12

ITU9 Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)

ITU T G.729 SG12

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

17 / 247

ITU10 Implementor's Guide for G.723.1 and G.729 Annexes F, G, H, I ITU T

G.Imp723.1/G.729/G.723.1

SG12

ITU11 Communications Quality of Service: A framework and definitions ITU-T G.1000 SG12 ITU12 End-user multimedia QoS categories ITU-T G.1010 SG12 ITU13 Performance parameter definitions for quality of speech and other

voiceband applications utilising IP networks ITU-T G.1020 SG12

ITU14 artificial voices ITU-T P.50 SG12 ITU15 In-service non-intrusive measurementdevice - Voice service

measurements ITU-T P.561 SG12

ITU16 Analysis and interpretation of INMD voice-service measurements ITU-T P.562 SG12 ITU17 methods for subjective determination of transmission quality ITU-T P.800 SG12 ITU18 Mean Opinion Score (MOS) terminology ITU-T P.800.1 SG12 ITU19 Subjective performance assessment of telephone-band and

wideband digital codecs ITU-T P.830 SG12

ITU20 Objective quality measurement of telephone-band (300-3400 Hz) speech codecs (PSQM algorithm)

ITU-T P.861 SG12

ITU21 Perceptual evaluation of speech quality (PESQ), an objective method for end-to-end speech quality assessment of narrowband telephone networks and speech codecs

ITU-T P.862 SG12

ITU22 Perceptual evaluation of speech quality (PESQ), an objective method for end-to-end speech quality assessment of narrowband telephone networks and speech codecs

ITU-T P.862 Amedment SG12

ITU23 Subjective video quality assessment methods for multimedia applications

ITU-T P.910 SG12

ITU24 Subjective audiovisual quality assessment methods for multimedia applications

ITU-T P.911 SG12

ITU25 General requirements for interworking with Internet protocol (IP)-based networks

ITU-T Y.1401 SG13

ITU26 Packet-based multimedia communications systems ITU-T H.323 SG16 ITU27 Implementors' Guide for Recommendations of the H.323 System

("Packet-based multimedia communications systems"):H.323, H.225.0, H.245, H.246, H.283, H.235, H.341, H.450 Series, H.460 Series, and H.500 Series

ITU-T H.Imp323/H.323/H.225.0/H.245/H.246/H.235/H.341

SG16

ITU28 A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels

ITU-T H.224 SG16

ITU29 Control protocol for multimedia communication ITU-T H.245 SG16 ITU30 Implementors' Guide for Recommendations of the H.323 System

("Packet-based multimedia communications systems"):H.323, H.225.0, H.245, H.246, H.283, H.235, H.341, H.450 Series, H.460 Series, and H.500 Series

ITU-T H.Imp323/H.323/H.225.0/H.245/H.246/H.235/H.341 (01/04) H.350

SG16

ITU31 Directory services architecture for multimedia conferencing ITU-T H.350 SG16 ITU32 Frame structure for a 64 to 1920 kbit/s channel in audiovisual

teleservices ITU-T H.221 SG16

ITU33 Multipoint extension for broadband audiovisual communication systems and terminals

ITU-T H.247 SG16

ITU34 Broadband audiovisual communication systems and terminals

ITU-T H.310 SG16

Ref ISO Doc Ref. Group ISO1 Generic coding of moving pictures and associated audio – Part 1:

Systems ISO/IEC 13818-1 MPEG

ISO2 Generic coding of moving pictures and associated audio – Part 2: Video

ISO/IEC 13818-2 MPEG

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

18 / 247

ISO3 Generic coding of moving pictures and associated audio – Part 3:

Audio ISO/IEC 13818-3 MPEG

ISO4 Generic coding of moving pictures and associated audio information: Extensions for Digital Storage Media Command and Control

ISO/IEC 13818-6 DSM-CC

ISO5 Coding of audio-visual objects - Part 2: Visual ISO/IEC 14496-2 MPEG ISO6 Coding of audio-visual objects - Part 10: Advanced Video Coding ISO/IEC 14496-10 MPEG ISO7 Coding of moving pictures and associated audio for digital storage

media at up to about 1,5 Mbps ISO/IEC 11172 MPEG

2.4 TERMINOLOGY AND ABBREVIATIONS The main acronyms used in this document are listed below, so that to ease the reading of this document. 16CIF 16-Common Intermediate Format 4CIF 4-Common Intermediate Format A/V Audio / Video AAA Authentication, Authorization and Accounting AAC Advanced Audio Coding ABR Available Bit Rate ADTS Audio Date Transport System AF Assured Forwarding AIFF Apple Interchange File Format AIT Application Information Table API Application Program Interface ARPU Average Revenue per User AS Autonomous System ASCII American Standard Code for Information Interchange ASF Advanced Streaming Format ASP Application Service Providers ASP Advanced Simple Profile ATM Asynchronous Transfer Mode AuSP Audio Service Provider AVC Advanced Video Coding AVC Advanced Video Coding AVI Audio Video Interleaved BGP Border Gateway Protocol BiFS Binary Format for Screener BIOP Broadcast Inter ORB Protocol CA Conditional Access CABAC Context-based Adaptive Binary Arithmetic Coding CAM Conditional Access Messages CBR Constant Bit Rate CBT Core-Based Trees CCITT International Consultative Committee of Telegraph and Telephone CDR Call Detail Records

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

19 / 247

CDTV Cell Delay Tolerated Variation CDV Cell Delay Variation CER Cell Error Rate CIF Common Intermediate Format CLEC Competitive Local Exchange Carrier CLIP Calling Line Identification Presentation CLIR Calling Line Identification Restriction CLR Cell Loss Ratio CMR Cell Misinsertion Rate COLP Connected Line Identification Presentation COLR Connected Line Identification Restriction CPC Conference Policy Control CPE Customer Premises Equipment CPL Call Processing Language CPM Critical Path Method CPS Calls per second CPU Central Processing Unit CRTP Compressed Real-Time Protocol CSMA/CA Carrier Sense Multiple Access – Collision Avoidance CSMA/CD Carrier Sense Múltiple Access – Collision Detection CTD Cell transfer delay CU Currently Unused DiffServ Differentiated Services DIS Draft International Standard DMIF Delivery Multimedia Integration Framework DML Domain Modelling Language DNS Domain Name Server DRM Digital Right Management DS Differentiated Services DSCP Differentiated Services Codepoint DSL Digital Subscriber Line DSM-CC Digital Storage Media - Command & Control DTS Decoding Time Stamps DTSP Digital TV Service Provider DVB-HTML Digital Video Broadcast - HyperText Markup Language DVB-J Digital Video Broadcast – Java DVB-MHP Digital Video Broadcast – Multimedia Home Platform DVB-MPE Digital Video Broadcast – MultiProtocol Encapsulation DVB-RCS Digital Video Broadcast-Return Channel Signalling DVB-S Digital Video Broadcasting – Satellite DVB-SI Digital Video Broadcast - Service Information DVD Digital Versatile Disk DVMRP Distance-Vector Multicast Routing Protocol E2E End to End ECM Entitlement Control Messages

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

20 / 247

EMM Entitlement Management Messages ESMTP Extended Simple Mail Transport Protocol ESP E-learning Service Provider ETSI European Telecommunications Standards Institute FCD Final Comitee Draft FDDI Fiber Distributed Data Interface FDIS Final Draft International Standard FER Frame Error Rate FIFO First In First Out FMO Flexible Macroblock Ordering FPS Frames per Second FTP File Transfer Protocol FW Firewall GOP Group Of Pictures GPL GNU Public Licence GPS Global Positioning System GSM Global System for Mobile communications HDTV High Definition Television HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure HW Hardware IA Intelligent Agent IANA Internet Assigned Numbers Authority IASP Interactive Applications Service Provider ID Identifier IDE Integrated Development Environment IEC International Electrotechnical Commission IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IMAP Internet Message Access Protocol INAP Interactive Network Access Provider IntServ Integrated Services IP Internet Protocol IPSEC Internet Protocol Security IRC Internet Relay Chat IS Integrated Services ISDN Integrated Services Digital Network ISL Interswitch Link ISO International Organization for Standardization/ ISP Internet Service Provider IT Information Technology ITSP Internet Telephony Service Provider ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

21 / 247

JPEG Joint Picture Experts Group JVT Joint Video Team L2TP Layer 2 Tunneling Protocol LAN Local Area Network LEC Local Exchange Carrier MAAS Multicast Address Allocation Server MAC Multiple Access Control MAN Metropolitan Area Network MASC Multicast Address-Set Claim MBGP Multicast Border Gateway Protocol MBS Maximum Burst Size MCR Minimum Cell Rate MCS Master Control Station MCSP Multiconference Service Provider MCU Multipoint Control Unit MHEG Multimedia Home Experts Group MHP Multimedia Home Platform MIDI Musical Instrument Digital Interface MIGP Multicast Interior Gateway Protocol MIT Massachusetts Institute of Technology MMS Microsoft Media Server MOS Mean Opinion Score MOSPF Multicast extension to Open Shortest Path First MPEG Motion Pictures Expert Group MSDP Multicast Source Discovery Protocol MSNP Microsoft Network Protocol MSP Multicast Service Provider MSS Maximum Segment Size MTP Multicast Transport Protocol MTU Maximum Transfer Unit NAL Network Abstraction Layer NAM Network Animator NAS Network Attached Storage NAT/FW Network Address Translation / Firewall NCC Network Control Center NDIS Network Driver Interface Specification NFS Network File System NNTP Network and News Transfer Protocol NOC Network Operations Center NS Network Simulator NSP Network Service Provider NTSC National Television Standards Committee OBP On-Board Processor OEM Original Equipment Manufacturer OLAP On-Line Analytical Processing

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

22 / 247

OSPF Open Shortest Path First OSS Operations Support System OTCL Object-oriented TCL PAL Phase Alternating Line PAMS Perceptual Analysis Measuring System PAT Program Association Table PAWS Protection Against Wraparound Sequence numbers PC Personal Computer PCM Pulse Code Modulation PCR Program Clock Reference PCR Peak Cell Rate PDF Portable Document Format PDNS Parallel Distributed Network Simulator PEP Performance enhancement Proxy PES Packetized Elementary Stream PESQ Perceptual Evaluation of Speech Quality PHB Per Hop Behaviour PID Packet Identifier PIM-DM Protocol Independent Multicast – Dense Mode PIM-SM Protocol Independent Multicast – Sparse Mode PKI Public Key Infrastructure PMT Program Map Table PNG Portable Network Graphics POP Point Of Presence POP3 Post Office Protocol version 3 POTS Plain Old Telephone Service PPP Point to Point Protocol PPPoE Point to Point Protocol over Ethernet PRI Primary Rate Interface PSI Program Specific Information PSMQ+ Perceptual Subjective Mean Quality PSTN Public Switched Telephone Network PTS Packets Transmitted per Second PTS Presentation Time Stamps QCIF Quarter-Common Intermediate Format QoS Quality of Service QT QuickTime RAID Redundant Array of Inexpensive Disks RAMA Route Addressed Multicast Architecture RCST Return Channel Satellite Terminal RM Real Media RME Resource Management Essentials RMP Reliable Multicast Protocol RP Rendez-vous Point RPF Reverse Path Forwarding

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

23 / 247

RSGW Return channel Satellite Gateway RSVP Resource Reservation Protocol RTCP RTP Control Protocol RTP Real Time Protocol RTSP Real Time Streaming Protocol SACK Selective Acknowledgement SAP Session Announcement Protocol SCCP Simple Control Conference Protocol SCPS-TS Space Communications Protocol Standard – Transport Protocol SCR Sustained Cell Rate SCR Source Clock Reference SCSI Small Computer System Interface SDI Serial Digital Interface SDP Session Description Protocol SDR Session Directory Tool SDSP Software Download Service Provider SDTV Standard Definition Television SECAM Sequential Colour with Memory SECBR Severely Errored Cell Block Rate SGML Standard Generalized Markup Language SIF Standard Interchange Format SIP Session Initiation Protocol SL Sync Layer SLA Service Level Agreements SLO Service Level Objective SMATV Satellite Master Antenna Television SMTP Simple Mail Transport Protocol SNACK Selective Negative Acknowledgement SNMP Simple Network Management Protocol SNO Satellite Network Operator SNR Signal to Noise Ratio SOC Service Operation Center SP Service Provider SPTS Single Program Transport Stream SS7 Signalling System number 7 SSF Scalable Simulator Framework SSH Secure Shell SSL Secure Socket Layer SSM Source Specific Multicast STB Set-Top Box SubQCIF Sub-Quarter-Common Intermediate Format SW Software TCL Tool Command Language TCP Transmission Control Protocol TCR Telemetry, Command and Ranging

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

24 / 247

TDMA Time-Domain Multiple Access TIPHON Telecom and Internet Protocol Harmonization Over Networks TLS Transport Layer Security TML Test Model Long-term TOS Type of Service TS Transport Stream TTL Time To Live TV Television UA User Agent UAS User Agent Server UBR Unspecified Bit Rate UDP User Datagram Protocol UML Unified Markup Language UMP Unreliable Multicast Protocol UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifiers URL Uniform Resource Locators UT User Terminal UTRAN UMTS Terrestrial Radio Access Network VAS Validation Server VBR Variable Bit Rate VCD Video Compact Disk VCEG Video Coding Experts Group VCL Video Coding Layer VLD Variable Length Decoding VOD Video On Demand VoIP Voice over IP VOP Visual Object Plane VPN Virtual Private Network VPN-SP Virtual Private Network Service Provider VR Virtual Reality VSN Virtual Satellite Network VSP Video Service Provider WAN Wide Area Network WAV Windows wave WMV Windows Media Video WWW World Wide Web XML Extensible Markup Language XSL Extensible Stylesheet Language

2.5 ACTORS AND ROLES In the following chapters will be used a group of actors and roles to define some specific part of the SATLIFE system. The role defines only a set of processes implying management functions. The real

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

25 / 247

entities, which take in charge one role or more, are named actors. For example, a company is an actor, which can cumulate more than one role (Satellite Network Operator and INAP, etc.). The different roles identified in the whole network business interacting with the SATLIFE system are:

• Satellite Network Operator (SNO): owns and is responsible for maintaining, managing, deploying and operating the SATLIFE system excluding terminals (RCSTs & RSGW’s). It is responsible for the global traffic and the Satellite Network management functions in term of health and performances. It manages the partitioning of the resources between INAP according to their contract.

• AMAZONAS Satellite Operator: owns and is responsible for maintaining, managing, deploying and operating the AMAZONAS Satellite. It exchanges with the SNO the OBP configuration and status data.

• Interactive Network Access Provider (INAP): provides Virtual Satellite Networks (VSNs) to the service providers and star and mesh connections to subscribers. One subscriber is linked with one and only one INAP. The INAP allows subscribers to benefit from services offered by Service Providers. It is responsible for the sharing of its resources between VSNs It manages and controls physical resources and RCSTs.

• Service Providers (SP): give access to a wide range of services involving terrestrial networks or not. They book capacity (one or several VSNs) to the INAP and offer services to the SATLIFE subscribers. There are several types of services providers classified into two groups:

o Network Service Providers (NSP): included in NSP are Internet Service Providers (ISPs), Multicast Service Providers (MSPs), Telephony companies (Telcos), and VPN Service providers (VPN-SP). It is assumed that the MSP is linked to one ISP.

o Application Service Providers (ASP): provides application services to the application subscriber (video, content on demand, games, etc); included in ASP are VoD Service Providers, Internet Telephony Service Provider (ITSP), MultiConference Service Providers (MCSP), E-learning Service Providers (ESP), Digital TV Service Provider (DTSP) and Software Download Service Provider (SDSP). DTSP could be composed by other types of services providers as Video Service (VSP), audio (AuSP) or interactive applications (IASP)

• Subscribers: use the Interactive Services provided by the INAP. It has a contract with ISP for the provision of services. It also delegates service usage to end-users. The subscriber hosts one or more user terminals (UT) and has access to the Satellite Network. Contracts between subscribers and their ISP are out of scope.

• User (or end-user): can connect directly or via a Local Area Network its own user terminal (UT) to a return channel satellite terminal (RCST); several users can share the same RCST (mainly in case of professional usage). The end user UT is connected to applications provided by ISP (broadband services). The LAN plus all UTs connected to a RCST is referred as Customer Premises Equipment (CPE).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

26 / 247

Figure 1. Relationship between roles

Cardinalities are indicated with numbers near relationships. Depending on business organization and market, some roles can be located in the same companies. The SNO offers a part of its Network to INAP. The INAPs are then linked to the SNO by a contract specifying the characteristics of the INAP services that they are allowed to use. The INAP partitions its Interactive Network into Virtual Satellite Networks (VSN) and sell them VSNs to the service providers. Each VSN is assigned a given pool of resources for its exclusive use. There is no interconnection between two different VSN. The service providers sell services to the subscribers according to a Service Level Agreement (SLA). The Subscribers can then use or delegate the usage of the subscribed services to users. DTSPs could provide several types of broadcast services to subscribers as video, audio and interactive applications.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

27 / 247

3. AMERHIS/IBIS SERVICE ENHANCEMENTS As has been previously stated, the SATLIFE project builds on the results of the AMERHIS/IBIS project. In the latter, some proposed services were considered and defined. These were summarily depicted, considering general characteristics. In this chapter, we will further explore these definitions, in order to reach a requirement list suitable to develop applications. This includes several enhancements from the initial AMERHIS/IBIS proposal, which will be thoroughly explained. The services where enhancements are analysed include: -Digital TV. This is the most classic satellite service, and also interactive TV applications will be taken into account, which will benefit from the new regenerative approach which significantly improves QoS. -Multiconference. This service considers both videoconferencing and VoIP, from a multi-user point of view. -Internet access. Satellite Internet access will benefit from the regenerative approach too. -LAN interconnection. Very similar to Internet access, LAN interconnection proves suitable for SATLIFE. -Multicast. General multicast service, upon which several applications may be built. “Mesh” and “star” topologies –considering users inside or outside the satellite network-, as proposed in AMERHIS/IBIS, will be further developed. For all services, we will characterize their traffic profile providing the following parameters (traffic descriptor of the ITU approach, see annex G):

• Bandwidth: The range of bandwidth requirements. In some cases this parameter is only a simple range that represents the possible values of the PCR; in other case, a complete characterization of the PCR/SCR/MCR is provided.

• Burstiness: this characteristic may be provided with several levels of detail. The most detailed way to specify the Burstiness of the traffic is the MBS; an alternative measure of Burstiness is the ratio between peak rate and average rate (PCR and SCR, respectively). In the cases where this ratio is not available, the peak characteristic is provided.

• Symmetry: reflects the relation between information flows (symmetrical or asymmetrical), usually between service/application provider and user.

• Topology may be: § One-to-one: interaction between two points, usually with symmetrical information

flows e.g. telephone call, videophone. § One-to-many point to point: interaction between one source of information and

multiple destinations in a point-to-point communication. Usually the information flows are asymmetrical and primary one-way e.g. video server, LAN TV.

§ One-to-many multicast: interaction between one information source and multiple destinations in a multicast. The information flows are generally asymmetrical and

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

28 / 247

primary one way, e.g. scheduled audio/video broadcast, push services, cache services.

§ Many-to-many: interaction between many source of information and many destinations. Information flows would be symmetrical and asymmetrical in a basic two-way communication. In this case, the support of multicast service is desirable.

Also, for each service we will characterise the QoS requirements:

• Delay tolerance (CTD, see annex G.1): maximum elapsed time permitted for a packet to be passed from the sender, through the network, to the receiver in order to keep the service at an acceptable level. Setup time (Service access time) and data transfer delay requirements may both be provided. For interactive services, the most significant delay is the response time.

• Jitter tolerance (CDV, see annex G.1): maximum variation permitted in end-to-end transit delay in order to maintain the service at an acceptable level.

• Loss tolerance (CLR, see annex G.1): maximum loss permitted (bits, packets or cell) to keep the service at an acceptable level. The units may be Bit Error Rate, or Packet/cell error rate.

For applications and services running over window-based transport protocols (like TCP), the delay tolerance parameter may affect performance, as window protocols are very sensitive to the bandwidth-delay product, as indicated in annex section G.4. These applications will continue to work in environments where the delay parameter is high, but the performance will not be good unless the solutions outlined in annex section G.4 are taken into account. Besides these parameters, some other criteria have been used to completely characterise the service/application:

• Protocols: The main protocols involved. • Type of user: The users community to which the service is oriented (Home or normal user,

Corporate user). • Security level: there are three levels in this criterion (required, not required and optional), e.g. e-

commerce billing transactions must have the “ required” security level.

3.1 DIGITAL TV One of the main uses of satellite networks nowadays is the provision of Digital TV Services. Audio, video and data are broadcasted to final users by satellite in a one-way communication, but two-way communication is needed for interactive applications. In this section we will analyze this kind of services, both in transparent and regenerative mode.

3.1.1 General system character ization/QoS parameters

STLF-210-REQ DTV-10. Bandwidth

Bandwidth depends on the quality selected, but 2 to 5 Mbps are a typical range.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

29 / 247

STLF-210-REQ DTV-20. Burstiness

This service is not burst-oriented, it is a continuous stream.

STLF-210-REQ DTV-30. Symmetry

This service is asymmetric and mainly one-way.

STLF-210-REQ DTV-40. Topology

The topology is one-to-many.

STLF-210-REQ DTV-50. Delay tolerance

Maximum delay is not specified for this service, although it should be kept as low as possible in order to not affect the jitter.

STLF-210-REQ DTV-60. Jitter tolerance

Jitter shall be as low as necessary in order to meet the requirement that the PCR accuracy is kept into a +/-500ns range.

STLF-210-REQ DTV-70. Loss tolerance

Loss tolerance shall be zero.

STLF-210-REQ DTV-80. Type of user

Typical type of user is home and corporate.

STLF-210-REQ DTV-90. Secur ity needed

Security should be provided for this service, but no Conditional Access procedures are going to be developed in SATLIFE, as this is out of the scope of the project.

3.1.2 Requirements For Remote Audio/Video Contr ibutions

3.1.2.1 Audio contribution formats

STLF-210-REQ DTV.CON.AUD-10. MPEG-2 Format

MPEG-2 audio encoding shall conform to ISO/IEC 13818-3.

STLF-210-REQ DTV.CON.AUD-20. Modes

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

30 / 247

The audio shall be encoded in one of the following modes:

• MPEG-1 single channel. • MPEG-1 dual channel • MPEG-1 joint stereo • MPEG-1 stereo

STLF-210-REQ DTV.CON.AUD-30. Compression layers

The compression layer should be one of the following: • Layer I • Layer II

STLF-210-REQ DTV.CON.AUD-40. Bitrates

The associated bit rates for audio shall be one of the following: • Layer I: 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416 or 448 kbps. • Layer II: 32, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 288, 320 or 384 kbps.

STLF-210-REQ DTV.CON.AUD-50. Sampling

The audio sampling shall be 16kHz, 32 kHz, 44,1 kHz, or 48 kHz.

3.1.2.2 Video contribution formats The following requirements indicate the main video formats for video contributions in digital TV.

STLF-210-REQ DTV.CON.VID-10. MPEG-2 format

MPEG-2 video encoding shall conform to ISO/IEC 13818-2.

STLF-210-REQ DTV.CON.VID-20. MPEG-2 SDTV profile

Video compressed in MPEG-2 Main Profile at Main Level for SDTV.

STLF-210-REQ DTV.CON.VID-30. MPEG-2 HDTV profile

Video compressed in MPEG-2 Main Profile at High Level for HDTV.

STLF-210-REQ DTV.CON.VID-40. MPEG-4 format

MPEG-4 video encoding shall conform to ISO/IEC 14496-2.

STLF-210-REQ DTV.CON.VID-50. MPEG-4 profiles

The MPEG-4 video shall be encoded in one of the following modes: • MPEG-4 Simple Profile

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

31 / 247

• MPEG-4 Advanced Simple Profile

The MPEG4 over MPEG2 syntax elements shall be implemented according to the Amendment 7 of the ISO/IEC 13818-1 standard. The stream_type field values of the PMT shall be :

- 0x10 for MPEG4 ISO/IEC 14496-2 visual in PES packets, - 0x11 for MPEG4 ISO/IEC 14496-3 audio in PES packets, - 0x12 for MPEG4 ISO/IEC 14496-1 SL-packetized stream or FlexMux stream carried in PES, - 0x13 for MPEG4 ISO/IEC 14496-1 SL-packetized stream or FlexMux stream carried in

ISO/IEC 14496 sections

STLF-210-REQ DTV.CON.VID-60. H264 format

H264/AVC video encoding shall conform to ISO/IEC 14496-10. The stream_type field value of the PMT shall be :

- 0x1B: for AVC video as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video

STLF-210-REQ DTV.CON.VID-70.WM9 format

The stream_type field value of the PMT shall be : - 0xEA: WMV9 video.

STLF-210-REQ DTV.CON.VID-80. MPEG-2 SDTV bitrates

The bit rate for MPEG-2 video for SDTV shall be between 2 and 4 Mbps.

STLF-210-REQ DTV.CON.VID-90. MPEG-2 HDTV bitrates

The bit rate for MPEG-2 video for HDTV shall be between 2 and 20 Mbps; anyway, it should be taken into account that it is very likely that SATLIFE won’ t support more than 4 or 8 Mbps in the return channel, so this will be the upper limit for HDTV applications, which are kept optional.

STLF-210-REQ DTV.CON.VID-100. MPEG-4 bitrates

The bit rate for MPEG-4 shall be up to 2 Mbps.

STLF-210-REQ DTV.CON.VID-110. H264 bitrates

The bit rate for H264/AVC shall be up to 2 Mbps.

3.1.2.3 System layer format The transmission system will be able to encapsulate audio and video streams into MPEG2/DVB Transport Streams.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

32 / 247

STLF-210-REQ DTV.CON.SYS-10. MPEG-2 format

The transmitted multiplex shall conform to ISO/IEC 13818-1. Table id value must follow below table:

Value Descr iption 0x00 program_association_section 0x01 conditional_access_section(CA_section) 0x02 TS_program_map_section 0x03 TS_description_section 0x04 ISO/IEC14496_scene_description_section 0x05 ISO/IEC14496_object_descriptor_section

0x06-0x3F ITU-T Rec. H.222.0 | ISO/IEC 13818 reserved 0x40-0xFE User private

0xFF Forbidden

Table 1. table_id assignment values

Stream type value must follow below table :

Value Descr iption 0x00 ITU-T | ISO/IEC Reserved 0x01 ISO/IEC 11172 Video 0x02 ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2

constrained parameter video stream 0x03 ISO/IEC 11172 Audio 0x04 ISO/IEC 13818-3 Audio 0x05 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections 0x06 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data 0x07 ISO/IEC 13522 MHEG 0x08 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Annex A DSM CC 0x09 ITU-T Rec. H.222.1 0x0A ISO/IEC 13818-6 type A 0x0B ISO/IEC 13818-6 type B 0x0C ISO/IEC 13818-6 type C 0x0D ISO/IEC 13818-6 type D 0x0E ISO/IEC 13818-1 auxiliary 0x0F ISO/IEC 13818-7 Audio with ADTS transport syntax 0x10 ISO/IEC 14496-2 Video 0x11 ISO/IEC 14496-3 Audio 0x12 ISO/IEC 14496 SL-packetized stream or FlexMux stream carried in PES

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

33 / 247

0x13 ISO/IEC 14496 SL-packetized stream or FlexMux stream carried in

ISO/IEC 13818-1 sections 0x14 ISO/IEC 13818-6 Synchronized Download Protocol

0x15-0x7F ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Reserved 0x80-0xFF User Private

Table 2. Stream type assignments

The tag used for the audio, video and MPEG4 descriptors must follow below table:

descriptor_tag TS PS Identification

0 n/a n/a Reserved 1 n/a n/a Reserved 2 X X video_stream_descriptor 3 X X audio_stream_descriptor 4 X X hierarchy_descriptor 5 X X registration_descriptor 6 X X data_stream_alignment_descriptor 7 X X target_background_grid_descriptor 8 X X video_window_descriptor 9 X X CA_descriptor 10 X X ISO_639_language_descriptor 11 X X system_clock_descriptor 12 X X multiplex_buffer_utilization_descriptor 13 X X copyright_descriptor 14 X maximum bitrate descriptor 15 X X private data indicator descriptor 16 X X smoothing buffer descriptor 17 X STD_descriptor 18 X X IBP descriptor

19-26 X defined in ISO/IEC 13818-6 27 X X MPEG-4_video_descriptor 28 X X MPEG-4_audio_descriptor 29 X X IOD_descriptor 30 X X FMC_descriptor 31 X SL_descriptor 32 X X OCR_ES_ID_descriptor 33 X X External_ES_ID_descriptor

34-63 n/a n/a ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Reserved

64-255 n/a n/a User Private

Table 3. Program and program element descr iptors

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

34 / 247

STLF-210-REQ DTV.CON.SYS-20. MPEG-2 transport

The transmitted multiplex shall use Transport Stream.

STLF-210-REQ DTV.CON.SYS-30. MPEG-2 PSI

Service Information shall conform to ISO/IEC 13818-1 MPEG-2 program specific information.

STLF-210-REQ DTV.CON.SYS-40. Minimum PSI

The minimum program specific information shall include in each transport stream: • One Program Association Table. • One or more Program Map Table.

STLF-210-REQ DTV.CON.SYS-50. PAT

Each digital TV service in a Transport Stream shall be included in the Program Association Table. This table shall be created manual or automatically for every transport stream.

STLF-210-REQ DTV.CON.SYS-60. PMT

Each digital TV service shall contain one Program Map Table and one or more audio and/or video streams. This PMT shall be transmitted multiplexed with the audio and/or video streams in the DVB-RCS channel.

STLF-210-REQ DTV.CON.SYS-70. PAT/PMT frequency

The bit rate of the PAT and PMT depends on the frequency with which the PAT/PMT information is transmitted in the transport stream. Although the TR 101 154 [ETS7] 4.1.7 recommends to send the PAT/PMT with a maximum time interval of 100 milliseconds between repetitions, the minimum frequency shall be a PAT/PTM packet at least every 0,5sg in order to avoid first priority errors in DVB analysers (this minimum frequency is described in TR 101 290 [ETS8] 5.2.1).

STLF-210-REQ DTV.CON.SYS-80. DVB-SI

The minimum service information shall include the following tables: • One Network Information Table. • One actual Service Description Table. • One actual present/following Event Information Table. • One Time and Date Table.

3.1.3 Requirements for audio/video reception Two scenarios are to be considered here. The first one is transparent DVB-S, which is coincident to the presently deployed architecture. This scenario is taken into account because of the actual deployment of

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

35 / 247

DVB-S uplink facilities, which needn’ t be updated. The user terminals needn’ t support IP, and are likely to be common DVB-S set-top boxes. The next figure shows a schematic representation of this scenario.

Figure 2. Transparent Digital TV scenar io

The second possibility is to uplink with DVB-RCS. In this case, the broadcasting terminal has to be updated, but not the user terminals. This doesn’ t include interactivity support, for which the user terminals have to be upgraded, but is very easy to integrate with interactivity services as we will explain later in this chapter. This implies the use of the regenerative facilities in the satellite, and the broadcasting terminal must be a RCST, as shows the following figure.

Figure 3. Regenerative Digital TV scenar io

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

36 / 247

STLF-210-REQ DTV.RX-10. Transmission

The audio/video broadcasted shall be transmitted by a DVB-RCS terminal located in any of the uplink coverages, or by a common DVB-S broadcasting station if transparent scenario is to be considered.

STLF-210-REQ DTV.RX-20. MPEG-2

The MPEG-2 audio/video over MPEG-2 TS shall be received by a standard set top box DVB-S located in any of the downlink coverages.

STLF-210-REQ DTV.RX-30. MPEG-4

The MPEG-4 video over MPEG-2 TS shall be received by the monitoring station unit located in any of the downlink coverages. This monitoring station shall perform the following activities: • Extract the MPEG-4 video from the MPEG-2 TS. • Analyze the protocol and syntax of the MPEG-4 video. • Display the MPEG-4 video. Depending on the future availability of DVB-S standard set top boxes with MPEG-4 support, the MPEG-4 audio/video over MPEG-2 TS could be received and displayed.

STLF-210-REQ DTV.RX-40. H264

The H264 video shall be received by the monitoring station unit located in any of the downlink coverages. This monitoring station shall perform the following activities: • Extract the H264 video from the MPEG-2 TS. • Analyse the protocol and syntax of the H264 video. • Display the H264 video. Depending on the future availability of DVB-S standard set top boxes with H264 support, the H264 audio/video over MPEG-2 TS could be received and displayed.

3.1.4 Requirements for interactive TV applications One of the major advantages of the digital TV transmission is the transmission of applications that are able to communicate the final users with the interactive service providers. These applications are executed on the set top box and they are programmed in a language with a specific API (Application Program Interface) that communicates with the multimedia commands (audio, video, data, etc) and with de return channel. In the DVB standard are defined the mechanisms for data transmission with DSM-CC (Digital Storage Media - Command & Control). However, the transmitted data depends on the specific API used during the application development. Nowadays there are several proprietary APIs in the market (OpenTV, Mediahighway, etc); this proprietary solutions are incompatible among them, because of this, the interactive application developed in different platforms with different APIs aren’ t interoperable. The future of the interactive applications requires a standard solution that make possible the use of an API

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

37 / 247

valid for all set top boxes. Actually, the DVB group has developed DVB-MHP (Multimedia Home Platform), this standard defines an open API based on Java. DVB-MHP defines the specification of the Multimedia Home Platform; this platform adds a technical solution for the user terminal that enables the reception and presentation of applications in a vendor, author and broadcaster neutral framework. The proposed architecture easily makes use of the existing infrastructure, adding an interactive application provider with an RCST uplinking to the satellite. User terminals have IP return support, and are connected to an RCST which can be deployed for a single building or neighborhood, using common infrastructure or SMATV structures. This also allows to keep the present set-top box park, which in general consists of DVB-S receivers with IP return channel via some terrestrial network. The next figure shows this structure.

Figure 4. Interactive TV scenar io

If we examine the scenario in depth, we can see that applications may be transmitted via the broadcast center, in an application carousel, just as has been usually done up to date, or via the RCST/Interactive applications provider. In both cases, DVB-S is used for downstream, whether it is emitted in transparent or regenerative mode, whereas in the second case the regenerative capability of the OBP is used for the upstreams. Hence, in both cases, user terminals have to support DVB-S receiving; the return channel is always via IP, and is completely independent from the forward channel. The interaction channel can be either regenerative or transparent; in the latter case, the interactive applications provider must be connected to the hub, either via a satellite link, which means an additional hop, or via a terrestrial link, or being embedded in the broadcast center. So the Interactive Applications Provider can be completely independent from the TV broadcast center, or be embedded in the same location.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

38 / 247

This architecture considers that the interactive applications provider is in the same satellite network, but it could also be out and have to be accessed via a gateway. Even if it is inside the satellite network, it may be placed on a different beam from the feeder and/or the users. These situations have to be considered.

STLF-210-REQ DTV.INT-10. Format

Interactive application shall conform to MHP defined in ETSI TS 102 812.

3.1.4.1 Broadcast channel

STLF-210-REQ DTV.INT-20. Application type

The DVB-MHP applications shall be based on Java or HTML.

STLF-210-REQ DTV.INT-30. Application encapsulation.

The files and directories that contains the application shall be encapsulated in BIOP messages that will be divided in DSM-CC sections as defined in ISO/IEC 13818-6.

STLF-210-REQ DTV.INT-40. Carousels/service relationship

A carousel DSM-CC shall be associated to a digital TV service thought the PMT.

STLF-210-REQ DTV.INT-50. Carousel/PID relationship

A carousel is associated to a single PID and a PID is associated to a single carousel.

STLF-210-REQ DTV.INT-60. Carousel/Application relationship

A carousel shall transport one or more applications.

STLF-210-REQ DTV.INT-70. Transmission

All data shall be transmitted in MPEG-2 transport stream packets as defined in ISO/IEC 13818-1.

STLF-210-REQ DTV.INT-80. Signalling

The minimum signalling information for each interactive application shall contain: • One Application Information Table as described in ETSI TS 102 812. This table shall contains the

following descriptors: • A transport_protocol_descriptor in the second descriptor loop. • A application_descriptor in the second descriptor loop. • A application_name_descriptor in the second descriptor loop. • A DVB-J or DVB-HTML_application_descriptor in the second descriptor loop. • A DVB-J or DVB-HTML_application_location_descriptor in the second descriptor loop.

• A group of descriptors in the PMT of the associated service:

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

39 / 247

• A stream_identifier_descriptor in the second descriptor loop of the PID containing the object

carousel . • A data_broadcast_descriptor in the second descriptor loop of the PID that contains the object

carousel. • A carousel_identifier_descriptor in the second descriptor loop of the PID that contains the

object carousel. • An application_signalling_descriptor in the second descriptor loop of the PID that contains the

AIT.

3.1.4.2 Interaction channel

STLF-210-REQ DTV.INT-90. Interaction channel protocols

The interaction channel shall provide the following protocols: • TCP/IP • UDP/IP • IP

3.1.4.3 Bit rates requirements

STLF-210-REQ DTV.INT-100. AIT bitrate

The minimum repetition rate for the AIT is 10 seconds, so the minimum bit rate for each AIT shall be 301 bps (188 * 16 packets to keep continuity counter without errors). However, a bit rate of 3 kbps should be enough to send a copy of the AIT per second.

STLF-210-REQ DTV.INT-110. Carousel bitrate

The bit rate for object carousels containing MHP applications shall be between 100 kbps and 2 Mbps. The bit rate depends on the type and the size of the interactive application.

STLF-210-REQ DTV.INT-120. Interaction channel bitrate

The bit rate for the interactivity channel depends on the type of the interactive application. For instance, a chess game shall require a few bits per second and a low quality videoconference on the TV shall require 200 or 300 kbps.

3.1.5 Requirements for interactive application reception

STLF-210-REQ DTV.INT.RX-10. Transmission

The interactive applications broadcasted shall be transmitted using the following methods: • Transparent mode: a DVB-S flux server located in the hub shall inject the interactive applications

carousels.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

40 / 247

• Regenerative mode: a DVB-RCS terminal located in any of the uplink coverages shall send the

interactive applications carousels.

STLF-210-REQ DTV.INT.RX-20. Set top box type

The interactive applications over MPEG-2 TS shall be received by a standard set top box DVB-S located in any of the downlink coverages. The set top box running the interactive application shall conforms to MHP defined in ETSI TS 102 812.1. The set top box shall be the same for both transparent and regenerative scenarios.

STLF-210-REQ DTV.INT.RX-30. Set top box interactive

The interactive applications that needs non-local interactivity shall require a set top box with an Ethernet link.

3.1.6 Video service provider unit requirements In the framework of the IBIS project, a Video Service provider unit has been used, which will be used in SATLIFE. The goal of the equipment is to permit broadcasting of MPEG2 video through an SP-RCST terminal.

Figure 5. IBIS video service provisioning

It also permits simultaneous encapsulation of IP data into MPEG2 TS, ensuring a powerful IP gateway feature. All combinations are possible for sources: video only, IP only, video and IP. Video source may be a file or a live transport stream. In SATLIFE, this unit will be improved unit in order to permit to broadcast H264 video through the system.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

41 / 247

Figure 6. SATLIFE video service provisioning

STLF-210-REQ DTV.VSP-10. Bitrate

The Service Provider unit itself is able to generate transport stream up to 38 Mbps, but the highest bitrate expected in SATLIFE is below 8 Mbps. Consequently, video bitrate shall be below 8 Mbps.

STLF-210-REQ DTV.VSP-20. H264 file format

It shall follow below requirements: • File containing a video component compliant with 14496-10 standard in raw byte or MPEG2

Transport Stream. • Raw byte file shall contain data in NAL units preceded by a start code prefix

(compliant with 14496-10 Annex B) • MPEG2 Transport stream file shall contain correct PSI (compliant with MPEG2 standard). At

least, a PAT which is refencing a PMT, which is itself referencing a H264 component. • Expected Rate : CBR, between 1 and 2 Mbits (will be communicated by GUI or additional file) • Frames : I, P • Progressive video (interlaced not supported) • Video component : YUV 4:2:0 • GOP every second (around each 24/25 frames) • I frame = IDR frame (Intra / Instantaneous Decoder reference) • SPS/PPS before IDR (Sequence Parameter Set / Picture Parameter Set) • Audio : Dolby AC3, MPEG Layer II, AAC (HE-AAC not supported)

STLF-210-REQ DTV.VSP-30. MPEG2 video file format

MPEG2 Transport stream file shall be compliant with MPEG2 standard. It shall contain correct PSI. At least, a PAT which is refencing a PMT, which is itself referencing a H264 component.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

42 / 247

STLF-210-REQ DTV.VSP-40. Content streaming

The IP gateway feature of the Service Provider unit permits to support IP streaming, whatever the source: MPEG4, Windows Media, Quick Time, ... The main constraint is related to the bitrate: it shall be below highest bitrate expected in SATLIFE.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

43 / 247

3.2 MULTICONFERENCE This will be one of the new SATLIFE services, to be deployed over the results of the AMERHIS and IBIS projects, and mainly based on the work done in ICEBERGS. It allows to establish multimedia communication between two or more users. It will provide the same communication capabilities than POTS with new added value services provided by the multimedia technology. This service allows to establish a real-time multimedia communication (video and audio) between users: - This service includes voice calls, from person to person, using dedicated phones compatible with the protocol used (in the case of VoIP technology, IP protocol, over IP networks). Besides there will exist the possibility of connection with other existing networks like PSTN, ISDN, GSM or UMTS. - As an extension of the voice telephony service described above there exists the possibility for one user of viewing, in addition to hearing, the other party. This service requires broad bandwidth in order to be able to transmit the big amount of data generated by the video. The scenario of typical conference services is shown next, and it is very similar to the e-learning service ones. Next figure shows such scenario where different kind of users can be involved (residential, corporate, terrestrial, etc.).

Figure 7. Typical scenar io of conference service

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

44 / 247

This model envisages the presence of both Multicast users and Unicast users, as well as MCUs for multiparty conferences. The conference model suitable for SATLIFE imposes the usage of multicast with only one satellite hop for the media flows (see C

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

45 / 247

ANNEX: ANALYSIS OF THE CONFERENCE MODELS for details). The main user cases will use the many-to-many multicast topology, taking advantage of the broadcast capability of satellite systems. The services of conference, session and policy control are typically centralized in conference servers, in coordination with AAA servers for the Authentication, Authorisation and Accounting functions. The quality of service (QoS) requirements in all real-time conference applications and services depends on the audio/video codecs and service level. This point will be taken into account in the related requirements (see section 3.2.5 Quality of Service). Besides that, the need of interconnection with legacy networks is met by Media Gateways, which should provide the required interconnection functionality. Likewise, this scheme considers two possible connection situations: in the first one, users are directly connected to the satellite network (using LANs or directly), and they might be on different satellite beams. In the second one, they are outside the Satellite Network Domain, on terrestrial networks served by different SPs (SP Network Domain). In such case they have to be accessed via the gateways (RSGW). The scenario shown for multiconference can be applied for both videoconference and VoIP services. In addition, all the requirements apply for VoIP service, except those related only to video communications, that are: - STLF-210-REQ MC.SF.SF-30. Media types - STLF-210-REQ MC.SF.CC-20. Conference application session management - STLF-210-REQ MC.IF.EQP-10. Endpoints - STLF-210-REQ MC.QOS-20. Audio-video synchrony (Lip synchronization) - STLF-210-REQ MC.QOS-40. Video movement - STLF-210-REQ MC.QOS-50. Picture resolution In the same way, if any special requirements are needed for VoIP services, they are introduced in the corresponding subsection. Next, a list of requirements will be stated, which shall be considered in SATLIFE’s support to conference services and applications in the above described scenario, and taking into account the considerations mentioned before.

3.2.1 Service Functionality Requirements

3.2.1.1 Session Control

STLF-210-REQ MC.SF.SC-10. Authentication

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

46 / 247

User authentication will be done before using the service (registration) and for call establishment. It will be based on login and password (digest method, according to RFC 3261, basic is deprecated). Additional security can be provided with IP access lists.

STLF-210-REQ MC.SF.SC-20. Author ization

The system will allow to control the services that the customer can use (access to PSTN endpoints, call blocking,…).

STLF-210-REQ MC.SF.SC-30. Authentication for conferences

For private conferences, there will be an additional authentication to join them (token for the conference). A tighter integration between the conference service and the underlying multiconference platforms would enable a single sign-on, and an integrated authentication/authorization scheme. However, the provider of the VoIP platform (for example) can be different of that of the conferencing service (see 3.2.2.2 VoIP Platform)

3.2.1.2 Service Functionality

STLF-210-REQ MC.SF.SF-10. Transparency to the user

The service should be provided with the objective (to be fulfilled as much as possible) that the end user is not aware of the utilization of an underlying satellite network (providing access or backbone connectivity)

STLF-210-REQ MC.SF.SF-20. Basic functionality

Establish a call to a single user or join a conference. Terminate a call. This service allows a multi-party conference to be established. This can happen as a result of two or more simultaneous calls merged into one conference or as a result of an initial two-party call later expanded to a conference. The limit on the number of participants in a conference is usually based on the policy of the entity hosting the N-Way Conference. There may be two different services included: - Conference by invitation: A user establishes a call (2 users) with other user. Then both of them are

able to add/invite more people to join the conference. No previous reservation of resources is needed. Similar to the N-way Conference service, but with video and audio available.

- Virtual room conference system: Another possibility is the existence of virtual rooms. A virtual room

is an address where several people can discuss together. The users will go into that virtual room when they call to that address. In the multimedia conference there could exist the possibility to have several sorts of users (optional): there can be users who cannot speak and others who can speak and hear. Previous reservation of resources is needed, at least the “ room”.

STLF-210-REQ MC.SF.SF-30. Media types

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

47 / 247

Session establishment requires actions regarding network resources (different resources will be needed if the communication is only audio than if it is audio and video). For different reasons (privacy, security, …) the mode must be agreed by all the implied parties. In general, before multimedia communication establishment, a media negotiation phase should take place, in order to determine if the communication is only audio (for example, for users without video HW), only video, or audio and video mode. If both terminals support the media types then the multimedia connection is established. One possibility could be to begin only in audio mode and, after agreement of both parties, the video mode is launched.

STLF-210-REQ MC.SF.SF-40. Typical call supplementary services

Several added-value services may be available in audio/video telephony. This (optional) services can be the following: - Incoming or outgoing blocking (white and black lists): This service allows the user or the service

provider to block unwanted incoming calls or to restrict the outgoing ones. For this purpose, white (allowed) and/or black (not allowed) lists will be created;

- Calling L ine Identification Presentation/Restr iction (CLIP/CLIR): The CLIP supplementary

service provides the called party with the possibility of receiving identification of the calling party. The CLIR supplementary service enables the calling party to prevent presentation of its number to the called party.

- Connected L ine Identification Presentation/Restr iction (COLP/COLR): The COLP

supplementary service provides the calling party with the possibility to receive identification of the connected party. The COLR supplementary service enables the connected party to prevent presentation of its ISDN number to the calling party.

- Call transfer : This service allows the served user A to transform an existing call (user A to user B)

into a new call between user B and user C selected by user A. User A may or not have a call established with user C prior to Call transfer.

- Call forwarding: This service is also known as Call Diversion and it comprises several services:

Call forwarding unconditional, Call forwarding busy, Call forwarding no reply and Call deflection. It is applied during call establishment, and it diverts an incoming call to another destination alias (e.g., telephone number, IP address, e-mail address) address.

- Call Forwarding Unconditional permits a served user to have incoming calls, which are

addressed to the served user's number, redirected to another number. - Call Forwarding Busy enables a served user to have calls, which are addressed to the served

user's number and meet busy, redirected to another number.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

48 / 247

- Call Forwarding No Reply enables a served user to have calls, which are addressed to the served

user's number and for which the connection is not established within a defined period of time, redirected to another number.

- Call Deflection permits a served user to respond to an incoming call offered by the served client

by requesting diversion of that call to another number specified in the response. This request is only allowed before the called user has answered the call.

Applications can be developed to allow the above variants of call forwarding to operate on all calls, or only on selective calls that fulfill specific programmed conditions or conditions manually entered by the user. For example, forwarding can be made dependent on various conditions such as the state of the called party, busy, no-reply, absent; the caller identification; the time of the day; the day of the week; etc. For each scenario, the user can program the forwarding of incoming calls to different destination addresses. For example, a user can program his/her client to forward all incoming calls between 8 a.m. and 5 p.m. on weekdays to his/her office phone, calls on weekends from specific Caller IDs to ring on his/her home phone, and all other calls to be forwarded to his/her voice mail. Programming of the destination address can be done locally at the home client or by remote programming via a connection to the home client. Such a rich service is not easily available in traditional telephony.

- Call hold: This service enables the served (Holding) user A to put user B (with whom user A has

an active call) into a hold condition (Held User) and subsequently to retrieve that user B again. During this hold condition, user B may be provided with music and/or video on hold. The served (Holding) user A may perform other actions while user B is being held, e.g., consult with another user C.

- Second call: This service enables the served (Holding) user A to perform a second call with another

user C while user B is held. When the call is established user A is able to switch from one user C to the other user B or to establish a conference.

- Call waiting: This service allows a served user who is busy with one or more calls to be informed

of an incoming call with an indication. The user then has the choice of accepting, rejecting, or ignoring the waiting call. The user calling the busy party is informed about the call waiting condition.

- Other services, like voicemail, call screening, call return, call ID blocking, etc.

STLF-210-REQ MC.SF.SF-50. Advanced supplementary services

The customization of services (by the user) with CPL (Call Processing Language) scripts will be an optional issue. Example: provision of advanced services through the manipulation of signalling fields (From, To,…) in the proxy server (service provider level)

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

49 / 247

3.2.1.3 Conference Control

STLF-210-REQ MC.SF.CC-10. Conference members management.

This covers the management of membership information/status of all current conference participants (invitations, joining/leaving, termination). This (optional) service allows users to see the state of presence of the contacts included in the buddy list (list of contacts). It will be also possible to signal the own presence and to modify the own state. Different kind of states can be supported: Online, Offline, Missing, etc.

STLF-210-REQ MC.SF.CC-20. Conference application session management

In this service different media sources are involved: video and/or audio. All of them should be synchronized. For this purpose, next issues must be considered: 1. Configuration of conferences. Negotiation mechanism for configuration of conferences (codecs,…). 2. Creation and termination of conferences. Creation and termination mechanism for conferences (can be protected by access control, either for administrators or customers). This can be done for scheduled conferences (normally for business) or dynamically created ones (two users that want to invite a third person and establish a conference in a more informal way). 3. Joining and leaving conferences. End users must be able to join and leave application conferences. 4. Picture mode. Typical picture modes are mosaic (continuous presence) and single picture (like voice-activated video or selection through conference control). The former imposes higher bandwidth consumption (in general any picture mode in which more than one source transmits video simultaneously, for example, for different video selection by each participant) and its support will be studied according to QoS and bandwidth requirements. Single picture mode should be supported. Mosaic mode is optional.

STLF-210-REQ MC.SF.CC-30. Conference floor management

Optional: provide capabilities for conference floor management/conduction functions (to implement access control rules for distributed application resources; i.e. it allows to formally control who is allowed to talk – or send other media data – at a given time).

STLF-210-REQ MC.SF.CC-40. Announcement of conferences

Scheduled conferences should be announced (date, time, conference ID, associated dial numbers/IP multicast address if needed,…) so that users can join them. Alternatives are through a web page (which could be automatically updated) or other specific protocols (like SAP).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

50 / 247

3.2.2 Inter face Requirements

3.2.2.1 Equipment

STLF-210-REQ MC.IF.EQP-10. Endpoints

End user terminal could be a SIP compliant PC, desktop videoconference equipment or gateways (PSTN/ISDN endpoints). About computing capacity, it is desired to avoid mixing media (audio/video) at end users terminals, so that low-end endpoints can access the service.

STLF-210-REQ MC.IF.EQP-20. Conference servers & MCUs

There are no limitations on the choice of using SW or HW platforms. SW ones usually allow more flexibility and can be open source.

STLF-210-REQ MC.IF.EQP-30. PSTN/ISDN Gateways

There are no limitations on the choice of using SW or HW platforms. Normally, gateways are HW based.

3.2.2.2 VoIP Platform

STLF-210-REQ MC.IF.VOIP-10. VoIP signalling protocol

SIP protocol will be used for the establishment and release of calls. Interworking with H.323 endpoints could be achieved with SIP/H.323 proxies.

STLF-210-REQ MC.IF.VOIP-20. VoIP server

VoIP server can be independent of the conference service and can be provided by a third party (one or more, that will be chosen by the end user). Conference service will be an value added service on top of a VoIP platform. The endpoint will enable the selection of the VoIP platform chosen by the user (by configuring the address of the proxy server). VoIP server will provide the following functionality: registration of users (all endpoints must initially register in the SIP proxy server), location of users (when an incoming call comes, based on the registration information: as opposed to the PSTN, a user is not fixed to a given location or phone device), dial plans (call by number/alias instead of IP), supplementary services (as shown in Service Functionality).

3.2.2.3 Connectivity

STLF-210-REQ MC.IF.CON-10. Network connectivity

Traffic in any of the input lines will be able to be routed to any of the output lines (full connectivity). The networks nodes shall enable the users to have access to satellite connectivity services. Such nodes are

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

51 / 247

distinguished on the basis of the offered capacity and the target functionality they are designed for (i.e. end users, providers, gateways to terrestrial backbones, and InSS) IP connectivity is required for endpoints, VoIP signalling servers and conferencing central resources (if needed)

STLF-210-REQ MC.IF.CON-20. Direct IP connectivity

Direct IP connectivity is mandatory. NAT/FW traversal imposes problems to VoIP signalling protocols. These devices are typical for corporate scenarios. Ad-hoc (optional) solutions may be optionally given for each NAT/FW configuration.

STLF-210-REQ MC.IF.CON-30. Bandwidth

The OBP should process a gross traffic capacity that supports the required bandwidth. Then, forthe uplink and downlink frequency bands, the operation in Ku Band will enable the support of high data rates traffic flows and reduced size terminals. According to QoS requirements (see also bandwidth requirement in section 3.2.5 Quality of Service and Table 5 Bandwidth for video and audio requirements), the model should minimize the required bandwidth for user access (dynamic allocation).

STLF-210-REQ MC.IF.CON-40. Legacy endpoints

Media connection through video and/or audio gateways (i.e., H.320 ISDN videoconference endpoints, PSTN phones and H.323 terminals, see 3.2.2.1 Equipment requirements). Signalling interworking: ISDN (PRI signalling) for basic connectivity. SS7 for operator interconnection.

STLF-210-REQ MC.IF.CON-50. IP routing

The satellite segment shall interwork with Internet routing protocols (also with multicast routing protocols if present in terrestrial network). The satellite network shall handle IP routing information to select the next hop. To improve QoS, it is desirable that the NOC selects the best terminal, i.e. the one that minimizes the number of routers between the landing point and target host, as landing point in the footprint area. The routing function will map the IP routing to the underlying satellite network (link layer) routing, assuming the shortest path in term of delay.

Then, being the satellite network a part of the global IP network, traffic is not required to be routed specifically through the satellite domain. So, IP routing through the satellite network is optional.

STLF-210-REQ MC.IF.CON-60. Interworking

It is mandatory that the satellite segment interworks with Internet, and other terrestrial networks (see also Legacy endpoints requirements in this section), through an interface defined at terminal level.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

52 / 247

1. Interworking type The satellite segment shall provide interworking services, for example as specified in ITU-T recommendation Y.1401 (optional). About interworking with H.323 endpoints, it could be achieved with SIP/H.323 proxies. 2. IP QoS support It is desiderable that the satellite segment interworks with Internet QoS support mechanisms, such as IntServ/RSVP or DiffServ, in order to provide end to end QoS at network level. The terminals should perform this interworking in terms of signalling and QoS support parameters mapping (optional). 3. IP application-layer control protocol For connection oriented satellite networks, the satellite segment shall interwork with IP-based application-layer control protocol, such as SIP, in order to improve the performance when users join a conference (only control plane). 4. Interworking with IP conference services of terrestrial networks is not considered, since subscribers can have all the functionality with a single provider (interworking should be done at application layer and this is not a problem specific to the satellite network, and therefore not the scope of the project).

STLF-210-REQ MC.IF.CON-70. Users Coverage

More than one geostationary satellite cluster is needed for worldwide coverage. The use of spot beams will increase the total system capacity.

However, users that want to access the service but are not geographically covered by the satellite could access to it through a satellite service provider, to which they will connect through terrestrial IP networks (like Internet).

3.2.3 Scalability and availability Requirements

3.2.3.1 Performance of the Conference Platform

Scalability of the Conference (signalling) platform is achieved using more equipment working in parallel. Conference platform does not impose limits to its services scalability .

To analyze the performance of the platform, there are several issues that must be taken into account:

- VoIP platform selected.

- Type of end-point terminals (HD/SW, analog, SIP, H.323, MGCP, etc).

- Number of phones that will be operated

- Number of external lines and of which type (analog, BRI, PRI, T1, VoIP,etc)

- Number of concurrent internal/external calls expected (example: 30%), based on Erlang tables.

- Codecs that will be employed, and consider the amount of transcoding to be done.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

53 / 247

- Features that the system shall provide (echo cancellation, voicemail, conferencing queues & call

center, recording, fax, voice menu, text-to-speech, speech recognition, etc.).

- Reliability/scalability of the system.

- Number of cascade servers.

- IP networks capabilities (speed, QoS support, protocols, resource dynamic allocation, delay, etc) as well as the impact of the satellite environment, must be taken into account.

Then, it has no sense to establish performance orientative figures now (i.e. CPS: Calls per second), until some of this parameters are fixed in the system design and development phases. These parameters could be:

- Number of call establishments per second (call arrival rate, λ).

- Number of simultaneous calls per second.

- Number of provisioned users.

- Number of users registered/connected to the system.

- Number of simultaneous users.

3.2.3.2 Scalability of the Conference Platform Scalability is related to computing capacity for audio and video mixing and switching (either user terminal which handles only one conference, see consideration on equipment requirements, or central dedicated resources with better performance if distributed/cascaded among several machines). Computing capacity in turn depends on the bandwidth of the conference (audio, low quality video or high quality video) and also the picture mode used (continuous presence, see conference control requirements, where there are more video flows to process, increases the CPU needed). Following figures are recommended to be supported:

STLF-210-REQ MC.SCA.CNF-10. Number of simultaneous users

The selected Conference Platform must been able to increase the total number of simultaneous users along all the conferencesshall using cascaded servers arquitecture. The number of simultaneous users, once the platform is selected, could be classified according to the different bit rates expected.

STLF-210-REQ MC.SCA.CNF-20. Number of simultaneous conferences

This number depends on the number of users at each conference. For instance, for a minimum of three users at each conference, the maximum number of simultaneous conferences can be obtained from the previous figures.

STLF-210-REQ MC.SCA.CNF-30. Number of users in a conference

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

54 / 247

This number is not limited by the system but by the management of the conference itself. A conference with more that 6 participants (transmitters) has not sense. Of course, the number of receivers is not limited.

STLF-210-REQ MC.SCA.CNF-40. Number of simultaneous users and satellite terminals

The following table summarises the approximate (due to the possible variation in overhead size for video) maximum number of simultaneous transmitting users for different types of satellite terminal (each with different uplink capacities, although they could be shown for other types of terminals, not being this capacities a requirement of the system) according to the quality of the video transmitted (see 3.2.5 Quality of Service for details on bandwidth consumption):

System Total bitrate (video

bitrate), [Kbps]

Max. Sim. Users SaT-A

160Kbps

Max. Sim. Users SaT-B 512Kbps

Max. Sim. Users SaT-C 2Mbps

Max. Sim. Users PrT-A 8.192Mbps

Max. Sim. Users PrT-B 32.768Mbps

Voice Only 17.2 8 26 108 439 1755 Voice Only with Silence Suppression

6 24 76 307 1258 5033

Minimun Video bitrate

33.2 (16) 4 13 55 227 909

Bussines quality

145.2 (128) 1 3 12 52 208

High quality

401.2 (384) 0 1 4 18 75

Very high quality

785.2 (768) 0 0 2 9 38

Table 4. Approximate maximum number of simultaneous transmitting users for different types of satellite terminal.

The number of maximum simultaneous users per satellite terminal depends of the system supported terminal types. Then, a minimum target will be the AMERHIS selected ones and their corresponding max. users. The number of satellite terminals supported will depend on total on-board traffic capacity and terminal capacity. We can differentiate between total population of terminals and active ones (those simultaneously capable of exchanging traffic). The OBP should process a gross traffic capacity that supports the required bandwidth; these figures will determine the number of supported terminals of each type (a minimum target will be the AMERHIS ones). The operation in Ku Band will enable the support of high data rates traffic flows and reduced size terminals.

3.2.3.3 Availability

STLF-210-REQ MC.SCA.AVL-10. Availability (uptime)

Voice services usually require carrier-grade availability: 99,9%. This applies at least for VoIP platform.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

55 / 247

STLF-210-REQ MC.SCA.AVL-20. Response time /timeouts

SIP RFC does not impose them (deregistration of endpoints, VoIP proxy server down, MCU down,…); however there is a draft that considers how to detect a failed call, dealing with session timers (draft-ietf-sip-session-timer-09.txt)

3.2.4 Administration

3.2.4.1 User installation and operation

STLF-210-REQ MC.ADM.UIO-10. User (CPE) installation

Installation of the required equipment for the users (CPE) of the service should be simplified to the maximum (both for HW and SW). That is, it does not require specialised personal at the user premises.

STLF-210-REQ MC.ADM.UIO-20. Independency of location

Initial authentication, end of session, and access to the system independent of the location

STLF-210-REQ MC.ADM.UIO-30. Administration

User administration of his personal profile/preferences should be done in a very easy way, for example through a web interface.

3.2.4.2 Administration

STLF-210-REQ MC.ADM.ADM-10. Single point of management

At least, the management of all servers of VoIP platform should be done from a single administration interface. Optional: SNMP support by the VoIP platform will enable the integration with typical management platforms.

STLF-210-REQ MC.ADM.ADM-20. Easy administration

It is desirable that provisioning of users should be done in an easy way. Also, addition of new equipment (including CPEs) and servers should be done in a single operation.

STLF-210-REQ MC.ADM.ADM-30. Independent administration

Independent administration of conference platforms (i.e. basic voice services can be provided by the VoIP platform alone,3.2.2.2 VoIP Platformrequirements).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

56 / 247

STLF-210-REQ MC.ADM.ADM-40. Statistics of use

Optional: Number of conversations, total time of conversations, average time of conversations, users currently connected, current conferences (useful in order to adjust the parameters to improve the global performance of the platform and to plan the installation of new resources).

3.2.5 Quality of Service Services management shall operate on the basis of the service category (SLA), QoS parameters and Traffic parameters. In this section, specific QoS issues for multiconference will be covered. The parameters that should be measured in order to guarantee the quality of the conference application transmission are the following, together with the limit values set by standardization bodies. Find below requirements of these QoS parameters: - Call set-up time - Bandwidth - Delay - Jitter - Packet loss - Audio-video synchrony (Lip synchronization) (* ) - Packet size - Echo control - Video movement (* ) - Picture resolution (* ) - E-Model R factor - Perceptual measurements: MOS, PESQ, PAMS, PSMQ+ - Quality measurement The requirements marked with an asterisk (* ), apply only for communications that include video. For these requirements, satellite network impact shall be taken into account if applies, at least from one end-point to the other (between satellite terminals). In order to have a better understanding, and considering that QoS impacts in the whole system only those specific multiconference requirements will be covered. For other QoS general purpose requirements, see 6.2.4 QoS assurance, 7.2.1 Requirements for system level measurement tools, E ANNEX: Methods for Measuring Speech Quality and G ANNEX: QUALITY OF SERVICE PROVISION ISSUES. For SLA, see section 6.3.1 Service Level Agreements.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

57 / 247

For SATLIFE applicable Traffic Models, see D ANNEX: DETAILED TRAFFIC MODELS. There are requirements also for Traffic Management procedures (see 7.1.1 End-to-End QoS model requirements) and for Traffic Models support (see 7.2.2 Requirements for Simulation tools).

STLF-210-REQ MC.QOS-10. Bandwidth

Approximate bandwidth required for audio (depends on codec) and video (apart from the codec, it has variable bitrate depending on luminance, movement, fps,…), including data overheads, are the following. Bandwidth of video is strictly related to video quality: - Low quality video(minimum bitrate)=33.2Kbps - Medium-high quality video=401.2 Kbps

Audio bitrate Video bitrate (Max)

Video bitrate (min)

17.2Kbps 1 384Kbps 16Kbps 1 For G.729 audio codec, which currently is the preferred one (for general systems)

[Ref: ITU-T Recommendation G.1010. End-user multimedia QoS categories. Nov 2001]

Table 5. Bandwidth for video and audio

1. CRTP Implementation on satellite terminals of CRTP is desired (optional) to reduce significantly overhead (60 bytes from IP+UDP+RTP headers, are reduced to 2-4 bytes).

STLF-210-REQ MC.QOS-20. Audio-video synchrony (L ip synchronization)

The recommended values for delay difference between speech and moving image (to preserve lip synchronisation) are: - Under 40 ms when speech arrives after moving image - Under 20 ms when speech arrives before moving image. However, 80ms can be an acceptable differences for both cases. [Ref: ETSI ETR 297 (1996): Human Factors (HF); Human Factors in Videotelephony]

STLF-210-REQ MC.QOS-30. Echo control

Audio echo control is a typical requirement for voice services, but for this project scope, it will be considered as optional.

STLF-210-REQ MC.QOS-40. Video movement

Number of frames per second (fps): no quality value is specified in standards since it depends on several factors like spatial format and image movement. It can be variable and can also be adjusted for the improvement of quality. Then, this requirement will be considered as optional.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

58 / 247

STLF-210-REQ MC.QOS-50. Picture resolution

Perceived quality is related to the screen size (CIF required for acceptable picture resolution for a 17“ screen, whereas Sub-QCIF is sufficient for a 4“ screen). Not all the codecs support all the picture formats (H.261: QCIF, CIF. H.263: Sub-QCIF, QCIF, CIF, 4CIF, and 16CIF. MPEG 1 standard format: SIF. MPEG 2 standard format: SIF, CCIR 601. MPEG-4: the live video coding part is similar to H.263). It is required at least a size of QCIF.

3.2.6 Secur ity Requirements The satellite segment should provide security services on both user and control plane. This includes: Signalling Confidentiality; Signalling Messages Origin Authentication; User Identity Privacy; Controlled Access; User Confidentiality Service. Then, from this service point of view, security provisioning is optional (it should be added on top of the system design). If end-to-end security is needed for multiparty conferencing over SATLIFE system, then it can be divided into several levels such as security requirements for conference registration, signalling messages, media (audio/video) traffic and billing messages (see 7.3.1 Billing).

STLF-210-REQ MC.SEC-10. Registration / Authentication

See also 3.2.1.1 Session Control (alternatively public key based systems could be used, which require additional external PKI infrastructure): 1. Administration Each ISP or Conference server is in charge of registration. 2. Installation SIP endpoints must have the HTTP Digest Authentication enabled in their protocol stack. 3. Performance This is a non real time operation. Therefore minimizing the delay overheads is not a critical issue. Besides that, it uses stateless challenge mechanism where the computational overhead is not large.

STLF-210-REQ MC.SEC-20. Signalling traffic

Securing conference signalling messages is optional, depending on the conference context. If there is a need to secure SIP messages, then messages authentication and encryption shall be provided at the SIP message level (application level), transport or network level. 1. Administration The SIP endpoints are in charge of their equipment. 2. Installation

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

59 / 247

The ISP should be responsible to setup the security association for example setting up TLS and IPSec software configuration. This should be installed at all SIP endpoints. 3. Performance Again this is a non real time operation, so the delay overheads are not critical.

STLF-210-REQ MC.SEC-30. Content (media) level

Securing conference media is optional, depending on the conference context. If there is a need to secure the media, then data encryption and integrity shall be provided. Also key management and re-keying mechanisms are needed due to the high volume of conferencing data (video, voice and data). 1. Key management operation This key management system should be provided either as an independent application or it should be integrated into SIP protocol for key distribution. 2. Scalability For highly interactive conferences (many-to-many), it is expected that the number of users will be small. Therefore there will be no scalability problems relating to security key management and re-keying. For large scale conferences with one or only few senders, there might be a very large number of receivers. Therefore the security key management and re-keying solution shall be scalable. 3. Administration Each owner of the MCU (if needed) is responsible for its own configuration and trust. 4. Installation The Key server could be located at one of the conference entities or independently at the ISPs site. 5. Performance Securing the real time media traffic (data privacy and or data integrity) will have an impact on the overall performance of the conference delivery system, especially if real time data volume is high. Therefore any security system must be evaluated carefully in terms of additional delay (taking into account that we cannot impose additional delay, this is very critical and limits the implementation) and packet loss. For delay and packet loss requirements, see 7.2.1 Requirements for system level measurement tools. Another performance issue is multiple video streams encryption. Due to the video high volume, the number of encrypted video streams shall be kept to minimum.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

60 / 247

3.3 INTERNET ACCESS SERVICE In this section, the most common Internet services and applications are described, from low interactivity services as file transfer to high interactivity as interactive games or from services that requires low bandwidth as chat to services that requires more bandwidth as streaming. Part of the data presented in the following services are based on the traffic models detailed in the document "System Service & System Requirements" [RD1]. Two architectural scenarios are to be considered, both of them very likely to occur. First one comprises Internet service provisioning outside of the satellite network. The platform for satellite access is DVB-S, which may be easily included in a TV broadcast center.

Figure 8. Internet access scenar io. Service provisioning outside the satellite network

Internet service provider may also be included in the satellite network, hence simplifying the structure. This architecture is the same as shall be seen for LAN interconnection in the next chapter.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

61 / 247

Figure 9. Internet access scenar io. Service provisioning inside the satellite network

First of all, we will describe some general requirements, which apply to all of the services usually provided via Internet. Most of them apply to the terminals. Afterwards, we will describe particular requirements for each of the services considered, like web browsing or e-mail.

STLF-210-REQ INT-10. NAT/NAPT support

The terminals shall support both dynamic and static NAT/NAPT address translation utilities, in order to allow the users to employ private addressing behind the terminal.

STLF-210-REQ INT-20. DHCP server in terminals

A DHCP self-configuring protocol server shall be included in the terminal, in order to allow the deployment of a self-configuring network behind the terminal.

STLF-210-REQ INT-30. MultiStation support

MultiStation configurations shall be supported by the terminal, to allow the user to create a private network behind the terminal.

STLF-210-REQ INT-40. QoS profiles

Different QoS profiles, or at least maximum bandwidth availabilities, shall be possible to configure.

STLF-210-REQ INT-50. Traffic pr ior ization

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

62 / 247

Different traffic from the same terminal shall be possible to distinguish and prioritise. For example, web browsing may have a higher priority than e-mail, or vice versa.

STLF-210-REQ INT-60. PPPoE support

PPPoE shall be supported, in order to allow different users to make use of the same RCST and be appropriately and separately billed. This way, the ISP monitors the different connections directly. For this purpose, the RCST shall allow a “bridge” mode.

3.3.1 Service requirements for Web browsing Web browsing is an asymmetrical service with primary one-way data flow (from web server to user) with many-to-one interaction. Many users access one web server at the same time. The protocol involved for this application is HTTP. The bandwidth required is not restricted but delay tolerance should be less than four seconds per page. The delay tolerance can be different and it depends on the web page type. In general, jitter tolerance sensitivity is not applicable in this case (no real time applications involved; real time applications as video through web pages is considered as streaming). The security level needed may be optional and it depends on the confidentiality of the information browsed, in this case, HTTPS protocol could be used. The data traffic has a bursty behaviour.

STLF-210-REQ INT.WEB-10. Bandwidth

There is no fixed bandwidth for web browsing, it is used as available. Even though, preserving a minimal bandwidth, for example 64 kbps, is strongly recommended.

STLF-210-REQ INT.WEB-20. Burstiness

The web browsing service is oriented to bursts.

STLF-210-REQ INT.WEB-30. Symmetry

The web browsing service is asymmetrical and mainly one-way.

STLF-210-REQ INT.WEB-40. Topology

The topology of web browsing is many-to-one.

STLF-210-REQ INT.WEB-50. Delay tolerance

The delay tolerance shall be less than 4 seconds per page due to being an interactive service; 4 seconds is a common upper limit in order to keep the user's perception of the service responsiveness low. This maximum delay tolerance shall be the same for transparent and regenerative scenarios.

STLF-210-REQ INT.WEB-60. Jitter tolerance

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

63 / 247

The jitter tolerance is not applicable in web browsing.

STLF-210-REQ INT.WEB-70. Loss tolerance

The loss tolerance shall be zero.

STLF-210-REQ INT.WEB-80. Protocols

The main protocols in web browsing are HTTP, HTTPS, TCP and IP.

STLF-210-REQ INT.WEB-90 .Type of user

The intended users for web browsing are home and corporate user.

STLF-210-REQ INT.WEB-100. Secur ity needed

Security is optional in web browsing but it shall be necessary in transactional services like e-commerce services. In that case HTTPS shall be used.

3.3.2 Service requirements for Chat A chat group is a group of any number of users that logs-in a system to have a typed, real-time, on-line conversation, either by all users logging into the same computer, or more commonly nowadays, in the same network. Chat groups are an asymmetrical service with many-to-many interaction (many-to-one and one-to-many because a server centralizes the service). The service focuses on home users, although it could be used by corporate users . The response time is more restricted than normal web browsing because higher level of user interaction. There is not restricted bandwidth requirement for this service. Usually, sensitivity to jitter tolerance is not applicable in this case. The data traffic has a bursty behaviour.

STLF-210-REQ INT.CHT-10. Bandwidth

There is no a fixed bandwidth for chat, it is used as available.

STLF-210-REQ INT.CHT-20. Burstiness

The chat service is oriented to bursts.

STLF-210-REQ INT.CHT-30. Symmetry

The chat service is asymmetrical and mainly one-way.

STLF-210-REQ INT.CHT-40. Topology

The topology of chat service is many-to-many (many to one and one to many).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

64 / 247

STLF-210-REQ INT.CHT-50. Delay tolerance

The delay tolerance shall be less than 4 seconds; 4 seconds is a common upper limit in order to keep the user's perception of the service responsiveness low. This maximum delay tolerance shall be the same for transparent and regenerative scenarios.

STLF-210-REQ INT.CHT-60. Jitter tolerance

The jitter tolerance is not applicable in chat.

STLF-210-REQ INT.CHT-70. Loss tolerance


STLF-210-REQ INT.CHT-80. Protocols

The main protocol used in chat service is IRC over TCP/IP.

STLF-210-REQ INT.CHT-90. Type of user

The intended users for chat service is home and corporate users.

STLF-210-REQ INT.CHT-100. Secur ity needed

Security to prevent eavesdropping is optional in chat.

3.3.3 Service requirements for Server Access Access server services consists to allow remote users to connect and establish temporary connections to a network server. Usually, general purpose computers, running Windows or Unix be equipped with software that provides this service. Alternately, dedicated hardware can be used for the same task. Server access, such as telnet application, has asymmetrical data flows. Usually, users receive more data than they send. The services focus on home and corporate users. The required bandwidth can be as low as 8 kbps and due to the natural interactivity of the service delay tolerance should be less than 350 ms. The service has not delay variation sensitivity and the security level can be optional. The traffic has a bursty behaviour.

STLF-210-REQ INT.ACC-10. Bandwidth

The required bandwidth can be as low as 8 kbps and due to the natural interactivity.

STLF-210-REQ INT.ACC-20. Burstiness

The service is oriented to bursts.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

65 / 247

STLF-210-REQ INT.ACC-30. Symmetry

The service is asymmetrical and mainly one-way.

STLF-210-REQ INT.ACC-40. Topology

The topology of this service is many-to-one.

STLF-210-REQ INT.ACC-50. Delay tolerance

The delay tolerance shall be less than 350 ms in a regenerative scenario and less than 700 ms in a transparent scenario.

STLF-210-REQ INT.ACC-60. Jitter tolerance

The jitter tolerance is not applicable in this service.

STLF-210-REQ INT.ACC-70. Loss tolerance


STLF-210-REQ INT.ACC-80. Protocols

The main protocols used in this service are TELNET, SSH and SLOGIN over TCP/IP.

STLF-210-REQ INT.ACC-90. Type of user

The intended users for this service are home and corporate user.

STLF-210-REQ INT.ACC-100. Secur ity needed

Security is optional in this service.

3.3.4 Service requirements for Streaming Streaming video and audio consists on the transmission of audio and video contents to final users that are able to display it, without requiring these users to wait for the entire file to be downloaded. Streaming audio and video services have asymmetrical primary one-way data flows. Usually, the interactive characteristic in both cases is one-to-many multicast; even though it could be one-to-many multipoint. These services are focused on home users as well as corporate users. The loss tolerance should be less than 1% FER (Frame Error Rate). The bandwidth requirement for streaming audio depends on the audio codec used. The bandwidth requirement for streaming video also depends on the video codec used.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

66 / 247

As streaming does not involve active interaction, delay tolerance is much less stringent than for conversational services. Jitter could be an issue, as adequate presentation at the receiver requires timely frame processing. But usually any jitter introduced by the network can be compensated by buffering frames in the receiver. These dejittering buffers contribute to the overall delay, but delay is not a critical issue in streaming services, so this is not a problem. In general, services requirements for both services depend on the level of service required ranging from best effort to high quality streaming audio/video service.

STLF-210-REQ INT.STR-10. Bandwidth

The required bandwidth for audio streaming is 16 to 256 kbps. These data rates include the common rates of different audio compression technologies. The required bandwidth for video streaming is 16 kbps to 4 Mbps. These data rates include the common rates of different video compression technologies.

STLF-210-REQ INT.STR-20. Burstiness


STLF-210-REQ INT.STR-30. Symmetry


STLF-210-REQ INT.STR-40. Topology

The topology is many-to-one for audio and video streaming.

STLF-210-REQ INT.STR-50. Delay tolerance

The delay tolerance shall be less than 10 seconds for audio and video streaming. This maximum delay tolerance shall be the same for transparent and regenerative scenarios.

STLF-210-REQ INT.STR-60. Jitter tolerance

The jitter tolerance is avoided using audio and video buffers.

STLF-210-REQ INT.STR-70. Loss tolerance

The loss tolerance shall less than 1% Frame Error Rate.

STLF-210-REQ INT.STR-80. Protocols

The main protocols used in audio and video streaming are MPEG, Windows Media, Real Media over UDP/IP or TCP/IP.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

67 / 247

STLF-210-REQ INT.STR-90. Type of user


STLF-210-REQ INT.STR-100. Secur ity needed


3.3.5 Service requirements for File Transfer File transfer service provides any user copying a file from a computer to another over a computer network. The type of the file could be ASCII or binary. File transfer is an asymmetrical service with primary one-way data flow. Usually, many home and corporate users access a file server in a many-to-one multipoint manner. The bandwidth requirements generally range from 14 kbps to 1.5 Mbps and it depends on the file server type. The network delay may degrade the throughput because the TCP problem described in 4.5. The security level needed depends on the information’s confidentiality. The data traffic may have a bursty behaviour depending on the TCP parameters.

STLF-210-REQ INT.FTP-10. Bandwidth

The required bandwidth can be as low as 14 kbps or as high as some Mbps.

STLF-210-REQ INT.FTP-20. Burstiness


STLF-210-REQ INT.FTP-30. Symmetry


STLF-210-REQ INT.FTP-40. Topology

The topology of this service is many-to-one.

STLF-210-REQ INT.FTP-50. Delay tolerance

The delay tolerance is not applicable in this service.

STLF-210-REQ INT.FTP-60. Jitter tolerance


STLF-210-REQ INT.FTP-70. Loss tolerance

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

68 / 247


STLF-210-REQ INT.FTP-80. Protocols

The main protocol used in this service is FTP over TCP/IP.

STLF-210-REQ INT.FTP-90. Type of user


STLF-210-REQ INT.FTP-100. Secur ity needed


3.3.6 Service requirements for Email Email service is a system that allows world-wide electronic communications in which a computer user can compose a message at one terminal that is generated at the recipient's terminal when he logs in. Electronic mail could be symmetrical or asymmetrical service. The users can receive and send the same amount of electronic messages or vice versa. Companies can use email service as a way to push information directly to the user. For this reason user can receive much more electronic messages than he sends. The service interaction can be one-to-one (mailing to one person) or one-to-many (mailing to a list). Usually, the user do not wait any time when sending an e-mail and the jitter tolerance is not applicable. There is not a specific bandwidth requirement for this service and the data traffic has a bursty behaviour.

STLF-210-REQ INT.EML-10. Bandwidth

There is no a fixed bandwidth for this service, it is used as available. However, a minimum fixed bandwidth is recommended, which may be around 64 kbps.

STLF-210-REQ INT.EML-20. Burstiness


STLF-210-REQ INT.EML-30. Symmetry

The service could be symmetrical and asymmetrical. Mainly is one-way.

STLF-210-REQ INT.EML-40. Topology

The topology of this service could be one-to-one or one-to-many.

STLF-210-REQ INT.EML-50. Delay tolerance

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

69 / 247


STLF-210-REQ INT.EML-60. Jitter tolerance


STLF-210-REQ INT.EML-70. Loss tolerance


STLF-210-REQ INT.EML-80. Protocols

The main protocols used in this service are SMTP, ESMTP, POP3, IMAP over TCP/IP.

STLF-210-REQ INT.EML-90. Type of user


STLF-210-REQ INT.EML-100. Secur ity needed


3.3.7 Service requirements for Newsgroup Usenet is an online system that provides services to distributed discussion forums through Internet. Usenet groups can be ‘unmoderated’ (anyone can post) or `moderated' (submissions are automatically directed to a moderator, who edits or filters and then posts the results). Some newsgroups have parallel mailing lists for Internet people with no Netnews access, with postings to the group automatically propagated to the list and vice versa. Some moderated groups (especially those which are actually gatewayed Internet mailing lists) are distributed as `digests', with groups of postings periodically collected into a single large posting with an index. Newsgroup service is an asymmetrical service. The users can receive more information that they send by electronic messages. Companies can use newsgroup but this service is more intended to normal or home users. The service interaction is one-to-many (mailing to a newsgroup). Usually, the user do not wait any time when sending a post and the jitter tolerance is not applicable. There is not a specific bandwidth requirement for this service and the data traffic has a bursty behaviour.

STLF-210-REQ INT.NWS-10. Bandwidth

There is no a fixed bandwidth for this service, it is used as available. However, a minimum fixed bandwidth may be considered, around 64 kbps.

STLF-210-REQ INT.NWS-20. Burstiness

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

70 / 247


STLF-210-REQ INT.NWS-30. Symmetry

The service is asymmetrical. Mainly is one-way.

STLF-210-REQ INT.NWS-40. Topology

The topology of this service is one-to-many.

STLF-210-REQ INT.NWS-50. Delay tolerance


STLF-210-REQ INT.NWS-60. Jitter tolerance


STLF-210-REQ INT.NWS-70. Loss tolerance


STLF-210-REQ INT.NWS-80. Protocols

The main protocols used in this service is NNTP over TCP/IP.

STLF-210-REQ INT.NWS-90. Type of user

The intended user for this service is home user.

STLF-210-REQ INT.NWS-100. Secur ity needed


3.3.8 Service requirements for Interactive Games Interactive game applications usually have symmetrical flows of information with many-to-many interaction (many-to-one and one-to-many because a server centralizes the service). The service is focused on home users with low bandwidth access (e.g. 8 kbps) but it depends on the game interaction. Delay and jitter tolerances also depend of the type of game and its interaction level. The security level is optional and the data traffic has a bursty behaviour.

STLF-210-REQ INT.GAM-10. Bandwidth

The required bandwidth for games goes from 8 kbps (in strategy or board games) to 128 kbps (used in very intensive interactive games as shoot-em-up).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

71 / 247

STLF-210-REQ INT.GAM-20. Burstiness


STLF-210-REQ INT.GAM-30. Symmetry

The service is symmetrical.

STLF-210-REQ INT.GAM-40. Topology

The topology of this service is many-to-many (many-to-one and one-to-many because a server centralizes the service).

STLF-210-REQ INT.GAM-50. Delay tolerance

The delay tolerance depends on the specific game.

STLF-210-REQ INT.GAM-60. Jitter tolerance

The jitter tolerance depends on the specific game.

STLF-210-REQ INT.GAM-70. Loss tolerance


STLF-210-REQ INT.GAM-80. Protocols

The main protocols used in this service are TCP/IP and UDP/IP.

STLF-210-REQ INT.GAM-90. Type of user

The intended user for this service is home user.

STLF-210-REQ INT.GAM-100. Secur ity needed


3.3.9 Service requirements for Messenger MSN Messenger Service enables a user to learn about the presence of other people on the Internet, and to communicate with them in real-time. This functionality is commonly referred to as Instant Messaging. Among the core services that the MSN Messenger Servers provide to clients are: • Authenticated user logon. • Adding and deleting members of the user's contact list.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

72 / 247

• Changing the user's on-line state. • Receipt of asynchronous, real-time, on-line state change notifications from members of the user's

contact list. • Delivering lightweight, real-time messages to other users. • Receipt of asynchronous, real-time messages from other users. • Configuring the user's access permissions, to restrict the ability of other users to view the user's on-

line state or send messages to the user. Messenger Service is a symmetrical service with many-to-many interaction (many-to-one and one-to-many because a server centralizes the service). The service is focused on home and corporate users with low bandwidth access. The response time is more restricted than normal web browsing because higher level of user interaction. Usually, sensitivity to jitter tolerance is not applicable in this case. The data traffic has a bursty behaviour.

STLF-210-REQ INT.MSN-10. Bandwidth

There is no a fixed bandwidth for chat, it is used as available.

STLF-210-REQ INT.MSN-20. Burstiness


STLF-210-REQ INT.MSN-30. Symmetry

The service is symmetrical.

STLF-210-REQ INT.MSN-40. Topology

The topology of this service is many-to-many (many-to-one and one-to-many because a server centralizes the service).

STLF-210-REQ INT.MSN-50. Delay tolerance


STLF-210-REQ INT.MSN-60. Jitter tolerance


STLF-210-REQ INT.MSN-70. Loss tolerance


STLF-210-REQ INT.MSN-80. Protocols

The main protocols used in this service are MSNP8, MSNP9 and MSNP10 over TCP/IP.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

73 / 247

STLF-210-REQ INT.MSN-90. Type of user


STLF-210-REQ INT.MSN-100. Secur ity needed


SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

74 / 247

3.4 LAN INTERCONNECTION SERVICE A Local Area Network (LAN) is a network usually within a single building that links computers with each other and with peripherals such as servers and printers. The interconnection is the association of two different services. LAN interconnection via satellite can be used to complement and extend existing terrestrial networks through interconnection of clusters of broadband islands (such as LANs and MANs) in remote regions, where terrestrial lines are expensive to install and operate. Satellite interconnected or hybrid satellite-terrestrial LANs have certain advantages over terrestrially connected LANs. A satellite can be used to interconnect LANs located in remote areas, and in a hybrid situation can be used for large data-file transfers, so this interconnection could avoid over-burdening the terrestrial networks. Next, we will state a brief architecture summary for this service. In this service, we can identify two types of corporate facilities: Central Facility and Client Facility. All the application servers are located in the Central Facility, including Internet access proxy/firewall, Web and E-mail server. Ther could be several Client Facilities accessing the different servers through their RCSTs. The general scheme of this architecture is depicted in the following figure.

Figure 10. LAN interconnection scenar io

As can be seen, the corporate servers have a separate Internet connection, independent from RCS platform. Otherwise, the ISP traffic has to be added. This scheme only considers the scenario where all LANs are directly connected to the satellite network. In fact, several architecture possibilities have to be checked. First, even if they are directly connected to the satellite network, they could be on different beams. But they can also be outside the network, on a

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

75 / 247

terrestrial network, and have to be accessed via the gateways. This implies additional requirements for the gateway equipment.

STLF-210-REQ LAN-10. Dynamic Bandwidth

In order to utilize the costly satellite bandwidth optimally, it shall be tested some bandwidth allocation algorithms which will aim to minimize both the bandwidth used and the network congestion. These algorithms will observe the incoming traffic and accordingly adjust the satellite bandwidth by sending out bandwidth addition/deletion requests to the satellite.

STLF-210-REQ LAN-20. Type of service

The system shall offers at least the following interconnection services: • VBR interconnection service: Variable Bit Rate service enables the support of applications that do not

require any timing relation between source and destination. The packets are sent to the satellite sub-network according to the scheduling mechanism and transferred to the receiver isochronously.

• CBR interconnection service: Constant Bit Rate service enables the supports of applications for which timing relation between source and destination is required.

• ABR interconnection service: Available Bit Rate service enables the support of applications that do not require any timing relation between source and destination and doesn’ t require any specific bit rate.

STLF-210-REQ LAN-30. Type of flows

The system shall supports unicast and multicast traffic.

STLF-210-REQ LAN-40. IP addresses

The system shall provide the full range of the private IP addresses. That is, any subscriptor of the LAN interconnection service shall have a complete isolation from any other subscriptor that use private IP address in his addressing plan.

STLF-210-REQ LAN-50. Internet access

The system shall provide Internet access to the subscriber that requests it.

STLF-210-REQ LAN-60. Intranet access

The system shall provide Intranet access to the subscriber that requests it.

STLF-210-REQ LAN-70. Lan2Lan

The system shall provide the interconnection between different LANs with a single satellite hop. That is, it won’ t be needed to reach a central hub in order to connect two different LANs.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

76 / 247

Interconnection of local area networks is a symmetrical many-to-many service, mainly provided to corporate users. In terrestrial networks Frame Relay or other WAN services usually provide this service. Traffic characterization depends on many factors, but in most cases a bandwidth about 1-2 Mbps will do for most cases. But some LAN interconnection cases could demand much more bandwidth, up to 100 Mbps. Traffic for this service is usually characterized as Available Bit Rate (ABR) but other configurations are possible. Usually the interconnection is performed at layer 3 (IP), but interconnection could be performed at layer 2 as well. Delay should be kept low (250-350 ms), and loss rate very low, comparable to that of LANs (better than 10-9).

STLF-210-REQ LAN-80. Bandwidth

The typical bandwidth required for LAN interconnection is from 64 Kbps to 8 Mbps.

STLF-210-REQ LAN-90. Burstiness


STLF-210-REQ LAN-100. Symmetry

Interconnection of local area networks is symmetrical.

STLF-210-REQ LAN-110. Topology

The topology of this service is many-to-many.

STLF-210-REQ LAN-120. Delay tolerance

The time after a request has been placed until it goes through, is highly variable. It can vary from 300 to 400 ms in a regenerative scenario, depending on such factors as the total load on the satellite, the total number of requests coming in from all the different users, etc. The delay tolerance in a transparent scenario shall vary from 600 to 800 ms due to the double satellite hop.

STLF-210-REQ LAN-130. Jitter tolerance


STLF-210-REQ LAN-140. Loss tolerance

The loss tolerance shall be comparable to that of terrestrial LANs.

STLF-210-REQ LAN-150. Protocols

The main protocol used in this service is IP.

STLF-210-REQ LAN-160. Type of user

The intended users for this service are corporate users.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

77 / 247

STLF-210-REQ LAN-170. Secur ity needed

The security is optional in this service. In case that security would be needed at IP level, IPSEC should be used. It should be noted that the requirements previously stated considered an IP-level LAN interconnection. However, sometimes it is appropriate to allow link-level interconnection, which permits a broader spectrum of applications and utilities. For instance, the NetBios protocol may be used, and subnetting is more natural, as all of the terminals are part of the same subnet, even if they are behind different RCSTs.

STLF-210-REQ LAN-180. L ink-level interconnection

Link-level interconnection possibilities are highly recommended. For this purpose, RCSTs should support “bridge” mode.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

78 / 247

3.5 MULTICAST SERVICE Multicast is a service which implies that a data packet can be delivered to a group of different receivers. The most common protocol to enable multicast transmission is IP. IP multicast is often described as the transmission of an IP datagram to a host group, a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same best-effort reliability as regular unicast IP datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time. For a reference of protocols, including routing and net mapping protocols, and general concepts about IP multicast, annex F should be a compulsive reading. RFC 1458 is also a document which provides background to implement IP multicast. Due to the simple interconnection of elements in the satellite network, scalability is not a problem, and many requirements that are often stated for multicast networking won’ t be considered. When QoS issues are to be considered for multicast applications, UDP should be used in the transport layer. Multicast can be used in many forms and for different servicing paradigms, and it is particularly interesting for distributed applications, multiconferencing, interactive gaming, etc. We have stated before some requirements in the description of particular services which use multicast; now, we will see an overall multicast requirement definition. Three architectural scenarios may be considered, one of them being “star” multicast, the second one being “mesh” multicast, and a final one which combines properties from both of them. The main difference between them is the involvement of a RSGW in the first one, because the multicast source is outside the satellite network; in the mesh setup, the multicast server is a RSCT receiving an IP stream, which is multicasted to several users. The third case also implies the use of an RGSW, but the source is inside the satellite. This last scenario and it would also allow the users to form their own multicast groups.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

79 / 247

Figure 11. Mesh multicast scenar io

The figure above shows the “mesh” multicast scenario. As can be seen, downlink is DVB-S, inside of which IP is encapsulated.

Figure 12. Star multicast scenar io

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

80 / 247

The figure above is the “star” multicast scenario, in which the RSGW links to an external multicast source. Another case is that in which the multicast source is inside the satellite network, but multicast terminals are either inside or outside the network. In fact, this is similar to the star configuration, but implies that the gateway must support multicast bidirectionally. The figure below displays this case.

Figure 13. Multicast scenar io with multicast terminal users outside of the satellite network

We will state a list of requirements which shall be considered in SATLIFE’s support to multicast service.

STLF-210-REQ MCS-10. Reserved IP addresses

Setting up a multicast group first requires assigning a multicast group address. All multicast traffic is then delivered to this address, which implies that all members of the group must be listening for traffic with this address. Multicast addressing shall conform to RFC 3171.

STLF-210-REQ MCS-20. Terminal requirements

End-user terminals shall support IGMP v2.

STLF-210-REQ MCS-30. Authentication and ver ification

Some groups may require authentication or conditional access procedures to be joined by certain users.

STLF-210-REQ MCS-40. Secur ity

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

81 / 247

Security is optional, but multicast key management protocols that are being defined in the IETF Multicast Security group should be evaluated.

STLF-210-REQ MCS-50. Hosts located in external networks

Hosts may be located in external networks, which means they have to be accessed via a gateway.

STLF-210-REQ MCS-60. Tunneling and interoperability for unicast external networks

Many operating systems such as Linux have embedded multicast support , and may also be configured to act as a multicast router. But some networks won’ t support multicast, and tunneling may be required at some point, possibly at the gateway, which means that multicast datagrams are encapsulated into unicast flows.

STLF-210-REQ MCS-70. Interoperability for other multicast systems

Connecting with external networks on a multicast service basis means that some kind interoperability with other multicast implementations has to be supported, specially when routing and constructing the delivery tree.

STLF-210-REQ MCS-80. Routing protocols

An extension to standard IP routing protocols should be implemented for multicast service support (MOSPF as an extension to OSPF, BGP, etc.). Annex section F should be the reference for this extension.

STLF-210-REQ MCS-90. Net flooding and resource abuse

The system should support the delivery of high-QoS IP multicast to the mobile terminals that are members of a multicast group without significantly affecting the power consumption of those mobile terminals that are not members of that multicast group.

STLF-210-REQ MCS.QOS-10. Quality of service support

The system should support the means to enable end-to-end QoS and should support a Policy-based QoS architecture for IP multicast at all QoS levels. This could imply the use of QoS protocols like RSVP or DiffServ.

STLF-210-REQ MCS.QOS-20. Quality of service extensions for multicast

New parameters of QoS may appear when operating multicast services; for example, a maximum jitter between multicast users belonging to the same group may be defined (that is, the maximum time elapsed from the instant when the first host of the group receives a multicast datagram, to the instant when the last host of the group receives that same datagram).

STLF-210-REQ MCS.QOS-30. Trade-off between speed and quality

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

82 / 247

Within an video communication system, diversity and adaptability can be accommodated by trading quality of service (i.e., image quality) with speed of transmission. Multicast support for quality-speed trades can be realized either through the use of different multicast groups, where each group receives a different image quality, or through the use of a single hierarchical stream with routers (or users) extracting relevant portions.

STLF-210-REQ MCS.QOS-40. Reliability

Network congestion or buffer overruns result in packet loss. A full range of transport reliability is required within an image communications framework. For some applications such as image conferencing, packet loss does not present a problem as dropped mouse movements can be discarded with no meaningful degradation in utility. However, for functions such as image archiving or detailed image analysis –for example, in telemedicine-, transport must be completely reliable, where any dropped packets must be retransmitted by the sender. Additionally, several hierarchical image compression methods can provide useful, albeit degraded, imagery using a semi-reliable service, where higher level data is transmitted reliably and the lower level data is transmitted unreliably. For this purpose, protocols RMP (Reliable Multicast Protocol) and UMP (Unreliable Multicast Protocol) are to be considered.

STLF-210-REQ MCS.QOS-50. Flow control

In support of reliable transport, image communications services must also support adaptation to network congestion using flow control mechanisms. Flow control regulates the quantity of data placed on the network per unit time interval, thereby increasing network efficiency by reducing the number of dropped packets and avoiding the need for large numbers of retransmissions. As was stated before, TCP mechanisms are to be considered at this point. A definition exists also for MTP (Multicast Transport Protocol). Next, we will characterize typical QoS parameters and service descriptors.

STLF-210-REQ MCS.QOS-60. Bandwidth

Bandwidth depends on the particular contents being multicasted, and can be as low as 24 kbps.

STLF-210-REQ MCS.QOS-70. Burstiness

Burstiness is dependant on the contents multicasted.

STLF-210-REQ MCS.QOS-80. Symmetry

The service is usually asymmetric and one-way, but again this is highly dependant on the contents.

STLF-210-REQ MCS.QOS-90. Topology

The topology is one-to-many, and can be extended to many-to-many.

STLF-210-REQ MCS.QOS-100. Delay tolerance

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

83 / 247

Delay tolerance depends on the particular application.

STLF-210-REQ MCS.QOS-110. Jitter tolerance

Jitter tolerance depends on the particular application.

STLF-210-REQ MCS.QOS-120. Loss tolerance

Loss tolerance depends on the particular application.

STLF-210-REQ MCS.QOS-130. Type of user

Type of user is home and corporate.

STLF-210-REQ MCS.GRP-10. Dynamic group assignment

Multicast nodes should have the ability to link or unlink at any time to a certain multicast group.

STLF-210-REQ MCS.GRP-20. Static and dynamic groups

It is likely that we will have some well-known groups (i.e., groups which are more or less permanent in existence) and some ephemeral groups. The dynamics of group membership are likely to be different for each class of groups, and the solution should take that into account as appropriate.

STLF-210-REQ MCS.GRP-30. Group composition

As we stated before, multicast groups may be formed by zero or more hosts.

STLF-210-REQ MCS.GRP-40. Host locations

Hosts may be located in different satellite beams, which has to be considered in order to correctly manage dataflow.

STLF-210-REQ MCS.GRP-50. Hosts joining several groups

Hosts may join more than one group at a time.

STLF-210-REQ MCS.GRP-60. Group size

It is likely that there will be a number of applications that have a few members per group (e.g., medical imaging) and a number of applications that have a large number of members per group (e.g., news distribution). The system shall adequately scale for both sparse and dense group memberships simultaneously.

STLF-210-REQ MCS.GRP-70. Multicast tree branching

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

84 / 247

In the face of group membership change, there must be a facility for incremental addition or deletion of "branches" in the multicast tree. Reconstructing the tree from scratch is not likely to scale.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

85 / 247

4. NEW SERVICES AND FUNCTIONALITIES

4.1 E-LEARNING

4.1.1 Introduction There are various types of TeleEducation applications, each one having different service requirements. Two main groups can be established:

ü Real-time conversational e-learning service (Synchronous E-learning): This is similar to a multiconference service with less restrictive requirements in the interaction between the interlocutors. It is a moderated conference (teacher is the moderator) with a rigid floor control. And this floor control has looser time constraints than a normal conference.

ü Low-interactivity e-learning service (Asynchronous E-learning): In this case, the real-time constraints almost disappear because the interaction between the students and the teacher is based on no real-time interaction (e-mail, web exercises, off-line chat…).

We will analyse here the most restrictive in terms of requirements, Real-time conversational e-learning service. This kind of service usually has two asymmetrical data flows, with outbound (teacher to students) greater than inbound. The topology is many-to-many multicast taking advantage of the broadcast capability of satellite systems. The TeleEducation by satellite is basically a videoconference application with one information source and many destination sites. The quality of service requirements in all videoconference applications depends on the audio/video codecs and service level as it was explained before. TeleEducation systems can support a medium to high number of home and corporate users. The data traffic has a bursty behaviour. In general, most of the multiconferencing requirements apply. Also, the scenario for the e-learning service is similar to the multiconference scenarios. Next figure shows such scenario where different kind of users can be involved (residential, and/or corporate, and/or neighbourhood SMATV users, and/or Terrestrial users).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

86 / 247

Figure 14. E-learning scenar io

As in the case of multiconference, multiple mixers or MCUs might be necessary to:

– Optimize the required satellite resources (reduce the number of video flows) – Reduce the mixing function at the end user machine (CPU consuming). – Reduce the required end-user network access rate.

In the case of e-learning application these MCU components might be not necessary because the above mentioned floor control limits the number of simultaneous flows in the system (one teacher and a low number of interacting students in a given time). This scheme considers the scenario where users are directly connected to the satellite network (using LANs or directly), and they might be on different satellite beams. They can also be outside the Satellite Network Domain; on terrestrial networks served by different SPs (SP Network Domain). In such case they have to be accessed via the gateways (RSGW). The conference model suitable for SATLIFE (see annex C) imposes the usage of multicast with only one satellite hop for the media flows. Both “star” multicast and “mesh” multicast might be used depending on

NCC MR RSGWk

SPi Network Domain

SPi Unicast Domain SPi Multicast Domain

BR

SPi Unicast EUs

INTERNET (Rest of SPs)

SPi Multicast EUs

BR

MCU NCC-RCST

BR: Border Router

MR: Multicast Router

SP: Service Provider

EU: End User

NCC: Network Control Centre

Residential Users

Corporate/SMATV Users

MCU

EU1

EU2

EU3

EUn

RCS

E-Learning Conference Server AAA Server

Corporate Users (Central)

Legacy Networks

(PSTN/ISDN)

MGW

AAA: Authentication, Authorization and Accounting MCU: Multipoint Control Unit

DVB-RCS

DVB-S

MGW: Media GateWay

Teacher Teacher Sat. Network Domain

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

87 / 247

the involved users and the place where the teacher or teaches are located. The scenario also shows some users that might have unicast access to the network. They need some way to access the multicast lecture such as using MCUs or tunnelling techniques. Conference, session and policy control are typically centralized in a conference server that is coordinated with the AAA server for the Authentication, Authorisation and Accounting functions. The last component of the scenario highlights the need of interconnection with legacy networks. In this case Media Gateways should provide the required interconnection functionality (signalling should be also considered) with the same requirements as for conference services. We will state a list of requirements which shall be considered in SATLIFE’s support to e-learning applications in the above described scenario.

4.1.2 General requirements

STLF-210-REQ LRN-10. Transparency to the user

The service functionality should be provided with the objective that the end user is not aware of the utilization of an underlying satellite network (providing access or backbone connectivity). Note that this transparency applies only to functionality; it does not apply to the perceived QoS (see multiconference QoS requirement in section 3.2.5).

STLF-210-REQ LRN-20. Asymmetr ical traffic

Teacher media flows provides high audio/video quality using permanent (during the lecture) assigned network resources. The interaction of the students is restricted to the time interval when the interaction occurs, and the involved multimedia flows requires a lower network band width.

STLF-210-REQ LRN-30. Many-to-Many traffic topology

All the users involved in the e-learning session must receive the same flows (expect in the case of private/side conversations).

STLF-210-REQ LRN-40. Supported protocols

E-learning service may be supported on different protocols (SIP or H323, RTP, MPEGx …)

STLF-210-REQ LRN-50. Lecture member management

Management of membership information/status of all current conference participants should be possible: invitations, joining/leaving, and termination.

STLF-210-REQ LRN-60. Lecture policy control

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

88 / 247

The policy control mechanism may be based on a Web interface (instead of a CPC protocol). Lecture policy is the set of rules associated with participation in a conference. These rules include directives on the lifespan of the conference, who can and cannot join the conference, definitions of roles available in the conference and the responsibilities associated with those roles. (See internet draft “Requirements for Conference Policy control protocol” , draft-ietf-xcon-cpcp-reqs-03)

STLF-210-REQ LRN-70. Conference application session management

1. Creation and termination of conferences. Creation and termination mechanism for conferences should be provided (it may be protected by access control, either for administrators or customers). This applies to scheduled conferences (normally for business) or dynamically created ones (two users that want to invite a third person and establish a conference in a more informal way).

2. Joining and leaving conferences. End users must be able to join and leave application conferences.

3. Picture mode. Moderator (teacher) video should be always shown (with different resolutions/sizes as imposed by the rest of the lecture material). For the interacting students, typical picture modes are mosaic (continuous presence) and single picture (like voice-activated video or selection through conference control). The former imposes higher bandwidth consumption (in general any picture mode in which more than one source transmits video simultaneously), but in this e-learning case, the maximum number of simultaneous interacting students should be limited by the policy rules (typically two).

STLF-210-REQ LRN-80. Lecture floor management

Floor control is a mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive access to the shared object or resource in a conference (lecture). A floor is defined as the temporary permission for a lecture participant to access or manipulate a specific shared resource or group of resources. In the e-learning service these mechanisms are necessary. This conference scenario enables a lecturer that presents a topic and can allow questions. The lecturer needs to know who the participants are and to be able to give them the right to speak. The right to speak can be based on floor control (it can be based on out of band mechanism).In general, the lecturer will be seen/heard by the conference participants and often will share a presentation or application with the other participants.

STLF-210-REQ LRN-90. Announcement of conferences

Scheduled conferences should be announced (date, time, conference ID, associated dial numbers/IP multicast address if needed,) so that users can join them. This announcement should be provided through a web page (which may be automatically updated); or optionally, with other specific protocols (like SAP).

4.1.3 Quality of Service requirements

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

89 / 247

STLF-210-REQ LRN.QOS-10. Bandwidth and Burstiness

Audio and video traffic is typically bursty as defined in the traffic models. Typical bandwidth requirements are: Outbound: > 500 kbps Inbound : >= 64 kbps

STLF-210-REQ LRN.QOS-20. Delay tolerance (interaction)

During the user interactions, delay tolerance requirements for system level measurement tools area applied. See 7.2.1 Requirements for system level measurement tools, Delay evaluation.

STLF-210-REQ LRN.QOS-30. Delay tolerance (floor negotiation)

This kind of service does not impose a very restrictive delay constraint for floor negotiation (typically the assignment to a student the right to interact in the system). Several seconds (< 4sec) may be acceptable to provide a suitable and dynamic e-learning service.

STLF-210-REQ LRN.QOS-40. Jitter tolerance

During the user interactions, jitter requirements for system level measurement tools area applied. See 7.2.1 Requirements for system level measurement tools, Jitter measurement.

STLF-210-REQ LRN.QOS-50. Loss tolerance

During the user interactions, loss tolerance requirements for system level measurement tools area applied. See 7.2.1 Requirements for system level measurement tools, Packet loss measurement.

STLF-210-REQ LRN.QOS-60. Packet size

Small payload size (codec dependent) is desired so that packetizing delay is minimised. However, this increases packet overhead and therefore bandwidth. Thus, payload size should have a compromise value between these QoS requirements.

STLF-210-REQ LRN-QOS-70. Star t-up time

Start-up time, including connection and codec initialisation, should be bounded. A maximum value of 10 seconds is proposed.

STLF-210-REQ LRN.QOS-80. Perceptual quality

Audio/video quality should be measured and kept into acceptable terms, taken account that e-learning requires users to pay close attention to the media and possibly a higher quality than other services is expected. For the purpose of evaluating quality, common perceptual models (PESQ, MOS, PAMS, PSMQ+…) shall be used.

STLF-210-REQ LRN.QOS-90. Audio/Video synchronization

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

90 / 247

Audio and video should be appropriately synchronized, in order to achieve lips-voice correspondence. Delay difference should be kept below 50 ms.

4.1.4 Secur ity requirements

STLF-210-REQ LRN.SEC-10. Authentication and registration

Authentication and registration are optional. If enabled, public key systems may be used, or HTTP Digest Authentication protocol. Authentication (during registration) is a non-real-time procedure, so QoS issues are not to be considered.

STLF-210-REQ LRN.SEC-20. Media traffic

If media is to be secured, then encryption and integrity procedures will be needed. Due to the high volume of data, key management and re-keying features should be also considered. These solutions have to be scalable and shall not affect the performance of the system, as media traffic usually consists of real-time streams.

STLF-210-REQ LRN.SEC-30. Signalling traffic

Signalling traffic may be secured, too. Delay requirements are non critical, being this a non-real-time operation.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

91 / 247

4.2 VIDEO ON DEMAND Video on demand (VOD) proposes to provide subscribers who are connected through a set-top box (STB) with the possibility of ordering at any time the video of their choice and starting immediately to watch it on their television set. Despite its great potential, VOD has had a slow start because none of the companies that invested in VOD have been able to come with a single successful commercial system. Broadcasting is one of several techniques that aim to reduce the cost of VOD. It is clearly not a panacea as it only applies to videos that are likely to be watched by many viewers. Even so, the savings that can be achieved are nevertheless considerable, as it is often the case that 40 percent of the demand is for a small number, say, 10 to 20, of popular videos. Taking into account that most of the users demand these few contents, the use of Near VOD (NVOD) techniques could fit better than real VOD the market needs at a reasonable price. A naive broadcasting strategy would simply consist of retransmitting the same video on several distinct channels at equal time intervals. Whenever a NVOD solution is deployed is mandatory the use of multicast techniques (as regular broadcast) while providing real VOD implies the use of unicast in order to give a customized control to a single user. In this section we will analyse the real VOD requirements. For VOD applications, it is necessary to integrate the interactive applications provider with the TV broadcast, which in fact turns out to be a VOD server. The whole application scenario comprises IP transport, encapsulated into different protocols, depending on the network segment. The upper layers include UDP and TCP, with real-time protocols upon them. In this case, broadcasting is done over DVB-RCS. The RCST deencapsulates IP traffic and distributes it to the IP set-top boxes, which in turn extract and decode the video.

Figure 15. Video on Demand scenar io

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

92 / 247

As can be seen, no external networks are considered in this scenario, but VOD server may be outside the satellite network, hence the uplink RCST could be a RSGW receiving the VOD server traffic from an external network. Actually the distribution of Digital TV over IP has not reached an agreement in the way the multimedia content should be delivered to the final user, and there exists work groups like the DVB-IPI where a final standard is under development. Nowadays there are many standards to make that distribution, but the market (mainly STB manufacturers and VOD servers) has not taking the final agreement about which standard use to guarantee their compatibility. There still many open roads in the video delivery that carry to different places: the next arrival of MPEG-4 AVC standard to the market, the lack of commercial initiatives of high quality video distribution over IP (TV quality), the always evolving content production market or the lack of fully tested DRM protection system. In this framework the final scenario is hard to foreseen and the best position is to guarantee that all the solutions are available, trying to focus to the market trends at any time. The STB developers are deploying equipments that support MPEG-2 TS contents due mainly to the fact that the chips used in their hardware includes that kind of synchronization in the video and audio stream. In our case the video delivery is carried over IP, using Unicast protocol, and then the content could be encapsulated in UDP or in RTP over UDP. The control protocol that provides interactivity to the final user is RTSP.

STLF-210-REQ VOD-10. Streaming

The video file does not need to be downloaded first before viewing thereby not infringing on copyright issues. The video shall be viewed instantaneously.

STLF-210-REQ VOD-20. Two way communication

The user shall need a reverse path or two way communications to interact with the VOD server.

STLF-210-REQ VOD-30. Satellite link

The system shall provide the interconnection between the VOD server and the final user with a single satellite hop. That is, it won’ t be needed to reach a central hub in order to connect both sides.

STLF-210-REQ VOD-40. Content Protection

Content Protection systems are required to avoid piracy.

STLF-210-REQ VOD-50. Content Formats

The main content formats shall be MPEG-2 Transport Stream format.

STLF-210-REQ VOD-60. Transport stream

The transport stream must carry only a single program (SPTS).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

93 / 247

The transport stream must consist of 188 byte packets.

The transport stream must start on a packet boundary and contain an integral number of transport packets.

Encoded material shall be delivered in one continuous transport stream without discontinuities from the beginning of the program through to the end.

A Program Association Table (PAT) for the program must occur in the transport stream before any Program Mapping Table (PMT) for the program.

Both PAT and PMT must be inserted in the transport stream greater than 4 times per second (8 times per second recommended) throughout the program to allow rapid program acquisition.

The Program Clock Reference (PCR) PID of the program must be the same as the video stream PID of the program.

PCRs must occur with a separation of less than100 ms.

PCR accuracy at 27 MHz must be +/- 5ppm.

A PCR time stamp must be present in any packet containing the start of a video Packetized Elementary Stream (PES) payload.

STLF-210-REQ VOD-70. Elementary stream

Each stream within the program must start on an access unit boundary and consist of an integral number of access units.

Decoding Time Stamps (DTS) and Presentation Time Stamps (PTS) carried in the program stream must be accurate as defined in the MPEG standard ISO/IEC 13818-4, which specifies that for most circumstances the values for these must be exact.

Each GOP must contain an I-frame as the initial picture frame.

Each GOP must be preceded by a sequence header and a sequence extension.

GOPs shall nominally be 15 for 30 fps video source material and 12 for 24 fps film material.

GOPs shall be closed to start, open after that if needed.

STLF-210-REQ VOD-75. Transport Delivery

The delivery transport protocol could be MPEG-2 TS packets directly over UDP or over RTP.

STLF-210-REQ VOD-80. Control Protocol

The protocol used for control over the delivery of data shall be RTSP.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

94 / 247

STLF-210-REQ VOD-90. Server Status

The VOD server will be able to support the following RTSP status: • SETUP: Causes the server to allocate resources for a stream and start an RTSP session. • PLAY: Starts data transmission on a stream allocated via SETUP. • PAUSE: Temporarily halts a stream without freeing server resources. • TEARDOWN: Frees resources associated with the stream. The RTSP session ceases to exist on

the server.

STLF-210-REQ VOD-100. Server Methods

The VOD server will be able to support the following RTSP commands: • DESCRIBE: the DESCRIBE method retrieves the description of a presentation or media object

identified by the request URL from a server. The DESCRIBE response must contain all media initialisation information for the resource(s) that it describes.

• SETUP: the SETUP request for a URI specifies the transport mechanism to be used for the streamed media.

• PLAY: the PLAY method tells the server to start sending data via the mechanism specified in SETUP.

• PAUSE: the PAUSE request causes the stream delivery to be interrupted (halted) temporarily. • TEARDOWN: The TEARDOWN request stops the stream delivery for the given URI, freeing the

resources associated with it. • GET_PARAMETER: the GET_PARAMETER request retrieves the value of a parameter of a

presentation or stream specified in the URI. • SET_PARAMETER: this method request set the value of a parameter for a presentation or stream

specified by the URI.

STLF-210-REQ VOD-110. User Commands

The user shall be able to perform the following actions: • Request a new content. • Pause a content that the user is receiving. • Restart a content in the last content position. • Fast forward in the sequence of the content. • Rewind in the sequence of the content. • Stop the content that the user is receiving.

STLF-210-REQ VOD-120. Log files

The server shall store at least the following information per session: • The time instant the content starts playing. • The time instant the content stops playing. • The name or the identification of the content. • IP Address of the video server. • IP Address of streaming destination.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

95 / 247

STLF-210-REQ VOD-130. User Terminal

The user terminal shall consist in a TV set connected to a digital set-top-box. Also it shall be necessary a RCST for the user interactivity, but this terminal could be shared among several users.

STLF-210-REQ VOD.QOS-10. Content bitrate

Content shall be delivered as a single program transport stream with a base data rate of no greater than the maximum bandwidth available in the RCST. Encoding shall be Constant Bit Rate.

STLF-210-REQ VOD.QOS-20. Delay, j itter and packet loss

Taken into account that a large buffer is expected at the user terminal, these QoS parameters may be less important than on an audio/video real-time streaming application. Anyway, if RSTP or other non-reliable protocol is to be used, then packet loss should be kept a low value.

STLF-210-REQ VOD.QOS-30. Picture resolution and frame rate

These parameters are conditioned to the selected media format and elementary stream characteristics, but should be kept on a high quality level, complying with the bandwidth limit stated before.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

96 / 247

4.3 SOFTWARE DOWNLOAD Software download services are used to broadcast any kind of digital content like music, video, software, advertisements, web pages, documents, mailing list, newsgroups, etc. This service is a satellite data service targeting PCs that provides value-added services at high speed. The broadcast service is similar to TV point-to-multipoint transmissions. Basically, the contents are transmitted in a carousel, which enables users to access relevant Internet contents without being on-line as contents are received continuously through the satellite link. The main components of a software download service are described in the following lines:

• Information providers: are the providers of the information broadcasted, this information could be equal than the online version or an adapted version for offline use.

• IP server: this module is the link between the information providers and the broadcast head end. The IP server will adapt the delivered contents to MPEG-2 format for broadcasting.

• Satellite gateway: this module is the link between the IP world and the satellite medium. This adapter could be implemented in a DVB-RCST.

• A client application: this application will allow the reception and storage of the transmitted data.

From all these components, a complete architecture could be induced. The user terminal is a PC with a DVB-S card, or some kind of multimedia set-top box with a hard disk. The proposal here is to use transparent DVB-S and thus encapsulate software into MPEG2-TS; otherwise, DVB-RCS and IP could be used, which is regenerated in the satellite and received as DVB-S in the user terminal.

Figure 16. Software download scenar io

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

97 / 247

STLF-210-REQ SWD-10. Type of contents

The primary content shall be HTML pages, but any multimedia data shall be transmitted if needed. In the following lines are some examples of sample contents:

• Most visited webs. • Newspapers. • Sport information. • Software, games, tax programs, etc. • Enterprise services.

STLF-210-REQ SWD-20. Content flows

The software download service shall implement several flows in order to transmit several contents in the same time to several users or groups of users.

STLF-210-REQ SWD-30. Content scheduler

The software download service shall implement a scheduler for the transmission of the contents. This scheduler shall include the following actions: • Program the transmission of a particular content at a specific time in a specific flow. • Delete the scheduler for a content. • Update the scheduler for a content. • Move a content from one flow to another.

STLF-210-REQ SWD-40. SI /PSI Information

The software download service shall require the following SI/PSI tables to be transmitted in the transport stream that the user will receive in order to allow the receiver to process the data properly: • Program Association Table (PAT). • Program Map Table (PAT). • Network Information Table (NIT). • Service Description Table (SDT). The software download service shall send the PMT and SDT tables The software download service shall not send the PAT and NIT tables, but shall provide the information needed in these tables.

STLF-210-REQ SWD-50. Program guide

The program guide shall be one of the contents to be transmitted. This program guide will list all the contents delivered in the current day and in the following days.

STLF-210-REQ SWD-60. Packet loss

This service requires a reliable transport or application layer. Content integrity is essential.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

98 / 247

STLF-210-REQ SWD-70. QoS

This is a non-real-time service, so Quality of Service features are optional.

STLF-210-REQ SWD-80. Client application

The software download service shall provide a user application. This user application will let the user specify the downloads to receive and store.

STLF-210-REQ SWD.SEC-90. Authentication

Authentication is optional.

STLF-210-REQ SWD.SEC-100. Content secur ing

Due to copyright reasons, contents may be secured and encrypted. Therefore security is optional.

STLF-210-REQ SWD.SEC-110. Signalling traffic secur ing

Signalling traffic securing is optional.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

99 / 247

4.4 NOMADIC ACCESS The nomadic access to the satellite system consists in a fixed mobile solution with an automatic scanner polarizer and beam positioner system for a foldable two-way satellite antenna. This service is aimed for the nomad users who want to have high speed access in remote locations where cable and DSL do not exist, or for mobile terminals. Nomadic access should be available for mesh and star multicast and unicast access types. This kind of access should imply the availability of all services and applications listed in this chapter and the previous one, with all the considerations taken into account, both architectural and end-to-end. The figure below shows an architecture sample from a scenario where all agents and application providers are inside the satellite network. This architecture could be extended for all the specific services and applications listed in this document.

Figure 17. Nomadic access scenar io. Application provider inside satellite network

This other figure below shows the architectural scenario in which there is an application provider outside the satellite network. Again, this architecture is familiar and may be appropriately extended.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

100 / 247

Figure 18. Nomadic access scenar io. Application provider outside the satellite network

No matter if the application provider is inside or outside the satellite network, transparent mode can be used, with the additional penalization of using a double hop, as traffic must go through the hub, which increases delay. The requirements stated below apply generally to fixed stations, but it has been also included requirements for mobile terminals, which possibly are mounted in vehicles like trains, vans or buses.

STLF-210-REQ NOM-10. Automatic acquisition

It shall be designed to automatically find and acquire the satellite beam and the satellite position based on the GPS position reading and other positioning parameters. The satellite acquisition and lock shall be done in less than 5 minutes with a stowed dish for a fixed station. Mobile stations should have an automatic acquisition system so as to not lose satellite coverage all along its trajectory. Automatic acquisition for mobile terminals is out of the scope of SATLIFE project.

STLF-210-REQ NOM-20. Transparent and regenerative

The nomadic access shall be used in transparent and regenerative modes.

STLF-210-REQ NOM-30. Connectivity

The service provided by the nomadic access shall be equal for mesh and start connections.

STLF-210-REQ NOM-40. Interoperability

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

101 / 247

The nomadic equipment shall be compatible with RCSTs of different manufacturers.

STLF-210-REQ NOM-50. Equivalent access

Internet or Intranet services shall be accessed by the nomadic terminal in exactly the same way as a land-based terminal. Requests from the onboard equipment are transferred to the satellite via the return link.

STLF-210-REQ NOM-60. Intended users

The nomadic access service is aimed for the following users: • Prosumer: for people willing Internet access and meshed connections. • Corporate: for people willing access to their corporate LAN.

STLF-210-REQ NOM-70. User inter face

The interface of the nomadic user shall give the following information: • GPS information. • Satellite information, for example the name and the longitude and the calculated elevation and

azimuth based on the GPS information. • Pointing information, for example the actual dish elevation, azimuth and polarization. • Status of the system, for example, moving the dish, dish stowed, signal detected, transmit enable, etc. • The level or quality of the received signal. • Control buttons to start or cancel the pointing process, stow the dish, test the system, etc.

STLF-210-REQ NOM-80. Graphical inter face

The graphical interface of the nomadic user shall be integrated with a navigation system.

STLF-210-REQ NOM-90. Automatic procedures

The service shall offer an automatic procedure to set-up the nomadic terminal with the updated configuration when this configuration needs to be changed. For example, when the nomadic terminal has changed its location, it could be necessary to update its coordinates in order to adjust the transmission. This kind of procedures should be automatic to avoid that the user have to deal with this internal parameters. In the case of mobile terminals, these procedures should also be fast enough to not lose connectivity along the way.

STLF-210-REQ NOM-100. Mobile terminals support

Moving terminals, mounted in vehicles, shall be supported by the system. These terminals will have the appropriate procedures for mobility support and management, as stated before.

STLF-210-REQ NOM.QOS-10. Bitrate

The service shall offer the same performance than the fixed service.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

102 / 247

STLF-210-REQ NOM.QOS-20. Delay

Delay shall depend on the particular service but shall be equal than the fixed access.

STLF-210-REQ NOM.QOS-30. Jitter

Delay shall depend on the particular service but shall be equal than the fixed access.

STLF-210-REQ NOM.QOS-40. Connection time

As it was stated before, satellite acquisition and lock shall be done in less than 5 minutes. Connection time (without the satellite acquisition phase) shall be equal than the fixed access.

STLF-210-REQ NOM.QOS-50. Packet loss

Packet loss shall be equal than the fixed access and should be kept low.

STLF-210-REQ NOM.SEC-10. Authentication and registration

System users should be appropriately authenticated into the system. Therefore security is required.

STLF-210-REQ NOM.SEC-20. Traffic encryption

Traffic and signalling securing is optional.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

103 / 247

5. MULTIMEDIA REQUIREMENTS So far, particular requirements for the applications considered, as well as enhancements from the AMERHIS/IBIS project, have been stated. Now, we will sum up requirements that apply to some or all of the services and scenarios described above, being thus general requirements that can be considered for the whole SATLIFE project. In the present chapter, we will state multimedia requirements, which are needed for correct interactivity and modern QoS audiovisual servicing. First, we will make a brief introduction about the state-of-the-art in multimedia services, which will state the possibilities to be chosen when deploying multimedia content networks. This includes a chronological overview of both standard and proprietary formats, showing the convergence between computer world and communication networking. With this background, formats may be chosen and requirements may be stated. This is done through the next two parts of the chapter. Both Audio/Video requirements, which state image quality and display, codec availability and processing needs, and Streaming requirements, which state the things needed to appropriately deliver these contents to the users, considering present technologies available, will be thoroughly described. It has to be taken into account that the following requirements apply to broadcast and video on demand applications, but not to multiconferencing, whose particular requirements have been already stated.

5.1 INTRODUCTION Video coding is a key element for the deployment of multimedia services, because uncompressed digital video means a dataflow too large for storage, processing or transmission. This compression is possible because video signal contains info that can be suppressed without significantly decreasing its quality:

• Spatial redundancy: in general, images contain uniform areas, whose degree of useful information is poor.

• Temporal redundancy: along a video sequence, there is often great similitude between consecutive images.

When coding video signals, lossy compression is always used (i.e., the signal recovered by the decoder is never equal to the original), because the most powerful techniques for non-lossy video coding can’ t reach compression ratios far above 50%, which is not enough for transmission purposes. The challenge of video coding is keeping the distortion suffered when using lossy compression on an acceptable range for the end user. Next, we will state the history of the more common video coding standards and formats (the following figure is a chronological scheme of this evolution).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

104 / 247

Figure 19. Classical standards evolution

Almost every video coding Standard follows the model named “hybrid coding” , which means they combine two coding modes. The first widely used hybrid codec was specified in H.261 standard, developed by ITU-T workgroup SG16. H.261 is oriented to videotelephony signal transmission, and thus, with low delay requirements. Nowadays it’s still the most widespread standard in videotelephony devices. Later came MPEG-1, developed by ISO’s MPEG. It’s a generic standard, appropriate for any kind of video. MPEG-1 had a great impact, and we can consider it as the start point of digital video revolution. MPEG-2 has had, and still has, even greater relevance. It’s the next step from MPEG-1, and has evident similarities to it (MPEG-2 video part basically adds interlaced video and higher binary rate and quality support). MPEG-2 is the basis for digital TV systems, either satellite or terrestrial, and for DVD. To guarantee device compatibility, MPEG-2 defines several “profiles” , which establish functionality sets, and “ levels” , which define complexity degrees, restricting coding parameters, and thus mean different levels of processing performance requirements for encoder and decoder.

5.1.1 Propr ietary Developments ISO and ITU standards have their historical origin focused in video usage on communication systems. But there’s another workline, which emerges from home computer software. This sector has been traditionally dominated by “ad hoc” solutions, developed by software manufacturers. The two traditional video format providers have been the main home computer operating systems developers, Microsoft and Apple; more recently, RealMedia has joined the bunch.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

105 / 247

Chronologically, the first format to hit the market was “QuickTime”, from Apple, which allowed to store video and audio files for reproduction in Macintosh computers. On the other hand, Microsoft created AVI (Audio Video Interleaved) format, which did the same for Windows operating system (later, cross versions of both formats where released, which allowed the usage of both in the two systems). It’s important to remark that both QuickTime and AVI are in fact a file format, not a video/audio coding algorithm; the format allows the embedding, on a standardized form, of video or audio tracks, which had been coded with compression algorithms. They are, thus, parallel to MPEG system layer. Both have the possibility of using an undefined number of video codecs. For this purpose, they provide an API for video track manipulation. In consequence, many different video codecs from third manufacturers were released, and many of them were supported by both formats (for example, CINEPAK or Intel Indeo). The spreading of Internet motivated the need of widening AVI and QuickTime formats in order to allow streaming instead of local reproduction: the file is sent progressively from a server and is decodified and shown as it is received, without having to wait for the whole file to be downloaded. For this purpose, Apple added streaming features to QuickTime. Microsoft, at the same time, developed a new specification to replace AVI, which was named ASF (“Advanced Streaming Format” ). Later, it was renamed Windows Media. By that time, Real Networks emerged as a third provider of streaming solutions with its RealMedia format, which wasn’ t related to a specific platform as the former ones. These three formats comprise, nowadays, the whole majority of the contents available in the Internet. It is to be remarked that both RealMedia and QuickTime (specially the latter) in their latest versions provide support for embedding MPEG-4 coded video. Microsoft, on its side, supports only his own video codec in Windows Media, which is named Windows Media Video (WMV). At the moment, DivX format is reaching great popularity, on its different implementations. In fact, DivX is just a combination of several existing formats and algorithms. Particularly, its video part uses MPEG-4 at simple profile. A comparison between different platforms and the standard is shown:

• DivX5 is an implementation of MPEG-4 Advanced Simple Visual Profile. DivX Networks is also working on file format compliance.

• Microsoft was one of the first companies to deploy an MPEG-4 Video codec in its Windows Media platform, in previous versions. It doesn’ t seem to be present in the latest version, Windows Media 9. Some developers will know Microsoft’s contribution to the MPEG-4 Reference Software, one of the two implementations of the MPEG-4 Visual standard that developers can download from ISO’s website (The other implementation is from the European project ‘MoMuSys’ ).

• The file format of MPEG-4 (MP4) is based on the QuickTime architecture. The rest of the MPEG-4 standard was developed independent of QuickTime. QuickTime started supporting MPEG-4 with its version 6, which includes Simple Visual profile and AAC.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

106 / 247

5.1.2 Standard formats

5.1.2.1 Standard formats up to MPEG-4 After the creation of the mentioned standards, both ISO’s MPEG and ITU’s SG16 have continued working in the elaboration of new specs which allow better performance or additional functionality. All of them keep on using the already mentioned hybrid codec scheme, with appropriate changes to obtain improvements. Concerning to ITU, after finishing in 1995 the original H.263 videotelephony standard, ITU-T’s VCEG (Video Coding Experts Group) group started working on two parallel development areas: a short-term one, aiming to add extra characteristics to H.263 standard, which produced the next standard review in 1998 (later, additional appendices were published), and a long-term one, which tried to develop a new standard for visual communication with a high compression ratio. This latter work line produced the H.26L standard draft, which offered significantly better efficiency in video compression than former ITU-T standards. The reference model of the codec being developed by VCEG was named Test Model Long-term (TML), and was successively refined. H.26L has served as a basis to the new JVT standard. About MPEG, the new standard is MPEG-4. This is a much more versatile standard than MPEG-2, and as a consequence much more complicated, which includes many algorithms and variations for video, audio and graphics coding, and also for interactive 3D scene composition from object definitions. Concerning to traditional video coding, it includes substantial quality improvements from MPEG-1 and MPEG-2, which have been subjectively tested. Given MPEG-4 complexity, the number of defined profiles is much larger than in MPEG-2. Among all of them, the most widely used for natural video coding on distribution or video on demand applications, are Simple profile (SP) and Advanced Simple profile (ASP). Both define only rectangular video, which means they don’ t support video objects; Advanced Simple profile includes Simple profile functionalities and also additional techniques which allow an even stronger bandwidth reduction. Reliable quality comparisons, i.e., subjective tests, between recent standards as MPEG-4 and proprietary formats (Windows Media, RealMedia) haven’ t been published yet. Anyway, it is assumed that there are no great differences between them. In practice, a service or content provider will choose one of them based in other type of considerations: availability for the desired platforms, ease of use, patents and licensing, strategical adequateness or sustainability and mid and long-term support.

5.1.2.2 JVT/H.264 Standard In 2001, MPEG recognised the potential benefits of the H.26L draft, which led to the joint workgroup JVT (Joint Video Team), which included ISO-MPEG and VCEG-ITU-T experts. JVT task was to finish the specs of H.26L draft and turn it into a complete International Standard. The final result was published as two identical standards: It was Part 10 of MPEG-4, with official title “Advanced Video Coding” , AVC. It is named as H.264 in the ITU-T terminology.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

107 / 247

The JVT standard is commonly known as H.26L or as JVT. It reached the FCD (Final Committee Draft) in December 2002, which means that the technical specs would remain unchanged since then. In march 2003 it was approved as FDIS (Final Draft International Standard), and afterwards it was officially published as an International Standard. The technical goals of the standard can be resumed in two points:

• Significant improvements in coding efficiency, seeking a binary rate reduction (for the same quality) from former standards of 50%.

• Efficient adaptation for transmission and error robustness, either being transported in MPEG-2 systems or on IP protocols like RTP.

5.2 AUDIO AND VIDEO REQUIREMENTS In order to store audio and video, it is important to define how it is going to be done. There are standard and commercial solutions, forward there are shown some of the most important, to compare them. We will study the formats in chronological order, starting with MPEG-1, following MPEG-2 and then with the most up-to-date formats: MPEG-4, Real, QuickTime and the flavours of DivX. We will review the most relevant formats to extract the different requirements that could be used in various scenarios. The compatibility between standards and commercial solutions is a big deal, in this sense Microsoft and Real Networks support MPEG-4 on their respective media players only through plug-in software provided by third-party vendors, those vendors focus on proprietary file formats. Instead, QuickTime supports MPEG4 itself.

5.2.1 MPEG1 In 1988 the Moving Picture Experts Group (MPEG) was founded under ISO/SC2 with the charter to standardize a video coding algorithm targeted for digital storage media and bit rates at up to about 1.5 Mbps. Its official denotation is now ISO/IEC/JTC1/SC29/WG11. The first Draft International Standard (DIS) released by the committee, ISO 11172 (MPEG-1), was drafted in 1991 and finally issued as IS in 1992. MPEG-1 is intended to be generic (although the initial target applications envisaged and applications parameters defined were constrained to digital storage media). Generic means, that the standard is independent of a particular application and therefore comprises mainly a toolbox. It is up to the user to decide, which tools to select to suit the particular applications envisaged. This implies, that only the coding syntax is defined and therefore mainly the decoding scheme is standardized. MPEG-1 defines a hybrid DCT/DPCM coding scheme with motion compensation similar to the H.261 and CCIR Rec. 723 coding standards. Further refinements in prediction and subsequent processing were introduced to provide the functionality required for random access in digital storage media. The video compression technique developed by MPEG-1 covers many applications from interactive systems on CD-ROM to the delivery of video over telecommunications networks. The MPEG-1 video coding standard is thought to be generic. To support the wide range of applications profiles a diversity of

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

108 / 247

input parameters including flexible picture size and frame rate can be specified by the user. MPEG has recommended a constraint parameter set: every MPEG-1 compatible decoder must be able to support at least video source parameters up to TV size: including a minimum number of 720 pixels per line, a minimum number of 576 lines per picture, a minimum frame rate of 30 frames per second and a minimum bit rate of 1.86 Mbps. The standard video input consists of a non-interlaced video picture format. It should be noted that by no means the application of MPEG-1 is limited to this constrained parameter set. The MPEG-1 video algorithm has been developed with respect to the JPEG and H.261 activities. It was sought to retain a large degree of commonalty with the CCITT H.261 standard so that implementations supporting both standards were plausible. However, MPEG-1 was primarily targeted for multimedia CD-ROM applications, requiring additional functionality supported by both encoder and decoder. Important features provided by MPEG-1 include frame based random access of video, fast forward/fast reverse (FF/FR) searches through compressed bit streams, reverse playback of video and editability of the compressed bit stream. MPEG1 (1992) The first generic audio coding standard. It had 3 layers and was used in DAB, DVB, internet audio as well as MP3 files. MPEG-1 defines a framework for coding moving video and audio, significantly reducing the amount of storage with minimal perceived difference in quality. In addition a System specification defines how audio and video streams can be combined to produce a system stream. This forms the basis of the coding used for the VCD format.

5.2.1.1 Fixed And Variable Bitrate coding MPEG1 enables fixed and variable codification.

STLF-210-REQ MUL.AAV.MP1-10. Target bitrate

The maximum bitrate for MPEG1 video shall be 1.5 Mbps. MPEG1 could not be used with low bitrate contents, so the target bitrate for video contents shall be from 1 to 1.5 Mbps, and up to 2 Mbps if audio is added.

STLF-210-REQ MUL.AAV.MP1-20. Var iable bitrate

MPEG-1 contents coded in variable bitrate in SATLIFE services shall be optional.

STLF-210-REQ MUL.AAV.MP1-30. Fixed bitrate

MPEG-1 contents coded in constant bitrate shall be used in SATLIFE services.

5.2.1.2 TV and PC contents

STLF-210-REQ MUL.AAV.MP1-40. TV Spatial resolution

For TV applications the spatial resolution to be used shall be 720x 576 pixels.

STLF-210-REQ MUL.AAV.MP1-50. PC Spatial resolution

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

109 / 247

For PC applications the spatial resolution to be used shall be 288 x 360 pixels (CIF).

STLF-210-REQ MUL.AAV.MP1-60. Time resolution

25 - 30 images/s depending on NTSC-PAL respectively.

5.2.1.3 Audio And Video File Formats

STLF-210-REQ MUL.AAV.MP1-70. Definition

MPEG1 did not explicitly define a format for storing compressed audiovisual data in a file. It is common for single compressed video sequences to be stored in files, simply by mapping the encoded stream to a sequence of bytes in a file.

5.2.2 MPEG-2 Studies on MPEG-2 started in 1990 with the initial target to issue a standard for coding of TV-pictures with CCIR Rec. 601 resolution at data rates below 10 Mbps. In 1992 the scope of MPEG-2 was enlarged to suit coding of HDTV - thus making an initially planned MPEG-3 phase superfluous. The DIS for MPEG-2 video was issued in early 1994. MPEG-2 is the audiovisual standard most widely used for entertainment video applications. MPEG-2 enables digital television and DVDs, and there are several hundred million MPEG-2 decoders deployed in Digital Satellite and Cable set-top boxes, DVD players and PCs. It is a more powerful format than MPEG-1, capable of achieving higher compression ratios and supporting interlaced video. MPEG–2 decoding and encoding are more CPU-intensive than for MPEG-1, especially for video. Virtually every image you see on television today, even on an analogic receiver, has at some point been coded and decoded in MPEG-2. Basically MPEG-2 can be seen as a superset of the MPEG-1 coding standard and was designed to be backward compatible to MPEG-1 - every MPEG-2 compatible decoder can decode a valid MPEG-1 bit stream. Many video coding algorithms were integrated into a single syntax to meet the diverse applications requirements. New coding features were added by MPEG-2 to achieve sufficient functionality and quality, thus prediction modes were developed to support efficient coding of interlaced video. In addition scalable video coding extensions were introduced to provide additional functionality and in order to keep implementation complexity low for products not requiring the full video input formats supported by the standard, such as embedded coding of digital TV and HDTV. However, implementation of the full syntax may not be practical for most applications. MPEG-2 has introduced the concept of "Profiles" and "Levels" to stipulate conformance between equipment not supporting the full implementation. Profiles and Levels provide means for defining subsets of the syntax and thus the decoder capabilities required to decode a particular bit stream.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

110 / 247

As a general rule, each Profile defines a new set of algorithms added as a superset to the algorithms in the Profile below. A Level specifies the range of the parameters that are supported by the implementation (i.e. image size, frame rate and bit rates). The MPEG-2 core algorithm at Main Profile features non-scalable coding of both progressive and interlaced video sources. It is expected that most MPEG-2 implementations will at least conform to the Main Profile at Main Level which supports non-scalable coding of digital video with approximately digital TV parameters - a maximum sample density of 720 samples per line and 576 lines per frame, a maximum frame rate of 30 frames per second and a maximum bit rate of 15 Mbps.

5.2.2.1 Levels And Profiles Because of the huge amount of possible applications, MPEG2 defines levels and profiles to make the design and implementation easier.

STLF-210-REQ MUL.AAV.MP2-10. Levels Definition

In the following table are listed the MPEG-2 levels identification names. However only Main and High levels shall be used in MPEG-2 contents.

Level Features Low Image 352x288 Main Image 720x576x25Hz, 720x480x29,97Hz High 1440 Image HDTV up to 1440x1152 High Image HDTV up to 1920x1152

Table 6. MPEG-2 levels

STLF-210-REQ MUL.AAV.MP2-20. Profiles Definition

Profiles reference to some of the tools of the standard. A resume is shown in the following table:

Profile Features Simple No B images Main Similar to MPEG-1 SNR Main Profile with quality scalability. Spatial Main Profile with spatial scalability. High Main Profile, SNR, spatial plus other functionalities

Table 7. MPEG-2 profile definitions

Some combinations of level and profiles are not supported in DVB-S, so only the following profiles and levels shall be used:

• MPEG-2 Main Profile at Main Level for SDTV. • MPEG-2 Main Profile at High Level for HDTV.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

111 / 247

Due to the return channel bitrate limitations, HDTV using DVB-RCS shall be limited and shall be optional.

5.2.2.2 Fixed And Variable Bitrate Coding For some applications, it is necessary to transmit the encoded video information with a fixed bit rate. For example, in broadcast mediums (satellite, cable, terrestrial etc.), practical limitations mean that current transmission is restricted to using a fixed bit rate. This is why fixed bit rate MPEG-2 encoders are available. It is true that a fixed bit rate encoder is not as efficient as the variable bit rate system, however the MPEG-2 system still provides very high quality video for both encoding methods. Very importantly, fixed bit rate encoding can also be carried out in real time, i.e. one pass of the video information. For live broadcasts, and satellite linkups etc. the real time encoding capability is essential. The advantage of using a variable bit rate is mainly the gain it gives in encoding efficiency. For fixed storage mediums (e.g. DVD) the variable bit rate is ideal. By reducing the amount of space needed to store the video (whilst retaining very high quality), it leaves more space on the medium for inclusion of other features e.g. multiple language soundtracks, extra subtitle channels, interactivity, etc. The other important feature of the variable bit rate system is that it gives constant video quality for all complexities of program material. A constant bit rate encoder provides variable quality.

STLF-210-REQ MUL.AAV.MP2-30. Fixed And Var iable Bitrate

MPEG-2 contents coded in constant bitrate shall be used in SATLIFE services. MPEG-2 contents coded in variable bitrate shall be optional.

5.2.2.3 Bitrate

STLF-210-REQ MUL.AAV.MP2-40. Bitrate

The maximum bitrate depends on levels and profiles. The target profile and level will be Main Profile-Main Level for any services and applications that will use MPEG-2 video. The maximum bitrate is 15 Mbps, with 4:2:0 and 720x576, however lower bitrates shall be used. The target bitrate for MPEG-2 video Main Profile at Main Level should be from 2 to 3 Mbps to accommodate to the satellite network. The target profile and level to be considered in services where HDTV is used shall be Main Profile at High Level. The maximum bitrate specified is 80 Mbps, with 4:2:0 and 1920x1152, but in order to accommodate to the satellite network the target bitrate should be from 2 to 3 Mbps. This bitrate is too low in order to send MPEG-2 video using HDTV, however, will be possible to send a carousel of static images.

5.2.2.4 TV And PC Contents

STLF-210-REQ MUL.AAV.MP2-50. Spatial resolution

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

112 / 247

The spatial resolution for SDTV shall be 720 x 576 pixels. The spatial resolution for HDTV shall be 1920 x 1080 pixels or 1280 x 720 pixels.

STLF-210-REQ MUL.AAV.MP2-60. Time resolution

The frames per second for DSTV shall be 25 / 30 fps. The frames per second for HDTV shall be 25 / 30 fps interlaced (using 1920 x 1080) or 60 fps progressive (using 1280 x 720).

5.2.2.5 Audio And Video File Formats


MPEG2 did not explicitly define a format for storing compressed audiovisual data in a file. It is common for single compressed video sequences to be stored in files, simply by mapping the encoded stream to a sequence of bytes in a file.

5.2.3 MPEG-4 MPEG-4 is an open standard, representing thousands of man-years of work shared by hundreds of companies. No one company can hope to match the technical and intellectual resources of an entire competitive market. No other technology has the potential to become as deeply developed and widely supported by multiple industries, vendors and service providers, and to be trusted by end users with their video and multimedia needs. Anticipating the rapid convergence of telecommunications industries, computer and TV/film industries, the MPEG group officially initiated a new MPEG-4 standardization phase in 1994 - with the mandate to standardize algorithms and tools for coding and flexible representation of audio-visual data to meet the challenges of future Multimedia applications and applications requirements MPEG-4 is developed by the Moving Picture Experts Group (MPEG), a workgroup of the International Organization for Standardization (ISO) and the International Electro-technical Committee (IEC) – the group that designed MPEG-1, which includes MP3 digital audio and MPEG-2 (the standard for the digital television, both DVB and DVD). Several streaming providers have adopted MPEG-4 including Apple, who adopted MPEG-4 Simple Visual Profile and Advanced Audio Coding for its QuickTime platform, Real Networks, who supports decoding of MPEG-4 content, and the popular DivX codec is also MPEG-4 compliant. In fact, most – if not all - of the major streaming players support, either natively or through plug-ins, the MPEG-4 standard in their currently deployed infrastructure and products. The best way to understand MPEG-4’s new paradigm is by comparing it to MPEG-2. In the MPEG-2 world, content is created from various resources such as moving video, graphics, text. After it is “composited” into a plane of pixels, these are encoded as if they all were moving video pixels. At the

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

113 / 247

consumer side, decoding is a straightforward operation. MPEG-2 is a static presentation engine: if one broadcaster is retransmitting another broadcaster’s coverage of an event, the latter’s logo cannot be removed, also for example, viewers may occasionally see the word “ live” on the screen when a broadcaster is showing third party live footage from earlier in the day. You can add graphic and textual elements to the final presentation, but you cannot delete them. The MPEG-4 paradigm turns this upside down. It is dynamic, where MPEG-2 is static. Different objects can be encoded and transmitted separately to the decoder in their own elementary streams. The composition only takes places after decoding instead of before encoding. This actually applies for visual objects and audio alike, although the concept is a little easier to explain for visual elements. In order to be able to do the composition, MPEG-4 includes a special scene description language, called BiFS, for Binary Format for Scenes. The BiFS language not only describes where and when the objects appear in the scene, it can also describe behaviour (make an object spin or make two videos do a cross-fade) and even conditional behaviour – objects do things in response to an event, usually user input. This brings the interactivity of MPEG-4. All the objects can be encoded with their own optimal coding scheme – video is coded as video, text as text, graphics as graphics – instead of treating all the pixels as moving video, which they often really aren’ t. MPEG-4 consists of closely interrelated but distinct individual Parts, that can be individually implemented (e.g., MPEG-4 Audio can stand alone) or combined with other parts. The basis is formed by Systems (part 1), Visual (part 2) and Audio (part 3). DMIF (Delivery Multimedia Integration Framework, part 6) defines an interface between application and network/storage. Conformance (part 4) defines how to test an MPEG-4 implementation, and part 5 gives a significant body of Reference Software, that can be used to start implementing the standard, and that serves as an example of how to do things.

5.2.3.1 Levels And Profiles

STLF-210-REQ MUL.AAV.MP4-10. Definition of levels and profiles

The MPEG-4 Visual standard defines (by October 2001) 18 visual object types and 19 visual profiles. Nine visual profiles have been defined in MPEG-4 Visual Version 1 [MPEG4-1]: Simple, Simple Scalable, Core, Main, N-bit, Scaleable Texture, Simple Face Animation, Basic Animated Texture, and Hybrid. Six additional visual profiles have been defined in MPEG-4 Visual Version 2 [MPEG4-2]: Core Scalable, Advanced Core, Advanced Coding Efficiency, Advanced Real Time Simple, Advanced Scaleable Texture, and Simple FBA. Moreover 2 additional profiles have been defined in the 1st Extension to the 2nd Edition of the MPEG-4 Visual standard [MPEG01a]: Simple Studio and Core Studio. And 2 profiles in the 2nd Extension to the 2nd Edition of the MPEG-4 Visual standard [MPEG01b]: Advanced Simple and Fine Granularity Scalability.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

114 / 247

Figure 20. An overview of the profile structure in MPEG-4

Visual profiles are defined using the visual object types, so is necessary to discuss these before discussing the profiles themselves. There are 5 different object types for representing natural video information: Simple, Simple Scalable, Core, Main, N-bit, Still Scalable Texture, Animated 2D Mesh, Basic Animated Texture, Simple Face. The visual profiles determine which visual object types can be present in the scene. This is also the way they are defined: as a list of admissible object types. Quite a few of them correspond to the most complicated object that they support, and they also have similar names. Next table gives an overview of the basic visual profiles which has been increased in different revisions of the standard.

STLF-210-REQ MUL.AAV.MP4-20. Basic visual profiles

Profiles à â Object types

Simple Simple Scaleable Core Main N-Bit Scaleable Texture

Simple ü ü ü ü ü Simple Scalable ü Core ü ü ü Main ü N-Bit ü Scalable Texture

ü ü

Number of Levels

3 2 2 3 1 3

Table 8. MPEG-4 profile definition

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

115 / 247

The Simple Profile only accepts objects of type Simple, and was created with low complexity applications in mind. The first usage is mobile use of (audio)visual services, and the second is putting very low complexity video on the Internet. Also small camera devices recording moving video to, e.g., disk or memory chips, can make good use of this profile. It supports up to four objects in the scene with, at the lowest level, a maximum total surface of a QCIF picture. There are 3 levels for the Simple Profile with bitrates from 64 to 384 Kbps.

STLF-210-REQ MUL.AAV.MP4-30. Simple profile levels and bitrate

The maximum bitrate for MPEG4 video coded in simple profile is: • L1. Maximum bitrate 64 kbps. • L2. Maximum bitrate 128 kbps. • L3. Maximum bitrate 384 kbps.

The Simple Scalable Profile can supply scalable coding in the same operational environments as foreseen for Simple, and has 2 levels defined.

STLF-210-REQ MUL.AAV.MP4-40. Simple scalable profile levels and bitrate

• The maximum bitrate for MPEG4 video coded in scalable profile is:L1. Maximum bitrate 64 kbps.

• L2. Maximum bitrate 128 kbps. The Core Profile accepts Core and Simple object types. It is useful for higher quality interactive services, combining good quality with limited complexity and supporting arbitrary shape objects. Also mobile broadcast services could be supported by this profile. While the levels do not prescribe the visual session size, they are created with a certain session size in mind, called the ‘ typical visual session size’ . For Simple this was QCIF, for Core it is QCIF and CIF for the two levels respectively. The amount of macroblocks is chosen such that a scene using this typical session size can have overlapping objects and still be ‘ filled’ .

STLF-210-REQ MUL.AAV.MP4-50. Core profile levels and bitrate

The maximum bitrate for MPEG4 video coded in core profile is: • L1. Maximum bitrate 384 kbps. • L2. Maximum bitrate 2000 kbps.

The Main Profile was created with broadcast services in mind, addressing progressive as well as interlaced material. It combines the highest quality with the versatility of arbitrarily shaped object using grey-scale coding. The highest level accepts up to 32 objects (of Simple, Core, or Main type) for a maximum total bitrate of 38 Mbps.

STLF-210-REQ MUL.AAV.MP4-60. Main profile levels and bitrate

The maximum bitrate for MPEG4 video coded in main profile is: • L1. Maximum bitrate 2000 kbps.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

116 / 247

• L2. Maximum bitrate 15000 kbps. • L3. Maximum bitrate 38400 kbps.

The N-bit profile is useful for areas that use thermal imagers, such as surveillance applications. Also medical applications may want to use the enhanced pixel depth giving a larger dynamic range in colour and luminance. It accepts objects of type Simple, Core, and N-bit. Currently only one level is defined.

STLF-210-REQ MUL.AAV.MP4-70. N-bit profile levels and bitrate

• The maximum bitrate for MPEG4 video coded in N-bit profile is:L1. Maximum bitrate 2000 kbps. The Scaleable Texture Profile is meant for audiographic applications. It was requested by companies that want to build mobile devices, which combine sound with synchronously displayed pictures, and possibly BIFS-based graphics, in very simple terminals.

STLF-210-REQ MUL.AAV.MP4-80. Scaleable texture profile levels and bitrate

The maximum bitrate for MPEG4 video coded in scaleable texture profile is: • L1. Maximum bitrate 32 kbps. • L2. Maximum bitrate 64 kbps. • L3. Maximum bitrate 128 kbps.

5.2.3.2 TV and PC contents

STLF-210-REQ MUL.AAV.MP4-160. Resolutions

Two resolutions shall be supported: QCIF and TV resolutions.

STLF-210-REQ MUL.AAV.MP4-170. Formats

Two formats shall be supported: progressive and interlaced video.

5.2.3.3 Audio and video file formats


The MPEG4 file format, standardized as parts of MPEG4, is designed to store MPEG4 Audio-Visual. This format is delivered from the ISO Base Media File Format which in turn is based on Apple Computer's Quick Time Format. In the ISO Media File Format a coded stream is stored as a track representing a sequence of coded data items.

5.2.4 H.264/AVC

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

117 / 247

In 1998, the Video Coding Experts Group (VCEG.ITU-T SG16 Q.6) started a project called H.26L with the target to double the coding efficiency when compared with any other existing video coding standard. In December 2001, VCEG and the Moving Pictures Expert Group (MPEG.ISO/IEC JTC 1/SC 29/WG 11) formed the Joint Video Team (JVT) with the charter to finalize the new video coding standard H.264/AVC. It also may be referred to as MPEG-4 Part 10. The H.264/AVC design covers a Video Coding Layer (VCL), which efficiently represents the video content, and a Network Abstraction Layer (NAL), which formats the VCL representation of the video and provides header information in a manner appropriate for conveyance by particular transport layers or storage media. The VCL design, as in any prior ITU-T and ISO/IEC JTC1 standard since H.261, follows the so-called block-based hybrid video-coding approach. The basic source-coding algorithm is a hybrid of inter-picture prediction, to exploit the temporal statistical dependencies, and transform coding of the prediction residual to exploit the spatial statistical dependencies. There is no single coding element in the VCL that provides the majority of the dramatic improvement in compression efficiency, in relation to prior video coding standards. Rather, it is the plurality of smaller improvements that add up to the significant gain. Next, we will provide an overview of the H.264/AVC design. The Profiles and Levels specified in the current version of H.264/AVC will be briefly described. The H.264/AVC design supports the coding of video (in 4:2:0 chroma format) that contains either progressive or interlaced frames, which may be mixed together in the same sequence. Generally, a frame of video contains two interleaved fields, the top and the bottom field. The two fields of an interlaced frame, which are separated in time by a field period (half the time of a frame period), may be coded separately as two field pictures or together as a frame picture. A progressive frame should always be coded as a single frame picture; however, it is still considered to consist of two fields at the same instant in time.

STLF-210-REQ MUL.AAV.AVC-10. Chroma format

H.264 uses 4:2:0 chroma sampling structure.

STLF-210-REQ MUL.AAV.AVC-20. Use of several chroma formats

If several chroma formats are to be supported, a conversion/decimation to 4:2:0 format has to be done previously to encoding. The output format will always be 4:2:0.

STLF-210-REQ MUL.AAV.AVC-30. Sequence field structure

Both interlaced and progressive formats may be used. The video coding layer of H.264/AVC is similar in spirit to other standards such as MPEG-2 Video. It consists of a hybrid of temporal and spatial prediction, in conjunction with transform coding. In summary, the picture is split into blocks. The first picture of a sequence or a random access point is typically Intra. coded, i.e., without using information other than that contained in the picture itself. Each sample of a block in an Intra frame is predicted using spatially neighbouring samples of previously coded blocks. The

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

118 / 247

encoding process chooses which and how neighbouring samples are used for Intra prediction, which is simultaneously conducted at the encoder and decoder using the transmitted Intra prediction side information. For all remaining pictures of a sequence or between random access points, typically Inter coding is used. Inter coding employs prediction (motion compensation) from other previously decoded pictures. The encoding process for Inter prediction (motion estimation) consists of choosing motion data, comprising the reference picture, and a spatial displacement that is applied to all samples of the block The motion data which are transmitted as side information are used by the encoder and decoder to simultaneously provide the Inter prediction signal.

STLF-210-REQ MUL.AAV.AVC-40. Motion compensation

Motion compensation can be done with a precision of ¼ pixel. The residual of the prediction (either Intra or Inter), which is the difference between the original and the predicted block, is transformed. The transform coefficients are scaled and quantized. The quantized transform coefficients are entropy coded and transmitted together with the side information for either Intra-frame or Inter-frame prediction. The encoder contains the decoder to conduct prediction for the next blocks or the next picture. Therefore, the quantized transform coefficients are inverse scaled and inverse transformed in the same way as at the decoder side, resulting in the decoded prediction residual. The decoded prediction residual is added to the prediction. The result of that addition is fed into a deblocking filter which provides the decoded video as its output. Profiles and levels specify the conformance points. These conformance points are designed to facilitate interoperability between various applications of the H.264/AVC standard that have similar functional requirements. A profile defines a set of coding tools or algorithms that can be used in generating a compliant bitstream, whereas a level places constraints on certain key parameters of the bitstream. All decoders conforming to a specific profile have to support all features in that profile. Encoders are not required to make use of any particular set of features supported in a profile but have to provide conforming bitstreams. In H.264/AVC, three profiles are defined.

STLF-210-REQ MUL.AAV.AVC-50. Profiles

The profiles defined are Baseline, Main and X. -The Baseline profile supports all features in H.264/AVC except the following two feature sets:

-Set 1: B slices, weighted prediction, CABAC, field coding and macroblock adaptive switching between frame and field coding. -Set 2: SP and SI slices.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

119 / 247

-The first set of features is supported by Main profile. However, Main profile does not support the FMO feature which is supported by the Baseline profile. -Profile X supports both sets of features on top of the Baseline profile, except for CABAC and macroblock adaptive switching between frame and field coding. In H.264/AVC, the same set of level definitions is used with all profiles, but individual implementations may support a different level for each supported profile. Eleven levels are defined, specifying upper limits for the picture size (in macroblocks), the decoder-processing rate (in macroblocks per second), the size of the multipicture buffers, the video bit-rate and the video buffer size. We will not make a particular comment on these levels, because such a concrete description is out of the scope of this document.

STLF-210-REQ MUL.AAV.AVC-55. Profile applications

When deciding what profile and level combination to choose, we should consider broadcast application as a starting point. D1 resolution at 2 Mbps shall be the format applied, and in this situation, baseline and main profiles are best suited, the first one if encoding speed is critical and main profile if quality and efficiency should be achieved. The extended profile is not considered for most applications. It uses sophisticated slice coding, and usually it is used for mobile terminals.

STLF-210-REQ MUL.AAV.AVC-57. Application bitrate

The following table states the performance of a common encoder, which should serve as a guideline for desired bitrates for applications. To correctly interpret these table correctly, the “Mode” column should be explained:

• “Real” means that encoding speed is of the most importance. This mode supports up to D1 real-time encoding with 1-3 Mbps bitrate. Faster encoding speed is achieved at the expense of certain degradation of compression and/or picture quality.

• “Fast” mode is a "normal quality fast encoding", which provides a bit nicer picture with a small performance penalty.

• “Good” mode is designed for optimal trade off between performance and quality. Used for real-time encoding of QCIF and CIF video sequences, and for off-line encoding of D1 sequences.

• "Best quality encoding" mode allows for maximum output image quality available. Used for off-line encoding with best compression and quality.

CPU Resolution Profile Mode Speed (fps)

Real 30 Baseline Fast 20

Good 15

D1(720x480) 2000 kbps

Main Best 6 Real 90 Baseline Fast 65

Good 60

CIF(352x288) 500 kbps

Main Best 20

P-IV 3.0 GHz

QCIF(176x144) Baseline Real 300

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

120 / 247

Fast 300

Good 110 128 kbps

Main Best 80

Table 9. H.264 encoder per formance

As can be seen, multiple bitrates can be achieved, depending on the features and processor performance required. For example, to achieve real-time 2Mbps compression with a standard P-IV 3.0GHz machine, baseline profile must be used, which means that quality won’ t be as good as can be. For best quality at these bitrates, encoding should be done off-line, or have a very high performance machinery. As for encoding, the same sum-up can be done for decoding, with the consideration that probably decoding machines have less processing capacity.

CPU Resolution Bitrate (kbps) Profile Speed (fps) Baseline 2000 QCIF(176x144) 128

Main 1000 Baseline 350 CIF(352x288) 500

Main 200 Baseline 100 500

Main 70 Baseline 90 1000

Main 60 Baseline 80

P-IV 3.0 GHz

D1(720x480)

2000 Main 50

Baseline 300 QCIF(176x144) 128 Main 150

Baseline 50 CIF(352x288) 500 Main 35

Baseline 12

P-III 800 MHz

D1(720x480) 2000 Main 8

Table 10. H.264 decoder per formance

As can be seen, if the user terminal is a P-III 800 MHz machine, maximum bitrate for real-time decoding (more than 25fps) is 500 kbps, corresponding to CIF format 352x288. So far, we have described the VCL, which is specified to represent, efficiently, the content of the video data. The Network Abstraction Layer, NAL, is specified to format that data and provide header information in a manner appropriate for conveyance by the transport layers or storage media. All data are contained in NAL units, each of which contains an integer number of bytes. A NAL unit specifies a generic format for use in both packet-oriented and bitstream systems.

STLF-210-REQ MUL.AAV.AVC-60. Transport layer definition

H.264 specifies a generic format for use in both packet-oriented and bitstream transport layer systems.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

121 / 247

The format of NAL units for both packet-oriented transport and bitstream delivery is identical, except that each NAL unit can be preceded by a start code prefix in a bitstream-oriented transport layer.

STLF-210-REQ MUL.AAV.AVC-70. Frame rate

Depending on the codec, frame rate can be specified to a 1/10000 of a second, for exact synchronization purposes. Most applications will make use of 25 fps and 30 fps frame rates, with minor adjustments.

STLF-210-REQ MUL.AAV.AVC-80. Picture resolution

Picture size can be defined in multiples of 16 pixels in each direction. Very often, there is a maximum picture size of 720 x 576 (25Hz) and 720 x 480 (30Hz) for low definition.

STLF-210-REQ MUL.AAV.AVC-90. High definition

As picture size can be customized, high definition sequences may be supported.

STLF-210-REQ MUL.AAV.AVC-100. Encoding delay

The encoding delay is measured between time the frame is sampled at the encoder and the time at which the frame is output from the bit buffer. Encoding delay is equal to number of b-frames between two p-frames. It should be kept low, but trying not to compromise coding efficiency.

STLF-210-REQ MUL.AAV.AVC-110. Bitrate mode

Generally, encoders operate in three modes: QP (fixed quality), VBR (variable bit rate) and CBR (constant bit rate). Depending on the bitrate mode used, different statistical coding may be applied.

STLF-210-REQ MUL.AAV.AVC-120. Dual pass encoding

Many encoders support dual-pass encoding on some levels. In the first pass, the encoder gathers information about the video sequence and uses that on the second pass to improve compression. Only VBR mode can be used with dual-pass encoding.

STLF-210-REQ MUL.AAV.AVC-130. Propr ietary coding tools

Some implementations of H.264 include additional features, like scene change detection, which may improve coding efficiency. This features depend on the precise codec used.

STLF-210-REQ MUL.AAV.AVC-140. Encoder-decoder interoperability

Encoder and decoder should be interoperable, if they are from different developers.

STLF-210-REQ MUL.AAV.AVC-150. Encoding hardware requirements

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

122 / 247

It is highly recommended to use dual memory bus platform with Intel Pentium 4 CPU at 3.0 GHz or more (Hyper Threading support is a big plus) for H.264 encoding. The previuos hardware requirement should serve as an orientation. It specifies the requirements for a common H.264 software codec running on a desk-top computer.

STLF-210-REQ MUL.AAV.AVC-160. Decoding hardware requirements

Minimum hardware requirement for Main profile full 720x480@30fps decoding is Pentium 4 2.4 GHz. Minimum hardware requirement for Baseline profile full 720x480@30fps decoding is Pentium 4 1.6 GHz.

5.2.5 Windows Media In 1991 Microsoft first released digital media operating system software. PCs running the Microsoft® Windows® 3.0 operating system with Multimedia Extensions had barely enough power to play back low-quality audio, and the delivery of even moderate-quality video seemed a distant dream. Since then, processor speeds have increased by a factor of approximately 100. Local storage capacity has increased even more, around 1000 times. High-resolution video monitors are now standard equipment, and high-quality stereo and Dolby Digital 5.1 Surround Sound cards have proliferated, along with speakers to match. The Internet, of course, has also enhanced the utility of the PC, including digital media, in ways not even imagined a decade ago. As it has been shown before Microsoft was one of the first companies to deploy an MPEG-4 Video codec in its Windows Media platform, and has contributed to the MPEG-4 Reference Software. And this is shown in its latest version. Windows Media Audio and Video 9 Series supports discrete digital 5.1 surround sound and high-definition full-screen video quality. The Windows Media Audio and Video 9 Series delivers a good fidelity audio and quality video at any bit rate – from dial-up to broadband, for streaming, download-and-play, and delivery of content on physical media – with compression improvements of 20 percent for audio and 15 to 50 percent for video, compared with Windows Media Audio and Video 8. The most dramatic improvements are seen at higher bit rates. Plug-in models for the player, server, and encoder enable developers to build their own custom digital media solutions and easily extend the entire Windows Media 9 Series platform. A wide range of development systems and programming languages are supported, including Microsoft Visual C++®, Visual C(TM), Visual Basic®, Visual Basic Script (VBScript), and Perl.

STLF-210-REQ MUL.AAV.WM-10. System requirements

The system requirements for a PC using Windows Media player 9 are:

• A Pentium II processor-based PC or compatible computer (233 MHz is required, but 500MHz is recommended).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

123 / 247

• 64 MB of RAM • Win 98SE / Me / 2000 / XP. • Internet Explorer 5.5 or later.

5.2.5.1 Windows Media Encoder Windows Media Encoder 9 Series is a tool for content producers who want to take advantage of the innovations in Windows Media 9 Series including high-quality multichannel sound, high-definition video quality, new support for mixed-mode voice and music content, and more.

STLF-210-REQ MUL.AAV.WM-20. Source files

The encoder can source from files that have the following file name extensions: .wav, .wma, .wmv, .asf, .avi, .mpg, .mp3, .bmp, and .jpg.

STLF-210-REQ MUL.AAV.WM-30. Conversion of MPEG-1 and MPEG-2 files

In order to convert MPEG-2 files, you must have a Microsoft DirectShow® decode filter installed on your computer. The DirectShow decode filter is available from third-party software vendors. You can test the source file by playing it using Windows Media Player 9 Series. If the video does not appear correctly, then the file will not be encoded correctly.

STLF-210-REQ MUL.AAV.WM-40. Convert uncompressed format

The encoder can capture to uncompressed Windows Media Format. This enables creation of high-quality archives that can be reprocessed by the encoder. The encoder can output to the Pulse Code Modulation (PCM) audio format and to uncompressed video. The pixel format used for the video is IYUV (also known as YV12).

5.2.6 Real Media Because the Internet was built to handle text-based information, not audio and video and other rich media, Real Networks, Inc. foresaw the need for specific solutions that could handle the creation, delivery and consumption of media via the Internet. That led RealNetworks, Inc. to invent and release the RealPlayer and RealAudio in 1995. Many video codecs employ “block-based” algorithms to do compression and decompression of video. These algorithms process several pixels of video together in blocks. As the compression ratios increase, these block-based algorithms tend to represent individual blocks as simply as possible. A single block may be represented simply as a single colour (e.g. the entire block is all “ light-blue”). Carefully studying competing video codecs, one can easily see this visual effect (so-called visual “artefacts”). When using block-based algorithms strong discontinuities, so-called block edges, can become very pronounced.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

124 / 247

RealVideo 10 avoids blockiness by employing sophisticated algorithms that are able to more accurately compress the video. New proprietary analysis and synthesis algorithms (transforms), more sophisticated motion analysis, content adaptive filtering technology, and other compression schemes built inside RealVideo 10 allow it to provide a higher fidelity reproduction of the video and maintain a more natural look and feel. RealVideo 10 does no post-processing in the decoder. The core RealVideo 10 algorithms are a significant improvement over existing video codecs. Excellent video quality is achieved without it. RealVideo 10 supports a wide range of video applications from real-time streaming to download and play to storage and archive.

STLF-210-REQ MUL.AAV.RM-10. System requirements

The system requirements for a PC using Real Video player 10 are:

• A Pentium processor-based PC or compatible computer (233 MHz). • 64 MB of RAM • Win 98SE / Me / 2000 / XP / NT( Service Pack 4) • Internet Explorer 5.5 or later.

5.2.6.1 Real Video 10 Encoder RealVideo 10 encoder supports different encoding modes.

STLF-210-REQ MUL.AAV.RM-20. Fixed and var iable bitrate codification

Allows encoded video content to maintain a consistent level of video quality, either by optimising for quality or a target average bitrate.

• Constant Bitrate • Variable Bitrate (with a possible maximum constrained bitrate) • Quality-Based Encoding (with a possible maximum constrained bitrate)

STLF-210-REQ MUL.AAV.RM-30. Two-Pass Encoding

Analyses video content in first pass to determine how best to vary the playback bitrate - most effective with VBR encoding.

5.2.7 Quick Time QuickTime has many applications. It is versatile and rich media for most online digital media. One of the strengths of QuickTime is its ability to import different types of media and export them into other forms. For example, formats such as AVI, MP3, AIFF, WAV, CD audio, DVCam, Text, Photoshop, Gif, JPEG, PNG, MIDI and other media forms can be exported to other forms such as AIFF, WAV, MIDI,

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

125 / 247

QuickDraw, Pictures, Text, and others. You would need a copy of QuickTime Pro to do this and it's a program running on both Macintosh and Windows computers. As it concerns QuickTime VR has the ability to choose different compression formats and quality (for example Sorenson video) give the media author opportunities to tailor VR has for web, CD and other presentation mediums. A frequently used compression format for VR has is Photo-JPEG. This often provides the best quality VR panoramic image for web use. Quick Time is an enabling technology - at the operating system level - that lets other applications (such as QuickTime Player, Word, Excel, PowerPoint, First-Class, and web browsers) display multimedia. A browser plug-in that can handle all can display audio, video, animations, Flash files, music, and interactivity. And a very popular way to put sound and video on the web or on CD-ROM QuickTime files are called QuickTime movies. A QuickTime movie usually is a file with moving pictures and synchronized sound - but it also could be still images with synchronized text; or invisible background music; or karaoke; or many other things. A QuickTime movie is a file that tells a computer what kind of media to present and when to present it. Version 6 was released in July of 2002, and added support for MPEG-4 file format, MPEG-4 Video, AAC Audio. QuickTime media can be compressed in many ways - and compressors keep improving.

STLF-210-REQ MUL.AAV.QT-10. System requirements

The system requirements for a PC using Quick Time player 6.5 are:

• Windows • A Pentium processor-based PC or compatible computer • At least 128MB of RAM • Win 98/Me/2000/XP

5.2.8 DivX

STLF-210-REQ MUL.AAV.DVX-10. Definition

As it has been shown before DivX is an implementation of MPEG-4, in this sense DivX for video shall support:

• MPEG-4 Simple Profile capable (ISO/IEC 14496-2) • MPEG-4 Advanced Simple Profile capable (ISO/IEC 14496-2) • H.263 (decoding only)

And for audio:

• MPEG-layer3 (MP3).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

126 / 247

The file format used is the Audio Video Interleave (AVI) file format.

STLF-210-REQ MUL.AAV.DVX-20. Encoding

DivX can encode in many different ways as: I-VOP, P-VOP, B-VOP, Quality-based encoding, One-pass variable bitrate, Multi-pass encoding (N-passes), Constant bitrate encoding (CBR), High Quality encoding mode, Different motion estimation criteria, Rate distortion algorithm, Video buffer verifier, User-specified keyframe insertion, Automated keyframe insertion, Automated scene detection, Patent-pending rate control algorithm, RC to support real time control through API support, I frame insertion forced through API support, 4 levels of encoding quality, Quarter pel, Global motion compensation, High Quality psychovisual mode, Texture cortex masking and Rate distortion algorithm, Hybrid mode (Texture cortex masking), Patent-pending noise reduction pre-processing, Interlaced video support, Support for DivX Certified Hardware profiles.

STLF-210-REQ MUL.AAV.DVX-30. Decoding

On the other hand the different ways of DivX decoding are: I-VOP, P-VOP, B-VOP, Quarter perl, Global motion compensation, Psychovisual modelling, Post-processing, MPEG-4 short header (H.263 stream), Video packet re-synch markers, Data partitioning, Overlapped block motion compensation, Reversible VLD.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

127 / 247

5.3 STREAMING REQUIREMENTS The basic idea behind streaming is to make video and audio available without requiring clients to wait for the entire file. It's easy to see how this could be a very useful tool when distributing information over vast networks like the World Wide Web. Streaming media has been adopted as an integral part of enterprise network applications including online training, teleconferencing, and shareholder relations Most data networks like the Internet are not designed with audio or video in mind. These media have specific requirements that make them a challenge to distribute. The protocols of the Internet were an intelligent solution to the problem of distributing static files. Unfortunately, audio and video need to be played in a continuous pattern. The data needs to be interpreted in a specific order. Internet traffic is routed through the path of least resistance. Packets often arrive out of order as a result. This presents no problem when and entire file is downloaded. Smart network protocols put the data in the proper order when stored on the client machine. The problems arise when an application like a streaming audio player needs packets in a timely manner. If a file is playing and the necessary packets are not present there will be dropout. Dropout is the scourge of streaming technologies, those annoying breaks in the presentation of video or audio. This is why companies spend all that time and money trying to come up with the best compression and streaming combination. When the player finds that it is missing a needed packet it will either forget about it and move to the next logical packet in the succession, or it will pause and wait for the packet. It depends on which streaming format you are using. Multimedia communication is greatly dependent on good standards. The presence of standards allows for a larger volume of information exchange, thereby benefiting the equipment manufacturers and service providers. It also benefits customers, as now they prerequisite to multimedia communication. Standards for video coding are also required to be efficient for the compression of video content. This is because a large number of bits are required for the transmission of uncompressed video data. Standards define a common language that different parties can use, so that they can communicate with one another. Standards are thus, a prerequisite to effective communication. Video coding standards define the bitstream syntax, the language that the encoder and the decoder use to communicate. Besides defining the bitstream syntax, video coding standards are also required to be efficient, in that they should support good compression algorithms as well as allow the efficient implementation of the encoder and decoder. These standards are mostly developed by two major organization. They are the International Organization for Standardization (ISO) and ITU-T. Both these organizations have defined different standards for video coding, as it has been show before.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

128 / 247

5.3.1 Audio/Video Transport Any of the standards or proprietary solutions that have been shown define a mandatory transport mechanism for coded visual data. However there are a number of possible transport solutions depending on the method of transmission, including the following.

5.3.1.1 MPEG2 Systems Part 1 of the MPEG2 standard defines two methods of multiplexing audio, video and associated information into streams suitable for transmission (Program Streams or Transport Streams). Each data source or Elementary Stream (e.g. a coded video or audio sequence) is packetised into Packetised Elementary Streams (PES) packets, and PES packets from different elementary streams are multiplexed together to form a Program Stream (typically carrying a single set of audio/visual data such a single TV channel) or a Transport Stream (which may contain multiple channels). The Transport stream adds both Reed-Solomon and convolutional error control coding and so provides protection for transmission errors. Timing and synchronisation is supported by a system of clock references and time stamps in the sequence of packets. An MPEG4 Visual stream may be carried as an elementary stream within a MPEG2 Program or Transport Stream.

STLF-210-REQ MUL.STR.MP2-10. Program Stream-Transport Stream

MPEG-2 Systems shall use Transport Stream form in the satellite network.

STLF-210-REQ MUL.STR.MP2-20. Reed-Solomon

In order to prevent and correct transmission errors, MPEG2 Systems uses Reed Solomon.

STLF-210-REQ MUL.STR.MP2-30. FEC-1/2, 3/4, 7/8

In order to prevent and correct transmission errors, MPEG2 Systems uses Forward error correction in different ways, depending on the error probability.

STLF-210-REQ MUL.STR.MP2-40. PCR

• The minimum time between two consecutives PCRs is100 ms. • The maximum jitter shall be 4ms.

5.3.1.2 Real Time Protocol: RTP RTP is the Internet-standard protocol (RFC 1889, 1890) for the transport of real-time data, including audio and video. RTP consists of a data and a control part called RTCP. The data part of RTP is a thin protocol providing support for applications with real-time properties such as continuous media (e.g., audio and video), including timing reconstruction, loss detection, security and content identification. RTCP provides support for real-time conferencing of groups of any size within an internet. This support

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

129 / 247

includes source identification and support for gateways like audio and video bridges as well as multicast-to-unicast translators. It offers quality-of-service feedback from receivers to the multicast group as well as support for the synchronization of different media streams. Transporting a coded audio-visual stream via RTP involves packetising each elementary stream into a series of RTP packets, interleaving these and transmitting them across an IP Network (using UDP as the basic transport protocol).

STLF-210-REQ MUL.STR.RTP-10. UDP por t

No fixed UDP port negotiated out of band.

STLF-210-REQ MUL.STR.RTP-20. UDP por t for RTCP

UDP port for RTCP shall be the UDP port for RTP + 1.

STLF-210-REQ MUL.STR.RTP-30. Media per session

Usually one media per RTP session, this is, two different RTP sessions to transport audio and video.

5.3.1.3 RTSP. Real Time Streaming Protocol In October 1996, Progressive Networks and Netscape Communications Corporation announced that 40 companies including Apple Computer, Autodesk/Kinetix, Cisco Systems, Hewlett-Packard, IBM, Silicon Graphics, Sun Microsystems, Macromedia, Narrative Communications, Precept Software and Voxware would support the Real Time Streaming Protocol (RFC 2326), a proposed open standard for delivery of real-time media over the Internet. RTSP is a communications protocol for control and delivery of real-time media. It defines the connection between streaming media client and server software, and provides a standard way for clients and servers from multiple vendors to stream multimedia content. The first draft of the protocol specification, RTSP 1.0, was submitted to the Internet Engineering Task Force (IETF) on October 9, 1996. RTSP is built on top of Internet standard protocols, including: UDP, TCP/IP, RTP, RTCP, SCP and IP Multicast. Netscape's Media Server and Media Player products use RTSP to stream audio over the Internet.

STLF-210-REQ MUL.STR.RTSP-10. Server And Client

The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on the transport mechanism used to carry continuous media. RTSP is intentionally similar in syntax and operation to HTTP/1.1 so that extension mechanisms to HTTP can in most cases also be added to RTSP. However, RTSP differs in a number of important aspects from HTTP:

• RTSP introduces a number of new methods and has a different protocol identifier. • An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless

nature of HTTP. • Both an RTSP server and client can issue requests.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

130 / 247

• Data is carried out-of-band by a different protocol, in most cases.

STLF-210-REQ MUL.STR.RTSP-20. Operations

The protocol supports the following operations: • Retrieval of media from media server: The client can request a presentation description via HTTP

or some other method. • Invitation of a media server to a conference: A media server can be "invited" to join an existing

conference, either to play back media into the presentation or to record all or a subset of the media in a presentation.

• Addition of media to an existing presentation: Particularly for live presentations, it is useful if the server can tell the client about additional media becoming available.

5.3.2 Digital TV streaming We will state the requirements for streaming digital TV.

5.3.2.1 Encoders A general purpose MPEG-2 encoder for contribution and cable applications provides video and audio output and for composing a set of services for a digital television system.

STLF-210-REQ MUL.STR.DTV-10. MPEG-2 Compression levels and profiles

MPEG-2 4:2:0 MP@ML compression.

STLF-210-REQ MUL.STR.DTV-20. Video Input

High-quality PAL/NTSC video input with sync or direct SDI I/P.

STLF-210-REQ MUL.STR.DTV-30. Audio channels

Audio extension up to 10 stereo channels with Dolby pass-through mode.

5.3.2.2 Multiplexers A multiplexer is a solution for composing a set of services for a digital television system. It can handle up transport streams, ensuring full DVB of output streams. And it could have capability to provide a solution for MPEG-2 local program insertions.

STLF-210-REQ MUL.STR.DTV-40. Program Stream multiplexing

A multiplexer shall multiplex single and/or multi-program streams.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

131 / 247

STLF-210-REQ MUL.STR.DTV-50. Transport Stream support in multiplexing

A multiplexer shall support MPEG-2 transport streams.

STLF-210-REQ MUL.STR.DTV-60. Signalling multiplexing

A multiplexer shall support signalling or trans-signalling of MPEG-2 transport streams.

STLF-210-REQ MUL.STR.DTV-70. Scrambling functions in multiplexer

A multiplexer shall implement DVB common scrambling functions and interfaces to most conditional access (CA) systems. In a DVB system, scrambling can work at either the level of the entire transport stream, or on the level of individual elementary streams. There's no provision for scrambling a service in its own right, but the same affect is achieved by scrambling all of the elementary streams in a service. In the case of scrambled elementary streams, not all of the data is actually scrambled - the packet headers are left unscrambled so that the decoder can work out their contents and handle them correctly. In the case of transport stream scrambling, only the headers of the transport packets are left unencrypted - everything else is scrambled. As well as encrypting the data that's supposed to be encrypted, the CA system adds two types of data to the stream. These are known as CA messages (CAM), and consist of Entitlement Control Messages (ECM) and Entitlement management Messages (EMM). Together, these control the ability of individual users (or groups of users) to watch scrambled content. The scrambling (and descrambling) process relies on three pieces of information:

• The control word • The service key • The user key

STLF-210-REQ MUL.STR.DTV-80. Data injection in multiplexer

A multiplexer shall multiplex data injection and opportunistic data injection features high-speed data insertion and no null packets.

STLF-210-REQ MUL.STR.DTV-90. Bitrate management in multiplexer

A multiplexer shall allow bit-rate management between several content providers sharing the same multiplex

5.3.3 PC streaming There are 3 major and standard file format for video that are widely used, depending on the used platform:

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

132 / 247

5.3.3.1 Microsoft Windows Media, AVI Video (*.avid) AVI is a format for video files that offers minimal compression ability and is available on the Windows platform only. It is widely used on the World Wide Web. Combined with Windows Media Player 9 Series, Windows Media Services 9 Series can provide an instant-on/always-on playback experience for users on broadband networks and an improvement in streaming reliability and responsiveness for dial-up users, virtually eliminating buffering delays and interruption when playing digital media content.

5.3.3.1.1 Unicast Streaming

There are some requirements for unicast streaming.

STLF-210-REQ MUL.STR.WM-10. Enabling a client in unicast streaming

To enable Windows Media Player and other clients to use the Hypertext Transfer Protocol (HTTP), Real Time Streaming Protocol (RTSP), or Microsoft Media Server (MMS) protocols to stream unicast content from a Windows Media server that is behind a firewall, open the following ports:

• In: TCP on por t 80, 554, 1755. The Windows Media server uses the TCP In ports to accept an incoming HTTP connection (port 80), RTSP connection (port 554), or MMS connection (port 1755) from Windows Media Player and other clients.

• In: UDP on por t 1755, 5005. The Windows Media server uses UDP In port 1755 to receive resend requests from clients streaming by using MMSU and UDP In port 5005 to receive resend requests from clients streaming by using RTSPU.

• Out: UDP between por ts 1024-5000. The Windows Media server uses UDP Out ports 1024-5000 to send data to Windows Media Player and other clients.

STLF-210-REQ MUL.STR.WM-20. Enabling a server in unicast streaming

To enable a distribution server that is behind a firewall to use the HTTP or RTSP protocols to stream unicast content from an origin server outside the firewall, open the following ports:

• In: UDP between por ts 1024-5000. The Windows Media server uses UDP In ports 1024-5000 to receive data from another server.

• Out: TCP on por t 80, 554. The Windows Media server uses the TCP Out ports to establish an HTTP connection (port 80) or RTSP connection (port 554) to another server or encoder.

• Out: UDP on por t 5005. When RTSPU distribution is used, the Windows Media server uses UDP Out port 5005 to send resend requests to another server.

5.3.3.1.2 Multicast Streaming

STLF-210-REQ MUL.STR.WM-30. Multicast Streaming

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

133 / 247

To distribute content by using multicast streaming, direct network traffic through the standard Class D IP addresses (224.0.0.0 through 239.255.255.255). To multicast, you must have enabled multicast-forwarding on your network.

STLF-210-REQ MUL.STR.WM-40. Stream profiles definition

• 500 kbps Stream Profile - 320x240 video file suitable for broadband target networks. • 400 kbps Stream Profile - 320 x 240 video file suitable for broadband target networks. • 300 kbps Stream Profile - 320 x240 or 160x120 video file suitable for broadband target networks. • 200 kbps Stream Profile - 320 x240 or 160x120 video file suitable for broadband target networks. • 112 kbps Stream Profile - 160x120 video file suitable for 112 kbps ISDN target networks. • 56 kbps Modem Stream Profile - 160x120 video file suitable for 56 kbps modem target networks. • 28.8 kbps Modem Stream Profile - 160x120 video file suitable for 28.8 kbps modem target

networks. An interesting feature of Windows Media is the possibility of using multi-bitrate encoding and streaming. Using this method of encoding, each different speed version of a video is encoded as part of one single, larger multi-bitrate video file. The larger video file may contain 3, 5, 7 or as many different speed versions as necessary. It is the job of the video server software to determine the connection speed of the user initially and throughout the entire video, and to serve up the appropriate speed version of the video to the viewer. Depending upon the length of the video and the amount of network congestion, the viewer may see a dozen or more changes of the audio and video stream during playback. This means the quality of the video will constantly be changing to accommodate network conditions. The actual size of the window and the quality of the audio is kept constant and as a result sometimes, unnecessarily large. This method of encoding has several advantages, but the server software is often over-sensitive to network conditions, and as a result will stream a lower quality version to the user than need be streamed. Thus, stream server needs to be fine-tuned in order for it to work.

STLF-210-REQ MUL.STR.WM-50. Multi-bitrate encoding

If multi-bitrate servicing is to be supported, the encoder must directly compress contents in a multi-bitrate format.

STLF-210-REQ MUL.STR.WM-60. Multi-bitrate streaming

The video server shall support multi-bitrate and automatically detect connection bandwidth.

STLF-210-REQ MUL.STR.WM-70. Static multi-bitrate support

As well as adaptive, auto-detectable multi-bitrate support, the video server shall allow the streaming of a single level of quality on a static manner.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

134 / 247

5.3.3.2 Apple QuickTime, Darwin Streaming Server (*.move) QuickTime is the multi-platform industry-standard multimedia architecture used by software tool vendors and content creators to create and deliver synchronized graphics, sound, video, text and music. Developed by Apple, it has become one of the most widely used formats on the World Wide Web. QuickTime movies can be compressed using software packages such as Adobe Premiere of Media Cleaner Pro to sizes that are feasible for use over the Internet. Darwin Streaming Server, the open source version of Apple’s QuickTime Streaming Server technology that allows you to send streaming media to clients across the Internet using the industry standard RTP and RTSP protocols. Based on the same code base as QuickTime Streaming Server, Darwin Streaming Server provides a high level of customisability and runs on a variety of platforms allowing you to manipulate the code to fit your needs.

STLF-210-REQ MUL.STR.QT-10. Stream profiles definition

• 1.5 Mbps Stream Profile - 320x240 video file with near CD quality audio for broadband target networks.

• 600 kbps Stream Profile - 320x240 video file with high radio quality audio for broadband target networks.

• 384 kbps Stream Profile - 320x240 video file with radio quality audio for broadband and narrowband target networks.

• 128 kbps ISDN to 28.8 kbps Modem Stream Profile - 160x120 video file with radio quality audio for 128 kbps ISDN down to 28.8 kbps Modem target networks.

• 56 kbps Modem Stream Profile - 160x120 video file suitable for 56 kbps modem target networks. • 28.8 kbps Modem Stream Profile - 160x120 video file suitable for 28.8 kbps modem target

networks.

5.3.3.3 Real Video Real Video is a format that is used over the Internet. Real Video uses a special player that can be freely downloaded over the Internet. It allows for "streaming," meaning that the movie can be played while it is being downloaded. The format uses heavy compression, and a special server is used to "stream" the files to clients. The end result is a format that can be utilized over the Internet by those with low bandwidth (modem) connections. Helix™ from RealNetworks is a universal digital media delivery platform. With industry-leading performance, integrated content distribution, advertising, user authentication, Web services support, and native delivery of RealMedia, Windows Media, QuickTime, and MPEG-4, Helix from RealNetworks is a robust digital media foundation that meets the needs of enterprises and networking service providers.

STLF-210-REQ MUL.STR.RV-10. Stream profiles definition

• 500 kbps Stream Profile - 320x240 video file suitable for broadband target networks.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

135 / 247

• 400 kbps Stream Profile - 320 x 240 video file suitable for broadband target networks. • 300 kbps Stream Profile - 320 x240 or 160x120 video file suitable for broadband target networks. • 200 kbps Stream Profile - 320x240 or 160x120 video file suitable for broadband target networks. • 112 kbps Stream Profile - 160x120 video file suitable for 112 kbps ISDN target networks. • 56 kbps Modem Stream Profile - 160x120 video file suitable for 56 kbps modem target networks. • 28.8 kbps Modem Stream Profile - 160x120 video file suitable for 28.8 kbps modem target

networks.

STLF-210-REQ MUL.STR.RV-20. Multi-bitrate streaming

Just as Windows Media, Real Media supports multi-bitrate encoding and streaming. This feature is named “SureStream”, and is very similar to Windows Media’s multi-bitrate. Video shall be encoded with this feature, and the video server shall support it, statically and adaptively.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

136 / 247

6. MANAGEMENT TOOLS REQUIREMENTS Service Management is defined as the set of mechanisms for provisioning new subscribers and service providers, controlling network feature delivery, advertising new services and applications and collecting the application data necessary to generate billings. These mechanisms need to interface with a well-defined data repository. In addition to standard protocols used within the network to facilitate feature delivery, a set of end user signalling protocols are needed to permit subscribers and service providers to request network features and resources. The architecture proposed in this document clearly needs management and control systems to configure the underlying network service features or “building blocks” .

Figure 21. Architecture layers

To support new services and their underlying service features requires a new set of network management and control interfaces. In this working text, we use the term “network management” when talking about the provisioning of services, which typically happens at a relatively long time-scale. “Network control”

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

137 / 247

refers to a real-time capability of the network to react to specific service requests. In all cases, appropriate billing records will need to be created for a wide variety of service features and services usage. These billing records will need to be created for static as well as dynamic usages.

6.1 MANAGEMENT REQUIREMENTS Service management enables service providers to manage the quality of their services as perceived by the customer. It ensures that services delivered to the customer are functioning to specifications. As the market continues to evolve and competition reaches new highs, the average revenue per user (ARPU) is continuously being driven down. Service providers need to reduce revenue loss and maximize their operational efficiencies to minimize or pre-empt the problems that are affecting their customers. To leapfrog the competition and to gain new, loyal customers, service providers are differentiating themselves by broadening their service portfolio and assuring that the quantity and quality of their services are superior to their competition. Moreover, with the increasing complexity and sophistication of today’s networks, it is no longer acceptable to just manage the network. For instance, from a network-management-system-monitoring perspective, the network may appear to be performing just fine, but devices may be misconfigured or may not be performing well enough to support the end services. Alternately, devices may fail, but redundancy devices and re-routing paths may continue to support the services. So, even though the customer may be impacted, the problem is not immediately apparent or it is not assigned high priority status. Most carriers already have an existing network management strategy but to gain further operational efficiency they are moving from a network-centric operation to a service-centric culture. Service management is the next stage in the evolution of operations support system (OSS) assurance management. Service providers are establishing service operation centers (SOCs) and co-locating them with their network operational centers (NOCs), for higher visibility into key service and customer account problems, enabling more proactive management and quicker service problem isolation and resolution. Service management provides a centralized view of consolidated data for a complete picture of the end-to-end services as well as the customers being supported by the network. Data is collected and correlated from various key sources into a single, intelligent graphical display. Key data sources include: · Trouble tickets · Active tests · Fault · Performance · Probe · CDRs · Inventory · Other in house systems (i.e., customer database) As an example, CDRs can be monitored so if there is a large dip in usage it may be an indication that there is a problem with users accessing or using the service. Another key data point is an increase of trouble tickets being reported on a service.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

138 / 247

Data is aggregated, weighted, propagated and correlated over a service topology (object model). This provides the end user with a high level view of the services, complete with summarized indicators for both performance and alert states. A “ three-layer logical/functional architecture” can be used as the base architecture to support the delivery of advanced QoS-enabled services. This approach is sufficiently generic to support a wide range of advanced services. In the previous figure, the three-layer logical architecture for support of services such as media-on-demand or conversational services is shown. It identifies the following layers: - The network layer : This layer has to support predictability, reliability and QoS enforcement - The “ common enabling services” layer : This layer provides a set of “common enabling services” that can be used by or shared among various applications and/or ASPs. Some of these services may be linked to the NCC (and to be provided by them in a mandatory way), while others may be provided by the NSP or ASP, depending on the business model chosen. The services are represented as “ logical functional blocks” , without specifying how or where these services are implemented. Various network elements may be used to implement any or all of these services, depending on the specific instantiation of the three-layer architecture. It is at this layer that the common data repository used by the network and application control planes will be found. - The application layer : This layer interacts with the “common enabling services” layer. For example, for conversational services, this layer could be implemented through a SIP server, while for media-on-demand one could implement a video-on-demand portal. Subscribers will directly interact with the application layer through a number of different protocols. Typically, only the ASP is assumed to be aware of the application-layer interaction. The three-layer architecture is a logical architecture, showing the mandatory and optional functions present in each layer of the architecture for advanced QoS-enabled services delivery. The architecture does not mandate that the implementation of any of these functions must be done in any specific network element in the actual network instantiation.

6.1.1 Requirements for “ common enabling services” for the Network Provider

STLF-210-REQ MGT.MGM.CES-10. Network and element management

This is an essential service in order to provision and monitor the network. Usually within this realm, the operator may define and provision different classes of traffic that will be available to interconnect subscribers to NSPs and ASPs. Additionally, QoS monitoring and SLA verification can be expected to become even more important.

STLF-210-REQ MGT.MGM.CES-20. Network Resource Control

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

139 / 247

This is an essential service in order to be able to set policy rules for traffic coming from different ASPs (which in turn allows for enforcement of the business model) and to avoid conflicts in traffic going to and coming from subscribers in a generally bandwidth-constrained environment. Network Resource Control allows support for Bandwidth and/or QoS on Demand. The requests for bandwidth usage can come from multiple sources, e.g. the application layer provided by the ASP, or the subscriber.

STLF-210-REQ MGT.MGM.CES-30. Accounting/Billing

Network Resource Control is an active part of the business enforcement process and therefore likely linked to an accounting system that will keep track of the ASP’s and/or subscriber’s network usage, both from a static (provisioned) and dynamic (“on demand”) point of view. It is expected that some services will be offered for a fixed fee, no matter how long the service duration or how many times the service is used in a month (or other fixed timeframe), while other services will be charged on a “per hour” or “per usage” basis. The Accounting / Billing system needs to be capable of capturing and reporting all these events.

STLF-210-REQ MGT.MGM.CES-40. Common Data Model

Managing the service includes keeping track of the parameters associated with subscribers and service providers. This can be done by means of a common data model, stored in a data repository. This is a shared resource, controlled by the NCC, and accessed by ASPs, NSPs, and end users. It will contain control values used by the all these entities when offering value added services. For example, the end user’s maximum sustainable line rate will be stored here and can be used to permit access to high bandwidth applications. If the end user’s satellite line is not capable of a sustained bandwidth of 1Mbps, it makes no sense to permit the end user to order a streaming movie that requires 1.5Mbps. Likewise, if there are contractual relationships with one service provider that prohibit an end user from accessing certain other service providers, this will also be tracked in the data repository.

6.1.2 Requirements For Optional “ Common Enabling Services” For The Network Provider The following (non-exhaustive) list of services could be provided through either the network provider(s) or the ASPs. The implementation of these services on a given access network could obviously be different for different applications and/or ASPs:

STLF-210-REQ MGT.MGM.CES-60. Authentication, Author ization, and Accounting

Conceptually similar to AAA used for high-speed Internet access today, but some changes may be needed due to the introduction of QoS-enabled services. Given that many ASPs don’ t want or need to support IP addressing, the Network Access Provider will need to create the infrastructure to provide basic network connectivity, including network authentication and IP address assignment and administration.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

140 / 247

STLF-210-REQ MGT.MGM.CES-70. Accounting And Billing

The network provider could either be accounting for the usage that ASPs are making of its infrastructure (e.g. volume based accounting) or do the billing function on behalf of some of the ASPs (e.g. content-based accounting and billing) that do not wish to engage in that process;

STLF-210-REQ MGT.MGM.CES-80. Digital Asset Management

The network provider could choose to include content distribution nodes (e.g. for audio and/or video) in its network and may require to actively manage the content over these nodes;

STLF-210-REQ MGT.MGM.CES-90. Content Integr ity And secur ity and Digital Rights Management

This service makes sure that the content is delivered in a secure way to the end user in an acceptable way for the content owners.

STLF-210-REQ MGT.MGM.CES-100. Service Level Management

The data collection portion of an overall service level agreement system is located at this layer. It is this data, coupled with reporting and billing mechanisms that could be used to document network performance in relation to contractual guarantees. It is currently unsure what level of optional services network providers will commonly implement in the near future. Moreover, various ASPs may have different strategies in teaming up with network providers. Nevertheless, a number of mandatory services are tied to the network provider regardless of the business model. The most realistic approach consists in focusing initially on these services, that a network provider has to bring to deliver the QoS-enabled services. Without any doubt, the differentiation and enforcement of the new QoS-enabled services brings some new challenges; specifically, the Network Resource Control service is the crucial piece to cater to the different applications and/or ASPs and to inform the accounting process if required.

STLF-210-REQ MGT.MGM.CES-120. Flexible Mix Of The Enabling Services

Ultimately, the goal of this architecture is to enable an Access Network to deploy a flexible mix of the enabling services. This mix can be different depending on the application considered and therefore, this framework should ultimately be open to accommodate different business models applicable to different ASPs. Many of the functionalities required (AAA, billing, resource management) are replicated in each business entity or exist in multiple layers in the architecture and in the supply chain suggesting that an element of recursion may be necessary when a service is requested.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

141 / 247

There may be multiple entry points into the supply chain depending on the services that each entity offers. There can be a retail relationship between the subscriber and the Network Provider. Likewise, the retail relationship may be between the subscriber and the Service Provider, with a corresponding wholesale relationship between the Service Provider and the Network Provider. This triggers a number of actions (some of which may be null functions). · The service request is authenticated and authorized. · Resources to provide the service are allocated. The resource allocation process may recurs as the service entity obtains services from subsidiary entities in the supply chain. This is especially true when the subscriber requests a service from the Service Provider who, in turn, needs to issue a complementary request to the Network Provider. · Service assurance information is collected from the service infrastructure, and subsidiary service entities. · Billing information is logged for future billing and settlement. Understanding how each service entity in the food chain will have common functional requirements for interactions for both initial service invocation, service assurance and billing and settlement will guide the evolution of the requisite interfaces.

6.1.3 Requirements For End To End Service Provisioning

6.1.3.1 Definition Of Type Of Service

STLF-210-REQ MGT.MGM.E2E-10. Asymmetr ic Services

It is common to enable services which require asymmetric bandwidth definition, thus, where required downstream bitrate is higher than upstream bitrate.

STLF-210-REQ MGT.MGM.E2E-20. Service Speeds

Availability of several rates of connection, due to the different requirements of different kinds of applications.

STLF-210-REQ MGT.MGM.E2E-30. Usage Caps

It could be necessary to have a policy to limit the user bandwidth when he/she uses more bandwidth during a fixed period of time than the maximum bandwidth permitted.

6.1.3.2 Subscribers Because of the changes in how the services are provisioned and managed, there are a number of new data points that must be tracked for each subscriber. Among these are:

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

142 / 247

STLF-210-REQ MGT.MGM.E2E-40. Maximum sustainable subscr iber bandwidth

A maximum sustainable subscriber bandwidth is to be defined, in order to correctly manage the whole capacity of the system.

STLF-210-REQ MGT.MGM.E2E-50. Maximum number of sessions allowed per subscr iber

Each user will not be able to open more than a certain number of sessions simultaneously, so as to establish a whole maximum number of connections.

STLF-210-REQ MGT.MGM.E2E-60. Permitted destinations for subscr ibers

Some destinations might be unavailable to the user, while others can be properly accessed, which implies that a list of permitted and forbidden destinations has to be created.

STLF-210-REQ MGT.MGM.E2E-70. Default protocol for subscr ibers

A certain protocol will be the default one for the user to communicate with the net. Mainly TCP/IP.

STLF-210-REQ MGT.MGM.E2E-80. Default destination for subscr ibers

A certain destination may be defined to be chosen by default, or as the startup destination for end users in their sessions.

STLF-210-REQ MGT.MGM.E2E-90. Default subscr iber bandwidth

Bandwidth also may be chosen by default, and allow changes only if needed because of the particular characteristics of the service or application in use.

STLF-210-REQ MGT.MGM.E2E-100. Single host or subnet needed for subscr ibers

It is necessary to assign just a single host or subnet per user, in order to limit the whole number of hosts in the net.

STLF-210-REQ MGT.MGM.E2E-110. Restr icted subscr iber (single destination only)

Some subscribers may be appropriately defined as restricted subscribers, which means that they can reach just a single destination defined in the service.

STLF-210-REQ MGT.MGM.E2E-120. Total subscr iber reserved bandwidth

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

143 / 247

Total reserved bandwidth is the whole limit of the system capacity, and cannot be surpassed in any case.

6.1.3.3 Service Providers Because of the changes in how services are provisioned and managed, there are more details needed per Service Provider. When various choices listed for an option, these are to be considered as examples only and not a definitive list of the choices for a given option.

STLF-210-REQ MGT.MGM.E2E-130. Minimum bandwidth needed for service providers

Service providers may require a minimum bandwidth to offer their product, so the system is required to provide a certain minimum bandwidth for service provider connections.

STLF-210-REQ MGT.MGM.E2E-140. Minimum QoS character istics for service providers

Service providers may require not only a minimum bandwidth but also a minimum definition of Quality of Service, which has to be clearly defined.

STLF-210-REQ MGT.MGM.E2E-150. Var ious protocol metr ics for service providers

Several protocol metrics will be available for service providers.

STLF-210-REQ MGT.MGM.E2E-160. Subscr iber protocol (e.g. IP, PPPoE)

Service providers require a protocol to be defined for end users in order to offer their end-to-end service provisioning.

STLF-210-REQ MGT.MGM.E2E-170. Service provider protocol (e.g. IP, L2TP, ATM)

A protocol is to be defined at the service provider side, too.

STLF-210-REQ MGT.MGM.E2E-180. Service provider authentication

In the service provisioning paradigm it is fundamental to provide some kind of authentication protocol definition for service providers, to make sure end users are correctly logged in and to prevent security issues in the system.

STLF-210-REQ MGT.MGM.E2E-190. IP address assignment for service providers

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

144 / 247

In case of using IP protocol for the end to end service provisioning, an IP address assignment is to be made. Service providers will have a range of IP addresses available for their use and assignment to subscribers, which may be managed dynamically, by the means of any common-use assignment protocol, or statically.

STLF-210-REQ MGT.MGM.E2E-200. Service provider transport

A transport protocol is to be chosen in order to provide a correct transport layer service depending of the required characteristics.

STLF-210-REQ MGT.MGM.E2E-210. Maximum simultaneous sessions

The number of concurrent sessions could be limited to a maximum.

6.2 MONITORING REQUIREMENTS The monitoring system monitors the performance, detects bottlenecks, and reports on the availability of systems:

STLF-210-REQ MGT.MON-10. Changes in the hardware error count of devices

For monitoring purposes, changes in the hardware error count of devices is to be defined.

STLF-210-REQ MGT.MON-20. CPU and memory

CPU and memory capability are required to be appropriately followed by the monitoring system.

STLF-210-REQ MGT.MON-30. Process availability

The availability of processes for all the agents in the network at any particular time is also a point which needs monitoring.

STLF-210-REQ MGT.MON-40. Disk states

Disk states, their contents, availability, running status and the like, are to be monitored by the monitoring system.

STLF-210-REQ MGT.MON-50. Disk free space

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

145 / 247

In particular, free space available in system disks is a point to which monitoring should pay special attention.

STLF-210-REQ MGT.MON-60. Cluster transitions (addition and removal of cluster members)

The monitoring system should be on the lookout for cluster transitions, i.e., addition and removal of cluster members.

STLF-210-REQ MGT.MON-70. CPU utilization

The degree of CPU utilization at every moment is another issue to be carefully monitored by the monitoring system.

STLF-210-REQ MGT.MON-80. Memory utilization

Just as the CPU utilization, it is important to monitor memory utilization.

STLF-210-REQ MGT.MON-90. Page and Swap file utilization

Another scarce resource to be managed and monitored is the page and swap file, whose degree of utilization and availability are to be measured and followed.

STLF-210-REQ MGT.MON-100. Throughput on LAN devices

LAN devices are common on most networks, and the throughput, i.e. speed of traffic flowing through them at every moment, can be easily measured and monitored. This parameter must be included in the monitoring requirements, to check possible bottlenecking at these points.

STLF-210-REQ MGT.MON-110. Direct I /O and queue lengths on disks

Another parameter to be measured in order to establish disk resource availability is direct input/output and queue lengths on disks.

STLF-210-REQ MGT.MON-120. Looping processes

The monitoring system has to be specially careful about looping processes, because of their particular characteristics and usage of resources.

STLF-210-REQ MGT.MON-130. Processes in var ious wait states

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

146 / 247

Processes can be in different wait states, an issue that has to be checked by the monitoring systems, to measure the degree of utilization of machines.

6.2.1 Levels And Uses Of Per formance Measurement Information Different management tiers need different kinds of information to make decisions. IT’s performance value to the customer-facing pieces should be assessed at all three levels, with the objective of developing a robust three-tier measurement system concentrating on the "vital few" indicators that will indicate alignment with enterprise goals.

STLF-210-REQ MGT.MON.LEV-10. Policy-or iented supplementary data

At the Enterprise Tier, IT performance and measures focus on mission results, or how well IT is meeting its purpose in supporting enterprise-wide goals and objectives. Reports generally highlight policy-oriented information showing areas of progress, problems, and contextual or explanatory information to supplement the performance data.

STLF-210-REQ MGT.MON.LEV-20. Specific Units or Processes per formance

At the Functional Tier, senior and mid-level managers want to know how specific units or processes are performing. Measurement often covers specific IT processes, portfolios, service lines, or applications development programs. Detailed performance information is used for management and improvement of operations and integrating activities across IT processes and programs.

STLF-210-REQ MGT.MON.LEV-30. System or project per formance

At the Project Tier, the measurement emphasis is generally on individual systems performance and individual project progress. Highly detailed tactical and execution information supports immediate day-to-day decision-making on priorities, adjustments, and resourcing.

6.2.2 Recommended IT Customer Facing Performance Measures Under the current business model, most customers initially interface with provider through one of three ‘customer contact points” . IT provides a variety of important services to these customer contact points.

STLF-210-REQ MGT.MON.CF-10. Web site customer contact points

Customers may interface with provider via a web site, a contact point which is everyday more popular and has to be carefully managed and whose performance should be measured.

STLF-210-REQ MGT.MON.CF-20. Call Centers customer contact points

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

147 / 247

Another point where customers may contact their providers is a Call Center, so this should be also taken in account.

STLF-210-REQ MGT.MON.CF-30. Field Engineers customer contact points

Field Engineers in direct contact with the customer are the third possibility in IT Customer facing.

STLF-210-REQ MGT.MON.CF-40. Data network connectivity

The first thing to be provided to IT Customer facing points, whatever they might be, is the need of data network connectivity.

STLF-210-REQ MGT.MON.CF-50. Remote network access

Remote network access is the possibility to connect to the network from a remote point. This is another requirement to deal with.

STLF-210-REQ MGT.MON.CF-60. Database integr ity and reliability

IT Database has to comply with integrity and reliability requirements, in order to have an appropriate performance in interfacing with the customers.

STLF-210-REQ MGT.MON.CF-70. Customer identification and transaction/order ing applications

Appropriate applications for customer identification, transaction and ordering have to be provided. These applications are specific to the particular contact point to be considered, i.e., web sites should be correctly designed for the user to interface with it, and Call Centers and Field Engineers have to be equipped with appropriate technology to cover this issue.

STLF-210-REQ MGT.MON.CF-90. Global messaging

Some kind of global messaging system has to be implemented to simplify the labour of customer contact points.

STLF-210-REQ MGT.MON.CF-100. Web site technical per formance

Web site has to be correctly designed, revised and beta tested to make sure its technical performance is appropriate and thus the customers won’ t get stuck in their use.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

148 / 247

Additionally It’s quality of support (responsiveness, knowledge, interpersonal skills, etc.) towards these customer contacts points directly contributes to their ability to better serve the customer.

STLF-210-REQ MGT.MON.CF-120. Cr itical application reliability

Critical applications, which may include operator applications for transactioning, ordering, etc., must be designed under parameters of reliability, so a mean time between failures and a maximum time to repair, or equivalent reliability measures, should be established to keep service into good standards.

STLF-210-REQ MGT.MON.CF-130. Web site per formance

The web site has to be performanced, not just in technical parameters as we stated before, but also from a general scope of categorization.

STLF-210-REQ MGT.MON.CF-140. Message transit time

Message transit time should be appropriately bounded, in order to keep overall servicing time inside a low ratio.

6.2.3 Multipurpose probes It is mandatory to be choosy when deciding what information should be gathered, when it should be collected, and from which part of the infrastructure. A top-down approach should be adopted because while it is possible to collect hundreds of metrics on the network and particular servers, not all of those metrics are useful in managing service performance. Service providers should focus on business needs instead of trying to collect every piece of data that can possibly be collected. In essence, we want to have an abstract view of the service, we want to answer generic questions such as: Is the quality of service that the ISP is providing to its customers adequate? Yes or no. At this point, we are not particularly interested in the cache-hit ratio of an obscure back-end Oracle database. In fact, the notion of an abstract service model is central to this work. A service model encapsulates the expert’s knowledge of the configuration and dependencies of a service and as a result, facilitates diagnosis by providing structure to the diagnostic process. Each service should be represented as a tree-like structure. The service model gives a top down definition of the various aspects of the service. Dependencies, relationships, and actual measurement data are brought together to form a complete picture of what makes up a service. At the root of this hierarchical model is the service itself, followed by the nodes which implement the service. At the leaf nodes of this service tree are the actual measurements that monitor fundamental aspects of the health and performance of each basic component of the service. Correlation of states based on the service model enables root-cause diagnosis.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

149 / 247

A key feature of this service model is its service-based nature. Most network management products offer a hardware-based view of the systems. Our application, in contrast, presents operators with a service-based view. Suddenly, they can manage their business operations – not just their underlying networks and system infrastructures.

STLF-210-REQ MGT.MON.PRB-10. Active probes

Active measurements stimulate traffic to networks, servers, and service applications to assess various metrics of interest about these elements.

STLF-210-REQ MGT.MON.PRB-20. Passive probes

Passive measurements utilize instrumentation built into network, server, and service application components. Since they do no not require the explicit stimulation of traffic, these measurements have minimal impact on ISP.

STLF-210-REQ MGT.MON.PRB-30. Network probes

A network probe is installed on each LAN segment of the ISP infrastructure. This probe captures all the messages it sees and associates a time-stamp with each message. All messages belonging to the same transaction share the same globally unique ID. Therefore, it is possible to detect transactions and monitor their response times. The network probe captures Ethernet frames coming from or going to a given host. These frames are then parsed into HTTP packets and messages. This probe is composed of two parts: a component in the user space (i.e. a Win32 application) and a component working at the Network Driver Interface Specification (NDIS) layer. The NDIS component binds to a network adapter and can monitor all the traffic the network adapter processes.

STLF-210-REQ MGT.MON.PRB-40. System and process probes

A system probe is installed on each machine of interest. This lightweight probe can collect any performance data that is stored in the registry. For a particular monitoring application, we were gathering performance data (processor, memory, disk, and network I/O) on the following components: the machine as a whole, and three processes: vPOS engine, web server and back-end database. Also a passive probe could monitor some specific performance counters like the cache-hit ratio, I/O transactions, I/O page reads, and user connections.

6.2.4 QoS assurance Negotiation over quality of service (QoS) is an important and challenging requirement of data intensive distributed system. As the nature of the negotiation process, which involves a series of message

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

150 / 247

exchanges, it is merged into the notification service context. In this point we deal with negotiation over QoS support in terms of a negotiator (QoS requester) wishing to receive notifications of a minimum quality and a negotiator (QoS provider) that can generate notifications possibly of varying quality.

STLF-210-REQ MGT.MON.QOS-10. Quality of service

The term Quality of Service (QoS) denotes various non-functional characteristics, such as availability, performance, reliability and security.

STLF-210-REQ MGT.MON.QOS-20. QoS negotiation

QoS negotiation is the process by which an agreement or a deal on the content of QoS is to be achieved between the two or more parties. Any application or object that confers with another or others applications or objects in order to come to terms or reach an agreement over QoS. A negotiator must have knowledge of QoS definition, negotiation protocol and ability to participate in a negotiation process. The negotiator who makes QoS request is requester, the one who provides QoS is requestee.

STLF-210-REQ MGT.MON.QOS-30. Negotiation protocol

Negotiation protocol is a protocol allowing negotiators to negotiate QoS options between themselves. A proposal is sent by QoS requester to request the QoS that the QoS requestee is willing to accept in an agreement. A revision is issued by QoS requestee in response to a proposal. It may contain all the QoS options that the QoS requestee supports, or a subset of the QoS the requestee can offer based on its business policy.

STLF-210-REQ MGT.MON.QOS-40. Agreement

An offer acceptable for both QoS requester and requestee involved in the QoS negotiation.

STLF-210-REQ MGT.MON.QOS-50. Data persistence

The system should implement a data persistence mechanism to guarantee all the negotiated QoS.

6.2.5 Service requirement for Monitor ing unit The services considered imply additional requirements for the monitoring unit, which will be next stated.

STLF-210-REQ MGT.MON.SRV-10. Input

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

151 / 247

The input shall be a Live MPEG2 Transport Stream (SATLIFE downlink), an MPEG2 Transport Stream file or an H264 raw byte file.

STLF-210-REQ MGT.MON.SRV-20. H264 raw byte file

H264 raw byte file shall conform to the following specifications: • File containing a video component compliant with 14496-10 standard in raw byte or MPEG2

Transport Stream. • Raw byte file shall contain data in NAL units preceded by a start code prefix

(compliant with 14496-10 Annex B) • MPEG2 Transport stream file shall contain correct PSI (compliant with MPEG2 standard). At

least, a PAT which is refencing a PMT, which is itself referencing a H264 component. • Expected Rate : CBR, between 1 and 2 Mbits (will be communicated by GUI or additional file) • Frames : I, P • Progressive video (interlaced not supported) • Video component : YUV 4:2:0 • GOP every second (around each 24/25 frames) • I frame = IDR frame (Intra / Instantaneous Decoder reference) • SPS/PPS before IDR (Sequence Parameter Set / Picture Parameter Set) • Audio : Dolby AC3, MPEG Layer II, AAC (HE-AAC not supported)

STLF-210-REQ MGT.MON.SRV-30. Analysis and display

Analysis and display shall consider the following features: • PSI hierarchic view • TR 101 290 analysis (P1, P2) • Frame decoding : I, P, main profile, SDTV • Macro block partition grid • Macro block type display • Slices display • Motion vector display • Frames & slices characteristics • Zoom (1/2, 1, 2, 4)

STLF-210-REQ MGT.MON.SRV-40. Output

The monitoring unit shall support the following output features: • TS Trimming feature (I frame accurate) • ES extraction

6.3 OPERATION REQUIREMENTS This chapter describes the procedures and requirements that have to be met in order to appropriately maintain the system. These are support features, which cover service level agreements, network measuring tools and general software/hardware procedure specifications.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

152 / 247

6.3.1 Service Level Agreements Service Level Management is the combination of these processes/actions that make sure that the Application will experience the desired behaviour, i.e. making sure the requested Service Level Agreement (SLA) is met. This is achieved by first mapping the SLA to the actual network/device specific configuration parameters, configuring the network with this information and then monitoring that the desired behaviour is achieved (i.e. Service Assurance). Service Level Management is likely to be a dynamic process. This is due to the fact that the configuration-monitoring-checking process is inherently a control process with a feedback loop. Service Level Management is intended to provide 3 levels of benefit – increasing over time:

• To provide a list of the salient network performance and operational metrics that might be used in a Service Level Objective (SLO) or Service Level Agreement (SLA).

• To provide a standard definition of such metrics so that the meaning would be common when used by various providers.

• To provide boundary condition service metrics that are driven by architectural considerations where applicable. For example, while it is NOT the intention of this document to set the SLO or SLA for Network Delay (Latency), any network that purports to support Voice over IP (VoIP) will need to have a maximum delay that is within the bounds necessary to support VoIP.

6.3.1.1 Network Performance Metrics

STLF-210-REQ MGT.OP.SLA-10. Network availability

The percentage of time that the NCC is available for subscribers to connect. This metric is defined on some time basis, such as a month, a week, or a year. An SLA should also specify not the entire network but the section of the network for which the NCC is responsible. For example, the NCC is not responsible for NSP problems.

STLF-210-REQ MGT.OP.SLA-20. Network Delay

The time it takes for a data packet to traverse the NCC, from end-to-end or edge-to-edge. Latency is defined in milliseconds and can be a one-way or round-trip delay.

STLF-210-REQ MGT.OP.SLA-30. Message Delivery

The ability of the NCC to transmit traffic at the negotiated speed. Some applicable measurements are packet loss. These metrics must have a time base as well.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

153 / 247

6.3.1.2 Operational Metrics

STLF-210-REQ MGT.OP.SLA-40. Mean response time

The time it takes the NCC to respond to submitted reports of trouble shall be kept to minimum.

STLF-210-REQ MGT.OP.SLA-50. Mean time to restore service

The measurement of the NCC’s ability to restore service within the negotiated interval.

STLF-210-REQ MGT.OP.SLA-60. Order ing system reliability

The measurement of the consistent availability of ordering system.

STLF-210-REQ MGT.OP.SLA-70. End-user installation guarantee

The measurement of the NCC's ability to meet negotiated order due dates. Service Level Management functionality must gather data from several key network elements. Knowing which element is dropping frames or discarding cells can dramatically reduce the time to repair a network. This data collection effort is also a key to generation of reports that are used to show whether the network has met or failed to meet contractual obligations for service delivery.

6.3.2 Procedures

STLF-210-REQ MGT.OP.PRO-10. NOC

All equipment needs to be monitored by an automatic monitoring system at a 24x7 staffed Network Operations Center (NOC). The NOC needs to act as a call center for problem reporting and is responsible for contacting the appropriate support personnel when a problem is reported.

STLF-210-REQ MGT.OP.PRO-20. Change initiation

Requests for changes or other work should generally be initiated through some type of work-request system that records and tracks the requested work. Such a system is also used to assign personnel who will make the requested changes and to record the progress of the work.

STLF-210-REQ MGT.OP.PRO-30. Change author ization

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

154 / 247

For each support/maintenance function, procedures need to be established about who can make what changes and when. Generally, only a team's lead person should authorize a change unless there is an emergency case or the lead team person has made alternative arrangements.

STLF-210-REQ MGT.OP.PRO-40. Change scheduling

Change-scheduling procedures need to be established to specify when changes can be made. Generally, changes are made only during the defined change-windows, except when special circumstances arise that require changes during other times. Usually, change-windows are well-defined time periods during off-peak work hours, such as in the mornings before regular working hours and/or on weekends. In general, no more than one significant change should be scheduled during a single change-window. Furthermore, sufficient time should elapse to assure validation of each change before another change is installed. The duration of the elapsed time is dependent upon the magnitude of the change. In some cases, very small configuration changes do not need to be scheduled in advance. However, change-notification is required upon completion of the change.

STLF-210-REQ MGT.OP.PRO-50. Change notification

Procedures and notification lists should be established and used to provide adequate notification of pending changes. Notification should also be given after a change is made. The amount of lead time of a change-notice is generally dependent upon how "big" a change is, the expected duration of disruption, the expected magnitude of the disruption, and the probability that the change might cause continuing problems and have to be quickly backed out. In some cases, very small configuration changes may not require advance change-notification. However, change-notification would be required upon completion of the change.

STLF-210-REQ MGT.OP.PRO-60. Configuration change log

The Provider will maintain, annotate, and publish a log to track configuration changes made by the Provider and external support entities (ISPs, LECs CLECs, etc.). At a minimum, the log will specify the date and time of the change, the nature of the change, impact of the change (system-wide impact or specific institution impact), and the name of the engineer or entity making the change. The Provider will publish this log online so primary members may periodically review it. It is highly recommended that primary members create and maintain a similar log that reflects configuration changes made at their institutions or changes made to support their secondary members.

STLF-210-REQ MGT.OP.PRO-70. Automatic configuration archiving

Configuration management should include some system that assures that all modified configurations are automatically archived. Configuration archiving should utilize some type of version-control facility such as Cisco RME.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

155 / 247

STLF-210-REQ MGT.OP.PRO-80. Configuration change

For every configuration change, no matter how big or small, a procedure needs to be established to address the following issues: 1. Assures that change-authorization, change-scheduling, and change-notification procedures are used. 2. Assures that the existing configuration has been saved in a configuration repository. 3. Assures that the old configuration can be quickly reinstalled after installation of the new configuration. If possible, the old configuration should be saved on the equipment in a non-volatile fashion. 4. Assures that the new configuration is tested for correct function to the extent possible. 5. Assures that the new configuration is saved to a configuration repository using some version-control facility such as Cisco RME. 6. Assures that the new configuration is stored in a permanent fashion on the equipment and will automatically reinstall during subsequent equipment reboots.

STLF-210-REQ MGT.OP.PRO-90. Firmware change

For every firmware change, a procedure needs to be established that addresses the following issues: 1. Assures that the change-authorization, change-scheduling, and change-notification procedures are used. 2. Assures to the degree possible that the firmware being installed is compatible with all hardware components and all other firmware prior to changing/installing the new firmware. 3. Checks whether configuration changes are needed prior to changing/installing firmware, and if so, assures that the configuration change procedures are used. 4. Assures that the old firmware can be quickly reinstalled after installation of the new firmware. If possible, the old firmware should be saved on the equipment in a non-volatile fashion. 5. Assures that the new firmware/configuration is tested for correct function to the extent possible. 6. Assures that the new firmware/configuration is stored in a permanent fashion on the equipment and will automatically reinstall during subsequent equipment reboots.

STLF-210-REQ MGT.OP.PRO-100. Hardware change

For every hardware change, a procedure needs to be established that addresses the following issues: 1. Assures that the change-authorization, change-scheduling, and change-notification procedures are used. 2. Checks to the extent possible that the hardware being installed is compatible with all remaining hardware components prior to changing/installing a new hardware component. 3. Checks to the extent possible whether configuration and/or firmware changes are also needed. If so, use the configuration and/or firmware change procedures prior to changing/installing a new hardware component. 4. Assures that the new hardware/configuration/firmware can be gracefully backed out.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

156 / 247

5. Assures that the new hardware/configuration/firmware is tested for correct function to the extent possible.

STLF-210-REQ MGT.OP.PRO-110. Logical access

Security procedures for validating the identity of individuals authorized to access equipment are necessary.

STLF-210-REQ MGT.OP.PRO-120. Physical access

Procedures need to be established for authorized support personnel to obtain physical access to the equipment at the POP. Access should be available at all times and without the need to be accompanied by on-site personnel. Someone from the POP site will be responsible for obtaining all necessary permissions, keys, card-keys, parking access, etc. required for physical access by authorized support personnel.

STLF-210-REQ MGT.OP.PRO-130. Out-of-band access

Remote serial-port access independent from the network being implemented will be necessary for emergency maintenance access to the equipment. This access can be implemented with a single dial-in modem for each serial port, or it may be implemented with a remote access server attached to the serial ports, with one or more dial-in modems attached to the remote access server. However, if a remote access server is used, the remote access server should be capable of functioning without access or reference to external equipment.

STLF-210-REQ MGT.OP.PRO-140. Access to log files

Syslogd files and other similar log files need to be maintained and access to these files needs to be provided to authorized support personnel.

STLF-210-REQ MGT.OP.PRO-150. Equipment spares

A spare needs to be maintained on-site for every component of every critical piece of equipment. Such spare equipment should be maintained at a revision level that is functionally equivalent to the equipment to be replaced. In general, it is preferable for spare equipment to be in the powered-on state, to be attached to the network to make upgrading firmware easier and to be monitorable if such equipment can be monitored.

STLF-210-REQ MGT.OP.PRO-160. Equipment maintenance contracts

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

157 / 247

For all equipment, a maintenance contract with the OEM vendor should be maintained that is sufficient to replace any failed component within 24 hours and without additional charge and which provides for upgrade of all firmware without additional charge.

STLF-210-REQ MGT.OP.PRO-170. Vender call

A table needs to be established that contains a line for each vendor-maintenance or leased facility. Each line includes the contracted facility, the parameters of the service, the vendor, the contracting agency, the contract number/identifier, the authorized technical and administrative contact, and any passwords required to contact the contractor for service.

STLF-210-REQ MGT.OP.PRO-180. Automatic software update

Terminal software may be updated automatically via a multicast or unicast transmission from the management center or from a specific facility controlled from the management center.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

158 / 247

7. TOOLS REQUIREMENTS SATLIFE system requires a set of tools to evaluate and dimensioning the network and provided service. Next figure shows the components and their relations needed to be able to dimensioning and tuning the SATLIFE system. The first steps are the definition of the Service scenarios, and the Identification of the End-User service Requirements. The rest of the components are described in this section; they are:

- Network services requirements and Model: Section 7.1 defines the requirements needed for the network modelling. These requirements will also be the baseline for the WP2200. They include: o End-to-End QoS: The set of requirements needed to provide E-to-E QoS mapping the

QoS parameters to the different segments of the network o End-to-End Multicast: The set of requirements needed to provide E-to-E multicast in a

system where the SATLIFE mesh satellite sub-network is the key element to provide multicast access to a broad population.

o Conversational Model: For conversational services (such as tele-education /tele-training and video-conference) in a satellite environment, only a subset of the defined conferencing models is possible due to the limitation in the number of satellite hops, and the need of minimise the required satellite network resources. The requirements imposed to the conversational model are highlighted.

- Definition of Traffic Models: Section 7.1 also defines the proposed model for the system traffic

that will be needed for its performance evaluation. - Requirements/Selection of Performance evaluation tools: Section 7.2 develops the set of

requirements to be applied to the selection of performance evaluation tools, both for a system simulation and also for a real system performance evaluation.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

159 / 247

Figure 22. Process for the modelling of SATLIFE

The final step of this process, the actual system evaluation, dimensioning and tuning, will be performed in other SATLIFE work packages.

7.1 MODELING TOOLS As it is described above, this section defines the requirements needed for the network modelling. They include the models requirements for: End-to-End QoS, End-to-End Multicast, and Conversational. Also the Definition of Traffic Models for the system traffic that will be needed for its performance evaluation.

7.1.1 End-to-End QoS model requirements The set of requirements needed to provide and modelling E-to-E QoS, mapping the QoS parameters to the different segments of the network is defined here.

STLF-210-REQ TLS.MOD.E2E-10. Satellite delay

More than one geostationary satellite cluster is needed for worldwide coverage. The use of spot beams will increase the total system capacity. However, being delay a critical requirement, double satellite hop (through Inter System Stations) must be avoided for real time services. Then, only a single satellite cluster

Conversational Services

Identification of IP Based End-User services requirements

Interactive Services

Streaming Services

Background Services

Definition of Traffic Models & Requirements/Selection of Performance evaluation tools

E-to-E QoS Model E-to-E Multicast

Model

IP Based Network services requirements & Model.

Conversational Model

Performance evaluation/System dimensioning and tuning

Definition of Service Scenar ios

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

160 / 247

shall be exploited and the ISL delay for Cluster collocated satellites shall fit the requirements (if not, terrestrial networks should be used). GEO satellite propagation delay has to be modelled.

STLF-210-REQ TLS.MOD.E2E-20. QoS support

The satellite segment shall provide QoS in terms of Packet Loss, Delay and Jitter. The satellite segment shall interwork with Internet QoS mechanisms IntServ/RSVP or DiffServ in order to provide end to end QoS at network level. The terminal model shall perform this interworking in terms of signalling and QoS parameters mapping.

STLF-210-REQ TLS.MOD.E2E-30. IP Routing: Shortest path

The shortest path in term of delay is assumed for the system model, but being the satellite network a part of the global IP network, traffic is not required to be routed specifically through the satellite domain.

STLF-210-REQ TLS.MOD.E2E-40. TCP improvements

The techniques to improve the TCP performance (see annex section G.4) has to be modelled. The TCP performance should be limited by the allocated band width resources.

STLF-210-REQ TLS.MOD.E2E-50. On-demand channels rates

The channel rate should accommodate user flows efficiently (with little unused channel capacity, bounded by the minimum switchable element). Minimum switchable element of traffic should also map efficiently to flow characteristics. According to QoS requirements, the model should minimize the required bandwidth for user access.

STLF-210-REQ TLS.MOD.E2E-60. Connection mode

It is recommended that two modes of connection are provided in the model: • Switched connection: assigned by the network on-demand via the connection control procedures. • Permanent connection: assigned by the network via management procedures (operator)

STLF-210-REQ TLS.MOD.E2E-70. Traffic Management procedures

The satellite network model implements the following Traffic Management procedures: • Connection Admission Control (required) • (Dynamic) Traffic Resources Management (required). • Traffic scheduling (no Traffic Shaping, required). • Forward Congestion Monitoring and Control (optional) • Usage Parameters Control (optional) . • Traffic Shaping (optional).

STLF-210-REQ TLS.MOD.E2E-80. Traffic Compression procedures

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

161 / 247

Implementation and modelling of compression techniques such as of CRTP is optional to reduce significantly overhead (60 bytes from IP+UDP+RTP headers, are reduced to 2-4 bytes).

7.1.2 End-to-End Multicast model requirements This section defines the set of requirements needed to provide E-to-E multicast in a system where the SATLIFE satellite sub-network is the key element to provide multicast access to a broad population.

STLF-210-REQ TLS.MOD.MUL-10. Satellite Network topology

The satellite network model should support single hop full-meshed connectivity among satellite terminals (through a GTW or not), besides the non-regenerative star topology (through a GTW).

STLF-210-REQ TLS.MOD.MUL-20. Satellite Network Multicast support

The satellite segment shall support multicast capabilities at link layer (with a negligible additional delay in this case of regenerative satellite) so that it can support IP multicast efficiently.

STLF-210-REQ TLS.MOD.MUL-30. Users’ multicast support

As explained in the conference model suitable for SATLIFE (see C

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

162 / 247

ANNEX: ANALYSIS OF THE CONFERENCE MODELS), IP Multicast shall be used for transmission of multimedia flows in the satellite network.

The model must support end users who may have unicast or multicast access. For the several services and applications developed in a unicast environment, like in one of the possible user cases for multiconference, the multicast support for unicast users could be achieved through a TCP/IP gateway that allows unicast users to access to the multicast domain services.

STLF-210-REQ TLS.MOD.MUL-40. Maximum number of satellite hops

According to delay requirements, multimedia flows must traverse at most one satellite hop when real time services are modelled.

STLF-210-REQ TLS.MOD.MUL-50. IP multicast in the satellite network

The space segment shall implement efficient replication of packets (with minimal fixed delay) for the required spot beams in order to support multicast, i.e. point-to-multipoint connectivity, based on the on-board processing multicast capabilities. IP Multicast must be used for transmission of multimedia flows in the satellite network, in order to save bandwidth (especially important for high-consumption media flows like video) and guarantee the single satellite hop requirement.

The IP Multicast requirements are described in section 3.5 MULTICAST SERVICE. For more information about IP multicast, see also F ANNEX: IP MULTICAST PROTOCOLS.

STLF-210-REQ TLS.MOD.MUL-60. Multicast mode requirement

Source-specific trees are established for each satellite source. A sparse mode multicast tree is a requirement (no data flooding), where a satellite conference can be distributed in a large area. Satellite domain media clients require one satellite hop to the multicast proxy. However, the communication between them is only for signalling purposes. No media communication between the satellite end user and a centralised server, proxy or Rendezvous Point (shared tree) should be needed.

STLF-210-REQ TLS.MOD.MUL-70. Inter -domain multicast requirement

An inter-domain multicast routing protocol might be required to extend the multicast reach to other terrestrial multicast domains connected to the satellite domain. See annex F for details.

1.Rendezvous Point (RP) in the satellite domain To enable inter domain multicast, a multicast source discovery between domains is required such as MSDP. The Rendezvous Point (RP) in the satellite domain is necessary to be the bridge to connect all of the RPs in different ISP domains using MSDP peering.

2.ISPs’ cooperation with satellite domain

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

163 / 247

ISPs shall configure their RPs and border gateway to peer with the satellite domain using MSDP and MBGP.

7.1.3 Conversational model requirements For conversational services such as tele-education/tele-training and multiconference in a satellite environment, only a subset of the defined conferencing models is possible due to the limitation in the number of satellite hops, and the need of minimise the required satellite network band width. The requirements imposed to the conversational model are highlighted here. The final configuration of the conversational model (servers, mixers…) should be provided by the defined SATLIFE scenarios. Annex C analyses the different conference models that have been proposed and their suitability for SATLIFE satellite network. As a conclusion of this analysis, the following requirements apply:

STLF-210-REQ TLS.MOD.CNV-10. Centralized signalling

For Tightly coupled conferences, a centralised server (focus, see annex C) is required for signalling purposed only.

STLF-210-REQ TLS.MOD.CNV-20. Distr ibuted multicast media (see annex C)

Media flows should be distributed using the multicast capabilities of the network. The one satellite hop for media flows imposes this requirement. Multiple mixers or MCUs might be necessary to:

1. Optimise the required satellite resources. 2. Reduce the mixing function at the end user machine (CPU consuming). 3. Reduce the required end-user network access rate.

7.1.4 User Traffic Models See annex D.

7.2 PERFORMANCE EVALUATION TOOLS This section defines the requirements imposed to the performance evaluation tools needed to dimensioning and tuning the SATLIFE services and network. It includes two types of tools:

1. System level measurement tools used to evaluate the performance of the real system. 2. Simulation and emulation tools used to evaluate the system performance through simulation

models. Simplified models (in terms of number of components) should be also evaluated using emulation laboratory environments.

7.2.1 Requirements for system level measurement tools The different quality evaluation /monitoring tools will be necessary in order to assess services QoS.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

164 / 247

The requirements for them will be overtaken in terms of price, supported protocols, supported QoS ratings (E-model, PESQ …), traffic simulation/generation, detection of network problems, platform (HW/SW), video support, customer support, and existing documentation.

STLF-210-REQ TLS.PER.SYS-10. E-Model R factor support for audio quality evaluation

Overall audio transmission quality Rating (R) for TIPHON systems must be supported to evaluate and monitor the QoS:

Table 11. Audio quality rating values requirements

Categories of speech transmission quality can be inferred from the following table:

[Ref: Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; End-to-end Quality of Service in TIPHON systems; Part 2: Definition of speech Quality of Service (QoS) classes. ETSI TS 101 329-2 V2.1.3 (2002-01)]

Table 12. Categor ies of speech transmission quality

The resulting R factor depends on several factors: codec type, packet loss, delay, and advance factor (See annex E). Of course, the measurement of these parameters should be also supported by the tool as stated in the following requirements.

STLF-210-REQ TLS.PER.SYS-20. Delay evaluation

Delay manifests itself in a number of ways, including the time taken to establish a particular service from the initial user request and the time to receive specific information once the service is established. Delay has a very direct impact on user satisfaction depending on the application, and includes delays in the terminal, network, and any servers. Note that from a user point of view, delay also takes into account the effect of other network parameters such as throughput. Also, delay and echo are effects that to some extent interact, the annoyance caused by echo increases when delay increases. Specifications of end-to-end (mean one-way) delay for TIPHON speech QoS classes are given in table:

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

165 / 247

[Ref: Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3; End-to-end Quality of Service in TIPHON systems; Part 2: Definition of speech Quality of Service (QoS) classes. ETSI TS 101 329-2 V2.1.3 (2002-01)]

Table 13. End-to-end delay specs for TIPHON speech QoS classes

Delay contributions include: codec delay (packetization and algorithmic lookahead), transmission (exact satellite delay depends on geographic position), router/satellite processing, dejittering buffer,… Video delay depends on the video frame rate, computing capacity (hardware or software) and the actual implementation. In order to assure voice quality, video delay limits must comply with audio delay limits, plus the lip synchronization margin. Small payload size (codec dependent) is desired so that packetizing delay is minimised. However, this increases packet overhead and therefore bandwidth. Considering that all the traffic received shall exit from the OBP with minimum delay (next frame), the end-to-end delay should be lower than 400ms. This “Poor” figure cannot be improved in a geostationary satellite system, and its effect in the subjective QoS has to be compensated applying the above mentioned Advantage factor.

STLF-210-REQ TLS.PER.SYS-30. Call set-up time evaluation

For connection oriented services, this parameter should be evaluated. As an example, according to ETSI TS 101 511 V0.1.1, the call set-up time for telephony call should be lower that 8 sec. (Local call < 3 sec; National long-distance calls < 5 sec; International calls < 8 sec [Ref: ETSI TS 101 511 V0.1.1])

STLF-210-REQ TLS.PER.SYS-40. Packet loss measurement

IP packet loss ratio should be measured.

As an example, for audio/video flows, the imposed thresholds are around 1-5% (depending on codec algorithms); in general they can be around 3% for audio and 1% for video. For audio it should be low enough to achieve that most of the users are satisfied (R factor ≥ 70). Using packet loss concealment algorithms the effects can be minimised. [Ref: ITU-T Recommendation G.1010. End-user multimedia QoS categories. Nov 2001] Burst packet loss shall be taken into account, because the effect of two or more packets lost in sequence is more dramatic than loss of single packets.

STLF-210-REQ TLS.PER.SYS-50. Jitter measurement

Jitter should be evaluated. This parameter is especially significant for real time services. Jitter can be eliminated at the expense of imposing additional fixed delay (with buffers) or packet loss (discarding late packets). Adaptive jitter

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

166 / 247

buffers are desirable in order to decrease these effects. Standards recommend jitter values under 1ms for audio and 50ms for video. [Ref: ITU-T Recommendation G.1010. End-user multimedia QoS categories. Nov 2001] [Ref: ITU-T Recommendation P.911. Subjective audiovisual quality assessment methods for multimedia applications. Dec 1998] In the project scenarios, the network jitter should be minimized in order to reduce it effect on the end-to-end delay and packet loss. It should be low enough to achieve that most of the users are satisfied (R factor ≥ 70). The transit time of a packet through an IP network will vary due to queuing and other effects. This delay variation is called jitter. Jitter is defined as the absolute value of the difference between the delay measurements of two adjacent packets. Delay variation is generally included as a performance parameter since it is very important at the transport layer in packetised data systems due to the inherent variability in arrival times of individual packets. However, services that are highly intolerant of delay variation will usually take steps to remove (or at least significantly reduce) the delay variation by means of buffering, effectively eliminating delay variation as perceived at the user level (although at the expense of adding additional fixed delay). However it imposes additional fixed delay. Adaptive jitter buffer codecs may be used to achieve jitter values for audio less than 1ms, though normally they are not free. For video, jitter values less than 50ms are desirable.

STLF-210-REQ TLS.PER.SYS-60. Advantage factor

Service should be provided making the user aware of the advantages (cost, coverage…) of the underlying satellite network which impact the QoS. This fact permits the improvement of the subjective quality (R factor because of the increasing of the A-Advantage factor).

STLF-210-REQ TLS.PER.SYS-70. Perceptual measurements

MOS testing provides a subjective measurement of the user-perceived voice quality. As a minimum, a target MOS of 3 (=Fair) should be set as the objective. The MOS rating is a composite subjective analysis of individual elements such as intrinsic voice quality, delay, perceived echo, background noise, voice clipping and effects of packet loss. MOS results are affected by a number of components within a VoIP system, in particular, the compression used, effectiveness of echo control, intrusiveness of silence suppression, end-to-end delay, delay variation and packet loss. The performance of each of these components and the net result in terms of conversational speech quality is a complex one. MOS (Mean Opinion Score) measures are rated following the table shown below:

Opinion Score Excellent 5

Good 4 Fair 3

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

167 / 247

Poor 2 Bad 1

Table 14. MOS measure rating

Where a 5 is an ideal score that is mostly impossible to achieve and 1 means that the conversation is inaudible. To most users an acceptable quality level must be around 4 meanwhile typical acceptable scores for all standards are as follows:

MOS 4.0 or higher (toll quality) PAMS 4.0 or higher PSQM 0.5 or below PESQ 3.8 or higher (toll quality-industry accepted)

Table 15. MOS accepted values

[ITU-T recommendation P.800: methods for subjective determination of transmission quality] The following table shows the intrinsic MOS associated with various voice-coding algorithms.

Speech Codec Bitrate(Kbps.) MOS G.711 64 4.3 G.726 32 4.0 G.723 6.3 3.8 G.728 16 3.9 G.729 8 4.0

GSM Full Rate 13 3.7

Table 16. MOS rates for var ious codecs

For more information about perceptual measurements standards, see E ANNEX: Methods for Measuring Speech Quality.

STLF-210-REQ TLS.PER.SYS-80. Support of the protocols involved in SATLIFE services.

The tools should support the analysis of the different involved protocols, for example SIP related protocols, H.323 protocols.

STLF-210-REQ TLS.PER.SYS-90. Traffic simulation and/or generation support

It can be helpful when evaluating the full possibilities of an specified network allowing the testers to generate many different situations varying the traffic levels or sources, usually Network analysis and network problem detection and troubleshooting is featured in the hardware network analyzer, this features comes handy when configuring the network prior to testing.

STLF-210-REQ TLS.PER.SYS-100. Development API support

A development API might be necessary to perform on-line or off-line data evaluation automatically.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

168 / 247

STLF-210-REQ TLS.PER.SYS-110. Platform compatibility

Although it is not a critical feature, the portability of the tool to different platforms may be useful (SW/HW).

STLF-210-REQ TLS.PER.SYS-120. L icences

The cost and conditions of the tool’s licences must also be considered in order to control costs and observe the SATLIFE contract terms at the same time.

7.2.2 Requirements for Simulation tools In this section we present the identified desirable features (requirements) for the network simulator to be used in the SATLIFE project. We have divided these features into two blocks, implemented models and environment quality, in terms of use easiness, integrated analysis tools, etc. Annex A analyses the candidate simulation tools against the requirements defined in this section.

STLF-210-REQ TLS.PER.SIM-10. TCP Enhancements support

Several TCP algorithms have been modified or added afterwards to fix bugs as well as to adapt the protocol to certain network characteristics. This resulted in many different TCP implementations. In satellite networks, where the bandwidth is an expensive resource and delays high, any problem occurred during the transmission results in important bandwidth and time wastes. Some techniques like Selective Acknowledgements or introducing Performance Enhancement Proxies (PEPs) were proposed to reduce the impact of these events (See annex G.4). Then it is desirable that the network simulator chosen has TCP models which implements as many algorithms and enhancements as possible. The emulator should also support TCP enhancements.

STLF-210-REQ TLS.PER.SIM-20. Multicast support

In scenarios where there are broadcast services and there isn’ t much bandwidth available multicast techniques become necessary. In the SATLIFE network two multicast protocols have been found especially interesting, Source Specific Multicast (SSM) and Protocol Independent Multicast-Sparse Mode (PIM-SM). Therefore, it is desirable that the simulator includes models for them. The emulator should be able to emulate for unicast and multicast packets.

STLF-210-REQ TLS.PER.SIM-30. Satellite network models

A satellite network model involves two different layers: the Multiple Access Control (MAC) and the radio interface (i.e. power considerations, electromagnetic propagation, etc.). In our case all aspects related to the channel special characteristics will be summarised in a Frame Error Rate (FER) value, then it isn’ t necessary that the network simulator has complex propagation models. However the MAC layer should be simulated so the network simulator should have models for typical satellite MAC protocols. The emulator should be able to support OBP as well as transparent satellite scenarios.

STLF-210-REQ TLS.PER.SIM-40. IPv6 support

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

169 / 247

To allow the possible introduction of IPv6 in the SATLIFE project, it is desirable that the network simulator includes models for IPv6. The emulator should work for both IPv4 and IPv6 packets.

STLF-210-REQ TLS.PER.SIM-50. Traffic Models support

Although, the experience in the IBIS project left us some traffic models which could be adapted to the finally selected network simulator. Anyway it will be considered as positive if the network simulator includes some traffic models for the SATLIFE project applications.

For more information about traffic models, see D ANNEX: DETAILED TRAFFIC MODELS.

STLF-210-REQ TLS.PER.SIM-60. Per formance

SATLIFE simulations are not expected to involve too many network elements, so performance is not a critical feature for choosing the simulator. However, this parameter has been considered and it may be used in the selection. We have considered two different factors:

§ Capability of parallelizing the simulation § Efficiency

STLF-210-REQ TLS.PER.SIM-70. User inter face

A rich user interface helps reducing the time for preparing a simulation and for interpreting the results. The emulator should graphical and easily configurable. We have divided the user interface into four different characteristics to be evaluated:

§ Graphic interface. § Model creation language § Simulation debugging tools § Results analysis tools

STLF-210-REQ TLS.PER.SIM-80. Platform compatibility

Although it is not a critical feature, the portability of the models, simulations, etc. to different platforms may be useful.

STLF-210-REQ TLS.PER.SIM-90. L icences

The cost and conditions of the simulator’s licences must also be considered in order to control costs and observe the SATLIFE contract terms at the same time.

7.3 BILLING TOOLS This chapter is an overview of billing and accounting tools, and a complete proposal for integrating this tools into the SATLIFE project.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

170 / 247

Total charges can be generated from the CDRs with a billing/accounting platform, which will not be covered by the project (billing is out of the natural scope of the SATLIFE project, and further integration with a billing platform will not be covered, although it is straightforward from the CDRs).

However, as these are interesting tools for commercial service deployment, we will describe the main guidelines for a future integration of the SATLIFE system with billing and accounting tools.

7.3.1 Billing

STLF-210-REQ TLS.BIL-10. Real time billing

All billing is performed in real time, as soon as the session starts, with the generation of CDRs (Call Detail Records). Balance is always up to date because billing is up to date.

This billing platform can process the CDRs offline. Alternatively, they have APIs that must be called by the proxy server to validate and charge the call on real time.

STLF-210-REQ TLS.BIL-20. Integrated billing

Billing, RADIUS, and customer care are integrated in a true all-in-one package. This integration reduces setup time and maintenance costs.

STLF-210-REQ TLS.BIL-30. Time, volume and cash bonuses

Offer cyclic rewards in the form of cash, volume, megabytes, and any combination of the above. This feature increases customer loyalty and differentiates from competition.

STLF-210-REQ TLS.BIL-40. Time of day/day of week impacts

Offer different tariff rates for different time of day and days of the week. For example, weekend free hours, unlimited downloads and weekdays a dollar an hour, 10c per megabyte. Reduce peak load by normalizing usage periods. Tailor offers to customer specific needs. Credit limits Enforce credit limits up to the second, based on customer remaining hours and cash balance. Offer zero leakage prepaid. Give customers full control over spending.

STLF-210-REQ TLS.BIL-50. Invoice threshold.

Determine whether to run invoicing for customers whose debt falls below a determined threshold. Reduce invoice production costs.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

171 / 247

STLF-210-REQ TLS.BIL-60. Fixed charges

Include fixed cyclic charges for services. Offer flat rate plan or time based plans. For example 10��

month gives 200 hours.

STLF-210-REQ TLS.BIL-70. Setup fees

Charge one-off account setup fees. Flexible invoicing date Monthly, weekly, daily, annual and anniversary invoicing schedules all supported Tailor invoicing to customer needs, distribute or centralize cash flow.

STLF-210-REQ TLS.BIL-80. Flexible renewal method

Accounts either expire after specified period or automatically renew. Offer guest plans, one off and subscriber services both supported.

STLF-210-REQ TLS.BIL-90. Complex taxes

Automatic calculation of multiple taxes as well as state taxes. Easily support users from different states. Save costs on bundling with external tax systems. Simplify reporting on taxes.

STLF-210-REQ TLS.BIL-100. Automated credit card payments

Automatically request payment by credit card using authorize.net. Reduce collections costs, increasing customer satisfaction.

STLF-210-REQ TLS.BIL-110. XML/XSL invoice customisation

Invoices are produced as an XML output which is automatically formatted with XSL for online presentation. Combination of portability and ease of presentation, easy to customize and suitable for web and print.

STLF-210-REQ TLS.BIL-120. Group billing

Bill multiple users as a single entity, making corporate and family offers.

STLF-210-REQ TLS.BIL-130. Proxy billing

Use a proxy server to outsource internet traffic and bill based on megabytes, hours used, or cyclic charges. Become a virtual service provide, offering hosting services for smaller providers.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

172 / 247

STLF-210-REQ TLS.BIL-140. Destination billing

Bill based on destination of internet call. Offer telephony pricing models for VoIP. Bundled packages Offer bundles of services. For example, internet and email. Satellite modem rental, etc. Give combined offers that leverage on market presence.

STLF-210-REQ TLS.BIL-150. Automated provisioning/de-provisioning

Complete Shell Script integration for activation, suspension, missed payments, password change, user details changed, termination and more. Markedly reduce integration time with external network elements such as mail servers, VAS servers, and more.

STLF-210-REQ TLS.BIL-160. Tiered rating

Provide discounts/penalties as total access time increases. Give incentives/penalties for increased usage time or downloads.

STLF-210-REQ TLS.BIL-170. Prepaid card handling

Prepaid cards can be used to register customers and different offers maybe be offered online to the customer according to the type of cards he used. Offers can be subscription services or one time packages (such as 10 hours for 30 days). A new prospect may even skip the registration process simply use the prepaid id and password to login (the system will then import him as a customer). A registered customer can then buy additional cards to refill (top-up) an account.

STLF-210-REQ TLS.BIL-180. Prepaid card bundles

To complement the enhanced prepaid capabilities, it is required to diversify the rating plans to ensure that the customers are satisfied and to increase the revenue. Some of the bundles that could be of interest include:

• Flat rate, tiered, duration based, usage based • Different tariffs for different time of day and/or days of week • Provide free hours and/or free megabytes on a periodic or one off basis • Charge setup fees up front or on first bill • Define special promotional offers • Origin/Destination based (for Voice Over IP services) • Automatically assign offers for customers that either expire after a set period

STLF-210-REQ TLS.BIL-190. User level billing

The end user may be billed independently from the RCST, bridging directly to the ISP.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

173 / 247

STLF-210-REQ TLS.BIL-200. Tar iff Structure

Subscriber charges will be designed according to the tariff structure defined for the service (which needs not be fixed). CDRs give enough flexibility to implement different charging schemes.

For example, in multiconference service and for point to point conferences, user that starts the conversation is charged; audio only cheaper than video; person that joins a videoconference is charged for it, unless it is invited by a third party that pays).

Another typical charges for a multiconference service include:

- Initial charge to use the service; monthly subscription fee.

- Normal call charges: call establishment fee; pay per call or flat rate (with an optional maximum number of minutes).

- Conference charges (conference central resources, if used): creation of a conference (establishment), duration of the conference, join the conference (invited, the one that invites pays; or not, the one that joins pays), call duration (per participant).

STLF-210-REQ TLS.BIL-210. Secur ity

If the billing traffic (between proxy and billing servers) passes through a public Internet, it should be encrypted and integrity protected, using underlying transport /network security techniques, like TLS and IPSec.

7.3.2 Radius

STLF-210-REQ TLS.RAD-10. Centralize user management

The system should implement a centralized user management tool based in the Radius protocol.

STLF-210-REQ TLS.RAD-30. Proxy and Roaming

Advanced Proxy support including static forwarding and DNS forwarding (Roaming).Deploy multi branch servers that can service each other. -Use central user database for multi site setups.

-Outsource Remote Access while maintaining control over users, groups, permission and billing, or provide outsourced Remote Access.

STLF-210-REQ TLS.RAD-40. Multiple dictionar ies

Over 30 vendor specific dictionaries, which can be easily customised for your special configuration, or create your own set of dictionaries. Take full advantage of vendor specific RADIUS attributes to tailor your setup to your needs. For example, apply bandwidth restriction, routing restrictions and more.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

174 / 247

STLF-210-REQ TLS.RAD-50. Identify instances of fraud

Allocate IP pools to access servers. Define callback services for corporate. Offer services tailored at high-end business customers. Concurrent session control. Limit the number of concurrent sessions a user or groups of users can have. Avoid misuse.

STLF-210-REQ TLS.RAD-60. Manage groups

Deploy different policies for different groups of customers, such as business and residential. For example, restrict bandwidth on particular times of day for a specific group. Optimize network usage for different customer expectations.

STLF-210-REQ TLS.RAD-70. Offer accounts based on QoS

The Radius protocol should offer different accounts based on QoS.

7.3.3 Reporting

STLF-210-REQ TLS.REP-10. Real time statistics

Real time, statistics for number of users on line, session duration and more, all from over the web. Have direct insight into the running of the system from anywhere in the world, through an internet browser.

STLF-210-REQ TLS.REP-20. Daily, weekly, monthly summaries

Summary reports for usage, cash earned and cash collected, automatically aggregated daily, weekly, monthly and annually to ease the access to most important statistics.

STLF-210-REQ TLS.REP-30. Graphs and analysis

Analytical graphs showing usage and earnings summaries to gain quick insight into the state of business from convenient visual graphs.

STLF-210-REQ TLS.REP-40. Top ten repor ts

Automatically generated top ten reports: top ten users in online time and in earnings. Detect fraud and unusual consumption habits.

STLF-210-REQ TLS.REP-50. E-mail repor ts

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

175 / 247

E-mail summary reports automatically to administrators to keep those that need to know in the know.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

176 / 247

8. REQUIREMENTS SUMMARY In this chapter, we will make a complete listing and summary of all the requirements stated along the document. The following table serves for this purpose. The first field is the requirement codename, as seen on the requirement statement. The following columns map the requirement with the service that need the system to meet that particular requirement:

• General: This requirement is general to all of the services described. • DTV: This requirement applies to Digital TV. • MC: This requirement applies to Multiconference. • INT: This requirement applies to Internet. • LAN: This requirement applies to LAN interconnection. • MCS: This requirement applies to Multicast. • LRN: This requirement applies to E-learning. • VOD: This requirement applies to Video on Demand. • SWD: This requirement applies to Software Download. • NOM: This requirement applies to Nomadic Access.

The kind of requirement may be M, which stands for mandatory, and O, which means that the requirement is optional. The final column indicates whether the requirement is new to SATLIFE project; otherwise, the requirement is assumed to be already present at the AMERHIS/IBIS project.

Requirement Name General DTV MC INT LAN MCS LRN VOD SWD NOM SATLIFE

STLF-210-REQ DTV-10. BANDWIDTH M X

STLF-210-REQ DTV-20. BURSTINESS M X

STLF-210-REQ DTV-30. SYMMETRY M X

STLF-210-REQ DTV-40. TOPOLOGY M X

STLF-210-REQ DTV-50. DELAY TOLERANCE M X

STLF-210-REQ DTV-60. JITTER TOLERANCE M X

STLF-210-REQ DTV-70. LOSS TOLERANCE M X

STLF-210-REQ DTV-80. TYPE OF USER M X

STLF-210-REQ DTV-90. SECURITY NEEDED O X

STLF-210-REQ DTV.CON.AUD-10. MPEG-2 FORMAT M X

STLF-210-REQ DTV.CON.AUD-20. MODES M X

STLF-210-REQ DTV.CON.AUD-30. COMPRESSION LAYERS M X

STLF-210-REQ DTV.CON.AUD-40. BITRATES M X

STLF-210-REQ DTV.CON.AUD-50. SAMPLING M X

STLF-210-REQ DTV.CON.VID-10. MPEG-2 FORMAT M X

STLF-210-REQ DTV.CON.VID-20. MPEG-2 SDTV PROFILE M X

STLF-210-REQ DTV.CON.VID-30. MPEG-2 HDTV PROFILE M X

STLF-210-REQ DTV.CON.VID-40. MPEG-4 FORMAT M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

177 / 247

STLF-210-REQ DTV.CON.VID-50. MPEG-4 PROFILES M X

STLF-210-REQ DTV.CON.VID-60. H264 FORMAT M X

STLF-210-REQ DTV.CON.VID-80. MPEG-2 SDTV BITRATES M X

STLF-210-REQ DTV.CON.VID-90. MPEG-2 HDTV BITRATES M X

STLF-210-REQ DTV.CON.VID-100. MPEG-4 BITRATES M X

STLF-210-REQ DTV.CON.VID-110. H264 BITRATES M X

STLF-210-REQ DTV.CON.SYS-10. MPEG-2 FORMAT M X

STLF-210-REQ DTV.CON.SYS-20. MPEG-2 TRANSPORT M X

STLF-210-REQ DTV.CON.SYS-30. MPEG-2 PSI M X

STLF-210-REQ DTV.CON.SYS-40. MINIMUM PSI M X

STLF-210-REQ DTV.CON.SYS-50. PAT M X

STLF-210-REQ DTV.CON.SYS-60. PMT M X

STLF-210-REQ DTV.CON.SYS-70. PAT/PMT FREQUENCY M X

STLF-210-REQ DTV.CON.SYS-80. DVB-SI M X

STLF-210-REQ DTV.RX-10. TRANSMISSION M X

STLF-210-REQ DTV.RX-20. MPEG-2 M X

STLF-210-REQ DTV.RX-30. MPEG-4 M X

STLF-210-REQ DTV.RX-40. H264 M X

STLF-210-REQ DTV.INT-10. FORMAT M X

STLF-210-REQ DTV.INT-20. APPLICATION TYPE M X

STLF-210-REQ DTV.INT-30. APPLICATION ENCAPSULATION M X

STLF-210-REQ DTV.INT-40. CAROUSELS/SERVICE RELATIONSHIP M X

STLF-210-REQ DTV.INT-50. CAROUSEL/PID RELATIONSHIP M X

STLF-210-REQ DTV.INT-60. CAROUSEL/APPLICATION RELATIONSHIP M X

STLF-210-REQ DTV.INT-70. TRANSMISSION M X

STLF-210-REQ DTV.INT-80. SIGNALLING M X

STLF-210-REQ DTV.INT-90. INTERACTION CHANNEL PROTOCOLS M X

STLF-210-REQ DTV.INT-100. AIT BITRATE M X

STLF-210-REQ DTV.INT-110. CAROUSEL BITRATE M X

STLF-210-REQ DTV.INT-120. INTERACTION CHANNEL BITRATE M X

STLF-210-REQ DTV.INT.RX-10. TRANSMISSION M X

STLF-210-REQ DTV.INT.RX-20. SET TOP BOX TYPE M X

STLF-210-REQ DTV.INT.RX-30. SET TOP BOX INTERACTIVE M X

STLF-210-REQ DTV.VSP-10. BITRATE M X

STLF-210-REQ DTV.VSP-20. H264 FILE FORMAT M X

STLF-210-REQ DTV.VSP-30. MPEG2 VIDEO FILE FORMAT M X

STLF-210-REQ DTV.VSP-40. CONTENT STREAMING M X

STLF-210-REQ MC.SF.SC-10. AUTHENTICATION M X

STLF-210-REQ MC.SF.SC-20. AUTHORIZATION M X STLF-210-REQ MC.SF.SC-30. AUTHENTICATION FOR CONFERENCES M X

STLF-210-REQ MC.SF.SF-10. TRANSPARENCY TO THE USER M X

STLF-210-REQ MC.SF.SF-20. BASIC FUNCTIONALITY M X

STLF-210-REQ MC.SF.SF-30. MEDIA TYPES M X

STLF-210-REQ MC.SF.SF-40. TYPICAL CALL SUPPLEMENTARY SERVICES O X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

178 / 247

STLF-210-REQ MC.SF.SF-50. ADVANCED SUPPLEMENTARY SERVICES O X STLF-210-REQ MC.SF.CC-10. CONFERENCE MEMBERS MANAGEMENT. O X

STLF-210-REQ MC.SF.CC-20. CONFERENCE APPLICATION SESSION MANAGEMENT M X STLF-210-REQ MC.SF.CC-30. CONFERENCE FLOOR MANAGEMENT O X STLF-210-REQ MC.SF.CC-40. ANNOUNCEMENT OF CONFERENCES M X

STLF-210-REQ MC.IF.EQP-10. ENDPOINTS M X

STLF-210-REQ MC.IF.EQP-20. CONFERENCE SERVERS & MCUS M X

STLF-210-REQ MC.IF.EQP-30. PSTN/ISDN GATEWAYS M

STLF-210-REQ MC.IF.VOIP-10. VOIP SIGNALLING PROTOCOL M X

STLF-210-REQ MC.IF.VOIP-20. VOIP SERVER M X

STLF-210-REQ MC.IF.CON-10. NETWORK CONNECTIVITY M

STLF-210-REQ MC.IF.CON-20. DIRECT IP CONNECTIVITY M

STLF-210-REQ MC.IF.CON-30. BANDWIDTH O

STLF-210-REQ MC.IF.CON-40. LEGACY ENDPOINTS M

STLF-210-REQ MC.IF.CON-50. IP ROUTING M

STLF-210-REQ MC.IF.CON-60. INTERWORKING M X

STLF-210-REQ MC.IF.CON-70. USERS COVERAGES M STLF-210-REQ MC.SCA.CNF-10. NUMBER OF SIMULTANEOUS USERS M X

STLF-210-REQ MC.SCA.CNF-20. NUMBER OF SIMULTANEOUS CONFERENCES M X

STLF-210-REQ MC.SCA.CNF-30. NUMBER OF USERS IN A CONFERENCE M X

STLF-210-REQ MC.SCA.CNF-40. NUMBER OF SIMULTANEOUS USERS AND SATELLITE TERMINALS M X

STLF-210-REQ MC.SCA.AVL-10. AVAILABILITY (UPTIME) M X

STLF-210-REQ MC.SCA.AVL-20. RESPONSE TIME /TIMEOUTS M X

STLF-210-REQ MC.ADM.UIO-10. USER (CPE) INSTALLATION M X

STLF-210-REQ MC.ADM.UIO-20. INDEPENDENCY OF LOCATION M X

STLF-210-REQ MC.ADM.UIO-30. ADMINISTRATION M X

STLF-210-REQ MC.ADM.ADM-10. SINGLE POINT OF MANAGEMENT M X

STLF-210-REQ MC.ADM.ADM-20. EASY ADMINISTRATION M X

STLF-210-REQ MC.ADM.ADM-30. INDEPENDENT ADMINISTRATION M X

STLF-210-REQ MC.ADM.ADM-40. STATISTICS OF USE O X

STLF-210-REQ MC.QOS-10. BANDWIDTH M X

STLF-210-REQ MC.QOS-20. AUDIO-VIDEO SYNCHRONY (LIP SYNCHRONIZATION) M X

STLF-210-REQ MC.QOS-30. ECHO CONTROL O X

STLF-210-REQ MC.QOS-40. VIDEO MOVEMENT O X

STLF-210-REQ MC.QOS-50. PICTURE RESOLUTION M X

STLF-210-REQ MC.SEC-10. REGISTRATION / AUTHENTICATION M X

STLF-210-REQ MC.SEC-20. SIGNALLING TRAFFIC O X

STLF-210-REQ MC.SEC-30. CONTENT (MEDIA) LEVEL O X

STLF-210-REQ INT-10. NAT/NAPT SUPPORT M X

STLF-210-REQ INT-20. DHCP SUPPORT M

STLF-210-REQ INT-30. MULTISTATION SUPPORT M

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

179 / 247

STLF-210-REQ INT-40. QOS PROFILES M

STLF-210-REQ INT-50. TRAFFIC PRIORIZATION M

STLF-210-REQ INT-60. PPPoE SUPPORT M X

STLF-210-REQ INT.WEB-10. BANDWIDTH M

STLF-210-REQ INT.WEB-20. BURSTINESS M X

STLF-210-REQ INT.WEB-30. SYMMETRY M X

STLF-210-REQ INT.WEB-40. TOPOLOGY M X

STLF-210-REQ INT.WEB-50. DELAY TOLERANCE M X

STLF-210-REQ INT.WEB-60. JITTER TOLERANCE M X

STLF-210-REQ INT.WEB-70. LOSS TOLERANCE M X

STLF-210-REQ INT.WEB-80. PROTOCOLS M

STLF-210-REQ INT.WEB-90 .TYPE OF USER M

STLF-210-REQ INT.WEB-100. SECURITY NEEDED M

STLF-210-REQ INT.CHT-10. BANDWIDTH M X

STLF-210-REQ INT.CHT-20. BURSTINESS M X

STLF-210-REQ INT.CHT-30. SYMMETRY M X

STLF-210-REQ INT.CHT-40. TOPOLOGY M X

STLF-210-REQ INT.CHT-50. DELAY TOLERANCE M X

STLF-210-REQ INT.CHT-60. JITTER TOLERANCE O X

STLF-210-REQ INT.CHT-70. LOSS TOLERANCE M X

STLF-210-REQ INT.CHT-80. PROTOCOLS M X

STLF-210-REQ INT.CHT-90. TYPE OF USER M

STLF-210-REQ INT.CHT-100. SECURITY NEEDED O X

STLF-210-REQ INT.ACC-10. BANDWIDTH M

STLF-210-REQ INT.ACC-20. BURSTINESS M X

STLF-210-REQ INT.ACC-30. SYMMETRY M X

STLF-210-REQ INT.ACC-40. TOPOLOGY M X

STLF-210-REQ INT.ACC-50. DELAY TOLERANCE M X

STLF-210-REQ INT.ACC-60. JITTER TOLERANCE O X

STLF-210-REQ INT.ACC-70. LOSS TOLERANCE M X

STLF-210-REQ INT.ACC-80. PROTOCOLS M X

STLF-210-REQ INT.ACC-90. TYPE OF USER M

STLF-210-REQ INT.ACC-100. SECURITY NEEDED O

STLF-210-REQ INT.STR-10. BANDWIDTH M X

STLF-210-REQ INT.STR-20. BURSTINESS M X

STLF-210-REQ INT.STR-30. SYMMETRY M X

STLF-210-REQ INT.STR-40. TOPOLOGY M X

STLF-210-REQ INT.STR-50. DELAY TOLERANCE M X

STLF-210-REQ INT.STR-60. JITTER TOLERANCE M X

STLF-210-REQ INT.STR-70. LOSS TOLERANCE M X

STLF-210-REQ INT.STR-80. PROTOCOLS M X

STLF-210-REQ INT.STR-90. TYPE OF USER M

STLF-210-REQ INT.STR-100. SECURITY NEEDED O

STLF-210-REQ INT.FTP-10. BANDWIDTH M X

STLF-210-REQ INT.FTP-20. BURSTINESS M X

STLF-210-REQ INT.FTP-30. SYMMETRY M X

STLF-210-REQ INT.FTP-40. TOPOLOGY M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

180 / 247

STLF-210-REQ INT.FTP-50. DELAY TOLERANCE O X

STLF-210-REQ INT.FTP-60. JITTER TOLERANCE M X

STLF-210-REQ INT.FTP-70. LOSS TOLERANCE M X

STLF-210-REQ INT.FTP-80. PROTOCOLS M X

STLF-210-REQ INT.FTP-90. TYPE OF USER M

STLF-210-REQ INT.FTP-100. SECURITY NEEDED O X

STLF-210-REQ INT.EML-10. BANDWIDTH M

STLF-210-REQ INT.EML-20. BURSTINESS M X

STLF-210-REQ INT.EML-30. SYMMETRY M X

STLF-210-REQ INT.EML-40. TOPOLOGY M X

STLF-210-REQ INT.EML-50. DELAY TOLERANCE M X

STLF-210-REQ INT.EML-60. JITTER TOLERANCE M X

STLF-210-REQ INT.EML-70. LOSS TOLERANCE M X

STLF-210-REQ INT.EML-80. PROTOCOLS M

STLF-210-REQ INT.EML-90. TYPE OF USER M

STLF-210-REQ INT.EML-100. SECURITY NEEDED O

STLF-210-REQ INT.NWS-10. BANDWIDTH M

STLF-210-REQ INT.NWS-20. BURSTINESS M X

STLF-210-REQ INT.NWS-30. SYMMETRY M X

STLF-210-REQ INT.NWS-40. TOPOLOGY M X

STLF-210-REQ INT.NWS-50. DELAY TOLERANCE O X

STLF-210-REQ INT.NWS-60. JITTER TOLERANCE O X

STLF-210-REQ INT.NWS-70. LOSS TOLERANCE M X

STLF-210-REQ INT.NWS-80. PROTOCOLS M

STLF-210-REQ INT.NWS-90. TYPE OF USER M

STLF-210-REQ INT.NWS-100. SECURITY NEEDED O

STLF-210-REQ INT.GAM-10. BANDWIDTH M

STLF-210-REQ INT.GAM-20. BURSTINESS M X

STLF-210-REQ INT.GAM-30. SYMMETRY M X

STLF-210-REQ INT.GAM-40. TOPOLOGY M X

STLF-210-REQ INT.GAM-50. DELAY TOLERANCE M X

STLF-210-REQ INT.GAM-60. JITTER TOLERANCE O X

STLF-210-REQ INT.GAM-70. LOSS TOLERANCE O X

STLF-210-REQ INT.GAM-80. PROTOCOLS M

STLF-210-REQ INT.GAM-90. TYPE OF USER M

STLF-210-REQ INT.GAM-100. SECURITY NEEDED O

STLF-210-REQ INT.MSN-10. BANDWIDTH M X

STLF-210-REQ INT.MSN-20. BURSTINESS M X

STLF-210-REQ INT.MSN-30. SYMMETRY M X

STLF-210-REQ INT.MSN-40. TOPOLOGY M X

STLF-210-REQ INT.MSN-50. DELAY TOLERANCE O X

STLF-210-REQ INT.MSN-60. JITTER TOLERANCE O X

STLF-210-REQ INT.MSN-70. LOSS TOLERANCE M X

STLF-210-REQ INT.MSN-80. PROTOCOLS M X

STLF-210-REQ INT.MSN-90. TYPE OF USER M X

STLF-210-REQ INT.MSN-100. SECURITY NEEDED O X

STLF-210-REQ LAN-10. DYNAMIC BANDWIDTH M

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

181 / 247

STLF-210-REQ LAN-20. TYPE OF SERVICE M

STLF-210-REQ LAN-30. TYPE OF FLOWS M

STLF-210-REQ LAN-40. IP ADDRESSES M X

STLF-210-REQ LAN-50. INTERNET ACCESS M

STLF-210-REQ LAN-60. INTRANET ACCESS M

STLF-210-REQ LAN-70. LAN2LAN M

STLF-210-REQ LAN-80. BANDWIDTH M

STLF-210-REQ LAN-90. BURSTINESS M

STLF-210-REQ LAN-100. SYMMETRY M X

STLF-210-REQ LAN-110. TOPOLOGY M

STLF-210-REQ LAN-120. DELAY TOLERANCE M X

STLF-210-REQ LAN-130. JITTER TOLERANCE O

STLF-210-REQ LAN-140. LOSS TOLERANCE M

STLF-210-REQ LAN-150. PROTOCOLS M

STLF-210-REQ LAN-160. TYPE OF USER M

STLF-210-REQ LAN-170. SECURITY NEEDED O

STLF-210-REQ LAN-180. LINK-LEVEL INTERCONNECTION O X

STLF-210-REQ MCS-10. RESERVED IP ADDRESSES M

STLF-210-REQ MCS-20. TERMINAL REQUIREMENTS M

STLF-210-REQ MCS-30. AUTHENTICATION AND VERIFICATION O X

STLF-210-REQ MCS-40. SECURITY O X

STLF-210-REQ MCS-50. HOSTS LOCATED IN EXTERNAL NETWORKS M X

STLF-210-REQ MCS-60. TUNNELING AND INTEROPERABILITY FOR UNICAST EXTERNAL NETWORKS M X

STLF-210-REQ MCS-70. INTEROPERABILITY FOR OTHER MULTICAST SYSTEMS M X

STLF-210-REQ MCS-80. ROUTING PROTOCOLS M X

STLF-210-REQ MCS-90. NET FLOODING AND RESOURCE ABUSE M X

STLF-210-REQ MCS.QOS-10. QUALITY OF SERVICE SUPPORT M X

STLF-210-REQ MCS.QOS-20. QUALITY OF SERVICE EXTENSIONS FOR MULTICAST M X

STLF-210-REQ MCS.QOS-30. TRADE-OFF BETWEEN SPEED AND QUALITY M X

STLF-210-REQ MCS.QOS-40. RELIABILITY M X

STLF-210-REQ MCS.QOS-50. FLOW CONTROL M X

STLF-210-REQ MCS.QOS-60. BANDWIDTH M X

STLF-210-REQ MCS.QOS-70. BURSTINESS M X

STLF-210-REQ MCS.QOS-80. SYMMETRY M X

STLF-210-REQ MCS.QOS-90. TOPOLOGY M X

STLF-210-REQ MCS.QOS-100. DELAY TOLERANCE O X

STLF-210-REQ MCS.QOS-110. JITTER TOLERANCE O X

STLF-210-REQ MCS.QOS-120. LOSS TOLERANCE O X

STLF-210-REQ MCS.QOS-130. TYPE OF USER M

STLF-210-REQ MCS.GRP-10. DYNAMIC GROUP ASSIGNMENT M

STLF-210-REQ MCS.GRP-20. STATIC AND DYNAMIC GROUPS M X

STLF-210-REQ MCS.GRP-30. GROUP COMPOSITION M

STLF-210-REQ MCS.GRP-40. HOST LOCATIONS M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

182 / 247

STLF-210-REQ MCS.GRP-50. HOSTS JOINING SEVERAL GROUPS M X

STLF-210-REQ MCS.GRP-60. GROUP SIZE M X

STLF-210-REQ MCS.GRP-70. MULTICAST TREE BRANCHING M X

STLF-210-REQ LRN-10. TRANSPARENCY TO THE USER M X

STLF-210-REQ LRN-20. ASYMMETRICAL TRAFFIC M X

STLF-210-REQ LRN-30. MANY-TO-MANY TRAFFIC TOPOLOGY M X

STLF-210-REQ LRN-40. SUPPORTED PROTOCOLS M X

STLF-210-REQ LRN-50. LECTURE MEMBER MANAGEMENT M X

STLF-210-REQ LRN-60. LECTURE POLICY CONTROL O X

STLF-210-REQ LRN-70. CONFERENCE APPLICATION SESSION MANAGEMENT M X

STLF-210-REQ LRN-80. LECTURE FLOOR MANAGEMENT M X

STLF-210-REQ LRN-90. ANNOUNCEMENT OF CONFERENCES M X

STLF-210-REQ LRN.QOS-10. BANDWIDTH AND BURSTINESS M X

STLF-210-REQ LRN.QOS-20. DELAY TOLERANCE (INTERACTION) M X

STLF-210-REQ LRN.QOS-30. DELAY TOLERANCE (FLOOR NEGOTIATION) M X

STLF-210-REQ LRN.QOS-40. JITTER TOLERANCE M X

STLF-210-REQ LRN.QOS-50. LOSS TOLERANCE M X

STLF-210-REQ LRN.QOS-60. PACKET SIZE M X

STLF-210-REQ LRN-QOS-70. START-UP TIME M X

STLF-210-REQ LRN.QOS-80. PERCEPTUAL QUALITY M X

STLF-210-REQ LRN.QOS-90. AUDIO/VIDEO SYNCHRONIZATION M X STLF-210-REQ LRN.SEC-10. AUTHENTICATION AND REGISTRATION O X

STLF-210-REQ LRN.SEC-20. MEDIA TRAFFIC O X

STLF-210-REQ LRN.SEC-30. SIGNALLING TRAFFIC O X

STLF-210-REQ VOD-10. STREAMING M X

STLF-210-REQ VOD-20. TWO WAY COMMUNICATION M X

STLF-210-REQ VOD-30. SATELLITE LINK M X

STLF-210-REQ VOD-40. CONTENT PROTECTION M X

STLF-210-REQ VOD-50. CONTENT FORMATS M X

STLF-210-REQ VOD-60. TRANSPORT STREAM M X

STLF-210-REQ VOD-70. ELEMENTARY STREAM M X

STLF-210-REQ VOD-75. TRANSPORT DELIVERY M X

STLF-210-REQ VOD-80. CONTROL PROTOCOL M X

STLF-210-REQ VOD-90. SERVER STATUS M X

STLF-210-REQ VOD-100. SERVER METHODS M X

STLF-210-REQ VOD-110. USER COMMANDS M X

STLF-210-REQ VOD-120. LOG FILES M X

STLF-210-REQ VOD-130. USER TERMINAL M X

STLF-210-REQ VOD.QOS-10. CONTENT BITRATE M X

STLF-210-REQ VOD.QOS-20. DELAY, JITTER AND PACKET LOSS M X

STLF-210-REQ VOD.QOS-30. PICTURE RESOLUTION AND FRAME RATE M X

STLF-210-REQ SWD-10. TYPE OF CONTENTS M X

STLF-210-REQ SWD-20. CONTENT FLOWS M X

STLF-210-REQ SWD-30. CONTENT SCHEDULER M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

183 / 247

STLF-210-REQ SWD-40. SI/PSI INFORMATION M X

STLF-210-REQ SWD-50. PROGRAM GUIDE M X

STLF-210-REQ SWD-60. PACKET LOSS M X

STLF-210-REQ SWD-70. QOS O X

STLF-210-REQ SWD-80. CLIENT APPLICATION M X

STLF-210-REQ SWD.SEC-90. AUTHENTICATION O X

STLF-210-REQ SWD.SEC-100. CONTENT SECURING O X

STLF-210-REQ SWD.SEC-110. SIGNALLING TRAFFIC SECURING O X

STLF-210-REQ NOM-10. AUTOMATIC ACQUISITION M X

STLF-210-REQ NOM-20. TRANSPARENT AND REGENERATIVE M X

STLF-210-REQ NOM-30. CONNECTIVITY M X

STLF-210-REQ NOM-40. INTEROPERABILITY M X

STLF-210-REQ NOM-50. EQUIVALENT ACCESS M X

STLF-210-REQ NOM-60. INTENDED USERS M X

STLF-210-REQ NOM-70. USER INTERFACE M X

STLF-210-REQ NOM-80. GRAPHICAL INTERFACE O X

STLF-210-REQ NOM-90. AUTOMATIC PROCEDURES M X

STLF-210-REQ NOM-100. MOBILE TERMINALS SUPPORT O X

STLF-210-REQ NOM.QOS-10. BITRATE M X

STLF-210-REQ NOM.QOS-20. DELAY M X

STLF-210-REQ NOM.QOS-30. JITTER M X

STLF-210-REQ NOM.QOS-40. CONNECTION TIME M X

STLF-210-REQ NOM.QOS-50. PACKET LOSS M X STLF-210-REQ NOM.SEC-10. AUTHENTICATION AND REGISTRATION M X

STLF-210-REQ NOM.SEC-20. TRAFFIC ENCRYPTION O X

STLF-210-REQ MUL.AAV.MP1-10. TARGET BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP1-20. VARIABLE BITRATE O O O O X

STLF-210-REQ MUL.AAV.MP1-30. FIXED BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP1-40. TV SPATIAL RESOLUTION M M M M X

STLF-210-REQ MUL.AAV.MP1-50. PC SPATIAL RESOLUTION M M M M X

STLF-210-REQ MUL.AAV.MP1-60. TIME RESOLUTION M M M M X

STLF-210-REQ MUL.AAV.MP1-70. DEFINITION M M M M X

STLF-210-REQ MUL.AAV.MP2-10. LEVELS DEFINITION M M M M X

STLF-210-REQ MUL.AAV.MP2-20. PROFILES DEFINITION M M M M X

STLF-210-REQ MUL.AAV.MP2-30. FIXED AND VARIABLE BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP2-40. BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP2-50. SPATIAL RESOLUTION M M M M X

STLF-210-REQ MUL.AAV.MP2-60. TIME RESOLUTION M M M M X


STLF-210-REQ MUL.AAV.MP2-80. FORMATS M M M M X

STLF-210-REQ MUL.AAV.MP4-10. DEFINITION OF LEVELS AND PROFILES M M M M X

STLF-210-REQ MUL.AAV.MP4-20. BASIC VISUAL PROFILES M M M M X

STLF-210-REQ MUL.AAV.MP4-30. SIMPLE PROFILE LEVELS AND BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP4-40. SIMPLE SCALABLE PROFILE LEVELS AND BITRATE M M M M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

184 / 247

STLF-210-REQ MUL.AAV.MP4-50. CORE PROFILE LEVELS AND BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP4-60. MAIN PROFILE LEVELS AND BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP4-70. N-BIT PROFILE LEVELS AND BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP4-80. SCALEABLE TEXTURE PROFILE LEVELS AND BITRATE M M M M X

STLF-210-REQ MUL.AAV.MP4-160. RESOLUTIONS M M M M X

STLF-210-REQ MUL.AAV.MP4-170. FORMATS M M M M X


STLF-210-REQ MUL.AAV.AVC-10. CHROMA FORMAT M M M M X

STLF-210-REQ MUL.AAV.AVC-20. USE OF SEVERAL CHROMA FORMATS O O O O X

STLF-210-REQ MUL.AAV.AVC-30. SEQUENCE FIELD STRUCTURE M M M M X

STLF-210-REQ MUL.AAV.AVC-40. MOTION COMPENSATION M M M M X

STLF-210-REQ MUL.AAV.AVC-50. PROFILES M M M M X

STLF-210-REQ MUL.AAV.AVC-55. PROFILE APPLICATIONS M M M M X

STLF-210-REQ MUL.AAV.AVC-57. APPLICATION BITRATE M M M M X

STLF-210-REQ MUL.AAV.AVC-60. TRANSPORT LAYER DEFINITION M M M M X

STLF-210-REQ MUL.AAV.AVC-70. FRAME RATE M M M M X

STLF-210-REQ MUL.AAV.AVC-80. PICTURE RESOLUTION M M M M X

STLF-210-REQ MUL.AAV.AVC-90. HIGH DEFINITION O O O O X

STLF-210-REQ MUL.AAV.AVC-100. ENCODING DELAY M M M M X

STLF-210-REQ MUL.AAV.AVC-110. BITRATE MODE M M M M X

STLF-210-REQ MUL.AAV.AVC-120. DUAL PASS ENCODING M M M M X

STLF-210-REQ MUL.AAV.AVC-130. PROPRIETARY CODING TOOLS O O O O X

STLF-210-REQ MUL.AAV.AVC-140. ENCODER-DECODER INTEROPERABILITY M M M M X

STLF-210-REQ MUL.AAV.AVC-150. ENCODING HARDWARE REQUIREMENTS O O O O X

STLF-210-REQ MUL.AAV.AVC-160. DECODING HARDWARE REQUIREMENTS O O O O X

STLF-210-REQ MUL.AAV.WM-10. SYSTEM REQUIREMENTS M X

STLF-210-REQ MUL.AAV.WM-20. SOURCE FILES M X

STLF-210-REQ MUL.AAV.WM-30. CONVERSION OF MPEG-1 AND MPEG-2 FILES M X

STLF-210-REQ MUL.AAV.WM-40. CONVERT UNCOMPRESSED FORMAT O X

STLF-210-REQ MUL.AAV.RM-10. SYSTEM REQUIREMENTS M X

STLF-210-REQ MUL.AAV.RM-20. FIXED AND VARIABLE BITRATE CODIFICATION M X

STLF-210-REQ MUL.AAV.RM-30. TWO-PASS ENCODING M X

STLF-210-REQ MUL.AAV.QT-10. SYSTEM REQUIREMENTS M X

STLF-210-REQ MUL.AAV.DVX-10. DEFINITION M X

STLF-210-REQ MUL.AAV.DVX-20. ENCODING M X

STLF-210-REQ MUL.AAV.DVX-30. DECODING M X

STLF-210-REQ MUL.STR.MP2-10. PROGRAM STREAM-TRANSPORT STREAM M

STLF-210-REQ MUL.STR.MP2-20. REED-SOLOMON M

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

185 / 247

STLF-210-REQ MUL.STR.MP2-30. FEC-1/2, 3/4, 7/8 M

STLF-210-REQ MUL.STR.MP2-40. PCR M X

STLF-210-REQ MUL.STR.RTP-10. UDP PORT M M X

STLF-210-REQ MUL.STR.RTP-20. UDP PORT FOR RTCP M M X

STLF-210-REQ MUL.STR.RTP-30. MEDIA PER SESSION M M X

STLF-210-REQ MUL.STR.RTSP-10. SERVER AND CLIENT M X

STLF-210-REQ MUL.STR.RTSP-20. OPERATIONS O X

STLF-210-REQ MUL.STR.DTV-10. MPEG-2 COMPRESSION LEVELS AND PROFILES M X

STLF-210-REQ MUL.STR.DTV-20. VIDEO INPUT M X

STLF-210-REQ MUL.STR.DTV-30. AUDIO CHANNELS O X

STLF-210-REQ MUL.STR.DTV-40. PROGRAM STREAM MULTIPLEXING M X

STLF-210-REQ MUL.STR.DTV-50. TRANSPORT STREAM SUPPORT IN MULTIPLEXING M X

STLF-210-REQ MUL.STR.DTV-60. SIGNALLING MULTIPLEXING M X

STLF-210-REQ MUL.STR.DTV-70. SCRAMBLING FUNCTIONS IN MULTIPLEXER O X STLF-210-REQ MUL.STR.DTV-80. DATA INJECTION IN MULTIPLEXER O X

STLF-210-REQ MUL.STR.DTV-90. BITRATE MANAGEMENT IN MULTIPLEXER M X

STLF-210-REQ MUL.STR.WM-10. ENABLING A CLIENT IN UNICAST STREAMING M X

STLF-210-REQ MUL.STR.WM-20. ENABLING A SERVER IN UNICAST STREAMING M X

STLF-210-REQ MUL.STR.WM-30. MULTICAST STREAMING M X

STLF-210-REQ MUL.STR.WM-40. STREAM PROFILES DEFINITION M X

STLF-210-REQ MUL.STR.WM-50. MULTI-BITRATE ENCODING O X

STLF-210-REQ MUL.STR.WM-60. MULTI-BITRATE STREAMING O X STLF-210-REQ MUL.STR.WM-70. STATIC MULTI-BITRATE SUPPORT O X

STLF-210-REQ MUL.STR.QT-10. STREAM PROFILES DEFINITION M X

STLF-210-REQ MUL.STR.RV-10. STREAM PROFILES DEFINITION M X

STLF-210-REQ MUL.STR.RV-20. MULTI-BITRATE STREAMING O X

STLF-210-REQ MGT.MGM.CES-10. NETWORK AND ELEMENT MANAGEMENT M STLF-210-REQ MGT.MGM.CES-20. NETWORK RESOURCE CONTROL M

STLF-210-REQ MGT.MGM.CES-30. ACCOUNTING/BILLING O X

STLF-210-REQ MGT.MGM.CES-40. COMMON DATA MODEL M X

STLF-210-REQ MGT.MGM.CES-60. AUTHENTICATION, AUTHORIZATION, AND ACCOUNTING O X

STLF-210-REQ MGT.MGM.CES-70. ACCOUNTING AND BILLING O X

STLF-210-REQ MGT.MGM.CES-80. DIGITAL ASSET MANAGEMENT O X

STLF-210-REQ MGT.MGM.CES-90. CONTENT INTEGRITY AND SECURITY AND DIGITAL RIGHTS MANAGEMENT O X STLF-210-REQ MGT.MGM.CES-100. SERVICE LEVEL MANAGEMENT O X

STLF-210-REQ MGT.MGM.CES-120. FLEXIBLE MIX OF THE ENABLING SERVICES O X

STLF-210-REQ MGT.MGM.E2E-10. ASYMMETRIC SERVICES M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

186 / 247

STLF-210-REQ MGT.MGM.E2E-20. SERVICE SPEEDS M X

STLF-210-REQ MGT.MGM.E2E-30. USAGE CAPS M X

STLF-210-REQ MGT.MGM.E2E-40. MAXIMUM SUSTAINABLE SUBSCRIBER BANDWIDTH M

STLF-210-REQ MGT.MGM.E2E-50. MAXIMUM NUMBER OF SESSIONS ALLOWED PER SUBSCRIBER M

STLF-210-REQ MGT.MGM.E2E-60. PERMITTED DESTINATIONS FOR SUBSCRIBERS O X

STLF-210-REQ MGT.MGM.E2E-70. DEFAULT PROTOCOL FOR SUBSCRIBERS M

STLF-210-REQ MGT.MGM.E2E-80. DEFAULT DESTINATION FOR SUBSCRIBERS M X

STLF-210-REQ MGT.MGM.E2E-90. DEFAULT SUBSCRIBER BANDWIDTH M

STLF-210-REQ MGT.MGM.E2E-100. SINGLE HOST OR SUBNET NEEDED FOR SUBSCRIBERS M X

STLF-210-REQ MGT.MGM.E2E-110. RESTRICTED SUBSCRIBER (SINGLE DESTINATION ONLY) M X

STLF-210-REQ MGT.MGM.E2E-120. TOTAL SUBSCRIBER RESERVED BANDWIDTH M

STLF-210-REQ MGT.MGM.E2E-130. MINIMUM BANDWIDTH NEEDED FOR SERVICE PROVIDERS M

STLF-210-REQ MGT.MGM.E2E-140. MINIMUM QOS CHARACTERISTICS FOR SERVICE PROVIDERS M X

STLF-210-REQ MGT.MGM.E2E-150. VARIOUS PROTOCOL METRICS FOR SERVICE PROVIDERS M

STLF-210-REQ MGT.MGM.E2E-160. SUBSCRIBER PROTOCOL (E.G. IP, PPPOE) M X

STLF-210-REQ MGT.MGM.E2E-170. SERVICE PROVIDER PROTOCOL (E.G. IP, L2TP, ATM) M X

STLF-210-REQ MGT.MGM.E2E-180. SERVICE PROVIDER AUTHENTICATION M X

STLF-210-REQ MGT.MGM.E2E-190. IP ADDRESS ASSIGNMENT FOR SERVICE PROVIDERS M

STLF-210-REQ MGT.MGM.E2E-200. SERVICE PROVIDER TRANSPORT M

STLF-210-REQ MGT.MGM.E2E-210. MAXIMUM SIMULTANEOUS SESSIONS M X

STLF-210-REQ MGT.MON-10. CHANGES IN THE HARDWARE ERROR COUNT OF DEVICES M X

STLF-210-REQ MGT.MON-20. CPU AND MEMORY M X

STLF-210-REQ MGT.MON-30. PROCESS AVAILABILITY M X

STLF-210-REQ MGT.MON-40. DISK STATES M X

STLF-210-REQ MGT.MON-50. DISK FREE SPACE M X

STLF-210-REQ MGT.MON-60. CLUSTER TRANSITIONS (ADDITION AND REMOVAL OF CLUSTER MEMBERS) M X

STLF-210-REQ MGT.MON-70. CPU UTILIZATION M X

STLF-210-REQ MGT.MON-80. MEMORY UTILIZATION M X

STLF-210-REQ MGT.MON-90. PAGE AND SWAP FILE UTILIZATION M X

STLF-210-REQ MGT.MON-100. THROUGHPUT ON LAN DEVICES M X

STLF-210-REQ MGT.MON-110. DIRECT I/O AND QUEUE LENGTHS ON DISKS M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

187 / 247

STLF-210-REQ MGT.MON-120. LOOPING PROCESSES M

STLF-210-REQ MGT.MON-130. PROCESSES IN VARIOUS WAIT STATES M X

STLF-210-REQ MGT.MON.LEV-10. POLICY-ORIENTED SUPPLEMENTARY DATA M X

STLF-210-REQ MGT.MON.LEV-20. SPECIFIC UNITS OR PROCESSES PERFORMANCE M X

STLF-210-REQ MGT.MON.LEV-30. SYSTEM OR PROJECT PERFORMANCE M X

STLF-210-REQ MGT.MON.CF-10. WEB SITE CUSTOMER CONTACT POINTS O X

STLF-210-REQ MGT.MON.CF-20. CALL CENTERS CUSTOMER CONTACT POINTS O X

STLF-210-REQ MGT.MON.CF-30. FIELD ENGINEERS CUSTOMER CONTACT POINTS O X

STLF-210-REQ MGT.MON.CF-40. DATA NETWORK CONNECTIVITY M X

STLF-210-REQ MGT.MON.CF-50. REMOTE NETWORK ACCESS M X

STLF-210-REQ MGT.MON.CF-60. DATABASE INTEGRITY AND RELIABILITY M X

STLF-210-REQ MGT.MON.CF-70. CUSTOMER IDENTIFICATION AND TRANSACTION/ORDERING APPLICATIONS O X

STLF-210-REQ MGT.MON.CF-90. GLOBAL MESSAGING O X

STLF-210-REQ MGT.MON.CF-100. WEB SITE TECHNICAL PERFORMANCE O X

STLF-210-REQ MGT.MON.CF-120. CRITICAL APPLICATION RELIABILITY M X

STLF-210-REQ MGT.MON.CF-130. WEB SITE PERFORMANCE O X

STLF-210-REQ MGT.MON.CF-140. MESSAGE TRANSIT TIME O X

STLF-210-REQ MGT.MON.PRB-10. ACTIVE PROBES O X

STLF-210-REQ MGT.MON.PRB-20. PASSIVE PROBES O X

STLF-210-REQ MGT.MON.PRB-30. NETWORK PROBES O X STLF-210-REQ MGT.MON.PRB-40. SYSTEM AND PROCESS PROBES O X

STLF-210-REQ MGT.MON.QOS-10. QUALITY OF SERVICE M X

STLF-210-REQ MGT.MON.QOS-20. QOS NEGOTIATION M X

STLF-210-REQ MGT.MON.QOS-30. NEGOTIATION PROTOCOL M X

STLF-210-REQ MGT.MON.QOS-40. AGREEMENT M X

STLF-210-REQ MGT.MON.QOS-50. DATA PERSISTENCE M X

STLF-210-REQ MGT.MON.SRV-10. INPUT M X

STLF-210-REQ MGT.MON.SRV-20. H264 RAW BYTE FILE M X

STLF-210-REQ MGT.MON.SRV-30. ANALYSIS AND DISPLAY M X

STLF-210-REQ MGT.MON.SRV-40. OUTPUT M X

STLF-210-REQ MGT.OP.SLA-10. NETWORK AVAILABILITY M X

STLF-210-REQ MGT.OP.SLA-20. NETWORK DELAY M X

STLF-210-REQ MGT.OP.SLA-30. MESSAGE DELIVERY M X

STLF-210-REQ MGT.OP.SLA-40. MEAN RESPONSE TIME M X STLF-210-REQ MGT.OP.SLA-50. MEAN TIME TO RESTORE SERVICE M X

STLF-210-REQ MGT.OP.SLA-60. ORDERING SYSTEM RELIABILITY M X

STLF-210-REQ MGT.OP.SLA-70. END-USER INSTALLATION GUARANTEE M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

188 / 247

STLF-210-REQ MGT.OP.PRO-10. NOC M X

STLF-210-REQ MGT.OP.PRO-20. CHANGE INITIATION M X

STLF-210-REQ MGT.OP.PRO-30. CHANGE AUTHORIZATION M X

STLF-210-REQ MGT.OP.PRO-40. CHANGE SCHEDULING M X

STLF-210-REQ MGT.OP.PRO-50. CHANGE NOTIFICATION M X

STLF-210-REQ MGT.OP.PRO-60. CONFIGURATION CHANGE LOG M X

STLF-210-REQ MGT.OP.PRO-70. AUTOMATIC CONFIGURATION ARCHIVING M X

STLF-210-REQ MGT.OP.PRO-80. CONFIGURATION CHANGE M X

STLF-210-REQ MGT.OP.PRO-90. FIRMWARE CHANGE M X

STLF-210-REQ MGT.OP.PRO-100. HARDWARE CHANGE M X

STLF-210-REQ MGT.OP.PRO-110. LOGICAL ACCESS M X

STLF-210-REQ MGT.OP.PRO-120. PHYSICAL ACCESS M X

STLF-210-REQ MGT.OP.PRO-130. OUT-OF-BAND ACCESS M X

STLF-210-REQ MGT.OP.PRO-140. ACCESS TO LOG FILES M X

STLF-210-REQ MGT.OP.PRO-150. EQUIPMENT SPARES M X

STLF-210-REQ MGT.OP.PRO-160. EQUIPMENT MAINTENANCE CONTRACTS M X

STLF-210-REQ MGT.OP.PRO-170. VENDER CALL M X STLF-210-REQ MGT.OP.PRO-180. AUTOMATIC SOFTWARE UPDATE M X

STLF-210-REQ TLS.MOD.E2E-10. SATELLITE DELAY M X

STLF-210-REQ TLS.MOD.E2E-20. QOS SUPPORT M X

STLF-210-REQ TLS.MOD.E2E-30. IP ROUTING: SHORTEST PATH M X

STLF-210-REQ TLS.MOD.E2E-40. TCP IMPROVEMENTS M X

STLF-210-REQ TLS.MOD.E2E-50. ON-DEMAND CHANNELS RATES M X

STLF-210-REQ TLS.MOD.E2E-60. CONNECTION MODE M X

STLF-210-REQ TLS.MOD.E2E-70. TRAFFIC MANAGEMENT PROCEDURES M X

STLF-210-REQ TLS.MOD.E2E-80. TRAFFIC COMPRESSION PROCEDURES O X

STLF-210-REQ TLS.MOD.MUL-10. SATELLITE NETWORK TOPOLOGY M X

STLF-210-REQ TLS.MOD.MUL-20. SATELLITE NETWORK MULTICAST SUPPORT M X

STLF-210-REQ TLS.MOD.MUL-30. USERS' MULTICAST SUPPORT. O X

STLF-210-REQ TLS.MOD.MUL-40. MAXIMUM NUMBER OF SATELLITE HOPS. O X

STLF-210-REQ TLS.MOD.MUL-50. IP MULTICAST IN THE SATELLITE NETWORK. M X STLF-210-REQ TLS.MOD.MUL-60. MULTICAST MODE REQUIREMENT M X

STLF-210-REQ TLS.MOD.MUL-70. INTER-DOMAIN MULTICAST REQUIREMENT O X

STLF-210-REQ TLS.MOD.CNV-10. CENTRALIZED SIGNALLING M X

STLF-210-REQ TLS.MOD.CNV-20. DISTRIBUTED MULTICAST MEDIA (SEE ANNEX B) O X

STLF-210-REQ TLS.PER.SYS-10. E-MODEL R FACTOR SUPPORT FOR AUDIO QUALITY EVALUATION M X

STLF-210-REQ TLS.PER.SYS-20. DELAY EVALUATION M X

STLF-210-REQ TLS.PER.SYS-30. CALL SET-UP TIME EVALUATION M X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

189 / 247

STLF-210-REQ TLS.PER.SYS-40. PACKET LOSS MEASUREMENT M X

STLF-210-REQ TLS.PER.SYS-50. JITTER MEASUREMENT M X

STLF-210-REQ TLS.PER.SYS-60. ADVANTAGE FACTOR O X

STLF-210-REQ TLS.PER.SYS-70. PERCEPTUAL MEASUREMENTS M X

STLF-210-REQ TLS.PER.SYS-80. SUPPORT OF THE PROTOCOLS INVOLVED IN SATLIFE SERVICES. M X

STLF-210-REQ TLS.PER.SYS-90. TRAFFIC SIMULATION AND/OR GENERATION SUPPORT O X

STLF-210-REQ TLS.PER.SYS-100. DEVELOPMENT API SUPPORT O X

STLF-210-REQ TLS.PER.SYS-110. PLATFORM COMPATIBILITY O X

STLF-210-REQ TLS.PER.SYS-120. LICENCES O X

STLF-210-REQ TLS.PER.SIM-10. TCP ENHANCEMENTS SUPPORT M X

STLF-210-REQ TLS.PER.SIM-20. MULTICAST SUPPORT M X

STLF-210-REQ TLS.PER.SIM-30. SATELLITE NETWORK MODELS M X

STLF-210-REQ TLS.PER.SIM-40. IPV6 SUPPORT M X

STLF-210-REQ TLS.PER.SIM-50. TRAFFIC MODELS SUPPORT M X

STLF-210-REQ TLS.PER.SIM-60. PERFORMANCE O X

STLF-210-REQ TLS.PER.SIM-70. USER INTERFACE O X

STLF-210-REQ TLS.PER.SIM-80. PLATFORM COMPATIBILITY O X

STLF-210-REQ TLS.PER.SIM-90. LICENCES O X

STLF-210-REQ TLS.BIL-10. REAL TIME BILLING O X

STLF-210-REQ TLS.BIL-20. INTEGRATED BILLING O X

STLF-210-REQ TLS.BIL-30. TIME, VOLUME AND CASH BONUSES O X

STLF-210-REQ TLS.BIL-40. TIME OF DAY/DAY OF WEEK IMPACTS O X

STLF-210-REQ TLS.BIL-50. INVOICE THRESHOLD. O X

STLF-210-REQ TLS.BIL-60. FIXED CHARGES O X

STLF-210-REQ TLS.BIL-70. SETUP FEES O X

STLF-210-REQ TLS.BIL-80. FLEXIBLE RENEWAL METHOD O X

STLF-210-REQ TLS.BIL-90. COMPLEX TAXES O X STLF-210-REQ TLS.BIL-100. AUTOMATED CREDIT CARD PAYMENTS O X

STLF-210-REQ TLS.BIL-110. XML/XSL INVOICE CUSTOMISATION O X

STLF-210-REQ TLS.BIL-120. GROUP BILLING O X

STLF-210-REQ TLS.BIL-130. PROXY BILLING O X

STLF-210-REQ TLS.BIL-140. DESTINATION BILLING O X

STLF-210-REQ TLS.BIL-150. AUTOMATED PROVISIONING/DE-PROVISIONING O X

STLF-210-REQ TLS.BIL-160. TIERED RATING O X

STLF-210-REQ TLS.BIL-170. PREPAID CARD HANDLING O X

STLF-210-REQ TLS.BIL-180. PREPAID CARD BUNDLES O X

STLF-210-REQ TLS.BIL-190. USER LEVEL BILLING O X

STLF-210-REQ TLS.RAD-10. CENTRALIZE USER MANAGEMENT O X

STLF-210-REQ TLS.RAD-30. PROXY AND ROAMING O X

STLF-210-REQ TLS.RAD-40. MULTIPLE DICTIONARIES O X

STLF-210-REQ TLS.RAD-50. IDENTIFY INSTANCES OF FRAUD O X

STLF-210-REQ TLS.RAD-60. MANAGE GROUPS O X

STLF-210-REQ TLS.RAD-70. OFFER ACCOUNTS BASED ON QOS O X

STLF-210-REQ TLS.REP-10. REAL TIME STATISTICS O X

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

190 / 247

STLF-210-REQ TLS.REP-20. DAILY, WEEKLY, MONTHLY SUMMARIES O X

STLF-210-REQ TLS.REP-30. GRAPHS AND ANALYSIS O X

STLF-210-REQ TLS.REP-40. TOP TEN REPORTS O X

STLF-210-REQ TLS.REP-50. E-MAIL REPORTS O X

Table 17. Requirements summary

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

191 / 247

9. CONCLUSIONS In this deliverable, the essential set of requirements for the effective provision and improvement of DVB-RCS regenerative and transparent systems has been stated, as was studied by the different partners. These have considered the different services to be considered in the SATLIFE project, setting an additional value from the IBIS and AMERHIS projects regarding interactive applications provisioning. It has to be concluded that new video coding standards, management tools, QoS abilities and new networking options like multicast have to be applied to fulfil the service requirements. Many of the requirements stated are new to SATLIFE project, which offers innovative services. Along the document, a difference has been made from whether the requirements are completely new to SATLIFE or they consider improving the existing AMERHIS/IBIS setup. The definition of requirements for digital TV, multiconference, VoIP, LAN-to-LAN connection, Internet access, multicast access, etc. stated will facilitate the enhancement and optimisation of DVB-RCS. In addition, multimedia, streaming, VoD, nomadic access, etc. have been studied thoroughly with the goal of augmenting the availability of future functionalities and options. This whole set of requirements, which is the output of work package 2100 and starting point for the whole of the work package 2000, will serve as the guideline for future developments and requirements, which are to be described on a lower level at work package 2200, considering network aspects in depth. Hence, they will continue to be described and perfectly appointed in future deliverables and works by the project partners, in order to appropriately implement and integrate new multimedia services in the IBIS/AMERHIS environment, as well as improving what has already been done in these.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

192 / 247

A. ANNEX: SIMULATION TOOLS In this section we review the network simultators considered to be possible candidates to take part in the simulations of WP 2200. They are analyses against the defined requirements of the simulation tools. We conclude with a comparative table that permits us to decide the suitable simulation tools for SATLIFE. A.1 PARALLEL/DISTRIBUTED NETWORK SIMULATOR (PDNS) The PDNS, Parallel Distributed Network Simulator is a project developed by the MANIACS research group from the Georgia Technology [18]. It consists of a set of enhancements and extensions of the popular and widely used NS network simulator to cope with simulations with very large topologies involved. The approach applied in this project is to provide means to distribute the simulation on several workstations connected via a standard Ethernet network using the TCP/IP stack. The key goal is to minimize the modifications in the simulator core so that the distributed environment can take advantage of any improvements made on the NS simulator. The simulation topology and the nodes and agents behaviour in PDNS are defined within a TCL simulation script. PDNS scripts use nearly the same syntax as NS. The differences between the PDNS script syntax and the NS script syntax are only due to the need to include new elements to support the distributed simulation such as remote links. PDNS inherits all the power and flexibility of NS models. This means that every model generated for NS will also be applicable in a PDNS simulation. Moreover, all tools designed for analysing the NS event trace results (such as NAM, Network Emulator) will also be valid for PDNS results. A.2 GEORGIA TECH NETWORK SIMULATOR (GTNETS) The GTNetS network simulator was designed by the same research group author of PDNS to solve some of the problems that this simulator presented as a result as being written in two different programming languages, more information about the project can be found at [20]. The main objective for this simulator was to provide an easy to use simulation tool which can handle large network topologies. This is achieved by dividing the simulation model into several sub models so that they can be processed in different systems, thus distributing the load among them. This simulation tool has been completely built in C++ using an object-oriented approach and maintaining many of the ideas used in the PDNS simulator. A GTNetS based simulation consists of a C++ program that defines the network topology and the behaviour of its simulated endpoints, nodes and links. The GTNetS models for each element and protocols are written as static or dynamic libraries to be included in the program. A.3 SCALABLE SIMULATION FRAMEWORK (SSFNET)

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

193 / 247

SSF provides a single, unified interface for discrete-event simulation (the SSF API) so that object-oriented models that utilize and extend the framework can be portable across SSF-compliant simulation environments. The framework’s primary design goal was to support high performance simulation. SSF makes it possible to build models that are efficient and predictable in their use of space, able to transparently utilize parallel processor resources, and scalable to very large collections of simulated entities. The SSF host language is the language in which the user writes SSF model code: for example, Java or C++. An SSF model is a conformant program in the host language, which at some point instantiates one or more entities, processes, and channel endpoints. The modeller defines the behaviour of entities by associating with them processes that are to be executed on their behalf. For further information about the SSF framework and the DML language see [19] A.4 OPNET MODELER The OPNET Modeller network simulator was developed at MIT and introduced as commercial network simulator in 1987 by OPNET Technologies [17]. Nowadays it is the leading commercial network simulator and also a widespread tool in the academic community as a result of its University Program. OPNET Modeller includes an extensive library of detailed protocols, application models and commercial network devices (including hundreds of vendor specific and generic device models like routers, switches, workstations and packet generators). The models are written in C/C++ language using Finite State Machine logic of states in transitions. All models provided are open source so that users can easily create their own models taking advantage of its object-oriented approach. Moreover, OPNET Modeller also includes support for basic protocol functions to simplify writing protocol models. OPNET Modeller interface is based on a series of graphical editors which comprise all needed functionality to configure the network topology, nodes and processes. This simulation tools also provides integrated tools for analysis and visualization. A.5 NETWORK SIMULATOR 2 (NS-2) NS is a discrete event simulator targeted at networking research. NS provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks. The NS simulator is widespread in both research and teaching environments. The main advantages of NS are the huge number of protocols and models supported and its flexibility to add new models or modify the existing ones. NS simulations are usually described in TCL scripts although it also provides a graphic interface called NAM (Network AniMator) which can be used to build the network topology and to simulate some protocols and events just by using the mouse. NAM also includes functionality to show an animation of the network events happened during the simulation, such as packet flow, queuing and discards, protocol states etc.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

194 / 247

The NS-2 network simulator is an object-oriented inherits all the power from the previous version adding an object-oriented approach. NS-2 uses a mixed OTCL (object-oriented TCL) and C++ set of libraries. All the simulator engine and models source code is freely available and can be downloaded with the manuals from [16]. A.6 ANALYSIS OF THE SIMULATOR TOOLS ACCORDING TO THE IMPOSED

REQUIREMENTS A-6.1 PDNS TCP Enhancements PDNS inherits the models from NS so it has the same support to enhancements that NS. NS uses TCP agents which can be one-way agents or two-way agents. These agents can follow one the next schemes:

SENDER SIDE RECEIVER SIDE

One-way agent

Tahoe Reno

NewReno SACK (RFC 2018)

Vegas FACK

Sink DelACK

SACK (RFC 2018) SACK/DelACK

Two-way agent Reno

Table 18. TCP agents

NOTES:

- Tahoe (1988): slow start, congestion avoidance, Fast Retransmit. - Reno (1990): Tahoe + Fast Recovery + TCP Header Prediction - Vegas (1995): Congestion Window Control + modified slow start - NewReno (1999): Slight variation of Fast Recovery Reno algorithm - SACK (1996): Reno + Selective ACK - FACK: Reno + Forward ACK - Sink: TCP sink with one ACK per packet - DelACK: TCP sink with configurable delay per ACK - SACK/DelACK: TCP sink with selective configurable delay ACK

Multicast PDNS also inherits multicast models from NS. NS has a centralized multicast very similar to PIM-SM (joins/prunes are instantaneous). Satellite network models NS uses instances of a class called Mac to simulate multiple access control. Objects from this class can be configured to set different bandwidth lengths or the MAC modulation rate. A class called CsmaMac

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

195 / 247

extends the basic class to introduce carrier sense and backoff mechanisms. The specific satellite extensions contribute two more models: a basic MAC for links with only one receiver (Mac/Sat) and an implementation of unslotted Aloha (Mac/Sat/UnslottedAloha). NS people is now working hard on Mobile Networking and thus in other MAC protocols such as 802.11 MAC protocol (already included in the distributions) and Preamble based TDMA protocol (which currently, supports a single hop). NS distributions also include other MAC protocols associated to different protocol stacks (for example the GSM/GPRS, UTRAN/UMTS, etc.). PDNS is highly compatible with NS models so many of this contributed code may be used by PDNS. IPv6 Although there are quite a lot of papers from people using NS-2 to perform simulations on Mobile IPv6, there is no explicit information about NS-2 support to IPv6 functionalities. Traffic Models NS2 includes models for the following applications or traffic sources:

§ On/Off exponential traffic source § On/Off Pareto traffic source § Constant Bit Rate traffic source § Traffic trace driven traffic source § Telnet § FTP § Web cache

Moreover, PDNS compatibility with NS allows to use the traffic models developed in the IBIS project (see section D.1). Per formance PDNS is a simulator designed for very large network simulations (more than a few thousands of network elements). This is achieved by distributing the simulation load into several processors, thus saving CPU and memory. From the studies reported in [15] we extracted that PDNS was able to process 43712 PTS (Packet Transmissions per Second).

User inter face PDNS does not provide a specific user interface. Except for a few commands to support the parallelizing, the script syntax, graphic interfaces, etc. are the same as in NS and they are discussed in section D.3. Execution platform PDNS is a set of code modifications for ns version 2.27. You will also need the libSynk libraries, which can be compiled for Intel Linux, Intel Solaris, Sparc Solaris, SGI Irix, HP UX, Macintosh OS X, and Microsoft Windows systems. The scripts that define the simulation elements and events use TCL language. They can be executed on any platform with PDNS installed. L icenses

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

196 / 247

NS and PDNS are free and licensed under GPL. A-6.2 GTNetS TCP Enhancements GTNetS supports the following TCP variants with detailed logging of sequence (sequence and acknowledgement numbers):

§ Tahoe § Reno § NewReno § SACK

Multicast GTNetS uses NIx-Vector routing as the default packet routing mechanism. The NIx-Vector approach does not calculate an all–pairs shortest–path–first graph and does not create routing tables. Instead, the routes are calculated on demand, and cached using a compact representation called a NIx-Vector. While this is not in fact the way existing networks are designed, the resulting savings in simulator memory is believed to be a beneficial trade-off. For those simulation experiments that do require the existence and maintenance of routing tables, a routing–table based routing method is also included. Multicast NIx-Vectors are the only available solution for packet-level multicast routing. Satellite Network Models GTNetS does not have specific models for satellite MAC layer. IPv6 GTNetS does not support IPv6 yet. Traffic Models GTNetS includes models for the following applications:

§ FTP § Web browser § CBR traffic sources § On/Off traffic source (exponential, Pareto, empirical, uniform and normal) § Peer-to-peer networks (Gnuntella) § SYN-Flood and UDP Storm attacks

Per formance GTNetS is a simulator designed for very large network simulations (more than a few thousands of network elements). This is achieved by distributing the simulation load into several processors, thus saving CPU and memory. From the studies reported in [15]we extracted that GTNetS was able to process up to 40706 PTS.

User inter face

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

197 / 247

GTNetS is a set of libraries containing models for applications traffic, protocol, links, queues, etc. A GTNetS based simulation is a C++ program which defines the network topology, events and agents and uses the model libraries. For this reason, GTNetS does not include a specific editor. GTNetS supports very fine-grained control over the tracing of packets through the simulation; tracing can be enabled or disabled by node, protocols, or specific protocol endpoints. Furthermore, individual data items in each protocol header can be selectively enabled or disabled from being logged. GTNetS supports data collection using histograms and cumulative distribution functions. It also gathers and reports a large number of statistics regarding the performance of the simulator itself, including total number of events, total packets generated, total execution time, just to name a few. The GTNets simulator includes a graphical viewer for the simulation topology, with selective enabling and disabling of display for specified nodes and links. Execution platform GTNetS can be executed on both Linux and Windows platforms. On Linux platforms the C++ model libraries can be linked statically or dynamically. On Windows platforms only the first possibility is available. L icense GTNetS is freely available and does not have use restrictions. A-6.3 SSFNet TCP Enhancements SSFNet supports the following TCP variants:

§ Tahoe § Reno § Delayed ACK

Multicast SSFNet does not support multicast. Satellite Network Models SSFNet does not have specific models for satellite MAC layer. IPv6 SSFNet does not support IPv6. Traffic Models SSFNet includes models for the following applications:

§ WWW browsing

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

198 / 247

Performance SSFNet has been designed for large network simulations executed on share–memory multiprocessor systems, with global state available to all simulation threads. This emulator has been tested to be useful in simulations up to 100000 network nodes. User Inter face SSFNet uses a specific language called DML (Domain Modelling Language) to configure the simulations and a Java API to define new models. SSFNet includes a graphical IDE (Integrated Development Environment) which can help to configure the simulations as well as to display the simulation results animation. Execution platform As SSFNet runs over a Java core, simulations and models can be easily ported to many different platforms. L icense SSFNet is under a GNU GPL license A-6.4 NS-2 TCP Enhancements NS-2 has the same support to TCP enhancements as PDNS (see above). Multicast NS-2 has the same multicast support as PDNS (see above). Satellite Network Models NS-2 has the same support to MAC layer in satellite networks as PDNS (see above). IPv6 There is not explicit information about NS-2 support to IPv6 Traffic Models NS-2 includes the same traffic model as PDNS (see above). Per formance NS-2 has no parallelizing capabilities but it can work quite well in simulations up to a few thousand network elements. User Inter face NS-2 internals are written in C++ and OTcl languages. The scripts defining the network topology, forced events, agents, etc. have to be written in Tcl. There is an auxiliary graphic tool called NAM. This tool can play a network animation using the NS-2 simulation results but it also can be used to configure the network topology and agent features.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

199 / 247

License NS are free and licensed under GPL. A-6.5 OPNET TCP Enhancements OPNET Modeler supports the following TCP algorithms:

§ Full implementation of slow-start congestion § avoidance and congestion control mechanism § Nagle’s algorithm for Silly Window Syndrome § avoidance § Karn’s algorithm to avoid retransmission ambiguity § problem § Fast Retransmit and Fast Recovery § Window Scaling § Selective Acknowledgment § Increased Initial Window Option § Explicit Congestion Notification

The OPNET’s TCP model implements the following features:

§ Reliability: acknowledgments and retransmissions triggered by adaptively calculated retransmission timers

§ Flow control: Dynamic windowing of transmissions based on the availability of buffering resources at receiving nodes

§ Resequencing: Reordering of out-of-order segment arrivals § Connection Setup and Termination: Three-way handshake protocol to establish and

teardown connections § Persistence Time-out: Timer enabling sending node to send one byte data segments to

receiving node with a very small window size to poll remote socket OPNET includes some pre-configured TCP models. These models are listed below:

§ Tahoe § Reno § NewReno with SACK and Window scaling extensions § Architecture specific settings (e.g., Windows 3.5/4.0/2000, Solaris 2.6/2.7, HPUX

10.xx/11.xx) Moreover, OPNET TCP models can configure window sizes, MSS, timer values, acknowledgment schemes and extensions, attributes for enabling fast-retransmit, fast-recovery, window scaling, and/or selective acknowledgment options. Multicast OPNET Modeler supports both PIM-SM and SSM (RFC 2362) multicast routing. Satellite Network Models

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

200 / 247

OPNET Modeler has models for the following MAC protocols:

§ CSMA/CA & CSMA/CD § Aloha § Ethernet § Token Ring

IPv6 OPNET Modeler supports IPv6. Traffic Models OPNET Modeler includes a quite big list of application traffic models. These models have also configurable parameters. The setup options for the application models are further described in section D.2. The available models are listed below:

§ Custom application § Database § E-mail § FTP § HTTP § Remote Login § Print § Voice Application § Video Conferencing

Per formance OPNET is a simulator designed to provide very accurate models. This generates a lot of events for every packet hop, thus reducing the number of packets it can process per second. OPNET has no parallelizing capabilities. From the studies reported in [15] we extracted that OPNET was able to process up to 2778 PTS.

User Inter face OPNET models are written in C++ language, but the implemented models can be configured just through dialog boxes. OPNET has a friendly graphic interface that allows users to configure topologies, agents, etc. just by using menus and other graphic elements. OPNET provides different editors to setup the simulations and tools to visualize the simulation results, play animations, etc.

License OPNET software is available for FREE to the academic research and teaching community. A.7 CONCLUSIONS The table below summarises the simulation tools requirements support for each candidate and presents the relevance of these requirements in the SATLIFE project context:

Network Simulator Criter ia Relevance PDNS GTNetS SSFNet OPNET NS-2

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

201 / 247

TCP Enhancements High 5 3.9 2.5 4.5 5

Multicast High 4.5 3.5 0 4.5 4.5

Satellite Models High 4 0 0 2.5 4

IPv6 Low 4.5 0 0 4.5 4.5

Traffic Models High 3.25 2.75 1 4.25 3.25

Performance Low 4.5 5 4.5 2.75 3.9

User Interface Normal 1 2.25 2 4.75 1.5

Compatibility Normal 5 4.5 5 5 5

Licenses High 5 5 5 3 5

Table 19. Simulation tools requirements suppor t

NOTE: Features are measured in a five point scale, where 5 means excellent and 0 means no support. Considering this values, the proposed candidates are OPNET or NS2. For SATLIFE, NS2 is the preferred tool mainly because the licenses availability for the involved partners, and also, their previous experience with this tool.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

202 / 247

B. ANNEX: EMULATION TOOLS The following emulation tools will be considered and evaluated. In the following work packages one of this emulation tools will be selected to implement the emulation scenarios: NIST Net The NIST Net network emulator is a general-purpose tool for emulating performance dynamics in IP networks. The tool is designed to allow controlled, reproducible experiments with network performance sensitive/adaptive applications and control protocols in a simple laboratory setting. By operating at the IP level, NIST Net can emulate the critical end-to-end performance characteristics imposed by various wide area network situations (e.g., congestion loss) or by various underlying subnetwork technologies (e.g., asymmetric bandwidth situations of xDSL and cable modems). ONE (the Ohio Network Emulator) ONE (the Ohio Network Emulator) is a tool that enables researchers to emulate a network between a pair of interfaces on a single Solaris-based workstation. The user can control various features of the network, such as propagation delay, queueing characteristics and bandwidth. In addition, the tool interfaces with Satellite ToolKit (STK) to emulate variable propagation delays based on the orbits of satellites. DummyNet Dummynet is a flexible tool for bandwidth management and for testing networking protocols. It is implemented in FreeBSD but is easily portable to other protocol stacks. It works by intercepting packets in their way through the protocol stack, and passing them through one or more pipes which simulate the effects of bandwidth limitations, propagation delays, bounded-size queues, packet losses, etc.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

203 / 247

C. ANNEX: ANALYSIS OF THE CONFERENCE MODELS C.1 Required multipar ty conferencing Models. Signalling/Media Connectivity Multi-party conferencing may be supported in many different ways. In this section, the various multi-party conferencing models are reviewed. These models are defined in Internet-Drafts:

ü A Framework for Conferencing with the Session Initiation Protocol (draft-ietf-sipping-conferencing-framework-01).

ü A Call Control and Multi-party usage framework for the Session Initiation Protocol (draft-ietf-sipping-cc-framework-03)

ü Models for multiparty conferencing in SIP[Obsolete] (draft-ietf-sipping-conferencing-models-01.txt)

For each model, it is discussed how they are used and then analyzed their relative benefits and drawbacks for the satellite environment, such a way that some of them will be discarded since the satellite network only supports the models that do not require two satellite hops for delivering the media data (audio, video, text, etc.). Hence, at this point, it will be described, in a consistent and complete fashion, the various multi-party conferencing models that SATLIFE should support. For each model, we discuss how the model works and, where it is taken from the Drafts, its suitability for SATLIFE. For those suitable and proposed models it is also discussed how well the model scales. The models can be classified into two groups:

ü Loosely Coupled Conference: A loosely coupled conference is a conference without coordinated signalling relationships amongst participants. Loosely coupled conferences frequently use multicast for distribution of conference memberships.

ü Tightly Coupled Conference: A tightly coupled conference is a conference in which a single user

agent, referred to as a focus, maintains a dialog with each participant. The focus plays the role of the centralized manager of the conference, and is addressed by a conference URI. It handles the signalling, and depending on the model also the media.

C.2 Tightly Coupled Conference: End System Mixing or end point server . In this model, user A calls user B, and they have a conversation. At some point later, user A decides to conference in user C. To do this, user A calls user C, using a completely separate call. This call uses a different Call-ID, different tags, etc. There is no call set up directly between users B and C. User A receives media streams from both B and C, and mixes them. Then, user A sends a stream containing A's and C's streams to B, and a stream containing A's and B's streams to C. C-2.1 Suitability for SATLIFE This model is not suitable for satellite networks since more than one satellite-hop is required, so it is not more studied here.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

204 / 247

C.3 Loosely Coupled Conference: Large-Scale Multicast Conferences Large-scale multicast conferences were the original motivation for both the Session Description Protocol (SDP) and SIP. In a large-scale multicast conference, one or more multicast addresses are allocated to the conference (more than one may be needed if layered encodings are in use). Each participant joins those multicast groups, and sends their media to those groups. Signalling is not sent to the multicast groups. The sole purpose of the signalling is to inform participants of which multicast groups to join, so they can learn them from: another participant through SIP (establishing a point-to-point SIP relationship with him), or another way (no signalling will be required at all), such as a web page, mail, etc. Hence, if there are N participants, each participant sends a single media stream to the group, and receives up to N-1 streams at any time. Note that the number of streams that a user will receive depends on who is actually sending at any given time. If the stream is audio, and silence suppression is utilized, the number of streams a user will receive at any given time is equal to the number of users talking at any given time. Even for very large conferences, this is usually just a small number of users. Large-scale multicast conferences are usually pre-arranged, with specific start and stop a time (which is why this information exists in SDP). Protocols such as the Session Announcement Protocol (SAP) are used to announce these conferences. However, multicast conferences do not need to be pre-arranged, so long as a mechanism exists to dynamically obtain a multicast address. SAP itself was originally used for this purpose, but this has been supplanted by the malloc architecture [RFC2908 – The internet multicast address allocation architecture]. C-3.1 Suitability for SATLIFE It is supposed in this model that all the terminals in the conference are fully multicast enabled and they perform audio/video mixing or switching as needed (it is also possible to include non-multicast terminals by means of conference bridges). This model is well suited for high capacity terminals and minimizes the total bandwidth in the network (if restricted the number of simultaneous video flows). Moreover, within the mixed terrestrial plus satellite network topology, this is the preferred model because it takes advantage of the intrinsic multicast nature of satellite transmission. Audio mixing, a high CPU consuming process, must be done in each terminal. For video, switching is desired (select a video source to present to the user from the video pool) or study the possibility of split video sources in different multicast groups. C-3.2 Scalability The scalability of conferences of this type can be excellent, especially for audio conferences. However, it is scalable under the assumption that multicast itself can scale to very large groups. Scaling is a bit harder for videoconferences. Unlike voice, where silence suppression allows for no data to be sent during periods of inactivity, the same is not the case for video. This makes it hard to scale without flooding users with lots of video packets. C.4 Tightly Coupled Conference: Centralized Conference Server (media and signalling may be

different servers) Centralized conference servers closely mirror dial-in conference bridges in the traditional PSTN. A dial-in conference server acts as a normal UA. Users call it, and the server maintains point to point Signalling

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

205 / 247

relationships with each user that calls in. The server takes the media from the users who dial into the same conference, mixes them, and sends out the appropriate mixed stream to each participant separately. Each UA (for example, A, B and C) has a point to point SIP and RTP relationship with the conference server. Each call has a different Call-ID. Each user sends their own media to the server: • The media delivered to user A by the server is the media mixed from users B and C. • The media delivered to user B by the server is the media mixed from users A and C. • The media delivered to user C by the server is the media mixed from users A and B. The conference is identified by the request URI of the calls from each participant. This provides numerous advantages from a services and routing point of view. For example, one conference on the server might be known as sip:[email protected]. All users who call sip:[email protected] are mixed together. Dial-In conference servers are usually associated with pre-arranged conferences. However, the same model applies to ad-hoc conferences. An ad-hoc conference server creates the conference state when the first user joins, and destroys it when the last one leaves. The SIP and RTP interfaces are identical to the pre-arranged case. C-4.1 Suitability for SATLIFE This model implies two satellite-hops for the media data so, by its own, it is not usable in the satellite network. C.5 Tightly Coupled Conference: Centralized Signalling, Distr ibuted Mixing Media In this conferencing model, there is a centralized controller, as in the dial-in and dial-out cases. However, the centralized server handles signalling only. The media is still sent directly between participants, using either multicast or multi-unicast. Multi-unicast is when a user sends multiple packets (one for each recipient, addressed to that recipient). The case of multicast will be studied better in the next model. Interestingly, this conference model is possible with baseline SIP and it is referred to as "Decentralized Multipoint Conference" in H.323. In a distributed mixed conference, there is still a centralized server which implements the focus, conference policy server, and media policy server. However, there are no centralized mixers. Rather, there are mixers in each endpoint, along with a conference policy server. The focus distributes the media by using third party call control to move a media stream between each participant and each other participant. As a result, if there are N participants in the conference, there will be a single dialog between each participant and the focus, but the session description associated with that dialog will be constructed to allow media to be distributed amongst the participants. In the case of satellite network with multicast support the multicast option is applied. If multicast is used, one or more multicast addresses are allocated to the conference (more than one may be needed if layered encodings are in use). Each participant joins those multicast groups, and sends their media to those groups. Note that users can join a conference of this type without being invited. All they

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

206 / 247

need is the multicast addresses, ports, and codecs being used. These can be obtained through any number of means, including SAP. SDP conference descriptions can even be obtained from web pages, for example. Once the addresses are obtained, the user simply joins the appropriate multicast groups. Note that absolutely no SIP signalling is required in this case. If the user has not learnt the multicast addresses by another way, SIP signalling will not be sent to the multicast groups but to the conference server, which will inform participants of which multicast groups to join. C-5.1 Suitability for SATLIFE Although the signalling process will require more than one satellite-hop, that is not a restricted issue in our environment since the “suitability parameter” is the number of hops for the delivering of the media data, and this is maintained to one. This model is required because it does use the multicast network support. C-5.2 Scalability The scalability of this conference model is like the “Large-Scale Multicast Conferences” model. From a media perspective, the conference server never even touches a single media stream and it is not needed each time a new user wants to add a conference, since it has been said already that contacting with the conference server is not the only way to learn the multicast address. C.6 Tightly Coupled Conference: Multiple Media Servers (Multiple-MCUs or Cascaded Mixers) It has been defined a new scenario in “draft-ietf-sipping-conferencing-framework-01” that was previously adopted and defined in ICEBERGS IST project. In this model, one or more MCU’s (Multipoint Control Units) or mixers exist on the network. Terminals send multimedia streams to the MCUs, which collects the streams, manipulates them and generates multicast flows received by all terminals. This model minimizes the bandwidth in comparison to the unicast conference and simplifies the terminal requirements. The mixed satellite-terrestrial network and the relatively high satellite delay imply that it is not desirable to send unicast audio/video from one terminal to a remote MCU through a satellite and then receive the composite signal again through the satellite link.

Figure 23. Multiple MCU architecture example

C-6.1 Suitability for SATLIFE

Satellite Network Multicast

��

��

��

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

207 / 247

Although the signalling process may require more than one satellite-hop, that is not a restricted issue in our environment since the “suitability parameter” is the number of hops for the delivering of the media data, and this is maintained to one. This model is required because it does use the multicast network support and optimize the mixing capabilities imposed to the end user machines. This conference model is fully compatible with the previous one, in the sense that some multicast users might be involved in the conference without a connection to a MCU. C-6.2 Scalability On the one hand, the scalability of this model is limited by the bandwidth and processing power of the MCU. If there are N local-participants in a conference, M of which are sending media streams, the MCU will need to manage N signalling relationships, perform M RTP stream decodes, and N RTP stream encodes (assuming M > 0). The encoding is the primary processing bottleneck, and the sending of the N media streams is the primary bandwidth bottleneck. However, MCUs can be built using heavy-duty hardware, and have high bandwidth access.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

208 / 247

D. ANNEX: DETAILED TRAFFIC MODELS The purpose of this annex is to review the traffic models for the envisaged scenarios for the SATLIFE project as an update of the ones proposed in IBIS project. These IBIS models have been extended with the built in the analysed simulation tools. D.1 IBIS Traffic Models In IBIS deliverable D20, traffic models were provided for the individual components of each IBIS scenario, and, when possible, traffic models for the aggregate traffic sources were also provided. Traffic models were described for the following applications/services:

- VOIP - INTERNET

o WEB SURFING o E-MAIL o FTP

- INTERACTIVE TV o PAY-PER VIEW/PAY TV o TELEVOTING o TELESHOPPING o BET SHOW

- LAN TO LAN INTERCONNECTION - VIDEOCONFERENCE/TELE-EDUCATION

See IBIS D20 for a detailed description of all these services. D.2 Application Traffic Models Built in OPNET Simulator Each application generates its own sort of traffic thus causing a different set of problems in the underlying network. Moreover, the same application may behave in a different way in different contexts so it is important to be able to accurately model the traffic patterns generated by a variety of applications. In this section we review the application models available in OPNET simulator, summarizing the parameters that characterize each one as well as their configuration possibilities. The application models available in OPNET simulator are listed below:

§ File transfer § Sending/Receiving e-mail § Remote login by telnet § Video conferencing involving images exchanges § Database queries and updates § Web browsing § Print job submission

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

209 / 247

§ On-Off voice model § Custom model for user-definable multi-tier application.

D-2.1 Application Models configurability All applications start a session at the specified application start time (100 seconds after the start of a simulation is the default). This session remains active until the specified application stop time (end of simulation is the default). D-2.1.1 File transfer (FTP) An FTP application enables file transfers between a client and a server. FTP has two basic commands for transferring a file: “get” and “put” . The “get” command triggers the transfer of a file from a remote server. The “put” command sends a file to a remote server. The configurable FTP attributes are described below:

§ Symbolic Server Name: Symbolic name of the file server to which the clients connect § File Size (random var iable, average specified): Size of a file being transferred § Type of Service (list): Quality of service parameter used to assign a priority to the traffic

generated by this application. § Command Mix [GET/total]: Ratio of GET command to the total number of commands. § Inter-Requests Time (random var iable, average specified): Time between subsequent

file requests § RSVP Parameters: RSVP parameters for making bandwidth reservations.

NOTE:

- Several FTP agents with different configurations can be associated to one machine. This represents several users generating FTP traffic simultaneously.

D-2.1.2 E-mail E-mail packages use a combination of SMTP (Simple Mail Transfer Protocol) and POP (Post Office Protocol). Both SMTP and POP use TCP as the underlying transport. SMTP transfers an e-mail from the client to the mail server. If TCP is chosen for the transport protocol, then a single TCP connection is opened between the client and the server, and data is transferred based on the configured send-and-receive rate attributes. The message transfer is modelled between the client and the server, not from the client to another client. The configurable e-mail attributes are described below:

§ Send Interarr ival Time (random var iable, average specified): Time between e-mails sent from the client to the server.

§ Send Group Size (random var iable, average specified): Number of e-mail messages grouped before transmission.

§ Receive Interarr ival Time: Time between e-mails received from the server at the client. § Receive Group Size (random var iable, average specified): Number of e-mail messages

grouped before reception. § Symbolic Server Name: Symbolic name of the server to which the client connects. § E-mail Size (random var iable, average specified): Average size of an e-mail message.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

210 / 247

§ Type of Service (list): Quality-of-service parameter for assigning priority to this

application's traffic. § RSVP Parameters: RSVP parameters for making bandwidth reservations.

D-2.1.3 Remote Login A Remote Login application models a remote login scenario. Users login to different machines, interact with the operating systems of the remote hosts. The commands they enter and the feedback they receive generate traffic on the network. TCP is the default transport protocol. The configurable Remote Login attributes are described below:

§ Inter-Command Time (random var iable, average specified): Time between commands issued within a remote login session.

§ Terminal Traffic (random var iable, average specified): Average amount of data transferred per command.

§ Host Traffic (random var iable, average specified): Average amount of data returned in response to a command.

§ Symbolic Server Name: Symbolic name of the server to be contacted. § Type of Service (list): Quality-of-service parameter for assigning priority to this

application's traffic. § RSVP Parameters: RSVP parameters for making bandwidth reservations.

D-2.1.4 Video Conferencing A video conferencing application lets users transfer streaming video frames across the network. UDP is the default transport protocol used for video conferencing. The configurable video conferencing attributes are described below:

• Frame Interar r ival Time Information § Incoming Stream Interarr ival Time (random var iable, average specified): Time

between frames generated within a video conferencing session from the destination. § Outgoing Stream Interarr ival Time (random var iable, average specified): Time

between frames generated within a video conferencing session from the source. • Frame Size Information

§ Incoming Stream Frame Size (random var iable, average specified): Average size of an incoming video frame.

§ Outgoing Stream Frame Size (random var iable, average specified): Average size of an outgoing video frame.

§ Symbolic Destination Name: Symbolic name of the destination to which the client connects.

§ Type of Service (list): Quality-of-service parameter for assigning priority to this application's traffic.

§ RSVP Parameters: RSVP parameters for making bandwidth reservations.

D-2.1.5 Database A database application enables the user to store information. Database operations are divided into two categories:

1) A database entry

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

211 / 247

2) A database query.

A database entry results in a fixed amount of data being written into the database. A database query results in the client issuing a query, and the server responding with some data. The default transport protocol for the database application is TCP. The configurable database attributes are described below:

Transaction Mix: Ratio of queries to the total number of transactions (queries + updates). Transaction Interarr ival Time (random var iable, average specified): Time between transactions. Transaction Size: Average size of an entry or a response to a query. Symbolic Server Name: Symbolic name of the server the client contacts. Type of Service (list): Quality-of-service parameter for assigning priority to this application's traffic. RSVP Parameters: RSVP parameters for making bandwidth reservations. D-2.1.6 Web browsing The HTTP application Web browsing. The user downloads a page from a remote server. The page contains text and graphic information (also referred to as “ inline objects”). TCP is the default transport protocol for HTTP. Each HTTP page request may result in opening multiple TCP connections for transferring the contents of the inline objects embedded in the page. The configurable HTTP application attributes are described below:

• HTTP Specification § HTTP Version (list): The name of the supported HTTP version. § Max Connections (value): Maximum number of simultaneous TCP connections that

HTTP can spawn. § Max Idle Per iod (value): Maximum idle time after which a connection is torn down. § Pipeline Buffer Size: The number of HTTP requests that can be buffered together in a

single application message. This attribute is only used for HTTP version 1.1. § Page Interarr ival Time (random var iable, average specified): Time between

subsequent pages that a user browses. • Page Proper ties

§ Object size (random var iable, average specified): Average size of an object. § Number of Objects (random var iable, average specified): Number of inline objects

contained in a page. (objects/page) § Location: The symbolic name of the server on which the object is located.

• Server Selection § Initial Repeat Probability (random var iable, average specified): Probability that a user

would request the next page from the same server. § Pages per Server (random var iable, average specified): Number of pages accessed

consecutively on the same server. § RSVP Parameters: RSVP parameters for making bandwidth reservations. § Type of Service (list): Quality-of-service parameter for assigning priority to this

application traffic.

D-2.1.7 Printing

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

212 / 247

A print application allows the user to initiate print jobs. TCP is the default transport protocol used for this application. Each print job creates a new TCP connection with the printer. The configurable print application attributes are described below:

§ Print Interarr ival Time (random var iable, average specified): Time between print jobs issued by the user.

§ File Size (random var iable, average specified): Average size of the file sent for printing. § Symbolic Pr inter Name: Symbolic name of the printer. § Type of Service (list): Quality-of-service parameter for assigning priority to this

application's traffic.

D-2.1.8 Voice A voice application enables two clients to establish a virtual channel over which they can communicate using digitally encoded voice signals. UDP is the default transport protocol used for this application. The voice data arrives in spurts that are followed by a silence period. Encoding schemes can be specified for the voice-to-packet translation. The configurable voice application attributes are described below:

§ Silence Length: Silence length for the incoming and outgoing calls along with the associated distributions.

§ Talk Spurt Length: Length of a talk spurt for the incoming and outgoing calls along with the associated distributions.

§ Symbolic Destination Name: Symbolic destination name of the client. § Encoder Scheme: Encoding scheme in effect at the client. § Voice Frames per Packet: Number of voice frames that can be sent in a single packet. § Type of Service (list): Quality-of-service parameter for assigning priority to this

application's traffic. § RSVP Parameters: RSVP parameters for making bandwidth reservations. § Traffic Mix: Proportion of traffic that should be modelled analytically instead of

discretely. Higher amounts of analytic traffic decrease simulation run times but may limit the statistics that can be collected. Setting this attribute to all background has the same effect as configuring this traffic as an IP traffic flow.

D-2.1.9 Custom application The custom application is a generic model that can represent a broad class of applications. It can be used when the application of interest does not correspond to any of the standard applications. The custom application provides attributes that allow you to configure various aspects of the application in detail.

A custom application can be used to represent any number of tiers, including a two-tier application. This section describes the Custom Application model and how it can be configured to represent different application architectures.

An application can be considered at different levels:

• Application: A software product that is used to perform a task. Examples include e-mail, FTP, Database, and HTTP.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

213 / 247

• Application architecture: The structure used to implement an application. For example, an FTP

application may be implemented according to a client-server architecture, where the client requests a file and the server responds with the file.

• Task: A basic unit of user activity within the context of an application. For example: reading an e-mail message, making a calendar entry, or obtaining records from a database. The start and end of a task must be defined. If a task involves some user “ think time” (user-activity time wherein a user considers incoming data), be sure to factor “ think time” into the total task response time.

• Phase: An interval of related activity that is contained within a task, e.g., a data transfer phase and a processing phase are specific phases of a task.

• Step: A phase consists of many steps, e.g., obtaining a simple record from a database server involves two steps: first, sending a request to the database server, and second, receiving the corresponding response.

• Tier: A single software process responsible for executing some or all of the steps in a task.

OPNET modeller custom application model provides a base for customizing client-server application. A custom application model has the following characteristics:

§ More than two hosts can be involved in data transfers and processing. You can specify the sequence of hosts involved in each task. The sequence begins with a workstation, ends with a server or workstation, and uses any collection of clients or servers in between.

§ Client-Server interaction is task-based. A task consists of many interactions between a client and a server, or between successive servers. The basic task consists of many “phases” . Each phase consists of either a data transfer or a processing event. Data transfer or processing event can occur at any device. This workstation-type device becomes a source node for the application. Subsequent phases are typically set up to occur in a chain, where the destination of one data transfer phase becomes the source of the next data transfer phase. Transfer of a request from the client to the server is one step. Transfer of a response from the server to the client is another step. Steps can be either serial or concurrent in nature: serial requires that a response is received before the next request is sent; concurrent allows a series of requests or a series of responses to be sent independently of each other. The entire task is complete only when the last phase of the task has been completed. A task need not terminate at the originating node, though this is a common case. Wherever the task completes, a “Response Time” statistic is measured to record the time separating the initiation of the task, (e.g., when a simulated user presses the “OK” button), to its completion (e.g., when the “hourglass” disappears).

Custom Applications are configured using two global objects: the Application Definition Object and the Task Definition Object. Tasks, which function as the building blocks of the custom application, are defined in the Task Definition Object. Once the tasks have been defined, they are used to build (define) the custom application in the Application Definition Object.

There are two ways to configure tasks: the first way is to manually configure the task phase by phase and the second way is to use ACE to record the task details then specify the ACE filename in the Task Specification Table. Detailed information on ACE is available in the ACE documentation. The configurable attributes for manual configuration are listed below:

§ Star t Phase After : Indicates when the phase begins. A phase can begin at the start of the application or it can begin after the previous phase ends.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

214 / 247

§ Source (list): A symbolic name that refers to the phase's source node. (Symbolic

names are resolved when the custom application is used in a project.) § Destination (list): A symbolic name that refers to the phase's destination node. § SourceŁŁŁŁ Dest Traffic: A compound attribute that describes the requests sent from the

source to the destination. This attribute specifies:

- Distributions for the size of requests, in terms of the number of packets sent and the size of each packet.

- Distributions for the time between successive requests at the source. This represents the time needed to generate each request.

- A distribution for the number of request/response pairs in the exchange. (Use the “constant” distribution if you want a specific number of requests and responses to occur. A single request and response is a common case; use the “constant” distribution with a mean of 1.0 to set up such a data transfer). For a processing phase, set the number of requests to 0.

- A distribution for initial processing time when the phase begins: in a data transfer phase, this is the time before the first request is sent, whereas in a processing phase, this is the total processing time.

§ DestŁŁŁŁ Source Traffic: A compound attribute that describes the responses sent from the destination to the source. If this attribute is set to “No Response”, requests will be generated based on the Interrequest Time distribution in the “Source->Dest Traffic” attribute but no responses will be returned to the device sending the requests.

§ REQ/RESP Pattern: This attribute specifies if each request is followed by a response “REQŁ RESP” or if several requests can be sent without waiting for a response “REQŁ REQŁ ” . If each request is followed by a response, the source is “blocked” from sending further requests until it receives a response.

§ End Phase When: This attribute specifies the activity that indicates the ending of the phase. This attribute has four possible values:

- When the final request leaves the source - When the final request arrives at the destination - When the final response leaves the destination - When the final response arrives at the source § Transport Connection: A compound attribute that specifies the transport connection

policy and limit used for the phase. The Policy attribute specifies how requests use connections; connections can be reused, or each request can use a new connection. The Limit attribute specifies the maximum number of connections that can be established.

D-2.2 User Profiles Profiles describe the activity patterns of a user or group of users in terms of the applications used over a period of time. It is possible to define several different profiles for a given LAN or workstation. These profiles can represent different user groups - for example, you can have an Engineering profile, a Sales profile and an Administration profile to depict typical applications used for each employee group. Profiles can execute repeatedly on the same node. OPNET enables you to configure profile repetitions to run concurrently (at the same time) or serially (one after the other). Profiles contain a list of applications. You can configure the applications within a profile to execute in the following manner:

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

215 / 247

§ At the same time § One after the other - in a specific order you determine § One after another - in a random order

D.3 Application Traffic Models Built in NS As stated previously, the NS simulator provides some application models to be attached to the simulations. In this section we will review these models, presenting their configurable parameters. D-3.1 Exponential On/Off traffic source Generates traffic according to an Exponential On/Off distribution. Packets are sent at a fixed rate during on periods, and no packets are sent during off periods. Both on and off periods are taken from an exponential distribution. Packets are constant size. The member variables that parameterize this traffic source are:

§ Packet size (value) § Burst Time (exponential random variable average) § Idle Time (exponential random variable average) § Rate (value)

NOTE: The Exponential On/Off generator can be configured to behave as a Poisson process by setting the Burst Time to 0 and the variable Rate to a very large value. The C++ code guarantees that even if the burst time is zero, at least one packet is sent. Additionally, the next interarrival time is the sum of the assumed packet transmission time (governed by the variable Rate) and the random variable corresponding to Idle Time Therefore, to make the first term in the sum very small, make the burst rate very large so that the transmission time is negligible compared to the typical idle times.

D-3.2 Pareto On/Off traffic source Generates traffic according to a Pareto On/Off distribution. This is identical to the Exponential On/Off distribution, except the on and off periods are taken from a Pareto distribution. These sources can be used to generate aggregate traffic that exhibits long range dependency. The member variables that parameterize this object are:

§ Packet size (value) § Burst Time (Pareto random variable average) § Idle Time (Pareto random variable average) § Rate (value) § Shape (value)

D-3.3 CBR traffic source Generates traffic according to a deterministic rate. Packets are constant size. Optionally, some randomizing dither can be enabled on the inter-packet departure intervals. The member variables that parameterize this object are:

§ Packet size (value) § Rate (value) § Interval (value)

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

216 / 247

§ Random (binary value): If set to 0 inter-packet departure time will be constant, otherwise a

little randomization will be introduced. § Maxpkts (value): Sets the maximum number of packets to be sent

NOTE: The setting of a CBR object's Rate and Interval are mutually exclusive (the interval between packets is maintained as an interval variable in C++, and some example scripts specify an interval rather than a rate). In a simulation, either a rate or an interval (but not both) should be specified for a CBR object.

D-3.4 Traffic Trace dr iven traffic source Generates traffic according to a trace file. Each record in the trace file consists of 2 32-bit fields in network (big-endian) byte order. The first contains the time in microseconds until the next packet is generated. The second contains the length in bytes of the next packet. D-3.5 FTP This model works by advancing the count of packets available to be sent by a TCP transport agent. The actual transmission of available packets is still controlled by TCP's flow and congestion control algorithm. The FTP model, implemented in OTcl, simulates bulk data transfer. The available methods for the Application/FTP class are listed below:

§ attach-agent: attaches an Application/FTP object to an agent. § Star t: start the Application/FTP by calling the TCP agent’s send(-1) function, which

causes TCP to behave as if the application were continuously sending new data. § Stop: stop sending. § produce n: set the counter of packets to be sent to n. § producemore n: increase the counter of packets to be sent by n. § send n: similar to producemore, but sends n bytes instead of packets.

Configuration Parameters are: § Maxpkts: The maximum number of packets generated by the source.

D-3.6 Telnet This model works by advancing the count of packets available to be sent by a TCP transport agent. The actual transmission of available packets is still controlled by TCP's flow and congestion control algorithm. Application/Telnet objects generate packets in one of two ways. If the member variable interval is non-zero, then inter-packet times are chosen from an exponential distribution with average equal to interval. If interval is zero, then inter-arrival times are chosen according to the tcplib distribution (see tcplib-telnet.cc). The start method starts the packet generation process. Configuration Parameters are:

§ interval: The average inter-arrival time in seconds for packets generated by the Telnet object.

D-3.7 Web cache All applications described above are “virtual'” applications, in the sense that they do not actually transfer their own data in the simulator; all that matter is the size and the time when data are transferred. Sometimes we may want applications to transfer their own data in simulations. One such example is web

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

217 / 247

caching, where we want HTTP servers to send HTTP headers to caches and clients. These headers contain page modification time information and other caching directives, which are important for some cache consistency algorithms. NS Web cache model involves three different models: Page pools, web server model and web client model and cache model.

§ PagePool and its derived classes are used by servers to generate page information (name, size, modification time, lifetime, etc.), by caches to describe which pages are in storage, and by clients to generate a request stream.

§ Server models behaviour of a HTTP server. Its configuration is very simple. All that a user needs to do is to create a server, attach a PagePool and wait. A Server object waits for incoming requests after simulation starts. A Server object accepts two types of requests: GET and IMS (If-Modified-Since).

§ Client models behaviour of a simple web browser. It generates a sequence of page requests, where request interval and page IDs are randomized. It's a pure OTcl class inherited from Http.

These three models are very complex and provide a big set of variables and commands to setup the Web Cache model. For further information about these models, see [16].

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

218 / 247

E. ANNEX: Methods for Measur ing Speech Quality There are several methods for measuring speech quality. The most obvious method is to have a large group of people subjectively rate the quality of a telephone call. The mean average of a group's ratings under a certain set of test conditions is then used as a quality score. This is known as Mean Opinion Score (MOS) testing. MOS testing has become the "benchmark" for determining the accuracy of speech quality measurement methods. However, it is very impractical to use in most situations. A repeatable mathematical method that can be automated with software is needed. Because of the non-linear and time-variant nature of VoIP networks, traditional metrics such as signal-to-noise ratios do not prove to be accurate when compared with subjective test results. However, three very effective and accurate methods have emerged: PSQM+, PAMS, and PESQ. These methods are mathematical algorithms that are implemented in software. They are based on perceptual models and are accurate in predicting scores from subjective testing. Each method performs a comparison between two voice signals: an original input signal, and an output signal that represents the input signal after it has been processed by a system or transmitted across a network. The comparison is performed in a perceptually-modelled domain, and determines audible errors in the output signal. PSQM and PSQM+ The Perceptual Speech Quality Measurement (PSQM) was developed by researchers at KPN in the Netherlands. It was approved by the ITU in 1996 as recommendation P.861, and was the first perceptual speech measurement technique to be accepted as an international standard. Although PSQM was designed to objectively measure speech quality across low bit-rate codecs, it became popular as a way to measure speech quality across entire VoIP networks. One PSQM drawback, however, is that it does not accurately report the impact of distortion when that distortion is caused by packet loss or other types of transmission impairments. Therefore, an improved version known as PSQM+ was developed to accurately account for these network impairments. PSQM+ scores represent a perceptual distance measure. That is, PSQM scores reflect the amount of divergence from a clean signal that a distorted signal exhibits. These scores range from 0 (indicating perfect quality) to values of six and higher (indicating poor quality). PSQM+ requires time-synchronization between the input and output signal. However, PSQM does not dictate a time-synchronization method. PAMS The Perceptual Analysis Measurement System (PAMS) was developed by researchers within the Psytechnics Group at British Telecom (Psytechnics was later spun off into an independent company). PAMS was developed independent of PSQM and was first released in 1998. PAMS also uses perceptual modelling to objectively measure speech quality and to predict subjective test scores, but uses different signal processing and modelling techniques than PSQM. PAMS includes a precise time-synchronization technique that increases its robustness when used for networks with variable delays. PAMS produces scores that correlate directly with MOS Listening Quality and Listening Effort scores; that is, on a scale from one to five.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

219 / 247

PESQ Beginning in 1998, the ITU solicited and reviewed drafts for a new standard. Upon reviewing submissions for the latest versions of PAMS and PSQM, they recommended a collaboration to combine these two leading methods. This collaboration between Psytechnics and KPN Research occurred, and the result was the Perceptual Evaluation of Speech Quality (PESQ). PESQ was approved by the ITU in March of 2001 as recommendation P.862, which replaces P.861. PESQ combines the best merits of PAMS and PSQM+. It is very accurate in predicting subjective test scores, and is robust under severe network conditions. PESQ produces MOS-like scores to indicate overall quality. It is expected that PESQ will become the leading standard for speech quality measurement on telephony networks. To finish with this section, it is important to point to out that the implementations of these standards requires the payment of royalties by the manufacturers of the products which in turn increase the price of them.

E-MODEL

Unlike the other perceptual tests described above, the E-model does not compare the original and received signals directly. Instead, it uses the sum of equipment impairment factors Ie, each one quantifying the distortion due to a particular factor. Impairment factors include codec used, echo, average packet delay, packet delay variation, and fraction of packets dropped. As an example, in a system with distortion due to the codec, average one-way delay, packet delay variation (jitter) and packet loss, the rating R is computed as follows:

R = R0 - Icodec -Idelay - Ipdv – Ipacketloss + A Where R0 is the highest possible rating for this system with no distortion. For standard tests a score of R0 = 100 is mostly used: R can then be used as-is or mapped to MOS. “A” is the Advance factor: Service should be provided making the user aware of the advantages (cost, coverage…) of the underlying satellite network which impact the QoS. This fact permits the improvement of the subjective quality (R factor because of the increasing of the A-Advantage factor).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

220 / 247

F. ANNEX: IP MULTICAST PROTOCOLS F.1 IP Multicast concept IP Multicast is an Internet protocol that enables transmission of data packets to a group of receivers. IP multicast makes efficient use of bandwidth by setting up a mid-point between unicast traffic (one - to-one) and broadcast IP traffic (one-to-all in a network). This is well suited for one-to-many or many-to-many bulk data transfer or multimedia (audio/video) streaming transmission to a large number of heterogeneous receivers. IP Multicast efficiently supports this type of transmission by enabling sources to transmit a single copy of a message to a group of interested receivers. This mode of transmission scales well with increasing number of receivers, unlike in the unicast case (one-to-one) , where the source has to send an individual copy of a message to each interested receiver (limited by bandwidth from sender). IP multicast is also more efficient than IP broadcasting (one-to-many), since in broadcasting a copy of a message is sent to all receiver s, including receivers who may not want to receive the message. More so, in the broadcast case message s are limited to a single subnet (to avoid flooding the entire Internet) compared to the multicast case (where receivers choose to join/leave different groups as they wish). IP multicast can be described as “ the transmission of an IP datagram to a host group, a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same best-effort reliability as regular unicast IP datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.” In addition, a single group address may have more than one data stream on different port number s (or different sockets in more than one application at the application layer).

Figure 24. Basic multicast transmission module

For each host group, a multicast address is allocated. Users can have group memberships by joining particular multicast groups. The membership and other information of each group is processed and

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

221 / 247

maintained across the entire WAN or internetwork. Multicast tree is introduced to establish and maintain the fabric of the multicast internetwork. In order to support native IP multicast, both the sending and receiving nodes and network infrastructure between them must be multicast enabled, including the intermediate routers. Native IP multicast at an end host requires support for IP multicast and delivery of data packets at the TCP/IP protocol stack (see Figure 25Error ! Reference source not found.)

Figure 25. IP multicast protocol stack

F-1.1 Multicast Addressing Multicast-Internet addresses have been introduced for IP multicast to define multicast host groups. These are class D addresses and their High order bits of 1st Octet are “1110”. This means that all IP Multicast-group addresses will fall in this range: 224.0.0.0 - 239.255.255.255 There are reserved link-local addresses from 224.0.0.0 to 224.0.0.255, which are used by network protocols on a local network segment and packets with them will never be forwarded by router. These reserved addresses are always transmitted with a time-to-live (TTL) of 1. This address range is only for the group address or destination address of IP Multicast traffic. The source address for multicast datagrams is always the unicast source address. Sources send out their datagrams to the multicast host group address that they have joined in and receivers listen on the group address for incoming packets. F-1.2 Multicast scoping The term scope refers to the region in which the data unit is forwarded. The scope of IP multicast can be unlimited. However, some algorithms have been employed to limit multicast scope for:

• Limitation of flooded network regions

• Multicast address reuse

• Privacy

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

222 / 247

Some multicast routing protocols use broadcast to initiate multicast tree, such as DVBRP. Limitation scope can prevent the temporarily flooding over the whole network. Also for the limitation of the multicast address resource, multicast address reuse is in demand. Because of scope limitation, multicast can be used multiple times as long as the domain of the groups does not overlap. Finally, by scoping the multicast groups, it can be helpful to guarantee a certain degree of privacy, e.g. users out of the scope cannot join the multicast group. There are two main mechanisms used for scoping:

• Scoping based on TTL value

• Administrative scoping TTL parameter is used to specify how many routers the packet can pass before dropped. Therefore, the maximum lifetime of an IP packet can be defined when it comes in the network. Administrative scoping mechanism hasn’ t been used widely. This mechanism defines the scope of the multicast group by specify groups of multicast address for different administrative regions. Only members of an administration region can join the corresponding group. F-1.3 Internet Group Management Protocol (IGMP) IGMP is a protocol that gives a host the ability to support multicasting. It works between a host and the immediately neighbouring multicast router and the router will use multicast routing protocol to establish or join a multicast tree for connection to the source. IGMP is used to manage the multicast groups. It enables the multicast router to track the membership information by using two types of IGMP massages: host membership query and host membership report. Host membership query is sent out periodically by multicast router to determine which multicast group has members on the local network. The query is sent to 224.0.0.1 (all multicast group members in local network) and hosts will generate a corresponding host membership reports to indicate router to which multicast group they belong. Hence, multicast router can establish a table to record the relationships of all hosts and groups. When a host want to join a multicast group, it immediately transmits a join-group report for that group rather than waiting for a query. When a host want to leave a group, it sends a leave-group report to the multicast router. IGMP can support more management service, e.g. report suppression and source filtering and so on. F.2 IP Multicast Routing IGMP can only provide management services between host and the nearest router. The multicast router has to employ some routing protocols to establish and maintain the connection between senders and receivers. Unlike IP routing (where routing table information, stored in routers, is used to determine optimal transmission paths for forwarding messages), IP Multicast routing is much more complex. In IP Multicast, the sender is not concerned with the number or location of clients. In stead the network under takes to deliver to all group members and minimise needless transmission to parts of the network where there is no receiver interest. To do this the multicast capable designated routers construct a spanning- tree (delivery tree), replacing the simple path in unicast, which is routed at each sender to the group. The spanning- tree approach ensures that there is only one path between every pair of routers and it is free of

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

223 / 247

endless loops. Routers located at the branches duplicate the incoming messages and send copies down the branch where there are group members. There are numbers of solutions to do this. In this section we provide an overview of multicast routing protocols. Basically, all of the multicast routing protocols can be categorized into two big classes one is intra-domain protocols and the other is inter-domain protocols. F-2.1 Intra-domain protocols This kind of protocol is called a Multicast Interior Gateway Protocol (MIGP) that is used to enable multicast routers to implement multicast communication within an autonomous system (AS) examples of such protocols are Distance-Vector Multicast Routing Protocol (DVMRP), Multicast Extensions to Open Shortest Path First (MOSPF), Protocol-Independent Multicast Dense Mode (PIM-DM) and Sparse Mode (PIM-SM), and Core Based Trees (CBT). These protocols can generally be subdivided into three categories, sparse mode, dense mode and link-state protocols. Dense mode assumes that most subnets in the network will be interested in multicast traffic. To inform other routers of multicast sources, it floods the multicast traffic to all routers in the network. A router with no receivers interested in this traffic will then tell its upstream router to stop forwarding this traffic or to prune this branch from the tree. This flood-and-prune mechanism allows these protocols to easily build a multicast distribution tree rooted at the source. A source-based tree guarantees the shortest and most efficient path from source to receiver. While this may be an ideal enterprise solution in many circumstances, the reliance on broadcast and flooding across the Internet simply will not scale. Examples of dense mode protocols are Distance Vector Multicast Routing Protocol (DVMRP) and Protocol Independent Multicast Dense Mode (PIM-DM). Sparse mode protocols implement a shared distribution tree. Here, the multicast distribution tree is rooted at a core router in the network called a rendezvous point (RP). When a source begins actively sending multicast traffic, its directly connected router, or designated router, registers with the RP. The RP will keep track of all active sources in a domain. When a router is connected to a host that wants to receive a multicast group, it will use RPF (Reverse Path Forwarding) to determine the shortest path to the RP. While the RP builds a tree to the source, all receivers join the tree at the RP. As long as all routers know which router is the RP, broadcast is not needed to distribute multicast routing information. Additionally, this limits the amount of routing state that all non-RP routers need to know. Protocol Independent Multicast Sparse Mode (PIM-SM) and Core-Based Trees (CBT) are examples of a sparse mode routing protocols. Link-state protocols such as Multicast Open Shortest Path First (MOSPF) function much like dense mode protocols in that they both use shortest path trees to distribute multicast traffic to the receivers in the network. Link-state protocols, however, don’ t use the flood and prune mechanism that is used in DVMRP or PIM-DM. Instead, they flood special multicast, link-state information that identifies the

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

224 / 247

whereabouts of group members (that is, receivers) in the network. All routers in the network use this group membership information to build shortest path trees from each source to all receivers in the group. Below a short description of the mentioned protocols is provided. DVMRP DVMRP is a source-based protocol using Reverse-Path Multicasting algorithm. To establish connections between multicast routers, the sender broadcast the first datagram that is forwarded to the entire internetwork as long as the TTL of the packet and router interface thresholds allow this. If the router has attached hosts belonging to the same multicast group, it duplicates the packet and sends to all of these hosts. If there are no this kind of host, the router send back a prune message to its parent node. Hence, its parents won’ t send the same multicast pair (source, group) to it. When a member of a new group on a particular link appears, a cancellation message to undo the prune message is sent upstream by the router. All of the multicast routers exchange their routing table update message periodically with their neighbours. The exchanged information is used to establish their multicast routing tables. This technique to create multicast trees is known as broadcast-and-prune. Broadcast-and-prune protocols are also known as dense mode protocols, because they are designed to perform better when the topology is densely populated with group members. Routers assume there are group members downstream, and so forward packets. Only when explicit prune messages are received does a router not forward multicast traffic. If a group is densely populated, routers are unlikely to ever need to prune. DVMRP is relatively easy to employ because it is based on well-known RIP algorithms. Another advantage is the low processing demands it places on the routers. However, it may cause bandwidth limitation for it’s periodically broadcasting flood multicast traffic through the entire network to rebuild multicast trees. Additionally, DVMRP is constrained by the unicast routing protocols underlying CBT The Core Based Trees (CBT) protocol began its life as a research paper and is now being standardized by the IETF. CBT uses the basic sparse mode paradigm to create a single shared tree used by all sources. The tree is rooted at a core. All sources send their data to the core and all receivers send explicit join messages to the core. There are two differences between CBT and PIM-SM. First, CBT uses only a shared tree, and is not designed to use shortest path trees. Second, CBT uses bi-directional shared trees, but PIM-SM uses unidirectional shared trees. Bi-directional shared trees involve slightly more complexity, but are more efficient when packets travelling from a source to the core cross branches of the multicast tree. In this case, instead of only sending traffic “up” to the core, packets can also be sent “down” the tree. While CBT has significant technical merits and is on par technically with PIM-SM, few routing vendors provide support for CBT. The reason seems to be that the vendor community was only going to support one sparse mode protocol and the implicit selection was PIM-SM. MOSPF Multicast Extensions to OSPF (MOSPF) is also based on unicast routing protocol OSPF to provide multicast. OSPF can construct a database for each router called link state database, which describe the network topology of the AS. Routers use this database to calculate the shortest path from the source and forward those packets arrival from the shortest path only. Five different types of link-state advertisements

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

225 / 247

(LASs) are used in OSPF to collect and exchange local network state, including the states of the routers’ interfaces and adjacencies. MOSPF add a new group membership LAS to OSPF to allow routers to flood the membership information collected using IGMP throughout the AS. This information is used to construct the link state database and to compute a shortest path tree for multicast: basically, MOSPF routers flood an OSPF area with information about group receivers. This allows all MOSPF routers in an area to have the same view of group membership. In the same way that each OSPF router independently constructs the unicast routing topology, each MOSPF router can construct the shortest path tree for each source and group. While group membership reports are flooded throughout the OSPF area, data is not. MOSPF is something of an oddity in terms of classification. It can be considered a dense mode protocol because membership information is broadcast to each MOSPF router, but it can be also considered an explicit join protocol because data is only sent to those receivers that specifically request it. The key to understanding MOSPF is to realize that it is heavily dependent on OSPF and its link state routing paradigm. We have described how MOSPF routes multicast traffic inside a single OSPF area. However, MOSPF provides mechanism to forward multicast packets between OSPF areas. The way that MOSPF handles interarea multicast routing is in many ways similar to OSPF’s handling of unicast. In OSPF, routers that connect a second-tier area to the backbone area are called area border routers (ABRs) and are responsible for forwarding routing information (primarily in the form of OSPF summary Link-State Advertisements (LSAs) – which summarize the networks inside an area) and unicast traffic between the two areas. Area Border Routers do not pass router or network Link-State Advertisements between areas; therefore, the topology of one area is not seen by a bordering area. To support interarea multicast, RFC 1584 defines interarea multicast forwarders, which are a subset of the OSPF ABRs in the network and are configured to perform multicast-related tasks, such as summarizing group membership into the backbone area and forwarding multicast packets between areas. This subset is called Multicast Area Border Routers (MABRs). MOSPF can forward normal unicast IP traffic at the same time it handles multicast traffic. It more rapidly adapts to changes of group membership and availability of network resources. Unlike DVMRP, MOSPF don’ t need flood packets to determine group membership or network topology. By using the same flexible-path metrics as OSPF instead of just a simple hop-count to create source-based tree, MOSPF is more convenient to support cost-based or QoS-based routing, for example. However, MOSPF doesn’ t support tunnels that are deployed in Mbone and the router needs a shortest path computation for all multicast source. Also, it is not well-suited for handling sparse topologies. PIM PIM has two modes of operation: PIM-DM, which employs an RSPT similar with DVMRP, and PIM-SM, which uses unidirectional shared trees. The main difference between PIM-DM and DVMRP is that DVMRP is based on the particular unicast routing mechanism, e.g. RIP, while PIM-DM don’ t need any specification of underlying unicast protocol. DVMRP routers may selectively forward packet to its downstream interfaces so that the next node will recognize that the local node is on the shortest path between it and the source. While PIM-DM router broadcasts the received packet to all of its downstream interfaces. PIM-SM is similar to PIM-DM in that routing decisions are based on whatever underlying unicast routing table exists, but the tree construction mechanism is quite different. PIM-SM's tree construction algorithm

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

226 / 247

is actually more similar to that used by CBT than to that used by PIM-DM. PIM-SM provides rendezvous points (RPs) for receivers to meet new sources. RPs are used by sender to announce their existence. Routers explicitly send a join messages to RP when its local or downstream host want to join a multicast group. Processing of this message by intermediate routes sets up the multicast tree branch from RP to the host. If a source want to send data to a multicast group, it just send registers massage, piggybacked on the data packet, to RPs for that group. Then the RP responds by sending join message to the source. Processing of these massages by intermediate routers establishes a packet delivery path from the source to the RP. PIM-SM avoids flooding packets over ASes for it’s based on receiver initiation tree and centralized RPs. However, those RPs may be the network traffic bottles and the potential single point failures. F-2.2 Inter-domain protocols This kind of protocols is employed by board routers, which interconnect two ASes, to enable multicast communication between each AS. Border Gateway Multicast Protocol (BGMP) is an example. BGMP provides a method for providers to distinguish which route prefixes they will use for performing multicast RPF checks. It contains two components: MIGP component and BGMP component. MIGP component is used by border router to communicate with the others intra-routers in the same AS while BGMP for construction of a bi-directional centre-tree. The root of this tree is an AS that claims a multicast address by employing a global multicast address allocation protocol such as the Multicast Address-Set Claim (MASC) protocol. BGMP use TCP as its transport protocol. Border routers exchange BGMP messages over TCP connection across them to update routing tables by sending join/prune messages. The shortest path between an AS and the source may be different with the one crossing the root of shared tree. Hence, BGMP allows router attach a source-specific branch to the shared tree, i.e. choose the shortest path instead of using tree root. The main advantage of BGMP is that an Internet can support non-congruent unicast and multicast topologies. When the unicast and multicast topologies are congruent BGMP can support different policies for each. BGMP provides a scalable policy based inter-domain routing protocol. Inter-domain multicast has evolved out of the need to provide scalable, hierarchical, Internet-wide multicast. Protocols that provide the necessary functionality have been developed, but the technology is relatively immature. The particular inter-domain solution in use is considered near-term, and is possibly only an interim solution: while the solution is functional, it lacks elegance and long-term scalability. As a result, additional work is underway to find long-term solutions. Some of these proposals are based on the standard IP multicast model. Others attempt to refine the service model in hopes of making the problem easier. These new protocols, which are being considered by the IETF, promise to provide solutions to the complex issues of inter-domain multicast routing. When the topic of extending inter-domain multicast beyond the outdated DVMRP-based Mbone was first discussed by several ISPs, it was agreed that some sort of sparse mode protocol was necessary. It seems that it would be preferred PIM-SM. However, this choice introduced some problems because it is very problematical to interconnect multiple sparse mode domains. The requirement of PIM-SM that there can only be one active RP for a given group presents a significant challenge in the interdomain world of the Internet. For practical reasons, ISPs do not want to rely on shared or third party RPs. ISPs require administrative control of their own RPs. A mechanism was needed for these different RPs to be able to communicate with one another to exchange information about the active sources in their respective domains. An early method of doing this was to have multicast peering exchanges on multi-access

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

227 / 247

interfaces (FDDI or Fast Ethernet) to which each ISP would connect its RP. By running PIM-DM on this multi-access interface, each RP would flood its source information to each other only on this interface. Among other problems with this hybrid PIM-SM/PIM-DM architecture was that each ISP would have to place its RP at the edge of the network to achieve this. As we will later examine, a well-designed PIM-SM implementation requires that the RP be well connected in the core of the network. F-2.2.1 Near-term solutions The ISPs listed the following major requirements that must be met before they could consider deployment of native multicast in the Internet to be feasible: • An Explicit Join protocol inside the domain for efficiency • Use of an existing (unicast) operations model for multicast peering • Not dependent on competitor’s RPs • Flexibility regarding RP placement The first item was, in general, already met by normal PIM-SM operation. However, at that time, the last three items required the development of two solutions: Multiprotocol BGP (a.k.a. Multicast BGP - MBGP) and Multicast Source Discovery Protocol (MSDP). Multiprotocol Border Gateway Protocol (MBGP) It creates extensions to the widely-used Border Gateway Protocol (BGP). Route aggregation and abstraction, as well as hop-by-hop policy routing, are provided in unicast using the Border Gateway Protocol (BGP). BGP offers substantial abstraction and control among domains. Within a domain, a network administrator can run any routing protocol desired. Routing to hosts in an external domain is simply a matter of choosing the best external link. BGP supports inter-domain routing by reliably exchanging network reachability information. This information is used to compute an end-to-end distance-vector-style path of AS numbers. Each AS advertises the set of routes it can reach and an associated cost. Each border router can then compute the set of ASes that should be traversed to reach any network. The use of a distance vector algorithm together with full path information allows BGP to overcome many of the limitations of traditional distance vector algorithms. Packets are still routed on a hop-by-hop basis, but less information is needed and better routing decisions can be made. The functionality provided by BGP, and its well-understood paradigm for connecting ASs, are important catalysts for supporting inter-domain multicast. A version of BGP capable of carrying multicast routes would not only provide hierarchical routing and policy decisions, but would also allow a service provider to use different topologies for unicast and multicast traffic. The mechanism by which BGP has been extended to carry multicast routes is called Multiprotocol Extensions to BGP4 (MBGP). MBGP is able to carry multiprotocol routes by adding the Subsequent Address Family Identifier (SAFI) to two BGP4 messages: MP_REACH_NLRI and MP_UNREACH_NLRI. Specifically for multicast, the SAFI field can specify unicast, multicast or unicast/multicast. With MBGP, instead of every router needing to know the entire flat multicast topology, each router only needs to know the topology of its own domain and the paths to reach each of the other domains. While MBGP is the first step toward providing inter-domain multicast, it alone is not a complete solution. MBGP is capable of determining the next hop to a host, but it is not capable of providing multicast tree construction functions. More specifically, what is the format of the join message? When should join messages be sent, and how often? Support for this functionality is not provided by MBGP; a true inter-domain multicast routing protocol is needed. Furthermore, conventional wisdom suggests that this protocol should not use the broadcast-and-prune method of tree

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

228 / 247

construction. The near-term solution being advocated is to use PIM-SM, to establish a multicast tree between domains containing group members. Multicast Source Discovery Protocol (MSDP) Various intra-domain routing protocols exist: there is a route exchange protocol to support multicast, and PIM-SM is to be used to connect receivers and sources across domain boundaries. But, there is still one function missing from the near-term solution. This function is needed when trying to connect sparse mode domains together. Given that PIM-SM is the only sparse mode protocol that has seen significant deployment, this function tends to be heavily influenced by PIM-SM. The problem is basically how to inform an RP in one domain that there are sources in other domains. The underlying assumption here is that a group can now have multiple RPs. However, the reality is that there is still only one RP per domain, but now multiple domains may be involved. The approach adopted is largely motivated by the perceived needs of the ISP community. In fact, the decision to have multiple RPs rather than a single root is what differentiates the near-term solution from other proposed solutions. A problem arises when group members are spread over multiple domains. There is no mechanism to connect the various intra-domain multicast trees together. While traffic from all the sources for a particular group within a particular domain will reach the group's receivers, any sources outside the domain will remain disjoint. Why is this the case? Within a domain, receivers send join messages toward one RP and sources send register messages to the same RP. However, there is no way for an RP in one domain to find out about sources in other domains using different RPs. There is no mechanism for RPs to communicate with each other when one receives a source register message. The decision to maintain a separate multicast tree and RP for each domain is driven by the need to reduce administrative dependencies between domains. Two potential problems are avoided in this way. • It is not necessary for two domains to co-administer a single sparse mode cloud. Relevant

administrative functions include identifying candidate RPs and establishing the group-RP mapping. • It becomes possible to avoid multi-party dependencies, in which multicast delivery for sources and

groups in one or more domains is dependent on another domain whose only function is to provide the RP. Dependencies can occur when all sources and receivers in the RP's domain leave or become inactive. The domain with the RP has no group members and yet is still providing the RP service. Depending on how multicast and inter-domain traffic billing is handled, this could be particularly undesirable.

The near-term solution adopted for this problem is a new protocol, appropriately named the Multicast Source Discovery Protocol (MSDP). This protocol works by having representatives in each domain announce to other domains the existence of active sources. MSDP is run in the same router as a domain's RP (or one of the RPs). MSDP's operation is similar to that of MBGP, in that MSDP sessions are configured between domains and TCP is used for reliable session message exchange. MSDP operation is described below. 1. When a new source for a group becomes active it will register with the domain's RP. 2. The MSDP peer in the domain will detect the existence of the new source and send a Source Active

(SA) message to all directly-connected MSDP peers. 3. MSDP message flooding:

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

229 / 247

- MSDP peers that receive an SA message will perform a peer-RPF check. The MSDP peer that

received the SA message will check to see if the MSDP peer that sent the message is along the “correct” MSDP-peer path. These peer-RPF checks are necessary to prevent SA message looping.

- If an MSDP peer receives an SA message on the correct interface, the message is forwarded to all MSDP peers except the one from which the message was received. This is called peer-RPF flooding.

4. Within a domain, an MSDP peer (also the RP) will check to see if it has state for any group members in the domain. If state does exist, the RP will send a PIM join message to the source address advertised in the SA message.

5. If data is contained in the message, the RP then forwards it on the multicast tree. Once group members receive data, they may choose to switch to a shortest path tree using PIM-SM conventions.

6. Steps 3-5 are repeated until all MSDP peers have received the SA message and all group members are receiving data from the source.

The issue of scalability is an important one to consider for MSDP. Because of the way MSDP operates, if multicast becomes tremendously successful, the overhead of MSDP may become too large. The limitation occurs if multicast use grows to the point where there are thousands of multicast sources. The number of SA messages (plus data) being flooded around the network could become very large. The generally-agreed-upon conclusion is that MSDP is not a particularly scalable solution, and will likely be insufficient for the long term. But, given that long-term solutions are not ready to be deployed, MSDP is seen as an immediate solution to an immediate need. The short-term inter-domain solution just described is referred to with the abbreviations for the three relevant protocols: MBGP/PIM-SM/MSDP: While the given description is relatively complete, there are a number of details which are not discussed. And as with any system, most of the complexity is in the details. Furthermore, we have not yet discussed the limitations of the current solution in any detail. In particular, a qualitative assessment of the scalability, complexity, and overall quality of the protocols would be valuable. MBGP/PIM-SM/MSDP: This solution is relatively straightforward once a person understands all the abbreviations and understands the motivating factors that drove the design of the protocols. While some argue that the current set of protocols is not simple, it really is no more complex than many other Internet services, such as unicast routing. The key advantage of MBGP/PIM-SM/ MSDP: it is a functional solution largely built on existing protocols. Furthermore, it is already being deployed with a fair amount of success. The key disadvantage is that, as a long-term solution, the MBGP/PIM-SM/MSDP protocol suite may be susceptible to scalability problems. F-2.2.2 Long-term solutions Although the combination of PIM-SM, MSDP, and MBGP is allowing many ISPs to deploy native inter-domain multicast service in their networks, there is still a need to continue researching and developing better solutions. Numerous such efforts are underway. These efforts can be broken down into two groups: efforts based on the standard IP multicast philosophy, and efforts which look to change this model in hopes of simplifying the problem. Border Gateway Multicast Protocol (BGMP) / Multicast Address Set-Claim (MASC)

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

230 / 247

The Border Gateway Multicast Protocol and its associated protocol, MASC have been introduced before. They form an architecture for inter-domain multicast routing. MASC forms the basis for a hierarchical address allocation architecture. MASC temporarily and dynamically allocates multicast address ranges to domains using a "listen and claim" approach with collision detection. In this approach, child domains listen to multicast address ranges selected by their parent, select sub-ranges from their parents' range and propagate the claims to their siblings. The "claimers" wait for a suitably long period to detect any collision before communicating the acquire range to (1) the domain's multicast address allocation server and to (2) other domains, through BGP, as multicast-specific routes. MASC can then allocate, from its multicast address range, individual multicast addresses to groups initiated in their domain. BGMP requires that each multicast group be associated with a single root or core and constructs a shared tree of domains, similarly to other shared tree protocols (e.g., PIM-SM and CBT). However, in BGMP, the root is an entire domain rather than a single router. BGMP is based on two main assumptions: • That a rendezvous mechanism, whereby members get to know the identity of the sources without the

need for global broadcast, is the most convenient for inter-domain multicast routing. • That specific ranges of the class D space are associated (e.g., via MASC) with various domains. Each

of these domains is chosen to be the root of the shared tree of domains for all groups whose address is in its range. This is because the root domain is very likely to be the domain initiator of the multicast group.

The actual number of multicast addresses, claimed by a domain using MASC, is a trade-off between two competing factors: • If the number of multicast addresses available is high, the domain will become the root domain for a

large number of groups. • If the claimed address range is sufficiently large, groups initiated locally can get multicast addresses

from the domain's range, thereby becoming locally rooted. The choice of the root of a shared tree in inter-domain routing has implications both in terms of policy and performance as it relates to end-to-end delay. In the intra-domain case, any router can be entitled to become core for the group. This is because the emphasis in the intra-domain case is on load sharing and the penalty on non-optimally located cores is not significant. The same cannot be said in the inter-domain case, that is, all possible root domains cannot be treated as eligible candidates. In inter-domain routing there are administrative issues concerning the ownership of the root domain and a greater risk from poor delay performance due to the location of the root. This is the reason why in BGMP the root domain has been chosen to be the domain of the group initiator in the hope that this domain will source a significant portion of the multicast data. BGMP uses the routes advertised by BGP to construct the multicast trees for active multicast groups. Since inter-domain routing involves the use of resources in autonomously administered domains, the routing policy constraints of such domains need to be accommodated. BGMP follows policy for multicast traffic using the selective propagation of group routes in BGP4+ (multicast extensions of BGP4, RFC 2283).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

231 / 247

BGMP runs on domain border routers and constructs a bi-directional shared tree that connects individual multicast trees built in a domain. Hence, the border routers also run protocols for multicast routing intra-domain (e.g., PIM-DM, PIM-SM). Such intra-domain routing protocols are also referred to as Multicast Interior Gateway Protocols or MIGPs. The modulo of the border router that runs an MIGP is referred to as the MIGP component; the modulo running BGMP is referred to as the BGMP component. It is up to the MIGP component to inform the BGMP component about group membership in the domain. This triggers BGMP to send "Joins" and "Prunes" border router to border router until the root domain or a border router that is already on the tree. In BGMP, the receiver domain is allowed to build source-specific uni-directional inter-domain distribution branches. However, such branches are not allowed to collide with the shared tree, for the sake of loop avoidance and possible introduction of duplicate packets. The need to construct such branches arises when the shortest path from the current domain to a source domain does not coincide with the bi-directional shared tree from the domain. This feature is very useful for domains running MIGPs, such as DVMRP and PIM-DM which support only source-based trees within the domain and only accept source traffic if it arrives from the shortest path back to the source (RPF check). The trick used by the ingress border router is to encapsulate the packets to the appropriate RPF-compliant border router, from where the packets can be injected into the domains' MIGP. If a source-specific branch is constructed, data is sourced into the domain via the appropriate border router avoiding the data encapsulation overhead. Source-specific branches differ from source-specific shortest path trees built by some MIGPs in that the source-specific branch stops where it reaches either a BGMP router on the bi-directional tree or the source domain. In shortest path trees, the source-specific state is set up all the way back to the source. It is also assumed that, since the inter-domain topology is sparser than the intra-domain topologies, the traffic concentration aspects related to the shared trees are not too much of a penalty for the protocol. In order to ensure reliable control message transfer, BGMP runs over TCP but uses a different TCP port than BGP's. BGMP routers have TCP peering sessions with each other for the exchange of BGMP control messages (e.g., "Join" and "Prunes"). The BGMP peers for a certain group are determined via BGP. It is assumed also that BGP's route selection algorithm ensures that one border router, among the border routers of the domain, is chosen as the best exit router for each group route. This router has an external peer as its next hop toward the root domain of the group and the other border routers have the best exit router for each group route. Data packets are forwarded in BGMP on a combination of BGMP and MIGP rules. Routers forward data packets to a set of targets according to a matching source-specific entry (S, G) if it exists. If not, a matching shared tree state entry for the group is checked. If neither is found, then the packet is sent natively to the next hop peer for G that is the best exit border router for the root domain according to BGP rules (this is the case for a non-member sender). If a matching entry was found the packet is forwarded to all other targets in the target list. If a target is a MIGP component, then forwarding is subject to the rules of the MIGP protocol. Satisfying policy constraints for an autonomous system's multicast traffic and considering heterogeneous routing domains can often translate into an increase of group state maintenance and delivery quality. BGMP goes around this problem by aligning multicast domains with autonomous systems and thus obtaining efficient policy support following the routes defined by BGP. Still, policy control is restricted to the policy constraint support of BGP's underlying hop-by-hop routing paradigm and path vector concept.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

232 / 247

This implies, for example, that network-specific policies cannot be supported. Furthermore, accepting traffic from "come-from" interfaces might not be discriminatory enough as a policy mechanism. This is because traffic barriers imposed by autonomous systems may be bypassed if a source is covered by a prefix that is homed to more than one domain. Due to bi-directional forwarding, BGMP is not adequate for asymmetrical routing environments. Moreover, BGMP can only support source-specific delivery criteria in limited cases, for the sake of reducing the complexity of the protocol. BGMP has been designed with the aim of being able to be used in heterogeneous multicast routing domains and to be independent of the MIGP deployed intra-domain. Thus, for a globally available multicast routing solution, the use of BGMP implies solving interoperability problems specific to whichever MIGP is in use. This has not proved to be an easy task and, in same cases, encapsulations cannot be avoided. This is the case when the MIGP protocol is suitable for regional deployment but not for supporting multicast transit traffic. Considering the above, it can be argued whether inter-domain multicast routing would not be better served with a unique routing protocol used intra-domain and inter-domain or an adaptation of an existing protocol that could then be applied both intra-domain and inter-domain. Root Addressed Multicast Architecture In response to the perceived complexity of MBGP/PIM-SM/MSDP and BGMP, and to the need to address additional multicast-related issues like security, billing, and management, some members of the multicast community are looking to make fundamental changes to the multicast model. One class of proposals that has received much attention recently is called the Root Addressed Multicast Architecture (RAMA). The premise for RAMA-style protocols is that most multicast applications are single-source or have an easily identifiable primary source. By making this source the root of the tree, the complexity of core placement in other multicast routing protocols can be eliminated. This tradeoff raises a number of important issues that are described at the end of this section. There are two primary RAMA-style protocols being discussed: Express Multicast and Simple Multicast. The key aspects of these two protocols are:

Express Multicast. Express is designed specifically as a single-source protocol. The root of the tree is placed at the source, and group members send join messages along the reverse path to the source. Express also provides mechanisms to efficiently collect information about subscribers. The protocol is specifically designed for subscriber-based systems that use logical channels. Representative applications include TV broadcasts, file distribution, and any single-source multimedia application. The key advantages of Express are that routing complexity can be reduced and that closed groups can be offered. Simple Multicast. Simple Multicast and Express Multicast are similar, but Simple Multicast has the added flexibility of allowing multiple sources per group. A particular source must be chosen as the primary, and the tree is rooted at this node's first-hop router. Receivers send join messages to the source, and a bidirectional tree is constructed. Additional sources send packets to the primary source. Because the tree is bidirectional, as soon as packets reach a router in the tree they are forwarded both downstream to receivers and upstream to the core. The advantages and disadvantages of this proposal are being heavily debated, but the proposal's authors believe that it eliminates the address allocation problem and the need to place and locate RPs. Address allocation

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

233 / 247

is done by using the core address and the multicast group address together to uniquely identify a group. By routing on this pair of addresses, each root/core/source can allocate, without collision, up to 2 32 addresses.

The Express and Simple multicast proposals have received significant attention in both the research community and the IETF. There is another question in addition to that of the merits of these new protocols. If these protocols are standardized, will they be expected to replace all existing protocols, or will they work in parallel with the existing multicast infrastructure? If the RAMA-style protocols are expected to work in cooperation with existing protocols, there will be yet another set of protocols to deploy, evaluate, and interoperate with. This does not make the provision of Internet-wide multicast easier. If RAMA-style protocols are expected to replace the current set of protocols, the question becomes whether they have enough flexibility to support all types of multicast applications. The bottom line is that these new protocols are still proposals, and it is uncertain what their future will be.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

234 / 247

G. ANNEX: QUALITY OF SERVICE PROVISION ISSUES In this section an overview of these issues is performed. Different guidelines on Quality of Service (QoS) are presented. As there are several standardising entities producing guidelines on this subject, a section is dedicated to each one. G.1 ITU B-ISDN QoS model B-ISDN (ATM) [10] allows point to point and point to multipoint virtual circuits to be requested with pre-specified QoS. ATM provides a rich set of QoS mechanisms with a wide variety of service categories or QoS descriptors, which offer fine control over the traffic parameters requested and managed. The most important QoS parameters are [10]: • Minimum cell rate (MCR). The minimum acceptable cell rate. • Sustained cell rate (SCR). The long term average cell rate. • Peak cell rate (PCR). The maximum rate at which cells will be sent. • Cell delay variation tolerance (CDTV). The maximum acceptable cell jitter. • Cell loss ratio (CLR): The ratio of total lost cells to total transmitted cells. • Cell transfer delay (CTD): The time difference, t2 – t1, between a cell reference event at an input of a

cell into a network or a link (t1), and the corresponding cell reference event created by the output of that same cell (t2).

• Cell delay variation (CDV): The CDV for a single cell is the difference between the CTD experienced by that cell from a nominal CTD.

• Cell error ratio (CER): The ratio of total errored cells to the total transferred cells. • Severely errored cell (SECBR): The ratio of total severely errored cell blocks to total cell blocks. • Cell misinsertion rate (CMR): The total number of misinserted cells observed during a specified time

interval divided by the time (CMR) interval duration. The ITU Recommendation that deals with performance and availability is I.356, B-ISDN ATM Layer Cell Transfer Performance. I.356 describes the QoS service classes, and ATM layer parameters. These QoS parameters are classified as the set of parameters that describe the traffic offered to the network (traffic descriptor), and the parameters that specify the required network quality for the given traffic descriptor. The traffic descriptor comprises: • Minimum cell rate (MCR). • Sustained cell rate (SCR). • Peak cell rate (PCR).

• Cell delay variation tolerance (CDTV). The required network service quality comprises: • Cell loss ratio (CLR). • Cell transfer delay (CTD). • Cell delay variation (CDV).

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

235 / 247

• Cell error ratio (CER). • Severely errored cell (SECBR). • Cell misinsertion rate (CMR). To accommodate the characteristics and requirements of various traffic types, ITU-T Recommendation I.356 defines various classes of service for ATM. Class 1 (stringent class) is a delay-sensitive class intended to support constant bit rate (CBR) and real-time variable bit rate (VBR) services such as telephony and videoconference. Class 2 (tolerant class) is a delay-tolerant class and supports available bit rate (ABR) and non-real-time VBR services such as video and data. Class 3 (bi-level class) supports VBR and ABR services such as high-speed data. Finally, class 4 (unspecified class UBR) supports unspecified such as file transfers and e-mail. The relationship between the parameters described in section G.1 and the ATM service classes defined above is: .

Traffic class Traffic contract CBR r t-VBR VBR UBR ABR

PCR specified specified specified optional specified CDVT specified

.25ms* specified .25ms*

NS NS NS

SCR NA specified specified NA NA MBS NA specified specified NA NA

Traffic descriptor

MCR NA NA NA NA specified CLR (CLP=0)

specified 1.7 E(-10)*

specified 1. E(-8)*

specified 1. E(-7)*

NS specified

CLR (CLP=1)

specified specified specified NS specified

CTD Max specified 0.5 ms*

Max specified 5 ms*

Mean specified

NS NS QOS parameters

CDV specified .15ms*

specified .15ms*

NS NS NS

* : typical values - NS: not specified - NA: not available CLR : Cell Loss Ratio - CLP: Cell Loss Priority (1=low priority cell) - CTD: Cell Transit Delay - CDV: Cell Delay Variation - PCR: Peak Cell Rate - CDVT: Cell Delay Variation Tolerance (not a user parameter) SCR: Sustainable Cell Rate (maximum average rate) - MBS: Maximum Burst Size (maximum number of cells at PCR rate) MCR: Minimum Cell Rate

Table 20. ATM service class parameters

G.2 Internet Integrated Services QoS model Often, real-time applications do not work well across the Internet because of variable queuing delays and congestion losses. The Internet, as originally conceived, offers only a very simple quality of service, point

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

236 / 247

to point best effort data delivery. Before real-time applications such as remote video, multimedia conferencing, visualisation, and virtual reality can be broadly used, the Internet infrastructure must be modified to support real-time QoS, which provides some control over end-to-end packet delays. This extension must be designed from the beginning for multicasting; simply generalising from the unicast (point-to-point) case does not work. Real-time QoS is not the only issue for a next generation of traffic management in the Internet. Network operators are requesting the ability to control the sharing of bandwidth on a particular link among different traffic classes. They want to be able to divide traffic into a few administrative classes and assign to each a minimum percentage of the link bandwidth under conditions of overload, while allowing unused bandwidth to be available at other times. Such a management facility is commonly called controlled link sharing. The term Integrated Services (IS) H is used for an Internet service model that includes best-effort service, real-time service, and controlled link sharing. The proposal of an architectural extension done in H is comprised of two elements: • An extended service model (the IS model) • A reference implementation framework, which gives a set of vocabulary and a generic program

organisation to realise the IS model. It is important to separate the service model, which defines the externally visible behaviour, from the discussion of the implementation, which may (and should) change during the life of the service model. The IS model makes some key assumptions: the first assumption is that resources (e.g., bandwidth) must be explicitly managed in order to meet application requirements. This implies that "resource reservation" and "admission control" are key building blocks of the service. Another fundamental assumption is that it is desirable to use the Internet as a common infrastructure to support both non real-time and real-time communication. In addition to this assumption of common infrastructure, a unified protocol stack model is adopted, employing a single internet-layer protocol for both real-time and non-real-time service. The IS model proposes to use the existing internet-layer protocol for real time data. There are real time applications requiring a service characterised by a perfectly reliable upper bound on delay. For these applications a guaranteed service is proposed. In contrast, there are tolerant applications that need not set their offset delay greater than the absolute maximum delay, since they can tolerate some late packets. These applications are called adaptive applications. For tolerant applications the service model proposed is called predictive service and it supplies a fairly reliable, but not perfectly reliable, delay bound. In many cases an application's data generation process is an intrinsic property unaffected by the network. However, there are likely to be many audio and video applications, which can adjust their coding scheme and thus can alter the resulting data generation process depending on the network service available. This alteration of the coding scheme will present a trade-off between fidelity (of the coding scheme itself, not of the playback process) and the bandwidth requirements of the flow. Such rate-adaptive applications have the advantage that they can adjust to the current network conditions by adjusting the traffic pattern itself.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

237 / 247

While real-time applications do not wait for late data to arrive, elastic applications will always wait for data to arrive. It is not that these applications are insensitive to delay; to the contrary, significantly increasing the delay of a packet will often harm the application's performance. Rather, the key point is that the application typically uses the arriving data immediately, rather than buffering it for some later time, and will always choose to wait for the incoming data rather than proceed without it. There are several categories of such elastic applications: interactive burst (Telnet, X, NFS), interactive bulk transfer (FTP), and asynchronous bulk transfer (electronic mail, FAX). The delay requirements of these elastic applications vary from rather demanding for interactive burst applications to rather lax for asynchronous bulk transfer, with interactive bulk transfer being intermediate between them. An appropriate service model for elastic applications is to provide as soon as possible (ASAP) service, or best-effort service. The IS model proposes to offer several classes of best-effort service to reflect the relative delay sensitivities of different elastic applications. The service model allows interactive burst applications to have lower delays than interactive bulk applications, which in turn would have lower delays than asynchronous bulk applications. In contrast to the real-time service models, applications using this service are not subject to admission control. In H the reference framework for the IS model can be found. This framework includes four components: the packet scheduler, the admission control routine, the classifier, and the reservation setup protocol. In the following paragraphs, the "flow" abstraction is defined as a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS. A flow is considered to be simplex, i.e., to have a single source but N destinations. Thus, an N-way teleconference will generally require N flows, one originating at each site. In today's Internet, IP forwarding is completely egalitarian; all packets receive the same quality of service, and packets are typically forwarded using a strict FIFO queuing discipline. For IS, a router must implement an appropriate QoS for each flow, in accordance with the service model. The router function that creates different qualities of service is called "traffic control". Traffic control in turn is implemented by three components: the packet scheduler, the classifier, and admission control. - Packet Scheduler. It manages the forwarding of different packet streams using a set of queues and

perhaps other mechanisms like timers. The packet scheduler must be implemented at the point where packets are queued; this is the output driver level of a typical operating system, and corresponds to the link layer protocol. The details of the scheduling algorithm may be specific to the particular output medium. For example, the output driver will need to invoke the appropriate link-layer controls when interfacing to a network technology that has an internal bandwidth allocation mechanism. There is another component that could be considered part of the packet scheduler or separate: the estimator. This algorithm is used to measure properties of the outgoing traffic stream, to develop statistics that control packet scheduling and admission control.

- Classifier. For the purpose of traffic control (and accounting), each incoming packet must be mapped into some class; all packets in the same class get the same treatment from the packet scheduler. The classifier performs this mapping. Choice of a class may be based upon the contents of the existing packet header(s) and/or some additional classification number added to each packet. A class might correspond to a broad category of flows, e.g., all video flows or all flows attributable to a particular organisation. On the other hand, a class might hold only a single flow. A class is an abstraction that may be local to a particular router; different routers along the path may classify the same packet differently.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

238 / 247

- Admission Control It implements the decision algorithm that a router or host uses to determine

whether a new flow can be granted the requested QoS without impacting earlier guarantees. Admission control is invoked at each node to make a local accept/reject decision, at the time a host requests a real-time service along some path through the Internet. The admission control algorithm must be consistent with the service model, and it is logically part of traffic control. Admission control is sometimes confused with policing or enforcement, which is a packet-by-packet function at the edge of the network to ensure that a host does not violate its promised traffic characteristics. We consider policing to be one of the functions of the packet scheduler. In addition to ensuring that QoS guarantees are met, admission control will be concerned with enforcing administrative policies on resource reservations. Some policies will demand authentication of those requesting reservations. Finally, admission control will play an important role in accounting and administrative reporting.

- The fourth and final component of the implementation framework is a reservation setup protocol, which is necessary to create and maintain flow-specific state in the endpoint hosts and in routers along the path of a flow. In section G-2.1 a reservation protocol (RSVP) is presented.

Integrated Services offers two QoS control services for delay-sensitive traffic:

• Guaranteed service, which guarantees a deterministic upper limit on delay as a packet travels through the network. Guaranteed service is designed for applications that are intolerant of delays, requiring that a packet arrive no later than a certain length of time after it was transmitted from its source. If the packet is delayed beyond that length of time, it is 'useless' to the receiving application and the result is distortion or degraded fidelity. Examples of such applications include voice and real time audio and video.

• Controlled Load service, which provides a fairly stable although probabilistic (predictive) upper limit on delay. Controlled Load service is designed for applications more tolerant of delays than those requiring guaranteed service but need a better than the best-effort service usually provided by a network. Examples of such applications include interactive access and non-real-time audio and video.

The guidelines for the use of Integrated Services in conjunction with the RSVP protocol for each of these services can be found in references [3] [12] [13]. The IETF has developed several specifications, documents, and is still doing investigation on provisioning of QoS over networks based on the Internet protocols. This section intends to show a summary of the most significant efforts in this field. Notice that, as the Internet is not tied to any specific network technology, the QoS mechanisms outlined here will work over and/or in co-operation with the specific network QoS mechanisms. G-2.1 RSVP Resource Reservation Protocol (RSVP) [2] is a protocol dedicated to being the facilitator and carrier of standardised QoS information and parameters. RSVP carries generic (industry-defined) QoS parameters from end nodes (inclusive) to each QoS-aware network device included in the path between RSVP session members. That is, RSVP is a means by which end nodes and network devices can communicate and negotiate QoS parameters and network usage admission.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

239 / 247

RSVP provides a mechanism for end systems to convey information to network devices about application data flow. Network devices can then take QoS- or policy-related action based on this information. From a policy-driven perspective, RSVP provides the necessary user information within industry standard–RSVP objects (much like a set of containers, each of which is defined based on its standard formats), that facilitate the exchange of user identity and admission requests. RSVP handles simplex flows, both for unicast and multicast sessions. So, the originator and the receiver of the data flow are treated in a different way. RSVP is not intended to transport data, nor to handle routing. It is a signalling protocol in which QoS requests are indicated. In this way, it can be used in the Integrated Services in the Internet [1] [4] as reservation protocol. Sending hosts generate RSVP messages known as PATH messages. These carry information describing the traffic sent on a specific conversation. The traffic description includes the identity of the sending user, the sending application, the sent traffic profile (bandwidth and burst characteristics), and the classification criteria by which the traffic can be recognised (for instance, source and destination IP addresses, and source and destination higher-layer ports). PATH messages go towards the receiver through the same way as data traffic would do. At each network device along the route, a PATH state is installed. When PATH messages arrive to their destinations, the receivers respond by sending RESV messages. These identify the receiving user, the type of IntServ required, and the amount of resources required. RESV messages return to senders along the same path traced by the PATH messages. As RESV messages arrive at network devices, they apply admission control to determine whether or not there are sufficient resources to accommodate the receiver’s request. If there are, the request is admitted, otherwise is rejected, thus yielding an error message notifying other RSVP-aware devices of the admission control failure. RSVP flow specifications include service class and two sets of numeric parameters Rspec, which defined the desired QoS, and Tspec, that described the data flow. The formats of Rspec and Tspec are generally opaque to RSVP, and are defined by the integrated service models [4] [3]. For the “guaranteed service” [12], the traffic flow specification Tspec of this QoS is a token bucket plus a peak rate p, a minimum policed unit m and a maximum datagram size M. The token bucket has a bucket depth b and a bucket rate r. Rates r and p are measured in bytes of IP datagrams per second (up to 40 Tbytes/s). Bucket depth b is measured in bytes, and can range up to 250 Gbytes. Peak rate is the maximum rate at which the source (or any reshaping point) may inject bursts into the network. All datagrams with size lower than m will be counted as being of size m. If the MTU of the link is lower than M, the flow should be rejected. The Rspec is defined as a rate R and a slack term S. The rate R is measured as r and p. It can be greater than the Tspec rate, in order to reduce the queuing delay. The slack term S is given in microseconds, and signifies the difference between the desired delay and the delay obtained by using a reservation level R. Another possible service type that RSVP can request is the “Controlled-Load”. This service expects the behaviour described in [13] as the one visible to applications receiving best effort service under unloaded

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

240 / 247

conditions. Its specification only uses the Tspec element, with the same meaning as for the guaranteed QoS. RSVP has been criticised as a means to provide QoS support in the Internet for the following reasons: - Poor scalability, as it requires the maintenance of state information on each device, associated to

every flow that passes through it. Clearly this would be unmanageable in a backbone router. - The lack of policy mechanisms to govern, in a secure manner, which traffic flows are granted

privileged access to network resources. - RSVP focused on protecting multimedia applications and not other non-multimedia mission-critical

applications.

Despite this initial criticism, RSVP is now being considered again as a valuable component, but within a broader set of QoS components. Reasons for this include: • Availability of RSVP signalling in a large number of hosts, especially those based on Microsoft OSs. • Scalability problems of RSVP can be greatly reduced if it is combined with other mechanisms,

especially Differentiated Services (see section G.3) • Recent work applying RSVP signalling to non-multimedia applications. G.3 Internet Differentiated Services (DiffServ) QoS model. The Differentiated Services Working Group belongs to the Transport Area within IETF. Their purpose is to define an architecture for implementing scalable service differentiation in the Internet. Traffic classification is conveyed by means of IP-layer packet marking using the DS field, which is a six-bit field common for IPv4 TOS and IPv6 Traffic Class octets. RFC 2474 and RFC 2475 define the architecture, and the general use of bits within the DS field (superseding the IPv4 TOS octet definitions of RFC 1349). Packets are classified based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other information such as incoming interface. A Service defines some significant characteristics of packet transmission: throughput, delay, jitter, and/or loss. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service. Differentiated services specification [5] was produced to overcome the scalability concerns of RSVP. The distinguishing feature of DiffServ is its scalability. The traffic handling mechanisms envisioned in RSVP/Integrated Services networks are per-conversation mechanisms. These treat each traffic flow between each instance of a sending and receiving application, in isolation. Aggregate mechanisms, such as DiffServ, group many traffic flows into a single aggregate class. Per-conversation traffic handling mechanisms rely on per-conversation classifiers. These typically use the IP source and destination addresses and ports to uniquely identify conversations. Aggregate traffic handling mechanisms typically rely on some mark in a packet that aggregates it into a queue shared by other packets with the same mark. Before the packet is submitted to the aggregate traffic handling mechanism, it must be marked with the appropriate tag. Aggregate traffic handling mechanisms require significantly less state and processing

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

241 / 247

power in network nodes than their per-conversation counterparts. This benefit is most significant in large networks that are required to handle large numbers of conversations. The compromise of aggregate traffic handling is that the QoS enjoyed by each conversation is dependent on the behaviour of the other conversations with which it is aggregated. DiffServ is a traffic handling mechanism. Differentiated services enable packets that pass through network devices operating on Layer 3 information, such as routers, to have their relative priority differentiated from one another. With differentiated services marking, Layer 3 devices can establish aggregated precedence-based queues and provide better service (when packet service is subject to queuing, as is the case under significant traffic loads) to packets that have higher relative priority. For differentiated services to be effective, Layer 3 devices must be DSCP-enabled. DiffServ defines a field in packets' IP [7], (6 bits in the TOS field of the IP header) to specify its value, called the DSCP (DiffServ code point); the first three of which were formerly used for IP precedence. Differentiated services have subsumed IP precedence, but maintain backward compatibility. Hosts or routers sending traffic into a DiffServ network mark each transmitted packet with a DSCP value. Routers within the DiffServ network use the DSCP to classify packets and apply specific queuing behaviour (known as per-hop behaviour or PHB) based on the results of the classification. Traffic from many flows having similar QoS requirements is marked with the same DSCP, thus aggregating the flows to a common queue or scheduling behaviour. When designing DiffServ some considerations were made: not depend on hop-by-hop application signalling, require only a small set of forwarding behaviours whose implementation complexity does not dominate the cost of a network device, work with existing applications, permit reasonable interoperability with non-DS-compliant network nodes and accommodate incremental deployment. The Working Group has standardised a small number of specific per-hop behaviours (PHB) and recommended a particular bit pattern or codepoint of the DS field for each one, in RFC 2474, RFC 2597, and RFC 2598. At present the DiffServ Working Group has defined some PHBs: • Expedited forwarding (EF) PHB [7]. The EF PHB is defined as a forwarding treatment for a particular

DiffServ aggregate where the departure rate of the aggregate’s packets from any DiffServ node must equal or exceed a configurable rate. The EF traffic should receive this rate independent of the intensity of any other traffic attempting to transit the node. It should average at least the configured rate. The configured minimum rate must be settable by a network administrator.

• Assured forwarding (AF) PHB [8]. Four classes are defined, and for each of them, packets may be marked with three possible drop precedence values. More AF classes or levels of drop precedence may be defined for local use. A DiffServ node must allocate a configurable minimum amount of forwarding resources to each implemented class. A class may receive more forwarding resources if there are excess resources available from other AF classes or PHB groups. There are no quantifiable timing requirements associated with the forwarding of AF packets.

• Default (Best Effort) PHB [6]. No guarantee for QoS. It is the one applied currently in the Internet. Notice that there will be much more PHBs, even with local or experimental significance, as it is suggested in draft [9]. The WG is now working in the development, of a format for precisely describing various

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

242 / 247

Behaviour Aggregates (BAs), which were initially defined in RFC 2474 and 2475. A BA is a collection of packets with the same codepoint, thus receiving the same PHB, from edge to edge of a single DiffServ network or domain. Associated with each BA are measurable, quantifiable characteristics which can be used to describe what happens to packets of that BA as they cross the network, thus providing an external description of the edge-to-edge quality of service that can be expected by packets of that BA within that network. A BA is formed at the edge of a network by selecting certain packets through use of classifiers and by imposing rules on those packets via traffic conditioners. The description of a BA contains the specific edge rules and PHB type(s) and configurations that should be used in order to achieve specified externally visible characteristics. In addition to defining a format for BA descriptions, specific descriptions of BAs that can be constructed using the standard PHBs will be developed and reviewed by a design team prior to informational or standards track publication. Differentiated services architecture only provides service differentiation in one direction of traffic flow and is therefore asymmetric. Development of a complementary symmetric architecture is a topic of current research. G.4 Performance problems of window based transport protocols over satellite. As TCP is the most widely used reliable transport protocol, its performance over satellite networks will be examined in this section. TCP performance depends not upon the transfer rate itself, but rather upon the product of the transfer rate and the round-trip delay. This "bandwidth x delay product" measures the amount of data that would "fill the pipe"; it is the buffer space required at sender and receiver to obtain maximum throughput on the TCP connection over the path. TCP performance problems arise when the bandwidth x delay product is large. An Internet path operating in this region is referred to as a "long, fat pipe", and a network containing this path as an "LFN”. Satellite networks are a typical case of these LFN networks. The following discussion about TCP behaviour over satellite networks has been taken mainly from [14]. Also, the proposed solutions for Wireless networks can be also considered as discussed in RFCs 3481, 3135, 3155, 2988 and 3449. G-4.1 Issues and Challenges The challenges in satellite TCP arise from the various inherent features of satellite channels and network features. These are briefly outlined. G-4.1.1 Channel Asymmetry Many satellite systems have bandwidth asymmetries between forward and backward data channels. There are some architectures where the return channel is implemented using a terrestrial channel instead of a satellite channel, and sometimes this terrestrial link has very low bandwidth (e.g. modem). This can be acceptable up to some extent, when TCP transfers are unidirectional and only TCP ACKs will travel on the return link. But asymmetric configurations can cause significant problems for TCP. For example, it is well known that slower reverse channels can induce deleterious effects such as ACK loss and compression, since ACK packets can get dropped or queued behind larger data packets, thus reducing the throughput. The throughput can also worsen if the return channel is much slower than the forward

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

243 / 247

channel in such a way that the transmission time of an ACK in the slow channel is greater than the transmission time of a maximum sized data PDU in the fast channel. G-4.1.2 Propagation Delays GEO satellite propagation delay is in the range 250–280 ms. In general, such delay conditions are problematic for TCP, reducing its responsiveness to packet loss. This is especially noticeable for connections wanting only to send marginally more than the default startup window size (one segment); that is, users must wait a full round-trip delay before the first ACK packet is received in the slow-start phase. Delayed ACK timers at the receiver can also exacerbate this problem, since the first segment cannot trigger the "ACK-every-other" rule. Another problem appears when there is a fast channel: as commercial TCP implementations usually handle the 16-bit window, thus imposing a 64Kbyte if unsigned integers are considered, the transmission window may become exhausted before receiving the first ACK from the other side, so having a stop-and-wait behaviour applied to transmitted data bursts, until ACKs arrive and transmission can proceed. Several solutions to this problem have been proposed, some of them deal with increasing TCP window size. But if extended windows are used, satellite delays combined with increasing channel speeds (ten of megabits per second or more) may require significant buffering. G-4.2 Solutions based on TCP modifications G-4.2.1 Window size As it has been indicated above, TCP default window size representation is limited to 16 bits, and this value may be insufficient for satellite bandwidth-delay products. This limits maximum throughput to roughly 1 Mbps. Simply assigning more bits for the TCP window size is not useful since associated changes to the header pose many interworking complications with older versions. The window scaling option described in IETF RFC 1072 and RFC 1323 [11] addresses this issue, allowing connections to negotiate a scaling factor on connection setup phase. This factor is a power of 2 and allows for window sizes up to 32 bits in length, which can easily cope with satellite networks. G-4.2.2 Sequence number ing Increased window sizes provided by mechanisms like the one outlined above may cause sequence number wraparound problems so protection against wraparound sequence numbers (PAWS) mechanisms are required [11]. G-4.2.3 Round tr ip time measurements Large round-trip delay variability can yield inaccurate round-trip time estimates, which will inevitably reduce the efficiency of TCP's loss detection mechanism. One shortcoming is that TCP's timer mechanism only clocks a single segment at a time, resulting in too coarse a sampling rate for dynamic conditions and large window environments, especially if buffering delays are of the same order as propagation delays. The proposed TCP echo option, which is signalled at startup (i.e., SYN handshake), solves this problem by associating a sender-side timestamp with each segment. Receivers echo these timestamps and provisions are given for handling delayed ACK timers and non-contiguous sequence

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

244 / 247

numbers (i.e., dropped segments); see IETF RFC 1072. The echo option is crucial for TCP satellite networks considering the larger delay variability and increased buffering requirements. G-4.2.4 Path MTU discovery. Larger TCP segment sizes will help open up the slow-start congestion window faster in long-delay environments. To this end, the well-known path maximum transmission unit (MTU) discovery approach can be used, essentially probing the network for the maximum IP (TCP) packet size, which can be supported along the end-to-end path. Although the delays incurred during the probing stage can be on the order of multiple round-trip times, MTU discovery can yield good benefits if maximum segment sizes are not known a priori. If the results of MTU discovery are stored, this can reduce latencies for future connections (in relatively static topologies). G-4.2.5 Slow star t phase. Since the slow start phase relies on returning ACK packets to increase window sizes, there is a direct dependence between round-trip times and bandwidth efficiency. Several methods have been proposed to reduce the amount of time required by slow start (and therefore, the amount of wasted capacity): • Increase the initial value of the congestion window cwnd. • using delayed ACKs only after slow start • Using byte counting: the congestion window increase is based on the number of previously

unacknowledged bytes covered by each incoming ACK, rather than on the number of ACKs received. This makes the increase relative to the amount of data transmitted, rather than being dependent on the ACK interval used by the receiver.

• Terminating slow start earlier by setting ssthresh to the product delay*bandwidth. • Allowing senders to transmit data with the first (SYN) segment (IETF RFC 1644) to avoid the "extra"

round-trip delay incurred by the three-way TCP handshake. The increase of the default window size allows more packets to be sent at startup, thereby triggering more ACKs and hence faster growth. In addition, a startup window size of two or more segments will also eliminate any additional delays caused by the delayed ACK timer. The exact choice of the initial window size is an open issue. Overly large values can be too aggressive and actually worsen packet drop rates. However, studies have shown that an initial value of four segments improves startup times significantly, without a corresponding (noticeable) increase in the packet loss. Results show savings of up to three round-trip times plus the ACK delay timer interval. G-4.2.6 Selective Acknowledge. A significant enhancement to the TCP protocol has been developed, termed selective acknowledgment (i.e., TCP SACK, IETF RFC 2018). TCP SACK is a data recovery algorithm, where receivers can selectively indicate which blocks (segments) were not received. This allows senders to explicitly retransmit only these omissions and can significantly reduce unnecessary retransmissions. Furthermore, careful consideration has been made to also allow incorporation of existing congestion control features, such as slow start, congestion avoidance, and fast recovery/retransmit. Nevertheless, excessive packet losses can cause SACK to run out of ACKs, and again, the basic timeout mechanism must be deployed here. SACK uses TCP headers to carry information on the missing blocks, although the current size only has space for indicating three regions. Results show that TCP SACK performs very well in long-delay environments with moderate losses

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

245 / 247

(under 50 percent of the window size), retransmitting all lost segments within the first round-trip time after fast recovery is triggered. Some comprehensive studies state that the SACK feature significantly reduces timeouts and is not overly aggressive when competing with non-SACK versions. The SACK option requires significant modifications to both the sender and receiver protocol stacks. G-4.2.7 Asymmetry Considerations An effective solution for asymmetric channel problems is to provide adequate reverse direction bandwidth and using sufficiently large packet sizes. Otherwise, increased forward buffering is required to handle larger line-rate bursts. However, more elaborate ACK handling schemes that push out older ACKs (drop-from-front strategies) or even manipulate ACK sequence numbers (ACK filtering schemes) may be useful. These solutions tend to keep and return ACK packets that contain higher sequence numbers, improving overall behaviour. Another proposed solution is to reduce the receiver's ACK generation rate: an "ACK-every-k" strategy where k > 2. This technique can reduce the loading on a slower ACK channel, but it can significantly lower startup window growth. These mechanisms can worsen the performance of recovery algorithms, and even SACK algorithms, as fewer ACKs are generated. The use of selective negative acknowledgements (SNACKs) has been proposed as a solution, with a modified TCP source simply retransmitting NACK blocks (i.e., not relying on the fast-retransmit mechanism to detect losses). Results show improved linear throughput degradation for increasing asymmetry. Since many fields in the TCP and IP headers remain constant over the life of a flow, it is not necessary to repeatedly include them in all transmissions. Well-known header compression techniques can reduce the volume of data on the bandwidth-constrained reverse links. G-4.3 Solutions based on Intelligent Interworking G-4.3.1 Multiple TCP Sessions One method of improving TCP transfers over satellite paths is to instantiate several parallel TCP sessions and stream data over them. Results show significant performance improvements in noisy satellite environments compared to a single connection (utilization, transfer times, etc). In addition, connection ramp-up times are greatly reduced by essentially increasing the initial window size to N segments, where N is the number of TCP connections. However, this approach results in an aggregate, which is less responsive to packet losses than is a single TCP connection. Several authors have described the effect of multiple TCP sessions as inducing "SACK-like" behaviour on the aggregate transfer; moreover, results show that performance improvements are actually better than those with a single TCP SACK session. Since multiple sessions imply smaller operating window sizes per session, burst losses are less likely to only affect a given flow. G-4.3.2 Shar ing TCP State Among Similar Connections.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

246 / 247

An alternative to attempting to select the parameters a-priori is sharing state across TCP connections and using this state when initialising a new connection. For example, if all connections to a subnet result in extended congestion windows of 1 megabyte, it is probably more efficient to start new connections with this value, than to rediscover it by requiring the cwnd to increase using slow start over a period of dozens of round-trip times. G-4.3.3 Link-Layer Interworking • Usage of link error feedback schemes, such as explicit loss notification (ELN) in ACK packets, ACK

snooping, and multiple/partial ACKs. Researchers have also integrated link-layer corruption indications more directly into modified satellite TCP stacks. For example, the Space Communications Protocol Standards-Transport Protocol (SCPS-TP) changes TCP's default window-reduction property upon loss detection by using a broader loss definition, namely congestion, corruption, or even connectivity. Remote base stations echo congestion-experienced or link-outage ICMP messages, in addition to regular duplicate ACK packets, and modified TCP sources use this information to avoid unnecessary window reduction. This gives very good improvements for higher BER channels, although some may argue that it violates the layering approach.

• Spoofing refers to techniques that "split" TCP connections between the (end) source and destination clients into two or more parts. Essentially, this breaks the end-to-end semantics of TCP by creating multiple connections terminated at the designated (access) nodes.

G-4.3.4 ACK Control Schemes Basically these schemes are:

• Delaying returning ACK packets (ACK pacing). This is a technique, used in the absence of incoming ACKs, where the data sender temporarily paces TCP segments at a given rate to restart the ACK clock. Upon receipt of the first ACK, pacing is discontinued and normal TCP ACK clocking resumes.

• Modifying the receiver window field in returning ACK packets (receiver window modification).

A benefit of ACK control is that no changes are necessary for TCP protocol stacks, and only sender-side complexity is incurred.

SATLIFE

D210 DATE:

01/10/2004

ISSUE:

01

PAGE:

247 / 247

H. RELATED DOCUMENTS [1] RFC 1633. Integrated Services in the Internet Architecture: an Overview. R. Braden, D. Clark, S.

Shenker. June 1994. [2] RFC 2205. September 1997. Resource reSerVation Protocol (RSVP) -- Version 1 Functional

Specification [3] RFC 2210. September 1997. The Use of RSVP with IETF Integrated Services. [4] RFC 2215. September 1997. General Characterisation Parameters for Integrated Service Network

Elements [5] RFC 2475. December 1998. An Architecture for Differentiated Services. [6] RFC 2474. December 1998. Definition of the Differentiated Services Field (DS Field) in the IPv4

and IPv6 Headers. [7] RFC 2598. June 1999. An Expedited Forwarding PHB. [8] RFC 2597. June 1999. Assured Forwarding PHB Group. [9] Internet Draft. August 1999. Management of PHBs. [10] A. S. Tanenbaum. Computer Networks 3rd Edition. Prentice Hall International 1996. [11] RFC 1323 TCP Extensions for High Performance V. Jacobson, R. Braden D. Borman May 1992. [12] RFC 2212. Specification of the guaranteed quality of service. [13] RFC 2211. Specification of the controlled load network element service. [14] Nasir Ghani, Sudhir Dixit. TCP/IP Enhancements for Satellite Networks.

IEEE Communications Magazine, July 1999. [15] M. Ammar, S. Ferenci, R. Fujimoto, K. Perumalla, G. Riley, A. Park, Hao Wu, “Simulation of

Large-Scale Communication Networks How Large? How Fast?” , 2002 [16] http://www.isi.edu/nsnam/ns/doc/index.html, Marc Greis, “NS Manual” [17] http://www.opnet.com, OPNET Technologies website [18] http://www.cc.gatech.edu/computing/pads/pdns.html, PDNS website [19] http://www.ssfnet.org/homePage.html, SSFNet website [20] www.ece.gatech.edu/research/labs/MANIACS/gtnets.htm, GTNetS website

Documents

SATLIFE-IST-1-507675 D210 DVB-RCS regenerative … regenerative (and transparent) system services requirements report Contractual Date of Delivery to the CEC: ... 4.3 SOFTWARE DOWNLOAD