DE69929340T2

DE69929340T2 - Verfahren und system für eine intelligente, verteilte netzwerk-architektur

Info

Publication number: DE69929340T2
Application number: DE69929340T
Authority: DE
Inventors: Robert Piano BARNHOUSE; Doug Plano CARDY; Kelvin Dallas PORTER; Ken Allen RAMBO; Carol Allen WALLER; Wendy Dallas Wong; George Plano YAO
Original assignee: MCI Worldcom Inc
Current assignee: Verizon Business Global LLC
Priority date: 1998-08-05
Filing date: 1999-07-30
Publication date: 2006-09-14
Anticipated expiration: 2019-07-31
Also published as: US6098094A; US20020059411A1; US7979518B2; EP1103027B1; CA2369038A1; US8693666B2; EP1103027A1; US20030088707A1; US20010014913A1; US20050066030A1; US6560646B2; US6850977B2; US6393476B1; WO2000008565A1; US20110249812A1; DE69929340D1; US6418461B1; EP1103027A4; US7013335B2; JP2002522932A

Description

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 X₁, X₂ und X₃, 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.

Claims

Intelligentes Kommunikationsnetzwerk für die Verwendung in einem Kommunikationssystem, wobei das Netzwerk dadurch charakterisiert ist, dass es umfasst: zumindest einen intelligenten verteilten Netzwerkknoten; zumindest einen intelligenten Vermittlungsknoten mit zumindest einem intelligenten Rufprozessor (172); ein Netzwerkmanagementsystem für die Überwachung und Steuerung des Kommunikationsnetzwerks und des zumindest einen intelligenten Vermittlungsknotens; einen Ressourcenkomplex (180), kommunikativ verbunden aber logisch getrennt von dem zumindest einen intelligenten Rufprozessor (172); wobei der zumindest eine intelligente Rufprozessor (172) ferner umfasst: eine logische Plattform mit einer Vielzahl von Funktionen, wobei zumindest eine der Funktionen eine Dienstverarbeitungsfunktion (22) ist, zumindest eine der Funktionen eine Rufverarbeitungsfunktion (24) ist, zumindest eine der Funktionen eine Einrichtungsverarbeitungsfunktion (26) ist, wobei die Vielzahl von Funktionen übertragbar ist auf zumindest zwei unterschiedliche Rechengeräte von verschiedenen Rechnerarchitekturen; und einen Prozessor für die Ausführung der Vielzahl von Funktionen, wobei der Prozessor eine flexible Architektur bereitstellt.
Intelligentes Netzwerk nach Anspruch 1, bei welchem die logische Plattform eine virtuelle Maschine ist.
Intelligentes Netzwerk nach Anspruch 2, bei welchem die Vielzahl von Funktionen in einer objektorientierten Sprache codiert ist.
Intelligentes Netzwerk nach Anspruch 2, bei welchem die Vielzahl von Funktionen als Java-Bytecodes codiert ist.
Intelligentes Netzwerk nach Anspruch 1, bei welchem die logische Plattform eine objektorientierte Plattform ist und die Vielzahl von Funktionen Managed Objects sind.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Prozessor beinhaltet: zumindest einen Mehrzweckrechner; zumindest ein Datenspeichergerät; und eine Hochgeschwindigkeitskommunikationsverbindung, die den Mehrzweckrechner mit dem Datenspeichergerät verbindet.
Intelligentes Netzwerk nach Anspruch 2, bei welchem der Mehrzweckrechner, das Datenspeichergerät und das Hochgeschwindigkeitsnetzwerk konfiguriert sind, um eine redundante Verarbeitung, Datenspeicherung und Kommunikation bereitzustellen.
Intelligentes Netzwerk nach Anspruch 7, bei welchem der Mehrzweckrechner ein auf einer Mikroprozessor-Architektur basierender ist.
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend eine erste Verbindung für das kommunizierbare Verbinden des Prozessors mit einem Zusatzprozessor, der zumindest eine Altfunktion bereitstellt, bestehend aus der Gruppe von: Beschaffung, Fakturierung und Dienstwiederherstellung.
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend eine zweite Verbindung für das kommunizierbare Verbinden des Prozessors mit einer Direktsignalisierungsverknüpfung (216).
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend eine dritte Verbindung (224) für das kommunizierbare Verbinden des Prozessors mit zumindest einem Ressourcenkomplex (206).
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend eine vierte Verbindung für das kommunizierbare Verbinden des Prozessors mit einem Weitverkehrsnetz (202).
Intelligenter Vermittlungsknoten nach Anspruch 1, bei welchem die Kommunikationsverbindung vom Ressourcenkomplex (206) zum intelligenten Prozessor ferner eine redundante Kommunikationsverbindung umfasst.
Intelligentes Netzwerk nach Anspruch 1, bei welchem die Kommunikationsverbindung vom Ressourcenkomplex (206) zum intelligenten Prozessor eine Hochgeschwindigkeits-Datenkommunikationsverbindung ist.
Intelligentes Netzwerk nach Anspruch 1, bei welchem ein Ressourcenkomplex-Proxy eine Schnittstelle vom intelligenten Rufprozessor zu dem Ressourcenkomplex (206) beinhaltet.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Ressourcenkomplex (206) eine Sammlung von physikalischen Geräten oder Ressourcen beinhaltet, die Träger-, Signal- und Verbindungsdienste bereitstellen.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Ressourcenkomplex (206) eine Schnittstelle beinhaltet, die mit einer Vielzahl von Teilnehmern und Vermittlungsnetzwerken über Standardtelephonie-Verbindungen verbindet.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Ressourcenkomplex (206) eine Vielzahl von Schnittstellen zu Kundensystemen beinhaltet.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Ressourcenkomplex (206) eine standardisierte Schnittstelle verwendet, um eine Einrichtungs- und Netzwerkmanagementverarbeitung zu unterstützen.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Ressourcenkomplex (206) zumindest eine Vermittlungsstruktur beinhaltet.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Ressourcenkomplex (206) ein intelligentes Peripheriegerät (88) beinhaltet, das auf Informationen hin innerhalb eines wirklichen Rufübertragungspfads verarbeitet und wirkt.
Intelligentes Netzwerk nach Anspruch 21, bei welchem das intelligente Peripheriegerät (88) Daten in Echtzeit mittels digitaler Signalverarbeitungstechniken verarbeitet.
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend Mittel für das kommunizierbare Verbinden des Ressourcenkomplexes (206) mit einem Netzwerkmanagementsystem (212) über eine Betriebsverbindung (226).
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend: eine erste Verbindung für das kommunizierbare Verbinden des Ressourcenkomplexes (206) mit einem Trägerabschnitt einer Direktverbindung (218); und eine zweite Verbindung für das kommunizierbare Verbinden des Prozessors mit einem Signalabschnitt der Direktverbindung (214).
Intelligentes Netzwerk nach Anspruch 1, ferner umfassend Mittel für die Überwachung und Manipulation einer Vielzahl von Verarbeitungsunterelementen, wobei die Unterelemente Teil der Vielzahl der Funktionen sind.
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend: Mittel für das Überwachen der Verwendung der Vielzahl von Funktionen; und Mittel für das Ausschließen einer ausgewählten Funktion von der Vielzahl von Funktionen.
Intelligentes Netzwerk nach Anspruch 1, bei welchem der Prozessor ein Verfahren einer virtuellen Maschine ausführt, das eine Dienstebenen-Ausführungsumgebung (242) lädt und ausführt.
Intelligentes Netzwerk nach Anspruch 27, bei welchem die Dienstebenen-Ausführungsumgebung (242) eine Vielzahl von Softwareinstanzen beherbergt, die die Dienstverarbeitungsarchitektur implementieren und von einer Managed-Objects-Basisklasse abgeleitet sind.
Intelligentes Netzwerk nach Anspruch 28, bei welchem die Vielzahl von Softwareinstanzen nach Bedarf durch ein Netzwerkmanagementsystem (212) oder während der Verarbeitung eines durch einen Teilnehmer angeforderten Dienstes instantiiert werden kann.
Intelligentes Netzwerk nach Anspruch 27, bei welchem die Dienstebenen-Ausführungsumgebung (242) die Ausführung einer Vielzahl von Managed Objects steuert.
Intelligentes Netzwerk nach Anspruch 30, bei welchem die Vielzahl von Managed Objects in einer objektorientierten Sprache codiert ist.
Intelligentes Netzwerk nach Anspruch 30, bei welchem die Vielzahl von Managed Objects als Java-Bytecodes codiert ist.
Intelligentes Netzwerk nach Anspruch 28, bei welchem die Dienstebenen-Ausführungsumgebung (242) eine Managed-Object-Ebene (244) und eine Bibliothek-Ebene (264; 266) beinhaltet.
Intelligentes Netzwerk nach Anspruch 28; bei welchem ein Satz von Betriebsregeln verwendet wird, um zu bestimmen, ob ein spezifisches Managed Object eingesetzt oder instantiiert werden kann oder nicht.
Intelligentes Netzwerk nach Anspruch 34, bei welchem der Satz von Betriebsregeln innerhalb des spezifischen Managed Objects codiert ist.
Intelligentes Netzwerk nach Anspruch 34, bei welchem der Satz von Betriebsregeln bei einem Netzwerkmanagementsystem (212) codiert ist.
Intelligentes Netzwerk nach Anspruch 29, bei welchem das Netzwerkmanagementsystem (212) beliebige Konflikte, die im Satz der Betriebsregeln auftreten, löst, wenn das Managed Object eingesetzt oder instantiiert wird.
Intelligentes Netzwerk nach Anspruch 34, bei welchem der Satz von Betriebsregeln logische Bedingungen spezifiziert, während welchen es dem Managed Object erlaubt oder verboten ist, eingesetzt oder instantiiert zu werden.
Intelligentes Netzwerk nach Anspruch 34, bei welchem der Satz von Betriebsregeln physikalische Orte spezifiziert, wo es dem Managed Object erlaubt oder verboten ist, eingesetzt oder instantiiert zu werden.
Intelligentes Netzwerk nach Anspruch 27, bei welchem die Dienstebenen-Ausführungsumgebung (242) ferner beinhaltet: Mittel für das Einsetzen und Entfernen einer Vielzahl von Managed Objects; Mittel für das Instantiieren, Abfragen und Zerstören einer Vielzahl von Managed-Object-Instanzen; Mittel für das Unterstützen der Interaktion und Zusammenarbeit der Vielzahl von Managed Objects; Mittel für das Verwalten von Zugriff auf eine native Bibliothek; Mittel für das Kommunizieren mit einer Schnittstelle zu einem Netzwerkmanagementsystem (212), um Steuersignale zu empfangen und zu implementieren; Mittel für das Bestätigen einer Vielzahl von globalen Werten; und Mittel für das Steuern des Startens und Stoppens der Vielzahl von Managed Objects.
Intelligentes Netzwerk nach Anspruch 27, bei welchem die Dienstebenen- Ausführungsumgebung (242) eine Basisklasse von Managed Objects beinhaltet, die eine Dienststeuerungsklasse (252), eine Rufsteuerungsklasse (250), eine Trägersteuerungsklasse (248) und eine Ressourcen-Proxy-Klasse (246) beinhaltet.
Intelligentes Netzwerk nach Anspruch 41, bei welchem die Dienststeuerungsklasse (252) ferner beinhaltet: einen Sitzungsmanager; eine Trägerpotential-Klasse (282); eine Dienstarbitrationsklasse (288) eine Merkmalsklasse (290) eine Dienstdiskriminator-Klasse (296) eine medienunabhängige Dienstklasse (289); und eine Verbindungsmanager-Klasse (302).
Intelligentes Netzwerk nach Anspruch 41, bei welchem die Rufsteuerungsklasse (250) ferner eine Veranlassungsklasse und eine Beendigungsklasse enthält.
Intelligentes Netzwerk nach Anspruch 41, bei welchem die Trägersteuerungsklasse (248) spezifische Signale und Ereignisse an und von dem Ressourcenkomplex (206) über den Ressourcen-Proxy adaptiert.
Intelligentes Netzwerk nach Anspruch 41, bei welchem die Ressourcen-Proxy-Klasse die Ausführungsumgebung mit einer Vielzahl von Vermittlungsgeräten in einem Trägernetzwerk koppelt.
Intelligentes Netzwerk nach Anspruch 41, bei welchem die Ressourcen-Proxy-Klasse ferner beinhaltet: eine Telephonklasse (320); eine Sprachantworteinheit-Klasse (322); eine Verbindungsleitungsklasse (324); und eine Modemklasse (326).
Intelligentes Netzwerk nach Anspruch 1, ferner beinhaltend: ein Weitverkehrsnetz (202), das eine Vielzahl von intelligenten verteilten Netzwerkknoten und das Netzwerkmanagementsystem (212) verbindet.
Intelligentes Netzwerk nach Anspruch 47, bei welchem das Weitverkehrsnetz (202) ein synchrones optisches Netzwerk ist.
Intelligentes Netzwerk nach Anspruch 47, bei welchem das Weitverkehrsnetz (202) eine gemeinsame Objektanfrage-Brokerarchitektur verwendet.
Intelligentes Netzwerk nach Anspruch 1, bei welchem das Netzwerkmanagementsystem (212) innerhalb eines Telekommunikationsmanagementnetzwerk-konformen Systems arbeitet.
Intelligentes Netzwerk nach Anspruch 1, bei welchem das Netzwerkmanagementsystem (212) die Vielzahl von intelligenten verteilten Netzwerkknoten derart überwacht und steuert, dass Dienste und Funktionen flexibel und dynamisch über die Vielzahl von intelligenten verteilten Netzwerkknoten verteilt werden können.
Intelligentes Netzwerk nach Anspruch 1, bei welchem das Netzwerkmanangementsystem (212) den Einsatz von Diensten steuert, die Gesundheit jener Dienste aufrecht erhält, Informationen über jene Dienste bereitstellt und Netzwerklevel-Managementfunktionen bereitstellt.
Intelligentes Netzwerk nach Anspruch 1, bei welchem das Netzwerkmanagementsystem (212) ferner beinhaltet: Mittel für das Aufrufen, Steuern und Überwachen der Dienste und Hardware in der Vielzahl von intelligenten Netzwerkknoten durch eine Agentenfunktionalität; Mittel für das Steuern des Betriebs eines lokalen Betriebssystems (260) auf jedem intelligenten Rufprozessor, einschließend das Starten und Stoppen einer Vielzahl von Verfahren, Abfragen der Inhalte einer Verfahrenstabelle und des Status einer Vielzahl von Verfahren; Mittel für das Überwachen der Leistung des intelligenten Rufprozessors (172); Mittel für das Steuern der Initialisierung und des Betriebs des Weitverkehrsnetzes (202); und Mittel für das Steuern und Unterstützen der Instantiierung einer Vielzahl von Dienstebenen- Ausführungsumgebungen, die auf einem einzelnen intelligenten Rufprozessor (172) laufen.
Intelligentes Netzwerk nach Anspruch 53, ferner beinhaltend eine Managed-Object-Erzeugungsumgebung (228), kommunizierbar verbunden mit dem Netzwerkmanagementsystem (212), für das Erzeugen, Modifizieren, Testen und Einsetzen von Funktionen, die vom Rufprozessor zu verwenden sind.
Intelligentes Netzwerk nach Anspruch 54, bei welchem die Managed-Object-Erzeugungsumgebung (228) modulare Werkzeuge verwendet, so dass Dienstentwicklungsarbeit aufgeteilt werden kann.
Intelligentes Netzwerk nach Anspruch 54, bei welchem Managed-Object-Software und entsprechende Abhängigkeiten in der Managed-Object-Erzeugungsumgebung (228) erzeugt werden.
Intelligentes Netzwerk nach Anspruch 54, bei welchem die Managed-Object-Erzeugungsumgebung (228) ferner eine Vielzahl von Unterkomponenten beinhaltet, die verwendet werden können, um Dienste zu erzeugen.
Intelligentes Netzwerk nach Anspruch 54, bei welchem die Managed-Object-Erzeugungsumgebung (228) ferner eine vereinheitlichte Sammlung von Werkzeugen beinhaltet, die auf einer einzelnen Bedienerumgebung oder Plattform beherbergt sind.
Intelligentes Netzwerk nach Anspruch 54, bei welchem die Managed-Object-Erzeugungsumgebung (228) ferner eine Sammlung von Handlungen beinhaltet, die im gesamten Verfahren der Diensterzeugung benötigt werden, wie beispielsweise Dienstdokumentation, Managed-Object-Definition, Schnittstellendefinition, Protokolldefinition und Dateneingabedefinition, welche in Managed Objects eingeschlossen sind, sowie Diensttestung.
Intelligentes Netzwerk nach Anspruch 1, bei welchem die Vielzahl von Funktionen zum intelligenten Rufprozessor (172) innerhalb eines beliebigen intelligenten verteilten Netzwerkknotens ohne Unterbrechen des Betriebs des intelligenten Rufprozessors bewegt werden kann.
Verfahren der Verwendung einer Managed-Object-Erzeugungsumgebung, um eine Softwarekonfiguration zu aktualisieren, dadurch gekennzeichnet, dass es folgende Schritte umfasst: Auswählen eines Softwarekomponententyps; Auswählen einer Softwarekonfiguration; Starten eines geeigneten Softwareerzeugungswerkzeugs; Verwenden des geeigneten Softwareerzeugungswerkzeugs, um ein oder mehrere Managed Objects innerhalb der Softwarekonfiguration zu modifizieren oder zu erzeugen; Sammeln von einem oder mehreren Ergebnissen von dem geeigneten Softwareerzeugungwerkzeug und; Aktualisieren der ausgewählten Softwarekonfiguration, basierend auf dem einen oder den mehreren Ergebnissen.
Verfahren der Verwendung eines oder mehrerer Managed Objects, um einen Dienst bereitzuststellen, umfassend die Schritte: Empfangen eines Ereignisses innerhalb einer Dienstebenen-Ausführungsumgebung (242); Bestimmen des einen oder der mehreren Managed Objects, die benötigt werden, um auf das Ereignis zu antworten; Instantiieren des einen oder der mehreren Managed Objects; und Bereitstellen des Dienstes unter Verwendung des einen oder der mehreren instantiierten Managed Objects.
Verfahren der Implementierung eines neuen Dienstes unter Verwendung eines oder mehrerer Managed Objects, umfassend die Schritte: Erzeugen des einen oder der mehreren Managed Objects; Testen des einen oder der mehreren Managed Objects in einer Dienstebenen-Ausführungsumgebung (242); wann immer das Testen des einen oder der mehreren Managed Objects erfolgreich ist, Durchführen von Integrationstests durch Testen des einen oder der mehreren Managed Objects mit anderen Managed Objects und Systemen, die benötigt werden, um den neuen Dienst zu implementieren; und wann immer die Integrationstestung erfolgreich ist, implementieren des neuen Dienstes durch Einsetzen des einen oder der mehreren Managed Objects an einem oder mehrere intelligente Rufprozessoren (172).