EP0850545A1 - Operational environment system for communication network service applications - Google Patents

Abstract

The purpose of the invention is to provide network operators or third parties (such as software companies) with an opportunity to implement their service ideas directly and without passing through a network provider while, at the same time, ensuring that faulty service applications thus implemented do not adversely affect the entire network. This purpose is achieved by a fault-tolerant operational environment system (FAU) as disclosed in this invention.

Description

description

Drainage system for service applications of a communication network

In today's N-ISDN and B-ISDN telecommunication networks, service applications are provided as part of the so-called intelligent network (IN for short).

1 shows the architecture of the intelligent network. The intelligent network is intended to enable a network operator to introduce new services quickly and easily, without having to intervene in the system program systems in each network node. The interventions mentioned are therefore restricted in an IN to as few central network nodes as possible, so-called service control points SCP, which are equipped at a central point with the appropriate application software for the new services, the so-called service applications, and then in a kind of "remote control" enable the individual network nodes to carry out the new services.

The aforementioned remote-controlled network nodes of the IN are also referred to as service access nodes or service switching points SSP. They are connected to a service control point SCP directly or via a signaling network such as the CCS7 signaling network.

A service management point SMP is used to administer the IN services by the network operator, the service provider and the service subscriber.

A call to a service of the intelligent network can first be routed from a normal, ie from a network node not remotely controlled by the SCP, to a service switching point SSP. The service switching determines based on the dialed number and / or the service code Point, which service control point SCP contains the service application corresponding to this service and then sends a request to this service control point as to how it should handle the call. After the SCP has examined the request, it sends a response to the service switching point, which contains information that it needs for further handling of the call.

The Service Control Point SCP requires an error-free (hardware / software) computer platform, since the service applications must have the same high availability as the other components in the basic network (SSP and other switching centers). For this reason, today the service applications are developed by software specialists from network suppliers and systematically tested with great effort. The network operator can only modify these service applications at the designated points (customizing). Examples of such service applications are:

- green number (freephone)

- Virtual private network

- Etc.

Programming of service applications (in the SCP and partly in the SMP) directly by the network operator or third parties (e.g. software houses) would be desirable. As a result, the network operators could implement their service ideas directly and without going through the network supplier (Open Network Provisioning: ONP).

However, this possibility entails the risk of introducing faulty service applications.

Although today with known techniques of fault tolerant

Hardware is working (N + 1, 1: 1 redundancy, microsynchronous systems), can not be prevented that the last called programming in the software, serious logical errors lead to the crash or dynamic misconduct of the service applications. This then usually has an effect on other service applications or on the basic network.

Examples of such logical errors are:

- An event expected by a service application never occurs. The process is blocked (deadlock).

- A service application goes into an inactive loop (endless loop), in which no more meaningful function runs.

A service application periodically exchanges messages with the basic network or with other SCP functions, but without carrying out a useful network function (active loop). There is also a risk of system overload for other, uninvolved service applications.

Without countermeasures against this type of logical error, opening the SCP / SMP for service programming by network operators or third parties is not possible.

The invention is based on the object of giving network operators or third parties (for example software houses) the opportunity to implement their service ideas directly and without going through the network supplier, and at the same time to ensure that faulty service implementations implemented in this way Applications have no negative effects.

This object is achieved by a runtime environment system according to claim 1.

An exemplary embodiment of the invention is explained in more detail below with reference to the drawing. The drawing comprises five Figures, with FIGS 2 to 5 serving to illustrate the exemplary embodiment.

The fault-tolerant execution environment in the SCP should recognize the following serious logical software error classes in the service applications as quickly as possible and immediately end the handling of the calls or other network functions by the faulty service application as required:

l) deadlock while waiting for internal SCP resources / events as well as events from the basic network,

2) Endiess Loop,

3) Active Loop

For other software error classes such as Address error,

Memory protection violation, etc., the detection and treatment is known and is not dealt with further here.

2 shows an SCP architecture which comprises an execution environment system FAU according to the invention. A corresponding architecture can be used for the SMP.

The process environment system FAU provides the service applications SAP with a fail-safe application programming interface API. The API provides a network operator and / or a third party with a system of function modules for programming an individual SAP. The FAU and the API are detailed by the system supplier, i.e. stable, tested and thus perform the functions represented by the API (viewed individually) error-free.

3 shows the method in the runtime environment system for recognizing the logical software error classes mentioned, namely deadlock, endiess loop and active loop in the service applications. The process includes the following features or process steps: 1) If an activated (ie in operation) service application reaches a state in which it is waiting for one or more network input events, these expected events (for example network messages to be received according to a known IN application protocol such as INAP or AIN) together with their identifier in a so-called event list IER of the FAU. If the service application mentioned leaves this waiting state, the events corresponding to this state are removed from the event list IER by the FAU.

2) Each time the context changes between two SAP internal functions, the FAU stores a time stamp (context change time stamp Cn) for this event. Context changes include, for example:

- method call of an object with object-oriented software architecture,

- procedure call including remote procedure call (RPC), - sending / processing of an internal, external message,

- Etc.

The context change events are normally recognized by the underlying operating system and dealt with in the runtime environment system in relation to the relevant service applications. The context change timestamp enables the FAU to assess the activity of a SAP.

3) A time stamp of the last network input event received by the base network or of the network output event output to the base network, the meaning of which will become clear later, is also stored by the runtime environment system.

4) One event counter NEZ is kept in the workflow environment system for each network output event. All possible network output events and their maximum number are given for a given Basic network protocol (e.g. according to the international standards INAP, AIN) well defined.

5) The process environment system periodically triggers an Application Activity Test AAT. The adjustable time period is recorded in the runtime environment system as a time stamp tn.

4 shows the process running in the runtime environment system for recognizing the logical errors mentioned in the service applications.

5 shows the relationship between the most important events.

The process shown in FIG. 4 proceeds as follows:

1) The triggering event of the method is the periodic Application Activity Test AAT.

2) At the time of the period tn of the application activity

The list IER of network input events for a specific call is first examined in tests. If it is not empty, it is checked whether all entered network input events are logically correct. This test is derived from knowledge of the standardized basic network protocol (e.g. INAP, AIN).

In the event of errors, the handling of the specified call is ended by the associated service application (deadlock: waiting for an event that never occurs).

If the network input events entered in the list IER are logically correct on the other hand, a check is also carried out to determine whether the base network can send these network input events at all (if the call was ended prematurely by the base network, this transmission is not possible, for example). For this purpose, a network activity test NAT is carried out using a known method, using one for this standardized test transaction is carried out (eg as part of the INAP, AIN protocol). If it is determined that the call is still active in the basic network, the call processing in the service application is continued.

3) If the event list IER is empty, the time stamp comparison Cn, Cn-1 is used to check whether this service application has not changed context since the last AAT period, i.e. whether Cn = Cn-1 applies, where Cn represents the context change time stamp for period tn and Cn-1 represents the context change time stamp for period tn-1. If this is the case, then there is either a deadlock or an inactive loop (endless loop).

4) If at least one context change has taken place (Cn> Cn-1), it is checked whether at least one message exchange (network input or network output event) has taken place between the service application and the basic network. If no message exchange of the service application with the basic network was observed by the runtime environment system in an adjustable period Δt, it is assumed that the service application is in a useless active loop (active loop).

5) If at least one network output event was generated by the service application in the period Δt, it is checked whether the maximum counter NEZ registering this event has now exceeded its limit value. If this is the case, an active loop is also recognized, i.e. the service application sends useless network output events.

6) It should be noted that the process environment system must also carry out additional conventional checks, for example checking the correct structure and syntax of all network events and their compatibility with the call handling in the basic network. This is done using known methods, that do not require further explanation here. In the event of errors or inconsistencies of this type, the call handling in the relevant service application is terminated by the process environment system.

Claims

claims 1. Process environment system for service applications of a communication network, with a) an application programming interface (API), which provides a network operator and / or a third party with functional modules for programming a service application (SAP), b) one Monitoring system which checks at certain points in time (tn) whether an activated service application, which has been programmed with the aid of the application programming interface, is operating logically correctly and, if necessary, causes the service application to be deactivated on the basis of the result of this check. 2nd Process environment system according to claim 1, characterized in that a) the monitoring system comprises storage means that store events sent by the communication network with respect to a call, for which a service application is waiting in the waiting state, b) the monitoring system for the said Checking points (tn) checks whether the events entered in the memory means relating to the call are logically correct, taking into account the waiting state of the service application, and cause the call to be ended and / or the service application to be deactivated , if the check of the service application with regard to this call reveals an incorrectness. 3. Process environment system according to claim 1 or 2, characterized in that a) the monitoring system comprises storage means, the event sent by the communication network with respect to a call. save for which a service application is waiting in the waiting state, b) the monitoring system checks at the aforementioned checking times (tn) whether it can be expected that the communication network will still meet the events expected by the service application will transmit and cause the termination of the call and / or the deactivation of the service application if the check shows that this will not be the case. 4. Process environment system according to one of claims 2 or 3, characterized in that the monitoring system, if no events have been entered for an activated service application in the storage means mentioned for a call, checks whether within this service application since the last check a context change has taken place and causes the termination of the call and / or the deactivation of the service application, if the check shows that this was not the case. 5. drainage environment system according to claim 4, characterized in that the monitoring system, if a context change has taken place within this service application since the last check, checks whether the service application has performed at least one message exchange and the termination of the call and / or deactivates the service application if the check shows that no message exchange has taken place. 6. Process environment according to claim 5, characterized in that the monitoring system, if at least one message exchange has been carried out since the last check, check whether the event counter (NEZ) has been exceeded and the termination of the call and / or the deactivation of the Service application initiates if the check shows that the event counter has been exceeded. 7. drainage environment system according to any one of claims 1 to 6, characterized in that the monitoring system causes the deactivation of a service application when the proportion of the termination of calls caused by the process environment system (FAU) in this service application over a certain limit - increases.