-
EINLEITUNG
-
Gebiet der
Erfindung
-
Die
Erfindung betrifft ein Gateway zum Erlauben einer Interaktion von
Netzwerkbetriebsmitteln (beispielsweise HLR, SMSC oder eine IVR-Plattform) eines
Operators mit Anwendungen zur Bereitstellung von Benutzerdiensten.
-
Stand-der-Technik-Diskussion
-
Es
ist für
Netzwerkteilnehmerdienste bekannt, durch Anwendungen bereitgestellt
zu sein. Jedoch sind bisher solche Anwendungen typischerweise im
Netzwerk des Operators untergebracht bzw. gehostet worden, beispielsweise
Vorausbezahlungs- bzw. Pre-paid-, Rufumleitungs- bzw. Call-forwarding- oder
Sprachpost- bzw. Voice-mail-Dienste. Ein Problem bei dieser Methode
ist, dass detaillierte Kenntnis der besonderen Systeme erforderlich
ist, um sie für
die erforderliche Interaktion zu programmieren. Dies ist zeitraubend
und teuer und erlaubt eine begrenzte Flexibilität.
-
Dies
ist einer der Gründe,
warum der „Parlay"-Standard zum Bereitstellen
eines Mechanismus für
offene APIs entwickelt wurde, der entweder im oder ohne das Netzwerk
lokalisierten Anwendungen erlaubt, auf Netzknoten zuzugreifen. Während dies eine
wichtige Entwicklung ist, gibt es einen Bedarf nach einem Netzübergang
bzw. Gateway zum Gebrauchmachen vom Parlay-Standard, um eine einfache und flexible
Verknüpfung
von Netzknoten mit Anwendungen mit minimaler Vorlaufzeit zu erlauben. Die
Erzielung einer kurzen Vorlaufzeit ist besonders wichtig für Netzoperatoren,
da sie danach streben, eine immer zunehmende Vielfalt von Teilnehmerdiensten
bereitzustellen, um Teilnehmerzahlen und zunehmende Einnahmen aufrechtzuerhalten.
-
WO
0022 792 beschreibt ein Verfahren zur Steuerung und Verwaltung von
Sprachen- und Datendiensten in einem Telekommunikationsnetz.
-
Die
internationale Patentanmeldung Nr. WO 00/42760 (Ericsson) beschreibt
ein Verfahren zum Zugriff auf einen Dienstknoten von einem Netzwerk-Endanschluss
bzw. -Endgerät,
bei dem das Netzwerk einen VoIP-Abschnitt und einen Zellularabschnitt
aufweist. Während
dies als für
das VoIP involvierende besondere Erfordernis effektiv erscheint, gibt
es einen Bedarf nach einem Gateway zum Erlauben eines flüchtigen
Zugriffs durch einen weiten Bereich von Anwendungen zu einem weiten
Bereich von Netzwerkbetriebsmitteln.
-
Diese
Erfindung ist auf die Bereitstellung eines solchen Gateways gerichtet.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Gemäß der Erfindung
ist ein Gateway für eine
Interaktion von Anwendungen mit Telekommunikationsnetzbetriebsmitteln
bereitgestellt, wobei das Gateway Mittel für einen Anschluss an die genannten Anwendungen
und Mittel für
einen Anschluss an die genannten Netzwerkbetriebsmittel umfasst,
dadurch gekennzeichnet, dass
das Netzwerkanschlussmittel aufweist:
- eine Außenschicht
von Netzdiensteschnittstellen, umfassend Mittel für einen
Anschluss an und zum Steuern von Netzbetriebsmitteln, und
- eine Innenschicht von Open-Standard-APIs, umfassend Mittel für einen
Anschluss an Netzbetriebsmittel mit entsprechenden Open-Standard-APIs
und für
einen Anschluss an Netzdiensteschnittstellen der Außenschicht.
-
Bei
einer Ausführungsform
umfasst das Gateway ferner einen Middleware-Bus, der sich zwischen
dem genannten Anwendungsanschlussmittel und der Innenschicht des
genannten Netzwerkanschlussmittels befindet.
-
Bei
einer anderen Ausführungsform
entspricht der genannte Middleware-Bus dem CORBA-Standard.
-
Bei
einer weiteren Ausführungsform
umfasst das Gateway ein Service-Gateway, umfassend Open-Standard-Dienste
der Innenschicht, Service-Level-Programme der Außenschicht und Mittel zum Verwalten
der Interaktion zwischen den Service-Level-Programmen und dem Netzwerkverkehr.
-
Bei
einer Ausführungsform
umfassen die Service-Layer-Programme Mittel zum Bereitstellen von
Rufstatusmaschinen zum Verwalten von Kommunikationsdialogen.
-
Bei
einer anderen Ausführungsform
umfasst das Service-Gateway einen Notificationsdemultiplexer, der
Mittel zum Versenden von Netzwerknotifications bzw. -benachrichtigungen
zu den Service-Logik-Programmen und zu Anwendungen umfasst.
-
Bei
einer weiteren Ausführungsform
umfasst die Außenschicht
ein Netzwerk-Gateway, das Signalgabestapel und Mittel zum Durchführen einer
Translation zwischen den genannten Stapeln und den Service-Logik-Programmen
des Service-Gateways umfasst.
-
Bei
einer Ausführungsform
umfasst die Innenschicht:
- eine Open-Standard-Gerüstschnittstelle
zum Middleware-Bus,
und
- eine Open-Standard-Service-Schnittstelle zum Middleware-Bus für die Interaktion
mit Anwendungen.
-
Bei
einer Ausführungsform
umfasst das Gateway ein Gerüst,
das Management-, Provisioning-, Subscription- und Sicherheitsfunktionen
zur Außenschicht
und zur Innenschicht umfasst.
-
Bei
einer anderen Ausführungsform
umfasst das Gateway Plattformbetriebsmittel zum Bereitstellen der
folgenden Funktionen für
die Innenschicht und die Außenschicht:
- einen Dauerdatenspeicher für
Steuer- und Konfigurationstabellen, und
- eine Kommunikationsfunktion für die interne Kommunikation,
die keinen verteilten Objekt-Middleware-Kommunikationsmechanismus verwendet,
und
- einen Eventmanager, der eine Standardschnittstelle zu Funktionen
innerhalb des Gateways bereitstellt, um Ereignisse bzw. Events zu
empfangen, empfangene Events in Information-, Fehler- und typische
Kategorien zu klassifizieren und die Events zu protokollieren.
-
Bei
einer Ausführungsform
umfassen die Plattenformbetriebsmittel ferner eine Zeitfunktion, umfassend
Mittel zum Aufrufen und Abbrechen von Zeitgebern bzw. Timern für Funktionen
des Gateways.
-
Bei
einer Ausführungsform
umfasst das Gateway:
- eine Managemententität zum Leiten
von Gateway-Managementsignalen,
- einen Webserver, der mit der Managemententität verbunden ist und Mittel
für die
Kommunikation mit Managementschnittstellen auf separaten Hardware-Plattformen
umfasst,
- einen Plattformmanager, der mit der Managemententität verbunden
ist und Mittel zum Steuern des Hoch- und Herunterfahrens einer primären Hardware-Plattform
für die
Innenschicht und die Außenschicht
umfasst.
-
Bei
einer Ausführungsform
umfasst das Mittel für
den Anschluss an die Anwendungen eine anwendungsseitige Schicht
von Komponenten mit einer Anwendungsschnittstelle und Logik und
eine netzwerkseitige Schicht, die Open-Standard-APIs zur Kommunikation
mit den Open-Standard-RPIs der inneren Schicht umfasst.
-
Bei
einer anderen Ausführungsform
liegen die anwendungsseitige Schicht und die netzwerkseitige Schicht
auf einer Plattform für
jede Anwendung vor, und die genannten Plattformen sind fern von
einer Plattform der Innenschicht und der Außenschicht.
-
Bei
einer anderen Ausführungsform
umfasst die anwendungsseitige Schicht wiederverwendbare Objekte
und Mittel zum Instanziieren der Objekte zum Bereitstellen einer
Komponente.
-
Bei
einer Ausführungsform
umfasst das Instanziierungsmittel einen XML-Interpreter, der Mittel zum
Interpretieren von Benutzereingaben von High-Level-Anschlussbefehlen
umfasst.
-
Gemäß einem
anderen Aspekt ist ein Anwendungsclient für einen Anschluss zwischen
einer Anwendung und Gateway-Open-Standard-APIs zum Bereitstellen von Zugang zu
Netzwerkbetriebsmitteln bereitgestellt, wobei der Client folgendes
umfasst:
- einen Kern von Open-Standard-APIs und
- wiederverwendbare Objekte und Mittel zum Instanziieren der genannten
Objekte, um Komponenten Logik und eine Anwendungsschnittstelle zu
geben.
-
Bei
einer Ausführungsform
umfasst das Instanziierungsmittel einen XML-Interpreter und eine Benutzeroberfläche zum
Leiten der Eingaben von High-Level-XML-Befehlen, die Schnittstellenanforderungen
definieren.
-
Bei
einer anderen Ausführungsform
umfasst der Anwendungsclient ferner wiederverwendbare Utility-Objekte
sowie Mittel zum Instanziieren der genannten Objekte, um Komponenten
für Protokollier-, Verfolgungs-,
Datenbankzugriffs- und Zeitfunktionen bereitzustellen.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
Kurze Beschreibung
der Zeichnungen
-
Die
Erfindung wird von der folgenden Beschreibung einiger ihrer Ausführungsformen
deutlicher verstanden, die nur beispielhaft gegeben ist unter Bezugnahme
auf die beigefügten
Zeichnungen, in denen:
-
1 ein
Diagramm ist, das den Kontext eines Gateways der Erfindung illustriert;
-
2 ein
Diagramm ist, das die logische Struktur des Gateways illustriert;
-
3 ein
Diagramm ist, das eine netzwerkseitige Struktur des Gateways im
Detail illustriert; und
-
4 ein
Diagramm ist, das eine anwendungsseitige Struktur des Gateways im
Detail illustriert.
-
Beschreibung
der Ausführungsformen
-
Bezugnehmend
auf die 1 interagiert ein Gateway 1 auf
einer Seite mit Netzwerken 2 eines oder mehrerer Operatoren.
Die Netzwerke 2 umfassen sowohl Festleitungs- als auch
Drahtlos-Netzwerke, obgleich sie von nur einem solchen Typ sein
können.
Diese Seite des Gateways 1 ist schließlich an Teilnehmer- bzw. Subscriber-Mobiltelefone 2 bzw. 3, Computer 4 und
andere Benutzereinrichtungen angeschlossen. Auf einer Anwendungsseite
ist das Gateway 1 mit von bzw. bei den Netz werk-Operatoren
untergebrachten bzw. gehosteten Anwendungen 10 und (über eine
Brandmauer bzw. Firewall 11 und das Internet 12)
mit von bzw. bei ASPs gehosteten kommerziellen Portalanwendungen 13 und
mit Firmenanwendungen in einem Intranet 14 in Schnittstellenverbindung
bzw. -anschluss.
-
Mehr
im Detail umfassen unter Bezugnahme auf die 2 in einem
illustrativen Beispiel die Anwendungen 10, 13 und 14 freie „0800"-Dienste, ein Luftverkehrslinienflugportal
und ein Einkaufsportal. Auf der Netzwerkseite 3 umfassen
die Netzwerkknoten ein HLR, MSCs und SMSC. Das Gateway 1 weist eine
Vierschichtstruktur aus Schichten 20, 21, 23 und 24 und
einen zentralen COBRA-Bus 22 auf. Der Zweck des Gateways 1 ist,
den Anwendungen Zugriff zu den Netzwerkressourcen bzw. – betriebsmitteln
zu erlauben.
-
Die
Schicht 20 umfasst Schnittstellenkomponenten, konfiguriert,
um den Anwendungen zu genügen.
Jede Schnittstellenkomponente umfasst eine Anwendungsschnittstelle,
eine Parlay-Schnittstelle und
eine Logik dazwischen.
-
Die
Schichten 21 und 23 umfassen jeweils offene Parlay-APIs
bzw. Open-Parlay-APIs, in der Schicht 21 geeignet zum Schnittstellen-Anschluss
an die Schicht-20-Komponenten-Parlay-Schnittstellen, und in der Schicht 23 geeignet
zum Netzwerkknotenanschluss. Solche APIs sind auf einem abstrakten
Niveau bzw. Level in den Parlay-Spezifikationen spezifiziert.
-
Die
Schicht 24 umfasst Netzwerkdiensteschnittstellen zum Schnittstellen-Anschluss
an und Steuern von Netzwerkbetriebsmitteln. Infolgedessen gibt es
auf einem hohen Level Symmetrie des Gateways um den CORBA-Bus 22 herum,
wobei letzterer Middleware zwischen den Parlay-APIs bereitstellt.
-
Wie
durch die Pfeile dargestellt sind einige der Anwendungen an die
Schicht 20 schnittstellenangeschlossen, während andere eine
Parlay-API aufweisen und so direkt an die Schicht 21 angeschlossen
sind. Ähnlich
sind einige der Netzwerkknoten an die Schicht 24 und andere
direkt an die Parlay-APIs in der Schicht 23 angeschlossen.
Jedoch gehen alle Interaktionen direkt oder indirekt durch die Parlay-Schichten 21 und 23,
und so wirken diese Schichten und der CORBA-Bus 22 als
ein zentraler Middlewarekern des Gateways 1.
-
Bezugnehmend
nun auf die 3 umfasst das Gatway 1 eine
die Schichten 23 und 24 und den CORBA-Bus 22 bereitstellende
Plattform. OA & M-Systeme 28 sind
mit der Plattform verbunden. Die oberen Schichten 20 und 21 residieren
in mit dem CORBA-Bus 22 verbundenen separaten Computern.
-
Diese
OA & M-Systeme 28 umfassen
einen Unternehmens-Operator 28A, einen Dienst- bzw. Service-Lieferant 28B,
einen Gerüst-Operator 28C, eine
Managementbenutzerschnittstelle 28D und ein externes Operatorsystem 28E.
-
Die
Schicht 24 ist primär
durch ein Netzwerk-Gateway 31 und durch Dienstlogikprogramme in
einem Dienst- bzw. Service-Gateway 32 implementiert.
Die Schicht 23 ist primär
durch Dienste und eine Parlay-Schnittstelle 41 im Service-Gateway 32 und
durch eine Gerüst-Parlay-Schnittstelle 40 in
einem Rahmenwerk bzw. Gerüst
(framework) 36 implementiert.
-
Auch
wird auf beide Schichten 22 und 24 von den verschiedenen
OA & M-Systemen 28 indirekt
zugegriffen. Auch umfasst die Plattform einen Web-Server 30,
einen Plattformbetriebsmittelbus 35, Plattformbetriebsmittel 37,
Plattformmanager 38 und eine Managemententität 39.
-
Die
Plattformbetriebsmittel 37 umfassen einen CORBA-Eventmanager 37A und
einen CORBA-Alarmmanager 37B.
-
Die
Betriebsmittel 37 umfassen auch Nicht-CORBA-APIs wie folgt:
- Datenbank-API 37C,
- Kommunikationen-API 37D,
- Zeitgeber-API 37E,
- Speichermanager-API 37F,
- Konfigurationsparameter-API 37G und
- Ablaufverfolgungs/Protokoll-API 37H.
-
Der
Manager 38 umfasst einen Plattformmanager 38A,
einen Accountmanager 38B, ein Netzwerkmanagement-MIB 38C und
einen Netzwerkbetriebsmittelmanager 38D.
-
Das
Folgende beschreibt die Schichten 23 und 24 detaillierter.
Das Gerüst 36 und
das Service-Gateway 32 sind jeweils mit dem CORBR-Bus 22 durch
Parlay-Schnittstellen 40 bzw. 41 verbunden. Jede
Parlay-Schnittstelle stellt eine API und Schnittstelleninstanziierung
für externen
Zugriff bereit. Zwei Schnittstellenkategorien sind vorgesehen. Die
Parlay-Gerüst-Schnittstelle 40 stellt
Umgebungsfähigkeiten
bereit, die das Management der Dienst- bzw. Service-Schnittstellen 41 unterstützen und
Anwendungen mit sicherem und vertraulichen Zugriff und Entdeckung
der bereitgestellten Dienste bereitstellen. Die Parlay-Service-Schnittstelle 41 stellt
Anwendungen mit einer abstrahierten Programmierungs-API einem Bereich
von Netzwerkdiensten und Information bereit.
-
Gerüst 36
-
Das
Gerüst 36 stellt
eine gemeinsame Dienstfunktionalität als wiederverwendbare Dienstelemente
bereit. Das Gerüst 36 stellt
das folgende bereit:
- – Management: Einfache Gerüstmanagement- und
Dienstmanagementaufgaben wie beispielsweise Schnittstellenverbindung
zwischen Diensten und Parlay-Management und externen Managemtsystemen 28,
die Diensteinsatz und -konfiguration, Dienststart und Dienststopp
bereitstellen. Bei Einsatz des Dienstes werden Managementdatenbanktabellen
und Kommunikationskanäle
mit Plattformbetriebsmitteln 37, dem Service-Gateway 32 und
dem Netzwerk-Gateway 31 erzeugt.
- – Bereitstellung:
Definition von Dienstkonfigurationsparametern für die Parlay-APIs der Schicht 23 auf
entweder einer globalen Basis oder einer begrenzten Adressierung
oder einem Benutzergruppenbereich wie beispielsweise Einstellungslevel für Event-
und Alarmmanagement. Außerdem
erlaubt eine gemeinsame Bereitstellung, dass sich verwandte Dienste
eine gemeinsame Bereitstellungsstrategie teilen.
- – Subscription:
Registrierung von Benutzern für Dienstgebrauch,
darunter Setzen von Triggerevents von Interesse für die Anwendungsoperation.
Da dies eine gemeinsame Subscriptionsschnittstelle ist, stellt sie
eine gleichförmige
Methode für
verschiedenen Diensten zugeordnete Benutzer bereit.
- – Sicherheit:
Das Gerüst 36 umfasst
eine Sicherheitsschnittstelle mit Industriestandard-Sicherheitsalgorithmen.
-
Das
Gerüst 36 ist
dauernd. Das heißt,
wenn aus irgendeinem Grund das Gateway 1 abgemeldet wird,
dann werden, wenn das Gerüst
in einen aktiven Status zurückgebracht
wird, alle Trigger, Anmeldungen bzw. Subscriptionen und andere Einstellungen wiederhergestelltt.
-
Service-Gateway 32
-
Das
Service-Gateway 32 verwaltet bzw. managt eine Interaktion
zwischen den (Schicht-24-)Dienstlogikprogrammen und dem über das
Netzwerk-Gateway 31 abgegebenen Netzwerkverkehr. Um dies
zu erreichen, stützt
das Service-Gateway 32 das für einen besonderen Parlay-Service
bzw. -Dienst (der Schicht 23) für ein gegebenes Netzwerkbetriebsmittelprotokoll
erforderliche Statusmodell. Beispielsweise können im Service-Gateway 32 ausgeführte Rufsteuerdienste
Meldungen zu und vom Netzwerk-Gateway 31 über ein geeignetes
Service- bzw. Dienstlogikprogramm senden und empfangen. Dieser abstrakte
Rufsteuerdienst kann zur Verwendung mit INAP, SIP usw. bereitgestellt
und konfiguriert sein. Die Dienstlogikprogramme im Service-Gateway 32 stellen
INAP- und SIP-Basisrufstatusmaschinen bereit, um den Kommunikationsdialog
zu managen.
-
Das
Service-Gateway 32 verwendet die im Gerüst 36 bereitgestellte
Funktionalität
(Subscription, Bereitstellung usw.), um die Zuordnung zwischen den
subscribierten Triggerevents der Anwendungen und den (Schicht-23-)Parlay-Dienstfällen zu
den (Schicht-24-)Dienstlogikprogrammen zu managen, wobei
Dienstsubscriptionen effektiv gemultiplext werden.
-
Das
Service-Gateway 32 stellt auf diese Weise einen Notifikationsdemultiplexer
bereit, der Netzwerknotifikationen zuerst für das geeignete Servicelogikprogramm
und, falls erforderlich, für
die Anwendung absetzt bzw, abfertigt.
-
Netzwerk-Gateway 31
-
Das
Netzwerk-Gateway 31 implementiert eine Transaktion zwischen
verkäuferzugeführten Stapelgrundelementen
und den Dienstlogikprogrammen des Service-Gateways 32.
Es managt auch die Transaktions- oder Dialogzuordnungen für neue laufende
Kommunikationen zwischen den Netzwerken und den Diensten.
-
Die
Konfiguration des Netzwerk-Gateways 31 stellt konsistente
Abbildungen zwischen im Service-Gateway 32 ausgeführten Dienstlogikprogrammen
und den mit dem Gateway 1 in Schnittstellenverbindung stehenden
Netzwerkbetriebsmitteln.
-
Eine
Kombination der Service-Gateway 32-Dienstlogikprogramme
und Funktionalität
des Netzwerk-Gateways 31 stellt die Schicht-24-Netzwerk-Serviceschnittstellen
zur Schnittstellenverbindung mit den und Steuerung der Netzwerkbetriebsmittel
bereit.
-
Plattformbetriebsmittel
37
-
Diese
sind generische Stützbetriebsmittel zum
Zugriff und zur Verwendung durch die anderen funktionellen Komponenten
des Gateways. Diese werden von den generischen Gerüstbetriebsmitteln separat
betrachtet, da sie auf die Ausführung
der Dienste allein nicht beschränkt
sind. Das folgende sind die Plattformbetriebsmittel:
- – Datenbank 37C:
Ein Dauerdatenbankspeicher für
alle Steuer- und Konfigurationstabellen stellt Bereitstellungsdaten
und Subscriptionsdaten bereit. Wenn außerdem die Ausführung des
Dienstes auch eine dauerhafte Datenspeicherung erfordert, kann der
Dienst Gebrauch von der Datenbank 37C über eine bekanntgemachte API
machen.
- – Kommunikationen 37D:
Das Gateway 1 verwendet CORBA-Kommunikationen in der Architektur, um
eine verteilte Lösung
zu realisieren. Jedoch benötigen
nicht alle Interprozess-Kommunikationen die Verwendung von CORBA,
und eine Kommunikationenbibliothek und eine Programmierungsschnittstelle
wird zum Sichern einer konsistenten und portablen Implementierung
aller Kommunikationen auf dem Gateway 1 verwendet. Dieses
Betriebsmittel ist verantwortlich für Managing und Steuerung der
Kommunikationswarteschlangen und -sockel in einer plattformunabhängigen Weise.
- – Eventmanager 37A:
Die Komponenten des Gateways 1 erzeugen Events, um eine
Anzeige ihrer Operation bereitzustellen. Der Eventmanager 37A stellt
eine Standardschnittstelle für
alle Komponenten zu Protokollevents in einer konsistenten Weise
bereit. Er sammelt die Events und managt die Protokollierung des
Events zu den Protokollen. Der Eventmanager 37A stützt die
folgenden Eventklassifikationen:
1. Information
2. Fehler
3.
Kritisches
Die Klassifikation des Events ist durch die das Event
erzeugende Komponente nicht bekannt, vielmehr verwendet der Eventmanager
eine konfigurable Eventmanagementtabelle, um die Eventdetails zu
definieren. Auf diese Weise können Events über die
Eventmanagementtabelle neu klassifiziert werden. Die Tabelle kann
auch zum Steuern des Bestimmungsprotokolls für das Event und Definieren
zusätzlichen
Eventinformationstextes, der im Eventprotokoll enthalten zu sein hat,
verwendet werden.
Durch die Eventmanagementtabelle können Events
als „gebührenpflichtig" definiert werden,
in welchem Fall das Event als für
Rechnungserstellung bzw. Gebührenerfassung
geeignet betrachtet werden soll und auf ein Gebührenerfassungsprotokoll für eine spätere Gebührenerfassungsverarbeitung
geschrieben werden soll. Die Gebührenerfassungsstrategie
dient zur Erzeugung von Gebührenerfassungsprotokollen
und Reihendaten zur Gebührenerfassungsverarbeitung.
Der Inhalt dieser Gebührenerfassungsprotokolle
ist durch den Gateway-Operator über
die Managemententität 39 konfigurierbar.
Die Gebührenerfassungsprotokolle
können
dann einem Interpolationssystem zugeführt werden, um die Gebührenaufzeichnungen
zur Eingabe in ein Kundengebührenerfassungssystem
zu erzeugen. Eine vollständige
Gebührenerfassungsflexibilität ist deshalb dem
Operator des Gateways verfügbar.
Alle
Events weisen einen in der Eventmanagementtabelle definierten konfigurierbaren
Eventlevel auf. Das Gateway 1 kann vom Operator zum Stützen eines
Eventschwellenlevels konfiguriert werden. Durch nur Stützen der
Protokollierung von Events durch den Eventmanager für die unter der
Eventlevelschwelle liegenden kann die gesamte Eventprotokollierung
dynamisch gesteuert werden.
- – Alarmmanager 37B:
Der Alarmmanager 37B ist ein spezieller Fall des Eventmanagers.
Er stellt eine Standardalarm-API und viele der gleichen konfigurierbaren
Eigenschaften wie der oben beschriebene Eventmanager bereit. Jedoch
wird er als eine vom Eventmanager separate Funktion seiend betrachtet,
da der Alarmmanager 37B auch mit von den darunter liegenden
Netzwerkbetriebsmitteln erzeugten und durch das Netzwerk-Gateway 31 gefilterten
Alarmen versorgt. Wenn außerdem
die Netzwerke, Dienste oder anderen Komponenten einen Alarm auslösen, soll der
Alarmmanager 37B zusätzlich
zur Protokollierung des Alarms, falls erforderlich, auch den Alarm
der externen Managementbenutzerschnittstelle 28D und dem
Netzwerkmanagement MIB 38C über die Managemententität 29 mitteilen. Eine
konfigurierbare Alarmmanagementtabelle wird zum Definieren von Alarmklassifikationen und
zur Mitteilung verwendet.
- – Zeitgeber 37E:
Viele der Kommunikationendialoge beim Betrieb im Gateway erfordern
die Verwendung von Zeitgebern zum Sicherstellen, dass Systembetriebsmittel
als ein Resultat eines Ausfalls nicht gesperrt werden, um den erwarteten
Dialog zu vollenden oder fortzuführen.
Die Gateway-Plattform umfasst eine generische, plattformunabhängige Zeitgebermanagementfunktions- und
Programmierungs-API. Diese wird zum Aufrufen und Beseitigen von
Zeitgebern und Anzeigen, wenn Zeitgeber abgelaufen sind, verwendet. Die
exakten Zeitgeberwerte sind über
eine Zeitgebermanagementtabelle konfigurierbar.
- – Speichermanager 37F:
Dieser standardisiert und vereinfacht alle auf der Plattform ausgeführten dynamischen
Speicheroperationen. Dieses Betriebsmittel dient primär zum Vereinfachen
einer Tragbarkeit über
mehrfache Hardwareplattformen.
- – Cparams 37G:
Das Gateway 1 umfasst eine Cparams-Bibliothek (Cparams = common configurable
parameters = gemeinsam konfigurierbare Parameter). Alle Prozesse,
die eine Konfiguration erfordern, verwenden dieses gemeinsame Betriebsmittel,
und die Einstellungen der Parameterwerte selbst und die Fähigkeit
zum Auffrischen der laufenden Konfiguration der individuellen Prozesse
werden über
die Managemententität 39 gesteuert.
- – Ablaufverfolgung/Protokollierung 37B:
Informelle Meldungen hinsichtlich der Operation der Gatewaykomponenten
können
durch diese Funktion zur Inspektion durch den Gateway-Operator bereitgestellt
werden. Zusätzlich
können
der Level und die aufgezeichnete Informationsmenge auf einer individuellen
Prozessbasis durch die Verwendung der Cparams konfiguriert werden,
was erlaubt, dass der Grad der Ablaufverfolgung und Protokollierung
dynamisch gesteuert werden kann.
-
Managemententität 39
-
Die
Managemententität 39 ist
für das
Managing und die Konfiguration aller Schlüsselprozesse und Komponenten
in der Plattform verantwortlich. Die Managemententität ist selbst
ein Prozess und stellt eine HTTP-Schnittstelle der Managementbenutzerschnittstelle über dem
Gateway-WEB-Server 30 bereit. Die von der Managemententität 39 bereitgestellte
Hauptfunktionalität
ist:
- – Plattformbetriebsmittel:
Die Managementidentität 29 bzw. 39 schnittstellenverbindet
die Plattform-Betriebsmittel, um alle Datenbank- und Konfigurationsdaten
zu managen und mit den Event- und Alarmmanagern zu interagieren,
um die Abgabe relevanter Information an die erforderliche Bestimmung
(beispielsweise GUI, externe Systeme usw.) sicherzustellen.
Das
Gateway 1 ist über
die Managemententität hoch
bzw. stark konfigurierbar. Dies liefert dem Gateway-Operator eine
maximale Steuerung über
die Plattformoperation. Jeder konfigurierbare Parameter weist einen
Voreinstellungswert (während
der Installation eingestellt und während des Prozesshochfahrens
verwendet) und einen Bereich zulässiger
Werte auf.
- – Plattformmanager 38A:
Der Plattformmanager 38A ist für das Hochfahren/Herunterfahren
des Gateways selbst und das Management von Plattformbetriebsmitteln
wie beispielsweise der Datenbank verantwortlich. Außerdem stellt
der Plattformmanager eine Prozessmanagentsteuerung bereit, die das
folgende umfasst:
Prozess-Hochfahren/Herunterfahren.
Prozessstatusüberwachung.
Der Plattformmanager 38A soll einen automatischen Prozessneustart
versuchen, wenn er konfiguriert ist, diesen auszuführen.
Prozessablaufverfolgungssteuerung.
Stellt einen Mechanismus zum Stützen
eines Stabs zum Konfigurieren des für Fehlersuche vorgesehenen
Ablaufverfolgungslevels bereit.
Prozessstatistikensteuerung.
Ein Mechanismus zur Erzielung von Zählern zu Prozessoperation und
-verkehr bei Befehlen oder bei regulären konfigurierbaren Intervallen.
- – Accountmanager 38B:
Bereitstellung einer Grundaccountmanagementstütze für die externen Benutzer, die
Zugriff auf das Gateway benötigen. Jeder
externe Benutzer kann so klassifiziert werden, dass er verschiedene
Kategorien eines Zugriffs zum Gateway bereitstellt. Der Accountmanager 38B ist
für die
Bereitstellung des geeigneten Parlay-Schnittstellen-Zugriffs zu
solchen Accounts, die für
eine Gatewaybenutzung validiert worden sind, verantwortlich.
- – Netzwerk-Management
MIB 38C: Ein für
direkte Kommunizierbarkeit mit externen OA & M-Systemen, und SNMP definiertes
MIB ist bereitgestellt.
- – Netzwerkbetriebsmittel-Manager 38D:
Jedes gestützte
Netzwerkbetriebsmittel soll einen herstellerspezifischen bzw. geschlossenen
Mechanismus zur Konfiguration des Betriebsmittels und Abfrage des
laufenden Betriebsmittelstatus bereitstellen. Der Netzwerkbetriebsmittel-Manager stellt
einen gemeinsamen und konsistenten Überblick über alle darunter liegenden
Netzwerkbetriebsmittel bereit.
-
WEB-Server:
Zusätzlich
zur Plattform und zum Prozessmanagement, die von der Managementidentität 39 bereitgestellt
sind, umfasst das Gateway 1 einen WEB-Server 30,
um die Managementschnittstellen zu stützen. Die Managementsysteme
kommunizieren mit den WEB-Serverschnittstellen über HTTP. Die WEB-Managementschnittstellen verwenden
eine Kombination aus JSP's,
Java Beans und Servlets. Diese Lösung
erlaubt den Managementschnittstellen, von der Causeway-Plattform
verteilt zu werden, falls erforderlich. Eine Kommunikation zwischen
der Schnittstellenmanagementlogik, repräsentiert durch die Servlets
und die Parlay-Schnittstellen, gestützt vom Gerüst- und Service-Gateway, wird über CORBA
für den
Gerüst-Operator,
Unternehmens-Operator und Dienstlieferant-Schnittstellen, definiert
in dem Parlay-Spezifikationen, durchgeführt. Zusätzlich kommuniziert die zum
Anschließen Schnittstellenverbinden
der Managementbenutzerschnittstelle 28D erforderliche Managementlogik
mit der Managemententität 39 über ein
Eigentums- bzw. herstellerspezifisches bzw. geschlossenes internes Managementprotokoll.
-
Das
folgende beschreibt das externe Managementsystem 28.
-
Management-Benutzer-Schnittstelle
28D
-
Stellt
ein grundlegende Benutzerschnittstelle zum Steuern des Managements
und der Konfiguration des Gateways 1 bereit. Zusätzlich zu
einer GUI zum Ausführen
von Standardbefehlen und Anzeigeresultaten ist auch eine scriptbasierte
Komponente enthalten, um eine schnelle Installation und Konfiguration
des Gateways zu erlauben. Die Managementbenutzerschnittstelle 28D betrifft
primär
Plattformoperation und ist stark mit dem über die Managemententität 39 und
den Plattformbetriebsmitteln 37 bereitgestellten Funktionen
verbunden.
-
Gerüst-Operator 28C
-
Stützt die
grundlegende Konfiguration der Parlay-Schnittstelle 40 und
ist für
das Managing und die Spezifizierung der Diensttypen, die im Service-Gateway 32 gestützt sind
und auf die über
die Parlay-Schnittstelle 40 zugegriffen werden kann, verantwortlich.
-
Service-Lieferant 28B
-
Erlaubt
Implementierungen von mit der Parlay-Gerüstschnittstelle 40 registrierten
Diensten.
-
Unternehmens-Operator
28A
-
Repräsentiert
den Diensteprovider als eine logisch separate Entität vom darunter
liegenden Netzwerk-Operator. Obgleich der Unternehmens-Operator 28A auch
der Gateway- und Netzwerk-Operator sein kann, bringt diese logische
Separation die Möglichkeit
zum Öffnen
neuer Geschäftsbeziehungen
ein. Diese optionale Separation zwischen Netzwerk-Operator und Service-Lieferer
stellt eine Stütze
für Dienstegroßhandel
(ASPs) und virtuellen Netzwerk-Operatorbeziehungen bereit und erlaubt
großen
Körperschafts-
oder Schlüsselaccounts die
Fähigkeit,
die Dienste mehr unter Kontrolle zu bekommen und ihren Gebrauch
auf spezielle Notwendigkeiten zuzuschneidern.
-
Die
Unternehmens-Operator-28A-Rolle im Gateway 1 ist
ungeachtet dessen, ob es eine logische Geschäftsunterscheidung gibt, erforderlich.
Der Unternehmens-Operator 28A ist für Erzeugung und Managing der
Dienstkontrakte und Subscriptionsaccounts und Beziehungen zwischen
Anwendungen und den Diensten, die sie zu benutzen wünschen, verantwortlich.
Eine hierarchische Subscriptionstopologie wird durch die Verwendung
von Dienstprofilen und Subscriptionszuordnungsgruppen derart gestützt, dass
Gruppen ähnlicher
Anwendungsbenutzer Zugriff auf die gleiche Gruppierung von Diensten
haben können.
-
Der
Unternehmens-Operator 28A erzeugt gültige Subscriptionsaccounts,
bevor eine Anwendung von Netzwerkdiensten, auf die durch die Parlay-Schnittstelle 40 zugegriffen
werden kann, Gebrauch machen kann.
-
Wieder
sich der Anwendungsseite zuwendend führen die Anwendungen 10, 13 und 14 die
Logik zum Bereitstellen der vom Endbenutzer oder Client benötigten Anwendungserfahrung
aus. Die Anwendungen können
lokal im Gateway 1 ausgeführt werden, wenn der Operator
volle Anwendungslösungen
auf einer einzelnen Plattform bereitzustellen wünscht, oder (wie dargestellt)
entfernt vom Gateway 1 und unter Verwendung von CORBA zur
Kommunikation.
-
Die
Anwendungen 10, 13 und 14 managen die
Parlay-Kommunikation zwischen der Anwendung und der Parlay-Schnittstelle 40,
um einen Parlay-Gerüst-36-Zugriff
und eine Dienstentdeckung zu erhalten. Wenn einmal ein geeigneter
Dienst zur Verwendung gewählt
worden ist, interagiert auch die Anwendung mit dem Dienst über die
Parlay-Schnittstelle 41, um die von der Anwendung angeforderte
Netzwerkbetriebsmittelfunktionalität zu benutzen.
-
Die
Entwicklung von Anwendungen durch Dienstprovider (umfassend Unternehmer,
virtuelle und „reale" Netzwerkoperatoren), unabhängige Softwareliferanten
bzw. -verkäufer
und potentielle Endbenutzer selbst wird durch Verwendung eines Parlay-Client-Proxys (PCP),
der die Schichten 20 und 21 implementiert, vereinfacht.
Dies ist vorgesehen, um die Parlay-Kommunikation zu den Schichten 23 und 24 zu
vereinfachen und eine Anwendungskomponenten-Wiederverwendung auf
der Basis eines einfachen Gebrauchs der Dienste zu unterstützen und
dadurch die Anwendungsentwicklungsaktivität zu vereinfachen. Der Gateway-Operator
und Teile anders als der Gateway-Operator können einen PCP benutzen.
-
Um
das Gateway 1 vollständig
im Bereich eines Netzwerk-Operators zu integrieren, sind Schnittstellen
zu existierenden Operator-Managementsystemen wie beispielsweise
Netzwerkmanagement, Kundenbetreuung, Rechnungserstellung bzw. Gebührenerfassung
usw. vorgesehen. Das Gateway 1 stützt diese Integration durch
Bereitstellung externen Zugriffs zur Managemententität 39 über eine
Zahl von Zugriffsprotokollen, beispielsweise SNMP, CORBA, HTTP.
Der Gateway-Operator konfiguriert den über die Managemententität bereitgestellten
externen Zugriff, um Interoperabilität zwischen Gateway-Managementfunktionen
und externen Systemen geeignet zu stützen.
-
Bezugnehmend
auf die 4 ist der PCP 50 dargestellt.
Die Schicht 20 umfasst einen XML-Interpreter, Parlay-Beans,
Utility-Beans und Komponentenanwendungen. Es ist auch ein gemeinsamer
Proxy-Manager vorhanden. Der PCP 50 wird, wie in 2 dargestellt,
vom ASP zusammen mit der Anwendung gehostet und erlaubt eine einfache
Schnittstellenverbindung mit kurzen Leitungszeiten zu den Schichten 23 und 24.
Die Schicht 21 umfasst Parlay-APIs.
-
Die
Parlay-Beans sind wiederverwendbare Objekte, die leicht instanziiert
werden können,
um eine Anwendungsschnittstelle, eine Parlay-Schnittstelle und Logik
dazwischen bereitzustellen. Eine XML-Scriptfunktion stellt eine
Benutzerschnittstelle bereit, um zu erlauben, dass eine Schnittstellenverbin dungskomponente
leicht instanziiert wird. Der XML-Interpreter führt die Niedriglevel-Instanziierung der
Parlay-Beans automatisch aus, um die Schnittstellenverbindungskomponente
zu vervollständigen.
-
So
umfasst der PCP 50 „Reihen"-Komponenten für die Schicht 20,
Parlay-APIs für
die Schicht 21 und Tools zum Ermöglichen einer einfachen Instanziierung
der Schicht-20-Komponenten (die Parlay-Beans), um der Anwendung
zu genügen.
-
Der
PCP 50 schirmt den Anwendungsentwickler gegen die Komplexität der Parlay-API 21 und gegen
die Kompliziertheiten von CORBA ab. Er stellt eine Zahl Programmierungsschnittstellen
bereit, die den Anwendungsentwickler mit einer Wahl versehen, die
zwischen einer vollständigen
Verantwortlichkeit für
Entwicklungsanwendungen, die direkt auf der Parlay-Schnittstellendefinition
basieren, (zur Schicht 21), oder alternativ dazu Entwicklung
einer Java-basierten Anwendung, die eine komponentenbasierte Java-Beans-IDE
verwendet oder eine einfache XML-basierte Scriptaufruf- bzw. Scripting-Schnittstelle
(zur Schicht 20) reicht. Die Schnittstellenwahl hängt vom
Geschick des Anwendungsentwicklers und der Komplexität der zu
entwickelnden Anwendung ab. Einfache Anwendungen können von
Programmkomponenten bzw. Beans oder unter Verwendung von Scripts
konstruiert werden, während
komplexere Anwendungen ein vollständigeres Verständnis dafür, wie die
Java-Programmierungsschnittstelle Parlay-Service unter Verwendung
des PCP-Kerns unterstützt,
erfordern sollten.
-
Um
die Entwicklung von Parlay-Clientanwendungen zu simplifizieren,
exponiert der PCP 50 Parlay-ähnliche Java-Beans an Anwendungsentwickler.
Die Beans laufen auf dem PCP-Kern, der aus Java-Parlay-Objektimplementierungen
und anderen verwandten Objekten besteht. Die PCP-Kerninhalte können nicht
direkt auf die Parlay-Anwendungen zugreifen, anstelle dessen werden
sie von den Parlay-Beans kontrolliert. Der Kern ist so ausgebildet, dass
er die Anwendung mit voller Parlay-Funktionali tät, aber in einer kontrollierten
und optimierten Weise bereitstellt.
-
Die
primäre
Funktion des PCP-Kerns ist, zwischen der Parlay-API, die CORBR- und Java-Implementierungen
der Parlay-Objekte verwendet, zu konvertiertieren. Der Schlüsselvorteil
ist, dass er die Entwicklung von Parlay-Anwendungen ohne Erfordernis einer
Kenntnis von CORBA ermöglicht.
-
PCP-Beans
-
Diese
Komponenten stellen robuste, effiziente, wiederverwendbare Funktionalität bereit,
die zum Erzeugen von PCP-Anwendungen schnell integriert werden können. Unter
Verwendung dieser PCP-Beans entwickelte Anwendungen können dann gegen
den PCP-Kern in einer zu irgendeiner anderen PCP-Anwendung identischen
Weise laufen.
-
Obgleich
die Majorität
der PCP-Beans kein eigenes GUI-Sichtbarwerden aufweisen, können ihre Eigenschaften
konfiguriert werden, und sie können noch
im Innern einer Java-Beans-IDE visuell zusammengesetzt werden.
-
Die
PCP-Beans ermöglichen
die Entwicklung von Parlay-Anwendungen ohne Erfordernis einer detaillierten
Kenntnis der Parlay-API. Ein Anwendungsentwickler benötigt nur
ein konzeptionelles Verständnis
von Parlay und den mit dem Gateway 1 arbeitenden Diensten
und kann Anwendungen von mehreren der PCP-Beans zusammensetzen. Die PCP-Beans
stellen eine einfache, leicht zu benutzende Diensterzeugungsumgebung
für Anwendungsentwicklung
bereit.
-
Es
gibt zwei Kategorien von PCP-Beans, die beim PCP 50 vorgesehen
sind. Die erste Kategorie, bekannt als die Parlay-Beans, stellt wiederverwendbare
Funktionalität
bereit. Die Parlay-Beans reagieren auf Events von anderen PCP-Beans
und rufen Operationen auf dem PCP-Kern auf. Beispiele umfassen Java-Beans
zum Ausführen
einer Authentisierung mit dem Cause way-Parlay-Gateway, Java-Beans
zum Entdecken von im Gateway laufenden Diensten und Java-Beans,
die wiederverwendbare Funktionalität für verschiedene im Gateway laufende Dienste
verkapseln.
-
Die
zweite Kategorie von PCP-Beans, bekannt als die Utility-Beans, stellen wiederverwendbare
Funktionalität
bereit, die für
den PCP-Kern nicht spezifisch ist. Utility-Beans rufen nicht irgendwelche Operationen
auf dem PCP-Kern auf. Sie enthalten Java-Beans zur Protokollierung
und Ablaufverfolgung, zum Datenbankzugriff und für zeitlich festgelegte Anforderungen.
-
Der
XML-Interpreter umfasst eine Document Type Definition (DTD, Dokumenttypdefinition),
welche die Interaktionen zwischen den vom PCP 50 bereitgestellten
verschiedenen Java-Beans
definiert. Der XML-Interpreter erlaubt, dass Anwendungen unter Verwendungen
von XML geschrieben werden, wobei jeder XML-Knoten einen des PCP-Kerns
oder der Utility-Beans repräsentiert,
und die Beans-Eigenschaften werden durch Knotenparameter repräsentiert.
-
Der
Proxy-Manager ist eine Managemententität, die für das Managing des PCP 50 und
die Anwendungen, die in ihm ausgeführt werden, verantwortlich
ist. Er führt
Anwendungslebenszyklus- und Anwendungsprofilmanagement-Funktionen
aus. Anwendungslebenszyklusmanagement umfasst die Funktionalität zum Installieren,
Aktivieren, Desaktivieren und Endinstallieren von Anwendungen auf dem
PCP 50. Anwendungsprofilmanagement umfasst die Konfiguration
von PCP-Einstellungen für jede
auf der Plattform eingesetzte Anwendung.
-
Es
ist zu erkennen, dass die Erfindung einen einfachen Migrationspfad
von laufender Netzwerksignalisierung bzw. -signalgabe und Kommunikationsprotokollen
(2G) zu neuen und zum Vorschein kommenden Techniken bzw.
Technologien (3G) durch Agieren als ein Adapter zwischen
den Anwendungen und Netzwerkbe triebsmitteln bereitstellt. Auch kann das
Gateway 1 die Fähigkeiten
des Netzwerks als eine einzelne logische Entität abfragen, eher als mit vielen
individuellen Netzwerkbetriebsmitteln direkt zu kommunizieren. Das
Gateway 1 stützt
Netzwerkunabhängigkeit
und -portabilität über Liferanten-
bzw. Verkäufergestützte Hardwareprodukte.
Außerdem stellt
das Gateway 1 eine Reihe von Diensten zur Verwaltung sehr
effektiv bereit. In den Schichten 20 und 21 erlaubt
das Gateway 1 eine weite Anwendungsentwicklerwahl von Schnittstellen,
darunter Parlay-APIs in Java- oder C++-Sprachen, einfache Java-Anwendungsentwicklung,
bei der verteilte Middleware vom Anwendungsentwickler verborgen ist,
eine Java-Beans verwendende komponentenbasierte Entwicklungsumgebung
und scriptbasierte Anwendungsentwicklungen.
-
Außerdem umfasst
der PCP einen SDK-Emulationsmodus (SDK = Software Development Kit
= Softwareentwicklungsbausatz), in welchem die ganze im PCP verfügbare Leistung
und Funktionalität
der APIs verwendenden Anwendungsentwicklungen mit einer integrierten
Emulations- und Testeinrichtung kombiniert sind. Dies wird auf einer einzelnen
Plattform ohne Erfordernis der Gateway-Schichten 23 und 24 oder
Netzwerkverbindung ausgeführt
und erlaubt so Anwendungsentwicklergemeinschaften Anwendungsideen
in Isolation von Netzwerk-Operatoren und noch im Vertrauen darauf, dass
die Anwendung den Anforderungen der standardisierten APIs genügt, zu entwickeln
und testen.