Details of FlowThru First Year Achievements

This document provides details of the Trial Business Systems defined in FlowThru andthe Components of which they are composed. This is precursored by details of thebusiness model used and the methodology followed in arriving at the system andcomponent models.

This document compliments the more brief first year report of FlowThru.

This document is also available in postscript and pdf formats.

Contents

OVERVIEW OF TRIAL BUSINESS SYSTEMS

ESSENTIAL BACKGROIUND

TeleManagement Forum Business Process Model

TINA Business Model and Reference Points

MAPPING TMF BUSINESS PROCESSES TO TINA BUSINESS ROLES

DEVELOPMENT GUIDELINES DETAILS

Multi-Domain Management Development Process

A Development Process for Reusable management Components

Reuse using Facades

Guidelines for Business Process Analysis

Multi-Domain Management Development using Reusable Management Components

Multi-Domain Management Development using Re-usable Management Components

SYSTEM MODEL DETAILS - TRIAL BUSINESS SYSTEMS

The Fulfilment Business System

System Description

Fulfilment Business Scenarios Overview

The Assurance Business System

System Description

Assurance Business Scenarios Overview

The Accounting Business System

System Description

Accounting Business Scenarios Overview

SYSTEM MODEL DETAILS - COMPONENTS

Subscription Management

Configuration Management- Network Management Component

Network Planning Component

Access Session Control Component

Usage Session Control Component

TINA WebStore Environment

TINA Trouble Reporting System (TTRS)

TMN / IMA-TTS

Network Manager OSF

Fault manager component and simulator

Configuration Management- Connection Management Component

ATM Accounting Component

Service Level Accounting Component

INTEGRATION TECHNOLOGY DETAILS

The TMN/C++ API

Data Bases as an Integration Technology

CORBA-CMIP gateway

Overview of Trial Business Systems

In the reporting period the project plan has been carefully examined and detailed in orderto ensure that the project goals can be effectively achieved within project resources. Thisis achieved by developing guidelines on both development methodologies and integrationtechnology based on a set of Trial Business Systems based on business process flowrequirements and the reuse of existing components.

The Trial Business systems have therefore been chosen carefully to both reflects theneeds of industry as well as to support the goals of the project. The Trial BusinessSystems have been selected to cover the three major business process areas identified bythe TM Forum, in order to demonstrate the widest range of industrial; applicability whileat the same time focussing on specific project goals.

All the trial business systems and component analysis and design activities have used theproject’s development guidelines, and are therefore providing a working case study of theapplication of the methodology. This will be validated by examination of the modelsproduced and through questioning of people who had to generate and understand themodels. Other specific project goals have been addressed by each Trial Business systemas shown in the table in figure 1. The table also shows which components are used inwhich Trial business Systems.

Goals Fulfilment Assurance Accounting

To demonstrateintegratedmanagement

Integrating serviceordering withnetwork planningand networkconfiguration

Integrating networkfault detection withservice level troubleticketing

Integrating networkand service levelusage metering withaccounting.

To demonstrateintegrationtechnology

CORBA Components CORBA-CMIP gateway Workflow

Components used SubscriptionManagmeent,ConfigurationManagement- NetworkManagement, NetworkPlanning

TINA Webstore, TINATrouble ReportingSystem, TMN/IMA-TTS, NetworkManagement OSF, FaultManager Componentand Simulator

Access and UsageSession Control,ConfigurationManagement-ConnectionManagement, ATMAccounting, ServiceLevel Accounting

Reuse andintegrate existingcomponents fromother projects

Prospect, REFORM Prospect, TRUMPET,SUSIE, P.612

Prospect, VITAL,SUSIE, ReTINA

Figure 1: Overview of FlowThru Trial Business systems

Essential Background

TeleManagement Forum Business Process Model

The TMF business model is described in the TMF Telecoms Operations Map [nmf-tom].The primary aim of this model is to provide a reference against which the definition ofstandardised interface between service providers and customer, suppliers or other serviceproviders can be conducted. It was based on surveys of existing providers, and framed soas to enable discussion of industrial agreements without having to expose the possibly

sensitive internal structures of any particular TMF member. A simplified view of themodel is presented in figure 2. The model is partitioned into processes that relate directlyto the customer, to internal service development and maintenance and to the managementof the provider’s networks and systems. The processes are also grouped vertically intomajor service management areas, i.e. the fulfilment/delivery of the service, theassurance/maintenance of the service and the billing/accounting for the service.Individual processes are defined in terms of activities within the process and of input andoutput triggers to the process.

Figure 2: TMF Telecommunications Operations Map

TINA Business Model and Reference Points

The TINA approach to business modelling is to identify a number of business roles anddefine the reference points that exist between them. The TINA business model definesthe following business roles:

• The Consumer role, which takes advantage of services provided by a TINAsystem but without the intention of providing TINA services to other businessroles.

• The Broker role, which enables other business roles to locate service providers.

• The Retailer role, which is concerned with providing services to the Consumerrole.

• The Third Party Provider role, which is concerned with providing services toRetailers or other Third Party Providers, but not directly to Consumers.

• The Connectivity Provider, which owns a network and provides connectivityservices over it to other business roles.

A set of business relationships (see figure 3) is specified between these business roles.TINA Reference Points (RPs) are defined in relation to the business relationships theysupport. All the non-Consumer roles have self referential business relationship supportingthe federation of and business co-operation between these roles.

Bkr Bkr

Bkr Bkr Bkr

Ret 3Pty

3PtyRtR

ConS ConS TConTConTCon

CSLN LNFed

Retailer

ConnectivityProvider

Consumer 3pty ServiceProvider

Broker

Figure 3: TINA Business Roles and Relationships

In a business situation where a TINA conformant system is required to support inter-domain interactions, the different business administrative domains involved may becharacterised by the TINA business roles they play with respect to each other. Thisdetermines the TINA business relationships they have with respect to each other. Theidentification of business relationships then allows inter-domain conformancespecifications to be defined by the amalgamation of the reference points related to thebusiness relationships, plus any service specific interactions required. These referencepoints are defined in segments, with common segments used to cover the core parts ofTINA system functionality. The primary segmentation is between access functionalityand usage functionality. The access segment is concerned with authentication andauthorisation of users, the selection of services and the setting up the context for the useand management of the service. The usage segment is subdivided into primary usagesegments covering the functionality that is the main objective of the service, and ancillaryusage segments that address administrative and management functionality. Thissegmentation of reference point definitions enables any inter-domain reference point tobe defined with the minimum set of functionality needed for the business relationshipsbeing analysed.

Mapping TMF Business Processes to TINA Business Roles

This mapping formed one of the early achievements of the project, having already beenaccepted for publication and also forming the basis of the projects close collaborationwith both TINA and TMF.

Though TINA defines a fairly restrictive architecture, it has been demonstrated thatcertain service control and management concepts can be applied to other frameworks,e.g. Internet services . Mapping the more flexible TMF business model onto the TINAone enables us to determine where specific TINA management solutions can be morewidely applied. It also provides us with an example of how the TMF business model canbe used in the analysis of other management frameworks.

Before examining such a mapping however, the core differences between the two modelsmust be appreciated. Firstly, the TMF Operations Map defines general business processesin existing telecoms businesses. These may be human based processes or automated ones.Part of the intention of the Operations Map is to identify and prioritise which processesthey wish to automate, and therefore which inter-process interactions would benefit fromindustry agreements. The TINA model restricts itself only to reference points that willyield automated interfaces. Also, the TMF Operations Map is concerned only withservice and network management processes, while the TINA reference points coverissues of service and network control as well. TINA also assumes its DistributedProcessing Environment (essentially CORBA) will be used to implement RP interactions,while the TMF Operations Map makes no assumptions about implementation technology.Functionally, TINA management is aimed specifically at managing TINA services(multimedia, multiparty, multiway, mobile) and network resources (connection oriented,broadband), while the TM Forum model is less specific, but is derived from themanagement of more contemporary services and networks, i.e. POTS, Frame Rely etc.TINA also specifically covers information services, while these have probably notinfluenced the initial TMF Operations Map to a large extent. Finally, the TM ForumOperation Map prioritises issues of process interaction and information flow betweenprocesses, while the TINA BM and RPs are focused on the development of detailed RPspecifications, based on other ODP-based TINA specifications, with little direct attentionplaced on information flows.

The basic approach to merging the TM Forum Operations Map to the TINA businessmodel and reference points is to identify which TM Forum processes operate in whichTINA Business Roles. Note that some TM Forum Processes may be present in more thanone TINA Business Role and that some TINA Business Roles may contain no TM Forumbusiness processes. This reflects the relative differences in the concerns of the twobodies, the TM Forum for instance sees little current application for the Broker role inmanagement.

An initial mapping of these TM Forum Business Processes onto TINA Business Roles isgiven in the figure 4.

Consumer

Retailer

Broker

Bkr

Bkr

Bkr

Bkr

Bkr

Ret

TCon TCon TConConS

ConS

3Pty

3Pty

RtR

CSLN LNFed

Connectivity Provider

3rd Party Service Provider

Figure 4: Mapping of TMF Business Processes onto TINA Business Roles

Given the possibility of merging the TM Forum and TINA models, one pressing issue isto align the notation and process used in defining both TM Forum Solution Sets andTINA RPs. Though both aim to define open interfaces between business roles, the TMForum approach is based on analysing business process information flows, while theTINA approach involved integrating component interfaces into suitably modularsegments. A methodological approach to integrating these approaches is addressed inFlowThru, which is liaising with both groups with the aim of achieving an agreement onthis.

Development Guidelines Details

The FlowThru Development guidelines present three ‘elements’ to ensuring successfuland flexible development of multi-domain service management systems, namely: adevelopment process which is customised to support management system componentdevelopment and component re-use; the development of business models capable ofrepresenting the underlying business processes for these systems; and integrationstrategies designed to assist the flexible and timely co-operation of these managementcomponents both within a single domain as well as across domain boundaries to realisemulti-domain management systems.

The guidelines present a categorisation of the types of organisations that influence theoperation of such delivery chains. The guidelines then present the emergent trends inmanagement systems development processes, business process modelling and reusablecomponent development. They also identify several possible management integrationtechnologies and techniques. They then describe guidelines for a development process forreusable management components, a business process representation to supportmultimedia telecommunication management systems and guidelines as to the applicationof two integration technologies to support management component co-operation andinteroperability. The guidelines illustrate how these three elements can be combined tosuccessfully develop co-operative management solutions across service delivery chains.

Multi-Domain Management Development Process

This section proposes a customised management development process. The developmentprocess facilitates both the design of reusable components as well as the overall multi-domain systems development composed of reusable management components. Thedevelopment process indicates where architectural and integration technologies influencethe design of the components and systems. The development process generates therelevant information required by a workflow management system to perform automated,flexible component integration and interoperability.

Open Service Market Busines Requreiments& Service Management Standards/Initiatives

Re-usable Information Objects &Computional Components (e.g. TINA)

Technology Constraints

Identification andSpecification of Objects and

Interaction Diagrams

Identification ofComponents & Interfaces

Mapping and deployment ofComponents onto

Target infrastructure

Implementation,Integration with

available Technologyand Tests

Perform Trial

and Evaluate

Identification ofBusiness Model(s)

And Business Processesexpressed as Use Cases

Requirements Capture

Analysis& DesignModelling

Implementation

Testing

TechnologyConstraints

Choice of developmentarchitecturee.g. CORBA, DCOM

Figure 5: Multi Domain Development Process incorporating system and reusablecomponent development

The FlowThru development process supports both component reuse and analysis ofbusiness processes, as part of a telecommunications management system development,and draws heavily on the Object Oriented Software Engineering (OOSE) developmentmethodology. This methodology is further extended with its application to software reusein, which also benefits from the application of UML notations to this process.

The proposed multi-domain management development process is an incremental processwhich supports the phases of requirement capture, analysis modelling, deign modelling,implementation, testing, deployment and integration. Figure 5 presents the designprocess as a cycle. The inner cycle illustrates the OOSE classical phases of thedevelopment cycle. The main cycle (signified with large circular arrows) identify theactual steps that need to be performed at each stage of the development of themanagement components and systems. The text external to the design process illustratesthe influences and constraints particular to the development of management systemswithin the context of the target implementation environment.

The Development process above exhibits a co-existence of OO development andcomponent-based development methodologies. In the context of the multi-domainmanagement systems, an OO development methodology is used to describe a set ofbusiness processes that will be supported by a number of reusable managementcomponents that will solve specific business problems.

A Development Process for Reusable management Components

Reusable components are typically presented to system developers as sets of libraries, i.e.as a set of software modules and definitions of the individual operations of thecomponent. Thus a component is presented in terms of that component’s design modeland its software. This can cause problems if changes are required in order to reuse thecomponent. Consider, for example a component, which is part of a framework. Theframework may be general, e.g. CORBA Services, or aimed to supporting systemssolving problems in a particular problem's domain, e.g. the TINA Service Architecture.In either case the framework will provide (or assume!) some high level architectural andtechnological guidance on how components can be integrated together and how they cansupport the development of the system. Such frameworks are often considered at theanalysis stage so that the analysis model is structured in a way that accommodates theinclusion of the framework’s components into the design model. This situation isdepicted in figure 6a However frameworks typically only give general guidance on theuse of components, and the suitability or otherwise of individual components insatisfying requirements still needs to be considered in the design process.

For telecommunication management systems development, such a typical componentreuse situation is difficult to apply because there is no commonly accepted frameworkthat supports a suitably wide range of components. Currently this is a problem domainwhere several different, though probably complementary frameworks can be used, suchas TMN and SMFs, CORBA, TINA. The TM Forum has the aim of trying to define thisframework that encompasses these and other suitable architectural and technologicalframeworks, however no such over-arching framework is currently available.

This development process for management component reuse is motivated by the absenceof such a well defined, common framework. Instead it attempts to provide guidance onhow components can be specified in a more self-contained manner that is commonlyunderstood. In this way, decisions about reuse can be made based on the suitability ofindividual components rather than a wider assessment of the suitability of an entireframework. The approach is aimed at making decisions based on the architectural andfunctional aspects of a component rather than its technology. The technology is treated asan orthogonal issue that is handled primarily through the employment of suitableintegration technologies and techniques.

The basis of the approach for reusable components is that components are not presentedjust as units of design and software, but should be packaged together with the analysismodel of the component, rather than being strongly integrated into a specific componentframework. If the modelling techniques used for the analysis model of the component aresimilar to that used for the modelling of the system in which they might be included, thenit is much easier to ensure that the component is suitable for use in the system. In additionthe system’s analysis model can directly use the abstractions of the various components itreuses, easing the task of requirements analysis, and ensuring at an early stagecompatibility between components and the system requirements. This analysis model-based reuse approach is depicted in figure 6b.

Figure 6: Typical Component Reuse

The presentation of a component for reuse is known as a facade. A facade presents the re-user of a component with the information needed to effectively reuse the component,while at the same time hiding from the re-user unnecessary design and implementationdetails about the component. In the analysis model-based reuse approach, the facadeconsists not just of reusable code and the design model details needed for reuse, but alsothe analysis model relevant to the design model part of the facade. The following sectionprovides more details on the generation of facades.

Reuse using Facades

A component may present several different facades, possibly aimed at different types ofre-users, e.g. black box or white-box re-users. A component may have various releases of

a facade to reflect the evolution of the component. The usefulness of the facade isstrengthened if there is clear traceability between the different models, so that within thefacade re-users can easily determine which parts are useful for them, working down fromthe analysis model level.

Obviously the construction of a facade from a component’s internal models that weregenerated during its software development process will be greatly eased if the same typeof modelling approach was used for this process. Strong traceability between thecomponents internal models will ease the selection of parts of the model for inclusion inthe facade, based for instance, on a set of use cases. However, it is not a requirement forthe component to have been originally developed and documented using an OOSE-likeprocess, and part of the benefit of facades should be that it can hide the internal model ifnecessary.

For instance if a component has been developed and documented using ODP viewpointsthe following mappings can be made, effectively reverse engineering the ODP model intothe facade format.

• Roles in the enterprise viewpoint map onto actors in the fa ade’s use case model.

• Computational objects from the computational viewpoint can map onto controlobjects in the analysis model.

• Computational object interfaces can map or be grouped into boundary objects inthe analysis model.

• Information object can map to entity objects in the facade’s analysis model.

• If some sequence diagrams have been used the clarify the interactions betweenCO and IOs then these might form the basis for reverse engineering use cases,otherwise use cases should be based on and be consistent with the component'srequirements.

Guidelines for Business Process Analysis

While OOSE provides good traceability through the development cycle of a system, atthe analysis stage use cases only help us analyse the interactions between a system andthe actors that use it at the system boundary. Use cases are not good at describing theinternal operation of a system. Even if sub-systems are identified, and use cases for eachsubsystem generated, these use cases may only interact with external roles, or subsystemsmodelled as roles. There is no well-understood mechanism for tracing the interactionsbetween different use cases in different subsystems. Use cases in different subsystemsmay be related by generalisation relationships, e.g. “uses” or “extends”, but these do notdefine details of the interactions, only that they are related. Use case text can includedetails of interactions with different subsystems, but this quickly becomes unwieldy,generating in effect a textual description of the system’s internal functionality.

However the identification of interactions between subsystems, is typically the kind ofanalysis that is performed in business process reengineering activities. Here, businesses

aim to define the major processes they provide to their customers, which at a high levelcan be adequately captured with use cases. However, the aim of business processreengineering is to analyse the internal processes of an organisation to understand howthey interact to provide value to customers, and how the structure of these processes andtheir interactions can be changed to improve customer services and reduce costs. Thisproblem is complicated for management systems by the interactions often required withprocesses in other organisations. The framework’s development methodology musttherefore address the problem of analysing the requirements for a multi-domainmanagement task that must be performed by interactions between management processes,some of which will support automated interactions and some of which will not.

The TM Forum Operations Map provides a model of suitable business processes whichfairly confidently reflects the typical operations of a service provider. This can thereforeprovide a starting point for the analysis and design of common solutions to managementproblems. It must also, however, allow the analysis of specific providers businessprocesses in order to identify where existing solutions, available as reusable components,can be applied. Analysis of business processes is typically performed by identifyingdiscrete activities and the events that propagate the control of execution of a task betweenactivities. This may involve different events being triggered in different conditions andthus different sequences of activities being followed in the execution of a task. Such ananalysis should also represent parallel activities, the conditions for their completion andthe synchronisation of control. Specific activities may also be broken down hierarchicallyinto finer grained activities.

A common representation of such control flow is event-driven process chains, a graphicalmodelling technique that allows activities to be associated with organisational roles andwith objects representing business information. The inclusion of activity diagrams inUML allows it to support a similar type of modelling diagram. The analysis of a specificmanagement tasks in a specific business scenario can therefore be initially described interms of a use case giving the interactions of the system with human roles. The use casemay not necessarily mention the internal business processes. These processes thereforeneed to be analysed using activity diagrams. The activities can be placed within swim-lanes representing TM Forum business processes, possibly residing in differentadministrative domains. This will ease the identification of where existing TM Forumbusiness agreements match to the requirements of the task at hand.

Multi-Domain Management Development using Re-usable ManagementComponents

The proposed multi-domain management development process is the modelling of thebusiness processes and constituent activities, the mapping between these managementactivities and reusable management components, and the integration of the components.The development process outlined below is customised for use of workflow engine toperform component integration. The development cycle identifies the steps that need tobe performed at each stage of the development of the management systems. The textexternal to the design process illustrates the influences and constraints particular to thedevelopment of management systems formed from reusable management componentswithin the context of the target implementation environment.

Open Service Market Business Requirements& Service Management Standards/Initiatives

Re-usable Information Objects &Computational Components (e.g. TINA)

Technology Constraints

Identification andRepresentation of

Management ProcessActivities and Process

Rulebase

Identification ofComponents & Interfaces and

Shared Data

Mapping of ManagementActivities to

Management Components

Development ofInterface Agents between

Workflow EngineAnd Components

Perform Trial

and Evaluate

Identification ofBusiness Model(s).

Identification ofManagement Processesexpressed as Use Cases

Figure 7 :Multi Domain Development Process using reusable components usingworkflow integration approach

System Model Details - Trial Business Systems

The Fulfilment Business System

The FlowThru Fulfilment Business System aims at providing an example of theinteractions between processes involved in service and network management related tothe provision of a service to a customer. The fulfilment business process is shown infigure 2. The scenario we consider in FlowThru does not address the Sales or the ServicePlanning/Development processes. Though links to some of the other TM Forumprocesses are identified, the operation of these other processes also is not explicitlyaddressed. The business processes addressed are therefore Order Handling, ServiceConfiguration, Network Planning/Development, Network Provisioning and NetworkInventory Management.

System Description

In FlowThru, the Fulfilment Business System concentrates on aspects associated with theappropriate network planning and provisioning activities for the delivery of services that

a customer has been subscribed to. In particular, we consider a scenario that deals withthe pre-service phase processes. That is, system set-up and ordering/subscription as wellas the appropriate network planning and provisioning with respect to the establishedsubscription contracts.

In essence, the system deals with the provisioning of ATM connectivity services tocustomers. The customer subscribes to an ATM service offered by a connectivityprovider that is capable of offering ATM connectivity with guaranteed QoS, in termsagreed by the customer upon creation of his subscription contract. The connectivityprovider undertakes appropriate network planning and configuration activities based on apredicted usage model that is built upon existing customers’ subscription contractsinformation.

Figure 8 depicts the high-level system description of the Fulfilment Business System.The figure depicts the involved components and identifies the boundary objects whereinteractions cross component boundaries.

Order Handling

NAP mgmt.

Subscription

VPC&Route mgmt.

Get CoS Definitions

.New Contract Info

Network Planner

Release NAP

Configuration Management

Customer

Locate/Activate NAP

Reconfigure Netw.

Service mgmt.

Usage mgmt.

SUG mgmt.

Figure 8: Fulfilment Business System Components and Interactions.

The following components are included in the system:

• Subscription Management: This component aims at supporting both theintroduction and withdrawal of services available to customers as well as enablingcustomer and provider administrator to manage which users may use whichfeatures of a services and from where. To this end, the Subscription Managementcomponent covers aspect of the Order Handling and Service Configurationprocesses.

• Configuration Management: This component is responsible for maintaining aconsistent view of the physical (i.e. ATM link) and logical (i.e. VPC) networkconfiguration and for undertaking the required physical configuration actions tonetwork elements as requested by its clients. The Configuration Managementcomponent covers aspects of the Network Provisioning process.

• Network Planner: This component is responsible for calculating the anticipatednetwork traffic and planning the VP layer network and the sets of admissibleroutes for customers’ VC connections. The performed VP and route planningtakes into account the certain Classes of Service characteristics that areguaranteed by the connectivity service provider.

Fulfilment Business Scenarios Overview

The Fulfilment Business System will be used for planning and providing networkconnectivity at the ‘pre-service’ phase of the service lifecycle. We assume the followingpreconditions to hold:

• The connectivity provider is pre-configured to be capable of guaranteeing anumber of network-level classes of services (CoSs). These CoSs are defined in astandard template format that the order handling process (i.e. the subscriptionmanagement component) is capable to map to a set of supported “applicationtypes”. The network-level CoS definitions are maintained within the NetworkPlanning component.

• The connectivity provider not only is aware of the installed network basis in termsof available physical network resources (e.g. links, nodes and ports – i.e. NAPs)but also is capable of performing a kind of User-Site-to-NAP address resolution.

The overall trial scenario considered for the fulfilment system is the following:

• Upon system initialisation, the Subscription Management component retrieves thelist of the supported CoSs and performs, internally, a mapping to a set ofapplication types, SLAs and Service Records that can comprise the offeredservices.

• In general, a customer’s request to the subscription management can be one of thefollowing:

• Create a new subscription contract

• Modify an existing subscription contract

• Modify a SUG associated with an existing subscription contract

• Drop an existing subscription contract

In this subsection we shall consider the case of a new subscription contract beingcreated. In that case, the customer gives information with respect to the SUGs (Service

Usage Groups) that will be using a specific service comprised of a SLA and a number ofService Records.

• Based on the above information given by the customer, the subscriptionmanagement requests from the configuration management component to activatethe NAPs that correspond to the sites of the SUGs indicated in the subscriptionrequest. As a result, a number of sites is activated while the activation of somesites (of the indicated SUGs) might remain pending until the appropriate networkinstallation process takes place (network installation is not automated in thespecified Fulfilment Business System).

• When the order is satisfied by the Subscription Management, an event isforwarded to the Network Planner containing information on the number of addedusers, the NAPs the users are attached to, as well as the application type they use.From this information, the Network Planner calculates the anticipated networktraffic and plans the network in terms of VPCs and admissible routes over whichuser VCs are going to be established upon service usage.

• After the planning activity is completed, the Network Planner instructs theConfiguration Management to re-configure the network so that to accommodatefuture connection requests as planned. It is possible that the creation of a newcontract might not change the network plan if the predicted traffic changes,incurred by the users of the new subscription contract, are insignificant.

The above scenario concentrates on the automated network configuration, planning andprovisioning, as a result of the established subscription contracts. Certain network re-configuration/re-planning is undertaken in the rest of customer requests (e.g. in case ofmodification of a SUG). Additionally, new sites (i.e. NAPs) can be configured in anautomated way.

Lastly, one of the future enhancements envisaged to the Network Planner boundary is theinteraction with a Network Performance Verification component that could be used forverifying the estimated traffic predictions with respect to the actual network load andemit performance degradation alerts when needed.

The Assurance Business System

The Assurance Business System concentrates on problem handling aspects of the in-service phase. It makes use of Subscription / Service Level Agreement (SLA)information (as defined in the Fulfilment Business System) to identify SLA violations.Since SLA violations have an impact on billing, a discounting scenario has beenconsidered within the Assurance Business System to highlight closely related interactionswith the Accounting Business System.

The system presented here aims to provide an example of the interactions betweenprocesses involved in the TMF customer access, service and network management levels.It will demonstrate the information flow to improve the quality of the service (QoS)

provided to a customer. The assurance business system will be based on the processes asidentified in the TMF Business Process Model(see figure 2). The specific scenariosadopted here, focus on the QoS management processes (CQM and SQM). Though linksto some of the other TMF BPM processes are identified, the operation of these otherprocesses is not addressed. The business process areas addressed are therefore ProblemHandling, Customer QoS Management, Service Problem Resolution, Service QualityManagement and Network Maintenance and Planning. Since a SLA violation may havean impact on the payment of a customer, the link to the rating and discounting processwill also be demonstrated in the assurance demo.

System Description

Figure 9 gives a high-level system description of the Assurance Business Systemincluding the various components. The diagram also identifies the boundary objectswhere interactions cross either domain boundaries or component boundaries. Thefollowing components comprise the system:

• The TINA Trouble Reporting System (TTRS) acts as central point of access forthe customer in case problems are encountered. Trouble reports are managed bythis component and the necessary actions are taken (within the component or withother components) to resolve encountered troubles and to enable paymentdiscounts.

• The Subscription Management component keeps information about customers,their subscribed services and related SLAs. This information is needed by TTRSto map incoming TRs to customers and their respective users and to verify SLAviolations.

• The Service Level Accounting component creates a bill on the basis of WebStoreservice and ATM connectivity service usage data and handles discounting issuesin case the TTRS encounters SLA violations.

• The TINA WebStore Environment provides the WebStore Service as a TINAservice to its customers. The WebStore is a Web based document store that offersa wide variety of document based management functionality.

• The CORBA/TMN Gateway converts requests between the two protocols.

• The TMN / IMA-TTS component represents the agent part of the IMA-TTSproduct. This product is a TMN compliant implementation of an Inter-operableTrouble Ticketing System based on ITU-T X.790 Recommendation andEURESCOM P612 specifications.

• The ATM Accounting component is concerned with accounting related issues atthe ATM level (e.g. charging based on volume transferred or applying discountsdue to network failures).

Trouble Handling

TTRS

TTRS

Order Handling

Subscription

WebStore Management

WebStore

Discount Handling

Svc. Usage Data Coll.

Accounting

CORBA TTS

TTS X.user

CORBA/TMNGateway

Customer

Customer Manager

Remedy ARS Interface

IMA TTS 1

NW1 Account Mgmt

ATM Accounting NW 1

NW1 Usage Data Coll.

Svc. Usage Data Coll.

Call Recording

QoS Monitoring

Network Mgmt System

NW Trouble Handling

Fault Mgmt System

Alarm Logging

TTRS

Customer Manager

Remedy ARS Interface

IMA TTS 2

NW2 Account Mgmt

ATM Accounting NW 2

NW2 Usage Data Coll.

Call Recording

QoS Monitoring

Network Mgmt System

NW Trouble Handling

Fault Mgmt System

Alarm Logging

X.coop Mgr

WebStoreProvider

NetworkProvider 2

NetworkProvider 1

Figure 9: Assurance Business System Components and Interactions.

• The Fault Manager component and simulator is responsible for logging failureson the network level. Moreover, network related alarms can be grouped in orderto provide other components with pre-processed information.

• The Network Manager OSF component is responsible for monitoring the agreedQoS level, usage logs and the management of network connections.

Assurance Business Scenarios Overview

The assurance business system is used for the demonstration of six trial scenarios todemonstrate the distributed fault management, i.e.: connectivity problem/QoSdegradations detected by customer or detected by connectivity providers (#1 or #2),TINA service (WebStore) problem/QoS degradations detected by customer and detectedby WebStore provider, identification of SLA violations and granting of discounts causedby SLA violations . The execution of the scenarios listed above will require andinterworking between all of the components depicted in figure 9. Each of the identifieduse cases corresponds to a trial scenario, although more complicated scenarios exhibitingmore than one use-case might be considered for the FlowThru Trial demonstration.

The Accounting Business System

The accounting system is a realisation of the TM Forum Billing Business Process. Thesystem consists of several co-operating service and network management componentsthat provide a combined and coherent accounting interface to the service customer.

With respect to the TM Forum Business Process Model, the bulling business process iscomprised of the Invoice and Collection, Rating and Discounting and Network DataManagement processes.

Since the existing components that FlowThru will re-engineer and integrate foraccounting are originally built on the TINA architectural and modelling concepts, amapping of the above components onto TINA business roles was proven useful. In thecontext of FlowThru, the components map onto TINA business roles, as follows:

• Invoicing and collection, seen as the responsibility of the Retailer,

• Rating and discounting, seen as the responsibility of the Broker, Retailer andThird-Party (3-Pty) Service Provider, enabling each to apply its own discountsand rates,

• Network Data Management, seen as the responsibility of the Connectivityprovider.

However, certain TINA accounting concepts cannot be mapped onto the TM ForumBusiness Process Model; this occurs because of the justifiable separation between servicelevel and network level accounting in the TINA model. For this reason, ‘Network DataManagement’ is renamed to ‘Usage/Performance Data Collection’ so that to better

signify its role in both the service and network layers. This results on a modification ofthe last mapping above such that the Usage/Performance Data Collection can be seen asthe responsibility of both the Third-Party (3-Pty) Service Provider and the ConnectivityProvider.

The specific scenario adopted in the Accounting Business System focuses on aspects ofthe accounting process for the connectivity provider, the third-party (3-Pty) serviceprovider and the invoicing (but not collection) part of the retailer.

System Description

Figure 10 shows the boundary objects of all the components comprising the accountingdemonstration system, their interfaces and their interactions. The system consists of sixseparate components, covering aspects of service and network control and management.The components are:

• Access Session Component, which is responsible for allowing access tosubscribed services by establishing a secure context for interactions between theConsumer and the Retailer,

• Service Session Component, which is responsible for the actual usage of aRetailer’s service by a Consumer. This component is specialised to cater for twodifferent service paradigms; those of the Tele-service and the EnhancedTelecommunication Service, represented by the ‘Digital Library’ and the ‘DigitalVideo Audio Conference’ services in this scenario,

• Subscription Component, responsible for determining what Retailer services,users (within the Consumer stakeholder) are entitled to access. It makes thisrelationship explicit in a contract between the Consumer and Retailer that theAccounting component can access,

• Accounting Component, responsible for collecting and collating service levelusage data, generated by the Consumer in the Retailer domain, generating chargesbased on this usage data and combining these charges with those of theConnectivity provider to generate a bill for the Consumer, based on guidelineslaid down in the contracts controlled by the Subscription Component,

• ATM Accounting Component, responsible for collecting network level usage dataand generating charges based on this data for the Connectivity Provider for useby the Retailer Accounting Component,

• Connection Management Component, responsible for providing ATMconnectivity between users (on Retailer request) and for generating network levelusage data for the ATM Accounting Component.

It should be noted that the difference between the Accounting and ATM Accountingcomponents is that they operate on different management levels. The Accountingcomponent operates on the service management level, while the ATM Accountingoperates at the network level. As already stated, these components where identified as a

result of the TINA-based system architecture. From a business process perspective, theyboth map onto the Usage/Performance Data Collection TM Forum business process.

Figure 10: Accounting Business System Components and Interactions.

Accounting Business Scenarios Overview

The components outlined above are envisaged to co-operate in the following fashion.

In the ‘pre-service’ phase:

• A customer subscribes to a specific service offered by a service provider, in thiscase either the ‘Digital Library’ or the ‘Digital Audio Video Conference’. Acustomer is defined to contain one or more users. When a new customer is createdthe SubM (Subscriber Manager) CO of the Subscription Component creates a newcontract and calls on the AM (Account Manager) CO of the AccountingComponent to create a new account.

In the ‘in-service’ phase:

• A user gains access to the service through the UA (User Agent) CO(computational object) of the Access Session Component. This UA subsequentlyrepresents the user in the provider domain.

• The user can then create or join a service session, whose lifecycle is controlled bythe SSM (Service Session Manager) CO in the Service Session Component,

• When the user requests usage of the service, a connection is set-up by the ServiceSession Component’s SSM CO. If the ‘Digital Audio Video Conference’ serviceis requested, then the SSM CO interacts with the CSM (Communication SessionManager) CO of the Connection Management Component to create acommunications session; this establishes an ATM connection between theinvolved users.

• While the user is using the service, the MM (Metering Manager) CO of the ATMAccounting Component receives, collects and collates, accountable events fromthe LNC (Layer Network Co-ordinator) CO of the Connection ManagementComponent.

• Meanwhile, at the service level, the UMData (Usage Metering Data) CO of theAccounting Component receives, collects and collates accountable events (usagedata) from the SSM CO of the Service Session Component.

• The user can request charges for service usage up to a certain time(getUserCharges), while a privileged user, called the Customer Administrator, canrequest the charges for a specific service session (getSessionCharges).

In the ‘post-service’ phase, or at the end of a defined period (defined in the contract);

• The Customer Administrator receives a bill from the BC (BillControl) CO of theAccounting Component. Generating this bill requires the generation of charges,based on information contained in the contract controlled by the SubM(Subscriber Manager) CO of the Subscription Component, by the ChargeControlCO of the Accounting Component. These charges can then be correlated with

those of the ATM Accounting Component’s ChargeManager CO in theAccounting Component’s BA (Billing Aggregation) CO, ready to produce a bill,based on other information contained in the contract, whose lifecycle is controlledby the BillControlCO of the Accounting component.

System Model Details - Components

Subscription Management

Subscription management comprises all management functions needed in order to defineservice offerings, administer customers and users, and manage the details of serviceprovisioning. For instance, the component allows for authorisation and barring of users’access to specific services, and the addition and removal of network sites from whichthese users may access the service. The design is based on the subscription modeldeveloped in TINA [tina-sa

The subscription component use cases have been developed based on the simple businessmodel of a service customer and a service provider having a contractual relationship witheach other. The subscription component is located in the provider’s administrativedomain and is used by two types of actors: administrators of the service provider and ofthe service customer.

The use cases implemented by the component cover the management of services,subscribers, and subscriptions. Service management is definition and adaptation ofoffered telecommunications services, from a management point of view. Management ofsubscribers consists of the creation and deletion of subscribers, the update of subscriberdetails, and the definition of subscriber’s end-user groups and network sites. Finally,subscription management covers subscribing customers to services, update subscriptiondetails, cancel subscriptions, and the authorisation of end-user for specific services.

The subscription Computational Objects (CO) define generic capabilities needed tomanage, from the subscription point of view, subscriber organisations and end-users,different types of services, and subscriptions to these services. The COs include: ServiceTemplate Handler, Subscriber Manager, Subscription Registrar, and Subscription Agent.

The Subscriber Manager manages information associated to subscribers, e.g., subscriberdetails and user groups. The Service Template Handler is responsible for handling servicetemplates that represent service capabilities provided by the provider. It also providesoperations, such as verification of subscription parameters, to the correspondingSubscription Registrar. The Subscription Registrar acts on behalf of a provider in dealingwith subscribers wishing to subscribe to a service. A single Subscription Registrar cancollect information for one service from one or more subscribers and will handle exactlyone service, since each service is likely to have different requirements for subscribing acustomer to a service. A Subscription Registrar is responsible for managing ofsubscription contracts, among others. The Subscription Agent is closely related to the

user agent CO which manages the access session of the TINA service architecture. Itsends appropriate subscription information to the User Agent, in reply to its request.

A separate management application or a special management may access the subscriptioncomponent. The implementation used was developed in the Prospect project, where itwas reused in several different services.

Configuration Management- Network Management Component

The Configuration Management (ConfM) component is part of the fulfilment scenario inFlowThru. Given the fact that the components taking part in this scenario are organised ina hierarchical layered fashion, the ConfM component is at the lowest part of thishierarchy, supporting configuration management capabilities to the underlying ATMnetwork.

The key functionality of the ConfM component is to keep a logical database of ATMnetwork configuration, which comprises both static resources, e.g. cross-connects /switches, links, ports, and semi-dynamic resources e.g. ATM Virtual Paths which in factform a logical network over the underlying physical network. In addition, the ConfMcomponent provides configuration capabilities upon the request of its clients, being ableto set-up and tear-down ATM Virtual Paths and to activate / deactivate a particulartermination point. In terms of the TMN layered hierarchy, ConfM covers both networkand element management functionality.

In the fulfilment scenario, ConfM is accessed by the Order Handler and Network Plannercomponents. The Order Handler interacts with ConfM in order to verify if a NetworkAccess Point (NAP) is available for a new subscriber and to subsequently activate it. TheNetwork Planner interacts with ConfM in order to reconfigure the existing ATM VirtualPath logical network when the addition of new subscribers reaches a threshold thatimplies a different expected utilisation pattern. In case the existing resources are notadequate any more for the “busy-hour” traffic, the installation of new nodes and linkswill be requested before the reconfiguration of the logical network takes place.

The ConfM consists internally of two sub-components: a passive sub-component, theNetwork Map (ConfM-NM), which keeps the current network topology, and an activesub-component, the Configuration Manager (ConfM-CM), which undertakes themanipulation of network elements. The ConfM component is based on CORBA, uses theTINA Network Resource Information Model (NRIM) and borrows ideas from the TMNin the sense that the ConfM-NM component offers a CMIS-like interface in CORBAIDL, including facilities such as scoping and filtering.

Network Planning Component

The Network Planner (NP) component is located at the network management level of theTMN hierarchy. From the TMF viewpoint, it maps to the “Network Planning andDevelopment” process.

This component is responsible for

• maintaining the definitions of the classes of service (CoSs) that the connectivityprovider’s network supports,

• calculating traffic predictions for the underlying network, based on informationregarding the anticipated network usage,

• undertaking the core network planning activity, based on the supported CoSs andthe anticipated network usage, in two layer networks:

• at the VP layer, it designs the VP topology, on-top of which the user VCs will beaccommodated,

• at the VC layer, it designs a set of alternative routes to choose from upon VCestablishment

The above planning activities are tightly coupled, since VPCs are established for routingVCs on-top of them.

More specifically, the Network Planner consists of the following three subsystems:

The Class Of Service Model (CoSM) subsystem.

The CoSM maintains a repository of the CoSs supported by the network. Each CoS isdefined in terms of its bandwidth characteristics, performance targets and restorationcharacteristics. It should be noted that the CoSM restricts, yet is based on, the servicesoffered to users through the Subscription Management component.

The Predicted Usage Model (PUM) subsystem.

The functionality of the PUM encompasses the maintenance of a valid model of theanticipated traffic to the network. Based on this model, the PUM supplies the VPC_TD(see below) with traffic predictions, required for the design of the VP layer. The VP layer(set of VPCs) and the static aspects of the VC layer (set of admissible routes per source-destination and CoS) are constructed based so that to satisfy the predicted traffic demand.

Anticipated traffic is modelled in terms of the numbers of connection requests per CoSbetween source-destination pairs. The model details how the connection requests andcharacteristics (e.g. holding time) change: hour by hour over the day; day by day over theweek; and week by week over the year.

The anticipated traffic model will be acquired from information regarding the subscribersof the network. This information is given by the Subscription Management component

and it describes the number of users that are subscribed to use the network according tospecific CoS characteristics as well as the destination distribution for their connectivitysessions given specific sources (i.e. NAPs). Also, data regarding historical network trafficwill be taken into account in order to make predictions as accurate as possible.

Normally, the model needs to be validated and modified against actual network usageregarding end-to-end connectivity. However, this will not be considered within thecontext of FlowThru.

The VPC Topology Design (VPC_TD) subsystem.

The main task of VPC_TD is to design and redesign, whenever necessary, working VPCsand sets of admissible routes taking into account the existing CoSs. In addition, theexisting component (made available by the REFORM project) also designs suitableprotection VPCs and allocates the appropriate amount of protection resources, thusproviding for a resilient network design. VPC_TD’s task is based on the predicted trafficand the physical constraints (e.g. connectivity, capacity of links) of the network. Theseinput parameters are subject to changes over the lifetime of a network. VPC_TD offers acertain level of flexibility to adapt to such changes.

The tasks of designing VPCs and routes based on them should not be seen in isolation asthey are tightly coupled; routes are based on VPCs; and VPCs are defined for routing.Along with these tasks, the tasks of designing appropriate protection VPCs andsubsequently allocating protection resources across the network could be considered.These tasks cannot be done in isolation but in an integrated manner and should follow thedesign of working VPCs and defined routes. All these tasks are part of an iterativeprocess involving complex optimisation problems aiming at providing cost-effectivedesign solutions. The optimisation targets are set according to the business policy of thenetwork operator. Part of this process will be to identify all possible routes betweensource and destinations and to choose a certain subset of these, according to theperformance targets of the CoSs to be carried. As a result, not all routes defined betweena source destination pair might be admissible to all CoSs.

The VPC_TD functionality has both static and dynamic aspects. The static aspect isrelated to the network planning activity and is used to initially design the network interms of working VPCs, routes per CoS based on them and protection VPCs and theappropriate amount of protection resources to cope with faults. This part is performed atnetwork start-up time.

The dynamic aspects cater for changes in the predicted network traffic, for predictioninaccuracies that could not be resolved by the lower level components, for the creation ofnew VPC or the deletion of old ones and for handling fault situations (including changesin the physical topology). As a result, the VPC network and the protection VPCs arereconfigured.

Access Session Control Component

The access session represents a secure relationship between a user and a provider ofservices. A user needs to have an access session established before he can engage in anyservice. The access session control component originates from the VITAL project and isaligned with the TINA Ret RP and Service Component Specifications. The functionalityprovided by the VITAL component can be summarised as:

• Access Session Management. Only named access that requires user authenticationis supported. A user can be involved in multiple access sessions with the sameprovider at the same time, where each access session is terminated on a differentend-user terminal. The user can get an overview of all these access sessions, withan indication of the end-user terminal terminating the access session. The user canalso delete any of these access sessions from within any other access session.

• Service Management. List all services offered by a Retailer. List all services towhich a Consumer is subscribed at a Retailer domain.

• Service Session Management of service sessions. Creation of a new servicesession. Receive invitations for joining a service session. List sessionannouncements. Joining service sessions on invitation or on announcement. Listall the service sessions in which the user is currently involved. Delete a servicesession in which the user is involved

• User Registration Management. Register a user to receive invitations on a specificterminal, although there is no access session established by that user on thatterminal.

The functionality of the component is extended within FlowThru to allow the user toretrieve his bill related to his service usage from the provider.

Usage Session Control Component

The service session represents an instance of a specific service and can involves a serviceprovider and any number of service users. For each of the users involved in the servicesession, this service session needs to be associated with an established access sessionwith the provider. The usage session control component originates from the VITALproject and is aligned with the TINA Ret RP and Service Component Specifications. Thefunctionality provided by the VITAL component implements the TINA session modelfeature sets, which can be summarised as:

• Basic FS. This is the only feature set which is required, i.e. it needs to besupported by every service implementation. This feature set is required to enablea user to request to end a service session and to allow a provider to inform a userthat a service session has been ended.

• Voting FS. This feature set is always used in conjunction with any of the *IndFeature Sets (see further). Most functions which are requested from the providerare potentially susceptible of voting, i.e. other users involved in the serviceinstance have a right to vote on whether or not the provider is allowed to actuallyprocess the requested function. This feature set is required to enable a user toissue a vote and to allow a provider to inform a user about the outcome of avoting procedure.

• Multiparty FS. This feature set allows the service to support having more than 1user involved in a service session. It enables a user to: invite other users to jointhe service session, delete other users from the service session and retrieveinformation on other users involved in the service session. It enables a providerto: inform a user that he has been deleted from the service instance, inform a userthat other users have been invited, have joined or have been deleted from theservice session

• MultipartyInd FS. This feature set allows the service to support voting onfunctions which are part of the Multiparty feature set. It allows the provider toinform the user that a request has been received to invite a user, to join the serviceinstance or to have a user deleted from the service instance

• Streambinding FS. This feature set allows the service to support the establishmentof information streams between the different user terminals. It supports streamswith topologies ranging from the simplest point-to-point to the most complexmultipoint-to-multipoint configurations. When the service is deployed on top of aconnection-oriented network, these information streams will be realised by settingup end-to-end connections (and possibly control of special resources, such asvideo bridges or media convertors). The demonstrator currently supports ATMand IP based transport networks. This feature set allows the user to request thecreation of a new stream, to deliver endpoints for the stream, to invite other usersto participate in the stream (i.e. to deliver an endpoint for the stream), to deleteusers from the stream (i.e. to remove the endpoints delivered by those users), toremove his own endpoints from the stream, to delete the complete stream. Itallows the provider to: inform the user that he has been added or removed to/fromthe stream or that the stream he was attached to has been deleted completely,inform the user that a new stream has been created, endpoints have been addedto/deleted from a stream, or a stream has been deleted.

• StreambindingInd FS. This feature set allows the service to support voting onfunctions which are part of the Streambinding feature set. It allows the provider toinform a user that a request has been received to create/delete a stream,add/remove endpoints to/from the stream, ...

• ControlSR FS. This feature set allows the service to establish control relationshipsbetween the users and objects in the service instance, such as other users orstreams. In general, it allows to express the control rights that users have tochange something to the service instance (such as add users, remove streams, etc),

which are referred to a ‘Write’ permissions, and the rights that users have to viewsomething in the service instance (such as view that a new user has been added,that a stream has been added, etc), which are referred to as ‘Read’ permissions.By setting the correct relationships, the ControlSR feature set implementation willtake care of all necessary checks (such as who is to receive a certain indication orinformation). This feature set allows the user to request the setting of a controlrelationship. It allows the provider to inform a user that a control relationship hasbeen set.

• ControlSRInd FS. This feature set allows the service to support voting onfunctions which are part of the ControlSR feature set. It allows the provider toinform a user that a request has been received to set a control relationship

Within FlowThru, this component will be adapted and extended to:

• allow the user to retrieve on-line info with regard to that specific service session

• generate accountable events towards the accounting management component

TINA WebStore Environment

The WebStore will be used in the assurance scenario as sample TINA service applicationto demonstrate TINA service fault scenarios and related trouble and problem handling.The WebStore system can be seen in the enhanced component model (see figure below).The service offers a Web interface to the customers for up- and downloading documentsto a centralised or distributed document store. The TINA Middleware Environmentcovers the required Service Architecture components embedding the Webstorecomponents depicted in figure 11, including TTRS; provider agent, user agent, user andservice session manager, subscription, accounting and the TINA DPE.

Figure 11: Simplified WebStore and TINA Environment Component Model

An initial version of the WebStore has been developed in the ACTS Project Prospect. Ithas been used in a tele-educational scenario to gain experience in multi-domain servicemanagement, multi-provider service composition and technology integration (Internet(SNMP), OSI (CMIS/CMIP), TMN based network management and CORBA / TINAbased service management. The Flowthru version will be adapted to current TINAversion 5.0 specifications and will provide an additional Interface to the TTRS as well asa direct up- and download of documents within the used databases.

TINA Trouble Reporting System (TTRS)

The TINA Trouble Reporting System (TTRS) will be implemented as a TINA servicethat realises the problem handling management process at the service layer of theFlowThru system. The service layer is based on the TINA service architecture, thus, theTINA TR service should be considered as a particular TINA management serviceproviding all the TINA service model functionality.

The TINA TRS provides facilities that allow handling of so called trouble reports (TRs atservice level) and trouble tickets (TTs at network/connectivity service level) whichinform customers about malfunction of the service to which they are subscribed. TheTINA TRS provides service view insurance to the customers in order to handle theirproblems. This means that the TTRS hides to the customer the details of the failure

(network or service) and the recovery process. The contract between the customer and theservice provider is based on SLA (Service Layer Agreements). So the second objective ofTINA TRS is to verify over time if the QoS for each customer and each provided service(e.g. Webstore) is fulfilled during the lifecycle of the service subscription. If not, a SLAviolation will be generated in order to discount the customer’s bill according to the tariffand the SLA agreed within the fulfilment phase.

The TINA TRS realise two main processes of the assurance process model:

• Problem handling process which provides the main task for receiving servicecomplaints from the customer, determines the causes of failure, initiates problemresolution, and tracks progress and resolution of troubles, generates trouble ticketsto the network level TTS and the WebStore service and finally notifies the enduser when the trouble is resolved. If problems have been detected by the TINAservices or the connectivity services, the customer will be informed (in specificcases also in the case, if the user is not directly (on-line) using the service, e.g. todistribute maitenance times).

• WebStore customer QoS management, which monitors performance and faults ofthe WS provisioning in order to detect any SLA violation. It establishes reportsand provides information about the SLA violation for the accounting system inorder to apply tariff related discounts in case of a fault within the WebStoreservice.

Beyond its relationship to the TMF assurance business processes, the TINA TRS fits inthe alarm management area of TINA fault service management. TINA fault managementdeals with fault alarms in general, which includes alarm correlation and alarmdistribution. It also includes identification of faults and the types of faults. It isparticularly important for a TINA system to be reliable, resilient, and fault-tolerant, sinceit consists of many semi-autonomous distributed elements. This distributed nature makesit very difficult to control and manage reliability of the entire system. In collaborationwith the network service level TTS the TTRS will help to ensure a high QoS (e.g. byminimised problem solution times) within a distributed TINA environment byexchanging trouble tickets between customer, service provider and connectivity providerdomains.

TMN / IMA-TTS

Trouble Ticketing (TT) is a widely used term within Telecommunication NetworkOperators (TNOs) and Service Providers (SPs) to describe a mechanism to control andrecord the problem handling and repair progress. – It is also being used to executeprocesses generated by the detection of a violation of the quality of service in context of adefined SLA.

Inter-domain trouble ticketing is needed when the provision of the end to end service to acustomer involves two or more organisations - such as occurs, for instance, forInternational Private Leased Data Circuits. In the case of e.g. two TNOs the first one

may have a problem reported to it by a customer and, after having carried outAnalysis/Testing and Diagnosis, it may determine that the fault lies within the domain ofthe second TNO. A standardised TTS on the Network Service Layer should be able, tocarry out the interconnection between the proprietary (pre-existent Remedy ARS) TTsystems of the two inter-operating TNO/SPs (“Legacy system integration”).

X.coop CMIP interface

MOT based

C++ Agent #1

Corba-CMIP gateway

X.user CMIP interface

(X.user) IIOP interfaceto TINA TRS

MOT based

C++ Agent #2

ARS ARS

Command lineinterfaces

Fig. 12 Usage of IMA-TTS in FlowThru ( non-TTS parts have dotted lines )

The IMA-TTS is a TMN compliant implementation of an Inter-operable TroubleTicketing System based on ITU-T X.790 Recommendation and EURESCOM P612specifications.

The IMA-TTS is basically made-up of a pair manager-agent (according to TMNdefinitions) using the CMIP protocol. They are running on Hewlett-Packard Open ViewDM platforms and were developed using HP OV MOT (Managed Object Toolkit)facility and the C++ programming language. An agent can serve more than one manager.For both components the human interface is realised by Java , enabling remote executionof the GUI(s) and for its downloading through the Word Wide Web.

IMA-TTS implements a number of Management Service Components (MSCs) that areeach composed of Management Function Sets (MFSs) which support and specify thedesired functionality. The MFS decomposition reflects roughly the natural life cycle of aTT.

Due to the way the MFS has been defined, the CMIP interface can be either an interfacebetween to Customer (X.user) or a cooperating interface between TNO/SP domains(X.coop) which provides the following MSC functions:

• TT Creation: This MSC contains MFS for various types of TT creation.

• TT tracking, monitoring and history: This MSC is intended to provide a managerwith the operation support to follow the evolution of a TT during its life cycle.

• TT management: This MSC contains functions allowing a manager to modify aTT attribute during the TTs active state.

• TT closure: This MSC allows a manager to request the closure of a TT, or toverify the correctness of the TT clearance by the agent in order to let the latter toclose it.

For details please see the EURESCOM P612 specs that are publicly available on theEURESCOM server.

For the FlowThru projects we will use the reuse of IMA-TTS Agent in three ways:

• to be interconnected to the TINA level TTRS over the standard CMIP interface(through a Corba/CMIP gateway),

• to be interconnected to an agent of a second connectivity provider over thestandard CMIP / Xcoop interface,

• to be interconected with a proprietary intra domain TTS (Remedy ARS).

Also the agent has to be extended with the automatic correlation between an X.user TTand an X.coop TT that in the current version is a manual process.

Network Manager OSF

The chief aim of the ATM Network OS is to provide end-to-end network connectionsbetween its customers in a flexible, efficient and economical way. Apart from providingnetwork connections the Network OS provides management functionality to support theneeds of its customers in terms of communication quality of service and behaviour inresponse to network faults.

A B

Subnetwork 2

Subnetwork 3

Subnetwork 1

Topological Points Link

Figure 13: A Subnetwork is decomposed into Links and Subnetworks

The public network infrastructure in FlowThru consists of interconnected ATM crossconnects in a topology of simulated elements. The ATM VP network managementservice is offered through a CMIP interface providing a layered view of the ATM VPlayer. Each of the separate ATM cross connects is viewed as a subnet partition in the VPlayer network. FlowThru applies a distributed object model, where the management andcontrol of the subnetwork partitions can be arbitrarily distributed among the cooperatingsubnetwork OS’es. The public ATM VP network management service is fullyimplemented on CMIS/CMIP technology using the Q3ADE TMN development tool. Thenetwork model applied within the public network is based on the ETSI NA43316 GenericObject Model Library (GOM), which has been specialised to the ATM technology.

The fundamental idea behind the GOM network model is the recursive decomposition ofnetworks into subnetworks interconnected by links. This decomposition process stops atthe lowest level where a subnetwork is "equal" to an ATM cross connect. The ATMnetwork element level is controllable via an ITU-T I.751 Q3 interface.

The issue of distribution of the network management application is in particular relevantfor ATM networks, where the granularity of the object model and the vast number ofobject instances renders a centralised management application inadequate for large ATMnetworks. When implementing a decentralised network management application it isimportant to allow for a distributed route determination process, and to allow forsubnetworks at higher partitioning levels to make qualified route decisions concerningroutes through an opaque subnetwork at a lower partitioning level. The concept of opaquesubnetworks and associated concepts for the handling of these within a Network OSprovides the means to distribute the implementation of the network service at will. Inorder to facilitate opaque subnetworks FlowThru (inherited from Prospect) has addedroute management objects to the network model. Within the partitioning hierarchy thesemanaged objects allow subnetworks at higher partitioning levels to query routeinformation from subnetworks at a lower partitioning level in order to make qualifieddecisions about which subnetworks a requested connection should be routed through.

Fault manager component and simulator

Surveillance of faults in end-to-end connections is achieved by the introduction of ageneric fault correlation function. If any of the managed objects that are involved in anend-to-end ATM connection changes to a faulty state, the managed objects whichrepresents the end-to-end ATM connection will be put into a fault state by the correlationfunction. This concept has been developed in an entirely generic way, which allows theimplementation to be reused in many similar situations without special programmingeffort.

1) Dependencies are setup throughthe eventSwitch at creation of aconnection from A to B2) A failure occurs3) The operational state of avpCTPBidirectional goes disabledand the state change event isforwarded through theeventSwitch to the affectedatmSubnetworkConnection4) The operational state of thisconnection goes disabled and thestate change event is forwarded tothe affectedatmSubnetworkConnection5) The operational state of thisconnection goes disabled and astate change event is sent

atmSubnetwork

atmTopologicalPoint vpCTPBidirectional

atmSubnetworkConnection atmCrossConnection

tcAdaptorTTPBidirectional

atmFabric atmFabric

Combi

3

4

5A B

2

SN1

SN1bSN1a

A1 A2 B1 B2

v2

Figure 14:A Generic Fault Correlation Object, the Event Switch

Configuration Management- Connection Management Component

The Configuration Management component was designed and developed in theREFORM project. It conforms to a relatively loose interpretation of the TINA NetworkResource Architecture (NRA) and to its Network Resource Information Model (NRIM),which it modifies and extends.

Its key functionality is the following:

• it keeps a representation of an ATM network as a set of NRIM-based informationobject instances and allows other components to develop a picture of what thenetwork looks-like by navigating their relationships; and

• it provides an interface that allows other components to request the creation ofATM Virtual Paths with particular route characteristics (and also their deletion);VPs are represented by objects kept in the network map, so that the picture of thenetwork is complete.

The representation of the ATM network is kept by a Network Map object (Confm-NM),which keeps objects internally as NRIM-based GDMO object instances and providesaccess to them through a CMIS-like interface realised in CORBA IDL. As such, thisobject conforms to the TINA NRIM, CMIS (X.710) and CORBA.

ATM Virtual Paths are set-up by a Connection Management object (Confm-CM). Thisprovides an interface that conforms loosely to TINA Connection Management, which itextends so that a particular route for the VP can be specified. In addition, this objectsimplifies TINA connection management by avoiding a hierarchical tree of network andelement management layer connection performers (NML and EML CPs), which are all“collapsed” to one object for simplicity and efficiency.

ATM Accounting Component

The ATM Accounting component is designed to capture ATM based charging schemesand apply these schemes to usage data gathered from an ATM service machine (NetworkElement OS). The system is capable of producing individual charges, or amalgamatedcharges (bills) based on this usage data, which are stored to a relational database, orproduced in simple report form. The overall component is broken down into two sub-components.

The metering sub-component communicates with an ATM Service Machine (NetworkElement OS) to extract Connection Detail Records (CDR's) using an API specificallydeveloped for that purpose. These CDRs describe completed SVC or PVC sessions, andare derived according to the CANCAN CDR specification. The CDR's arebuffered/logged by the ATM Network OS and are periodically dispatched to the MeteringManager. The Metering Manager also filters and stores the CDR's in a generic and morepersistent form. This generic form is referred to as Service Detail Record (SDR).

The charging sub-component will accept the SDR's from the metering sub-component. Itscentral function is to then rate these SDR's and produce into persistent storage ratedSDR's, which we can call Charge Records. The rate at which these charge records isproduced is dependent on two factors:

• The rate at which SDR's are received from the Metering System.

• A threshold factor, configurable, which dictates frequency with which the rateengine is engaged. If the threshold factor is set to 1, then the rate engine will be

engaged as soon as a SDR arrives. A multiple threshold factor indicates that thatmultiple of SDR’s must be available before the engine will be launched.

For the purpose of integrating the accounting component, a billing sub-component isomitted and other accounting systems (for example from TCD or GMD) are allowed toretrieve these charge records, and incorporate them into TINA service layer bills. Thisinterface has been designed to be flexible, as such it supports "On-demand" and"notification" methods of charging information propagation.

Service Level Accounting Component

The Flowthru accounting component is based on TINA accounting management definedin the second version of the TINA Service Architecture, and was developed within theProspect project. Some extensions of the Prospect system were deemed necessary by thepresence of network level accounting in the Flowthru project. The accounting componentcontains functionality that covers all areas of the TMF “Billing” high-level businessprocess. It maps certain TMF processes onto TINA business roles, and in some casesconcentrates on specific low-level activities within the processes.

The accounting component deals only with the production of the final bill (invoicing) notpayment of that bill (collection) for the TMF “Invoicing and Collection” process, it alsooffers “hot-billing” functionality, enabling users and administrators to see the chargesaccrued so far in a particular service session.

Bill production is accomplished by the BillControlCO sub-component of the accountingsubsystem (or system component), while the TMF “Rating and Discounting” businessprocess maps onto the operational interfaces of the ChargeControlCO sub-component.Rate calculation is accomplished via control interfaces on the sub-component that areoutside the scope of the TMF business process model.

The TMF concept of “Network Data Management” is expanded to cover both networkand service level usage data collection, with the collection, collation and aggregation ofservice level data achieved by the UMDataCO (Usage Metering Data) sub-componentand the aggregation of charges bases on network and service level usage effected in theBACO (Billing Aggregation) sub-component.

The Accounting component interacts with the following components within the overallaccounting business process demonstration system;

• Subscription Component, through its customer account manager sub-component(create customer account) and its subscriber manager sub-component (subscribecustomer to service),

• Access Session Component, through functionality implementing the “billinginformation” use-case,

• Service Session Component, by allowing the possibility of “hot-billing” or in-session usage charges, and by generating accountable events, on which all chargesand bills will ultimately be based,

• ATM Accounting component, by supplying tagged charges to allow customerlevel correlation of the network level and service level usage.

The following diagram outlines the interactions with these components, while thecomponent fa ade shows the interfaces and boundary objects that are involved ininteractions.

Integration Technology Details

The approach taken to the definition of integration technology follows a similar approachto the TMF Technology Integration Map, i.e. to identify the different technologies used inor applicable to the area and then discern where integration technology is required.However FlowThru goes further with an emphasis on how integration technology cansupport the integration of components from different sources, including commercial off-the-shelf components.

In addition to using CORBA-CMIP gateways, CORBA Components and Workflowtechnology this section details some other integration technology being applied in theTrial Business Systems.

The TMN/C++ API

The TM Forum specification set NMF040-NMF043 defines a standard ApplicationProgramming Interface (API) for use with the international standards for network andsystems management. The objective of this API is to provide a straightforwardmechanism to write portable and interoperable management application programs usingC++.

The specification of this API is divided in four parts. An overview is provided in NMF043 which discusses conventions used, and documents shared or common areas of theAPI. The remaining parts document three separable APIs that are designed to worktogether.

• An API that supports access to abstract data in the form of Abstract SyntaxNotation One (ASN.1) types and values. This is called ASN.1/C++ (NMF 040-1& NMF 040-2).

• An API that supports access to Common Management Information Services(CMIS), and the Association Control Service Element (ACSE). This is calledCMIS/C++ (NMF 041).

• An API that supports access to managed objects, and all of their properties(attributes, notifications, operations, and behaviour). This is called GDMO/C++(NMF 042-1 & NMF 042-2).

Any particular implementation of this API need not necessarily support every aspect.Similarly, a particular application will likely only use a subset of the capabilities definedhere.

FlowThru intends to use the TMN/C++ API as a means to integrate the accounting andnetwork components.

Data Bases as an Integration Technology

The Data Base Integration can be seen as a ’last resort’ integration technology. Such atechnology is to be used mainly in two cases:

1. When the cost of product reutilization based on the more modern and flexibleapproaches (gateways, workflow engines) is too high to justify the reutilization ofcomponents;

2. When the majority of pre-existent components, that have to be put to worktogether, are already using the same/similar type of Data Base ManagementSystem (e.g. relational DBMS). Frequently, this approach is to be taken for thereutilization of "legacy" products that were written without the utilisation ofcurrently existing standardisation mechanisms for distributed computing (TMN,DCE, CORBA).

Two technical conditions are prerequisites for a data base to be used as a interfacebetween two independently developed software products (components). There are thefollowing:

1. The data base is able to hold proper data representations for all information that isto be transferred between components - for most present day DBMS thisrequirement is fulfilled.

2. The data base management system poses - or at least may be easily extended with- a notification mechanism. This mechanism consists of some form of a storedprocedure that is to be automatically executed (fired) when some conditionsbecome true inside the data base (e.g. a piece of data stored in base has beenmodified) or in its environment (e.g. a specific process has just connected to thedata base).

In FlowThru this concept will be used in the assurance business system trial to exchangeinformation between the fault management system and the TTS.

CORBA-CMIP gateway

The CORBA-CMIP gateway (CORBAGW ) used in FlowThru was initially developed inthe Prospect project. In FlowThru it will be used in the accounting and assurancescenarios to bridge the technology gap between the CMIP and CORBA worlds.

The CORBAGW effectively brings CMIP managed objects into the CORBA objectdomain. The CORBAGW acts as a CORBA server in the CORBA domain, effectivelycarrying out the invocations on all the managed objects that reside in CMIP agents. Itdoes this by acting as a manager (client) in the CMIP domain, translating CORBAmethod invocations to CMIP requests. The CORBAGW thus provides CORBA-basedmanagement systems with an access to existing CMIP-based agents with standardisedinformation models.

The CORBAGW implements a CORBA server/client process that enables CORBA basedmanagement applications to view/control objects in CMIP based Q3 agents, and toreceive events emitted by CMIP agents. The CORBAGW adheres to the interworkingprinciples defined by the Open Group/NMF Joint Inter-Domain Management task force(JIDM).

The primary requirements pursued in the design of the CORBAGW are to:

• Adhere to the translation principles defined by JIDM

• Allow for fully dynamic run-time configuration of dictionary information

• Provide a scaleable implementation allowing for access to a configurable numberof OSI agent

The CORBAGW functionality allows for dynamic update of dictionary information toinclude new object classes and/or OSI agents at run-time. This is realised byimplementing the dictionary information as a local MIB accessible through either the Q3protocol, the CORBA interface or the local management interface of the CORBAGW.Furthermore, the CORBAGW provides an implementation that makes the performance ofthe CORBAGW independent of the number and sizes of the underlying OSI agents.

The CORBAGW includes a JIDM compliant GDMO to IDL compiler, which performs atranslation of GDMO definition into CORBA IDL and provides the mapping informationneeded by the CORBAGW kernel.

The CORBAGW has numerous fields of application.

• The CORBAGW can be used as a standalone gateway bridging between theCORBA and CMIS/CMIP technology domains

• The CORBAGW can be used to provide a standardised management API thatmaps to a multiple number of implementation languages and through whichCORBA, CMIP and SNMP based agents can be managed.

• The CORBAGW can be used to implement heterogeneous agents capable ofbeing managed by both CORBA and CMIP based management applications

Back to FlowThru homepage