-
Mobiltelefon-
oder zellulare Netze haben sich in letzter Zeit stark verbreitet,
und die Größe, Geschwindigkeit
und Komplexität
der Netze hat ebenfalls zugenommen. Telekommunikationsdiensttechnologien,
die in der Lage sind, derartige Hochgeschwindigkeitsdatenanforderungen
zu erfüllen,
umfassen die existierende T1/E1-Technologie.
-
Ein
Testen wird verwendet, um neue Dienstinstallationen zu qualifizieren,
und um Fehler zu suchen, die bei bestehenden Anlagen auftreten. Signalisierungsanalysatoren
ermöglichen
ein verteiltes Testen und eine Analyse, um die Mobiltelefonnetze
zu prüfen
oder Probleme zu suchen.
-
Um
die Kosten zu verringern und die Technikerproduktivität zu steigern,
rüsten
Telekommunikationsdienstanbieter ihre Wartungstechniker zunehmend
mit tragbaren Computern (z. B. Laptop-PCs) für Außendienstverwaltung, Datenbankzugriff
und Systemtesten und -analyse aus. In dem Maß, in dem die Größe und Geschwindigkeit
von Mobilnetzen zugenommen hat, hat jedoch auch der Bedarf an der Fähigkeit
zugenommen, mehr Kanäle
gleichzeitig zu überwachen
und zu analysieren.
-
Bestehende
Telekommunikationstestprodukte sind im allgemeinen prozessorbasiert
und konnten nur 64 Kanäle
unterstützen.
Somit benötigen
die bestehenden Telekommunikationstestprodukte im Allgemeinen eine
komplexe Schaltungsanordnung und Prozessoren, ähnlich denjenigen, die in Personalcomputern
zu finden sind. Es wäre
somit von Vorteil, ein leicht herzustellendes Telekommunikationstestsystem
zu haben, das variabel konfiguriert werden kann, um ein Testen bei
mehreren Hochgeschwindigkeitstoren und zahlreichen Kanälen gleichzeitig durchzuführen.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein Verfahren, eine
Kanalisierungsvorrichtung und ein System zum Analysieren von Mobilfernsprechdaten
mit verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch ein Verfahren gemäß Anspruch 1 oder 18, eine
Kanalisierungsvorrichtung gemäß Anspruch
8 sowie ein System gemäß Anspruch
24 gelöst.
-
Diese
und/oder andere Aspekte und Vorteile von Ausführungsbeispielen der vorliegenden
Erfindung werden aus der folgenden Beschreibung der Ausführungsbeispiele
zusammengenommen mit den beiliegenden Zeichnungen ersichtlich und
leichter erkannt. Es zeigen:
-
1 ein
Flussdiagramm, das ein Verfahren zum Analysieren von Mobilfernsprechdaten
durch eine Kanalisierung gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung veranschaulicht;
-
2 ein
Blockdiagramm einer Kanalisierungsvorrichtung zum Analysieren von
Mobilfernsprechdaten gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
3 ein
Beispiel eines HDLC-Rahmens, der durch den Rahmengeber von 2 verarbeitet wird;
-
4 ein
Beispiel eines TRAU-Rahmens, der durch den Rahmengeber von 2 verarbeitet wird;
-
5 ein
Blockdiagramm des Packetierers von 2; und
-
6 ein
Blockdiagramm, das die Operation der Pufferverwaltungseinrichtung
von 5 veranschaulicht.
-
Es
wird im Detail Bezug auf die Ausführungsbeispiele der vorliegenden
Erfindung genommen, wobei Beispiele derselben in den beiliegenden
Zeichnungen veranschaulicht sind, wobei sich gleiche Bezugszeichen
insgesamt auf die gleichen Elemente beziehen. Die Ausführungsbeispiele
sind im Folgenden unter Bezugnahme auf die Figuren beschrieben.
-
1 ist
ein Flussdiagramm, das ein Verfahren zum Analysieren von Mobilfernsprechdaten durch
eine Kanalisierung gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung veranschaulicht. Mit jetziger Bezugnahme
auf 1 werden bei Operation 110 eindeutige
Kanäle
innerhalb von Daten, die von einem Mobilfernsprechnetz von mehreren
Eingängen
empfangen werden, identifiziert, und dann werden die Daten syntaktisch
in Rahmenfragmente analysiert, die jedem Kanal zugeordnet sind.
Zum Beispiel können
Daten von bis zu 8 T1- oder
E1-Toren auf einem 2G- oder einem 2,5G-Mobilfernsprechnetz gleichzeitig empfangen
werden. Die Rahmenfragmente werden als zu einem bestimmten Kanal
gehörend
identifiziert, basierend auf Werten, die in einer Kanalisierungstabelle
gespeichert sind, die im Folgenden näher beschrieben ist. Normalerweise
sind die Daten Signalisierungsdaten. Die vorliegende Erfindung beschränkt sich
jedoch nicht auf Signalisierungsdaten, und bei den Daten kann es sich
auch um andere Typen von Mobilfernsprechdaten handeln, wie z. B.
Sprachdaten, Textnachrichtdaten oder Internetdaten (z. B. wenn ein
Mobiltelefon verwendet wird, um im Internet zu surfen). Außerdem sind
Ausführungsbeispiele
der Erfindung nicht auf ein Handhaben ausschließlich von T1- oder E1-Toren beschränkt, und
Eingangssignale von mehr als acht Toren können empfangen werden, um mehrere
Kanäle
zu analysieren.
-
Von
Operation 110 geht der Prozess über zu Operation 120,
bei der Rahmenfragmente, die miteinander in Beziehung stehen, identifiziert
werden und in vollständige
Rahmen gebildet oder gruppiert werden. Die Rahmenfragmente werden
als zu einem bestimmten Rahmen gehörend identifiziert unter Verwendung
der Kanalisierungstabelle gemäß entweder einem
Hohe-Ebene-Datenverbindungssteuerungsprotokoll (High Level Data
Link Control protocol) oder einem Umcodierer-und-Ratenadaptereinheit-Protokoll (Transcoder
and Rate Adapter Unit protocol). Vollständige Rahmen werden dann aus
den identifizierten Rahmenfragmenten gebildet und können dann
zu einem Speicher ausgegeben werden, wo ein Prozessor (nicht gezeigt)
auf die Rahmenfragmente zugreift, und der Prozessor kopiert und überträgt die vollständigen Rahmen
zu einem PC zur Anzeige an einen Benutzer.
-
Von
Operation 120 geht der Prozess über zu Operation 130,
bei der Mobilfernsprechdatenverwendungsstatistiken erzeugt werden
basierend auf den Rahmenfragmenten und vollständigen Rahmen auf einer Pro-Kanal-Basis.
Die Mobilfernsprechdatenverwendungsstatistiken weisen normalerweise
einen Gesamtbytezählwert,
einen Gesamtrahmenzählwert, einen
Gesamtkurzrahmenzählwert,
einen Gesamtzählwert
abgebrochener Rahmen und einen Gesamtrahmenprüfsummenfehlerrahmenzählwert in
irgendeiner Kombination auf. Diese Mobilfernsprechdatenverwendungsstatistiken
werden dann zu einer Anzeige, einem Personalcomputer oder einer
anderen Vorrichtung, die in der Lage ist, mit einem Benutzer eine
Schnittstelle zu bilden, ausgegeben. Die Mobilfernsprechdatenverwendungsstatistiken
können
auch in einem Speicher gespeichert werden zur späteren Wiedergewinnung durch
den Benutzer, um das Mobiltelefonnetz zu untersuchen. Außerdem können die
vollständigen
Rahmen über
einen PC, ein Endgerät
oder eine andere Anzeigevorrichtung einem Benutzer angezeigt werden.
Das Verfahren kann in Hardware, Software oder einer Kombination von
beiden implementiert sein.
-
2 ist
ein Blockdiagramm einer Kanalisierungsvorrichtung 200 zum
Analysieren von Mobilfernsprechdaten gemäß einem Ausführungsbeispiel der
vorliegenden Erfindung. Mit Bezugnahme auf 2 weist
die Kanalisierungsvorrichtung ein feldprogrammierbares Gatterarray
(FPGA) 201 auf, das einen Ringpuffer 204, einen
Extrahierer 216, einen Rahmengeber 220, einen
Packetierer 224 und eine Statistikeinheit 230 umfasst.
Eine Kanalisierungstabelle 234 ist auch in einem Speicher
auf dem FPGA 201 gespeichert, obwohl die Kanalisierungstabelle 234 auch
in einem externen Speicher (nicht gezeigt) liegen kann. Mobilfernsprechdaten
werden auf einem Bus 202 empfangen und in dem Ringpuffer 204 gespeichert.
Die Mobilfernsprechdaten sind multiplexte Daten von dem Mobilnetz,
das bis zu 8 T1- oder 8 E1-Tore aufweist, jedoch nicht darauf beschränkt ist. Es
sei darauf hingewiesen, dass andere codierte Paketdaten, die von
anderen Typen von Hochgeschwindigkeitstoren empfangen werden, ebenfalls
durch die Kanalisierungsvorrichtung 200 verarbeitet werden können.
-
Der
Ringpuffer 204 weist ein Kontextinformationsfeld 206,
eine Fragmentierungstabelle 208, einen Datenspeicherbereich 201 und
eine Zugriffssteuerung 212 auf. Der Ringpuffer 204 speichert
die Mobilfernsprechdaten, wobei die Mobilfernsprechdaten Zeitschlitzdaten
und Kontextinformationen aufweisen, die den Zeitschlitzdaten entsprechen.
Ein Byte an einem bestimmten Ort innerhalb eines T1- oder E1-Rahmens
wird als ein Zeitschlitz bezeichnet. Das Kontextinformationsfeld 206 speichert
die Kontextinformationen, die den Zeitschlitzen entsprechen. Zum Beispiel
Informationen wie das Ursprungstor des Zeitschlitzbytes, die Zeitschlitznummer
und einen Zeitstempel, um anzuzeigen, wann das Zeitschlitzbyte empfangen
wurde. Der Datenspeicherbereich 210 beträgt 32 Bytes
und speichert die empfangenen Zeitschlitze. Wie es im Folgenden
näher beschrieben ist,
speichert die Fragmentierungstabelle 208, die durch den
Extrahierer 216 erzeugt wird, Einträge, die ein Byte begleiten,
wenn sich das Byte zu jedem Prozessor bewegt (z. B. dem Extra hierer 216,
dem Rahmengeber 220, dem Packetierer 224 und der
Statistikeinheit 230). Die Zugriffssteuerung 212 steuert eine
Kommunikation zwischen dem Ringpuffer 204 und jeweils dem
Extrahierer 216, dem Rahmengeber 220, dem Packetierer 224 und
der Statistikeinheit 230.
-
Die
Zugriffssteuerung 212 verwendet Zeiger (nicht gezeigt),
um ein Byte zum Verarbeiten durch einen der Prozessoren, bei denen
es sich um den Extrahierer 216, den Rahmengeber 220,
den Packetierer 224 bzw. die Statistikeinheit 230 handelt,
in eine Warteschlange zu stellen. Ein gegebenes Byte bewegt sich
von einem Prozessor zu einem anderen, während es den Ringpuffer 204 durchläuft. Jeder Prozessor
verarbeitet Bytes so lange, wie ein Datenbyte in dem Ringpuffer 204 vorhanden
ist, das durch den vorhergehenden Prozessor verarbeitet wurde. Wenn
jeder Prozessor ein Byte verarbeitet, kann zu dem Kontextinformationsfeld 206 und
der Fragmentierungstabelle 208, die dem Byte entsprechen,
etwas hinzugefügt
werden, dieselben können
modifiziert oder neu geschrieben werden zur Verwendung durch den
nächsten
Prozessor. Der Extrahierer 216, der Rahmengeber 220,
der Packetierer 224 und die Statistikeinheit 230 können jeweils
parallel verarbeiten, so dass ein hoher Durchsatz erreicht werden kann.
-
Der
Extrahierer 216 analysiert die gespeicherten Zeitschlitzdaten
syntaktisch in eine Mehrzahl von Kanälen, wobei jeder Kanal eine
Mehrzahl von Rahmenfragmenten aufweist. Genauer gesagt liest der
Extrahierer 216 die Zeitschlitz- und die Tornummer für ein Byte
und das Byte von dem Ringpuffer 204 und trennt die Bits
in dem Byte in entsprechende Kanäle.
Der Extrahierer 216 analysiert das Byte syntaktisch durch
Bezugnahme auf eine Kanalisierungstabelle 234 unter Verwendung
der Zeitschlitz- und der Tornummer, die diesem Byte entsprechen.
-
Die
Kanalisierungstabelle 234 weist bis zu 8 Einträge pro Tor
pro Zeitschlitz auf, da jedes Bit des Zeitschlitzes in acht unterschiedlichen
Kanälen
verwendet werden könnte.
Bevorzugt, jedoch nicht zwingend, erzeugt ein Benutzer abhängig von
einem Typ einer Kommunikationsverbindung, mit der das FPGA 201 kommunikativ
gekoppelt ist, die Konfiguration der Kanalisierungstabelle 234,
um für
jeden Zeitschlitz an jedem Tor anzugeben, welche Bits zu einem spezifizierten
Kanal gehören,
welche Rahmenbildung dieser Kanal verwendet, welche Filterung benötigt wird
und welche Variante der CRC verwendet werden soll. Für jeden
Eintrag wird ein Bitfeld aus der Kanalisierungstabelle 234 zusammen
mit einer Kanalnummer, einem Rahmenbildungstyp, einer Filterungsoption
und einer CRC-Option gelesen. Die Kanalisierungstabelle 234 kann
auch auf eine Voreinstellung voreingestellt sein, die der Benutzer
wahlweise durch eine Eingabevorrichtung (nicht gezeigt) verändern kann.
-
Der
Extrahierer 216 nimmt jedes Bitfeld und jede Kanalnummer
und erzeugt einen Eintrag in die Fragmentierungstabelle 208 in
dem Ringpuffer 204. Jeder Eintrag in der Fragmentierungstabelle 208 weist
1 bis 8 Bits des ankommenden Datenbytes, die zu den niederstwertigen
Bits in einem neuen bytegroßen
Eintrag der Fragmentierungstabelle 208 abwärts verschoben
werden, die Anzahl von Bits, die in dem Fragmenteintragsdatenbyte
gültig
sind, und die Kanalnummer, den Rahmenbildungstyp, die Filterungsoption
und die CRC-Option auf, wie dieselben aus der Kanalisierungstabelle
gelesen werden.
-
Es
sei z. B. angenommen, dass ein Zeitschlitz durch den Extrahierer 216 aus
dem Ringpuffer 204 gelesen wird. Der Extrahierer schlägt in der
Kanalisierungstabelle 234 einen Eintrag nach, der dieser
Zeitschlitz- und Tornummer entspricht, und bestimmt, dass Bits 2,
5 und 6 des Zeitschlitzes zu Kanal 1 gehören. Der Extrahierer 216 schreibt
dann diese drei Bits als Bits 0, 1 und 2 eines neuen bytegroßen Eintrags
in die Fragmentierungstabelle 208. Somit sind nun diese
3 Bits, die dem Kanal 1 entsprechen, ein Rahmenfragment in dem Eintrag
in der Fragmentierungstabelle 208 in dem Ringpuffer 204 und
sind bereit, durch den nächsten
Prozessor, den Rahmengeber 220, verarbeitet zu werden.
-
Der
Rahmengeber 220 akkumuliert die Rahmenfragmente gemäß den gespeicherten
Kontextinformationen und den entsprechenden Kanälen. Der Rahmengeber 220 liest
jedes Rahmenfragment aus dem Ringpuffer 204 und verkettet
Bits von ähnlichen Kanälen von
vorhergehenden Rahmenfragmenten und prüft auf ein vorbestimmtes Rahmenbildungsmuster,
um Rahmen zu entwerfen. Der Rahmengeber 220 verwendet entweder
ein Hohe-Ebene-Datenverbindungssteuerungsprotokoll
(HDLC) oder ein Umcodierer-und-Ratenadaptereinheit- (TRAU-) Protokoll,
um die akkumulierten Rahmenfragmente derart zu etikettieren, dass
der Packetierer 224 die akkumulierten Rahmenfragmente entweder
als ein Anfangsrahmenfragment, ein Mittelrahmenfragment oder ein
Endrahmenfragment erkennt. Der Rahmengeber 220 kann bis
zu 2048 Kanäle
gleichzeitig unterstützen.
-
Wenn
der Rahmengeber 220 das HDLC-Protokoll verwendet, liest
der Rahmengeber 220 jedes Mal ein Byte aus dem Ringpuffer 204,
wenn ein neuer Zeitschlitz durch den Ringpuffer 204 auf
dem Bus 202 empfangen wird. Diesem gelesenen Byte zugeordnet
ist ein Eintrag der Fragmentierungstabelle 208 mit bis
zu 8 Rahmenfragmenten. Jedes Rahmenfragment weist Daten (d. h. 1
bis 8 Bits), die Größe der Daten
(d. h. 1 bis 8) und eine entsprechende Kanalnummer auf.
-
3 ist
ein Beispiel eines HDLC-Rahmens. Mit Bezugnahme auf das Beispiel
von 3 handhabt der Standardrahmen des HDLC-Protokolls
sowohl Daten als auch Steuernachrichten. Der Anfangsindikator 302 ist
ein Muster von acht Bits. Die Nutzlast 304 kann einen Adress-
und einen Datenabschnitt umfassen und ist ein Vielfaches von 8 Bits,
bevor eine Null-Bit-Einfügung
durchgeführt
wird. Die CRC weist ein CRC-Wort 306 von 16 Bits Länge auf. Der
Endindikator 308 oder das Rahmenabgrenzungsflag, ist ein
vorbestimmtes Muster von 8 Bits. Der HDLC-Rahmen kann auch das Signalisierungssystem
Nr. 7- (SS7) Format umfassen.
-
Der
Rahmengeber 220 weist gemäß diesem Aspekt der vorliegenden
Erfindung ein 24-Bit-Schieberegister (nicht gezeigt), einen Bitschiebezähler (nicht
gezeigt) und einen Speicher (nicht gezeigt) auf. Der Speicher ist
ein interner Speicher des FPGA 201. Diese Komponenten sind
in dem FPGA 201 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung implementiert.
-
Im
Einzelnen ist der Speicher partitioniert, um die folgenden Informationen
zu umfassen, die unabhängig
für jeden
Kanal wiedergewonnen werden können:
die letzten 16 Bits des gegebenen Kanalbitstroms (als „vorhergehende
Daten" bezeichnet);
einen Phasenindikator (0–7),
der verwendet wird, um Ausgangsbits zu Ausgangsbytes umzuwandeln;
einen Indikator, der als „neuer
Rahmen" bezeichnet wird,
der anzeigt, dass nun ein neuer Rahmen beginnt; einen Indikator,
der als „Vorherige
ZBD" bezeichnet
wird, der eine Nullbitlöschung
(zero bit deletion-ZBD) anzeigt, die stattgefunden hat, genau bevor
zu einem anderen Fragment geschaltet wurde; und einen Indikator „erstes
Flag erhalten",
der verwendet wird, um eine Ausgabe zu unterdrücken, bis zumindest das erste
Flag eingegeben wird.
-
Beim
Verarbeiten von Daten verarbeitet der Rahmengeber 220 jedes
Fragment durch eine Reihe von Operationen. Die Schieberegisterbits
(15:0) werden mit den „vorhergehenden
Daten" aus dem Speicher
für den
betreffenden Kanal geladen, und der Bitschiebezähler wird auf Null initialisiert.
Die verbleibenden Schieberegisterbits (23:16) werden mit den ankommenden
Rahmenfragmentdaten (1 bis 8 Bits) geladen. Falls der „Vorherige
ZBD"-Indikator gesetzt ist,
werden Bits (22:15) mit den ankommenden Daten geladen. Der Grund
dafür liegt
darin, dass beim letzten Mal, als ein Fragment für diesen Kanal verarbeitet wurde,
ein Nullbit gelöscht
worden war. Die Bits in dem Schieberegister werden um eine Stelle
nach rechts verschoben, der Phasenindikator wird inkrementiert,
und der Bitschiebezähler
wird inkrementiert.
-
Der
Phasenindikator wird inkrementiert, außer derselbe weist einen Wert
von 7 auf, denn in diesem Fall wird derselbe auf 0 gesetzt. Bits
(15:8) des Schieberegisters werden auf Datenmuster 01111110 oder
11111110 geprüft,
bei denen es sich um das Rahmenabgrenzungsflag bzw. die Abbruchrahmenindikatoren
handelt. Bits (13:8) des Schieberegisters werden auf 011111 geprüft, was
anzeigt, dass eine Nullbitlöschung
stattfinden muss. In der Zwischenzeit wird der Phasenindikator auf
einen Wert von Null geprüft,
und der Indikator „erstes
Flag erhalten" wird
gesetzt, um anzuzeigen, dass zumindest ein Rahmenabgrenzungsflag
erfasst worden ist. Falls „erstes Flag
erhalten" echt ist
und der Phasenindikator Null ist, werden Schieberegisterbits (7:0)
ausgegeben und in den Fragmenteintrag in der Fragmentierungstabelle 208,
der derzeit verarbeitet wird, zurückgeschrieben. Der Anfangsindikator
wird gesetzt und „neuer
Rahmen" wird negiert,
falls „neuer
Rahmen" gesetzt
ist, das Rahmenabgrenzungsflag zu diesem Zeitpunkt jedoch nicht
erfasst worden ist. Der Endindikator wird gesetzt, falls „neuer
Rahmen" nicht gesetzt
ist, das Rahmenabgrenzungsflag jedoch erfasst worden ist. Falls
weder der Anfangs- noch der Endindikator zutreffen, wird der Indikator
auf Mitte gesetzt, was anzeigt, dass das erfasste Rahmenfragment
die Mitte eines vollständigen
Rahmens ist.
-
Falls
das Rahmenabgrenzungsflag oder der Abbruchrahmenindikator erfasst
worden ist, dann wird das interne Flag „neuer Rahmen" gesetzt. Falls das
Rahmenabgrenzungsflag erfasst worden ist, dann wird das interne
Flag „erster
Rahmen erhalten" gesetzt.
Falls der Abbruchrahmenindikator erfasst worden ist, dann wird das
interne Flag „erster
Rahmen erhalten" negiert.
-
Falls
der Bitschiebezähler
gleich der Größe des ankommenden
Rahmenfragments ist, werden Bits (15:0) des Schieberegisters in
den Fragmenteintrag in der Fragmentierungstabelle 208,
der derzeit verarbeitet wird, zurückgeschrieben, und das nächste Rahmenfragment
ist bereit, verarbeitet zu wer den. Außerdem wird, falls eine Nullbitlöschung durchgeführt werden
muss, der Indikator „Vorherige
ZBD" gesetzt.
-
Falls
der Bitschiebezähler
nicht gleich der Größe des ankommenden
Rahmenfragments ist, dann wird, falls eine Nullbitlöschung stattfinden muss,
Bit (13) gelöscht,
Bits (12:1) werden um eine Stelle nach rechts verschoben, und Bits
(23:14) werden um zwei Stellen nach rechts verschoben. Ansonsten
werden, wenn keine Notwendigkeit einer Nullbitlöschung besteht, Bits (23:1)
um eine Stelle nach rechts verschoben. Dann fährt der Prozess fort mit einem
Inkrementieren des Phasenindikators und einem Prüfen auf das Rahmenabgrenzungsflag
und die Abbruchrahmenindikatoren.
-
Eine
Ausgabe von dem Rahmengeber 220 unter Verwendung von HDLC
erfolgt jedes Mal, wenn ein Byte (Zeitschlitz) in die Kanalisierungsvorrichtung 200 auf
dem Bus 202 eingegeben wird. Diesem Byte zugeordnet ist
eine Fragmentierungstabelle 208 mit bis zu 8 Rahmenfragmenten
darin. Jedes Fragment weist auf: 8 Datenbits; einen Rahmenanfangs-,
-mitte- und -endindikator; eine Kanalnummer; einen Indikator für abgebrochene
Rahmen; und einen FCS-Fehlerrahmenindikator.
-
Wenn
der Rahmengeber 220 das TRAU-Protokoll verwendet, liest
der Rahmengeber 220 jedes Mal ein Byte aus dem Ringpuffer 204,
wenn ein neuer Zeitschlitz durch den Ringpuffer 204 auf
dem Bus 202 empfangen wird. Diesem Byte zugeordnet ist eine
Fragmentierungstabelle mit bis zu 8 Rahmenfragmenten darin. Jedes
Rahmenfragment weist Daten (d. h. 1 bis 8 Bits), die Größe der Daten
(d. h. 1 bis 8) und die entsprechende Kanalnummer auf.
-
4 ist
ein Beispiel eines TRAU-Rahmens. Mit Bezugnahme auf das Beispiel
von 4 bezieht sich D auf Datenbits, Cn bezieht sich
auf Steuerbits und T bezieht sich auf Zeitgebungseinstellungsbits. Die
Zeitgebungseinstellungsbits werden verwendet, wenn der nächste Rahmen
vier Bits früher
startet als das Ende des aktuellen Rahmens. Es sei darauf hingewiesen,
dass es andere, nicht gezeigte Varianten des TRAU-Rahmens gibt,
die mit unbedeutenden Modifizierungen durch diese Erfindung gehandhabt werden
können.
-
Der
Rahmengeber 220 weist gemäß diesem Aspekt der vorliegenden
Erfindung ein 26-Bit-Schieberegister (nicht gezeigt), einen Bitschiebezähler (nicht
gezeigt) und einen Speicher (nicht gezeigt) auf. Der Speicher ist
bei einem Aspekt der vorliegenden Erfindung ein interner Speicher
des FPGA 201. Die anderen Komponenten sind ebenfalls in
dem FPGA 201 implementiert gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung.
-
Bei
diesem Beispiel ist der Speicher partitioniert, um die folgenden
Informationen zu umfassen, die unabhängig für jeden Kanal wiedergewonnen werden
können:
die letzten 18 Bits eines gegebenen Kanalbitstroms (als „vorhergehende
Daten" bezeichnet);
einen Phasenindikator (0–7),
der verwendet wird, um Ausgangsbits zu Ausgangsbytes umzuwandeln;
einen Zählwert,
der als „BwdSchutz" bezeichnet wird,
der aufeinanderfolgende fehlerhafte Rahmenbildungsmuster aufzeichnet,
die erfasst worden sind; einen Zählwert,
der als „Bits
vom Ende" bezeichnet wird,
der aufzeichnet, wie viele Bits von dem aktuellen Rahmen noch auszugeben
sind; einen Zählwert, der
als „Bits
vom Anfang" bezeichnet
wird, der aufzeichnet, wie viele Bits von dem aktuellen Rahmen ausgegeben
worden sind; und einen Indikator, der als „Rahmenbildungszustand" bezeichnet wird,
der anzeigt, ob eine Rahmensynchronisation erreicht worden ist.
-
Bei
einer Operation verarbeitet der Rahmengeber 220 unter Verwendung
von TRAU jedes Fragment durch eine Reihe von Operationen, bis alle Rahmenfragmente
identifiziert und zu vollständigen Rahmenbytes
umgewandelt worden sind. Die Schieberegisterbits (17:0) werden mit
den „vorhergehenden
Daten" aus dem Speicher
für den
betreffenden Kanal geladen, und der Bitschiebezähler wird auf Null initialisiert.
Die Schieberegisterbits (25:18) werden mit den ankommenden Rah menfragmentdaten
(1 bis 8 Bits) geladen. Lokale Variablen werden auf „BwdSchutz", „Bits vom
Ende", „Bits vom
Anfang" und „Rahmenbildungszustand" gesetzt, wie von
dem lokalen Speichereintrag für
den Kanal, der verarbeitet wird, wiederhergestellt, wie von dem
Rahmenfragment erhalten. Anschließend werden die Bits in dem Schieberegister
um eine Stelle nach rechts verschoben, der Phasenindikator wird
inkrementiert, und der Bitschiebezähler wird inkrementiert. Der
Phasenindikator wird inkrementiert, außer derselbe weist einen Wert
von 7 auf, denn in diesem Fall wird derselbe auf 0 gesetzt. Bits
(17:1) werden auf ein Datenmuster 10000000000000000 geprüft, bei
dem es sich um den gemeinsamen Teil des TRAU-Rahmenbildungsmusters
für die
verschiedenen TRAU-Rahmentypen handelt. Falls der aktuelle Rahmenbildungszustand für diesen
Kanal außerhalb
des Rahmens (out-of-frame-OOF)
ist und ein Rahmenbildungsmuster erfasst ist, wird der Rahmenbildungszustand
auf im Rahmen (in-frame-INF) gesetzt. Gleichzeitig wird „Bits vom Ende" auf 319 gesetzt, „Bits vom
Anfang" wird auf
1 gesetzt, und „BwdSchutz" wird auf 0 gesetzt.
-
Falls
der aktuelle Rahmenbildungszustand für diesen Kanal INF ist und „Bits vom
Ende" = 0, dann
wird, falls ein Rahmenbildungsmuster erfasst ist „BwdSchutz" auf 0 gesetzt, ansonsten
wird „BwdSchutz" inkrementiert, da
kein Rahmenbildungsmuster an der erwarteten Stelle vorliegt. Falls „BwdSchutz" den Wert 3 erreicht,
wird der Rahmenbildungszustand auf OOF gesetzt.
-
Falls
das TRAU-Rahmenbildungsmuster nicht erfasst ist oder der Rahmenbildungszustand nicht
INF ist, dann wird „Bits
vom Ende" dekrementiert
und „Bits
vom Anfang" wird
inkrementiert. Wenn „Bits
vom Anfang" 17 erreicht,
werden die Bits C1 bis C5 untersucht. Falls die Bits C1 bis C5 bestimmte Werte
aufweisen, kann der Rahmen einer Zeitgebungseinstellungssteuerung
(TAC) unterzogen werden.
-
Falls
der Rahmen einer TAC unterzogen wird, dann werden, wenn „Bits vom
Anfang" gleich 22 ist,
die Bits C6 bis C11 untersucht und gemäß dem TRAU-Standard decodiert.
Das Ergebnis davon verursachte, dass der Wert „Bits vom Ende" angepasst wird,
mit dem Effekt, dass das Rahmenbildungsmuster des nächsten Rahmens
mit einem Versatz gegenüber
der normalen Beabstandung von Rahmenbildungsmustern getestet wird.
-
Wenn
der Phasenindikator Null ist und der Rahmenbildungszustand INF ist,
werden Bits (7:0) des Schieberegisters in den Fragmenteintrag in
der Fragmentierungstabelle 208, der derzeit verarbeitet wird,
zurückgeschrieben.
Der Anfangsindikator wird gesetzt, falls „Bits vom Anfang" = 1, der Endindikator wird
gesetzt, falls „Bits
vom Anfang" = 313,
und falls weder der Anfangs- noch der Endindikator zutreffen, wird
der Indikator auf Mitte gesetzt.
-
Falls
der Bitschiebezähler
gleich der Größe der ankommenden
Daten ist, werden Schieberegisterbits (17:0) in den Fragmenteintrag
in der Fragmentierungstabelle 208, der derzeit verarbeitet
wird, zurückgeschrieben,
zusammen mit den Werten „Bits vom
Anfang", „Bits vom
Ende", „Rahmenbildungszustand" und „BwdSchutz". Das nächste Rahmenfragment
ist dann bereit, um verarbeitet zu werden. Nachfolgende Rahmenfragmente
werden in einer ähnlichen
Weise verarbeitet.
-
Eine
Ausgabe von dem Rahmengeber 220 unter Verwendung von TRAU
erfolgt jedes Mal, wenn ein Byte (Zeitschlitz) in die Kanalisierungsvorrichtung auf
dem Bus 202 eingegeben wird. Diesem Byte zugeordnet ist
eine Fragmentierungstabelle 208 mit bis zu 8 Rahmenfragmenten
darin. Jedes Fragment weist auf: acht Datenbits; einen Rahmenanfangs-, -mitte-
und -endindikator; und eine Kanalnummer.
-
Der
Packetierer 224 gruppiert die akkumulierten bytegroßen Rahmenfragmente
in vollständige Rahmen.
Der Packetierer 224 prüft
jeden Eintrag der Fragmenttabelle 208 und erzeugt vollständige Rahmen
für jeden
Kanal aus den ankommenden Bytes. Der Packetierer 224 kann
jeden Kanal unabhängig von
den anderen Kanälen
verarbeiten. Diese Entschachtelungsfunktion ermöglicht es, dass die Kanalisierungsvorrichtung
effizient wirksam ist und jeden Kanal getrennt von den anderen Kanälen verarbeitet. Gemäß einem
anderen Aspekt der Erfindung kann der Packetierer SS7-Nachrichten
basierend auf einem Längenfeld
filtern und inaktive TRAU-Sprachrahmen filtern.
-
5 ist
ein detaillierteres Blockdiagramm des Packetierers 224 von 2.
Der Packetierer 224 weist eine Ausgabeeinheit 500 und
eine Pufferverwaltungseinrichtung 502 auf. Die Ausgabeeinheit 500 fügt auf einer
Pro-Kanal-Basis jedem Anfangsrahmenfragment einen Kopfblock hinzu,
und fügt
jedem Endrahmenfragment einen Nachsatz hinzu. Die Pufferverwaltungseinrichtung 502 gruppiert
die Rahmenfragmente von der Ausgabeeinheit 500, die jedem
Kanal entsprechen, in einen vollständigen Rahmen, der ein Anfangsrahmenfragment,
zumindest ein Mittelrahmenfragment und ein Endrahmenfragment umfasst.
Die vollständigen
Rahmen werden dann zu einem Speicher gesendet für einen Zugriff durch einen
Prozessor, der die Rahmen kopiert und zu einem PC überträgt zur Anzeige
an einen Benutzer.
-
6 ist
ein detailliertes Blockdiagramm der Pufferverwaltungseinrichtung 502 von 5.
Mit Bezugnahme auf 6 sind die Stromstatusliste
(SSL) 650, die Freiblockliste (FBL) 651 und die
Liste abgeschlossener Nachrichten (CML) 652 Listen, die
in einem externen SDRAM 644 aufrechterhalten werden. Diese
Listen werden durch die SSL-Verwaltungseinrichtung 622,
die FBL-Verwaltungseinrichtung 638 bzw. die CML-Verwaltungseinrichtung 624 verwaltet. Der
Eingangspuffer 604 empfängt
ein Rahmenfragment von der Ausgabeeinheit 500 von 5.
Die SSL-Verwaltungseinrichtung 622 bestimmt über Verbindung 606,
ob es sich bei dem Rahmenfragment um den Anfang eines neuen Rahmens,
die Fortsetzung eines bestehenden Rahmens oder das Ende eines bestehenden
Rahmens handelt. Falls die SSL 622 bestimmt, dass es sich
bei dem Rahmenfragment um einen neuen Rahmen handelt, wird eine Puffernummer
von der FBL-Verwaltungseinrichtung 638 erhalten, und die
Puffernummer wird in der SSL 650 für diesen Index gesichert. Falls
die SSL-Verwaltungseinrichtung 622 bestimmt, dass es sich
bei dem Rahmenfragment um eine Fortsetzung handelt, dann wird der
bestehende Puffer von der SSL 650 erhalten. Der Kern 612 schreibt
die Daten in den zugeteilten Puffer in einem Speicher, wie z. B.
einem externen SDRAM 616. Der externe SDRAM 616 ist
in viele getrennte Puffer partitioniert, von denen jeder groß genug
ist, um einen Rahmen zu halten.
-
Falls
der Kern 612 bestimmt, dass ein gesamter Rahmen geschrieben
worden ist, dann fügt der
Kern 612 über
die Verwaltungseinrichtung 624 der Liste abgeschlossener
Nachrichten (CML) eine Nachricht zu der CML 652 hinzu.
Die CML-Verwaltungseinrichtung 524 teilt
dem Ausgabeelement 620 mit, dass ein vollständiger Rahmen
darauf wartet, ausgegeben zu werden. Das Ausgabeelement 620 greift
auf den Rahmen über
den Kern 612 zu und gibt den Rahmen über eine Verbindung 226 an
einen Speicher aus zur Übertragung
an einen PC, einen vernetzten Computer oder eine andere Anzeigevorrichtung.
-
Unter
erneuter Bezugnahme auf 2 erzeugt die Statistikeinheit 230 Mobilfernsprechdatenverwendungsstatistiken,
die jedem Kanal zugeordnet sind, basierend auf den Rahmenfragmenten
und vollständigen
Rahmen. Die Mobilfernsprechdatenverwendungsstatistiken weisen einen
Gesamtbytezählwert,
einen Gesamtrahmenzählwert,
einen Gesamtkurzrahmenzählwert,
einen Gesamtzählwert
abgebrochener Rahmen und einen Gesamtrahmenprüfsummenfehlerrahmenzählwert in
einer vorbestimmten Kombination auf.
-
Die
Statistikeinheit 230 tastet durch die Fragmenttabelle 208 ab,
um Bytes zu lesen, um ausgewählte
Statistiken zu erzeugen. Die Statistiken können entweder für eine spätere Wiedergewinnung durch
einen Benutzer gespeichert werden o der können zu einem Personalcomputer
(PC) oder einer anderen Anzeigevorrichtung gesendet werden zur Anzeige
der gesammelten Statistiken an den Benutzer.
-
Die
Ausführungsbeispiele
der vorliegenden Erfindung, die hier beschrieben sind, sind für eine Verwendung
bei einer Mehrkanalmobilfernsprechnetzüberwachungskanalisierungsvorrichtung entworfen.
Die Kanalisierungsvorrichtung unterstützt bis zu 2048 gleichzeitige
Kanäle.
Aufgrund der parallelen Verarbeitungsstruktur ist die Kanalisierungsvorrichtung
schnell und effizient. Die Kanalisierungsvorrichtung ist für eine einfache
Herstellung unter Verwendung eines FPGA implementiert.
-
Obwohl
dieselbe in Ausführungsbeispielen der
vorliegenden Erfindung so beschrieben wurde, dass dieselbe auf einem
FPGA implementiert ist, können
andere Ausführungsbeispiele
der vorliegenden Erfindung auch als computerlesbare Codes in einem
computerlesbaren Aufzeichnungsmedium implementiert sein. Das computerlesbare
Aufzeichnungsmedium umfasst alle Arten von Aufzeichnungsvorrichtungen,
bei denen Daten gespeichert werden, die durch ein Computersystem
gelesen werden können.
Derartige computerlesbare Aufzeichnungsmedien sind ROM, RAM, CD-ROM,
Magnetband, Diskette und optische Datenspeicherung und eine Übertragung über Trägerwellen,
z. B. das Internet. Auch kann das computerlesbare Aufzeichnungsmedium
unter Computersystemen, die über
ein Netzwerk verbunden sind, verteilt werden, und die computerlesbaren
Codes können
darauf gespeichert werden und in einer dezentralisierten Weise ausgeführt werden.
-
Die
vielen Aspekte und Vorteile von Ausführungsbeispielen der vorliegenden
Erfindung sind aus der detaillierten Beschreibung ersichtlich, und
somit ist es beabsichtigt, dass die beiliegenden Ansprüche alle
derartigen Merkmale und Vorteile der Ausführungsbeispiele der Erfindung,
die in die wahre Wesensart und den Schutzbereich der Erfindung fallen, abdecken.
Da zahlreiche Modifizierungen und Veränderungen ohne Weiteres durch
Fachleute entwickelt werden können,
ist es ferner nicht erwünscht,
die Erfindung auf den genauen Aufbau und die Operation der Ausführungsbeispiele
zu beschränken,
die veranschaulicht und beschrieben sind, und dementsprechend kann
auf alle geeigneten Modifizierungen und Äquivalente zurückgegriffen
werden, die in den Schutzbereich der Erfindung fallen. Zum Beispiel
ist der Prozess in 1 ein Beispiel und Modifizierungen
sind möglich,
und die Kanalisierungsvorrichtung in 2 ist ein
exemplarisches FPGA-Ausführungsbeispiel,
obwohl Modifizierungen und Konstruktionen möglich sind, die externe Komponenten
als Ersatz verwenden.