Operational environment system and method for communication...

Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C709S202000, C709S223000, C709S241000, C709S241000, C714S100000, C714S004110

Reexamination Certificate

active

06496861

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates, generally, to operational environment systems and methods for communication network service applications and, more specifically, to an operational environment system and method which allows operators and third parties to implement service ideas directly into a communication network without having to pass through a network supplier and which ensures that faulty service applications implemented in such a way have no negative effects.
2. Description of the Prior Art
In present-day N-ISDN and B-ISDN telecommunications networks, Service Applications are provided as part of the known Intelligent Network (IN for short).
FIG. 1
shows the architecture of the Intelligent Network. The Intelligent Network is intended to allow a network operator to introduce new services quickly and without any problems, and without having to take any actions relating to the installation program systems in each network node. Such actions in an IN are therefore limited to as few central network nodes, so-called Service Control Points SCP, as possible. These points, at a central point, are equipped with the appropriate application software for the new services, the so-called Service Applications, after which, by a type of “remote control”, it is possible for the individual network nodes to implement the new services.
The remote-control network nodes of the IN are also called Service Access nodes or Service Switching Points SSP. They are connected to a Service Control Point SCP directly or via a signalling network, such as the CCS
7
signalling network. A Service Management Point SMP is used by the network operator, the service provider and the service subscriber to administer the IN services.
A call to a service on the Intelligent Network may first of all be routed to a Service Switching Point SSP from a normal network node, that is to say a network node that is not remotely controlled by the SCP. The Service Switching Point uses the dialed number and/or the Service Code to determine 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 must process the call. Once the SCP has investigated the request, it sends a reply to the Service Switching Point, which reply contains information that the Service Switching Point requires to continue processing the call.
The Service Control Point SCP requires a hardware/software computer platform that is as fault-free as possible 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, the Service Applications are nowadays developed by the network suppliers' software specialists and are systematically tested, at high cost. All that the network operator can do is to modify, i.e. customize these Service Applications at the points provided for this purpose. Examples of such Service Applications include:
“green” numbers (freephone; toll-free numbers)
Virtual Private Network
It would therefore be desirable for Service Applications (in the SCP and, to some extent, in the SMP) to be programmed directly by the network operator or third parties; for example, software houses. In this way, network operators can implement their service ideas directly and without passing via the network suppliers (Open Network Provisioning: ONP). However, this capability involves a risk of the introduction of faulty Service Applications.
Although known fault-tolerant hardware techniques are known (N+1, 1:1 redundancy, microsynchrone systems), it is impossible to prevent serious logic faults when programming software in the way mentioned above, such may lead to the system applications crashing or behaving incorrectly in a dynamic situation. This normally causes a reaction on other Service Applications and/or on the basic network.
Examples of such logic faults include:
An event expected by a Service Application never occurs. The operation is blocked (deadlock).
A Service Application goes into an inactive loop (endless loop) in which sensible functions are no longer carried out.
A Service Application periodically carries out a message interchange with the basic network or with other SCP functions, but without carrying out any sensible network function (active loop). There is also a risk of system overload for other Service Applications that are not involved.
Without any countermeasures against this type of logic fault, it is impossible to allow network operators and/or third parties to have access to the SCP/SMP for service programming.
SUMMARY OF THE INVENTION
The invention is based on the object of making it possible for network operators and/or third parties, for example, software houses, to implement their service ideas directly and without passing via the network suppliers, and at the same time to ensure that faulty Service Applications implemented in such a way have no negative effects.
In an embodiment of the present invention, an operational environment system on a communication network is disclosed which includes an Application Programming Interface (API) which has function modules accessible by network operators and/or third parties for programming purposes, a Service Application Program (SAP) which is programed into the API via the function modules, and a monitoring system which checks at predetermined times whether the SAP is operating logically correctly and which deactivates the operation of the SAP upon an incorrect operation.
In an embodiment, the operational environment system further includes one or more events transmitted by the communication network to the monitoring system and for which the SAP is waiting in a wait state, storage means in the monitoring system for storing the one or more events, and wherein the monitoring system checks whether the one or more events are logically correct taking account of the wait state of the SAP and thereafter ends the call and/or deactivates the operation of the SAP upon an incorrect operation.
In an embodiment of the operational environment system, the monitoring system checks whether it is to be expected that the communication network will still transmit events and thereafter ends the call and/or deactivates the operation of the SAP upon a finding that no events will be transmitted.
In an embodiment of the operational environment system, the monitoring system checks, if no events have been entered in the storage means, whether a context change has occurred within the SAP since a last check and thereafter ends the call and/or deactivates the operation of the SAP upon finding that no context change has occurred.
In an embodiment of the operational environment system, the monitoring system checks, if a context change has occurred with the SAP since the last check, whether the SAP has carried out at least one message interchange and thereafter ends the call and/or deactivates the operation of the SAP if the check indicates that no message interchange has occurred.
In an embodiment, the operational environment system further includes an event counter, wherein the monitoring system checks whether the event counter has overrun, if at least one message interchange has taken place since the last check, and thereafter ends the call and/or deactivates the operation of the SAP if the check indicates that the event counter has overrun.
In a further embodiment of the present invention, a method of addressing faults in an operational environment system on a communication network is disclosed which includes the steps of: providing an Application Programming Interface (API) in the operational environment system wherein the API includes function modules accessible by network operators and/or third parties; programming a Service Application Program (SAP) into the function module; providing a monitoring system in the operational environment system; using the monitoring system to check at predetermined times whether the SAP is operating logically correctly; a

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Operational environment system and method for communication... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Operational environment system and method for communication..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Operational environment system and method for communication... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2934936

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.