DE69733066T2

DE69733066T2 - Validierung von prozessen in einem netz

Info

Publication number: DE69733066T2
Application number: DE69733066T
Authority: DE
Inventors: Bart Jellema; Rene Peeren; Louise Croughan; Freek Aben
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1996-07-19
Filing date: 1997-07-16
Publication date: 2006-05-04
Anticipated expiration: 2017-07-17
Also published as: KR20000067859A; NO316200B1; EP0913063A2; WO1998004091A3; DK0913063T3; BR9710489A; CA2260817A1; JP2000514975A; CA2260817C; NO990213L; CN1230321A; GB2315646B; AU725000B2; ES2239360T3; KR100454537B1; JP4279353B2; EP0913063B1; AU3767597A; GB2315646A; DE69733066D1

Description

Diese Erfindung betrifft ein Verfahren zur Validierung einer Prozedur in einem Netzwerkprotokoll. Insbesondere betrifft die Erfindung ein Netzwerkprotokoll wie das Intelligent Network Application Protocol (INAP), das für die Unterstützung des Capability Set 1 (CS1) erforderlich ist, das in dem Europäischen Telekommunikationsstandard ETS 300 374 definiert ist.
In einem Protokoll wie INAP CS1 treten eine Anzahl gültiger Prozeduren oder Befehlsabfolgen auf, die durchgeführt werden können, um bestimmte Aufgaben auszuführen. Da jedoch die Anzahl der möglichen Prozeduren groß ist, werden die gültigen Prozeduren nicht direkt, sondern mittels eines Satzes von Regeln definiert. Jegliche Prozedur oder Befehlsabfolge, die diese Regeln nicht übertritt, wird somit als gültige Prozedur betrachtet.
Im Stand der Technik können die Regeln durch das Definieren einer Finite State Machine (FSM) bezüglich jeder Entität und jeder Schnittstelle beschrieben werden, wobei eine Schnittstelle eine Grenze zwischen zwei Entitäten ist. Die FSM funigert dann als Modell für das Verhalten eines Prozesses. Eine FSM besteht aus Zuständen, die miteinander verbunden werden können. Ein Prozess kann nur einmal in einem Zustand vorhanden sein, kann sich aber als Ergebnis eines Ereignisses von einem Zustand zu einem verbundenen Zustand bewegen. Bei dem Übergang von einem Zustand zu einem anderen können Aktionen ausgeführt werden. Solch ein System wird beschrieben in KAKUDA et al, „A Dynamic Resolution Method for Feature Interactions and its Evolution", Feature Interaction in Telecommunications Systems III, Seiten präsentiert beim dritten Feature Interaction Workshop (FIW' 9, KYOTO, JP, 11.–13. Okt. 1995).
Wenn eine FSM zur Validierung einer Prozedur in einem Netzwerkprotokoll benutzt wird, sind die Ereignisse somit Befehle, die in dem Protokoll definiert sind, oder andere Ereignisse, die aus anderen Prozessen wie dem Rufprozess kommen. Die Regeln, die die gültigen Prozeduren in einem Netzwerkprotokoll wie INAP CS1 definieren, sind die Regeln bezüglich der Single Association Control Function (SACF) und der Multiple Association Control Function (MACF). Die SACF-Regeln finden Anwendung, wo eine einzelne Assoziation vorhanden ist, und die MACF-Regeln finden Anwendung, wo es mehrere, zusammenhängende Assoziationen gibt, wobei eine Assoziation ein Signalisierungskanal ist, der eine spezifische Schnittstelle benutzt, die die Kommunikation zwischen zwei Entitäten ermöglicht.
Leider erfordert die formelle Beschreibung aller SACF-Regeln und MACF-Regeln mit einer einzigen FSM eine zu komplexe FSM. Daraus folgt, dass viele Prozeduren, umfassend alle MACF-Prozeduren, immer noch in natürlicher Sprache definiert werden. Es gibt keine Mechanismen zur Validierung von Regeln für diesen Prozedurtyp, nämlich Prozeduren, die nicht bezüglich einer einzigen FSM pro Assoziation spezifiziert werden können.
Die vorliegende Erfindung betrifft ein Verfahren zur Validierung einer Prozedur dadurch, dass die Regeln von multiplen FSMs spezifiziert werden können. Insbesondere können mehrere Prozesse, die jeweils eine spezifische FSM starten, an der Validierung eines einzigen Ereignisses beteiligt sein.
Die Validierung eines Ereignisses findet in zwei Phasen statt. Zuerst werden die relevanten Prozesse durch Festlegen, ob sie bestimmte Kriterien erfüllen, ausgewählt. In der zweiten Verarbeitungsphase verarbeiten alle ausgewählten Prozesse das Ereignis.
Dies hat den Vorteil, dass sich alle beteiligten Prozesse in einem stabilen Zustand befinden, bevor ein Ereignis von irgendwelchen Prozessen verarbeitet wird.
Zum besseren Verständnis der vorliegenden Erfindung wird nun beispielhaft auf die beiliegenden Zeichnungen Bezug genommen.
1 ist eine Darstellung von zwei FSMs, die eine Container-Schnittstelle gemeinsam benutzen.
2 stellt eine Situation dar, in der ein Prozess Ax, der A startet, zwei Prozesse Bx und By beinhaltet, die B starten.
3 stellt eine FSM dar, die selbst aus einer Anzahl anderer FSMs besteht.
4 stellt die FSM zur Sitzungsansicht dar.
5 stellt die FSM zur Rufansicht dar.
6 stellt die FSM zur Cp oder Ap dar.
Gemäß der Erfindung kann die Validierung einer Prozedur mehrere Prozesse umfassen, und die erste Phase der Validierung umfasst das Auswählen der Prozesse, die an der Validierung beteiligt sind.
Die Auswahl der Prozesse benutzt Kritierien, die auf Eigenschaften und gegenseitigen Beziehungen der FSMs basieren, die die jeweiligen Entitäten und Schnittstellen darstellen.
Zuerst wird bestimmt, ob irgendwelche FSMs eine „Container-Schnittstelle" gemeinsam benutzen. 1 ist eine Darstellung von zwei FSMs A und B, die eine Container-Schnittstelle gemeinsam benutzen. Wenn zwei FSMs diesen Schnittstellentyp gemeinsam benutzen, wird eine als in der anderen beinhaltet betrachtet, die wiederum die erste enthält. In dem Beispiel von 1 enthält FSM A FSM B, und FSM B ist in FSM A beinhaltet. Eine erste FSM, die in einer zweiten FSM beinhaltet ist, ist definitionsgemäß auch in irgendeiner dritten FSM beinhaltet, die eine zweite FSM enthält. Das heißt, wenn A in B beinhaltet ist, und B in C beinhaltet ist, ist definitionsgemäß A auch in C beinhaltet. Es kann behauptet werden, dass A indirekt in C beinhaltet ist. Sofern nicht anderweitig erwähnt, bedeutet der Begriff „beinhaltet" wie hier benutzt sowohl direkt als auch indirekt beinhaltet und könnte als solcher eine Beziehung zwischen mehr als zwei FSMs bestimmen. Interaktionen zwischen Prozessen über eine Assoziation auf einer Container-Schnittstelle werden anders behandelt als andere Interaktionstypen.
Eine Schnittstelle kann als Container-Schnittstelle klassifiziert werden, wenn Folgendes für beide FSMs gilt.
eine FSM ist nur direkt in einer anderen FSM beinhaltet;
eine FSM ist nicht in sich selbst beinhaltet;
ein Prozess, der eine FSM startet, hat keine Assoziationen mit mehr als einem Prozess, der eine FSM startet, in der die erste direkt beinhaltet ist.
Bezüglich 1 weist ein Prozess, der eine FSM B startet, folglich nur eine Assoziation mit maximal einem Prozess auf, der FSM A startet. Ein Prozess, der FSM A startet, kann jedoch Assoziationen mit mehreren Prozessen aufweisen, die FSM B starten (diese Anwendungen betreffen so den Prozess, der FSM A startet). A oder B können auch andere (nicht Container-) Schnittstellen aufweisen. In 1 wird FSM B mit einer anderen Schnittstelle I1 dargestellt.
Einzelheiten von Beinhaltungsbeziehungen können in einem System einfach in Form eines Baums gespeichert werden, der nachstehend als FSM-Baum bezeichnet wird. Die Wurzel des FSM-Baums ist eine FSM, die in keiner anderen FSM beinhaltet ist. Die Blätter des FSM-Baums sind FSMs, die keine anderen FSM enthalten.
Das Beinhaltungskonzept ist auch für Prozesse gültig: ein Prozess ist in einem anderen Prozess beinhaltet, wenn die FSM, die von der ersten gestartet wird, in der FSM beinhaltet ist, die von der zweiten gestartet wird. Außerdem müssen die zwei Prozesse auch assoziiert werden, entweder direkt oder indirekt, über einen Prozess, mit dem sie beide (direkt oder indirekt) assoziiert werden. Zum Beispiel stellt 2 eine Situation dar, in der ein Prozess Ax, der A startet, zwei Prozesse Bx und By beinhaltet, die B starten.
Wie FSMs können die Einzelheiten dieser Beinhaltungsbeziehungen in einem System einfach in Form eines Baums gespeichert werden, der nachstehend als Prozess-Baum bezeichnet wird. Wenn der Prozess-Baum gescannt wird, kann entweder eine getrennte Datenstruktur benutzt werden, oder die Assoziationen zwischen den Prozessen können benutzt werden. Der Satz von Prozessen, die sich in dem gleichen Prozess-Baum befinden, bilden eine Basis für den Auswahlprozess.
Die zweite Eigenschaft, die zur Definition der Auswahlkriterien für die Prozesse benutzt wird, ist der „Container-Kontext", der ein Satz von vordefinierten Werten ist, die unterschiedliche, mögliche Kontexte eines zu validierenden Ereignisses identifizieren. Unterschiedliche Ereignisse, die die gleiche Assoziation benutzen, können somit unterschiedliche Kontexte aufweisen. Zum Beispiel befinden sich in CS1 einige Befehle im Kontext einer einzigen Partei, die an dem Ruf beteiligt ist.
Prozesse können auch einem Container-Kontext zugeordnet werden. In diesem Fall identifiziert dies eine Beziehung zwischen einem Ereignis und einem spezifischen Prozess.
Wenn folglich ein Ereignis (das „aktuelle" Ereignis) validiert werden soll, ist es möglich, einen Satz von Prozessen zu identifizieren, der sich mit dem Container-Kontext des aktuellen Ereignisses deckt.
Die Zuordnung von Container-Kontexten wird durch Zuordnen eines Satzes von Container-Kontexten zu jeder FSM durchgeführt: Fx = (CC1, CC2, ... CCn). Ein Container kann keiner FSM zugeordnet werden, wenn er schon einer FSM zugeordnet ist, die ihn enthält oder in der er beinhaltet ist. Dies muss vom System überprüft werden, wenn Container-Kontexte FSMs zugeordnet werden. Ein Ereignis kann einem einzigen Container-Kontext zugeordnet werden. Dieser Container-Kontext wird dann auch dem aktuellen Ereignis zugeordnet und als „aktueller Container-Kontext" bezeichnet. Angesichts des Satzes von Ereignissen, die auf einer bestimmten Schnittstelle ankommen können, müssen alle möglichen Container-Kontexte für den Satz von Ereignissen einer FSM zugeordnet worden sein, die die FSM, die die Schnittstelle gemeinsam benutzt, ist, diese enthält oder in ihr beinhaltet ist.
Jeder Prozess in einem Prozess-Baum wird einem Container-Kontext aus Fx zugeordnet, so dass unterschiedliche Prozesse, die die gleiche FSM starten, und Teil des gleichen Prozess-Baums, unterschiedlichen Container-Kontexten zugeordnet werden.
Zum Beispiel können in einem Protokoll 30 mögliche Leg-IDs vorhanden sein, die jeweils als ein Container-Kontext benutzt werden können. Einige Befehle sind für den ganzen Ruf gültig (zum Beispiel Ruf Freigeben), und sie haben den Ruf als Container-Kontext. Ein Befehl, der eine Leg-ID als Parameter aufweisen kann, wird als 30 getrennte Ereignisse betrachtet (eins für jede mögliche Leg-ID). Dies erfordert eine Analyse des Befehls, um ihn einem der 30 möglichen Ereignisse zuzuordnen (zum Beispiel bestimmt der Leg-ID-Parameter oder der voreingestellte Leg-ID-Parameter das Zuordnen von Befehl zu Ereignis).
Die dritte Eigenschaft, die beim Definieren der Auswahlkriterien für die Prozesse benutzt wird, ist die „Container-Aktionen", die ein besonderer Satz von Aktionen ist, der an Zustandsübergängen in einer FSM bestimmt werden kann. Diese Aktionen können die Verarbeitung des aktuellen Ereignisses durch andere Prozesse beeinflussen. Zum Beispiel können sie einen anderen Prozess dazu veranlassen, das Ereignis nicht zu verarbeiten, obwohl er dafür bestimmt war.
Jedes System weist eine Anzahl von definierten Container-Aktionen auf. Da Container-Aktionen andere Prozesse beeinflussen können, können Konflikte auftauchen, wenn mehrere Prozesse Container-Aktionen ausführen, die sich gegenseitig beeinflussen. Das System muss festgelegte, klare Interaktionen zwischen diesen Container-Aktionen aufweisen. Zum Beispiel schließen Container-Aktionen mit höherer Priorität alle Container-Aktionen mit niedrigerer Priorität (für das aktuelle Ereignis) aus. Die Prinzipien, die zum Definieren dieser Interaktionen benutzt werden, werden hier nicht weiter beschrieben; es wird vorausgesetzt, dass das System auf Grund eines Satzes von Container-Aktionen einen Unter-Satz von Container-Aktionen identifizieren kann, die zugelassen werden. Dieser Unter-Satz wird hiernach als aktuelle „Container-Aktionen" bezeichnet.
Damit das System die unterschiedlichen Container-Aktionen aus unterschiedlichen Prozessen koordinieren kann, sind vor der Verarbeitung eines Ereignisses zwei Stufen erforderlich.
Erstens werden angesichts eines Satzes von Prozessen, die ein Ereignis verarbeiten können, die Container-Aktionen gesammelt, so dass diese Prozesse ausgeführt werden, sobald sie das Ereignis verabeiten. Dies erfordert das Vorverarbeiten eines Ereignisses durch die beteiligten Prozesse: die resultierenden Zustandsübergänge werden bestimmt (da diese die Aktionen bestimmen, die ausgeführt werden), aber nicht ausgeführt.
Zweitens erzeugt das System basierend auf den gesammelten Container-Aktionen und der Priorität, die zwischen ihnen im System definiert ist, die aktuellen Container-Aktionen.
Wenn ein Ereignis von einem Satz von Prozessen verarbeitet werden soll, müssen ihre Container-Aktionen möglicherweise koordiniert werden, um zu vermeiden, dass die gleiche Aktion zweimal ausgeführt wird.
Wie oben beschrieben umfasst die erste Phase der Validierung das Auswählen der Prozesse, die an der Validierung beteiligt sein sollen, unter Benutzung von Kriterien, die auf den oben beschriebenen Eigenschaften basieren.
Obwohl es einen Prozess gibt, der das Ereignis anfangs über eine Assoziation empfängt, wird das Ereignis nicht sofort durch diesen Prozess verarbeitet. Auch wenn der Prozess des Empfangens immer als Ergebnis der Auswahlphase ausgewählt wird, kann der Prozess das Ereignis nur dann verarbeiten, wenn er ausgewählt worden ist.
Als Teil der Auswahlphase wird bestimmt, ob es einen aktuellen Container-Kontext gibt. Wenn es keinen aktuellen Container-Kontext gibt, wird nur der Prozess ausgewählt, der das Ereignis empfangen hat. Wenn es einen aktuellen Container-Kontext gibt, wird irgendein Prozess ausgewählt, der die beiden folgenden Kriterien erfüllt. Erstens muss der Prozess entweder den Container-Kontext halten, oder einen Prozess enthalten, der einen Container-Kontext hält, oder in einem Prozess beinhaltet sein, der einen Container-Kontext hält, der wiederum der Prozess ist, der das Ereignis empfangen hat, diesen enthält oder in ihm beinhaltet ist. Zweitens darf der Prozess keine Container-Aktionen außer den aktuellen Container-Aktionen ausführen.
Die Auswahlphase beginnt mit dem Überprüfen des Prozesses, der das Ereignis empfangen hat. Davon ausgehend wird der Prozess-Baum zur Wurzel und zu den Blättern gescannt. Für jeden gescannten Prozess wird überprüft, ob er sich mit dem Container-Kontext deckt. Jeder Deckungsprozess wird zur Auswahl hinzugefügt. Mehrere Optimierungen finden Anwendung. Erstens, wenn ein Deckungsprozess den Prozess enthält, der das Ereignis empfangen hat, gibt es keinen anderen Deckungsprozess. Dies ist darauf zurückzuführen, dass ein Container-Kontext einer FSM nicht zugeordnet werden kann, wenn diese FSM schon eine FSM enthält, der der Container-Kontext zugeordnet ist, oder darin beinhaltet ist. Zweitens, wenn ein Deckungsprozess gefunden worden ist, gibt es keinen anderen Deckungsprozess, der die gleiche FSM startet.
Dies ergibt mindestens einen Deckungsprozess, und für jeden gefundenen Deckungsprozess wird der Prozess-Baum erneut zur Wurzel und den Blättern gescannt. Jeder Deckungsprozess wird nun zur Auswahl hinzugefügt, vorausgesetzt, dass er nicht vorher ausgewählt worden ist.
Danach wird das Ereignis wie vorstehend beschrieben von allen ausgewählten Prozessen vorverarbeitet. Dies ergibt die aktuellen Container-Aktionen, die wiederum den endgültigen Satz von Prozessen in der Auswahl bestimmen.
Damit der Auswahlprozess richtig arbeiten kann, muss es aussehen, als ob der komplette Prozess-Baum verfügbar ist, bevor das erste Ereignis validiert wird. Dies bedeutet, dass ein Prozess für jede FSM im Prozess-Baum für jeden Container-Kontext vorhanden sein muss, der ihm zugeordnet ist (sogar wenn er sich möglicherweise im Zustand Ruhe befindet). Die Systemverwaltungszeit, die dies ergeben würde, ist für jedes System inakzeptabel. Das folgende Verfahren kann benutzt werden, um Prozesse auf Anfrage zu erzeugen: –
Wenn während des Auswahlprozesses das Ende des Baums erreicht wird (dieser Prozess wird nachstehend bezeichnet als: letzter Prozess), aber die FSM, die von dem letzten Prozess gestartet wird, nicht die Wurzel oder das Blatt des entsprechenden FSM-Baums ist, dann:

– Wird beim Scannen zur Wurzel ein Prozess für die FSM erzeugt, in dem die letzte FSM direkt beinhaltet ist, wenn diese FSM eine FSM ist, die einen Zustandsübergang von Ruhe für das aktuelle Ereignis spezifiziert hat, oder darin beinhaltet ist, mit einer Aktion, die nicht ,keine Aktion' ist.
– Werden beim Scannen zu den Blättern ein oder mehrere Prozesse für jede FSM erzeugt, die direkt in der letzten FSM beinhaltet ist und die eine FSM ist oder enthält, die einen Zustandsübergang von Ruhe für das aktuelle Ereignis spezifiziert hat, mit einer Aktion, die nicht ,keine Aktion' ist. Ein Prozess wird für die FSM erzeugt, wenn ihre Fx den aktuellen Container-Kontext als Mitglied aufweist, oder wenn ihre Fx leer ist. Anderenfalls wird ein Prozess für jedes Mitglied der FSM's Fx erzeugt. Dann wird eine Assoziation mit jedem Prozess erstellt, wonach das Verfolgen fortgesetzt wird.

Das System muss für jede FSM wissen, für welche Ereignisse es eine Aktion bestimmt, die nicht ,keine Aktion' ist, wenn sie im Zustand Ruhe empfangen wird.
Prozesse können entfernt werden und alle Assoziationen auf den Container-Schnittstellen können freigegeben werden, wenn es sich im Zustand Ruhe befindet und keine anderen Prozesse enthält. Es kann eine Situation entstehen, wo sich ein Prozess nicht im Zustand Ruhe befindet, aber keine Assoziationen mehr hat, das heißt, der Prozess hängt. Das System kann dies erkennen, weil der Prozess dann eine Wurzel und das einzige Blatt ist. Das System erzeugt in diesem Fall ein besonderes Ereignis, zum Beispiel ,verwaist', auf das der Prozess zu Ruhe gehen sollte (falls nicht, wird es als Fehler betrachtet).
Nachdem die Auswahlphase abgeschlossen und eine Gruppe von Prozessen ausgewählt worden ist, verarbeitet jeder ausgewählte Prozess das Ereignis unabhängig von den anderen ausgewählten Prozessen. Das Ereignis kann dann validiert werden.
Da Ereignisse auf unterschiedlichen Assoziationen ankommen und nachfolgende Ereignisse nicht verarbeitet werden können, bis ein vorheriges Ereignis verarbeitet worden ist, ist eine Warteschlangenbildung erforderlich. Ein Ereignis wird in die Warteschlange versetzt, wenn es schon Ereignisse gibt, die sich in der Warteschlange befinden, oder wenn es schon ein aktuelles Ereignis gibt. Ereignisse werden für den Wurzelprozess des Prozesses, der das Ereignis empfangen hat, in die Warteschlange versetzt. Unterschiedliche Warteschlangen können Anwendung finden, je nachdem, wie viele unterschiedliche Prioritäten es gibt. Ereignisse, die über Container-Schnittstellen empfangen werden, haben eine höhere Priorität als Ereignisse, die über andere Schnittstellentypen empfangen werden. Folglich müssen die Warteschlangen für diese Ereignisse leer sein, bevor ein Ereignis von einer anderen Warteschlange aufgenommen werden kann. Dies gibt allen beteiligten Prozessen die Möglichkeit, sich gegenseitig zu aktualisieren, bevor das nächste, zu validierende Ereignis empfangen wird.
Die Erfindung wird nun mit Bezug auf ihre Anwendung auf ein spezifisches Beispiel detaillierter beschrieben, das aus dem Ericsson CS1+ INAP-Protokoll für IN entnommen ist, das durch eine Anzahl FSMs beschrieben wird. Eine dieser FSM ist die SSF-FSM, die selbst aus einer Anzahl FSMs besteht, wie in 3 dargestellt.
Folglich enthält die Sitzungsansicht-FSM die Rufansicht-FSM, die wiederum die Cp- und Ap-FSMs enthält. Die Cp- und Ap-FSMs benutzen gemeinsam eine Schnittstelle, die aber keine Container-Schnittstelle ist.
Die Rufansicht-FSM weist externe Schnittstellen mit dem Ruf und der SCF (Service Control Function) auf. Auf diesen Schnittstellen können Ereignisse ankommen, die bezüglich SACF- und MACF-Regeln verifiziert werden müssen.
Die folgenden Container-Aktionen werden identifiziert (in Reihenfolge der Priorität vorgestellt):
EreignisZwischenspeichern. Das Ereignis wird zwischengespeichert (der Zwischenspeicher-Mechanismus selbst wird hier nicht beschrieben). Es folgen keine Fehlerprozeduren.
EreignisZurückweisen. Das Ereignis wird zurückgewiesen: es folgt eine Fehlerprozedur.
4 stellt die FSM für die Sitzungsansicht dar, die die MACF-Regeln für INAP bestimmt. Es gibt eine MACF-Regel: mehrere Assoziationen können für mehrere SCFs gleichzeitig existieren, aber nur eine kann den Ruf steuern.
Es gibt keine Befehle, die die Sitzungsansicht als Container-Kontext aufweisen. Da die Sitzungsansicht alle anderen FSMs beinhaltet, ist die Sitzungsansicht immer an der Validierung jedes Ereignisses beteiligt.
Eine neue Assoziation mit der SCF ist nur zugelassen, wenn sich die FSM für die Sitzungsansicht im Zustand Ruhe oder Überwachungsbeziehungen befindet. Wenn sich die FSM für die Sitzungsansicht im Zustand Steuerbeziehung befindet, wird der Befehl InitialDP (der eine neue Assoziation mit der SCF startet) zurückgewiesen. Der Befehl wird dann ignoriert.
5 stellt die FSM für den Prozess Rufansicht dar, der SACF-Regeln für die Assoziationen mit der SCF und den Ruf bestimmt, wie in einem einzelnen SCF-Prozess zu sehen ist.
Es gibt wenige Befehle, die die Rufansicht als Container-Kontext aufweisen, zum Beispiel Ruf Freigeben.
Die Zustände: SetUp, Schwebend und Aktiv entsprechen Zuständen in der BCSM. Während sich die SCF im SetUp befindet, kann sie unter Benutzung normaler CCF-Prozeduren (Befehl InformationSammeln) immer noch Ziffern von den Benutzer sammeln. Sobald sie sich in Schwebend befindet, ist dies nicht mehr möglich (InformationSammeln zurückgewiesen). Während sie sich in Aktiv befindet, kann die SCF den Ruf nicht weiterleiten (Verbinden zurückgewiesen). Der Ruf kann nur durch ein bestimmtes Ereignis von dem Ruf nach Schwebend zurückkehren.
Sobald sich die Partei, die den Ruf begonnen hat, in Ersatz befindet, hat sie den Ruf verlassen. Es ist dann für die SCF nicht mehr möglich, den Ruf zu leiten (das Ereignis aus dem Ruf, das die FSM dazu veranlasst hat, von Aktiv zu Schwebend überzugehen, veranlasst nun einen Zustandsübergang zu dem gleichen Zustand mit keiner Aktion). Sobald sich die SCF in Überwachungsbeziehung befindet, kann sie den Ruf nicht länger steuern, aber die Ereignisse überwachen, die im Ruf geschehen (alle Steuerbefehle werden zurückgewiesen). Es sollte beachtet werden, dass ein Ereignis, wenn es den Zustand Überwachungsbeziehung betritt, von dieser FSM erzeugt wird und zur Sitzungsansicht gesendet wird (um einen Zustandsübergang zu Überwachungsbeziehungen hervorzurufen).
6 stellt eine FSM für die Cp oder Ap dar. Die Cp und Ap weisen identische Zustände auf. In einer Rufansicht kann es nur eine Cp-Ansicht geben, aber es kann mehrere Ap-Ansichten geben. Die Cp oder Ap bestimmt SACF-Regeln für die Assoziation mit der SCF, und der Ruf für diejenigen Befehle, in denen die Cp oder Ap beteiligt ist.
Die FSM stellt die Synchronisierungsprozeduren zwischen der SSF und der SCF und die Prozeduren dar, um mit der Ruf-Partei zu interagieren (nicht die Benutzung von normalen CCF-Prozeduren).
Es gibt keine Befehle, die eine Cp oder Ap als Container-Kontext aufweisen. Welche der Ansichten beteiligt ist, wird von der FSM bestimmt, die in der Cp und Ap enthalten ist, der Leg.
Es gibt eine Schnittstelle zwischen der Cp und Ap, wie in 3 gezeigt, die benutzt wird, um Legs von einer Ansicht zur anderen zu bewegen (tatsächlich bedeutet dies, dass der beinhaltete Prozess für die Leg freigegeben wird und ein neuer auf der anderen Seite gestartet wird).
Im Zustand WFI in der FSM wird der Cp- oder Ap-Prozess mit der SCF synchronisiert, obwohl die Synchronisierung unterbrochen werden kann, wenn der Benutzer auflegt (Ereignis, das von einem CLSM-Prozess hereinkommt). Es sollte beachtet werden, dass unterschiedliche Ap-Prozesse folglich nicht zusammen und nicht mit dem Cp-Prozess synchronisiert werden: die Synchronisierung gilt nicht für den kompletten Ruf.
Während die Benutzerinteraktion weitergeht (die FSM befindet sich im Zustand Benutzerinteraktion WFI, oder Benutzerinteraktion Verarbeiten), werden alle Befehle von der Cp zwischengespeichert, außer VerbindungTrennenWeiterleiten. Der Zwischenspeicher wird freigegeben, wenn die FSM zurück zu WFI oder Verarbeiten übergeht. Die Ap speichert nur RufFreigeben zwischen, und dies wird nur lokal zwischengespeichert, das heißt, ohne andere FSMs zu betreffen. Folglich benutzt die Ap dafür keine Container-Aktion.
Wenn sich die FSM im Zustand Verarbeiten befindet, laufen die SSF und die SCF gleichzeitig, das heißt, sie sind nicht synchronisiert.
Die FSMs für die Legs in der Cp und Ap sind identisch, einschließlich aller Zustandsübergänge, Aktionen etc. Diese FSMs haben nur die Zustände Ruhe und Aktiv. Diese FSMs dienen als ein Container-Kontext für Befehle. Da die Legs in der Cp und Ap identisch sind und jede nur einen Zustand aufweist (neben Ruhe), kann ein Leg-Prozess von Ap zu Cp ,bewegt' werden und umgekehrt, durch Übergehen des exisitierenden Prozesses von Aktiv zu Ruhe, und Übergehen eines neuen Prozesses (in der Zielansicht) von Ruhe zu Aktiv.
Die Position des Leg bestimmt so, ob die Cp-Ansicht oder eine Ap-Ansicht beteiligt sein wird. Das Konzept „Legs" stellt Netzwerkressourcen dar, die einer einzigen Partei in einem Ruf zugeordnet sind. Es kann nur ein Leg in einer Ap geben, aber es kann mehrere Legs in der Cp geben.
Demzufolge ist es möglich, die Kriterien zu bestimmen, die beim Auswählen der Prozesse benutzt werden sollen, die ein Ereignis während der Validierung verarbeiten sollen.
Es sollte beachtet werden, dass das Konzept der Container-Schnittstellen im Allgemeinen benutzt werden kann, um das Verhalten eines Systems oder eines Teils eines Systems gegenüber Auslösern (das heißt, die aus anderen Systemen oder einem Teil des gleichen Systems kommen) zu beschreiben.

Claims

Ein Verfahren zur Validierung eines Ereignisses in einem eine Mehrzahl von Prozessen umfassenden intelligenten Netzwerk, wobei das Verfahren umfasst: Auswahl derjenigen Prozesse aus allen Prozessen, die vorherbestimmte Kriterien erfüllen; und unabhängige Verarbeitung des Ereignisses in allen ausgewählten Prozessen; dadurch gekennzeichnet, dass der Schritt des Auswählens das Definieren von Beziehungen zwischen diese Prozesse darstellenden FSMs (Finite State Machines), einschließlich des Definierens von Container-Schnittstellen zwischen den Prozessen, umfasst.
Ein Verfahren nach Anspruch 1, wobei die vorherbestimmten Kriterien Folgendes umfassen: Bestimmen, ob irgendwelche FSMs eine Container-Schnittstelle gemeinsam benutzen, und Bestimmen, ob irgendwelche Prozesse sich mit einem Container-Kontext des aktuellen Ereignisses decken.
Ein Verfahren nach Anspruch 1 oder 2, wobei das Ereignis in einem ersten Prozess empfangen wird, und das Verfahren die Verzögerung der Verarbeitung des Ereignisses im ersten Prozess bis zu dem Zeitpunkt umfasst, an dem der Schritt des Auswählens abgeschlossen ist.
Ein Verfahren nach Anspruch 1, 2 oder 3, wobei der Schritt des Auswählens dieser Prozesse, die die vorherbestimmten Kriterien erfüllen, Folgendes umfasst: Auswählen eines ersten Satzes von Prozessen, die den Satz von Kriterien erfüllen; Vorverarbeiten des Ereignisses im ersten Satz von Prozessen; und Auswählen eines zweiten Satzes von Prozessen aufgrund des Ergebnisses der Vorverarbeitung.
Ein Verfahren nach Anspruch 4, wobei der zweite Satz von Prozessen nur dann ausgewählt wird, wenn sie aktuelle Container-Aktionen beinhalten.
Ein Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt der Verarbeitung des Ereignisses das Zwischenspeichern eines empfangenen Ereignisses beinhaltet, bis ein früher empfangenes Ereignis verarbeitet wurde.