EP1205078A2

EP1205078A2 - An intelligent network management system

Info

Publication number: EP1205078A2
Application number: EP00951332A
Authority: EP
Inventors: Richard Mcconnell
Original assignee: Openwave Systems Inc
Current assignee: Great Elm Group Inc
Priority date: 1999-07-01
Filing date: 2000-06-29
Publication date: 2002-05-15
Also published as: WO2001003447A2; AU6431100A; WO2001003447A3

Abstract

An intelligent network management system (1) interfaces with a C7 signalling network (6) to provide an SS7 interface to CORBA-based intelligent network services. A service control point (SCP, 11) interprets incoming service requests and translates them into service invocations. An example of a service is a number portability service. The SCP (11) has a service load disperser (SLD, 40) for interaction with multiple service servers (41). A service data point (12) has a database load disperser (DLD, 55) interacting with multiple database access servers. A service management system (SMS, 10) interfaces with the DLD (55) and with an application manager (50) for management of service, customer, and network management.

Description

" An Intelligent Network Management System"

INTRODUCTION

Field of the Invention

The invention relates to an intelligent network management system.

Prior Art Discussion

Intelligent networks operate on the basis of removing "intelligence" from centralised systems and placing it in distributed computer nodes.

It is an object of the present invention to provide an intelligent network management system to allow telecommunication networks to benefit from intelligent networking so that the range of services available to them is increased.

Another object is that the management system allows access to information transparently of the location of the software or hardware platform.

SUMMARY OF THE INVENTION

According to the invention, there is provided an network management system comprising:

a service control point for interfacing with a telecommunications signalling network and for interfacing with CORBA-based intelligent network services,

a service data point for interfacing with the service control point; and a service management system for service and customer management.

In one embodiment, the service control point comprises means for mapping signalling network protocol invocations to CORE A invocations.

In another embodiment, the service control point comprises a service switching point simulator for receiving signalling network service requests and for sending responses to a signalling network.

In one embodiment, the service switching point simulator comprises means for providing access to a plurality of clients as signalling network users.

In one embodiment, the service control point comprises a service selection interaction manager comprising means for mapping invocations between a signalling network protocol and CORBA.

In another embodiment, the service selection and interaction manager comprises a stack manager comprising means for monitoring incoming service requests and for translating them into associated invocations, and a service manager comprising means for managing said invocations.

Preferably, the stack manager comprises means for managing a pool of signalling network objects allocated to service invocations.

In one embodiment, the service manager comprises means for managing a service handler object for interacting with an application manager of the service control point. In another embodiment, the service selection and interaction manager comprises means for maintaining a table of service references and for accessing a service configuration file mapping service operation codes with service descriptions.

Preferably, the service control point further comprises a service load disperser comprising means for performing load balancing of a pool of service servers on a per- in vocation basis.

In one embodiment, the service load disperser comprises means for creating a service manager object for handling requests for services.

In another embodiment, the service load disperser comprises means for registering the object reference of the service manager object with a CORBA names service.

In a further embodiment, the service data point comprises a database load disperser for interfacing between clients requiring database access and database access servers.

In one embodiment, the database load disperser comprises means for creating an instance of a dummy object, for associating a loader object with it, and for registering the dummy object with a CORBA names service.

In a further embodiment, the loader object comprises means for executing a load- balancing algorithm when invoked.

In one embodiment, the service management system comprises means for interfacing with an application manager of the service control point and for providing service management, customer management, and network management interfaces. In another embodiment, the service management system comprises a plurality of manager stations, each comprising for making invocations on the application manager according to user instructions.

In one embodiment, each manager station comprises means for passing object references to the application manager, and the application manager comprises means for reporting alarm conditions using said object references.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:-

Fig. 1 is a schematic representation of an intelligent network management system showing the manner in which it is connected to a telecommunication network;

Fig. 2 is a more detailed diagram showing the internal architecture of the management system;

Fig. 3 is a diagram showing the architecture of a service switching point simulator of the system;

Fig. 4 is a diagram showing the architecture of a service selection interaction manager; Fig. 5 is a diagram showing interaction for service selection/creation/invocation;

Fig. 6 is a diagram showing the interfaces of a data load disperser;

Fig. 7 is a diagram showing the management architecture of the system;

Fig. 8 is a diagram showing a global view of a portability service in the system; and

Fig. 9 is an information flow sequence diagram for a number portability service.

Description of the Embodiments

Referring initially to Fig. 1, an intelligent network management system 1 of the invention is illustrated. The system 1 is shown connected to a telecommunication network 2 comprising local exchanges 3, an intelligent peripheral (IP) 4, a trunk exchange 5, and a C 7 signalling network 6.

The system 1 comprises a management interface 7. A service creation environment (SCE) 8 is connected to an SCE interface 9. The SCE 8 and the management interface 7 are connected to a service management system (SMS) 10, in turn connected to a service switching point (SCP) 11. The SCP 11 is connected to a service data point (SDP) 12. Both the SCP 11 and the SDP 12 are connected to the telecommunication network 2. In Fig. 1, the interrupted lines represent signalling paths, the full lines in the system 1 represent management links, and the full lines in the network 2 represent speech paths. The system 1 provides an SS7 interface to CORBA-based intelligent network (IN) services, and also provides a service management interface, a customer management interface, and a network management interface. More particularly, the SCP 11 interprets incoming SS7 messages and translates them into service invocations and controls execution of services, in this embodiment a number portability service. The number portability service is one example of a service which is provisioned by the system 1, however, it is envisaged that many other types of services may be provisioned. The SDP 12 provides access to a database for translation purposes and the SMS 10 provides management functions.

Referring now to Fig. 2, a breakdown of the SMS 10, the SCP 11, and the SDP 12 is illustrated. The SCP 11 comprises a service switching point (SSP) 15 for interaction with the signalling network 6. The SCP 11 maps a telecommunication protocol, in this embodiment an INAP protocol, to CORBA. Thus, INAP invocations are transferred to CORBA invocations in a CORBA environment having an Orbix ™ names database 42.

The SSP 15 comprises a Service Switching Point Simulator (SSPS) 16 and an SS7 process 17. The SS7 process 17 exports an INAP API to the SSPS 16, to allow the SSPS send INAP service requests to the remainder of the SCP 11.

The SSPS 16 is shown in more detail in Fig. 3. An internal SS7 process 18 interfaces with the C7 signalling network 6, and INAP service requests are received by an SSPS receiver function 19 and logged to a Received File 20. An SSPS sender function 21 sends INAP responses to the C7 signalling network 6 and logs the responses to a Sent File 22. An SSPS analyser function 23 analyses the contents of the files 20 and 22 and maintains a status file 24. Thus, the internal SS7 process 18 performs two related functions as follows: providing the SSPS 16 with an API to an ETSI INAP CS-1 message set and therefore send/receive SS7 messages to/from another stack in the network 2, and

providing functional entities within the CORBA environment with an API to the ETSI INAP CS-1 message set and therefore the ability to receive and send SS7 messages into and out of the CORBA environment.

The SSPS 16 provides sessions to a large number of clients by multiplexing connections and any number of clients can connect and initiate a session to the SS7 process and become an INAP user. In doing this, they receive a unique socket reference which can be used to receive and send INAP messages.

The SCP 11 also comprises a service selection/ interaction manager (SSIM) 30. This performs a very important function in mapping invocations between INAP and CORBA. A detailed breakdown is shown in Fig. 4. A stack manager 35 monitors incoming SSI service requests and translates them into associated invocations on a service manager 36. It also manages a pool of INAP Objects, which are allocated to service invocations. Each INAP Object allows the following:

sending any ETSI Core INAP message,

receiving any ETSI Core INAP message, and

termination of any service using the INAP interface

In addition to providing this interface each INAP Object automatically reports any SS7 errors to an Application Manager 50, also shown in Fig. 2. In the service manager 36, a Service Handler Object implements the interface, and the main operations available in this interface are:

receiving a service request from the Stack Manager 35, error reporting from a Database Load Disperser 55 (also shown in Fig. 2), provisioning/suspension/deletion of services from the Application Manager 50.

In addition to providing the above interface the Service Handler Object reports any error conditions to the Application Manager 50, such as receiving requests for services that are not provisioned.

Referring now to Fig. 5, the immediate actions following the service start-up and the transactions required for an ensuing service invocation are illustrated.

1. A Service Load Disperser (SLD) 40 is linked between incoming service requests and a pool of Service Servers 41 to facilitate load balancing on a per-invocation basis. The first action of the SLD 40 is to create a SERVMANAGER object. This object handles requests for services and maintains a list of real server references relating to the backend objects contained in the Service Servers 41.

2. The SLD 40 registers the object reference of the SERVMANAGER object with the names database 42.

3. The SSIM 30 receives an INAP message, which is interpreted as a request for a service.

4. If the operation code received in the INAP message does not map to any of the service references contained in the SSIM's in-memory references contained in the SSIM's in-memory table, the SSIM 30 will search a Service Configuration File 43. The Service Configuration File 43 cross-references the INAP operation code of all services against a textual description of the service (the information contained in this file is configured from the SMS interface).

5. The SSIM uses the textual description retrieved from the Service Configuration File 43 to interrogate the names database 42 and retrieve the object reference to the appropriate SERVMANAGER object. This leads to dependencies between the information stored in the Service Configuration File 43 and that in the names database 42.

6. The SSIM 30 uses the retrieved object reference to build a one-way invocation to the SERVMANAGER object requesting invocation of the service to handle the INAP request.

All service instance interfaces are common and this is enforced by inheritance from an abstract service class. Any object reference returned from the names database 42 can then be narrowed to this abstract service type and the common method for service execution invoked. An INAP object enabling SS7 communication for the service will be passed as part of any invocation.

7. The invocation is made to SERVMANAGER. This function will use a load balancing technique in order to choose an object reference associated with one of the backend objects and invoke the associated IDL method in the Service Server 41.

8. The Service Server 41 will begin service execution.

The forms of external management performed by the SSIM 30 are as follows: • SSP Regulation - If the SSPS 16 is making service requests that are causing the system 1 platform to overload or excessively queue service requests then it will make use of an INAP object to send a "Call Gap" message to the SSPS. This request will cause the SSPS to terminate service request for a defined period. This type of scenario would also require an application specific event to be raised to the application manager 50 after which the event would then be translated into a SMS 10 user interface alarm.

• SSPS Health Check. This is performed after a pre-defined period, which did not contain any transactions with the SSPS. This action is implemented by using an

INAP object to send an Activity Test INAP message to the SSPS and checking for a response. Non-responsive SSPS's will be reported to the application manager 50, resulting in an alarm being sent to the SMS 10 interface 7.

• SDP 12 Management - Performed if services are encountering difficulty in accessing the SDP 12 database 57. The SSIM 30 can be informed of such a situation from the data manager in the form of an IDL request. It is envisaged that services could be invoked and informed to use a mirror database.

The SLD 40 server is placed between the SSIM 30 and the Service Servers 41 to provide a service specific interface for the selection and execution of services. The SERVMANAGER object provides an interface to the following functional entities:

Service Servers 41:

reporting of alarm conditions, registration, and termination

Application Manager 50: increase/decrease of Service Servers 41.

Each Service Server (SS) 41 contains a single object allowing any CORBA client the ability for service execution. Each client builds an IDL or DII request in a format identical across all services. Each SS 41 can also use the IDL interface in the SERVMANAGER for the reporting of errors during service execution and IDL to the INAP Object for the sending and the receiving of SS7 messages.

As shown in Fig. 6 the database load disperser (DLD) 55 is placed between the clients who require database access and the Database Access Servers 56 performing database operations. In the DLD 55, a DBLOADER mstance is a specialised loader, which contains a list of object references associated with the real Database Access Servers 56. The actual implementation requires the Database Load Disperser 55 to create an instance of a dummy object and associate a DBLOADER instance with it. This dummy object is then registered with the names database 42 following which it is deleted, in the DLD 55. Clients wishing to access the database can then use the names database 42 to retrieve the object reference of the dummy object. When the client invokes using this reference an object fault will be raised and the load method in DBLOADER invoked. This load method will execute a load-balancing algorithm on the list of object references and returns the selected reference. A Runtime function will then automatically invoke the operation on this reference.

The DLD 55 also provides an interface to the following functional entities:

Database Access Servers 56:

reporting of alarm conditions, registration, and termination Application Manager 50:

increase/decrease of Database Access Servers 56.

The DLD 55 automatically reports alarms via IDL to the SSIM 30 so that services can be informed to use a backup database, (if one exists). Alarms will also be reported to the Application Manager 50 to facilitate operator intervention.

Each Database Access Server 56 contains a single object allowing any CORBA client to access database information. Each client builds an IDL or DII request in a format identical to that specified for SCP to SDP and SDP to SCP INAP transactions. Each DAS 56 can also use the IDL interface in the DBLOADER object for reporting errors when attempting database access.

Referring to Fig. 7, the SMS 10 comprises an Application Specific Manager (ASM) 60 and an Orbix™ Manager 61. The ASM 60 comprises a number of separate components which include the following.

A Management Library 63. This is linked into applications which are designated to be part of the managed system.

A Component Management Interface 62. This process is the main concentration point for the management of CORBA applications.

The system 1 allows for three distinct areas of management, as follows.

Service Management. Provided by using the management interfaces exported by the component management interface. Customer Management - Provided by a Service Manager component of the SMS 10 using a JDBC interface to the database to provide the following operations:

Add a customer

Remove a customer

Update a customer

Retrieve Billing Information

Network Management. Achieved by using the defined IDL interfaces to the Orbix™ Manager 61. Three distinct areas of network management are addressed:

Performance

Activity measurement, for example, the number of invocations, exceptions, connections, throughput and queue lengths. Performed on a per-process or per- interface basis.

Probes and Request tickets - allows information gathering on status and timings of particular invocations

Fault

Exception Notification and dimmer function - allows reporting on exceptions. The dimmer function provides the ability to associate conditions with exceptions and therefore only report on critical exceptions. Thresholds - allows threshold values to be associated with runtime attributes. Exceeding a threshold with a predefined time period will result in a notification being sent.

Diagnostics Monitoring - allows the viewing of diagnostic output.

State of Health - provides reporting on unexpected server deaths.

Configuration

Quiescϊng - ability to suspend, shutdown, or restart a server.

Configuration Files - allows configuration information to be obtained from the predefined Orbix configuration files.

Dynamic Management - ability to turn management functionality on and off.

Each manager station 70 (shown in Fig. 2) provides a JAVA-based GUI to allow operators to perform service, customer, and network management. Each manager station 70 has an IDL based interface to the Application Manager 50, allowing the retrieval of management based information and the sending of management based commands. This client will also need to present an interface to the Application Manager 50 to allow the reporting of alarm conditions. The primary purpose of this component is to allow management of both the CORBA environment and the all application-specific elements.

When the Manager Station 70 is started it creates an instance of its alarm interface and passes it to the Application Manager 50, along with the operator's details. The

Application Manager 50 will then verify the user's details and respond to the Manager Station 70 client indicating that the access is permitted or refused. If access is granted then the relevant Manger Station 70 instance will make IDL invocations on the Application Manager 50 as dictated by the user's actions. The Application Manager 50 may also report alarm conditions to all active Manager Stations 70 suing the object references passed in during initiation. When the user terminates their interface session then the Service Manager 70 will again inform the Application Manager 50 and reference to the associated object reference will be removed.

In this embodiment, a simple number portability service is provided by the system 1 and a global view of this is illustrated in Fig. 8. An information flow sequence diagram is given in Fig. 9. The service requires that there is availability of an initial information package or the dialling string from the originating party.

The TRANSLATE object then performs translation of the originating routing information to a new routing case. The POR specifies that call routing should continue acting on the new routing case. This may appear to be a simplistic service, but number translation is at the heart of the most common IN service such as freephone, credit car, premium charge, UPT and VPN.

The following information inter-changes are shown in Fig. 9.

1. At a DP2 stage within the SCF/SSF it is detected that this call requires special routing. Therefore an Initial DP operation is sent to the SCP 11 indicating a service request. The Initial DP message contains the dialled digits and the requested service.

2. The SCF uses the Query function to lookup the actual routing case to be used for the dialled digits. This information is sent back in the Query_Res message. 3. The SCF sends a Connect message to the SSF with the destination routing address to be used.

4. The BCSM moves into the Routing PIC and acts on the routing address provided by the SCF.

5. The Originating half of the BCSM received an indication from the terminating half that the called party has answered. The 0_Active PIC can then be entered.

It will be appreciated that the invention provides for seamless distribution of IN services, for the network 2. For example, an IN service may be moved to an adjunct processor without any code changes. Because the object-oriented methodology is used, there are well-defined interfaces. Also, it will be appreciated that the system can transparently interwork across networks, operating systems, and programming languages. Also, the system 1 can avail of CORBA services such as increased speed and flexibility of development and also availability of horizontal facilities such as user interface, time operations, and data interchange.

The invention is not limited to the embodiments described but may be varied in construction and detail within the scope of the claims.

Claims

1. An intelligent network management system comprising:

a service control point (11) for interfacing with a telecommunications signalling network (6) and for interfacing with CORBA-based intelligent network services (41),

a service data point (12) for interfacing with the service control point; and

a service management system (10) for service and customer management.

2. A system as claimed in claims 1 or 2, wherein the service control point (11) comprises means for mapping signalling network protocol invocations to CORBA invocations .

3. A system as claimed in claim 3, wherein the service control point (11) comprises a service switching point simulator (16) for receiving signalling network service requests and for sending responses to a signalling network (6).

4. A system as claimed in claim 3, wherein the service switching point simulator (16) comprises means for providing access to a plurality of clients as signalling network users.

5. A system as claimed in any preceding claim, wherein the service control point (11) comprises a service selection interaction manager (30) comprising means for mapping invocations between a signalling network protocol and CORBA.

6. A system as claimed in claim 5, wherein the service selection and interaction manager (30) comprises a stack manager (35) comprising means for monitoring incoming service requests and for translating them into associated invocations, and a service manager (36) comprising means for managing said invocations.

7. A system as claimed in claim 6, wherein the stack manager (35) comprises means for managing a pool of signalling network objects allocated to service invocations.

8. A system as claimed in claim 7, wherein the service manager (36) comprises means for managing a service handler object for interacting with an application manager (30) of the service control point.

9. A system as claimed in claim 8, wherein the service selection and interaction manager (30) comprises means for maintaining a table of service references and for accessing a service configuration file (43) mapping service operation codes with service descriptions.

10. A system as claimed in any preceding claim, wherein the service control point (11) further comprises a service load disperser (40) comprising means for performing load balancing of a pool of service servers (41) on a per-invocation basis.

11. A system as claimed in claim 10, wherein the service load disperser (40) comprises means for creating a service manager object for handling requests for services.

12. A system as claimed in claim 11, wherein the service load disperser (40) comprises means for registering the object reference of the service manager object with a CORBA names service (42).

13. A system as claimed in any preceding claim, wherein the service data point (12) comprises a database load disperser (55) for interfacing between clients requiring database access and database access servers (56).

14. A system as claimed in claim 13, wherein the database load disperser comprises means for creating an instance of a dummy object, for associating a loader object with it, and for registering the dummy object with a CORBA names service.

15. A system as claimed in claim 14, wherein the loader object comprises means for executing a load-balancing algorithm when invoked.

16. A system as claimed in any preceding claim, wherein the service management system (10) comprises means for interfacing with an application manager (50) of the service control point (11) and for providing service management, customer management, and network management interfaces.

17. A system as claimed in claim 16, wherein the service management system (10) comprises a plurality of manager stations (70), each comprising for making invocations on the application manager (50) according to user instructions.

18. A system as claimed in claim 17, wherein each manager station (70) comprises means for passing object references to the application manager (50), and the application manager comprises means for reporting alarm conditions using said object references.

19. A computer program product comprising software code portions for completing a management system of any preceding claim when loaded in loaded in a digital computer.