DE60115294T2

DE60115294T2 - Überwachung von Netzleistungsparametern in einem mobilen Netz

Info

Publication number: DE60115294T2
Application number: DE60115294T
Authority: DE
Inventors: James Xanthos; Mark Mcdowell; Graham Stead; Joseph Khalil; David Helinski; Joseph Kitchell
Original assignee: Telephia Inc
Current assignee: Nielsen Mobile LLC
Priority date: 2000-07-06
Filing date: 2001-07-06
Publication date: 2006-08-03
Anticipated expiration: 2021-07-07
Also published as: ATE311054T1; EP1374481A2; AU2002218803A1; DE60115294D1; WO2002005486A2; WO2002005486A3; EP1374481B1

Description

EINFÜHRUNG
Die vorliegende Erfindung bezieht sich im Allgemeinen auf ein System für die Messung der Dienstqualität in einem drahtlosen Netzwerk. Insbesondere bezieht sich die vorliegende Erfindung auf ein System zur Messung der Dienstqualität in einem drahtlosen Netzwerk, welches mehrere ferne Einheiten und einen Back-End-Prozessor verwendet.
TECHNOLOGISCHER HINTERGRUND DER ERFINDUNG
Es gibt zwei technische Hauptgebiete, die während den letzten wenigen Jahren ein explosives Wachstum zeigten: Das Erste sind die kabellosen Kommunikationen und das Zweite ist die Verwendung von Datendiensten, insbesondere das Internet. Diese beiden technische Gebiete erfordern beide einen Satz von speziellen Tools um ihre Dienstqualität zu messen. Interessanterweise beginnen die kabellosen Kommunikationen und die Datendienste zu konvergieren. Unglücklicherweise wurde diese Konvergenz nicht von der Entwicklung von zweckmässigen speziellen Werkzeugen begleitet um die Datenqualität der Dienste eines kabellosen Netzwerks zu prüfen.
Das Wachstum von kabellosen Kommunikationen war erstaunlich. Vor zwanzig Jahren bestand in der Tat keine Verwendung von kabellosen Kommunikationsgeräten, wie Mobiltelefonen. Die Marktdurchdringung für kabellose Geräte betrug hingegen für 1999 in den USA 32 Prozente. Die gegenwärtige Voraussage ist, dass 80 Prozente der US-Bevölkerung 2008 Kabellos-Abonnenten sein werden.
Es gibt eine Vielfalt von speziellen Tools, die für die Messung der Qualität der Dienste über kabellose Netzwerke verwendet werden. Diese umfassen folgende (nur um einige Namen zu erwähnen):
Ascom QVoice (einschliesslich QVoice unbedient);
Ericsson TEMS, RSAT-2000, Benchmarker, CellAD, und CeNA;
Nokia TOM;
Safco VoicePrint, DataPrint, und WalkAbout;
Comarco BaseLINE und Gen II;
Grayson Surveyor;
ZK CellTest DX136 und DXC;
Ameritec Swarm;
Neopoint Datalogger; und
Qualcomm QCTest Retriever und QCTest CAIT.
Die allgemeine Unzulänglichkeit dieser Geräte besteht darin, dass sie in erster Linie dafür entwickelt wurden um die Sprechqualität und/oder die RF-Parameter über das kabellose System zu bestimmen. Einige davon wurden modifiziert um einige rudimentäre Datenmessungen zu umfassen; sie sind jedoch nicht optimiert um kabellose Datenmessungen durchzuführen. Insbesondere ermöglichen sie keine unbedienten Messungen von mehreren fernen Einheiten in statistisch signifikanter Weise durch Fernsteuerung durch einen Back-End-Prozessor.
Die klassische Weise der Messung der Sprechqualität von Dienst und/oder RF-Parametern in einem kabellosen Netzwerk umfasst das Aussenden von Technikern um die Ansteuerung des Netzwerks zu testen. Der Ansteuerungstest umfasst die Platzierung eines Testinstruments in einem Fahrzeug und das Durchführen eines Testskripts, das entweder ein Sprach-Testsignal generiert oder empfängt. Das empfangende Ende der Kommunikationsverbindung verwendet ein DSP, das ein Modell des humanen Hörens enthält, um die empfangenen Sprachproben des Systems zu messen und eine entsprechende Qualitätsauswertung zu erzeugen. Zusätzlich können einige der Systeme andere Systemparameter messen, wie SINAD, Lärm, Störung, empfangenes Signalniveau, und Ruf-Fortschritts-Statisiken.
Unglücklicherweise funktionieren die klassischen Messverfahren für die Sprachqualität von Dienst- und/oder RF-Parameter nicht sehr gut für die Messung der Datenqualität des Dienstes. Um Statistisch signifikante Messungen der Datenqualität von Diensten eines kabellosen Netzwerks zu messen, ist es erforderlich mehrere Messungen von mehreren fernen Geräten vorzunehmen. Im Weiteren ist die Messung der Datenqualität inhärent verschieden von andern Messungsarten, wegen Latenzeffekten und andern Effekten, die datenspezifisch sind.
Die meisten existierenden Messgeräte haben diese Fähigkeit aus verschiedenen Gründen nicht. Die Preise von Messinstrumenten liegen im Bereich irgendwo zwischen $5K bis $100K. Dies macht es vom Preis her prohibitiv eine statistisch relevante Flotte von fernen Geräten aufzustellen. Was daher erforderlich ist, sind Fernsteuerungsgeräte, die optimiert sind für die Durchführung von Messungen, die für kabellose Netzwerke nützlich sind, wie die Latenzzeit für den Webseitenzugriff oder die Verzögerung der SMS-Zustellung.
Das Wachstum der Datendienste war so erstaunlich wie die Wachstumsrate der Wireless-Industrie. Die grösste Antriebskraft hinter dem Wachstum der Datendienste war das enorme Wachstum des Internets. Zum Beispiel existierten 130 Websites im Juni 1993, 230 000 Websites im Juni 1996 und 10 Millionen Websites Ende 1999.
Es wurden verschiedene spezielle Tools entwickelt um die Datenqualität der Dienste im Internet zu prüfen.
Das US Patent Nr. 6 006 260, Barrick Jr. et al. (übertragen an Keynote Systems, Inc) offenbart ein Verfahren für die Gewinnung von Latenzzeit, die durch einen User in einem Netzwerk wahrgenommen wird. Die Schritte des Verfahren umfassen einen User-Browser, der einen GET-Befehl aussendet um eine HTML-Seite mit einem eingebetteten Java-Script aufzurufen. Das Java-Scipt startet einen Zeitgeber und erzeugt einen GET-Befehl um eine HTML-Seite aufzurufen. Wenn die Seite empfangen ist, wird der Timer gestoppt und die Zeitgeberinformation, die zusammen mit den Cookie-Daten auf der Browsermaschine gespeichert ist, wird an einen Relais-Server gesandt, welcher die Information protokolliert.
Das US-Patent Nr. 5 657 450, Rao et al. lehrt die Vorgabe von Zeitabschätzungen für lang laufende distale Quellenzugangsoperationen unter Verwendung eines Zwischenservers nahe des Arbeitsraums des Klienten.
Das US-Patent Nr. 6 012 096, Link et al. offenbart ein Verfahren für die Überwachung der der Anwenderzeit beim Seiten browsen.
15. US-Patent Nr. 6 012 096. Link et al. lehrt ein Verfahren für die Überwachung einer Klient-Klient-Netzwerk-Latenzzeit für Spielanwendungen. Das Verfahren umfasst ein Ping-, Antwort- und Antwort-Antwort-Protokoll.
Unglücklicherweise lehrt keines dieser Patente ein Verfahren, welches für die Verwendung zur Messung der Datenqualität von Dienstmessungen über kabellose Netzwerke zweckmässig ist.
In der EP-A-0837615 wird ein System für ein Mobiltelefonsystem vorgeschlagen. Ein ferngesteuertes Testtelefon stellt eine kabellose Verbindung zu einem Mobiltelefonsystem her, das eine Sprachschlaufe implementiert um die Qualität der mobilen Sprachverbindung abzuschätzen. Dieses System verwendet kein Steuermodem. Das Testtelefon ist demzufolge nicht mobil und kann nicht wirklich die Umstände eines Mobiltelefons emulieren.
Wie vorher erwähnt, findet eine enorme Konvergenz statt, die ein kabelloses Netzwerk mit einem Datendienst kombiniert. Dataquest schätzt, dass der US-Markt für kabellose Daten (Einschliesslich Telefone, PDAs, Laptops, und dergleichen) von 3 Millionen Abonnenten im Jahr 1999 zu 36 Millionen Abonnenten im Jahr 2003 wachsen wird. Ericson schätzt, dass eine Milliarde kabellose Einheiten 2003 weltweit im Gebrauch stehen werden, und dass 40 Prozent (400 Millionen) dieser Einheiten durch Daten-User verwendet wird. Im Weiteren sagt Erikson voraus, dass 2003 ein Übergangsjahr sein wird, in welchem der kabellose Netzzugang den kabelgebundenen Netzzugang überschreiten wird.
Als ein weiteres Mass des explosiven Wachstums der Konvergenz von kabellosen Systemen und dem Internet, kann man auf die Vorhersage der Anzahl von kabellosen Internet-Abonnenten blicken. Nach der Strategis-Gruppe wird die Anzahl von kabellosen Portalen von 300'000 im Jahr 2000 auf 9.8 Millionen im Jahr 2003, und schliesslich auf 24.0 Millionen im Jahr 2005 ansteigen.
Eine Auswahl von technischen Fortschritten beschleunigte die Konvergenz von Internetzugriffen über kabellose Geräte. 1997 vereinigten drei konkurrierende Mobiltelefonverkäufer (Nokia, Erikson und Mototorola) und eine kleine Software-Gesellschaft (Phone.com, vormals Unwired Planet) ihre Kräfte um einen normierten Weg zu kreieren um Internet-Daten und kabellose Telefone zu übertragen, ohne dass ein allzu grosse Bandbreite belegt wird. Das Resultat dieser Zusammenarbeit war Die Entwicklung des Wireless Application Protocol (WAP). Eine Basiskomponente von WAP war die Entwicklung von WML (Wireless Markup Langage, welche die frühere Phone.com Handheld Device Markup Langage HDML ersetzte), welche den Web-Inhalt im Vergleich zu HTML komprimiert. Zusätzlich entwickelte das WAP-Forum Standards für die Verwendung von Mikrobrowsern in mobilen Geräten.
Unglücklicherweise liess die Entwicklung der kabellosen Netzzugangstechnologie die Entwicklung von Messtools für kabellose Daten signifikant hinter sich. Demnach besteht ein dringendes Bedürfnis nach spezifische Testtools, die auf die konvergierenden Technologien von kabellosen Systemen und Datenkommunikationen gerichtet sind.
KURZE BESCHREIBUNG DER ERFINDUNG
Um dieses Bedürfnis zu befriedigen wird ein Mess-Tool zur Messung der Datenqualität von Diensten über kabellose Netzwerke zur Verfügung gestellt. Dieses Tool wurde von Grund auf geschaffen, mit verschieden spezifischen Attributen.
Die Erfindung wird durch den Gegenstand des Unabhängigen Systemanspruch 1 definiert.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1a–g zeigen eingewöhnliches Kommunikationsnetzwerk mit verschiedenen kabellosen Kommunikationswegen, die mit dem Internet verbunden sind.
1a zeigt den Kommunikationsweg für Verkehrsdaten in einem verkabelten Internet-Messsystem.
1b zeigt den Kommunikationsweg für Verkehrsdaten währen einer durch einen Schaltkreis geschalteten Datenverbindung gemäss einer Ausführungsform der vorliegenden Erfindung.
1c zeigt den Kommunikationsweg für Verkehrsdaten während einer Packet geschalteten Datenverbindung gemäss einer Ausführungsform der vorliegenden Erfindung.
1d zeigt den Kommunikationsweg für Verkehrsdaten, während einer SMS-Meldungsübertragung, gemäss einer Ausführungsform der vorliegenden Erfindung.
1e zeigt den Kommunikationsweg für Verkehrsdaten während einer aWAP-Datenverbindung gemäss einer Ausführungsform der vorliegenden Erfindung.
1f zeigt den Kommunikationsweg für Verkehrsdaten während einer aWAP-Datenverbindung gemäss einer Ausführungsform der vorliegenden Erfindung.
1g zeigt den Kommunikationsweg für Verkehrsdaten während einer aWAP-Daten-Verbindung, die einen WAP-Überwachungsprozessor einschliesst, gemäss einer Ausführungsform der vorliegenden Erfindung.
1h zeigt den Kommunikationsweg für die Steuerverbindung gemäss einer Ausführungsform der vorliegenden Erfindung.
2a zeigt die Systemarchitektur gemäss einer Ausführungsform der vorliegenden Erfindung.
2b zeigt die Systemarchitektur gemäss einer weiteren Ausführungsform der vorliegenden Erfindung.
2c zeigt die Systemarchitektur gemäss einer weiteren Ausführungsform der vorliegenden Erfindung.
2d zeigt die Systemarchitektur gemäss einer weiteren Ausführungsform der vorliegenden Erfindung.
2e zeigt die Systemarchitektur gemäss einer weiteren Ausführungsform der vorliegenden Erfindung.
3a bis 3d zeigen Varianten Grund-Systemarchitekturen gemäss einer weiteren Ausführungsform der vorliegenden Erfindung.
3a zeigt die Grund-Systemarchitektur für die ferne Einheit.
3b zeigt eine weitere Architektur für eine ferne Einheit mit einem separaten Steuerverbindungsmodem und einem Verkehrsmodem.
3c zeigt eine weitere Architektur für eine ferne Einheit mit einem separaten Steuerverbindungsmodem und mehreren Verkehrsmodems.
3d zeigt eine weitere Architektur für eine ferne Einheit, die mehrere Peripheriegeräte umfasst, gemäss einer Ausführungsform der vorliegenden Erfindung.
4a bis 4d zeigen eine Variante von alternativen Ausführungsformen für die ferne Einheit.
4a zeigt eine Hardwareausführung der fernen Einheit unter Verwendung eines Laptops oder einer Handheldeinheit.
4b zeigt eine Hardwareausführung der fernen Einheit unter Verwendung eines Single-Board-Computers (SBC).
4c zeigt die Organisation des durch Software definierten Radios.
4d zeigt die Organisation der Software in der fernen Einheit.
5a zeigt die Architektur des Backend-Prozessors.
5b zeigt die Architektur des Backend-Prozessors.
5c zeigt die Architektur für das Portal.
6a zeigt Beispiele von einigen von den Gebieten der fernen Einheit ausgehenden Paketen (sowohl Daten als auch signalisierende).
6b zeigt Beispiele von einigen von den Gebieten des Backend-Prozessors ausgehenden Paketen (sowohl Daten als auch signalisierende).
7a zeigt ein Verfahren für die Messung der Datenqualität des Dienstes in einem kabellosen Netzwerk.
7b zeigt ein Verfahren für die Messung der Datenqualität des Dienstes in einem kabellosen Netzwerk, einschliesslich mindestens eines Schrittes, der sich auf die Infrastruktur des kabellosen Netzwerks bezieht.
7c zeigt ein Verfahren für die Messung der Datenqualität des Dienstes in einem kabellosen Netzwerk, einschliesslich mindestens eines befehlsunabhängigen Schrittes.
8a zeigt ein Balkendiagramm von Downloadzeiten von verschiedenen Portalen.
8b zeigt ein Balkendiagramm von Downloadzeiten über verschiedenen kabellose Netzwerke.
8c zeigt ein Balkendiagramm des Prozentsatz der Aufrufbeendigung über verschiedene kabellose Netzwerke
8d zeigt ein trendbezogenes Diagramm, das die Aufrufsbeendigung gegen verschiedene kabellose Netzwerke darstellt.
8e zeigt ein Balkendiagramm der mittleren Downloadzeiten mit einem Zusammenbruch der Netzwerklatenz am WAP-Gateway.
8f zeigt ein Tortendiagramm der Fehlerstatistik für den kabellosen Zugang von Yahoo.
9 erläutert ein System gemäss einer beispielhaften Ausführungsform der vorliegenden Erfindung.
10 erläutert die fernen Einheiten (PUPPIs) im beispielhaften System.
11 erläutert Verfahren, welche alle Softwaremodule für spezifische Aufgaben enthalten.
12 erläutert einen Router als Schnittstelle zwischen einer externen Kommunikationsleitung und einem LAN, der mit den PUPPIs verbunden ist.
13 erläutert die Grundarchitektur für den Back-End gemäss einer beispielhaften Ausführungsform.
14 erläutert zwei grundlegende Softwaremodule, die im Back-End enthalten sind.
15 erläutert die Hardwarearchitektur für den Back-End gemäss einer beispielhaften Ausführungsform.
SPEZIALBESCHREIBUNG
I. ÜBERBLICK
Um die vorliegende Erfindung zu verstehen ist es hilfreich den Kommunikationspfad des Tools der laufenden Datenmessungen mit dem Kommunikationspfad zu vergleichen. Die 1a–g zeigen ein gewöhnliches Kommunikationsnetzwerk mit einer Variante von kabellosen Kommunikationswegen, die mit dem Internet verbunden sind. Es ist den durchschnittlichen Fachleuten gut bekannt, dass diese Figuren ein gewöhnliches Netzwerk erläutern, welche erläuternden Zwecken dient. Zum Beispiel befindet sich in einigen mobilen Netzwerken ein Basisstationscontroller mit mehreren Basisstationen zwischen ihren Verbindungen zum MSC. Als weiteres Beispiel können der WAP-Gateway, der Datenpaket-Gateway und die PSTN-Verbindung in einigen kabellosen Netzwerken durch ein einziges Gerät ersetzt sein, das direkt mit dem MSC verbunden ist.
1a zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten in einen gewöhnlichen verkabelten Internetmesssystem. Die Verkehrsdaten fliessen zwischen dem User-Gerät 124 über dem Internet 122 zu einem Standard-Anwendungsserver 126, was allgemein eine HTML Seite erbringt.
1b zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten während einer durch einen Schaltkreis geschalteten Datenverbindung. Die Verkehrsdaten fliessen von der fernen Einheit 102-1 zur Basisstation 106, MSC 108, PSTN 110, ISP 112, Internet 122, und zu einem Standardanwendungsserver 126. Der Standardanwendungsserver 126 kann zum Beispiel eine HTML-Seite zustellen.
1c zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten während einer Paket geschalteten Datenverbindung. Die Verkehrsdaten fliessen von der fernen Einheit 102-1 zur Basisstation 106, MSC 108, zum Bediener-Basisnetz 114, zum Paketdaten-Gateway 118, zum Internet 122, und zum Standard-Anwendungsserver 126. Der Standardanwendungsserver 126 kann zum Beispiel eine HTML-Seite zustellen.
1d zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten während der Übermittlung einer SMS-Mitteilung. Wenn die SMS Mitteilung zur fernen Einheit 102-1 übermittelt wird, fliessen die Verkehrsdaten von einem Standardanwendungsserver 126 zum Internet 122, SMSC 116, zum Bediener-Basisnetz 114, zum MSC 108, zur Basisstation 106, und zur fernen Einheit 102-1.
1e zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten während einer aWAP Datenverbindung. Wenn die ferne Einheit 102-1 auf den aWAP-Server 128 zugreift, fliessen die Verkehrsdaten von der fernen Einheit 102-1 zu einer Basisstation 106, zum MSC 108, zur Bedienerbasisstation 114, zum WAP-Gateway 120, zum Internet 122, und zum WAP-Server 128. Zum Beispiel erlaubt der Verkehrsdatenpfad, der in 1e gezeigt ist, Latenzmessungen für den kabellosen Webseitenzugriff oder E-commerce-Transaktionen.
Es ist wichtig festzustellen, dass obschon der Begriff WAP auf das kabellose Internet-Protokoll angewandt wird, die Prinzipien der vorliegenden Erfindung nicht auf eine WAP-Implementierung eingeschränkt sind. Die vorliegende Erfindung kann unter Verwendung irgend eines Internet-Protokolls ausgeführt werden, einschliesslich HDML und andere zukünftige kabellose Internetprotokolle, die noch entwickelt werden können. Die beiliegenden Beispiele werden mit einigen konkurrierenden Technologien zur Verfügung gestellt, damit diese Offenbarung funktionell mit WAP äquivalent betrachtet wird. Zum Beispiel kann der Webgehalt als Textmitteilung oder als SMS-Mitteilung (wie durch Xypoint oder GoSMS vorgeschlagen) zugestellt werden, so dass er mit existierenden Mobiltelefonen kompatibel ist. Alternativ kann der Webgehalt als existierender HTML-Gehalt für kabellose Geräte zugestellt werden, wie vorgeschlagen durch Spyglass' Prism Technology oder durch iMode aus Japan. In einem weiteren Beispiel kann der Gehalt durch ein Vorlagenmodell bearbeitet werden, welches den existierenden HTML-Gehalt liest und die Daten in eine Vorlage einpasst, die für verschiedene Arten von Mobiltelefonen optimiert ist, wie das von Everypath.com vorgeschlagene System. In einem andern Beispiel kann der Datengehalt an einen Palm Pilot oder einen andern PDA oder ein Handheldgerät, das ein eigenes Protokoll verwendet, zugestellt werden
Zusätzlich wird erwähnt, dass die vorliegende Erfindung nicht auf die Verwendung des Internets eingeschränkt ist, sondern, es kann wirksam praktiziert werden, indem ein weit reichendes Netzwerk verwendet wird, ungeachtet der besonderen Hardware-Ausführungsbesonderheiten. Folglich wird der Ausdruck Wireless Date Protocol (WDP) auswechselbar mit dem allgemein verwendeten begriff WAP verwendet um das Protokoll zu beschreiben, welches für den kabellosen Datenzugang verwendet wird.
1f zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten währen einer aWAP Datenverbindung. Wenn die ferne Einheit 102-1 auf den Benchmark WAP-Server 130 zugreift, fliessen die Verkehrsdaten von den fernen Einheiten 102-1 zu einer Basisstation 106, einem MSC 108, Bediener-Basissystem 114, einem WAP Gateway 120, und zum Benchmark WAP-Server 130. Diese Konfiguration erlaubt Datenmessungen ohne dass Unsicherheiten der Latenz durch das Internet 122 selbst eingeschlossen sind. In andern Worten erlaubt die Konfiguration in 1f Messungen der Latenz wegen dem kabellosen Netzwerk selbst, ohne Beitrag vom Internet 122.
1g zeigt den Kommunikationsweg (dicke unterbrochene Linie) für die Verkehrsdaten während einer aWAP-Datenverbindung, einschliesslich einem aWAP Überwachungsprozessor 132. Der WAP überwachende Prozessor 132 kann als Überwachungs-Software implementiert werden, die auf einem separaten Gerät installiert ist und das am WAP Gateway 120 angehängt ist. Die Software soll den Verkehr durch den WAP Gateway 120 überwachen und Messdaten zur Verfügung stellen, wie Durchsatz, Latenz und Information über verlorene Pakete. Diese Konfiguration erlaubt, dass das kabellose Netzwerk und das Internet 122 selbst separat analysiert und überwacht werden, wodurch für beide Leistungsinformationen zur Verfügung gestellt werden. Im Weiteren ist der WAP Überwachungs-Prozessor 132 fähig Protokollinformationen direkt vom WAP-Gateway 120 zu sammeln, welche bei den mehreren fernen Einheiten (102-1 bis 102-N) nicht erhältlich sind.
Die Überwachungssoftware kann als separate Anwendung auf dem WAP-Gateway 120 laufen, oder kann in die WAP-Gatewaysoftware selbst eingebettet werden und kann als Teil der gesamten Gateway-Applikation laufen. Die Überwachungssoftware könnte einen Mechanismus zum Sammeln von Messdaten aufweisen, und diese Informationen an den Back-End-Prozessor weiterleiten über das Internet, das kabellose Netzwerk, oder durch einige andere Mittel. Die Überwachungssoftware kann Resultate temporär lokal abspeichern und eine Vorverarbeitung der Daten vornehmen, bevor sie an den Back-End-Prozessor weitergeleitet werden.
1h zeigt den Kommunikationsweg für die Steuerverbindung. Die Steuerverbindung wird verwendet um die fernen Einheiten 140, 142, 144, 146 vom Back-End-Prozessor 148 fernzusteuern. Spezifisch ist der Prozess im Back-End-Prozessor 148, welcher mit den fernen Einheiten 140, 142, 144, 146 kommuniziert, ein Flotten-Managementprozess, welcher später im Detail diskutiert wird.
Die fernen Einheiten können entweder mobil 140, 142, 144 oder stationär 146 sein. Die mobilen Einheiten 140, 142, 144 können in einer Vielzahl von Fahrzeugen montiert werden, wie in Taxis, Polizeiautos, Busse, Postfahrzeuge, Lieferwagen, Flottenfahrzeuge, um einige Beispiele anzugeben. Die stationären fernen Einheiten 146 können in irgend einem Bereich montiert werden, in welchem sich die Öffentlichkeit versammelt und kabellose Geräte verwendet werden. Dies umfasst Flughäfen, Busstationen und Bahnhöfe, nur um einige Beispiele anzugeben.
Es sind Varianten von Kommunikationstechnologien erhältlich um Steuerverbindungen zu erstellen. Die Steuerverbindungen können als Daten implementiert werden, die auf gängigen kabellosen Netzwerken laufen, wie CDMA iDEN, TDMA, oder GSM, nur um einige Beispiele zu nennen. Zusätzlich kann die Steuerverbindung auf einem AMPS-Netzwerk ausgeführt werden, das zum Beispiel CDPD verwendet. Alternativ kann die Steuerverbindung unter Verwendung eines Zwei-Weg-Datensystems, wie ARDIS, MOBITEX, SKYTEL und dergleichen ausgeführt werden.
II. SYSTEM-ARCHITEKTUR
2a zeigt die System-Architektur gemäss einer Ausführungsform der Erfindung. Wie vorher beschrieben umfasst die Erfindung mehrere ferne Einheiten (202-1–202-N), die entweder mobil oder stationär sein können. Jede ferne Einheit kann eine Standorteinheit (202a-1–202a-N) einschliessen, welche erlaubt, dass die ferne Einheit ihren Standort genau bestimmen kann. Im weiteren umfasst jede ferne Einheit eine Kommunikationsverbindung (202b-1–202b-N), die sowohl für die Kommunikationsverbindung als auch die Verkehrsdaten sorgt. Die Kommunikationsverbindung 202b-1 kommuniziert über ein Kommunikationsnetzwerk 210 welches die Information auf den Kommunikationsserver 212 weiterleitet, welcher mit einem Datennetzwerk 220 verbunden wird. Das Datennetzwerk 220 kann ein öffentliches Datennetzwerk wie das Internet oder ein privates Datennetzwerk sein. Ein Back-End-Prozessor 224 ist mit dem Datennetzwerk 220 verbunden um die Steuerverbindungsinformation zu beherrschen, sowohl Befehle wie auch Antworten und Verkehrsdaten. Zusätzlich sind die Kunden 222 auch mit dem Datennetzwerk verbunden, so dass sie auf den Back-End-Prozessor 224 zugreifen kann.
2b zeigt die System-Architektur gemäss einer weiteren Ausführungsform der vorliegenden Erfindung. Das System in 2b unterscheidet sich vom System, das in 2a dargestellt ist, indem das Steuerverbindungsnetzwerk und das Verkehrs-Datennetzwerk zwei verschiedene Kommunikationsnetzwerke sind. Jede ferne Einheit (z.B., 202-1) kann eine Standorteinheit 202a-1 enthalten, die den fernen Einheiten 202-1 erlaubt, ihren Standort genau zu bestimmen. Im Weiteren umfasst jede ferne Einheit 202-1 einen Steuerverbindungsmodul 202c-1 und einen Verkehrsdatenkommunikationsmodul 202d-1. Die Steuerverbindung 202c-1 leitet Befehls- und Antwortinformationen durch ein Kommunikationsnetzwerk A 210A und einen Kommunikationsserver A 212A an das Datennetzwerk 220 weiter. Das Verkehrsdatenkommunikationsmodul 202d-1 leitet Verkehrsdaten durch das Kommunikationsnetwerk B (210B) und den Kommunikationsserver B (212B) und das Datennetzwerk 220. Ein Back-End-Prozessor 224 wird mit dem Datennetzwerk 220 verbunden um die Steuerverbindungsinformation zu verarbeiten, sowohl Befehle als auch Antworten, und Verkehrsdaten. Zusätzlich sind die Kunden 222 auch mit dem Datennetzwerk 220 verbunden, so dass sie auf den Back-Endprozessor 224 zugreifen können.
2c zeigt die Systemarchitektur gemäss einer andern Ausführungsform der Erfindung. Das System, das in 2c dargestellt ist, unterscheidet sich vom System, das in 2b gezeigt ist, wobei jede ferne Einheit (z.B., 202-1) mehrere Verkehrsmodule (202d1-1–202dN-1) besitzen kann. Jede ferne Einheit 202-1 kann eine Lokalisierungseinheit 202a-1 umfassen, die der fernen Einheit erlaubt, ihre Position genau zu bestimmen. Zusätzlich umfasst jede ferne Einheit 202-1 ein Steuerverbindungsmodul 202c-1 und umfasst mehrere Verkehrsdatenkommunikationsdatenmodule (202d1-1–202dN-1). Die Steuerverbindung leitet Befehl- und Antwortinformationen durch das Kommunikationsnetzwerk A 210A und dem Kommunikationsserver A 212A zum Datennetzwerk 220. Jedes Verkehrsdatenkommunikationsmodul 1 bis N (202d1-1–202dN-1) leitet Verkehrsdaten durch das Kommunikationsnetwerk B-1 (210B-1) bzw. B-N (210B-N), und durch die Kommunikationsserver B-1 (212B-1) bzw. B-N (212B-N) zum Datennetzwerk 220. Ein Back-End-Prozessor 224 ist verbunden mit dem Datennetzwerk 220 zur Verarbeitung der Steuerverbindungsinformation, der Befehls- als auch der Antwort-, und der Verkehrsdaten. Zusätzlich sind die Kunden 222 auch mit dem Datennetzwerk 220 verbunden so dass sie auf den Back-End-Prozessor 224 zugreifen können.
2d zeigt die Systemarchitektur gemäss einer weitern Ausführungsform der Erfindung. Das System in 2d unterscheidet sich vom System, das in 2c gezeigt ist, darin dass mehrere Steuerverbindungs-Kommunikationsnetzwerke verwendet werden können. Dies ist besonders wichtig in Systemen, in welchen die fernen Einheiten in verschiedenen Städten angewandt werden. Es kann bevorzugt sein, in diesem Fall ein verschiedenes Steuerverbindungskommunikationsnetzwerk in verschiedenen Städten zu verwenden, das von der Abdeckung des kabellosen Netzwerks und von der Preisgestaltung der Daten abhängig ist.
Jede ferne Einheit (202-1–202-N) kann eine Positionierungseinheit (202a-1–202a-N) umfassen, welche es der fernen Einheit erlaubt ihre Position genau zu bestimmen. Im weiteren umfasst jede fernen Einheit (202-1–202-N) ein Steuerverbindungskommunikationsmodul (202c-1–202c-N) und umfasst mehrere Verkehrsdatenkommunikationsmodule (202d1-1–202dN-1–202d1-N–202dN-N). Die Steuerverbindung überträgt Befehls- und Antwortinformation durch eines der Kommunikationsnetzwerke A-1 (210A-1) bis A-N (210A-N in Abhängigkeit des zweckmässigen Kommunikationsnetzwerk für die spezifische ferne Einheit. Jedes Verbindungskommunikationsnetzwerk A-1 (210A-1) bis A-N (210A-N) ist mit einem entsprechenden Kommunikationsserver A-1 (212A-1) bis A-N (212A-N) verbunden, was die Übermittlung der Befehls- und Antwortinformation an das Datennetzwerk erlaubt. Jedes Verkehrsdatenkommunikationsmodul 1 (202d1-1) bis N (202d1-N) leitet Verkehrsdaten durch das Kommunikationsnetzwerk B- 1 (21OB-1) bzw. B-N (210B-N), und durch die Kommunikationsserver B-1 (212B-1) bzw. B-N (212B-N) zum Datennetzwerk. Ein Back-End-Prozessor 224 ist mit dem Datennetzwerk 220 verbunden für die Verarbeitung der Steuerverbindungsinformation, Befehls- und auch Antwort- und Verkehrsdaten. Zusätzlich sind die Kunden 222 auch mit dem Datennetzwerk 220 verbunden, so dass sie auf den Back-End-Prozessor 224 zugreifen können.
2e zeigt die Systemarchitektur gemäss einer weiteren Ausführungsform der Erfindung. Das System in 2e unterscheidet sich vom System, das in 2d dargestellt ist, wobei sowohl mobile als auch stationäre ferne Einheiten gezeigt sind. Da die Verkehrsdaten-Kommunikationskanäle in 2e die gleichen sind wie diejenigen in 2d, wurden sie weggelassen um das Diagramm zu vereinfachen. Die Steuerverbindungen für die mobilen fernen Einheiten (202-1 bis 202-N) sind die gleichen wie diejenigen, die in 2d beschrieben sind.
Jede stationäre ferne Einheit (202-X bis 202-Y) kann eine Lokalisierungseinheit (202a-X bis 202a-Y) enthalten, welche der fernen Einheit erlaubt, in genauer Weise ihren Standort zu bestimmen. Die Lokalisierungseinheit (202a-X bis 202a-Y) ist in den stationären fernen Einheiten im Allgemeinen fakultativ, da ihr Standort vermutlich bekannt ist. Jede stationäre ferne Einheit enthält ein Steuerverbindungsmodul (202c-X bis 202c-Y), welches über eine entsprechende kabelgebundene Leitung verbunden ist mit einem entsprechenden Kommunikationsnetzwerk C-1 (210C-1) bis C-N (210C-N) und dem angeschlossenen Kommunikationsserver C-1 (212C-1) bis C-N (212C-N), welches ermöglicht, dass die Befehls- und Antwortinformation an das Datennetzwerk 220 geleitet wird. Ein Back-End-Prozessor 224 ist verbunden, um ein Datennetzwerk 220 zu sein, um die Steuerverbindungs- Informationen, Befehls- und Antwort-, und Verkehrsdaten zu verarbeiten. Zusätzlich werden die Kunden 222 auch mit dem Datennetzwerk 220 verbunden, so dass sie auf den Back-End-Prozessor 224 zugreifen können.
III. FERNE EINHEIT
Die ferne Einheit hat eine Anzahl von Attributen. Die ferne Einheit sollte vorzugsweise tragbar sein, im Hinblick auf die Grösse und das Gewicht, so dass sie in einem Fahrzeug oder in einem stationären öffentlichen Bereich verwendet werden kann. Mögliche Fahrzeuge umfassen Busse, Polizeifahrzeuge, Taxis, Postfahrzeuge, Lieferwagen, und Flottenfahrzeuge, nur um einige zu erwähnen. Beispiele von stationären öffentlichen Anlagen sind Flughäfen, Bahnhöfe, Busstationen und solche öffentliche Anlagen, wo eine grosse Anzahl von Leuten kabellose Geräte verwendet.
Eine andere Eigenschaft der fernen Einheit ist, dass sie entweder in einem Fahrzeug oder in einem öffentlichen Bereich montierbar ist. Beispielsweise können die fernen Einheiten an DIN-Bars montiert sein, wie sie im Allgemeinen für industrielle Ausrüstungen verwendet werden. Alternativ können die fernen Einheiten an einer Standardklammer, Spannankervorrichtung, Stoffstreifen, Bolzen, oder mit einem Klebemittel, wie Velcro, zum Beispiel, montiert werden.
Eine weitere Eigenschaft der fernen Einheit ist, dass sie fähig ist, einen breiten Temperaturbereich zu überstehen, wie der industrielle Temperaturbereich von –40 Grad C bis +80 Grad C, zum Beispiel. Diese Eigenschaft erlaubt die Verwendung der fernen Einheit in einem weiten Bereich von geographischen Umgebungen. Im Weiteren erlaubt sie den Einsatz der fernen Einheit an stellen wie im Kofferraum eines Fahrzeugs, wo die Luftzirkulation eingeschränkt ist.
Eine andere Eigenschaft der fernen Einheit ist die Fähigkeit Vibrationen zu überstehen. Diese Eigenschaft ist wichtig, da viele der fernen Einheiten in Fahrzeugen zum Einsatz gelangen und einer starken Vibration unterworfen sind. Es gibt eine Anzahl von Standardtechniken, welche verwendet werden können um die Vibrationseinwirkungen auf die die ferne Einheit zu mildern. Diese beinhalten Frequenz absorbierende Montagematerialien und die Einkapselung der Komponenten der gedruckten Schaltung zwecks zusätzlicher Stabilität.
Eine andere Eigenschaft der fernen Einheit ist, dass sie allen lokalen Normen für Strahlungen entspricht, sowohl der ausgestrahlten als auch den geleiteten. In den Vereinigten Staaten, zum Beispiel, werden die Strahlungen der meisten digitalen Geräte abgedeckt durch den FCC Teil 15, und Strahlungen von mobilen Geräten werden abgedeckt durch FCC Teil 22. In Europa bestehen generell Richtlinien, die die Strahlungsaussendung, Leitungsausstrahlungen und „Radiated Immunity" abdecken, um das CE-Label zu erhalten.
Eine weitere Eigenschaft der fernen Einheit ist die Fähigkeit, die Input Energiequelle zu bedienen. Zuerst sollte die ferne Einheit einige Arten der Energieregulierung umfassen. Dies ist besonders wichtig in einer Fahrzeugumgebung, in welcher die Energie, die von der Fahrzeugbatterie zugeführt wird, sehr rauschend ist. Zusätzlich sollte die ferne Einheit umfassen: Die Fähigkeit sämtliche externe Module oder Peripheriegeräte mit Energie zu versorgen, welche an die Hauptsteuerungseinheit angeschlossen sind. Im Weiteren können die fernen Einheiten ein Art von Batterieunterstützung mit einem automatischen Ladegerät aufweisen, damit die ferne Einheit in einer mobilen Umgebung nicht die Fahrzeugbatterie entlädt, wenn die Zündung ausgeschaltet ist. Diese Anforderung ist bei einer stationären Verwendung nicht so wichtig, da die Energie von einer Wechselstromquelle unter Verwendung eines Gleichrichters bereitgestellt werden kann. Man kann jedoch auswählen, ob die Batterie mit Ladegerät in dieser Konfiguration eingeschlossen sein soll, auch um, im Fall eines Wechselstromausfalls, eine Ersatzbatterie Verfügung zu stellen. Schliesslich kann die ferne Einheit eine Art von "Schlaf-Modus" einschliessen, um in Perioden von sporadischer Aktivität Energie zu sparen.
Die ferne Einheit wird nun im Hinblick auf verschiedene Ausführungsformen gemäss der Erfindung beschrieben. Die 3a bis 3d zeigen verschiedene Grundarchitekturen für die ferne Einheit. 4a bis 4d zeigen verschiedene mögliche Anwendungen für die ferne Einheit.
3a zeigt die Basisarchitektur für die ferne Einheit. Die ferne Einheit 300 enthält eine Steuereinheit 302, eine Lokalisierungseinheit 304, und eine Steuerverbindung und ein Verkehrsmodem 306. Die Steuereinheit 302 ist das Hauptsteuergerät für die ferne Einheit 300 und ist mit der Lokalisierungseinheit 304 und der Steuerverbindung und dem Verkehrsmodem 306 verbunden. Die Lokalisierungseinheit 304 bestimmt den Standort der fernen Einheit 300.
Die Steuerverbindung und das Verkehrsmodem 306, dargestellt in 3a werden verwendet um mit dem Back-End-Prozessor 224 zu kommunizieren. Die Steuerverbindung und das Verkehrsmodem 306 sind mit der Steuerungseinheit 302 verbunden um Steuerungsinformation und Verkehrinformation zu senden und zu empfangen. Die Steuerungseinheit führt im Allgemeinen ein Hauptprogramm aus, das die Lokalisierungseinheit 304 und die Steuerverbindung und das Verkehrsmodem 306 steuert.
Es gibt Varianten von Wegen, in welchen die Lokalisierungseinheit 304 den Standort gemäss der Erfindung bestimmen kann. Die Lokalisierungseinheit 304 kann einen GPS-Empfänger enthalten, wie solche die zum Beispiel hergestellt werden durch Trimble, Ashtech, Garmin, oder Magellan. Wenn die Lokalisierungseinheit 304 ein GPS-Empfänger ist, kann die Verbindung zur Steuerungseinheit 302 eine serielle Kommunikationsverbindung sein. In einer andern Ausführungsform, kann die Lokalisierungseinheit 304 ein GPS-Daughterboard sein, wie ein solches das zum Beispiel durch Avocet, Trimble, Ashtech, oder Rockwell hergestellt wird. Wenn die Lokalisierungseinheit 304 ein GPS-Daughterboard ist, ist die Verbindung zur Steuerungseinheit 302 in der Regel durch einen eigenen Connector verbunden, der auf der Steuerungseinheit 302 montiert ist. Die Steuerung des GPS-Daughterboard wird im allgemeinen durchgeführt, in dem eine serielle Verbindung verwendet wird. In einer weiteren beispielhaften Ausführungsform der Erfindung kann die Lokalisierungseinheit 304 ein GPS-Chipset oder einen einfachen GPS-Chip enthalten, welcher direkt auf der Steuerungseinheit 302 montiert ist, und welcher ein Busschnittstelle besitzt. Weiter kann jede der GPS-Implementierung der Lokalisierungseinheit ein differenzierendes GPS verwenden, welches RTCM oder RTCA Korrekturen oder kann alternativ WAAS-Fähigkeiten aufweisen.
Es ist den Fachleuten gut bekannt dass es Variationen von alternativen Implementierungen für Lokalisierungseinheit gibt, welche das Standard-GPS nicht involvieren. Zum Beispiel kann man ein verteiltes GPS-System verwenden, ein solches, wie dasjenige, das von SnapTrack entwickelt wurde, in welchem die GPS Funktionalität teilweise durch einen zentralisierten Server verarbeitet wird. Eine andere alternative Lokalisierungsoption ist die Verwendung einer Triangulationstechnik, welche entweder den Ankunftswinkel oder die Zeitdifferenz der Ankunftsinformation verwendet. Obschon der allgemeine Ausdruck Triangulation verwendet wird, besteht keine Anforderung, dass drei Messpunkte verwendet werden müssen. Eine weitere Lokalisierungsoption ist die Verwendung des RF-Fingerprinting, wie dasjenige, das durch U.S. Wireless entwickelt wurde, welches den Einheitsstandort auf Basis einer Mehrpfad-Signatur bestimmt.
Die Fachleute werden verstehen, dass 2a–e, 3a–d, und 4a logische Antennen anstatt physikalische Antennen zeigen. Diese logischen Antennen können virtuell irgendwelche Kombinationen eingehen, zu einer einzigen physikalischen Antenne oder zu Gruppen physikalischer Antennen je nach den spezifischen Erfordernissen.
3b zeigt eine andere Architektur für die fernen Einheit 300 mit einem separaten Steuerverbindungsmodem 308 und einem Verkehrsmodem 310. 3b unterscheidet sich von 3a darin, dass die Steuerverbindung und das Verkehrsmodem 306 in ein separates Steuerverbindungsmodem 308 und Verkehrsmodem 310 geteilt sind. Der Vorteil des Trennens des Steuerverbindungsmodem 308 vom Verkehrsmodem 310 besteht darin, dass es der fernen Einheit 300 erlaubt mit Steuerungsinformation und Verkehrsinformation über verschiedene Kommunikationsnetzwerke zu kommunizieren.
Es ist den Fachleuten gut bekannt, dass es eine Vielfalt von Realisierungen für das Verkehrsmodem und auch das Steuerverbindungsmodem gibt, welche kollektiv als Modemeinheiten bezeichnet werden. Die Modemeinheiten können ein Mikrotelefon umfassen, das mit der Steuerungseinheit unter Verwendung eines seriellen Kabels verbunden ist. Die Modemeinheiten können einen Modemmodul umfassen, der mit der Steuerungseinheit verbunden ist, wobei ein spezielles serielles Kabel verwendet wird. Die Modemeinheiten können eine PCMCIA-Karte umfassen, die mit der Steuerungseinheit unter Verwendung eines PCMCIA-Sockels verbunden sind. Die Modemeinheiten können ein kundenspezifisches Modem umfassen, das entweder auf einer separaten gedruckten Platine oder auf der auf der gleichen Platine wie die Steuerungseinheit ausgeführt sein kann. Die Modemeinheiten können ein Software-definiertes Radio (SDR) umfassen, in welchem der grösste Teil der Radiofunktionalität softwaremässig implementiert ist. Die Software kann auf einer separaten Platine oder auf der gleichen Platine wie die Steuerungseinheit laufen. Das Steuerverbindungsmodem kann ein 2-Weg-Datengerät umfassen, wie dass RIM Blackberry oder das Motorola CreataLink, welche mit dem Steuerungsmodem über eine serielle Verbindung verbunden sind.
Das Verkehrsmodem 310 ist so ausgewählt, dass es über ein kabelloses Netzwerk unter Verwendung eines besonderen Wireless-Standard arbeiten kann. Zum Beispiel kann das kabellose Netzwerk AMPS, iDEN, CDMA, TDMA, GSM, ARDIS, MOBITEX, oder CDPD sein. Es wird angemerkt, dass Diese Standards als Beispiele aufgelistet sind und den Umfang der Erfindung nicht einschränken sollen. Es ist den Fachleuten gut bekannt, dass andere Wireless-Netzwerk-Standards, wie W-CDMA, PHS, i-Burst, NAMPS, ETACS, WLL, UMTS, TETRA, und NMT ebenfalls unterstützt werden können, nur um einige Beispiele mehr aufzuzählen.
Das Verkehrsmodem 310 kann mehr als einen Wireless-Standard verwenden. Zum Beispiel, QUAL-COMM-Hersteller Dual-Modus Telefone, welche den CDMA- und auch den AMPS-Betrieb unterstützen. Zusätzlich ist es möglich, wenn das Verkehrsmodem 310 angepasst ist, ein Software-definiertes Radio zu verwenden, dann ist es möglich, alle der oben erwähnten Standards, die eine einzige Hardware-Plattform verwenden, zu implementieren.
Das Steuerverbindungsmodem 308 ist auch so ausgewählt, dass es über ein kabelloses Netzwerk arbeiten kann, wobei ein besonderer Wireless-Standard verwendet wird. Zum Beispiel kann das kabellose Netzwerk ebenfalls AMPS, iDEN, CDMA, TDMA, GSM, ARDIS, MOBITEX, oder CDPD sein. Ein primärer Faktor bei der Auswahl eines Wireless-Standards für das Steuerverbindungsmodem ist die Preisgestaltungspolitik für die Übertragung von Steuerverbindungs-Informationen.
3c zeigt eine andere Architektur für die ferne Einheit 300 mit einem Steuerverbindungsmodem und mehreren Verkehrsmodems 310-1–310-N 3c unterscheidet sich von 3b da sie mehrere Verkehrsmodems statt ein einziges Verkehrsmodem hat. Die Architektur der fernen Einheit 300 von 3c umfasst eine Steuerungseinheit 302, welche mit einer Lokalisierungseinheit 304, einem Steuerverbindungsmodem 308, und den Verkehrsmodems 1 (310-1) bis N (310-N) verbunden ist.
3d erläutert eine ferne Einheit, welche mehrere Peripherien umfasst. Die Architektur der fernen Einheit 300 von 3d umfasst eine Steuerungseinheit 302, welche mit einer Lokalisierungseinheit 304, einem Steuerverbindungsmodem 308, Verkehrsmodems 1 (310-1) bis N (310-N, einer Ersatzbatterie (Absicherung der Stromversorgung) 312, einem externen Speicher 314, einem Wireless-LAN-Gerät 316, und einem RF-Scanner 318 verbunden ist. Die Lokalisierungseinheit 304, das Steuerverbindungsmodem 308, und die Verkehrsmodems 1 (310-1) bis N (310-N) werden in gleicher Weise verwirklicht, wie dies oben unter Bezugnahme 3c diskutiert wurde.
Die Absicherung der Stromversorgung 312, dargestellt in 3d, stellt der fernen Einheit 300 Energie zur Verfügung, wenn die Hauptenergieversorgung ausfällt. Wenn die ferne Einheit 300 in einem Fahrzeug montiert ist, wird die Absicherung der Stromversorgung 312 verwendet, wenn die Fahrzeugzündung ausgeschaltet ist, um sicherzustellen, dass die fernen Einheit 300 nicht die Fahrzeugbatterie erschöpft, wenn das Fahrzeug geparkt ist. Wenn die ferne Einheit 300 an einem stationären Standort montiert ist, kann die Absicherung der Stromversorgung 312 verwendet werden, um Energie zur Verfügung zu stellen, wenn die Hauptenergie wegen einem Stromausfall im Gebäude unterbrochen ist. Die Absicherung der Stromversorgung 312 umfasst eine Batterie und einen Batterielader. Die Batterie kann aus verschiedenen bekannten Wiederaufladungstechnologien bestehen, wie verkapselte Blei/Säure, NiCad, NiMH, und Lithium, zum Beispiel.
Der externe Speicher 314 stellt eine temporäre Speicherkapazität für Daten zur Verfügung; die nicht unmittelbar zum Back-End-Prozessor 224 zurück gesendet werden. Es gibt verschiedene Gründe für die Speicherung der Daten auf einem externen Speicher 314. Zum Beispiel wenn die Layer 3 Netzwerkdaten für das kabellose Netzwerk sammelt, ist es möglich, die 1 Mbyte/Stunde/Datentechnologie zu verwenden. Es kann prohibitive teuer sein, diese umfangreichen Daten zum Back-End-Prozessor 224 via das Steuerverbindungsmodem 308 zurück zu senden. Folglich können die Daten lokal in einem externen Speicher 314 gespeichert werden und zu einem späteren Zeitpunkt unter Verwendung eines alternativen Pfades gedownloadet werden.
In einem andern Beispiel können die gesammelten Daten für die Übertragung in eine Warteschlange gestellt werden, wenn die Fahrzeugzündung ausgeschaltet ist. Es kann bevorzugt sein, die gespeicherten Daten nicht zu übertragen bis die Zündung wieder eingeschaltet ist, um eine unnötige Erschöpfung der Batterie, des Mechanismus der Absicherung der Stromversorgung 312 zu vermeiden. Demnach können die Daten lokal im externen Speicher 314 gespeichert werden und in eine Warteschlange gestellt werden zur Übertragung zum Steuerverbindungsmodem 308 zu einem späteren Zeitpunkt, wenn die Zündung des Fahrzeugs eingeschaltet ist.
Es ist den Fachleuten gut bekannt, dass der externe Speicher 314 auf verschiede Arten realisiert werden kann. Zum Beispiel kann der externe Speicher als PCMCIA-Flashcard realisiert werden, die in einer PCMCIA-Anschlussdose der Steuerungseinheit eingesteckt werden kann. In einem andern Beispiel kann der externe Speicher 314 ein SANdisk sein, der mit der Steuerungseinheit über ein eigenes Verbindungselement verbunden ist. Alternativ wird der Speicher 314 unter Verwendung eines sich drehenden Speichergeräts realisiert, wie einer speziellen Festplatte, zum Beispiel eines PCMCIA-Festplattenmoduls. In mobilen Umgebungen wird jedoch bevorzugt, einen externen Speicher ohne bewegliche Teile zu verwenden um die Zuberlässigkeit der fernen Einheit zu verbessern.
Das Wireless-LAN-Gerät 316 erlaubt Hochgeschwindigkeits-Datenübertragungen über kurze Distanzen. Das Wireless-LAN-Gerät 316 ist zum Beispiel unter Verwendung der Bluetooth-Technologie implementiert. Das Wireless-LAN-Gerät 316 stellt einen alternativen Pfad für das Downloaden der Daten zur Verfügung, die im externen Speicher 314 gespeichert sind. Wenn zum Beispiel die ferne Einheit 300 in einem Taxi montiert ist, und die Layer 3 Wireless-Netzwerkdaten von einem früheren Sammelvorgang gespeichert sind, dann ist das Wireless-LAN-Gerät 316 frei mit einem Wireless-LAN-Controller (nicht dargestellt) zu kommunizieren, der sich im Taxi Abfertigungszentrum befindet, um die Daten zum Back-End-Prozessor 224 zurück zu übertragen. In einem alternativen Beispiel, kann das Wireless-LAN-Gerät 316 zur Kommunikation mit einem lokalen I/O-Gerät (nicht dargestellt verwendet werden, welches in einem Lieferlastwagen zum Einsatz gelangt, um die Kommunikation mit einer zentralen Abfertigungsstelle und dem Führer des Lieferlastwagen zu erlauben.
Der RF-Scanner 318 erlaubt der fernen Einheit 300 eine verbesserte Funktionalität durch Erhöhen der Fähigkeiten zum Durchführen der RF-Optmierung des kabellosen Netzwerks. Der RF-Scanner 318 erlaubt das Sammeln von mehr RF-Daten als dies traditionell durch Verkehrsmodems (310-1–310-N) möglich ist. Der RF-Scanner 318 hat zum Beispiel eine viel höher flexible Eingabebandbreite, das sie nicht gezwungen ist, auf dem kabellosen Netzwerk einen einzigen Verkehrskanal abzuhören. Zusätzlich kann der RF-Scanner 318, wenn für die CDMA-Sammlung optimiert ist, mehrere nützliche CDMA-Netzwerk-Parameter sammeln, wie das Messen des Io im Kanal, Reduktion der Breite des Verbreiterungscodes, Messen des Ec/Io, und messen der Chipverzögerung. Der RF-Scanner 318 kann durch die Verwendung eines im Handel erhältlichen Scanners oder durch die Entwicklung eines speziellen Scanners implementiert werden, zum Beispiel durch Verwendung eines Software definierten Radios.
4a zeigt eine Hardware-Implementierung der fernen Einheit 400 durch Verwendung einer Laptop- oder Handheld-Einheit 402. Die Laptop- oder die Handheldeinheit 402 ist mit einem GPS-Empfänger 404, einem Steuerverbindungsmodem 408, und Verkehrsmodem 410 verbunden. Die Laptop oder Handheldeinheit läuft zum Beispiel mit mehreren Betriebssystemen, wie Windows 95/NT/CE, Linux oder Palm OS. Die Peripheriegeräte 404, 408, 410 sind mit der Laptop- oder Handheldeinheit 402 über serielle Ports, PCMCIA-Ports, Ethernet, oder USB verbunden. Je nach der Zweckmässigkeit. Die Laptop- oder Handheldeinheit 402 sollte Gerätetreiber für alle Peripheriegeräte haben, welche in das Betriebssystem eingebaut oder in einer höheren Sprache geschrieben sind. Weiter läuft die Laptop- oder Handheldeinheit 402 mit einem Hauptprogramm, das einen Auszug der Standortinformation vom GPS-Empfänger 404 erlaubt und sendet und empfängt die Kommunikation über den Steuerungs- und Verkehrskanälen.
4b zeigt eine Hardware-Implementation der fernen Einheiten unter Verwendung eines Single-Board-Computers (SBC; Einplatinenrechner). Der Single-Board-Computer kann als Standard von mehreren Anbietern gekauft werden, zum Beispiel von SBS, ADS, oder Datalogic. Alternativ kann der Single-Board-Computer für die spezifische Anwendung in der fernen Einheit konstruiert werden. 4b zeigt eine typische Architektur für den Single-Board-Computer, einschliesslich einem Mikroprozessor 420, der über eine Adresse und einem Datenbus mit einem BootROM 424, einem Flashspeicher 426, einem DRAM/SRAM 428, einem PCMCIA-Sockel 430, einem UART 432, einer USB-Schnittstelle 434, einer Ethernet-Schittstelle 436, einer CANSchnittstelle 438, einem Wireless-LAN-Gerät 440, und einer optionalen A/D & D/A Schnittstelle 442 verbunden ist. Der Mikroprozessor 420 kann auch direkte Verbindungen zu einem Temperaturfühler 444, einer Anzeige-Schnittstelle 446, und einem Mehrzweck-I/O haben. Zusätzlich kann der Single-Board-Computer einen Energierregel-Schaltkreis 448 haben, welcher mit einer geschalteten Energiequelle und der Erdung verbunden ist, und zusätzlich mit einer optionalen Ersatzbatterie 450 verbunden sein.
Es ist den Fachleuten gut bekannt, dass der Single-Board-Computer unter Verwendung einer Anzahl von verschiedenen Technologien implementiert werden kann. Zum Beispiel kann der Mikroprozessor ein StrongARM, ARM, Pentium, PowerPC, Motorola 68000, und dergleichen sein. Weiter ist eine Anzahl von Betriebssystemen erhältlich, wie Windows CE, Windows 95/98, Windows NT, Linux, Palm OS, VXWorks, OS-9, PSOS und dergleichen. Die seriellen Ports von UART 432, oder direkt vom Mikroprozessor 420, werden zur Anbindung an Peripheriegeräte, wie an das Verkehrsmodem 410 oder an den GPS-Empfänger 404 verwendet und sollten konfigurierbare Bit-Rates, Wortgrössen, Startbits, Stoppbits, Paritätsbits besitzen und die Fähigkeit haben entweder auf TTL- oder auf RS-232 Spannungsniveaus betrieben zu werden.
4c zeigt die Organisation eines Software-definierten Radios. Alle Elemente des Software-definierten Radios 460 können in irgend einer Kombination definiert werden, in Abhängigkeit der Anforderungen. Die Elemente umfassen einen RF-Scanner 462, ein Steuerverbindungsmodem 464, Verkehrsmodems 1 (466-1) bis N (466-N), a Lokalisierungseinheit 468, und ein Wireless-LAN-Gerät 470. der Vorteil der Verwendung einer softwaredefinierten Radioarchitektur besteht darin, dass sie simultan die Implementierung von mehreren Standards auf einem einzelnen Hardwaregerät erlaubt. Dies kann die Kosten der fernen Einheit stark reduzieren. Die dem Software-definierten Radio 460 zugrunde liegenden architektonischen Konzepte sind den Fachleuten gut bekannt und wurden in Artikeln in zahlreichen Zeitschriften, wie dem IEEE Communications Magazine diskutiert.
4d erläutert die Organisation der Software in der fernen Einheit. Auf dem untersten Niveau stellt das Betriebssystem 476 die Grundfunktionalität für die Hardwareplattform zur Verfügung. Die ferne Einheit kann mit verschieden Betriebssystemen arbeiten, wie beispielsweise mit Windows 95/NT/CE, Linux, Palm OS, VXWorks, QNX, oder pSOS. Weiter ist es je nach den Anforderungen möglich ohne Betriebssystem zu arbeiten und Plattform-spezifische Codes zu schreiben um die Routinen des untersten Niveaus zu implementieren.
Auf dem nächsten Niveau, umfasst die Software der fernen Einheit Gerätetreiber 478, Utilities 480, Protokolle 482 und Benutzerinterfacemodule 484. Die Gerätetreiber 478 erlauben die Kommunikation mit den Peripheriegeräten, wie beispielsweise dem GPS-Empfänger 404 und den kabellosen Modems. Die Utilities 480 unterstützen die Funktionen der unteren Niveaus, wie beispielsweise die Verschlüsselung und Kompression. Die Protokolle 482 unterstützen irgend ein Protokoll, welches in der fernen Einheit benötigt wird, wie zum Beispiel ein WAP-Browser, TCP/IP, X.25, und jegliche eigenen Paket-Protokolle. Das Benutzerschnittstellenmodul 484 umfasst alle für die lokale Steuerung der fernen Einheit erforderlichen Funktionalitäten, wie ein einfaches Menusystem. Es ist den Fachleuten gut bekannt, dass einige oder alle Module auch im Betriebssystem eingebaut sein können.
Auf dem nächsten Niveau, umfasst die Software der fernen Einheit mehrere zusätzliche Module, wie ein Vorverarbeitungsmodul 486, ein DB/Speichermodul 488, und ein softwaredefiniertes Radiomodul 490. Das Vorverarbeitungsmodul 486 kann zum Vorverarbeiten der gesammelten Daten verwendet werden. Dies ist besonders hilfreich in einem Betriebsszenario wo grosse Datenmengen gesammelt werden und reduziert werden müssen um die Steuerverbindungsbandbreite zu erhalten. Das DB/Speichermodule 488 kann verwendet werden um die verlangten Aufträge und/oder die gesammelten Daten zu speichern und zu organisieren. Das softwaredefinierte Radiomodul 490 wird wie oben beschrieben implementiert unter Bezugnahme auf 4c.
Die Hauptanwendung 492 ist auf dem nächsten Niveau und führt die Routinen der höheren Niveaus aus. Die Hauptanwendung 492 wird beispielsweise verwendet um Aufträge über die Steuerverbindung zu erhalten, die Aufträge auszuführen, und die Auftragsdaten über die Steuerverbindung zu übertragen.
In den oben beschriebenen Implikationen ist die Steurungseinheit 302 als Mehrzweckcomputer in Form einer Laptop- oder Handheldeinheit 402 dargestellt. Obschon dies bezüglich der Flexibilität der Programmierung gewisse Vorteile hat, kann die Erfindung ebenfalls ausgeführt werden, indem anstelle der Mehrzweckcomputer Computer für einen speziellen Zweck verwendet werden.
IV. DER BACK-END-PROZESSOR
5a zeigt die Architektur des Back-End-Prozessors 500. Der Back-End-Prozessor 500 umfasst folgende verarbeitende Elemente: Flottenmanagement 502, Testverkehrsgenerator 504, Post-Prozessor 506, Benutzerschnittstelle 508, Portal 510, Kartierung 512, und Verrechnung und Buchhaltung 514. Diese verarbeitenden Elemente sind durch ein Datennetzwerk 516 untereinander verbunden. Es ist den Fachleuten gut bekannt, dass das Datennetzwerk 516 ein LAN, WAN, Wechselverarbeitungs-Kommunikationen innerhalb des Computers oder einem Netzwerk, oder irgend einer Kombination des oben angegebenen sein kann.
5b zeigt die Architektur des Back-End-Prozessors 500. Der Back-End-Prozessor 500 umfasst folgende verarbeitende Elemente: Flottenmanagement 530, Testverkehrsgenerator 532, Post-Prozessor 534, Benutzerschnittstelle 536, und Portal 538 einschliesslich ein Kartierungselement 538a und ein Verrechnungs- und Buchhaltungselement 538b. Zusätzlich ist das Flotten-Management-Element 530 mit einer Sammeldatenbank 540, einer Missionsdatenbank 542, und einer Datenbank der fernen Einheit 544 verbunden; Das Postprocessing-Element 534 ist mit einer Postprocess-Datenbank 546 und der Sammeldatenbank 540 verbunden, und das Portal 538 ist mit einer Kartierungsdatenbank 548 und einer Verrechnungs- und Buchhaltungsdatenbank 550 verbunden.
140. Das Flottenmanagementelement 530 ist die Hauptschnittstelle im Back-End-Prozessor für das Kommunizieren mit den fernen Einheiten. Das Flottenmanagement-Element behält die Spur der fernen Einheiten, indem es auf die Daten der Datenbank 544 der fernen Einheiten zugreift, indem es die Missionsplanung und die Koordination durchführt, auf Basis von Informationen, die von der Benutzerschnittstelle 536 zur Verfügung gestellt werden, indem es Informationen zum Testverkehrsgenerator 532 sendet und empfängt, um Anrufe terrestrischen Ursprungs zu erzeugen, und indem es Befehle sendet und empfängt und den fernen Einheiten über die Steuerverbindung antwortet.
Das Flottenmanagement-Element 530 empfängt Auftragsanfragen von der Benutzerschnittstelle 536 und speichert die Information in der Auftragesdatenbank 542. Es führt dann eine Terminplanungsfunktion auf Basis der verlangten Aufträge durch, die in der Auftragsdatenbank 542 gespeichert sind, im Vergleich mit den erhältlichen fernen Einheiten, wie bestimmt durch die Zugänglichkeitsinformation, die in der Datenbank 544 der fernen Einheit gespeichert ist. Die geplanten Aufträge sind in der Auftragsdatenbank 542 als verlangte Aufträge gespeichert und werden zur richtigen Zeit über die Steuerverbindung zu den fernen Einheiten gesendet. Die verlangten Aufträge können gespeichert und als Batch von Aufträgen oder als individuelle Aufträge gesandt werden, je nach den Anforderungen.
Die Information, die durch das Flotten-Management-Element 530 empfangen wird, wird in der Sammeldatenbank 540 gespeichert und an das Postprozessorelement 534 gesandt, welches die rohen Auftragsdaten speichert und auch die Nachverarbeitung durchführt und die Nachverarbeitungsresultate speichert.
Die Nachverarbeitung umfasst die Verarbeitung der empfangenen Daten für jeden RF/Netzwerk-Parameter, der im Zusammenhang mit dem kabellose System oder der statistische Information steht, die sich auf den kabellosen Datenzugang bezieht.
Die Analyse der RF/Netzwerk-Parameter kann auf verschiedene Arten durchgeführt werden, wie diejenigen, die beschrieben sind in der Provisional US Patent Application No. 60/149,888 mit dem Titel "Wireless Telephone Network Optimization" die am 19. August 1999 eingereicht wurde, und auf welche hier in ihrer Gesamtheit für alle Zwecke Bezug genommen wird. Diese provisorische Offenbarung stellt eine Simulationsumgebung zur Verfügung um optimale empfangsbezogene (coverage-related) Parameter für Sektoren eines kabellosen Netzwerks zur Verfügung zu stellen. Diese Simulationsumgebung erlaubt einem Netzwerk-Ingenieur Parameter eines virtuellen Modells eines kabellosen Netzwerks zu variieren und zu beobachten wie die Änderungen den Empfang beeinflussen. Die provisorische Offenbarung stellt weiter einen Optimierungs-Algorithmus zur Verfügung um Hand-Off-Zeiteinteilungsparameter für Sektoren in einem kabellosen Netzwerk zur Verfügung zu stellen. Der Optimierungs-Algorithmus analysiert gemessene Daten in Bezug auf den Netzwerkempfang und das regionale Gebiet um zu einem Bericht zu gelangen, der empfohlene Werte für die Fenstergrössen-Parameter (code division systems) oder Zeit-Fortschritt-Parameter (time division systems) enthält.
Die Nachverarbeitung für die statistische Analyse umfasst den kabellosen Datenzugang, der unter Verwendung des Verkehrsmodems in der fernen Einheit erreicht wird. Die statistische Analyse erlaubt die Kombination von verschieden gesammelten Informationen um Berichte für spezifische Kunden zu produzieren. Zum Beispiel, wird die Latenz von WAP-Zugängen auf einem spezifischen URL über verschiedene unterschiedliche Netzwerke gemessen und als Balkengraphik dargestellt. Weitere Beispiele von statistischer Analyse und Berichtsgeneration werden im Betriebsabschnitt unter Bezugnahme auf 8a–8f diskutiert.
Das Benutzer-Schnittstellenelement 536 ist mit dem Flottenmanagement-Element 530 verbunden um die Aufträge zu planen auf Basis der vom Kunden vorgegebenen Parameter. Zusätzlich ist das Benutzer-Schnittstellenelement 536 mit dem Nachverarbeitungs-Element 534 verbunden, um den Benutzern spezielle Abfragen, den Zugang zu vorher gespeicherten Abfragen, den Zugang zu Berichten, die aus den nachverarbeiteten Daten erzeugt wurden, zu erlauben. Das Benutzerschnittstellenelement 536 ist auch mit dem Portal 538 verbunden um für die Kunden 560 Zugang von einem verbundenen Datennetzwerk, wie dem Internet 562, zu erlauben.
Das Portalelement 538 wirkt als Betriebssystem, das verschiedene low-level Funktionen für mehrere Applikationen zur Verfügung stellt. Das Portal 538 umfasst ein Kartierungselement 538a und ein Verrechnungs- und Buchhaltungselement 538b. Das Portal 538 ist mit den Datenbanken 548, 550 für die Kartierungsinformation und die Verrechnungs-Buchhaltungs-Information verbunden. Zusätzlich ist das Portal 538 mit dem Datennetzwerk 562, wie dem Internet verbunden, um dem Kunden den Eingang in das System zu erlauben. Das Portal ist auch mit dem Nach-Prozessor 535 verbunden um zum Beispiel den Zugang zu den nachverarbeiteten Daten für die Visualisierung mit der Kartierungs-Software zu erlauben.
5c zeigt die Architektur für das Portal 570 in Übereinstimmung mit einer Ausführungsform der Erfindung. Das Portal 570 arbeitet als Betriebssystem, das gewöhnliche low-level-Funktionen für eine Vielzahl von Anwendungen zur Verfügung stellt und als Schnittstelle für den Kundenzugang durch das Internet wirkt. Die Portal 570-Funktionen sind in vier Hauptgruppen organisiert: Datenbanken 572, GUI-Steuerung 574, Arbeitsgruppenfunktionen 576, und Sicherheit 578. Die Datenbank 572-Funktionen umfassen das Gelände, die Morphologie, Gebäude, und Verrechnung und Buchhaltung. Die GUI-Steuerungen 574 umfassen Kartierung/GIS, Diagramme, und virtuelle Realität. Die Arbeitsgruppenfunktionen 576 umfassen die Zugangskontrollen und den gängigen Dialog. Die Sicherheitsfunktionen 578 umfassen das Login, Partitionierungs-, und Prüfungsspuren. Das Portal umfasst auch ein API 580, welches den Zugang zu verschiedenen Anwendungen erlaubt.
IV. STEUERVERBINDUNGS-KMMUNIKATIONSPROTOKOLL
Die Steuerverbindung erlaubt Kommunikationen zwischen den mehreren fernen Einheiten und dem Back-End-Prozessor. Es ist eine Anzahl von möglichen Protokollen für die Steuerverbindung möglich. Das Kommunikationsprotokoll kann ein Standardprotokoll sein, wie z.B. TCP/IP, WAP, oder X.25, oder ein eigenes Protokoll, welches für die erforderlichen Kommunikationen optimiert ist, oder einige Kombinationen eines Standard- und eines eigenen Protokolls.
Gemäss einer Ausführungsform der Erfindung, wird ein eigenes Paketprotokoll verwendet. Eine Auflage bezüglich des Paketprotokolls ist die Auflage der Anerkennung für Pakete.
151. Die Rückmeldungen können auf verschiedene Weise gehandhabt werden. Sie können als individuelle Pakete gesandt werden für jedes gesandte Hauptpaket. Dies ist der kräftigste Mechanismus, er ist jedoch in seiner Bandbreite ineffizient. Alternative Rückmeldungen können als Feld eines darauf folgenden Pakets gesandt worden, wobei ein Paketnummerierungsschema verwendet wird um anzugeben, welches vorhergehende Paket rückgemeldet wurde. Dieses Verfahren erfordert mehr Overhead bei jedem Ende der Kommunikationsverbindung, um die Spur der vorher gesandten Pakete zu halten, ist jedoch bezüglich der verwendeten Bandbreite effizienter. Als andere Alternative kann das Rückmeldungssystem durch das Kommunikationssystem selbst gehandhabt werden, so dass das Paketprotokoll das Thema nicht ansteuern muss. Zum Beispiel haben viele der Zwei-Weg-Datensysteme ein eingebautes Rückmeldungssystem, so dass die Paketzustellung virtuell garantiert ist. In diesem Fall ist es nicht erforderlich, Rückmeldungen in das Paketprotokoll einzuschliessen, da sie auf einem andern Niveau gehandhabt werden.
Es gibt zwei Grundtypen von Paketen: Anzeigepakete und Datenpakete.
Die Anzeigepakete stammen entweder von einer fernen Einheit oder vom Back-End-Prozessor. Einige Beispiele von Paketen, die aus fernen Einheiten stammen sind Zündung ein, Zündung aus, und Status-Update. Das Zündung-ein-Paket zeigt, dass die Fahrzeugzündung eingeschaltet worden ist und das Zündung-aus-Paket zeigt an, dass die Fahrzeugzündung ausgeschaltet worden ist. Dies Pakete werden durch den Back-End-Prozessor verwendet um die Datensammlung in einer mobilen fernen Einheit sauber zu planen. Das Status-Update-Paket zeigt den aktuellen Status der fernen Einheit an.
Einige Beispiele von Paketen die vom Back-End stammen sind die Rückstellungs- und die Statusanfrage. Das Rückstellungspaket wird verwendet um die ferne Einheit ferngesteuert zurückzusetzen. Das Statusanfragepaket wird verwendet um ferngesteuert die Statusinformation einer fernen Einheit abzufragen.
Die Datenpakete stammen entweder von der fernen Einheit oder vom Back-End-Prozessor. Die vom Back-End stammenden Datenpakete bestehen im Allgemeinen aus Auftragsanfragen und die von der fernen Einheit stammenden Datenpakete bestehen im Allgemeinen aus Auftragsdaten.
6a zeigt Beispiele einiger Felder, die aus Paketen der fernen Einheiten stammen (Daten und auch Signalisierung) 610. Einige Beispiele auf den Paketgebieten umfassen einen Pakettyp ID 610a, eine ferne Einheit ID 610b, Datum und Zeit 610c, Mitteilungsnummer 610d, Auftrags-ID-Number 610e, Standortinformation 610f, Nutzlastinformation 610g, und Checksummeninformation 610h. Das Pakettyp-ID-Feld 610a gibt den Typ des Pakets, damit der Back-End-Processor erkennt, wie das Paket für die richtigen Felder geparst werden muss. Das ID-feld der fernen Einheit 610b wird zum Identifizieren der fernen Einheit, die das Paket sendet verwendet. Das Feld für Datum und Zeit 610c gibt Datum und die Zeit der Durchführung Messung an. Das Mitteilungs-ID-Nummernfeld 610d wird verwendet um die Spur der Mitteilung zu verfolgen. Das Feld der Auftrags-ID-Nummer 610e wird von den Datenpaketen verwendet um den entsprechenden Back-End-Auftrag anzugeben, welcher die Erzeugung der Nutzlastinformation des Pakets verursacht hat. Das Standortsinformationsfeld 610f gibt den Standort der fernen Einheit zur Zeit der Datenerfassung an. Das Checksummen-Informationsfeld 610h wird verwendet um die Integrität des Datenpakets-Information sicherzustellen. Der Ausdruck Checksummme wird allgemein für irgend eine Art der Fehlerkorrektur und/oder des Fehlernachweises zur Sicherstellung der Integrität der Datenpakete verwendet.
Das Informationsfeld 610g betreffend das aus der fernen Einheit stammende Nutzlastinformationspaket kann viele Formen annehmen. Es kann Rufstatistiken, wie die korrekte Zeit, die Anrufdauer, ob der Anruf keine Verbindung erstellen konnte oder angenommen wurde, und dergleichen umfassen. Zusätzlich kann es grundlegende RF-Engineering-Messungen umfassen, wie RSSI, BER, FER, SQE, und dergleichen. Im Weiteren können die Nutzlastinformationen die Layer 3-Informationen umfassen, welche die Ruf-Routing-Daten und -Informationen bezüglich der Konfiguration des kabellosen Netzwerks offenlegen. Die Layer 3-Informationen können durch Vorverarbeitung in der fernen Einheit vollständig oder gefiltert gesammelt werden, je nach der gewünschten Informationsmenge. Zusätzlich kann die Nutzlast Anwendungsinformationen, wie die Latenz für den Zugang zur aWAP-Seite oder der Verzögerung des Empfangs einer SMS-Mitteilung umfassen.
6b zeigt Beispiele einiger der Felder in Paketen, die vom Back-Endprozessor stammen (beide: Daten und Signalisierung) 620. Einige Beispiele von Paketfeldern umfassen einen Pakettyp ID 620a, eine ID 620b der fernen Einheit, Datum und Zeit 620c, Mitteilungsnummer 620d, Auftrags-ID-Nummer 620e, Nutzlastinformation 620f, und Checksummeninformation 620g. Das Pakettyp-ID-Feld 620a gibt den Typ des Pakets an, damit die ferne Einheit weiss, wie das Paket für die eigenen Felder zu parsen ist. Das ID-Feld 620b der fernen Einheit wird verwendet um die die von der fernen Einheit empfangenen Pakete zu identifizieren. Das Datum-und-Zeit-Feld 620c zeigt das Datum und die Zeit der Sendung des Pakets an. Das Mitteilungsnummmernfeld 620d wird verwendet um die Spur der Mitteilung für Bestätigungszwecke zu halten. Das Auftrags ID-Nummernfeld 620e wird verwendet um den Back-Endauftrag anzugeben, der die Erzeugung der die Nutzlastinformation des Back-Ends angibt. Das Checksummeninformationsfeld 620g wird verwendet um die Integrität der der Paketsummeninformation sicherzustellen. Der Ausdruck Checksumme wird generisch verwendet um sich auf irgend einen Typ der Fehlerkorrektur und/oder eine Fehlernachweismethode zu beziehen um die Inergrität der Paket-Integrität sicherzustellen
Das Feld 620f der vom Back-End-Prozessor stammenden Nutzlastinformation kann eine Anzahl von Formen annehmen. Es kann eine Auftragsinformation sein die sich auf den Typ der gesammelten Daten bezieht, einschliesslich dem Typ des Zugangs (WAP, schaltkreisgeschaltete Daten, etc), einen Auslöser de sich auf die Zeit (oder Zeitbereiche) bezieht, um den Testanruf zu machen, eine Auslöser, der sich auf den Standort (oder Standortbereiche) bezieht um den Testanruf zu machen, ein kabelloses Testsystem (wenn die fernen Einheiten mehrfache Verkehrsstandards unterstützen), eine Zieltelefonnummer oder -URL, und ob der Anruf mobil oder vom Festnetz stammt.
Es sollte beachtet werden, das die oben beschriebenen Paketfeldertypen nur zur Erläuterung angegeben sind und die aktuellen Felder, welche verwendet werden können, in keiner Weise einschränken.
Die Informationen im Paket können entweder als ASCII oder als binäre Datei gesandt werden. ASCII ist nützlich, da einige Zwei-Weg-Systeme für das Paging verwendet werden und nur ASCII Textinformationen durchlassen. Die binäre Speicherung ist nützlich, da Sie mehr bandbreiteneffizient ist als ASCII. Im Weiteren kann die Paketinformation durch eine Anzahl von Standardmethoden komprimiert werden, wie Null-Kompression, Lauf-Längen-Kompression, Passwort-Dekodierung, adaptive Huffman Kodierung, Lempel-Ziv-Kodierung, und dergleichen. Zusätzlich kann die Paketinformation durch eine Anzahl von Standardverfahren entschlüsselt werden, wie DES, Tripel-DES, RSA, PGP, und dergleichen.
Gemäss einer Ausführungsform der Erfindung werden die Pakete in grösseren Dateien für die Übertragung über die Steuerverbindung kombiniert. Dieses ist vorteilhaft in einer Umgebung in welcher das Steuerungsnetzwerk eine fixierte Ladung pro Paket belastet. Demzufolge können grössere Dateien kostenwirksamer sein. Weiter kann es vorteilhaft sein, die gesammelten Informationen für eine spätere Übertragung auf einer fernen Einheit zu speichern. Dies kann vorkommen wenn die Layer 3-Informationen gesammelt werden, da die Daten schneller gesammelt werden können, als sie über die Steuerverbindung gesandt werden kann. Zusätzlich können die gesammelten Informationen auf der fernen Einheit gespeichert werden, wenn die Fahrzeugzündung während dem Auftrag in mobiler Umgebung ausgeschaltet ist. Dies kann vorkommen, weil das System versucht die Übertragungen zu reduzieren, wenn die Zündung ausgeschaltet ist, um die Lebensdauer der Batterie auszudehnen.
V. MESSMETHODE
7a zeigt eine Methode zur Messung der Datenqualität des Dienstes in einem kabellosen Netzwerk. Die Methode umfasst die Schritte des Sendens von Befehlsinformationen 702, der Durchführung von Messungen 704, und des Empfangs von Antwortinformationen 706.
Zum Beispiel kann das Senden von Befehlsinformationen 702 die Verwendung eines Back-End-Prozessors umfassen um entweder Daten oder Signalisierungspakete an die fernen Einheiten eines Messsystems, wie eines der oben beschriebenen, zu senden. Im Weiteren kann der Schritt der Durchführung von Messungen 704 die Durchführung einer Anzahl von Messungen umfassen, der Latenz des kabellosen Internetzugangs, der e-Commerce-Transaktionen, der Kabellosen Nachrichtenübertragung, oder von Push-Technologien. Der Schritt des Empfangs von Nachrichteninformationen 706 kann Antworten auf Statusanfragen oder Daten umfassen, die auf die Anfragen oder Daten beziehen, die während dem Schritt der Durchführung von Messungen 704 gesammelt werden.
7b zeigt ein Verfahren für die Messung der Datenqualität von Diensten in einem kabellosen Netzwerk, einschliesslich mindestens eines Schrittes, der sich auf die kabellose Netzwerkinfrastruktur bezieht. Das Verfahren umfasst die Sende-702, Ausführungs-704, und Empfangs 706-Schritte, welche unter Bezugnahme auf 7a beschrieben sind. Zusätzlich umfasst das Verfahren die Schritte der Überwachung eines WAP-Gateways 710 und des Benchmarkings in einem WAP-Gateway 712.
Der Schritt der Überwachung des WAP-Gateway 710 kann die Überwachung des Verkehrs durch den WAP-Gateway umfassen und Messmittel, wie Durchsatz, Latenz und Information der verlorene Pakete zur Verfügung stellen. Weiter kann der Überwachungsschritt 710 die Sammlung von Protokoll-Informationen erlauben, direkt vom WAP-Gateway, der für die mehreren fernen Einheiten nicht erhältlich zu sein braucht. Der Schritt des Benchmarking am WAP-Gateway 712 kann Latenzmessungen erlauben, ohne das Unsicherheiten der Latenz durch das Internet oder das Datennetzwerk selbst eingeschlossen sind. Dies erlaubt das Vorlegen von Daten, welche einen Zusammenbruch zwischen der Latenz des kabellosen Netzwerks und dem Datennetzwerk angeben
Es ist wichtig festzustellen, dass im Hinblick auf die Schritte 710 und 712 die Geschlossenheit des WAP-Gateway von einem logischen und nicht von einem physikalischen Standpunkt aus beschrieben ist. Es wird von den gewöhnlichen Fachleuten anerkannt, dass diese Prozessschritte mit wohlbekannten Technologien durchgeführt werden können, in welchen das Überwachungs- oder Benchmarkingelement sich vom WAP-Gateway weit entfernt befindet. Weiter wird, wie vorher diskutiert wurde, der Ausdruck WAP allgemein verwendet um irgend ein kabelloses Internetprotokoll zu beschreiben, einschliesslich HDML, WAP-Wettbewerber, und all zukünftigen kabellosen Internetprotokolle, die entwickelt werden könnten.
7c zeigt ein Verfahren zum Messen der Datenqualität des Dienstes in einem kabellosen Netzwerk, einschliesslich mindestens eines zusätzlichen bestellungsunabhängigen Schrittes. Das Verfahren umfasst die Sende-702, Ausführungs-704, und Empfangs 706-Schritte, die unter Bezugnahme auf 7a beschrieben sind. Zusätzlich umfasst das Verfahren die Schritte des Zugangs vom Internet 720, Planungsmissionen 722, Erzeugung von Testverkehr 724, Speichern auf einer fernen Einheit 726, Vorverarbeitung auf einer fernen Einheit 728, Nachverarbeitung auf den Back-End 730, und Organisation der Informationen auf der fernen Einheit 732.
Der Schritt des Zugangs vom Internet 720 kann die Fähigkeit umfassen einen Zugang zum Messsystem durch ein Portal vom Internet herzustellen, um die Aufträge festzusetzen und Berichte zu generieren, zum Beispiel aus den nachverarbeiteten Daten. Der Schritt der Planung der Aufträge 722 kann das Festlegen von Parametern umfassen, welche sich auf die spezifischen Daten beziehen, die durch das System gesammelt werden. Zum Beispiel können diese Parameter etwas des Folgenden umfassen: Zugangsart – WAP, SMS, Instant Messaging, Push-Daten, und dergleichen; Geräteart – WAP, PDA, Pager, kabelloses Modem, und dergleichen.; Auslöser – Rufzeit, Standort der fernen Einheit oder eine Kombination; kabelloses System – Sprint, Nextel, AT&T, und dergleichen.; Ruf-Info – Ziel-Telefonnummer, URL, Transaktionszeit, etc.; und mobile der Festnetzanrufe. Der Schritt der Erzeugung von Testverkehr 724 kann die Erzeugung von SMS Mitteilungen oder zum Beispiel von andern Datenpaketen umfassen, die an ferne Einheiten zu senden sind.
Der Schritt der Speicherung auf der fernen Einheit 726 kann die Speicherung von Aufträgen und von gesammelten Daten auf der fernen Einheit umfassen. Der Schritt der Vorverarbeitung auf der fernen Einheit 728 kann das Verarbeiten von Daten umfassen, die vor der Speicherung der Daten oder der Übertragung zum Back-End-Prozessor empfangen wurden. Der Schritt der Nachverarbeitung am Back-End 730 kann das Verarbeiten der Empfangenen umfassen, entweder für RF/Netzwerk-Parameter, die sich auf das kabellose System beziehen, oder auf statistische Informationen, die sich auf den kabellosen Datenzugang beziehen. Der Schritt des Organisierens der Informationen der fernen Einheit kann zu Beispiel die Speicherung von Informationen zur Identifikation der fernen Einheit in einer Datenbank der fernen Einheit, die Speicherung von gesammelten Daten in einer Datenbank für gesammelte Daten, oder die Speicherung von nachverarbeiteten Daten in einer Datenbank für nachverarbeitete Daten umfassen.
Es soll beachtet werden, dass die Flusspfeile in den 7a–7c nur zu Erläuterungszwecken angegeben sind und nicht einen erforderlichen Befehl für die Verfahrensschritte widerspiegelt.
VI. OPERATIONLLES UND GESCHÄFTSMODELL
In den vorgängigen Abschnitten dieser Beschreibung wurde ein Verfahren und ein System zur Messung der Datenqualität von Diensten in einem kabellosen Netzwerk beschrieben, wobei mehrere ferne Einheiten und ein Back-End-Prozessor verwendet wurden. Das Verfahren und das System kann auch ein Element umfassen, welches sich in der Infrastruktur des kabellosen Netzwerks befindet, zum Beispiel im WAP-Gateway um das Protokoll der kabellosen Daten anzuzeigen und um die Benchmarkmessungen 173 durchzuführen.
Statt die Messausrüstung als Endprodukt zu verkaufen, wird das System gemäss der Definition der Erfindung als Endprodukt bevorzugt als gesammelte Daten und Statistiken, welche von den gesammelten Daten erzeugt werden, verkauft. Der Warenname für diese Dienstleistung ist vorzugsweise "Bitwise". Die Daten und Statistiken, die durch das System generiert werden, müssen nicht "real-time" sein, sondern, wie vorher offenbart, unterstützt das System wenn gewünscht nahezu "real-time"-Daten. Typischerweise, werden die Daten über eine Zeitperiode, wie ein Tag, eine Woche, ein Monat oder sogar ein Jahr, gesammelt und analysiert, je nach den Anforderungen des Klienten.
Die Typen der gesammelten Daten umfassen Latenz, Rufstatistiken (wie Rufbeendigung, Rufabbruch, usw.), BER/FER, und verschiedene kabellose Netzwerkparameter, wie RSSI und Layer 3-Informationen. Zum Beispiel wird ist Latenzzeit ein Mass für die Zugangszeit für eine WML-Seite von einem aWAP-Server oder die Zeit um eine Webtransaktion zu beenden. Weiter kann das System die Latenzmessung aufteilen in den Beitrag des verkabelten Netzwerks und des kabellosen Netzwerks, indem eine Komponente verwendet wird, die sich im WAP-Gateway befindet.
Weiter können die fernen Einheiten verwendet werden um zusätzlich Funktionen auszuüben, welche einen Wert in vertikalen Märkten besitzen. Wenn sich die fernen Einheiten zum Beispiel im Feld einer mobilen Umgebung befinden, in einer Fahrzeugflotte, können die fernen Einheiten eine automatische Fahrzeuglokalisierung (AVL) bereit stellen, zusätzlich zur Datenqualitätsmessungen der Dienstleistungen. Zusätzlich könnten die Positionsdaten der mobilen fernen Einheit so verarbeitet werden, dass sie nahezu Realtime-Verkehrsinformationen zur Verfügung stellen, welche zum Beispiel über das Internet verbreitet werden könnten.
Es gibt eine Anzahl von möglichen Preisgestaltungs-Strategien für die Daten und Statistiken, die durch das System produziert werden. Der Verbraucher kann pro Minute Systemgebrauch oder pro Transaktion belastet werden. Alternativ kann der Verbraucher pro Stadt, pro Kabellosanbieter und pro Monat für die bezogenen Daten und Statistiken belastet werden. Weiter produziert das Nachverarbeitungselement Aggregate von industrieweiten Statistiken, zu Beispiele durch Vergleichen von verschiedenen Kabellosanbietern oder Inhaltsprovidern, welche vorzugsweise in Paketen vorliegen und als separates Produkt verkauft werden.
Die Kunden des Systems haben eine Anzahl von gemeinsamen Eigenschaften. Es sind dot.com- und e-Commerce- Gesellschaften, welche die User der Kabellosgeräte anvisieren, indem ihr Inhalt und ihr Geschäft auf Kabellos-Websites getragen wird. Weiter haben sie im Allgemeinen ein Bedürfnis für die rechtzeitige Verbreitung von Inhalt und Transaktionen und haben ein leidenschaftliche Interesse an positiver Kunden-Erfahrung.
Die Kunden können in eine Vielfalt von verschiedenen Gruppen aufgeteilt werden. Sie können Kabellosbediener sein, welche die Messung der Performance ihrer Netzwerke wünschen, um den Verkehr zu erhöhen und die Performance zu optimieren. Weiter können die Kunden kabellose Portale und/oder ISPs sein, wie AOL, Yahoo, Alta Vista, MSN, Lycos und Excite, nur um einige Beispiele zu nennen. Zusätzlich können die Kunden Content-Provider sein, in einer Vielfalt von Gebieten, wie die Servicearena, welche Finanz-, Wetter-, oder Verkehrsinhalt anbietet; die Internet-Auktionsarena, welche zeitempfindliche Anbietinformationen anbietet; die Moment-Mitteilungsarena, wie das AOL Anytime, Anywhere Programm; und die Pushdaten-Technologiearena, in welcher Informationen, wie Fluglinien-Informationen und Verkehrsaktualisierungen auf die mobilen Geräte gepushed werden.
Die Gründe, dass Kunden das System verwenden, gemäss einer Ausführungsform der Erfindung, sind ziemlich geradlinig. Es erlaubt den Kunden die kabellosen Internet-Transaktion durch die Augen der Endverbraucher zu sehen, in Bezug auf ihre Erfahrung, wenn sie auf den Inhalt zugreifen und Geschäfte von kabellosen Geräten aus abwickeln. Zusätzlich erlaubt es den Kunden ein Verfahren für die Auswertung und den Vergleich der Performance von kabellosen Netzwerken, welche den Inhalt überbringen. Weiter erlaubt es den Kabellosbedienern und den Content-Providern solide Daten um Flaschenhälse und Performanceprobleme im Netzwerk genau festzulegen. Zusätzlich liefert es Informationen um die Belegschaft wegen kritischen Dienstmängeln zu alarmieren, damit rechtzeitig Korrekturen vorgenommen werden können.
Es gibt eine Vielfalt von potentiellen Messungen, welche vorgenommen werden können. Jede Messung bezieht sich auf einen Auftrag. Einige Beispiele von Aufträgen umfassen die Abfrage einer WML-Seite, den Abschluss eines e-Commerce-Geschäfts, den Empfang von gepushten Dateninhalten, die Durchführung eines sicheren Geschäfts und die Durchführung von Benchmarking von verschiedenen Teilen des Netzwerks durch die Verwendung einer Komponente, die sich im WAP-Gateway befindet.
Es gibt eine Vielfalt von Verfahren für die Eingabe von verlangten Aufträgen. Wenn der Kunde dies wünscht, kann er seine Anforderungen mit dem System Operator diskutieren und dem System Operator erlauben die Aufträge einzugeben. Alternativ erlaubt eine Anwenderschnittstelle im Back-End-Prozessor dem Kunden die eigenen Aufträge über das Internet einzugeben, durch Eingabe über das Portal.
Die Parameter für einen Auftrag können mindestes folgende Punkte umfassen: Typ des Zugangs – WAP, SMS, Instant Messaging, Push-Daten, und dergleichen. Typ des Geräts – WAP, PDA, Pager, kabelloses Modem, und dergleichen. Auslöser – Anrufzeit, Standort der fernen Einheit, oder eine Kombination Kabelloses System – Sprint, Nextel, AT&T, und dergleichen. Call Info – Ziel-Telefonnummer, URL, Typ der Transaktion, usw. mobiler oder Festnetzursprung.
Der Output des Systems kann durch mehrfache Wege erhalten werden. Im Allgemeinen können Kunden formatierte Berichte einrichten, welche periodisch mit den angeforderten Daten und den statistischen Informationen erzeugt werden können. Die Berichte sind in vielfältiger Weise erhältlich, wie gesehen in einem Web-Browser, gesendet als Anhang an einer e-Mail, gesendet als Datei, die FTP verwendet oder irgend eine anderes Protokoll, oder gesendet via normale Post, nur um wenige Beispiele zu nennen. Die Berichte können in einer Vielfalt von Formaten angeordnet sein, je nach den Anforderungen des Kunden mit Beispielen, welche in den folgenden Figuren vorgelegt werden.
8a zeigt ein Balkengrafik-Ergebnis 810 von Download-Zeiten von verschiedenen Portalen. Die y-Achse der Balkengrafik bezieht sich auf die mittlere Downloadzeit in Sekunden und die x-Achse bezieht sich auf die Stadt, in welcher die Messung durchgeführt wurde. Die drei Balken stellen Messungen dar für Yahoo, AOL, und einen Portalindex von Messungen an allen Portalen. Die dargestellte Statistik betrifft kabellose Carrier, mit einem Messintervall von 15 Minuten zwischen 6 Uhr vormittags und 12 Uhr mittags für die Periode vom 1.3.2000 bis 7.3.2000.
8b zeigt eine Balkengrafik-Ergebnis 820 von Downloadzeiten über verschiedene kabellose Netzwerke. Die y-Achse der Balkengraphik bezieht sich auf die mittlere Downloadzeit in Sekunden und die x-Achse bezieht sich auf die Stadt in welcher die Messung durchgeführt wurde. Die drei Balken stellen Messungen für Nextel, Sprint PCS, und AT&T Wireless dar. Die dargestellte Statistik bezieht sich auf den Zugang auf Yahoo, mit einem Messintervall von 30 Minuten zwischen 6 Uhr vormittags und 9 abends, für Periode vom 1.3.2000 bis 7.3.2000.
8c zeigt ein Balkengrafik-Ergebnis 830 für den Prozentsatz der Anrufbeendigung über verschiedene kabellose Netzwerke. Die y-Achse der Balkengrafik bezieht sich auf den Prozentsatz der Anrufbeendigung und die x-Achse bezieht sich auf die Stadt in welcher sie Messung durchgeführt wurde. Die drei Balken stellen die Messungen dar für Nextel, Sprint PCS, und AT&T Wireless. Die dargestellte Statistik bezieht sich auf den Zugang auf Yahoo, mit einem Mess-Intervall von 30 Minuten zwischen 6 Uhr vormittags und 9 abends, für Periode vom 1.3.2000 bis 7.3.2000.
8d zeigt ein hochgerechnetes Grafik-Ergebnis 840 einer Anrufbeendigungen über verschiedene kabellose Netzwerke. Die y-Achse der Balkengrafik bezieht sich auf den Prozentsatz der Anrufbeendigung und die x-Achse bezieht sich auf die Stadt in welcher die Messung durchgeführt wurde. Die drei Balken stellen die Messungen dar für Nextel, Sprint PCS, und AT&T Wireless. Die dargestellte Statistik bezieht sich auf den Zugang auf Yahoo, mit einem Mess-Intervall von 30 Minuten zwischen 6 Uhr vormittags und 9 abends, für Periode vom 1.3.2000 bis 7.3.2000.
8e zeigt ein Balkengrafik-Ergebnis 850 von mittleren Downloadzeiten mit einem Zusammenbruch der Netzwerklatenz am WAP-Gateway. Die y-Achse der Balkengraphik bezieht sich auf die mittlere Downloadzeit in Sekunden und die x-Achse bezieht sich auf die Stadt in welcher die Messung durchgeführt wurde. Die Balken stellen die Messungen für Nextel dar mit einer Statistik für den Zugang auf Yahoo, mit einem Mess-Intervall von 60 Minuten zwischen 12 Uhr mittags und 12 Uhr mittags, für Periode vom 1.3.2000 bis 7.3.2000.
8f zeigt eine Tortengrafik 860 der Fehlerstatistik für den kabellosen Zugang zu Yahoo. Die Abschnitte der Tortengrafik zeigen den DNS-Nachschlagefehler, Verbindungszeitüberschreitung, Seiten-Zeitüberschreitung, Inhaltsfehler und erfolgreiche fehlerfreie Verbindungen. Die Statistik stellt eine Fehlerstatistik für alle Carrier mit Statistik dar, dargestellt für den Zugang zu Yahoo, mit einem Messintervall von 60 Minuten zwischen 12 Uhr mittags und 12 Uhr mittags, für Periode vom 1.3.2000 bis 7.3.2000.
VII. BEISPIELHAFTE AUSFÜHRUNGSFORM
Unter Bezugnahme auf 9 besitzt ein System gemäss einer beispielhaften Ausführungsform der vorliegenden Erfindung zwei Hauptkomponenten: ferne Einheiten (a.k.a. PUPPIs) 910, 920, welche Messungen durchführen bezüglich dem Internet-Gehaltszustrom über kabellose Netzwerke und einem Back-End 930, welcher die fernen Einheiten 910, 920 steuert und eine Datensammlung und -speicherung durchführt.
Die Grundsteuerung des PUPPI 910 besteht aus Befehlen, die vom Back-End 930 zum PUPPI 910 gesendet werden, und Antworten, die vom PUPPI 910 zum Back-End 930 gesendet werden. Die Befehle sind allgemeine Aufträge, die den PUPPI 910 anleiten, Daten eines besonderen kabellosen Gehalt-Providers in einer besonderen Zeitperiode zu senden. Die Antworten sind im Allgemeinen die Resultate dieser Sammelaufträge. Die technische Schnittstelle des PUPPI zur Steuerverbindung 950 ist ein Modem 912 das eine Kommunikation über eine Kommunikationsverbindung 940, erlaubt, wie PSTN, oder über ein Datennetzwerk, wie das Internet. Die Steuerverbindung 950 kann in einer verkabelten Konfiguration implementiert werden, wie in 9 dargestellt, oder in einer kabellosen Konfiguration, die ein kabelloses Modem verwendet.
Das technische Gerät des PUPPI für die Durchführung der kabellosen Messungen ist im Allgemeinen EIN Standard-Handgerät 914, das mit der PUPPI Steuereinheit über ein serielles Kabel verbunden ist. Es kann jedoch jedes kabellose Gerät verwendet werden, wie ein kabelloses Modem-Modul, PDA, RIM-Gerät, Pager, usw., je nach dem kabellosen Netzwerk, das zu testen ist. Zusätzlich wird das Software-Modul mit dem zweckmässigen WDP ausgewählt, basierend auf dem zu testenden kabellosen Netzwerk.
Unter Bezugnahme auf 10, umfassen die fernen Einheiten (PUPPIs) im beispielhaften System eine Steuerungseinheit 916 zur Steuerung der fernen Einheit, ein Testverkehrsmodem 914 für die Durchführung von Messungen auf dem kabellosen Netzwerk und ein Steuerverbindungsmodem 912 für den Durchgang von Befehlen und Antworten zwischen der fernen Einheit 910 und dem Back-End-Prozessor 930 (unter Bezugnahme auf 9).
Die Steuerungseinheit 916 kann als PC, Laptop, Handheld-Computer oder als Embedded Computer implementiert werden, nur um einige wenige Bespiele zu nennen. Das Testverkehrsmodem 914 kann als Standard-Handset oder als Modemmodul implementiert werden, eines davon sollte eine externe Antenne umfassen. Das Steuerverbindungs-Modem 912 kann als Standard-POTS-Modem (das eine reservierte Telefonleitung verwendet), ein DSL-Modem, ein ISDN-Modem oder ein äquivalentes System implementiert sein.
Die interne Hardwareschnittstelle für das PUPPI ist als RS-232 serielle Verbindung zwischen der Steuerungseinheit 916 und dem Testverkehrsmodem 914 (im Allgemeinen ein Handgerät) verkörpert. Alternativ kann die Verbindung als USB-Port, Firewire-Port, PCMCIA, oder jede andere zweckmässige Schnittstelle für das Testverkehrsmodem implementiert werden. Die interne Hardware-Schnittstelle zwischen der Steuerungseinheit 916 und dem Seuerungsverbindungsmodem 912 hängt von dem ausgewählten Steuerverbindungsmodem ab. Wenn ein Standard-V.90-Modem (56.6 kbit/s) verwendet wird, dann kann es im Gehäuse der Steuerungseinheit untergebracht werden und im PCI-Systembus eingesteckt werden, oder über eine Ethernet-Verbindung über ein LAN verbunden werden. Wenn ein DSL-Modem (oder ein anderes fortschrittliches Daten-Modem) verwendet wird, dann wird es mit der Steuerungseinheit mit einer zweckmässigen Schnittstelle verbunden. Wenn ein kabelloses Verbindungssteuerungsmodem 912 verwendet wird, wird es mit der Steuerungseinheit 916 über zweckmässige Schnittstellen, wie einem seriellen Port, kommunizieren.
Die PUPPIs im beispielhaften System sind stationäre Inneneinheiten oder mobile Einheiten, einschliesslich einer externen Kabellosantenne, unter Fernsteuerung vom Back-End, unter Verwendung einer speziellen Scriptsprache.
Das PUPPI ist so ausgestaltet um einen Abonnenten zu simulieren, der ein WAP-fähiges Handgerät oder irgend ein WDP-fähiges kabelloses Gerät verwendet. WAP Handgeräte haben Mini-Browser auf den Handgerät geladen, welche diese Funktionalität erlauben. Wegen Beschränkungen in der Fähigkeit, Daten auf dem Handgerät selbst zu steuern und zu verfolgen, kann die beispielhafte ferne Einheit die Web-Browsing-Funktionalität vom Handgerät zur Steuerungseinheit verschieben, wo eine volle Browser-Steuerung und ein Datentracking möglich ist. In diesem Fall wird das Handgerät für eine Einwahl-Netzwerkverbindung verwendet, das einen Zugang zum kabellosen Netzwerk zur Verfügung stellt und erlaubt, dass Pakete zwischen dem WAP-Browser auf der Steuerungseinheit und dem WAP-Gateway am Bedienungsschalter über das Handgerät fliessen.
Die PUPPI-Software umfasst drei Hauptprozesse, ein Test-Prozess, Ein Steuerungsprozess und ein Erfassungsprozess. Der Testprozess ist für alle Aspekte der Messung verantwortlich. Der Steuerungsprozess ist für alle Kommunikationen mit dem Back-End-System verantwortlich. Der Erfassungsprozess ist für die Erfassung aller Ereignisse von jedem Prozess und für die Alarm-Generierung verantwortlich.
Unter Bezugnahme auf 11, sind Prozesse erläutert, die Softwaremodule enthalten, die für spezifische Aufgaben verantwortlich sind.
Das Hauptsteuerungsmodul (MCM) 1104 ist für die Führung und Steuerung der PUPPI-Einheit verantwortlich. Einige Funktionen für welche MCM verantwortlich ist, sind nachstehend aufgelistet:

• Beschäftigung von Modulen mit Messungen
• Handhabung Zeiteinteilungsbelangen
• Starten und Stoppen von Messungen
• Antworten auf Diagnose-Anträge
• Empfang von Auftragslisten
• Senden von gesammelten Daten

Das Testverbindungsmodul (TLCM) 1108 steuert die Testanschlussverbindung. Die Testanschlussverbindung wird durch Datenmodule verwendet um vom kabellosen Datennetzwerk Informationen zu sammeln. Die Testanschlussverbindung umfasst eine Einwahlnetzwerkverbindung um Module zu unterstützen, die kabellose Daten benötigen, und eine direkte Handgeräteverbindung für Module, die Transportinformationen benötigen.
Das GPS-Modul (GPSM) 1112 kann gegebenenfalls umfasst werden um GPS-Informationen an den Hauptsteuerungs-Modul abzugeben. Zum Beispiel kann die Zeitinformation, die durch das GPS-Modul bereitgestellt wird, vom MCM verwendet werden um sehr genaue Zeitstempel für die gesammelten Daten bereitzustellen. Weiter kann in einer mobilen Umgebung die Standortinformation vom GPS-Modul verwendet werden um eine Standortinformation bereitzustellen. Der Ausdruck GPS wird verwendet um allgemein sich auf irgend eine Art von Positionslokalisierungstechnologie zu beziehen, einschliesslich ein vertriebenes GPS (z.B. SnapTracks) und Zeitunterschied der Ankunft oder Zeitwinkel der Ankunft (z.B. TruePosition). Diese zusätzlichen Formen von Lokalisierungsbestimmungen können die Zugabe eines Lokalisationsservers an das System umfassen.
Das WAP/WML-Datenmodul (WDM) 1116 ist verantwirtlich für die Durchführung aller WAP-bezogenen Aufgaben. Im Modul eingebettet sind WAP-Browser-Fähigkeiten vorhanden. Das WDM ist für die Handhabung aller WAP-Gateway-Login-Anfragen und Sicherheitscodewechsel verantwortlich. Wie vorher diskutiert können die beispielhaften Ausführungsformen ein WDM umfassen um Daten auf irgend einem WDP zu sammeln, je nach dem Netzwerk, welches getestet wird.
Das Transportdatenmodul (TDM) 1120 ist verantwortlich für das Sammeln aller transportbezogenen Daten, wie Signalstärke, Qualität, usw. Dieses Modul ist transportspezifisch konstruiert, und ist auf Basis der verwendeten Transporttechnologie beladen (d.h. CDMA, iDEN, TDMA, GSM, usw.). Da die Daten für jede Transporttechnologie verschieden gesammelt werden, kann das Modul parallel mit andern Moduls (z.B. iDEN) betrieben werden, oder es kann nötig sein es seriell zu betreiben, während andere Module nicht Daten sammeln (z.B.. CDMA).
Das SMS-Module (SMSM) 1124 ist verantwortlich um SMS-Informationen zu sammeln, die sich auf ein spezifisches kabelloses Netzwerk beziehen. Zum Beispiel kann die SMS-Mitteilung entweder übertragen oder empfangen werden durch das Modul. Das SMS-Module ist fähig den Unterschied zwischen der Zeit der SMS-Übertragung und Empfang zu verfolgen um die Latenz des Systems zu bestimmen.
Das PDA-Modul (PDAM) 1128 ist verantwortlich für das Sammeln von Informationen, die sich auf den PDA-Zugang von Daten über ein kabelloses Netzwerk beziehen. Die möglichen zu verwendenden PDAs können Palm, Pocket PC, Handspring, RIM, usw. umfassen, sind jedoch nicht darauf eingeschränkt.
Das Push Notification Modul (PNM) 1132 ist verantwortlich für das Sammeln von Informationen, die sich auf Daten beziehen, die über ein kabelloses Netzwerk zum fernen Gerät gepushed werden. Zum Beispiel umfasst der Phone.com-Gateway eine Utility für das Pushen von Daten zum fernen Gerät unter Verwendung von WAP. Es gibt eine Vielfalt von andern Wegen, über welche Daten zum fernen Gerät gepushed werden können.
Das passive Überwachungs-Modul (PMM) 1136 ist verantwortlich für das Sammeln von Informationen, die sich auf die passive Überwachung eines kabellosen Netzwerks beziehen. Dies ist verschieden von der Latenz-Messungsfunktion, da kein Bedarf an einem Prozess für die Generation von irgendwelchen Informationen besteht (d.h. es ist nur die Überwachung und der passiven Empfang von Informationen nötig). Zum Beispiel hört das PMM den Steuerungskanal und sammelt Layer 3-Informationen.
Das kabellose Web-Daten-Modul (WWDM) 1140 ist verantwortlich für die Durchführung von Aufgaben, die sich auf den gewählten kabellosen Web-Standard beziehen. Dieses Modul ist dem WAP/WML-Modul ähnlich, wird aber in Netzwerken verwendet, in welchen andere kabellose Web-Protokolle (wie HDML, i-MODE, usw.) verwendet werden, statt WML. Diese Protokolle werden generell als WDP (Wireless Data Protocol) bezeichnet.
Das HTML-Daten-Modul (HTDM) 1144 ist verantwortlich für die Durchführung von HTML Aufgaben. Dieses Modul ist ähnlich wie das WAP/WML-Modul, wird aber in Netzwerken verwendet, in welchen HTML statt WML verwendet wird.
212. Das E-Mail-Daten-Modul (EDM) 1148 ist verantwortlich für die Durchführung von e-Mail-Aufgaben. Dies umfasst die Fähigkeit sowohl e-Mails zu senden und auch zu empfangen auf dem fernen Gerät über das kabellose Netzwerk.
Das FTP-Daten-Modul (FDM) 1152 ist verantwortlich für die Durchführung von FTP-Aufgaben, welche die Übertragung von Dateien umfassen. Obschon dieses Modul als FTP bezeichnet wird (auf Basis des TCP/IP-Datenübertragungsprotokoll), ist diese Modul fähig eine Vielfalt von Dateiübertragungsprotokollen zu implementieren, die zukünftige Protokolle umfassen, die entwickelt werden um Dateien auf kabellosen Netzwerken zu übertragen.
Das Paket-Schnüffel-Modul (PSM) 1156 ist verantwortlich für die Durchführung von Paket-Schnüffelaufgaben. Dies umfasst die Fähigkeit Paketinformationen von tiefem Niveau zu entschlüsseln und zu protokollieren, ähnlich der Funktionalität auf einem LAN-Paket-Sniffer.
Das Multimedia-Daten-Module (MMDM) 1160 ist verantwortlich für die Durchführung von Aufgaben, die sich auf die Übertragung und den Empfang von verschiedenen Multimediadaten beziehen. Zum Beispiel können die Multimediadaten Musikdateien sein, wie MP3-komprimierte Musik oder irgend eine Art von gestreamtem Video, wobei eine Vielfalt von verschiedenen Kompressionsstandards verwendet wird.
Das Status-Modul (StatM) 1164 ist verantwortlich für die Bereitstellung von Status-Informationen, die sich auf die fernen Einheit beziehen. Dies wird erreicht auf irgend einem der vielfältigen alternativen Wege. Zum Beispiel kann das Status-Modul verantwortlich sein für die periodische Bereitstellung von "Herzschlägen", welche durch den Back-End überwacht werden, um sicherzustellen, dass die ferne Einheit immer noch am Leben ist und es ihr gut geht. Diese Herzschläge können eine einfache Nachricht verkörpern, welche lediglich bestätigt, dass die Einheit am Leben ist, oder sie können durch kompliziertere Mitteilungen verkörpert werden, einschliesslich Status-Informationen, wie der verfügbare Speicher, die verwendete Speicherkapazität, die gegenwärtige Konfiguration, Temperatur, usw. Als andere Alternative kann das System durch den Back-End verkörpert werden, der die fernen Einheiten abfragt, und das Status-Modul, das auf die Anfragen reagiert. In einer weiteren Alternative kann das System sowohl Herzschläge und auch abgefragte Status-Antworten umfassen.
Das optionale Steuerungs-Verbindungs-Anschluss-Modul CLCM) 1168 führt (wenn implementiert) den Steuerverbindungsanschluss. Der Steuerverbindungsanschluss wird durch die PUPPI-Einheit verwendet um Mitteilungen von der Back-End-Software zu senden und zu empfangen. Dieses Modul ist fakultativ und kann in Implementationen weggelassen werden, welche ein höherstufiges Protokoll verwenden um die Verbindung zwischen den fernen Einheiten und dem Back-End aufrecht zuerhalten. Zum Beispiel kann, wenn auf den fernen Einheiten eine Datenbank mit Installationsinfo und gesammelten Daten läuft, der Back-End mit den fernen Einheiten kommunizieren, indem einfach auf ihre individuellen Datenbanken zugegriffen wird, wobei Kommunikationen der fernen Datenbanken verwendet werden.
Jedes Datenmodul protokolliert die gesammelten Informationen auf einer lokalen Datenbank über das Logging-Modul (LM) 1172. Dieses Module handhabt Datenprotokollierungsanfragen von jedem Modul.
219. Das Alarmmodul (AM) 1176 erlaubt das Einstellen von Alarmbedingungen und erzeugt Alarme, wenn eine Alarmbedingung erreicht ist. Wenn zum Beispiel Daten auf der fernen Einheit gespeichert werden, kann eine Alarmbedingung eingestellt werden, wenn die On-Board-Speicherung mehr als 80% voll ist, um zu verhindern, dass ein Speicher-Overflow stattfindet.
Jedes Software-Modul hat eine definierte Methode um mit dem PUPPI-Haupt-Steuerungs-Module (MCM) 1104 zu kommunizieren. Das MCM 1104 hat die Fähigkeit Anfragen an jedes Module zu senden und Antworten zu erhalten. MCM 1104- Anfragen können Statuschecks, Aufgaben usw. umfassen. Jedes Modul kommuniziert dem Logging-Modul (LM) 1172 um Resultate zu protokollieren.
Das WAP Daten-Module (WDM) 1116 kommuniziert mit dem WAP-Gateway unter Verwendung des UDP. Das Steuerverbindungs-Anschluss-Module (CLM) 1168 kommuniziert mit dem Back-End-Server unter Verwendung von TCP/IP.
222. Das beispielhafte System hat eine Fernsteuerfähigkeit. Eine Fernzugangsapplikation (z.B., PC Anywhere oder ein Äquivalent davon) befindet sich auf jeder PUPPI-Einheit geladen um den vollen Fernzugang zur PUPPI-Einheit zu erlauben. Diese Software ist so konfiguriert, dass sie automatisch durchgeführt wird und einen Hostmodus eingibt, wenn die Maschine gestartet wird. Während der Ausführung bleibt die Anwendung im Hostmodus und wartet auf die Verbindungen von externen Maschinen.
Das beispielhafte System hat auch Applikationsschutzfähigkeiten. Jeder PUPPI-Einheit kann eine spezielle Hardwarekarte enthalten, welche verwendet werden kann um die Maschine zu rebooten, wenn Softwareprobleme auftreten. Das Hauptsteuerungsmodul (MCM) 1104 erhält die Aufgabe der Überwachung jedes Prozesses um zu verifizieren, dass jeder korrekt läuft. Wenn irgend ein Prozess nicht auf die Anfrage des MCM reagiert, rebootet die Hardwarekarte die Maschine automatisch innerhalb einer vordefinierten Zeitperiode.
Für eine stationäre PUPPI in einer gesteuerten Umgebung, wird eine beispielhafte PUPPI-Steuerungseinheit vorteilhaft in ein Standardrahmen des PC montiert. Für eine mobile PUPPI gibt es eine Vielfalt von möglichen Ausführungsformen, je nach der Betriebsumgebung. Die PUPPI- Hardware kann einen speziellen Einsatz umfassen um das Handgerät vom PC abzuschirmen. Der Handgeräteeinsatz umfasst eine Zugang für ein serielles Kabel für Kontrollzwecke und einen Port für eine externe Antenne.
Im Fall, dass mehrfache Technologien am fernen Standort erforderlich sind, gibt es eine Vielfalt von Optionen, die eingesetzt werden können. Zu Beispiel eine einzige PUPPI-Einheit mit mehreren seriellen Ports kann installiert werden um mehrere Technologien zu implementieren. Die einzige Begrenzung dieses Approachs ist die Verarbeitungskraft und die Speicherkapazität des PUPPI um mehrere Technologien zu unterstützen. Alternativ kann jede PUPPI eine einzige Technologie unterstützen und über ein LAN mit der Fähigkeit mit dem Back-End zu kommunizieren, verbunden sein.
Beispielsweise unter Bezugnahme auf 12 wird ein Router 1200 verwendet, als Schnittstelle zwischen einer externen Kommunikationsleitung 1210 (wie einer DSL- oder Einwahlleitung) und einem LAN 1220, das mit den PUPPIs 1230 verbunden ist.
In 13 ist die Basisarchitektur für den Back-End gemäss einer beispielhaften Ausführungsform erläutert
Der Back-End führt folgende Hauptfunktionen durch:

• Durchführung des Flottenmanagements der PUPPIs, das das Senden von Befehlen und das Empfangen von Antworten unter Verwendung der Steuerverbindung umfasst, und die Durchführung einer Wartefunktion von Aufträgen auf Basis von Messscripten
• Aufrechterhalten einer Datenbank mit PUPPI-Informationen
• Aufrechterhalten einer Datenbank von geforderten und geplanten Sammelaufträgen
• Aufrechterhalten einer Datenbank von gesammelten Daten
• Bereitstellen einer Anwender-Schnittstelle für die Eingabe von Aufgaben für Sammelaufträge und den Auszug von gesammelten Daten

Die Anwenderschnittstelle 1310 zum System ist eine einfache Schnittstelle, die dem Anwender erlaubt Testscripts über das Internet 1320 herzustellen um Daten zu sammeln und die gesammelten Daten abzurufen. Der andere Hauptbestandteil des Back-End stellt das Flotten-Management und das Daten-Management für die PUPPI-Flotte 1330 zur Verfügung, die geplanten Aufträge 1340, und die gesammelten Daten 1350 zu Verfügung.
Der Back-End wird unter Verwendung von kommerziellen PCs und Standardsoftware und Datenbanktools implementiert.
Die Back-End-Software umfasst vorzugsweise eine Flottenmanager-Anwendung, einen zentralisierten Datenbankserver und einen Webserver. Die Flottenmanager-Software erlaubt dem Systembediener das Folgende zu tun:

• Messungen zu definieren
• Messungen den PUPPIs zuzuordnen
• Abfragen der PUPPIs nach diagnostischen Informationen
• Start und Beenden der PUPPI-Messungen
• Abfragen der PUPPIs nach Konfigurationsinformationen
• Planen der Ausgabe von Messungen
• Abfragen der PUPPIs nach Messresultaten

Alle Daten, die von den PUPPIs gesammelt wurden, werden auf einem zentralisierten Datenbankserver gespeichert. Die Datenbank enthält detaillierte Informationen über die Messungen, Zuordnungen, Konfigurationsinformationen usw. Die durch das System zu sammelnden Daten werden über eine Scriptsprache eingegeben.
Unter Bezugnahme auf 14, werden zwei grundlegende Softwaremodule, die im Back-End eingefügt sind, erläutert. Die Module, das Warteschlangen-Aufbau-Modul 1410 und das Planer-Module 1420, wandeln die Auftragsanfragen vom Script in einen aktuellen Auftrag, der auf dem PUPPI auszuführen ist, um.
Das Warteschlangenaufbau-Module 1410 nimmt die Informationen vom Script und wandelt sie in eine Warteschlange von Datensammlungsaufträgen für die PUPPIs um. Der Planer 1420 nimmt die Informationen in der Warteschlange und wandelt sie in regelmässigen Intervallen in eine Liste von Aufgaben um (z.B. täglich), welche zu den PUPPIs gesandt und dann ausgeführt werden. Die resultierenden Daten werden, nachdem sie gesammelt wurden, von der PUPPI-Datenbank 1430 abgerufen.
Unter Bezugnahme auf 15, wird die Hardware-Architektur für den Back-End gemäss der beispielhaften Ausführungsform erläutert. Die Back-End-Hardware umfasst mindestens eine skalierbare Konfiguration von kommerziellen Servern 1510, 1520, 1530, die 24/7-Operationen unterstützen. Durch die Ausgestaltung fliessen signifikant weniger Daten zwischen dem aWAP-Klienten und dem Server, als zwischen einem Internet-Klient und dem Server. Viele der Aufgaben, die durch einen Internet-Klienten gehandhabt werden (z.B. DNS Nachschlageanfrage und Antwort), sind unter WAP vom Klienten zum Server (oder Gateway) verschoben worden. Zusätzlich unterscheiden sich Seiten auf WAP-basierten WML-Seiten von Internet-basierten HTML-Seiten. WML-Seiten führen das Konzept von Kartenstapeln und Karten ein. WML-Seiten enthalten Kartenstapeln, welche eine oder viele Karten enthalten können. Jede Karte ist einer einzelnen Seite oder Bildschirmansicht ähnlich. Eine Kartenstapel enthält normalerweise eine Sammlung von Karten. Wenn ein Anwender eine URL von einem WAP-Gerät anfordert, wird oft ein Kartenstapel mit mehreren Karten zum Browser heruntergeladen. Ist einmal der gesamte Kartenstapel heruntergeladen, kann sich der Anwender zwischen Bildschirmen bewegen, ohne dass vom Server angefordert werden muss, neuen Gehalt herunterzuladen.
Das System gemäss dem Beispiel ist so konfiguriert, Informationen zusammeln, wie sie für das WAP-basierte Browsing spezifisch sind. Die folgenden Masse können durch das beispielhafte System gesammelt werden. Der Web-Download würde die Simulation einschliessen, dass ein Anwender eine einzige Web-Seite herunterladen würde. Nachstehend aufgelistet ist ein Beispiel einer Informationsart, die sammelbar ist.
• GET Zeit & Datum

Zeit und Datum für welches der Browser ein GET-Befehl für die Anforderung eines URL ausgibt.

• URL Adresse

Adresse des abgefragten URL.

• Kartenstapel Text Grösse

Grösse in Bytes des Textteils des Kartenstapels und aller verbundenen Karten.

• Bild Zählung

Ein Zählung der Anzahl der Bilder die in einem Kartenstapel eingebettet sind.

Für jedes Bild können folgende Informationen gesammelt werden:
• Bildgrösse

Grösse des Bildes in bytes.

• Bild-Zeit

Zeit um das Bild herunterzuladen.

• Bild-URL

URL des Bildes.

• Totale Kartenstapel-Zeit

Erforderlich Zeitdauer um den gesamten Kartenstapel und die damit verbundenen Bilder herunterzuladen.

• Totale Kartenstapel-Bytes

Gesamtzahl von Bytes innerhalb des Kartenstapels (Text und Bilder)

• Resultat

Ob der Web-Download erfolgreich war oder nicht.

Web-Navigations-Messungen umfassen die Simulation einer Anwender-Navigation auf einer Seite, von der Seite verschieden ist, die durch den Haupt-URL definiert ist. Zum Beispiel kann ein Kunde wünschen, zu wissen, wie lange es braucht um zum Finanz-Nachrichten-Teil der Bloomberg-Seite zu navigieren.
Alle Informationen, die im Web-Download-Abschnitt aufgelistet sind, können für jeden Kartenstapel, der als Teil der Navigationsaufgabe heruntergeladen wurde, gesammelt werden. Zusätzlich können die nachstehend aufgelisteten Informationen auch in Abhängigkeit einer technischen Abschätzung von Invertix gesammelt werden.
• Total Karten

die totale Anzahl von Karten (oder Bildschirmen) um die Endbestimmung zu erreichen.

• Total Kartenstapel

Totale Anzahl der Kartenstapeln, welche zur Erreichung eines Endziels heruntergeladen werden mussten.

• Total Navigationszeit

Erforderliche Zeitdauer um zum Endziel zu navigieren.

• Total Navigations-Bytes

Totale Anzahl von Bytes die heruntergeladen wurden um zu einem Endziel zu navigieren.

• Resultat

Ob der Web-Navigation erfolgreich war oder nicht.

Web-Transaktionen umfassen generell Komponenten der Web-Download- und Web-Navigations-Verfahren. Web-Transaktionen sind definiert als irgendwelche Aktionen, welche vom Anwender die Eingabe von Informationen verlangen um ein Resultat zu erhalten. Einige Beispiele umfassen die Eingabe der eigenen Postleitzahl um das Wetter abzufragen, die Eingabe eines Häkchensymbols um eine Börsenquote abzufragen; oder die Eingabe einer Rechnungsinformation um ein Buch zu kaufen. Web-Transaktionen sammeln alle Masse einschliesslich der obigen für einen Web-Download und eine Web-Navigation. Zusätzlich können die nachstehend aufgelisteten Informationen auch gesammelt werden.
• Antwortzeit

Zeit des Netwerks um auf eine Anwendereingabe zu antworten.

• Resultat

Ob die Anwender-Eingabe erfolgreich war oder nicht.

Eine volle Web-Transaktion kann erfordern, dass eine Anwender-Eingabeinformation auf mehreren Bildschirmen eingegeben wird. Das Mass für jede Anwendereingabe und -antworten würde gesammelt. Der Erfolg oder der Misserfolg einer Transaktion würde auf den Daten basieren, welche in Beantwortung der Anfrage retourniert werden.
VIII. Datensuch-Funktionalität
Die Offenbarung hat soweit das Sammeln und das Speichern der Daten betont. Das Thema der Handhabung der Daten in einer Weise, welche für den Endverbraucher Wert vermehrend ist, ist wertvoll und fügt die wirtschaftliche Lebensfähigkeit des Systems hinzu. Die gesammelten Daten können gelagert und für die Datensuche verwendet werden um einen Mehrwert zu schaffen.
Telecom-Dienstleister (Kabellos-Versorger, ISPs, CLECs, ILECs, Satellite und IXCs) können kabellose Datenportale aufbauen und ihre Back Office-stove-pipe-Datensysteme in einer einzigen Lagerplattform integrieren. Zusätzlich können Telecombetreiber kabellose Portale aufbauen und betreiben und Rechnungsdaten und andere Kundenbetreuungsdaten den Abonnenten zugänglich machen, durch eine interaktive, anpassbare Web- und/oder Kabellosdaten-Schnittstelle.
Eine Datenübersetzungsanwendung wird konfiguriert um Daten von verschiedenen verkaufsunabhängigen Bereichen (Buchhaltung, Kundenbetreuung, Marketing, Leistungsfähigkeit des Netzwerks) zu sammeln, und sie in einem einzigen Lager mit spezifischen vertikal dimensionierten Aufteilungen zu hosten. Der Datenmodus des Datenlagers ist so konfiguriert um das Berichten zu erleichtern und zu Beschleunigen.
Gemäss einer bevorzugten Ausführungsform wird das Datensuchen implementiert (zum Beispiel durch verwenden von MicroStrategy's Intelligent E-Business Platform) so dass die Endverbraucher eine graphische web-basierte Front-End-Schnittstelle verwenden können, um analytische Online-Abfragen der unterstrichenen Daten durchführen zu können, und auf die spezifischen Bedürfnisse massgeschneiderte Berichte schaffen zu können. Die Einzelheiten der Berichte reichen vom hochkarätigen Management-Report, wo die Anwender vertikal und horizontal suchen können, bis zu Daten auf dem atomaren Niveau.
Tools ermöglichen fortschrittlichen Call-Center-Management-Anwendungen das folgende zu tun:

• Erhöhen der Produktivität der Angestellten und Reduktion der Antwortzeiten durch detaillierte Analysen der Anrufvolumen und -muster,
• Verbesserung der Effektivität des Call-Centers, indem Berichte für die Behebung von Beschwerdefällen erstellt werden,
• Zugänglich machen von Informationen für die Marketingmitarbeiter für die Entwicklung von Kunden-Kampagnen, und
• Erhöhen der Kundenloyalität indem sie durch personalisierte Mitteilungen über die Leistungsfähigkeit des Netzwerks und die Problemlösungen informiert werden.

Effektives Marketing ist kritisch für Erhaltung von Kunden, ebenso wie für die Akquisition von neuen. Die Sicherstellung, dass Kunden einen optimalen Plan für ihre Einsatzpläne haben, ist hilfreich zur Verstärkung des Einkommens und für die Reduktion der Abwanderung, indem das Management befähigt ist, eine Marketingstrategie zu planen um neue Produktangebote zu schaffen, die Preisgestaltung zu analysieren und den Einfluss von neuen Angeboten auf den Gewinn abzuschätzen.
Ein Portal stellt den Abonnenten einen einzigen Ausgangspunkt für den Zugang zu Dateninformationen, -analysen und -verbreitung zur Verfügung. Als personalisierter webbasierter Zugang zu Informationen, erlaubt er den Anwendern die Schlüsselinformation zu abonnieren, ihre Bedürfnisse zu personalisieren, und die gewünschte Häufigkeit für ihre Lieferung zu spezifizieren, alles durch eine einzige webbasierte Schnittstelle. In einem Beispiel wird eine solche Funktionalität durch MicroStrategy InfoCenter betrieben. Das Portal ist für den grossvolumigen Einsatz konzipiert und umfasst einen asynchronen Update-Server, ein Hochgeschwindigkeits-Schnittstellen-Cache und Clustering um die Bedürfnisse der grossvolumigen Implementationen abzudecken. Anpassbar an viele Verbraucheranforderungen kann das Telco Portal den Telco-Bediener mit den Fähigkeiten für seine interne Gemeinschaft versehen:

• Analyse der Kosten und des Einkommens,
• Anpassen der Preisgestaltung und von Promotionen zur Erhaltung der Servicequalität,
• Verbesserung der Verkäufe und des Kundendiensts,
• Optimierung der Kundenloyalitätsprogramme and
• Reduktion der Abwanderung.

Ein Portal stellt auch Netzwerkbedienungs- und -leistungspersonal zur Verfügung, mit einem wirksamen Benachrichtigungstool, das Länder- und Fernverkehrsaktivitäten aufzeichnet. Täglich, wöchentliche und monatliche Berichte werden automatisch generiert und zum richtigen Personal gepushed. Die Anwender können Regeln für Alarme einstellen und Mitteilungen zu ihren mobilen Geräten auf Basis von gewissen Auslösekriterien senden lassen. Eine solche Funktionalität wird vorteilhaft durch MicroStrategy Broadcaster betrieben.
IX. Kombination von verschiedenen Systemen
Das System wird als Stand-alone-System mit der Erklärung der obigen Ausführungsformen beschrieben. Gemäss einer weiteren Ausführungsform der Erfindung wird jedoch das System mit einem oder mehreren sekundären Datensammelsystemen kombiniert.
Ein solches sekundäres Datensammelsystem funktioniert so, dass es einige der gleichen Daten sammelt, wie sie durch das System gemäss der obigen beispielhaften Ausführungsform gesammelt wurden. Dieses sekundäre System sammelt diese Daten und sendet sie zu einem System gemäss der beispielhaften Ausführungsform zur Verarbeitung.
Eine anderes solches sekundäres Datensammelsystem funktioniert, indem es Daten sammelt, die verschieden sind von den Daten, welche durch das beispielhafte System gesammelt werden. Die Daten vom sekundären System und dem beispielhaften System werden kombiniert, entweder vor oder nach der Verarbeitung um für die Kunden Berichte mit mehr Wert zu erstellen.
Gemäss einer alternativen Ausführungsform, sammelt ein System gemäss der vorliegenden Erfindung zusätzliche Daten (ausserhalb der oben diskutierten Standardtypen), welche dann exportiert werden, für die Verwendung im sekundären System, entweder vor oder nach der Verarbeitung.
Zusätzlich wird bemerkt, dass eine Back-End-Installation gemäss der vorliegenden Erfindung nicht auf die Steuerung von fernen Messeinheiten eingeschränkt ist. Der Back-End-Teil eines Systems gemäss der vorliegenden Erfindung ist nützlich für das Vorlegen einer Planung, Steuerung und Datensammlung für eine Vielfalt von andern Systemen (zum Beispiel, Datensammelsensoren, Telekommunikationsnetzwerk-Betriebszentren, sowohl für verkabelte, wie auch kabellose Systeme, Telekommunikations-QOS-Netzwerk-Betriebszentren, Überwachungs- und Sicherheitssystem, automatische Einstellung von Parametern von kabellosen Netzwerk-Basisstationen usw.).
Ein drittes Implementationsparadigma ist im Fall von Netzwerken, die bereits gut etablierte Back-End-Operationen aufweisen, ebenfalls zweckmässig. Im Gegensatz zu den Stand-Alone- und Mastercontroller-Paradigmen, die oben diskutiert wurden, kann ein Back-End gemäss der vorliegenden Erfindung als ein zugefügter Satz von Funktionalitäten als Teil einer schon existierenden Netzwerk-Back-End-Installation implementiert werden. Jede zusätzliche Hardware, welche die Implementierung der Funktionen des Back-Ends gemäss der vorliegenden Erfindung erfordert, wird in einfacher Weise in solche eines existierenden Systems integriert, wobei das existierende System reprogrammiert wird um die oben beschrieben Dienste zu erbringen.
Der Bereich der Erfindung wird nur durch die. beigefügten Patentansprüche limitiert.

Claims

Messsystem zum Messen der Datenqualität des Dienstes mindestens eines kabellosen Verkehrsnetzwerks, umfassend: eine Mehrzahl von fernen Einheiten (300) für die Durchführung von Messungen mindestens eines kabellosen Netzwerks, wobei jede der Mehrzahl von fernen Einheiten (300) einen Klienten eines kabellosen Datenprotokolls, WDP, in Gang setzt, jede der Mehrzahl von fernen Einheiten (300) umfasst: mindestens ein Testverkehrsmodem (310), das angepasst ist, eines oder mehrere des mindestens einen kabellosen Verkehrsnetzes zu verbinden, gekennzeichnet durch ein Steuerverbindungsmodem (308), und eine Steuereinheit, die mit dem Testverkehrsmodem und dem Steuerverbindungsmodem gekuppelt ist, und ein Backend-Prozessor (224) für die Fernsteuerung der Mehrzahl von fernen Einheiten (300), wobei der Backend-Prozessor (224) unter Kommunikation mit jeden der Mehrzahl von fernen Einheiten (300) über eine Steuerverbindung steht, und Befehle und Antworten mit dem Steuerverbindungsmodem über die Steuerverbindung austauscht; wobei ausgewählte Einheiten der Mehrzahl von fernen Einheiten den Betrieb eines WDP-fähigen kabellosen Geräts simulieren indem der WDP-Klient Zugang zu mindestens einem kabellosen Verkehrsnetzwerk über das Testverkehrsmodem hat (310).
Messsystem nach Anspruch 1, worin das Testverkehrsmodem ein kabelloses Handgerät umfasst.
Messsystem nach Anspruch 1, worin das Testverkehrsmodem ein kabelloses Modemmodul umfasst.
Messsystem nach Anspruch 1, worin das Steuerverbindungsmodem ein POTS-Modem umfasst und die Steuerverbindung eine zugeordnete Telefon-Linie umfasst.
Messsystem nach Anspruch 1, worin das Steuerverbindungsmodem ein DSL-Modem umfasst und die Steuerverbindung eine zugeordnete DSL-Linie umfasst.
Messsystem nach Anspruch 1, worin das Steuerverbindungsmodem ein IDSN-Modem umfasst und die Steuerverbindung eine zugeordnete IDSN-Linie umfasst.
Messsystem nach Anspruch 1, worin der WDP-Klient in der Steuereinheit verwirklicht ist.
Messsystem nach Anspruch 1, worin der WDP-Klient im Testverkehrsmodem verwirklicht ist.
Messsystem nach Anspruch 1, worin der WDP-Klient einen WAP-Browser umfasst.
Messsystem nach Anspruch 1, worin der WDP-Klient einen iMode Browser umfasst.
Messsystem nach Anspruch 1, worin die ferne Einheit einen Abonnenten simuliert, wobei ein WDF-fähiges kabelloses Gerät verwendet wird.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein Datentransportmodul, TDM, umfasst, das in Beziehung stehende Daten transportiert.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten einen Kurzmitteilungsdienst, SMS, umfasst, der SMS-Informationen sammelt.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein Modul eines persönlichen digitalen Assistenten, PDA, umfasst, das PDS-Informationen sammelt.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein Push-Benachrichtigungsmodul, PNM, umfasst, das in Beziehung stehende gepushte Informationen sammelt.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein passives Überwachungsmodul, PMM, umfassen, das in Beziehung stehende Informationen für die passive Überwachung mindestens eines kabellosen Verkehrsnetzwerks sammelt.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein HTML Datentransportmodul umfassen, das mit HTML in Beziehung stehende Informationen transportiert.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein Packetsniffingmodul, PSM, umfasst, das Packetsniffing durchführt.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten ein Multimediadatenmodul, MMDM, umfasst, das Aufgaben durchführt, die sich auf Multimediadaten beziehen.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten eine Datenbank, umfassen, die eine Speicherung der Messungen durchführt.
Messsystem nach Anspruch 1, worin der Backend-Prozessor, eine Datenbank, umfasst, die eine Speicherung der Messungen durchführt.
Messsystem nach Anspruch 1, worin der Backend-Prozessor ein Terminplanmodul umfasst, das eine Speicherung der Messungen durchführt.
Messsystem nach Anspruch 1, worin der Backend-Prozessor ein Datensuchmodul umfasst, das die Messungen analysiert.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten stationär sind.
Messsystem nach Anspruch 1, worin die eine oder die Mehrzahl von fernen Einheiten mobil sind.
Messsystem nach Anspruch 1, worin der Backend-Prozessor in einer frei stehenden Konfiguration ausgeführt ist.
Messsystem nach Anspruch 1, worin der Backend-Prozessor so ausgestaltet ist, dass er Befehle und Steuerungen für verschiedene Systeme ausserhalb des Messsystems ausführen kann.
Messsystem nach Anspruch 1, worin der Backend-Prozessor so ausgeführt ist, dass er Versuchsdaten von einem oder mehreren sekundären Systemen erfassen kann, die verschieden von den fernen Einheiten sind.
Messsystem nach Anspruch 1, worin der Backend-Prozessor so ausgestaltet ist, dass eine vorher existierende Backend-Installation übernommen werden kann, um einen Satz von zusätzlichen Funktionalitäten einzuverleiben.
Messsystem nach Anspruch 1, worin: das Testverkehrsmodem ausgewählt ist aus der Gruppe bestehend aus: kabelloses Handgerät und kabelloses Modemmodul; und worin ein Wireless Application Protocol, WAP, – Browser über die Steuereinheit oder das Testverkehrsmodem ausgeführt wird; und worin die ausgewählte Einheit oder Mehrzahl von fernen Einheiten einen Abonnenten simulieren, der ein WAP- fähiges kabelloses Gerät verwendet, indem es durch den WAP-Browser Zugang zu dem mindestens einen kabellosen Verkehrsnetzwerk via dem Testverkehrsmodem besitzt.
Messsystem nach Anspruch 1, worin der Backend-Prozessor enthält: eine Flottendatenbank zur Speicherung von Informationen, die sich auf die Mehrzahl von fernen Einheiten beziehen; eine Missions-Terminplanungsdatenbank zur Speicherung von Informationen, die sich auf die Messungsmissionen beziehen, die durchzuführen sind, durch die eine oder die Mehrzahl von fernen Einheiten; und ein Flottenmanagementserver in Kommunikation mit jeder der einen oder Mehrzahl von fernen Einheiten über entsprechende Steuerverbindungen und der angepasst ist, Befehle und Antworten mit ausgewählten Einheiten der einen oder der Mehrzahl von fernen Einheiten auszutauschen, wobei der Flottenmanagementserver die Kommunikation mit den fernen Einheiten erbringt, auf Basis von Informationen, welche die Flottendatenbank zugänglich macht, wobei die Befehle auf Informationen basieren, die aus der Missionsterminplanungsdatenbank zugänglich sind; wobei der Flottenmanagementserver für gewisse der Mehrzahl von fernen Einheiten den Steuerbefehl führt, um den Betrieb eines WDP-fähigen kabellosen Geräts zu simulieren, indem der WDP-Klient Zugang zu dem mindestens einen kabellosen Verkehrsnetzwerk besitzt.