Last update PvD
Integration
Overview
Integration and interworking are probably the most important issues in network management. Integration is also the most misused word; the meaning and interpretation varies with the person and his intentions. Both integration and interworking strive for the same objective: simplification of use by combining funtions. But they do so in a distinct manner.
Interworking is the interaction between two –or more– entities which remain clearly visible separate entities. And integration is co-operation between two –or more– entities such that the combination operates as a virtually single entity.
Interworking is commonly found between entities which are supposed to remain separate, for example between operators (who have no intention of merging) to solve particular telecommunication demands (e.g. interconnection; see section on Interworking).
And integration is commonly found between Operations Support Functions (OSFs) to easy operations (this document).
In the TMN context here, Integration is packaging two or more components (OSFs in this context) into a single component. Former interfaces have become internal interfaces, most likely hidden from the outside world (and are therefore proprietary).
Interworking on the other hand, keeps the two components separated but requires a well defined interface to allow useful co-operation. In TMN terms, the interface should have an Information Model (i.e. a Q3xyz).
For some TMN purposes, interworking is more desirable as the interface is a standard (and because many OSFs will be quite complex).
First, a broad distinction is made between horizontal integration versus vertical integration in the TMN Logical Layered Architecture. Horizontal integration is integration between two OSSes/OSFs in the same layer or between two 'TMN stacks' at the same level; this can potentially occur at any of the 5 layers of TMN. Vertical integration is between two hierarchical OSSes/OSFs in the same layer or between any two adjacent layers.
Integration is also a automation issue. In the most simplest form, it is screen integration: two or more applications in separate windows on the same screen (e.g. X-windows). It facilitates simple manual interworking like copy/paste between 2 windows (it is an improvement over re-entering computer print-out).
Platform integration is probably the next step. For the user/operator it may not bring immediate advantages, but it creates a uniform operational environment (e.g. standardisation on General system Management procedures like start-up and back-up) and benefits developers (a lot of proven and known modules available). And it paves the way for true integration.
There is also a practical limit to integration; an OSS may become so complicated that it becomes hard to adapt and maintain it. And it is counter productive for modularity: the capability to replace a module by another. In general, one would prefer interworking over integration when crossing an LLA-boundary (e.g. between NML & SML).
Often integration is considered when the official standard is perceived as too limited for one's purpose. An acceptable solution then, is to provide 2 interfaces: the official one, and a proprietary interface with all desired capabilities. Or the proprietary interface with Mediation to the official interface.
Thought a solution through mediation may not win a beauty contest, it is a practical solution for many cases. It allows interworking and facilitates a migration path to a more integrated operations.
It keeps the items conforming to the standard separate from the non-standard items while adding non-standard capabilities.
The ultimate solution is of course a full-fledged Q3-interface with all required capabilities.
When two TMN stacks have been integrated at a particular level in the LLA, in principle there would be no need anymore for integration at higher levels (there are some rare exceptions). But there must be a strong relationship between the two TMN stacks to require and justify integration. Horizontal integration is mostly a unification of two similar concepts.
We start our analysis at the bottom, and work our way up to the top.
Strictly this is not integration in the TMN, but in the network layer. Still, integration may occur here, with significant advantages in operation (less resources, cheaper management). A typical example is the integration of data networks, e.g. integrating an X.25 network with a Frame Relay network, i.e. multi-service equipment, or the unification of equipment. If the most important resources –switching nodes and trunks– are shared, network management should be integrated as well (errors are in common, capacity is shared). Interworking between network equipment is usually not a problem (covered by extensive standards). But it requires that the management stack also integrates the multiple services.
When dissimilar services –e.g. switching & transport– are integrated, it is probably vertical integration.
A normal case of integration in EML is the multi-element manager. Usually it concerns identical –or at least similar– equipment (from the same supplier), and strictly speaking it is hardly integration as the elements are treated as separate and independent entities; it is more platform integration.
However, apart from cost-effectiveness by using a single system to manage multiple elements, there could be a capability for performing particular transactions on all elements through a single command. Also, some information (e.g. default values, software releases) can be shared.
Integration in EML becomes more of value when the network elements are not identical but only similar, i.e. in the case of multi-vendor or multi-technology. However, both multi-vendor and multi-technology integration requires significant standardisation, which is currently not planned.
As NML should manage the whole network and hide all technology from SML, it must integrate multi-vendor and multi-technology (if a network doesn't have multiple vendors and multiple technologies, it will be very small).
A typical example: a Leased Lines network with SDH backbone and PDH access; without integration provisioning of a Leased Line requires the creation of a PDH access trail from customer A premises to the backbone (in an PDH OSS), an SDH trail through the backbone (in the SDH OSS), and the PDH trail from the backbone to customer B premises (in the PDH OSS again). Here also, standardisation is a prerequisite.
To achieve a single point of customer facing and a single bill per customer for all services for proper customer care, all services should be virtually integrated in SML. SML may consist of multiple OSSes (it most likely will), for the customer (and therefore preferably also for the service operator) it should present itself as a single system.
It does involve quite distinct services (e.g. Leased Lines and Mobile Telephone, potentially in a single contract) and many additional support functions (e.g. billing, invoicing), and is therefore a considerable challenge. But the rewards are great.
As we are usually considering a single operator, i.e. a single business, there shoud be no integration issue at BML.
However, this may not be the case when two operators merge, or when in a large corporation divisions operate more or less independently (i.e. have their own profit & loss responsibility); this is not elaborated here any further.
This is the integration of two or more adjacent layers in the Logical Layered Architecture. It is commonly done through the various Management Functional Areas (i.e. FCAPS), which are defined independent of any layering anyway.
A special case is when two service layers of a network (not the TMN) are integrated in a single node. E.g. an ATM switch usually has a lot of SDH-interfaces (terminations); if the switch has the capability to cross-connect SDH paths it integrates an SDH cross-connect and an ATM switch.
But even if the ATM node would not be capable of cross-connecting SDH terminations, it integrates the SDH terminations (which would otherwise be in separate equipment), it effectively integrates the (SDH) transport layer and the (ATM) switching layer in a single equipment unit.
This is actually service (layer) integration in network equipment. It is preferably, but not necessarily, leading to management integration; one may still have two TMN stacks (in the example an SDH/transport management system, and an ATM/switch management system).
Even when the network equipment would be separate equipment (i.e. non-integrated), the two TMN stacks have many relationships in nodes and connections (the SDH terminates in the ATM exchange, and ATM uses SDH connections to get to other ATM exchanges). And an SDH failure will lead to loss-of-signal in ATM (but that would be vertical integration at NML).
Note also that such integration can be stacked further. E.g. a data service like Frame Relay can be integrated in the ATM exchange (and ultimately will be).
Its is not uncommon to have some (element) management built into a network element. Typical examples are telephone switches, and some data switches in LANs.
The advantage is that such a system is pretty much autonomous; it can effectively respond to adverse conditions on its own. Any response is of course not necessarily the best for the whole network but only for an individual local node. Still, it provides the foundation for a robust network, and is therefore a very good concept.
A common problem for existing network elements with built-in management (like currently telephone switches), is that they not (yet) conform to standards. And modifying large existing operational systems to conform to standards is not undertaken lightly.
Integration between EML & NML is possible, but seems less likely. The combination of network management and (multi-)element managers may provide some advantages but they seem not to be really significant, and are hence not first priority.
As services in networks commonly depend on each other, there is certainly interaction at the service level. Most services use the PDH or SDH transport service, so any transport service failure will pop-up in 'higher-level services' as a network connection failure. For example, an SDH failure will lead to loss-of-signal in several other services, like telephony and data.
Obviously, the transport management system can inform the switching management systems quite precisely about the fault, at least to inform the switching management that it is not a problem in their network but in the underlying services.
Note that formally it is a transport service failure which leads to switching network failures, with potential consequences for switching services (if the switching service does not have a rerouting backup). The interaction can be implemented between the transport NML and the switching NML(s), or between the transport SML and the switching NML.
Though interworking between NML & SML will be extensive, it is not desirable that OSFs from these distinct layers are integrated: the interface between NML & SML is an important interface used in many instances (e.g. the above mentioned service integration, for Customer Network Management and VPNs). The multitude of combinations between network management and service management for all kinds of services is enormous; it is more important to define a proper interface to allow good interworking.
In any organisation, information regarding profit its 'products' must be reported. For telecom companies specifically:
Such SML data must be abstracted and presented to BML. But actual integration seems less desirable.
Some examples of Integration:
Obviously, standardisation (mainly of the q3-interface) is paramount.
Next section: Issues
Up to Contents
Up to Index
=O=