Verfahren zur Diensteerkennung in intelligenten Netzwerken
Technischer Hintergrund der Erfindung
-
Die vorliegende Erfindung betrifft ein Verfahren zur
Erkennung von Dienstwechselwirkungen in intelligenten Netzwerken.
Insbesondere betrifft die vorliegende Erfindung die
Spezifizierung der Dienste und ein Verfahren zur Erkennung von
Dienstwechselwirkungen, die auf Spezifikationen beruhen.
-
In modernen Telekommunikationsnetzwerken bieten Betreiber
immer mehr zusätzliche Dienste für Ihre Kunden an. Beispiele
hiervon sind Anrufererkennung (OCS = Originating Call
Screening), virtuelle private Netzwerke (VPN = Virtual Private
Network), Nachfolge-Anrufweiterschaltung (FOC = Follow On
Call) und Sprachenwahl (LGS = Language Selection). Mit der
ansteigenden Anzahl von Diensten steigt gleichfalls die
Wahrscheinlichkeit der Wechselwirkung zwischen diesen Diensten.
In den meisten Fällen sind diese Wechselwirkungen
unerwünscht, da sie unerwartet auftreten und Nebeneffekte
erzeugen können. Daher sollte das Auftreten von
Dienstwechselwirkungen erkannt und verhindert werden, vorzugsweise bei der
Erstellung dieser Dienste.
-
Verfahren des Standes der Technik zur Erkennung von
Dienstewechselwirkungen waren primär mit dem Vergleich der
wörtlichen Beschreibung der Dienste beschäftigt. Dieser bekannte
Weg weist Nachteile auf, die in Ungenauigkeiten liegen, da
wörtliche Beschreibungen häufig vage und doppeldeutig sind,
und diese Verfahren sind zeitintensiv, da vielfältige
Dienstleistungsspezifikationen von Hand zu vergleichen sind.
-
Druckschrift 1 ("A Practical Approach to Service
Interactions") schlägt vor, eine mehr strukturierte Herangehensweise
der Erkennung von Dienstwechselwirkungen, indem Bedingungen
eingesetzt werden, um Dienste zu spezifizieren und mögliche
Wechselwirkungen zu erkennen. Diese Druckschrift liefert
jedoch keine vollständige Erkennungsmethode, die von einem
Computer ausgeführt werden kann.
-
Die Druckschrift 8 ("A Verification Scheme for Service
Specifications Described by Information Sequence Charts") schlägt
ein Verfahren zur Erkennung von Dienstwechselwirkungen vor,
das von einem Computer ausgeführt werden kann. Dieses
bekannte Verfahren baut allerdings ausschliesslich auf
chronologischen Fehlern und findet nicht alle möglichen Fehler.
-
Die Druckschrift 9 ("Administrable feature interaction
concept") beschreibt den Einsatz von Auslösepunkten in der
Erkennung von Wechselwirkungen. Nur die Prioritätsabfolge von
zusätzlichen Diensten (oder "Merkmalen") wird eingesetzt, um
mögliche Wechselwirkungen zu erkennen.
-
Die Druckschrift 10 ("A design support method for
telecommunication service interactions") beschreibt ein Verfahren
entsprechend dem Obergriff des Anspruchs 1.
Zusammenfassung der Erfindung
-
Ein Ziel der vorliegenden Erfindung liegt darin, ein
Verfahren zur Erkennung von Dienstwechselwirkungen anzugeben,
welches zumindest teilweise in einem Computer ausgeführt werden
kann.
-
Ein weiteres Ziel der vorliegenden Erfindung liegt darin, ein
vollständiges und wirkungsvolles Verfahren zur Erkennung von
Dienstwechselwirkungen anzugeben.
-
Ein weiteres Ziel der vorliegenden Erfindung liegt darin, ein
Verfahren zur Spezifikation von Diensten anzugeben, welches
unzweideutige Beschreibungen von Diensten liefert, die die
automatische Verarbeitung von diesen Beschreibungen zur
Erkennung von Dienstwechselwirkungen gestattet.
-
Demgemäss ist ein Verfahren zur Erkennung von
Dienstwechselwirkungen in Netzwerken angegeben, wobei das Verfahren den
paarweisen Vergleich von Dienstemerkmalen während eines
Anrufes umfasst, wobei die Dienste als externe Zustände eines
grundlegenden Anrufsstatusmodelles ausgestaltet sind, wobei
die Merkmale die Bedingungen umfassen, die mit den
Dienstleistungen verknüpft sind, wobei die Bedingungen Vorher-
Bedingungen, die den Status des Modells vor der Ausführung
des Dienstes definieren, und Nachher-Bedingungen umfassen,
die den Status des Modells nach der Ausführung des Dienstes
definieren, dadurch gekennzeichnet, dass die Bedingungen
weiterhin globale Bedingungen, die eine Bedingung des Modells
während des gesamten Anrufes definieren, globale Vorher-
Bedingungen, die eine Bedingung für das Modell während des
Anrufes bis zur Ausführung des Dienstes definieren, und
globale Nachher-Bedingungen umfassen, die eine Bedingung des
Modells während des Anrufs nach der Ausführung des Dienstes
definieren.
-
Durch den Einsatz von formalen Spezifikationen, die die oben
beschriebenen Bedingungen einsetzen, kann eine exakte und
unzweideutige Erkennung von Wechselwirkungen von Diensten
bereitgestellt werden. Durch das Verifizieren von formal
benannten Bedingungen kann ein Verfahren geliefert werden,
wel
ches in einfacher Weise automatisiert werden kann und welches
hoch zuverlässige Ergebnisse liefert.
Druckschriften
-
[1] E. Kuisch et al.: "A Practical Approach to Service
Interactions", IEEE Communications Magazine, August 1993,
Seiten 24-31.
-
[2] "An axiomatic basis for computer programming", Comm
ACM 12 (Oktober 1969), 576-580, 583.
-
[3] ITU (CCITT) Recommendation Q.1211, "Introduction to
Intelligent Network for Capability Set 1".
-
[4] ITU (CCITT) Recommendation Q.1214, "Distributed
Functional Plane for Capability Set 1".
-
[5] ETSI draft ETR NA601-09, Service Life Cycle Reference
Model, (Juli 1993).
-
[6] Europäische Patentanmeldung 94200299.9.
-
[7] ITU Recommendation Q.1204.
-
[8] Okamoto et al.: "A Verification Scheme for Service
Specifications Described by Information Sequence Charts",
IEICE Transactions on Communications, Vol. E75-B,
Nr. 10, Seiten 978-985, Tokyo, Oktober 1992.
-
[9] Schessel: "Administrable feature interaction concept",
International Switching Symposium, Yokohama, 1992.
-
[10] Harada et al.: "A design support method for
telecommunication service interactions", GLOBECOM 91,
Session 46, Papier 3, Vol. 3, Phoenix, USA, Seiten 1661-
1666.
Kurze Beschreibung der Zeichnungen
-
Die Erfindung wird nun unter Bezugnahme auf die beigefügten
Zeichnungen beschrieben. Es zeigen:
-
Fig. 1 eine schematische Darstellung eines grundlegenden
Anrufzustandsmodelles, wie es im Verfahren der
vorliegenden Erfindung eingesetzt wird,
-
Fig. 2 eine schematische Darstellung von zusätzlichen
Diensten in Beziehung zum grundlegenden
Anrufzustandsmodell,
-
Fig. 3 eine schematische Darstellung der anwendbaren
Bereiche der Bedingungen für zusätzliche Dienste (ASP),
-
Fig. 4 eine schematische Darstellung für die Durchführung
eines Anrufs,
-
Fig. 5 eine schematische Darstellung möglicher
Wechselwirkungsfälle, und
-
Fig. 6 eine schematische Darstellung anwendbarer Bereiche
von Bedingungen für Paare von zusätzlichen Diensten
(ASPs).
Ausführliche Beschreibung der Erfindung
I. Anrufmodell
-
In dieser Druckschrift wird der Begriff "ASP" verstanden als
"Durchführung zusätzlicher Dienste" (Additional Service
Processing), d. h. die Bearbeitung oder Ausführung von einem
zusätzlichen Dienst zu dem grundlegenden Anrufzustandsmodell
(Basic Call State Model = BCSM). Insbesondere werden ASPs im
allgemeinen so verstanden, dass diese unabhängig voneinander
spezifiziert sind, d. h. es wird angenommen, dass die ASPs
nicht ausgelegt sind, zusammenzuwirken.
-
Das grundlegende Anrufzustandsmodell (BCSM), welches
vorzugsweise im Verfahren gemäss der vorliegenden Erfindung
eingesetzt wird, ist schematisch in der Fig. 1 dargestellt. Dieses
BCSM umfasst eine Anzahl von Schritten oder Stufen, die
jeweils Zuständen in einem Anruf entsprechen. Das BCSM nach
Fig. 1 umfasst die "Ausgehenden-BCSM" ("Originating BCSM")
und die "Eingehenden-BCSM" ("Terminating BCSM") der "ITU
Recommendation Q.1204" und umfasst damit den anrufenden und
angerufenen Fall.
-
Die jeweiligen Zustände (Erkennungspunkte) des vorliegenden
BCSM, wie er in der Fig. 1 dargestellt sind, sind:
-
1. Null (ursprünglicher oder Ruhezustand)
-
2. Anrufversuch-autorisiert (Originating-Attempt-Authorized)
-
3. Nehme-Information (Collect-Info)
-
4. Information-aufgenommen (Info-Collected)
-
5. Analysiere-Information (Analyze-Info)
-
6. Information-analysiert (Info-Analyzed)
-
7. Routen (Routing)
-
8. Routing-Auswahl-Versagen (Route-Select-Failure)
-
9. Anrufsversuch-autorisiert
(Terminating-Attempt-Authorized)
-
10. Verbindungsauswahl & Ruf (Select-Facilities & Present
Call)
-
11. Angerufener-Teilnehmer-Besetzt (T-Called-Party-Busy)
-
12. Anrufender-Teilnehmer-Besetzt (O-Called-Party-Busy)
-
13. Alarm (Alerting)
-
14. Angerufener-Teilnehmer-ohne-Antwort (T-No-Answer)
-
15. Anrufender-Teilnehmer-ohne-Antwort (O-No-Answer)
-
16. Angerufener-Teilnehmer-Antwort (T-Answer)
-
17. Anrufender-Teilnehmer-Antwort (O-Answer)
-
18. aktiv (Activ)
-
19. Anrufer-im-Gespräch (O-Mid-Call)
-
20. Angerufener-im-Gespräch (T-Mid-Call)
-
21. Anrufer-beendet (O-Disconnect)
-
22. Angerufener-beendet (T-Disconnect)
-
23. Anrufer-Ausnahme (O-Exception)
-
24. Beendigung (Abandon)
-
Es ist wohlverstanden, dass in der oben stehenden Liste das
Präfix "O" jeweils für "Originating" (ausgehender Anruf oder
Teilnehmer) steht, wohingegen "T" auf "Terminating"
(eingehender Anruf oder Teilnehmer) hinweist. Das BCSM nach
Fig. 1 hat den Vorteil, dass die den Erkennungspunkten
zuge
wiesenen Nummern als Zeitreferenzen geeignet sind, wobei
höhere Zahlen auf später liegende Zeitpunkte hinweisen. Dies
vereinfacht die computerisierte Verarbeitung. Für weitere
Details der BCSM wird auf Druckschrift [7] hingewiesen.
-
Im Verfahren gemäss der vorliegenden Erfindung ist der
Einfluss von Diensten, wie der des intelligenten Netzwerkes (IN
= Intelligent Network), auf dem grundlegenden
Anrufzustandsmodell (BCSM) beschrieben durch die (z. B. graphische)
Erweiterung des BCSM mit externen Zuständen, die zusätzliche
Dienstverarbeitungszustände (ASP) genannt werden. Dies
bedeutet, dass diese Dienste als zusätzliche Zustände des BCSM
aufgefasst werden.
II. Spezifikation der Dienste
-
Gemäss der vorliegenden Erfindung werden Dienste formal
beschrieben durch das Mittel von Bedingungen, die z. B. in
Vorher-Bedingungen und Nachher-Bedingungen verwirklicht sind.
Vorher-Bedingungen und Nachher-Bedingungen beschreiben eine
Funktion (d. h. ein ASP) eines Systems (d. h. ein intelligentes
Netzwerk) in den Begriffen von Systemzuständen. Vorher-
Bedingungen und Nachher-Bedingungen beschreiben, was die
Funktion bewirkt durch die Definition von Zuständen vor und
nach der Ausführung der Funktion, anstelle der Beschreibung,
wie die bestimmte Funktion ausgeführt wird.
-
Ein Servicemodell mit Vorher- und Nachher-Bedingungen ist in
der Fig. 2 dargestellt. Drei ASPs (ASP1, ASP2 und ASP3)
wechselwirken mit dem BCSM und die Wechselwirkungen sind durch
die Pfeile zwischen dem BCSM und den ASPs dargestellt. Diese
Pfeile, wie sie in der Fig. 2 genutzt werden, zeigen
schematisch die Zeitpunkte (Erkennungspunkte), wenn die Ausführung
des BCSM unterbrochen wird, um ein ASP auszuführen, d. h. wenn
das BCSM verlassen wird und wenn wieder zu ihm zurückgekehrt
wird (siehe auch Fig. 1).
-
Vor und nach der Ausführung jedes ASPs sind gewisse Vorher-
Bedingungen und Nachher-Bedingungen erfüllt. Zum Beispiel
wird die Vorher-Bedingung Pre1 in dem BCSM vor der Ausführung
des ASP1 erfüllt. Nach der Ausführung des ASP1 wird die
Nachher-Bedingung Post1 erfüllt. Damit wird das Verhalten von
ASP1, zumindest teilweise, durch die Bedingungen Pre1 und
Post1 definiert. In gleicher Weise sind die Bedingungen Pre2
und Post2 mit dem ASP2 verbunden und die Bedingungen Pre3 und
Post3 sind mit ASP3 verbunden.
-
Zusätzlich zu den Vorher-Bedingungen und den
Nachher-Bedingungen werden die folgenden Bedingungen identifiziert:
-
- globale Bedingungen (Eigenbedingungen), die während des
gesamten Anrufs erfüllt werden,
-
- globale Vorher-Bedingungen, die erfüllt werden, bis ein
ASP ausgeführt wird,
-
- globale Nachher-Bedingungen, die erfüllt werden,
nachdem ein ASP ausgeführt worden ist, bis zur Beendigung
des Anrufes.
-
Die Zeitrelationen der verschiedenen Bedingungen sind in der
Fig. 3 dargestellt. Globale Bedingungen halten vor, während
und nach der Ausführung des betreffenden ASP. Es ist klar
ersichtlich, dass für ein bestimmtes ASP nur diejenigen
globalen Bedingungen in Betracht zu ziehen sind, welche diesen ASP
beeinflussen oder die von dem betreffenden ASP beeinflusst
werden können. Globale Vorher-Bedingungen (mit "PreGlobal" in
Fig. 3 bezeichnet) gelten bis zur Ausführung des ASP, globale
Nachher-Bedingungen (in der Fig. 3 mit "PostGlobal"
bezeichnet) gelten nach der Ausführung des ASP. Vorher-Bedingungen
und Nachher-Bedingungen ("Pre" und "Post" in Fig. 3) gelten
zu Beginn und zum Ende der Ausführung des jeweiligen ASP,
wobei eine Vorher-Bedingung eine Notwendigkeit zur Ausführung
des ASP ist und eine Nachher-Bedingung nach der Ausführung
des ASP etabliert wird. (Es ist zum Zwecke der Klarheit
darauf hinzuweisen, dass in der Fig. 3 der Austritt (Exit) und
die Rückkehr (Return) nicht durch Pfeile wie in der Fig. 2
bezeichnet sind).
-
Das Verhalten eines ASP kann in bezug auf die vorliegende
Erfindung wie folgt ausgedrückt werden:
-
{globale Bedingung}
-
{globale Vorher-Bedingung ASP}
-
{Vorher-Bedingung ASP}
-
ASP
-
{Nachher-Bedingung ASP}
-
{globale Nachher-Bedingung ASP}
-
In Zusatz zu den Bedingungen können verschiedene Datentypen
des ASP identifiziert werden als: BCSM-Daten, BCSM-
Statusinformationen, Servicedaten und
Teilnehmerwechselwirkungsdaten. BCSM-Daten werden vom BCSM eingesetzt, d. h. die
Nummer des Anrufers (CallingPartyNumber) und die Nummer des
Angerufenen (CalledPartyNumber). BCSM-Daten werden zwischen
dem BCSM und den ASPs ausgetauscht. Die BCSM-
Statusinformation bezieht sich auf die Zustände des BCSM.
Diese Information wird zwischen dem BCSM und einem ASP zu
Beginn und zum Ende der Ausführung des ASP ausgetauscht.
Dienstedaten sind spezifische Daten für einen bestimmten Dienst,
z. B. eine persönliche Nummer. Dienstedaten werden nicht
zwischen dem BCSM und den ASPs ausgetauscht.
Teilnehmerwechselwirkungsdaten beziehen sich auf die Mitteilung des Dienstes
an die Endteilnehmer. Sie umfassen Mitteilungen an die
Teilnehmer und aufgenommene Informationen (CollectedInfo) von den
Teilnehmern. Teilnehmerwechselwirkungsdaten werden zwischen
dem BCSM und des ASPs ausgetauscht. Die oben genannten
Datentypen bilden zusammen die Datenumgebung eines Dienstes.
-
Ein Attribut wird durch die gemeinsamen Daten für alle
betroffenen Prozesse gebildet. Im folgenden Fall weist ein
Attribut aus Daten aus, die sowohl dem BCSM als auch einem AST
bekannt sind, und es wird eingesetzt, um das Verhalten des
jeweils anderen zu beeinflussen. Die hauptsächliche Bedeutung
von Attributen liegt in der unzweideutigen Zuweisung von
Namen zu unterschiedlichen (Typen von) Daten. Attribute können
entweder BCSM-Daten (z. B. CallingPartyNumber,
CalledPartyNumber), BCSM-Statusinformationen (z. B. Exit, Return,
ReturnState, EDP-Set) oder Teilnehmerwechselwirkungsdaten (z. B.
Mitteilungen (Announcements), Collectedlnfo) sein.
III. Erkennungsverfahren
-
Das Erkennungsverfahren gemäss der vorliegenden Erfindung
umfasst den paarweisen Vergleich von Merkmalen zur
Spezifikationszeit. ASPs, die entsprechend dem oben stehenden
spezifiziert sind, können in einfacher Weise verglichen und auf
Wechselwirkungen überprüft werden. Es ist anzunehmen, dass
die ASPs verknüpft sind, d. h. die ASPs besitzen jeweils nur
einen Rücklauf. Weiterhin wird angenommen, dass für jedes
Paar von zu prüfenden ASPs der erste ASP (ASP1) beginnt
(exit1) und aussteigt (exit), bevor der zweite ASP (ASP2)
beginnt (exit2). Mit anderen Worten, verlässt ASP1 den BCSM zu
einem früheren Zeitpunkt als ASP2. Dies wird symbolisch
geschrieben als exit1 < exit2, wobei das Zeichen "< " bedeutet
"früher in der Zeit". Im Falle, dass ASP2 vor ASP1 endet
(exit1 > exit2, wobei das Zeichen "> " bedeutet "später in der
Zeit"), und dass in dem BCSM nach Fig. 1 ebenfalls bedeutet,
dass ein höher liegender Erkennungspunkt und zugeordnete
Referenznummer vorliegt. Die ASPs sollten ausgetauscht werden,
um die oben stehende Annahme zu erfüllen. Im Falle, dass die
ASPs zur selben Zeit beginnen (exit1 = exit2, wobei das
Zeichen "=" bedeutet "zum selben Zeitpunkt"), sollte das
Erkennungsverfahren zweimal angewandt werden, wobei die ASP1 und
ASP2 nach dem ersten Lauf gewechselt werden.
-
In der Fig. 5 sind Enden und Ausgänge schematische
dargestellt, wobei Ausgänge als Pfeile, die vom BCSM zu den ASPs
zeigen und rückkehrend durch Pfeile dargestellt werden, die
von den ASPs zum BCSM zeigen. Die Bezugszeichen 1, 2, 3 und 4
beziehen jeweils vier konsekutive (Erkennungs)Punkte im BCSM.
Es sollte festgehalten werden, dass die Grösse der besagten
Referenzzahlen keinen Einfluss auf die Erkennungspunkte in
Fig. 1 haben.
-
In der Fig. 5a geht ASP1 (1) heraus (exit1) und kehrt zurück
(2) (return1), bevor ASP2 herausgeht (3) (exit2): exit1 <
exit2 und return1 < exit2. In der Fig. 5b ist exit1 < exit2,
aber return1 > exit2: return1 ist mit dem Punkt 3 verbunden,
während exit2 mit dem Punkt 2 verbunden ist. In der Fig. 5c
ist exit1 = exit2 (Punkt 1). Im Falle der Fig. 5c kann eine
Wechselwirkung zwischen den zwei ASPs erwartet werden.
-
Es ist festzuhalten, dass der Begriff C-BCSM (Centralised
BCSM, zentralisiertes BCSM) in Fig. 5 sich auf das BCSM nach
Fig. 1 bezieht, d. h. das zentralisierte Anrufmodell, bei dem
O-BCSM und T-BCSM kombiniert sind (siehe auch Druckschrift
[4]).
-
Wie oben angesprochen weist das Verfahren gemäss der
vorliegenden Erfindung die Vorabschritte auf (i) Unterteilen der
ASPs in verknüpfte Teile und (ii) Vergleichen der Austritts-
(exit) und Rückkehr- (return) Information von Paaren von
ASPs, wobei der ASP mit ASP1 bezeichnet wird, der den
frühesten Austrittszeitpunkt aufweist (den kleinsten
Austrittsstatus, d. h. den Erfassungspunkt mit der kleinsten Nummer in dem
BCSM nach Fig. 1) und wobei der andere mit ASP2 bezeichnet
wird. Nachfolgend können die folgenden Schritte durchgeführt
werden, um das Wechselwirkungspotential der ASPs festzulegen:
-
1. Falls return1 > exit2 gehe zu Schritt 5.
-
2. Falls ASP1 eine bestehende Steuerbedingung
aufrechterhält, gehe zu Schritt 5.
-
3. Falls (return2 > exit1) oder (exit1 = exit2 und
return2 > exit2):
-
Verifiziere {Pre1} CallProcessing(exit1, exit2) {Pre2} und
Verifiziere {Post1 und PostGlobal1 und Global1}
CallProcessing (return2, exit1) {Pre2}
-
3.1. Falls eine der Aussagen wahr ist und die andere
falsch ist, dann gebe aus "Wechselwirkung auf Grund eines
Steuerkonfliktes" (ASP1 beeinflusst die Steuerung von ASP2).
Gehe zu Schritt 6.
-
3.2. Falls beide Aussagen wahr sind:
-
Verifiziere {PreGlobal2 und Global1 und Pre1} ASP1
{PreGlobal2 und Global2 und Post1} und
-
Verifiziere {PostGlobal1 und Global1 und Pre2} ASP2
{PostGlobal1 und Global1 und Post2}.
-
3.2.1. Falls (nur) eine der beiden Aussagen falsch ist,
dann gebe aus "Wechselwirkung".
-
3.2.2. Gehe zu Schritt 6.
-
4. Falls (return2 ≤ exit1) und (exit1 ≠ exit2 oder
return2 < exit2):
-
Verifiziere {Post2 und Global2 und PostGlobal2 und
PreGlobal2} CallProcessing(return2, exit1) {Pre1}
-
4.1 Falls unwahr und wiederholte Ausführung von ASP1
gewünscht ist, dann gebe aus "Wechselwirkung" (ASP1 sollte
ausgeführt werden, wird es aber nicht).
-
4.2 Falls wahr und wiederholte Ausführung von ASP1
nicht gewünscht ist, dann gebe aus "Wechselwirkung" (wegen
unerwünschter Wiederholung).
-
4.3 Gehe zu Schritt 6.
-
5. Verifiziere: {Pre1} CallProcessing(exit1, exit2)
{Pre2}
-
Falls wahr: "Wechselwirkung" (auf Grund eines
Steuerkonfliktes).
-
6. Falls die ASPs bei einem Anruf auftreten können, an
dem drei Teilnehmer involviert sind, dann
-
6.1 Falls beide ASPs bei angerufenen Teilnehmern
(terminating parties) wirken, dann verifiziere:
-
{PostGlobal1 und Global1 und Pre2} ASP2 {PostGlobal1 und
Globall und Post2} und
-
{PreGlobal2 und Global2 und Pre1} ASP1 {PreGlobal2 und
Global2 und Post1}
-
6.2 Falls unwahr, dann "Wechselwirkung" (weil ein
Konflikt der Bedingungen besteht).
-
7. Falls die ASPs in unabhängigen Sessionen auftreten, dann
verifiziere:
-
{PostGlobal1 und Global1 und Pre2} ASP2 {PostGlobal1 und
Globall und Post2}
-
{PreGlobal2 und Global2 und Pre1} ASP1 {PreGlobal2 und
Global2 und Post1} und
-
{PostGlobal2 und Global2 und Pre1} ASP1 {PostGlobal2 und
Global2 und Post1}
-
{PreGlobal1 und Global1 und Pre2) ASP2 {PreGlobal1 und
Global1 und Post2}
-
7.1 Falls unwahr, dann "Wechselwirkung" (weil ein Konflikt
der Bedingungen besteht).
-
Falls andere verknüpfte ASP-Kombinationen zu betrachten sind,
gehe zu Schritt 1 zurück.
-
Die oben erwähnten Steuerverknüpfungen können durch das
Mittel der BCSM Status Informationen im EDP-Set (umfassend
DetectionPointNumber und RelationshipID) identifiziert werden.
-
Mit dem oben beschriebenen Verfahren können Wechselwirkungen
in einfacher Weise erfasst werden, entweder per Hand oder mit
Computer-Unterstützung, und es kann ein Netzwerk realisiert
werden, welches frei von Wechselwirkungen ist.
-
Die Verifizierungsregeln des Verfahrens gemäss der
vorliegenden Erfindung haben das Format {P} S {Q}, wobei P und Q
Bedingungen sind und S ein Verfahren ist (ASP). In einer
Verifizierungsregel gilt:
-
- Falls P nicht hält: schliesse UNWAHR (FALSE).
-
- Falls P hält und {P} S {Q} hält: schliesse WAHR (TRUE).
-
- Falls P hält und {P} S {Q} nicht hält: schliesse UNWAHR
(FALSE).
-
Das Verfahren S kann auch durch die Bezeichnung
CallProcessing(x, y) entsprechend Fig. 4 bezeichnet werden, wobei
darunter der Übergang eines Zustandes x zu einem Zustand y in dem
BCSM verstanden wird. Der Status x kann beispielsweise exit1
sein, wohingegen der Status y exit2 sein kann.
-
Wie bereits oben beschrieben, wendet das Verfahren gemäss der
Erfindung logische Verifizierungsregeln auf formale
Spezifikationsregeln an, um mögliche Wechselwirkungsfälle zu
erfassen und zu entdecken.
IV. Beispiele
-
In den Beispielen bedeutet das Zeichen "logisches UND",
wohingegen das Zeichen "logisches ODER" bedeutet. Das Zeichen
bedeuten "logisches NICHT". Das Zeichen bedeutet
Verkettung. Um anzuzeigen, dass einige Daten existieren und nicht
spezifische Werte haben ("egal"), wird die Bezeichnung
[dataname0] benutzt, z. B. CalledPartyNumber0 (hier werden die
umfassenden Zeichen < und> eingesetzt, um ein Datenbeispiel
zu spezifizieren). Um festzuhalten, dass einige Daten nicht
verfügbar sind (und keinen Wert haben), wird der "Wert" NILL
benutzt.
-
Die Funktion "Prüfe" ("Screen") beschreibt eine logische
Aussage, d. h. prüft auf Auftreten. Screen< Value-list> ,
< Column-list> , < Table-name> ) liefert das boolesche Ergebnis
der Frage, ob in den Spalten < Column-list> der Tabelle
<
Table-name> die Werte < Value-list> verfügbar sind.
Kommentare in den Beispielen sind zwischen /* und */
eingeschlossen.
Beispiel 1
-
Das folgende Beispiel wird die Anwendung des Verfahrens zur
Ableitung von Vorher-(Pre-) und Nachher-(Post-)Bedingungen
von einer Textbeschreibung in zehn Schritten aus aufzeigen.
Das Beispiel wird den Originating Call Screening Service
(OCS) einsetzen:
-
"Ausgehende Anrufe können von dem Originating Call Screening
gesteuert werden. Dies gestattet es dem Teilnehmer,
festzuhalten, dass ausgehende Anrufe entweder eingeschränkt
verfügbar oder allgemein gestattet sind. Dies wird entsprechend
einer Liste festgehalten (screening list) und optional durch
die Tageszeitkontrolle. Dies kann jeweils auf Anrufbasis
(per-call basis) durch jeden aufgehoben werden, der den
richtigen Identifizierungskode aufweist." [3]
-
Der hier eingesetzte OCS-Service enthält eine Nummernliste
von nicht erlaubten Nummern; daneben wird hier aus Gründen
der Vereinfachung auf die Umgehung der Prüfung mit Hilfe von
Identifizierungskodes nicht eingegangen.
-
Entsprechend dem Verfahren der vorliegenden Erfindung werden
die folgenden Schritte vollführt:
-
Schritt 1 erfordert die Identifizierung einer
Datenbankstruktur für das OCS; da für das OCS angenommen wird, dass es
aktiv ist. Wir abstrahieren von den Daten, die eingesetzt
werden, um den OCS-Aktivierungszustand aufzuzeigen. Die folgende
Struktur wird eingesetzt werden:
-
OCS-Tabelle: CallingParty & CalledParty, mit Schlüssel
(CallingParty, CalledParty), wobei die Datentypen von
Calling
Party und CalledParty jeweils CallingPartyNumber und
CalledPartyNumber sind.
-
Die Interpretation dieser Tabelle ist: das Auftreten von
(CallingParty, CalledParty) in der OCS-Tabelle bedeutet, dass
ein Anruf von der CallingParty (Ausgangsseite (originating
side)) zu der CalledParty (angerufene Seite (terminating
side)) nicht gestattet ist. Auf Grund dieser Interpretation
sollten beide Spalten in solch einer Tabelle markiert werden:
die Spalte CallingParty ist dem Attribut CallingPartyNumber
und die CalledParty der CalledPartyNumber zugewiesen.
-
Es sollte festgehalten werden, dass die BCSM-Daten
Calling-PartyNumber, die den Standort der anrufenden Partei angibt,
und die CalledPartyNumber, die die gewählten Zahlen oder den
Ort des angerufenen Teilnehmers umfasst, Daten des Typs sind:
Liste von E.164 Typdaten (siehe auch internationalen
Datenstandard E.164).
-
In Schritt 2 (der eine globale Bedingung in Worten des Ziels
des Dienstes definiert), ist der Ausdruck des Zieles: Wenn
ein Anruf aktiv ist, dann werden die CallingPartyNumber und
die CalledPartyNumber nicht in Reihe in der OCS-Tabelle
auftreten. Es werden Attribute eingesetzt (unter Einsatz des
BCSM-Statuszustandes, um den Zustande des BCSM offenzulegen):
(BCSM-Status = Activ
Screen((Last(CallingPartyNumber),Last(CalledPartyNumber)), (CallingParty, CalledParty), OCS-
Tabelle) = WAHR)
-
Schritt 3 (durchgehen der Erfassungspunkte in dem BCSM und
identifizieren der durchzuführenden Handlungen) führt zu der
Schlussfolgerung, dass Info-Analysed der geeignete
Detektionspunkt ist (6 in Fig. 1), um den einzigen OCS-ASP zu
starten. Das Durchlaufen der ASPs für den OCS ist auf einen ASP
reduziert.
-
Schritt 4 (Bestimmen einer Auslösebedingung für das ASP und
Einsatz von dieser als ersten Teil eine Vorher-Bedingung)
führt zu folgender Vorher-Bedingung:
-
{/* Auslösekriterium */ Exit = 6 /* andere Attribute */
CallingPartyNumber = CallingPartyNumber0 CalledPartyNumber
= CalledPartyNumber0 EDP-Set = EDP-Set0 Announcements =
Announcements0 Collectedlnfo = Collectedlnfo0},
-
wobei EDP-Set der Satz der betroffenen
(Austritts-)Erfassungspunkte ist.
-
In Schritt 5 (der den ASP allgemein charakterisiert) wird der
Zweck des ASP festgestellt: stelle fest, ob ein Anruf erlaubt
ist oder nicht. Die folgenden Fälle können identifiziert
werden. Für das OCS sind solche Fälle möglichen Wegen
zugewiesen, nachdem die Betrachtung durchgeführt worden ist; drei
Fälle sind möglich:
-
- das Paar (Last(CallingPartyNumber0), Last(CalledParty-
Number0)) wird nicht in der OCS-Tabelle gefunden; dies
bedeutet, dass der Anruf erlaubt ist;
-
- das Paar (Last(CallingPartyNumber0), Last(CalledParty-
Number0)) wird in der OCS-Tabelle gefunden; dies bedeutet,
dass der Anruf nicht erlaubt ist;
-
- etwas ging während der Ausführung des ASP schief.
-
Schritt 6 (Durchgehen aller Attribute und Feststellen, ob
diese in dem ASP benutzt werden) führt zu den folgenden
Attributen:
-
- CallingPartyNumber und CalledPartyNumber (in Schritt 1
erwähnt)
-
- Announcements (Mitteilungen) (auf Grund der
Notwendigkeit der Information eines Teilnehmers, falls ein Fehler
aufgetreten ist, oder wenn der Anruf nicht durchgeführt worden
ist)
-
- Austritt (Exit) und Rückkehr (Return) (werden benutzt,
um den Beginn bzw. das Ende des ASP anzuzeigen)
-
Schritt 7 (für jedes Attribut aus Schritt 6 und benutzt als
Eingangswert, bestimme seinen Einsatz je Fall nach Schritt 5
in Operationen in der Datenbankstruktur): es ist möglich,
diese Fälle (Schritt 5) im folgenden Format niederzulegen, im
Falle einer Post-Bedingung
-
{(/* der Anruf ist erlaubt */
Screen((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = UNWAHR) ....)
(/* der Anruf ist nicht erlaubt */
Screen((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = WAHR) ....)
(/* es ist ein Fehler aufgetreten */ SLE-Error ....)}
-
Es ist festzustellen, dass SLE-Error eine Variable ist, die
ausdrückt, dass irgendein Fehler während der Ausführung der
Dienstelogik aufgetreten ist (z. B. Operationen in nicht
existierenden Datenbanken) auf Grund derer der Anruf abgebrochen
worden ist.
-
In Schritt 8 (stelle je Fall, wie in Schritt 5, den Wert
jedes Attributes fest, welches als Ausgangswert in den
Begriffen der Datenbankstruktur nach Schritt 1 und in den
Operationen nach Schritt 7 eingesetzt wird, und schreibe diese
Operationen in einer Nachherbedingung getrennt durch logische ODER
auf) wobei die Nachherbedingung ausgeweitet wird: im Falle,
in dem der Anruf erlaubt ist, wird nichts geändert ausser der
Rückkehr (Return); im Falle, in dem der Anruf nicht erlaubt
ist, und im Falle, in dem ein Fehler aufgetreten ist, wird
die CallingPartyNumber auf NILL gesetzt und die Meldung
(Announcement) wird verändert. Dies ergibt:
-
{(/* der Anruf ist erlaubt */
Screen((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = UNWAHR) Return
= 6 ....)
(/* der Anruf ist nicht erlaubt */
Screen((Last(CallingPartyNumber0), Last(CalledPartyNumber0),)
(CallingParty, CalledParty), OCS-Tabelle) = UNWAHR) Return =
1 CalledPartyNumber = CalledPartyNumber0 NILL
Announcements = Announcements0 "es ist nicht erlaubt, diese
Nummer anzurufen" ....)
(/* es ist ein Fehler aufgetreten */
SLE-Error Return = 1 CalledPartyNumber =
CalledPartyNumber0 NILL Announcements = Announcements0 "Es ist ein
Fehler aufgetreten" ....)
-
Schritt 9 (prüfe, ob alle in den Vorher-Bedingungen genannten
Attribute in mindestens einer der Fälle der Nachher-Bedingung
auftreten und entferne nicht auftretende Ausdrücke) führt zur
Entfernung des EDP-Set und der Collectedlnfo von der Vorher-
Bedingung
-
{1* Auslösekriterium */ Exit = 6
/* andere Attribute */ CallingPartyNumber =
CallingPartyNumber0 CalledPartyNumber = CalledPartyNumber0 Announcements
= Announcements0}
-
Schritt 10 (prüft, ob jedes Attribut, welches in der Vorher-
Bedingung erwähnt worden ist, in jeder Nachher-Bedingung
auftritt, und fügt, falls nicht, einen Ausdruck hinzu, wo das
Attribut fehlt, um den ursprünglichen Wert oder NILL [leerer
Wert] dem Attribut zuzuweisen) führt zu folgender Nachher-
Bedingung:
-
{(/* der Anruf ist erlaubt */
Screen((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = UNWAHR) Return
= 6 Announcements = Announcements0 CallingPartyNumber =
CallingPartyNumber0 CalledPartyNumber = CalledPartyNumber0)
(/* der Anruf ist nicht erlaubt */
Screen((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = WAHR) Return =
1 CalledPartyNumber = CalledPartyNumber0 NILL
Calling-PartyNumber = CallingPartyNumber0 Announcements =
Arinouncements0 "es ist nicht erlaubt, diese Nummer anzurufen")
(/* ein Fehler ist aufgetreten */
SLE-Error Return = 1 CalledPartyNumber =
CalledPartyNumber0 NILL CallingPartyNumber = CallingPartyNumber0
Announcements = Announcements0 "Ein Fehler ist aufgetreten")}
-
In Schritt 11 (prüfe, ob ein Anteil der Nachher-Bedingung
während mehrerer Zustände des BCSM erfüllt sein sollte, und
lege sie als globale Nachher-Bedingung fest und prüfe, ob ein
Anteil der Vorher-Bedingung während mehrerer Zustände des
BCSM erfüllt sein sollte, und lege sie als globale Vorher-
Bedingung fest) wird festgestellt, dass die
CalledPartyNumber, falle es eine normale Telefonnummer (ordinary telephone
number) ist, nach dieser Prüfung nicht gewechselt werden
darf. Daher sollten die Ausdrücke, die der CalledPartyNumber
einen Wert zuweisen, als globale Bedingungen angesehen
werden.
-
Dies legt die Ableitung der Vorher- und Nachher-Bedingungen
für das OCS fest:
-
{/* Auslösekriterium */ Exit = 6 /* andere Attribute */
CallingPartyNumber = CallingPartyNumber0 CalledPartyNumber
= CalledPartyNumber0 Announcements = Announcements0}
-
OCS
-
{(/* der Anruf ist erlaubt */ Screen
((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = UNWAHR) Return
= 6 Announcements = Announcements0 CallingPartyNumber =
CalledPartyNumber0 CalledPartyNumber = CalledPartyNumber0)
(/* der Anruf ist nicht erlaubt */ Screen
((Last(CallingPartyNumber0), Last(CalledPartyNumber0)),
(CallingParty, CalledParty), OCS-Tabelle) = WAHR) Return =
1 CalledPartyNumber = CalledPartyNumber0 NILL
Calling-PartyNumber = CallingPartyNumber0 Announcements =
Announcements0 "Es ist nicht erlaubt, diese Nummer anzurufen")
(/* Ein Fehler ist aufgetreten */
SLE-Error Return = 1 CalledPartyNumber =
CalledPartyNumber0 NILL CallingPartyNumber = CallingPartyNumber0
Announcements = Announcements0 "Ein Fehler ist
aufgetreten")}
-
{/* globale Nachher-Bedingung */
(Class(CalledPartyNumber) -= OrdinaryTelephoneNumber CalledPartyNumber ≠
CalledPartyNumber0 CalledPartyNumber ≠ (CalledPartyNumber0
NILL))}
-
Unter Berücksichtigung der globalen Bedingung und dem
Ergebnis der Prüfung auf Grund des OCS ASP, kann in einfacher
Weise festgestellt werden, dass die globale Bedingung, die in
Schritt 2 genannt worden ist, durch die oben angegebene
globale Nachher-Bedingung wiedergegeben wird, wenn das BCSM
aktiv ist.
Beispiel 2
-
In diesem Beispiel wird eine einfache Spezifikation für
ausgehende Anrufüberwachung (Outgoing Call Screening) oder kurz
OCS benutzt, die eine sogenannte "Negativliste" ("black
list") von nicht zugänglichen Nummern einsetzt, und es wird
ein abgekürztes Wählverfahren (Abbreviated Dialling) oder ABD
eingesetzt werden. CPN (und cpn) wird als Abkürzung für
Nummer des angerufenen Teilnehmers verwendet werden (aus called
party number).
-
OCS-T: OCSList
-
{exit = 4 cpn = CPN1}
-
OCS
-
{(Screen(cpn, OCS-T) = UNWAHR cpn = CPN1 return = 4)
(Screen(cpn, OCS-T) = WAHR cpn = CPN1 return = 1)}
-
{PostGlobal: cpn = CPN1}
-
Die Bedingungen setzen die Spezifikationsvariable (mit dem
konstanten, aber unbekannten, Wert) CPN1 ein. So sagt die
globale Nachherbedingung, die von jedem anderen ASP
aufrechterhalten werden muss, aus, dass die Nummer des angerufenen
Teilnehmers nicht verändert werden kann.
-
In diesem Beispiel wird der folgende Fall eingesetzt werden:
Post: ((Screen (cpn, OCS-T) = UNWAHR cpn = CPN1 return =
4)
-
ABD-T: ABDNr & TransNr
-
{exit = 4 (Collected-Info) cpn = CPN0}
-
ABD
-
{return = 4 (Collected-Info) cpn = translate(CPN0, ABDNr,
ABD-T) }
-
Wenn das Profil betrachtet wird, kann festgestellt werden,
dass für die Erfassung zwei Fälle (weil exit-OCS = exit-ABD)
betrachtet werden müssen: [ABD; OCS] und [OCS; ABD]. im
Rahmen dieses Beispiels wird nur [OCS; ABD] untersucht.
-
Die zuerst zu überprüfende Regel ist:
-
{Post1} CallProcessing(return2, exit1) {Pre2},
-
was in dem Beispiel aussieht wie:
-
{(Screen(cpn, OCS-T) = UNWAHR cpn = CPN1)}
-
CallProcessing(4, 4)
-
{cpn = CPN0}
-
Dies ist nur wahr, wenn CPN1 = CPN0, aber da CPN1 und CPN0
Spezifikationsvariablen sind, wird CPN0 = CPN1 gelten.
Der Fall CPN0 = CPN1 erfordert von uns, die Regeln mit den
globalen Bedingungen zu verifizieren; in diesem Falle sieht
eine von diesen (die zweite) aus:
-
{cpn = CPN1 und cpn = CPN0}
-
ABD
-
{cpn = CPN1 und cpn = translate(CPN0, ABDNr, ABD-T)}
-
Da CPN0 = CPN1 und translate(CPN0, ABDNr, ABD-T) sicher einen
Wert ergeben wird, der von CPN0 abweicht, ist diese globale
Bedingung verletzt: in diesem Fall wird eine Wechselwirkung
festgestellt, d. h. eine Wechselwirkung ist für die
Kombination ABD und OCS möglich. Es ist festzuhalten, dass keine
Interaktion festgestellt werden kann, wenn keine globale
Bedingung eingesetzt wird.
Beispiel 3
-
Das ursprungsabhängige Routen (Origin Dependent Routing) oder
kurz ODR und das zeitabhängige Routen (Time Dependent
Routing) oder kurz TDR wird in diesem Beispiel eingesetzt. Beide
werden als Anrufermerkmale angesehen.
-
ODR-T: CalledPartyNumber & CallingPartyNr & TransNr {exit = 4
cpn[1..2] = "88" cpn = CPN0 CallingPartyNr =
CallingPartyNr0}
-
ODR
-
{return = 7 (routing) cpn = translate({CPN0,
CallingPartyNr0), {CalledPartyNumber, CallingPartyNr}, ODR-T)}
-
TDR-T: CalledPartyNumber & Time & TransNr {exit = 4
cpn[1..2] = "89" cpn = CPN1}
-
TDR
-
{return = 7 cpn = translate({CPN1, system-time},
{CalledPartyNumber, Time), TDR-T)}
-
Da für den Austritt exit-ODR und exit-TDR identisch sind,
sind zwei Fälle zu betrachten. In diesem Beispiel wird nur
[ODR; TDR] betrachtet werden. Weil für die Rückkehr
return-ODR > exit-TDR, besteht ein möglicher Steuerkonflikt und
die folgende Verifizierungsregel muss geprüft werden:
-
{Pre1} CallProcessing(exit1, exit2) {Pre2}
-
d. h.:
-
{cpn[1..2] = "88" cpn = CPN0 CallingPartyNr =
CallingPartyNr0} CallProcessing(4, 4) {cpn[1..2] = "89" cpn = CPN1}
-
Da CallProcessing(4, 4) nichts ausführt, wird sich der Wert
von cpn[1..2] nicht verändern, daher wird diese Regel nicht
erfüllt. Daher besteht keine Wechselwirkung.
-
Dieses Beispiel ist eher illustrierend für die häufig
einfache Anwendung des Verfahrens gemäss der Erfindung.