20.11.2012 Views

Contents Telektronikk - Telenor

Contents Telektronikk - Telenor

Contents Telektronikk - Telenor

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

56<br />

Architectures for the modelling of QoS functionality*<br />

BY FINN ARVE AAGESEN<br />

A service is the behaviour of some functional<br />

capability. Quality of service<br />

(QoS) is a measure of the relative frequency<br />

of specific events within a service.<br />

These specific events are used as<br />

quality criteria for proper service functioning.<br />

The functional architecture of a telecommunication<br />

service providing system is<br />

defined as the total set of functional elements<br />

and the dynamic relationship between<br />

these functional elements. This<br />

architecture has both an operational and<br />

a management part. The operational<br />

architecture defines the primary functionality<br />

related to the real-time handling of a<br />

call, while the management architecture<br />

represents the additional functionality<br />

needed for the administration of the operational<br />

functionality. A QoS architecture<br />

is a view of the functional architecture,<br />

focusing on traffic-resource-related<br />

aspects. A QoS service is defined as the<br />

QoS-related aspects of a service relationship.<br />

An optimum traffic solution is related<br />

to the existence of an optimum QoS<br />

architecture.<br />

This paper discusses state-of-the art for<br />

QoS architectures for telecommunication<br />

service providing systems. The ISO/OSI<br />

and the ITU-F/ISDN QoS frameworks<br />

are presented. Some reflections on the<br />

ideal QoS architecture are also given.<br />

Keywords: Computer-Communication<br />

Networks, Network Architecture and<br />

Design, Network Protocols, Telecommunication<br />

Networks, B-ISDN, Quality of<br />

Service.<br />

1 Introduction<br />

1.1 QoS in perspective<br />

During the last few years, an increased<br />

attention has been given to the concept of<br />

Quality of Service (QoS). For telephone<br />

networks and circuit-switched data communication<br />

networks, QoS has always<br />

been taken seriously. During several<br />

decades, there has been a significant traffic<br />

research related to the QoS aspects of<br />

these systems, and the system design,<br />

standardisation and planning cultures<br />

have been QoS-oriented. The distances<br />

* Part of the work reported in this paper<br />

was done under contract with <strong>Telenor</strong><br />

Research as a part of the project “QoS<br />

in Layered Architecture”.<br />

between the traffic research, system<br />

design, standardisation and traffic planning<br />

cultures have been relatively short.<br />

As the packet switching technology was<br />

introduced in the 1970s, this co-operative<br />

QoS-oriented culture was not inherited.<br />

Considering the standardisation, QoS<br />

concepts have been defined and discussed,<br />

but many QoS-related items are<br />

either “for further study”, “left to the network<br />

service provider”, or not mentioned<br />

at all. The driving force behind packetswitching<br />

has been service- and protocol-oriented<br />

rather than QoS-oriented.<br />

There has been a significant traffic research<br />

related to packet switching. However,<br />

there are gaps between the traffic<br />

research, the system design and standardisation<br />

and the traffic planning cultures.<br />

The B-ISDN specification and standardisation<br />

process has shown similar symptoms.<br />

It is well-known that ATM is much<br />

more vulnerable to bad dimensioning and<br />

non-optimal functionality than packetswitching.<br />

There has been a considerable<br />

traffic research related to the traffic<br />

aspects of ATM. However, there has<br />

been a gap between the traffic research<br />

and the system specification and standardisation<br />

cultures.<br />

So, how come that QoS has not been<br />

appropriately handled for packet-switching<br />

and ATM? One obvious explanation<br />

is that QoS is difficult to handle. The<br />

appropriate handling requires a total view<br />

of the user behaviour parameters as well<br />

as an understanding of the various<br />

aspects of the system functionality. One<br />

other explanation is that the objective of<br />

the protocol-related standards is to focus<br />

on the interaction aspects between systems<br />

and on the information that is<br />

exchanged. QoS-related aspects can<br />

therefore fall out of the standardisation<br />

context. Protocol data units (PDUs) related<br />

to traffic-resource allocation are of<br />

interest, but locally applied functionality<br />

for the allocation of traffic resources are<br />

not. In a way QoS has not been important<br />

enough. It seems now, however, that the<br />

time is mature for the handling of QoS in<br />

a more systematic way and from the view<br />

of totality.<br />

One reason for this increased focusing on<br />

QoS is that the explosion in the use of<br />

Internet has demonstrated the insufficiency<br />

of QoS-less protocols in high load situations.<br />

Internet is periodically so overloaded<br />

that the network is practically<br />

useless for planned professional work. A<br />

second reason is the awareness of the<br />

QoS-related problems faced in the ATM<br />

standardisation. ATM is by politicians<br />

and industry allotted the role of the backbone<br />

of the future Information Super<br />

Highway. QoS concepts are given much<br />

attention in the ATM standards. However,<br />

there is a lack of conclusions. If the<br />

QoS problems of ATM are not solved,<br />

ATM can adopt the nature of the connection-less<br />

Internet or the circuit-switched<br />

X.21, with upgraded bandwidths. A third<br />

reason for the increased focus on QoS is<br />

the growing number of applications with<br />

well-defined QoS requirements. The<br />

obvious inadequacy of the OSI transport<br />

layer to handle the well-defined QoS<br />

responsibility has stimulated the QoS discussion.<br />

The new evolving set of applications<br />

are represented by the “multimedia<br />

culture”. This culture, seeing the communication<br />

system from above, has also<br />

contributed with their own solutions to<br />

many of the non-solved problems of<br />

packet-switching and B-ISDN.<br />

So it seems that time wants QoS solutions<br />

rather than “for-further-study” classifications.<br />

The QoS-oriented culture that<br />

has been typical for the circuit-switched<br />

communication era may get its renaissance<br />

in the high capacity and multimedia<br />

communication era.<br />

1.2 Outline of this paper<br />

A summary of state-of-the art for QoS<br />

architectures for telecommunication service<br />

providing systems is given. It will<br />

be focused on the QoS aspects of the primary<br />

operational functionality of a system<br />

in a proper functioning state.<br />

Section 2 gives a presentation of generic<br />

concepts. Concepts such as service, QoS,<br />

QoS service, QoS architecture and traffic<br />

handling functionality are defined.<br />

Section 3 presents the ISO/OSI view of<br />

QoS, which is defined within the framework<br />

of the hierarchical OSI model. The<br />

OSI QoS Framework that is now under<br />

work is a valuable contribution to the<br />

introduction of QoS in packet-switched<br />

and ATM systems. However, so far, the<br />

framework is preliminary, and the intention<br />

must be followed up in the specific<br />

standards. Section 4 presents the narrowband<br />

and broadband ISDN views of QoS,<br />

defined within the framework of a usernetwork<br />

relationship.<br />

In Section 5, the characteristics of an<br />

ideal QoS architecture is discussed. An<br />

application-oriented QoS service is an<br />

important element within an ideal QoS<br />

architecture. Section 6 gives summary<br />

and conclusions.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!