-
Hintergrund
der Erfindung
-
Diese Erfindung bezieht sich im allgemeinen auf
die Bereitstellung einer Dienstelogik für ein intelligentes Netz (IN)
und insbesondere auf eine Verfahrensweise zur Erzeugung von einer
Dienstelogik in einer Diensteerstellungs-Umgebung auf der Grundlage der IN Ausführungs-Umgebung.
-
Die Architektur des intelligenten
Netzes wurde durch die Bemühungen
von internationalen Normungsgremien einschließlich der ITU-T (ehemals CCITT),
dem Amerikanischen Nationalen Normungsinstitut (ANSI) und dem Europäischen Telekommunikations-Normungsinstitut
(ETSI); und regionaler Spezifizierungsorganisationen einschließlich Bellcore entwickelt.
Diese Entwicklung wird durch die Nachfrage nach schneller Entwicklung
und Einsatz von Diensten in dem Telekommunikationsnetz vorangetrieben.
Die ITU-T Spezifikation „Revised
ITU-T Recommendation Q.1214 – Distributed
Functional Plane for Intelligent Network CS-1" und der ITU-T Spezifikationsentwurf „ITU-T
Recommendation Q.1224 – Distributed
Functional Plane for Intelligent Network Capability Set 2" bieten ein allgemeines
Modell für Netzelement-Ausführungsumgebungen
wie die Dienstesteuerungsfunktion (SCF) und die spezialisierte Ressourcen-Funktion
(SRF). Die ITU-T Spezifikationen Q.1205 „Intelligent Network Physical
Plane Architecture" und
Q.1215 „Physical
Plane for Intelligent Network CS-1" beziehen diese Funktionen auf physikalische
Plattformen, wie eine Dienstesteuerungsstelle (SCP), ein intelligentes
Peripheriegerät (IP),
eine Dienstevermittlungsstelle (SSP) und einen Diensteknoten (SN).
-
In ähnlicher Weise definiert die
Bellcore Spezifikation „AIN
SCP Generic Requirements Application Support Processing" GR-1280 CORE, Issue
1, August 1993 eine Dienstebereitstellungsarchitektur für die SCP
einer erweiterten intelligenten Architektur (AIN). Während diese
Spezifikationen die Basis für Dienstebereitstellung
und -ausführung
in den Ausführungs-Umgebungen
(EEs) intelligenter Netze bereitstellen, befassen sie sich nicht
mit der Notwendigkeit einer flexiblen Einrichtung zur Ermöglichung
einer Übertragbarkeit
von Dienstelogik, die von Diensteerstellungs-Umgebungen (SCEs) verschiedener Anbieter
geschaffen wurden, während
sie andererseits eine Flexibilität
in dem Dienstebereitstellungsprozess ermöglichen. Dienste erfordern
eine spezielle Auslegung, um bestimmte Teilnehmerbedürfnisse zu
befriedigen, zusätzlich
zur Definition des Verhaltens des Dienstes.
-
Telekommunikationsdienste intelligenter Netze
werden üblicherweise
unter Benutzung einer höheren
Programmierumgebung, die im allgemeinen als SCE bezeichnet wird,
entwickelt. Telekommunikationsdienste werden über ein Diensteverwaltungssystem
(SMS) bereitgestellt, das heißt
Dienste werden Telekommunikationsteilnehmern zugeordnet. Diensteinformation
wird zu der EE heruntergeladen, die entweder eine SCP, ein IP, ein
SN oder eine SSP oder eine Kombination aus diesen Elementen des
Intelligenten Netzes sein kann.
-
Derzeit ist üblich, dass jede EE in einer
herstellerspezifischen Art implementiert wird. Typischerweise stimmen
die Leistungsfähigkeiten
der SCE der Hersteller mit den Leistungsfähigkeiten ihrer EEs überein.
Um Diensteerreichbarkeit für
alle Diensteteilnehmer und -Nutzer zu bieten, müssen Diensteanbieter und -betreiber
Dienste für
jede verschiedene EE im Netz (von Hand) neu definieren, was zu inkonsistentem
Diensteverhalten, Übersetzungsfehlern,
und einer Verzögerung
der Diensteeinführung führt. Als
eine Zwischenlösung
richten manche Betreiber spezifische Dienste auf spezifische Herstellerprodukte
aus. Dennoch führt
das zu Einsatz- und Zusammenarbeitsfragen, einschließlich Diensteabdeckungs-Fragen.
-
Ein herkömmlicher Ansatz, Dienstelogikübertragbarkeit
zu erreichen, benutzt Kreuzkompilierungstechniken und Zwischensprachen,
wobei ein Ausgangs-Dienstelogikprogramm
von der SCE in eine Form übersetzt
wird, die passend für
die Ziel-EE ist. Zum Beispiel beschreibt das US Patent Nummer 5,488,569,
das am 30. Januar 1996 auf den Namen von Slutsman et al erteilt
wurde, eine Zwischensprache, die als anwendungsorientierte Programmiersprache
(AOPL) bezeichnet wird, und einen zugehörigen Kompilierungsprozess
mit drei Durchläufen,
um zwischen den verschiedenen SCEs und Ausführungsumgebungen zu vermitteln.
Der Slutsman Ansatz bedingt jedoch einen Prozess zur Diensteerstellung.
Die AOPL hängt
speziell von einer genauen Darstellung für die Dienstelogik ab, und
zwar von dem Programmcode, der direkt von der SCE ausgegeben wird.
Es gibt andere Verfahren zur Diensteerfassung, die 1) Dienstelogik
während
der Bereitstellungsphase manipulieren, oder 2) eine interpretierende
Ausführungsumgebung
nutzen. Deshalb benötigt AOPL
eine flexiblere Einrichtung zur Erfassung unterschiedlicher SCE-Ausgänge.
-
Des Weiteren vereinheitlicht die
Telekommunikationsindustrie gegenwärtig die Benutzung von Anwendungsprogramm-Schnittstellen
(APIs), die die EE Funktionalität
abstrahieren und eine einfache Einrichtung zum Aufrufen dieser Funktionalität bereitstellen.
-
Beispiele schließen folgendes ein:
- – Die
Internationale Norm ISO/IEC 9595: 1991 „Information technology – Open Systems
Interconnection – Common
management information service definition" beschreibt Dienste, die benutzt werden,
um Verwaltungsinformationen auf grundlegende Operationen zu übertragen.
Diese Dienste sind im Wesentlichen APIs, die zum Verwalten von Telekommunikationssystemen
benutzt werden.
- – Die
Internet Engineering Task Force, Network Working Group, Request
For Comment 1508 „Generic
Security Service Application Program Interface" definiert APIs, die Sicherheitsdienste-APIs im
Internet bereitstellen. Die Definitionen unterstützen eine Vielfalt von grundlegenden
Mechanismen und Techniken.
- – Die
Bellcore Spezifikationen TA-TSY-000924 „Service Logic Interpreter
1+ Framework" und SR-TSY-000778 „Service
Logic Interpreter Preliminary Description" stellen ein Gerüst für eine Dienstelogik-Ausführungsumgebung
unter Verwendung von APIs bereit.
-
Dennoch behandeln auch diese Spezifikationen
keinen flexiblen Dienstebereitstellungsprozess, auf der Grundlage
der gegenwärtigen
Architektur intelligenter Netze.
-
Eine flexible und leistungsfähige Einrichtung zur
Ermöglichung
einer Übertragbarkeit
von Dienstelogik, die von SCEs von verschiedenen Herstellern hergestellt
wurde, die gleichzeitig eine Flexibilität in dem Dienstebereitstellungsprozess
an die EEs ermöglicht,
ist wünschenswert.
-
Ohara et al beurteilen in ihrem Artikel „Evaluation
of the Service execution environment and the service development
environment for AIN" Globecom 1992,
Band 1, 6.–9.
Dezember 1992, Orlando US, Seiten 549–553, XP000357843 die Möglichkeit
eines Szenariumprozessors in einer Dienstelogik-Ausführungsumgebung
aus. Sie beschreiben ein Softwareengineering-Modell zur Einführung neuer
Telefondienste, wobei das Modell auf dem Konzept von Szenarien beruht.
-
Zusammenfassung
der Erfindung
-
Es ist ein Ziel der vorliegenden
Erfindung, eine neue und verbesserte Verfahrensweise zur Bereitstellung
von Dienstelogik zu schaffen.
-
Die Erfindung stellt daher, gemäß einem
ersten Gesichtspunkt, ein Verfahren zur Definition des Verhaltens
eines Dienst für
einen Teilnehmer in einem intelligenten Telekommunikationsnetz bereit,
um die Übertragbarkeit
von Dienstelogik zu ermöglichen, die
unter Benutzung verschiedener Diensteerstellungs-Umgebungen (SCEs)
erstellt wurde, wobei das Verfahren die folgenden Schritte umfaßt: Bereitstellen
von Schnittstellendefinitionen, gemäß denen jeweilige Funktionen
in einer Ausführungsumgebung des
Netzes aufrufbar sind, Zugriff auf die Schnittstellendefinitionen
an einer Diensteerstellungs-Umgebung (SCE), um eine Dienstelogik-Darstellung
des Dienstes zu konstruieren, wobei die SCE einzelne Schnittstellendefinitionen
auswählt,
die verwendet werden, um entsprechende Funktionsaufrufe innerhalb
der Dienstelogik-Darstellung zu bestimmen; und Liefern der Dienstelogik-Darstellung
zusammen mit Daten des Teilnehmers an die EE.
-
Gemäß einem anderen allgemeinen
Gesichtspunkt stellt die vorliegende Erfindung ein System zur Definition
des Verhaltens eines Dienstes für einen
Teilnehmer in einem intelligenten Telekommunikationsnetz bereit,
um Übertragbarkeit
von Dienstelogik, die unter Benutzung verschiedener Diensteentwicklungsumgebungen
(SCEs) geschaffen wurde, zu ermöglichen,
mit: einem Katalog der Grundelemente der Anwendungsprogramm-Schnittstellen
(API), die festlegen, wie jeweilige Funktionen in einer Ausführungsumgebung
(EE) des Netzes aufzurufen sind; einer Diensteerstellungsumgebung (SCE)
zum Aufbauen einer Dienstelogik-Darstellung des Dienstes, wobei
die SCE einen Zugriff auf den Katalog ausführt und einzelne API Grundelemente auswählt, die
verwendet werden, um entsprechende Funktionsaufrufe innerhalb der
Dienstelogik-Darstellung zu bestimmen; und einer Einrichtung zur
Lieferung der Dienstelogik-Darstellung zusammen mit Daten des Teilnehmers
an die EE.
-
Die internationale Patentanmeldung
Nummer PCT/CA95/00297 auf den Namen von K. Borg et al, die am 14.
Dezember 1995 unter der Nummer WO95/34175 veröffentlicht wurde, beschreibt
eine Technik zur Erzielung einer flexibleren Dienstebereitstellung.
Die Technik von Borg bezieht sich auf die Definition von Diensten
durch Daten und nicht durch ausführbaren
Softwarecode. Das ergibt einen einfacheren und vorhersehbareren
Bereitstellungsprozess, da Daten leichter in einer EE einzusetzen
sind, als Software.
-
In einer speziellen Ausführungsform
dieser Erfindung kommt die Technik von Borg zusammen mit einer Bibliothek
von Schnittstellendefinitionen zum Einsatz, wodurch sowohl eine übertragbare
als auch eine flexible Dienstebereitstellung erreicht werden kann.
Anwendungsprogramm-Schnittstellen (APIs) werden in der Telekommunikationsindustrie vereinheitlicht
und können
als die Schnittstellendefinitionen benutzt werden. Diese APIs stellen
ein herstellerneutrales Zusammenwirken durch ihre Vereinheitlichung
bereit, während
den Herstellern eine Flexibilität
hinsichtlich der Realisierungsoptionen ermöglicht wird.
-
Somit charakterisiert die vorliegende
Erfindung Einrichtungen zur Erleichterung der Übertragbarkeit von Dienstelogik
auf verschiedene EEs, die von SCEs von verschiedenen Herstellern
erstellt wurden, während
eine Flexibilität
in Dienstebereitstellungsplattformen und Prozessanwendungen ermöglicht wird.
Vorteile dieser Erfindung beinhalten, dass sie die Benutzung von
industriell genormten Anwendungsprogramm-Schnittstellen (APIs) der
EEs als Grundlage dafür
ermöglicht,
die Übertragbarkeit zu
erleichtern. Des Weiteren verwendet sie diese API Kenntnis direkt
in der SCE. Das SCE Ausgangsformat stellt dazugehörige Grundelemente
für den
API Aufruf bereit. Zur selben Zeit wird die Flexibilität in den
Einrichtungen berücksichtigt, über die
SCE Ausgänge
an den EEs durch die Bereitstellungsplattform und den Bereitstellungsprozess
bereitgestellt werden.
-
Kurze Beschreibung
der Zeichnungen
-
Die Erfindung wird besser aus der
folgenden Beschreibung der Dienstebereitstellungs-Verfahrensweise
unter Bezugnahme auf die beigefügten Zeichnungen
verständlich,
in denen:
-
1 die
von der ITU-T vereinheitlichte Funktionsarchitektur intelligenter
Netze darstellt, wie sie in ITU-T Spezifikationsentwurf Q.1224 „Distributed
Functional Plane for Intelligent Network Capability Set 2" angegeben ist;
-
2 den
Prozessablauf für
die Bereitstellung von übertragbarer
Dienstelogik basierend auf Ausführungsumgebungs
APIs darstellt;
-
3 verschiedene
Dienstelogikbereitstellungs- und -einsatzmöglichkeiten darstellt;
-
4 eine
Dienstelogikdarstellung, auf der Grundlage von vereinheitlichten
APIs zeigt;
-
5 in
einem Blockdiagramm eine Dienstelogik-Ausführungsumgebung gemäß einer Ausführungsform
der vorliegenden Erfindung darstellt.
-
Ausführliche
Beschreibung
-
In 1 ist
die genormte funktionelle ITU-T-Architektur für ein intelligentes Netz (IN)
dargestellt, in dem eine Diensteerstellungs-Umgebungs-Funktion (SCEF) 10 die
nötigen
Hilfsmittel für Netzbetreiber
oder ihre Beauftragten bereitstellt, um eine Verhaltensdarstellung
für Verbindungs-
und Diensteabwicklung zu erstellen. Der Ausgang des SCEF 10 wird
von einer Diensteverwaltungsfunktion (SMF) 11 genutzt,
um die verschiedenen Ausführungsumgebungen
bereitzustellen, auf die die Dienstelogik bei der Ausführung der
Dienste Bezug nimmt. Die SMF 11 aktualisiert den SCEF Ausgang, um
die Logik für
die Ausführung
zu vervollständigen, zum
Beispiel durch Verbinden geigneter Teilnehmerdaten (z. B. Routing
Nummern) und Ausführungsumgebungsdaten
(z. B. OMs) mit dem SCEF Ausgang. Die IN Ausführungsumgebungen schließen, ohne notwendigerweise
hierauf beschränkt
zu sein, eine Dienstesteuerungsfunktion (SCF) 12, eine
spezialisierte Betriebsmittelfunktion (SRF) 13, und eine Dienstevermittlungsfunktion
und eine Verbindungssteuerungsfunktion (SSF/CCF) 14 ein.
Wie in den ITU-T Empfehlungen Q.1205 und Q.1215 beschrieben, werden
die Funktionen SCEF 10, SMF 11, SCF 12,
SRF 13 und SSF/CCF 14 auf bestimmte physikalische
Elemente intelligenter Netze, beziehungsweise eine Diensteerstellungsumgebung
(SCE), ein Diensteverwaltungssystem (SMS), einen Dienstesteuerungspunkt
(SCP), ein intelligentes Peripheriegerät (IP) und eine Dienstevermittlungsstelle
(SSP), abgebildet.
-
Andere Funktionselemente der IN Architektur
beinhalten eine Diensteverwaltungs-Zugangsfunktion (SMAF) 15,
eine Dienstedatenfunktion 16, und eine Verbindungssteurungsfunktion
(CCAF) 17. Des Weiteren bezeichnen Elementverbindungen,
die durch durchgezogene Linien 18 dargestellt werden, eine
Dienstesteuerung, gestrichelte Linien 19 bezeichnen eine
Verwaltungssteuerung, und mit Perlen versehene Linien 20 sind
Sprachverbindungen. Die Balken 21 bezeichnen Zwischennetz-Verbindungen.
-
In 2 ist
eine Diensteerstellungsumgebung (SCE) 22 gezeigt, die die
Fähigkeit
zur Erstellung von IN basierenden Diensten bereitstellt und die typischerweise
eine grapische Benutzeroberfläche (GUI),
Entscheidungsgraph-Editoren, Tabellen und rechnergestützte Softwaretechnik-
(CASE) Werkzeuge beinhaltet, was die Erstellung von Logikdarstellungen
solcher Dienste vereinfacht. Die SCE 22 ist eine weit anerkannte
Plattform zur Unterscheidung von Herstellern in der Telekommunikationsindustrie,
insofern als die SCE Ausgangs- oder Dienstelogikdarstellung 23 verschiedene
Fähigkeiten
und Formate, die für
einen bestimmten Hersteller typisch sind, bereitstellen kann. Zur
selben Zeit jedoch gibt es ein anerkanntes Bedürfnis, die Übertragbarkeit der Dienstelogikdarstellung
von der SCE 22 zu einer Zielausführungsumgebung 24 zu
ermöglichen.
Da eine weite Auswahl von SCE Anwendungen besteht, ist es sehr schwierig,
Anforderungen für
entweder das Format der Dienstelogikdarstellung oder einen Prozess, durch
den diese Dienstelogikdarstellung 23 für die Ausführungsumgebung (EE) 24 realisiert
wird, anzugeben.
-
3 zeigt
verschiedene Verfahren zum Einsatz von Dienstelogik und Daten. In
Verfahren A wird unter Benutzung der SCE 22 die Dienstelogik 38a mit
den Teilnehmerdaten 38b geschaffen, wobei ein bestimmtes
Verhalten, das in die Logik 38a eingebettet ist, definiert
wird. Der resultierende SCE Ausgang ist zum Einsatz in der Ausführungsumgebung 24 bereit
(physikalisch kann der SCE Ausgang über SMS zu der Ausführungsumgebung übertragen
werden). In Verfahren B wird die Dienstelogik 39 für alle Instanzen
dieses Dienstes bestimmt. Teilnehmerspezifische Daten 40 werden
an der SMS 25 erfasst. Die Dienstelogik 39 bezieht
sich auf die Teilnehmerdaten 40. Im Verfahren C wird eine
allgemeine Dienstelogikdarstellung 23 unter Benutzung der
SCE 22 erstellt. Die Dienstelogik 41a wird in
der SMS 25 durch Definition von teilnehmerspezifischen
Optionen und Daten 41b fertiggestellt. Die Dienstelogik 41a und Daten 41b werden
dann auf die Ausführungsumgebung 24 angewendet.
Jedes dieser Verfahren stellt gültige
Lösungen
für die
Dienstelogikdefinition und -bereitstellung dar. Jedes Verfahren
definiert einen Dienst in Begriffen der Dienstelogik und Teilnehmerdaten.
Ein Verfahren zur Definition von Diensteverhalten wird benötigt, das
diese verschiedenen Lösungen
in Einklang bringt.
-
Unter erneuter Bezugnahme auf 2 ist zu erkennen, dass
zur Erzielung einer Übertragbarkeit von
Dienstelogik bei gleichzeitiger Unterstützung eines flexiblen Dienstebereitstellungsprozesses
gemäß der vorliegenden
Erfindung ein Katalog 26 von Ausführungsumgebungs-Schnittstellen-Definitionen von
der SCE 22 im Dienstelogik-Erstellungsprozess 27 verwendet
wird, um eine Dienstelogikdarstellung 23 aufzubauen. Die
Schnittstellendefinitionen stellen formale Spezifikationen bereit,
durch die jeweilige Funktionen 28, die in der Ausführungsumgebung 24 unterstützt werden,
aufgerufen werden können.
Beispiele dieser Funktionen beinhalten geographisches Routing, Tageszeitentscheidung
und Abspielmitteilungen. Jede Schnittstellendefinition beinhaltet
eine Funktionsidentifikation zum Aufruf ihrer entsprechenden Funktion 28 und
bestimmt alle Eingangs- und Ausgangsparameter,
die von dieser Funktion benötigt
werden. Diese vordefinierten Funktionsschnittstellen können als
eine Softwarebibliothek realisiert werden, die von der SCE 22 importiert
wird oder für diese
zugänglich
ist. Die Funktionen 28 können in der EE 24 als
ausführbarer
(d. h. kompilierter) Softwarecode oder als interpretierbare regelbasierte
Logikdarstellungen, von denen kompilierter Code tatsächlich aufgerufen
wird, realisiert werden.
-
Vorteilhafterweise kann der Katalog 26 der Schnittstellendefinitionen
von der Industrie anerkannte Anwendungsprogramm-Schnittstellen(APIs)-Grundelemente
beinhalten. Durch Vereinheitlichung der APIs durch Definition ihres
Formats, der Eingangsparameter, der Ausgangsparameter, etc., die
durch die Grundelemente oder Primitiven 29 gekapselt sind,
können
die IN Diensteanbieter Dienste, die für vielfache Zielausführungsumgebungen 24 geeignet
sind, spezifizieren und erstellen. Die API Primitiven geben die
Schnittstellen der EE Funktionen 28 wieder, ohne dass die
ausführliche
Implementierung dieser Funktionalität spezifiziert wird. Die SCE 22 führt einen
Zugriff auf den Katalog 26 der EE APIs aus und wählt die
individuellen API Primitiven 29 aus, die benutzt werden,
um Funktionsaufrufe in der Dienstelogikdarstellung 23 zu
spezifizieren. Des Weiteren wird die Dienstelogikdarstellung 23 durch den
Dienstelogikerstellungs-Prozess 27 erstellt, wobei Regeln
verwendet werden, um den logischen Fluß und die Aufrufe der Funktionsbausteine,
die ebenfalls den Funktionen 28 in der EE 24 entsprechen,
zu steuern. API Primitive unterscheiden sich von den Prozessen der
Funktionsbausteine darin, dass letztere eine hersteller- oder plattformspezifische
Implementierung einer Funktionalität einer Ausführungsumgebung
sind.
-
In diesem Prozess wird kein ausführbares Dienstelogikprogramm
(d. h. Code) von der SCE 22 erzeugt, sondern vielmehr eine
interpretierbare Form von Regeln, die die Dienstelogik darstellen.
Die Dienstelogikdarstellung 23 umfasst Daten, die gemäß einer
spezifischen Syntax formatiert werden, wodurch die Regeln charakterisiert
werden, wobei einzelne Regeln so angeordnet sind, dass sie den in der
EE 24 zu bewirkenden logischen Fluss wiedergeben.
-
Die Dienstelogikdarstellung 23 wird
anschließend
als der SCE Ausgang an das SMS 25 bereitgestellt, das wiederum
einen EE realisierten SCE Ausgang 30 an die EE 24 bereitstellt.
Gemäß der vorliegenden
Erfindung verbessert die an dem SMS 25 bewirkte Bereitstellung
die Übertragbarkeit
des Dienstelogikdarstellungs-Formats 23 an EEs 24 verschiedener
Hersteller unter Benutzung eines flexiblen Verfahrens, das Teilnehmer
einem Dienst zuordnet. Die von der SCE 22 abgegebene Dienstelogikdarstellung 23 gibt
einen allgemeinen Dienstelogikfluß wieder, der alle Eigenschaften
beinhaltet, die für den
Dienst an der EE 24 unterstützt sind. Auf dem SMS 25 verarbeitet
die plattformspezifische Dienstelogikdarstellungs-Funktion 32 den
SCE Ausgang als eine Funktion von Teilnehmerdaten 31, die teilnehmerspezifische
Optionen für
den Dienst enthält,
wodurch der EE instanzierte SCE Ausgang 30 erzeugt wird,
der seinerseits auf die EE 24 heruntergeladen wird. Der
EE instanzierte SCE Ausgang 30 bildet eine auf die Teilnehmer
kundenspezifisch angepasste Version der allgemeinen Dienstelogikdarstellung 23 (d.
h. eine Dienstelogikdarstellung, die zu einem spezifischen Teilnehmer
gehört)
und wird daher als eine Teilnehmerdienstelogikdarstellung 33 bezeichnet.
-
In der EE 24 ist diese Teilnehmerdienstelogikdarstellung 33 zugänglich durch
einen Dienstelogikinterpreter 34, der die Regeln, die den
logischen Fluß leiten,
interpretiert, was in 2 durch
den Flussgraphen 35 in der Darstellung 33 gezeigt
ist. Dementsprechend ruft der Interpreter 34 die Funktionen 28 auf,
die den API Primitiven 37 und den Funktionsbausteinaufrufen 36 entsprechen,
die während der
Interpretation der Teilnehmerdienstelogikdarstellung 33 durchlaufen
werden.
-
In 4 ist
ein Beispiel einer API Primitiven 42 beispielhaft erläutert, die
einen Teil der Teilnehmerdienstelogikdarstellung 33 bildet
und die den Aufruf einer Prozedur darstellt, die als „a" bezeichnet ist. Der
API Primitiven 42 ist eine genaue Syntax zum Aufruf zugeordnet,
die die Liste von geeigneten Eingangs-, Ausgangs- und geänderten
Parametern ist. In dem dargestellten Beispiel bezeichnet API_a 42 ein
spezifisches Feld 43 eines Anrufdaten-Datensatzes 44 als
Eingangsdaten für
den ersten formellen Parameter parm1 45, leitet die Ausgangsdaten
als zweiten Parameter parm2 47 ab und speichert die Ausgangsdaten
in einem Feld 46 des Anrufdaten-Datensatzes 44,
bezeichnet Teilnehmerdaten 48 als Eingang für den dritten
Parameter parm3 49 und bestimmte Plattformdaten 50 für ihren
vierten Parameter parm4 51. Die aktuelle Position oder
der Wert für einen
API- (oder Funktionsbaustein) Parameter wird während der Erstellung der Dienstelogikdarstellung 33 definiert.
-
Um dieses Konzept weiter zu verdeutlichen, wird
ein Beispiel einer zeitabhängigen
Routing-Funktion als API_a 42 verwendet. Der erste Parameter parm1 45,
der aus dem Anrufdaten-Datensatz 44 abgeleitet wurde, kann
die Rufnummer sein. Der zweite Parameter parm2 47, der
der Ausgang als ein Ergebnis der Funktion ist, würde die Routingnummer sein. Der
dritte Eingangsparameter parm3 49 könnte eine Routingtabelle auf
der Grundlage der Zeit bezeichnen, die durch die spezifischen Teilnehmerdaten 48 definiert
ist, und die die Zuordnung von Tageszeit-Schlitzen zu Routingzielen liefern würde. Der vierte
Eingangsparameter parm4 51 wird aus den Plattformdaten 50 gewonnen,
die beispielsweise einen Systemtaktwert liefern.
-
5 stellt
die Haupt-Software- und -Datenkomponenten einer Ausführungsumgebung
dar. Die Ausführungsumgebung
verwirklicht mehrere Funktionen, die benutzt werden, um eine Diensteanforderung
zu bearbeiten und einen Dienst für
bestimmte Teilnehmer aufzurufen. Bei Eingang einer ankommenden Nachricht 52 wird
ein Speicherblock zur Speicherung von Anruf- und Dienstelogikvariablen 53 zugewiesen
oder zurückgewonnen,
abhängig
davon, ob die ankommende Nachricht einem vorher bestehenden Vorgang
zugeordnet ist. Der Speicherblock 53 wird benutzt, um alle
Variablen zu speichern, die während
der Ausführung
eines Dienstes benötigt
werden. Eine Nachrichtdekodierfunktion 55 leitet Informationen
von der Nachricht 52 ab, die benutzt wird, um den aufzurufenden
teilnehmerspezifischen Dienst und daraus die Parameterposition zur Benutzung
durch die API Primitiven und/oder Funktionsbausteine zu ermitteln.
-
Eine Teilnehmerprofil-Abruffunktion 56 benutzt
ein oder mehrere Informationselemente, die aus der Nachrichtdekodierfunktion 55 resultieren,
um eine Teilnehmerdienstelogikdarstellung 57 von einer Teilnehmerprofildatenbank 58 abzurufen,
die dem teilnehmerspezifischen Diensteangebot entspricht. Der Datensatz
für die
Teilnehmerdienstelogikdarstellung 57 wird aus der Datenbank 58 gewonnen
und für einen
Dienstelogikinterpreter 59 bereitgestellt. Der Dienstelogikinterpreter 59 navigiert
dann durch die Teilnehmerdienstelogikdarstellung 57. Funktionen, die
durch den Interpreter bewirkt werden, beinhalten:
- – Ermitteln,
welcher Funktionsbaustein 60 oder welche API Primitive 61 als
nächstes
aufzurufen ist;
- – Übergeben
der Ausführungssteuerung
an den Funktionsbaustein 60 oder die Funktion, die durch die
API Primitive 61 dargestellt wird;
- – Überwachen
auf Fehlerzustände
und deren Abwicklung; und
- – Gewinnen
der Parameterwerte aus den verschiedenen Positionen in dem System
und Übergeben
dieser Werte zu Funktionsbausteinen 60 und API Primitiven 61,
wie benötigt.
-
Ein Nachrichtencodierprozess 62 führt eine Codierfunktion
aus, die Variablen aus dem Speicherblock 53 entnimmt, um
eine codierte abgehende Nachricht 63 zu erzeugen. Diese
Funktion wird nach der Beendigung des Dienstelogikinterpreters 59 aufgerufen.
-
Diese Erfindung stellt einen Grad
der Übertragbarkeit
von SCEs verschiedener Hersteller durch die übereinstimmende Benutzung von
industriell genormten APIs bei gleichzeitiger Berücksichtigung
der Flexibilität
bereit, die in dem Dienstebereitstellungsprozess zum Einsatz kommt.
-
Der Fachmann wird erkennen, dass
zahlreiche Abwandlungen und Änderungen
der Erfindung durchgeführt
werden könnten,
ohne von dem Schutzumfang abzuweichen. Es soll deshalb verständlich sein,
dass bei Fehlen spezifischer Beschränkungen hinsichtlich jeder
Ausführungsform
die Ansprüche nicht
als auf die präzisen
vorstehend beschriebenen Ausführungsformen
beschränkt
anzusehen sind.