-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich auf eine Anordnung zum Verbessern
der Dienstarchitektur für ein
zusammengesetztes Telefonnetz, umfassend mehrere Typen von Zugang/Protokollen
ebenso die umfassend parallele Dienstknoten.
-
Mit
anderen Worten findet die vorliegende Erfindung ihre Anwendung auf
dem Gebiet von H.323 und Dienststeuerung.
-
HINTERGRUND
DER ERFINDUNG
-
Die
vorliegende Erfindung wurde in Verbindung mit Problemen entwickelt,
auf die man trifft, wenn dienstspezifische Anpassungen an die Anforderungen
des einzelnen Kunden in einem Netz durchgeführt werden.
-
Das
Problem besteht darin, dass die jeweilige Dienstlogik stark in die
Vermittlungslogik des Kernnetzes integriert ist. Dies bedeutet,
dass neue Dienstlogik und Dienstanpassungen Änderungen in den Kernvermittlungsfunktionen
erfordern können.
Dies macht ist wiederum sehr schwer, kundenspezifische Anpassungen an
der Dienstschicht durchzuführen.
-
Z.B.
können
große Änderungen
in den IN-Diensten nicht ohne Aktualisierung der Vermittlungen (switches)
in dem Netz durchgeführt
werden, d.h. selbst wenn die Steuerung in Wirklichkeit zwischen
dem Handapparat und Knoten 1 in dem Netz geschieht, gibt es eine "Transportausrüstung", die auch zu aktualisieren
ist, da die Dienststeuerung die gleichen Steuerdaten/Mechanismen/Pfade
wie diese Transportknoten verwendet.
-
BEKANNTE LÖSUNGEN UND
PROBLEME MIT DIESEN
-
Wie
oben erläutert,
besteht das Hauptproblem mit traditionellen Netzen darin, dass die
Dienststeuerprotokolle mit unteren Schichtfunktionen integriert
sind, wie etwa Ruf- und Mediensteuerung. Dies bindet die Dienststeuerebene
an untere Schichtfunktionen, wie etwa Basisvermittlungsfunktionen,
und führt
Systemkopplungen ein, die Kundenanpassung von Dienststeuerung aufwändig machen.
-
Die
Dienststeuerung und Dienste sind somit häufig an gegebene Zugangsprotokolle
gebunden. Dies führt
häufig
zum Aufbau von parallelen Dienstnetzen mit geringen Unterschieden
in Protokollen und Diensten. Jedes Dienstnetz löst dann die Dienstprobleme
für einen
spezifischen Typ vom Netz. Dies führt typischerweise zu teuren
und ineffektiven Dienstentwicklungsrahmenwerken, die unflexibel,
teuer und schwer zu warten sind.
-
Für die IP-Telefonnetze,
wie durch den Standard H.323 definiert, ist das Dienststeuerprotokoll
durch die Standard-Suite H.450 definiert. Dies definiert ein band-internes
(in-band) Dienststeuerprotokoll, das innerhalb der H.225.0-Rufsteuerebene
(einer definierten Teilmenge von Q.931) ausgeführt wird. Dieses Protokoll definiert
eine Menge von ASN.1-Dienststeuernachrichten,
die zum Aufrufen und Steuern von Diensten verwendet werden. Die
Probleme bei diesem Ansatz werden wie folgt zusammengefasst:
Einführung von
neuen Diensten erfordert Aktualisierungen von H.450-Nachrichten
und Dekodierungslogik im Gatekeeper (Tor wächter). Dies verlangsamt die
Einführung
von Dienstlogik, da es sowohl einen Standardisierungsprozess als
auch Aktualisierungen an der Vermittlungssteuerebene erfordert.
-
Anpassung
von Dienststeuerung an lieferantenspezifische Steuernachrichten/Logik
wird unmöglich (oder
teuer), da sie sich auf den Vermittlungskern bezieht.
-
Integration
und Zusammenarbeit von Datentransferprotokollen (messaging protocols)
wird schwerer, da sie mehr Umschlüsselung von Nachrichten erfordert.
-
Die
Benutzer-Benutzer-Nachrichten und Benutzer-Dienst-Nachrichten werden
innerhalb der gleichen Nachrichten und Rahmung (framing) ausgeführt. Um
Benutzer-Dienst-Nachrichten zu identifizieren, müssen alle Nachrichten analysiert
werden – nicht
nur jene, die für
Dienste adressiert sind. Das Protokoll ist ASN.1-kodiert und integriert
sich nicht leicht mit MIME-kodierten Datentransferdiensten (messaging
services).
-
EP 1 003 343 A1 ,
veröffentlicht
am 24.5.2000, bezieht sich auf ein System zum Managen von Kommunikationssitzungen
zwischen unterschiedlichen Netzen, wie einem PSTN-Netz und dem Internet.
Das System inkludiert eine Dienstlogik-Steuervorrichtung, die die
Kommunikationssitzung durch ein IP-PSTN-Gateway herstellt.
-
MIZUNO
O. et al: "Advanced
Intelligent Network and the Internet Combination Service and its
Customization",
IEICI. TRANS. COMMUN., Vol. E81-B, Nr. 8, August 1998, beschreibt
die Diensterstellung und Kundenanpassung in einem Szenarium mit
einem intelligenten Netz, was Kunden erlaubt, ihre eigenen Dienstspezifikationen
zu definieren. Die Lösung
schlägt
vor, Internet-Technologien zu verwenden, die auf IN angewendet werden.
-
ZIELE DER
ERFINDUNG
-
Ein
Ziel der vorliegenden Erfindung besteht darin, eine Anordnung vorzusehen,
durch die eine kosteneffektive und adaptive Dienstarchitektur für ein zusammengesetztes
Netz, umfassend mehrere Typen von Zugang, auf eine weit mehr angebrachte
und vielseitige Art und Weise implementiert werden kann.
-
Ein
anderes Ziel der vorliegenden Erfindung besteht darin, eine Anordnung
vorzusehen, durch die die Dienstnetze einfacher integriert und entwickelt
werden können.
-
Noch
ein anderes Ziel der vorliegenden Erfindung besteht darin, eine
Anordnung vorzusehen, wodurch die Dienstarchitektur und Zugangstechnologien
flexibler und einfacher zu warten gemacht werden.
-
KURZE ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
obigen Ziele werden in einer Anordnung erreicht, wie in der Präambel angeführt, was
gemäß der vorliegenden
Erfindung dadurch gekennzeichnet ist, dass sie ein offenes Dienststeuerprotokoll
umfasst, was Unterstützung
von zugangsspezifischen Protokollen und Diensten erlaubt, während auch
den jeweiligen Zugangsnetzen erlaubt wird, die gleichen Zugangsknoten
und Dienstarchitekturen gemeinsam zu nutzen, das offene Dienststeuerprotokoll
zum Entfernen der Kopplung zwischen der Zugangs-/Diensttechnologie
und der Vermittlungslogik in dem Kernnetz angepasst ist.
-
Mit
anderen Worten zielt die Erfindung auf kundenspezifische Anpassung
von Dienststeuerprotokollen, indem erlaubt wird, dass die Dienststeuerung
unabhängig
von den anderen Steuerfunktionen spezialisiert wird, wie etwa Rufsteuerung
und Mediensteuerung.
-
Die
Erfindung schlägt
vor, ein offenes Dienststeuerprotokoll zu verwenden, das eine kosteneffektivere Unterstützung von
zugangsspezifischen Protokollen und Diensten erlaubt, während den
jeweiligen Zugangsnetzen auch erlaubt wird, die gleichen Dienstknoten
und Dienstarchitekturen gemeinsam zu nutzen. Die Lösung zielt
auch auf die Entfernung der Kopplung zwischen der Zugangs-/Diensttechnologie
und der Vermittlungslogik in dem Kernnetz. Die vorgeschlagene Lösung basiert
auf H.323, erweitert mit HTTP für
die Dienststeuerung.
-
Weitere
Merkmale und Vorteile werden aus der folgenden Beschreibung, aufgenommen
in Verbindung mit den eingeschlossenen Zeichnungen, ebenso wie aus
den eingeschlossenen Patentansprüchen
erscheinen.
-
KURZE OFFENBARUNGEN DER
ZEICHNUNGEN
-
1 ist
ein schematischer Plan, der Vielfachzugangstyp und Dienstknotenarchitektur
veranschaulicht.
-
2 ist
ein schematischer Plan, der das allgemeine Prinzip der vorliegenden
Erfindung veranschaulicht, umfassend einen zusammengesetzten einzelnen
Dienstknoten mit Plugin-Architektur, was eine homogene Architektur
mit Zugangsadaptern ergibt.
-
3 ist
ein vereinfachtes Blockdiagramm, das ein Referenzmodell gemäß der vorliegenden
Erfindung veranschaulicht.
-
4 ist
ein schematischer Plan, der eine Dienstknotenstruktur gemäß einer
Ausführungsform
der vorliegenden Erfindung veranschaulicht.
-
5 ist
ein schematischer Plan, der ein Beispiel einer Verwendung gemäß der vorliegenden
Erfindung veranschaulicht.
-
DETAILLIERTE
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
-
In 1 gibt
es einen schematischen Plan, der einen Vielfachzugangstyp und Dienstknotenarchitektur vom
Stand der Technik veranschaulicht.
-
Um
die Probleme bezogen auf die Dienstarchitektur für ein derartiges zusammengesetztes
Netz, umfassend mehrere Typen von Zugang, ebenso wie umfassend parallele
Dienstknoten/Netze für
jeweilige Zugangstechnologien, hervorzuheben, wird gemäß der vorliegenden
Erfindung vorgeschlagen, ein offenes Dienststeuerprotokoll zu verwenden,
wie dies mit Bezug auf 2 detaillierter erörtert wird.
-
2 veranschaulicht
eine homogene Dienstarchitektur mit Zugangsadaptern, gemäß der vorliegenden
Erfindung, wodurch das offene Dienststeuerprotokoll so implementiert
werden kann, um eine kosteneffektivere Unterstützung von zugangsspezifischen
Protokollen und Diensten zu erlauben, während auch aktiven Zugangsnetzen
erlaubt wird, an den gleichen Dienstknoten und Dienstarchitekturen
teilzuhaben.
-
Mit
der vorgeschlagenen Lösung,
die in dem allgemeinen Plan gemäß 2 eingebettet
sein kann, ist es auch möglich,
die Kopplung zwischen der Zugangs-/Diensttechnologie und der Vermittlungslogik
in dem Kernnetz zu entfernen.
-
Die
vorgeschlagene Lösung
basiert auf H.323, erweitert mit HTTP für die Dienststeuerung.
-
Genauer
ersetzt die vorgeschlagene Lösung
die Standard-Suiten H.450 mit dem offeneren und erweiterbaren HTTP-Protokoll.
Die Lösung
macht auch von der Merkmalsmenge von HTTP Gebrauch, um die erforderliche
Flexibilität
hinzuzufügen.
Unter diesen Merkmalen sind zu finden:
-
HTTP-Tunneln (HTTP-Tunnelling)
-
Das
Tunnelling-Merkmal verweist auf die Verwendung des HTTP-Transportschichtprotokolls
zum Übertragen
anderer Datenprotokolle (in welchem Fall die HTTP-Header Information
darüber übertragen,
welche Art von Nutzlasttyp/Protokoll übertragen wird).
-
Serverseitiges
Plugin
-
Der
Plugin-Ansatz repräsentiert
die serverseitige Entsprechung von Browser-Plugins, wobei Plugins einer
dritten Seite (Objekte/Funktionen) dynamisch hinzugefügt werden
können.
Der Aufruf eines Plugins wird durch das Inhaltstypfeld oder durch
Selektionen/Filter in dem gegebenen Pfad gesteuert. Die Bindung
zwischen dem Plugin und den Aufrufkriterien wird durch Konfiguration
eingestellt.
-
Servlet-Funktionen
-
Der
Servlet-Ansatz bezieht sich auf Servlet-Objekte, die CGI-artige Funktionen
implementieren, kann aber Persistenz über Sitzungen hinzufügen und
ist objektorientiert.
-
BESCHREIBUNG
DER LÖSUNG
-
Die
Offenbarung der Erfindung bezieht sich auf ein H.323-basiertes Telefonnetz,
wo Clients Telefonrufe durch eine zentrale Ruf-/Steuerverarbeitungsvermittlung
durchführen,
die ein Gatekeeper genannt wird. Der Gatekeeper führt Ruf-/Steuerverarbeitungsfunktionen
durch, wie etwa Abrechnung, Weiterleitung und Ressourcensteuerung,
und kann auch rufbezogene Dienste in einem Dienstknoten gemäß den Rufzuständen und
den Benutzerprofilen aktivieren. Wenn der Client und der Gatekeeper
unterschiedliche Sprachen/Dialekte sprechen, wird ein Zugangsknoten
dazwischen hinzugefügt,
um die erforderlichen Gateway-Funktionen durchzuführen.
-
In 3 wird
ein vereinfachtes Netzreferenzmodell veranschaulicht.
-
Diese
Offenbarung der Erfindung schlägt
vor, das H.450-basierte Dienststeuerprotokoll zwischen den Zugangsknoten
und dem Gatekeeper/Dienstknoten durch ein HTTP-basiertes Protokoll
zu ersetzen. Dies bedeutet, dass Dienstkonfigurations- und Steuernachrichten
durch die Zugangsknoten HTTP-kodiert und durch den Dienstknoten
dekodiert, analysiert und ausgeführt
werden. Dies wiederum bedeutet, dass es keine Normalisierung der
Dienstprotokolle in den Zugangsknoten gibt und dass die Abbildung
von den zugangsspezifischen Dienstdaten zu den Dienstknotensprachen
durch Dienstknoten-Plugins/Servlets durchgeführt wird.
-
Der
Dienstknoten repräsentiert
eine Menge von Softwareprozessen, die zum Ausführen von Telefondiensten und
Interagieren mit dem Gatekeeper fähig sind. Der Dienstknoten
sieht somit eine Menge von Dienstfunktionen vor und bietet eine
Programmierungs-API für
Dienstausführung
und Steuerung an. Der Dienstknoten sieht auch einen HTTP-Server
vor, der HTTP-Tunnelling, Servlets und serverseitige Plugins unterstützt. Durch
die Verwendung dieses HTTP-Servers ist es möglich, ein Plugin oder Servlet
zu schreiben, das mit der Programmierungs-API interagiert, um die
Dienstausführung
zu steuern. Ein Beispiel dessen könnte ein Plugin sein, das DTMF-Codes
in API-Methodenaufrufe übersetzt,
z.B. kann DTMF "*23*1*1530#" in die API-Methode "UserIsBusyTo(15.30)" übersetzt werden.
-
In 4 ist
eine Veranschaulichung der Dienstknotenarchitektur angegeben.
-
Um
eine akzeptable Dienstverfügbarkeit
vorzusehen, werden der Dienstknoten und der HTTP-Server Installationen
von neuen Plugins/Servlets zur Laufzeit unterstützen müssen. Ferner muss die Architektur
derart sein, dass fehlerbehaftete Plugins, Servlets oder Sitzungen
den Betrieb des Dienstknotens nicht beeinträchtigen.
-
Die
beschriebene Architektur und Merkmalsmenge unterstützt zugangsspezifische
Dienststeuernachrichten ebenso wie kundenspezifische Anpassung des
Dienstnetzes und der Dienststeuerprotokolle, obwohl innerhalb der
Grenzen der Merkmalsmenge der Dienst-API. Dies wird durch die folgenden
zwei Beispiele veranschaulicht.
-
Um
ein zugangsspezifisches Dienststeuerprotokoll hinzuzufügen, wie
etwa QSIG, müsste
der Lieferant einen Zugangsknoten und ein Dienst-Plugin-/Servlet
schreiben.
-
Der
QSIG-Zugangsknoten würde
die Ruf- und Verbindungssteuernachrichten in das H.323-Format übersetzen,
würde aber
die QSIG-Nachrichten innerhalb von HTTP-Nachrichten tunneln und
diese zu dem Dienstknoten adressieren.
-
Ein
QSIG-Plugin/Servlet würde
auf dem HTTP-Server des Dienstknotens geschrieben und installiert. Die
Logik dieses Plugin/Servlet würde
die QSIG-Nachrichten in Methodenrufe (und Fähigkeitsmengen) in der Dienst-API übersetzen.
Wenn eine QSIG-Dienststeuernachricht von einer PBX gesendet wird,
wird der Zugangsknoten die QSIG-Nachricht in einen HTTP-Rahmen einhüllen und
ihn zu dem Dienstknoten senden. Der HTTP-Server in dem Dienstknoten
wird das Paket empfangen, erfassen, dass das Format etwas ist, das
QSIG genannt wird, seine Konfigurationsdaten nachschauen und das
korrekte Plugin/Servlet für
QSIG aktivieren. Dieses Plugin/Servlet wird die QSIG-Nachricht analysieren,
Methodenrufe in der API durchführen
und die angemessene QSIG-kodierte Antwort zurückgeben.
-
Wenn
neue Merkmale dem Dienstknoten und der Dienst-API hinzugefügt werden,
können
die Aktualisierungen zu den zugangsspezifischen Teilen durch Aktualisierungen
der Plugins/Servlets bereitgestellt werden, d.h. es sind keine Aktualisierungen
in den Zugangsknoten erforderlich.
-
Um
ein anbieterspezifisches Dienststeuerprotokoll hinzuzufügen, z.B.
basierend auf GSM-SMS, müsste
der Anbieter ein Plugin/Servlet schreiben, das die GSM-SMS-Nachrichten
in Methodenrufe über
die Dienst-API übersetzt.
Die Prozeduren sind wie oben definiert, aber in diesem Fall kann
eine externe dritte Seite anbieterspezifische Kundenanpassung an
dem Dienstnetz durchführen,
ohne an neue Auslieferungen des Kernsystems gebunden zu sein. In 5 wird
das GSM-SMS-Beispiel neben einer Vorgabeoption veranschaulicht.
-
VORTEILE
-
Hinzugefügte Flexibilität
-
Das
Dienststeuerprotokoll ist im Sinne einer Unterstützung von unterschiedlichen
Dienststeuerdatenformaten/Kodierungsstandards flexibler. Für jeden
neuen Kodierungsstandard muss ein neues Plugin kodiert werden.
-
Einfachheit
-
Das
Dienststeuerprotokoll wird dadurch flexibler, dass es einfacher
ist, neue Dienststeuernachrichten hinzuzufügen und diese unterstützt. Es
wird einfacher, das System zu debuggen, den Nachrichtentransport (vgl.
SSL) zu sichern und die Daten durch Firewalls und Proxies zu bekommen.
-
Kundenanpassung
-
Die
Lösung
erlaubt dem Dienstanbieter, anbieterspezifische Dienststeuernachrichten
unabhängig
von dem Systemlösungsanbieter
hinzuzufügen.
Dies bedeutet, dass ein Anbieter neue Steuernachrichten zum Dekodieren
dieser unabhängig
von dem Systemanbieter hinzufügen
kann (z.B. eine neue SMS-Nachricht hinzufügen und das Plugin für dessen
Dekodierung aktualisieren).
-
Leistungsverhalten
-
Die
Nachrichten werden zu dem korrekten Empfänger adressiert, was bedeutet,
dass der Gatekeeper nicht alle Nachrichten aktualisieren muss (inkludierend
Benutzer-Benutzer-Nachrichten), um die Benutzer-Dienst-Daten aufzunehmen.
-
AUSWEITUNG
-
1) Integration mit Datentransferanwendungen
-
Das
HTTP-Dienststeuerformat folgt dem MIME-Kodierungsstandard, der durch
SMTP, NTTP und S/MIME-Datentransferanwendungen verwendet wird. Es
wird erwartet, dass es möglich
sein sollte, diese Dienststeuerung mit diesen Datentransferanwendungen
zu integrieren.
-
2) Unterstützung für Benachrichtigungsdienste
-
Das
Prinzip kann erweitert werden, um dem Anwendungsserver zu erlauben,
HTTP-Nachrichten/Benachrichtigungen zu den Clients auszugeben (z.B.
wenn sich der Client registriert). Dies kann z.B. zum Benachrichtigen
des Benutzers über
neue E-Mail-Nachrichten in der In-Box verwendet werden.
-
3) Erweiterungen zum Unterstützen des
SIP-Protokolls
-
Das
SIP-Protokoll baut auf einer Verwendung des HTTP-Protokolls auf
und kann wahrscheinlich in die Systemlösung relativ einfach integriert
werden, falls der Anwendungsserver Dienste für einen Ruf aus dem blauen
(call-from-the-blue services) unterstützt.
-
4) Endgerät-(Gateway)-zu-Endgerät-(Gateway)
Dienststeuerung
-
Falls
zwei Endgeräte
(oder ihre Gateways) wünschen,
Dienststeuerung/Daten auszutauschen, könnten sie diese Dienststeuerung/Daten
in einer Sprache austauschen, auf die sie sich geeinigt haben. Die
jeweiligen Entitäten
(Endgeräte
oder Gateways) können
dynamisch Transcoder-Servlets/Plugins von einem zentralen Aufbewahrungsort
bei Bedarf herunterladen.
-
Dies
könnte
z.B. verwendet werden, wenn Benutzer A in seinem PC Benutzer B in
einem GSM-Endgerät
eine E-Mail-Nachricht sendet. Das GSM-Gateway entscheidet, dass
die E-Mail nicht verstanden wird und ruft irgendeinen Transcoder
(Codeumsetzer) zur Behandlung dieser E-Mail ab. Die Wahl vom Transcoder
kann gemäß Benutzerpräferenzen,
vorherigem Benutzerverhalten, Netz oder Betreiberkriterien ausgewählt werden. Beispiele
von Transcodern könnten
hier sein:
- • Transcoder
von E-Mail zu GSM-SMS-Nachricht
- • Transcoder
von E-Mail zu Sprachwiedergabe
- • Transcoder
von E-Mail zu WAP
-
1) Zugangssteuerung basierend
auf Dienststeuerungs-Plugin
-
Der
Zugang zu Transcoder-Funktionen (Servlets/Plugins) kann gemäß Abonnementprofilen,
Benutzerstandorten und anderer Metrik des Systems gesteuert werden.
Ferner kann die aufgerufene Transcoder-Funktion Zugangssteuerung
in den spezifischen Informationselementen der Dienststeuerung/Datenprotokolle
anwenden. Dies könnte
z.B. verwendet werden um zu steuern, wann und von wo ein gegebener
Dienst und welche Art von Dienstdaten verwendet wird, die in dem
gegebenen Kontext legal sind. Ein Beispiel könnte sein, den Inhalt einer
GSM-SMS-Nachricht zu filtern um sicherzustellen, dass keine Pornografiedaten übertragen
werden. (Der Transcoder würde
in diesem Fall als eine Anwendungsschicht-Firewall agieren.)
-
-
