-
1. Einführung
-
Es
wird eine graphische Service-Erstellungsumgebung beschrieben, welche
in der Lage ist Intelligente Netzwerk (IN)-Dienstleistungen für ein Dienstintegrierendes
Digitales/Intelligentes Breitbandnachrichtennetz (B-ISDN/IN) Netzwerk
zu erzeugen. Diese Breitband-Dienstleistungs-Erstellungsumgebung basiert auf einer
Erweiterung eines äquivalenten Schmalband-Produktes,
wie z.B. GAIN INventor, vertrieben von GPT Limited. GAIN INventor
ist eines aus einer Familie an Produkten, welche auf dem UNIXTM-Betriebssystem und einer Dienstlogik-Ausführungsumgebung
(Service Logic Execution Environment) (SLEE) basieren. Die SLEE
ist so entwickelt, um Telekommunikations-Dienstleistungen Dienstlogik-Programme
zu unterstützen
und basiert auf der SLEE API, welche im Bellcore AIN 1.0-Standard
definiert ist. Die SLEE beruht sowohl auf der Zielumgebung, dem
Dienststeuerpunkt (Service Control Point) (SCP), als auch auf dem
INventor. Eines der Merkmale des INventors ist die graphische Dienstleistungs-Erstellungsumgebung,
welche die Erstellung von Telekommunikations-Dienstleistungen erlaubt,
welche graphische Symbole verwenden, welche zusammen verbunden sind,
um ein Dienstleistungsbild auszubilden. Das Dienstleistungsbild
ist eine allgemein logische Beschreibung einer Dienstleistung ohne
jegliche ausdrückliche
Referenz auf die Dienstleistungs-Steuerfunktion
(SCF/SSF) oder Dienstleistungs-Vermittlungsfunktion
(SRF)-Schnittstellen-Meldungen, welche anders sind als jene auf einem
höheren
Level.
-
Sektion
2 wird als Hintergrundmaterial bereitgestellt. Die Annäherung innerhalb
des Projektes wurde gemacht, um geschaltete Breitband-Dienstleistungen
bereitzustellen, welche Erweiterungen der klassischen IN-Architektur
sind, da dies die typische Dienstleistungs-Entwicklungs-Architektur
nicht wesentlich ändert.
Die Service Switching Points (SSP), Service Control Points (SCPs)
und Intelligent Peripherals (IP) wurden verbessert, um mit der Breitband-Funktionalität zurechtzukommen.
Der Breitband-SCP (B-SCP) wird als Verbesserungen von einer existierenden
Schmalband-Funktionalität
realisiert. Der Breitband-SCP (B-SCP) wird als Verbesserungen zu
einem existierenden Schmalband-Produkt realisiert. Es wurden Dienstleistungs-Logik-Programme erzeugt,
welche erforderlich sind um zu ermöglichen, dass die komplexen
Breitband-Dienstleistungen auf dem B-SCP laufen, und zwar unter
Verwendung einer Breitband-Graphik-Umgebung
(B-SCE).
-
Mizuno
et. al. in „Service
Specification Description and Service Logic Program Generation for Intelligent
Networks" Intelligent
Networks: The Path to Global Networking, Proceedings of the International
Council for Computer Communication Intelligent Networks Conference,
Tampa, 4.–6.
Mai 1992, S. 430–440,
offenbart eine schmalbandgraphische Dienstleistungs-Erstellungsumgebung
zum Erzeugen von intelligenten Netzwerk-Dienstleistungen für ein Intelligentes Netzwerk,
welches einen intelligenten Editor, welcher Aufbaublöcke enthält; einen Bild-Editor
und einen Code-Erzeuger enthält,
wobei die Aufbaublöcke
eine Kollektion von spezifischen Aktionen, einem Datenzugriff und
Datenmanipulations-Routinen und Bildblöcken sind, welche das graphische
Layout der Dienstleistung bestimmen.
-
Gemäß der vorliegenden
Erfindung ist eine graphische Erstellungsumgebung von Breitbanddiensten
bereitgestellt, zur Erstellung von IN-Diensten für ein Dienstintegrierendes
Digitales/Intelligentes Breitbandnachrichtennetz, wobei die graphische Erstellungsumgebung
von Breitbanddiensten Baueinheiten, einen Bildeditor und einen Code-Generator
aufweist, wobei die Baueinheiten eine Anzahl von bestimmten Breitbandfunktionen,
Datenzugriffs- und Datenverarbeitungsroutinen plus Bildblöcke sind,
die die graphische Gestaltung des Dienstes definieren, und außerdem Baueinheiten
für generische
Dienste aufweist, die fähig
sind, eine bestimmte Nachrichtenfolge durchzuführen, dadurch gekennzeichnet,
dass die bestimmte Nachrichtenfolge durch irgendwelche asynchronen
Ereignisse unterbrochen werden kann, wobei die ursprüngliche
Nachrichtenfolge wiederaufgenommen wird, sobald ein Ereignis bearbeitet
wird.
-
Die
vorliegende Erfindung wird nun mittels Beispiel mit Bezug auf begleitende
Zeichnungen beschrieben, in denen:
-
1 das
Einheits-Beziehungsdiagramm für das
Schaltzustands-Modell zeigt;
-
2 das
Zustandsdiagramm für
die Beine von 1 zeigt;
-
3 das
Zustandsdiagramm für
die Verbindung von 1 zeigt;
-
4 die
Maschine endlicher Zustände
für die
Breitband-Dienstleistungs-Steuerfunktion
zeigt;
-
5 die
Meldungssequenz für
die AddBearer-Option in den BearerControl Generischen Dienstblöcken zeigt;
-
6A und 6B zusammengefasst
die Laufzeit-Aktion der AddBearer-Option in der Bearer Control-GSBB
zeigen.
-
2. IN-basierte
Breitband-Dienste
-
Die
wichtigsten Belastungen eines Breitband-Netzwerkes auf IN mit Bezug
auf Dienst-Erstellung sind:
- – die Anzahl
an B-ISDN-Rufen, welche einen IN-Dienst enthalten kann, ist nun
zahlreich;
- – beim
Abwickeln der Ereignisse bezüglich
der mehreren Rufe kann die Sequenz von einer Meldungsankunft an
der Dienstlogik unvorhersagbar sein;
- – die
Interaktion zwischen dem Netzwerk und Benutzer, welche von Breitband-Diensten
aufkommt, ist von erhöhter
Komplexität.
-
Lösungen dieser
Probleme enthalten eine Einführung
eines Schaltzustand-Modells in der Dienst-Schaltfunktion, eine Maschine
endlicher Zustände
in der Dienst-Steuerfunktion, welche die asynchronen Meldungen bewältigen kann,
und durch Einführung
einer „sehr
intelligenten" Intelligenten
Peripherie, um die komplexe Benutzer-Interaktion Handzuhaben.
-
2.1 Schaltzustand-Modell
-
Das
Schaltzustand-Modell (SSM) ist eine Funktion innerhalb des B-SSP,
welches die Aufgabe hat, die Ereignisse und Erfassungspunkte (DPs)
von den mehreren Basis-Anruf-Zustandsmodellen zu koordinieren, welche
einen Dienstmodus ausbilden. Es bietet eine objektorientierte Ansicht
der Netzwerk-Elemente und -Ressourcen der Anruf-Steuerfunktion (CCF)
zu der Dienstlogik an. Dieses Objektmodell entfernt die Komplexität am B-SCP,
um den DPs an der Dienstlogik zu koordinieren. Das Modell ist in
der Lage, sowohl abstrakte Attribute, wie Besitz des Modus, als
auch konkretere Elemente der anrufgleichen Parteien und Verbindungen
darzustellen. 1 zeigt das Einheits-Beziehungsdiagramm
für das
Schaltzustand-Modell.
-
Innerhalb
dieses Modells können
mehrere Parteien einem Modus beiwohnen, wobei ein Modus eine Darstellung
einer vollständigen
Anruf-Konfiguration, wie von einem IN-Dienst aus gesehen, ist, und eine
Partei stellt reale Endbenutzer oder Netzwerkknoten, wie den B-IP
oder sogar den B-SCP, dar. Zwischen solchen Parteien können Verbindungen
aufgebaut werden, wobei Verbindungen entweder mit Beziehung zum Überbringer
oder ohne Beziehung zum Überbringer
sein können.
Eine Verbindung enthält mehrere
Beine, wobei das Bein den Kommunikationspfad an eine Partei darstellt,
welche durch eine Verbindung mit weiteren Parteien verbunden ist.
Ein wesentliches Attribut von Verbindungen und Beinen ist der Status.
Dies stellt den Status des jeweiligen Objektes in der Rufverarbeitung
dar. 2 und 3 zeigen die Zustandsdiagramme
für die Überbringer-
und Bein-Objekte. Änderungen
im Status-Attribut von Beinen und Verbindungen können an die Dienstlogik gemeldet
werden, wenn eine Zustandsänderung
stattfindet.
-
2.2 Der Breitband-INAP
-
Die
Information fließt
zwischen der B-SCF und der B-SSF, welche auf der abstrakten Darstellung
des SSM-Modells basieren. Die B-SCF ist nur in der Lage, die Objekte
im Modell zu manipulieren, und als Ergebnis erlauben die Betriebe
für die
Informationsflüsse
nur eine solche Objektmanipulation.
-
Das
Protokoll zwischen dem B-SSP und dem B-SCP, welches aufgekommen
ist, basiert auf der Manipulation der Objekte, welche im SSM-Modell dargestellt
werden. Ausdrücke
wie Hinzufügen
und Löschen
werden bei Objekten angewendet, wie z.B. Parteien, und einer Verbindung,
um dieses Protokoll bereitzustellen. Wenn beispielsweise die Dienstlogik wünscht, eine
neue Überbringer-Verbindung zwischen
zwei Parteien in dem existierenden IN-Modus hinzuzufügen, wird der Betrieb AddBearerToSession verwendet,
um den B-SSP anzuweisen, diesen Betrieb durchzuführen. Dies führte zu
einem Breitband-IN-Anwendungsprotokoll (B-INAP), welches vom derzeitigen IN-CS
1 oder 2-Standard unterschiedlich ist, aber Ähnlichkeiten mit dem aufkommenden
IN-CS 3.2-Standard hat. Der B-SCP hält seine eigene Ansicht des
SSM-Modells aufrecht,
sobald Beziehungsinformation im Informationsfluss übertragen
wird. Das Modell in der B-SCF wird mit dem Modell im B-SSP abgestimmt,
welches bedeutet, dass, wenn ein Ereignis auftritt, welches den
SSM-Zustand ändert,
ein Kommunikationsfluss verwendet wird, um den SSM-Zustand in den
zwei Knoten abgestimmt zu lassen. Zustandsänderungen treten als Er gebnis
eines durch die B-CCF gemeldeten Ereignisses auf, wobei in diesem
Fall der B-SSF-zu-B-SCF-Informationsfluss stattfindet. Die Steuerung
darüber,
bis zu welchem Zustand Änderungen
an die Dienstlogik gemeldet werden, ist unter der Steuerung der
Dienstlogik selber. Die Dienstlogik muss Anfragen an den B-SSP senden,
so dass die bestimmten Zustandsänderungen,
welche auftreten, gemeldet werden. Beispielsweise muss im oben erwähnten AddBearerToSession-Betrieb,
damit die Dienstlogik eine Meldung empfangen kann, dass die Überbringer-Verbindung aufgebaut
wurde, eine RequestReportSSMChange gesendet werden, welcher den Übergang
BeingSetUp zu SetUp spezifiziert, und zwar vor Senden der Meldung.
Somit wird, wenn die Netzwerkverbindung tatsächlich aufgebaut ist, die Dienstlogik über den Aufbau
der Verbindung informiert, und zwar über den Betrieb ReportSSMChange,
welcher anzeigt, dass der Überbringer-Status
sich zum Status SetUp geändert
hat.
-
2.3 B-SCF-Maschine endlicher
Zustände
-
Eine
wesentliche Konsequenz des SSM und des B-INAP, soweit der B-SCP
betroffen ist, ist die Maschine endlicher Zustände auf der Zugriffsseite. Nach
dem Empfang der Meldung, welche die Dienstlogik auslöst, und
zwar der Dienstanfrage, hat der B-SCP eindeutig die notwendigen
SSM-Zustandsänderungen
vorzubereiten, um den Status der Rufe und/oder Verbindungen aufgespürt zu lassen.
Die Dienstlogik muss informiert werden, wenn Verbindungen aus irgendeinem
Grund freigelassen werden, und da dies mittels einer ReportSSMChange-Meldung
erreicht wird, muss die Dienstlogik in einer Position sein, eine
solche Meldung in irgendeinem Zustand zu akzeptieren, nachdem die
IN-Dienstlogik ausgelöst
ist. 4 zeigt die Maschine endlicher Zustände, dass
der B-SCP-Zugriffsverwalter in der Lage sein muss, mit Zustand A
klarzukommen, welches den Leerlauf-Zustand darstellt, bei welchem
die Dienstlogik auf die Anfangs-IN-Auslösung
(ServiceRequest) wartet. Bei diesem Ereignis wechselt der Zustand
auf Zustand B. Dies ist ein alles umgreifen der Zustand, bei welchem
Meldungen zur Sendung an den B-SSP vorbereitet werden, jedoch muss
er unbedingt ebenfalls in der Lage sein, während dieses Zustandes Meldungen
vom B-SSP zu akzeptieren. Dies ist so aufgrund der Tatsache, dass
Rufe und/oder Verbindungen zu jeder Zeit freigelassen werden können, welches
zu einer Meldung an die Dienstlogik führt.
-
2.4 Benutzer-Interaktion
-
Bei
den betrachteten Dienstleistungen können Benutzer, welche eine
Set-Top-Box verwenden, eine interaktive Phase des Dienstes oder
einer Navigation einnehmen, welche es dem Benutzer erlaubt, Passwörter einzugeben,
Dienstprofile zu aktualisieren oder Selektionen vorzunehmen, welche
die IN-Dienstlogik beeinflussen. Da jeder Dienst unterschiedliche
Anforderungen hat, wurden zwei Annäherungen an die Benutzer-Interaktion
entwickelt. Zur einfachen und allgemeinen Interaktion, welche vorgesehen
ist, um zusammen mit jedem End-System zu arbeiten, wurde das Merkmal
Benutzerdienst-Interaktion (USI) eingeführt. Diese verwendet eine Signalisierungsverbindung
zwischen dem End-System und
dem B-SCP, um Benutzerdienst-Information zu übermitteln. Für eine komplexe
Multimedia-Interaktion wurde eine breitbandspezialisierte Quellfunktion (B-SRF)
eingeführt,
welche eine GUI-basierte Interaktion mit dem End-System unterstützt.
-
Eine
verbindungsorientierte Überbringer-Unabhängigkeit
(COBI) wurde als Transportmittel angepasst, um eine direkte Interaktion
zwischen Benutzer und Dienstlogik zu ermöglichen. Die Handhabung von
rufbezogenen Ereignissen und nicht rufbezogenen Ereignissen wird
in einer vereinheitlichten Ansicht zum B-SCP durch das IN-SSM-Modell
dargestellt. Die B-SRF stellt dieselbe Funktionalität wie im Schmalband-Fall
dar, mit den hauptsächlichen
Ausnahmen, dass es seine eigene Logik und Verarbeitungsfähigkeit
enthält,
um zusammen mit dem Breitband-CPE zu arbeiten, um die Dienstleistungen
auf eine benutzerfreundliche Weise bereitzustellen, und welche mit
dem Netzwerk über
eine spezialisierte Schnittstelle zur B-SCF interagiert. Die Erstellung
einer Dienstlogik, welche sich in der B-SRF befindet, wird nicht
in Erwägung
gezogen, jedoch werden Hilfsmittel zum Erzeugen der Dienstlogik
in Erwägung
gezogen, welche sich in der B-SCF befindet und dort ausgeführt wird.
-
3. Dienst-Erstellungs-Umgebung
für Breitband-IN-Dienste
-
Die
Schmalband-Dienst-Erstellungsumgebung basiert auf den logischen
Verbindungen von graphischen Baueinheiten, welche hier als allgemeine
Dienst-Baueinheiten (oder GSBBs) bezeichnet werden, jedoch können die
Konzepte genauso bei einer Breitband-Umgebung angewendet werden.
Die GSBBs sind eine Annäherung
an die dienstunabhängige
Einheit oder SIB-Konzepte in IN-CS-1.
Die SCE enthält
eine endliche Anzahl an GSBBs, welche in einer GSBB ausgewählt und
angepasst werden können.
Angepasste Beispiele der GSBBs oder Icons werden auf einer Skizze
platziert und zusammen verbunden, um den Dienstlogik-Fluss auszubilden,
welcher in einer Bilddatei erforderlich ist. Ein Code-Generator wandelt
die Bilddatei in Laufzeit-Dateien um, welche erforderlich sind,
um den Dienst laufen zu lassen. Es gibt grob gesagt drei Klassen
an GSBBs. INAP-abhängige
GSBBs, INAP-unabhängige GSBBs und
Bild-GSBBs. Die erste Klasse, nämlich
die INAP-abhängigen
GSBBs, wandelt sich in eine Sequenz an B-INAP-Meldungen, welche zwischen dem B-SCP
und B-SSP und/oder B-IP ausgetauscht werden. INAP-unabhängige GSBBs
führen
Betriebe durch, welche sich nicht auf INAP-Betriebe beziehen. Die
Mehrheit bezieht sich auf eine Datenbank-Manipulation, enthält jedoch
auch eine Variablen-Manipulation und eine Dienstlogik-Fluss-Steuerung.
Die Bild-Klasse beeinflusst nur das Layout des Dienstbildes.
-
Die
Annäherung
innerhalb der erzeugten Breitband-SCE lag darin, die bestehende
SLE innerhalb des Schmalband-Produktes wiederzuverwenden, entwickelt
jedoch neue INAP-abhängige
GSBBs, um die Funktionen zu handhaben, welche von der B-INAP erforderlich
sind, plus einer neuen Infrastruktur, um die Breitband-Funktionalität zu unterstützen, wie
z.B. die abstrakte Ansicht, welche durch das Schaltzustand-Modell
und die Maschine endlicher Logik der Dienstlogik eingeführt wird.
-
3.1 Allgemeine Dienst-Baueinheiten
für Breitband-Dienste
-
Es
wurden GSBBs, welche von den neuen B-INAP abhängen, oder B-INAP-abhängige GSBBs zusammen
mit neuen GSBBs, um die Beeinflussung der Breitband-Dienste in Betracht
zu ziehen, entwickelt. Im wesentlichen wurden B-INAP-abhängige GSBBs
im Originalprodukt aufgenommen und wurden erfolgreich ohne Änderungen
wiederverwendet. Die entwickelten B-INAP-abhängigen GSBBs fallen in die
folgenden Kategorien:
- – Rufsteuerungs-GSBBs
- – B-SRF-Interaktions-GSBBs
- – Benutzerdienst-Interaktions-GSBBs
- – weitere
verschiedene B-INAP-abhängige
GSBBs
-
Die
Rufsteuerungs-GSBBs führen
alle notwendigen Betriebe durch, welche erlauben, dass die Verbindungen
zwischen Benutzern im IN-Dienstmodus aufgebaut und gelöscht werden.
Die B-SRF-Interaktions-GSBBs
handhaben alle Betriebe, welche die B-SRF anweisen, eine skriptbasierte Interaktion mit
dem Benutzer laufen zu lassen, als auch Information über den
Benutzer zu sammeln. Die Benutzer-Interaktions-GSBBs erlaubt es
der Dienstlogik, dass End-zu-End-Protokoll zwischen dem Benutzer
und der Dienstlogik zu handhaben, wobei der Dienst-Ersteller Meldungen
zu und vom Benutzer aufbauen und extrahieren kann. Weitere entwickelte
GSBBs erlauben die Auslösung
und korrekte Beendigung von IN-Diensten und GSBBs, welche die Sammlung
von gepufferten SSM-Ereignissen als Ergebnis der für die B-SCP-implementierte Maschine
endlicher Zustände erlauben.
-
Für die Rufsteuerungs-GSBBs
ist der Dienst-Ersteller, anstelle dass er eine komplette Ansicht
der SSM bereitstellt, nur in Kenntnis von Parteien und überbringerzugehörigen/überbringer-nichtzugehörigen Verbindungen.
Der Dienst-Ersteller verwendet die Verzeichnisnummer, um die Partei-Objekte
zuzuweisen, und verwendet die Kennungen, um Überbringer zu identifizieren
und hat keine aktuelle Sicht von Bein-Objekten. Die Dienst-Infrastruktur handhabt
die komplexe Verknüpfung
von Objekten und Kennungen, welche die notwendige Abbildung im SSM-Modell durchführen. Dies
hat den Vorteil, dass der Dienst-Ersteller
sich nicht mit den komplexen Objekt-Verknüpfungen und -Beziehungen, welche
vorliegen, zu beschäftigen
braucht.
-
7 stellt
eine Liste an möglichen
GSBBs bereit. Alle GSBBs, welche sich auf einen Datenbankzugriff
beziehen, werden ohne jegliche Modifikationen aufgenommen. Diese
Datenzugriffs-GSBBs erlauben
beispielsweise das Nachschlagen nach einer Tageszeit-Leitung oder
nach einem Bereich einer Ursprungsbestimmung. Da es keine Beeinflussung eines
Breitband-Netzwerkes gibt, bleiben die Baueinheiten unbeeinflusst.
Ein GSBB, welcher es dem Dienst-Ersteller erlaubt, einen maßgeschneiderten Datenzugriff
zu bestimmen, versorgt jegliche spezielle Anforderungen der Breitband-Dienste.
-
3.2 GSBB-Meldungssequenz
-
Jeder
der B-INAP-abhängigen
GSSBs übersetzt
in eine Sequenz an Meldungen, welche zwischen dem B-SCP und dem
B-SSP und/oder B-IP ausgetauscht
werden. Diese Meldungssequenz wird von einer dynamischen Beschreibung
des GSBB übersetzt,
wobei die Information in den Meldungen für eine Kombination der Werte
bestückt
wird, welche durch den Dienst-Ersteller von einer graphischen Benutzer-Schnittstelle,
dem SSM-Modell und der Dienst-Infrastruktur eingesetzt werden. Die
GSBBs wurden erzeugt, um den Typ an B-INAP-Betrieb wiederzuspiegeln.
Wieder wurden Begriffe, wie z.B. Hinzufügen und Löschen, angewendet, um die erlaubten Aktionen
in der GSBB zu beschreiben. Jedoch sind solche Aktionen auf Verbindungen
oder reale Endbenutzer beschränkt,
die Aktion des GSBB wird entweder zur Erstellung oder Löschung von
allen notwendigen SSM-Objekten im B-SSP führen. Beispielsweise erlaubt
einer der entwickelten neuen GSBBs, nämlich der BearerControl-GSBB,
die Auswahl von entweder der Löschung
einer bestehenden Überbringer-Verbindung
oder die Erstellung einer neuen Überbringer-Verbindung
zwischen zwei bestehenden Parteien. Diese Aktionen werden auf den
DeleteBearer oder AddBearerToSession B-INAP-Betrieben abgebildet.
Wenn eine neue Überbringer-Verbindung angefragt
wird, werden neue Objekte bezüglich
der Überbringer-Verbindung
und ihrer damit in Zusammenhang stehenden Beine erzeugt. Innerhalb
der B-SCE wird dies automatisch durch die Infrastruktur gemacht,
wodurch diese Aufgabe vom Dienst-Ersteller entfernt wird. Dies stellt
sicher, dass eine einheitliche SSM-Information in den Meldungen
zum B-SSP eingesetzt wird. Der Dienst-Ersteller muss die Überbringer-Eigenschaften
(beispielsweise Bandbreite, Klasse, usw.) und die Verzeichnisnummer
der Parteien, welche die Überbringer-Verbindung
teilen, zuführen.
-
Jeder
GSBB hat eine spezielle Meldungssequenz-Beschreibung, welche die
Meldungen beschreibt, welche zwischen dem B-SCP und dem B-SSP und/oder
dem B-IP ausgetauscht werden. Die Antworten vom B-SSP nehmen die
Form von Zustandsänderungen
bezüglich
von Objekten an. Die Kommunikation, welche diese Zustandsänderung anzeigt,
wird nur gesendet, wenn die Dienstlogik zuvor eine spezielle Meldung
gesendet hat, welche anfragt, über
die Zustandsänderungen
informiert zu werden. Ein Teil der GSBBs-Funktion ist es, alle notwendigen Zustandsänderungen
im SSM-Modell bereit
zu machen, und zu ermöglichen,
dass der GSBB über
das Ergebnis der Anfrage der erforderlichen Operation informiert
wird. Jede Rufsteuerungs-GSBB macht automatisch die notwendigen
Zustandsänderungs-Anfragen
in der Form von RequestReportSSMChange bereit, so dass sie immer über das
Ergebnis einer Rufsteuerungs-Anfrage in Kenntnis gesetzt wird.
-
5 zeigt
die Meldungssequenz, welche zwischen der Dienstlogik und dem B-SSP
ausgetauscht wird, wenn die AddBearer-Option in der BearerControl-GSBB ausgewählt wird.
Es ist jedoch zu erwähnen,
dass dies die erwartete Meldungssequenz unter normalen Bedingungen
zeigt und die Möglichkeiten
auftretender Ausnahmen ausschließt. Die drei RequestReportSSMChanges
machen automatisch die Zustandsänderungen
bereit, welche anzeigen werden, ob der Überbringer aufgebaut wurde oder
eine der End-Parteien es verweigert hat, den Ruf zu akzeptieren
oder eine der Parteien den Ruf abgebrochen hat. Der GSBB hat ein
Statusfeld, welches mit einem Wert bestückt werden wird, welcher das
Ergebnis der AddBearer-Anfrage anzeigt. Es sind zusätzliche
GSBBs möglich,
um es dem Dienst-Ersteller zu ermöglichen, Werte des Statusfelds
zu testen und eine geeignete Aktion im Dienstbild vorzunehmen.
-
Um
die Dienst-Erstellungsverarbeitung zu vereinfachen, werden die GSBBs
nur erlauben, dass sequentielle Betriebe durchgeführt werden.
Das heißt,
dass der GSBB nun erlauben wird, dass ein weiterer Betrieb durchgeführt wird,
bis eine Meldung eines Ergebnisses des Betriebes gemeldet wird. Wenn
sequentielle Betriebe durchgeführt
werden, ist es möglich,
dass eine Zustandsänderung
gemeldet wird, welche sich nicht auf den Betrieb bezieht, den die
GSBB angefragt hat durchzuführen,
das heißt, beispielsweise
die Auflösung
einer getrennten Überbringer-Verbindung innerhalb
desselben IN-Modus. In einem solchen Fall wird die normale Meldungssequenz
unterbrochen, um zu ermöglichen,
dass diese Meldung gelesen wird und dass ihr Inhalt als ein asynchrones
Ereignis gepuffert wird. Dies ist offensichtlich in der Laufzeit-Fluss-Beschreibung
des GSBB in 6A und 6B. Sobald
das Ereignis gepuffert ist, wird der GSBB seine normale Aktion, wie
durch die dynamische Beschreibung diktiert, wiederaufnehmen. Zusätzliche
GSBBs wurden bereitgestellt, um solch gepufferte Ereignisse zu testen
und zu lesen, um zu erlauben, dass sie, wie durch die Diensterfordernisse diktiert,
gehandhabt werden.
-
3.3 GSBB-Laufzeit-Aktion
-
Zusätzlich zu
einer Meldungssequenz-Datei hat jede GSBB eine damit in Zusammenhang
stehende Laufzeit-Aktions-Datei, welche die Aktionen beschreibt,
die das Icon durchführen
wird. Diese Aktionen können
nicht durch den Dienst-Ersteller geändert werden, sobald die geeignete
GSBB-Operation ausgewählt
wurde. 6 zeigt die Laufzeit-Aktionen für die AddBearer-Option
in der BearerControl-GSBB, wie durch die Meldungssequenz in 5 beschrieben.
-
3.4 Dienst-Erstellungsumgebungs-Architektur
-
Die
zentrale Architektur der B-SCE ist in 8 gezeigt.
Die Architektur hat drei eindeutige Bereiche: Baueinheits-Definition, Bild-Editor
und Code-Erstellung.
-
Die
Baueinheits-Definition ist die Stufe, wo die allgemeinen Dienst-Baueinheiten
selber definiert werden. Dies enthält die Definition der Meldungssequenz-Karte,
welche in Abschnitt 3.2 beschrieben ist, die Laufzeit-Aktionen,
welche in Abschnitt 3.3 beschrieben sind. Die Trennung zwischen
dieser Definition und dem graphischen Bild-Editor bedeutet, dass zukünftige Fähigkeiten
nicht vom graphischen Editor abhängig
sind.
-
Der
Bild-Editor ist ein graphisches Werkzeug, das dem Dienst-Ersteller erlaubt,
die Baueinheiten von einer Palette auszuwählen und sie zu einem Zeichenbereich
hinzuschieben. Sie können dann
miteinander verbunden werden, um einen logischen Fluss auszubilden,
welcher durch die Diensterfordernisse erfordert wird. Jede Baueinheit
enthält ein
Eigenschaftsblatt, welches Eingabefelder, Menüs und Auswahlknöpfe enthält, welche
verwendet werden, um den genauen Betrieb zu spezifizieren. Ein solch
genauer Betrieb kann sich auf ein Entscheidungs- Zweigkriterium, eine Benutzer-Interaktions-Information,
welche an den Endbenutzer gesendet wird, oder auf die Überbringer-Eigenschaften, welche erforderlich
sind, um eine bestimmte Überbringer-Verbindung
aufzubauen, beziehen. Die Ausgabe des Bild-Editors ist eine allgemeine
Logik-Beschreibung eines Dienstes, ohne jegliche eindeutige Referenz
auf den B-INAP, welcher sich von jenen auf einem höheren Level
unterscheidet.
-
Auf
diese Bilddatei wird vom Code-Generator eingewirkt, um Laufzeit-Dateien
zu erzeugen, welche erforderlich sind um den Dienst auf einem B-SCP auszuführen. Da
die Bilddateien keinerlei Information über die Meldungen enthalten,
verwendet die Code-Erstellung die GSBB-Meldungssequenz-Details und
Laufzeit-Aktionen,
um die notwendigen Übersetzungen
für die
B-INAP-Betriebe
durchzuführen.
Zusätzlich
werden SSM-Details und die asynchronen Meldungssammlungs-Details
ebenfalls vom Code-Generator
verwendet, um den ANSI C-Quellcode für das Dienstlogik-Programm
zu erzeugen.
-
4. Schlussfolgerung
-
Die
Anwendung einer Intelligenten Schicht auf Breitband-Netzwerke kann durch
eine graphische Dienst-Erstellungsumgebung
ermöglicht
werden. Ein flexibles Schmalband-System kann erweitert werden, um
die zusätzliche
Komplexität
bereitzustellen, welche durch diese Umgebung auferlegt wird. Um
die Dienste zu realisieren, welche diese Umgebung verwenden, wie
zum Beispiel eine verbesserte Breitband-Videokonferenz, ist die getrennte Steuerung von
Verbindungen, zusammen mit der asynchronen Handhabung von Ereignissen,
notwendig.
-
Zusätzlich wird
eine Dienstlogik erforderlich, um mit komplexen Knoten, wie z.B.
Intelligente Peripherien, zusammenzuarbeiten, um dem Benutzer vergleichbare
Dienst-Navigationstechniken
bereitzustellen.