Conceptual QoS Framework for Managing End-User Services in the Next Generation Network

Transcription

1 Conceptual QoS Framework for Managing End-User s in the Next Generation Network Derrick Mwansa and Hu Hanrahan Centre for Telecommunications Access and s 1 School of Electrical and Information Engineering University of the Witwatersrand, Johannesburg Private Bag 3, WITS 2050, Republic of South Africa Tel: Fax: {d.mwansa, h.hanrahan}@ee.wits.ac.za Abstract We describe, analyse, model and present a conceptual QoS framework for managing end-user services in the NGN. The framework harmonises both the business aspects of future service trading models and the performance management aspects of the NGN into a common QoS model. Modelling inputs are realistic QoS viewpoints of end-user, service provider and the NGN roles in service provision, taken at a point far into the future. Critical QoS deficiencies left by many frameworks are also covered. Index Terms end-user services, QoS, management framework I. INTRODUCTION s the Next Generation Network (NGN) develops to a Abetter service provision infrastructure, certain areas critical to operation and general acceptance of the NGN as the future service delivery infrastructure still remain unresolved. We identify mechanisms for meeting perceived Quality of (QoS) of end-user applicative services as one critical requirement that needs urgent implementation in the NGN. Another requirement, which is a direct consequence of enduser QoS demands and since realising QoS in the NGN itself is complex and costly, is how Providers (SPs) can fulfil the QoS while at the same time meeting their own core business interests that is reducing CAPital EXpenditure (CAPEX) and maximizing Return On Investment (ROI). Both requirements call for a development of a QoS framework for managing end-user services in the NGN. Additionally, the framework should unify aspirations of both the end-user and the SP in an integrated manner. An NGN end-user is more focused on getting value for money from the services paid for, and demands that his service QoS interests be protected by some form of service contracts such as Level Agreements (SLAs). On the other hand, the SP s obligation to meeting QoS for the various end-user services is only a marketing strategy and a measure to escape contractual penalties. Since the problem of managing end-user service QoS is the SP s responsibility, the SP has two tasks on 1 The Centre is supported by Telkom SA Limited, Siemens Telecommunications, Sun Microsystems SA and the THRIP Programme of the Department of Trade and Industry hand. The first task is a question of making various end-user services perform with QoS stipulated in the service contracts. Most important to the SP is how it can meet the required performances in a cost effective way. Additionally, the SP would want to put in place a mechanism that brings the enduser QoS concept into a business process whereby it can formulate a way of tapping revenue out of trading user-centric services with QoS differentiation. An SLA-driven approach to managing end-user perceived QoS presents an optimal solution to resolving tensions in the user-sp QoS management paradigm. In the SLA-driven QoS approach, resources in the NGN are deployed for QoS per subscription type. Moreover, the concept of SLA itself is inherently business oriented and can find easy incorporation into a QoS-enabled service trading process. While the NGN itself has shown a rich, flexible and longterm cost-effective means of creating services and applications, and a supporting multiservice capable transport network, it at present severely lacks end-user service QoS support. There also exist many QoS frameworks today, particularly for packet differentiation at the IP layer. However no particular frameworks exist that fully address real characteristics of the NGN QoS role players in their models. We present a process for developing a feasible QoS framework in section 2. Section 3 clarifies our benchmark QoS concept and criteria. In section 4, QoS viewpoints are presented from which QoS management requirements are identified. The conceptual QoS framework is built in section 5. Section 6 closes the paper and identifies future research. II. MODELLING AN END-USER QOS FRAMEWORK A QoS development process is shown in figure 1. Modelling a framework for managing end-user perceived QoS in the NGN would require, initially laying boundaries on the QoS concept and criteria to set the modeling benchmark. This need arises because there exist many concepts and criteria used to describe QoS in the ICT industry today. Three core modelling viewpoints are identified in figure 1: the end-user viewpoint that abstracts the end-user QoS role, potential user service consumption model, service characteristics, its QoS aspirations

2 and the implications that all these aspects have on overall QoS management. The SP viewpoint abstracts the service provider (SP) role, its NGN standpoint, its enabling service trading models, and how the SP would want to manage end-user service QoS. The NGN viewpoint brings out the service delivery infrastructure role, its characteristics, and the problems it presents to managing end-user QoS. More particularly this viewpoint abstracts QoS management in the target NGN, taking into account the NGN drivers, enabling architectures and capabilities, and technology that meet aspirations of the NGN. The Other factors viewpoint represents external modelling factors that may be critical to decision making in QoS system design. Key QoS features of viewpoints and the initial QoS concept and criteria, provide inputs to setting QoS management modelling requirements. Using the requirements, an analysis is performed and a conceptual QoS management model is presented. The next step is to decompose the framework and modelling in detail various framework architectural parts, information modelling and final implementation of the QoS framework using a suitable software engineering process. QoS Concept & Criteria Initial QoS Management Requirements User VP Provider VP NGN VP Other factors QoS Framework Requirements and Feasible Model Analysis QoS Management Framework Model Fig. 1. QoS framework development process. III. QUALITY OF SERVICE Decomposition Detailed Architecture Information Modelling Implementation A. QoS Concept Many concepts and measures of QoS currently exist in the ICT industry today. For example, in a telco s marketing department, friendliness to customers and rate at which customers are receiving front-end services can be translated into some measure of service quality. Clarifying the benchmark QoS concept is mandatory. We seek to develop a framework for managing end-user perceived applicative service performance QoS based on SLAs. The ITU-T defines QoS as a general representative of the many performance aspects and numerous measures that define the collective effect of service performances that determine the degree of satisfaction of a user of the service [1]. In defining the SLA part of our target QoS, we extend a definition [2], as a contract that exists between an SP and a service user. The SLA is designed to create a common understanding about a number of service aspects such as service quality levels, support options, enforcement or penalty provisions for services not provided, a guaranteed level of system performance as relates to downtime or uptime, a specified level of customer support and what software or hardware will be provided and for what fee, among other things. An SLA document generally has two parts: a business or legal part, and a technical part. On the technical part reside Level Specifications, also called Level Objectives (SLOs). SLOs depict sets of parameters that define offered services and QoS [3]. QoS, then, is only a subset of the SLA requirements. However, an SLA-driven QoS is the general set of performance metrics as specified in the SLOs which must be satisfied by the network and service intelligence infrastructure to meet the requirements offered to or negotiated with the service user. Enforcement mechanisms that facilitate end-to-end QoS guarantees of negotiated service levels are also part of the QoS requirement. B. QoS Criteria Performance specifications for QoS on an SLA document may come in many forms such as security, operational and serveability related QoS. These criteria have very unrelated QoS modelling benchmarks. Taking as a base serveability related performance, the criterion can be further broken into sub-criteria such as service accessibility, retainability, disengagement and service integrity [4]. The base substrate QoS criteria that we seek to build the QoS framework on in this paper is service integrity. An SLA-driven framework for managing service integrity QoS builds on the general set of performance parameters that are associated with maintaining a contract-negotiated end-user QoS in the NGN from an end-toend point of view during end-user service usage phase. Configuration metrics to maintain integrity QoS during service usage are related to user information transfer. Typical measures of service integrity during information transfer at the transport level, for example, are metrics such as throughput, sequence, latency, jitter and loss. Enforcing integrity QoS may sometimes require decisions to be made on very short time scales requiring speeds commensurate to bearer traffic flows. At the application-services level, more particularly in the SP domain, meeting user perceived QoS in the NGN is more than just mere conditioning of information transfer performance metrics. Moreover, while performance itself is important to maintain service integrity, the SP views QoS needs from a business perspective, and the end-user from a standpoint of getting value for money from using QoS-aware services, among other things. IV. QOS VIEWPOINTS A. End-User Viewpoint The viewpoint of the NGN end-user role is as follows: the user subscribes to a service provider (SP role) for a service or service bundle. Subscription takes a direct or indirect route through third party customer roles. During subscription, the user is provided with user-friendly high-level QoS categories such as gold, silver, or bronze, for example Video on Demand with gold quality. Categories other than the Olympic criteria may be used. However the end-user would want to have enough QoS categories to choose from but the selection list

3 should not be overcrowded. Technological jargon such as those found in SLSs should also be hidden from the user, unless asked. End-users in general have a slothful and thrifty characteristic, always lazy and seeking value for money. Once subscribed, the users demand that the system allows them to change subscription type any time, for example switching from gold to bronze for a particular service. Subscription change may take place when the users are consuming or not consuming services. The NGN end-users also want unfettered access to any service provider, freedom to use any terminal type and available access networks as they move from one point to another. The services consumed by the user may be real-time or non real-time communication, content, and transaction services. Some services may require complex service delivery mechanisms with full support from the service delivery infrastructure (NGN), of multimedia, multiparty and mobility (3M) of terminals, users and the services themselves. The Virtual Home Environment (VHE) [5], for example, is one such service delivery mechanism. Meeting QoS for the 3Mbrand services in the VHE mode can be a complex task. The NGN end-users do not care about the complexities in the NGN infrastructure and the technology used to delivered services to them. The end-users concern themselves only with the services they are consuming and whether the services are being delivered with agreed qualities. The users also expect the SP to comply with stipulated qualities when delivering services. Failure on the part of the provider to meet any or some of the requirements in the SLA may result in a course of action such as penalties or in some cases, finding a compromise. For example, the service provider may ask a user to accept a degraded service if it finds that it cannot meet agreed QoS. Sometimes failure to honour the contracted QoS could have been originated within the end-user domain itself or the user access network. For example, the user may request for services requiring bandwidth that either the terminal or the access network or both may fail to support. Sometimes the user might not have paid for the quality asked for, in which case the QoS request should be denied. Many other cases of compromise can take place. However, any feasible QoS framework should address the slothful nature and thrifty characteristics of end-users and the value-for-money concept. Penalties and other legal issues are not in this paper s scope. B. Provider Viewpoint The NGN as a service delivery infrastructure is itself complex and initial migration costs are large. The SP chooses to migrate to the NGN only as a strategic move to enhance its business aspiration. Always, the SP looks to reducing CAPEX and maximizing ROI. Meeting the end-user QoS requirement is not only challenging but introduces additional costs. The SP s obligation to meeting the various end-users perceived service QoS is only a marketing caption and a measure to escape contractual penalties. The SLA document itself provides a reference for doing so. In principle the SP has two tasks on hand: The first task is a question of making various end-user applicative services perform with QoS stipulated in the service contracts. The second, and most important to the SP, is how it can do so with minimum costs. Additionally the SP would want to put in place a mechanism that brings the end-user QoS concept into a business process whereby it can formulate a way of tapping revenue out of trading user-centric services with QoS differentiation. Performing such tasks in the NGN presents many challenges. C. Delivery Infrastructure (NGN) Viewpoint The NGN is driven by complex business models, an integrating architecture, populated with advanced capabilities both at the service and transport planes, and multiple technology standards competing to realise the vision. Also complex services and service delivery mechanisms involving multiple administrative domains are characteristic of the NGN. 1) Enabling Business Models NGN business models focus on efficient creation, sale and delivery of services. In the future there will exist multiple interactions between stakeholders bringing about diverse relationships. Enabling service trading models for the future are meta-market models in which multiple stakeholders with similar interests are united via unique selling points called mediators. Mediation does not introduce a new business model per se but introduces a framework that allows evolution of business models as the general status quo of the ICT industry changes [6]. Any feasible QoS framework for trading services with QoS needs to address mediation-based market models. 2) Architecture and Capabilities We build on the ITU-T definition in [7] to define the NGN as a concept embracing the collective improvements being made to the service provision infrastructures from the base of three traditional networks: the fixed PSTN/ISDN, second generation mobile networks, and the Internet whereby, the enhancements have brought about the convergence, firstly, of these networks through flexible interworking arrangements and, secondly, of service platforms. The NGN is also concept of defining networks based on a number of separations into layers, planes and open interfaces to support the evolution as shown in figure 2. Ref. [8] gives more details on the vision for the target NGN. Application Capability Functions Network Capability Functions Switching CPE Access Feature Server Telco SCF Telco NSCF Telco Network Core Application Server Application Server Federated SCF Federated NSCF Federated Network Core Fig. 2. Principal s and typical domains in NGN

4 Five principle layers are identified. a) Application : the locus of ICT application logic that may be in a telco or in an Application Provider (ASP) domain. b) Capability Functionality (SCF) : the locus of generic, stable and robust functionality to support traditional real-time and non real-time communication, content, and transaction services, and the emerging 3M services, employing network connectivity. c) Network Capability Functionality (NSCF) : the locus of functions that allow fulfilment of requests from the SCF layer for transport flows. d) Routing and switching: the part of the network transport domain layer that routes transport flows, aggregate or per flow. e) Transmission/Transport Flows: the means of carrying transport flows between elements such as switches. Domains at the transport network level may be arranged as follows: customer premises equipment in end-user domain, Access Network, Edge which may be inside or outside a core network domain, the Core network itself (which may be originating, transit or terminating and may play visited or home network roles), and Gateways. Domains at applications-services layer may play originating, transit or terminating SP roles and may also play visited or home service provider roles. D. Some QoS Management Requirements A QoS framework for managing end-user services should be an SLA-driven end-to-end QoS framework modelled on inputs of realistic viewpoints of end-user, service provider and the NGN roles like the ones brought up in the QoS viewpoints. The model must harmonise both the business aspects of future service trading models and the performance management aspects of the NGN into a common QoS model. The model must be aware of the layering and separation of concerns, and multiple administrative domains in the NGN infrastructure but should provide an integrated QoS management framework following a horizontal and vertical abstraction approach. The framework must be a technology independent framework with generic support for multiple NGN architectures, service platforms and transport networks. The framework must be capable of supporting QoS issues of a variety of existing and emerging NGN services including services delivered using complex service delivery mechanisms such as the VHE. The framework must emphasize user-centrism in its design and strive to meet end-user service performances with all the NGN infrastructure complexities. By so doing the framework should facilitate implementation of a dynamic, intelligent and flexible QoS system to deal with the unexpected conditions in the NGN, helping with service adaptation as required using broad criteria involving user s QoS choices, service provider and network policies and their performance issues. To date there exist many QoS frameworks, mainly for differentiated packet treatment at the IP layer. No particular framework exists that fully address real characteristics of the NGN QoS role players. A realist framework is required. V. CONCEPTUAL QOS MANAGEMENT FRAMEWORK MODEL Two key criteria are at the centre of modelling the SLA-driven QoS framework for managing end-user services in the NGN: the performance aspect of QoS management and the business aspects of trading telco services with QoS. The performance aspect answers the question of making the various end-user applicative services perform with QoS as stipulated in the service contracts. The Business aspect answers the question of meeting required service performances with minimum costs, following an SLA-driven QoS management approach. A sub-requirement of the business criteria is to show how a mechanism that incorporates QoS into a business process can be realised. Although the two criteria meet in the business process when trading telco services, there QoS modelling benchmarks are different. For example, meeting performance QoS may require hard response time bounds to make timely decisions related to performance QoS enforcement whereas the business QoS processing time requirements may be more relaxed. Also, requirements for interdomain QoS information signalling (messaging) for the two QoS criteria are different. For example, signalling performance QoS information might require an almost nonblocking channel, whereas the business QoS information channel may tolerate messaging over best-effort transport means. Moreover, business communication usually involves a lot overhead possessing such as security procedures. Clear distinctions must exist between QoS management entities carrying out business related QoS functions and those carrying out performance related QoS functions in the overall management framework. Based on this principle, we propose two types of QoS management components: engineering QoS management components that provide functional nodes where performance QoS requirements and those delivered come together, with retribution of performances if not honoured; business QoS management components that provide points where business related processes are conducted. We also clearly separate interfaces for exchanging performance QoS information (thick solid lines) from business interfaces (thick broken lines) as shown in figure 3. A. Concepts in the QoS Framework Model In a Level Agreement (SLA)-based end-user QoS management model, there is always a service around which SLA contracts revolve. There is also a supplier and a consumer of the service. In our model, the end-user is the consumer of the service. The SP is the supplier of the service. An assumption here is that there is no direct contractual agreement between the end-user and the transport provider on matters of service provision. The end-user relates to the transport provider through the SP. To provide a service to an end-user placed at some geographical distance (usually users are quite distant), the SP requests an NP in the end-user s vicinity for transport services. Two kinds of services emanate from this paradigm: the actual applications the user wants to consume from the SP, and the transport service that the SP receives from the NP. We distinguish the two types of services

5 Applicative Business Applicative Engineering Transport Business Transport Engineering Transport Resource Originating User User1 Interface User1 Engineering User1 Network Interface User Access User Business A Originating Applicative/Network Providers SP1 Engineering NP1 Engineering Applicative/Network Provider Access SP Business A NP Business A Transit Applicative/Nework Providers SP2 Engineering NP2 Engineering Access Network 1 Core Network 1 Core Network 2 Applicative/Network Provider Access SP Business B NP Business B Terminating Applicative/Nework Providers SP3 Engineering NP3 Engineering Core Network 3 User Access User Business B NP Business C NP4 Engineering Access Network 2 Terminating User User2 Interface User2 Engineering User2 Network Interface Fig. 3. Conceptual QoS Management Framework Model. Broken thick lines depict interfaces for business QoS information. Solid thick lines represent interfaces for exchanging performance related QoS as follows: the term Applicative is used to mean the user-centric services, and Transport is used to refer to the transport service offered to the SP. The Applicative Provider plane, for example, holds the combined layers of the Application and SCF layers of figure 2. The Transport network Provider plane holds the NSCF, Routing / switching, and the transmission layers. We also use two terms quite distinctly in the QoS framework: Engineering and Business. Engineering is used to denote the collective technical processes required to deliver services with the required performance QoS. Business is used to denote the business processes taking place in the business layers. B. Architectural layering The concept of Applicative and Transport is used to identify the layers. Originating, Transit and Terminating roles of SPs and NPs are shown. Originating and Terminating roles of end-users are also shown. Engineering and Business layers are clearly separated both at the applicative service provider and transport service provider planes. The layers and domains are populated with QoS management components. An arbitrary layout is shown of how the components may be distributed for end-to-end QoS management in a two-party call scenario across the three roles that providers may play (originating, transit, and terminating). Five principle layers are identified: 1) Applicative- Business (ASB) : the locus of management components on the applicative service provision plane for QoS handling at business level. The ASB layer runs from an originating user access domain through participating SPs to a terminating end-user access domain. The end-user gains access to the SPs part of the ASB layer through a User Business (UBC) in the user access domain. 2) Applicative- Engineering (ASE) : the locus of performance QoS engineering components on the applicative service provision plane. The ASE layer runs from an originating end-user domain, through participating SPs to a terminating end-user domain. In addition to playing originating, transit, and terminating SP roles, participating SPs may also play visited or home service provider roles. The home SP is the SP who knows the end-user. The visited SP is the SP domain where the user currently requests services from when roaming. The visited SP does not normally keep subscription data about the visiting user. The home SP has full subscription data about the roaming user, including QoS categories for services subscribed, which must be furnished to the visited SP. The ASE layer is also populated with Application / SCF components of participating SPs which may be highly heterogeneous themselves, developed on different NGN service architectures such as Parlay, JAIN and TINA. 3) Transport- Business (TSB) : the locus of QoS management components on the transport service provision plane at business level. The TSB layer runs from an originating NP business domain to a terminating NP Business domain. 4) Transport- Engineering (TEB) : the locus of performance QoS engineering components on the transport service provision plane. The TEB layer runs from an originating NP domain through participating NP domains, to the terminating NP domain. The TEB layer also hosts NSCFs of participating NPs such as call admission control. 5) Transport Resource : the locus of transport networks. Heterogeneous networks populate this layer such as PSTN / ISDN, 2G, 3G, IP, ATM, MPLS, DWDM. C. Description of s and Domains Four generic domains and six generic QoS management components can be identified in figure 3: 1) Generic s a) User Business (UBC): a functional node hosting specialised functions that the user needs to access the SP domain at the business layer. UBC functions are required, for example, to provide end-users with unfettered access to the SPs, help users choose the SPs and particular services, QoS categories and signing SLAs. The UBC in general emulates a flight reservation agency in the airline transport business model where on one side it presents a user-friendly customer interface, and on the other side it has an enormous task of coordinating with various SP business entities on behalf of customers. More particularly the UBC emulates in part a QoSaware Retailer in the TINA Business Model [10] and an

6 Access Mediator in [11]. One UBC serves many end-users. b) User Engineering (UEC): a performance QoS component that emulates in part a user context component in [9] with QoS bias. The UEC takes a partner role for an SP Engineering (SEC) component on the SP side. A common interface exists between the UEC and SEC for QoS signaling at and during service usage. c) SP Business (SBC): receives requests from UBCs for service requests. The SBC coordinates with an SP Engineering (SEC) of the SP that provides the requested service, and with NP Business s (NBC) for transport services at the business layer. Many SECs may own one SBC. The SBC concept also satisfies the requirement for trading telco services in a mediation-based meta-market model in [6]-[11]. d) SP Engineering (SEC): responsible for end-user QoS fulfilment. It also works with an SP s call / session managers for end-to-end QoS signaling and control across other SPs and the participating NPs. Two forms of signalling may take place: the SEC translates SLAs into network parameters which are then signalled to other providers. Or if there is an agreed standard set of QoS classes, QoS classes should be signalled instead. A QoS enforcement point in the participating NP translates the classes into network parameters. The later is preferred to reduce signalling load. Since the ASE layer (end-to-end) may host heterogeneous service components within and among participating SP domains, the SEC must support them or provide minimal adaptations for the same. One SP role owns one SEC. e) NP Business (NBC): receives requests from SBCs for SPs access to network resources. The NBC does not know specific details about the transport resources. Negotiations take place at the business layer. The NBC forwards requests to the appropriate NP where actual granting of the network resources and QoS enforcement takes place. The NBC also negotiates with other NBCs for transport business associations. One NBC can be owned by many NPs. f) NP Engineering (NEC): Transforms QoS parameters or classes into network demands. The NEC works with NSCF capabilities to enforce QoS. One NEC is owned by one NP role. However an NP may own more than one transport network which may be heterogeneous. The NEC needs to have generic support for all network cases. 2) Generic Domains a) User domains: locus of components residing at the enduser site. Only one QoS component (UEC) is shown in this domain type in figure 3. The User and User Network interfaces are not QoS components. b) User Access domains: locus of components associated with user access and can be populated by the UBC, NBC and NEC component types. For example, at the originating side in figure 3, only a UBC is shown whereas at the terminating side all three component types are shown. This is because the access network (Access Network 1) at the originating side is managed by NP1. Business QoS requirements for NP1 are managed by NBC_A. At the terminating side, the assumption is that Access Network 2 is managed by NP4 whose business QoS issues are handled by NBC_C. c) Applicative/Network Provider domains: locus of transport network and applicative service providers QoS management components. Engineering functions to run the applicative and transport services are shown. QoS components in this domain are SECs and NECs. However an access NEC could exist in the user-access domain if a separate NP other than the one managing the core network manages that access network, in which case the separate access NP should have its own NBC to manage its business QoS as depicted in figure 3. d) Applicative/Network Provider Access Domains: locus of business QoS components associated with provider access. Both the SBC and NBC are shown in these domain types. VI. CONCLUSIONS AND FUTURE RESEARCH We have shown how an SLA-driven QoS framework for managing end-user services in the NGN can be realised. The framework is an integrated QoS framework that harmonises the business concerns of future service trading models and the performance management aspirations of the NGN into a common QoS model. We are decomposing the framework and modelling in detail the identified framework components and will come up with an information model and a prototype implementation of the framework. A model-driven software development approach to implementing the framework is proposed to provide a technology-independent implementation which can be mapped to platform specific implementations of providers. VII. REFERENCES [1] ITU-T Recommendation E.800, "Terms and definitions related to quality of service and network performance including dependability", Geneva [2] t.html, last accessed, June 22, [3] G. Gylterud and S. Tognon, Non-functional aspects of OSA, Proceedings of the 8 th International Conference on Intelligence in next generation Networks (ICIN), Bordeaux, France, March-April [4] S. Åberg, et al, OSS Quality of API Version 1.0 Overview (Part 1), OSS through Java Initiative, Revised June [5] R. Roque1, et al, VESPER Project - Validation of VHE Concept, 1- PT Inovação, Lg. Mompilher, 22, 2º, 4050 Porto, February 2001, Portugal [6] M. Smirnov, Group Mediation - A Business Model for Mobilised Internet, 2 nd International Workshop on New Models of Business, St.- Petersburg, Russia, June [7] C. Young-Han, Next Generation Network activities in ITU-T, Proceedings of the 8 th International Conference on Intelligence in next generation Networks (ICIN), Bordeaux, France, March-April [8] H. Hanrahan and D. Mwansa, A Vision for the Target Next Generation Network, Submitted to SATNAC2003, [9] R. Christian and H. Hanrahan, User Context Functionality Requirements for Next Generation Network s, Work In Progress Paper, Submitted to SATNAC2003, [10] M. Yates, et al, TINA Business Model and Reference Points, Telecommunications Information Networking Architecture Consortium, May [11] G. Cortese et al., CADENUS: Creation and Deployment of End-User s in Premium IP Networks, Advances in QoS: the European IST Premium IP Projects, Vol.41 No.1, January See [8] for authors biographies.