Intelligent Network (IN) and Telecommunications Management Networks (TMN) are already two standardisation efforts which are widely endorsed. However, IN and TMN cannot be treated separately. Today’s products and their underlying architectures are not considered sufficient for the new world that operators and their suppliers are facing. There is a generally recognised need to take advantage of recent advances in distributed computing and object-oriented analysis and design, together with today’s established solutions to help solve the challenges identified.

The intention is to make use of recent advances in distributed computing and objected-oriented analysis and design, in order to achieve a drastically improved interoperability, a better reuse of software and specifications, and a flexible placement of software on computing platforms. IN and TMN are integrated to formed Telecommunications Information Networking Architecture (TINA).

In the architecture of certain European implementations of IN, a service management system (SMS) is used to support technical management. One of the SMS’ major functions is to supervise the network’s service control points (SCPs) at network level, whereas one or several service provision points (SPPs) can be connected to the SMS to perform specialised commercial management functions. Because of this type of IN architecture, let us compare the different between IN management and the TMN concept.

From the architectural viewpoint, it is a straightforward exercise to compare the roles of the SMS, SPP, and operations system (OS), respectively.

SMS, home for the service reference database, performs service technical data management ( such as downloading of service programs to the SCPs ) and network ( nodes ) technical management ( supervision of remote operation and maintenance of the SCP’s subnetwork ). As such, it performs OS functions and can be seen as a network OS and a network element OS. The updating of the reference database and the concentration and analysis of call statistics also are SMS functions that fully match OS functions, dealing with service management. For this reason, the SMS also can be considered as a service OS.

The SPP is a dedicated node devoted to the service provider or authorised service subscriber access, dealing with commercial management of IN services and customers. As such, it also performs OS functions, and can be seen as a commercial/business OS. Additionally, SPP can be seen as a service OS as it also is involved in management of technical data subscription, such as service configuration management and management of resources needed for the service.

Such implementation does not preclude other physical architectures where, for instance, SMS and SPP roles are hosted by a unique node. From a functional perspective, both architectural approaches are comparable because they both separate network provider activities from service provider activities. The other IN components actually are the equivalent of network elements (NE).

Therefore, the direct interface between SMS and SCP to exchange management information would be a Q3 interface. The interface between SPP and SMS would be either a Q3 or X interface. It would be a Q3 interface whenever the service provider’s role and the network operator’s role are handled by the same actor; an X interface whenever the service provider is in a competitive domain. In such a domain the service provider’s role is clearly isolated from the role of the technical network operator. Management of IN services may be compared to the TMN service management, residing in an OS. Special features for this management are dynamic service management, on-line modification, rapid introduction of a new service, and service deployment. They can be taken directly into account by the TMN. Accordingly, one could foresee introducing the service creation part of IN management into the TMN concept ( although no such plan is under study inside TMN today).

This TMN service management would need to cover all service-related aspects such as operational management of an already installed service, service creation, service introduction in the network and deployment.

All networks, regardless of their nature, have very similar network management needs. IN management needs would bring only specific requirements such as new service introduction and generalisation.

An IN operator must manage service subscribers then allocate the required resources within the network to supply each subscriber with the appropriate service. This activity, however, does not differ significantly from conventional subscription management. Moreover, such management must be the same for all services, whether they be IN oriented or general, when offered to subscribers. Such consistency becomes vital when considering such things as the migration of an IN service to the general network.

Another point is that IN operator must manage a complete network of nodes, links, and resources. Network supervisory functions such as alarm and performance monitoring are necessary. Finally, the IN introduces the possibility for subscribers to directly manage certain aspects of their own service parameters such as traffic and charging data. This new type of commercial network management inside the general network requires stringent access security, data visibility, and operator authentication practice, all of which strongly resembles conventional network OAM.

So far, the study of telecommunications management has concentrated on the TMN framework and related definition methodology. IN specification, which is more call control oriented, may find useful information, methods, and guidelines in such TMN specification. This would prevent redesigning IN management in another way. Similarly, object-oriented techniques developed during TMN definition are extremely rich. Using the inheritance mechanism, OOT methodology enables progressive adaptation of managed objects into finely defined objects inheriting the properties of parent objects. At a certain level, precise IN objects could inherit from non-IN-specific parent objects. This would avoid different definitions for the same entities that have to be manipulated in the same framework for the same OAM functions.

To ensure consistent management definition, it is desirable to re-use the existing TMN specifications. IN provides clear distinctions between the network, its services, service users, and providers. By highlighting the needs for each of these aspects, the data management requirements become more precise at each management level, thus clarifying the relevant functions to be performed.

IN is based on a largely distributed service processing system where components are subject to individual and nonsynchronised evolution. The object-oriented design techniques widely used in TMN allow for the isolation and explicit description of all object interactions.

IN is a generic, service-oriented architecture, intended to be used for all kinds of services (real-time or management) on top of call-control type services. TMN is a generic, management-oriented architecture, intended to be used for all kinds of management services. Obviously, the IN and TMN architectures overlap. For instance, one TMN application such as billing and one IN application such as Freephone must be tightly related because Freephone billing should be handled in a consistent way with TMN billing. This shows that, unless both IN and TMN architectures are made more consistent.

Unfortunately, very little work has been achieved on IN/TMN integration in CCITT. Therefore, what follows is based on results from the joint IN/TMN expert group of ETSI NA4-NA6. These results have been considered as the starting point of CCITT’s work on the integration of IN and TMN.

Integrating IN and TMN is necessary. But how? One should consider IN as one part of the network. As the whole network is to be managed by TMN, it is then clear that IN must be managed by TMN. Also, management aspects of IN mainly deals with service management, As non IN- structured services are to be handled by TMN. Therefore the proposed principle to achieve IN/TMN integration is to use the TMN approach for management aspects of IN. IN management aspects must then be considered as TMN management services and TMN techniques must then be applied, for each plane of the INCM.

CCITT has only shown a framework of how IN and TMN can be integrated. Of course, much work in both is needed to define in great detail such an integration in order to provide the ability of swift service introduction, vendor independence and flexible management. Major areas of work that can be positioned in the four planes of the management-IN conceptual model are :

• M-INCM service plane: the identification and specification of Management Services and management services features ( SFs). They can be derived from already identified IN management requirements, based on the IN management process, the IN based telecommunication devices ( like VPN ) and possibly the OSI system management functional areas.
• M-INCM global functional plane : the identification and specification of Management Service Independent Building Blocks (MSIBs). They can be derived from the above mentioned management services, management SFs and any generic TMN management service. Also, it is necessary to define the building blocks forms ( e.g. objects ) and the rules for using these building blocks ( for in stance for allowing for expressing parallelism).
• M-INCM distributed function and informational Plane: the identification and specification of managed objects and, systems functions along with the specification of the shared management knowledge for each OSFs. The managed objects can be derived from, and mapped on the above mentioned MSIBs, thus defining the "information flows" between OSFs.
• M-INCM physical plane: the identification and specification of IN- management protocols based on the identified managed object operations and common management ASEs like CMISE in the context of Q3 TMN interfaces.

 When defining the IN management information model, it is necessary to define it consistently with other TMN management service information models. For instance, billing or customer administration or traffic management are also performed in some way in the IN management. Mechanisms used in the IN management should be the same as in other TMN management services. This is of special importance for both the IN experts as the TMN experts in order to ensure that IN management can be interconnected to other TMN management services.

Under the pressure of delivering and more effectively managing a growing number of services and assisted by a continuous evolution of the network and software technology, both IN and TMN are bound to evolve towards an integrated architecture by using the same technological solutions, such as the adoption of TINA.

In TMN, network evolutions such as broadband and synchronous digital hierarchy ( SDH) will imply modifications or even the disappearance of some functions ( for instance as a result of introduction of "self healing" capabilities). Therefore, there is a need in TMN to go towards a software architecture allowing real flexibility in application interoperability. The modification of one application would then be easily coped with by the applications that are interconnected to it.

 In IN, it will also be necessary to take into account new network capabilities (e.g. broadband, multimedia). To this end. It will be necessary for the SCF to control new types of resources. The SCF will be modified, as well as associated service logics. Similarly, the SSF will be modified. Therefore, there is also the need in IN to go towards a software architecture allowing real flexibility in application interoperability.

Both in IN and TMN, the challenge is to ensure a global consistency of all interconnected applications, while allowing for evolution of some applications. This shows that while IN and TMN architectures are to be integrated, they both must evolve towards a unified target architecture in order to be more flexible.

The TINA Architecture is divided into three subsets:

• Computing Architecture
• Service Architecture
• Management Architecture

A TINA service, as any telecommunications or computer service, comprises several interoperable service components, described, specified, and implemented according to the TINA Computing Architecture principles and concepts.

Each service component is composed of one or a number of software units, called computational objects. The communication between ( and the execution of ) the service components and their computational objects, are supported in TINA by a distributed processing environment of DPE. Examples of the generic DPE services are traders and name servers that help identify and locate relevant software units, notification servers that help forward messages to the relevant software units, security servers that ensure only authorised interaction between service components to take place, transactional servers, etc.

In order to achieve good structure, modularity, and software reusability, the regular ( non-DPE ) service components are divided into three component categories – actual Service components, described in the TINA Service Architecture, Resource Management components and Resource components. Components from the service category form the actual services or parts thereof, e.g. Generic session End-Points, User Agents, Service Session Managers, or Communication Session Managers, as described below. They all rely on common Resource Management components, e.g., Connection Performers, fault managers, and Configuration Repositories. Resource components model the actual transmission and switching resources.

Here has shown the importance of integrating IN and TMN. It has given a framework of how IN and TMN should be integrated and has identified a number of study items that remain to be studied. Finally, it has shown the overall evolution towards the usage of a more general and unified architecture, TINS, in order to allow for more flexibility in application interoperability.