DE69910816T2

DE69910816T2 - Verfahren und gerät um echtzeit rufbearbeitungsdienste in einem intelligenten netzwerk zur verfügung zu stellen

Info

Publication number: DE69910816T2
Application number: DE69910816T
Authority: DE
Inventors: Ajay Deo; Wendy Wong; Henry Wang; Sami Syed
Original assignee: Deo Ajay Lewisville; Syed Sami Colorado Springs; Wang Henry Colorado Springs
Current assignee: Verizon Business Global LLC
Priority date: 1998-10-20
Filing date: 1999-10-20
Publication date: 2004-06-17
Anticipated expiration: 2019-10-21
Also published as: AU1215200A; AU6522099A; EP1157529B1; AU770505B2; CN1334939A; JP2002528968A; WO2000023898A1; DE69914952D1; ATE248401T1; DE69914952T2; CN1336068A; DE69921169T2; IL142663A0; EP1131730A1; WO2000024182A9; IL142661A0; DE69921169D1; AU773432B2; CN1126350C; AU1129100A

Description

Die vorliegende Erfindung befasst sich im Allgemeinen mit intelligenten Netzsystemen zur Bereitstellung von Kommunikations-Diensten, und speziell mit einem neuartigen Steuersystem für Dienste, um Dienste zur Echtzeit-Ereignisverarbeitung an jedem einer Vielzahl von Serviceknoten, die über ein intelligentes Netz verteilt sind, bereitzustellen.
Ein Netzdienst ist eine von einem Kommunikationsnetz und diesem zugeordneten Ressourcen ausgeführte Funktion, wie Datenübertragung) oder Fernsprechen, als Antwort auf eine Interaktion mit einem oder mehreren Abonnenten. Zum Beispiel kann ein zum Fernsprechnetzwerk gehöriger Dienst, wie Anrufweiterleiten oder Voicemail-Zugang, von einem Abonnenten durch Wählen einer speziellen Ziffernsequenz aufgerufen werden. Andere Netzwerk-Dienste sind daraufhin ausgerichtet, dem Netzwerkbesitzer bei der Sicherheit, Validierung und Authentifizierung zu assistieren. Das Hinzufügen oder Ändern eines Dienstes erfordert Änderungen im Kommunikationsnetzwerk.
Die meisten konventionellen Telekommunikationsnetzwerke sind als miteinander verbundenen Switches und Kommunikations-Diensten zusammengesetzt. Diese Switches werden von integrierten oder eingebauten Prozessoren gesteuert, die mit proprietärer, vom Hersteller des Switches entwickelter Software oder Firmware betrieben werden. Typischerweise muss die Software oder Firmware des Switch-Herstellers alle funktionalen Aspekte der Diensteverarbeitung, Anrufverarbeitung, Anlagenverarbeitung und Netzwerkmanagement unterstützen. Das bedeutet, dass wenn ein Netzwerkbetreiber einen neuen Dienst einführen oder einen existierenden Dienst modifizieren will, die Software von jedem Switch des Netzwerkes durch die verschiedenen Switch-Hersteller geändert werden muss.
Die Tatsache, dass das Netzwerk unterschiedliche Switchmodelle von unterschiedlichen Herstellern enthält, erfordert umsichtige Entwicklung, Überprüfung und Inbetriebnahme der neuen Software. Die zum Entwickeln, Testen und Inbetriebnehmen der neuen Software benötigte Zeit verlängert sich, weil die Quelltextgröße in jedem Switch mit jeder neuen Revision größer und komplexer wird. Somit kann dieser Prozess mehrere Jahre dauern. Zusätzlich belastet diese erhöhte Komplexität die Prozessoren der Switches zusätzlich, erhöht die Wahrscheinlichkeit für Fehlfunktionen und macht unter Umständen die Modifikation oder den Austausch des Switches erforderlich. Darüber hinaus führt die Tatsache, dass mehrere Netzbetreiber von einer allgemeinen Menge von Switch-Herstellern abhängen zu zwei unerwünschten, wettbewerbseinschränkenden Situationen. Erstens wird die Software-Weiterentwicklung eines Herstellers vermutlich versuchen, von mehreren Netzbetreibern geforderte Änderungen einzubauen, womit den Netzbetreibern die Möglichkeit genommen wird, sich mit ihren Diensten von den von der Konkurrenz angebotenen Diensten abzugrenzen. Dies zwingt manche Netzbetreiber auch, darauf zu warten, bis der Hersteller Forderungen anderer Netzbetreiber in die neue Weiterentwicklung aufnimmt. Zweitens kann eine Weiterentwicklung der Switch-Software, die eine von einem Netzbetreiber angefragte Funktion zur Implementierung eines neuen Dienstes enthält, unabsichtlich anderen Netzbetreibern zugänglich werden.
Diese Probleme wurden unerträglich, da die Nachfrage nach neuen Netzdiensten exponentiell in den letzten fünf bis zehn Jahren aufgrund von erhöhter Abonnentenmobilität, erhöhter Vielfalt und Bandbreite des Verkehrs, Auflösung traditionellen Nummerierungspläne, fortgeschrittener Dienste und erhöhtem Wettbewerb gestiegen ist. Daher ist es weithin anerkannt, dass neue Netzarchitekturen einen flexibleren Weg zum Erschaffen, Inbetriebnehmen und Ausführen von Dienstlogik aufnehmen müssen. Um die neuartige Architektur der vorliegenden Erfindung, die im Anschluss beschrieben wird, in vollem Umfang zu würdigen, wird der relevante Stand der Technik mit Bezug auf 1 im Folgenden beschrieben.
Mit Bezug auf 1 wird eine logische Darstellung verschiedener Switch-Architekturen, einschließlich der vorliegenden Erfindung, gezeigt. Ein monolithischer Switch, im Weiteren mit 20 bezeichnet, enthält Dienstverarbeitungsfunktionen 22, Anrufverarbeitungsfunktionen 24, Anlagenverarbeitungsfunktionen 26 und ein Switching-Fabric 28. All diese Funktionen 22, 24, 26 und 28 sind hart-codiert, vermischt und undifferenziert, so wie dies durch die Gruppe 30 symbolisch dargestellt ist. Darüber hinaus wurden die Funktionen 22, 24, 26 und 28 von den Switch-Herstellern entwickelt und arbeiten auf proprietären Plattformen, die sich von Hersteller zu Hersteller unterscheiden. Daraus folgt, dass diese Funktionen 22, 24, 26 und 28 nicht ohne Hilfe des Herstellers modifiziert werden können, was die Entwicklung und Implementierung neuer Dienste verlangsamt und die Kosten für die Markteinführung eines neuen Dienstes erhöht. Die Entwicklung neuer und innovativer Dienste, Anrufverarbeitung, Da tenverarbeitung, Signalverarbeitung und Netzbetrieb sind daher beschränkt durch die Kontrolle des Herstellers über eine proprietäre Switch-Hardware und Software, und die inhärente Schwierigkeit bei der Einführung und Implementierung von Industriestandards.
Die Dienstverarbeitungsfunktionen 22 sind innerhalb des monolithischen Switches 20 codiert und erlaubt nur lokale Kontrolle dieses Prozesses, der auf lokalen Dateninhalten und der gewählten Nummer ausbaut. Diese lokale Information wird von einer hart-codierten Verarbeitungsmaschine interpretiert, die die codierte Dienstfunktion ausführt. Die Anrufverarbeitungsfunktionen 24 sind hart-codiert und unterstützen Anrufursprungs- und Anrufbeendigungsfunktionen. Dieser Prozess stellt tatsächlich individuelle Verbindungen her und trennt sie, um einen Anruf zu vervollständigen. Gleichermaßen sind auch die Anlagenverarbeitungsfunktionen 26 hart-codiert und unterstützen die gesamte Datenverarbeitung, die sich mit den bei einem Anruf beteiligten physikalischen Ressourcen befasst. Das Switching-Fabric 28 stellt die Hardware-Komponente des Switches und den Computer, auf dem die vom Switch-Hersteller, wie Northern Telecom, Inc., bereitgestellte, monolithische Software abläuft, dar. Das Switching-Fabric 28 stellt die physikalischen Einrichtungen, die zum Ausbauen einer Verbindung erforderlich sind und die Trägervorrichtungen (T1-Leitungen und DSO's), Switching-Matrixvorrichtungen (Netzebenen und ihre Prozessoren), Verbindungsebenen-Signalprozessoren (SS7, MTP, ISDN, LAPD) und spezialisierte Schaltkreise (Konferenzanschlüsse, Wähltondetektoren) umfassen, aber nicht auf diese beschränkt sind, bereit.
Ein Versuch, die zuvor beschriebenen Probleme zu behandeln, stellt der ITU-T Intelligent Network Standard ("IN") dar, welcher von der International Telecommunications Union und dem European Telecommunication Standards Institute bestätigt wird. Gleichermaßen brachte Bellcore den Advanced Intelligent Network Standard ("AIN") vor. Obwohl diese zwei Standards sich bezüglich Präsentation und Fortschritt unterscheiden, haben sie nahezu identische Ziele und Grundkonzepte. Entsprechend werden diese Standards als eine einzelne Netzarchitektur betrachtet, in der die Dienstverarbeitungsfunktionen 22 vom Switch getrennt sind.
Durch Benutzen der IN- und AIN-Architekturen könnte ein Netzbetreiber vermutlich einen neuen Dienst durch Erzeugen und Inbetriebnehmen eines neuen Dienstlogikprogramms ("SLP"), welches im Wesentlichen eine Tabelle mit dienstunabhängigen Baublöcken ("SIBB"), die während eines gegebenen Anruftyps aufgerufen werden, ist, einführen. Ent sprechend diesem Ansatz wirkt eine Anzahl von spezifischen Elementtypen zusammen in Verbindung mit einem SLP, um Netzabonnentendienste zur Verfügung zu stellen. Als Ergebnis sind jegliche neuen oder potentiellen Dienste durch die existierenden SIBBs beschränkt.
Die IN- oder AIN-Architektur, welche mit 40 bezeichnet ist, trennt auf logische Weise die Funktionen des monolithischen Switches 20 in einen Dienstesteuerungsknoten ("SCP") 42 einerseits und in einen Dienstevermittlungsknoten ("SSP") und ein Switching-System 44 andererseits. Der SCP 42 enthält Dienstverarbeitungsfunktionen 22, wohingegen der SSP und das Vermittlungssystem 44 die Anrufverarbeitungsfunktionen 24, die Anlagenverarbeitungsfunktionen 26 und das Switching-Fabric 28 enthalten. In diesem Fall sind die Anrufverarbeitungsfunktionen 24, die Anlagenverarbeitungsfunktionen 26 und das Switching-Fabric 28 hart-codiert, gemischt und undifferenziert, so wie es durch die Gruppe 46 dargestellt ist.
Der Service Switching Point ("SSP") ist ein im Switch residierendes funktionelles Modul, das dazu dient, zu erkennen, wenn die Signalisierung eines Abonnenten mehr als ein einfaches, allein auf der gewählten Nummer basierendes Routing erfordert. Der SSP unterbricht die Behandlung des Anrufs, während er eine Anfrage für die korrekte Behandlung des Anrufs zum entfernten SCP 22 initiiert, welcher im Wesentlichen als Datenbankserver für eine Anzahl von Switches dient. Diese Unterteilung der Verarbeitung resultiert in der Wegnahme der seltenen, jedoch zeitraubenden Aufgabe der Behandlung von Anrufen mit speziellen Diensten vom Switch. Darüber hinaus wägt diese moderate Zentralisierung zwischen einem bequem modifizierbaren, schwer belasteten Repository, welches das gesamte Netz bedient, gegen die Inbetriebnahme einer kompletten Kopie des Repositorys an jedem Switch ab.
Mit Bezug auf 2 wird ein Diagramm eines Telekommunikationssystems, welches eine IN- oder AIN-Architektur benutzt, gezeigt und mit 50 bezeichnet. Verschiedene Kundensysteme, wie ein ISDN-Terminal 52, ein erstes Telefon 54, ein zweites Telefon 56, sind mit dem SSP und dem Switching System 44 verbunden. Das ISDN-Terminal 52 ist mit dem SSP und Switching System 44 über die Zeichengabestrecke 60 und die Transportleitung 62 verbunden ??? (Bezugszeichen überprüfen: signaling live 58, transport line 60). Das erste Telefon 54 ist mit dem SSP und dem Switching System 44 über die Transportleitung 64 verbunden ??? 62. Das zweite Telefon 56 ist mit einem entfernten Switching-System 66 ??? 64 über die Transportleitung 68 ??? 66 und das entfernte Switching-System 66 ist mit dem SSP und dem Switching-System 44 über die Transportleitung 70 ??? 68 verbunden.
Wie zuvor bezüglich 1 beschrieben, ist der SSP 70 ein funktionelles, im Switch residierendes Modul, um festzustellen, wann die Zeichengabe eines Kunden mehr als ein einfaches, auf der gewählten Nummer basierendes Routing erfordert. Der SSP 70 unterbricht die weitere Behandlung des Anrufes während er eine Anfrage für die korrekte Behandlung des Anrufs auslöst. Diese Anfrage wird in Form einer SS7-Nachricht an einen entfernten SCP 42 gesendet. Dieser Dienststeuerungsknoten 42 wird so genannt, da an dieser Stelle eine Änderung des Datenbankinhalts die Netzfunktion, so wie sie Abonnenten erscheint, die über die vielen entgegengesetzten Switches verbunden sind, verändern. Die Anfrage wird über die Zeichengabeleitung 72 an den Signalübertragungsort ("STP") 74 gesendet, welcher einfach ein Router für SS7-Nachrichten unter jenen Elementen ist, und dann über die Zeichengabeleitung 76 an den SCP 42 gesendet.
Das Managementsystem für integrierte Dienste ("ISMS") 78 ist gedacht als ein Managementwerkzeug zur Inbetriebnahme oder Veränderung von Diensten oder zur Verwaltung von abonnenten-bezogenem Zugang zu Diensten. Das ISMS 78 arbeitet hauptsächlich durch Veränderung der verarbeitenden Logik und der innerhalb des SSP 70 und des SCP 42 gespeicherten Daten. Das ISMS 78 hat verschiedene Bedienerschnittstellen 80 und 82. Dieses ISMS 78 ist mittels der Betriebsleitung 84 mit dem SCP 42 verbunden, der SSP und das Switching System 44 mittels Betriebsleitung 86 und das Intelligent Peripheral ("IP") 88 mittels Betriebsleitung 90. Das Intelligent Peripheral 88 ist eine Vorrichtung, die zum Hinzufügen von Funktionen zum Netzwerk dient, die nicht auf den Switches verfügbar sind, wie ein Sprachausgabe- oder -erkennungssystem. Das IP 88 ist mit dem SSP und dem Switching-System 44 über die Zeichengabeleitung 92 und die Transportleitung 94 verbunden.
Bezugnehmend auf 2 wird nun die Verarbeitung eines Anrufes gemäß dem Stand der Technik beschrieben. Der Anruf wird ausgelöst, wenn der Kunde den Hörer abhebt und zu wählen beginnt. Der SSP 70 am Switch des Unternehmens überwacht den Wählvorgang und erkennt die Triggersequenz. Der SSP 70 unterbricht die weitere Behandlung des Anrufs, bis eine Dienstelogik konsultiert werden kann. Der SSP 70 stellt dann eine Standard-SS7-Nachricht zusammen und sendet sie via STP(s) 74 an den SCP 42. Der SCP 42 empfängt und decodiert die Nachricht und ruft das SLP auf. Der SLI interpretiert den SCP, welcher seinerseits das Ausführen anderer Funktion wie einer Datenbankabfrage zwecks Nummerübersetzung anfordern kann. Der SCP 42 sendet eine SS7-Nachricht an den SSP und das Switching-System 44 bezüglich der Verarbeitung des Anrufes zurück oder setzt auf andere Weise eine Nachricht an die Netzwerkelemente ab, den korrekten Dienst auszuführen. Bei Beendigung des Anrufs wird eine SS7-Nachricht zwischen den Switches gesendet, um den Anruf zu beenden und Anrufdetaildatensätze werden erzeugt durch jeden an dem Anruf beteiligten Switch. Die Anrufdetaildatensätze werden für jeden Anruf gesammelt, korreliert und offline ausgewertet, um die Rechnung für gebührenpflichtige Anrufe abzuleiten und somit die Anrufverarbeitung abzuschließen.
Die IN- und AIN-Architekturen versuchen eine Standardmenge von Funktionen vorzudefinieren, um alle vorhersehbaren Dienste zu unterstützen. Diese Standardfunktionen sind alle hartcodiert in verschiedenen Zustandsmaschinen im Switch. Unglücklicherweise können keine neuen Funktionen, die wahrscheinlich in Verbindung mit neuen Technologien oder unvorhergesehenen Bedürfnissen nach Diensten auskommen, ohne eine umfassende Überholung und Testen der Netzwerksoftware über viele Herstellerplattformen implementiert werden. Darüber hinaus kann, falls eine neue Funktion Änderungen in standardisierten Anrufmodellen, Protokollen oder Schnittstellen erforderlich macht, die Implementierung des Dienstes, der diese Funktion benutzt, verzögert werden, bis die Änderungen durch einen Industrienormenverband ratifiziert werden. Aber selbst als Normentwürfe versucht haben, die Menge der von IN- und AIN-unterstützten Funktionen zu vergrößern, haben Ausrüstungslieferanten verweigert, diese Normentwürfe zu bestätigen aufgrund des schrittweisen Anwachsens der Codekomplexität.
Bei weiterer Betrachtung der 2 entstehen andere Beschränkungen der IN- und AIN-Architektur dadurch, dass die Anrufverarbeitungs- und Anlagenverarbeitungsfunktionen, insbesondere der SSP 70, innerhalb des Switches arbeitet. Dies führt dazu, dass diese Funktionen von jedem Switch-Hersteller unter Benutzung ihrer proprietären Software bereitgestellt werden müssen. Netzbetreiber sind daher immer noch stark von Softwareweiterentwicklungen der Hersteller für die Unterstützung neuer Funktionen abhängig. Um die Lage noch weiter zu verkomplizieren, kann der Netzbetreiber SSP 70 Module nicht in Verbindung mit anderen Modulen in einer einheitlichen Entwicklungs- und Testumgebung testen. Darüber hinaus gibt es keine Absicherung, dass ein für die Verarbeitungsumgebung eines Switch-Herstellers gedachte SSP 70 kompatibel sein wird mit der Diensteerzeugungsumgebung des Netzbetreibers.
Diese Abhängigkeit mehrerer Netzbetreiber von einer verbreiteten Menge von Switch-Herstellern resultiert in zwei unerwünschten Situationen, die den Wettbewerb einschränken. Erstens wird die Software-Weiterentwicklung eines Herstellers vermutlich versuchen, von mehreren Netzbetreibern geforderte Änderungen einzubauen, womit den Netzbetreibern die Möglichkeit genommen wird, sich mit ihren Diensten von den von der Konkurrenz angebotenen Diensten abzugrenzen. Dies zwingt manche Netzbetreiber auch, darauf zu warten, bis der Hersteller Forderungen anderer Netzbetreiber in die neue Weiterentwicklung aufnimmt. Zweitens kann eine Weiterentwicklung der Switch-Software, die eine von einem Netzbetreiber angefragte Funktion zur Implementierung eines neuen Dienstes enthält, unabsichtlich anderen Netzbetreibern zugänglich werden. Aus diesem Grund, trotz der Absichten der IN- und AIN-Architekten ist das Erschaffen, Testen und Inbetriebnehmen neuer Dienste für Netzbetreiber immer noch gehemmt, weil der Netzbetreiber nicht die umfassende Kontrolle über oder Zugriff auf die funktionellen Elemente, welche das Verhalten von Netzdiensten ausmacht, haben.
In einem anderen Versuch, diese Probleme zu lösen, trennt eine separate Switch-Intelligence und eine Switching-Fabric ("SSUSF")-Architektur, mit 150 gekennzeichnet, den SSP 70 logisch von dem Switching-System 44. Sich wieder auf 1 beziehend, enthält die Switch-Intelligence 152 die Anrufverarbeitungsfunktionen 24 und die Anlagenverarbeitungsfunktionen 26, die in diskreten Zustandstabellen mit entsprechenden hart-codierten Zustandsmaschinen codiert sind, was symbolisch durch die Kreise 154 und 156 dargestellt wird. Die Schnittstelle zwischen den Switching-Fabric-Funktionen 158 und den Intelligence-Funktionen 152 kann durch ein Kommunikationsnetzwerk erweitert werden, so dass das Switching-Fabric 158 und die Switch Intelligence 152 nicht notwendigerweise physikalisch zusammen platziert, auf dem gleichen Prozessor ausgeführt oder sogar eine Eins-zu-Eins-Korrespondenz haben müssen. Daher stellt die Switch Intelligence 152 eine schlüssige Schnittstelle von einfachen, nicht dienstspezifischen, nicht herstellerspezifischen Funktionen, die allen Switches gemein sind, zur Verfügung.
Ein Intelligent Computing Complex ("ICC") 160 enthält die Dienstverarbeitungsfunktionen 22 und kommuniziert mit mehreren Switch Intelligence-Elementen 152. Dieser Ansatz bietet dem Netzbetreiber Vorteile durch flexible Dienstimplementierung, weil alle bis auf die allerelementarsten Funktionen aus dem Bereich des herstellerspezifischen Codes herausgenommen wurden. Weitere Verbesserungen können durch das Bereitstellen einer einheitlicheren Umgebung für das Erschaffen, Entwickeln, Testen und Ausführen von Dienstlogiken realisiert werden. Eine solche Umgebung ist in WO 95/23483 beschrieben.
Wie zuvor diskutiert, basieren aktuelle Netzswitches auf einer monolithischen proprietären Hardware und Software. Obwohl Netzwerkswitches Millionen von Dollar kosten können, ist diese Ausrüstung relativ langsam im Sinne von Verarbeitungsgeschwindigkeit, wenn es im Licht aktuell erhältlicher Computertechnik betrachtet wird. Zum Beispiel basieren diese Switches auf Reduced-Instruction Set Computing ("RISC")-Prozessoren, die im Bereich von 60 MHz laufen und die untereinander mittels eines Datenkommunikationsprotokolls, wie X.25, kommunizieren, das typischerweise eine Übertragungsrate von 9,6 Kb/s zwischen verschiedenen Plattformen in einem Switching-Netzwerk unterstützt. Dies ist extrem langsam, wenn es mit Personal Computern, welche mit 200 MHz oder mehr arbeitende Prozessoren enthalten, und Hochleistungsarbeitsstationen, die 150 Mb/s FDDI und ATM-Schnittstellen anbieten, verglichen wird. Dementsprechend muss es Netzbetreibern möglich sein, Hochleistungsarbeitsstationen anstelle von proprietärer Hardware zu benutzen.
Die vorliegende Erfindung ist auf ein Dienststeuerungssystem zur Bereitstellung von Echtzeitdienstverarbeitung aller Ereignisse und Dienstanforderungen, die an einem Ressourcenkomplex, z. B. Switch oder Router, eintreffen, der physikalisch jedem von einer Vielzahl von verteilten Dienstknoten eines intelligenten Kommunikationsnetzwerks zugeordnet ist.
Allgemein ist die Dienststeuerungskomponente der Erfindung in der Lage, den Ressourcenkomplex eines intelligenten Netzwerks, z. B. ATM-Switch, Internet-Gateway, Intelligent Peripheral oder andere Switch- oder Router-Ressourcen, bei der Verarbeitung von Dienstanfragen anzuleiten, und umfasst weiterhin die benötigte Intelligenz, um die Serviceanfragen zu verarbeiten. Insbesondere befähigt die eingebaute Intelligenz die Dienststeuerungskomponenten zur Interaktion mit anderen Komponenten des intelligenten Netzwerks, um auf zusätzliche Logik zuzugreifen oder Information zu erhalten (Dienst- oder Benutzerdaten), welche für die Verarbeitung einer Dienstlogikinstanz benötigt werden. Die Dienststeuerung besitzt Schnittstellen und interagiert mit dem Ressourcenkomplex und einem lokalen Datenmanagementsystem während der Echtzeitdienstverarbeitung und besitzt die logischen und verarbeitenden Fähigkeiten, die zum Behandeln von durch intelligente Netzwerke bereitgestellte Dienstversuche benötigt werden. Die Dienststeuerung wird von einem Dienstadministrator und von Datenmanagementkomponenten des intelligenten Netzwerks geleitet, aktualisiert und verwaltet. Das intelligente Netzwerk stellt intelligente Anrufverarbeitungsdienste, unabhängig von und transparent für die Anrufvermittlungsplattform oder den Ressourcenkomplex, in dem ein Anruf eintrifft, bereit und ist auf die Behandlung von Anrufereignissen angepasst. Somit ist die Abhängigkeit von teueren, herstellerspezifischer Hardware, Betriebssystemen und Vermittlungsplattformen beseitigt. Das verteilte intelligente Netzwerk unterstützt zusätzlich ortsunabhängige ereignisverarbeitende Dienstausführung, womit die modularen softwarelogischen Programme so gut wie überall in der Architektur laufen können, und stellt ortsunabhängige Kommunikationen zwischen diesen verteilten Prozessen bereit, womit der Bedarf an spezialisierten Dienstknoten weiterhin eliminiert wird.
Insbesondere steuert die Erfindung einen oder mehrere Prozesse, welche gestartet werden, wenn eine Dienstanforderung an die Dienststeuerungskomponente durch den Ressourcenkomplex gesendet wird. Die Dienststeuerung interagiert mit anderen Komponenten, um auf für das Bereitstellen des angefragten Dienstes benötigte Daten zuzugreifen. Wenn die Verhaltenssequenz des angefragten Dienstes komplett ist, oder wenn der Dienstbenutzer die Benutzung des Dienstes aufgibt, ist der Prozess komplett. Alle Resourcen, die bei der Bedienung des Dienstanfragers im Auftrag der Anfrage beteiligt sind, werden am Ende der Verarbeitung freigegeben. Jede Dienstanfrage initiiert eine Instanz (thread) der Dienstverarbeitung, und sorgt somit für eine leistungsfähige parallele Verarbeitung mit wenig Eventualitäten oder Nadelören.
Vorzugsweise unterhält jede Thread-Instanz eines Dienstes ihre eigene Ereignis-Queue mit einer Dienststeuerung, was für die asynchrone Kanalisierung von Ereignissen sorgt, die für einzelne Anrufinstanzen auf der Thread-Queue des Dienstes zur Speicherung und Ausführung empfangen wurden entsprechend einer vordefinierten, dem Ereignis zugeordneten Priorität. Die Dienststeuerung sorgt zusätzlich für die asynchrone Kanalisierung von Ereignissen an dem Switch/Ressourcenkomplex, oder andere ausführende logische Dienstprogramme, wobei die Thread-Instanz blockiert, solange sie auf eine Antwort wartet.
Gemäß der Erfindung umfassen die Hauptzuständigkeiten der Dienststeuerungskomponente: Annahme und Verarbeitung von Ereignissen oder Anfragen von einer Vermittlungsplattform oder anderen externen Ressourcen; Identifizierung und Aufruf von logischen Dienstprogrammen, um die eintreffende Anfrage zu verarbeiten; Anfordern von dienst- oder kundenbezogenen Daten von einem Datenmanagement-Speichergerät über ein Netzwerkbetriebssystem, (NOS) oder direkt über eine Programmschnittstelle zu einer Datenbankanwendung (API); Aktualisierung von dienst- oder kundenbezogenen Daten an eine Datenmanagementkomponente über ein NOS; Bereitstellen der Fähigkeit, priorisierte Ereignisse und Nachrichten an einen Ressourcenkomplex und andere logische Dienstprogramme zu senden, um die Benutzerinteraktion zu steuern; Empfangen von Nachrichtensätzen vom Ressourcenkomplex – einschließlich Benutzereingabe, wie z. B. PIN (Zweiklangmehrfrequenz) DTMF-Ziffern, die einem ausgewählten Menueeintrag entsprechen, etc.; Festhalten von Zuständen und Daten aller in die gleiche Dienstverarbeitungsinstanz eingebundenen Teilnehmer; und Erzeugen von Rechnungsdatensätzen und Übermittlung dieser an eine Rechnungsdatensatzerzeugungsfunktion der Datenmanagementkomponente.
Die verschiedenen Merkmale der Neuheit, welche die Erfindung charakterisieren, sind mit Sorgfalt in den angefügten und Teil der Offenbarung bildenden Ansprüche herausgestellt. Für ein besseres Verständnis der Erfindung, ihrer Vorteile beim Betrieb, und spezifischer durch ihre Benutzung erhaltene Objekte, sollten die Zeichnungen und Beschreibungen, in denen bevorzugte Ausführungsformen der Erfindung dargestellt und beschrieben werden, herangezogen werden. Die oben beschriebenen und weitere Vorteile der vorliegenden Erfindung mögen mit Verweis auf die folgenden Beschreibungen zusammen mit den begleitenden Zeichnungen besser verstanden werden, in denen:
1 eine logische Darstellung verschiedener Switching-Architekturen ist;
2 ein Diagramm eines Telekommunikationssystems ist, das eine typische Konfiguration mit einem intelligenten Netz, entsprechend dem Stand der Technik, benutzt;
3 ein Diagramm eines Telekommunikationssystems ist, das eine intelligente verteilte Netzarchitektur benutzt;
4(a) ein Blockdiagramm ist, das die SA- und DM-Komponenten des Next Generation Intelligent Network zeigt;
4(b) die Funktionalität der Dienstverwaltungskomponente 300 begrifflich illustriert;
4(c) die funktionelle Architektur der Datenmanagementkomponente 400 illustriert;
5 ein logisches und funktionelles Diagramm eines Telekommunikationssystems ist, das eine intelligente verteilte Netzwerkarchitektur gemäß der vorliegenden Erfindung verwendet;
6 ein Diagramm ist, das die Schichtung der funktionellen Schnittstellen innerhalb eines intelligenten Anrufprozessors gemäß der vorliegenden Erfindung illustriert;
7 ein Diagramm ist, das die Klassenhierarchie der verwalteten Objekte innerhalb eines intelligenten Anrufprozessors gemäß der vorliegenden Erfindung illustriert;
8 eine bevorzugte Architektur einer Servicesteuerungsumgebung 430 illustriert;
9 die funktionelle Architektur der NOS NT- und LRM-funktionellen Unterkomponenten illustriert;
10 die Architektur des Ressourcenmanagementsystems für das intelligente Netz illustriert;
11(a) und 11(b) die dreistufige Funktionalität des intelligenten Netzwerkressourcenmanagements darstellt;
12(a) den SLEE-Anlaufprozess illustriert;
12(b) den Servicemanagerprozess illustriert;
12(c) den SLEE-Klassenladerprozess illustriert;
12(d) und 12(e) Flussdiagramme, die die Serviceagentfunktionalität darstellen, illustriert;
12(f) den Threadmanagerprozess illustriert;
12(g) den Nachereignisprozess des Serviceagenten illustriert;
13(a)–13(c) einen Beispielprozessablauf für das Durchführen eines 1–800/8xx Anrufverarbeitungsdienstes darstellt;
14 das Anrufverarbeitungsszenario darstellt, so wie es von IDNA/NGIN bedient wird.
Die vorliegende Erfindung ist eine Komponente eines umfassenden intelligenten Netzwerks, die hier alternativ mit Intelligente Verteilte Netzwerkarchitektur ("IDNA") oder Intelligente Netze der nächsten Generation ("NGIN") bezeichnet werden. Wie hier beschrieben, ist die NGIN-Architektur dafür entwickelt, intelligente Anrufverarbeitungsdienste für jeglichen an einem Ressourcenkomplex oder einer Vermittlungsplattform, wie z. B. einem Switch, einem Router, einer IP-Endadresse, etc., empfangenen Anruftyp durchzuführen. Die IDNA bzw. das NGIN umfasst vorzugsweise eine Vielzahl von verteilten Dienstknoten, wobei jeder Knoten eine Ausführungsumgebung bereitstellt, die eine Anrufverarbeitungsfunktionalität, die für die Behandlung eines Anrufs an der Instanz, von der er am Switch oder Ressourcenkomplex empfangen wurde, dem dementsprechenden Serviceknoten physikalisch zugeordnet ist. NGIN ist eine hochskalierbare Architektur und derart konstruiert, dass sichergestellt ist, dass ausführbare Dienstobjekte, verkörpert durch unabhängige logische Dienstprogramme ("SLP"), und zugehörige Daten zum Ausführen von Ereignisdiensten, wie z. B. 1–800 Telefonanrufe, Faxsendungen, etc., an den Dienstknoten auf kosteneffektive Weise in Betrieb genommen und unterhalten werden können. Durch den Einsatz einer CORBA-konformen Object Request Broker-Technologie unterstützt das intelligente Netzwerk orts- und plattformunabhängige Dienstausführungen von Anrufverarbeitung, die unabhängig sind von und transparent für die Vermittlungsplattform oder den Ressourcennkomplex des Ereignisses, wo ein Ereignis oder ein Anruf empfangen wird, und ermöglicht es, dass logische Programme in einer hohen Programmiersprache praktisch überall im Netzwerk laufen können, unabhängig von der dienstausführenden Plattform. Darüber hinaus stellt das System ortsunabhängige Kommunikation dieser verteilten Prozesse untereinander bereit.
Mit Bezug auf 1 wird die intelligente, verteilte Netzarchitektur ("IDNA") generell mit 170 bezeichnet. Die vorliegende Erfindung vereint den ICC 160 und die Switch-Intelligenz 152 der SSUSF-Architektur 150 in einem intelligenten Anrufprozessor ("ICP") 172. Im Gegensatz zu den IN oder AIN der SSUSF-Architekturen 40, deren Funktionen in Zustandstabellen definiert sind, enthält der ICP 172 die Dienststeuerungsfunktionen 22, Anrufverarbeitungsfunktionen 24 und Anlagenverarbeitungsfunktionen 26 als verwaltete Objekte in einer objektorientierten Plattform, was durch die Blöcke 174, 176 und 178 symbolisch dargestellt wird. Der ICP 172 ist von dem Ressourcenkomplex 180 logisch getrennt.
Jetzt bezugnehmend auf 3, wird ein Telekommunikationssystem, das eine intelligente, verteilte Netzwerkarchitektur gemäß der vorliegenden Erfindung einsetzt, beschrieben und generell mit 200 bezeichnet. Das Wide Area Network ("WAN") 202 ist ein System, welches die Verteilung von Anwendungen und Daten über ein weites geographisches Gebiet unterstützt. Das Transportnetz basiert auf einem Synchronous Optical NETwork ("SONET") und verbindet die IDNA-Knoten 204 und ermöglicht es den Anwendungen innerhalb dieser Knoten miteinander zu kommunizieren.
Jeder IDNA-Knoten 204 enthält einen intelligenten Anrufprozessor ("ICP") 172 und einen Ressourcenkomplex 180 (1). 3 stellt einen IDNA-Knoten 204 mit einem Ressourcenkomplex A ("RCA") 206 und einen Ressourcenkomplex B ("RCB") 208 dar. Der ICP kann mit zusätzlichen Prozessoren 210 verbunden werden, welche existierende Supportfunktionen unterstützen, wie z. B. Bereitstellung, Rechnungsstellung und Wiederherstellung, wobei diese Funktionen allerdings durch die in einem Network Management System ("NMS") 212 zur Verfügung gestellte Funktionalität absorbiert werden können. In der bevorzugten Ausführungsform jedoch können diese Supportfunktionen durch ein zentralisiertes Dienstverwaltungs- ("SA") System 500 bereitgestellt werden, die eine Daten Management ("DM") Komponente 400 hat, welche im Zusammenhang mit 4(a) beschrieben wird. So wie weiterhin in 3 gezeigt, kann der ICP 172 auch mit anderen ICPs 172, anderen Netzwerken (nicht gezeigt) oder anderen Vorrichtungen (nicht gezeigt) über eine Direktverbindung 214 mit Zeichengabe 216 und Trägerverbindungen 218 verbunden sein. Eine Direktverbindung vermeidet Latenz zwischen den verbundenen Geräten und erlaubt es den Geräten, in ihrer eigenen Sprache zu kommunizieren. Der ICP 172 ist das "Gehirn" des IDNA-Knotens 204 und ist vorzugsweise ein Mehrzweckcomputer, der von einem Gerät mit einem einzelnen Prozessor und einem einzelnen Speicher bis hin zu einem Großcomputernetzwerk reichen kann, in Abhängigkeit von den Verarbeitungsanforderungen des IDNA-Knotens 204. Vorzugsweise hat der Mehrzweckcomputer redundante Verarbeitungs-, Speicher- und Verbindungseinheiten.
In diesem Text bezieht sich die Bezeichnung Mehrzweckcomputer auf Computer, die serienmäßig produzierte Komponenten sind, oder aus diesen zusammengesetzt werden können, im Gegensatz zu speziell für Telefonvermittlungsanwendungen konfigurierte und entwickelte Geräte. Die Integration von Mehrzweckcomputern im Fernsprechnetzwerk weist zahlreiche Vorteile auf.
Die Verwendung von Mehrzweckcomputern versieht den ICP 172 mit der Fähigkeit der Heraufskalierung mit zusätzlicher Hardware, um gestiegene Verarbeitungsbedürfnisse zu erfüllen. Diese Ergänzungen schließen die Fähigkeit zur Erhöhung der Verarbeitungsleistung, der Datenspeicherung und der Kommunikationsbandbreite ein. Diese Ergänzungen erfordern keine Modifikation der herstellerspezifischen Software und/oder Hardware in jedem Switch des Fernsprechnetzes. Folglich können neue Dienste und Protokolle in globalem Maßstab ohne Modifikation von einzelnen Geräten des Vermittlungsnetzes implementiert und installiert werden. Durch den Wechsel von monolithischen Switches 20 (1) zu intelligenten Anrufprozessoren 172, bietet die vorliegende Erfindung vorgenannte Vorteile und erhöhte Fähigkeiten.
Im Fall von Anwendungen, die mehr Verarbeitungsleistung benötigen, erlaubt der Mehrprozessorbetrieb die Benutzung von weniger teueren Prozessoren, um das Preis/Leistungsverhältnis für Anrufverarbeitung zu optimieren. Für andere Anwendungen kann es vorteilhaft, nötig oder kosteneffektiver sein, leistungsfähigere Maschinen, wie z. B. Minicomputer, mit höheren Verarbeitungsgeschwindigkeiten zu benutzen.
Der ICP 172 kann, wie oben erwähnt, eine Gruppe von Mehrzweckcomputern umfassen, die z. B. unter einem UNIX- oder Windows NT-Betriebssystem laufen. Beispielsweise kann der ICP 172 in einer großen Anwendung, die bis zu 100.000 Anschlüsse an einem einzelnen Ressourcenkomplex unterstützt aus sechzehn (16) 32-Bit-Prozessoren, die bei 333 MHz in einem symmetrischen Multi-Prozessoren-Cluster arbeiten, bestehen. Die Prozessoren könnten z. B. auf vier separate Server mit jeweils vier Prozessoren verteilt sein. Die einzelnen Prozessoren wären über ein System Area Network ("SAN") oder eine andere Clustering-Technologie verbunden. Der Prozessoren-Cluster könnte sich den Zugriff auf Redundant Array of Indenpendent Disks ("RAID")-modulare Datenspeichergeräte teilen. Gemeinsamer Speicher kann durch Hinzufügen oder Entfernen von modularen Plattenspeichergeräten angepasst werden. Die Server im Cluster würden sich vorzugsweise redundante Verbindungen mit dem RC 180 (1) teilen.
Wie dargestellt und wie die "plug and play"-Eigenschaft von Personal Computern, ist die ICP-Software-Architektur ein offenes Verarbeitungsmodell, das die Austauschbarkeit von folgenden unterstützt: (1) Verwaltungssoftware; (2) ICP-Anwendungen; (3) Rechner, Hardware und Software; (4) Ressowcenkomplex-Komponenten; und sogar (5) Dienstarchitektur und Verarbeitung. Eine solche generische Architektur reduziert Wartungskosten aufgrund Standardisierung und zieht Nutzen aus den größenbedingten Kosteneinsparungen.
Somit ermöglicht die vorliegende Erfindung die Unterteilung von Entwicklungsarbeit und die Benutzung von modularen Werkzeugen, die zu schnellerer Entwicklung und Implementierung von Diensten führen. Darüber hinaus sind die Benutzung und die relevanten Aspekte der Dienstverwaltung bedarfsgemäß in Reichweite der Steuerung des Netzbetreibers, im Gegensatz zu den durch feste Nachrichtenprotokolle oder eine bestimmte Kombination von durch einen gegebenen Hersteller gelieferter Hardware und Software auferlegten Einschränkungen.
Durch die Benutzung von verwalteten Objekten erlaubt es die vorliegende Erfindung auch, dass Dienste und Funktionen flexibel ("wo gewünscht") und dynamisch ("on the fly") über ein Netz verteilt werden, wobei eine Anzahl von Faktoren, wie z. B. Kapazität und Nutzung, zugrundegelegt werden. Die Leistungsfähigkeit wird verbessert, weil die Dienstverarbeitung 22 (1), die Anrufverarbeitung 24 (1) und die Anlagenverarbeitung 26 (1) in einer homogenen Plattform agieren. Zusätzlich erlaubt die vorliegende Erfindung die Über wachung und Manipulation von Unterelementen von Anruf, auf die vorher nicht zugegriffen werden konnte. Die vorliegende Erfindung stellt auch die Überwachung der Benutzung von Funktionen oder Diensten zur Verfügung, so dass diese eliminiert werden können, wenn sie veraltet oder unbenutzt sind.
Der Ressourcenkomplex ("RC") 180 (1) ist eine Sammlung von physikalischen Geräten, oder Ressourcen, die Träger-, Zeichengebungs- und Verbindungsdienste zur Verfügung stellen. Der RC 180, welcher Intelligent Peripherals 88 enthalten kann, ersetzt das Switching-Fabric 28 und 158 (1) der IN- oder AIN- oder SSI-/SF-Architektur. Im Gegensatz zu der IN- oder AIN-Architektur, findet die Steuerung des Ressourcenkomplex, wie z. B. RCA 206, auf einer niedrigeren Ebene statt. Darüber hinaus kann der RCA 206 mehr als ein Switching-Fabric 158 enthalten. Die Switching-Fabrics 158 oder andere Kundenschnittstellen (nicht gezeigt) werden über Standard-Fernsprechverbindungen mit mehreren Abonnenten und Vermittlungsnetzen verbunden. Diese Kundensysteme können ISDN-Endgeräte 52, Faxgeräte 220, Telefone 54 und Nebenstellenanlagen 222 enthalten. Der ICP 172 steuert und kommuniziert mit dem RC 180 (1), dem RCA 206 und RCB 208 über eine Hochgeschwindigkeits-Datenkommunikations-Pipe (mindestens 100 Mb/sec Ethernet-Verbindung) 224. Der RC 180, 206 und 208 können analog zu einem Print-Drucker und ICP 172 analog zu einem Personal Computer gesehen werden, wobei der Personal Computer einen Treiber benutzt, um den Drucker anzusteuern. Der "Treiber" im IDNA-Knoten 204 ist ein Ressourcenkomplex Proxy ("RCP") (nicht gezeigt), welcher weiter unten in Verbindung mit 5 beschrieben wird. Dies erlaubt es Herstellern, einen IDNA-konformen Knoten, der diese Schnittstelle benutzt, zur Verfügung zu stellen, ohne dass sie ihre gesamte Software für den Einbau des ID-NA-Modells neu schreiben müssen.
Zusätzlich findet die Steuerung des Ressourcenkomplexes 180 (1), RCA 206 und RCB 208 auf einer niedrigeren Ebene, als normalerweise durch die AIN- oder IN-Architektur bereitgestellt, statt. Daraus resultiert, dass Ressourcenkomplex-Hersteller nur eine einzelne Schnittstelle zur Verfügung stellen müssen, um Anlagen- und Netzwerkverwaltungsverarbeitung zu unterstützen; sie müssen dem Netzwerkbetreiber keine spezifische Anruf- und Dienstverarbeitung zur Verfügung stellen. Eine Schnittstelle auf niedriger Ebene wird durch diskretere Operationen abstrahiert. Mit nur einer Schnittstelle kann der Netzbetreiber von einem weiten Spektrum von Herstellern von Ressourcenkomplexen wählen, wobei die Ent scheidung auf der Grundlage von Preis und Leistung erfolgt. Intelligenz wird dem ICP 172 eher als dem RC 180 hinzugefügt, was den RC 180 von Änderungen isoliert und seine Komplexität verringert. Da die Rolle des RC 180 vereinfacht ist, sind Veränderungen einfacher durchzuführen, womit der Übergang zu alternativen Vermittlungs- und Übertragungstechnologien, wie z. B. dem Asynchronous Transfer Mode ("ATM"), vereinfacht wird.
Intelligente Peripherals ("IP") 88 stellen die Fähigkeit bereit, in dem eigentlichen Anrufübertragungspfad enthaltene Information zu verarbeiten und auf diese einzuwirken. IP's 88 sind im Allgemeinen in einem separaten Ressourcenkomplex, wie z. B. RCB 208 und werden durch die ICP's 172 in ähnlicher Weise wie der RCA 206 gesteuert. IP's können die Fähigkeit zur Verfügung stellen, Daten im eigentlichen Anrufubertragungspfad in Echtzeit mittels digitaler Signalverarbeitung ("DSP") zu verarbeiten.
Das Network Management System ("NMS") 212 wird zur Überwachung und Steuerung von Hardware und Diensten im IDNA-Netzwerk eingesetzt. Eine vorgeschlagene Implementierung des NMS 212 mag ein Telecommunications Management Network ("TMN")-konformer Rahmen, der die Verwaltung von Komponenten innerhalb des IDNA-Netzwerkes 200 bereitstellt, sein. Genauer steuert das NMS 212 die Inbetriebnahme von Diensten, sorgt für die Gesundheit dieser Dienste, stellt Informationen über die Dienste bereit, und stellt eine Managementfunktion auf Ebene des Netzwerks für das IDNA-Netzwerk 200 bereit. Das NMS 212 greift auf Dienste und Hardware über eine Agentenfunktionalität innerhalb des IDNA-Knotens 204 zu und steuert jene Dienste und Hardware. Der ICP-NMS-Agent (nicht gezeigt) innerhalb des IDNA-Knotens 204 führt die Befehle oder Anfragen aus, die von dem NMS 212 ausgingen. Das NMS 212 kann den RCA 206 und den RCB 208 direkt über eine Standardbetriebsverbindung 226 überwachen und steuern.
Wie weiterhin in 3 gezeigt, enthält die Umgebung zur Erzeugung verwalteter Objekte ("MOCE") 228 die Unterkomponenten zur Erzeugung von Diensten, die im IDNA-Netz 200 ablaufen. Ein dienstunabhängiger Baublock und eine API-Repräsentation, die ein Dienstentwickler zum Erzeugen neuer Dienste benutzt, sind innerhalb der primären Unterkomponenten der MOCE, einer graphischen Benutzeroberfläche ("GUI"), eingebettet. Die MOCE 228 ist eine vereinigte Sammlung von Werkzeugen, die auf einer Einzelbenutzerumgebung oder Plattform beheimatet sind, auch mit Service Creation ("SC")-Umgebung bezeichnet. Sie stellt die Sammlung von Operationen, die über den gesamten Prozess der Diensterzeugung benötigt werden, dar, wie z. B. Dienstdokumentation, Definition der verwalteten Objekte, Schnittstellendefinition, Protokolldefinition und Dateneingabedefinition, die in den verwalteten Objekten und im Test des Dienstes gekapselt sind. Der Netzbetreiber muß einen Dienst unter Benutzung der MOCE 228 nur einmal entwickeln, weil die verwalteten Objekte auf alle Knoten seines Netzes angewendet werden können. Dies unterscheidet sich von dem Netzbetreiber, der jeden der verschiedenen Switch-Hersteller eine eigene Version des Dienstes entwickeln lässt, was bedeutet, dass der Dienst mehrere Male entwickelt werden muss.
Die MOCE 228 und das NMS 212 sind miteinander über das Repository 230 verbunden. Das Repository 230 enthält die verwalteten Objekte, die durch das NMS 212 verteilt und im ID -NA/NGIN-Knoten 204 benutzt werden. Das Repository 230 stellt außerdem einen Puffer zwischen der MOCE 228 und dem NMS 212 bereit. Die MOCE 228 kann jedoch auch direkt mit dem NMS 212 verbunden werden, um das Netz "live" zu testen, was durch die gestrichelte Linie 232 angedeutet wird.
Gemäß der bevorzugten Ausführungsform der Erfindung, gezeigt in 4(a), enthält das IDNA/NGIN-System eine zentralisierte Dienstverwaltung, bzw. Service Administration ("SA")-Komponente 500, die sowohl eine Speicher-(Repository) 230 Funktionalität und eine generische Netzverwaltungs-(NMS) 212 Funktionalität des IDNA-Systems 170 zusammen mit zusätzlichen Fähigkeiten bereitstellt. Im Allgemeinen unterstützt die SA-Komponente 500 Offline-Speicherung, Benamung, Verteilung, Aktivierung und Entfernung aller Dienste und Daten vom IDNA/NGIN-System, wie in 4(a) gezeigt, und stellt zusätzlich eine Datenmanagement ("DM")-Funktion bereit, welche die Laufzeitspeicherung, Replikation, Synchronisation und Verfügbarkeit von Daten, die von den Dienstobjekten in IDNA/NGIN-Dienstknoten benutzt werden, ermöglicht.
Genauer, wie begrifflich in 4(b) gezeigt, ist die Dienstverwaltungskomponente 500 eine Komponente, die alle benötigte Funktionen ausführt zum Verwalten, Speichern und Verteilen jeglicher Dienste und Dienstedaten, die von den IDNA-Dienstverarbeitungsknoten benutzt werden, sowie zum Konfigurieren von sowohl der im System IDNA/NGIN implementierten Hardware- als auch Software-Komponenten. Allgemein, wie in 4(b) gezeigt, ist die SA-Komponente 500 verantwortlich für: Empfangen der Daten von der MOCE (Diensterzeu gung) 228, Empfangen von Kundenanweisungsdaten 502 vom Anweisungseingang und anderen vorhandenen Systemen 229, um das IDNA/NGIN-System zur Benutzung durch Kunden einzurichten; Absetzen von Daten, dienstunabhängigen Baublöcken ("SIBBs"), logischen Dienstprogrammen ("SLPs") und anderer logischer Dienstkomponenten 503, wie z. B. an die MOCE 200, so wie durch MOCE/SCE-Benutzer gefordert, z. B. während des Diensterzeugungsprozesses; Empfangen von vervollständigten und getesteten Dienstpaketen, SIBBs, SLPs oder anderen Dienstlogiken oder Datenkomponenten 506 von der MOCE 228; Zuteilen eindeutiger Namen an jede Dienstkomponente; und der Verteilung von Daten und jeder Dienstkomponente 509 an eine datenverwaltungsfunktionelle Komponente 600, die hierin später detaillierter beschrieben wird. Zusätzlich, wie in 4(a) gezeigt, unterhält die Serviceverwaltung 300 das Repository 230, welches eine globale Datenbank mit Datensätzen, bzw. Database of Record ("DBOR"), enthält, die alle IDNA-Dienste und Daten umfasst und von der die Datenverwaltungskomponente 600 all ihre Daten empfängt.
Weitere Verantwortlichkeiten der Dienstverwaltung umfassen: Aktivierung von Daten und Servicekomponenten 512, um sicherzustellen, dass sämtliche Daten, SIBBs und verwaltete Objekte oder logische Dienstprogramme SLPs für die Knoten mittels der Datenmanagementkomponente 600 verfügbar sind; Registrierung der Namen von Daten, SLPs und SIBBs 515 durch Zuführen ihrer logischen Namen an ein Netzwerkbetriebssystem, bzw. Network Operating System („NOS")-Komponente 700, die später im Detail beschrieben wird, für eine dortige Registrierung; Deaktivieren von Daten und Dienstkomponenten 518; und Entfernen von Daten und Diensten 521 aus dem IDNA/NGIN-System mittels der Datenmanagementkomponente 600. Die Serviceverwaltung führt zusätzlich eine Konfigurationsverwaltungsfunktion durch Mitführen des Zustands von jedem SIBB und Dienst (ungetestet, getestet, eingesetzt, etc.) zusätzlich zu der Versionierung durch ihren Namensgebungsprozess. Dies stellt sicher, dass ein Dienst nicht eingesetzt wird, bis alle Komponenten dieses Dienstes erfolgreich getestet und konfiguriert wurden.
Wie weiterhin in 4(b) gezeigt, führt die Dienstverwaltungskomponente 500 weiterhin die Funktion der Konfigurierung und Versorgung der IDNA/NGIN-Dienstknoten 204 gemäß der von der SA empfangenen Konfigurationsinformation durch. Insbesondere bestimmt die SA-Komponente 500 gestützt auf die empfangenen Konfigurationsinformationen die Fähigkeiten von jeder Komponente an jedem Dienstknoten 204, welche Dienste und Daten an wel che Knoten zu verteilen sind, welche Dienste auf welchem Server oder welchen Servern, die beim Dienstknoten angesiedelt sind, laufen werden, und welche Daten zwischengespeichert werden auf mit (dem) IDNA/NGIN-Knotenserver(n) assoziierten lokalen Speichern. Insbesondere verteilt die SA in Dienstprofil-(Konfigurations)-Dateien 580 enthaltene Konfigurationsregeln an einen (Knoten)-Ressourcen-Manager bzw. Local (node) Resource Manager („LRM") Komponente 575 des NOS-Systems 700 zur Speicherung in dem lokalen LRM-Zwischenspeicher, der an jedem Dienstknoten platziert ist. Diese Konfigurationsdateien 580 legen fest, welche Dienste an einem IDNA-Knoten ausgeführt werden. Der LRM liest zunächst diese Dienstprofildatei 580, die in dem lokalen Zwischenspeicher an dem Knoten gespeichert ist, und bestimmt eine spezifische Dienstebene in der Ausführungsumgebung („SLEE"), wie z. B. eine virtuelle Maschine, um den Dienst gemäß den Regeln der Dienstprofildatei auszuführen, und welche Dienste aktiv (als beständige Objekte) in der SLEE ausgeführt werden, oder nur auf Anfrage hin instantiiert werden.
Wieder auf 4(a) Bezug nehmend, fungiert die NGIN-Datenmanagementkomponente 600 sowohl als Dienstlebenszyklus-, als auch als Dienstbenutzungskapazität. So wie die Dienstverwaltungskomponente die globale Datenbank der Datensätze (Repository) unterhält, versorgt die Datenmanagementkomponente 600 jeden IDNA/NGIN-Dienstknoten mit lokalen Datenspeicherungs- und Datenmanagementfunktionen. Dies schließt alle Datentypen ein, wie: Dienstprogramme und SIBBs, Daten für Dienste (Kundenprofile, Telefonnummern, etc.), Multimediadateien (wie Audiodateien für interaktive Sprachantwort („IVR")-Dienste), etc.. Im Speziellen enthält die Datenmanagementkomponente 600 eines Dienstknotens einen Auszug aus dem globalen DBOR der SA mit allen benötigten Daten für die durch den lokalen NGIN-Dienstknoten auszuführenden Dienste, so, wie durch die Dienstverwaltung spezifiziert. Die Mechanismen davon werden mehr ins Detail gehend mit Bezug auf 4(c) beschrieben.
In der bevorzugten Ausführungsform stellt die Datenmanagementkomponente 600 der SA-Komponente lokale Datenspeicherungs- und Managementfunktionen für jeden IDNA/NGIN-Dienstknoten zur Verfügung. Insbesondere speichert das Datenmanagement die von der Dienstverwaltung empfangenen Daten in einer oder mehreren Datenbanken, und macht Dienste/Daten für die Dienstesteuerungsumgebung durch Zwischenspeichern der benötigten Daten auf einem in den Dienststeuerungscomputern residierendem Speicher, oder auf einem am gleichen Ort vorhandenen Datenbankserver bequem verfügbar, so dass Dienste/Daten für einen Dienstesteuerungsdienst mit minimaler Wartezeit verfügbar sind. Allgemeiner leistet die Datenmanagementkomponente 600 die Echtzeitspeicherung, Replikation, Synchronisation und Verfügbarkeit von Daten, unabhängig davon, ob diese von der Dienstverwaltung oder als Resultat der Dienstverarbeitung empfangen wurden. Diese DM-Funktionen mögen weiterhin eingeteilt werden in: 1) eine Daten-Repository-Funktion; 2) eine Datenmanipulationsfunktion; 3) eine Datenhilfsprogrammfunktion; und 4) eine Rechnungsdatensatzerzeugungs-Funktion.
Jetzt bezugnehmend auf 5 wird ein logisches und funktionelles Diagramm eines Telekommunikationssystems, das eine intelligente, verteilte Netzarchitektur 200 gemäß der vorliegenden Erfindung verwendet, beschrieben. Der ICP 172 ist als einen ICP-NMS-Agenten 240 und eine SLEE 242 enthaltend gezeigt, welche ihrerseits eine Vielzahl von verwalteten Objekten 246, 248, 250 und 252, die aus der Basisklasse 244 der verwalteten Objekte abgeleitet sind.
Generell sind verwaltete Objekte eine Methode zum Verpacken von Softwarefunktionen, wobei jedes verwaltete Objekt sowohl funktionelle als auch Verwaltungsschnittstellen zur Implementierung der Funktionen des verwalteten Objektes anbietet. Die Verwaltungsschnittstelle steuert den Zugriff bezüglich wer und was auf die Funktionen des verwalteten Objekts Zugriff hat. In der vorliegenden Erfindung ist die gesamte Fernsprechanwendungssoftware, außer der Infrastruktursoftware, die auf den IDNA/NGIN-Knoten 204 läuft, als verwaltete Objekte und unterstützende Bibliotheken verteilt. Dies stellt eine einheitliche Schnittstelle und Implementierung zur Kontrolle und Verwaltung der IDNA-Knotensoftware bereit.
Die Sammlung der Netzwerkelemente, die den von dem Knoten behandelten Trägerverkehr verbinden, routen und beenden, werden gemeinsam als der Ressourcenkomplex („RC") 180 bezeichnet. Die auf der SLEE auflaufenden dienstverarbeitenden Anwendungen benutzen den Ressourcen-Proxy („RCP") 244 als eine Steuerungsschnittstelle zum RC 180. Der RCP 244 kann mit einem Gerätetreiber verglichen werden, dahingehend, dass er geräteunabhängige Befehle von Objekten in der SLEE auf gerätespezifische Befehle, die vom RC 180 ausgeführt werden, umsetzt. Der RCP 242 (??? 244) kann als eine Schnittstelle beschrieben werden, die die grundlegenden Befehle, die bei allen Anbietern von Ressourcen gleich sind, im RCP 244 implementiert. Der RCP 244 kann wie gezeigt als eines oder mehrere verwaltete Objekte, die auf einem IDNA-Knoten 204 ablaufen, implementiert werden. Alternativ könnte diese Funktion als Teil des RC 180 bereitgestellt werden. Das NMS 212, das Repository 230 und die MOCE 228 stimmen mit den Beschreibungen dieser Elemente während der Diskussion der 3–5(a) überein.
Man beachte, dass die Betriebsverbindung 226 das NMS 212 direkt mit dem RC 180 verbindet. Dies entspricht der traditionelleren Rolle eines Netzwerkverwaltungssystems, bei dem es um die Überwachung des Betriebszustands der Netzwerk-Hardware geht. Dies kann unabhängig von der IDNA-Architektur getan werden (z. B. durch Benutzen des bekannten TMN-Ansatzes). Zusätzlich kann der RC 180 mit anderen Ressourcenkomplexen 254 verbunden werden. Eine direkte Zeichengabeverbindung 214 ist ebenso als in den ICP 172 hineingehend gezeigt, so dass die Zeichengabe 216, wie SS7, die Anrufverarbeitungsumgebung direkt erreichen kann. Durch Abfangen der Zeichengabe an der Netzwerkperipherie kann die SS7-Nachricht direkt zum ICP 172 gehen, ohne durch den RC 180 zu gehen. Dies reduziert die Wartezeit und verbessert die Robustheit durch Verkürzung des Zeichengabepfads. Eine begleitende Trägerleitung 218 ist mit dem RC 180 verbunden.
6 stellt die Schichten der funktionellen Schnittstellen innerhalb des ICP 172 dar. Die MOCE 228 ist das System, wo die Software der verwalteten Objekte und ihre Abhängigkeiten erzeugt werden. Das NMS 212 steuert die Ausführung des ICP 172 durch Ansteuern einer innerhalb des ICP 172 bereitgestellten Agentenfunktion über die Schnittstelle, wobei diese Funktion ICP-NMS-Agent 240 genannt wird. Das NMS 212 steuert den Betrieb des lokalen Betriebssystems („LOS") 260 auf dem ICP 172. Das NMS 212 steuert den Betrieb des ICP 172 einschließlich dem Starten und Stoppen von Prozessen, Abfragen der Inhalte der Prozesstabelle, und den Zustand der Prozesse, Konfiguration der Betriebssystemparameter und der Überwachung der Leistung des Mehrzweckcomputersystems, welcher den IPC 172 beherbergt.
Das NMS 212 steuert auch den Betrieb des Wide Area Network Betriebssystems („WA-NOS") 262. Das NMS 212 steuert die Initialisierung und den Betrieb der WANOS Hilfsprozesse und die Konfiguration der WANOS-Bibliotheken über seine Steuerung des LOS 260 und jegliche andere von der NMS SLEE-Steuerung bereitgestellte Schnittstellen. Das NMS 212 steuert die Instantiierung und den Betrieb einer SLEE oder mehrerer SLEE's 242, die auf dem ICP 172 ablaufen. Das LOS 260 ist ein kommerzielles, weit verbreitetes Betriebssystem zum Betrieb des Mehrzweckcomputers. Das WANOS 262 ist ein kommerzielles, weit verbreitetes Middle-Ware-Software-Paket (z. B. ein Object Request Broker), das die nahtlose Kommunikation zwischen Rechnerknoten erleichtert. Die SLEE 272 beherbergt die Ausführung von verwalteten Objekten 244, welche Softwareinstanzen sind, die die Dienstverarbeitungsarchitektur implementieren. Die SLEE 242 implementiert die Mittel zur Steuerung der Ausführung von verwalteten Objekten 244 durch den ICP-NMS-Agent 240. Somit ist eine SLEE 242 Instanz ein Softwareprozess, der fähig ist, verteilte Objektsoftware zu verteilen und zu entfernen, verwaltete Objektinstanzen zu instantiieren und zu zerstören, die Interaktion und Zusammenarbeit von verwalteten Objekten zu unterstützen, Zugriff auf Herstellerbibliotheken 264 zu regeln und Austausch über die Schnittstelle mit den NMS-ICP-Agent 240 durch Implementierung der benötigten Steuerungen durchzuführen.
Die Herstellerbibliotheken 264 sind Bibliotheken, die so programmiert sind, dass sie nur von dem LOS 260 oder dem WANOS 262 und der durch den Netzwerk-Computer vorgegebenen Ausführung (z. B. kompilierte C-Bibliotheken) abhängen. Sie werden hauptsächlich benutzt, um die ursprünglich von der SLEE 242 bereitgestellten Funktionen zu erweitern.
SLEE-Bibliotheken 266 sind Bibliotheken, die zur Ausführung in der SLEE 242 programmiert sind. Sie können auf die von der SLEE 242 und den Hersteller-Bibliotheken 264 bereitgestellten Funktionen zugreifen. Die verwalteten Objekte 244 sind Software, die von der SLEE 242 geladen und ausgeführt werden. Sie können auf die von der SLEE 242 und den SLEE-Bibliotheken 266 (und möglicherweise den Hersteller-Bibliotheken 264) bereitgestellte Funktionalität zugreifen.
Der ICP-NMS-Agent 240 stellt für das NMS 212 die Fähigkeit zur Steuerung des Betriebs des ICP 172 bereit. Der ICP-NMS-Agent 240 implementiert die Fähigkeit, den Betrieb und die Konfiguration des LOS 260, den Betrieb und die Konfiguration des WANOS 262 und die Instantiierung und den Betrieb der SLEE(s) 242 zu steuern. Die vorgeschlagene Dienstverarbeitungsarchitektur arbeitet mit Schichten wachsender Abstraktion. Aus der Perspektive der SLEE 242 jedoch gibt es nur zwei Schichten: die Schicht der verwalteten Objekte 244, welche die Schicht von Objekten (Softwareinstanzen) ist, die unter der Kontrolle des NMS 212 interagieren; und die Bibliotheksschicht 264 oder 266, welche die Schicht der Software (entweder SLEE 242 eigen oder LOS 260 eigen) ist, die den Betrieb der verwalteten Objekte 242 244) oder der SLEE 242 selber mit ergänzenden Funktionen versorgt. Es ist jedoch vorgesehen, dass zu einem Zeitpunkt das NMS 212 die Kontrolle über den exakten Ort von verwalteten Objektinstanzen ausgibt. Zum Beispiel kann es verwalteten Objektinstanzen erlaubt werden, von einem Knoten zum nächsten zu wandern, auf der Grundlage eines oder mehrere Algorithmen oder Ereignissen, so wie zum Beispiel als Reaktion auf Nachfrage.
Es sollte verstanden werden, dass die LOS- und WANOS-Funktionalität zusammen als ein Netzwerkbetriebssystems oder „NOS" dargestellt werden kann, wie in 6 gezeigt, das zum Bereitstellen von plattformunabhängigen und ortsunabhängigen Netzwerkverbindungen zwischen den IDNA/NGIN-Systemkomponenten fungiert. Das heißt, das NOS umfasst einen Satz von netzwerkweiten Diensten, der Prozessschnittstellen und Kommunikation innerhalb der anderen IDNA/NGIN-funktionellen Komponenten und Unterkomponenten bereitstellt. Unter den vom NOS bereitgestellten Diensten sind Objektkonnektivität, Übersetzung logischer Namen, Interprozesskommunikation und lokales und systemweites Ressourcen-Management („RM"). Wie zum Beispiel in 4(a) gezeigt, stellt die NOS-Komponente 700 die lokale (NODE RM) und systemweite Ressourcen-Management (SYS RM)-Funktion bereit. Insbesondere kapselt die NOS-Komponente den Ort von irgendeinem Dienst von den Prozessen, die Dienste und Daten benötigen, so dass ein Prozess nur einen einzelnen logischen Namen aufrufen muss. Die NOS-Komponente legt sodann fest, welche Instanz eines Dienstes zu benutzen ist, und stellt die Verbindung mit dieser Instanz her. Das NOS 700 ermöglicht zum Teil sowohl den weitverteilten Charakter von IDNA/NGIN als auch die Plattformunabhängigkeit von IDNA/NGIN. Zum Beispiel benutzen oben erwähnte logische Programme die NOS-Komponente 700 zum Aufruf anderer logischer Programme und können daher andere logische Programme, die auf unterschiedlichen SLEEs ablaufen, in entweder dem gleichen Dienstknoten oder einem entfernten Dienstknoten aufrufen. Insbesondere kann ein Dienstknoten durch die SA 500 zur Ausführung von nur bestimmten Diensten spezifiziert werden. Wenn ein Anruf an einem Switch mit einem zugeordneten Dienstknoten 204 ankommt, für den der benötigte Dienst nicht durchgeführt werden kann, z. B. Teilnahme an einer Konferenzbrücke, muss die IDNA den Anruf eventuell an einem anderen Knoten, der für die Bereitstellung eines solchen Dienstes konfiguriert ist, weiterleiten. Vorzugsweise wird die IDNA mittels der NOS-Komponente 700 den benötigten Dienst an einem anderen entfernten Dienstknoten aufrufen, die Anrufverarbeitung durchführen und eine Dienstantwort an den Switch des ursprünglichen Knotens bereitstellen.
Nun mit Bezug auf 7 wird die Klassenhierarchie der verwalteten Objekte gemäß der vorliegenden Erfindung beschrieben. Die abstrakte Basisklasse für verwaltete Objekte 244 enthält eine gewöhnliche Funktionalität und virtuelle Funktionen, um sicherzustellen, dass alle abgeleiteten Klassen korrekt als Objekte in der SLEE 242 unterstützt werden. Es werden speziell vier unterschiedliche Unterklassen gezeigt, die Dienststeuerungsklasse 252, die Anrufsteuerungsklasse 250, die Trägersteuerungsklasse 248 und die Ressourcen-Proxy-Klasse 246.
Die Dienststeuerungsklasse 252 ist die Basisklasse für alle Dienstfunktionenobjekte. Die Session-Manager-Klasse 280 kapselt session-bezogene Informationen und Aktivitäten. Eine Session kann einen oder mehrere Anrufe oder andere Aufrufe von Netzwerkfunktionen umfassen. Die Session-Manager-Klasse 280 stellt eine eindeutige Identifizierung für jede Session bereit. Wenn Anrufverarbeitung in knotenbezogener Weise stattfindet, müssen Rechnungsinformationen zusammengetragen werden. Eine eindeutige Identifizierung für jeden Anruf macht das Zusammentragen einfach, anstelle einer benötigten, aufwändigen Korrelationsverarbeitung. Bei der Dienstverarbeitung werden Protokolle durch aufeinanderfolgende Schichten der Abstraktion eingehüllt. Schließlich ist das Protokoll genügend abstrahiert, um die Allokation/Instantiierung eines Session-Managers zu gewähren (z. B. würde bei SS7 der Empfang einer IAM-Nachricht das Verfügen über ein Session-Management gewährleisten).
Die Trägerfähigkeitsklasse 282 wechselt die Servicequalität mit Rücksicht auf den Träger. Eine Dienststeuerungsklasse 252 kann Veränderungen in der Servicequalität, bzw. Quality-of-Service („QoS") eines Anrufs ermöglichen oder sogar die Trägerfähigkeit verändern, wie ein Wechsel von 56 Kbit/s zu einer höheren Rate und dann zurück. Die Die QoS wird von der Verbindungsmanagerklasse 302 verwaltet. Zum Beispiel stuft eine Halbe-Übertragungsraten-Unterklasse 284 die QoS eines Anrufs auf eine 4 Khz-Abtastrate herunter, anstelle der üblichen 8 Khz-Abtastrate. Eine Stereounterklasse 286 mag einem Benutzer den Aufbau von zwei Verbindungen innerhalb eines Anrufs zur Unterstützung von linkem und rechtem Kanal erlauben.
Die Dienstentscheidungsklasse 288 regelt die Vermittlung von Dienstkonflikten und Dienstinteraktionen. Dies wird benötigt, weil Dienstkontrollklassen 252 in Konflikt geraten können, insbesondere von Herkunfts- und Anrufszieldiensten. Aus vielen praktischen Gründen ist es unerwünscht, innerhalb jeder Dienstkontrollklasse 252 die Kenntnis über das Auflösen von Konflikten mit jedem anderen Typ der Dienstkontrollklasse 252 zu programmieren. Anstelle werden bei Identifikation eines Konfliktes Verweise auf die im Konflikt stehenden Dienste und deren anhängigen Anfragen an die Dienstvermittlungsklasse 288 übergeben. Die Dienstvermittlungsklasse 288 mag dann über den geeigneten Ablauf von Aktionen entscheiden, wobei unter Umständen der lokale Zusammenhang, Konfigurationsdaten und noch ausstehende Aufrufe der in Konflikt stehenden Dienstobjekte berücksichtigt werden. Das Vorhandensein einer Dienstvermittlungsklasse 288 erlaubt die explizite Dokumentation und Programmierung von Konfliktlösungs-Algorithmen im Gegensatz zu entweder hart-codierten oder impliziten Mechanismen. Ferner müssen die existierenden Dienste bei Aktualisierung oder Hinzufügen eines Dienstes nicht aktualisiert werden, um jegliche Konfliktänderungen zu berücksichtigen, was das Ändern von Mehrfachbeziehungen innerhalb eines einzelnen Dienstes erfordern könnte.
Die Eigenschaftsklasse 290 implementiert den Standardsatz von mit Fernsprechen verbundenen Fähigkeiten (z. B. 3-Wege-Anruf, Anklopfen). Eine solche Fähigkeit kann eine Übernahme 292 sein, um es einem Ausgangspunkt zu ermöglichen, einen vorhandenen Anruf zu trennen, um einen beabsichtigten Empfänger zu erreichen. Eine weitere gängige Fähigkeit kann einen Anrufblock 294 einschließen, wobei ein Herkunftsangebot auf der Grundlage eines Satzes von Kriterien über die Herkunft zurückgewiesen werden kann.
Die Dienstunterscheidungsklasse 296 wird benutzt, um selektiv andere Dienste während der Anrufverarbeitung aufzurufen und ist selbst als ein Dienst klassifiziert. Die Dienstunterscheidungsklasse 296 stellt eine flexible, kontextsensitive Dienstaktivierung bereit und beugt dem Bedarf vor, fixen Quellcode innerhalb jedes Dienstobjektes zu haben, wann ein Dienst aktiviert werden soll. Die Aktivierungssequenz ist vom Dienst selber isoliert. In einem Beispiel haben Abonnent A und Abonnent B Zugriff auf denselben Satz von Funktionen. Abonnent A entscheidet sich selektiv eine oder mehrere seiner Dienste mittels eines bestimmten Satzes von Signalen aufzurufen. Abonnent B zieht die Benutzung eines unterschiedlichen Satzes von Signalen zur Aktivierung seiner Dienste vor. Der einzige Unterschied zwischen den Abon nenten ist die Weise, auf die sie ihre Dienste aktivieren. Daher ist es wünschenswert, den Auswahlprozess vom Dienst selber abzutrennen. Hierfür gibt es zwei Lösungen. Der Dienstauswahlprozess für die Abonnenten A und B kann in getrennten Dienstunterscheidungsklassen 296 programmiert sein, oder eine Dienstunterscheidungsklasse 296 kann pro Abonnent ein Profil benutzen, um die geeignete Information anzugeben. Dies kann auf die Anwendung für mehr Benutzer generalisiert werden, deren Dienstsätze nicht zusammenhängend sind. Weiterhin kann die Benutzung einer Dienstunterscheidungsklasse 296 die Abbildung von Zugriff auf Dienste auf Grundlage des Kontexts oder des Fortschritts eines gegebenen Anrufs verändern. Die Implementierung dieser Klasse erlaubt es verschiedenen Anrufteilnehmern, unterschiedliche Dienste zu aktivieren, unter Umständen durch Benutzung unterschiedlicher Aktivierungseingaben. Im Stand der Technik lieferten alle Switch-Lieferanten unflexible Dienstauswahlschemata, welche diese Fähigkeit verhinderten.
Die medienunabhängige Dienstklasse 298 ist ein Typ der Dienststeuerungsklasse 252, wie Speichern und Weiterleiten 300, Rundsenders, Umleitung, Vorrang, Dienstqualität, bzw. QoS, und Mehrparteienverbindungen, die sich auf unterschiedliche Medientypen inklusive Sprache, Fax, e-mail und andere anwenden lässt. Wenn eine Dienststeuerungsklasse 252 entwickelt wird, die auf jeden Medientyp angewendet werden kann, kann die Dienststeuerungsklasse 252 in wiederbenutzbare Dienststeuerungsklassen 252 unterteilt werden. Die Dienststeuerungsklasse 252 ist unterteilt in medienabhängige Funktionen und medienunabhängige Funktionen (wie z. B. einen medienunabhängigen SC, der einen Dienst implementiert und einen Satz von medienabhängigen Hüll-SC's – einer pro Medientyp). Da von der medienunabhängigen Klasse 298 abgeleitet, stellen Speichern und Weiterleitung 300 die generischen Fähigkeiten zum Speichern einer Nachricht oder eines Datenstroms irgendeines Medientyps und dann die Fähigkeit, diese oder diesen später auf Grundlage irgendeines Ereignisses zuzustellen. Umleiten stellt die Fähigkeit bereit, eine Verbindung von einer logischen Adresse zu einer anderen auf Grundlage von festgelegten Bedingungen zu verschieben. Dieses Konzept ist die Basis für Anrufweiterleitung (alle Typen), ACD/UCD (automatische Anrufverteilung), WATS (1–800-Dienste), Finde-mich/Folge-mir und mobiles Roaming etc.. Vorrang, entweder durch Verhandeln oder auf andere Weise, schließt Dienste, wie Anklopfen, Prioritätsvorrang, etc. ein. QoSmodulierte Verbindungen implementieren zukünftige Dienste über Paketnetze, wie Sprache/Fax, Streaming Video und Dateiübertragung. Mehrparteienverbindungen schließen Drei-Wege- und N-Wege-Videokonferenzen, etc. ein. Obwohl Benutzerbedienung und -eingabe hauptsächlich mittels der Tasten auf einem Telefon implementiert wird, wird erwartet, dass Spracherkennung zukünftig für die Benutzerbedienung und -eingabe benutzt wird.
Die Verbindungsmanagerklasse 302 ist verantwortlich für die Koordinierung und das Schlichten von Verbindungen der verschiedenen Trägersteuerungen 248, die an einem Anruf beteiligt sind. Somit ist die Komplexität des Verwaltens der Konnektivität zwischen Parteien in Mehrfachanrufen gekapselt und aus allen anderen Diensten entfernt. Dienst- und Anrufverarbeitung sind von den Verbindungen entkoppelt. Dies bricht mit dem Schema der Abbildung von Anrufen zu Verbindungen als eins zu viele (l : n). Jetzt steht die Abbildung von Anrufen zu Anrufen im Verhältnis viele zu viele (n : n).
Die Verbindungs-Managerklassen 302 innerhalb einer Architektur sind für den Alleinbetrieb oder die Zusammenarbeit unter ihresgleichen ausgelegt. Im Betrieb präsentieren die Dienststeuerungsklassen 252 den Verbindungs-Managerklassen 302 Anfragen zum Hinzufügen, Modifizieren und Entfernen von Anrufsegmenten. Es liegt in der Verantwortung der Verbindungsmanagerklasse 302, diese Änderungen durchzuführen. Bemerkung: da Verbindungen entweder als Ressourcen in und von ihren selbst oder als die Attribute von Ressourcen betrachtet werden können, kann eine Verbindungsmanagerklasse 302 als ein Proxy oder ein Aspekt von grundlegenden Ressourcen-Managementfunktionen implementiert werden.
Die Anrufsteuerungsklasse 250 implementiert die notwendige Anrufverarbeitung, wie den grundlegenden endlichen Zustandsautomat, der gewöhnlich in der Fernsprechtechnik benutzt wird, und spezifiziert, wie die Anrufverarbeitung stattzufinden hat. Zwei Klassen können abgeleitet werden gemäß der funktionellen Unterteilung in Herkunft (Anruf) 304 und Ziel (Anrufannahme) 306.
Die Trägersteuerungsklasse 248 ist ausgelegt auf das Anpassen von spezifischen Zeichengaben und Ereignissen vom und an den Ressourcenkomplex 180, mittels des Ressourcen-Proxy 246 in gewöhnliche Zeichengaben und Ereignisse, die von den Anrufsteuerungsobjekten 250 verstanden werden können. Eine erwartete Rolle eines von dieser Klasse abgeleiteten Objekts ist die Sammlung von Informationen über das Herkunftsende eines Anrufs, wie der Abonnententelefonnummer, der Klasse des Dienstes, des Zugriffstyps, etc. Unterklassen können aufgrund der Anzahl von Schaltkreisen oder Kanälen, die mit der Zeichengabe zusammen hängen, unterschieden werden. Dies mag eine kanalbezogene Klasse 308 einschließen, so wie dies auf dem einzelnen Zeichengabekanal pro 23 Trägerkanäle in einer ISDN-Primärschnittstelle 310, eine Einzelkanalklasse 312, wie durch ein analoges Telefon 314 typifiziert, was Wähltöne/-Impulse zur Steuerung eines einzelnen Schaltkreises benutzt, und die allgemeine Kanalklasse 316, repräsentiert durch die SS7-Zeichengabe 318, die sämtlich von Trägerkanälen getrennt ist.
Die Ressourcen-Proxy-Klasse 246 ist der Bereitstellung einer Schnittstelle der Ausführungsumgebung zu realen Switches und anderen Elementen des Trägernetzwerks gewidmet. Beispiele interner Zustände, die auf dieser Ebene implementiert sind, und die von allen abstammenden Klasse geerbt werden, sind betriebsbereit im Gegensatz zu außer Betrieb und frei im Gegensatz zu in Benutzung. In Erwägung gezogene abgeleitete Klassen sind Telefon 320 (ein Standard-Proxy für ein Standard-2500-Gerät), Sprachantworteinheiten („VRUs") 322 (ein Standard-Proxy für Sprachantworteinheiten), IMT-Stammverbindungen 324 (ein Standard-Proxy für digitale Stamm (T1/E1)-Schaltungen, und Modemverbindungen 326 (ein Standard-Proxy für digitale Modems), die bezüglich den Typen von Ressourcen im Ressourcenkomplex 180 entsprechen. Eine bevorzugte Weise, in der eine Dienststeuerungskomponente hereinkommende Dienstanfragen bedienen mag, wird nun mit weiterem Bezug auf 10 beschrieben, die insbesondere eine andere Ausführungsform einer Dienststeuerungsumgebung 134 bescheibt mit SLEE-Anwendungen 450, 450', die innerhalb des Betriebssystems 435 eines Dienststeuerungsservers, wie einem Mehrzweckcomputer 440, ausgeführt werden.
Wie in 8 gezeigt, ist die SLEE 450 eine Java^TM „virtuelle Maschine", die darauf ausgerichtet ist, wenigstens fünf Typen von logischen Programmen (Objekten), die zur Ausführung von Anrufverarbeitungsdiensten und anderen unterstützenden Diensten implementiert sind, auszuführen: 1) Logische Merkmalsunterscheidungsprogramme („FD") 510, welche funktionelle Unterkomponenten der Dienststeuerungsklasse/Dienstunterscheidungsklasse 296 ( 7) sind, die als erste eine Dienstanfrage von einer Vermittlungsplattform empfangen, aufgrund einiger verfügbarer Kriterien, wie z. B. der gewählten Nummer des Anrufs, entscheiden, welcher Dienst auf einem Anruf ausgeführt wird, und dann ein anderes geeignetes logisches Dienstprogramm zur Verarbeitung des Anrufs aufruft; 2) die logischen Dienstprogramm („SLP")-Objekte 520, die funktionelle Subkomponenten der Dienststeuerungsklasse 252 ( 7) sind, die die Dienstverarbeitung für eine empfangene Dienstanfrage oder ein Ereignis leisten; 3) logische Leitungsprogramm („LLP")-Objekte 530, die funktionelle Subkomponenten der Anrufsteuerungsklasse 250 (7) sind, die den aktuellen Zustand der Netzwerkzugangsleitung behalten; 4) logische Ereignisprogramme („ELP")-Objekte 540, die funktionelle Subkomponenten der Dienststeuerungs/Session-Managerklasse 260 (7) sind, an die alle anderen logischen Programme Ereignisse schreiben; und 5) logische Anrufprogramm („CLP")-Objekte 545, die funktionelle Subkomponenten der Dienststeuerungs/Verbindungsmanagerklasse 203 (7) sind, die den Zustand eines gesandten Anrufs durch Bereitstellen eines Verbindungspunktes für alle anderen logischen Programme, die an der Verarbeitung eines Anrufs beteiligt sind, behält. Jedes dieser logischen Programme ist durch Software-„Objekte" verkörpert, die vorzugsweise in der Java-Programmiersprache beschrieben sind, welche entweder zeitweise instantiiert oder dauerhaft sein können, wie später beschrieben wird. Die IDNA/NGIN-Dienststeuerungs-Architektur ist so ausgelegt, dass diese Objekte nur einmal in den MOCE/SCE geschrieben werden, und auf einem SLEE auf jeglichem Computertyp und auf jeglichem Betriebssystemtyp irgendwo im Netzwerk eingesetzt werden können.
Mit größerer Genauigkeit ist der FD 510 eine statische Subkomponente, die 1) zunächst eine Dienstanfrage von einem Ressourcenkomplex empfängt, wie z. B. einem Switch, wenn der Switch feststellt, dass der Dienst durch die IDNA/NGIN verarbeitet wird; 2) analysiert die mit der Dienstanfrage zusammenhängende Information; und 3) bestimmt welcher SLP zur Verarbeitung der Dienstanfrage fähig ist. Vorzugsweise mag der FD eine Systemaufgabe oder ein instantiiertes Objekt für den Empfang von durch den Ressourcenkomplex bereitgestellten Daten sein, wobei die Daten einschließen, aber nicht beschränkt sind auf die angerufene Nummer, die rufende Nummer, das Herkunfts-Ortsnetz, Informationen über die Herkunftsleitung und die ID des Netzwerkanrufs. Über das NOS initiiert der FD 510 die Instantiierung des geeigneten SLP, des CLP und des Herkunfts-LLP, um den Anruf zu verarbeiten. Vorzugsweise ist der FD ein dauerhaftes Objekt, der nicht an einen speziellen Anruf oder ein Ereignis gebunden ist, und läuft ständig aktiv in der Dienststeuerungs-SLEE 450 ab. In Abhängigkeit von der Komplexität der ausgeführten Analyse und dem Anfragevolumen an den FD, mögen eine oder mehrere Instanzen des FDs aktiv in einer Dienststeuerungs-SLEE 450 ablaufen, um die Last aufzuteilen und Echtzeiteffizienz zu garantieren. Zum Beispiel mag ein FD zur Analyse von empfangenen SS7-Nachrichtendaten benutzt werden, während ein anderer FD zur Analyse von ATM-Nachrichtendaten benutzt wird.
Das logische Leitungsprogramm (LLP) 530 ist die funktionelle Subkomponente, die: 1) den aktuellen Zustand eines Netzwerkzugangs, einer Verbindung oder Leitung behält; 2) das Datenmanagement nach dem physikalischen Punkt, der Verbindung oder Leitung zugeordneten Merkmalen abfragt; und 3) diese Merkmale anwendet, wie Anruftrennung, Anklopfen, Anrufweiterleitung und overflow routing, so wie es die Anrufsituation verlangt. Es gibt einen der Herkunftsleitung des Anrufs zugeordneten LLP, im Nachfolgenden „LLPO", und einen einer Punktverbindung oder der Zielleitung des Anrufs zugeordneten LLP, im Nachfolgenden „LLPT". Wenn eine Instanz eines logischen Leitungsprogrammes intantiiert ist, registriert es sich selbstständig mit der Switching Fabrik. Wie später beschrieben wird, sendet das logische Leitungsprogramm 530 alle ereignisbezogenen Daten an die ELP-Subkomponente der gleichen Instanz der Dienstverarbeitung.
Dynamische Subkomponenten sind solche Komponente, die gemäß unterschiedlicher Stadien der Dienstverarbeitung dynamisch konstruiert werden, und welche zerstört werden, wenn eine Instanz der Dienstverarbeitung vollständig ist, und schließen ein: logische Ereignisprogramme, bzw. Event Logic Programs (ELP); logische Anrufprogramme, bzw. Call Logic Programs (CLP); und logische Dienstprogramme, bzw. Service Logic Programs (SLP).
Das logische Ereignisprogramm (ELP) 540 ist die funktionelle Subkomponente, die zum Behalten der Echtzeitereignisdaten, die während der Dienstverarbeitung erzeugt werden, benutzt wird und zeichnet alle Ereignisdaten auf, die während der Ausführung eines Dienstes auftreten. Das logische Ereignisprogramm wird vorzugsweise instantiiert durch den Anrufsteuerungsprozess beim Switch, wenn ein Ereignis zum ersten Mal empfangen wird. Wenn der Switch eine Dienstanfrage an das NGIN sendet, fügt er die Adresse des ELP dieser Anfrage bei, so dass Ereignisdaten an dieses mit dem Anruf verbundene logische Programm gesendet werden mögen. Auf das logische Ereignisprogramm haben alle Subkomponenten innerhalb der gleichen Instanz der Dienstverarbeitung, d. h. das CLP, das LLP und das SLP, die zu diesem Anruf gehören, Zugriff. Während jede Dienstverarbeitungskomponente im Zuge der Abarbeitung eines Dienstes diesen Anruf verarbeitet, schreibt sie Ereignisdaten an das ELP, über das NOS, gemäß vorher festgelegten Regeln. Bei Beendigung eines Anrufs werden die Ereignisdaten in dem ELP an einen Datenspeicher oder ein Log geschrieben, von dem die Ereignisdaten dann in Rechnungsdatensätze kompiliert werden und nachgeschaltete Systeme zur Rechnungsstellung, Verkehr/Benutzungsberichterstattung und andere track-Office-Funktionen gesendet werden. Insbesondere leistet das ELP die Funktion von: 1) Sammeln der von einem bestimmten Anruf erzeugten Netzereignisse; 2) Formatierung der Ereignisse in geeignete Anrufverlaufsdatensätze, z. B. Anrufdetaildatensätze („CDRs"), Rechnungsdatensätze („BDRs"), Switchereignisdatensätze, etc.; und 3) Überprüfung, Validierung und Speicherung der Information in z. B. einem Datenmanagement zur späteren Übertragung an ein nachgeschaltetes System, z. B. der Kundenrechnungsstellung. Es sollte verstanden werden, dass die Regeln zur Festlegung, welche Ereignisse an das ELP geschrieben werden, bei der Diensterzeugung aufgestellt werden. Ereignisdaten sind darüber hinaus den Betrugsmanagement- und Netzwerkmanagementsystemen zugänglich.
Das logische Anrufprogramm (545) ist die funktionelle Unterkomponente, die den Zustand jedes an der Dienstverarbeitung beteiligten SLPs behält, und stellt Prozessschnittstellen unter allen Diensten (LP's) bereit. In einer Ausführungsform wird ein CLP durch den FD instantiiert, wenn ein Ereignis Dienstanfragen zum ersten Mal für einen Anruf empfangen wird oder kann durch eine am Switch lokalisierte Anrufsteuerungskomponente instantiiert werden. Alternativ mag das CLP 545 durch ein SLP 510 zu irgendeinem Zeitpunkt während der Dienstverarbeitung instantiiert werden, in Übereinstimmung mit einem im SLP programmierten Trigger; auf diese Weise kann die Instantiierung eines CLPs zu einem Dienst spezifisch sein. Das logische Anrufprogramm empfängt die Adressen aller Unterkomponenten innerhalb der gleichen Instanz der Dienstverarbeitung zur Zeit der Instantiierung, d. h. der SLPs, der LLPs und des ELP. Das CLP assoziiert daraufhin das oder die SLP(s), das LLPO, das LLPT und das ELP mit diesem Anruf und ist für den Zugriff durch all diese Unterkomponenten innerhalb der gleichen Instanz der Dienstverarbeitung freigegeben. Das heißt, dass das logische Anrufprogramm der Verbindungspunkt für die Kommunikation zwischen den SLPs und den LLPs, die an der gleichen Instanz der Dienstverarbeitung beteiligt sind, ist. Wenn ein Anruf vollständig ist, teilt das CPL die Anrufvervollständigung allen Unterkomponenten innerhalb der gleichen Instanz der Dienstverarbeitung mit, was den Beendigungsprozess der logischen Programme auslöst.
Das logische Dienstprogramm (SLP) 520 ist die dynamische Unterkomponente, die die zur Ausführung eines Dienstes benötigte Logik bereitstellt. Ein SLP ist an einen Dienst und nicht an einen Anruf gebunden und führt Dienste und darin enthaltene Besonderheiten für einen Anruf aus. Die Besonderheiten, die ein SLP auf einen Dienst anwenden kann, schließen zum Beispiel Anruf-Routing-Algorithmen und IVR-Dienste ein. Das SLP mag ein dauerhaftes Objekt für häufig genutzte Dienste sein, oder es mag instantiiert werden, wenn dies durch den FD angefragt wird und bei Anrufvervollständigung wieder gelöst werden, z. B. für selten benutzte Dienste. Ob ein bestimmtes SLP ständig, zu manchen Zeiten oder nur auf Nachfrage hin aktiv ist, wird durch die Konfigurationsdatei 580, die durch die Dienstverwaltung für diesen Dienst, wie in 11 gezeigt, erzeugt wird, festgelegt. Vorzugsweise hat das SLP Zugriff auf die CLP- und ELP-Unterkomponenten innerhalb derselben Instanz der Dienstverarbeitung.
Nicht alle SLPs stehen mit einem spezifischen Anrufdienst in Verbindung und manche SLPs sind für Aufgaben verfügbar, die von anderen SLPs benötigt und aufgerufen werden. Somit mag ein SLP für einen 800-Dienst ein SLP für eine Leitungsinformations-Datenbankabfrage aufrufen, um seine Aufgabe für die Anruf-Routing-Übersetzung abzuschließen. Ein SLP kann auch die Kontrolle über die Anrufverarbeitung für einen Anruf an ein anderes SLP übergeben. Vorzugsweise soll nur ein kontrollierendes SLP gleichzeitig für eine einzelne Instanz der Dienstverarbeitung laufen. Jegliche Ereignisdaten, die als Teil der von dem SLP geleisteten Dienstaufgaben erzeugt werden, werden an die ELP-Komponente 540 innerhalb derselben Instanz der Dienstverarbeitung gesendet.
Ein SLP darf nicht direkt in einem Betriebssystem ausgeführt werden, weil es nicht alle Informationen für ein Betriebssystem zur Ausführung enthält. Falls das SLP ferner unter verschiedenen Betriebssystemen ausgeführt werden muss, ohne das Format und den Inhalt zu ändern, wird NOS middle-ware zwischen dem SLP und dem Betriebssystem bereitgestellt, um die Konsistenz des SLPs über Betriebssystemgrenzen hinweg beizubehalten.
Wie weiterhin in 8 gezeigt, umfassen andere Prozesse, die innerhalb der SLEE 450 als Unterstützungs- und Betriebsfunktionen ablaufen: ein Service Manager („SM")-Objekt 554, das für das Laden, Aktivieren, Deaktivieren und Entfernen der Dienste, die in der SLEE ablaufen, verantwortlich ist, und weiterhin alle anderen innerhalb seiner SLEE ablaufenden Dienste überwacht und Status und Benutzungsdaten an das NOS berichtet; ein NOS-Clientprozess 558, welcher eine NOS-Klassenbibliothek ist, die für Schnittstellen mit NOS-Diensten benutzt wird und von allen innerhalb dieser SLEE ablaufenden Dienste zum Aufruf von NOS-Diensten benutzt wird, d. h. der Übergang zum NOS ist; ein Thread-Manager („TM") 557, welcher von NGIN-Diensten zur gleichzeitigen Ausführung ohne Blockierung aller SLEE-Ressourcen benötigte Funktionalität bereitstellt; und eine Datenmanagement-API („DM API") 410, die als Schnittstelle mit dem lokalen Zwischenspeicher 415 und der Zwischenspeicher-Managerkomponente des DM 400 benutzt wird, was bezüglich 4(c) beschrieben wird. Noch weitere Dienstinstanzen, die wie in 8 gezeigt, in die SLEE geladen werden, umfassen eine Dienstagenten („SAg")-Instanz 559 und eine damit assoziierte Thread-Manager-Instanz 557, die für die Dienstaktivierung im Dienstknoten benutzt werden, was hierin detaillierter beschrieben wird. 12(a) stellt die (SLEE.java)-Prozessschritte, die den Haupteinstiegspunkt in den SLEE-Prozess bereitstellen, dar. Wie in 12(a) gezeigt, wird in Schritt 602 angenommen, dass eine Systemkomponente verfügbar ist, ein NOS-Standort-Lokalisierungssystem einschließlich eines NOS-Clientprozesses 558 und eines NOS-Masterprozesses 560 (11), welche von einer NOS-Klassenbibliothek bereitgestellt werden, die als Schnittstelle mit NOS-Diensten benutzt wird und von allen Diensten, die innerhalb der SLEE laufen, zum Aufruf von NOS-Diensten benutzt wird, zum Empfangen von logischen Namen und Objektreferenzregistrierungen verfügbar ist, und dass das Betriebssystem des Dienststeuerungsservers, z. B. Windows NT, UNIX, PC etc., den SLEE-Prozess starten mag, z. B. durch Erkennen eines Aufrufs eines Urladers wie Main () oder Fork (). Es sollte verstanden werden, dass die NOS-Masterkomponente 560 (8) eine direkte Schnittstelle mit dem Betriebssystem des Computers, mit dem NOS-Clientprozess 558 und anderen Systemkomponenten 571 besitzt. Vorzugsweise ist ein NOS-Masterprozess 560 an dem Netzwerk oder dem lokalen Knoten lokalisiert, der eine Schnittstelle mit dem NOS-Clientobjekt 558 auf jeder SLEE besitzt und alle NOS-Klassenbibliotheken zum Bereitstellen von NOS-Diensten bereitstellt. Als Nächstes wird in Schritt 604 die Dienststeuerungs-Konfigurationsdatei analysiert, und ein Konfigurationsobjekt, welches eine Schlüssel-Wertpaare enthaltende Hash-Tabelle einschließt, wie in Schritt 606 angezeigt, aufzubauen. Die SLEE akzeptiert zwei Parameter: einen Namen und eine Konfigurationsdatei. Der Parametername ist eine eindeutige NGIN-Namenszeichenkette, die von dem NOS-Neutralisierungsdienst zur Identifizierung dieser Instanz der SLEE benutzt wird, d. h. von der SLEE für ihre eigene Registrierung beim NGIN-Lokalisierungsdienst benutzt wird (Schritt 612), und die Konfigurationsdatei wird von dem Lokalisierungsdienst zum Auffinden seines Standortlokalisierers benutzt. Zum Beispiel kann diese Tabelle zum Auffinden von SLEE-Konfigurationseigenschaften benutzt werden. Da NOS CORBA implementiert, wird die grundlegende CORBA-Funktionalität als Nächstes in Schritt 608 initialisiert. Als Nächstes wird in Schritt 610 eine SLEE-Klassenladerklasse instantiiert und ein NOS-Lokalisierungs-Proxy-Dienst wird innerhalb der SLEE, wie in Schritt 612 angedeutet, instantiiert. Als Nächstes wird, wie in Schritt 615 angedeutet, die Service-Manager-(SM)-Klasse mittels einer Klassenladerklasse geladen, instantiiert und mit dem lokalen NOS verknüpft, d. h. das SM-Objekt wird beim lokalen Proxy-NOS-Lokalisierungsdienstobjekt registriert. Es sollte verstanden werden, dass der lokale Lokalisierungsdienst die Registrierung des Service-Managers an andere Lokalisierungsdienste in der NGIN-Domäne weiter gibt. Wie in Bezug auf 12(b) beschrieben wird, ist das Service-Manager-Objekt nach Registrierung beim Lokalisierungsdienst fähig, Dienstmanagementanfragen zum Laden, Aktivieren, Deaktivieren und Entfernen von Diensten zu/von der SLEE zu verarbeiten. Schließlich läuft wie in Schritt 618 angedeutet, eine Prozessereignisschleife ab, die der SLEE-Thread ist, der die SLEE am Laufen hält und der SLEE die Verarbeitung von NOS-Ereignissen ermöglicht, so wie diese durch die Service-Manager („SM")- oder Service-Agent („SAg")-Objekte hereinkommen, was hierin später detaillierter erklärt wird.
12(b) stellt die Schritte des (ServiceManagerImpl.java)-Prozesses dar, die ausgeführt werden durch die Dienst-Manager-Objektinstanz 554 (8), welche wie oben mit 12(a), Schritt 615 diskutiert, instantiiert wird. Vorzugsweise implementiert das SM-Objekt eine ORB-Schnittstelle zum Durchführen von Dienstmanagementoperationen im Auftrag des NOS. Der Prozess stellt die von der SM-Instanz unternommenen Schritte zum Laden, Aktivieren, Deaktivieren, Ausführen und Beenden von Diensten innerhalb der SLEE dar, d. h. mittels (load)-, (run)-, (start)- und (Stopp)-Methoden. Die an die SM-Objektinstanz übergebenen Parameter durch das NOS schließen die logische Referenz auf den gewünschten Dienst und einen Bool'schen Indikator ein, der anzeigt, ob das NOS den Dienst beim NGIN-lokalen Ressourcen Manager bzw. NGIN Local Ressource Manager (LRM ) Standortlokalisierer registrieren soll, oder ob der Dienst selber für die Registrierung vom NOS verantwortlich ist. Wie in Schritt 620 angedeutet, wird zunächst eine Aufforderung zum Laden eines Dienstes empfangen und ein Handle in dem Proxy-Ladungsdienst wird in Schritt 622 erzeugt. Dann wird in Schritt 624 entschieden, ob der angeforderte Dienst, z. B. 1-800-R-Gespräch („18C"), bereits geladen ist, d. h. ob das den angeforderten Dienst verkörpernde Objekt instantiiert ist. Falls das Objekt für den angeforderten Dienst bereits instantiiert ist, wird das NOS die Objektreferenz dieses Dienstes als Antwort zurückgegeben, um die physikalische Objektinstanz in Schritt 626 zu lokalisieren und der Prozess kehrt zum Schritt 632 zurück. Wenn das Dienstobjekt für den angefragten Dienst, z. B. 18C, nicht bereits instantiiert ist, so wird in Schritt 625 die Klassenladerklasse instantiiert, welche ein rekursives Laden zum Laden aller Klassen, von denen der angeforderte Dienst abhängt, inklusive anderer SLPs und SIBBs, implementiert. Das rekursive Laden ist durch das Nachschlagen in einer lokalen Konfigurationsdatei in z. B. dem lokalen Zwischenspeicher möglich. Insbesondere wird ein Indikator übergeben, der anzeigt, ob ein Klassenlader eine dieser abhängigen Klassen in die JVM laden muss. Beim Laden von Klassen für einen Dienst in der ersten Instanz wird dies so verstanden, dass eine generische Serviceagentklasse geladen werden kann, wenn nicht bereits geschehen. Nach dem Laden aller Klassen in Schritt 625 wird in Schritt 628 ein Bool'scher Registerindikator überprüft, um festzustellen, ob der Dienst sich bereits selber bei dem lokalen NOS-Namensdienst (Proxy) registriert hat. Wenn der Bool'sche Registerindikator gesetzt ist, z. B. als wahr, dann obliegt ihm die Verantwortung, sich beim NOS-Namensdienst zu registrieren, wie in Schritt 630 gezeigt. Im anderen Fall fährt der Prozess mit Schritt 632 fort, wo die SAg-Klasse instantiiert wird und eine Assoziierung zwischen der Dienstagent-Objektinstanz 558 (11) und dem bestimmten Dienst gemacht wird, d. h. durch Übergabe des SLP-Objekt in die Serviceagentinstanz. Dann wird in Schritt 635 ein neuer SLEE-Thread erzeugt, in einer Weise, die noch zu beschreiben ist, und der SLEE-Thread wird zum Ausführen des Serviceagenten aufgerufen, d. h. der SLEE-Thread wird mit dem Serviceagenten assoziiert. Schließlich wird der SM-Prozess verlassen und der Prozess kehrt zum SLEE-Javaprozess zurück. Durch die im SM bereitgestellten Methoden ist er zusätzlich für die Überwachung aller anderen Dienste, die innerhalb der SLEE ablaufen und für das Berichten von Zustand und Benutzungsdaten an das NOS verantwortlich.
Weiter bezüglich des SM-Prozesses wird der Aufruf von (SLEEClassLoader.java) jetzt detaillierter im Hinblick auf 12(c) beschrieben. Insbesondere ist die SLEEClassLoader-Klasse eine spezialisierte Klasse und Erweiterung der ClassLoader-Klasse der JVM. Sie erweitert das Verhalten des systemeigenen Klassenladers dadurch, dass sie das Laden von Klassen über das Netzwerk zulässt. Somit überprüft in einem ersten Schritt 686 der 12(c) der Klassenlader zunächst seinen lokalen Zwischenspeicher, der mit der Instanz der SLEE assoziiert ist, um nachzuschauen, ob die Klasse bereits geladen und definiert wurde. Wenn die Klasse bereits geladen wurde, kehrt der Prozess zurück. Wenn die Klasse noch nicht geladen wurde, dann wird in Schritt 688 eine Nachricht mittels des NOS verschickt, um in einem lo kalen Datenspeicher, bzw. local data store (DM) zu überprüfen, ob die Klasse zum Laden verfügbar ist. Zum Beispiel kann der SLEEClassLoader die Klasse aus einer relationalen Datenbank mittels JDBC-Datenbankverbindung erhalten, es ist jedoch verstanden, dass er die Klassen aus irgendeiner relationalen Datenbank, die die JDBC API unterstützt, erhalten kann. Wenn die Dienstklasse nicht im lokalen Datenspeicher gefunden wird, dann überprüft der SLEEClassLoader ein lokales Dateisystem in Schritt 689. Wenn die Klasse entweder im Datenspeicher oder im lokalen Dateisystem gefunden wurde, wird die Klasse geholt, wie in Schritt 690 gezeigt. Dann wird in Schritt 694 eine Methode defineClass aufgerufen, um die Klasse für die JVM-Ausführungsumgebung verfügbar zu machen: Insbesondere mag die (defineClass)-Methode rekursiv jede der zum Ausführen dieses Dienstes spezifizierten Klassen durchgehen und ein Array von Bytes in eine Instanz einer Klasse Class konvertieren. Instanzen dieser neu definierten Klasse können dann durch Benutzung der Methode newInstance der Klasse Class erzeugt werden. Diese Funktionalität erlaubt es der SLEE, neue Dienste zu laden und zu instantiieren und trotzdem generisch zu bleiben. Vorzugsweise wird wie in Schritt 695 gezeigt, eine Methode zum Füllen des lokalen Datenspeichers aufgerufen, so dass das nächste Mal, wenn die Klasse geladen wird, diese im Zwischenspeicher anzutreffen ist.
In der bevorzugten Ausführungsform registriert sich jedes dieser instantiierten Objekte selber bei dem NOS-Lokalisierungsdienst, d. h. LRM 577, gemäß einer Namenskonvention, die allgemein durch die folgende Zeichenkette erläutert wird:
... Standortebene. SLEE-Nummer. SLP-Name ...
wobei die Standortebene die Information ist, die zum physikalischen Standort des NGIN-Dienststeuerungsservers 440 gehört; die SLEE-Nummer die der bestimmten SLEE, in der das Objekt instantiiert wurde, ist, z. B. SLEE#1; und der SLP-Name der logische Name des Dienstes ist, z. B. Feature Discriminator#1. Die Zeichenkette kann auch eine „Versionsnummer" enthalten. Ein Registrierungsname wird an die anderen Lokalisierungsstandorte in der NGIN-Domain übertragen; und durch diesen Registrierungsprozess und die NOS-Ressourcen-Management-Funktionalität (noch zu beschreiben), weiß die NOS-Komponente, welche Prozesse einsatzbereit sind, wo diese eingesetzt sind und wo Dienste im Augenblick verfügbar sind.
Die Methoden und Konstruktoren der von einem Klassenlader erzeugten Objekte können auf andere Klassen verweisen. Um die Klassen, auf die verwiesen wird, zu bestimmten, ruft die Java Virtual Machine die Load-Class-Methode des Klassenladers, der die Klasse ursprünglich erzeugt hat, auf. Wenn die Java Virtual Machine nur feststellen muss, ob die Klasse existiert und, falls diese existiert, deren Oberklasse kennen muss, wird ein „Auflösungs"-Indikator auf falsch gesetzt. Wenn jedoch eine Instanz der Klasse gerade erzeugt oder irgend eine ihrer Methoden gerade aufgerufen wird, muss die Klasse auch aufgelöst werden. In diesem Fall wird der Auflösungsindikator auf wahr gesetzt und die Methode resolveClass wird aufgerufen. Diese Funktionalität garantiert, dass die Klassen/SIBBs/JavaBeans, auf die durch den Dienst verwiesen wird, auch durch den SLEEClassLoader aufgelöst werden.
12(d) stellt den Prozessfluss der Service-Agent-Klasse bei ihrer Instantiierung dar. Wie in Schritt 639 gezeigt, enthält der erste Schritt die Instantiierung eines Thread Manager („TM")-Objekts, das mit dem Service Agent assoziiert wird und mit TM-Objektinstanz 557 in 11 gekennzeichnet ist. Wie noch beschrieben wird, basiert das Thread-Manager-Objekt auf einer (ThreadManager)-Klasse, die so instantiiert werden kann, dass sie sich wie eine Thread-Fabrik verhält, die in der An funktioniert, dass pro Dienstanfragen ein neuer SLEE-Thread erzeugt wird, oder ein Thread-Warehouse, was gewünscht ist, wenn die Ausführung auf Maschinen mit langer Threaderzeugungs-Verzögerung erfolgt. Als nächstes tritt die mit dem Dienst assoziierte SA in Schritt 640 in eine Prozessereignisschleife mittels seiner (run)-Klassenmethode ein und ist nun für den Empfang eines mit dem Dienst assoziierten Anrufereignisses bereit.
Mit Bezug auf 12(e) werden die Details der ServiceAgent-Klasse dargestellt, die den Übergang in die NGIN-Dienste mittels ihrer (begin)-, (continue)- und (end)-Klassenmethoden bereitstellt. Jeder Dienst innerhalb der SLEE hat ein assoziiertes ServiceAgent-Objekt, das auf einer Klasse basiert, die für das Verwalten von Dienstinstanzen (Anrufinstanzen) und das Verteilen von Ereignissen an Dienstinstanzen verantwortlich ist. Wie in 12(e) gezeigt, wird nach der Instantiierung eines SAg-Objekts durch die (load)-Methode des Service-Managers die (begin)-Methode des SAg's jedes Mal, wenn ein neuer, diesen Dienst anfordernder Anruf empfangen wird, aufgerufen. Insbesondere werden die in 12(e) in Schritt 641 gezeigten, tid-, orid-Anrufidentifizierungsparameter und ein Nachrichtenstrom mit Ereignisinformationen, die sich auf die Dienstverarbeitung dieses Anrufs beziehen, z. B. wie durch eine Initial Address Message („IAM") vom IDNA/NGIN-Switch, welcher hierin mit Next Generation Switch („NGS") bezeichnet wird, zunächst in die begin-Methode des SAg's hinein übergeben. Dann wird in Schritt 643 der Nachrichtenstrom decodiert, z. B. durch Aufruf einer (decode)-Methode zur Extraktion der kritischen Informationen, die mit dieser Dienstinstanz in Verbindung stehen. Zusätzlich wird eine Anruf-Kontext-Objektinstanz zur Verwaltung von Anrufkontextdaten erzeugt, um die extrahierte Nachrichteninformation zu empfangen. In der begin-methode wird, wie angedeutet in Schritt 645, für diesen Anruf ein neuer Thread allokiert durch Aufrufen der allocate-Methode der Thread-Manager-Instanz, wie hierin mit Bezug auf 12(g) beschrieben wird, oder ein Thread wird auf einen Pool von Threads herausgezogen, falls mehrere Threads für diesen Dienst im Voraus instantiiert wurden. Andernfalls, falls die (continue)-Methode des SAgs aufgerufen wird, wird eine dem allokierten Thread entsprechende Objektreferenz für diesen Anruf als Ergebnis zurückgegeben.
Das Thread-Manager-Objekt basiert genauer auf der Thread-Manager-Klasse, welche vorzugsweise auf Session-Ids basierende Threads verwaltet. Zwei Methoden (allocate) und (release) werden jeweils für die Allokation und das Freigeben von Threads bereitgestellt. Sowohl allocate als auch release erwarten einen eindeutigen Identifizierer als Schlüssel, der für Thread-Identifizierung benutzt werden kann. Die eindeutigen Identifzierer schließen eine Transaktions-ID („Tid"), die durch den NGS-Switch, der den Anruf empfangen hat, gesetzt wird, und eine Objektreferenz-ID („Orid"), die den Anrufer identifiziert, ein und werden zur Identifizierung einer Anrufinstanz benutzt. 12(f) stellt die Details des Betriebs der (allocate)-Methode der Thread-Manager-Klasse dar. Wie in 12(f) in Schritt 660 dargestellt wird, werden die Tid- und Orid-Ideritifizierer zur eindeutigen Identifzierung der Anruftransaktion in den Prozess gegeben und auf Grundlage der Identifizierer wird ein eindeutiger Schlüssel erzeugt. Dann wird in Schritt 662 eine Abfrage gemacht, ob der Schlüssel einen bereits bestehenden Thread identifiziert, z. B. durch Überprüfung einer Hash-Tabelle mit Schlüssel-Wertpaaren. Wenn der Schlüssel erkannt wird, was bedeutet, dass der Dienst-Thread bereits für den Anruf allokiert wurde, gibt der Thread-Manager in Schritt 664 die SLEE-Thread-Instanz (thread Objekt) nach Befragung der Hash-Tabelle als Ergebnis zurück. Andernfalls wird in Schritt 663 ein Zähler, der die Anzahl der instantiierten Dienst-Threads festhält, erhöht, und mit dem Ziel, die Systemlast zu überwachen, wird in Schritt 665 festgestellt, ob der Maximalwert für die Anzahl von Thread-Instanzen für diesen Dienst überschritten wurde. Falls der Maximalwert für die Anzahl von Thread-Instanzen für diesen Dienst überschritten wurde, z. B. durch Vergleich des Zählerwerts mit dem Wert für die Maximalanzahl von Dienstinstanzen, wie er in der Dienstkonfigurationsdatei gefunden wird, wird in Schritt 667 eine Nachricht an das NOS abgesetzt, um diesem das Suchen nach einer anderen, möglicherweise verfügbaren Instanz für diesen Dienst zu ermöglichen, z. B. in einer anderen SLEE, die am selben Standort oder an einem anderen Dienstknotenstandort abläuft, woraufhin der Prozess zurückkehrt. Im weiteren SleeThread-Instantiierungsprozess ist die Initialisierung beim PrioritätsEreignisQueue bzw. PriorityEventQueue, die im weiteren Detail mit Bezug auf 12(g) hierin beschrieben wird. Wenn der Maximalwert der Anzahl von Thread-Instanzen für diesen Dienst nicht überschritten wurde, wird in Schritt 668 festgestellt, ob ein Schwellwert für die Anzahl von Thread-Instanzen für diesen Dienst überschritten wurde. Wenn ein Schwellwert für die Anzahl von Thread-Instanzen für diesen Dienst überschritten wurde, dann wird in Schritt 669 eine Warnung an die NOS-lokale Ressourcen-Management-Funktion abgesetzt, dass der Dienstschwellwert erreicht wurde. Schließlich wird in Schritt 670 unabhängig von der Ausgabe in Schritt 668 eine neue SleeThread-Instanz für den angeforderten Dienst allokiert, die Prioritäts-Ereignis-Queue wird für den angeforderten Dienst initialisiert und der Thread wird gestartet, wobei die Kontrolle an die SAg-Instanz für diesen Dienst übergeben wird.
Zurückkehrend zu der in 12(e) gezeigten Funktionalität der ServiceAgent-(begin)-Methode, werden mit dem Thread in einer Beziehung stehende Objektvariablen in Schritt 646 initialisiert und eine neue Objektinstanz des angefragten Dienstes wird durch Aufruf einer (clone)-Methode instantiiert, nachdem der Thread-Manager den Thread für die Dienstinstanz allokiert hat. Dann wird in Schritt 648 die neu geklonte SLP-Instanz im neu allokierten Thread gesetzt. In Schritt 650 muss dann eine Entscheidung getroffen werden, ob Ereignisinformationen existieren, die benötigt werden, um mit dieser Anrufinstanz assoziiert zu werden, z. B. sämtliche aus dem Eingabenachrichtenstrom extrahierte IAM-Informationen. Falls es mit der neu geklonten SLP-Instanz assoziierte Ereignisinformationen gibt, werden diese auf den Thread geschoben, wie in Schritt 652 angedeutet. Unabhängig davon, ob es Ereignisinformationen, die auf den Thread geschoben werden müssen, gibt oder nicht, wird der neu allokierte Thread für dieses SLP gestartet und wartet auf die asynchrone Ankunft von dienstbezogenen Ereignisinformationen, welche durch die SA-(continue)-Methode verarbeitet werden können. Wie erwähnt, unterhält der für diesen Anruf allokierte SleeThread eine Prioritätsereignis-Queue zur Aufnahme aller dienstbezogenen Ereignisinformationen, die während der Verar beitung empfangen werden. Alle mit der Dienstverarbeitung in Verbindung stehenden Ereignisse haben eine zugeordnete Priorität und der Thread wird die Verarbeitung von Ereignisin- formationen gemäß ihrer Priorität organisieren, d. h. sie entsprechend in der Ereignis-Queue dieses Dienstes platzieren. Schließlich wird in Schritt 654 die Thread-Ereignis-Schleife für diese Anrufinstanz gestartet.
Es sollte verstanden werden, dass die SA-(continue)-Methode im Wesentlichen das Gleiche ist wie die in 12(e) gezeigte (begin)-Methode, mit dem Unterschied, dass die SA(continue)-Methode zur Kanalisierung von Echtzeit-dienstbezogenen Ereignissen auf einen Dienstverarbeitungs-Thread, der bereits für diese Anrufinstanz instantiiert wurde, angewiesen ist, wie oben mit Bezug auf 12(e) diskutiert. Somit empfängt die continue-Methode des Service Agent's Ereignisse und Identifikationsparameter der Anrufinstanz, reallokiert den mit den tid-, orid-Parametern für das empfangene Ereignis assoziierten Dienst-Thread und schiebt das Ereignis auf die Ereignis-Prioritäts-Queue des Threads. Es sollte verstanden werden, dass sowohl die SAg- und SM-Klassen beide eine IDL-Schnittstelle an das NOS umfassen. Dienste (SLPs) haben solch eine Schnittstelle jedoch nicht und sind fähig, systemweit mittels ihrer SAg-Schnittstelle zu kommunizieren. Während der Echtzeitdienstverarbeitung ist die SLEE 450 fähig zur Ausführung des Folgenden: 1) Interpretieren von Instruktionen auf den SLPund SIBB-Ebenen während der Dienstverarbeitung; 2) Abliefern der hereinkommenden Ereignisse an die vorbestimmte Instanz des SLP; 3) Erzeugen von Trace-Daten, falls ein Tracing-Indikator gesetzt ist; 4) Erlauben des Tracings auf den SLP-, SIBB- und SLEE-Ebenen einzuschalten und die Trace-Daten an eine bestimmte Ausgabe zu senden; 5) Erzeugen von SLEE-Benutzungsdaten und Versenden der Laufzeitbenutzungsdaten an eine bestimmte Ausgabe; 6) Erzeugen von Ausnahmedaten (Fehlern) für die Telekommunikations-Management-Network (TMN)-Schnittstelle; 7) Erzeugen von Leistungsdaten für die TMN-Schnittstelle; 8) Empfangen einer Nachricht/Anforderung zum Hinzufügen neuer Instanzen von SLP oder Hilfsprogrammen und Hinzufügen solcher neuer SLP oder Hilfsprogramminstanzen ohne Unterbrechung und Verschlechterung der Dienstverarbeitung; und 9) Unterstützen des gleichen Dienstes durch Multiple Dienststeuerungsinstanzen zur Aufteilung von Last.
Wenn eine Dienstinstanz die Verarbeitung beendet hat, wird sie entweder die Beendigung des Dienstes anstoßen oder ein anderer, mit ihr in Kommunikation stehender Prozess wird dies tun. In beiden Fällen wird die SAg (end)-Methode aufgerufen, welche zur Beendigung der mit dem Anruf assoziierten Thread-Instanz fungiert. Dies wird durch Aufrufen einer ThreadManager (release)-Methode übergeben, der die Anrufinstanz eindeutig identifizierenden Tid- und Orid-Identifizierer, Schieben sämtlicher Ereignisse auf die Ereignis-Queue des Threads und Freigeben des Anrufs, z. B. durch Beendigung der Thread-Instanz und/oder Zurückplatzieren der Thread-Instanz in einen Thread-Pool erreicht.
Vorzugsweise stellt die SleeThread-Klasseninstanz die von dem IDNA/NGIN-Diensten benötigte Funktionalität bereit, damit diese gleichzeitig ohne Inanspruchnahme aller SLEE-Ressourcen ausgeführt werden können, und erleichtert kooperatives Teilen der Resourcen. Im Speziellen besteht eine Eins-zu-Eins-Beziehung zwischen SleeThread und einer Dienstinstanz, wobei die SLEE eine Instanz eines SleeThreads mit einer Instanz eines Dienstes assoziiert, d. h. für jeden Anruf, der von einem Dienst behandelt wird, gibt es eine mit dem Anruf assoziierte Instanz von SleeThread. Der SleeThread agiert auch wie ein Daten-Warehouse für den Dienst durch Beherbergen einer Transaktions-id (tid), Objektreferenz-id (Orid), von Objektreferenzen, d. h. sowohl Peer als auch Agents, ein SLP und eine Prioritäts-Ereignis-Queue, die mit dem SLP assoziiert ist. Genauer agiert ein SleeThread wie ein Ereigniskanal zwischen dem Dienst (SLP) und dem ServiceAgent durch Implementierung zweier Schlüsselschnittstellen: einen PushConsumer, um es dem ServiceAgent zu ermöglichen, Ereignisse auf den SleeThread zu schieben; und einen PullSupplier, der es Diensten ermöglicht, Ereignisse aus dem ihnen zugeordneten Thread herauszuziehen. Wie noch beschrieben werden wird, hat jeder SleeThread eine Instanz von PriorityEventQueues, um NGINEvents in der beschriebenen Weise einzureihen.
Vorzugsweise ist die (PriorityEventQueue)-Klasse eine plattformunabhängige Klasse, die Ereignisse (abgeleitete Klassen von NGINEvent) mit einem Dienst (SLP) assoziiert. Wie mit Bezug auf Schritte 667, 670, 12(f) gezeigt, instantiiert jedes SleeThread-Objekt eine Instanz von PriorityEventQueue, welche eine Hash-Tabelle von Ereignissen umfassen kann. Die Ereignisse können in aufsteigender Reihenfolge eingereiht werden, wobei die Ereignisprioritäten zum Beispiel in der NGINEvent-Basisklasse definiert werden und von 10 bis 1 reichen, wobei 10 die höchste Priorität ist. Somit kann jeder Thread die Anzahl der Ereignisse, die für die Verarbeitung zur Verfügung stehen, mitzählen, womit voller Dienstverarbeitungs-Parallelismus ermöglicht wird.
12(g) stellt eine (postEvent)-Methode dar, die die Logik zur Ermittlung der Priorität des durch den Thread empfangenen Ereignisses, wie in Schritt 677 dargestellt, und das Einstellen von Ereignisse in die PriorityEventQueue. Wie in 12(g) gezeigt wird, wird dies im Wesentlichen erreicht durch Vergleichen der Priorität des eingestellten Ereignisses mit der Priorität des Ereignisses, das als Nächstes auf der Prioritäts-Queue in Schritt 678 verarbeitet wird, Feststellen, ob die Priorität des eingestellten Ereignisse größer ist als die Priorität des als Nächstes in der Queue zu verarbeitenden Ereignisses (wenn vorhanden), in Schritt 680 und Platzieren von entweder dem eingestellten Ereignis an der Spitze der Queue, um es als Nächstes zu verarbeitendes Ereignis zu setzen, wie in Schritt 682a angedeutet, oder Durchwandern der Queue und Feststellen des Platzes in der Queue, wo das Ereignis gemäß seiner Priorität gespeichert werden soll, wie in Schritt 682b angedeutet. Dann verarbeitet in Schritt 684 der SleeThread-Prozess das nächste Ereignis der Priorität, sobald er Verarbeitungszeit vom System zugewiesen bekommt.
Genauer wird eine PullSupplier-Schnittstelle durch den SleeThread implementiert, um einen Betrieb zu unterstützen, in dem Konsumenten Daten von Versorgern anfordern durch Aufrufen von entweder einer „Pull"-Operation, die blockiert, bis die Ereignisdaten verfügbar sind, oder das Werfen einer Ausnahme und die Übergabe der Ereignisdaten an den Konsumenten, oder die „tryPull"-Operation, welche nicht blockiert. Das heißt, falls die Ereignisdaten verfügbar sind, gibt sie die Ereignisdaten zurück und setzt einen Parameter hasEvent auf wahr; wenn das Ereignis nicht verfügbar ist, setzt es den hasEvent-Parameter auf falsch und ein Nullwert wird zurückgegeben. Somit kann der SleeThread als ein Ereignisspender agieren und der Dienst (SLP) übernimmt die Konsumentenrolle. Der Dienst (SLP) benutzt den SleeThread pull oder tryPull zum Holen von Ereignisdaten aus dem SleeThread. Der Dienst benutzt entweder die Pull-Operation, falls er nicht ohne die Ereignisdaten fortfahren kann, andernfalls benutzt er die tryPull-Operation.
Die PushConsumer-Schnittstelle wird vom SleeThread implementiert und implementiert eine generische PushConsumer-Schnittstelle, die einen Betrieb untersützt, bei dem Versorger-Ereignisdaten an den Konsumenten durch Aufruf einer Push-Operation auf dem Thread und durch Übergeben der Ereignisdaten als Parameter an die Prioritäts-Ereignis-Queue dieses Threads kommunizieren. Auf diese Weise agiert der SleeThread als ein Ereigniskonsument und der Serviceagent übernimmt die Versorgerrolle. Der Serviceagent benutzt die SleeThread-Pushoperation zur Kommunizierung von Ereignisdaten an den SleeThread. Ein Ereignis „kill"-Dienst mag die höchste Priorität haben. Prioritäten für Ereignisse mögen auf Standardwerte gesetzt sein oder, wenn neu erzeugte Ereignisklassen entwickelt werden, bei der Diensterzeugung bestimmt werden.
Wie beschrieben kanalisiert die Service-Agent-Instanz für einen bestimmten Dienst alle Ereignisse, die während der Dienstverarbeitung von/aus der für diesen Anruf erzeugten Dienst-Thread-Instanz empfangen und erzeugt wurden. Zum Beispiel kann ein initiales Ereignis, das von einem Switch an einem Knoten erzeugt wurde, ein (ServiceRequestEvent), dessen Klasse für die Weiterleitung einer initialen Dienstanforderung an die IDNA/NGIN-Dienststeuerung verantwortlich ist, enthalten, insbesondere die entsprechenden initialen Anrufkontextinformationen, wie: der Auslösezeitpunkt der Dienstanforderung; die Switch-II, von der die Anforderung her kommt; die Port-ID der Herkunft des Anrufs; die Nummer des Anrufers; die Nummer des Angerufenen, etc. Eine NGINevent-erweiternde (connectEvent)-Unterklasse kann die Zeit der Verbindungsaufnahme berichten; die Stationsnummer, mit der die Nummer des Anrufers verbunden ist; und im Zusammenhang mit einem ATM-VNET-Dienst die eintreffende Virtual-Path-ID und die abgehende Virtual-Path-ID berichten. Eine NGINevent-erweiternde (releaseEvent)-Unterklasse kann das Freigabeereignis berichten. Zum Beispiel kann im Zusammenhang mit einem ATM-VNET-Dienst die Freigabe verursacht werden, wenn der Anrufer oder der Angerufene den Anruf beendet oder wenn das Benutzerguthaben aufgebraucht ist. Eine solche Klasse kann SIBBs implementieren zur Feststellung von: der Erzeugungszeit eines Freigabeereignisses; des Grunds der Erzeugung des Freigabeereignisses und der verstrichenen Zeit von der Verbindungsaufnahme zwischen Anrufer und Angerufenem bis zur Erzeugungszeit des Freigabeereignisses. Darüber hinaus kann eine NGINevent-erweiternde (terminateEvent)-Unterklasse zur Übertragung einer Beendigungsnachricht vom NGIN an NGS benutzt werden. Bei Erhalt dieser Nachricht kann der Switch den Abbruch des Verbindungsprozesses auslösen. Eine (MonitorReleaseEvent)-Unterklasse erweitert den NGINevent und wird benutzt, um eine Nachricht an NGS zu senden, mit der NGS die Aufforderung bekommt, eine Freigabeanzeige an NGIN bei Empfang einer Freigabeanzeige zu senden. Wenn NGS eine Überwachungsfreigabenachricht empfängt, kann eine (UniNotifyEvent)-Unterklasse zum Senden einer Benachrichtigung an den Urheber (Anrufer) aufgerufen werden. Die (MonitorConnectEvent)-Unterklasse erweitert NGIN-Event und ist eine Unterklasse, die benutzt wird, um eine Nachricht vom NGIN an NGS zu senden, mit der NGS aufgefordert wird, ein Ereignis an NGIN zu senden, wenn eine Verbindungsnachricht empfangen wird.
Wie im Zusammenhang mit Echtzeit-Dienstverarbeitung erwähnt, schließt die Abruf- und Aktualisierungsfunktionalität des Datenmanagements ein, auf die von DM während der Dienstverarbeitung abgespeicherten Daten zuzugreifen.
In der bevorzugten Ausführungsform empfängt DM an jedem bestimmten Dienstknoten Datenanforderungen von einer ausführenden verwalteten Objektinstanz in der SLEE, z. B. durch das NOS während der Dienstverarbeitung. Datenmanagement benachrichtigt speziell den Anfordernden (z. B. verwaltetes Objekt), falls es nicht in der Lage ist, die Datenanforderung zu verstehen. Falls die Datenanforderung für die Abfrage einer Dateneinheit ist, gibt das Datenmanagement die angeforderten Daten an den Anfordernden (z. B. mittels NOS) zurück. Es sollte verstanden werden, dass jegliche zur Manipulation und Abfrage von Daten in einem einzelnen Repository oder über mehrere Repositories hinweg benötigte Unterstützung durch DM bereitgestellt wird. Datenmanagement unterstützt zusätzlich die Sammlung und das Zusammentragen von Abfrageergebnissen, die sich über mehrere Repositories erstrecken. Falls DM nicht in der Lage ist, den Namen der angeforderten Einheit während der Datenabfrageanforderung zu lokalisieren, benachrichtigt DM die NOS-Komponente. Die NOS-Komponente wird ebenfalls benachrichtigt, falls ein Datenbankfehler während der Abfrage der Dateneinheit auftritt. Zusätzlich benachrichtigt Datenmanagement den Anfordernden (das ausführende Dienststeuerungsobjekt), über die Unfähigkeit eine spezielle Dateneinheit von einem gültigen Namen abzufragen. Falls die Datenabfrage für die Aktualisierung einer Dateneinheit ist, aktualisiert Datamanagement die Dateneinheit und stellt fest, ob eine Erwiderung erforderlich ist. Das DM benachrichtigt den Anfordernden, falls es nicht in der Lage ist, eine in einer Datenanforderung spezifizierte Dateneinheit zu aktualisieren und benachrichtigt zusätzlich NOS, falls es nicht in der Lage ist, den Namen der in der Datenaktualisierungsanforderung angeforderten Einheit zu lokalisieren. Zu jedem Zeitpunkt während des NGIN-Betriebs benachrichtigt DM das NOS über einen Datenbankfehler während der Aktualisierung einer Dateneinheit. Falls die Datenanforderung für die Entfernung einer Dateneinheit ist, entfernt DM das Datenelement und stellt fest, ob die Transaktion auf anderen Repositories ausgelöst werden muss.
4(c) stellt allgemein die funktionelle Architektur der Datenmanagementkomponente 400 dar, welche umfasst: eine Dienststeuerungsserverkomponente 405 zur Verfügbarmachung von Anrufdienstdaten am Dienstknoten für die Echtzeitanrufverarbeitung; und eine Datenbankkomponente 407, verkörpert als diskreter Datenbankserver, zur Speicherung und Verteilung von ausgewählten Untermengen der durch die SA erhaltenen Daten. Im Speziellen schließt die Dienststeuerungsserverkomponente 405 einen Datenmanagement(DM)-Client 409 ein, der die eigentliche Datenmanagementanwendung darstellt; eine DM-API 410, die mit der DM-Anwendung verbunden ist und die Schnittstelle zu der DM-Anwendung ist, wird benutzt, um Daten von der SA zu erhalten; einen lokalen Zwischenspeicher 415, der geteilter Speicher auf einem Dienststeuerungsserver ist zur Speicherung von einigen oder allen Daten aus dem DBOR-Extrakt, die für die Anrufeverarbeitung gemäß einer lokalen Zwischenspeicherungsstrategie verfügbar sind, in einem Zwischenspeichermanager, bzw. Cache-Manager 420, der den Zustand des lokalen Zwischenspeichers durch Implementierung einer lokalen Zwischenspeicherungsstrategie behält und mit dem DM-Server kommuniziert, um Daten aus dem DBOR-Extrakt herauszuholen. Die Datenbankkomponente 407 schließt ein DBOR-Extrakt 427 ein, das eine oder mehrere Datenbanken mit Daten, die von den verwalteten Objektinstanzen während der Dienstausführung an diesem Knoten benutzt werden, umfasst; einen DBOR-Extraktmanager 426 zur Verwaltung einer ausgewählten Untermenge von Informationen, die in der SA behalten werden; ein SA-Client 422, der von der Dienstverwaltung empfangene Daten in den DBOR-Extraktmanager 426 eingibt; eine DDAPI 424, welche die Prozessschnittstelle zwischen dem SA-Client 422 und dem Datenverteilungsprozess der SA ist; und ein Datenmanagementserver 425, der im Allgemeinen Datenextrakte aus dem DBOR-Extraktmanager 426 behandelt.
Der Datenmanagementbetrieb wird nunmehr mit Bezug auf 4(c) und 8 beschrieben. Innerhalb einer SLEE können mehreren Funktionstypen Daten vom Datenmanagement 400 benötigen, einschließlich, aber nicht beschränkt auf verwaltete Objekte (SIBBs, SLPs, etc.) und NOS. All diese sind in 4(c) als DM-Client dargestellt, der in der Dienststeuerung SLEE abläuft. Ein DM-Client 410 benutzt die DM API 412, um eine Datenanforderung zu machen, während die DM API 412 einen Satz allgemeiner Nachrichten für alle DM-Clienten als Schnittstelle mit Datenmanagement bereitstellt. Die DM API 412 kapselt auch den spezifischen Ort, wo die Daten benötigt werden, vom DM-Client ab, da diese Daten in einem lokalen Zwischenspeicher 415 oder nur in dem DBOR-Extrakt 427 gespeichert werden können.
Der DM-Client 410 fordert Daten mittels eines logischen Namens an und die DM API 412 stellt fest, ob diese Daten aus dem lokalen Zwischenspeicher geholt werden können oder ob es nötig ist, die Daten von dem DBOR-Extrakt mittels des DM-Servers anzufordern. Vorzugsweise ist der lokale Zwischenspeicher 450 ein geteilter Zwischenspeicher, der für jeden Prozess, der auf jeder im Steuerungsserver 405 bereitgestellten SLEE abläuft, verfügbar ist, d. h. es kann einen oder mehrere für unterschiedliche Anwendungen bereitgestellte lokale Zwischenspeicher geben, z. B. einen 1-800-Prozess-Zwischenspeicher, einen Routing-Manager-Zwischenspeicher, etc., wobei jeder geteilte Zwischenspeicher seinen eigenen jeweiligen Zwischenspeichermanager hat.
Wenn ein DM-Client 410 eine Datenanforderung macht, überprüft die DM API zunächst den lokalen Zwischenspeicher 415 um zu sehen, ob die angeforderten Daten dort gespeichert sind. Wenn die angeforderten Daten im lokalen Zwischenspeicher 415 gespeichert sind, holt die DM API die angeforderten Daten heraus und stellt diese dem DM-Clienten 410 bereit, wobei irgendeine Standardtechnik zur Datenabfrage benutzt wird, wie z. B. Hashing-Schlüssel und Algorithmen oder indizierte sequenzielle Zugriffsmethoden.
Wenn die angeforderten Daten nicht im lokalen Zwischenspeicher 415 gespeichert sind, holt der zugeordnete Zwischenspeichermanager 420 die Daten von dem DBOR-Extrakt 427 mittels des DM-Servers 425. Insbesondere benachrichtigt die DM API 412 den Zwischenspeichermanager 420, dass sie bestimmte Daten benötigt und der Zwischenspeichermanager antwortet durch das Senden einer Abfrage an den DM-Server 425. Der DM-Server 425 wiederum holt die angeforderten Daten von dem DBOR-Extrakt mittels des DBOR-Extraktmanagers 426 zum Zugriff auf die Datenbank. Der DM-Server 425 sendet die angeforderten Daten zurück an den Zwischenspeichermanager 420 und der Zwischenspeichermanager holt die Daten der DM-Client 610 mittels der DM API 412 bereit. Der Zwischenspeichermanager kann die angeforderten Daten auch in den lokalen Zwischenspeicher 415 schreiben, abhängig von der lokalen Zwischenspeicherungsstrategie, die abhängig ist von sowohl Dienstnachfrage und den Fähigkeiten der Computer, auf denen diese ablaufen, insbesondere der Speicherkapazität. Diese Spezifikationen werden von dem Dienst und Computerprofilen, die durch die Dienstverwaltung erzeugt wurden, erhalten. Vorzugsweise wendet die Datenzwischenspeicherungs-Managerkomponente für den DM 400 des IDNA/NGIN eine ,Client Side Caching'-Strategie an jedem Dienstknoten an.
Die IDNA/NGIN-Netzwerk-Betriebssystem („NOS")-Komponente 700 wird genauer hinsichtlich der 8–10 beschrieben. Wie erwähnt schließen die NOS-Funktionen das Ermöglichen von Interprozess-Kommunikationen, Objekt-Konnektivität und lokale und netzwerkweite Ressourcenmanagementfunktionen für das IDNA/NGIN-System 170 ein. Weil alle NGIN-Prozesse auf einer Vielzahl von Hardware- und Betriebssystemplattformen in einer weit verteilten Architektur ablaufen, stellt NOS plattformunabhängige und ortsunabhängige Kommunikationen aller Prozesse untereinander bereit. Insbesondere umfasst NOS mehrere funktionelle Unterkomponenten, um die Schnittstelle zwischen allen NGIN-Prozessen inklusive der Schnittstellen zwischen Dienststeuerung, Dienstverwaltung und Datenmanagement, bereitzustellen. Das NOS ist auch die Schnittstelle zwischen Switchanrufsteuerung und Dienststeuerung (5) und ermöglicht es zwei oder mehreren auf der gleichen SLEE ablaufenden Prozessen, miteinander zu kommunizieren.
Wie in den 8–10 gezeigt, enthalten die NOS-funktionellen Unterkomponenten: 1) einen Namensübersetzungs-(„NT")-Prozess 570, der logische Namen für Daten und Dienstobjekte in physikalische Adressen, die sowohl den Computer (als eine Netzwerkadresse) als auch die Speicheradresse, an der das angeforderte Objekt abläuft, identifiziert, auflöst; 2) Lokale-Ressourcen-Management- bzw. Local Resource Management („LRM")-Prozesse 575, 577, der den Zustand von in der SLEE und an einem Dienstknoten ablaufenden Ressourcen mitschreibt und behält; 3) einen globalen Netzwerk-Ressourcen-Zustands- bzw. Network Resource Status („NRS")-Prozess 590, der den Zustand aller Dienstknotenressourcen über das gesamte NGIN-Netzwerk behält und Interprozess-Kommunikationen bereitstellt; 4) einen Satz von Diensten zum Bereitstellen von Objekt-Konnektivität, sowie die durch eine Common Object Request Broker Architecture (CORBA) bereitgestellte kompatible ORB, die Kommunikationen zwischen Objekten aus unterschiedlichen Computerplattformen, API-Nachrichtensätzen und Internet Protocol (IP)-Kommunikationen ermöglicht, auf solch eine Weise, dass bestimmte Anforderungen an die Echtzeitanruf-Verarbeitungsleistung eingehalten oder übertroffen werden. Zum Beispiel sollte die typische Antwortzeit zur Verarbeitung eines typischen 1-800-Nummer „R-Gespräch"-Ereignisses ungefähr 50 bis 100 msec betragen.
Wie hierin beschrieben kann die NOS-Komponente 700 implementiert werden durch Benutzung eines CORBA-kompatiblen ORB für Objekt-Konnektivität, wie durch Orbix^®, entwickelt von IONA Technologies in Cambridge, MA und Dublin, Irland. Ein ORB stellt Kommunikationen zwischen Objekten auf unterschiedlichen Computerplattformen bereit, durch Bereitstellen eines Namensdienstes, der die Zuordnung von logischen Namen zu physikalischen Adressen ermöglicht.
Beim Systemstart wird die SLEE 450 gestartet und startet innerhalb ihrer Umgebung eine Instanz einer NOS-Client-Komponente 558 und eine Dienstmanagerprozesskomponente 554. Das SM SLP 554 holt den logischen Namen für andere Komponenten aus der Konfigurationsdatei 580, die die logischen Namen von unverzüglich zu instantiierenden Diensten umfasst. Es stellt dann dem logischen Namen den ORB-Namensdienst zur Verfügung, welcher diesen logischen Namen mit einer physikalischen Adresse verknüpft. Der ORB unterhält von diesem Zeitpunkt an die Dienstobjekt-Konnektivität. Der ORB-Namensdienst wird auch für andere Registrierungen von Diensten benutzt. Jeder auf einer SLEE gestartete Dienst registriert sich selbst bei NOS, und mittels dieser Registrierungen identifiziert der ORB physikalische Adressen für logische Namen.
Um plattformunabhängige Kommunikationen zwischen interaktiven Objekten zu implementieren, werden Schnittstellen definiert, wie durch eine Schnittstellendefinitionssprache („IDL") ermöglicht. CORBA unterstützt IDL zur Zeit, andere objekt-orientierte Kommunikationstechnologien, wie das remote method invocation (RMI)-Protokoll können jedoch implementiert werden, solange die Leistungsanforderungen an die Echtzeit-Anrufverarbeitung eingehalten werden. Insbesondere werden die Schnittstellen für jede der NGIN-Komponenten zur Zeit ihrer Erzeugung definiert und werden zur Laufzeit durch Speicherung in einem beständigen Datenspeicher oder einer Bibliothek (nicht gezeigt), die dem lokalen LRM 575 zugeordnet ist, verfügbar gemacht, wie in 9 gezeigt. Dienste werden befähigt, diese Bibliothek abzufragen, um neue Objektschnittstellen kennen zu lernen. Der NOS-Clientprozess 558 und NOS-Master 560 (8) ist eine NOS-Klassenbibliothek, die zur Bildung einer Schnittstelle mit NOS-Diensten benutzt wird und von allen innerhalb dieser SLEE ablaufenden Dienste benutzt wird, um NOS NT- und LRM-Dienste aufzurufen, wie hierin genauer beschrieben werden wird.
Jetzt Bezug nehmend auf 9 wird die funktionelle Architektur der NOS NT-funktionellen Unterkomponente 570 und LRM-funktionellen Unterkomponente 575 dargestellt, die auf einem Computer angesiedelt sind, und eine oder mehrere SLEEs 450 und 450' ausführen, wobei eine NT- und LRM-Unterkomponente mit jeder SLEE assoziiert ist. 9 stellt insbesondere ein Beispiel eines einzelnen NGIN-Dienstknotens oder „Standorts" 45 dar, der wenigstens zwei Rechnersysteme 440 und 440', die jeweils die SLEE-Komponenten 450 und 450' und jeweils die NOS-Komponenten 700 und 700', welche je eine NT-funktionelle Unterkomponente 570 und 570' und je eine LRM-funktionelle Unterkomponente 575 und 575' enthalten, implementieren. Obwohl eine einzelne SLEE auf einem separaten Computer ablaufend gezeigt wird, sollte verstanden werden, dass zwei oder mehrere SLEEs auf dem gleichen Computer an einem einzelnen Standort operieren können. Ablaufend auf jeder SLEE 450, 460' gibt es mehrere mit S1, .., S4 benannte Dienstobjekte oder Prozesse, die ein SLP, LLP, CLP, ELP, ein beständig ablaufendes FD-Logikprogramm und ein NOS-Clientobjekt 558 oder ein anderer Prozess sein können.
Wie hierin beschrieben, enthält jede NOS NT-funktionelle Unterkomponente 570, 570' einen Prozess zur Identifizierung der korrekten Version von Daten oder dem zu benutzenden Dienstobjekt, und die optimale Instanz dieses zu benutzenden Objekts, insbesondere durch Erlauben eines Prozesses, jeden anderen Prozess aufzurufen, durch die Benutzung eines einzelnen, allgemeinen logischen Namens, der unverändert bleibt über verschiedene Versionen und Instanzen des aufgerufenen Prozesses hinweg. Somit kapselt die NOS NT-Komponente 570 Objektreferenzen, Versionierung und physikalische Orte von Instanzen von Prozessen.
Wie hierin beschrieben, stellt jede lokale Ressourcen Manager-(„LRM")-Komponente 575, 575' des NOS 700 an jedem Dienstknoten fest, welche Dienste auf welcher SLEE an einem Knoten auszuführen sind, mittels in einer Dienstprofil (Konfigurations)-Datei 580 enthaltener Konfigurationsregeln, die den Inhalt des von der SA zu speichernden in dem lokalen LRM-Zwischenspeicher eingespielte Inhalte des Dienstprofils enthalten kann. Der LRM liest diese im lokalen Zwischenspeicher in diesem Knoten gespeicherte Dienstprofildatei 580 zunächst, und stellt fest, auf welcher spezifischen SLEE ein Dienst gemäß den Regeln in der Dienstprofildatei auszuführen ist und welche Dienste aktiv (als beständige Objekte) in der SLEE auszuführen sind oder welche nur auf Anfrage zu instantiieren sind.
In der bevorzugten Ausführungsform ermöglicht der LRM 575 Konfiguration und Optimierung der Dienstausführung zur Laufzeit durch Mitschreiben der Gesundheit und des Zustands aller Dienststeuerungsprozesse. Insbesondere unterhält jede LRM-funktionelle Unterkomponente eine Liste aller Dienste, die zum Laufen auf dieser SLEE programmiert sind, welche Dienstprozesse (Objektreferenzen) auf einer SLEE aktiv ablaufen und den aktuellen Belastungszustand (Verarbeitungskapazität) der SLEE(s) an diesem Knoten auf der Grundlage von vorbestimmten Schwellwerten.
Genauer ist die SLEE (server)-LRM-Komponente 575 ein Satz von in einem lokalen Zwischenspeicher eingebaute Bibliotheken von Objektreferenzen, die jedem Objekt (logisches Programm) in dem System entsprechen und dessen Objektreferenz die Information über den Server enthält, wie die IP-Adresse und Portnummer, um die Kommunikation zu ermöglichen. Wenn neue Objekte innerhalb des Systems verfügbar werden, werden sie beim NOS registriert, d. h. eine Objektreferenz wird für sie zur Registrierung in dem lokalen Zwischenspeicher mittels dem Datenmanagement erzeugt.
Nach Abfrage seiner Dienstprofil (Konfigurations)-Datei 580 zur Feststellung, welche Dienste umgehend zu instantiieren sind, sendet die NOS LRM-Komponente 575 eine Aufforderung zur Dienstaktivierung NOS NT 570 an das aktive Dienst-Manager-Objekt 554 in der SLEE mittels der NOS-Client-Instanz 558, welche auch in der SLEE 450 abläuft. Das SM-Objekt 554 ist ein API-Objekt zum Ermöglichen der Steuerung von SLEE-Diensten. Zum Beispiel stellt es die Fähigkeit zum Instantiieren neuer Dienste bereit, wenn eine Anforderung für einen inaktiven Dienst empfangen wird. Das heißt, dass es fähig ist, einen Prozess-Thread dem Objekt zuzuweisen, wenn dieses instantiiert wird und der Dienst sich dann selber beim NOS mittels LRM 575 registriert. Wenn ein Dienst unter Benutzung seines logischen Namens durch einen anderen Dienst aufgerufen wird, benutzt der LRM die Regeln in der Konfigurationsdatei, um festzustellen, welche Instanz aufzurufen ist, durch Benutzung des ORB-Namensdienstes zur Verknüpfung des logischen Namens mit den physikalischen Adressen aktiver Instanzen.
Wie in 9 gezeigt, ist dem NGIN-Standort oder Dienstknoten 45 ein Standort LRM 577, welcher über eine NOS-Komponente 700'' auf einem separaten Computer 440'' oder auf einem gemeinsam genutzten Computer, wie dem Computer 440 oder dem Computer 440', ab läuft, zugeordnet. Der Standort LRM 577 fungiert zum: 1) Mitschreiben der Verfügbarkeit von Diensten an jeder SLEE, die eine Funktion der momentanen Belastung aller auf jeder SLEE ablaufenden Prozesse ist; und 2) Führen einer Ressourcen-Zustandsliste, die eine aktiv aktualisierte Kopie von jedem individuellen SLEE LRM 577 ist, mit dem Hinzufügen eines SLEE-Identifizierers für jede Ressource. Die Standort-LRM-Unterkomponente 577 bestimmt, welche Instanz eines angeforderten Dienstes benutzt werden sollte auf der Grundlage von mehreren Kriterien, einschließlich, aber nicht beschränkt auf: 1) die Nähe einer aufgerufenen Dienstinstanz zur Instanz des aufrufenden Dienstes (das Gleiche gegenüber einer unterschiedlichen SLEE, das Gleiche gegenüber einem unterschiedlichen Standort); 2) die Nähe der aufgerufenen Dienstinstanz zu den Daten des Datenmanagements, die vom aufgerufenen Dienst benötigt werden; und 3) die momentanen System- und Prozesslasten.
Ein in 9 dargestelltes Beispiel: immer wenn ein Prozess, zum Beispiel S1 in SLEE 1, ein SLP, S4, instantiieren muss, um einen bestimmten Prozess auszuführen, z. B. Vnet-Dienst, macht NOS zunächst eine Feststellung, ob der Dienst, d. h. dessen Objektreferenz, im lokalen Speicher verfügbar ist, z. B. im SLEE 1. Wenn der lokale LRM 575 die Referenz auf das angeforderte Objekt nicht hat, sucht NOS im LRM 577 auf Standortebene, um den Ort dieser dem angeforderten Dienst entsprechenden bestimmten Objektreferenz zu bestimmen. Zum Beispiel kann das Objekt in SLEE 2 gefunden werden, wie in 9 gezeigt, und wenn es gefunden ist, wird NOS diesen Dienst durch Instantiierung einer Instanz dieses Objektes verfügbar machen, falls SLEE die Kapazität hat, dies so zu tun, d. h. ihr Benutzungsschwellwert noch nicht erreicht wurde.
Wie weiterhin in 10 gezeigt, enthält die NOS-Komponente 700 zusätzlich zu je einem LRM 575 für jede SLEE und LRM 577 für jeden Standort eine Network Ressource Status („NRS")-Unterkomponente 590, die ein Prozess ist, der eine netzwerkweite Ressourcen-Management-Funktion erfüllt. Inbesondere enthält der NRS eine Untermenge der von jedem Standort LRM unterhaltenen Daten, für jeden Standort LRM im Netzwerk, z. B. Standort LRMs 577a,.., 577c entsprechend jeweils den Standorten 440a–440c in 10. Der NRS 590 enthält: 1) eine Liste der SLEEs; 2) welcher Typen von Diensten zum Ablauf auf jeder SLEE programmiert sind, und 3) welche Dienste auf jeder SLEE aktiv ablaufen, d. h. die momentane Last der SLEE als eine Prozentgrundlage. Diese NRS-Unterkomponente 590 ist eine logischerweise zentralisierte Funktion, die NRS eine weitere Ebene der Verbreitung von An forderungen, die die Standort-LRMs 577a,.., 577c nicht befriedigen können, gibt. Zusätzlich enthält die NRS-Unterkomponente 590 einen binären Indikator für jede SLEE 450 zur Anzeige, ob die SLEE in Betrieb ist oder nicht, und ob ein Dienst-Benutzungsschwellwert von dieser SLEE erreicht wurde. Die Anwendung des „in Betrieb"- oder „nicht in Betrieb"-Indikators und des Benutzungsschwellwerts werden benutzt, um festzustellen, ob eine SLEE verfügbar ist, um Dienstanforderungen von anderen Diensten zu akzeptieren und die NRS-Unterkomponente kann einfach einen binären Indikator, ob oder nicht eine SLEE verfügbar ist, bereitstellen, wenn dieser Indikator und die Anwendung des Schwellwerts gegeben sind. Beispielweise, wenn ein angefordertes SLP-Objekt in einer SLEE gefunden wird, diese SLEE jedoch nicht die Kapazität zur Instantiierung des angeforderten Prozesses hat, wird sie eine Benachrichtigung an den Standort LRM 577 senden, dass der Benutzungs-Schwellwert für diese SLEE erreicht wurde, und sie nicht in der Lage ist, weitere Anforderungen für diesen Dienst zu behandeln. Diese Information wird auch an die NRS-Komponente 590 weitergeleitet (10).
Wieder auf 8 Bezug nehmend, implementiert das NGIN-System einen Überwachungsmechanismus 595 zur Überwachung der Speicherkapazität, Datenbankkapazität, Länge einer Warteschlange für angeforderte Objekte, Menge der Zeit in der Warteschlange und andere Ressourcen/Belastungsparameter für jede SLEE in dem System. Diese Faktoren sind für das NOS 700 verfügbar, welches ein Festlegen über die Benutzungsschwellwerte der SLEE's auf Grundlage von einem oder mehrerer dieser Faktoren macht. Zusätzlich zu einem festen Schwellwert können mehrere Schwellwerte als Hysterese benutzt werden.
Ein erläuterndes Beispiel der vom NOS ausgeführten Managementfunktionen inklusive NT, LRM und NRS, die NOS 700 das Bereitstellen von Standort- und Plattform-unabhängiger Verarbeitung ermöglichen, bei gleichzeitiger Aktivierung der generellen Verarbeitungsfähigkeiten von NGIN, wird jetzt mehr ins Detail gehend im Hinblick auf 11(a)–11(b) beschrieben. In dem mit Bezug auf 11(a) und 11(b) beschriebenen LRM-Prozessfluss 801 wird angenommen, dass ein auf SLEE 1 auf einem Dienstkontrollerserver 1 ablaufender Dienst S1 einen Dienst S2 aufrufen muss, wie in Schritt 802 angedeutet. Dienst S1 kann ein FD oder ein logisches Dienstprogramm sein, das ein Ereignis mit einer Dienstanforderung von einer Switching-Fabric-Rufsteuerung empfangen hat und ein anderes SLP, S2 z. B., aufrufen muss, um die Anrufverarbeitung zu vollenden.
Insbesondere setzt Dienst S1 im Hinblick auf 11(a) eine Anforderung an NOS 700 unter Benutzung des logischen Namens von SLP S2 ab. Wenn die SLP-Anforderung für ein Dienstobjekt empfangen wird, wird die NOS-Namensübersetzungsfunktion 570a wie in Schritt 804 gezeigt, implementiert, um festzustellen, ob das NOS den angeforderten Dienst als aktiv auf dem lokalen Dienststeuerungsserver 1 erkennt, d. h. eine Objektreferenz, die mit dem logischen Namen des angeforderten Dienstes assoziiert ist, hat. Vorzugsweise enthalten die im lokalen Serverzwischenspeicher gespeicherten Daten die folgenden NOS-Namensdatenfelder: 1) ein SLP-logischer Dienstname, der typischerweise der den Dienst beschreibende logische Name ist und der Name, auf den die Eigenschaftsunterscheidungsdaten zeigen; 2) eine optionale Versionsnummer, die die Version eines bestimmten Dienstes, die benötigt werden könnte, beschreibt, z. B. für einen speziellen Kunden, der diese Version eines laufenden Dienstes benötigt, oder einen Knoten, etc.; 3) der Zustand inklusive: eingesetzt, d. h. wenn die SA Arbeitspakete am Knoten in Betrieb genommen hat, die Dienste jedoch nicht aktiviert sind, aktiv, d. h. anzeigend, dass der Dienst im Augenblick aktiv ist, oder Rückgriff (fallback), wenn ein Rückgriff auf eine vorhergehende Version eines Dienstobjektes gewünscht ist, z. B. um eine schnelle Umkehrung bereitzustellen; 4) der Objektname oder die Referenz, der/die eine IP-Adresse, Port und andere den physikalischen Standort einer Objektinstanz identifizierende Information enthalten kann; 5) das Datum und die Zeit der Aufnahme des Betriebs und der Beendigung des Betriebs; 6) der Objektname des Fehlerprozesses, z. B. falls das Objekt nicht verfügbar ist oder nicht aktiviert werden kann; und 7) der Rückgriff-Objektname, welcher auszuführen ist, wenn es sich im Rückgriffzustand befindet. Ein lokaler Server NOS mit Namensgebungsprozess ist von Diensten begünstigt, die von einem LRM-Zustandsprozessor (nicht gezeigt), der die lokale Serverzwischenspeicher-Zustandsdatenbank nur mit momentan aktiven Diensten, die in einer bestimmten SLEE im Dienststeuerungserver ablaufen, aktiviert, bereitstellt. Dies ist so, damit die lokale Server-NOS-Namensübersetzungsfunktion zunächst lokal ausgeführt werden kann. Wenn NOS zu Beginn eine Namensanforderung bekommt, schaut es bei einem logischen Namen zum Erhalt eines Objektnamens (oder Objektreferenz) nach. NOS bekommt den Objektnamen von dem logischen Namen und der Knoten-LRM-Prozess bestimmt die beste Instanz des angeforderten Objekts, die anzusprechen ist auf der Grundlage von einer oder mehreren Geschäftsregeln, wie in Schritt 806 angedeutet.
Wenn bei Schritt 804 der logische Name erkannt und die Objektreferenz verfügbar ist, dann geht der Prozess zur LRM-Funktion in Schritt 806 über, um aktive („verfügbare"), auf der SLEE ablaufende Instanzen von S2 gemäß bestimmter Kriterien, wie Benutzungsschwellwerte, zu bestimmen. Wenn keine aktiven Instanzen gefunden werden, kann der LRM überprüfen, ob S2 zur Ausführung auf SLEE 1 programmiert ist, jedoch noch nicht instantiiert wurde. Wenn dies der Fall ist, kann NOS 700 entscheiden, dass eine Instanz von S2 auf SLEE 1 instantiiert wird, falls SLEE 1 genügend verfügbare Kapazität hat. Wie erwähnt weiß der LRM auf Serverebene nur, was auf dem Server aktiv ist und weiß, was instantiiert wurde. Wenn das Objekt momentan aktiv und instantiiert auf der lokalen Serverebene ist, dann wird die Objektreferenz zur Instantiierung eines neuen Threads für diesen Dienst an die SLP-Anforderung zurückgegeben. NOS wird die Instantiierung eines neuen Dienst-Threads zur Ausführung des angeforderten Dienstes auf der Grundlage der zurückgegebenen Objektreferenz auslösen und gibt eine Objektreferenz zurück, falls diese nicht bereits instantiiert ist.
Falls in Schritt 804 festgestellt wird, dass SLEE 1 nicht beliebig verfügbare Kapazität besitzt, oder falls S2 nicht zur Ausführung auf SLEE 1 verfügbar ist, dann sendet der LRM auf SLEE 1 in Schritt 810 eine Dienstanforderung an den Standort LRM 577a (10). Der Standort LRM wendet ähnliche Geschäftsregeln an und bestimmt, ob eine Instanz von S2 aktiv ist, oder ob eine instantiiert werden sollte auf einer anderen SLEE an diesem Standort. Somit wird im Schritt 810 die Knoten-NOS-Namensübersetzungsfunktion implementiert zur Feststellung, ob der angeforderte logische Name an diesem Knoten verfügbar ist, d. h. ob eine andere SLEE am gleichen oder an einem unterschiedlichen lokalen Dienststeuerungsserver an diesem Knoten eine mit dem logischen Namen des angeforderten Dienstes assoziierte Objektreferenz unterhält. Falls der logische Dienstname im Schritt 810 erkannt wird, fragt die NT-Unterkomponente 570 NOS LRM 575 ab, um festzustellen, welche Instanz von S2 zu benutzen ist. Der Knoten-LRM wendet dann Geschäftsregeln gegen eine Knotenzwischenspeicher-Zustandsdatenbank (nicht gezeigt) im Schritt 814 an, um die gewünschte Objektreferenz für den angeforderten Dienst, wenn aktiv, zu erhalten, und gibt diese Adresse an das aufrufende SLP (Schritt 802, 11(a)) zurück. Falls festgestellt wird, dass der Dienst momentan nicht instantiiert ist oder dass der angeforderte Dienst auf einer bestimmten SLEE nicht instantiiert werden kann, aufgrund von Prozesslast oder anderen auferlegten Beschränkungen, dann wird in Schritt 818 ein Zuweisungs- und Ladeprozess durch Überprüfung der Knotenzwischenspeicher-Zustandsdatenbank und Implementierung anwendbarer Geschäftsregeln, die sich auf z. B.
Dienstnähe, Datennähe, Schwellwerte, momentane Verarbeitungslasten, etc. beziehen, durchgeführt, womit der angeforderte Dienst in der SLEE, wo festgestellt wurde, dass das Dienstobjekt für die Instantiierung fähig ist, instantiiert wird und die Adresse an das aufrufende SLP zurückgegeben wird. Es sollte verstanden werden, dass ein Ringschema implementiert werden kann, mit der Bestimmung, welcher Dienst-Thread zu instantiieren ist, wenn mehr als ein Dienst pro SLEE für die Instantiierung verfügbar ist.
Wieder mit Bezug auf 11(a), wenn in Schritt 810 festgestellt wird, dass der momentane Knoten den angeforderten logischen Namen nicht erkennt, d. h. der Knotenzwischenspeicher hat keine Objektreferenz, die mit dem logischen Namen des angeforderten Dienstes assoziiert ist, oder aufgrund von angewendeten Geschäftsregeln das Objekt an dem Knoten nicht instantiieren kann, dann wird der globale Netzwerk-Ressourcen-Status-, bzw. Network Resource Status (NRS)-Prozess 590 in Schritt 822 gefragt, den aktuellen Zustand von SLEEs in dem intelligenten Netzwerk 170 zu prüfen und eine SLEE festzustellen, die die Dienstanforderung für S2 behandeln kann. Zuvor wird, wie in Schritt 820 dargestellt, eine Überprüfung gemacht, um festzustellen, ob eine Indexnummer, die die Anzahl der Male, die das Netzwerk-Ressourcen-Management zwecks Finden einer Objektreferenz befragt wurde, repräsentiert, einen voreingestellten Grenzwert, z. B. dreimal, überschreitet. Wenn dieser Schwellwert überschritten wurde, wird der Prozess beendet und der Administrator wird benachrichtigt, dass das Dienstobjekt nicht gefunden werden kann, und dass eine Fehlerbedingung existiert, wie in Schritt 821 dargestellt. Wenn der NRS-Abfrageschwellwert nicht überschritten wurde, bestimmt der NRS-Prozess 590, welcher Dienstknoten im Netzwerk fähig sein könnte, den angeforderten Dienst auszuführen, wie in Schritt 822 dargestellt. Nach Bestimmung des Knotens im intelligenten Netzwerk, wie in Schritt 822 dargestellt, fährt der Prozess mit Schritt 824, 11(b), fort, wo die Knoten-NOS-Namensübersetzungsfunktion 570b implementiert ist, um eine mit dem logischen Namen des angeforderten Dienstes assoziierte Objektreferenz zu erhalten. Wenn der logische Dienstname an diesem Knoten in Schritt 824 nicht erkannt wird, dann wird die NRS-Anfrage-Indexnummer um eins erhöht in Schritt 829, und der Prozess geht zurück zu Schritt 820, 11(a), um zu überprüfen, ob der Indexnummer-Schwellwert überschritten wurde, woraufhin eine Fehlerbedingung existiert. Falls in Schritt 820, 11(a) der NRS-Abfrageindex nicht den voreingestellten Schwellwert überschritten hat, wird der NRS-Prozess 590 nochmals in Schritt 822 abgefragt, um einen neuen Standort eines verfügbaren Dienstes an einem anderen Dienstknoten zu finden.
Wenn der logische Name in Schritt 824 erkannt wird, fährt der Prozess mit Schritt 826 fort, um eine Adresse zu bestimmen, die mit der angeforderten Objektreferenz gemäß akzeptierbaren Verarbeitungslasten assoziiert ist. Diese Adresse wird dann an das anfordernde SLP, wie in Schritt 802, 11(a), gezeigt, zurückgegeben. Falls in Schritt 826 festgestellt wird, dass der Dienst momentan nicht instantiiert (aktiv) ist, dann fährt der Prozess mit Schritt 828 fort, um einen Zuweisungs- und Ladeprozess zu ermöglichen durch Überprüfung der Knotenzwischenspeicher-Zustandsdatenbank 768 an diesem Knoten, Implementieren von Geschäftsregeln und Instantiieren des angeforderten Dienstes in der SLEE, wo festgestellt wird, dass das Dienstobjekt für die Instantiierung verfügbar ist. Im Weiteren wird die Adresse des instantiierten Objekt-SLP an den anfordernden Client in Schritt 824 zurückgegeben.
Wenn erst einmal eine aktive Instanz von S2 ausgewählt wurde, wird die Objektreferenz für diese S2-Instanz am NT auf SLEE 1 zurückgegeben (Schritt 802). Der NT übersetzt den logischen Namen S2 sodann effektiv in einen Objektidentifizierer für die gewählte Instanz von S2 und benutzt diesen Objektidentifizierer für S2 in den fortschreitenden Interprozess-Kommunikationen zwischen S1 und S2. Der Objektidentifizierer enthält eine IP-Adresse, Port und andere den physikalischen Standort der Objektinstanz identifizierende Information. Wenn eine Objektreferenz bestimmt ist, stellt NOS sodann Objekt-Konnektivität zwischen den zwei Diensten durch Implementierung eines CORBA-kompatiblen ORB's bereit, und Datenkommunikationsverbindungslose Protokolle wie UDP/IP. Der Standort des aufgerufenen Dienste, egal ob auf der gleichen SLEE ablaufend oder auf einer anderen SLEE an einem anderen Standort tausende Meilen entfernt, ist für den aufrufenden Dienst vollständig transparent. Somit, falls ein SLP zur Bedienung eines Anrufes auf einer SLEE an einem entfernten Standort instantiiert wird, wird der Anruf immer noch auf dem Switch gehalten, auf dem er empfangen wurde. Vorzugsweise stellt NOS sicher, sobald auf eine Objektreferenz einmal zugegriffen wurde, zum Beispiel an einem anderen Standort mittels der NOS-Ebene, dass die Objektreferenz am anfordernden Standort für zukünftige Referenzen zwischengespeichert wird und durch die Dienstverwaltung geprüft wird. Somit wird in diesem Beispiel zur Reduzierung von folgenden Markierungen (look-ups) durch Auslösen einer Standort-LRM-Markierung, wenn dieser Dienst wieder benötigt wird, die Objektreferenz für Dienst S2, wo auch immer sie lokalisiert ist, danach im lokalen Zwischenspeicher im LRM 575 vom SLEE 1 zwischen gespeichert. Es sollte für fähige Fachleute offensichtlich sein, dass es eine Vielzahl von Arten gibt, auf die Dienstobjektreferenzdaten in einer SLEE bereitgestellt werden können.
Beispielsweise kann ein NOS-Datenreplikationsmechanismus eingesetzt werden, um alle Objektreferenzen an einem Standort-LRM 577 an jedem LRM für jede SLEE an diesem Standort replizieren.
Im Zusammenhang mit einem 1-800-Anruf („18C") wird nun ein 18C-Anrufverarbeitungsund Dienstbenutzungsszenario beispielhaft beschrieben, wobei auf das Flussdiagramm in 13(a)–13(c) und das konzeptuell-funktionelle Diagramm in 18 Bezug genommen wird. Zunächst kommt, wie in Schritt 920 gezeigt, ein Anruf an dem NGS-Switching-Fabric 75 an. Wenn das NGS den Anruf empfängt, stellt eine Trägersteuerungskomponente (5) die Anrufsteuerungskomponente mit der Eingangsleitung, auf der der Anruf empfangen wurde, sowie die ANI, die gewählte Nummer und andere für die Anrufverarbeitung benötigte Daten zur Verfügung. Eine Anrufsteuerungskomponente unterhält ein Zustandsmodell für den Anruf das gemäß seiner programmierten Logik ausgeführt wird. Zusätzlich sind in dem Zustandsmodell Auslösesignale (Trigger) für die Instantiierung eines ELP 540 und das Senden einer Dienstanforderung an einen FD 510, wie in 18 gezeigt, enthalten. Um ein ELP zu instantiieren, adressiert die NGS-Anrufsteuerungskomponente 90 eine Nachricht NOS unter Benutzung eines logischen Namens für ein ELP, wie in Schritt 923 in 13(a) angedeutet. Das NOS sendet als Antwort eine Nachricht an ein Service-Managerobjekt (8), um ein ELP innerhalb einer SLEE zu instantiieren und gibt eine Objektreferenz für dieses ELP an die Anrufsteuerung zurück, wie in Schritt 926 dargestellt. Die NGS-Anrufsteuerungskomponente nimmt diese Objektreferenz in eine Dienstanforderungsnachricht auf, die an ein FD in der SLEE gesendet wird, wie in Schritt 929 angedeutet. Somit werden alle qualifizierten Ereignisdaten, die für den Anruf von irgendeinem Prozess erzeugt werden, an den instantiierten ELP-Prozess geschrieben. Insbesondere ist die Dienstanforderungsnachricht an einen logischen Namen für FD adressiert; dieser logische Name wird von der NOS NT-Komponente in eine physikalische Adresse für ein FD-logisches Programm, welches am gleichen Dienstknoten, an dem der Anruf empfangen wurde, abläuft, übersetzt. In der Dienstanforderungsnachricht sind die gewählte Nummer, ANI und andere Daten enthalten.
Als Nächstes benutzt der FD, wie in Schritt 931 angedeutet, seine Eigenschaftsunterscheidungstabelle, um zu identifizieren, welches SLP die empfangene Dienstanforderung behandeln soll. Wenn zum Beispiel die empfangene Nachricht eine 18C-Dienstanforderung ist, so ist diese von dem 18C SLP zu behandeln. Die nachfolgende Tabelle 3 ist ein Beispiel einer verkürzten FD-Tabelle mit Einträgen inklusive Zeigern auf verschiedene „gebührenfreie", z. B. 1-800-Anrufdienste.
Entry Port Table
„001001" SLP pointer 'Vnet'
„001002" Table pointer to FGD table
FGD table
1800* table pointer 800 table
1888* table pointer 800 table
1900* table pointer 900 table
1* SLP pointer Local number'
800 table
1800collectSLP pointer to '1-800-C'
1800888000SLP pointer 'Op Service'
1800* SLP pointer '800 service'
1888* SLP pointer '800 service'
wobei FGD der Eigenschaften-Gruppen-Unterscheiden ist. Insbesondere auf der Grundlage der Herkunft des Anrufs im Netzwerk (Schalttafel) und des Typs des empfangenen Anrufs (z. B. 1–800), wird der FD einen geeigneten SLP-logischen Namen festlegen. Zum Beispiel zeigt die Identifikation „001002" den Empfang eines Anrufs, welcher ein Nachschauen in der FGD-Tabelle (Zeiger auf FGD-Tabelle) erfordert. Die FGD-Tabelle wiederum unterhält Zeiger auf andere Tabellen, abhängig von der gewählten Nummer, z. B. 800*, wobei ein einfaches '*' ein Begrenzungszeichen ist. Von dieser 800-Tabelle erhält der FD zum Beispiel ei nen Zeiger auf den angeforderten SLP-logischen Namen. Nachflgend wird dieses SLP aufgerufen und die Dienstanfrage wird am NOS übergeben, welches ein CLP 545-, ein LLPO 530- und SLP 520-Objekt gemäß dem angeforderten 18C-Dienst instantiiert. Zum Beispiel wird mit Bezug auf das LLPO ein logischer Name für das LLPO für NOS bereitgestellt auf der Grundlage der Trägersteuerungsleitung, auf der der Anruf entgegengenommen wurde. Die Identifikation dieser Leitung basiert entweder auf ANI oder die Eingangsleitung wird von der Trägersteuerungskomponente 80 identifiziert. Die ANI identifiziert die ursprüngliche Eingangsleitung, auf der der Anruf abgesetzt wurde, die die gleiche oder auch nicht die gleiche Eingangsleitung sein kann, auf der das NGS den Anruf empfängt, d. h. der empfangene Anruf kann zum Beispiel auf einem lokalen Netzwerk abgesetzt worden sein und am Switch 75 an ein Fernvermittlungsträgernetzwerk übergeben worden sein. Daher können an eine Leitung gebundene Eigenschaften, wie Anklopfen oder Unterbrechung von der ANI identifiziert werden. Das NOS übersetzt den logischen Namen für das LLPO in eine physikalische Adresse zwecks LLPO-Instantiierung. Während andere logische Programm (wie z. B. SLPs) an anderen Standorten instantiiert werden können, werden die LLPs an dem Standort instantiiert, an dem sich die mit ihnen assoziierten Leitungen befinden. Die LLPs werden in der SLEE instantiiert, was auf einem Dienststeuerungsserver oder einem Anrufsteuerungsserver sein kann. Wenn es einmal instantiiert ist, fragt das LLPO im Datenmanagement nach an die Leitung gebundenen Eigenschaften, behält den Zustand der Herkunftsleitung und wird sämtliche Eigenschaften wie Anklopfen oder Überfluss-Routing (overflow routing) aufrufen, wenn diese Eigenschaften vom Anrufer (d. h. Anklopfen) oder vom Netzwerk (d. h. overflow routing) aufgerufen werden.
Mit Bezug auf Schritt 934, 13(a), empfängt das NOS eine Übergabeanforderung einer Dienstanforderung vom Eigenschaftenunterscheider, die den den bestimmten aufzurufenden Dienst repräsentierenden logischen Namen enthält, z. B. 18C. Das NOS identifiziert, dass diese Anforderung einen logischen Namen enthält und schaut in seiner Instanzentabelle (nicht gezeigt) nach, um festzustellen, ob es irgendwelche SLP-Prozesse zur Bedienung dieser Dienstanforderung verfügbar hat. Es identifiziert auch über die NOS LRM-Funktion, welche Instanz des angeforderten Typs zu benutzen ist, wie in Schritt 937 angedeutet. Dann sendet das NOS, wie in Schritt 941 angedeutet, eine Anforderung an das Service-Managerobjekt, welches auf einer Dienststeuerungs-SLEE abläuft, um den angeforderten 18C-SLP-Dienst aufzurufen. In der bevorzugten Ausführungsform wählt NOS das SLP von einem Dienststeue rungsserver, welcher die ursprüngliche hereinkommende Dienstanforderungsbenachrichtigung vom NGS erhalten hat, jedoch ist dies so verstanden, dass NOS das SLP in irgendeiner Dienststeuerungskomponente durch die Implementierung des NOS LRM basierend auf seiner Liste von Dienststeuerungsinstanzen und deren aktuellen Zustand wählen könnte. Wie in Schritt 943 angedeutet, stellt NOS fest, ob das gewählte SLP bereits instantiiert ist, und wenn das gewählte SLP nicht bereits instantiiert ist, wird es den SM zur Instantiierung des SLP-Objektes anweisen, wie in Schritt 946 angedeutet. Andernfalls, wenn das gewählte SLP bereits instantiiert ist, weist der Thread-Manager dem SLP-Objekt einen neuen Prozess-Thread zu, wie in Schritt 945 angedeutet.
Der nächste Schritt 949 von 13(b) erfordert, dass der instantiierte SLP-Prozess seine physikalische Adresse beim NOS registriert, und dass das NOS dieses SLP an die Dienstanforderung allokiert. Dann übergibt das NOS die Dienstanforderungsübergabenachricht an das neue SLP, wie in Schritt 951 angedeutet. Parallel dazu sendet das NOS alle Daten an das instantiierte CLP, einschließlich Objektreferenzen für die instantiierten SLP-, ELP- und LLPO- Objekte. Objektreferenzen für das CLP und ELP werden auch für das LLPO und das SLP bereitgestellt, so dass das LLPO und das SLP eine Schnittstellenverbindung mit dem CLP und dem ELP aufnehmen können. Schließlich, wie in Schritt 954 gezeigt, beginnt das SLP mit der Verarbeitung des Anrufs gemäß seiner progammierten Logik.
Im Zusammenhang mit einem 18C-Anruf erhält das 18C-SLP 520 vorzugsweise die benötigten Daten von einer 18C-Routing-Datenbank (nicht gezeigt), um eine geeignete Entscheidung zu treffen. Wie in 13(c) gezeigt, ruft das 18C SLP 520 folgende Schritte auf Senden eines logischen Namens für die 18C-Routing-Datenbank, den es benötigt, an das NOS NT in Schritt 960; Abfragen des DM mit dem logischen 18C Routing-Datenbanknamen und Empfangen des eigentlichen 18C-Routing DB-Namens vom DM sowie dessen Speicherort, wie in Schritt 962 angedeutet; Anfordern des NOS LRM, um festzustellen, ob die 18C-Routing-Datenbank lokal verfügbar ist, wie in Schritt 964 gezeigt, und, wenn ja, Rückgabe der physikalischen Adresse der 18C-Datenbank an das 18C SLP, wie in Schritt 966 angedeutet; Senden einer Anfrage an Datenmanagement für einen Kundenprofilauszug durch Senden der angerufenen 800-Nummer, der Leitungs-ID, Herkunfts-Switch-Stamm und der ANI, wie in Schritt 968 angedeutet; Empfangen vom DM der endgültigen Routing-Informationen einschließlich des Switches/Stamms zurück an das 18C SLP, wie in Schritt 970 angedeutet, und im Schritt 972, Auffordern des DM, den eigentlichen Zielstandort (Knoten) des in der Routing-Antwort spezifizierten Ziels nachzuschauen und Empfangen von DM-Zielknotenstandort. Danach zieht die Prozedur das Senden von Routing-Antwortinformationen an das ELP 510 zur Übernahme in den Anrufkontextdaten, z. B. im DM gespeichert, nach sich; und Senden einer Herauswählanforderung mit Übergabebefehl an das CLP 545 einschließlich der Routing-Information. In diesem Szenario kann der Zielknoten entfernt sein, wodurch es nötig wäre, das Ziel-LLP auf den entfernten Knoten zu instantiieren und das Profil nachzuschlagen, um irgendwelche Eigenschaften der Zielleitung festzustellen. In anderen Dienstflussszenarien kann das SLP einen oder mehrere andere SLPs aufrufen müssen.
Wenn das SLP ein Netzziel für den Anruf bestimmt hat, oder auf andere Weise ein Ressourcen-Komplex auszuführende Aktionen bestimmt hat, z. B. Detektion von DTMF-Ziffern oder Abspielen von Sprache, sendet es eine Dienstantwortnachricht an NGS-Anrufsteuerung, wie in Schritt 257 angedeutet. Die Anrufsteuerung führt dann die Instruktionen aus, die verbunden sein können mit einer Anweisung an den NGS-Switch 75' (14), den Anruf aufzubauen und zu vervollständigen, bis zu einem Netzwerkziel, wie in Schritt 959 gezeigt.
Genauer wird eine Herauswahl/Übergabeprozedur implementiert, die vom CLPL 545 das Senden der Herauswahl mit dem Übergabebefehl an das LLPO (Herkunftsleitung), welche an einen NOS-Agenten am Anruf-Switch weitergeleitet ist, welche den Anruf bis zum Zielknoten routet, erfordert. Der ELP-Prozess schreibt dann die Herauswahlanruf-Kontextdaten an den DM.
Zurück zu Schritt 957, falls das SLP an die Anrufsteuerung eine physikalische Adresse für ein Netzwerkziel zurückgibt, dann wird ein LLPT-Prozess 531 für die Leitung, für die der Anruf bestimmt ist, instantiiert. Dies wird durch die Freigabe für NOS einen logischen Namen für das LLPT mit dem vom SLP bereitgestellten Netzwerkziel zu assozieren, ermöglicht; dieser logische Name wird dem NOS entweder durch das SLP (in einer Ausführungsform) oder durch Anrufsteuerung in einer Dienstanforderung an ein FD (in einer anderen Ausführungsform) zur Verfügung gestellt. Das NOS wiederum instantiiert das LLPT in einer SLEE an dem Dienstknoten, an dem die Zielleitung existiert.
Alternativ kann das SLP in Schritt 957 stattdessen eine Anforderung für eine spezifische Ressource zurückgeben, wie zum Beispiel eine NR-Funktion, im Beispiel der Verarbeitung von 18C-Anrufen. Das NGS bestimmt, welche Ressource zugewiesen werden soll, d. h. welcher Switch-Port mit IVR-Fähigkeiten, VRU-Port, etc. und gibt an das SLP eine Adresse für die Ressourcce zurück. Das SLP identifizien eine Adresse für das mit dieser Ressource assoziierte LLPT (mittels Anfrage an Datenmanagement) und fordert die Instantiierung dieses LLPT's an. Der Anruf wird dann an diese Ressource geleitet und verarbeitet, unter Umständen mit einer weiteren Dienstanforderung an NGIN.
Wenn der Anruf beendet ist (d. h. wenn beide Parteien die Verbindung unterbrochen haben), empfangen die LLPs eine Anrufbeendigungsnachricht von der NOS-Komponente an jedem Switch 75, 75' (14) und leiten die Anrufbeendigungsbenachrichtigung an das CLP weiter. Das CLP leitet die Anrufbeendigungsbenachrichtigung an die assoziieren LLPs und das ELP weiter und werden beendet, was durch die CLP-Benachrichtigung ausgelöst wird. Vor seiner Beendigung können ELP-Anrufdetaildaten, welche nach Beendigung des Anrufs erhalten bleiben müssen, z. B. für Rechnungsstellung und verschiedene andere Zwecke, zuerst gespeichert werden.
Einige bevorzugte Ausführungsformen wurden im Detail oben beschrieben. Es ist zu verstehen, dass der Umfang der Erfindung auch Ausführungsformen begreift, die sich von den beschriebenen unterscheidet, jedoch innerhalb des Umfangs der Ansprüche sind.
Zum Beispiel ist der Mehrzweckcomputer als eine Rechenvorrichtung zu verstehen, die nicht speziell für einen Anwendungstyp gemacht ist. Der Mehrzweckcomputer kann eine beliebige Rechenvorrichtung von beliebiger Größe sein, die die zur Implementierung der Erfindung benötigten Funktionen ausführen kann.
Ein weiteres Beispiel ist die „Java"-Programmiersprache, die durch andere äquivalente Programmiersprachen ersetzt werden kann, welche ähnliche Eigenschaften haben und ähnliche Funktionen, wie sie zur Implementierung der Erfindung erforderlich sind, ausführen.
Die Benutzung dieser Begriffe hierin, sowie der anderen Begriffe, ist nicht als Beschränkung der Erfindung auf diese Begriffe allein gemeint. Die benutzten Begriffe können durch andere ausgetauscht werden, die Synonyme sind und/oder sich auf äquivalente Dinge beziehen. Wörter der Einbeziehung sind als nicht erschöpfend zu interpretieren bei Berücksichtigung des Umfangs der Erfindung. Es sollte auch verstanden werden, dass verschiedene Ausführungsformen der Erfindung Hardware, Software oder mikrocodierte Firmware verwenden oder in dieser verkörpert sein können.

Claims

Servicekontrollsystem für ein Kommunikationsnetzwerk mit einer Vielzahl von Serviceknoten, wobei jeder Knoten eine Datenspeichereinrichtung und eine Ausführungsumgebung zur Durchführung von Services als Antwort auf den Empfang eines Ereignisses an einem Netzwerkschaltelement, einem Serviceknoten zugeordnet, besitzt, wobei das System folgendes umfasst: eine Serviceadministratoreinrichtung zur Erzeugung eines Serviceprofils an jedem Knoten, ein Serviceprofil, einschließend den Typ und die Menge von Serviceobjektresourcen bezüglich der Serviceverarbeitung an jedem Knoten, sowie zum Herunterladen des Typs und der Menge der Serviceobjektresourcen zu den Knoten entsprechend dem Profil; einen Instantiierunsgsmechanismus zur Instantiierung von Serviceobjekten zur Ausführung in der einen oder den mehreren Ausführungsumgebungen; und eine Resourcenmanagementeinrichtung zur Verfolgung von Ausführungsumgebungsresourcen an einem Serviceknoten, und zum erhalten einer Liste von Servicetypen, verfügbar an jedem Serviceknoten in dem Netzwerk, wobei jeder Servicetyp einen zugeordneten Potentialstatus besitzt, der anzeigt, ob ein angefragter Service verfügbar ist für die Instantiierung an einen Serviceknoten, wobei, wenn der Potentialstatus anzeigt, dass ein angefragter Service nicht für die Instantiierung in dem Netzwerk verfügbar ist, die Resourcenmanagementeinrichtung den Bedarf der Instantiierung neuer Serviceobjekte an die zentrale Administratoreinrichtung für das Herunterladen und Aktivieren eines neuen Service an einem Serviceknoten übermittelt.
System nach Anspruch 1, bei welchem der Instantiierungsmechanismus folgendes beinhaltet: ein erstes Objekt zum Laden eines oder mehrerer Serviceobjekte von dem Datenspeichersystem und Instantiieren des einen oder der mehreren Objekte zur Ausführung innerhalb der Ausführungsumgebung; und ein zweites Objekt korrespondierend zu einem speziellen Service zur Zuordnung eines oder mehrerer Servicethreads, wobei jede Serviceinstanz mit jeder empfangenen An frage für diesen Service korrespondiert, wobei jede Servicethreadinstaz einen dazu zugeordneten einzigartigen Identifikator besitzt.
System nach Anspruch 2, weiter umfassend ein Netzwerkbetriebssystem zum Bereitstellen von Echtzeitkommunikation von Nachrichten und Ereignissen zwischen aus-führenden Objektinstanzen, wobei das zweite Objekt mit einem speziellen Service zur Kanalisierung von Ereignissen und Nachrichten zwischen den Serviceinstanzen korrespondiert, wobei die Ereignisse und Nachrichten den einzigartigen Identifikator zur Koordination von empfangenen Nachrichten und Ereignissen an die geeigneten Serviceinstanzen enthält.
System nach Anspruch 3, ferner umfassend einen Ereigniseinreihungsmechanismus, zugewiesen für jede Servicethreadinstanz zum Einreihen von Ereignissen, der Serviceinstanz zugeordnet, die im Verlauf der Serviceausführung empfangen werden, wobei die Ereignisse eine zugeordnete Priorität besitzen, eine Reihenfolge anzeigend, in welcher das Ereignis ausgeführt werden soll, wobei die Ereigniseinreihungseinrichtung das Verarbeiten der empfangenen Ereignisse entsprechend dessen zugeordneter Priorität ermöglicht.
System nach Anspruch 3, ferner umfassend ein Klassenladeverfahren zum anfänglichen Laden von einem oder mehreren Serviceobjekten von dem Datenspeichersystem entsprechend einer Konfigurationsdatei, ein Initialservicepotential für den Serviceknoten implementierend, wobei der Klassenlader, verantwortlich für das Instantiieren des ersten Objekts und beliebiger Serviceobjekte, zum Zwecke der Verfügbarkeit gemäß einer vordefinierten Servicepotentialstrategie.
System nach Anspruch 3, bei welchem das zweite Objekt, korrespondierend zu einem speziellen Service, eine Threadmanagerinstanz enthält, zum Vergleichen der Menge von Threadinstanzen, einem Service zugeordnet, mit einem vordefinierten Schwellwert, festgelegt in dem Serviceprofil, sowie zum Erzeugen eines Warnsignals an die Resourcemanagementeinrichtung, wenn die Ausführungsumgebung die Instantiierung von neuen Servicethreadinstanzen nicht länger unterstützt.
System nach Anspruch 6, bei welchem der Serviceobjektinstantiierungsmechanismus das Netzwerkbetriebssystem beinhaltet, wobei die Resourcenmanagementeinrichtung ferner das Verarbeitungspotential einer Ausführungsumgebung an jedem Serviceknoten verfolgt und eine Anzeige an das Netzwerkbetriebssystem bereitstellt, ob eine Ausführungsumgebung an einem Serviceknoten einen Service, basierend auf dessen Verarbeitungpotential, ausführen kann.
System nach Anspruch 7, bei welchem die Resourcenmanagementeinrichtung ferner eine Überlaststatusanzeige an das Netzwerkbetriebssystem kommuniziert, wenn eine Anzahl von Servicethreads, die derzeit bei einer Ausführungsumgebung ausgeführt werden, den vordefinierten Schwellwert überschreitet, und weitere Serviceobjektinstantiierungen an der Ausführungsumgebung verhindert.
System nach Anspruch 3, bei welchem der Instantiierungsmechanismus folgendes umfasst: eine Registrierung von aktiven Serviceobjektthreads, korrespondierend zu Instanzen von Services, die bei einer Ausführungsumgebung ausgeführt werden, bei jeder Ausführungsumgebung; und eine Mappingeinrichtung zum Mapping eines logischen Namens eines Services mit einer Objektreferenz, wobei das Netzwerkbetriebssystem die Objektreferenz zur Ermöglichung der Instantiierung einer angefragten Serviceobjektthreadinstanz in einer lokalen Ausführungsumgebung verwendet.
Verfahren zum Bereitstellen von Services an Serviceknoten in einem Kommunikationsnetzwerk, wobei jeder Serviceknoten eine Datenspeichereinrichtung und eine Ausführungsumgebung zum Durchführen von Services als Antwort auf den Empfang eines Ereignisses an einem Netzwerkschaltelement, einem Serviceknoten zugeordnet, aufweist, wobei das Verfahren folgendes umfasst: Erzeugen eines Serviceprofils für jeden Serviceknoten, beinhaltend Typ und Menge von Serviceobjektresourcen bezüglich der Serviceverarbeitung an jedem Knoten, sowie Herunterladen des Typs und der Menge der Serviceobjektresourcen zu dem Knoten gemäß dem Profil; Instantiieren von Serviceobjekten zur Ausführung in der einen oder den mehreren Ausführungsumgebungen; und Verfolgen der Ausführungsumgebungsresourcen an einem Serviceknoten durch führen einer Liste von Servicetypen, verfügbar an jedem Serviceknoten, wobei jeder Servicetyp einen zugeordneten Potentialstatus besitzt, der anzeigt, ob ein abgefragter Service für die Instantiierung an einem Serviceknoten verfügbar ist, wobei, wenn der Potentialstatus anzeigt, dass ein abgefragter Service nicht für die Instantiierung in dem Netzwerk verfügbar ist, der Bedarf des Instantiierens von neuen Serviceobjekten an eine zentrale Administratoreinrichtung zum Herunterladen und Aktivieren eines neuen Serviceobjekts an einem Serviceknoten kommuniziert wird.
Verfahren nach Anspruch 10, bei welchem der Instantiierungsschritt folgendes beinhaltet: Bereitstellen eines ersten Objekts zum Laden von einem oder mehreren Serviceobjekten von dem Datenspeichersystem und Instantiieren des einen oder der mehreren Objekte für die Ausführung innerhalb der Ausführungsumgebung entsprechend den empfangenen Serviceanfragen; und Bereitstellen eines zweiten Objekts, korrespondierend zu einem speziellen Service zur Zuordnung eines oder mehrerer Servicethreads für jede Serviceinstanz, korrespondierend zu jeder erhaltenen Anfrage für diesen Service, wobei jede Servicethreadinstanz einen zugeordneten eindeutigen Identifikator besitzt.
Verfahren nach Anspruch 11, ferner umfassend den Schritt des Kommunizierens von Nachrichten und Ereignissen, erzeugt während der Serviceobjektausführung, zwischen einem oder mehreren ausführenden Serviceobjekten in Unterstützung der Serviceverarbeitung, wobei die Ereignisse und Nachrichten durch einen einzigartigen Identifikator identifiziert werden, um die Ausführungsserviceinstanzen über das zweite Objekt zu korrigieren.
Verfahren nach Anspruch 12, ferner beinhaltend den Schritt der Einreihung von Ereignissen, einer ausführenden Serviceinstanz zugeordnet, die im Verlauf der Serviceausführung empfangen werden, wobei die Ereignisse eine zugeordnete Priorität besitzen, eine Reihenfolge anzeigend, in welcher das Ereignis durchgeführt werden soll, wobei die empfangenen Ereignisse gemäß deren korrespondierender Priorität verarbeitet werden.
Verfahren nach Anspruch 10, ferner beinhaltend: anfängliches Laden eines oder mehrerer Serviceobjekte von dem Datenspeichersystem entsprechend einer Konfigurationsdatei, ein erstes Servicepotential für den Serviceknoten bereitstellend, wobei der Klassenlader verantwortlich ist für die Instantiierung des ersten Objekts und eines beliebigen Serviceobjekts, zum Zwecke der Verfügbarkeit gemäß einer Vordefinierten Servicepotentialsstrategie.
Verfahren nach Anspruch 11, bei welchem der Schritt der Verfolgung der Ausführungsumgebungsresourcen an einem Serviceknoten folgendes beinhaltet: Vergleichen der Mengen von Threadinstanzen, einem Service zugeordnet, mit einem vordefinierten Schwellwert, festgelegt in dem Serviceprofil; und Erzeugen eines Warnsignals an eine Resourcenmanagementeinrichtung, wenn eine Ausführungsumgebung die Instantiierung von neuen Servicethreadinstanzen nicht länger unterstützt.
Verfahren nach Anspruch 10, bei welchem der Instantiierungsmechanismus folgendes umfasst: Erhalten einer Registrierung von aktiven Serviceobjektthreads, korrespondierend zu Instanzen von Services, die an einer Ausführungsumgebung an jedem Serviceknoten ausgeführt werden; und Mapping eines logischen Namens eines Service mit einer Objektreferenz; und Verwenden der Objektreferenz zur Ermöglichung der Instantiierung einer angefragten Serviceobjektthreadinstanz in einer lokalen Ausführungsumgebung.