-
Die
Erfindung betrifft ein Verfahren zur Bereitstellung eines Dienstes
für Benutzer
eines Telekommunikationsnetzes nach Anspruch 1, ein Verfahren zum
Ausführen
einer Dienstlogikfunktion in einer Dienststeuereinrichtung eines
Telekommunikationssystems nach Anspruch 15, eine Dienststeuereinrichtung
zum Anschluss an eine oder mehrere Dienstvermittlungsstellen eines
Telekommunikationsnetzes nach Anspruch 16 und einen Verarbeitungsknoten
für eine
an eine oder mehrere Dienstvermittlungsstellen eines Telekommunikationsnetzes angeschlossene
Dienststeuereinrichtung nach Anspruch 18.
-
Telekommunikationsdienste
können
entsprechend der Architektur des Intelligenten Netzes erbracht werden.
-
Ein
Benutzer eines Telekommunikationsnetzes fordert einen Dienst durch
Wahl der dem Dienst zugeordneten Nummer an. Der Ruf mit dieser Nummer
wird durch das Telekommunikationsnetz zu einer Dienstvermittlungsstelle
geleitet, die diesen Ruf als einen den Dienst anfordernden Ruf erkennt.
Dann kommuniziert die Dienstvermittlungsstelle über ein Datennetz mit einer
Dienststeuereinrichtung, dem so genannten Dienststeuerungspunkt.
Dieser Dienststeuerungspunkt enthält eine Dienstlogik, die eine Beschreibung
des Verfahrens enthält,
welches durchzuführen
ist, um den Dienst dem rufenden Benutzer bereitzustellen. Aufgrund einer
Aufforderung der Dienstvermittlungsstelle wird die Durchführung dieses
Verfahrens durch die Dienstlogik initiiert und der angeforderte
Dienst dem Benutzer bereitgestellt.
-
Diese
Dienstlogik ist als ein einziger Prozess realisiert, der alle Verbindungen
nacheinander abwickelt, wobei jede von diesen eine Warteschlange durchläuft. Jede
Verbindung ist einem Kontext zugeordnet, wodurch der Verbindungszustand
zwischen Benutzerinteraktionen nicht verloren geht. Der Dienst wird
durch einen endlichen Automaten ausgeführt, dem als Eingangsinformation
die TCAP-Nachricht und der Kontext der Verbindung zugeführt wird.
-
Eine
solche Dienstlogik ist bekannt aus Kusaura et al., „Distribution
of service data to distributed SCPs in the advanced IN", GLOBECOM 95, 14.
Nov. 1995, Singapore, S. 1272–1276.
Dort wird ein semantisches Verfahren zum Verteilen von Dienstdaten von
einem Systemmanagement an verteilte Dienststeuerungspunkte beschrieben.
Einen ersten Einblick in die Common Object Request Broker Architecture
gibt Tibbits in seinem Aufsatz „CORBA: A common touch for
distributed applications",
DATA COMMUNICATIONS, Band 24, Nr. 7, 21. Mai 1995, New York, USA,
S. 71–75.
-
Der
Nachteil des obigen Lösungsansatzes liegt
darin, dass bei dieser Architektur zur Bereitstellung von Diensten
in der Dienststeuerungseinrichtung eine ankommende Dienstanforderung
auf ihre Ausführung
warten muss, bis die aktuelle abgearbeitet ist. Somit ist die Anzahl
der der von der Dienststeuereinrichtung bearbeitbaren Dienstanforderungen
streng begrenzt.
-
Es
ist deshalb eine Hauptaufgabe der vorliegenden Erfindung, die Anzahl
von Dienstanforderungen, die von einem an der Ausführung von
Diensten für
Benutzer eines Telekommunikationsnetzes beteiligten Verarbeitungsknoten
bewältigt
werden können, zu
erhöhen.
-
Diese
Aufgabe wird gelöst
durch eine Verfahren zur Bereitstellung eins Dienstes für Benutzer
eines Telekommunikationsnetzes nach der Lehre des Anspruchs 1, durch
eine Verfahren zum Ausführen einer
Dienstlogikfunktion in einer Dienststeuereinrichtung eines Telekommunikationssystems
nach der Lehre des Anspruchs 15, durch eine Dienststeuereinrichtung
zum Anschluss an eine oder mehrere Dienstvermittlungsstellen eines
Telekommunikationsnetzes nach der Lehre des Anspruchs 16 und durch
einen Verarbeitungsknoten für
eine an eine oder mehrere Dienstvermittlungsstellen eines Telekommunikationsnetzes
angeschlossene Dienststeuereinrichtung nach der Lehre des Anspruchs
18.
-
Der
Grundgedanke der Erfindung besteht darin, dass für jede von einer Dienstvermittlungsstelle
empfangene Dienstanforderung innerhalb der Dienststeuereinrichtung
ein Dienstsitzungsobjekt (Service Session Object) erstellt wird,
das über
eine Objektinfrastruktur mit anderen Objekten in einer objektorientierten
Rechnerumgebung interagieren und kommunizieren kann, und dass das
jeweilige Dienstsitzungsobjekt die Ausführung des Dienstes für den jeweiligen
Dienstanforderungsanruf steuert.
-
Damit
basiert die Dienstarchitektur nicht mehr auf einem Funktionsentwurf,
und es können Technologien
wie Multithreading oder Multiprocessing angewendet werden.
-
Durch
die Einführung
einer objektorientierten Rechnerumgebung und des oben beschriebenen speziellen
Objektdesigns kann die Verarbeitung der Dienstanforderungen verteilt
werden, wodurch eine hohe Skalierbarkeit und IT-Plattform-Unabhängigkeit erzielt
werden. Die Neugestaltung der Dienstlogik nach diesem Lösungsansatz
ermöglicht
einen einfachen Dienstübergang
sowie einfache Personalisierung, Verteilung und Wartung der Software.
Das Entwurfsmuster ermöglicht
es, alle Vorteile der objektorientierten Programmierung zu nutzen.
-
Weiterhin
ist es möglich,
Multithreading einzuführen.
Der direkte Vorteil besteht darin, dass eine Dienstsitzung, d.h.,
die Abarbeitung einer Dienstanforderung, nicht durch die Ausführung einer
anderen blockiert wird.
-
Die
Verwendung eines Factory-Objekts ermöglicht die Implementierung
mehrerer Lebenszyklus-Richtlinien für die Dienstsitzungsobjekte.
-
Weiterhin
ist es vorteilhaft,
- • jeden Dienst mit einem dedizierten
CORBA-Server zu realisieren. Dann wird jeder Anruf an den Dienst
von einem einzigen CORBA-Objekt abgewickelt.
- • die
Erstellung eines Dienstsitzungsobjekts durch ein dienstspezifisches
Factory-Objekt zu verwalten.
- • die
Schnittstellendefinition eines Dienstsitzungsobjekts als „TCAP,
abgebildet über
IDL" festzulegen.
-
Durch
die Verwendung von CORBA-Servern wird die Realisierung der Dienststeuereinrichtung vereinfacht
und Skalierbarkeit gewährleistet.
-
Weitere
vorteilhafte Ausgestaltungen der Erfindung sind den Unteransprüchen zu
entnehmen.
-
Die
Erfindung wird nun anhand der beiliegenden Zeichnungen beschrieben.
-
1 zeigt
in einem Blockschaltbild die Architektur eines Telekommunikationssystems,
das eine erfindungsgemäße Dienststeuereinrichtung
enthält.
-
2 zeigt
in einem Blockdiagramm eine erste Objektarchitektur des Telekommunikationssystems.
-
3 zeigt
in einem Blockdiagramm eine zweite Objektarchitektur des Telekommunikationssystems.
-
4 zeigt
in einem Blockdiagramm eine dritte Objektarchitektur des Telekommunikationssystems.
-
5 zeigt
in einem Blockdiagramm eine Objektarchitektur einer Dienstvermittlungsstelle
für das
Telekommunikationssystem.
-
1 zeigt
ein Telekommunikationssystem TS mit einem Telekommunikationsnetz
KN1, einem einem Teilnehmer A zugeordneten Teilnehmerendgerät T, einem
Kommunikationsnetz KN2 und zwei Dienststeuereinrichtungen SCP1 und
SCP2.
-
Das
Telekommunikationsnetz KN1 ist beispielsweise ein Fernsprechnetz.
Dieses Netz kann auch ein Datennetz oder ein Kommunikationsnetz
für gemischte
Daten-, Sprach- und Bildübertragung
sein.
-
Von
den Vermittlungsstellen des Netzes KN1 sind zwei speziell ausgestaltete
Vermittlungsstellen SSP1 und SS2 gezeigt. Diese Vermittlungsstellen sind
Dienstvermittlungsstellen, die eine Dienstvermittlungs-Funktionalität SSP enthalten.
Zu diesen Vermittlungsstellen werden Dienstanforderungsanrufe von
Teilnehmern des Netzes geleitet. Wenn eine solche Dienstvermittlungsstelle
eine solche Dienstanforderung empfängt, sendet sie eine entsprechende
Anforderung über
das Netz KN2 an eine der beiden Dienststeuereinrichtungen SCP1,
SCP2. Gesteuert von der jeweiligen Dienststeuereinrichtung SCP1,
SCP2 wird dann der Dienst erbracht.
-
Jede
der Dienststeuereinrichtungen SCP1 und SCP2 stellt einen oder mehrere
Dienste S bereit und realisiert eine Dienststeuerfunktion.
-
Das
Kommunikationsnetz KN2 ist vorzugsweise ein Datennetz, insbesondere
ein Netz gemäß dem SS7-Zeichengabeprotokoll.
Dieses Netz kann auch ein LAN (Local Area Network), ein MAN (Metropolitan
Area Network) oder ein ATM-Netz (ATM = asynchroner Transfer-Modus)
sein.
-
Vorzugsweise
sind die Dienstvermittlungsstellen SSP1, SSP2 und die Kommunikation
zwischen diesen und den Dienststeuereinrichtungen SCP1, SCP2 entsprechend
der Architektur des Intelligenten Netzes (entsprechend der des Dienstvermittlungspunkts
und entsprechend der Kommunikation zwischen dem Dienstvermittlungspunkt
und dem Dienststeuerpunkt), die zum Beispiel in ITU-T-Empfehlung Q.1214
beschrieben ist, ausgelegt.
-
Wenn
ein Anwender einen Dienst S starten will, wählt er eine spezielle Nummer
für diesen Dienst.
Die Ortsvermittlungsstelle leitet diesen Anruf zu den nächstgelegenen
Dienstvermittlungsstellen, und damit wird die Dienstvermittlungsfunktionalität SSP aktiviert,
den Dienst zu starten. Dies geschieht durch Senden einer Aufforderung
an die SCP, die Ausführung
eines Dienstlogikprogramms (Service Logic Program – SLP) einzuleiten.
Ein SLP ist dienstspezifisch, es gibt dem Netz vor, wie der Dienst
zu behandeln ist. Es führt Dienstlogik,
Statistiklogik, Datenbanklogik, Gebührenlogik usw. aus. Ein SLP
liefert auch Anweisungen für
die Vermittlungsstelle (z.B. Aufbau des zweiten Abschnitts der Verbindung) und
die intelligente Peripherie (z.B. Ansageeinrichtungen). Dafür wird das
INAP-Protokoll verwendet, und INAP-Nachrichten werden in TCAP-Nachrichten zwischen
SCP und SSP transportiert.
-
Bei
der Entwicklung einer verteilten Anwendung werden zunächst die
möglichen
zu verteilenden Systemkomponenten identifiziert (d.h., welche die Objekte
des Systems sind und wie sie zu größeren Objekten vereinigt werden,
die dann verteilt werden).
-
Die
Aufgliederung der SCP in Objekte bietet einige Möglichkeiten. Die 2 bis 3 veranschaulichen
diese, strukturiert in unterschiedlichen Architekturen. Alle Zustandsinformationen
zur Abwicklung eines Anrufs wurden zusammengehalten und diese gesamten
benötigten
Daten wurden in Objekten gruppiert. So ist eine Möglichkeit
für SCP-Objekte
ein Scriptobjekt, das die Dienstlogik für einen Anruf und ein Objekt
pro Datenobjekt ausführt.
-
Die
Werte der Datenobjekte sind in einer Datenbank enthalten, so dass
vorzugsweise Datenobjekte verwendet werden, welche die Verwendung
einer Datenbank verdecken (d.h., es wird eine gewisse Unabhängigkeit
von der Datenbank angestrebt). Die Schwierigkeit liegt darin, dass
die Bildung von CORBA-Objekten aus diesen Objekten zu einem beträchtlichen
Overhead führt,
wenn Methoden (z.B. Lesen oder Schreiben von Attributwerten) daran
ausgeführt werden,
Die Systemleistung würde
damit inakzeptabel werden.
-
Das
Scriptobjekt könnte
in eine Dienstausführungsmaschine
und einen SIB-Graphen zerlegt werden. Damit könnten auch SIBs zu verteilten
Objekten werden. Wenn Datenbankobjekte verteilt sind, bietet dies
die Möglichkeit,
einen SIB auf der Maschine auszuführen, in der das jeweilige
Datenobjekt gespeichert ist. Es ist ein System denkbar, in dem es eine
Steuerinstanz (einen Script) gibt, die SIBs abgesetzt ausführt (mögliches
zusätzliches
Overhead), oder ein System, in dem die Steuerung von SIB zu SIB
weitergegeben wird. Diese Abwägung
zwischen der Ausführung
eines Scripts auf einer Maschine und der Ausführung von Teilen eines Scripts
(SIBs) dort, wo die Daten gespeichert sind, ist es sicher wert,
näher untersucht
zu werden.
-
Die
wichtigste SSP-Funktionalität
besteht darin, eine Programmeinstiegsmöglichkeit („hook") zwischen der Verbindungsabwicklung
und dem IN-System bereitzustellen. Ein SSP-Server muss mindestens
ein Objekt als Brücke
zur normalen Verbindungssteuerfunktion (Call Control Function – CCF) und
ein Objekt als Brücke
zur Vermittlungsfunktion (Switching Function – SF) aufweisen. Auch ein Objekt
als Brücke
zwischen speziellen Ressourcen (Specialized Resource Function – SRF) (z.B.
Ansageeinrichtungen) erscheint naheliegend. In 4 sind
diese Objekte als Vermittlungssteuerungs-, Verbindungssteuerungs-
und Spezialressourcenobjekt dargestellt. Weiterhin wird ein als
Verbindungsabwickler (Call Handler – CH) bezeichnetes Objekt benötigt, das
mit der SCP und den anderen Objekten in der SSP verschachtelt ist.
Hier gibt es zwei Möglichkeiten:
Entweder wird nur ein Call Handler, der alle Verbindungen abwickelt,
oder mehrere, die jeweils eine Verbindung abwickeln, vorgesehen.
Sind mehrere vorhanden, die nur für die Dauer der Verbindung bestehen,
dann ist auch ein entsprechendes Factory-Objekt zur Kontrolle des
Lebenszyklus dieser Objekte erforderlich.
-
Im
Folgenden wird die Architektur eines SSP-Servers nach CORBA beschrieben.
Für die
Vermittlungssteuerungs-, Verbindungssteuerungs- und Spezialressourcenobjekte
könnte
es zwei Lösungsansätze geben.
Beim ersten Lösungsansatz
sind diese Objekte lediglich Schnittstellenobjekte zwischen der
proprietären
Anwenderprogramm-Schnittstelle (Application Programming Interface – API) von
vorhandener Software. Beim zweiten Lösungsansatz würden sie
die Hardware direkt steuern; dies bedeutet, dass eine CORBA-Schnittstelle
zu Vermittlungssteuerung, Verbindungssteuerung & Spezialressourcen vorzusehen ist.
Theoretisch wäre
dies die beste Lösung,
da dieser Lösungsansatz
eine insgesamt konsistente Software-Architektur ergeben würde. In diesem
Fall müsste
eine spezielle IDL-Anpassungsschnittstelle entwickelt werden.
-
Ein
SMP ist für
ist für
Dienststeuerung und Überwachung
verantwortlich. Um Dienste steuern zu können, braucht das SMP kein
DPE-Objekt zu sein. Was benötigt
wird ist, dass die Objekte, die gesteuert werden (z.B. Script),
eine Schnittstelle dafür
bereitstellen. Zur Überwachung
ist ein SMP-Objekt erforderlich, das in der Lage ist, „Ereignisse" von Objekten zu
empfangen, die überwacht
werden. In unserem Forschungsprototypen haben wir als Beispiel dafür, was als
Management-Funktionalität
in der SCP möglich
ist, eine Ablaufverfolgungs-Steuerung (trace control) definiert
und implementiert.
-
Im
vorhergehenden Abschnitt wurde eine Anzahl von Möglichkeiten für CORBA-Objekte
in einer IN-Architektur beschrieben. Im folgenden Abschnitt werden
bestimmte dieser CORBA-Objekte zu einer speziellen Architektur gruppiert.
Die Sequenz der Architekturen kann als mögliches Entwicklungs-Szenario,
ausgehend von heutigen Dienstebreitstellungprodukten, insbesondere
IN-Produkten, angesehen werden.
-
Die
Grundlage der ersten Architektur ist die Verwendung einer verteilten
Datenbank zur Datenverteilung und einer CORBA-Verteilung für eine verteilte
SCP. Diese Architektur ist für
eine Verbindung mit vorhandenen SSPs ausgelegt, somit ist die SSP kein
CORBA-Objekt. Da diese Architektur zur Implementierung eines Forschungsprototypen
verwendet wurde, soll nun darauf genauer eingegangen werden als
auf die anderen. 3 veranschaulicht diese Architektur.
-
Die
Grundkomponenten in der Architektur sind:
- • das Script:
ein CORBA-Objekt, das genau eine Verbindung abwickelt
- • die
SLI (Service Logic Interface), ein CORBA-Objekt, das einen TCAP-Dialog abwickelt
und sich mit der SSP koppeln lässt
- • die
verteilte DB.
-
Vorhandene
IN-ServiceScripts können
in Scriptobjekten eingekapselt sein.
-
Ein
Scriptobjekt enthält
außerdem
den einen bestimmten Anruf betreffenden Dienstdaten- und Anrufkontext,
und pro Anruf ist ein Scriptobjekt instantiiert. Die Schnittstelle
des Scriptobjekts enthält
Operationen, welche diejenigen TCAP-Nachrichten darstellen, die
das Script während
seiner Ausführung empfängt.
-
Eine
spezielle Dienstlogik-Schnittstelle (Service Logic Interface – SLI) erhält die #7-Nachrichten von
der SSP und leitet sie unter Verwendung der ORB-Dienste an die entsprechende
Scriptobjekt-Instantiierung weiter. Die Schnittstelle des SLI-Objekts enthält die TCAP-Nachrichten, die
an sie gesandt werden können.
Pro Anruf ist ein SLI-Objekt instantiiert.
-
Da
die Script- und SLI-Objekte nur für die Dauer einer Verbindung
existieren, werden entsprechende Factory-Objekte zu deren Erstellung und Löschung verwendet.
Datenobjekte sind keine CORBA-Objekte, sie sind als C++ Objekte
implementiert. Diese Lösung
verdeckt die Verwendung einer besonderen Datenbank vor der Dienstlogik.
-
Als
Datenbank kann zum Beispiel Oracle, SQLNET oder ObjectStore verwendet
werden. Zum SMP wurden keine Überlegungen
angestellt; wir hätten
den proprietären
Mechanismus verwenden können,
um Zustandsinformationen an ihn zu senden, oder ihn als CORBA-Objekt
mit geeigneter IDL-Schnittstelle definieren können.
-
Es
ist beispielsweise problemlos möglich,
ein kleines Ablaufverfolgungs-Steuerungssystem zu entwerfen und
implementieren; jeder Server weist ein Überwachungsobjekt auf, und
der Ablaufverfolgungs-Steuerungsteil des SMP kann Methoden aufrufen,
um Ablaufverfolgungen bei bestimmten Implementierungsobjekten an-
und auszuschalten. Der SMP verwaltet auch die Datenbank (unter Verwendung
von SQLNET).
-
Ein
Script und eine SLI sind CORBA-Objekte; wie diese auf Server verteilt
sind ist eine Frage des Systemaufbaus. Ein CORBA-Server ist ein
Prozess, der in einem bestimmten Knoten im System abläuft. Es
gibt einen SLIServer im System, der sich mit SSP koppeln lässt. Er
weist ein CORBA-Objekt, die SLIFactory, auf, das immer vorhanden
ist, wenn der Server läuft.
-
Der
hauptsächliche
Zweck dieses Objekts besteht darin, neue SLI-Objekte zu erstellen,
wenn neue Anrufe gestartet werden. Der SLIServer ist in dem Knoten
enthalten, in dem die #7-Hardware und -Software installiert sind.
Das System kann eine Anzahl von ScriptServern aufweisen, nämlich einen
pro verfügbaren
Knoten.
-
Der
Server weist außerdem
ein Factory-Objekt auf, das während
der Lebensdauer des Servers existiert. Dieses Factory-Objekt ist
im CORBA-Benennungsdienst registriert, so dass es von einer SLI gefunden
werden kann. Auf diese Weise wird die Dienstlogik-Verteilung vereinfacht.
Die Verarbeitungsleistung des Systems zu erhöhen bedeutet lediglich, die
neue Maschine zu installieren, den ScriptServer darauf auszuführen, und
wenn die SLI das nächste
Mal nach einem ScriptFactory sucht, steht eine neue Möglichkeit
zur Verfügung.
Derselbe Mechanismus gewährleistet
auch eine gewisse Zuverlässigkeit:
Wenn eine Maschine aus irgendeinem Grund ausfällt, erhält die SLI einfach keinen Verweis auf
diesen ScriptServer mehr. Auch ist das ScriptFactory am besten für die Installation
einer Management-Schnittstelle geeignet (z.B. um die Dienstmerkmale
zu ändern),
da es immer zur Verfügung
steht, solange der Server läuft.
-
Die
Schnittstelle zwischen SLI und Script ist als asynchron und in Form
von TCAP-Grundelementen („Primitives") (BEGIN, INVOKE,
RESULT, ...) definiert. Diese Option ist insofern von Vorteil, als
eine der zu erfüllenden
Forderungen die Wiederverwendung vorhandener IN-Produktsoftware
ist. Eine andere Option besteht darin, diese Schnittstelle in Form von
INAP-Grundelementen zu definieren.
-
Der
Unterschied zwischen einem CORBA-Objekt, einem (CORBA) Server und
einem Prozess muss klar sein. Ein CORBA-Objekt implementiert eine
Schnittstelle und läuft
innerhalb eines CORBA-Servers ab. Der CORBA-Server selbst ist ein
Prozess, der auf einem Host (oder Knoten) abläuft. Diese Definition ist wichtig
für das
Verhältnis
zwischen einem Script und einer Verbindung. In der aktuellen IN-Produkt-Implementierung
von ALCATEL ist ein Script ein Prozess, der verschiedene Verbindungen abwickelt
und für
jede von diesen einen anderen Verbindungskontext führt. Dies
geschieht aus Gründen der
Leistungsfähigkeit
des Systems: Für
jede Verbindung einen eigenen Prozess (Script) zu starten erfordert
einige Zeit.
-
Man
könnte
bei diesen Architekturen einen ähnlichen
Weg einschlagen (ein Script wickelt n Verbindungen ab), doch die
Tatsache, dass ein Script mehrere Kontexte hat, ist nicht so klar,
und es ist möglich,
das Problem der Leistungsfähigkeit
durch Verwendung eines CORBA-Servers mit mehreren Scripts (die jeweils
eine Verbindung abwickeln) anzugehen. Es ist also besser, wenn bei
dieser Architektur ein Host einen oder mehr CORBA-Server abarbeiten kann,
die jeweils unterschiedliche Scriptobjekte, welche jeweils eine
Verbindung abwickeln, ausführen.
-
Der
CORBA-Server ähnelt
dem Script im aktuellen IN-Produkt,
doch das Problem der Bewältigung
von Mehrfachkontexten wird vom Anwendungsprogrammierer auf die CORBA-Plattform
verlagert.
-
Ein
weiterer Schritt in dieser Sequenz von Architekturen, eine zweite
Architektur, besteht darin, das Scriptobjekt in seine Komponenten
zu zerlegen. Wie bekannt, sind IN- Dienste als eine Anzahl von SIBs ausgeführt, welche
Knoten in einem Dienstlogik-Graphen darstellen. Die Ausführung des
Scripts bedeutet, dass SIBs ausgeführt werden und abhängig von
von der SSP kommenden Daten und Antworten zum nächsten SIB übergegangen wird. Statt dies als
monolithische Software-Einheit (aus dem SCE) zu entwerfen, könnte es
in Form von kooperierenden SIBs entworfen werden. Wie bekannt, sind
die SIBs des IN Capability Set 1 nicht genügend definiert, um in der vorhandenen
Form verwendet werden zu können.
Dies hat dazu geführt,
dass IN-Plattform-Provider ihre eigenen Sätze von SIBs vom Standard abgeleitet
haben und Software von SIBs zwischen Plattformen nicht wiederverwendbar
ist.
-
Wenn
SIBs als CORBA-Objekte definiert sind, könnte dieser Zustand durchbrochen
werden und Dienstanbieter wären
in der Lage, ihre eigenen Dienste unter Wiederverwendung bestehender
SIBs (Quellcode) zu entwickeln.
-
Das
Vorhandensein von SIBs als unabhängige
CORBA-Objekte bietet die Möglichkeit,
die SIBs an unterschiedlichen Orten auszuführen. Statt die Daten (unter
Verwendung einer verteilten Datenbank oder von CORBA-Objekten) an
den Ort zu bringen, wo das Script oder der SIB ausgeführt wird,
könnte man
den SIB auf der Maschine starten, auf der sich die Daten befinden.
Dies bietet Vorteile. Es ist ein System denkbar, in dem es eine
Steuerinstanz (ein Script) gibt, die SIBs abgesetzt ausführt, oder
ein System, in dem die Steuerung von SIB zu SIB weitergegeben wird.
-
Eine
dritte Architektur bricht mit dem traditionellen IN-Produkt in dem Sinn,
dass sie auch die SSP zu einem CORBA-Objekt macht. Bei den vorhergehenden
Architekturen ist es aus Zuverlässigkeitsgründen immer
noch erforderlich, dass CORBA-Server auf den Maschinen installiert
werden, die in einem zuverlässigen
LAN miteinander verbunden sind. In der Praxis, mit den aktuellen
DPE-Implementierungen (TCP/IP), bedeutet dies, dass die Maschinen
am selben Ort installiert werden. Diese technologische Einschränkung verhindert,
dass die SSP in die DPE gelegt wird, da in der Praxis SCP- und SSP-Standorte
an unterschiedlichen Stellen liegen. Doch die Technologie entwickelt
sich weiter, und DPE-Provider (z.B. IONA) untersuchen die Möglichkeit,
ihr Produkt zu anderen Transportprotokollen, z.B. #7-Links für Telekommunikationszwecke,
zu portieren. Wenn dies geschieht, ist der Schritt der Umwandlung
einer SSP in ein CORBA-Objekt nicht so groß. In diesem würde das
SLI-Objekt nicht
mehr benötigt,
da das SSP-Objekt dessen Rolle übernehmen
könnte.
Wenn ein Anruf gestartet wird, erhält es einen Verweis auf ein SriptFactory
und ersucht darum, das Scriptobjekt selbst zu erstellen. Es könnte dann
mit dem Objekt direkt kommunizieren. Auch kann die bei dieser Kommunikation
verwendete Sprache (INAP, eingekapselt in eine TCAP-basierte Schnittstelle)
vereinfacht werden. Diese Schnittstelle könnte in Form von INAP-Grundelementen
(z.B. provide instruction(args), join(args)) definiert werden. Dies
würde den
Systementwurf und die Systemimplementierung verbessern (vereinfachen),
da die TCAP-Schicht für
den Programmierer verschwindet. Man könnte sagen, dass bei Verwendung
von CORBA der Anwendungsprogrammierer sich nur mit der Anwendungsschicht der
Kommunikation, nicht jedoch mit der Kommunikationssteuerungsschicht
(wenn TCAP verwendet wird), befassen muss.
-
Der
letzte Schritt wäre,
ein Endgerät
zu erweitern/integrieren (wie von TINA vorgeschlagen). Dies würde eine
größere Änderung
der Benutzereinrichtung bedeuten. Diese Änderung ist allerdings nicht
undurchführbar,
wenn man berücksichtigt,
dass immer mehr Benutzer Verbindung mit dem Internet über ihre
Fernsprechleitungen aufnehmen. Die Technologie, die erforderlich
ist, um die DPE auf das Endgerät
auszudehnen, ist ähnlich.
Der Nutzen wäre, dass
das Endgerät-zu-Netz-Protokoll
viel reichhaltiger werden könnte
als lediglich DTMF-Töne
als Nummern weiterzugeben.
-
Die
oben beschriebenen Architekturen bieten eine Lösung, um insbesondere IN-Plattformen skalierbarer
zu machen. Da das Zusammenwirken mit und die Entwicklung aus bestehenden
Produkten wichtig ist, wurde eine Sequenz von Architekturen angegeben,
die als ein mögliches
Evolutions-Szenario angesehen werden kann.
-
Als
Beispiel wird im Folgenden eine Implementierungsprozedur gemäß der Architektur
3 beschrieben:
Es soll ein Kreditkartenanruf-Dienst für das bestehende
UNIX-basierte Alcatel-IN-Produkt implementiert werden. Der Kreditkartenanruf-Dienst
ist ein „typischer" IN- Dienst und ermöglicht es,
ein von einem beliebigen Endgerät
geführtes
Gespräch
einer bestimmten Kartennummer zu berechnen. Zum Aufbau der Verbindung
muss der Benutzer eine Kartennummer, einen PIN-Code und die Zielnummer
eingeben. Wenn die eingegebenen Daten korrekt sind, wird die Verbindung
zur Zieladresse durchgeschaltet und die Kosten der Karte des Benutzers
belastet.
-
Ein
so genannter SSP Simulation Stub wurde zur Erzeugung des TCAP-Dialogs
für den
Kreditkartenanruf verwendet. Der SSP-Stub ist ein CORBA-Objekt,
das die gleichen TCAP-Nachrichten
sendet und empfängt
wie eine SSP. Der SSP-Stub
ist in der Lage, unterschiedliche Verbindungs-Szenarien zu simulieren, unterschiedliche
Belastungen zu erzeugen und ein Szenario beliebig oft zu wiederholen.
-
Ein
anderes allgemeines Problem bei der Verwendung von CORBA in einer
IN-orientierten Dienstebereitstellungs-Architektur ist das Zusammenwirken von
CORBA-basierten IN-Anwendungen mit älteren („legacy") IN-Anwendungen.
-
Dieses
Zusammenwirken kann mittels Anpassung (Adaptation) erreicht werden.
Es geht dabei darum, wie eine CORBA-basierte Infrastruktur mit den älteren Vermittlungssystemen,
nämlich
SSPs, kommunizieren kann.
-
Es
sind zwei Lösungsansätze möglich:
-
1) Definition einer Anpassungseinheit,
die eine Anwendungsebenen-Brücke
ist, welche die Abbildung von SS.7- und TCAP-Grundelementen in IDL-Aufrufe bewirkt.
-
Dieser
Lösungsansatz ähnelt dem
der XoJIDM-Gruppe für
den CORBA/CMIP-Gateway [4][5]. Das Arbeitsergebnis dieser Gruppe
kann hier verwendet werden, insbesondere die statische Abbildung
von GDMO/ASN.1 auf IDL-Schnittstellen.
-
Um
die Auswirkung auf bestehende Systeme gering zu halten, sollte CORBA
Framework-Dienste und Werkzeuge bereitstellen, um diese Abbildung
zu erreichen. Die Verfügbarkeit
eines solchen Frameworks ermöglicht
das Zusammenwirken eines CORBA-basierten IN mit verschiedenen Arten
von bestehender Hardware, wie z.B. SCPs und HLRs.
-
Eine
solche Anwendungsebenen-Brücke sollte
durch hohe Verfügbarkeit
und hohe Leistungsfähigkeit
gekennzeichnet sein, ohne dabei einen Engpass für ein verteiltes System zu
bilden. Für
das geforderte Echtzeitverhalten ist dies allerdings eine Zwischenlösung auf
dem Weg zu einem vollständig CORBA-basierten
IN-System.
-
Dieser
Lösungsansatz
würde die
Erstellung einer IDL-Schnittstelle zur Darstellung von Anwendungsebenen-Protokollen
wie MAP, INAP und anderen, die auf der TCAP-Schicht basieren, erfordern. Die
TCAP-Schicht stellt einen „ROSE-ähnlichen" asynchronen RPC-Dienst über der
SCCP-Schicht bereit.
Und ein Basieren der Brücke
auf TCAP schließt
die Verwendung von leitungsbezogenen Zeichengabeprotokollen, wie
ISUP und TUP, von der Lösung
aus.
-
Wie
bei der XoJIDM-Lösung
sollte eine statische Umsetzung der INAP/TCAP-Spezifikation zu IDL-Schnittstellen stattfinden,
was durch einen dedizierten Kompilierer erfolgt. So kann jeder INAP-Dialekt
in geeignete IDL-Schnittstellen umgesetzt werden. Diese Anwendungsebenen-Brücken würden diese
IDL-Schnittstellen implementieren und eine dynamische Umsetzung
zwischen von IDL abgeleiteten Typen und deren ASN.1-Äquivalenten
durchführen.
-
CORBA-Knoten,
welche die speziellen Brücken
verwenden, würden
im allgemeinen zwei Server ausführen,
nämlich
jeweils einen zur Abarbeitung von abgehenden Aufrufen und einen
zur Abarbeitung von ankommenden Aufrufen. Da TCAP ein verbindungsloser
Dienst ist, muss der Gateway den Zustand aufrechterhalten, um Aufrufe
an Antwortverhalten und Ausnahmenbedingungen anzupassen.
-
2) Verwendung von SS7
als umgebungsspezifisches Inter-ORB-Protokoll
(ESIOP):
-
Eine
mögliche
Lösung
besteht darin, das CORBA GIOP auf SS7 abzubilden oder ein neues, erweitertes
Protokoll (ESIOP) auf den SS7-Schichten aufzubauen.
-
Die
ESIOP-Lösung
würde im
Wesentlichen ein SS7-Protokoll
als Transportprotokoll für
das GIOP-Protokoll
verwenden. CORBA-Objekte wären
im gesamten SS7-Netz in genau derselben Weise sichtbar, wie dies
mit CORBA IIOP im Internet der Fall wäre. Dies würde es einem ORB ermöglichen,
eine bestehende SS7-Infrastruktur für Transportzwecke zu verwenden.
-
Es
ist zu beachten, dass bestehende Zeichengabenetze nicht für die Unterstützung der
Art von Verkehr dimensioniert sind, die zwischen CORBA-Knoten ausgetauscht
wird. Ein möglicher
Vorteil dieses Lösungsansatzes
liegt jedoch darin, dass die fehlertolerante Eigenschaft des SS7-Netzes
ausgenutzt werden kann.
-
Die
erste Frage ist die Wahl der SS7-Protokoll-Zugriffsebene für die Lösung. Die beiden hauptsächlichen
Alternativen sind TCAP und SCCP:
-
GIOP auf TCAP-Ebene:
-
Es
sollte möglich
sein, TCAP für
den Transport von GIOP-Nachrichten zu verwenden, denn IT ist im
Wesentlichen ein ROSE-ähnlicher
Dienst. Dienste, die TCAP verwenden, müssen ihre Operationen unter
Verwendung von ASN.1-Modulen definieren. Es ist geplant, ASN.1-Makros
für die
Definition der Operationen zu verwenden: Request, Reply, CancelRequest,
LocateRequest, LocateReply, CloseConnection und MessageError. Diese
Operationen entsprechen den GIOP-Grundelementen. Der Gateway wäre für die Umsetzung
des CDR-Formats, in der von GIOP verwendeten Form, in eine Form
zuständig,
die unter Verwendung von ASN.1-Typen transportierbar ist (eventuell
als nichttransparenter Puffer mit BER-Codierung).
-
Obwohl
es im Prinzip möglich
sein sollte, TCAP als Basis für
das ESIOP zu verwenden, ist dies nicht geeignet wegen
- • der
Komplexität
der Implementierung
- • des
durch die TCAP-Schicht zusätzlich
zum eigentlichen Transport verursachten Overhead
- • der
asynchronen Eigenschaft des Protokolls.
-
ESIOP auf SCCP-Ebene:
-
Die
andere Möglichkeit
für die
Implementierung des SS7 ESIOP besteht darin, dies auf der SCCP-Ebene
vorzunehmen. Der SCCP stellt Dienste bereit, die der OSI-RM-Netzschichtfunktionalität entsprechen.
Er kann sowohl im verbindungsorientierten als auch im verbindungslosen
Modus arbeiten. Es müsste
möglich
sein, den SCCP zum Transport von GIOP-Nachrichten zu verwenden, obwohl der
ESIOP-Code eventuell zur Ausführung
von eigenen Transportschicht-Funktionen (z.B. Ende-zu-Ende-Flussregelung und
Segmentierung/Wiedervereinigung) benötigt wird. Auch müsste es
möglich
sein, CORBA-Knoten
unter Verwendung der SCCP-Adressierungsart „Global Title" zu adressieren.
Somit scheint es, dass die Verwendung von SCCP als Basis für einen
ESIOP für
das SS7-Netz die beste Lösung
wäre.
-
Folgende
Anforderungen sind für
eine objektorientierte Umgebung und eine Infrastruktur vorteilhaft,
in der ein Dienstsitzungsobjekt interagiert (beschrieben anhand
der CORBA-Umgebung):
-
Hinsichtlich
funktioneller Anforderungen sollte CORBA Folgendes vorsehen:
- – asynchrones
Aufrufmodell und Unterstützung für Gruppenkommunikation
im ORB;
- – geeignete
Programmeinstiegsmöglichkeiten
zur Erweiterung des ORB mit Sicherheits-, Transaktions- und Replikationsmechanismen;
- – Knotenmanagement
und Einrichtungen für
minimalen Objekt-Lebenszyklus;
- – einen
Zeitdienst und systemspezifische Überwachungseinrichtungen zum
Erfassen von Rechenereignissen und technischen Ereignissen;
- – Unterstützung für Multithreading
mit flexiblen Ereignis-auf-Thread-Abbildungen.
-
Die
nichtfunktionellen Anforderungen an CORBA betreffen:
- – Identifizierung
des Grades der Skalierbarkeit und Objektgranularität, den der
ORB im IN-Kontext erfüllen
sollte;
- – Identifizierung
des Leistungsniveaus, das der ORB in Bezug auf Latenzzeit, Durchsatz
usw. erreichen muss;
- – Vorsehen
eines prädiktiven
ORB-Kerns durch Instrumentierung und Dokumentierung des zeitlichen
Verhaltens der Plattform;
- – Zuverlässigkeit,
d.h. Anforderungen, die akzeptables Verhalten für die verteilten Anwendungen bei
Hardware-Ausfällen und
Softwarefehlern definieren. In diesem Fall können zwei Arten von Zuverlässigkeit
identifiziert werden, nämlich
Integritätszustand
und Verfügbarkeit;
- – Handhabbarkeit,
d.h. Anforderungen, die eine einfache Entwicklung, einfachen Aufbau
und einfachen Betrieb für
komplexe Anwendungen ermöglichen,
in diesem Fall Wartbarkeit, (Re)Konfigurierbarkeit und Erweiterbarkeit
von CORBA-Anwendungen.
-
Asynchrones
Aufrufmodell, wie es üblicherweise
von IN-Anwendungen
verwendet wird. Somit ist ein asynchrones und wahlweise isochrones
Aufrufmodell beim ORB erforderlich. Hier wird ein clientseitiges
Programmiermodell benötigt,
das potenziell einen „lightweight" asynchronen Kommunikationsmechanismus
unterstützt,
der einen obligatorischen Rückruf
(Mandatory Callback) (oder einen so genannten ORB-Upcall-Mechanismus)
und wahlweise ein „Futures"-Programmiermodell
enthält.
-
Für dasselbe
Objekt sollten asynchrone und synchrone Modelle koexistieren. Der
maximale Grad des Parallelbetriebs ist in der Konfiguration definiert (z.B.
QoS-Parameter) und muss steuerbar sein, mit der Möglichkeit,
die Anfrage in eine Schlange zu stellen und eine Ausnahme (Exception)
zurückzuschicken.
-
Eine
Fehlererkennungs-Grundunterstützung sollte
von der ORB-Ausführungssoftware
für jedes Objekt,
das diese benötigt,
bereitgestellt werden. Dies kann über einen Timer erfolgen, der
im Client-Prozess implizit eingestellt und verwaltet wird.
-
Flexibilität und Skalierbarkeit:
-
Der
ORB sollte in der Lage sein, Anwendungen zu unterstützen, die
eine große
Anzahl von Objekten bewältigen,
und viele gleichzeitige Verbindungen zu abgesetzten Objekten zu
unterstützen.
-
Der
Speicheraufwand für
einen Fernbezug auf eine Schnittstelle in einer bestimmten Kapsel (d.h.
einem Unix-Prozess) sollte in der Größenordnung eines Standardsprach-Pointers
liegen.
-
Eine
typische Telekommunikationsumgebung umfasst Objekte sehr verschiedener
Granularität
sowohl in Bezug auf Raum (Speichergröße) als auch in Bezug auf Zeit
(Objekt-Lebensdauer).
Ein skalierbarer ORB sollte Objekte in unterschiedlichen Granularitätsstufen
unterstützen
und das mit der Behandlung von kleinen und flüchtigen Objekten und mit der
Abwicklung von Verbindungen zu abgesetzten Objekten verbundene Overhead
zu minimieren. Um einen Teil der ORB-Fehlertoleranz und -Zuverlässigkeit
zu erreichen, könnte
das CORBA-Objektmodell so erweitert werden, dass es Gruppen von
Objekten wie die beschriebenen („Group Communication") unterstützt.
-
Zuverlässigkeit und Verfügbarkeit:
-
Um
die Zuverlässigkeitsanforderungen
zu erfüllen,
kann der Begriff der replizierten verteilten Objekte in CORBA eingeführt werden.
Damit werden die kritischen Komponenten der Anwendung über replizierte
Objekte implementiert. Dieses Replica-Management kann vom ORB automatisch
so durchgeführt
werden, dass mit einem bestimmten Serverobjekt interagierende Clienten
keine Kenntnis haben, ob dieses Objekt repliziert ist oder nicht.
Der Grad der Replizierung kann durch die gewünschte Stufe der Zuverlässigkeit
bestimmt werden, die mittels der maximalen Anzahl von gleichzeitigen
Ausfällen,
der Art des Ausfalls (bösartig
oder gutartig) und der Art der gewünschten Zuverlässigkeitseigenschaft,
wie z.B. Integrität
und Verfügbarkeit,
gemessen werden kann. CORBA sollte für verteilte IN-Systeme hohe
Verfügbarkeit
und Fehlertoleranzfähigkeiten
bereitstellen, um die gleiche Robustheit wie derzeitige IN-Systeme zu
gewährleisten.
-
Auch
zeitliche Anforderungen können
durch den Replica-Dienst
erfüllt
werden. Zum Beispiel werden Anwendungen, die begrenzte und voraussagbare
Verzögerungen
aufweisen müssen,
mittels replizierter Objekte implementiert. Jedes Replica ist in
der Lage, alle für
das Objekt definierten Methoden lokal zu verarbeiten. Ist kein Ausfall
vorhanden, kann ein Client jede der Antworten auf einen Methoden-Aufruf als
sein Ergebnis verwenden (die Aufrufe werden in diesem Fall synchron
durchgeführt).
Zu diesem Zweck erhält
der ORB eine modulare Struktur, die in Abhängigkeit von Anwendungs- oder
Dienstanforderungen die Implementierung von unterschiedlichen Profilen
ermöglicht.
Diese Profile stellen eine Abstraktion der vom zugrunde liegenden
Betriebssystem bereitgestellten Ressourcen dar. Eines der ORB-Module
ist dann ein Ausfalldetektor, der in der unteren Ebene der ORB-Struktur angeordnet
ist. Eine Antwortverzögerung
auf einen Aufruf, die eine bestimmte Schwelle überschreitet, wird als Ausfall
eingestuft. Somit ist ein Client in der Lage, Zuverlässigkeit
zugunsten von zeitlicher Genauigkeit zu opfern: Je kürzer die
Schwelle ist, umso enger sind die Grenzen der Verzögerung.
Durch ausreichend häufige
Replizierung des Objekts ist der Client in der Lage, sowohl zeitliche
Anforderungen als auch Zuverlässigkeitsanforderungen
gleichzeitig zu erfüllen.
-
Hier
wurden Anforderungen an einen Replikationsdienst mit Korrektheits-,
Sicherheits- und „Liveness"-Eigenschaften identifiziert,
sowie ein Ausfalldetektormodul, das Teil des ORB-Kerns ist.
-
Leistung:
-
Die
Leistung eines IN wird in der Anzahl von Anrufen pro Sekunde für Dienstknoten
und intelligente periphere Geräte
und in der Anzahl von Transaktionen pro Sekunde für Signalsteuerungspunkte
gemessen. Bei diesen Anrufen und Transaktionen kann es sich um zwischen
einem SSP und der Intelligenten Schicht ausgetauschte gekettete
Nachrichten handeln. Um die tatsächliche
Leistung von älteren IN-Systemen
zu erhalten, ist die Echtzeitleistung des ORB für die Verwendung von verteilter
Datenverarbeitung in IN-Systemen sowie dessen Verteilung im geographischen
Maßstab
(dezentrale IN-Systeme) erforderlich. Zur Erzielung einer besseren
Leistung für
verteilte IN-Systeme sollte das ORB-Anruf-Overhead reduziert und
das Leistungsniveau, das der ORB in Bezug auf Latenzzeit, Durchsatz
usw. erreichen muss, definiert und dokumentiert werden.