Information Modeling of Trouble: A Service Provider View Shmuel Markovits, Michael Lam and Robin Braun Institute of Information and Communications Technology University of Technology Sydney, Australia Email:
[email protected],{michael.lam,robin.braun}@uts.edu.au Abstract—This paper focuses on providing an information model view of the Trouble component of the assurance domain. This is derived using an understanding of the TMF eTOM processes and the associated SID Information Model through its application to the Trouble processes. We begin by examining existing standards and adapt and/or derive entities which are used within these processes and develop some entities which are undefined or unavailable currently in the SID definitions. We describe an implementation that leverages the use of the SID information model principles to enhance Trouble assurance.
I. INTRODUCTION The environment in which Telecommunication Service Providers (SP) operate is rapidly changing. Previously only technology focused, the SP is now required to be more customer focused. Customers, demanding more are concerned with the effectiveness, timeliness and quality of services bound by Service Level Agreements. To meet these demands there is a requirement for SP to inter-work with stakeholders such as suppliers, partners, and customers in analyzing and refining methods of business. The Enhanced Telecommunications Operations Map (eTOM) business processes and the Shared Information/Data (SID) Information Model are two initiatives from the TeleManagement Forum (TMF[1]) providing a greater understanding of business methods to interact seamlessly internally and externally with their business stakeholders. An insight into the eTOM and SID is gained by looking at a generic process such as trouble resolution. To create these processes, their definitions are drawn from TMF eTOM processes and adapted through an investigation of fault management. These processes form the foundation for developing an information flow. The SID defines basic entities used for understand the model and we find a need for further definition and expansion of those entities. Detection and reporting troubles describes the methods available in identifying the occurrence of a trouble and the systems needed to support these methods. The methods include proactive, preventative, and reactive detection. For these methods we focus on some of the current standards used to establish a interface between the service provider and the customer to report on troubles, namely X.790 by the ITU-T, RFC 1297 from the IETF, CSM-TR from the MNM Team , and TMF601 or
NMF601. We describe the problems, requirements, and a discussion on the advantages and disadvantages of these standards. This paper begins by providing an overview of information models, eTOM and SID, We provide an overview of the Assurance issues, in particular Trouble management as part of Fault management, discuss existing standards, and describe some of the trouble resolution process using eTOM processes. From there we draw upon this knowledge and define entities which are needed for this process and which are presently undefined or unavailable currently in the SID definitions. We then describe a multimedia service context where we have experimented with an implementation using SID based constructs. A.
Purpose of Information Models Where previously businesses could overlook the role and importance of networks in business operations this is no longer the case, networks are now ever increasingly becoming an essential part of mission-critical processes. Network management can assist in reducing the risks or costs exposure associated with the operation of network systems [2]. This is achieved through the monitoring, control, interpretation and analysis of information from these systems. As such information models are a core requirement for a successful network management system. The need for an open, standardised information model is particularly important to the area of network management which finds itself in an increasingly heterogeneous networking environment. While vendors subscribe to standards, their implementations vary significantly resulting in difficulties such as interoperation with other or existing networking equipment. Information models assist to alleviate the problem of vendor interoperability by providing a common source for the definition of data and information on which solutions can be based upon. Thus solutions based upon the one information model will provide consistency in the interpretation of information from heterogeneous network environment and add efficiency in the exchange of this information between systems and the business processes they support internally and externally to an enterprise. The SID information model is one such model. It has been developed by the TMF to provide a common repository of information or data for business processes in
the eTOM. Our focus for this paper will be upon the use of the SID in understanding the information flow for business process flows and consequently the relationship between this information and the processes which use it. eTOM The eTOM, recently endorsed as a Recommendation M.3050 by the International Telecommunications Union (ITU), is an initiative by the TMF to define a business process framework for Service Providers and others within the telecommunications industry. This framework better known as the eTOM framework is to serve as a business process reference model for those in the Telecommunications industry. It will assist them in categorizing, understanding, determining, and modeling, the required interactions and relationships of business activities within their organization to carry out end-to-end processes and consequently meet their organizational goals.
ongoing initiative. Some Domains such as the Enterprise Management Domain are still under construction and incomplete. Hence not all business process elements have been coupled to aggregate business entities.
B.
C.
SID The SID or Shared Information/Data model like the eTOM is an initiative by the TMF and represents the information or data elements contained within the knowledge base of the NGOSS. It is one of many information models available from standards bodies. Its’ focus is on what information/data or static things are of interest to the business rather then dynamic interests or processes which the eTOM addresses. In other words the context or process in which a thing participates can be viewed as a dynamic interest to an enterprise whereas an entity with attributes such as a customer in a process is perceived as a static thing of interest. SID entities many of which are still undergoing development are encompassed in a framework consisting of areas. These areas are known as Domains and form the framework in which the things of interest or entities to the business are contained. The SID domains are illustrated in figure 1 below:
Figure 1: SID Domains
The SID can be decomposed into further detail or levels. This further detail is represented by Aggregate Business Entities which Domains are composed of. ABEs represented by the white boxes in figure 2 represent information and operations belonging to a closely related group of Business Entities. With the knowledge and description of Aggregate Business Entities it is possible to couple them with the business process elements as defined in the eTOM. This will in turn provide a business viewpoint on the data/information. However the SID model is still an
Figure 2: SID ABEs
II.
FAULT MANAGEMENT
A. Fault Management Overview Fault Management is one of five functions identified by the International Telecommunications Union to categorize the offerings by network management systems. These five functions include Fault, Configuration, Performance, and Security and combined is commonly known as FCAPS. Fault Management encompasses many tasks and activities including detection, isolation, and correction of faults; adjustment or reconfiguration in the network environment; maintaining and examining error logs, accepting and acting on error detection notifications, tracing and identifying faults, carrying out sequences of diagnostics tests, correcting faults, reporting error conditions, and localizing and tracing faults by examining and manipulating database information To support these activities and meet the increasing demands of customers Service Providers are seeking new ways to improve their fault resolution processes. This not helped by the increasing complexity of networks caused by the large array of network devices on the market and the varying standards used. Hence the fault resolution process is becoming increasingly complex and a number of key areas of this process need to be addressed. Theses areas include but are not limited to: • Improving the communication between the customer and the Service Provider to detect and notify of troubles more quickly and effectively. • Understanding the importance of services and recognizing the relationship between service problems and resources. • Automating and reducing the manual intensiveness of fault diagnostics. The improvement of communications between customers and Service Providers is driven by the need for a common understanding of the information and data shared between the two parties. A number of information standards and recommendations are discussed. The relationship between services and resources needs to be better understood due to the need now to analyze the levels of quality required to be delivered to customers; the
failure of a resource can have a major impact on the ability of the SP to deliver a resource and hence can impinge greatly on business success or failure. B.
Detection and Reporting of Problems The terms alarms, faults and trouble are used within Fault Management. Alarms are regularly associated to the element layer and network elements. These can be of various types ranging from informational, warnings to severe. Multiple alarms if severe are correlated and recognised as due to a fault or malfunction within a physical (network element, port, power supply etc) or logical (link, termination point) resource leading to a fault within the network. After fault localisation and analysis the fault might be declared service affecting and impacting on a customer. The term fault is regularly associated with the network layer. A corresponding trouble ticket is created to represent the activity needed to resolve the fault. The previous activities would be called proactive fault management. A customer might report a trouble or initiate an inquiry which after investigation, called reactive fault management, might relate to an existing fault for which Trouble Administration will create a trouble ticket or find an existing trouble ticket. The term trouble is regularly associated with the service layer. Preventative fault management is usually conducted by deliberately injecting events by the Service Provider to evaluate what-if scenarios [3]. The detection and reporting of problems particularly for reactive and proactive cases is becoming a more complex task. As a result of the need for Service Providers to establish a greater customer focus as well as remain within agreed service levels trouble management has become more demanding, requiring a greater amount of functionality and efficiency. Trouble management (often referred to as trouble administration in older standards) is the means of handling problems systematically [4]. These needs can be addressed through a greater coordination between the trouble administration systems belonging to all the players within the network. As customers demand and service providers are required to ensure end to end accountability, all customers and service providers, service providers and their network providers and service providers to service providers need to interwork. Through the coordination of systems between providers and customers, automated and standardized trouble administration interface can be implemented resulting in greater efficiency of trouble administration processes and increased opportunity for greater functionality in these systems. In order to provide information regarding service troubles they need to be presented and available in a form which is understandable by the customer management systems in each of the communicating domains. Hence a generic format for a trouble report which entails the details of the problem along with a generic interface needs to be defined [5]. This will support the interoperation of the customer service management systems in each domain or communication between the layers of a service hierarchy. C.
Standards and Related Work Currently, a number of standards are available in relation to the management of troubles from various forums and bodies. These standards include X.790 from
the ITU, TMF501 (NMF501) and TMF601 (NMF601) from the TMF and RFC 1297 from the IETF. The X.790 recommendation from the ITU-U is defined to be concerned with the management of malfunction in systems and communication networks from the perspective of a provider of service and use of that service, where malfunction is known as “troubles”. X.790 defines a trouble report format for customers to present problems through to the service provider’s customer interface and have the reported problem advanced for resolution. This format is represented by a base class called Trouble Report and two derived classes called Telecommunication Trouble Report (TTR) and Provider Trouble Report (PTR) [5]. The TTR is used by customers to report problems to the service provider whereas the PTR is used by service providers to notify customers of a trouble. An inspection of the X.790 Information model reveals it is telecommunication nature. The naming conventions and many of the attributes and values of the report formats imply an application to telecommunications equipment and telephony services [5]. For example, trouble type values such as noRingNoAnswer, hungUp, dialToneAfterDialing, doNotAnswer, and speedCall are quite telephony specific [6]. Enhancement with a more service and data attributes would be positive. The TMF addresses the customer to service provider interface exclusively in its documents NMF501 and NMF601[4, 7]. NMF501 details the business requirements or drivers, context and scope, trouble administration process, technical requirements, and specific trouble administration interface functional requirements, for the customer interface between providers and customers to exchange and manage trouble information. NMF601 defines the functionality and information for the exchange of management information to meet the requirements defined in NMF501. The trouble administration system modeled by the TMF defines a Customer Trouble Ticketing domain (CTT) in which two system objects, Customer Trouble Ticketing – Customer (CTT-Cust) and Customer Trouble Ticketing Service Provider (CTT-SP) interact via interfaces. These include Customer-TTR interface, TTR-Notification interface type, and PTR-Notification interface type. The Customer-TTR interface type consists of operations which can be invoked by a user on the customer end to create and track a X.790 telecommunications trouble report (TTR). The TTR-Notification interface type encompasses operations available to the service provider for invocation when the customer needs to be informed of events related to TTRs. A X.790 Provider Trouble Report(PTR) and PTR-notification is used by service providers to inform the customer of events, status changes for planned maintenance on a telecommunication service. A full life cycle and detailed use case scenarios are provided. The IETF NOC TT Requirements (RFC 1297 [8]) provides a description of the general functions of a Trouble Ticket System (TTS) that could be designed for Network Operations Centers (NOC). RFC 1297 is quite general in its description of the requirements of a trouble ticketing system as its primary audience is the Internet community whose interest lies in operator-level application tools for network operations. Consequently the document is somewhat informal [5] and unlike the
recommendations from the ITU-T and TMF it does not provide a detailed information model which service providers and developers can use as a basis to implement their own customer trouble management systems. An implementation of the TMF model is described in [9, 10].within a TINA-C environment using a CORBA interface and a commercial trouble ticketing system. As TINA-C separates the service aspect from the network layer, a TINA Service (TINA Trouble Report System TTRS) is defined interacting to the network layer TT System. In [5] a model of a generic data structures that caters for the needs of IT environments based on above structures is presented. The generic data structure is termed Customer Service Management Trouble Report (CSM-TR). The CSM-TR is formed by finding the common attributes from three sources – TMF and ITU-T trouble defined attributes and other trouble ticketing systems. The set of common attributes are defined as those which have similar semantic meanings and are relevant to the exchange of problem management information in an IT environment. The OSS/J Trouble Ticket API [11] defines a design and implementation of the TMF model using the very specific java, javabeans, JMS technology. The OSS/J project has recently committed to align itself to using SID entities. Some rework of existing will be required especially as [11] was finalized before that. As seen each of the standards described provide their own contributions towards the development of trouble management systems between service providers and customers. The ITU-T and TMF models define detailed trouble report formats while the IETF recommendation provides some useful input and suggestions which can be built upon. What is missing is a model derived from a representation of all information flows within a service provider domain and external to it the customer domain and other service providers in a value chain. A process flow of all business activity in a SP environment is represented in the eTOM. ETOM PROCESS FLOW III. A trouble resolution process involving a SP and their customer(s) can be modeled using the processes defined in the eTOM. As an example of one the processes we focus on the case of a reactive trouble resolution process – when a customer initiates the trouble process being informing the SP of the occurrence of a problem for a product. To provide a concise explanation and highlight the use of eTOM process flows we examine an interaction between the customer and SP which may be part of a larger process flow at both eTOM levels 2 and 3. The eTOM process flow in figure 3 consists of a number of steps. These steps are only a part of a larger process flow. The purpose of each step could be explained as follows: 1. Customer reports problem.
Figure 3: eTOM level 2 process flows
2. 3.
Customer Interface Management accepts the Trouble notification from the customer and passes a report to Problem Handling for processing. Problem Handling receives the report and determines if the reported problem is new or has been received previously. If the reported problem is new or contains new information, then a trouble report or Trouble Ticket is created or a current report is updated for the customer respectively. If the trouble notification from the customer is for a problem previously reported then this is made known to the customer and the trouble report is closed. The closed report is analyzed and any useful customer data is recorded.
Figure 4: eTOM level 3 process flows
The eTOM can be decomposed into further detail or another level – level 3. Figure 4 depicts the level 2 eTOM process given earlier in its level 3 form. The steps used can be explained as follows: 1. A request is made by a customer to the Service Provider to investigate a possible problem with a Service provided to them. 2. All points of contact a customer will have with a Service Provider will be conducted via Customer Interface Management processes. As such the customer’s trouble report is initially received and handled by the Manage Request process. Manage Request passes the customer’s report to Manage Contact to identify the customer. 3. Manage Contact process identifies the customer who is making the request and passes the result of its verification back to Manage Request. 4. Once the identification of the customer has been verified by Manage Request, details of the problem and customer are sent Report Problem. 5. A new trouble report is generated if required or the existing report provided by the customer is used to be passed on to other processes for
further analysis. Report Problem passes the trouble report to Isolate Problem & Initiate Resolution. IV.
Based on the eTOM specification and the processes involved a table is developed that makes a correspondence between the business processes defined in the eTOM and level 1 ABEs defined within the SID documentation. This table was based on and further developed from the inputs and sources defined in [12]. Some of the relevant parts of the mapping table for this discussion are reproduced in Figure 5. Note that there is not necessarily a one to one relationship between an eTOM process and a SID ABE. The SID has Trouble related ABEs identified, such as the CustomerProblem, ProductTrouble, ServiceTrouble, ResourceTrouble. These will need to be associated with Trouble. Management Domains (SID Lvl 0)
Cust. Problem Handling
Customer
Customer QoS/SLA Management
Product Customer Product Service
Service Problem Management Service Quality Analysis, Action & Reporting Resource Problem Management
Level 2: Customer Interface Management
FROM ETOM TO SID
A. Mapping the Interaction
eTOM Level 2 Process
eTOM process step xx
Service Service Resource
Resource Quality Analysis, Action & Reporting
Resource
Resource Data Collection, Analysis & Control
Resource
Aggregate Business Entities (SID Lvl 1) Customer Problem Customer Bill Inquiry Product Performance Customer SLA Product Trouble Service Test Service Trouble Service Quality Service Outage Service Trouble ResourceProblem ResourceConfiguration Resource Trouble Resource TrafficUsage Resource Performance Resource Trouble Resource Performance Resource Usage
Figure 5: Mapping eTOM to SID
This has been furthered developed by examining every step in the processes defined above for the trouble resolution interaction, its information flow and entities involved. The requirement is to identify each ABE and finding its corresponding SID entity and attributes used in the interactions. An example of the format and its breakdown to show the effected SID entities of one the processes steps is provided in Figure 6. Manage Request process handles the interaction with the Customer notifying them of the status of their trouble. It is uses the base concept of TTR Notification of NM501 to achieve this.
Level 3: Manage Request Description: An (optional) outbound notification regarding the restoration of the trouble is made. This involves a business interaction between the customer and the Service Provider. SID Entities Used: ABEs Customer Interaction
SID classes & subclasses Business
Attributes used id, interactionDate,
Interaction
Description
TR
notificationDescription,
Notificatio
notificationDateTime,
n
notificationPriority
Customer Problem Figure 6: Detailed Level 3 and SID
B. Derived Trouble Report Information Model From the eTOM problem resolution process we can follow the flow of information from one process to another. This includes the attributes which are touched upon at each stage and were explicitly highlighted in the tabulated descriptions previously. Most of the surrounding entities, and their attributes were acquired from the SID model. The Trouble entities have been influenced from other information or data models of Trouble which include X.790, MNM Service Model from [5], and NMF 601 model. The classes, subclasses, and attributes which have been added or derived from the other information models for the SID are further explained below. The SID is described using UML. The SID uses three of the four layers of the UML, namely the MetaModel, Model and user objects layer. The MetaModel layer is extended through sterotypes, such as entity, entityspecifications and associations. The SID uses as one of its basic design patterns, the Entity-EntitySpecification pattern. This pattern differentiates the entity and its associated characteristics and behaviour of an entity by modelling them as a specification. This separates the entity from its characteristics that are common. In this pattern other associations are made between other interacting entities and the entity. In the SID the domains of Product, Service and Resource are modeled using this pattern. Thus there exists a model of Product and ProductSpecification, Service and SeviceSpecification and Resource and ResourceSpecification. Thus a Customer is offered a Product which is defined by a ProductSpecification. The Product can be composed of services which they are defined by a ServiceSpecification utilising underling Resources which are defined by ResourceSpecificattions. The SID also differentiates also by discussing a e “customer facing” view and a “resource facing” view.
We model a Trouble as a Trouble entity with a TroubleSpecification entity. This allows to differentate between types of trouble reports. This can act as the base Trouble entity that is modeled in X.790. As mentioned previously the X.790 requires a Telecommunication Trouble Report (TTR) and Provider Trouble Report (PTR). We use the TroubleSpecification entity to act as the base class to allow for the two different reports needed, TTR, and PTR. From these we can derive further specific reports more tailored to the resource or service type. Also it converges with the idea of customer facing view and resource facing view. The Provider has naturally a resource view and similiarly the customer with his view. MetaModel Layer
Model Layer
Product Trouble
describes
ProdSpecDescibesProd
ProductSpecification
TroubleSpecDescribesTrouble
TroubleSpecification
CustomerFacingTrouble
ResourceFacingTrouble
TTR
PTR
have been initiated by the Customer as a reported error as described in the above mentioned reactive fault management scenario. The PartyRole of Customer as the effected user or organization is thus modeled. The SP staff involved in the resolution of the trouble as representative of the SP organisation is also modeled using the same entity the PartyRole. In passing we note the inherent existence of a customer facing view and a resource facing view within the modeled PartyRole. Alarms, faults and outage on a Resource are modeled in the SID as entities within the Resource ABE. A Resource is differentiated as LogicalResource, PhysicalResource and Network, each having their own EntitySpecification within ResourceTrouble. Thus an alarm, fault or outage can be associated with a LogicalResource, PhysicalResource and Network entity. The SID cites derived entities LogicalResourceFault, LogicalResourceAlarm, and LogicalResourceOutage, and similarly for PhysicalResource and Network. One of each is shown in figure below. Fault
aggregates
Alarm
Outage
PhysicalRes ource
Figure 7: Entity and EntitySpecification for Trouble
On a change of status of the Trouble (create, deferred, cleared, close, StatusUpdate etc) a Notification is required to the interested Parties. A Notification is an event which implements the requirements of NMF501 TTR and PTR notifications over the CCT interfaces. In the SID model, a Customer buys a Product that is a “customer facing” view of a service. This pr aggregated of Services and utilises Resources. The Trouble in the proactive or reactive fault management use cases is associated with Product, Service and Resouces. More specifically with the defined EntitySpecification of Product, Service and Resouces. Thus a Trouble has an associations with all the EntitySpecifications mentioned. A Trouble can be an aggregate of other troubles. Thus there is an association of the Trouble to itself. This allows for a Trouble processes to correlate to other reported Troubles. It further allows for a Trouble History Report to be produced, a requirement of a X.790 ProductSpecification has a
Trouble
TroubleSpecDescribesTrouble
NetworkFault
NetworkAlarm
PR_Fault
PR_Alarm
LR_Fault
LR_Alarm
NetworkOutage
Resource
Network
PR_Outage LR_Outage
Figure 9: Alarms, Faults and Outage
A similar styled structure is cited for the Service ABE, where CustomerFacingAlarm and ResourceFacingAlarm, as well as for Fault and Outage is mentioned. During the processes within the Reactive and proactive fault management stages as outlined previously, these entities become associated with a Trouble. Our model shows the advantage of discussing the environment in the context of other SID entities. Other Core entities from the SID used are the Location and Calender entry classs for time stamping the troubles and notifications. Other types of reports made be derived from the two basic reports. As an xample an customer informing update termed a status report would be derived asa subset from the TTR. We also note the interaction of NMF 501/601 classes.
ServiceSpecification
TroubleSpecification
V.
aggregates emits TT(n) can be associated with previous TT (n-1) creating TT history report
Logical Resource
ResourceSpecification
Notificatiion
Notification implements TTR_Notify PTR_Notify
Figure 8 TroubleSpecifiction
A Trouble report is associated with a PartyRole. This is the SID model of interaction with a Party (person or an organization) that have specific functions or roles. A Party might have a number of Roles. In the eTOM Value Chain one SP organization might be a Customer to another SP and hence the PartyRole can de different dependent on the activity in the Value Chain. In our case Trouble might
TELCOLLABORATION SERVICE
A. Experiment CeNTIE UTS Telecollaboration Project [13] has researched the use of Telecollaboration in the context of desktop devices. We used the freely available CXP API from MSR as the base tool for the Telecollaboration application [14] for desktops. We have used the standard capabilities provided (video, audio and chat) and enhanced and added collaboration application components (Shared Editor, Voter, Meeting Note Taker and Scheduler for Meeting) and uses the CXP APIs’ for sending and receiving objects over the internet, wan or lan. The UTS CeNTIE group have been using the developed tools to enhance their telecollaboration meetings and have
incorporated internal feedback to further better develop these components. TroubleTicket/ Troublereport/ Problem aresynomous. eTOMGB921DinProblemtriesto differentiatethat aProblemreports iswhenanussuederivesfromcustomer whileTTderivesfromnetwork or elementlayer. However itusesthese terms interchangably ServiceLevelSpecification
ServiceLevelObjective
ManagedEntity ManagedInfo
TroubleAdministration-functionset-(M.3400) Troubleadministrationtransfers troublereportsoriginatedbycustomersandtroubleticketsoriginatedbyproactive failuredetectionchecks. It supportsactiontoinvestigateandclear thetroubleand providesaccesstothestatusof servicesandtheprogressinclearingeachtrouble Resource
Service
Problem/Trouble
Party
ResourceSpec ServiceSpec
Event
Report
specifications. Using the SID framework we remap the components into SID framework of Product, Product atomic, service and resources. This way we have included the notion of the service as it seen to the customer as Product. This is what is sold to the customer. The product is composed of some atomic products. The customer chooses what the constituents of the product he elects to work with. In the service plane the TCS is represented by the TCS service components and Connectivity services. They can be subdivides into TCS host services are application services and persistency services The resources that they require with of are in the include in the resource plane.
Product
TT(n) canbeassociated withpreviousTT(n-1) creatingTThistoryreport
ResourceConfiguration
Product (Atomic) Notification
ServiceConfiguration
FaultInfo
-Status +Description +Priority +DateTime
TT(n)
Trouble Report RF_Trouble
CF_Problem
Ntwk Topology
TT(n-1)
Notificationpublishesanstatuschangeof theTT asmentionedinNM501TTRinterface. Thesecanbecreate, closeor statuschanges. ThesecanbebetweenCustoriginatedtoSP,SP- SP andSPtoCust.
TC-Chat
Service
TCS –
TCS -
Basic
Premium
TCC Service
TC-Audio
TC-Video
TCA Service
……… Service
Logical Resources
WorkSpace
Protocol T.120
Protocol G.711
Figure 11: Associating TCS to SID Domains
ServiceProvider ReportisaSPviewof Service/Resourcefacingreport of theTrouble
Connectivity Services
Location
CalendarEntry
RF_Trouble Report
TC- Editor
CF_Trouble Report
StatusReportisaCustomer facingreport updatingonthecurrentstatusof theTrouble
Figure 10: Trouble in SID context
We have positioned the Telecollaboration applications as exemplars of advanced services (Telecollaboration Service – TCS) over the CeNTIE network. As an example of the tools the Collaboration Editor provides the user with the capabilities to collaborate with other participants in a venue and to create/edit a mutual collaborative document. The nature of the venue is distributed and each participant transmits his/her updates, in a pseudo-parallel manner, to a local copy of the document at the participants’ sites via a Real-Time-Protocol (peer to peer). Each participant sees others participants’ updates, caret location movements and activity percentage in “realtime”. Another tool, the Voter allows collaborative voting capability. At a collaborative session at various times during a session in a ‘venue’ a vote might need to be taken after an issue has been raised and discussed. It announces a topic as a question receives and collates responses as votes and shows a tallied vote. In our environment a tool bundle used is a Product within the Product Catalogue. They in turn rely on underlying Services and defined by (elementary) service
Protocol H.261
We have enhanced our application suite to incorporate and support fault management reporting via Web and XML based portal. An early prototype of the interface has been developed and implemented. The interface allows for the implementation of the CCT_Cust and TTR_Notify interfaces derived from NMF 501/601 requirements. Our enhancements allow for a session and service specific CCT_Cust interface to be instantiated via a session specific web page identified for this Product and associated services. Within this webpage the two interfaces of CCT_Cust and TTR_Notify are enabled and made available to PartyRoles, who act as the customer user and SP administrator. The user interface and administrator interface allows for the creation, change of status of Trouble tickets (CCT_Cust) as well as the place where the SP can report the status and (hopefully) closure of Trouble (TTR_Notify). The advantage of utilising a Web based interface is seen when the service’s basic communication capabilities might have been compromised. The service’s communications device might no longer be capable of being used effectively. The CCT/TTR interfaces however are made available to any web enabled device including hand-helds. On the start of a session after the standard login are accepted, a unique session id is created for all collaboration participants. This can be used as seed for the individualised Trouble page. It is important to note that this page is not required to be used nor has a trouble ticket been created but the interfaces have been made available. It is there only when required. When a fault is obvious it is utilized to either enquire about a Trouble or create a Trouble instance. As it is and individualized Trouble page only relevant Troubles to this session are revealed. Troubles reported included service and network layer issues. They included loss of continuity in video and sound streaming, breakup of the video, introduction of
artifacts on video, speed of updates, loss of application data etc. The Trouble resolution proceeds through eTOM processes such as Fault localisation, Root cause analysis as prescribed. Relevant information is updated in the Trouble ticket. Update information is available on the via the TTR-Notify interface. On resolution of the Trouble status is changed, user notified who verifies resolution of malfunction and Trouble is closed. B. Discussion The environment in which Service Providers operate is becoming increasingly innovative, competitive, and customer focused in nature. In an effort to accommodate these changes Service Providers have reacted by adapting past standards and methods to their current systems. It is interesting to note that use of the integrated information model for one component of the model allows for natural access to related and associated information. This is seen in our case where the individualized Trouble page has at its instantation access to the associated ServiceSpecification and ResourceSpecification instances of the associated service and resources used in the session. The implementation of the NMF 501/601 CTT interface with the values supplied by X.790 reveals that it fulfils a very specific telecommunication industry requirement. These will need to be enhanced to reflect the changing resource, service and application requirements. Furthermore as the industry moves forward, the line between telecommunications and IT infrastructure is become blurred as Service Providers become aggregators of other third party Service Providers in a Value Chain. This will be a driver for Service Providers to integrate their systems with other Value Chain actors, such as customers, third party providers and suppliers. Information models as mentioned earlier are a key component to making this possible by defining the functions, data, and information that needs to be exchanged between the different parties involved in a business process lifecycle. The goal of the SID is to provide a common data and information reference by which all the varying stakeholders or constituents of the Information Communication and Service Provider industry can use for their services and solutions. The SID work is still evolving and not been complete. There are still many things of interest or entities which have yet to be defined or expanded upon. The study of the requirements, methods, and technologies for trouble resolution processes has identified some contributions which can contribute to the SID model. In particular the area of Trouble Reporting, which is an essential part of the trouble resolution process as it not only provides a central reference for the Service Provider on a fault but as shown with diagnostic systems, it can be used to add a level of automation to the fault resolution process. As such the suggestions have been made for a trouble report classes to accommodate the Customer to Service Provider interface as specified in the NMF and X.790 recommendations. These can be incorporated into the SID as a part of the service trouble aggregate business entity. The SID complemented by the eTOM is a powerful enabler for the Service Provider. The eTOM not only provides a perspective on the relationship between
processes within the business but also between itself and business partners and customers. The SID as discussed defines the entities which are required for each of these activities. When combined the eTOM and SID can provide a flow of activities for an end-to-end business process but also give a perspective of how information is shared amongst or between these activities, that is, an information flow. VI. CONCLUSION The eTOM has existed for sometime and is quite thorough in its definitions of processes for the Service Provider business. It is now recognized by the ITU-T as standard M.3050. The SID as its information model however is still largely an ongoing or developing initiative of the Telemanagement Forum. We have provided a information model design for the Trouble entity adopting the style of the SID and discussing its usage and incorporation with other SID entities. The use of the information model has allowed an implementation of the Trouble customer to service provider interface to be more efficient by automatically referencing associated entities and allowing for trouble data population efficiently. REFERENCES [1] [2] [3] [4] [5]
[6] [7] [8] [9]
[10]
[11] [12] [13] [14]
TMForum, "www.tmforum.org," TeleManagement Forum Web site. Y. Yemini, "The OSI network management model," Communications Magazine, IEEE, vol. 31, pp. 20-29, 1993. K. Terplan, OSS Essentials: Wiley Computer Publishing, 2001. TMForum, "NMF501- Customer to Service Provider Trouble Administration Business Agreement," August 1996. M. Langer and M. Nerb, "Defining a Trouble Report Format for the Seamless Integration of Problem Management into Customer Service Management," presented at Workshop of HP-OVUA99, 1999. "Introduction to X.790," P609 Deliverables Eurescom 1997. TMForum, "NMF601- Customer to Service Provider Troulble Administration Information Agreement," March 1997. IETF, " NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT Requirements")," 1992. R. O. Sinnott, T. Gringel, M. Tschichholz, and W. Vortisch, "Supporting Service Quality Assurance via Trouble Management.," presented at Managing QoS in Multimedia Networks and Services, IEEE/IFIP TC6 WG6.4 & WG6.6 Third International Conference on Management of Multimedia Networks and Services (MMNS'2000), September 25-28, 2000, Fortaleza, Ceara, Brazil, 2000. N. Agoulmine, D. Dragan, Gringel, J. Hall, E. Rosa, and M. Tschichholz, "Trouble Management for Multimedia Services in Multi-Provider Environments," Journal of Network and Systems Management,, vol. 8, 2000. P. Gauthier, "JSR 91 OSS/J Trouble Ticket API," 02 February 2002. TMForum, "Shared Information/Data(SID) Model Concepts, Principles, and Domains- GB922 ." CeNTIE, "CeNTIE UTS Telecollaboration Project," http://www.telecollaboration.eng.uts.edu.au. MicrosoftResearch, "ConferenceXP API vers 3.0." http://www.conferencexp.net.
