-
Auf der ganzen Welt möchten Organisationen
steigende Kommunikationskosten senken. Die Konsolidierung von separaten
Sprach- und Datennetzwerken bietet eine Gelegenheit für beträchtliche
Einsparungen. Dementsprechend wird die Herausforderung eines Integrierens
von Sprach- und Datennetzwerken für viele Netzwerkverwalter immer
mehr zur Priorität.
Organisationen verfolgen Lösungen,
die sie befähigen, überschüssige Kapazitäten bezüglich Breitbandnetzen
für eine
Sprach- und Datenübertragung
zu nutzen sowie das Internet und firmeninterne Intranetze als Alternativen
zu kostspieligeren Medien zu nutzen.
-
Allgemein sind schaltungsbasierte
Anrufe derzeit von höherer
Qualität
als paketbasierte. Es besteht ein Anreiz, diesen Mangel dadurch
zu berichtigen, daß man
Netzwerke schafft, bei denen die Qualität von VoP-Anrufen (VoP = voice
over packet, Sprache über
Paket) dieselbe ist wie die von schaltungsbasierten Kommunikationen,
oder besser ist als jene. Um dieses Ziel zu erreichen, ist es wünschenswert,
in der Lage zu sein, eine Sprachqualität für Anrufe in einem VoP-Netzwerk
zu messen und diejenigen Netzwerkbedingungen, die bewirken, daß ein VoP-Anruf
eine unter dem Standard liegende Qualität aufweist, zu identifizieren.
Da viele Anrufe über
ein VoP-Netzwerk übertragen
werden, besteht ein Bedarf, Sprachqualität in vielen Anrufen zu messen,
um die Zulänglichkeit
des Dienstes bezüglich
seiner beabsichtigten Anwendung zu beurteilen. Bekannte Meßlösungen von
VoP-Netzwerken haben Schwierigkeiten, alle Anrufe gleichzeitig zu
erfassen und zu messen, da derzeitige Netzwerke einer hohen Bandbreite
in der Lage sind, mehr Daten zu übertragen
als durch Meßnetzwerkprozessoren
analysiert werden können.
-
Ein bekanntes Testverfahren umfaßt einen
aktiven Test, bei dem ein „Testanruf" auf einer Netzwerkverknüpfung eingerichtet
wird und bekannte Daten übertragen
werden. Dieses Testverfahren weist jedoch nachteilhafterweise das
Erfordernis auf, daß jegliches
Problem in dem Netzwerk rekonstruiert werden muß, bevor es diagnostiziert
werden kann.
-
Demgemäß besteht ein Bedarf an einem
passiven Testverfahren, bei dem Messungen eines funktionstüchtigen
Netzwerks durch Abhören
durchgeführt
werden können.
Bei Netzwerken einer niedrigen Bandbreite ist es möglich, alle
Anrufe zu erfassen und zu analysieren. Es besteht jedoch weiterhin
ein Erfordernis einer passiven Messung eines VoP-Netzwerks einer
hohen Bandbreite.
-
Es ist die Aufgabe der vorliegenden
Erfindung, ein Verfahren und eine Vorrichtung zu schaffen, die bei Netzwerken
mit hoher Bandbreite eine zuverlässige
Messung der Sprachübertragung
ermöglichen.
-
Diese Aufgabe wird durch Verfahren
gemäß den Ansprüchen 1,
16 und 25 sowie durch eine Vorrichtung gemäß Anspruch 20 gelöst.
-
Ein Verfahren zum Messen eines Voice-Over-Paket-Netzwerks
(VoP-Netzwerks) umfaßt
folgende Schritte: Erfassen und Identifizieren zumindest eines Pakets
in einem Netzwerk als ein VoP-Signalisierungspaket und Bestimmen
eines interessierenden Anrufs auf der Basis von Informationen, die
in zumindest einem Signalisierungspaket enthalten sind. Das Verfahren
fährt mit
folgenden Schritten fort: Erfassen und Identifizieren zumindest
eines zusätzlichen
Pakets als ein VoP-Datenpaket und Analysieren des VoP-Datenpakets
nur dann, wenn das VoP-Datenpaket dem interessierenden Anruf entspricht.
-
Gemäß einem weiteren Aspekt eines
Ausführungsbeispiels
umfaßt
ein Verfahren zum Messen einer Sprachqualität in einem Voice-Over-Paket-Netzwerk
folgende Schritte: Annehmen eines Datenpakets, das einem Anruf entspricht,
und Vergleichen eines Beschreibungselements des Datenpakets mit
einer Auslösebedingung.
Falls die Auslösebedingung
für das
Datenpaket existiert, umfaßt
das Verfahren ferner folgende Schritte: Sammeln des Datenpakets
zu einer Flußinformationsaufzeichnung,
Berechnen einer Statistik aus der gesammelten Flußinformationsaufzeichnung,
und Speichern der Statistik.
-
Eine Vorrichtung zum Messen eines
Voice-Over-Paket-Netzwerks
weist folgende Merkmale auf: eine Filtermaschine, die Pakete in
einem Netzwerk annimmt und jedes Paket als einen Pakettyp in einer
Gruppe, die aus einem VoP-Signalisierungspaket,
einem VoP-Datenpaket und anderen Paketen besteht, identifiziert. Die
Vorrichtung weist ferner einen Anrufsignalisierungsanalysator auf,
der die Signalisierungspakete annimmt und eine Anrufflußaufzeichnung
für einen
aktiven Anruf erzeugt. Ein Auslöseranalysator
nimmt Parameter an, um einen interessierenden Anruf an die Filtermaschine
zu definieren, und eine Flußmaschine
nimmt VoP-Datenpakete von der Filtermaschine an. Die Vorrichtung
weist ferner eine Flußanwendung
auf, die die VoP-Pakete
analysiert.
-
Ein Verfahren zum Messen eines Voice-Over-Paket-Netzwerks,
das folgende Schritte aufweist: Einrichten von Auslösern, die
Charakteristika eines oder mehrerer interessierender Anrufe definieren,
und Erfassen von Datenpaketen für
den einen oder die mehreren interessierenden Anrufe. Das Verfahren
fährt mit
folgenden Schritten fort: Sammeln von Informationen auf der Basis
der Datenpakete, Berechnen einer Statistik auf der Basis der gesammelten
Informationen, und Speichern der Statistik.
-
Vorteilhafterweise ermöglichen
bestimmte Ausführungsbeispiele
eines Testsystems gemäß den vorliegenden
Lehren eine Echtzeitanalyse von Voice-Over-Paket-Netzwerken einer
hohen Bandbreite.
-
Bevorzugte Ausführungsbeispiele der vorliegenden
Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden
Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
vereinfachtes Blockdiagramm eines veranschaulichenden Netzwerks
mit Voice-Over-Paket-Daten;
-
2 ein
Blockdiagramm eines Ausführungsbeispiels
eines Meßsystems
gemäß den Lehren
der vorliegenden Erfindung;
-
3 ein
Datenflußdiagramm
eines Ausführungsbeispiels
eines Verfahrens gemäß den Lehren
der vorliegenden Erfindung;
-
4 ein
Flußdiagramm
eines Ausführungsbeispiels
einer Filtermaschine gemäß den Lehren
der vorliegenden Erfindung;
-
5 ein
Flußdiagramm
eines Ausführungsbeispiels
eines Anrufsignalisierungsanalysators gemäß den Lehren der vorliegenden
Erfindung;
-
6 ein
Flußdiagramm
eines Ausführungsbeispiels
einer Anrufflußaufzeichnungslogik
gemäß den Lehren
der vorliegenden Erfindung;
-
7 ein
Flußdiagramm
eines Ausführungsbeispiels
einer Flußmaschine
gemäß den Lehren
der vorliegenden Erfindung; und
-
8 ein
Datenflußdiagramm
eines alternativen Ausführungsbeispiels
eines Systems gemäß den vorliegenden
Lehren.
-
Ein passiver Test eines VoP-Netzwerks
einer hohen Bandbreite umfaßt
ein Verfahren, bei dem lediglich ein Teilsatz aller VoP-Anrufe in
einem Netzwerk analysiert wird, um die Zulänglichkeit einer VoP-Verknüpfung zu
bewerten. Der Teilsatz von VoP-Anrufen wird als die „interessierenden
Anrufe" bezeichnet
und ist von allen anderen Anrufen und Daten, die in dem Netz übertragen
werden, isoliert. Beispiele von interessierenden Anrufen, die von
den anderen Anrufen in dem Netzwerk isoliert sind, umfassen folgende,
sind aber nicht auf diese beschränkt:
Anrufe, die Fehler oder eine abnormale Trennung aufweisen, Anrufe,
die einen spezifischen Codierer/Decodierer verwenden, Anrufe, die
einen spezifischen Pfad, Router oder spezifische Medien verwenden,
Anrufe, die an einem spezifischen Endpunkt oder bei einem spezifischen
Anrufer entstehen oder enden, Anrufe, die Konferenzanrufe implementieren,
sowie Anrufe, die einen Fernanrufdienst verwenden.
-
Unter spezifischer Bezugnahme auf 1 der Zeichnungen ist ein
vereinfachtes Blockdiagramm eines veranschaulichenden VoP-Netzwerks
gezeigt, bei dem ein erster Mediennetzübergang 1 einen Konversatiosverkehr
von einem oder mehreren Telefonen 2, 3 und vielleicht
einer oder mehreren elektronischen Vorrichtungen, z. B. einem Computer 4,
annimmt. Der erste Mediennetzübergang
nimmt den Konversationsverkehr an und codiert unter Verwendung eines
oder mehrerer Signalisierungs- und Daten-VoP-Protokollpakete jede Konversation
zu einem VoP-Anruf. Die codierten Pakete aller Anrufe und Daten
werden in ein VoP-Netzwerk 5 eingespeist. Bei dem gezeigten
spezifischen Ausführungsbeispiel
ist das VoP-Netzwerk 5 eine 100BaseT-Ethernet-Netzwerkverknüpfung. Eine
gegenüberliegende
Seite des VoP-Netzwerks 5 weist
einen zweiten Mediennetzübergang 6 auf, der
die codierten Pakete empfängt
und sie an ihre jeweiligen Bestimmungsorte weiterleitet.
-
Unter spezifischer Bezugnahme auf 2 der Zeichnungen ist ein
Blockdiagramm eines Hardwaresystems zur Implementierung der vorliegenden
Lehren gezeigt, bei dem ein im Test befindliches Netzwerk 102 VoP-Anrufe
zur Analyse durch das veranschaulichte System führen kann. Die Anrufe können mit
einer beliebigen Anzahl von VoP-Protokollen codiert sein, die ohne
Einschränkung
H.323, Mediennetzübergangsteuerprotokoll
(MGCP – media
gateway control protocol) und ein Sitzungseinleitungsprotokoll (SIP – session
initiation protocol) umfassen. Eine Arbeitsstation 104,
die bei einem bevorzugten Ausführungsbeispiel
eine Sun Netra-20 ist, die ein solares Betriebssystem und eine Agilent-Technologies-NgN-Software betreibt,
ist mit einer Netzwerkkarte 105 bestückt, die bei einem bevorzugten
Ausführungsbeispiel
eine Einstecknetzwerkkarte ENP2506 105 von Radisys, Corp.,
ist. Die ENP2506 umfaßt
einen IXP1200-Prozessor mit sechs Mikroprozessormaschinen. Sie betreibt
ein VXWorks-Betriebssystem
von Windriver und eine Tornado-Entwicklungsumgebung.
Vier der Mikroprozessormaschinen in der Netzwerkkarte 105 werden
für einen
Filtermaschinenprozeß verwendet,
und zwei werden für
einen Flußmaschinenprozeß verwendet.
Wie Fachleute angesichts der vorliegenden Lehren erkennen werden,
dient die Zuweisung einer Mikroprozessormaschine zu einem bestimmten Prozeß dem Hauptzweck
eines effizienten Lastausgleichs und Verarbeitens, und sie kann
in Abhängigkeit
einer spezifischen Implementierung der vorliegenden Lehren variieren.
Die Netzwerkkarte 105 überwacht
passiv einen Datenverkehr, der durch das zu testende Netzwerk 102 über die
Testnetzwerkverbindung 108 geführt wird. Die Arbeitsstation 104 kommuniziert
durch einen herkömmlichen
PCI-Bus 107 mit der Netzwerkkarte 105 und kommuniziert
unter Verwendung eines Verwaltungs-LAN 106 mit anderen
Vorrichtungen. Eine externe Kommunikation über das Verwaltungs-LAN 106 dient
Zwecken, die, ohne Einschränkung,
ein Empfangen von Anforderungen von externen Vorrichtungen und ein
Melden gesammelter und berechneter Daten an externe Vorrichtungen
umfassen.
-
Unter spezifischer Bezugnahme auf 3 der Zeichnungen ist ein
Datenflußdiagramm
eines Ausführungsbeispiels
eines Verfahrens gemäß den vorliegenden
Lehren gezeigt, bei dem Netzwerkdaten auf der Testverknüpfung 103 durch
eine Filtermaschine 201 empfangen werden. Die Filtermaschine 201 ist
ein Softwareprozeß,
der auf vier der Mikroprozessormaschinen, die sich auf der Netzwerkkarte 105 befinden,
betrieben wird.
-
Unter spezifischer Bezugnahme auf 4 der Zeichnungen ist ein
Flußdiagramm
des Filtermaschinenprozesses 201 gezeigt. Die Filtermaschine 201 nimmt
ein Datenpaket von der aktiven Testverknüpfung 103 an 301 und
erfaßt
dasselbe. Das Datenpaket ist entweder ein VoP-Signalisierungspaket
oder ein VoP-Datenpaket oder eine andere Art von Paket. Die Filtermaschine 201 bestimmt
anhand einer Serie von Vergleichen 302 mit bekannten Protokollen,
ob das Datenpaket ein VoP-Signalpaket ist, und falls dies der Fall
ist, welcher Typ von Signalprotokoll verwendet wird. Falls einer
der Serie von Vergleichen 302 eine Übereinstimmung mit einem der
unterstützten
Signalisierungsprotokollen ergibt, leitet 303 die Filtermaschine 201 das
VoP-Signalisierungspaket und die Protokolltypinformationen an einen
Anrufsignalisierungsanalysator 202 und beginnt den Filtermaschinenprozeß für das nächste fortlaufende
Paket auf der Testverknüpfung 103.
Falls das Paket nicht als VoP-Signalisierungspaket identifiziert
wird, versucht die Filtermaschine 201, es als VoP-Datenpaket
zu identifizieren 304. VoP-Datenpakete folgen einem Echtzeitprotokoll
und werden herkömmlicherweise
als „RTP-Paket" bezeichnet. Ein
RTP-Paket weist Anfangsblockinformationen auf, die einen Zeitstempel
von dem sendenden Mediennetzübergang,
eine Paketsequenznummer, eine IP-Adresse und eine Tornummer umfassen.
Die IP-Adresse und die Tornummer identifizieren eindeutig den Anruf,
dem das RTP-Paket entspricht. Falls die Filtermaschine das Paket als
RTP-Paket identifiziert, leitet sie das Paket an die Flußmaschine 203 weiter 305 und
beginnt den Filtermaschinenprozeß für das nächste fortlaufende Paket auf
der Testverknüpfung 103.
Falls das Paket weder ein VoP-Signalisierungspaket
noch ein RTP-Paket ist, verwirft die Filtermaschine das Paket ohne
weitere Verarbeitung. Der Filtermaschinenprozeß kehrt dann zum Anfang zurück, um das nächste fortlaufende
Datenpaket anzunehmen und zu verarbeiten.
-
Unter spezifischer Bezugnahme auf 5 der Zeichnungen ist ein
Flußdiagramm
gezeigt, das den Anrufsignalisierungsanalysator 202 veranschaulicht.
Der Anrufsignalisierungsanalysator ist das von Agilent Technologies,
Inc., erhältliche
NgN-Softwareprodukt, das in dem Anrufsignalisierungsanalysator 202 enthalten ist,
wie in der am 16. Oktober 2002 mit der Veröffentlichungsnummer 1249986
veröffentlichten
europäischen Patentanmeldung
und in der am 18. April 2001 unter der Veröffentlichungsnummer 1093312
veröffentlichten europäischen Patentanmeldung,
deren Lehren durch Bezugnahme in das vorliegende Dokument aufgenommen
sind, offenbart ist. Die Filtermaschine leitet bei 303 einen
Strom von VoP-Signalisierungspaketen von dem Anrufsignalisierungsanalysator
weiter. Bei jedem VoP-Paket in dem Strom empfängt die Filtermaschine 201 ferner
einen Signalisierungsprotokollparameter, der das bei dem VoP-Signalisierungspaket
verwendete spezifische Signalisierungsprotokoll angibt. Der Anrufsignalisierungsanalysator 202 nimmt
das VoP-Signalisierungspaket und den Signalisierungsprotokollparameter
bei 401 an. Der Anrufsignalisierungsanalysator 202 bestimmt 402,
ob für
den Anruf, der durch das VoP-Signalisierungspaket dargestellt wird,
bereits eine Anrufflußaufzeichnung
(CFR – call
flow record) existiert. Falls der Anruf neu ist und noch keine CFR
existiert, richtet der Anrufsignalisierungsanalysator eine neue
CFR ein 403. Der Anrufsignalisierungsanalysator extrahiert 404 anschließend Informationen
aus dem VoP-Signalisierungspaket
und bestückt
die CFR mit den extra hierten Informationen. Mehrere VoP-Signalisierungspakete
werden verwendet, um die CFR vollständig zu bestücken. Pro
Anruf auf der Verknüpfung
liegt eine eindeutige CFR vor.
-
Die CFR ist eine Datenstruktur, die
Informationen für
den Anruf speichert, die folgende umfassen:
| Anruferzeugungszeit
(Call Create Time) : | Die
Zeit, zu der die erste Nachricht empfangen wurde. |
| anrufende
Nummer (Calling Number): | Die
Telefonnummer, von der der Anruf ausging. |
| Anruf-ID
(Call ID): | Identifizierer,
der durch die Soft-Umschaltung
dem Anruf zugewiesen wird. |
| Anrufzustand
(Call State): | Verbunden,
getrennt oder in Arbeit. |
| Gewählte Nummer
(Dialed Number) : | Die
Telefonnummer, die angerufen wurde. |
| IP-Adressen
(IP Addresses): | IP-Adressen
aller Elemente, die an einem Anruf beteiligt sind (z. B. Soft-Umschaltung,
Mediennetzübergang
usw.). |
| Protokolle
(Protocols): | Signalisierungsprotokolle,
die bei einem Anruf verwendet werden. |
| Laufzeit
(Running Time) : | Die
Dauer, die der Anruf bereits andauert, falls der Anruf immer noch
fortdauert. |
| Status
(Status): | OK,
Fehler, Wartung oder Warnung. |
| RTP-Pfadinfo
(RTP Path Info) : | IP-Adresse
und UDP-Tore des RTP-Stroms |
| Beantwortet
(Answered): | Ob
der angerufene Teilnehmer den Anruf beantwortete oder nicht. |
| Trägerfähigkeit
(Bearer Capability): | Spezifiziert
einen angeforderten Dienst: Paket- oder Schaltungsmodus, Datenrate,
Art des Informationsgehalts. |
| Blockiert
(Blocked): | Jegliche
Nachricht, die die Blockierungsbedingung einer Schaltung oder einer
Gruppe von Schaltungen beeinflußt,
wird angegeben. Schaltungen können
zu einem beliebigen Zeitpunkt blockiert, nicht blockiert oder zurückgesetzt
werden, und folglich können
einer oder mehrere Anrufe freigegeben werden. Falls ein Wert leer
ist, bedeutet dies, daß in
dieser Anrufaufzeichnung keine Blockierungs- oder Nicht-Blockierungsnachrichten
enthalten waren. |
| CIC: | CIC
des IAM-Abschnitts des Anrufsegments. |
| KOTFehlgeschlagen
(COTFailed): | Falls
an der Schaltung ein Kontinuitätstest
angefordert wurde, bevor der Anruf plaziert wurde, sind in diesem
Feld jegliche Protokolle aufgelistet, die ein Fehlschlagen eines
Kontinuitätstests
angaben. |
| KOTAngefordert
(COTRequested): | In
diesem Feld sind jegliche Protokolle aufgelistet, die eine Anforderung
bezüglich
eines Kontinuitätstests
an der Schaltung ausgaben, bevor der Anruf plaziert wurde. |
| KOTErfolgreich
(COTSuccessful): | Falls
an der Schaltung ein Kontinuitätstest
angefordert wurde, bevor der Anruf plaziert wurde, sind in diesem |
| | Feld
jegliche Protokolle aufgelistet, die einen erfolgreichen Kontinuitätstest angaben. |
| Anrufbeantwortungs-zeitfenster (Call
Answer Time Window): | Der
Zeitpunkt, zu dem der Anruf beantwortet wurde. Falls das Feld leer
ist, wurde der Anruf nicht beantwortet. Anzeige bei SMR-Markierung: HH:MM:SS:mmm |
| Anruferzeugungs-zeit (Call Create
Time): | Zeit,
zu der der Anruf begann. |
| Anrufdauer
(Call Duration): | Die
Dauer (von einer hergestellten Verbindung bis zu einer getrennten
Verbindung) des Anrufs. |
| Anrufaufbauzeit
(Call Setup Time) : | Zeit,
um den Anruf aufzubauen, von IAM bis ANM (nur SS7) . HH:MM:SS:mmm |
| Anrufabbauzeit
(Call Teardown Time) : | Zeit
zum Trennen des Anrufs, von REL bis RLC (nur SS7). Anzeigeformat:
HH:MM:SS:mmm |
| Träger-ID-Code
(Carrier ID Code): | Eine
drei- oder vierstellige Zahl, die den Träger, durch den der Anruf weitergeleitet
wurde, eindeutig identifiziert (nur SS7). |
| Wähltonverzögerung (Dial
Tone Delay): | Zeit
vom Abheben bis zum Empfang des Wähltons. Anzeigeformat: HH:MM:SS:
mmm |
| DPC: | Bestimmungspunktcode
(Destination Point Code), der in dem IAM-Abschnitt des SS7-Protokolls
zu finden ist. |
| GAP: | Das
GAP-Feld (GAP = Generic Address Parameter, generischer Adreßparameter)
von der IAM-Nachricht (nur SS7). Falls es leer ist, wurde die IAM- |
| | Nachricht
nicht gesehen oder enthielt keinen GAP-Parameter. |
| JIP: | Das
sechsstellige JIP-Feld (JIP = Jurisdiction Information Parameter,
Rechtsprechungsinformationsparameter) von der IAM-Nachricht. (Nur
SS7). Fall leer, wurde die IAM-Nachricht nicht gesehen oder enthielt keinen
JIP-Parameter. |
| Lokaler
PC (Punkt-Code)
(Local PC (Point Code)): | Punktcode
der lokalen Schaltstelle oder der Vorrichtung, die den Anruf handhabt
(nur SS7). Falls leer t, bedeutet dies, daß die IAM-Nachricht nicht gesehen wurde. |
| LRN: | Das
10-stellige LRN-Feld (LRN = Local Routing Number, lokale Weiterleitungsnummer)
von der IAM-Nachricht (nur SS7). Falls leer, wurde die IAM-Nachricht nicht gesehen
oder enthielt keinen LRN-Parameter, da eine Lokale-Nummer-Portabilität nicht
verwendet wurde. |
| Wartungsnachrichten
(Maintenance Messages): | Zeigt
Wartungsnachrichten an, z. B. GRS, GRA usw. |
| Ursprungsantwortverzögerung (Originating
Answer Delay): | Die
Zeit, die benötigt
wurde, bis der Ursprungsanruf beantwortet wurde. HH:MM:SS:mmm |
| Ursprungsanruf-Prozessor (Originating
Call Processor): | Der
Name oder die IP-Adresse des Anrufagenten, Anrufprozessors, Mediennetzübergangs,
Proxy-Servers oder des Softwareschalters, der den Anruf auf der
Ursprungsseite handhabt. |
| | Könnte leer
sein, wenn nur die Zielseite des Anrufs für NgNAS sichtbar war oder wenn
der Anruf direkt von Endpunkt zu Endpunkt ging, ohne eine Schaltstelle
zu durchlaufen. |
| Ursprungsendpunkt
(Originating End Point): | Der
Name oder die IP-Adresse des Teilnehmer-Netzübergangs, der SIP-Entität oder des
H.323-Anschlusses, von dem bzw. von der der Anruf ausging. Könnte leer
sein, falls lediglich die Zielseite des Anrufs für NgNAS sichtbar war. |
| Ursprungsendpunkt-Typ (Originating
End Point Type): | Die
Art von Vorrichtung, von der der Anruf ausging. |
| OPC: | Ursprungspunktcode
(Originating Point Code), der in der in der IAM des SS7-Protokolls zu finden
ist. |
| Ursprungstrennverzögerung (Originating
Release Delay): | Die
Zeit, die benötigt
wurde, bis die Ursprungsvorrichtung den Anruf volständig trennte
und für
einen weiteren Anruf zur Verfügung
stand. Anzeigeformat: HH:MM:SS:mmm |
| Ursprungs-RTP-Jitter (Originating
RTP Jitter) : | Der
RTP-Jitter, der durch die Ursprungsseite des Anrufs berichtet wird
(nur MGCP). HH:MM:SS:mmm |
| Ursprungs-RTP-Latenz (Originating
RTP Latency): | Die
durch die Ursprungsseite des Anrufs berichtete RTP-Latenz (nur MGCP).
HH:MM:SS:mmm |
| Ursprungspakete-Empfang (Originating
Packets Rx): | Die
durch die Ursprungsseite des Anrufs empfangenen RTP-Pakete (nur
MGCP). |
| Ursprungspakete-Senden (Originating
Packets Tx): | Die
durch die Ursprungsseite des Anspruchs gesendeten RTP-Pakete (nur
MGCP). |
| Verlorene
Ursprungspakete (Originating Packets Lost): | Die
verlorenen RTP-Pakete, wie sie durch die Ursprungsseite des Anrufs
gemeldet werden (nur MGCP). |
| Nach-Wählen-Verzögerung (Post
Dial Delay): | Die
Zeit zwischen der Beendigung des Wählens seitens des Anrufurhebers
und der Anzeige der Schaltstelle, daß der Anruf läuft. HH:MM:SS:mmm |
| Trennzeit
(Release Time): | Nicht
mit der Trennzeit für
CFRs zu verwechseln. Zeitstempel des letzten Anrufsegments (Grundelement), das
den Anruf beendet. Fehlgeschlagene Anrufe zeigen keine Trennzeit
an. |
| Code
der Ursache der Trennung (Rel Cause Code): | Der
Grund, warum der Anruf getrennt wurde. |
| Trenncode
(Release Code): | Details über eine
Interpretation des Trenncodes sind unter SS7/IPDC-Ursachenwerte oder
MGCP-Ansprecheinzelheiten
zu finden. |
| Ferner
PC (Punkt-Code)
(Remote PC (Point Code)): | Punktcode
des fernen Endes des Anrufs. (Nur SS7). Falls leer, bedeutet dies,
daß die
IAM-Nachricht nicht gesehen wurde. |
| Softwareschalteradresse
(Softswitch Address): | Die
IP-Adresse oder der DNS-Name des Softwareschalters, der den Anruf
aufbaut. Diese bzw. dieser wird von dem IP-Quellenadreßfeld der
RCSI-Nachricht erhalten. |
| Startzeit
(Start Time): | Nicht
mit der Anruferzeugungszeit für
CFRs zu verwechseln. Zeitstempel des ersten Anrufsegments (Grundelements),
das den Anruf startet. |
| Zielantwortverzögerung (Term
Answer Delay): | Die
Zeit, die benötigt
wurde, bis der Anruf beantwortet wurde (aus der Perspektive des
Anrufs am Ziel). HH:MM:SS:mmm |
| Zielanruf-Prozessor (Term Call
Processor): | Der
Name oder die IP-Adresse des Anrufagenten, Anrufprozessors, Mediennetzübergangs,
Proxy-Servers oder des Softwareschalter, der den Anruf auf der Zielseite
handhabt. Könnte
leer sein, wenn nur die Ursprungsseite des Anrufs für die NgN-Anwendung sichtbar
war oder wenn der Anruf direkt von Endpunkt zu Endpunkt ging, ohne
eine Schaltstelle zu durchlaufen. |
| Zielrichtung
(Term Direction): | Wer
beendete den Anruf: Teilnehmer oder Netzwerk. Falls leer, kam nie
eine Verbindung oder nie eine Trennung des Anrufs zustande. |
| Ziel-Endpunkt
(Term End Point): | Der
Name oder die IP-Adresse des Teilnehmer-Netzübergangs, der SIP-Entität oder des
H.323-Anschlusses, bei dem bzw. bei der der Anruf endete. Könnte leer
sein, falls lediglich die Ursprungsseite des Anrufs für NgNAS
sichtbar war. |
| Ziel-Endpunkt-Typ (Term End Point
Type): | Die
Art von Vorrichtung, bei der der Anruf endete. |
| Ziel-RTP-Jitter (Term RTP
Jitter): | Der
RTP-Jitter, der durch die Zielseite des Anrufs berichtet wird (nur
MGCP). HH:MM:SS:mmm |
| Ziel-RTP-Latenz (Term RTP
Latency) : | Die
durch die Zielseite des Anrufs berichtete RTP-Latenz (nur MGCP).
HH:MM:SS:mmm |
| Zielpakete-Empfang (Term Packets
Rx): | Die
durch die Zielseite des Anrufs empfangenen RTP-Pakete (nur MGCP). |
| Zielpakete-Senden (Term Packets
Tx) | Die
durch die Zielseite des Anrufs gesendeten RTP-Pakete (nur MGCP). |
| Verlorene
Zielpakete (Term Packets Lost): | Die
verlorenen RTP-Pakete, wie sie durch die Zielseite des Anrufs gemeldet
werden (nur MGCP). |
| Zeit
zum Antworten (Time To Answer): | Zeit
zwischen der IAM- und der ANM-Nachricht.
Im Grunde die Zeit, die es dauerte, bis der Anruf beantwortet wurde.
Falls der Anruf nicht beantwortet wurde (keine ANM wurde empfangen),
ist das Feld leer. |
| Bündelungsnetzübergangadresse
(Trunking Gateway Address): | Die
IP-Adresse oder der DNS Name des Bündelungsnetzübergangs,
der den Anruf führt.
Diese bzw. dieser wird von dem IP-Bestimmungsortadreßfeld der
RCSI-Nachricht erhalten. |
| Zieltrennverzögerang (Term
Release Delay): | Die
Zeit, die es dauerte, bis die Zielvorrichtung den Anruf vollständig trennte
und für
einen anderen Anruf bereit wurde.HH:MM:SS:mmm |
-
Die Gesamtfunktion des Anrufsignalisierungsanalysators
gemäß den Lehren
der vorliegenden Erfindung besteht daher darin, verwandte VoP-Signalisierungspakete
zu sammeln und zu korrelieren und aus den VoP-Signalisierungspaketen
Informationen zu extrahieren, die notwendig sind, um die CFR-Datenstruktur
zu Zwecken einer Anruftestverwaltung zu bestücken. Wenn eine CFR angibt,
daß der
gegenwärtige
Anruf vollständig
aufgebaut wurde, oder falls seit dem letzten VoP-Signalisierungspaket
für die
aktuelle CFR eine gewisse Zeitperiode verstrichen ist, kündigt der
Anrufsignalisierungsanalysator die CFR der CFR-Logik 204 gegenüber an 405.
Dementsprechend versucht das System auch dann, wenn der aktuelle
Anruf nicht vollständig aufgebaut
wurde, Pakete für
den Anruf zu erfassen, da ein Fehlschlagen beim Aufbauen wichtige
Daten beim Diagnostizieren eines gemeldeten Problems darstellen
kann. Die CFRs werden einen vorbestimmten Zeitraum lang in einem
Speicher gehalten. Bei einem spezifischen Ausführungsbeispiel beträgt die vorbestimmte
Zeitdauer 30 bis 90 Tage. Vorteilhafterweise ermöglicht ein Zugriff auf die
CFRs eine spätere
Wiedergewinnung von Maßdaten,
die sich auf einen spezifischen Anruf beziehen. Dies kann wichtig
sein, wenn von einem Anruf gemeldet wird, daß er unter einem gewissen Standard
liegt. Ein Dienstanbieter, der ein System gemäß den Lehren der vorliegenden
Erfindung verwendet, kann eine Beschwerde empfangen und Daten bezüglich des gemeldeten
Anrufs wiedergewinnen, um eine Diagnose und Korrektur des Problems
zu erleichtern.
-
Unter spezifischer Bezugnahme auf 6 der Zeichnungen ist ein
Flußdiagramm
gezeigt, das den CFR-Logikprozeß 204 veranschaulicht.
Der CFR-Logikprozeß 204 nimmt
die CFR von dem Anrufsignalisierungsanalysator 202 an 501,
wenn die CFR angekündigt
wird 405. Die CFR-Logik bestimmt 502, ob die angekündigte CFR
eine IP-Adresse und eine Tornummer des Anrufs enthält. Falls
dies der Fall ist, leitet 503 die CFR-Logik die IP-Adresse
und die Tornummer an die Filtermaschine 201. Falls die
CFR die IP-Adresse und Tornummer nicht enthält, fährt der CFR-Logikprozeß mit dem
Schritt des Bestimmens 504 fort, ob in der CFR enthaltene
Informationen mit einem einer Anzahl von Auslösern 205 übereinstimmen.
Die Auslöser
sind Bedingungen oder boolesche Kombinationen von Bedingungen, die
einen interessierenden Anruf definieren. Gerade die interessierenden
Anrufe werden letztlich erfaßt
und analysiert, während
andere Anrufe und Datenpakete verworfen werden. Ein Auslöser kann
für jegliches
Datenfeld, das durch die CFR erfaßt wird, definiert sein. Für praktische
Zwecke nimmt man an, daß manche
der nützlicheren
Auslöser
eine spezifische Telefonnummer, eine Route, die einen spezifischen
Mediennetzübergang,
Signalisierungsnetzübergang,
Torwächter
und Router umfaßt,
ein spezifischer Codec, ein Anruf, der eine Trennung vor einer Anrufbeendigung
enthält,
ein Anruf, der Fehler enthält,
Konferenzanrufe und Anrufe einer entweder ungewöhnlich kurzen oder einer ungewöhnlich langen
Dauer sind. Ein Auslöser
kann ferner eine boolesche Kombination jeglicher der in der CFR erfaßten Daten
umfassen. Auslöser
ermöglichen
eine adaptive Analyse lediglich bestimmter Anrufe, die zur Isolierung
eines Problems bei einer spezifischen Ausrüstungseinheit oder in einem
spezifischen Bereich einer Anruffunktionalität beiträgt. Eine Unterstützung bei
der Isolierung eines gemeldeten Problems ermöglicht vorteilhafterweise eine
schnellere Lösung
der identifizierten Ursache des gemeldeten Problems. Eine alternative Art
von Auslöser
identifiziert interessierende Anrufmuster. Beispielsweise kann die
CFR-Logik 204 konfiguriert sein, um ein durch eine Kombination
von Anrufen definiertes Ereignis zu identifizieren, beispielsweise
wenn eine Einleitung und eine Beendigung eines kurzen ersten Anrufs
zwischen zwei Telefonnummern und anschließend eine Einleitung eines
zweiten Anrufs zwischen denselben zwei Telefonnummern kurze Zeit
später
vorliegt. Ein derartiges Anrufmuster kann einen Hinweis auf eine
schlechte Sprachqualität
des ersten Anrufs darstellen. Der zweite Anruf in dem Muster wäre daher
ein interessierender Anruf. Die CFR-Logik 204 identifiziert das
Anrufmuster, wie es durch die Auslöser 205 definiert
ist, und signalisiert das Anrufmuster 507 direkt an die Flußanwendung 206.
Das Anrufmuster, das von der CFR-Logik 204 an die Flußanwendung 206 signalisiert wird,
versieht die Flußanwendung 206 mit
Informationen, die die FIR 607, die sich auf den Anruf
bezieht, als interessierenden Anruf auf der Basis eines Anrufmusters
identifizieren.
-
Als Beispiel eines Auslösers eines
interessierenden Anrufs, falls ein bestimmter Ausrüstungsgegenstand
neu in einem Netz ist, beispielsweise ein Codec, unterstützt ein
Auslöser,
der lediglich diejenigen Anrufe analysiert, die durch den Codec
verarbeitet werden, den Benutzer des neuen Ausrüstungsgegenstandes darin, die
Funktionalität
desselben nach der Installation zu verifizieren. In diesem Fall
wäre der
Auslöser
alle Anrufe, die einen spezifischen Nutzlasttyp aufweisen. Als weiteres
Beispiel kann ein Kunde häufige
Probleme lediglich in bezug auf einen Dienst für Konferenzanrufe gemeldet
haben. Ein Auslösen
bezüglich
lediglich Konferenzanrufen an eine oder von einer spezifischen Telefonnummer
ermöglicht
eine Analyse genau des gemeldeten Problems, um zu verifizieren,
daß das
Problem tatsächlich
existiert, und identifiziert anschließend das Ausmaß des Problems.
Ferner kann ein Benutzer die Auslöser modifizieren, um ein Anrufproblem
auf methodische Weise zu isolieren.
-
Bei einem spezifischen Ausführungsbeispiel
sind die Auslöser
in einer Auslöserdatendatei
gespeichert, die Zeichenfolgedaten aufweisen, die durch Strichpunkte
getrennt sind. Die CFR-Logik 204 liest die Auslöserdatendatei.
Die Auslöserdatendatei
umfaßt
eine Identifizierung der Auslöserkategorie,
ein Ist-Gleich-Zeichen und schließlich den Auslöser selbst.
Boolesche Kombinationen verwenden die „Und"- und „Oder"-Terminologie sowie mathematische „Größer-als"-, „Kleiner-als"- und Klammern-Konventionen
für kompliziertere Auslöser. Zu
Veranschaulichungszwecken kann eine einzelne Auslöserdatendatei
folgendes umfassen:
anrufende_Num = 4155554455;
gewählte_Num
= 4155551921;
ip = 130.29.44.165 und Nutz_Last_Typ = 18;
Anruf_Zustand
= getrennt und Anruf_Zustand = Fehler;
(ip = 130.29.44.165
oder ip = 130.29.44.166 oder
ip = 130.29.44.167) und (Anruf_Zustand
= Fehler);
(Anruf Dauer > 1:00:00)
oder (Anruf_Dauer < 0:00:01);
-
Jede Zeile, die durch einen Strichpunkt
getrennt ist, ist ein anderer Auslöser. Demnach sind alle Anrufe,
die einen beliebigen der Auslöser
erfüllen,
interessierende Anrufe. Falls ein Kunde eine Sprachqualität beklagte,
ermöglichen
die ersten zwei Auslöser
von angerufene_Num und gewählte_Num
eine Analyse von lediglich VoP-Anrufen zu oder von dieser Telefonnummer.
Der dritte Auslöser
identifiziert einen bestimmten Codec in dem Netzwerk. Eine Analyse
von Anrufen von einem Codec ermöglicht
ein Überwachen
eines neuen Ausrüstungsgegenstands,
um zu gewährleisten,
daß seine
Verwendung die Sprachqualität
nicht nachteilig beeinflußt.
Es ist üblich,
alle Anrufe mit identifizierten Fehlern zu erfassen, da der Fehlerstatus
auf ein Problem hinweist, und eine Sammlung und Analyse aller Anrufe
mit Fehlern dazu beiträgt,
eine Quelle der Fehler zu isolieren. Ein Benutzer sieht vielleicht,
daß die
meisten Fehler auftreten, wenn der Anruf einen oder mehrere Mediennetzübergänge passiert.
Der Benutzer kann dann den Auslöser
modifizieren, um alle Anrufe mit Fehlern zu erfassen, die auch die
IP-Adresse des in Frage kommenden Mediennetzübergangs umfassen. Ein Beispiel
eines derartigen Auslösers
ist der vierte Auslöser
bei den beispielhaften Auslösern.
Es ist auch vorteilhaft, Anrufe sowohl einer sehr kurzen Dauer als
auch einer sehr langen Dauer zu analysieren. Anrufe einer langen Dauer
sind interessant, weil sie viele Daten enthalten und fehleranfällig sind.
Anrufe von kurzer Dauer sind interessant, weil sie möglicherweise
eine freiwillige Anrufbeendigung durch den Anrufenden oder Angerufenen infolge
einer schlechten Sprachqualität
bedeuten können.
Ein Benutzer kann die Auslöser
modifizieren, indem er auf die Auslöserdatendatei zugreift und
dieselbe modifiziert. Alternativ dazu kann der Benutzer unter Verwendung
einer graphischen Benutzerschnittstelle (GUI – graphical user interface)
die Auslöser
eingeben.
-
Falls die CFR mit einem der benutzerdefinierten
Auslöser 205 übereinstimmt,
oder wenn die CFR-Logik 204 einen interessierenden Anruf
auf der Basis eines Anrufmusterauslösers identifiziert, leitet 505 die CFR-Logik 204 die
IP-Adresse und Tornummer des Anrufs an die Flußmaschine 203. Wie
Fachleute einer Betrachtung der 6 entnehmen
können,
wird die IP-Adresse und Tornummer bei dem CFR-Logikprozeß möglicherweise
zweimal gesandt. In der ersten Instanz wird die IP-Adresse und Tornummer
eines jeglichen VoP-Anrufs an die Filtermaschine 201 gesandt.
Demnach erfaßt
die Filtermaschine 201 alle RTP-Pakete und leitet sie an
die Flußmaschine 203 weiter.
In der zweiten Instanz werden die IP-Adresse und Tornummer lediglich derjenigen
VoP-Anrufe, die mit den definierten Auslöserkriterien übereinstimmen,
an die Flußmaschine 203 gesandt.
Demnach verarbeitet die Flußmaschine 203 lediglich
diejenigen VoP-Pakete, die den interessierenden Anrufen entsprechen.
Die CFR-Logik 204 bestimmt anschließend, ob der interessierende
Anruf auf einem Auslöser
eines interessierenden Anrufs beruht oder auf einem Anrufmusterauslöser 506 beruht.
Falls der Anruf auf einem Auslöser
eines interessierenden Anrufs, beruht, ist keine weitere Verarbeitung
notwendig, und der Prozeß setzt
sich vom Anfang fort. Falls der Anruf auf der Basis eines interessierenden
Anrufmusters bezüglich
einer Erfassung ausgelöst
wird, sendet die CFR-Logik 204 auch die Anrufmusterinformationen
zusammen mit der jeweiligen FIR an die Flußanwendung 206. Auf
diese Weise kann die Flußanwendung
den Anruf als Bestandteil eines Anrufmusters, das eine schlechte
Sprachqualität
aufweist, identifizieren.
-
Unter spezifischer Bezugnahme auf 7 der Zeichnungen ist ein
Flußdiagramm
der Flußmaschine 203 gezeigt.
Die Flußmaschine 203 nimmt
RTP-Pakete von der Filtermaschine 201 an 601.
Die Flußmaschine 203 vergleicht 602 die
RTP-Informationen
mit der IP-Adresse und der Tornummer, die durch die CFR-Logik 204 gesandt
werden 505. Falls die RTP mit keinem der Auslöser 205 übereinstimmt,
verarbeitet die Flußmaschine 203 das
RTP-Paket nicht weiter und kehrt zu dem Anfang des Prozesses zurück, um das
nächste
fortlaufende RTP-Paket anzunehmen. Falls das RTP-Paket mit der IP-Adresse und der Tornummer übereinstimmt,
bestimmt die Flußmaschine,
ob für
den derzeitigen Anruf eine Flußinformationsaufzeichnung
(FIR) vorliegt. Falls die FIR nicht existiert, erzeugt und initialisiert
die Flußmaschine 203 eine
neue FIR und fährt
fort. Die Flußmaschine 203 extrahiert 604 anschließend eine
Sequenznummer und einen Zeitstempel von der RTP. Die Sequenznummer
und der Zeitstempel werden anschließend für den vorliegenden Anruf zu
der FIR gesammelt 605. Nach einem vorbestimmten Zeitraum 606 sendet 607 die
Flußmaschine 203 alle
aktiven FIRs an die Flußanwendung.
-
Die Flußanwendung 206 ist
eine Software, die eine Statistik über die gesammelten FIRs berechnet, die
durch die Flußmaschine
an sie gesendet werden. Berechnungen umfassen Messungen des Paketverlustes,
des Jitters, der Sprechpausenerfassung und die voraussehende mittlere
Bewertungsnote, sind aber nicht auf diese beschränkt. Die Flußanwendung
führt alle
Berechnungen durch und speichert periodische Ergebnisse auf einer
Pro-Anruf-Basis in einer Datenbank. Auf Berechnungen, die durch
die Flußanwendung 206 durchgeführt werden,
wird über
das Verwaltungs-LAN 106 zum Zweck einer Anzeige gegenüber einem
Benutzer oder zum Zweck einer Verwendung durch andere Anwendungen,
beispielsweise Firehunter-Produkt von Agilent Technologies, Inc.,
zugegriffen, um die Daten über
mehrere Anrufe zusammenzufassen.
-
Unter spezifischer Bezugnahme auf 8 der Zeichnungen ist ein
Datenflußdiagramm
eines alternativen Ausführungsbeispiels
gemäß den Lehren
der vorliegenden Erfindung gezeigt. Unter Bezugnahme auf 3 der Zeichnungen ist eine
Flußanwendung 206 auf
zumindest einer Hostseite der Prozessorhardware gezeigt. Unter Bezugnahme
auf 8 der Zeichnungen
sind sowohl eine Hostseitenflußanwendung 206 sowie eine
Kartenseitenflußanwendung 207 gezeigt.
Das Ausführungsbeispiel
der 8 der Zeichnungen
ist nützlich,
falls eine zusätzliche
Verarbeitungsleistung benötigt
wird, um Berechnungen über
die FIRs durchzuführen, oder
wenn es vorteilhaft ist, Verarbeitungsverantwortlichkeiten von der
Hostarbeitsstation 104 auf die Prozessoren auf der Netzwerkkarte 105 abzuladen.
-
Bei einem Ausführungsbeispiel gemäß den Lehren
der vorliegenden Erfindung ist es ferner möglich, Muster der interessierenden
Anrufe zu identifizieren und zu analysieren. Jeder interessierende
Anruf weist eine oder mehrere Anrufcharakteristika auf, die durch
die Daten in der CFR erfaßt
werden, beispielsweise anrufende Telefonnummer, angerufene Telefonnummer,
Anrufdauer und Netzwerkroute. Auf der Basis der Anrufcharakteristika
analysiert das Anrufmuster interessierende Anrufe und sammelt dieselben.
Anrufmuster werden infolge der Sammlung offensichtlich. Diese Analyse
wird in der CFR-Logik 204 auf effiziente Weise durchgeführt, und
Ergebnisse werden an die Flußanwendung 206 signalisiert.
Alternativ dazu können
auch Anrufkombinationen erfaßt
werden. Beispielsweise ist eine Kombination von Anrufbedingungen
zwischen denselben zwei Telefonnummern oder gemeinsamen Netzwerkrouten
ein potentieller Indikator einer schlechten Sprachqualität. Falls
im einzelnen ein Anruf beendet und anschließend in einer der beiden Anrufrichtungen rasch
erneut eingerichtet wird, kann er auf eine Verbindung und Beendigung
aufgrund einer schlechten Sprachqualität und eine anschließende rasche
Neuerstellung, um den Anruf abzuschließen, hinweisen. Das erfaßte Muster
lautet daher auf einen oder mehrere Anrufe kurzer Dauer, auf die
rasch ein längerer
Anruf zwischen denselben zwei Telefonnummern folgt.