EP0850545A1 - Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes - Google Patents

Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes

Info

Publication number
EP0850545A1
EP0850545A1 EP96930159A EP96930159A EP0850545A1 EP 0850545 A1 EP0850545 A1 EP 0850545A1 EP 96930159 A EP96930159 A EP 96930159A EP 96930159 A EP96930159 A EP 96930159A EP 0850545 A1 EP0850545 A1 EP 0850545A1
Authority
EP
European Patent Office
Prior art keywords
service application
call
service
monitoring system
check
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP96930159A
Other languages
English (en)
French (fr)
Inventor
Maximilian Sevcik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to EP96930159A priority Critical patent/EP0850545A1/de
Publication of EP0850545A1 publication Critical patent/EP0850545A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0435—Details
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13533—Indexing scheme relating to selecting arrangements in general and for multiplex systems multivendor and hybrid, e.g. public/private, networks, inc. international
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13545—Indexing scheme relating to selecting arrangements in general and for multiplex systems monitoring of signaling messages, intelligent network

Definitions

  • 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.
  • the SCP 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:
  • 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.
  • 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.
  • FIGS 2 to 5 serve 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:
  • FIG. 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.
  • 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.
  • these expected events for example network messages to be received according to a known IN application protocol such as INAP or AIN
  • Context changes include, for example:
  • - procedure call including remote procedure call (RPC), - sending / processing of an internal, external message,
  • RPC remote procedure call
  • 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.
  • 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.
  • NEZ 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.
  • Basic network protocol e.g. according to the international standards INAP, AIN
  • 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.
  • FIG. 4 shows the process running in the runtime environment system for recognizing the logical errors mentioned in the service applications.
  • the triggering event of the method is the periodic Application Activity Test AAT.
  • 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).
  • 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).
  • 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.
  • 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.

Abstract

Ziel der Erfindung ist es, Netzbetreibern bzw. Dritten (z.B. Software-Häusern) die Möglichkeit zu eröffnen, ihre Service-Ideen unmittelbar und ohne den Umweg über den Netzlieferanten zu implementieren, und gleichzeitig zu gewährleisten, daß solchermaßen implementierte fehlerbehaftete Service-Applikationen keine negativen Auswirkungen haben. Dieses Ziel wird durch ein erfindungsgemäßes Ablaufumgebungssystem (FAU) erreicht.

Description

Beschreibung
Abiaufumgebungssystem für Service-Applikationen eines Kom¬ munikationsnetzes
In heutigen N-ISDN und B-ISDN Telekoinmunikationsnetzen werden Service-Applikationen im Rahmen des sogenannten Intelligenten Netzes (kurz IN) bereitgestellt.
FIG 1 zeigt die Architektur des Intelligenten Netzes. Das In¬ telligentes Netz soll es einem Netzbetreiber ermöglichen, neue Dienste (Services) rasch und problemlos einzuführen, oh¬ ne dafür in jedem Netzknoten Eingriffe in die Anlagenpro- grammsysteme vornehmen zu müssen. Die genannten Eingriffe werden deshalb in einem IN auf möglichst wenige zentrale Netzknoten, sogenannten Service Control Points SCP, be¬ schränkt, die an zentraler Stelle mit der entsprechenden App¬ likations-Software für die neuen Dienste, den sogenannten Service-Applikationen, ausgerüstet werden und dann in einer Art "Fernsteuerung" die einzelnen Netzknoten in die Lage ver¬ setzen, die neuen Dienste auszuführen.
Die genannten ferngesteuerten Netzknoten des IN werden auch als Dienst-Zugangsknoten oder Service Switching Points SSP bezeichnet. Sie sind direkt oder über ein Signalisierungsnetz wie beispielsweise das Signalisierungsnetz CCS7 mit einem Service Control Point SCP verbunden.
Ein Service Management Point SMP dient zum Administrieren der IN-Dienste durch den Netzbetreiber, den Dienstanbieter und den Dienstteilnehmer.
Ein Ruf zu einem Service des Intelligenten Netzes kann von einem normalen, d.h. von einem nicht durch den SCP fernge- steuerten Netzknoten zunächst zu einem Service Switching Point SSP geroutet werden. Anhand der gewählten Nummer und/oder des Service Codes bestimmt der Service Switching Point, welcher Service Control Point SCP die diesem Service entsprechende Service-Applikation enthält und sendet an¬ schließend zu diesem Service Control Point eine Anfrage, wie er den Ruf zu behandeln hat. Nachdem der SCP die Anfrage un- tersucht hat, sendet er eine Antwort zum Service Switching Point, die Informationen beinhaltet, die dieser zur weiteren Behandlung des Rufes benötigt.
Der Service Control Point SCP erfordert eine möglichst feh- lerfreie (Hardware/Software-)Rechnerplattform, da die Ser¬ vice-Applikationen die gleiche hohe Verfügbarkeit aufweisen müssen, wie die übrigen Komponenten im Basis-Netz (SSP und andere Vermittlungsstellen) . Aus diesem Grund werden heute die Service-Applikationen durch Software-Spezialisten der Netzlieferanten entwickelt und systematisch mit hohem Aufwand getestet. Der Netzbetreiber kann diese Service-Applikationen lediglich an den dafür vorgesehenen Stellen modifizieren (customising) . Beispiele für solche Service-Applikationen sind:
- grüne Nummer (freephone; gebührenfreie Nummer)
- Virtual Private Network
- etc.
Wünschenswert wäre nun eine Programmierung von Service-Appli¬ kationen (im SCP und teilweise im SMP) direkt durch den Netz- betreiber, bzw. dritte (z.B. Software-Häuser) . Dadurch könn¬ ten die Netzbetreiber ihre Service-Ideen unmittelbar und ohne den Umweg über den Netzlieferanten implementieren (Open Net- work Provisioning: ONP) .
Diese Möglichkeit birgt jedoch die Gefahr des Einbringens fehlerbehafteter Service-Applikationen.
Obwohl heute mit bekannten Techniken der fehlertoleranten
Hardware gearbeitet wird (N+l, 1:1 Redundanz, mikrosynchrone Systeme) , kann nicht verhindert werden, daß bei der letztge- nannten Programmierung in der Software schwerwiegende logi¬ sche Fehler zum Absturz bzw. zum dynamischen Fehlverhalten der Service-Applikationen führen. Dies hat dann üblicherweise eine Rückwirkung auf andere Service-Applikationen, bzw. auf das Basis-Netz.
Beispiele für solche logische Fehler sind:
- Ein von einer Service-Applikation erwartetes Ereignis tritt nie ein. Der Ablauf wird blockiert (Deadlock) .
- Eine Service-Applikation geht in eine inaktive Schleife (endless loop) , in der keine sinnvolle Funktion mehr ab¬ läuft.
- Eine Service-Applikation führt periodisch einen Nachrich¬ tenaustausch mit dem Basis-Netz oder mit anderen SCP-Funk- tionen, ohne jedoch eine sinnvolle Netzfunktion auszuführen (active loop) . Es besteht die Gefahr der Systemüberlast auch für andere, unbeteiligte Service-Applikationen.
Ohne Gegenmaßnahmen gegen diese Art von logischen Fehlern ist die Öffnung des SCP/SMP für die Service-Programmierung durch Netzbetreiber bzw. Dritte nicht möglich.
Der Erfindung liegt die Aufgabe zugrunde, Netzbetreibern bzw. Dritten (z.B. Software-Häuser) die Möglichkeit zu eröffnen, ihre Service-Ideen unmittelbar und ohne den Umweg über den Netzlieferanten zu implementieren, und gleichzeitig zu ge- währleisten, daß solchermaßen implementierte fehlerbehaftete Service-Applikationen keine negativen Auswirkungen haben.
Diese Aufgabe wird durch ein Ablaufumgebungssystem gemäß An¬ spruch 1 gelöst.
Im folgenden wird ein Ausführungsbeispiel der Erfindung an¬ hand der Zeichnung näher erläutert. Die Zeichnung umfaßt fünf Figuren, wobei die FIG 2 bis 5 zur Darstellung des Ausfüh¬ rungsbeispiels dienen.
Die fehlertolerante Ablaufumgebung im SCP soll möglichst schnell folgende schwerwiegende logische Software-Fehlerklas¬ sen in den Service-Applikationen erkennen und nach Bedarf die Behandlung der Rufe oder anderer Netzfunktionen durch die fehlerhafte Service-Applikation sofort beenden:
l) Deadlock beim Warten auf SCP-interne Ressources/Ereignisse sowie auf Ereignisse aus dem Basis-Netz,
2) Endiess Loop,
3) Active Loop
Für andere Software-Fehlerklassen wie z.B. Adressfehler,
Speicherschutz-Verletzung usw., gilt die Erkennung und Be¬ handlung als bekannt und wird hier nicht weiter behandelt.
FIG 2 zeigt eine SCP-Architektur, die ein erfindungsgemäßes Ablaufumgebungssystem FAU umfaßt. Für den SMP ist eine ent¬ sprechende Architektur anwendbar.
Das Ablaufumgebungssystem FAU stellt den Service-Applikatio¬ nen SAP ein ausfallsicheres Application Programming Interface API zur Verfügung. Das API stellt einem Netzbetreiber und/oder einem Dritten ein System von Funktions-Bausteinen zur Programmierung einer individuellen SAP zur Verfügung. Das FAU und die API sind vom Systemlieferanten ausführlich, d.h. stabil, getestet worden und führen somit die durch das API repräsentierten Funktionen (einzeln betrachtet) fehler¬ frei aus.
FIG 3 zeigt das Verfahren im Ablaufumgebungssystem zur Erken¬ nung der genannten logischen Software-Fehlerklassen, nämlich Deadlock, Endiess Loop und Active Loop in den Service-Appli- kationen. Das Verfahren beinhaltet folgende Merkmale bzw. Verfahrensschritte: 1) Erreicht eine aktivierte (d.h. im Betrieb befindliche) Service-Applikation einen Zustand, in welchem sie auf ein oder mehrere Netzinput-Ereignisse wartet, werden diese er- warteten Ereignisse (z.B. zu empfangende Netzmeldungen ge¬ mäß einem bekannten IN-Anwendungsprotokoll wie INAP oder AIN) zusammen mit ihrer Kennung in eine sogenannte Ereig¬ nisliste IER des FAU eingetragen. Verläßt die genannte Service-Applikation diesen Wartezustand, werden die diesem Zustand entsprechenden Ereignisse vom FAU aus der Ereig¬ nisliste IER entfernt.
2) Bei jedem Kontextwechsel zwischen zwei SAP-internen Funk¬ tionen wird von der FAU ein Zeitstempel (Kontextwechsel- zeitstempel Cn) für dieses Ereignis gespeichert. Als Kon¬ textwechsel gelten z.B.:
- Methodenaufruf eines Objektes bei objektorientierter Software-Architektur,
- Prozeduraufruf inkl. Remote Procedure Call (RPC) , - Aussenden/Bearbeiten einer internen, externen Meldung,
- etc.
Die Kontextwechselereignisse werden normalerweise vom unter¬ liegenden Betriebssystem erkannt und im Ablaufumgebungssy- stem, bezogen auf die relevanten Service-Applikationen, be¬ handelt. Durch den Kontextwechsel-Zeitstempel kann das FAU die Aktivität einer SAP beurteilen.
3) Ein Zeitstempel te des letzten vom Basis-Netz empfangenen Netzinput-Ereignisses bzw. des an das Basis-Netz ausgege¬ benen Netzoutput-Ereignisses, dessen Bedeutung später deutlich wird, wird ebenfalls vom Ablaufumgebungssystem gespeichert.
4) Pro Netzoutput-Ereignis wird ein Ereigniszähler NEZ im Ab¬ laufumgebungssystem geführt. Alle möglichen Netzoutput-Er¬ eignisse und ihre maximale Anzahl sind bei einem gegebenen Basis-Netz-Protokoll (z.B. gemäß den internationalen Standards INAP, AIN) wohl definiert.
5) Das AblaufUmgebungssystem löst periodisch einen Applica- tion Activity Test AAT aus. Die einstellbare Zeitperiode wird im Ablaufumgebungssystem als Zeitstempel tn festge¬ halten.
FIG 4 zeigt das im Ablaufumgebungssystem ablaufende Verfahren zur Erkennung der genannten logischen Fehler in den Service- Applikationen.
FIG 5 zeigt den Zusammenhang zwischen den wichtigsten Ereig¬ nissen.
Das in FIG 4 dargestellte Verfahren läuft wie folgt ab:
1) Auslöseereignis des Verfahrens ist der periodische Appli¬ cation Activity Test AAT.
2) Zum Zeitpunkt der Periode tn des Application Activity
Tests wird zunächst die Liste IER der Netzinput-Ereignisse für einen bestimmten Ruf untersucht. Ist diese nicht leer, wird überprüft, ob alle eingetragenen Netzinput-Ereignisse logisch korrekt sind. Dieser Test wird aus Kenntnis des standardisierten Basis-Netz-Protokolls (z.B. INAP, AIN) abgeleitet) .
Bei Fehlern wird die Behandlung des genannten Rufes durch die zughörige Service-Application beendet (Deadlock: War- ten auf ein Ereignis, das nie eintrifft) .
Falls die in der Liste IER eingetragenen Netzinput-Ereig¬ nisse logisch andererseits korrekt sind, wird ferner über¬ prüft, ob das Basis-Netz diese Netzinput-Ereignisse über¬ haupt aussenden kann (wenn der Ruf durch das Basis-Netz vorzeitig beendet wurde, ist diese Aussendung z.B. nicht möglich) . Hierzu wird mit einem bekannten Verfahren ein Netz Activity Test NAT durchgeführt, indem eine dafür standardisierte Testtransaktion durchgeführt wird (z.B. als Bestandteil des INAP-, AIN-Protokolls) . Wird dabei festgestellt, daß der Ruf im Basis-Netz noch aktiv ist, wird die Ruf-Bearbeitung in der Service-Applikation weiter fortgesetzt.
3) Ist die Ereignisliste IER leer, wird anhand des Zeitstem¬ pelvergleichs Cn, Cn-1 überprüft, ob diese Service-Appli¬ kation seit der letzten AAT-Periode keine Kontextwechsel durchgeführt hat, d.h. ob Cn=Cn-l gilt, wobei Cn den Kon¬ textwechsel-ZeitStempel zur Periode tn und Cn-1 den Kon¬ textwechsel-Zeitstempel zur Periode tn-1 darstellt. Ist dies der Fall, dann liegt entweder ein Deadlock oder eine inaktive Schleife (Endless Loop) vor.
4) Hat mindestens ein Kontextwechsel stattgefunden (Cn>Cn-l) wird überprüft, ob zwischen Service-Applikation und Basis- Netz mindestens einen Nachrichtenaustausch (Netzinput- oder Netzoutput-Ereignis) stattgefunden hat. Wurde in ei- nem einstellbaren Zeitraum Δt kein Nachrichtenaustausch der Service-Applikation mit dem Basis-Netz durch das Ab¬ laufumgebungssystem beobachtet, wird angenommen, daß die Service-Applikation sich in einer nutzlosen aktiven Schleife (Active Loop) befindet.
5) Wenn im Zeitraum Δt mindestens ein Netzoutput-Ereignis durch die Service-Applikation erzeugt wurde, wird über¬ prüft, ob der dieses Ereignis registrierende Maximalzähler NEZ nunmehr seinen Grenzwert überschritten hat. Ist dies der Fall, wird ebenfalls ein Active Loop erkannt, d.h. die Service-Applikation sendet nutzlose Netzoutput-Ereignisse.
6) Anzumerken ist, daß das AblaufUmgebungssystem noch zusätz¬ liche konventionelle Überprüfungen vornehmen muß, z.B. Kontrolle der richtigen Struktur und Syntax aller Netzer¬ eignisse und ihrer Kompatibilität mit der Ruf-Behandlung im Basis-Netz. Dies wird mit bekannten Verfahren gemacht, die hier nicht der näheren Erläuterung bedürfen. Bei Feh¬ lern bzw. Inkonsistenzen dieser Art wird vom Ablaufumge- bungssystem die Ruf-Behandlung in der betreffenden Ser¬ vice-Applikation abgebrochen.

Claims

Patentansprüche
1. Ablaufumgebungssystem für Service-Applikationen eines Kom¬ munikationsnetzes, mit a) einem Application Programming Interface (API) , das einem Netzbetreiber und/oder einem Dritten Funktions-Bausteine zur Programmierung einer Service-Applikation (SAP) zur Verfügung stellt, b) einem Überwachungssystem, das zu bestimmten Zeitpunkten (tn) überprüft, ob eine aktivierte Service-Applikation, die mit Hilfe des Application Programming Interface pro¬ grammiert wurde, logisch korrekt arbeitet und aufgrund des Ergebnisses dieser Überprüfung gegebenenfalls die Deakti¬ vierung der Service-Applikation veranlaßt.
2 . Ablauf Umgebungssystem nach Anspruch 1 , d a d u r c h g e k e n n z e i c h n e t , daß a) das Überwachungssystem Speichermittel umfaßt, die vom Kom- munikationsnetz bezüglich eines Rufes gesendete Ereignis¬ se, auf die eine Service-Applikation im Wartezustand war¬ tet, speichern, b) das Überwachungssystem zu den genannten Überprüfungszeit¬ punkten (tn) überprüft, ob die in den Speichermitteln be- züglich des Rufes eingetragenen Ereignisse unter Berück¬ sichtigung des Wartezustandes der Service-Applikation lo¬ gisch korrekt sind und die Beendigung des Rufes und/oder die Deaktivierung der Service-Applikation veranlaßt, falls die Überprüfung der Service-Applikation bezüglich dieses Rufes eine Inkorrektheit ergibt.
3. AblaufUmgebungssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet , daß a) das Überwachungssystem Speichermittel umfaßt, die vom Kom¬ munikationsnetz bezüglich eines Rufes gesendete Ereignis- se, auf die eine Service-Applikation im Wartezustand war¬ tet, speichern, b) das Überwachungssystem zu den genannten Überprüfungszeit¬ punkten (tn) überprüft, ob zu erwarten ist, daß das Kommu¬ nikationsnetz die von der Service-Applikation erwarteten Ereignisse noch aussenden wird und die Beendigung des Ru¬ fes und/oder die Deaktivierung der Service-Applikation veranlaßt, falls die Überprüfung ergibt, daß dies nicht der Fall sein wird.
4. AblaufUmgebungssystem nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet , das Überwachungssystem, falls für eine aktivierte Service- Applikation in den genannten Speichermitteln bezüglich eines Rufes keine Ereignisse eingetragen sind, überprüft, ob inner¬ halb dieser Service-Applikation seit der letzten Überprüfung ein Kontextwechsel stattgefunden hat und die Beendigung des Rufes und/oder die Deaktivierung der Service-Applikation ver¬ anlaßt, falls die Überprüfung ergibt, daß dies nicht der Fall war.
5. Abiaufumgebungssystem nach Anspruch 4, dadurch gekennzeichnet, daß das Überwachungssystem, falls innerhalb dieser Service- Applikation seit der letzten Überprüfung ein Kontextwechsel stattgefunden hat, überprüft, ob die Service-Applikation min¬ destens einen Nachrichtenaustausch vorgenommen hat und die Beendigung des Rufes und/oder die Deaktivierung der Service- Applikation veranlaßt, falls die Überprüfung ergibt, daß kein Nachrichtenaustausch vorgenommen wurde.
6. AblaufUmgebungssystem nach Anspruch 5, dadurch gekennzeichnet , daß das Überwachungssystem, falls seit der letzten Überprü- fung mindestens ein Nachrichtenaustausch vorgenommen wurde, überprüfen, ob der Ereigniszähler (NEZ) überschritten wurde und die Beendigung des Rufes und/oder die Deaktivierung der Service-Applikation veranlaßt, falls die Überprüfung ergibt, daß der Ereigniszähler überschritten wurde.
7. Abiaufumgebungssystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet , daß das Überwachungssystem die Deaktivierung einer Service- Applikation veranlaßt, wenn der Anteil der durch das Ablauf- umgebungssystem (FAU) bedingten Beendigungen von Rufen bei dieser Service-Applikation einen bestimmten Grenzwert über- steigt.
EP96930159A 1995-09-15 1996-09-03 Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes Ceased EP0850545A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP96930159A EP0850545A1 (de) 1995-09-15 1996-09-03 Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP95114576 1995-09-15
EP95114576 1995-09-15
PCT/EP1996/003865 WO1997010683A1 (de) 1995-09-15 1996-09-03 Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes
EP96930159A EP0850545A1 (de) 1995-09-15 1996-09-03 Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes

Publications (1)

Publication Number Publication Date
EP0850545A1 true EP0850545A1 (de) 1998-07-01

Family

ID=8219619

Family Applications (1)

Application Number Title Priority Date Filing Date
EP96930159A Ceased EP0850545A1 (de) 1995-09-15 1996-09-03 Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes

Country Status (3)

Country Link
US (1) US6496861B1 (de)
EP (1) EP0850545A1 (de)
WO (1) WO1997010683A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19844825A1 (de) * 1998-09-30 2000-04-13 Alcatel Sa Verfahren, Dienststeuerungseinheit, Dienstvermittlungsstelle und Kombinationsknoten zum Bereitstellen von Telekommunikationsdiensten
US6647420B2 (en) * 2001-01-18 2003-11-11 Reynolds And Reynolds Holdings, Inc. Enterlink for providing a federated business to business system that interconnects applications of multiple companies
US7231433B1 (en) 2000-01-19 2007-06-12 Reynolds And Reynolds Holdings, Inc. Enterlink for providing a federated business to business system that interconnects applications of multiple companies
US6693898B1 (en) * 2000-02-01 2004-02-17 Lucent Technologies, Inc. Call control model for a packet-based intelligent telecommunications network
US6766482B1 (en) 2001-10-31 2004-07-20 Extreme Networks Ethernet automatic protection switching
US7757242B2 (en) * 2006-05-26 2010-07-13 International Business Corporation Apparatus, system, and method for asynchronous outbound transaction event processing into an SAP application using service oriented architecture
US7917651B2 (en) * 2006-05-26 2011-03-29 International Business Machines Corporation Apparatus, system, and method for asynchronous complex inbound transactions from SAP applications using service oriented architecture

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4617663A (en) * 1983-04-13 1986-10-14 At&T Information Systems Inc. Interface testing of software systems
AU8449991A (en) * 1990-07-20 1992-02-18 Temple University - Of The Commonwealth System Of Higher Education System for high-level virtual computer with heterogeneous operating systems
JP2734465B2 (ja) * 1991-04-10 1998-03-30 三菱電機株式会社 ネットワーク用入出力装置
US5237684A (en) * 1991-08-12 1993-08-17 International Business Machines Corporation Customized and versatile event monitor within event management services of a computer system
US5488648A (en) * 1993-08-17 1996-01-30 Telefonaktiebolaget L M Ericsson Behavior monitoring and analyzing system for stored program controlled switching system
CA2188288C (en) * 1994-04-21 2000-08-29 Donald George Paul Waters Service creation apparatus for a communications network
US5956489A (en) * 1995-06-07 1999-09-21 Microsoft Corporation Transaction replication system and method for supporting replicated transaction-based services
US5751964A (en) * 1995-09-12 1998-05-12 International Business Machines Corporation System and method for automatic determination of thresholds in network management
DE69626127T2 (de) * 1995-11-02 2003-10-23 British Telecomm Diensterzeugungsvorrichtung für ein Kommunikationsnetz und entsprechendes Verfahren

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9710683A1 *

Also Published As

Publication number Publication date
WO1997010683A1 (de) 1997-03-20
US6496861B1 (en) 2002-12-17

Similar Documents

Publication Publication Date Title
DE69837010T2 (de) System und verfahren zum steuern des zugriffs auf eine vermittlungsdatenbank
EP0743595B1 (de) Kommunikationssystem mit Mitteln zum Austausch von Software
DE60109709T2 (de) Datenverwaltungsrahmenwerk für Verfahrensverwaltung
DE19681682B4 (de) Telekommunikationsnetz-Verwaltungssystem
DE69932567T2 (de) Redundante Anrufverarbeitung
DE69733266T2 (de) Ausfallsicheres und ereignisgesteuertes transaktions-system und verfahren
DE69829759T2 (de) Verteilung von nachrichten zu dienststeuereinrichtungen
DE602005004334T2 (de) Nms zur Verarbeitung von Multi-Server Ereignissen
DE69732221T2 (de) Verfahren zum Anbieten von einem Dienst an Fernmeldenetzbenutzern
EP0915435B1 (de) Verfahren zum gesicherten Speichern von veränderlichen Daten
EP0825524A1 (de) Verfahren zur Verwaltung der Benennung von Objekten
DE69833026T2 (de) Verfahren und system zur automatischen überprüfung der bereitstellung von fernmeldediensten
EP0973342A2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
EP0779733A2 (de) Verfahren zur Vergebührung der Nutzung eines Telekommunikations-Dienstes sowie Vermittlungssystem, Dienststeuereinrichtung und Netzwerkmanagementeinrichtung
EP1002395A1 (de) Bedieneinrichtung zur bedienung eines netz-management-systems
EP0959588A2 (de) Netzelement mit einer Steuerungseinrichtung und Steuerungsverfahren
DE10000825A1 (de) Verfahren, Vermittlungsstelle, Gebührenrechner, Gebührenabrechnungsrechner und Programm-Module zur Verarbeitung von Gebührendaten für Telekommunikations-Dienstleistungen
DE69731182T2 (de) Nachrichtenverfahren zwischen einer Dienstvermittlungsstelle und einer Dienstkontrolleinrichtung in einem Fernmeldenetz
DE69825560T2 (de) Intelligentes netzwerk mit einer verteilten dienststeuerungsfunktion
EP0850545A1 (de) Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes
EP1198143A2 (de) Netzwerk-Management System
EP0680238A2 (de) Programmgesteuerte Einrichtung insbesondere Breitband-ISDN-Kommunikationseinrichtung mit mindestens einem in dieser ablaufenden Vermittlungstechnischen Prozess
DE60101999T2 (de) Dienstenentwicklungsumgebung
EP1371236A1 (de) Verfahren zur selektiven und gesammelten weiterleitung von meldungen in einem tmn-netzwerk
DE19717112C2 (de) Verfahren und Wartungsanlage zum Betreiben eines Telekommunikationsnetzes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19980304

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 20001228

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APBX Invitation to file observations in appeal sent

Free format text: ORIGINAL CODE: EPIDOSNOBA2E

APBZ Receipt of observations in appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNOBA4E

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

APAA Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOS REFN

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20060319

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E