Contents · 2012-12-18 · Contents Telektronikk Volume 94 No. 1 - 1998 ISSN 0085-7130 Editor: Ola Espvik Tel. + 47 63 84 88 83 Status section editor: Per Hjalmar Lehne Tel. + 47

Contents

Telektronikk

Volume 94 No. 1 - 1998ISSN 0085-7130

Editor:Ola EspvikTel. + 47 63 84 88 83

Status section editor:Per Hjalmar LehneTel. + 47 63 84 88 26

Editorial assistant:Gunhild LukeTel. + 47 63 84 86 52

Editorial office:TelektronikkTelenor AS, Telenor Research & DevelopmentP.O. Box 83N-2007 Kjeller, Norwayemail: [email protected]

Editorial board:Ole P Håkonsen, Senior Executive Vice PresidentOddvar Hesjedal, Vice President, Research & DevelopmentBjørn Løken, Director

Graphic design:Design Consult AS

Layout and illustrations:Gunhild Luke, Britt Kjus, Åse AardalTelenor Research & Development

Feature

Status

Special

International Research and Standardization Activities in Telecommunications: Introduction, Per Hjalmar Lehne ................................................... 149

The EU Research Programme ACTS – A GeneralDescription with Focus on Telenor Participation, Rolf B. Haugen ......................................................... 150

InfoWin – Multimedia Information Window for ACTS,Thorbjørn Thorbjørnsen and Claus Descamps ........ 159

FERT – Forum for European R&D inTelecommunications, Tor M. Jansen ....................... 164

Mathematical Model and Algorithms forFABONETT/SDH, Ralph Lorentzen ........................ 135

CORBA and Intelligent Networks (IN),Helge Armand Berg .................................................. 119

Jada: Java, Architecture, Development and Application, Arne Solevåg Hatlen, Øystein Myhre, Birger Møller-Pedersen and Stig Jarle Ness ............ 125

Guest editorial, Arve Meisingset ................................... 1

Introduction to Information Systems Architecture,Arve Meisingset ............................................................ 3

The Urd Systems Planning Method, Arve Meisingset .......................................................... 12

Decomposition and Granularity in Systems Planning, Sigrid Steinholt Bygdås .............................................. 22

The Role of Subject Graphs, Arne Solevåg Hatlen .... 28

Three Perspectives on Information SystemsArchitecture, Arve Meisingset .................................... 32

Alliance Approach to the TMN X Interface, Ronald Bonica ............................................................ 39

The Open Service Layer Protocol (OSLP), Ronald Bonica ............................................................. 48

Introduction to RM-ODP – A Reference Model ofOpen Distributed Processing, Håkon Lønsethagen .... 55

RM-ODP for Transport Network Modelling– An Example, Håkon Lønsethagen ........................... 67

Engineering Communicating Systems,Knut Johannessen ....................................................... 79

The TINA Architecture, Tom Handegård and Lill Kristiansen ......................... 95

CORBA as an Infrastructure for Distributed Computing and Systems Integration, Håkon Solbakken (ed.), Ole Jørgen Anfindsen, Eirik Dahle, Tom Handegård and Kjell Sæten ......... 107

When IT managers are asked inwhich area they have greatestneed for contributions, theytypically answer IT architecture.IT architecture is considered tobe a means to control bothevolution of systems and changeof technology. A telecommuni-cations operator typicallymanages several hundreds,maybe thousands of internalcomputer systems running ontens of different technologies.This picture is extended withsoftware from different vendorsin the telecommunicationsnetwork itself, in service pro-visioning and for communicationwith vendors, partners, retailersand customers. The IT managersrequest means to manage currentand future systems to servethe varying needs of the organ-isation in a timely manner. Astelecom operators are replacingmuch of their personnel bycomputer systems, cost effectiveoffering and management ofthese systems become critical tothe survivability of the company.

The IT architecture subject has in some way or other beenaddressed since the first creation of computers. Systems plann-ing problems have been addressed for a generation (30 years).Still, IT architecture at large is a poorly understood subject andsome aspects have been shown relatively little attention byacademia. One reason for this may be that large systems andlarge families of systems are only addressed by the industry andthey exceed the size of academic studies. Also, the effects of anew systems plan may come ten years after introduction, whenthe original plan is forgotten and the analysts are gone. Thedesign of individual smaller systems provides a more manage-able and controllable size for theory development and valid-ation. Added to this situation, the IT architecture subject isburdened with much sloppy terminology and marketing slogans.The fact that terminology and architectures are interwoven andmotivated by marketing and power struggles within the organ-isation should come as no surprise to the critical reader.Therefore, the analysts will have to face many obstacles in thedevelopment of much needed rational approaches to IT archi-tecture.

To make the scope of this issue clear, I have to introduce someterms which are frequently used with overlapping and undefinedmeanings. The term Information Technology, IT for short, cov-ers a vast area of computer and telecommunications techno-logies, media, and their usage. I will use the term InformationSystems, IS for short, to denote both manual and automaticsystems used to provide or manage information to some users.Thus, an automatic IS denotes use of IT in a system which pro-vides information to some users. Actually, an automatic ISmanages data only. The data may provide information and/orknowledge to some users. When using the term IS, we consider

the high level user relatedaspects of the systems and dis-regard the low level hardwarerelated aspects. The term IT ismisused in most organisations,as exemplified in the first twoparagraphs of this introduction,as well. Organisations not pro-ducing the technology shoulduse the term IS and avoid use ofthe term IT.

The term Information SystemsArchitecture, ISA for short, isused to denote the overallstructuring of an informationsystem or a family of inter-connected information systems.We will decompose ISA intotwo orthogonal dimensions:

• An information systems planprovides an overview of whatsystems are planned to existin some area and the inter-connections between thesesystems

• A system architecture pre-scribes the structure of onesystem or a class of systems.

The term system appears in both these definitions. Aninformation system we consider to be made up of a set of dataprovided with a mechanism to enforce the consistency of thesedata. An automatic information system can be centralised or dis-tributed; however, it is the scope of the consistency enforcingmechanism which defines the boundary of the system and theboundaries between systems.

The assignment of functionality to systems we call evolutionplanning. Evolution planning is typically operational (one yearrange) or tactical (two – three years). More radical designs orredesigns of a family of systems, i.e. information systemsplanning, is considered to belong to strategic planning (typicallythree or more years into the future). This issue focuses onstrategic rather than evolution planning. Also, we do not addressin any detail the assignment of functionality to systems; neitherthe detailed design of user interfaces to systems. User interfacedesign relates to systems planning, as data and interfaces aredesigned relative to tasks, and the tasks are defined relative tothe data and interfaces they will manage. Hence, tasks andcomputer system boundaries have to be designed interactively,and not in a strict sequence!

We will use the term migration planning to denote the planningof migration from one system architecture and/or infrastructureto another.

The term system architecture denotes the structuring of thesystem IS itself, while infrastructure denotes the software andhardware environment in which the IS is running. The terminfrastructure comprises the execution platform, as well as tools

1

Guest editorialA R V E M E I S I N G S E T

Telektronikk 1.1998

used to develop and manage the software. The term system soft-ware is used as a synonym to the term software infrastructure.The infrastructure may impose restrictions on the system archi-tecture of the IS.

Frequently, evolution and migration planning are linked, as thefunctionality of a system is typically changed when the systemis being migrated. This issue of Telektronikk addresses platformissues. Migration planning is not covered. However, needs formigration is motivating the papers on platforms. System archi-tecture is addressed in some of the papers, but is not coveredextensively. To separate the telecommunication network fromservice provision is one of the particular architecture issues forthe telecom domain. Interoperation of alliance partners is an-other topic. Both these topics are addressed.

The previous paragraphs define not only the scope of this issue,but also the focus of current research on ISA in Telenor R&D.Furthermore, the paragraphs provide some indications of thelimitations of this research, even if some planned papers aremissing. The first paper of this issue provides an introduction toISA. If information systems planning is paralleled with cityplanning, systems planning relates to which buildings shouldexist, and what communication is needed between thesebuildings. The platform issue relates to which basements thesebuildings should have. Even if these questions provide a limitedview on ISA, they are fundamental questions of any architecturework, and I hope the reader will benefit from reading ourquestions and answers.

2 Telektronikk 1.1998

This paper parallels informationsystems architecture with city plans,building architecture and construc-tion. The paper discusses the merits ofsystems planning and human-com-puter interface design at large, anddiscusses the dependence on organisa-tion of users and tasks. Informationsystems architecture is as conflictingan area as city planning. The paperwill highlight some of these conflicts.The information analyst may be pro-vided with rationale techniques toanalyse systems and organisations,however, for the choice of values andloyalty there is no objective and in-dependent position. Also, informationsystems architecture is no unique field,but consists of several sub-fields, forwhich specific expertise and app-roaches are needed. The paper makesan attempt to distinguish these fields.

From solitude toabundance

A traditional Norwegian house – as wedream of it – is placed in nature, distantfrom other houses. It is a white house,accompanied with a red farmhouse, afruit garden, a few flowers and small pat-ches or strips of green fields, surroundedby a huge forest, mountains and fjords.This solitude can be compared with theearly days of computing, when a fewcomputer systems were surrounded by amainly manual organisation. As a con-trast to this romantic picture, Figure 1provides a modern functionalistic viewon architecture.

In the 1970s systems developers inScandinavia [1] were pretty conscious ofthe social environment of computer sys-tems, how systems were used and whatco-operation between management andemployees was needed for the success oftheir use. The project workers wereconscious of what work should be auto-mated and what should not. In particular,the critical school of systems develop-ment contributed to making the labourunions become constructive participantsin the development of computer systems.This co-operation has been weakened inthe 1990s, in particular as business pro-cess re-engineering (BPR) consultants[2] have brought the system-theoreticalschool with some new icons from USAback to Scandinavia and thought thenews was progress. They do not seem tohave knowledge of the historical de-

velopment of Scandinavian systemsthinking from the system-theoreticalschool (Langefors), via the socio-tech-nical school (Høyer) to the critical school(Nygaard) and design of artefacts (Ehn)[3] (Dahlbom) [4], nor of their relation-ships to Taylor, Mumford, Marx, Hegeland Simon. Certainly not to activitytheory [5] and Soviet philosophy [6]– or to John Dewey’s Theory of inquiry(1938). These mentioned authors providesome of the basic texts for any inquiryinto the design of manual or automaticinformation systems.

A multimillion dollar BPR project inTelenor has produced a stack a couple ofmetres high of PowerPoint paper copiesand many promises in the internal press.Nothing of this is applicable for com-puter systems development – not even assurveying material, and neither may suchusage have been intended. Our manage-ment claimed that the work was urgentand most important. However, the resultsfrom the project, if any, are highlyquestionable.

3

Introduction to Information Systems ArchitectureA R V E M E I S I N G S E T

Telektronikk 1.1998

Figure 1 Hannes Meyer: Proposed design of the League of Nations’ building inGeneva, 1927 (not built). In Hannes Meyer’s opinion a completely rational building,where size, form and interior design are unconditionally determined by technical andfunctional requirements. The ‘rationality’ is underlined right down to the method ofsketching and the choice of the print. (From Nygaard, E. Arkitektur i en forvirret tid :Internasjonale strømninger 1968–94. Copenhagen, Christian Ejler, 1995.)

Today, a large proportion of the officeroutines are automated by computers,and reorganisation of the company is justas much a question of organisation ofcomputer systems as of organisation ofpeople. The BPR project proves thatmany organisations are willing to spendmuch money on addressing computersystems in an organisational context.

Poverty andmisconceptions

Much housing architecture in Norway istraditional, with old brown timber styles,white or otherwise painted houses fromearly this century, and fishing villages –all in wood. However, mass production,panorama windows, new materials,petrol stations, and bad functionalismhave frequently provided a poor result.There are exceptions, like stavechurches, stone churches, Hanseatictowns, old mining towns, a Jugend styletown, advanced functionalism from thiscentury and some good modern archi-tecture of public buildings.

Many human-computer interface systemdesigners seem to think that anything isgood if they just use windowing, iconsand pop-up menus. However, these arethe architectural parallels to petrolstations and shopping centres. Thegraphics and contents take their modelsfrom books for pre-school children. TheIS user interfaces are frequently of poorquality. If the programmers tried topublish on paper, their products – bothcontent and editing – would frequentlynot be accepted.

Many current web-pages are clutteredwith graphics – which increase both tele-communication transmission time andhuman interpretation time. Databaseapplications frequently use panels withsmall windows for individual fields andtables, which clutters the overall rela-tionships and presentation of the infor-mation. The metaphors for desktops havebeen used and misused in areas wherethey do not fit, for example in databasemanagement and process control.Widgets appropriate for the windowframe are frequently and inappropriatelyput into the window working area.Windows are cluttered with information– like advertisements on a shoppingcentre window. This is the opposite endof the quality scale from what is providedby contentious and knowledgeable bookprinters. Therefore, we need old

knowledge rather than new knowledge tohuman-computer interaction design. Weneed purity rather than overloading, andwe need to investigate recurrent patternsother than current windows metaphors.Consciousness about aesthetic values andstyles has to be radically improved.Fundamental questions about the designof user interfaces at large should beaddressed: What are good user interfacepatterns of various kinds of computersystems? Is it really true that screenpresentations should differ from paperpresentations? Should we alternativelystrive for compatibility between andindependence of media?

Information systemsplanning parallelledwith city planning

Norway has few examples of consciouslyplanned architectures at large, wheretowns and landscapes are formed arti-ficially, to support human living. How-ever, the common Danish-Norwegianking Christian IV used quadratic streetplans in his many renewed town designs,like Kristiansand and Oslo. There are afew examples of artificial landscapedesigns, like the Fredrikstad fortress andthe Vigeland park. The most striking


CE

B

D

A1 A2

Figure 2 Organic growth and planned urban form diagrams.Key: A – two characteristic kinds of Organic Growth: Western European (A1),providing for street frontage plot development and Mesopotamian/Islamic (A2) withhousing access culs-de-sac; B – the gridiron as the usual basis of Planned UrbanForm; C – an organic growth nucleus with planned gridiron extension, loosely basedon Edinburgh; D – a planned gridiron nucleus with organic growth extension, looselybased on Timgad; E – the special three-dimensional Western European circumstanceswhereby an early medieval organic growth pattern was superimposed on theabandoned gridiron of a temporarily deserted Roman city – based on Cirencester,England. (From Morris, E A J. History of Urban Form : Before the industrial revolu-tions. Longman, Scientific & Technical, Third edition, 1994.)

examples, though, are roads, railwaysand bridges that have been transformingthe landscape of modern Norway.Bridges and roundabouts have becomeobjects for artistic expression. Figure 2provides some conceptions of city plans.

Information systems planning is in [7]compared with city planning. Informa-tion systems planning is as different fromthe development of individual computersystems as city planning is different frombuilding design.

City planning – or the lack of it – hasprofound impact. Motorway inter-changes, brick, asphalt, aluminium,glass, cars, noise and exhaust can have adevastating impact on the living condi-tions of the inhabitants, while organicGerman villages or harmonious StPetersburg provide much richer conditi-ons. Villages are frequently not strictlyplanned, but regulated by some kind of

consensus, while St Petersburg is develo-ped according to a grandiose plan. Theexamples show the importance of choo-sing an appropriate perspective on cityplanning and of realising what interestsare being served. The unlimited power ofPeter the Great may help when develo-ping a city plan, but more modest appro-aches may provide just as good results.

The current situation in a company likeTelenor is that most data and functionsare already automated. Some computersystems are up to 20 years old, use oldtechnology, are adapted to an organisa-tion extinct many years ago, and are notsupporting new technology in the tele-communication network. Neither maythey support new services to the cus-tomer, new organisation of work, andservice management by the customersthemselves. Examples of such mis-adap-tations exist, even if this is not a balancedpresentation of IS in Telenor. However,

these are some of the reasons why ISarchitecture is listed as the highest prio-rity work item by most IS managers [8][9]. The prescription used for this diseaseis frequently to provide a business infor-mation framework [10] [11] [12] [13] tosurvey all systems, data and work pro-cedures of the entire organisation and toimplement procedures for requirementcapture and implementation. Theseapproaches are at great risk of controllingeverything, but creating nothing. Afocused approach on a problem areawhich needs attention can be much moresuccessful than attempts at developing agrandiose plan for everything. The pre-ferred degree of integration can be diffe-rent for components of one system, forsystems within one business unit, forbusiness units within one corporation, forpartners within an alliance, for vendor-customer relationships and for competingparties requiring some co-operation.Each kind of co-operation may needdifferent focus and approaches to sys-tems and communication planning. Notethat still other techniques may be neededto define software components and iden-tify commonalities and differences tosupport reuse and sales of software com-ponents to customers having similar butdifferent needs.

Organisation struggle

Frequently, IS architecture is by the ISmanagers considered as a means toempower the IS department itself. Byintroducing strict management pro-cedures, the IS department hopes toacquire control of the situation and not tobe dependent on the unpredictable will ofthe business units only. The IS depart-ment has often been frustrated by thebusiness units introducing new tech-nology in the network and for serviceprovision, and only thereafter ask foradministrative support by computer sys-tems. Therefore, a co-ordinated business,technology and computing strategy issought for. Also, a corporation wide ISdepartment can claim to have a moreglobal perspective than the individualbusiness units. However, the businessunits are created to provide more indi-vidual freedom and flexibility than whatcan be achieved by one centralisedorganisation. The business units areestablished in a period of great change intechnology, services, markets, regula-tions and competition. The divergence ofthe corporation into business units canprovide the corporation with dynamic

5Telektronikk 1.1998

Box 1 Terms and definitions

Systems planning - identification and delimitation of what systems shouldexist, and identification of the relationships betweensystems

Communication planning - identification and standardisation of communicationflow, contents and means

Evolution planning - planning of transition from current systems toplanned systems

Systems framework - the analysis and design environment provided to thedeveloper, within which he undertakes his work

System architecture - structuring of each system as seen by the systemdeveloper as the primary user of the architecture

System development - surveying, analysis, design, implementation, testingand installation of an individual system or a com-ponent of a system

Change management - management of change requests, analysis of changeeffects, management of changes and provision of thechanged system

Infrastructure - the total environment in which a system is runningand supported

Platform - the hardware, software and middleware on which thesystem is running

Migration planning - planning of transition from current infrastructure tonew infrastructure

Software portfolio planning - planning of software components to be provided tosome market, and which can be variously configuredin customer systems

powers to compete with small inde-pendent companies [14]. This indicatesthat centralisation of the IS departmentand the split of the corporation intoseveral business units may serve con-flicting interests. The conflicting direc-tions can also be interpreted as attemptsby the top management to ‘ride twohorses’ into an uncertain future, or itshows lack of a clear strategy. The ISanalysts will in this situation be forced tochoose between conflicting interests, asdescribed by the critical school of sys-tems development – there is no inde-pendent and objective position. However,the analyst can investigate consistencyand consequence of choices, and he maytry to balance conflicting interests. Theidentification and formulation of strate-gies and perspectives are central themesand means of power struggle.

Current IS architecture work has replacedmuch of the previous ‘data modelling’work. During the 1980s several organisa-tions attempted to define and harmoniseuse of terms throughout the entire corpo-ration. Some of this work proved veryuseful, like introduction of organisationwide customer identifiers, product identi-fiers, etc. However, most of the work

lacked focus and priorities. New datadefinitions were developed for systemsto be implemented 5–10 years into thefuture, and proved to be non-appropriateor forgotten when needed. A morefocused approach to defining data foremerging systems only, and to co-ordi-nate data only when found beneficial andurgent could have produced better cost-benefit. The data administration of the1980s centralised power and bureaucracywithin the IS departments without pro-ducing the prospected benefits. De-centralisation of data administration toindividual business units with co-ordina-tion between business units only whenneeded could have produced betterresults and a more sustainable organisa-tion of the work. The central data admi-nistrator in the IS department could thenhave concentrated on initiation, teaching,supervision and co-ordination, withoutbeing responsible for managing his owndata administration people and theirtasks.

During the 1990s, IS architecture hasreceived much of the attention given todata administration during the 1980s.The challenges being addressed aregreater than those facing the designer of

individual systems. The reasons for thisare the greater size of the problem ofanalysing the whole corporation ratherthan an individual system, problems withchoice of an appropriate level of detail,abstraction versus the concrete, organisa-tion dependence versus independence,technology dependence versus indepen-dence, and short term versus long termplanning. The risks for misconceptions,unfocused organisation of work, and useof inappropriate techniques are veryhigh. Only a small portion of the effortsput into IS architecture will produce use-ful results. Also, little or no appropriateeducation in – and knowledge of – thefield is available. A manager may be sur-prised by this situation; however, if hecompares with city planning, he shouldnot be surprised. Despite the risks, mis-adaptions between computer systems andto the organisation of the company makeIS architecture work most needed.

Information systemarchitecture paralleledwith building design

A traditional Norwegian home applies afunctional layering of its floors: Thecellar is used as washroom and as foodstore for potatoes, cabbage, canned food,etc. The ground floor contains theentrance, living rooms and the kitchen.The bedrooms and a bathroom are foundon the first floor. The loft is used to storeaway unused furniture, carpets andmaybe dried meet and fruit. Figure 3shows some architectural patterns.

Similar functional layering softwarearchitectures are being developed forcomputer systems; however, their roleand purpose are more unclear. Softwarearchitecture is concerned with the organi-sation of software systems, functions anddata as perceived by the end users anddevelopers.

The client-server architecture arrivedwith personal computers and work-stations allowing more computing to takeplace in the client. Fat clients have beenfound easy to implement, but thin serversare not found very efficient for servingmany users simultaneously. Fat serverscan be efficient, but provide in principlenot much different from IBM 3270alphanumeric and graphical dialogues ondumb terminals available in the early1970s. Today, this is called networkcomputing. More balanced architectures


Figure 3 Construction materials: characteristic room sizes, height of building andsize of openings in walls, as constrained by traditional ‘local vernacular’ materialsand technology, related to the scale of the human figure.(From Morris, E A J. History of Urban Form : Before the industrial revolutions. Long-man, Scientific & Technical, Third edition, 1994.)

have most often been inefficient toimplement, because functions have to becarefully split between the nodes, and theinteraction between the nodes is fre-quently command-based. The three-tier-architecture provides a principal split bet-ween external presentation, applicationand internal storage of data. However, ithas the same difficulties with providingefficient development as with balancedclient-server architectures. The reason forthe difficulty may be that they do notdistinguish between specification andimplementation. This is accomplished bythe three-schema architecture [15]; whilethe specifications are split into externalschemata, application schema, and in-ternal schemata, the execution archi-tectures can be generated in various waysautomatically. Unfortunately, not manydevelopers and tool vendors know thethree-schema architecture. The three-schema architecture realises that softwarecan be nested [16], becoming moreabstract than housebuilding. Both usageand development/compilation dimen-sions of software can be realised by simi-lar or identical transformations, and thisway, the software can be put in series andparallel [17], as well.

The subject software architecture is in[18] split into four categories: (i) archi-tectural description languages, (ii) codifi-cation of architectural expertise, (iii)frameworks for specific domains, and(iv) formal underpinnings for archi-tecture. The book uses the specificationlanguage Z, based on predicate calculus,for the first category. As exemplified inthe Urd method – see next paper – thedifficulty is not only what languageshould be used, but what notions shouldbe described in an architecture. The bookdescribes the following architecturalstyles of the second category: pipes andfilters, data abstraction and object-ori-ented organisation, event-based andimplicit invocation, layered systems,interpreters, process control, distributedprocesses, subroutine organisation, statetransitions, reference architectures forspecific domains, and heterogeneousarchitectures. Within the second cate-gory, the book provides a design spacefor user-interface architectures. Otherpapers of this issue of Telektronikk pro-vide contributions to the third category,on the data-oriented, distributed and tele-com sub-domains. The fourth categoryprovides means to reason on architec-tures.

Frameworks

I believe building architects can special-ise in different kinds of buildings, andthey can have menus for what kinds offeatures have to be provided for thesebuildings. These menus are not prototypedesigns of the buildings, but they areframeworks for various designs.

While a software architecture prescribesthe structure of the final systems, aframework prescribes the structure of thespecifications of these systems, functionsand data. We use the term managementframework when this structure aims atdescribing and controlling the whole cor-poration and not just the structure of theexisting and planned software systems,functions and data. The managementframework aims at providing the ISarchitects with control of their totalenvironment.

For software systems there are frame-works, reference models, architectures orprototype designs which apply to specificapplication areas, like user-interface soft-ware or database applications. Also, thereare frameworks for distributed databases,distributed processing, long transactions,telecommunication services, telecommu-nication management, telecommunica-tion networks, and object orientation. Forsome areas there are competing frame-works, and some are overlapping. Someareas are specific, and some are believedto be very generic.

Open Distributed Processing, ODP, [19]provides a framework for specifying andimplementing communicating systems.However, the overall architecture of thefinal system is provided in the computa-tional viewpoint of the ODP specifica-tions. Hence, ODP is called a frameworkand not an architecture; however, theframework can be considered to be ameta-architecture of the final systems,functions and data. The three-schemaarchitecture applies the same three layersboth in the architecture and in its meta-architecture. ODP does not contain anylayer or viewpoint similar to the externallayer of the three-schema architecture,nor does the pure three-schema archi-tecture contain any layer for partitioningand communication. Hence, the twoarchitectures/frameworks overlap, butdo not completely cover each other.

Some frameworks can be used in severaldifferent ways. The ODP referencemodel can be understood as follows: the

enterprise viewpoint contains all businesspolicies as well as requirements on thesystems of the studied applicationdomain; the information viewpoint con-tains all data definitions, their behaviour– and grouping into systems, screens andreports; the computational viewpointcontains the vertical partitions of thesedefinitions; the engineering viewpointcontains the horizontal configuration ofthe systems; while the technology view-point contains the implementationdesigns. Each viewpoint is a completespecification of the entire applicationdomain from one perspective; only thetechnology viewpoint is needed to imple-ment the systems.

[20] provides a different interpretation ofuse of the ODP reference model: theenterprise viewpoint contains an identifi-cation of functions or tasks to be supp-orted by the systems; the informationviewpoint contains data definitions andconstraints on the behaviour, but notfunctional derivations; while the com-putational viewpoint contains the pro-cessing prescriptions and interfaces be-tween processes; the engineering view-point defines the functions needed tosupport distribution; while the tech-nology viewpoint identifies the tech-nology needed to implement the systems.Here all viewpoints are needed to pro-vide a complete specification, and refe-rences are made between viewpoints toprovide completeness.

The two interpretations of the ODP refe-rence model may produce totally diffe-rent specifications and implementations.

James Martin provides a managementframework in his book [10] together withprescriptions for development processesand methods. The Telenor BusinessInformation Architecture, BIA, [11] andthe BT Tile Architecture [12] primarilyprovide management frameworks forbusiness processes, tasks, data defini-tions, functions and systems, and notelaborate methods. In particular, BIA hasa strong focus on business goals. On theother hand, the Urd method takes busi-ness plans and overall organisation ofthe corporation for granted, and analysessoftware systems and their organisationonly. Urd provides no managementframework.

Frameworks can be specified as view-points, roles, function blocks, dataschemata, data flow, control flow, prece-dence relationships, predicates, objects or


other. Even if some initial comparisonsof frameworks – and architectures – areprovided in this issue of Telektronikk, wehave rather shallow knowledge of how tospecify frameworks, what are the(hidden) implications of use of differentspecification techniques, what scope ofvalidity is provided by each framework,which benefits and drawbacks do theyprovide, and how are the frameworkscompared and evaluated. These questionsmay not only be of academic interest, butcan have huge practical implications onhow planning and development work ispursued – and on the final designs.

Methods

A method should define the goal for apiece of work, and a way of undertakingthe work to achieve the goal. Both focuson the goal and conscious control that thework leads to the goal are important toproduce effective results.

In the mid-1970s, I participated in usingthe ISAC [21] method to analyse a largeportion of the information handling inTelenor. We made decompositions on upto seventeen levels, some nodes in somegraphs were trivial, others were verycomplex, without us knowing this. We,as analysts, felt that we lost control of theabstract decomposition, and we had justvague ideas about how to use the analysisresults in the subsequent design. Muchwork on large systems is like this, youcan feel lost, and then some magic hap-pens – provided by a key designer, whotakes responsibility and provides what isneeded irrespective of the theory predi-cated.

A specification of automatic informationsystems is comparable to a scientifictheory in the way it corresponds topeople outside the automatic system,how it describes the managed applicationarea, and how it prescribes the structureand behaviour of the automatic informa-tion system itself. See a separate paperon these three dimensions in this issue ofTelektronikk. A method for developingand validating the specifications of auto-matic information systems is comparableto a philosophy of science, and muchcould be learned, but is not yet done, bycomparing these.

The ISAC method [21] is primarily amethod for the development of individualsystems, but addresses some aspects ofsystems planning, as well. The Urd

method provides an approach to systemsplanning only, and no approach to ana-lysis and design of individual systems.

An approach to systems planning anddevelopment can be evolutionary orrevolutionary. The analysts have to con-sider carefully what is the most appro-priate time perspective and approach.The choice will depend on the situation:market needs, user requests, reorganisa-tion of work, change of technology,change of communication interfaces toother systems, and change of data defi-nitions and entities of the applicationdomain. The Urd method provides both acorrective and an idealistic design phase.Even if evolutionary design is not thepurpose of this approach, it provides‘evolutionary’ intermediate results on theroad to developing a revolutionary newdesign for the application area.

Process organisation

The approach to design a house isdependent on what tools and prefabri-cated elements are available. So alsofor information systems.

A method is a way of thinking, while aprocess prescribes how work may beorganised into separate activities, i.e.phases, steps or other, to achieve thegoal. Activities should provide somevisible useful results to somebody, andshould be delimited by some reportingand decision. The process structure isinfluenced by the method used, but stepsin the method may not be identical tosteps in the process, e.g. you may do sur-veying, analysis and some design in oneand the same step of the process. [22]provides an overview of state-of-the-artof process definition (research).

The Urd method primarily prescribesorganisation of activities, i.e. processorganisation, but contains method state-ments, as well. The Urd subject analysisphase contains both analysis of data anddesign of subjects in one and the samephase.

Engineering

Building construction involves a lot ofengineering and handicraft professionsin areas like insulation, dampproofing,electricity supply, water supply, car-pentry, plumbing, light planning, heat-ing, locksmithing, painting, colour plan-ning, interior planning, decoration, etc.

Larger buildings require many more pro-fessions, like statics, material sciences,fire planning, ventilation, automation,accommodation, car parking, industrialarchitecture, hotel architecture, super-market architecture, etc.

Most contributions from software peopleare really on engineering issues and noton the more high level architectureissues. Therefore, implementation andarchitecture issues are frequently con-fused. The implementation issues cancomprise choice of communicationprotocols, database management tools,repositories, screen definition languages,programming language (styles), etc.

Portfolio planning andglobalisation

In times gone by, building elements weretypically hand-crafted on location.Today, new building elements are typi-cally produced in specialised factories,collected into modules by module pro-ducers, and installed by a professionalteam in accordance with a standardarchitecture.

Software vendors will typically sell theirsoftware to many organisations. The ISdepartment will typically want to reusetheir objects, modules, systems and infra-structure within several user organisationunits. The reuse can be cost-effective forvendors and customers alike. However,there are a lot of concerns to be made:The software should fit into an existingorganisation, business, culture and langu-age, and it should co-operate with exist-ing objects, modules and systems, whichmost often are different for differentorganisations. How to identify areas forreuse, how to define elements suited toreuse, how to provide infrastructures forreuse, and how to incorporate reuse con-siderations into methods and tools areimportant questions. Use of one (kind of)system to support several business unitsis not and should not be the normalanswer to these questions. Portfolioplanning is an important topic, concernedwith the product planning, co-ordinationand marketing from the developmentorganisation. Portfolio planning shouldnot be confused with systems planning ofthe customer organisations, e.g. in thebusiness units of the corporation. How-ever, it is the co-ordination of portfolioand systems plans that can provide thebenefits to the corporation.


way that the particularities are not re-vealed, and they provide no means ofcomparison, generalisation and adjust-ment. No surprise, this lack of con-structiveness is called ‘logical’.

In the Urd method great care is taken tosurvey and analyse the concrete aspectsof the organisation, its routines, data andsystems, without going into a too deeplevel of detail. Also, a concrete systemsplan, with reference points between sys-tems, is provided as the end result. Data(relationships), with their subordinatebehaviour (called methods in objectoriented languages), are grouped intosystems.

The approach and perspective taken inthe Urd method are distinctively differentfrom that of approaches which identifyfunctions of the application domain [10][11] [12] [21]. Frequently the functionoriented approaches do not distinguishbetween manual and automated tasks,and they do not provide rules for whatshould be considered one or two func-tions – in sequence, or in parallel. Thefinal outcome of using the approach maybe a set of functions and groups of data.These functions and groups may in nodirect way relate to systems and theirinterconnections. Hence, separatemappings from these notions to designnotions are needed. As mentioned, theresults of applying the Urd approach andsome other approaches can be very diffe-rent. This proves that the analysts mustbe conscious about what perspective andwhich approach to choose for their sys-tems planning.

The Urd method may be appropriate forco-ordinated design of a family of sys-tems. However, Urd is inappropriate fordesign of communication solutions be-tween more independent organisationsand systems. For this purpose, a brokerkind of solution will be more appropriate.This issue of Telektronikk provides twopapers on this topic, but provides nomethod for planning and co-ordinatingsuch exchange of information. The ana-lysis method needed may be dependenton the solution envisaged.

Change and use

It is being claimed that the most perma-nent entity in Oslo is the continuing con-struction work. That the constructionwork is everlasting may be true. How-ever, while each construction project

lasts typically for some months, each housemay last for tens or hundreds of years.

Large automated information systemsmay have a typical lifetime of twentyyears. There is no indication that thistypical lifetime has changed significantlyover the history of computing or that itwill change in the near future. However,the time periods between new versionsmay change depending on software en-vironments, tools, developer organisa-tion, and end user organisation wish andcapability to adopt the new versions.

There has been a lot of talking, thinkingand implementation of modularisation ofhouses. However, the effects at large arehard to spot. It is typically small entitieslike doors, windows, mirrors, toilets,wallpaper, etc. which are reused, andtheir effects are enormous.

Notions like modularisation, reuse,object-orientation, etc. have been verypopular in programming. Certainly, a‘divide and conquer’ strategy has beenneeded to implement any large system,including use of software developed byothers. Reuse of application independentsoftware, and of application dependentdata types, is certainly used. However,the frequency and benefits of real reuseof application dependent code is un-certain, and it is more uncertain what‘preparation for unpredictable change’can mean. What does reuse mean? Cancentralisation of code do much the sameas inheritance? Can copying of code domuch the same? Is reuse within and be-tween applications not so much of inte-rest? Will the real benefits come fromstandardisation of data types and objectsfor entire application areas, and down-loading and configuration of these moreor less ready-made applications?

Some schools [24] advocate adoption ofgeneric software, which is specialised bythe users themselves. Web-sites anddrawing packages are examples of this.Web-sites can become large for a largeuser group, and hence, personalisedtailoring should be discouraged. Drawingapplications may be prepared for smalleruser groups, and invites tailoring.

A person may design and build a smallcottage without an architect, and he maydecorate and adapt the room to hisusage. However, when it comes to largerand maybe more long-lasting construc-tions, architects and engineers areneeded.


The enterprise is not the only possiblescope of portfolio and systems planning.The aim of component technology is toprovide software components that can bereused in various environments. Theentire globe can be the marketplace [23].Effective use of component softwareraises a set of fundamental questions:Will a designer first have to write a de-tailed specification before he can searchfor a component, which he can use? Ifthe implementation is generated auto-matically from the specification, what isthen the benefit? How should a compo-nent be prepared for specialisation andextensions? How will a componentdepend on other components and theirenvironment, and how will the designerlearn about this, and be guided in hisdesigns? Will the designer operate as alibrarian, rather than as a creative de-signer? Will there be reuse of compo-nents within certain schools or applica-tion areas, in which the designers getspecialised training, and not much acrossthese schools? The standardisation of thetelecommunication management frame-work, TMN, within the InternationalTelecommunication Union, ITU, maydefine such a school. Future TMN soft-ware may be based on downloadingTMN object definitions from the ITU web.

Design implications

Systems planning may have as good ordevastating impact as city planning, andthe implications of alternative designsare at least as poorly understood.

Information systems planners need tochoose design perspective and serve theinterests of different stakeholders just asconsciously as any city planner. How-ever, you may know a good city planwhen you see it, but it is hard to tell whatcharacteristics make a good city plan.Computer systems planners need toacquire knowledge of what is a good sys-tems plan. The Urd method aims at iden-tifying systems in which consistency ofdata has to be enforced, and which servethe manual organisation in the best way.

Some approaches to systems planning[11] claim to ‘provide the glue to bringtogether any fragmented organisation’.However, this may neither be an appro-priate goal, nor may the approach pro-vide techniques to analyse similaritiesand dissimilarities between organisationunits. Frequently, they do the opposite,they decompose tasks and data in such a

We believe that the situation is similarfor information systems. Systems plan-ning and system development for largesystems are separate professions re-quiring a large set of surveying, analysisand design techniques in addition toknowledge about technology, organisa-tion and specific application areas. Newtechnology, like webs and other genericsoftware, may change the borderlinesbetween what requires high expertise andwhat can be handled by more novicedevelopers or the end users themselves,but the need for the information systemsarchitects and engineers remains.

A particular problem for large organisa-tions is the cascading of changes.Changes may cascade within one systemdue to a poor structure of the system.More challenging is the cascading ofchanges between systems. Here, detailedrepositories are needed to trace effects ofchanges via several systems. Changemanagement systems are needed to co-ordinate the changes, and responsibilitiesand costs of changes have to be shared.

Maintenance

Every owner of a house knows the costsof maintenance.

So does the owner of an information sys-tem. The speculations on reuse havefrequently been motivated by hopes orintentions to reduce maintenance costs.However, there are reports [25] tellingthat adaptive maintenance can reduce themaintainability of the program code.Therefore, after some time, replacement

of a family of systems can provide bene-fits which cannot be obtained by adaptivemaintenance. Finally, replacement ofsystems can be cheaper than the initialdevelopment of these systems. This is anadditional reason for pursuing long rangestrategic and idealistic planning of infor-mation systems, and not just short tomedium term adaptive maintenance. Theplanner should note, however, that thenew systems should not just replace theold ones, but provide new features andutilise opportunities not addressed by theold systems.

Aesthetics

Building architecture is not only con-cerned with functionality, but is con-cerned with aesthetic values, as well.Figure 4 provides some example buildingdesigns which are believed to be nice.

The aesthetic aspects of information sys-tems architecture are in particular poorlyunderstood. Should aesthetic aspects of asystems plan or a system design have anysignificance? What does it mean? Does itmean simplicity, understandability, sym-metry, richness, or whatever? If object-orientation is considered good, is then thearchitecture good as long as it usesobject-orientation? Is it our beliefs aboutthe values that matter, or are there somemore fundamental properties of the archi-tecture itself that makes it nice or good?These are some of the practical andphilosophical questions which should beaddressed concerning the aestheticaspects of information systems.

References

1 Bansler J. Systems Development inScandinavia : Three theoreticalschools. Scandinavian Journal ofInformation Systems, 1, August 1989.

2 Hammer M, Champy, J. Reengineer-ing the corporation : a manifesto forbusiness revolution. London, Nicho-las Brearly, 1993.

3 Ehn, P. The Art and Science ofDesigning Computer Artifacts.Scandinavian Journal of InformationSystems, 1, August 1989.

4 Dahlbom, B, Mathiassen L. Compu-ters in Context : The Philosophy andPractice of Systems Design. Cam-bridge, Blackwell, 1993.

5 Bødker, S. A Human Activity App-roach to User Interfaces. Human-Computer Interactions, 4 (4), 1989.

6 Bakhurst, D. Consciousness andRevolution in Soviet Philosophy :From the Bolsheviks to Evald Ilyen-kov. Cambridge, Cambridge Univer-sity Press, 1991. ISBN 0-521-40710-9.

7 Veryard, R. Information coordina-tion : the management of informationmodels, systems and organizations.Englewood Cliffs, NJ, Prentice Hall,1994. ISBN 0-130099243-7.

8 Lederer, A L, Salmela, H. Toward atheory of strategic information sys-tems planning. Journal of StrategicInformation systems, 5 (3), 1996.

9 Gottschalk, P. A Review of Litera-ture on Implementation of StrategicInformation Systems. Norsk Informa-tikk-Konferanse, NIK. Trondheim,Tapir, 1996. ISBN 82-519-1381-0.

10 Martin J, Leben J. Strategic Informa-tion Planning Methodologies. Engle-wood Cliffs, NJ, Prentice Hall, 1989.ISBN 0-89435-358-6.

11 Telenor IT. Business InformationArchitecture. Oslo, unpublished.

12 Furley, N. The BT Operational Supp-ort Systems Architecture. BT Tech-nology Journal, 15 (1), 1997.


Boje Lundgaard and Lene Tranbjerg:Housing units at Blangstedgård, 1988

Heinrich Tessenow: Town house project,1911

Figure 4 From Nygaard, E. Arkitektur i en forvirret tid : Internasjonale strømninger1968–94. København, Christian Ejler, 1995.

13 Modelware International. Introduc-tion to the IFW A/B Level DataModel. 1998.

14 Katz, H (ed). Telecommunications :restructuring work and employmentrelations worldwide. Itacha, ILPPress, 1997.

15 Griethuysen, J J van (ed). Conceptsand Terminology of the ConceptualSchema and the Information Base.Geneva, ISO, 1982. (ISO TC97/SC5N692.)

16 ITU-T. Data-Oriented Human-Com-puter Interface Specification Tech-nique : scope, approach and refe-rence model. Geneva, ITU, 1993.(ITU-T Recommendation Z.352.)

17 Meisingset, A. A Data Flow App-roach to Interoperability. Telektro-nikk, 89 (2/3), 52–59, 1993.

18 Shaw, M, Garlan, D. Software Archi-tecture. Englewood Cliffs, NJ, Pren-tice Hall, 1996. ISBN 0-13-182957-2.

19 ITU-T. Reference Model of OpenDistributed Processing. Draft.Geneva, ITU, 1995. (Recommenda-tion X.901.)

20 ITU-T. Application of the RM-ODPframework. Geneva, ITU, 1996.(ITU-T Recommendation G.851.1.)

21 Langefors, B. Theoretical Analysis ofInformation Systems. Oslo, Universi-tetsforlaget, 1966.

22 Conradi, R, Chunnian, L. RevisedPMLs and PSEEs for Industrial SPI :Object-Oriented Technology. In:Object-oriented technology :ECOOP/97 workshop reader, Jyvas-kylä. J Bosch, S Mitchell (eds.).(Lecture Notes in Computer Science;1357.) Berlin, Springer, 1997.

23 Murer, T. The Challenge of theGlobal Software Process : Object-Oriented Technology. In: Object-oriented technology : ECOOP/97workshop reader, Jyvaskylä. J Bosch,S Mitchell (eds.). (Lecture Notes inComputer Science; 1357.) Berlin,Springer, 1997.

24 Mørch, A. Evolving a Generic Appli-cation into a Domain-oriented DesignEnvironment. Scandinavian Journalof Information Systems, 8 (2).

25 Kaasbøl, J J. How evolution of in-formation systems may fail : manyimprovements adding up to negativeeffects. European Journal of Infor-mation Systems, 6 (3), 1997.


Arve Meisingset is Senior Research Scientist atTelenor R&D. He is currently working on informa-tion systems planning, formal aspects of human-computer interfaces and middleware standard-isation. He is ITU-T SG10 Vice Chairman and theTelenor ITU-T technical co-ordinator.

e-mail:[email protected]

This paper summarises a method forthe identification and delimitation ofcomputer systems within one businessunit. The method defines what systemsshould exist within an applicationarea, defines the subject contents ofthese systems and the boundariesbetween the systems. A more detailedexposition of the method is found in [1].

1 Systems planning

Systems planning comprises specifica-tion and initiation of development of afamily of systems, while system develop-ment comprises specification and de-velopment of individual systems only.

Our approach to systems planning isabstract in the sense that it identifies sub-jects (being aggregates of data classes),activities and systems at a high level,without addressing the detailed design ofdata, functions and use of the individualsystems.

Our systems planning approach com-prises the identification of:

• systems

• subject contents of systems

• reference points between systems

• applications of systems

• co-operation between applications

• manual activities

• routines and data flow betweenactivities and systems

• opportunities, costs and impact

• priorities.

Our approach is constrained by premisesgiven by:

• business planning; choice of businessareas, markets and market strategies

• high level organisation; future splitinto business units and degree of co-ordination.

Systems planning addresses the use ofcomputer systems, and does not address

• IT architecture; principles, technicalsolutions and organisation of ITsupport

• role of development projects; identifi-cation and prioritisation

• role of maintenance work; identifica-tion and prioritisation.

Our approach has a main stream, de-picted in Figure 1.1, but feedback loopsmust be observed. As an example, oppor-tunities and constraints of the computersystems may provide ideas for change ofthe business plan and of the high levelorganisation.

Our systems planning method is de-veloped to facilitate internal systemsplanning

• in one business unit

• for business units which already haveseveral computer systems

• for strongly data oriented applications.

The method does not address

• co-ordination between loosely coupledbusiness units

• systems planning for new businessunits/functions

• highly mathematical or processoriented applications.

Our systems planning method is con-strained by the use of decentralisation asa political means of splitting the enter-prise into several business units, but

allows centralisation of systems and acti-vities as a means to improve efficiencywithin a business unit. However, systemscan be partitioned into (co-operating)applications as a means of decentralisa-tion within that business unit.

The method takes

• existing systems• existing organisation of work • problems and opportunities

as its starting points.

The method delivers applicable inter-mediate results by

• identification of problems and oppor-tunities

• overlap between existing systems

• a corrective systems plan

• an idealistic systems plan.

We believe systems planning should takesurveying of existing knowledge of sys-tems, applications and activities as thestarting point. Our analysis methodfocuses on the identification of subjectswhich in principle can form a data baseeach.

Our idealistic design method groups sub-jects into systems to support the mostefficient design of activities and routines.

12

The Urd Systems Planning MethodA R V E M E I S I N G S E T

Telektronikk 1.1998

Businessplanning

High levelorganisation

Systems planning

IT architecture

Systemdevelop-

ment

Func-tionality

Mainte-nance

Func-tionality

Systemsplanningtakes this asa premise

Systemsplanningdoes notcomprisethis

Figure 1.1 The main planning stream

Problems andopportunities

Surveying

Analysis

Corrective design

Idealistic design

Overlap

Correctivesystems plan

Idealisticsystems plan

Figure 1.2 Phases in systems planning


1 System

A system is a computer system whichcan enforce the integrity of its owndata. A system is in the systems plan-ning defined to be a collection of datatypes (aggregated into subjects); there-fore, we do not consider properties ofthe system related to external userfunctionality or internal storage andaccessing of data.

2 Application

An application is an instantiation of (avertical partition of) a system togetherwith a (horizontal and/or vertical parti-tion of) a set of data instances. Applica-tions can be independent, looselycoupled or integrated, i.e. stronglycoupled within the scope of the system.

3 Subject

A subject is an aggregation of datatypes which in principle can make upan autonomous system. A subject isdefined to contain a set of referencesbetween object classes, with asso-ciated object classes and namebindings.

4 Reference point

A reference point indicates communi-cation needs/redundancy between sub-jects or systems. An object class whichbelongs to several subjects or systemsis called a reference point. A referencepoint can be n-ary.

5 Name binding

A name binding prescribes that in-stances of the subordinate object classare identified locally to an instance oftheir superior object class by theirrelative distinguished name. Namebindings used in the systems planningcan form trees of object classes only,never networks.

6 Reference

A reference is a pointer attribute fromone object class to one other objectclass. Pointers can be one-way or two-way, i.e. two mutually dependent one-way pointers. All references are binary.

7 Object class

An object class can contain attributes(single- or multi-valued) and references

and can be associated to other objectclasses by name bindings.

8 Interface

The communication paths betweenapplications are called interfaces. Inter-faces can exist between applicationswithin one system or of different sys-tems. Interfaces are binary. There canbe several interfaces for each refe-rence point, and vice versa. Interfacescan be one-way or two-way.

9 Activity

An activity is a task which is carried outwithin one organisation unit (at thelowest formal level of the organisationhierarchy) without awaiting communi-cation from other organisation units.The activities of the systems planningare really activity types.

10 System activation

A system activation is the use of a sys-tem by an activity (or other system acti-vation) which provides results to thesame or other activities (or system acti-vations). The system activations in thesystems planning are really systemactivation types.

11 Data flow

A communication path between activi-ties and/or system activations is calleda data flow. Data flows can be one-wayor two-way. Data flows can conveycontrol and is then called control flow.Data flows in the systems planning arereally data flow types. While referencepoints can be n-ary, data flows arebinary only.

12 Routine

A routine is a set of data flows betweenactivities and system activations whichfollows one input data flow to the busi-ness unit. Routines are in the systemsplanning considered not to containloops even if they may be visiting thesame organisation unit several times.Note that routine graphs depict dataflows between activities and systemactivations, while data flow graphsdepict data flow between organisationunits and systems. Routines in the sys-tems planning are really routine types.

Box 1 – TerminologyThe analysis work in all phases is a top-down decomposition of relations anddependencies. This knowledge is used ina bottom-up design.

The method is not abstract in the sense ofbeing independent of organisation, rou-tines and data design. Our method relatesto concrete organisations, routines anddata designs.

We do not believe in

• the existence of a universal method forall systems planning

• an all-comprehensive planning of allsystems of an enterprise

• simultaneous application of a phase/step to all systems.

We believe planners should choose tech-niques and application areas according tospecific needs:

• the planning method should be ad-justed to the specific problems of theapplication area

• the planning should focus on the sys-tems and applications considered to beof greatest importance

• use of phases/steps to different appli-cation areas need not be synchronised.

Systems plans frequently end up as‘paper results’ without sufficient focusand determination on implementation.Therefore, the systems plan should beanchored by the customer, who must beengaged in prioritisation and start-up ofimplementation projects.

Compared to alternative approaches, ourmethod provides

• less detailed analysis than [2]

• more detailed analysis than [3]

• top-down surveying followed bybottom-up design, as opposed to top-down-only approaches, like [3]

• identification and delimitation of sys-tems, as opposed to identification offunctionality only, like [3], [4].

We do not think that a cook book forsystems planning can provide a uniqueguide to obtaining a good plan. In orderto obtain successful results, a good cookis needed as well, and the planners haveto choose elements from the cook bookwhich are relevant to the needs of theirapplication domain. Choice of the app-ropriate level of detail for the planning is

difficult, because enough information iswanted to make informed decisions,while we want to leave the detaileddesign to the following implementationprojects. The cook book identifies ele-ments which should be surveyed andanalysed in order to make rational designchoices.

Several terms are assigned a specialmeaning in our method. See Box 1 –Terminology.

2 Surveying

The objective of the surveying phase is toidentify problems and opportunities withexisting systems and activities.

Figure 2.1 shows the steps in the survey-ing phase.

2.1 Delimitation

The scope of the study is decided to-gether with the IT co-ordinator of thebusiness unit to be studied. This stepshould provide

• identification of a list of interrelatedsystems to be studied

• identification of the owner organisa-tion unit of each individual system.

2.2 System survey

This survey should be carried out foreach system identified in the previousstep. The survey can be accomplished byquestionnaires to the owner organisationunits. The questions comprise

• problems with existing systems andtheir use

• opportunities within the total applica-tion domain

• data flow between systems

• problems related to data flow

• impact of technology, organisation ormarket change

• user organisation units (at the lowestformal level) of the system

• identification of persons to be inter-viewed in each user organisation unit.

2.3 User survey

The user survey should be undertaken ineach user organisation unit identified inthe previous step. The survey is accom-plished by interviews with the expertsidentified.

The user survey comprises:

• areas of responsibility of the userorganisation unit

• all systems used within the entire userorganisation unit

• problems related to use of each indi-vidual system

• opportunities related to these systems

• candidate manual activities to be auto-mated

• data flow between this user organisa-tion unit and other units

• data flow between systems; if thisinformation is easily obtained

• problems related to data flow

• critical success factors in each organi-sation unit

• impact of technology, organisation andmarket change

• identification of real users of datamanaged by the systems identified inthe delimitation step.

This step surveys the entire user organi-sation unit, and not only use of the sys-tems identified in the delimitation phase.

The purpose of this enlarged scope of thesurvey is to provide information on theusers’ total need for system support.

The purpose of making a distinction be-tween (system) users and data users isthat the system/terminal users are fre-quently not the real users of data. Thedata users can be customers, sales per-sonnel, technicians and managers who donot use the systems themselves.

2.4 Usage survey

This survey should be undertaken foreach (kind of) data user. The survey canbe accomplished by interviews of thedata users. This survey need only beundertaken if the system users cannotprovide satisfactory information of needfor data.

The usage survey comprises:

• tasks of the data user

• data needed for the tasks

• problems related to data use

• systems providing data to the differenttasks

• problems related to data delivery

• critical success factors for the data user

• impact of technology, organisation ormarket change.

2.5 Problem identification

This step summarises

• problems• opportunities

within the studied application domain.

This step can be organised into three sub-steps:


System survey

User survey

Usage survey

Problemidentification

Delimitation

Figure 2.1 Surveying

Problem domain Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Problem domain Yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

Figure 2.2 Report on project candidates

• extraction of problems and opportuni-ties from the questionnaire replies andinterview reports

• identification of project candidatesfrom the extracted information

• organisation of the project candidatesinto appropriate problem domains.

The results from this step should be com-piled into a report which is presented tothe customer (steering group and othersponsors of the project). The resultsshould also be validated through a hear-ing among system owners and interviewpersons. The customer makes decisionsconcerning immediate actions based onthe results.

3 Analysis

The objective of the analysis phase is toidentify a set of subjects which can beimplemented as autonomous databases.

The subject analysis starts with a correc-tion of the existing data structures.Therefore, the result of the analysisdepends on the design choices made, butprovides an abstraction over the datadesigns, as well. The subject analysis isindependent of the usage of data and theexternal design of systems. Therefore,the subject analysis is labelled dataoriented, not function oriented.

We recommend that the analysis iscarried out on a per system basis, due tothe size and complexity of each system.

This, however, leads to a need for har-monising subject graphs into a unifiedsubject graph at a later stage.

The subject analysis is split into foursteps, as shown in Figure 3.1.

3.1 Correction of data structure

The purpose of this step is to develop aharmonised and simplified data structureper system.

The step is carried out like a reengineer-ing per system, and the work is based onthe following information sources:

• database schema, as the primarysource, if available

• system documentation

• user documentation

• user interface.

The result is documented in GraphicGDMO, ITU-T draft Rec. Z.360 [5],using

• object classes• references• name bindings.

Z.360 is used due to its support of namebindings and references to expressdependencies between object classes.Value classes, attribute classes, structurerecords, etc. are removed from thegraphs. Inheritance is removed bycopying into the subclass.

3.2 Subject design

The purpose of this step is to design asubject graph for each data structuregraph (for every system) from the pre-vious step.

A subject graph comprises a set of sub-jects and reference points between thesesubjects. The subjects are disjunct aggre-gates of references between objectclasses. The references are aggregated insuch a way that constraints can be en-forced within a subject, and there is noneed for co-ordination across subjects.

A data structure graph for a subject com-prises

• references which are existentiallydependent on other references withinthe subject

• associated references, i.e. referencesrelated to an object class within thesubject and which otherwise wouldhave been isolated in a separate subjectfor this reference

• object classes which are related byreferences within the subject

• name bindings to the mentioned objectclasses together with all recursivelysuperior object classes and namebindings.

The same object classes and namebindings can belong to several subjects.

If each subject is implemented in a sepa-rate database, then global distinguishednames are needed to refer between thedatabases. Therefore, object classes (con-taining these names) are used as refe-rence points between subjects. If oneobject class is used to refer between morethan two subjects, then this object classrepresents an n-ary reference point.

Note that in subject design, referencesare aggregated into subjects, which eachin principle could form an autonomous


Subject design

Unified subjectgraph

Systems overlap

Correction ofdata structure

Figure 3.1 Analysis

Path

Object className binding

Course

Link

Station

Node

Two-way reference

Figure 3.2 Graphic GDMO

Course networkSubject

Link network

Binaryreference

point

Ternaryreference point

Node Course

Figure 3.3 Subject graph

database. Subject design is, therefore,distinguishable from clustering tech-niques of object classes in repositories.

3.3 Unified subject graph

The objective of this step is to collectand harmonise subject graphs from allsystems into one unified subject graphfor the entire systems family. The sys-tems planners must consider that

• different names may have beenassigned to similar subjects indifferent systems

• identical names may have beenassigned to different subjects indifferent systems

• the data structures of different systemsmay not be harmonised.

The unification of subject graphs willresult in

• a splitting and/or grouping of subjects

• renaming and/or redefinition of sub-jects

• creation, deletion and/or redefinition ofreference points.

3.4 Systems overlap

The objective of this step is to identifyoverlaps between systems.

The step can be divided into three substeps:

• make a list of all subjects of the uni-fied subject graph

• create a subject-system-matrix

• identify and summarise overlaps.

The results from the subject analysis arecollected in a report to the customer(steering group and other sponsors).The customer makes decisions based onthe report.

4 Corrective design

The aim of corrective design, Figure 4.1,is to harvest immediate results from thesurveying and subject analysis withouthaving to wait for a final idealistic design.

Corrective design takes the subject-system-matrix as its starting point.Corrective design requires acquisition ofknowledge from development and main-tenance personnel; typically an expert persystem is needed. If these experts cannottake active part in the corrective design,they have to be interviewed by systemsplanners.

4.1 Subject co-ordination

Subject co-ordination addresses thehandling of subjects across systemboundaries. This step aims at removingoverlaps between systems and to improvethe communication between systems.

The subject co-ordination can be dividedinto four substeps:

• co-ordination and consistency control

• discussion of vertical partitioning

• discussion of horizontal partitioning

• consider joining or partitioning of sub-jects.

Co-ordination and consistency controlshall

• ensure that subject and data definitionsare co-ordinated and correctly inter-preted across systems

• summarise and co-ordinate resultsacross systems.

The project workers will typicallyencounter the following obstaclesduring the analysis:

• different systems use different data andsubject definitions

• different systems use different or iden-tical labels of the same or differentdata and subjects.

The project may find it convenient toidentify a co-ordinator for each subject ora set of subjects across all systems.

Discussion of vertical overlap is under-taken for each subject which is spreadacross two or more systems. The sub-stepcomprises:

• identification of characteristics of theoverlap

• assign ownership to the subject to onesystem

• consider if the redundancy betweensystems should be removed

• consider if data should be moved fromone system to another

• reconsider the interfaces between sys-tems.

Discussion of horizontal overlap isundertaken for each subject which spanstwo or more systems. The sub-step com-prises consideration of


Path

Existentialdependency Course

LinkNode

Link network

Figure 3.4 Data structure graph persubject with indication of existential

dependencies

System S1 S2 S3 S4 S5

SubjectT1 x x xT2 x xT3 xT4 xT5 x x xT6 xT7 x xT8 x x xT9 x x

T10 x x x xT11 xT12 xT13 x

Figure 3.5 Subject-system-matrix

Systemsco-ordination

Actions

Subjectco-ordination

Figure 4.1 Corrective design

• whether the span of the subject acrossseveral systems is due to horizontalpartitioning of a data type

• co-ordination and communicationbetween systems.

The last substep, ‘consider joining orpartitioning of subjects’, reconsiders andsummarises joining or partitioning ofeach subject across all systems in whichit is contained.

4.2 Systems co-ordination

This step is carried out for each systemand can be divided into two sub-steps:

• consideration of partitioning each sys-tem into applications

• summarising the recommendations foreach system.

The project must consider if it is app-ropriate to carry out the first sub-step.A system can be horizontally partitionedinto

• several independent and non-over-lapping applications

• several autonomous, but communi-cating applications

• several dependent and partly over-lapping applications.

The second sub-step summarises

• proposals for redistribution of func-tionality between systems

• proposals for changes of each system

• implications for development, admi-nistration and use of the systems.

Proposals for move of functionality be-tween systems can be documented in a sys-tems co-ordination graph. See Figure 4.2.

4.3 Actions

The results from Corrective design arereported to the customer and othersponsors of the project. Decisionsconcerning implementation must bemade by the organisations responsiblefor each system.

5 Idealistic design

The purposes of idealistic systems plan-ning are

• to develop an idealistic systems plan,which will serve as a vision for sub-sequent development projects

• to develop an application plan for eachsystem

• to redesign activities and routines

• to develop cost and impact analyses.

The objective of the planning is to designthe most efficient manual and automaticprocessing of data. This is achieved bymoving activities as close to the cus-tomer as possible. Aggregation of sub-jects into systems is done in such a waythat the routines are not hampered by aneed to access several systems. Newrequirements are met by incorporatingnew data definitions and redesign ofactivities and routines.

5.1 Redesign of data andsubjects

This step comprises:

• definition of data for new needs

• redesign and harmonisation of data ofexisting systems.

New data definitions are considered tobelong to one or more hypothetical sys-tems. This step is carried out like aniteration of the three first steps of theanalysis phase. The result of the work isdocumented in a unified subject graphfor the (new and old) data definitions.

5.2 Identification of routines

A routine comprises all data flow whichresults from one data flow input to abusiness unit until data leave this busi-ness unit.


System 1 System 2

System 3

Data exchange

Partto be

moved

System Subject

Figure 4.2 Systems co-ordination graphIdentificationof routines

Routine surveying

Unified subjectgraph

Subject design


Routine analysis

Redesign ofroutines

Unification ofroutines

Subject use

Subject grouping

System design

Design ofapplications

Evolutionplanning

Evaluation

Final report

Planning,evaluationandreporting

Design

Subjectuse andgrouping

Surveying,analysisand designof routines

Redesignof data andsubjects

Figure 5.1 Idealistic design

A data flow graph, from the informationcollected during the Surveying phase, isdeveloped – as an intermediate result –for

• all systems

• all user organisation units

• all data flow between these systemsand units.

The final results from this step are

• identification of all inputs to the busi-ness unit

• prioritisation of which routines to beanalysed in which sequence.

5.3 Routine surveying

Each routine is surveyed by interviewingexpert users and by acquisition of routinedescriptions. Note that there are fre-quently discrepancies between routinedescriptions and the actual routine.

The routines are documented in enume-rated notes. Note that a routine can visitan organisation unit several times.

The level of detail of the routine survey-ing has to be considered in each indi-vidual case; however, the surveying hasto distinguish organisation units at thelowest formal level.

The results from the surveying can bedocumented in informal routine graphs.

5.4 Routine analysis

In this step a routine graph is developedfor each routine. See Figure 5.3. Allwork carried out in one organisation unit

without intermediate communicationwith other units is defined to be one acti-vity.

The routine graphs depict activities, sys-tem activations (including use of manualfiles), and data and control flows be-tween these. Furthermore, vertical linesbetween activities indicate that they areundertaken in the same organisation unitand vertical lines between system activa-tions indicate that they are of the samesystem.

5.5 Redesign of routines

The purpose of this step is to design themost efficient allocation of work to orga-nisation units and sequencing of work foreach routine. This objective can typicallybe met by moving work as close to theinitiation of the routine as possible. Notethat reallocation of work frequently willimply change of access to systems.

The redesign is documented in routinegraphs of the same kind as used in theroutine analysis. Note that vertical linesindicate alternative work flow in case theintermediate communication (possiblyvia systems) to other organisation units isnot needed.

5.6 Unification of routines

This step studies

• harmonisation of routines• linking of routines

with the corresponding updating of rou-tine graphs. Centralisation and decentral-isation are essential questions of thisstep.

The resulting graphs are called unifiedroutine graphs.

5.7 Subject use

In this step every subject is listed foreach data flow between activities andsystem activation in each unified routinegraph. The subjects, which are depictedin the unified routine graphs, refer to theunified subject graph.

The resulting graphs are called routine-subject-graphs. A collection of subjectscan be referred to as a subject set.

5.8 Subject grouping

The purpose of this step is to identifysubject groups which can serve as sys-tems. The group of subjects used by oneactivity forms the starting point for thegrouping. This way, work is not ham-pered by one activity having to accessseveral systems.

Sometimes the tasks contained in an acti-vity are so loosely coupled or subjectsare so seldom accessed that the subjectscan be organised into several subject


Business unit

Systems

Data flow

Organisation units

Figure 5.2 Data flow graph withinitiation of two routines

System activations

Data flow

Activities

Control flow

Figure 5.3 Routine graph

System activations

Subject

Activities

Subject set

Figure 5.4 Routine-subject-graph

Subject group 1xxxxxxxxxxxxxxxx

Subject group 2xxxxxxxx

Subject group 3xxxxxxxx

Figure 5.5 Subject groups

groups or systems per activity. We wantto design disjunct subject groups or sys-tems. Since the needs of some activitiescan be in conflict, some subjects may besplit on several subject groups/systems orjoined into several subject groups/sys-tems. The resulting subject groups aredocumented in named lists and are de-coupled from the activities.

5.9 Systems design

This step produces the main result fromthe entire systems planning work.

Based on the results from the previousstep, this step proposes

• new, redesigned and existing systems• reference points between systems.

The results are documented by

• one systems graph, see Figure 5.6• a subject graph for each system.

5.10 Design of applications

This step will propose

• vertical and horizontal partitioning ofsystems into applications

• introduction of controlled redundancybetween applications of each system

• introduction of controlled redundancybetween systems

• interfaces and co-ordination mecha-nisms between applications

• interfaces and co-ordination mecha-nisms between systems.

The results are documented in

• an application graph for each system• a subject graph for each application.

The project will have to consider if thetasks of this step can be postponed to thesubsequent development projects.

5.13 Final report

The results from idealistic design arecollected into

• recommendations to the steering groupand other interested parties

• documentation to developers.

See contents of the systems plan in sec-tion 1, Systems planning.

The results should be validated by ITsupport, IT co-ordinator, system ownersand expert users before final decisions inthe steering group or higher level bodies.The decisions should be anchored by abinding IT strategy and concrete de-velopment initiatives by the customer.

References

1 Saxlund, G et al. The Urd SystemsPlanning Method. Kjeller, TelenorR&D, 1996. (Report N 52/96.)

2 Martin, J. Strategic InformationPlanning Methodologies. EnglewoodCliffs, NJ, Prentice Hall, 1989. (ISBN0-89435-358-6.)

3 Telenor IT. BIA : Business Informa-tion Architecture. http://info.telenor.no.

4 Furley, N. The BT Operational Sup-port Systems Architecture Frame-work. British TelecommunicationsEngineering, 15 (4), 1996.

5 ITU-T. Report of the meeting held inGeneva from 10 to 18 April 1996.Geneva, ITU, 1996. (COM 10-R 4-E.)


System 1 System 2

System 3 System 4

Figure 5.6 Systems graph with reference points

Appl. 1.1 Appl. 1.3

Appl. 1.2

System 1

Figure 5.7 Application graph with data flow

Arve Meisingset is Senior Research Scientist atTelenor R&D. He is currently working on informa-tion systems planning, formal aspects of human-computer interfaces and middleware standard-isation. He is ITU-T SG10 Vice Chairman and theTelenor ITU-T technical co-ordinator.


5.11 Evolution planning

This step will propose a migration pathfrom the current systems to implementa-tion of the proposed systems plan.

The project will have to choose betweena revolutionary or evolutionary migrationstrategy.

5.12 Evaluation

The objective of this step is to develop acost-benefit evaluation of the proposalsfrom the previous steps. This step shallproduce

• cost estimates

• economic and other benefits from theproposals

• implications for personnel and otherimplications.

Since the idealistic plan is long range andstrategic, the benefits can be long range,as well. Therefore, it may be difficult toundertake an economic analysis. In thiscase, it may be more appropriate to pro-vide strategic considerations on techno-logical, organisational, regulatory ormarket changes.


Box 2 – Method overview

Systemdevelopm.

Funct.atity

Main-tenance

Funct.atity

The methoddoes not

comprise this

Delimitation Problemidentification

Usagesurveying

Usersurveying

Systemssurveying

High levelorganisation

Businessplanning

Surveying

Analysis

ActionsSystems

co-ordinationS ubject

co-ordination

Corrective design

Unifiedsubject graph

Subjectdesign

Correctionof data

Idealistic design

Systemoverlap

Unifiedsubject graph

Subjectdesign


Unificationof routines

Redesignof routines

Routineanalysis

Routinesurveying

Final reportEvaluationEvolutionplanning

Subject use Subjectgrouping

System design Design ofapplications

Identificationof routines

Systems planning

IT architecturePlanning for a familyof systems

Functionality isdecided per system

Dotted boxescan be skipped

The methodpresupposes

this


Box 4 – Example Subject graph

Box 3 – Example Systems graph

Customersystem

Trafficsystem

Networksystem

Organizationsystem

Map systems

Service bus. units Network bus. units

Common

Optimisationsystems

Cablesystem

Stationsystem Fabonett

Sambands-nummer

Hendelse

Prosjekt

Dokument

InstansNett-

leverandør

Samband Mp.sb.

Adresse

Strekning

Ekstremtmedium

Sambands-avgr. Plan

Kurs

Gruppe

Transm.-system

Kopling

Utstyr

Mp.tr.sys. Radiolinje Mp.gruppe

Ordre

Stasjon Rad

Uts.enh

Funksjon

HylleStativ

BlokkUtstyr Sek.par

Sb.sys.pkt

Hendelse +Trab s.sys

Katalognr

+Gruppe

+Kurs

Samband

Linje

+Samband

+Mp.sb.

Sak

Dok Sak.inst.

Gruppe

Trans.sys

Uts.rel.

Kanal

Område

Ks.sek.

KOpl.pkt.

Kurs

Kurspar

Plan

Sent.omr

Ext.tr.med

Samb.ag.

Samb.sek.

Jur.pers.

+O.lj.nr.

Mp.samb

Anropsnr.

StrekningSb.bunt

+Sentral

+Sb.bunt

Hvk.

Knutepkt.


This paper addresses the granularityproblem of systems planning. Five sys-tems planning methods are presented,and their granularity levels are identi-fied according to a granularity levelhierarchy.

In the 1970s many organisations startedto computerise their data and processes.Now, twenty years later, they experienceinformation system chaos. Purchasing ofnew systems seldom takes the existingsystems into account, and while newcomputerised systems are added to thesystem portfolio, old systems are seldomremoved. To ensure that the computer-ised information systems fit together andsupport the business in the best waypossible, information systems planningshould be performed.

‘Strategic information systems planning’,or ‘systems planning’ for short, has beendefined as “the process of identifying aportfolio of computer-based applicationsthat will assist an organisation in exe-cuting its business plans and realising itsbusiness goals” [1]. Systems planning isa complex and critical task, and it is oftenunsuccessful, partly because the plan isnot followed [1].

The literature provides various systemsplanning methods, see for example [2],[3], [6] or [7]. Methods differ in scopeand granularity. Some methods, likeMartin [2], have the whole enterprise asits scope, while others, like the Urdmethod [3], have a business unit or a setof systems within the business unit as itsscope.

Regardless of scope, systems planning isa complex task. To get an understandingof a complex problem area, it can bebeneficial to decompose it into smallerparts that are easier to deal with. Thisapproach is called ‘top-down’. Whenevery problem part is understood, youmust put the parts together to get a newpicture, which provides a better design ora better understanding of the problemarea. This approach is called ‘bottom-up’.

The problem of decomposition is whento stop decomposing. How do we knowthat we have reached the necessary levelof detail? In the case of composition, thequestion is at which level of detail do westart? If we analyse too many details, wemay get lost, and never come up with asystems plan. If we analyse too few

details, we may not be able to address thereal problems. This is the heart of thegranularity problem. Because systemsplanning precedes system development,it should not require a detailed analysisof each new system. The detailed analy-sis should be left for the system develop-ment activity. However, for the systemsplanning results to be useful in sub-sequent system development projects, itmust be so detailed that the conclusionsbecome trustworthy. The granularityproblem of systems planning can there-fore be seen as how to compromise be-tween planning efforts and quality of theresulting systems plan. There may not beone general solution to this problem, and,as this paper shows, different systemsplanning methods provide differentanswers to the granularity problem.

In this paper we present five methods forsystems planning. To be able to comparethe granularity levels of various methods,we have identified nine general granula-rity levels, see Table 1. We havearranged the granularity levels in a hier-

archy, but are aware of the fact that thelevels do not always define a strict scale.Another difficulty with the comparison isthat even if two methods address thesame granularity level, one can do this inan abstract way, while the other does it ina concrete way. Nevertheless, we find thehierarchy helpful in visualising and com-paring the granularity levels of themethods. The reader should, however, becautious when using the diagrams.

ISAC

The ISAC method was widely used inScandinavia during the 1970s. It is in facta system development method, whichincorporates systems planning aspects aswell. It is presented in this paper, becauseit provides a comprehensive generalframework for analysing informationsystems.

ISAC was the name of a research groupat the Royal Technical High School andthe University of Stockholm, in the early

Decomposition and Granularity in Systems PlanningS I G R I D S T E I N H O L T B Y G D Å S

Granularity Granularity level entity class Typical numberlevel no. of entities

8 Enterprise 11)

7 Business Unit 5 – 100

6 Organisation Unit / System 50 – 10002)

5 Activity / Function 500 – 20003)

4 Subject 100 – 5004)

3 Entity / relationship 1000 – 2000

2 Attribute 5000 – 10,000

1 Process description 5000 – 10,000

0 Detailed implementation 5000 – 10,000

Table 1 Granularity level hierarchy

NOTES:

1) To come up with this hierarchy, we have considered an enterprise of largenational and medium international size, like Telenor. Please note that the granu-larity levels will not always constitute a strict hierarchy.

2) We assume that each system supports the activities of one business unit only.

3) We do no generalisation of functions and activities across business units orsystems.

4) A subject is a collection of relationships with corresponding peer entities. Sub-jects are (unlike functions) unified across systems, that means that they are onlycounted once even if they are used by several systems.


seventies. The group developed a methodfor information system developmentbased on the work of Børje Langefors.

The scope of the ISAC method is anorganisation or organisation unit. Thisrelates to the granularity levels 6 to 8 inTable 1. Within this scope it is the peoplerelated to the organisation (unit) and theproblems they experience in their workthat are important. ‘People’ includes thefollowing roles: user, manager, worker,customer and fonder.

The design philosophy is compositionalor bottom-up in the sense that it isassumed that the solutions to sub-problems within the organisation willgive the solutions to the organisation’sproblems as a whole [5]. During theanalysis, however, you will work top-down, decomposing functions and in-formation.

The ISAC method has an initial phase (I)called Change Analysis. The purpose ofthis phase is to identify if the organisa-tion needs an automated information sys-tem at all. In other words, ISAC does not,like most other methods, assume that thedevelopment of an information system isthe solution to an organisation’s prob-lems [5]. Another interesting differencefrom most methods is, as stated byAvison and Fitzgerald in [5], that:

“Need is established only if it is seenthat an information system benefitspeople in their work, so that purefinancial benefit to the organisation,or some other benefit, is not thought tobe an indication of need for an infor-mation system.”

The purpose of the second phase (II),activity studies, is to delimit the informa-tion system. To do this, activities thatwill be supported by the system are iden-tified and analysed. Information neededby the activities, and the informationflows between the activities are identi-fied.

The third phase (III) is called informationanalysis. In this phase the contents andtasks of the information system areanalysed. For each task, input and outputinformation sets are analysed. (An infor-mation set is a data flow or a data store.)The analysis consists among other thingsof precedence and component analysis ofeach information set. The analysis maylook quite similar to functional decompo-sition, but the reasoning process is diffe-

rent; ISAC’s precedence analysis identi-fies the input information necessary toproduce the information set studied.When the input information set is identi-fied, the output information set derivableform this input is identified. If the twooutput information sets are identical, theanalysis stops. To be able to reason aboutthe transformation between input andoutput information sets, the structure ofthe information sets must be known. Thisstructure is analysed in the componentanalysis. When precedence and com-ponent analysis are taken down to thelowest level of decomposition, the logicof the resulting processes (transforma-tions) is analysed. Descriptions of theinformation processes are then made. AProcess description is a detailed descrip-tion of the prerequisites, conditions, per-mitted states for conditions and requiredactions for the process.

In the ISAC method, an information sys-tem is not necessarily computerised. Inthe fourth phase (IV) of the method, it isdecided for each process, if it will beautomated or not. Related automated ormanual processes are grouped. A groupof automated processes defines a pro-gram. To perform data program design,Jackson Structured Programming (JSP) isrecommended. ISAC also recommendsthat the workers design their own manual

routines. The elementary information setsthat are a result of phase III, are aggre-gated into permanent or temporal datasets, based on their functional depen-dencies, and messages, files or databasesare designed.

In the method’s last phase (V), the equip-ment-independent system design fromphase four is adapted to fit the particularequipment chosen.

To summarise, the ISAC method add-resses systems planning aspects, andends with a detailed system development.Figure 1 illustrates the process. Bars illu-strate granularity levels, parentheses illu-strate alternatives (that is and/or alterna-tives), and arrows illustrate transitions.

Urd

In 1993 the Telenor Network businessunit asked Telenor R&D to develop anidealistic systems plan for the key infor-mation systems of the business unit. Theproject started out searching for a suit-able method in literature, but did not findone single method that fulfilled theneeds. Some methods, like Inmon’sInformation Paradigm [4] was consideredto be more suitable for financial thantelecommunication information systems.This was due to the fact that operational

I II III IV V

Phases

8

7

6

5

4

3

2

1

0

Gra

nila

rity

leve

ls

ISAC

Figure 1 Granularity levels in the different phases of the ISAC methodBars illustrate granularity levels, parentheses illustrate alternatives (that is and/or

alternatives), and arrows illustrate transitions.


data in telecommunication systems aremore complex to handle than Inmonsuggests, and therefore his categoriesprovide inappropriate splits of data. Asan example, several points of time mustbe handled to establish a circuit, and thisdata may not be split on several data-bases. Other methods, like Martin’sInformation Systems Planning [2], wasconsidered to be too detailed for thepurpose of this project. Inspired by litera-ture, the project developed its ownmethod, called the Urd method. Urd isdescribed in more detail elsewhere in thisissue of Telektronikk.

According to the Urd method, a systemsplan should give answers to the follow-ing important questions: which systemsand data do a business unit really need,and how should the data and systems beorganised to support the business unit inthe best possible way?

The Urd method focuses on a family ofconcerned systems within a businessunit. Surveying and analysing are per-formed top-down and the design bottom-up. During the analysis existing systemsare decomposed into data objects andrelations, and grouped into subjects (formore details see [3]). The subjects are

used to compose new systems in theidealistic design phase.

The purpose of the first phase (I), survey-ing, is to identify problems and oppor-tunities related to the systems. Systemowners, system users and data users areinterviewed during this phase. Beside thesystems, information flow between sys-tems and between systems and organisa-tion units are studied. The lowest granu-larity level of this phase is systems andorganisation units.

The second phase (II), data subject analy-sis, is performed to identify overlaps ofthe systems data. Entities and relation-ships are studied and grouped into sub-jects, see [3] for a definition of subjectand more information on the grouping.The subjects are used as building blockswhen new systems are identified, in thelast phase (IV).

Corrective systems planning, the thirdphase (III), is optional. The purpose ofthis phase is to reduce overlap in existingsystems, while waiting for the realisationof a more idealistic systems plan.According to the method, entities andrelationships are the correct granularitylevel of this phase. In practice, however,the project experienced that attributes

had to be studied to be able to decide if asubject overlap indicated a real overlapin data instances or not. The reason whythis detailed level is necessary is becausethe analysis results now are used indesign of improvements of current sys-tems. A graph showing data flow be-tween systems and ownership of subjectssummarises the results of this phase.

The last phase (IV) of the method iscalled idealistic systems planning. A newsystems plan for the application area ofthe system family studied is constructed.The intention is to support the businessunit in the best possible way. Routinesare analysed and redesigned. Subjects areassigned to redesigned activities (that areanalysed at organisation level only). Sys-tems are then designed as the set of sub-jects that serve the redesigned activitiesin the best possible way. Finally, cost-benefit analysis and migration plans aredeveloped.

To summarise, the Urd method is only asystems planning method, even thoughsome system design aspects are add-ressed in the optional third phase. Thegranularity levels are illustrated inFigure 2.

Information StrategyPlanning

James Martin presents a method forinformation strategy planning in his bookStrategic Information Planning Methodo-logies [2]. The scope of this method isthe whole business or enterprise. Themethod is top-down. Involvement of top-management in the planning process isregarded as crucial for the ability toimplement the systems plan. Top man-agement is directly involved in perform-ing the first four phases of the method.The method consists of six phases, pre-sented below. The business areas, whichare identified in the last phase of themethod, are subjects for further planningstudies.

The phases are:

I Linkage Analysis Planning. The pur-pose of this phase is to formulate astrategic business vision.

II Entity-Relationship Modelling. Thisphase is performed to get a betterunderstanding of the enterprise. Inaddition it provides a complete list ofthe functional areas, functions andactivities that constitute the enterprise.

8

7

6

5

4

3

2

1

0

Gra

nila

rity

leve

ls

I II III IV

Phases

Urd

Figure 2 Granularity levels in the different phases of the Urd method. Phase 3 is optional


Figure 3 Granularity levels in the different phases of the Information StrategyPlanning method

Figure 4 Granularity levels in the different phases of the Information Co-ordinationmethod

III Technology Impact Analysis. Thepurpose here is to give top manage-ment an overview of potential oppor-tunities and threats due to technolo-gical changes1.

IV Critical Success Factor Analysis.Through this phase focus is put onthe most important activities for theenterprise. Based on the results fromthis phase, decision support systemsfor the enterprise should be designed.

V Goal and Problem Analysis. In thisphase the information needs of theorganisation units within the enter-prise are identified.

VI Business Area Identification. Busi-ness Areas of the enterprise, and thedata and functions that belong toeach business area are identified.Overlap in data and functions be-tween business areas are minimised.

The Information Strategy Planningmethod does not deliver a completesystems plan. Systems plans are preparedby performing an analysis of each of thebusiness areas identified during the laststep of this method. We may thereforelook at the method as a prescription of aninitial part of the systems planning pro-cess.

Information Co-ordination

In his book, Information Co-ordination –the management of information models,systems and organisations [6], RichardVeryard presents an organic planningmethod. The term organic refers to theidea of gradual change towards a moreidealistic solution, see [6]. Veryard pre-fers to call the result of this method astrategy, and not a plan. The scope of themethod is the business/enterprise. Thephases of this organic planning methodare:

I Discover business objectives andgoals. This is performed through adiscussion with top management,which also aims to identify the busi-ness’ strengths, weaknesses, threatsand possibilities.

1 Our granularity level hierarchy doesnot cover technology, like new hard-ware components. We have given thisphase granularity level 6, only becausethe discussions are performed at theorganisation unit level.

I II III IV V

Phases

8

7

6

5

4

3

2

1

0

Gra

nila

rity

leve

ls

VI

Information Strategy Planning

I II III IV V

Phases

8

7

6

5

4

3

2

1

0

Gra

nila

rity

leve

ls

VI

Information Co-ordination


II Build a high-level conceptual modelof the business’ functions and enti-ties. This model is called informationarchitecture.

III Survey existing and planned systems,and the interfaces between them. Thisincludes comparison with the infor-mation architecture to ensure qualityand usefulness, and discussions withtop management to identify the mainproblems and opportunities.

IV Establish a set of system develop-ment principles and procedures, andestablish the support groups andtechnical infrastructure necessary tosupport them.

V Identify and prioritise between someimportant projects, necessary to per-form the next three to five years.

VI Tactical planning, that is identifysome small and medium sized pro-jects to be performed during the firstyear (in parallel with the more im-portant ones identified above).

This method addresses systems planningonly, and not system development. Thesystems plan is of a tactical, not ideal-istic, nature. We define tactical planning

to have a perspective of three to fiveyears, while idealistic planning has aperspective of five or more years.

Business/enterprisemodelling

Katz presents a way of doing business orenterprise modelling [7] where one goalis to minimise data sharing between workprocesses. Another goal is to ensure thatdata users are satisfied with data quality.The scope of the method is the businessor enterprise. The first part of the work,identifying all processes of the enter-prise, can be performed top-down bydecomposing the business functions. Thelast part of the work is performedbottom-up. This includes clustering datato minimise data sharing between pro-cesses. In his paper [7], Katz does notdivide his method into distinct phases. Tobe able to compare the granularity of hismethod with the others, we have identi-fied five phases, as follows:

I Process identification. This includesdecomposition of business functionsand identification of the data thateach business process uses.

II Interviews. This phase involvesemployees from all over the enter-prise. One of the goals of the inter-views is to find out if data users aresatisfied with data quality or not.

III Design of an integrated systemsarchitecture. This phase includesclustering data to identify businessprocesses. The data is grouped in away that minimises data sharing be-tween business processes.

IV Simulation. This is performed toreveal which of the business pro-cesses that will benefit the most fromthe suggested changes.

V Tactical project identification. Theprojects necessary to implement theintegrated information systems archi-tecture are identified.

The business/enterprise modellingmethod is a systems planning methodonly, and not a system development plan.We have presented the method as it willbe performed if an integrated systemsarchitecture is the chosen solution. Thiswill not always be the case, see [7].

Conclusions

The granularity level diagrams show thatthe method with the lowest granularitylevel (level 0) is the ISAC method. Thereason for this is that ISAC includes sys-tem development, and this requires moredetails than systems planning. We findthe next granularity level up (level 2) inthe Urd method. This is because the thirdphase of Urd (the optional one) containssystem design aspects, which belong tosystem development as well. For theother methods, granularity level 3,entity/relationship, seems to provide thesufficient details. This is true for the Urdmethod, too, when the optional phase isskipped.

In Urd, level 3 is used to design subjectsat level 4. The idealistic design is thenbased on level 4. The other methods pre-sented in this paper do not address level4. Constructing a subject can be seen as aparallel to normalising relations due tofunctional dependencies in the relationalmodel. The difference is that whilenormalisation in the relational modelfocuses on functional dependencies be-tween attributes, Urd focuses on func-tional dependencies between relation-ships. The third phase of the business/enterprise modelling method includesclustering, and is probably based on simi-

8

7

6

5

4

3

2

1

0

Gra

nila

rity

leve

ls

I II III IV

Phases

V

Business enterprise modelling

Figure 5 Granularity levels in the different phases of the Business/enterprisemodelling method


lar ideas about functional dependenciesas the relational model.

The diagrams show that all the methods,except Urd, start with granularity level 8,the enterprise level. The reason for this isthat the scope of this method is a systemsfamily of one of the enterprise’s organi-sation units, and not the enterprise as awhole, as for the other methods. Thismethod is the only idealistic or strategicsystems planning method of the fivemethods presented. It may also be anoperational systems planning method(with a one-year perspective), if the thirdphase is performed. The information co-ordination and the business/enterprisemodelling methods are tactical systemsplanning methods. The informationstrategy planning method does not de-liver a systems plan. This method con-stitutes a framework for organising dataand functions in an enterprise.

Systems planning methods differ, inscope and granularity. Four of themethods presented in this paper gothrough exactly the same granularitylevels, but in different order and througha different number of phases. It is never-theless significant which of the methodswe use. As we have just stated, themethods serve different purposes. Whenchoosing a systems planning method, themost important thing to do is to ensurethat the method we choose is able toanswer the problem we want to solve. Ifwe need a framework, like the one theinformation strategy planning provides,we do not choose Urd. Do we need a sys-tems plan, we do not choose to do infor-mation strategy planning. And, if weneed a systems plan, we have to find outif it should be an operational, tactical oridealistic plan.

References

1 Lederer, A L, Salmela, H. Toward atheory of strategic information sys-tems planning. Journal of StrategicInformation systems, 5, 237–253,1996.

2 Martin, J, Leben, J. Strategic Infor-mation Planning Methodologies.Englewood Cliffs, NJ, Prentice Hall,1989. ISBN 0-89435-358-6.

3 Saxlund, G et al. The Urd systemsplanning method. Kjeller, TelenorFoU, 1996. (Report FoU N 52/96.)

4 Inmon, W H. Data architecture : theinformation paradigm, 2nd ed.Boston, Mass., QED TechnicalPublishing Group, 1992. ISBN 0-13-850538-1.

5 Avison, D E, Fitzgerald, G. Informa-tion Systems Development : Metho-dologies, Techniques and Tools.Oxford, Blackwell Scientific Publica-tions, 1988. ISBN 0-632-01645-0.

6 Veryard, R. Information coordina-tion : the management of informationmodels, systems and organizations.Englewood Cliffs, NJ, Prentice Hall,1994. ISBN 0-130099243-7.

7 Katz, R L. Business/enterprisemodelling. IBM Systems Journal, 29,509–525, 1990.

Sigrid Steinholt Bygdås has been employed byTelenor R&D as Research Scientist since 1992.She has been working with models and methodsfor systems planning, system development andCASE tool evaluation. Her current interests are insystems plan implementation and software archi-tecture.



This paper presents the notion of sub-ject graphs, which is a way of part-itioning a data structure into candidateautonomous databases. Subject graphsare used in the Urd method – a sys-tems planning method. An overview ofUrd can be found in another paper inthis issue of Telektronikk.

Purpose and overallprocess

In the Urd method, the term ‘system’ isdefined to be the data that is enforced asone consistent whole. This means that asystem contains all the data needed for anapplication area, and the rules of con-straints needed to maintain consistencybetween these data. This definition of

system insists on consistency within thesystem’s boundaries, but a system cannotguarantee complete consistency of datathat is communicated between differentsystems.

According to Urd, the first step in theprocess of making a systems plan is tosurvey the applications in the applicationarea. The survey consists of interviewingthe application owners, users of the appli-cations and users of the data extractedfrom each application. The goal is to iden-tify problems and possibilities with the oldapplications and usage of the applications.

The subsequent step is to analyse theidentified applications. The goal is toidentify overlap between systems, i.e.common data across two or more sys-tems. To achieve this, subject graphs areconstructed.

To design subject graphs, we start with adata structure graph for each system.Some of the systems do not have a docu-mented graph, and for these a graph mustbe developed. Other systems do have adata structure graph, but not in a suitableform. Often, the data definitions of a sys-tem are found in various forms. Ex-amples could be anything from databasescripts, conversion documentation, userdocumentation, to plans for a new sys-tem. The documentation may not be con-sistent and is frequently not up to date.To analyse the data structure, all thedocumentation must be transformed intothe same notation.

An alphanumeric notation is not verysuitable for getting an overview of thedata definitions, thus a graphical notationis required. The notation used is a subsetof Graphic GDMO (Guidelines for theDefinition of Managed Objects) [4].Figure 1 shows a small data structuregraph expressed in Graphic GDMO,showing examples of all the constructsthat we use.

Note especially that there are no attri-butes in the data structure graph. Veryoften multivalued attribute groups areseparated as different entities. Theseattribute groups are removed from thegraph. This way, we get a more compactdata structure graph, focusing on thecentral object classes.

Once a system’s data structure is pro-vided in a common notation, it is pos-sible to perform a subject analysis on thedata structure. The result is a subject

The Role of Subject GraphsA R N E S O L E V Å G H A T L E N

TrialConnectionTermination

Point

LinkConnection

Link

Managed ObjectClass

Name BindingTwo-way referenceOne-way reference

Name

Figure 1 A small example data structure graph, showing the subset of GraphicGDMO that we use. At the bottom of the figure is a legend explaining the symbolsused in the graph

TrialConnectionTermination

Point

LinkConnection

LinkTransportation

Termination

Link Linkconnection

Figure 2 To the left the data structure graph presented in Figure 1 is shown, with indications of sub-ject definitions (the two coloured areas). The corresponding subject graph is shown to the right. Thesubject graph consists of two subjects, Transportation and Termination. The names are ‘arbitrary’names, indicating the type of data the subjects consist of. Link and Link Connection are the two objectclasses that are needed in both subjects because of the name binding between them. Thus, they definereference points between the two subjects


graph per system. The transition from thedata structure graph in Figure 1 to a sub-ject graph is shown in Figure 2.

Having performed a subject analysis forall relevant applications, the resultingsubjects from all the subject graphs arecollected in a subject-system matrix, asshown in Figure 3. If two subject graphscontain the same or very similar subjects,this is considered a subject overlap.

Subset of Graphic GDMO

A specification using GDMO or anotheralphanumeric notation is usually veryelaborate and difficult to overview.Graphic GDMO provides the overviewfor a GDMO specification. GraphicGDMO does not show the completeGDMO specification, however, and thusit can only be used as a supplement to thealphanumeric specification, and is indeedmeant only as a supplement.

For systems planning, however, the levelof details provided by Graphic GDMOsuffices.

Graphic GDMO is used because of itsdistinction between name bindings (con-tainment) and references. In addition tothe symbols presented in Figure 1,Graphic GDMO has constructs for view-ing attributes of managed object classes,and relations between managed objectclasses, such as inheritance (derivedfrom), containment (name bindings),references and relationships with con-straints. The complete specification ofGraphic GDMO is defined in ITU-Trecommendation Z.360 [4].

Subject graphs

A subject is a collection of associations(references, relationships and name bind-ings) between object classes. A subjectgraph is a collection of subjects, eachcovering a connected fragment of a sys-tem’s data structure, with referencepoints between them.

Each reference or relationship can onlyparticipate in one subject. This rule doesnot apply to name bindings.

Between the subjects are referencepoints. A reference point is an objectclass that forms one end of two or moreassociations located in different subjects.A reference point can be binary or n-ary,i.e. an object class is related to two ormore subjects.

Figure 4 shows a generic example of asubject graph. Here, subjects S2 … S5contain one or more relationships inwhich object class A takes part. Theobject class A is said to be a referencepoint between subjects S2 ... S5. In thesame manner, the object class B is areference point between S1 and S5, andC between S2 and S3.

Let A be an object class participating inmore than one relationship within subjectS3. This multiplicity does not change thenature of the reference point – S3 stillonly ‘participates once’ in referencepoint A. Thus, reference point A definesthe data that must be communicated be-tween the two subjects, if the subjects areincluded in different systems. It does not,however, define the data that must becommunicated to perform a given opera-tion, or the sequence of the data commu-nication.

The purpose of defining subject graphs isto identify ‘natural’ vertical partitions ofthe data, i.e. a fragment of the data struc-ture that in principle could be imple-mented as a separate database.

When designing a subject graph, eachsystem is analysed separately from theothers. The purpose of this is to keep thescope of the analysis to a manageablesize. However, it is important to keep inmind that all the subject graphs are to becompared and joined across several sys-tems. Thus, identifying similar subjects isvital.

Subject design criteria

There are few formal criteria for definingwhich information should be groupedinto one subject.

The main criterion is to group existen-tially dependent associations into thesame subject. This way, existential con-straints can be enforced within a subject,and does not require references to othersubjects. The term existential dependencycorresponds to functional dependency inthe relational model.

Another grouping criterion is thatsuperior name bindings1 of an objectclass should be present if a reference orrelationship to the same object class isincluded in the subject. Figure 2 showsan example of this. Here, the name bind-ing between Link and Link Connection isincluded in the same subject as the two-way reference between Link Connectionand Connection Termination Point.

Sometimes there will be “loose” relation-ships (or object classes) in a data struc-ture, i.e. a relationship that does not haveany strong dependency to other parts ofthe data structure and does not strictly fitinto any subject. These relationshipscould be kept as separate subjects, butmay be included in a subject togetherwith other data with which it is fre-quently used.

1 A superior name binding is also knownas an identifying name binding, i.e. aname binding that is used to identifyinstances of an object class, withoutwhich the object instance could not beuniquely defined.

System System A System BSubject

S1

S2

S3

S4

S5

X

X

X

X

X

X

X

Figure 3 An example subject-systemmatrix, showing five subjects, of whichone (S3) exists in system A only, two sub-jects (S2 and S5) exist in system B only,and two subjects (S1 and S4) indicate anoverlap, as they are present in both systems

S1

S2 S5

S3 S4

B

A

C

Figure 4 A generic subject graph, show-ing five subjects S1 ... S5, connected withthree reference points A, B and C


Use of subjects

The purpose of using subject graphs is tointroduce a high-level view of the data,without having to address all the detailsof the data structure and the specificdifferences of data structures within eachsystem.

However, there are fundamental diffe-rences between subject graphs and datastructure graphs. A node in the subjectgraph corresponds to a set of edges –associations – in the data structure graph,and an (n-ary) edge – a reference point –in the subject graph corresponds to anode (an object class) in the data struc-ture graph. Thus, a subject graph is adual hyper graph of the data structuregraph.

The purpose of subject graphs – to defineminimal candidate systems and needs forcommunications between these – seemsto be clear. However, we have onlyexperiences from one large project inusing the graphs, and in this project wedid not gain enough experience with uni-fication across several systems. Accord-ing to the experiences, we have noticedthat the contents of ‘similar’ subjects indifferent subjects are most likely to bedifferent, but having identified the sub-jects, it is believed to be more feasible toharmonise two subjects than harmonisingtwo (or more) data structures.

The introduction of new technology, newservices and new data standards mayintroduce new data structures that need tobe harmonised with existing systems.Old and new data structures can be verydifferent. Unification on subject level isthen believed to be more appropriate forsystems planning work, than at classlevel. However, for providing the unifi-cation of subjects, the discussion anddetailed comparison have to be made atclass level.

In the Urd method, subject graphs aredeveloped per system, analysed for over-lap and then unified across the system.This is not the only conceivable app-roach, as the data structures could havebeen unified before development of theunified subject graphs. However, thiswould require working with more de-tailed designs during the systems plan-ning work.

Comparison with otherkinds of grouping

When doing strategic planning, we seekto avoid too many details. In some tech-niques, such as [2], this is achieved byabstracting similar object classes into oneabstract object class, often called a ‘cen-tral’ object class. It is stated that thisabstract object class represents all objectswith the same common factors. This isnot the case with subjects, as subjects arecollections of associations, where thecontent of the collection is known.

The Urd method is to be used in strategicplanning. The bottom-up approach ofUrd is another difference from the top-down approach of some strategic plan-ning work. By using subject graphs, abottom-up approach is forced, requiringthe designers to identify the real datatypes (object classes) and associations inan application area, instead of usinggeneralised, i.e. less detailed abstrac-tions. It is believed that a bottom-upapproach at this level yields a betterresult.

In [1], William Inmon suggests a methodfor collecting data from an organisation’scomputer systems. Inmon’s proceduresuggests grouping the data according totheir usage. The data are divided into twocategories, one for operational data, andanother for data used in decision support.The latter category is then divided intoatomic, departmental and individual data.

The goal of the grouping is to enableusage of data for new purposes. Inmon’sgrouping differs from the grouping ofdata into subjects, in at least two ways:First, the data in a subject are groupedaccording to usage. Second, the subjectsdo not necessary become databases,several subjects can later be joined intoone database.

In [2], Martin and Leben describemethods for strategic information plan-ning, and techniques to support the acti-vities in this method. They define entity-relation (ER) models associating func-tions with business units and data enti-ties. As with Inmon, these criteria forgrouping entities differ from the criteriafor grouping information into subjects, inthat subjects are organisation indepen-dent. However, in an idealistic designphase of the Urd method, subjects aregrouped into systems according to theirusage in manual routines.

Clustering [7, 8] is a much-used term fortechniques for grouping data. Clusteringmight look similar to defining subject asit defines clusters of data items used inthe same operations. However, the ob-jective is typically to minimise the num-ber of page references in a disk opera-tion, or to localise object instances thatare used in the same transactions. In bothcases, the objective is to increase the per-formance of a system. Clusteringschemes are concerned with objectinstances and attributes, thus operatingon a more detailed level than subjectgraphs. Clusters also differ from subjectsin that subjects are class level collections,whereas most clustering techniquesgroup data instances. There are schemesfor class level clustering, but they usuallyhave the same goal of minimising remotereferences, as with instance level cluster-ing.

When using subjects as a basis forimplementing computing systems, sub-jects might be joined on class level andpartitioned on instance level, accordingto some distribution criteria. Thus, clus-tering is used for a different purpose thansubjects and gives very different results.

Usefulness

The “Use of subjects” sections haveidentified several applications for subjectgraphs. Identifying overlaps across sys-tem borders, supporting the harmonisa-tion of computer systems and identifica-tion of possible partitions of distributedapplications.

However, subject graphs are probablynot the universal medicine for allharmonisation problems2. When con-structing subject graphs for a set of re-lated systems, person-dependency mightbe a problem. To ensure that subjectgraphs are comparable – and this isusually a requirement when analysing anapplication domain – the designers mustwork closely together, having at least anindication of the common fragments ofthe data model in different systems.

Neither does subject graphs present ageneral solution for the problem ofschema integration or migration. It isquite possible to make data structurescompletely incompatible with others, and

2 And neither has this been the intentionof subject graphs or Urd.


mapping fragments into subjects does notpresent a solution for integrating twodifferent models, or migrating data fromone data model to another model.

We have, however, good reasons to be-lieve that construction of subject graphscan be helpful in giving a simplified viewof possible overlaps across systemswithin an application area. With thebottom-up nature of constructing subjectgraphs one could be more confident ofthe completeness of the overview, i.e.that every part of the systems’ data struc-tures are included, than with a top-downapproach.

References

1 Inmon, W H. Data architecture : theinformation paradigm, 2nd ed.Boston, Mass., QED TechnicalPublishing Group, 1992. ISBN0–99435-358-6.

2 Martin, J, Leben, J. Strategic Infor-mation Planning Methodologies.Englewood Cliffs, NJ, Prentice Hall,1989. ISBN-0-13-850538-1.

3 Meisingset, A. Graphic GDMO.Telektronikk, 93, (2), 94–96, 1997.

4 ITU-T. A Graphic GDMO. Geneva,ITU. (ITU-T RecommendationZ.360.)

5 ITU-T. Information Technology :Open Systems Interconnection :Structure of Management Informa-tion : Guidelines for the Definition ofManagement Objects. Geneva, ITU,1992. (ITU-T RecommendationX.722.)

6 ITU-T. Information Technology :Open Systems Interconnection :Structure of Management Informa-tion : General Relationship Model.Geneva, ITU. (ITU-T Recommenda-tion X.725.)

7 Meisingset, A. The Urd method.Telektronikk, 94 (1), 12–21, 1998(this issue).

8 Everitt, B R. Cluster analysis. Hal-stad Press, 1993.

9 Javin, A K, Dubes, R C. Algorithmsfor Clustering Data. Prentice-Hall,1988.

Arne Solevåg Hatlen is Research Scientist atTelenor R&D, where he has been involved in sys-tems planning and systems planning methodo-logy work in the area of TelecommunicationsManagement Network (TMN). His main interestsare object-orientation in design and implementa-tion, and he is currently working in a Telenor R&Dproject dealing with the object web and middle-ware technologies for the Internet.

e-mail: [email protected]

This paper proposes three perspectiveson the end user data managed andprovided by a computer system. Theproposed perspectives are normativeand not descriptive, as current prac-tice frequently deviate much from theproposed norm. The purpose of theproposal is to present principles whichcan serve as subject for discussion aswell as guidelines for design and use.

Introduction

The end user data define what the systemlooks like as seen from the outside. Thethree perspectives define how these data

relate to the application domain, the enduser organisation, and how the data relateto each other. Hence, the perspectivesprovide theories for how a system canrelate to the outside world and how thesystem of data can be structured.

The modelling dimension states how datarelate to entities in the applicationdomain, e.g. the telecommunication net-work, being managed by the data of thesystem, see Figure 1. The correspon-dence dimension states how the organisa-tion of data into systems, functions andscreens relate to business units, organisa-tion units and tasks. The classificationdimension states how data relate to theirdata definitions, meta data definitions,etc. The reader should be warned thatmany approaches provide neither model-ling nor correspondence, even if they(inappropriately) use terms like ‘models’and ‘tasks’. Also, there are many alterna-tive (mis)conceptions about classificationand instantiation.

Each of the subsequent sections providestheories for the three dimensions. Even ifthe sections provide a technical definitionof the three dimensions, the readershould note that they define profoundcharacteristics of a system in an applica-tion and usage context.

Figure 2 provides a framework for inter-pretation of the dimensions. The frame-

work defines the formats needed for themapping of data between two media. Notall formats and all transformations areneeded in every information system (IS),however, it is these transformationswhich make ISes interesting and usefulto most users. If data are only replicatedbetween systems, then only the middlelayer(s) of the framework is (are) needed.

A more complete exposition of theframework illustrated in Figure 2 isfound in [1].

The reader should note that the corre-spondence theory of human-computerinterface design prescribes an organisa-tion dependence between organisationsand systems. This theory is contradictoryto theories of virtual organisations claim-ing independence of locations and orga-nisational boundaries. The organisationdependence can be illustrated by thefollowing realistic example: Suppose atelecommunication corporation is splitinto a service business unit and a networkbusiness unit. In order to support theindependence of these business units andtheir rights to choose products from anddeliver services to competing organisa-tions, the systems should be split onthese two units – the service businessunit may need a service management sys-tem, the network business unit may needa network management system, and theymay exchange data automatically via an

32

Three Perspectives on Information Systems ArchitectureA R V E M E I S I N G S E T

Telektronikk 1.1998

Application domain

Manualorganisationand othersystems

Data of asystem

Modelling

Correspon-dence

Classi-fication

Figure 1 Perspectives on informationsystems

TS OS TS DS PS

Lr Cr Tr Or Tr Dr Pr

LS

CP TP OP TP DPIP

CS

LP PP

System schema

External schema Application schema Internal schema

Mapping between sets of data

Two-way data flow

Set of data

Processor

Colours have

no significance

External processor Application processor Internal processor

L = Layout T = Terminology D =DistributionC = Contents O = Concept P =Physical-S = Schema -r = Processor -P =Population

Figure 2 The data translation reference model

electronic order handling system. If,alternatively, the business units weremerged, both service and network man-agement could most efficiently be pro-vided by one integrated system for thisunified business unit, and the split be-tween management systems was notneeded. There is no generic informationsystem architecture (ISA) or approachwhich is robust to such organisationalchanges, but there may be software archi-tectures, tools and development tech-niques which can simplify reorganisationof systems when needed.

The three proposed principles providelinguistic deep structure, system theo-retical contributions to human-computerinterface design. The principles relate tolanguage theory. The modelling theoryrelates to denotational semantics. Thecorrespondence theory relates to corre-spondence semantics. The classificationtheory provides a copy ‘semantics’. Theauthor prefers to reserve the term‘semantics’ for the denotational versiononly. It is outside the scope of this paperto provide parallels to philosophy, lin-guistics and formal language theory.

The Model Theory forHuman-Computer Inter-action Design

This section adapts model theory inter-pretation of language statements tohuman-computer interaction design.

Background

Statements can be categorised into thefollowing three kinds: 1) Commands,like ‘Remove the diskette!’ and ‘Performx + 1’; 2) Questions, like ‘What is thecustomer number?’ and ‘If x < 3’; and 3)Informative statements, like ‘Customer 1has phone number 3’ and ‘x = 2’.

Here we will deal only with informativestatement. Informative statements statean association between terms.

Some terms or combination of terms candenote a phenomenon in some applica-tion area, e.g. the combination of terms‘circuit name A-B 1’ can denote a uniquecircuit in a network of some administra-tive domain. The total expression ‘circuitname A-B 1’ is said to denote, model ordescribe this phenomenon. However,each of the component terms, A, B and 1,

of the expression may not denote, modelor describe any phenomenon.

Some terms or combination of terms canbe created to provide an overview ofother terms, e.g. ‘circuit group A-B 1’may be created to provide an overview ofthe constituents ‘circuit A-B 1’, ‘circuitA-B 2’ and ‘circuit A-B 3’ between thesame two nodes – A and B – in the net-work. The combination ‘circuit groupA-B 1’ constitutes a derived data itemand may not denote a directly observablephenomenon in the network. Therefore,this combination is said to describe/model nothing.

If data denote something, then the map-ping is considered to be 1:1. In any case,there is a functional mapping (n:1) fromphenomena to data. If the relationshipsbetween or behaviour of the phenomenaare modelled, then the mapping is iso-morphic, i.e. the modelled relationshipsand behaviours are preserved as associa-tions among the data. This property ofthe mapping makes the data become amodel of the described world.

Note that in this text we will only discussdenotation/description/modelling map-pings between terms and phenomena. Wewill neither discuss assertion mappingsfrom statements to propositions/facts northe assignment of truth values derivedfrom these mappings.

Several terminologies may be used todescribe identical or overlapping worlds,e.g. ‘circuit A-B 1’ may denote the samephenomenon as ‘samband 12345’ inanother terminology. The requirementsfor functional mappings from phenomenato any data and isomorphic mappings todescribing data apply to every termi-nology.

Rather than introducing mappings be-tween phenomena and data in each termi-nology, an intermediate conceptual levelbetween phenomena and terms can beintroduced. A functional and isomorphicmapping is introduced between pheno-mena and concepts at the conceptuallevel. Each concept can then be mappedby an isomorphic mapping to a term insome terminology. These mappings mustbe stated explicitly, e.g. ∃ !x (Denotes(circuit A-B 1, x)∧ Denotes (samband12345, x)) states that there is exactly onex (∃ !x) such that x is denoted by either ofthe compound terms ‘circuit A-B 1’ or‘samband 12345’. The two denotationmappings state the formal semantics, i.e.

the common formal meaning, of the twosyntactical expressions. If this mappingis not stated, then the data do not modelanything in the formal sense. The dataare then just inscriptions, not descrip-tions.

If no formal denotational semantics isprovided, the data may still be intendedto model something in the informalsense. However, the data designers andend user operators must take great care toensure that the mapping to each indi-vidual real world phenomenon is com-monly understood and shared by theusers of the data. This implies that

• each individual phenomenon isuniquely baptised, labelled or other-wise distinguished from other pheno-mena

• classes are clearly defined, explained,related to other classes and exposed toall users concerned.

Guidelines

The following modelling guidelinesapply to the design of data of the applica-tion layer of the HMI reference model:

1 There should be a functional mappingfrom phenomena in the applicationarea to application layer data.

2 If the application layer data describesome phenomenon, then this mappingshould be isomorphic.

3 The application layer should includecentralised definitions of all alpha-numeric, graphical or other termino-logies used within the application,


circuit group A-B 1

circuit A-B 1

circuit A-B 2

circuit A-B 3

circuit A

samband 12345

Denotes

Phenomena

Concepts

Terms

Figure 3 Use of Ogden’s triangle todepict mappings between terms, conceptsand phenomena. Some terms denote con-cepts, which model phenomena

including synonymy mappings be-tween terminologies or mappings tocommon concepts.

4 There should be a homomorphic (n:1)mapping from data instances to dataclasses in the application layer.

5 The application layer should containall relevant derivation rules betweenand constraints on the data.

ITU-T Recommendation Z.352 Appen-dix I [2] provides additional guidelinesfor data design. Both basic and deriveddata are defined, managed and providedfrom some user needs. Analysis of usertasks may help to identify such needs;however, the tasks may as well be de-fined to manage data already defined, orthe tasks may support needs outside theboundary of the task analysis. Therefore,data must be provided from a marketpoint of view and not from a restrictivetask analysis only.

The following modelling guidelinesapply to the design of the contents layerof the HMI reference model:

1 The contents of screens and reportsfound in the contents layer should con-tain no other data than those defined inthe application layer of the application,and permissible manipulation com-mands on these data. The contents ofeach screen and report is typically asubset of the information contained inone application system.

2 The contents of each screen and reportshould form one connected graph.There should be a homomorphic (n:1)mapping from the contents graph tothe corresponding application layerdata. See additional note in principle(5).

3 The contents of each screen and reportshould form a tree, possibly with refe-rences between nodes in this tree or tonodes outside the tree.

4 Any data object from the applicationlayer can form the root of one or morecontents trees.

5 Referenced data objects in the applica-tion layer may become subordinates ina corresponding contents tree. There-fore, the contents of the contents layermay not have identical structure to thecorresponding subset of the applicationlayer. However, there is no transforma-tion of data formats between the twolayers.

6 If an object is listed subordinate to itssuperior objects, then local distin-guished names can be used. If sub-ordinate objects are listed without theirsuperior objects, then global distin-guished names are used. However, itis permissible to list objects and theirsuperior in reverse order, using localdistinguished names only, if this isproperly indicated to the user.

7 There should be a homomorphic (n:1)mapping from data instances to dataclasses in the contents layer.

Item (5) corresponds to the use of sub-clauses in natural language: The mainclause refers to an item which has somecharacteristics, defined in the subsequentsubclause. For example, ‘Circuit hasEnd-point, which is a Station and hasName and Address’ In the applicationlayer ‘Circuit’ and ‘Station’ are twodifferent object classes. ‘Circuit’ has anattribute ‘End-point’ referring to‘Station’. ‘Station’ has two attributes‘Name’ and ‘Address’.

The given principles for contents designapply both to data classes and datainstances. These principles address howinformative statements of the applicationlayer are mapped into the contents layerto maintain the information stated in theapplication layer.

The following modelling guidelinesapply to the design of the layout at thehuman-computer interface:

1 The root node of the contents treeshould be clearly indicated in everypresentation.

2 The context in which the presentationis provided, e.g. indication of systemname, function name, etc., shouldclearly be indicated in every presenta-tion.

3 The layout – alphanumeric, graphic orother – should clearly indicate how allthe data items relate to each other andthe correct sequences of these refe-rences, e.g. <John, 12345>=/=<12345,John>.

4 The layout should clearly indicate theclass of every data item presented andthe relations between these classes.

5 Class labels appear as headings or icontypes at the HCI.

6 References between objects should –both in alphanumeric and graphicalpresentations – be clearly distin-

guished from the presentation of thereferenced object itself, such that theuser can distinguish creation/modifica-tion/deletion of a reference to an objectfrom creation/modification/deletion ofthe object itself.

7 Subordination, superiority and glo-bality of objects, attributes and valuesshould be clearly indicated.

8 Fonts, sizes and colours may bechanged in the mapping from the con-tents layer to the layout. However, thebasic data types should not be altered.

Rationale

The rationales for the given modellingprinciples are to make

• data understood and easy to manipu-late by the users of the data

• the data definitions, structure and for-mats harmonised and recognisablethroughout all presentations

• the structure of the data visible andrecognisable to the users of the data

• the data uniquely interpretable by theusers of the data

• the mappings between instances andclasses visible, such that classes can beinferred from instances and vice versa

The CorrespondenceTheory for Human-Com-puter Interaction Design

This section provides a correspondencetheory interpretation of language state-ments to human-computer interactiondesign.

Background

Correspondence theory is concerned withthe contexts in which statements areuttered, and with the correspondencemappings between a statement and itscontexts.

The statement ‘Person 1 has phone num-ber 3’ may assert a state of affairs insome given application area. Aspects ofthis assertion/denotation mapping werediscussed in the previous section. In thissection we will discuss the contextsexplaining why this statement is utteredand assign the statement to the appro-priate contexts. Statements have both


senders and receivers; however, this dis-tinction will not be used in this section.

Identical statements may be stated in dif-ferent contexts. The statement ‘Person 1has phone number 3’ may be provided toa telephone user who wants to phone Per-son 1. The information may be providedin a paper directory, by the enquiry ser-vice, as information in an e-mail, in atechnical paper, or appear in a serviceprovision task of a telecom operator.Even if, in this case, the final use of theinformation is much the same, theorganisational contexts in which thestatement is uttered and used are verydifferent. If identical information is givenin two different administrative domains,both denotations and terminology can bedifferent. Identical terms can refer to dif-ferent instances and to different classes.Therefore, the knowledge of the corre-spondence to the organisational contextsis required to provide a complete andunique interpretation of the statements.

A modern organisation is considered tobe an information system. This meansthat we will consider the organisation toconsist of manual and automatic informa-tion processing. In this context we willdisregard classical organisations contain-ing labour like ditch digging, transport,production, etc. in manual or automaticform. We will constrain ourselves tomanual and automatic information pro-cessing only. If other labour takes placein the organisation, we will only studythe information processing part.

The correspondence theory of human-computer interaction design addressesthe mapping between statement produc-tion to or from the computer and theorganisation of manual tasks of the usersand user organisation.

Computer systems should not be de-signed for a given organisation of manualwork only. Also, a manual organisationshould not just adapt to a given computersystem. Rather, both the computer sys-tem and the surrounding manual organi-sation should be designed interactively,such that the best use of both automaticand manual resources could be achieved,ref. the system theoretical school for sys-tems development.

The design of human-computer inter-faces must realise the different strengthsand weaknesses of automatic and manualinformation processing, ref. the socio-

technical school for systems develop-ment.

Finally, a designer of human-computerinterfaces has to realise and balance dif-ferent and conflicting interests by diffe-rent user groups and individuals, ref. thecritical school for systems development.This last point implies that human-com-puter interfaces should not only beevaluated in a laboratory setting, butmust be evaluated in an organisationalsetting of terminal operators, operatororganisation, management, customersand others.

To define the user groups and stake-holders of an information system is notrivial task, and the user groups tend tochange as time passes. For example, tele-com service customers may at first not beconsidered candidate operators of thehuman-computer interface. However,later they may be managing their ownservices over the interface. Even in thefirst case, they are real users of the data,which the telecom terminal operatorsmay not be.

In addition to the above concerns, thehuman-computer interaction designershould bear in mind which perspectiveon the system is imposed by alternativedesigns and systems developmentmethods. A process oriented design mayput users and systems in a strict workflow. Typically, this provides a highdegree of automation and little flexi-bility. A tool perspective put the mainresponsibility for undertaking tasks onthe users, while the system is used tosupport this work. The tool perspectivemay not provide a high degree of auto-mation, but may provide great flexibilityin work flow and use of the system. ITU-T Recommendation Z.352 [2] recom-mends a data-oriented approach: In thiscase, the computer system is an editor ondata, which may model some Universe ofDiscourse. This is a tool perspective onhuman-computer interaction design.Recommendation Z.352 Annex A.3 Datadesign indicates how processes/functionscan be automated within a pure data-oriented approach. In this case, the com-puter system acts as a process controlsystem.

Principles

The following correspondence guidelinesapply to the structuring of the applicationlayer of the HMI reference model:

1 Business planning of market segmentsand market strategy is normally con-sidered to be outside the scope ofhuman-computer interaction design.However, business planning can pro-vide premises for human-computerinteraction design, and human-com-puter interaction opportunities mayaffect business planning.

2 The overall organisation of the corpo-ration into business units is normallybased on business planning, and isconsidered to be outside the scope ofhuman-computer interaction design.However, business units are con-sidered to be the legal customers ofcomputer systems. Therefore, thescope of a computer system is definedby the individual business unit. Thisdoes not prohibit the system beingused by customers outside the businessunit itself. The business unit normallyforms the maximum scope of interestfor a systems directory of any userwithin the business unit.

3 A computer system is defined toenforce its data as one consistentwhole, i.e. the system will guaranteethat a statement p and ¬p will not bekept simultaneously in a system at anymoment of time. If such conflictingstatements are provided, they must beprovided from different systems.Occasionally, several business unitsmay co-operate and act as a customerof one computer system, but normallya business unit will require freedom toorganise its own manual and automaticinformation processing. This flexibilityis what makes it an autonomous busi-


Organisation ofpeople and tasks

Correspon-dence

betweenorganisation

of tasksand thehuman-

computerinterface

Statementsand terms

Figure 4 While the basic structures ofstatements and terms are given by theirmodelling roles, selection, overall struc-ture and ordering are controlled by theorganisation of people and tasks

ness unit. This independence of busi-ness units does not prohibit severalbusiness units acquiring identical sys-tems holding different data, and sys-tems of different business units mayexchange information, but consistencyof data is not guaranteed at any time.Every user should be made explicitlyaware of which systems he is usingand the borderlines of these systems,as this can affect his work within eachsystem. A system can be either cen-tralised or distributed; however, this isnot relevant to the user as long as con-sistency throughout the entire systemis enforced. If consistency is not en-forced, then there are several systems.

4 Maximum flexibility of work organisa-tion is achieved if as much work aspossible is moved to the businessfacing office within the business unit.This redesign of work flow forms apremise for design of systems bounda-ries. The systems should normally bedesigned to support all work on a rou-tine within one office of the businessunit and minimise the need to shift be-tween several systems to carry out thiswork. However, conflicting needs be-tween several routines and offices haveto be observed. This principle observesthe need to take routine design as apremise for the design of systemsboundaries. Intermediate organisationlevels between the corporation andbusiness units are normally not rele-vant to human-computer interactiondesign, and intermediate levels be-tween business units and offices (i.e.the formal organisation units at thelowest level) are normally not relevant.

Note that correspondences are stated be-tween systems and organisational units.Organisational units have real objectiveand observable existence, while businessprocesses and tasks have no objectiveexistence, unless they are defined relativeto organisational units. Business pro-cesses and tasks can be considered tomake up an alternative organisationstructure; however, they are not autho-rised to constitute one. Therefore, systemplans and system designs cannot bedesigned from the perspective of abstractbusiness processes and tasks, but shouldbe designed from the perspective of anexisting or planned organisation of thecorporation.

The following correspondence guidelinesapply to the design of the contents layerof the HMI reference model:

1 One individual user or user group willtypically have rights to use severalfunctions within one system. The parti-tion into functions should not unneces-sarily hinder the user to perform seve-ral tasks simultaneously. Therefore,functions should be defined more froman access rights perspective than iden-tification of individual tasks. However,sometimes dangerous operations maybe moved into a separate function toavoid possibly harmful, but permis-sible operations.

2 Modelessness is achieved by nottailoring and sequencing a set of ope-rations to a task. Modeless dialoguesare created to obtain flexibility and,hence, non-correspondence betweenhuman-computer interaction designsand tasks. If greater control is wanted,then screen pictures can be orderedinto one or more alternative sequences,corresponding to steps of the tasks ofthe individual or typical user.

3 The design of layout and contents ofeach screen picture is constrained bythe modelling guidelines in the pre-vious section. However, some freedomexists to further tailor the human-com-puter interface to the tasks. This isobtained by ordering the informationin the most appropriate sequence forperforming the task without violatingthe modelling guidelines. However,the user can also benefit from havingthe information presented in a harmo-nised sequence across several tasks.Therefore, contentious choices oftrade-offs between harmonisation andtailoring must be made.

4 Great flexibility is provided to the enduser if he can perform any permissiblecommand to a data item in every placeit appears. This provisioning shouldnot be constrained by function borders.

The following correspondence guidelinesapply to the design of the layout layer ofthe HMI reference model:

1 Great flexibility and tailoring can beachieved simultaneously by allowingthe user himself to perform thetailoring. The tailoring can includemeans to state selection and projectionof data in any screen picture and report– alphanumeric, graphic and other –and means to create minor modifica-tions of fonts, colours, sizes andgraphical layout. These changes shouldbe local to the individual user and notaffect other users or constraints orderivations enforced by the system.

Rationale

The rationales for the given corre-spondence principles are to provide

• correspondence to the concrete organi-sation of human work

• understanding of these bindings andlack of such bindings

• efficient support of the work beingdone

• flexibility in the organisation andundertaking of the work

• flexibility in the design of the com-puter system.

The Classification Theoryof Human-Computer Inter-action Design

This section provides a theory of how theform of data instances and classes shouldrelate to each other from a human userpoint of view.

Background

Most programming and specificationlanguages require a human or computerinterpretation of the statements in thoselanguages in order to produce or validatethe permissible form of a data instanceitem. Typically, the prescriptions containkeywords and constraints which may notmake it straightforward to validate theform of a given data item. Also, use ofdifferent word orders in the prescriptionsand the corresponding data instances cancontribute to these difficulties. This isexemplified in Figure 5. See details in [3]and [4].

Use of various kinds of inheritance (ofObject Class, Name Binding, Relation-ships, Packages, Attributes and datavalue types) can make it very difficult tovalidate forms of a data instance, aspieces of the prescription are spreadout on many remote statements.

The example in Figure 5 shows ObjectClass labels, Package labels and Attri-bute labels being defined in separate andindependent statements (and templates),which refer to each other. This use ofindependent templates requires that alllabels (circuitGroup, namePkg, name)are globally unique. If, alternatively, theAttribute Class were defined in-linewithin the Object Class template, e.g.


circuitGroup Object Classname Attribute Class,

then the Attribute Class label, e.g. name,could have been reused with a differentmeaning and different value set within adifferent Object Class label. This couldprovide a means to define name scopeswithin superior labels, and the prescrip-tion could get a structure identical to thatof its instances.

Note that name scoping in Predicate cal-culus is different from what is exempli-fied above; constants are globally unique,while variables are unique within thescope of their quantifier. Predicate cal-culus provides no means of definingterms (constants and variables) within thescope of superior terms. Also, Predicatecalculus provides no means of instantia-tion. However, it provides means to vali-date non-consistency – of p and ¬p. Notethat two unrelated statements p and q areconsistent. This is different from instanti-ation, as well, as instances are only per-missible if they are instances of someexplicitly defined class.

Principles

The following principles apply to thecorrespondence between data instancesand data classes as seen at the human-computer interfaces:

1 End users need access to data classesto validate their form prior to imple-mentation, for end user help and as anaccess means to data instances.

2 Data subordination (to other data, asindicated by indentation in the aboveexamples) should be used to definename spaces of data classes and datavalues; hence, (the end user form of)data are organised into data trees,where each data item has a superiordata item and can have several sub-ordinate data items – this applies toboth instances and classes.

3 The syntactical form of data classesshould be homomorphic to that of theirinstances, i.e. several instances can beof the same class, and if instance b issubordinate to instance a, then theclass of b must be subordinate to theclass of a, and if instance b has a refe-rence c to a, then the class of b musthave a reference c to the class of a; thehomorphism requirement implies thatclass labels are copied into instancesand appear in every instance, andimplies that significant duplicates arefrequently used.

4 The root node of a data instance tree isreferred to as a population relative tothe corresponding root node of its dataclass tree. This root node is referred toas a schema relative to a correspondingroot node of a data instance tree. Aschema may have several populations,and a population may have severalschemata – even if this is not typical.


Interpreter/compiler

Object Class circuitGroupCharacterized By namePkg

Package namePkgAttribute name

Attribute nameetc.

Prescription

Executableprocess

circuitGroupname

Validationresult

Classes

Data instances

Figure 5 Non-homomorphic classes. The example depicts lack of compliance betweenthe structure of data instances (e.g. circuitGroup containing name) and the corre-sponding specification containing prefix keywords (e.g. Object Class), extra constructs(e.g. Package), (lack of) indentations (e.g. of Attribute), and maybe word orders (e.g.Object Class statements, Package statements and Attribute statements in differentsections)

Termination

S

Graphic specifiation

(Station

P

SystemSchema

GroupGroup

Alphanumeric specifiation

Termination<>´´

S<>´´Group

Station

P<>´´(Population

PopulationGroup

GroupGroup

Group

GroupGroup

Station

Figure 6 Example system containing one population and its schema; recursion is usedto prescribe the Group hierarchy

5 Schema references can be made fromclass data to other data; hence, endusers may access class data andinstance data by the same means. Thisimplies that the syntactical form ofclasses and instances must be identical,and classes may not be marked withlabels like Object Class, AttributeClass, etc.

6 A schema reference can be used todefine recursion by referring to asuperior node in the data class tree.

7 Use of inheritance should be avoided,since this can be provided by themapping from Application to Externalschemata, while Schema references,including recursion, and data type refe-rences only are used within the pre-scription, e.g. the Application schema.

Figure 6 exemplifies how data may relateto each other in a data tree.

Rationale

The classification theory of human-com-puter interaction provides

• direct end user access to and inter-pretation of specifications withoutcomplex transformations and inter-pretations

• use of local labels in the formal speci-fications, being typical for headings atthe human-computer interfaces

• use of significant duplicates, beingtypical for graphic symbols at thehuman-computer interfaces

• definition of schema and populationdata relative to each other, providingequal access to population and schemadata

• avoidance of use of inheritance andinterpretation of its implications.

References

1 Meisingset, A. A data flow approachto interoperability. Telektronikk, 89(2/3), 52–59, 1993.

2 ITU-T. Data oriented human-machine interface specification tech-nique : scope, approach and refe-rence model. Geneva, ITU, 1993.(ITU-T Recommendation Z.352,03/93.)

3 ITU-T. Draft Recommendation Z.35xand Appendices to Draft Recommen-dations. Geneva, ITU, 1992. (CCITTCOM X-R 12.)

4 ITU-T. Draft Answers to Q1, 2 and3/10. http://www.itu.ch/Standardiza-tion, SG10, Reports/. Also publishedin: Meisingset, A. The HMI specifi-cation technique. Kjeller, TelenorR&D, 1996. (Report N 54/96.)


Arve Meisingset is Senior Research Scientist atTelenor R&D. He is currently working on informa-tion systems planning, formal aspects of human-computer interfaces and middleware standardi-sation. He is ITU-T SG10 Vice Chairman and theTelenor ITU-T technical co-ordinator.


Telecommunication service providersmaintain alliances through which theyresell each other’s services. By lever-aging the alliance’s reach and diver-sity, each alliance partner offers acomplete portfolio of global services toits customers.

Alliance success depends upon inter-operability among alliance partners.Therefore, the alliance must maintaina discipline through which alliancepartners exchange orders, troublereports, performance reports andusage reports. To this end, the Inter-national Telecommunications Unionspecifies the TelecommunicationsManagement Network (TMN) X Inter-face.

This paper presents an alliance app-roach to the TMN X Interface. Twoprinciples guide the alliance approach.First, the X Interface must not com-promise alliance partner autonomy.Second, the X Interface must facilitateinter-operability. Interface specifica-tions must be publicly available andthe interface must not be so complexas to preclude any organization fromjoining the alliance.

Introduction

Market demands motivate telecommuni-cations service providers (SPs) to reselleach other’s services. The resale agree-ment can include two or more SPs. In thesimplest case, a customer purchases ser-vice from a main service provider (MSP).As the MSP cannot support the serviceusing its own network resources, it estab-lishes a separate service agreement withanother SP. The MSP purchases servicefrom the SP and resells the service to itscustomer.

In the most complex case, a customerpurchases service from an MSP. TheMSP divides the service into com-ponents, determining that it can provideselected components while it cannot pro-vide others. The MSP provides selectedservice components and purchases theremaining components from one or moreSPs.

Each SP, in turn, divides the servicerequest that it receives into components.The SP can provide selected componentswhile it cannot provide others. Therefore,the SP provides selected service com-ponents and purchases remaining com-ponents from peer SPs.

Figure 1 illustrates both simple and com-plex resale.

In order to maintain the business arrange-ment described above, SPs must supporta suite of SP-to-SP protocols. ITU-TRecommendation M.3010 [1] identifiesthe SP-to-SP protocol suite as the XInterface.

This paper explores technical require-ments for the X Interface. It extends theX Interface framework presented in ITU-T Recommendation M.3320 [2].

The following sections provide indepen-dent views of the X Interface. The firstsection defines business requirements.The second presents inter-operabilityrequirements in terms of the Telecommu-nications Management Network (TMN).The third section identifies impedimentsto TMN development and the final sec-tion presents a pragmatic, alliance app-roach to the TMN X Interface.

Business Requirements

Seamless Service

The MSP must present a seamlessservice to the customer. In a seamlessservice, the customer maintains a singleservice agreement with the MSP and the

MSP manages service agreements withSPs on the customer’s behalf. The cus-tomer can, but need not, be aware thatSPs contribute to the service.

Typically, service agreements include thefollowing:

• Service activation scheduling require-ments

• Trouble reporting and trouble resolu-tion requirements

• Service availability requirements

• Quality of service requirements

• Performance reporting requirements

• Billing and pricing requirements.

Therefore, the X Interface must supportautomated exchange of the followinginformation between SPs:

• Order entry and order tracking infor-mation

• Trouble reporting and trouble manage-ment information

• Performance information (quality ofservice and service availability)

• Billing and usage information.

The X Interface may be extended tosupport the real-time exchange of serviceeffecting network events.

39

Alliance Approach to the TMN X InterfaceR O N A L D B O N I C A

Telektronikk 1.1998

Customer

MSP

SP SP SP SP SP

SP SP

MSPCustomer

Simple Resale Complex Resale

Figure 1 Simple Resale versus Complex Resale

Autonomy

Each SP is an autonomous fiscal entity.Therefore, each SP retains the right tomanage its own resources. For example,when an SP receives a request for ser-vice, that SP determines which resourceswill be assigned to the service and whenthose resources will be deployed. Therequesting organization cannot directlyallocate resources owned by the serviceproviding organization.

As each SP is an autonomous fiscalentity, each SP retains the followingrights:

• The right to maintain its own re-sources. Resources include networkresources and operational supportsystems.

• The right to operate its support sys-tems according to local policy. Forexample, each SP determines the hoursduring which its operational supportssystems are available and the hoursduring which they are off-line forpreventive maintenance.

• The right to maintain its own data baseof record. The data base of recorddescribes all services that the SP hasrequested through the X Interface orprovided in response to requestsreceived through the X Interface.

Although the SP acknowledges theexistence of another data base at theremote end of the X Interface, the SPviews its own data base as the “database of record”. SPs need not trusteach other to maintain a data base ofrecord.

• The right to specify the technologythat supports its enterprise. Therefore,the X Interface must specify a suite ofprotocols, not a suite of products.

Furthermore, the X Interface must besimple. Integration with SP operationalsupport systems must not be time con-suming or expensive. The X Interfacemust employ only the most commonlyavailable technologies. SPs should not berequired to embrace new, complex orexotic technologies in order to partake inthe X Interface.

Security

The X Interface must provide the follow-ing security features:

• authentication• non-repudiation• privacy.

Authentication assures a message re-ceiver of the message originator identity.It protects both the originator and thereceiver from malicious parties that mas-querade as the message originator.

Non-repudiation assures the messagereceiver that the message originator can-not deny having sent the message. Pri-vacy assures both the message originatorand the message receiver that unautho-rized third parties cannot access messagecontents.

TMN Requirements

TMN Overview

Recommendation M.3010 presents gene-ral architectural requirements for a Tele-communications Management Network(TMN). Figure 2 introduces TMN func-tional blocks and reference points.

M.3010 defines the following functionalblocks:

• Work Station Function (WSF) – “TheWSF provides the means to interpretTMN information for the managementinformation user.”

• Operations System Function (OSF)– “The OSF processes informationrelated to the telecommunicationsmanagement for the purpose of moni-toring/coordinating and/or controllingtelecommunications functions in-cluding the management function.”

• Network Element Function (NEF)– “The NEF is a functional blockwhich communicates with the TMNfor the purpose of being monitoredand/or controlled.”

• Q Adaptor Function (QAF) – “TheQAF block is used to connect as partof the TMN those non-TMN entitieswhich are NEF-like and OSF-like.”

• Mediation Function (MF) – “The MFblock acts on information passing fromthe OSF to the NEF (or QAF) toensure that the information conformsto the expectations of the functionblocks attached to the MF.”

M.3010 also defines the q, x, f, m, and greference points. A similarly namedinterface (Q, X, F, M and G) serviceseach reference point. The q and x refe-rence points are relevant to this paper.


WSF

OSF

MF

TMN

QAF NEF

f

f q3

qx

qxqx

q3

q3

q3

g

m

WSF

OSF

MF

TMN

QAFNEF

f

fq3

qx

qxqx

q3

q3

q3

g

m

x x

Figure 2 Illustration of Reference Points Between Management Function BlocksFrom CCITT M.3010, Figure 5/M.3010

M.3010 defines the q reference point asfollows:

The q reference points serve to deline-ate a logical part of the informationexchange between function blocks asdefined by the information modelmutually supported by those functions.

M.3010 identifies two q reference pointsubclasses. These are the q3 subclass andthe qx subclass.

By contrast, M.3010 defines the xreference point as follows:

The x reference points are located be-tween the OSF function blocks in diffe-rent TMNs. Entities located beyond thex reference point may be part of anactual TMN (OSF) or part of a non-TMN environment (OSF-like). Thisclassification is not visible at the xreference point.

Although M.3010 states that “the proto-col definition should seek to minimizethe difference between TMN interfaces”,it also recognizes that the Q and X Inter-faces are not identical. The X Interfacemust support the above stated businessrequirements, particularly those require-ments that address autonomy and secu-rity.

In order to support above stated require-ments, the TMN framework specifiesthat the Q and X Interfaces typicallyoperate upon unique subsets of the man-agement information model. Further-more, the TMN framework supportsmultiple communications services acrossboth the Q and X Interfaces.

Management InformationDomains

The Q and X Interfaces typically operateupon unique subsets of the TMN infor-

mation model. The TMN frameworkdivides OSFs and the information modelelements into the following layers:

• Element management layer (EML)– “The EML manages each networkelement on an individual basis andsupports an abstraction of the functionsprovided by the NE (network element)layer.”1

• Network management layer (NML)– “The NML has the responsibility forthe management of all network ele-ments, as presented by the EML, bothindividually and as a set. It is not con-cerned with how a particular elementprovides services internally.”

• Service management layer (SML)– “The service management layer isconcerned with, and responsible for,the contractual aspects of aspect of theservices that are being provided tocustomers or are available to potentialnew customers.”

• Business management layer (BML)– “The business management layer hasthe responsibility for the total enter-prise and is the layer at which agree-ments between operators are made.This layer normally carries out goalsetting tasks rather than goal achieve-ment, but can become the focal pointfor action in cases where executiveaction is called for.”

Figure 3 illustrates layered OSFs com-municating through the Q Interface. Inthe figure, the Business OSF causes theService OSF to create, modify anddestroy service layer objects by sendingmessages across the Q Interface. TheBusiness OSF also causes the ElementManagement OSF to create, modify anddestroy element management layerobjects by sending messages across theQ Interface.

By contrast, the X Interface is typicallyrestricted to communication between ser-vice layer OSFs. Using the X Interface,an MSP causes an SP to manipulate ser-vice layer objects within the SP domain.The SP service layer OSF causes the SPnetwork layer OSF to manipulate SP net-work layer objects by sending messagesthrough the Q Interface.


1 As the network element layer residesoutside of the OSF domain, it is notincluded in this list.

OSF

MF

NEF

q3

OSF

OSF

OSF

q3

q3

q3

q3

q3

BusinessOSF

ServiceOSF

NetworkOSF

ElementManagementOSF

NEFunctions

BusinessManagementLayer

ServiceManagementLayer

NetworkManagementLayer

NetworkElementManagementLayer

NetworkElementLayer

Figure 3 Example of a TMN OS functional hierarchyFrom M.3010 Figure II-1/M.3010

Therefore, the MSP cannot determinewhen or how the SP realizes the servicein terms of network layer objects. The SPretains functional autonomy.

Restricting the X Interface to servicelayer interactions insulates the MSP fromSP network and network element layerdetails. Technical autonomy is enhancedin that the MSP and SP can model thenetwork and network element layers dif-ferently, without affecting their ability tointeract at the contractual, service layer.Figure 4 illustrates SPs (in this case,value added service providers) inter-acting at the service layer.

The TMN framework permits the servicelayer of one TMN to communicate with alower layer of another TMN when theproblem domain permits. For example,the service layer of one TMN may com-municate with the network layer of an-other TMN when functional autonomybetween TMNs is not required and whenit is not economical to build a servicelayer OSF in the second TMN.

M.3010 warns that “implementation ofsuch an architecture may require verystrong access control mechanisms.”Figure 5 illustrates inter-layer communi-cation across the X Interface.

Communication Services

Recommendation M.3320 states that thefollowing communication services areavailable to the TMN X Interface:

• Interactive Services• File Transfer Services• Directory Services• Store and Forward Services.

Interactive Services

Using interactive services, SPs accessobjects that reside within each other’sdomains. As the name implies, inter-active services support near-real-timeaccess. In order to support interactiveservices, SPs maintain a manager/agentrelationship.

Figure 6 illustrates the manager/agentrelationship. In the figure, the managedsystem maintains managed objects andagent software. Managed objects providean abstracted view of a managedresource. For example, if the managedresource is a frame relay switch, man-aged objects might represent frame relaypermanent virtual circuits. Agent soft-ware accesses managed resources inorder to maintain managed objects.

Agent software represents managedobjects through a hierarchic data struc-ture called the Management InformationTree (MIT). The manager and agent mustagree upon the structure of managedobjects before communicating throughthe interactive service. An ASN.1 Man-agement Information Base (MIB) defini-tion formalizes the structure of managedobjects.

In order to access managed objects, themanager sends messages to the agent.The agent, in turn, performs managementoperations on the manager’s behalf.

According to Recommendation Q.812[3], the Common Management Informa-tion Service Element (CMISE) [4] pro-vides interactive services for the TMN XInterface. The following is a list ofCMISE primitives:

• M-CREATE – create a managed objectinstance

• M-DELETE – destroy one or moremanaged object instances

• M-GET – retrieve selected attributesfrom one or more managed objectinstances

• M-SET – modify selected attributes forone or more managed object instances

• M-ACTION – perform an object spe-cific operation upon one or moremanaged object instances

• M-CANCEL-GET – cancel a pre-viously issued M_GET operation

• M-EVENT-REPORT – register fornotification when one or moremanaged object instances change.

Most CMISE primitives operate uponone or more managed object instances.In order to specify which instances theprimitive operates upon, the manager“scopes” its requests. Scoping reliesupon the hierarchic nature of manage-ment information.


OSF

OSF

TMN3

OSF

MF

NEF

OSF

OSF

OSF

q





NetworkElementLayer

OSF

OSF

OSF

OSF

TMN2

TMN1

xx

Figure 4 Examples of Value Added ServicesFrom M.3010 Figure II-2/M.3010

When the manager issues a request, itspecifies a point on the hierarchic MIT,called the base object. It also specifies towhich of the following the requestedaction should be applied:

• the base object only

• the (n)-level subordinated to the baseobject

• the base object and all of its sub-ordinates down to and including the(n)-level

• the base object and all of its sub-ordinates.

The manager can exempt selected objectinstances from the operation by “filter-ing”. For example, using a singleM_DELETE primitive, a manager candestroy all object instances subordinateto a base object except those with attri-bute “A” equal to five.

The manager/agent relationship is asym-metric. For example, only the managercan issue an M-CREATE request. Inorder to support symmetric relationships,both systems (managed and managing)must be equipped with both manager andagent software.

Figure 7 depicts upper layer protocolprofile for interactive services.

File Transfer Services

SPs access each others files using the filetransfer service. Specifically, SPs exe-cute the following actions upon files thatreside in another SP’s domains:

• Create/delete file

• Read file attributes (e.g., creation time,last modification time)

• Open/close file

• Read/write contents.

Recommendation Q.812 identifies thefile transfer service for the TMN-X Inter-face as being provided by File Transfer,Access and Management (FTAM) [5].Specifically, the following FTAM filestructures are supported across the XInterface:

• Unstructured text files (FTAM-1 docu-ment type)

• Unstructured binary files (FTAM-3document type)

• Sequentially ordered files (NBS-6document type).

Because the X Interface supports onlythe above listed file structures, FTAMrandom access capabilities are not avail-able at the X reference point. (FTAMrandom access capabilities apply only todocument types FTAM-2 and FTAM-4documents.)

Figure 8 depicts upper layer protocolprofile for file transfer services.

Directory Services

The directory service allows distributionof management information over a poten-tially unlimited number of OSI end sys-tems. Despite its physical distribution,the end user or application invoking thedirectory service perceives managementinformation as a single physical unit.


OSF

OSF

TMN3

OSF

MF

NEF

OSF

OSF





NetworkElementLayer

OSF

OSF

TMN1

TMN2 x

x

Figure 5 Examples of Inter-TMN OS functional connectivityFrom M.3010 Figure II-3/M.3010

ManagerManagement operations

Notifications

Agent

PerformingmanagementoperationsNotificationsemitted

Local systemenvironment Managed

object

Managingopen system Communicating Managed open system

Figure 6 Interaction between Manager, Agent and objectsFrom M.3010 Figure 8/M.3010

Recommendation Q.812 defines thedirectory services for the TMN-X Inter-face as being provided by the X.500series of recommendations.

Store and Forward Services

Although Recommendation M.3320states that store and forward services areavailable to the X Interface, it providesno specifics. Therefore, the current docu-ment provides a generic description ofstore and forward services.

When an application submits a protocoldata unit (PDU) to the store and forwardservice, the store and forward serviceexecutes the following actions:

• Assign a sequence number to the PDU.

• Commit the PDU and sequencenumber to persistent storage

• Return the sequence number to theapplication.

When the application receives thesequence number, it is certain that thePDU will be delivered to the remoteapplication as soon as possible. It is alsocertain that PDUs will be delivered to theremote application in the same order inwhich they were submitted to the localstore and forward service entity.

Although the application can query thePDU delivery status, it cannot retract thePDU from the store and forward entity.The following is a list of PDU deliverystatus:

• Pending transmission – the PDU isawaiting transmission from the localstore and forward entity to the remotestore and forward entity.

• Pending delivery – the PDU has beenreceived and made persistent by theremote store and forward entity. It isawaiting delivery to the remote appli-cation.

• Delivered – the PDU has been de-livered to the remote application.

Impediments to a TMN XInterface

The communication services describedabove are feasible if all SPs maintain adata base of record that is organizedaccording to TMN sanctioned informa-tion models. In this case, the mappingbetween data base of record and manage-ment information tree is trivial. The


FTAM (ISO 8571)

Layer 7

ACSEX.227, ISO 8650

(X.217, ISO 8649)

ISO Presentation Layer

X.209, ISO 8826 BERkernel

X.226, ISO 8323(X.216, ISO 8822)

ISO Session Layer

kernel, duplexX.225, ISO 8827

(X.215, ISO 8326)

X.224, ISO 80738073/AD2

X.224, ISO 8073

Layer 6

Layer 5

Layer 4

Figure 8 Protocol profile for network management whichuses file transfer

From Q.812, Figure 2/Q.812

SMASEs (further study)

Layer 7CMISE

ISO 9596-1,Version 2ISO 9595-1,Version 2

ROSEX.229, ISO IS 9072-2

(X.219, ISO IS 9072-1)

ACSEX.227, ISO 8650

(X.217, ISO 8649)

ISO Presentation Layer

X.209, ISO 8826 BERkernel

X.226, ISO 8823(X.216, ISO 8822)

ISO Session Layer

kernel, duplexX.225, ISO 8327

(X.215, ISO 8326)

X.224, ISO 80738073/AD2

X.224, ISO 8073

Layer 6

Layer 5

Layer 4

Figure 7 Protocol profile for network management whichuses transaction function

From Q.812, Figure 1/Q.812

CMISE agent simply provides remoteaccess.

Unfortunately, many SPs do not maintaina data base of record that is organizedaccording to TMN sanctioned informa-tion models. The following are commoncauses of deviation:

• Many SPs maintain legacy systemsthat pre-date TMN sanctioned infor-mation models.

• Market pressures motivate SPs to pro-vide services before standards bodiescodify a corresponding informationmodel.

• Support systems distinguish them-selves from one another throughunique data base organizations.

Therefore, the CMISE agent must imple-ment complex adaptation functions inorder to compensate for the “impedancemismatch” between data base of recordand management information tree. Typi-cally, adaptation function development isvery costly and adaptation software is notreusable.

The impedance mismatch problem iswell known to CMISE application de-velopers. Because of the impedance mis-match problem, many CMISE agents donot implement scoping, filtering, or eventforwarding registration.

An Alliance Approach

Having examined SP business require-ments and TMN inter-operability re-quirements, we can formulate a prag-matic, alliance approach to the TMN XInterface. The alliance approach extends,but does not deviate from, the canonicalTMN X Interface described above.

The alliance approach contains informa-tion, management protocol and transportaspects. Information aspects addresswhich objects are to be shared by SPsthrough the X Interface. Managementprotocol aspects address how SPs coordi-nate management functions (e.g., ordermanagement, trouble management).Communication aspects address how SPscommunicate with each other.

Information Aspects

Objects shared through the X Interfacemust be sufficiently well defined that SPscannot misinterpret their meaning. In

order to achieve the required level ofspecificity, each object definition mustinclude the following:

• A concise textual description

• A complete list of attributes, with aconcise textual definition for eachattribute

• A complete list of methods, with aconcise textual definition for eachmethod.

Concise object modeling is a monu-mental task. As object model size in-creases, so do the following:

• the probability that the object modelcontains one or more imprecisely de-fined objects

• the probability that the object model isinternally inconsistent

• the probability that some aspect of theobject model will be misunderstood byan SP.

Therefore, the object model sharedthrough the X Interface must include asfew objects as possible. In order torestrict model size, as well as preserveSP autonomy, shared objects must berestricted to the TMN service layer.

Each object shared across the TMN XInterface is categorized as either servicespecific or service independent. Servicespecific objects define the services thatSP purchase from one another. They con-tain contractual attributes, configurableattributes, performance attributes andusage attributes.

Contractual attributes define service type,service availability dates, service avail-ability requirements (e.g., mean time be-tween failures) and quality of servicerequirements. Each contractual attributecontributes to the service price. Con-figurable attributes specify additionalservice definition parameters that do notcontribute to service price.

Performance attributes define metrics foravailability and quality of service. Usageattributes define metrics for usage basedbilling.

Each time the SP community agrees tosupport a new service through the TMNX Interface, it must define at least onenew service specific object. The SP com-munity should seek object modelingguidance from the most widely acceptedstandards. For example, the objects that

describe Internet service should resembleMIB-II [6].

Service independent objects representgeneric operations between SPs. Serviceindependent objects include the follow-ing:

• Order• Trouble report• Performance report• Usage report.

Service independent objects should bedefined by international standards when-ever possible. For example, ITU-TRecommendation X.790 [7] defines thetrouble report and several associatedobjects (e.g., contact).

If widely accepted international stan-dards are not available, the SP commu-nity should define service independentobjects with guidance from emergingstandards. For example, the Open ServiceLayer Protocol [8] draws upon ITU-TDraft Recommendation M.3208.1 [9] andemerging Network Management Forumproposals in order to define the orderobject.

Above all, service independent objectsmust be simple. They must supportsimple management protocols.

Management Protocol Aspects

The X Interface must support single stateand multi-state protocols. Single stateprotocols support automated exchange ofperformance and usage information.Single state protocol supports the follow-ing scenario:

• The SP creates a service independentobject within its own data base ofrecord. The service independent objectrepresents a performance report orusage report.

The SP also creates zero or more ser-vice dependent service objects. It asso-ciates the service independent objectswith the service dependent object.

• The SP sends a message to the MSPinforming the MSP that the newobjects have been created.

• The MSP creates identical objectswithin its data base of record.

• The MSP sends a confirmation mes-sage to the SP.


In a single state protocol, the SP can sendmessages to the MSP in batch mode. Inthis case, the MSP can confirm receptionof the entire batch with a single message.

Multi-state protocols support the follow-ing scenario:

• The MSP creates a service independentobject within its own data base ofrecord. The service independent objectrepresents an order or trouble report.

The MSP also creates zero or moreservice dependent objects. It associatesthe service independent objects withthe service dependent object.

• The MSP sends a message to the SPinforming the SP that the new objectshave been created.

• The SP creates identical objects withinits data base of record.

• The SP processes the objects containedby its data base of record according tolocal policy. It updates object statusand engineering details as appropriate.

• Each time the SP updates the objectscontained by its data base of record, itsends a status update message to theMSP. Each status update messagecontains a status indication and allengineering detail specified by the SP.

• The MSP receives the status updatemessage and updates the correspond-ing objects in its data base of record.

• When the MSP receives a statusupdate message that indicates the orderhas been completed or the troubleticket has been closed, the MSP sendsthe SP a message indicating whether ornot it is satisfied with how the manage-ment operation has been executed.

Once the MSP sends its initial messageto the SP, the MSP’s ability to communi-cate with the object contained by the SPdata base of record is extremely limited.Specifically, the MSP can

• monitor status update messages sentfrom the SP

• synchronize its copy of the data baseobject with the SP copy by requestinga retransmission of the last statusupdate message

• send a message to the SP that appendsfree form text to the object. Themessage can also escalate an issueor defer a trouble ticket.

In order to modify or cancel a manage-ment operation (i.e., order or troubleticket), the MSP must create a new objectwithin its data base of record. The newobject supersedes or cancels the originalobject. The MSP sends a message to theSP and the SP creates an identical objectwithin its data base of record. The SPprocesses both objects according to thescenario described above.

Multi-state protocols minimized theimpedance mismatch effect that ischaracteristic of CMISE. SPs executeonly a few course-grained operationsupon objects that reside in each othersdomain. Therefore, SPs need not imple-ment complex adaptation functions thatmap every possible view of their man-agement information tree to their database of record. SPs implement only asmall set of adaptation functions thatsupport object creation, status updatereporting, and operation closure.

The Open Service Layer Protocol(OSLP) is a multi-state protocol that sup-ports ordering. The Open Trouble Man-agement Protocol (OTMP) is a similarmulti-state protocol that supports troublemanagement. OSLP is presented in an-other paper [8] in this issue of Telektro-nikk, while OTMP is not yet published.

Communication Aspects

The Basic Encoding Rules (BER) de-scribed in ITU-T RecommendationX.209 [10] provide OSI presentationlayer services to both single state andmulti-state protocols.

All currently defined single state proto-cols send BER encoded messagesthrough the file transport service whileall currently defined multi-state protocolssend BER encoded messages through thestore and forward service. In the future,however, new single state protocols thatemploy store and forward services maybe developed. Similarly, new multi-stateprotocols that employ file transfer ser-vices may be developed.

The File Transfer Protocol (FTP) de-scribed in IETF RFC 959 [11] providesfile transfer services to upper layer appli-cations. This augmentation to the com-munication services described in Q.812is justified by the following arguments:

• FTP provides services commensuratewith those provided by the FTAM sub-set profiled in Q.812.

• FTP is available in the public domain.

• FTP has gained much wider commer-cial acceptance than FTAM.


PerformanceTBD

ISO Presentation LayerX.209, ISO 8826 BER

Transmission Control ProtocolIETF RFC 793

OSLP

OTMP UsageTBD


APT Store & Forward File Transfer ProtocolIETF RFC 959

Internet ProtocolIETF RFC 791

Figure 9 Unified View of the Alliance Approach to theTMN X Interface

Store and forward services are providedby the Alliance Point-to-Point TransportProtocol (APT). APT is defined in theOSLP documentation suite.

Lower layer services are provided by theTransmission Control Protocol (TCP)[12] and the Internet Protocol (IP) [13].

As stated in Recommendation M.3320,SPs maintain pair-wise agreements re-garding encryption and security adminis-tration. Because each SP is constrainedby its national security and encryptionpolicy, it may not be possible to specify asingle, global security policy.

Figure 9 depicts a unified view of thealliance approach to the TMN X Inter-face.

Conclusions

The X Interface approach proposedherein is an expedient solution. Althoughit is less robust than the canonical imple-mentation described in RecommendationM.3320, it permits SPs to reap benefitsfrom the TMN architecture in the shortterm.

References

1 ITU-T. Principles for a Telecommu-nications Management Network.Geneva, ITU, 1992. (ITU-T Recom-mendation M.3010.)

2 ITU-T. Management RequirementsFramework for the TMN X Interface.Geneva, ITU, 1997. (ITU-T Recom-mendation M.3320.)

3 ITU-T. Upper Layer Protocol Pro-files for the Q3 and X Interface.Geneva, ITU, 1996. (ITU-T Recom-mendation Q.812.)

4 ISO. Information Processing Systems: Opens Systems Interconnection :Common Management InformationProtocol Specification (CMIP).Geneva, 1995. (ISO 9595-1 version2.)

5 ISO. Information Processing Systems: Open Systems Interconnection :File Transfer, Access and Manage-ment, Part 1: General Introduction.Geneva. (ISO 8571-1.)

6 IETF. Management Information Basefor Network Management of TCP/IP-

based internets. MIB-II, 3/91. (RFC1213.)

7 ITU-T. Trouble Management Func-tion for ITU-T Applications. Geneva,ITU, 1995. (ITU RecommendationX.790.)

8 Bonica, R P. Open Service LayerProtocol (OSLP). Telektronikk, 94(1), 48–54, 1998 (this issue).

9 ITU-T. TMN Management Servicesfor Dedicated and ReconfigurableCircuits Network : Leased CircuitServices. Geneva, ITU, 1997. (ITU-TDraft Recommendation M.3208.1.)

10 ITU-T. Specification of Basic Enco-ding Rules for Abstract Syntax Nota-tion One (ASN.1). Geneva, ITU,1988. (ITU-T RecommendationX.209.)

11 IETF. File Transfer Protocol (FTP).1985. (RFC 959.)

12 IETF. Transmission Control Proto-col. 1981. (RFC 793.)

13 IETF. Internet Protocol. 1981. (RFC791.)


Ronald P. Bonica is a member of the MCI InternetEngineering Team. He is currently under contractto the Concert Frame Relay Team and partici-pating in the Concert Alliance Interface Standardseffort. His interests are TMN and Internet archi-tecture.



Market demands motivate telecommu-nications service providers to reselleach other’s services. In order tomanage the resale environment, ser-vice providers must agree upon a suiteof protocols through which they canexchange management information.The protocol suite must support ordermanagement, trouble management,performance reporting and usagereporting.

The Telecommunications ManagementNetwork (TMN) X Interface addressesthe required protocol suite in generalterms. Another article in this issue ofTelektronikk proposes “an allianceapproach” to the protocol suite. Thispaper presents the Open Service LayerProtocol (OSLP), an order manage-ment protocol that applies the allianceapproach to the TMN X Interface.

OSLP services are organized intolayers. The lower layer provides astateless protocol through which ser-vice providers exchange order infor-mation. The upper layer is a signifi-cant extension to the TMN X interfacein that it maintains persistent informa-tion concerning the state of subcon-tracted orders.

Introduction

OSLP supports the automated exchangeof ordering information across ServiceProvider (SP) boundaries. It complieswith the Alliance Approach to the TMNX Interface [1].

OSLP maximizes inter-operability andautonomy among SPs. It maximizesinter-operability by specifying a conciseservice order syntax. The concise serviceorder syntax includes a service indepen-dent component and many service speci-fic components. The service independentcomponent codifies a generic orderobject. The generic order object specifiesall order attributes and the states throughwhich each order must progress en routeto completion. The service independentcomponent also specifies several genericobjects that are associated with orders(i.e., contact, location).

A service specific component describeseach service that SPs offer to one an-other. For example, one service specificcomponent describes the frame relayservice, while another describes the IPservice. Service specific componentsinclude all service configuration para-meters (e.g., bandwidth, quality ofservice).

OSLP contributes to SP autonomy bymaintaining an environment in whicheach SP retains the following rights:

• The right to manage its own networkresources. Although SPs request ser-vices using OSLP, they cannot dictatewhich network resources will supportthe service or when those resourceswill be deployed.

• The right to operate its support sys-tems according to local policy. Forexample, each SP determines the hoursduring which its operational supportssystems are available and the hoursduring which they are off-line. OSLPadapts by sending each messagethrough a point-to-point store andforward service.

• The right to security. OSLP messagesare encrypted to ensure authentication,non-repudiation and privacy.

• The right to maintain its own data baseof record. An SP’s data base of recorddescribes all services that the SP hasrequested via OSLP or provided inresponse to OLSP requests.

Although the SP acknowledges theexistence of another data base at theremote end of the OSLP interface, theSP views its own data base as the “database of record”. SPs need not trusteach other to maintain an accurate database of record.

• The right to progress orders as perlocal policy. Although OSLP defines ageneric order object and the statesthrough which orders progress en routeto completion, it does not specifywhich activities occur in each state.

• The right to specify the technologythat supports its enterprise. As OSLPrestricts itself to communication re-garding TMN service layer objects,SPs are free to model business, net-work and network element layerobjects as per local policy.

Furthermore, OSLP relies upon onlythe most widely accepted standards(e.g., TCP, IP) for lower layer services.SPs need not embrace new, costly orexotic technologies in order to imple-ment OSLP.

The following sections describe signifi-cant aspects of OSLP.

The OSLP BusinessRelationship

OSLP formalizes the business relation-ship depicted in Figure 1. In the figure,the customer contracts with a main ser-vice provider (MSP) for service.

The MSP submits an order to its localservice layer operation systems function(SL-OSF). The MSP’s SL-OSF dividesthe order into service components andidentifies components that the MSP canprovide using its own network resources.The MSP network might provide allcomponents, selected components, or nocomponents.

The MSP’s SL-OSF sends a request forlocally provided components to a localnetwork layer operation systems function(NL-OSF). The MSP’s NL-OSF provi-sions and manages the locally providedservice components as per local policy.

The MSP’s SL-OSF also identifies ser-vice components that the MSP cannotprovide using its own network resources.Using OSLP, the MSP orders those ser-vices from a peer service provider (SP).

The Open Service Layer Protocol (OSLP)R O N A L D B O N I C A

SL-OSF

NL-OSF

Network

config

trouble

perform

billing

OSLP

Customer

SL-OSF

NL-OSF

Network

config

trouble

perform

billing

OSLP

MSP SP

Figure 1 The MSP/SP Relationship


When the SP SL-OSF receives its OSLPorder, it determines whether its local net-work can fulfil the entire request. If so,the SP SL-OSF sends a message to itslocal NL-OSF. The SP’s NL-OSF pro-visions the order as per local policy.

When the SP’s NL-OSF fulfils therequest, it sends a completion message toits local SL-OSF. The SP SL-OSF re-ceives the completion message and sendsan OSLP completion message to theMSP’s SL-OSF. The MSP accepts theservices and the SP bills the MSP forservices rendered.

When the MSP SL-OSF receives com-pletion messages from the SP’s SL-OSF

and its local NL-OSF, it reports servicefulfilment to the customer. The customeraccepts the service and the MSP bills thecustomer.

OSLP messages contain TMN servicelayer objects only. Therefore, the MSPcan request services using OSLP, butcannot dictate which network resourceswill support the service or when those

resources will be deployed.

OSLP messages describe serviceconnections and service end-points. A service endpoint is aninterface through which a partyoutside of the SP network inter-face interfaces with the SP net-

work. User-to-network interfacesimplement an endpoint through whichusers interface with the SP network. Net-work-to-network interfaces implement anendpoint through which peer networksinterface with the SP network.

OSLP messages never describe how anSP connects endpoints within its ownnetwork, because TMN assigns suchdetails to the network layer. OSLP mes-sages never include internal implementa-tion or routing details.

OSLP codifies only those messages thatpass between the MSP’s SL-OSF and theSP’s SL-OSF. Organizations can imple-ment their internal service layer to net-work layer interface using either proprie-tary protocols, the canonical Q3 Interface[2] or an OSLP variant that addressesnetwork layer objects.

Subcontracting Relationships

SPs receive requests for services thatthey cannot provide using their

own network resources. Whenan SP receives such a request,it can either reject or subcon-tract the request. If the SPrejects the request, it sends anOSLP message to the MSPindicating order rejection.

If the SP subcontracts the request, itexecutes the following procedure:

• Divide the request into com-ponents

• Identify service componentsthat the local network cansupport

• Send a request for locally supportedcomponents to the local NL-OSF

• Identify a secondary SP for the re-maining service components

• Send an OSLP service request to thesecondary SP

• Send the MSP an OSLP messageinforming it of the subcontractingarrangement

• Receive an OSLP completion messagefrom the secondary SP

• Send an OSLP acceptance message tothe secondary SP

• Receive a completion message fromthe local NL-OSF

• Send an OSLP completion message tothe MSP.

In short, the primary SP maintains anoriginal contract with the MSP and a sub-contract with the secondary SP. Theprimary SP assumes the SP role withrespect to the original contract and theMSP role with respect to the subcontract.

Figure 2 depicts the subcontracting rela-tionship.

Complex and RecursiveSubcontracting

In the example above, the primary SPrequests services from a single secondarySP. In complex cases, the primary SPdivides the original request into manyparts and requests service components

Figure 2 Subcontracting

SecondarySP

MSP Role

PrimarySP

MSP

SP Role

MSP Role

SP Role

OriginalContract

Sub-contract

SecondarySP

MSP Role

PrimarySP

MSP

SP Role

MSP Role

SP Role

OriginalContract

Sub-contract

SecondarySP

MSP Role

SP Role

Sub-contract

Figure 3 Complex Subcontracting Figure 4 Recursive Subcontracting

PrimarySP

TertiarySP

MSP Role

MSP

SP Role

MSP Role SP Role

OriginalContract

SecondSub-contract

MSP Role

SP Role

SecondarySP

FirstSub-contract


from two or more secondary SPs. Figure3 illustrates complex subcontracting.

Furthermore, the subcontracting rela-tionship is recursive. The secondary SPcan subcontract services from yet anotherSP. Figure 4 illustrates recursive subcon-tracting.

All subcontracting details are relayedupstream to the MSP.

OSLP Services

OSLP services are organized into the fol-lowing layers:

• Primitive services (provided by the lower layer)

• Subcontracting services (provided by the upper layer).

Primitive services are stateless. AlthoughMSP and SP applications employ primi-tive services to exchange order informa-tion, the OSLP primitive layer does notmaintain a data base of outstandingorders. MSP and SP applications mustmaintain a data base of outstandingorders and manage these orders as perlocal policy.

OSLP provides one set of primitive ser-vices to MSPs and another set of primi-tive services to SPs.

Subcontracting services are statefull.When a primary SP divides an incomingorder into components and subcontractseach component to a secondary SP, theprimary SP’s OSLP subcontracting layerrecords the incoming order and all com-ponent orders in a local data base. Theprimary SP’s subcontracting layer alsoforwards all component orders to thesecondary SPs.

When secondary SPs achieve provision-ing milestones, they update their orderstatus and send the primary SP an OSLPmessage notifying it of the update. Theprimary SP’s OSLP subcontracting layerexecutes the following actions:

• Update the component order status inthe local OSLP data base

• Re-evaluate the status of the originalorder received from the MSP

• Store the original order status in thelocal OSLP data base

• Send the MSP an OSLP message indi-cating the original order status and thestatus of all component orders

• Inform the primary SP’s higher levelapplications of new order status.

The subcontracting service constitutes asignificant extension to the canonicalTMN X Interface. Specifically, the sub-contracting service introduces the con-cept of a statefull, persistent transaction.Although the subcontracting service isoptional, it is useful to SPs that engage insubcontracting.

OSLP MSP Services (Primitive Layer)

OSLP provides the following services toMSPs:

• MSPs create, modify and cancel ordersusing OSLP.

• MSPs annotate orders with free formtext using OSLP.

• MSPs escalate and de-escalate order-ing issues using OSLP.

• MSPs query order status using OSLP.

• OSLP notifies the MSP when SPscompletes provisioning milestones.

• MSPs accept completed services usingOSLP.

• OSLP notifies the MSP when an SPunilaterally re-engineers a service.

• OSLP notifies the MSP when an SPannotates an order with free form text.

• OSLP notifies the MSP when the SPrequests de-escalation.

Order Creation

MSPs create the following order types:

• Bid request• Provisioning request.

SPs respond to a bid request with the fol-lowing:

• An estimated completion date (manda-tory)

• Engineering details (supplied at SPdiscretion)

• A price (supplied upon MSP request).

SPs respond to a provisioning request byprovisioning and testing the requestedservice. SPs inform the MSP each time aprovisioning milestone is completed.

Each order, regardless of type, containszero1 or more service components. Eachservice component contains an action,service independent details, and servicespecific details.

MSPs request the following serviceactions:

• Install a new service• Change an existing service• Discontinue an existing service.

MSPs specify the following service inde-pendent details for each service:

• Service identifiers (e.g., access circuitidentifiers)

• Service type (e.g., IP access, X.25access)

• Contact details

• Billing details.

A single OSLP order can contain compo-nents that specify different actions andservice types. For example, an MSP canrequest the following using a singleOSLP order:

• Installation of an IP service• Discontinuation of an X.25 service• Modification of a frame relay service.

The SP cannot charge for any componentof an order until all components of orderare complete and accepted by the MSP.

Using OSLP orders, the MSP can queuemultiple actions against a single service.For example, on a single day, an MSPcan:

• Schedule a circuit for installation inJanuary

• Schedule the same circuit for upgradein February

• Schedule the circuit for disconnectionin March.

Order Modification and Cancellation

MSPs create orders that supersede orcancel other orders. The SP respondstwice. First, the SP responds to the initialorder, specifying that it is aborted atMSP request. Next, the SP responds to

1 A supplier might place an order withno service components in order toupdate contact information.


the modifying or canceling order, speci-fying that it is in progress or complete.

OSLP does not permit MSPs to modifyor cancel orders directly. MSPs mustissue a new order that supersedes orcancels an existing order.

Order Annotation

MSPs can append annotations (i.e., freeform text) to an order at any time. OSLPforwards the annotations to the supplier.

Using annotations, MSPs can escalateordering issues to the SP’s management.MSPs can also de-escalate issues whenthey have been notified that the issue hasbeen resolved.

OSLP notifies the MSP of annotationsgenerated by the SP. OSLP also notifiesthe MSP when the SP requests de-escala-tion.

Order Status Inquiry

MSPs query the status of their orders bysending the SP an OSLP message. SPsrespond to the OSLP query by re-evalu-ating the order’s status and sending anOSLP status update message to the MSP.The OSLP status update message in-cludes all service details that were pro-vided by the SP, including the orderstatus.

Milestone Notification / Order Status Update

OSLP notifies MSPs when SPs achievethe following provisioning milestones:

• The SP has claimed the order. The SPwill fulfil the order without subcon-tracting.

• The SP has distributed the order. TheSP will fulfil the order, but has sub-contracted some or all of the order tosecondary SPs.

• The SP has subcontracted the order.The SP will fulfil the order, but hassubcontracted some or all of the orderto secondary SPs. The secondary SPs(or their SPs) have claimed their por-tions of the order.

• The SP has engineered the order. Forexample, the SP has assigned accessports.

• The SP has completed the order. It hasprovisioned and tested the service.

• The SP has failed the order due toorder ambiguity or inability to providethe requested service.

• The SP has aborted the order at theMSP’s request.

Order Acceptance / Rejection

After OSLP notifies the MSP that the SPhas provisioned and tested the service,the MSP must either accept or reject theservice within a configurable timeperiod. If the MSP accepts the service orfails to take action within the configur-able time period, the SP initiates thebilling process.

If the MSP rejects the service, the MSPand SP must negotiate the issue outsideof OSLP. Typically, the SP resolves theproblem, and the MSP accepts the ser-vice at a later date.

Re-engineering Notification

OSLP notifies the MSP when an SP uni-laterally re-engineers a service. The SPcan re-engineer the service in response toa failure condition or in conjunction witha network grooming effort. The SP alsocan re-organize support staff, assigningnew support contacts to a service.

SP Services (Primitive Layer)

OSLP provides the following services tosuppliers:

• OSLP notifies the SP of incomingorders.

• SPs notify the MSP of milestone com-pletion using OSLP.

• OSLP notifies the SP of incomingstatus inquires.

• SPs respond to status inquires usingOSLP.

• OSLP notifies the SP when the MSPaccepts service order completion.

• SPs notify the MSP of unilateral ser-vice re-engineering using OSLP.

• SPs annotate orders with free form textmessages and distribute annotations toMSPs using OSLP.

• SPs request de-escalation of orderingissues using OSLP.

• OSLP notifies the SP when the MSPannotates an order with free form text.

• OSLP notifies the SP when the MSPescalates or de-escalates an orderingissue.

These services are symmetric with thoseprovided to MSPs.

Subcontracting Services(Subcontracting Layer)

The subcontracting service integratesMSP and SP services. The subcontract-ing service includes:

• Order binding• Delayed order binding.

The following example illustrates orderbinding:

An MSP orders a frame relay perma-nent virtual circuit (PVC) from aprimary SP. The PVC connects anendpoint in London to an endpoint inRome. The primary SP cannot fulfil theorder using its own network resources.Therefore, it divides the order into twocomponents. One component connectsthe London endpoint to a frame relaynetwork-to-network interface (NNI) inMilan. The other component connectsthe Roman endpoint to an NNI that isco-located with the first NNI in Milan.

The primary SP assigns one servicecomponent to a secondary SP in Eng-land and the other to a secondary SPin Italy. Using OSLP subcontractingservice, the primary SP creates a neworder representing each service com-ponent and binds the new orders to theoriginal order from the MSP.

The OSLP subcontracting layerrecords the original order and the neworders in its local data base. It sendsone new order to the secondary SP inEngland and the other to the second-ary SP in Italy.

As the secondary SPs provision theircomponents, they send status updatemessages to the primary SP. When theprimary SP’s subcontracting layerreceives these messages, it re-evalu-ates the status of the original orderfrom the MSP.

The primary SP’s subcontracting layercomposes a status update message thatincludes information concerning theoriginal order, as well as the two neworders. The primary SP’s subcontract-ing layer sends this message to theMSP as well as to the primary SP’shigher lever applications.


In the example above, the primary SPchooses the NNI at which the two PVCsegments meet. Therefore, the primarySP issues complete service orders to bothsecondary SPs, simultaneously, specifyinga network-to-network interface for each.

Business policy can require that one orthe other secondary SP specifies the net-work-to-network interface. Therefore,OSLP supports delayed order binding.The following frame relay example illu-strates delayed order binding:

An MSP orders a frame relay PVCfrom a primary SP. The PVC connectsan endpoint in London to an endpointin Rome. The primary SP cannot fulfilthe order using its own networkresources. Therefore, it divides theorder into two components. One com-ponent connects the London endpointto an unspecified NNI. The other com-ponent connects the Roman endpointto another unspecified NNI.

The primary SP assigns one servicecomponent to a secondary SP in Eng-land and the other to a secondary SPin Italy. It updates the Italian servicecomponent, specifying it must providean NNI that interfaces with the EnglishSP’s network.

Using the OSLP subcontracting ser-vice, the primary SP creates a neworder representing each service com-ponent and binds the new orders to theoriginal order from the MSP. The pri-mary SP also “delays” transmission ofthe English SP’s order.

The OSLP subcontracting layerrecords the original order and the neworders in its local data base. It sendsone new order to the secondary SP inItaly and defers transmission of theother new order.

As the secondary SP in Italy provisionsits component, it sends status updatesmessages to the primary SP. When theprimary SP’s subcontracting layerreceives these messages, it re-evalu-ates the status of the original orderfrom the MSP.

The primary SP’s subcontracting layercomposes a status update message thatincludes information concerning theoriginal order, as well as the two neworders. The primary SP’s subcontract-ing layer sends this message to theMSP as well as to the primary SP’shigher lever applications.

When the primary SP applicationdetects that the secondary SP in Italyhas assigned an NNI, it updates theorder to the secondary SP in Englandand removes the delay. The primarySP’s subcontracting layer sends theorder to the SP in England and orderprocessing continues.

OSLP ArchitectureThe following are OSLP architecturalgoals:

• Maximize the number of SPs that canpartake in the protocol

• Maximize the number of viewsthrough which SPs can access eachother’s ordering information using theprotocol.

These goals are in conflict. As the proto-col becomes more robust, and offers alarger number of access views, it alsobecomes more difficult and costly tointegrate with SP legacy systems. As theprotocol becomes more difficult andcostly to integrate with SP legacy sys-tems, the number of SPs that can partakein the protocol decreases.

Therefore, OSLP provides the minimumnumber of access views required to sup-port order management. Specifically,OSLP implements a multi-state protocol.

Multi-state protocols support the follow-ing scenario:

• The MSP creates an order within itsown data base of record.

• The MSP sends a message to the SPinforming the SP that the new orderhas been created.

• The SP creates an identical order with-in its data base of record.

• The SP processes the order containedby its data base of record according tolocal policy. It updates order status asappropriate.

• Each time the SP updates the ordercontained by its data base of record, itsends a status update message to theMSP. The status update message con-tains all SP provided order attributes,including status.

• The MSP receives the status updatemessage and updates the correspond-ing order in its data base of record.

• When the MSP receives a statusupdate message that indicates the order

has been completed, the MSP sendsthe SP a message indicating whether ornot it is satisfied with the servicerendered.

Once the MSP sends its initial messageto the SP, the MSP’s ability to communi-cate with the order contained by the SPdata base of record is extremely limited.Specifically, the MSP can:

• Monitor status update messages sentfrom the SP

• Synchronize its copy of the order withthe SP copy by requesting a retransmis-sion of the last status update message.

• Send a message to the SP that appendsfree form text to the order. The mes-sage can also escalate an orderingissue.

In order to modify or cancel an order, theMSP must create a new order within itsdata base of record. The new order super-sedes or cancels the original order. TheMSP sends a message to the SP and theSP creates an identical order within itsdata base of record. The SP processesboth orders according to the scenariodescribed above.

Multi-state protocols minimized the costof integration with legacy systems. SPsexecute only a few course-grained opera-tions upon orders that reside in eachothers SP’s domain. Therefore, SPs neednot implement complex adaptation func-tions that map OSLP messages to everypossible view of their legacy data base ofrecord. SPs implement only a small set ofadaptation functions that support ordercreation, status update reporting, andorder closure.

The OSLP Protocol DataUnit (PDU)

Organizations initiate and progressorders by exchanging OSLP PDUs. InOSLP, the initiating organization as-sumes the MSP role and the order reci-pient assumes the SP role.2

2 The distinction between the MSP orga-nization and the MSP role is impor-tant. Recall that in a subcontractingarrangement, the primary SP assumesthe SP role with respect to the originalcontract and the MSP role with respectto the subcontract (see Figure 2)


Header field description Supplied by:

Organization identifier for the MSP role MSP role

Order identifier assigned by the MSP role MSP role

List of contacts that represent the MSP role MSP role

Organization identifier for the SP role MSP role

Order identifier assigned by the SP role SP role

List of contacts that represent the SP role SP role

Organization identifier for the MSP MSP role

Order identifier generated by MSP MSP role

Order type (i.e., request bid with pricing information,request bid without pricing information or request provisioning) MSP role

Order disposition (i.e., new order, supersede previous order,cancel previous order) MSP role

OSLP message type (See details below) MSP role

Order due date MSP role

Order estimated completion date SP role

Order status (See details below) SP role

Date and time of last status update SP role

Order confirmation status (See details below) MSP role

Subcontracting details (i.e., a list of orders sent to secondarySPs in order to fulfil current order) SP role

List of annotations to current order MSP or SP role

The OSLP PDU contains a header and apayload. The header represents serviceindependent order attributes while thepayload represents a list of specific ser-vices that are being ordered.

Most header values are supplied by theMSP role at order creation time. Selectedattributes are supplied by the SP role.Table 1 describes the OSLP headerfields.

The following are OSLP message types:

• OSLP Service Request (OSR)

• OSLP Provisioning Status Update(OPSU)

• OSLP Ping (OPNG)

• OSLP Provisioning Completion Con-firmation (OPCC)

• OSLP Re-engineering Notification(OREN)

• OSLP Free Form Text (OTXT).

The OSR Message

The MSP role creates a service orderwithin the SP data base of record bysending an OSR messages.

The OPSU Message

The SP role sends the MSP role one ormore OSPU messages between OSRreception and order completion. The SProle sends an unsolicited OSPU messageeach time it achieves a provisioningmilestone. It also sends an OPSU mes-sage in response to each status inquiryreceived from the MSP role.

The OPSU message specifies order statusand engineering details. Table 2 definesorder status values.

The OSLP Ping Message (OPNG)

The MSP role sends the SP role anOPNG message order to request a statusupdate regarding a particular order. TheSP responds to the OPNG message withan OPSU message.

OPSU Provisioning CompletionConfirmation (OPCC) Message

The MSP role sends the SP role anOPCC message in response to an OPSU(complete) message. The OPCC messageindicates whether or not the MSP roleconcurs that the service has been pro-visioned as requested. Upon receiving a

Table 1 OSLP Header Attributes

Status Description

Initial The order has been created, but not acted upon.

Claimed The SP role has determined that it can provide the entire locally,without subcontracting.

Distributed The SP role has determined that it cannot provide the entire ser-vice without subcontracting. Therefore, the SP role has subcon-tracted at least a portion of the request to one or more secondarySPs.

Subcontracted The SP role has determined that it cannot provide the entire ser-vice without subcontracting. Therefore, the SP role has subcon-tracted at least a portion of the request to one or more secondarySPs. The secondary SPs have claimed their portion of the order.

Engineered The SP role has engineered the service request (e.g., assignedaccess ports).

Complete The SP role has provisioned and tested the service.

Accepted The MSP role has accepted service delivery. Billing may begin.

Failed The SP role has determined that it cannot provide the service.

Aborted The SP role has aborted the service request at the MSP’s request.

Unknown The SP role has received a status inquiry for an unknown order.

Table 2 OSPU Service Request Status Values


positive OPCC message, the SP role ini-tiates the billing process. Upon receivinga negative OPCC message, the MSP andSP roles resolve the issue outside ofOSLP.

If the SP role does not receive an OPCCmessage (either positive or negative)within a configurable period, it assumesthat the service has been provisioned asrequested and initiates the billing process.

The OSLP Re-engineering (OREN)Message

The SP role sends the MSP role anOREN message to indicate a unilateralchange in engineering details after trans-mission of the OPSU (complete) mes-sage. Changes can represent networkgrooming efforts or emergency repairactions.

OREN messages are propagatedupstream to the MSP organization.

The OSLP Free Text Message(OTXT)

The OTXT message can serve any of thefollowing functions:

• Carry free form text regarding an order

• Manage escalation of an issue to SProle management.

Either the MSP or SP role can send anOTXT message at any time.

OSLP Stack

OSLP is a multi-state protocol that doesnot require robust interactive communi-cations services. Therefore, OSLP doesnot rely upon services provided by theCommon Information Service Element(CMISE).

Furthermore, OSLP does not requireobject location services. Therefore,OSLP also does not rely upon servicesprovided by X.500 or the CommonObject Request Broker Architecture(CORBA).

Alternatively, OSLP relies upon servicesprovided by the stack depicted in Figure 5.

The Basic Encoding Rules (BER) de-scribed in ITU-T RecommendationX.209 provide OSI presentation layerservices.

Point-to-point store and forward servicesare provided by the Alliance Point-to-Point Transport Protocol (APT). APT isdefined in the OSLP documentationsuite.

Lower layer services are provided by theTransmission Control Protocol (TCP)and the Internet Protocol (IP).

As stated in Recommendation M.3320[3], SPs maintain pair-wise agreementsregarding encryption and security admi-nistration. Because each SP is con-strained by its national security and en-cryption policy, it may not be possible tospecify a single, global security policy.

Conclusions

OSLP provides a mechanism throughwhich SPs exchange ordering informa-tion. As OSLP’s architecture minimizesthe cost of integration with legacy ordermanagement systems, it encourages awide community of SPs to partake in theprotocol.

References

1 Bonica, R P. Alliance Approach tothe TMN X Interface. Telektronikk,94 (1), 39–47, 1998 (this issue).

2 ITU-T. Principles for a Telecommu-nications Management Network.Geneva, ITU, 1992. (ITU-T Recom-mendation M.3010.)

3 ITU-T. Management RequirementsFramework for the TMN X Interface.Geneva, ITU, 1997. (ITU-T Recom-mendation M.3320.)


Transmission Control ProtocolIETF RFC 793

OSLP Primitive Service

APT Store & Forward

Internet ProtocolIETF RFC 791

OSLP Subcontracting Service

Higher Level Application

Figure 5 OSLP Supporting Stack

Ronald P. Bonica is a member of the MCI InternetEngineering Team. He is currently under contractto the Concert Frame Relay Team and partici-pating in the Concert Alliance Interface Standardseffort. His interests are TMN and Internet archi-tecture.


Distributed processing has becomeincreasingly important in the lastdecade, due to the need for inter-connecting existing systems, neworganisational trends, and intra- aswell as inter-organisational co-opera-tion. RM-ODP aims at providing a co-ordinating framework for the stan-dardisation of Open Distributed Pro-cessing.

1 Introduction

The joint ISO/ITU standardisation ofRM-ODP, Reference Model of OpenDistributed Processing, aims at providinga co-ordinating framework for the stan-dardisation of Open Distributed Process-ing. This framework identifies an archi-tecture that supports distribution, inter-working and portability. These factorsare the basis for providing the benefits ofdistributed information processing in anenvironment of heterogeneous enablingtechnology. The main users of RM-ODPare considered to be standards writersand architects of open distributed sys-tems.

Besides distribution of possibly remoteprocesses, distributed systems are charac-terised by the following inherent charac-teristics [1]:

• Concurrency, i.e. components exe-cuting in parallel

• Lack of global state, i.e. the entireglobal state of a distributed systemcannot be precisely determined

• Partial failures, i.e. any componentmay fail independently of any othercomponents

• Asynchronisity, i.e. communicationand processing activities are not drivenby a single global clock, and relatedevents in a distributed system cannotbe assumed to take place at a singleinstant.

With these aspects taken into account,RM-ODP must in addition to hetero-geneity, also consider and provide forautonomy, openness (enabling bothportability and interworking), integration(incorporating various systems andresources into a whole), and flexibility.The issue of autonomy deals with thesituation where the systems are spreadover a number of autonomous manage-ment or control authorities (organisa-tional units or administrative domains),without any central point of control.

Flexibility, addresses several issues, suchas continued operation of legacy systems,support of a system’s evolution, as wellas capabilities facilitating run-timechanges and reconfigurations.

The RM-ODP standards are organisedinto four parts.

• Part 1 [1], Overview; provides an over-view of RM-ODP, including its moti-vation (partly covered above), scope,justification and explanation of keyconcepts, and an outline of the archi-tecture, including explanatory material.This part is not normative.

• Part 2 [2], Foundations; contains thedefinition of concepts and analyticalframework for normalised descriptionof (arbitrary) distributed processingsystems. The level of detail is limitedto what is necessary and sufficient as abasis for Part 3. This part is normative.

• Part 3 [3], Architecture; contains thespecification of the required characte-ristics that qualify distributed process-ing as open. These are constraints towhich ODP standards must conform.It uses the descriptive techniques fromPart 2. This part is normative.

• Part 4 [4], Architectural semantics;contains a formalisation of the centralODP concepts defined in Part 2. Theformalisation is achieved by in-terpreting each concept in terms ofconstructs of different standardisedformal description techniques. Thispart is normative.

This paper, whose aim is to provide anintroduction to RM-ODP, is predomi-nantly based on these four parts. In addi-tion, this article also attempts to identifyand discuss some of the challenges andstill open issues related to RM-ODP.

The development of RM-ODP has beenbased on several sources [5], of whichthe ANSA Research Program has made asignificant contribution. The idea of di-viding the problem domain of open dis-tributed processing into five projectionsto handle complexity, is discussed in [6].These projections, which correspond tothe five viewpoints of RM-ODP, is a keyelement in the ANSA Architecture, con-sisting of a set of six frameworks add-ressing most aspects of distributedsystems design and implementation.

55

Introduction to RM-ODP – A Reference Model of Open Distributed Processing

H Å K O N L Ø N S E T H A G E N

Telektronikk 1.1998

Technology

Viewpoint Engineering

Viewpoint

Enterprise Viewpoint

Com

putational

View

pointInfo

rmat

ion

Vie

wpo

int

Objectives,Enterprise objects,

Roles,Policies, Actions,

Non-functional reqs.

Info

rmat

ion

obje

cts,

Sem

antic

s,R

elat

ions

hips

,C

onst

rain

ts,

Sta

te c

hang

e

Distrib

uted process

ing

infrastr

ucture,

execu

table engineering

objects,

Distrib

ution

transp

arencies

Functional

decomposition,

Com

putational objects,

Interfaces,

Interactions

Implementation

and computing

technology,

Technology dependent

testing

ODP System

Figure 1 RM-ODP Viewpoints

RM-ODP Part 1 states: “A viewpoint is asubdivision of the specification of a com-plete system, established to bringtogether those particular pieces of infor-mation relevant to some particular areaof concern during the design of the sys-tem”. The five RM-ODP viewpoints(viewpoints on the system and its en-vironment) are (se also Figure 1):

• the enterprise viewpoint, which is con-cerned with the business activities ofthe specified system, by focusing onpurpose, scope, and policies

• the information viewpoint, which isconcerned with the information thatneeds to be stored and processed, andthe semantics of the information

• the computational viewpoint, which isconcerned with distribution by add-ressing functional decomposition intocomputational objects which interact atinterfaces

• the engineering viewpoint, which isconcerned with the mechanisms andfunctions supporting distribution of thecomputational objects and their inter-action

• the technology viewpoint, which isconcerned with the choice of imple-mentation and computing technology.

The viewpoints should not be consideredas layers of functionality, nor should afixed order be assigned to them accord-ing to design methodology. In addition tothe five viewpoints, the framework de-fined by RM-ODP comprises a viewpointlanguage for each viewpoint, specifica-tion of functions required to supportODP systems, and a set of transparencyprescriptions. The latter shows how touse the ODP functions to achieve distri-bution transparency. Each viewpointlanguage defines the concepts and rulesfor specifying ODP systems from thecorresponding viewpoint. The combina-tion of the computational language, theengineering language, and the trans-parency prescriptions determine thearchitecture of the ODP systems.

A goal of the framework is to allow dif-ferent parts of the design to be workedon separately. However, it should alsoclearly identify those parts of the designthat constrain other parts. The mecha-nism of viewpoints is one of the twomain structuring approaches adopted bythe ODP architecture, while distributiontransparencies provide the other.

Distribution transparencies deal with anumber of concerns and aspects that aredirect results of distribution, such asremoteness, failure, etc. The ODP frame-work addresses these concerns by identi-fying generic means to make theseaspects transparent to the applicationdesigners and developers. RM-ODPdefines the following transparencies(along with related requirements andsolutions that satisfy them):

• access transparency, – masks the dif-ferences in invocation mechanisms anddata (message) representation to en-able interworking between distributedprocesses of heterogeneous techno-logy. This transparency is generallyinherent to the distributed infrastruc-ture.

• failure transparency, – masks from anobject (see below for a definition of‘object’ and ‘interface’) the failure andpossible recovery of other objects (oritself) to enable fault tolerance. If thistransparency is provided, the designercan work under the assumption thatthis class of failure does not occur.

• location transparency, – masks the useof information about location in spacewhen identifying and making associa-tion between object interfaces. Whenthis transparency is provided, identifi-cation of object interfaces is achievedby naming based only on a logicalview.

• migration transparency, – masks froman object the ability of a system tochange the location of that object.Migration of objects is often used toachieve load balancing and reducelatency.

• relocation transparency, – masks froman interface the relocation of anotherinterface bound to it. Relocationallows system operation to continueeven when migration or replacement ofsome objects creates transient incon-sistency.

• replication transparency, – masks theuse of a group of mutually behaviour-ally compatible and synchronisedobjects to support an interface. Repli-cation is often used to enhance perfor-mance and availability.

• persistence transparency, – masksfrom an object the deactivation andreactivation of other objects (or itself).The state of an object must be per-sistently stored even when processingand memory resources cannot be allo-

cated to the object, or as a means tofacilitate recovery.

• transaction transparency, – masksfrom an object the co-ordination ofactivities amongst a configuration ofdependent objects to achieve con-sistency.

The transparencies may be provided forby a generic distributed infrastructure.This infrastructure or distributed pro-cessing environment, provides ODPfunctions coping with the transparencies.By implementing these functions as partof a generic infrastructure, software reuseis achieved by letting the ODP functionsbe (re-)used by several applications. Thenotion of middleware, which in the lastfew years has become an establishedterm in the industry, is used to designatesoftware providing the generic distri-buted infrastructure. Various middle-wares, however, may offer a subset ofthe above list of transparencies, as wellas additional functions and services.

The remainder of this paper is structuredas follows: Section 2 briefly presents thefundamental and generic (modelling)concepts of RM-ODP. Sections 3, 4, 5, 6,and 8 present the five RM-ODP view-points and corresponding viewpoint lan-guages, in the order as indicated above.In addition, distribution transparenciesand ODP functions are covered in moredetail in section 7. Section 9 provides anintroduction to the issue of architecturalsemantics. A discussion is provided insection 10, on what is believed to beopen issues related to RM-ODP. Con-cluding remarks are given in section 11.An example of a way of using RM-ODPis provided in a separate paper in thisissue of Telektronikk [7].

2 Foundations – The CommonModelling Concepts

The ODP Architecture1 is defined in Part3 of RM-ODP. It defies a viewpointlanguage for each of the five viewpoints.The concepts identified in each of theviewpoint languages are based on andpossibly refine the generic modellingconcepts defined in Part 2, Foundations.

In addition to providing interpretation ofa few terms or concepts generally appli-cable to any modelling activity, Part 2makes the following categorisation ofconcepts;


• basic modelling concepts, – conceptsfor modelling the ODP systems. Anyviewpoint language must relate tothese concepts.

• specification concepts, – concepts re-lated to the relevant specification lan-guage. These concepts are not intrinsicto the distributed system, however,some systems may directly rely onspecifications of for example a con-ceptual specification.

• structuring concepts, – concepts thatrelate to various aspects of designingand description of distributed systems,such as their various system architec-ture properties and policies, organisa-tion of objects, naming issues, issuesrelated to activity and behaviour, aswell as management.

• conformance concept, – conceptsnecessary to interpret the notion ofconformance to ODP based standardsand of conformance testing.

2.1 Basic modelling concepts

By the basic modelling concepts, ODPintroduces a general object-based model.However, this does not imply that theobject-oriented modelling style isadopted2. An object is an abstract modelof an entity. An object is further charac-terised by its unique identity, by its state,its encapsulation, and its behaviour.Encapsulation ensures that the state ofthe object may only be accessed via oneor more interfaces of an object. Other-wise, only internal actions may alter thestate of an object.

At this generic level, few assumptionsare made, and an object may be of anylevel of granularity, complexity, andallow internal parallelism. Interactionsbetween objects are not constrained andmay include both asynchronous (whichimplies concurrency) and various syn-chronous interactions.

Interactions among objects may onlyoccur on the object interfaces. An inter-face identifies a set of possible interac-tion types, and may be considered as aservice of the object. This set of possibleinteractions represents a part of theobject’s behaviour. An object may havemultiple interfaces, which allow func-tional separation as well as distributionof the object’s points of interaction.

The above mentioned properties of anobject, provide well defined separationbetween objects. That is, every depen-dency among objects is captured by acorresponding interface. This furtherallows a compatible object, as perceivedby its environment, to replace anotherobject without influencing the environ-ment of the original object.

2.2 Specification Concepts

While an ODP system in general can bedescribed by the basic modelling con-cepts as a collection of related, interact-ing objects, the specification conceptsintroduce several additional concepts thatmay be related to requirements placed onany specification language used for thespecification of an ODP system.

Among these concepts are the importantnotions of composition and refinement.Composition and its dual, decomposition,of specifications can be a useful means ofthe modelling and design process. A dis-tinction between composition of objectsand composition of behaviours is made.Refinement is the process of transform-ing one specification into another moredetailed specification.

Furthermore, the notions of type andclass are defined, as well as the corre-sponding notions admitting hierarchiesof types or classes, i.e. subtype/supertypeand subclass/superclass. The notions oftemplate and instantiation of a templatealso fall into the category of specificationconcepts.

2.3 Structuring Concepts

While the specification concepts allowstructuring of specifications, the struc-turing concepts on the other hand areconcerned with structuring and propertiesof the ODP systems as such.

In addition to various concepts used fororganising and relating sets of objects,such as configuration, domain, group,reference point, and epoch, this part alsodefines several fundamental conceptsrelated to naming, and transparencies, aswell as policies – the latter will becovered in more detail with respect to theenterprise viewpoint. Management con-cepts such as application management,communication management, manage-ment information, managed and man-aging roles, and notification are alsodefined.

An important policy concept is that ofenvironment contract, which is a contractbetween an object and its environment.Constraints related to quality of service(QoS), usage, and management are intro-duced. These notions are important to theenterprise and the computational view-points. QoS constraints include temporal,volume (e.g. throughput), and depen-dability constraints (e.g. availability,reliability, maintainability, security andsafety). Usage and management con-straints include issues related to locationas well as distribution transparencies.Non-functional requirements is a fre-quently used expression denoting theseconstraints.

While the concepts of behaviour andactivity were identified as basicmodelling concepts, concepts related tostructures of activities, as well as con-cepts related to contractual behaviour(related to contracts among sets ofobjects) are defined in this part. Severalcategories of roles are also identifiedrelated to causality of object interaction.Causality, e.g. producer vs. consumer, isan issue particularly relevant to thecomputational viewpoint.

Of particular importance in open distri-buted processing is the concept of bind-ing between object interfaces. A bindingis a contractual context, which is theknowledge that a particular contract isestablished between two or more inter-faces, and hence between their support-ing objects, and implies that a particularbehaviour of this set of objects is ex-pected.


1 A general description of the notion ofarchitecture at this level of abstractionwas not found in RM-ODP Part 2.However, it becomes evident from theusage of terms in the documents thatwhile the ‘ODP (Architectural)Framework’ identifies the (frame of)overall elements encompassed by theODP Architecture, the notion of ODPArchitecture itself designates both theframework and the concepts and rulesdefined as part of each element of theframework.

2 An object-oriented modelling stylemust include the concept of inheritance[8] and possibly polymorphism (gene-ric operation) [9].

2.4 Conformance Concepts

Distributed systems are potentially verycomplex, the components are hetero-geneous and may undergo individualevolution, and several administrativedomains may be involved. This com-plexity puts a great challenge on ex-pression of conformance requirementsand on conformance assessment andtesting.

Conformance relates statements of aspecification (a standard) to observableevents and behaviour of the correspond-ing implementation at certain confor-mance points. The RM-ODP identifiesseveral classes of reference points in thearchitecture. Such a reference point is apotential conformance point. If so de-clared by some specification, this pointmust then be accessible to testing of con-formance.

RM-ODP identifies four classes of refe-rence points of which a reference pointpotentially may be identified as a confor-mance point:

• programmatic reference point, – atwhich a programmatic interface can beestablished to allow access to a func-tion. A programmatic interface is aninterface which is realised through aprogramming language binding.

• perceptual reference point, – at whichthere is some interaction between thesystem and the physical world, e.g. ahuman-computer interface.

• interworking reference point, – atwhich an interface can be establishedto allow communication between twoor more systems or components. Inter-working conformance involves inter-connection of reference points.

• interchange reference points, – atwhich an external physical storagemedium can be introduced into thesystem. The storage medium may beused to interchange information fromone system to another.

3 The Enterprise View-point and Language

The enterprise viewpoint allows an ODPsystem to be represented in the context ofthe enterprise in which it operates. Theaim is to identify requirements of a sys-tem in terms of objectives, policy state-ments and obligations by the variousroles identified in the enterprise view-

point. This viewpoint further identifiesactivities to be realised by the system aswell as the various contracts with itsenvironment. The motivation for a sepa-rate viewpoint to express these issues, isbased on the idea of decoupling the set ofobjectives for the system from the waythey are realised.

The concepts of ‘community’ and ‘fede-ration’ are defined by this viewpointlanguage. A community represents theODP system and the environment inwhich it operates. A community willidentify the scope of the system relativeto this community. The following ele-ments constitute a community:

• the enterprise objects comprising thecommunity

• the roles fulfilled by each of thoseobjects

• policies governing interactionsbetween enterprise objects

• policies governing the creation,deletion, and usage of resources byenterprise objects

• policies governing the configurationand structuring of enterprise objectsand assignment of roles to enterpriseobjects

• policies relating to environment con-tracts, governing the system.

An enterprise object can fulfil roles asso-ciated with different communities. Thisis determined by the environment con-tracts on which a corresponding commu-nity is based. An enterprise object ful-filling a role is defined and constrainedby permissions, obligations, and prohibi-tions associated with that role. Theseaspects, expressing policies of an objectmay change dynamically according tointeractions between objects. In theenterprise viewpoint, actions betweenobjects relating (and changing) obliga-tions, permissions, and prohibitions toassociations between objects are of parti-cular interest. Furthermore, objectivesand policies related to resource usage,accounting, and non-functional require-ments are identified within the enterpriseviewpoint.

Enterprise objects may be owned andcontrolled by different authorities oradministrative domains. A federation is aparticular community where objects areassociated with different authorities. Theobjective of a federation will typicallydepend on joint and co-ordinated activi-

ties. The autonomy of enterprise objectsmust be considered when describing therules for the establishment of a federa-tion, the joining to a federation, as wellas the cessation of federation participa-tion. The policies related to delegation,security and trust are of particularinterest to communities describingfederations.

All four classes of reference points, asdescribed in section 2.4, may be subjectto enterprise specification. Conformancestatements in the enterprise language interms of a particular set of objectives andpolicies must be related to a referencepoint identifiable in the engineeringviewpoint. By observing the behaviour ofthe system at this reference point, theinteractions with the system may beinterpreted in the enterprise languageterms to check conformance.

4 The Information View-point and Language

The information viewpoint is focusedtoward the information that needs to bestored and processed by the system, thatis, the semantics of this information aswell as the semantics of the informationprocessing in an ODP system. The infor-mation language defines the generic con-cepts, rules and structures to be used inthis viewpoint. An information specifica-tion defines the information and seman-tics in terms of a configuration of infor-mation objects and their relationships,the behaviour of those objects, and theenvironment contracts for the system.

Furthermore, the motivation for theinformation language is to facilitate thecorrect interpretation of information con-veyed while interacting among com-ponents of an ODP system. If com-ponents of a distributed system are notfounded on a common understanding ofthe common information among thecommunicating components, the systemis not likely to behave as expected.

The information objects represent entitiesthat occur in the real world, in the ODPsystem, or in other viewpoints. Anatomic information object represents abasic information element, while com-plex information is represented as a com-posite information object containingencapsulated information objects. Hence,an information object being a componentof a composite object cannot be a com-ponent of another.


The information language comprisesthree schemata. An information objecttemplate may reference any of theseschemata:

• invariant schema, – a set of predicateson one or more information objectswhich must always be true for theentire life-time of the objects. Thus,the invariant schema constrains thepossible states and state changes of thecorresponding objects.

• static schema, – the state of one ormore information objects, at somepoint in time, subject to the constraintsof any invariant schema.

• dynamic schema, – the allowable statechanges of one or more informationobjects, subject to the constraints ofany invariant schema.

Typically, the identified state change willgo from one static schema to anotherstatic schema, and as such, model thebehaviour of the system in terms of thestate space of which it operates. Allow-able state changes can be subject toordering and further temporal constraints.A dynamic schema can involve the crea-tion of new information objects or thedeletion of information objects.

While the invariant schema may beregarded as the specification of the typesthat will always be satisfied of one ormore information objects, the staticschema is the specification of the typesof one or more information objects atsome particular point in time. The typesspecified by the static schema are thussubtypes of the types specified in theinvariant schema.

Distribution and localisation are not con-sidered by the information specification.However, the notion of interface is notprohibited as part of an information spe-cification. No assumptions may, how-


Signal interfacesignature

for each signalinterface type

a finite set ofAction template(s)

one for each signal typein the interface

Signal name

a finite number ofParameter(s)

Causalityeither initiating or

responding

Flow name

Information typeStream interfacesignature

for each signalinterface type

a finite set ofAction template(s)

one for each flow typein the interface

Causalityeither initiating or

responding

Signal name

Parameter type

Operationinterfacesignature

for eachoperation

interface type

a finite set ofAnnoncementsignature(s)

(is an Action template)one for each operation type

in the interface that is anannoncement

a finite set ofInterrogationsignature(s)

(is an Action template)one for each operation type

in the interface that is aninterrogation

Causalityeither client (initiating) or server

for the interface as a whole

Invocation name


Invocation name


a finite set ofAction signature(s)

one for eachtermination type

Parameter name

Parameter type

a finite number ofParameters(s)

Parameter name

Parameter type

Parameter name

Parameter type

Termination name

Figure 2 Interface signatures

ever, be made about the location of theinterface or about the interface appearingas such in an implementation.

Conformance relative to a conformancepoint must be based on observations atsome engineering reference point(s). Thebehaviour at this reference point must beconsistent with a particular set of in-variant, static, and dynamic schemata asidentified by the corresponding confor-mance statements.

5 The ComputationalViewpoint andLanguage

The computational language and the en-gineering language have got the mostattention in the RM-ODP specifications.While the enterprise and information

viewpoints deal with distribution at ahigh level only, that is, what constitutes asystem, the computational as well as theengineering viewpoints explicitly add-resses distribution. The computationalviewpoint is concerned with the deci-sions of how to distribute the job of thesystem by a functional decompositioninto computational objects. On the otherhand, the mechanisms for interactionamong distributed components are pro-vided by the engineering viewpoint.

The computational language identifies anobject model, which in broad terms de-fines what kinds of interfaces an objectcan have, how interfaces may be boundto each other, and the kinds of interac-tions that may take place at the inter-faces. The goal of the computationallanguage is to enable a component speci-fier to express constraints on distribution

of an application only in terms of en-vironment contracts, i.e. interfaces andinterface bindings. The degree of distri-bution, e.g. replication, or any otherdependency on realisation of distributionneed not be expressed in the computa-tional language. This will promote openinterworking and portability of com-ponents.

5.1 Computational interfacesand object interactions

The computational language identifiesthree types of interfaces; operational,stream, and signal interfaces. These cate-gories of interfaces correspond with thethree forms of interactions that can takeplace between computational objects.Each interaction must occur at one of theestablished (bond) interfaces of a com-putational object. The forms of inter-actions are:

• signals, which are the elementaryatomic interactions. A signal is con-sidered as an atomic action sharedbetween an initiating object and aresponding object, resulting in a one-way communication from the initiatingobject to the object accepting the com-munication.

• operations, which from a client object,request an invocation of some functionat the server object. Furthermore, thereare two types of operations;

i) interrogation, where the serverreturns a response (termination) tothe client object, and

ii)announcement, where no responseby the server back to the client isexpected. An announcement may beused to report some event or statechange.

• flows, which is an abstraction of acontinuous sequence of interactions,resulting in conveyance of informationfrom a producer object to a consumerobject. Flows can be used to model, forexample, audio and video streams aspart of a multimedia telecommunica-tions service.

Notice that the notion of client and serveras associated with interrogations andannouncements are merely roles. Thus, aserver object as seen relative to an inter-rogation may emit an announcement tothe corresponding client object. In thatcase, this client object takes the serverrole with respect to the mentionedannouncement.


Box 1 – Binding between computational interfaces

A binding between computational interfaces is an abstraction of an established com-munication path between the interfaces. The notion of explicit binding is used whenexplicit actions are needed to establish a binding. An explicit binding action allowsexplicit handling of the binding, including means to express configuration and QoS.Implicit bindings on the other hand, are assumed when the specification notationdoes not offer means of expressing binding actions. Implicit binding is only definedfor operation interfaces. It involves creation of the appropriate client operation inter-face, binding the client interface to the server interface, and invocation of the serverobject, using the client operation interface.

Any binding action must ensure that the bound interfaces are of the same kind, e.g.operational, and that they have complementary causality, e.g. client interface againsta server interface. Moreover, the types of the signatures must also be compatible.

Explicit bindings are either primitive bindings or compound bindings. A primitive bind-ing is a binding directly between two computational objects. The corresponding bind-ing action is parameterised using one identifier of each of the two interfaces involved.One of these interfaces is an interface belonging to the computational object initiatingthe binding. A primitive binding action is atomic in the sense that either the bindingwill be established or it will fail.

A compound binding involves a dedicated binding object. A binding object is itself acomputational object, however, constrained by a set of rules for compound bindings.A binding object is a means to bind more than two computational objects, and furtherto allow controlling the configuration of the binding as well as controlling QoS relatedaspects.

By appropriate parameters, the compound binding action identifies the desired bind-ing object template to be used and the interfaces of the computational objects to takepart in the compound binding. The interfaces to be bound must be assigned rolescorresponding to the formal role parameters of the binding object template. The be-haviour of the binding object is expressed in terms of these roles.

The initiator of the compound binding action may in subsequent interactions with theother computational objects disseminate the identifier of the binding object controlinterface and information about the state of the binding object. At that time, the othercomputational objects can also access the control interfaces of the binding object andmanipulate the binding object.

Whereas participants of a flow or anoperation may have an inconsistent viewof an interaction at different times,especially when failures have occurred,there is no concept of partial failure ofsignals. A signal either fails or succeedsidentically for both participants in theinteraction. Modelling operations andflows in terms of signals may be neces-sary in order to enable consideration ofend-to-end quality of service (QoS)characteristics.

A computational specification will spe-cify a set of computational object tem-plates, which comprises a set of com-putational interface templates. Both theinterface and the object templates com-prise associated behaviour specificationsand environment contract specifications.In addition, an interface template con-tains one of either a signal, an opera-tional, or a stream interface signature.These signatures and their comprisedelements can be considered the core ofthe computational language. Each of theinterface signatures and their comprisedelements are illustrated in Figure 2. Therelationship between table cells is a‘comprises’ relationship. The plural (s)indicate a ‘many’ cardinality of the rela-tionship.

The notion of complementary interface,say Y is complementary to X, indicatesthat interface signatures are identicalexcept for the complementary causality.

Parameters identifiable in a signal oroperation signature can take values iden-tifying computational interfaces or com-putational interface signature types. Thelatter then makes the type system of thecomputational signatures higher order.

A computational specification defines aninitial configuration of computationalobjects and their behaviour. This con-figuration will change as computationalobjects or interfaces are instantiated ordeleted, binding actions are performed,or control functions on binding objectsare effected.

The computational language is associatedwith several categories of structuringrules. Various naming rules constrain thecontext and scope of names in computa-tional specifications. Furthermore, thetemplate rules identify the various kindsof actions performed by computationalobjects, the failure rules identifyingpotential points of failure in computa-tional activities, and the portability rules

identifying aspects that must be con-sidered when designing a portabilitystandard.

The structuring rules that relate to distri-bution transparent interworking are ofparticular importance. They are the inter-action rules, which have been consideredin this subsection, the binding rules, andthe type rules. The latter two are de-scribed in the accompanying text boxes.

6 The Engineering View-point and Language

While the computational viewpoint isconcerned with specification of abstractcomputational components or objects, theengineering language is concerned with

how to realise these abstract objects andhow to enable interactions among theserealised engineering objects.

The engineering language is based on amapping where each computationalobject is realised as one or several basicengineering objects. One basic engineer-ing object, or the set of basic engineeringobjects, realising a computational object,can only correspond to that computa-tional object. Accordingly, there is a one-to-one correspondence between an en-gineering interface and a computationalinterface (except when engineeringobjects are replicated).

The engineering language also definesconcepts and rules that model the distri-buted infrastructure, which enables exe-


Box 2 – Interface signature typing and subtyping

Computational interfaces are strongly typed. This enables early (e.g. compile-time)consistency checking between interface specifications and implementations. Thetype rules in RM-ODP are focused on subtyping rules for the various kinds of com-putational interface signatures, i.e. signal, operation, and stream signatures.

The notion of subtyping is particularly important with respect to evolution of systems.A desired property is to enable replacement of an interface or a component (e.g. acomputational object) without any noticeable difference to its environment. Usually,one would like to replace a server object without having to change (several) clientobjects. Replacement without any noticeable difference to the environment is theideal goal related to the notion of substitutability. In Part 2, Foundations, this propertyis called behavioural compatibility. The notion of interface type and interface subtypeideally captures all aspects of an interface specification necessary to ensure substi-tutability; an interface may replace another interface if the first is an interface subtyperelated to the interface type of the second.

However, typing and subtyping in RM-ODP, as well as in other object models like theCORBA object model [10], are based on types associated with interface signaturesonly. The notion of interface signature types captures the syntactic aspects of theinterface specifications as well as type consistency of the parameters of the inter-faces. Additional aspects related to interface behaviour or environment contracts ofthe interface are not covered by the typing of interface signatures. Hence, the signa-ture subtyping rules only define a set of minimum requirements for achieving substi-tutability.

The semantics of flows and composition of flows related to stream interfaces may beapplication dependent, thus RM-ODP does not prescribe a complete set of subtypingrules for stream interface signatures.

Intuitively one can say that the subtyping rules are based on the idea of avoidingunexpected kinds of interactions. As an example, considering operation interface sig-nature types having the server causality3: X is a signature subtype of Y, if for everyinterrogation in Y there is a corresponding one in X with the same name, the samenumber and name of the corresponding parameters; and each parameter type in Y isa subtype of the corresponding parameter type in X; and for every termination in Y,there is a corresponding one in X with the same name, the same number and nameof the corresponding parameters; and for every parameter result type associated withthe termination in Y, the corresponding result type in X is a subtype of the one in Y.

3 RM-ODP does not relate the subtyping rules for operation interfaces to the causality of the inter-face. The resulting problems this causes are pointed out by Sinnott and Turner in [11].

cution of the basic engineering objects aswell as interactions among these objects.The distribution transparencies are pro-vided by this enabling infrastructure. Theallocation of basic engineering objects tocomputing and storage facilities (systemresources) is a concern of the engineeringviewpoint. This issue is relevant whenconsidering for example system struc-tures and how to balance processingload as well as means for increasingresilience. This issue is the topic of‘Engineering communicating systems’,another article in this issue of Telektro-nikk [12].

In addition to identifying the concept ofbasic engineering object, the engineeringlanguage identifies plain engineering

objects that are fundamental to and partof the distributed computing infrastruc-ture. These engineering objects have adirect mapping to the available systemresources and model the relevant aspectsof these resources according to the in-herent nested structure of system re-sources. Figure 3 provides an illustrationof plain engineering objects and theirnested structure, and how basic engineer-ing objects fit into this structure.

The notion of cluster is used to representa configuration of basic engineeringobjects forming a unit for the purpose ofvarious object or cluster managementtasks. The clusters reside at the innerlevel of the nested structure of engineer-ing objects. One of these tasks is instan-

tiation of the cluster, based on a clustertemplate representing a configuration ofbasic engineering objects, the initial stateof the objects and the initial bindingsassociated with these objects.

The task of checkpointing is also asso-ciated with the concept of cluster. Check-pointing a cluster results in a cluster tem-plate reflecting the state and structure ofthe objects contained in the cluster at thetime of the checkpointing action. Clustercheckpoints further provide a basis fortasks such as deactivation, reactivation,recovery and migration of clusters. Thetasks just mentioned are provided by thecluster manager plain engineering object.


CLM

E E

Cluster

CLM

E E

Cluster

* * * *

Nucleus

Cluster

CPM CPM

Capsule Capsule

ClientStub

ClientBinder

ClientProtocolObject

#

#

#

Channel(established)

Cluster

Capsule

Nucleus

ServerStub

ServerBinder

ServerProtocolObject

#

#

#Interceptor

Node

ChannelClient Part

ChannelServer Part

Channel(established)

Node

E :CPM :CLM :* :" :# :

Basic Engineering ObjectCapsule managerCluster managerObject management interfaceNode management interfaceChannel control interface

E

Serverinterface

Clientinterface

(optional)

" "

Figure 3 Example structure of engineering objects

At the next grouping level, the concept ofa capsule is used as a container for agroup of clusters. Considered in relationto an operating system, the capsule canbe thought of as a protected process withits own protected address space. Thecluster on the other hand can be thoughtof as a segment of the virtual memorycontaining objects controlled by the cap-sule. The capsule is usually the smallestunit of independent failure. The capsulecontains a capsule management engineer-ing object that manages all the clustermanagers residing in the capsule. In addi-tion to interaction with the cluster man-agers initiating the cluster managementtasks, the capsule manager may have tointeract with other ODP functions to ful-fil its management policy.

A capsule forms a single unit for the pur-pose of encapsulation of processing andstorage, and can thus be considered asoccupying a portion of the processingcapacity and memory space controlledand managed by an operating system. Atthe outer level of grouping, the conceptof a node is used to designate the totalprocessing, storage and software re-sources controlled by an operating sys-tem. The internal structure of the node,e.g. the number of processors, is of noconcern to the engineering viewpoint.

In terms of the engineering language, anode encompasses a nucleus representing(the kernel of) the operating system ofthe node. A nucleus is an engineeringobject controlling and managing thecapsules of the corresponding node. Thenucleus provides a set of node manage-ment interfaces, one to each of the asso-ciated capsules. It provides basic servicesto the capsules such as providing com-munication resources and generation ofunique identifiers for identification ofengineering object interfaces.

Interactions among objects in the samecluster are efficiently provided by pro-gramming language and run-time systemspecific means. On the other hand, inter-action among objects in different clustersinvolves a configuration of engineeringobjects called a channel. A channel pro-vides support mechanisms that make itpossible to cope with inter-node commu-nication, as well as capsule failure andrelocation of cluster from one capsule toanother, possibly of different nodes.Three kinds of engineering objects areinvolved in the establishment of a chan-nel. The stub is concerned with themarshalling and representation of infor-

mation carried between the basic en-gineering objects. A stub further relies ona binder that maintains the integrity andstate of the association with the peerobject. A protocol engineering objectprovides and manages the actual commu-nication of messages between itself andits peer protocol object. The bindingsbetween basic engineering object sup-ported by channels are called distributedbindings. Group communication andmulticast involve multi-endpoint chan-nels.

When a basic engineering object inter-face is created, a corresponding en-gineering interface reference is created.Associated with this reference is infor-mation about the signature type of theinterface, a communication address to beused when establishing a binding to thisinterface, and information related toexpected non-functional capabilities ofthe channel used for the binding. A bind-ing endpoint identifier is used by thebasic engineering objects, in the namingcontext of a capsule, for identificationand selection of appropriate binding end-points.

If a channel crosses an administrativedomain boundary, the channel will likelyinclude one or more interceptor engineer-ing objects. The role of the interceptorobject may be to check and enforce vari-ous policies associated with the interac-tions, translation of interface references,as well as checking of signature types ofthe conveyed engineering interface refe-rences.

Associated with the concepts and struc-tures just mentioned are additional rulesthat form an integral part of the engineer-ing language. An engineering specifica-tion must conform to these rules. In addi-tion, an engineering specification mustidentify the necessary ODP functions tosupport the transparencies assumed bythe computational specification, and tosupport the functional distribution of anODP system.

7 Distribution Trans-parencies and ODPFunctions

As mentioned in the introduction, the dis-tribution transparencies are fundamentalfor making abstract specifications of dis-tributed systems possible. A transparencyschema is associated with a computa-

tional specification and defines the con-straints on the mapping from a computa-tional specification to an associated en-gineering specification, – the latter spe-cifies how to realise the transparencies.This mapping expands the computationalspecification with additional behaviour,and with ODP functions explicitlyrealising the functionality masked by thetransparencies.

Although described in a separate section,the ODP functions are – based on theirroles – naturally associated with the en-gineering viewpoint. ODP functions canbe realised as objects or components, i.e.groups of objects. RM-ODP indicatesdependencies among various functions.However, RM-ODP leaves the precisespecification of these facilities to otherspecification efforts. In the specificationeffort by OMG4, their CORBA ObjectServices can be considered as examplesof ODP functions. See another article onCORBA in this issue of Telektronikk [13].

Access and location transparencies areassumed to be provided by every distri-buted processing infrastructure. Thesetransparencies are provided by the funda-mental facets of the infrastructure, that is,the channel and facilities for handlinglocation independent interface refe-rences. Other transparencies can be pro-vided in combination with these, how-ever, based on selection by the applica-tion developer.

ODP functions can themselves be struc-tured and complex, and may be modelledand specified based on the RM-ODPitself. Depending on the objective of thefunction, viewpoints such as enterpriseand information may be more or lessrelevant. The computational viewpoint,however, is relevant for specifying ODPfunctions. In a computational specifica-tion of an ODP function, one can ofcourse not assume the transparency to beprovided by the function to be specified.When this function is relied upon asbeing part of the infrastructure, anabstraction of the function may be usedin a computational specification. Some ofthe ODP functions identified do not havedirect correspondence with a distributiontransparency. However, these functionsprovide useful services that can naturallybe associated with the infrastructure andreused by several applications.


4 http://www.omg.org/

The ODP functions are placed into fourcategories:

• Management functionsThese are the node management,object management, cluster manage-ment and capsule management func-tions. These functions form an integralpart of the engineering viewpoint.

Many of the further functions below aredirectly involved in supporting one ormore transparencies. With one exception,these functions can be included in theinfrastructure on a selective basis.

• Co-ordination functionsThe engineering interface referencefunction is an integral part of the en-gineering language. The other func-tions in this category are the eventnotification, the checkpointing andrecovery, the deactivation and reac-tivation, the group, the replication, themigration, and the transaction func-tion.

• Repository functionThe functions in this category are thestorage, the information organisation,the relocation, the type repository, andthe trading function. The trading func-tion is supported by a trader objectallowing other objects to announcetheir capabilities. Client objects canthen search the trader for interfacereferences according to requestedservices.

• Security functionsThey are the access control, the secu-rity audit, the authentication, the in-tegrity, the confidentiality, the non-repudiation, and the key managementfunction.

8 Technology Viewpoint

A technology specification defines thechoice and suitability of technology forthe actual implementation of the ODPsystem. It will include specification ofbasic components of enabling technologypossible based on implementable stan-dards as well as specification of the com-munication mechanisms and technologyused. The choice of technology willinfluence the achievable quality of ser-vice and other aspects related to perfor-mance.

The issues relevant in the technologyviewpoint can to a great extent be treatedseparately from the ODP systems de-velopment process as such. However, the

technology language plays an importantrole when it comes to testing of ODPsystems. The exact technology dependentconformance points are identified in thisviewpoint, and associated with confor-mance points and specifications in theother viewpoints. Additional informationmust be supplied in this viewpoint en-abling correct interpretation of observa-tions in terms of the vocabulary of speci-fications from other viewpoints. Theadditional information required for test-ing is called IXIT – ImplementationeXtra Information for Testing.

9 Architectural semantics

As the above text indicates, the RM-ODParchitecture is a rich collection of con-cepts, their relationships, and rulesaiming at covering every significantaspect of distributed processing. Ideally,the ultimate goal of this standardisationeffort should be to reach precise andsound definitions of every architecturalelement, that is, to develop an architec-tural semantics. To achieve this, onemust formalise and provide precisesemantics for every architectural ele-ment, covering every viewpoint as wellas relationships between viewpoints.

The architectural semantics work hasbeen based on interpreting given archi-tectural concepts in terms of the semanticmodel of a given formal description tech-nique (FDT), or directly in (established)mathematical terms.

This formalisation process is expected tobe beneficial in many respects. Sinnottand Turner provide an account of thebenefits in addition to a discussion onvarious aspects related to the idea ofarchitectural semantics [14]. The obviousbenefit is the avoidance of any ambiguityassociated with the architectural ele-ments. This process also provides anopportunity to compare the chosen FDTs,and possibly suggest improvements toany of the FDTs. Furthermore, if archi-tectural semantics for each viewpointlanguage is developed, this will provide auseful starting point for using the particu-lar FDT to specify an ODP system fromthe considered viewpoint.

After reducing the ambitions as com-pared to the initial schedule [14], thearchitectural semantics work group hasrecently put forward Part 4, ArchitecturalSemantics, for approval as an Inter-national Standard. In this version the

architectural semantics cover the basicmodelling concepts and the specificationconcept of Part 2, Foundations. Amend-ments to Part 4 can be expected, as de-velopments for the viewpoint languagesand a greater extent of the Part 2 con-cepts become more complete and mature.

10 Discussion

The work with RM-ODP has come to amilestone as Part 2 and Part 3 of RM-ODP have reached the level of inter-national standard/recommendation in1995. However, it is expected that newODP standards will be developed toaddress specific areas of concern [15].These efforts may in turn result in theneed for revising the RM-ODP architec-ture, as well. The following will raise afew issues indicating where RM-ODPcan be made more specific. However, aswill be explained, this may depend on theintended use of the ODP architecture. Itis not within the scope of this paper to gointo detailed discussions of these issues –merely an introduction will be given.

10.1 Viewpoint correspon-dence and viewpointrelevance

The goal of the RM-ODP framework andarchitecture is to cover all kinds of distri-buted processing. As this is a very ambi-tious goal, it should not be of great sur-prise that the ODP viewpoints have diffe-rent significance as related to variousapplication or system domains.

In this section, the information andcomputational viewpoints will be con-sidered. These viewpoints are particu-larly important as they together containevery functional aspect of a system orreference point, such as the definition ofinformation structures and constraints,and identification of computational units.RM-ODP does not prescribe any preciseway of achieving a mapping or ensuringconsistency between the two viewpoints.In many cases, the mapping between thetwo viewpoints is non-trivial, and de-pending on the kind of system or applica-tion domain in focus, the role of the twoviewpoints and the way they map to-gether will differ. This will be exempli-fied in the next few paragraphs.

In the application domain of networkmanagement, the information viewpointplays a dominant role. An entire informa-tion specification can be associated with


a reference point between a managingand a managed system, and it specifiesthe managed system as perceived fromthis reference point. Another paper in thisissue of Telektronikk provides an exampleof how to use RM-ODP in the networkmanagement application domain [7].

On the other hand, consider for examplereal-time telecom systems. In this appli-cation domain, the computational view-point will have a dominant role, asnumerous communicating components orcomputational objects are specified. Fora discussion of using RM-ODP for thespecification of GSM, see Hellan et al.[16]. In their discussion, they show howan information specification can be usedto specify constraints related to associa-tions among computational objects aswell as how various information ele-ments are associated with various com-putational objects. In this applicationdomain, the information specificationbecomes “fragmented”, as different partsof the information specification relate toand place constraints on different com-putational objects.

In the case of network management, thecorrespondence between an informationspecification and a computational speci-fication is simple, when considered froma high level. In this case, a computationalobject can be considered to correspondwith an entire system. However, the re-finement of such a high level compu-tational object under the constraint of aninformation specification, into a set ofpotentially distributed interacting lowerlevel computational objects is non-trivial.

The notion of “an ODP system” is usedextensively throughout the RM-ODPspecifications. Part 1 states: “A view-point is a subdivision of the specificationof a complete system, established tobring together those particular pieces ofinformation relevant to some particulararea of concern during the design of thesystem”. Developing a clever system- orsystems architecture is by itself a chal-lenging task, and systems or sub-systemscan be related in complex ways. Rela-tionships among viewpoint specificationsthen become more complex and the one-to-one case can no longer be assumed.Complex relationships among viewpointspecifications have not been addressedby RM-ODP.

In addition to putting the focus on thesystem, it can also be feasible to identifyinterworking reference points5 (IRPs)

between systems, and develop precisespecifications of these. One challenge notcovered by RM-ODP is then how torelate an IRP specification with corre-sponding specifications of the distributedcomponents realising the IRP. This issueis analogous to refinement of a high levelcomputational object into a set of lowerlevel computational objects.

10.2 Multiparty InterworkingReference Points

The notion of an IRP specification is use-ful in regard to specification of a binaryreference point between two systemssuch as a managed and a managing sys-tem. Such a specification is essentially aninformation specification6, and a model-based specification technique [17] isappropriate. However, cases exist wherean interaction between two systems mayrelate to the state space and interactionswith one or several other systems, aswell. This situation is often characterisedby the systems being autonomous, andthat each system has their own dedicatedview of the state space of each of theother systems.

In this case, the notion of IRP can beused to specify co-ordinated interwork-ing and behaviour among several sys-tems. A multiparty IRP specification canthen be considered as a specification ofmultiparty inter-system interworking. Acombined use of a model-based and aninteraction-based formal specificationtechnique should be considered for thespecification of multiparty IRPs.

Although transient inconsistenciesamong the systems cannot be avoided,one can avoid permanent inconsistencies.This can be achieved by means of gene-ric consistency preserving mechanisms(transactions).

10.3 Reusing and combiningspecifications

Reusing and “merging” several genericspecifications represents a particularchallenge. The generic specificationsmay need to be customised and profiledby excluding some features and addingother features. In addition, optionalityfrom the generic specification will oftenbe resolved. Features from the variousgeneric specifications may correlate inunexpected ways. The introduction ofviewpoint relative specifications compli-cates these matters. RM-ODP does notaddress the challenge of reusing andcombing viewpoint specifications.

10.4 Flexibility and evolution

Flexibility was identified as one of theobjectives of RM-ODP. Support of sys-tems evolution is an integral aspect offlexibility. The relevance of systemsevolution will vary from applicationdomain to application domain. However,precise logistics of application versionsand corresponding IRP specifications isrequired to support systems evolution.

RM-ODP Part 2 identifies the notion ofepoch as a period of time for which anobject displays a particular behaviour. Achange of epoch may be associated witha change of the type of the object. In thissense, the notion of epoch can be relatedto type evolution, versioning and extensi-bility. However, RM-ODP does not gointo any detail regarding the issue ofevolution. In particular, the co-ordinatedevolution of related viewpoint specifica-tions is a challenging task that needs tobe addressed.

11 Conclusion

The RM-ODP standards have providedsignificant contribution to the progress ofdistributed processing. The five view-points with their corresponding lan-guages, as well as the generic RM-ODPconcepts and rules, represent an im-portant base of insight in this field.

However, several challenges related tospecification and modelling of distri-buted processing and systems still remainopen. Depending on application domain,rigorous ways of relating informationviewpoint specifications and computa-tional viewpoint specifications areneeded. Refinement, composition, andevolution of multiple viewpoint specifi-


5 RM-ODP states that an interworkingreference point is an interaction point.An interaction point is a locationwhere a set of interfaces exists. Thenotion of interworking reference point(IRP) as adopted in this discussion isassumed not to be constrained by aunit of distribution or a location inspace. Thus, the set of interfaces com-prising an IRP can be distributed.

6 In [7], the author argues that it is use-ful to extend such an information spe-cification using the interface construct.

cations must be addressed. These funda-mental relationships among specifica-tions must be developed in order toprovide an adequate set of specificationtools.

In addition to the RM-ODP standardisa-tion community itself, other arenas willalso contribute to the further develop-ment of RM-ODP. Significant develop-ments are made by the Object Manage-ment Group (OMG), for examplethrough its work on the Unified Model-ling Language (UML), and the BusinessObject Architecture. Other arenasmaking contributions are various work-shops and conferences such asFMOODS7 and the OOPSLA8 works-hops on Object Oriented BehavioralSemantics. As many of the open issuesare related to concepts and rules con-cerning specification expressiveness,semantics and specification relationships,the just mentioned efforts will also con-tribute to the further development of for-mal specification techniques.

12 References

1 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Overview. Geneva,ITU, 1997. (ITU-T Rec. X.901.)(Common text with ISO/IEC.)

2 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Foundations. Geneva,ITU, 1995. (ITU-T Rec. X.902.)(Common text with ISO/IEC.)

3 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Architecture. Geneva,ITU, 1995. (ITU-T Rec. X.903.)(Common text with ISO/IEC.)

4 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Architectural Seman-tics. Geneva, ITU, 1997. (ITU-TDraft Rec. X.904.) (Common textwith ISO/IEC.)

5 Linington, P F. RM-ODP : TheArchitecture. In: Raymond, K, Arms-trong, L (eds.). (ICODP ’95) Pro-ceedings Third IFIP InternationalConference on Open DistributedProcessing. London, Chapman &Hall, 1995.

6 Iggulden, D et al. Architecture andFrameworks, APM.1017.02. Archi-tecture Projects Management Ltd,UK, 1994.

7 Lønsethagen, H. RM-ODP for Trans-port Network Modelling : An Ex-ample. Telektronikk, 94 (1), 55–66,1998 (this issue).

8 Wegner, P. Dimensions of object-based language design. In: Procee-dings of the OOPSLA’87, 168–182,1987.

9 Snyder, A. The Essence of Objects :Concepts and Terms. IEEE Software,1993.

10 OMG. The Common Object RequestBroker : Architecture and Specifica-tion, Revision 2.2. February 1998.

11 Sinnot, R O, Turner, K J. TypeChecking in Open Distributed Sys-tems : a Complete Model and its ZSpecification. In: Rolia, J et al. Pro-ceedings of the IFIP/IEEE inter-national conference on Open Distri-buted Processing and DistributedPlatforms (ICODP/ICDP’97),Toronto, Canada, May 1997.London, Chapman & Hall, 1997.

12 Johannessen, K. Engineering com-municating systems. Telektronikk, 94(1), 79–94, 1998 (this issue).

13 Solbakken, H et al. CORBA as aninfrastructure for distributed com-puting and systems integration.Telektronikk, 94 (1), 107–118, 1998(this issue).

14 Sinnott, R O, Turner, K J. Applyingformal methods to standard develop-ment : the open distributed process-ing experience. Computer Standards& Interfaces, 17, 1995.

15 Milosevic, Z, Bearman M. Towards anew ODP Enterprise Language. In:Rolia, J et al. Proceedings of theIFIP/IEEE international conferenceon Open Distributed Processing andDistributed Platforms (ICODP/ICDP’97), Toronto, Canada, May1997. London, Chapman & Hall,1997.

16 Hellan, J K et al. On the Applica-bility of an ODP-compatible Frame-work to the Specification of GSM.In: The Fifth TINA Conference,Melbourne, Australia, Feb. 1995.

17 Goldsack, S J, Kent, S J H (eds).Formal Methods and Object Tech-nology. Berlin, Springer, 1996.


7 IFIP International Conference on For-mal Methods for Open Object-basedDistributed Systemshttp://www.cs.ukc.ac.uk/research/net-dist/fmoods/

8 ACM Conference on Object-OrientedProgramming Systems, Languages andApplications.http://www.acm.org/sigplan/oopsla/

Håkon Lønsethagen is Research Scientist atTelenor R&D, Kjeller, Network and ServiceManagement Platform Unit. Currently, his focusis access network management and ATM trans-port network management. His research interestsare systems architecture, systems evolution andspecification techniques.


The following provides an example toillustrate one way to use RM-ODP1.The example is taken from the net-work management applicationdomain. This approach of using RM-ODP has been developed by ITU-TSG152. Comments will be madethroughout the example both withrespect to this particular way of usingRM-ODP as well as to what the gainsand advantages are of using RM-ODPin this application area. A few com-ments will also be made with respect tothe TINA-C3 work and their use ofRM-ODP.

1 Introduction

This example is based on the “SimpleSubnetwork Connection Configuration”management application as defined byITU-T SG15 in RecommendationsG.852.1, G.853.2 and G.854.1 [6, 7, 8].This represents one management applica-tion of several, where many are stillunder development. SG15 has developeda methodology based on RM-ODP suit-able for the purpose of transport networkmodelling which is documented in aseparate recommendation G.851.1 [9].With respect to the notion of logicallayered architecture as suggested byTMN (M.3010 – [10]) these specifica-tions address the network managementlayer.

The example will select and present partsof these recommendations to demonstratethe main features of each RM-ODPviewpoint and corresponding language.Discussion of detailed issues of theselanguages will not be made. Commentswill be made at the end of the exampleraising a few issues related to this app-roach.

The SG15 specification effort is based ona generic functional architecture of digi-

tal transport networks – G.805 [11].G.805 defines architectural concepts re-lated to functional aspects of transportnetwork resources, such as topologicalcomponents, transport entities and trans-port processing functions.

In order to provide some backgroundinformation, Figure 1 introduces the net-work architectural entities used in thisexample. Some of the definitions are“simplified” to avoid the need of pre-senting the entire G.805 model.

2 Enterprise Viewpoint

In general terms, the enterprise viewpointis concerned with the business activitiesof the specified system by focusing onpurpose, scope, and policies. The fol-lowing statement reflects the role of theenterprise viewpoint as considered bySG15. “The enterprise viewpoint is in-cluded in the network model in order to:

• document the use of the various por-tions of the model based on communi-ties of common functions (applica-tions); and

• provide a way of specifying the re-quirements upon which the model isdefined.”

A community specifies the scope of thespecific management application infocus, and comprises a set of roles, a setof actions, and a set of policies to satisfythe common objective, or contract, that isshared between the roles. A communitydescription represents a set of potentialcommunity contract instances, each ofwhich reflects a particular selection ofservice features available, and each basedon negotiation. Thus, a contract repre-sents a service with an associated qualitythat is offered in a client/provider rela-tionship by the provider to its client.

Figure 2 shows the example in the leftcolumn. Comments are provided in theright column to explain the most im-portant concepts used in the correspond-ing description. These comments do notprovide an exhaustive presentation of rele-vant issues with this respect. The metho-dology document itself (G.851.1 – [9])should be conferred for a more completepresentation. Comments may also be lo-cated in-line with the example. Italics willbe used for this purpose. Comments initalics in the right column, reflect relatedcomments by the author. This scheme willbe used for the other examples as well.

The rationale behind the enterprise view-point is to provide a de-coupling of

67

RM-ODP for Transport Network Modelling – An ExampleH Å K O N L Ø N S E T H A G E N

Telektronikk 1.1998

- topological component: An architectural component used to describe the trans-port network in terms of the topological relationshipsbetween sets of points within the same layer network.

- transport entity: An architectural component which transfers informationbetween its inputs and outputs within a layer network.

- characteristic information: A communication signal and specific transport formatwhich is transferred on a transport entity.

- layer network: A topological component that includes both transportentities and transport processing functions that de-scribe the generation, transport and termination of aparticular characteristic information.

- port: It consists of a pair of associated input/output(sink/source) of a transport entity.

- subnetwork: A topological component used to effect routing of aspecific characteristic information within a specific layernetwork.

- subnetwork connection: A transport entity that transfers information across asubnetwork, it is formed by the association of ports onthe boundary of the subnetwork.

Figure 1 Example G.805 definitions

1 Reference Model of Open DistributedProcessing [1–4]. See another paperin this issue of Telektronikk for anintroduction to RM-ODP.

2 The work on network level manage-ment of transmission systems has beentransferred to SG4 Question 18 for thestudy period 1997–2000.

3 TINA-C: Telecommunications Informa-tion Networking Architecture Consor-tium. RM-ODP is one of the foundationsof TINA [5]. http://www.tinac.com/

objectives and requirements of an ODPsystem from its realisation. The aboveexample illustrates how this aim isaccomplished. Furthermore, note that theenterprise viewpoint descriptions areapplication-driven. An important inten-tion of this approach is not to be pre-scriptive about the information elementsintroduced.


COMMUNITY sscc “Simple Subnetwork Connection Configuration”

1 PURPOSE“The objective of the community is to configure point-to-point subnetwork connectionsbetween pairs of ports, which have been previously populated on the boundary of asubnetwork.”

2 ROLE

caller “This role reflects the client of the actions defined in this community. Oneand only one caller role occurrence may exist in the community.”

provider “This role reflects the server of the actions defined in this community. Oneand only one provider role occurrence must exist in the community.”

port “This role reflects the G.805 port resource used in the actions defined in thiscommunity. Zero or more port role occurrences may exist in the community.”

sn “This role reflects the G.805 subnetwork resource used in the actionsdefined in this community. One and only one sn role occurrence must existin the community.”

snc “This role reflects the G.805 subnetwork connection resource used in theactions defined in this community. Zero or more snc role occurrences mayexist in the community.”

3 POLICYOBLIGATION OBLG_1“The provider shall support such viewing of the resource properties and relationshipswhich have been identified and allowed in the service contract with the caller.”

4 ACTION4.1 sscc1 “Setup Point-to-Point SNC”“This action sets up a point-to-point subnetwork connection between two ports on thesame subnetwork.”

ACTION_POLICYOBLIGATION OBLG_1“This action must be provided in respect to all the action policies or it fails. In the eventthe action fails, the provider shall report to the caller which action policy has been violated.”

OBLIGATION OBLG_2“The caller shall identify two ports which must be part of the community.”

A community comprises six elements:Purpose, Role, Policy, Action (withaction policies), Activity and Contract

This clause introduces the purpose andobjective of the community as a whole.

A caller role represents the behaviour ofan enterprise object that defines the ser-vice requests of a given service.

This clause introduces all the roles in thecommunity.

A provider role represents the behaviourof an enterprise object that performs theservice requests of a given service.

Other roles of a service represent be-haviour of enterprise objects, reflectingthe involvement of resources in the con-text of this service.

These statements give the overall poli-cies associated with the community.

The ACTION clause provides a list ofactions which support the purpose of thecommunity.

These policies are associated with thecorresponding action, and should statethe role and information involved. It isthe intent not to be prescriptive aboutthe information in the enterprise view-point.

Figure 2 Example enterprise

The enterprise viewpoint does not iden-tify computational interfaces. However,the notion of a community implies anabstract, high level “interface” betweenroles – in this case the caller and the pro-vider role. Whenever such an interface isdescribed, one must make some designdecisions about information and func-tionality associated with this abstract

interface. This becomes clear if one triesto use a formal language for the enter-prise specification. Thus, the position ofan enterprise specification relative to aninformation and a corresponding com-putational specification only becomes amatter of level of detail or specialisationof the specifications.


The ACTIVITY clause is used in thecase where the client has to addressseveral related (ordered) actions to theprovider as part of a service feature.

A contract is the result of negotiationreflecting the agreed selection from theset of service features provided by theservice provider.

OBLIGATION OBLG_3“In case of service establishment, the provider shall inform the caller of the subnetworkconnection identifier that is unique in the community for the duration of the subnetworkconnection.”

PERMISSION PERM_1“The caller may provide a user identifier for the requested subnetwork connection.”

OBLIGATION OBLG_4“If PERM_1 is part of the contracted service, then the provider shall use the user identi-fier, if provided, as a unique subnetwork connection identifier when communicating withthe caller.”

OBLIGATION OBLG_5“If PERM_1 is part of the contracted service and if the user identifier is not unique inthe provider context, then the provider shall reject the user identifier and inform thecaller of the rejection.”

PERMISSION PERM_2“The caller may specify the characteristics of the requested transport service (e.g.bandwidth, directionality, route selection criteria, availability, etc.). These are contractand technology specific.”

PROHIBITION PROH_1“The provider shall not satisfy the request if one or both the ports are already used in asubnetwork connection.”

4.2 sscc2 “Release Point-to-Point SNC”“This action is used to release a simple point-to-point subnetwork connection.”

ACTION_POLICYOBLIGATION OBLG_1“This action must be provided in respect to all the action policies or it fails. In the eventthe action fails, the provider shall report to the caller which action policy has beenviolated.”

OBLIGATION OBLG_2“The caller shall uniquely identify an existing subnetwork connection via its subnetworkconnection identifier.”

OBLIGATION OBLG_3“The provider shall inform the caller of the subnetwork connection identifier of the sub-network connection which has been released.”

5 ACTIVITY“None.”

6 CONTRACT“Service features subject to negotiation as part of the service contract shall include:- degree of visibility of resource (their properties and relationships); andother features which are for further study.”

The above remark is valid consideringthe functional aspects of an enterprisespecification. In addition, an enterprisespecification also provides a means ofcapturing high level requirements andobjectives associated with the computinginfrastructure and other non-functionalaspects. Infrastructure and other non-

functional aspects have not been focusedin the SG15 work.

TINA-C has adopted a somewhat diffe-rent approach with respect to the enter-prise viewpoint. A particular enterpriseviewpoint description template has notbeen developed. However, various TINAdocuments play the role of an enterprise

description as they describe businessmodels where stakeholders are identifiedrepresenting actors or agents of the ODP(TINA) system. The associated objec-tives and requirements are identified at ageneral service independent level, andnon-functional aspects are also con-sidered to some degree. The TINA busi-ness model and requirements documents

viewpoint specification


2.2.16 subnetwork2.2.16.1 Informal description

DEFINITION“A subnetwork information object represents a G.805:1995 subnetwork (seeG.805:1995 definition).”

ATTRIBUTEsignalIdentification

“A subnetwork carries a specific format. The specific formats will be defined in thetechnology specific extensions.”

2.2.16.2 Semi-formal descriptionsubnetwork INFORMATION OBJECT CLASSDERIVED FROM networkInformationTop;CHARACTERIZED BY

subnetwork PACKAGEBEHAVIOURsubnetworkPackageBehaviour BEHAVIOURDEFINED AS“<DEFINITION>”;;ATTRIBUTESsignalIdentification;;;

2.2.16.3 Formal description…

2.2.16.4 Potential relationships<linkBinds><linkConnectionIsTerminatedBySubnetworks><snIsPartitionedBySn><subnetworkHasSubnetworkConnections><subnetworkIsDelimitedBy><topologicalComponentIsDelimitedBy>

Figure 3 Example common information specification

The information specification providesan informal, a semi-formal and a formalspecification of the specified information.The formal specification technique isbased on Z [15]. The formal part will notbe elaborated on.

The semi-formal part uses GDMO with“MANAGED OBJECT CLASS” keywordchanged to “INFORMATION OBJECTCLASS” and the following restrictions:- no access specifier can be assigned

to attributes;- the REGISTERED AS clause is not

required;- no ACTIONS or NOTIFICATIONS can

be specified;- the WITH ATTRIBUTE SYNTAX

clause shall not be used.

For further details refer to G.851.1Annex B. ([16] provides an introductionto GDMO.)

The concept of potential relationships isused in the common information specifi-cation to indicate the possible relation-ship types that may apply to the objectclass or its subclass. Application specificspecifications will state which of theserelationship types will be used in themanagement application in question.The relationship types are included inthe common specification to provideclarity and readability. The list is notintended to be complete.

thus set the stage for further TINA infor-mation and computational specifications.

From the above discussion, it is con-cluded that requirements capture is theforemost objective of the enterpriseviewpoint.

3 Information Viewpoint

The information viewpoint is concernedwith the information that needs to bestored and processed, and the semanticsof the information.

G.853.2 “Subnetwork connection man-agement information viewpoint” [7]represents the information specificationrelated to the enterprise specification inG.852.1. However, G.853.2 is in turnbased on a management application inde-pendent common information specifica-

tion G.853.1 “Common elements of theinformation viewpoint for the manage-ment of a transport network” [12]. Thecommon information specification is amanagement application independentdescription of information objects andrelationship classes, representing G.805transport network resources. G.853.1then provides a basis for applicationspecific information specifications. Thelatter can extend the common classes byspecifying additional subclasses. Addi-tional relationship classes can also bespecified in application specific informa-tion specifications.

The specification templates used aremodifications of the GDMO [13] andGRM [14] templates respectively. Themodification of GDMO will be explainedalong with the example presented. GRMis extended with the opportunity of pro-

viding more than just one object classlabel in the “COMPATIBLE WITH”clause. By this opportunity, one avoidsthe need of writing down “duplicate”relationships.

Figure 3 shows an example selected fromG.853.1, the common information speci-fication. It is provided to show oneexample of an information object classdefinition specified in the common infor-mation specification.

An example illustrating the full structureof an information specification is pro-vided in Figure 4. This example is se-lected from G.853.2 Annex A: “Informa-tion viewpoint for the simple subnetworkconnection management”. Thus, this isan example of a management applicationspecific information specification. Theexample shows selected parts of G.853.2


3 Import<“Rec.G.853.1”,INFORMATION_RELATIONSHIP: subnetworkIsDelimitedBy>This information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,PURPOSE><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_1>

<“Rec.G.853.1”,INFORMATION_RELATIONSHIP:subnetworkConnectionIsTerminatedByPointToPoint>This information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,PURPOSE><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_2><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:PROH_1>

<“Rec.G.853.1”,INFORMATION_RELATIONSHIP: subnetworkHasSubnetworkConnections>This information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,PURPOSE><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_3><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_4>

<“Rec.G.853.1”,ATTRIBUTE:userLabel>This information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_3><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:PERM_1><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_4><“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,OBLIGATION:OBLG_2>

4 Information object class definition4.1 ssccSubnetworkThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ROLE:sn>

4.1.1 Informal descriptionDEFINITION

“This object class is derived from subnetwork.”RELATIONSHIP

“<subnetworkIsDelimitedBy>”,“<subnetworkHasSubnetworkConnections>”

4.2 ssccSubnetworkConnectionThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ROLE:snc>


“This object class is derived from subnetworkConnection.”ATTRIBUTE

userLabel“This attribute is used to identify the ssccSubnetworkConnection”

RELATIONSHIP“<subnetworkIsDelimitedBy>”,“<subnetworkConnectionIsTerminatedByPointToPoint>”,“<subnetworkConnectionHasTSC>”,“<subnetworkHasSubnetworkConnection>”

1 Diagrams of information objects and relationship classes

subnetworkConnection

ssccSubnetworkConnection

Inheritance diagram

2 Label references(Label references are used to provide local names of information entities specified in other documents.For example:)

Full label reference Local label reference

<“Rec.G.853.1”,INFORMATION_OBJECT: subnetwork> <subnetwork>

The Import clause provides a list of infor-mation entities or concepts which havebeen specified in other documents. Cor-responding to each information concepta relevant part of an enterprise specifi-cation is referenced. This approach illu-strates how correspondence betweenthe enterprise and the information view-points is provided.

(In the following only the informaldescriptions will be presented.)

Diagrams are provided for readability.(This example does not show alldiagrams of Annex A.)

(The ‘sscc’ prefix is used throughout theRecommendation and is an abbreviationfor simple subnetwork connection con-figuration.)

(Label references are also used in otherclauses, as will become evident below.The label reference structure and syntaxwill not be covered in any more detail here.)

The mandatory relationships for thismanagement application are listed in theRELATIONSHIP section. The relation-ships are selected from the list of poten-tial relationships of the common informa-tion specification.

Additional relationships may be definedin application specific specifications.The relationship<subnetworkConnectionHasTSC>is an example of this possibility. Theactual definition will be done below.

Figure 4 Example information viewpoint specification (panel 1 of 3)


4.3 ssccSubneworkTPBidirectionalThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ROLE:port>


“This object class is derived from ssccSubnetworkTPSink and ssccSubnetworkTPSource.”

4.4 ssccSubnetworkTPSinkThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ROLE:port>


“This object class is derived from subnetworkTPSink .”RELATIONSHIP

“<subnetworkIsDelimitedBy>”,“<subnetworkConnectionIsTerminatedByPointToPoint>”

4.5 ssccSubnetworkTPSourceThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ROLE:port>


“This object class is derived from subnetworkTPSource .”RELATIONSHIP

“<subnetworkIsDelimitedBy>”,“<subnetworkConnectionIsTerminatedByPointToPoint>”

4.6 serviceCharacteristicsThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,PERMISSION:PERM_2>


“This object class reflects all the characteristics associated with the requested quality of thetransport service relevant to the subnetwork connection establishment. This object class willbe refined due to the (transport) technological dependent characteristics.”

RELATIONSHIP“<subnetworkConnectionHasTSC>”

5 Information relationship definitions5.1 subnetworkConnectionHasTSCThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1,PERMISSION:PERM_2>


“The subnetworkConnectionHasTSC relationship type describes the association between asubnetwork connection and the related quality of Transport Service Characteristics.”

ROLEtransportQualified

“Played by instances of the ssccSubnetworkConnection information object class and sub-classes”

transportQualifier“Played by an instance of the serviceCharacteristics object class.”

INVARIANTinv_1

“Several objects playing the transportQualified role may be involved in the relationship.”Inv_2

“Only one object playing the transportQualifier role may be involved in the relationship.”

(These roles are relationship roles [14]and should not be confused with rolesas identified in the enterprise viewpoint.)

(TP – Termination Point)

(From G.853.1 [12]: The subnetworkTP-Sink information object is an abstractionthat represents the potential terminationof a transport entity and the associatedunidirectional port. It also represents thepotential for connection across sub-net-works. Correspondingly, the subnet-workTPSource represents the potentialorigin of a transport entity.)



6 Static schemas6.1 ssccNotConnectedThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1, OBLIGATION:OBLG_2>,<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1, PROHIBITION:PROH_1>,<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc2, OBLIGATION:OBLG_2>


“The ssccNotConnected schema defines a schema type with two non-connected subnet-workTP information object subtype candidates to the point-to-point connection manage-ment service.”

ROLEinvolvedSubnetwork

“Played by an instance of the ssccSubnetwork information object type or sybtype.”potentialAEnd

“Played by an instance of the ssccSubnetworkTPSink,ssccSubnetworkTPSource or ssccSubnetworkTPBidirectional object types or subtypes.”

potentialZEnd“Played by an instance of the ssccSubnetworkTPSink,ssccSubnetworkTPSource orssccSubnetworkTPBidirectional object types or subtypes.”

INVARIANTINV_1

“The object playing the potentialAEnd and potentialZEnd roles are involved in aninstance of the subnetworkIsDelimitedBy relationship type with the object playing therole involvedSubnetwork.”

INV_2“The object playing the potentialAEnd role is not involved in any instance of the sub-networkConnectionIsTerminatedByPointToPoint relationship type or subtype.”

INV_3“The object playing the potentialZEnd role is not involved in any instance of the sub-networkConnectionIsTerminatedByPointToPoint relationship type or subtype”

6.2 ssccConnected…

7 Dynamic Schemas

7.1 ssccNotConnected_ssccConnectedThis information concept is related to the following enterprise entities:<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1 >.

7.1.1 Informal descriptionDEFINITIOIN

“This dynamic schema expresses the transition of two non-connected extremitiestoward two connected extremities ”

PRE-CONDITIONS <ssccNotConnected>;

POST-CONDITIONS <ssccConnected>;

7.2 ssccConnected_ssccNotConnected…

8 Attributes“None”


A static schema is used to define a stateof a system (of this kind) at an instanceof time. This global/generic (compound)state involves one or more attributes ofone or more information objects. A set ofstatic schemata is used to describe thepre-condition of a global system statetransition. Likewise, a set of staticschemata is used to describe the post-condition of a transition. It is only neces-sary to specify the static schemas thatare of interest.

The DEFINITION clause provides theoverall semantic of the global state.

The ROLE clause identifies all the staticschema roles used in descriptions ofinvariants (see below), and which objectclasses that can play each of theseroles.

The INVARIANT clause provides theapplicable attribute value constraints.These constraints can be within anobject or between objects through re-lationship constraints.

A dynamic schema identifies a particulartransition between compound states(described by static schemata).Transitions (dynamic schemata) will bereferenced and further described in acorresponding computational specifica-tion.

Attribute types will typically be defined inthe common information specification forreuse by other information specifications.The semi-formal description of attributetypes are based on the ATTRIBUTEtemplate of GDMO excluding the WITHATTRIBUTE SYNTAX clause.

Annex A to illustrate how this specifica-tion in turn corresponds to a correspond-ing computational specification.

The example illustrates how elements ofan enterprise specification are referenced

from an information specification, thusproviding correspondence between thetwo viewpoints. Furthermore, one canobserve that information entities havebeen identified and described (pre-scribed), possibly by using a formal

language. Note that an information speci-fication defines one (logically centra-lised) state space and its constraints ofan abstract system. Although possibletransitions of that state space of such asystem can be identified in an informa-


2 simple SNC performer interfaceThe simple subnetwork performer manages the set-up and release of subnetwork connections. Thesimple SNC performer interface is required to satisfy the enterprise requirements stated in:

<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc1 >,<“Rec.G.852.1”,COMMUNITY:sscc,ACTION:sscc2 >.

This interface provides basic connection set-up functionality. The operation ssccSetupSubnetworkCon-nection sets up a subnetwork connection, and the operation ssccReleaseSubnetworkConnection re-moves the subnetwork connection.

COMPUTATIONAL_INTERFACE simpleSncPerformerIfce OPERATION <ssccSetupSubnetworkConnection>;

<ssccReleaseSubnetworkConnection >;

2.1 sscc set-up SNCThis operation sets up a simple subnetwork connection between a single A-End snTP or nTP, and asingle Z-end snTP or nTP.

OPERATION ssccSetupSubnetworkConnection INPUT_PARAMETERS

subnetwork : SubnetworkId ::= (ssccSnIfce)– If the performer is associated with only one subnetwork, the subnetwork parameter of this operation isredundant and may be removed as an engineering optimization.

snpa : SnTPId ::= (snTPIfce);snpz : SnTPId ::= (snTPIfce);dir : Directionality;suppliedUserLabel : UserLabel;serviceCharacteristics : CharacteristicsId ::=

(serviceCharacteristicsIfce);

Fully qualified label reference Local reference used

<“Rec.G.853.1”,INFORMATION_RELATIONSHIP: <subnetworkIsDelimitedBy>subnetworkIsDelimitedBy>

…

<“Rec.G.853.2”,STATIC_SCHEMA:ssccNotConnected> <ssccNotConnected>

Fully qualified ASN.1 production reference Local reference used

“M.3100 : 199x : ASN1DefinedTypesModule”::Failed Failed

“M.3100 : 199x : ASN1DefinedTypesModule”::Directionality Directionality

“M.3100 : 199x : ASN1DefinedTypesModule”::UserLabel UserLabel

0 Computational interfaces to satisfy simple subnetwork connection configuration communityenterprise requirements

The simple subnetwork connection configuration enterprise requirements are met by the interfaces spe-cified in this Annex.

1 Label referencesThe following information relationships, static schema, and ASN.1 productions are referenced in thisAnnex:

In the parameter declaration to the left,snpa is the name of the formal para-meter, SnTPId is the name of the para-meter type, and “::= (snTPIfce)” declaresthe parameter type to conform to thesnTPIfce interface signature type. Theindirect type assignment is introduced toallow mapping from communicationdomain independent interface types tocommunication domain dependent inter-face types.

(Example label references.)

(snTP – subnetwork termination point.nTP – network termination point. nTP isa generalisation of networkTTP and net-workCTP. TTP – trail termination point.CTP – connection termination point. Forfurther explanations, conf. G.853.1 [12].)

Figure 5 Example computational


OUTPUT_PARAMETERSnewSNC : SNCId ::= (sncIfce);agreedUserLabel : UserLabel;

RAISED_EXCEPTIONSincorrectSubnetworkTerminationPoints : SEQUENCE OF SnTPId;subnetworkTerminationPointsConnected : SEQUENCE OF SnTPId;invalidTransportServiceCharacteristics : NULL;failure : Failed;wrongDirectionality : Directionality;userLabelInUse : UserLabel;

BEHAVIOURINFORMAL

…SEMI_FORMAL

PARAMETER_MATCHINGsubnetwork : <ssccNotConnected, ROLE:involvedSubnetwork> AND

<ssccConnected, ROLE:involvedSubnetwork> ;snpa : <ssccNotConnected, ROLE:potentialAEnd> AND

<ssccConnected, ROLE:connectedAEnd> ;snpz : <ssccNotConnected, ROLE:potentialZEnd> AND

<ssccConnected, ROLE:connectedZEnd> ;dir : <ssccConnected, ROLE:involvedSubnetwork, ATTRIBUTE: directionality> ;newSCN : <ssccConnected, ROLE:involvedPointToPointSubnetworkConnection>;suppliedUserLabel : <ssccConnected, ROLE:involvedSubnetwork,

ATTRIBUTE: userLabel> OR <> ; – – The user does not have to supply auser label value

agreedUserLabel : <ssccConnected, ROLE:involvedSubnetwork, ATTRIBUTE: userLabel> ;

serviceCharacteristics : <ssccConnected, ROLE:involvedServiceCharacteristics> ;

PRE_CONDITIONS <ssccNotConnected> ;POST_CONDITIONS <ssccConnected> ;

EXCEPTIONSIF PRE_CONDITION <inv_1> NOT_VERIFIED RAISE_EXEPTION

incorrectSubnetworkTerminationPoints ;IF PRE_CONDITION <inv_2> NOT_VERIFIED RAISE_EXEPTION

subnetworkTerminationPointsConnected ;IF PRE_CONDITION <inv_3> NOT_VERIFIED RAISE_EXEPTION

subnetworkTerminationPointsConnected ;IF POST_CONDITION <inv_1> NOT_VERIFIED RAISE_EXEPTION failure ;IF POST_CONDITION <inv_2> NOT_VERIFIED RAISE_EXEPTION failure ;IF POST_CONDITION <inv_3> NOT_VERIFIED RAISE_EXEPTION failure ;IF POST_CONDITION <inv_4> NOT_VERIFIED RAISE_EXEPTION userLabelInUse ;

;

2.2 sscc release SNC…

A parameter matching clause specifiesthe set of information objects or attri-butes that are intended to be bound tothe parameter. It specifies an informa-tion object, either directly or as a ROLEplayed in an information relationship,possibly via a static schema role as inthis example, or an attribute value of aninformation object.

(<inv_x> refers to invariants of the corre-sponding static schema. See Figure 4,panel 3.)

(While input parameters are provided inthe invocation by the caller, the outputparameters are provided in the corre-sponding termination by the provider.)

viewpoint specification

tion specification, no decision has beenmade as to how the transitions relate tointerfaces of a corresponding computa-tional or engineering specification. More-over, specific operations and their para-meters are not part of this specification.

TINA has adopted a similar approach ofusing GDMO in combination with GRMfor the information viewpoint [17].However, TINA allows specification ofoperations as a part of the informationviewpoint.

4 Computational View-point

The computational viewpoint is con-cerned with distribution by addressing

functional decomposition into computa-tional objects which interact at interfaces.

This section will follow up the two pre-vious ones, and shows an example wherecomputational interfaces for the simplesubnetwork connection configurationmanagement application are defined. Theexample is based on selected parts ofG.854.1 “Computational interfaces forbasic transport network model” [8]. Al-though SG15 has developed a templatefor specifying computational objects, thishas not been used in G.854.1. It has beenstated that computational objects are onlydefined for an application if the requiredinteractions between the interfaces (i.e.between the engineering objects realisingthe interfaces) need to be standardised.

The specification approach makes a dis-tinction between communication domain-independent computational specificationsand communication domain-dependentcomputational specifications. The latterbeing related to a communication domainlike CORBA/IIOP [18], OSI SystemsManagement/CMIP [19, 20], etc. Thedifference between the two is that thefirst only uses ASN.1 [21] abstract syn-tax4, while the latter uses a particularsyntax which will be used in the en-gineering realisation as well. In addition,a communication domain dependent spe-cification must introduce a common“top” interface type from which the otherinterfaces are derived. For example forthe GDMO/CMISE [13, 22] engineeringstyle, this would resemble the GDMO“top” managed object class [23]. Figure 5shows a communication domain-inde-pendent specification case.

In this example, we have seen how inter-faces and operations have been intro-duced as well as associated operationexceptions. Although not demonstrated,additional sequencing constraints regard-ing operation sequences may be added inthis viewpoint. The example has demon-strated how parameter values are asso-ciated with information entities ex-pressed in an information specification.Behavioural constraints have been ex-pressed by referencing static schemata ofthe information specification.

TINA has also developed a specificationlanguage for the computational view-point [24, 25]. This is a superset of the

CORBA IDL [18], allowing specificationof computational objects. The TINAapproach does not provide a “parametermatching” facility for stating correspond-ence with an information specification.

5 Engineering Viewpoint

The engineering viewpoint is concernedwith the mechanisms and functions sup-porting distribution of the computationalobjects and their interaction.

The focus of the engineering viewpoint, asinterpreted by SG15, is the infrastructuretechnology specific specifications of inter-faces and basic engineering objects andhow these are grouped into clusters. Non-functional requirements from enterprisespecifications must be considered andaccommodated when making decisionsabout basic engineering objects and howthey are grouped into clusters and capsules.

Thus far, SG15 has not prescribed anyspecific engineering specifications.However, their methodology presented inrecommendation G.851.1 indicates a wayof mapping from the information andcomputational specifications to GDMO,which in turn can be implemented usingCMISE/CMIP. Mappings to other infra-structure specific specifications are forfurther study.

It is interesting to note the difference inthe way SG15 and TINA-C interpret whatis a computational object vs. what is abasic engineering object. SG15 considersCORBA IDL [18] objects and GDMOManaged Objects as engineering objects,while TINA-C considers their ODL lang-uage [25] (a super set of CORBA IDL) asa computational language.

6 Comments

The above examples have given an indi-cation of how the RM-ODP can beapplied within one specific applicationdomain, that is, the field of networkmanagement. In this field, the modellingand specification of information repre-senting the resources to be managed is ofutmost importance. This is reflected bythe importance of the information view-point and the common information speci-fication G.853.1 [12]. The essence of thedistributed management system is de-scribed in this viewpoint, the informationto be manipulated and its semantics, andrelationships and constraints, static aswell as dynamic.

A thorough assessment of the RM-ODP-based approach developed by SG15 ascompared with other approaches will notbe undertaken here. However, a fewcomments are made, comparing theSG15-approach with the more traditionalOSI Systems Management [19] approach.

The following can be considered as maincontributions of the SG15 approach ascompared with the OSI Systems Manage-ment approach:

• The introduction and use of the enter-prise viewpoint for documenting re-quirements, policies and scope.

• Enabling information specificationswithout any coupling to distribution,centralisation or implementation.

• Enabling specification of computa-tional interfaces and a mechanism ofreferencing elements of a correspond-ing information specification, thusmapping behaviour and constraintsspecified in the information viewpointto the computational viewpoint.

To illustrate the difference between thisapproach and the OSI Managementapproach, Figure 6 is provided. Figure 6(a) shows the OSI Management app-roach. In the figure, the notion of inter-working reference point (IRP)5 is intro-duced. The concept is used here to desig-nate the interworking between two sys-tems. In the OSI Management case, anIRP specification will correspond to amanagement information specificationusing GDMO.

In the OSI Management approach, it isassumed that the communication be-tween the managing and the managedsystems is provided by the MIS-user pro-cesses in the manager and the agent rolerespectively. This solution does not sup-port the notion of multiple computationalinterfaces associated with a MIS-user ora managed system. This results in a cen-tralised solution for the managementinteractions.


4 Only a subset of ASN.1 is allowed, toprovide easier translation to other syn-taxes.

5 RM-ODP states that an interworkingreference point is an interaction point.An interaction point is a locationwhere a set of interfaces exists. Thenotion of interworking reference point(IRP) as adopted in this discussion isassumed not to be constrained by aunit of distribution or a location inspace. Thus, the set of interfaces com-prising an IRP can be distributed.

The goal of the SG15 approach has been,among others, to relieve this constraint.Instead of assuming interactions with anagent being constrained to one location,the SG15 approach is assuming a “distri-buted agent”, facilitated by a set of pos-sibly distributed computational/engineer-ing interfaces. This is illustrated inFigure 6 (b), where IRPB includes a setof associated interfaces (interface bind-ings). The managed system (or more pre-cisely, the agent process) does not haveto be located in one node any longer (norbe considered as an entity at all).

At an abstract level, the managed as wellas the managing distributed system, canbe considered as a high level computa-tional object. The encapsulated statespace of this computational object can bespecified as perceived at one of its sup-porting IRPs (e.g. IRPB), and the be-haviour of interactions on an IRP can bespecified in terms of changes to this statespace. In this way, an IRP is only oneview of the state space encapsulated bythe computational object (the manageddistributed system). The figure furtherillustrates a sub-structure of such acomputational object. This sub-structureis just an example, as there exist nume-rous ways of realising such a distributedsystem (computational object). The in-ternal structure of this high level com-putational object will be hidden from thespecification of the IRP.

Extending informationspecifications with interfaces

The SG15 approach, by the combinationof information and computational inter-

face specifications, provides a means ofstating IRP specifications of the kindillustrated in Figure 6 (b). However, asthe above example has shown, one facetof the SG15 information specification isthat it does not identify any operations orinterfaces. These are instead identified inthe computational viewpoint. However,it is a rather elaborate task to relate acomputational specification to the infor-mation specification. Accordingly, it isalso a challenging task for the reader tocomprehend and relate the separate spe-cifications.

Therefore, it could be a good idea toextend information specifications byallowing the notion of interfaces to beused with such specifications. The RM-ODP definition of the information view-point and language does not preclude theuse of interfaces within the informationviewpoint. A mechanism allowing speci-fication of sequencing constraints amongoperations may also be useful.

The issue of extending information speci-fications with interfaces is not exclusive-ly relevant to the field of network man-agement. As long as it is appropriate touse a model-based specification tech-nique [26] (i.e. the specification tech-nique assumed for the information lan-guage), and one wants to specify a sys-tem from the perspective of an IRP, itcan be useful to extend such an IRP-related information specification withinterfaces. In such a case, an interfaceinstance has a natural correspondencewith the lifetime of an information object(instance) or the system instance itself.Due to the correspondence between inter-

faces and information objects, it seemsnatural to develop an interface constructto be used with the information language.Pre- and post-conditions related to theexistence of information objects will thenalso naturally apply to the existence ofcorresponding interface instances, aswell.

An information specification with inter-faces and sequencing constraints can beconsidered as a refinement of the corre-sponding information specification with-out these constructs. By enabling thisrefinement step within one language, therefinement task will be easier and moremanageable, particularly due to improvedreadability. IRP specifications, or infor-mation specifications with interfaces, canbe considered as a merge of the informa-tion and the computational viewpoints.Furthermore, it will be possible to com-pile such an information specificationand generate stubs and skeletons for en-gineering objects according to the choseninfrastructure technology.

The formal specification language Z orany object-oriented extensions of Z [27],extended with an interface construct anda means of expressing sequencing con-straints, seems to be an attractive lan-guage for the specification of IRPs. Byusing a formal language, the support forvarious consistency checking can betaken advantage of.

To conclude this section, the issue ofgeneric interface is addressed. Althoughnot shown in the above example, thecomputational specification G.854.1includes several interface specifications


MIS-user(agent role)

Managed open system

MIS-user(manager role)

Managing open system

IRPA IRPB

MIS-user An application making useof systems managementservices [19].

IRP Interworking Reference Point.

Managing (distributed) open system

Managed distributed open system

(a) (b)

Interface binding

Computational - orBasic EngineeringObject

(Engineering) Node

Figure 6 OSI Management vs. distributed management

used for reading (querying) information.Often, significant specification effort isneeded to allow sufficient capabilities forquerying information. A more efficientapproach as seen from a specificationperspective, is to provide a generic inter-face allowing queries based on a querylanguage. This way, query types do thennot need to be specified in advance, andmay be dynamically developed and in-voked on the interface. However, non-functional requirements associated withthe use of this general purpose interfaceare likely to be needed.

7 References

1 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Overview. Geneva,ITU, 1997. (ITU-T Rec. X.901.)(Common text with ISO/IEC.)

2 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Foundations. Geneva,ITU, 1995. (ITU-T Rec. X.902.)(Common text with ISO/IEC.)

3 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Architecture. Geneva,ITU, 1995. (ITU-T Rec. X.903.)(Common text with ISO/IEC.)

4 ITU-T. Information technology :Open distributed processing : Refe-rence Model : Architectural Seman-tics. Geneva, ITU, 1997. (ITU-TDraft Rec. X.904.) (Common textwith ISO/IEC.)

5 TINA-C. Overall Concepts and Prin-ciples of TINA, Version 1.0. 1995.

6 ITU-T. Management of the transportnetwork : Enterprise viewpoint forsimple subnetwork connection man-

agement. Geneva, ITU, 1996. (ITU-TRec. G.852.1.)

7 ITUT-T. Subnetwork connectionmanagement information viewpoint.Geneva, ITU, 1996. (ITU-T Rec.G.853.2.)

8 IUT-T. Management of the transportnetwork : Computational interfacesfor basic transport network model.Geneva, ITU, 1996. (ITU-T Rec.G.854.1.)

9 ITU-T. Management of the transportnetwork : Application of the RM-ODP framework. Geneva, ITU, 1996.(ITU-T Rec. G.851.1.)

10 ITU-T. Principles for a Telecommu-nications management network.Geneva, ITU, 1996. (ITU-T Rec.M.3010.)

11 ITU-T. Generic functional architec-ture of transport networks. Geneva,ITU, 1995. (ITU-T Rec. G.805.)

12 ITU-T. Common elements of theinformation viewpoint for the man-agement of a transport network.Geneva, ITU, 1996. (ITU-T Rec.G.853.1.)

13 ITU-T. Information technology :Open Systems Interconnection :Structure of Management Informa-tion : Guidelines for the definition ofmanaged objects. Geneva, ITU,1992. (ITU.T Rec. X.722.) (Commontext with ISO/IEC.)

14 ITU-T. Information technology :Open Systems Interconnection :Structure of management information: General Relationship Model.Geneva, ITU, 1995. (ITU-T Rec.X.725.) (Common text withISO/IEC.)


Håkon Lønsethagen is Research Scientist atTelenor R&D, Kjeller, Network and ServiceManagement Platform Unit. Currently, his focusis access network management and ATM trans-port network management. His research interestsare systems architecture, systems evolution andspecification techniques.


15 Spivey, J M. The Z Notation : AReference Manual, 2nd ed. PrenticeHall, 1992. (International Series inComputer Science.)

16 Kåråsen, A-G. The structure of OSImanagement information. Telektro-nikk, 89 (2/3), 90–96, 1993.

17 TINA-C. Information Modeling Con-cepts, Version 2.0. April 1995.

18 OMG. The Common Object RequestBroker : Architecture and Specifica-tion, Revision 2.2. February 1998.

19 ITU-T. Information technology :Open Systems Interconnection : Sys-tems management overview. Geneva,ITU, 1992. (ITU-T Rec. X.701.)

20 ITU-T. Common management infor-mation protocol specification forCCITT applications. Geneva, ITU,1991. (ITU-T Rec. X.711.)

21 ITU-T. Information technology :Abstract Syntax Notation One(ASN.1) : Specification of basic nota-tion. Geneva, ITU, 1994. (ITU-TRec. X.680.) (Common text withISO/IEC.)

22 ITU-T. Common management infor-mation service definition for CCITTapplications. Geneva, ITU, 1991.(ITU-T Rec. X.710.)

23 ITU-T. Information technology :Open Systems Interconnection :Structure of management information: Definition of management informa-tion. Geneva, ITU, 1992. (ITU-TRec. X.721.) (Common text withISO/IEC.)

24 TINA-C. Computational ModellingConcepts, Version 3.2. May 1996.

25 TINA-C. ODL Manual, Version 2.3.July 1996.

26 Goldsack, S J, Kent, S J H (eds.).Formal Methods and Object Techno-logy. Berlin, Springer, 1996.

27 Stepney, S, Barden, R, Cooper, D.Object Orientation in Z. Berlin,Springer, 1992.

This paper presents a framework forconfiguration design of object-orientedcommunicating systems. Systemcharacteristics depend on the distri-bution of computing tasks betweencomputing resources and many distri-bution schema are normally valid.Selection of the best overall distri-bution schema is a difficult optimiza-tion problem that has been studied inthe context of file allocation and taskallocation. Each distribution schemarequires a specific support from thedistributed processing environment.QoS attributes are used to guide therefinement of a computational view-point specification into an engineeringviewpoint specification. Using work-load information, hierarchical clusteranalysis is proposed as a heuristicmethod to select and modify engineer-ing clusters.

1 Introduction

The size and complexity of communi-cating systems span from a few com-puters interconnected on a local area net-work to global telecommunications net-works. However, whatever the size andcomplexity, all communicating systemsare interconnected by a network. Al-though the capacity of both wide areaand local area networks is rapidly in-creasing, network interconnectionusually results in different communica-tion characteristics than communicationwithin a single machine; lower band-width, longer message delay, otherfailure semantics, other security threats,etc. Design and configuration of commu-nicating systems must take into accountthe network characteristics. Often, addi-tional software components are required,e.g. in order to handle faults, to whatwould be necessary with a single com-puter. Also, the configuration of systemcomponents depends on the networkcharacteristics.

In this paper, we use the term “engineer-ing” to denote the assignment of com-puting tasks to computing resources,normally with the objective to achievethe overall best possible service. Com-municating systems are not new, andthere is a rich literature on engineeringaspects such as task allocation (assign-ment) (e.g. [34, 2, 42, 7]) and loadbalancing (e.g. [29, 6]). The largevolume of work related to engineering isan indication of the theoretical challenge,the practical requirements, as well as the

diversity in considerations and systemconstraints.

In this paper, the focus is on object-oriented communicating systems andarchitectures. Some of the current re-search into architectures and techno-logies for future telecommunication sys-tems, e.g. the Telecommunication Infor-mation Network Architecture (TINA)[5], is based on object-orientation. Man-agement of telecommunication networksand services is a domain where object-oriented technology is increasing inimportance. Many teleoperators have orhave had systems dedicated to the man-agement of a specific technology. Thisscenario is illustrated in Figure 1 whereeach technology (PDH, PSTN, etc.) ismanaged by one or more systems consti-tuting a vertical slice through the logicalmanagement layers of the TMN architec-ture [23]. The result is (hopefully) a tech-nically efficient solution within eachdomain. However, the overall architec-ture lacks horizontal integration, result-ing in more difficult management acrossdomains. Integration between systems is

facilitated by manual operations, and theorganizational efficiency suffers. Inaddition, some data elements are nor-mally replicated between managementdomains, and the lack of integrationmakes it more difficult to maintain con-sistency. Hence, reduced data quality isa likely result of the vertically integratedarchitecture. Horizontal integration isrequired to achieve common manage-ment between technology domains. Thisscenario is shown in Figure 2 wheresome element management aspects arestill handled by technology specific sys-tems, while network and service manage-ment functions are handled by generic(technology independent) managementsystems. The result is better organiza-tional efficiency with reduced need formanual operations. Horizontal integra-tion also contributes to better data qua-lity. However, the technical efficiencymay be reduced with increased distancebetween components, which was (orwould be) located together with verticalintegration. A communication architec-ture based on the principle of a softwarebus for interaction between objects, e.g.

79

Engineering Communicating SystemsK N U T J O H A N N E S S E N

Telektronikk 1.1998

Servicemanagement

Networkmanagement

Elementmanagement

PDH SDH PSTN ISDN ATM . . .

PDH

Servicemanagement

Networkmanagement

Elementmanagement

Order handling Accounting/billing

Customercare

Networktopology

Pathmanagement

Trafficmanagement

Fault Test Configuration Security

SDH PSTN ISDN ATM . . .

. . .

. . .

. . .

Figure 2 Horizontal management integration

Figure 1 Vertical management system integration

CORBA [37], offers great flexibility inlocation of objects. By using technologybased on this principle together with pro-per engineering, we may aim for both thefunctionality resulting from horizontalintegration and the performance providedwith vertical integration.

Components of communicating systemscan fail during operation, and the load onthe systems will change over time. Inboth cases, there is a need for reconfigu-ration. Efficient reconfiguration is onlypossible with support from the run-timeenvironment. Communicating systemsare able to continue operation with somereduction in performance and dependa-bility1 with one or more failures. Perfor-mability analysis (e.g. [36, 20]) is theanalysis of the combined effect of perfor-mance and dependability on operationalsystems, and a performability manager[16] can use this analysis to maintain arequired service level.

In principle, the capabilities that allowreconfiguration of systems in response tofailures and change in load also make itpossible to tune performance while thesystems are in operation. Hence, it couldnaïvely be assumed that engineering is ofminor importance during the develop-ment phase. Although communicatingsystems may allow reconfigurationduring operation, this freedom is nor-mally restricted by the components of thesystem. These components are identifiedand designed as part of the system de-velopment, when different system struc-tures are analyzed to select the best set ofcomponents. The knowledge that isgained through this analysis is also ofvalue when the system is put into opera-tion. Further, more fundamentally, theengineering effort during developmentestablishes confidence that the system –with specific configurations – will beable to meet service requirements.

In general, system specifications (orsome parts of these) can be classified asbeing either functional or quantitative.The functional specification prescribes“what the system shall do” while thequantitative specification defines “howwell”. In this paper, the functional speci-fications are taken as given, and conceptsand techniques are presented that facili-tate quantitative modelling during thedevelopment phase.

1.1 Outline

The reference model for open distributedprocessing (RM-ODP) is a useful frame-work for design of distributed systemsand is presented in section 2.

The next subsection presents an overviewof the allocation problem of object-ori-ented systems. The object model itself issufficient for functional analysis (e.g.specification validation), but informationabout the computing infrastructure(nodes and network) is required for quan-titative analysis. Hence, objects must beassociated with concrete computationalresources.

Interaction between objects must besupported by a run-time environmentwhere the objects are assigned to differ-ent nodes. The required support from theinfrastructure can be expressed as qualityof service attributes as explained in sec-tion 3.

Performance engineering is a central partof a quantitative analysis, and techniquesare available for use during system de-velopment. Important concepts fromperformance engineering are presentedin section 4.

In section 5, the general concepts fromperformance engineering and analyticalsystem analysis is applied to communi-cating systems. Workload modelling ispresented together with system andmodel constraints, and possible solutiontechniques are identified.

1.2 The problem

Engineering of communicating systemsis concerned with allocation of entities –in this case objects – to the computingresources that are available. The alloca-tion should result in a configuration thatmeets the requirements to the services.Requirements at a high level can bestated in terms of functionality, qualityand cost. Performance and dependabilityare aspects of quality and can be ex-pressed as constraints (e.g. average inter-active response time less than ∆ seconds)associated with the functional require-ments and capabilities. Often, we seek asystem configuration (or architecture)that minimizes the total cost of the sys-tem. Engineering the distribution of com-municating systems is clearly an opti-mization problem. In operational re-search this type of problem is generally

known as the assignment problem [46].The problem is visualized in Figure 3,where application objects map to nodes(the computing resources) which areinterconnected by some communicationnetwork. An optimal solution to theallocation problem as formulated is nottrivial. Even so, the above problem state-ment is a simplification. The problem isactually modified by the solution to theproblem: interaction between applicationobjects assigned to different nodes mustbe supported by distribution supportobjects not present in the original model.Distribution support objects performbasic communication functions (whichare always required) and support therequired quality of service associatedwith interactions. Distribution supportobjects are often allocated to the samenode(s) as the supported applicationobjects, but can also be assigned to sepa-rate nodes. This is shown in Figure 4.

2 Open DistributedProcessing

The reference model for open distributedprocessing (RM-ODP) [25, 26] is both aframework for discourse and a basis forspecification of concrete architectures forobject-oriented distributed processing.This section identifies and describes thesub-set of these concepts that is impor-tant to engineering of communicatingsystems2. General introductions to ODPconcepts are found in [40, 33].

2.1 Viewpoints

This section provides a brief discussionof viewpoints and their relevance to dis-tribution engineering. A number ofdifferent abstractions of a system is pos-sible. These abstractions are called view-points in RM-ODP and are formed by aselected set of architectural concepts.The reference model identifies five view-points as necessary and sufficient:

• Enterprise viewpointThe purpose and policies of the ODPsystem are issues in the enterpriseviewpoint. In our context, the securitypolicy is of particular interest.


2 RM-ODP use the term “system” in ageneral sense as “something of inte-rest as a whole or as comprised ofparts” [25].

1 The functionality of a system can bereduced when components fails, i.e.the availability of functions is reduced.


Objects

Physicalresources

mapping

Node

Link

Figure 3 The assignment problem

cluster assignment

object assignment(implied)

= application object

cluster

= distribution supportobject

Figure 4 The effect of distribution on the assignment problem

• Information viewpointThe information viewpoint is con-cerned with the static and dynamicaspects of information in the ODP sys-tem and will not be addressed further.

• Computational viewpointIn the computational viewpoint, anODP system is a collection of objectsinteracting at interfaces. Hence, thecomputational viewpoint enables dis-tribution (e.g. partitioning, fragmenta-tion and communication). Conceptsfrom this viewpoint are discussedfurther in section 2.2.

• Engineering viewpointThe focus of the engineering viewpointis on the mechanisms and functions inan ODP system that supports distribu-tion. In a sense, the computationalabstraction prepares for distribution(interaction between objects are ex-posed) while the engineering view-point provides a grouping of objectsinto larger units (clusters) that can bedistributed within an ODP system.Concepts from this viewpoint are dis-cussed further in section 2.3.

• Technology viewpointThis abstraction is close to implemen-tation, and the technology that is se-lected for the implementation. Thetechnology viewpoint will not be dis-cussed further in this paper. However,a more complete engineering analysisthan presented in this paper, will alsotake into account technology specificparameters.

The computational and engineeringviewpoints are essential in our context,and key concepts from these viewpointsare described in the following two sub-sections.

2.2 Computational viewpoint

The computational viewpoint is anabstraction which focuses on objectsinteracting at interfaces. Interactions canbe of three kinds: signals, operations andflows3. Signals are atomic interactionswith unidirectional communication. Thestructure of a flow is important to both

the producer and the consumer(s) of theflow. However, with respect to the distri-buted processing environment, a flow isan abstraction with no visible, internalstructure.

Operations are either announcements orinterrogations. Announcements are inter-actions (sent) from a client to a server,while interrogations consist of two inter-actions: first, an invocation by the clienton the server and secondly, a terminationreturning information to the client.

In order for an interaction to take placebetween two (or more) objects, a bindingmust be established between the objects.A binding is either explicit, i.e. estab-lished through a binding action of arequesting object, or implicit, i.e. estab-lished when required by the infrastruc-ture of the distributed system. A direct(primitive) binding is possible betweentwo objects, while a binding betweenmore than two objects is performed bya separate binding object.

2.3 Engineering viewpoint

The engineering viewpoint prescribes animplementation in terms of engineeringobjects, nodes, nucleus, capsules andcluster, and relations between these con-

cepts. A node contains a nucleus (e.g. theoperative system), a number of capsulesand a capsule manager. Each capsule is acollection of objects forming a singleunit for the purpose of encapsulation ofprocessing and storage, e.g. an applica-tion process. Each capsule may contain anumber of clusters together with a clustermanager. The cluster is a collection ofengineering objects forming a distribu-tion unit (e.g. distribution functions applyto clusters, not to single objects).

Bindings between engineering objectsare either local or distributed. A channelis required for a distributed binding. Thechannel is a configuration of special en-gineering objects (stubs, binders, proto-col objects and interceptor objects) be-tween interfaces. A stub object is res-ponsible for local transformations of theinteractions in the channel, the binderobjects maintain a distributed bindingbetween the interacting objects, the pro-tocol objects perform the communicationprotocol functions, and the interceptorobject may perform required transforma-tions as well as monitor and enforce poli-cies on the permitted interactions. Anexample channel is shown in Figure 5.

In the engineering viewpoint specifica-tion, a particular allocation of objects toclusters is selected from the set of pos-


3 RM-ODP distinguishes between inter-actions that may not be visible andinterfaces that are visible. This distinc-tion is reflected in the terminology.Hence, a “flow” is an interaction thatcan be made visible across a “stream”interface.

Server

Stub

Binder

Protocol

Client

Stub

Binder

ProtocolInter-ceptor

Controlinterfaces

Channel

interactions

Figure 5 Channel in support of distributed binding

sible allocations allowed by the compu-tational viewpoint specification. In thispaper, the allocation of object to clustersis called the distribution schema. Itshould be noted that the distributionschema does not (necessarily) includeassignment of clusters to capsules (pro-cesses) on particular nodes. However,derivation of the distribution schemata isbased on a (possibly idealized) specifica-tion of available computing resources.

2.4 Distributed processingenvironment and distri-bution services

An attractive feature of ODP systems isthe (promised) set of capabilities offeredby the distributed processing environ-ment (DPE). These capabilities are avail-able to construction of ODP systemseither explicitly, as services (ODP func-tions), or implicitly through distributiontransparencies.

Distribution transparencies allow thedeveloper to focus on the design andbuild of his local functions withouthaving to know the implementation orlocation of co-operating functions. Ineffect, a distribution transparency hidessupporting services as well as implemen-tation issues from the developer. Theresult is reduced complexity as seen froman application perspective, but at the costof increased complexity of the infra-structure [43]. The reference model (RM-ODP) identifies the following transpar-encies:

• Access transparency masks differencesin data representation and invocationmechanisms (i.e. protocols).

• Failure transparency masks from anobject the failure of other objects (orthe object itself) to enable fault tole-rance.

• Location transparency masks the useof location information from bindingactions.

• Migration transparency masks from anobject the systems’ capability ofmoving that object.

• Relocation transparency masks reloca-tion of an interface from other inter-faces bound to that interface.

• Replication transparency masks theuse of replicated objects in support ofan interface.

• Persistence transparency masks froman object the activation and deactiva-

design to detailed implementation. Eachlevel of abstraction makes some charac-teristics of the system visible, while othercharacteristics are disregarded. We usethe term “non-functional” to denoterequirements or properties associatedwith the functional aspects that are de-fined at a lower level of abstraction.These properties are used (together withother information) to guide the refine-ment or transformation into a more de-tailed specification. Location of objectsand clusters (the computing tasks) is seenas a refinement of the computational spe-cification into an engineering specifica-tion.

The notion of “non-functional” require-ments is similar to QoS as used in [22],which identifies QoS requirements onobjects (e.g. capacity), on interactions(e.g. timeliness and security) and asso-ciated with content (e.g. integrity). How-ever, on operations only a subset of theQoS characteristics identified in [22] isrelevant (e.g. stream oriented require-ments such as jitter may not be relevant).

In general, QoS requirement can bestated as attributes from three per-spectives:

• OfferedThese are QoS attributes associatedwith an interface supported by a serverobject and thus available for inspectionand selection by a client.

• RequiredThese are QoS requirements expressedby client objects and which must bemet by server objects (and the distri-buted processing environment) to havea successful binding.

• ExpectedA server object may express QoSrequirements to be met by the clientobject. Such requirements are lessintuitive than offered and requiredQoS, but are equally relevant. Oneexample is traffic shaping on broad-band stream interfaces. Another ex-ample is a banking application wherethe bank expects the client (customer)to support security services (e.g.authentication and integrity) on inter-actions.

In addition, the agreed QoS is the nego-tiated QoS between the client and theserver based on the required, offered andexpected QoS requirements.


tion of other objects (or the objectitself).

• Transaction transparency masks co-ordination between objects to achieveconsistency.

In contrast to distribution transparencieswhich are hidden from the application,ODP functions (also known as DPE ser-vices) are accessed directly from theapplication code, and are a collection offunctions that are applicable to the con-struction of distributed processes [26].The reference model identifies fourgroups of ODP functions:

• Management functionsThese functions are related to manage-ment of nodes, objects, clusters andcapsules.

• Co-ordination functionsThis group includes functions for eventnotification, checkpoint and recovery,object grouping, replication, objectmigration and transaction processing.Note: While migration transparencymasks from the object that it is beingmoved, the DPE provides capabilitiesallowing other objects to control objectmigration.

• Repository functionsStorage functions, relocation functionand trading functions are part of thisgroup. A trader is a support servicematching requests for service withobjects offering a compatible service[27].

• Security functionsThe reference model identifies a set ofsecurity services equivalent to thesecurity services defined in the secu-rity framework [5], i.e. authenticationand access control, integrity and con-fidentiality, non-repudiation as well assecurity audit and key management.

The capabilities of the DPE reduces theburden on the developer. However, in adeployed ODP system, distribution ser-vices are activated and will influence theperformance of the system. The effect ofthis influence is not obvious and is anadditional challenge to performance en-gineering.

3 Refinement ofspecifications

During development, a system is definedat several levels of abstraction from aninitial high level specification through

The following subsections describe howsecurity and dependability requirementsare expressed as QoS attributes on inter-faces and how model refinement isguided by a set of transformation rules.

3.1 Security requirements

Security requirements are often expres-sed in terms of confidentiality, integrityand availability and are supported bysecurity services. A general frameworkof security services is given in [24],which identifies the following five ser-vice classes:

• Authentication• Access control• Confidentiality• Integrity• Non-repudiation.

Each class may contain more specializedservices, and [24] identifies a total of 14security services. Security services areabstractions and do not (as the namecould indicate) identify any particulartype of implementation. In fact, a secu-rity service can sometimes be realized bydifferent security mechanisms, dependingon the context. Encipherment is an ex-ample of a mechanism which can supporta number of services. Some mechanismsare pervasive, i.e. not specific to a subsetof security services, and are in principleuseful to all services. Trusted functional-ity and audit trail are examples of suchmechanisms.

Engineering of the security requirementscan be organized into three steps:

1. First, security requirements are statedusing QoS attributes which identifysecurity services.

2. Second, security mechanisms areselected to suit the distribution be-tween client and server objects, e.g.confidentiality using access control ispossible within a single cluster ornode, while confidentiality must besupported by encipherment wheninformation is communicated acrossan exposed network.

3. As the final step, a specific implemen-tation of the security mechanism isselected, e.g. a large number of en-cipherment algorithms are (or may be)available.

3.2 Dependability require-ments

Dependability [31] is expressed by anumber of attributes; usually related to

• reliability• availability• safety4.

Dependability objectives are expressed interms of the three dependability attri-butes, and the systems are designed tomeet these objectives through the use ofdependability techniques. Dependabilityis designed by observing

• fault tolerance• fault prevention• fault removal• fault forecasting.

Of these techniques, fault tolerance is thecapability of a system to continue opera-tion (possibly with reduced performance)in the presence of faults; a fault ismasked and not seen as a failure from theenvironment (e.g. the user). The aim ofthe other techniques is to remove faultsbefore the system is put into operation.As we are concerned with system charac-teristics resulting from the distribution ofobjects and clusters, the techniques forfault tolerance handling is of most rele-vance.

While security attributes state the permis-sible capabilities offered by an object, thecorresponding dependability attributesstate the ways in which the object is ableto fail5. A failure is manifested in afailure behaviour (the failure semantics)and the fault tolerant capabilities must beconstructed accordingly. Failures can beclassified as timing or value failures [8].Timing failures can further be identifiedas early, late or omission timing failures.

The failure semantic of an object isexpressed as a subset of the set of failureclassifications:

Dependability ::= SEQUENCE

failureModeFailureModesOPTIONAL,

-- failureMode is only-- present as part of the-- offered QoS expressed-- by a server object

availabilityDependabilityMeasureOPTIONAL,

reliabilityDependabilityMeasureOPTIONAL

FailureModes ::= BIT STRING unknown (0)valueFailure (1),timingFailure (2),earlyTimingFailure (3),lateTimingFailure (4),omissionTimingFailure(5),...

DependabilityMeasure ::= REAL

Security and dependability requirementsand characteristics can be combined intoa single QoS attribute.

3.3 Transformation rules

In principle, each object in an ODP sys-tem can be assigned to a cluster indepen-dently of all other objects. The number ofpossibilities for assignment of n objectsto clusters is given by the number ofways to assign n items to subsets. Withan unlimited6 number of clusters, thenumber of possible distributions is givenby the Bell number [18]:

B(n) ≈ nn, for large n

With the number of clusters fixed to K,the number of distributions is given by[28]:

B(n +1) =n

k

k

∑ B(n − k)


4 Some authors [e.g. 8] also treat infor-mation security as an aspect of de-pendability. However, the relationshipbetween dependability and security isnot fully clarified, and for the presentdiscussion they are therefore treatedas different properties. Safety is notconsidered in this paper.

5 The failure modes of containingcluster, capsule and node do of courseinfluence the possible failure modes ofan object. Hence, the specification offailure modes on objects will be con-sidered as requirements to be sup-ported by the DPE.

6 The number of objects is an upper limiton the number of clusters.

Example: With n = 50 the number of dis-tributions is roughly 1047. If the numberof clusters is fixed with K = 5, the num-ber “reduces” to 1032.

In practical systems, restrictions arelikely to reduce the degree of freedom inobjects assignment. However, it isimpossible to manually design anoptimal7 distribution schema of manyinteresting systems. Rules are required toguide the automated transformation of acomputational viewpoint specificationinto an engineering viewpoint specifica-tion.

Transformation rules must capture boththe characteristics of the assignment pro-cess, as well as relationships betweenQoS attributes.

Transformation rules are invoked whenobject instances are allocated to differentclusters. When this happens, the inter-actions (if any) between the objects areexamined to determine if QoS require-ments are defined that requires a refine-ment of the specification (see Figure 6).

A layered approach is assumed in thetransformation, i.e. the different QoSrequirements are treated as separatetransformations. Another approach is anintegrated transformation where all QoSrequirements (on one interface) are con-sidered at the same time. There are argu-ments in favour of and against both thelayered and the integrated approach [14].The sequence in which the transforma-tions are applied is significant, and theresulting protocol hierarchies are shownin Figure 7.

We assume that all transformation fol-lows the second alternative to ensure thatall communication is protected as appro-priate.

An outline of the security transformationfunction is provided in Figure 8. Theresult of the transformation is a sequenceof specification transformation steps.Since a transformation may not result inan optimal distribution (or better than the

S(n, K ) = S(n −1, K −1) + K ⋅S(n −1, K )

S(n, K ) =1

K!(−1)

K −i

i=1

K

∑K

i

in


7 With respect to some stated objective.

DISTRIBUTION TRANSFORMATION

Problem: Client object c and server object s are to be assigned to different clus-ters.

Answer: ∆, i.e. the list of specification transformation steps to meet the QoSrequirements.

Comment: Interaction, e.g. interfaces between object c and object s are examinedto determine the need for specification transformation.

begin

∆ ← ∅ ; (* an empty set of transformations *)

if assignment(c) ≠ assignment(s) then do

forall interface ∈ interaction(c,s) ∪ interaction(s,c) do

begin

if security QoS defined on interface then

∆ ← ∆ + transformation sequence of security support;

if dependability QoS defined on interface then

∆ ← ∆ + transformation sequence of dependability support;

end

return ∆;

end

Figure 6 Distribution transformation

client object ⇔ security protocol ⇔ dependability protocol

Node A

server object ⇔ security protocol ⇔ dependability protocol

Node B

Alternative 1

client object ⇔ dependability protocol ⇔ security protocol

Node A

server object ⇔ dependability protocol ⇔ security protocol

Node B

Alternative 2

Figure 7 Security and dependability protocol hierarchies

current), backtracking is essential andthis task is made easier with a transfor-mation sequence.

3.4 Transformation example

An example computational specificationwith three objects A, B and C is shown inFigure 9 where arrows point towards theserver object in each interaction. Thisexample also illustrates that the presenceof security requirements can guide theidentification of clusters. In this case,object A expects a non-repudiation ser-vice on the interface used by object B.Normally, non-repudiation services areonly considered on interactions betweenobjects in different domains. Hence,objects A and B are most likely assignedto different clusters.

A concrete interpretation of this exampleis the following:

Object A represents an ordering service.Non-repudiation with proof of origin isused to ensure the authenticity of thepurchaser (object B) and the content ofthe order. Object B makes use of a sub-scribed information service (object C)and must present access control informa-tion to get access. Another informationservice from object C is used by object A.

This simple specification is transformedinto the engineering viewpoint specifica-tion shown in Figure 10. In this case, theoffered and required dependability attri-butes are compatible, and the dependa-bility transformations are not invoked.Authentication is supported by authenti-cation service objects (ASO), whichgenerate and validate authenticationinformation. Access control informationis added to the interaction between B andC by the AIO object; this information isreceived by the access enforcementobject (AEO) which queries the accessdecision object (ADO) to determine ifaccess is permitted.

The non-repudiation requirement intro-duces a little more complication. Thenon-repudiation service requires thesupport of an integrity service. Hence,between the object generating non-repu-diation information (NGO) and the userof this information (NUO), integrity ser-vice objects (ISO) are inserted to ensurethe integrity of non-repudiation informa-tion. In this case, the non-repudiation isfurther supported by a trusted third party(TTP).


SECURITY TRANSFORM

Problem: Client object c and server object s with security requirements shall be allocated todifferent clusters.

Answer: A sequence of engineering specification transformations (∆) is provided to meet thesecurity QoS requirements.

Comment: Security requirements are validated and adjusted to add basic security services re-quired by high-level security services, e.g. non-repudiation implies authentication andintegrity, and to remove redundant basic services, e.g. integrity is made redundant byconfidentiality.

Security capabilities are added to the model in the following order:

- access control- non-repudiation- authentication- confidentiality- integrity

This sequence is a design decision imbedded in the transformation rules.

begin

required_c ← required security capabilities from c;

expected_s ← expected security capabilities from s;

∆ ← ∅ ; (* an empty set of transformations *)

if not compatible requirements and capabilities then

error “object c and s cannot be located in different clusters with fulfilment of security require-ments”;

sec_req ← required_c ∪ expected_s;

seq_req ← seq_req ∪ basic services required by high level services;

for capability ∈ access control, non-repudiation, authentication, confidentiality, integrity do

if capability ∈ seq_req then

begin

∆ ← ∆ + new security service objects if not already present;

∆ ← ∆ + interfaces within the clusters and between the clusters;

∆ ← ∆ + remove old interface between the clusters when inline security service;

∆ ← ∆ + attach/update workload information to interfaces:

end

return ∆;

end

Figure 8 Security transformation

requires entity authenticationA

B

C

offers entity authentication,availability > 0.995

offers entity authentication,availability > 0.995

expects access control

requires entity authenticationavailability > 0.99

offers entity authentication,expects non-repudiation

(proof of origin)

Figure 9 Application model with security requirements on interactions


Of course, the transformation shown inFigure 10 is only valid – or of interest –when the three objects A, B and C areassigned to different clusters. Anotherallocation could give a different transfor-mation.

4 Performance engineering

The goal of performance engineering isto establish quantitative knowledge of theperformance of a computer system. Thisknowledge is expressed using a set ofperformance measures for the differentcharacteristics of the system. In thispaper, we are concerned with perfor-mance (real or predicted) of deployedsystems only. Other important perfor-mance issues, e.g. related to systemsdevelopment, are not addressed. Perfor-mance measures are always related to ameasurement context (measurementperiod, time and day of measurement,etc.) which should be stated togetherwith the relevant performance measure.A classification of system performancemeasures is given in Table 1.

Within the literature, both performanceevaluation and performance engineeringare encountered [15, 44]. There is noclear distinction between these terms.Historically, evaluation has roughly beenassociated with evaluation of existing,completed or nearly completed systems.However, it is well known that it isharder to remedy deficiencies in a fin-ished product – or late in the develop-ment process – than to remove the prob-lems in the design, and performance en-gineering stresses the importance ofaddressing performance in the designprocess [38].

The formulation of performance evalua-tion is simple: a workload is (thought tobe) applied to the system, resulting in aperformance prediction as shown inFigure 11. Workload is the totality ofprocessing requests submitted to asystem from the users during someperiod of time. Information system usersare normally human, but in general theusers can be both human and machine.Of course, a real workload can only beapplied to a real system, and duringdevelopment a model workload must beapplied to a model of the system.

Performance (P) is a function of both thesystem structure (S) and the workload(W):

P(S, W)

ISO NGO

TTP

ISO

NUO

A

ASO ASO

C

AEO ADO

B

ASO AIO

Cluster Cluster

Cluster

Cluster

Figure 10 Example application augmented with distribution support objects

Class Definition Example performance measure

Productivity Volume of work per unit time Throughput rate(item/time unit)

Production rate

Capacity (maximum throughput rate)

Responsiveness The time between input and corre- Response time, e.g. transaction exe-sponding output (time unit) cution time

Turnaround time, e.g. time to start anew job

Reaction time, e.g. time between a keyis pressed and the echo is presentedon the screen

Utilization The fraction of an interval in which a Hardware module utilization (CPU, I/O, component is used (for some purpose) ...)(dimension-less)

Operation system utilization

Application utilization

Database utilization

Table 1 System performance measures (adapted from [15])

Three different types of performanceengineering activities can be identified[21]:

• designThe goal of this activity is constructionof a system structure (S) which pro-vides a requested performance (p0)when subjected to a specified work-load, i.e. P(S, W) ≥ p0.

• improvementThe performance of a system (S) canbe improved if it is possible to modifythe system to a new structure S’ withP(S’, W) > P(S, W).

• comparisonWhen n system structures are possible,performance prediction aims to pro-vide an ordering between the systems:

P(S1, W) ≥ P(S2, W) ≥ ... ≥ P(Sn, W)

Several techniques are available forperformance engineering. While exactmeasurements can be obtained on anexisting system, performance predicationmust rely on a model of the proposedsystem. Mathematical models are oftenconsidered ‘best’, as analytical solutionsare sometimes obtainable. However, notall mathematical models have solutions,or unrealistic assumptions must be madein order to produce a solution. In thesecases, simulation models are attractive.Simulation is flexible, but at the cost ofprocessing and interpretation of results.Furthermore, a simulation model (only)gives results to some level of confidence.

Although important, performance en-gineering is but one aspect of systemsengineering. The methods used must beevaluated against a set of requirements[44, 38]:

• supplement (and integrate with) exist-ing methods

• ease of use

• rapid assessment

• sufficient precision

• lifecycle usefulness

• wide applicability

• cost-efficiency.

Based on the above requirements, a sig-nificant part of work in performance en-gineering applies operational analysis[38, 10, 32] or mean value analysis [19,44, 38, 15, 35, 32] rather than more ela-borate (and complex) network queuinganalysis. Operational analysis is based on

relationships between observable vari-ables over a period of operation (whenthe system exists). The power of opera-tional analysis is founded in that theserelationships are independent of distribu-tion functions (as is Little’s result). Theutilization law serves as an example onhow operational relations are established(notation is given in Figure 12), and isderived as

Other operational laws are derived in asimilar manner and can be applied toeach service centre (both technical de-vices such as CPU and disk, and humanprocessing tasks). The original formula-tions of the operational laws [3] was onlyapplicable to open queuing networks, buthave later been extended to cover alsoclosed queuing networks [9].

An example illustrates the application ofoperational analysis:

Assume that a system has been observedover some time. During this observationperiod, the system has been used (busy)75 % of the time and has processed(completed) 500 jobs (e.g. customers),and the mean service time per job is50 ms. At the end of the observationperiod, 45 jobs are either being processedor are waiting. What is the response timeof the system?

In this example, the throughput is

and the response time of the system isfound as

Mean value analysis (MVA) [38, 19] is aset of computationally efficient solutionsto both open and closed queuing net-works. Different service disciplines, e.g.infinite service, load dependent service,load-independent service, can be used toconstruct and solve a number of systemmodels using MVA.

Operational variables can be considered asample of the corresponding stochasticvariable. A drawback with both opera-tional analysis and MVA is that onlyexpectation values are computed. Higher

R =N

X=

45 jobs

15 jobs / s= 3 s

X =U

S=

0.75

50 ms / job=15 jobs / s

U =B

T=

B

T⋅C

C=

C

T⋅

B

C= X ⋅S


System (S)Performance

prediction (P)

Workload (W)

Figure 11 Performance evaluation

T observation period

Ck number of observed completions

Xk throughput

Bk busy period

Uk utilization

Nk number of customers

Mk number of interactive users

Rk residence time

Z think time (terminal user)

Vk visitation ratio

Notation

Note – A subscript denotes a specific service centeror device

Operational relationships

throughput

mean service time

utilizationU ≡

busy period

observation period≡

BT

S ≡busy period

number of completions≡

BC

X ≡number of completions

observation period≡

CT

Operational laws

Little’s law N = X ⋅ R

General responsetime law

Interactive responsetime law

Forced flow law Xk = Vk ⋅ X

R =N

X− Z

R = Rkk∑ ⋅V k

Figure 12 Operational analysis

order moments (e.g. variance) or distri-bution functions of response time, uti-lization, etc. are not available. This kindof information is normally of significantvalue when the result of analysis is inter-preted. An example is illustrative: Withan exponential response time distribu-tion, 22.3 % of all customers experiencea response time in excess of 50 % of themean value, and 13.5 % experience aresponse time twice as long as theaverage. If the response time had fol-lowed an Erlang-10 distribution (i.e. thedistribution of the sum of ten identical,independent exponentially distributedvariables), only 7.0 % of all customerswould experience a response time ex-ceeding 50 % of average and only 5.0 %would experience a response time ex-ceeding twice the average. These con-cerns are to some extent addressed withsensitivity analysis [38] which can beused to evaluate the influence on a givenperformance measure from a change ineither a performance parameter or a sys-tem parameter.

Operational analysis and MVA arefavoured by performance engineers whoargue [e.g. 44, 38] that these techniquesfulfil the set of requirements presentedabove (ease of use, etc.). More detailedanalysis, e.g. use of queuing theory, issometimes based on assumptions that donot hold for computer systems (e.g.arrival and service time distributions).

Another reason why simpler mean valueanalysis is used, is the inherent in-accuracy in the workload parameters(presented in the following subsection),which reduces the utility of detailedanalysis.

4.1 Workload

Modelling of the workload is one of themost difficult tasks of performance en-gineering. The workload is the combina-tion of service requests put on the systemfrom the environment. Performance en-gineers often identify three types ofservice based on the parameters charac-terizing the service usage [32]:

• transactionA transaction workload is the result of“infrequent” service request from alarge number of users such that theworkload is independent of the numberof active users. Hence, the workloadcan be expressed by a single arrivalintensity λ.

• batchDuring the observation period, thebatch workload is considered to berunning. Hence, there is no arrival ofnew batch jobs and the workload isexpressed by the size nj of batch job j.

• interactive (or terminal)A transaction workload results whenthe infrequent requests are appliedfrom a large number of users. If thenumber of users is smaller or the ser-vice request is more frequent, theresulting workload depends on thestate, i.e. the number of active jobs.Hence, the use of an interactive servicek is characterized by the average num-ber of users of the service togetherwith the per user intensity, i.e. (nk , λk).

The total workload on a system can beidentified as a combination of transac-tion, batch and interactive workloads.

An external service request, e.g. from auser, can be recursively decomposed to asequence of requests8 on subcomponents.This decomposition process is by someauthors called workload devolution [21].The devolved work describes serviceinvocations between components and is

independent of the rate of work, and issometimes called a static model of theworkload. The static model together withthe dynamic invocation of services (e.g.transaction intensity), defines the dyna-mic workload on system components.The static model can be derived frominspection of the system and softwarestructure. Figure 13 illustrates how in-vocation of services at some level iresults in invocation of services fromcomponents at the next level. Serviceinvocation between two adjacent levelsof abstraction can be described as an ni ×ni+1 matrix

where ni is the number of components atlevel i. From this specification it is easyto compute the invocation of the low-level n services as

Of course, many execution graphs are notstrictly hierarchical as presented inFigure 13. Cycles within the graph arepossible as a result of direct or indirectrecursion. In such cases, the elements of

must be replaced by the average

number of invocations with the loopsremoved.9

Ci~

C~

= Co~

× C1~

×K ×Cn~

Ci~

= ckl( )


8 It is useful to separate between servicerequests on an abstract machine andoperations on a specific physical con-figuration. This separation allows formapping to different implementationsfrom the same basic model.

Level i-1

Level i

Level i+1

A

B C D

FE G

= (sub) component

= service

Legend:

Figure 13 Generalized system structure (example)

9 This is always possible in a real (andstable) system where the number ofrecursive invocations must be finite.

4.2 Example

A simplified example from telecommuni-cation trouble management illustratesworkload modelling: Customers contacta service centre to notify of some fault inthe network (e.g. missing dial tone). Atthe service centre, the following opera-tions can be performed (also shown inFigure 14):

1 Information is retrieved on

- customer

- current network faults possiblyaffecting the customer

- the customer service history

2 Testing of access equipment

3 Create trouble ticket

4 Update customer service history.

The workload can be decomposed intodatabase requests, CPU requirements andcommunications requirements (the low-level services). An example decomposi-tion of one service request is shown inFigure 14: The report failure task is in-voked by the customer. The customerinformation is always retrieved and isalways updated, while line test is onlyperformed for 60 % of reported failuresand repair is only requested for 30 % ofall reported failures.10 Total workload onphysical resources is then calculated as:

where the resulting vector is workload on(CPU1, CPU2, Disk1, Disk2, Com1), andstated in terms of CPU cycles, diskaccess and message length.

5 Distributionengineering

The objective of distribution engineeringof systems is to identify an optimalassignment of objects to computingresources. The next subsection explainsworkload modelling of interactingobjects. Subsequently, constraints on theoptimization problem11 are identified.Different optimization objectives are pre-sented in section 5.3 and an overview ofpossible solution techniques are given in5.4.

5.1 Workload modelling

The workload model contains a staticpart, i.e. how objects interact, as well as adynamic part, i.e. the frequency of inter-action as described in section 4.1. It isuseful to classify objects as either coreobjects or user objects such that there isno interaction between user objects. Thepurpose of this classification is to sepa-rate the workload generating part, e.g. theuser objects. The total workload is thenthe sum of work generated by all userobjects.

The static structure of the workload isderived from object behaviour informa-tion. For each run (activation) of a userobject u we record the number of invoca-tions of operation o on core object s by

object c as Restricting the work-

load to transactions, the interaction fre-quency between objects is then computedas

s(c,s,o)u

.

W~

=

1 1 0.6 0.3

200000 0 10 0 0

100000 0 4 0 0

0 150000 0 0 3000

0 200000 0 15 0

=

300000 1500000 14 4.5 1800


Customer Service center

Fault expert

Trouble ticketmanager

Testperformer

Customerdatabase

Servicehistory

Currentfaults

Troubletickets

Network

Legend: OMT [41]

Figure 14 Trouble management scenario

10All figures in the example are for illu-strative purposes only and are notobserved from operational troublemanagement.

11An overview of optimization modelscan be found in [46].

Customer Report failure

Retrieve customerinformation

Update customerinformation

Perform linetest

Order repair

Disk1 CPU1 Disk2Com1 CPU2

1 1 0.6 0.3

154

10 200.000150.0003.000100.000200.000

Figure 15 Trouble management configuration and workload (example)

where λ(s) is the aggregated activationfrequency on core object s.

Given a processing requirement

per operation o of object class C, theresulting per time unit processing requi-rement for core object s is computed as

The user object rate λu and the process-

ing requirement are difficult to

estimate and the uncertainty limits theprecision of the workload model. Theinvocation structure su

(c,s,o) can be deri-ved from simulation of the behaviour ofthe system or directly counted from traceinformation. Of course, exhaustive coun-ting from all possible trace sequences isnot realistic in a real system. However,the most frequent execution paths can beexpected to dominate the result. Early inthe design phase, detailed information of

the processing requirement is not

available, and educated estimates mustsuffice. Hence, the workload modelneeds to be revised in an iterative processas more information is made available.

5.2 Constraints

Capacity constraints are related to pro-cessing, storage and communication:

• The requested processing from allobjects and clusters assigned to a nodemust be less than the available capa-

city of the node:

for all nodes n

where AC(n) is the set of clustersassigned to node n and AO(c) is the setof objects in cluster c.

• Total bandwidth requirements fromobject interactions must be less than

P(s) < CnP

s ∈ Ao (c)∑

c∈ AC (n)∑

C(n)P

PoC

PoC

p(s,o) = λ (s,o) ⋅ PoC(s)

p(s) = p(s,o)o∑

PoC

λ (c,s,o)u = λ u ⋅ s(c,s,o)

u

λ (c,s,o) = λ (c,s,o)u

u∑

λ (s,o) = λ (c,s,o)c∑

λ (s) = λ (s,o)o∑

the bandwidth capacity CLl available

on links between nodes:

for all links l

where mo is the mean message size foroperation o and AL(l) is the set of allinteractions routed on link l.

• Physical storage capacity CSn of each

node must be greater than the requiredstorage from all objects.

for all nodes n.

In addition to the capacity constraints,the model formulation itself has a set ofconstraints, e.g.

• an object is allocated to only onecluster

• all objects are assigned to some cluster

• a cluster is allocated to only one com-puting node

• all clusters are assigned to some node.

Given the following definitions

Mi = cost of node i

the model constraints are formulated as

∃ i ⋅ Θi,j = 1 ⇔ Ωj = 1for all objects j

∃ i ⋅ Ψi,j = 1 ⇔ Φj = 1for all clusters j

for all objects j

for all clusters i

Ψi, jj

∑ =1

Θi, jj

∑ =1

Φi =1, if any cluster is allocated to node i

0, otherwise

Ωi =1, if any object is allocated to cluster i

0, otherwise

Ψi, j =1, if cluster i is allocated to node j

0, otherwise

Θi, j =1, if object i is allocated to cluster j

0, otherwise

s ∈ Ao (n)∑ d(s) < Cn

S

(s,c,o)∈ AL (l )∑ mo ⋅ λ (c,s,o) < Cl

L

which states that when an object isassigned to a cluster, there is an object atthat cluster, etc. The model constraintsalso require every object to be assignedto only one cluster and every cluster tobe assigned to only one node.

5.3 Optimization objectives

Without consideration of performance ordependability, a simple formulation is tominimize cost, i.e.

subject to the constraints from section5.2. Although performance as well asQoS requirements are ignored, this opti-mization objective is of some interest asit gives a lower bound on the cost of thesystem. Further, with Mi = 1, the result isthe least number of computing nodes thatis needed.

When minimization of capital cost is theobjective, performance and QoS require-ments are included as additional con-straints in the optimization problem, i.e.“What is the system structure that offersthe least capital cost and which fulfilsthese performance and quality charac-teristics?”

An alternative objective is optimizationof performance and QoS, and with capi-tal cost modelled as constraints, i.e.“What is the system structure that offersthe best performance and quality charac-teristics given this constraint on capitalcost?”

An objective function for process alloca-tion which maximizes reliability is givenin [42] which is readily adapted to objectand cluster allocation.12 Reliability ismaximized when the mean number offailure is minimized:

where γ is the failure intensity of nodesand links, ec is the accumulated execu-tion time of cluster c (on node n) during

min: γnN

c∑

n∑ ⋅Ψc,n ⋅ec +

l∑

(s,c,o)∈ AL (l )∑ γ l

L ⋅mo ⋅ λ (c,s,o) ⋅ ∆t / ClL

min: MiΘii∑


12The formulation in [42] is more gene-ral as each path between nodes can beconstructed by a sequence of links. Inour formulation, nodes are directlyinterconnected by (virtual) links.

an interval ∆t. The first part is theaverage number of node failures, whilethe second part is the average number ofcommunication failures.

Minimization of waiting time13 isexpressed as the objective function:

where

is the waiting time at node n for opera-tion o, µn,o is the service rate of the ope-ration, λn,o is the activation frequencyand Λ is the total workload on all nodes.Both the service rate and the utilizationUn depend on the number of clusters andobjects allocated to the node.

5.4 Optimization techniques

A number of optimization objectives arepresented in the previous subsection.Assignment of objects to clusters andclusters to nodes is at least as difficult asassignment of files to nodes or tasks toprocessors. These problems are known tobe NP-hard [45], which implies thatdirect solution techniques from mathe-matical programming are not feasible. Anumber of heuristic solutions has beenproposed for allocation of files and clus-ters in distributed databases [e.g. 11, 12,45, 4, 39], including techniques based on

• knapsack• branch and bound• network flow.

Heuristic solutions of task assignment toprocessors have been studied [e.g. 34, 2,42, 7]. As task assignment and file allo-cation are similar problems, many of theheuristic approaches are similar. In addi-tion, techniques from artificial intelli-gence are used in [42], where the solu-tion state space is examined with anadaptation of the A* algorithm.

Solutions to difficult problems like taskassignment and object and cluster assign-ment, can be made much more effectivewith a good initial solution. The aggrega-

Wn,u =1 / µn,u

1−Un

min:λ n,o

Λo∑

n∑ Wn,o

ted interaction frequency between clientand server objects

can be used to form clusters such thatobjects with frequent interaction areassigned to the same cluster (and objectswith infrequent interaction are assignedto different clusters). However, the speci-fication transformation resulting fromassignment of interacting objects to diffe-rent clusters, results in a modification ofobject interaction. It is not sufficient tojust group objects with high interactionrates. In addition, the capacity of nodes,storage and links limit the number ofobjects and clusters that can be assignedto the same node. However, good initialsolutions can be found, which limits theexamined state-space and reduce therunning time.

Cluster analysis is a collection of tech-niques used in many branches of scienceto group or classify entities. In this case,the term ‘cluster’ is different from‘cluster’ as defined by RM-ODP, but isa general grouping of objects based onsome measure of ‘dissimilarity’ or,equivalently, ‘similarity’ betweenobjects. The result of cluster analysisdepends both on the measure of dis-similarity and the algorithm to groupobjects (see [13, 28, 1]). Definition ofthe dissimilarity measure depends on theapplication domain, while clusteringalgorithms are applicable betweendomains. However, not all algorithms areequally suitable, and a clustering algo-rithm should be applicable in an applica-tion domain.

λ (c,s) = λ (c,s,o)o∑

In general, clustering algorithms can beclassified as hierarchical, overlappingand partitioning. Hierarchical clusteringstarts with each object allocated to onecluster. Following this, the two mostsimilar clusters are merged until a singlecluster is formed (or a predefined numberof clusters is reached). Hierarchicalclustering is often illustrated a tree asshown in Figure 16 where the heightindicates when clusters are merged.Clusters formed by hierarchical cluster-ing are disjoint at each level in the tree,e.g. each object is assigned to only onecluster. When engineering communi-cating systems, the hierarchy of clusterscan be used to select objects to be as-signed to ODP clusters, and to selectobjects to move to other ODP clusterswhen an object assignment violates con-straints (e.g. capacity or QoS require-ments).

Overlapping or fuzzy clustering is pos-sible when similarity between objects isused to assign a degree of cluster mem-bership to objects. Fuzzy clustering isfrequently used within the fields ofpattern recognition and data mining, butcan also be applied to guide assignmentof objects to ODP clusters.

While hierarchical and overlappingclustering start with individual objectsand gradually merge objects to largerclusters, partitioning is a technique wherea single cluster is divided into smallerclusters. Partitioning is generally usefulwhen the result is few but large clusters.Fragmentation of tables in a distributeddatabase is an example where partition-ing can be used to group attributes intofragments that are distributed [45].


13As only transactions are addressed,the throughput is in equilibrium equalto the applied workload.

First merge

O1

Last merge

O2 O3 O4 O5 O6 O7 O8 O9 O10

Figure 16 Hierarchical clustering

How to measure similarity δ(c,s) betweentwo objects c and s in a system? Both theinvocation frequency between objectsδ(c,s) = λ(c,s), as well as the average band-width requirement between objects

can be used. Message size information isincorporated in the bandwidth require-ment, and is most likely the best choice.However, when ‘short’ messages areused by prioritized applications, and‘larger’ messages are less important, theinvocation frequency can be the betterchoice of similarity measures.

Given a similarity measure, differenthierarchical clustering algorithms (orstrategies) are possible. A simple strategyis single-link clustering. In this case,clusters with the two most similar objectsare joined, e.g. find two objects c and ssuch that

δ(c,s) + δ(s,c)

is maximized and join the clusters con-taining objects c and s. A drawback ofthis technique is that clusters can be con-structed with little internal cohesion asonly interaction between pairs of objectsis used. This is avoided by complete-linkclustering which joins clusters such thatthe similarity between all objects in thetwo clusters is maximized, e.g. jointclusters A and B such that

is maximized. Complete-link clusteringmaximizes internal interaction and mess-age exchange, while interaction betweenclusters is minimized.

Given the objects from Figure 16, aheuristic approach initially assigns allobjects to a single cluster on a singlenode. Assuming system constraints areviolated, the cluster is split by reversingthe last merge operation. Hence, twoclusters with objects O1, O2, O3, O4,O5, O6, O7 and O8, O9, O10 areformed and assigned to different nodes.In this case, the transformation rulesfrom section 3.3 are applied to augmentthe object model with necessary distribu-tion support objects. If constraints arestill violated, the cluster last merged issplit. In this case, the larger cluster O1,O2, O3, O4, O5, O6, O7 is split into O1,O2, O3, O4 and O5, O6, O7. This pro-

δ a,b( ) +δ b,a( )( )a∈ Ab∈ B

∑

δ(c,s) = moo∑ ⋅λ (c,s,o)

cess is repeated until all constraints aresatisfied (if possible).

The method outlined above is notguaranteed to produce an optimal solu-tion, as many possible configurations arenot investigated. However, clusters aresplit such that the most similar objectsare kept together, which is goodengineering practice.

6 Conclusion

An overview of engineering principlesfor communicating systems has beenpresented. Optimal allocation of compu-tational viewpoint objects to engineeringviewpoint clusters is an NP-hard problemand heuristic solutions are necessary. Asmany different distribution schema arepossible, system specifications expressrequirements on the distributed process-ing environment as QoS attributes asso-ciated with functional capabilities. Whena particular distribution schema is se-lected, QoS attributes are used to guidespecification refinement. The refinementprocess augments the specification withthe necessary distribution support ob-jects. Clustering of objects based onobject interaction and the bandwidthrequirement between objects are pro-posed to help select useful distributionschema. Each schema can be analyzed,using analytical techniques from queuingtheory, to select the schema that is opti-mal given an objective function and a setof system constraints.

7 References

1 Arabie, P, Hubert, L J, De Soete, G(ed). Clustering and classification.Singapore, World Scientific Publish-ing, 1996.

2 Bowen, N S, Nikolaou, C N, Gha-foor, A. On the Assignment Problemof Arbitrary Process Systems toHeterogenous Distributed ComputerSystems. IEEE. Trans. Comput., 41(3), 275–73, 1992.

3 Buzen, J P. Computational algo-rithms for closed queuing networkswith exponential servers. Comm.ACM, 16 (9), 527–31, 1973.

4 Ceri, S, Martella, G, Pelagatti, G.Optimal File Allocation in a Compu-ter Network : a Solution MethodBased on the Knapsack problem.

Computer Networks, 6, 345–57,1982.

5 Chapman, M, Montesi, S. OverallConcepts and Principles of TINA.TINA Consortium, 1995. (Technicalreport.)

6 Chu, T C K, Abraham, J A. LoadBalancing in Distributed Systems.IEEE Trans. Soft. Eng., SE-8 (4),401–12, 1982.

7 Chu, W W et al. Task Allocation inDistributed Processing. IEEE Com-puter, 13 (11), 57–69, 1980.

8 Cristian, F. Understanding fault-tole-rant distributed systems. Communi-cations of the ACM, 34 (2), 57–78,1991.

9 Dallery, Y, Cao, X R. Operationalanalysis of stochastic closed queuingnetworks. Performance Evaluation,14, 43–61, 1992.

10 Denning, P J, Buzen, J P. The opera-tional analysis of queuing networkmodels. Comput. Surveys, 10 (3),225–61, 1978.

11 Dowdy, L W, Foster, D V. Compara-tive Models of the File AssignmentProblem. ACM Comput. Surv., 14(2), 287–313, 1982.

12 Eswaran, K P. Placement of Recordsin a File and File Allocation in aComputer Network. In: InformationProcessing ‘74. Stockholm, 1974,304–307.

13 Everitt, B R. Cluster analysis. Hal-stead Press, 1993.

14 Fabre, J-C, Prennou, T. Friends : AFlexible Architecture for Implement-ing Fault Tolerant and Secure Distri-buted Applications. In: Second Euro-pean Dependable Computing Con-ference (EDCC-2). Taormina, Italy,1996.

15 Ferrari, D. Computer Systems Per-formance Evaluation. Prentice-Hall,1978.

16 Franken, L. Quality of Service Man-agement : a Model-Based Approach.Performability modelling tools andtechniques. Centre for Telematicsand Information, University ofTwente, 1996. (PhD thesis.)


18 Graham, R L, Knuth, D E, Patashnik,O. Concrete mathematics, Addison-Wesley, 1989.

19 Harrison, P, Patel, N. PerformanceModelling of Communication Net-works and Computer Architectures.Addison-Wesley, 1993.

20 Haverkort, B R, Niemegeers, I G.Performability modelling tools andtechniques. Performance Evaluation,25, 17–40, 1996.

21 Hughes, P. Performance Engineer-ing. Trondheim, Department of Com-puter Systems and InformationScience, Norwegian University ofScience and Technology, 1997.(Technical Report.)

22 ISO/IEC JTC 1/SC 21/WG7 N1192.Working document on QoS in ODP.1997.

23 ITU. Principles for a Telecommuni-cations management network.Geneva, ITU, 1996. (ITU-T Recom-mendation M.3010 (05/96).)

24 ITU. Security architecture for OpenSystems Interconnection. Geneva,ITU, 1991. (ITU-T Rec. X.800.)(ISO 7489-2, 1989.)

25 ITU. Open Distributed Processing :Reference Model : Foundations.Geneva, ITU, 1995. (ITU-T Rec.X.902.) (ISO/IEC 10746-2, 1996.)

26 ITU. Open Distributed Processing :Reference Model : Architecture.Geneva, ITU, 1995. (ITU-T Rec.X.903.) (ISO/IEC 10746-3, 1996.)

27 ITU. Open Distributed Processing :Trading Function, Part 1 : Specifica-

tion. Geneva, ITU, 1996. (Draft ITU-T Rec. X.950.) (ISO/IEC DIS 13235-1. Geneva, 1996.)

29 Jain, A K, Dubes, R C. Algorithmsfor Clustering Data. Prentice-Hall,1988.

30 Kim, C, Kameda, H. An Algorithmfor Optimal Static Load Balancing inDistributed Computer Systems. IEEETrans. Comput., 41 (3), 381–84,1992.

31 Laprie, J-C (ed). Dependability :Basic Concepts and Associated Ter-minology. Springer, 1992. (PDCSTech. Rep. No. 31, May 1990.)

32 Lazowska, E D et al. QuantitativeSystem Performance : Computer Sys-tems Analysis Using Queuing Net-work Models. Prentice-Hall, 1984.

33 Linington, P. RM-ODP : the archi-tecture. In: 3rd international IFIPTC6 Conference on Open DistributedProcessing. 1995, 15–33.

34 Lo, V M. Heuristic Algorithms forTask Assignment in Distributed Sys-tems. IEEE Trans. Comput., 37 (11),1384–97, 1988.

35 Menascé, D A, Almeida, V, Dowdy,L W. Capacity Planning and Per-formance Modeling. Prentice-Hall,1994.

36 Meyer, J F. On evaluating the per-formability of degradable computingsystems. IEEE Trans. Comput., 29(8), 720–31, 1980.

37 OMG. The Common Object RequestBroker : Architecture and Specifica-tion. 1995. (Technical report, re-vision 2.0.)

38 Opdahl, A L. Performance engineer-ing during information system de-velopment. Trondheim, Departmentof Computer Systems and Tele-matics, Norwegian Institute of Tech-nology, 1992. (Dr.ing (PhD) thesis.)

39 Ramamoorthy, C V, Wah, B W. TheIsomorphism of Simple File Alloca-tion, IEEE Trans. Comp, 32 (3),231–231, 1983.

40 Raymond, K. Reference model ofopen distributed processing (RM-ODP) : Introduction. In: 3rd interna-tional IFIP TC6 Conference on OpenDistributed Processing, 1995, 3–14.

41 Rumbaugh, J et al. Object-orientedmodeling and design. Prentice-Hall,1991.

42 Shatz, S. Task Allocation for Maxi-mizing Reliability of DistributedComputer Systems. IEEE Trans.Comput., 41 (9), 1156–68, 1992.

43 Sienknecht, T, Martinka, J, Friedrich,R. Murky transparencies : Clarityusing performance engineering. In:3rd international IFIP TC6 Con-ference on Open Distributed Pro-cessing, 1995, 507–510.

44 Smith, C. Performance Engineeringof Software Systems. Addison-Wes-ley, 1989.

45 Tamer Orzu, M, Valduriez, P. Prin-ciples of Distributed Database Sys-tems. Prentice-Hall, 1991.

46 Williams, H P. Model building inmathematical programming. Wiley,1993.


Knut Johannessen is Senior Engineer at TelenorNett, IT department, working with strategy foroperational support systems and IT architecture.He is participating in ITU-T SG4 which specifiesRecommendations for TMN. He is also currentlypursuing a Ph.D. at the Department of Tele-matics, Norwegian University of Science andTechnology with focus on architectural design ofdistributed systems.


TINA is a general software architec-ture, applicable to a broad range oftelecommunications and informationservices. The architecture is based onthe principles of object-orientation,CORBA-based distributed processing,and separation of services from under-lying network. The purpose is to pro-vide for common services over diffe-rent underlying network technologiesand rapid service development in anopen environment that encouragesthird party development. This paperprovides an overview of the TINAarchitecture and contrasts it withrelated work in the area of multi-media services, intelligent networks,and broadband networks.

1 Introduction

The Telecommunications InformationNetworking Architecture Consortium(TINA-C) consists of approximately40 telecommunications and informationtechnology companies from all over theworld. The consortium started in 1993with the goal to define and validate asoftware architecture that will enableefficient introduction and management ofnew and sophisticated telecommunica-tions services. The TINA architecture isbased on object-oriented technology anddistributed computing, and incorporatesresults from international standards suchas ITU/ISO RM-ODP, ITU-T TMN,ATM Forum, and OMG’s CORBA archi-tecture.

During the first phase of TINA-C, ex-tending from 1993 to 1997, the TINAarchitecture was developed by a CoreTeam of about thirty member companyengineers located in Bellcore’s premisesin New Jersey, USA. The basic set ofTINA specifications are now consideredstable, and are available to the publicthrough its Web site (http://www.tinac.com). The second phase of the consor-tium is now starting, and is planned toextend for three years through the year2000.

The TINA architecture has three majorgoals [1]:

• To make it possible to provide versa-tile multimedia services

• To make it easy to create and manageservices and networks, and

• To create an open telecommunicationssoftware component marketplace.

TINA is intended to be a general soft-ware architecture, applicable to a broadrange of telecommunications and infor-mation services. It is, however, speci-fically intended to suit the followingareas of application: New broadbandnetworks (ATM networks and B-ISDN),new sophisticated services (multimediaservices, multiparty conferencing, VPNservices, and IN-type services), andnomadic communication and new mobilenetworks (uniformly providing usermobility, terminal mobility and sessionmobility, UMTS, and DECT). Note thatTINA was planned and initiated beforethe spectacular raise in Internet and Intra-net technology during the recent years.However, the TINA work has not beenunaffected by the Internet developments,and many of the TINA results (e.g. theService Architecture) are, due to theirquite general nature, seen as useful in thecontext of the Internet.

The TINA architecture is based on theprinciples of object-orientation, distribu-tion, and separations of concern. Thepurpose of these principles is to ensureinteroperability, portability and reusa-bility of software components, indepen-dence from specific technologies, and toshare the burden of creating and man-aging a complex system among differentbusiness stakeholders, such as users, ser-vice providers and network providers.

Object-oriented techniques focus onreducing complexity through modulariza-tion, encapsulation of data and methods,and reuse of existing components. Break-ing a complex system down into a set ofencapsulated objects reduces complexity,and de-couples the software modulesfrom each other so that a change in onecomponent due to a change in underlyingtechnology, (standards, languages, pro-grams, networks, etc.) does not affectother components.

Distribution of service software compo-nents over different parts of the networkcan improve performance by reducingnetwork load and applying load balanc-ing techniques. Furthermore, servicesmay be made more fault tolerant by theapplication of techniques such as objectreplication. Finally, distribution is tosome extent an inherent element of manytelecommunication services. A key prin-ciple for TINA is that telecommunica-tions services and management systemsare considered as software applicationsthat operate in a distributed environment.To simplify the development of thesedistributed applications TINA mandatesthe use of a Distributed Processing En-vironment (DPE). The purpose of theDPE is to hide from the applications thedetails of the underlying technologiesand distribution concerns, thus simplify-ing the construction of distributed soft-ware.

TINA adopts two major separations ofconcern, see Figure 1. The first separa-tion is between applications and theunderlying distributed processing en-vironment (DPE) on which they run, asdescribed in the previous paragraph. Thesecond is the separation of applicationsinto a service-specific part and a networkcontrol and management specific part.The latter interacts with the transport net-work. The separation into a service partand a network part is one of the keyfeatures of the TINA architecture. Itallows provision of common servicesfor different underlying network tech-nologies, including SDH, ATM, andradio networks.

According to the separation principles,TINA is divided into three sub-architec-tures: The Computing Architecture [2, 3,4] defines the DPE and associatedmodelling concepts. The TINA DPE isbased on OMG’s CORBA with adaption

95

The TINA ArchitectureT O M H A N D E G Å R D A N D L I L L K R I S T I A N S E N

Telektronikk 1.1998

ServiceArchitecture

NetworkResource

Architecture

Computing Architecture

TransportNetwork

Figure 1 The TINA architecture consists of three sub-architectures: Computing, service, and resource architectures

for telecommunications requirements.The Service Architecture [5] defines a setof principles for providing services. Ituses the notion of session to offer a co-herent view of the various events andrelationships taking place during the pro-vision of services. The Network Architec-ture [6] describes a generic, technologyindependent model for setting up connec-tions and managing telecommunicationnetworks.

The TINA Service and Resource Archi-tectures are based on a specific model ofhow business within the telecommunica-tions domain will be conducted. TheTINA Business Model [7] describes thedifferent parties involved in service pro-visioning and their relationships to eachother. A small number of roles aredefined, which reflect the major businessseparations of a complex telecommunica-tions and information market: Consumer,retailer, broker, third party service pro-vider, content provider, and networkprovider. Within the service and resourcearchitectures, Reference Points are iden-tified. Each reference point comprises aset of interfaces describing the interac-tions taking place between these roles.For the most important reference points,detailed specifications have been de-veloped [8, 9, 10]; other interfaces areyet to be described in detail.

2 Overview of the TINAArchitecture

This chapter provides an overview of thedifferent parts of the TINA architecture,and how they fit together. It is importantto note that in a telecom system, someparts may conform to TINA, whilst otherparts may not. For instance, it is possibleto build services that conform to theTINA service architecture on networksthat are not consistent with the TINAresource architecture. In this case, thesystem uses the TINA service architec-ture, but not the TINA resource architec-ture.

2.1 The Computing Architec-ture and DPE

The TINA Computing architecture con-sists of three parts: Information Model-ling Concepts [2], Computational Model-ling Concepts [3], and DPE Architecture[4]. The TINA computing architecture isbased on ITU/ISO’s Reference Model forOpen Distributed Computing (RM-ODP),

and the three parts corresponds roughlyto RM-ODP’s information, computa-tional, and engineering viewpoints,respectively.

The information and computationalmodelling concepts define the conceptsand languages that are used to writespecification of TINA Reference Pointsand software components. The informa-tion and computational parts of TINAspecifications are considered comple-mentary to each other.

The information model describes theinformation-bearing entities in the appli-cation (or component, or referencepoint), their relationships to each other,and the constraints and rules governingtheir behaviour. It identifies the entitiesthat the application deals with and isindependent from distribution concerns.The language used for TINA informationspecifications is Object Modelling Tech-nique (OMT) [12] for graphical specifi-cations, and a simplified version ofGDMO for textual specifications.

The computational model focuses on thesoftware modules, objects, and theirinterfaces. Applications consist of collec-tions of objects that interact with eachother via interfaces. Each object providesone or more interfaces to enable otherobjects to access its capabilities.

Objects interact either by invoking opera-tions and sending responses or by meansof stream flows. Interfaces used for theformer kind of interaction are called ope-rational interfaces, and interfaces usedfor the latter kind are called stream inter-faces. The interactions that occur at anoperational interface is based on theparadigm of remote procedure calls, i.e.they are structured in terms of invoca-tions of one or more operations andresponses to these invocations.

A stream interface is an abstraction thatrepresents an end-point of a continuosinformation flow, such as a video oraudio flow. When objects interact via

stream interfaces, the informationexchange occurs in the form of streamflows between the objects, where eachstream flow is unidirectional and is a bitsequence with a certain frame structure(data format and coding) and quality ofservice parameters.

The computational objects are specifiedusing TINA-ODL (Object DefinitionLanguage). TINA-ODL is a pure super-set of OMG IDL. The major part of atypical ODL specification of a softwaremodule is description of the attributesand operations it supports, using OMGIDL.

The CORBA architecture is the basis forthe TINA DPE. The CORBA architec-ture does not meet all the requirements oftelecommunications applications, how-ever. Consequently, TINA-C’s workwithin the DPE area has been focused onthe identification of additional require-ments and working within the OMG tohave the current standards extended ornew standards established. Extensionsthat have been addressed by TINAinclude multimedia support (control ofaudio/video streams), support for real-time requirements, support for alternativetransport protocols (other than TCP/IP)such as SS7 and ATM, extensions toIDL, and new object services (e.g. TMN-style notification service). Refer to [11]in this issue of Telektronikk for moreinformation on CORBA and the OMG.

The DPE (Figure 3) is a layer on top ofthe underlying operating system andcommunications software. The DPEnodes have basic communication capa-bilities to set up connections betweenthem in order to establish communicationchannels that can be used to carry opera-tional communication between the appli-cation objects. These communicationcapabilities are in the TINA terminologyreferred to as the kernel transport net-work (KTN). The KTN can be comparedto the signalling network in traditionaltelecommunication system architectures.


Stream flow endpoint(source)

Stream flow endpoint(sink)

Stream Flow

Stream StreamInterface

Figure 2 Stream interfaces and stream flows

2.2 Business Model andReference Points

The TINA business model and referencepoints [7] consists of two parts:

1. A generic framework for specifyinginteractions and contracts betweenbusiness administrative domains. Thisincludes templates and languages forinformational and computational speci-fications.

2. A set of defined business roles, andfor each defined relationship betweenroles, definition of reference points.

The generic framework is important toallow for openness and flexibility. Itallows two business administrativedomains to define their own businessroles and interactions.

The defined business roles and referencepoints identify components and functio-nality that are specific to TINA. Thebusiness roles have been identified byanalysing the current business rela-tionships in telecommunication andinformation services.

2.2.1 TINA Business Roles

The identified set of TINA business rolesare (see Figure 4):

• Consumer – a stakeholder that con-sumes services, e.g. a private person, ahousehold or a company. This type ofstakeholders is the ultimate target forthe business in a TINA system. Allother types of stakeholders can becharacterised as “producers” or“middlemen”.

• Retailer – a stakeholder that provides(sells) different kinds of services to theconsumers. Retailers ensure ease ofaccess and provide quality guaranteesto consumers.

• Third Party Service Provider – astakeholder that provides services tostakeholders other than consumers.

• Broker – a stakeholder that providesinformation about how to find servicesand stakeholders in the TINA system.A broker provides a specific service,which has a general use in a TINA sys-tem.

• Network Provider – a stakeholder thatprovides transport services and con-trols and manages communicationequipment, like switches, cross-con-nects, bridges, routers and trunks. Notethat the term ‘network provider’ mustbe understood in a strict sense, not as asynonym for Public Network Opera-tors (PNO). The PNOs will to a largeextent operate also in the retailer busi-ness role.

It is important to notice that one businessadministrative domain, such as a PNO,may simultaneously perform several ofthe defined business roles, and internallyit might either comply with the definedreference points, or use other proprietaryinteractions.

The main activities of the consumerbusiness role are:

1. Obtain location of retailers, serviceproviders, and other consumers.

2. Initiate service relationships thatinclude service providers and otherconsumers.


TINA ServiceComponents

TINAApplications

DPE

DPEImplementation

kTN

Hardware

TransportNetwork

Inter DPE nodeinterface (IIOP)

TINA Network ResourceComponents

Local operatingsystem andcommunicationssoftware

Figure 3 TINA DPE and kernel transport network

3. Register and de-register at retailers.

4. Indicate availability to retailers, e.g.for receiving invitations and calls.

5. Accept downloads from retailers toupgrade the interaction capability withthe retailer. This allows tailored, non-standardised services to be providedby the retailer, and makes tailored ser-vices and service functionality an issuein the competition between retailers.

Consumers can use one or more retailers,even at the same time. The life-time of arelationship between a particular con-sumer and a particular retailer can varyfrom seconds to years. For example, aconsumer might use a particular serviceoffered by a retailer only once. Anotherexample is a consumer that is a faithfulclient to a particular retailer for a longtime and uses the retailer as a “one-stop-shop”.

The main objectives for the retailer busi-ness role are the following:

1. Provisioning and management of ser-vices

2. Collecting accounting information forthe purpose of billing for service usage

3. Establishing relationships to other ser-vice providers, both other retailers andthird party providers

4. Value adding services from third partyproviders.

A retailer can deploy a new service forimmediate use by any consumer in theTINA system without consulting orstandardising the services with otherretailers. This is an absolute requirementthat will allow a TINA system to be anattractive and dynamic system for thefuture. Together with the downloadingcapability of the consumer this enablesrapid service deployment.

A retailer can interact with other retailersand/or third party service providers.Often the term ‘service provider’ is usedfor both. The difference between thesetwo roles may not be so big, but a retailerhas his own subscribers, while a thirdparty service provider does not. The thirdparty provider may be a pure content pro-vider, providing content to be distributedby the retailer to the subscribers of theretailer.

A stakeholder in the business role of net-work provider controls and manages atransport network containing switches,cross-connects, routers and trunks. Thetransport network is controlled by TINAConnection Management, see section 2.4.

The transport network operated by asingle network provider is unlikely to bea global network that connects all theconsumers, retailers and third party ser-vice providers. The global transport net-work is most likely to be segmented intoa number of subnetworks controlled by

different stakeholders, each in the net-work provider business role. To allowmanagement (set-up, removal, etc.) ofconnections routed through two or morenetwork segments belonging to differentconnectivity providers, the connectivityproviders have to federate. The sameprinciples that apply to NNI (network-to-network interface) for bearer services intraditional networks apply to federationamong connectivity providers. The refe-rence point LNFed deals with the inter-face between federated subnetworksoperated by different network providers.

TINA supports the concept of layer net-works. A client/server relationship existsbetween the connectivity provider thatmanages the client layer network and theconnectivity provider that manages theserver layer network. The client layernetwork uses resources of the serverlayer network. The reference point CSLNdeals with the interface between clientand server layer networks operated bydifferent network providers.

Stakeholders in the broker business rolehave a specific mission in the TINA sys-tem, which is to provide stakeholderswith information on how to reach otherstakeholders and business administrativedomains and how to reach services pro-vided in the TINA system. A broker mayact as an entity that ensures equal accessto services. It may also act much the wayan Internet search engine does. The mainobjectives of this business role are:

1. Obtain location of retailers2. Register and de-register at retailers3. Indicate availability to retailers.

2.2.2 TINA reference points

In order for a system to become TINAcompliant, some conformance require-ments have to be fulfilled. The confor-mance requirements are expressed interms of reference points. If one or moreof the defined reference points are ful-filled, the system is a TINA system. Twotypes of conformance requirements arerelevant to TINA:

1. Interdomain reference points: Con-formance requirements for interopera-bility between different business admi-nistrative domains

2. Intradomain reference points: Con-formance requirements for TINA com-ponents developed by different ven-dors and to be used within one admi-nistrative domain.


Broker

Consumer Retailer3pty Service

Provider

ConnectivityProvider

Bkr

RtR

3Pty

3PtyRet

Bkr

TCon ConS ConS TCon

LNFedCSLN

TCon

Bkr

Bkr

Figure 4 TINA business roles and reference points. The reference points defined arecalled Retailer RP (Ret), Third-party RP (3Pty), Connectivity service RP (ConS),Client-server layer network RP (CSLN), Layer Network Federation RP (LNFed),

Retailer-to-Retailer RP (RtR), Terminal Connectivity RP (TCon), and Broker RP (Bkr)

The interdomain reference points servethe same purpose as NNI interfaces inB-ISDN signalling or X reference pointsin TMN. They deal with interfaces be-tween different administrative domains.

The intradomain reference points may becompared to e.g., SSP-SCP INAP in INand Q interfaces in TMN. They deal withcomponent interworking and mainlyrepresent requirements on vendors. Thedetails of intradomain reference pointsare not currently worked out in TINA,but the service and network componentspecifications [13, 14] will contain goodcandidates for such reference points.

Each interdomain reference point has twoparts: Access part and usage part.

The access part contains the interfacesthat are needed to establish a contractualrelationship over an administrativedomain boundary. TINA has attemptedto define a generic access part that can beas much as possible applicable to all refe-rence points. This may actually not becompletely achievable because differentrequirements apply to different referencepoints. For example, the access part be-tween the consumer and the retailer willtypically be asymmetric, with the retailerproviding access to the consumer, whilethe relation between two network pro-viders may be peer-to-peer and sym-metric. The security issues may alsovary. However, the notion of accesssession is useful in all cases where admi-nistrative domains are crossed. Currently,the asymmetric access part is defined. Itsdefinition is placed within the Ret refe-rence point document [8].

Note that the separation of access andusage parts allows the access to be con-formant to the TINA reference point,while the usage part can be otherwiseagreed between the involved businessadministrative domains in case the TINAdefined usage parts do not fit thesebusiness administrative domains.

The usage part depends completely onthe business roles involved and the ser-vices to be performed.

Specifications are currently completedfor the Ret, TCon, and ConS referencepoints. These reference points are defi-ned in detail, including CORBA IDLdefinitions, message sequence charts andinformation models.

The Ret specification is the most com-plex one. Ret contains the asymmetricaccess part, and all the necessary inter-faces and information to perform the ser-vice session control between one retailerand one or several consumers. The Retspecification also includes the operationsneeded at communication session level.Thus, Ret contains specifications formost of what is described in the TINAService Architecture. Great care has beentaken to make the specifications wellstructured and modular. In fact, the spe-cification has been divided into modules,called feature sets, that to a large extentcan be used individually. The specifica-tions may be worth looking into for any-one planning to build large IDL specifi-cations, even if they are not specificallyinterested in the particular informationhandled over Ret.

ConS and TCon are also fully definedspecifications, though not that complex.TCon needs to be supplemented withdetails for each technology involved.

It is likely that a lot of work done for thecurrently defined reference points can bereused for the remaining referencepoints.

2.3 Service Architecture

2.3.1 Requirements

The TINA Service Architecture is de-signed to achieve:

• Support for a wide range of services,including IN-like services like ‘free-phone’ and queuing services, and alsomultimedia, multiparty services withall possible payment and service con-trol schemas

• Support for rapid service development,including development of services thatare not standardised

• Support for tailored services

• Support for a multiplayer environment,e.g. to allow equipment and softwarefrom different vendors within one

business domain, and also to allowseveral service domains to offer com-pound services

• Support for service manageability,including but not limited to customeraccess to management services, e.g.management of timetables to deter-mine personal availability, or on-linemanagement of subscriptions

• Universal service access, includingglobal mobility, such as personalmobility and service mobility

• Ubiquitous information access, e.g.support to find information even whenthe information server has moved toanother place.

TINA does not standardise specific ser-vices like ‘Video On Demand’ or ‘Teleeducation’. Instead, the TINA ServiceArchitecture provides a framework thatsupports personal mobility, multipartyservices and service tailoring. The Ser-vice Architecture covers the upper part ofFigure 4, including the relationships be-tween consumers, retailers, brokers andservice providers.

2.3.2 Service Architecture Basics

The Service Architecture is illustrated inFigure 6. The picture is somewhatsimplified. The objects involved areexplained as follows:

Initial Agent (IA), User Agent (UA) andProvider Agent (PA) are the objectsrelated to the access part. The bindingbetween UA and PA is called an accesssession. A session may be seen as a collec-tion of objects collectively fulfilling a task.

The IA exists due to initial, insecureaccess, and it also provides anonymousaccess. Access specific UAP (as-UAP)may be seen as a presentation tiertowards the end user.

After the logon procedure has establishedan access session, the user may typicallyeither start a service of his own, or join


Consumer Retailer

TINA compliant access

Proprietary usage

Figure 5 Separation of access and usage allows a standard protocol to be used foraccess, while a proprietary protocol is used for service usage

an existing service session, as a reply toan invitation. The invitation mechanismis the linkage between the access sessionand the service session. There are alsorelations to ensure that the service ses-sions controlled by an access session willdie when the access session dies.

The main objects related to service usageare Service Session Manager (SSM),User Session Manager (USM), and UserApplication (UAP). The SSM is the coreof the service; it contains the core servicelogic. Different types of SSMs will existfor different service types. The main pur-pose of the USM is to provide tailoringof services for specific users. The USMis optional, however. In case tailoring isnot an issue, it may be omitted. Otherservice specific support objects, notshown in the figure, might also exist.In the retailer domain this may includemixing bridges (MCU) and other con-verters. The collection of SSM andUSMs collectively controlling a serviceexecution constitutes a service session.

The UAP may be service specific andcontain service logic and user interfacerelated functionality. The UAP may alsobe more generic, like a Web browser.

In case streams are needed as part of theservice, e.g. for a Video-on-demandservice, a communication session willbe initiated.

Details of each of the three sessions – theaccess session, the service session and

the communication session – will follow,but first the example scenario illustratedin Figure 6 will be explained. The scena-rio is as follows:

(1) Interactions to establish an accesssession.

(2) User 1 starts a service session, andthe SSM is instantiated.

(3) User 1 uses the service as a singleuser information retrieval service,e.g. to browse the video offers of theday.

(4) User 1 invites user 2 to join his ser-vice session.

(5) The user agent for user 2 stores theinvitation, e.g. because user 2 iscurrently not logged on, or has acti-vated ‘do not disturb’.

(6) User 2 logs on.

(7) User 2 joins the service session; thismay be done from the same terminal,or User 2 might use another accesssession from another terminal.

(8) The users exchange video interests orother service specific information.They also exchange more genericinformation like available streaminterfaces, etc. They might possiblynegotiate the payment schema, unlessthey choose a default schema. Thenecessary stream bindings are thenset up through the communicationsession (not shown in this figure).

Some comments related to the relation-ships between the different sessionsmight be appropriate. A service sessionmay be started from (i.e. controlled by)an access session of a user. A service ses-sion may also be started and controlledby the retailer. The former is the normalchoice for a multimedia multiparty con-ference, the latter is well suited for chat-like services.

Some service sessions may be openlyannounced (like ‘chat-rooms’), whileother service sessions are closed. For theopenly announced sessions, end usersmay join freely, though they may still becharged for the service usage. For theclosed sessions, the only way to evenknow the existence of the service session,is through receiving an invitation to join.

One service session might use and controlseveral communication sessions. This isallowed for maximum flexibility. The ser-vice session might even hand over thecontrol of a communication session toanother service session, if appropriate.

Note that the pricing for the usage of theservice is independent from the inviter/invitee distinction. Both ‘freephone’,‘premium charge’ or ‘split charging’ maybe in place at the service usage level. Formore advanced multiparty services thepayment schemas may be quite complex,e.g. the ‘boss’ pays for audio, those whowants video pay for themselves, or anyother payment schema one can imagine.

2.3.3 The Access Session anduser mobility

The access session related object UserAgent (AU) has an important role inproviding personal mobility and sessionmobility. The UA acts as a personalagent for a particular end-user. Uponreception of an invitation to join a servicesession – this may be anything from asimple point-to-point call or a complexmulti-party-conference – the UA handlesthe invitation. The UA may either:

• Send the invitation to a selected termi-nal, e.g. depending on the type of theservice

• Re-issue the invitation to someoneelse, e.g. the called user’s secretary

• Screen the invitation and ignore it

• Store the invitation, e.g. if the user isnot logged on, his terminal is switchedoff, or he has activated ‘do not disturb’functionality


as-UAP

PA

IA

UA

ServiceFactory

as-UAP

PA

IA

UA

(1)

(2)

(6)

(7)(2) (7)

ss-UAP ss-UAPUSM SSM USM(3) (4)

(8)

(3)

(8)

(8) (7) (8)

(2) (7)(2)

(4) (5)

(8)

Consumerdomain

Consumerdomain

Retailer (service provider) domain

Figure 6 Example of objects related to the service architecture

• Start a service to handle the invitationin more sophisticated ways, e.g. theinvitation may be addressed to “Big-Company”, and based on location, typeof service. etc., the invitation may behanded over to the appropriate serviceoffice, much like UAN services in IN.

Note that the invitation may be sent toone terminal, like a pager or anothersmall terminal, while joining of the ser-vice session might be done from anotherterminal, e.g. if the service needs a termi-nal with a high quality screen.

TINA handles invitations and user mobi-lity as part of a generic access mecha-nism, and not as a particular service.Remember also that the TINA accesssession may be used together with arbi-trary services. This allows the personalmobility and access to be provided byTINA, even for services that are proprie-tary and do not use any of the genericTINA defined interfaces in the servicesession part, see Figure 5.

2.3.4 Service Session

The service session controls and mani-pulates a service instance. TINA hasdefined a number of generic servicesession components and interfaces. Thesegeneric components must be specialisedor combined with service specific com-ponents to form specific services. Thegeneric interfaces include:

1. Functionality to negotiate regardingtransport connection requirementsamong the involved parties in a servicesession. Examples of parameters arequality of service requirements, sup-ported protocols, and coding formats.

2. Generic control and voting mecha-nisms for multiparty services. Thisenables one party to propose a changein the service session, and the otherparties to vote over this proposalbefore it is realised. The proposedchange in the service session may bethings like: adding another party,establish or change a video or audioconnection, etc.

Service specific behaviour is of coursetotally dependent on the type of service.For a game service the service specificbehaviour might check that the rules ofan interactive game are followed. For avideo on demand service specific operati-ons related to content, like browse,rewind, stop, etc. fall into this category.Specialisation of the generic control and

voting mechanisms mentioned above,e.g. to handle the different parties in amulti-party conference differently, is alsopossible.

The Service Session Manager (SSM)represents the core service logic. Diffe-rent User Service Session Managers(USM) represent the different customisa-tion of the service to the different endusers. The User Application (UAP)represents the end user in the end userdomain.

Tailoring can be done in several dimen-sions. It can be done by the USM, asexplained above. Alternatively, it can bedone by specialising the service, i.e.SSM, and optionally USM and/or UAP,by adding new interfaces and/or special-ising the behaviour of the objects.

The UAP may be service specific anddownloaded or otherwise provided fromthe service provider. It may be the casethat the same UAP is used for many ser-vices, like a web browser. But in othercases the UAP may be specific for a par-ticular service.

2.3.5 Communication session

In addition to the Access and ServiceSessions described above, the TINAservice architecture also defines the con-cept of Communication Session. Simplystated, the communication session pro-vides a high-level view of underlyingtransport networks. More specifically,the overall goals of the communicationsession are to:

• Offer a technology independent viewof the network to the service session

• Control and manage quality of service,set-up, modifications, etc. of multipleconnections.

Some reasons why the communicationsession is separated from the servicesession are:

• It enables third-party control of con-nections. For example, some usersparticipate in multimedia conferencesusing e.g. video streams, but withoutreceiving the video streams them-selves. Example: A conference man-ager may control and pay for somestream flows between some end users,but without participating in all streamflows himself.

• It enables the same communicationsession entities to be used by differentservices, i.e. the service tailoring maybe done at the service level withoutaffecting the behaviour of the commu-nication related objects.

• It enables a service session to be sus-pended, and the communicationsession to be ended. On service re-sumption a new communication ses-sion can be started.

Figure 7 shows the objects making up thecommunication session, and their rela-tionship to the service session, repre-sented by the SSM (possibly USM) andthe UAP(s).

As seen from the service session, thecommunication session takes care of theconnections end-to-end between userapplications (UAPs). The communicationsession related objects are Communica-tion Session Manager (CSM) and Termi-nal Communication Session Manager


UAP-1 SSM UAP-2

CSMTCSM TCSM

Consumerdomain

Consumerdomain

Retailer (service provider)domain

Figure 7 Objects involved in the Communication Session

(TCSM). These objects are furtherdescribed in section 2.4.

The TINA Service Architecture assumesthat the network is capable of informingthe services about all the necessaryevents from the network. For example,for a video-on-demand service where thecustomer pays on-line for the video con-tent, it is very important that the contentis actually delivered on-line according tothe agreement, if not, the price should beadjusted.

2.4 Network ResourceArchitecture

The TINA Network Resource Architec-ture (NRA) defines a generic technologyindependent framework for connectioncontrol (setting up, modifying and re-leasing connections) and for managingtelecommunications networks. It consistsof two parts, an information model calledNetwork Resource Information Model

(NRIM) and a computational part, thelatter identifying software componentsand interfaces between them.

The NRIM is based on concepts fromITU-T standards. It extends these con-cepts to support different network tech-nologies. The NRIM is intended to begeneral and network technology indepen-dent, yet it is a fact that the work hasbeen focused on ATM networks.

An overview of the computational speci-fication is shown in Figure 8. The NRAhas three layers:

• The Communication Session layer• The Connection Session Layer• The Layer Network.

The Communication Session is the top-most layer. It provides service softwarewith a simple, network independentinterface to control and manage connec-tions, called flows at this level. The flowsextend between flow termination points.

A flow termination point is an endpointof a flow and may represent a hardwaredevice such as a microphone or a loud-speaker, or software component. Flowtermination points are located withinterminals. Since terminals and networksmay have different capabilities, animportant part of flow establishment isto agree on the quality of service andcoding formats, e.g. MPEG or H.261for video, to use.

The central components within this layerare called the Communication SessionManager (CSM) and Terminal Commu-nication Session Manager (TCSM). TheCSM has the overall responsibility. Itprovides service components with a viewof connections that is “abstract”, i.e.independent from specific network tech-nologies. TCSMs run within terminalsand represent the terminals for the pur-pose of establishment and managementof flows. The CSM thus interacts withthe TCSMs and the CC (describedbelow) to establish the flows.

The abstract nature of the interface pro-vided to services by the CSM is veryimportant since it enables the construc-tion of services that can run on differentunderlying network technologies.

Below the Communication Session wefind the Connection Session layer. Thecentral component within this layer is theConnection Coordinator (CC). The CCprovides the CSM with interfaces tointerconnect network access points. TheCC hides underlying network techno-logies, and provides an abstract view ofthe connections. It is able to use differentunderlying network technologies toestablish the connections. It will pickone or more specific underlying networks(“layer networks”) based on the Qualityof Service requirements on the connec-tions expressed by the CSM. Thus, theCC is the component of the architecturethat maps the abstract, application ori-ented QoS requirements down to require-ments on a specific network technology,e.g. traffic class, bit rate, end-to-enddelay, and cell delay variation. The CCalso handles inter-working betweendifferent network technologies.

The bottom layer of the NRA computa-tional architecture is the Layer Network.The central component here is the LayerNetwork Coordinator (LNC). It dealswith the set-up and management of con-nections within a specific type of net-work. The layer network may be struc-


SSM

CommunicationSession Manager

ConnectionCoordinator

Layer NetworkCoordinator

NML ConnectionPerformer

NMLConnectionPerformer



NE NE NE NE NE NEElements

TerminalCSM

TerminalCSM

Figure 8 Overview of the network resource architecture

tured as a hierarchy of subnetworks.Each subnetwork is controlled by aConnection Performer (CP) component.

Two noteworthy points concerning theNRA are:

• It has a strictly hierarchical structureand is an example of a class of connec-tion control systems referred to as“open signalling systems”. The idea isto implement the network intelligence,i.e. routing algorithms and QoS man-agement, in computers outside theswitches. The switches themselves aresimple and “dumb” and controlledthrough a simple, low level interface,see Figure 9.

• It provides a common architecture forcontrol and management. This is incontrast to traditional network systems,where a distinction is made betweensignalling and management applica-tions, the two being based on totallydifferent software architectures.

3 Relationships to otherwork

This chapter contrasts TINA with relatedwork within the areas of multimedia ser-vices, intelligent networks and broadbandnetworks.

3.1 TINA and other approachesto multimedia services

Regarding full multi-media multi-partyservices, there are several existing stan-dards in the area, like the ITU standardsH.32x for conferencing over POTS,ISDN, LAN and IP networks. In addi-tion, there has long been activities in ITUSG11 for ‘call control’ of multiparty ser-vices inside the framework of B-ISDNsignalling. The purpose of this chapteris to contrast TINA to some of theseapproaches.

3.1.1 The H.32x family

The ITU standards H.32x focus little onconferences on demand. The conferencesare planned in advance and typicallyordered by fax or web. Also the loca-tion/terminal of the different participantsare agreed in advance, so personal mobi-lity is not an issue, and not explicitlycovered.

The H.32x family of systems does notencourage individual tailoring of services

to individual users. By using generic ope-rations, the number of interactionsamong the involved parties tend to bequite large. Normally, the service takesseveral or many seconds to establish.Payment, subscription, etc. are out of thescope and must be handled by proprie-tary means.

There are different versions of this stan-dard for different types of networks. Weconsider H.320 for N-ISDN and H.323for IP as most important and will coverthem specifically.

3.1.1.1 H.320 over ISDN

H.320 standardises multimedia confe-rencing over ISDN. In H.320 the controloperations are sent in-band. First a plainISDN bearer channel (B-channel) is esta-blished from each of the conference par-ticipants to the service provider. The ser-vice provider negotiates the coding for-mats, QoS, number of B-channels, etc.with the conference participants over thischannel. After this set-up phase both con-trol and media streams are sent over theagreed number of B channels.

TINA, in contrast, sends control informa-tion on a logically separate network,which is a better approach when controlinformation is exchanged before themedia streams are set up. Since TINA, asopposed to H.320, supports personalmobility and ‘on-demand’ invitations, noparticular assumptions regarding networktechnology are made at the service con-trol level. Instead, the kTN is used tocarry the control information.

Note, though, that from the networkpoint of view, pure ISDN is used to

support H.320 conferencing. All the con-ferencing related service control is doneend-to-end between the different endusers and the service provider, who isalso an end user seen from the ISDN net-work’s point of view. The conferencingservice unit (MCU) and the software forconference control can be owned andoperated by a service provider differentfrom the ISDN provider. Thus, theyseparate service provider and networkprovider and allow for business relation-ships quite like the way TINA does.

3.1.1.2 H.323 over IP

H.323 standardises multimedia confe-rencing in LANs and IP networks. H.323share with TINA the principles of separa-tion of “service control” from “connec-tion control”. This is done through threedifferent protocols: RAS, H.245 andH.225. H.323 does not, however, focuson conferencing across different admini-strative domains. The focus so far is onconferencing within a single domain,called an H.323 zone.

The gatekeeper is the unit providingaccess control and bandwidth inside oneH.323 zone. Conferencing across severalH.323 zones is currently for furtherstudy; this is linked to the developmentof IP reservation mechanism like RSVPand how zone or domain boarders willaffect the reservation protocols in IP.

H.323 version of conferencing addressesmany other areas as well, such as IPmulticast, and gateways between H.323zones and basic ISDN terminals andH.320 compliant terminals are defined.Thus, terminals outside this H.323 zone,placed in an ISDN network, can partici-


4' 5'4 5 4'' 5''1 6 3 2

Figure 9 Open signalling

Figure 10 Classical signalling

pate in this conference service withoutinvolving any conference service at theISDN side.

We may note that the H.323 standard forconferencing over IP has been developedquickly and mainly by software com-panies, and then put into ITU to be‘stamped’. New versions of the standardare under development.

3.1.2 Control of multimediastreams in OMG

The OMG has just adopted a standardcalled ‘Control of A/V Streams’1. Pro-ducts supporting this standard are ex-pected some time during 1998. TheOMG standard can be seen as a simpli-fied version of the TINA concept ofcommunication session. The proposal isspecifically aimed at being well suitedboth for ATM and for IP networks. Thisillustrates how the TINA communicationsession concept is well suited to fit be-tween TINA Service Architecture anddifferent underlying network techno-logies. It also relates to H.245, being sortof a ‘CORBA-fied’ version of it.

3.1.3 B-ISDN Call Control

In B-ISDN signalling there is the conceptof ‘call control’. In addition, IN trigger-ing mechanisms, like N-ISDN Q.1200-CS3, are assumed in cases where moreadvanced service session control isneeded. This means that service controlis split between the basic B-ISDN signal-ling and IN. Basic B-ISDN signalling

contains generic service operations likejoin, ownership control, etc. in additionto pure connection establishment. Theproposed mechanisms for IN-triggeringare quite complex, so that e.g. personalmobility and other service related issuesmight be handled during connectionestablishment, instead of prior to connec-tion establishment.

As the focus over the last few years hasshifted towards multimedia over IP, itmay be questioned whether service con-trol for this type of services will ever behandled by the far less open B-ISDNsignalling system. Basic connection con-trol may, however, be handled by B-ISDN signalling.

3.2 TINA and IN

TINA has sometimes been referred to as‘the next generation IN’. There is someelement of truth in this expression; thereare similarities between TINA and IN.There are also, however, great diffe-rences, both in scope and technicalapproach. The similarities and diffe-rences will be discussed in the following.The considerations are related to scope,user interface, support for mobility, andsupport for rapid service development.

Both TINA and IN focus quite stronglyon value added services, like freephoneand premium rate. But unlike TINA andH.32x conferencing services, IN is tar-geted towards enhancing N-ISDN andplain telephony (‘POTS’) calls betweentwo endpoints. Other services not basedon N-ISDN, or not based on a two partycall, are excluded from current IN. Thisinvolves most of the multiparty and/ormultimedia services.

All IN services can be used from a plaintelephone without any extra equipment.This usability from every phone is amajor strength with IN. As GSM phones,ISDN phones, and palm tops becomeincreasingly widespread and have in-creasingly good displays, this strengthwill, however, be less important in thefuture. Moreover, many services, e.g.ticket booking, are quite clumsy to usewith the telephony interface and couldobviously be handled better with atext/icon based user interface, more likethe one on the web.

In IN, all outgoing calls are assumed tobe placed from a telephone, and allmessages to the involved parties are sup-posed to be delivered over voice as well.Future multimedia services violate thisassumption, however. If a user wants to‘call’ a ‘multi-media UTP’ number, hemight as well start from a PC, and if thecalled party is not available, electroniccommunication, like e-mail, may takeplace instead. Under such circumstancesthe basic assumptions in IN are invali-dated, and a voice connection neverreally needs to be established.

The assumption in standardised IN is thatBCSM is always used. This translates toan assumption that every service invoca-tion starts with the initiation of anN-ISDN voice call. This assumptionallows personal mobility to be handledduring the establishment of the voiceconnection, i.e. at the originating side foroutgoing calls, and at the terminatingside for incoming calls. In TINA, mobi-lity is handled through interactions overthe kTN (signalling network) beforemedia connections are established. Thisapproach seems to be better sited to sup-port a multi-media and multi-networkenvironment.

The most important goal of IN is to sup-port rapid development of new services.IN has not completely lived up to itsexpectations in this area. This is partlybecause services are based on standard-ised modules called SIBs (service inde-pendent building blocks). Deployment ofnew SIBs in IN tends to require upgradesalso in the switches. Another reason isthat the BCSM and the IN-triggeringtend to make quite complex interactionsbetween INAP and ISUP signalling.A third reason being that the softwaredevelopment environment in IN is aclosed one, and that specialised skills areneeded to do ‘IN-programming’. This isopposed to other approaches towards ser-


1 The term A/V stream in one OMGcorresponds to the more generic termmulti media stream.

1 8

2 3

7 6 5 4

NNI Signalling

UNI Signalling

vice provisioning, notably the Internetand TINA, where open interfaces andstandard application development toolsare used.

One may suspect that very little fromexisting SIBs and IN software may bereused in future multi-media, multi-partyservices. Rather, principles from H.32xand from the TINA service architecturemay be highly relevant in such a context.

3.3 Signalling in B-ISDN andATM

Traditional signalling techniques comefrom the telephony world and these para-digms are still prevalent in broadbandnetworks. For example, the ATM stan-dard for signalling is now Q.2931 whichis based on the narrowband ISDN Q.931standard. The basic principles of thissignalling paradigm is illustrated inFigure 10.

There are several limitations to Q.2931.For this reason, there are currentlyenhancements under study within ITU-Tand ATM Forum. The limitations can besummarised as:

• The model is geared to running asingle connection within a single call.Much more flexibility is needed tosupport multimedia and conferencingservices. There is a need for complextopologies, and some notion of a ses-sion to encompass these multi-partyconnections.

• The implementations of UNI signal-ling have too large a footprint. Allcode needed to run the protocol has tobe built into the terminal. The switchalso needs to run the entire protocolleading to a huge amount of coderunning on the switch. The code is alsoall mixed up with session level logicabout what the end parties can do.

• More than the code, the specificationof the ATM-Forum UNI requiresalmost 150 text book pages to definethe connection management signalling.This is because it must define the de-livery semantics and encoding at thebit level. An equivalent CORBA basedinterface for slightly more function-ality requires dramatically fewer (10 or20) pages and is mainly self documen-ting. The expression ‘CORBA based’automatically defines the deliverysemantics and encoding.

The TINA Network Resource Architec-ture is based on a totally different para-digm, often referred to as open sig-nalling. The paradigm, illustrated inFigure 9, allows third party providers todevelop hardware independent signallingsystems. This software utilizes low-levelopen interfaces for switch control andconfiguration.

The potential benefits of this architectureare:

• The implementation is simpler, since itis based on an underlying DPE.

• Different, more centralised approachesto routing becomes feasible.

• A common architecture can be usedfor both control (e.g. signalling) andmanagement.

• The architecture is well suited to sup-port the complex connection topo-logies needed by multimedia and con-ferencing services

The major obstacle for the TINA NRAand other architectures based on the opensignalling paradigm is the fact that itdiffers so radically from traditional sig-nalling systems and lacks support fromthe major equipment vendors and stan-dards bodies.

4 Future Work

The first phase of TINA-C ended inDecember 1997. In January 1998 the con-sortium embarked on a second phase witha modified organisation. The most impor-tant change is that the Core Team hasbeen dissolved. According to the plan, theconsortium will now be driven by Work-ing Groups consisting of voluntary parti-cipants from the member companies. Theconsortium will be controlled by the Con-sortium Forum (CF) consisting of repre-sentatives from all member companies,and an Architecture Board (AB). The ABwill consist of a limited number of repre-sentatives, and is responsible for the tech-nical coherence of the work plan, and forsetting up the Working Groups. With thenew organisation, TINA-C also intro-duced multiple membership classes, theidea being to increase the number ofmember organisations, and especially toencourage universities to join.

The decision to organise an extension ofTINA is clearly motivated by the fearthat the architecture and specificationswill have very little impact on the in-

dustry if the Consortium is closed now.Firstly, there is a need to promote theresults to a wider audience than the rela-tively closed group of companies thathave been involved so far. Part of thestrategy is to try actively to involve moreorganisations in the consortium, and tospend resources on large scale demon-strations of services based on the TINAarchitecture. Several demonstrations areplanned during 1998, involving majorcompanies.

Moreover, there are several unfinishedparts of the architecture. Several refe-rence points have not been specified.Many feel that the architecture needssimplification, and strategies for migrat-ing from existing telecommunicationsarchitectures to TINA are not adequatelydescribed.

At the time of writing, the followingWorking Groups (WG) have beenestablished:

• DPE WG. The purpose of this WG isto continue the clarification of theadditions required in the area of Distri-buted Processing Environment to theOMG specifications, and to continuethe effort to encourage adoption ofcorresponding specifications by theOMG.

• Service Management WG. The pur-pose of this WG is to define a frame-work for service management, recog-nising that the service managementarea is poorly covered in other forums.

• IN and TINA WG. The purpose of thisWG is to specify strategies to migratefrom services based on ITU-T IN toTINA based services, and to promoteand contribute elements of the TINAarchitecture to the groups withinITU-T standardising IN and UMTS.

• Next Generation Mobility WG. Thepurpose of this WG is to further de-velop the work done by TINA withinthe areas of personal mobility andterminal mobility, and to contributethe results to standardisation bodiesworking with future mobile networks,such as UMTS.

An unanswered question is whether thebest approach is to pursue the TINAideas within a TINA consortium, orwhether to do it within other forums,such as the OMG TelecommunicationsDomain Task Force, which includesmany of the same members, and even thesame people.


5 Concluding remarks

The TINA architecture promotes manyprinciples that apparently would havegreat benefits to different stakeholders inthe telecommunications industry if theywere adopted. By hiding the complexityof the networks from the services, theTINA architecture could help operatorsdevelop common services over differentnetwork technologies, and to introducenew services more rapidly, thereby re-ducing operations and maintenance costs.Furthermore, the use of a generic distri-buted processing environment ensuresportability across multi-vendor equip-ment, the telecom industry to benefitfrom advances in computing technology,e.g. object orientation and distribution.Finally, the use of a common architecturefor all kinds of services would enablemanufacturers to adopt a common app-roach to services and their management.

Although many of the underlying prin-ciples of TINA are useful, it is not cur-rently clear that TINA as such will bewidely adopted. One of the major pro-blems of the architecture is its hugescope. If introduced all at once, it wouldrepresent a revolution in the telecommu-

nications industry. That is not likely tohappen. Of course, TINA is not necessa-rily a question of all or nothing. A systemmay use only part of the TINA architec-ture, neglecting other parts. Clear strate-gies are lacking, however. A secondproblem is the lack of industry supportoutside the research organisations of themember companies. So far, TINA pro-ducts are non-existent. Finally, TINAfaces competition from other initiativeswith partly overlapping goals. Some ofthese initiatives have a stronger industrysupport and move much faster thanTINA, e.g. the OMG, the ITU-T H.32xseries of recommendations, the Javacommunity, and several activities withinthe Internet community related to multi-media services and future network infra-structure.

6 References

Note: The TINA documents are availablefrom the TINA-C Web sitehttp://www.tinac.com.

1 Darmois, E, Hoshi, M. SoftwareArchitecture for Multimedia andInformation Services. Global Com-munications, 1997.

2 Informational Modelling Concepts,Version 2.0. TINA-C, April 1995.

3 Computational Modelling Concepts,Version 3.2. TINA-C, May 1996.

4 Engineering Modelling Concepts.TINA-C, December 1994.

5 TINA Service Architecture, Version5.0. TINA-C, June 1997.

6 TINA Network Resource Architec-ture, Version 3.0. TINA-C, February1997.

7 TINA Business Model and ReferencePoints, Version 4.0. TINA-C, May1997.

8 Ret Reference Point Specification,Version 1.0. TINA-C, September1997.

9 The ConS Reference Point, Version1.0. TINA-C, November 1996.

10 The Tcon Reference Point, Version1.1. TINA-C, November 1996.

11 Solbakken, H et al. CORBA as anArchitecture for Distributed Systems.Telektronikk, 94 (1), 107–118, 1998(this issue).

12 Rumbaugh, J et al. Object-OrientedModeling and Design. EnglewoodCliffs, NJ, Prentice Hall, 1991.

13 Service component specificationspart B, Version 1.0. TINA-C, Janu-ary 1998.


Tom Handegård is Research Scientist at TelenorR&D, Kjeller, where he has been employed since1990. He has been working with Intelligent Net-works, B-ISDN signalling, and the TINA architec-ture. Currently, his main interests are withinvarious aspects of distributed object-orientedsystems, including CORBA and Java technology.


Lill Kristiansen holds a PhD (Dr. Scient) in mathe-matical logic from the University of Oslo in 1993.She worked with object oriented methods andtools applied to IN and TINA at Telenor R&D from1993 to 1997. She is currently working as processand methodology coordinator at Ericsson, in theInternet/Broadband group. She is also engaged atUniversity Studies at Kjeller (UNIK) as associateprofessor.


This article provides an overview ofthe Common Object Request BrokerArchitecture (CORBA) as a techno-logy for distributed computing andsystems integration. CORBA is bothrobust and commercially available. Itprovides a relatively high-level solu-tion for program-to-program commu-nication, interoperability across diffe-rent platforms, networks and lan-guages, and a rich infrastructure fordeveloping, integrating and runningdistributed applications.

There is a trend in enterprise applica-tion development towards three-tier ormultitier architectures with thin Web-based clients and integration of legacysystems. CORBA fits well into thispicture, and major computer softwarevendors have chosen CORBA as a keytechnology for the next generationWeb.

CORBA has become an interestingtechnology for telecom applications aswell. OMGs Telecom Domain TaskForce is currently working on how tointroduce CORBA in telecommunica-tion management systems, includingsystems based on TMN and SNMP,and in Intelligent Networks (IN).

1 Introduction

The design and implementation of soft-ware is a difficult and expensive activity,especially when the software has to runon a network of machines, with the over-all functionality distributed among themachines, and when the software has tobe integrated with other systems, such aslegacy systems or purchased systems.This is increasingly the situation today.To add to the complexities, today’s soft-ware often has to deal with heterogene-ous environments of different languages,platforms and network protocols.

The challenges of developing distributedsoftware stem from fundamental prob-lems, such as detecting and recoveringfrom network and host failures, and fromlimitations with tools and techniquesused to build such software. The chal-lenges of integrating systems stem fromthe use of different models, languages,interfaces and protocols.

Distributed object computing is a promi-sing approach to distributed computingand systems integration. It combines twomajor areas in software technology: dis-tributed computing systems and object-

oriented design and programming. Distri-buted computing system techniquesfocus on how to provide support forresource sharing, openness, concurrency,scalability, fault tolerance and trans-parency [1]. Object-oriented design andprogramming, on the other hand, focuson reducing complexity through modu-larization, encapsulation of data andmethods, inheritance, polymorphism andreuse of existing components.

The two most widely adopted distributedobject computing models are the Com-mon Object Request Broker Architecture(CORBA), which is standardised by theObject Management Group (OMG), andthe Distributed Component Object Model(DCOM), which is being developed byMicrosoft.

CORBA defines how client applicationscan invoke operations on server objects,no matter where they are located andwho designed them, using the services ofan Object Request Broker (ORB). TheOMG has two main goals with CORBA[2]. Firstly, to make it easier to imple-ment software that must bridge theboundaries of different platforms, net-works, and languages. Secondly, toencourage the development of open soft-ware that can be used as components oflarger systems. The ultimate goal is toreduce complexity, lower cost and hastenthe introduction of new software applica-tions.

CORBA specifications and implementa-tions have been evolving over severalyears, and they are still under construc-tion. Although the first CORBA specifi-cation was defined in 1991, and CORBAproducts have been available since 1993,it is just in the last year or two that reallyworkable standards as well as completeand robust implementations have beenproduced.

The adoption of CORBA technology hasincreased rapidly in the same period,partly because of the marriage ofCORBA and Web-technology. Majorcomputer software vendors such as Net-scape, Oracle, Sun and IBM have chosenCORBA as a key technology for the nextgeneration Web. The new Web, calledthe Object Web [3], will be used to buildand deploy full-blown business applica-tions based on three- and multitier archi-tectures, and thin clients running in Web-browsers, providing a globally accessibleuser interface.

Over the last two years the authors of thisarticle have both studied and gainedpractical experience with CORBA. Aspart of the ACTS ReTINA project, weare currently building a BVPN (Broad-band Virtual Private Network) demon-strator using CORBA [4]. The main aimis to test the ReTINA DPE (DistributedProcessing Environment), a real-timedistributed processing environment basedon CORBA.

The aim of this article is to provide anoverview of CORBA and how to useCORBA to develop distributed applica-tions. We provide an introduction toOMG and the CORBA standard and lookinto how to use CORBA to implementapplications. We present an architecturefor CORBA applications and explainhow this architecture can be enriched bythe use of Java and Web-technology. Wealso describe how CORBA can be inte-grated with database systems and Trans-action Processing (TP) monitors, andhow CORBA can be used for systemsintegration. After looking into thesegeneral issues about using CORBA, wepresent the status with respect to the useof CORBA in telecom applications. Thelast part of the article compares CORBAwith DCOM and other distributed objecttechnologies, and presents an overviewof CORBA products and also the futuredirections for CORBA.

2 OMG and CORBA

OMG was founded in May 1989 as aninternational industry consortium con-sisting of eight companies: Sun Micro-systems, Unisys Corporation, Data Gene-ral, Canon Inc., Philips Telecommunica-tion N.V, Hewlett-Packard, AmericanAirlines, and 3Com Corporation. This listhas now increased to over 700 membersworld-wide, and it is the largest softwareconsortium in the world today. The orga-nisation is a non-profit corporation. Itdoes not develop software itself, butrather makes specifications for develop-ment and deployment of heterogeneousdistributed systems.

In order to make a specification within acertain area (e.g. naming service), a taskforce within OMG sends out an RFP(Request For Proposal). Each OMGmember that intends to respond to anRFP, whether individually or jointly withother members, must submit a letter ofintent (LOI) to respond to OMG by adate specified in the RFP. This date is

107

CORBA as an Infrastructure for Distributed Computingand Systems IntegrationH Å K O N S O L B A K K E N ( E D I T O R ) , O L E J Ø R G E N A N F I N D S E N , E I R I K D A H L E , T O M H A N D E G Å R D , K J E L L S Æ T E N

Telektronikk 1.1998

typically 60 days before the initial sub-mission date. Often more than one pro-posal will be received, and a review andvoting process is conducted to select oneof them. OMG will then adopt the speci-fication and vendors can start the imple-mentation. Note that after a membersends a proposal to an RFP, it must havean implementation within six months.Therefore, most of the adopted specifica-tions are based on proven technology.

Sometimes a Request for Information(RFI) is sent out prior to an RFP. TheRFI is a general request to the computerindustry, universities, and any otherinterested parties to submit informationabout a particular technology area to oneof the Task Forces in OMG. Based on theresponses, an RFP might be sent out.

2.1 The Object ManagementArchitecture

OMG has specified a high-level architec-ture called Object Management Architec-ture (OMA). OMA provides a frameworkof services, facilities, and interfaces fordistributed systems, and it consists offive components.

• Object Request Broker (ORB): is thesoftware communication bus that allobjects use to communicate.

• Object Services: provides funda-mental, commonly used functionalityto other CORBA objects.

• Common Facilities: while Object Ser-vices provides services to objects,facilities provide functionality to appli-cations. Example of such a facility isthe System Management Facility.

• Domain Interfaces: these are interfacesfor specific application fields ordomains, like telecom, finance andhealth.

• Application Interfaces: are interfacesfor a specific application, and not partof the OMG standard, since OMG doesnot develop applications, and probablynever will.

The rest of this section will concentrateon the ORB architecture and the ObjectServices. While a lot of the Object Ser-vices have been specified, the domaininterfaces and the common facilities arethe most recent areas of focus, and willnot be described in more details.

2.2 CORBA

The most important part of OMA is theCORBA specification. It describes indetail the interfaces and characteristics ofan ORB. It contains all the necessaryfunctionality to identify and locateobjects, handle connections, invokemethods on objects, and pass data be-tween objects. The latest revision of theCORBA specification is CORBA 2.0,and the major components in it are: ORBcore, Interface Definition Language(IDL), Inter-ORB Protocol (IIOP), staticand dynamic invocations, language map-pings, and Object Adapters. We will startby explaining what IDL is, then give anexample of how to use CORBA (usingStatic invocation), followed by a shortdescription of dynamic invocation, inter-face repository, and object adapters.

2.2.1 IDL

In order for a client to communicate witha CORBA object it needs to know whatoperations or services that object canprovide. This is often called the interfaceof an object and in CORBA this interfaceis specified using IDL. Even though IDLhas a somewhat similar syntax to C/C++,it is not an imperative programminglanguage, but a declarative language.This means that the interface and theimplementation are separated, and theimplementation can be programmed inany programming language with a map-ping to IDL. Languages with a mappingfrom IDL include C, C++, Smalltalk,Cobol, and Java. A language mappingmeans that each element in IDL is trans-lated to a construct in the target languageusing an IDL compiler. An interface inIDL is for example mapped to an inter-face in Java, and to a class in C++.

So what does IDL look like? Figure 2 isan example from an ATM configurationmanagement system.

Modules are used to control name spaces.To refer to LayerNetwork above, youneed to use the module-name:NRCM::LayerNetwork. LayerNetwork isan interface, inheriting methods and attri-butes from ATMObject (not shown).Interface inheritance is an importantfeature in IDL, and it allows reuse ofexisting interfaces. All the methods andattributes in ATMObject will be inheritedinto LayerNetwork. LayerNetwork addstwo methods, createSubnetwork andupdateBandwidth. The createSubnetwork


Object Request Broker

ApplicationInterfaces

DomainInterfaces

CommonFacilities

ObjectServices

Figure 1 Object Management Architecture

module NRCM

interface LayerNetwork : ATMObject

exception AlreadyExists ;

Subnetwork createSubnetwork(in string name) raises (AlreadyExists);

void updateBandwidth(in string name, inout long bw);

;

;

Figure 2 IDL example

method creates a new Subnetwork objectwith the name given as in parametername, and it returns an object referenceto the newly created Subnetwork object.updateBandwidth takes a layer-networkname and a bandwidth (bw) as in para-meter. bw is also an out parameter, and itreturns the available bandwidth of thelayer-network. IDL operations can raiseexceptions to indicate the occurrence ofan error. The createSubnetwork methodchecks if a subnetwork with the samename already exists, and if it does, itgives an AlreadyExists exception back tothe calling object.

IDL is a simple, declarative interfacedefinition language. It does not includefeatures for defining object behaviour. Itallows mappings to both object-orientedand non-object-oriented languages. It ispossible to have a mapping to for ex-ample COBOL, which is important whenencapsulating legacy systems.

2.2.2 CORBA development process

Now that you know IDL, let us see howyou can write a client/server application.

Figure 3 shows the development process.You start by writing the IDL in a file,and the interfaces will be the contractbetween the client and the server pro-gram. A client programmer runs the IDLfile through an IDL compiler to producestub code in the selected language. Hethen writes a client program which in-vokes the operations defined in the IDLfile, and then link this code with the stubsfile. The client is then ready to go. A ser-ver programmer will start his work byrunning the same IDL file through anIDL compiler to produce skeleton codein his favorite language. He then imple-ments the interfaces in the IDL file, andcompiles and links them with the skele-ton code. Note that client and serverprogrammers can select different imple-mentation languages. So what happenswhen the two programs are executed?The server program creates someCORBA object, and the client gets areference to this object. It can get thisinitial reference either from a NamingService, from a proprietary bind mecha-nism, or by importing a stringified objectreference from a file. This object refe-rence is really a pointer to a local proxythat represents the object on the server.The client does not need to know wherethe real object is or anything else aboutit, except that it must provide the func-tionality specified by the IDL. The client

can be written in Java, running on Win-dows, while the server can be written inC++, running on Solaris. When the clientcalls a method, it really calls the localproxy, which sends a request to the ser-ver, which calls the skeleton code, whichagain calls the real implementation. Theimplementation code is executed, andthen the result is returned in the oppositedirection. The strength of this approach isthat the environment in which the clientand the server execute can be completelydifferent, they are still able to communi-cate with each other.

2.2.3 IIOP

CORBA 1.2, which came in 1991, didnot specify the protocol it would use forsending requests and data betweenobjects. This led to a different, proprie-tary protocol for each CORBA vendor. In1995, the CORBA 2.0 specification wasreleased, and one of the most importantfeatures was that it specified an on-the-wire protocol for interoperability be-tween ORBs from different vendors. Thisprotocol is called Internet InterOrb Proto-col (IIOP), and it is running over TCP/IP.An IIOP packet consists of all the infor-mation an ORB needs, the target object,the operation being called, and the para-meters in the call. IIOP provides the pro-tocol, but something more is also neededin order to provide interoperability be-tween different ORBs. The object refe-rences that each ORB uses must be stan-dardised. CORBA 2.0 does this by speci-

fying an Interoperable Object Reference(IOR). This means that if you have anIOR to an object, you can talk to it. Itcontains information about the machine-name and the port of the server, the nameand the type of the called object and so on.

2.2.4 Dynamic Invocation andInterface Repository

Static invocation is appropriate for pro-ducing client/server application software.However, sometimes you want to be ableto talk to an object without knowing itsinterface at development time. This is thecase for tool-builders who want to maketools that list methods and attributes andpossibly invoke methods on any object.OMG has called this dynamic invocationand it is provided in CORBA 2.0 byusing what is called Interface Repository(IR). Whenever you compile an IDL file,you can specify that you want the meta-data to be inserted in the IR. A client thatwants to use the object without havingthe IDL file, can then ask the IR for themetadata and construct a call to theobject at runtime. The drawback withdynamic invocation is that it is cumber-some to program and fortunately mostclient/server application programs do nothave to use it.

2.3 CORBA Services

The idea behind the CORBA Services isto provide fundamental services to appli-cation objects. OMG has defined the


IDL

IDLCompiler

IDLCompiler

Client developer Server developer

Client"stub"

Server"skeleton"

Client Server

Figure 3 The CORBA development process

interfaces (in IDL) and the semantics ofeach of the services. The implementa-tions of the services are not standardized,and it is up to each vendor to make surethey deliver the functionality specified byOMG.

There are 17 object services as per today,and more might be added later. The 17services are: Collection, Properties, Con-currency control, Query, Event notifica-tion, Relationships, Externalization, Ini-tialization, Security, Licensing, Startup,Life cycle, Time, Naming, Trader, Per-sistence, and Transactions. Below is adescription of some of the most impor-tant services.

Naming: This service is often comparedto the white pages in a telephone direc-tory. It allows a client to find an objectbased on a name. A server can registervarious objects by giving them a name,and the client asks the Naming Servicefor an object reference by specifying aname.

Event: This service is used for sendingasynchronous events between objects.An object can ask the event service to benotified when a specific event occurs,like an attribute changing value in an-other object. The sender and the receiverof the event do not have to know abouteach other, and it allows one-to-manycommunication.

Trader: This service can be compared tothe yellow pages in a telephone directorywhere it is possible to find objects basedon some search criteria. It can also becompared to a Web-site search enginethat returns object references instead ofURLs.

Security: In all systems and especially indistributed systems, security is an all-important issue. CORBA addresses theseissues in the Security Service. It is con-cerned with confidentiality and integrityof the data, accountability of users andavailability of a system. Unlike some ofthe services mentioned above, security isan integrated part of the system and notjust a standalone service.

Transaction Service: See section 3.4.

3 Using CORBA

In this section we will look into how touse CORBA in the realisation of appli-cations.

3.1 Three-tier architecture

Traditionally, client-server applicationshave mostly been based on two-tierarchitectures; either with all the applica-tion logic on the desktop, the server run-ning only the DBMS, or with a slightlythinner client and some application logicon the server, e.g. in the form of DBMSstored procedures. The main advantagesof the two-tier architecture is its simpli-city; it is quite straightforward to decidewhich functions go where, and normallyall development tools can be purchasedfrom one vendor.

Two-tier architectures have a number ofserious shortcomings, leading to in-creasing popularity for three-tier archi-tectures. These architectures are definedas follows. The first tier contains theclients, typically providing a user inter-face and local processing as appropriate.Generally, the clients can be kept small.The second tier (or ‘middle tier’) con-tains the application logic, while the thirdtier contains DBMSs and other back-endsystems. The clients should never accessthe systems in the third tier directly. Themiddle tier makes abstractions of theresources in the third tier, and therebyshields the clients from the plethora ofback-end systems. A replacement of aback-end system such as a DBMS withanother one should not affect clients.

The advantages of three- over two-tierarchitectures include

• thin clients (only presentation logic).Thin clients are suitable for executionwithin Web browsers, which arerapidly becoming very popular asgeneral front-end tools

• less communication overhead, sincemost of the data processing is donewithin the middle tier, located on theserver

• DBMS independence, and ability toutilize data from multiple sources

• better support for inter-applicationcommunication and integration withlegacy systems (see below).

The main drawbacks of three-tier archi-tectures compared to two-tier architec-tures are the increased complexity andthe fact that very often no single vendorprovides the complete infrastructure.

CORBA applications are typically basedon the three-tier architecture, as illu-strated in Figure 4. Typically, clients pro-

vide the user interface and interact withmiddle tier objects over an ORB. Themiddle tier infrastructure may also offerthe clients an interface based on Micro-soft’s DCOM. In some cases this may bean attractive alternative for clients run-ning on Windows platforms. OMG hasdeveloped a DCOM-CORBA interopera-bility standard, and gateway products areavailable from CORBA vendors.

The middle tier contains the objects,often called ‘business objects’, thatimplement the application logic. Busi-ness objects within this tier may them-selves have client-server relationships.The term multi-tier architecture is some-times used to emphasize this aspect ofthe middle tier.

The business objects can also utilizefunctionality provided by CORBA ser-vices, such as transactions and securityservices. They communicate amongthemselves and with the object servicesover an ORB. This means that thebusiness objects can be distributed over anumber of processing nodes. The parti-tioning of objects onto processing nodesdepends on requirements on performanceand the number of simultaneous clients.Additionally, object TP monitors can beused to improve the performance andfault-tolerance of the middle tier applica-tions by providing mechanisms such asload balancing and object replication (seesection 3.4).

The back-end tier contains databases andlegacy applications. The middle tierobjects communicate with the databasesand applications in the third tier usingwhatever protocol or middleware avail-able, CORBA compliant or not. CORBAvendors already support a range of adap-ters and mechanisms enabling CORBAobjects in the middle tier to communicatewith some of the most popular DBMSsand other legacy systems, see sections3.3, 3.4, and 3.5 for more details.

3.2 CORBA, Java, and the Web

Java is an object-oriented programminglanguage that has gained much attentionover the last couple of years. The mainreason for Java’s popularity is the lan-guage’s inherent support for portability,mobile code, Web integration, and arelatively rich, standard class library.

As with all popular programming lan-guages, OMG and the CORBA vendors


have undertaken a number of efforts toprovide support for the use of Java inCORBA environments. The reason forthe strong interest in Java is that Java hasa number of properties that are comple-mentary to the properties provided bythe CORBA architecture as such.

Firstly, Java provides the ability to writeportable clients and object implementa-tions. Once a CORBA object has beenimplemented with Java, it can be runanywhere without the need for recom-pilation.

Secondly, Java offers simplified codedistribution. Client applications do nothave to be installed on client computers,but are downloaded from a central (Web)server as needed. Note that in this case,there are two ways to support CORBAon the client (browser) side. The firstalternative is to include a Java ORBwithin the browser. This approach issupported by Netscape, who provides aJava ORB with every instance of their

browser. The second alternative is todownload all the necessary ORB func-tionality from the Web server along withthe applet (in this case often referred toas an ORBlet). The latter alternative hasthe disadvantage of increased downloadtime on startup, but the advantage that itrequires no pre-installed CORBA supporton the client side.

Thirdly, Java supports Web integration.Client applications (Java applets) can bediscovered through Web surfing, down-loaded into Web browsers and be inte-grated within HTML pages.

Finally, Java is a simpler language towrite object implementations than C++,the most common language used forCORBA objects so far. On the downside,the performance of Java is poorer thanthe performance of C++, although thearrival of JIT (Just-In-Time) compilersfor Java has recently improved Java per-formance.

Through Java, CORBA is integrated withWeb technology. The Java-CORBAcombination is currently regarded bymany (e.g. by Netscape and Oracle) asthe most important element of an infra-structure for the next generation WWW,the so-called ‘Object Web’.

Note that in the Java case, the OMG isfor the first time working on an inverselanguage mapping; a Java to IDL lan-guage mapping. The motivation is to en-able automatic generation of IDL fromJava interface definitions. This will ineffect hide IDL from developers workingwith pure Java applications. Proprietaryproducts supporting automatic Java-to-IDL are already available. These toolsprovide programmers with an environ-ment very similar to the one provided byJava RMI (see section 5.2), yet at thesame time preserve the interoperabilityproperties of CORBA, e.g. allowingaccess to the Java objects from clientswritten in other languages, through theautomatically generated IDL interface.


Application server

HTTP/IIOPInternet

Legacy systems

HTMLpages

Middle tierClient-tier Back-end tier

Javaapplets

Gateway

Databaseadapters

Businessobjects

Billingservice

Objecttransaction

serviceO

bjec

t R

eque

st B

roke

r

Web server

Databases

HTTP

Firewall

Figure 4 Three-tier architecture based on CORBA and Internet technology. The first tier contains the client components thatprovide a user interface and local processing as appropriate. Typically, the clients can be implemented as CORBA-enabled appletsrunning inside Web browsers. The middle tier contains HTML pages and Java applets that are stored on Web servers, and objectsthat represent persistent data and implement business logic and are running on application servers. All the middle tier objects areinterconnected by an ORB. The objects can utilize functionality provided by general services, such as transaction services, billingservices, and security services. The back-end tier contains databases and legacy systems. They are integrated with the middle tier

business objects through database adapters and gateways, respectively

3.3 Integration with databases

Many CORBA applications will needsupport for object persistence. An objectis said to be persistent if it is stored insuch a way that it remains available forany application that needs it, even if theserver process that manages the object isno longer active. Typically, persistentobjects are stored in databases. If goodsupport for object persistence is to befound in a CORBA environment, certainrequirements must be met both by ORBsand DBMSs (database management sys-tems).

The most important requirement forDBMSs is support for storing objects asobjects, i.e. without having to dis-assemble the objects, e.g. into relationaltuples, in order to store them. It is ofcourse possible to make objects persis-tent by means of a DBMS that does notunderstand objects, but it will be cumber-some and/or yield poor performance.Products exist that map objects to rela-tions, but storing object directly in data-bases appears to be a better solution.Two kinds of DBMSs are competing inthis market: object-relational(ORDBMSs) and object-oriented(OODBMSs). The first group consists ofrelational database products with objectextensions added to them, more or lessaccording to the emerging SQL3 stan-dard. The three products currently lead-ing this trend are Oracle, DB2, and Infor-mix, with Sybase and SQL Server as pos-sible future contenders. The other groupconsists of DBMSs that have been de-signed for objects from the very begin-ning. The pertinent standard for thisgroup is ODMG-93, from the ObjectData Management Group (www.odmg.org). Some of the more well-knownproducts are GemStone Objectivity/DB,ObjectStore, O2, Poet UniSQL and Ver-sant.

The two most important requirements forORBs are support for loaders and user-defined object names, also known asmarkers or reference data. A loader is aroutine that is capable of loading a givenobject from a file or database in the eventthat a client tries to invoke a method onan object that happens not to be inmemory. Without a loader, such a situa-tion will result in an object fault, and theclient’s request cannot be processed.Support for user-defined object names isnecessary because every time a loaderbrings a given object in from the data-base, it must be able to assign the same

name to it. This is a prerequisite, becausethe object name is the key used by theORB to determine whether or not aninvoked object is in memory, and if not,the object name is used by the loader tofind the requested object in the database.If the object name were to keep changingall the time, this way of doing thingssimply would not work. Neither loadersnor user-defined object names are re-quired by CORBA, but we think thatsooner or later OMG will have to specifya standard solution to these issues. Theoverall architecture for a CORBA serverwhose objects are stored in a database, isshown in Figure 5.

The glue that is used to tie together anORB and a DBMS, is frequently referredto as a database adapter. In addition to aloader, a database adapter must have amodule that can take care of memorymanagement. This will typically involvethings like keeping track of whichobjects are being referenced by clients,and preventing the server’s memory frombeing overloaded with database objects(the number of objects in the databasecould easily exceed the capacity of theserver) by choosing suitable victimswhenever necessary (e.g. based on a leastrecently used algorithm) and throwingthem out. Should such a victim be in-voked by a client holding a reference toit, then the loader will automaticallybring the object in question back into theserver’s memory.

Two CORBA services are particularlyrelevant in a database context, namelythe Persistent Object Service (POS) andObject Query Service (OQS). POS pro-vides generic interfaces that can be usedwith a variety of data stores, thus makingit easy to port CORBA applications fromone data store to another. However, it isnow recognised that the first version ofPOS has been a failure, and OMG is cur-rently working on a major revision. OQSenables clients to submit ad-hoc queriesto the CORBA server, using a querylanguage supported by the underlyingdata store, typically Structured QueryLanguage (SQL) or Object Query Lan-guage (OQL).

3.4 ORBs and Transactions

If a server is to provide advanced ser-vices and/or support a large number ofconcurrent clients, one soon discoversthat just having a CORBA-compliantORB is insufficient. Developers of such

systems will require more sophisticatedenvironments, with support for transac-tions, concurrency control, naming, noti-fication, security, system management,load balancing, and more. As mentionedelsewhere in this article, OMG has de-fined a number of CORBA Services thataddress these needs. However, there isalso a need to integrate such services ina coherent way, and products that arecapable of such integration are oftenreferred to as TP monitors.

The most important benefit that TPmonitors has to offer CORBA environ-ments, is probably that of making client-server interactions transactional. In parti-cular, this means that a client can make


CORBA SERVER

Database Adapter

DATABASE

Figure 5 A database can contain a largenumber of persistently stored objects,and it may not be feasible to have all ofthose objects inside the server’s addressspace at any one point in time. The solu-tion is to have a database adapter thatcan throw out objects whenever that isnecessary in order to make room for newones. If a thrown out object (shown as adotted circle in the figure) is re-invokedby a client, the database adapter, bymeans of its loader component, will bringthat object back in from the database.This happens transparently to the client.Thus, any object in the server’s addressspace has a persistent version of itself inthe database, but the converse is not true

several invocations on the server, andthen decide whether to commit or abortthe work thus performed. In other words,several operations can be grouped into asingle logical unit of work (LUW), andeither all effects of that LUW are appliedto the server, or they are all wiped out,meaning the server will be left in a stateas if the LUW in question never executedat all. This property is known as atomic-ity. If more than one data store is in-volved in a LUW, then one must in gene-ral use a protocol known as two-phasecommit (2PC) to ensure atomicity. Anydecent TP monitor will support 2PC, andtherefore free CORBA programmersfrom the non-trivial task of implementingthat protocol.

Two of the CORBA Services are of parti-cular interest in this context, viz. theObject Transaction Service (OTS) andthe Concurrency Control Service (CCS).OTS and CCS correspond to the twoproblem domains dealt with in transac-tion management respectively; (1) re-covery – making sure that work done bytransactions are either properly com-mitted or rolled back, and (2) concur-rency control – making sure that differenttransactions do not unduly interfere witheach other. Both these aspects of transac-tions must be dealt with in order toensure the classical ACID properties(atomicity, consistency, isolation, dur-ability). Products that implement OTSand CCS are now available in the

marketplace. The current trend seems tobe to market OTS and CCS as key com-ponents of TP monitors, rather thanselling them as separate products.

TP monitors have been successfully usedin mainframe environments for some20 years (e.g. CICS), and are just nowbeginning to emerge in the CORBAmarketplace. Several TP monitors orOTS/CCS implementations for CORBAenvironments were available, or about tobecome available, by late 1997. Iona hasteamed up with Groupe Bull and Trans-arc to offer OrbTP and OrbixOTS/Orbix-OTM, respectively. IBM’s ComponentBroker includes a TP monitor which, likeOrbixOTM, is based on Encina fromTransarc. And BEA Systems offers aTuxedo-based TP monitor called Object-Ware.

3.5 Systems Integration

Due to its inherent ability to overcomeproblems related to distribution as wellas language and platform heterogeneity,CORBA is positioned to play a signifi-cant role in the area of systems integra-tion. In particular, many companies thatuse mainframes will find it interestingthat by means of IDL their legacy sys-tems can be accessed by clients runningon PCs or Unix workstations. For ex-ample, an ORB running on a mainframecan provide access to applications run-

ning in CICS or IMS regions. This can beachieved in at least two different ways.One alternative is to have a gateway ser-ver that accepts an incoming CORBAmethod and then either builds a CICSComarea which is passed to the CICSprogram or builds an IMS messagewhich is submitted to the IMS inputqueue. The other alternative is to re-writeexisting applications so that they can actas CORBA server implementationobjects. The latter provides more flexi-bility but requires an ORB that supportsthe native language of the legacy applica-tion in question, typically Cobol. Forcompanies that have invested heavily inmainframe applications, integration withPCs and workstations could be a majorincentive to adopt CORBA technology.

As a more general observation, one couldsay that OMG in its approach to systemsintegration has chosen a level of abstrac-tion that is a lot more reasonable thansome of the alternatives. Enabling inte-gration by insisting that all systems berun on the same operating system, and/oruse the same programming language, isunrealistic in the first place. Moreover, itwould at best be a partial solution to theintegration problems. At least twoalternatives remain. One is to build agateway for each pair of systems thatneed to interact, the other is to create aframework to which any system thatobeys certain rules can be connected. Theadvantages of the latter approach overthe former is illustrated in Figure 6.CORBA is an example of a framework-based approach to interoperability. It isinteresting to observe that object-orienta-tion, which separates external (object)interfaces from internal implementationdetails, seems to be an ideal foundationfor interoperability frameworks. In theforeseeable future therefore, we expectany CORBA competitors to be otherobject-oriented middleware architectures,most notably DCOM from Microsoft.

4 CORBA for telecomapplications

CORBA is rapidly becoming one of thetechnologies of choice for developingdistributed systems in all areas of infor-mation technology including telecommu-nications. The following sections willdiscuss CORBA for telecom manage-ment systems, CORBA for IN, andCORBA support for multimedia appli-cations.


Custom Interface Solutions Framework-based Solutions(Good Software Architecture Practices)

Order (N*N) Interfaces Order (N) Interfaces

Figure 6 This figure illustrates one advantage of a framework-based approach tointeroperability. If a gateway is to be built for each pair of systems that need to inter-act, the number of gateways needed will be proportional to the square of the number ofsystems. When using a framework like e.g. CORBA, one interface per system will suf-fice. (Figure adopted from [5])

CORBAmanager

Gateway OSIagent

IDLGDMO/CMIP

OSImanager

Gateway CORBAagent

IDLGDMO/CMIP

Figure 7 The gateway assumes the role of an OSI manager.This allows a CORBA system to manage TMN-compliant net-work elements and mediation devices, and is a likely way ofintroducing CORBA into the TMN architecture. The installedbase of network elements remains as they are (provided thatthe network elements support GDMO/CMIP communication)

Figure 8 The gateway assumes the role of an OSI agent.This allows a TMN system to manage network elements with

IDL interfaces, which may be interesting in the future.More important, the gateway’s ability to play the role of bothagent and manager means that CORBA management systemscan interoperate with TMN management systems – in TMN

terms referred to as peer communication between OperationsSystems

4.1 CORBA and Telecommu-nications ManagementSystems

Telecommunications Management Sys-tems in this context comprise Telecom-munications Management Network(TMN) -compliant systems and SNMP-based systems. TMN is an architecturespecified by ITU-T and ETSI, andapplied by Network Management Forum,for management of telecom networks andservices. SNMP (Simple Network Man-agement Protocol) from IETF is used formanagement of data equipment, routers,etc. Both TMN and SNMP have a man-ager-agent communication architecture.TMN has selected OSI ‘Guidelines forthe Definition of Managed Objects’(GDMO) and ‘Abstract Syntax Notation1’ (ASN.1) as the interface specificationlanguage, and OSI Common Manage-ment Information Protocol (CMIP) as theapplication layer protocol.

The JIDM group of Network Manage-ment Forum (NMF) in conjunction withthe Open Group has pioneered the map-ping between GDMO, CORBA andSNMP. They have a complete specifi-cation for a static translation between

GDMO and IDL, and an interactiontranslation specification is underway.

The OMG Telecom Domain Task Forceis looking at two aspects:

1. CORBA and TMN/SNMP coexistenceand interoperability (a similar objec-tive as NMF)

2. CORBA architecture inspired byTMN.

As regards interoperability, OMG issuedan RFP titled “Interoperability betweenCORBA and Telecommunications Man-agement Systems” in September 1997.Adoption of the specification is expectedat the end of 1998. The scope of the RFPis to address the integration of GDMO/CMIP and SNMP management applica-tions and protocols into a CORBA en-vironment through an application proto-col gateway. Only the GDMO/CMIPintegration is covered here, but a similarapproach is also requested for SNMP.

The integration will provide interopera-bility between TMN systems andCORBA systems, and preserve theinvestment in GDMO/ASN.1 informa-tion models. Proposals should address:

• Translation of GDMO to and fromIDL specifications. Algorithms forstatic translation is requested, wherestatic means that a GDMO to IDLcompiler is used to generate staticstubs/skeletons.

• Interaction translation. CMIP protocoldata units are dynamically translated toone or more requests or replies on IDLinterfaces.

Interaction translation is carried out by agateway. The positioning of the gatewayis depicted in Figure 7 and Figure 8. Thespecification translation is not shown inthe figures, it takes place at compile time,and the result is used to implement thegateway.

As regards creating a CORBA architec-ture inspired by TMN, the most relevantspecification is the Notification Service,which extends the CORBA capabilitiesof the CORBA event service to supportfiltering. A Notification Service RFP wasissued in January 1997, and adoption ofthe specification is expected by March1998. Event consumers can express inte-rest in events that are filtered by type andcontent, and thus receive only a specificsubset of all the events supplied to thenotification service. The service providesa decoupling of consumers and pro-ducers, and shall satisfy the scalabilitydemands (high volumes) of event-drivenapplications running within large net-works including telecommunicationmanagement applications. Functionalityrequirements include dynamic additionof user-defined event types by producers,quality of service with respect to eventdelivery (guaranteed, priorities, besteffort), federation of notification servers,etc. Also, there should be a specificationof event types and contents applicable toparticular vertical domains such as tele-com (ref. TMN “X.700 series”).

4.2 CORBA and ITU-T Intelli-gent Networks (IN)

IN allows centralised processing of ser-vice logic and service data separatedfrom the switching function in theswitches, as opposed to traditional ser-vice implementations where a switchhandles both the service processing andthe switching. IN does not require that allswitches are equipped with all services,and prevents heavy software upgrades inthe switches. IN only requires theswitches to support a service switchingpoint (SSP), which during call processing


is able to encounter an IN service trigger-ing condition, and call a service controlpoint (SCP) in order to process servicelogic and data. ITU and ETSI have speci-fied both the architecture (called the INarchitecture) and specific services (calledIN services) following this approach.This text covers IN capability set 1,which is restricted to narrow-band tele-phony services. IN objectives includerapid service creation, tailored services,new services which rely on centraliseddata, well-managed services and cost-effective services.

IN has been implemented in the networksof telecom operators over the last years,but has only partly met the objectives.Existing IN implementations often sufferfrom being proprietary solutions. SCPsare usually closed environments whichare inflexible with respect to integrationwith other systems. Service creationenvironments are special purpose and notbased on state of the art software de-velopment tools. Specialised manage-ment systems are needed. Implementa-tions are expensive.

The most realistic way of introducingCORBA into IN is to apply CORBA tothe parts of IN which are separated fromthe switches. ITU and ETSI have stan-dardised the communication between theSSP and the SCP, and the protocol iscalled INAP (Intelligent Network Appli-cation Protocol). INAP uses TransactionCapability Application Protocol (TCAP),which again uses the ISO Remote Opera-tion Service Element (ROSE) protocol.ROSE implements the Remote OperationService (ROS). INAP, TCAP and ROSEcommunication is carried by the signal-ling system No. 7 (SS7) network. A gate-way between INAP/ROS and IDL opera-tions would allow CORBA-based imple-mentations of SCP and other ‘central-ised’ IN entities including the ServiceData Point and Service Management Sys-tem. The prerequisite is that the networkelements have to support standard INAP/ROS, which is not always the case.

It is expected that OMG will approve anRFP on interoperability betweenCORBA and IN by December 1997. TheRFP will request an IN/CORBA gatewayfor interaction translation between INAP/ROSE messages and operations on IDLinterfaces. There is a debate about thebest protocol level for the gateway, i.e.whether there should be a ROSE toCORBA or INAP to CORBA gateway.The ROSE gateway would be very gene-

ral (because ROSE is used by severalapplication layer protocols includingINAP and CMIP) and more complex,and could suffer from performance short-comings. The most likely approach willbe an INAP/CORBA gateway.

IN services have stringent requirementsto performance, scalability and avail-ability. CORBA technology will have toprove that these requirements can be ful-filled.

4.3 Control and Managementof Audio/Video Streams

A specification for control and manage-ment of audio/video streams (hereaftercalled the AV streams specification) wasadopted by OMG in September 1997.The AV streams specification introducesa wide range of application uses, in-cluding:

• Conferencing, entertainment, bio-medical or security applications

• Distributed simulation or games

• High-bandwidth instrumentation inprocess or real-time control applica-tions

• Bulk transfer of data, e.g. medicalrecords, still images, software updates.

The specification covers topologies ofstreams, multiple flows, stream identifi-cation, stream set-up, modification andrelease, quality of service and relation-ship to network protocols. A streamrepresents continuous media transferbetween end-points. Stream topologiescovered are point-to-point and point-tomultipoint. Three types of transport aresupported by the framework, namelyconnection-oriented (like TCP), data-gram-oriented (like UDP) and unreliableconnection-oriented (like ATM AAL5).In principle, the specification allows astream to be supported by any transportprotocol including IP or ATM, hence theAV streams specification can be seen asan abstract framework residing on top ofthe transport. The AV streams specifica-tion has been influenced by the Telecom-munication Information NetworkingArchitecture Consortium (TINA-C)architecture, and the functionality issimilar to the TINA CommunicationSession Manager component.

5 Alternative Technologies

CORBA is not the only middleware thatsupport distributed objects. The two mostserious competitors are Microsoft’sDCOM, and JavaSoft’s Java RMI.


SS7 network

Gateway

SCP

SSP SSP

IntelligentPeripheral

CORBA domain

SS7 domain

INAP/ROS

IDL

Figure 9 IN-CORBA gateway. The gateway allows development of centralised servicelogic and data (residing in the SCP) based on CORBA technology

5.1 Microsoft DCOM

DCOM (Distributed Component ObjectModel) is Microsoft’s distributed objectmiddleware and the most serious com-petitor to CORBA. The first version ofDCOM was shipped as part of the Win-dows NT 4.0 operating system in mid-1996. DCOM is a distributed extensionof COM, which was introduced in 1993,as part of OLE (Object Linking andEmbedding).

DCOM has many of the same features asCORBA: An interface definition lan-guage (similar to OMG IDL), supportfor multiple implementation languages,static operation invocations, and dynamicinvocations (similar to CORBA dynamicinvocation interface, DII). Moreover,basic object services are available,notably naming, transactions and secu-rity. The object services are availableas separate products.

The biggest difference between CORBAand DCOM lies in the object model.CORBA uses a ‘classical’ object model,similar to what is found in most object-oriented programming languages.DCOM objects on the other hand do notsupport multiple inheritance on inter-faces, but instead provide reuse throughmore unusual mechanisms based on con-tainment and aggregation. DCOM alsosupports a component model, based onso-called AxtiveX controls. An Active Xcontrol is simply a DCOM object thatfollows certain rules in its communica-tion with other objects.

The heavy backing (i.e. Microsoft) andthe technical features of DCOM make ita serious alternative to CORBA. Themost important drawbacks are its com-plexity and the fact that it is only avail-able on Windows platforms.

5.2 Java RMI

Java RMI (Remote Method Invocation)is a standard component of the Java sys-tem (JDK 1.1), available in every Javainstallation. RMI enables (remote)method invocations across Java VirtualMachines. The RMI package can inmany ways be compared to an ORB asdescribed in section 2. It enables clientsto invoke methods on remote objects in away that is similar to invoking methodson local objects.

Java RMI shares the basic principles withCORBA and DCOM. Clients interactwith servers via interfaces. A local object(RMI stub) acts as a local proxy for theremote object. As in CORBA, the stubsare automatically created from interfacespecifications by a stub compiler. More-over, clients locate and bind to serverobjects via a naming service (called‘repository’).

RMI interfaces are, however, not speci-fied using an external language (likeCORBA IDL or DCOM IDL). Instead,native Java notation is used as the inter-face specification language.

Compared to CORBA and DCOM, RMIadds several innovations, including theability to pass object values (state), notonly object references, as parameters ofremote invocations, dynamic down-loading of object implementation code,and distributed garbage collection (al-though currently not bullet-proof).

On the negative side, RMI has someserious disadvantages. Firstly, RMI sup-ports only Java-to-Java communication.It lacks a language neutral interopera-bility protocol. Moreover, the perfor-mance of RMI compared to Java ORBsis very poor. Also, RMI lacks protocollevel support for security contexts andtransaction contexts, lacks persistentobject references, has a very primitivenaming service, no support for dynamicinvocations (analogous to CORBA DII),and lacks a rich set of object services.

To conclude, Java RMI is easy to use forJava developers. Due to the shortcomingsmentioned above, it is questionable, how-ever, whether it is a suitable infrastruc-ture for large, more complex systems.

6 CORBA products

This section presents an overview ofCORBA products offered and their statusby the end of 1997.

6.1 ORBs and Object Services

CORBA 2.0 compatible ORBs with IDLcompilers are the basic CORBA product,and are available from several vendors.The most popular CORBA products in1996 according to an IDC market re-search [6] are: Iona’s Orbix (30 %market share), TCSI’s Object ServicesPackage ORB (21 %), BEA’s Object-Broker (16 %) and Visigenic’s Visi-

broker (11 %). Other important ORBsare: NEO and Java IDL from Sun Micro-systems and IBM’s Component Broker.The leading ORB implementations arerobust, because they have undergoneseveral product cycles. Important pro-gramming language mappings andmost operating systems are supported.

By the end of 1997 important CORBAservices have been implemented, in-cluding naming, event, concurrency,transaction, trader and security. Namingand event service implementations havematured, while the transaction, trader andsecurity implementations are first versionimplementations. Note though that trans-action and security service implementa-tions are mostly based on existing offer-ings (from DCE environments, etc.),hence they are fairly mature. Implemen-tations of other services are in progress.

CORBA has emerged as a distributedobject infrastructure for the Internet.During 1997 CORBA became Internet-ready in the sense that Java applets caninteract with CORBA servers over theInternet using IIOP including lightweightInternet security support. Products includeIDL to Java compiler, ORB implementa-tion in Java, and IIOP over the SecureSocket Layer protocol, the latter providingauthentication and encryption. Note thatCORBA applications on the server sidecan also be programmed in Java. Furtherintegration of CORBA and Java is evolv-ing rapidly, see section 3.2.

The first versions of CORBA productstargeted for large-scale applications wereavailable by the end of 1997. This meansprovision of a middle-tier (see section3.1) application platform that integratesthe features of CORBA with scalabletransaction management and the abilityto access existing applications, databasesand non-CORBA middleware. Theobjective is to provide a CORBA-basedplatform for large systems and mission-critical systems. System developmentand system management tools are alsopart of the offerings.

6.2 Integration with otherproducts

Integration of CORBA with databasemanagement systems (DBMSs) in orderto bring persistence to CORBA objects issupported, see section 3.3. Databaseadapters support adaptation betweenCORBA objects and database objects.


Adapters for ObjectStore, Versant andDB2 are available, and more adapterswill soon follow. Database adapterframeworks that can be used to createnew database adapters to DBMSs arealso available.

TP monitors already exist which supportscalable transaction management basedon other message formats and transac-tions services than CORBA. The currenttrend is to integrate popular and well-proven TP monitors (Encina, Tuxedo,etc.) with CORBA, and the first integra-tions were available by the end of 1997.See section 3.4 for more informationabout transactions and TP monitors.

Interworking with non-CORBA middle-ware is being developed. OMG com-pliant Microsoft COM-CORBA gate-ways are available which enable COM-based applications to access CORBAobjects in a transparent way. Proprietarygateways to IBM CICS and messageoriented middleware (MOM) are alsoavailable.

The first environments for building,deploying and managing CORBA appli-cations were available by the end of1997. Vendor specific graphical develop-ment tools for CORBA are available.Also, popular development tools such asPowerBuilder, Rational Rose and IBMVisual Age are integrated with CORBA.System management tools are deliveredby CORBA vendors implementing theCORBA system management facilityspecification, and also supporting aSimple Network Management Protocol(SNMP) interface in order to manageCORBA applications from popularmanagement systems such as HPOpenView, Tivoli and Unicenter.

7 Future directions

OMG has planned a new version of theCORBA specification. The new version,which is called CORBA 3.0 and is duefirst quarter of 1998, will include updatesand additions already made to theCORBA 2.0 specification, and severalnew and interesting enhancements thatare on their way.

One of the new features that are expectedto be included in CORBA 3.0 is theCORBA Messaging Service, which willprovide the ORB with Message OrientedMiddleware (MOM) functions. MOM isa key technology for a class of client/ser-

ver applications. It allows general-pur-pose messages to be exchanged in a sys-tem using message queues. When usingMOM, a client is allowed to make asyn-chronous, non-blocking requests. Thismeans that the client does not have to bemultithreaded, and clients will conse-quently be simpler and easier to main-tain. MOM will allow clients and serversto run at different times, support nomadicclients and allow servers to determinewhen to retrieve messages off theirqueues. MOM will allow a loosercoupling between applications thancurrently supported by ORBs which areoften preferred for inter-applicationcommunication. On the downside, MOMdoes not support distributed transactions,because a transaction is broken into sepa-rate units of work.

OMG is currently extending the CORBAobject model to allow objects withmultiple interfaces, and to allow objectsto be passed by value in operations.Another important ongoing initiative is todevelop a component model for CORBAbased on the Java component model,Java Beans. If the work is successful, itwill be possible to view CORBA objectsas Beans. This will in turn make it pos-sible to manipulate general CORBAobjects in graphical development tools(‘beanboxes’ in Java parlance), therebyreducing the complexity of creatingCORBA applications.

Another enhancement that is expected tobe included in CORBA 3.0 is server-sideportable frameworks that will makeCORBA servers portable from one ORBto another.

Within the CORBAfacilities componentof the Object Management Architecture,much attention is given to mobile agents.A mobile agent is a CORBA object thatcan move its code and state across anIIOP network.

Within the domain areas, OMG membersare currently specifying domain frame-works for several domains, includingElectronic Commerce and Telecom.There is also work going on to build ageneric business framework, called theBusiness Object Facility (BOF). The ideabehind the BOF is to make it much easierto develop CORBA applications.

Readers who are interested in a moredetailed account of the future develop-ment of CORBA, are referred to [3], onwhich the above outline is based.

8 References

1 Coulouris, G, Dollimore, J, Kind-berg, T. Distributed Systems : Con-cepts and Design. Wokingham,Addison-Wesley, 1994. ISBN 0-201-62433-8.

2 Baker, S. CORBA DistributedObjects. Harlow, Addison-Wesley,Longman, 1997. ISBN 0-201-92475-7.

3 Orfali, R, Harkey, D, Edwards, J.Instant CORBA. New York, Wiley,1997. ISBN 0-471-18333-4.

4 ACTS project AC048 (ReTINA).BVPN Service Demonstrator Specifi-cation. S.L., 1997. (AC048/TLN/WP5/DS/L/011 (D5.03).)

5 Mowbray, T J, Zahavi, R. The Essen-tial CORBA : Systems IntegrationUsing Distributed Objects. NewYork, Wiley, 1995. ISBN 0-471-10611-9.

6 Garone, S. Middleware : 1997Worldwide Markets and Trends.International Data Corporation(IDC), 1997. (IDC report.)

9 Bibliography

Baker, S, Cahill, V, Nixon, P. BridgingBoundaries: CORBA in perspective.IEEE Internet Computing, 1 (5), 1997.http://computer.org/internet/.

ITU-T Recommendation M.3010. Prin-ciples for a Telecommunications Man-agement Network. Geneva, 1996.

ITU-T Recommendation Q.1201. Prin-ciples of Intelligent Network Architec-ture. Geneva, 1993.

OMG. Control and Management ofAudio/Video Streams. OMG RFP Sub-mission. Revised submission. (OMGDocument: telecom/97-05-07.)

OMG. Notification Service Request ForProposal, final version, 11.12.96. 1996.(OMG Document: telecom/97-01-03.)

OMG. The Common Object Request Bro-ker : Architecture and Specification,revision 2.0. 1995.


OMG. Topology Service Request ForProposal, draft 2, 16.01.97. (OMGDocument: telecom/97-01-02.)

Schmidt, D. C. Distributed Object Com-puting. IEEE Communications Magazine,35 (2), 1997, 42-44.

Vinoski, S. Distributed Object Compu-ting With CORBA. C++ Report, 5 (6),1993, 32-38.

Vinoski, S. CORBA : Integrating DiverseApplications within Distributed Hetero-geneous Environments. IEEE Communi-cations Magazine, 35 (2), 1997, 46-55.

ZhongHua, Y, Duddy, K. CORBA : Aplatform for Distributed Object Compu-ting. http://www.infosys.tuwien.ac.at/Research/Corba/archive/intro/OSR.ps.gz.


Ole Jørgen Anfindsen is Research Scientist atTelenor R&D and an associate professor in theSoftware Engineering and Database ResarchGroup, University of Oslo. He has been involvedwith database technology since 1982, and hisresearch interests include databases, transactionmodels, object orientation, and CORBA. He is theTechnical Representative for Telenor to theObject Database Management Group.


Håkon Solbakken is Research Scientist at Tele-nor R&D, Kjeller, where he has been employedsince 1986. He has been working with softwarespecification and development in the field of net-work management and services. His interestsinclude software development methods and tools,distributed object technology, and user interfacedesign and implementation.


Eirik Dahle is Research Scientist at Telenor R&D,Kjeller, where he has been working since 1988.He has worked with software specification anddevelopment in the field of network managementand services. His interests include middleware,distributed object technology and databasemanagement systems.


Tom Handegård is Research Scientist at TelenorR&D, Kjeller, where he has been employed since1990. He has been working with Intelligent Net-works, B-ISDN signalling, and the TINA architec-ture. Currently, his main interests are withinvarious aspects of distributed object-orientedsystems, including CORBA and Java technology.


Kjell Sæten is Research Scientist at TelenorR&D. After completing his masters thesis at Stan-ford University he spent several years developingsoftware for seismic systems at Geco-Pracla. Hejoined Telenor R&D in 1997. His current interestsare within distributed systems based on Java andCORBA technology.


This article discusses design of aCORBA/IN Interworking function(IWF). A static IN/CORBA IWF isproposed, residing on the INAP/TCAPlayer, between Service Switch Func-tion (SSF) and the Service ControlFunction (SCF). It is argued that theIWF should facilitate a smooth, realtime interaction between the SS7domain and the CORBA domain. Inparticular, the IWF should addressharmonisation of the asynchronous,message oriented communicationparadigm of the SS7 domain and theblocking, connection oriented para-digm of the CORBA domain. The IWFshould also deal with the vital, low-level, real time, concurrent, event-based, queue-oriented aspects of theinteraction and provide the IN servicedeveloper with high-level CORBAinterfaces. The CORBA Event Serviceor the coming Message Service, en-hanced with real-time and reliabilityrequirements necessary for IN, issuggested for the interaction betweenthe CORBA domain and the IN/CORBA IWF.

Introduction

Rapid introduction of new services and ahigh degree of customisation are a neces-sity in the new, competitive environmentwhere the telecom operators are con-fronted with a fast changing environ-ment, deregulation and liberalisation. Asthe data and the telecom world converge,there is an increasing orientation in thetelecom society towards an open soft-ware creation- and standardised com-puting-environment. There seems to bean increasing belief that middlewaretechnology like CORBA can successfullybe applied as an infrastructure in value-added telecom networks to meet the newchallenges. CORBA technology has al-ready been used in a number of non-realtime application areas in the telecomworld. This article addresses issues re-lated to introduction of CORBA techno-logy in the real time Intelligent Networkdomain. The design and implementationof an IN/CORBA Interworking Function(IWF) is outlined. An IN/CORBA IWFcan be seen as a first migratory steptowards TINA like networks and as aninterworking unit between TINA likenetworks and traditional IN aware tele-com networks. An IN/CORBA IWF canalso be seen as an opening of the telecomvendor specific environment to achieverapid creation, customisation and deploy-

ment of new services. Contrary to thetelecom vendor controlled regime, anIN/CORBA IWF will facilitate thirdparty delivery and competition of servicecreation environments and service com-ponents, both on software and hardwarelevel.

The plan for this article is first to providea short introduction of ITU standardisa-tion of IN, followed by a discussion ofwhat parts of IN are best suited for earlyintroduction of CORBA. Design choicesand design of an IN/CORBA IWF areoutlined, and development, deploymentand execution of services are presentedin the context of an IN/CORBA IWF.The project is a co-operation betweenTelenor and the Irish company IONATechnologies, which so far is the mostsuccessful CORBA technology manu-facturer. It is likely that other partnerswill be added later. The short term goal isto investigate the issues related to designand implementation of an industrialstrength CORBA/IN IWF to produce ananswer to a future OMG Request ForProposal on IN and CORBA interwork-ing. The author is enjoying a stay withIONA Technologies.

Overview of IntelligentNetworks

The basic idea behind the ITU standard-isation of IN is to ease the introduction ofnew services by centralising the servicelogic in a few dedicated service nodes.The aim is to enable services to be addedwithout costly upgrading of the switchinghardware and software infrastructure.The service switching functions are sepa-rated from the service control software.The switch interrupts its processing atcertain pre-determined points to query aremote server for service specific instruc-tions. The switch can get several inter-mediate instructions before the final one,containing the routing address. Thus theservice logic is removed from the switchand is relocated to a separate the serviceserver. The service logic program can beviewed as a distributed application whichpartly runs on the switches and partlyruns on the service server. Hence theswitch does not have to be pre-loadedwith service specific information.

Service independence is another keynotion in IN, which addresses reusability

119

CORBA and Intelligent Networks (IN)H E L G E A R M A N D B E R G

Telektronikk 1.1998

Service Feature 1

Service Feature 2

Service Feature 1

Service Feature N

Service Plane

Service A Service B

BCP

Global Functional Plane

Global ServiceLogic

Distributed Functional Plane

Distributed ServiceLogic

Physical Plane

SIB1

SIB3

SIB3

SDF

SSF SRF

SMFSSFSCF

FunctionalEntities

SDP

SSP

SCP SSP

IP

PhysicalEntities

Figure 1 Use of the IN Conceptual Model to depict CS-1

of components for building services. TheIN Conceptual Model, INCM, is amodelling tool for describing the capa-bilities and characteristics of the architec-ture. ITU Standardisation of IN is seen asa stepwise evolution in what is called aCapability Set (CS). Typical CS-1 ser-vices are: number translation services,alternate billing services and screeningservices. Typical CS-2 enhancements arelikely to be; end user interaction with ser-vice control outside the context of a call,mid-call interaction, mobility, IN inter-working, IN management based on ITU-TMN management standards.

INCM consists of four planes whichaddress different aspects of IN. The twoupper planes focus upon the creation andperception services. The two lowerplanes address the IN functional andphysical architectures. The end-user viewof a service is defined in the ServicePlane. Each service is compounded byone or more service feature(s) which aregeneric, reusable components. The INservice developer perspective is found inthe Global Function Plane (GFP). The INservice developer builds an end-user ser-vice by combining Service IndependentBuilding-blocks (SIBs) in the IN ServiceCreation Environment Function (c.f.Figure 2). Distribution issues are com-pletely abstracted away from the GlobalFunction Plane. The GFP views the tele-

com network as a virtual computer withservice programs having virtual access toall computer programs and ignoringothers. The Distributed Function Planedefines a distribution view of the IN interms of units of network functionalitycalled functional entities. The ServiceControl function (SCF) hosts the servicelogic programs. The Service Data Func-tion (SDF) hosts service related data. TheService Switching Function (SSF) en-ables the triggering of services fromthe switches. The Service ManagementFunction (SMF) supports the IN servicemanagement. The Specialised ResourceFunction (SRF) provides control andaccess to resources used in service pro-vision in the intelligent network. TheIntelligent Network Application Protocol(INAP) defines the interface protocol forIN control messages between the IN enti-ties. The Physical Plane (PP) defines thereal deployment of an IN. There areoptional mappings from the DistributedFunction Plane to the Physical Plane, butit is not possible to split one single func-tional entity among different physicalentities.

An IN can be considered as a layer overany transport network (cf. Figure 2). TheCall Control Agent Function (CCAF) isthe initial access point to a network fromthe user terminal function. It passes callset-up and service request messages to

the Call Control Function (CCF) for thebasic call processing. To perform thebasic call processing, the CCF maintainsa Basic Call State Model (BCSM) bothfor calling and the called party for eachincoming call. The BCSM is a finite statemachine representing a set of differentstates of a call, like headset lifted off,number dialled, etc. The BSCM identi-fies logical points in the basic call pro-cessing at which IN service logic, locatedin the Service Control Function (SCF), ispermitted to interact with the BCSM. TheSSF provides a set of functions requiredfor interaction between the CCF and theSCF. The IN physical entities communi-cate via the Intelligent Network Applica-tion Protocol (INAP), which relies on theSignalling System No. 7.

What functional entities toCORBAise?

There seems to be consensus in theIN/CORBA research society [2, 4, 5, 6,7] that the SSF/CCF will be the last enti-ties to be CORBAised (or being replacedby TINA aware switches), because thebulk of the organisational and technicalinvestment resides here. Entities com-prising the IN layer and the ServiceCreation and Management layer (cf.Figure 2) are considered to be better can-didates for early CORBAtion. Complete


SSF

CCF CCF

SSF

CCF

SCEF SMF

SDF SCF SRF

CCAFBCSM BCSM BCSM

CCAF

7 8 9

4 5 6

1 2 3

*0 #

7 8 9

4 5 6

1 2 3

*0 #

"Service Creation andManagement Layer"

"IN Layer"

"Network Layer"

Service ExcutionSSF Service Switching FunctionSCF Service Control FunctionSDF Service Data FunctionSRF Service Resource Function

Call HandingCCAF Call Control Agent FunctionCCF Call Control FunctionBCSM Basic Call State Model

Management and Service DeploymentSCEF Service Creation Environment FunctionSMF Service Management Function

Call set up and invocation of INManagement and deployment of services

Figure 2 The “Service Creation and Management layer”, the “IN layer” and the “Network layer” depicted in the IN CS-1Distributed Function Plane. Services are created with the SCEF, deployed and managed with the SMF and executed in the

“IN layer” controlling the “Network layer”

or partwise CORBAtion of the IN-layernecessitates an IN/CORBA IWF (cf.Figure 3).

CORBA objects will replace the IN enti-ties. IN control messages between theSSF and the IN layer are converted bythe IWF to suitable CORBA object in-vocation(s). In the opposite directionCORBA replies, and method invocationsare converted to IN control messagessent to the SSF/CCF. This article focuseson CORBAtion of the IN-layer, but anobvious step to make, given a CORBA-ised IN layer, is also to CORBAise theService Creation Environment andManagement of services deployed in aCORBA environment.

The IN/CORBA IWF;design choices

In this subsection different designchoices of an IN/CORBA IWF are dis-cussed.

• IWF protocol layer: In what protocollayer should an IWF reside? See nextsubsection.

• Static or dynamic approach: A staticapproach means using the CORBAStatic Invocation Interface and staticclient stubs for invocation of CORBAobjects. Such an approach implies thatoperations supported by the gatewaymust be known at compile time,though some configuration flexibilitycan be implemented. The dynamicapproach refers to use of the CORBADynamic Skeleton Interface and theDynamic Invocation Interface insteadof pre-compiled client stubs. Thisapproach gives more flexibility con-cerning what has to be known at com-pile time. The object invocations andprotocol translation are constructedrun-time.

• Functionality located in the IWF:Should the IWF just have pure proto-col translation functionality or would itbe beneficial to locate more function-ality in the IWF?

INAP protocol layers

There are alternatives regarding on whatprotocol layer an IN/CORBA IWFshould reside (cf. Figure 4).

INAP (Intelligent Network ApplicationProtocol) uses the transaction capabilitiesof TCAP (Transaction Capability Appli-

cation Protocol). TCAP is in turn basedon ROS (Remote Operation Services)[10]. EURESCOM [2] proposes twovariants of a simple, static IWF residingon the INAP layer. These approaches areclaimed to be easy to implement. How-ever, later work by EURESCOM pro-poses the more general and complexROS gateway [4]. The AT&T reply [5,7]to the OMG Request For Information“Intelligent Networking using CORBA”[14] suggests a dynamic gateway at theROS layer due to the widespread use ofROS in the telecom world. Also, a gate-way in the SCCP layer has been pro-posed, because the layer above the SSCPis claimed to be vendor specific. Thisapproach is not investigated in our pro-ject.

The discussion on the choice of protocollayer and static or dynamic gateway willbe done in parallel because, in our opin-ion there is a close relationbetween the alternatives. Fora gateway on the ROS layera dynamic approach is an ob-vious choice, because thisgateway will have applica-tion areas beyond the INcase. A static ROS gatewayhas less “value” than a staticINAP/TCAP gateway,because the INAP and TCAPlayer have to be rebuild. Thevalue of a dynamic approachfor an INAP/TCAP gatewayis less obvious, because thereare many predeterminedaspects due the close rela-tionship between the SSFand the SCF. Therefore, we

concentrate our discussion on either adynamic gateway on the ROS layer or astatic gateway / “Interworking Function”on the INAP/TCAP layer. The use of theterm Interworking Function instead ofthe term gateway will be motivatedbelow.

Protocol layer and static ordynamic approach?

The Remote Operations Service Element(ROSE) protocol is an implementation ofthe Remote Operation Service (ROS)[10]. The ROS model provides a numberof constructs to define the interactionbetween distributed objects using theinformation object class construct of theAbstract Syntax Notation One (ASN.1).The concepts of ROS and CORBA aremostly complementary. ROS is a verygeneral communication paradigm based


SORBASMF

7 8 9

4 5 6

1 2 3

*0 #

CORBA domain

CORBA basedSCP, SDP

ORB B

IWFORB A

IIOP

IP

STP STP SCP

SLP

DB

SSF/CCF

SSF/CCF

7 8 9

4 5 6

1 2 3

*0 #

7 8 9

4 5 6

1 2 3

*0 #

SubscriberSubscriber

Subscriber

SS7 domain

The IN/CORBAgateway

Figure 3 The IN/CORBA IWF and CORBAtion of the IN-layer

Figure 4 INAP protocol stack

INAP

ROS

TCAP (/ROS) Users

TransactionSublayer

TCAP

SCCP

MTP 3/2/1

INAP layer

ROS layer

SCCP layer(SS7)Transport

on a simple request/reply model. Unlikea traditional client-server model, whichdefines the operation which the clientmay invoke on the server, the ROSmodel simultaneously defines both theclient and the server aspects of a ROSobject. In CORBA IDL the focus is onthe server aspects of an object. [7] pro-vides a “specification translation” be-tween ROS and CORBA. To ease thistranslation, use of the TINA ODL basedconstructs ‘required and supported inter-faces’ is suggested. The TINA ODL con-structs ‘required interface’ correspond tothe CORBA IDL interface for an object.The TINA ODL construct ‘requiredinterface’ means an interface that anobject is dependent on as a client. Thisconstruct is unavailable in CORBA at themoment. The INAP operations defined inCapability Set 1 [12] utilise the expres-sive power of ROS to a limited extent.A survey of the CS-1 specified INAPoperations revealed that only one of 55operations uses the “required interface”of ROS. This indicates an “overhead” ofimplementing the generic ROS gatewayfor the IN case. Due to the above reasonsit will be experimented with a staticINAP/TCAP Interworking Function.

A thick or thin IWF?

What functionality should reside in theIWF is a major design choice. In order to

get a better basis for this design choice,the interaction between the SSF and SCF,as defined in [11,12], is examined.

When a call/attempt is initiated by an enduser and processed at an exchange, aninstance of a BCSM is created (cf. Figure5). As the BCSM proceeds, it encountersthe detection points (DPs). If a DP isarmed as a trigger DP (TDP), an instanceof an SSF-Finite State Machine (SSF-FSM) is created. The SSF-FSM interactswith the SCF in the course of providingIN service features to users. It providesthe SCF with an observable view ofSSF/CCF call/connection processingactivities, and provides the SCF withaccess to SSF/CCF capabilities andresources. It also detects IN call/connec-tion processing events that should bereported to active IN Service Logic Pro-gram Instances (SLPIs), and managesSSF resources required to support IN ser-vice logic instances.

An example of an event that changes thestate in the SSF-FSM is the firing of anarmed TDP of type Request. This willchange the state of the SSF-FSM from“Idle” to “Waiting for Instructions” ande.g. the INAP operation InitialDP will besent to the SCF. The SSF-FSM in itspresent situation is awaiting furtherinstructions from the SCF. At this stagea control relationship is established be-

tween the SSF and the SCF. A timer isstarted in the SSF in order to avoidexcessive call suspension time for thisspecific call. The SSME maintains thedialogues with the SCF on behalf of allinstances of the SSF-FSM. The Func-tional Entity Manager (FEAM) providesthe low level interfaces for establishingand maintaining the interfaces to theSCF, and passing and queuing messagesto the SSME and the SCME. When theInitialDP INAP operation is received bythe SCF, an instance of an SCF Call StateModel (SCF-FSM) is created, and therelevant SLP is invoked. Multiple re-quests (INAP operations) may be exe-cuted concurrently and asynchronouslyby the SCF. This motivates the need for asingle entity that performs the tasks ofcreation, invocation and maintenance ofthe SCF-FSM objects. This entity iscalled the SCF Management Entity(SCME). In addition to the above tasks,the SCME maintains the dialogues withthe SSF on behalf of all instances of theSCF-FSMs through the FEAM.

We summarise the characteristics for theinteraction between SSF and SCF: eventbased, non-blocking, concurrent andqueue-oriented exchanges of INAP ope-rations, and an infrastructure consistingof managers and Finite State Machinesthat prevent the SLP dealing with suchissues.


CCF Connection Control FunctionBCSM Basic Call State ModelTDP Trigger Detection PointSSF Service Switching FunctionSCF Service Control FunctionSSF-FSM Service Switch Function - Finite State Machine

SCF-FSM Service Control Function - Finite State MachineFEAM Functional Entity Access ManagerSSME SSF Management EntitySCMF SCF Management EntitySLPI Service Logic Program Instance

SSF

States PICs)

CCF

TDP

Analyze_Info

TDPTrigger table

Trigger 1 0

Trigger 2 X

Trigger 3 0

CallProcessingSuspended

CallProcessingResumed

Activetrigger

1

8

BCSM

SSME

Waiting forInstructions

Waiting - UserInteraction

Monitoring

Idle

SSF - FSM

SCF

SCME

Preparing SSFInstructions

Routing toresource

User Interaction

Idle

SSF - FSM

Exceptionto SSF

SLPI

ServiceExecutionEnvironment

FEAM FEAMINAP

Figure 5 Relationship between the CCF/SSF and the SCF

Significant traits of CORBA object in-vocations are synchronous or deferredsynchronous, blocking and connection-oriented. The paradigm differencesbetween the CORBA and the SS7/INshould preferably be harmonised by theIN/CORBA IFW. Useful tools forachieving this seems to be CORBAServices, like the Event Service or thecoming Messaging Service. These ser-vices facilitate asynchronous, messagebased CORBA object interactions in ade-coupled manner, like the interactingentities in the SS7 domain. Implementa-tions of the above mentioned CORBAServices with the required reliability andreal-time characteristics for the IN casecan serve as a means for harmonisationbetween the domains.

The Event Service is intended as anoptional extension to an ORB to allowclients to communicate with applicationobjects using events. Suppliers generateevents, and consumers receive them. TheEvent Service defines a de-coupled com-munication style. It defines an indirectcommunication style using event chan-nels, where both push and pull eventdelivery are supported [15]. The comingMessaging Service is likely to supportasynchronous invocation, contain qualityof service features such as lifetime of arequest, reliability, server side queuemanagement, load balancing and routing.EURESCOM promotes in [4] an exten-sion of the Event Service to address real

time and the fault tolerant requirementsof IN. Use of such an Event Service isclaimed to facilitate a flexible, exten-sible, “component plug-in” orientedarchitecture for building services.

As has been motivated above, a thin IWFwhich only covers syntactic protocoltranslation between the SS7 domain andthe CORBA domain may push too muchresponsibility on the CORBA serverobjects in order to deal with queue man-agement, concurrency, real time, and theevent based interaction with the SSF.Therefore, a thicker IWF is investigatedin the project, and the term InterworkingFunction is preferred to gateway, becausein our approach we want to put morethan protocol translation functionality tothe IWF.

The IN/CORBA IWF

As explained in the previous sections thedesign of a thick Interworking Functionon the TCAP/INAP layer is proposed. Inthe following text the term End User Ser-vice (EUS) refers to an End User Serviceimplemented in the CORBA domain.The EUS corresponds to the SLPI in theIN domain.

The following components to the SCF’sFEAM and SCME are necessary in theCORBA/IN IWF:

• IWF-Functional Entity Access Man-ager (IWF-FEAM)

- Provide access to other non-CORBAFunctional Entities (SRF, SCF,SDF)

- Translate incoming/outgoing INAPoperations to/from CORBA typesusing the IDL-ASN.1 engine

- Provide queue-management of in-coming and out-going INAP opera-tions

• IWF-Management Entity (IWF-ME)

- Create, maintain and delete theIWF-FSM for each call that needsprocessing of the IN-layer

- Maintain the dialogues with the SSFon behalf of all SCF-FSMs troughthe IWF-FEAM

• The IWF-Finite State Machine

- Interact both with the SS7 domainthrough the IWF-ME and theCORBA domain through an EventService

- Resolve the CORBA reference tothe EUS using the Naming Service

- Start an EUS instance asynchro-nously with an Event Service

- Keep the necessary CORBA refe-rences

- Provide a set of IDL operationswhich correspond to INAP opera-


Charge

IWF-FEAM IWF-Functional Entity ManagerIWF ME IWF Management EntityIWF-FSM IWF Finite State MachineEUS End User ApplicationORB Object Request Broker

IWF-FEAM

CORBA/IN IWF

ASN.1 -IDL

engineIWF-ME

IWF-FSM

SSFINAP

ORB

EventService

NamingService

UserInteraction

Reusable CORBAobjects

Service SpecificCORBA objects

EUS

Figure 6 The IN/CORBA Interworking Architecture

tions of interest to the EUS toinvoke (see example in the textbelow)

- “Listen to” invocation from the EUSand the SSF and take necessary ac-tions

- Maintain timers to supervise theEUS and the interaction with theSSF.

The translated INAP operation will bedirected to the correct instance of theIWF-FSM by the IWF-ME based on theCALL-ID if there exists an IWF-FSM forthis call. Otherwise, a new IWF-FSMinstance is created. The IWF-FSM willresolve CORBA object references basedon the parameters of the translated INAPoperation using the Naming Service. TheIWF-FSM will contain the fine-granulartimer semantics that are characteristic forSSF/SCF interactions. The EUS will beinvoked asynchronously by an Eventbased Service, initiated from the IWF-FSM. The IWF-FSM will be able tolisten to asynchronous events or requestsfrom the EUS and the SSF and take ac-tions based on them. The IWF-FSM willcontain IDL interfaces which representthe INAP operations which are of interestto an EUS to invoke. A typical exampleis the INAP operation PromptAndcollect-UserInformation, which is used to collectmore information from an end user, suchas a pin code. If this operation is invokedon the IDL interface of the IWF-FSM,then the state is changed to “User Inter-action” and the operation is sent to theSRF (cf. Figure 2). The EUS does notneed to stop its executions as this hap-pens. A response from the SRF will bereported back to the EUS and through theIWF-FSM asynchronously. Error situa-tion in the EUS will be reported back tothe relevant IWF-FSM through the Event

based Service, as well. Errors and timeouts in the SSF are received by the rele-vant IWF and necessary actions, like cle-aring the resources in the CORBAdomain, will be performed.

Detailed requirements to the IN/CORBAIWF can be found in [2, 4] and else-where. Some additional design require-ments are summarised below:

• The IWF should be independent of theimplementation of EUS. There shouldbe no need for recompiling the IWFwhen new services are introduced.

• An open, precise interface is requiredbetween the IWF and the CORBAdomain in order to facilitate third partydelivery and competition of ServiceCreation Tools. Re-implementation ofCORBA objects with SIB like func-tionality can be considered as sug-gested in Figure 6. Another possibilityis to implement TINA inspired objectsinteracting with IN. This has been ex-amined in [6].

• The IWF should be modular withregard to different INAP protocolstacks. The modification on the IWF incase of adjusting the IWF to differentvendor protocol INAP stacks should beminimal, and if possible, such adjust-ments should be configurable withoutrecompiling.

References

1 Magedanz, T, Popescu-Zeletin, R.Intelligent Networks : Basic Techno-logy, Standards and Evolution.London, Thomson Computer Press,1996. ISBN 1-85032-293-7.

2 EURESCOM. CORBA as an En-abling Factor for Migration from IN


Helge Armand Berg has been working as Re-search Scientist at Telenor R&D since 1991 inthe areas of TMN, TINA, CORBA and distributeddatabase systems. Since June 1997 he has beenworking on IN and CORBA in a co-ordinated pro-ject between Telenor and IONA Technologies,Dublin. He has a particular professional interest inthe CORBA technology.


to TINA. (A EURESCOM-P508 Per-spective (Final), Annex 5.)

3 ALCATEL. Intelligent Networkingusing CORBA. 1997. (ALCATEL’sResponse to the OMG Request forInformation. April 1997, ReferenceULT/C/97/0121.)

4 EURESCOM. Introduction of Distri-buted Computing Middleware inIntelligent Networks. (A EURES-COM-P508 perspective, OMG Doc.Number orbos/97-09-11.)

5 AT&T. Design of a ROS : CORBAGateway for Inter-operable Intelli-gent Networking Applications. 1997.(AT&T Response to the OMGRequest for Information, April 1997,OMG – telecom/97-04-01.)

6 Herzog, U, Magedanz, T. From INtoward TINA : Potential MigrationSteps. In: International conferenceon intelligence in services and net-works : technology for cooperativecompetition, IS&N, Cernobbio. Ber-lin, Springer, 1997.

7 Mazumdar, S, Mitra, N. ROS-to-CORBA Mappings: First Step to-wards Intelligent Networking usingCORBA. In: International confe-rence on intelligence in services andnetworks : technology for coopera-tive competition, IS&N, Cernobbio.Berlin, Springer, 1997.

10 ITU-T. Information technology –Remote Operations: Concepts ,model and notation. ITU-T Rec.X.880, 1994. ISO/IEC 13712-1:1995.

11 ITU-T. Distributed functional planefor intelligent network CS-1. Geneva,ITU, 1995. (ITU-T Rec. Q.1214.)

12 ITU-T. Interface Recommendationfor intelligent network CS-1. Geneva,ITU, 1995. (ITU-T Rec. Q.1218.)

13 ETSI. Core INAP. 1997. (ETSIDocument ETS 300 374.)

14 OMG. RFI on Issues concerningIntelligent Networking with CORBA.(Nilo Mitra, AT&T, OMG - tele-com/96-12-02.)

15 OMG. CORBAservices : Overview.(Formal/97-02-06: CORBA servicesspecification.)

Introduction

The architecture presented here has beendeveloped as part of the Jada project atTelenor R&D. The original objective ofthe project was to evaluate the use ofJava/Internet technology for Telecommu-nication Management Network (TMN).The Jada architecture and tools formaking this kind of application haveuncovered additional results from theproject.

This presentation of Jada has its focus onarchitecture. For details on the projectand on the prototype GDMO/Java toolsdeveloped as part of the project, pleaseconsult [2].

The following dimensions of architecturewill be covered:

• Distributed Object Architecture • Application Architecture• Architecture of Development Tools.

Jada ArchitectureOverview

A Jada application is organised as a setof interacting server and client systems.Each server system is organised as anaming tree of Java objects, while clientsare Java applets. This is shown in Figure1. Client-server and server-server inter-action is provided by means of JavaRemote Method Invocation (RMI), soserver objects are characterised byremote interfaces. Systems are eitherassociated with and used by a client userapplication in terms of an applet, or areused by each other; in both cases bymeans of Java remote method invocationbetween objects. Systems may either beindependent systems or just componentsof a larger system.

The ideas behind the architecture are:

• Operator/user applications can bemade readily available through wide-spread browser technology (JavaApplets).

• The Java technology, including distri-bution by means of RMI, can be usedfor real application development, andnot just for making fancy applets aspart of web-pages.

These elements of the architecture arenot unique for Jada – but is shared bymost Java applications involving RMIand applets.

However, Jada applies the object modelof GDMO [5] and maps this into Javaobject models. The GDMO approachmeans that each object is characterisedby a set of packages, each having attri-butes and actions. Attributes are speci-fied to have values according to ASN.1types, and may be specified as GET orGET-REPLACE operations. Actions arespecified with parameters and results interms of ASN.1 types. Clients andobjects in other servers may set and getattributes and request objects to performactions. In addition, objects may emitnotifications.

Objects are named within a system bymeans of name bindings. A system has asits root an object of class system. Eachobject named by another superior objecthas an attribute that is used for naming.

The Jada development environment con-tains, in addition to a pure Java develop-ment environment, a set of GDMO de-velopment tools that help in producingJava representations of GDMO specifiedobject models.

As shown in Figure 2, the Java imple-mentation is generated from GDMO spe-

125

Jada: Java, Architecture, Development and ApplicationA R N E S O L E V Å G H A T L E N , Ø Y S T E I N M Y H R E , B I R G E R M Ø L L E R - P E D E R S E N A N D S T I G J A R L E N E S S

Telektronikk 1.1998

Applet

Java-enabledBrowser

system system

system

RMI

RMI RMI

Server (s)

RMI

HTTP

system

system

GDMOspec.s

GDMOapplication

spec.s

Telenor Profile spec.- supported models- Java code

JavaGDMO Compiler

Predefined Java- Java Runtime system- Object panels

Documentation- html

GenericBrowser

Java ClientImpl.

Java ServerImpl.

Java virtual machine

Standards

Telenor Specific

Figure 2 Architecture of Jada Development Tools

Figure 1 A Jada application consisting of a set of server systems and a client applet

cifications. These include GDMO speci-fications of standard object models in thedomain; in addition comes the moreapplication specific specifications. Usu-ally, GDMO specifications are verygeneric, with optional packages coveringa wide variety of cases. Profile specifica-tions provide the subset that is used. Inaddition, the profile specifications mayinclude Java code to complement theskeleton Java code generated from theGDMO specifications. The GDMO com-piler will among other things generatethe method name and parameters for anaction specified in GDMO, while thecomplementary Java code in the profilespecification will provide the implemen-tation of this action. The generated Javacode is running on top of a Jada RuntimeSystem that in turn is run by the Javavirtual machine. In order to present andenter values in attributes of objects, aPanel is defined for each class. In addi-tion, a generic Browser provides meansfor navigating in the naming trees of thesystems.

Distributed ObjectArchitecture

The basic execution architecture of Jadais an architecture of distributed Java RMIobjects. For this presentation it is notimportant which underlying protocol thatis used. It could be: HTTP, a special RMIprotocol, a protocol for a combinedCORBA/RMI approach, or anotherprotocol. For a discussion of per-formance and security, the choice ofprotocol may however be important.

The distributed object architecture comesabout by mapping the GDMO objectmodel shown in Figure 3 into a corre-sponding API on top of Java/RMI:

• GDMO Object classes are mapped toJava interfaces and implementationclasses.

• GDMO attributes are mapped to set-and get methods of the Java interfacesand implemented by variables andimplemented set- and get methods inthe implementation classes.

• GDMO actions are mapped to methodsof the interfaces and implemented inthe implementation classes.

• GDMO notifications are mapped to aspecial method that treats the notifi-cation and possibly generates eventreports by means of remote methodinvocations on destination objects.

• GDMO packages are mapped to inter-face types with methods representingthe contents of the packages.

• GDMO behaviour specifications aremapped to documentation only (inHTML).

• GDMO name bindings are mapped tocreate methods in the naming classesand for each class to a general Con-tainer interface specifying the con-tainment relationship for objects ofthe class.

• ASN.1 types are mapped to data typeclasses in Java, and these are then usedto specify variables in the implemen-tation classes and parameters tomethods.

One may argue that Managed ObjectClasses should become Java classes, butin fact, Managed Object Classes reallyjust define how the manager views theinformation in the MIB, and this isexactly the purpose of interfaces in Java.

As is indicated in Figure 5, a ManagedObject Class ‘C’ is mapped to an inter-face ‘C’ that extends interfaces corre-sponding to both superclasses andpackages, and the corresponding imple-mentation class ‘CImpl’ extends Man-agedObjectImpl and implements theinterface ‘C’.

The fact that the managed objects maybe named in the containment tree is re-flected by the fact that ManagedObject-Impl extends RemoteContainerImpl. Thisis not shown in Figure 5.


Attributes

Actions

Attributes

Actions

....

....

Package 1

Package 2

....

superclasses

<attribute-name> ATTRIBUTEWITH ATTRIBUTE SYNTAX <ASN.1 type>;...

REGISTERED AS Attribute 1;

<action-name> ACTION...MODE CONFIRMED;WITH INFORMATION SYNTAX <ASN.1 type>;WITH REPLY SYNTAX <ASN.1 type>;

REGISTERED AS ACTION 1;

Figure 3 GDMO class objects with packages, superclasses, attributes and actions

RMI

Remote Method Invocation (RMI) enables objects inone Java Virtual Machine (VM) to seamlessly invokemethods on objects in a remote VM. To invoke amethod on a remote object the Java program needs areference to the object. A remote reference is obtainedeither as an argument or return value, or by means ofthe simple name service provided by RMI. To lookup aremote object the name of the object and the location(hostname) must be known.

The architecture of RMI consists of three layers, asshown in Figure 4:

• Stub/Skeleton Layer: Client-side stubs and server-sideskeletons

• Remote Reference Layer: Reference/invocation be-haviour

• Transport Layer: Connection set up and management,and remote object tracking.

Client Server

Stubs Skeletons

Remote Reference Layer

Transport

Figure 4 The layers of RMI

A remote object implements one or more remote inter-faces, which are pure Java interfaces that declare themethods of the remote object. A method invocation on aremote object has the same syntax as a method invoca-tion on a local object.

Application Architecture

The architecture of objects within server-and client systems is normally not con-sidered a part of a distributed objectmodel, but is left to whatever possiblearchitectures being supported by theactual implementation language. This isnot the case with Jada. In addition to thebasic structuring of systems by means ofname bindings mentioned above, Jadaapplies the following classification ofobjects (or in some cases just aspects ofobjects) into the following categories(shown in Figure 6):

• Model specific objects/aspects ofobjects, which come from an objectmodel of the domain

• Application specific objects/aspects ofobjects, which have to do with theapplication specific functionality of agiven application and not of thedomain

• Interface specific objects/aspects ofobjects, that define either interfaces toother systems or user interfaces.

The classification into model, applicationand interface does not have to classifywhole objects, but also aspects ofobjects, i.e. one object may have bothmodel and application specific aspects.In order for the classification to work foraspects, it is required that the specifica-tion of the different aspects of the sameobject class can be isolated and identi-fied. Depending on the situation, we will

talk about application objects or applica-tion specific aspects. Details of thisclassification can be found in [1].

There are three motivations for themodel-application-interface classifica-tion:


Attributes

Actions

Attributes

Actions

....

....

Package 1

Package 2

....

superclasses

<attribute-name> ATTRIBUTEWITH ATTRIBUTE SYNTAX <ASN.1 type>;...

REGISTERED AS Attribute 1;

MOC C

interfacePackage 2

interface C

Java interfaceimplementing theinterface for thecorrespondingmanaged objectclass

set<attribute-name>(<ASN.1type>datatype)...<ASN.1 type>datatype get <attribute-name>...

extendsinterfacePackage 1

extends (<ASN.1 type>datatype)<action-name>(<ASN.1 type>datatype)(action behavior in Java)

extends

class CImpl

Java classimplementing theinterface for thecorrespondingmanaged objectclass

<action-name> ACTION...MODE CONFIRMED;WITH INFORMATION SYNTAX <ASN.1 type>;WITH REPLY SYNTAX <ASN.1 type>;

REGISTERED AS ACTION 1;

implements ManagedObjectImplextends

interfaces

Figure 5 GDMO to Java mapping

interfacespecificobjects/aspects

applicationspecificobjects/aspects

modelspecificobjects/aspects

Figure 6 Object classification categories

• It helps in classifying requirements:An application will have requirementson

- which application domain to cover

- which functionality to provide

- which users and other systems tointerface to.

• It helps in stabilising a given design:The objects coming from a domainmodel is more stable than the objectsproviding the functional requirements,as these may change with changingrequirements.

• It supports reuse: The reason for iden-tifying the model objects is that thecorresponding classes have a largepotential for (re)use within other appli-cations in the same domain.

An object-oriented analysis of a domainwill result in a domain object model.When an application in the domain isimplemented in terms of objects, it isobvious to start with objects that comedirectly from this analysis.

The domain of Jada (network and servicemanagement) has several domain objectmodels covering network elements andnetworks. These domain object modelsare standardised and specified in GDMO.The model specific objects of Jada appli-cations are produced by mapping theseGDMO specified object models to cor-responding Java object models.

Most object-oriented analysis methodsrecommend domain object modelling. Incontrast to most of these, where domainobject models consist of classes of‘passive data objects’, the typical domainobject models for Jada include managedobjects that have actions.

Application specific objects are objectsthat are particular for the given applica-tion. While requirements on the applica-tion that have to do with the domain maybe associated with the model specificobjects, functional requirements maylead to application specific objects/aspects.

Giving the model specific objects (andclasses) of an application,

• requirements that naturally can beassociated with the model specificobjects lead to the introduction ofapplication specific aspects of thegiven model specific objects, e.g. bydefining subclasses with additionalmethods that represent applicationspecific functionality

• requirements that cannot naturally beassociated with the model specificobjects lead to the introduction ofseparate application specific objects.

As the Jada development tool makes itpossible to associate Java code withGDMO specified classes, it is possible tospecify these application specific objectsin GDMO and let them be contained as

subordinate to the root sys-tem object, see Figure 7.They may either be madevisible through namingattributes or just be ‘blackobjects’ that are there toprovide the applicationspecific functionality.

As mentioned above, mostdistributed architectures do not

provide any structure for parts of systemsrunning on servers, and the classificationinto model, application and interfaceobjects/aspects is introduced for this pur-pose. The following compares this classi-fication with two- and three-tier architec-tures.

Traditionally, client-server applicationswere mostly based on two-tier architec-tures; either with all the application logicon the desktop, the server running onlythe database, or with a slightly thinnerclient and some application logic on theserver. The main advantage of the two-tier architecture is its simplicity; it isquite straightforward to decide whichfunctions go where.

In three-tier architectures the first tiercontains the clients. The clients typicallyprovide a user interface and some localprocessing. The second tier contains theapplication logic (often called ‘businessobjects’), while the third tier contains thedatabase(s). The clients never access thethird tier directly. The middle tier makesabstractions of the resources in the thirdtier.

Business objects within the second tiermay themselves have client-server rela-tionships (multi-tier architecture).

The back-end tier contains databases andlegacy applications. The middle tierobjects communicate with the databasesand external applications in the third tier.

The three-tier architecture has someresemblance to the model/application/interface classification. Business objectsmay be introduced to capture applicationspecific aspects. While the three-tierarchitecture is introduced for ‘physical’reasons (load distribution, independenceof data representation, etc.), the model/application/interface classification isintroduced in order to structure a largenumber of objects independent ofwhether they are part of clients, serversor databases. When a three-tier architec-ture is applied to an application that also


Applet

Java-enabledBrowser

system system

system

RMI

RMI RMIRMI

HTTP

system

system

Application specific objects"black objects"

Figure 7 Application specific objects

classifies by means of model/applica-tion/interface, there may be interface spe-cific objects in the middle tier and appli-cation specific objects in the first tier.The third tier will probably mostly havemodel specific objects (the data baseobjects of a domain object model), butthe middle tier may also have modelobjects. As an example, a GDMO-speci-fied Management Information Base(MIB) may be represented both as data-base objects in the third layer and as‘agent’ objects together with the otherapplication specific objects in the middlelayer.

Architecture of JadaDevelopment Tools

The special thing about the Jada develop-ment architecture is that it is centredaround GDMO specifications and thatas many as possible of the applicationsare generated from these. Parts of theJava implementation is generated fromGDMO specifications:

• standard object models in the domain,and

• application specific specifications.

In Figure 8 the development architectureis illustrated with the GDMO specifica-tions that have been used in the examplesystem.

Profiles

Usually, GDMO specifications are gene-ric, with optional packages covering awide variety of cases. The profile specifi-cations provide the subset that is used forthe specific cases. The profile also speci-fies the system root which is normallynot specified in existing standard objectmodels. Profiles are specified in a nota-tion similar to GDMO. No effort hasbeen put into making this notation acomplete language in the sense thatbehaviour of objects can be specified.See Figure 9.

Code

GDMO specified models include specifi-cation of behaviour in terms of informaltext only. For the purpose of generatingserver systems according to a GDMOmodel, a simple mechanism for asso-ciating code with the GDMO specifica-tions has been developed. In order not tochange the GDMO specifications, the

code is provided in separate specifica-tions. The profile specifications are thebasis for the implementation, and itassociates code to each class, set/replacemethod and action of the profile, seeFigure 10.

Jada Runtime System

The Jada Runtime System consists of anumber of Java interfaces and classesthat implement basic properties of man-aged objects in accordance with theGDMO standard X.722 [5].

• Attribute types in terms of ASN.1 aresupported by a set of Java classesimplementing the ASN.1 types. Inaddition, there are Panel object classesdefining user interface components forall these types. Each panel shows thecontents of the corresponding valueobject, and provides both an editableand a view-only version.

• Name bindings are supported by Javainterface types and implementationclasses that provide navigation in MIBs.

• The capability of sending event reportsis supported by an EventReporterinterface and of receiving event reportsby the EventReportDestination inter-face are supported.

The JADA prototype environment con-tains a generic browser for inspectingMIBs. It is generic in the sense that it is

independent of the information modelbeing inspected. The browser is made byuse of the Java Reflection API. With thisAPI it is possible to get informationabout any object, such as information


GDMOspec.s

GDMOapplication

spec.s

Telenor Profile spec.- supported models- Java code

JavaGDMO Compiler

Predefined Java- Java Runtime system- Object panels

Documentation- html

GenericBrowser

Java ClientImpl.

Java ServerImpl.

Standards

X.721, M.3100,ETSI, GOM

Telenor Specific

DSC, KOFSERMAN

Java virtual machine

Figure 8 Jada Development applied to example systems

logProfileBehaviour BEHAVIOUR DEFINED AS" This interface defines the Telenor" concrete MIB interface to the X721.Log" managed object class. ";

Log PROFILEINCLUDES X721.log;

SUPPORTS CONDITIONAL PACKAGES//FROM: X721.log:

X721.finiteLogSizePackage,X721.logAlarmPackage,X721.availabilityStatusPackage,X721.duration,X721.dailyScheduling,X721.weeklyScheduling,X721.externalScheduler,

//FROM: X721.top:X721.packagesPackage;

//X721.allomorphicPackage;//NOT SUPPORTED

SUPPORTS NAME BINDINGSX721.log-system;

BEHAVIOUR logProfileBehaviour;REGISTERED AS telenorProfileID 999;

Figure 9 Example Profile Specification

Figure 10 Example Code Specification

Figure 11 Jada Example System

about methods, constructors, fields, etc.Due to the mapping of GDMO to Java,the Browser needs a little help. Forinstance, it needs help to identify whichmethods that are operations on attributesand which are in fact actions defined inGDMO. In order to solve this problem,all objects can be asked for their GDMO-attributes, actions and name bindings.

The Browser will then use reflection toget the parameters right.

The use of the Reflection API togetherwith the DataPanels enables the Browserto display all objects, regardless of type.In addition to viewing an object, it is alsopossible to change its attributes by in-voking the appropriate set-methods.

Application of the JadaArchitecture

In order to illustrate the architectureissues of Jada, a prototype Jada applica-tion is presented. The domain of thisprototype application includes bothGDMO specified network models andapplication models. Among the applica-tion objects are the customer class andorder class. In addition, the exampleapplication implements an interface tothe invoice system of Telenor (KOF).

The distributed objectarchitecture

The example Jada application consists ofthree server systems (Sermas, KOF andDSC). The distributed object architectureof the example application is shown inFigure 11.

• Sermas is a Telenor-specific systemsupporting user configuration of SDH-lines and status reporting about a cus-tomer’s subscribed lines. Sermas relieson the DCS system to provide connec-tions to Sermas. Sermas handles infor-mation about Customers and CustomerSubscriptions, a Customer’s AccessPoints (CAPs), as well as informationabout SDH leased-line services. Fordetails, see the Sermas specification in[3]. The GDMO specification forSermas is generated from the corre-sponding OMT specification from theSermas Requirements Specification.

• DCS is the network management sys-tem providing the SDH leased-lines toSermas. The SDH network equipmentand connections are registered, moni-tored and maintained in the DCS. Thesystem is based on a GDMO specifica-tion, which in turn builds on ITU-TM.3100 and ETSI GOM.

• The KOF application is based on asmall subset of KOF specified inGDMO for the purpose of the demon-stration. To populate and interrogatethe different MIBs, a generic browseris used. The Browser navigatesthrough the data by using the naminghierarchy defined in the MIBs. Theonly client application with a userinterface (and even that is kept at aminimum) is the Sermas operatorapplication, while the other applica-tions are interfaced by means of thebrowser.

• The user application supports an ope-rator in accessing (reading and up-


//$CODE=$PRF:Telenor.KOF.Kof#DECLARATION// CODER:Attached DECLARATION Code

/*** This variable carries the reference to the KOFagent in Sermas.**/

Telenor.KOF.KofAgent kofAgent;

//$CODE=$PRF:Telenor.KOF.Kof#ACT:KOF.invoicing// CODER:Attached ACTION Code KOF.createInvoiceParam cIP = new KOF.createInvoiceParam();

// assign to cIPs attributes from argumentBillingImpl aBillingImpl= (BillingImpl)billing;cIP.setAccountId(

(aBillingImpl.createOrFindAccount(argument.getCustomerId())).getAccountId());

cIP.setPeriod(argument.getPeriod());messageProcessing.createInvoice(cIP);

userappl.

Java-enabledBrowser

Sermas system

system

RMI

RMI

Jada example system

RMI

HTTP

KOF

DSC

dating) the Sermas server. The userapplication is an Applet, running in anordinary, Java-enabled Web browser.

The application architecture

The object classes of the object modelsof X.721, M.3100, ETSI GOM and theactual application of these in the DSCobject model form the model specificpart of the Jada example system, espe-cially the DSC part. The Sermas partbuilds partly on this, but introduces otherkinds of model object classes, as thecustomer object class, which typicallymay be used in other systems wherecustomers are handled. Examples of

model specific object classes in KOFare Customer and Address.

The objects of the user interface appletare obvious examples of interfaceobjects. Other examples are objects thatinterface Sermas with DSC and KOF.

KOF has typical model specific objectslike orders and invoices (common tomany Order-Invoicing systems), as wellas application specific objects. Sermashas, among others, customer and cus-tomer access points as model objects,and subscriptions as application objects.Figure 12 shows an overview of Sermas’object model.

Conclusion

Jada, a prototype environment for de-veloping management systems in Javabased upon GDMO specifications, hasbeen presented. Jada extends the basicdistributed architecture of RMI objectsby the architecture defined by theGDMO object model.

The basis in terms of GDMO gives Jadaa benefit in domains where GDMO isalready used. The example application ofJada contains a GDMO specified net-work model and this was readily trans-lated to Java.


Figure 12 A simple version of Sermas, specified in OMT

serviceProvider customer networkProvider

billingLog

detailedBillingRecord

customerPremises customerOperatorSermasoperator

customerAccessPoint

subscriptionaccessPointBinding

usageHistoryLog

circuit

X.746:schedulersubclases

sdhLLservice

SLA

1+

1+

1+

1+

A B A contained in B

class exactly one

class zero or more

class zero or one

class one or more1+

class numerically specified1-2, 4

X.721. system (Sermas)

For design of applications that do nothave a domain object model GDMOspecification, Jada has been used

• for generating a Java design from anOMT model by specifying the OMTmodel in GDMO and then translatingit to Java, and

• for generating a Java design from anexisting database application, making

the design directly in GDMO and thentranslating it to Java.

The benefit of using GDMO for theobject model is that the documentationbeing produced by the Jada tool will bethe same for standardised GDMO modelsas for the design models.

References

1 Mathiesen, L et al. ObjektorienteretAnalyse. Forlaget Marko, 1993.

2 Møller-Pedersen, B et al. Jada :Java-, Architecture, Development,and Application. Kjeller, TelenorR&D, 1998. (Note FoU N 01/98.)

3 Breivik, T et al. Input to the SermasRequirements Specification. Kjeller,Telenor R&D, 1996. (Note FoUN 16/96.)

4 ITU-T. Information Technology :Open Systems Interconnection :Structure of Management Informa-tion : Definition of ManagementInformation. Geneva, ITU, 1992.(ITU-T Recommendation X.721.)

5 ITU-T. Information Technology :Open Systems Interconnection :Structure of Management Informa-tion : Guidelines for the Definition ofManagement Objects. Geneva, ITU,1992. (ITU-T RecommendationX.722.)


Arne Solevåg Hatlen is Research Scientist atTelenor R&D, where he has been involved insystems planning and systems planning metho-dology work in the area of TelecommunicationsManagement Network (TMN). His main interestsare object-orientation in design and implementa-tion and he is currently working in a Telenor R&Dproject dealing with the object web and middle-ware technologies for the Internet.


Øystein Myhre is Research Scientist at TelenorR&D, where he is engaged in the evolution of theInternet. He has been involved in developing TMNsystems at Telenor and at Siemens Telecom Nor-way. His experience with object-orientation goesback to the development of early implementationsof the object-oriented language Simula at the Nor-wegian Computing Center and at the NorwegianDefence Research Establishment.


Birger Møller-Pedersen is Senior ResearchScientist at NorARC, Applied Research Center,Ericsson Norway, Software Engineering.


Stig Jarle Ness is Research Scientist at TelenorR&D, where he has been employed since 1996.His interests are middleware, distributed com-puting and object-oriented systems.


Special



1 Introduction

The PC-based planning tool FABONETT has earlier been estab-lished as an aid for planning the deployment of service accesspoints in PDH-based access networks (see [1]). What is de-scribed here is a related tool to be used for the same problem inSDH-based access networks. This new tool, which has beencalled FABONETT/SDH, has been created through a jointeffort by Telenor Research and Development, Det NorskeVeritas and regional network planners in Telenor Nett. FABO-NETT/SDH has been developed for use by network plannersresponsible for planning Telenor’s access networks.

FABONETT/SDH is an integer programming model whichattempts to find the lowest cost SDH-based access networkstructure which meets all capacity and connectivity require-ments. The integer program is solved using a combination of abranch and cut algorithm with dynamic variable and constraintgeneration, and heuristics.

The planner can choose which categories of variables whichwill be treated as integer variables in the branch and cut phaseof the algorithm, and which variables will be determined byusing heuristics. The user interface allows the planner to makemodifications to the solution found, and check feasibility andcost.

FABONETT/SDH has a graphical and table based user inter-face, and most of the development work has been directed to theimplementation of this interface. In this paper, however, onlythe mathematical model and algorithms used in FABONETT/SDH are described.

2 The service access point structuredesign problem

Here a short description will be given of the service access pointstructure design problem to be solved.

We are given a local switch (LS) and a set of main distributionpoints (MD-s) together with a set of what we call special sub-scribers (SS-s). The MD-s and the SS-s can be connecteddirectly to LS or via service access points (SAP-s) where multi-plexing is done. FABONETT/SDH operates with copper cables,fibre cables and, by stretching the analogy, radio cables. An SSmust be connected to LS or to a SAP by either fibre or radiocables. An MD must be connected to LS or to a SAP by coppercables. A sequence of cables which connects an MD or an SS toa SAP or to LS, or which connects a SAP to another SAP or toLS, is called a connection. The SAP-s may belong to SDH ringswhich must go through LS. In an SDH ring there are connec-tions between pairs of contiguous SAP-s in the ring, and con-nections between LS and SAP-s adjacent to LS in the ring.

Each cable is placed in a sequence of contiguous trace sections.A trace section is characterized by its cost, length, type and oneor more section codes. The trace section type determines interalia which cable types can be placed in the trace section. Typi-cal trace section types are conduits and ducts (existing or new),trenches of different categories, air cable sections and radiosections.

A section code is simply a positive integer. Two trace sectionsshare a common section code if events causing damage to thetwo trace sections are assumed to be positively correlated.A connection inherits the section codes from the trace sectionsused by the cables forming the connection. Two connectionsbelonging to the same SDH ring may not share a section code.

FABONETT/SDH operates with PDH SAP-s and SDH SAP-s.All SDH SAP-s are assumed to contain add/drop multiplexers(ADM-s). If an MD is directly connected to a SAP, the SAPmust contain RSS/RSU. An SDH SAP can be a TransmissionPoint (TP). A TP does not contain RSS/RSU. Consequently,SS-s and other SAP-s, but no MD-s, can be directly connectedto a TP.

FABONETT/SDH will not propose new PDH SAP-s. It may,however, propose that PDH SAP-s, which in the existing net-work are directly connected to LS, should be connected to anSDH SAP instead.

All SDH rings pass through LS and are either STM1 or STM4SNCP rings.

The SDH SAP-s are ordered hierarchically: SDH SAP-s whichcan only be connected directly to LS or placed in SDH ringsthrough LS are called S1 SAP-s. SDH SAP-s which can only beconnected directly to LS or S1 SAP-s are called S2 SAP-s. SDHSAP-s which can only be connected directly to LS, S1 SAP-s orS2 SAP-s are called S3 SAP-s. S1 SAP-s may belong to STM1or STM4 SDH rings or not belong to rings at all. S1 SAP-swhich belong to rings are called ring SAP-s. By extension oflanguage LS is also denoted as an S0 SAP. If an S2 (S3) SAP Sis connected to an S1 (S2) SAP S’, we say that S is subordinateto S’.

PDH SAP-s may be directly connected to LS or to SDH SAP-s.There are two categories of PDH SAP-s, namely those whichrequire only a single connection, and those which requiredouble connection (i.e. two connections with no section code incommon) back to LS. The PDH SAP-s will normally be con-nected to LS in a way specified by the user. If this is not done, aPDH SAP which requires double connection to LS will beallowed to be singly connected to a ring SAP.

An MD may be directly connected through copper cables eitherto LS or to a SAP which is not a TP. A PDH SAP can only haveconnected to it MDs which either are connected to it in theexisting network or which the planner explicitly connects to it.There may be subscribers connected to an MD who require theMD to be connected directly either to LS, to a ring SAP or to aPDH SAP with double connection to LS.

A circuit connecting an SS to LS belongs to one of two types,namely regular circuits and singular circuits. The singular cir-cuits must be directly connected to LS through fibre. The regu-lar circuits can be connected directly to LS or to a SAP throughfibre or radio. Some SS-s may require that their regular circuitsare connected directly either to LS, to a ring SAP or to a PDHSAP with double connection to LS. A PDH SAP can only haveconnected to it SS-s which are connected to it in the existingnetwork or which the planner explicitly connects to it. By con-vention we say that an SS is connected to a SAP (or LS) if theSS’s regular circuits are connected to the SAP (or LS).

135

Mathematical Model and Algorithms forFABONETT/SDHR A L P H L O R E N T Z E N

Telektronikk 1.1998

Based on the location of LS, locations of MD-s, SS-s, existingcables, existing and candidate trace sections, existing and candi-date SAP-s, FABONETT/SDH tries to find the lowest cost net-work design. The design problem is formulated as an integerprogram which is solved by a combination of linear program-ming with dynamic row and column generation, branch andbound, and heuristics.

Figure 1 gives a schematic view of the network structure. Figure2 shows an input network structure with candidate SAP-s andtrace sections. Figure 3 shows the same structure together withthe chosen SAP-s and connections.

FABONETT/SDH does not invent possible locations for candi-date SAP-s and candidate trace sections. All candidate SAP-sand trace sections must be provided by the user.

Since FABONETT/SDH does not necessarily solve the designproblem to a theoretical optimum, the planner must inspect thesolution and sometimes make model reruns with slightly alteredinput. The planner may for example question FABONETT/

SDH’s selection of a particular SAP candidate and wish to makea rerun with this SAP excluded. FABONETT/SDH’s input for-mat makes this possible without erasing the SAP candidate fromthe input. Or the planner may question the correctness of con-necting a particular SS directly to LS. A rerun may then bemade where the planner specifies which SAP-s the SS should beallowed to connect to.

The planner has a problem of a dynamic nature. In establishingthe best network structure the development of the demand struc-ture over time must be taken into consideration. FABONETT/SDH is a static ‘one shot’ model. Some simple features for‘dynamic use’ are, however, built into FABONETT/SDH. Theplanner can give selected SAP and trace section candidates thelabel ‘preferred’ and give them a bonus. Then two FABONETT/SDH runs are made. First a ‘future run’ is made where the cir-cuit demands represent some future point in time. Then themain run is made where some or all the candidate SAP-s andtrace sections chosen in the future run are labelled ‘preferred’and given a suitable bonus.


PSAP SAP3 SAP2 SAP1 LS SAP1 SAP2 SAP3 PSAP

SAPR

SAPR

MD SSSSMD

Figure 1 Schematic view of network structure

PSAP

LS

SAP2

SAPR

SS

MD

SAPR

SAPR

MD

MD

MD

Figure 2 Input with candidate network elements

3 FABONETT/SDH input in broad terms

The complete input in the form that the planner has to present it,both tabular and graphical on background maps, is described onFABONETT/SDH’s help pages. In order to give an impressionof what input data are needed, an overview of main input itemsis given below. Not all of these data items are used in theinteger programming model, and it will not be apparent how theindividual data elements relate to the model. In the next sectiona detailed description will be given of the input which is directlyrelated to the formulation of the integer program.

• Local switch:- location- cost per line directly from MD-s

• Candidate service access points:- location- status (‘existing’, ‘free’, ‘required’, ‘excluded’, ‘preferred’)- type (single/double connection PDH SAP, SDH SAP, ring

SAP, TP, order in hierarchy)- capacity (maximum number of lines)- bonus (if status is ‘preferred’)

• Main distribution points:- location- SAP type requirement- number of subscribers of various types- number of 2 Mb/s circuits coming from subscribers- maximal distance to connecting SAP

• Special subscribers:- location- circuit requirements (nMb/s for regular circuits and fibre

pairs for singular circuits)- which candidate SAP-s the SS can be connected to

• Nodes (end points of trace sections which are not locations ofLS, candidate SAP-s, MD-s or SS-s):- location- cable splicing (‘possible’, ‘not possible’)- signal regeneration (‘existing’, ‘possible’, ‘not possible’)

• Trace sections:- location- length- type- status (‘existing’, ‘free’, ‘compulsory’, ‘excluded’, ‘pre-

ferred’)- bonus (if status is ‘preferred’)- section codes

• Existing cables:- type- number of available pairs- which trace sections the cable is placed in

• Service access point types:

- single/double connection PDH SAP, STM1/STM4 SDHSAP, ring SAP, TP

- capacity (maximum number of lines from MD-s)

- life cycle cost for all components (RSS/RSU, connections,cabinet, power etc.)

• Subscriber types:- traffic in erlangs

• Cable types:- medium (copper, fibre, radio)- number of pairs- cost per metre- economic life time- trace section types the cable type may be placed in

• Trace section types- cost per metre

4 The integer programming model

4.1 General

Here we describe the core of FABONETT/SDH, namely theinteger programming model. First we introduce some morenotation. Then we describe the input which is used to formulate


PSAP

LS

SAP2

SAPR

SS

MD

SAPR

SAPR

MD

MD

MD

Figure 3 Resulting design

the constraints. Finally, the variables and constraints aredescribed, and the form of the cost function is outlined.

We set up an undirected network which we call the link networkwith two types of links, namely trace section links and cablelinks. The cable links represent pieces of existing cables be-tween contiguous nodes on the cable where cable splicing maytake place. The trace section links represent trace sections(existing or not) where new cables may be placed. A tracesection link inherits the section codes from the trace section itrepresents. A path in the link network is a sequence of con-tiguous links. All trace section links without section codes(usually ducts) are duplicated, and the original and the duplicatelink receive different section codes. The duplicate links aregiven cost 0, but ‘pushes’ on its original as indicated in the con-straints (21) in section 4.4 below.

As indicated earlier we operate with copper cables, fibre cablesand, by analogy, ‘radio cables’. A radio cable contains one paironly. Its capacity will typically be 155 Mb/s or 622 Mb/s. Theregular demands of SS-s can be routed on radio cable pairs withlower capacities, e.g. 34 Mb/s or 8 Mb/s.

4.2 Notation

In order to describe the integer programming model we intro-duce some notation.

G geographical node containing candidate SAP-s

S service access point

U special subscriber

M main distribution point

R SDH ring

l cable or trace section link

r(U) no. of fibre/radio pairs carrying regular circuits toSS U (normally 0 or 1)

s(U) no. of fibre/radio pairs carrying singular circuits toSS U

P(M) required no. of copper pairs connected to MD M

TO1(M) no. of 2 Mb/s from MD M which do not requireprotection in ring

TO2(M) no. of 2 Mb/s from MD M which do require protec-tion in ring

TO1(U) for SS U’s regular demand, no. of 2 Mb/s which donot require protection in ring

TO2(U) for SS U’s regular demand, no. of 2 Mb/s which dorequire protection in ring

TO1(S) no. of 2 Mb/s from PDH SAP S which do notrequire protection in ring

TO2(S) no. of 2 Mb/s from PDH SAP S which do requireprotection in ring

TOCAP(R) capacity for 2 Mb/s in ring R (126 for STM-1-ringsand 504 for STM-4-rings)

LIN(M) no. of lines from MD M

LINCAP(S) maximum no. of lines to SAP S

Γ(S) a minimal set of MD-s which can be connected toSAP S and which together exceed the line capacityof SAP S

fl no. of available fibre/radio pairs in cable link l

kl no. of available copper pairs in cable link l

pfl an upper bound on the number of SAP-s and SS-swhich need fibre/radio pairs in trace link l

pkl an upper bound on the sum of fractions of MD-scopper pair requirements which can pass throughlink l

TRAF1(M) traffic (in erlangs) on lines from MD M which donot require protection in ring

TRAF2(M) traffic (in erlangs) on lines from MD M whichrequire protection in ring

E0 and E the constant and rate of increase of the linearizederlang function expressing, for a given blockingprobability, the number of channels needed as afunction of traffic

4.3 Variables

When we below state the condition for a variable to be equal to1 it is assumed that the variable is 0 otherwise.

xS = 1 if SAP S is established

xMS fraction of traffic and circuits from MD M whichgoes to SAP S (S may be LS)

xUS = 1 if the regular circuits from SS U go to SAP S (Smay be LS)

xSS’ = 1 if SAP S is subordinate to SAP S’ (S’ may be LS)

xR = 1 if STM ring R is established

xi = 1 if a radio mast is established in node i

xl = 1 if trace link l is established

xld = 1 if the duplicate trace link to trace link l is established

x2SS’ no. of 2 Mb/s in an STM1 connection between theSDH SAP-s S and S’ where S is subordinate to S’


x2SR no. of 2 Mb/s (stand-by circuits included) to ringSAP S routed in ring R

xMGv no. of copper pairs from MD M to LS/SAP node Gvia path v

xUGv no. of fibre/radio pairs from SS U to LS/SAP nodeG via path v carrying regular circuits (0 or 1)

xUv no. of fibre pairs from SS U to LS via path v carry-ing singular circuits

xSGv no. of fibre/radio pairs from SAP S to LS/SAP nodeG via path v (0 or 1)

yMG number of lacking paths from MD M to node G

yUG number of lacking paths for regular circuits fromSS U to node G

yM = 1 if there is no connection from MD M

ysU number of singular circuits to SS U which lack con-

nection

yrU = 1 if the regular circuits to SS U lack connection

yG = 1 if no SAP is established in node G

yfl extent of fibre/radio capacity violation in trace link l

ykl extent of copper capacity violation in trace link l

The y variables are introduced in order to avoid infeasibilitieswhen solving the integer program. They are given large co-efficients in the objective function.

4.4 Constraints

(1)

(2)

(3)

(4)

(5)

(6) xS – xMS ≥ 0

(7) xS – xUS ≥ 0

(8)

(generated only if left hand side can be < 0)

− LIN(M)xMSM∑ + LINCAP(S)xS ≥ 0

xUSS∑ + yU

r =1

xMSS∑ + yM =1

xUvv∑ + yU

s ≥ s(U )

xUGvv∑ − r(U ) xUS

S ∈ G∑ + yUG ≥ 0

xMGvv∑ − P(M) xMS

M ∈ G∑ + yMG ≥ 0

(8’)

for all minimal Γ(S) (8’) is an alternative to (8)

(9) 63xSS’ – x2SS’ ≥ 0 (not generated if S is a PDH SAP)

(10) xS’ – xSS’ ≥ 0

(11)

(12)

(13)

(14)

(15)

(S being a non-ring SAP)

(16)

(S being a ring SAP)

(17)

where the sums are over paths and rings which passthrough cable link l.

(18)

where the sums are over those paths and rings which passthrough trace link l.

(19)

where the sum is over those paths which pass throughcable link l.

(20)

where the sum is over those paths which pass throughtrace link l.

−xMGv

P(M)MGv∑ + pkl xl + pkl ykl ≥ 0

− xMGvMGv∑ ≥ −kl

− xSGv∑ −xUGv

r(U )∑ −

xUv

s(U )∑ − xR∑ + p fl xl + p fl yl ≥ 0

− xSGv∑ − xUGv∑ − xUv∑ − xR∑ ≥ − f l

−E0 xS

30+

E ⋅TRAF1(M)

30+ TO1(M)

xMS

M∑

−2E0 xS

30+

E ⋅TRAF2(M)

30+ TO2(M)

xMS

M∑

= 0

x2SRR∋ S∑ − x2S’S

S’∉ PDH∑ − TO1(S’) + 2TO2(S’)[ ]

S’∈ PDH∑ xS’S

− TO1(U ) + 2TO2(U )[ ]U∑ xUS

−E0 xS

30+

E ⋅TRAF1(M)

30+ TO1(M)

xMS

M∑

= 0

x2SS’S’∑ − x2S’S

S’∉ PDH∑ − TO1(S’)xS’S

S’∈ PDH∑ − TO1(U )xUS

U∑

xS − xRR∋ S∑ = 0

TOCAP(R)xR − x2SRS∑ ≥ 0

xSGvv∑ − xSS’

S’∈ G∑ ≥ 0

xS − xSS’S’∑ = 0

Γ S( ) −1( )xS − xMSM ∈Γ (S)

∑ ≥ 0


(21) xl – xld ≥ 0

(22) xi – xl ≥ 0 if node i is one of the end points of link l.

(23)

(1) expresses that all copper pairs from MD M to node G mustfollow a path from M to G.

(2) expresses that a fibre pair carrying regular circuits from SSU to node G must follow a path from U to G.

(3) expresses that fibre pairs carrying singular circuits from SSU to LS must follow paths from U to LS.

(4) expresses that MD M must be connected to a SAP (or to LS).

(5) expresses that an SS U having regular circuits must be con-nected to a SAP (or to LS).

(6) expresses that if MD M is connected to SAP S, then S mustbe established.

(7) expresses that if SS U is connected to SAP S, then S must beestablished.

(8) or (8’) express that the number of subscriber lines connectedto SAP S must not exceed the capacity of S.

(9) expresses that the number of 2 Mb/s between SAP S andSAP S’ cannot exceed 63.

(10) expresses that if SAP S is established and is subordinate toSAP S’, then S’ must be established.

(11) expresses that if SAP-2 or SAP-3 candidate S is estab-lished, then it must be subordinate to some SAP S’.

(12) expresses that if SAP S is established and is subordinate tosome SAP in geographical node G, then there must be a pathfrom S to G.

(13) expresses that the number of 2 Mb/s in ring R must notexceed ring capacity.

(14) expresses that ring SAP S is established if and only if itbelongs to an established ring.

(15) and (16) express flow conservation of 2 Mb/s circuitspassing through SAP S.

(17) and (18) express that there must be sufficient number offibre pairs in link l to support all fibre requirements in it.

(19) and (20) express that there must be sufficient number ofcopper pairs in link l to support all copper requirements in it.

(21) expresses that new cables can be placed in a duplicate linkonly if new cables are placed in the corresponding original link.

(22) expresses that if radio links are established, then corre-sponding radio masts must be established.

xTS ∈ G∑ + yG =1

(23) expresses that at most one SAP can be established in a geo-graphical node.

Constraints of type (13) and many variables will be generateddynamically during the solution of the problem. In addition,trace cut constraints, to be described later, will be generateddynamically.

4.5 The cost function

The cost function to be minimized has the following form:

(24)

Here the c-s represent cost coefficients derived from cost datagiven in FABONETT/SDH’s input tables, and C is a large posi-tive constant. This cost function is detailed elsewhere. We onlymention here that the coefficients cfl and ckl are chosen a littlelarger than the cost per pair for new fibre pairs and copper pairs.

5 Solution Method

5.1 General

The solution method is a combination of:

• linear programming with dynamic path generation• branch and cut• cost adjustment heuristics (optional)• variable fixing heuristics.

In the branch and cut phase the variables xS, xMS, xUS and,optionally, xl are required to be integer. For large problems thebranch and cut phase may take too long if the xl variables arerequired to be integer. Therefore the planner has the option ofnot requiring these variables to be integer in this phase. Theirvalues will then, together with other variables not required to beinteger in the branch and cut phase, be determined by heuristics.

5.2 Solving the linear programming relaxationwith dynamic path and ring generation

We repeatedly solve linear programming relaxations of theproblem. The number of path and ring variables xMGv , xUGv ,xUv , xSGv , xR and x2SR is so large that it is unrealistic to includethem all in the model from the outset. The relevant path andring variables are therefore generated dynamically during thesolution process using classical column generation techniques.

The following notation is used for the shadow prices associatedwith the constraints which involve path and ring variables:

Constraint no. Shadow price

(1) πMG

(2) πUG

(3) πU

cMGv∑ xMGv + cUGv∑ xUGv + cUv∑ xUv + cSGv∑ xSGv + cR∑ xR

+ cS∑ xS + cSS’∑ xSS’ + ci∑ xi + cl∑ xl + cMS∑ xMS + cUS∑ xUS

+ c fl∑ y fl + ckl∑ ykl + C yM + yMG + yUr + yU

s( )∑ .


(12) πSG

(13) πR

(14) πS

(16) πSbal

(17) πflca

(18) πfltr

(19) πklca

(20) πkltr

Here πR is not known for rings which are not generated.

We assume that we have a feasible basis for our system. Thereduced costs for the path and ring variables relative to thisbasis can be expressed as follows:

Variable Reduced cost

5.3 Reduced costs for ring variables which arenot generated

In order to establish reduced costs relative to our basis for ringvariable x2SR which are not generated we need the values of theshadow prices πR associated with the corresponding constraints(13) which are not generated. We shall show how we establishπR. We pretend that (13) is included in the system and that xR isin our basis with value 0. Since xR is basic we have that

(31)

so that

(32)πR = cR + π fl

ca

l ∈ R∑ + π fl

tr

l ∈ R∑ + πS

S ∈ R∑

/ TOCAP(R).

cR − TOCAP(R)πR + π flca

l ∈ R∑ + π fl

tr

l ∈ R∑ + πS

S ∈ R∑ = 0

πR − πSbal

(30) x2SR

cR − TOCAP(R)πR + π flca

l ∈ R∑ + π fl

tr

l ∈ R∑ + πS

S ∈ R∑

(29) xR

cSGv − πSG + π flca

l ∈ v∑ + π fl

tr

l ∈ v∑

(28) xSGv

cUv − πU + π flca

l ∈ v∑ + π fl

tr

l ∈ v∑ / s(U )

(27) xUv

cUGv − πUG + π flca

l ∈ v∑ + π fl

tr

l ∈ v∑ / r(U )

(26) xUGv

cMGv − πMG + πklca

l ∈ v∑ + πkl

tr

l ∈ v∑ / P(M)

(25) xMGv

5.4 Finding not already generated path variableswith minimum reduced cost

From our cost model (which is not described here) we knowthat the costs for the path variables xMGv , xUGv , xUv and xSGvcan be decomposed in a series of link terms. Therefore the prob-lem of finding a variable for each path variable type which hasminimum reduced cost becomes a shortest path problem in thelink network where the length of a link is the sum of the rele-vant π term (i.e. one of the terms πkl

ca , πflca , πkl

tr / P(M), πfltr ,

πfltr / r(U), πfl

tr / s(U)) and the link term in the cost decomposition.

For each variable type we shall include in the linear program avariable with minimum reduced cost if this reduced cost isnegative.

5.5 Finding not already generated ring variableswith minimum reduced cost

When we generate a new ring R we shall always at the sametime generate the ring variables xR and x2SR belonging to thering together with the corresponding constraint (13).

In section 5.4 we have seen that the variables xR can be assumedto be basic for new rings so that these variables need not bepriced out. When we shall establish ring variables of the typex2SR associated with a SAP S in a geographic node G with mini-mum reduced cost, we see that we need to find a ring through Sand LS which minimizes

(33)

From the cost model we know that the cost coefficient cR can bedecomposed in a term not associated with links and a series oflink terms. The link independent term represents costs in LS.We add one half of this cost term to the link term for all linksinto LS. Therefore the problem of finding a variable of type x2SRwith minimum reduced cost is reduced to a shortest ring prob-lem where the length of a link is the sum of the πassociatedwith the link (i.e. either πfl

ca or πfltr) and the link term from the

adjusted decomposition described above, and where the ‘length’of SAP candidate S is given by πS. We see that it is not remune-rative to include in the ring a SAP candidate with non-negativeπS even if the ring happens to go through the correspondinggeographical node.

Ideally, we should for each SAP candidate and each ring vari-able type introduce into the linear program a variable with mini-mum reduced cost if this reduced cost is negative, i.e. if the ringlength is less than TOCAP(R)πS

bal. Normally, we shall doexactly that, but first we will check whether with simpler meanswe can establish new x2SR variables associated with modifica-tions of existing rings which price out negatively. We proceedas follows:

We go through the (unmodified) rings we have generated al-ready one by one, and for each of these rings we check whetherthere are ring SAP candidates which

• do not belong to the ring

• are situated in geographical nodes which the ring passesthrough

cR + π flca

l ∈ R∑ + π fl

tr

l ∈ R∑ + πS

S ∈ R∑ .


• do not have a link in each of the two paths to LS in the ringwith common section code.

For each ring where this is the case we sort such SAP candi-dates by descending value of – πS + TOCAP(R)πS

bal and classifythem as untreated. Then we modify the ring by including thefirst untreated SAP candidate S and also including other ringSAP candidates located in geographical nodes which the ringpasses through and which have negative πS. Furthermore, weremove from the ring SAP candidates with positive πS. Wedenote the modified ring by R’. If the ring length of R’ is lessthan TOCAP(R)πS

bal , x2SR’ prices out negatively. If that is thecase we include R’ with all its associated variables in the linearprogram.

SAP candidate S, together with the other SAP candidates whichwere included in R’, are classified as treated, and we proceed tothe next untreated SAP candidate.

If we by carrying out the above manage to identify some x2SRvariables which price out negatively, we introduce them, to-gether with the corresponding ring variables into the linearprogram and reoptimize.

It is only when we do not manage to introduce modified rings inthis way that we try to establish shortest rings through the ringSAP candidates. In that case we start again by sorting the ringSAP candidates according to descending value of– πS + TOCAP(R)πS

bal and classify them as untreated. Then westart with the first untreated ring SAP candidate and try to find ashortest ring containing it. The SAP candidate is then classifiedas treated. If the corresponding x2SR variable prices out nega-tively, the ring is introduced into the LP together with asso-ciated variables, and all SAP candidates belonging to the ringare classified as treated.

In the next section we shall describe an algorithm for estab-lishing a shortest ring. This algorithm requires that all linklengths are non-negative. We have therefore a methodologicalproblem because one or more πS-s may be negative. The equal-ity sign in (14) may in principle be replaced by ≥ which wouldimply πS ≥ 0. We have, however, used equality in order totighten the LP relaxation.

The link network, which was originally defined to be an un-directed network, is converted to a directed network by dupli-cating the links and giving the two duplicates opposite directionwith the same length. If the ‘length’ πS of ring SAP candidate Sis negative, we can make use of this by reducing the length onS’s ingoing and outgoing links. This procedure can be general-ized. We start with a ring SAP candidate S0 with most negativeπS and let it form a node set N. We then try to successivelyextend N.

Assume there is a maximal node set N with the following twoproperties:

• All nodes in N can be connected through paths of length 0

• There are SAP-s in N with negative πS.

We let Nc denote the complement of N. Let the shortest linksbetween N and Nc have length mN > 0, and set

We put µN = min (mN, –πN/2), subtract µN from the lengths ofall links between N and Nc and distribute 2µN to the SAP-s withnegative πS in such a way that all these SAP-s still have πS ≤ 0.Then we extend N by including into N all nodes which now canbe reached from nodes in N through paths of length 0. Then wesee again if there are node sets with the two properties men-tioned above and, if so, repeat the procedure.

The links in N which in this way have got their lengths reducedto 0 constitute a tree structure. We replace all nodes in N, exceptthe node containing S0, by two nodes, namely an in-node and anout-node. All links belonging to the tree structure which go inthe direction of S0 are changed to go between in-nodes whilst alllinks belonging to the tree structure which do not go in thedirection of S0 are changed to go between out-nodes. All re-maining links going to the original nodes are changed to enterthe corresponding in-nodes whilst remaining links emanatingfrom the original nodes are changed to emanate from the corre-sponding out-node. In this way we increase the probability thatshortest rings will pick up ring SAP candidates with negativeπS.

As mentioned above, SAP candidates with non-negative πS willnot be considered for inclusion in new rings. They will notcause any link length adjustment, and the nodes they are locatedin will in this context be considered as nodes without a SAPcandidate.

5.6 Shortest ring algorithm

We shall here describe an algorithm for establishing a shortestring passing through LS and a geographical node G.

There exists an algorithm which for several nodes G simultane-ously establishes rings where each ring is a shortest ring passingthrough LS and one of the G-s. This algorithm requires, how-ever, extensive administration and overhead. Since we operatewith a relatively small number of geographical nodes containingSAP candidates, we believe it to be more efficient to apply, foreach G, a simpler algorithm which establishes a shortest ringthrough LS and G. We shall now describe this algorithm whichis nothing but a specialization of Busacker and Gowen’s clas-sical algorithm for finding minimal cost flows in directed net-works.

We shall initially assume that all links have different sectioncodes. Afterwards we shall describe how we proceed withoutthis assumption. The algorithm is based on an implementationof Dijkstra’s shortest path algorithm which accepts parallel linksbetween pairs of nodes.

1. We replace all undirected links by one link in each direction,both with length equal to the length of the undirected link.

2. We apply Dijkstra’s algorithm for finding a shortest pathfrom LS to G. Let this path have length L. During this processwe partition the nodes into two categories K and Kc where Kconsists of the nodes to which we have found a shortest path,and Kc consists of the remaining nodes. For j in K we let Lj bethe shortest path from LS to j.

πN = πSS ∈ N ;πS <0

∑ .


The zM variables are given a small negative cost –ε.

The following inequalities are included in the LP from the out-set:

(34)

with shadow price KMε.

For each M with zM < 1 we do the following:

For the link network we assign capacity cl to link l where cl isset to:

Links with xl = 0 are removed from the link network.

In addition we introduce links with capacity P(M) betweenLS/SAP candidates for M and a supernode. Then we find maxi-mum flow between M and the supernode, with a min cut (C,C’)where M∈ C, and check whether

(35)

If not, and if in addition there exists at least one link l in (C,C’)with xl > 0, we add the constraint (35) to the LP and optimizewith path and ring generation.

Here we of course generate paths from the M-s for which wehave added constraints (35). Such paths which only use freelinks get a bonus equal to the shadow price κM

0 which (34)would have got if zM had cost 0. We shall now determine κM

0:

Assume first that zM is basic both if zM has cost –ε and if zM hascost 0. Then:

(36) –P(M)κM0 + remaining terms = 0

(37) –P(M)κMε + remaining terms = –ε.

The terms denoted as remaining terms are non-negative. Weassume that the basis is the same whether zM has a positive costor not. Then remaining terms are the same in (26) and (27). Thisgives:

(38) κM0 = κM

ε – ε / P(M).

Assume now that zM is non-basic (this can happen only if zMhas cost 0). Then κM

0 = 0 since (24) is satisfied with strict in-equality. (26) then implies that remaining terms = 0, in otherwords that the other constraints in which zM occurs are not bind-ing. Then they will not be binding with a small negative cost onzM either, so that remaining terms = 0 also in (27). With cost –ε on zM, zM will always be basic so that (27) is satisfied, andwe have that:

(39) κMε = ε / P(M).

This means that (38) is still valid.

zM + xll ∈ C,C’( )

∑ − xMSS ∈ C’∑ ≥ 0.

cl =

xl if l is not a free link

min P(M), the slack in 19( ) if l is a free link containing a copper cable

0 otherwise

xMGvG ,v in free links only

∑ − P(M)zM ≥ 0


3. We give node j in K the node number Lj and the nodes in Kc

the node number L. Then we modify the link length for alllinks l by adding i’s node number and subtracting j’s nodenumber. The modified link lengths will thus satisfy thefollowing two conditions:

• they are non-negative,

• they are 0 along the shortest path.

4. We delete the links which constitute the shortest path to Gwhich we have found and assign length 0 to the correspond-ing links heading in the opposite direction.

5. We then apply Dijkstra’s algorithm to find a shortest pathfrom LS to G in the modified network.

6. We combine the two shortest paths we have found to make aring by dropping all links common to the two paths.

Of course, there may not exist any ring passing through LS andG. Then we set the ring length to ∞.

Now we return to the situation where several links can share acommon section code. We have three options for the solution ofthis problem based on one exact and two heuristic methods.

The exact method consists of using a depth-first tree searchwhere we successively eliminate links which violate the sectioncode requirements. We form a directed tree structure of shortestring problems where the root node is the shortest ring problemwithout section codes. The tree in which we perform the depth-first search is such that the successors to a problem node arenodes representing problems where we exclude exactly one linkfor which the section code requirement is violated. (We remarkthat it is permitted to pass through links sharing the same sec-tion code between two consecutive SAP candidates in the ring.)During the tree search we continually update an upper andlower bound on the shortest ring length so that we can find ashortest feasible ring without necessarily traversing the wholetree.

The first heuristic consists simply of removing in step 4 all linksfrom the network which have common section code with linkson the shortest path we found from LS to G, and which are notheading in the opposite direction of links on this shortest path.For the rest the method is identical to the exact method.

The second heuristic is the same as the first except that wealways accept the first ring we get. This heuristic will give afeasible ring if all links which share a common section code areparallel.

6 Trace cut constraint generation

6.1 Trace cut generation for paths to main distri-bution points

We focus on a node in the branch and bound tree where wewant to add trace cuts.

We denote links l which have no xl as free links and define

zM =1 if all paths to M from LS /SAP consist of free links only

0 otherwise

If we have generated (35) for an MD M and κM0 > 0, and the

shortest path does not consist of free links only, we must gene-rate another shortest path which uses free links only and givethe resulting path (if it exists) a bonus κM

0.

6.2 Trace cut generation for rings

Again we focus on a node in the branch and bound tree wherewe want to add trace cuts.

We define:

F(S): the set of rings through S which use free links only forat least one of the paths from S to LS

FF: the set of rings which use free links only

We observe that wS ≥ zS . The wS and zS variables are given asmall negative cost –ε.

The following inequalities are included in the LP from the out-set:

(40)

(41)

For every ring SAP S with zS < 1 we do the following:

We consider the link network and give capacity cl to link lwhere cl is given the value xl if l is not a free link, and the value1 otherwise.

Then we find the maximum flow between S and LS, withmin cut (C,C’), and check if

(42)

is satisfied. If (42) is not satisfied, we add (42) to the LP andoptimize with column generation.

Finding κSF0 and κS

FF0 from κSFε and κS

FFε is analogous tofinding κM

0 from κMε. We get:

(43) κSF0 = κS

Fε – ε

(44) κSFF0 = κS

FFε – ε.

After we have generated a shortest ring through S again we canhave three situations:

wS + zS + xll ∈ (C,C’)

∑ − 2xT ≥ 0

xRR∋ S,R∈ FF

∑ − zS ≥ 0 with shadow price κ SFFε

.

xRR∋ S,R∈ F(S)

∑ − wS ≥ 0 with shadow price κ SFε

.

zS

=1 if ring SAP S is established,

and the ring through S belongs to FF0 otherwise

wS

=1 if ring SAP S is established,

and the ring through S belongs to F(S)0 otherwise

1. The shortest ring belongs to FF. Then the ring is given abonus κS

FF0 + κSF0.

2. The shortest ring belongs to F(S)\FF. Then the ring is given abonus κS

F0. If in addition κSFF0 > 0, we must also find a com-

peting ring in FF which is given a bonus κSFF0 + κS

G0.

3. The shortest ring does not belong to F(S). If κSF0 > 0, we

must find a competing shortest ring in F(S) which is given abonus κS

F0. If in addition this ring belongs to FF, it is givenan additional bonus κS

FF0. If κSFF > 0 and the ring does not

belong to FF, we must find a competing shortest ring in FFwhich is given a bonus κS

FF0 + κSF0.

One problem is how we find a shortest ring in F(S). We havenot found any exact method for this, so we use a heuristic. Inbrief, the heuristic amounts to the following:

1. We establish a shortest path v from LS to S in the subgraphconsisting of free links only.

2. Then we establish a shortest path from LS to S where we arenot allowed to use links with section code common with anyof the links in v.

We have not yet implemented trace cut generation for rings. Towhat extent this will be done is yet to be decided.

7 Integer programming heuristics

7.1 Introduction

The integer programming heuristic is roughly the same whichwas applied in [1]. Initially, we optionally use a branch and cutalgorithm with dynamic column generation at each node in thebranch and cut tree where the user decides which amongst thevariable types xS, xMS, xUS, xSS’ and xl should be required to beinteger. During the branch and cut phase the variables yfl and yklare given a temporary upper bound equal to zero.

The variables of the types xS, xMS, xUS, xSS’ and xl which are notrequired to be integer in the branch and cut phase are, togetherwith the path and ring variables, fixed sequentially. For variablefixing the variables xS are given first priority, and amongst thesevariables the ones that are higher in the SAP hierarchy are givenhigher priority. Variables of type xSS’ are given second priority,variables of types xMS and xUS are given third priority, and vari-ables of type xl are given fourth priority.

The path and ring variables are generated dynamically, so theyare always fixed sequentially with fifth priority.

For large problems it may demand too much resources torequire the xl variables to be integer in the branch and cut pro-cess. On the other hand, using the variable fixing heuristic forthe xl variables may imply a significant underestimation of tracelink costs. We therefore apply trace capacity adjustment.

7.2 Trace capacity adjustment

We assume that we have arrived at a stage where all variables ofthe types xS, xMS, xUS, and xSS’ are integer. We remove the tem-porary upper bounds on the variables yfl and ykl, run the LP, andcheck for every trace link l the value of xl. If xl = 0, ykl = 0 andyfl = 0, we set upper bounds 0 on the variables xl, ykl and yfl and


classify trace link l as excluded. If 0 < xl < threshold or yfl > 0or ykl > 0 (where threshold is a parameter between 0 and 1), weadjust pfl to pfl xl + pfl yfl if (18) is satisfied with equality, andpkl to pkl xl + pkl ykl if (20) is satisfied with equality. Then werun the LP again.

When a variable xl is given a lower bound 1, we set pkl = pfl = ∞.Furthermore, when all xl have become integer, all xl which havebecome 1 are given lower bound 1 (accompanied by a corre-sponding upward adjustment of p-s), and all xl which havebecome 0 are given upper bound 0. Then a new optimization iscarried out.

Capacity adjustment is currently executed only once. It may,however, be repeated several times. It is also possible to executecapacity adjustment before all variables of the types xS, xMS,xUS, and xSS’ have become integer, but this has not been imple-mented.

8 Acknowledgement

The author wishes to thank Øyvin Eriksen who has contributedmany ideas during the development of the algorithms and whohas programmed the algorithms for PC.

9 Reference

1 Lorentzen, R. Mathematical model and algorithms used inthe access network planning tool FABONETT. Telektro-nikk, 91 (4), 135–139, 1995.


Ralph Lorentzen is Research Scientist atTelenor R&D, working with CommunicationsNetwork Planning. His interests concentrateon applications of mathematical pro-gramming.



Status


International Research and Standardization Activities in Telecommunications

Editor: Per Hjalmar Lehne


As a follow-up from the previous issue of Telektronikk(3/4.1997) where four ACTS (Advanced CommunicationsTechnologies and Services) projects were presented (CRABS,OPEN, MoMuSys and SINUS), this issue of the Status sectioncontains articles on the ACTS program and on Telenor’s partici-pation in general. Because the ACTS programme probably isthe most important scene for setting the future telecom agenda,we feel it is important to focus on both the work, the results andhow it is organised.

In the first article, Dr. Rolf B. Haugen, manager of Telenor’sexternal relations, presents the ACTS programme, how it isorganised, and makes short descriptions of the projects whereTelenor participates. The ACTS programme is now in its thirdand last phase. After the third call for proposal has beenfinalized some 200 projects have been launched.

The ACTS programme does not only fund specific technologi-cal projects aimed at system design and so on. The so-calledhorizontal actions are important to disseminate results and toconnect the different projects together. The InfoWin project isdescribed by Mr. Thorbjørn Thorbjørnsen. This project is meantto be the ACTS Information Window, allowing informationflow from the projects to the outside world as well as giving theoutside world an opportunity to look into what is happening inACTS. InfoWin publishes on the web, as well as news clips,bulletins and thematic issues. It is also responsible for the ACTSYearbook.

A lot of standards work and work relating to the use ofstandards is going on outside the large and well known organi-sations (e.g., ETSI1, ITU2 and ISO3). In the final and thirdarticle of this issue, Mr. Tor M. Jansen presents FERT, whichstands for “Forum for European R&D in Telecommunications”.The goal of FERT is basically to provide strategic guidance inthe European telecommunications development. The role ofthese types of organisations and projects is significant in the co-operative process in R&D and standardisation.

149

IntroductionP E R H J A L M A R L E H N E

Telektronikk 1.1998

1 European Telecommunications Standards Institute2 International Telecommunications Union, a UN-body3 International Standardisation Organisation

Interactive Digital Multimedia Services

CRABS Cellular Radio Access for Broadband Services

MAESTRO Maintenance System based on Telepresence for RemoteOperators

CUSTOM TV

VIS-à-VIS Fitness for Purpose of Videotelephony in Face-to-Facesituations

Mobility and Personal Communication Networks

MoMuSys Mobile Multimedia Systems

SAMBA System for Advanced Mobile Broadband Applications

SINUS Satellite Integration into Networks for UMTS

STORMS Software Tools for the Optimization of Resources in MobileSystems

High-Speed Networking

ASICCOM ATM Switch for Integrated Communication Computation andMonitoring

CA$HMAN Charging and Accounting Schemes in Multi Service ATMNetworks

EXPERT Platform for Engineering Research and Trials

JAMES Provision of European Networking Facilities (PEN)

NICE National Hosts Interconnection Experiment

REFORM Resource Failure and Restoration Management in ATM-based IBCN

SMASH Storage for Multimedia Applications Systems in the Home

TRUMPET TMN's Regulations and Multiple Providers Environment

Photonic Technologies

BLISS Broadband Lightwave Sources and Systems

MEPHISTO Management of Photonic Systems and Networks

OPEN Optical Pan-European Network

ACTUAL Application and Control of Widely Tuneable Lasers

Quality, Security and Safety of Communication Systems and Services

RETINA An Industrial-Quality TINA-Compliant Realtime DPE

Horizontal Actions

INFOWIN Multimedia Information for National Hosts

OPTIMUM Optimized Network Architectures for Multimedia Services

TERA Techno-Economic Results from ACTS

INFOBRIDGE The Bridge from ACTS to the outside world

Table 1 ACTS projects with Norwegian participation

Per Hjalmar Lehne is Research Scientist atTelenor Research & Development, Kjeller.He is working in the field of personal com-munications, with a special interest inantennas and radio wave propagation forland mobile communications.



1 Introduction

ACTS is an abbreviation for ‘Advanced Communications Tech-nology and Services’ and is part of the 4th framework pro-gramme in EU. The total budget is about 670 MECU whichcorresponds to 5 % of the total framework budget. It is a directsuccessor to the previous RACE-programme, known to manyfor its pioneering work within ATM. ACTS is divided into three(time) phases, each starting with a ‘call for interest’. At present(end 1997) we have just entered the last phase, which meansthat there is about two more years to go. During the first twophases about 150 projects have been launched, with the thirdcall this number will increase to about 200.

ACTS was established on 27 July 1994 by a European Councildecision, the objectives being “… To develop advanced commu-nications systems and services for economic development andsocial cohesion in Europe, taking account of the rapid evolutionin technologies, the changing regulatory situation and opportu-nities for development of advanced trans-European networksand services ...”

There has been a clear shift in technology focus from the earlyRACE-programmes (RACE I and RACE II) to ACTS. Theobjective of RACE was to bring forward necessary technologyfor broadband communications (ATM), whereas ACTS is ori-ented towards end-users of advanced communications. Much ofACTS research is thus linked to trials and pilots of the thusdeveloped technologies. In this context photonics is an exemp-tion; it is commonly recognized that more fundamental researchis still needed within this area in order to obtain cost-effectivecomponents. Hence, ACTS supports several research projectsdevoted to optical components and systems.

Formal decisions to be taken in ACTS are discussed in ACTSManagement Committee (AMC). In AMC all EU/EEAcountries are represented by two delegates, appointed by theirrespective governments. In the Norwegian case, one delegatecomes from the Research Council (NFR) and the other fromTelenor, a rather typical combination. AMC is an advisorygroup for the Council, but to my experience, its professional(i.e. project-related) advice has always been followed.

One of the most important tasks of AMC is to approve newprojects. The projects are, of course, evaluated on the groundsof their technical merits, which certainly give strong guidancefor the final approval. More than 90 % of the projects areapproved on this basis. Occasionally there are nevertheless‘political’ arguments for choosing one project to another. Anythus unresolved dispute in AMC will finally go to formalvoting. This is usually not in the interest of Norway (and EFTAcountries) since we have no voting rights. Of the above men-tioned three phases of ACTS, only the first one applied formalvoting for final approval of the projects; in the succeedingphases agreements were reached based on consensus.

Although research and technological development is the mainfocus of ACTS, the Council has opened for certain supportmeasures and concerted activities. These are generally known as‘horizontal actions’. Horizontal activities might be of varioustypes like encourage practical experimentation, help dissemi-nate results, promote synergies, inform external interest group,assess socio- and techno-economic factors, etc. Some projectsare directly placed under the ‘horizontal action’ label like Info-

win and Optimum, while other activities are placed in researchproject pertaining to other domains. One example here is theproject Nice that belongs to ‘high speed networks’. I will comeback to these projects later.

National Host (NH) is another concept closely associated withACTS. The very idea behind NH stems from the notion thatACTS focuses on demonstrators and piloting. Hence, the Com-mission sent an invitation to all the EU/EEA members to pro-vide infrastructure and projects facilities, called National Host,for the ACTS projects to come. The rationale was that by offer-ing such an infrastructure, the respective countries wouldqualify to run corresponding ACTS projects, sort of a ‘tendersituation’ for ACTS projects. In practice, this ‘tender idea’ wasnot really launched, but one (or more) NH was neverthelesscreated in every participating country.

NHs are today established in more than 20 countries andsupport practical experimentation of advanced communicationsat national and European level. They are interconnected withcommercial services like ISDN and Internet in addition to ex-perimental services like ATM (through the James network). Ontop of this, the NHs have agreed to operate a defined set of linkservices, both standardized as well as leading-edge services farfrom maturity. These link services support all communicationsneeds, from e-mail to multimedia mail, video conferencing toco-operative work, high-speed file transfer, multi-site con-ferences and meetings, etc.

The National Hosts are jointly organized in National HostsForum which meets regularly, plans major conferences anddemonstrations, discusses common problems and makes in-formal agreements.

2 Call for interest

A ‘call for interest’ starts with an invitation to submit proposalsfor projects within a predefined set of tasks. The tasks aregrouped into a number of areas, called domains. In ACTS weare talking about six domains to be further dwelt upon below.When proposals have been submitted, they are evaluated by agroup of independent experts. The experts are grouped into‘panels’; each panel with responsibility of evaluating proposalswithin one particular domain.

The chairman of each panel presents the result of the evaluationto AMC. This is usually done through two consecutive AMC-meetings. The first one is devoted to panel presentations withpossibility of (short) questions for clarifications, whereas thenext one opens for more in-depth ‘cross examination’ of thepanels. After these ‘professional’ discussions of the projects,AMC normally needs one or two further meetings until thewhole package is approved.

The above mentioned procedure is a rather general one in EU. Itmight seem long and bureaucratic, but at least in case of ACTS,the secretariat in Brussels runs it very smoothly. As an examplefrom last call: Final date for proposals was 28 September, atwhich time 195 proposals had arrived. Evaluation started imme-diately and for the next AMC-meeting, 23 Octobre, we found onour table several printed documents containing project descrip-tions, evaluation reports (2 volumes) and executive summary(including statistics). Not bad for a three weeks period! The

The EU Research Programme ACTSA General Description with Focus on Telenor ParticipationR O L F B . H A U G E N


final approval was done by AMC on 25 November; hence theelapse of time from reception of proposals to approval of thenew projects was two months.

3 Concertation

ACTS is an integrated research programme. The overall result itachieves will be greater than the sum of the individual projects’results. Hence, quite an effort has been made to obtain synergiesfrom projects belonging to different domains, leading to con-cepts like chains and concertation. A chain is a ‘horizontal’grouping of projects that contain elements of similarities, nomatter which domain they belong to. In certain cases the pro-jects may also contribute to the work of another, and some pro-jects choose to support several different chains. This leads to aneed for internal concertation within the programme. In thiscontext concertation may be defined as: ‘the bringing togetherof people and their organizations/projects, to profit from eachothers’ knowledge and experience, to coordinate or encouragethe convergence of ongoing work on the most important issues,and so to build a broadly based consensus on the way to realizeadvanced communications in Europe’.

Concertation within ACTS centres on three main groupings:

• Plenary Meetings of all project managers, typically 3 or 4times per year

• Technology oriented R&D domains, meeting in parallel aftera plenary and focusing on the main technical areas of the pro-gramme

• Objective Driven Chains, each supporting a defined objectiveand contributing to a specific result (for example guidelines).

Through a Concertation Steering Committee, an ongoing effortis made to keep the work of individual chains and domainsaligned both inside and outside of the Programme. Sometimesthis may lead to changes in timing and priority for individualactions within the projects themselves.

3.1 Chains

For organizational convenience, individual chains are groupedinto five main groups:

• BA: Broadband Access Networks: Economics and Evolution

• NI: Network Level Inter-operability and Management

• SI: Global Service Integration

• GA: Generic Access to Applications (User perspective)

• XB: External: Broadening of Awareness (Programme Level).

BA addresses issues arising from different topologies of accessnetworks, their potential for evolution, economics, integrationissues, etc.

NI deals with major issues of interworking and integration,including signalling and interoperability, roaming and locationfunctions to provide mobility in both fixed and cellular net-works. The work aims to ensure end-to-end quality of serviceacross multiple network operators and service providers in acompetitive environment.

SI seeks to decouple the characteristics of services from those ofthe underlying networks, for example that service can be pro-vided irrespective of access network architectures. The workwill also serve to ensure continuity of services as the underlyingnetwork technologies evolve.

GA works in a similar way on the application level, to ensurethat generic applications can be supported across differentindustry sectors and organizations, irrespective of the differentplatforms and terminal equipment.

XB chains are formed to address specific needs for broadeningawareness at Programme level, whenever there is no clear initia-tive taken by any single project or chain. That is, this group ofchains represents overall Programme interests.

3.2 Guidelines

Concerted efforts of Programme projects may take on manyforms, as for example realization of common demonstrators.More frequently, the concerted actions will result in guidelines.Guidelines are concise documents targeted towards outsideusers. They provide the basis for consultation and systematiccollaboration with related research and policy initiatives withinEU, the member states and third countries, internationalindustry groupings, standardization bodies, etc. The guidelinespresent various form for strategic and/or specific technicalrecommendations of the ACTS programme.

Guidelines will typically point to techno-economic feasibility ofalternative technological solution under specific circumstances,and so contribute to a reduction of options for product and ser-vice deployment.

3.3 Horizontal projects

As mentioned earlier, there are in ACTS several projects de-voted to ‘horizontal actions’. Most of these will be found in thedomain named ‘Horizontal actions’ but some are also placedwithin one of the other domains. We will in this section con-sider three projects that all have played an important role in dis-seminating results both inside and outside the programme:

• James (Joint ATM Experiment on European Services)• Nice (National Host Interconnection Experiments)• Infowin (Multimedia Information for National Hosts).

Only the last one, Infowin, belongs to the Horizontal Actionsdomain.

3.3.1 James

James belongs to the Networking domain and has an objectiveto test and evaluate new ATM-based broadband experimentalservices and applications throughout Europe. As a research pro-ject James aims to demonstrate the utility and added-value ofadvanced ATM networks and contains tasks like:

• ATM VP Bearer Service• IP over ATM• ATM Switched VC Service• LAN Interconnection Service• SMDS over ATM Service• Network Management.


However, in addition to the above mentioned areas, which areresearch areas in their own merits, James has (had) the im-portant function of providing ATM infrastructure to severalother ACTS projects. In particular, the various National Hostsare tied together by the James network, as depicted in Figure 1.In this sense James has been a very important horizontal projectwithin the ACTS programme. Members of the James project arethe major tele-operators in Europe that, in fact, have subsidizedthe usage of the network.

The James projects will unfortunately be closed by end ofMarch 1998, after which time broadband field trials in ACTShave to be based on commercial solutions.

3.3.2 Nice

The objective of Nice is to assist the National Hosts to providecommon, international broadband applications on an ATMinfrastructure. It belongs to the Networking Domain. Theproject concentrates on teleconferences and distributed meetingsassociated with ACTS and other EU R&D activities. The Natio-nal Hosts are the prime vehicle for delivering these experimen-tal services.

Nice is thus integrating systems so as to enable groups of NHsto provide common, international broadband teleconferencingand fast asynchronous services based on ATM. In 1996 theparticipation in Nice was extended to Central and EasternEurope (CEE) and the Newly Independent States of formerSoviet Union (NIS).

Examples of activities are:

• Advanced Broadband summer school 1996: 22 sites withmore than 1000 people

• Distributed meeting for G7’s GIBN project

• Linking Russian and Western partners in workshops.

3.3.3 Infowin

The objective of the Infowin project is to provide the ACTSInformation Window. This window allows information to flowfrom ACTS projects to the outside world, and also helps theoutside world to be visible to the ACTS projects.

Infowin provides support for the internal communications ofACTS, within the project as well as between projects and theCommission. The project is structured around information andmarketing, editorial and dissemination, on-line as well asthrough other means. Updated information is always to be foundon the Web-site: www.infowin.org/.

Type of information from Infowin is:

• Newsclips: Info published and distributed via WWW ande-mail twice a month. Information about ACTS projects andnew technology developments.

• Bulletins, appearing four times a year. Cover special researchtopics of ACTS or other topics of current interest, importantevents, articles, and publications.

• Thematic Issues published quarterly cover special researchtopics of ACTS or other topics of current interest. A Thema-tic Issue can be a regular publication or it may be a workshop.

Oslo

Helsinki/FinnetHelsinki/TelecomFinland

Copenhagen

Vienna

Milan

Madrid

Lisbon

Dublin

LondonAmsterdam

Köln

Zürich

Paris

Brüssel

Athens

Reykjavik

Helsingborg

Luxembourg

Tel Aviv, Israel

Figure 1 Points of presence of James

Distributed trialsand events

National hostcountry A

National hostcountry B

ATM satellitelinksNew common

services fromthe NHs

Figure 2 Nice assists the NHs in their service experiment


4 Domains

The total project budget of ACTS is about 630 MECU, whichcorresponds to NOK 5 billion. Every project is assigned to onesingle domain as their ‘home base’. As already mentioned, thereare five technology-oriented domains and a sixth housing thosehorizontal projects which do not belong to one of the techno-logy oriented ones. The domains are:

• Interactive Digital Multimedia Services (162 MECU)

• Photonic Technologies (104 MECU)

• High Speed Networking ( 75 MECU)

• Mobility and Personal Communications Networks (115 MECU)

• Service Engineering, Security and Comm. Management (TMN) (143 MECU)

• Horizontal Domain ( 31 MECU)

The figures in brackets represent the initial distribution of thefunding amongst the various domains. The final numbers, as oftoday, show a small shift in the favour of Multimedia Servicesand High Speed Networking.

The number of Telenor participating projects, to be discussedbelow, might seem a bit ambitious. But since there is a mix ofprojects from all three phases of ACTS, some projects (fromphase 1) are about to terminate, whereas the projects from thethird call are on the point of starting up.

5 Projects with Telenor participation

5.1 Domain 1: Interactive Digital MultimediaServices

The tremendous interest in real-time interactive multimediaservices indicates a large potential market for these services.Hence, this domain has attracted a large amount of project pro-posals, many with a very high professional quality. The resulthas been an approval of projects that exceeds the initial budgetby about 20 MECU.

The domain has been subdivided into the following three sub-domains:

SD1: Multimedia Content manipulation and management

SD2: Interactive Distribution and Transmission

SD3: Server based Multi Media Services.

Telenor participates in four projects within sub-domain SD1:

• Momusys: Mobile Multimedia Systems

• Custom TV

• Maestro: Maintenance System based on Telepresence forRemote Operators

• Vis à Vis: Fitness for Purpose of Videotelephony in Face-to-Face Situations.

Momusys started already in the first phase of ACTS and ishenceforth in its third year of running. An extension (Momusys-Ext) was approved at the third call. The objective of the project

is to develop and validate possible technologies for audio-visualfunctionalities for mobile systems. The work has been heavilybased on the standardization work in ISO MPEG-4 as well asITU and ETSI; in fact, Momusys is a provider of software pro-grams to the MPEG work. The project has also developed an‘MPEG-4 terminal’ that is used in the field trial. The project isprogressing well with many promising results.

Custom TV has the main objective to develop, demonstrate andvalidate technology for user-friendly screen customization andinteractive program selection in a multimedia broadcast en-vironment. The project will demonstrate the evolutionary pathfrom MPEG-2 to MPEG-4 and MPEG-7. Custom TV is a phase3 project, starting end 97 / beginning 98.

Maestro aims at developing the use of telepresence for main-tenance, installation and repair of mechanical equipment. It isparticularly dedicated to the training of complex maintenance/installation scenarios for remote users. The resulting technologyshould enable users to be trained by connecting to a ‘VirtualShowroom’ where they can learn maintenance proceduresthrough computer-augmented video-based telepresence. Theproject is progressing well and the demonstrator is about to bestarted.

Vis à Vis is a third call project, starting at the beginning of 1998.The project aims at examining videotelephony for communica-tion in companion with face-to-face communications.

Telenor is attending only one project in sub-domain SD2:

• Crabs: Cellular Radio Access for Broadband Services.

Crabs is a project of 1017 man months divided among 9 part-ners and 3 associated partners and with Telenor as a prime con-tractor.

The main objective of Crabs is to develop and demonstrate acellular radio system to provide broadband interactive multi-media services, e.g. digital television. The system operates inthe 40 GHz frequency band, and field trials will take place infive European countries: Czech Republic, Greece, Italy, UK andNorway.

Figure 3 The cellular broadband network of Crabs


5.2 Domain 2: Photonics technologies

The ultimate goal for a European Broadband Infrastructure is anetwork based upon optical fibre technology, i.e. a transparentoptical network. The focus of interest in ACTS is to optimizethe use of photonics by analyzing network as a whole, ratherthan just using optics for individual point-to-point links. Pend-ing breakthrough is within switching/routing functionality,optimal balance between optics and electronics, multiple wave-lengths as a means for routing and multiplexing, network man-agement, etc.

Telenor is participating in four projects in the photonics domain,addressing several of the above mentioned issues:

• Open: Optical Pan-European Network

• Bliss: Broadband Lightwave Sources and Systems

• Mephisto: Management of Photonic Systems and Networks

• Actual: Application and Control of Widely Tunable Lasers

The last project, Actual, is a new project starting in 1998.

Open aims at studying the feasibility of an Optical Pan-Euro-pean overlay Network by interconnecting major European citiesby high-capacity optical fibre links. The nodes will use multi-wavelength 4x4 cross-connects with wavelength routing stages.

The potential capacity of each fibre link will be upgradable to atleast 40 Gbit/s, each channel supporting STM-16 SDH or higherdata-rate transport service. The proposed approach relies onextensive use of WDM for both transmission and routing pur-poses.

There are two field trials, one between Norway and Denmark,and one between Paris and Brussels. The Nordic field trial useslinks between Arendal and Thisted/ Hjøring in Denmark withfour-wave mixing and very long repeater spacing.

Mephisto considers network management (TMN) to an ad-vanced all-optical core network. It exploits wavelength divisionmultiplexing (WDM) for transmission and routing. The projectdevelops a generic information model for operation and man-agement of optical networks and their components.

Bliss has as its main objective to bring key advanced com-ponents for optical networks to full maturity. Demonstrationsof practical applications are carried out within the project aswell as in other ACTS projects. The project will demonstrate a4 x 2.5 Gbit/s WDM long haul transmission system including across-connect where the influence of specific device propertiesare studied. A main focus is also on the implementation ofoptical receiver chips in Access Networks, where a PON andan ATM ring field trial is performed. The latter is based on theAline concept of Siemens/Telenor.

Actual is starting up in 1998 (from the third call). It will developa methodology for control and management of widely tunablelasers for WDM networks. The lasers should be capable ofhandling 128 channels with a 0.4 nm channel spacing. NTT inJapan is participating in the project. Their focus is on the controlpart of the laser.

Circuit layer

DXC

Digital path sub-layer

Optical path sub-layer

Optical transmission medium layer

Switch

DXC

Switch

OXC OXC

Bea

rer

netw

ork

Sco

pe o

r th

eO

PE

N p

roje

ct

Tran

spor

t lay

ers

Figure 4 Open Network Concept

Siemens 1

Tx

Rx

STM 1test

Siemens 2

Tx

Rx

STM 1test

Rx

Tx

Rx

Aline

Rx

~~~

~~~

Tx

Rx

Tx

Rx

Rx~~~

~~~Aline

Tx

Rx

Kjeller - Oslo (Siemens): 43.28 km

50/50

Siemens 4

Siemens 3

90 %

10 %10/9050/50

50/50

Figure 5 Bliss trial in Norway


5.3 Domain 3: High Speed Networking

The Race programmes focused a lot on broadband networkingprinciples like ATM. At this stage ACTS wants to ensure thathigh-speed networks will interwork at all levels and will satisfythe user needs and demands. Projects in this domain will thuscontribute to broadband systems made of different technologiesand provide a platform for advanced multimedia services. Thetrials and experiments will allow a verification of the techno-logies, the user acceptance of the technologies, the Quality ofService concepts and the compliance with standards and regula-tions.

Telenor participates in the following 8 projects within thisdomain:

• Asiccom: ATM switch for Integrated Communications,Computation and Monitoring

• Ca$hman: Charging and Accounting Schemes in Multi-Ser-vice Networks

• Expert: Platform for Engineering Research and Trials

• James: Joint ATM Experiment on European Services

• Nice: National Host Interconnection Experiments

• Reform: Resource Failure and Restoration Management inATM based IBCN

• Diana: Demonstration of IP and ATM Networking Applica-tions

• ITUnet: International Trials with Users and Networks fromEuropean Testbeds.

In this listing the first four projects belong to phase 1 of ACTSand will be terminated in the first half of 1998, Reform is aphase 2 project (i.e. terminating in 1999) and Diana and ITUnetare phase 3 projects, starting in 1998.

James and Nice have been described in section 4 and will not befurther dwelt on here.

Asiccom realizes an ATM Gigabit switch on a single-chip, de-veloping the architecture for an effective support of a broadrange of services, and implementing a Gigabit ATM testbed.

Ca$hman studies the charging and accounting schemes forATM networks. The project develops appropriate pricing

Figure 6 Charging ATM traffic with different tariff parameters


models and their efficient implementation in hardware and soft-ware. Extensive use is made of National Host facilities for vali-dation and for acquiring important user feedback.

Reform has an objective to specify, design and develop a systemwith the necessary functions for ensuring network performanceand availability within acceptable levels. It particularly con-siders mechanisms for fault detection, self healing mechanisms,intelligent routing mechanisms, load balancing algorithms, tomention but a few.

Expert has as its main objective to enhance the ATM testbeds inBasel and Leichelsham. These two testbeds were established inthe RACE-II programme. New features are APON access andan integrated service CPN switch. The platform is used to de-termine critical factors in ATM network performance andcontrol of end-to-end QoS. The Expert platform now contains14 ATM switches, and a variety of interworking units likeATM/ISDN and ATM/ Frame Relay interworking units asshown in Figure 7.

Diana is a starting project that specifies and provides a genericnetwork infrastructure involving ATM and next generation IP.

ITUNet is based upon ideas coming from Telenor. It aims atexperimenting with several broadband services to residentialusers using e.g. xDSL. It also offers an innovative network solu-tion based on inverse multiplexing of ATM over VDSL, usingtwisted pair access networks.

5.4 Domain 4: Mobility and Personal Communi-cations Networks

The projects within this domain cover three sub-areas:

• Mobile services• Mobile/wireless network platforms• Enabling technologies.

Telenor only participates in the second sub-area, the networkplatforms.

There are two different types of platforms considered in ACTS,the UMTS (Universal Mobile Telecommunications System) andthe WLAN/MBS platform. Here WLAN stands for WirelessLocal Area Network and MBS Mobile Broadband System.

ATM PON

ATMbackbone ring

2.5 Gbit/s

Basel

TMN station

Router

ONUTBTB

ONUTBTB

ATM(JAMES)

Leidschendam

2 Mbpsmapper

FRIWU

N-ISDNIWU

MEGACOM

FrameRelay

N-ISDN

N-ISDNgateway

Figure 7 The Expert platform


The main characteristic of UMTS is a hierarchical cell structuredesigned for support of a wide range of multimedia broadbandservices within the various cell layers. Use is here made ofadvanced transmission and protocol technologies.

The driving force for introducing WLAN in an office environ-ment is the proliferation of portable and laptop computers andthe potential savings in avoiding wiring or re-wiring of build-ings. Hence, next generation mobile systems must incorporatean integrated WLAN capability.

Telenor participates in the following three projects:

• Sinus (Satellite Integration into Networks for UMTSservices)

• Samba (System for Advanced Mobile Broadband Appli-cations)

• Sumo (Satellite UMTS Multimedia Service Trials OverIntegrated Testbeds).

Needless to say, Sinus and Sumo belong to the UMTS platformand Samba to the WLAN/MBS platform.

Sinus’ main objective is to validate the UMTS segment fordifferent satellite interfaces and interworking with terrestrialcomponents. The project also assesses the economical andtechnical feasibility of providing services through the UMTSsatellite component. Sinus will define and demonstrate an end-to-end communication network. The trials will implement inter-segment hand-over (satellite–terrestrial), mobile managementcall routing, and resource management.

Sumo is a ‘third call project’ starting in March 1998 with aplanned duration of 22 months. It is heavily based on Sinus andaims at identifying and demonstrating service support and net-work control for the satellite segment of UMTS. A testbed willbe developed, with features like multimedia terminals, satelliteaccess terminals, satellite channel emulator, satellite inter-ference simulator and a live satellite channel. The Sumo trialsaddress Interoperability between terrestrial UMTS networksand various satellite systems (LEO; MEO; GEO), capacity ondemand and validating the GRAN concept (i.e. independence ofthe physical access scheme (CDMA, FDMA, TDMA).

Samba develops an MBS trial platform consisting of two basestations and two mobile stations operating in the 40 GHz fre-quency band. The millimetre-wave transceiver as well as theantenna are developed within the project. Each mobile stationoffers a transparent ATM bearer service up to 34 Mbit/s.

5.5 Domain 5: Service Engineering, Security andComm. Management (TMN)

This domain focuses on

• how the inherent intelligence in the network maybe employed to provide flexibility and open com-petition in the provision of services

• means for managing and administrating end-to end communi-cation systems which span many independent network opera-tors and service providers.

The emphasis is on applying the best techniques for systemspecifications and corresponding software development with theaim of creating open platforms.

Telenor participates in one project in the service engineeringsub-area:

• Retina: An Industrial-Quality TINA Compliant Real-TimeDPE.

Retina develops and demonstrates a TINA compliant Distri-buted Processing Environment (DPE) based on CORBA. It willdemonstrate a BVPN service V1 application to be run in a wide-area distributed environment. Experiments are based on localATM networks at each demo site, which are connected to theirrespective National Hosts in Norway and Italy.

5.6 Domain 6: Horizontal Actions

As mentioned before, there are in ACTS several projects thatare of common interest to the Programme as a whole. Threesuch projects were discussed in section 4 – James, Nice andInfowin. Only the latter, however, is part of the domain ‘Hori-zontal Actions’ that we are now going to discuss.

The projects in this domain are grouped in the following sub-areas:

Figure 8 The Optimum platform

Demand for the TelecommunicationsServices

Services Architectures

DB

Revenues Investments

OA&MCosts

Geometricmodel

Cashflows,profit & loss accounts

First installedcost

Life cyclecost

NPV IRR

Economicinputs

Year 0 Year 1 Year n Year m

Paybackperiod


• Techno-Economic and Social Aspects• Concerted Actions and Consensus Development on Guidelines• Telework and Electronic Commerce for SMEs• Dissemination, Exploitation and Broadening Participation.

Telenor is at present participating in the following four projects:

• Optimum: Optimized Network Architectures for MultimediaServices

• Infowin: Multimedia Information Windows for NationalHosts

• Tera: Techno Economic Results from ACTS

• Infobridge: The Bridge from ACTS to the Outside World.

Here the last two projects come from the third call, starting at thebeginning of 1998, and to some extent one can say that Optimumevolves into Tera and Infowin into Infobridge. Referring to thesub-division above, Optimum/Tera belong to the Techno-Econo-mic as well as the Dissemination sub-domains. Infowin/Info-bridge certainly belong to the Dissemination sub-domain.

Optimum’s objective is to establish guidelines for the intro-duction of advanced communications network and multimediaservices in a competitive environment. That is to say, Optimumconsiders the telecommunications access network, compares thecost (including forecast) of different technologies, like optics,copper, radio, and give guidelines for further evolution of thenetwork. The architecture for a specific set of services is beingdefined and combined with traffic, demand and tariffs. Riskevaluation for various scenarios is also included in the project.

Telenor is the prime contractor of the project.

Tera is the continuation of Optimum, which will terminate in1998. Its objective is to support consolidation of deploymentguidelines and their dissemination. Tera will also perform techno-economic evaluation of outputs from various ACTS projects

Infobridge is a continuation of Infowin and intends to dissemi-nate and promote results from the ACTS programme. This willbe achieved by developing an Infospace, publication of regularnews-service, publishing CD-ROM, etc.

6 Concluding remarks

Telenor has participated in altogether 24 ACTS projects duringa 5 – 6 years period (plus the project Emphasis, from which wechose to withdraw after one year’s participation). In theAppendix is a listing of all the 24 projects with their Telenor

contact person. The experience gained through this collabora-tion has had an important bearing on the professional work andcompetence of Telenor Research and Development; the resultsand knowledge thus obtained have been acquired in anextremely cost-effective way. Projects in the NOK 50 –100 mill. range are not easily financed on a national level.

It is also interesting to follow the ease with which our re-searchers are now taking part in the international researchcommunity. We are, together with our Nordic colleagues,highly appreciated as partners in the various EU projects andare from time to time getting more offers than we can accept.It is also clearly seen that the project consortia we enter intohave been increasingly solid; in the first phase of call for papersin ACTS we had a ‘hit rate’ (i.e. approved projects) of about60 – 70 %, in the last call it was very close to 100 %! Hence, theexperience gained through the ACTS participation has not onlybeen on the professional level; equally important has been the‘education’ of our researcher to be part of, and feel at home in,the international research community. This is also reflected inour role in the projects; in the first phase it was rather unthink-able to go for a project leadership, in the second phase Telenorwas ‘prime’ (i.e. project leader) in two projects (Optimum andCrabs), and in phase three we were prime in two additionalprojects (Tera and Itunet).

The yearly project evaluations, performed by a panel of expertson behalf of the EU Commission, show good results for most ofthe ACTS projects in which we participate. From the last evalu-ation, in January 1998, the Open project got top score on allevaluation points with MoMuSys and Expert very close behind.

7 AppendixOverview of Telenor participation in ACTS projects with contact person:

ACTS Domain ACTS Project Telenor Contact

Interactive Digital Momusys Robert DanielsenMultimedia Custom TV Robert DanielsenServices Maestro Ola Ødegård

Vis à Vis Bjørn HestnesCrabs Agne Norbotten

Photonic Open Torodd OlsenTechnologies Bliss Evi Zouganeli

Mephisto Terje HenriksenActual Evi Zouganeli

High Speed Asiccom Geir MillsteinNetworking Ca$hman Ragnar Andreassen

Expert Harald PettersenJames Svein Tore JohnsenNice Kaare Inge SlettaReform Svein Tore JohnsenDiana Egil AarstadITUNet Einar Edvardsen

Mobility & Personal Sinus Jørn KårstadCommunications Sumo Jørn Kårstad

Samba Stein Svaet

Communications Retina Eirik DahleManagement

Horizontal Actions Optimum Borgar OlsenTera Borgar OlsenInfowin Thorbjørn ThorbjørnsenInfobridge Thorbjørn Thorbjørnsen

Rolf B. Haugen is Chief of Research and Head ofExternal Relations at Telenor R&D. His work in-cludes co-ordination of Telenor activities in the EUresearch programme, EURESCOM and nationalprojects with the Norwegian Research Council, aswell as co-ordination of standardization activities inTelenor. He is a member of the General Assemblyin ETSI and EURESCOM. In the BT-alliance he isresponsible for co-ordinating technology collabora-tions.e-mail: [email protected]

ACTS (Advanced Communication Technologies andServices), established under the Fourth Framework Pro-gramme (1994 – 1998), represents the European Union’smajor effort to support research and development in thefield of Telecommunications. The work within the pro-gramme is carried out in the context of trials to encourage adialogue between developers and users. The ACTS pro-gramme is a truly co-operative challenge that brings to-gether many companies and organisations from all sectorsof the European telecommunications industry in more than150 projects. The success of ACTS can only be achievedthrough the effective exchange of information, not onlywithin the programme, but also across the boundaries of theprogramme. In this context InfoWin, the ACTS InformationWindow, was established with the purpose of adding valueto the information flow between ACTS projects and betweenthe ACTS programme and the outside world.

1 Introduction to InfoWin

The InfoWin project provides the ACTS Information Window(http://www.infowin.org). This window allows information toflow from ACTS projects to the outside world and also allowsthe outside world to see what is happening in ACTS. The Infor-mation Window ensures that ACTS participants keep an up-to-date view of the development of the telecom market and itsneeds, whilst simultaneously ensuring the visibility of ACTSand maximising its impact. InfoWin also provides services forthe internal communication of the ACTS programme.

InfoWin exists to maximise the synergies of the ACTS pro-gramme, and the economies of scope, scale and integrationwhich can be achieved by working together on advanced com-munications. The increased rate of development of advancedcommunications services and implementations brought about bythese synergies will make an important contribution to the de-velopment of the European economy. By maximising theimpact of the work of ACTS, InfoWin supports the develop-ment of the information society in Europe and on a global scale.InfoWin also supports the dissemination of advanced communi-cations concepts and services into all the regions of Europe,ensuring that the benefits can be felt throughout the community,such as in the introduction of teleworking in peripheral regionsand the development of high-speed infrastructure in the coreregions.

The project consortium includes National Hosts, telecommuni-cation companies, academic institutions, computing and re-search centres and specialists on marketing and informationdissemination.

2 How InfoWin works

InfoWin focuses on information content, and follows a scien-tific approach for providing the information presented at theinformation window. The project is structured around the keysteps in the information publication process: informationgathering and writing relevant material, editing the informationin an appropriate way for different target audiences and thepublication and marketing of the information to those audi-ences. The electronic information system activities includedin the project are those necessary to support the informationdissemination.

InfoWin aims its products at different target groups. Theserange from the inner circle of the ACTS community over thegeneral R&D, business and political communities, to the generalpublic at large. The work is based on an in-depth understandingof the different communities that have an interest in the ACTSprogramme and projects. Major contributors to this work areNational Hosts and educational institutions.

The regular products of InfoWin are: Newsclips, Bulletins,Thematic Issues and the ACTS yearbooks (all described inChapter 3). The effort that goes into the production and dis-semination of these publications is structured as:

• Information gathering and reporting (based on origin)

• Editorial work (based on subject)

• Dissemination – marketing and promotion (based on targetaudience).

The next sections will deal with these points in greater detail,starting off with a description of the editorial work of InfoWin.

2.1 Editorial work

The purpose of editorial work is to add value and structure tothe raw information. Value is added by analysing and consoli-dating the information so as to present the information in formsthat are easily accessible and in line with the needs of the in-tended target groups.

Much effort goes into tailoring the publications for the differenttarget groups such as:

• The ACTS community. This community is well aware of theprogramme, has good knowledge of the main content of theprogramme and requires technical and detailed informationregarding ACTS and research activities elsewhere.

• The R&D community in general, such as research institutionsand universities. This community is aware of the existence ofthe European research programmes in various levels of detail.A group that requires detailed, technical information.

• The business community: industry, financial services, ad-ministrations and users. They have to keep up-to-date withnew developments in the advanced communications area.

• The political community: administrations and technical bodiesin charge of implementing policies. The quest for informationis crucial in their forecasting and regulatory roles.

• The public at large. Proper information can improve thegeneral understanding of upcoming new technologies andservices.

The information enhancement pyramid shown in Figure 1 app-lies to the publications of InfoWin, and it depicts the amount ofeditorial work that is put into the different publications. Thematerial closer to the top of the pyramid represents the publica-tions that require the highest editorial effort. The bottom of thepyramid represents material basically dealing with raw informa-tion of the form of project deliverables and reports. On the leftwe find the different kinds of publications represented by thepyramid.

159

InfoWin – The Multimedia Information Window for ACTST H O R B J Ø R N T H O R B J Ø R N S E N A N D C L A U S D E S C A M P S

Telektronikk 1.1998

2.2 The regional representatives – a key mechanism to InfoWin

To support the vast information gathering and disseminationactivities, InfoWin established the regional representativemechanism.

InfoWin aims at bringing services close to the people who needit. To support the vast information gathering and disseminationactivities, InfoWin established the regional representativemechanism. Western Europe has been divided into nine regions,each covered by one or more regional representatives respon-sible for promoting the activities of ACTS and for gatheringinformation on relevant results and activities.

2.2.1 Information gathering by regionalrepresentatives

The objectives of the information gathering activity is to:

• collect information and handle requests for informationcollection

• gather information that directly relates to the ACTS pro-gramme and make this information available for furtherprocessing

• working as technology journalists, cover conferences andmeetings related to ACTS projects and the programme as awhole

• report on ACTS projects, their progress and results.

InfoWin aims to improve the flow of information betweenACTS projects, and between ACTS projects and the outsideworld. The first task of regional representatives is to gather theinformation within the boundaries set by the editorial board ofInfoWin. The regional representatives have therefore to keepabreast with the developments in advanced telecommunicationtechnologies and to understand which relevant research is goingon within their region and in ACTS projects.

2.2.2 Dissemination and marketing activities byregional representatives

The main goal of dissemination and marketing is to deliver theright information to the right audience. Through their close con-tact with the local market, the regional representatives provide agood mechanism to achieve effective dissemination. They alsoreceive valuable feedback or requests for specific informationthrough their contact network.

The target groups of InfoWin have very different requirements.Through the regional representatives, InfoWin carries out large-scale surveys to identify their needs. The surveys are usuallycarried out at concertation meetings. Concertation can be de-fined as the bringing together of people and their projects, toprofit from each other’s knowledge and experience, to co-ordi-nate or encourage the convergence of on-going work on themost important issues. The aim is to build a broadly-basedconsensus on the ways to realise advanced communications inEurope. Concertation takes place both within ACTS and ex-ternally with related initiatives and interest groups representingthe broader communications public.

In ACTS, the concertation mechanisms are organised aroundDomains and Chains. Domains provide internal forums forprojects working on similar technical areas to share ideas andexperiences. Chains are objective driven and more outwardfacing than the Domains, and comprise projects working to-gether on technology development and technology trials.

2.2.3 The Regional Representative Community

In order to make the best use of the experience and knowledgethat exist in the Regional Representatives network, a free-flow-ing information exchange and personal rapport with fellowregional representatives is essential. This open infrastructure ofcontact points allows for rapid exchange of information, andmakes for a global overview of the ACTS programme.


SpecialPresentations

Marketing andPromotion Material

Thematic IssuesBulletins

Newsfeed Production(Newsclips similar to Reuters or AP)

Index Information created by Information ProvidersIndex Information created by automatic means

Full documents deliverables, ACTS Documents,other comm. Documents etc.

Multimedia CDs

Printed or electronicbrochures

Printed or electronicdocuments

Web Documents

Web services

FormattedDocuments

Amount ofEditorial Work

Amount of Information

Figure 1 Information enhancement pyramid

• UK and Ireland

• Nordic countries (Denmark, Finland,Iceland, Norway and Sweden)

• Germany and Austria

• Greece

• Italy

• Portugal and Spain

• Switzerland

• Benelux.

• France

InfoWin’s Regional Representatives are a group of regionalexperts that provide an important interface between the ACTScommunity and the outside world. These ‘local correspondents’perform a dual role in gathering and producing information, andmarketing ACTS/InfoWin and disseminating information.

Through personal visits, attendance of workshops, conferencesand other events, regional representatives establish and maintaincontacts within the ACTS R&D and business communities.

Within each region, the regional representatives operate asteams. Each Region has a main contact person who co-ordinatesand monitors the work in her/his region. The co-ordinatorassigns work to members of the team and is the main contactpoint within the region for enquiries from both inside and out-side ACTS.

3 Products

Most of the InfoWin products are available through the ACTSInformation Window. InfoWin also produces booklets, manualsand CD-ROMs, which are targeted at different audiences and atmanifold events.

3.1 Information Window

The Information Window is a repository of all general informa-tion and public domain results of the ACTS Programme. It re-sides on the WWW and makes full use of a decentralised archi-tecture to allow the Commission, each project, Domain andChain groups to manage their own contributions. InfoWin en-sures the overall coherence of the information window, andmaintains a single, well-structured point of entry. The informa-tion window is a basic resource that supports ACTS concerta-tion, both internally and externally to the programme. It simul-taneously supports the development of working documents inclosed discussion forums, and broadens awareness of ACTSresults through regular newsletters and dissemination initiativeson specific issues.


Figure 2 Homepage of the InfoWin Infospace

List of participants in the InfoWin consortium

Country Organisation Website

D RUS, University of Stuttgart http://www.rus.uni-stuttgart.de/

UK Analysys Ltd. http://www.analysys.com

F Expertel http://www.expertel.fr

I CSELT SPA http://www.cselt.stet.it

D Deutsche Telekom Berkom GmbH http://b5www.deteberkom.de/

D Fraunhofer Institute for Computer http://www.igd.fhg.deGraphics

F INRIA http://www.inria.fr

A Techno-Z FH F&E http://www.newmedia.at/main.html

GR Intracom Hellenic Tele-communications Ele

GR NCSR Demokritos

IS PTT Iceland http://www.simi.is

CH Swisscom http://www.swisscom.com

B Synergetics IT consultants NV http://www.synergetics.be

E Telefonica Investigation http://www.tid.esy Desarollo

N Telenor FoU http://www.fou.telenor.no

UK Sheffield Hallam University http://www.shu.ac.uk

DK UNI-C, Danish Computing Centre http://www.uni-c.dkfor Research and Education

- Multimedia Success Stories: A series of case studies ofmultimedia applications that are commercially available.This thematic issue provides an insight into the generalfactors that contribute to the success of a multimedia pro-ject. Whatever your interest in multimedia might be, thisproduct is meant not only to inspire you, but also to showyou how a vision can be turned into commercial reality.

- Advanced Business Communications in Europe: Theimplementation of new technologies is about to radicallyalter the way companies communicate, both internally andwith the outside world, with customers, subcontractors andsuppliers. This thematic issue comprises case studies ofEuropean Small and Medium sized Enterprises (SMEs) thatmake extensive use of advanced business communicationtechnologies and from whom other SMEs can learn rele-vant lessons.

- Multimedia Broadcast: Provides an overview of EuropeanR&D in the field of interactive multimedia broadcast ser-vices and applications.

- Mobile Communications On-line: This publication exploitsthe pervasiveness of the WWW and the Internet to increasethe awareness of European R&D and standardisation acti-vities in the expanding field of Mobile Communications.Apart from evolution issues, where experts survey the mainresearch topics, this product provides state-of-the-art infor-mation concerning European mobile operators and ser-vices.

- ATM in Europe: Gives an overview of the European R&Din the ATM (Asynchronous Transfer Mode) area. It focuseson the activities, trials, and results of the ACTS Programme,the TEN-IBC Preparatory Action, and other EC-fundedprogrammes.

- Information Brokerage: Gives an overview of EuropeanR&D in the area of Information Brokerage in the context ofElectronic Commerce, focusing on the activities, trials andresults of the ACTS Programme.

• Communication Handbook (in co-operation with the ACTSproject NICE)

The Communication Handbook is a user guide with preciseand pragmatic recommendations for the use of formats andrendering tools. The services provided by InfoWin and NICEare described together with the best way to access them.These services are not restricted to ACTS participants andeveryone is encouraged to try out and test them.

• Bulletin

The InfoWin Bulletin is published quarterly, and is arrangedto coincide with the ACTS Concertation meetings in Brus-sels. It is the in-house journal of the ACTS community and isavailable in various formats: WWW, paper, CD-ROM andfloppy disk. It covers special research topics of ACTS andother topics of current interest, important events, articles, andpublications

• ACTS yearbook – the ACTSxx Products

Each year InfoWin assists in the production of the ACTSyearbook (published in CD-ROM and printed versions). Thescope of this publication is not just to present the yearlyprogress of the ACTS programme, but also to give an over-view of the whole programme, including a description of the


3.2 On-line Information

• InfoWin Infospace (www.infowin.org mirrored atwww.de.infowin.org)

The Infospace is the main entrance to information aboutACTS-projects, Chains, Domains, ACTS in general, NationalHosts, etc. It contains information about the latest news andreviews regarding public domain results and working papers.A screen-dump of the homepage of the ACTS Infospace isshown in Figure 2.

• ACTS Newsclips

The ACTS Newsclips activity produces a bi-weekly columnwith spot news, covering developments in Advanced Commu-nications Technologies and Services. Newsclips are publishedon-line within the Infospace and also via e-mail.

• Thematic Issues

InfoWin Thematic Issues provide in-depth coverage of specialresearch topics within ACTS and other topics of current inte-rest within the area of trans-European telecommunication net-works and the information society. Topics are often user-ori-ented or service-oriented. They are published in various for-mats (paper, CD-ROM, on-line). To date, the following The-matic Issues have been published:

political and social background. The publication is intendedfor all interested parties of ACTS, including ACTS pro-gramme participants, researchers, politicians and the public atlarge which is involved in ACTS through user trials. ACTS97 is the annual technical report of the EU’s research andtechnological development programme on Advanced Com-munications Technologies and Services. The report is publis-hed in seven volumes:

- Brochure: a brief introduction to the ACTS Programme

- Compendium of Practical Experimentation and Trials: anoverview of the experimentation undertaken by ACTS pro-jects. The technical platforms are specified and details onwhere and when the trials are taking place are given.

- Overview: This is an executive summary of ACTS imple-mentation, and the broader context for its results

- Programme Guide: Programme level results, and ongoingconcertation activities within the Domains, Chains andChain groups

- Project Summaries: a summary of each ACTS project

- fACTS Booklet: a handy, pocket-sized booklet containingessential reference information for programme participants

- ACTS 97 CD-ROM: the complete ACTS 97 publications inmultimedia form with additional information on a numberof related subjects.

4 Achievements

The InfoWin projects and services are in great demand, witnessthe high number of monthly hits – on average 200,000 – on theInfoWin servers. There are over a thousand subscribers to theInfoWin Newsclips, which further demonstrates the value of theservice.

InfoWin has received two awards for its work.

4.1 European Telework Award

European Telework Week, initiated by the European Commis-sion in 1995, is an annual event that supports industries, admini-strations and other interested parties in the teleworking arena.

Telework Awards are given to organisations that, in the opinionof the evaluators, have made outstanding contributions to tele-work development in Europe. The Telework Awards are sup-ported by the partners in the European Telework Week initiativewhich include the European Commission, the European Tele-work Development (ETD) project and industry representatives.

There were over sixty nominations for the European TeleworkAwards ‘97. InfoWin received the Telework Award in the cate-gory ‘media coverage’ for its overall coverage of the ‘EuropeanTelework Week’.

4.2 NBNSOFT

NBNSOFT, an e-journal that awards for content and stories,awarded the InfoWin Newsclips – The best “what’s newest onthe Net”. The award was received in July 1996 in the categoryof the ‘newest technology and educational resources’. The

accompanying statement was: “ACTS News-Clips, an informa-tive bi-weekly newsfeed about developments in AdvancedCommunications Technologies and Services (ACTS), coverstories ranging from satellite links in Greece and Norway to thefuture of PC-TV”.


Claus Descamps is Research Scientist inthe Unit of Satellite & Radio Systems atTelenor R&D, Kjeller.


Thorbjørn Thorbjørnsen is Senior Adviserin the Unit of Satellite & Radio Systems atTelenor R&D, Kjeller.



Introduction

In telecommunications,the service providers, the

network operatorsand the telecom-municationsindustry domi-

nate the com-mercial andtechnologicalscene in Europe.The European

Commission ishelping to estab-lish research and

development pro-grammes in many areas,where the activities are

partly funded by the EuropeanUnion (EU). Many of these projects involve, or are directlyrelated to telecommunications. In many areas, the differentactors in the telecommunications sector have common interests.Therefore, there is a need for making these interests influencethe contents and direction of the R&D programmes.

This has resulted in the creation of several co-operative fora.The telecom operators co-operate in ETNO, European Telecom-munications Network Operators. The industry has an organisa-tion called ETIC, European Telecommunications IndustrialConsortium.

FERT is an organisation with membership open to differentsectors like manufacturers, network operators, service providersand users. It is the only organisation in Europe where consensuson strategic guidance to the development of telecommunicationsin Europe is being achieved between the different actors group-ings.

The results and contributions are based on the wide range ofknowledge and experience of the members, and FERT providesimportant input to the EU Commission and other bodies.

The actors use the forum as a platform for promoting andinfluencing directly and indirectly the content and direction ofthe ongoing and future European Union collaborative R&Dprogrammes and contributing to the other European bodies.

Activities

The main activities of FERT is to establish

• Ways and means by which collaborative R&D in telecommu-nications will benefit the evolution of Europe’s informationsociety

• “Common visions” of the evolution of telecommunicationsbased on customer requirements and advances in technology.

FERT members have initiated strategic projects in the area oftelecommunications (CONCORD 2, CONVAIR) for the on-going 4th Framework Programme of EU. The common maingoal of the two projects is to help pave the way for the Informa-tion Society of the future.

CONCORDIA (CONCORD 2) – within the Telematics Appli-cation Programme, has the main task of identifying users’ re-quirements necessary from future communication services andnetworks indicated by the emerging applications.

The main objectives of CONCORDIA include:

• Recording of harmonised results in Infrastructure EvolutionRecommendations (IER)

• Recommendations

• Promotion of the exploitation and use of results

• Collection of feed-back on the results and of the selectedsolutions

• Providing advice and recommendations based also on theresults achieved by the CONVAIR project in ACTS

• Supporting Sector Actors to orient their strategies and tooptimise their support to the Telematics Applications.

CONVAIR – within the ACTS (Advanced CommunicationsTechnologies & Services) programme, has the main task ofdeveloping “Harmonised visions” of EU communicationsperspectives and to identify the key areas that are critical for therealisation of the future Communication and InformationSociety. In particular, CONVAIR aims at preparing outputswhich may be used as planning guidelines for players in ICT(Information and Communication Technology), developingcommon statements on strategic European telecommunicationsevolution. Topics and priorities for future collaborative R&DProgrammes will also be identified. The project’s initial resultsare already emerging. In particular, the approach and a frame-work for the whole study have been defined in detail, a soundbasis for discussion on visions has been set up and the criticalareas and key issues have been listed during the first fewmonths of activity.

The members of FERT are engaged in many projects within theEU R&D programmes ACTS, TELEMATICS and ESPRIT,which are within the 4th Framework Programme.

At present, a main activity of FERT is to establish “CommonVisions” for the 5th Framework Programme.

Structure of FERT

Plenary Assembly

The Plenary Assembly is open to all members of FERT, andhere the members may exchange information and ideas abouttelecommunications development and trends.

Generation and elaboration of guidelines, perspectives andproposals for the Management Board are also important tasks.

FERT Management Board (FMB)

This is the executive body of FERT. It is responsible for theestablishment of Working Groups and projects, and also actionstowards the EU Commission and the public. Presently, it con-sists of ten members from the industry and the network opera-tors. The chairmanship is rotated every six months between the

FERT– Forum for European R&D in TelecommunicationsT O R M . J A N S E N

FERT


Member Groupings represented. In the second half of 1998, Mr.Cordaro of Telecom Italia is Chairman.

Member Grouping

The members of FERT organise themselves into MemberGroups consisting of the actors in the different Sectors of Tele-communications. The Sector of Telecommunications Manu-facturers is already organised in ETIC. The members in theSector of Telecommunications Operators come mainly from theETNO organisation. The Member Groups decide about theirrepresentatives within the FERT Management Board.

Membership of FERT is open to:• European Telecommunication Manufacturers• European Network Operators• European Telecommunication Service Providers• European Users Associations.

FERT as an open forum is prepared to accept membership of allEuropean actors in telecommunications.

Present Members of FERT ManagementBoard

The Board at present consists of representatives from thefollowing organisations:

Manufacturers (ETIC): Network Operators:

GPT (D.J. Cleobury) France Telecom (D. Thebault)Alcatel (P. Goossens) Telecom Italia (G. Cordaro)Italtel (G. Fabri) Deutsche Telekom (F. Wichards)Siemens (K.U. Stein) BT (J. Grierson)Nokia (K. Baughan) Telenor (T. Jansen)

FERT Secretariat

The Deputy Director, Mr P. Polese, heads the Secretariat andthe address of the FERT Secretariat is:

Rue Montoyer 39, bte 6/7, B - 1000 BruxellesTel.: + 32 2 549 08 40Fax: + 32 2 549 08 52/53E-mail: [email protected] site: http://www.cselt.it/webhost/fert/

For more information, either contact the Secretariat or visit theweb site.

FERT plenary assembly

FERTmanagement

board

Workinggroups

FERTsecretariat

Membergroupings

Structure of FERT

Tor M. Jansen is Director of Research atTelenor R&D, Kjeller, with the ExternalRelations (ER) group, and also with theMobile Communications group. He isresponsible for co-ordinating the work inETNO R&D WG, EURESCOM and FERT.
