DE69421178T2

DE69421178T2 - Fehlertolerantes dienstleistungsanbietungsgerät zur verwendung in einem telekommunikationssystem

Info

Publication number: DE69421178T2
Application number: DE69421178T
Authority: DE
Inventors: Colin Low
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1993-06-14
Filing date: 1994-06-10
Publication date: 2000-01-20
Anticipated expiration: 2014-06-11
Also published as: EP0704141A1; WO1994030027A1; EP0704141B1; DE69421178D1; GB9312246D0; JPH09502841A; US5910984A

Description

GEBIET DER ERFINDUNG

Die vorliegende Erfindung bezieht sich auf Telekommunikationsnetzwerke und insbesondere auf eine fehlertolerante Dienstbereitstellungsvorrichtung zum Bereitstellen von Rufverarbeitungsdiensten bezüglich eines Umschaltungszentrums eines Telekommunikationsnetzwerkes.

HINTERGRUND DER ERFINDUNG

Eine Telekommunikationsnetzwerkarchitektur weist bekanntermaßen ein Umschaltungssystem zum Bewirken, daß eine elementare Rufverarbeitung Rufe aufbaut, beibehält und löscht, und eine Dienstbereitstellungseinrichtung auf, die mit dem Umschaltungssystem kommuniziert, um Dienste zusätzlich zu der elementaren Rufverarbeitung bereitzustellen; Beispiele solcher zusätzlichen Dienste sind:
3-Wege-Ruf
Private virtuelle Netzwerke
Rufabschirmung
Rufblockierung
Rufweiterleitung
Aufwachrufe
Ruf abwarten Freisprechen/Teleinfo
Fernwählen
Rufnamelieferung
800-Zahlen-Nachschlagen
Schnellwählen
Gelbe-Seiten-Plus
Universales Personaltelephon
Kontokarte/Kreditkartenruf
Nummerübersetzung
Automatische Netzwerkrufverteilung
Das Umschaltungssystem einer solchen Anordnung behandelt einen Ruf allgemein so, als ob derselbe zwei oder mehr Rufabschnitte (ferner bekannt als "Segmente") aufweist, und wirksam ist, um den oder jeden solchen Rufabschnitt aufzubauen, beizubehalten und zu löschen. Wenn folglich das Umschal tungssystem mehr als ein Umschaltungszentrum oder einen Umschaltungspunkt aufweist, wird ein Ruf typischerweise behandelt werden, als ob derselbe einen Ursprungs- und Endrufabschnitt bei jedem Umschaltungszentrum aufweist; natürlich kann der Ruf bezüglich eines höheren Pegels sogar bei einer solchen Anordnung so betrachtet werden, als ob derselbe aus lediglich einem Abschnitt besteht. Um die elementare Rufverarbeitungsfunktionalität des Umschaltungssystems mit der Dienstbereitstellungseinrichtung schnittstellenmäßig zu verbinden, ist das Umschaltungssystem mit einer Schnittstelleneinrichtung versehen. Diese Schnittstelleneinrichtung versetzt das Umschaltungssystem in die Lage, bezüglich eines speziellen Rufabschnittes eine Dienstbereitstellung von der Dienstbereitstellungseinrichtung anzufordern und der Dienstbereitstellungseinrichtung über den Verlauf durch den Prozeß des Aufbauens, Beibehaltens und Löschen dieses Rufabschnittes zu berichten, und dieselbe setzt ferner die Dienstbereitstellungseinrichtung dazu in die Lage, diesen Prozeß gemäß des Dienstes zu beeinflussen, der durch die Dienstbereitstellungseinrichtung vorgesehen ist.
Eine solche herkömmliche Telekommunikationsnetzwerkarchitektur, die als AIN (Advanced Intelligent Network = fortgeschrittenes intelligentes Netzwerk) bekannt ist, ist durch Bellcore vorgeschlagen worden und ist detailliert in den folgenden und anderen Dokumenten beschrieben:
- Advanced Intelligent Network Release 1 Network & Operations Plan, Bellcore Special Report SR-NPL-001623, Nr. 1, Juni 1990,
- Advanced Intelligent Network Release 1 Switch - Service Control Point (SCP) Application Protocol Interface General Requirements, Bellcore Technical Advisory TA-NWT-001126 Nr. 1, Mai 1991.
Die Beschreibung eines Ausführungsbeispiels der vorliegenden Erfindung, die in dieser Spezifikation enthalten ist, ist in den Zusammenhang eines AIN-Netzwerkes gestellt, wobei dementsprechend für Details der Implementierung der gesamten Netzwerkarchitektur bezüglich des beschriebenen Ausführungsbeispiels der Erfindung ein Bezug auf die im vorhergehenden erwähnten Dokumente gerichtet ist. Um jedoch ein Verständnis der vorliegenden Erfindung zu erleichtern, ohne es zu erfordern, daß auf die im vorhergehenden erwähnten Dokumente Bezug genommen wird, werden bestimmte wichtige Aspekte eines AIN-Netzwerkes hierin bezugnehmend auf Fig. 1 bis 9 beschrieben, wobei diese Figuren auf denjenigen, die bei den Bellcore Dokumenten erscheinen, basieren. Es wird darauf hingewiesen, daß die vorliegende Erfindung auf andere Umgebungen als einem AIN-Netzwerk angewendet werden kann.
Für den Zweck der vorliegenden Einführung wird nun ein kurzer Überblick über die allgemeine AIN-Architektur bezugnehmend auf Fig. 1 der begleitenden Zeichnungen gegeben.
Bei dem Netzwerk von Fig. 1 wird die elementare Rufverarbeitung (d. h. der Rufaufbau, die Rufbeibehaltung und die Ruflöschung) durch einen (oder mehrere) Dienstumschaltungspunkte SSP (SSP - service switching point) 10 ausgeführt, zu denen die Endbenutzer 11 verbunden sind. Zusätzliche Dienste, wie z. B. diejenigen, die im vorhergehenden aufgelistet wurden, werden dem SSP 10 auf eine Anforderung hin entweder durch einen Dienststeuerungspunkt (SCP = service control point) 12 oder eine Nebeneinrichtung 13 bereitgestellt, von denen beide Beispiele einer Dienstbereitstellungsvorrichtung (SPA; SPA = service-providing apparatus) sind. Die Nebeneinrichtung 13 ist dem SSP 10 direkt zugeordnet, während der SCP 12 und der SSP 10 über ein Zentralkanal-Signalgebungs- (CCS; CCS = common chanal signalling) Netzwerk 14 miteinander kommunizieren, das typischerweise Signalübertragungspunkte (STP; STP = signal transfer points) 18 aufweisen wird. Der SCP 12 kann mehr als einem SSP 10 zugeordnet sein. Jede SPA (ob der SCP 12 oder die Nebeneinrichtung 13) liefert eine Dienstlogikausführungsumgebung (SLEE; SLEE = service logic execution environment) 15, bei der die Beispiele eines oder mehrerer Dienstlogikprogramme (SLP; SLP = service logic programs) 16 ausgeführt werden können. Die SLEE 15 und das SLP 16 liefern zusammen eine Dienstlogikfunktionalität zum Bereitstellen von Diensten bezüglich des SSP 10.
Wenn der SSP 10 einen Ruf empfängt, untersucht derselbe bei einem Betrieb innere Auslösebedingungen und möglicherweise Benutzerinformationen (z. B. gewählte Zahlen), um zu ermitteln, ob es der Ruf erforderlich macht, daß durch eine SPA 12, 13 ein Dienst bereitgestellt wird; das Überprüfen der Auslösebedingungen wird bei mehreren unterschiedlichen Punkten bei der Rufverarbeitung ausgeführt. Wenn der SSP 10 bestimmt, daß ein Dienst erforderlich ist, meldet derselbe einer SPA, welcher gewünschte Dienst angefordert wird, und sendet derselben eine logische Darstellung des Rufs bezüglich dessen Verbindungsmöglichkeit und dessen Rufverarbeitungsstatus. Die SPA stellt dann den angeforderten Dienst bereit, wobei dies entweder eine einzige Wechselwirkung zwischen dem SSP und der SPA oder eine Sitzung von Wechselwirkungen umfassen kann.
Zusätzlich zu dem SSP 10 und der Nebeneinrichtung 12 weist das Netzwerk von Fig. 1 eine intelligente Peripherie (IP; IP = intelligent peripheral) 16 und ein Betriebssystem (OS; OS = operations system) 17 auf. Die IP 16 stellt Betriebsmittel für den SSP 10 bereit, wie z. B. Stimmansagen und digitale DTMF-Zahlsammelfähigkeiten. Das OS 17 weist einen Überblick des Netzwerkes und von dessen Diensten auf, und führt Funktionen, wie z. B. eine Netzwerküberwachung und eine Netzwerksteuerung, durch.
Wenn das Netzwerk mehr als einen SSP 10 aufweist, durch den ein Ruf geleitet werden kann, ist vorzugsweise jeder SSP mit denselben Unterstützungbetriebsmittel wie der SSP 10 von Fig. 1 versehen.
Aus dem vorhergehenden kurzen Überblick eines AIN-Netzwerkes wird ersichtlich werden, daß eine SPA 12, 13 ein integraler Bestandteil des Netzwerkes ist, und folglich ähnlichen Einschränkungen bezüglich der Verfügbarkeit und der Zuverlässigkeit wie der SSP 10 selbst unterworfen ist. Um diesen Anforderungen zu genügen, ist eine fehlertolerante Architektur für eine SPA 12, 13 erforderlich.
Eine mögliche Lösung besteht darin, eine Fehlertoleranz auf niedriger Ebene (d. h. Hardware) zu schaffen, bei der ein Komponenten- oder Teilsystemausfall erfaßt und gehandhabt wird; eine solche Lösung ist jedoch im allgemeinen aufwendig und ist langsam, um von den Verbesserungen der Prozessortechnologie zu profitieren.
Aus diesem Grund attraktiver sind Lösungen, die eine Replizierung einer Verarbeitungsfähigkeit aufweisen, wobei Allzweckprozessoren verwendet werden. Eine mögliche Lösung dieses Typs würde darin bestehen, eine aktive Replizierung zu verwenden, bei der mehrere Prozessoren dieselben Prozesse ablaufen lassen, dieselben Daten empfangen und dieselbe Verarbeitung ausführen, wobei dann ein Mehrheitswahlschema verwendet wird, um das Verarbeitungsergebnis zu bestimmen. Eine solche Lösung würde jedoch aufwendig, und lediglich dann möglich sein, falls das Systemverhalten deterministisch ist. Eine weitere mögliche Lösung, die eine Replizierung der Verarbeitungsfähigkeit verwendet, ist eine passive Replizierung, bei der ein Hauptverarbeitungsbetriebsmittel normalerweise das Verarbeiten ausführt und daraufhin ein Sicherungsverarbeitungsbetriebsmittel gemäß der Ergebnisse der Verarbeitung aktualisiert; auf diese Weise wird das Sicherungsverarbeitungsbetriebsmittel bezüglich der Statusdaten ununterbrochen aktualisiert, wobei dasselbe folglich bereit ist, die Arbeit des Hauptbetriebsmittels zu übernehmen, sollte das Letztgenannte ausfallen. Eine SPA kann jedoch typischerweise 1000 Dienstanforderungen pro Sekunde handhaben. Falls die SPA Rufinformationen für drei Minuten (beispielsweise) zurückhalten muß, dann würde dieselbe zu jedem Zeitpunkt gespeicherte Informationen (inklusive Rechnungsin formationen) für 180.000 Rufe aufweisen. Es ist nicht praktikabel, von der Hauptverarbeitungseinrichtung die Statusdaten bezüglich jedes Rufs nach außen zu übertragen, wann immer die Daten geändert werden, da die Anzahl von Dienstanforderungen zu groß ist (es wird darauf hingewiesen, daß, wenn die Statusdaten geändert werden, entweder alle Statusdaten bezüglich des entsprechenden Rufs übertragen werden müssen oder ansonsten eine Extraverarbeitung ausgeführt werden muß, um vor der Übertragung lediglich der Änderungen nach außen die Änderungen zu identifizieren und einzutragen - bei beiden Fällen ist das Betriebsmittel, das lädt, wesentlich größer, als es im allgemeinen erforderlich sein wird, um das Ergebnis der Verarbeitung, die die Statusdatenänderungen erzeugt hat, zu der SPA zurückzuübertragen.
Eine weitere mögliche fehlertolerante Architektur würde darin bestehen, eine Haupt- und eine Sicherungsverarbeitungseinrichtung wie bei einer passiven Replizierung vorzusehen, aber dabei die Statusdaten von der Hauptverarbeitungseinrichtung zu einem stabilen Speicher zu sichern; sollte die Hauptverarbeitungseinrichtung ausfallen, wird die Sicherungsverarbeitungseinrichtung in Betrieb versetzt, wobei derselben die Statusdaten übergeben werden, die in dem Sicherungsspeicher gehalten werden. Eine solche Architektur leidet jedoch an denselben Nachteilen, die im vorhergehenden bezüglich der passiven Replizierung angesprochen wurden.
Eine Aufgabe der vorliegenden Erfindung besteht darin, eine verbesserte fehlertolerante Dienstbereitstellungseinrichtung zu schaffen.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß einem Aspekt der vorliegenden Erfindung wird eine Dienstbereitstellungsvorrichtung zum Bereitstellen von Rufverarbeitungsdiensten für ein Umschaltungszentrum eines Telekommunikationsnetzwerkes bezüglich Rufsegmenten geschaffen, die durch dasselbe aufgebaut, beibehalten und gelöscht werden, dadurch gekennzeichnet, daß die Dienstbereitstellungsvorrichtung folgende Merkmale aufweist:
- eine erste Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungszentrum im Normalfall,
- eine zweite Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungszentrum im Fall eines Ausfallens der ersten Dienstlogikeinrichtung,
- eine Erholungseinrichtung, die auf einen Ausfall der ersten Dienstlogikeinrichtung anspricht, um die zweite Dienstlogikeinrichtung in Betrieb zu bringen, und
- einem Sicherungsspeicher,
wobei die erste Dienstlogikeinrichtung wirksam ist, um zu den Sicherungsspeicher Statusdaten zu sichern, die durch die erste Dienstlogikeinrichtung bezüglich einer Dienstbereitstellung für das oder jedes Rufsegment gehalten werden, für das dieselbe augenblicklich Dienste bereitstellt, wobei dieses Sichern der Statusdaten bezüglich des Rufsegmentes lediglich bewirkt wird, nachdem die erste Dienstlogikeinrichtung bestimmt hat, daß sie im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens des entsprechenden Rufsegmentes erforderlich sind, und wobei die zweite Dienstlogikeinrichtung auf das In-Betrieb-Bringen hin Statusdaten von dem Sicherungsspeicher empfängt, die notwendig sind, damit dieselbe fortfährt, Dienste bezüglich augenblicklicher Rufsegmente bereitzustellen.
Durch diese Anordnung wird das Betriebsmittel, das lädt, des Hauptverarbeitungsbetriebsmittels der SPA (d. h. der im vorhergehenden genannten "ersten Dienstlogikeinrichtung"), das erforderlich ist, um die Statusdaten zu sichern, wesentlich reduziert, da der größte Teil der Wechselwirkung zwischen einem SSP und einer SPA während eines Rufaufbaus stattfindet, d. h. einer Zeitdauer, die weniger als eine Sekunde andauert. Falls die Rufinformationen während des Rufaufbaus verloren gehen, ist dies von minimaler Wichtigkeit, da geringe Einnahmen verloren gegangen sind, und der Benutzer den Ruf neu probieren wird, falls der Ruf fehlschlägt. Die Pro- Ruf-Informationen, die die SPA während des Rufaufbaus ansammelt, werden lediglich wertvoll, falls der betroffene Rufabschnitt stabil (d. h. eingerichtet) wird, wobei an diesem Punkt die Anzahl der Wechselwirkungen zwischen dem SSP und der SPA typischerweise gering ist, und die Daten zunehmend wertvoller werden, während die Rufdauer fortschreitet.
Gemäß der vorliegenden Erfindung nimmt die erste Dienstlogikeinrichtung der SPA automatisch den Punkt wahr, bei dem zumindest die Mehrheit der Dienstbereitstellungstätigkeiten, die während des Aufbauens eines Rufsegments erforderlich sind, abgeschlossen worden sind, und sichert die Rufdaten zu einem Sicherungsspeicher, wo dieselben ein Ausfallen überleben werden. Bei dem Ereignis eines Ausfallens wird die Mehrheit von Rufen bei dem Prozeß des gerade Aufgebautwerdens verloren gehen, aber die Dienstbereitstellung kann für jeden Ruf (inklusive aller stabilen Rufe) fortgesetzt werden, der Dienstbereitstellungsstatusdaten in dem Sicherungsspeicher gespeichert hatte, indem die zweite Dienstlogikeinrichtung gestartet und mit den Statusdaten, die in dem Sicherungsspeicher gehalten werden, versehen wird.
Bei einem Ausführungsbeispiel bestimmt die erste Dienstlogikeinrichtung, daß dieselbe im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens des entsprechenden Rufsegmentes erforderlich sind, wenn durch das Umschaltungszentrum gemeldet wird, daß zumindest die Mehrzahl der Rufsegmentaufbauprozesse abgeschlossen worden sind. Alternativ kann die erste Dienstlogikeinrichtung bestimmen, daß diesel be im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens der entsprechenden Rufsegmente erforderlich sind, indem lediglich wahrgenommen wird, wo sich dieselbe in dem Prozeß der Dienstbereitstellung befindet. Ein weiterer Lösungsansatz, der zu dem Letztgenannten ähnlich ist, besteht darin, da die erste Dienstlogikeinrichtung bestimmt, daß dieselbe im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens des entsprechenden Rufsegmentes erforderlich sind, wenn dieselbe bestimmt, daß es sein kann, daß die nächste Dienstbereitstellungstätigkeit nicht notwendig ist, bis das entsprechende Rufsegment in seine stabile Phase eingetragen ist.
Um die Statusdaten, die in dem Sicherungsspeicher gehalten werden, aktualisiert zu halten, führt jede Änderung, die der ersten Sicherung der Statusdaten zu dem Speicher bezüglich eines speziellen Rufsegments durch die erste Dienstlogikeinrichtung folgt, bezüglich dieser Statusdaten in der ersten Dienstlogikeinrichtung zu einem Aktualisieren der Statusdaten, die in dem Sicherungsspeicher gehalten werden.
Der genannte Sicherungsspeicher ist vorzugsweise eine fehlertolerante Datenbasis oder ein Plattenlaufwerk.
Vorteilhafterweise werden nicht alle gesicherten Daten zu der zweiten Dienstlogikeinrichtung weitergeleitet, wenn die Letztgenannte in Betrieb gebracht wird; dies so durchzuführen, würde nicht nur eine erhebliche Verzögerung verursachen, bevor die zweite Logikeinrichtung verfügbar wäre, sondern es ist ferner nicht notwendig, da einige der Daten nicht wieder erforderlich sind. Stattdessen werden Statusdaten, die ein spezielles Rufsegment betreffen, zu der zweiten Dienstlogikeinrichtung vorzugsweise lediglich dann weitergeleitet, wenn die Letztgenannte solche Informationen als ein Ergebnis einer Kommunikation von dem Umschaltungszentrum erfordert.
Wenn Sitzungen eines oder mehrerer Rufe mit den Sitzungsinformationen über solche Sitzungen, die in der SPA gehalten werden, eingerichtet werden können, werden diese Sitzungsinformationen vorzugsweise ebenfalls zu dem Sicherungsspeicher gesichert. Die gesicherten Sitzungsinformationen werden von dem Sicherungsspeicher zu der zweiten Dienstlogikeinrichtung auf das In-Betrieb-Bringen der letzteren hin vorzugsweise lediglich in dem Fall weitergeleitet, wenn ferner Statusdaten für ein augenblickliches Rufsegment, das für die entsprechende Sitzung relevant ist, zu der zweiten Dienstlogikeinrichtung weitergeleitet wird.
Gemäß eines weiteren Aspekts der vorliegenden Erfindung wird eine Dienstbereitstellungsvorrichtung zum Bereitstellen von Rufverarbeitungsdiensten für ein Umschaltungszentrum eines Telekommunikationsnetzwerkes bezüglich Rufsegmenten geschaffen, die durch dasselbe aufgebaut, beibehalten und gelöscht werden, dadurch gekennzeichnet, daß die Dienstbereitstellungsvorrichtung folgende Merkmale aufweist:
- eine erste Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungszentrum im Normalfall,
- eine zweite Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungszentrum im Fall eines Ausfallens der ersten Dienstlogikeinrichtung,
- eine Erholungseinrichtung, die auf ein Ausfallen der ersten Dienstlogikeinrichtung anspricht, um die zweite Dienstlogikeinrichtung in Betrieb zu bringen, und
- einen Sicherungsspeicher,
wobei die erste Dienstlogikeinrichtung wirksam ist, um zu dem Sicherungsspeicher Statusdaten zu sichern, die durch die erste Dienstlogikeinrichtung bezüglich einer Dienstbereitstellung für das oder jedes Rufsegment gehalten werden, für das dieselbe augenblicklich Dienste bereitstellt, wobei das Sichern der Statusdaten bezüglich des Rufsegments lediglich dann bewirkt wird, nachdem zumindest die Mehrheit der Aufbauprozesse für das Segment abgeschlossen worden sind, und wobei die zweite Dienstlogikeinrichtung auf das In-Betrieb- Bringen von dem Sicherungsspeicher Statusdaten empfängt, die notwendig sind, damit dieselbe fortfährt, Dienste für augenblickliche Rufsegmente bereitzustellen. In diesem Fall ist es das Abschließen von zumindest der Mehrheit des Rufsegmentaufbauprozesses selbst (und nicht der Dienstbereitstellungstätigkeiten), das verwendet wird, um zu bestimmen, wann die Statusdaten gesichert werden sollen.
Gemäß eines weiteren Aspekts der vorliegenden Erfindung wird ein Telekommunikationsnetzwerk geschaffen, das ein Umschaltungssystem zum Bewirken einer elementaren Rufverarbeitung, um Rufe aufzubauen, beizubehalten und zu löschen, und eine Dienstbereitstellungseinrichtung aufweist, die mit dem Umschaltungssystem kommuninziert, um Dienste zusätzlich zu der elementaren Rufverarbeitung bereitzustellen; wobei das Umschaltungssystem einen Ruf so behandelt, als ob derselbe zumindest einen Rufabschnitt aufweist, und wobei das System wirksam ist, um den oder jeden solchen Rufabschnitt aufzubauen, beizubehalten und zu löschen, wobei das Umschaltungssystem eine Schnittstelleneinrichtung aufweist, um das System mit der Dienstbereitstellungseinrichtung schnittstellenmäßig zu verbinden, um dadurch zu ermöglichen, daß das Umschaltungssystem von derselben eine Dienstbereitstellung bezüglich eines speziellen Rufabschnittes anfordert, daß dasselbe der Dienstbereitstellungseinrichtung über das Vorankommen durch den Prozeß des Aufbauens, Beibehaltens und Löschens dieses Rufabschnittes berichtet, und um zu ermöglichen, daß die Dienstbereistellungseinrichtung diesen Prozeß gemäß des Dienstes beeinflußt, der durch die Dienstbereitstellungseinrichtung gerade bereitgestellt wird, dadurch gekennzeichnet, daß:
- die Schnittstelleneinrichtung wirksam ist, um der Dienstbereitstellungseinrichtung zu berichten, wann das Aufbauen des entsprechenden Rufabschnittes im wesentlichen abgeschlossen ist; und
- die Dienstbereitstellungseinrichtung eine erste Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungssystem im Normalfall, eine zweite Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungssystem im Fall eines Ausfallens der ersten Dienstlogikeinrichtung, eine Erholungseinrichtung, die auf ein Ausfallen der ersten Dienstlogikeinrichtung anspricht, um die zweite Dienstlogikeinrichtung in Betrieb zu bringen, und einen Sicherungsspeicher aufweist; wobei die erste Dienstlogikeinrichtung wirksam ist, um zu dem Sicherungsspeicher Rufabschnitt-bezogene Daten zu speichern, die durch die erste Dienstlogikeinrichtung bezüglich des oder jedes Rufabschnitts gehalten werden, für das dieselbe augenblicklich Dienste bereitstellt, wobei dieses Sichern bezüglich des Rufabschnittes lediglich dann bewirkt wird, nachdem die Schnittstelleneinrichtung des Umschaltungssystems gemeldet hat, daß das Aufbauen des Rufabschnittes zumindest im wesentlichen abgeschlossen worden ist, und wobei die zweite Dienstlogikeinrichtung auf das In-Betrieb-Bringen hin von dem Sicherungsspeicher mit den Rufabschnitt-bezogenen Daten versehen wird, die notwendig sind, da dies forfährt, die angeforderten Dienste bezüglich der augenblicklichen Rufabschnitte bereitzustellen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Es wird nun die Dienstbereitstellungsvorrichtung (SPA; SPA = Service-providing apparatus), die die vorliegende Erfindung aufweist, mittels eines nicht begrenzenden Beispiels bezugnehmend auf die begleitenden diagrammartigen Zeichnungen beschrieben, bei denen
Fig. 1 ein Diagramm ist, das eine bekannte allgemeine Architektur für ein Telekommunikationsnetzwerk darstellt, das dazu gedacht ist, zusätzlich zu dem elementaren Rufaufbau und der elementaren Ruflöschung Dienste bereitzustellen, wobei das Netzwerk von Fig. 1 insbesondere einen Dienstumschaltungspunkt (SSP) und zwei Vorkehrungen für eine Dienstbereitstellungsvorrichtung (SPA) aufweist, namentlich einen Dienststeuerungspunkt (SCP) und einen Nebeneinrichtungsprozessor;
Fig. 2 ein Diagramm ist, das ein Verbindungsmöglichkeitsmodell für einen Zwei-Teilnehmer-Ruf darstellt, der durch einen einzigen SSP gehandhabt wird, wobei das Modell ein Ursprungs- und ein End-Rufsegment aufweist;
Fig. 3 ein Diagramm ist, das ein Verbindungsmöglichkeitsmodell für einen Zwei-Teilnehmer-Ruf darstellt, der zwei SSP durchläuft, wobei das Modell ein jeweiliges Urprungs- und End-Rufsegment für jeden SSP aufweist;
Fig. 4 ein Diagramm der Verarbeitungsfunktionalität des SSP von Fig. 1 ist;
Fig. 5 ein vereinfachtes Statusübergangsdiagramm eines elementaren Ursprungsrufmodells (originating basic call model) (BCM; BCM = basic call model = elementares Rufmodell) ist, das die elementare Rufverarbeitungsfunktionalität des SSP von Fig. 1 für ein Ursprungsrufsegment modelliert;
Fig. 6 ein vereinfachtes Statusübergangsdiagramm ist, das ähnlich zu dem von Fig. 5 ist, sich aber auf ein End-BCM bezieht;
Fig. 7 ein Diagramm ist, das den Verbindungsmöglichkeits status von Ursprungs- und End-Rufsegmenten relativ zu dem Fortschreiten durch jeweils das Ursprungs- und End-BCM von Fig. 5 und 6 darstellt;
Fig. 8 ein Flußdiagramm ist, das die Verarbeitung darstellt, die durch die Auslöseüberprüfungspunkt- (TCP-; TCP = trigger checkpoint) -Blöcke dargestellt wird, die in Fig. 5 und 6 gezeigt sind;
Fig. 9 ein Diagramm ist, das die Handhabung einer Verbindungsansicht (CV; CV = connection view) und die Informationsflüsse zeigt, die für eine CV-Verarbeitung relevant sind; und
Fig. 10 ein Blockdiagramm der Dienstbereitstellungsvorrichtung ist, die die Erfindung darstellt und für eine Verwendung als der SCP und/oder als der Nebeneinrichtungsprozessor von Fig. 1 geeignet ist.

BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS

Die Dienstbereitstellungsvorrichtung, die die Erfindung darstellt, wird hierin im folgenden bezüglich des herkömmlichen Netzwerkes von Fig. 1 beschrieben, das im vorhergehenden beschrieben wurde. Um vollständig zu verstehen, bei welchen Stufen während der Rufverarbeitung die Dienstbereistellungsvorrichtung das Sichern der Rufstatusinformationen bewirken wird, ist es notwendig, das Rufmodell zu verstehen, das in den im vorhergehenden erwähnten Bellcore-Dokumenten beschrieben ist, um die Elemente zu definieren, die für eine Wechselwirkung zwischen einem SSP 10 und einer SPA 12, 13 relevant sind. Die Hauptmerkmale dieses Rufmodells werden daher im folgenden beschrieben.
Das Rufmodell ist ein konzeptionelles Modell, das auf der existierenden digitalen Umschaltungsfunktionalität aufbaut, die in vielen modernen digitalen Schaltern vorgefunden wird.
Insbesondere definiert das Rufmodell, welche zusätzliche Verarbeitungsfunktionalität in einem SSP über und oberhalb einer elementaren Standard-Rufverarbeitung vorhanden sein muß, um eine Schnittstelle für den Letztgenannten mit einer SPA vorzusehen. Wie es vollständiger im folgenden erklärt werden wird, wird diese zusätzliche Funktionalität in zwei Verarbeitungsblöcke eingeteilt, namentlich die BCM-Verarbeitung, die die elementare Rufverarbeitung zum Aufbauen und Löschen von Rufabschnitten betrifft, und die Verbindungsansicht- (CV-; CV = cennection view) -Verarbeitung zum Bereitstellen einer Übersicht über jeden Rufabschnitt, für den Dienste erforderlich sind, und zum Wechselwirken mit der SPA. Es wird darauf hingewiesen, daß das Rufmodell mit dessen BCM- und CV-Verarbeitungsfunktionalitätsblöcken ein Mittel zum Modellieren der Wechselwirkungen zwischen einem SSP und einer SPA ist; aktuelle Implementierungen von SSPs werden im allgemeinen nicht direkt auf das Modell passen, aber dieselben werden nichtsdestotrotz die allgemeine Funktionalität des Letztgenannten enthalten.

Verbindungsmöglichkeitdarstellung

Das Rufmodell basiert auf einer Sicht eines Rufs als ein Erzeugnis eines Ursprungsrufabschnitts und eines Endrufabschnitts innerhalb jedes SSP 10, den der Ruf durchläuft; diese Rufabschnitte, die als Rufsegmente CS (CS; CS = call segments) bekannt sind, werden auf eine funktionell getrennte Art und Weise in Übereinstimmung mit der Praxis bezüglich digitalen Stromschaltern gehandhabt. Folglich kann dieses CS mit einem jeweiligen Dienst von einer SPA 12, 13 unabhängig versehen sein, und unterschiedliche CS, die demselben Ruf zugeordnet sind, können durch unterschiedliche SPA bedient werden.
Fig. 2 stellt einen Zwei-Teilnehmer-Ruf dar, der durch einen einzigen SSP 10 abgeschlossen wird, und folglich lediglich zwei Rufsegmente CS1, CS2 aufweist. Fig. 3 stellt jedoch ei nen Zwei-Teilnehmer-Ruf dar, der durch zwei SSP 10 läuft, und folglich vier Rufsegmente CS1 bis CS4 aufweist, wobei die Segmente CS1, CS3 Ursprungs-CS und die Segmente CS2, CS4 End-CS sind.
Wie aus Fig. 2 und 3 gesehen werden kann, wird ein CS selbst so betrachtet, als ob es aus zwei Beinen L0, L1 und einem Verbindungspunkt CP aufgebaut ist; die zwei Beine entsprechen Kommunikationswegen zu jeweiligen Teilnehmern des Ursprungs- und End-Teilnehmers (folglich bildet das Bein L0 von CS2 in Fig. 3 eine Amtsleitung).
Tatsächlich kann ein CS mehr als zwei Beine aufweisen, und zwar in Fällen, wie z. B. Mehr-Teilnehmer-Rufen, bei denen sich mehrere Beine an einer Seite des Verbindungspunktes befinden können. Diese Zuordnung der Beine mit dem CP eines CS stellt die Verbindungsmöglichkeit des Letztgenannten dar, das heißt, wie dasselbe strukturiert ist, um angeschlossen zu werden.

Rufmodell

Als ein Ergebnis der im vorhergehenden erwähnten Segmentierung eines Rufs in ein Ursprungs- und End-CS innerhalb eines SSP ist das Rufmodell für das Bilden einer Schnittstelle für einen SSP 10 mit einer SPA 12, 13 bezüglich eines CS definiert.
Weiterhin insbesondere fügt das Rufmodell zu der elementaren Rufverarbeitung, die für jedes CS bewirkt wird, sowohl eine BCM-Verarbeitungsfunktionalität als auch eine CV-Verarbeitungsfunktionalität hinzu, um eine Schnittstelle für eine SPA mit der Schalterbasierten Rufverarbeitung eines CS zu bilden. In Fig. 4 ist folglich die Schalterbasierte elementare Rufverarbeitung für einen Zwei-Teilnehmer-Ruf (Rufaufbau, Rufbeibehaltung und Ruflöschung) innerhalb eines SSP durch Zugangsverarbeitungsblöcke 20 und einen zugrundelie genden Rufverarbeitungsblock 21 dargestellt, während für jedes CS zusätzliche BCM-Verarbeitungsblöcke und CV-Verarbeitungsblöcke 22 und 23 hinzugefügt sind. Der BCM-Verarbeitungsblock 22 steht in Wechselwirkung mit den Zugangsverarbeitungsblöcken 20 und dem zugrunde liegenden Rufverarbeitungsblock 21, um sowohl dem zugeordneten CV-Verarbeitungsblock 23 über den Fortschritt der elementaren Rufverarbeitungsoperationen für das betroffene CS zu berichten, als auch um zu ermöglichen, daß diese elementaren Operationen über den CV-Verarbeitungsblock durch eine SPA gesteuert werden. Der CV-Verarbeitungsblock 23 ist dafür verantwortlich, eine Übersicht über die Verbindungsmöglichkeit des CS beizubehalten, Meldungen mit einer SPA auszutauschen, wie es bezüglich der Dienstbereitstellung für das CS durch die SPA erforderlich ist, und Steuerungsgrundelemente zu dem BCM- Verarbeitungsblock 22 und dem zugrunde liegenden Rufverarbeitungsblock 21 zu übergeben, um die Rufverarbeitung bzw. die Verbindungsmöglichkeitsaspekte des CS zu steuern, wie es für die SPA erforderlich ist, um den angeforderten Dienst zu implementieren.
Der BCM-Verarbeitungsblock 22 führt seine Funktion gemäß einer Rufmodellkomponente aus, die als das elementare Rufmodell (BCM) bezeichnet wird und die Punkte in der Schalterbasierten elementaren Rufverarbeitung definiert, bei denen eine SPA über den Fortschritt informiert werden kann und dieselbe die nachfolgende Verarbeitung beeinflussen kann.
Der CV-Verarbeitungsblock 23 führt seine Funktion aus, indem er eine Rufmodellkomponente verwendet, die als die Verbindungsansicht (CV) bezeichnet wird und definiert, welche Elemente eines CS für eine SPA sichtbar und zugänglich sind.

Elementares Rufmodell (BCM)

Das elementare Rufmodell ist eine Darstellung in einer Sta tusübergangsdiagrammform, die die elementare Rufverarbeitung in dem SSP für einen Zwei-Teilnehmer-Ruf modelliert. Die als wesentlich betrachtete Verarbeitung ist durch eine Reihe von PIC (Point in Call = Punkte im Ruf) dargestellt, die die Stufen des BCM bilden. Jeder PIC wird auf das Auftreten eines vorspezifizierten Ereignisses oder vorspezifizierter Ereignisse hin angeregt. Alle Verarbeitungsmerkmale, die für die elementare Verarbeitung, die für Zwei-Teilnehmer-Rufe erforderlich ist, nicht wesentlich sind, (ob Schalterbasierte Dienste oder Dienste, die von einer SPA 12, 13 angefordert werden sollen), werden bei Auslöseüberprüfungspunkten (TCP) eingebunden, die sich bei dem Ausgang von jedem PIC befinden. Ob ein solches Weiterverarbeitungsmerkmal bei einem speziellen TCP eingebunden ist, wird von den Auslösekriterien abhängen, die bei dem TCP spezifiziert sind; falls kein Auslösekriterium bei einem TCP zutrifft, wird die Verarbeitung zu dem nächsten PIC fortschreiten. Falls ein Auslösekriterium zutrifft, wird in dem Fall, daß ein SPA-Dienst erforderlich ist, eine Meldung zu der relevanten SPA zusammen mit relevanten Rufdetails gesendet, wobei der angeforderte Dienst nachfolgend bereitgestellt wird. Die SPA kann den Punkt in dem BCM steuern, bei dem die Verarbeitung fortschreitet, wobei entweder ermöglicht wird, daß die Verarbeitung zu dem nächsten PiC fortschreitet, oder daß ein anderer PIC ernannt wird, bei dem die Verarbeitung fortgesetzt werden soll.
Das BCM wird in ein Ursprungs-BCM, das die Verarbeitung bezüglich eines Ursprungs-CS modelliert, und ein End-BCM aufgeteilt, das die Verarbeitung bezüglich eines End-CS modelliert. Fig. 5 bzw. Fig. 6 zeigen das Ursprungs- und End-BCM, wobei aber in beiden Fällen diese BCM durch Weglassen der Mittel-Ruf- und Ausnahme-Ereignisse vereinfacht worden sind.
Das Ursprungs-BCM, das in Fig. 5 gezeigt ist, weist zehn PIC 1-10 auf, von denen jeder die wesentliche Rufverarbeitungsstufe darstellt, die in der Figur genannt ist. Das Ereignis E, das das Anregen von jedem PIC bewirkt, ist in Fig. 5 ebenfalls angezeigt. PIC 6 stellt folglich beispielsweise die Stufe der Rufaufbauautorisierung dar, wobei das betroffene Ausgangsereignis E darin besteht, daß diese Autorisierung gegeben wird; während alle anderen PIC neben dem PIC 6 angeregt werden, werden die Auslösekriteria in dem zugeordneten TCP getestet.
Aus Fig. 6 wird ersichtlich, daß, sollte ein Trennungsereignis bei irgendeinem PIC erfaßt werden, die Verarbeitung über einen TCP zu der Null-Stufe PIC 1 zurückkehrt.
Das End-BCM, das in Fig. 6 gezeigt ist, ist in allgemeiner Form ähnlich zu demjenigen von Fig. 5, weist aber lediglich sieben PIC 11 bis 17 mit deren zugeordneten TCP auf.
Die Stufe eines CS bezüglich dessen Verbindungsmöglichkeitsmerkmale (CP, Beine) wird natürlich mit dem Fortschreiten durch das entsprechende BCM variieren. Fig. 7 zeigt diese Variation durch Darstellen der Statusse der Verbindungsmöglichkeitsmerkmale des Ursprungs- und End-CS (auf der rechten Seite von Fig. 7) relativ zu dem Fortschreiten durch die entsprechenden BCM (die in einfacher Form auf der linken Seite von Fig. 7 gezeigt sind). Während der Rufaufbauphase eines CS wird dem CS eines oder beide Beine fehlen; sobald ein CS beide Beine aufweist, wird dasselbe als stabil bezeichnet und verbleibt so, bis der Ruf getrennt oder gelöscht wird. Für einen Ruf freilich, der durch einen SSP vollständig aufgebaut werden soll, müssen sich sowohl das Ursprungs- als auch das End-CS in ihrem stabilen Status befinden. Aus Fig. 7 kann ersehen werden, daß das Ursprungs-CS durch die PIC 1 bis 6 aufgebaut wird, und durch die PIC 7 bis 10 hinweg stabil ist, während das End-CS durch die PIC 11 bis 14 hinweg aufgebaut wird, und durch die PIC 15 bis 17 hinweg stabil ist. Fig. 7 zeigt ferner den relativen Versatz zwischen den PIC des Ursprungs- und des End- BCM.
Als nächstes wird auf das TCP-Verarbeitungsflußdiagramm von Fig. 8 Bezug genommen, wobei eine weitere Betrachtung dessen angestellt werden wird, was passiert, wenn ein TCP in einem BCM angetroffen wird. Wie bereits darauf hingewiesen worden ist, werden bei einem TCP die Auslösekriterien überprüft (Block 31), um zu sehen, ob eine Meldung zu einer SPA 12, 13 gesendet werden sollte. Diese Auslösekriterien werden in dem SPP 10 durch das OS 17 (siehe Fig. 1) zusammen mit Informationen über die SPA, die kontaktiert werden soll, den Parametern, die zu der SPA gesendet werden sollen, und dem eingestellt werden, ob oder ob nicht eine Verarbeitung in dem SPP bezüglich des betroffenen CS zurückgehalten werden sollte, wobei eine Antwort von der SPA ansteht. Das Ergebnis der Untersuchung der Auslösekriterien in Block 31 wird in dem Block 32 getestet, und, falls keine Auslösung erfüllt wird, wird die Verarbeitung bei dem nächsten PIC fortgesetzt (siehe Block 33). Falls der Test des Blocks 32 anzeigt, daß einer Auslösung genügt wird, daß dieselbe aber zu der designierten SPA lediglich gemeldet werden soll, ohne die Verarbeitung zurückzuhalten, wird dies in Block 34 durchgeführt, bevor zu dem nächsten PIC fortgeschritten wird. Falls der Test des Blocks 32 schließlich anzeigt, daß einer Auslösung Genüge getan ist, und daß die CS-Verarbeitung zurückgehalten werden soll, während eine Meldung zu der designierten SPA unternommen und eine Antwort empfangen werden soll, schreitet die TCP-Verarbeitung zu einem Block 35 fort, um Meldungen zu der SPA durchzuführen und eine Antwort zu empfangen. In diesem letzteren Fall kann die Antwort von der SPA eine Antwort von dem SPP erfordern (siehe Block 36), wobei bei diesem Fall der Block 35 erneut betreten wird; andernfalls wird die Antwort verarbeitet (Block 37), wobei, falls ein Sprung zu einem PIC angefordert wird, der sich von dem nächsten in der Reihenfolge unterscheidet, (wie es in Block 38 getestet wird) dies bei Block 39 auf Anregen einer TCP-Verarbeitung hin durchgeführt wird.
Als Teil ihrer Antwort bei dem Block 35 kann die SPA eine Ereignismaske einstellen, die danach fragt, daß dieselbe über bestimmte spezifizierte Ereignisse unterrichtet wird, sobald und wann dieselben bei der Verarbeitung des betroffenen CS auftreten. In diesem Fall wird bei einem nachfolgenden TCP diese Ereignismaske bei dem Block 31 (zusammen mit den Auslösekriterien für den betroffenen TCP) untersucht, wobei, falls das angeforderte Ereignis aufgetreten ist, eine geeignete Meldung zurück zu der SPA durchgeführt wird; wie bei den Auslösungen, kann diese Meldung spezifiziert sein, um mit oder ohne eine Zurückhaltung der CS- Verarbeitung aufzutreten, wodurch die TCP-Verarbeitungsblöcke 32 bis 39 gleichermaßen auf angeforderte Ereignisse wie auf Auslösungen anwendbar sind.
Es wird darauf hingewiesen, daß bezüglich des Rufmodells die BCM-Verarbeitung die Kommunikationen mit einer SPA nicht direkt bewirkt; stattdessen kommuniziert die BCM-Verarbeitung, wie es im vorhergehenden beschrieben wurde, Ereignisse, die gemeldet werden sollen, zu der CV-Verarbeitung und den letztgenannten Kommunikationen mit der SPA.

Verbindungsansicht (CV)

Wie bereits darauf hingewiesen wurde, liefert eine CV bezüglich eines speziellen CS eine Darstellung der elementaren Rufverarbeitungsbetriebsmittel, die für eine SPA 12, 13 zugänglich sind. Die CV-Verarbeitungsfunktionalität (Block 23, Fig. 4) leitet die CV und versieht die SPA mit einem Zugang zu den Betriebsmitteln, die durch die CV angezeigt werden, um es zu ermöglichen, daß die SPA die elementare Rufverarbeitung des betroffenen CS (über die BCM-Verarbeitung) sowie die Verbindungsmöglichkeitsaspekte des CS steuert.
Die CV kann die Form einer Sammlung von CV-Objekten, die die elementaren Rufverarbeitungsbetriebsmittel darstellen, die für ein CS relevant sind, durch ein BCM-Objekt und die Verbindungsmöglichkeitsbetriebsmittel durch den CP und die Bein-Objekte annehmen. Der Status der Betriebsmittel, die durch die CV-Objekte dargestellt werden, bildet zu jedem Zeitpunkt den CV-Zusammenhang; wie es in Fig. 9 dargestellt ist, weist der CV-Zusammenhang 40 eine Komponente (der BCM- Zusammenhang 41), die die Rufverarbeitungs- (BCM-) -Aspekte des betroffenen CS betrifft, und eine Komponente (den Verbindungsmöglichkeitszusammenhang 42) auf, die die Verbindungsmöglichkeitsaspekte des CS betrifft.
Fig. 9 zeigt ferner die Informationsflüsse, die für die CV- Verarbeitung relevant sind, die bezüglich einer CV ausgeführt wird. Inbesondere können Rufverarbeitungsereignisse entweder von einer BCM-Verarbeitung 22 oder einer zugrundeliegenden Rufverarbeitung 21 gemeldet werden, wobei Steuerungsgrundelemente zu diesen letztgenannten übertragen werden können. Darüberhinaus können "Schalter-CV"-Meldungen zu einer SPA 12, 13 übergeben werden und "SPA-CV"-Mitteilungen zurückempfangen werden.
Die Handhabung der CV, die durch die CV-Verarbeitungsfunktionalität bewirkt wird, weist folgende Schritte auf: Erzeugen einer CV bezüglich eines speziellen CS, wann immer eine Ereignismeldung von dem entsprechenden BCM anzeigt, daß ein Dienst von einer SPA 12, 13 angefordert werden soll; Melden von Ereignissen (inklusive von Auslösungen) zu einer SPA, wie es erforderlich ist, zusammen mit einer Kopie des CV-Zusammenhangs; Aktualisieren des CV-Zusammenhangs, um die Änderungen des Statusses der Rufverarbeitungsbetriebsmittel aufgrund entweder von Rufverarbeitungsereignissen in dem SSP oder aufgrund von Tätigkeiten, die die Rufverarbeitungsbetriebsmittel ansprechend auf "SPA-CV"-Mitteilungen von einer SPA manipulieren, wiederzuspiegeln; und Entfernen der CV, wenn dieselbe für die SPA nicht länger von Interesse ist.

Stabiles-CS-Melden

Es wird hierin im folgenden erklärt werden, daß die SPA, die im folgenden bezüglich Fig. 10 beschrieben wird, eine Kenntnis dessen erfordert, wann ein CS, zu dem dieselbe einen Dienst bereitstellt, dessen stabile Phase während der Rufverarbeitung erreicht. Aus der vorhergehenden Beschreibung wird ersichtlich, wie dies erreicht werden kann.
Wenn eine Auslösung während der Verarbeitung eines HCM erfaßt wird, die anzeigt, daß ein Dienst von einer SPA angefordert werden soll, meldet dies das BCM insbesondere zu der CV-Verarbeitung, wobei sich die Erzeugung einer entsprechenden CV und die Ausgabe einer "Schalter-CV"-Mitteilung zu der SPA ergibt. Die Auslösung wird auf eine festgelegt, bezüglich der eine Antwort von der SPA erfordert wird. Die SPA- Antwort, die in einer "SPA-CV"-Meldung zurückgesendet wird, wird angeordnet, um eine Ereignismaske aufzuweisen, die anfragt, daß dieselbe über das Auftreten des Ereignisses informiert wird, das das CS in dessen stabile Phase nimmt (für ein Ursprungs-CS würde dies ein "Rufaufbau-autorisiert"- Ereignis sein); diese Ereignismaske wird zu dem BCM für das CS übergeben. Wenn das Ereignis, das das CS-Eintreten in dessen stabile Phase anzeigt, auftritt, wird darauffolgend die relevante TCP-Verarbeitung eine Meldung bewirken, die zu der SPA durchgeführt werden soll.

Dienstbereitstellungsvorrichtung (SPA)

Fig. 10 zeigt eine Form der SPA, die die vorliegende Erfindung darstellt und für die SPA 12, 13 von Fig. 1 verwendet werden kann. Die aktuellen Details der Hardware und Software, die erforderlich sind, um einen speziellen Dienst bereitzustellen, sind für die vorliegende Erfindung nicht relevant und werden folglich hierin nicht beschrieben werden. Was von Interesse ist, ist die allgemeine fehlertolerante Architektur, die für die SPA verwendet wird.
Bei dem Ausführungsbeispiel von Fig. 10 weist die SPA eine erste Dienstlogik 50 typischerweise in der Form eines All zweckprozessors (inklusive eines lokalen Speichers) auf, auf dem eine Betriebssystemsoftware, um eine SLEE-Funktionalität bereitzustellen, und eine oder mehrere SLP-Programme laufen. Die erste Dienstlogik 50 steht durch eine Schnittstelle 51 in Wechselwirkung mit einem SSP und liefert normalerweise die Funktionalität der SPA bezüglich des Bereitstellens der Dienste für den SSP.
Die SPA weist ferner eine zweite Dienstlogik 52 auf, die im wesentlichen dieselbe Funktionalität wie die erste Dienstlogik 50 aufweist, aber normalerweise nicht in Betrieb ist. Die zweite Dienstlogik 52 dient als eine Sicherung bezüglich der ersten Dienstlogik 50 in dem Fall eines Ausfallens der Letztgenannten. Eine Erholungssteuerungsfunktionseinheit 53 überwacht die erste Dienstlogik 50 und bringt auf das Erfassen eines Ausfallens der Letztgenannten hin die zweite Dienstlogik 52 in Betrieb und steuert die Schnittstelle 51 bezüglich Umschaltungsmeldungen von dem SSP zu der Logik 52 und nicht zu der Logik 50.
Um es zu ermöglichen, daß die zweite Dienstlogik fortfährt, Dienste bezüglich zumindest einiger der Dienstanforderungen bereitzustellen, die durch die erste Dienstlogik 50 zu dem Zeitpunkt ihres Ausfallens gehandhabt wurden, ist ein zuverlässiger Sicherungsspeicher 55 vorgesehen. Die erste Dienstlogik 50 ist angeordnet, um auf eine CS-Dienstanforderung anzusprechen, um die Ereignismaske für das BCM des anfordernden CS einzustellen, derart, daß das Letztgenannte bewirken wird, daß die erste Dienstlogik 50 informiert wird, wenn das CS in dessen stabile Phase der Rufverarbeitung eintritt. Auf das Informiertsein der ersten Dienstlogik 50 hin, daß ein CS, für das dieselbe augenblicklich Dienste bereitstellt, in seine stabile Phase eingetreten ist, wird die Dienstlogik 50 zu dem zuverlässigen Speicher 55 alle relevanten Statusdaten zum Verarbeiten der CS-Dienstanforderungen speichern; diese Daten werden relevante CV-Zusammenhangdaten und Statusdaten über die SLP-Verarbeitung aufweisen, die gerade ausgeführt wird, um die Dienstanforderung zu bearbeiten. Falls natürlich ein CS seine stabile Phase bereits vor der Anforderung eines Dienstes erreicht hat, wird die Dienstlogik 50 ansprechend auf die Dienstanforderung geeignete Statusdaten zu dem Speicher 55 speichern.
Unter der Annahme, daß die erste Dienstlogik 50 fortfährt, normal zu arbeiten, werden, sollten sich die Statusdaten, die für das CS relevant sind, ändern, die Statusdaten wieder zu dem Speicher 55 gespeichert (alternativ werden lediglich die Änderungen gespeichert). Auf das Abschließen von Dienstbereitstellungen für eine angeforderte CV durch die Dienstlogik 50 hin wird die Logik 50 bewirken, daß die Statusdaten, die in dem Speicher 55 gehalten werden und für das CS relevant sind, gelöscht werden.
Wenn eine Dienstanforderung lediglich eine einzige, unmittelbare Antwort erfordert, werden bezüglich dieser Anforderung keine Statusdaten zu dem Speicher 55 übergeben.
Falls die erste Dienstlogik 50 ausfallen sollte und die zweite Dienstlogik 52 in Betrieb gebracht ist, sind die Statusdaten über die Dienste, die gerade für die CSs, die ihre stabilen Phasen erreicht haben, bereitgestellt sind, für die zweite Dienstlogik verfügbar, um es zu ermöglichen, daß dieselbe fortzufährt, die relevanten Dienste auf eine Art und Weise bereitzustellen, die für den Benutzer unmerklich ist. Während es möglich wäre, einfach alle Statusdaten, die in dem Speicher 55 gehalten werden, zu der Sicherungsdienstlogik 52 zu übergeben, würde dies eine erhebliche Zeitdauer in Anspruch nehmen, falls dies alles zusammen durchgeführt wird. Dementsprechend ist es vorzuziehen, Statusdaten über jedes CS wiederherzustellen, sobald und wenn die zweite Dienstlogik 52 Meldungen von einem SSP bezüglich eines augenblicklichen Dienstes empfängt.
Der zuverlässige Speicher 55 ist beispielsweise eine fehlertolerante Datenbasis oder ein Plattenlaufwerk. Dieser Speicher 55 wird typischerweise angeordnet sein, um perio disch seinen Inhalt abzutasten, und Eintragungen zu entfernen, die länger als eine vorbestimmte Zeitdauer vorhanden waren, die größer eingestellt ist als die maximale praktische Zeit, über die hinweg eine Dienstanforderung gegenwärtig sein wird; auf diese Art und Weise wird verhindert, daß der Speicher 55 mit wertlosen Eintragungen vollgestopft wird.
Es wird darauf hingewiesen, daß mehr als eine Sicherungsdienstlogik vorgesehen sein kann, so daß, sollte die zweite Dienstlogik 52 ebenfalls ausfallen, eine weitere Dienstlogik in Betrieb gebracht werden kann usw. Wenn mehrere Sicherungsdienstlogiken vorgesehen sind, wird jede, wenn sie die aktive Logik ist, dieselben Prozesse des Speicherns der Statusdaten über stabile CS ausführen, wie es im vorhergehenden für die Logik 50 beschrieben wurde.
Natürlich können verschiedene andere Modifikationen an der SPA von Fig. 10 vorgenommen werden. Beispielsweise kann der Punkt in der CS-Rufverarbeitung, bei dem die Statusdaten gespeichert worden sind, von dem präzisen BCM-Ausgangsereignis variiert werden, das das CS in dessen stabile Phase nimmt; der wichtige Punkt besteht darin, daß, da die meisten Dienstbereitstellungstätigkeiten während des Rufaufbaus auftreten, und da das vorgesehene Speichern der Statusdaten, die für die Dienstbereitstellungen für ein CS relevant sind, nicht gestartet werden, bis nachdem die Mehrheit der Dienstbereitstellungstätigkeiten, die während eines CS-Aufbaus erforderlich sind, abgeschlossen worden sind, es erheblich weniger Speicherungsoperationen geben wird, als erforderlich wären, falls alle Dienstbereitstellungstätigkeiten eine Speicherung zu dem Speicher 55 in Gang setzen würden.
Darüberhinaus wird in dem Fall, daß viele der Dienste durch die SPA bereitgestellt werden sollen, das Dienstbereitstellungs-SLP an dem Punkt oder nahe bei dem Punkt aufgerufen, bei dem das CS in dessen stabile Phase eintritt. Bei solchen Fällen kann das SLP selbst verwendet werden, um eine Speicherung der Statusdaten zu dem Speicher 55 in Gang zusetzen, ohne daß irgendeine Notwendigkeit vorliegt, daß eine explizite Ereignismeldung von dem SSP vorgenommen werden muß; es besteht folglich keine Notwendigkeit dafür, daß die entsprechende BCM-Ereignismaske auf das Anforderungsereignis eingestellt werden soll, das ein Identifizieren eines Eintritts in die stabile Phase der CS-Rufverarbeitung meldet. Tatsächlich kann ein Lösungsansatz aufgegriffen werden, bei dem kein Dienst das Melden eines Ereignisses spezifisch anfordern wird, um das Speichern der Statusdaten in Gang zu setzen; stattdessen wird das Speichern der Statusdaten zuerst für einen speziellen Dienst bewirkt, wann immer bestimmt wird, daß die nächste nachfolgende Tätigkeit, die auf dem Dienst durchgeführt werden soll, nicht auftreten kann, bis nachdem das betroffene CS in seine stabile Phase eingetreten ist. Dies kann bedeuten, daß die Statusdaten früh in der Aufbauphase eines CS gespeichert werden, falls die nächste Dienstbereitstellungstätigkeit eine derartige ist, die nicht auftreten wird, bis nachdem das CS in dessen stabile Phase eingetreten ist.
Es wird darauf hingewiesen, daß unabhängig davon, ob das erste Speichern der Statusdaten explizit durch den SSP angefordert wird oder durch die SPA gemäß dessen bestimmt wird, wo sich dieselbe in dem Prozeß der Dienstbereitstellung befindet, die Wirkung darin besteht, das Speichern der Statusdaten aufzuschieben, bis nachdem alle oder die meisten der Dienstbereitstellungstätigkeiten abgeschlossen worden sind, die während eines CS-Aufbaus erforderlich sind.

Claims

1. Dienstbereitstellungsvorrichtung zum Bereitstellen von Rufverarbeitungsdiensten für ein Umschaltungszentrum eines Telekommunikationsnetzwerkes bezüglich Rufsegmenten, die durch dasselbe aufgebaut, beibehalten und gelöscht werden, dadurch gekennzeichnet, daß die Dienstbereitstellungsvorrichtung folgende Merkmale aufweist:

- eine erste Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungszentrum im Normalfall,

- eine zweite Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungszentrum im Fall eines Ausfallens der ersten Dienstlogikeinrichtung,

- eine Erholungseinrichtung, die auf ein Ausfallen der ersten Dienstlogikeinrichtung anspricht, um die zweite Dienstlogikeinrichtung in Betrieb zu bringen, und

- einen Sicherungsspeicher,

wobei die erste Dienstlogikeinrichtung wirksam ist, um in dem Sicherungsspeicher Statusdaten zu speichern, die durch die erste Dienstlogikeinrichtung bezüglich einer Dienstbereitstellung für das oder jedes Rufsegment gehalten werden, für das dieselbe augenblicklich Dienste bereitstellt, wobei dieses Speichern der Statusdaten bezüglich eines Rufsegmentes lediglich bewirkt wird, nachdem die erste Dienstlogikeinrichtung bestimmt hat, daß sie im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens des entsprechenden Rufsegmentes erforderlich sind, und wobei die zweite Dienstlogikeinrichtung auf das In-Betrieb-Bringen hin von dem Sicherungsspeicher Statusdaten empfängt, die notwendig sind, damit dieselbe fortfährt, Dienste bezüglich augenblicklicher Rufsegmente bereitzustellen.

2. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der die erste Dienstlogikeinrichtung bestimmt, daß sie im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens des entsprechenden Rufsegments erforderlich sind, wenn dieselbe durch das Umschaltungszentrum darüber informiert wird, daß zumindest die Mehrheit der Rufsegmentaufbauprozesse abgeschlossen worden ist.

3. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der die erste Dienstlogikeinrichtung bestimmt, daß sie im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens der entsprechenden Rufsegmente erforderlich sind, wenn dies der Fortschritt der Dienstbereitstellung durch die Dienstlogikeinrichtung bezüglich eines speziellen Rufsegmentes so anzeigt.

4. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der die erste Dienstlogikeinrichtung bestimmt, daß sie im wesentlichen zumindest die Mehrheit ihrer Dienstbereitstellungstätigkeiten abgeschlossen hat, die während des Aufbauens der entsprechenden Rufsegmente erforderlich sind, wenn dieselbe bestimmt, daß es sein kann, daß die nächste Dienstbereitstellungstätigkeit nicht erforderlich ist, bis das entsprechende Rufsegment in dessen stabile Phase eingetreten ist.

5. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der nach dem ersten Speichern der Statusdaten in dem Sicherungsspeicher bezüglich eines speziellen Rufsegmentes durch die erste Dienstlogikeinrichtung jegliche Änderungen dieser Statusdaten in der ersten Dienstlogikeinrichtung eine Aktualisierung der Statusdaten bewirken, die in dem Sicherungsspeicher gehalten sind.

6. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der der Sicherungsspeicher eine fehlertolerante Datenbasis ist.

7. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der die Statusdaten, die ein spezielles Rufsegment betreffen, zu der zweiten Dienstlogikeinrichtung lediglich dann übergeben werden, wenn die Letztgenannte solche Informationen als ein Ergebnis einer Kommunikation von dem Umschaltungszentrum erfordert.

8. Dienstbereitstellungsvorrichtung gemäß Anspruch 1, bei der Sitzungen eines oder mehrerer Rufe eingerichtet werden können, wobei Sitzungsinformationen über solche Sitzungen in der Dienstbereitstellungseinrichtung gehalten und in dem Sicherungsspeicher gespeichert werden, wobei die Sitzungsinformationen auf das In-Betrieb-Bringen der zweiten Dienstlogikeinrichtung hin von dem Sicherungsspeicher zu der zweiten Dienstlogikeinrichtung lediglich dann übergeben werden, wenn die Statusdaten für ein augenblickliches Rufsegment, das für die entsprechende Sitzung relevant ist, ebenfalls zu der zweiten Dienstlogikeinrichtung übergeben werden.

9. Dienstbereitstellungsvorrichtung zum Bereitstellen von Rufverarbeitungsdiensten für ein Umschaltungszentrum eines Telekommunikationsnetzwerkes bezüglich Rufsegmenten, die durch dasselbe aufgebaut, beibehalten und gelöscht werden, dadurch gekennzeichnet, daß die Dienstbereitstellungsvorrichtung folgende Merkmale auf weist:

- einen Sicherungsspeicher,

wobei die erste Dienstlogikeinrichtung wirksam ist, um in dem Sicherungsspeicher Statusdaten zu speichern, die durch die erste Dienstlogikeinrichtung bezüglich einer Dienstbereitstellung für das oder jedes Rufsegment gehalten werden, für das dieselbe augenblicklich Dienste bereitstellt, wobei dieses Speichern der Statusdaten bezüglich eines Rufsegmentes lediglich bewirkt wird, nachdem zumindest die Mehrheit der Aufbauprozesse für das Segment abgeschlossen worden ist, und wobei die zweite Dienstlogikeinrichtung auf das In-Betrieb-Bringen hin von dem Sicherungsspeicher Statusdaten empfängt, die notwendig sind, damit dieselbe fortfährt, Dienste bezüglich augenblicklicher Rufsegmente bereitzustellen.

10. Ein Telekommunikationsnetzwerk mit einem Umschaltungssystem zum Bewirken einer elementaren Rufverarbeitung, um Rufe aufzubauen, beizubehalten und zu löschen, und einer Dienstbereitstellungseinrichtung, die mit dem Umschaltungssystem kommuniziert, zum Bereitstellen von Diensten zusätzlich zu der elementaren Rufverarbeitung; wobei das Umschaltungssystem den Ruf so behandelt, als ob derselbe zumindest einen Rufabschnitt aufweist, und wobei das System wirksam ist, um den oder jeden solchen Rufabschnitt aufzubauen, beizubehalten und zu löschen, wobei das Umschaltungssystem eine Schnittstelleneinrichtung zum Bilden einer Schnittstelle zwischen dem System und der Dienstbereitstellungseinrichtung aufweist, um dadurch das Umschaltungssystem in die Lage zu versetzen, von derselben eine Dienstbereitstellung für einen speziellen Rufabschnitt anzufordern, um der Dienstbereitstellungseinrichtung über den Fortschritt hinsichtlich des Prozesses des Aufbauens, Beibehaltens und Löschens dieses Rufabschnittes zu berichten, und um es zu ermöglichen, daß die Dienstbereitstellungseinrichtung diesen Prozeß gemäß dem Dienst, der durch die Dienstbereitstellungseinrichtung bereitgestellt wird, beeinflußt, dadurch gekennzeichnet, daß

- die Schnittstelleneinrichtung wirksam ist, um der Dienstbereitstellungseinrichtung zu berichten, wann das Aufbauen des entsprechenden Rufabschnittes zumindest im wesentlichen abgeschlossen ist; und

- die Dienstbereitstellungseinrichtung folgende Merkmale aufweist: eine erste Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungssystem im Normalfall, eine zweite Dienstlogikeinrichtung zum Bereitstellen der Dienste für das Umschaltungssystem im Fall eines Ausfallens der ersten Dienstlogikeinrichtung, eine Erholungseinrichtung, die auf ein Ausfallen der ersten Dienstlogikeinrichtung anspricht, um die zweite Dienstlogikeinrichtung in Betrieb zu bringen, und einen Sicherungsspeicher; wobei die erste Dienstlogikeinrichtung wirksam ist, um in dem Sicherungsspeicher Rufabschnitt-bezogene Daten zu speichern, die durch die erste Dienstlogikeinrichtung bezüglich des oder jedes Rufabschnitts gehalten werden, für das dieselbe augenblicklich Dienste bereitstellt, wobei diese Sicherung bezüglich des Rufabschnittes lediglich bewirkt wird, nachdem die Schnittstelleneinrichtung des Umschaltungssystems gemeldet hat, daß das Aufbauen dieses Rufabschnittes zumindest im wesentlichen abgeschlossen worden ist, und wobei der zweiten Dienstlogikeinrichtung auf das In-Betrieb-Bringen hin von dem Sicherungsspeicher die Rufabschnitt-bezogenen bereitgestellt werden, die notwendig sind, um fortzufahren, die angeforderten Dienste bezüglich der augenblicklichen Rufabschnitte bereitzustellen.