Summary

Recommendation X.790 (95/5): This recommendation is concerned with the management of malfunction in systems and communications networks from the perspective of a provider of service and user of that service. In the document these malfunctions are referred to as 'troubles'. A report is defined to allow a user to report a trouble, which will then be progressed to resolution by a provider. During the resolution by the service provider, the service user may determine the current state of resolution by issuing a request for this information. When cleared the provider may notify the user. Particular types of trouble are included, however the use of this recommendation by a particular application may require trouble types specific to that application to be used — this is catered for in this document.

In short: the recommendation specifies the interworking to convey information between distinct TMN systems on troubles and their resolution; not how to resolve troubles within in a network.
This all is commonly known as Trouble Ticketing (TT).

Scope

[X.790] From time to time all systems including communications networks develop problems or malfunctions referred to in this document as 'troubles'. A 'trouble' in a communications network is a problem that has an adverse effect on the Quality of Service perceived by the network users. When a trouble is detected, maybe as a result of an alarm report, a trouble report may be entered by a user or the system may raise a report automatically. Management of that trouble report is necessary to ensure that it receives attention and is cleared to restore the service to its previous level of capability.
At the time of trouble, a network may have been interworking with another network to provide a service, and the other network may be causing the problem. Therefore, agreed international standards are required to enable trouble management information to be exchanged across interfaces between management systems which may be client-to-service provider or service provider-to-service provider interfaces and may represent inter-jurisdictional as well as intra-jurisdictional boundaries.

So, Trouble Ticketing is concerned with the exchange of information across management boundaries (domains) between:

customer and service provider (e.g. network operator);
service provider and other service provider (i.e. the first provider is acting on behalf of his customer for 'global' services); or
between regional management domains within a service provider.

And, in order to exchange and handle information, it should be standardized.

Two non-TMN OSSes may exchange (trouble) information automatically according to TMN standards (by a reverse QAF); this is known as Electronic Bonding (EB).

Functionality

[X.790] The scope of this document is to specify the Trouble Management functionality for:

reporting of troubles on services or resources on a managed network or system;
tracking the progress of trouble to resolution;
clearing and closure of trouble.

Trouble Reports describe the nature of the problem (troubles on services or resources) as well as ongoing status. {By origin there are two reasons for Trouble Tickets:

Complaints

A customer reporting loss of quality to his provider;
A service provider may –after investigation– have to report this to the 'other' provider; and

Notifications

A service provider detects loss of quality (e.g. due to network failure or a threshold crossing alarm); or
A service provider announces loss of quality in advance (e.g. due to planned maintenance).

A service provider may have to forward such information to his customers by (SLA) contract.}

Once a trouble report is instantiated (the trouble ticket exists), there will be requests for information, responses and notifications (progress reports, ultimately the closure of the Trouble Ticket).

Note that when problems do not affect customer services, it is not necessary to send Trouble Tickets (though the operator may use the mechanism internally to track problem solution).

Application

[X.790] In general Trouble Management is the trouble reporting and tracking between Conformant Management Entities (CME) interoperating cooperatively towards resolution of a trouble (no distinction is made between inter-jurisdictional and intra-jurisdictional interfaces). A trouble report gets instantiated for this purpose. In cases where CMEs are interoperating cooperatively towards the resolution of a trouble, it means that both manager and agent CME may have a shared responsibility for resolution of trouble.
The trouble management function recommendation is one that may be used by a CME acting in:

a manager role to manage trouble(s) and any corresponding trouble report(s) that have been raised to an agent role CME for resolution;
an agent role responsible for resolving a trouble(s) and corresponding trouble report(s) that have been raised to it by a manager role CME;
both an agent and manager role to manage trouble(s) and any corresponding trouble report(s) that have been raised internally (i.e. top the part performing the agent role) by another part of itself performing the manager role. In this case the CME itself is responsible for resolving the trouble, but in addition, the CME may also inform other manager role CMEs that are part of the cooperating networks, if they are liable to be affected by the trouble or can help with trouble resolution.

So, in order to resolve 'trouble', the management systems of operator and customer (who could be an operator acting on behalf of his customer) have to cooperate. For the cooperation these management systems should be standardized, hence the 'Conformant Management Entities' (CME). However, the definition can be performed dynamically as a subset of existing attributes.
The cooperation is the common manager/agent-relationship, where the agent is responsible for trouble resolution, and the manager for management of trouble reports and tracking of resolution. The CME at the customer has the manager role, the CME at the provider/operator the agent role, and in the manager role for trouble resolution for internal purposes.
Apart from that, as the trouble may originate in the network of another operator (service provider), the CME may also have to act as manager towards the other operator.

States

Queued: A trouble report is in a queued state when it has been instantiated but the trouble resolution process has not yet been initiated.
A trouble report may be cancelled by the manager. The agent on receiving such a request will attempt to close the trouble report.
Open/Active: The trouble report becomes 'open/active' when appropriate actions to resolve the trouble are initiated.
An 'open/active' trouble report may be 'referred' to another Hand-off Person, or 'transferred' to another Responsible Person for further processing. The state however remains unchanged as 'open/active'. {This includes potential escalation procedures or forwarding to other service providers.}
A trouble report may be cancelled by the manager. The agent on receiving such a request will attempt to close the trouble report.
Deferred: This state indicates that corrective action to resolve the trouble has been postponed. This can occur when the faulty resource is inaccessible for a period and repair activity can not proceed.
A deferred TTR may become 'open/active' again, or move directly to the 'closed' state if it is canceled for some reason.
A trouble report may be cancelled by the manager. The agent on receiving such a request will attempt to close the trouble report.
Cleared: A trouble report moves to the 'cleared' state when the trouble has been corrected. If the manager needs to verify that the trouble has been resolved, verification may optionally be awaited by the agent prior to closure of the trouble report.
Closed: This state indicates that the trouble resolution process is complete. Upon closure, the trouble report attributes are captured in a historical event generated at trouble report closure which may then be stored in a log of of trouble history records, for future reference. The trouble report may then be eliminated at the agent's convenience.
Disabled: A 'disabled' value is exhibited when a trouble report's information cannot be updated due to local conditions. In the 'disabled' condition only read operations can be performed. This state can be entered from {all} other states due to local conditions.

Trouble reports

There are two distinct trouble reports:

TTR: Telecommunications Trouble Report is a superset of the information necessary for both the client to service provider and service provider to service provider relationships. The distinction between a client to service provider and a service provider to service provider relationship on an association will be by the selection of a suitable profile and negotiation of appropriate functional units.
It has an extensive definition: 104 (!) attributes, many of which are 'list of sometype', 'reference to some_entity' and/or are optional.
PTR: Provider Trouble Report object has been defined to address specific additional requirements in other recommendations.; This is an extremely restricted subset of the TTR; it is only meant to convey provider network troubles. Just read-only operations allowed.

There can be separate TTR and PTR objects regarding the same trouble ?
Obviously, a lot of information will be the same, e.g. Begin_Time, End_Time, Location_Ptr (location of origin of trouble report), Unavailable_Service_Ptr (affected services).

The Trouble Report Administration model allows multiple Trouble Report formats as defined by instances of the Trouble Report Format Definition (TRFD) object. Each Trouble Report format is a predefined combination of trouble report attributes. The Trouble Report format applicable to a particular CNM-service-managed or -managed object instance can be dynamically specified by the service provider through the Trouble Report Format Definition object. {!!!}

When the Trouble Report format is explicitly defined through the Trouble Report Format Definition object, a Telecommunications Trouble Report instance shall consists of:

the mandatory attributes of the TTR (as defined in the TTR object definition);
the attributes in conditional packages of the TTR that 'must be present' (as defined by the corresponding TRFD object);
optionally the attributes in conditional packages of the TTR that 'may be present' (as defined by the corresponding TRFD object).

Details

As it is not very useful to give an overview on all 104 attributes, only the main attributes and all actors (persons or organizations) involved are described here in short. Note that 'manager' and 'agent' indicate the respective CMEs.

A specific problem for definition of problem management, is that it has to refer to the service which experiences loss of quality, but that no Service Model has been defined in any way in the standards. Therefore, they preliminary define 'CNM Service' and 'Account' objects.

Trouble Report State: As defined above: Queued, Open/Active, Deferred, Cleared, Closed, Disabled.
Trouble Type: Identifies the category of trouble that is being reported.
Perceived Trouble Severity: Allows the manager to indicate the effect of the trouble on the managed object.
Preferred Priority: The urgency with which the manager requires resolution of the problem.
Related Trouble Report List: Identifies other associated trouble reports.
Additional Trouble Information List: Describes further the selected Trouble Type. A minimum of 256 octets shall be supported, regardless of the number of values in the set. The manager can only add information, but not remove it. It is possible that the oldest information may be lost if an implementation has restrictions on the maximum size.
Initiating Mode: How the trouble report was initiated (i.e. over interoperable interface, E-mail, fax, phone, …).
Trouble Detection Time: When trouble was detected. This may be different from the time at which the trouble report was created.
Dialogue: Enables interaction between agent and manager at each stage in the resolution. It is free format and a notification is emitted each time it is modified. New text may replace old text.
Alarm Record Pointer List: Points to instance(s) of the Alarm Record available in the agent system (when the trouble report was generated as a result of an alarm).
Service Identifier: Distinguishing attribute of the CNM Service managed object class.
Service Profile Description + Identifier: Explains a particular instance of the Service Profile in text, and provides the distinguishing attribute.
Customer: Always in the role of manager
Account Contact List: The individuals in the manager's organization who can be contacted regarding the account.
Additional Text: Contains additional pertinent enterprise information that describes the account.
Manager Contact Person + Alternate Manager Contact Person: Identifies an individual respectively an alternative individual in the manager's rganization who can be contacted regarding the trouble report.
Agent Contact Person: An individual in the agent's organization who can be contacted regarding the trouble report.
Trouble Report Status Window: Sliding window during which a 'trouble report progress' notification is expected (starting from the most recent notification).
Responsible Person: Indicates the person who has overall responsibility for solving the problem indicated by the trouble report. He or she may not be the person who performs the repair activities, but is the one responsible for the trouble resolution process, which includes tracking of the problem, isolation off the problem, and correction of the problem.
May delegate to another Responsible Person (i.e. for skills, domains)
Escalation List: Whether escalation is requested by manager and granted by agent. Optionally the level and the person.
Repair Activity List: Describing the specific repair functions performed, who performed them, and when.
Entry Time: When repair activity has been started.
Maintenance Organization Contact: The company or organization whose responsibility is to perform maintenance on the 'managed object instance' (called by the agent).
Activity Person: The operator or supervisor who created the repair activity request (WorkOrder).
Activity Code: identifies the general repair activity category [X.721].
Activity Duration: Time spend on billable or non-billable activities.
Location Access Person: Enables the manager to specify details at the location.
Trouble Found: Enumerated code identifies the problem resolved.
Commitment Time: Indicates either the on-site or trouble cleared time given to the customer.
Close Out Verification: Indicates whether the manager has verified repair completion, denied repair completion, or taken no action.
Close Out Narrative: Provides a place for the person who resolved the problem to document any additional information regarding the trouble report closure.
Hand Off Centre & Location: The service provider's control centre & location to which a trouble report has been referred.
Hand Off Person: The head of the Hand Off centre where the trouble report has been referred (assigned for resolution; agent side).
Hand Off Time: Time at which trouble was referred to Hand Off Centre.
Trouble Clearance Person: The individual in the manager's organization who has last modified either 'Cancel Request by Manager' or 'CloseOut Verification'.
Restored Time: Indicates when the trouble was cleared.
Outage Duration: The amount of time between trouble report receiving and clearing time, excluding any time for delayed maintenance or service not accessible for repair.

Next chapter: Interworking
Up to Contents
Up to Index

=O=