-
Die
vorliegende Erfindung betrifft allgemein eine Netzwerkvermittlung
in einem Telekommunikationssystem und spezieller ein Verfahren und
ein System für
eine intelligente verteilte Netzwerkarchitektur für eine Dienstverarbeitung.
-
Ein
Netzwerkdienst ist eine Funktion, welche mittels eines Kommunikationsnetzwerkes
geleistet wird, wie z.B. ein Daten- oder Telefonienetzwerk, und dessen
assoziierten Ressourcen als Antwort auf eine Interaktion mit einem
oder mehreren Teilnehmern. Z.B. kann ein Telephonienetzwerkeinwohnerdienst, wie
z.B. eine Rufweiterleitung oder ein Ton-Mailbox-Zugang, durch einen Teilnehmer aufgerufen
werden mittels Wählen
einer speziellen Sequenz von Zahlen. Andere Netzwerkdienste können darauf
gerichtet sein, einen Netzwerkbesitzer bei der Sicherheit, Validierung
und Authentifikation zu helfen. Hinzufügen oder Modifizieren eines
Dienstes erfordert Änderungen,
welche in dem Kommunikationsnetzwerk vorgenommen werden müssen.
-
Die
meisten konventionellen Telekommunikationsnetzwerke sind aus zusammengeschalteten Vermittlungen
bzw. Switches und Kommunikationsgeräten zusammengesetzt. Diese
Vermittlungen werden durch integrierte oder eingebettete Prozessoren, betrieben
durch geschützte
Software oder Firmware, entworfen durch den Vermittlungshersteller,
gesteuert. Typischerweise muss die Vermittlungsherstellersoftware
oder Firmware alle funktionalen Aspekte einer Dienstverarbeitung,
Rufverarbeitung, Einrichtungsverarbeitung und eines Netzwerkmanagements bzw.
Netzwerkverwaltung unterstützen.
Dies bedeutet, dass wenn ein Netzwerkbesitzer wünscht, einen neuen Dienst zu
implementieren oder einen existierenden Dienst zu modifizieren,
muss die Software von jeder Vermittlung in dem Netzwerk durch die
verschiedenen Vermittlungshersteller korrigiert werden.
-
Die
Tatsache, dass das Netzwerk verschiedene Vermittlungsmodelle von
verschiedenen Herstellern enthält,
erfordert eine sorgfältige
Entwicklung, Testung und Einsatz von neuer Soft ware. Die geforderte
Zeit zum Entwickeln, Testen und Einsetzen der neuen Software wird
verlängert,
weil die Code-Größe bei jeder
Vermittlung größer und
komplexer mit jeder neuen Korrektur bzw. Revision anwächst. Daher
kann dieses Verfahren einige Jahre dauern. Zusätzlich belastet diese erhöhte Komplexität weiter
die Vermittlungsprozessoren, erhöht
die Gefahren für
eine Vermittlungsfehlfunktion und kann die Modifikation oder den
Austausch der Vermittlung erfordern.
-
Darüber hinaus
resultiert der Umstand, dass viele Netzwerkbesitzer von einem allgemeinen
Satz von Vermittlungsherstellern abhängen, in zwei unerwünschten
Situationen, welche den Wettbewerb einschränken. Erstens könnte eine
Herstellersoftwareversion versuchen Änderungen einzubauen, gefordert
durch verschiedene Netzwerkbesitzer, was die Netzwerkbesitzer von
einer echten Unterscheidung ihrer Dienste von den Diensten, bereitgestellt
durch ihren Wettbewerb, abhält.
Dieses veranlasst einige Netzwerkbesitzer auch zu warten, bis der
Hersteller Anforderungen von anderen Netzwerkbesitzern in die neue
Version einbaut. Zweitens eine Vermittlungssoftwareversion, inkorporierend
eine Funktion, wie gefordert durch einen Netzwerkbesitzer, einen neuen
Service zu implementieren, kann unbeabsichtigt zugänglich für andere
Netzwerkbesitzer werden.
-
Diese
Probleme sind nicht tolerierbar geworden, da die Forderungen nach
neuen Netzwerkdiensten sich exponentiell über die letzten fünf bis zehn Jahre
erhöht
haben, wegen der erhöhten
Teilnehmermobilität,
der erhöhten
Vielfalt und Bandbreite des Verkehrs, der Auflösung von traditionellen Nummernplänen, anspruchsvolleren
Diensten und erhöhten
Wettbewerb. Daher ist es weithin anerkannt, dass neue Netzwerkarchitekturen
einen flexibleren Weg einer Erzeugungs-, Einsatz- und Ausführungs-Dienstlogik
benötigen.
In diesem Zusammenhang offenbart WO96/20448 eine flexible Netzwerkplattform
und ein Rufverarbeitungssystem, worin das Rufverarbeitungssystem
eine bestimmte Rufverarbeitungsarchitektur und ein Ressourcenmanagementsystem
beinhaltet. Die Offenbarung dieses Dokuments ist jedoch nicht ausreichend,
die obigen Probleme zu lösen.
-
Um
die neuartige Architektur der hierin beschriebenen vorliegenden
Erfindung vollständig
zu verstehen, wird die folgende Beschreibung des Standes der Technik
mit Bezug auf die 1 bis 4 bereitgestellt.
-
Bezug
nehmend auf 1 wird eine logische Darstellung
von verschiedenen Vermittlungsar chitekturen, einschließend die
vorliegende Erfindung, gezeigt. Eine monolithische Vermittlung,
welche allgemein als 20 gekennzeichnet ist, enthält Dienstverarbeitungsfunktionen 22,
Rufverarbeitungsfunktionen 24, Einrichtungsverarbeitungsfunktionen 26 und
eine Vermittlungsstruktur 28. Alle diese Funktionen 22, 24, 26 und 28 werden
durch den Vermittlungshersteller erzeugt und betrieben auf proprietären bzw.
geschützten
Plattformen, welche von Hersteller zu Hersteller variieren. Als
ein Ergebnis können
diese Funktionen 22, 24, 26 und 28 nicht
ohne die Hilfe des Herstellers modifiziert werden, wodurch eine
Dienstentwicklung und Implementierung verzögert ist und die Kosten für die Markteinführung eines
neuen Dienstes sich erhöhen.
Die Entwicklung von neuen und innovativen Diensten, Rufverarbeitung,
Datenverarbeitung, Signalverarbeitung und Netzwerkoperationen sind
daher eingeschränkt
durch die Herstellersteuerung über
seine geschützte
Vermittlungshardware und Software und die inhärente Schwierigkeit der Etablierung
und Implementierung von Industriestandards.
-
Die
Dienstverarbeitungsfunktionen 22 werden innerhalb der monolithischen
Vermittlung 20 codiert und erlauben nur eine lokale Steuerung
dieses Verfahrens, basierend auf lokalen Dateninhalten und der gewählten Nummer.
Diese lokale Information wird durch eine handcodierte Prozessmaschine
interpretiert, welche die codierte Dienstfunktion ausführt. Die
Rufverarbeitungsfunktionen 24 sind fest programmiert und
unterstützen
die Rufveranlassungs- und
Rufbeendigungsfunktionen. Dieses Verfahren erstellt und beendet überhaupt
individuelle Verbindungen, um einen Anruf vollständig auszuführen. Ähnlich dazu sind auch die Einrichtungsverarbeitungsfunktionen 26 fest
programmiert und stellen die gesamte Datenverarbeitung, betreffend
die physikalischen Ressourcen, welche in einem Anruf involviert sind,
bereit. Der Vermittlungsaufbau 28 repräsentiert die Hardwarekomponente
der Vermittlung und bringt den Computer dazu, die monolithische
Software zu verarbeiten, welche durch den Vermittlungshersteller bereitgestellt
wird, wie z.B. Northern Telecom, Inc. Der Vermittlungsaufbau 28 unterstützt die
physikalischen Möglichkeiten
bzw. Einrichtungen, welche zum Etablieren einer Verbindung notwendig
sind, und kann ohne zu limitieren einschließen Trägergeräte (T1's und DSO's), Vermittlungsmatrixgeräte (Netzwerkstrukturen
und ihre Prozessoren), Verbindungslagen- bzw. „Link layer" – Signalprozessoren (SS7, MTP,
ISDN, LAPD) und spezialisierte Schaltkreise (Konferenzports, Audiotondetektoren).
-
Bei
einem Versuch, die zuvor beschriebenen Probleme zu adressieren,
befürworten
die International Telecommunications Union und das European Telecommunication
Standards Institute den ITU-T intelligenten Netzwerkstandard ("IN"). Ähnlich dazu
befürwortet
Bellcore den Advanced Intelligente Network Standard ("AIN"). Obwohl diese beiden
Standards in der Präsentation
und dem Entwicklungsstand differieren, haben sie fast identische
Ziele und Basiskonzepte. Entsprechend werden diese Standards als eine
einzige Netzwerkarchitektur betrachtet, in welcher die Dienstverarbeitungsfunktionen 22 von
der Vermittlung abgetrennt sind.
-
Unter
Verwendung der IN- und AIN-Architekturen könnte ein Netzwerkbesitzer vermutlich
einen neuen Dienst durch Erzeugung und Entwicklung eines neuen Dienstlogikprogramms
bzw. Service Logic Program ("SLP") ausliefern, welches
essenziell ein Verzeichnis von dienstunabhängigen Ausführungsblöcken bzw. Service Independent
Building Blocks ("SIBB") darstellt, welche
während
eines gegebenen Typs von Anruf aufgerufen werden. Gemäß diesem Ansatz
arbeiten eine Anzahl von spezifischen Elementtypen in Verbindung
mit einem SLP zusammen, um Dienste für die Netzwerkteilnehmer bereitzustellen.
Als ein Ergebnis werden einige neue oder potenzielle Dienste durch
die bestehenden SIBBs beschränkt.
-
Die
IN- oder AIN-Architektur, welche allgemein als 40 bezeichnet
ist, separiert logisch die Funktionen der monolithischen Vermittlung 20 in
einen Dienststeuerungspunkt bzw. Service Control Point ("SCP") 42 und
einen Dienstvermittlungspunkt bzw. Service Switching Point ("SSP") und ein Vermittlungssystem
bzw. Switching System 44. Der SCP 42 enthält die Dienstverarbeitungsfunktionen 22,
während
der SSP und das Vermittlungssystem 44 die Rufverarbeitungsfunktionen 24,
die Einrichtungsverarbeitungsfunktionen 26 und die Vermittlungsstruktur 28 enthalten.
In diesem Fall werden die Rufverarbeitungsfunktionen 24,
die Einrichtungsverarbeitungsfunktionen 26 und die Vermittlungsstruktur 28 fest programmiert,
miteinander gemischt und undifferenziert, wie durch Gruppe 46 dargestellt.
-
Der
Dienstvermittlungspunkt ("SSP") ist ein funktionales
Modul, welche sich in einer Vermittlung befindet, um zu erkennen,
wenn eine Teilnehmersignalisierung mehr als ein einfaches Leiten,
einzig auf einer gewählten
Nummer basierend, erfordert. Der SSP schiebt eine weitere Handhabung
des Rufes auf, während
er eine Anfrage nach einer korrekten Handhabung des Rufes an den
entfernten SCP 42 initiiert, welche essenziell als ein
Datenbankserver für eine
Anzahl von Vermittlungen agiert. Diese Unterteilung der Verarbeitung
resultiert in der Auslagerung der seltenen, jedoch Zeit verbrauchenden
Aufgabe der Handhabung von Spezialdienstrufen von der Vermittlung.
Weiterhin führt
diese moderate Zentralisierung zu einem Ausgleich zwischen einem
Bestehen eines leicht modifizierbaren, stark belasteten Speichers,
unterstützend
das gesamte Netzwerk, und dem Aufstellen einer vollständigen Kopie
des Speichers bei jeder Vermittlung.
-
Nun
Bezug nehmend auf 2 wird ein Diagramm eines Telekommunikationssystems,
anwendend eine IN- oder AIN-Architektur, gezeigt und ist allgemein
mit 50 bezeichnet. Verschiedene Kundensysteme, wie ein
ISDN Terminal 52, ein erstes Telefon 54 und ein
zweites Telefon 56 werden mit dem SSP und dem Vermittlungssystem 44 verbunden. Das
ISDN Terminal 52 wird mit dem SSP und dem Vermittlungssystem 44 durch
eine Signalisierungsleitung 60 und eine Transportleitung 62 verbunden.
Das erste Telefon 54 wird mit dem SSP und dem Vermittlungssystem 44 über eine
Transportleitung 64 verbunden. Das zweite Telefon 56 wird
mit einem entfernten Vermittlungssystem 66 durch eine Transportleitung 68 verbunden
und das entfernte Vermittlungssystem 66 wird mit dem SSP
und dem Vermittlungssystem 44 durch eine Transportleitung 70 verbunden.
-
Wie
zuvor mit Bezug auf 1 beschrieben ist der SSP 70 ein
funktionales Modul, welche sich in einer Vermittlung befindet, um
zu erkennen, wenn eine Teilnehmersignalisierung mehr als ein einfaches Leiten,
basierend auf der gewählten
Nummer, erfordert. Der SSP 70 schiebt die weitere Handhabung des
Rufes auf, während
er eine Anfrage für
eine richtige Handhabung des Rufes initiiert. Diese Anfrage wird
in Form einer SS 7 Nachricht an einen entfernten SCP 42 gesendet.
Der Dienststeuerungspunkt 42 ist so genannt, weil eine Änderung
des Datenbankinhaltes an dieser Position die Netzwerkfunktion verändern kann,
wie es Teilnehmern erscheint, die durch viele gegenüberliegende
Vermittlungen verbunden sind. Die Anfrage wird über eine Signalisierungsleitung 72 an
den Signaltransferpunkt bzw. Signal Transfer Point ("STP") 74 gesendet,
welcher einfach ein Router für
eine SS 7 Benachrichtigung unter diesen Elementen ist, und dann
durch eine Signalisierungsleitung 76 zu dem SCP 42.
-
Das
integrierte Servicemanagementsystem ("ISMS") 78 ist
als ein Managementwerkzeug vorgesehen, um Dienste anzuwenden oder
zu verändern oder
um den Per-Teilnehmerzugang zu den Diensten zu managen. Das ISMS 78 arbeitet
hauptsächlich durch Änderung
der Betriebslogik und den Daten, gespeichert innerhalb der SSP 70 und
SCP 42. Das ISMS 78 besitzt verschiedene Anschlüsse 80 und 82. Dieses
ISMS 78 wird verbunden mit dem SCP 42 durch die
Betriebsleitung 84, mit dem SSP und dem Vermittlungssystem 44 durch
die Betriebsleitung 86 und mit dem intelligenten Peripheriegerät bzw. Intelligent
Peripheral ("IP") 88 durch
die Betriebsleitung 90. Das intelligente Gerät 88 ist
ein Gerät,
das verwendet wird, Funktionen dem Netzwerk hinzuzufügen, welche
bei den Vermittlungen nicht verfügbar
sind, wie z.B. Stimmrückmeldung
oder ein Spracherkennungssystem. Das IP 88 wird mit dem
SSP und dem Vermittlungssystem 44 durch eine Signalisierungsleitung 92 und
eine Transportleitung 94 verbunden.
-
Nun
Bezug nehmend auf die 2 und 3 wird die
Verarbeitung eines Rufes in Übereinstimmung
mit dem Stand der Technik beschrieben werden. Der Ruf wird initiiert,
wenn der Kunde den Hörer
abnimmt und das Wählen
beginnt in Block 100. Der SSP 70 überwacht
bei der Vermittlungsfirma das Wählen
und erkennt die Auslösesequenz
in Block 102. Der SSP 70 schiebt die weitere Handhabung des
Rufes auf bis die Dienstlogik in Block 104 befragt werden
kann. Der SSP 70 erzeugt dann eine Standard SS 7 Nachricht
und sendet diese durch STP(S) 74 an den SCP 42 in
Block 104. Der SCP 42 empfängt und decodiert die Nachricht
und ruft den SLP in Block 106 auf. Das SLI interpretiert
den SLP, welcher zum Aktualisieren anderer Funktionen wie dem Datenbanksuchfeld
für eine
Nummernübersetzung
aufrufen kann in Block 106. Der SCP 42 sendet
eine SS 7 Nachricht an den SSP und das Vermittlungssystem 44 zurück, betreffend
die Handhabung des Anrufes, oder liefert andernfalls die Nachrichten
an die Netzwerkelemente, um den richtigen Dienst in Block 108 auszuführen. Zum
Abschluss des Anrufes wird eine SS 7 Nachricht an die Vermittlungen
versendet, um den Anruf zu beenden, und Anrufdetailaufnahmen werden
von jeder Vermittlung, involviert in den Anruf in Block 110,
erzeugt. Die Anrufdetailaufzeichnungen werden offline gesammelt,
korreliert und aufgelöst
für jeden
Anruf um eine Rechnung für
Gebührenanrufe in
Block 112 zu erhalten. Die Rufverarbeitung wird beendet
in Block 114.
-
Die
IN- und AIN-Architekturen versuchen einen Standardsatz von Funktionen
vorzudefinieren, um alle vorhersehbaren Dienste zu unterstützen. Diese
Standardfunktionen sind alle fest programmiert in den verschiedenen
Zustandsmaschinen in der Vermittlung. Unglücklicherweise können einige
neue Funktionen, welche möglicherweise
aufkommen in Verbindung mit neuen Technologien oder unvorhergesehenen
Diensterfordernissen, nicht implementiert werden ohne eine extensive Überholung
und Testung der Netzwerksoftware in Hinblick auf viele Verkäuferplattformen.
Wenn darüber
hinaus eine neue Funktion Änderungen
an standardisierten Rufmodellen, Protokollen oder Schnittstellen
erfordert, kann die Implementierung des Dienstes, verwendend diese Funktion,
sich verzögern
bis die Änderungen
durch eine Industriestandardgruppe ratifiziert wurden. Aber gerade
wenn Entwurfstandards versucht haben, den Satz von IN- und AIN-
unterstützten
Funktionen zu erweitern, haben die Zubehörzulieferer sich geweigert,
diese Entwurfstandards wegen der starken Erhöhung in der Codierkomplexität zu bestätigen.
-
Nun
Bezug nehmend auf 4 wird ein Verfahren für eine generische
Diensterzeugung in Übereinstimmung
mit dem Stand der Technik beschrieben werden. Der Netzwerkbesitzer
fordert eine neue Funktion, beinhaltend einen neuen Dienst, einen neuen
Anrufszustand und ein neues Protokoll in Block 120 an.
Wenn ein neues Anrufmodell am Entscheidungsblock 122 gefordert
wird, muss ein Vorschlag an die Körperschaft für Standards
eingereicht werden und der Netzwerkbesitzer muss auf die Industrieanpassung
des neuen Standards warten, was ein bis drei Jahre dauern kann in
Block 124. Nachdem der neue Standard angepasst ist oder
wenn ein neues Anrufmodell nicht gefordert wird, wie festgelegt
im Entscheidungsblock 122, muss der Netzwerkbesitzer nachfragen
und auf Codierupdates von jedem Hersteller warten, um die neue Funktion
zu implementieren, welches sechs bis acht Monate dauern kann, in
Block 126.
-
Der
Netzwerkbesitzer muss die neue Funktion und alle früheren Funktionen
von jedem Hersteller testen in Block 128, was ein bis drei
Monate dauern kann. Wenn keiner der Tests erfolgreich war, wie festgestellt
im Entscheidungsblock 130, und der Grund des Fehlers ein
Konstruktionsproblem ist, wie festgestellt im Entscheidungsblock 132,
muss das Verfahren in Block 122 erneut gestartet werden.
Wenn jedoch der Grund des Fehlers ein Codierproblem, wie festgestellt
im Entscheidungsblock 132, ist, muss der Hersteller die
Codierung in Block 134 korrigieren und das Testen muss
in Block 128 wiederholt werden.
-
Wenn
alle Tests erfolgreich sind, wie festgestellt im Entscheidungsblock 130,
und der Hersteller erzeugt den Dienst, wie festgestellt im Entscheidungsblock 136,
muss der Netzwerkbesitzer eine neue Dienstversion von dem Hersteller
anfordern und auf die Lieferung der getesteten Version in Block 138 warten.
Wenn jedoch der Netzwerkbesitzer den Dienst erzeugt, wie festgestellt
im Entscheidungsblock 136, muss der Netzwerkbesitzer eine
neue Version des Dienstes erzeugen, verwendend ein Erzeugungswerkzeug
und durch eine Einheitstestung iterieren, um sicherzustellen, dass
der neue Dienst korrekt arbeitet in Block 140. In jedem
Fall leistet der Netzwerkbesitzer dann einen Integrationstest, um
sicherzustellen, dass alle früheren
Dienste noch vollständig
arbeiten, in Block 142. Dann muss ein Systemtest durchgeführt werden,
um die korrekte Koordination zwischen dem SCP und der Vermittlung
in Block 144 si cherzustellen. Der Netzwerkbesitzer muss
dann die simultane Ladung der neuen Softwareversion für alle Vermittlungen
und SCP's in dem Netzwerk
in Block 146 koordinieren. Die Implementierung der neuen
Funktion wird in Block 148 abgeschlossen.
-
Nun
erneut Bezug nehmend auf 2 erheben sich andere Begrenzungen
der IN- und AIN-Architektur,
wenn die Anrufverarbeitung- und Einrichtungsverarbeitungsfunktionen,
namentlich der SSP 70, innerhalb der Vermittlung arbeiten
sollen. Als ein Ergebnis müssen
diese Funktionen bereitgestellt werden von jedem Vermittlungshersteller
unter Verwendung ihrer geschützten
Software. Die Netzwerkbesitzer sind daher immer noch stark abhängig von den
Herstellersoftwareversionen bei der Unterstützung neuer Funktionen. Daneben
verkompliziert die Sache weiter, dass der Netzwerkbesitzer die SSP 70 Module
nicht in Verbindung mit anderen Modulen in einer vereinigten Entwicklung
und Testumgebung testen kann. Darüber hinaus gibt es keine Sicherheit, dass
ein SSP 70, beabsichtigt für eine Vermittlungsherstellerverarbeitungsumgebung,
mit der Netzwerkbesitzerdiensterzeugungsumgebung kompatibel sein wird.
-
Diese
Abhängigkeit
vieler Netzwerkbesitzer von einem allgemeinen Satz von Vermittlungsherstellern
führt zu
zwei unerwünschten
Situationen, welche den Wettbewerb beschränken. Erstens eine Herstellersoftwareversion
könnte
versuchen, Änderungen, gefordert
durch verschiedene Netzwerkbesitzer, zu inkorporieren, wodurch die
Netzwerkbesitzer davon abgehalten werden, ihre Dienste tatsächlich von
den Diensten, bereitgestellt durch ihre Wettbewerber, zu unterscheiden.
Dieses veranlasst einige Netzwerkbesitzer auch zu warten, bis der
Hersteller Forderungen von anderen Netzwerkbesitzern in die neue
Version inkorporiert. Zweitens eine Vermittlungssoftwareversion,
inkorporierend eine Funktion, wie gefordert von einem Netzwerkbesitzer,
um einen neuen Dienst zu implementieren, kann unbeabsichtigter Weise
für andere
Netzwerkbesitzer verfügbar
werden. Trotz der Absichten der IN- und AIN-Architekten werden daher
die Netzwerkbesitzer-Erzeugung, -Testung und -Anwendung neuer Dienste
noch behindert, da der Netzwerkbesitzer keine vollständige Kontrolle
von oder Zugang zu den funktionalen Elementen hat, welche das Netzwerkdienstverhalten festlegen.
-
Bei
einem anderen Versuch diese Probleme zu lösen, trennt eine separate Vermittlungsintelligenz-
und Vermittlungsstruktur- bzw. Separate Switch Intelligence- und
Switch Fabric("SSI/SF") Architektur, welche
allgemein als 150 (1) bezeichnet
ist, logisch den SSP 70 von dem Vermittlungssystem 44.
Nun wiederum Bezug nehmend auf 1 enthält die Ver mittlungsintelligenz 152 die
Rufverarbeitungsfunktionen 24 und die Einrichtungsverarbeitungsfunktionen 26,
welche verschlüsselt
in diskreten Zustandstabellen mit korrespondierenden festprogrammierten
Zustandsautomatenmaschinen sind, welche durch die Kreise 154 und 156 angezeigt
sind. Die Schnittstelle zwischen den Vermittlungsstrukturfunktionen 158 und
den Vermittlungsintelligenzfunktionen 152 kann erweitert
werden durch ein Kommunikationsnetzwerk, so dass die Vermittlungsstruktur 158 und
die Vermittlungsintelligenz 152 nicht notwendigerweise
physikalisch am selben Ort sein müssen, um innerhalb desselben
Prozessors ausgeführt
zu werden, oder besitzen gerade eine 1:1 Korrespondenz. Die Vermittlungsintelligenz 152 stellt
wiederum eine einheitliche Schnittstelle von einfachen nichtdienstspezifischen,
nichtherstellerspezifischen Funktionen dar, welche allen Vermittlungen
gemein ist.
-
Ein
intelligenter Rechenkomplex bzw. Intelligent Computing Complex ("ICC") 160 enthält die Dienstverarbeitungsfunktionen 22 und
kommuniziert mit mehreren Vermittlungsintelligenzelementen 152. Dieser
Ansatz bietet dem Netzwerkbesitzer Vorteile bei der flexiblen Dienstimplementierung,
da alle oder zumindest die elementaren Funktionen außerhalb des
Bereiches der herstellerspezifischen Codierung verschoben werden.
Weitere Verbesserungen können
realisiert werden durch Bereitstellen einer einheitlicheren Umgebung
für die
Erzeugung, Entwicklung, Testung und Ausführung der Dienstlogik.
-
Wie
zuvor diskutiert, basieren die aktuellen Netzwerkvermittlungen auf
einer monolithischen geschützten
Hardware und Software. Obwohl Netzwerkvermittlungen Millionen von
Dollars kosten können,
ist solch eine Ausrüstung
relativ langsam betreffend die Verarbeitungsgeschwindigkeit im Hinblick auf
die gegenwärtig
verfügbare
Rechentechnologie. Z.B. basieren diese Vermittlungen auf Prozessoren mit
einer reduzierten Instruktionssatzrechnung bzw. Reduced-Instruction
Set Computing – ("RISC") Prozessoren, welche
im Bereich von 60 MHz laufen und miteinander kommunizieren, verwendend
ein Datenkommunikationsprotokoll, wie das X.25, das typischerweise
eine Übertragungsrate
von 9,6 Kb/s zwischen den verschiedenen Plattformen in einem Vermittlungsnetzwerk
unterstützt.
Dieses ist extrem langsam verglichen mit Personalcomputern, welche Prozessoren
enthalten, die mit 200 MHz oder darüber und neuesten Computerarbeitsstationen
arbeiten, welche 150 Mb/s FDDI- und ATM-Schnittstellen ermöglichen. Netzwerkbesitzer müssen dementsprechend
in die Lage versetzt werden, neueste Arbeitsstationen anstelle von
geschützter
Hardware zu verwenden.
-
Die
vorliegende Erfindung kann einschließen einen intelligenten Rufprozessor,
einen intelli genten Vermittlungsknoten und ein intelligentes Kommunikationsnetzwerk
zur Verwendung in einem Kommunikationssystem. Der intelligente Rufprozessor
kann einschließen
eine logische Plattform, aufweisend eine Vielzahl von Funktionen,
wobei zumindest eine der Funktionen eine Dienstverarbeitungsfunktion
ist, zumindest eine der Funktionen eine Rufverarbeitung ist und
zumindest eine der Funktionen eine Einrichtungsverarbeitung ist,
und einen Prozessor zum Ausführen
der Vielzahl von Funktionen. Der intelligente Vermittlungsknoten
kann einschließen
einen intelligenten Rufprozessor und einen Ressourcenkomplex, kommunizierbar
verbunden mit dem intelligenten Rufprozessor und logisch getrennt
von dem intelligenten Rufprozessor. Das intelligente Kommunikationsnetzwerk
kann einschließen
eine Vielzahl von intelligenten verteilten Netzwerkknoten, ein Netzwerkmanagementsystem
zum Überwachen
und Steuern eines Weitverkehrsnetzwerkes bzw. Wide Area Network
und der Vielzahl von intelligenten Vermittlungsknoten, wobei das
Weitverkehrsnetzwerk untereinander die Vielzahl von intelligenten
verteilten Netzwerkknoten und das Netzwerkmanagementsystem verbindet.
-
Die
obigen und weitere Vorteile der vorliegenden Erfindung können besser
verstanden werden durch Bezugnahme auf die folgende Beschreibung
in Verbindung mit, den beiliegenden Zeichnungen in welchen gilt:
-
1 ist
eine logische Darstellung von verschiedenen Vermittlungsarchitekturen,
einschließlich der
vorliegenden Erfindung.
-
2 ist
ein Diagramm eines Telekommunikationssystems, anwendend eine typische
intelligente Netzwerkkonfiguration entsprechend des Standes der
Technik.
-
3 ist
ein Flussdiagramm für
eine generische Rufverarbeitung entsprechend dem Stand der Technik.
-
4 ist
ein Flussdiagramm für
eine generische Diensterzeugung entsprechend dem Stand der Technik.
-
5 ist
ein Diagramm für
ein Telekommunikationssystem, anwendend eine intelligente verteilte Netzwerkarchitektur
in Übereinstimmung
mit der vorliegenden Erfindung.
-
6 ist
ein logisches und funktionales Diagramm eines Telekommunikationssystems,
anwendend eine intelligente verteilte Netzwerkarchitektur in Übereinstimmung
mit der vorliegenden Erfindung.
-
7 ist
ein Diagramm, darstellend das Layering von funktionalen Schnittstellen
innerhalb eines intelligenten Rufprozessors in Übereinstimmung mit der vorliegenden
Erfindung.
-
8 ist
ein Venn-Diagramm die Verschachtelung der Verarbeitungszusammenhänge, wonach eine
virtuelle Maschine eine Dienstlogikausführungsumgebung in Übereinstimmung
mit der vorliegenden Erfindung unterstützt.
-
9 ist
ein Diagramm, darstellend die Klassenhierarchie der Managed Objects
innerhalb eines intelligenten Rufprozessors in Übereinstimmung mit der vorliegenden
Erfindung.
-
10 ist
ein Diagramm, darstellend die Interaktion von Managed Objects in
einem beispielhaften Rufverarbeitungsszenario in Übereinstimmung mit
der vorliegenden Erfindung.
-
11 ist
ein Flussdiagramm für
eine generische Rufverarbeitung in Übereinstimmung mit der vorliegenden
Erfindung.
-
12 ist
ein Flussdiagramm für
eine generische Diensterzeugung, verwendend die Managed Objects
in Übereinstimmung
mit der vorliegenden Erfindung.
-
13 veranschaulicht
die Verwendung von ähnlichen
Werkzeugen während
der Diensterzeugung, um kompatible Objekte für dieselbe Zielumgebung in Übereinstimmung
mit der vorliegenden Erfindung zu erzeugen.
-
14 veranschaulicht,
wie die Palette für jedes
Werkzeug in Erwiderung zu neuen funktionalen Stücken in Übereinstimmung mit der vorliegenden Erfindung
variieren kann.
-
15 veranschaulicht
den Managed Objects-Erzeugungsumgebung-Verwendungsfluss.
-
16 veranschaulicht
den Managed Objects-Erzeugungsumgebungsspeicher und
-
17 veranschaulicht,
wie die vereinheitlichte Ausführungsumgebung
ebenfalls eine vereinfachte Erzeugung und Modifikation gerade der
Werkzeuge ermöglicht,
bei welcher die Entwickler die Objekte für das SLEE erzeugen.
-
Nun
Bezug nehmend auf 1 wird eine intelligente verteilte
Netzwerkarchitektur bzw. Intelligent Distributed Network Architecture
("IDNA") in Übereinstimmung
mit der vorliegenden Erfindung allgemein als 170 bezeichnet.
Die vorliegende Erfindung vereint den ICC 160 und die Vermittlungsintelligenz 152 der
SSI/SF-Architektur 150 in einem intelligenten Rufprozessor
bzw. Intelligent Call Prozessor ("ICP") 172.
Im Gegensatz zu den IN- oder AIN- oder SSI/SF-Architekturen 40,
deren Funktionen in Statustabellen definiert sind, enthält der ICP 172 die Dienststeuerungsfunktionen 22,
Rufverarbeitungsfunktionen 24 und Einrichtungsverarbeitungsfunktionen 26 als
Managed Objects in einer objektorientierten Plattform, welche durch
die Blöcke 174, 176 und 178 symbolisiert
ist. Der ICP 172 ist logisch getrennt von dem Ressourcenkomplex 180.
-
Nun
Bezug nehmend auf 5 wird ein Telekommunikationssystem,
anwendend eine intelli gente verteilte Netzwerkarchitektur in Übereinstimmung
mit der vorliegenden Erfindung beschrieben werden und wird allgemein
bezeichnet als 200. Das Weitverkehrsnetzwerk bzw. Wide
Area Network ("WAN") 202 ist
ein System, welches die Verteilung der Anwendungen und Daten quer über ein
großes geographisches
Gebiet unterstützt.
Das Transportnetzwerk basiert auf einem synchronen optischen Netzwerk
bzw. Synchronous Optical NETwork ("SONET") und verbindet die IDNA-Knoten 204 und
ermöglicht
den Anwendungen innerhalb dieser Knoten mit jedem anderen zu kommunizieren.
-
Jeder
IDNA-Knoten 204 enthält
einen intelligenten Rufprozessor ("ICP") 172 und
einen Ressourcenkomplex 180 (1). 5 veranschaulicht
einen IDNA-Knoten 204, aufweisend einen Ressourcenkomplex
A bzw. Resource Complex A ("RCA") 206 und
einen Ressourcenkomplex B bzw. Resource Complex B ("RCB ") 208. Der
ICP 172 kann mit Zusatzprozessoren 210 verbunden
werden, welche bestehende Unterstützungsfunktionen bereitstellen,
wie z.B. Beschaffung, Bezahlung und Wiederherstellung. Schließlich können die
durch die Durchsatzprozessoren 210 bereitgestellten Funktionen
durch Funktionen innerhalb des Netzwerkmanagementsystems ("NMS") 212 aufgenommen
werden. Der ICP 172 kann ebenso mit andern ICP's 172, anderen
Netzwerken (nicht gezeigt) oder anderen Geräten (nicht gezeigt) durch eine
direkte Verbindung 214, aufweisend eine Signalisierung 216 und
Trägerverbindungen 218,
verbunden werden. Eine direkte Verbindung verhindert eine Verzögerung zwischen
den verbundenen Geräten
und erlaubt den Geräten
in ihrer eigenen Sprache zu kommunizieren. Der ICP 172 ist
das "Gehirn" des IDNA-Knotens 204 und
ist vorzugsweise ein Mehrzweckcomputer, welcher von einem einzelnen
Prozessor mit einem einzelnen Speichergerät bis zu einem großumfänglichen
Computernetzwerk, in Abhängigkeit
von den Verarbeitungserfordernissen des IDNA-Knotens 204,
reichen kann. Vorzugsweise wird der Mehrzweckcomputer eine redundante
Verarbeitung, einen Speicher und Verbindungen aufweisen.
-
Wie
hierin verwendet, gehören
Mehrzweckcomputer zu Computern, welche sind oder zusammengesetzt
sein können
mit kommerziellen Standardkomponenten im Gegensatz zu zweckbestimmten
Geräten,
speziell konfiguriert und gebaut für Telephonievermittlungsanwendungen.
Die Integration von Netzwerkcomputern innerhalb des Rufnetzwerkes
bietet zahlreiche Vorteile.
-
Die
Verwendung von Mehrzweckcomputern gibt dem ICP 172 die
Möglichkeit
mit zusätzlicher Hardware
aufgerüstet
zu werden, um erhöhten
Verarbeitungsbedürfnissen
zu begegnen.
-
Diese
Zusätze
schließen
die Fähigkeit
ein, die Verarbeitungsgeschwindigkeit, den Datenspeicher und die
Kommunikationsbandbreite zu erhöhen. Diese
Zusätze
erfordern keine Modifikation der herstellerspezifischen Software
und/oder Hardware bei jeder Vermittlung in dem Rufnetzwerk. Konsequenterweise
können
neue Dienste und Protokolle implementiert werden und in einem globalen
Maßstab ohne
Modifikation von individuellen Diensten in dem Vermittlungsnetzwerk
installiert werden. Bei einer Änderung
von monolithischen Vermittlungen 20 (1)
zu intelligenten Rufprozessoren 172 stellt die vorliegende
Erfindung die vorangegangenen Vorteile und erhöhten Möglichkeiten bereit.
-
In
dem Falle von Anwendungen, welche mehr Verarbeitungsleistung erfordern,
erlaubt eine Multiverarbeitung die Verwendung von weniger teueren
Prozessoren, um das Preis/Leistungsverhältnis für Rufverarbeitung zu optimieren.
In anderen Anwendungen kann es vorteilhaft, notwendig oder kosteneffektiver
sein, leistungsfähigere
Maschinen zu verwenden, wie Minicomputer, mit höheren Verarbeitungsgeschwindigkeiten.
-
Der
ICP 172 kann, wie oben beschrieben, ein Cluster von Mehrzweckcomputerbetriebssystemen, z.B.
ein UNIX oder Windows NT Betriebssystem, umfassen. Z.B. kann in
einer großen
Anwendung, unterstützend
bis zu 100.000 Ports an einem einzigen Ressourcenkomplex, der ICP 172 bestehen
aus (16 -) 32 – Bit-Prozessoren,
arbeitend bei 333 MHz in einem symmetrischen Multiprozessorcluster.
Die Prozessoren können
z.B. in vier getrennte Server mit jeweils vier Prozessoren unterteilt
sein. Die individuellen Prozessoren würden mit einem Systemverkehrsnetzwerk
bzw. System Area Network ("SAN") oder einer Clustertechnologie
verbunden werden. Der Prozessorcluster könnte einen Zugang zu dem redundanten
Array von unabhängigen
Festplatten bzw. Redundant Array of Independent Disks ("RAID") modularen Datenspeichergeräten teilen.
Der geteilte Speicher kann eingestellt werden durch Zugabe oder
Entfernung der modularen Festplattenspeichergeräte. Die Server in den Clustern
würden
vorzugsweise redundante Verbindungen zu dem RC 180 (1)
teilen.
-
Wie
veranschaulicht und ähnlich
zu dem "plug and
play"-Merkmal von
Personalcomputern ist die ICP-Softwarearchitektur ein offenes Verarbeitungsmodell,
welches die Austauschmöglichkeit
von (1) Managementsoftware, (2) ICP Anwendungen, (3) Rechenhardware
und - Software,
(4) Ressourcenkomplexkomponenten und selbst (5) Dienstarchitektur
und - Verarbeitung
erlaubt. Solch eine generische Architektur reduziert die Aufrechterhaltungskosten
im Hinblick auf die Standardisierung und stellt die Vorteile bereit,
welche durch die Öko nomien
der Größe herrühren.
-
Daher
ermöglicht
die vorliegende Erfindung die Aufteilung der Entwicklungsarbeit
und die Verwendung von modularen Werkzeugen, wodurch eine schnellere
Entwicklung und Implementierung von Diensten erreicht wird. Darüber hinaus
liegen die Verwendung von und die relevanten Aspekte des Dienstmanagements
innerhalb der Kontrolle des Netzwerkoperators mit einer geforderten
Basis im Gegensatz zu den Zwängen,
eingeführt
durch ein festes Nachrichtenprotokoll oder eine bestimmte Kombination von
Hardware und Software, geliefert durch einen gegebenen Hersteller.
-
Durch
die Verwendung von Managed Objects gestattet es die vorliegende
Erfindung den Diensten und Funktionen auch flexibel ("wo du es möchtest") und dynamisch ("direkt") quer über das Netzwerk
verteilt zu werden, basierend auf einer beliebigen Anzahl von Faktoren,
wie Kapazität
und Verwendung. Die Leistung wird verbessert, da die Dienstverarbeitung 22 (1),
die Rufverarbeitung 24 (1) und die
Einrichtungsverarbeitung 26 (1) auf einer
homogenen Plattform arbeiten. Zusätzlich erlaubt die vorliegende
Erfindung die Überwachung
und Manipulation von Rufunterelementen, auf welche zuvor nicht zugegriffen
werden konnte. Die vorliegende Erfindung erlaubt es außerdem Netzwerkoperator
die Verwendung von Funktionen oder Diensten zu überwachen, so dass sie gelöscht werden
können,
wenn sie veraltet oder unbenutzt sind.
-
Der
Ressourcenkomplex ("RC") 180 (1) ist
eine Ansammlung von physikalischen Geräten oder Ressourcen, welche
bereitstellen Träger-,
Signalisierungs- und Verbindungsdienste. Der RC 180, welcher
intelligente Peripheriegeräte 88 einschließen kann,
ersetzt die Vermittlungsstruktur 28 und 158 (1)
der IN- oder AIN- oder SSI/SF-Architektur. Im Gegensatz zu der IN-
oder AIN-Architektur ist die Steuerung des Ressourcenkomplexes,
wie dem RCA 206, auf einem niedrigeren Niveau. Außerdem kann der
RCA 206 mehr als eine Vermittlungsstruktur 158 enthalten.
Die Vermittlungsstrukturen 158 oder andere Kundenschnittstellen
(nicht gezeigt) verbinden zu mehreren Teilnehmern und Vermittlungsnetzwerken über Standardtelephonieverbindungen.
Diese Kundensysteme können
einschließen
ISDN Terminals 52, Faxgeräte 220, Telefone 54 und
PBX-Systeme 222. Der ICP 172 steuert und kommuniziert
mit dem RC 180 (1), dem RCA 206 und
dem RCB 208 mittels einer Hochgeschwindigkeitsdatenkommunikationsleitung
(minimale 100 Mb/sec Ethernetverbindung) 224. Die RC 180, 206 und 208 können mit
einem Drucker analogisiert sein und der ICP 172 kann mit
einem Personalcomputer analogisiert sein, wobei der Personalcomputer
einen Treiber zum Steuern des Druckers verwendet. Der "Treiber" in dem IDNA-Knoten 204 ist
ein Ressourcenkomplexproxy ("RCP") (nicht gezeigt),
welcher weiter unten mit Bezug auf 6 beschrieben
werden wird. Dieses erlaubt den Herstellern einen IDNA konformen
Knoten bereitzustellen, verwendend diese Schnittstelle, ohne dass
deren gesamte Software umgeschrieben werden muss, um die IDNA Modelle
zu inkorporieren.
-
Zusätzlich ist
die Steuerung des Ressourcenkomplexes 180 (1),
des RCA 206 und des RCB 208 auf einem geringeren
Niveau als typischerweise bereitgestellt durch die AIN- oder IN-Architektur.
Im Ergebnis müssen
die Ressourcenkomplexhersteller nur eine einzige Schnittstelle bereitstellen,
um die Einrichtungs- und Netzwerkmanagementverarbeitung zu unterstützen; sie
müssen
den Netzwerkbesitzer nicht mit einer spezifischen Ruf- und Dienstverarbeitung
ausstatten. Eine Geringniveauschnittstelle wird aufgeteilt in diskretere
Betriebsarten. Durch das Besitzen nur einer einzigen Schnittstelle wird
es dem Netzwerkbesitzer gestattet, aus einem weiten Spektrum von
Ressourcenkomplexherstellern auszuwählen, wobei die Entscheidungen
auf Preis und Leistung basieren. Eine Intelligenz wird zu dem ICP 172 hinzugefügt, entgegen
dem RC 180, was den RC 180 von Änderungen
isoliert und seine Komplexität
reduziert. Da die Rolle des RC 180 vereinfacht wird, werden Änderungen
leichter durchgeführt, was
es leichter macht, zu alternativen Vermittlungen und Übertragungstechnologien
zu wechseln, solchen wie asynchroner Transfermodus ("ATM").
-
Intelligente
Peripheriegeräte
("IP") 88 bieten die
Möglichkeit,
zu verarbeiten und auf Information zu reagieren, enthalten innerhalb
des tatsächlichen
Rufübertragungsweges.
Die IP's 88 befinden
sich allgemein in einem separaten Ressourcenkomplex, wie dem RCB 208,
und werden gesteuert durch die ICP's 172 in ähnlicher Weise wie der RCA 206.
Die IP's 88 können die
Möglichkeit
bereitstellen, Daten auf dem tatsächlichen Rufübertragungsweg
in Echtzeit, verwendend eine digitale Signalverarbeitung ("DSP")-Technologie, zu
verarbeiten.
-
Das
Netzwerkmanagementsystem ("NMS") 212 wird
verwendet, um die Hardware und die Dienste in dem IDNA Netzwerk 200 zu überwachen
und zu steuern. Eine vorgeschlagene NMS 212 Implementierung
könnte
sein ein Telekommunikationsmanagementnetzwerk ("TMN")-konformes
System, welches das Management der Komponenten innerhalb des ID-NA Netzwerkes 200 bereitstellt.
Spezifischer steuert das NMS 212 die Anwendung der Dienste,
erhält die
Gesundheit dieser Dienste aufrecht, stellt Informationen über diese
Dienste bereit und stellt eine Netzwerkniveaumanagementfunktion
für das
IDNA Netzwerk 200 bereit. Das NMS 212 greift zu
und steuert die Dienste und Hardware durch eine Agentenfunktionalität innerhalb
der INDA-Knoten 204. Der ICP-NMS-Agent (nicht gezeigt)
führt innerhalb
des IDNA-Knotens 204 die Befehle oder Anfragen, gestellt
durch das NMS 212, aus. Das NMS 212 kann die RCA 206 und
RCB 208 durch eine Standardbetriebsverbindung 226 direkt überwachen
und steuern.
-
Die
Managed Objects – Erzeugungsumgebung
("MOCE") 228 enthält die Unterkomponenten, um
Dienste zu erzeugen, welche in dem IDNA Netzwerk 200 laufen.
Ein dienstunabhängiger
Gebäudeblock
bzw. Service Independent Building Block ("SIBB")
und API Repräsentationen,
welche ein Dienstdesigner verwendet, um neue Dienste zu erzeugen,
sind innerhalb der MO-CE's primären Unterkomponente,
einer graphischen Benutzerschnittstelle bzw. Graphical User Interface
("GUI"), eingebettet. Die
MOCE 228 ist eine vereinheitlichte Sammlung von Werkzeugen,
vorhanden in einer einzigen Benutzerumgebung oder Plattform. Sie
repräsentiert
die Sammlung von Betriebsarten, welche gefordert werden durch den
Prozess der Diensterzeugung, wie z. B. die Dienstdokumentation,
die Managed Objects – Definition,
die Schnittstellendefinition, die Protokolldefinition und die Dateneingabedefinition,
welche verpackt sind in Managed Objects, und die Diensttestung.
Der Netzwerkbesitzer muss einen Dienst nur einmal entwickeln, verwendend
die MOCE 228, da die Managed Objects auf alle Knoten in
seinem Netzwerk angewendet werden können. Dieses steht im Gegensatz
zu dem Netzwerkbesitzer, bei denen jeder der verschiedenen Vermittlungshersteller
seine eigene Version des Dienstes entwickelt, was bedeutet, dass
der Dienst mehrfach entwickelt werden muss.
-
Die
MOCE 228 und das NMS 212 sind miteinander verbunden über einen
Speicher bzw. Repository 230. Der Speicher 230 enthält die Managed Objects,
welche durch das NMS 212 verteilt sind und in den IDNA-Knoten 204 verwendet
werden. Der Speicher 230 stellt ebenfalls einen Puffer
zwischen der MOCE 228 und dem NMS 212 bereit.
Die MOCE 228 kann jedoch direkt mit dem NMS 212 verbunden sein,
um ein "live" – Netzwerktesten zu leisten,
was durch die gestrichelte Leitung 232 angezeigt wird.
-
Nun
bezugnehmend auf 6 wird ein logisches und funktionales
Diagramm eines Telekommunikationssystems, anwendend eine intelligente
verteilte Netzwerkarchitektur 200 in Übereinstimmung mit der vorliegenden
Erfindung beschrieben werden. Der ICP 172 wird gezeigt,
einen ICP-NMS Agenten 240 und eine Dienstebenenausführungsumgebung bzw.
-
Service
Layer Execution Environment ("SLEE") 242 zu
enthalten, welche wiederum eine Vielzahl von Managed Objects 246, 248, 250 und 252,
abgeleitet von der Managed Objects – Basisklasse (244),
beherbergen.
-
Allgemein
stellen Managed Objects ein Verfahren zum Packen von Softwarefunktionen
dar, worin jedes Managed Object sowohl funktionale als auch Managementschnittstellen
anbieten, um die Funktionen des Managed Object zu implementieren. Die
Managementschnittstelle steuert den Zugang bezüglich wer und was auf die Managed
Object – Funktionen
zugreifen kann. In der vorliegenden Erfindung wird die gesamte Telephonieanwendungssoftware, außer der
Infrastruktursoftware, betrieben durch den IDNA Knoten 204,
als Managed Objects und Unterstützungsbibliotheken
verwendet. Dies schafft eine gleichartige Schnittstelle und Implementierung,
um die IDNA Knotensoftware zu steuern und zu managen.
-
Die
Sammlung der Netzwerkelemente, welche den Trägerverkehr, ausgeführt durch
den Knoten, verbinden, muten und beenden, wird gemeinschaftlich
benannt werden als der Ressourcenkomplex ("RC") 180.
Die Dienstverarbeitungsanwendungen, laufend auf der SLEE, verwenden
den Ressourcen-Proxy ("RCP") 244 als
eine Steuerschnittstelle an den RC 180. Der RCP 244 kann
verbunden werden an einen Gerätetreiber,
indem er ausrüstungsunabhängige Befehle
von Objekten in der SLEE an ausrüstungsspezifische
Befehle, die von dem RC 180 auszuführen sind, adaptiert. Der RCP 244 kann
beschrieben werden als eine Schnittstellenimplementierung der Basisbefehle,
allgemein bekannt unter den Verkäufern
der Ressourcen in dem RCP 244. Der RCP 244 könnte implementiert
werden, wie gezeigt, als ein oder mehrere Managed Objects, laufend
in dem IDNA Knoten 204. Alternativ könnte diese Funktion als ein
Teil des RC 180 bereitgestellt werden. Das NMS 212,
der Speicher 230 und die MO-CE 228 sind konsistent mit
der Beschreibung dieser Elemente in der Diskussion der 5.
-
Beachte,
dass die Betriebsverbindung 226 das NMS 212 mit
dem RC 180 direkt verbindet. Dies korrespondiert mehr mit
der traditionellen Rolle eines Netzwerkmanagementsystems bei der Überwachung des
Betriebsstatus der Netzwerkhardware. Dieses kann unabhängig von
der IDNA-Architektur durchgeführt
werden (z. B. unter Verwendung des gut bekannten TMN-Ansatzes). Zusätzlich kann
der RC 180 mit anderen Ressourcenkomplexen 254 verbunden
werden. Eine direkte Signalisierungsverbindung 214 wird
ebenso gezeigt, eintretend in den ICP 172, so dass die
Signalisierung 216, z. B. eine SS 7, direkt in die Rufverarbeitungsumgebung
eintreten kann. Durch Unterbrechung der Signalisierung an der Netzwerkperipherie kann
die SS 7 Nachricht direkt zu dem ICP 172 gehen, ohne durch
den RC 180 zu gehen. Dies reduziert die Wartezeit und verbessert
die Stabilität
durch Kürzung
des Signalweges. Eine begleitende Trägerverbindung 218 ist
mit dem RC 180 verbundern.
-
7 zeigt
den Ebenenaufbau der funktionellen Schnittstellen innerhalb des
ICP 172. Die MOCE 228 ist das System, wo die Managed
Objects – Software
und ihre Abhängigkeiten
erzeugt werden. Das NMS 212 steuert die Ausführung an
dem ICP 172 durch Kopplung an eine Agentenfunktion, bereitgestellt
innerhalb des ICP 172, bezeichnet als ICP-NMS-Agent 240.
Das NMS 212 steuert den Betrieb des lokalen Betriebssystems
("LOS") 260 an dem
ICP 172. Das NMS 212 steuert den Betrieb des ICP 172,
einschließlich
des Startens und Stoppens von Prozessen, Abfragen der Inhalte der
Prozesstabelle und des Status der Prozesse, des Konfigurierens der
Betriebssystemparameter und des Überwachens
der Leistung des Mehrzweckcomputersystems, welches den ICP 172 beherbergt.
-
Das
NMS 212 steuert ebenso den Betrieb des Weitverkehrsnetzwerkbetriebssystems
("WANOS") 262. Das
NMS 212 steuert die Initialisierung und den Betrieb der
WANOS-Unterstützungsprozesse
und die Konfiguration der WANOS-Bibliotheken über seine Steuerung des LOS 260 und
beliebiger anderer Schnittstellen, bereitgestellt durch die NMS SLEE-Steuerung. Das NMS 212 steuert
die Instantiierung und den Betrieb eines oder mehrerer SLEE's 242, laufend
auf dem ICP 172. Das LOS 260 ist ein kommerzielles
Standardbetriebssystem zum Betreiben des Mehrzweckcomputers. Das
WANOS 262 ist ein kommerzielles Standardintegrationsplattform- bzw. – middleware – softwarepaket
(z. B. ein Objektanforderungsvermittler), welches eine nahtlose Kommunikation
zwischen Rechenknoten ermöglicht. Die
SLEE 242 beherbergt die Ausführung der Managed Objects 244,
welche Softwareinstanzen darstellen, die die Dienstverarbeitungsarchitektur
implementieren. Die SLEE 242 implementiert die Mittel zur Steuerung
der Ausführung
der Managed Objects 244 durch den ICP-NMS-Agent 240. Daher ist eine
SLEE 242-Instanz ein Softwareprozess, welcher in der Lage ist, Managed
Objects – Software
anzuwenden und zu entfernen, Managed Objects – Instanzen zu instantiieren
und zu zerstören,
die Interaktion und Zusammenarbeit von Managed Objects zu unterstützen, den
Zugang zu nativen Bibliotheken 264 zu verwalten und mit
den NMS-ICP-Agenten 240 bei
der Implementierung der geforderten Steuerungen zu koppeln.
-
Die
nativen Bibliotheken 264 sind Bibliotheken, welche codiert
sind, um nur von dem LOS 260 oder dem WANOS 262 und
der nativen Mehrzweckcomputerausführung (z. B. kompi lierte C-Bibliotheken)
abzuhängen.
Sie werden hauptsächlich
verwendet, um die native Funktionalität, bereitgestellt durch die
SLEE 242, zu ergänzen.
-
Die
SLEE-Bibliotheken 266 sind codierte Bibliotheken, um in
der SLEE 242 ausgeführt
zu werden. Sie können
auf die Funktionen zugreifen, bereitgestellt durch die SLEE 242 und
die nativen Bibliotheken 264. Die Managed Objects 244 sind
die Software, geladen und ausgeführt
durch die SLEE 242. Sie können auf die Funktionalität zugreifen,
bereitgestellt durch die SLEE 242 und die SLEE-Bibliotheken 266 (und
möglicherweise
die nativen Bibliotheken 264).
-
Der
ICP-NMS-Agent 240 versorgt das NMS 212 mit der
Möglichkeit
zur Steuerung des Betriebes des ICP 172. Der ICP-NMS-Agent 240 implementiert die
Möglichkeit
zur Steuerung des Betriebes und der Konfiguration der LOS 260,
des Betriebes und der Konfiguration des WANOS 262 und der
Realisierung und des Betriebes der SLEE(S) 242. Die vorgeschlagene
Dienstverarbeitungsarchitektur arbeitet in Ebenen mit sich erhöhender Abstraktion.
Ausgehend von der Perspektive der SLEE 242 gibt es jedoch
nur zwei Ebenen: die Managed Objects – Ebene 244, welche
eine Ebene von Objekten ist (Softwareinstanzen), welche unter der
Steuerung des NMS 212 interagieren, und die Bibliotheksebene 264 oder 266,
welche eine Softwareebene ist (entweder nativ zu der SLEE 242 oder
zu dem LOS 260), welche Ergänzungsfunktionen zu dem Betrieb
der Managed Objects 242 oder der SLEE 242 selbst
hinzufügt.
Es wird jedoch erwartet, dass an einem gewissen Punkt das NMS 212 die
Steuerung des exakten Ortes der Managed Objects – Instanzen loslassen kann.
Z. B. wird den Managed Objects – Instanzen
gestattet, von einem Knoten zu einem anderen zu migrieren, basierend
auf einem oder mehreren Algorithmen oder Ereignissen, z. B. als
Antwort auf eine Anforderung.
-
8 zeigt
die Verschachtelung der Verarbeitungszusammenhänge innerhalb eines ICP 172, so
dass die SLEE 242 innerhalb einer virtuellen Maschine 270 implementiert
wird. Eine virtuelle Maschine 270 wird gestartet als ein
Verfahren bzw. Prozess innerhalb eines LOS 260 in einem
ICP 172. Dann wird der SLEE-Managementcode geladen und
ausgeführt
als das Hauptprogramm 272 durch den VM-Prozess 270.
Der SLEE-Managementcode, ausgeführt
als das Hauptprogramm 272, verbindet zu der ICP-NMS-Agent
240-Funktionalität
und überwacht die
Erzeugung und Zerstörung
von Managed Objects – Instanzen 274 von
der Klassentabelle 276. Z.B. Managed Object X, welches
sich in der Klassentabelle 276 befindet, das mehrere Instanzen
aufweisen kann, wird beschrieben werden, wobei jedes Managed Object
X danach nach Bedarf X1, X2 und
X3, entweder unter NMS-Steuerung oder während des
Verlaufes der Verarbeitung von Diensten, angefragt durch Teilnehmer,
instantiiert wird. Die Verwendung einer virtuellen Maschine 270 trägt Implikationen
sowohl zur Diensterzeugung als auch Dienstlogikausführung.
-
Die
IN- und AIN-Architekturen drehen sich um Dienste, welche als Zustandstabellen
codiert sind. Diese Zustandstabellenbeschreibungen werden durch
eine fest programmierte Zustandsmaschine interpretiert, welche die
codierte Dienstfunktion ausführt.
Im Ergebnis sind die MOCE 228 und der Dienstlogikinterpreter
("SLI") sehr von einander
abhängig
und stellen nur eine festgelegte Palette von Funktionen bereit.
Wenn ein gewünschter
neuer Dienst eine Zugabe einer neuen Gebäudeblockfunktion erfordert,
müssen
sowohl die MOCE 228 als auch der SLI verändert, rekompiliert,
durchgetestet und in einem koordinierten Modus angewendet werden.
In einer IN- oder AIN-Architektur erfordert die Anwendung eines
neuen SLI-Codes
eine kurze Auszeit innerhalb des Netzwerkes. Im Gegensatz dazu stellt
die vorliegende Erfindung eine mehrfache simultane Architektur bereit,
welche es erlaubt, neuen und alten SLI's zu koexistieren.
-
Die
vorliegende Erfindung verwendet eine virtuelle Maschine 270 um
diese Nachteile zu überwinden.
Eine virtuelle Maschine 270 ist ein funktionales Äquivalent
eines Computers, programmierbar auf einem derart elementaren Funktionsniveau
(d. h., logische Operatoren, Variablen, bedingte Jumper usw.), das
ein beherbergtes Programm eine beliebige vorstellbare logische Funktion
grundsätzlich
ausüben
kann, selbst jene, welche nicht ganz ausgeführt werden wie bei einem Endzustandmodell.
Die Universalität
einer virtuellen Maschine 270 ist besonders nützlich in
dieser Anwendung zum Gestatten der Ausführung einer Rufverarbeitungslogik
in Formen, welche bezüglich
einer Zustandstabelle bevorzugt sein können. Dieses unterscheidet
sich von einem logischen Interpreter, welcher typischerweise Funktionen
mit höherem
Niveau unterstützt
und ist in Programmsemantiken und in der Flexibilität der Ausführung beschränkt. In
den IN- und AIN-Architekturen unterstützt der SLI eine begrenzte
Struktur und einen begrenzten Satz von Funktionen.
-
Wenn
die virtuellen Maschine 270-Software auf einem Mehrzweckcomputer
läuft,
kann die virtuelle Maschine 270 als eine Adapterebene betrachtet werden.
Der Code, welcher als ein Programm innerhalb der virtuellen Maschine 270 läuft, kann
dieselbe Granularität
der Steuerung und des Zugriffs auf Input/Output und der Speicherung
aufweisen, als ob er direkt auf dem Prozessor laufen würde, sogar
kann exakt das selbe Programm übertragbar
auf eine völlig verschiedene
Prozessorhardware, auf welcher eine äquivalente virtuelle Maschinenumgebung
läuft (d.
h. betrieblich in heterogenen Umgebungen), übertragen werden.
-
In
einer bevorzugten Ausführungsform
ist die "Java"-Plattform, entwickelt
von Sun Microsystems zum Ausführen
aller Telephonieanwendungssoftware vorgeschrieben. Die Verbreitung
von Java verleiht praktische Vorteile bei der Plattformübertragbarkeit, Ubiquität der Entwicklungswerkzeuge
und Fertigkeitssätze
sowie den existierenden Unterstützungsprotokollen,
wie ftp und http. Java bringt eine objektorientierte Programmierung
in einen ähnlichen
Modus zu C++. Der SLEE-Managementcode 272 und alle Managed
Objects 276, angegeben in der SLEE 242, sind als
Java Bytecodes codiert. Der SLEE-Managementcode 272 schließt Funktionen
zum Installieren, Entfernen und zum Instantiieren von Klassen, zum
Abfragen und Entfernen von Instanzen und zum Bestätigen globaler
Werte und Lauf-/Stopp-Status ein.
-
Trotz
der vorangegangenen Vorteile scheint die Verwendung einer virtuellen
Maschine als eine SLEE 242, insbesondere einer Java virtuellen
Maschine, von IN- und AIN-Architekten übersehen worden zu sein. Vielleicht
voreingenommen durch die bekannteren Telephonieanwendungen, wie
interaktive Spracherkennung, haben die IN- und AIN-Designer gedacht,
dass eine fest eingestellte Palette von Funktionen adäquat und
bevorzugt wegen ihrer offensichtlichen Einfachheit und Ähnlichkeit.
zu traditionellen Rufverarbeitungsmodellen ist. Während der AIN-Ansatz
die Geschwindigkeit der Diensterzeugung nur innerhalb eines festgelegten
Rufmodells und Funktionensatzes verbessert, kann die vorliegende
Erfindung so einfach das gesamte implizite Dienstframework entfalten,
um neue Dienstanforderungen und neue Rufverarbeitungsparadigmen
zu ermöglichen.
-
Die
Wahl einer objektorientierten SLEE 242 führt zu vielen
Schlüsselvorteilen,
einschließlich
eines Abhängigkeitsmanagements
und geteilter Sicherheit unter koinstantiierten Objekten. Die beworbenen
Vorteile einer objektorientierten Programmierung, wie Modularität, Polymorphie
und Wiederverwendung, werden in der SLEE 242 realisiert,
in Übereinstimmung
mit der vorliegenden Erfindung. Wegen der Managed Objects – Vererbungshierarchie
können
weit verbreitete Änderungen
im Rufmodell, Protokoll oder einigen anderen Aspekten der Rufverarbeitung
durch relativ örtliche
Codeänderungen,
z. B., an einer einzigen Basisklasse, berührt sein. Ein anderer bedeutender
Vorteil ist, dass die codierten Klassen, von welchen Objekte realisiert
werden innerhalb jeder SLEE 242, aktualisiert werden können, ohne
die SLEE 242 auszuschalten oder erneut hochzufahren.
-
In
einer bevorzugten Ausführungsform
kann ein Satz von Betriebsregeln verschlüsselt sein, um die Anwendung
eines neuen klassenimplementierten Codes auf die SLEE 242 oder
die Instantiierung der Objekte davon, basierend auf einer physikalischen Örtlichkeit
oder Betriebszuständen,
zu gestatten oder zu beschränken.
Diese Regeln können
an verschiedenen Orten codiert werden, wie dem Teil des Managed
Objects – Bildes,
das das NMS 212 verwendet für eine Anwendung, oder hinein
in den tatsächlichen Objektcode,
welcher durch die SLEE 242 aktiviert wird. In jedem Fall
würde das
NMS 212 Fehlerbehandlungsprozeduren aufweisen, wenn die
Instantiierung missglückt.
Gebietsbeschränkungen
könnten beliebige
Mittel zur Charakterisierung der physikalischen Örtlichkeit des Knotens (z.
B. Nation, Staat, Stadt, Straßenadresse
oder globale Koordinaten) sein.
-
Zusätzlich kann
ein Verfahren zur Konfliktlösung
zwischen den Betriebsregeln innerhalb des Satzes angenommen werden.
Z. B., wenn ein spezifisches Objekt am Knoten X instantiiert werden
muss, welcher sowohl in Region A und Region B liegt, und der Satz
von Betriebsregeln führt
dazu, dass die Instantiierung des spezifischen Objekts verboten
ist in Region A, aber erlaubt ist in Region B, bildet sich ein Konflikt
darüber,
ob oder ob nicht das spezifische Objekt an dem Knoten X instantiiert
werden kann. Wenn jedoch eine Konfliktlösungsregel einfach dazu führt, dass
Objekte nur instantiiert werden können, wo sie erlaubt sind,
wird der Konflikt gelöst
und das spezifische Objekt nicht an dem Knoten X instantiiert. Dieser
Satz von Betriebsregeln könnte
verwendet werden, die Anwendung oder Instantiierung eines Trunkmanagementklassencodes
auf Situationen zu beschränken,
wo der intelligente Rufprozessor tatsächlich Trunk-Ressourcen verwaltet.
Diese Regeln könnten
ebenso verwendet werden, Zahlungsprozessorinstanzen zu beschränken, welche
zugeschnitten sind auf Zahlungsregulationen eines spezifischen Status
zu den Grenzen dieses Status. Wie zuvor erwähnt, können diese Ortsbeschränkungsregeln
intern oder extern zu dem Klassenobjekt sein.
-
Nun
bezugnehmend zu 9 wird die Klassenhierarchie
von Managed Objects in Übereinstimmung
mit einer bevorzugten Ausführungsform
der vorliegenden Erfindung beschrieben werden. Die abstrakten Basisklassen – Managed
Objects 244 beinhalten eine allgemeine Funktionalität und virtuelle Funktionen,
um sicherzustellen, dass alle abgeleiteten Klassen richtig als Objekte
in der SLEE 242 unterstützt
werden können.
Es werden vier verschiedene Unterklassen spezifischer gezeigt, die
Dienststeuerklasse 252, die Rufsteuerungsklasse 250, die
Trägersteuerungsklasse 248 und
die Ressourcen-Proxy-Klasse 246.
-
Die
Dienststeuerungsklasse 252 ist die Basisklasse für alle Dienstfunktionsobjekte.
Die Sitzungsmanagerklasse 280 verkapselt die sitzungsbezogenen
Informationen und Aktivitäten.
Eine Sitzung kann umfassen einen oder mehrere Rufe oder andere Aufrufe
von Netzwerkfunktionen. Die Sitzungsmanagerklasse 280 stellt
einen einzigen Identifizierer für jede
Sitzung bereit. Wenn eine Rufverarbeitung stattfindet in einem Knotenmodus,
dann muss die Zahlungsinformation gesammelt werden. Ein einziger Identifizierer
für jeden
Ruf macht die Sammlung leicht, anstelle einer geforderten teueren
Korrelationsverarbeitung. Bei der Dienstverarbeitung werden Protokolle
durch sukzessive Abstraktionsebenen übernommen. Schließlich ist
das Protokoll ausreichend abstrahiert, um die Anweisung/Instantiierung eines
Sitzungsmanagers zu garantieren (z. B. in einer SS 7, würde der
Empfang einer IAM-Nachricht garantieren, dass ein Sitzungsmanagement
besteht).
-
Die
Trägerpotentialklasse 282 ändert die Qualität des Dienstes
auf dem Träger.
Die Dienststeuerungsklasse 252 kann Änderungen in der Dienstqualität bzw. Quality-of-Service
("QoS") eines Rufes oder
selbst eine Änderung
des Trägerpotentials,
wie Ändern
von 56 Kbit/s zu höheren
Geschwindigkeit und dann wieder zurück, ermöglichen. Der QoS wird verwaltet
durch die Verbindungsmanagerklasse 302. Z. B. degradiert
eine Halbgeschwindigkeitsunterklasse 284 den QoS eines
Rufes auf eine 4 Khz-Samplerate, anstelle einer gewöhnlichen
8 Khz-Samplerate. Eine Stereounterklasse 286 dürfte einem
Benutzer erlauben, zwei Verbindungen in einem Ruf zu bilden, um
einen linken Kanal und einen rechten Kanal zu unterstützen.
-
Die
Dienstentscheidungsklasse 288 codifiziert die Vermittlung
von Dienstkonflikten und Dienstinteraktionen. Dieses ist erforderlich,
da sich Dienststeuerungsklassen 252 widersprechen können, im
Besonderen Entstehungs- und Beendigungsdienste. Aus vielen praktischen
Gründen
heraus ist es unerwünscht,
innerhalb jeder Dienststeuerungsklasse 252 eine Orientierung,
wie ein Konflikt mit jedem anderen Typ einer Dienststeuerungsklasse 252 zu
lösen ist,
zu codieren. Stattdessen werden, wenn ein Konflikt erkannt wird,
Referenzen zu den konfliktauslösenden
Diensten und ihren anhängenden
Anfragen zu der Dienstentscheidungsklasse 288 geleitet.
Die Dienstentscheidungsklasse 288 kann dann den geeigneten
Weg der Aktion entscheiden, gegebenenfalls einen lokalen Kontext,
Konfigurationsdaten und nachfolgende Anfragen nach den konfliktauslösenden Dienstobjekten
in Betracht ziehend. Das Bestehen einer Dienstentscheidungsklasse 288 erlaubt
explizit eine Dokumentation und Codierung von konfliktauflösenden Algorithmen,
entgegen entweder fest codierten oder impliziten Mechanismen. Darüber hinaus
müssen,
wenn ein Dienst aktualisiert oder hinzugefügt wird, die existierenden
Dienste nicht aktualisiert werden, um beliebige Konfliktänderungen
zu berücksichtigen,
welche die Änderung
von vielen Beziehungen innerhalb eines einzigen Diensts erfordern
können.
-
Die
Merkmalsklasse 290 implementiert den Standardsatz von Möglichkeiten,
verbunden mit Telephonie (z. B. Drei-Wegeanrufen, Rufwarteschleife). Eine
solche Möglichkeit
kann eine Beeinflussung 292 sein, um eine Veranlassung
zu ermöglichen,
um einen existierenden Ruf zu trennen, um einen beabsichtigen Empfänger zu
erreichen. Eine andere gewöhnliche
Möglichkeit
kann einschließen
einen Rufblock 294, wodurch ein Veranlassungsangebot zurückgewiesen
werden kann, basierend auf einem Satz von Kriterien bezüglich der
Veranlassung.
-
Die
Dienstdiskriminationsklasse 296 wird verwendet, um andere
Dienste selektiv aufzurufen während
einer Rufverarbeitung, und wird selbst als ein Dienst unterklassifiziert.
Die Dienstdiskriminationsklasse 296 führt zu einer flexiblen, kontextsensitiven
Dienstaktivierung und umgeht die Notwendigkeit einen festgelegten
Code innerhalb jedes Dienstobjektes zur Bestimmung zu haben, wann
der Dienst zu aktivieren ist. Die Aktivierungssequenz wird von dem Dienst
selbst isoliert. Z. B. haben der Teilnehmer A und der Teilnehmer
B Zugang zu demselben Satz von Merkmalen. Der Teilnehmer A wählt aus,
um selektiv einen oder mehrere von seinen Diensten, verwendend einen
besonderen Satz von Signalen, anzuwählen. Der Teilnehmer B bevorzugt,
einen verschiedenen Satz von Signalen zu verwenden, um seine Dienste
zu aktivieren. Der einzige Unterschied zwischen den Teilnehmern
ist die Art mit der sie ihre Dienste aktivieren. So ist es wünschenswert,
den Auswahlprozess von dem Dienst selbst abzuteilen. Es gibt zwei
mögliche
Lösungen.
Der Dienstauswahlprozess für
die Teilnehmer A und B kann eine separate Dienstdiskriminationsklasse 296 codieren
oder eine Dienstdiskriminationsklasse 296 kann ein Profil pro
Teilnehmer verwenden, um die geeignete Information anzuzeigen. Dieses
kann verallgemeinert werden, um bei mehreren Benutzern angewendet
zu werden, deren Dienstsätze
getrennt sind. Darüber
hinaus kann die Verwendung einer Dienstdiskriminationsklasse 296 die
Zuordnung des Zugangs zu Diensten, basierend auf dem Zusammenhang
oder Fortschritt eines gegebenen Anrufes, ändern. Die Implementierung
dieser Klasse erlaubt verschiedenen Anrufbeteiligten, verschiedene
Dienste, verwendend gegebenenfalls verschiedene Aktivierungsinputs,
zu aktivieren. Im Stand der Tech nik lieferten alle Vermittlungsverkäufer unflexible
Dienstauswahlschemata, welche diese Möglichkeit verhinderten.
-
Die
medienunabhängige
Dienstklasse 298 ist eine Art von Dienststeuerungsklasse 252,
wie ein Speicherverfahren bzw. Store-and-Forward 300, Rundfunk,
Umleitung, Bevorrechtigung, QoS und Mehrparteienverbindungen, welche
auf verschiedene Mediatypen angewendet wird, einschließlich Stimme,
Fax, Email und andere. Wenn eine Dienststeuerungsklasse 252 entwickelt
ist, kann diese auf jeden Mediatyp angewendet werden, dann kann
die Dienststeuerungsklasse 252 in wiederverwendbare Dienststeuerungsklassen 252 aufgebrochen
werden. Wenn die Dienststeuerungsklasse 252 in medienabhängige Funktionen
und eine medienunabhängige
Funktion aufgebrochen wird (d. h. eine medienunabhängige SC,
welche implementiert einen Dienst und einen Satz medienabhängiger Pack-SC's – einen
pro Medientyp), wie abgeleitet von der medienunabhängigen Klasse 298,
stellt das Speicherverfahren 300 die generische Möglichkeit
bereit, eine Nachricht oder einen Datenstrom eines gewissen Medientyps
zu speichern, und dann die Möglichkeit
diese später
auszuliefern, basierend auf einem gewissen Ereignis. Die Umleitung
stellt die Möglichkeit
bereit eine Verbindung von einer logischen Adresse zu einer anderen zu
bewegen, basierend auf spezifizierten Bedingungen. Dieses Konzept
ist die Basis für
die Rufweiterleitung (alle Typen), ACD/UCD, WATS (1-800-Dienste), Finde-mich/Folge-mir
und mobiles Roaming usw. Die Bevorrechtigung, entweder verhandelt
oder anderes, beinhaltet Dienste, wie Anruf halten, Prioritätssteuerung
usw. QoS modulierte Verbindungen implementieren Zukunftsdienste über Paketnetzwerke,
wie z. B. Stimme/Fax, Videoübertragung
und Datenübertragung.
Die Mehrparteienverbindungen schließen Drei-Weg- und N-Weg-Videokonferenzen
usw. ein. Obwohl eine Benutzersteuerung und Eingabe grundsätzlich implementiert
ist, verwendend die Tasten auf einem Telephon, wird erwartet, dass
eine Stimmerkennung zur Benutzersteuerung und Eingabe in der Zukunft
verwendet wird.
-
Die
Verbindungsmanagerklasse 302 ist verantwortlich für die Koordinierung
und Entscheidung bzw. Arbitration von Verbindungen der verschiedenen
Trägersteuerungen 248,
involviert in einen Ruf. Die Komplexität der Verwaltung der Anschlussfähigkeit
zwischen Parteien in Mehrfachrufen wird daher eingekapselt und von
allen anderen Diensten entfernt. Die Dienst- und Rufverarbeitung
sind von den Verbindungen entkoppelt. Dieses bricht das Paradigma
der zugeordneten Rufe zu Verbindungen von eins zu mehreren. Nun
ist die Zuordnung von Rufen zu Rufen viele zu viele.
-
Die
Verbindungsmanagerklassen 302 sind innerhalb einer Architektur
gebildet, um alleinstehend zu arbeiten oder als gleichrangig zusammenzuarbeiten.
Im Betrieb bieten die Dienststeuerungsklassen 252 die Verbindungsmanagerklassen 302 auf
Anfrage an, Rufsegmente hinzuzufügen,
zu modifizieren und zu entfernen. Es liegt in der Verantwortlichkeit der
Verbindungsmanagerklasse 302 diese Änderungen durchzuführen. Beachte:
Da Verbindungen entweder als Ressourcen zu und für sich selbst oder als Attribute
von Ressourcen betrachtet werden können, kann eine Verbindungsmanagerklasse 302 implementiert
werden als ein Proxy oder ein Aspekt von Basisressourcenmanagementfunktionen.
-
Die
Rufsteuerungsklasse 250 implementiert eine essentielle
Rufverarbeitung, wie z. B. die Basis-Endzustandsmaschine, gewöhnlich verwendet für Telephonie,
und spezifiziert, wie eine Rufverarbeitung stattzufinden hat. Zwei
Klassen können
davon abgeleitet werden, die funktionale Trennung der Entstehung
(Platzierung eines Rufes) 304 und der Beendigung (Annehmen
eines Rufes) 306.
-
Die
Trägersteuerungsklasse 248 ist
auf ein Adaptieren spezifischer Signale und Ereignisse zum und weg
vom Ressourcenkomplex 180 gerichtet, mittels des Ressourcen-Proxy 246,
in gewöhnliche
Signale und Ereignisse, welche durch die Rufsteuerungobjekte 250 verstanden
werden können.
Eine vorweggenommene Rolle eines Objektes, abgeleitet von dieser
Klasse, ist Informationen über
das Entstehungsende eines Rufes, wie eine Teilnehmerzeilennummer,
Dienstklasse, Zugangstyp usw., zu sammeln. Die Unterklassen können sich
auf der Basis der Nummer der Schaltungen oder Kanäle, assoziiert
mit der Signalisierung, unterscheiden. Diese können eine kanalassoziierte
Klasse 308 einschließen,
wie dies zutrifft auf einen einzigen Signalisierungskanal pro 23
Trägerkanälen in eine
ISDN-Hauptschnittstelle 310, eine Kanaleinzelklasse 312,
wie typisiert durch ein analoges Telephon 314, welches
ein Wählen
zum Steuern einer einzigen Schaltung verwendet, und die Kanalallgemeinklasse 316,
dargestellt durch eine SS 7 – Signalisierung 318,
vollständig
abgetrennt von den Trägerkanälen.
-
Die
Ressourcenproxyklasse 246 ist vorgesehen, die Ausführungsumgebung
mit den Realwelt-Vermittlungen
und anderen Elementen in dem Trägernetzwerk
zu verbinden. Beispiele für
interne Zustände,
implementiert auf diesem Niveau und vererbt von allen davon abstammenden
Klassen, eingeschaltete Dienste versus ausgeschaltete Dienste und frei
versus in Benutzung. In Betracht gezogene abgeleitete Klassen sind
Telephon 320 (ein Standard-Proxy für einen Standard 2500 Satz),
Spracherwiderungseinheiten ("VRUs") 322 (ein
Standard-Proxy für Spracherwiderungseinheiten),
IMT-Trunk- bzw. -Stamm- Verbindungen 324 (ein Standard-Proxy
für digitale
Trunk-(T1/E1)-Schaltungen) und Modemverbindungen 326 (ein
Standard-Proxy für
digitale Modems), korrespondierend mit spezifischen Typen von Ressourcen
in dem Ressourcenkomplex 180.
-
Nun
Bezugnehmend auf 10 wird eine dynamische logische
Beziehung einiger instantiierter Objekte gezeigt werden. Ein Realwelt-Telephon
A 330 ist an eine Kette von Objekten in der SLEE 242 durch
einen Ressourcenkomplex-Proxy (nicht gezeigt) gekoppelt. Die RC_Phone
A 332 -, die BC_Phone A 334 – und die CC_Orig A 336 – Objekte verbleiben
zu jeder Zeit in der SLEE 242 instantiiert. Eine Zustandsänderung
und eine Benachrichtigung erscheint unter diesen Objekten so oft
das Realwelt-Telephon aufgelegt oder abgenommen wird oder wenn das
Tastenfeld gedrückt
wird. Ähnlich dazu
wird das Telephon B 338 in der SLEE 242 durch eine
Kette von RC_Phone B 340 -, BC_Phone B 342 – und CC_Term
B 344 – Objekte
dargestellt. Eine Instanz eines Rufblocks bzw. Call Block B 346 wird
einem CC_Term B 344 zugewiesen, Anzeigend, dass der Teilnehmer
B zuvor eine Ruflockierfunktion für das Telefon B 338 in
Kraft gesetzt hat.
-
Wenn
der Teilnehmer A abnimmt, empfängt das
RC_Phone A 332 eine Meldung und sendet diese an das BC_Phone
A 334, welches die Meldung an den Sitzungs- bzw. Session
Manager A 348 weitergibt, um die Sitzung zu starten. Der
Session Manager A 348 bestimmt algorithmisch die Standarddienststeuerungsklasse,
assoziiert mit dem Sitzungsstart (d. h., es wird nachgesehen in
der Konfiguration, spezifiziert als die Standardeinstellung des
RC_Phone A 332). Der Session Manager A 348 erkennt,
dass der Dienst- bzw. Service_Discriminator A 350 die Standarddienststeuerungsklasse
ist und ruft ihn an.
-
Der
Service-Discriminator A 350 weist das BC_Phone A 334 an,
genügend
Informationen zu sammeln, festzustellen, dass der Dienst ultimativ
aktiviert wurde (z. B., er veranlasst den Teilnehmer A den Dienstcode
und/oder Zielziffern zu wählen).
In diesem Beispiel bestimmt der Service Discriminator A 350,
ob der Teilnehmer A beabsichtigt, einen Speicherverfahrens- Store
And Forward – Dienst 352 (z. B.
ein Anrufboxmerkmal) oder einen Halb-Raten- bzw. Half-Rate – Anruf 354 (ein Dienst,
welcher die Trägerfähigkeit
einstellt; er reduziert die Bandbreite auf die Hälfte) oder eine Beeinflussung 356 (ein Dienst,
welcher einen Terminator anweist, eine Entstehung zu akzeptieren)
zu aktivieren.
-
Der
Teilnehmer A wählt
die Ziffern, um die Aktivierung einer Beeinflussung des Phone B 338 anzuzeigen.
Der Service_Discriminator 350 aktiviert das Beeinflussungsmerkmal 356.
Die Beeinflussungsdienststeuerung 356 sammelt genügend Informationen,
um festzustellen, ob der Teilnehmer A anrufen möchte. Die Beeinflussungsdienststeuerung 356 wählt die
Entstehungsrufsteuerung (CC_Orig A 336) an, um den Ruf über den
Verbindungs- bzw. Connection Manager A 358 anzubieten.
Der Connection Manager A 358 kontaktiert die Beendigungsrufsteuerung,
CC_Term B 344, welche den Call_Block Dienst B 346 kontaktiert,
welcher daraufhin aktiviert wird. Der Call Block Dienst 346 unterrichtet
den Connection_Manager A 358 durch den CC_Term B 344,
dass der Ruf zurückgewiesen
wurde. CC_Orig A 336 instruierte den Connection_Manager
A 358, eine Zurückweisung
nicht zu akzeptieren aufgrund der Beeinflussungsdienststeuerung 356.
Der Beeinflussungs 356 – und der Call Block 346 – Dienst
befinden sich nun im Konflikt.
-
Der
Connection_Manager 358 wählt den Dienstarbitrationsdienst 360,
mitteilend den Konflikt. Der Dienstarbitrationsdienst 360 bestimmt,
basierend auf der gegenwärtigen
Information, algorithmisch einen Gewinner (z. B., muss die Beendigungsrufsteuerung
den Ruf akzeptieren). CC_Term B 344 akzeptiert den Entstehungsversuch
und es wird eine geeignete Signalisierung an das BC_Phone B 342 und
das RC_Phone B 340 übermittelt.
Das Phone B 338 beginnt mit dem Klingeln und der Teilnehmer
B antwortet. Das resultierende Antwortereignis wird durch das CC_Term
B 344 über
alle Wege an das CC_Orig A 336 übermittelt. An diesem Punkt
wählt der
Connection_Manager A 358 den Redeweg und Teilnehmer A und
B sind im Gespräch.
Der Ruf ist nun in einem stabilen Zustand. Der Dienst- bzw. Servicemanager
A 348 zeichnet den erfolgreichen Abschluss des Rufes auf.
Nun warten sowohl die Rufkontrollen 336 und 344 auf
ein Beendigungssignal, welches den Ruf beenden wird. Der Teilnehmer
B hängt
ein. Die Nachricht wird übermittelt
an beide Rufsteuerungen 336 und 344. Die Rufsteuerungen 336 und 344 beenden
ihre Teilnahme in dem Ruf. Der Connection Manager A 358 baut
die Verbindung ab und der Session Manager 348 zeichnet
die Beendigung des Rufs auf. Der Teilnehmer A hängt ein und der Servicemanager 348 übermittelt
die Aufnahme des Rufes an das Bezahlungssystem. Wie Fachleute wissen
werden, können
Kompromisse eingegangen werden zwischen dem Wert der Flexibilität beim Instantiieren
von Objekten auf Anfrage und dem Leistungszuwachs der Instantiierung
und Verwaltung der Instanzen, bevor sie benötigt werden.
-
11 ist
ein Flussdiagramm der Verfahrensschritte für eine generische Rufverarbeitung
in Übereinstimmung
mit der vorliegenden Erfindung, wobei Interaktionen stattfinden
in einer Hochgeschwindigkeitsumgebung und eine Rufverarbeitungsintelligenz
von Beginn an eines gegebenen Rufes angewendet werden kann. Der
Kunde nimmt den Hörer
ab und beginnt im Block 370 zu wählen. Die Verbindungsbedingung
und jeder Satz gewählter
Ziffern erscheinen als inkrementierte Ereignisse innerhalb der ICP/SLEE über den
RCP oder alternativ als Signalisierung, direkt gesendet vom Zentralbüro zu dem
ICP über
eine direkte SS 7-Verbindung
im Block 372. Die Ressourcensteuerungs-, Trägersteuerungs- und
Rufsteuerungsinstanzen, assoziiert mit der Verbindung, antworten
auf jedes Ereignis und instantiieren Dienstobjekte, wenn benötigt im
Block 374. Die Dienstobjekte können weitere Interpretationen
auf nachfolgende Ereignisse anwenden und können andere Dienstobjekte instantiieren.
Die Interaktionen unter den Ressourcensteuerungs-, Trägersteuerungs-,
Rufsteuerungs- und Dienststeuerungsobjekten und beliebiger anderer
Datenbankressourcen treten innerhalb einer Hochgeschwindigkeitsumgebung auf.
Die Befehle zur Ressourcensteuerung, um einen Dienst zu implementieren,
werden durch den RCP organisiert und eine umfangreiche Aufzeichnung
der Rufaktivität
wird gespeichert oder unmittelbar für Bezahlungszwecke im Block 376 verarbeitet.
Eine einzelne Ruf- oder Sitzungsverarbeitung wird im Block 378 abgeschlossen.
-
12 veranschaulicht
die Verfahrensschritte für
eine generische Diensterzeugung, verwendend Managed Objects in Übereinstimmung
mit der vorliegenden Erfindung. Die Diensterzeugung, verwendend
Managed Objects findet vollständig
innerhalb der Netzwerkbesitzersteuerung statt, ist beträchtlich schneller
und wird innerhalb einer vereinheitlichten Umgebung, verwendend
einen festen Satz von Werkzeugen, geleistet. Eine neue Funktion
wird nachgefragt, beinhaltend einen neuen Dienst, einen neuen Rufzustand
und ein neues Protokoll, im Block 380. Der Netzwerkbesitzer
benutzt eigene Dienstdesigner oder Programmierer, um Managed Objects (Trägersteuerung,
Rufsteuerung und Dienststeuerung) zu modifizieren, wie benötigt, im
Block 382. Eine iterative Einheitstestung, verwendend neue
Versionen der Managed Objects in einer Test-SLEE, wird verifiziert,
durchgeführt;
bis die neue Funktion im Block 384 verifiziert wurde. Eine
Integrationstestung von neuen Versionen von Managed Objects in Verbindung
mit nur jenen anderen Objekten und Systemteilen, welche mit den
modifizierten Objekten interagieren, im Block 386. Das
NMS wird verwendet, um die neuen Managed Objects in den ICP's im Block 388 anzuwenden.
Eine Implementierung der neuen Funktion wird im Block 390 abgeschlossen.
-
13 veranschaulicht
die Verwendung ähnlicher
Werkzeuge während
einer Diensterzeugung, um kompatible Objekte für dieselbe Zielumgebung in Übereinstimmung
mit der vorliegenden Erfindung zu erzeugen. In der MOCE 228 verwenden
die Entwickler von verschiedenen Funktionalitätstypen (Kontext A 400,
Kontext B 402 und Kontext C 404) ähnliche
Werkzeuge (Werkzeug A 406 und Werkzeug B 408),
um kompatible Objekte (MO Typ 1 410, MO Typ 2 412 und
MO Typ 3 414) für
dieselbe Zielumgebung zu erzeugen. Die Palette (Palette A 416, Palette
B 418 und Palette C 420) für jedes Werkzeug (Werkzeug
A 406 und Werkzeug B 408) ist annähernd verschieden
für den
Entwicklungstyp. Jedes Managed Object (MO Typ 1 410, MO
Typ 2 412 und MO Typ 3 414) wird erzeugt durch
Kombinieren von Eingabe- bzw. Input-Daten (MO Typ 1 Input Form A 422,
MO Typ 2 Input Form A 424 und MO Typ 3 Input Form AD 426)
und Kontextinformationen (Kontextinfo A 428, Kontextinfo
B 430, Kontextinfo C 432), verwendend die Werkzeuge
(Werkzeug A 406 und Werkzeug B 408) und Paletten
(Palette A 416, Palette B 418 und Palette C 420).
Die Managed Objects (MO Typ 1 410, MO Typ 2 412 und
MO Typ 3 414) werden dann in dem Speicher 230 gespeichert.
-
14 veranschaulicht,
wie sich die Palette für
jedes Werkzeug in Erwiderung auf neue funktionale Stücke in Übereinstimmung
mit der vorliegenden Erfindung ändern
kann. Die Palette für
jedes Werkzeug kann sich in Erwiderung auf neue funktionale Stücke, eingeführt durch
andere Entwickler, ändern.
-
15 veranschaulicht
den Managed Objects – Erzeugungsumgebung-Verwendungsfluss. Der
Softwarekomponententyp wird ausgewählt im Block 450 und
die Konfiguration wird ausgewählt
im Block 452 und das geeignete Werkzeug wird in Block 454 eingeführt. Der
Benutzer kann auswählen
Werkzeug A 456, Werkzeug B 458 oder Werkzeug C 460. Als
Nächstes
werden die Ergebnisse im Block 462 gesammelt und die Konfiguration
wird im Block 464 aktualisiert.
-
16 veranschaulicht
den Managed Objects Erzeugungsumgebungssoftwarestapel. Die Basis
des Managed Object – Erzeugungsumgebungssoftwarestapel
ist die Entwicklungsinfrastruktur 470. Die Entwicklungsinfrastruktur 470 ist
verbunden mit der Softwarekonfigurationsdatenbank 472,
um relevante Informationen zum Erzeugen von Managed Objects zu lesen
und zu speichern. Der Benutzer erzeugt Managed Objects, verwendend
Softwareerzeugungswerkzeuge A 480, B 482 und C 484,
welche wiederum Werkzeugadapter A 474, B 476 und
C 478 verwenden, um mit der Entwicklungsinfrastruktur 470 zu
koppeln.
-
17 veranschaulicht,
wie die vereinheitlichte Ausführungsumgebung
auch die vereinfachte Erzeugung und Modifikation selbst der Werkzeuge, durch
welche die Entwickler Objekte für
die SLEE schaffen, vorsieht.
-
Einige
bevorzugte Ausführungsformen
wurden oben im Detail beschrieben. Es sollte verstanden sein, dass
der Umfang der Erfindung ebenso Ausführungen umfasst, welche sich
von diesen beschriebenen unterscheiden, jedoch innerhalb des Umfangs der
Ansprüche
sind.
-
Z.
B. wird ein Mehrzweckcomputer verstanden werden als Rechengerät, welches
nicht speziell für
eine Art von Anwendung hergestellt ist. Der Mehrzweckcomputer kann
ein beliebiges Rechengerät von
beliebiger Größe sein,
welches die Funktionen leisten kann, gefordert, die Erfindung zu
implementieren.
-
Ein
weiteres Beispiel ist, dass die "Java"-Programmiersprache
mit anderen äquivalenten Programmiersprachen,
welche ähnliche
Charakteristiken haben und ähnliche
Funktionen leisten werden, wie gefordert, ausgetauscht werden kann,
um die Erfindung zu implementieren.
-
Die
Verwendung dieser Begriffe sowie der anderen Begriffe führt nicht
dazu, die Erfindung allein auf diese Begriffe zu begrenzen. Die
verwendeten Begriffe können
mit anderen, welche synonym sind und/oder sich auf äquivalente
Dinge beziehen, ausgetauscht werden. Wortinklusionen sind zu interpretieren
als nicht erschöpfend
bei der Betrachtung des Umfangs der Erfindung. Es sollte ebenso
verstanden werden, dass verschiedene Ausführungsformen der Erfindung
in Hardware, Software oder mikrocodierter Firmware verkörpert sein
können
oder diese einsetzen können.