DE60032616T2 - Verfahren und system zum abfragen von merkmalen in einem zellularen kommunikationssystem - Google Patents

Verfahren und system zum abfragen von merkmalen in einem zellularen kommunikationssystem Download PDF

Info

Publication number
DE60032616T2
DE60032616T2 DE60032616T DE60032616T DE60032616T2 DE 60032616 T2 DE60032616 T2 DE 60032616T2 DE 60032616 T DE60032616 T DE 60032616T DE 60032616 T DE60032616 T DE 60032616T DE 60032616 T2 DE60032616 T2 DE 60032616T2
Authority
DE
Germany
Prior art keywords
mpt
information
network
parent
attribute
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60032616T
Other languages
English (en)
Other versions
DE60032616D1 (de
Inventor
E. Paul San Diego BENDER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/480,710 external-priority patent/US6850494B1/en
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of DE60032616D1 publication Critical patent/DE60032616D1/de
Publication of DE60032616T2 publication Critical patent/DE60032616T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Monitoring And Testing Of Transmission In General (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • I. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft drahtlose Netzwerkkommunikationen. Insbesondere betrifft die vorliegende Erfindung ein neues und verbessertes Protokoll, durch welches drahtlose Netzwerkelemente kommunizieren können.
  • II. Hintergrund
  • In Kommunikationsnetzwerken benötigen viele Funktionen, welche durch individuelle Netzwerkelemente durchgeführt werden, ein Wissen über Information von umgebenden Netzwerkelementen. Obwohl andere Techniken wie das Ausbreiten von benötigter Information individuell zu jedem Netzwerkelement von einem zentralen Steuerungselement bekannt sind, hat die vorliegende Erfindung signifikante Vorteile gegenüber diesen anderen Techniken. Zu versuchen, Information von einem zentralen Steuerungselement zu mehreren Netzwerkelementen auszubreiten, ist zeitraubend und fehleranfällig. Zusätzlich verändern sich einige Attribute (wie Ressourcenverfügbarkeit) häufig.
  • In einem CDMA Kommunikationssystem benötigen viele Funktionen, welche durch die Netzwerkelemente durchgeführt werden, Information von umgebenden Netzwerkelementen. In der vorliegenden Erfindung ist das Protokoll in Ausdrücken der Informationsausbreitung zwischen Netzwerkelementen, welche Modem-Pool-Transceiver und Modem-Pool-Steuerelemente bzw. Modem-Pool-Controller (MPCs) haben. Ein Modem-Pool-Transceiver (MPT) ist ein Kommunikationsnetzwerkelement, welches Modulation und Demodulation von Funkfrequenznetzwerkverkehr durchführt und ist auch für das Einteilen, die Leistungssteuerung und Aufgaben des Handhabens von Overhead-Nachrichten verantwortlich. Ein MPC ist ein anderes Element, welches Funksteuerung und Signalisierungsdienste für die MPT Elemente vorsieht, welche Leistungssteuerungssynchronisation, Erhalten des Modemssit zungszustands, und Netzwerkverbindungssteuerung beinhalten. MPCs erzeugen und verarbeiten Daten für die MPTs, um zu senden und zu empfangen. MPTs benötigen Luftinterfaceattribute von benachbarten MPTs, um die korrekten Luftinterface-Overhead-Nachrichten zu konstruieren. MPCs benötigen Luftinterfaceattribute von MPTs, um MPT Übergabe durchzuführen. MPCs benötigen Luftinterfaceattribute von MPTs, um Zugriffsterminalpaging durchzuführen. Ein Zugriffsterminal (AT = access terminal) ist eine Einrichtung mit einem Modem und einem Dateninterface, welches dem Benutzer erlaubt, auf ein IP Netzwerk durch ein Zugriffsnetzwerk (AN = access network) zuzugreifen. MPCs benötigen Ressourcenverfügbarkeitsattribute von umgebenden MPCs, um MPC Übergabe durchzuführen.
  • Derzeit gibt es kein ideales Verfahren um die Bedarfe von Elementen von drahtlosen Kommunikationsnetzwerken zum direkten Austauschen von Information zu erfüllen.
  • Ein Problem, welches auftritt, wenn Netzwerkelemente nicht direkt Information austauschen können, ist, dass MPCs kein zweckdienliches Verfahren haben, um Information über benachbarte MPTs aufzufinden, welche notwendig ist, um AT Paging durchzuführen. Zu jeder gegebenen Zeit kann ein MPC verantwortlich sein, um eines oder mehrere untätige ATs zu pagen.
  • „Untätig" bzw. „schlafend" bezieht sich auf die Zeitperiode, wenn ein AT und ein AN eine Sitzung aufgebaut haben, aber keine aufgebaute Verbindung haben. Untätiger Modus erlaubt dem AT, den „immer an" Zustand aufrecht zu erhalten, während nur begrenzte Funkverbindungskapazität und begrenzte AT Leistung verwendet wird, wenn Daten gesendet oder empfangen werden.
  • Um Daten zu einem untätigen AT zu liefern, muß das MPC dazu in der Lage sein, das AT zu orten. Das MPC ortet das untätige AT durch Paging des untätigen ATs in allen MPTs, in welchen das untätige AT platziert sein kann. Diese Sammlung von MPTs wird als der Pagingbereich bezeichnet. Um das untätige AT zu pagen, muß das MPC den Pagingbereich kennen.
  • Derzeit gibt es kein ideales Verfahren zum Erfüllen der Bedarfe von MPCs, um dynamisch Pagingbereichsinformation aufzufinden, welche für AT Paging benötigt wird.
  • Weitere Aufmerksamkeit wird auf das Dokument US-A-5,892,916 gelenkt, welches ein System und ein Verfahren zum Netzwerkmanagement offenbart, einschließlich eines Nachrichtenverarbeitungsvorgangs, welcher einen Netzwerkmanager hat, und mindestens ein Netzwerkelement ist beschrieben. Dieses Netzwerkmanagementnachrichtensystem sendet und empfängt mehrere gleichzeitige Nachrichten zwischen der Netzwerkelementschicht und der Netzwerkmanagementschicht. Die Unterstützung von gleichzeitigem Benachrichtigen beschleunigt und vereinfacht das Netzwerkmanagement. Eine Clientanforderung wird bei einem ersten gemanagten Objekt empfangen, mindestens ein Teil der Clientanforderung wird durch ein zweites gemanagtes Objekt erfüllt. Eine Hauptzeile wird ansprechend auf den Empfang der Clientanforderung erzeugt, und eine Unterzeile, welche mit einer Anforderung für ein gemanagtes Objekt in Verbindung steht, welche mit dem zweiten gemanagten Objekt verbunden ist. Die Unterzeile hat einen Index, welcher die Unterzeile zu der Hauptzeile zuordnet, und korreliert eine Antwort auf die Anforderung des gemanagten Objekts mit der Clientanforderung.
  • Gemäß der vorliegenden Erfindung werden ein Verfahren und eine Vorrichtung zum Bestimmen von zellularen Pagingbereichen gemäß den Ansprüchen 1 und 4 vorgesehen. Bevorzugte Ausführungsbeispiele der Erfindung sind in den abhängigen Ansprüchen beansprucht.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung ist ein neues und verbessertes Protokoll zum direkten Aktualisieren von Attributinformation in Kommunikationsnetzwerken.
  • Die vorliegende Erfindung liefert ein allgemeines Protokoll basierend auf dem Hypertexttransferprotokoll in Version 1.1 (HTTP/1.1) und Multipurpose Internet Mail Extensions (MIME), welches individuellen Netzwerkelementen erlaubt, andere Netzwerkelemente direkt nach Information ohne Eingreifen des Netzwerkmanagers abzufragen. Es reduziert erheblich Systemversagen, welche durch Ausbreitungsfehler und verschwundene Information verursacht werden, und ermöglicht auch den Einsatz von zusätzlichen Netzwerkelementen und das Entfernen von Netzwerkelementen.
  • Die Netzwerkelemente können ihre Attribute durch die Verwendung von HTTP/1.1 verfügbar machen. Andere Netzwerkelemente sind dazu in der Lage, nach spezifischen Attributen unter Verwendung des HTTP GET Verfahrens abzufragen. Die Antwort ist ein zurückkommender HTTP Header mit einem MIME Teilkörper, welcher eine Liste von Attributnamen/Wertepaaren enthält.
  • Die vorliegende Erfindung liefert ein allgemeines Protokoll zum Erlauben, dass Kommunikationsnetzwerkelemente andere Netzwerkelemente nach Information abfragen. Es erlaubt, dass Netzwerkinformation in einem Ort konfiguriert wird und dynamisch durch andere Orte abgefragt wird. Es verhindert Ausbreitungsfehler und Fehler durch veralterte Information, welche durch Ausbreiten von benötigter Information individuell zu jedem Netzwerkelement durch Netzwerkmanagerinterfaces durch einen zentralisierten Netzwerkmanager verursacht werden.
  • Ausführungsbeispiele der vorliegenden Erfindung erfüllen auch Bedarfe des Auffindens von Paginginformation durch Vorsehen eines Protokolls zum Erlauben eines MPCs, um dynamisch Information abzufragen, welche für AT Paging von MPTs benötigt wird. Die vorliegende Erfindung sieht ein Verfahren zum Bestimmen von zellularen Pagingbereichen eines drahtlosen Kommunikationsnetzwerks durch Austauschen von Netzwerkkonfigurationsinformation direkt zwischen Netzwerkelementen, und Bestimmen von Zugriffster minalpagingbereichen von der ausgetauschten Netzwerkkonfigurationsinformation vor.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Merkmale und Vorteile der vorliegenden Erfindung werden von der detaillierten Beschreibung, welche unten stehend gegeben wird, offensichtlich werden, wenn sie zusammen genommen wird mit den Zeichnungen, wobei gleiche Bezugzeichen durchgängig korrespondieren, und wobei Folgendes gilt:
  • 1 ist ein funktionales Blockdiagramm eines exemplarischen Ausführungsbeispiels der vorliegenden Erfindung korrespondierend zu einer Topographie eines traditionellen drahtlosen Kommunikationsnetzwerks, d.h. mit verteilten MPTs;
  • 2A zeigt eine Topographie eines drahtlosen Kommunikationsnetzwerks mit verteilten NASs;
  • 2B zeigt eine Topographie eines drahtlosen Kommunikationsnetzwerks mit verteilten MPCs;
  • 3 ist ein Flussdiagramm, welches den Mechanismus des Aktualisierens von Systemparametern der vorliegenden Erfindung zeigt;
  • 4 ist ein Diagramm eines exemplarischen Ausführungsbeispiels der Inhalte von Maschinenanfragengen und Maschinenantworten der vorliegenden Erfindung;
  • 5 ist ein Datenstrukturdiagramm, welches die Datenhierarchie der vorliegenden Erfindung zeigt;
  • 6 ist ein zu einem gewissen Grade abstrahiertes Flussdiagramm, welches eine Übersicht des Mechanismus des Aktualisierens von Systemparametern zeigt;
  • 7 ist ein Flussdiagramm, welches die Ortsaktualisierungsprozedur der vorliegenden Erfindung zeigt;
  • 8 ist ein Flussdiagramm, welches die Antennenattributaktualisierungsprozedur der vorliegenden Erfindung zeigt;
  • 9 ist ein Flussdiagramm, welches die MPT Nachbaraktualisierungsprozedur der vorliegenden Erfindung zeigt;
  • 10 ist ein Flussdiagramm, welches die MPC Aktualisierungsprozedur der vorliegenden Erfindung zeigt;
  • 11 ist ein Blockdiagramm, welches die Vorrichtung zeigt, welche verwendet wird, um den Attributabfragevorgang der vorliegenden Erfindung auszuführen;
  • 12 ist ein Flussdiagramm, welches das Informationszwischenspeicherverfahren der vorliegenden Erfindung zeigt;
  • 13 ist ein Blockdiagramm, welches die Vorrichtung zeigt, welche verwendet wird, um das Auffinden von Paginginformation in einem drahtlosen Kommunikationssystem durchzuführen;
  • 14 ist ein AT Pagingbereichsdiagramm;
  • 15 ist ein stark abstrahiertes Diagramm eines Verfahrens, welches verwendet wird, um das Auffinden von Paginginformation in einem drahtlosen Kommunikationssystem durchzuführen;
  • 16 ist ein Datenstrukturdiagramm, welches die Datenhierarchie von Attributen des Auffindens von Paginginformation eines Ausführungsbeispiels der vorliegenden Erfindung zeigt; und
  • 17 ist ein Blockdiagramm, welches ein Verfahren zum Bestimmen von Paginginformation zeigt.
  • DETAILLIERTE BESCHREIBUNG DER BEVROZUGTEN AUSFÜHRUNGBEISPIELE
  • Ein exemplarisches Telekommunikationsnetzwerksystem, in welchem die vorliegende Erfindung ausgeführt ist, ist in 2A gezeigt. 2A zeigt Drahtloskommunikationsnetzwerkzugriffspunkte 100A, 100B, 1000, welche über ein Internetprotokoll (IP) Netzwerk 110 verbunden sind. Die Zugriffspunkte 100A, 100B, 1000 liefern drahtlosen Dienst für Teilnehmer in vordefinierten geographischen Bereichen. Manchmal teilt ein Zugriffspunkt 100A, 100B, 1000 Teile von geographischen Abdeckbereichen, welche als Sektoren bezeichnet werden, ein, und bedient diese unabhängig voneinander. Die Einteilung in Sektoren eines Zugriffspunkts ist im Stand der Technik gut bekannt und ist detailliert im dem U.S. Patent mit der Nummer 5,625,876, benannt „METHOD AND APPARATUS FOR PERFORMING HANDOFF BETWEEN SECTORS OF A COMMON BASE STATION" beschrieben, welches dem Bevollmächtigten der vorliegenden Erfindung zugeordnet ist und hierin im Weg der Referenz mit aufgenommen wird. Die MPTs 106, welche die gleichen oder HF-nahen Bereiche abdecken, werden als die Nachbarn eines Zugriffspunkts bezeichnet. In drahtlosen Kommunikationssystemen werden die MPTs 106, für welche gegebene MPTs 106 und MPCs 108 Information benötigen, durch die HF Ausbreitungscharakteristika der Signale, welche durch die Netzwerkzugriffspunkte übertragen werden, bestimmt. In dem exemplarischen Ausführungsbeispiel ist der Zugriffspunkt 100A, 100B, 1000 ein topologisches Element eines Kommunikationsnetzwerks, welches in einer einzigen Hardwareplattform beinhaltet ist, welche ein oder mehrere MPTs (MPT = Modem Pool Transceiver) 106, ein MPC 108, und einen Netzwerkzugriffsserver (NAS = Network Access Server) 104 beinhaltet. Der Netzwerkzugriffserver 104 ist eine Einrichtung, welche Zugriff zu Diensten auf dem Netzwerk in einer kontrollierten Art und Weise vorsieht, und zwar basierend auf der Identität der Benutzer der in Frage stehenden Netzwerkdienste und der Politik des Anbieters dieser Dienste. Der NAS 104 führt traditionelle Netzwerkzugriffsserverprotokollfunktionalität wie durch die Punkt-zu-Punkt Protokoll (PPP = Point to Point Protocol) Gruppe, entfernte Authentifizierungseinwahlbenutzerserver (RADIUS = Remote Authentication Dial-In User Server) Protokollgruppe, und die zweite Schicht Tunnelprotokoll (L2TP = Layer two Tunneling Protocol) Gruppe definiert vor. Der MPT 106 enthält eine Reihe von Verkehrskanalmodems und ist verantwortlich für das Erzeugen der gesendeten Wellenform, und zum Empfangen von Übertragungen von Teilnehmern in dem Abdeckbereich eines MPTs 106. Der MPT 106 erzeugt und empfängt Wellenformen durch Modulation und Demodulation von Funkfrequenznetzwerkverkehr, und führt auch Einteilung, Leistungssteuerung, und Systemparameternachrichtenverarbeitungsaufgaben aus. Das MPC 108 ist ein Netzwerkelement, welches Daten für die MPTs erzeugt und verarbeitet, und zwar zum Senden und Empfangen. Die MPCs 108 sehen auch Funksteuerung und Signalisierungsdienste für die MPT 106 Elemente, wie Leistungssteuerungssynchronisation, Erhalten des Modemzustandsstatus und Netzwerkverbindungsteuerung vor.
  • Es gibt zwei topologische Zugriffsnetzwerkreferenzmodelle zusätzlich zu der traditionellen drahtlosen Netzwerkkonfiguration: Das mit verteilten MPCs; und das mit verteilten NASs.
  • 1 ist ein funktionales Blockdiagramm eines exemplarischen Ausführungsbeispiels der vorliegenden Erfindung korrespondierend zu einem traditionellen oder verteilten MPT 10, wobei die Drahtloskommunikationsnetzwerktopographie MPCs 14 bei einem Punkt zentralisiert sind, welcher traditionell als Basisstationsteuerelement (BSC = Base Station Controller) 16 identifiziert ist. NAS 18 Funktionalität ist bei einem Punkt angeordnet, welcher manchmal als ein Paketdatendienstknoten (PDSN = Packet Data Servicing Node) 20 bekannt ist. 1 zeigt ein verteiltes MPT Zugriffsnetzwerk, wobei die MPTs 10 verteilt sind und die MPCs 14 und NASs 18 zentralisiert sind. Ein Zugriffspunkt für verteilte MPTs bzw. ein verteilter MPT Zugriffspunkt wird durch Zusammengruppierung von einem oder mehreren co-angeordneten MPTs gebildet. Das Zugriffsnetzwerk wird durch Verbinden von einem oder mehreren verteilten MPT Zugriffspunkten, einem oder mehreren zentralisierten MPCs oder einem oder mehreren zentralisierten Netzwerkzugriffsservern gebildet.
  • 2A zeigt eine Topographie eines verteilten NAS Drahtloskommunikationsnetzwerks. In einem verteilten NAS Zugriffsnetzwerk sind der MPT 106, MPC 108 und NAS 104 verteilt. 2A zeigt den Zugriffspunkt 100A, 100B, 1000, welcher durch Zusammengruppierung von einem oder mehreren MPTs, einem oder mehreren MPCs und einem oder mehreren Netzwerkzugriffsservern gebildet ist. Das Zugriffsnetzwerk wird durch Verbinden von einem oder mehreren verteilten Zugriffspunkten gebildet.
  • 2B zeigt eine Topographie eines verteilten MPC-Drahtloskommunikationsnetzwerks. In einem verteilten MPC Zugriffsnetzwerk sind das MPC 206 und das MPC 200 verteilt und der NAS 208 ist zentralisiert. Ein Zugriffspunkt ist durch Zusammengruppierung von einem oder mehreren MPTs und einem oder mehreren MPCs gebildet. Das Zugriffsnetzwerk ist durch Verbindung von einem oder mehreren verteilten Zugriffspunkten und einem oder mehreren zentralisierten Netzwerkszugriffsservern gebildet. Wieder kommunizieren Zugriffspunktkomponenten direkt miteinander über das IP Netzwerk 202 unter Verwendung der vorliegenden Erfindung. In einem verteilten MPC Zugriffsnetzwerk sind MPT und MPC verteilt und der NAS ist zentralisiert.
  • In CDMA Kommunikationsnetzwerken müssen Betriebs- und Netzwerkmanagementparameter in mehreren Plätzen durchgängig in dem System bekannt sein. Obwohl die vorliegende Erfindung in dem Kontext von CDMA Kommunikationsnetzwerken beschrieben ist, wird der Fachmann verstehen, dass die Lehren der vorliegenden Erfindung einfach auf andere drahtlose Kommunikationssysteme wie GSM und AMPS Kommunikationsnetzwerke erweitert werden können. Diese Parameter beinhalten Information, welche in Betriebsnachrichten wie Übergabeanweisungsnachrichten, Leistungssteuerungsparameternachrichten, Pagenachrichten und Nachbarlistennachrichten enthalten sind. Die Inhalte dieser Nachrichten sind im Stand der Technik gut bekannt und detailliert in der Familie von Standards der Telecommunications Industry Association IS-95, benannt „MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEM" beschrieben. Die Nachrichten sind für illustrative Zwecke beschrieben. Es wird vom Fachmann verstanden werden, dass die Lehren auf andere Nachrichten erweitert werden können, welche notwenig für den Betrieb eines drahtlosen Kommunikationssystems sind. Netzwerkkonfigurationsparameter müssen auch bekannt sein und in mehreren Orten aktualisiert gehalten werden. Wenn zum Beispiel ein MPT 106 online oder offline gebracht wird oder temporär ausfällt, müssen andere MPTs 106 und MPCs 108 in dem System über die Veränderung in den Ressourcen informiert werden. Die vorliegende Erfindung ist eine Verbesserung gegenüber vorher bekannten Techniken zum Aktualisieren von Parametern wie Ausbreitung von benötigter Information durch das Netzwerkmanagementinterface individuell zu jedem Netzwerkelement von einem zentralen Netzwerkmanager. Vorher bekannte Verfahren benötigen Eingriff des zentralen Managers und führen Ausbreitungsfehler ein, welche Systemfehler verursachen.
  • Die vorliegende Erfindung ermöglicht, dass die Ausbreitung von Drahtlos CDMA Netzwerkinformation der Ausbreitung von Internetinformation gleicht, und zwar durch Loswerden mit einem zentralisierten Manager. Das Internet hat keinen zentralen Manager an der Spitze des Internets, welcher neue Information herunter zu jedem Router im Internet jedes Mal gibt, wenn ein Router hinzugefügt oder entfernt wird von dem Internet. Internetrouter kennen ihre benachbarten Router durch Adresskonfiguration und können Information über diese direkt durch drahtgebundene Verbindung abfragen. Die vorliegende Erfindung erlaubt MPT 106 Elementen, Information über ihre Nachbarn abzufragen, indem sie mit einer Liste von vollständig qualifizierten Domainnamen (FQDN = Fully Qualified Domain Names) von benachbarten MPTs 106 beliefert werden und ein Protokoll zur direkten Kommunikation mit Elementen eines anderen Sektors ohne drahtlose Verbindungen liefern. MPCs 108 enthalten Listen von MPTs 106, für welche diese Service vorsehen. Somit eliminiert die vorliegende Erfindung den Bedarf zum Ausbreiten von redundanter Information durch das Netzwerkmanagementinterface individuell zu jedem Netzwerkelement von einem zentralen Ort. Die vorliegende Erfindung erlaubt den MPT 106 und MPC 108 Netzwerkelementen, dass sie hinzugefügt und entfernt werden von einem drahtlosen Kommunikationsnetzwerk in im Wesentlichen der gleichen Art und Weise, wie ein Router zum Internet dazugefügt oder davon entfernt wird.
  • Die vorliegende Erfindung liefert ein Protokoll, welches erlaubt, dass Netzwerkeinheiten Information von einer Netzwerkeinheit erhalten, wo die Infor mation am einfachsten konfiguriert ist. Das Protokoll ist ein einfaches und flexibles Verfahren zum Auffinden von Information und zum Wissen, für wie lange die Information gültig ist. Die vorliegende Erfindung erlaubt, dass sich Attribute in einem Ort direkt zu anderen Orten ausbreiten, wo sie benötigt werden. Zusätzlich, weil die meisten Informationsveränderungen selten auftreten, gibt das Protokoll nur abgefragte Information zurück, wenn sich die Information seit der letzen solchen Abfrage verändert hat.
  • 3 zeigt ein stark abstrahiertes Blockdiagramm des Informationsabfragevorgangs. In Block 300 wird ein Parameter eines Netzwerkelementes verändert. In Block 302 wird eine Parameterliste, welche in dem Netzwerkelement enthalten ist, aktualisiert, um die Veränderung anzuzeigen. In Block 304 frägt ein entferntes Netzwerkelement die Information in der Liste ab. In Block 306 bestimmt das Netzwerkelement, welches die Liste enthält, ob die Liste aktualisiert wurde, seit der letzten Abfrage von dem abfragenden Element. Wenn die Liste aktualisiert wurde seit der letzen Abfrage wird die aktualisierte Liste zu der abfragenden Einrichtung in Block 307 ansprechend auf die Abfrage gesendet. Wenn in Block 306 das Netzwerkelement, welches die Liste enthält, bestimmt, dass keine Veränderung aufgetreten ist, wird in Block 309 die Liste nicht gesendet, weil das abfragende Element bereits diese Liste hat. Wenn die Liste in Block 307 gesendet wurde, aktualisiert in Block 308 das entfernte Netzwerkelement die Parameterliste dementsprechend.
  • 4 zeigt die Maschineninterfaces, welche in Block 304 verwendet werden, um Information von entfernten Orten abzufragen, und in Block 308, um aktualisierte Information zu senden. In dem exemplarischen Ausführungsbeispiel fragen Netzwerkelemente Attributinformation durch die Verwendung der Hypertexttransferprotokoll (HTTP) GET Nachricht 418 ab. Die Elemente empfangen Information in einer HTTP Antwort 420, welche HTTP Headerfelder 426 und einen Multipurpose Internet Mail Extensions (MIME) Teil 427 enthält. Der MIME Teil 427 besteht aus einem MIME Header 408–414 und einem Körper, welcher eine Liste der abgefragten Attributnamen/Wertpaare 416 enthält.
  • Um mit der HTTP Terminologie konsistent zu sein wird das Netzwerkelement, welches das HTTP GET 418 Verfahren verwendet, um die Attribute abzufragen, als der Client bezeichnet werden, und das Netzwerkelement, welches den Antwort HTTP Header 426 und die abgefragten Attribute 416 in einer MIME Teil Antwort 427 liefert, wird als der Server bezeichnet werden. Das exemplarische Ausführungsbeispiel der vorliegenden Erfindung verwendet die Formate, welche in HTTP Version 1.1 und MIME Version 1.0 beschrieben sind. Die entfernten Clients können nun die aktualisierte Information von dem Serverort 304 abfragen.
  • Der Client frägt die gewünschten Attributwerte unter Verwendung des HTTP GET Verfahrens mit den Attributnamen, welche in dem Abfragefeld des absoluten Universal Resource Identifier (URI) enthalten ist, ab. In dem exemplarischen Ausführungsbeispiel hat die URL 418 die Teilform:
    "http://<element>:<port>/get_attributes?<attributes>"
    wobei das Element 402 der vollständig qualifizierte Domainnamen des versorgenden Elements, Port 403 die Portnummer des Protokolls 404, und die Attribute 406 die gewünschten Attribute, separiert durch „&" sind. Der HTTP Abfrageheader kann auch optionale Felder enthalten, welche in RFC 2068 beschrieen sind. Die vorliegende Erfindung richtet Abfagen immer auf dem optionalen wenn modifiziert weil (If Modified Since) Feld 421 her. Der Client verwendet das If Modified Since Feld 421, um den Server darüber zu informieren, wann er zuletzt die Information aktualisiert hat.
  • Der Server verwendet das If Modified Since 421 Feld der Anforderung 418, um zu bestimmen, ob aktualisierte Information gesendet werden soll. Wenn der Server die Information nicht aktualisiert hat seit der Zeit, welche in dem If Modified Since Feld spezifiziert wurde, gibt der Server eine abgekürzte Nachricht 420 zu dem Client zurück, welche nur HTTP Header 426 Felder ohne MIME Teil-427-Antwort enthalten.
  • Wenn abgefragte Information aktualisiert wurde seit der Zeit, welche in dem If Modified Since Feld spezifiziert ist, wodurch die If Modified Since 418 Bedingung der Abfrage getroffen wird, antwortet der Server mit einem HTTP Header 426 und einem MIME Teil 427, welcher eine Liste von Attributnamen/Wertepaaren 416 für die abgefragten Attribute enthält. Der Server verwirft lautlos alle nicht erkannten Attribute. Der Server fügt das Last Modified (Zuletzt geändert) Feld 425 in den Antwortheader 426 ein. Der Server setzt den Wert des Last Modified Felds 425 auf die Modifikationszeit und das Datum des letzten modifizierten Attributs in der Antwort.
  • Die Antwort auf die Attributabfrage wird in Version 1.0 des experimentellen MIME Subtyps 408 text/x-attribute-list getragen. Dieser MIME Subtyp wird durch das Kontexttypfeld 408 angezeigt. Der Versionsparameter 410 zeigt die Version des x-attribute-list 408 Formats an. Der derzeitige Wert des Versionsparameters 410 ist 1.0. Der Zeichensatzparameter 412 zeigt den verwendeten Zeichensatz an. In dem exemplarischen Ausführungsbeispiel ist der einzige gültige Wert für den Zeichensatzparameter „US-ASCII". Der <element> Parameter 414 zeigt den Netzwerkelementtyp des Servers an. Zum Beispiel zeigen „modem-pool-transceiver" und „modem-pool-controller" an, dass der Server ein Kommunikationsnetzwerk MPT und ein Kommunikationsnetzwerk MPC ist. Der Körper 416 des MIME Teils enthält null oder mehr Felder. Jedes Feld enthält den Namen und den Wert von einem Attribut. Einige Attributfelder 416 werden am leichtesten als Elemente eines Arrays ausgedrückt. Das MIME Typformat 427 nimmt ein einheitliches Verfahren zum Ausdruck eines Arrays als einen Satz von Feldern 416 an. Ein mehrdimensionales Array wird als ein Array von Arrays behandelt. Array-Elemente werden indiziert von 0 ab unter Verwendung von Ganzzahlen. Für ein Attributarray mit dem Attributnamen „X" wird die Anzahl von Elementen in dem Attributarray durch den Attributnamen „X#" repräsentiert. Für ein Attributarray mit dem Attributnamen „X" wird das Element K in dem Attributarray durch den Attributnamen „X[K]" repräsentiert.
  • Wenn die Abfrage den Attributnamen für ein Attributarray enthält, dann enthält die Antwort 420 die Anzahl von Elementen in dem Array und jedes Element in dem Array, wobei die Anzahl von Elementen in dem Array vor allen Elementen in dem Array erscheint.
  • Einige Attribute, wie Attribute, welche Charakteristika eines MPT Nachbars anzeigen, werden am einfachsten als Teil einer Hierarchie ausgedrückt. Das MIME Typ Format 427 nimmt ein einheitliches Verfahren zum Ausdrücken eines Attributs in einer Hierarchie als ein Feld an. Wenn ein Attribut innerhalb einer Hierarchie in ein Feld konvertiert wird, wird es in den Attributnamen „Y.X" konvertiert, wobei „X" der Name des Attributes ist, und Y ist der Attributname des älteren Teils des Attributs. Beispiele des Ausdrückens von Arrays und Hierarchien sind in 8 und 9 beschrieben.
  • Netzwerkelemente machen alle ihre Attribute durch das Abfrageprotokoll der vorliegenden Erfindung verfügbar.
  • 5 ist ein Datenbaumdiagramm eines exemplarischen Ausführungsbeispiels einer teilweisen Datenhierarchie der vorliegenden Erfindung, welches die MPT Datenstruktur illustriert. Es wird vom Fachmann verstanden werden, dass die Hierarchie für illustrative Zwecke präsentiert wird und nicht alle notwendigen Attribute beinhaltet. Zusätzlich können andere Strukturen verwendet werden und sind innerhalb des Umfangs der Präsentation.
  • Location (Ort) 502 ist der hierarchische Stamm von allen Attributen, welche den Ort des MPTs spezifizieren.
  • Translation 504 ist der hierarchische Stamm von allen Attributen, welche den Ort der MPTs spezifizieren. Latitude (Breite) 506 spezifiziert die Breite des MPTs. Die Breite wird in Grad, Minuten und Sekunden ausgedrückt, wobei eine positive Zahl die nördliche Hemisphäre anzeigt. Die Breite reicht von –90 Grad bis +90 Grad. Longitude (Länge) 510 spezifiziert die Länge des MPTs. Die Länge wird in Grad, Minuten und Sekunden ausgedrückt, wobei eine positive Zahl östliche Länge anzeigt. Die Länge reicht von –180 Grad bis +180 Grad. Altitude (Höhe) 508 spezifiziert die Höhe des MPTs. Die Höhe wird in Metern ausgedrückt, wobei eine positive Zahl Höhe über dem Meeresspiegel anzeigt.
  • Rotation (Drehung) 512 ist der hierarchische Stamm von allen Attributen, welche die Orientierung des MPTs bezüglich der Erde spezifizieren. Horizontal (Horizontale) 514 spezifiziert die horizontale Orientierung des MPTs relativ zu Osten. Die horizontale Orientierung wird in Grad, Minuten und Sekunden ausgedrückt, wobei eine positive Zahl die nördliche Hemisphäre anzeigt. Vertical (Vertikale) 516 spezifiziert die relative vertikale Orientierung des MPTs. Die vertikale Orientierung wird in Grad, Minuten und Sekunden ausgedrückt. Die vertikale Orientierung reicht von –90 Grad bis +90 Grad.
  • Temporal (Zeit) 518 spezifiziert die lokale Zeitverschiebung des MPTs relativ zu der Universal Coordinated Time (UTC). Die lokale Zeitverschiebung wird in Stunden, Minuten und Sekunden ausgedrückt. Die lokale Zeitverschiebung reicht von –12 Stunden bis zu +12 Stunden.
  • Antenna (Antenne) 520 ist der hierarchische Stamm von allen Attributen, welche Charakteristika der Antennen des MPTs spezifizieren. Transmit (Sendung) 522 ist ein Array des hierarchischen Stamms von allen Attributen, welche die Charakteristika der Sendeantennen des MPTs spezifizieren. Location (Ort) 540 ist der hierarchische Stamm von allen Attributen, welche den Ort der Sendeantenne relativ zu dem Ort spezifizieren, welcher in dem Ort 502 spezifiziert ist. Beamwidth (Strahlbreite) 542 ist die Strahlbreite der Sendeantenne. Die Strahlbreite wird in Grad ausgedrückt. Die Strahlbreite reicht von 0 bis 360 Grad. Gain (Gewinn) 544 ist der Gewinn der Sendeantenne. Der Sendeantennengewinn wird in Dezibel ausgedrückt. Der Gewinn reicht von 0 bis 100 Dezibel.
  • Receive (Empfang) 524 ist ein Array des hierarchischen Stamms von allen Attributen, welche die Charakteristika der Empfangsantennen des MPTs spezifizieren. Location (Ort) 546 ist der hierarchische Stamm von allen Attributen, welche den Ort der Empfangsantenne relativ zu dem Ort spezifizieren, welcher in Location 502 spezifiziert ist. Beamwidth (Strahlbreite) 548 ist die Strahlbreite der Empfangsantenne. Die Strahlbreite wird in Grad ausgedrückt. Die Strahlbreite reicht von 0 bis 360 Grad. Gain (Gewinn) 550 ist der Gewinn der Empfangsantenne. Der Empfangsantennengewinn wird in Dezibel ausgedrückt. Die Verstärkung reicht von 0 bis 100 Dezibels.
  • Neighbor (Nachbar) 526 ist ein Array des hierarchischen Stamms von allen Attributen, welche die Charakteristika der Nachbarn des MPTs spezifizieren. FQDN 528 enthält den vollständig qualifizierten Domainnamen (FQDN) von dem Nachbar. Cost (Kosten) 530 enthält die Kosten für die Verwendung des Nachbars. Je niedriger die Kosten sind, desto wahrscheinlicher kommuniziert ein AT mit dem MPT, um diesen MPT Nachbar zu sehen. Die Kosten sind nützlich im Beschneiden von Nachbarlisten, welche zu groß sind.
  • Controller (Steuerelement) 532 ist ein Array, welches jeden der MPCs enthält, von welchen der MPT Dienst empfängt. FQDN 534 enthält den vollständig qualifizierten Domainnamen des Steuerelements.
  • Air Interface (Luftinterface) 536 ist der hierarchische Stamm von allen Drahtloskommunikationsnetzwerkluftinterfaceattributen. Der Air Interface 536 Stamm ist erweiterbar auf jedes Luftinterfaceprotokoll. HDR 538 ist ein Beispiel der Erweiterbarkeit des hierarchischen Stamms des Luftinterface 536. HDR ist ein vorgeschlagenes Luftinterface zum Vorsehen von hoher Datenrate. Das HDR Luftinterface ist detailliert in der U.S. Patentanmeldung mit Seriennummer 08/963,386, benannt „METHOD AND APPARATUS FOR HIGHER RATE PACKET DATA TRANSMISSIONS", angemeldet am 3. November 1997, jetzt U.S. Patent mit der Nummer 6,574,211, erteilt am 3. Juni 2003 an Padovani et al., dem Bevollmächtigten der vorliegenden Erfindung zugeordnet und hierin durch Referenz mit aufgenommen, beschrieben. Andere mögliche Luftinterfaceerweiterungen können GSM, IS-95, CDMA2000, und WCDMA einschließen, aber sind nicht darauf eingeschränkt.
  • 6 ist ein Flussdiagramm eines exemplarischen Ausführungsbeispiels einer zu einem gewissen Grade abstrahierten Übersicht der Systemparameterabfrage der vorliegenden Erfindung und des Aktualisierungsmechanismus. Der Fachmann wird verstehen, dass die Anordnung der in 6 gezeigten Schritte nicht einschränkend ist. Ferner werden die Anforderungen für Information logisch integriert werden, wie es auch die Antworten sein werden, und es wird in Erwägung gezogen, dass typischerweise nur ein Untersatz der integrierten Information in den Abfragen und Antworten sein wird. Typischerweise werden Abfragen in einer verbundenen Abfrage für komplexe Sammlungen von Attributen gemacht, und zwar nicht seriell für einzelne Attribute, wie zur Einfachheit gezeigt ist. 6 ist eine Übersicht der in dem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung ausgetauschten Information. Der Informationsabfragevorgang startet in Block 600, wenn ein Client wünscht, Information bezüglich eines Servers zu aktualisieren. In dem exemplarischen Ausführungsbeispiel aktualisiert der Client Information bezüglich der Attribute, welche die MPT Charakteristika des Servers spezifizieren.
  • In Block 601 frägt der Client unter gewissen Bedingungen Ortsinformation 502 ab. Ein detailliertes Flussdiagramm des Ortsinformationsabfrageverfahrens ist in 7 gezeigt. In Block 602 bestimmt der Server, ob sich die abgefragte Ortsinformation in dem Server verändert hat, seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, wie durch das If Modified Since 421 Feld der Abfrage 418 hergerichtet; der Server sendet die neue Ortsattributsinformation in Block 604 und der Prozess fährt mit Block 605 fort. Wenn die abgefragte Information sich nicht verändert hat, sendet der Server Headerfelder 426, aber sendet keinen MIME Teil 427 neuer Ortsattributsinformation, und der Vorgang fährt direkt mit Block 605 fort. Wenn neue Attributinformation in Block 604 gesendet wurde aktualisiert der Client die Ortsattributsinformation dementsprechend.
  • In Block 605 frägt der Client unter gewissen Bedingungen Antenneninformation 512 ab. Ein detailliertes Flussdiagramm des Antennenattributabfrageverfahrens ist in 8 gegeben. In Block 606 bestimmt der Server, ob die abgefragte Antenneninformation sich in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, wie durch das If Modified Since 421 Feld der Abfrage 418 hergerichtet; der Server sendet die neue Antennenattributinformation in Block 608 und der Vorgang fährt mit Block 609 fort. Wenn sich die abgefragte Information nicht verändert hat, sendet der Server Headerfelder 426, aber sendet keinen MIME Teil 427 mit neuer Antennenattributinformation, und der Vorgang fährt direkt mit Block 609 fort. Wenn neue Attributinformation in Block 608 gesendet wurde aktualisiert der Client die Antennenattributinformation dementsprechend.
  • In Block 609 frägt der Client unter gewissen Bedingungen Nachbarinformation 526 ab. Ein detailliertes Flussdiagramm des Nachbarattributabfrageverfahrens wird in 9 gegeben. In Block 610 bestimmt der Server, ob die abgefragte Nachbarinformation sich seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert wurde, verändert hat, wie durch das If Modified Since 421 Feld der Abfrage 418 hergerichtet; der Server sendet die neue Nachbarattributinformation in Block 612; und der Vorgang fährt mit Block 613 fort. Wenn die abgefragte Information sich nicht verändert hat sendet der Server Headerfelder 426, aber sendet keinen MIME Teil 427 mit neuer Nachbarattributinformation, und der Vorgang fährt direkt zu Block 613 fort. Wenn neue Attributinformation im Block 612 gesendet wurde aktualisiert der Client seine Nachbarattributinformation dementsprechend.
  • In Block 613 frägt der Client unter gewissen Bedingungen Steuerungselementinformation 532 ab. Ein detailliertes Flussdiagramm des Steuerungselementattributabfrageverfahrens wird in 10 gegeben. In Block 614 bestimmt der Server, ob sich die abgefragte Steuerungselementinformation in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese In formation von diesem Client spezifiziert ist, verändert hat, wie durch das If Modified Since 421 Feld der Abfrage 418 hergerichtet; der Server sendet die neue Steuerungselementattributinformation in Block 616; und der Vorgang fährt mit Block 617 fort. Wenn die abgefragte Information sich nicht verändert hat, sendet der Server Headerfelder 426, aber sendet keinen MIME Teil 427 mit neuer Steuerungselementattributinformation, und der Vorgang fährt direkt mit Schritt 617 fort. Wenn neue Attributinformation in Block 616 gesendet wurde aktualisiert der Client seine Steuerungselementattributinformation dementsprechend.
  • Im Block 617 frägt der Client unter gewissen Bedingungen Luftinterfaceinformation 536 ab. In Block 618 bestimmt der Server, ob sich die abgefragte Luftinterfaceinformation in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, wie durch das If Modified Since 421 Feld der Abfrage 418 hergerichtet; der Server sendet die neue Luftinterfaceattributinformation in Block 620; und der Vorgang fährt mit Schritt 622 fort. Wenn die abgefragte Information sich nicht verändert hat, sendet der Server Headerfelder 426, aber sendet keine neue Luftinterfaceattributinformation und der Vorgang fährt direkt mit Block 622 fort. Wenn eine neue Attributinformation in Block 620 gesendet wurde aktualisiert der Client seine Luftinterfaceattributinformation dementsprechend.
  • 7 ist ein Flussdiagramm eines exemplarischen Ausführungsbeispiels des Systemparameteraktualisierungsverfahrens für die Ortsattribute 502, welche den Ort von MPT Typ Netzwerkelementen spezifizieren. Die Ortsattribute 502 sind der hierarchische Stamm von allen Attributen, welche den Ort des MPTs spezifizieren. 7 gibt ein detailliertes Flussdiagramm der Ortsattributabfrage 601. Der MPT Ortsinformationsabfragevorgang startet in Block 700, wenn ein Client wünscht, die Ortsinformation eines benachbarten MPT Servers auf dem drahtlosen Kommunikationsnetzwerk zu aktualisieren.
  • In Block 702 frägt der Client Breiteninformation ab. Das Translationsattribut 504 ist der hierarchische Datenstrukturstamm von allen Attributen, welche den physikalischen Ort des MPTs auf der Erde beschreiben. Das Längenattribut 506 spezifiziert die Länge des MPTs, ausgedrückt in Grad, Minuten und Sekunden, wobei eine positive Zahl die nördliche Hemisphäre anzeigt. In Block 702 frägt der Client Breiteninformation 506 von zum Beispiel dem MPT 000.mpt.an.net auf dem Protokollport 10 durch Erteilen der folgenden URI ab, welche auf dem If Modified Since 418 Feld hergerichtet ist:
    „http://0000.mpt.an.net:10/get_attributes?Location.Translation.Latitude"
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von us-ascii, und einen Elementtyp 414 Wert von modem-pool-transceiver, enthält. Wenn sich die abgefragten Informationen in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, sendet der Server ein Last Modified Feld und die neue Breitenattributinformation in der MIME Teil Antwort 427, welche das Namensattribut Namenwert Feld eines Location.Translation.Latitude Werts, ausgedrückt in +1-1dd.mm.ss.f. enthält. Die Breite reicht von –90 Grad bis +90 Grad.
  • In Block 704 frägt der Client Ortstranslationslängeninformation ab. Das Längenattribut 510 spezifiziert die Länge des MPTs, ausgedrückt in Grad, Minuten und Sekunden, wobei eine positive Zahl östliche Länge anzeigt. In Block 704 frägt der Client Längeninformation 510 von dem beispielhaften MPT durch Erteilen der folgenden URI ab, welche auf dem If Modified Since 418 Feld hergerichtet ist:
    http://0000.mpt.an.net:10/get_attributes?Location?Translation.Longitude
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, einer Version 410 von 1.0, einen Zeichensatz 411 Wert von us-ascii, und einen Elementtyp 414 Wert von modem-pool-transceiver enthält. Wenn sich die abgefragte Längeninformation in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert wurde, verändert hat, gibt der Server ein Last Modified Feld und die neue Längenattributinformation in der MIME Teil Antwort 427 zurück, welche das Name-Attribut Name-Wert Feld eines Location.Translation.Longitude Werts enthält, ausgedrückt als + l – dd.mm.ss.f. Die Länge reicht von –180 Grad bis +180 Grad.
  • In Block 706 frägt der Client Ortstranslationshöheninformation ab. Das Höhenattribut 508 spezifiziert die Höhe des MPTs ausgedrückt in Metern, wobei eine positive Zahl Höhe über dem Meeresspiegel anzeigt. In Block 706 frägt der Client Höheninformation 508 von dem beispielhaften MPT durch Erteilen der folgenden URI an, welche auf dem If Modified Since 418 Feld hergerichtet ist:
    http://0000.mpt.an.net:10/get_attributtes?Location.Translation.Altitude
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontext-Typ 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII und einem Elementtyp 414 Wert von Modem-pool-transceiver enthält. Wenn sich die abgefragte Höheninformation in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem gleichen spezifiziert ist, verändert hat, gibt der Server ein Last Modified Feld und die neue Höhenattributinformation in der MIME Teil Antwort 427 zurück, welche das Name-Attribut Name-Wert Feld eines Location.Translation.Altitude Werts enthält, ausgedrückt als + l- m.f.
  • In Block 708 frägt der Client horizontale Orientierungsinformation an. Das Rotationsattribut 512 ist der Stamm bzw. Wurzel (Root) der hierarchischen Datenstruktur von allen Attributen, welche die Orientierung eines MPTs zu der Erde beschreiben. Das Horizontalattribut 514 spezifiziert die horizontale Orientierung des MPTs relativ zu Osten. Die horizontale Orientierung ist in Grad, Minuten und Sekunden ausgedrückt, wobei eine positive Zahl die nördliche Hemisphäre anzeigt. In Block 708 frägt der Client Horizontal 514 Information von dem beispielhaften MPT 0000.mpt.an.net auf dem Protokollport 10 durch Erteilen der folgenden URI ab, welche auf dem If Modified Since 418 Feld hergerichtet wird:
    http://0000.mpt.an.net:10/get_attributes?Location.Rotation.Horiziontal
    auf dem Netzwerk. Der Server antwortet mit einem Header welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII, und einen Elementtyp 414 Wert von Modem-pool-transceiver enthält. Wenn die abgefragte horizontale Orientierungsinformation sich in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, sendet der Server ein Last Modified Feld und die neue horizontale Attributinformation 514 in der MIME Teil Antwort 427, welche das Name-Attribute Name-Wert Feld eines Location.Rotation.Horiziontal Werts enthält, ausgedrückt als + l – dd.mm.ss.f.
  • Die horizontale Orientierung reicht von –180 Grad bis +180 Grad.
  • In Block 710 frägt der Client vertikale Orientierungsinformation ab. Das vertikale Attribut 516 spezifiziert die vertikale Orientierung des MPTs relativ zu einer Linie, welche senkrecht von dem Zentrum der Erde gezeichnet ist. Die vertikale Orientierung ist ausgedrückt in Grad, Minuten und Sekunden. In Block 710 frägt der Client vertikale Information 516 von dem beispielhaften MPT durch Erteilen der folgenden URI ab, welche auf dem If Modified Since 418 Feld hergerichtet ist:
    http://0000.mpt.an.net:10/get_attributes?Location.Rotation.Vertical
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, einer Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII, und einem Elementtyp 414 Wert von Modem-pool-transceiver enthält. Wenn sich die abgefragte vertikale Orientierungsinformation in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, sendet der Server ein Last Modified Feld und die neue vertikale 516 Attributinformation in der MIME Teil Antwort 427, welche das Name-Attribut Name-Wert Feld eines Location.Rotation.Horizontal Werts enthält, ausgedrückt als + l – dd.mm.ss.f. Die vertikale Orientierung reicht von –90 bis +90 Grad.
  • In Block 712 frägt der Client Ortszeitinformation ab. Das Zeitattribut 518 ist der hierarchische Datenstrukturstamm von allen Attributen, welche die Zeitverschiebung eines MPTs beschreiben. Das Zeitattribut 518 spezifiziert die lokale Zeitverschiebung des MPTs relativ zur Universal Coordinated Time (UTC). Die lokale Zeitverschiebung wird in Stunden, Minuten und Sekunden ausgedrückt, wobei eine positive Zahl eine zu UTC hinzugefügte Zeitdifferenz anzeigt. Im Block 712 frägt der Client Zeitinformation 518 von dem beispielhaften MPT durch Erteilen der folgenden URI ab, welche auf dem If Modified Since 418 Feld hergerichtet ist:
    http://0000.mpt.an.net:10/get_attributes?Location.Temporal
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII, und einen Elementtyp 414 Wert von Modem-Pool-Transceiver enthält. Wenn die abgefragte Zeitinformation sich in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, sendet der Server ein Last Modified Feld und die neue Zeitattributinformation in der MIME Teil Antwort 427, welche das Name-Attribut Name-Wert Feld eines Location.Temporal Werts enthält, ausgedrückt als +l – hh.mm.ss.f. Die lokale Zeitverschiebung reicht von –12 Stunden bis +12 Stunden.
  • Die Ortsinformation 502 Abfragen schließen in Block 714 ab, wenn der Client das Abfragen von Ortsinformation eingestellt hat.
  • 8 ist ein Flussdiagramm eines exemplarischen Ausführungsbeispiels des Systemparameteraktualisierungsverfahrens der vorliegenden Erfindung für alle Antennenattribute 520, welche die Charakteristika der Antennen des MPTs spezifizieren. 8 gibt ein detailliertes Flussdiagramm der Antennenattributabfrage 605. Ein MPT Antenneninformationsabfragevorgang startet in Block 800, wenn ein Client wünscht, Antenneninformation von einem MPT Server des drahtlosen Kommunikationsnetzwerks zu aktualisieren.
  • In Block 802 frägt der Client Antennensendeinformation ab. Das Antennenattribut 520 ist der hierarchische Datenstrukturstamm von all den Attributen, welche die Charakteristika der Antenne oder des Satzes von Antennen des MPTs beschreiben. Das Sendeattribut 522 ist ein Array von allen Attributen, welche die Charakteristika der Sendeantennen des MPTs spezifizieren. Location 540 ist der hierarchische Stamm von all den Attributen, welche den Ort der Sendeantenne relativ zu dem Ort, welcher in Location 502 spezifiziert ist, beschreiben. Beamwidth 542 ist die Strahlbreite der Sendeantenne. Die Strahlbreite wird in Grad ausgedrückt. Gain 544 ist der Gewinn der Sendeantenne. Der Gewinn der Sendeantenne wird in Dezibel ausgedrückt.
  • Einige Attribute, wie eine MPT Übertragung 522, werden am leichtesten als ein Element eines Arrays ausgedrückt. Das MIME Teilformat nimmt ein einheitlichen Verfahren zum Ausdrücken eines Arrays als ein Satz von Feldern an. Ein multidimensionales Array wird als ein Array von Arrays behandelt. Arrayelemente werden von 0 an unter Verwendung von Ganzzahlen indiziert. Für ein Attributarray mit dem Attributnamen von „X" wird die Anzahl von Elementen in dem Attributarray durch den Attributnamen „X#" repräsentiert. Für ein Attributarray mit dem Attributnamen „X" wird das Element K in dem Attributarray durch den Attributnamen „X[K]" repräsentiert.
  • Wenn die Abfrage den Attributnamen für ein Attributarray enthält, dann enthält die Antwort 420 die Anzahl von Elementen in dem Array und jedes Element in dem Array, wobei die Anzahl von Elementen mit dem Array vor allen Elementen in dem Array erscheint.
  • In Block 802 frägt der Client Übertragungsarrayinformation 522 von dem beispielhaften MPT mit 1 Sendeantenne ab, und zwar durch Erteilen der folgenden URL, hergerichtet auf dem If Modified Since 418 Feld:
    http://0000.mpt.an.net:10/get_attributes?Antenna.Transmit.Gain&Antenna.Transmit.Beamwidth
    auf dem Netzwerk. Der Sender sendet einen Header, welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII und einen Elementtyp 414 Wert von Modem-pool-transceiver enthält. Wenn die abgefragte Information sich in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, sendet der Server ein Last Modified Feld und die neuen Antennenübertragungsarrayattributinformation in der MIME Teil Antwort 424, welche die Anzahl von Elementen in dem Beispiel Antenna.Transmit Array enthält, ausgedrückt als
    Antenna.Transmit#1,
    wobei der Gewinn der Sendeantenne als Antenna.Transmit„0".Gain:d.f ausgedrückt wird, die Strahlbreite der Sendeantenne wird ausgedrückt als
    Antenna.Transmit[0]Beamwidth:d.f,
    die Strahlbreite reicht von 0 bis 360 Grad. Der Gewinn reicht von 0 bis 100 Dezibel.
  • In Block 804 frägt der Client Empfangsantenneninformation ab. Das Antennenempfangsattribut 524 ist ein Array des hierarchischen Datenstrukturstamms von all den Attributen, welche die Charakteristika der Empfangsantenne des MPTs oder des Satzes von Empfangsantennen spezifizieren. Location 546 ist der hierarchische Stamm von all den Attributen, welche den Ort der Empfangsantenne relativ zu dem Ort, welcher in Location 502 spezifiziert ist, spezifizieren. Beamwidth 548 ist die Strahlbreite der Empfangsantenne. Die Strahlbreite reicht von 0 bis 360 Grad. Gain 550 ist der Gewinn der Empfangsantenne. Der Empfangsantennengewinn wird in Dezibel ausgedrückt.
  • In Block 804 frägt der Client Empfangsantennenarrayinformation 524 von einem Antenne MPT mit einer Empfangsantenne durch Erteilen der folgenden URI an, welche auf dem If Modified Since 418 Feld hergerichtet ist:
    http://0000.mpt.an.net:10/get_attributes?Antenna.Receive.Gain&Antenna.Receive.Beamwidth
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII und einen Elementtyp 414 Wert von Modem-pool-transceiver enthält. Wenn die abgefragte Information sich in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert wurde, verändert hat, gibt der Server ein Last Modified Feld und die neue Antennenempfangsarrayattributinformation in der MIME Teil Antwort 427, welche die Anzahl von Elementen in dem Beispiel Antenna Receive Array, enthält, und zwar ausgedrückt als
    Antenna. Receive#:1,
    der Gewinn der Empfangsantenne wird ausgedrückt als
    Antenna.Receive[0].Gain:d.f,
    die Strahlbreite der Empfangsantenne wird ausgedrückt als
    Antenna.Receive[0].Beamwidth:d.f,
    die Strahlbreite reicht von 0 bis 360 Grad, zurück. Der Gewinn reicht von 0 bis 100 Dezibel.
  • Die Antenneninformation 525 Abfrage wird in Block 806 beendet, wenn der Client das Abfragen von Antenneninformation beendet hat.
  • 9 ist ein Flussdiagramm eines Beispiels der Nachbarattribute 526, welche die Charakteristika der Nachbarn des MPTs spezifizieren. 9 gibt ein detailliertes Flussdiagramm der Nachbarattributabfrage 609. Ein MPT Nachbarinformationsabfrageprozess startet in Block 900 wenn ein Client wünscht, Nachbarinformation von einem MPT Server auf dem drahtlosen Kommunikationsnetzwerk zu aktualisieren.
  • In Block 902 frägt der Client Nachbarinformation ab. Nachbarattribute 526 ist ein Array des hierarchischen Stamms von allen Attributen, welche Charakteristika der Nachbarn des MPTs spezifizieren. Nachbarattribute 526 beinhaltet FQDN Information und Kosteninformation. FQDN Attribute 528 enthält den vollständig qualifizierten Domainnamen (FQDN) des Nachbars. Das Kostenattribut 530 enthält Information über die Verwendung des Nachbarn.
  • Einige Attribute, wie Attribute, welche Charakteristika eines MPT 106 Nachbars repräsentieren, werden am einfachsten als Teil einer Hierarchie ausgedrückt. Der MIME Typ nimmt ein einheitliches Verfahren zum Ausdrücken eines Attributs in der Hierarchie als ein Feld an. Wenn ein Attribut innerhalb einer Hierarchie in ein Feld konvertiert wird, wird es in den Attribut-Namen „Y.X" konvertiert, wobei „X" der Name des Attributs ist, und Y ist der Attribut-Name des älteren Teils des Attributs.
  • Nachbarattribut 526 Information ist sowohl ein Array wie auch eine Hierarchie. In Block 902 frägt der Client Nachbarattributinformation 526 von einer beispielhaften Hierarchie ab. Die beispielhafte Hierarchie enthält ein drahtloses Kommunikationsnetzwerk 110 mit einem MPC 108 und drei MPTs 106. Das MPC 108 hat den FQDN „0000.mpc.an.net". Die MPTs 106 haben in dem Beispiel die FQDNs „0000.mpt.an.net", „0001.mpt.an.net" und „0002.mpt.an.net". Jedes MPT 106 ist ein Nachbar der anderen zwei MPTs 106 und hat keine Weiterleitungskosten.
  • Das MPT 106 speichert Nachbarattribute in dem Array Nachbarattribute 526. Die gespeicherte Information beinhaltet die FQDN Attribute 528 der Nachbarn, die Kostenattribute 530 der Nachbarn, und zwar korrespondierend zu Weiterleitungskosten.
  • In Block 902 frägt der MPC Client 0000.mpc.an.net die gesamte Information über die Nachbarn von MPT 0000.mpt.an.net durch Erteilen der folgenden URI ab, und zwar hergerichtet auf dem If Modified Since 418 Feld:
    http://0000.mpt.an.net/get_attributes?Neighbor
    auf dem Netzwerk.
  • Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII, und einen Elementtyp 414 Wert von modem-pool-transceiver enthält. Wenn sich die abgefragte Information in den Servern seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert wurde, verändert hat, antwortet der Server mit einem Last Modified Feld und der gesamten neuen Nachbararrayhierarchieinformation in der MIME Teil Antwort 427. Zusätzlich enthält der Körper 416 die Name-Attribute Name-Wert Felder für die Anzahl von Nachbarn, welche das Steuerelement in dem Beispiel hat, und zwar ausgedrückt als
    Neighbor#:2
    Der FQDN des ersten Nachbars, ausgedrückt als
    Neighbor[0].FQDN:0001.mpt.an.net
    Die Kosten des ersten Nachbars, ausgedrückt als
    Neighbor[0].Cost:0
    Der FQDN des zweiten Nachbars, ausgedrückt als
    Neighbor[1].FQDN:0002.mpt.an.net
    Und die Kosten des zweiten Nachbars, ausgedrückt als
    Neighbor[1].Cost:0
  • Die Nachbarattribut 526 Informationsabfrage wird beendet, in Block 904, wenn der Client damit fertig ist, Nachbarhierarchieinformation abzufragen.
  • 10 ist ein Flussdiagramm eines exemplarischen Ausführungsbeispiels der Systemparameteraktualisierungsprozedur der vorliegenden Erfindung, für die Attribute, welche die MPC Netzwerktypen spezifizieren, von welchen die MPT Netzwerktypen Dienst abfragen. 10 liefert ein detailliertes Flussdiagramm der Steuerungselementattribut 613 Abfrage. Ein Steuerungsinformationsabfragevorgang startet in Block 1000 wenn ein Client wünscht, Steuerungselementinformation zu aktualisieren, von welcher ein MPT Server Dienst empfangen kann.
  • In Block 1002 frägt der Client Steuerungsinformation ab. Das Steuerungselementattribut 532 ist der hierarchische Datenstrukturstamm der FQDN Attribute 534, korrespondierend zu den MPCs, welche ein MPT verwenden kann.
  • In Block 1002 frägt der Client das FQDN Attribut 534 ab, zum Beispiel von einem MPT mit 1 MPC. Im Block 1002 erteilt der Client die folgende URL, hergerichtet auf dem If Modified Since 418 Feld.
    http://0000.mpt.an.net:10/get_attributes?Controller
    auf dem Netzwerk. Der Server antwortet mit einem Header, welcher einen Kontexttyp 408 von text/x-attribute-list, eine Version 410 von 1.0, einen Zeichensatz 412 Wert von US-ASCII und einen Elementtyp 414 Wert von Modem-pool-transceiver enthält. Wenn sich die abgefragte Information in dem Server seit der Zeit, welche in dem If Modified Since Feld für diese Information von dem Client spezifiziert ist, verändert hat, sendet der Server ein Last Modified Feld und die neue Steuerungselemetarrayattributinformation in der MIME Teil Antwort 427, welche die Anzahl von Elementen in dem beispielhaften Steuerungselementarray enthält, ausgedrückt als Controller#:1, und der Domainname ausgedrückt als Controller[0].FQDN:0001.mpc.an.net.
  • 11 ist ein Blockdiagramm, welches die Vorrichtung zeigt, welche verwendet wird, um die Attributabfrageoperation der vorliegenden Erfindung auszuführen. Der Zugriffspunkt 1100A besteht aus Netzwerkelementen und einem Netzwerkinterface 1104A, wie ein IP Router. Das Netzwerkinterface 1104A ist eine Einrichtung, welche den nächsten Netzwerkpunkt bestimmt, zu welchem ein Datenpaket in Richtung seines Ziels weitergeleitet werden soll, und verbindet ein Netzwerkelement mit einem IP Netzwerk über eine Vielzahl von Überbringerdiensten. Das Netzwerkelement kann MPT (10, 106 oder 206), MPC (14, 108 oder 200) oder Netzwerkzugriffsserver (18, 104 oder 208) sein. Nur für illustrative Zwecke ist der Teil der Netzwerkelemente, welche für die Attributabfrageoperation relevant sind, in dem Netzwerkelement gezeigt.
  • Das Netzwerkelement enthält eine Speichereinrichtung 1110A, welche die Attribute des Netzwerkelements 1100 speichert, wobei die Attribute eine Liste von FQDNs von anderen Netzwerkelementen, welche durch das Netzwerkelement abgefragt werden sollen, enthält. Der Steuerungsprozessor 1106A empfängt ein Signal von dem Abfragenachrichtengenerator 1102A, und zwar anzeigend für einen Bedarf von Information von einem anderen Netzwerkelement. Der Steuerungsprozessor 1106A erhält einen FQDN von dem Speicherelement 1100A, und zwar ansprechend auf das Signal von dem Abfragenachrichtgenerator 1102A und im Zusammenhang mit dem Sig nal und der FQDN generiert er eine Abfragenachricht. Der Steuerungsprozessor 1106A liefert die Nachricht zu dem Netzwerkinterface 1104A, welches die Nachricht zu dem geeigneten Netzwerkelement 1106B weiterleitet. Das Netzwerkinterface 1104B richtet die Abfragenachricht zu dem Netzwerkelement 1112B. Die Abfragenachricht wird zu dem Steuerungsprozessor 1106B geliefert. Ansprechend auf die Abfragenachricht frägt der Steuerungsprozessor 1106B Information bezüglich der abgefragten Attribute von dem Speicher 1110B ab. Der Antwortnachrichtgenerator 1108B liefert Nachrichtpacketinformation zu dem Steuerungsprozessor 1106B. Der Steuerungsprozessor 1106B generiert ansprechend auf die Information von dem Speicher 1110B und dem Antwortgenerator 1108B eine Antwortnachricht, welche er zu dem Netzwerkinterface 1104B liefert. Das Netzwerkinterface 1104B richtet die Antwortnachricht zu dem Steuerungsprozessor 1106A in dem Zugriffspunkt 1100A.
  • Wenn die Attributinformation in der Antwortnachricht von Element 1100B neu ist, dann aktualisiert der Steuerungsprozessor 1106A die Information in dem Speicherelement 1110A. Es wird vom Fachmann verstanden werden, dass die reziproke Operation des Abfragens des Netzwerkelements durch einfaches Umdrehen der A's und B's durchgeführt werden kann.
  • 12 ist ein Flussdiagramm eines exemplarischen Ausführungsbeispiels des Verfahrens der vorliegenden Erfindung zum Abfragen und Zwischenspeichern von Attributinformation, um Verarbeitung und Netzwerkverkehr zu verringern. Das Clientabfrage- und Serverzwischenspeicherverfahren, welches in 12 gezeigt ist, erlaubt dem Client, nur gesendete Information abzufragen, wenn sich die Information verändert hat, und verhindert, dass der Server wiederholt die gleiche Antwort erzeugt und zurückgibt.
  • Block 1222 zeigt die clientseitige Zustandsabfrage. In HTTP kann das GET Verfahren nach mehreren unterschiedlichen Kriterien hergerichtet werden. Dies erlaubt, dass der Client anfordert, dass der Server nur Information sendet, wenn sich die Information verändert hat. Von besonderer Verwendung ist in diesem Abfrageprotokoll der If Modified Since Zustand. Die Verwendung des If Modified Since Zustands verringert Netzwerkverkehr und Clientverarbeitung. In Block 1200 verwendet der Client ein GET Verfahren, welches auf dem If Modified Since Feld hergerichtet ist, um Attributinformation abzufragen. In Block 1202 bestimmt der Client, ob der Server mit aktualisierter MIME Teil 427 Attributinformation geantwortet hat. Wenn der Server mit aktualisierter MIME Teil 427 Information geantwortet hat, in Block 1204, speichert der Client das jüngste Last Modified Since Feld 425 der Antwort von jeder unterschiedlichen Abfrage zu jedem Server zwischen, zur Verwendung in zukünftigen Abfragen. Wenn der Client eine Abfrage zu einem Server in Block 1200 wiederholt, setzt der Client das If Modified Since Feld 421 auf den Wert des zurückgegebenen Last Modified Felds 425.
  • Der Block 1224 zeigt das serverseitige Zwischenspeicherverfahren der vorliegenden Erfindung. In vielen Fällen werden Protokolle, welche dieses Abfrageprotokoll verwenden, Abfragen verwenden, welche immer die gleichen sind. Zusätzlich werden in vielen Fällen Protokolle, welche dieses Abfrageprotokoll verwenden, nach Attributen abfragen, welche sich selten verändern, welche als statische Attribute bekannt sind. Als ein Ergebnis erzeugen derzeitige Server wiederholt die gleiche Antwort und geben diese zurück. Durch das Zwischenspeichern von Abfrageantworten, welche nur statische Attribute enthalten, verringert die vorliegende Erfindung die Serververarbeitung. In der vorliegenden Erfindung markiert der Server bestimmte Attribute als „statisch". Attribute, welche als „statisch" markiert sind, sollen Attribute sein, welche sich selten verändern. Zum Beispiel sind Attribute, welche hart codiert sind (wie Protokollrevisionen) und Attribute, welche sich nur während Netzwerkaufbau und Optimierung verändern (wie Nachbarlisten) gute Kandidaten, um als „statisch" markiert zu werden. Andererseits sind Attribute, welche sich als eine Funktion der Belastung verändern (wie verfügbare Bandbreite) schlechte Kandidaten, um als „statisch" markiert zu werden. In Block 1206 verändert der Server ein statisches Attribut. In Block 1208 verwirft der Server alle zwischengespeicherten Antworten, wann immer eines der Attribute, welche als „statisch" markiert sind, modifiziert wird. Dies wird einige gespeicherte Seiten unnötigerweise verwerfen (to flush). Weil sich jedoch „statische" Attribute per Definition selten verändern ist der Einfluss des unnötigen Speicherverwurfs minimal. Der Server stellt sicher, dass der Zwischenspeicher verworfen wird, wenn irgendein Attribut in der Abfrage verändert wurde. Der Server bekommt viele der Vorteile des Zwischenspeichers unter Verwendung eines einfachen konservativen Zwischenspeicherverwerfungs bzw. löschungsalgorithmus.
  • In Block 1210 empfängt der Server eine Attributabfrage von einem Client. In Block 1212 bestimmt der Server, ob ein Zwischenspeicher für die abgefragte Information existiert. Wenn der Zwischenspeicher vorher aufgrund einer Attributveränderung verworfen (flushing) wurde, baut der Server einen neuen Zwischenspeicher in Block 1220 auf, und die Steuerung fährt mit dem Block 1214 fort. Anderenfalls fährt die Steuerung direkt mit dem Block 1214 fort.
  • In Block 1214 bestimmt der Server, ob sich die abgefragte Information verändert hat, seit der letzten solchen Abfrage unter Verwendung des If Modified Since Felds 421 der Abfrage. Wenn sich die Information nicht verändert hat, wird nur der HTTP Antwortheader 426 zurückgegeben, wie in Block 1218 gezeigt ist. Wenn sich die abgefragte Information verändert hat seit der Zeit, welche in dem If Modified Since Feld spezifiziert ist, dann gibt der Server in Block 1216 den HTTP Antwortheader 426 und die MIME Teil-427-Antwort von dem Zwischenspeicher zurück.
  • 13 ist ein Blockdiagramm, welches die Vorrichtung zeigt, welche verwendet wird, um Paginginformationsauffindung mit dem Zugriffsnetzwerkpaginginformationsprotokoll durchzuführen. Das Zugriffsnetzwerkpaginginformationsprotokoll erlaubt einem MPC 1300, dynamisch den Pagingbereich 1302 von ATs 1306A, 1306B, 1306C zu bestimmen, welche das MPC 1300 steuert.
  • Wenn ein AT untätig ist, oder eine aktive Sitzung und keine aktive Verbindung hat, beliefert das AT 1306 das Zugriffsnetzwerk mit regulären Ortsaktu alisierungen. Es gibt mehrere Trigger, welche verursachen, dass ein AT 1306 das Zugriffsnetzwerk mit einer Ortsaktualisierung versorgt.
  • Das MPC Element 1300 sieht Dienst zu einer Sammlung von einem oder mehreren MPT Elementen 1308 über das IP Netzwerk 1304 vor. Ein AT 1306 aktualisiert, oder registriert, seinen Ort mit MPC 1300 durch Senden seiner Ortsinformation zu dem MPT 1308, in welchem es sich befindet. Das MPT 1308 leitet die Ortsinformation zu dem MPC 1300 über das IP Netzwerk 1304 weiter. Die MPC 1300 lokalisiert das AT 1306 durch Paging des AT 1306 in all den MPTs 1302, in welchen das AT 1306 platziert sein kann. Die Sammlung von MPTs 1302, wo ein AT platziert sein kann, ist der Pagingbereich 1302 des ATs.
  • 14 zeigt einen AT Pagingbereich. In einem Ausführungsbeispiel wird ein Protokoll für MPCs zum Bestimmen von Pagingbereichen ohne die Intervention eines zentralen Netzwerkmanagers geliefert. Der Pagingbereich wird durch die AT 1404 Ortsaktualisierungsprozeduren, bekannt als Registrierung, bestimmt. Die AT 1404 Bewegung durch das Zugriffsnetzwerk kann Ortsregistrierung mit MPCs basierend auf unterschiedlichen Kriterien einschließlich Distanz 1406 und Zone 1400A oder beidem benötigen, und zwar abhängig davon, welche Typen von Ortsregistrierung in dem AT 1404 aktiviert sind. Ein Registrierungsbereich korrespondiert zu dem berichteten MPT 1402 der Ortsaktualisierung, zuzüglich aller anderen MPTs, zu welchem sich das AT 1404 ohne erneute Registrierung nicht bewegen kann, weil keine Distanz oder Grenzzone überquert wurde. Mit anderen Worten ist der Registrierungsbereich der Bereich, in welchem das AT 1404 ohne den Bedarf für erneute Registrierung angeordnet sein kann. Dieser Bereich wird durch die Registrierungsdistanz und die Registrierungszone bestimmt. Wenn ein AT innerhalb der Registrierungsdistanz von dem letzten AT ist, in welchem das AT registriert ist, und innerhalb der gleichen Registrierungszone ist, dann ist das AT in dem gleichen Registrierungsbereich.
  • Der Pagingbereich ist eine Liste von MPTs 1402, 1403, in welchen das AT zu irgendeinem gegebenen Zeitpunkt angeordnet sein kann. Die Liste enthält die MPTs 1402, welche in dem Registrierungsbereich des ATs angeordnet sind, und alle anderen Nachbarn 1403. Die Nachbarn 1403 der MPTs 1402 in dem Registrierungsbereich sind in dem Pagingbereich beinhaltet, um der Tatsache Rechnung zu tragen, dass das AT eine Zeit ungleich Null braucht, um zu detektieren, dass eine Ortsaktualisierung durchgeführt werden muß, und um die Ortsaktualisierung durchzuführen. Mit anderen Worten kann das AT in ein benachbartes MPT überquert haben, bevor eine Ortaktualisierung bei dem MPC aufgetreten ist.
  • Wenn zonenbasierte Registrierung bei dem AT 1404 aktiviert ist muß das AT 1404 eine Ortsaktualisierung durchführen, wenn das AT 1401 von einer Zone 1400a zu einer benachbarten Zone 1400b überquert. Wenn distanzbasierte Registrierung bei dem AT 1404 aktiviert ist, muß das AT 1404 eine Ortsaktualisierung durchführen, wenn sich das AT 1404 weiter als eine Distanz R 1406 seit der letzten Ortsaktualisierung bewegt. Der Pagingbereich, welcher erzeugt wurde, ist das MPT 1402, wo das AT 1404 als letztes sich selbst berichtet hat, dass es dort angeordnet ist, und ein Ring von benachbarten MPTs 1403 um das MPT 1402. Pagingbereiche hängen von den Werten der Distanz- und Zonenortsaktualisierungstrigger ab. Wenn die Werte dieser Trigger sich zwischen MPTs unterscheiden können, sind sie unabhängig von dem AT. Registrierungsdistanzen 1406 und Zonen 1400 sind durch den Dienstanbieteroperator für jedes MPT derart konfiguriert, dass sie die Menge von Registrierungsverkehr gegen die Menge von Pagingverkehr auf dem Netzwerk ausgleichen. Das Pagingauffindeprotokoll und der Pagingbereichsalgorithmus für die derzeit beschriebenen Ausführungsbeispiele bestimmen, wo ein AT zu pagen ist, welches sich durch das Zugriffsnetzwerk bewegt, basierend auf der konfigurierten Information und dem letzten registrierten Ort.
  • Jedes MPT hat seinen eigenen Pagingbereich. Ein Sektor kann eines oder mehrere MPTs haben. Wenn ein Sektor mehr als ein MPT hat, kommunizie ren die MPTs mit ATs auf unterschiedlichen Frequenzen. Ein benachbartes MPTs in einem benachbarten Sektor ist bekannt als ein horizontaler Nachbar. Ein benachbartes MPT in dem gleichen Sektor, welches auf einer unterschiedlichen Frequenz betrieben wird, ist als ein vertikaler Nachbar bekannt.
  • 15 ist ein stark abstrahiertes Blockdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel zum Durchführen von Paginginformationsauffindung in einem drahtlosen Kommunikationssystem.
  • Distanz- und Zonenaktualisierungstrigger erlauben dem Zugriffsnetzwerk, den Pagingbereich für ein AT zu verringern.
  • Wenn distanzbasierte Ortsaktualisierung aktiviert ist, dann wird das AT eine Ortsaktualisierung durchführen, nachdem es sich weiter als die Ortsaktualisierungsdistanz bewegt hat, seit das AT zum letzten Mal eine Ortsaktualisierung durchgeführt hat. Wenn zonenbasierte Ortsaktualisierung aktiviert ist, dann wird das AT eine Ortsaktualisierung durchführen, nachdem es sich in eine Ortsaktualisierungszone bewegt hat, welche unterschiedlich von der Ortsaktualisierungszone ist, in welchem das AT die letzte Ortsaktualisierung durchgeführt hat.
  • Die Blöcke 1500 bis 1510 zeigen die Pagingfunktionalität des ATs. In Block 1500 bestimmt das AT, ob die distanzbasierte Ortsaktualisierung aktiviert ist. Wenn distanzbasierte Ortsaktualisierung aktiviert ist, bestimmt das AT in Block 1502, ob sich seine Distanz um mehr als eine konfigurierte Registrierungsdistanz verändert hat. Anderenfalls fährt die Steuerung direkt zu Block 1506 fort. Wenn in Block 1502 das AT bestimmt hat, dass sich seine Distanz um mehr als den Distanztrigger verändert hat, führt das AT in Block 1504 eine Ortsdistanzaktualisierung durch und die Steuerung geht zu Block 1506 über. Wenn keine Distanzaktualisierung notwendig ist in Block 1504, geht die Steuerung zu Block 1506 über.
  • In Block 1506 bestimmt das AT, ob die zonenbasierte Ortsaktualisierung aktiviert ist. Wenn zonenbasierte Ortsaktualisierung aktiviert ist bestimmt das AT in Block 1508, ob das AT sich in eine Ortsaktualisierungszone bewegt hat, welche unterschiedlich ist von der Ortsaktualisierungszone, in welchem das AT die letzte Ortsaktualisierung durchgeführt hat. Wenn die zonenbasierte Ortsaktualisierung nicht aktiviert ist, bricht die AT Verarbeitung ab, und zwar bis zu dem nächsten Aktualisierungsintervall. Wenn in Block 1508 das AT bestimmt hat, dass sich seine Zone verändert hat, führt in Block 1510 das AT eine Ortszonenaktualisierung durch, und die AT Verarbeitung bricht ab, und zwar bis zu dem nächsten Aktualisierungsintervall. Wenn keine Zonenaktualisierung in Block 1510 notwendig ist bricht die AT Verarbeitung bis zu dem nächsten Aktualisierungsintervall ab. Aktualisierungsintervalle werden durch eine Zustandsmaschine bestimmt, welche jedes Mal ausgeführt wird, wenn sich das AT in die Abdeckung eines neuen MPTs bewegt.
  • Wenn ein AT eine Ortsaktualisierung durchführt wird die Ortsaktualisierung zu dem MPT weitergeleitet, welcher den AT Dienst liefert. Wenn das MPC keinen Dienst für den MPT liefert, welcher die Ortsaktualisierung erhalten hat, dann werden ein oder zwei Dinge passieren. Wenn das AN (access network) MPC Übergabe unterstützt, dann wird das AT zu einem MPC übergegeben, welches Dienst für den MPT liefert, welcher die Ortsaktualisierung empfangen hat. Wenn das Zugriffsnetzwerk keine MPC Übergabe unterstützt, dann wird die Sitzung beendet werden und das AT wird eine neue Sitzung aufbauen müssen. Die neue Sitzung wird mit einem MPC aufgebaut werden, welches Dienst für den MPT liefert, welcher die Ortsaktualisierung empfangen hat. Als ein Ergebnis muß die Anzahl von Pagingbereichen, über welche ein bestimmtes MPC Wissen haben muß und darüber Information behalten muß, verringert werden.
  • Die Blöcke 1512 bis 1514 zeigen die individuellen Pagingfunktionalitätsaufgaben des MPTs. Der MPT empfängt Ortsaktualisierungen von ATs in dem Aufgabenblock 1512. In dem Aufgabenblock 1514 leitet das MPT die Ortsaktualisierungen zu dem MPC weiter, welches das MPT bedient, und leitet Pa gingnachrichten, welche von dem MPC empfangen wurden, zu ATs weiter. Der MPT antwortet auf Pagingauffindeattributabfragen von dem MPC in dem Aufgabenblock 1515.
  • Die Blöcke 1516 bis 1520 zeigen die individuellen Pagingfunktionalitätsaufgaben des MPCs. In dem Aufgabenblock 1516 empfängt das MPC AT Ortsaktualisierungen, welche durch das MPT weitergeleitet wurden, und verwendet die Information, um aktualisierte Pagingbereiche für das AT in dem Aufgabenblock 1518 zu bestimmen. Das MPC sendet Pagingnachrichten zu untätigen ATs in dem Aufgabenblock 1520. Die Pagingbereichbestimmung und AT Pagingfunktionalität des MPCs sind detailliert mit Bezug auf 17 beschrieben.
  • 16 ist ein Datenbaumdiagramm eines exemplarischen Ausführungsbeispiels einer teilweisen Datenhierarchie der vorliegenden Erfindung, welches Paginginformationsauffindeattribute zeigt, welche eine Erweiterung des Luftinterface 536 Stamms sind. Es wird vom Fachmann verstanden werden, dass die Hierarchie für illustrative Zwecke gegeben wird, und nicht alle notwendigen Attribute enthält. Zusätzlich können andere Strukturen verwendet werden und sind innerhalb des Umfangs der vorliegenden Erfindung.
  • Airinterface 1600 ist der hierarchische Stamm von allen Interfaceattributen.
  • HDR 1602 ist der hierarchische Stamm von allen HDR Luftinterfaceattributen.
  • Protocol (Protokoll) 1603 ist der hierarchische Stamm von allen HDR Luftinterfaceattributen, welche durch den Protokolltyp und den Protokollsubtyp organisiert sind.
  • Type_08 1604 ist der hierarchische Stamm von allen HDR Luftinterfaceattributen, welche mit dem HDR Protokolltyp 8, dem Overheadprotokoll, verbunden sind.
  • SubType_0000 1606 ist der hierarchische Stamm von allen HDR Luftinterfaceattributen, welche mit dem HDR Protokolltyp 8, dem Routenaktualisierungsprotokoll und dem Protokollsubtyp 0, dem voreingestellten Overheadprotokoll, verbunden sind.
  • AccessNetworkID (Zugriffsnetzwerk ID) 1608 spezifiziert das Zugriffsnetzwerk, zu welchem das MPT gehört.
  • SectorID (Sektor ID) 1610 spezifiziert den Sektor, zu welchem der MPT gehört.
  • ChannelFrequency (Kanalfrequenz) 1612 spezifiziert die Kanalfrequenz des MPTs.
  • Type_10 1614 ist der hierarchische Stamm von allen HDR Luftinterfaceattributen, welche mit dem HDR Protokolltyp 10, dem Routenaktualisierungsprotokoll, verbunden sind.
  • SubType_0000 1616 ist der hierarchische Stamm von allen HDR Luftinterfaceattributen, welche mit dem HDR Protokolltyp 0x10, dem Routenaktualisierungsprotokoll und Protokollsubtyp 0, dem voreingestellten Routenaktualisierungsprotokoll, verbunden sind.
  • Latitude (Breite) 1618 spezifiziert die Breite des ATs. Dieses Attribut ist äquivalent zu dem Attribut Location.Translation.Latitude 506.
  • Longitude (Länge) 1620 spezifiziert die Länge des ATs. Dieses Attribut ist äquivalent zu dem Attribut Location.Translation.Longitude 510.
  • LocationUpdateDistanceEnabled (Ortsaktualisierungsdistanz aktiviert) 1622 ist ein boolesches Attribut, welches anzeigt, ob distanzbasierte Ortsaktualisierung aktiviert ist oder nicht.
  • LocationUpdateDistance (Ortsaktualisierungsdistanz) 1624 ist die Ortsaktualisierungsdistanz.
  • LocationUpdateZoneEnabled (Ortsaktualisierungszone aktiviert) 1626 ist eine boolesche Variable, welche anzeigt, ob zonenbasierte Ortsaktualisierung aktiviert ist oder nicht.
  • LocationUpdateZone (Ortsaktualisierungszone) 1626 ist die Ortsaktualisierungszone.
  • 17 ist ein Blockdiagramm, welches eine Pagingbereichsbestimmung und ein AT Paging Verfahren gemäß einem Ausführungsbeispiel zeigt.
  • Pagingbereichsbestimmung und AT Paging sind MPC Funktionen. Jedes MPC baut eine Datenbank auf, welche die Pagingbereiche von jedem AT enthält, für welche das MPC Dienst liefert.
  • Eine naheliegende Implementierung der Datenbank kann einen oder mehrere Pagingbereichseinträge pro AT haben. Weil ein MPC bis zu eintausend ATs pro MPT bedienen kann, kann diese Implementierung zu einer sehr großen Datenbank führen. Zusätzlich, weil mobile ATs sich häufig bewegen, kann diese Implementierung zu einer großen Anzahl von Datenbankaktualisierungen führen. Jedoch implementiert die vorliegende Erfindung die Datenbank auf eine effizientere Art und Weise.
  • Pagingbereiche hängen von den Werten der Distanz- und Zonenortsaktualisierungstrigger ab. Während die Werte dieser Trigger zwischen MPTs unterschiedlich sein können, sind die Werte unabhängig von dem AT. Deshalb hat die Pagingbereichsdatenbank der vorliegenden Erfindung einen Pagingbereichseintrag pro MPT, anstatt einem Pagingbereichseintrag pro AT. Weil mehrere ATs wahrscheinlich in dem gleichen MPT angeordnet sind, verringert das Aufweisen von nur einem Eintrag pro MPT die Größe der Datenbank.
  • Wenn ein AT eine Ortsaktualisierung durchführt wird die Ortsaktualisierung zu dem MPC weitergeleitet, welches dem AT Dienst liefert. Wenn dieses MPC keinen Dienst für den MPT liefert, welcher die Ortsaktualisierung liefert, wird die vorliegende Erfindung eine oder zwei Antworten liefern. Wenn das Zugriffsnetzwerk keine MPC Übergabe unterstützt, dann wird das AT zu einem MPC übergegeben, welches Dienst für den MPT liefert, welcher die Ortsaktualisierung empfangen hat. Wenn das Zugriffsnetzwerk MPC Übergabe unterstützt, dann wird die Sitzung beendet werden und das AT wird eine neue Sitzung aufbauen müssen. Die neue Sitzung wird mit einem MPC aufgebaut, welches Dienst für den MPT liefert, welcher die Ortsaktualisierung empfangen hat. Als ein Ergebnis vereinfacht das vorliegende Ausführungsbeispiel ferner die Pagingbereichsdatenbank.
  • Weil ein MPC ATs, welche Ortsaktualisierungen in MPTs durchführen, welche das MPC nicht bedient, entweder übergeben oder freigeben wird, muß die Datenbank der vorliegenden Erfindung nur einen Pagingbereichseintrag für jeden MPT enthalten, für welchen die Datenbank Dienst liefert. In dem Fall, in welchem die MPCs innerhalb der Zugriffspunkte angeordnet sind, wird die Datenbank des vorliegenden Ausführungsbeispiels Einträge nur für MPTs enthalten, welche in dem gleichen Zugriffspunkt sind.
  • Das MPT führt anfängliche Füllung seiner Datenbank in Block 1700 aus. Um die Pagingbereichsdatenbank zu füllen, verwendet jedes MPC den Algorithmus des vorliegenden Ausführungsbeispiels, um den Pagingbereich für jeden MPT zu bestimmen, für welchen es Dienst liefert. Das vorliegende Ausführungsbeispiel findet Pagingbereichsveränderungen alle 20 Minuten durch verursachen auf, dass das MPC den Pagingbereich alle 15 Minuten für jedes MPT erneut bestimmt, für welchen es Dienst liefert. Zusätzlich bestimmt das MPC erneut den Pagingbereich, wann immer das MPC zurückgesetzt wird, wie nach einer Firmwareaktualisierung oder einem Stromausfall. Schließlich erlaubt das vorliegende Ausführungsbeispiel, dass das MPC den Pagingbereich, welcher unter dem Kommando des Operators steht, erneut bestimmt.
  • Die erste Bestimmung des Pagingbereichs wird in dem Block 1702 durchgeführt. Wenn der Pagingbereich für einen MPT zuerst bestimmt wird, führt das MPC das Folgende aus.
  • Beim Starten des Stamm-MPTs folgt das MPC rekursiv der Nachbarliste, bis eines der Anhaltekriterien erfüllt ist. Der Stamm-MPT ist der MPT, für welchen das MPC den Pagingbereich bestimmt. Wenn distanzbasierte Ortsaktualisierung auf dem Stamm-MPT aktiviert ist, dann hält die Rekursion an, wenn die Distanz zwischen dem Stamm-MPT und dem abgefragten MPT die Ortsaktualisierungsdistanz des Stamm-MPTs übersteigt. Wenn zonenbasierte Ortsaktualisierung aktiviert ist auf dem Stamm-MPT, dann hält die Rekursion an, wenn die Zone des abgefragten MPTs unterschiedlich ist von der Zone des Stamm-MPTs. Der MPT Pagingbereich ist die Liste von allen MPTs, welche abgefragt wurden.
  • Der Pagingbereich beinhaltet alle MPTs, in welchen ein AT keine Ortsaktualisierung durchführen würde, wenn das AT eine Ortsaktualisierung in dem Stamm-MPT durchgeführt hätte. Zusätzlich beinhaltet der Pagingbereich die Nachbarn der vorhergehend benannten MPTs. Die Nachbarn sind beinhaltet, um der Tatsache Rechnung zu tragen, dass ein AT eine Zeit ungleich Null benötigt, um zu detektieren, dass eine Ortsaktualisierung durchgeführt werden muss, und um die Ortsaktualisierung durchzuführen.
  • Der Algorithmus des vorliegenden Ausführungsbeispiels schneidet die MPTs ab, in welchem ein AT gepagt wird, und zwar basierend auf dem Ortsaktualisierungsbereich. Jedoch schneidet der Algorithmus MPTs nicht ab, in welchen das AT gepagt ist, und zwar basierend auf dem AT Identifizierer. Ein Zugriffsknoten des Zugriffsnetzwerks ist ein Einzel-Abdeckungs-, Einzelfrequenzpunkt der Verbindung zu einem Zugriffsnetzwerk. Ein Zugriffsknoten ist der grundlegende Baustein des Zugriffsnetzwerks. Der Zugriffsknoten ist durch einen Sektor (SectorID) 1610 und eine Trägerfrequenz (ChannelFrequency) identifiziert. Ein Sektor des Zugriffsnetzwerks ist eine Sammlung von einem oder mehreren Kanälen mit dem gleichen geographischen Abdeckbereich und SectorID 1610.
  • Wenn ein Zugriffspunkt mehrere Zugriffsknoten enthält, muss eine Pagenachricht für ein bestimmtes AT nur zu dem Zugriffsknoten gesendet werden, zu welchem das AT gehasht wird, oder erfolgreich zu einem AT Pagenachrichtadressschlüssel des Zugriffsknoten passen. Hashing ist die Transformation einer AT Adresse in einen (normalerweise kürzeren) Wert von fester Länge, oder Schlüssel, welcher die ursprüngliche Adresse repräsentiert. Hashing wird verwendet, um den Eintrag in einer Datenbank zu indizieren und zu erhalten, weil es schneller ist, den Eintrag unter Verwendung des kürzeren, gehashten Schlüssels zu finden, anstatt ihn unter Verwendung des ursprünglichen Werts zu finden.
  • Der Algorithmus kann ferner die MPT Pagingliste durch Eliminieren von allen Zugriffsknoten in einem Zugriffsport verringern, zu welchem das AT nicht hashen wird, oder eine Adressschlüsselübereinstimmung erreichen. Jedoch verringert das vorliegende Ausführungsbeispiel nicht die MPT Pagingliste durch Eliminieren von allen Zugriffsknoten in einem Zugriffsport, zu welchem das AT nicht hashen wird, und zwar aus dem folgenden Grund. Wenn ein Zugriffsknoten innerhalb des Zugriffsports fehlschlägt, werden einige ATs, welche durch den Zugriffsport abgedeckt sind, zu unterschiedlichen Zugriffsknoten hashen. Wenn die Zugriffsknotenpagingliste abgeschnitten wurde, um nur die Zugriffsknoten zu enthalten, zu welchen das AT ursprünglich gehasht hat, dann müsste die Zugriffsknotenpagingliste aktualisiert werden, wann immer ein solcher Zugriffsknotenfehler aufgetreten ist. Der Dienstausfall, welcher von solchen Zugriffsknotenfehlern resultiert, ist verbunden mit der MPT Paginglistenaktualisierungsrate. Als ein Ergebnis würde das Abschneiden der Zugriffsknotenpagingliste derart, dass sie nur die Zugriffsknoten beinhaltet, zu welchen das AT hasht, unnötigerweise die MPT Paginglistenaktualisierungsrate erhöhen.
  • Nachdem zunächst ein Pagingbereich bestimmt wurde, bestimmt das MPC regulär erneut den Pagingbereich in Block 1704. Die erneute Bestimmung ist die Gleiche wie die erste Bestimmung 1702, mit einer Ausnahme. In der ersten Bestimmung, wenn ein abgefragtes MPT nicht antwortet, dann hält die Rekursion durch dieses MPT an. Wenn jedoch in erneuter Bestimmung das abgefragte MPT nicht antwortet, dann nimmt die Rekursion an, dass die Konfiguration unverändert ist seit der letzten Abfrage und fährt fort. Dies macht das Protokoll tolerant gegenüber temporären MPT Ausfällen. Weil das vorliegende Ausführungsbeispiel tolerant gegenüber Ausfällen ist, müssen Listen nicht in jedem MPT für jedes Auftreten eines temporären Ausfalls eingestellt werden. Die Listen konfigurieren sich dynamisch selbst, wobei jede Zelle Paginginformationsauffindung selbst durchführt. Das vorliegende Ausführungsbeispiel eliminiert den Bedarf dafür, dass Pagingbereiche durch einen zentralen Manager in dem Ereignis eines temporären Zellenausfalls erneut konfiguriert werden. Dieses Merkmal des vorliegenden Ausführungsbeispiels eliminiert Pagingbereichsinformationsausbreitungsfehler und Systemversagen, welche durch Pagingversagen verursacht werden. Zusätzlich, wenn Träger Registrierungsdistanzen oder Zonen verändern, muß die Liste nicht manuell durch einen zentralen Netzwerkmanager verändert werden. Stattdessen sieht das vorliegende Ausführungsbeispiel ein Verfahren zum automatischen Aktualisieren der Pagingbereiche unter Verwendung der Paginginformationsauffindung und Zugriffsnetzwerkattributabfrageprotokolle vor.
  • Die erste Bestimmung des Pagingbereichs und die erneute Bestimmung benötigen, dass der MPT nach Information abfrägt, wie in Block 1706 gezeigt ist. Das MPC führt die Abfragen unter Verwendung des Zugriffsnetzwerkattributabfrageprotokolls aus. Das MPC frägt das MPT mit If Modified Since hergerichteten HTTP GET Abfragen 418 für die folgenden Parameter aus: „Neighbor.FQDN" 528, „AirInterface.HDR.Protocol.Type_08.Subtype_0000" 1606, und „AirInterface.HDR.Protocol.Type_Subtype_0000" 1616.
  • Es kann sein, dass das MPC nicht alle diese Attribute für einen spezifischen MPT benötigt. Jedoch anstatt unterschiedliche Abfragen für die spezifischen Attribute zu erzeugen, welche das MPC von jedem MPT benötigt, wird eine einzige Abfrage, welche die Vereinigung von all den Attributen ist, durch das Protokoll des vorliegenden Ausführungsbeispiels erzeugt. Dies wird derart durchgeführt, dass jeder MPT die gleiche Abfrage von jedem MPC empfangen wird. Deshalb wird der MPT nur benötigen, eine Abfrageantwort zwischen zu speichern. Das MPC wird jedoch die Attribute, welche es benötigt, verwerten müssen.
  • Das MPC verwendet die Attribute „AirInterface.HDR.Protocol.Type_08.Subtype_0000.AccessNetworkID" 1608, „AirInterface.HDR.Protocol.Type_08.Subtype_0000.SectorID" 1610, und „AirInterface.HDR.Protocol.Type_08.Subtype_0000.ChannelFrequency" 1612, von der Abfrageantwort.
  • Wenn das abgefragte MPT das Stamm MPT ist, dann verwendet das MPC die zusätzlichen Attribute „AirInterface.HDR.Protocol.Type_10.Subtype_0000.Latitude" 1618, „AirInterface.HDR.Protocol.Type_10.Subtype_0000.Longitude" 1620, „AirInterface.HDR.Protocol.Type_10.Subtype_0000.LocationUpdateDistanceEnabled" 1622, „AirInterface.HDR.Protocol.Type_10.Subtype_0000.LocationUpdateDistance" 1624, „AirInterface.HDR.Protocol.Type_10.Subtype_0000.LocationUpdateZoneEnabled" 1626, und "AirInterface.HDR.Protocol.Type_10.Subtype_0000.LocationUpdateZone 1628" von der Abfrageantwort 420.
  • Wenn distanzbasierte Ortsaktualisierung auf dem Stamm-MPT aktiviert ist, dann verwendet das MPC die zusätzlichen Attribute "AirInterface.HDR.Protocol.Type_10.Subtype_0000.Latitude" 1618, und "AirInterface.HDR.Protocol.Type_10.Subtype_0000.Longitude" 1620 von der Abfrageantwort 420.
  • Wenn zonenbasierte Ortsaktualisierung auf dem Stamm-MPT aktiviert ist, dann verwendet das MPC die zusätzlichen Attribute „AirInterface.HDR.Protocol.Type_10.Subtype_0000.LocationUpdateZone" 1628 von der Abfrageantwort 420.
  • In Block 1708 pagen MPCs ATs, welche Dienst von den MPCs empfangen, unter Verwendung des Pagingprotokolls des vorliegenden Ausführungsbeispiels. Wenn ein AT gepagt wird sendet das MPC eine Pagenachricht zu einem oder mehreren MPTs.
  • Jede Pagenachricht, welche durch das MPC gesendet wird, beinhaltet den Identifizierer für den AT, welcher gepagt wird. Dies erlaubt einem MPT, Pagenachrichten basierend darauf, ob das AT die Zugriffsknoten des MPTs hashen wird oder nicht, zu verwerfen.
  • Das MPC sendet eine Kopie der Pagenachricht zu jedem MPT in dem Pagebereich. Die IP Adresse, welche von dem MPT für seine Pagingressource verwendet wird, kann eine Unicast, Multicast oder Broadcast Adresse sein.
  • Es wird erlaubt, dass die IP Adresse der Pagingressource des MPTs eine Multicast und Broadcast Adresse ist, damit die Anzahl von Pagenachrichtenkopien, welche das MPC senden muß, verringert wird, wodurch der Pagingverkehr auf dem Zugriffsnetzwerk verringert wird.
  • Wenn entweder distanzbasierte oder zonenbasierte Ortsaktualisierung aktiviert ist, beinhaltet die Pagingnachricht einen einzigartigen Über die Luft Identifizierer, welcher die AccessNetworkID 1608 und SectorID 1610 für jeden MPT in dem Pagingbereich enthält. Dies erlaubt einem MPT, Pagenachrichten zu verwerfen, für welche der MPT nicht zur Sendung zuständig ist.

Claims (8)

  1. Ein Verfahren zum Bestimmen von zellularen Paging- bzw. Funkrufbereichen eines drahtlosen Kommunikationsnetzwerks, wobei das Verfahren Folgendes aufweist: anfängliches Bevölkern bzw. Füllen (1700) einer Pagingbereichsdatenbank, und zwar beginnend mit einem Root- bzw. Stammmodem-Pool-Transceiver abgekürzt als MPT (1402); Senden von Anfragen direkt an die Nachbarn (1403) des Stamm-MPTs (1402), um hinsichtlich einer Nachbarliste, enthalten in einem jeden der Nachbarn (1403) des Stamm-MPTs, nachzufragen; Empfangen der Nachbarliste enthalten in einem jeden der Nachbarn (1403) des Stamm-MPTs; rekursives Folgen von Nachbarlisten der Nachbarn (1403) des Stamm-MPTs, die auf das Stamm-MPT (1402) antworten, und zwar um die Pagingbereichsdatenbank anfänglich mit den Nachbarn des Stamm-MPTs zu füllen bzw. zu belegen; Beenden des rekursiven Folgens der Nachbarlisten der Nachbarn (1403) des Stamm-MPTs bei Erfüllung eines Stoppkriteriums; und periodisches Neubestimmen (1704) des Pagingbereichs.
  2. Verfahren nach Anspruch 1, das weiterhin Folgendes aufweist: Beenden des rekursiven Folgens der Nachbarlisten von MPTs, die auf das Stamm-MPT (1402) antworten, wenn distanzbasierte Ortsaktualisierung beim Stamm-MPT (1402) aktiviert ist und ein abgefragtes MPT die Ortsaktualisierungsdistanz des Stamm-MPTs (1402) überschreitet.
  3. Verfahren nach Anspruch 1, das weiterhin Folgendes aufweist: Beenden des rekursiven Folgens von Nachbarlisten der MPTs, die auf das Stamm-MPT (1402) antworten, wenn zonenbasierte Ortsaktualisierung in dem Stamm-MPT (1402) aktiviert ist und ein ab gefragtes MPT sich in einer unterschiedlichen Zone befindet als das Stamm-MPT (1402).
  4. Ein Verfahren nach Anspruch 1, wobei das periodische Neubestimmen des Pagingbereichs beinhaltet, dass angenommen wird, dass die Konfiguration unverändert ist, seit der letzten Abfrage, wenn das MPT nicht antwortet.
  5. Eine Vorrichtung zum Bestimmen von zellularen Pagingbereichen eines drahtlosen Kommunikationsnetzwerks, wobei die Vorrichtung Folgendes aufweist: ein Root- bzw. Stamm-MPT mit einem Speicher, der eine Pagingbereichsdatenbank enthält; einen Anfragenachrichtengenerator zum Senden von Anfragen direkt zu den Nachbarn (1403) des Stamm-MPTs (1402), Nachfragen hinsichtlich einer Nachbarliste, die in jedem der Nachbarn (1403) des Stamm-MPTs enthalten ist; ein Netzwerkinterface zum Empfangen von Nachbarlisten, enthalten in jedem der Nachbarn (1403) des Stamm-MPTs; einen Steuerprozessor zum rekursiven Folgen von Nachbarlisten der MPTs, die auf das Stamm-MPT (1402) antworten, und zwar um anfänglich die Pagingbereichsdatenbank mit den Nachbarn des Stamm-MPTs (1402) zu bevölkern bzw. zu belegen und zum Beenden des rekursiven Folgens der Nachbarlisten von MPTs, wenn ein Stoppkriterium erfüllt ist; ein Programm innerhalb des Steuerprozessors zum periodischen Neubestimmen des Pagingbereichs.
  6. Vorrichtung gemäß Anspruch 5, wobei der Steuerprozessor das rekursive Folgen von Nachbarlisten der MPTs, die auf das Stamm-MPT (1402) antworten, beendet, wenn distanzbasiertes Ortsaktualisieren auf dem Stamm-MPT aktiviert ist und ein abgefragtes MPT die Ortsaktualisierungsdistanz des Stamm-MPTs (1402) überschreitet.
  7. Vorrichtung nach Anspruch 5, die weiterhin aufweist, dass der Steuerprozessor das rekursive Folgen von Nachbarlisten von MPTs, die auf das Stamm-MPT (1402) antworten, beendet, wenn zonenbasiertes Ortsaktualisieren auf dem Stamm-MPT aktiviert ist und ein abgefragtes MPT sich in einer unterschiedlichen Zone als das Stamm-MPT (1402) befindet.
  8. Vorrichtung nach Anspruch 5, wobei der Steuerprozessor periodisch den Pagingbereich neu bestimmt und annimmt, dass die Konfiguration seit der letzten Anfrage unverändert ist, wenn ein MPT nicht antwortet.
DE60032616T 1999-09-27 2000-09-27 Verfahren und system zum abfragen von merkmalen in einem zellularen kommunikationssystem Expired - Lifetime DE60032616T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US406452 1989-09-13
US40645299A 1999-09-27 1999-09-27
US16332799P 1999-11-03 1999-11-03
US163327P 1999-11-03
US480710 2000-01-07
US09/480,710 US6850494B1 (en) 1999-09-27 2000-01-07 Method and system for querying attributes in a cellular communications system
PCT/US2000/026429 WO2001024557A1 (en) 1999-09-27 2000-09-27 Method and system for querying attributes in a cellular communications system

Publications (2)

Publication Number Publication Date
DE60032616D1 DE60032616D1 (de) 2007-02-08
DE60032616T2 true DE60032616T2 (de) 2007-11-15

Family

ID=27388871

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60032616T Expired - Lifetime DE60032616T2 (de) 1999-09-27 2000-09-27 Verfahren und system zum abfragen von merkmalen in einem zellularen kommunikationssystem

Country Status (7)

Country Link
EP (1) EP1216588B1 (de)
CN (1) CN1376369B (de)
AT (1) ATE349866T1 (de)
AU (1) AU7617000A (de)
BR (1) BR0014299A (de)
DE (1) DE60032616T2 (de)
WO (1) WO2001024557A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2826808B1 (fr) 2001-06-29 2005-04-08 Evolium Sas Procede de gestion de ressources de traitement dans un systeme de radiocommunications mobiles
JP4295934B2 (ja) 2001-09-28 2009-07-15 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、無線基地局及び一斉呼び出し方法
MY148183A (en) 2006-10-31 2013-03-15 Qualcomm Inc Inter-enode b handover procedure
MX2009007855A (es) * 2007-02-12 2009-08-18 Ericsson Telefon Ab L M Mejora en agrupacion de red.
US9392504B2 (en) 2007-06-19 2016-07-12 Qualcomm Incorporated Delivery of handover command
EP2154918B1 (de) * 2008-08-13 2012-02-01 Alcatel Lucent Dezentralisiertes Verfahren zur Handhabung eines Zellenausfalls in einem Funknetz
US9148477B2 (en) * 2009-01-29 2015-09-29 Qualcomm Incorporated Methods and apparatus for communicating in a wireless system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ZA948134B (en) * 1993-10-28 1995-06-13 Quaqlcomm Inc Method and apparatus for performing handoff between sectors of a common base station
US5892916A (en) * 1997-12-23 1999-04-06 Gehlhaar; Jeff B. Network management system and method using a partial response table

Also Published As

Publication number Publication date
EP1216588A1 (de) 2002-06-26
AU7617000A (en) 2001-04-30
CN1376369B (zh) 2010-12-15
DE60032616D1 (de) 2007-02-08
BR0014299A (pt) 2002-08-27
CN1376369A (zh) 2002-10-23
EP1216588B1 (de) 2006-12-27
WO2001024557A1 (en) 2001-04-05
ATE349866T1 (de) 2007-01-15

Similar Documents

Publication Publication Date Title
DE60225645T2 (de) Verfahren und zugehörendes Gerät zur verteilten dynamischen Funkrufzonengruppierung in einem heterogenen Zugangsnetz
EP1465443B1 (de) Verfahren und Vorrichtung zur Behandlung von ortsbasierten Diensten
DE602004008353T2 (de) Unlizenzierte funkzugangsnetze in zellularen mobilfunknetzen
DE10296925B4 (de) Globales Ausrufen von Mobilstationen in einem drahtlosen Netz unter Verwendung eines MSC-Pools
DE102005001267B4 (de) Effizienter und schlanker Algorithmus zur Informationsverbreitung für mobile drahtlose Ad hoc-Netzwerke
DE60126845T2 (de) Auswahl einer MSC aus einem Pool von MSCs zur Kommunikation mit einem Zugangsknoten in einem zellularen Mobilfunknetz
DE69833939T2 (de) Kommunikationssystem mit standort-informationsübertragung für streifende mobilstationen
DE60127423T2 (de) Verfahren und vorrichtung für deckungssteuerung von multicastdiensten in einem drahtlosen netz
DE102019103055A1 (de) Management von funkeinheiten in cloud radio access netzwerken
DE69734306T2 (de) Zwei-wege schnurloses Nachrichtensystem
DE60035989T2 (de) Verfahren und vorrichtung zur rundsendung von systeminformation in einem zellularen kommunikationsnetz
EP0760192B1 (de) Verfahren zur teilnehmerdatenübertragung bei einem wechsel des funkkommunikationssystems
DE602004000808T2 (de) Verfahren zur Abfrage eines elektronischen Briefkastens
DE60203667T2 (de) Verfahren und System zum Steuern eines Kommunikationsnetzes und eines im Netz angewandten Routers
DE60209448T2 (de) Verfahren und System zur dynamischen Einordnung beweglicher Objekte
DE10297189T5 (de) Ortsverwaltungssystem und Paging-Server in einem drahtlosen IP-Netz
DE60222818T2 (de) System und Verfahren zur Auswahl eines Unterstützungsknotens in einem Funkkommunikationssystem
DE69929193T2 (de) Verfahren zur steuerung von kommunikation sowie kommunikationssystem
DE112016003238T5 (de) Demokratisierte zellulare netzwerkverbindungsfähigkeit durch kleine zellen
DE602004004991T2 (de) Automatisierte Installation von Netzgeräten mit Informationen über Regeln, Authentifizierung und gerätespezische Daten
DE202006005732U1 (de) Vorrichtung zum Koordinieren einer nahtlosen Kanalumschaltung in einem Maschennetz
US6850494B1 (en) Method and system for querying attributes in a cellular communications system
DE60032616T2 (de) Verfahren und system zum abfragen von merkmalen in einem zellularen kommunikationssystem
DE112006001712B4 (de) Auf dem Address Resolution Protocol basierendes drahtloses Zugriffspunktverfahren und entsprechende Vorrichtung
DE602004011893T2 (de) Verfahren und System zur Besserung eines level-3 Weiterreichens

Legal Events

Date Code Title Description
8364 No opposition during term of opposition