Concepts for Service adaptation, scalability and QoS ... - CiteSeerX

Concepts for Service adaptation, scalability and QoS handling on mobility enabled networks Andreas Kassler, Dave Wisely, Louise Burness, Toms Robles, Hctor Velayos, Alberto Lopez Toledo, Felix Javier Garcia Philippe Jacquet, Georges Gyory, Francois Dumontet, Nikos Georganopoulos Georg Neureiter, Christian Hellwig, Ern Kovacs, Oliver Schramm, Matthias Riedel, Davide Mandato.∗ Abstract: This document investigates concepts of Service Adaptation, Scalability, QoS Handling and Management on mobility-enabled IP based networks. This deliverable focuses on managing QoS End-to-End including mobile end-systems and IP based wireless access networks (i.e. the BRAIN Access Network, BAN) in the transmission path. This includes the possible impact of mobility on QoS issues. In order to solve this issue, rapid QoS signalling, QoS Management and adaptation mechanisms are required. , Abstract mechanisms of the BRAIN End-to-End QoS framework are introduced and a QoS and Mobility architecture above the transport layer is derived. Keywords: BRAIN, Beyond 3G, IP, Mobility Support, Quality of Service, QoS, User, Service, Application, Multimedia, Legacy, Wireless, QoS Adaptation, QoS Broker, QoS Framework, QoS Mechanism, QoS Control, QoS Management, QoS Provision, Resources, Controllers, ESI, End-to-End Negotiation, Adaptation Path, QoS Service Cubicle, Renegotiation, Synchronisation, QoS Correlation, Scenario, Use Case.

∗

Please see inside for affiliation of all the authors

IST-1999-10050 BRAIN Deliverable 1.2 Concepts for Service adaptation, scalability and QoS handling on mobility enabled networks.

Contractual Date of Delivery to the CEC: 31.3.2001 Actual Date of Delivery to the CEC: Author(s):

31.3.2001

Davide Mandato

Participant(s): Agora Systems, British Telecom, Ericsson, INRIA, King's College London, Siemens, Sony, T-Nova Berkom Workpackage: WP1 – Services and Applications Est. person months: 70 Security:

PUB

Nature:

R

Version: Total number of pages: 229 Abstract: This document investigates concepts of Service Adaptation, Scalability, QoS Handling and Management on mobility-enabled IP based networks. This deliverable focuses on managing QoS End-to-End including mobile end-systems and IP based wireless access networks (i.e. the BRAIN Access Network, BAN) in the transmission path. This includes the possible impact of mobility on QoS issues. In order to solve this issue, rapid QoS signalling, QoS Management and adaptation mechanisms are required. , Abstract mechanisms of the BRAIN End-to-End QoS framework are introduced and a QoS and Mobility architecture above the transport layer is derived. Keyword list: BRAIN, Beyond 3G, IP, Mobility Support, Quality of Service, QoS, User, Service, Application, Multimedia, Legacy, Wireless, QoS Adaptation, QoS Broker, QoS Framework, QoS Mechanism, QoS Control, QoS Management, QoS Provision, Resources, Controllers, ESI, Endto-End Negotiation, Adaptation Path, QoS Service Cubicle, Renegotiation, Synchronisation, QoS Correlation, Scenario, Use Case

CEC Deliverable Number 1.2

1 / 229

Del 1.2 Draft v6.03.doc

Draft / 06.02

29.3.2001

The authors would like to dedicate this deliverable to Aki Laukkanen, a much liked and highly respected colleague who made valuable contributions to our work before his tragic death earlier this year. Our sympathies go out to his family and friends in Finland in their grief.


2 / 229


Draft / 06.02

29.3.2001

Executive Summary Wireless access to both Telecom and Internet services are getting more and more focus in telecommunications and, more particularly, in mobile computing. Known benefits of IP-based protocols are interoperability, the support of different terminals and application-specific features. The development of micro/macro IP mobility and wireless IP technologies paves the way to a full integration of the Internet with the 2nd and 3rd generation of mobile phone systems, thus unleashing a broad set of possible new applications and services that can be offered to both sedentary and nomadic users. Moving a step further, the BRAIN (Broadband Radio Access for IP Based Networks) project has been proposed to study a system architecture that combines broadband radio access technology based on the HIPERLAN/2 standard with other wireless access network technologies (like UMTS), to enable full coverage of seamless IP-based services for users in hot spot areas and on the move. In addition to enabling broadband wireless and mobile access to the Internet, the BRAIN architecture will combine these features with support for QoS-aware applications and services, thus enabling new kinds of applications that benefit from this synergy. For instance, with BRAIN technology it will be possible to achieve high quality audio and video wireless transmission by using IP services, with support for QoS throughout the whole BRAIN architecture. This deliverable focuses on managing QoS End-to-End including mobile end-systems and IP based wireless access networks (i.e. the BRAIN Access Network, BAN) in the transmission path. This includes the possible impact of mobility on QoS issues. The support of QoS in conjunction with mobility is in fact quite difficult to achieve in the aforementioned BRAIN scenarios because of handovers and high error rates. To solve this issue, very rapid QoS signalling and adaptation mechanisms are required. This in particular translates into a significant amount of additional software functionality in the terminal devices. This deliverable contains two major parts. The first part elaborates a generalised QoS framework for distributed multimedia systems providing support for mobility, taking into account state of the art solutions. First, we introduce the concept of a re-negotiable QoS contract and a simple model of what we understand as QoS. Then we introduce a number of well-known design principles and QoS mechanisms. Based on these foundations and on requirements deduced from BRAIN deliverable 1.1, we then present the BRAIN QoS Framework. The BRAIN Framework, is centred on a set of intuitive design patterns, and introduces a set of innovative concepts. First of all we introduce a hierarchy of streams and associations and describe adaptation paths that allow users to specify the behaviour of the system in case fewer resources become available. Finally, we provide some admission control functionality and draft several protocol variants for an End-to-End negotiation of QoS that includes local resource reservation and adaptation path strategies. The second part of this deliverable presents a QoS and Mobility architecture above the transport layer, capable of implementing the mechanisms of the BRAIN QoS framework. This architecture, known as BRENTA (BRain ENd Terminal Architecture), makes use of the services offered by a BRAIN-enabled transport protocol stack through a so-called Extended Socket Interface (ESI), which is detailed in BRAIN deliverable 2.2. CEC Deliverable Number 1.2

3 / 229


Draft / 06.02

29.3.2001

BRENTA is designed to offer a step-wise approach to deployment of various types of applications. By following this approach, BRENTA can accommodate applications of various complexity, ranging from today’s legacy application (QoS-unaware or only partially aware) all the way to foreseen light applications delegating QoS issues to a third party entity, called the QoS Broker. The deliverable then includes a few simple examples, which help to show how the BRAIN QoS Framework implemented within BRENTA works. Finally, we conclude this document with an evaluation of BRENTA with respect to the original goals, and a comparison of our work with other well-known architectures. A set of appendices is included at the end of this document: Appendix A provides an overview of the BRENTA requirements. We start with use case analysis based on usage scenarios already developed in BRAIN deliverable 1.1. We then describe application and service issues and their associated QoS violations. We introduce several performance metrics and provide background information on our measurement subsystem used for detecting QoS violations. This appendix concludes with a short discussion of Network and Communication Terminal Aspects and makes some proposals on a typical BRAIN terminal. Appendix B presents an in depth analysis of traffic models and multimedia streams, which is necessary for deriving QoS parameters for the transport layer used in the ESI. We analyse several scenarios: packetized voice, videoconferencing, video streams and different MPEG streams. We also include models of data traffic such as world-wide web browsing, e-mail, file transfer and simple on/off sources. Appendix C provides an in depth analysis of MPEG streams in order to derive a concrete traffic model for MPEG streams. We analyse MPEG1, MPEG2 and MPEG4 and recapitulate the traffic model analysis. Appendix D describes different communication terminals with their characteristics. Future trends in mobile terminals are presented in an effort to characterise one or more terminals to be used in the BRAIN network. Issues like resource availability, terminal capabilities, network capacity, and mobility aspects are addressed. Appendix E provides a survey of existing standards, projects and working groups. We focus in particular on the ETSI and on the ITU-T ISO/IEC approach, which we consider a very important architecture. Finally, Appendix F provides insight in the management of multiple streams and how QoS synchronisation could be achieved based on RTP. This leads to the concept of QoS correlation introduced at the end of this appendix.


4 / 229


Draft / 06.02

29.3.2001

Authors Partner

Name

University of Ulm (Siemens)

Andreas Kassler

Phone: +49-731 502 4146 Fax: +49-731 502 4142 E-mail: [email protected]

British Telecom

Dr. Dave Wisely

Phone: +44 147 364 3848 Fax: +44 147 364 6885 E-mail: [email protected]

British Telecom

Louise Burness


Agora Systems

Dr. Tomás Robles Valladares

Phone: +34 91 549 5700 +367 Fax: +34 91 336 7333 E-mail: [email protected]

Agora Systems

Héctor LuisVelayos

Phone: +34 91 533 58 57 Fax: +34 91 533 84 77 E-mail: [email protected]

Agora Systems

Alberto Lopez

Phone: +34 91 549 5700 +442 Fax: +34 91 676 482 956 E-mail: [email protected]

Ericsson

Felix Javier Garcia Visiedo

Phone: +34 91 3393774 Fax: +34 91 3394001 E-mail: [email protected]

INRIA

Philippe Jacquet

Phone: +33 1 39 635263 Fax: +33 1 39 63 55 66 E-mail: [email protected]


Phone / Fax / E-mail

5 / 229


Draft / 06.02

29.3.2001

Partner

Name

INRIA

Georges Gyory

Phone: +33 1 39 635150 Fax: +33 2 99 84 5566 E-mail: [email protected]

INRIA

Francois Dumontet

Phone: +33 1 39 635125 Fax: +33 1 39 63 5566 E-mail: [email protected]

King’s College London

Nikos Georganopoulos

Phone: +44 207 848 2889 Fax: E-mail: [email protected]

T-Nova Berkom

Georg Neureiter


T-Nova Berkom

Christian Hellwig


SONY

Ernö Kovacs


SONY

Oliver Schramm


SONY

Matthias Riedel


SONY

Davide Mandato



Phone / Fax / E-mail

6 / 229


Draft / 06.02

29.3.2001

Table of Contents LIST OF FIGURES ................................................................................................................................. 12 ABBREVIATIONS .................................................................................................................................. 14 ABBREVIATIONS .................................................................................................................................. 14 1.

INTRODUCTION............................................................................................................................ 18 1.1 1.2 1.3 1.4 1.5 1.6

2.

SCOPE ......................................................................................................................................... 18 GOALS......................................................................................................................................... 19 DERIVED REQUIREMENTS FOR BRENTA.................................................................................... 21 THE BRAIN END TERMINAL ARCHITECTURE (BRENTA) - INTRODUCTION .............................. 23 DOCUMENT STRUCTURE ............................................................................................................. 25 REFERENCES ............................................................................................................................... 26

QOS FRAMEWORK FOR ADAPTABLE SERVICES WITH MOBILITY SUPPORT ......... 27 2.1 DISTRIBUTED MULTIMEDIA SYSTEMS ......................................................................................... 27 2.2 CONCEPT OF A QOS CONTRACT .................................................................................................. 28 2.3 CONCEPT OF GENERALISED QOS FRAMEWORK .......................................................................... 28 2.3.1 General QoS Principles...................................................................................................... 32 2.3.2 QoS Mechanisms ................................................................................................................ 34 2.3.2.1 2.3.2.2 2.3.2.3

QoS Provision Mechanisms ................................................................................................. 34 QoS Control Mechanisms..................................................................................................... 34 QoS Management Mechanisms .......................................................................................... 35

2.4 BRAIN QOS FRAMEWORK ......................................................................................................... 37 2.4.1 Overview............................................................................................................................. 37 2.4.2 QoS Adaptation Framework............................................................................................... 39 2.4.3 Levels of Quality of Service ................................................................................................ 40 2.4.3.1

2.4.4 2.4.4.1 2.4.4.2

2.4.5 2.4.5.1 2.4.5.2 2.4.5.3

2.4.6 2.4.7

A simple QoS Model .............................................................................................................. 41

Resource Provider / Consumer Design Pattern ................................................................. 44

Resource Providers ................................................................................................................. 45 Resource Consumers .............................................................................................................. 47

QoS specification and monitoring design pattern .............................................................. 48

Definition of QoS contract ................................................................................................... 48 QoS monitoring and QoS violation detection ................................................................ 50 Per flow adaptation strategies.............................................................................................. 51

QoS Mapping: a Design Principle ..................................................................................... 52 Multi-stream synchronisation and QoS correlation ........................................................... 55

2.4.7.1 Introduction ............................................................................................................................... 55 2.4.7.2 The BRAIN Approach: the Data Model .......................................................................... 56 2.4.7.2.1 The Flow concept .................................................................................................................... 56 2.4.7.2.2 The QoS Context concept ........................................................................................................ 57 2.4.7.2.3 The Association concept.......................................................................................................... 59 2.4.7.2.4 Relationship between QoS Context and QoS Association ....................................................... 60 2.4.7.2.5 QoS- and synchronisation-specification model........................................................................ 60 2.4.7.2.6 Adaptation Path ....................................................................................................................... 60 2.4.7.2.7 Negotiation of the Adaptation Path.......................................................................................... 62 2.4.7.3 Example...................................................................................................................................... 65

2.4.8

Profiles and QoS Adaptation Policies ................................................................................ 67

2.4.8.1 QoS profile ................................................................................................................................ 67 2.4.8.1.1 User QoS Profile...................................................................................................................... 67 2.4.8.1.2 User QoS Contract................................................................................................................... 68 2.4.8.1.3 Terminal Capabilities............................................................................................................... 70 2.4.8.2 QoS Contract Template ......................................................................................................... 71 2.4.8.3 Access control and privacy .................................................................................................. 72 QoS Policy................................................................................................................................. 72 2.4.8.4


7 / 229


Draft / 06.02

29.3.2001

2.4.8.5 Profile matching ...................................................................................................................... 73 2.4.8.6 Identifying, creating and exchanging profiles ................................................................ 73 2.4.8.7 Roles and links between user QoS profiles ..................................................................... 74 2.4.8.8 Requirements for the service applications ....................................................................... 74 2.4.8.8.1 Protocols .................................................................................................................................. 74 2.4.8.8.2 Data formats ............................................................................................................................ 74 2.4.8.9 Recommendation for terminals ........................................................................................... 74

2.5 ADMISSION CONTROL ................................................................................................................. 75 2.5.1 Framework Level Admission Tests ..................................................................................... 76 2.5.2 Resource Controller Admission Tests................................................................................. 77 2.6 END-TO-END QOS NEGOTIATION ................................................................................................ 78 2.6.1 Scope .................................................................................................................................. 78 2.6.2 Introduction........................................................................................................................ 78 2.6.3 The core concept of E2NP/E2RP ....................................................................................... 79 2.6.4 What to negotiate ............................................................................................................... 80

Types of supported E2NP ..................................................................................................... 81 Capabilities ................................................................................................................................ 81 2.6.4.2.1 Media Types and QoS Contract Dimensions ........................................................ 82 2.6.4.2.2 Codecs................................................................................................................................ 82 2.6.4.2.3 Bitrates ............................................................................................................................... 82 2.6.4.2.4 Terminal capabilities ..................................................................................................... 83 2.6.4.2.5 Network Resource Reservation support .................................................................. 83 2.6.4.3 QoS Contract ............................................................................................................................ 84 2.6.4.4 Adaptation Path........................................................................................................................ 84 2.6.4.1 2.6.4.2

2.6.5 2.6.6

2.6.6.1 2.6.6.2 2.6.6.3

Types of E2NP .................................................................................................................... 85 Mapping between Type of Service and Type of E2NP/E2RP ............................................. 86

Conversational Services ........................................................................................................ 86 Distribution Services .............................................................................................................. 87 Information Retrieval Services ........................................................................................... 87

2.6.7 End-to-End Re-negotiation Protocol (E2RP) ..................................................................... 87 2.6.8 Guidelines for E2NP/E2RP Specification .......................................................................... 89 2.7 DISCUSSION ................................................................................................................................ 90 2.8 REFERENCES ............................................................................................................................... 90 3.

THE BRAIN END TERMINAL ARCHITECTURE (BRENTA)................................................ 93 3.1 THE BRENTA LAYERED ARCHITECTURE................................................................................... 94 3.2 THE EXTENDED SOCKET INTERFACE ........................................................................................... 96 3.3 THE SESSION LAYER PROTOCOLS ............................................................................................... 98 3.3.1 Introduction........................................................................................................................ 98 3.3.2 The Session protocol layers................................................................................................ 98 3.3.2.1 3.3.2.2

H.323 ........................................................................................................................................... 99 SIP ................................................................................................................................................. 99

3.3.3 The implications for the BRAIN system.............................................................................. 99 3.4 THE BRAIN COMPONENT LEVEL API ...................................................................................... 100 3.4.1 The Component Model ..................................................................................................... 100 3.4.2 Concept of Virtual Transport Service............................................................................... 101 3.4.3 Basic components ............................................................................................................. 102 3.4.3.1 Component Coordinator ...................................................................................................... 102 3.4.3.2 Media Handler ........................................................................................................................ 104 3.4.3.3 Chain Coordinator ................................................................................................................. 104 3.4.3.4 Resource Managers and Resource Controllers ............................................................ 106 3.4.3.4.1 Resource Managers................................................................................................................ 107 3.4.3.4.2 Resource Controllers ............................................................................................................. 111

3.4.4 3.4.5

3.4.5.1 3.4.5.2

Session Manager .............................................................................................................. 114 Monitor components......................................................................................................... 114

Monitoring of Resources..................................................................................................... 115 Monitoring QoS Characteristics ....................................................................................... 116

3.4.6 MM Components .............................................................................................................. 117 3.5 THE BRAIN HIGH LEVEL API.................................................................................................. 119 3.5.1 Introduction...................................................................................................................... 119


8 / 229

Del 1.2 Draft v6.03.doc 3.5.2 3.5.3

4.

29.3.2001

High Level QoS API ......................................................................................................... 119 QoS Broker....................................................................................................................... 121

3.5.3.1 3.5.3.2 3.5.3.3

3.6

Draft / 06.02

QoS Reallocation......................................................................................................................... 123 Orchestration of Resources.......................................................................................................... 123 Use of fuzzy logic technology ..................................................................................................... 124

REFERENCES ............................................................................................................................. 125

EXAMPLE...................................................................................................................................... 127 4.1 THE SCENARIO .......................................................................................................................... 127 4.1.1 Goals ................................................................................................................................ 128 4.2 SETUP OF CONNECTION AND NEGOTIATION PROCESS................................................................. 128 4.3 NEGOTIATED QOS ADAPTATION PATH ...................................................................................... 130 4.3.1 QoS adaptation state planes of videoconference example................................................ 132 4.3.2 QoS adaptation state planes of Video on Demand example ............................................. 133 4.4 ASSUMPTIONS ........................................................................................................................... 133 4.5 ADAPTATION OF THE VOD SESSION (SCENARIO I) .................................................................... 134 4.6 OPTIMISATION OF THE VIDEOCONFERENCE SESSION (SCENARIO II) .......................................... 136 4.7 ADAPTATION DUE LACK OF LOCAL RESOURCES (SCENARIO III) ................................................ 136 4.8 REFERENCES ............................................................................................................................. 137

5.

DISCUSSION AND CONCLUSION............................................................................................ 138 5.1 EVALUATION............................................................................................................................. 138 5.1.1 End Terminal QoS Broker Scenario................................................................................. 138 5.1.2 Comparison with other architectures ............................................................................... 142 5.2 REFERENCES ............................................................................................................................. 146

APPENDIX A

DERIVED REQUIREMENTS FOR BRENTA ................................................... 148

A.1 USE CASES ................................................................................................................................ 148 A.1.1 Introduction...................................................................................................................... 148 A.1.2 BRAIN Overall Model ...................................................................................................... 148 A.1.3 Providers Viewpoint ......................................................................................................... 149 A.1.3.1 A.1.3.2

A.1.4 A.1.5 A.1.6

Service Providers......................................................................................................................... 149 Subscription to a Service ............................................................................................................. 150

The Problem Domain ....................................................................................................... 151 Users Point of View.......................................................................................................... 152 Usage Scenarios ............................................................................................................... 154

A.1.6.1 A.1.6.2 A.1.6.3

Leisure Time scenario ................................................................................................................. 155 Nomadic Worker scenario ........................................................................................................... 156 Medical Care scenario ................................................................................................................. 157

A.2 APPLICATION AND SERVICE ASPECTS ....................................................................................... 158 A.2.1 Definition of attributes ..................................................................................................... 159 A.3 QOS MONITORING .................................................................................................................... 160 A.3.1 Resources - The wrapping concept................................................................................... 161 A.3.2 QoS characteristics - The probing concept ...................................................................... 162 A.3.3 Key QoS characteristics ................................................................................................... 163 A.3.3.1 A.3.3.2

Session Level Performance Metrics............................................................................................. 163 Higher Level Performance Metrics.............................................................................................. 163

A.4 NETWORK AND COMMUNICATION TERMINAL ASPECTS ............................................................ 164 A.4.1 Concept of Personal Wireless Assistant ........................................................................... 164 A.4.2 Concept of Virtual Transport Service............................................................................... 165 A.4.3 BRAIN terminal ................................................................................................................ 166 A.4.3.1

A.5

BRAIN terminal/application classification.................................................................................. 167

REFERENCES ............................................................................................................................. 168

APPENDIX B

TRAFFIC MODELS OF MULTIMEDIA STREAMS ....................................... 170

B.1 INTRODUCTION ......................................................................................................................... 170 B.2 PACKET VOICE .......................................................................................................................... 170 B.3 VIDEOCONFERENCE .................................................................................................................. 171 B.4 STREAMING VIDEO MODELS ...................................................................................................... 173 B.4.1 MPEG video models......................................................................................................... 173

B.4.1.1 B.4.1.2

Markovian process models ............................................................................................ 173 Multilevel source traffic models .................................................................................. 174


9 / 229


B.4.1.3 B.4.1.4

Draft / 06.02

29.3.2001

Traffic model parameters ............................................................................................... 174 Statistical properties ......................................................................................................... 175

B.4.2 Autoregressive video model.............................................................................................. 175 B.5 DATA TRAFFIC MODELS............................................................................................................. 177 B.5.1 World wide web browsing ................................................................................................ 177 B.5.1.1 Memoryless on/off sources.......................................................................................................... 177 B.5.1.1.1 Long term dependent traffics ................................................................................................ 178 B.5.1.1.2 Long term dependence and packet loss in telecom traffics ................................................... 178 B.5.1.2 ETSI model for UMTS ................................................................................................................ 179 B.5.1.3 GTE Laboratories model ............................................................................................................. 180

B.5.2 File Transfer..................................................................................................................... 182 B.5.3 E-mail ............................................................................................................................... 182 B.6 REFERENCES ............................................................................................................................. 183 APPENDIX C

TRAFFIC MODELS .............................................................................................. 185

C.1 MPEG TRAFFIC......................................................................................................................... 185 C.1.1 MPEG stream structure.................................................................................................... 185 C.1.1.1 Elementary stream, program stream, and transport stream .......................................................... 185 C.1.1.2 Structure of the elementary streams............................................................................................. 185 C.1.1.3 Audio stream structure................................................................................................................. 185 C.1.1.3.1 MPEG1 Audio ...................................................................................................................... 185 C.1.1.3.2 MPEG2 Audio ...................................................................................................................... 186 C.1.1.3.3 MPEG4 Audio ...................................................................................................................... 187 C.1.1.4 Video stream................................................................................................................................ 187 C.1.1.4.1 MPEG1 and the group of frames structure............................................................................ 187 C.1.1.4.2 MPEG2, more options........................................................................................................... 188 C.1.1.4.3 MPEG4, everything permitted .............................................................................................. 188 C.1.1.5 Volume and bandwidth estimate in MPEG stream ...................................................................... 188 C.1.1.5.1 Big/small image size estimation............................................................................................ 188 C.1.1.5.2 Common bandwidth values................................................................................................... 189

C.1.2

Data traffic ....................................................................................................................... 189

C.1.2.1 Web access structure ................................................................................................................... 189 C.1.2.2 Statistical data.............................................................................................................................. 190 C.1.2.2.1 Heavy-tailedness of the traffic .............................................................................................. 193

C.2 C.3

RECAPITULATION OF THE TRAFFIC MODEL ANALYSIS................................................................ 195 REFERENCES ............................................................................................................................. 195

APPENDIX D

COMMUNICATION TERMINAL ASPECTS ................................................... 197

D.1 INTRODUCTION ......................................................................................................................... 197 D.2 FIXED TERMINALS ..................................................................................................................... 197 D.3 MOBILE TERMINALS .................................................................................................................. 197 D.4 TERMINAL ASPECTS .................................................................................................................. 198 D.5 THE CLASSMARK CONCEPT ...................................................................................................... 200 D.6 UMTS....................................................................................................................................... 200 D.6.1 3G terminals..................................................................................................................... 200 D.6.2 MExE................................................................................................................................ 201 D.7 REFERENCES ............................................................................................................................. 202 APPENDIX E GROUPS

SURVEY OF EXISTING STANDARDS, PROJECTS, AND WORKING 203

E.1 THE PLAYERS ............................................................................................................................ 203 E.2 ETSI APPROACH ....................................................................................................................... 204 E.3 ITU-T | ISO/IEC APPROACH .................................................................................................... 205 E.3.1 The Reference Model........................................................................................................ 206 E.3.1.1 The key concepts ......................................................................................................................... 206 E.3.1.2 QoS Characteristics ..................................................................................................................... 208 E.3.1.3 QoS Categories ............................................................................................................................ 210 E.3.1.4 QoS management......................................................................................................................... 210 E.3.1.5 Phases of QoS activity................................................................................................................. 211 E.3.1.5.1 Establishment Phase.............................................................................................................. 212 E.3.1.5.2 Negotiation mechanisms ....................................................................................................... 213 E.3.1.5.3 Resource allocation ............................................................................................................... 216 E.3.1.5.4 Operational Phase.................................................................................................................. 217 E.3.1.5.5 Tuning mechanisms............................................................................................................... 218


10 / 229

Del 1.2 Draft v6.03.doc E.3.2 E.3.3 E.3.3.1

E.4

Draft / 06.02

29.3.2001

QoS verification................................................................................................................ 219 The OSI QoS Framework ................................................................................................. 219 Management Entities ................................................................................................................... 222

REFERENCES ............................................................................................................................. 223

ANNEX F

QOS SYNCHRONISATION AND CORRELATION ................................................ 224

F.1 NETWORK SYNCHRONISATION .................................................................................................. 224 F.2 QOS SYNCHRONISATION ........................................................................................................... 224 F.2.1 RTP................................................................................................................................... 224 F.2.2 RTCP and stream Synchronisation................................................................................... 225 F.2.3 RTP header Compression................................................................................................. 226 F.3 DIFFERENT PEER FLOWS ............................................................................................................ 226 F.4 PRIORITY WITHIN MULTI-FLOWS ............................................................................................... 226 F.5 MULTI-FLOW MANAGEMENT VIA AGENT .................................................................................. 228 F.6 QOS CORRELATED FLOWS ......................................................................................................... 228 F.7 REFERENCES ............................................................................................................................. 229


11 / 229


Draft / 06.02

29.3.2001

List of Figures Figure 2.1: Horizontal and vertical coverage of a QoS Framework........................................................... 29 Figure 2.2: Hierarchy of QoS strategies..................................................................................................... 30 Figure 2.3: Generalised integrated QoS framework supporting adaptivity and mobility........................... 31 Figure 2.4: UML Analysis Class Diagram: Application Taxonomy .......................................................... 38 Figure 2.5: UML Analysis Class Diagram: QoS Adaptation Logic ........................................................... 40 Figure 2.6: Layers in distributed Multimedia applications......................................................................... 43 Figure 2.7: Resource consumption cycle ....................................................................................... 44 Figure 2.8: Adaptation path of the quality/interactivity QoS plane............................................................ 52 Figure 2.9: Choosing the right set of implementation and configuration parameters ................................ 53 Figure 2.10: Example of QoS Mapping ..................................................................................................... 54 Figure 2.11 General Data Model: QoS Context ......................................................................................... 63 Figure 2.12 General Data Model: Association ........................................................................................... 64 Figure 2.13 General Data Model: QoS Context vs. Association relationship ............................................ 64 Figure 2.14: QoS- and correlation-specification model ............................................................................. 65 Figure 2.15 Example: UML Statechart ...................................................................................................... 66 Figure 2.16: Structure of user QoS profiles ............................................................................................... 68 Figure 2.17: Tree representation of the QoS Contract (Some nodes have been removed from representation).................................................................................................................................... 70 Figure 2.18: Role of the QoS Policy in the QoS Negotiation..................................................................... 73 Figure 2.19: CC/PP application scenario ................................................................................................... 75 Figure 3.1: The BRAIN End-System layered Terminal Architecture (BRENTA)..................................... 95 Figure 3.2: Overall architecture of the ESI ................................................................................................ 97 Figure 3.3: BRENTA Component Model ................................................................................................ 101 Figure 3.4: VTS concept .......................................................................................................................... 102 Figure 3.5 Basic primitives about component capabilities discovery ...................................................... 103 Figure 3.6: Network operator selection and high level auto-configuration .............................................. 105 Figure 3.7: Resource Provider/Consumer Design Pattern........................................................................ 106 Figure 3.8: BRENTA wrapper concept.................................................................................................... 115 Figure 3.9: BRENTA Probing Concept ................................................................................................... 116 Figure 3.10: Relationship between BRAIN QoS Broker and BRAIN Component Level API................. 121 Figure 3.11: QoS Broker structure ........................................................................................................... 122 Figure 4.1: Example overview ................................................................................................................. 128 Figure 4.2: Adaptation path...................................................................................................................... 131 Figure 4.3: VoD QoS adaptation planes................................................................................................... 132 Figure 4.4: Videoconference QoS adaptation planes ............................................................................... 133 Figure 4.5: Generic QoS contract scheme to negotiate and detect QoS violations .................................. 134 Figure 5.1: Separated QoS management (Type D App.).......................................................................... 139 Figure 5.2: Merged QoS management (Type C App.) ............................................................................. 139 Figure A.1: Wrapper concept ................................................................................................................... 161 Figure A.2: Probe concept........................................................................................................................ 162 Figure A.3: Virtual Terminals Example................................................................................................... 165 Figure A.4: Virtual Transport Services Architecture ............................................................................... 166 Figure B.1: Packet Stream Produced by a Packet Voice Source.............................................................. 170 Figure B.2: Markovian process of big/small frame emission................................................................... 174 Figure B.3: staying time distribution in the Big and the Prediction image emission mode...................... 175 Figure B.4: Variable bit rate compressed video sources .......................................................................... 176 Figure B.5: Video packet generation process........................................................................................... 176 Figure B.6: Aggregation of independent on/off sources .......................................................................... 177 Figure B.7: WWW Traffic Pattern generated by a Browsing Session ..................................................... 179 Figure B.8: Document arrival pattern of a web user. ............................................................................... 181 Figure B.9: Traffic Pattern Generated by an FTP Session ....................................................................... 182 Figure B.10: E-mail log file histogram with 15000 samples.................................................................... 183 Figure C.1: MPEG 1 Layer III audio coding............................................................................................ 186 Figure C.2: MPEG 2 audio coding........................................................................................................... 187 Figure C.3: MPEG 2 sequence - frame size density graph....................................................................... 189 Figure C.4: Daily traffic to the World Cup web site ................................................................................ 192 Figure C.5: Hourly traffic variation ......................................................................................................... 193


12 / 229


Draft / 06.02

29.3.2001

Figure C.6: Distribution of session length and inter-arrival request ........................................................ 193 Figure C.7: File size distribution.............................................................................................................. 194 Figure C.8: Web site objects related file size distribution........................................................................ 194 Figure C.9: Complementary distribution function ................................................................................... 195 Figure C.10: Aggregated complementary distribution function............................................................... 195 Figure D.1: Generic MExE architecture................................................................................................... 202 Figure E.1: The Players............................................................................................................................ 204 Figure E.2: ETSI QoS Framework - Reference Model ............................................................................ 205 Figure E.3: ITU-T | ISO/IEC QoS Framework - Reference Model.......................................................... 206 Figure E.4: QoS Management Function................................................................................................... 208 Figure E.5: Generic, specialised, and derived QoS Characteristics.......................................................... 209 Figure E.6 Limits and thresholds ............................................................................................................. 212 Figure E.7: OSI QoS Framework ............................................................................................................ 220 Figure E.8: Outgoing flow of QoS requirements ..................................................................................... 221 Figure E.9 Incoming flow of QoS requirements ...................................................................................... 222


13 / 229


Draft / 06.02

29.3.2001

Abbreviations ACPI ADV AFUTT AMNet AMR ANUIT AP API APM AQUA AQuaFWiN ARQ AS ATM AUSTEL BER BIOS BRAIN BRENTA CATV CATSERVER CC/PP CCITT CD CDF ChC CHQ CIF CIGREF CMIP COPS CORBA COST CPU CS CSCW CTM DAP DAVIC DCOM DECT DLC DNS DQM DS, DiffServ DSCP E2NP / E2RP EC EDGE ESI ESL ESPRIT ETNO ETSI EU EURESCOM

Advanced Configuration and Power Interface Arbeitsgemeinschaft für Datenverarbeitung L'Association Française des Utilisateurs de Télécommunications American Network and Internet Services Adaptive Multi-Rate speech codec Assocazione Nazionale Utenti Italiani Di Telecomuniczioni6 Access Point Application Programming Interface Advanced Power Management Adaptive End-System Quality of Service Architecture Adaptive QoS Framework for Multimedia in Wireless Networks Automated Repeat reQuest Application Service Asynchronous Transfer Mode AUStralian TELecommunications Authority Bit Error Rate Basic Input Output System Broadband Radio Access for IP Based Networks BRAIN End Terminal Architecture CAble TV Cable TV Server Composite Capabilities/Preference Profiles Comité Consultatif International Téléphonique et Télégraphique Complementary Distribution Channel Definition Format Chain Coordinator Controlled Highest Quality Cells In Frames Club Informatique des Grandes Entreprises Françaises Common Management Information Protocol Common Open Policy Service Common Object Request Broker Architecture European Cooperation in the field of Scientific and Technical Research Central Processing Unit Communicating Sub-System Computer-Supported Cooperative Work Cordless Terminal Mobility Discrete-Autoregressive Process Digital Audio Video Council Distributed Component Object Model Digital European Cordless Telecommunications Data Link Control Domain Name System Dynamic QoS Management Differentiated Services DiffServ Codepoint End-to-End QoS Negotiation /Re-negotiation Protocol Error Control Enhanced Data rates for Global Evolution Extended Socket Interface / Enabled Service Interface Enhanced Socket Layer European Strategic Programme for Research and Development in Information Technology European Telecommunications Network Operators Association European Telecommunications Standards Institute European Union European for Research and Strategic Studies in Telecommunications


14 / 229

Del 1.2 Draft v6.03.doc EVUA FCC FEC FSM FTP GDMO GPRS GPS GSM GTE GUI HDTV HO HP HQA HSCSD HTML HTTP I/O ID IEC IEEE IETF IntServ INTUG IP IPCDN IPv4 / IPv6 ISDN ISO IT ITU ITU-T JMF JPEG LAN LDAP LQA MAC MASA MASI MEM MexE MH MIB MM MMI MMWN MOS MPEG MS MT MTU NA NEC NFS NIC NM NMDG

Draft / 06.02

29.3.2001

European Virtual Private Network Association Federal Communications Commission Forward Error Correction Finite State Machine File Transfer Protocol Guidelines for Definition of Managed Objects General Packet Radio System Global Positioning System Global System For Mobile Communication General Information Research Laboratories Graphical User Interface High Definition Television Hand-Over Hewlett Packard Highest Quality Attainable High Speed Circuit Switched Data Hypertext Mark-up Language Hypertext transfer protocol Input/Output Identification International Engineering Consortium Institute of Electrical and Electronics Engineers Internet Engineering Task Force Integrated Services International Telecommunications Users Group Internet Protocol IP over Cable Data Network Internet Protocol version 4 / version 6 Integrated Services Digital Network International Standardization Organization Information Technology International Telecommunication Union ITU – Telecommunication Standardization Sector Java Media Framework Joint Photographic Experts Group Local area network Lightweight Directory Access Protocol Lowest Quality Acceptable Medium Access Control Mobility and Service Adaptation in Mobile Networks Laboratoire d'Informatique de Paris 6 (LIP6) formerly called MASI Lab Memory Manager Mobile Station Application Execution Environment Media Handler Management Information Base Multimedia Man-Machine Interface Multimedia support for Mobile Wireless Network Mean Opinion Score Motion Picture Experts Group Mobile Station Mobile Terminal Maximum Transfer Unit Network Aspects Nippon Electric Company Network Flow Synchronization protocol Network Interface Card Network Management Forum Network Measurement and Description Group


15 / 229

Del 1.2 Draft v6.03.doc NORTIB NP NTP NTSC ODP OMG OS OSI OSPM P3P PAL PC PCF PCM PCMCIA PDA PDC PDF PDU PE PHB PHY PSNR PSTN PV PWA QCF QCIF QDL QF QML QoS QSDG RC RDF RFC RGB RM RMI ROCH RP RPC RSVP RTCP RTP RTSP SAP SDP SG SI SIP SM SMA SMIL SMM SMS SMTP SNMP SP

Draft / 06.02

29.3.2001

Norsk Tele- og Informasjonsbrukerforening Network Performance Network Time Protocol National Television Standards Committee Open Distributed Processing Object Management Group Operating System Open System Interconnection Occupational Skills Profile Model Platform for Privacy Preferences Phase Alternating Line Personal Computer Policy Control Function Pulse Code Modulation Personal Computer Memory Card International Association Personal Digital Assistant Public Digital Cellular Probability Density Function Protocol Data Unit Protocol Entity Per-Hop Forwarding Behavior Physical Layer Peak Signal to Noise Ratio Public Switched Telephone Network Packet Voice Personal Wireless Assistant QoS Control Function Quarter Common Intermediate Format QoS Description Language QoS Filter QoS Modeling Language Quality of Service Quality of Service Development Group Resource Consumer Resource Description Framework Request for Comments Red Green Blue Resource Manager, Reference Model Remote Method Invocation RObust Header Compression Resource Provider Remote Procedure Call Resource Reservation Protocol Real Time Transport Control Protocol Real Time Transport Protocol Real Time Streaming Protocol Service Access Point Session description protocol. Study Group Service/Socket Interface Session Initiation Protocol Session Manager System Management Agent Synchronized Multimedia Integration Language System Management Manager Short Message Service Simple Mail Transfer Protocol Simple Network Management Protocol Service Performance, Service Provider


16 / 229

Del 1.2 Draft v6.03.doc S-PCF S-QCF SQCIF SQL STQ SU SWAN TCP TDD TINA-C TIPHON TMA TTI TUA TV UAPROF UDP UML UMTS URL UTRAN VBR VC VD VOD VoIP VPN VTS W3C WAMIS WAP WG WML WP WWW xDSL XML XRM

Draft / 06.02

29.3.2001

System Policy Control Function System QoS Control Function Sub QCIF Structured Query Language Speech, Transmission Planning, and Quality of Service Service User Seamless Wireless ATM Network Transport Control Protocol Time Division Duplex Telecom Information Network Architecture Consortium Telecommunications And Internet Protocol Harmonization Over Networks Telecommunications Managers Association Transmission Time Interval Telecommunications Users Association Television User Agent PROFile User Datagram Protocol Unified Modeling Language Universal Mobile Telecommunications System Uniform Resource Locator UMTS Terrestrial Radio Access Network Variable Bit Rate Video Coder Video Decoder Video On Demand Voice over IP Virtual Private Network Virtual Transport Services, Virtual Terminal Service World Wide Web Consortium Wireless Adaptive Multimedia Information System Wireless Application Protocol Working Group Wireless Mark-Up Language Workpackage World Wide Web x (all types of) Digital Subscriber Lines eXtensible Markup Language eXtended integrated Resource Model (XRM)


17 / 229


1.

Draft / 06.02

29.3.2001

Introduction

1.1 Scope This document investigates concepts of Service Adaptation, Scalability, QoS Handling and Management on mobility enabled IP based networks. It develops a QoS management framework (or a QoS architecture) that enables distributed multimedia applications with adaptation mechanisms and QoS provision End-to-End, across heterogeneous networks including wireless access. One part of the overall End-to-End path is the BRAIN access network, but we did not want to restrict ourselves to a specific lower layer network technology. Therefore, a QoS enabled IP network provides the basis of our work in the network domain. Providing QoS guarantees with mobile devices leads to the following mobility specific problems: •

Burst errors and high error rate at the lower network layers. – It is almost impossible to achieve QoS guarantees within a mobile environment, due to the fluctuating radio quality.

•

Connection losses due to natural obstacles (mountains, rapid weather changes, etc.) or due to leaving the borders of the signal range of the base station – If a mobile device is about to move out of coverage and there is no way to provide any connectivity, one cannot provide QoS at the network layer, so one cannot provide End-to-End QoS.

•

Lack of QoS support on horizontal handover – A base station does not support certain QoS or cannot support because of overloading.

•

QoS changes due to movements into another network system – If the mobile device stays in the coverage area of several overlay networks, a hand-off to a different access technology could be forced if the mobile device leaves the area of coverage of one of the networks and enters another one with a different technology supported. As an example, a mobile device is served with an inhouse HiperLan/2 access network. If the user walks outside the building, the terminal has to switch to, e.g. UMTS. In this situation, a QoS violation is possible.

•

QoS changes due to traffic changes between the mobile device and the network – By increasing of the traffic or due to the appearance of a high priority traffic flows the QoS for certain traffic flows can change.

•

The network QoS is not supported by the devices themselves since the mobile devices have less battery, memory, CPU power, etc. in comparison with the fixed terminals.

This deliverable tries to provide solution strategies for the above listed problems. Our work is not concerned with trying to provide hard QoS guarantees. In contrast we are targeting towards soft End-to-End QoS guarantees in order to provide more predictable results than best effort. Distributed multimedia applications such as audio/video conferencing, broadcast quality audio/video presentation demand predictable QoS (not hard QoS guarantees) and access to the end-system and network resources. For


18 / 229


Draft / 06.02

29.3.2001

example, a video-player must be able to execute periodically (e.g. 25 times per second) and must obtain the necessary amount of CPU time, memory and network bandwidth to be able to receive the packets, reassemble them, decode and display the frames without any interruption. Operating system and network resources must be managed and coordinated appropriately in order to provide predictable soft End-to-End QoS up to the user despite the unreliable wireless channel. Finally we want to remark, that this deliverable is specifically focused on QoS-related problems. We did not deeply investigate other requirements we identified in [D.1.1], such as security, billing, accounting, etc., since they are complementary. We did focus rather on the core work in the process of a building an End-to-End QoS architecture that is based on all-IP wireless network provision form the BRAIN point of view (see § 1.3 for more details). In [D.1.1] we also provided a business model for the BRAIN systems. How the future deployment and marketing of BRAIN systems will implement this business model is not a technical matter directly related with the work developed in this Deliverable. So, we maintain a neutral position in this point avoiding references to questions such as: who sign the contract with the final customer, who stores customers profiles and send bills to him, etc., in order to support any alternative the market apply in the future. Specifically we do not go into details about which service provider is going to sign the contract with the final customer, storing user profiles, warranting services quality and generating bills for the customer. 1.2 Goals The main goal of this work is to provide concepts that result in a platform that can be used by different application types in order to provide QoS support, mobility handling and adaptation mechanisms. Mainly, we are interested in an end-point architecture. There are other approaches (for a nice overview see [Aurre98a]) that also include entities inside the network into their architecture in order to provide better support for heterogeneous end-systems. We note, that this is not excluded a priori by our approach, as one goal is to provide an open and extensible platform that may be extended later by add-on functionality such as network centric stream adaptation or downloadable codecs. We provide support for different kind of applications. On one hand it should be possible to bring QoS support into legacy applications without changing their source code. This will be accomplished by an external configurator, which would allow to e.g. enabling certain network level queuing and scheduling mechanisms in order to prioritise e.g. traffic generated by web-browsing applications. In addition, we want support for QoS aware applications that use a QoS and mobility enabled service interface (ESI) to request network QoS for their flows. Next, component based applications (e.g. using CORBA or Java beans) should be provided by a component framework that abstracts from media handling, QoS management and QoS negotiation. Finally, we wanted to provide support for multimedia services for which applications just register and specify a target quality and a degradation path. Our architecture negotiates for resources locally and with the peers and provides the services. Once there is a QoS violation detected, the architecture applies the degradation path and switches to a lower pre-negotiated quality. An important goal for us was to be as independent as possible from any particular technology. As an example, we did not want to restrict ourselves to use a certain protocol (like SIP) for session initiation because this would restrict the scope of the architecture in the future. Instead, we provide components that expose a standardised interface to other components. These components then might use internally SIP or any


19 / 229


Draft / 06.02

29.3.2001

other equivalent protocol to initiate a session. The important thing is that by sharing a common interface, different components can be interchangeably used to fit the bill. This approach also allows us to be vendor independent since only the interface and the semantics determines the required functionality. As an example, one vendor might provide the SIP based component whereas a different vendor may provide a CORBA based component. It should also be possible to plug these components together, making the architecture pluggable. The most important goal we had in mind when designing the architecture was to provide End-to-End QoS support, which is very hard to achieve due to the unpredictable wireless environment. We restricted ourselves to provide soft QoS guarantees and offer the opportunity for a user or an application to specify user preferences and adaptation paths, thus providing well-defined actions that are applied whenever QoS violations are detected. When managing QoS End-to-End, we have to manage local resources (like CPU or memory), the resources provided by the network1 and co-ordinate local, network and remote resources in a well-defined way. This requires a local resource management plane, a QoS negotiation mechanism among peer instances of the architecture and the QoS orchestration mechanism, which co-ordinates the resources in a well-defined way. In addition, we support different QoS policies that define, when and how QoS violations are detected and what reactions are to be carried out (i.e. switch the codec or switch to a lower frame rate). In addition, the architecture should provide support for mobility and wireless access. In fact, this is a very important goal to achieve. We handle mobility and wireless access in several ways. First, the architecture provides support for adaptable services, where the services can adapt (again taking into account the user preferences) to the link quality based on monitoring information. Second, the architecture provides support for power management, which is very important in wireless networks. As an example, one QoS management strategy could be: "if the battery power is low and the link quality is bad, switch to codec X". Finally, mobility is hidden somehow from the network interface via the ESI. However, we can also customise the default operation of the terminal network stack. As an example in a multi-homed terminal, we have the opportunity to select a certain network technology. This is useful, if for example simultaneously UMTS and HIPERLAN is available but the user always wants to use HIPERLAN (if available) because it is free. Finally, our architecture should be easily deployable in order to be acceptable by the community. Since the main parts of the architecture will consist of pluggable components, dynamically updating the system is possible. In addition, some parts of the architecture can be seen as optional add-ons that provide better service guarantees. As an example, if there is no need for local CPU management, the component that manages the resource CPU may be absent (or may do nothing) but the architecture still should work properly. This allows the architecture to be deployed on different devices: from small hand-held devices (where only the most important parts are necessary) to fullblown workstations (where the full architecture can operate). In this sense, the architecture can be seen as scalable, which was another design goal. When designing the BRENTA (see § 3) we were inspired by the MASA QoS architecture [HSKKN01], because the MASA architecture was designed to support mobility and service adaptation mechanisms for multimedia services and applications. 1

Which is managed via the Extended Socket Interface (ESI) and mechanisms dealt in the other BRAIN workpackages WP1 and WP2


20 / 229


Draft / 06.02

29.3.2001

MASA separates media processing from the application, because it is not necessary to reinvent the wheel for all applications. MASA provides a whole set of adaptation mechanisms that are included in a comprehensive QoS framework based on resource brokers and negotiation mechanisms. 1.3 Derived Requirements for BRENTA The BRAIN project aims to deliver Broadband Radio Access over IP Networks by enhancing the HIPERLAN/2 air interface – making it suitable for supporting high performance multimedia services and connection to an IP access network. The BRAIN project will include the design of such an IP access network, so that it will support QoS, mobility management, and authentication functions. An interface will be defined between the BRAIN IP access network and the layer 2 access technology – allowing other access technologies (e.g. Bluetooth) to connect in a standardised way. Finally BRAIN will research how applications can be supported when users may be connected from a range of different access technologies, over connections of different and changing bandwidths and quality. All of these parts constitute the BRAIN system design. BRAIN deliverable 1.1 [D.1.1] addresses the problem of how BRAIN systems will be used, what users will or will not want from such system and how they will integrate with existing technologies (e.g. UMTS). Here we summarise the main requirements identified for the various entities that make up BRAIN. Requirements identified in [D.1.1] are mainly related with mobile IP services used across different fixed and wireless access technologies. Three usage scenarios were carefully chosen to investigate the full range of potential uses of the BRAIN system: leisure time, nomadic worker and medical care (see Appendix A.1). The BRAIN business model identifies the key actors in the delivery of future high performance multimedia services: content service providers, application service providers, proxy service providers, networks service providers, network service providers, network infrastructure providers, network infrastructure providers and terminal suppliers. The use of open interfaces and protocols, both of them based on international standards, are the best way to insure co-operation among all the players involved in the provision of services to the final user. QoS support was one of the mayor issues identified in [D.1.1]. We developed the concept of the cubicle to summarise some of the conclusions from the usage scenarios: the cubicle characterises services in a cube whose axes are mobility, QoS, and user priority. From this business model we concluded that BRAIN will be complementary to 3G systems – providing hot spot, high bandwidth, coverage in public and private places at low cost. From this model and the scenarios we have identified, user requirements such as multiple fixed and mobile access technologies, user profiles, hand-over support, and user priority support. The use of the cubicle concept will allow players of the BRAIN system to identify business opportunities as well as the characterisation of the services and identification of the potential users. The most common way of using BRAIN networks is to use a PWA (Personal Wireless Assistant) connected to the Internet over different media. Although we are mainly interested in the IP aspect of mobility and the wireless link, we should take all the layers into account. The specific security weakness of this kind of portable devices could render IP layer security ineffective. In the context of BRAIN, a PWA can be seen as a virtual device that is instantiated in several ways on the BRAIN end-terminal, depending on its intended usage. Future PWAs will be based on phones, PDAs, PCs, or


21 / 229


Draft / 06.02

29.3.2001

any other Internet-enabled user equipment. Mobile or fixed devices may be configured indistinctly to play the role of a PWA for the user. It is even possible to “create” a PWA from the combined features of several single hardware devices e.g. a laptop combined with a mobile wireless phone can be made to behave like a PWA. The PWA could be equipped with more than just one radio access module and therefore should be able to perform suitable, transparent, vertical and horizontal handovers. Another important element identified in [D.1.1] is VTS (Virtual Transport Service), which represents the association of a user terminal (PWA) with a network service provider. In this context, a network service provider is an organisation that offers network services through one or more access networks, typically including IP basic connectivity and some proxy and application services. Once a terminal establishes an association with a network service provider, conceptually, a new VTS is created and configured with a set of parameters negotiated with the provider that will be used by the applications that run over it. The way virtual transport services are defined makes them independent of networks. That is, a user terminal could have two different VTS' working over the same access network. That is the case of the terminal accessing mall’s private services (VTS1) and the user’s regular network provider (VTS2) through the mall’s HIPERLAN/2 infrastructure. Or, alternatively, the terminal could have different VTS working over different access networks. That is the case when the second VTS of the previous example works over a different access network (GPRS, UMTS). Since BRAIN user terminals should be able to maintain simultaneous associations with different network providers - through the same or different physical networks, network services should be able to: • • •

Setup or disconnect virtual transport services when the user decides to join or abandon an association with a network provider. Auto-configure virtual transport services with basic IP and proxy service parameters obtained from the network service provider. Manage IP mobility inside each virtual transport service.

The PWA provides applications with the needed support to work over different virtual transport service and is also very important for dealing with vertical handovers. Finally we summarise other relevant requirements identified in D.1.1: 1. Personal mobility requirements • •

The need for profiles The need to adapt services to the access link and terminal being used

2. Network requirements • • •

The need to support vertical handover (e.g. HIPERLAN/2 to UMTS) The need for flexible and modular QoS support The need for auto-configuration

3. Billing and accounting requirements •

The need for a single bill

4. Authentication and security required • •

The need for systems to respect confidentiality The need for unified authentication (also known as single sign-in)


22 / 229


Draft / 06.02

29.3.2001

Finally, we concluded in [D.1.1] that a BRAIN system meeting the requirements set forth in [D.1.1] would provide users with the functionality they will require by 2005. This will: facilitate the development of seamless access; help in the specification of an open architecture for broadband internet; create new business opportunities for the key actors and guide contributions to evolving standards. In other words contribute directly to the goals of the BRAIN project. 1.4 The BRAIN End Terminal Architecture (BRENTA) - Introduction Within this section we present a short overview on the QoS framework that we derived for the BRAIN project: the BRAIN End Terminal Architecture (BRENTA). We provide just an overview to introduce the reader to the architecture. In the § 3 we then provide generic concepts that are used in QoS architecture design, while in § 4 we focus on BRENTA details (see Figure 3.1). A user terminal will access services according to a QoS contract with the service provider. Given the need of outfitting applications with adaptation mechanisms in order to cope with QoS contract violations, shifting such mechanisms from the applications to a flexible “middleware” featuring QoS and mobility related functions, greatly simplifies the development of applications for mobile environments. The purpose of BRENTA is to provide such adaptation functionality, through the stepwise induction of a middleware solution. Key requirements for BRENTA are modularity, openness and configurability/flexibility. Modularity guarantees that existing applications can be immediately used as is, whereas more complex middleware solutions can be gracefully introduced later, as soon as they become available. Openness further broadens the scope of BRENTA, making it interoperable with other architectural solutions (e.g. active networks). Furthermore, since BRENTA is mostly designed based on IETF protocols and software components as building blocks, openness and modularity guarantee that future emerging IETF protocols providing more refined support for mobility and QoS may be easily integrated. Flexibility is needed to cope with different media types by, e.g. supporting downloadable codecs. Furthermore, QoS-enabling components featuring standardised interfaces may also be downloaded from a server during runtime in order to enhance the system. In order to address both existing and future applications, BRENTA introduces a classification of applications based on the degree of QoS awareness they feature. Type A applications are legacy ones (email, ftp, web-browsing…), which typically access IP services through classical transport layer interfaces (Application Programmer Interface - API - 0). External configurator tools may eventually be used to boost QoS aspects for such applications. Some of these applications may also use some proprietary QoS-enabled transport interfaces (e.g. Microsoft’s GQoS), or even directly the BRENTA Enhanced Socket Interface (API A – in the following ESI). This interface has been specifically designed to support QoS and mobility aspects, and to abstract BRENTA from specific network implementation details. Type B applications may use various session layer protocols (e.g. H.323, SIP, and RTSP) across the API B. These protocols may even be partly embedded into the applications. Since type B applications directly manage QoS and mobility related issues


23 / 229


Draft / 06.02

29.3.2001

by themselves, they only use standard protocols (e.g. IETF protocols), enhanced by some mobility related functionality. Moving a step further, applications modelled after component-based architectures (CORBA, Java Enterprise Beans, DCOM…) are expected to emerge in the midterm and thus to reduce development time for sophisticated applications and services. To this extent, type C applications will leverage existing implementations of protocol and multimedia functionality (like frame grabbers, codecs, packetizers, renderers…) through the BRENTA API C, which is offered by a set of software components. However, the QoS adaptation logic still resides within the applications. IETF protocols can also be encapsulated in components to provide compatibility and flexibility (e.g. the Session Manager - SM - maps session protocols like SIP, H.323, RTSP, and SAP to an abstract API). The API C also allows dynamic downloading of key components for e.g. updating codecs or protocol objects. Finally, we foresee that future type D applications will totally rely on an external entity, the QoS Broker - by accessing it either as an API C component or transparently via the high-level API D. The QoS Broker manages and co-ordinates local, network, and remote (peer’s) resources, to cope with QoS violations, based on user-QoS profiles or application-supplied policies. These applications will support more predictable services and allow applications to react in a pre-determined way to QoS violations. Whenever these take place, the QoS Broker will provide a controlled and predictable degradation of the QoS, based on a set of high-level QoS parameters and policies for each subscribed service. The QoS Broker maps these parameters to application and network specific QoS parameters. These applications may even be XML-based applications, which interpret XML documents (e.g. SMIL) describing the business logic on a declarative basis. For supporting all such types of applications, we have therefore identified a set of APIs and a variety of components, end-system mechanisms, and protocols coping with the dynamic QoS management. The BRENTA architecture is split into two major planes: the usual data networking plane, and a QoS- and resource-management plane. The latter will provide mechanisms for: local, network, and remote resource management; support for Mobility; QoS orchestration; support for adaptation mechanisms and policies; support for personal user QoS profiles and VTS; Local resources management (like CPU-time, memory, battery power…) is necessary for providing more predictable QoS (otherwise applications would run locally in a best effort mode only). Centralised Resource Controllers (RC - one per resource type) monitor and control the given resources on a system-wide basis, whereas sets of Resource Managers (RM - one per resource type) deal with resource usage on a per flow basis, by interacting with the corresponding RC for low level functionality. Network resource management is necessary to provide a guaranteed amount of network resources (e.g. bandwidth) to mission critical applications. To this extent, application may reserve network resources by using whatever functionality the ESI abstracts. A


24 / 229


Draft / 06.02

29.3.2001

Stack Manager can also be used for optimisation reasons, by accessing link level resource availability information so as to identify when QoS can be upgraded. Remote resource management assures that the peer actually has enough local resources for sustaining the proposed QoS contract. Dedicated End-to-End QoS negotiation protocols are envisaged (through the SM, as extensions of existing protocols). Mobility support will be handled via a combination of macro- and micro-mobility protocols, which are however transparent to BRENTA thanks to the abstraction provided by the ESI. QoS orchestration mechanisms co-ordinate local, remote and network resources in order to provide predictable End-to-End QoS. To this extent, BRENTA introduces at API C level a set of components for co-ordinating multimedia components. The Media Handler (MH) co-ordinates the use of sets of multimedia components, by delegating the management of such components to Chain Coordinator (ChC) components. Each ChC instance combines together and co-ordinates multimedia components on a per flow basis, based on applications requirements, and deals with local resource management (through RM’s). The QoS Broker finally manages QoS adaptation transparently to the applications, by co-ordinating all these components, based on adaptation policies. Support for VTS selection will be provided together with user QoS policies. The framework comprises different levels of more sophisticated adaptation strategies, which in turn is a trade-off between the amount of control and performance in order to know about the status of communication stack. It is thereof necessary to balance the amount of effort put to negotiate time consuming End-to-End resources versus the likely faster changes in local resources. 1.5 Document Structure This deliverable contains two major parts. The first part (covered in § 2) elaborates a generalised QoS framework for distributed multimedia systems providing support for mobility, by taking into account state of the art solutions. First, we introduce the concept of a re-negotiable QoS contract and a simple model of what we understand as QoS. Then we introduce a number of wellknown design principles and QoS mechanisms. Based on these foundations and on requirements deduced from [D.1.1], we then present the BRAIN QoS Framework. The second part of this deliverable (covered in § 3) presents a QoS and Mobility architecture above the transport layer, capable of implementing the aforementioned BRAIN QoS framework. This architecture, known as BRENTA (BRain ENd Terminal Architecture), makes use of the services offered by a BRAIN-enabled transport protocol stack through a so-called Extended Socket Interface (ESI), which is detailed in [D.2.2]. The deliverable then includes a few simple examples (in § 4), which help to show how the mechanisms of the BRAIN QoS Framework implemented within BRENTA, work together. Finally, we conclude this document (in § 5) with an evaluation of BRENTA with respect to the original goals, and a comparison of our work with other well-known architectures. Appendix A provides an overview on derived requirements for BRENTA. We start with use case analysis based on usage scenarios already developed in [D.1.1]. Then we describe application and service aspects and QoS violations. We introduce several performance metrics and provide background information on our measurement


25 / 229


Draft / 06.02

29.3.2001

subsystem used for detecting QoS violations. This appendix concludes with a short discussion of Network and Communication Terminal Aspects, and makes some proposals on a typical BRAIN terminal. Appendix B presents an in depth analysis on traffic models and multimedia streams, which is necessary for deriving QoS parameters for the transport layer used in the ESI. We analyse several scenarios: packetized voice, videoconference, video streams and different MPEG streams. We also include models about data traffic such as world-wide web browsing, e-mail, file transfer or simple on/off sources. Appendix C provides an in depth analysis of MPEG streams in order to derive a concrete traffic model for MPEG streams. We analyse MPEG1, MPEG2 and MPEG4 and recapitulate the traffic model analysis. Appendix D describes different communication terminals with their characteristics. Future trends in mobile terminals are presented in an effort to characterise one or more terminals to be used in the BRAIN network. Issues like resource availability, terminal capabilities, network capacity, and mobility aspects are addressed. Appendix E provides a survey of existing standards, projects and working groups. We focus in particular on the ETSI and on the ITU-T ISO/IEC approach, which we consider a very important architecture. Finally, Appendix F provides insight in the management of multiple streams and how QoS synchronisation could be achieved based on RTP. This leads to the concept of QoS correlation introduced at the end of this appendix. 1.6 References [D.1.1]

IST-1999-100050 BRAIN D.1.1. “Scenarios for mobile IP services and resulting requirements in different wireless networks”, August 2000. [X641R98] ITU-T Recommendation X.641 (12/97) | ISO/IEC 13236:1998, “Information technology Quality of Service: Framework”. [Kassl00] A. Kassler, L. Burness, P. Khengar, E. Kovacs, D. Mandato, J. Manner, G. Neureiter, T. Robles, H. Velayos, “BRENTA - Supporting Mobility and Quality of Service for Adaptable Multimedia Communication”, in Proceeding of the IST Mobile Communications Summit 2000, Galway, Ireland, October 2000, pp. 403 - 408.

[Aurre98a] C. Aurrecoechea, A. T. Campbell, L. Hauw, “A Survey of QoS Architectures”, ACM/Springer Verlag Multimedia Systems Journal, Special Issue on QoS Architecture, Vol. 6 No. 3, pg. 138-151, May 1998.

[HSKKN01] H. Hartenstein, A. Schrader, A. Kassler, M. Krautgaertner, C. Niedermeier, “High Quality Mobile Communication”, in: Proceeding of the KIVS 2001, Hamburg, February 2001.


26 / 229


2.

Draft / 06.02

29.3.2001

QoS Framework for Adaptable Services with Mobility Support

2.1 Distributed Multimedia Systems This section introduces the Quality of Service (QoS) concept and includes an overview of state of the art frameworks dealing with the provision, control, and management of QoS in the most general case of Distributed Multimedia Systems. A framework for evaluating current and future architectures is then proposed, and finally key guidelines for the design of BRENTA are presented. The success of an application largely depends on its man-machine interface. To this extent, all the system and network components should co-operate, so as to meet the ultimate goal of satisfying the users' perceptional requirements. Quality of Service (QoS) in such a context thus describes "the set of those quantitative and qualitative characteristics of a distributed system2, which are necessary in order to achieve the required functionality of an application" [Vogel95]. The introduction of QoS concepts impact business models as well. But with increasing competition to carry long distance traffic, billing for distance will no longer sustain the growth. To this extent, carriers will most likely take into account the inclusion of billing for QoS in the definition of new revenue streams [Castl98]. The various parameters collectively expressing a given set of users' QoS requirements can be grouped in tuples in a multidimensional space, also known as tuple-space. Different points in a tuple space thus describe the behaviour of different applications. Some of these parameters may be mutually dependent or even contradictory3. Given that the user-perceived QoS corresponds more to a region rather than to a single point in the aforementioned tuple space, the actual working point may change over time within the negotiated region. Distributed Multimedia Systems best represent human perception and way of exchanging information. Distributed Multimedia Systems require the transmission of information in various forms (typically as media streams) over a network of interconnected stations. Typically, some stations act as data-sources (by either processing information in real-time, or retrieving it from databases), while others act as data-sinks (i.e. for presentation). Some other stations can act both as data-source and data-sink (e.g. Tele-conferencing). In order to provide over a certain period of time the perception of continuos media streams (also known as flows), a comprehensive mechanism has to be taken into account, including storage, transmission, processing, and presentation functionality, with respect to the computer and network systems used. Particularly, synchronisation requirements are to be identified, so as to address user perception issues concerning the simultaneous presentation of different types of media streams (i.e. lip-sync issues in audio and video applications).

2

To this extent, systems are to be intended as whatever the applications use for communicating with each other, under given QoS constraints. In such a context, the network can thus be seen as a tool, which systems can use not only for delivering information (in the data and control plane), but also for addressing users' perceptional requirements.

3

For instance, bit error rate and delay: an increasing bit error rate could be compensated by introducing forward error correction (FEC), which in turn results in lower bandwidth, or by retransmission, which causes longer delays


27 / 229


Draft / 06.02

29.3.2001

Multimedia applications and services can be classified into presentational and conversational types, each having different requirements. Conversational applications like video-conferencing or CSCW impose real-time capabilities to the system and network, whereas the requirements of presentational applications (like Video on Demand or multimedia e-mail) are not so stringent. 2.2 Concept of a QoS contract A QoS contract is a form of agreement between users of a service and service providers. The QoS contract can be specified on a per flow basis. The resource user requests certain resources for a given flow to be provided and managed by the service provider. If enough resources are available to accommodate the given request, a QoS contract is established between the resource user and the resource provider. The resource provider must guarantee4 to treat the flow in such a way that the requirements are fulfilled. The resource user on the other hand agrees that it is not going to send more traffic over the network than was specified within the QoS contract. If both parties comply with the obligations set forth in the given QoS contract, the QoS contract guarantees that the service provider treats all packets for the given flow in such a way that the QoS requirements of the resource user are met. If the resource user does not operate according to the given QoS contract (e.g. by sending more traffic than she/he originally requested in the QoS contract), the resource provider gives no guarantee at all, i.e. the resource provider may eventually drop packets. It is very important that the contract is not static, and that the contract can be negotiated and monitored dynamically in order to adapt to changes in service user requirements. The negotiated QoS parameters define a contract between the user and the Service Provider. Once this contract has been signed, the system should try to comply with the negotiated values. However, the network's state may change due to statistical multiplexing, varying signal quality, or congestion. 2.3 Concept of Generalised QoS Framework "The intention of QoS architecture research is to define a set of quality of service configurable interfaces that formalise quality of service in the end-system and network, providing a framework for the integration of quality of service control and management mechanisms" [Aurre98]. Based on this well-known definition of a QoS architecture or framework, we can abstract two main points. A QoS framework comprises a set of QoS configurable interfaces and a set of mechanisms that provide QoS control and management functionality according to the QoS specification made via the interface. When applying this definition to distributed multimedia applications, we can see a QoS framework as a collection of control and management units processing the data flow through a computer system. The computer system can be a single machine or a network-connected one. A QoS framework has a QoS configurable interface to the applications whose flows it manages. The QoS management includes mechanisms as media scaling and control of the media sources (see § 2.3.2.2). At the same time it can also take care of the network flow management, such as priority control and filtering of the flows. 4

How tight this guarantee is, depends on the type of service that is part of a set of parameters that comprise the contract


28 / 229


Draft / 06.02

29.3.2001

A QoS Framework could be organised according to different criteria, e.g. the type of the QoS architecture (horizontal or vertical – see Figure 2.1). The structure of the QoS Framework can concern the network level, the application level or the both of them. Frameworks that take in account only the network level mainly address such issues as the flow management and the network resource management, using admission control at the network edges or packet handling mechanisms inside the network. A typical example would be the IntServ architecture (please refer to § 5). Architectures that work on the application level are assuming that the underlying network is QoS-capable. They typically provide adaptation mechanisms at the application level to provide the correct QoS for the media flows and adapt to QoS delivery based on network level treatment.

Figure 2.1: Horizontal and vertical coverage of a QoS Framework

The QoS Frameworks can be also distinguished according to the degree of integration. An integral QoS architecture considers all the components that lay within and interact with a certain flow, i.e. all end-systems, network elements... On the other hand a nonintegral QoS architecture manages only parts of the End-to-End path, e.g. the network only or the end-systems only. By designing a QoS Framework it should be taken in account that the mechanisms that provide QoS can be located in the end network nodes only or along the entire network. If the internal network nodes are QoS enabled, it is possible to accomplish some multiparty communication scenarios in a heterogeneous environment. In such case of heterogeneity it is desirable that some adaptation of the flow takes place inside the internal network nodes due to performance reasons. By designing the QoS mechanisms for a QoS Framework it should be taken in account: •

how to deal with best effort networks;

•

how to use networks that provide differentiated services;

•

how to support multiparty communication between heterogeneous clients;

•

how to support wireless networks; and


29 / 229


•

Draft / 06.02

29.3.2001

how to support seamless handover scenarios for wireless access networks.

Figure 2.2: Hierarchy of QoS strategies

Under differentiated service quality we understand that for a particular category of traffic one or more basic quality metrics (delay, jitter, loss, bandwidth, etc.) are considered. Using configuration mechanisms for the different types of quality issues within the routers and the end-systems we can then introduce these differentiated services. There are several approaches how a QoS strategy (Figure 2.2) could be applied for providing such services. The implementation of a certain QoS strategy can be application-specific and can be a part of the application itself5, or it can be an application-independent management task that is provided by a set of QoS configurable components6, e.g. within a group of QoS management systems there could be some simple resource management units dealing only with the parts of the underlying transmission technology (network, network-subsystem, operating system). Or there could be an integrated QoS management unit - thereinafter, the broker - dealing with all aspects of QoS (QoS policies, QoS negotiations, QoS management, QoS resource handling) on behalf of applications7.

5

Like the BRENTA type A or B applications described later in § 3.1

6

Like the set of components that BRENTA type C applications use, as described later in § 3.1

7

Like in the case of the BRENTA type D applications described later in § 3.1


30 / 229


Draft / 06.02

29.3.2001

Figure 2.3: Generalised integrated QoS framework supporting adaptivity and mobility

As the user will be the instance that decides about success or failure of a system, we see the user requirements and preferences as the most important input for a QoS framework. Figure 2.3 provides our functional top level view on how an integrated End-to-End QoS framework could look like. The user tunes the behaviour of the system by detailing his/her requirements with a given QoS definition GUI that the QoS framework shall export. Alternatively, the application that uses the QoS framework can export its own QoS definition GUI to the user and use the QoS-API that the framework exports to access the services provided by the framework. Our reference architecture, BRENTA (please refer to § 3) provides different complex APIs depending on the type of applications that use the framework. In this figure, we separate the application (this would be a type D application) from the actual media management, QoS management and control, because we see these as special tasks that not every application programmer should re-invent. Instead, we see the QoS-framework providing a toolbox that application programmers can use to implement QoS aware, adaptive applications rather easily. Therefore, the framework encapsulates media handling (like media capturing, compressing...), protocol handling (like RTP protocol processing) and network mechanisms (like send/receive operations or invoking transport and network level QoS mechanisms), which is provided by a set of components in an object oriented way, making it very easy to support openness, flexibility and extensibility. In addition, some applications (type C might want to directly access components). Users QoS requirements are thus translated in a QoS specification that the framework is able to understand and negotiate with its peer entities in the distributed scenario. QoS management and control entities are necessary to enforce the QoS locally (e.g. by resource management). QoS Monitoring is used for fine-tuning and detecting situations, where the QoS cannot be maintained (for example, if the mobile terminal performs a hand-over and the network resources are not longer there). QoS negotiation is necessary to negotiate QoS among the peers and to come to a common agreement on the amount of resources that the local system is requesting from the peer implicitly. By implicitly we mean that if peer A sends a stream to peer B, peer A has to implicitly request that amount of resources from peer B that enables peer B to handle the stream. If peer A sends 20 fps video, peer B has to reserve the resources for handling the decompression and display of the frames. Adaptability is build into the end-system in a sense that all


31 / 229


Draft / 06.02

29.3.2001

components can adapt to changing resource availability if instructed by management entities, that co-ordinates them. Finally, the BRAIN access networks together with the IP core network provides the network resources that are necessary for data delivery. This kind of QoS framework provides for example the following advantages: •

application programmers program to a set of interfaces and not to implementations that might change over time

•

the framework implements the adaptation mechanisms so it is not for an application programmer necessary to re-invent the wheal again and again. Application programmers simply provide a policy that determines how the adaptation is carried out (i.e. the adaptation path)

•

the framework is platform independent and can be implemented on any platform adding the functionality that is necessary to fulfil the QoS API.

•

separating the applications from the media management allows to change the media management transparently, e.g. if new codecs are available without changing the application code.

•

intelligent optimisation rules regarding network load, network types, charging, ... can be plugged in and updated transparently to the applications

•

device independence is achieved by the applications from the media management

•

network layer QoS provisioning can be changed without changing the application code, i.e. applications need not be programmed to RSVP daemons.

•

configurable hand-over decisions allow the implementation of intelligent hand-over decisions (e.g. now switch to WaveLAN because its for free)

•

User QoS profiles can configure media streaming services. The user just selects a given profile and tailors the service to its own will. This allows building a hierarchy of QoS parameters from abstract quality definitions (e.g. TIPHON classes) to a very special QoS definition.

•

Pluggable components are used that provide open interfaces. This allows for dynamic downloading of new functionality or capabilities without changing the application code.

2.3.1

General QoS Principles

The following principles govern the construction of a generalised QoS framework. •

Integration principle "Integration principle states that QoS must be configurable, predictable and maintainable over all architectural layers to meet End-to-End QoS. Flows traverse resource modules (e.g., CPU, memory, multimedia devices, network, etc.) at each layer from source media devices, down through the source protocol stack, across the network, up through the receiver protocol stack to the playout devices. Each resource module traversed must provide QoS configurability (based on a QoS specification), resource guarantees (provided by QoS control mechanisms) and maintenance of ongoing flows" [Aurre98].

•

Separation principle "Separation principle states that media transfer, control and management are functionally distinct architectural activities. The principle states that these tasks


32 / 229


Draft / 06.02

29.3.2001

should be separated in architectural QoS frameworks. One aspect of this separation is the distinction between signalling and media-transfer. Flows (which are isochronous in nature) generally require a wide variety of high bandwidth, low latency, non-assured services with some form of jitter correction. On the other hand, signalling (which is full duplex and asynchronous in nature) generally requires low bandwidth, assured-type services" [Aurre98]. •

Transparency principle "Transparency principle states that applications should be shielded from the complexity of underlying QoS specification and QoS management. An important aspect of transparency is the QoS-based API at which desired QoS levels are stated […]. The benefits of transparency are that it reduces the need to embed functionality in the application, hides the detail of underlying service specification from the application and it delegates the complexity of handling QoS management activities to the underlying framework" [Aurre98].

•

Multiple timescales principle "Multiple timescales principle guides the division of functionality between architectural modules and pertains to the modelling of control and management mechanisms. It is necessitated by, and is a direct reflection of, fundamental time constraints that operate in parallel between resource management activities (e.g., scheduling, flow control, routing, QoS management, etc.) in distributed communications environments" [Aurre98]. As an example, a CPU scheduler has to be implemented very efficiently because it performs simple operations (deciding which thread to schedule next) very frequently. In contrast, the admission control functionality for the resource CPU is more time consuming and has to be performed whenever a new thread needs resources (e.g. typically each 10 seconds or so). So it operates on a different timescale and it is thus managed by a different functional entity, the CPU controller.

•

Performance principle "Performance principle subsumes a number of widely agreed rules for the implementation of QoS-driven communications systems which guide the division of functionality in structuring communication protocols for high performance in accordance with systems design principles, avoidance of multiplexing, recommendations for structuring communications protocols, and the use of hardware assists for efficient protocol processing" [Aurre98].

•

Simplicity Principle A QoS-Architecture should be built as simple as possible and as complex as necessary. This very general engineering principle seems to be obvious. A detailed look at different QoS approaches presented in the literature will reveal however that this rule has not always been taken into account. This is especially true for the definition of an architecture whose components are widespread in a very heterogeneous environment of end-systems and network entities. Being simple is a very important issue for the acceptance and deployment of such an approach.

•

Scalability A general and comprehensive QoS architecture should be able to support different kinds of end-systems as well as underlying network technologies. In order to achieve a seamless transition from legacy, best effort end-systems to an end-system


33 / 229


Draft / 06.02

29.3.2001

that provides full support for QoS, it should not be necessary to integrate all QoS components (e.g. transcoding units, filters, etc.) within end systems and all network nodes, if there is no demand for the full functionality or if the underlying network doesn't support every possible QoS mechanism. Therefore, all interfaces and as many of the architectural components as possible should be as generic as possible. The architecture should work, even if not all components that constitute the architecture are present. Of course, the functionality may be limited if some components are missing but nevertheless the resulting architecture should offer more guarantees than best effort architectures. 2.3.2

QoS Mechanisms

Realise the desired application End-to-End QoS behaviour. 2.3.2.1 QoS Provision Mechanisms

This is static form of resource management, dealing with flow establishment and Endto-End re-negotiation phases. QoS provision is comprised of the following components: •

QoS mapping "performs the function of automatic translation between representations of QoS at different system levels (i.e., operating system, transport layer, network, etc.) and thus relieves the user of the necessity of thinking in terms of lower level specification. For example, the transport level QoS specification may express flow requirements in terms of level of service, average and peak bandwidth, jitter, loss and delay constraints. For admission testing and resource allocation purposes this representation must be translated to something more meaningful to the end-system" [Aurre98].

•

Admission testing "is responsible for comparing the resource requirement arising from the requested QoS against the available resources in the system. The decision whether a new request can be accommodated generally depends on system-wide resource management policies and resource availability. Once admission testing has been successfully completed on a particular resource module, local resources are reserved immediately and then committed later if the End-to-End admission control test (i.e., accumulation of hop by hop tests) is successful" [Aurre98].

•

Resource reservation protocols "arrange for the allocation of suitable end-system and network resources according to the user QoS specification. In doing so, the resource reservation protocol interacts with QoS-based routing to establish a path through the network in the first instance; then, based on QoS mapping and admission control at each local resource module traversed (e.g. CPU, memory, I/O devices, switches, routers, etc.) End-to-End resources are allocated. The end result is that QoS control mechanisms such as network-level cell/packet schedulers and end-system thread schedulers are configured accordingly" [Aurre98].

2.3.2.2 QoS Control Mechanisms

Based on the levels of QoS requested during the QoS Provision phase, these mechanisms (operating at speed comparable to media transfer speed) provide real-time traffic control of flows. •

Flow shaping


34 / 229


Draft / 06.02

29.3.2001

"regulates flows based on user supplied flow performance specifications. Flow shaping can be based on a fixed rate throughput (i.e., peak rate) or some form of statistical representation (i.e., sustainable rate and burstiness) of the required bandwidth. The benefit of shaping traffic is that it allows QoS frameworks to commit sufficient end-to-end resources and to configure flow schedulers to regulate traffic through the end-systems and network. It has been mathematically proven that the combination of traffic shaping at the edge of the network and scheduling in the network can provide hard performance guarantees" [Aurre98]. •

Flow scheduling "manages the forwarding of flows (chunks of media based on application layer framing) in the end-system and network (packets and/or cells) in an integrated manner. Flows are generally scheduled independently in the end-systems but may be aggregated and scheduled in unison in the network. This is dependent of the level of service and the scheduling discipline adopted" [Aurre98].

•

Flow policing "the dual of monitoring: the latter usually associated with QoS management observes whether QoS contracted by a provider is being maintained whereas the former observes whether the QoS contracted by a user is being adhered to. Policing is often only appropriate where administrative and charging boundaries are being crossed, for example, at a user-to-network interface. Flow shaping schemes at the source allow the policing mechanism to detect misbehaving flows" [Castl98].

•

Flow control "includes both open-loop and closed loop schemes. Open loop flow control is used widely in telephony and allows the sender to inject data into the network at the agreed levels given that resources have been allocated in advance. Closed loop flow control requires the sender to adjust its rate based on feedback from the receiver or network. Applications using closed loop flow control based protocols must be able to adapt to fluctuations in the available resources. On the other hand, applications which cannot adjust to changes in the delivered QoS are more suited to open loop schemes where bandwidth, delay and loss can be deterministically guaranteed for the duration of the session" [Aurre98].

•

Flow synchronisation "required to control the event ordering and precise timings of multimedia interactions. Lip-sync is the most commonly cited form of multimedia synchronisation (i.e., synchronisation of video and audio flows at a playout device). Other synchronisation scenarios reported include: event synchronisation with and without user interaction, continuous synchronisation other than lip-sync, continuous synchronisation for disparate sources and sinks. All place fundamental QoS requirements on flow synchronisation protocols" [Aurre98].

2.3.2.3 QoS Management Mechanisms

In order to ensure that the contracted QoS is actually sustained, it may not be sufficient to simply commit resources. To this extent the following QoS management mechanisms have been identified. Functionally similar to QoS Control, the QoS Management of flows though allows users to finely tune the overall system performance, at multiple timescales.


35 / 229


•

Draft / 06.02

29.3.2001

QoS Monitoring "allows each level of the system to track the ongoing QoS levels achieved by the lower layer. QoS monitoring often plays an integral part in a QoS maintenance feedback loop, which maintains the QoS, achieved by resource modules. Monitoring algorithms operate over different timescales. For example, they can run as part of a scheduler (as a QoS control mechanism) to measure individual performance of ongoing flows. In this case measured statistics can be used to control packet scheduling and admission control. Alternatively, QoS monitoring can operate on an end-to-end basis as part of a transport level feedback mechanism or as part of the application itself" [Aurre98].

•

QoS Maintenance "compares the monitored QoS against the expected performance and then exerts tuning operations (i.e., fine or coarse grain resource adjustments) on resource modules to sustain the delivered QoS. Fine grain resource adjustment counters QoS degradation by adjusting local resource modules (e.g., loss via the buffer management, throughput via the flow regulation, and queuing delays and continuous media playout calculation via the flow scheduling)" [Aurre98].

•

QoS Adaptation If, after re-negotiation, the QoS still cannot be achieved, applications should adapt to cope with the changes in the QoS of the system. This mostly involves user interaction or some pre-configured user preferences. Some examples of application adaptations to switch to lower frame rate, reduce the frame size, etc., i.e. to apply QoS or media scaling mechanisms. As an example, see [Fry97], [Delgr94], and [Li98]. Adaptation is a dynamic management function.

•

QoS Negotiation The process of reaching an agreement regarding QoS specification between all involved functional entities. Typically, entity A requests some QoS using a QoS specification from entity B. Entity B performs admission control. If this fails, entity A modifies the QoS specification and the cycle starts again, until agreement is reached, which then results in resource reservation. The modification of the QoS specification by entity A should be conforming to the user preferences. This may involve QoS mapping. For more examples, see [Fry97], [Koist98]. QoS negotiation is a static management function.

•

QoS Scalability "comprises QoS filtering (which manipulates flows as they progress through the communications system) and QoS adaptation (which scales flows at the end-systems only) mechanisms. Many continuous media applications exhibit robustness in adapting to fluctuations in end-to-end QoS. Based on the user supplied QoS management policy, QoS adaptation in the end-systems can take remedial actions to scale flows appropriately. Resolving heterogeneous QoS issues is a particularly acute problem in the case of multicast flows. Here individual receivers may have differing QoS capabilities to consume audio-visual flows; QoS filtering helps to bridge this heterogeneity gap while simultaneously meeting individual receivers' QoS requirements" [Aurre98].


36 / 229


Draft / 06.02

29.3.2001

2.4 BRAIN QoS Framework 2.4.1

Overview

Starting from the requirements set forth in [D.1.1] and further analysed in Appendix A, the given problem domain can be modelled as follows (see Figure 2.4). The key actors are the Services, the Resources associated with such services, and the Service Users. Services can be classified into Elemental Services and Service Packages. The former being associated with a given resource, whereas the latter are simply aggregations of Elemental Services. This aggregation relationship is however recursive, in the sense that Service Packages can aggregate other Service Packages, thus leading to a hierarchy of Services. This hierarchical model is quite general, since its applicability can span from Services offered (e.g. through the Internet) to low-level functionality located on a given terminal device (e.g. a hard disk driver) The relationship between Elemental Services and Resources is mediated by two ad-hoc entities: a Resource Manager, and a Resource Controller. The former is a specialisation of Elemental Services, and it can be dedicated to the processing of information related with a given telecommunication session. The Resource Controller is a centralised entity, which directly manages the associated Resource on behalf of one or more instances of the Resource Manager (for more detail about Resource Manager / Controller, please refer to § 2.4.4). Service Users can access Service Packages either directly (within the context of a given background software process), or by invoking a specific Application. Applications are simply a specialisation of the Service Package concept, and more specifically can be simply described as the physical standalone realisation of a Service Package. Applications can be further classified into Standalone Applications and Communication Applications. The formers are applications like word processors, which generally do not require any form of communication with programs located on remote terminal devices. These applications are taken into account in the QoS Adaptation Framework, since they consume resources on the local terminal device, to the detriment of other Applications, including Communication Applications.


37 / 229


Draft / 06.02

29.3.2001

Figure 2.4: UML Analysis Class Diagram: Application Taxonomy

Communication Applications are all those Applications whose business logic includes the use of communications with other similar Applications installed on remote terminal devices. Communication Applications can be further classified into four types: •

Application Type A: this type of application typically runs over standard TCP/IP (+UDP) stacks and does not address any QoS issues.

•

Application Type B: this type of application directly manages QoS and mobility related functionality, without any external support. These applications can use various session layer protocols (e.g. SIP, H.323), and deal with QoS issues via IntServ and/or DS. Additionally, these applications will typically include RTP/RTCP/RTSP functionality. These applications are likely to be specialised applications, written by skilled application programmers, who know how to directly deal with issues like e.g. QoS violations. An example of such applications would be commercial off-the-shelf and/or upcoming QoS-enhanced Voice over IP client applications.

•

Application Type C: this type of application is able to adapt to QoS violations by itself but can rely on basic lower level functionality offered by software components8. Therefore, the development of this type of application can be eased considerably, thanks to the extensive reuse of existing software. This is a category of applications not yet commercially available. Upcoming products will be based on existing component-based platforms, e.g. Microsoft's DCOM, OMG's CORBA, or Sun's Enterprise Java Beans.

8

Examples of components are video grabbers, data compressors, packetizers, etc.


38 / 229


•

Draft / 06.02

29.3.2001

Application Type D: this type of application is typically not designed to deal directly with QoS violation issues, though it is QoS-aware. Therefore these applications need some form of intelligence, provided by external software components that hide QoS and mobility handling issues from them. Furthermore, application programmers can even use high level QoS-languages for the provision of QoS. This paradigm significantly eases the programming of distributed multimedia applications, e.g. multimedia information kiosks that subscribe to an adaptable, QoS aware video streaming service.

This type of classification indirectly applies to Service Packages as well, since these are de facto implemented within the context of specific Applications running as background software processes. Finally, the Service User can access Services (as aforementioned) either through Service Packages or through Applications, by using (specific and personal) service configuration information. This information can be modelled as a set of Profiles: •

User Profile: collects information uniquely identifying the Service User (e.g. login/passwords, digital certificates), and it may also contain some general preferences (e.g. language).

•

Service Package Profile: collects information used for configuring a given Service Package the way the Service User prefers.

•

Application Profile: collects information used for configuring a given Application the way the Service User prefers.

2.4.2

QoS Adaptation Framework

Starting from the model presented in the previous paragraph, the rest of this section focuses on the mechanisms that can be employed for achieving automatic and (to the greatest possible extent) QoS and mobility adaptability. These mechanisms are presented in the context of a framework, which is derived from the goals and guidelines set forth in § 2. Figure 2.5 presents the model upon which the framework is based. The most elemental QoS mechanism that can be used for enforcing QoS awareness is QoS provisioning (see § 2.3.2.1). This capability is offered by applications Type B, C, and D, by their very definition. Concerning Application Type A, since almost all legacy applications do not feature any QoS support, an external configuration tool can be used for providing QoS transparently to these applications. This configurator should allow users or administrators to configure/setup and monitor QoS parameters that can be associated with application streams. By such mechanisms, standard legacy applications (like Web-Browser or ftp downloader) could be enhanced to provide more predictable services without changing the application code. Such a tool might be accessed through a set of GUIs (each addressing a given level of user expertise). If no QoS is provisioned, the given legacy application will still be able to operate as usual, but without QoS support. QoS Adaptation mechanisms logically extend the QoS Provision functionality by adding capabilities for reacting to violations of the negotiated QoS contract. These mechanisms can be further classified into Application-Wide and System-Wide. The formers are scoped within the context of a single instance of a given application. The latter deal with all the resources available within the given terminal device, with the


39 / 229


Draft / 06.02

29.3.2001

network resources, and with the resource usage at the peer end-system: this is the case of Applications Type D.

Figure 2.5: UML Analysis Class Diagram: QoS Adaptation Logic

Application-Wide QoS Adaptation mechanisms can be further classified into Local Resource Unaware and Local Resource Aware ones. The formers are either totally unable or only partially able to assess the status of (and consequently use) resources on the given terminal device: this is the case of Applications Type B. The latter are able to assess the status of (and consequently use) all the resources the given application needs on the given terminal device: this is the case of Applications Type C. System-Wide QoS Adaptation mechanisms can exercise some level of control on applications using the Application-Wide QoS Adaptation mechanisms, by using specific Control Information as a handle to identify the controlled entity. This type of control is envisaged to be quite dangerous (pause, resume, kill process), since malicious developers can create applications implementing Application-Wide QoS Adaptation mechanisms, which simply ignore any control from external entities. 2.4.3

Levels of Quality of Service

When applied to distributed-multimedia systems, QoS describes the set of qualitative and quantitative characteristics of the whole system which are necessary to achieve the required functionality. It can be seen clearly, that for different types of multimedia services (e.g. presentational or conversational) different characteristics exist imposing different constraints on the whole systems. For example, the delay requirements for a real- time videoconference are more stringent than for VoD. Generally, the success of a


40 / 229


Draft / 06.02

29.3.2001

system depends on its acceptance to the user, which is influenced mainly of the presentation of multimedia data to the user. We express QoS in terms of different parameters (and values) like e.g. (delay = 100 ms, bandwidth = 100 Kb/s), together forming a tuple in a multidimensional space. The behaviour of different applications or components can be described by different parameters and some of these parameters may be mutually dependent (like transmission charges and bandwidth). QoS parameters are always subject to negotiation between system components or layers. There are different possibilities to group QoS parameters. One would be to distinguish between:

performance-oriented (like End-to-End delay, bit-rate);

format-oriented (like temporal, spatial resolution of a video stream, compression scheme);

synchronisation-oriented (like skew between audio and video, between tele-pointer and audio);

cost-oriented (like data transmission charges); and

user-oriented (like subjective image or audio quality).

2.4.3.1 A simple QoS Model

In this section we derive a simple QoS model based on layers in distributed multimedia applications. QoS parameters are usually subject to negotiation9 between system components and/or layers both in the local system and among peers. We can identify three main processing steps within a distributed multimedia application for determining QoS at different layers. 1) At the beginning of a negotiation cycle (locally or among peers), the user specifies wishes in terms of user-perceived QoS. These parameters describe a user's satisfaction with the application performance, with respect to factors such as cost, synchronisation, and quality of presentation. As an example, the user may choose a high-quality video stream. In addition, the expert user might detail the requirements in the form of a high level description for example for media related properties (like the frame rate is high or the frame quality is TV like). 2) The user-perceived QoS parameters can be mapped down through the different system components or layers (hardware, network, OS-capabilities, capabilities of multimedia devices, codec availability...). For example the high-quality video stream can be mapped onto actual values for frame-size (depending on the characteristics of the frame-grabber and the power of the machine), frame-rate (depending on the CPU utilisation, frame-grabber...) and so on. In the above example, a high frame rate could be translated in an interval of 20...30 fps, whereas a large frame size could be translated in a width between 400 and 600 pixels and a height between 600 and 800 pixels. Depending on the codec used the bandwidth demand is calculated. Note that at this stage, parameter values are 9

The complexity of negotiation mechanisms may induce to skip or otherwise address such an issue. Nevertheless, the very same charter of the BRAIN project constraints designers to take negotiation issues into account. Expensive high bandwidth would be in fact wasted if no provisions of enough resources (at application, system, and network level) were made beforehand. Given the many components involved in the given scenarios, proper negotiation of the resources they need is thus necessary. To this extent, explicit signalling mechanisms need to be properly identified [see § 2.6].


41 / 229


Draft / 06.02

29.3.2001

derived from high level specifications, which might be based on a mapping policy and preferences of the user (see § 2.4.6). The system is now able to deal with the concrete values for, e.g. negotiating with other components. 3) Negotiation between different system components and layers may be undertaken in order to guarantee that all layers and/or components can satisfy the negotiated parameters. The application can start executing only if an agreement can be achieved. Otherwise, the user has to be informed. It would be better to offer users only those ranges of parameters the system is able to guarantee. However, it is not trivial task to do this in advance. It is also possible to offer different types of agreements (like best effort or guaranteed10) or to assign probabilities to the agreements (e.g. up to 80% the bandwidth can be guaranteed). Negotiation might involve re-negotiation, if some parts can not cope with the original specification. For re-negotiation, lower QoS parameters might be used derived from an Adaptation Path (see §§ 2.4.5 and 2.4.7). However, these tasks can be complicated by further factors. For instance, during a communication session, both the characteristics of the streams and the users' requirements may change. This requires QoS re-negotiations, which can also happen if the network's state changes due to congestion or due to handover of a mobile terminal to a new access-point, which cannot guarantee the old QoS. An example of such a changing situation is a medical consulting session, where the user requests a low quality connection for teleconferencing resulting in low bandwidth and high packet loss probability. However, these tasks can be complicated by further factors. For instance, during a communication session, both the characteristics of the streams and the users' requirements may change. This requires QoS re-negotiations, which by the way can also happen if the network's state changes due to congestion or due to handover of a mobile terminal to a new access-point, which cannot guarantee the old QoS. As an example for such a changing situation can be considered a medical consulting session, where the user requested a low quality connection for teleconferencing resulting in low bandwidth and high packet loss probability. If an Ultrasound Video (Heart Pumping, Foetus Motions, etc.) has to be shared it is necessary for a proper diagnosis, that both participants see the same Ultrasound Video without errors and smoothly. So the packet loss probability should be much lower and the required bandwidth increases dramatically (Ultrasound Video requires several megabytes per seconds. In order to have a fast transmission, the bandwidth should increase from e.g. 64 Kb/s for the teleconference to several Mb/s during jointly viewing the Ultrasound Video). A communication session is described by many different parameters. Several parameters may be mutually dependent or even contradictory like bit-error-rate and delay. Since the user's wishes in terms of user perceived QoS correspond rather to a region in the parameter space than to a single point, the actual working point may change over time remaining still in the region (see § 2.4.7), specified by the user as User QoS parameter. The negotiated QoS parameters define a contract between the user and the system. Once signed by the system, it should try to comply with the negotiated values. However, the network state may change especially within wireless networks due to varying channel conditions and a changing system load may lead to congestion. From operating system point of view, a starting real-time process or several low priority processes 10

Guaranteed QoS levels are actually per se probabilistic, the name simply identifying the type of user's specification.


42 / 229


Draft / 06.02

29.3.2001

simultaneously may block the process for which the user has negotiated QoS parameters and the operating system may no longer guarantee the old values. So, continuously monitoring (see § A.3 in Appendix A) the network and system may lead to correction mechanisms and precautions can be taken in order to avoid re-negotiations (like blocking of low priority tasks, lowering the bandwidth in advance by increasing quantization for video-conferencing...).

Layer2Layer QoS Control

Peer2Peer QoS Management User QoS (simple !)

User

Application level System level (OS + CS)

Application QoS

System & T QoS

Network level

Multimedia devices level

Network QoS

Device QoS

Figure 2.6: Layers in distributed Multimedia applications

Figure 2.6 depicts important layers involved in overall media processing for distributed multimedia applications. At the uppermost level, users specify their preferences and quality trade-offs (see § 2.4.8) for the given sessions11. These requirements have to be mapped to application specific parameters, which then influence system level entities (operating system scheduler, transport subsystem buffers...). As framework level QoS parameters we denote those parameters that are used for tuning the components that we derive later (see § 3), both internally (inside the components) and externally visible (in the component interface). These QoS parameters have then to be mapped to system level QoS parameters representing the operating system (OS) or communicating subsystem (CS) level QoS parameters. Note, that internally, transport level QoS parameters may also be used (As an example, the CS level parameters could be the parameters specified in the extended socket interface - see § 3.2). Finally, these parameters have to be mapped to the devices level QoS parameters (as an example, 20 fps for the framegrabber) or to the network level QoS parameters (as an example, to parameters used for the BRAIN QoS service provider derived in [D.2.2]). On the lowest level, the multimedia devices and network parameters used for setting up the connection have to be derived. On each layer, monitoring entities (see § 3.4.5) should track the conformance of each component against the desired QoS. If some component can no longer maintain the negotiated QoS, all the other components have to be notified and the system as a whole should react accordingly. This can be implemented by a central 11

Of course, default configuration has to be available and applied whenever the users are not willing to specify settings. This feature can be achieved by using customisable profiles, each addressing specific users, situations, applications, and/or business models.


43 / 229


Draft / 06.02

29.3.2001

component that has knowledge about the overall system’s state. Such state deals with resources, users’ preferences (denoted by policies and profiles), and the remote peers’ capabilities and resource situation, as well as the resources available in the network (see § 3.5.3), thus orchestrating QoS both locally, at the peer and inside the network. Since the user is the most important part in the system we take the users view on QoS as a basis. The user has typical requirements to applications and a suitable interface should be provided in order to let him specify her/his preferences. Preferences determine the users’ wishes and how the system should re-act in case the once maintained QoS can no longer be maintained. As an example the user would like to have a high quality videoconference (whatever high quality means) and if this cannot be maintained, he would like to preserve frame-rate over frame-quality. This policy would be applicable to an action movie where it is important to have a smooth motion vision. In contrast, a different policy could be that the user would like to have a high-quality video session and he would like to preserve frame-quality over frame-rate. This example would be applicable for news like applications, where the speaker does not move too much (see § 2.4.8). 2.4.4

Resource Provider / Consumer Design Pattern

Design pattern describes proven solutions for common problems in object-oriented analysis and design. With design patterns, one may reuse successful and tested solutions instead of solving each problem from scratch. This section presents a design pattern, for providing resource management functionality. As multimedia streams consume different types of resources as they flow from source to sink, resources have to be managed somehow in order to provide QoS guarantees. The resource management system is split in two parts for each resource type (i.e. memory, CPU, network…) Resource Consumers (RC) and Resource Providers (RP). As part of the overall End-to-End QoS framework mechanisms a set of co-operative components manage local resources. In general, resource negotiation and resource usage is a steady process. First, a RC requests some resources from a RP (see (1.) in Figure 2.7). The RP first checks, if enough resources are available in order to fulfil requests by performing an admission test (2.). If the request can be granted, the resource scheduler (if necessary) is informed and controlled resource usage is established. During the usage of the resource, the RP provides usage and QoS measurement information for the RC (3.). For example, the RC may request from a RP notification in case more resources become available (if, for example, other RCs released some resources). $GDSWDWLRQ 5HTXHVWV

5HVRXUFH &RQVXPHU

5HTXHVW 4R6 5H1HJRWLDWH

5HVRXUFH 3URYLGHU

$GPLW 4R6

HJ&38

8VDJHDQG 4R6 0HDVXUHPHQW

Figure 2.7: Resource consumption cycle Renegotiating may become necessary during the lifetime of the resource consumption cycle, if the resource consumer detects that it needs more (4.) resources or less (5.)


44 / 229


Draft / 06.02

29.3.2001

resources than requested during step 1. If the current level of resource consumption can no longer be maintained by the RP, the RP may request adaptation (6.) from the RC in order to change its resource consumption behaviour. Also, the RP may specify whether the RC should increase or decrease the resource consumption. By such generic mechanism, we may include adaptation functionality in the resource consumption cycle. We distinguish between Re-Negotiation and Adaptation. Adaptation is always triggered by the resource provider. This might happen in two cases: upgrade and downgrade. o Overload situation (downgrade): the current QoS cannot be maintained for all or dedicated resource consumers. The resource provider notifies the consumers using adaptation request (6.). As an example, a user might move in the region of a new base station that offers less bandwidth. So the network level QoS contract may be violated after hand-off. In that case the resource provider for the network resource would adapt the resource consumer (all or only dedicated ones) for that resource. o More resources become available (upgrade): this situation might happen, if a resource consumer requested a certain QoS but, due to fewer resources available, is granted a lower QoS. The resource consumer then might request to be notified whenever more QoS will become available. Re-negotiation is always triggered by the resource consumer. This might happen in two cases: upgrade and downgrade. o More resources (upgrade): the current QoS provided by the resource provider is not enough to satisfy the resource consumer. In that case the resource consumer would re-negotiate with the resource provider to upgrade its QoS contract. As an example, the user requested to send the video no longer with 10 fps, but instead with 20 fps. o Fewer resources (downgrade): the current QoS provided by the resource provider is not necessary to fulfil the resource consumer’s requirements. In that case the resource consumer would re-negotiate with the resource provider to downgrade its QoS contract. As an example, the user requested to send the video no longer with 20 fps, but instead with 10 fps. In the next sections we analyse RPs and RCs in more detail. 2.4.4.1 Resource Providers

Resource Providers are necessary for the service provisioning part of the resource. Remember that the framework should be able to manage several resources in parallel. However, a Resource Provider is only responsible for a single resource type. The tasks for Resource Providers are to

provide admission control functionality

provide means for reserving resources

schedule already reserved resources in a controlled way

measure resource usage and QoS delivery

allow dynamic re-negotiation when necessary

allow global and local adaptation.


45 / 229


Draft / 06.02

29.3.2001

We distinguish between global and local adaptation. Remember that a Resource Provider may serve several Resource Consumers simultaneously. There might be situations, where the resource availability that the resource controller manages, is changed. As an example, a hand-over to a new access point may result in less bandwidth available. It is then up to the resource controller for the network resources to re-distribute resources accordingly. This is what we call global adaptation, because it involves all (or a subset) of resource consumers. In contrast local adaptation describes the mechanism were a RP forces one dedicated RC to adapt to a lower or higher level of resource availability (for example, if a video connection has exceeded its bandwidth share over an averaging interval, the RP for the resource network is likely to notify this connection to reduce network usage). By global adaptation we describe the fact that all RCs may be forced to perform adaptation to resource availability (for example, if a mobile connects to a new access point and where less bandwidth is available and the policy is to share bandwidth among all connections in a fair way). In contrast local adaptation describes the mechanism were a RP forces one dedicated RC to adapt to a lower or higher level of resource availability (for example, if a video connection has exceeded its bandwidth share over an averaging interval, the RP for the resource network is likely to notify this connection to reduce network usage). We separate clearly between policies and mechanisms for each of the functions in order to allow for extensibility and provide a flexible framework. Therefore, we can test different user supplied policies and preferences without modifying the general mechanisms. Depending on the type of resource, RPs may be split further into two components:

resource controllers and

resource schedulers.

The split of functionality is motivated by the different timescale design principle. Schedulers typically have to perform very short tasks at a high priority (e.g. determining which packet to forward or determining which thread has to be executed next) whereas resource controllers typically perform lower priority tasks that may last longer (i.e. providing admission control functionality). In addition, resource schedulers are only necessary if access to a resource depends on time constraints. For example, the resources CPU and network need resource schedulers to provide tight QoS guarantees for the specific resource whereas the resource memory does not need a memory scheduler a priori. The resource controller is tightly coupled with resource schedulers. Resource schedulers are typically provided by the operating system for CPU (or by the protocol stack for the networks). In this paper, we focus only on resource controllers. The tasks for the resource controllers are to

provide admission control services for the resource

provide mechanisms to reserve/release resources

provide means for dynamic (global and local) adaptation and

provide mechanisms to perform dynamic QoS (re-) negotiation.

On the other hand, resource schedulers implement policies how a resource is shared among multiple competing resource consumers. Because only resource schedulers have


46 / 229


Draft / 06.02

29.3.2001

information of resource usage they also provide feedback information for resource consumers on resource usage and QoS delivery. The tasks for the resource schedulers are to

schedule already reserved resources in a controlled way

measure resource usage and QoS delivery

The resource controllers cover all other tasks for the RPs. Scheduling resources and measuring QoS delivery and resource usage are tasks that have to be performed very often with minimal overhead. Therefore, resource schedulers perform these tasks. 2.4.4.2 Resource Consumers

Resource consumers implement the resource consumption oriented part of a resource. In order to consume resources, RCs have to

negotiate for resources or QoS

Re-negotiate for resources or QoS if resource consumption changes

Release the resource when finished

adapt to QoS specification in a defined way. Note that the resource controller as part of the resource provider tells the resource consumer to adapt if necessary

sample resource usage and measure received QoS in order to provide a GUI for displaying and forwarding usage information to other components

Resource consumers play an active part in the overall resource negotiation and consumption process. Therefore, a major distinction is made from the traditional way of programming. As a design constraint, the framework via some components should be able to decide on behalf of the application, if adaptation is necessary and if so, calls the user/application programmer-supplied adaptation mechanisms. In that sense, applications simply have to register with the framework, which has to provide some well defined interfaces to specify QoS, preferences and policies. Each resource consumer (i.e. for each resource) consists of several components:

Resource Managers, which are part of the consumer side of the resource consumption model.

Resource negotiation functionality, which provides mechanisms for communicating with resource controllers. For example, QoS parameters may be propagated to a RC for negotiating for resources using resource negotiation functionality.

Usage estimation functionality, which allows the resource managers to receive feedback from the resource schedulers on resource consumption and QoS delivery.

In order to handle multiple (CPU, network, and buffers) and composite resources for more complex tasks, a hierarchical organisation of resource managers may be possible, building a tree of resource managers. This approach has the following advantages: 1. adaptation to a certain level of QoS for one resource may lead to adaptation for all other resources. A resource manager, which uses other pre-existing resource managers, can force the resource consumers of the other resource managers to adapt. 2. a resource may depend on other resources to work properly. For example, the network resource needs some CPU to perform protocol processing. This can be


47 / 229


Draft / 06.02

29.3.2001

handled only in an integrated fashion, where a composite resource manager has at least two resource managers: one for the network and one for the CPU. 3. a common interface can be exploited, where the same function calls are used to request a composite resource to request, negotiate and control all involved resources. 4. remote resource availability can be handled very easily, if a virtual resource manager negotiates for remote resources on a remote host. The local resource managers negotiate with local resource controllers using the same functions as provided for resource consumers. As we have now introduced Resource Managers, Resource Controllers and Resource Schedulers together with their specific tasks, we may for each resource now define the exact functionality and an API that exploits this functionality. This is outside the focus of this document. However, we will use the design patter later also to derive a resource manager and controller for user QoS profiles, because these profiles can be seen as another type of resource. Note also, that clients never talk directly to controllers. Instead they use managers to implicitly use services provided by the controllers. This provides several advantages:

the interface between managers and controllers can be changed (e.g. for speed-up) without changing the client program code.

the function split between managers and controllers can be changed without changing the interface to the manager.

2.4.5

QoS specification and monitoring design pattern

Several relations in the BRAIN QoS Framework are modelled using the Resource Provider/Consumer Design Pattern previously introduced. This section will introduce the QoS specification Design Pattern, which complements it. This new Design Pattern describes the contents of the QoS contract established between provider and consumer to regulate the service provision. It also specifies how the obtained QoS can be monitored and how the violations of the agreed contract can be detected. The reactions to these violations are described at the end of this paragraph. 2.4.5.1 Definition of QoS contract

The concept of QoS contract was introduced as part of the Generalised QoS Framework for Distributed Multimedia Systems and further elaborated in the BRAIN QoS Adaptation Framework. This section will present the details of the QoS contract definition. The QoS contract specifies the agreement between the Provider and the Consumer for the service usage. The Provider offers a template contract as a set of parameters, which must be measurable. The template contract contains four fields per parameter. The first is the parameter name, a human readable text string. The second and third fields will be numbers representing the minimum and maximum possible values for the parameter. The fourth field is a number representing the relative importance of the parameter with respect to the rest of the parameters in the template contract. It is given as a natural number, starting with the number one in descending priority. Based on its internal adaptation policy, the provider uses the priority information for each parameter for finetuning the contract. During this optimisation process, the provider will treat the parameters that have higher priority in a preferred way. The provider has many options to regulate its service delivery process in order to not violate the contract. These


48 / 229


Draft / 06.02

29.3.2001

decisions are based on the provider’s policy, which is guided by the priority information. This is the formal representation for template QoS contracts: TC = { (p1, min_p1, max_p1, imp_p1), (p2, min_p2, max_p2, imp_p2), ... ,(ti, min_ts, max_ts) } The last parameter is special. It represents the time interval at which the Provider must report usage measurements. It is given in milliseconds and must always be present. As an example we will consider a software component that provides an audio transmission service. The template QoS contract could be: TC = { (quality, 0, 2, 2), (interactivity, 0, 2, 1), (ti, 1000, 10000) } This template QoS contract can be read as follows. The audio transmission service offers three levels of quality ranging from 0 to 2 (e.g. minimum (0), medium (1), high (2)); and three levels of interactivity ranging from 0 to 2 again (e.g. streaming (0), conversational (1), real-time (2)). Interactivity is more important than quality for the provision of the service within the Consumer expectations. The service reports can be generated at a rate between 1 and 10 seconds. In general, the semantic of the different levels of each parameter is unknown for the consumer. A possible way to obtain such information is that the Provider registers meaningful strings together with the contract template in the system. If this is not the case, then the number only represents different levels. The Consumer will obtain the QoS contract template and it will set the desired values for QoS parameters forming the requested contract. These values must be inside the limits specified in the template QoS contract. In the previous example, the requested QoS contract could be: RC = { (quality, 1, 2, 2), (interactivity, 1, 1, 1), (ti, 1000, 2000) } This means that this Consumer request conversational audio with medium or high quality. Reports must be generated between 1 and 2 seconds. It instructs the provider to regulate service delivery in such a way, that interactivity is more important than quality, quality is bounded between medium and high and interactivity is always conversational. Note that the Consumer did not modify the relative importance, thus accepting the one proposed in the template contract. In a general case, it is possible that the Consumer modifies the relative importance of the parameters. The Provider should honour this request. When the Provider receives the requested QoS contract, it will agree by returning the contract. If any parameter cannot be attended (e.g. because the resources availability changed since the template was obtained by the Consumer), it will ignore the original request and generate a new proposed QoS contract with modified values. The process will finish when Consumer and Provider exchange the same QoS contract. It might happen that the finally agreed upon QoS contract is not good enough for the Consumer. The consumer then has two options. The first involves not using the service and restarting the negotiation at a later time when more resources might be available. The second option involves start using the service within the agreed QoS contract but register in the Provider the desired QoS contract–probably more resources consuming. If later the Provider detects that there are resources available to fulfil this desired QoS contract, it will notify Consumer that upgrade would be possible. Here there are other two possibilities: either the provider only indicates the direction (i.e. upgrade) or the


49 / 229


Draft / 06.02

29.3.2001

provider can propose a new QoS contract that the provider derived from the old contract, the registered contract and the resource availability. In addition to this mechanism, an additional parameter is needed: the priority of the QoS contract, i.e. the priority among all contracts for the given Provider. In the case that the provider should later propose a new QoS contract (if the consumer registered for notification), it has to rebalance the resources among all consumers that requested adaptation. The priority can help for allocating more resources to those consumers that have higher priority. 2.4.5.2 QoS monitoring and QoS violation detection

The monitoring frequency of the QoS contract cannot be an arbitrary value set by the Consumer. For example, in CPU cycles reservation service is not feasible that each Consumer monitors the number of received cycles. Other example could be a broadcast transmission service where the Consumer will not run peer entities in each receiver. Thus the Consumer cannot receive reports on the reception of the information sent. To solve this situation, the BRAIN QoS Framework establishes that each Provider must report service usage –termed usage report- to each Consumer within the negotiated frequency. This will allow Consumers to monitor how QoS is being served. If monitoring is not desired, the Consumer sets the monitoring value to –1. The template QoS contract and its correspondent usage report are shown below: TC = { (p1, min_p1, max_p1, imp_p1), (p2, min_p2, max_p2, imp_p2), ... ,(ti, min_ts, max_ts) } UR = { (p1, value), (p2, value), ... } The usage report contains two elements for each QoS parameter contained in the template QoS contract. The first element is the parameter name and the second a number representing the provided service for the monitored values since the last report. The usage report does not contain any time interval value. The report is supposed to be sent during the agreed time interval. There is no need for a timestamp as this communications is local, internal to the terminal; thus it will not suffer any transmission delay. The Consumer can safely assume that the usage report was generated at the same time it was received. A sample usage report for the example introduced in the previous section can be found below: UR = { (quality, 2), (interactivity, 1) } It means that since the last report the quality of the audio transmission was high and the interactivity was conversational. In this case, the Provider honoured the QoS contract. This is easy to test automatically as each parameter is inside the agreed values: RC = { (quality, 1, 2, 2), (interactivity, 1, 1, 1), (ti, 1000, 2000) } The Provider will build the number in the usage report by sampling the served service each time an UR must be generated. The Consumer could store every UR and perform some statistical calculations on received values. These calculations can be used to proactively change the QoS contract in some cases. For example, if the Consumer is detecting that a particular parameter is always too close to the limit, it can decide to start a re-negotiation of the QoS contract to obtain broader limits. This is termed QoS change (corresponds to the renegotiate in the consumer/provider design pattern § 2.4.4) and it is initiated by the Consumer. If the Provider detects that a parameter of the QoS contract cannot be honoured, it will immediately send a notification to the Consumer including information about the CEC Deliverable Number 1.2

50 / 229


Draft / 06.02

29.3.2001

parameter. The Consumer is also able to detect a QoS violation itself when a single usage report is missing. The notification will allow an earlier detection to the Consumer, so the reaction will be faster. We also denote the notification as adapt, because the consumer has to react and adapt accordingly due to the QoS violation. In the next section the BRAIN QoS adaptation model is presented, showing how this way of representing the QoS contract and the report usage messages allows to implement automatic adaptation. In essence, after detecting a QoS violation (i.e. via receiving an adaptation notification or UR indicating that at least one parameter is outside the limit), the Consumer will start the negotiation of a new QoS contract. The usage report containing the violation can be used to build the new QoS contract together with the importance parameter and the adaptation policy inside the resource consumer. The Consumer cannot rely absolutely in the usage reports. At least it should track the reception of the reports in the agreed interval. It is considered a QoS violation the reception of the report later than expected or not receiving it at all. Furthermore, the Consumer may decide to implement additional monitoring of the received service when possible. It may happen that the Provider knows in advance that the agreed QoS contract can no longer be respected. In this case, the Provider will issue an adaptation request to the interested Consumers containing the new contract template. This is not considered a QoS violation, but the Consumer should also adapt. 2.4.5.3 Per flow adaptation strategies

When accessing a service, the Consumer will request a level of service specified in the QoS contract. The Consumer can obtain acceptable service with different combinations of values of the QoS parameters. These alternative set of contracts will be termed valid QoS contracts. Furthermore, when the Provider reduces the offered levels of service by changing the template QoS contract, the Consumer should be able to assess which parameters are most important. This is reflected in the importance value and it allows to build a new QoS contract easier to fulfil by Provider, but still acceptable for Consumer. These contracts will be termed acceptable QoS contracts. The ordered set of valid and acceptable QoS contracts form the adaptation path. The QoS contracts are ordered from valid to acceptable. The adaptation path is built reducing first the parameters with lower importance value. Recall that the highest importance corresponds to number one. In the introduced example, the audio transmission service offers the following template QoS contract: TC = { (quality, 0, 2, 2), (interactivity, 0, 2, 1), (ti, 1000, 10000) } To build the adaptation path, the Consumer must assign an importance for each QoS parameter or accept the included importance values of the template contract. In this example, if the Consumer accepts the values included in the template contract, it will be given priority to maintain interactivity over quality. And there are some values of QoS parameters that are not acceptable. For example, the quality cannot be low (0) and the interactivity cannot be streaming (0). With this information, the adaptation path can be automatically built by combining QoS parameter ranges from higher to lower values. The valid QoS contract will select real-time (2) as interactivity value, allowing the degradation of quality. This produces the following QoS contracts: C1 = { (quality, 2, 2,2), (interactivity, 2, 2,1), (ti, 1000, 10000) }


51 / 229


Draft / 06.02

29.3.2001

C2 = { (quality, 1, 1,2), (interactivity, 2, 2,1), (ti, 1000, 10000) } Note that quality was degraded first because interactivity (1) was assigned higher priority than quality (2). The acceptable QoS contract will use conversational (1) as interactivity value, allowing again the degradation of quality. C3 = { (quality, 2, 2,2), (interactivity, 1, 1,1), (ti, 1000, 10000) } C4 = { (quality, 1, 1,2), (interactivity, 1, 1,1), (ti, 1000, 10000) } Thus the adaptation path (AP) for this Consumer will be: AP = { C1, C2, C3, C4 } The behaviour of the Consumer will be as follows: it will always require C1 as QoS contract. If Provider does not accept it, it will try C2, C3 and C4 in this order. Suppose that C1 is accepted. Quality

2

1

C3

C1

C4

C2

1

2

Interactivity

Figure 2.8: Adaptation path of the quality/interactivity QoS plane

If a QoS violation is detected (by notification or usage report missing) during service usage, Consumer will start re-negotiation using a lower QoS contract in the adaptation path. Based on its adaptation policy it will use the next lower QoS contract (i.e. contract C2). Note that it could also use in this step C3 instead of C2 and later try to upgrade to C2. If the new agreed QoS contract is in the valid group, Service User will keep using it. If it is in the acceptable group, Service User will use the service with that level, but will register one of the valid QoS contracts to receive notification by the Provider whenever new resources are available. This will allow recovering valid QoS levels without the need polling constantly. 2.4.6

QoS Mapping: a Design Principle

As described in § 2.4.5, QoS Contracts capture the high level QoS aspects that the user perceives. This can be described as the goal of any QoS adaptation mechanism. In order to achieve this goal, one has to face in real implementations with a set of low-level functions, which can be tuned to a certain extent, by configuring and/or controlling some implementation-specific parameters. To this extent, some mapping functionality shall then be used, for deriving the values of such implementation-specific parameters, out of the original QoS Contract.


52 / 229


Draft / 06.02

29.3.2001

Most of the times, this is a complex problem that can be reduced to the optimisation of some objective function in a multi-dimensional space. In fact, several low-level functions can be combined together to achieve similar goals with respect to some highlevel requirements, and for each of such configurations of low-level functions a specific class of mapping functions may be required. In this section we present a design principle that can be used for steering the choice of such configurations with respect to any given pairing of a function and a correspondingly lower-level function. This principle basically describes how to achieve the goals set forth in § 2.4.5. What we present in this paragraph is though a qualitative approach. The complete description of functions and their implementation-specific parameters, along with the necessary mapping functionality, is out of the scope of this section. Figure 2.9 depicts the given problem domain by using a simple set model, where each set can be associated with a concept of cubicle12, similar to the one described in [D.1.1]. The overall space represents all the possible combinations of values of all the possible implementation parameters (i.e., by taking into account all the possible low-level functions that can be combined to achieve the given QoS Contract). For the sake of simplicity, Figure 2.9 represents only a two-dimensional space, where only two types of implementation parameters are considered.

Figure 2.9: Choosing the right set of implementation and configuration parameters

The bubble termed “application characterisation” represents the ideal settings that best map the original high level QoS Contract. Our goal is to try to approximate those settings, by taking into account the level of granularity of the implementation parameters, and the precision of the mapping formulas used. The figure shows five possible sets of solutions for the given example, where each set contains equivalent combinations of implementation parameters with a given combination of low-level functions.

12

As described in previous sections, QoS Contracts usually specify ranges of values for each QoS characteristic.


53 / 229


Draft / 06.02

29.3.2001

The set E3 has no intersection with the goal settings, and can therefore be immediately rejected. The other four sets (E1, E2, S1, and S2) are instead all equally valid. The question then is, which of them should be chosen. This choice has a direct impact on which low-level functions should be used, and therefore what mapping functionality to employ. To answer this question, we propose as qualitative methodology, derived from the Quality Function Deployment (QFD) [Akao90]. With this methodology (hereby used in a very simplified form) one can easily identify which implementation parameter set (and hence mapping formulas13) best approximates the given high level QoS Contract. Figure 2.10 shows how we can use this methodology for solving the given problem. The choice of the parameters shown in this figure is purely based on explanatory reasons. A possible application of this methodology is the mapping of high-level QoS Contracts to multimedia component configurations done by the Chain Coordinator, as explained in § 3.4.3.1. A detailed example of such a mapping is presented in § 4.

Figure 2.10: Example of QoS Mapping

Each QoS characteristic contained in the given high-level QoS Contract is first of all regarded as a requirement and assigned a Rate of Interest (RoI), which measures the relative importance of such requirement with respect to all the other ones, for a given type of service. The RoI basically coincides with the concept of priority indicated in § 2.4.5.3. These requirements are then organised as rows of a table, where the columns represents all the sets of possible solutions. These requirements are then organised as rows of a table, where the columns represents all the sets of possible solutions. Each column identifies a given configuration of low-level functions, along with the corresponding implementation parameters’ values, based on a specific mapping functionality. Whereas

13

Most likely the result will address only classes of formulas, since the implementation parameters can vary from vendor to vendor.


54 / 229


Draft / 06.02

29.3.2001

requirements can be derived from user profiles, the information concerning each column can be derived from some system policies. Each column is then evaluated against such requirements, and a coupling weight is then assigned to each entry of such table (according to the convention indicated in Figure 2.10). These weights represent how well the given set of solutions meets the requirements. Once the table has been completed, one can calculate for each column the sheer sum of weights and the sum of weights taking into account the RoI14. The former can be used for identifying a strong structural correlation between the set whose column maximises said sum, and the requirements. The sum of weights taking into account also the RoI can be used instead for identifying a strong instance correlation between the set whose column maximises said sum, and the requirements. Structural Correlation measures how well between a given set of implementation parameters matches the original requirements (i.e. the given set of parameters specifying a given application characterisation). This metric applies to all types of services, and can be used for steering architectural design decisions. With this metric, one can read the results as follows: •

Strong correlation occurrences identify key design issues

•

Weak correlation occurrences may help pruning the set of choices

Instance Correlation measures the coupling between BRAIN characterisation for a given type of service, and the set of implementation parameters. This metric can be used for steering configuration and/or QoS (re)negotiation. With this metric, one should check results against some minimum threshold: •

Above the threshold: the correlation value should be regarded as an endorsement priority-order

•

Below the threshold: the correlation value should be regarded as a pruning priorityorder.

2.4.7

Multi-stream synchronisation and QoS correlation

2.4.7.1 Introduction

Multi-media sessions may contain several streams of basic types (i.e. audio, video, and data). As an example, one session could contain two video streams and four audio streams from different partners or even from one partner in a surround scenario. Then the user should be given means to specify the quality of each single stream and in addition parameters that determine the inter-stream behaviour. As an example, stream synchronisation issues for audio or video fall into this category. In addition to specifying the quality, the user should therefore be given mechanisms to specify inter-stream preferences. As an example, the user could specify that the audio streams are more important and which audio stream is the reference stream used for synchronisation. Finally, the user might want to maintain several sessions in parallel. As an example, the user might participate in a real-time conference while simultaneously connecting to a VoD server. Then, the user should be given means to specify session related QoS parameters (like session establishment time) and inter session parameters 14

Other statistics are also possible.


55 / 229


Draft / 06.02

29.3.2001

and preferences. As an example the user might specify that the videoconference is more important than the VoD session. This hierarchical concept leads to a whole set of options how the system could adapt to different situations. Users QoS parameters and preferences would provide the input to the regulation process that is triggered by QoS-aware applications. These parameters, when mapped to low-level implementation parameters, determine a working point that can be used for tuning the overall system. Finally, they provide a degradation path that helps the system to decide in overload situations, how it should react in order to be compliant with the users specifications. This section addresses issues concerning the classification, specification, and enforcement of QoS correlation constraints on sets of flows in the media rich applications. To this extent, a data model is described: this data model can be used for designing the high level QoS interface presented in [Kassl00]. An introduction on QoS correlation can be found in Appendix F.6. 2.4.7.2 The BRAIN Approach: the Data Model

Figure 2.11, Figure 2.12, Figure 2.13, and Figure 2.14 depict the key concepts of the data model (in form of UML class diagrams). Users shall be able to access multiple devices (or, more generally, Systems), to run one or multiple Applications. Given an Application, the User shall be able to create an instance of a telecommunication Session (e.g. a conference call) with other parties. The Session thus groups all the logical Associations among all the parties involved in it, where each Association identifies a group of unidirectional Streams of information originating from the given computing unit and leading to a given peer party within the given Session. To this extent, we hereby introduce the concept of Streams, QoS Context, and QoS Associations. 2.4.7.2.1

The Flow concept

In this model, Flows are defined as the continuous unidirectional exchange of information between two peers at application level. Different types of Flows may exists: audio, video, data, text, or any combination thereof. A given party may act as a pure Flow Source (i.e. it exclusively sends out information), as a pure Flow Sink (i.e. it collects streamed information from the other party)15, or as both Flow Source and Flow Sink (typical of a conversational mode)16. Flow can multiplex Layers, where each Layer enhances incrementally the level of detail relative to the given base information (carried by the so-called Base Layer). This means that adding Layers can progressively increase the level of detail of the base information. Example: MPEG-2. Simple Flows (i.e. those without multiplexed Layers) and Layers get then mapped to streams at transport layer. We will use this distinction between flows and streams throughout the whole document. Applications use the Flow concept as the elemental unit of control while performing QoS provision and management tasks, but the applications can be also programmed to work: •

at lower resolution (by directly addressing Layers), or

15

A typical example is a Video on Demand service.

16

A typical example is a videoconference service.


56 / 229


•

Draft / 06.02

29.3.2001

at a higher resolution (by bundling input and output Flows in Bi-directional Flows).

2.4.7.2.2

The QoS Context concept

A QoS Context identifies an arrangement of QoS specifications that shall be enforced throughout a given set of Flows. In this way, the QoS Context concept can be used for enforcing the aforementioned QoS-correlation requirement throughout said set of Flows. This means that whatever the QoS specification of each Flow may be, the QoS Context forces a set of QoS constraints to be applied to the all the Flows belonging to the given set. For instance, all the Flows belonging to a given group can be assigned more or less resources (and therefore QoS), out of a bulk of reserved resource. This choice can be based on a priority scheme that can even be altered at run time by the user (e.g. by pointing a mouse over a window associated with a given Flow) and/or the communication system. As mentioned previously, electronic game applications and/or media-rich interactive applications offer other examples of multi-flow applications, where bundles of audio and video Flows are associated with objects to be presented to the user. For example, a moving and/or rotating cube can be displayed on a monitor with its faces textured with images from video Flows; and different audio Flows, each associated with a cube face, can be played whenever the corresponding face is oriented to a certain direction. To this extent, this type of applications shall be able to guarantee not only that related Flows are played within given temporal relationships (time-synchronisation), but also that the aggregate QoS experienced by the Flows is not below a minimum threshold (QoS-correlation). For instance, just continuing the game application example, it could make no sense to have some facets of the cube being textured as black and white movies, and others as high quality colour still images, even though the images were completely synchronised from a sheer temporal perspective. It would make more sense to have all facets displaying black and white movies, thus avoiding the pointless consumption of resources to get colour images to the detriment of the frame rate at which said images would be displayed. Of course the decision of what level of correlation should be enforced at QoS level among a set of Flows, is left to the developers' and even to the user's discretion. As previously anticipated, QoS-synchronisation may also address QoS constraints that might need to be enforced on the QoS specifications of each Flow belonging to the given QoS Context. Following the definitions set forth in [ISOX641], QoS parameters (in ISO terminology, the QoS characteristics) identify measurable QoS-related quantities and can be further classified into generic, specialised, and derived ones: •

Generic QoS characteristics try to capture a common underlying QoS parameter that can be applied to any particular circumstance, independently thus of what it is applied to.

•

Specialised QoS characteristics are concrete instances of generic QoS characteristics (eventually, generic QoS characteristics can be sufficiently concrete to be used as is, but in most of the cases a specialisation is required to capture the system- or network-specific peculiarity). For instance, a generic Time Delay QoS characteristic can be further specialised so as to reflect system implementation specific issues. The specialisation approach is well suited for addressing complex distributed systems, by mapping QoS characteristics at appropriate levels of abstractions.


57 / 229


•

Draft / 06.02

29.3.2001

Derived QoS Characteristics capture the dependencies between QoS characteristics, based on mathematical relationships. Some derived QoS characteristics may even be statistical in nature (e.g. maximum, minimum, range, mean value, variance and standard deviation, n-percentile, statistical moments, etc.). Even derived QoS characteristics can be specialised much like the generic ones. Therefore, specialisation and derivations can be regarded as orthogonal transformations of QoS characteristics. However, it must be noted that derivation may involve more than one generic/derived/specialised QoS characteristic (e.g. availability is a function of reliability and maintainability).

QoS Contexts can thus capture (in an associated QoS Contract) also those QoS parameters derived from the QoS specifications of the Flows that belong to said QoS Context. For example, the total amount of memory or the average bandwidth used by the given set of Flows. Finally, QoS Contexts can also address specific QoS parameters that indirectly affect to all the underlying Flows (e.g. system-level reliability issues). To sum up, QoS Contexts deal with QoS-correlation issues, and more specifically with: •

Common level of QoS specification for a group of Flows

•

Derived QoS parameters

•

QoS parameters indirectly affecting QoS specifications of Flows

The QoS Context concept can be further refined in various ways. We hereby present a default model, which is considered to be sufficiently detailed to take into account the many aspects of the given problem domain. The QoS Broker Plug-in concept (described in detail in § 3.5.3), along with the specific introduction of QoS Contract Type concepts, allow in any case the possibility to extend or even define alternative models. The hereby-presented model includes three types of QoS Contexts: the User Context, the Application Context, and the Session Context. •

The User Context defines the context of a given user (either restricted to the given computing unit the user is currently using, or extended to a set of computing units the user might be using concurrently). For instance, a given user can define (or be assigned) a given quota of a given type of resources, no matter what applications the user runs.

•

The Application Context describes the context of a given application. For instance, real-time requirements (minimum scheduling frequency), no matter of what specific activities the user exercises through said application.

•

The Session Context describes the context of a given session. For instance, the priority of a business-related videoconference session with respect to a private one, which is run concurrently to the former, no matter of what the QoS specifications of each individual Flows within said sessions may be. Following the same example, derived QoS parameters can be forced on a Session Context by e.g. imposing that the overall bandwidth consumption of all the Flows of a given videoconference session, shall not exceed a given threshold (and/or be less than a minimum level).

By following the aforementioned logical relationships among User, Applications, and Sessions, any given Session QoS Context can be nested in an Application QoS Context, and the latter can be nested in a User QoS Context. This means that the QoS parameters


58 / 229


Draft / 06.02

29.3.2001

of a given QoS Context can be derived from the nested QoS Contexts, and/or be indirectly applicable to the nested QoS Contexts. Furthermore, each QoS Context can be assigned a priority, which QoS-aware applications can use to determine the relative importance of siblings QoS Contexts, should some corrective actions be required (e.g. pre-empt an application due to heavy load of the given computing unit). Each QoS Context can be associated with a Finite State Machine (FSM), and this will be described bellow 2.4.7.2.3

The Association concept

Flows (and eventually Bi-directional Flows) can be grouped using various criteria. The basic Flow-grouping concept can be abstracted in the Association concept. The Association is any type of user-specified grouping of unidirectional flows of information originating from the given computing unit and leading to a given peer party within the given session. Therefore the Association shall include an identifier of the peer (e.g. a URL, a phone number, a pair of IP address and TCP port number). QoS Associations define time-synchronisation constraints on a multiplicity of related Flows, all originating from a terminal device and leading to the same endpoint. Associations are mainly useful for representing bundles of Flows, which QoS-aware applications can handle as a whole when trading off quality to resource availability among a multiplicity of equivalent bundles. To this extent, QoS Contexts are similar to Associations in that they can be assigned priorities, so as to allow QoS-aware applications to devise the best strategy for coping with a changed QoS scenario (e.g. dropping or degrading the quality of a whole Association). Each Association can be further specialised in various types of Flows grouping. Similarly to the case of QoS Contexts, we present a default model, which is considered to be sufficiently detailed to take into account the many aspects of the given problem domain. One can even use Plug-ins, associated with specific QoS Contract Types, to extend or even define alternative models for QoS-aware applications. The proposed model is based on different Association Roles, each addressing the clustering of Flows in associations at different levels, as described below: •

Per System Role: groups all the Flows originated by the given computing unit and leading to the same specific peer endpoint

•

Per User Role: groups all the Flows originated by the given user operating on the given computing unit, whereby said Flows lead to the same specific peer endpoint

•

Per Application Role: groups all the Flows originated by the given user using the given application on the given computing unit, whereby said Flows lead to the same specific peer endpoint

•

Per Session Role: groups all the Flows originated by the given user using the given application on the given computing unit, whereby said Flows lead to the same specific peer endpoint within the context of a given session

•

Any Role: groups Flows and leading to the same specific peer endpoint based on custom grouping criteria.


59 / 229


Draft / 06.02

29.3.2001

The definition of these roles (with the exception of the Any Role) is therefore reflecting the QoS Context model described in the previous paragraph. More specifically one can note that: •

the Per Session Role is a specialisation of the Per Application Role;

•

the Per Application Role is a specialisation of the Per User Role;

•

the Per User Role is a specialisation of the Per System Role.

2.4.7.2.4

Relationship between QoS Context and QoS Association

QoS Contexts differ from QoS Associations insofar as the formers specify QoS parameters that should be enforced throughout the whole set of Flows belonging to one or multiple QoS Associations, as indicated in Figure 2.13 (UML class diagram). 2.4.7.2.5

QoS- and synchronisation-specification model

Figure 2.14 depicts as a UML class diagram [Booch99] the model hereby proposed. This model, as aforementioned, covers both time-synchronisation and QoS-correlation issues, as follows: •

QoS specifications are modelled as QoS Contracts, which can be defined in an extensible manner, by using the concept of QoS Contract Type17.

•

Time-synchronisation is modelled by identifying a reference Flow in a given Association, and by associating each Flow belonging to the given Association with Synchronisation Information. The latter specifies the maximum delay and maximum jitter of a given Flow with respect to the reference Flow.

•

QoS-correlation is modelled by defining for each QoS Context a given QoS Contract.

Any QoS-aware application enforcing this model, shall ensure the consistency of the QoS Specifications with respect to both time- and QoS-synchronisation constraints (if any), and raise exceptions to the applications should any incongruity be detected thereabout. This model complies with the layering principle described in [X641R98a], by addressing QoS specification in a hierarchical manner, where one or more hierarchical levels (see § 2.4.7.2.6) can be mapped to a specific function in a layered architecture. For instance, in BRENTA the QoS Broker (described in § 3.5.3) can take care of enforcing both time-synchronisation and QoS-correlation among multiple flows, whereas each instance of the Chain Coordinator (described in § 3.4.3.3) deals with QoS adaptation at flow level only. 2.4.7.2.6

Adaptation Path

Based on the definitions set forth in the previous paragraphs, we ultimately propose a data model that defines generic data containers for specifying application-specific QoS parameters, along with adaptation policies. 17

More precisely, QoS Contracts are instantiations of QoS Contract Types, which - differently from the original QML specification [Frolu98] - are de facto used to catch multiple QoS Aspects. A QoS Aspect groups a certain number of QoS parameters related to a specific cross-cutting QoS concern (concept of Aspect Oriented Programming [Kicza97]). QoS Contract Types can be sub-typed and can be standardised, so that QoS-aware applications can interpret the semantics of a QoS Contract and decide whether it has enough capability to enforce such contract or not. In the latter case, QoS-aware applications are designed so as to be able to eventually select and remotely access or download a component (i.e. a Plug-in), which is specifically designed to handle the given QoS Contract (see § 2.4.5.1).


60 / 229


Draft / 06.02

29.3.2001

More specifically, adaptation policies shall identify well-defined adaptations of the basic QoS specification to a set of alternate degraded QoS specification (i.e. lower levels of QoS), in correspondence to well-defined sets of QoS changes, as monitored by the overall middleware [Loyal]. Due to the hierarchical structure of QoS Context and Associations, which reflects the way such adaptation policies are structured, it is hereby envisioned that the right model to address this complex issue is to model policies as hierarchical Finite State Machines (FSM) [Booch99]. Each State of such hierarchical FSM is uniquely identifies the one-to-one relationship between a given QoS Contract and a QoS Context. States can be classified into two Types of States: •

Negotiable States: the hierarchical FSM can access this kind of states only upon preliminary successful negotiation of the QoS Contract associated with the given State. Transitions among these states involve only negotiation mechanisms.

•

Controllable States: at the lowermost level of the hierarchical FSM (i.e. at Flow level) one can access this kind of states (which means being able to select multimedia components and configurations thereof) without the need to have peers negotiating anything among themselves18. Transitions among these states involve only control mechanisms on the terminal19.

More specifically, Controllable States are yet another level of inner states embedded within the Negotiable States and are defined and used exclusively by the middleware for handling the internal mechanisms associated with the use of the Multimedia Components. Each Transition of such hierarchical FSM describes a peculiar QoS change, which the system shall react to. The Transitions are triggered whenever specific predicates (i.e. the comparison of values of Monitored Parameters against QoS contracts statements) evaluate to true. Transitions are associated eventually with high level Actions (e.g. drop Flows - Drop action - or start new Flow - Add action). These actions can be eventually cause the generation of events to the users a temporary out of service condition due to a hand-off occurrence. QoS-aware applications shall allow the triggering of these events, through the insertion of armed Triggers in correspondence of given Transitions. As aforementioned, Transitions involving Controllable States trigger only control mechanisms, which however are not specified through this Data Model (it is up to QoSaware applications to figure out the correct action to take). This means that these Transitions are associated with QoS changes which do not force the operative point (i.e. the set of values of all the parameters specified in the given QoS Contract Type) to move outside of the bounds set by the Negotiable States. Differently from QDL [Loyal], the specifications of the QoS Contract, States, Transitions, and the Actions to be taken upon Transitions occurrence are de-coupled as indicated in Figure 2.14. This introduces modularity and thus flexibility to the design: one can combine a given QoS Contract with different adaptation policies, and adaptation policies can be configured with different hierarchical FSMs. At the bottom of this hierarchical structure, named States and Transitions can be finally directly applied to individual Flows. 18

With the exception of the choice and parameterisation of codecs, which need to be (re)-negotiated among peers.

19

For a formal justification of this, please refer to § 2.4.5. For an example, please refer to § 4


61 / 229


Draft / 06.02

29.3.2001

2.4.7.2.7 Negotiation of the Adaptation Path

So far only the negotiation of QoS Contracts in specific QoS Contexts and, eventually, of multimedia components (like e.g. codes) has been taken into account. However, before ever going to that level of details, the various communicating peers using the mechanisms described in the previous paragraphs need to share a common knowledge of adaptation path, that is the structure of the hierarchical FSM must be agreed by all said communicating peers. Also in this case negotiation schemes derived from those defined in [Loyal] can be used, whereby however the negotiated entity is not a parameter or a contract, rather the adaptation policies themselves. This means that the peers need to negotiate the various QoS Contracts describing degraded levels of QoS along with the rules describing when and how transitions among the various degraded levels should occur. This form of negotiation therefore implies the aforementioned ones: by negotiating the hierarchical FSM, one necessarily has to negotiate also the individual Negotiable States only. The negotiation process typically involves an initiator and one or multiple responders, and can be performed in one shot or on an iterative basis [Loyal]. The initiator offers a bid to the responders, who examine it and return a counteroffer to the initiator. The latter collects the counteroffers and determines the one (if any) which satisfies the requirements of all the involved parties. Once such optimal counteroffer has been sorted out, the initiator sends it as a new bid to each responder. In an iterative scheme, the process could at this point restart, should one of the responder still do not accept the new bid. The iterative approach must however be constrained with an upper limit of iteration, and it is in any case quite complex and not efficient. Therefore this model focuses only on the basic, non-iterative scheme. The idea we hereby propose is basically consists in running a non iterative negotiation process at start-up time, i.e. when an initiator peer starts communicating with other peers (e.g. at session invitation time), with respect to adaptation paths. The initiator will propose a hierarchical FSM (i.e. a specific adaptation path), and each responder will validate the bid against its own adaptation policies, and respond accordingly with a counteroffer. This model limits the scope of the counteroffers to the definition of a subset of the original bid (in order to limit the complexity level of the problem). This translates at responder-level into: •

a QoS Contract conformance verification [Frolu98] applied to each QoS State with respect to the QoS Contract Types and QoS Contracts applicable for the given responder, and

•

a set of pruning operations applied onto the structure of the original hierarchical FSM proposed by the initiator.

One must note that whenever a new communicating peer joins a group of already communicating peers, the new peer act as initiator of a new negotiation process at Session Context level, following the same mechanisms described above. Furthermore, any ad hoc creation, modification, or removal of QoS Contexts and/or Flows after that the negotiation process has been successfully completed (i.e. not already taken into account in the negotiated adaptation path), would trigger once again a new instance of the negotiation process.


62 / 229


Draft / 06.02

29.3.2001

Since the negotiation process is quite expensive (and exactly for this reason we hereby propose to limit it only at start-up time), successive re-negotiation as described above can cause inefficiencies. To this extent one must however note that: •

in a video-on-demand scenario, both parties simply agree a priori on a adaptation path on a predetermined set of Flows, in order to cope with QoS changes. The variability of the aforementioned ad hoc changes therefore does not apply to this case.

•

the initiator can eventually already take into account events like the creation, modification, or removal of QoS Contexts and/or Flows in the adaptation path it bids.

•

after the initial negotiation, all peers can more quickly converge to negotiation agreements compared to the case of the initial negotiation, since the majority of them are using an already negotiated hierarchical FSM.

Finally, one must note that the user her/himself might deliberately cause a QoS change on an already running multimedia application, for example in order to increase or decrease the overall level of QoS, or some part of it only. This negotiation would reflect in a change in the QoS Contracts associated with the adaptation path, but could also reflect on the structure of adaptation path itself.

Figure 2.11 General Data Model: QoS Context


63 / 229


Draft / 06.02

29.3.2001

Figure 2.12 General Data Model: Association

Figure 2.13 General Data Model: QoS Context vs. Association relationship


64 / 229


Draft / 06.02

29.3.2001

Figure 2.14: QoS- and correlation-specification model 2.4.7.3 Example

A statechart representing an example of instantiation of the hierarchical FSM is presented in Figure 2.15, where QoS Contexts are put in evidence with respect to the States. For the sake of simplicity, each QoS Context is shown as associated with a unique instance of a FSM (e.g. the given User Context is associated with only one hierarchical FSM, each state of which contains only one nested FSM). By using the concurrency concept of statecharts [Booch99] one can easily model more complicated scenarios where, e.g. a user may have two applications running (for instance a videoconference one and a video-on-demand one) and each featuring its own hierarchical FSM. At the lowest level of the hierarchical FSM, are inner FSMs composed of only Controllable State, one within each QoS State associated with a given Flow. Such FSM composed of only Controllable State can be either specified ad-hoc through the API or can simply be general purpose ones re-used across the hierarchical FSMs.


65 / 229


Draft / 06.02

29.3.2001

Figure 2.15 Example: UML Statechart


66 / 229


2.4.8

Draft / 06.02

29.3.2001

Profiles and QoS Adaptation Policies

The success of multimedia applications and services running on a heterogeneous distributed environment lie on the ability of the system to adapt the provided contents to changing conditions of the network, user preferences and different capabilities of terminals. This adaptation process has to take some information to provide the user with a service in keeping with a QoS contract, terminal capabilities and personal preferences. We need to provide a way to represent all this information and to define a protocol to exchange it between the involved parties (see § 2.6). In order to specify QoS characteristics, it is necessary to have a flexible language that is powerful enough to define a QoS contract. This language can then also be used to query QoS capabilities of individual resources and software components in the distributed system. XML based syntax seems to be adequate to specify QoS requirements on distributed systems and to query QoS capabilities. In this document, we assume that the user QoS profiles are stored and managed by some trusted entity. This entity can communicate with other entities providing various services, so that the applications can retrieve or modify profiles and profile data as necessary. For this purpose an interface has to be also designed. The location of this entity and the fact that it could be centralised, replicated or distributed do not really matter, but it is important that all applications can use a common set of protocols and data types for exchanging profiles. The recommendations in this report are based on W3C and IETF standards such as CC/PP, P3P, RDF, LDAP, etc. 2.4.8.1 QoS profile

The QoS profile information contains the description of the user’s QoS requirements and the service provider QoS proposed contract20 (see § 2.4.5.1). These two parts are used to negotiate QoS parameters between the user and the service provider, and in case of agreement represents the QoS contract. Together with this information is a description of the terminal capabilities from the terminal being used to access the service, integrating all the information that would be useful to adapt contents and services to user needs and desires. This way, QoS profile can be logically split in two major parts: information related to the user QoS preferences and terminal characteristics and service provider QoS offerings. QoS profile can be seen as another type of resource within the framework presented along this document. It is therefore natural to adopt the Manager/Controller mechanism introduced later in this document (see § 3.4.3.4). Figure 2.16 shows the logical structure of the QoS profile. 2.4.8.1.1 User QoS Profile

As stated above, the user QoS profile can in turn be split in two parts: •

20

The Requested QoS Contract: contains user’s desired values for QoS parameters for a given service.

Note, that in the case of a distributed scenario, the service provider can also be the remote peer that offers some services (like Video on Demand) to the local system.


67 / 229


•

Draft / 06.02

29.3.2001

The Terminal Capabilities: these represent the current hardware capabilities of the terminal: its type (PC, PDA, phone…), its CPU power and memory (if any), the resolution of the screen, number of colours, input devices (keyboard, pen, voice), supported applications or protocols… This information would be useful to the service provider to adapt the contents and services offered to the user’s terminal features.

User QoS Profile

Requested QoS Contract

User QoS Profile

Terminal Capabilities

Template QoS Contract

Service Provider QoS contract template

Figure 2.16: Structure of user QoS profiles

All these properties should be described and exchanged using a high-level standard syntax to warranty interoperability between different network elements involved in QoS negotiation. The W3C Composite Capabilities/Preference Profiles [CCPP99a] proposes a framework for content negotiation. This proposal fits our needs since it express data in an object oriented way, allowing the expression of relationships between data elements and the exchange of semantic information. CC/PP describes an encoding for capabilities based on XML/RDF [RDF99a]. The syntax described here is just an encoding proposal to exchange information between the involved entities and not describe the way this entities store the profile information. The basic data model for CC/PP is a collection of tables. Each table contains a collection of RDF statements formed by attribute/value pairs. For efficiency reasons when using wireless networks, CC/PP adds some extensions to this basic data model, as the use of default properties and indirect references. The profile controller (see § 3.4.3.4.2.1) would then use CC/PP Exchange Protocol CC/PP99b or the WAP UAPROF protocol WAP99a to collect profile information, which will be possibly modified by the proxies or gateways that are in the network. This is just an alternative, another one, described later in this document is the use of LDAP directories. 2.4.8.1.2 User QoS Contract

The QoS contract proposed by the user is represented by CC/PP (RDF) record that is linked to the service provider QoS contract proposed for that service and for that given service. We need to identify and authenticate the owner of the user QoS profile since we would have different levels of service offered to different users. Service provider would have different templates for different services and use that templates as an initial QoS contract to start the negotiation. Most of the data contained in this CC/PP record is specific to the current session and does not need to be persistent.


68 / 229


Draft / 06.02

29.3.2001

The applications relying on the profile server will only use the QoS profile information. The involved parts in the negotiation use the profile server to retrieve required QoS profile data. The negotiation is initiated exchanging the CC/PP record and matching the user QoS preferences and service provider QoS proposed contract until the values reflected in both parts match, satisfying service provider and user needs (see § 2.6). Suppose that the user specifies QoS parameters for Audio and Video Flows and wants to define the following values: Audio={(Delay, 100, 250), (Quality, CD, CD)} Video={(Delay, 150, 400), (Color, True_color, True_color), (Height, 320, 320), (width, 200, 200), (fps, 10, 18)}

And some QoS parameters which, at first, are independent from the media QoS parameters but would impose some constraints to this media parameters. For example, “bandwidth” would be a constraint to the maximum number of fps of a video Flow. (bandwidth, 100Kb/s, 1024Kbps) Here is how the CC/PP representation of this QoS contract looks like: /> />


69 / 229


Draft / 06.02

29.3.2001

/> />

The CC/PP representation of the QoS contract will be directly mapped to a tree as shown in Figure 2.17.

Delay

Max

100 100

Min

250 250

Max

CD CD

Min

CD CD

Max

150 150

Min

400 400

Max

10 10

Min

18 18

Audio Audio Quality Media Media Streams Streams

Delay Current Current Network Network Session Session

FPS

Video Video

Color

Bandwidth Network Network Connection Connection

Max

100 100

Min

1024 1024

Max True_Color True_Color Min

True_Color True_Color

Figure 2.17: Tree representation of the QoS Contract (Some nodes have been removed from representation) 2.4.8.1.3 Terminal Capabilities

The description of the terminal capabilities gives the service provider an idea on how to adapt the contents to fit the user’s terminal features. The natural way to represent this information using a high-level description language is, as in the case of QoS contract, the use of CC/PP. This way, terminal capabilities are perfectly defined and integrated with QoS contract information. Consider we are using a multimedia Acme R520 terminal to access a VoD service on the network, and that terminal has the following characteristics: CPU_Model=”A520”, CPU_Speed=”200Mhz”, Memory=”64Mb”, Keyboard=”No”, Speaker=”yes”, Screen_size=”320x200”, Num_Colours= “256”, OSName=”AcmeOS”, OSVersion=”2.0”. The CC/PP representation of this information would look like:


70 / 229


Draft / 06.02

29.3.2001

As we did with QoS contract in Figure 2.17, a tree representation of the terminal capability definition is also possible. In the previous example all the information goes from the mobile terminal to the service provider. We can add indirection, to improve network performance, as showed in the next example. This way, the service provider does not receive the information directly, it has to look for it in the given URL: 2.4.8.2 QoS Contract Template

QoS contract template (see § 2.4.5.1) is the part of the QoS profile related to the service provider. When a user wants to use a service, the service provider offers the user a QoS contract template containing QoS parameters related to that service. The service provider will offer the QoS contract related to the requested service that fits better with the QoS levels that the user has assigned, based on the available resources in that moment for that service. As well as user QoS profile, QoS contract template would be suitably represented using the CC/PP syntax. CEC Deliverable Number 1.2

71 / 229


Draft / 06.02

29.3.2001

2.4.8.3 Access control and privacy

The user must be able to selectively allow or deny any application to access some parts of the profile. In order to do that, each field in the profile would have an access flag associated to it. This flag can take the following values: • Allow any application to read this field. • Allow only the applications in the trusted-list to read this field. • Require a confirmation from the user before allowing any application to access this field. • Require a confirmation from the user, only if the application is not in the trustedlist. • Do not allow any application to access this field Whenever application (service) requests the value of one or several fields in the profile, the profile server checks the corresponding access flags. If any of them is set to “ask”, then a confirmation request will be sent to the user. The user can then select if he wants to add the service to the trusted-list, to allow it to read the given field(s) only during the current session, or to deny the request. It is possible that some notification or “push” services will try to access the user profile while the user is not connected. In this case, any field that is set to “ask” will be treated as if the access was denied. 2.4.8.4 QoS Policy

The QoS policy would be defined as a set of unambiguous rules that describe the action(s) to occur when specific condition(s) exist. The organisation of rules is hierarchical since a rule will often comprise of other rules. The application of these rules, and the actions taken in consequence, affect the negotiation of the QoS contract at the beginning of a session, and even would lead to the re-negotiation of that contract during the session due to changing conditions that triggers certain actions. As an example, we will have the following rule that is part of a policy: “Provide the JitterFreeMPEG2 video service for authorised users between authorised points, but only at agreed-upon times”. This rule will be defined as: IF user IN ApprovedUsers AND service IN VideoServices AND source IN VideoSources AND destination IN VideoDestinations AND time IN ApprovedTimePeriods THEN provide JitterFreeMPEG2

If a user ask for a JitterFreeMPEG2 Video service, specifying certain QoS parameters in its proposed QoS contract, the service provider will authorise or deny that service to that user as a result of applying that rule. In the previous example the action to be taken is a “yes” or “no” action, but QoS policy rules would be more complicate and affect the range of values of QoS parameters in the QoS contract modifying the way the service provider offers its services. The QoS Policy influences mainly the QoS negotiation (i.e. how the Adaptation Path is interpreted). QoS Policies influence how the QoS Contract Template is constructed. We therefore distinguish between two different QoS Policies (see Figure 2.18): a. one influencing the QoS Contract Template construction b.

one influencing the QoS negotiation.


72 / 229


Draft / 06.02

Requested QoS Contract

29.3.2001

Profile Composition

Terminal Capabilities

QoS Negotiation

QoS Contract Template

QoS Contract Agreement

QoS Policy Figure 2.18: Role of the QoS Policy in the QoS Negotiation

Figure 2.18 shows the influence of QoS policy in the QoS negotiation process. QoS policy would condition the way the service provider design its QoS contract template since it has to be design to fulfil the rules given by the policy. On the other hand, QoS policy influences QoS negotiation process between the client and the service provider. The QoS contract resulting from the negotiation must not infringe any of the rules given by the QoS policy. At the same time, the policy gives some guidelines on how to interpret the adaptation path defined by the user. 2.4.8.5 Profile matching

During the profile matching process, the CC/PP record representing user QoS requirements and QoS contract template offered by the service provider are compared. If both contract proposals do not match, the two parties update the given QoS parameter values and compare them again until both match. The result of this matching process is the QoS contract, which would be valid for the current network session or would be changed by user or service provider due to a change on requirements or availability of resources. 2.4.8.6 Identifying, creating and exchanging profiles

The suggested protocol for accessing the profiles is LDAP [LDAP95a], [LDAP95b], and [LDAP7]. This protocol is simple, extensible, and cross-platform and is already implemented in several products. In addition, LDAP front-ends to several databases already exist, so the core of the profile server could be full-featured SQL database with CC/PP in and out filters. The LDAP server allows the applications to read, modify, copy or delete user QoS profile. The “read” operation is allowed to all services, but is subject to the restrictions added by the user to control her privacy (see section 2.4.8.3). This implies that the access to some parts of the profile may be delayed if a confirmation from the user is required. The “copy” and “delete copy” operations are also allowed to all services, although the access restrictions will be propagated to the copy. The “create” and “modify” operations are restricted: only one special application is allowed to do that. The profile manager is the only application that can modify the user QoS profiles. From the user’s point of view, this ensures that any change to her profile will always be done through the same interface (which can require some additional authentication). Any


73 / 229


Draft / 06.02

29.3.2001

application and/or network component can invoke the profile manager service if needed, and that service will take control of the current session until the user has finished editing her profile. The control will then be given back to the initial service. 2.4.8.7 Roles and links between user QoS profiles

The user can have several roles. All roles are grouped in the same user profile, but the user can switch between them in order to activate different QoS parameters for different services or situations. The user interface in the terminal should provide a way for the user to select among the list of available roles before using a service. There could even exist some predefined QoS templates for different services so the user does not have to define every significant value for every service he/she is going to use. Remember that in most cases the user is not familiar with QoS parameters and values that gives him/her the desired look and feel to the application. 2.4.8.8 Requirements for the service applications

In order to be able to connect to a profile server, an application must support the protocols and data formats described in this report. 2.4.8.8.1 Protocols

The recommended protocol to access the QoS profile repository is: •

LDAP v2 [LDAP95a] or v3 [LDAP97]

If the profile server is implemented on top of an SQL database (e.g. Oracle, MySQL, Postgres, Sybase) then it might be possible for the application to connect to the database directly and use for example SQL instead of LDAP. This could be more efficient because SQL would allow more complex queries to be satisfied in one transaction and the application would not have to implement the LDAP protocol. But this is not recommended because the profile server should probably add some access that would not be possible if a direct access to the database is allowed. 2.4.8.8.2 Data formats

The data formats described in this report are based on the following standards: •

RDF [RDF99a], [RDF99b] and XML.

•

CC/PP [CC/PP99a] (based on RDF), including the types defined in UAPROF [WAP99a].

It is not necessary for the application to implement the CC/PP Exchange Protocol [CC/PP99b], because only the data types defined by those standards are used here. The profile server collects the information using the appropriate protocols, and then aggregates it in a RDF record, which can be requested or modified using LDAP. 2.4.8.9 Recommendation for terminals

In order to make the best use of the features (input and output devices) provided by the terminal being used, it is important that the services that support customisation of the user interface can get a comprehensive CC/PP record from the profile server. In order to do that, the profile server must be able to get a valid description of the capabilities of the terminal. It is possible for the profile server to guess some of these capabilities. It would look up the user in a subscriber database and guess the capabilities according to the type of terminal used, if this information is available, or by looking at the user-agent that was used in the last requests. However, these methods require that each new model of CEC Deliverable Number 1.2

74 / 229


Draft / 06.02

29.3.2001

terminal be registered in a database so that its capabilities are known. Maintaining this list of terminals can be a major problem. This is why it is better if the terminal itself provides a description of its capabilities (or a pointer to this description), so that the profile server does not have to guess them based on list of terminals that could easily be out-of-date. The principle described by CC/PP, Figure 2.19 represents a typical scenario for hardware capability exchange. Hardware Hardware Vendor Vendor

Link to default Hard Capabilities and overrides of default values Wireless network & Internet access infrastructure

Hard. Capabilities Mobile Mobile Portal Portal

Internet

Figure 2.19: CC/PP application scenario

2.5 Admission Control When data has to be transmitted under QoS guarantees from source to sink, all functional entities along a path must work together in order to provide at least some QoS guarantees for distributed multimedia applications. Therefore, all entities (i.e. the end-systems and optional processing elements in the network) have to manage their resources and try to maintain QoS contracts over the duration of a session for all clients without scarifying them. The resource providers have to perform availability checks for each request for resource usage. The result of such checks depends on the system status and may vary over time (more resources may become available over time, if sessions are torn down). Within our envisaged framework, a co-ordinating entity not only manages local resources but also orchestrates the players in order to provide End-to-End QoS. That means that also resource availability at the peer and inside the network has to be considered. At the end-systems, the following resources can be managed:

CPU resources

Memory resources

local network stack related resources

multimedia device resources

Local end-system admission tests can be divided into two sub-systems according to the ISO/OSI communication subsystem layering:

Framework level admission tests

Resource controller level admission test

Framework level admission tests try to analyse the resource availability managed by framework components, like renderer, capturer, etc., whereas resource controller level admission tests are specific for one single resource (e.g. CPU) and depend on the CEC Deliverable Number 1.2

75 / 229


Draft / 06.02

29.3.2001

scheduling mechanism for the specific resource (e.g. if the scheduling mechanism for CPU is changed, the admission test for allocating CPU resources has to be changed, too). The result of the admission tests represents the local resource availability status, which is needed inside the co-ordinating entity for negotiating with the remote peer (i.e. the local co-ordinating entity has to know about the local resource availability status before negotiating with the remote peer). Not necessarily, they might change during the negotiation phase anyhow. In addition to local end-system admission tests we have to orchestrate the end-systems involved. In a one-to-one communication scenario, we have two end-systems communicating. We take this scenario as the basis for our discussion below. By orchestrating we mean the fact, that it is not sufficient to reserve only locally without asking the peer what he would like to get. As an example, the sender might easily send 25 fps and reserve the resources for that. The receiver but might only be able to receive 5 fps, so it is unnecessary to reserve at the sender resources for 25 fps (both for CPU, memory and network). Orchestration also deals with the sequence of actions that have to be performed when orchestrating. As an example, we have to consider if we first reserve locally and then try to reserve remotely, or vice versa. 2.5.1

Framework Level Admission Tests

The devices used for capturing the data have to offer a certain performance. Therefore, a device quality test for each device involved in the transmission process should be performed.

device quality tests The quality of the device has to be examined. A comparison of framework level QoS parameters and the parameters provided by the multimedia devices has to be done in order to determine, if a specific device can fulfill the desired QoS. For example a video device driver may provide a sample rate of 20fps at 16 Bit/pixel colours, but the desired framework level sample rate is 30fps at true-colour.

local schedulability test This is a test of schedulability of the tasks needed to process the multimedia Flows. Note, that there may be several sub-tasks needed to process a flow at an end-point (i.e. capture, compress, packetize and send). The local schedulability test offers a combined result for all sub-tasks. This schedulability test is different from the admission test performed at the resources controller. There are also different types of tasks: periodic tasks for the periodic production or consumption of media deadlinedriven tasks, which can be further sub-divided in hard-real-time deadline tasks, soft-real-time deadline tasks and non-real-time-deadline tasks (i.e. garbage collection)

End-to-End delay test This is a two-step process. First, the duration of the local framework tasks has to be checked against the End-to-End delay bound (as a framework level QoS parameter). If not enough resources are available locally to fulfil the delay requirements, the negotiation can not proceed and the next lower QoS has to be derived from the user QoS preferences according to the given adaptation path. The local admission test then may continue at lower resource requirements, until enough local resources are available. In the second step, the processing time of the framework level tasks at the


76 / 229


Draft / 06.02

29.3.2001

remote end-point and the network-oriented delay have to be checked against the total End-to-End delay bound. Admission is granted, if (i) local admission succeeded and (ii) network and remote admission succeeded. The order of admission tests can be determined by state machines and higher level protocols.

buffer allocation test Memory availability has to be checked for multimedia devices in order to smooth traffic jitter. Smoothing traffic is required if the measured End-to-End delay is less than the requested End-to-End delay. If the measured delay is more than the requested delay, adaptation has to be triggered.

2.5.2

Resource Controller Admission Tests

For each resource type, a resource controller together with a resource manager is responsible for granting admission for the specific resource. If several resource consumers request resources from one single resource simultaneously, a resource scheduler has to distribute resources according to the QoS requirements of the resource consumers.

throughput admission test This admission test is a task of the network controller. Goal of the test is to control the assignment of bandwidth to individual connections. The network host interface capability and its device driver determine the upper bound. Two different tests could be performed: (1) the throughput for one connection must be less than the total bandwidth of the host interface in that particular direction; and (2) the sum of throughputs for all connections in each direction must be less than or equal than the total bandwidth of the host interface in each direction.

rate control admission test The number of packets per second that are moved from/to user space to/from kernel space have to be checked against the local system capabilities and system usage.

End-to-End-delay test The duration of all network tasks has to be checked against the required End-to-End framework level delay bound. This test is in the responsibility of the network controller, which should implement it together with the network packet scheduler implemented inside the protocol stack and hidden by the ESI. This is similar to the framework level End-to-End delay test.

schedulability test The schedulability of all tasks (network and framework level tasks as well as all other tasks currently running in the operating system) has to be guaranteed. This test is in the responsibility of the CPU controller that should implement it together with the CPU scheduler. Two different time dependencies have to be considered: Time dependencies between framework tasks (capture, compress, packetize) and network-subsystem tasks (send/receive). Time dependencies between input/output Flows (e.g. for interactive conference scenarios).

buffer allocation test


77 / 229


Draft / 06.02

29.3.2001

If network tasks queue packets for incoming/outgoing traffic, enough buffer has to be available for buffering. Also, if internal re-transmit protocols are used in order to cope with packet loss on the wireless link or due to router buffer overflow, buffer space has to be reserved, too. 2.6 End-to-End QoS negotiation 2.6.1

Scope

The scope of this section is to set forth the requirements of an End-to-End QoS Negotiation /Re-negotiation Protocol (thereinafter, the E2NP/E2RP). The purposes of this protocol are: •

the establishment of QoS End-to-End in a co-ordinated manner among peers at several layers (not only network QoS, but also resource reservation in the endsystems)

•

the addressing of re-negotiation issues, which may be required due to variations in QoS delivery at various layers (e.g. network resources, end-system resources); and

•

the attempt to leverage existing protocols (e.g. SIP [Handl99]) to the greatest extent, by introducing new functionality with respect to QoS management with minimum impact on the protocol specification.

We motivate the need for such a protocol by the following example. Suppose an application wants to send video at 20 fps to a client. It is useless to waste network resources (for transmitting the 20 fps), if the client has only enough resources to handle 10 fps. Therefore we conclude that in addition to managing local resources at the endsystems, resource reservation is necessary in the network and a co-ordination of these resources requires some protocol, that both parties can agree on a common set of QoS levels and degradation path, which is applicable if the current level of QoS can no longer be maintained. 2.6.2

Introduction

One of the key requirements of the BRAIN project is the support of various types of service [D.1.1]: •

Conversational mode services

•

Distribution mode services

•

Information retrieval mode services

For each type of services, a specific flavour of the E2NP/E2RP may be required. The reason for that is that, depending on the type of service, different action sequences are required for reserving network resources, which also depends on the communication mode of each peer (sender/receiver). For instance, some questions need to be addressed, like whether the receiver needs to wait to be contacted by the sender, or who initiates resource reservation on the network (the sender or the receiver). The answers to these questions depend on the type of service. In addition, the E2NP/E2RP depends on the protocols and extensions thereof, on which it is based (e.g. SIP or RTSP [Schulz98]). This section analyses the different aspects and


78 / 229


Draft / 06.02

29.3.2001

the various negotiation strategies to be applied in BRENTA with respect to the various types of services supported. 2.6.3

The core concept of E2NP/E2RP

The establishment of a QoS-enabled communication session can be accomplished in a multi-step process, starting with negotiation of QoS aspects on an End-to-End basis [Marsh00]. The key idea hereby proposed is to have peers negotiating beforehand (i.e. before the actual communication takes place) a common level of QoS on which use all peers can agree. This is a form of pre-negotiation of a vocabulary, which peers can later use for efficiently dealing with contingent negotiations (e.g. when establishing audio/video Flows) or re-negotiations. The benefit of this approach is that time necessary for renegotiation is reduced because the peers may only refer to a negotiated state instead of performing a full negotiation cycle during streaming. Furthermore, the type of negotiation can be tailored based on capabilities that are currently available at all peers. The identified steps are: (1) pre-negotiation of a set of QoS contracts with all the peers. Such set describes an Adaptation Path for a generic Flow of a given type (e.g. audio, video, or data Flows). (2) As intermediate step, peers may negotiate QoS correlation and synchronisation aspects among multiple Flows. This might not be necessary if a session contains only one Flow: in that case QoS correlation would be simply ignored. Thus this step builds up the session concept. Please note that, should peers have to co-ordinate several streams, QoS correlation and synchronisation issues would be handled at runtime by triggering specific co-ordination function (based on e.g. RTP), which are derived from the negotiated QoS states. (3) As a last step, peers can negotiate QoS Contracts on a per Flow basis at establishment time, based on the pre-negotiated vocabulary established during step (1). Only at this step, actual admission control is performed. To this extent, this invention proposes to follow an economy principle derived from [Nahr95] observing the fact that network resources have to be shared and are more expensive than local resources. Please note that the term expensive is being used in this document in a very loose way: this section in fact does not try to address any monetary aspect (which, even if important, involves too many actors in the market and therefore is too complex to be solved). The hereby-proposed process is based on the following ordered steps: (3.1) Local resources (i.e. resources managed by the local system) like CPU, memory, and power are reserved on the terminal device of the party initiating the communication (i.e. the initiator). These are the cheapest resources, since exclusively the initiator uses them. The amount of resources that are reserved at the initiator corresponds to the quality that the initiator is interested in. (3.3)

Remote resources like CPU, memory, and power are reserved on the terminal device of the party accepting the request to establish the communication (i.e. the responder). These resources may be eventually shared by multiple initiators with respect to multiple telecommunication sessions, like in the case of a Video-on-Demand scenario (where the responder is the video server, which needs to serve multiple requests from multiple users). It does not make sense to try to reserve these shared


79 / 229


Draft / 06.02

29.3.2001

resources (thus affecting other communication sessions terminating on said responder) prior of having ascertained the availability of resources at the initiator side. (3.3) Only when both the local and remote resources have successfully been reserved, network resources are reserved, which are shared (by definition) by a multiplicity of parties, and therefore to this extent can be considered as the most expensive resources at all. (4) Last but not the least, the E2NP/E2RP describes a protocol procedure for informing peers about changes in capability configuration (e.g. the installation or removal of a given multimedia codec) of given participant of the given communication session. By proactively disseminating this information among peers, proper actions can be taken with respect to any currently active communication session, and to all the negotiation processes concerning future attempts to establish communication sessions. Steps (2) and (3) (or (121), (2), and (3)) can be treated jointly as one-shot22 or separately as a sequence of actions23. Note that in certain cases only step (3) might be necessary. As an example, if everything is pre-negotiated by default (using fixed settings) and only one quality and configuration of a video-stream is located on a server. A key aspect of the E2NP/E2RP is that it can be used not only in conjunction with network resource reservation signalling protocols, but also with other types of QoS architectures, like DiffServ [Blake98]. In the latter case, pre-negotiation will focus on having peers agreeing on the types of QoS classes to use, with respect to the capabilities of each peer. 2.6.4

What to negotiate

First of all let’s focus on (i) what type of information needs to be negotiated, and (ii) under which circumstances. More specifically, peers should agree on: •

which E2NP to use;

•

which capabilities are available and applicable;

•

what QoS contracts are applicable and form the adaptation path; and

•

adaptation paths themselves.

Most of these features are not supported by existing versions of SIP and RTSP. Furthermore, the E2NP/E2RP is flexible enough to integrate any existing network resource reservation protocol (e.g. RSVP or Yessir [Pan99]). In the following, we circumstantiate these assumptions with motivations.

21

In such a case, pre-negotiation might later be no longer valid should a new party join a session with a different understanding what an adaptation path is with respect to the already negotiated one.

22

As an example, negotiation and set up of a session with two audio- and three video-streams, simultaneously

23

Pre-negotiation first, then start with the first audio-stream, add the first video-stream, add the second audio-stream, add the second video-stream…


80 / 229


Draft / 06.02

29.3.2001

2.6.4.1 Types of supported E2NP

The BRENTA architecture is aimed to a broad set of applications and services. To this extent, most of the state of the art applications will not be able to employ the herebydescribed E2NP without any specific retrofitting; rather they will eventually apply some other form of negotiation mechanism. It is reasonable to assume also that future applications may eventually only partially support the E2NP, or just different versions thereof. For these reasons, the first type of information that needs to be negotiated at all is the type and version of supported E2NP, if any. The SM has to encapsulate the protocols being used and provide a dedicated API for them. For instance, this might be accomplished by using a directory server. As an example, a directory entry associated with a given peer, and named “E2NP/E2RP”, would act as a token indicating that the given peer supports the E2NP/E2RP. The directory entry could look like: E2NP = ( type of service, protocol to be used, version number) where “type of service” could indicate information retrieval service or conversational service, “protocol” could indicate SIP (together with SDP) or H.323 or RTSP (i.e. which protocol is the given E2ENP based upon), and “version number” could be a number discriminating incremental sets of functionality. This information can be not only directly queried on purpose by the peers, but the directory servers themselves can also pro-actively disseminate it, by using SAP [Handl00] extension. In addition to the aforementioned protocols, specific extensions are needed to carry out the negotiation and describe the Adaptation Path. As an example, the E2NP/E2RP can be mapped - based on the type of service - to the following protocols: Type of Service Conversational services Distribution services Audio/Video on Demand (Push/Pull mode)

Protocols SIP/H.323 + enhancements SAP + RTSP/SIP + enhancements RTSP + enhancements

Similarly, application (rather the SM) could also use CORBA or RMI/RPC mechanisms, thus reducing the development time of the SM. All three modes could be advantageously handled by a Session Manager component, transparently to applications using it. 2.6.4.2 Capabilities

Various types of capabilities might need to be negotiated among peers: •

Media Types and QoS Contract Dimensions

•

Bitrates

•

Codecs

•

Terminal capabilities

•

Network Resource Reservation support

The following paragraphs analyse in detail each type of capabilities.


81 / 229


2.6.4.2.1

Draft / 06.02

29.3.2001

Media Types and QoS Contract Dimensions

The type of media can be used to screen following information in the E2NP messages. In addition, the peers may agree on a common set of media types. As an example, if a receiver requests an audio stream and the sender does not have a microphone, further negotiation of audio codecs can be skipped. This translates in structuring the messages in a format, which is convenient for the peers while negotiating. In addition to media type, we have to include the list of QoS Contract Dimensions, which the contracts are made of. As an example, one peer might want to negotiate frame rate and frame size whereas other peer may want to negotiate frame rate only. As an example, it might be useless to try to negotiate frame size, if the VoD server has only one representation of the movie and there is no network media adaptation unit available. For instance, media types could be one or more of the following: mediaType = (audio(param_audio), video(param_video)) The refinements param_audio and param_video detail the QoS contract dimensions, like frame size, frame rate for video and sampling frequency and number of channels for audio are described in the next sections. This format is to be applied to each media type description in a given E2ENP message. 2.6.4.2.2

Codecs

Before peers can negotiate QoS contracts or even Adaptation Paths (see below), they shall agree first, on which codecs are generally applicable. In fact, even though a given peer might be equipped with a given set of codecs, their use is actually constrained by the availability of similar codecs by all the other peers. Today’s SIP implementations allow the negotiation of codecs at invitation time on a peer-to-peer basis, and with respect to the specification of well-defined streams. We hereby propose an extension of such SIP capability, by negotiating during step (1) described in § 2.6.3 - the complete list of available codecs, irrespective of which streams will use them later at stream establishment time. In other words, peers can in this way agree on a common subset of codecs before the actual media specification takes place. Furthermore, since current and future terminal devices shall be able to install or remove codecs on the fly, the common set of codecs might need to be later renegotiated, during connection time (e.g. in the midst of a videoconference). This could be achieved by using new SIP messages [Marsh00]. See during step (4) described in § 2.6.3). 2.6.4.2.3

Bitrates

Two main mechanisms are employed by clients to minimise the amount of bandwidth used for multimedia applications: using low (constant) bitrate codec thus reducing network resource consumption using variable bitrate codecs According to § 2.6.4.2.2, clients have to agree on a certain set of compatible codecs. We must however make sure, that the bitrate that the codec generates, can be supported both by the clients (for sending/receiving) and by the network (both the access networks and the core). In addition, one codec may generate different bitrate levels, which depends on the codec configuration. As an example, the G.726 codec may generate bitrates of 16, 24, 23 or 40 kb/s. There may be situations, where the receiver is able to handle only a


82 / 229


Draft / 06.02

29.3.2001

certain configuration of the given codec. As an example, if the receiver uses a 19.6 kb/s modem, the receiver can only handle the 16 kb/s configuration of the G.726 codec. In addition, certain audio codecs and several video codecs can generate a variable bitrate, which is typically specified using a leaky bucket model. Here, the bitrate requirements are specified using a sustainable bitrate, a peak bitrate and a burst time (duration that indicates how long the source is allowed to send at the peak rate). This invention proposes that in addition to a negotiation of the set of compatible codecs, for each codec the peers have to agree on a valid codec configuration in terms of bandwidth that each peer can handle. We propose that the initiator provides and negotiates with the peers a set of bandwidth specifications using the leaky bucket model (sustainable bitrate, peak bitrate, and burst time), which supports both constant and variable bitrates. In the above example, both parties would agree on the G.726 codec with the following bitrate specification: (sustainable bitrate, peak bitrate, burst time) = (16, 16, N/A). Having agreed on a compatible codec configuration in terms of bitrates, actual target bitrates that are being used in the actual configuration are negotiated with the network during step (3) (see § 2.6.3). 2.6.4.2.4

Terminal capabilities

The physical characteristics (e.g. monitor size) of terminal devices may change from model to model, and affect the delivery of services over telecommunication networks. This is important, as it makes no sense to stream a video in HDTV quality to a mobile phone that has only black and white display at QCIF size. Therefore, peers have to agree on terminal capabilities when negotiating QoS. Such terminal capabilities are the size of the display, the number of colours available, the general capabilities of rendering a given media type (e.g. is an audio mixer available?), and all kind of static information for services that are necessary for rendering a given media type. To this extent, the Composite Capabilities/Preference Profiles [CC/PP] framework language (XML combined with RDF) and request/response HTTP protocol offers today a handy way for specifying terminal capabilities in an RDF format. 2.6.4.2.5

Network Resource Reservation support

It is useless to try to demand network resources End-to-End using a signalling protocol like RSVP, if it can be determined a priori that one or multiple remote peers are not RSVP aware. To this extent, a possible solution is to ask peers to check if the given signalling protocol is available there. Another lighter solution is similar to the one proposed in [Marsh00]: during prenegotiation, peers exchange the information about the direction along with they are going to reserve network resources. Allowable values are N/A, sender, receiver, sender/receiver, where the concepts of sender and receiver relate to the resource reservation protocol used (if any). This information can in fact model the type of reservation protocol used, if any. For instance, in a simple Video on the Demand service scenario where RSVP is available End-to-End, the client acts as a receiver, whereas the server acts as a sender, since RSVP is a receiver-initiated. In case of Yessir [Pan99], which is sender-initiated, the configuration - from a resource reservation protocol perspective - would be the opposite.


83 / 229


Draft / 06.02

29.3.2001

Similarly, in a videoconference scenario with End-to-End RSVP support, each peer would be configured as a sender/receiver24. If no direction is specified for a given peer, the corresponding peers can immediately deduce that no network resource reservation mechanism is available on the given peer. The key point is that this model allows to cope also with cases where no QoS signalling protocol (like RSVP) is available End-to-End. In such a case, each peer would be simply modelled as a sender (or nothing at all). 2.6.4.3 QoS Contract

In the context of this section, QoS are defined as sets of application-level QoS characteristics, each expressed in terms any of the following (see Appendix E): • • •

Operating target: the desired value Operating region: a desired interval of values Thresholds/limits: a set of values marking different states with respect to the QoS adaptation business logic.

Any of the aforementioned QoS specifications could also be expressed in statistical format, by e.g. stating percentiles, mean value, variance, etc [Frolu98], but we do not consider such formats in this document. Rather, we use the type of QoS Contracts described in § 2.4.5, where the aforementioned operating target/region/thresholds can be easily modelled by assigning proper values to each tuple of the QoS Contracts described in § 2.4.5. 2.6.4.4 Adaptation Path

Peers can agree not only on a given QoS Contract, but also on alternative ones, which can be advantageously used whenever the network and/or terminal resources availability change over time. In such a way, each peer will exactly know which alternative QoS Contract (and under which circumstances) shall be enforced in order to cope with a critical QoS Change or with any QoS Violation with respect to the currently enforced QoS Contract. During the step (1) indicated in § 2.6.3, only flow-related Adaptation Paths (see § 2.4.7) are pre-negotiated. Higher level ones (associated with QoS Correlation issues) shall be negotiated at higher level at step (2). Together with the best-case QoS contract, the Adaptation Path forms an extended QoS contract (see § 2.4.5). Each QoS Contract contained in such extended QoS Contract is negotiated and indexed. If a peer later decides to switch to a lower level of QoS, only the index identifying the QoS Contract (i.e. the QoS State, as described in § 2.4.7.2.7) is needed to tell the other peer to adapt to that QoS State. The need for negotiating full-blown Adaptation Paths, rather than simply the list of codecs (as it is done today in common session protocols, e.g. SIP), stems from the fact that especially with video codecs it may not always be possible to implicitly derive network QoS requirements (e.g. bandwidth) from the simple knowledge of the codec type. Furthermore, Adaptation Paths can be used for pre-negotiating constraints 24

This is true if the peer would like to participate actively in the conference (i.e. by both sending and receiving simultaneously). If a client were only receiving a media stream (e.g. student in a remote lecture scenario) it would be configured as the client that acts as a receiver of a VoD session. If a client is only sending a media stream in the conference (i.e. lecturer in a remote lecture scenario) it would be configured as the server that acts as a sender of a VoD session. In any case, the type of resource reservation protocol used determines whether each peer is able to initiate a resource reservation (thus acting as a sender) or respond to one of these (thus acting as a receiver).


84 / 229


Draft / 06.02

29.3.2001

affecting the use of terminal resources other than codecs: such resources can in fact impose restrictions on the use of codecs. For instance, even though peers may agree on using MPEG-4 codec, it may end up that video grabber/player devices might not be able to handle high data rates. 2.6.5

Types of E2NP

The actors participating to communication sessions can act roles like: •

Sender/Receiver: the Sender can be solely transmitting data to a Receiver, whereas a Receiver receives data from a sender. A two-way conference can be modelled with a sender/receiver and receiver/sender pair.

•

Initiator/Responder: the initiator invites responders to participate communication session. The responder waits for a request from the initiator.

to

a

Possible combinations are: • •

Initiator and Sender -> Responder and Receiver Initiator and Receiver -> Responder and Sender

In the case where the initiator is the receiver, the receiver of a media stream initiates the session (the receiver invites and the sender waits to be contacted). In the case where the initiator is the sender, the sender of a media stream initiates the session (the sender invites and the receiver waits to be contacted). An Initiator/Sender can talk with a Responder/Receiver. An Initiator/Receiver can talk with a Responder/Sender. According to the ISO QoS Framework (see Appendix E), following are listed the key scenarios affecting the type of E2NP that needs to be used within the BRAIN context. •

Peer-to-Peer negotiation: can be actually extended also to multiple peers participating to e.g. a videoconference, but where each peering is regulated by a direct peer-to-peer QoS negotiation mechanism.

•

1xN Multicast negotiation: in this case, a sender and multiple receivers need to negotiate one or multiple QoS characteristics at a time. This can be done either on a connection-wide basis (i.e. determining a least common denominator good for all peers) or on a receiver-selected basis (peer-to-peer negotiation for some QoS characteristics among certain peers - see previous point). Should an E2NP be chosen on a connection-wide basis, the mechanisms described in Appendix E shall be taken into account. In case of a best effort level of agreement, receivers can still be used even if they cannot agree on a least common QoS level, otherwise (e.g. in case of a guaranteed QoS policy), those receivers must be dropped or other mechanisms have to be used. As an example, media filters or transcoders can be used in between a sender and a receiver to tailor media streams in such a way, that receivers’ capabilities and QoS states can be matched with senders’ QoS states. The media transcoder can be used to translate from one representation to another (e.g. switching the codec of the media stream from PCM to GSM audio). Media filters can be used for finer granular adaptation of media qualities (e.g. adapting to frame size, frame rate or desired quality without forcing the sender to adapt). For more information on media filtering/transcoding, see [Kassl99] The connection-wide E2NP can be effectively used for enforcing QoS Correlation (see § 2.4.7) among multiple flows from various sources. The 1xN Multicast


85 / 229


Draft / 06.02

29.3.2001

negotiation may in fact be used for determining the common QoS not only for downstream flows (i.e. from the unique sender to multiple receivers), but also for the opposite direction25. This means that the sender can eventually correlate the QoS of incoming flows from all of its receivers. Actually, the ISO QoS Framework deals with 3-party negotiation, involving an initiator, a provider, and one or multiple responders. In this section we limit our scope however to the relationship between an initiator/provider and one or multiple responders. The choice of not involving explicitly a provider is due to the fact that only end-terminals, without the support from any communication network element, shall be able to enforce the hereby-proposed E2NP. This restriction stems from the heterogeneous nature of the Internet, and to the need to provide a feasible solution in the short term. In any case, during the pre-negotiation phase, each peer assesses the bids received from other peers against pre-configured User-Profiles (see §§ 2.4.7 and 2.4.8), which contain pre-computed Adaptation Paths, similarly to what described in [Ott99]. The assessment can be achieved by comparing each parameters of each QoS contract provided in the bid, with the corresponding information contained in said User Profiles. In any case, the decision whether to accept a bid or formulate a counteroffer is made, by taking into accounts all the QoS dimensions of the QoS contracts. The initiator associates each QoS Contract of its bid with an identifier. Responders will notify the acceptance of a given QoS Contract (or the proposal for an update thereof, as a counteroffer), by specifying the corresponding identifier. Should a responder feature a better QoS Contract resolution (i.e. in the case of a given QoS Contract in the bid, in correspondence to which multiple QoS Contracts with “finer” granularity are available at one of the Responders), said responder may return a counteroffer with new QoS Contracts. It is up to the initiator to collect these counteroffers, choose the most meaningful ones, associate them with new identifiers, and propose them to all peers in a new negotiation round. 2.6.6

Mapping between Type of Service and Type of E2NP/E2RP

The following paragraphs describe how E2NP/E2RP can be deployed with respect to the various types of services mentioned in § 2.6.2. 2.6.6.1 Conversational Services

This is the case of services like real-time videoconference or CSCW. The key characteristic of these services is that the type of content exchanged among peers is most likely based on user interactions with the systems and with other peers. For instance, most of video flows will carry live images (e.g. taken from a web-cam). Another important aspect is that peers need to agree beforehand on a given agenda, which includes the start-time and duration of the service. This is typically accomplished by using SIP, in the Internet world. How this type of services is actually deployed, is highly implementation dependent. Taking as an example a videoconference, special bridges are used in the telecom world so as to offer a star topology solution. Any interested party can thus join a videoconference by simply contacting the bridge. In the Internet world, on the other hand, it is common the use of multicast technology: any interested party would simply have to “tune” on the proper multicast group. 25

Although normally peer-to-peer negotiations are used for the upstream flows, if any.


86 / 229


Draft / 06.02

29.3.2001

From an E2NP perspective, however, we hereby assume that peers shall use unicast signalling for negotiating a common level of QoS. Conversational services can be modelled as cases of one Initiator and multiple Responders, where all peers can act as Sender and/or Receiver, according to §2.6.5. Furthermore, from a resource reservation protocol perspective (see § 2.6.4.2.5), each party can use either a sender-driven or a receiver-driven network resource reservation protocol (if any). Thus, an Initiator requests some resources from the network and from a Responder (since the Responder has to provide the resources for decoding and displaying). In addition, the Initiator manages its own resources locally. 2.6.6.2 Distribution Services

Distribution services can involve a content provider and (i) known or (ii) unknown content consumers. In the former case, SIP or RTSP extension might be used similarly to the case of information retrieval services, in the latter case RTSP extensions are envisioned. The sender shall simply announce the list of multicast groups, which the receivers may choose from for “tuning” on the current content distribution. Except for the quite unusual case of known content consumers, only a reduced version of E2NP/E2RP can be mapped to SAP. The Adaptation Path can be simply modelled as having the content provider streaming the same content with different QoS levels to different multicast groups (one per QoS level). Content consumers shall therefore simply monitor the level of QoS available at their terminal/access network, and eventually tune on another multicast group if any QoS Change or QoS Violation occurs in the meanwhile. Alternatively, the full-blown E2NP/E2RP could be used in conjunction with media filter/transcoder in the network, tailoring the media streams to match the different QoS levels. To this extent, the content consumers should simply instruct the media transcoders/filters to switch to a new QoS level. It is up to the content provider and to the receivers’ media handlers to ensure that the streams distributed on different multicast groups are mutually synchronised. For optimisation purposes, the sender may however collect statistics concerning the number of receivers per multicast group (channel), so as to avoid flooding the network with packets of unused channels. This requires some signalling between the content provider and each content consumer. This document however does not address such special case. 2.6.6.3 Information Retrieval Services

This type of services is typically managed by using RTSP protocol [Schulz98]. Enhancements of such protocol for achieving E2NP/E2RP goals are envisioned, similarly to what described for the case of conversational services. QoS Correlation features can also be achieved by using SMIL [SMIL98]. This section does not address the integration of such technology. 2.6.7

End-to-End Re-negotiation Protocol (E2RP)

The E2RP is the subset of the E2NP focusing on re-negotiation issues. Possible causes for E2RP to occur are:


87 / 229


Draft / 06.02

29.3.2001

1. QoS Violation detected at an arbitrary component; or 2. the current monitored level of QoS is no longer compatible with the currently enforced QoS Contract [Bhatt99]; or 3. a notification of newly discovered additional resources has been received by some specific functionality (e.g. more CPU becomes available because some media processing chains ceased to exist, hand-over to an access network that offers more resources…); or 4. one of the peers decided to enforce a different QoS Contract (e.g. the user requested a higher frame rate). Cases 2 and 3 are mostly related to optimisation processes, which allow applications to upgrade/degrade their QoS requirements in a smooth manner, whereas case 1 deals with dramatic shortages of resources, which badly affect applications, if not properly and promptly treated. To this extent, case 1 implies renegotiating resources without the need to try to maintain the previously reserved resources26, whereas this is not possible in cases 2 and 3. This means that whenever dealing with optimisation issues, one has to take care of: •

either allocating resources in excess of the difference between the previously allocated resources and the new amount (in the case of QoS upgrade);

•

or allocating the new resources from the scratch, while keeping the old ones until the re-negotiation has been successfully completed (pessimistic approach). This can also be modelled as trying to allocate more resources while still keeping the old one. If this fails, one has still the old ones; otherwise one has more resources available.

•

releasing some resources to switch to a lower QoS state (in the case of QoS downgrade);

The first option seems to be quite attractive, but some resources might not be easily shared among different QoS States. For example, the scheduling information about the thread of a given codec might be totally useless, if said codec is going to be pre-empted and substituted with another one, which runs on a totally different thread. Therefore the second approach, though pessimistic, seems to be the most realistic one. In the following we will therefore refer explicitly to the allocation of new resources and later release of old ones. In addition, releasing resources is always possible, because the system load is decreased. Whenever a re-negotiation is triggered each peer determines from the pre-negotiated Adaptation Path the best alternative QoS Contract that should be enforced in order to cope with the detected QoS Change/Violation. The identity of the new QoS Contract is exchanged among peers, in order to come to an agreement on which QoS Contract should be actually enforced. Having previously negotiated the Adaptation Path allows the peers to more efficiently perform such renegotiating, by simply exchanging said identifiers. Should all peers detect a violation simultaneously, some form of contention resolution algorithm would need to be enforced. To this extent different well-known techniques are available: assigning master/slave roles (typically assigning to the Initiator the master role), or re-attempting after a random time has elapsed. The E2NP/E2RP leverages the master/slave role, similarly to what is done in [Marsh00]. 26

This deliverable however does not enter into more details concerning network resources reservation strategies, being these totally masked by the ESI.


88 / 229


Draft / 06.02

29.3.2001

To sum up, three types of re-negotiation are possible: a) one triggered by a QoS violation detection, where new resources are allocated from the scratch and the old ones are automatically released (for QoS downgrade cases, this might be not an issue); b) one dealing with optimisation issues, where new resources are allocated from the scratch and the old ones are released later, at E2RP successful completion; and c) one dealing with optimisation issues, where new resources are allocated from the scratch and the old ones are automatically released. 2.6.8

Guidelines for E2NP/E2RP Specification

Current work in the IETF Multiparty Multimedia Session Control (mmusic: http://www.ietf.org/html.charters/mmusic-charter.html) is focusing on new ideas concerning capability description language, abbreviated format for a composite media feature set, and negotiation for conversational services (including the aforementioned [Marsh00]). All the IETF proposals relate very much to the ideas set forth in this section, but they analyse individual aspects, whereas the section tries to combine these bits together, so as to address the overall picture of End-to-End QoS (re)negotiation protocol. Even though the full specification of the E2NP/E2RP is out of the scope of this document, some features of such protocol can be already identified as follows: •

The aforementioned Capabilities, QoS Contracts, and Adaptation Paths should be modelled by using SDP [Handl98], so as to ease the mapping of E2NP/E2RP to SIP, SAP, and RTSP.

•

The pre-negotiation phase can take care of managing a limited number of iterations, taking into account peers’ counteroffers.

•

Eventually, the pre-negotiation phase (i.e. the step (1) indicated in § 2.6.3) can be totally implemented in SAP.

•

In the case of information retrieval services, QoS Correlation features may be achieved for example by using SMIL [SMIL98].

•

Resources should be reserved following this order: in the end-terminals first, and then in the network. This because the most contended and expensive resources are the network ones27.

•

Additional messages for the addressing: A. QoS Contract negotiation (by using the identifiers associated with the prenegotiated QoS Contracts of the Adaptation Path), and B. co-ordination of network resource reservation (if any) among peers, are envisioned for SIP [Marsh00], RTSP, and SAP.

•

27

Capabilities may be installed/de-installed even at runtime: to this extent, asynchronous messages may be exchanged among peers for notifying such events. In a Video on Demand scenario, it is reasonable to assume that clients first try to reserve resources in their own terminals, then request the video server to reserve resources for them, and finally co-operate with said server so as to reserve network resources (either end-to-end, or in the access network only).


89 / 229


Draft / 06.02

29.3.2001

The motivation for doing this lies on the fact that some peers may be willing to upgrade QoS as soon as detect that the other peers are also equipped with the some high performance capabilities28. •

During runtime of a so established multimedia session, at any time any component may request an adaptation. This again requires co-ordination of local, remote and network resource management. When performing this adaptation, user defined or provided preferences can be used implicitly by following the pre-negotiated adaptation path.

2.7 Discussion Current standardisation efforts like the ETSI [X641R98] and the ITU-T | ISO/IEC [X641R98] QoS Frameworks offer basic foundations upon which other standards or architectures targeting QoS can be derived. A detailed comparison of some of the wellknown QoS frameworks and architectures available as of this writing can be found [Aurre98]. On the other hand, as pointed out in [Aurre98], most of the state of the art frameworks and architectures do not capture the overall aspects of QoS. To this extent, a set of principles and basic concepts have been abstracted out and organised in a Generalised QoS Framework. This framework can be used for evaluating the existing state of the art. For instance, the ITU-T | ISO/IEC QoS Framework only mentions QoS Mapping issues and totally ignores (excepts for some mentions about filters and buffering mechanisms) the QoS Control Mechanisms described in § 2.3.2.2. Furthermore, the ITU-T | ISO/IEC approach neither takes into account monitoring and warning management with respect to QoS Availability and QoS Degradation, nor QoS maintenance issues regarding QoS Renegotiation and QoS Scaling (see § 2.3.2.3). Nevertheless, the combination of the Generalised QoS Framework abstract concept and the general concepts offered by the aforementioned ETSI and the ITU-T | ISO/IEC QoS Frameworks constitute a powerful tool for guiding the design of BRAIN’s own QoS architecture, as well as for defining a conformance framework thereof. Based on this assumption, in this section we have then presented a set of additional design principles and basic models, which try to address the original goals of this document within the context of a BRAIN QoS Framework. The next section addresses implementation issues with respect to most of the functionality of such framework, by introducing BRENTA. 2.8 References [Akao90] [Aurre98]

[Bhatt99]

28

Y. Akao, Quality Function Deployment QFD: integrating Customer Requirements into Product Design, Productivity Press, Cambridge MA, 1990. C. Aurrecoechea, A. T. Campbell, L. Hauw, “A Survey of QoS Architectures”, ACM/Springer Verlag Multimedia Systems Journal , Special Issue on QoS Architecture, Vol. 6 No. 3, pg. 138-151, May 1998 [Castl98] B. Castle, “QoS in ETSI TIPHON and the Internet”, (http://www.eurescom.de/~public-seminars/1998/QUTE98/09Castle/sld001.htm). S. Bhatti, G.Knight, “Enabling QoS adaptation decisions for Internet applications”, London, UK, 1999.

E.g. a Video on Demand client may have both an MPEG-2 and an MPEG-4 codecs available, whereas the server has only an MPEG-2 codec: therefore the peers can agree upon using MPEG-2 only. Should later the server be upgraded with an MPEG-4 codec, it would make sense to inform the client.


90 / 229

Del 1.2 Draft v6.03.doc [Blake98] [Booch99] [CC/PP99a] [CC/PP99b] [Delgr94] [D.2.2] [Frolu98] [Fry97] [Handl98] [Handl99] [Handl00] [Kassl99] [Kassl00]

[Kicza97] [Koist98] [ISOX641] [LDAP95a] [LDAP97] [LDAP95b] [Li98] [Loyal] [Marsh00] [Nahr95] [Ott99] [Pan99] [RDF99a] [RDF99b] [Shulz98] [SMIL98]

Draft / 06.02

29.3.2001

S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture for Differentiated Services“, IETF Request for Comments: 2475, December 1998. G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, Addison Wesley Longman, 1999. W3C, “Composite Capability/Preference Profiles: A user side framework for content negotiation”, W3C Note 27 July 1999, (http://www.w3.org/TR/NOTE-CCPP/). W3C, “CC/PP Exchange Protocol based on HTTP Extension Framework”, W3C Note 24 June 1999, (http://www.w3.org/TR/NOTE-CCPPexchange/). L.Delgrossi, C.Halstrick, D.Hehmann, R.Herrtwich, O.Krone, J.Sandvoss, and C.Vogt, "Media Scaling in a Multimedia Communication System", in ACM Multimedia Systems Journal, Vol. 2, No. 4, pp. 172-180, 1994. IST-1999-100050 BRAIN D.2.2. “BRAIN Architecture specifications and models, functionality and protocol specifications”, March 2001. S. Frolund, J. Koistinien, “QML: A Language for Quality of Service Specification”, HPLab Technical Reports, HPL-98-10, 980210 (http://www.hpl.hp.com/techreports/98/HPL98-10.html). M. Fry, “QoS management in a World Wide Web environment which supports continuous media “, in Distributed Systems Engineering, Vol. 4, pp. 38-47, 1997. M. Handley, V. Jacobson “SDP: Session Description Protocol“, IETF Request for Comments: 2327, April 1998. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, “SIP: Session Initiation Protocol“, IETF Request for Comments: 2543, March 1999. M. Handley, C. Perkins, E. Whelan, “Session Announcement Protocol “, IETF Request for Comments: 2974, October 2000. A. Kassler, P. Schulthess, “An End-to-End Quality of Service Management Architecture for Wireless ATM network”, in Proceedings of the HICSS 32, Mauii, Hawaii, USA, January 1999. A. Kassler, L. Burness, P. Khengar, E. Kovacs, D. Mandato, J. Manner, G. Neureiter, T. Robles, H. Velayos, “BRENTA - Supporting Mobility and Quality of Service for Adaptable Multimedia Communication”, in Proceeding of the IST Mobile Communications Summit 2000, Galway, Ireland, October 2000, pp. 403 - 408. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J. Loingtier, J. Irwin, “Aspect-Oriented Programming”, in ECOOP'97 proceedings, Finland, 1997. J. Koistinen, A. Seetharaman, "Worth Based Multi Category Quality Of Service Negotiation in Distributed Object Infrastructures", in HP Research Report HPL-98-51, 1998. ITU-T Recommendation X.641 (12/97) | ISO/IEC 13236:1998, Information technology Quality of Service: Framework. LDAP v2 specifications, 1995, IETF, RFC 1777 to 1779. LDAP v3 specifications, 1997, IETF, RFC 2251 to 2256. H. Alverstrand, “Tags for the Identification of Languages”, IETF, RFC 1766, March 1995. B. Li, K. Nahrstedt,"A Control Theoretical Model for Quality of Service Adaptations", in Proceedings of Sixth International Workshop on Quality of Service (IWQoS 98), pp. 127136, May 1998. J. P. Loyall et al., “QoS Aspect Languages and their Runtime Integration”, in Lecture Notes in Computer Science, Vol. 1511, Springer-Verlag. W.Marshall et al., “SIP Extensions for Resource Management”, IETF draft , November 2000. K. Nahrstedt, J. M. Smith, “The QoS Broker”, IEEE Multimedia Magazine, Spring 1995 (2)1, pp. 53-67. J. Ott et. al., “Capability description for group cooperation”, IETF Internet-Draft, Work-inprogress, . P. Pan, H. Schulzrinne, “YESSIR: A Simple Reservation Mechanism for the Internet”, Computer Communications Review (CCR), Vol. 29, No. 2, pp. 89-101, April 1999. W3C, “Resource Description Framework (RDF) Model and Syntax Specification”, W3C Recommendation 22 February 1999, (http://www.w3.org/TR/REC-rdf-syntax/) W3C, “Resource Description Framework (RDF) Schema Specification”, W3C Candidate Recommendation 27 March 2000, (http://www.w3.org/TR/rdf-schema/) H. Schulzrinne, A. Rao, R. Lanphier, “Real Time Streaming Protocol (RTSP)“, IETF Request for Comments: 2326, April 1998. Synchronized Multimedia Integration Language (SMIL) 1.0 Specification, W3C Recommendation, 15-June-1998.


91 / 229


Draft / 06.02

29.3.2001

[Vogel95]

A.Vogel et al., “Distributed Multimedia and QoS: A survey”, in: IEEE Multimedia, Vol.2, No. 2, 1995, pp.10-19. [X641R98] ITU-T Recommendation X.641 (12/97) | ISO/IEC 13236:1998, “Information technology Quality of Service: Framework”. [WAP99a] WAP Forum, Wireless Application Group “User Agent Profile Specification” (WAG UAPROF), Proposed version 0.6, 22 June 1999. URL: http://www.wapforum.org/ (registration required). [WAP99b] W3C & WAP Forum, “WAP Binary XML Content Format”, W3C Note 24 June 1999, (http://www.w3.org/TR/wbxml)


92 / 229


3.

Draft / 06.02

29.3.2001

The BRAIN End Terminal Architecture (BRENTA)

The goal of the BRENTA is to allow any kind of application to get the desired level of support from a given system communicating over open environments like the Internet. For dedicated applications, BRENTA will provide mechanisms for: •

Local resource management Local resource management is necessary for providing more predictable QoS. Without local resource management, applications run locally only in a best effort mode. As an example consider a VoD application that wants to retrieve a video stream at 25 fps. If not enough CPU resources are available locally for decoding and displaying the stream at this frame rate, it makes no sense to request 25 fps from the server.

•

Network resource management Network resource management is necessary to provide bandwidth guarantees to services and applications. Since native BRAIN will use the HIPERLAN/2 wireless access technology, bandwidth can be reserved from the air interfaces, which is important for mission critical applications. The management of network resources is achieved through the ESI, as provided by the BRAIN access network [D.2.2]. Remote resource reservation assures that the necessary resources are also available at the remote communication partner. This will be negotiated using dedicated protocols like SIP/SDP or custom mechanisms based on CORBA for component based architectures.

•

QoS orchestration QoS orchestration mechanisms manage and co-ordinate local, remote and network resources in order to provide predictable End-to-End QoS.

•

Support for Mobility BRENTA uses a QoS- and Mobility-enhanced transport service interface (ESI) for accessing network QoS-related services. However BRENTA can explicitly influence Mobility through the Local Management Interface [D.2.2].

•

Support for adaptation mechanisms and policies Support for adaptation mechanisms and policies are provided by BRENTA on behalf of applications. The reason to provide adaptation mechanisms was the question, why applications always try to re-invent the wheel. This becomes evident when looking at VoIP applications, where each treats QoS violations in its own way. BRENTA provides mechanisms to adapt “transparently” on behalf of applications. The specifics of how the adaptation should be performed can be specified via adaptation policies.

•

Support for personal user QoS profiles and VTS Support for VTS selection will be provided together with user QoS policies that let the user specify degradation paths in case less or more resources become available.

•

Support for legacy applications


93 / 229


Draft / 06.02

29.3.2001

All legacy applications (like email, ftp, web-browsing…) have to be supported in order to render BRENTA an open architecture. Optionally, legacy applications can be associated with some QoS provisioning functionality (via a configurator), acting on the application’s flow transparently to applications. In such a way, one may retrofit otherwise QoS-unaware legacy applications with some degree of QoS-awareness (though no application adaptation in front of QoS changes/violations is guaranteed). •

Support for emerging component based applications We foresee that in the future more and more component based (CORBA, Java Enterprise Beans, DCOM…) applications architectures will be utilises that will ultimately result in a reduction in the development time of increasingly sophisticated applications and services. BRENTA also provide solutions for supporting these component-based applications architectures.

Key requirements for BRENTA are (i) modularity, (ii) openness and (iii) configurability/flexibility. Modularity guarantees that existing applications can be immediately ”plugged in”, whereas more complex middleware solutions can be gracefully introduced later, as soon as they become available. Openness further broadens the scope of the proposed architecture, taking into account interoperability issues with other architectural solutions (e.g. active networks). Flexibility is needed to cope with different media types by, e.g. supporting downloadable codecs. In addition, the interfaces have to be well defined and standardised so that QoS enabling components may enhance the system by downloading them from a server at runtime. 3.1 The BRENTA Layered Architecture The BRENTA architecture operates in two major planes (see Figure 3.1): the (usual) networking plane, and the QoS and resource management plane. The QoS management aspect of the latter is actually optional, insofar as some dedicated services and applications may request QoS management from BRENTA (type D applications, see below), whereas other applications may want to manage QoS by their own. Applications and services in BRENTA will interface with a QoS- and mobility-aware protocol stack (networking plane) through a set of interfaces, each addressing a specific type of application, as described below. Legacy applications (type A) access IP services by directly interacting with the classical (neither QoS- nor mobility-aware) transport layer (Application Programmer Interface API - 0). Such applications may eventually use the services provided by an Enhanced Socket Interface (API A), which allows separating BRENTA from a specific network implementation. Type B applications may use various session layer protocols (e.g. H.323, SIP) across the API B. These protocols may be even partly embedded into the applications. Since type B applications directly have to manage QoS and mobility related issues by themselves, they only use standard IETF protocols enhanced by some mobility related functionality. Type C applications incorporate the functionality provided by a component level API (denoted as API C). The API has to provide specific multimedia components like frame grabbers, codecs, packetizers, renderers that can be combined together on a per flow basis, based on applications requirements. IETF protocols can also be encapsulated in components to provide compatibility and flexibility. That is, type C applications would use a session manager that could be based on SIP or H.323 transparently to the applications. In addition, API C provides components that deal with local resource CEC Deliverable Number 1.2

94 / 229


Draft / 06.02

29.3.2001

management. Furthermore, this API allows dynamic downloading of key components for updating codecs or protocol objects, for example. In any case, the built-in intelligence that adapts and reacts to QoS violations still has to be implemented inside the application. Finally, type D applications will totally rely on an external entity, which we call the QoS Broker (either as an API C component or transparently via an high-level API D), for managing local and remote resources, so as to re-act to QoS violations and mobility specific events, based on user or application supplied policies via user QoS profiles. Type D Applications may even be XML-based applications, which interpret XMLbased documents (e.g. SMIL), which describe the presentation and QoS aspects in a declarative manner.

Figure 3.1: The BRAIN End-System layered Terminal Architecture (BRENTA)

In order to support all the different types of applications described above (i.e. type A, B, C and D), a variety of components must be identified, including a set of APIs as well as end-system mechanisms, and protocols coping with the dynamic variation in mobility management and QoS. BRENTA will provide applications with more predictable services and allow applications to react in a pre-determined way to QoS violations. Premium services will be available in hot spot areas with maximum quality, depending on user policies. When moving out of those areas, the user expects a controlled and predictable degradation of


95 / 229


Draft / 06.02

29.3.2001

the QoS, if s/he is operating a dual-mode terminal. However the user may control the degradation by specifying a set of high-level QoS parameters and policies for each service s/he subscribed. These parameters are the main input for tuning the BRAIN QoS architecture. The architecture specifies how these parameters are mapped to application and network specific QoS parameters, providing End-to-End QoS. To achieve user expectations, co-operation is needed between the application providing the services, the operating system managing local resources and the network elements including the BRAIN mobile terminal. BRENTA is designed using IETF protocols and custom components as building blocks. Due to the open architecture and the component model used, future emerging IETF protocols providing support for mobility and QoS may easily be integrated. The rest of this section details the BRENTA architecture by following a bottom-up approach, i.e. by starting from the ESI up to the Interface Type D. This choice which at first may appear to be in conflict with BRAIN’s top-down approach, is motivated by the need to induce new concepts gradually, according to the aforementioned BRENTA step-wise approach to various types of applications. 3.2 The Extended Socket Interface Applications should be able to request a certain QoS level for their network operations. In that sense, BRAIN has to provide an interface for applications and services to request a certain QoS at network level (Figure 3.2). To this extent, BRAIN provides a QoS supporting transport service interface which provides not only the standard transport primitives (like open, close, listen, connect) but also additional primitives that give applications the facility to enable QoS [D.2.2]. Application can thus be implemented against this QoS supporting transport service interface (in the following Enhanced Socket Interface, ESI), which also hides mobility related aspects. In addition of supporting legacy applications, the ESI provides the lowlevel functionality for BRENTA’s networking plane. The basic functionality of the ESI is to send and receive data units to/from the remote host with optional QoS guarantees. Legacy applications would use standard send/receive calls whereas the QoS-aware applications use the ESI, which provides mechanisms for requesting, renegotiating and releasing QoS, i.e. resources within the mobile terminal stack and inside the network. The ESI, by design, is a generic interface, independent of any platform, QoS mechanisms provided in the network, or end-system and is independent of a given transport service provider implementation. Below the ESI, a BRAIN specific service interface (Brain Service Interface, Brain SI) is used to request services from a BRAIN specific transport provider and the QoS Service Provider. Some parts of the mechanisms that are necessary to deal with vertical hand-offs are located below the IP-layer. For example, in the figure bellow, for UMTS the PHY, DLC and Convergence layers denote these. In addition, an Enhanced Socket Layer (ESL) provides QoS-parameter and primitive mapping functionality. The QoS Mapper has to translate a generic QoS specification from the ESI to/from a given QoS specification, which the lower SI is able to understand (this means to translate ESI QoS specifications to parameters that the BRAIN-SI can handle). The Primitive Mapper translates ESI generic primitives to/from the corresponding implementation-dependent primitives provided by the underlying protocol stack, like the BRAIN SI ones.


96 / 229


Draft / 06.02

29.3.2001

Figure 3.2: Overall architecture of the ESI

In addition to these mechanisms, a Stack Manager besides the stack offers a Local Management Interface for allowing QoS-related configuration, which is necessary for supporting vertical-handoff29, and for selecting local traffic control functionality30. By using this local management entity, it is also possible to introduce QoS for legacy applications. As an example, this configurator could trigger the association of a certain DiffServ Codepoint (DSCP) with a dedicated flow (i.e. associate high priority and low packet dropping for all IP packets for port 80). The lower layers would recognise the request for premium service for the dedicated flow and could associate a dedicated HIPERLAN/2 channel for these packets. As an alternative, the configurator could initiate RSVP messages to setup resource reservation in the network transparently to the application for reserving e.g. 64 Kb/s peak, 32 Kb/s sustainable bandwidth for the downlink of an Internet connection at a maximum delay of 100 ms. Standard legacy applications (like Web-Browser or ftp client) could be enhanced to provide more predictable services without changing the application code. If no QoS is provisioned, the given legacy application will still be able to operate as usual, but without QoS support. 29

In the case AAA functionality is necessary.

30

E.g. influencing the classification, queuing and scheduling at the IP layer.


97 / 229


Draft / 06.02

29.3.2001

3.3 The Session Layer Protocols 3.3.1

Introduction

Session-layer (signalling) protocols are used for creating, modifying, monitoring and terminating sessions with one or more participants. These sessions include multimedia conferences and Internet telephone calls. The session layer protocols that monitor the progress of a session and data delivery are well understood and commonly used. It is assumed that real-time applications transport data using RTP, and use RTCP [Schulz96] to monitor the data transport. However, the protocols to initiate the session are less stable. Currently if two users wish to communicate using Internet Telephony, they typically phone each other on the public telephone network to alert each other to the fact that they want to have such a call and agree on technical details. A session initiation protocol should automate much of this procedure – by essentially deploying a daemon that listens in on a fixed port on the terminal to handle such requests. These protocols alert peer applications, and initiate the negotiation of media and their associated codecs, and also support multiparty calls. The application may use information about local resources and their knowledge of the network to agree on a description of the session. An example of this would be a terminal, which knows it has a wireless network connection or limited CPU resources free and may therefore suggest a low quality voice encoding. Once this agreement has been reached, the terminals may begin negotiation with the network if they need to reserve any resources - not all sessions will need network resource reservation. Should resource reservation fail, the session protocols can be used to attempt to find another suitable session description. Serious QoS violations can be identified by the receiver based i.e. on RTCP. The session initiation protocol then allows the terminals to change the session description to match the available resources. Ideally, the session protocols should give the sender sufficient information so that, should it detect a QoS violation, it knows how to adapt its data. The concepts described above could be applied to BRENTA type B application. Moreover, these concepts could be applied to a component-based architecture, as well as to type C and D applications. A second role of the session initiation protocols is to provide the mechanism by which users and terminals are located - a directory service. 3.3.2

The Session protocol layers

Based on the type of service mentioned in [D.1.1], several session protocol layers can be used as indicated in the table below. Type of Service Conversation service Distribution service Audio/Video on Demand (Push/Pull mode)

Protocols SIP/H.323 SAP + RTSP/SIP RTSP

In order to fulfil BRENTA session layer related function, these standardised protocols can be combined and enhanced (see § 2.6). In the following paragraphs, we focus on H.323 and SIP since these are two competitive technologies.


98 / 229


Draft / 06.02

29.3.2001

3.3.2.1 H.323

The H.323 protocol suite [H.323] contains a full session control protocol - it includes session initiation and data transport and session control functionality (the latter through RTP). This protocol suite was originally developed in the early 1990's and was focussed on video-conferencing. It is integrated into a number of applications including CUSeeMe Professional and Microsoft's Netmeeting. Although the latter is still not totally compliant with the standard, the two applications can now interwork. The current standards have a number of weaknesses however, making H.323 more suitable for LAN environments than the Internet. Full details can be found [Schulz], but one main point is the fact that it is a heavyweight protocol. For example, establishing a session using H.323 can take up to 7 round trips to establish. The signalling must be transported using (multiple) TCP connections, which is an unnecessary overhead for wireless applications and also complicates the implementation of firewalls. The whole specification is long and complex - which may be one reason for lack of compliance. It includes much functionality, which is available already through other Internet standards. In certain scenarios, it may also require states to be held throughout the network, thus being less suitable for wide area networks. Finally, user mobility can lead to routing loops. H.323 is still under development to tackle this criticism (which have typically originated from the SIP community). The next version 3 [Dalgi99] should include fast call set up, UDP signalling, and should solve the routing loops, but it is not yet available as a standard. There is some evidence that H.323 will eventually converge with its new rival, SIP, but convergence is slow. Whilst it is widely used in applications, there is less evidence of it being widely supported by network operators (the operator support is required for largescale networks and directory services). For example UMTS Release 4 and most PSTN gateways use the alternative SIP. 3.3.2.2 SIP

The Session Initiation Protocol (SIP) is a recent IETF development meant to be a general multimedia session initiation protocol. It is smaller than H.323. It is transport layer independent - most implementations use UDP transport. It is lightweight; for example it only requires 1.5 round trips to establish a session. When using UDP, it simplifies multicasting, which simplifies some applications. It is a text-based protocol, similar to HTTP and therefore it is easier to write and debug it. On the other end, it is less efficient than binary protocols. SIP also allows far more extensive error and status reports. SIP is almost invariably used to carry session description messages as defined by the session description protocol SDP [Handl98] but even this is flexible. To allow for fast adaptation several streams could be agreed upon in session initiation. As well as being a simple protocol, SIP is regarded as more general. For example it supports both distributed control and centralised bridge architectures for multiparty calls. 3.3.3

The implications for the BRAIN system

At the application layer, it is desirable to develop applications that are independent of the underlying technology. This implies the requirement to use an API that can be mapped to whichever session protocol layers are supported by the system. At the session layer, there is a need for both parties to use the same session initiation protocol. To achieve the full benefits of using session protocols, both parties need to be using network providers that use the same protocol31. Therefore, it is likely that a "BRAIN compliant terminal" will be based on SIP and provisions will be made for 31

Strictly speaking, any third party may provide SIP services, the client simply needs the address of the SIP server.


99 / 229


Draft / 06.02

29.3.2001

H.323, which will eventually be made operational through some interworking function32. 3.4 The BRAIN Component Level API Type C and D Applications are envisioned to leverage existing component-based architectures, in order to reuse any multimedia component available in the marketplace. In order to enforce the BRAIN mechanisms described in § 2.4, it is not sufficient to simply use existing architectures. i. To this extent, in this section we focus on the basic functions that we identified as necessary, in order to achieve the goals set forth in § 2.4. We present these functions as components themselves, so as they can fit whatever component architecture is actually being used. It should be noted, however, that these functions may be implemented in various ways (e.g. the Resource Controllers - see § 3.4.3.4.2 - may be implemented as modules linked with the OS; whereas the Media Handler - see § 3.4.3.2 - may be implemented as an independent daemon). 3.4.1

The Component Model

The Component model is based on interoperable units, each of them independent enough to be modified without harming the other components. Like all components, their specification is independent of the operating system on which they are implemented in order to create open BRENTA applications. The goal of the component model is to specify functionality of components that are necessary to provide E2E QoS, independent of the OS. Depending on the target platform some functionality may have to be implemented, or else wrappers may be deployed to provide access to the functionality provided by the OS itself. The goal of BRENTA is not only to be open, but also to be backward compatible with existing component solutions, by using well-defined interfaces against which adapters can be implemented. The components are all interrelated. The following figure illustrates the key elements of the BRAIN component level API. Three design patterns are used: •

Factory design patterns [Gamma94], where the Media Handler creates and manages a multiplicity of Chain Co-ordinators.

•

A component chain design pattern, where each Chain Coordinator handles a multiplicity of components (multimedia components or other supporting components). Each Chain Coordinator is associated with a given stream and handles communication through multiple flows by using an ESI socket per flow. The Chain Coordinator chains the components together in order to provide proper handling of the media depending on the type of the media (audio/video) and the level of QoS required. This kind of chaining can either be preprogrammed or directly steered by the applications.

•

Resource provider/consumer design pattern. Please refer to § 2.4.4 and 3.4.3.4.

In the following paragraphs, we also analyse the monitoring of QoS violations and resource usage by further detailing the architecture described above.

32

The mapping from SIP to H.323 is relatively easy and well [Singh00] (the converse is not true). SIP is considered a general, flexible, session initiation protocol.


100 / 229


Draft / 06.02

29.3.2001

Figure 3.3: BRENTA Component Model

3.4.2 Concept of Virtual Transport Service The Virtual Transport Services provide conceptual support for the provision of mobility in BRAIN. Applications will run in the user’s terminal. The access to the services from the terminal may take place through several different wireless access networks. Till this point there is no major differences between IP connections. Nevertheless BRAIN terminals are allowed to move maintaining the session from one access network to another one. This causes that the terminal has to get a new IP address. This change of the IP address of one of the participant in a session may cause a lot of problems. In order to isolate this problem, we propose the creation of the VTS concept. Figure 3.4 describes how applications may interchange several flows, meanwhile a flow is only associated with an application (on the same terminal). Each flow is transmitted throughout a VTS, which will be active while the flow is active. The same VTS may support several flows, so it will be maintained while any of the flows are active33. 33

Internet connections (associations in the general case) are strongly coupled with the IP addresses of the connected applications. When the IP address of one of the end points of the connection changes, the full connection must be


101 / 229


Draft / 06.02

29.3.2001

The VTS may use sequentially different NICs, when the terminal changes from one area to another. It is the responsibility of the VTS to hide this change, and their consequences to the flow and consequently to the Application.

Figure 3.4: VTS concept

3.4.3

Basic components

3.4.3.1 Component Coordinator

The main function of this component is to handle the lifecycle of components in BRENTA. Thus there will be only one instance of this component running in the terminal. It maintains a registry with the description of installed components. The information stored per component must allow the media handler to select the proper components needed to handle a particular media stream. This information should include as a minimum the component type (e.g. video codec), parameters of the component to adjust its performance and the template QoS contract for the offered service. The component co-ordinator will provide some searching functionality to facilitate finding a component given the required capabilities. Whenever a component is needed, the component co-ordinator will be required to create an instance of it, by returning a handle. If the component is designed to be shared between different applications, the component co-ordinator will return the handle of the running instance. When a component is no longer in use, the component co-ordinator will decide when to stop the component based on its policy. It might be the case that the component is running without being used at that moment. This is useful for some types of components. As an example, a component retrieving location information performs better when it is running during a well-defined interval of time, even if it is not used during most of that interval.

restarted again. If this happens when a vertical handover occurs, the effect will be similar to shut-down and restart of the application, causing an unacceptable QoS degradation.


102 / 229


Draft / 06.02

29.3.2001

Finally, the component co-ordinator is also in charge of updating existing components or searching for new components that provide functionality required by applications in BRENTA. When a missing or outdated component is detected, it downloads the needed component from a remote provider and updates the configuration files. The schedule of this download is left to the QoS reaction component. For example power saving considerations may prevent the updating of components that would require too much data traffic. The download can occur at any time but the component change should occur only in harmless fashion with regards to active managed streams. The next figure shows the basic primitives for obtaining the capabilities of components already installed and also includes the process to install a new component. The component co-ordinator and its main function-the registry- are drawn separately for clarity, as they exchange some messages. The QoS Broker (see § 3.5.3) will negotiate capabilities with remote peers, obtaining the local capabilities from the registry through the media manager. If during this negotiation, capabilities that are required are not available, the QoS broker will request from the registry these capabilities using the primitive RegisterForCapabilityUpdates. Upon receiving this message the component co-ordinator will download the needed component, install it and then notify to the registry (MountCapability) about the new capability available. The registry in turn will notify the QoS broker of this update using the AddedCapability primitive. It might also be the case that a component is uninstalled. The registry will be notified by the component co-ordinator using UnmountCapability. The registry will propagate this notification the QoS broker using RemovedCapability. Whenever an update occurs (install or uninstall), the QoS broker will renegotiate capabilities with peers.

Figure 3.5 Basic primitives about component capabilities discovery


103 / 229


Draft / 06.02

29.3.2001

3.4.3.2 Media Handler

The applications type C and / or the QoS Broker (see § 3.5.3 for more details) access the BRAIN Component Level API through the Media Handler, an entity in charge of two major tasks: 1. managing multiple application streams, by associating each of them with a specific set of components and ESI sockets, so as to satisfy the QoS level specified at application level with respect to each given stream; multiple stream synchronisation and correlation can enforced either at application level, or by using specific components; 2. monitoring resource usage on a system-wide basis on behalf of applications, and providing the latter with means for controlling said resources; this functionality is achieved by using the resource consumer/producer design pattern (see § 2.4.4), implemented by using the Resource Managers and Controllers described below. The level of resource controlling is limited in scope, since its goal is to provide management functionality with a means for altering resource reservations on the local terminal. 3. providing applications / QoS Broker with estimates of required amount of local resources and the list of necessary capabilities required to manage a given stream: this information is necessary for preparing the information that needs to be negotiated End-to-End with peers (see E2NP). In order to deal with multiple streams, the Media Handler spawns and delegates to this extent instance of a Chain Coordinator per stream. Therefore, applications / QoS Broker will request the Media Handler the creation, management, and release of a Chain Coordinator for each stream: this is the controlling part of the BRAIN Component Level API. Once a given instance of a Chain Coordinator is available, the applications / QoS Broker will use this for setting QoS specifications and perform business related actions. These are translated in the selection, chaining, and configuration of software components, like multimedia or monitor components. The following paragraph describes the Chain Coordinator in more details. 3.4.3.3 Chain Coordinator

Applications of type C / QoS Brokers are by definition in charge of defining high level QoS adaptation strategies, like the End-to-End negotiation and enforcement of QoS Adaptation Paths, based on User Profiles and system policies. To this extent, the QoS Contracts used are quite high-level, which means close to the level of detail that is visible to (eventually non-expert) users. In order to map to low level functionality, the applications / QoS Broker delegate the Chain Co-ordinators to deal with the mapping of the high level QoS specifications described above, in low level contracts which are enforced throughout the chain of components associated with a given stream. An example of such a chain could be the combination of a video grabber, providing input to a layer codec, which finally provides input to multiple packetizers, each associated with a specific ESI socket. The Chain Coordinator will therefore derive from the high-level QoS Contracts sets of low level QoS Contracts, associated with a low level Adaptation Path (AP), based on system policies. The ChC then uses such an AP for fast adaptation to QoS Changes within the envelope of the AP, by simply reconfiguring specific components of the


104 / 229


Draft / 06.02

29.3.2001

chain, or even substituting, adding, or removing them on runtime. Only whenever a QoS change/ violation outside the given AP envelope is detected at ESI level or by some monitoring of components’ parameters, the ChC raises an indication to apps /QoS Broker, requesting the higher levels to take some high level QoS adaptation strategic decision. This type of ChC being delegated low level QoS adaptation is said to work in Automatic Mode. Should however the applications/QoS Broker have more knowledge of the components available, the ChC can be operated in a manual mode, where the low-level QoS adaptation mechanism is no longer delegated to the ChC. In order to distinguish the two modes, two types of ChC are provided the AutoModeChainCoordinator and the ManualModeChainCoordinator, both specialisations’s of the abstract concept of ChainCoordinator. It is up to the applications/QoS broker to request to the Media Handler, which type to spawn. The MH is in charge of creating and managing both types. Each instance of ChC (of both types) will additionally chain resource managers (see next section), which are meant to monitor and control local resources on a stream basis only. Some streams will require their transmission over the network. Though there are special components in charge of this function – packetizers - the ChC will manage the configuration of the connections using ESI primitives. The main aspect of this function is the selection of the network provider each time a connection is established. The next figure shows some of the steps involved in this process. The first one is to maintain a list of available network providers. A Virtual Transport Service (VTS) will represent each network provider in the terminal. VTS creation is a function of the Stack Manager; the ChC will perform a selection of the most suitable VTS per connection (see Figure 3.6).

Selection of autoconfiguration server

on demand test of autoconfiguration server

proactive test of autoconfiguration server

connection parameter manager

VTS supervisor

VTS research

Mapping of parameters

Available resource estimation

VTS selection

Application allocation to VTS

Figure 3.6: Network operator selection and high level auto-configuration CEC Deliverable Number 1.2

105 / 229


Draft / 06.02

29.3.2001

To perform this selection, the ChC will gather information of the connection and the service offered by each VTS. First it will check which VTS can reach the expected end point of the connection. Attending the BRAIN usage scenarios, it will be usual that several VTS can reach a particular destination. In this case, the ChC will inquire each of the VTS’ about the available resources. Only VTS’ offering enough resources to fulfil the QoS request of the connection will be considered candidates. If there are several candidate VTS’ after this process, the ChC will select one based on the User Profiles or system policies. These might include cost considerations, for example. In addition to this selection function, the ChC will take advantage of the autoconfiguration offered by network operators through the VTS. The VTS allows the discovery of servers offered by its associated network provider. The ChC will discover these servers and inform to the chained components of their existence. Some components can improve their performance by using these servers, like a DNS server available at the fastest network provider. 3.4.3.4 Resource Managers and Resource Controllers

According to the Resource Provider/Consumer Design Pattern described in § 2.4.4, applications can access services offered by local resources (like CPU, memory, battery power management, and auxiliary external devices) and network resources, through the mediation of Resource Managers and Resource Controllers (see Figure 3.7). This pattern can handle both resource usage monitoring and resource control.

Figure 3.7: Resource Provider/Consumer Design Pattern

As mentioned in § 3.4.3.2 and 3.4.3.3, BRAIN applications of type C and D will rely on the Media Handler and the Chain Co-ordinators for accessing resource management, respectively on a system-wide and on a flow-wide basis. The Media Handler and each instance of the Chain Coordinator will therefore be able to use an instance of the


106 / 229


Draft / 06.02

29.3.2001

Resource Manager for each type of resource (the Resource Controllers are centralised entities, most likely implemented as extensions of the OS). Since the control of some type of resources may depend on the use of other types of resources (e.g. hard disk access for memory swaps may impact on power management), the Media Handler and the Chain Coordinator can try to enforce some form of resource control co-ordination. It is however expected (and highly recommended) that most of these issues will be directly addressed at OS level, that is, the Resource Controllers simply model functionality that should be preferably implemented as an OS extension. For instance, the following algorithm may be used for accepting any request to perform control on any type of resource: 1. evaluate impact on CPU usage, and submit any necessary request to the CPU manager: only if it is accepted then 2. evaluate impact on memory usage, and submit any necessary request to the memory manager: if it is accepted then 3. evaluate impact on power usage, and submit any necessary request to power manager. If the three sub-requests are accepted then the resource reservation can be confirmed. If the power sub-request is refused it may be the consequence of additional power consumption resulting from either CPU overload or memory over-reservation34. The following paragraphs detail first the Resource Managers and then the Resource Controllers for each type of resource. 3.4.3.4.1 Resource Managers 3.4.3.4.1.1

Profile Manager

The tasks of the Profile Manager is to provide an interface for QoS negotiation for the specific resource, namely the profile, i.e. to provide means for specifying profiles. Similar to providing adaptation mechanisms, the Profile Manager would notify the Broker whenever profile information has been changed or updated, i.e. due to user interaction or due to some other events. The Profile Manager would enable the QoS Broker to request and release a profile from the Profile Controller. In addition, an intelligent QoS Profile Manager might restrict the users' choice to QoS parameter values that are manageable by the local system. As an example it makes no sense to offer the user the option to request a high-quality real-time videoconference on a GSM-phone. However, this might be possible on a high performance workstation. If the user’s QoS profile has been changed by some other components, the Profile Manager would notify the user. 3.4.3.4.1.2

Network Manager

According to the provider/consumer design pattern, the Network Manager implements the consumer helper component and provides an interface for a given component to:

34

negotiate for network resources ultimately using the ESI [D.2.2] based on a proposed QoS contract;

Continuing the previous example, the memory reserved in user space may require some low priority applications to swap on hard disk. In this case the battery lifetime could be significantly shortened. The request should then be reprocessed taking into account this additional constraint.


107 / 229


Draft / 06.02

29.3.2001

re-negotiate for network resources with the ESI if network resource consumption of the component changes;

release the network resources with the ESI when the component ceases to exist;

notify the component that uses the Network Manager of any adaptation requests that are received in the case of overload/underload situations;

sample (local) network resource usage and measure received Network QoS; and

perform transparent Re-negotiation with the ESI if instructed by the component that uses the Network Manager based on its monitoring information.

The Network Manager always works together with a socket (and implicitly the ESI), because it is ultimately the socket that requests services from the ESI. Note that any component that needs Network resources for its tasks can use the Network Manager. However, the most likely component that uses it is the ChC to request Network resources for the media transmission. The Network Manager forwards the requests to the ESI that implements the admission control functionality for the resource Network. For the QoS specification for the network resources, we refer the reader to the ESI description [D.2.2]. In addition, the Network Manager is able to trigger handover functionality based on information obtained from the Stack Manager. It informs the component that uses it about:

possible handover opportunities (i.e. it notifies the detection of new networks or if some networks are no longer accessible);

whether it is planning to perform a handover in the near future; and

whether a forced handover has happened.

The Network Manager also provides the component that uses it with relevant monitoring parameters like available raw access bandwidth (even quantized to discrete levels like low, medium, high), signal quality at the link level. Therefore, higher level hand-over strategies become possible that may be based on preferences and/or cost reasons. Having information about the type of handover that is planned/performed, the network manager can easily detect, if a QoS upgrade is possible. If the hand-over has occurred and no QoS violation has been received from the ESI, the network manager would request, if instructed, more resources from the ESI on behalf of the component that uses it (e.g. via notifyResource, see § 2.4.4). By combining an ESI-QoS aware socket with a network manager provides thus a powerful tool for requesting notification, whenever new resources become available for the network. 3.4.3.4.1.3

Memory Manager

It is necessary to guarantee memory access for a given amount of memory (necessary to capture and process media units) within a bounded latency for providing satisfactory QoS. This lead to the requirement, that memory access has to be controlled and all critical memory should be located in the non-pageable memory area. For the QoS architecture, where memory is treated as a resource, this leads to a memory controller and a memory manager that have to work together to provide predictable memory access for media handling and processing.


108 / 229


Draft / 06.02

29.3.2001

According to the provider/consumer design pattern, the Memory Manager implements the consumer helper component and provides an interface for a given component to:

negotiate for Memory resources with the Memory Controller based on a proposed QoS contract;

Re-negotiate for Memory resources with the Memory Controller if Memory resource consumption of the component changes;

Release the Memory resources with the Memory Controller when the component ceases to exist;

Notify the component that uses the Memory Manager of any adaptation requests that are received from the Memory Controller in the case of overload/underload situations;

Sample Memory resource usage and measure received Memory QoS; and

Perform transparent Re-negotiation with the Memory Controller if instructed by the component that uses the Memory Manager based on its monitoring information.

Note that any component that needs Memory resources for its tasks can use the Memory Manager. However, the most likely component that uses it is the ChC to request Memory resources for the media processing. The Memory Manager forwards the requests to the Memory Controller that implements the admission control functionality for the resource Memory. For the resource memory, the number of buffers needed per stream is as important as the access latency associated with the buffers. If the memory is located at a swappable page, the access time is calculated to the time needed to access the external device and the time needed for communication inside the operating system. Latency bound for accessing the device is typically much higher than the time needed to perform the operating system calls, which is bounded by bus transfer speed and system clock. In order to get predicted performance, buffers should typically be locked in memory. 3.4.3.4.1.4

CPU Manager

According to the provider/consumer design pattern, the CPU Manager implements the consumer helper component and provides an interface for a given task (or Thread) to:

negotiate for CPU resources with the CPU Controller based on a proposed QoS contract;

re-negotiate for CPU resources with the CPU Controller if CPU resource consumption of the task changes;

release the CPU resources with the CPU Controller when the task is finished;

notify the component that uses the CPU Manager of any adaptation requests that are received from the CPU Controller in the case of overload/underload situations;

sample CPU resource usage and measure received CPU QoS;

perform transparent Re-negotiation with the CPU Controller if instructed by the component that uses the CPU Manager based on its monitoring information;

Note that any component that needs CPU resources for its tasks can use the CPU Manager. However, the most likely component that uses it is the ChC to request CPU resources for the media processing.


109 / 229


Draft / 06.02

29.3.2001

The CPU Manager forwards the requests to the CPU Manager that implements the admission control functionality for the resource CPU. The following parameters should be supported when requesting CPU resources:

Period: the duration of one iteration. This parameter can typically be derived by the component that uses the CPU Manager. As an example, if the ChC is configured to generate 25 fps, the desired period would be 40 ms; and

Quantum: the amount of CPU allocated for the task during one period. Typically, this parameter cannot be known a priori. So it is up to the CPU Manager to estimate this parameter and start with a default value when making the reservation with the CPU Controller. After several periods, the CPU Manager can re-negotiate with the CPU Controller transparently based on monitoring information.

3.4.3.4.1.5

Other Managers

These components are in charge of dealing with other local resources like the management external auxiliary devices (e.g. by using wireless links, like Bluetooth), or battery power management. They may have impact on the OS kernel space domain. In the following we concentrate only on the power management. 5.4.2.4.1.6.1 Power Manager

Mobile terminals are typically operated by using batteries. In order to allow applications to operate correctly on such devices, sufficient battery lifetime must be preserved. This means that when the terminal is unplugged from the mains, the usage of the terminal’s hardware resources should be controlled, so as to ensure that battery lifetime remains greater than a given lower threshold. Since application lifetimes are usually well known, one can algorithmically estimate when the battery consumption for said applications causes the battery lifetime to decrease below the aforementioned threshold. Should however an application not indicate its lifetime, some estimation should then be computed. When the terminal is plugged to the mains, the system should estimate the expected plugged duration, so that power consumption can be planned (by taking into account the longest application lifetime), in such a way that the batteries can be successfully reloaded before that time expires. Ideally the user should be able to manually overwrite said estimated duration. In order to properly administer battery power some hardware resources (e.g. peripherals like a floppy disk unit) may be put in an idle or power saving mode. In particular the radio interface may have adaptable power saving modes, which must be tuned according to communication demand and power consumption constraints. A lower communication quality may be acceptable for power saving reasons, according to the QoS parameters of the currently active flows. Another example of power management strategy would be to pause low-priority applications, so as to allow more important applications to drain the power necessary for them to operate. The Chain Coordinator (or the Media Handler, on a system-wide basis) can monitor and eventually control (on behalf of applications) the amount of power dedicated to specific applications and/or to classes of applications, by using the Power Manager component. This component co-ordinates with the Power Controller (described in § 5.4.2.4.1.6.2) any monitor- and control-request from the applications.


110 / 229


Draft / 06.02

29.3.2001

Through this component, one can then assign applications to specific classes of power management behaviours, monitor their battery consumption, and eventually reassign them to other classes, so as to achieve different QoS treatments. 3.4.3.4.2 Resource Controllers 3.4.3.4.2.1

Profile Controller

The Profile Controller has to maintain a consistent user QoS Profile set. Therefore, it is responsible for controlling admission to the profile, i.e. to request a certain profile either locally from a profile database or remotely from a central profile repository. In addition the Profile Controller would manage reservation for the profile, i.e. the Profile Controller would store, install and remove the profile either on request of the user or some other entity (i.e. the broker or the application). Together with the Profile Manager the Profile Controller would negotiate for a profile. The Profile Controller could also present a Profile definition GUI where the user might set-up or change the Profile or her/his preferences. As the Profile Controller controls admission to the profile, the profile controller knows the location of the profile. This could be on the same physical host (i.e. the end-system) but also on a different location (i.e. the profile provider). If the Profile Controller has to contact the profile provider to get access to the profile, this could be based on some directory-based mechanisms (like LDAP). If the profile is located on a profile provider, we have to distinguish who is the owner of the profile, i.e. who decides about possible changes to the profile: a) the user is the owner of the profile, i.e. the profile provider acts as simple storage server for the profile, which could be useful for small devices like PDAs with limited persistent storage capabilities; b) the profile provider is the owner of the profile; i.e. the profile provider is able to change the profile due to some reasons (see above). In the case of b) we have to distinguish between two models: a)

all service providers implement their own profile manager and own profile database

b)

some services share a profile manager

Clearly, case a) will be more realistic in the sense that no standards are available at the moment, but is not scalable and not manageable. If a profile manager is shared, the profile manager has to be standardised. Therefore, an interface that service providers can use for validating and updating profiles is necessary. Note, that an update of profiles should be allowed only on instantiated profiles in the end-systems and not in the database which still holds the original user defined profile. 3.4.3.4.2.2

Stack Manager

The goal of the Stack Manager (or Network Controller, in the language of the design pattern) is to provide through the so-called Local Management Interface [D.2.2] a functionality for locally managing the network stack. The Stack Manager works together with the network manager. More information can be found in [D.2.2]. 3.4.3.4.2.3

Memory Controller

The goal of the Memory Controller is to guarantee, together with the Memory Manager, access to a certain amount of memory given a bounded latency. During page swapping CEC Deliverable Number 1.2

111 / 229


Draft / 06.02

29.3.2001

periods, offered by standard operating systems in order to provide virtual memory, realtime multimedia applications may suffer from unpredictable delay for memory accesses. Therefore, access to memory has to be encapsulated by a memory controller to provide applications by memory areas offering latency bound access. In addition, admission tests have to be performed by the Memory Controller to determine if there is enough memory that can be accessed at certain latency. Also, the Memory Controller should offer means for pre-empting memory from low-priority tasks on behalf of high-priority tasks. We can distinguish between three different levels of tasks for the resource memory:

Locked: memory belonging to the locked class are locked in memory and thus not swappable. Locked memory is non-preemptible from other memory classes. Therefore, locked memory has the highest priority.

Locked-Pre: memory belonging to the locked-pre class are locked in memory but are preemptible by memory requests from the locked class, which may happen during periods of low memory availability

Pageable: memory belonging to the pageable class is served by standard swappable virtual memory. This memory area is preemptible by locked and locked-pre memory class.

In order to distinguish what type of memory should be applied, we can use the application level QoS parameter service-type with values: best effort, predictive, adaptive, guaranteed. If guaranteed QoS is requested, we use the locked memory class. If best effort is specified, we apply pageable. To all other classes, we can apply lockedpre. According to the provider/consumer design pattern, the Memory Controller implements the provider helper component. The Memory Controller interacts with the Memory Manager to:

provide admission control services for the resource Memory;

provide mechanisms to reserve/release Memory resources;

provide means for dynamic (global and local) adaptation of Memory resources and provide mechanisms to perform dynamic Memory (re-) negotiation.

3.4.3.4.2.4

CPU Controller

According to the provider/consumer design pattern, the CPU Controller implements the provider helper component. The CPU Controller interacts with the CPU Manager to:

provide admission control services for the resource CPU;

provide mechanisms to reserve/release CPU resources;

provide means for dynamic (global and local) adaptation of CPU resources; and

provide mechanisms to perform dynamic CPU (re-) negotiation.

First, the CPU Controller performs admission control when it receives a new request from a CPU Manager. If the request is granted, it forwards the new task to the CPU Scheduler (see below) and the task is then scheduled according to its CPU specification. During runtime of the task, the CPU Controller works together with the CPU Manager for re/negotiating for CPU resources. Whenever the CPU Controller receives re/negotiation requests from the CPU Manager, the CPU Controller checks with the admission control algorithm, if enough resources are available. Finally, when the task


112 / 229


Draft / 06.02

29.3.2001

ceases to exist and it is instructed by the CPU Manager, the CPU Controller releases the resources from the CPU Scheduler. If the CPU Controller detects overload situations, it notifies all CPU Managers to perform adaptation based on its internal adaptation policy. One could use priorities to detail the adaptation request. If a CPU Manager has requested to be notified whenever there are more resources available, the CPU Controller would notify the CPU Manager, if, for example, other tasks finished and there are more resources available. The CPU Controller works together with a CPU Scheduler, which implement policies how the CPU is shared among multiple competing CPU consumers. Because only the CPU scheduler has information of CPU usage, the CPU scheduler provides feedback information for CPU consumption and QoS delivery for the CPU Managers and CPU Controllers. Therefore, the tasks for the CPU Scheduler is to:

schedule already reserved resources in a controlled way; and

measure resource usage and QoS delivery.

Note that it is not our intention to completely rewrite an operating system. We simply identify any missing functionality that is required to provide QoS End-toEnd. On some operating systems, there may be schedulers available, which already provide the required functionality, so the CPU Scheduler would simply be a wrapper to already existing functionality. On other target platforms, the CPU Scheduler would have to implement more functionality, if it is not provided by the target platform itself. Note also, that together with the scheduling algorithm used by the scheduler (i.e. earliest deadline first or rate monotonic or variants thereof), the CPU Controller implements the admission control algorithm that matches the scheduling algorithm. 3.4.3.4.2.5

Other Controllers

As indicated in § 3.4.3.4.1.5, one can explicitly manage additional types of resources, so as to achieve the desired level of QoS. In the following paragraph we limit our discussion to the case of power resource controller (compare with § 5.4.2.4.1.6.1). 5.4.2.4.1.6.2 Power Controller

The motivations and implications of power management have already been presented in § 5.4.2.4.1.6.1. In this paragraph, we focus on the low-level mechanisms to employ for meeting the requirements set forth above. As anticipated in § 3.4.3.4, the Power Controller, as any other Resource Controller, may be well part of an OS extension. Actually, especially in this case, the low level functionality concerning power management needs to be as close as possible to the OS, since the use of any type of resource (CPU, memory, network, external auxiliary devices) has deep implications with respect to the use of the power. Concerning power control aspects, the Power Controller should deal with: •

system power management;

•

device power management;

•

processor power management;

•

device- and processor-performance management;


113 / 229


Draft / 06.02

29.3.2001

•

plug and play operations: insertion/removal (even during runtime operations) of hardware components shall be taken into account for updating power management strategies;

•

system events;

•

battery management;

•

thermal management (since the fan draws power);

•

embedded controller; and

• system bus controller. The Power Controller shall be integrated with existing technical solutions (like ACPI, OSPM, and APM in the case of Wintel platforms [ACPIv20]), by extending them so as to allow applications being assigned to different levels of power management behaviours. When it comes to monitoring battery lifetime, the following aspects should be taken into account: • •

current battery load; last full-loaded battery capacity (it varies during battery lifetime, due to memory effects); • battery usage history (to compute the expected reload time when plugged); • plug status of the terminal; • CPU present mode and speed; • hard disk usage; • internal memory power consumption; • screen mode; • radio interface; and • other peripherals power usage. Expected plugged duration time and default application duration time should be deduced from previous usage of the terminal or default values after a reset. 3.4.4

Session Manager

This component manages the establishment of sessions with peers through the network. As there are several competing protocols for this purpose, this component will offer an independent API to applications, thus allowing for the implementation of protocol independent application. But the session manager will implement different session protocols (e.g. SIP, H.323...) to be able to peer with different remote partners. The selection of the adequate session protocol and the mapping from the API to it are also functions of this component. Given this functional description, there will be only one instance of the session manager running in the terminal. Depending on the session protocol, once the session is established some procedures might have to be carried out to maintain it. The session manager will perform these on behalf of the application. 3.4.5

Monitor components

A measurement system for QoS monitoring in BRENTA means a system where instances such as the QoS Broker and the Chain Coordinator is given a method to efficiently monitor what is the actual status of the system and if the promised QoS is


114 / 229


Draft / 06.02

29.3.2001

reached. The measuring system proposed here involves to monitor two types of resources: system specific resources by deploying so called ‘wrappers’ and traffic flow related performance information in terms of QoS characteristics by deploying dedicated probes (see Figure 3.8). In Appendix A.3, a more general overview and introduction to these two concepts is provided.

Figure 3.8: BRENTA wrapper concept

The following chapters deal with BRENTA specific framework issues and how the discussed functionality can be applied there. 3.4.5.1 Monitoring of Resources

Components are installed and managed per flow by the Chain Coordinator, which is in turn also responsible to install the wrapper accordingly. The Chain Coordinator itself is directly controlled by the Media Handler, one reason for this is that media streams could contain more then one stream, such as a workgroup sharing tool will support audio, video and data streams in one bundled application. According to the framework, the Media Handler then is controlled by the QoS broker, which is needing information about consumption of resources in BRENTA component based type C and D applications.


115 / 229


Draft / 06.02

29.3.2001

The Chain Coordinator is responsible for the management of the wrapper, as well as it receives the periodic reports about the status of the resources. The underlying protocol for the information exchange is described in a generic way in (see § 2.4.5). However, CPU usage, memory allocation and consumption of other resources are varying over a certain time period and collection of more statistical values is recommended. For long term statistical processing of this information, the wrapper deliver also reports of resource consumption to the Resource Profiler and stores the information in the Registry. The QoS Broker has access to the Registry through the Media Handler respective the Resource Managers. 3.4.5.2 Monitoring QoS Characteristics

The so-called monitor probe is indeed implementation specific, but in general it could be implemented in a component fashion.

Figure 3.9: BRENTA Probing Concept

The existing framework will be used to include monitoring probe components and request from the to be monitored component to subscribe a service to report towards the probe QoS characteristics such as performance parameters about a specific flow, group of flows or other used traffic specific flow information to a certain extent. At this point, it has to be assumed that the components within the framework will offer some standardised interface to provide their key performance information, which is then collected by the monitor probe35. For those vendors, who will not support this kind of interface, the monitor probe features a negotiation protocol in order to tap QoS characteristics in a different way36. 35

The component itself is closest to this kind of traffic information and knows best about the QoS characteristics performance. The wrapper approach mentioned before is not feasible to be deployed here as well.

36

Such an approach might be difficult and is not the focus of this chapter.


116 / 229


Draft / 06.02

29.3.2001

The information gathered by the monitoring probe could be forwarded as such to the Chain Coordinator but certain mathematical functions such as statistics as well as correlation [Aquila00] could be performed on site. It is clear that the amount of gathered information should be kept at a certain economical level, thus mathematical function at this point is recommended. The information flow of reports is bound to the protocol proposed in (see § 2.4.5). The probes report to the Chain Coordinator, which is then informing the QoS Broker to support it to make decisions and to invoke adaptation procedures if necessary. In general, the traffic contract (see § 2.4.5) is defining the QoS states and therefore the Chain Coordinator (in auto mode) gets the information of what kind of information needs to be monitored from the dimensions defining the cubicles. The probes are directly related to the dimensions of the cubicles. There are several possibilities to gather the information needed – depending on where the probes are placed for gathering information in the BRENTA framework (§ 2.4). They are designed to collect the information from the following sources: •

via local application specific mechanisms, e.g. from the various API interfaces deployed in the communication stack of the BRENTA host as well as preconfigured components with built-in probing interfaces

•

as control messages from the remote receivers of the flow, e.g. using RTP/RTCP [RFC1890]

•

messages through the ESI interface, e.g. using SNMP37 [RFC1901] for network specific information

It has to be mentioned that gathering information both about resources and QoS characteristics is not supposed to consume a major part of the CPU power, instead, the timescales used and the amount of information flow towards other components (ultimately, the QoS Broker) has to be carefully engineered. It is up to the application programmers of the graphical GUI tool, type B applications and as well as to the Chain Coordinator in auto mode monitor resources and QoS characteristics only that are needed to assist the decision entities for the adaptation process. 3.4.6

MM Components

As multimedia components we denote all those components that are used in a processing chain by the ChC. The ChC may be configured in several modes for different media types: •

As a sender chain

•

As a receiver chain

When configured as a sender chain, the chain is the source of a media stream, whereas in the receiver chain mode, the chain acts as sink of a media stream. As a source of a media stream, the sender chain has to gather media units from some source entity, which we also can model as object:

37

•

File, that holds compressed or uncompressed media units and is able to act as container for all media types

•

Microphone for the media type audio

SNMP is not capable to perform real time monitoring, it is only suitable for long time scale monitoring.


117 / 229


•

Draft / 06.02

29.3.2001

Frame-grabber for the media type video

Once the (raw) media data is obtained from the source object, it might be pre-processed by some •

Filter that optionally processes raw media data. As an example, such a filter may be an effect filter or a colour conversion filter for calculating the correct colour model for the media codec

Typically, before transmission over a network occurs, media data units are compressed to save network resources. This information reduction process can also be modelled using an object, which we call •

MediaCodec, that encapsulates a media compressing/decompressing algorithm. Typically there are different kinds of codecs available: audio and video codecs. Also, for each type of codec, different algorithms exist. As an example, there are MPEG, H.261 or H.263 codecs for video whereas GSM, G.711 or G.728 codecs for audio.

After the media units have been compressed, the compressed data is typically packetized in RTP packets before transmitted over the network. However, the packetization algorithm depends on the type of codec used. For example, the packetization works different for MPEG compressed streams than for H.263 compressed streams. It is thus natural to include this functionality into another object, the •

MediaPacketizer, that take compressed media units and generates RTP packets. This operation depends on the media codec

Finally, the RTP packets generated by the MediaPacketizer have to be send over the network using •

Socket, that allows enabling all QoS functionality offered by the ESL and sends the compressed RTP packets generated by the MediaPacketizer to a dedicated IP address and port.

Note, that we can model two scenarios with these components: real-time conferencing and VoD. For Real-time conferencing, the chain could look like: Frame-grabber -> Filter -> MediaCodec -> MediaPacketizer -> Socket For VoD and compressed video files, the chain could look like: File -> MediaPacketizer -> Socket. Note also, that for media codecs that generate multi-layered streams (with several network layer flows), several sockets might be used with different QoS settings for each socket. It is then up to the receiver chain to synchronise these flows and generate one multi-layered stream that the receiver side codec can decode. As a sink of a media stream, the receiver chain has to receive RTP packets generated by the peer using a •

Socket, that receives the packets at a given port.

The RTP packets are then forwarded to a •

Reassembler, that takes the RTP packets from the socket and generates the compressed media data units. This operation depends on the media codec and works in the reverse direction as the MediaPacketizer


118 / 229


Draft / 06.02

29.3.2001

After the compressed samples have been reconstructed, the Reassembler forwards the compressed data to the •

MediaCodec, that encapsulates a media compressing/decompressing algorithm and generates an uncompressed media data unit. The output of this operation would be an uncompressed video frame or a number of raw audio samples.

Finally, the raw data is forwarded to a •

PostProcessor, that modifies the uncompressed media data units before rendering. For the media type video for example, the PostProcessor would stretch the video frame to match the display size and format, would translate to the correct colour model or would implement any kind of filter operation that is required.

As a last step, the raw media information is then rendered using a •

Renderer, that displays the raw video frames for the media type video. For the media type audio, the renderer would use the loudspeaker or mixer to play the uncompressed audio samples. As an alternative for debugging, the Renderer could also write the media data to a file.

Summarising this section, we have identified a number of components that provide the functionality to model a complete multimedia framework. The components support any media type (audio and video) and any situation (source or sink) as well as scenario (VoD, where the source retrieves the compressed samples from a file and real time conferencing, where the uncompressed samples are gathered from a microphone/grabber). However when implementing these components, one could use already available frameworks (like JavaMediaFramework, JMF), that might be based on a different component model. So the components mentioned in this section are just a proposal, that the ChC can use. If the implementers decide to use JMF for implementing the ChC functionality, the internal components might look differently but provide the same functionality. 3.5 The BRAIN High Level API 3.5.1

Introduction

This section details the ways high level specification of QoS requirements can be achieved. To this extent, concepts from § 2.4.7 are further elaborated, and the BRENTA Interface Type D concept (see § 3.1) is taken into account. A generic data model for specifying any type of QoS requirements - at a level of abstraction that trades off implementation independence to information completeness is therefore presented. 3.5.2

High Level QoS API

The BRAIN High Level Interface is Object-Oriented API based on data model presented in § 2.4.7.2. As such, it is not just specified as a list of functions, rather as a list of objects (each providing a specific functionality), and the relationships among them. The BRENTA approach envisions as ultimate achievement the possibility of developing thin and simple QoS- and mobility-aware applications that delegate an external QoS Broker entity for what QoS- and mobility- adaptation it concerns.


119 / 229


Draft / 06.02

29.3.2001

Such applications - indicated as BRENTA Applications Type D in § 3.1 - are therefore the most advanced ones in the BRENTA model. With these applications developers will in fact be able to specify QoS requirements and adaptation policies in a user-friendly, concise, and effective way, so that the QoS Broker is able to get the information it needs to manage QoS- and mobility-adaptation on behalf of said applications. These applications shall indirectly interface to the QoS Broker through the BRENTA Interface Type D (see § 3.1), which ultimately shall be implemented as a platformindependent Application Programming Interface (API). Requirements for this API are: •

Expressiveness: the API shall be able to capture the application developers' high level requirements in a user-friendly, concise, and effective way

•

Ease of use.

•

Platform-independence

•

Multi-stream Time Synchronisation: the API shall be able to let the application developers set constraints on the timing relationships among streams originated by different sources (see § 2.4.7).

•

Multi-stream QoS Correlation: the API shall be able to let the application developers set constraints on the relationships among streams originated by different sources, in order to enforce a homogeneous QoS specification and adaptation treatment among said streams (see § 2.4.7).

•

Extensibility: the API shall be able to deal not only with issues identified during the API design-phase, but also with any later custom-specific QoS and policy specifications.

•

Event-based call-back model: this API shall let the developers register their applications with said API in order to be notified via event-based mechanism, whenever the QoS Broker is not able to fulfil its obligations, due to some extraordinary event (unaccounted effects of QoS violations due to e.g. hand-offs). This is a form of very high level application adaptability to QoS changes: for instance, during black-out periods due to hand-offs, the application can be promptly informed so that special courtesy information about the out-of-service event can be gracefully presented to the application users.

The middleware offering this API shall offer therefore the possibility to (i) create/manage Streams and to (ii) associate them with multi-streams synchronisation constraints, QoS specification, and adaptation policies (e.g. the description of Adaptation Paths). By using this API, application developers shall therefore be able to focus (i) on the specification of an Adaptation Path on various levels (see § 2.4.7) and (ii) on the establishment, management, and release of QoS- and mobility-enabled information exchanges with peers. As aforementioned, the § 2.4.7.2 already describes the object model, which this ObjectOriented interface is based upon. More detailed description of such API is not within the scope of this section.


120 / 229


3.5.3

Draft / 06.02

29.3.2001

QoS Broker

Applications type D rely on the QoS Broker functionality for handling QoS Management and adaptation. Figure 3.10 indicates how the QoS Broker relates to the BRAIN component model described in § 3.4. The QoS Broker is in charge to manage the set of active flows by deciding the distribution of resources among them and resolving any conflicts between flows whenever required resources are lacking. In particular the QoS Broker handles priorities in order to provide the optimal repartition according to the user privilege and application QoS. This component negotiates End-to-End QoS Specifications with remote peers and may delegate ChC for low level QoS adaptation. The decisions taken by the QoS Broker are forwarded to the Chain Coordinator which feedback to the local and external resource managers implied by the decision.

Figure 3.10: Relationship between BRAIN QoS Broker and BRAIN Component Level API

To this extent, the QoS Broker provides the following functionality: •

Management of User Profiles and Policies

•

End-to-end QoS negotiation / re-negotiation protocol

•

Enforcement of AP through FSM

•

Assessment of current QoS level

•

QoS mapping

As depicted in Figure 3.11, in order to deal with all these issues, the QoS Broker can be modelled as a group of functional units around a core co-ordinating function, the QoS Broker Co-ordination Unit (modelled according to the Mediator design pattern [Gamma94]). The QoS Broker interacts with a User Profile Manager and Policy Manager, to deal respectively with users’ preferences (in terms of AP), and system configuration (in CEC Deliverable Number 1.2

121 / 229


Draft / 06.02

29.3.2001

terms of QoS adaptation strategies with respect to component parameters configuration), which need to be negotiated End-to-End with peers and to be enforced [HSKKN01]. A Negotiation Unit deals with E2NP/E2RP functionality (E2NP REF), by interfacing with the Session Manager, in order to leverage the appropriate (wrt the given type of service) session protocol layer. An FSM engine unit provides the execution environment for the FSM modelling the pre-negotiated AP. A QoS assessment unit gathers information from monitors (either simple or derived see § 3.4.5), and estimates out of these measurements the actual high-level QoS level currently being experienced [Bhatt99]. This unit then compares the estimate against the FSM States, in order to check whether the currently enforced QoS Contract (i.e. the currently active state in the FSM) complies with the estimated QoS Level, and to what extent. A compatibility factor and a time window can be used for tuning the sensitivity of said algorithm. The goal is to determine whether a new QoS Contract out of the prenegotiated AP better fits the estimated QoS level. Once a new QoS Contract has been selected, the QoS Co-ordination Unit interfaces directly with the MH/ChC to delegate to it low-level QoS adaptation tasks.

Figure 3.11: QoS Broker structure

Should a ManualModeChainCoordinator be used (see § 3.4.3.3), the QoS Broker Unit would then need to directly perform (through the QoS Mapper unit) QoS parameter


122 / 229


Draft / 06.02

29.3.2001

mapping: from the high level QoS specification of the AP to the components parameters specification. 3.5.3.1 QoS Reallocation

The QoS Broker performs QoS re-negotiation according to resource manager design pattern described in § 2.4.4, that is either upon user’s change of profile, or from peer’s initiative, or detected changes in network resource usage. More specifically, QoS reallocation occurs whenever any of the following events takes place:

the resource changes (e.g. radio propagation degradation);

an application renegotiates its QoS parameters on line;

a new flow is accepted; or

an old flow is terminated.

The QoS Broker must manage adaptation in front of mobility, by monitoring and orchestrating resources accordingly. Once the QoS Broker provides the Chain Coordinator with a new QoS contract, the latter breaks the contract up into a low-level AP, as described in § 2.4.5. The detailed specification of the resource orchestration algorithm is not within the scope of this document. However, it should optimise some utility function taking as arguments the QoS contracts of the allocated and pending streams and the currently allocated resources to these streams. 3.5.3.2 Orchestration of Resources

In this section we identify different options, how local and remote end-system resources and network resources can be orchestrated in order to provide End-to-End QoS. We have to consider the different ordering of tasks the Resource Managers and the QoS Broker have to perform. There are several options and it depends on the scenario, which option is the most suitable one. So we therefore first identify the scenarios we are looking at. For each scenario, we have then to find the correct sequence of actions to be taken by the QoS Broker and the Resource Managers. As an example, the list below summarises some generic actions that the components have to take. The user via the application requests the user QoS definition GUI via the high level API The QoS Broker requests the GUI from the user QoS profile manager, which forwards the request to the profile controller to locate a default profile. The user defines her/his QoS preferences and degradation paths. The QoS profile controller stores the profile in its database. The user triggers the call set-up. Note this can also be done above the framework by some application-to-application interaction (like ringing). The remote application accepts the call and sends an ID back. The local application asks the QoS Broker via the high level API to initiate an appropriate streaming session.


123 / 229


Draft / 06.02

29.3.2001

The QoS Broker queries the local user QoS profile manager about the actual QoS profile to use for the given stream. The QoS Broker negotiates for capabilities (like codecs...) with the remote broker using the session manager, which internally might use SIP for that purpose. The QoS Broker decides the actual streaming parameters by querying the local resource managers (i.e. CPU, network, and memory). The QoS Broker advises the resource managers to reserve appropriate resources locally. The QoS Broker advises the Chain Controller to set-up and tune the correct media processing chain and to initiate the streaming process. The QoS Broker informs the application about the stream that was started and returns an ID. The QoS Broker then listens to monitoring results and local (triggered by the managers and controllers) as well as remote adaptation requests (initiated by the peer broker). 3.5.3.3 Use of fuzzy logic technology

When it comes to addressing the “high-level” and “user-friendly” aspects of the Type D Interface, one has to clearly define how users, who are not skilled in the art of computer programming and multimedia service management, can effectively use such interfaces. From an implementation perspective, it is also a critical issue to determine how to deal with QoS adaptation, based on Adaptation Paths and monitoring of certain physical parameters. One can address these issues either by designing an ad hoc solution, which is tightly coupled to a specific platform or in a more general way, by leveraging fuzzy logic technology [Zadeh74]. Simply stated, fuzzy logic defines a superset of the conventional (Boolean) logic, by extending it to deal with the concept of partial truth, as a means to model the uncertainty of natural language38. Partial truth-values thus span between "completely true" and "completely false" across a range of concept refinements similar to what commonly happens in the natural language (e.g. “almost true”)39. This technology can be effectively used to provide users with the possibility to express high-level QoS specifications by simply using linguistic expression, like: QoS Contract = (Video stream: medium-high frame rate, very high frame size, and slightly good image quality). Of course, this might seem odd from an application developer’s perspective, but it totally makes sense to non educated users, who typically provide such kind of fuzzy

38

Rather than being a single theory by itself, fuzzy theory can be regarded as a methodology to generalise any specific theory from a crisp (discrete) to a continuous (fuzzy) form.

39

The “do not care” term, usually expressed in truth tables as an “X” symbol, can be modelled in fuzzy logic by writing correspondingly an if-then rule where the “X“ term is simply ignored in the antecedent on the left hand side (LHS) of the rule.


124 / 229


Draft / 06.02

29.3.2001

specifications either by selecting a well defined User Profile from a list, or by using some GUI functionality. A key point is that these linguistic expressions are mapped to crisp numbers, based on mappings and rules, which can be provided by vendors, service providers, and/or system administrators. These mappings and rules are therefore totally transparent to agnostic users, who thus perceive their high-level user profiles as being portable from platform to platform. From an Interface Type D implementation perspective, by using fuzzy logic one can also achieve the following goals: •

the capability of mixing analogue input parameter values with discrete commands from users, administrators, or peers. A fuzzy rule could look like the following: if (monitored_total_bandwidth is “very low”) (measured - analog parameter) and (user_command is “black_white”) … (command - discrete parameter) then (change codec “H.263”)

•

the capability of concisely expressing the state transitions of the FSM describing Adaptation Paths (see § 2.4.7) ;

•

easing the implementation of the mapping between the user’s QoS specifications and BRENTA components’ parameter configuration ; and

•

the assessment of current QoS State with respect to the aforementioned FSM [Bhatt99].

The use of fuzzy logic in BRENTA is simply suggested and it is not detailed in this document, since this requires further study. 3.6 References [ACPIv20] “Advanced Configuration and Power Interface Specification”, Rev. 2.0, July 2000. [Aquila00] F. Strohmeier (ed), et al, “Report on the development of measurement utilities for the first trial”, IST-1999-10077, Aquila - Adaptive Resource Control for QoS Using an IP based Layered Architecture, September 2000. [Bhatt99] Sallem N. Bhatti, Graham Knight, “Enabling QoS adaptation decisions for Internet applications”, London, UK, 1999. [Bissel00] T. Bissel, M. Bogen, C. Bonkowski, D. Strecker, “QoS Assessment and Measurement for End-to-End Services”, Proceedings of COST 263 Conference on Quality of Future Internet Services, Berlin, September 2000. [Camp96] A. Campbell, C. Auurecoechea, L. Hauw, “A Review of QoS Architectures”, Proc. Of 4th IFIP International Workshop on Quality of Service (IWQS'96), Paris, France, March 1996 (ftp://ftp.ctr.columbia.edu/CTR-Research/comet/public/papers/96/CAM96a.ps.gz). [Carter96] R. L. Carter, M. E. Crovella, “Dynamic Server Selection using Bandwidth Probing in WideArea Networks”, Tech. Rep. BU-CS-96-007, Computer Science Department, Boston University, March 1996. [Dalgi99] Dalgic and Fang , "Comparision of H.323 and SIP for IP telephony signalling", Proc of photonics east, Sept '99. [D.2.2] IST-1999-100050 BRAIN D.2.2. “BRAIN Architecture specifications and models, functionality and prtocol specifications”, March 2001. [Gamma94] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison Wesley, USA, 1994. [Handl99] Handley et al., “Session Initiation Protocol”, IETF RFC 2543, March 1999. [Handl98] Handley and Jacobson, “Session description protocol”, IETF RFC 2327, April 1998. [H.323] H323 current standard. (http://www.itu.int/itudoc/itu-t/rec/h/s_h323.htm). [HSKKN01] H. Hartenstein, A. Schrader, A. Kassler, M. Krautgaertner, C. Niedermeier, “High Quality Mobile Communication”, in: Proceeding of the KIVS 2001, Hamburg, February 2001.


125 / 229

Del 1.2 Draft v6.03.doc [ITU861] [Jacobs97] [Kassl00]

[Paxson97] [QoSF99] [RFC1890] [RFC1901] [Schulz] [Schulz96] [Stemm00] [Tanen96] [X641R98] [Zadeh74]

Draft / 06.02

29.3.2001

ITU-T Recommendation P.861, “Objective quality measurement of telephone-band (3003400 Hz) speech codecs”, February 1998. V. Jacobson, “pathchar – A Tool to Infer Characteristics of Internet Paths”, 1997 (ftp://ee.lbl.gov/pathchar). A. Kassler, L. Burness, P. Khengar, E. Kovacs, D. Mandato, J. Manner, G. Neureiter, T. Robles, H. Velayos, “BRENTA - Supporting Mobility and Quality of Service for Adaptable Multimedia Communication´, in Proceeding of the IST Mobile Communications Summit 2000, Galway, Ireland, 1-4 October 2000, pp. 403 - 408. V. Paxson, “Measurements and Analysis of End-to-End Internet Dynamics”, Ph.D. thesis, U. C. Berkeley, May 1997. “Introduction to QoS Policies”, QoS Forum White Paper, July 1999. (http://www.qosforum.com). H. Schulzrinne, “RTP Profile for Audio and Video Conferences with Minimal Control”, RFC1890, Jan 1996. J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Introduction to Community-based SNMPv2”, RFC1901, Jan 1996. Schulzrinne, (www.cs.columbia.edu/~hgs/sip/h323-comparision.html). H. Schulzrinne et al., “RTP: A Transport Protocol for Real-Time Applications”, IETF RFC 1889, January 1996. [Singh00] K. Singh, H.Schulzrinne, "Interworking Between SIP/SDP and H.323". Proceedings of the 1st IP-Telephony Workshop (IPTel'2000), April 2000. Mark Stemm, Randy Katz, Srinivasan Seshan, “A Network Measurement Architecture for Adaptive Applications”, Proceedings of IEEE Infocom 2000, Tel Aviv, Israel, March 2000. Computer Networks, Andrew S. Tanenbaum, Prentice Hall, 1996, ISBN 0-13-349945-6. ITU-T Recommendation X.641 (12/97) | ISO/IEC 13236:1998, “Information technology Quality of Service: Framework”. L. A. Zadeh. “Fuzzy Logic and its application to approximate reasoning”, Information Processing, 74:591--594, 1974.


126 / 229


4.

Draft / 06.02

29.3.2001

Example

The following chapter summarises and clarifies many BRENTA functions by working through an example which was derived from the original scenario detailed in [D.1.1] - a life in the day of the character Carol. Key topics already covered in the previous sections of this document are outlined in this example and demonstrate how this work could be put together to solve the requirements raised in the first phase of this project40. Interface functions, protocols and contracts between different instances involved and the interworking of several components as well as the orchestration of the QoS Broker will be illustrated in this example. The applications chosen for this example focussed on point to point oriented real-time applications only (video on demand and videoconference) but in order to simplify the example non real-time and multipoint scenarios are not dealt with here41. It also has to emphasise that it was not intended to deal with other important issues such as localisation, service discovery, security, accounting, and billing which was not the focus of this work. 4.1 The scenario Carol has lunch break and walks to a nearby shopping mall to take her lunch there. Unnoticed, her PDA (Personal Digital Assistant) has registered her to the BigCheese’s HIPERLAN/2 hotspot inside the mall where she takes her lunch and watches trailers of the latest movies offered there. Later, Peter her colleague back in the office calls her because of some urgent business. She has already finished her lunch and continues her conversation with Peter while she walks back to her office. At the same time, the movie trailer continues to be displayed in the corner of her PDA display. When Carol arrives at the premises of her office, she continues both of her running sessions, but seamlessly switches over to the next HIPERLAN/2 area that covers her office complex. When she finally arrives in her office, she has already solved the important work issue with Peter over her PDA and meets him face to face to have over a relaxed after-lunch coffee. Analysing the scenario and taking into account the two services mentioned in the scenario description above, we can identify two VTS' (Virtual Transport Services) at Carols terminal in the initial phase. The first one (VTS-1) is related to the video on demand session, consuming the bandwidth offered by the HIPERLAN/2 cell inside the food court. The second videoconference session, referred as VTS-2, is using the public UMTS service provided by her service provider. Each terminal (PDA and also the VoD server) has implemented the BRENTA stack capable of adapting multimedia services in a fast and dynamic fashion. In order to demonstrate how BRENTA works, each terminal is equipped with some video and speech codecs, which are able to serve and adapt to the requirements illustrated in our example.

40

Business aspects related to the BRAIN business model has been already dealt in [D.1.1] and was not the scope of this document.

41

This phase of the project did not concentrate on multipoint connections, which could be elaborated in a follow up project phase.


127 / 229


Draft / 06.02

29.3.2001

Figure 4.1: Example overview

4.1.1

Goals

Our goals here are to cover representative cases that demands adaptation of the services to the new environments Carol is moving around. Service adaptation (also referred to as QoS adaptation) occurs due to: •

Vertical handover between radio access networks such as HIPERLAN/2 and UMTS as well as from UMTS to HIPERLAN/2 due to user mobility (degradation and upgrade of network resources).

•

New resource allocation due to lack of or even improved local resources.

Derived from the goals mentioned previously, three cases have been selected in order to demonstrate how BRENTA deals with various situations. Scenario I)

In the VoD session, we demonstrate how adaptation is triggered due to fewer available resources at the network level (see § 4.5).

Scenario II)

In the videoconference session, we illustrate how adaptation is triggered having more available network resources gained due to vertical handover from UMTS to the office’s HIPERLAN/2 cell (see § 4.6).

Scenario III) Adaptation of the VoD server session due to the lack of local resources when Carol accepted the invitation to Peters videoconference session. The terminal resources require adaptation because there are not enough resources to start the second session (see § 4.7). 4.2 Setup of connection and negotiation process When Carol first walks into the shopping mall and starts a session in order to watch the latest movie trailers, as well as when she receives the call from Peter, a couple of prerequisite steps need to take place. The involved peers (terminal components in the CEC Deliverable Number 1.2

128 / 229


Draft / 06.02

29.3.2001

broader scope) need to negotiate which capabilities they are going to share as well as how to fix a common adaptation path (see also § 2.6). We assume that the main preferences have been tailored before by exchanging the e2np entries (which are stored in the registry) such as: e2np.terminalA.VTS1= (VoD, RTSP, 01) e2np.terminalA.VTS2= (conversational, SIP, 01) e2np.terminalB.VTS2= (conversational, SIP, 01) e2np.terminalC.VTS1= (VoD, RTSP, 01) What follows is the negotiation of capabilities such as media types and QoS contract dimensions, bitrates, deployed codecs, terminal capabilities and support of network resource reservation through ESI (Extended Socket Interface). All involved parties offer their initial contract parameters and common parameters are taken as a basis for further operation. Note that the agreed adaptation path depends also on the policy, which is part of the preferences or contract and is stored also in a profile. Each terminal proposes the following media types: mediaType.terminalA(Carol) = (audio(1,2,3), video(framerate (1,2,3), framesize(2,3), PSNR (1,2,3))) mediaType.terminalB(BigCheese) = (audio(2,3), video(framerate (3), framesize(2,3), PSNR (1,2,3))) mediaType.terminalC(Peter) = (audio(1,2,3), video(framerate (1,2,3), framesize(2,3), PSNR (2,3))) The next step is then to advertise the available codecs to the negotiating side, which could be done by an extension of SIP at invitation time (see § 2.6.4.2.2). As indicated in the initial figure above, terminal A offers GSM G.711, G.728 codecs for audio streams and MPEG-1 and H263 codecs for multimedia streams. Terminal B offers also GSM G.711, G.728 and only the H263 video stream codec. Terminal C is the Video on Demand server and therefore offers only the MPEG-1 codec. The above mentioned media types and the available codecs are then going to be mapped to bitrates and are in this example the basis for bandwidth reservation at the ESI. As already stated in § 2.6.4.2.2, the target bitrates are influenced by various parameters such as in the case of the video codecs by the frame size, frame rate and image quality. The appropriate parameters needs to be estimated by deploying traffic models (see also § Appendix C.1). For the sake of providing a rough estimate, the videoconference session at a frame size of QCIF (176x144 pixels) with a transmission rate of 12 frames per second and a fairly good video quality coded as MPEG-1 will generate around 600kbps at a constant bitrate, which needs to be reserved at the ESI (see § Appendix B.3). Terminals could announce and register their capabilities by deploying the Composite Capabilities/Preference Profiles framework language as proposed in § 2.4.8. To take an in-depth view into Peter’s terminal (as known as terminal B), the example XML encoded terminal profile already mentioned in § 2.4.8 is depicted again below.


129 / 229


Draft / 06.02

29.3.2001

4.3 Negotiated QoS adaptation path The environment Carol is dealing with causes the involved terminals to adapt to the new situation (optimisation and adaptation due to factors such as the change of radio resources, change of local system availability as well as user driven changes). Her contract profile states that for the VoD as well as the videoconference application 4 adaptation stages are offered, both for video and audio stream. The four adaptation stages are defined in their dimensions for the video stream as frame rate, frame size and visual quality and for audio the audio quality. Each parameter of this QoS profile is scaled into three different stages and accordingly mapped to the 4 QoS states C1 to C4. QoS Profile

VoD

Traffic Contract State Framerate 1:[15-25fps] 2:[5,15] 3:[0,5] Framesize 1:4CIF (704x576 pixels) 2:CIF (352x288 pixels) 3:QCIF (176x144 pixels)

C1 1

C2 1

C3 2

C4 3

C1 3

C2 3

C3 3

C4 3

2

3

3

3

2

3

3

3

2 Visual Quality Note: No colours are taken into account in this example PSNR (Peak Signal to Noise Ratio): 1:Good: >30db 2:Medium: [25,30db] 3:Low: C2:

keep the frame rate of 15 fps (the lowest interval bound) and allow the codec to increase the quantization in order to reduce the quality (below 25dB) as well as to reduce the frame size to QCIF and degrade the audio quality for reducing the resulting bandwidth,

(ii) C1->C2->C3:

reduce further the frame size to 10 fps (ID=2) and the frame rate and quality of video according to state C2 as well as to degrade further the audio quality.

(iii) C1->C2->C3->C4: drastically reducing further the frame rate to below 5fps (ID=3) and keep the other parameters as mentioned in C3. It depends on the QoS policy of the ChC, which is tailored by the priorities. As in our example the frame rate (priority 1) is most important and the visual quality and the frame size is less important (priority 2), the ChC would first lower the visual quality by increasing the quantization, thus reducing bandwidth. If this is still not enough, the ChC could reduce the frame size in order to jump to QoS state C3. If even further reducing the overall consumed bandwidth by drastically reducing the framer ate and thus changing into QoS state C4 is still not sufficient to cope with the resources available, the ChC will forward the QoSviolation.Indication to the Broker. The ChC sends periodically combined usage reports (extracting the most important parameters from the component usage reports) to the Broker according to the QoS contract, i.e. each 1000 ms. The Broker can use these usage reports for the following two reasons: • •

The QoS Broker can detect a QoS violation (i.e. if a interval bound is violated) The QoS Broker can evaluate, if it would be better to move to a new QoS state even if this would not be necessary at the moment in order to prevent state flapping. As an example, if the frame rate varies between 12 and 16 fps (the interval bound is 15 fps) and the quality varies between 23 and 26 dB (the interval bound is 25 fps), it would be better to go further down the degradation path to the new state C3 that needs less resources immediately instead of repeatedly switch between the states.


135 / 229


Draft / 06.02

29.3.2001

At the very end of the handover process, a second primitive Disconnect.Indication sent through the ESI informs about that the HIPERLAN service provided at VTS-1 has been disconnected because the handover has been successfully performed. 4.6 Optimisation of the videoconference session (Scenario II) Our character Carol is heading for her office and the running videoconference session profits due to the vertical handover at the network level from the serving UMTS cell to the HIPERLAN/2 area, which is covering the office complex. We assume that Carol’s terminal A has been operating in the QoS state C3, indicating that in this case the UMTS cell provides less bandwidth capacity compared to the HIPERLAN/2 cell. Carols contract with her home network provider allows her to use the HIPERLAN/2 facilities and the ChC is informed through a QoSviolation.Indication primitive from the ESI indicating that for the given VTS-2 more network resources are available. Analogue to Scenario I (§ 4.5), a second primitive Disconnect.indication sent through the ESI informs about that the UMTS service provided at VTS-2 is ought to be discontinued after the new HIPERLAN/2 sessions has been successfully set up. The Traffic Contract is analogue to Scenario I, except that the priorities are different, which affects the decision for the adaptation path: TCVideoconf = { (framerate,3,3,3), (framesize,3,2,2), (visual quality,3,1,2),(audio quality,3,2,1), (ti, 500, 1000) } The frame rate is fixed in this adaptation example to below 5 fps, since it has the lowest assigned priority. The dimensions that are left over to focus are frame size, visual quality and audio quality, which has been given the highest priority. In order to change the audio quality from telephony (ID=3) to radio (ID=2), we have to move up from QoS state C3 to C1. The ChC setups and controls the new media procession chain that receives from the associated component Usage Reports (UR) that there is no violation detected due to enough resources available both at the network level (HIPERLAN/2 cell) and local resources (CPU power, memory, battery power, etc.). Beforehand, the ChC informs the QoS broker about the planned changes and the according component changes are executed and used components are disconnected from the media stream. 4.7 Adaptation due lack of local resources (Scenario III) We know from the initial story above that Carol receives in the BigCheese foodcourt the invitation from Peter to share a face-to-face videoconference. She accepts the invitation, but at the same time she is still running the movie trailer VoD session, which cannot being continued at the current quality (C1) because her terminal needs some processing power for the videoconference session in advance. Information about local resource usage is done at the Resource Manager level, which collects information from the Resource Controllers by deploying the wrapper concept (see § 3.4.5 and Appendix A.3.1). We assume at this point that the CPU usage is also treated similarly to the frame-grabber Traffic Contract mentioned in Scenario I. URCPU Manager.VOD = {(usage,3)} Note: Because the CPU Manager is highly OS and implementation dependent, we do not provide here a more detailed level of how CPU power could be expressed


136 / 229


Draft / 06.02

29.3.2001

and how the usage of CPU power is estimated in advance to setup the TC accordingly. When negotiation for the additional videoconference session takes place, the CPU manager indicates through the QoSviolation.Indication sent to the ChC that the new videoconference session can not be performed even at the lowest QoS state (C4). This means there is no room to adapt except to reduce CPU consumption of the running VoD session to free resources. This is done by reducing the QoS State of the VoD session from C1 to C4, analogue to the Scenario I (§ 4.5 and § 2.6.7). By doing this, the frame rate, the frame size, the video and audio quality of the VoD session have been drastically reduced in order to free CPU power for the videoconference session. The next Usage Report of the videoconference session confirms that the CPU resources are available and no further local resources are needed. 4.8 References [D.1.1]

IST-1999-100050 BRAIN D.1.1. “Scenarios for mobile IP services and resulting requirements in different wireless networks”, August 2000.


137 / 229


5.

Draft / 06.02

29.3.2001

Discussion and Conclusion

5.1 Evaluation Along this document we have introduced an architecture that combines broadband radio access technology based on the HIPERLAN/2 standard, with other wireless access network technologies (like UMTS), to enable full coverage of seamless IP-based services for users in hot spot areas and on the move. Whereas wireless broadband networking provides new challenges and benefits for applications, adaptable applications are necessary to support Quality of Service (QoS) towards the user in a heterogeneous network scenario including broadband wireless and "standard" wireless access technology. The BRAIN end terminal architecture (BRENTA), described in this work, provides end to end QoS support, mobility management and adaptation mechanisms. Given the difficulty to provide end to end QoS support in a wireless environment, a set of mechanisms, such as user preferences definition and adaptation paths, were defined in order to allow the system to react on QoS violations in a predefined way. When defining the architecture, one of the main requirements we imposed ourselves was to allow existing applications, even with no QoS support, to run on BRENTA. We think this is the key point if we want BRENTA to be successful. For this reason we started with a classification of applications on four different groups depending on their QoS awareness and the way the four defined application classes were supported by BRENTA. Mobility is another key point supported by the architecture, providing adaptation mechanism to services taking care of user preferences expressed on profiles, managing terminal and network resources. 5.1.1

End Terminal QoS Broker Scenario

From the very beginning BRENTA was intended to allow the negotiation and enforcement of quality of service parameters from the user and its application to the network. Under this perspective BRENTA’s Object Oriented Design led to a component supporting framework, which offers functionality similar to QoS-A (see § 2.4.3). In addition, it provides mobility support and explicitly distinguishes different application types that are supported. From a different perspective, we can see BRENTA like a generalisation of the architecture introduced and successfully experimented in IST project CATSERVER [CATSE] for the QoS management in CATV network A (see § 5.1.2). Furthermore the choice of Internet level for quality of service resolution is a confirmation of the choice made in CATSERVER and in IETF working groups (IPCDN). However the quality of service perceived by the user do not depend only on the network performances, it can also depend in the local resource (CPU, memory) of the used system. For example the hearing of an MP3 could be disturbed by CPU burstiness caused by other applications, like word processing, etc. Therefore there is a legitimate need to involve local resource management in the QoS negotiation and management, which is integrated in our framework. At this level there are the following fundamental alternatives of management entity architecture:


138 / 229


Draft / 06.02

29.3.2001

- The separation of QoS management (see Figure 5.1) -

The merge of QoS management (see Figure 5.1)

User/appli

User/appli

BRENTA ChC / ESL

OS

Network

OS

Figure 5.1: Separated QoS management (Type D App.)

User/appli

User/appli

BRENTA OS

OS Network

Figure 5.2: Merged QoS management (Type C App.)

It must be clear that BRENTA is handling management entities and is not addressing the implementation layering. Therefore the components in the architecture are management component and not system layers. In the separated QoS management (type D applications), where the application is not aware of the streaming media and does not care about QoS management and negotiation (because BRENTA does the job on behalf of applications) the BRENTA architecture manages and co-ordinates available resources locally (via resource controllers), in the network (via the ESI). BRENTA provides on the peer host (using the E2NP) a local QoS monitoring functionality and an interface between user/application and the QoS management architecture itself. In this alternative the interaction between fundamental components is the following: •

Local user/ applications identify the envelope of acceptable QoS parameters that can be supported.

•

The user/ applications delegate the negotiation of the envelope of acceptable QoS parameters that can be supported by both hosts and by user profile to the QoS management architecture. The user/ applications submit to BRENTA QoS Broker their envelope of acceptable QoS parameter.

•


139 / 229


Draft / 06.02

29.3.2001

•

BRENTA QoS Broker returns the accepted envelope of QoS parameters (coordinated locally and on the peers) and proceeds to external resource reservation (e.g. via the ESI and RSVP).

•

The components of the BRENTA start the processing and transmission, which in turn is managed by the broker.

In the merged QoS management (type C application) BRENTA can take in charge both local and external management. In this case the interactions between the fundamental component reduce to the following: •

BRENTA mediates between user and application and fixes the envelope of acceptable QoS parameters according to user and application profiles; in addition, the application can directly negotiate using e.g. SIP/SDP

•

BRENTA can negotiate and reserve the accepted QoS parameters with peer system;

•

BRENTA returns parameters to user/applications;

•

BRENTA only manages network resources by providing access to the ESI;

•

Applications manage their own resources with the host operating system.

The separated QoS management has the advantage to unify the QoS management. However, although it looks simpler than merged management, separated QoS management contains several drawbacks that may divert the attraction of this concept. 1. It introduces a layer between application and OS; however as BRENTA is modular and platform independent, BRENTA has just to provide the add-on on the target platform that is required to provide the dedicated functionality. As an example, if some host operating system support the reservation of CPU cycles and processing power for dedicated tasks, the CPU management and Controller would just provide wrapper functionality (for example the RT-Mach). On other target platforms where only best effort CPU management is available, the CPU Manager and Controller would provide the functionality that is necessary to reserve the resources on behalf of the application. 2. It introduces some security gap by too closely connecting network and operating system. However, security considerations are out of the scope of this work. 3. It introduces management complication due to the extreme diversity of resource management (CPU, memory, power management). Nevertheless, this is required to manage QoS and can not be avoided. We considered this complication in the design and delegated it to the broker that manages and co-ordinates. The broker is supported by QoS decision policies that help in deciding the correct actions to be performed. Let consider the complexity of the connection between memory management and power management. If real-time applications have fixed memory allocation, then there will be less free memory for other applications that may swap on the hard disk. Since hard disk swap reduce battery autonomy, there is a potential conflict with power management. Existing applications may have their own resources management (type A applications) that can coexist with BRENTA management. For that purpose, the resource controllers can reserve a portion of the available resources for legacy applications (e.g. the CPU Controller may reserve only up to 90% CPU for type C and D applications and other applications may share the remaining 10%). For example the game 4x4 evolution has a


140 / 229


Draft / 06.02

29.3.2001

multi-player mode, it also enables the cycle increase of processor that reduces battery lifetime and affect CPU management. The implementation will have to make a serious deal with the operating system and maybe some particular specifications would be impossible to implement above some operating system. For example the CPU management is the kind of elements whose feasibility would highly depend on the operating system. Furthermore some architecture like multi-processor would need special adaptation of the specification, but this extreme case may not likely to happen. Moreover this independence to OS may in certain case be favoured by agent implementation or even by plug-in approach. In this perspective, the components could be changed in line when new software becomes available. The user preferences may be difficult to handle in its diversity. For example the user may want to follow several video sources, but only one really has its full attention. This occurs when the user follows several socket contests or a single socket contest with several angles in a socket contest, or several TV channels, or several angles in video surveillance. In this case the user may want to have on one hand high quality but not real timeliness on the channel he focuses on, and in the other hand to have real timeliness but medium bad quality on the other channels. With this combination the user (which could be a TV operator) could switch as fast as possible to the angle where the action happens. Or it may be any other kind of exotic combinations. This kind of situations are managed by BRENTA, since it allows to define, for each video, the desired QoS parameters and tell the ChC to switch after negotiating. The users' preferences can be handled implicitly with CC/PP (see § 2.4.8). The remaining challenge is thus to provide intelligent user interfaces to apply the correct profiles for different situations (note, that BRENTA allows to select different profiles). As type D applications mainly deal with their own business logic and GUI and delegate the streaming to BRENTA, these applications could concentrate on intelligent GUIs. Provided these uncertainties the separated QoS management seems more natural and safer, especially in the perspective of an evolutionary route of BRAIN network and in consideration of the scope of the project (which should be network and internet oriented). Having identified the drawbacks and advantages, the BRAIN project has selected to provide the application with the freedom to choose between the merged QoS management approach for type C applications that mainly use components and that are free to use any component they would like. On the other hand type C applications would use the full functionality of the framework making them very easy to implement by delegating all the management jobs to the framework. In particular, the applications of type A and B don’t use BRAIN management (application of type A is just above transport layer), and applications of type C and D use BRENTA, application D uses top level BRAIN API together with the broker and are the ultimate goal of BRENTA vision. However, some of the algorithms needed for this local management have not been identified nor specified. Due to its complexity it seems premature to use and specify the separated QoS management without complete investigation of the algorithms needed for this management. Consequently the qualitative analysis of management components was incomplete. Due to its close relation with algorithmic and implementation issues, some component descriptions may need to be reviewed at design time, once a target platform is defined.


141 / 229


5.1.2

Draft / 06.02

29.3.2001

Comparison with other architectures

Recently, a quite large number of QoS architectures and frameworks evolved. In principal, we can classify the architectures according to the area they are targeting. While some architectures focus on mechanisms at network layer and below, others are more interested in mechanisms above network layer and finally there are frameworks providing integral functionality. In addition, some architectures rely on functionality put inside the network (like active routers or proxy servers). Also there are some architectures that provide inherent support for mobility. The problem in those cases is that those architectures only target at functionality below network layer and do not consider adaptation mechanisms at higher layers. They just consider integrated applications that are tightly coupled with the architecture itself, which is not desirable, because it limits flexibility. In this section we compare our architecture with other QoS architectures and frameworks and analyse the difference with state of the art solutions. We start by providing a short overview on what we believe are the most important architectures and then try to put our architecture in the overall picture. A non exhausted survey providing an excellent overview on the architectures can be found at [Aurre98a] which does however not include specific mobility oriented QoS frameworks. In this section, we do however not compare our solution with the solution adopted by ETSI [ETSIR03] or the ITU-T | ISO/IEC QoS Framework [X641R98a], since this will be done in the Appendix. We therefore refer the reader to Appendix A, which provides the key concepts of ITU-T | ISO/IEC QoS Framework (like QoS Characteristics, layering principle, or QoS mechanisms). The most well known QoS architectures at network layer are the Integrated Services [Brade94] (IntServ) and the Differentiated Services [Blake] (DiffServ) architecture. The IntServ framework was designed to provide special handling for certain types of traffic and to provide a mechanism for applications to choose between multiple levels of delivery services for its traffic. For IntServ, QoS defines the nature of the packet delivery service provided by the network, which is characterised by a certain set of parameters. In contrast to IntServ, the DiffServ approach tries to avoid complex softstate information as needed by RSVP. DiffServ allows aggregating traffic classification state, which makes it more scalable. Packets are classified and marked to receive a particular per-hop forwarding behaviour (PHB) on nodes along their path. As these are pure network layer QoS architectures they can provide a basis for an integrated QoS architecture using the Internet model. In order to support mobility and wireless links, some additions have to be provided for IntServ, especially for its signalling protocol RSVP [Brade97] to work properly. In this comparison we do not include IntServ and DiffServ because we are targeting at an integrated QoS architecture that provides network layer QoS functionality and higher layer QoS management in order to provide QoS to adaptable applications or even to build a framework that provides adaptable services and QoS support. More information on IntServ and DiffServ can be found in [D.2.2]. The OMEGA QoS architecture [Nahr95a], [Nahr95b] is an application level End-to-End QoS architecture that focuses on QoS support at the end-system. It builds on top of a QoS-enabled network (in their wok it is based on ATM). Intermediate nodes are not included into the architecture. At the end-system, OMEGA uses a layered model. On top the user has certain QoS requirements, which are forwarded to a QoS-enabled application, which runs on an operating system that must fulfil system level QoS requirements. Devices are modelled by device QoS and the QoS enabled network by network QoS. A QoS Broker orchestrates, controls, and maintains all types of QoS. It interacts with the user, application, operating system and network. The QoS Broker


142 / 229


Draft / 06.02

29.3.2001

enforces QoS at the end-system using real-time operating system mechanisms and communicates with the peer QoS Broker by exchanging the necessary QoS information. The brokers can play different roles depending on the scenario: buying or selling resources and sending or receiving streams. OMEGA does however not provide support for mobile hosts and network level QoS mechanisms are focused on ATM networks. Also, multiparty support for heterogeneous receivers is missing. We inherit the valid concept of the QoS Broker as a co-ordination facility for orchestrating and negotiating QoS locally and at the peers. The NEC QoS architecture is based on CORBA [Wein98] and provides support for QoS sensitive multimedia applications. It tries to use and integrate the functionality of audio/video-streaming extensions for CORBA in order to allow for a building-block approach. Using this architecture it will be easy to create Internet services. The architecture features open interfaces to network entities and QoS sensitive multimedia services. However, using CORBA as an integral part of the architecture limits the scope of it. Additionally, mobility is not supported. Also, only network level QoS adaptation is possible with this architecture. There is no support for QoS scaling for the media streams, so it is rather difficult to provide adaptable services. QoS management in the network is missing and the framework only works properly if all network-based applications are build on top of the virtual services provided by the architecture. Also, the QoS strategies of this architecture have no influence on other flows that also may exist within the network, so prioritisation of flows is difficult to achieve. AQUA [Laks96] is QoS architecture for managing resources at the end-system. Nevertheless, a common framework for managing different kind of end-system resources is presented including the adaptive and dynamic nature of multimedia applications. Network QoS mechanisms are not considered by AQUA. It rather relays on a QoS enabled network (they use ATM as a basis). Also, mobility is not supported. However, AQUA provides the necessary end-system mechanisms for applying adaptive QoS strategies to the resource management system of AQUA. We inherit from AQUA the manager-controller design paradigm and the idea to treat profiles like another resource. The Lancaster QoS-A [Camp94] is an integrated, layered QoS architecture, which incorporates network QoS management, QoS scaling and filtering mechanisms. It also includes management of the end-systems and network nodes. Within QoS-A, flows represent single media streams (audio or video) that originate at an end-system and terminate at an end-system travelling through the network. Service contracts are binding agreements between the service user and provider. Flow management allows monitoring and maintenance of the QoS levels that were specified within the service contract. Several layers and planes are managed throughout QoS-A. The physical, data link and network layers provide basic End-to-End QoS support. On top, the transport layer provides a range of configurable protocols and the orchestration layer allows for jitter correction and multimedia synchronisation across multiple related flows. Finally, the distributed systems platform provides for multimedia communication. The protocol plane is split into control and user part. The QoS maintenance plane is responsible for the user contract and fine-grained flow control. Finally, the flow management plane is responsible for flow establishment, QoS re-negotiation and QoS adaptation. It uses QoS managers performing the fine-grained monitoring and maintenance of their associated protocol entities. In [Camp96] including a framework for control enhances the QoS-A and management of multi-layer coded flows. For that the dynamic QoS management (DQM) was introduced that enables End-to-End rate shaping, which adapts the rate of multi-layer flows to the available network resources and uses an adaptive network


143 / 229


Draft / 06.02

29.3.2001

service. QoS-A can be seen as an integral QoS architecture, which integrates network and end-system QoS aspects. However, QoS-A only works for applications that use QoS-A API. Therefore, legacy non-QoS applications (i.e. Type A applications in our terminology) cannot be easily supported. In addition, there is no central intelligence, where the overall QoS policy is selected. The managers do not really co-operate and are not controlled. Also, mobility is not supported. AMNet [Witt97], [Witt98] focuses on heterogeneous multimedia communication and provides mechanisms for QoS filtering and scaling within network nodes. It uses RSVP for signalling QoS at network layer and defines QoS filters on active components within the network that perform the QoS scaling. AMNet uses an RSVP daemon, a QoS filter (QF) daemon to dynamically receive QoS filter object information via RSVP, and then tunes the QoS filter accordingly. AMNet only focuses on dynamic filtering mechanisms inside the network to adapt to receiver requirements in multicast scenarios. End-system QoS is not addressed and it depends on the underlying network technologies for providing the QoS. Also, mobility is not supported. The NEC framework for providing adaptive QoS [Ott97] tries to introduce adaptive QoS into every layer of distributed and heterogeneous multimedia systems. For achieving this goal, QoS is specified by the means of contracts, which are established between clients and service providers using a single, generic API. This API can be recursively applied to all levels of the hierarchy using different levels of detail thus building a service hierarchy, which constitutes QoS for the whole system. At network level, a dynamic network service contract is used to support user-initiated renegotiations. However, this architecture does not specify mechanisms for handling multi-party conferencing. Also, a QoS orchestration entity responsible for QoS management is missing. We inherit the idea of the QoS contract but include also the FSM and adaptation path into the contract. Also, the above framework does not include support for mobility related QoS management. The CooQoS Management Architecture [Hafid98] is a network centric QoS architecture that addresses multicast and scalability issues using distributed co-operative QoS management. The main part of this architecture is represented by application-oriented QoS agents, which are distributed throughout the network and the end systems. The QoS agent is responsible for QoS management, especially for QoS (re-)negotiation, QoS mapping, resource reservation, QoS monitoring and QoS adaptation. An interagent protocol is defined around the concept of QoS violation, QoS solve and QoS persuade messages. The proposed architecture does not describe how adaptation mechanisms can be included. Also, inter stream dependency with respect to QoS or synchronisation is not taken into account as all application streams have separate communication channels for their QoS agents, which are not controlled by a central entity. Also mobility management is not included into the architecture. In addition to the architectures mentioned so far, other QoS architectures can be found in [Aurre98a] like the Heidelberg QoS architecture, XRM, Tenet, TINA, MASI or the Washington End-system QoS architectures which do not feature support for mobility. The next group of architectures we are presenting does inherently support mobility, but are either closed in a sense that the architecture is closely coupled with the application or with a given network. Also, almost all of these architectures are focus on physical, data link layer or network layer QoS mechanisms and do not orchestrate QoS throughout the system. In particular we mention the Adaptive QoS Framework for Multimedia in Wireless Networks (AQuaFWiN) [Vanda99], where the applications are CEC Deliverable Number 1.2

144 / 229


Draft / 06.02

29.3.2001

tightly coupled with the rest of the framework but no API is provided. The network elements have to be AQuaFWiN aware in order to support AQuaFWiN specific mobility management. Also, media adaptation in the network to bridge heterogeneity is not considered. An adaptive mobile multimedia networks architecture [Alwan96] for a "3M" environment (real-time Multimedia, Multihop and Mobile) was designed and implemented in the WAMIS (wireless adaptive multimedia information system) project. WAMIS is an integral QoS architecture that supports the QoS enhanced transmission of compressed audio and video streams. However, WAMIS is tightly coupled with the media compression technology that was developed for WAMIS and no network adaptation mechanism is available for heterogeneous communication partners. Also, no resource management at the end-systems is deployed. As an integral architecture it is difficult for WAMIS end-systems to communicate with standard end-systems. The Seamless Wireless ATM Network (SWAN) [Agra96] is an indoor wireless network built to support integrated services (multimedia) in a wireless environment. It provides a flexible platform for adaptive applications. SWAN only provides the networking functionality to support QoS in a mobile environment at network layer. Applications nevertheless have to be adaptive in order to react to hand-offs where the quality of the link changes. Network adaptation of the multimedia streams is not considered. In addition, resource management is only performed for the network resources due to the use of ATM inside the end-system. All other resources are not managed. The Multimedia support for Mobile Wireless Network (MMWN) system [Rama98] uses adaptive link and network layer algorithms to support QoS in large, multihop mobile wireless networks. Nodes organise themselves into hierarchical control structure. Similar to SWAN, MMWN focuses on the network architecture, which is necessary in a mobile environment in order to support QoS. Neither application layer techniques nor resource management at the end-nodes are considered. However, MMWN provides mechanisms for enforcing QoS at network layer in the presence of mobility. Also, media stream management is not considered. The rest of this paragraph finally highlights the points of contact and the differences between the aforementioned CATSERVER [CATSE] and BRENTA. The CATSERVER project was an ESPRIT project, whose aim was to design and implement multimedia services over CATV networks. The physical architecture of a CATV network is very similar to a BRAIN network in the sense that on CATV there are enduser cable modem connected to central head-end, and in BRAIN networks there are mobile nodes around a central BRAIN access point. Therefore it is natural that both projects end with similar logical architecture. Notice that the QoS controller is very similar to BRENTA since the QoS controller is hosted by terminal nodes and interfaces with applications. Indeed the QoS controller maps QoS application requirement to QoS proxy parameters (bit rate, service class, delay). It also forwards these parameters to the local manager of the QoS stack. For each reservation request the QoS controller forwards a list application acceptable QoS parameters tuple. The QoS proxy is kind a centralised version of the QoS Broker (this terminology was not fully spread at this time). It monitors the resource of the CATV networks (downstream and upstream channels) and keeps track of the bandwidth reservation. For each reservation request from the QoS controller it returns one accepted QoS among the list of acceptable QoS parameters submitted by the QoS controller for a given flow. It performs an admission control based on service class (not fully implemented). It also CEC Deliverable Number 1.2

145 / 229


Draft / 06.02

29.3.2001

keeps memory of the list of acceptable QoS tuple per flow in order to accelerate renegotiation when the bandwidth use is changing (for example when a new admission occurs). CATSERVER supports conferencing scenario, which has been experimented on the actual implementation. On the other hand, for obvious reasons CATSERVER is restricted to fixed network and therefore it does neither address mobility, nor manage several remote head-end together (although this was an identified extension) compared to BRAIN, which has to manage several access points together). For obvious reasons CATSERVER is restricted to fixed network and does not address mobility aspect. With this aspect we can see that CATSERVER is a kind of subset of BRAIN restricted to a specific network. CATSERVER does not also manage several remote head-ends together, although it was an identified extension. Therefore this is another difference with BRAIN, which has to manage several access points together. 5.2 References [Agra96]

P. Agrawal and E. Hyden and P. Krzyzanowski and P. Mishra and M. Srivastava and J. Trotter, “SWAN: A Mobile Multimedia Wireless Network”, IEEE Personal Communications, April 1996. [Alwan96] A. Alwan and R. Bagrodia and N. Bambos and M. Gerla and L. Kleinrock and J. Short and J. Villasenor, “Adaptive Mobile Multimedia Networks”, in IEEE Communications Magazine, vol. 34 no. 4, April 1996. [Aurre98a] C. Aurrecoechea, A. T. Campbell, L. Hauw, “A Survey of QoS Architectures”, ACM/Springer Verlag Multimedia Systems Journal, Special Issue on QoS Architecture, Vol. 6 No. 3, pg. 138-151, May 1998. [Blake] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, IETF Network Working Group. [Brade94] R. Braden, D. Clark, and S. Shenker, “Integrated Services in the Internet Architecture: An Overview”, IETF RFC 1633, June 1994. [Brade97] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, RFC 2205, September 1997, Proposed Standard (ftp://ftp.isi.edu/in-notes/rfc2205.txt). [Camp94] A. Campbell, G. Coulson and D. Hutchinson, “A Quality of Service Architecture”, ACM Computer Communications Review, April 1994. [Camp96] A. Campbell, G. Coulson and D. Hutchison, “Supporting Adaptive Flows in a Quality of Service Architecture”, ACM Multimedia Systems Journal 1996. [CATSE] CATV Networks: demonstration of a new generation of multimedia internet SERVERS, CATSERVER: ESPRIT Project N. 25046, 1998-2000. [D.2.2] IST-1999-100050 BRAIN D.2.2. “BRAIN Architecture specifications and models, functionality and protocol specifications”, March 2001. [ETSIR03] ETR 003: Network Aspects (NA); General aspects of Quality of Service (QoS) and Network Performance (NP) - 2nd edition. [Hafid98] A. Hafid, S. Fischer: “A Multi-Agent Architecture for Cooperative Quality of Service Management”, in Management of Multimedia Networks and Services (Proceedings of MMNS'97), pages 41-54, Chapman & Hall, London, 1998. [Laks96] K. Lakshman and Raj Yavatkar, “AQUA: An Adaptive End-System Quality of Service Architecture”, High Speed for Multimedia Applications, pp. 155-177, Kluwer Academic Publishers, 1996. [Nahr95a] K. Nahrstedt: “An Architecture for End-to-End Quality of Service Provision and its Experimental Validation”, PhD thesis, Department of Computer and Information Science, University of Pennsylvania, August 1995. [Nahr95b] K. Nahrstedt and J. Smith, “The QoS Broker”, IEEE Multimedia, 2(1): 53-67, Spring 1995. [Ott97] M. Ott, G. Michelitsch, D. Reininger and G. Welling, “An Architecture for Adaptive QoS and its Application to Multimedia Systems Design”, Special Issue of Computer Communications on Building Quality of Service into Distributed Systems, 1997. [Vanda99] B. Vandalore et al. “AQuaFWiN: Adaptive QoS Framework for Multimedia in Wireless Networks and its Comparison with other QoS Frameworks”, In: Proceedings of the LCN '99, October 1999.


146 / 229


Draft / 06.02

29.3.2001

[Wein98]

S. Weinstein, M. Suzuki, J.P. Redlich and S. Rao, “A Distributed Object Architecture for QoS-Sensitive Networking”, Proc. IEEE OpenArch’98, San Francisco, CA, pp.3-13. [Witt97] R. Wittmann and M. Zitterbart, “Towards support for heterogeneous Multimedia Communications”, Fifth IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS'97), Tunis, Tunisia, October 29-31, 1997. [Witt98] R. Wittmann and M. Zitterbart, “AMnet: Active Multicasting Network”, Proc. of IEEE Intern. Conf. on Communications (ICC'98), Atlanta, GA, USA, June 1998. [X641R98a] ITU-T Recommendation X.641 (12/97) | ISO/IEC 13236:1998, Information technology Quality of Service: Framework.


147 / 229

Appendix ADerived Requirements for BRENTA A.1Use Cases A.1.1

Introduction

Deliverable D.1.1 [D.1.1] of BRAIN project identifies the requirements on the building blocks -for example mobility management and authentication - which will be needed to build the BRAIN system. In D.1.1 deliverable we arrived at carefully chosen scenarios and at requirements we believe will be needed for the BRAIN system by looking into the future at the behaviour of users and the provision of service to them. [D.1.1] also developed a business model for systems beyond 3G. This chapter provides formalisation by the means of UML diagrams [Booch98] the key requirements identified in [D.1.1]. These Diagrams will be further complemented whit Diagrams describing the proposed architecture for the BRAIN terminal [Neure00]. We start presenting the overall model of the BRAIN services, and then we present Providers and Users point of view of the services. Finally we describe provide a description for the three scenarios presented in [D.1.1]. A.1.2

BRAIN Overall Model

The BRAIN general model identified in [D.1.1] is described in Figure 5.1. In this model we can see how the final user (Service User) communicate with the available Interactive Services (interactive Service Instance). Service providers offer services that will be access by the Users by the means of Terminal. The provisions of services will base on the availability of several resources. Those resources must managed by the BRAIN system.

Figure 5.1: Overall BRAIN model


148 / 229


A.1.3

Draft / 06.02

29.3.2001

Providers Viewpoint

In the BRAIN System there are several players. They may be divided in two main groups: users and providers. Meanwhile users ask for an integrated service, without worrying about how it is providers, Providers has to combine different technologies to satisfy the users’ demands. A.1.3.1 Service Providers

Figure 5.1.2 describes how Contents Provider collaborates in the process of content provision. Advertisers and Contents Production are the two main content inputs to the systems. Application providers will transform the contents for adapting them to the different applications and environments. Content adaptation is very important in BRAIN because the users will access services from many terminals, expecting to have always the same appearance. Proxy service is a network service that also provides contents adaptation. Revenue flows are not considered in this diagram.

Advertiser

Content Adaptation

Provide advertisement content

Proxy Service Provider

Content Production

Content transformation Content Service Application Provider Service Provider Figure 5.1.2: Content Providers

Figure 5.1.3 describes how the Service user will access the services. S e r v ic e P r o v id e r g e n e ra liz e s th e c o m m o n a s p e c ts o f a ll th e v a rio u s t y p e s o f p ro v id e rs

S e r v ic e

O ff e r S e r v ic e

S e r v ic e M a n a g e m e n t

S e r v ic e P r o v id e r

C o n t e n t D e liv e r y

b ro k e r

S e r v ic e U s e r

Q o S C o n tr a c t E n f o r c e m e n t

Q o S B ro k e r

Figure 5.1.3: Service Providers


149 / 229


Draft / 06.02

29.3.2001

In our model the Service Provider role generalises the common aspects of all the various types of providers. The service provider will manage and co-ordinate different single services, playing also the role of a Service Broker. The BRAIN network, under the conditions agreed between the user and the QoS Broker, will distribute contents provided by different services. Certain services may be associated to a QoS level; it is the users final decision, which QoS contract to sign in order to receive the contents in a good enough shape. A.1.3.2 Subscription to a Service

Before accessing the services, the user has to subscribe to them. The application service provider will provide the Service providers to offer services to the user will use applications. Nevertheless the service provider must agree with the Proxy Service Provider and the Infrastructure Service provider in order to be able to have good enough connections for those applications supported by the QoS contract (see Figure 5.1.4). Such services providers will them agree with the user and the Network Service Provider in a QoS contract for supporting future content delivery. The business polities for supporting this process is out of this schema, meanwhile it may be based on open standard and platform, or specific negotiations among involved actors.

Netw ork Service Provider

Proxy Service Provider

Infrastructure Service Provider

Establish Cooperation Q oS Contract Service User Enforcem ent

Get access to uses Service Provider

Application Service Provider

Application

Figure 5.1.4: Access Management

The second part in the subscription management is to maintain and control the subscription of the user to a certain service. Service Provider and Service User must collaborate throw several procedures (see Figure 5.1.5): subscribe and update subscription, which implies the (re)negotiation of the QoS contract, and the unsubscribe procedure. The service provider has to maintain information about subscriptions, for billing and accounting, service statistics and for future negotiations with networks, infrastructure, proxy and applications providers.


150 / 229


Draft / 06.02

29.3.2001

Service Provider

Subscribe

Maintain subscriptions

Establish QoS Contract

Update subscription

Unsubscribe

Service User Figure 5.1.5: Subscription Management

A.1.4

The Problem Domain

[D.1.1] provides a generic business model, which is considered to apply for many business cases within BRAIN. Figure 5.1.6 represents this model. Further examples of the application of this model will be shown for the usage cases described in [D.1.1]. Figure 5.1.6 describes how different services providers will combines their services in an open interconnection basic for providing BRAIN users with final services. This model identifies many service providers' roles. In the real world the same company must play different roles, but still it is interesting to maintain interfaces between different roles. This will enforce the provision of services to other services providers, and will clarify how and where companies are making money and how they can retains clients that are users. This model opens many possibilities for incoming companies that do not need to provide all the services, but just to integrate their services in this open model. Companies. It also offers the possibility for a fast creation and integration of new services and applications to be integrated this model for well-established companies.


151 / 229


Draft / 06.02

29.3.2001

Figure 5.1.6: The BRAIN business model

A.1.5

Users Point of View

The Service User will access to BRAIN services directly form the PWA as described in [D.1.1]. This will require the creation of user profiles. User profiles are described in Figure 5.1.7. User's profiles play a key role in the QoS policies to be applied by the BRAIN Network. User profiles identify user’s requirements and constraint about the services he want to how. Those requirements will mainly impact available resources and how these resources will be charged. Other information to be included in these profiles will refer to customisation of services and applications when the users change form one PWA to another.


152 / 229


Draft / 06.02

29.3.2001

Figure 5.1.7: User's profiles

In the BRAIN System, User's profiles are a key parameter for any access to services and application, as shown in Figure 5.1.8, concerning the three scenarios identifies in Deliverable 1.1 [D.1.1]. Diagrams for each scenario will be provided in section 5.1.6 (Usage scenarios).

Figure5.1.8: User's Profiles and usage scenarios


153 / 229


Draft / 06.02

29.3.2001

Figure 5.1.9 shows the relation of the VTS (Virtual Terminal Service) concept in the BRAIN framework. VTS plays a key role in BRAIN, because it allows applications to use connections (throw different access services) transparently. VTS will be used by the applications as a specific instance of the general Terminal Service in order to isolate from the problems related with the real connections. The user will access BRAIN services by the use of the corresponding applications. Such application selects one of the user profiles, and then uses the corresponding VTS to access the connection service. Meanwhile the user is working with the application some handover operations may occur. If horizontal handover happens, there is not any implication for the connection service, form the point of view of the IP service. But if a vertical handover happens, the VTS has to deal the problems related with the switching from the old network to the new one. So VTS is the responsible of reallocating all the resources, including QoS support from the all connection thought the all access service to the new one. This process has to be co-ordinated with the QoS Broker and the mobility management service.

QoS Contract Enforcement

Select User Profile

Mobility Management

Connection Service User

Application

Network Service

Virtual Terminal Service

Connection Service Terminal Service

Network Service

Figure 5.1.9: Virtual Terminal Service usage

A.1.6

Usage Scenarios

In this section we show how the previous model instantiated for one of the scenarios proposed in [D.1.1]. Three scenarios were identified in [D.1.1]: 1.

Leisure-time – A scenario which demonstrates that users may wish to be connected to HIPERLAN/2 for low cost and high bandwidth in the home or shopping mall but will also want to connect to cellular technologies (e.g. UMTS or GPRS) from the same terminal and access the same services. In particular, the users in this scenario require support for vertical handover between the two technologies.

2.

Nomadic worker – In this scenario we have looked at a future corporate worker, demonstrating that HIPERLAN/2 may be used as part of office intranets providing integration with fixed intranets. The scenario also produces the idea of profiles – when on company business a worker requires different preferences, charging strategies etc. than when on personal business, but will want to use only one terminal and access the same basic services, such as e-mail.


154 / 229


3.

Draft / 06.02

29.3.2001

Medical care – This scenario demonstrates a specialised application of the BRAIN system. The main point arising from this scenario is that users can have very different priorities for the supply of the same quality service – in this case the patient being monitored requires absolute priority.

In this section we will provide the UML model for each scenario. A.1.6.1 Leisure Time scenario

In this case we concentrate in the first part of the Leisure Time scenario, when the BRAIN user (Sandy) is at the BigStore. In this scenario Sandy uses four different applications: e-commerce, on-line gaming and chat and videoconference. Specifically at the first part of the usage scenario Sandy uses chat, Video Conference and e-commerce applications. While Sandy is in the BigStore, services are provided by the BigStore Service Provider, which plays several roles: Network Service provider, Application Service Provider, Infrastructure Service Provider and Content Service Provider. Other roles described in the general business model are not taken into consideration for the sake of simplicity. It is not of course required the BigStore Operator will directly manage all these services, but he co-ordinates all of them, and is the final responsible form the users point of view. So in this case the BigStore Operator offers to the users a complete set of services for satisfying all the user’s requirements. Nevertheless the user wants to access some services provide by the Bob’s cheese store. In this case using the connection services provided by the BigStore Sandy connect with theBob0s cheese store. This connection requires the usage of external connections provided by the BigStore thought some public IP Service provider. So in this case Sandy access transparently to Bob’s cheese store services completing the shopping of such special Feta cheese she need for the Salad. It is important to note how Bob’s cheese services just deal with content service provision, relaying on public IP service providers for other user' services. It is also important to note how most of the services used by Sandy takes advantage of the users profiles defined by Sandy. Those users profile permits: Sandy receives authorisation for using some kind of services, services are personalised to Sandy’s preferences, etc. Unless in this example we do not deal with the next step in the scenario: when Sandy leaves the BigStore, we show how connection services will use handover services for providing seamless services to Sandy. In this case two networks are involved: BigsStore Network and Public IP network. But when Sandy leaves the BigStore a new Network Service Provider will be involved: the UMTS public service provider. In this case, handover services of BigStore, UMTS and IP service provider must communicate and co-ordinate in order to offer seamless vertical/horizontal handover connections to Sandy’s applications.


155 / 229


Draft / 06.02

29.3.2001

BigStore Service

Provider

IP public service provider

Bob's Cheese store

Network Service Provider

Application Service Provider


Content Service Provider

Network Service Provider


uses

Content Service Provider

Connection Service Content Production

Handover Service

Handover Service

Service Access Connection Service

Access Service

Chat

Content Production

Select User Profile E-commerce

video-Conference

defines

Users Profiles

User

Figure 5.1.10: Leisure Time use cases A.1.6.2 Nomadic Worker scenario

Imagine the day of Stephanie Jones, mother of one child (little George) and married to a businessman (Peter). She is a member of a large multinational corporation based in London and therefore is constantly on the move from one place to the next, often having to cross international borders. She possess a PWA which allows her to remain connected to the Internet, no matter where in the world she decides to go next. The scheduled business meeting in London has been moved to Madrid instead, and then she has to rearrange some of the issues of her private agenda, including co-ordinating with other agendas. She moves from her home to the train station, the London Airport, the Madrid Airport, and the company premises in Madrid. Meanwhile she is permanently connected, and she contacts with her family by videoconference. She uses several applications independently of the network she is connected in each moment. Figure 5.1.12 summarised the relations between the user and the services provided in this scenario.


156 / 229


Draft / 06.02

29.3.2001

A c c e s s S e rv ic e < < e x te n d s > > < < e x te n d s > >

< < e x te n d s > > B R A IN S e rv ic e

C o n te n t D o w n lo a d

C o n te n t S tre a m in g < < e x te n d s > >

V id e o -o n -D e m a n d

< < e x te n d s > >

CSCW

D is trib u te d A g e n d a

W e b -B ro w s in g

V id e o C o n fe r e n c e

U ser

Figure 5.1.12: BRAIN nomadic worker A.1.6.3 Medical Care scenario

Mr. Paul Pangalos is a 69-year-old pensioner. He has a history of debilitating diseases such as heart disease, diabetes, among many others. Having just retired recently, after spending much of his life working on the factory floor, he would prefer to spend his time for himself and his family, and not be stuck in a hospital. The status of his health requires continual monitoring, Mr. Pangalos owns a PWA, capable of providing many generic services such as high-speed Internet access, video telephony among others. Mr. Pangalos is initially at home, and then goes to the hospital where the service is set up for him. The service is perceived to be a continuous one, i.e. whether the user is at home, shopping etc. Medical data is transmitted to the hospital over whichever network is present.


157 / 229


Draft / 06.02

29.3.2001

< < e x te n d s > > M in o r D is tu rb a n c e

R e g u la r R e p o rt s

M e d ic a l S y s te m

P a t ie n t

M a jo r D is t u rb a n c e

M e d ic a l P e r s o n

U p g ra d e S o ft w a re

Figure 5.1.13: BRAIN medical care

A.2Application and Service Aspects The main focus of this work item is to find attributes derived from user needs (user level based attributes) and map them together with the network level based attributes to show proper ways of BRAIN relevant handover opportunities. These attributes will form the foundation of the requirements, further dealt in [D.1.1]. As networks have become faster, people have started to build applications and services that make use of the speed, not just to do the same old thinks faster, but to do completely new thinks. In particular, increased bandwidth have enabled real time applications, that send voice and video information over IP networks. Non real time applications have also reduced the time required for completing theirs tasks, making them usable in the new context. Each application has their own characteristics that may be defined by the use of a set of attributes. Value ranges between a minimum and maximum values often define the attributes. There are many instances of an application used by many different users. Each of the users will have their own preferences for the application, or the group of applications combined for the provision of a certain service. Any decision-making process for adaptation must allow the application to apply users preferences to the information about QoS being experiences by the data flows used by the application. Combination of application and user attributes provides basic input for the QoS adaptation mechanisms. Adaptation mechanisms will also require some information about Network level based attributes. The combination of network and user and applications attributes will result in the implementation of a policy for QoS assurance and dynamic adaptation. QoS policies must deal not only with QoS degradation but also with specific situation of BRAIN system: handover opportunities.


158 / 229


A.2.1

Draft / 06.02

29.3.2001

Definition of attributes

QoS characterisations are realised by the means of the identification of relevant attributes. Value ranges between a minimum and maximum values define the attributes. CCITT provides the following definition of QoS: “The collective effect of service performance which determine the degree of satisfaction of a user of the service.” CCITT Recommendation E.800

This is quite unwieldy, and is far more meaningful if broken into the following viewpoints: • QoS requirements of the user • QoS offered by the service/application provider • QoS achieved by the service/application provider • QoS perceived by the user A close interaction exists between these four viewpoints and is illustrated by the diagram of figure 6.2.1.

SERVICE/APPLICATION PROVIDER

USER

NETWORK PROVIDER

Network related criteria QoS Requirements

Network Performance Objectives

QoS Offered Network nonrelated criteria

QoS Perceived

QoS Achieved

Network Performance Measured

Figure 6.2.1 – Inter-relationship of different QoS viewpoints

The service/application provider offers certain QoS levels, which the user will then request. Depending on these requirements from the user, the service provider’s QoS terms are mapped to network performance (NP) parameters, which form the network provider’s performance objectives. The NP is measured, which is then translated to QoS achieved. The user then perceives what is achieved. A means is required to map the requirements of the user (qualitative and non-technical) to more quantitative NP parameters. Both the ITU-T and ETSI recommend using the Matrix Approach to address this. This method involves the derivation of a service-


159 / 229


Draft / 06.02

29.3.2001

specific matrix for the particular service that is being considered. A generic example is given below in Table 6.2.1. Each application/service will have it’s own particular matrix. Each cell in the matrix reflects the user’s requirements with respect to the particular function being considered. For example cell 8.1: “Information transfer – Speed” will contain what type of transfer rates the user expects from the service in consideration. This will be a qualitative description. Once a matrix of requirements has been obtained, its contents are mapped onto their corresponding quantitative parameters, like bit-rate, delay, jitter, bit error rate etc. A full explanation of all of the cells can be found in [E003]. Service Function

Service Quality Criteria

Sales

Service management

Call technical quality

Speed 1

Accuracy 2

Availability 3

Reliability 4

Security 5

Simplicity 6

Reliability 7

1 Provision

2

Alteration

3

Service support

4

Repair

5

Cessation

6

Connection establishment

7

Information transfer

8

Connection release

10

Billing

11

Network/service management by customer

12

Table 6.2.1 – A generic matrix for the capture of the user’s QoS requirements

A.3 QoS Monitoring A measurement system for QoS monitoring means a system where the application and its user has a method to efficiently monitor what is the actual status of the system and if the promised QoS is reached, especially when adaptation processes are necessary to fit to changed radio and other environments (e.g. terminal battery power). The method should produce data of situations when QoS is not reached and of those situations where some improvement is needed in order to reach the QoS targets. Before the higher level application instances can make decisions about any changes in its behaviour, it needs to know what is the current status of each system component, i.e. if the network resources are blocked by a sudden network change and the buffers are already overflowed. For this reason, QoS contract relevant statistics needs to be


160 / 229


Draft / 06.02

29.3.2001

metered43 as well as other involved system components such as CPU load, memory availability, battery power and other resources. The measuring system proposed here involves monitoring two types of resources: system specific resources and traffic flow related performance information in terms of QoS characteristics. Due to the very different nature of resources and QoS characteristics, a different scheme is proposed for each. A.3.1

Resources - The wrapping concept

Certain various elements of the whole architecture perform different kind of tasks such as grabbing of frames and coding of multimedia streams, etc. This kind of elements, which could be distributed over the whole framework, demands certain resources, which are closely related to the operating system. Different operating systems have different real-time capabilities and provide different support for multimedia devices. The critical issues are performance, scheduling and resource reservation. Unfortunately resources are not always available and directly influence the performance of the element or component. To provide an example, a codec demand a certain amount of CPU power but for other reasons such as limited battery consumption the CPU has to switch to low energy consumption and the codec cannot perform anymore its task properly. Higher instances in the framework need to be informed about this situation.

Figure A.1: Wrapper concept

Since we do not specify here which operating system are to be deployed, a generic approach is proposed in order to monitor the consumption of resources. The so-called "wrapper" allows building an additional shell - similar to an onion - around the element or component and reports the consumption of resources. It has to be mentioned that the design of the wrapper is highly implementation specific because low-level functions of the operating system are monitored. The important point is that once the generic wrapping functionality is installed in the framework, it could be used recursively for

43

Definition of metering, as defined in [QoSF99]: “Metering is an ongoing active or passive examination of the network and its constituent devices checking network health, whether policies are being satisfied, and whether clients are taking unfair advantage of network services.”


161 / 229


Draft / 06.02

29.3.2001

each component. The wrapper as such is working as a probe to report and forward consumption to higher entities. A.3.2

QoS characteristics - The probing concept

Metering of QoS characteristics such as traffic flows is a key task in BRAIN because the required adaptation process relies highly on feedback of the performance of the deployed components. As an example, the subscriber access to the BRAIN can be achieved through various access methods (i.e. fixed and radio access) where the traffic characteristics could be drastically different. The measurement methodology of usage monitoring is based on passive measurement techniques only. Instead of actively probing the active traffic channels i.e. to inject simulated traffic, the current condition is gauged by the traffic that applications generate as they communicate with other hosts. Following [Stemm00] a significant advantage of passive measurements is that they do not introduce additional traffic into the network. Some active probing systems like Cprobes [Carter96], Packet Bunch Mode [Paxson97] and Pathchar [Jacobs97] use tens of kilobytes of probe traffic to generate a single performance measurement. This probing traffic is not directly used by any application and could be a significant portion of the traffic between a pair of communicating terminals. Widespread use of active probing could significantly reduce the bandwidth available to useful application traffic (i.e. slow GPRS connection). The idea is to take the approach similar to [Stemm00]. Application specific performance information is passively collected and if necessary cached and mathematically processed to estimate traffic flow conditions and reports the performance of the components.

Figure A.2: Probe concept

Following [Bhatt99] and [Camp96] it has to be considered that, as a definition of a flow is application-specific so is the timescale over which measurements of performance parameters are measured. This means that it must be kept in mind that there is always a limit of how often measurements can be obtained, without deteriorating considerably the performance of the whole system. For the aforementioned reason and to support hierarchical structures, the ISO approach for measuring generic, derived and specialised QoS characteristics are introduced (Appendix E). As explained in (Appendix E), generic QoS characteristic do not need to be post processed and trying to capture a common underlying QoS aspect. If there are mathematical relationships as well as if statistical processing of measurements are necessary (e.g. maximum, minimum, range, mean value, variance and standard


162 / 229


Draft / 06.02

29.3.2001

deviation, statistical moments, etc.) then from the generic measurements are transformed into derived respective specialised QoS characteristics. Interworking and transparency in such an architecture is achieved by subscribing the to be measured component to probing components. In order to ensure the correct interpretation of the gathered information, probing components can be used recursively, building a hierarchical structure. Higher layer related components are responsible to provide a specification of the requested report and guide the lower probing components to let the associated components subscribe to their services. This feature allows performing End-to-End QoS observations and measurements. It is important to be mentioned that the generic points of the components are implementation specific and could highly differ from implementation and operating system. A.3.3

Key QoS characteristics

A.3.3.1 Session Level Performance Metrics

Multimedia streams are often relayed to one session, meaning i.e. a videoconference session contains usually a duplex video and a duplex audio stream. Because each stream is attached to and handled with different QoS requirements, the streams are sometimes not anymore synchronised. This effect manifests itself at the receiving side often in variations of lip-synchronisation or even loss of one ore more media streams. Skew stands for a synchronisation parameter and is usually expressed in the maximum time of synchronisation in milliseconds. The task of a probe component at the session layer is among others to monitor the corresponding multimedia streams by gathering information about the time stamps [RFC1890] and sound out if variations are detected. Another session layer related performance parameter is to monitor the session setup time and release time, as well as to monitor the handoff and/or roaming time and RTP statistics. Focusing to the handoff time, the session layer will be one of the first lower layers that will detect anomalies and will report them at once. QoS Characteristic Skew

Handover type Handover speed Session setup time Session release time

Performance Metric perfect (0 ms) lip-synchronisation (1-160ms) not synchronised (> 160ms) lossy/lossless milliseconds milliseconds milliseconds

Table A-1: Session Level Performance Metrics A.3.3.2 Higher Level Performance Metrics

Each application specific multimedia stream is highly dependent on the lower layer characteristics. They are often implemented in different kinds and depend on the used codecs. Some of them are provided in the following table, but they are by far not exhaustive [Aquila00], [Bissel00].


163 / 229


Draft / 06.02

Traffic Stream Type Voice over IP File Transfer Streaming Audio

QoS Characteristic call set-up time voice quality delivery time audio quality Mean Opinion Score44 (MOS)

Streaming Video

Visual quality in PSNR (Peak Signal to Noise Ratio) [dB] Frame rate [f/s]

Resolution

29.3.2001

Performance Metric milliseconds as defined in [ITU861] seconds telephone (mono, 4kHz, 8bit) radio (mono, 22kHz, 8bit) CD (stereo, 44kHz, 16bit) unsatisfactory (1) medium (2-3) good (4) excellent (5) good (>30db) medium (25-30db) low (30 f/s) reduced-rate (2-25 f/s) single images (1 f/s) still image (0 f/s) HDTV (1600x1200 pixels) 16CIF (1408x1152 pixels) 4CIF (704x576 pixels) PAL (768x576 pixels) CIF (352x288 pixels) QCIF (176x144 pixels) SQCIF (128x96 pixels)

Table A-2: Higher Level Performance Metrics

A.4 Network and Communication Terminal Aspects Depending on their nature, applications running on BRAIN terminals have very different requirements on network services. Legacy applications, designed for fixed networks, will typically suffer performance problems due to the different characteristics of the wireless access link, and require transparency in the management of mobility, but they will work seamlessly over a BRAIN network. However, new applications that exploit all the possibilities offered by the network will clearly demand new services, either from the network itself, from the protocol stacks running on terminals or, most commonly, from both. QoS management of communication links between terminals and network, availability of network providers and their offered services, knowledge of terminal location, are some examples of new functions that will have to be included as network services in order to fulfil new application requirements. A.4.1

Concept of Personal Wireless Assistant

BRAIN usage scenarios present different situations where people use their Personal Wireless Assistant (PWA) in places where services from different network and application providers are accessible. For example, a user inside a mall can access specific shopping services provided by the mall company through its HIPERLAN/2 network. He could also access general services (like telephony, videoconference, e-mail, etc) offered by one or more application service providers that are accessed through the mall’s HIPERLAN/2 network (which could be interconnected with a core network), or using another access network based on a different technology like UTRAN or GPRS, or even using the same (another superposed HIPERLAN/2 access network). In general,

44

Examples for MOS: G.711=4.1; G.726=3.8; G.723=3.9; G.239=3.9


164 / 229


Draft / 06.02

29.3.2001

several network providers could be accessible at any place, even in the case that only one access network technology is available. In some situations described in the usage scenarios, a PWA should be connected simultaneously to more than one network provider at a given time. For example, one of the users is receiving shopping information (a picture or a video) from the mall servers, and decides to forward it to somebody else using her/his regular e-mail service. It could be the case that the mall’s access network provides IP connectivity with an IP core network (i.e. the mall’s network department has agreed with network service providers to extend their service inside the mall, giving IP global connectivity to users), so the mail server can be accessed seamlessly. A.4.2

Concept of Virtual Transport Service

Therefore, user terminals should support what we will name “Virtual Transport Services”, in order to be able to maintain several simultaneous associations with different network service providers; either through the same access network or through different ones, and using different IP addresses for each of them. And the network service should offer support for this ‘virtuality’.

A Virtual Transport Service (VTS) represents the association of a user terminal (PWA) with a network service provider. In this context, a network service provider is an organisation that offers network services through one or more access networks, typically including IP basic connectivity and some proxy and application services. Once a terminal establishes an association with a network service provider, conceptually, a new VTS is created and configured with a set of parameters negotiated with the provider that will be used by the applications that run over it. The way virtual transport services are defined makes them independent of networks. That is, a user terminal could have two different VTS working over the same access network.

Figure A.3: Virtual Terminals Example

During the life of a VTS changes can happen due to the movement of the terminal. For example, the terminal could change the HIPERLAN/2 access point it is connected to. This change will probably be handled through HIPERLAN/2 handover mechanisms, so


165 / 229


Draft / 06.02

29.3.2001

from the architectural point of view the change is managed at the sub-network layer of the architecture. Additionally, the terminal could move itself from a HIPERLAN/2 network to a UMTS based one (vertical handover). In this case, management of mobility will probably be made at IP level, using IP mobility. But, from the point of view of VTS, although the access network used could change, the association with the network provider remains. Described in terms of IP mobility [Perki96a], each VTS is associated with a home IP address. Figure A.3 presents an example where a user moves from her/his office (I) –which is the home location- to a shopping centre (III). The user is registered with the network service provider who assigned him a home IP address belonging to one IP subnet in her/his office. The user has several applications started (e-mail, VoIP, etc) running over a virtual transport service (VTS1) which at position (I) uses the office HIPERLAN/2 (Figure A.4, I). When the user moves to the shopping Center, he goes through streets where there is only UMTS coverage, so VTS1 makes a vertical handover to maintain the association with the network provider, probably acquiring a new care-of-address (Figure A.4, II). Finally, when the user enters the shopping Center, a new VTS is created (VTS2) that makes use of the HIPERLAN/2 network to access shopping services (Figure A.4, III). VTS2 will use a dynamic private IP address. From the point of view of applications, each time a VTS is created, it is assigned an IP address that will not change during the life of that VTS during the auto-configuration phase. Internally, the IP address used by the VTS could change due to mobility issues, but this change will be transparent for applications. In case that, for any major reason, the IP address has to be changed, conceptually, the present VTS will be closed and a new VTS will be created using the new IP address. Application1

Application2

Applications

Applications

Mobile TCP/IP Stack

Mobile TCP/IP Stack

Mobile TCP/IP Stack

Mobile TCP/IP Stack

HyperLAN/2 HIPERLAN/2

UMTS

UMTS

HIPERLAN/2

VTS1

VTS 1

VTS 1

(I)

Application3

(II)

VTS 2

(III)

Figure A.4: Virtual Transport Services Architecture

A.4.3

BRAIN terminal

Appendix D presents various types of communications terminals and their capabilities. Following the presented terminal design trend, different types of terminals can connect to a BRAIN system and get different services according to their physical capabilities. BRENTA [Neure00] is designed to accommodate support for a very wide range of applications from legacy applications to new adaptive applications yet to be developed. Similarly new terminals with more capabilities will be developed supporting existing and new applications. A framework for classifying different types of terminal should be considered, regarding the characteristics that should be taken into account when trying to map BRAIN services/applications to these types of terminals. As seen before terminal devices comprise of different layers and characteristics, which interact with each other. Nevertheless it is possible to distinguish different aspects that are of most importance for BRAIN services and applications, i.e. QoS and how they relate to the physical capabilities of the terminals. In [D.1.1] BRAIN services scenarios


166 / 229


Draft / 06.02

29.3.2001

have been identified and the analysis can be based on these scenarios focusing on QoS and mobility aspects. It is then possible to devise a framework for identifying:

•

what kind of support we really be expected from terminals (e.g. for certain lowprofile types of terminals, part of BRENTA could be placed in agents – e.g. in MExE environment?)

•

what kind of negotiation should be designed: e.g. for UMTS devices, an e-2-e QoS negotiation based, among other information, on MExE classmark identifiers could be used more generally to provide interoperability among different types of terminals.

To this extent, BRAIN could employ and even propose an extension of the MExE definition used in UMTS, based e.g. on the application classification that exists in BRENTA. A.4.3.1 BRAIN terminal/application classification

In this section a terminal and application classification is attempted focusing mainly on QoS and mobility aspects. This will follow the MExE classifications for UMTS (see section 3.6) but generic terms will be used to relate more to the BRENTA architecture. A given BRENTA classmark shall identify a category of BRENTA terminals supporting BRENTA functionality with a minimum level of processing, memory display and interactive capabilities. A proposed terminal classification relating to the BRENTA architecture is:

BRENTA classmark 1 terminals require limited input and output facilities and are designed to provide fats and cheap information access on low QoS connections. These terminals support standard voice and WAP-like applications.

BRENTA classmark 2 terminals require standard input and output facilities and are designed to provide information access for legacy applications with out mobility or QoS awareness. These terminals support legacy applications (BRENTA type A).

BRENTA classmark 3 terminals use a run-time system requiring more processing, storage and network resources. These terminals also support mobility and are also QoS aware in a self-contained manner without exchanging information with the network. Self-contained QoS aware apps (see BRENTA type B) are supported by these terminals.

BRENTA classmark 4 terminals have the same capabilities like classmark 3 terminals but also have BRAIN component level APIs implemented exchanging through the Broker information with the network for adaptable mobility and QoS awareness. QoS Broker based applications using Broker API directly (see BRENTA type D.1) are supported by these terminals.

BRENTA classmark 5 terminals have the same capabilities like classmark 4 terminals but also have XML document APIs implemented exchanging information directly with the network for adaptable mobility and QoS awareness. XML-document based applications using browser for presentation and for accessing the QoS Broker interface (see BRENTA type D.2) are supported by this terminals. For example fixed terminals can be included in any classmark according to their software and middleware capabilities and can run: Voice applications Legacy, QoS-unaware applications QoS aware applications Full-blown applications CEC Deliverable Number 1.2

167 / 229


Draft / 06.02

29.3.2001

Component based applications Broker based applications XML-document based applications

Mobile Terminals could also be designed for any of the above mentioned classmarks. Mobile terminals belonging to classmark 1 can run: Voice applications WAP applications Mobile terminals belonging to classmark 2 can run: Voice applications Data applications Legacy, QoS-unaware Mobility unaware (cordless phones do not feature H-O capabilities) Mobility aware Mobile terminals belonging to classmark 3 can run: Voice applications Data applications Legacy, full blown QoS and mobility aware Mobile terminals belonging to classmark 4 have the same abilities like classmark 3 and are able to use downloadable components, but logic is embedded in device Mobile terminals belonging to classmark 4 have the same abilities like classmark 4 and are able to use downloadable components and logic can be either embedded or downloaded, or executed on agents. A.5References [Aquila00]

F. Strohmeier (ed), et al, “Report on the development of measurement utilities for the first trial”, IST-1999-10077, Aquila - Adaptive Resource Control for QoS Using an IP based Layered Architecture, September 2000. [Bhatt99] Sallem N. Bhatti, Graham Knight, “Enabling QoS adaptation decisions for Internet applications”, London, UK, 1999. [Bissel00] T. Bissel, M. Bogen, C. Bonkowski, D. Strecker, “QoS Assessment and Measurement for End-to-End Services”, Proceedings of COST 263 Conference on Quality of Future Internet Services, Berlin, September 2000. [Booch98] Grady Booch, Ivar Jacobson, James Rumbaugh, Jim Rumbaugh. The Unified Modeling Language User Guide (The Addison-Wesley Object Technology Series). Addison-Wesley Pub Co; ISBN: 0201571684. October 30, 1998. [Braden94] R. Braden, D. Clark, and S. Shenker. Integrated Services in the Internet Architecture: An Overview. RFC 1633, July 1994. [Camp96] A. Campbell, C. Auurecoechea, L. Hauw, “A Review of QoS Architectures”, Proc. Of 4th IFIP International Workshop on Quality of Service (IWQS'96), Paris, France, March 1996 (ftp://ftp.ctr.columbia.edu/CTR-Research/comet/public/papers/96/CAM96a.ps.gz). [Carter96] R. L. Carter, M. E. Crovella, “Dynamic Server Selection using Bandwidth Probing in Wide-Area Networks,” Tech. Rep. BU-CS-96-007, Computer Science Department, Boston University, March 1996. [Chen89] S. K. Chen, E. D. Lazowska, D. Notkin, and J. Zahorjan. Performance implications of design alternatives for remote procedure call stubs. In Proceedings of the Ninth International Conference on Distributed Computing Systems, pages 36--41, June 1989. [Clark92] D. Clark. Supporting real-time applications in an integrated services packet network: Architecture and mechanism. In Proceedings of the SIGCOMM '92 Symposium, pages 14-26, August 1992. [CCITT211] CCITT Recommendation I.211; "Integrated Services Digital Network (ISDN), General Structure and Service Capabilities, B-ISDN Service Aspects"; 1991. [D.1.1] IST-1999-100050 BRAIN D.1.1, “Scenarios for mobile IP services and resulting requirements in different wireless networks”, August 2000.


168 / 229

Del 1.2 Draft v6.03.doc [Demic00] [E003] [ITU861] [Jacobs97] [Koodi00] [Lazar94] [Mathi99] [MMCF95] [Neure00]

[Paxson97] [Perki96a] [QoSF99] [RFC1890] [RFC1901] [RFC2330] [RFC2679] [RFC2680] [RFC2681] [Stemm00]

Draft / 06.02

29.3.2001

C. Demichelis, P. Chimento, “Instantaneous Packet Delay Variation Metric for IPPM”, Internet Draft, July 2000 (http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-05.txt). ETSI Technical Report 003: Network Aspects; General aspects of Quality of Service and Network Performance (October 1994) ITU-T Recommendation P.861, “Objective quality measurement of telephone-band (3003400 Hz) speech codecs”, February 1998. V. Jacobson, “pathchar – A Tool to Infer Characteristics of Internet Paths”, 1997 (ftp://ee.lbl.gov/pathchar). R. Koodi, R. Ravikanth, “One-way Loss Pattern Sample Metrics”, Internet Draft, July 2000 (http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-pattern-03.txt). Lazar, A. A., Bhonsle S., Lim, K.S., “A Binding Architecture for Multimedia Networks”, Proceedings of COST-237 Conference on Multimedia Transport and Teleservices, Vienna, Austria, 1994. M. Mathis, M. Allman, “Empirical Bulk Transfer Capacity”, Expired Internet Draft, October 1999 (http://www.advanced.org/IPPM/docs/draft-ietf-ippm-btc-framework-02.txt). "Overview of End User Applications for Multimedia Communications", The Multimedia Communications Forum (MMCF); MMCF/95-001, Approved Rev 1.0, 1995. G. Neureiter, L. Burness, A. Kassler, P. Khengar, E. Kovacs, D. Mandato, J. Manner, T. Robles, H.Velayos, “The BRAIN Quality of Service Architecture for Adaptable Services with Mobility Support”, in Proceedings of the 11th IEEE International Symposium on Personal, Indoor and Mobile Radio Communication London, United Kingdom, 18-21 September 2000. V. Paxson, “Measurements and Analysis of End-to-End Internet Dynamics”, Ph.D. thesis, U. C. Berkeley, May 1997. C. Perkins ed., "IP Mobility Support", IETF RFC 2002, October 1996. “Introduction to QoS Policies”, QoS Forum White Paper, July 1999 (http://www.qosforum.com). H. Schulzrinne, “RTP Profile for Audio and Video Conferences with Minimal Control”, RFC1890, Jan 1996. J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Introduction to Community-based SNMPv2”, RFC1901, Jan 1996. V. Paxson, G. Almes, J. Mahdavi, M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, February 1998 (http://www.ietf.org/rfc/rfc2330.txt). G. Almes, S. Kalidindi, M. Zekauskas, “A One-way Delay Metric for IPPM”, RFC 2679, September 1999 (http://www.ietf.org/rfc/rfc2679.txt). G. Almes, S. Kalidindi, M. Zekauskas, “A One-way Packet Loss Metric for IPPM”, RFC 2680, September 1999 (http://www.ietf.org/rfc/rfc2680.txt). G. Almes, S. Kalidindi, M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, September 1999 (http://www.ietf.org/rfc/rfc2681.txt). Mark Stemm, Randy Katz, Srinivasan Seshan, “A Network Measurement Architecture for Adaptive Applications”, Proceedings of IEEE Infocom 2000, Tel Aviv, Israel, March 2000.


169 / 229


Draft / 06.02

29.3.2001

Appendix B Traffic models of multimedia streams B.1 Introduction Application layer is sitting on top of the protocol stack of every communication network. Various types of applications exist with different characteristics, generating data traffic that is carried through the network. Data traffic patterns of different application can be statistically described and modelled to provide information used for the design of a specific communication system, and the simulation of its performance. Although it is very difficult to model exactly the packet generation patterns of all the considered services and applications, there exist traffic models for some of the most important IP applications as they are used today or in future IP networks like BRAIN. New multimedia applications are of special interest because of their adaptive and real time characteristics. This section describes the statistical characteristics and models of various applications in an effort to define the connection requirements of underlying layer protocol entities. The section is structured as follows: Sections B.2, B.3, and B.4 describe different models for multimedia applications, some with real time characteristics, including Packet Voice (PV) used for voice over IP, Video conferencing and Video streaming (including MPEG). Section B.5 describes traffic models for data services like World Wide Web (WWW), File Transfer Protocol (FTP) and e-mail and. All these packetbased services have received extensive attention due to the exponential growth of the Internet. Although data traffic applications do not have strict QoS requirements, their generated traffic influences the operation and performance of the system and thus they are analysed and presented here. This appendix is also supported by Appendix C, which gives more details on the statistical analysis of MPEG and WWW traffic streams. B.2 Packet Voice The speech traffic model can be described as a birth-death process with a Poisson distributed arrival process and an exponential distributed call duration [D3.1]. Conversational speech can be characterised with a sequence of talkspurts (service times, messages) separated by silent spurts (idle times). In a conversational speech, each party is usually silent for more that 60% of the time [Brady69]. Therefore, a PV terminal can be modelled as a Markov model with two states of “silence” and “talkspurt”. When in “silence”, the terminal generates no packet and when in “talkspurt”, it generates packet at a constant rate [Goodm91]. During the activity phase IP packets carrying the speech information are transmitted. This type of traffic is therefore simulated as an on-off model with activity and silent periods are generated by an exponential distributed random variable with mean values T_on and T_off respectively. Talkspurt

Talkspurt Silence Time

Figure B.1: Packet Stream Produced by a Packet Voice Source.


170 / 229


Draft / 06.02

29.3.2001

Payload size depends on the considered speech codec and the packet rate. The adaptive multi-rate speech codec (AMR) [Fings01] is a multi-mode codec with bit rates between 4.75 and 12.2 Kb/s. Processing is done on 20 ms frames taking 160 samples per frame. It offers high speech quality under a wide range of transmission conditions. With a packet rate of 12.2 Kb/s the packet size has a payload of 32 bytes. Furthermore the header comprising of RTP, UDP and IP has 40 bytes using Ipv4 and up to even 60 bytes using IPv6. This shows the problem of the header overhead typical for VoIP. Header size can be reduced considering that there is significant redundancy between header fields, both within the same packet header but in particular between consecutive packets belonging to the same packet stream. Using header compression [Burme01] static field information is sent only initially and predictability and dependencies is used for the other fields. The existing header compression schemes are designed for fixed links and they do not work well for cellular links. For this reason there is a working group (RObust Header Compression) developing header compression schemes especially for wireless links. It is assumed that header bytes can be compressed to 8 bytes using ROCH [Isabe93] but sizes can vary depending on the level of robustness required. The Transmission Time Interval (TTI) of these (32+8) byte packets is assumed to be 20 ms. For instance within an active period of 3 seconds 150 IP packets have to be transmitted. Table B-1 summarises the parameters of the traffic model. In HIPERLAN/2, the DLC Data Unit has 48 bytes reserved for the payload of the packet so variable sized IP packets have to be converted to fixed sized Data Units. The convergence layer must implement the segmentation and reassembly of the packets. Activity Mean call duration Mean active phase T_on Mean silent phase T_off Payload of IP packet IP Framing Overhead Transmission time interval Voice packet generation IP packet rate

50 % 120 seconds 3 seconds 3 seconds 32 bytes 8 bytes 0.02 seconds 0.02 seconds 0.02 packet/sec 50 Hz

Table B-1: Parameters of Packet Voice for VoIP traffic model.

B.3 Videoconference Traffic correlation is an important traffic level feature of videoconference that has a significant impact on performance. The complexity of videoconference traffic is a natural consequence of integrating, over a single communication channel, a diverse range of traffic sources such as video, voice, and data that differ a lot in their traffic patterns as well as their performance requirements. Specifically, we can find variable bit rate (VBR) real-time applications such as compressed video and audio which show certain degrees of correlation between arrivals and high dependence in time (selfsimilarity). Compressed digital video streams traffic shows self-similarity. A consequence is that merging of traffic streams does not result in smoothing of traffic. The ITU recommendation H.323 defines the components, procedures and protocols necessary to provide audio-visual communication. Following this recommendation G.728 for audio coding and H.263 QCIF for video coding have been selected. H.323 enforces the use of Real Time Protocol of the Internet Engineering Task Force (IETF) for flow transmission.


171 / 229


Draft / 06.02

29.3.2001

We will consider a single video channel to transmit video compressed using the H.263 standard. We will simulate the transmission of rather still images. The image size and quality depends on the type of terminal and the concrete application:

•

In indoor scenarios as the small company the BRAIN user is using conventional office equipment and therefore he expects fixed network QoS. The image format should be CIF (352x288 pixels) or QCIF (176x144 pixels) depending on the quality required.

•

In portable usage scenario the user uses a small and light device called PWA. He is moving and has simultaneously access to multimedia services. Due to low resolution of those terminals QoS requirements in terms of data rate are quiet modest. The image format in this case should be SQCIF (128x96 pixels).

The parameter values have been extracted from the Isabel Videoconference System [Isabe93] that codifies images using 24 bits per pixel and then compress them using H.323. After an image is captured, it is processed and a stream of RTP packets is generated. Packet size is not uniform because it depends on the image complexity and the differences between contiguous images. As it happens in an MPEG video stream, all frames are not treated equally. Once a selfcontained-picture is compressed and the rest of pictures are difference images significantly smaller. The frequency of the big images in the stream can be fixed. In this case the system transmit one complete picture for each 15 different images. An important issue is to know the quantity of bandwidth to reserve in order to get a determined QoS. As a general videoconference system does no generate a uniform video stream enough bandwidth needs to be reserved to absorb the traffic peaks but this is very inefficient. Due to this videoconference applications, like Isabel, can be used to regulate the image quality based on the bandwidth reserved. The bandwidth to reserve depends on parameters as frame rate, image size and image quality required. The application has a procedure that prevents the coder from exceeding a certain rate by reducing quality. Therefore the traffic rate generated becomes nearly uniform. There exist two possibilities:

•

QCIF images (176x144 pixels) with a transmission rate of 12 frames per second. Studying the traffic generated by an Isabel application under these conditions we have concluded that we would need to reserve around 600Kb/s. This implies that varying the image quality we won’t let our transmission rate get higher than the 600Kb/s reserved. . This produces a mean size of packets of 6 Kbytes/frame.

•

SQCIF images (128x96 pixels) with a transmission rate of 12 frames per second. Using the same procedure we have concluded that for this image size we would need to reserve 150 Kb/s, therefore, the mean size of packets is 1.5 Kbytes/frame.

The speech coder that will be used is G.728 LD-CELP. The most important parameters of this coder are:

•

bit rate = 16 Kb/s

•

frame size = 0.625 ms

Though the coder generates an almost constant bit rate, the size of the audio frames will be considered same as the MTU of the subnetwork. When reproducing audio and video samples must be synchronised at destination, but this matter is left to further studies. It will not be included in the initial simulations.


172 / 229


Draft / 06.02

29.3.2001

There are some timing restrictions imposed to the videoconference traffic [D.1.1]

•

end to end delay should be under 200 ms

•

set-up time under 20 sec.

B.4 Streaming video models Video traffic, in compressed form, is expected to be the prime example of variable bit rate traffic type. When uncompressed, a video signal is representative of constant bit rate type traffic. Video frames to be transmitted at the common rate of 30 frames/sec are sampled and quantized, pixel by pixel, providing a constant number of bits/frame and hence bits/sec. For different transmission standards capacity of up to 180 Mb/s is needed to transmit a signal. Compression is used to reduce the transmission rate of a video signal. Moving Pictures Experts Group (MPEG) develop different coding standards for compression of video signals The bit rate as a function of time or frame number of a typical compressed video signal has several characteristic properties that are worth of notice. First is the slow variation of the signal. Video signals, despite the heavy compression, typically manifest high correlation from frame to frame. A typical correlation measure is 10 – 20 frames. A second characteristic feature of a video signal is that occasionally the bit transmission rate is found to increase dramatically for a short interval of time (at most 1 – 2 frames) and then drop down to a more normal range. This is attributed to scene changes, with correspondingly large changes in the picture content. Finally, bit rate histograms of different video signals (videophone, video conference and studio TV signals) have shown that several video signals appear to have Gaussian shaped histograms. B.4.1

MPEG video models

MPEG – the Moving Picture Experts Group – was established in 1988 and set out to develop full audio-visual coding standards for multimedia applications. Since then various MPEG standards have been produced that are widely used today. Appendix C gives a detailed description of the different MPEG audio and video standards. Based on that analysis the following traffic models have been perceived that try to capture the operation of the standards. B.4.1.1 Markovian process models

This is a discrete time model of the bandwidth requirement of the MPEG (1, 2 or 4) stream. The emission of one frame per time unit is considered as the basic functioning of the sender and the sequence of the frame sizes is described. For this doing the most important information is to know if the sender is sending a big image or not. So he is considered to be in one of several possible states and the future of the frame size sequence being determined by the current state of the sender. As the sender can emit at most 11 small images between two big images and possibly less (if a scene cut occurs in the film), the sender will pass between her/his possible states with the following probabilities:


173 / 229


Draft / 06.02

29.3.2001

Figure B.2: Markovian process of big/small frame emission

From this graph the bandwidth mean and variance can be computed. B.4.1.2 Multilevel source traffic models

A multi-level source traffic model can model the continuous MPEG stream. According to this model the traffic source can be in one of two states: emitting a big image or emitting a predicted image. In both states the source emits at a bandwidth of known expectancy and within-state variance. State changes of the source are a Markovian process. The staying time in each state is of arbitrary distribution. This model permits to handle heavy-tailed staying time distributions, which arise from positively auto-correlated traffic, which is the case of the elementary video stream. The state change is a semi-Markov process in the sense of [Cinla75], i.e. the staying times in each state have arbitrary distributions and the process of the state changes is a Markovian process. The expected heavy-tailed distributions of scene lengths are among the motivations of the Renegotiated Constant Bit Rate proposal in [Gross95]. [Duffi66] shows that multiplexing allows gains in bandwidth and buffer use even in the case of heavy-tailed distributions and long-term dependency between the traffic streams. B.4.1.3 Traffic model parameters

The modelled stream is described using the following parameters:

•

Ep

expectancy of bandwidth for predicted images

•

Bpr

ratio of bandwidth expectancies for big images vs predicted images

•

Vp

variance of bandwidth for predicted images

•

Vb

variance of bandwidth for big images

•

L

length of the sequence between scene cuts, in frames

•

n number of frames starting by a big image in absence of scene cuts, actually 12

Finally, the distribution of the staying times in both states: for the Big image emission mode the staying time is constant. And for the Predicted image emission mode the staying time is: at each of the n - 1 expected predicted images (including the first) a scene cut may occur, forcing the return to the Big image emission mode. After n - 1 predicted images the source will unconditionally return to the Big image emission mode.


174 / 229


Draft / 06.02

29.3.2001

Figure B.3: staying time distribution in the Big and the Prediction image emission mode

B.4.1.4 Statistical properties The mean bandwidth for a scene of length L is: § ( Bpr − 1) ª L º · ¨¨ 1 + «« n »» ¸¸ L ¹

E = Ep ©

(2-1)

and for the variance of the bandwidth V, using the notation:

M=

ªLº «« n »» L ,

(2-2)

the following, ª º ª º V = (Vp) + (Vb) + Ep∗¨¨©(Bpr) ¨¨©− m + «« n »»¸¸¹ + Bpr¨¨©2m − m − 2«« n »»¸¸¹ + (− m + m +1)¸¸¹ 2

2

2

§

2

§

2

§

L ·

3

2

L ·

3

2

·

(2-3)

holds. Another characteristic of the stream is a strong auto-correlation for a 1/2 second delay (the delay between two big images in absence of a scene change) for every reasonable length of scenes. B.4.2

Autoregressive video model

This section describes another of the numerous traffic models incorporating the characteristics of variable bit rate (compressed) video that have been proposed. This traffic model is the Discrete-Autoregressive Process (DAP). Let λ (n) be a number of bits/pixel in the encoded frame number n, using discrete form of autoregressive process, λ (n) is presented by:

λ (n) = aλ (n − 1) + bw(n)

a

Concepts for Service adaptation, scalability and QoS ... - CiteSeerX

Concepts for Service adaptation, scalability and QoS ... - CiteSeerX

Suggest Documents

Concepts for Service adaptation, scalability and QoS handling on

QoS Adaptation in Service-Oriented Grids - CiteSeerX

qos with reliability and scalability in adaptive service-based ... - AIRCC

QoS-driven Runtime Adaptation of Service Oriented ... - CiteSeerX

A QoS Adaptation Service for Mobile Streaming Applications

a scalable qos adaptation service for mobile multimedia applications

A QOS-BASED FRAMEWORK FOR THE ADAPTATION OF SERVICE ...

MOSES: a Framework for QoS Driven Runtime Adaptation of Service ...

a scalable qos adaptation service for mobile multimedia applications

Online QoS Prediction for Runtime Service Adaptation ... - CUHK CSE

Adaptation to Drifting Concepts - CiteSeerX

Adaptation to Drifting Concepts - CiteSeerX

QOS SERVICE ROUTING FOR SUPPORTING ... - CiteSeerX

A Service-Oriented Architecture for QoS Configuration and ... - CiteSeerX

On Availability QoS for Replicated Multimedia Service and ... - CiteSeerX

A Service Agent for Connection and QoS Management ... - CiteSeerX

QoS Guarantees and Service Differentiation for Dynamic ... - CiteSeerX

Issues and Architectures For Better Quality of Service (QoS) - CiteSeerX

QOS SERVICE ROUTING FOR SUPPORTING

Composite service adaptation: a QoS-driven approach - Core

QoS-driven Proactive Adaptation of Service ... - Semantic Scholar

Multimedia QoS Adaptation for Inter-tech Roaming

Multimedia Content Adaptation for QoS Management over ...

QoS Adaptation and Flow Filtering in ATM Networks - CiteSeerX