-
Die
vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen von
persönlichen
Diensten für ein
an ein Kommunikationsnetz angeschlossenes Kommunikationsmittel eines
Benutzers. Weiterhin betrifft die Erfindung einen Dienstrechner
dafür,
einen Dienstserver dafür,
einen Dienstcontainer dafür,
ein Dienstrechnermodul für
einen Dienstrechner und ein Dienstservermodule für einen Dienstserver.
-
Bekannten
Kommunikationsnetze, z.B. so genannte Intelligente Netze (Intelligent
Networks – IN),
stellen vordefinierte Gruppen von Kommunikationsdiensten für Kommunikationsmittel
von Benutzern, z.B. für
Fernsprechendgeräte
oder Personalcomputer von Teilnehmern, bereit. Zu diesem Zweck ist
in einem Intelligenten Netz zum Beispiel ein globaler Dienstesteuerungsknoten
(Service Control Point – SCP) über das
zentrale Zeichengabenetz Nr. 7 mit mehreren Dienstevermittlungsknoten
(Service Switching Points – SSPs)
verbunden. Der Dienstesteuerungsknoten steuert zentral die Bereitstellung
eines oder mehrerer Kommunikationsdienste für die mit dem Dienstesteuerungsknoten
verbundenen Dienstevermittlungsknoten.
-
Ein
solches Intelligentes Netz ist aus
U.S. Patent
Nr. 6,061,729 bekannt, das ein Telekommunikationsnetz mit
einem Client-System und einem Server-System beschreibt. Das Client-System
weist eine Dienstnachricht und eine Client-Schnittstelle auf. Die Dienstnachricht
hat ein Standardformat und ist geeignet, mindestens eine Plattformmanager-Operation, welche
das Server-System betreffende Informationen anfordert, eine Datenbank-Operation, die eine Modifizierung
von einen Dienst im Server-System betreffenden Informationen anfordert,
und eine Dienstmanager-Operation zu definieren, die eine Verwaltung
des Dienstes im Server-System anfordert. Das Server-System enthält einen
Plattformmanager, ein Datenbank-Subsystem, einen Dienstmanager und eine
Server-Schnittstelle.
Der Plattformmanager ist geeignet, das Server-System betreffende
Informationen zu speichern und bereitzustellen. Das Datenbank-Subsystem
ist geeignet, den Dienst betreffende Informationen zu speichern
und bereitzustellen. Der Dienstmanager ist geeignet, den Dienst
im Server-System zu verwalten. Die Server-Schnittstelle ist geeignet, die von
der Client-Schnittstelle über das Netz übertragene
Dienstnachricht zu empfangen und eine darin enthaltene Plattformmanager-Operation zum Plattformmanager,
eine enthaltene Datenbank-Operation
zum Datenbank-System und eine enthaltene Dienstmanager-Operation
zum Dienstmanager zwecks Ausführung
weiterzuleiten.
-
Die
Dienstevermittlungsknoten sind speziell ausgerüstete Kommunikationsnetzknoten.
Wenn eine dieser Vermittlungsstellen von einem Teilnehmerendgerät des Kommunikationsnetzes
eine spezielle Aufforderung zum Aufbau einer Verbindung erhält, wird
diese Information an eine im Dienstevermittlungsknoten integrierte
Dienstvermittlungsfunktion adressiert, die wiederum eine Dienstanforderungsnachricht
an den globalen Dienstesteuerungsknoten sendet. Im Dienstesteuerungsknoten
triggert diese Anforderungsnachricht eine ihr zugeordnete Dienstlogik,
welche dann die Bereitstellung des Kommunikationsdienstes steuert,
indem sie zum Beispiel den Dienstesteuerungsknoten anweist, die
spezielle Aufforderung zum Aufbau einer Verbindung mit einer anderen
Fernsprech-Zielnummer zu verbinden, oder die Aufforderung zu einem
Dienstunterstützungssystem,
z.B. einem intelligenten Peripheriegerät (Intelligent Peripheral – IP) leitet,
das Sprachnachrichten ausgibt oder eine Spracherkennung durchführt.
-
Wenn
ein Teilnehmer eines Kommunikations-"Heimnetzes" vorübergehend
von seinem Heimnetz in ein besuchtes Kommunikationsnetz wechselt, dann
erwartet er von dem besuchten Kommunikationsnetz, dass dieses eine
so genannte virtuelle Heimumgebung (Virtual Home Environment – VHE) bereitstellt,
die aus einer vordefinierten Gruppe von Kommunikationsdiensten besteht,
welche üblicherweise
von Kommunikations-Heimnetzen entsprechend dem persönlichen
Profil eines Teilnehmers bereitgestellt werden. Auch wenn das Kommunikations-Heimnetz
das persönliche
Profil des Teilnehmers zu dem besuchten Kommunikationsnetz überträgt, ist letzteres
normalerweise nicht in der Lage, alle durch das Teilnehmerprofil
definierten Arten von Kommunikationsdiensten durchzuführen. So
ist zum Beispiel das intelligente Peripheriegerät (IP) des besuchten Netzes
nicht in der Lage, Spracherkennung durchzuführen, oder es steht in einem
Dienstesteuerungsknoten des besuchten Kommunikationsnetzes keine Dienstlogik
für die
Bereitstellung eines speziellen Kommunikationsdienstes zur Verfügung. Auch
wenn die Dienstlogik zur Verfügung
steht, z.B. vom Kommunikations-Heimnetz zum besuchten Kommunikationsnetz
transferiert wurde, kann im Dienstesteuerungsknoten eine Dienstausführungsplattform,
welche die Dienstlogik ausführen
kann, fehlen.
-
In
einem anderen Szenario ist das Teilnehmerendgerät an ein Datenkommunikationsnetz
angeschlossen, zum Beispiel an das Internet. In diesem Fall führt ein
vorgegebener Internet-Server oder ein Server-Cluster des Heimnetzbetreiters
die persönlichen
Kommunikationsdienste für
den Teilnehmer aus. Solche Dienste können mehr daten-orientiert oder mehr
sprach-orientiert sein. Unter Verwendung von z.B. VOIP (Voice over
Internet Protocol) ist das Benutzerendgerät über das Internet mit einem
Dienstesteuerungsknoten des Benutzer-Heimnetzes verbunden. Je nach
dem augenblicklichen Standort des Endgeräts kann eine zufällig große Entfernung
zwischen dem Server und dem Endgerät eine beträchtliche Netzbelastung verursachen.
Außerdem
ist in diesem Fall die Antwortzeit bei der Nutzung eines Dienstes
am Endgerät
unangenehm lang.
-
Bei
beiden vorstehend erwähnten
Beispielen ist die Bereitstellung der persönlichen Dienste für ein Kommunikationsmittel
eines Benutzers weitgehend von der Architektur und den Fähigkeiten
des jeweiligen, vom Benutzer aktuell benutzten Kommunikationsnetzes
abhängig.
-
Zusammenfassung der Erfindung
-
Es
ist somit Aufgabe der Erfindung, persönliche Dienste für ein Kommunikationsmittel
eines Benutzers weitgehend unabhängig
von einem Kommunikationsnetz, an welches das Kommunikationsmittel angeschlossen
ist, bereitzustellen.
-
Diese
Aufgabe soll durch Verfahren gemäß dem technischen
Grundprinzip des Anspruchs 1, einen Dienstrechner gemäß dem technischen
Grundprinzip des Anspruchs 7, ein Dienstrechner-Modul gemäß dem technischen
Grundprinzip des Anspruchs 8, einen Dienstserver gemäß dem technischen
Grundprinzip des Anspruchs 9, ein Dienstserver-Modul gemäß dem technischen
Grundprinzip des Anspruchs 10 und einen Dienstcontainer gemäß dem technischen
Grundprinzip des Anspruchs 11 gelöst werden. Vorteilhafte Ausgestaltungen
der Erfindung ergeben sich aus den abhängigen Ansprüchen und der
Beschreibung.
-
Ein
Grundprinzip der Erfindung besteht darin, dass ein Dienstrechner
die Funktion einer netzunabhängigen
Dienstausführungsplattform übernimmt,
die einen Dienstcontainer ausführt,
der über ein
Kommunikationsnetz, an welches das Endgerät gerade angeschlossen ist,
einen persönlichen
Dienst für
ein Kommunikationsmittel eines Benutzers, z.B. ein Endgerät, bereitstellt.
Zu diesem Zweck bietet der Dienstrechner dem Dienstcontainer mindestens
eine Netzsperre, die eine vordefinierte Schnittstelle zu dem Kommunikationsnetz
ist. Ein vom Betreiber des Benutzer-Heimnetzes betriebener Dienstserver überträgt den Dienstcontainer
zum Dienstrechner, zum Beispiel als Antwort auf eine vom Benutzerendgerät übertragene
Dienstanforderung für
den persönlichen Dienst.
Der Dienstcontainer enthält
eine Dienstmaschine, welche die Ausführung des persönlichen Dienstes
für das
Benutzerendgerät
regelt. Dazu führt die
Dienstmaschine mindestens eine Dienstkomponente aus, die zusammen
mit der Dienstmaschine im selben Dienstcontainer übertragen
wird. Die Dienstkomponente kann auch über einen anderen Dienstcontainer
zum Dienstrechner übertragen
werden. Für die
Bereitstellung des persönlichen
Dienstens verwendet der Dienstcontainer die Netzsperre, welche zum
Beispiel eine Schnittstelle zu einer Anrufverbindung zum Benutzerendgerät ist.
-
Der
Dienstrechner ist eine netz- und betreiberunabhängige Ausführungsplattform für Dienstcontainer
und steuert den Zugang des jeweiligen Dienstcontainers zu dem Kommunikationsnetz über die
Netzsperre(n). Auf diese Weise kann je nach dem dezentralen Standort
des Dienstrechners der Dienstcontainer nahe beim aktuellen Standort
des Endgeräts
ausgeführt
werden, für
welches der Dienstcontainer den persönlichen Dienst bereitstellt.
Der Betreiber des Kommunikationsnetzes, an welches das Benutzerendgerät gerade
angeschlossen ist, braucht weder komplexe Dienstausführungsplattformen
zu betreiben, wie z.B. die oben erwähnten Dienstesteuerungsknoten,
die speziell für
die Ausführung
vordefinierter Dienstlogiken angepasst sind, noch dedizierte Dienstressourcenpunkte bereitzustellen,
wie z.B. das erwähnte
Intelligente Peripheriegerät
(IP), das Sprachnachrichten ausgibt und Spracherkennung durchführt. Der
kontrollierte Zugang zum Kommunikationsnetz wird durch den Dienstrechner
geregelt, wohingegen der Dienstserver Dienstcontainer bereitstellt,
die für
die vom Dienstrechner angebotenen Sperren angepasst sind. Im Wesentlichen
braucht der Betreiber lediglich einen Dienstrechner zu betreiben,
der eine einfache Struktur aufweist, wie z.B. der Network Computer
in der Java-Architektur. Der Dienstrechner führt einen Dienstcontainer aus
und bietet diesem ein gesteuerte Netzsperre zum Kommunikationsnetz.
Auch kann ein unabhängiger
Drittbetreiber den Dienstrechner im Auftrag des Betreibers des Kommunikationsnetzes
betreiben. Die Dienstcontainer selbst enthalten die angeforderte Dienstinstanz
und führen
diese aus. Die Dienstinstanz ist zum Beispiel ein Programmmodul
oder ein Objekt, das individuell konfigurierte und standardisierte
Dienste ausführt,
z.B. Dienste des Intelligenten Netzes (IN) gemäß so genannten Capability Sets, wie
sie von der International Telecommunication Union (ITU), dem ehemaligen
CCITT (Comité Consultatif International
Télégraphique
et Téléphonique),
definiert wurden. Mögliche
von den Dienstcontainern ausgeführte
Dienste sind zum Beispiel Rufumleitung im Besetztfall (Call Forwarding
(if the called party is) Busy – CFB),
Spracherkennung oder ein Postfachdienst, der Nachrichten für einen
Benutzer speichert. Unabhängig
von dem Kommunikationsnetz, das gerade das Benutzerendgerät bedient,
kann der Benutzer eine reale oder virtuelle Heimumgebung und die ganze
Palette der dieser Heimumgebung zugeordneten persönlichen Dienste
nutzen. Außerdem
ist die Schnittstelle zwischen dem Dienstrechner und dem Dienstserver
recht einfach, da lediglich Dienstcontainer übertragen werden, welche Dienstinstanzen
einkapseln. Weiterhin wird die Einführung eines neuen oder modifizierten
Dienstes erleichtert, da lediglich ein die Instanz des neuen Dienstes
enthaltender Dienstcontainer, jedoch keine Anpassung des Dienstrechners
an den neuen Dienstcontainer erforderlich ist.
-
Vorteilhafterweise
stellt der Dienstrechner für den
Dienstcontainer eine Monitorsperre bereit, über die der Dienstcontainer
den Dienstserver über
den Zustand des Dienstrechners informiert. Die Monitorsperre könnte auch
als "Call and Session
Detailed Record"-Sperre
(CDR Lock) bezeichnet werden, da über die Monitorsperre gesendete
Daten zum Beispiel Informationen über die Auslastung des Dienstrechners
und/oder die Auslastung der Netzsperre(n) enthalten. Abhängig von
diesen Informationen stellt der Dienstserver dem Benutzer den persönlichen Dienst
in Rechnung und/oder steuert er die Bereitstellung des persönlichen
Dienstes, z.B. überträgt er weitere
Dienstcontainer, die weitere Dienstkomponenten enthalten, zu einem
zweiten Dienstrechner, wenn der für das Endgerät zuständige erste
Dienstrechner zum Beispiel nahe an der Überlastungsgrenze ist. Die
Monitorsperre kann in die oben erwähnte Netzsperre integriert
werden.
-
Für das Management
der Dienstbereitstellung durch den Betreiber des das Benutzerendgerät versorgenden
Kommunikationsnetzes und/oder durch den Betreiber des Dienstservers
ist es von Vorteil, wenn der Dienstrechner eine Managementsperre für den Dienstcontainer
bereitstellt. Der Dienstcontainer sendet Alarme über die Managementsperre zu
einem Bedienplatz oder zu einem Netzmanagement-System, die zum Beispiel
eine Störung
des Dienstrechners anzeigen.
-
Die
nachfolgende Beschreibung dient zur Erläuterung der Vorteile der Erfindung
auf der Grundlage von praktischen Beispielen, wie sie in den beigefügten Zeichnungen
dargestellt sind.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt
eine Anordnung für
die Durchführung
des erfindungsgemäßen Verfahrens
mit Endgeräten
TERA und TERB, einem erfindungsgemäßen Dienstserver SSV und einem
erfindungsgemäßen Dienstrechner
SSC.
-
2 ist
ein Ablaufdiagramm, das ein beispielhaftes Verfahren zum Bereitstellen
von Diensten gemäß der Erfindung
veranschaulicht.
-
Ausführliche Beschreibung der Erfindung
-
Im
Folgenden wird ausführlich
auf die derzeit bevorzugten, in den beigefügten Zeichnungen dargestellten
Ausführungsbeispiele
der Erfindung eingegangen. Bei der Beschreibung der bevorzugten
Ausführungsbeispiele
und Anwendungen der vorliegenden Erfindung wird um der Klarheit
willen eine spezifische Terminologie benutzt. Die Erfindung ist
jedoch nicht auf die gewählte
spezifische Terminologie beschränkt,
und es versteht sich, dass jedes spezifische Element alle technischen
Equivalente einschließt,
die in ähnlicher
Weise wirken, um einen ähnlichen
Zweck zu erreichen.
-
1 zeigt
als Beispiel eine sehr schematisch dargestellte Anordnung, mit der
die Erfindung realisiert werden kann. Es sind Endgeräte TERA
und TERB dargestellt, die als Kommunikationsmittel von Benutzern
A und B (nicht dargestellt) dienen. Das Endgerät TERA ist zum Beispiel ein
analoger oder ein ISDN-Fernsprechapparat (ISDN = Integrated Services
Digital Network), ein Personalcomputer oder ein Bildtelefon. Das
Endgerät
TERB ist zum Beispiel ein Mobilfunkendgerät, welches das so genannte Wireless
Application Protocol (WAP) interpretieren kann, oder ein so genannter
Network Computer (NC) gemäß der Java-Architektur (wie
von Sun Microsystems, Inc., Mountain View, California, definiert).
Die Endgeräte
TERA und TERB können
an lokale Computernetze oder private Fernsprechnetze (beide nicht dargestellt)
am Ort des Benutzers A bzw. B angeschlossen sein.
-
Der
Einfachheit halber sind die Endgeräte TERA und TERB gleich aufgebaut
und nur schematisch als Funktionsblockdiagramme dargestellt. Die Endgeräte TERA
und TERB weisen Verbindungsmittel TRA und TRB zum Senden und Empfangen
von Daten über
ein Kommunikationsnetz NET auf, das zum Beispiel ein Mobilfunknetz,
ein leitungsvermitteltes Kommunikationsnetz, das Internet oder jede
gewünschte
Kombination solcher Netze ist. Das Netz NET kann ein reales oder
virtuelles privates Netz/Firmenetz oder ein öffentliches Netz sein. Die
Verbindungsmittel TRA und TRB umfassen zum Beispiel DSL-Modems (DSL = Digital
Subscriber Line), ISDN-Adapter oder Funkschnittstellen-Module. Weiterhin
weisen die Endgeräte
TERA und TERB Steuermittel CPUTA bzw. CPUTB sowie Speichermittel MEMTA
bzw. MEMTB auf, die jeweils untereinander und mit den Verbindungsmitteln
TRA bzw. TRB über nicht
gezeigte Verbindungen verbunden sind. Die Steuermittel CPUTA und
CPUTB sind zum Beispiel Prozessoren, mit denen ein Programmcode
ausgeführt
werden kann, der in den Speichermitteln MEMTA bzw. MEMTB gespeichert
ist. Die Speichermittel MEMTA und MEMTB sind zum Beispiel als Festplatten
oder RAM-Module realisiert. Außerdem
weisen die Endgeräte
TERA und TERB Anzeigemittel, wie zum Beispiel LCDs (Liquid Crystal
Displays), und Eingabemittel, zum Beispiel Tastaturen, auf; die
Anzeigemittel und die Eingabemittel sind nicht dargestellt. Weitere
nicht dargestellte Komponenten sind Mikrofone und Lautsprecher für Spracheingabe
und Sprachausgabe. Die Endgeräte
TERA und TERB werden mittels eines Betriebssystems betrieben.
-
Dem
Kommunikationsnetz NET ist ein Dienstrechner SSC zugeordnet. Der
Dienstrechner kann vom Betreiber des Netzes NET betrieben werden,
das, wie bereits erwähnt,
ein Firmennetz sein kann. Einige wichtige Komponenten des Dienstrechners
sind als Beispiele dargestellt, nämlich ein Steuermittel CPUSC,
ein Speichermittel MEMSC und ein Verbindungsmittel TRSC. Unter Verwendung
des Verbindungsmittels TRSC, das z.B. Schnittstellenkarten umfasst,
kann der Dienstrechner SSC Verbindungen CA, CB, CCONL, CCDRL und
CCN und weitere, nicht dargestellte Verbindungen aufbauen. Bei dem
Steuermittel CPUSC handelt es sich um einen Prozessor oder eine
Gruppe von Prozessoren, die in der Lage sind, den Programmcode von
im Speichermittel MEMSC gespeicherten Programmmodulen auszuführen. Das
Steuermittel CPUSC steuert die Funktion des Servers SSC und beeinflusst
dabei zum Beispiel die weitere Funktion des Verbindungsmittels TRSC.
Das Verbindungsmittel TRSC, das Steuermittel CPUSC und das Speichermittel
MEMSC sind untereinander durch Verbindungen verbunden, die in 1 nicht
dargestellt sind. Der Dienstrechner SSC wird mittels eines Betriebssystems
betrieben. Im vorliegenden Ausführungsbeispiel
ist der Dienstrechner SSC ein so genannter dünner Client (thin client),
also ein System, das mit einem sehr einfachen Betriebssystem ohne
lokale Systemverwaltung arbeitet und über ein Netzwerk übermittelte
Anwendungen ausführt.
Der Dienstrechner SSC kann jedoch auch aus einem komplexeren System
bestehen, das eine lokale Systemverwaltung enthält und einige Basisdienste bereitstellt.
-
Im
vorliegenden Fall sind die vom Dienstrechner SSC ausgeführten Anwendungen
Dienstcontainer CONT1 und CONT2, die von einem Dienstserver SSV über die
Verbindung CCONL übermittelt wurden.
Außerdem
enthält
der Dienstrechner SSC ein Dienstrechnermodul SCM, das im vorliegenden Ausführungsbeispiel
eine so genannte virtuelle Maschine enthält. Dies ist eine Software-"Ausführungsmaschine", die nach strengen
Sicherheitsprüfungen die
Bytecodes des Dienstcontainers auf dem Steuermittel CPUSC sicher
und kompatibel ausführt.
Das Dienstrechnermodul SCM kann einen Interpretierer umfassen, welcher
Anweisungen des Programmcodes des Dienstcontainers CONT1 dekodiert
und ausführt.
Darüber
hinaus kann das Dienstrechnermodul SCM maschinenabhängige Verfahren
dynamisch verknüpfen,
eine Speicherverwaltung durchführen oder
Ausnahmen im Auftrag des Dienstcontainers CONT1 behandeln.
-
Der
Einfachheit halber sind auch vom Dienstserver SSV nur einige wichtige
Komponenten dargestellt, nämlich
ein Steuermittel CPUSV, ein Speichermittel MEMSV und ein Verbindungsmittel
TRSV. Unter Verwendung des Verbindungsmittels TRSV kann der Server
SSV Verbindungen CCONL und CCDRL zum Dienstrechner SSC und Verbindungen
CSCE und CDB zu einer Dienstentwicklungsumgebung SCE bzw. einer
Datenbank DB aufbauen. Gemäß einer
weiteren Ausführungsform
der Erfindung sind die Dienstentwicklungsumgebung SCE und die Datenbank
DB im Dienstserver SSV integriert. Das Verbindungsmittel TRSV kann
zum Aufbau weiterer Verbindungen dienen, die nicht dargestellt sind.
Bei dem Steuermittel CPUSV handelt es sich um einen Prozessor oder
eine Gruppe von Prozessoren, die fähig sind, den Programmcode
von in dem Speichermittel MEMSV gespeicherten Programmmodulen auszuführen. Von
diesen Programmmodulen ist ein Dienstservermodul SSM dargestellt,
der wesentliche erfindungsgemäße Funktionen
ausführt.
Das Steuermittel CPUSV steuert die Funktion des Servers SSV und beeinflusst
dabei zum Beispiel die weitere Funktion der Verbindungsmittel TRSV.
Die Verbindungsmittel TRSV, das Steuermittel CPUSV und die Speichermittel
MEMSV sind untereinander durch Verbindungen verbunden, die in
-
1 nicht
dargestellt sind. Der Server SSV wird mittels eines Betriebssystems,
z.B. Unix, betrieben.
-
Der
Dienstserver SSV wird von einem Heimnetz-Betreiber von Benutzern
A und B betrieben, denen der Heimnetz-Betreiber jeweils individuelle
persönliche
Dienste anbietet, wie zum Beispiel Bildfernsprechen, Meldungsfelder
(personal message boxes), Rundsenden (broadcasting), Gruppenaufruf (multicasting),
Abrechnungseinsicht, "Information Pushing" aufgrund eines Benutzerprofils
oder einer Verzeichniseinsicht. In einem speziellen Szenario werden
sowohl der Dienstrechner SSC als auch der Dienstserver SSV vom selben
Betreiber betrieben.
-
Ein
beispielhaftes Verfahren zum Bereitstellen eines persönlichen
Dienstes für
das Endgerät TERA
ist in 2 dargestellt und umfasst Schritte S21 bis S27.
Im Schritt S21 meldet sich der Benutzer A beim Endgerät TERA an
und benutzt typischerweise eine Windows-Anwendung oder dergleichen,
oder er hebt einfach einen Handapparat des Endgeräts TERA
ab. Eine Maus und/oder eine Tastatur und/oder eine Sprachschnittstelle
des Endgeräts TERA
initiieren ein Programmmodul PMPA zum Abruf und zur Nutzung von
persönlichen
Diensten, wobei das Programmmodul PMPA durch das Steuermittel CPUTA
ausgeführt
wird.
-
Das
Programmmodul PMPA arbeitet zum Beispiel wie folgt:
Auf dem
Anzeigemittel des Endgeräts
TERA kann zum Beispiel ein Symbol für Dienststart erscheinen. Durch
Anklicken oder anderweitige Auswahl des Symbols, durch Drücken einer
Taste der Tastatur oder durch Eingabe eines Sprachbefehls initiiert
der Benutzer A im Schritt S22 die Übertragung einer Anforderungsnachricht
durch das Übertragungsmittel TRA
zum Netz NET über
die Verbindung CA. Die Anforderungsnachricht umfasst die Identität und Adresse
des Benutzers A, sodass Nachrichten und Dienstdaten, wie z.B. eine
Eins, die Befehle zum Steuern persönlicher Dienste anzeigt, zum
Benutzer A zurückübertragen
werden können.
Die Anforderungsnachricht kann auch einen persönlichen Berechtigungs- oder
Zugangscode des Benutzers A umfassen, wobei der Berechtigungscode
den Benutzer A berechtigt, auf den angeforderten Dienst zuzugreifen.
Im vorliegenden Ausführungsbeispiel
leitet das Netz NET die Anforderungsnachricht zum Dienstrechner
SSC weiter. Im Schritt S23 leitet der Dienstrechner SSC die Anforderung über die
Verbindung CCONL zum Dienstserver SSV weiter. Mit Hilfe eines vom
Steuermittel CPUSV ausgeführten
Programmmoduls SSM prüft
der Dienstrechner SSV im Schritt S24 den Umfang, in welchem vom
Benutzer A angeforderte Dienste vom Dienstrechner SSC erhältlich sind.
Die Dienste können
vom Benutzer A abonnierte, gebührenpflichtige
Dienste sein oder zum Beispiel Dienste, die gebührenfrei sind und mittels des
Dienstrechners SSC über
das Netz NET bereitgestellt werden. Im vorliegenden Fall ist der
vom Benutzer A angeforderte Dienst ein Meldungsfeld-Dienst, der
durch am Endgerät
TERA eingegebene Sprachbefehle gesteuert wird.
-
Es
ist jedoch auch möglich,
dass der Dienstrechner SSC umgangen wird und das Netz die Anforderungsnachricht über eine
in 1 nicht dargestellte Verbindung direkt zum Dienstserver
SSV weiterleitet, oder dass, in einem anderen Szenario, ein vom Dienstrechner
SSC ausgeführter
dedizierter Dienstcontainer den Schritt S24 – Prüfung der tatsächlichen Fähigkeit
des Dienstrechners SSC, die vom Benutzer A angeforderten persönlichen
Dienste bereitzustellen, also der Dienstbereitstellung, z.B. durchgeführt durch
im Dienstrechner SSC bereits abgespeicherte Dienstcontainer – durchführt.
-
Der
Dienstserver SSV stellt fest, dass der Dienstrechner SSC nicht fähig ist,
Funktionen wie die vom Benutzer A angeforderten auszuführen. Folglich lädt der Server
SSV im Schritt S25 den Dienstcontainer CONT1 zum Dienstrechner SSC über die
Verbindung CCONL herunter, die z.B. im Internet oder in einem Transportnetz,
wie z.B. einem Synchronous Optical Network (SONST) oder einem SDH-Netz
(SDH = Synchronous Digital Hierarchy), aufgebaut werden kann.
-
Der
Dienstrechner SSC empfängt
den Dienstcontainer CONT1 über
Empfangsmittel CONL und installiert den Dienstcontainer CONT1 in
seinem Speichermittel MEMSC. Anschließend ruft das Dienstrechnermodul
SCM im Schritt S26 eine im Dienstcontainer CONT1 enthaltene Dienstmaschine SM1
auf.
-
Das
Empfangsmittel CONL ist ein Programmmodul, welches die Verbindung
mit dem Dienstserver SSV abwickelt, also das auf der Verbindung
CCONL verwendete Protokoll verwaltet und Dienstcontainer umfassende
Daten empfängt.
In jedem Fall wird die für
die Verbindung CCONL benötigte
physikalische Schnittstellenfunktion vom Verbindungsmittel TRSC
abgewickelt. Das Empfangsmittel kann vorteilhafterweise auch eine
spezialisierte Object-Request-Broker(ORB)-bindende
Software sein, um auf dem Dienstrechner SSC ablaufende Softwaremodule
in die Lage zu versetzen, Anrufe und Anforderungen an den als so
genannter Object Request Broker dienenden Dienstserver SSV abzusetzen.
Die jeweilige Architektur kann gemäß der Common-Object-Request-Broker(CORBA)-Spezifikation der
Object Management Group (OMG) realisiert werden. Die logische Funktion
des Empfangsmittels CONL, z.B. Protokollabwicklung und ORB-Binding, kann
vom Verbindungsmittel TRSC ausgeführt werden oder im Dienstrechnermodul
SCM integriert sein. Zu diesem Zweck ist das Verbindungsmittel TRSC, zum
Beispiel eine Schnittstellenkarte, mit einem Prozessor CTC versehen,
der den Programmcode des Empfangsmittels CONL ausführt.
-
Das
Dienstrechnermodul SCM bietet der Dienstmaschine SM1 einen kontrollierten
und sicheren Zugriff zu vorgegebenen Ressourcen des Dienstrechners
SSC, wie zum Beispiel Zugriff zum Speichermittel MEMSC und Prozessorzeit
des Steuermittels CPUSC. Unter Verwendung der vom Dienstrechnermodul
SCM angebotenen Ressourcen regelt die Dienstmaschine SM1 die Ausführung der
persönlichen
Dienste für
das Endgerät
TERA. So aktiviert die Dienstmaschine SM1 Dienstkomponenten CP1
und CP2, die ebenfalls im Dienstcontainer CONT1 enthalten sind.
Die Dienstkomponenten CP1 und CP2 sind Programmmodule oder Programmfunktionen, die
den Meldungsfeld-Dienst ausführen.
Die Dienstmaschine SM1 ist beispielsweise eine Java-Anwendung, die im
Dienstrechnermodul SCM einen Anwendungskontext für die Dienstkomponenten CP1
und CP2 ausführt
und bereitstellt. Die Dienstkomponenten CP1 und CP2 sind oder umfassen
z.B. Java-Applets oder JavaBeans. Die Dienstkomponente CP1 kann
jedoch auch eine von der Dienstmaschine SM1 aufgerufene Funktion
sein. In jedem Fall bilden die Dienstmaschine SM1 und die Dienstkomponenten CP1
und CP2 eine Dienstinstanz.
-
Im
Schritt S26 baut der Dienstcontainer CONT1 eine Verbindung CA zum
Endgerät
TERA über
eine vom Dienstrechner SSC für
den Dienstcontainer CONT1 bereitgestellte Netzsperre NWL auf. Die
Netzsperre NWL bildet für
den Dienstcontainer CONT1 eine vordefinierte Schnittstelle zum Netz NET.
Diese Schnittstelle kann zum Beispiel eine einfache Call-Schnittstelle
sein. In diesem Fall baut die Netzsperre NWL unter Verwendung einer
der Verbindung CA zugeordneten Teilnehmerrufnummer eine Anrufverbindung
auf, wobei die Teilnehmerrufnummer vom Dienstcontainer CONT1 bereitgestellt
wird. Je nach den Fähigkeiten
des Netzes NET und der jeweiligen Endgeräte können die Netzsperre NWL und das
Verbindungsmittel TRSC auf verschiedene Weise so konfiguriert sein,
dass sie z.B. eine ISDN-Schnittstelle, eine Eithernet-Schnittstelle,
ein DSL-Modem oder/und eine Schnurlostelefon-Schnittstelle (z.B.
einen 900-MHz-Sender/Empfänger)
enthalten. Der Dienstrechner SSC kann mehrere Netzsperren parallel
bereitstellen, die im Aufbau gleich und auf verschiedene Weise konfiguriert
sind. Im Schritt S27 fordert der Dienstcontainer CONT1 den Benutzer
A auf, eine Sprachansage als "Willkommensnachricht" für den auszuführenden
Meldungfeld-Dienst aufzunehmen, wobei die Dienstkomponente CP1 die
Dialogfunktion oder Eingabe-Ausgabe-Funktion
mit dem Endgerät
TERA und die Dienstkomponente CP2 die Aufnahmefunktion ausführt.
-
Beim
Endgerät
TERA können
die Funktionen in Bezug auf die Bereitstellung des persönlichen Dienstes,
also in Bezug auf den Meldungsfeld-Dienst, durch übliche Mittel
ausgeführt
werden, wie zum Beispiel durch Mikrofone und Lautsprecher für Spracheingabe
und -ausgabe. Es ist jedoch möglich,
dass das Programmmodul PMPA und der Dienstcontainer CONT1 für die Dienstbereitstellung interagieren.
Zum Beispiel kann der Dienstcontainer CONT1 einen Programmcode,
z.B. Objekte, über
die Verbindung CA zum Programmmodul PMPA senden. Indem das Programmmodul
PMPA dieses Objekt ausführt
oder anwendet, sendet es über
eine Pull-Aktion weitere Datenanforderungen zum Dienstcontainer
CONT1 oder "pusht" Daten zum Dienstcontainer CONT1,
die von diesem auszuwerten sind. Die Push-und-Pull-Aktionen können gemäß den Java-Definitionen durchgeführt werden.
-
Die
Netzsperre NWL kann auch eine Steuer- oder Signalschnittstelle bieten,
zum Beispiel eine Schnittstelle zu einem Zeichengabenetz wie das
zentrale Zeichengabesystem Nr. 7. Auf diese Weise kann ein vom Dienstrechner
SSC ausgeführter Dienstcontainer
Dienste eines intelligenten Netzes bereitstellen, z.B. den so genannten
automatischen Rückruf
der Person, die zuletzt angerufen hat (Automatic Callback – ACB).
Zu diesem Zweck kann der Dienstcontainer über die Netzsperre NWL mit
nicht dargestellten, irgendwo im Netz NET angeordneten Einrichtungen
des intelligenten Netzes kommunizieren, z.B. mit intelligenten Peripheriegeräten (Intelligent
Peripherals – IPs),
Dienstevermittlungsknoten (Service Switching Points – SSPs)
oder einem Dienstesteuerungsknoten (Service Control Point – SCP) und
dergleichen. Weiterhin kann die Netzsperre NWL auf den jeweiligen
IN-Verbindungen verwendete Protokolle abwickeln, zum Beispiel das
Intelligent Network Applications Protocol (INAP), den Transport
Capabilities Application Part (TCAP) oder den Signalling Connection
Control Part (SCCP).
-
Die
Netzsperre NWL kann auch eine Schnittstelle zu Verbindungen bilden,
auf denen das Transmission Control Protocol/Internet Protocol (TCP/IP) verwendet
wird, zum Beispiel Verbindungen über
das Internet. Die Netzsperre NWL ist in 1 als Modul dargestellt,
das im Verbindungsmittel TRSC enthalten ist und sowohl die physikalische
als auch die logische Schnittstellenfunktion steuert. In diesem
Fall führt
der Prozessor CTC einen Programmcode der Netzsperre NWL aus, wodurch
er die logische Funktion der Netzsperre NWL steuert, zum Beispiel
Protokollschichten abarbeitet. Die logische Funktion kann jedoch
auch ganz oder teilweise vom Dienstrechnermodul SCM übernommen
werden, oder sie kann von einem separaten Programmmodul übernommen
werden, das vom Steuermittel CPUSC ausgeführt wird und mit dem Dienstrechnermodul
SCM interagiert.
-
Im
vorliegenden Fall möchte
der Benutzer den Meldungsfeld-Dienst
mittels Sprachbefehlen steuern. Deshalb wird eine jeweilige Anforderung vom
Endgerät
TERA über
die Verbindung CA zum Dienstcontainer CONT1 übermittelt. Da weder die Dienstmaschine
SM1 noch die Dienstkomponenten CP1, CP2 aktuell fähig sind,
eine automatische Spracherkennung durchzuführen, überträgt die Dienstmaschine SM1 eine
jeweilige Anforderung zum Dienstserver SSV, z.B. mittels eines Containers.
Daraufhin übermittelt
der Dienstserver SSV dem Dienstrechner SSC den Dienstcontainer CONT2,
der eine Dienstkomponente CP3 enthält, welche ein Programmmodul
oder eine Funktion ist, die eine automatische Spracherkennung durchführen kann.
Die Dienstmaschine SM1 und/oder das Dienstrechnermodul SCM verknüpfen den
Dienstcontainer CONT2 mit dem Dienstcontainer CONT1. Schließlich führt die
Dienstmaschine SM1 die Dienstkomponente CP3 aus, welche die Sprachbefehle
des Benutzers A aufzeichnet und in Befehle umsetzt, die von der
Dienstmaschine SM1 und/oder der Dienstkomponente CP1 verstanden
werden können.
-
In
einem weiteren Szenario werden einige Basisdienstfunktionen vom
Dienstrechner SSC ausgeführt,
zum Beispiel die erwähnte
automatische Spracherkennung. Im vorliegenden Fall wird die automatische
Spracherkennung durch das Dienstrechnermodul SCM oder durch ein
mit dem Dienstrechnermodul SCM verknüpfbares Programmmodul durchgeführt. Das
Dienstrechnermodul SCM stellt für den
Dienstcontainer CONT1 eine Ressourcensperre API bereit, die dem
Dienstcontainer CONT1 einen Zugriff auf eine automatische Spracherkennungsfunktion
ermöglicht.
In diesem Fall kann die Ressourcensperre API als eine Anwenderprogramm-Schnittstelle
angesehen werden. Gemäß einem
anderen Ausführungsbeispiel
kann die Ressourcensperre API eine Schnittstelle zu einem externen
intelligenten Peripheriegerät
(IP) sein, das ein so genannter spezieller Ressourcenpunkt ist,
der z.B. Spracherkennung durchführt.
-
Der
Einfachheit halber sind in 1 nur Dienstcontainer
CONT1 und CONT2 dargestellt, die vom Dienstrechner SSC ausgeführt werden.
Der Dienstrechner SSC führt
jedoch weitere, in 1 nicht dargestellte Dienstcontainer
aus, zum Beispiel einen Dienstcontainer, der über die Verbindung CB persönliche Dienste
für das
Endgerät
TERB bereitstellt. Zu diesem Zweck ist der Dienstrechner SSC so ausgelegt,
dass er eine signifikante Anzahl von Transaktionen pro Sekunde ausführen kann.
Zusätzlich
lagert der Dienstrechner SSC zwischen auszuführenden Dienstcontainern um
(swapping). Es kann jedoch vorkommen, dass der Dienstrechner SSC nahe
an seiner Überlastungsgrenze
ist. Um eine Überlastungs-
oder Blockierungssituation zu vermeiden, teilt der Dienstcontainer
CONT1 dem Dienstserver SSV den Zustand des Dienstrechners SSC über eine
Monitorsperre CDRL mit. Die über
die Monitorsperre CDRL und die Verbindung CCSL gesendeten Daten
enthalten zum Beispiel Informationen über die Auslastung des Dienstrechners
SSC für
die aktuelle Dienstsitzung und/oder über die Auslastung der Netzsperre
NWL. Abhängig
von diesen "Call
and Session Detailed Record"-Daten
(CDR-Daten) kann der Dienstserver SSV weitere Dienstcontainer für die Endgeräte TERA
und TERB statt auf den Dienstrechner SSC auf andere, in 1 nicht
dargestellte Dienstrechner herunterladen. Der Dienstrechner SSV
steuert also die Belastung des Dienstrechners SSC. CDR-Daten können auch
dazu dienen, z.B. dem Benutzer A eine Gebühr für die Benutzung des Dienstrechners
SSC und/oder für
die Benutzung der Verbindung CA in Rechnung zu stellen. Weiterhin können die
CDR-Daten für
statistische Zwecke oder dergleichen verwendet werden. CDR-Daten
können z.B.
nach und/oder ein- oder
mehrmals während
der Ausführung
des Dienstcontainers CONT1 übertragen werden.
Wie bereits in Verbindung mit der Netzsperre NWL beschrieben, kann
die Monitorsperre CDRL ebenfalls ein separates Programmmodul sein,
das vom Prozessor CTC des Verbindungsmittels TRSC ausgeführt wird.
Die Monitorsperre CDRL, d.h. ihre logischen Algorithmen, kann bzw.
können
jedoch im Dienstrechnermodul SCM integriert sein. Die Funktion der
Monitorsperre CDRL kann jedoch auch vom Empfangsmittel CONL übernommen
werden. In diesem Fall werden CDR-Daten in dedizierten Dienstcontainern
vom Dienstcontainer CONT1 über
die Verbindung CCONL zum Dienstserver SSV übertragen.
-
Eine
Managementsperre NML bildet eine weitere Schnittstelle zur Überwachung
und Steuerung des Dienstcontainers CONT1 und/oder des Dienstrechners
SSC. Der Dienstcontainer CONT1 sendet Alarme über die Managementsperre NML
und eine Verbindung CCN zu einem Managementsystem NMS, das z.B.
ein Bediengerät
oder ein Netzmanagementsystem ist. Die Alarme zeigen dem Managementsystem
NMS zum Beispiel eine Störung oder Überlastung
des Dienstrechners SSC an oder informieren über einen Kommunikationsfehler
des Dienstcontainers CONT1 während
der Kommunikation mit dem Endgerät
TERA. In der entgegengesetzten Richtung kann das Managementsystem
NMS einen Befehl senden, der den Dienstcontainer CONT1 zum Beispiel
anweist, in einer Überlastsituation
des Dienstrechners SSC seinen Betrieb zeitweilig einzustellen. Das
Managementsystem NMS kann durch den Betreiber des Netzes NET, des
Dienstrechners SSC oder des Dienstservers SSV betrieben werden. Der
Umfang, in dem Alarme oder Befehle über die Managementsperre NML übertragen
werden können,
hängt von
dem Umfang ab, in dem der Dienstcontainer CONT1 vom Managementsystem
NMS gesteuert, werden soll. Es ist möglich, dass die Managementsperre
NML eine transparente Verbindung für die gesamten Überwachungs-
und Steuerressourcen des Dienstcontainers CONT1 anbietet. Weiterhin kann
das Managementsystem NMS ein so genannter dünner Client sein oder einen
solchen umfassen, der vom Dienstcontainer CONT1 gesteuert oder fernbetrieben
wird. Wie von der Netzsperre NWL und der Monitorsperre CDRL bekannt,
können
die logischen Funktionen der Managementsperre NML zum Beispiel vom
Dienstrechnermodul SCM oder von einem durch das Verbindungsmittel
TRSC lokal ausgeführten
Programmmodul übernommen
werden.
-
Die
vom Dienstserver SSV übermittelten Dienstcontainer
können
vorkonfiguriert und im Speichermittel MEMSV gespeichert sein. Das
Dienstservermodul SSM ermittelt den oder die relevanten Dienstcontainer
gemäß einer
vom jeweiligen Benutzer gesendeten Anforderung und stellt den Dienstcontainer
für den
Dienstrechner SSC bereit. Das Speichermittel MEMS kann auch Benutzerprofile
enthalten, aus denen von Benutzern abonnierte Dienste, Interessen
von Benutzern und solche Interessen betreffende Informationen ersichtlich
sind.
-
Die
Benutzerprofile und/oder zumindest irgendeine Art von Dienstcontainern
können
in einer globalen Datenbank DB abgespeichert sein, die vom Heimnetz-Betreiber
des jeweiligen Benutzers betrieben und gewartet wird, im vorliegenden
Fall vom Heimnetz-Betreiber der Benutzer A und B. Der Dienstserver
SSV fordert über
eine Verbindung CDB Benutzerdaten oder Dienstcontainer von der Datenbank
DB an, die ein einzelner Server oder ein Datenbank-Cluster sein
kann, der den Dienstserver SSV sowie weitere, nicht dargestellte
Server versorgt.
-
Das
Dienstservermodul SSM kann jedoch auch eine nicht dargestellte Packungsplattform
enthalten, die geeignet ist, Dienstcontainer bereitzustellen. Die
Packungsplattform verpackt Dienstkomponenten, die für die Bereitstellung
eines gewünschten Dienstes
relevant sind, in Dienstcontainer. Solche Dienstkomponenten können zum
Beispiel Dienstlogiken sein, die von einer Dienstentwicklungsumgebung SCE über die
Verbindung CSCE geliefert werden. Die Dienstlogiken sind Anwendungsprogramme
oder Anwendungsfunktionen, die von einer Dienstmaschine eines Dienstcontainers
ausgeführt
oder interpretiert werden. Die Dienstlogiken können gemäß den Definitionen eines intelligenten
Netzes ausgelegt sein und aus einem proprietären Programmcode bestehen.
Weiterhin passt die Packungsplattform den Dienstcontainer an die
vom jeweiligen Dienstrechner angebotenen Sperren an, zum Beispiel
an die Netzsperre NWL des Dienstrechners SSC.
-
Aufgrund
der Verkapselung in Dienstcontainern sind verschiedene weitere Arten
von zur Ausführung
oder Anwendung durch eine Dienstmaschine vorgesehenen Dienstkomponenten
möglich,
wie zum Beispiel:
- – Benutzerinformationen, die
durch die jeweilige Dienstmaschine z.B. zu einem Endgerät zu übertragen
sind, wobei das Endgerät
die Benutzerinformationen anzeigt;
- – Anwendungsprogramme,
z.B. Java-Applets, die von einem Endgerät oder einem Dienstrechner auszuführen sind,
und
- – Klang-
oder Video-Dateien, die von einem Endgerät oder einem Dienstrechner
zu reproduzieren sind.
-
Weiterhin
kann der Dienstserver SSV zum Dienstrechner SSC einen "Transport"-Dienstcontainer übertragen,
der einen Dienstcontainer enthält und
einhüllt,
welcher zur Ausführung
in einem nicht dargestellten Second-Level-Dienstrechner oder in den Endgeräten A oder
B vorgesehen ist. Beispielsweise kann der Dienstcontainer CONT2
ein solcher "Transport"-Dienstcontainer
und die Dienstkomponente CP3 ein darin eingepackter Dienstcontainer sein.
Die Dienstmaschine SM1 leitet die Dienstkomponente/den Dienstcontainer
CP3 über
die Netzsperre NWL zum Endgerät
TERB oder zu einem anderen, nicht dargestellten Dienstrechner weiter.
Das Endgerät
TERB bzw. der nicht dargestellte Dienstrechner führt die Dienstkomponente CP3,
die selbst ein Dienstcontainer ist, aus. Zu diesem Zweck ist im
Endgerät
TERB ein Programmmodul PMPB installiert, das in Aufbau und Leistung
dem Dienstrechnermodul SCM entspricht.
-
Gemäß einem
weiteren Ausführungsbeispiel führt der
Dienstcontainer CONT1 die Funktion eines CTI-Servers (CTI = Computer
Telephony Integration) aus, während
das Endgerät
TERA ein Fernsprechapparat und das Endgerät TERB ein Personalcomputer ist,
der sich gerade in der Domäne
des Benutzers A befindet und mit dem Endgerät TERA kooperiert. Zu diesem
Zweck übermittelt
der Dienstcontainer CONT1 Signalisierungsdaten, z.B. ISDN-D-Kanal-Daten, über die
Verbindung CA zum Endgerät
A. Über
die Verbindung CB kommuniziert der Dienstcontainer CONT1 unter Verwendung
eines CTI-Protokolls, das z.B. auf dem von der European Computer Manufacturers
Association (ECMA) definierten CSTA-Protokoll 179/180 (CSTA = Computer
Supported Telephony Applications) basiert, mit dem Endgerät TERB.
-
Gemäß einem
weiteren Ausführungsbeispiel führt der
Dienstcontainer CONT1 die Funktion einer so genannten Softswitch
aus. Zum Beispiel kann der Dienstcontainer CONT1 die Endgeräte TERA
und TERB nach Art einer im Netz NET angeordneten Wählnebenstellenanlage
(Private Automatic Branch Exchange – PABX) miteinander verbinden.
In diesem Fall übermittelt
der Container CONT1 Signalisierungsdaten für die Bereitstellung von Teilnehmerdiensten,
wie z.B. Anzeige des Namens eines Anrufers oder Besetztanzeige,
auf den Verbindungen CA und CB, während die Endgeräte TERA
und TERB über
eine im Netz NET aufgebaute und z.B. vom Dienstcontainer CONT1 unterstützte Anrufverbindung
COM kommunizieren.
-
In
einem anderen Szenario übernimmt
der Dienstcontainer eine so genannte Soft-Terminal-Funktion. Ist
z.B. das Endgerät
TERB ein Sprachterminal, das keinen Bildfernsprechanruf empfangen kann,
dann können
der Dienstcontainer CONT1 den Videokanal der Bildfernsprechverbindung
und das Endgerät
TERB den Sprechkanal der Bildfernsprechverbindung abschließen.
-
Weiterhin
kann der Dienstcontainer CONT1 als ein so genannter Soft Special
Resource Point (Soft SRP) dienen, der z.B. Spracherkennung durchführt. Dieser
SRP kann von lediglich einem, ihm speziell zugeordneten Dienstcontainer
benutzt oder, gemäß einem
anderen Ausführungsbeispiel,
als globaler SRP verwendet werden, der von verschiedenen, auf dem
Dienstrechner SSC oder nicht dargestellten externen Dienstrechnern
ablaufenden Dienstcontainern zu adressieren ist.
-
Es
kann vorkommen, dass ein Dienstcontainer nur einmal abläuft und
neu in den Dienstrechner SSC geladen wird, wenn der Dienst des jeweiligen Dienstcontainers
erneut benötigt
wird. Der Dienstrechner SSC kann jedoch einen Dienstcontainer für einen
längeren
Zeitraum speichern, wenn der jeweilige Dienstcontainer häufig genutzt
wird. Zu diesem Zweck können
der Dienstrechner SSC und/oder der Dienstserver SSV die Nutzung
des Dienstcontainers überprüfen. Ein
Dienstcontainer, der über
einen vorgegebenen Zeitraum nicht genutzt wurde, kann aus dem Speichermittel
MEMSC entfernt werden. Die beiden Dienstcontainermanagement-Verfahren, "einmal laden und
vielmals ausführen" (load once and run
many times) oder "einmal
laden und einmal ausführen" (load once and run
once) können
parallel durchgeführt
werden und können
vom Inhalt des jeweiligen Dienstcontainers abhängig sein.
-
In
einem weiteren Szenario werden die Schritte S21 bis S25 wie folgt
durchgeführt:
Das Netz NET arbeitet wie ein intelligentes Netz (IN), und das Endgerät TERA ist
ein Fernsprechapparat. Das Netz NET enthält mehrere Dienstevermittlungsknoten (SSPs,
nicht dargestellt) und mindestens einen Dienstesteuerungsknoten
(SCP, nicht dargestellt), wobei die SSPs und der SCP zumindest teilweise
gemäß den in
der Einleitung der vorliegenden Beschreibung erwähnten Spezifikationen der ITU
aufgebaut sind und arbeiten. Ein Benutzer A wählt mittels einer Tastatur
des Endgeräts
A eine vorgegebene Fernsprechnummer. Das Endgerät A sendet eine die vorgegebene
Fernsprechnummer enthaltende Verbindungsanforderung zum Netz NET.
Ein Dienstevermittlungsknoten (SSP, nicht dargestellt) stellt durch Überprüfung der
vorgegebenen Fernsprechnummer fest, dass die Verbindungsanforderung
keine Anrufverbindung, sondern einen Dienst betrifft. Deshalb leitet
der Dienstevermittlungsknoten die Verbindungsanforderung zu einem
Dienstesteuerungsknoten (SCP, nicht dargestellt) weiter. Der SCP
prüft,
ob der Dienstrechner SSC fähig
ist, den angeforderten Dienst auszuführen, und, wenn dies nicht
der Fall ist, bittet den Dienstserver SSV, den Dienstcontainer CONT1
zum Dienstrechner SSC herunterzuladen. Hierbei ist klar, dass die
Funktionen des Dienstrechners SSC in den erwähnten SSP oder SCP oder in eine
Kombination von beiden, einen so genannten Dienstevermittlungs-
und Dienstesteuerknoten (Service Switching and Control Point – SSCP),
integriert werden können.
Mit anderen Worten: Der Dienstrechner SSC ist mit Mitteln zur Ausführung von Dienstvermittlungs-
und/oder Dienststeuerungsfunktionen versehen, wie sie in der Einleitung
der vorliegenden Beschreibung beschrieben sind.
-
Die
vorstehende Erfindung wurde zwar für ein besseres Verständnis in
einiger Ausführlichkeit beschrieben,
doch es ist offensichtlich, dass im Rahmen der Erfindung bestimmte Änderungen
und Modifizierungen möglich
sind. Zum Beispiel kann der zwischen dem Dienstrechner SSC und dem
Dienstserver SSV verwendete Kommunikationsmechanismus jeder geeignete
Object Request Broker sein, und er kann auch proprietär sein.
Weiterhin ist die Implementierung weder auf Java noch auf objektorientierte Programmiersprachen
im Allgemeinen, wie z.B. C++ oder dergleichen, beschränkt. Anstelle
des zwischen dem Dienstrechner SSC und dem Dienstserver SSV verwendeten
Object-Request-Broker-Kommunikationsmechanismus kann jeder geeignete
Kommunikationsmechanismus zum Einsatz kommen.