PatentDe  


Dokumentenidentifikation DE602005000549T2 22.11.2007
EP-Veröffentlichungsnummer 0001608103
Titel System zur Betriebsdatenlieferung unter Verwendung transparenter Sh-Schnittstellendaten eines IP Multimedia Systems
Anmelder Lucent Technologies Inc., Murray Hill, N.J., US
Erfinder Raether, Helmut L., Will, IL 60431-0550, US;
Rudolph, Michael Joseph, Dupage, IL 60565, US
Vertreter derzeit kein Vertreter bestellt
DE-Aktenzeichen 602005000549
Vertragsstaaten DE, FR, GB
Sprache des Dokument EN
EP-Anmeldetag 08.06.2005
EP-Aktenzeichen 052535051
EP-Offenlegungsdatum 21.12.2005
EP date of grant 14.02.2007
Veröffentlichungstag im Patentblatt 22.11.2007
IPC-Hauptklasse H04L 12/24(2006.01)A, F, I, 20070116, B, H, EP
IPC-Nebenklasse H04L 29/08(2006.01)A, L, I, 20070116, B, H, EP   

Beschreibung[de]
TECHNISCHES GEBIET

Die vorliegende Erfindung betrifft allgemein die Bereitstellung von Teilnehmerdaten, und insbesondere ein Verfahren zum Bereitstellen von Anwendungsserverdaten unter Verwendung eines HSS als einen Weg von einem Bereitstellungssystem zu einem Anwendungsserver. Sie bezieht sich im allgemeinen auf ein System, das eine herkömmliche Bereitstellungsschnittstelle zu dem IMS-HSS und die Sh-Schnittstelle von dem HSS zu einer generischen Anwendung verwendet, um Dienstdaten bezüglich der Anwendung am anderen Ende der Sh-Schnittstelle bereitzustellen.

ALLGEMEINER STAND DER TECHNIK

Unter Dienstbereitstellung verstehen verschiedene Personen viele verschiedene Dinge. Zum Beispiel kann sie sich auf die „Vorbereitung im voraus" von IT-Systemmaterialien oder -Hilfsmitteln beziehen, die zur Ausführung einer bestimmten definierten Aktivität erforderlich sind. Sie geht weiter als die anfängliche Möglichkeit der Bereitstellung von Betriebsmitteln zum weitergehenden Verwaltungs-Lebenszyklus dieser Betriebsmittel als verwaltete Posten. Dies könnte die Bereitstellung rein digitaler Dienste wie zum Beispiel von Benutzer-Accounts und Zugangsprivilegien auf Systemen, Netzwerken und Anwendungen umfassen. Es könnte auch die Bereitstellung von nicht-digitalen oder physischen Betriebsmitteln umfassen, wie zum Beispiel das Anfordern von Büroräumen, Mobiltelefonen und Kreditkarten.

CORBA ist ein Beispiel für eine Schnittstelle, die in Bereitstellungssystemen verwendet werden kann. CORBA ist die Abkürzung für Common Object Request Broker Architecture, die offene, anbieterunabhängige Architektur und Infrastruktur von OMG, die Computeranwendungen benutzen, um über Netzwerke miteinander zu arbeiten. Unter Verwendung des Standardprotokolls IIOP kann ein auf CORBA basierendes Programm von einem beliebigen Anbieter auf praktisch jedem Computer, Betriebssystem, jeder Programmiersprache und jedem Netzwerk mit einem auf CORBA basierendem Programm von demselben oder einem anderen Anbieter auf praktisch jedem anderen Computer, Betriebssystem, jeder Programmiersprache und jedem Netzwerk interoperieren.

CORBA ist in vielen Situationen nützlich. Aufgrund der Leichtigkeit, mit der CORBA Maschinen von so vielen Anbietern integriert, wobei Größen von Zentralrechnern über Minis und Desktops bis zu der in der Hand gehaltenen Geräten und eingebetteten Systemen reichen, ist sie die von großen (und sogar nicht so großen) Unternehmen am häufigsten gewählte Mittelware. Einer ihrer wichtigsten und auch häufigsten Verwendungszwecke liegt in Servern vor, die eine große Anzahl von Clients mit hohen Trefferraten, mit hoher Zuverlässigkeit abwickeln müssen.

CORBA-Anwendungen bestehen aus Objekten, einzelnen Einheiten ablaufender Software, die Funktionalität und Daten kombinieren und die häufig (aber nicht immer) etwas in der realen Welt repräsentieren. Typischerweise gibt es viele Instanzen eines Objekts eines einzelnen Typs – zum Beispiel hätte eine E-Commerce-Website viele Einkaufswagen-Objektinstanzen, die alle in Bezug auf Funktionalität identisch sind, aber sich darin unterscheiden, daß jede einem verschiedenen Kunden zugewiesen ist und Daten enthält, die die Waren repräsentieren, die ihr bestimmter Kunde gewählt hat. Für andere Typen könnte nur eine Instanz vorliegen. Wenn eine Legacy-Anwendung, wie zum Beispiel ein Buchhaltungssystem, in Code mit CORBA-Schnittstellen eingewickelt ist und Clients in dem Netzwerk eröffnet wird, besteht gewöhnlich nur eine Instanz.

Für jeden Objekttyp, wie zum Beispiel den gerade erwähnten Einkaufswagen, definiert man eine Schnittstelle in OMG IDL. Die Schnittstelle ist der Syntaxteil des Vertrags, den das Serverobjekt den Clients, die es aufrufen, anbietet. Jeder Client, der eine Operation an dem Objekt aufrufen möchte, muß diese IDL-Schnittstelle verwenden, um die Operation zu spezifizieren, die er durchführen möchte, und um die von ihm gesendeten Argumente zu ordnen. Wenn der Aufruf das Zielobjekt erreicht, wird dieselbe Schnittstellendefinition verwendet, um die Argumente zu entordnen, so daß das Objekt die angeforderte Operation mit ihnen durchführen kann. Die Schnittstellendefinition wird dann zum Ordnen der Ergebnisse für ihre Rückreise verwendet, und zu ihrer Entordnung, wenn sie ihr Ziel erreichen.

Die IDL-Schnittstellendefinition ist von der Programmiersprache unabhängig, kann aber über OMG-Standards auf alle gängigen Programmiersprachen abgebildet werden: OMG besitzt standardisierte Abbildungen von IDL auf C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, und IDL Script.

Diese Trennung der Schnittstelle von der Implementierung, die durch OMG IDL ermöglicht wird, ist das Wesentliche von CORBA – wie sie Interoperabilität mit allen beanspruchten Transparenzen ermöglicht. Die Schnittstelle zu jedem Objekt wird sehr strikt definiert. Im Gegensatz dazu ist die Implementierung eines Objekts – sein Ausführungscode und seine Daten – von dem Rest des Systems hinter einer Grenze, die der Client nicht überschreiten darf, verborgen (d.h., eingekapselt). Clients greifen nur durch ihre bekanntgestellte Schnittstelle auf Objekte zu, wobei nur die Operationen aufgerufen werden, die das Objekt durch seine IDL-Schnittstelle freilegt, mit nur den Parametern (Eingabe und Ausgabe), die in dem Aufruf enthalten sind.

Das sogenannte Diameter-Protokoll ist eine Erweiterung des RADIUS-Protokolls (Remote Access Dial In User Services). Es behandelt zusätzliche für Roaming, Netzwerkzugangsserver AAA, Mobil-IP-Skalierbarkeit und -Erweiterbarkeit naturgemäße Fähigkeiten. Das RADIUS-Protokoll wurde weithin und erfolgreich eingesetzt, um AAA-Dienste (Authentifikation, Authorisation und Buchhaltung) für Einwähl-PPP/IP- und Mobil-IP-Zugang bereitzustellen. Naturgemäße Unzulänglichkeiten des RADIUS-Protokolls haben seine Fähigkeit zur Anpassung an die immer weiter zunehmenden Fähigkeiten von Routern und Netzwerkzugangssservern (NAS) und die sich immer weiter erweiternde Menge von gewünschten AAA-Diensten eingeschränkt.

Der Referenzpunkt Sh 3GPP gibt die Definition der Interaktionen zwischen dem HSS (Heimatteilnehmerserver) und dem SIP RS (Anwendungsserver) und zwischen dem HSS und dem OSA SCS (Dienstfähigkeitsserver). Er wird unter Verwendung der Erweiterbarkeit des Diameter-Protokolls definiert.

Sh wird unter Verwendung der in dem Diameter-Protokoll naturgemäßen Erweiterbarkeit als eine Anwendung implementiert. Technisch wird Sh unter Verwendung einer anbieterspezifischen IETF-Diameter-Anwendung definiert, wobei der Anbieter 3GPP ist. Die Anbieterkennung wird von IANA 3GPP zugewiesen und die Diameter-Anwendungskennung wurde der Sh-Schnittstelle zugewiesen.

Ein Nachteil vorbekannter Bereitstellungssysteme besteht darin, daß Dienstanbieter zu jeder Anwendung einzeln eine Schnittstelle bilden. Als Ergebnis müssen separate Wege zwischen der Bereitstellungszentrale und jedem teilnehmerspezifische Daten erfordernden Netzwerkelement aufgebaut werden.

Die Zusammenfassung von CANNELLE ET AL., „SERVICE CONTROL FOR NEXT-GENERATION APPLICATIONS IN WIRELESS IP MULTIMEDIA NETWORKS", BELL LABS TECHNOLOGY, BELL LABORATORIES, MURREY HILL, NJ, USA, Band 8, Nr. 1, 9.7.2003 (2003-07-09), Seiten 27-42, XPOO8035120 ISSN:1089-7089, sagt folgendes aus: „Innerhalb des Partnerschaftsprojekts der 3. Generation (3GPP) wird der Vorstoß des auf dem Sitzungeinleitungsprotokoll (SIP) basierenden Multimedia-Subsystems des Internet-Protokolls (IP) (IMS) in Betracht gezogen, um einen schnellen Fortschritt in Richtung der Bereitstellung von Multimedia-Anwendungen für immer anspruchsvollere Endbenutzer zu erlauben. Das Beispiel der Dienstprogrammierbarkeit unter Verwendung von Anwendungsprogrammierschnittstellen (APIs) des offenen Netzwerks mit dem offenen Dienstzugang (OSA) als seinen Hauptexponenten hilft dabei, diese Entwicklung zusammen mit der Verwendung von SIP anzutreiben. Der Brennpunkt der vorliegenden Arbeit ist die Multimedia-Dienste-Architektur in dem IMS durch Bereitstellen von Einzelheiten der Interaktion des IMS und der Anwendungsserver in Form des OSA-Gateway und des SIP-Anwendungsservers. Die Arbeit versucht, den Wert der Schnittstelle der IMS-Dienststeuerung (ISC) bezüglich Anwendungsserverinteraktion in den IMS zu bewerten. Die Arbeit liefert einen OSA-Anwendungsbenutzungsfall und präsentiert außerdem den Präsenzserver als ein Beispiel für einen SIP-Anwendungsserver, der in das IMS paßt. ©2003 Lucent Technologies Inc." Seite 31 dieses Dokuments zeigt die Auflistung von Anwendungsservern durch den S-CSCF, der auf den HSS zugreift, und den HSS-Zugriff durch den Anwendungsserver, um Benutzerprofil- und Teilnahmeinformationen zu erhalten. Seite 34 zeigt eine Publish/Subscribe-Interaktion.

KURZFASSUNG

Verfahren gemäß der vorliegenden Erfindung werden in den unabhängigen Ansprüchen dargelegt. Bevorzugte Merkmale werden in den abhängigen Ansprüchen dargelegt.

Das Verfahren zur Bereitstellung von Anwendungsserverdaten unter Verwendung eines HSS als einen Weg von einem Bereitstellungssystem zu einem Anwendungsserver gemäß einer Ausführungsform der Erfindung umfaßt ferner die folgenden Schritte: Bilden einer Schnittstelle eines Bereitstellungssystems mit einem HSS mit einer Sh-Schnittstelle; und Verwenden der Sh-Schnittstelle als eine Bereitstellungsschnittstelle.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Merkmale beispielhafter Implementierungen der Erfindung werden aus der Beschreibung, den Ansprüchen und den beigefügten Zeichnungen ersichtlich. Es zeigen:

1 ein Blockdiagramm, das ein Telekommunikationssystem zur Verwendung mit dem vorliegenden Verfahren und System veranschaulicht.

2 eine Tabelle von über die Sh-Schnittstelle durch Operation zugänglichen Daten.

3 ein sehr allgemeines Flußdiagramm logischer Operationsschritte, die gemäß einer Ausführungsform des vorliegenden Verfahrens und Systems befolgt werden können.

4 ein weiteres Flußdiagramm von logischen Operationsschritten, die gemäß einer Ausführungsform des vorliegenden Verfahrens und Systems befolgt werden können.

5 ein Blockdiagramm einer Ausführungsform des vorliegenden Verfahrens und Systems.

6 ein Blockdiagramm einer weiteren Ausführungsform des vorliegenden Verfahrens und Systems.

7 Blockdiagramm einer weiteren Ausführungsform des vorliegenden Verfahrens und Systems.

8 ein Flußdiagramm logischer Operationsschritte, die gemäß einer Ausführungsform des vorliegenden Verfahrens und Systems befolgt werden können.

9 ein weiteres Flußdiagramm logischer Operationsschritte, die gemäß einer Ausführungsform des vorliegenden Verfahrens und Systems befolgt werden können.

AUSFÜHRLICHE BESCHREIBUNG

Die konkreten Werte und Konfigurationen, die in diesen nicht einschränkenden Beispielen besprochen werden, können variiert werden und werden lediglich angeführt, um eine Ausführungsform der vorliegenden Erfindung zu veranschaulichen, und sollen den Schutzumfang der Erfindung nicht einschränken.

Ausführungsformen der vorliegenden Verfahren beziehen sich im allgemeinen auf ein System, das eine herkömmliche Bereitstellungsschnittstelle zu dem IMS HSS und die Sh-Schnittstelle von dem HSS zu einer generischen Anwendung verwendet, um Dienstdaten über die Anwendung am anderen Ende der Sh-Schnittstelle bereitzustellen.

Ausführungsformen der vorliegenden Verfahren ermöglichen eine generische Bereitstellung von mit einem beliebigen IMS-Anwendungsserver assoziierten Teilnehmerdaten. Dies führt zu dem Vorteil, daß das Bereitstellungssystem des Dienstanbieters die Anzahl der Schnittstellen, die es unterstützen muß, reduzieren kann. Das Bereitstellungssystem kann eine herkömmliche Bereitstellungsschnittstelle zu dem IMS HSS und die Sh-Schnittstelle von dem HSS zu einer generischen Anwendung verwenden, um Dienstdaten bezüglich der Anwendung am anderen Ende der Sh-Schnittstelle bereitzustellen. Dies ist nützlich, weil der HSS transparente Daten verwendet, so daß er das Format des von ihm Weitergegebenen nicht erkennen muß. Weiterhin existiert als ein Beispiel die Bereitstellung von Elementen auf den HSS bereits über eine wohldefinierte CORBA-Schnittstelle. Das Bereitstellungssystem kann definierte Standardmechanismen verwenden, um einen Bereitstellungsweg zu dem Anwendungsserver zu erzeugen. Es versteht sich, daß eine CORBA-Schnittstelle nur ein Beispiel ist, das die Ausführungsformen der vorliegenden Verfahren benutzen kann.

Die Sh-Schnittstelle ist ein Beispiel für eine Publish/Subscribe-Schnittstelle. Eine Publish/Subscribe-Schnittstelle ermöglicht es einer Anwendung (Client), Daten fern auf einem Server zu speichern. Außerdem ermöglicht sie es dem Client, an nachfolgenden Aktualisierungen der Daten teilzunehmen. Wenn die Daten aktualisiert werden, sendet der Server eine Kopie der Daten zu dem Client. Bei der derzeitigen Implementierung wirkt der Anwendungsserver als der Client, und der HSS als der Server. Die Sh-Schnittstelle des IP-Multimedia-Subsystems (IMS) wird als eine Publish/Subscribe-Schnittstelle betrachtet.

Die technische Spezifikation von 3GPP spezifiziert die Interaktion zwischen dem HSS (Heimatteilnehmerserver) und dem SIP AS und zwischen dem HSS und dem OSA SCS (Dienstfähigkeitsserver). Diese Schnittstelle wird als der Sh-Bezugspunkt bezeichnet. Stufe 2 des IP-Multimedia-Kernnetzwerk-Subsystems wird in 3GPP TS 23.228 spezifiziert, und die Signalisierungsflüsse für die IP-Multimedia-Verbindungssteuerung auf der Basis von SIP und SDP werden in 3GPP TS 24.228 spezifiziert. Die IP-Multimedia-Sitzungsabwicklung mit dem IP-Multimedia-Verbindungsmodell wird in 3GPP TS 23.218 spezifiziert.

Bei der IP-Multimedia-Sitzung können die IP-Multimedia-Sitzung und die IP-Multimedia-Verbindung als äquivalent behandelt werden. Transparente Daten sind Daten, die syntaktisch, aber nicht semantisch von dem HSS verstanden werden können. Sie sind Daten, die ein AS in dem HSS zur Unterstützung seiner Dienstlogik speichern kann. Ein Beispiel sind Daten, die ein AS in dem HSS speichert, wobei er ihn als Lager benutzt. Nichttransparente Daten sind Daten, die sowohl syntaktisch als auch semantisch von dem HSS verstanden werden können. Ein AS (Anwendungsserver) kann entweder einen SIP-Anwendungsserver oder einen OSA-Dienstfähigkeitsserver bedeuten.

Der Anwendungsserver kann über die Sh-Schnittstelle mit dem HSS kommunizieren und der HSS kann mit dem Anwendungsserver über die Sh-Schnittstelle kommunizieren. Operationen an der Sh-Schnittstelle können zu funktionellen Gruppen klassifiziert werden, wie zum Beispiel Datenabwicklungsprozeduren (Herunterladen von Daten aus dem HSS in einen AS, und Aktualisieren von Daten in dem HSS) und Teilnahme-Benachrichtigungsprozeduren (wie zum Beispiel wenn AS daran teilnimmt, Benachrichtigungen von dem HSS über Änderungen an Daten zu empfangen, und der HSS einen AS über Änderungen an Daten benachrichtigt, für die der AS zuvor teilgenommen hat).

Ein Anwendungsserver (AS) kann ein IP/PBX, ein Buddy-System, ein Push-to-Talk-System, Instant Messaging, ein beliebiger allgemeiner Prepaid-Telefondienst usw. sein.

In bezug auf 1 liefert IMS 101 eine Infrastruktur zur Abwicklung mehrerer gleichzeitiger, auf IP basierenden Dienste für einen Teilnehmer, in einem Mobilitätsrahmen. Ein Element dieses IMS 101 ist der HSS 103. Der HSS 103 ist das zentrale Lager von während einer IMS-Verbindung verwendeten Teilnehmerdaten. Teilnehmerdaten werden als Teil der Benutzerregistration über die auf Cx-Diameterbasierende Schnittstelle zu I-CSCF und S-CSCF übermittelt. Andere Anwendungen können über eine andere HSS-Schnittstelle, nämlich Sh durch 3GPP, auf viele dieser Daten zugreifen.

Der HSS 103 spielt in dem IMS 101 eine wichtige Rolle, und stellt sicher, daß das Profil für einen IMS-Teilnehmer nach Authentifikation zu dem S-CSCF weitergeleitet wird. Er enthält die notwendigen Daten, damit CSCF die SIP-Verbindung steuern und/oder umleiten kann. Dies wird auf der Cx-Schnittstelle erzielt.

Eine weitere Rolle, die der HSS 103 spielt, ist die eines zentralen Datenlagers zur Ermöglichung des Informationsaustausches zwischen den Anwendungsservern (AS). Er ermöglicht es Anwendungen, datenabhängig von dem Datentyp zu pullen, an ihnen teilzunehmen oder zu pushen. Dienste können nun zwischen mehreren Verarbeitungsplattformen kommunizieren, indem Lagerdaten in dem HSS 103 gelassen werden. Außerdem sind andere Arten von HSS-Daten den Anwendungen anforderungs- oder teilnahmeweise verfügbar. Bestimmte Einschränkungen bezüglich Datentyp werden in einer revidierten Version eines 3GPP 29.328 angegeben (siehe die in 2 abgebildete Tabelle).

Die Sh-Schnittstelle ermöglicht Datenkommunikation zwischen dem HSS und dem Anwendungsserver bzw. den Anwendungsservern für einen Teilnehmer. Sie besteht aus nichttransparenten Daten und transparenten Daten. Nichttransparente Daten sind mit einem Teilnehmer assoziiert und enthalten die Etiketten in der Tabelle von 2, mit Ausnahme von Zeile 4.

Lagerdaten oder transparente Daten sind per Teilnehmer assoziiert, aber auch per Dienstindikation. Mit verschiedenen Dienstindikationen kann ein Dienst mehrere Definitionen transparenter Daten gemeinsam benutzen oder die transparenten Daten können zwischen separaten Plattformen, die Service 1 verwenden, gemeinsam benutzt werden, während eine andere Menge transparenter Daten von Plattformen, die Service 2 verwenden, gemeinsam benutzt werden kann. Das Format transparenter Daten ist dem HSS nicht bekannt, könnte aber eingekapselte XML- oder LDAP-Anfragen sein. Sie können mit der Sh-Diameter-Schnittstelle (die auch als die Sh-Schnittstelle bezeichnet wird) geschrieben oder gelesen werden. Zusätzlich unterstützt die Schnittstelle eine Teilnahme- und Benachrichtigungsfähigkeit.

Ein großer Teil der HSS-Daten kann gelesen oder gepullt werden. Weiterhin kann auch ein Anwendungsserver (AS) an gewählten Elementen dieser Daten teilnehmen. Auf diese Weise sendet der HSS Daten zu dem AS, wenn sie sich in dem HSS ändern.

Ein Beispiel für transparente Daten ist eine Buddy-Liste, die gemeinsam von gewillten Anwendungspartnern benutzt werden kann. Man nehme zum Beispiel an, daß Dienst A (Push-To-Talk (PTT)) und Dienst B (Instant Messaging) Buddy-Listen gemeinsam benutzen möchten. Die in 3 und 4 dargestellte Sequenz von Sh-Interaktionen kann zur Erzielung dieser gemeinsamen Benutzung unter Verwendung des HSS als gemeinsames Lager verwendet werden.

Damit die transparenten Sh-Daten über Anwendungen hinweg übermittelt werden können, muß jede Anwendung in der Lage sein, die in dem HSS gespeicherte vereinbarte Struktur zu verstehen. In diesem Szenario sind beide fähig, die Daten zu schreiben sowie Benachrichtigungen, daß sich die Daten geändert haben, zu empfangen und zu analysieren.

Hinsichtlich der Rolle des Bereitstellungssystems in der MMD-Dienstarchitekturplattform wird das Bereitstellungssystem als eine Bereitstellungsschnittstelle für alle erforderlichen Netzwerkelemente angesehen, wodurch alle Teilnehmer Zugang zu allen ihren Diensten erhalten können. Eine CORBA-Schnittstelle zu dem HSS geht zur Provisionierung der HSS-Teilnehmer als Unterstützung ihrer IMS-Fähigkeiten. Zusätzlich wird in Betracht gezogen, daß der HSS auch Anwendungsserver-Bereitstellungsinformationen aus dem Bereitstellungssystem in Richtung mehrerer Varianten von Anwendungsserversystemen leitet. Zur Erzielung der Bereitstellung der Sh-Schnittstelle kann man transparente Daten verwenden.

Es liegt im Interesse der Anwendungsserversituation, da der Inhalt der Lagerdaten (in einem echten IMS-Raum) dem HSS unbekannt ist. Deshalb würde der HSS die transparenten Daten eloquent weiterleiten, und müßte nicht beteiligt werden, falls sich die Datendefinition ändert oder erweitert. Nur die Endbenutzer (Anwendungsserver) müssen ihr Format verstehen.

5 zeigt eine Ausführungsform der Schnittstelle des HSS 103 zu dem Bereitstellungssystem 109 und dem Anwendungsserver 107, wie zum Beispiel einer IP/PBX. Unser Ziel ist die Bereitstellung der Anwendungsserverdaten unter Verwendung des HSS 103 als Weg von dem Bereitstellungssystem 109. Es sind zwei Schritte erforderlich. Zuerst werden die Daten aus dem Bereitstellungssystem 109 zu dem HSS 103, und dann von dem HSS 103 zu dem Anwendungsserver 109 gesendet. Zu diesem Zweck CORBA-Bereitstellung 111 von dem Bereitstellungssystem 109 zu dem HSS 103, und dann Verwendung der transparenten Datenfähigkeiten der Sh-Schnittstelle 113, um den Anwendungsserver 107 über neu bereitgestellte Daten für einen Teilnehmer zu benachrichtigen.

Das Bereitstellungssystem 109 stellt die HSS-Teilnehmerdaten unter Verwendung der CORBA-Schnittstelle 111 bereit. Alle erforderlichen Daten zur Unterstützung der Cx-Schnittstelle, sowie nicht-schreibbare Daten auf der Sh-Schnittstelle 113 kommen über diesen Mechanismus. Die Sh-Daten, die als transparente Daten definiert sind, können auch über diese CORBA-Schnittstelle 111 gesendet werden. Die nichttransparenten Daten für einen Teilnehmer werden in dem HSS 103 empfangen und mit ihren bekannten Attributen gespeichert. Transparente Daten für diesen Anwendungsserverdienst werden als ein Datenblock in der DF-Funktion 115 des HSS 103 gespeichert. Der HSS 103 kennt den Inhalt der transparenten Daten nicht. Dieser Mechanismus übermittelt HSS-Daten und Teilnehmerdaten in Bezug auf Anwendungsserver 107 von dem Bereitstellungssystem 109 in den HSS 103.

Zur Erzielung des nächsten Schritts kann die HSS-Bereitstellung über diese CORBA-Schnittstelle 111 neue Parameter enthalten, um Teilnahme-Anforderungs-Typ, AS-Identität und Dienstindikation des Anwendungsservers 107 mit einzuschließen. Dieser Inhalt wäre dem Empfang einer Sh-Subs-Notif (Teilnahme-Benachrichtigungs-Anforderung) von dem Anwendungsserver ähnlich. Sie kann auch Authentifikations- oder andere erforderliche Informationen zum Einrichten der nachfolgenden Diameter-Nachricht enthalten. Der transparente Datenparameter könnte als CORBA-verkapselte LDAP-Anfragen in einem Format, das der Anwendungsserver 107 versteht, codiert werden. Dadurch würden dem HSS 103 genug Daten zum Fortfahren gegeben.

Der nächste Schritt ist das Überbringen von Anwendungsserverdaten von dem HSS 103 zu dem Anwendungsserver 107. Transparente Daten mit einer einzigen Dienstindikation stellen einen einzigen Dienst bereit. Ferner kann man mehrere Dienstindikationen verwenden, um mehrere Dienste für den selben Teilnehmer bereitzustellen. Der HSS 103 nimmt über CORBA-Bereitstellung empfangene Parameter, läßt den Anwendungsserver 107 an den transparenten Daten teilnehmen, und leitet die LDAP-Bereitstellung enthaltenden Daten über eine Prozedur (Sh-Schnittstelle 113) des Diameter-Protokolls Sh-Notif (Push-Benachrichtigung-Anforderung) zu dem Anwendungsserver 107. Der Anwendungsserver 107 unterstützt die Sh-Diameter-Schnittstelle, extrahiert die LDAP-Enveloppe aus dem AVP der transparenten Daten, und wendet die Änderungen an. Die unter dem CORBA-Umschlag und der Sh-Schnittstelle enthaltenen transparenten Nutzdaten werden nun zwischen Endpunkten übermittelt, die den vordefinierten Inhalt verstehen.

6 zeigt eine weitere Ausführungsform der HSS-Schnittstelle von dem HSS 103 zu dem Bereitstellungssystem 109 und dem Anwendungsserver 107. Bei dieser Ausführungsform erfolgt die aktuelle Schnittstelle zu der Anwendungsserverbereitstellung über ein LDAP-Protokoll, und daß im Anwendungsserver 107 keine Sh-Schnittstelle verfügbar ist. Die Anwendungsserverdaten können unter Verwendung des HSS 103 als Weg von dem Bereitstellungssystem 109 bereitgestellt werden. Wieder sind zwei Schritte erforderlich. Erstens werden die Daten von dem Bereitstellungssystem 109 zu dem HSS 103, und dann von dem HSS 103 zu dem Anwendungsserver 107 gesendet. Zu diesem Zweck wird wie oben beschrieben CORBA-Bereitstellung von dem Bereitstellungssystem 109 zu dem HSS 103 verwendet. Als nächstes kann eine LDAP-Schnittstelle von dem HSS 103 zu dem gewünschten Anwendungsserver 107 erzeugt werden, und enthält die in dem AVP der transparenten Daten gefundenen eingekapselten LDAP-Anfragen.

In der CORBA-Bereitstellung des Bereitstellungssystems können die LDAP-Bindeanforderung unterstützende Daten enthalten sein. Dies würde dem HSS 103 anzeigen, daß eine LDAP-Schnittstelle 117 transparente Daten zu dem Anwendungsserver 107 senden muß. Da diese transparenten Daten eingekapselte LDAP-Zeichenketten sind, kann der HSS 103 diese transparenten Daten über die LDAP-Schnittstelle 117 zu dem Anwendungsserver 107 verschieben. Dieser Ansatz erfordert keine Änderungen in dem Bereitstellungssystem 109, erfordert aber nur, daß der HSS 103 weiß, daß dieser spezielle Übertragungsmodus existiert, so daß er LDAP- oder Diameter-Protokoll-Anforderungen differenzieren kann.

Eine Ausführungsform des vorliegenden Verfahrens und Systems umfaßt das Einkapseln von LDAP in CORBA-Objekte, und das nachfolgende Propagieren der Daten zu dem HSS. Dessen ungeachtet sind mehrere Varianten dieser Ausführungsform möglich, wie in den folgenden Abschnitten besprochen wird.

Um die Menge an in dem HSS gespeicherten Daten zu reduzieren, wird eine CORBA-Schnittstelle erzeugt, die so wirkt, als wenn ein Anwendungsserver die folgende Sequenz bereitgestellt hätte:

Teilnehmenlassen des Anwendungsservers an transparenten Daten für diesen Dienst;

Erzeugen neuer Lagerdaten in dem HSS, wobei die Sh-Profilaktualisierungsanforderung mit einer Sequenznummer von 0 emuliert wird, um Datenerzeugung anzuzeigen;

dies bewirkt, daß der Anwendungsserver über diese Datenänderung benachrichtigt wird;

Beenden der Teilnahme des Anwendungsservers an den transparenten Daten für diesen Dienst; und

Löschen der transparenten Daten für diese Kombination von Dienst/Teilnehmer unter Verwendung einer Aktualisierungsprofilanforderungsprozedur, die keine Dienstdaten enthält. Die Daten können nun im Einklang mit den Sh-Schnittstellenbeschreibungen aus dem HSS entfernt werden.

Dieser Ansatz kann auch für die LDAP-Lösung von 5 verfolgt werden. Bereitgestellte transparente Daten würden dieselben wie bei der Ausführungsform von 4 bleiben. Die Diameter-AVP's können dieselbe Benennung und Bereitstellung beibehalten. Nachdem Daten zu dem Anwendungsserver gesendet wurden, könnte der HSS dann die gespeicherten transparenten Daten löschen.

Das Bereitstellungssystemformat für Anwendungsserverdaten ist größtenteils unbekannt. CORBA mit eingekapselten LDAP-Anfragen ist eine Ausführungsform. Wenn dieses Format kein LDAP-eingekapseltes CORBA oder eine bestimmte Datenform ist, die in transparenten Daten eingekapselt werden kann, dann wäre ein weiterer Vorschlag XML-formatierte relationale Datenbankposten, die jeweils mit zu dem AS gesendeter separater Hinzufüge-, Modifizier- oder Löschoperation assoziiert werden könnten.

Wenn der HSS die Einzelheiten jedes Anwendungsservers oder Anwendungsserver-Bereitstellungsschemas verstehen muß, ist große Arbeit in dem HSS erforderlich, um die Anforderungen jedes AS zu unterstützen. Anwendungen, darunter Anwendungsserver, weisen komplexe Datenschemata auf. Um das Risiko einer Option zu lindern, daß der HSS Daten interpretieren muß, kann eine Abbildung von XML auf LDIF, gekoppelt mit einer besser definierten LDIF-zu-LDAP-Schnittstelle ein geeigneter Ansatz sein. Offensichtlich wäre eine Menge von Schnittstellenübersetzungsregeln besser als wenn der HSS das Schema jedes Anwendungsservers oder AS-Bereitstellungsparameter kennen müßte. Übersetzungen von XML in LDIF und von LDIF in LDAP sind bekannt.

Das Bereitstellungssystem kann auch eine Diameter-Sh-Schnittstelle zu dem HSS implementieren, als ein Anwendungsserver wirken, und eine Teilnahme-Benachrichtigungs-Anforderung senden, um Echtzeitaktualisierungen dieser Daten anzufordern, falls der Anwendungsserver sie ändert. Zusätzlich sind mehr Echtzeit-HSS-Daten über diese HSS-Schnittstelle verfügbar. Diese Fähigkeit wird durch den Anfrage-/Teilnahme-/Benachrichtigungs-Pfeil von dem Bereitstellungssystem zu dem HSS in 6 und 7 angezeigt.

Im allgemeinen kann das beschriebene System folgendes aufweisen: Mittel zum Senden von Daten von dem Bereitstellungssystem zu dem HSS, und dann zum Senden von Daten von dem HSS zu dem Anwendungsserver; Mittel zum Bereitstellen, durch das Bereitstellungssystem, von HSS-Teilnehmerdaten unter Verwendung einer vorbestimmten Schnittstelle; Mittel zum Empfangen nichttransparenter Daten für einen Teilnehmer in dem HSS und zum Speichern der nichttransparenten Daten mit bekannten Attributen davon in dem HSS; Mittel zum Speichern transparenter Daten für diesen Anwendungsserverdienst als einen Datenblock in dem HSS; Mittel zum Bereitstellen von neuen Parametern, die mindestens eine Identität des Anwendungsservers anzeigen, für die HSS-Bereitstellung über die vorbestimmte Schnittstelle; Mittel zum Teilnehmenlassen des Anwendungsservers an den transparenten Daten durch den HSS unter Verwendung der über die vorbestimmte Schnittstelle empfangenen Parameter; Mittel zum Leiten der transparenten Daten zu dem Anwendungsserver über ein vorbestimmtes Protokoll; Mittel zum Extrahieren von Informationen aus den transparenten Daten durch den Anwendungsserver zur Unterstützung der Publish/Subscribe-Schnittstelle; und Mittel zum Übermitteln von transparenten Nutzdaten der transparenten Daten, die unter einem vorbestimmten Umschlag für die vorbestimmte Schnittstelle und die Publish/Subscribe-Schnittstelle enthalten sind, zwischen Endpunkten, die den vordefinierten Inhalt verstehen.

Eine in 8 abgebildete Ausführungsform des vorliegenden Verfahrens zur Bereitstellung von Anwendungsserverdaten unter Verwendung eines HSS als Weg von einem Bereitstellungssystem zu einem Anwendungsserver kann die folgenden Schritte aufweisen: Senden von Daten von dem Bereitstellungssystem zu dem HSS, und dann Senden von Daten von dem HSS zu dem Anwendungsserver (Schritt 801); Bereitstellen, durch das Bereitstellungssystem, von Teilnehmerdaten für den HSS unter Verwendung einer CORBA-Schnittstelle (Schritt 802); Empfangen von nichttransparenten Daten für einen Teilnehmer in dem HSS und Speichern der nichttransparenten Daten mit den bekannten Attributen davon in dem HSS (Schritt 803); Speichern von transparenten Daten für diesen Anwendungsserverdienst als einen Datenblock in einer DF-Funktion des HSS (Schritt 804); Bereitstellen von neuen Parametern, darunter Teilnahme-Anforderungs-Typ, AS-Identität und Dienst-Indikation des Anwendungsservers (Schritt 805) für die HSS-Bereitstellung über die CORBA-Schnittstelle; Teilnehmenlassen, durch den HSS unter Verwendung der über die CORBA-Schnittstelle empfangenen Parameter, des Anwendungsservers an den transparenten Daten (Schritt 806); Leiten der transparenten Daten, die LDAP-Bereitstellung enthalten, zu dem Anwendungsserver über eine Sh-Schnittstelle (Schritt 807); Extrahieren, durch den Anwendungsserver und zur Unterstützung der Sh-Schnittstelle, der LDAP-Enveloppe aus den transparenten Daten, und Anwenden der Änderungen (Schritt 808); und Übermitteln der unter einem CORBA-Umschlag für die CORBA-Schnittstelle und die Sh-Schnittstelle enthaltenen transparenten Nutzdaten zwischen Endpunkten, die Inhalte der transparenten Daten verstehen (Schritt 809).

Eine in 9 abgebildete weitere Ausführungsform des vorliegenden Verfahrens zur Bereitstellung von Anwendungsserverdaten unter Verwendung eines HSS als Weg von einem Bereitstellungssystem zu einem Anwendungsserver kann die folgenden Schritte aufweisen: Senden von Daten von dem Bereitstellungssystem zu dem HSS und Senden von Daten von dem HSS zu dem Anwendungsserver (Schritt 901); Bereitstellen, durch das Bereitstellungssystem, der HSS-Teilnehmerdaten unter Verwendung einer CORBA-Schnittstelle (Schritt 902); Empfangen von nichttransparenten Daten für einen Teilnehmer in dem HSS und Speichern der nichttransparenten Daten mit bekannten Attributen davon in dem HSS (Schritt 903); Speichern transparenter Daten für diesen Anwendungsserverdienst als einen Datenblock in einer DF-Funktion des HSS (Schritt 904); Bereitstellung, für die HSS-Bereitstellung über die CORBA-Schnittstelle, von neuen Parametern, die Teilnahme-Anforderungs-Typ, AS-Identität, und Dienst-Indikation des Anwendungsservers enthalten (Schritt 905); Leiten der transparenten Daten, die LDAP-Bereitstellung enthalten, zu dem Anwendungsserver über eine Sh-Schnittstelle (Schritt 906); Extrahieren, durch den Anwendungsserver, und zur Unterstützung der Sh-Schnittstelle, der LDAP-Enveloppe aus den transparenten Daten und Anwenden der Änderungen (Schritt 907); und Übermitteln der unter einem CORBA-Umschlag für die CORBA-Schnittstelle und die Sh-Schnittstelle enthaltenen transparenten Nutzdaten zwischen Endpunkten, die den vordefinierten Inhalt verstehen (Schritt 908).

Ein weiteres Merkmal von Ausführungsformen der vorliegenden Verfahren besteht darin, daß das System auch Änderungen von einem Anwendungsserver zu einem Bereitstellungssystem zurückmelden kann. Bei einer Ausführungsform kann ein solches Verfahren die folgenden Schritte aufweisen: Bilden einer Schnittstelle eines Bereitstellungssystems mit einem HSS mit einer Publish/Subscribe-Schnittstelle; Verwenden der Publish/Subscribe-Schnittstelle als eine Bereitstellungsschnittstelle zur Bereitstellung von Anwendungsserverdaten für einen Anwendungsserver; und Propagieren von Datenänderungen von dem Anwendungsserver zurück zu dem Bereitstellungssystem unter Verwendung der Publish/Subscribe-Schnittstelle. Bei bestimmten Ausführungsformen kann die Publish/Subscribe-Schnittstelle eine Sh-Schnittstelle sein.

Das verbesserte vorliegende Verfahren und System überwindet die Unzulänglichkeiten des Stands der Technik, wobei Bereitstellungssysteme bei Dienstanbietern zu jeder Anwendung einzeln Schnittstellen bilden, was zu der Notwendigkeit des Aufbaus separater Wege zwischen der Bereitstellungszentrale und jedem teilnehmerspezifische Daten erfordernden Netzwerkelement führt.

Ausführungsformen der vorliegenden Verfahren machen einen separaten Bereitstellungsweg zu jedem Anwendungsserver überflüssig, und verwenden stattdessen den HSS zur Weiterleitung der Anforderung, ohne daß der HSS den Inhalt der Anforderung kennen muß. Dies ist zum Aufrüstungszeitpunkt nützlich, wenn der Inhalt des Bereitstellungsblocks verändert wird, sich die Anwendung und das Bereitstellungssystem ändern müssen, aber da der HSS das Format nicht kennt, er keine Schnittstellenaufrüstung benötigt.

Da die Sh-Schnittstelle Teilnahme/Benachrichtigung der Bereitstellung in transparente Daten erlaubt, erlaubt es die Sh-Schnittstelle dem HSS, den korrekten Anwendungsserver zu finden, und das Bereitstellungssystem muß nicht wissen, wohin, außer dem HSS, die Daten gehen. In einem Beispiel können mehrere Anwendungsserver vorliegen, die jeweils möglicherweise mehrere Teilnehmer aufweisen, und das Bereitstellungssystem weiß nicht, welche Teilnehmer mit welchen Anwendungsservern assoziiert sind. Wenn die Bereitstellungsdaten an dem Bereitstellungssystem ankommen, weiß das Bereitstellungssystem nur, zu welchem HSS sie zu senden sind. Der HSS führt Teilnahmeinformationen und weiß deshalb, zu welchem Teilnehmer die Bereitstellungsdaten zu senden sind, weil die transparenten Daten Namen und Zählerdaten sowie Nutzdaten für den bestimmten Teinehmer aufweisen.

Das vorliegende System und Verfahren kann mit nicht-mobilen Telefonen und Endgeräten sowie mit Mobiltelefonen und mobilen Endgeräten verwendet werden. Außerdem kann man mit dem vorliegenden Verfahren und System verschiedene Arten von Datenspeichereinrichtungen verwenden. Zum Beispiel kann es sich bei einer Datenspeichereinrichtung um eines oder mehrere der folgenden handeln: magnetische, elektrische, optische, biologische, und atomische Datenspeichermedien.


Anspruch[de]
Verfahren zur Bereitstellung von Anwendungsserverdaten unter Verwendung eines Heimatteilnehmerservers HSS (103) als Weg von einem Bereitstellungssystem zu einem Anwendungsserver AS, wobei das Verfahren die folgenden Schritte umfaßt:

Senden von Daten von dem Bereitstellungssystem (109) zu dem HSS (103), und dann

Senden von Daten von dem HSS (103) zu dem Anwendungsserver (107);

Bereitstellen, durch das Bereitstellungssystem (109), von Teilnehmerdaten für den HSS unter Verwendung einer CORBA-Schnittstelle (111);

Empfangen von nichttransparenten Daten, das heißt, von Daten, die syntaktisch und semantisch von dem HSS verstanden werden können, wobei es sich bei den nichttransparenten Daten um Teilnehmerdaten handelt, in dem HSS (103) und Speichern der nichttransparenten Daten mit den bekannten Attributen davon in dem HSS (103);

Speichern von transparenten Daten als einen Datenblock in dem HSS (103) zur Versorgung des Anwendungsservers (107), wobei transparente Daten Daten bedeutet, die von dem HSS (103) syntaktisch, aber nicht semantisch verstanden werden können;

Bereitstellen von neuen Parametern, darunter Teilnahme-Anforderungs-Typ, AS-Identität und Dienst-Indikation des Anwendungsservers (107), für den HSS über die CORBA-Schnittstelle (111);

Teilnehmenlassen, durch den HSS (103) unter Verwendung der über die CORBA-Schnittstelle (111) empfangenen Parameter, des Anwendungsservers (107) an den transparenten Daten;

Leiten der transparenten Daten zu dem Anwendungsserver (107) über eine Publish/Subscribe-Schnittstelle (113);

Extrahieren, durch den Anwendungsserver (107) und zur Unterstützung der Publish/Subscribe-Schnittstelle (113), eines nativen Bereitstellungsscripts aus den transparenten Daten unter Analyse von Datenänderungsbenachrichtigungen und Anwenden der Datenänderungen; und

Übermitteln der unter einem CORBA-Umschlag für die CORBA-Schnittstelle (111) und die Publish/Subscribe-Schnittstelle (113) enthaltenen transparenten Nutzdaten zwischen Endpunkten, die Inhalte der transparenten Daten verstehen.
Verfahren nach Anspruch 1, wobei die Publish/Subscribe-Schnittstelle (113) eine Sh-Schnittstelle (113) ist, wobei CORBA-Bereitstellung von dem Bereitstellungssystem (109) zu dem HSS (103) verwendet wird und wobei transparente Datenfähigkeiten der Sh-Schnittstelle (113) benutzt werden, um den Anwendungsserver (109) über neue bereitgestellte Daten für einen Teilnehmer zu benachrichtigen, und wobei als transparente Daten definierte Sh-Daten auch über die CORBA-Schnittstelle (111) gesendet werden. Verfahren nach Anspruch 1, wobei die neuen Parameter ferner mindestens zum Aufbau einer nachfolgenden Diameter-Nachricht erforderliche Authentifikationsinformationen umfassen. Verfahren nach Anspruch 1, wobei der HSS (103) den Inhalt der transparenten Daten nicht kennt. Verfahren nach Anspruch 1, wobei die HSS-Daten und Teilnehmerdaten in bezug auf Anwendungsserver (109) von dem Bereitstellungssystem (109) in den HSS (103) überbracht werden. Verfahren nach Anspruch 1, wobei CORBA einen transparenten Datenparameter verkapselt, der LDAP-Operationen in einem vorbestimmten Format angibt, das der Anwendungsserver (109) versteht. Verfahren nach Anspruch 1, wobei ein einzelner Dienst mit transparenten Daten mit einer Einzeldienstindikation bereitgestellt wird und wobei mehrere Dienste für einen selben Teilnehmer mit Mehrfachdienstindikationen bereitgestellt werden. Verfahren nach Anspruch 1, wobei die transparenten Daten Daten sind, die der HSS (103) syntaktisch, aber nicht semantisch versteht, und wobei die transparenten Daten Daten sind, die ein Anwendungsserver (109) in dem HSS (103) speichert, um seine Dienstlogik zu unterstützen, und die nichttransparenten Daten Daten sind, die der HSS (103) sowohl syntaktisch als auch semantisch versteht. Verfahren zur Bereitstellung von Anwendungsserverdaten unter Verwendung eines Heimatteilnehmerservers HSS (103) als Weg von einem Bereitstellungssystem zu einem Anwendungsserver, wobei das Verfahren die folgenden Schritte umfaßt:

Senden von Daten von dem Bereitstellungssystem (109) zu dem HSS (103) und dann Senden von Daten von dem HSS (103) zu dem Anwendungsserver (107);

Bereitstellen, durch das Bereitstellungssystem (109), von Teilnehmerdaten für den HSS (103) unter Verwendung einer vorbestimmten Schnittstelle (111);

Empfangen von nichttransparenten Teilnehmerdaten, das heißt, von Daten, die syntaktisch und semantisch von dem HSS verstanden werden können, in dem HSS (103) und Speichern der nichttransparenten Daten mit bekannten Attributen davon in dem HSS (103);

Speichern von transparenten Daten als einen Datenblock in dem HSS (103) zur Versorgung des Anwendungsservers (107), wobei transparente Daten Daten bedeutet, die von dem HSS (103) syntaktisch, aber nicht semantisch verstanden werden können;

Bereitstellen von neuen Parametern, die mindestens eine Identität des Anwendungsservers (107) angeben, für den HSS über die vorbestimmte Schnittstelle (111);

Teilnehmenlassen, durch den HSS (103) unter Verwendung der über die vorbestimmte Schnittstelle (111) empfangenen Parameter, des Anwendungsservers (107) an den transparenten Daten;

Leiten der transparenten Daten zu dem Anwendungsserver (107) über ein vorbestimmtes Protokoll;

Extrahieren, durch den Anwendungsserver (107) und zur Unterstützung der Publish/Subscribe-Schnittstelle (113), von Informationen aus den transparenten Daten; und

Übermitteln von transparenten Nutzdaten der transparenten Daten, die unter einem vorbestimmten Umschlag für die vorbestimmte Schnittstelle (111) und die Publish/Subscribe-Schnittstelle (113) enthalten sind, zwischen Endpunkten, die den Inhalt der transparenten Daten verstehen.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com