DE10314597A1

DE10314597A1 - Verfahren und Anordnungen in einem Telekommunikationsnetz

Info

Publication number: DE10314597A1
Application number: DE10314597A
Authority: DE
Inventors: De Miguel Angel Boveda; Hernandez Manuel Lorenzo; Jens Jonsson; Anders Eriksson; Ingvar Berg; Lars Jensen; Andreas Torstensson; Niklas Bratt
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-04-25
Filing date: 2003-03-31
Publication date: 2003-11-06
Also published as: GB2387991A8; GB0307264D0; KR101027891B1; US20040039772A1; GB2387991B; JP2004007677A; CN100559764C; GB2387991A; CN1458767A; KR20030084594A

Abstract

Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet einer Verteiler von Diensten in Kommunikationsnetzen und insbesondere auf eine Bereitstellung von Diensten in einem Kommunikationsnetz mit einer Vielzahl von Dienstsystemen, Dienstanbietern und Dienstbefähigern. Das System gemäß der Erfindung sieht ein Systemkomponentenregister (SCR) vor, umfassend Dienstinformation in Bezug auf eine Vielzahl von Diensten in dem Dienstnetz (209), wobei die Dienstinformation in Dienstdatendatensätzen gespeichert ist, einer für jeden Dienst oder Gruppe von Diensten. Jeder Dienstdatendatensatz umfasst mindestens ein Dienstinstanzfeld (540), das eine Dienstinstanz für den spezifischen Dienst oder Gruppe von Diensten identifiziert, und, falls der spezifische Dienst oder Gruppe von Diensten ein komplexer Dienst ist oder eine gemeinsam genutzte Ressource nutzt, mindestens ein Abhängigkeitsfeld (550), das Abhängigkeiten für den spezifischen Dienst oder Gruppe von Diensten zu mindestens einem anderen Dienstsystem in dem Dienstnetz definiert.

Description

Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet einer Verteilung von Diensten in Kommunikationsnetzen und insbesondere auf eine Bereitstellung von Diensten in einem Kommunikationsnetz mit einer Vielzahl von Dienstsystemen, Dienstanbietern und Dienstbefähigern.

Hintergrund der Erfindung

Traditionell waren Kommunikationsnetze, wie etwa mobile Telefonnetze (PLMN), feste schaltungsvermittelte Netze (PSTN) und Datenkommunikationsnetze getrennte Systeme. Die Telekommunikationsnetze wurden als vertikal integriert charakterisiert, was bedeutet, dass Anwendungen und Dienste eng an die Technik zum Transport gebunden sind. Das mobile System GSM z. B. sieht eine Menge von Diensten und Anwendungen vor, deren Erscheinen, Vorteile und Begrenzungen mindestens zu einem großen Ausmaß durch die Kommunikationstechnik gegeben sind. Ein festes Telefonnetz (PSTN) hat eine unterschiedliche Menge an Diensten und Anwendungen vorgesehen, die eng mit der Kommunikationstechnik verbunden sind, die in dem System verwendet wird, und die Dienste unterscheiden sich häufig in Verwendung und Erscheinen von einem ähnlichen Dienst in einem PLMN. Dienste, die dem Endbenutzer ähnlich erscheinen, können wegen den gleichen engen Bindungen zu der Technik in den verschiedenen Netzen sehr verschieden implementiert sein.

Die enge Verknüpfung zwischen den Diensten und der Kommunikationstechnik war außerdem ein wichtiger Grund für die Tatsache, dass der Netzbetreiber auch der dominierende Anbieter von Diensten für den Endbenutzer war. Um einen Dienst vorzusehen, war Kenntnis von und Zugang zu dem vollständigen Netz entscheidend. Ein vertikal integriertes Netz wird in Fig. 1 dargestellt.

Es gibt eine steigende Nachfrage nach einer größeren Variation von Diensten, komplexen Diensten und um Wettbewerb zwischen Dienstanbietern zu erlauben. Zur gleichen Zeit haben sich die Tele- und Datenkommunikationsnetze entwickelt. Die neuen Generationen von Kommunikationssystemen integrieren verschiedene Kommunikationstechnologien, wie etwa zellulare Telefonie und IP-basierte Datenkommunikation. Die neuen Systeme werden häufig als horizontal geschichtet abgebildet, mit z. B. einer Zugangsschicht, einer Kernschicht und einer Dienstschicht. In Fig. 2 wird ein geschichtetes Kommunikationssystem abgebildet. In diesem Szenario interagieren existierende und neue Beteiligte, z. B. Betreiber, Dienstanbieter, Dienstbefähiger, Inhaltsanbieter und Anwendungs- (Internet) Dienstanbieter, um dem Endbenutzer eine große Vielfalt an Diensten anzubieten. Die Dienste werden in der Dienstschicht angeboten und verwaltet, die die Form eines Netzes, des Dienstnetzes 200, hat. Das Dienstnetz 200 interagiert mit dem Kernnetz 210, das typischerweise eine IP-Architektur hat und Transport- und Schaltfunktionalität vorsieht. Aus dem Kernnetz ist es möglich, mit einer Vielzahl von Zugriffsnetzen zu kommunizieren. Die Zugriffsnetze können von verschiedenen Arten sein, inkludierend zellulare Systeme 220 mit unterschiedlicher Kapazitäten und Charakteristika, wie etwa GSM oder UMTS, feste Telefonie (PSTN) 230, IP-basierte Datenkommunikation 240 und Kabel-TV 250. Das Dienstnetz 200 hat vorzugsweise eine offene Architektur, z. B. Offene Dienstarchitektur (Open Service Architecture, OSA) und eine offene Schnittstelle, z. B. OSA-Applikationsprogrammschnittstelle, API, derart, um der Menge an Beteiligten zu ermöglichen zu interagieren, um den Endbenutzern Dienste vorzusehen. Ein Vergleich zwischen vertikal integrierten Netzen und geschichteten Netzen kann in Ericsson Review Nr. 2, 2001 Seiten 62-67 gefunden werden.

Die angebotenen Dienste können vorzugsweise maßgeschneidert werden nach der persönlichen Präferenz des Endbenutzers, dem Zugriffsverfahren (mobiles System, festes System etc.), Charakteristika des Zugriffsendgerätes (z. B. die Kapazität eines mobilen Endgerätes), Abonnementtyp etc. Obwohl z. B. das Zugriffsverfahren die Ausführung des Dienstes in dem Dienstnetz beeinflussen wird, werden viele Teile der Ausführung eines Dienstes ungeachtet z. B. des Zugriffsverfahrens ähnlich oder identisch sein. Deshalb kann ein Dienstanbieter die gleichen "Baublöcke" verwenden, um unterschiedliche Dienste aufzubauen, die an unterschiedliche Endbenutzer angepasst sind. Ein Baublock kann z. B. ein Verzeichnisdienst, ein Nachrichtendienst oder ein Positionierungswerkzeug sein, die auch als Dienstbefähiger bezeichnet werden. Die Offenheit der Dienstnetze ebenso wie die Möglichkeit, Baublöcke für mehr als einen bestimmten Dienst zu verwenden, werden als Schlüsselfaktoren zum Anziehen sowohl von Beteiligten, wie etwa Betreiber, Dienstanbietern und Dienstbefähigern, als auch Endbenutzern wahrgenommen, um neue Dienste zu entwickeln bzw. zu verwenden.

Der angebotene Dienst wird von Basistelefondiensten, wie etwa Herstellen eines Rufes zwischen zwei mobilen Teilnehmern (Abonnenten), zu komplexen Diensten reichen, die unterschiedliche Zugriffsnetze, eine oder mehr Internetanwendungen und Sicherheitsdienste einbeziehen. Komplexe Dienste können einen Dienst inkludieren, der Positionierung, Nachrichten und elektronischen Handel verwendet. Ein positionierungsbasierter Dienst könnte z. B. Finden eines Hotels nahe der Position des Endbenutzers sein. Ein derartiger Dienst könnte eine Verwendung der Positionierungswerkzeuge des mobilen Systems über das mobile Positionierungszentrum, eine oder mehr Internetanwendungen zum Finden und Kategorisieren von Hotels in einem bestimmten Bereich, Anwendungen, die die Information in ein Format umwandeln, das für eine Darstellung auf dem Endgerät des Endbenutzers geeignet ist, z. B. WAP, und Anwendungen für elektronischen Handel, die eine sichere Buchung und Bezahlung eines Raums erleichtern, einbeziehen. Ein anderes Beispiel von komplexen Diensten bezieht sich auf das, was als Flottenverwaltung bekannt ist. Information über eine Position von jedem einzelnen Benutzer in einer ausgewählten Gruppe von Benutzern wird einem oder allen Benutzern in der Gruppe präsentiert. Die Position von jedem Benutzer wird durch das Positionierungssystem vorgesehen. Ein Benutzer kann auf diesem Weg aktualisierte Information über die Positionen von allen anderen in der Gruppe erhalten. Dieser Typ von Diensten kann z. B. beim Verwalten einer Flotte von Lieferfahrzeugen nützlich sein. Um derartige Dienste anzubieten und auszuführen, ist eine große Anzahl von Schnittstellen zwischen verschiedenen Dienstsystemen erforderlich, und da verschiedene Dienstsysteme durch verschiedene Dienstbefähiger vorgesehen werden können, sollte das Bedürfnis nach einem Dienstnetz und einem Dienstnetz, das eine offene Architektur und standardisierte Schnittstellen aufweist, offensichtlich sein.

Die Menge an Diensten, die in einem Dienstnetz durch eine Menge an Dienstanbietern, Befähigern etc. vorgesehen werden, die Endbenutzer, die in verschiedenen Zugriffsnetzen verstreut sind und mit der Anforderung nach personalisierten Diensten und verschiedenen Formen von Bezahlung, werden die Nachfrage nach richtigen endbenutzerbezogenen und dienstbezogenen Daten erhöhen und ein unmittelbarer Zugriff auf diese Daten ist entscheidend. In den heute existierenden Netzen sind Daten, die sich auf die Endbenutzer beziehen, überall in dem Netz verstreut, und in vielen Fällen werden redundante Endbenutzerdaten gespeichert und verwendet. Ähnlich sind Daten in Bezug auf Dienste hauptsächlich in den unterschiedlichen Dienstsystemen verstreut. Das verstreute Speichern der Daten und die Redundanz machen es schwierig, die Information abzurufen und zu aktualisieren. Es wird in den existierenden Netzen mit ihren verstreuten Daten insbesondere schwierig sein, eine stabile Funktionalität von komplexen Diensten zu implementieren und sicherzustellen. Ein Nachteil mit den verstreuten Daten kann mit dem Beispiel eines Endbenutzers, der sein Abonnement für einen komplexen Dienst beendet, der z. B. auf einem Positionierungsdienst beruht, veranschaulicht werden. Alle Daten, die sich auf diesen Teilnehmer beziehen, werden dann aus dem Dienstsystem entfernt, das den Positionierungsdienst vorsieht. Der Endbenutzer kann dennoch wünschen, andere komplexe Dienste zu verwenden, die die Positionierung verwenden, da aber die endbenutzerbezogenen Daten aus dem Dienstsystem entfernt wurden, das den Positionierungsdienst vorsieht, werden diesen anderen komplexen Diensten entscheidende endbenutzerbezogene Daten fehlen. Es wird in einem bestimmten Fall nicht möglich sein, die komplexen Dienste durchführen zu können, und in anderen Fällen, falls die Endbenutzerdaten dennoch von irgendwo in dem Netz abgerufen werden können, wird die Ausführung des komplexen Dienstes verzögert sein und/oder zu einer erhöhten Verkehrslast führen.

Nicht nur die Benutzer- und Teilnehmerdaten tragen das Risiko, in dem Dienstnetz verstreut zu sein, sondern auch Information über die verfügbaren Dienste selbst kann in einem großen Dienstnetz leicht degenerieren. Diese Dienstdaten inkludieren die Information, die für eine Dienstbereitstellung ebenso wie eine Ausführung eines Dienstes benötigt wird. Ein typisches Dienstnetz kann Tausende von Diensten enthalten, und neue Dienste, oder Kombinationen von Diensten werden beständig entstehen ebenso wie weniger erfolgreiche Dienste verschwinden werden. In dem Szenario mit Dienstdaten, die in dem Dienstnetz verstreut sind, wird es z. B. für einen Betreiber schwierig sein, alle Dienstinformation zu verfolgen, die benötigt wird, um die Dienste auszuführen, die ein Endbenutzer abonniert, und dem Endbenutzer neue Dienste anzubieten. Ferner wird es von entscheidender Wichtigkeit sein, neue Dienste schnell und richtig anzubieten, da die "Lebenszeit" eines bestimmten Dienstes kurz sein wird.

In dem Fall von komplexen Diensten mit z. B. unterschiedlichen Dienstbefähigern, die die unterschiedlichen "Baublöcke" eines komplexen Dienstes vorsehen, wird es das gegenwärtige Szenario mit verstreuten Dienstdaten für den Anbieter des komplexen Dienstes schwierig und langsam oder sogar unmöglich machen, über Änderungen in den "Baublöcken" aktuell informiert zu sein, Änderungen, die die Durchführung des komplexen Dienstes nachteilig beeinflussen können.

Die Probleme mit einer existierenden Handhabung von Diensten in dem Dienstnetz können wie folgt zusammengefasst werden:

a) Dienste werden durch unterschiedliche Dienstsysteme in dem Dienstnetz aufgestellt (deployed) und die Beziehungen zwischen den Dienstsystemen und den Diensten werden nicht einfach abgerufen;
b) Neue Dienste sollten den Endbenutzern schnell angeboten werden; und
c) Abhängigkeiten zwischen den unterschiedlichen Dienstsystemen, die durch einen komplexen Dienst verwendet werden, sind nicht einfach verfügbar.

Zusammenfassung der Erfindung

Das gegenständliche Problem ist, in einem Dienstnetz zum Vorsehen eines komplexen Dienstes und/oder einer Menge an Diensten ein Verfahren, Datenmodell und System zum Bereitstellen von Diensten vorzusehen.

Das Problem wird durch das System, wie in Anspruch 1 definiert, das Datenmodell gemäß Anspruch 9 und das Verfahren, wie in Anspruch 17 definiert, gelöst.

Das System gemäß einer Ausführungsform der Erfindung sieht ein Systemkomponentenregister (system component register, SCR) vor, umfassend Dienstinformation in Bezug auf eine Vielzahl von Diensten in dem Dienstnetz und Dienstdatendatensätze, die die Dienstinformation speichern, einen für jeden Dienst oder eine Gruppe von Diensten. Jeder Dienstdatendatensatz umfasst mindestens ein Dienstinstanzfeld, das eine Dienstinstanz für den spezifischen Dienst oder eine Gruppe von Diensten identifiziert; und, falls der spezifische Dienst oder eine Gruppe von Diensten ein komplexer Dienst ist oder eine gemeinsam verwendete Ressource nutzt, mindestens ein Abhängigkeitsfeld, das Abhängigkeiten für den spezifischen Dienst oder eine Gruppe von Diensten zu mindestens einem anderen Dienstsystem in dem Dienstnetz definiert.

Das Datenmodell gemäß einer Ausführungsform der Erfindung ist angepasst, für eine Bereitstellung von Diensten in einem Dienstnetz mit einer Vielzahl von Dienstsystemen zum Vorsehen einer Vielzahl von Diensten verwendet zu werden. Das Dienstdatenmodell umfasst Dienstinformation in Bezug auf eine Vielzahl von Diensten in dem Dienstnetz, die Dienstinformation ist in Dienstdatenobjekten strukturiert, eines für jeden Dienst oder eine Gruppe von Diensten, und jedes Dienstdatenobjekt umfasst: mindestens ein Dienstinstanzobjekt, das eine Dienstinstanz für den spezifischen Dienst oder eine Gruppe von Diensten angibt; und mindestens ein Abhängigkeitsobjekt, das Abhängigkeiten für den spezifischen Dienst oder eine Gruppe von Diensten zu mindestens einem anderen Dienstsystem in dem Dienstnetz definiert, falls der spezifische Dienst oder eine Gruppe von Diensten ein komplexer Dienst ist oder eine gemeinsam genutzte Ressourcen nutzt.

Das Verfahren gemäß der Erfindung zum Bereitstellen von Diensten in einem Dienstnetz, wobei Dienstinformation in Bezug auf eine Vielzahl von Diensten in einem Systemkomponentenregister (SCR) gespeichert wird, umfasst die Schritte:

- Aufstellen des Dienstes in dem Dienstnetz durch Vorsehen einer ersten Darstellung des Dienstes in dem SCR;
- Vorsehen des Dienstes durch Vorsehen einer zweiten Darstellung des Dienstes in dem SCR, wobei die zweite Darstellung des Dienstes eine Spezialisierung der ersten Darstellung ist. Das Verfahren kann ferner den Schritt umfassen:
- Anbieten des Dienstes an Endbenutzer durch Vorsehen einer dritten Darstellung des Dienstes in einer gemeinsamen Teilnehmer-/Benutzerdatenbank (common subscriber/user database, CSD), wobei die dritte Darstellung des Dienstes eine Spezialisierung der zweiten Darstellung des Dienstes ist.

Dank dem Dienstkomponentenregister gemäß der Erfindung und den Dienstdatendatensätzen, die gemäß dem Dienstdatenmodell der Erfindung strukturiert sind, wird eine zentralisierte Bereitstellung von Diensten in dem Dienstnetz erleichtert.

Durch diese Anordnungen wird eine stabile Umgebung in dem Dienstnetz geschaffen und eine schnelle und sichere Bereitstellung von Diensten wird sichergestellt.

Definitionen

Dienstnetz (Service Network, SN) - entspricht der Dienstschicht in der horizontal geschichteten Ansicht eines Kommunikationssystems. Knoten und eine Vielzahl von Dienstsystemen, die notwendig sind, um Endbenutzerdienste vorzusehen, werden als Teile des Dienstnetzes betrachtet. Welche Knoten genau, die betrachtet werden, zu dem Dienstnetz zu gehören, werden von der Implementierung abhängen.

Dienstsystem - System zum Vorsehen eines Dienstes oder eines Teils eines Dienstes. Das Dienstsystem gehört typischerweise zu dem Dienstnetz. Ein Dienstsystem kann andere Dienstsysteme verwenden (mit ihnen kommunizieren), um einem Endbenutzer einen spezifischen Dienst vorzusehen, und ein komplexer Dienst kann benötigen, eine Vielzahl von Dienstsystemen zu verwenden, um den Dienst auszuführen. Ein Dienstsystem kann einen oder mehr unterschiedliche Dienste oder Teile von Diensten vorsehen.

Dienstinstanz - ein Dienstsystem kann einen oder mehr "Baublöcke" zum Vorsehen eines Dienstes vorsehen, wobei derartige "Baublöcke" als Dienstinstanzen bezeichnet werden. Der Dienst kann nur einen "Baublock" oder eine Vielzahl von "Baublöcken" benötigen, die möglicherweise durch unterschiedliche Dienstsysteme vorgesehen werden.

Komplexer Dienst - ein Dienst, der zwei oder mehr Dienstsysteme engagieren muss, um dem Endbenutzer einen spezifischen Dienst vorzusehen.

Kurze Beschreibung der Figuren

Die Merkmale und Vorteile der vorliegenden Erfindung, die oben umrissen werden, werden nachstehend in der detaillierten Beschreibung in Verbindung mit den Zeichnungen vollständiger beschrieben, in denen gleiche Bezugszeichen überall auf gleiche Elemente verweisen, in denen:

Fig. 1 eine schematische Zeichnung eines traditionellen vertikal integrierten Netzes ist;

Fig. 2 eine schematische Zeichnung eines horizontal geschichteten Netzes ist, das ein Dienstnetz umfasst;

Fig. 3 die Beziehungen zwischen Basisentitäten der vorliegenden Erfindung veranschaulicht;

Fig. 4 einen Dienstlebenszyklus schematisch veranschaulicht;

Fig. 5 eine schematische Zeichnung des SCR gemäß der Erfindung ist;

Fig. 6 eine schematische Zeichnung des SCR gemäß einer Ausführungsform der Erfindung ist;

Fig. 7 eine schematische Zeichnung eines Bereitstellungstemplates gemäß einer Ausführungsform der Erfindung ist;

Fig. 8 eine schematische Zeichnung eines Beispiels von Dienstinformation ist, die in dem SCR gemäß einer Ausführungsform der Erfindung gespeichert wird; und

Fig. 9 eine schematische Zeichnung des UDM gemäß der Erfindung ist.

Detaillierte Beschreibung der Erfindung

Es werden nun Ausführungsformen der Erfindung mit Bezug auf 3 die Figuren beschrieben.
Die Steuerung des riesigen Umfangs an verschiedener Information, die zum Vorsehen und Ausführen von Diensten in den Dienstnetzen benötigt wird, ist für das Bereitstellen und die Durchführung der Dienste entscheidend, wie in dem Abschnitt Hintergrund beschrieben wird. Die vorliegende Erfindung spricht die oben angegebenen Probleme in Bezug auf die Streuung von Information in dem Dienstnetz durch Vorsehen eines Systemkomponentenregisters (SCR) an, das typischerweise als eine gemeinsame Datenbank, für die Information, die für eine Dienstbereitstellung in einem Dienstnetz benötigt wird, realisiert wird. Das SCR umfasst Information über den Typ von Diensten, Beschreibung der Dienste, Spezifikation des Dienstsystems oder Systemen, in dem ein Dienst installiert ist, und Dienstabhängigkeiten von anderen Diensten. Deshalb kann auf die Information, die vorzugsweise für eine gesamte Dienstbereitstellung in einem Dienstnetz benötigt wird, über die gesamte Entität in dem Netz zugegriffen werden.
Die Dienstdaten, die in dem SCR gespeichert sind, sind gemäß einem Dienstdatenmodell (SDM) strukturiert. Es sollte verstanden werden, dass das SCR Information über den Dienst als solchen vorsieht und nicht irgendwelche Information über Teilnehmer oder Benutzer enthält. Diese Teilnehmer-/Benutzerdaten werden vorzugsweise in einer gemeinsamen Teilnehmer- /Benutzerdatenbank (CSD) gespeichert, die von dem SCR getrennt ist. Es sollte auch verstanden werden, dass das SCR die Information vorsieht, die für die Bereitstellung eines Dienstes benötigt wird - die tatsächliche Ausführung eines Dienstes wird durch das Dienstsystem selbst gehandhabt, möglicherweise mit Information, die aus der CSD abgerufen wird.
Die oben erwähnte CSD enthält gemeinsame Benutzer- und Teilnehmerdaten, die durch eine Vielzahl von Diensten in dem Dienstnetz verwendet werden, ebenso wie die Beziehung zwischen Teilnehmer und Benutzern und Verknüpfungen zu angegliederten Daten. Die angegliederten Daten sind typischerweise endbenutzerbezogene Daten, die für einen Dienst oder eine Gruppe von Diensten spezifisch sind, und nur für ein spezifisches Dienstsystem relevant sind. Die gemeinsamen Benutzer- /Teilnehmerdaten werden in Übereinstimmung mit einem Benutzerdatenmodell (User Data Model, UDM) gespeichert.
Die Verwaltung von Daten, sowohl Benutzer-/Teilnehmerdaten als auch Dienstdaten, ist bei der Bereitstellung von komplexen Diensten besonders kritisch. Komplexe Dienste erfordern häufig eine Einbeziehung von zwei oder mehr Systemen zum Vorsehen von Diensten, wie z. B. in dem zuvor beschriebenen Beispiel einer Buchung in einem Hotel. Ein positionierungsbasierter Dienst würde typischerweise das mobile Positionierungszentrum eines Systems, MPC, und den Heimat-Teilnehmerserver, HSS, einbeziehen, wo das Profil eines Benutzers für das mobile Netz (Zugriffsnetz) gespeichert wird. Die Systeme wie MPC und HSS sind ein Beispiel der zuvor erwähnten "Baublöcke" oder Dienstbefähiger, die notwendig sind, um einen komplexen Dienst aufzubauen. Ein anderes Beispiel einer gemeinsam genutzten Ressource, die durch eine Vielzahl von komplexen Diensten genutzt wird, ist ein Kalender. Ein Benutzer wünscht typischerweise nur einen Kalender, der alle Einträge anzeigt, ungeachtet dessen, wie die unterschiedlichen Einträge erstellt wurden. In dem obigen Beispiel einer Buchung in einem Hotel greift der Dienst zum Buchen in einem Hotel vorzugsweise auch auf den Kalender zu, um die Reservierung automatisch einzutragen. Der Benutzer verwendet den gleichen Kalender, um Veranstaltungen zu buchen, sich an Geburtstage zu erinnern etc. In einem Geschäftsszenario kann ein Teilnehmer wünschen, dass alle seine Benutzer Zugriff auf einen gemeinsamen Kalender oder auf Kalender eines jeden anderen haben, um Funktionen verwenden zu können, die z. B. automatisch überprüfen, wann eine Gruppe von Benutzern für eine Veranstaltung frei ist. Deshalb kann der Dienst "Kalender" abhängig von der Verwendung als ein autonomer Dienst oder ein "Baublock" oder Dienstbefähiger für komplexe Dienste betrachtet werden. Um zu verhindern, dass Daten, die für ein Dienstsystem notwendig sind, durch ein anderes, z. B. das eine Dienstsystem, das das MPC verwendet, das Abonnement/Aktivierung des MPC beendet, wenn ein anderes Dienstsystem das Abonnement/Aktivierung benötigt, um seinen komplexen Dienst durchzuführen, geändert oder entfernt werden, müssen die Abhängigkeiten zwischen den Dienstsystemen angegeben werden.
Die Beziehungen zwischen Diensten, Dienstsystemen und Dienstinstanzen werden durch das folgende Beispiel weiter veranschaulicht. Die beiden Dienste lokaler Filmdienst und Nachrichtenaktualisierungsdienst werden angeboten. Lokaler Filmdienst verwendet Dienstsystem A und B, Nachrichtenaktualisierungsdienst verwendet Dienstsystem B und C. Deshalb hat der lokale Filmdienst zwei Dienstinstanzen, eine in Dienstsystem A und eine in Dienstsystem B. Nachrichtenaktualisierung benötigt auch zwei Dienstinstanzen, eine in Dienstsystem B und eine in Dienstsystem C.
Beim Verstehen, wie Dienste in dem Dienstnetz aufgestellt, vorgesehen und angeboten werden, sind drei Basisentitäten wichtig. Die drei Entitäten, der Teilnehmer, der Benutzer und der Dienst und ihre Beziehungen werden in Fig. 3 veranschaulicht. Die Entität Teilnehmer 310 abonniert eine oder mehr Mengen oder Pakete von Diensten 325, die in dem Dienstnetz vorgesehen sind. Der Teilnehmer 310 besitzt einen oder mehr Benutzer 305. Der Benutzer 305 ist der eine, der aktiv einen Vorteil von einem Dienst 320 zieht. Der Benutzer kann nur Dienste verwenden, die zu der Menge von Diensten 325 gehören, die der Teilnehmer 310 abonniert. Der Benutzer 305 wird immer zu einem Teilnehmer 310 gehören müssen. Der Teilnehmer 310 wird immer einen oder mehr Benutzer 305 besitzen. In vielen Fällen werden der Teilnehmer 310 und der Benutzer 305 die gleiche Person sein, aber z. B. für einen Geschäftsteilnehmer kann der Teilnehmer die Firma sein und die Benutzer werden die Angestellten der Firma sein.
Die Dienstdaten werden gemäß einem Dienstdatenmodell SDM gespeichert, was zu einem Dienstdatendatensatz SDR führt, der indem SCR gespeichert wird. Um das erfinderische Konzept zum Vorsehen eines SCR zu verstehen, ist es nützlich, den Lebenszyklus eines Dienstes in dem Dienstnetz zu beschreiben, von einer Konzeption eines neuen Dienstes zu dem Dienst, der einem Endbenutzer angeboten wird. Die Dienste werden in das SCR eingetragen und innerhalb des SCR mit der Hilfe von Bereitstellungstemplates entwickelt. Die Bereitstellungstemplates definieren die Information, die durch ein Dienstsystem benötigt wird, d. h. das Template sieht Information über die angegliederten Daten vor, die für diesen Dienst bereitzustellen sind, ebenso wie die Bereitstellungsoperationen, die durch das System, das den Dienst beherbergt, unterstützt werden.
Deshalb sehen die Bereitstellungstemplates nicht nur Information darüber vor, welche Daten bereitgestellt werden sollten, sondern auch wie sie bereitgestellt werden sollten. Ein neuer Dienst kann als sich in den folgenden Schritten entwickelnd abgebildet werden, beschrieben mit Bezug auf Fig. 4, wobei die Schritte ein Verfahren zum Bereitstellen eines Dienstes in einem Dienstnetz gemäß der Erfindung beschreiben:

- Aufgestellter Dienst (410). Wenn ein neuer Dienst entwickelt wurde, wird er in das Dienstnetz als ein aufgestellter Dienst eingeführt. Der aufgestellte Dienst ist eine erste Darstellung eines Dienstes und typischerweise ist eine Vielzahl von unterschiedlichen Konfigurationen des Dienstes möglich. Der aufgestellte Dienst wurde in dem Dienstnetz installiert und registriert. Jeder aufgestellte Dienst hat vorzugsweise ein zugehöriges Bereitstellungstemplate, das Bereitstellungstemplate für einen aufgestellten Dienst 440. Der Hauptzweck dieses Templates ist es, die Benutzerdaten zu beschreiben, die eine Bereitstellung benötigen, und die Operationen zu definieren, die durch das Dienstsystem unterstützt werden.
- Vorgesehener Dienst 420. Der vorgesehene Dienst definiert unterschiedliche Konfigurationen des aufgestellten Dienstes. Jede Konfiguration stellt einen vorgesehenen Dienst dar und ist eine zweite Darstellung eines Dienstes. Der aufgestellte Dienst kann z. B. eine Speicherung von 100 MB pro Benutzer für einen E-Mail-Dienst erlauben, der Betreiber kann aber wünschen, dies auf 10 MB pro Benutzer zu begrenzen. Dies veranschaulicht, wie der Dienst aus der Perspektive eines Kundenbeziehungs-Verwaltungssystems oder Geschäftsverwaltungssystemen gesehen werden sollte. Mit dem vorgesehenen Dienst steht ein Bereitstellungstemplate für einen vorgesehenen Dienst 450 in Verbindung. Da der vorgesehene Dienst eine Spezialisierung des aufgestellten Dienstes ist, wird das Bereitstellungstemplate für einen vorgesehenen Dienst 450 auf dem Bereitstellungstemplate für einen aufgestellten Dienst 440 basieren. Es ist jedoch möglich, weitere Spezialisierungen der Information in dem Template für einen aufgestellten Dienst in dem entsprechenden Template für einen vorgesehenen Dienst vorzunehmen. Ein weiterer Zweck des vorgesehenen Dienstes ist es, die Abbildung von angegliederten Befehlen und Attributen zu der Schnittstelle vorzunehmen, die zu dem Geschäftssystem vorgesehen wird.
- Angebotener Dienst 430. Ein vorgesehener Dienst wird dem Benutzer oder Teilnehmer als ein angebotener Dienst präsentiert. Der angebotene Dienst repräsentiert eine dritte Darstellung eines Dienstes und wird typischerweise eine Modifikation des vorgesehenen Dienstes 420 sein, um zu einem spezifischen Kundensegment zu passen. Diese Spezialisierung wird durch das Bereitstellungstemplate für einen angebotenen Dienst 460 angegeben.

Die Bereitstellungstemplates für einen aufgestellten 440 und vorgesehenen Dienst 450 befinden sich im SCR, während sich das Bereitstellungstemplate für einen angebotenen Dienst 460 in CDS befindet. Die Bereitstellungstemplates 440, 450, 460 können vorzugsweise als XML-Dateien gespeichert werden.
Die Entitäten in dem SCR sollten den Dienstlebenszyklus widerspiegeln und Verknüpfungen zu Dienstinstanzen definieren. Die Implementierung kann abhängig von der Technologie, die verwendet wird, um das CSR aufzubauen, variieren, aber die logische Gruppierung sollte die gleiche sein. Die folgenden Hauptentitäten, die in Fig. 5 schematisch dargestellt werden, sollten in dem CSR beinhaltet sein:

- Aufgestellter Dienst 510: enthält Information über einen Dienst, der in dem Dienstnetz installiert und registriert wurde. Die Entität aufgestellter Dienst beschreibt alle Fähigkeiten eines Dienstes und spezifiziert alle Daten, insbesondere Benutzer- und Teilnehmerdaten, die für eine Bereitstellung des Dienstes benötigt werden;
- Vorgesehener Dienst 520 ist eine Spezialisierung des aufgestellten Dienstes 510. Die Spezialisierung ist z. B. eine Begrenzung einer zulässigen Speichergröße für jeden Benutzer in einer E-Mail-Anwendung. Die Spezialisierung, z. B. Begrenzung, wird z. B. durch einen Systembetreiber eingerichtet;
- Dienstsystem 540 umfasst Information, die die Dienstinstanz und Adressierungsmittel für die Dienstinstanz spezifiziert. Wenn aus der Sicht von angegliederten Daten gesehen, spezifiziert das Dienstsystem 540 eine angegliederte Instanz und Adressierungsmittel für die angegliederte Instanz.
- Dienstabhängigkeiten von 550: Abhängigkeiten zwischen Diensten, die einen komplexen Dienst aufbauen oder eine gemeinsam genutzte Ressource verwenden, werden in dem SCR in den Entitätsdienstabhängigkeiten 550 gespeichert.
- Templates 560: Die Dienstdaten werden in das SCR mit der Hilfe von Templates eingegeben. Auch wird die Spezialisierung eines Dienstes, der durch den vorgesehenen Dienst und den aufgestellten Dienst dargestellt wird, gemäß Templates durchgeführt. Die Templates werden vorzugsweise in einem Format gespeichert, das kompakt und leicht austauschbar ist, z. B. als XML-Dateien (erweiterte Textauszeichnungssprache, extended Markup Language). Die Bereitstellungstemplates für aufgestellte 561 und vorgesehene Dienste 562 befinden sich im SCR, während sich das Bereitstellungstemplate für einen angebotenen Dienst 563 in CDS befindet.
- Angebotener Dienst 530 ist eine Spezialisierung eines vorgesehenen Dienstes 520, die eine Anpassung auf ein Kundensegment oder ein Dienstpaket widerspiegelt. Ein vorgesehener Dienst 520 kann zu einer Vielzahl von angebotenen Diensten 530 führen. Der angebotene Dienst 530 repräsentiert die Verbindung zwischen den Daten in dem UDR und dem SCR. Streng genommen ist der angebotene Dienst nicht eine Entität innerhalb des SCR, er gehört zu dem UDM, ist aber hier inkludiert, um die Beziehungen zu Entitäten innerhalb des SCR zu veranschaulichen (vorgesehener Dienst 530).

Die Speicherung von Dienstdaten einschließlich der Bereitstellungstemplates in dem SCR sollte in Übereinstimmung mit dem Dienstdatenmodell geschehen, welches mit Bezug auf Fig. 6 beschrieben wird.
Das SDM umfasst die nachstehend beschriebenen Objekte. Eine Realisierung des SCR wird Dienstdatendatensätze gemäß dem SDM umfassen, wobei ein Dienstdatendatensatz z. B. Felder entsprechend den nachstehend beschriebenen Objekten haben wird. Beispiele von Dienstdatendatensätzen für einige beispielhafte Dienste werden nachstehend vorgesehen. Das SDM umfasst die Objekte:

- Dienstgruppe 605: Das Objekt Dienstgruppe ist ein Platzhalter für Dienste. Dienste von einem Dienstanbieter können z. B. unter einer Dienstgruppe zusammengestellt sein, während die Dienste, die zu einem anderen Dienstanbieter gehören, unter einer anderen Dienstgruppe zusammengestellt sein können. Die Verwaltung der Dienstgruppe wird vorzugsweise durch einen Dienstverwalter durchgeführt.
- Dienst 610: Das Dienstobjekt ist der Platzhalter für alle Information in Bezug auf einen Dienst. Die Dienststatusattribute sind zwingend erforderlich und enthalten den Status des Dienstes.
- Dienstzugriffsdefinition 615: Für jeden Dienst kann ein Dienstzugriffsdefinitionsobjekt erstellt werden. Das Dienstzugriffsdefinitionsobjekt enthält Information darüber, wie der Dienst zu verwenden ist.
- Bereitstellungszugriffsdefinition 620: Für jeden Dienst kann ein Bereitstellungszugriffsdefinitionsobjekt erstellt werden. Das Bereitstellungszugriffsdefinitionsobjekt enthält Information darüber, wie der Dienst bereitzustellen ist. Dieses Objekt spezifiziert das Bereitstellungstemplate für den aufgestellten Dienst.
- Dienstinstanz 630: Es wird ein Dienst in einer oder mehr Dienstinstanzen installiert. Das Dienstinstanzobjekt enthält Information über eine Dienstinstanz. Attribute dieses Objekts sollten den Dienstzugriffspunkt für die Dienstinstanz spezifizieren und, falls der Dienst Bereitstellung erfordert, den Bereitstellungszugriffspunkt für die Dienstinstanz spezifizieren.
- Vorgesehener Dienst 640: Wenn ein aufgestellter Dienst zu einem vorgesehenen Dienst entwickelt ist, wird ein Objekt für einen vorgesehenen Dienst für den Dienst erstellt. Ein Attribut sollte das Bereitstellungstemplate für den vorgesehenen Dienst spezifizieren. Dieses Bereitstellungstemplate wird aus dem Bereitstellungstemplate für einen aufgestellten Dienst verfeinert.
- Dienstabhängigkeiten 650: Falls der Dienst von anderen Diensten abhängt, wird das Dienstabhängigkeitsobjekt erstellt. Ein zwingend erforderliches Mehrwertattribut sollten die Dienstidentitäten für alle abhängigen vorgesehenen Dienste spezifizieren.

Bezugnehmend auf Fig. 6 haben die Dienstinstanz 630 und der Dienst 610 eine Entsprechung in dem Hauptentitätsdienstsystem 540.
Die Bereitstellungszugriffsdefinition 620 wird erstellt, wenn der aufgestellte Dienst erstellt wird. Wenn der vorgesehene Dienst erstellt ist, wird das Objekt "vorgesehener Dienst" 640 der Information in dem SCR hinzugefügt. Deshalb werden die SCR-Daten für einen vorgesehenen Dienst sowohl das Bereitstellungstemplate für einen vorgesehenen Dienst als auch das Bereitstellungstemplate für einen aufgestellten Dienst enthalten. Dies ist notwendig, wenn man später den vorgesehenen Dienst entfernen will, aber die Information für einen aufgestellten Dienst behalten will.
Die Bereitstellungstemplates sind für die Bereitstellung der richtigen Information in jedem der Schritte der Entwicklung eines Dienstes entscheidend. Die Templates sind innerhalb des SDM und der Inhalt der Templates hängt, falls es ein Template ist, das einen aufgestellten Dienst beschreibt, von einem vorgesehenen Dienst oder einem angebotenen Dienst ab. Eine allgemeine Struktur wird jedoch für alle Bereitstellungstemplates die gleiche sein und wird mit Bezug auf Fig. 7 beschrieben.
Wie in der Figur angezeigt, wird ein Bereitstellungstemplate 700 die folgenden Hauptteile umfassen:

- Templatekopf 705, umfassend einen standardisierten XML- Schema-Dateikopf;
- Bereitstellungsprotokollinformation 710, die die angegliederten Daten, die Bereitstellung benötigen, und die unterstützten Bereitstellungsanforderungen beschreibt;
- Abbildungsregeln 720, die beschreiben, wie die Bereitstellungsanforderungen, die in einem Anwendungs- (angegliederten) System unterstützt werden, auf Geschäftsverwaltungssysteme abgebildet werden sollten. Abbildungsregeln existieren nicht für aufgestellte Dienste; und
- Dienstrichtlinie 730, die beschreibt, wann und wie der Dienst verwendet werden kann.

Die Bereitstellungsprotokollinformation 710 kann ferner einige der folgenden Teile umfassen, die als Beispiele von Information betrachtet werden sollten, die in der Bereitstellungsprotokollinformation 710 vorgesehen ist.

- Bereitstellungsprotokoll 711, das die Bereitstellungsschnittstelle entscheidet, die durch die Angliederung unterstützt wird;
- Befehlstemplate 712, das Information über die möglichen angegliederten Befehle umfasst, die zu der Angliederung gesendet werden. Der Inhalt in dieser Sektion unterscheidet sich abhängig von der Bereitstellungsschnittstelle, die durch die Angliederung unterstützt wird.
- Attributliste 713, die alle Attribute beschreibt, die für eine Bereitstellung des Dienstes in der Angliederung erforderlich sind. Die Attributliste wird immer den Attributnamen, Datentyp und Vorgabewerte enthalten. Die zulässigen Datentypen der Attribute hängen von der Schnittstelle ab, die zu der Angliederung verwendet wird.
- Attribute einer gemeinsam genutzten Ressource 714, die Attribute definieren, die sich auf gemeinsam genutzte Ressourcen beziehen. Das Attribut einer gemeinsam genutzten Ressource 714 verweist stets auf ein existierendes Attribut in der Attributliste 713.
- Kontextattribute 715 sind der Schlüsselbezeichner für einen Benutzer oder Teilnehmer in dem angegliederten System. Das Kontextattribut 715 verweist stets auf ein existierendes Attribut in der Attributliste 713.

Wie Daten in dem SCR gemäß der vorliegenden Erfindung gespeichert werden, wird weiter in einem Beispiel veranschaulicht, das mit Bezug auf Fig. 8a und b beschrieben wird. Die Daten werden in Übereinstimmung mit dem Dienstdatenmodell SDM gespeichert, das mit Bezug auf Fig. 6 und Fig. 7 beschrieben wird, auf die in diesem Beispiel auch verwiesen wird. In dem veranschaulichenden Beispiel werden die vier Dienste gespeichert und haben entsprechende Datensätze: lokale Filmankündigung 810 : 1, lokale Wettervorhersage 810 : 2, mobile Positionierung 810 : 3 und Bankdienst 810 : 4. Jeder Dienstdatendatensatz umfasst mehrere Attribute inkludierend eine Dienst-ID, einen Dienstnamen und einen Dienststatus. Die Dienste sind in zwei Dienstgruppen gruppiert, Dienstgruppe A 805 : 1 bzw. Dienstgruppe B 805 : 2, gemäß einem Bereitsteller. Es sind andere Wege zum Gruppieren möglich. Jede Datensatzdienstgruppe umfasst eine Dienstgruppen-ID und einen Dienstgruppennamen. Lokale Filmankündigung 810 : 1 und lokale Wettervorhersage 810 : 2 gehören zu Dienstgruppe A 805 : 1. Mobile Positionierung 810 : 3 und Bankdienst 810 : 4 gehören zu Dienstgruppe B 805 : 2.
Jeder Dienst wird detailliertere Dienstinformation gespeichert haben, wie in Fig. 8b veranschaulicht. Diese Information wird Spezifikationen über die Dienstabhängigkeiten 850 haben: in dem Beispiel hängt lokale Filmankündigung 810 : 1 von mobiler Positionierung 810 : 3 ab. Diese Abhängigkeit ist in dem Feld Dienstabhängigkeiten 850 vorzugsweise durch Spezifizieren der Dienst-ID des Dienstes (mobile Positionierung) definiert, von dem lokale Filmankündigung abhängig ist.
Lokale Wettervorhersage hängt von mobiler Positionierung 830 und Bankdienst 840 ab (nicht gezeigt). In diesem Fall werden die Dienstabhängigkeiten 865 zwei Dienst-ID's inkludieren, die auf mobile Positionierung 830 bzw. Bankdienst 840 verweisen.
Die Dienstinformation, die durch den Dienstdatendatensatz vorgesehen wird, umfasst ferner in Übereinstimmung mit dem SDM (Fig. 6) die Felder Bereitstellungszugriffsdefinition 820, Dienstinstanz 830, vorgesehener Dienst 940 und Dienstzugriffsdefinition. Der Zweck dieser Felder ist oben in der Beschreibung des SDM angegeben.
Die Trennung von Benutzer-/Teilnehmerinformation (gespeichert in CSD), Dienstinformation (gespeichert in SCR) und angegliederten Daten ist ein wichtiger Teil des erfinderischen Konzepts der vorliegenden Erfindung. Um die Beziehungen zwischen der CSD und dem SCR zu veranschaulichen, wird eine Beschreibung der CSD und des Benutzerdatenmodells gegeben.
Die Benutzer-/Teilnehmerdaten werden gemäß einem Benutzerdatenmodell UDM gespeichert, was zu einem Benutzerdatendatensatz (User Data Record, UDR) führt, der in der CSD gespeichert wird, der tatsächliche benutzerbezogene Daten und Endbenutzerabonnements für Dienste umfasst. Das Prinzip des Benutzerdatenmodells wird mit Bezug auf Fig. 9 beschrieben. Der Benutzerdatendatensatz UDR wird nach den Prinzipien des UDM aufgebaut. Die Struktur der Daten, die in der CSD gespeichert werden, muss sorgfältig gestaltet werden, um interne Replikation von Daten zu vermeiden, die richtigen Verknüpfungen zu den Systemen zum Vorsehen von Diensten und Aufrechterhalten der benötigten Daten auf dem logischsten Weg vorzusehen. Die Daten werden logisch in Objekte gruppiert, wobei Schlüsselobjekte Teilnehmer, Benutzer und Dienst in Übereinstimmung zu den oben beschriebenen Hauptentitäten sind. Ein Objekt entspricht einem Feld in dem UDR. Die Pfeile in der Figur zeigen Verknüpfungen zwischen den Objekten an. Die Implementierung kann abhängig von der Technologie variieren, die verwendet wird, um die CSD aufzubauen, aber die logische Gruppierung sollte die gleiche sein.
Die folgenden Objekte sollten vorzugsweise in dem UDM beinhaltet sein:

- Benutzer 905: enthält Basisbenutzerinformation (z. B. Benutzeridentitäten). Ein Benutzer 905 gehört stets zu einem Teilnehmer 910;
- Teilnehmer 910: enthält Basisteilnehmerinformation (z. B. Teilnehmeridentitäten);
- Kundensegment 915: verwendet, um Teilnehmer 910 zu klassifizieren. Enthält Kundensegmentbeschreibung und Basisdaten;
- Angebotener Dienst 920: enthält Dienstbasisinformation;
- Dienstpaket 925: verwendet, um Dienste 920 zu verpacken;
- Dienstpäketabonnement 930: verwendet, um ein effektives Abonnement eines Dienstpakets 925 durch einen Teilnehmer 910 widerzuspiegeln;
- Dienstabonnement 935: verwendet, um effektive Abonnements einzelner Dienste 920 in einem Dienstpaket durch einen Teilnehmer, der durch das Dienstpaketabonnement 930 angegeben ist, widerzuspiegeln;
- Dienstaktivierung 940: verwendet, um eine effektive Aktivierung eines einzelnen Dienstes aus dem Dienstabonnement 935 durch einen Benutzer 905 widerzuspiegeln;
- Falls Abhängigkeiten zwischen Dienstsystemen innerhalb des UDR zu handhaben sind, enthält die durch Teilnehmer gemeinsam genutzte Ressource 945 Basisdaten der gemeinsam genutzten Ressource, die in einem bestimmten Dienst verwendet wird, der durch einen Teilnehmer 910 abonniert ist und durch das Dienstabonnement 935 angegeben ist; und
- durch Benutzer gemeinsam genutzte Ressource 950: enthält Basisdaten der gemeinsam genutzten Ressource, die in einem bestimmten aktivierten Dienst 940 durch einen Benutzer 905 verwendet wird.

Das Benutzerobjekt 905 und das Teilnehmerobjekt 910 sind Beispiele von Identifikationsobjekten. Das Dienstabonnementobjekt 935 und die Dienstaktivierungsobjekte 940 sind Beispiele von Dienstobjekten. Alle Dienste, die in dem Dienstnetz 200 vorhanden sind, sind durch das UDM bekannt. Der Teilnehmer 910 kann dann einen Dienst abonnieren. Das Objekt eines angebotenen Dienstes 920 enthält Information über alle angebotenen Dienste und enthält Verweise oder Verknüpfungen zu Dienstdaten, die in dem SCR 970 gespeichert sind, dargestellt durch das Objekt eines vorgesehenen Dienstes 975 (640). Dies ist vorzugsweise die einzige direkte Verknüpfung zwischen den UDR-Daten und dem SCR. Ein Teilnehmer 910 könnte Dienste einen nach dem anderen abonnieren, aber dies würde die Bereitstellung umständlich machen. Vorzugsweise werden ähnliche Dienste oder ein Dienst, die/der wahrscheinlich den gleichen Teilnehmer anziehen, gemeinsam gruppiert, was in dem Objekt Dienstpaket 925 widergespiegelt wird. Ein bestimmter Dienst kann in einer Vielzahl von Dienstpaketen angeboten werden. Außerdem kann ein Dienstpaket einer Gruppe von Teilnehmern mit den gleichen Charakteristika und erwarteten Bedürfnissen angeboten werden. Deshalb können Teilnehmer 910 in ein Kundensegment 915 gruppiert werden, und der Teilnehmer 910 kann alle Dienste abonnieren, die dem Kundensegment angeboten werden, zu dem er gehört. Ein Dienst wird einem Kundensegment durch sein Inkludieren in ein oder mehr Dienstpakete 925 hinzugefügt. Kurz gesagt, Dienstpakete 925 gruppieren Dienste 920 und Kundensegment 915 gruppiert Teilnehmer 910.
Bezugnehmend auf das Beispiel eines angebotenen Dienstes, das mit Bezug auf Fig. 9 beschrieben wird, sind lokale Filmankündigung 910 : 1, lokale Wettervorhersage 910 : 2, mobile Positionierung 910 : 3 und Bankdienst 910 : 4 in der CSD durch den angebotenen Dienst 920 registriert. Die Dienste können außerdem als ein Dienstpaket, spezifiziert im Dienstpaket 925, registriert sein, z. B. ein Paket, das "lokalisierter Dienst" genannt wird und die Dienste lokale Filmankündigung und lokale Wettervorhersage inkludiert.
Das Dienstkomponentenregister und die Dienstdatendatensätze erleichtern eine zentralisierte Bereitstellung von Diensten in dem Dienstnetz. Durch das UDM werden die Dienste den Endbenutzern auf einem vereinheitlichten Weg angeboten. Durch diese Anordnung wird eine stabile Umgebung in dem Dienstnetz geschaffen und eine schnelle und sichere Bereitstellung von Diensten wird sichergestellt.
Während die Erfindung in Verbindung mit dem beschrieben wurde, was gegenwärtig als die praktischsten und bevorzugten Ausführungsformen betrachtet wird, ist zu verstehen, dass die Erfindung nicht auf die offengelegten Ausführungsformen zu begrenzen ist, sondern es ist im Gegenteil beabsichtigt, verschiedene Modifikationen und äquivalente Anordnungen abzudecken, die innerhalb des Geists und Bereichs der angefügten Ansprüche inkludiert sind.

Beispiel eines Anwendungsfalls

Vorbedingungen

Es wird ein detailliertes Beispiel eines typischen Bereitstellungsszenario angegeben, in dem ein Endbenutzer den lokalen Wettervorhersagedienst aktiviert. Das Beispiel basiert auf den folgenden Voraussetzungen:

- Die angebotenen Dienste und Dienste wurden eingerichtet, wie oben beschrieben.
- Ein Teilnehmer wurde erstellt.
- Benutzer, die zu dem Teilnehmer gehören, wurden erstellt.
- Der Teilnehmer gehört zu einem Kundensegment, dem eine Bereitstellung des Dienstpaketes "lokalisierte Dienste" erlaubt ist.
- Der Teilnehmer, der zu unserem Endbenutzer gehört, hat das Dienstpaket "lokalisierte Dienste" abonniert.

Ereignisfluss

Nachstehend folgt eine Beschreibung des typischen Ereignisflusses, wenn ein Endbenutzer den Dienst abonniert. Das genaue Verhalten wird von der kundenspezifischen Einrichtung des Dienstnetzes abhängen.

1. Der Endbenutzer wünscht, sich nach neuen verfügbaren Diensten in seinem Portal umzusehen, und verwendet ein WAP- (drahtloses Applikationsprotokoll, Wireless Application Protocol) Endgerät, um auf die Homepage des Portals zuzugreifen.
2. Das Portal wird die verfügbaren Dienste für diesen Benutzer durch Senden einer CAI3 G-Anforderung zu CPE anfordern.
3. CPE wird überprüfen, welche Dienste für diesen Benutzer verfügbar sind, durch Überprüfen des Inhalts der Dienstpaketes, die durch den Teilnehmer abonniert sind, zu dem der Benutzer gehört. Diese Information befindet sich in der CSD.
4. CPE antwortet mit einer CAI3G-Antwort zu dem Portal.
5. Das Portal erstellt eine WAP-Seite mit Information über die verfügbaren Dienste. Es ist zu beachten, dass die Antwort von CPE nur die Information enthält, die dem Endbenutzer zu präsentieren ist. Sie enthält keinerlei Information darüber, wie sie dargestellt werden sollte. Das Portal sollte dies selbst durch Verwendung von Technologien wie style sheets (Stilblätter) und Endgerätedatenbanken lösen.
6. Der Endbenutzer findet den lokalen Wettervorhersagedienst und den lokalen Filmankündigungsdienst. Er entscheidet, den lokalen Wettervorhersagendienst zu aktivieren.
7. Das Portal fordert die Dienstparameter für diesen Dienst von CPE an.
8. CPE schaut in SCR nach, um irgendwelche Dienstabhängigkeiten zu finden. Der lokale Wettervorhersagedienst hängt von dem Positionierungsdienst und einem Bankdienst ab.
9. CPE überprüft, ob der Endbenutzer den Positionierungsdienst und den Bankdienst bereits abonniert hat. Da in CSD bereits ein Bankdienstabonnement existiert hat, wird dieses Abonnement erneut verwendet, aber ein Positionierungsdienst wird zu erstellen sein.
10. CPE liest das Bereitstellungstemplate für einen angebotenen Dienst für den lokalen Wettervorhersagedienst und den Positionierungsdienst. Diese Information ist als XML-Dateien in CD gespeichert. Die XML-Dateien werden dem Format folgen, das durch den angebotenen Dienst XML schCPEs entschieden wird.
11. CPE wird die Attributinformation aus den beiden Templates in einer neuen XML-Zeichenkette verketten und dies zu dem Portal zurückgeben.
12. Das Portal wird eine neue WAP-Seite mit einem Eingabefeld für jedes Attribut erstellen, das es in der XML-Antwort von CPE findet. Es wird einen Bezeichner entsprechend dem Attributnamen und ein Eingabefeld hinzufügen, das zu dem Datentyp des Attributs passt.
13. Der Endbenutzer wird alle Eingabefelder in der grafischen Benutzeroberfläche (GUI) ausfüllen und den OK-Knopf drücken.
14. Das Portal wird die Daten gemäß der Attributinformation validieren, die durch CPE vorgesehen wurde. Es wird überprüfen, dass alle zwingend notwendigen Attribute ausgefüllt wurden und dass alle Daten innerhalb der spezifizierten gültigen Bereiche sind.
15. Das Portal sendet eine CAI3G-Anforderung, um das Abonnement zu erstellen, zu CPE. Als einen Eingabeparameter wird es die XML-Zeichenkette mit allen ausgefüllten Endbenutzerdaten inkludieren.
16. CPE wird Dienstinstanzdaten von SCR erhalten und die am meisten geeignete Instanz für eine Bereitstellung für den Benutzer auswählen. Dies wird basierend auf dem Ergebnis des Verteilungsalgorithmus geschehen (auch in dem SCR gefunden).
17. CPE erstellt die Angliederungsbereitstellungsbefehle gemäß dem Bereitstellungstemplate für einen aufgestellten Dienst, gefunden in dem SCR.
18. CPE sendet die Bereitstellungsbefehle zu Angliederungen (unter Verwendung von CAI3G, CAI oder LDAP).
19. CPE aktualisiert die Benutzerdaten in CD.
20. CPE aktualisiert E-AAA.
21. CPE sendet eine OK-Antwort zu dem Portal.
22. CPE benachrichtigt CAS (Kundenverwaltungssystem, Customer Administrative System) (falls das CAS für Benachrichtigungen über diesen Typ von Ereignissen abonniert wurde).

Claims

1. System, angepasst zur Bereitstellung von Diensten in einem Dienstnetz (200) mit einer Vielzahl von Dienstsystemen zum Vorsehen einer Vielzahl von Diensten, wobei das System ein Systemkomponentenregister (SCR) umfassend Dienstinformation in Bezug auf eine Vielzahl von Diensten in dem Dienstnetz umfasst, die Dienstinformation in Dienstdatendatensätzen gespeichert ist, einer für jeden Dienst oder Gruppe von Diensten, und wobei jeder Dienstdatendatensatz umfasst:
mindestens ein Dienstinstanzfeld (540; 630), das eine Dienstinstanz für den spezifischen Dienst oder Gruppe von Diensten identifiziert; und
mindestens ein Abhängigkeitsfeld (550; 650), das Abhängigkeiten für den spezifischen Dienst oder Gruppe von Diensten zu mindestens einem anderen Dienstsystem in dem Dienstnetz definiert, falls der spezifische Dienst oder Gruppe von Diensten ein komplexer Dienst ist oder eine gemeinsam genutzte Ressourcen nutzt, wodurch das Dienstkomponentenregister und die Dienstdatendatensätze eine zentralisierte Bereitstellung von Diensten in dem Dienstnetz erleichtern.

2. System nach Anspruch 1, wobei der Dienstdatendatensatz ferner umfasst:
ein Dienstfeld (610), das Information in Bezug auf einen Dienst enthält;
ein Dienstzugriffsdefinitionsfeld (615), das Information darüber enthält, wie der Dienst zu verwenden ist;
ein Bereitstellungszugriffsdefinitionsfeld (620), das Information darüber enthält, wie der Dienst bereitzustellen ist.

3. System nach Anspruch 2, wobei der Dienstdatendatensatz ferner die Felder umfasst:
Feld eines aufgestellten Dienstes (510), das Information über einen Dienst umfasst, der in dem Dienstnetz installiert und registriert wurde; und
Feld eines vorgesehenen Dienstes (520; 640), das eine Spezialisierung des aufgestellten Dienstes darstellt.

4. System nach Anspruch 2, wobei der Dienstdatendatensatz ferner mindestens ein Templatefeld (562, 561; 620, 640) umfasst, das Bereitstellungstemplates spezifiziert, die für den Dienst relevant sind, wobei die Bereitstellungstemplates die Information, die für eine Bereitstellung eines Dienstes erforderlich ist, und die Bereitstellungsoperationen, die durch das Dienstsystem unterstützt werden, definieren.

5. System nach Anspruch 4, wobei mindestens eines der Bereitstellungstemplates in dem SCR gespeichert wird.

6. System nach Anspruch 4, wobei die Bereitstellungstemplates in einem Format gespeichert sind, das kompakt und leicht austauschbar ist, z. B. als XML-Dateien (extended Markup Language).

7. System nach Anspruch 2, wobei das Bereitstellungszugriffsdefinitionsfeld (620) ferner das Bereitstellungstemplate für einen aufgestellten Dienst spezifiziert.

8. System nach Anspruch 1, wobei der Dienstdatendatensatz ferner ein Dienstgruppen- (605) Feld umfasst, das mindestens zwei Dienste identifiziert, die gemeinsam gruppiert sind.

9. Dienstdatenmodell, angepasst, um für eine Bereitstellung von Diensten in einem Dienstnetz (200) mit einer Vielzahl von Dienstsystemen zum Vorsehen einer Vielzahl von Diensten verwendet zu werden, wobei das Dienstdatenmodell Dienstinformation in Bezug auf eine Vielzahl von Diensten in dem Dienstnetz umfasst, die Dienstinformation in Dienstdatenobjekten strukturiert ist, eines für jeden Dienst oder Gruppe von Diensten, und wobei jedes Dienstdatenobjekt umfasst:
mindestens ein Dienstinstanzobjekt (540; 630), das eine Dienstinstanz für den spezifischen Dienst oder Gruppe von Diensten identifiziert; und
mindestens ein Abhängigkeitsobjekt (550; 650), das Abhängigkeiten für den spezifischen Dienst oder Gruppe von Diensten zu mindestens einem anderen Dienstsystem in dem Dienstnetz definiert, falls der spezifische Dienst oder Gruppe von Diensten ein komplexer Dienst ist oder eine gemeinsam genutzte Ressource nutzt, wodurch das Dienstdatenmodell eine zentralisierte Bereitstellung von Diensten in dem Dienstnetz erleichtert.

10. Datenmodell nach Anspruch 9, wobei das Dienstdatenobjekt ferner umfasst:
ein Dienstobjekt (610), das Information in Bezug auf einen Dienst enthält;
ein Dienstzugriffsdefinitionsobjekt (615), das Information darüber enthält, wie der Dienst zu verwenden ist;
ein Bereitstellungszugriffsdefinitionsobjekt (620), das Information darüber enthält, wie der Dienst bereitzustellen ist.

11. Datenmodell nach Anspruch 10, wobei der Dienstdatendatensatz ferner die Objekte umfasst:
Objekt eines aufgestellten Dienstes (510), das Information über einen Dienst umfasst, der in dem Dienstnetz installiert und registriert wurde; und
Objekt eines vorgesehenen Dienstes (520; 640), das eine Spezialisierung des aufgestellten Dienstes darstellt.

12. Datenmodell nach Anspruch 9, wobei das Dienstdatenobjekt ferner mindestens ein Templateobjekt (562, 561) umfasst, das Bereitstellungstemplates spezifiziert, die für den Dienst relevant sind, wobei die Bereitstellungstemplates die Information, die für eine Bereitstellung eines Dienstes benötigt wird, und die Bereitstellungsoperationen, die durch das Dienstsystem unterstützt werden, definieren.

13. Datenmodell nach Anspruch 12, wobei mindestens eines der Bereitstellungstemplates in dem SCR gespeichert wird.

14. Datenmodell nach Anspruch 12, wobei die Bereitstellungstemplates in einem Format gespeichert sind, das kompakt und leicht austauschbar ist, z. B. als XML-Dateien (extended Markup Language).

15. Datenmodell nach Anspruch 10, wobei das Bereitstellungszugriffsdefinitionsobjekt (620) ferner das Bereitstellungstemplate für einen aufgestellten Dienst definiert.

16. Datenmodell nach Anspruch 9, wobei das Dienstdatenobjekt ferner ein Dienstgruppenobjekt (605) umfasst, das mindestens zwei Dienste identifiziert, die gemeinsam gruppiert sind.

17. Verfahren zum Bereitstellung von Diensten in einem Dienstnetz, wobei Dienstinformation in Bezug auf eine Vielzahl von Diensten in einem Systemkomponentenregister (SCR) gespeichert ist, wobei das Verfahren die Schritte umfasst:

- Aufstellen (410) des Dienstes in dem Dienstnetz durch Vorsehen einer ersten Darstellung des Dienstes in dem SCR;

- Vorsehen (420) des Dienstes durch Vorsehen einer zweiten Darstellung des Dienstes in dem SCR, wobei die zweite Darstellung des Dienstes eine Spezialisierung der ersten Darstellung ist.

18. Verfahren nach Anspruch 17, ferner den Schritt umfassend:

- Anbieten (430) des Dienstes an Endbenutzer durch Vorsehen einer dritten Darstellung des Dienstes in einer gemeinsamen Teilnehmer-/Benutzerdatenbank (CSD), wobei die dritte Darstellung des Dienstes eine Spezialisierung der zweiten Darstellung des Dienstes ist.

19. Verfahren nach Anspruch 17, wobei der Schritt zum Aufstellen (410) des Dienstes durch Verwenden eines Bereitstellungstemplates eines aufgestellten Dienstes (440) durchgeführt wird, das Benutzerdaten spezifiziert, die bereitzustellen sind, und um die Operationen zu definieren, die durch das Dienstsystem, das den Dienst vorsieht, unterstützt werden.

20. Verfahren nach Anspruch 17, wobei der Schritt zum Vorsehen (420) des Dienstes durch Verwenden eines Bereitstellungstemplates eines vorgesehenen Dienstes (450) durchgeführt wird.

21. Verfahren nach Anspruch 18, wobei der Schritt zum Anbieten (430) des Dienstes durch Verwenden eines Bereitstellungstemplates eines angebotenen Dienstes (460) durchgeführt wird.