QoS Module in the Assurance process
Last update PvD
Issues
Overview
For proper operation (real-time), a lot of information is kept in Network Elements. Should this information also be kept in the EML management system, or even higher in the TMN to facilitate fast response to management requests ? Also, service options are often required at SML; should they be kept there as well ?
Such replication of information would speed-up management operations, and may serve as a back-up for the other system in case of a severe failure.
However, information replication will introduce mismatches with potentially severe consequences.
The straightforward answer: M.3010 says No in Shared Management Knowledge. It leaves the possibility open to cache information where desired. By nature, a cache contains hidden information allowing quick access, but is not the leading source of information; it can be made invalid (cache flush) by certain operations or events. One could apply some aging to the data; exceeding a time limit would then invalidate that data. Certainly, some information is semi-permanent, and the availability of notifications allows forced updates.
One should consider what kind of questions one wants to answer in each Operations Systems Function (OSF). E.g. for SML these are questions/complaints concerning service options, billing, QoS, and requires therefore the customer's service profile, last bill, and network performance data (all semi-permanent data).
Some information is not required by NEs and only required at higher level management systems (typical at SML, e.g. billing address), but for NML a lot of information is required from the Network Elements.
One must consider the leading source for all information: for equipment information it is obviously the NE, but for service data it is the SML. When starting network management it may be easier to use the lower level (NEL) data as leading, but it is basically wrong for service data: top level (SML) reflects the contract with the customer and is leading ! If there are mismatches, it is clear what direction the update must have.
The next questions {for developers} are how fast may the information change, and whether it is possible to acquire information from other OSFs sufficiently fast. If data is cached, when to flush it.
Many events –in particular network faults– cause an avalanche of derived events. Consider a cable cut on an STM-1 (SDH) fiber: apart from the 'signal loss' alarms from both sides, it may cause 63 E1 service alarms (or a multiple of that when using STM-16 and/or WDM). What when a node fails, all connected Network Elements will send alarms ! Such events will flood the TMN.
What can be done about this ? Performance requirements for a TMN (including the DCN) are difficult to state.
In general, performance management of the TMN itself is still a blank area.
The simple answer is to avoid consequential alarms and only report the 'root cause'. Sadly enough, commonly the root cause is not available, either because the root has no 'intelligence' (e.g. a cable) or the intelligence died with it (e.g. a node). But other 'equipment alarms' are available, and must be reported. It would be nice if some clever OSF would correlate the equipment alarms to a single root cause, but somehow this is not the practice.
In all cases, the tenths or hundreds of service alarms should not be reported. If you are interested in impacted services, you should (use a facility to) interrogate the TMN about services on the failed equipment.
In general, only alarms that indicate serious trouble for the network (i.e. impacting multiple users) should be reported (e.q. not 'loss of signal' of a CPE from a normal subscriber).
Most telecom suppliers (i.e. manufacturers of network equipment) also provide EML and some NML. Should network suppliers provide management systems for SML, or leave that to the IT-world (SML is basically in the IT-arena).
When buying network equipment, operators take the availability of management systems into account to select the network (equipment) supplier. They will look for proven inter-working between network and management system. This avoids interfacing problems and development delays, allowing them to go into operation from day 1: faster service creation is a major competitive advantage. As a consequence, the q3-interface to the NE has become irrelevant. In future the priority for selection might even reverse; operators may buy a network management system and select compatible network equipment (and the q3-interface is relevant again).
Network Management systems have different requirements than Telecom systems, see the comparison below:
| Network system | Management system |
|---|---|
| Dispersed system | Centralised system |
| Compact size | Large server |
| Rugged, uncontrolled environment | Controlled & climatised environment |
| Strict real-time response | Near real-time at best |
| Limited processor & memory capacity, commonly no disc | Multi-processor, large memory, disc arrays |
| Basic operating system | Full-fledged operating system |
Also not everything has to be immediately available (the operator would have a major organizational problem implementing a full TMN), but the supplier should show vision and commitment (it requires long term development to have all functionality in an environment with emerging/changing standards and emerging services).
An additional advantage for (Telecom) manufacturers to be in the NM area, is that you learn a lot more about the operator's problems and needs. This is certainly a marketing pro. However, the IT world is commonly not used to the stringent reliability requirements of the telecom world, and it is not easy to develop TMN components; it takes years before a fully satisfactory solution will be obtained.
Most telecom suppliers are organised by Business Divisions, where each division is developing network systems of a particular technology (e.g. a Transport Division, a Telephony Division and a Data Division). Each Business Division would therefore develop the required (Element) Management Systems to support the sales of their network elements.
That is clearly not a good approach: the management systems for distinct technologies have much more in common than a management system and a specific network technology (as we can see from the table above). It makes more sense to put all management system development in a separate unit. But that leads to a funding problem.
Management systems are required to sell network equipment, but the costs for developing management systems is commony higher than the price they can ask for. Within a Business Division the network equipment is subsidising the management system, but with a common unit developing management systems it becomes unclear how much each division should contribute. Operators will have to pay more for NM.
Suppliers used to sell only a few or even a single management system per operator, and often specially adapted for that operator. So the (considerable) development costs can only be amortized on a relatively small number of systems. Due to competition, cross-subsidizing of Network Management development by network equipment will stop. Hence, these systems will be relatively expensive {and some operators are not used to pay such prices}. Rigorous standardisation should make components suitable for many operators, and allow more acceptable prices. Currently, TMN recommendations now standardize a lot of network management functions, and Object Oriented development enables relative cheap adaptations.
On the other hand, operators can not live anymore without modern network management; they can not afford not to pay for it. And in the deregulated countries there will be several tens of operators (UK has 150; Finland 50).
Pricing strategy is important as small operators need nearly the same network management functionality as the large operators, but can not afford to pay the same price. The price should also reflect the size of the application (also, chances for bugs are smaller when an application is used less). Apart from a basic 'delivery cost' (platform & software), the price may be based on application size (i.e. license fee per customer, port or link). Maintenance may include new releases (very useful with emerging standards).
Most effort in standardisation (by the ITU-T, which is a co-operation of operators and manufacturers) has gone to the q3 between network and TMN. However, operators commonly buy element managers –and often network management systems– from the same manufacturer as the network equipment, and interface these systems to their (legacy) service management OSSes. The interface between EML & NEL is usually q3, but is actually irrelevant: the manufacturer will see to it that their element managers work properly with their network elements whether the interface is q3 or proprietary. The standardisation problem has shifted to the interface between EML/NML and SML, where there is hardly any standardisation (i.e. all legacy/proprietary interfaces).
In general operators are adapting their existing (legacy) service management systems to manage new (technology) networks and new services. Standardisation in this area is not done in association with the ITU, but in the TeleManagement Forum (TMF). As the TMF is not paying attention to any q3 interface, the q3 is effectively dead (maybe except the EML/NEL-interface).
Operators are co-operating for standardisation on service management in the TeleManagement Forum (TMF). In particular the 'Service Management, Automation and Re-engineering Team' (SMART) provides an attempt to unify the problem area. This has resulted in the FAB-areas:
While FAB provides a nice view on service management, it is a very complex architecture. On top of a layer providing general facilities and NML functionality, FAB consists of 15 modules with a great many interfaces between them. On average a module has 7(!) interfaces to other modules.
This makes it virtually impossible to replace a module by a new one, i.e. the concept of modularity is lost. While the ideas are nice, the architecture is completely impractical; it lacks abstraction.
Next section: Standards
Up to Contents
Up to Index
=O=