DE112004001819B4

DE112004001819B4 - Endpunkt-Registrierung mit lokaler Verzögerungszeit in einem Rufabwicklungssystem

Info

Publication number: DE112004001819B4
Application number: DE112004001819.6T
Authority: DE
Inventors: Sachin Garg; Chandra M. R. Kintala; Edward Vincent Naybor; David Thomas Stott
Original assignee: Avaya Inc
Current assignee: Avaya Inc
Priority date: 2003-09-30
Filing date: 2004-09-30
Publication date: 2016-07-07
Anticipated expiration: 2024-10-01
Also published as: WO2005033900A3; GB0603998D0; GB2421145A; DE112004001819T5; US20050068907A1; US8050199B2; WO2005033900A2; GB2421145B

Abstract

Verfahren umfassend:
(A) Empfangen einer Angabe einer Dauer M_opt an einem Endpunkt, wobei:
i. die Angabe der Dauer M_opt während einer ersten Registrierung des Endpunkts bei einem Rufabwicklungssystem empfangen wird, und
ii. infolge der ersten Registrierung eine Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem hergestellt wird; und
(B) in Ansprechen auf eine Erkennung eines Fehlers der Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem,
eine Nachricht von dem Endpunkt übertragen wird, wobei:
i. die Nachricht als Teil einer zweiten Registrierung des Endpunkts bei dem Rufabwicklungssystem übertragen wird,
ii. die Nachricht nach Ablauf einer Verzögerungsdauer seit der Erkennung des Fehlers übertragen wird,
iii. die Verzögerungsdauer eine Dauer D aufweist,
iv. D von dem Endpunkt zufällig ausgewählt ist,
v. D kleiner oder gleich M_opt ist.

Description

Prioritätsbeanspruchung
Die vorliegende Anmeldung beansprucht die Priorität der provisorischen US-Patentanmeldung 60/507,179, eingereicht am 30. September 2003, mit dem Titel ”Method and Apparatus for Dependability Enhancement in a Distributed Multi-Site Call Center”, deren Offenbarungsgehalt hier vollumfänglich durch Bezugnahme einbezogen wird.
Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein Rufzentralen oder andere Rufabwicklungssysteme, bei welchen Spracheanrufe, E-Mails, Faxe, Sprachnachrichten, Textnachrichten, Internetdiensteanforderungen oder andere Arten von Kommunikationsvorgängen zur Abwicklung auf eine Anzahl von dienstleistenden Agenten verteilt werden, und spezieller Rufzentralen, welche mehrere geographisch verteilte Arbeitsstellen umfassen.
Hintergrund der Erfindung
Rufzentralen verteilen Rufe/Anrufe und andere Arten von Kommunikationsvorgängen oder Arbeitsaufträgen an verfügbare dienstleistende Agenten entsprechend verschiedenen vorgegebenen Kriterien. Eine gegebene Rufzentrale kann in einer geographisch verteilten Weise implementiert sein, z. B. als Kombination mehrerer verteilter Standorte der Rufzentrale an unterschiedlichen Orten. Eine solche Anordnung wird im Allgemeinen als Multistandort-Rufzentrale oder allgemeiner als Multistandort-Rufabwicklungssystem bezeichnet. Bei Multistandortsystemen dieser Art wird typischerweise ein zentralisierter Lastausgleichsprozess genutzt, um Kommunikationsvorgänge zur Bearbeitung auf die verschiedenen Standorte zu verteilen.
Ein exemplarisches Multistandort-Rufabwicklungssystem ist in US-Patent 6,633,640 , erteilt am 14. Oktober 2003 für die Erfinder R. A. Cohen et al., mit dem Titel ”Methods and Apparatus for Analysis of Load-Balanced Multi-Site Call Processing Systems” beschriebenen, welches zusammen mit dem vorliegenden abgetreten worden ist und hier durch Bezugnahme einbezogen wird.
Trotz der zahlreichen Vorteile, die durch die Verfahren bereitgestellt werden, welche in dem vorstehend zitierten Dokument beschrieben sind, bleibt die Notwendigkeit für weitere Verbesserungen bestehen, insbesondere was die Verbesserung der Zuverlässigkeit von Multistandort-Rufabwicklungssystemen betrifft. Beispielsweise steht eine wichtige Ursache für eine Instabilität in einem gegebenen Multistandort-Rufabwicklungssystem mit einer Überlastungssituation in Verbindung, wenn Endpunkte nach einem Netzwerkfehler, Geräteausfall oder einem anderen ähnlichen Zustand versuchen, sich zu registrieren. Es werden Verfahren benötigt, welche in diesen und anderen Situationen ein besseres Leistungsverhalten bieten können.
Die EP 1 047 241 A2 bezieht sich auf ein System und ein Verfahren zum Wiederanfahren von Signalisierungseinheiten in H.323-basierten Echtzeit-kommunikationsnetzen.
Die US 5,226,077 bezieht sich auf einen Verstärker für Telefonkopfhörer mit automatischer An/Aus-Detektion.
Die WO 01/69862 A2 beschreibt ein drahtloses Mobilfunknetz umfassend einen Mobilfunkteilnehmer, der mit einem Server über eine erstes drahtlose Strecke durch das Netz kommuniziert, wobei Weiterleitungsknoten gemäß einem Protokoll miteinander kommunizieren, durch welches jeder Streckenknoten verbindungsbezogene Informationen zu keinem oder mehreren Nachbarknoten auf der Grundlage eines durch diesen Weiterleitungsknoten entwickelten und gepflegten Verzeichnisbaumes verteilt.
Die US 2003/0123619 A1 sieht einen Mechanismus vor, so dass ein Benutzer die Registrierung seiner Telefonadresse mit einem anderen Endgerät auf eine effiziente und benutzerfreundliche Weise initiieren kann. Der Benutzer initiiert einen Anruf an einen Registrierungsdienst um eine Audioverbindung mit seinem Endgerät einzurichten. Sobald die Audioverbindung hergestellt wird, kann der Benutzer akustisch einen Registrierungsbefehl und seine Identität angeben um die Anmeldung des Benutzers am Terminal für künftige Anrufe zu erleichtern, die an die Telefonadresse des Benutzers gerichtet sind.
Die US 5,978,669 A offenbart ein Verfahren um Missbrauch in einem zellularen Funktelefonsystem zu erfassen. Missbrauch wird angenommen, wenn das System einen Mehrfachzugriff von einer Mobilstation erkennt, wenn eine Kollision der Aktivität auftritt, wenn das System eine vorzeitige Registrierung der Mobilstation empfängt, wenn die Überprüfung oder die Betreiber-initiierte Ortung der Mobilstation eine Existenz der Mobilstation an zwei Orten gleichzeitig offenbart oder wenn die Überwachung der Aktivität des mobilen Teilnehmers ungewöhnliche Aktivität zeigt.
Zusammenfassung der Erfindung
Die vorliegende Erfindung zeigt Techniken zur Verbesserung der Zuverlässigkeit auf, welche zur Implementierung in einem Multistandort-Rufabwicklungssystem oder einer anderen Art von Rufabwicklungssystem geeignet ist.
Entsprechend einem Aspekt der Erfindung nutzt ein Rufabwicklungssystem, welches mehrere verteilte Rufzentralenstandorte umfassen kann, einen Ansatz mit einer lokalen Verzögerungszeit (engl. ”back-off”) für die Endpunktregistrierung. Das Rufabwicklungssystem umfasst eine Mehrzahl von Endpunkten und zumindest einen ersten Server, wobei sich die Endpunkte bei dem ersten Server registrieren, um Anrufe in dem Rufabwicklungssystem zu senden und zu empfangen. In Ansprechen auf einen Ausfall der End-zu-End-Verbindungsfähigkeit oder ein anderes bestimmtes Ereignis wird ein Registrierungsprozess in dem Rufabwicklungssystem für einen gegebenen der Endpunkte ausgelöst. Die Absendung zumindest einer Nachricht der Sequenz wird für den gegebenen Endpunkt in solcher Weise gesteuert, dassan diesem Endpunkt eine lokale zufallsmäßige Verzögerungszeit oder andere lokale Verzögerungszeit für die gesteuerte Nachricht bereitgestellt wird.
Bei einer beispielhaften Ausführungsform wird ein zweiter Server, der als Aggregationsserver implementiert ist, derart konfiguriert, dass er die Absendung von Nachrichten durch die Endpunkte derart steuert, dass eine lokale stochastische (engl. ”random”) Verzögerungszeit für jeden der Mehrzahl von Endpunkten bereitgestellt wird, indem er die Auslieferung von Fehlerbenachrichtigungen an die Endpunkte staffelt.
Vorteilhafterweise wird durch die Erfindung entsprechend der beispielhaften Ausführungsform die zuvor beschriebene Überlastungssituation, die sich ansonsten ergeben könnte, wenn Endpunkte nach einem Netzwerkfehler, Geräteausfall oder einem anderen ähnlichen Zustand versuchen, sich zu registrieren, beträchtlich vermindert.
Kurze Beschreibung der Zeichnungen
1 stellt ein Blockdiagramm eines beispielhaften Multistandort-Rufabwicklungssystems dar, in welchem die Erfindung implementiert werden kann.
2 stellt ein Blockdiagramm einer möglichen Implementierung einer verteilten Rufzentrale in dem Multistandort-Rufabwicklungssystem aus 1 dar.
3 stellt ein Zeitablaufdiagramm dar, das eine erfolgreiche Registrierungssequenz für einen Endpunkt des Systems aus 1 zeigt.
4 stellt ein Zeitablaufdiagramm dar, das einen Engpass zeigt, der sich ergeben kann, wenn in dem System aus 1 eine große Anzahl von Endpunkten im Wesentlichen gleichzeitig Registrierungsversuche unternimmt.
5 stellt ein Zeitablaufdiagramm dar, das die Nutzung einer lokalen stochastischen Verzögerungszeit vor der Auslösung der Registrierung entsprechend einer beispielhaften Ausführungsform der Erfindung zeigt.
6 stellt ein Blockdiagramm einer möglichen Implementierung zumindest eines Teils des Systems aus 1 dar, welche einen Aggregationsserver (AS) entsprechend einer beispielhaften Ausführungsform der Erfindung umfasst.
7 stellt ein Zeitablaufdiagramm dar, das die Funktionsweise des AS aus 6 veranschaulicht. Die 8 bis 12 sind grafische Darstellungen, die verschiedene Aspekte des Leistungsverhaltens beispielhafter Ausführungsformen der Erfindung zeigen.
Detaillierte Beschreibung
Obgleich die Erfindung nachstehend in Verbindung mit der Abwicklung von Anrufen in einem exemplarischen System dargestellt wird, welches mehrere verteilte Rufzentralenstandorte umfasst, ist sie nicht auf die Nutzung mit irgendeiner bestimmten Art von Systemkonfiguration oder Kommunikationsabwicklungsanwendung beschränkt. Beispielsweise kann die Erfindung auch in Rufabwicklungssystemen mit einem einzigen Standort genutzt werden. Zudem ist die Erfindung auf die Abwicklung eingehender Kommunikationsvorgänge, ausgehender Kommunikationsvorgänge oder beider anwendbar. Die offenbarten Verfahren können mit automatischen Rufverteilungs(ACD; für engl. ”automatic call distribution”)-Systemen, Telemarketing-Systemen, Nebenstellenanlagen(PBX; für engl. ”private-branch exchange”)-Systemen, computergestützte Telefonie(CTI; für engl. ”computer-telefonie integration”)-basierten Systemen wie auch in Kombinationen aus diesen und anderen Arten von Rufzentralen genutzt werden. Eine Rufzentrale entsprechend der Erfindung kann unter Nutzung einer beliebigen Netzwerk-Infrastruktur konfiguriert sein, wie beispielsweise dem asynchronen Transfermodus (ATM), lokalen Bereichsnetzen (LAN; für engl. ”local area network”), Weitverkehrsnetzen (WAN; für engl. ”wide area network”), Internetprotokoll(IP)-Netzen, usw.
Der Begriff ”Rufzentrale”, wie er vorliegend genutzt wird, soll somit jede Art von ACD-System, Telemarketing-System oder anderem Kommunikationssystem einschließen, welches Anrufe oder andere Dienstleistungsanforderungen verarbeitet, darunter Sprachanrufe, Videoanrufe, Multimediaanrufe, E-Mails, Faxe, Text-Chat oder Sprachnachrichten wie auch verschiedene Teile oder Kombinationen dieser und anderer Arten von Kommunikationsvorgängen. Der Begriff ”Anruf”, wie er vorliegend genutzt wird, soll jede vorstehend erwähnte Art von Kommunikationsvorgang wie auch Teile oder Kombinationen dieser und anderer Kommunikationsvorgänge einschließen.
1 zeigt ein beispielhaftes Rufabwicklungssystem 10, das mehrere verteilte Rufzentralenstandorte umfasst. Das System 10 umfasst einen Netzanbieter 20, eine zentrale Lastausgleichsanwendung 30 und einen Satz von Leistungsdaten 40. Der Netzanbieter 20 ist über Sätze von Amts/Fernleitungen 50 und 60 mit verteilten Rufzentralenstandorten 100-1 bzw. 100-2 gekoppelt. Jedem der verteilten Rufzentralenstandorte 100-i, i = 1, 2, ... ist ein entsprechender Satz von Agenten-Endgeräten 110-i zugeordnet.
Man wird erkennen, dass, obgleich in 1 nur zwei Standorte gezeigt sind, die Erfindung in einem System mit jeder gewünschten Anzahl von Standorten implementiert werden kann. Außerdem kann die Erfindung, wie zuvor angemerkt, in einem Rufabwicklungssystem mit einem einzigen Standort implementiert werden.
Bei einem Fall einer möglichen Konfiguration kann zumindest eine Teilgruppe der Agenten-Endgeräte 110 über ein oder mehrere (nicht gezeigte) Netze von Dienstanbietern getrennt von den Rufzentralenstandorten 100 vorgesehen sein. Eine solche Konfiguration ist bei Anwendungen wünschenswert, bei welchen die Agenten-Endgeräte geographisch verteilt sein müssen, die Rufzentralenstandorte oder einer oder mehrere zugeordnete Server der Wartungsfähigkeit, Sicherheit oder des Datenschutzes wegen jedoch an einem einzigen Ort lokalisiert sein müssen. Es sind zahlreiche andere Konfigurationen möglich, wie Fachleute auf dem Gebiet erkennen werden.
Die Agenten-Endgeräte 110 können als Beispiele dafür betrachtet werden, was vorliegend allgemeiner als Endpunkte bezeichnet werden soll. Solche Endpunkte können beispielsweise IP-Telefone oder andere Typen von Telefonen, Computerendgeräte, Arbeitsplatzrechner, usw. umfassen.
Jeder der Rufzentralenstandorte 100-1 und 100-2 kann zusätzlich zu anderen Elementen einen oder mehrere Server umfassen, wie später detaillierter beschrieben werden soll.
Die Endpunkte registrieren sich typischerweise bei einem entsprechenden Server des Rufzentralenstandorts, wie allgemein bekannt ist.
Im Betrieb empfängt die zentrale Lastausgleichsanwendung 30 eine Benachrichtigung bezüglich eines eingehenden Anrufs von dem Netzanbieter 20. Die zentrale Lastausgleichsanwendung 30 greift dann auf die Leistungsdaten 40 zu, um festzustellen, wohin der Anruf zu lenken ist, d. h. welcher der verteilten Rufzentralenstandorte 100-i den Anruf empfangen sollte. Die zentrale Lastausgleichsanwendung 30 setzt den Netzanbieter 20 von ihrer Rufzentralenstandort-Auswahl in Kenntnis, und der Netzanbieter 20 leitet dementsprechend den eingehenden Anruf zu dem ausgewählten der verteilten Rufzentralenstandorte 100-i über die entsprechende Leitung weiter. An dem ausgewählten Standort können herkömmliche Agentenauswahl- und Rufauswahlverfahren genutzt werden, um den eingehenden Anruf an ein bestimmtes Agenten-Endgerät der entsprechenden Gruppe von Agenten-Endgeräten 110-i zu lenken. Dieser Vorgang wird für alle eingehenden Anrufe wiederholt, die an das Multistandort-Rufabwicklungssystem 10 gerichtet sind. Leistungsdaten werden von den verteilten Rufzentralenstandorten 100-i gesammelt und werden in dem Leistungsdatensatz 40 gespeichert, zur Nutzung durch die Lastausgleichsanwendung 30 beim Treffen zukünftiger Anruflenkungsentscheidungen.
2 zeigt ein vereinfachtes Blockdiagramm einer möglichen Implementierung eines gegebenen der verteilten Rufzentralenstandorte 100-i in dem System 10 aus 1. Der verteilte Rufzentralenstandort 100-i umfasst Schnittstellen 112 zu externen Kommunikationsverbindungen, ein Kommunikations-Koppelnetz (engl. ”communications switch fabric”) 113 sowie Dienstschaltungen 114, welches z. B. Tonerzeuger, Ansageschaltungen usw. sein können. Der verteilte Rufzentralenstandort 100-i umfasst ferner einen Speicher 115 und einen Prozessor 116. Der Speicher 115 kann zum Speichern von beispielsweise Steuerprogrammen, Daten usw. genutzt werden und kann ein elektronischer Speicher, ein plattenbasierter Speicher oder eine Kombination dieser und anderer Speicherelemente sein. Der Prozessor 116 ist derart konfiguriert, dass er gespeicherte Steuerprogramme ausführt, um die Schnittstellen 112 und das Koppelnetz 113 zu steuern, um Rufverteilungsfunktionalität bereitzustellen und um eine Speicherung oder Verarbeitung von E-Mails, Faxen und anderen Kommunikationsvorgängen zu ermöglichen. Der Prozessor 116 kann z. B. ein Mikroprozessor, eine Zentraleinheit (CPU; für engl. für ”central processing unit”), ein Computer, eine anwendungsspezifische integrierte Schaltung (ASIC; für engl. ”application specific integrated circuit”) oder verschiedenen Teile oder Kombinationen dieser oder anderer Verarbeitungselemente darstellen.
Der verteilte Rufzentralenstandort 100-i aus 1 kann eine Kommunikationssystem-Vermittlungseinrichtung wie etwa die Kommunikationssystem-Vermittlungseinrichtung DEFINITY^® für Unternehmenskommunikationsdienst (ECS; für engl. ”enterprise communication service”) umfassen, die bei der Avaya Inc., Basking Ridge, New Jersey, USA, erhältlich ist.
Ein anderes Beispiel für eine Rufverarbeitungs-Vermittlungseinrichtung, die zur Verwendung in Verbindung mit der vorliegenden Erfindung geeignet ist, ist die Kommunikationssystem-Vermittlungseinrichtung MultiVantage^TM (MV), die ebenfalls bei der Avaya Inc. erhältlich ist.
Solche Einrichtungen können als Beispiele dafür betrachtet werden, was vorliegend allgemeiner als Server bezeichnet wird.
Ein oder mehrere Server oder Teile oder Kombinationen solcher können beispielshalber unter Verwendung des Speichers 115 und des Prozessors 116 implementiert werden.
Generell kann eine beispielhafte Ausführungsform eines gegebenen Rufzentralenstandorts mehrere Server umfassen, wie etwa einen MV-Server, einen dynamisches Host Konfigurations Protokoll(DHCP; für engl ”Dynamic Host Configuration Protocol”)-Server und einen triviales Dateitransferprotokoll(TFTP; für engl. ”Trivial File Transfer Protocol”)-Server. Diese und andere Server-Anordnungen, die üblicherweise in Rufzentralen genutzt werden, sind Fachleuten auf dem Gebiet allgemein bekannt. Solche Server können innerhalb einer System-Vermittlungseinrichtung oder extern einer solchen Vermittlungseinrichtung implementiert sein. Außerdem kann eine Vermittlungseinrichtung als einen oder mehrere Server umfassend betrachtet werden.
Weitere Details, was Rufabwicklungsverfahren betrifft, die in dem verteilten Rufzentralenstandort 100-i genutzt werden können, finden sich z. B. in US-Patent 5,206,903 , erteilt am 27. April 1993 für die Erfinder J. E. Kohler et al., mit dem Titel ”Automatic Call Distributation Based an Matching Required Skills with Agents Skills”; US-Patent 5,905,793 , erteilt am 18. Mai 1999 für die Erfinder A. D. Flockhart et al., mit dem Titel ”Waiting-Call Selection Based an Anticipated Wait Times”; US-Patent 6,192,122 , erteilt am 20. Februar 2001, mit den Titel ”Call Center Agent Selection that Optimizes Call Wait Times”; US-Patentanmeldung 09/219,995, eingereicht am 23. Dezember 1998 im Namen der Erfinder R. A. Cohen und R. H. Foster, mit dem Titel ”Call Selection Based an Continuum Skill Levels in a Call Center”; und US-Patent 6,563,920 , erteilt am 13. Mai 2003 für die Erfinder A. D. Flockhart et al., mit dem Titel ”Methods and Apparatus for Processing of Communications in a Call Center Based an Variable Rest Period Determinations”, welche hier alle durch Bezugnahme einbezogen werden.
Es sei angemerkt, dass die spezielle Anordnung des Systems 10 und seiner Elemente, wie sie in den 1 und 2 gezeigt ist, lediglich beispielshalber angegeben ist und nicht als die Erfindung auf eine bestimmte Ausführungsform oder Gruppe von Ausführungsformen einschränkend betrachtet werden sollte. Die Erfindung kann in vielen anderen Arten von Multistandort-Verarbeitungssystemkonfigurationen implementiert werden, wie etwa solchen, die in US-Patent 5,754,639 beschrieben sind, das am 19. Mai 1998 für die Erfinder A. D. Flockhart et al. erteilt worden ist, mit dem Titel ”Methods and Apparatus for Queuing a Call to the Best Split”, welches hier durch Bezugnahme einbezogen wird.
Das in Verbindung mit den 1 und 2 beschriebene exemplarische System kann in einfach zu übersehender Weise programmiert oder anderweitig konfiguriert werden, um die Verfahren zur Verbesserung der Zuverlässigkeit gemäß der vorliegenden Erfindung zu realisieren, wie sie nachstehend beschrieben sind.
Wie bereits angemerkt, besteht ein wesentlicher Grund für die Instabilität in einem System, wie es zuvor beschrieben worden ist, in einer Überlastungssituation, wenn Endpunkte nach einem Netzfehler, Geräteausfall oder einem anderen ähnlichen Zustand versuchen, sich zu registrieren. Der Begriff ”registrieren” soll im vorliegenden Zusammenhang einen Vorgang umfassen, welcher es IP-Endpunkten oder anderen Endpunkten gestattet, sich bei einem Server bekannt zu machen, sodass sie in dem System Anrufe tätigen und empfangen können. Im Falle von IP-Endpunkten kann der Registrierungsvorgang beispielsweise die Bindung von IP-Adressen für die Endpunkte an bestimmte System-Nebenstellen beinhalten.
Der Vorgang der Fehlererkennung und Registrierung erfolgt in herkömmlichen Systemen typischerweise über einen Austausch von Nachrichten, die in den ITU-T-Empfehlungen spezifiziert sind, darunter der ITU-T-Empfehlung H.323, ”Packet based multimedia communication systems”, 1998, und der ITU-T-Empfehlung H.245, ”Control protocol for multimedia communication”, 1998, welche hier beide durch Bezugnahme einbezogen werden. Wenn beispielsweise an einem IP-Endpunkt eine Zeitüberschreitung der Übertragungssteuerungsprotokoll(TCP; für engl. ”Transmission Control Protocol)-Lebenderhaltung (engl. ”keep-alive”, nachfolgend abgekürzt als ”KA”) auftritt, kann angenommen werden, dass ein Ausfall der Verbindungsfähigkeit aufgetreten ist. Die exakte Feststellung eines Fehlers erfolgt üblicherweise nicht auf Grundlage einer einzigen Zeitüberschreitung sondern einer Folge von KA-Zeitüberschreitungen.
Nach der Feststellung eines Fehlers beginnt der Wiederherstellungsprozess, welcher das Feststellen des Servers und/oder einer zugehörigen Steuerungs-LAN(C-LAN; für engl. ”Control Local Area Network”)-Karte von Avaya oder eines anderen Bauteils und danach die Registrierung des Endpunkts bei diesem Server beinhalten kann. Die Feststellungsprozedur erfolgt mit GRQ/GCF-Nachrichten, wogegen die Registrierung RRQ/RCF-Nachrichten beinhaltet. GRQ und GCF bedeuten Gateway-Anforderung (engl. ”Gateway Request”) bzw. Gateway-Bestätigung (engl. ”Gateway Confirm”), und RRQ und RCF bedeuten Registrierungs-Anforderung engl. ”Registration Request”) bzw. Registrierungs-Bestätigung (engl. ”Registration Confirm). Die Nachrichten GRQ/GCF und RRQ/RCF können insgesamt als ein spezielles Beispiel dafür angesehen werden, was vorliegend allgemeiner als eine ”Registrierungssequenz” bezeichnet wird.
Bei einer beispielhaften Implementierung eines verteilten Systems kann ein Netzausfall an einem gegebenen Rufzentralenstandort die Auslösung einer Wiederherstellungsprozedur von derart vielen wie etwa 1000 oder mehr IP-Telefonen oder anderen Endpunkten innerhalb einer kurzen Zeitspanne bewirken. Die Flut von GRQ-Nachrichten bewirkt, dass der zugehörige Server überlastet wird. Das Endergebnis der Überlastung ist ein Verlust von GRQs, was zu mehrfachen Wiederholversuchen der Registrierung durch eine große Teilgruppe von Endpunkten führt. Einige von diesen können schließlich sogar in einen Neustart-Modus übergehen. Die Überlastung tritt auf, da der Server typischerweise darauf beschränkt ist, nur eine bestimmte Anzahl von gleichzeitigen Registrierungssequenzen, beispielsweise 10, zu bearbeiten. Nehmen wir ein spezielleres Beispiel, so tauscht ein typischer IP-Endpunkt eine Benutzer-Datagramm-Protokoll(UDP; für engl. ”User Datagram Protocol”)-Nachrichtensequenz mit dem Server aus, um sich zu registrieren. Eine erfolgreiche Registrierungsprozedur an dem Server kann die folgenden Schritte beinhalten:

1. Empfang einer GRQ von dem Endpunkt;
2. Senden einer GCF an den Endpunkt als Antwort;
3. Empfang einer RRQ von dem Endpunkt;
4. RCF als Antwort an den Endpunkt.

Die Gesamtzeit, die für diese Schritte benötigt wird, wollen wir als die Registrierungszeit T_reg bezeichnen. Die Zeit und die Nachrichtenaustauschsequenz sind in 3 dargestellt.
Wenn an dem Server nicht innerhalb einer spezifizierten Zeit, z. B. innerhalb von 15 Sekunden ab dem Senden einer GCF-Nachricht zu dem Endpunkt, eine RRQ-Nachricht empfangen wird, fällt der Server von der Registrierung ab. Es sei angenommen, dass der Server aufgrund von Beschränkungen seiner zugehörigen Login-Verwaltungselemente nur 10 gleichzeitige Registrierungen abwickeln kann (obgleich bei anderen Ausführungsformen Login-Verwaltungselemente genutzt werden können, die in der Lage sind, mehr oder weniger gleichzeitige Registrierungen zu behandeln). Anders ausgedrückt, wenn zu irgendeinem Zeitpunkt 10 Registrierungsprozeduren ablaufen, können zu diesem Zeitpunkt keine weiteren GRQs bearbeitet werden. Wenn an dem Server x GRQs innerhalb einer Registrierungszeitspanne ankommen, wobei x größer als 10 ist, dann werden x – 10 Anforderungen fallengelassen. Dieses Problem verschärft sich weiter unter bestimmten Bedingungen, beispielsweise wenn der Server und die IP-Endpunkte durch eine Übersee-WAN(Weitverkehrsnetz)-Verbindung getrennt sind, mit einer beträchtlichen mittleren Einweg-Laufzeit, z. B. einer Laufzeit von etwa 150 Millisekunden oder mehr.
In einem gegebenen System können zwei komplementäre Lösungen implementiert werden, um das Überlastungsproblem bei der Registrierung zu behandeln. Die erste ist eine Ratendrosselung für die GRQs, und die zweite ist die Nutzung von Registrierung-im-Gange(RIP; engl. ”Registration-in-Progress”)-Nachrichten. Diese werden im Nachfolgenden jeweils kurz beschrieben.

1. Ratendrosselung der GRQs. Die Idee besteht darin, die Flut an GRQs zu drosseln, bevor diese den Server erreichen. Eines der Elemente, das eine Drosselung gestattet, ist ein Gateway-Router am Rufzentralenstandort. Bei einem typischen Aufbau kann der Router derart konfiguriert werden, dass er die Rate der GRQ-Anforderungen auf einen Wert bei oder unterhalb der Rate, welche der Server abwickeln kann, limitiert, welche bei etwa 100 GRQs pro Sekunde liegen kann.
2. Nutzung von RIP-Nachrichten. Da der Server im vorliegenden Beispiel nur 10 gleichzeitige Registrierungssequenzen verarbeiten kann, wird im Falle einer GRQ-Flut bei einer beträchtlichen Anzahl von Endpunkten eine Zeitüberschreitung beim Warten auf eine GCF auftreten und diese werden einen Wiederholversuch mit GRQs starten, wodurch sich die Flut verschlimmert. Bei der genannten Lösung sendet der Server, bevor er die GRQ fallen lässt, eine RIP-Nachricht an den Endpunkt ab, welche diesen auffordert, nach einem Auszeitintervall, das in der RIP-Nachricht spezifiziert wird, erneut zu versuchen. Diese Auszeit ist normalerweise länger als die lokale Auszeit an dem Endpunkt, was dazu führt, dass die Ankunft von GRQs an dem Server verlangsamt wird.

Für den Rest der Beschreibung sei die Nutzung einer Ratendrosselung und von RIP-Nachrichten für die Beschreibung der beispielhaften Ausführungsform angenommen, sofern nichts anderes angegeben ist. Außerdem sei angenommen, dass die sich registrierenden Endpunkte IP-Endpunkte sind, obgleich die Verfahren auch auf eine breite Vielfalt anderer Typen von Endpunkten anwendbar sind. Es sollte jedoch erkannt werden, dass diese und andere Annahmen, welche vorliegend angegeben sind, nicht für alternative Ausführungsformen der Erfindung zu gelten brauchen.
Entsprechend einem Aspekt der Erfindung werden die vorstehend beschriebenen Lösungen der Ratendrosselung und der Nutzung von RIP-Nachrichten ergänzt durch die Nutzung eines Ansatzes, welcher vorliegend als lokale stochastische Verzögerungszeit von den Endpunkten bezeichnet wird.
Es sei unterstrichen, dass die Absicht der beispielhaften Ausführungsform nicht darin besteht, die Mechanismen der Ratendrosselung und der RIP-Nachrichten zur Behandlung des Überlastungsproblems bei der Registrierung zu ersetzen, sondern diese zu ergänzen. Bei einer gegebenen Ausführungsform der Erfindung könnte jedoch auch nur der Ansatz der lokalen stochastischen Verzögerungszeit genutzt werden, während einer der zwei anderen Mechanismen oder beide wegfallen.
Die vorgeschlagene Lösung mit lokaler stochastischer Verzögerungszeit bietet die folgenden Vorteile:

1. Sie reduziert die Gesamt-Wiederherstellungszeit, wenn ein Ausfall auftritt. Durch Nutzung von RIPs wird die mittlere Wiederherstellungszeit im Vergleich dazu, wenn keine RIP-Nachrichten abgesendet werden, reduziert. Die Nutzung einer lokalen stochastischen Verzögerungszeit reduziert jedoch die Wiederherstellungszeit weiter.
2. Die Stabilität des Wiederherstellungsprozesses wird verbessert.

Um die Grundideen hinter dem Ansatz der lokalen zufallsmäßigen oder stochastischen Verzögerungszeit in der beispielhaften Ausführungsform zu skizzieren, umreißen wir im Folgenden zunächst den Wiederherstellungsprozess. Zum Zwecke der Erörterung sei angenommen, dass eine C-LAN-Karte hochgerüstet wurde und zurückgesetzt wurde. Dies bewirkt eine beinahe sofortige Fehlererkennung an allen Endpunkten, da für alle offenen Signalisierungskanäle an diesem C-LAN ein TCP-Rücksetz-Paket gesendet wird. Sobald ein Endpunkt den Fehler erkennt, startet er die Wiederherstellungsprozedur durch Absenden einer GRQ-Anforderung.
4 stellt eine Situation dar, bei welcher mehrere im Wesentlichen gleichzeitige Registrierungsversuche in dem System aus 1 erfolgen. In diesem Zeitablaufdiagramm und in anderen hier gezeigten Zeitablaufdiagrammen ist die Zeit auf der horizontalen Achse dargestellt. Ereignisse für typische IP-Endpunkte sind als Symbole dargestellt, mit einer jeweiligen Legende. Es sei angemerkt, dass zum Zwecke der einfachen und übersichtlichen Darstellung keine RRQ-Nachrichten gezeigt sind.
Die GRQs werden an den Endpunkten generiert und werden an dem Server innerhalb einer kurzen Zeitspanne empfangen. Während die ersten 10 GRQs verfügbare Login-Verwaltungselemente an dem Server in Anspruch nehmen und die Registrierungssequenz beginnen, erhalten etwaige nachfolgend ankommende eine RIP-Nachricht zurück. Man beachte jedoch, dass immer noch folgende Bedingungen gelten:

1. GRQs werden an dem Server in eine Warteschlange eingereiht und werden in einer zuerst-herein-zuerst-heraus(FIFO; für. ”first-in-first-out”)-Manier geprüft.
2. Das Senden einer RIP-Nachricht nimmt Ressourcen des Serverprozessors in Anspruch.
3. Es besteht die Möglichkeit, dass eine RIP-Nachricht zurück zu dem Endpunkt bei der Übertragung verloren geht.

Anders ausgedrückt beruht die Lösung mit RIP-Nachrichten auf dem Prinzip der ”Tolerierung” der GRQ-Flut, sobald diese einmal begonnen hat.
Der Ansatz mit einer lokalen stochastischen Verzögerungszeit entsprechend der vorliegenden Erfindung ergänzt den RIP-Ansatz insofern, als er darauf abzielt zu verhindern, dass die GRQ-Flut aufzutreten beginnt. Das Zeitablaufdiagramm aus 5 stellt eine Implementierung des Ansatzes der stochastischen Verzögerungszeit dar.
Die fehlende Ankunft von TCP-KA-Nachrichten von dem C-LAN an dem IP-Endpunkt (mit Auszeiten und Wiederholversuchen) wird als Ausfall der End-zu-End-Verbindungsfähigkeit analysiert. Das Fehlen von RAS-KA-Nachrichten kann, wenn geeignet, ebenfalls zur Erkennung von Fehlern genutzt werden. Sobald ein IP-Endpunkt einen Fehler erkennt, startet er den Neuregistrierungsprozess, indem er eine GRQ-Nachricht an das C-LAN in seiner Liste absendet. Bei dem Ansatz mit stochastischer Verzögerungszeit gemäß der beispielhaften Ausführungsform hält der IP-Endpunkt nach der Fehlererkennung und bevor die GRQ gesendet wird, die Übertragung derselben um eine stochastische Verzögerungszeit zurück. Der Bereich der Zufallszahlen wird durch solche Faktoren wie die Gesamtanzahl von IP-Endpunkten, die Plattform (z. B. Avaya DEFINITY^® Gar, Avaya DEFINITY^® S8700, usw.) bestimmt und sollte vorzugsweise vorkonfiguriert werden. Bei einem Szenario mit mehr als 1000 IP-Telefonen oder anderen Endpunkten an einem einzigen Rufzentralenstandort wird, wenn gleichzeitig die Wiederherstellung startet, die Auslösung der Registrierung aufgrund der Verzögerungszeit gestaffelt. Dies hat mehrere potenzielle Vorteile, welche nachstehend aufgeführt sind.

1. Die Erzeugung von RIP-Nachrichten nimmt CPU-Ressourcen an dem Server in Anspruch. Die Nutzung lokaler Verzögerungszeiten verringert die Konkurrenz um die CPU-Ressourcen an dem MV-Server, und dadurch sind dann mehr CPU-Ressourcen für die Abwicklung der Registrierung und die Anrufabwicklung verfügbar, da die Notwendigkeit für die Erzeugung von RIP-Nachrichten reduziert wird.
2. Die System/Endpunkt-Wiederherstellung ist weniger anfällig bezüglich eines Verlusts an RIP-Nachrichten, da es von Anfang an weniger RIP-Nachrichten gibt. Wie zuvor angemerkt, kann eine RIP-Nachricht von dem Server zu dem Endpunkt bei der Übertragung im Netz verloren gehen.
3. GRQ-Nachrichten werden bei verschiedenen Prozessen/Komponenten in eine Warteschlange eingereiht, bevor sie letztendlich von dem Server bearbeitet werden. Diese umfassen die CLAN-Schnittstelle und zugehörige Prozesse höherer Protokolle, andere Prozesse an dem Server, usw. Es ist möglich, dass bei einem plötzlichen Schub von GRQs einige Warteschlangen überlaufen, was zum Verlust einer GRQ führt, bevor diese bearbeitet wird. Durch die lokale Verzögerungszeit an dem Endpunkt wird die Wahrscheinlichkeit dafür, dass eine Warteschlange überläuft, beträchtlich reduziert, indem die GRQ-Rate an der Quelle, d. h. dem Endpunkt, reguliert wird.
4. Generell ist die Wiederherstellungszustandsmaschine stabiler, da die Wahrscheinlichkeit geringer ist, dass der Endpunkt seine Wiederholversuche bei einer verfügbaren C-LAN-Karte aufgibt und daher eine andere auf der Liste versucht. In einigen Fällen ohne Übermittlung von RIP-Nachrichten wurde festgestellt, dass Telefone in einen Neustartzyklus übergingen.

Die vorstehenden Vorteile führen unmittelbar zu einer Reduzierung der mittleren Wiederherstellungszeit für einen IP-Endpunkt in einer Situation, in der eine große Anzahl von IP-Endpunkten die Verbindungsfähigkeit verliert und versucht, sich neu zu registrieren. Anders ausgedrückt ist bei einem Rufzentralen-Szenario die mittlere Gesamtzeit, welche zur Wiederherstellung für die Endpunkte benötigt wird, im Vergleich zu dem Fall, bei dem von den Endpunkten keine stochastische Verzögerungszeit genutzt wird, geringer. Dieser Vorteil wird nachfolgend detailliert quantifiziert und erklärt.
Den IP-Endpunkten wird in der beispielhaften Ausführungsform vorzugsweise eine Angabe für eine optimale Verzögerungsdauer M_opt zur Verfügung gestellt. Wenn die Registrierungsprozedur beginnt, können die Endpunkte einen Zufallswert zwischen 0 und M_opt heranziehen und können so viele Sekunden lang warten, bevor sie GRQs absenden. Da diese M_opt von der Anzahl der Endpunkte abhängt, die bei dem Server registriert sind, sowie der CPU-Kapazität der Server-Plattform, besteht eine Möglichkeit der Benachrichtigung und/oder Konfigurierung der Endpunkte über den Server.
Beispielsweise während eines anfänglichen Urladens und/oder einer Registrierungsprozedur (bei der eine Standard-Verzögerungszeit von 0 Sekunden genutzt werden kann) gibt der MV-Server dem Endpunkt den Wert für M_opt an. Dieser Wert kann in dem MV-Server statisch von einem Administrator konfiguriert werden oder kann dem Server anderweitig zur Verfügung gestellt werden.
Es ist auch möglich, dass die Endpunkte den Wert für M_opt von einem DHCP-Server in einem der optionalen Parameter erhalten. Der DHCP-Server wiederum könnte manuell administriert werden oder den Wert anderweitig erhalten.
Entsprechend einem weiteren Aspekt der Erfindung wird ein zusätzliches Architekturelement eingeführt, das wir als Aggregationsserver (AS) bezeichnen. Der Zweck dieses zusätzlichen Elements besteht nicht nur darin, die Überlastungsprobleme bei der Registrierung lösen zu helfen, sondern auch andere Vorteile zu bieten, die nachstehend erörtert werden sollen.
6 stellt ein Beispiel für die Platzierung eines AS an einem exemplarischen Rufzentralenstandort wie auch dessen Funktionalität dar. Obwohl der AS in der Figur als separates Netzwerkelement gezeigt ist, ist dies nicht notwendigerweise der Fall. Beispielsweise könnten einige der Fähigkeiten des AS zusammen mit einem anderen Systemserver lokalisiert sein, beispielsweise einem MV-Server oder einem TFTP-Server. Der in 6 gezeigte Satz von Systemelementen kann als eine mögliche Implementierung zumindest eines Teils des Multistandort-Rufabwicklungssystems aus 1 oder eines Rufabwicklungssystems mit einem einzigen Standort betrachtet werden.
Die Abkürzung RRJ in der Figur bedeutet Registrierungszurückweisung (engl. ”Registration Reject”), die Abkürzung RAS bedeutet Registrierungsannahmesignalisierung (engl. ”Registration Admissions Signaling”) und die Abkürzung KA bedeutet Lebenderhaltung (engl. ”Keep-Alive”).
Wie in der Figur gezeigt ist, umfasst das Rufabwicklungssystem 200 eine Vermittlungseinrichtung 202 DEFINITY^® ECS von Avaya, die als Elemente in der vorliegenden Ausführungsform eine C-LAN-Karte 204 von Avaya und einen Software-basierten MV-Server 206 umfasst. Die Vermittlungseinrichtung 202 ist über ein LAN 212, einen Router 214, ein WAN 216 und einen Router 218 mit einem AS 210 verbunden. Der AS 210 ist über ein LAN 220 mit Endpunkten 222 verbunden. Somit ist der AS 210 in der vorliegenden Ausführungsform zwischen die Vermittlungseinrichtung 202 und die Endpunkte 222 gekoppelt.
Das C-LAN 204 dient in der vorliegenden Ausführungsform als eine IP-Schnittstelle zu dem MV-Server 206. Beispielsweise empfängt das C-LAN GRQ-Nachrichten und leitet diese an den MV-Server weiter.
Bei einem exemplarischen Aufbau dieser Art sind die IP-Endpunkte 222 typischerweise mit dem MV-Server 206 über eine WAN-Verbindung verbunden. Solche Funktionen wie Fehlererkennung, Registrierung, Rufsignalisierung und Rufdaten laufen alle über die WAN-Verbindung, mit separaten End-zu-End-Verbindungen zwischen jedem Endpunkt und dem Server. Zum Beispiel hat jeder Endpunkt seine eigene TCP-Verbindung mit dem C-LAN 204, über welche TCP-KA-Nachrichten ausgetauscht werden. Da die WAN-Verbindung eine begrenzte Kapazität hat, welche für die Rufsignalisierung, Rufdaten, Verwaltungsverkehr gemeinsam genutzt wird, sollte bei einer etwaigen Verdichtung von Verkehr die Verbindung für weitere Anrufe freigegeben werden.
Daher ist der AS 210 bei der vorliegenden Ausführungsform an dem Rufzentralenstandort angeordnet, um als Sammelpunkt für viele Funktionen zu dienen, welche von den IP-Endpunkten auf individueller Basis ausgeführt werden.
Beispiele für diese Funktionen sind nachstehend aufgeführt.

1. Sammeln von herzschlagartigen TCP-KA-Nachrichten zu/von dem C-LAN. Bei gleicher Nutzung der WAN-Verbindung können KA-Nachrichten mit viel höherer Frequenz gesendet/empfangen werden. Dies würde zu einer beträchtlichen Zunahme der Zeit führen, zwischen AS und C-LAN Ausfälle der Verbindungsfähigkeit festzustellen. Da sich der AS an dem gleichen LAN wie die Endpunkte befindet, ist erstens die Wahrscheinlichkeit geringer, dass Fehler auftreten, und zweitens könnten etwaig auftretende Fehler durch Redundanzen maskiert werden.
2. Sammeln von RAS-KA-Nachrichten zu/von dem MV-Server. Analog würde eine Sammlung von RAS-KA-Nachrichten zu/von dem MV-Server einen Austausch mit höherer Frequenz ermöglichen. Noch wichtiger ist, dass sie eine Reduzierung der CPU-Last an dem MV-Server ermöglicht. Ohne Aggregation ist für G3rs diese Überlastung so beträchtlich, dass die RAS-Auszeit in der Größenordnung von Minuten liegt. Obgleich der CPU-Overhead für RAS-KA-Nachrichten auf der Plattform S8700 geringer ist, ist dennoch durch Aggregation ein Vorteil gegeben.
3. Staffelung von Fehlerbenachrichtigungen zu den Endpunkten. Mit dieser Funktion soll der Effekt der lokalen Verzögerungszeit an den Endpunkten erzielt werden. Wie in dem Zeitablaufdiagramm aus 7 gezeigt ist, wird, anstatt dass die Endpunkte nach der Fehlererkennung freiwillig warten, die Erkennung selbst gestaffelt.

Anders ausgedrückt wird, anstatt dass die Fehlererkennung an den Endpunkten stattfindet, dadurch, dass die TCP-KA-Nachrichten gesammelt werden, die Erkennung zuerst an dem AS erfolgen. Es ist dann möglich, die Endpunkte nicht sofort von dem Fehler zu benachrichtigen, auf welche Benachrichtigung hin diese die neue Registrierungsprozedur starten werden. Vielmehr kann der AS die Benachrichtigungen zu jedem Endpunkt zeitlich staffeln, sodass eine GRQ-Flut vermieden wird.

4. Registrierungs-Ratensteuerung und -Aggregation. Der AS kann auch als Registrierungs-Proxy für alle Endpunkte, die lokal an seinem Standort vorgesehen sind, dienen. Dies könnte z. B. in einfacher Weise erreicht werden, indem die IP-Adresse des AS als erste Adresse in eine Liste mit einer oder mehreren Serveradressen gesetzt wird, die zu dem Endpunkt gesendet wird oder manuell an dem Endpunkt konfiguriert wird, oder durch Nutzung des DHCP-Protokolls. Ein solches Merkmal kann erforderlich machen, dass der AS einen Teil des H.323-Stapels aufweist. Zumindest wird NAT-/PAT-Fähigkeit benötigt, wenn der AS als Durchgangs-Proxy dienen soll, der nur auf Schicht 3 agiert.

Nachstehend sind Beispiele für vorteilhafte Merkmale angegeben, welche in dem System bereitgestellt werden können, falls der AS derart implementiert wird, dass er als Proxy dient.

1. Da die GRQs nun für den AS bestimmt sind, wird eine Flut nur über das LAN zu dem AS auftreten. Der AS kann Ratensteuerungsmechanismen anwenden, um die Rate der zu dem MV-Server durchlaufenden GRQs zu regulieren. Wie in dem Diagramm aus 6 gezeigt ist, könnte die Ratensteuerung basierend auf einem Token-Bucket-Schema erfolgen, bei welchem die Tokens auf Basis der Raten der RCF- und GCG-Nachrichten von dem MV-Server zu den Endpunkten generiert werden.
2. Der AS kann mehrere GRQs zu einem einzigen Paket zusammenfassen, das an den MV-Server gesendet wird. Obgleich dies zur Einsparung von Netzressourcen führt, wird das Protokoll zwischen dem AS und dem Server dadurch vom Standard abweichen. Ein Ansatz, bei welchem diese GRQ-Aggregation nur erfolgt, wenn für den Fehler bekannt ist, dass es sich um einen katastrophalen Fehler oder Totalausfall handelt, kann ebenfalls vorteilhaft sein.
3. Wenn der AS aus Sicht der IP-Endpunkte als der Server betrachtet wird, ist es wahrscheinlich, dass auch die RTP-Ströme durch den AS laufen werden. Bei einem Rufzentralen-Szenario werden mehrere solcher Ströme durch den AS hindurch und zu dem abgesetzten MV-Server laufen. Vom Standpunkt der Bandbreitenutzung her wäre eine Komprimierung und Sammlung von RTP-Paketen zu größeren Paketen an dem AS und danach eine Dekomprimierung und Entpackung an dem Server vorteilhaft.

Die Komplexität eines gegebenen Soll-Rufabwicklungssystems kann es schwierig machen, dessen Verhalten im Einzelnen zu verstehen, wenn eine große Anzahl von Endpunkten sich gleichzeitig registrieren. Um dieses Verhalten besser zu verstehen, haben wir einen ereignisbasierten Simulator genutzt, um eine Reihe von Simulationen auszuführen, wie sie nachstehend beschrieben sind.
Die Simulation umfasst die Endpunkte, LANs, das WAN, das C-LAN, den MV-Server, den DHCP-Server und den TFTP-Server. Jedes Element weist bestimmte einstellbare Parameter auf (etwa den Zeitbetrag, der benötigt wird, um einen jeweiligen bestimmten Nachrichtentyp zu verarbeiten). Die Elemente unterhalten auch Zustandsinformationen, die benötigt werden, um Protokolle wie etwa DHCP, TFTP, H323 RAS usw. abzuarbeiten.
Der Simulator war in der Lage, das Verhalten eines Systems mit den vorgeschlagenen Verbesserungen vorherzusagen. Beispielsweise wurde der Ansatz der lokalen stochastischen Verzögerungszeit zu dem Simulator hinzugefügt, ohne dass das Merkmal an tatsächlichen Endpunkten implementiert zu werden brauchte.
Es sei angemerkt, dass das Vorhandensein bestimmter abgeschätzter Parameter, beispielsweise der Nachrichtenverarbeitungszeiten, eine Einschränkung hinsichtlich der Genauigkeit des Simulators darstellt.
Eine spezielle Frage, die wir beantworten wollten, war, wie stark das Verfahren der lokalen zufallsmäßigen Verzögerungszeit die Wiederherstellungszeit verbessern würde. Um dies zu quantifizieren, variierte der Simulator den Abstand zwischen den Zeitpunkten, zu denen die Endpunkte starteten (als Startrate/Boot-Rate, engl. ”boot-rate”, bezeichnet).
Die Sätze von Simulationstests, bei denen nur die Boot-Rate der Endpunkte variiert wurde, wurden in Durchläufe gruppiert. Bei jedem Durchlauf wurde die Boot-Rate für die Endpunkte bei Raten von 5 ms, 10 ms, 20 ms, 40 ms, 75 ms, 100 ms, 150 ms und 250 ms bewertet. Da einer der Hauptvorteile der Verzögerungszeit-Lösung darin besteht, dass der MV-Prozess weniger Zeit zur Verarbeitung von RIP-Nachrichten benötigt, sollte die Verarbeitungszeit für RIP-Nachrichten ein Faktor für die Effizienz der Strategie sein. Die RIP-Nachrichten-Verarbeitungszeit wurde bei 2,5 ms, 5 ms und 15 ms bewertet.
Da der Lösungsansatz der Ratenbegrenzung ein ähnliches Problem lösen würde, wurden die Durchläufe mit Rate-Limitierung wiederholt, die unter Verwendung von Beispielraten simuliert wurde. In ähnlicher Weise hatten wir die Erwartung, dass die Verzögerungszeit sinnvoller ist, wenn ein hoher Paketverlust zwischen den Endpunkten und dem Server auftritt, da die RIP-Nachrichten verloren gehen könnten. Um diese Hypothese zu untersuchen, wurden die Durchläufe mit einer Paketverlust-Wahrscheinlichkeit von 5% wiederholt.
Als nächstes wurden dann die Daten untersucht, um die Zeit für die Registrierung aller Endpunkte mit der Zeit zum Registrieren von 90% und 95% der Endpunkte zu vergleichen, um zu sehen, ob die letzten wenigen Registrierungen wesentlich sind. Danach wurden die Experimente mit 2000 Endpunkten wiederholt, um zu sehen, wie die Anzahl der sich registrierenden Endpunkte die Registrierungszeit beeinflusst. Schließlich wurden die Experimente so wiederholt, dass die Endpunkte zu zufälligen (unabhängig voneinander gewählten) Zeitpunkten anstatt an festgelegten Zeitpunkten (mit konstantem Abstand zwischen diesen) mit der Registrierung begannen.
Die Simulationsergebnisse können auf mehrerlei Weise graphisch dargestellt werden. In 8 ist beispielsweise die Anzahl der registrierten Endpunkte (auf der vertikalen Achse) in Abhängigkeit von der Zeit (auf der horizontalen Achse) graphisch dargestellt. Jede Kurve repräsentiert eine andere Boot-Rate. In 9 sind z. B. die simulierten Ergebnisse graphisch derart dargestellt, dass der Zeitbetrag, der zur Registrierung der Endpunkte erforderlich ist (auf der vertikalen Achse), in Abhängigkeit von der in Millisekunden angegebenen Boot-Rate (auf der horizontale Achse) gezeigt ist. Datenpunkte für unterschiedliche Boot-Raten im gleichen Durchlauf sind verbunden.
8 zeigt die Gesamtanzahl der registrierten Endpunkte in Funktion der Zeit für verschiedene Boot-Raten. Man beachte, dass die erste Registrierung erst nach 30 Sekunden erfolgt, da der Simulator den Boot-Prozess an den IP-Endpunkten einschließt (obgleich für diese Experimente die Endpunkte derart konfiguriert waren, dass der DHCP- und der TFTP-Server umgangen wurden). Die RIP-Nachrichten-Verarbeitungszeit wurde für diesen Graph auf 10 ms festgelegt. Allgemein nimmt die zur Registrierung der Endpunkte erforderliche Zeit mit abnehmender Boot-Rate ab, bis sie einen optimalen Wert (nahe 150 ms) überschreitet. Jenseits des optimalen Werts war der Server frei, während er darauf wartete, dass die Endpunkte sich zu registrieren versuchen.
Für die langsamste Boot-Rate ist die Kurve eben, weil der Server immer frei war, um die nächste Anforderung zu verarbeiten. Die zweitniedrigste Boot-Rate (150 ms) war geringfügig schneller als die optimale Rate. Bei einigen wenigen Anforderungen war ein Wiederholversuch notwendig, wodurch sich ein Wendepunkt für die letzten etwa 40 Endpunkte ergibt. Die Kurven für die schnellsten Boot-Raten weisen einen Wendepunkt für die etwa 40 Sekunden, bevor sich die ersten paar Endpunkte registrierten, auf. Dies legt nahe, dass der Server vollständig überhäuft war, bis nach der RIP-Nachrichten-Abarbeitung die Abstände der Anforderungen vergrößert wurden. Zum Beispiel ist es wahrscheinlich, dass die GRQ-Nachrichten aufgrund der limitierten Länge der Eingangswarteschlange an dem Server fallengelassen wurden.
Für die schnellste Boot-Rate (5 ms) brauchten die Endpunkte 338 Sekunden für die Registrierung, was etwas besser ist als die 360 Sekunden, die für die nächstschnellste Boot-Rate (10 ms) erforderlich waren. Dieser Effekt ist in anderen Experimenten beobachtet worden. Bei der extrem kurzen Boot-Rate ist es wahrscheinlich, dass viele Anforderungen, die ansonsten den Server zwingen würden, eine RIP-Nachrichten-Antwort abzuarbeiten, an der Eingangswarteschlange des Servers fallengelassen werden.
Beim schlechtesten Fall (10 ms Boot-Rate) benötigten die Endpunkte 360 Sekunden für die Registrierung. Im besten Fall (150 ms) waren nur 247 Sekunden erforderlich. Setzt man die Rate für die lokale stochastische Verzögerungszeit auf 150 Sekunden fest, so könnte die für den schlechtesten Fall erforderliche Registrierungszeit um 113 Sekunden reduziert werden. Gemessen von dem Zeitpunkt an, zu dem der erste Endpunkt den Boot-Prozess abgeschlossen hat (d. h. unter Ignorierung der 25 Sekunden Bootzeit, bevor die erste Registrierungsnachricht gesendet wurde), verbesserte sich die Registrierungszeit mit dem Verzögerungszeit-Ansatz um mehr als 1/3.
9 zeigt die Auswirkung der Rate-Limitierung an dem WAN-Router. Die Rate-Limitierung war nur in bestimmten Situationen effektiv. Bei einer Boot-Rate von 40 ms und einer RIP-Nachrichten-Verarbeitunszeit von 15 ms, beispielsweise, verbessert eine Rate-Limitierung das Leistungsverhalten um 2,5% (von 401 auf 391 Sekunden). Bei den meisten anderen Szenarien hatte die Rate-Limitierung keine merkliche Auswirkung auf das Leistungsverhalten oder führte zu einer geringfügigen Verschlechterung.
10 zeigt die Auswirkung eines zufallsmäßigen Paketverlusts von 5%. Wie erwartet erhöhte sich die zum Abschluss des Registrierungsprozesses benötigte Zeit bei einem hohen Grad an Paketverlust, weil nützliche Pakete fallengelassen wurden. Möglicherweise überraschend ist, wie elastisch das System gegenüber einem Paketverlust war. Man beachte, dass die Kombination aus Paketverlust und Rate-Limitierung oft ein schlechteres Verhalten als ein Paketverlust allein ergab. In jedem Fall war die lokale Verzögerungszeit immer noch effektiv hinsichtlich der Reduzierung der Registrierungsabschlusszeit im Vergleich zum bestgelegenen Fall.
Die meisten Durchlaufe in 8 zeigen einen Kurvenschwanz-Effekt, bei dem die letzten paar Endpunkte länger für die Registrierung benötigen als im durchschnittlichen Fall. Dies ist ein Nebeneffekt der Verzögerungszeit-Verfahren und Endpunkt-Prozeduren, welche es erforderlich machen können, dass der Endpunkt eine Verzögerungszeit einführt oder einen Neustart ausführt, wenn er nicht in der Lage ist, sich zu registrieren.
Die beste Lösung für die beispielhafte Ausführungsform ist wahrscheinlich eine solche, bei welcher der größte Teil der Endpunkte schnell registriert wird. Diese unterscheidet sich geringfügig von der Zeit, die zur Registrierung aller Endpunkte erforderlich ist, welche die ist, die durch die Ergebnisse gemessen wird. Um zu sehen, ob die zur Registrierung der letzten wenigen Telefone erforderliche Zeit wesentlich ist, zeigt 11 die Zeit zur Registrierung von 100%, 95% und 90% von 2000 Endpunkten mit drei RIP-Nachrichten-Verarbeitungszeiten.
Der Unterschied zwischen den Kurvenverläufen ist gering. Ein gewisser Schräglauf ist zwischen den Boot-Raten 2,5 und 5 ms zu erkennen. Dies legt nahe, dass der Kurvenschwanz-Effekt bei extrem schnellen Bootzeiten eine geringfügige Rolle spielt, aber klein genug ist, dass es sinnvoll ist, die für einen 100%igen Abschluss erforderliche Zeit in der Analyse zu verwenden.
Ein weiterer Satz von Durchlaufen wurde simuliert, um den Effekt einer Verdopplung der Anzahl der Endpunkte, die sich zu registrieren versuchen, auf 2000 zu zeigen. Diese Ergebnisse sind in 11 gezeigt. Bei einer RIP-Nachrichten-Verarbeitungszeit von 15 ms war die Wirkung einer lokalen Verzögerungszeit beträchtlich. Eine mittlere Verzögerungszeit von 250 ms war um etwa 40% effizienter als für 10 ms. Die optimale Boot-Rate lag zwischen 150 ms und 250 ms. Bei einer Verzögerungszeit von 175 ms (in der Figur nicht gezeigt) ist die Registrierung in 462 Sekunden abgeschlossen, beinahe der halben Zeit. Für kürzere RIP-Nachrichten-Verarbeitungszeiten kann sich durch die lokale Verzögerungszeit die Registrierungszeit verbessern, aber nicht so deutlich wie bei den größeren RIP-Nachrichten-Verarbeitungszeiten.
Für die Daten in den vorstehend beschriebenen Ergebnissen wurde angenommen, dass der Abstand zwischen den Anfangsanforderungen der Registrierung gleichmäßig verteilt ist. Das heißt, bei einer Boot-Rate von 5 ms senden die Endpunkte Registrierungsnachrichten zu den Zeitpunkten 0,5 ms, 10 ms, ..., 995 ms. Dies ist möglicherweise für ein praktisches System nicht realistisch, da die Endpunkte mehr oder weniger unabhängig voneinander beginnen. Um das stochastische Wesen des Verfahrens mit lokalen zufälligen Verzögerungszeiten zu erfassen, wurde das Experiment aus 8 wiederholt, wobei die Telefone unabhängig voneinander zufallsmäßige Verzögerungszeiten wählten. Die neuen Resultate sind in 12 gezeigt. Die beiden graphischen Darstellungen sind nahezu identisch, bis auf die Welligkeit in letzterer und eine geringfügige Verbesserung für die Fälle mit hohen Boot-Raten. Dies legt nahe, dass es sinnvoll war, einen festen Abstand zwischen den Registrierungszeitpunkten anstatt eines zufallsmäßigen Abstands zu simulieren. Die Verwendung eines fixen Abstands hatte den Vorteil, dass die Ergebnisse wiederholbar waren (außer wenn ein zufallsmäßiger Paketverlust genutzt wurde).
Es sollte unterstrichen werden, dass die speziellen Anordnungen, die bei den vorstehenden Simulationen genutzt wurden, lediglich Beispiele darstellen und nicht als Erfordernisse der Erfindung betrachtet werden sollten.
Bei alternativen Ausführungsformen der Erfindung können die beschriebenen Verfahren auf andere Systeme als solche, die verteilte Rufzentralenstandorte umfassen, angewendet werden. Beispielsweise könnten die erfindungsgemäßen Verfahren auf ein System mit einem einzigen Standort angewendet werden.
Die vorstehend beschriebenen Ausführungsformen der Erfindung sind lediglich zur Veranschaulichung gedacht. Zum Beispiel sollte angemerkt werden, dass die in 1 gezeigte exemplarische Systemkonfiguration in solcher Weise geändert werden kann, dass sie eine breite Vielfalt unterschiedlicher Anordnungen von Komponenten umfasst, um die vorliegend beschriebenen Verarbeitungsfunktionen bereitzustellen. Eine dieser alternativen Anordnungen kann derart konfiguriert sein, dass die beschriebenen Verfahren zumindest zum Teil in einem so genannten ”Off-Board”-Server implementiert werden, z. B. einem außerhalb einer System-Vermittlungseinrichtung vorgesehenen Server. Bei dieser Art von Anordnung steuern ein oder mehrere Server die Verteilung der Arbeit auf Agenten in einem Unternehmen in solcher Weise, dass die Verarbeitungsfunktionen, die mit der Verteilung in Verbindung stehen, insgesamt oder zum Teil von der Vermittlungseinrichtung auf die Server übertragen werden können. Der Begriff ”Rufzentrale”, wie er vorliegend genutzt wird, soll diese und andere alternative Systeme einschließen, in welchen die vorliegende Erfindung implementiert werden kann.
Der vorstehend beschriebene Ansatz der lokalen zufallsmäßigen Verzögerungszeit kann unter Verwendung anderer Arten einer lokalen Verzögerungszeit implementiert werden, z. B. einer Verzögerungszeit, die nicht notwendigerweise zufällig ist, sondern stattdessen pseudozufällig ist oder einem bestimmten vorgegebenen Muster folgt.
Außerdem stellt der vorstehend beschriebene AS lediglich ein Beispiel für eine Art von Proxy dar, der genutzt werden kann, um die zugehörige Funktionalität bereitzustellen, und es können andere Arten von Proxys, die auf anderen Verfahren als dem beschriebenen Token-Bucket-Verfahren beruhen, verwendet werden.
Es sei außerdem angemerkt, dass die Erfindung zumindest teilweise in Form eines computerlesbaren Mediums oder eines anderen ähnlichen Mediums ausgeführt werden kann, welches Software enthält, die, wenn sie von einem Computer oder einer anderen Art von Prozessor ausgeführt wird, bewirken wird, dass der Prozessor die vorstehend beschriebenen Verarbeitungsfunktionen implementiert. Solche Softwareprogramme können z. B. in dem Speicher 115 oder einem beliebigen anderen computerlesbaren Medium gespeichert werden, das dem System 10 zugeordnet ist, und können von dem Prozessor 116 oder einer anderen dem System 10 zugeordneten Verarbeitungshardware ausgeführt werden. Diese und zahlreiche andere alternative Ausführungsformen, die in den Schutzumfang der folgenden Ansprüche fallen, werden für Fachleute auf dem Gebiet offensichtlich sein.

Claims

Verfahren umfassend: (A) Empfangen einer Angabe einer Dauer M_opt an einem Endpunkt, wobei: i. die Angabe der Dauer M_opt während einer ersten Registrierung des Endpunkts bei einem Rufabwicklungssystem empfangen wird, und ii. infolge der ersten Registrierung eine Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem hergestellt wird; und (B) in Ansprechen auf eine Erkennung eines Fehlers der Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem, eine Nachricht von dem Endpunkt übertragen wird, wobei: i. die Nachricht als Teil einer zweiten Registrierung des Endpunkts bei dem Rufabwicklungssystem übertragen wird, ii. die Nachricht nach Ablauf einer Verzögerungsdauer seit der Erkennung des Fehlers übertragen wird, iii. die Verzögerungsdauer eine Dauer D aufweist, iv. D von dem Endpunkt zufällig ausgewählt ist, v. D kleiner oder gleich M_opt ist.
Verfahren nach Anspruch 1, wobei die Angabe von M_opt durch einen Server übertragen wird; und der Server Teil des Rufabwicklungssystem ist.
Verfahren nach Anspruch 1, wobei der Endpunkt ein Internetprotokoll(IP)-Endpunkt ist.
Verfahren nach Anspruch 1, wobei die Nachricht eine Benutzer-Datagramm-Protokoll(UDP)-Nachricht ist.
Verfahren nach Anspruch 1, wobei die zweite Registrierung des Endpunkts bei dem Rufabwicklungssystem umfasst: Senden einer GRQ-Nachricht, Empfangen einer GCF-Nachricht, Senden einer RRQ-Nachricht und Empfangen einer RCF-Nachricht.
Verfahren nach Anspruch 1, wobei: die Nachricht von dem Endpunkt an einen Server übertragen wird; und das Rufabwicklungssystem ferner einen Router umfasst, der zwischen dem Endpunkt und dem Server gekoppelt ist, wobei der Router wirksam ist, eine Rate zu begrenzen, mit welcher Nachrichten von dem Endpunkt an den Server ausgeliefert werden.
Verfahren nach Anspruch 6, wobei die Nachrichten GRQ-Nachrichten umfassen.
Verfahren nach Anspruch 1, wobei: die Nachricht von dem Endpunkt an einen Server übertragen wird; und der erste Server, wenn er nicht in der Lage ist, eine spezifische Nachricht der Sequenz für den gegebenen Endpunkt zu verarbeiten, weil er bereits einen Registrierungsprozess für eine maximale Anzahl von Endpunkten abwickelt, derart arbeitet, dass er an den gegebenen Endpunkt eine Nachricht sendet, welche angibt, dass eine andere Registrierung im Gange ist, sowie anfordert, dass der gegebene Endpunkt nach einem bestimmten Intervall seinen Registrierungsversuch wiederholt.
Verfahren nach Anspruch 1, wobei die Angabe von M_opt von einer Anzahl von Endpunkten abhängig ist, die bei dem Rufabwicklungssystem registriert sind.
Verfahren nach Anspruch 1, wobei die Angabe der Dauer M_opt von der Kapazität einer Zentraleinheit (CPU) des Rufabwicklungssystems abhängig ist.
System umfassend: einen Server, der Teil eines Rufabwicklungssystem ist; und ein Endpunkt zum: (A) Empfangen einer Angabe einer Dauer M_opt, wobei: i. die Angabe der Dauer M_opt von dem Server während einer ersten Registrierung des Endpunkts bei einem Rufabwicklungssystem empfangen wird, und ii. infolge der ersten Registrierung eine Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem hergestellt wird; und (B) in Ansprechen auf eine Erkennung eines Fehlers der Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem eine Nachricht von dem Endpunkt übertragen wird, wobei: i. die Nachricht als Teil einer zweiten Registrierung des Endpunkts bei dem Rufabwicklungssystem übertragen wird, ii. die Nachricht nach Ablauf einer Verzögerungsdauer seit der Erkennung des Fehlers übertragen wird, iii. die Verzögerungsdauer eine Dauer D aufweist, iv. D von dem Endpunkt zufällig ausgewählt ist, und v. D kleiner oder gleich M_opt ist.
System nach Anspruch 11, wobei der Endpunkt ein Internetprotokoll(IP)-Endpunkt ist.
System nach Anspruch 11, wobei die die Nachricht eine Benutzer-Datagramm-Protokoll(UDP)-Nachricht ist.
System nach Anspruch 11, wobei die zweite Registrierung des Endpunkts mit dem Rufabwicklungssystem umfasst: Senden einer GRQ-Nachricht, Empfangen einer GCF-Nachricht, Senden einer RRQ-Nachricht und Empfangen einer RCF-Nachricht.
System nach Anspruch 11 umfassend einen Router, wobei der Router eine Rate begrenzt, mit welcher Nachrichten vom Endpunkt zu dem Server ausgeliefert werden.
System nach Anspruch 14, wobei die Nachrichten GRQ-Nachricht umfassen.
System nach Anspruch 11, wobei der Server, wenn er nicht in der Lage ist, eine spezifische Nachricht der Sequenz für den gegebenen Endpunkt zu verarbeiten, weil er bereits einen Registrierungsprozess für eine maximale Anzahl von Endpunkten abwickelt, derart arbeitet, dass er an den gegebenen Endpunkt eine Nachricht sendet, welche angibt, dass eine andere Registrierung im Gange ist, sowie anfordert, dass der gegebene Endpunkt nach einem bestimmten Intervall seinen Registrierungsversuch wiederholt.
System nach Anspruch 11, wobei die Angabe von M_opt von einer Anzahl von Endpunkten abhängig ist, die bei dem Rufabwicklungssystem registriert sind.
System nach Anspruch 11, wobei die Angabe von M_opt von der Kapazität einer Zentraleinheit (CPU) des Rufabwicklungssystem abhängig ist.
Vorrichtung umfassend: Mittel zum Empfangen einer Angabe einer Dauer M_opt an einem Endpunkt, wobei: i. die Angabe der Dauer M_opt während einer ersten Registrierung des Endpunkts bei einem Rufabwicklungssystem empfangen wird, und ii. infolge der ersten Registrierung eine Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem hergestellt wird; und Mittel zur Übertragung einer Nachricht von dem Endpunkt, in Ansprechen auf eine Erkennung eines Fehlers der Verbindung zwischen dem Endpunkt und dem Rufabwicklungssystem, wobei: i. die Nachricht als Teil einer zweiten Registrierung des Endpunkts mit dem Rufabwicklungssystem übertragen wird, ii. die Nachricht nach Ablauf einer Verzögerungsdauer nach der Erkennung des Fehlers übertragen wird, iii. die Verzögerungsdauer die Dauer D aufweist, iv. D von dem Endpunkt zufällig ausgewählt ist, und v. D kleiner oder gleich M_opt ist.