PatentDe  


Dokumentenidentifikation DE112006000314T5 20.12.2007
Titel Verfahren und System von Software-Architekturen für die Netzwerkverwaltung von mobilen drahtlosen Breitbandnetzwerken
Anmelder Intel Corporation, Santa Clara, Calif., US
Erfinder Chou, Joey, Scottsdale, Ariz., US;
Ovadia, Shlomo, San Jose, Calif., US
Vertreter BOEHMERT & BOEHMERT, 28209 Bremen
DE-Aktenzeichen 112006000314
Vertragsstaaten AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KM, KN, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, LY, MA, MD, MG, MK, MN, MW, MX, MZ, NA, NG, NI, NO, NZ, OM, PG, PH, PL, PT, RO, RU, SC, SD, SE, SG, SK, SL, SM, SY, TJ, TM, TN, TR, TT, TZ, UA, UG, US, UZ, VC, VN, YU, ZA, ZM, ZW, EP, AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, IE, IS, IT, LT, LU, LV, MC, NL, PL, PT, RO, SE, SI, SK, TR, OA, BF, BJ, CF, CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, TG, AP, BW, GH, GM, KE, LS, MW, MZ, NA, SD, SL, SZ, TZ, UG, ZM, ZW, EA, AM, AZ, BY, KG, KZ, MD, RU, TJ, TM
WO-Anmeldetag 31.01.2006
PCT-Aktenzeichen PCT/US2006/003443
WO-Veröffentlichungsnummer 2006083897
WO-Veröffentlichungsdatum 10.08.2006
Date of publication of WO application in German translation 20.12.2007
Veröffentlichungstag im Patentblatt 20.12.2007
IPC-Hauptklasse H04L 12/24(2006.01)A, F, I, 20060131, B, H, DE
IPC-Nebenklasse H04L 12/28(2006.01)A, L, I, 20060131, B, H, DE   

Beschreibung[de]
GEBIET DER ERFINDUNG

Das Gebiet der Erfindung betrifft im allgemeinen drahtlose Kommunikationsnetzwerke und betrifft genauer, jedoch nicht ausschließlich ein Verfahren und ein System von Software-Architekturen für die Netzwerkverwaltung von mobilen Breitbandnetzwerken.

HINTERGRUNDINFORMATION

Der IEEE (Institute of Electrical and Electronic Engineers) 802.16 ist eine auftretende Folge von Funkschnittstellenstandards für einen kombinierten festen, tragbaren und mobilen drahtlosen Breitbandzugriff (MBWA – Mobile Broadband Wireless Access). Anfänglich als ein Funkstandard konzipiert, um eine kostengünstige Breitband-Anschlußmöglichkeit auf der letzten Meile für diejenigen zu ermöglichen, die nicht durch verdrahtetes Breitband, so wie Kabel oder DSL, bedient werden, entwickeln sich die Spezifikationen, um eine größere Marktgelegenheit für mobile Hochgeschwindigkeits-Breitbandanwendungen ins Auge zu fassen. Die Architektur des IEEE 802.16 spricht nicht nur das traditionelle Problem der „letzten Meile" an, sondern unterstützt auch herumreisende und bewegliche Kunden bei ihrem umtriebigen Leben. Die MBWA-Architektur wird von der Worldwide Interoperability for Microwave Access (WiMAX) forum Network Working Group (NWG) standardisiert. Aus Gründen der Bequemlichkeit werden die Ausdrücke 802.16 und WiMAX in dieser Beschreibung austauschbar verwendet, um sich auf die Folge der IEEE 802.16 der Funkschnittstellenstandards zu beziehen.

1 zeigt ein vereinfachtes drahtloses Breitbandnetzwerk mit einer zellenähnlichen Architektur von Punkt-zu-Multipunkt (PMP) zum Betrieb bei sowohl lizensierten und lizenzfreien Frequenzbändern typischerweise unterhalb von 11 GHz. Andere Typen der Architekturen (nicht gezeigt), so wie vermaschte drahtlose Breitbandnetzwerke, sind zulässig. Ein Basis-IP (Internet Protocol)-Netzwerk 100 ist mit einem drahtlosen Breitbandnetzwerk verbunden, wobei Funkzugangsknoten (RANs – Radio Access Nodes) 102A und 102B verwendet werden. Jeder RAN ist über eine verdrahtete Verbindung, so wie eine optische Faser (veranschaulicht als optische Faserverbindungen 103A, 103B und 103C) oder drahtlose Verbindungen von Punkt zu Punkt (nicht gezeigt) mit einer oder mehreren Funkzellen (veranschaulicht zwischen RAN 102A oder 102B zu Funkzellen 104A, 104B und 104C) verbunden. An dem Netzknoten einer Funkzelle befindet sich eine jeweilige Basisstation (BS) 106A, 106B und 106C. Ein Basisstation-System umfaßt ein hochentwickeltes Antennensystem (AAS – Advanced Antenna System), welches sich typischerweise oben auf einem Funkturm befindet und verwendet wird, um Hochgeschwindigkeitsdaten an mehrere Teilnehmerstationen (SSs – Subscriber Stations) 108 und mobile Teilnehmerstationen (MSSs – Mobile Subscriber Stations) 109 zu senden und Daten von den Teilnehmerstationen über unidirektionale drahtlose Verbindungen 110 zu empfangen (jede SS-Uplink-Sendung ist von den anderen unabhängig). Genauer kann jede SS 108 auf das Netzwerk 100 (über eine geeignete BS) zugreifen, indem die PHY + MAC (Physikalische + Medienzugangssteuerung)-Merkmale verwendet werden, die durch den IEEE P802.16 Funkschnittstellenstandard definiert sind. Eine SS kann einem festen Teilnehmerort entsprechen (z.B. in einem Haus oder Büro) oder kann einem mobilen Teilnehmer entsprechen, der auf das drahtlose Breitbandnetzwerk über ein mobiles Gerät (MSS) zugreift, so wie einem persönlichen digitalen Assistenten (PDA), einem Laptop-Computer usw.

Das Übertragen von Datenimpulsen von dem Netzwerk 100 zu einer SS 108 geschieht in der folgenden Weise. Die Datenimpulse, so wie IP-Pakete oder Ethernet-Frames werden von einem geeigneten RAN zu einer geeigneten BS innerhalb einer gegebenen Zelle geschickt. Die BS verkapselt die Daten in dem IEEE 802.16-2004 Datenframeformat und sendet dann außerhalb der Sichtlinien (NLOS -Non-Line-Of-Sight) Daten an jede SS 108, wobei eine unidirektionale drahtlose Verbindung 110 verwendet wird, welche als „Downlink" bezeichnet wird. Das Senden von Daten von einer SS 108 an das Netzwerk 100 geschieht in der umgekehrten Richtung. In diesem Fall werden die verkapselten Daten von einer SS an eine geeignete BS gesendet, wobei eine unidirektionale drahtlose Verbindung verwendet wird, die als ein „Uplink" bezeichnet wird. Die Datenpakete werden dann an einen geeigneten RAN geschickt, in IP-Pakete oder Ethernet-Frames umgewandelt und schließlich an einen Zielknoten in dem Netzwerk 100 gesendet. Datenpulse können gesendet werden, indem entweder Frequenzduplex (FDD – Frequency Division Duplexing)-, Halbduplex-FDD- oder Zeitduplex (TDD – Time Divion Duplexing)-Schemata verwendet werden. In dem TDD-Schema nutzen sowohl der Uplink als auch der Downlink denselben HF-Kanal, senden jedoch nicht gleichzeitig, und in dem FDD-Schema arbeiten der Uplink und der Downlink auf unterschiedlichen HF-Kanälen, jedoch werden die Kanäle gleichzeitig gesendet.

Mehrere BSn werden so aufgebaut, daß sie ein zellenähnliches drahtloses Netzwerk bilden. Ein Netzwerk, das ein gemeinsam genutztes Medium verwendet, erfordert einen Mechanismus, es in effizienter Weise gemeinsam zu nutzen. Innerhalb jeder Zelle ist die Architektur des drahtlosen Netzwerks ein Zweiwege-PMP, welches ein gutes Beispiel eines gemeinsam genutzten Mediums ist; hier ist das Medium der Raum (die Luft), durch die sich die Funkwellen fortpflanzen. Der Downlink, von der Basisstation (BS) zu einer SS, arbeitet auf einer PMP-Basis. Vorschriften innerhalb des Standards IEEE 802.16-2004 und dem Entwurf IEEE 802.16eD5a (Dezember 2004) umfassen eine zentrale BS mit einem AAS innerhalb jeder Zelle. Ein solches AAS umfaßt eine sektorisierte Antenne, die in der Lage ist, mehrere unabhängige Sektoren gleichzeitig zu behandeln. Bei dieser Art des Aufbaus können die Arbeitsgänge der Basisstationen, die unten beschrieben sind, für jeden der unabhängigen Sektoren implementiert werden, so daß mehrere gemeinsam angeordnete Basisstationen mit mehreren Sektorantennen, die einen gemeinsamen Controller nutzen, in dem Netzwerk eingesetzt werden können. Innerhalb eines gegebenen Frequenzkanals und eines Antennensektors empfangen alle Stationen dieselbe Sendung oder Teile dieser.

In der anderen Richtung nutzen die Teilnehmerstationen den Uplink zu der BS auf einer Anfragebasis gemeinsam. Abhängig von der verwendeten Diensteklasse können der SS kontinuierliche Rechte zum Senden verliehen werden, oder das Recht zu senden kann von der BS nach dem Empfang einer Anfrage von einer SS erteilt werden. Zusätzlich zu individuell adressierten Nachrichten können Nachrichten auch auf Mehrpunktverbindungen geschickt werden (Steuernachrichten und Videoverteilung sind Beispiele von Mehrpunktverbindungsanwendungen) ebenso wie als Rundruf an alle Stationen. Innerhalb jedes Sektors halten sich die Benutzer an ein Sendeprotokoll, das die Verträglichkeit zwischen den Benutzern steuert und es dem Dienst ermöglicht, an die Verzögerungen und Anforderungen an die Bandbreite jeder Benutzeranwendung angepaßt zu sein.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Die voranstehenden Aspekte und viele der begleitenden Vorteile dieser Erfindung werden leichter erkannt, während dieselbe besser durch Bezugnahme auf die folgende genaue Beschreibung verstanden wird, wenn diese zusammen mit den beigefügten Zeichnungen gelesen wird, wobei gleiche Bezugsziffern sich bei den verschiedenen Ansichten auf gleiche Teile beziehen, wenn nicht anders angegeben:

1 ist ein schematisches Schaubild eines beispielhaften drahtlosen Breitbandnetzwerkes mit Punkt-zu-Multipunkt-Topologie basierend auf der Folge der Standards IEEE 802.16;

2 ist ein schematisches Schaubild eines Netzwerkverwaltungs-Referenzmodells für eine Architektur eines drahtlosen Breitbandnetzwerkes mit mobilen Teilnehmerstationen (MSSs), gemäß einer Ausführungsform der Erfindung;

3a ist ein schematisches Schaubild eines Protokollschichtreferenzmodells mit Netzwerkverwaltung für MSSs in einem drahtlosen Breitbandzugangs (BWS – Broadband Wireless Access)-Netzwerk mit entsprechender Softwarearchitektur der Steuer-, Daten- und Verwaltungsebene gemäß einer Ausführungsform der Erfindung;

3b ist ein schematisches Schaubild des Protokollschicht-Referenzmodells mit Netzwerkverwaltung der 3a, das weiter Nachrichtenströme im Zusammenhang mit dem Wiedergewinnen von Parametern von einer MSS veranschaulicht;

3c ist ein schematisches Schaubild des Protokollschicht-Referenzmodells mit Netzwerkverwaltung der 3a, das weiter Nachrichtenströme in Verbindung mit dem Senden von Parametern an eine MSS veranschaulicht;

4a4e sind schematische Darstellungen einer Verwaltungsinformations (Daten)-Bank (MIB – Management Information (Data Base))-Struktur, die bei dem Netzwerkverwaltungs-Referenzmodell der 2 benutzt wird, um das Bereitstellen des Netzwerkes und Verwaltungsarbeitsgänge zu vereinfachen;

5 ist ein Ablaufdiagramm, das Arbeitsgänge veranschaulicht, die durchgeführt werden, um Parameter aus einer MSS gemäß einer Ausführungsform der Erfindung zu gewinnen;

6a ist eine Tabelle, die das Format einer TLV-Anfragenachricht zeigt;

6b ist eine Tabelle, die das Format einer TLV-Antwortnachricht zeigt;

7 ist ein Ablaufdiagramm, das Arbeitsgänge veranschaulicht, welche durchgeführt werden, um dynamische Dienstestromparameter an eine MSS bereitzuhalten, wobei ein Proxi Simple Netzwork Management Protocol (SNMP)-Agent an einer Basisstation verwendet wird;

8 ist ein Ablaufdiagramm, das Arbeitsgänge veranschaulicht, die während des Bereithaltens von Diensteströmen für eine mobile Teilnehmerstation gemäß einer Ausführungsform der Erfindung durchgeführt werden;

9 ist ein Ablaufdiagramm, welches Einzelheiten der Arbeitsgänge zum Bereitstellen der Diensteströme gemäß Block 804 in 8 veranschaulicht;

10 ist ein Ablaufdiagramm, welches Einzelheiten der Downloadoperation von dynamischen Dienstestromparametern des Blocks 806 in 8 veranschaulicht;

11 ist ein Ablaufdiagramm, das Arbeitsgänge und Logik veranschaulicht, welche während einer Ausführungsform einer Übergabeprozedur ausgeführt werden, die verwendet wird, um eine Funkschnittstelle für eine MSS von einer Dienste leistenden BS zu einer Ziel-BS zu überführen;

12 ist ein Ablaufdiagramm, das Einzelheiten der Übergabeprozedur-Arbeitsgänge des Blocks 1108 in 11 veranschaulicht;

13 ist ein Ablaufdiagramm, das Einzelheiten der Downloadoperation für die dynamischen Dienstestromparameter nach Block 1112 in 11 veranschaulicht; und

GENAUE BESCHREIBUNG

Hierin werden Ausführungsformen eines Verfahrens und von Systemen von Software-Architekturen, um Netzwerkverwaltung zu unterstützen und die Bereitstellung von Diensten für mobile drahtlose Breitbandnetzwerke beschrieben. In der folgenden Beschreibung werden zahlreiche bestimmte Einzelheiten aufgeführt, um für ein gründliches Verständnis von Ausführungsformen der Erfindung zu sorgen. Ein Fachmann wird jedoch erkennen, daß die Erfindung ohne eine oder mehrere der bestimmten Einzelheiten in die Praxis umgesetzt werden kann, oder mit anderen Verfahren, Komponenten, Materialien usw. In anderen Fällen sind gut bekannte Strukturen, Materialien oder Arbeitsgänge nicht gezeigt oder nicht in Einzelheiten beschrieben, um das Verschleiern von Aspekten der Erfindung zu vermeiden.

Die Bezugnahme in dieser Beschreibung auf „eine Ausführungsform" bedeutet, daß ein bestimmtes Merkmal, eine Struktur oder eine Eigenschaft, die in Verbindung mit der Ausführungsform beschrieben ist, in wenigstens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit ist das Auftreten des Ausdrucks „bei einer Ausführungsform" an verschiedenen Stellen in dieser Beschreibung nicht notwendigerweise auf dieselbe Ausführungsform bezogen. Weiterhin können bestimmte Merkmale, Strukturen oder Eigenschaften bei einer oder mehreren Ausführungsformen in irgendeiner geeigneten Weise kombiniert werden.

Einer der wichtigeren Aspekte, die in auf 802.16 basierenden drahtlosen Breitbandnetzwerken ausgestaltet ist, ist die Fähigkeit, mobile Teilnehmer zu unterstützen. Insbesondere ist dieses eine der schwachen Verbindungen bei den vorliegenden, auf Zellen basierenden Netzwerken. Obwohl moderne, auf Zellen basierende Netzwerke „2S G" und „3 G" es Teilnehmern ermöglichen, Daten von mobilen Plattformen zu empfangen und zu senden, sind die Sendegeschwindigkeiten relativ schlecht. Ein wichtiger Grund dafür ist, daß die darunterliegenden Zuführmechanismen (die Zellennetzwerke) ursprünglich für Sprachkommunikation gedacht waren, die relativ geringe Sendegeschwindigkeiten erfordert.

Die MBWA-Architektur, die von der WiMAX-forum Network Working Group (NWG) standardisiert wird, zielt darauf ab, Unterstützung für hohe Sendegeschwindigkeiten für mobile Teilnehmer zur Verfügung zu stellen. Gleichzeitig ist die MBWA-Architektur auch dazu gestaltet worden, die Rich-Service-Möglichkeiten zu unterstützen, so wie Hochgeschwindigkeitsdaten-, Streaming Video- und Voice-over-IP (VoIP)-Dienste, die ursprünglich feste Teilnehmerstationen zum Ziel gehabt hatten, um die Diensteanforderungen der „letzten Meile/ersten Meile" zu erfüllen.

Ein weiterer wichtiger Aspekt von WiMAX-Netzwerken ist das Bereitstellen von Diensten. Um dem Endnutzer Zugang zu einem WiMAX-Netzwerk zu ermöglichen, müssen die SS des Benutzers und Diensteströme (d.h. ein unidirektionaler Strom von MAC-Dienstedateneinheiten auf einer Verbindung mit einer besonderen Qualität für den Dienst (QoS – Quality of Service)) zur Verfügung gestellt werden. Anders als die begrenzte QoS-Unterstützung, die von den einfacheren Wi-Fi (d.h. IEEE 802.11)-Netzwerken zur Verfügung gestellt wird, die üblicherweise verwendet werden, um in der heutigen Umgebung Zugang zu einem drahtlosen Netzwerk zur Verfügung zustellen, unterstützt die Architektur nach IEEE 802.16 einen reichen Satz an QoS-Merkmalen. Darüberhinaus benutzt WiMAX eine anspruchsvollere drahtlose Funkschnittstelle als Wi-Fi, was somit komplexere Betrachtungen über das Bereitstellen von Diensten erfordert.

Genauer basiert WiMAX auf einer zentralisierten Steuerarchitektur, bei der der Scheduler in der BS die vollständige Steuerung über den Zugang zum drahtlosen Medium bei allen SSn innerhalb seiner Zelle hat. WiMAX kann gleichzeitig mehrere drahtlose Verbindungen unterstützen, die durch einen vollständigen Satz von QoS-Parametern gekennzeichnet sind. Darüberhinaus sorgt WiMAX dafür, daß der Paketklassifizierer diese Verbindungen mit verschiedenen Nutzeranwendungen und Schnittstellen abbildet, die von Ethernet, TDM (Zeitmultiplexieren – Time Division Multiplexing), ATM (Asynchroner Übertragungsmodus – Asynchronous Transfer Mode), IP (Internet-Protokoll), VLAN (Virtuelles Nahbereichsnetzwerk – Virtual Local Area Network) usw. reichen. Jedoch steigert der reiche Satz an Merkmalen und die Flexibilität in WiMAX auch die Komplexität des Diensteeinsatzes und des Versorgens von festen und mobilen Breitbandnetzwerken mit drahtlosem Zugang.

2 zeigt ein Verwaltungs-Referenzmodell 200 von Breitbandnetzwerken mit drahtlosem Zugang (BWA – Broadband Wireless Access) gemäß einer Ausführungsform der Erfindung. Das Modell umfaßt ein Netzwerk-Verwaltungssystem (NMS – Network Management System) 202, verwaltete Basisstationknoten (für die beispielhaften Basisstationen 206 und 208 als verwaltete Knoten 2041 und 2042 veranschaulicht) und eine Dienstestrom-Datenbank 210, die in einem Datenbankserver 212 versorgt wird. Das NMS 202 und die Dienstestrom-Datenbank sind zur Kommunikation mit den BSn (z.B. der Basisstation 206 und 208) des WiMAX-Netzwerks über ein Netzwerk 214 verbunden, das typischerweise ein Fernbereichsnetzwerk (WAN – Wide Area Network) oder ein öffentliches Netzwerk (z.B. das Internet) sein kann. Die verwalteten Knoten der BS sammeln und speichern verwaltete Objekte im Format einer Verwaltungsinformationsbasis (MIB – Management Information Base) nach 802.16, wie durch die MIB-Elemente 208 und 220 veranschaulicht. Bei einer Ausführungsform werden die verwalteten Objekte den NMSn (z.B. NMS202) verfügbar gemacht, indem das einfache Netzwerk-Verwaltungsprotokoll (SNMP – Simple Network Management Protocol) verwendet wird, wie es durch IETF RFC (Request for Comments) 1157 (d.h. http://www.faqs.org/rfcs/rfc1157.html) festgelegt ist.

Jede der Basisstationen 206 und 208 versorgt ein jeweiliges Abdeckungsgebiet. Der „Fußabdruck" (d.h. die Form) jedes Abdeckungsgebietes wird im allgemeinen von dem Typ der Antenne (z.B. Einzelsektor, Mehrfachsektor oder omnidirektional) abhängen, der von der Basisstation bereitgehalten wird, in Kombinationen mit geographischen Betrachtungen und/oder solchen über die Infrastruktur und der Leistung des Funksignals. Zum Beispiel, obwohl es als außerhalb der Sichtlinie (NLOS) bezeichnet wird, können ein geographisches Gebiet, so wie Berge und Bäume, und öffentliche Infrastruktur, so wie große Gebäude, die Fortpflanzung des drahtlosen Signals beeinflussen, was zu einem verkleinerten Abdeckungsgebiet führt. Die Stärke des Funksignals für WiMAX-Sendungen ist auch durch das verfügbare HF-Spektrum für lizensierte und/oder lizenzbefreite Operationen beschränkt. Aus Gründen der Einfachheit sind die jeweiligen Abdeckungsgebiete 222 und 224 für die Basisstationen 206 und 208 als Ovale veranschaulicht.

Eine gegebene Basisstation ist in der Lage, die Kommunikation sowohl mit MSSn und festen SSn innerhalb ihres Abdeckungsgebietes zu unterstützen. Um vollständige Mobilität zu unterstützen, muß das Abdeckungsgebiet nächster „Nachbar"-Basisstationen einen bestimmten Grad an Überlagerung haben, wie es durch ein Überlagerungs-Abdeckungsgebiet 226 in 2 veranschaulicht ist. Wenn sich eine MSS durch das Abdeckungsgebiet bewegt (so wie es durch eine MSS 228 veranschaulicht ist, die sich zwischen den Abdeckungsgebieten 222 und 224 bewegt), werden periodisch Daten über ihre Signalstärke gesammelt, um zu bewerten, welche BS benutzt werden sollte, um die gegenwärtige Ebene der Dienste am besten beizubehalten. Angesichts dieser Daten über die Signalstärke, ebenso wie anderer Betrachtungen, die in Einzelheiten hiernach aufgeführt sind, wird die BS, die verwendet wird, um einer gegebenen MS Dienste zur Verfügung zu stellen, über einen Übergabe (HO – Hand Over)-Prozeß umgeschaltet werden, wenn sich das MSS innerhalb verschiedener Abdeckungsgebiete von BSn bewegt. Einzelheiten der Arbeitsgänge beim Übergabeprozeß werden hiernach beschrieben.

Wie hierin verwendet, bezieht sich eine Mobile Teilnehmerstation im allgemeinen auf ein elektronisches Gerät, das Kommunikation mit Basisstationen in einem drahtlosen Breitbandnetzwerk ermöglicht. Eine MSS kann zum Beispiel ein Chipsatz nach IEEE 802.16e innerhalb einer Express Karte oder einer Netzwerkschnittstellenkarte sein, die eine einsteckbare Komponente für eine mobile Kundenplattform, so wie einen Notebook-Computer (z.B. den Notebook-Computer 230, der in 2 veranschaulicht ist), ein tragbares Gerät (PDA, Taschen-PC, mobiles Telefon usw.) aufweist.

Die Dienstestrom-Datenbank 210 enthält den Dienstestrom und die damit verknüpfte Information über QoS, die die BS und die SS/MSS bei der Erzeugung von Transportverbindungen leitet, wenn ein Dienst bereitgestellt wird, wenn eine SS in das WiMAX-Netzwerk eintritt oder eine mobile SS in ein Abdeckungsgebiet einer BS eintritt. Im allgemeinen können SSn/MSSn direkt von einem NMS oder indirekt durch eine BS, die als ein SNMP-Proxy arbeitet, verwaltet werden. Bei einer Ausführungsform wird die Verwaltungsinformation zwischen einer SS/MSS und einer BS über einen primären oder sekundären Verwaltungs-CID (Verbindungsidentifizierer – Connection Identifier) für eine verwaltete SS/MSS transportiert.

Es gibt drei Arten von Diensteströmen, die durch den Standard IEEE 802.16-2004 definiert sind, welche bereitgestellte Diensteströme, bewilligte Diensteströme und aktive Diensteströme umfassen. Ein bereitgestellter Dienstestrom ist ein Dienstestrom, der bereitgestellt ist, jedoch nicht unmittelbar aktiviert wird. Externe Auslöser werden verwendet, um einen bereitgestellten Dienstestrom in einen bewilligten Dienstestrom zu überführen. Dieser Dienstestrom wird angestoßen, wenn eine SS über eine Netzwerkeintrittsprozedur in das Netzwerk eintritt, mit Bereitstellungsbefehlen, die von dem NMS verwaltet werden.

Bei einem bewilligten Dienstestrom wird eine Netzwerkressource durch eine Zulassungssteuerung reserviert. Bei einer Technik werden externe Auslöser verwendet, um einen bewilligten Dienstestrom in einen aktiven Dienstestrom zu überführen. Bei einer weiteren Technik können dynamische Dienstezusatz (DAS – Dynamic Service Addition)-Nachrichten verwendet werden, um ein ähnliches Ergebnis zu erzeugen. Ereignisse ähnlich dem „Abheben" bei einem Telefoniemodell werden verwendet, um einen Dienstestrom für einen unverlangtt erteilten Dienst (UGS – Unsolicited Grant Service) zu aktivieren. Anwendungsbezogene Auslöser können ebenfalls benutzt werden, um den Übergang zu einem aktiven Dienstestrom zu bewirken.

Ein aktiver Dienstestrom ist ein Dienstestrom, der aktiv ist. Das heißt, es ist ein Dienstestrom, dem Netzwerk-Ressource, so wie Uplink- und Downlink-Bandbreite, für die Nutzung durch Datentransport zugeteilt sind. Er benutzt einen aktiven Satz von QoS-Parametern, der eine Untermenge der bewilligten Menge der QoS-Parameter ist.

Einzelheiten einer Ausführungsform eines Protokollschicht-Referenzmodells mit Netzwerkverwaltung 300 für mobile BWA-Netzwerke sind in den 3a, 3b und 3c gezeigt. Das Netzwerkverwaltungs-Referenzmodell umfaßt ein Netzwerkverwaltungssystem 302, welches verwendet wird, um verschiedene Netzwerkelemente zu verwalten, wie es durch Basisstationen 304 und 306 und MSSn 308 und 310 veranschaulicht ist. Das Netzwerkverwaltungssystem 302 umfaßt ein Elementverwaltersystem (EMS – Element Manager System) 312, das zur Kommunikation mit einer Dienste-Datenbank 314 verbunden ist, in der verschiedene Diensteproviderdaten gespeichert sind, einschließlich Daten, die sich auf Diensteströme von MSS und SS beziehen (ähnlich denen, die in der Dienstestrom-Datenbank 210 gespeichert sind, Fallen (traps) und Ereignisse). Ein Dienstezugangspunkt (SAP – Service Access Point) 316 für Netzwerkebenen wird verwendet, um eine Schnittstelle zwischen dem EMS 312 und den Basisstationen 304 und 306 zur Verfügung zu stellen, die es dem EMS ermöglicht, mit den Basisstationen über IP-Sendungen zu kommunizieren, die als IP-Transportwolke 318 veranschaulicht sind.

Bei einem herkömmlichen EMS-Modell wird ein EMS verwendet, um eine oder mehrere Arten von Netzwerkelementen in dem System zu verwalten. Zum Beispiel kann in einem Telekommunikationssystem ein EMS verwendet werden, um die Arbeitsgänge verschiedener Telekommunikationsschaltsysteme und ähnlicher Netzwerkelemente zu verwalten. Ähnlich wird das EMS 312 verwendet, um Netzwerkelemente in dem BWA-System zu verwalten, so wie die Basisstationen 304 und 306. Anders als bei einem herkömmlichen Ansatz eines EMS-Modells jedoch ermöglicht es die Architektur des Verwaltungs-Referenzmodells 300 dem EMS 312 auch, mobile Teilnehmerstationen über Proxi-Verwaltungsdienste zu verwalten, die an den Basisstationen zur Verfügung gestellt werden.

In weiteren Einzelheiten ist ein SNMP-Proxiagent an jeder Basisstation vorgesehen, wie es durch die Proxi-SNMP-Agenten 320 und 322 veranschaulicht ist. Dem Proxi-SNMP-Agenten ist es möglich, mit dem EMS 312 über einen SNMP-Manager 324 zu kommunizieren, wobei herkömmliche SNMP-Nachrichten verwendet werden. SNMP basiert auf dem Verwalter/Agenten-Modell, das aus einem Verwalter, einem Agenten, einer Datenbank für Verwaltungsinformation, verwalteten Objekten und dem Netzwerkprotokoll besteht. Der Verwalter führt Verwaltungsanwendungen aus, die das verwaltete Netzwerk überwachen und steuern. Der Agent ist ein Verwaltungssoftwaremodul, das sich in einem verwalteten Objekt befindet, um die Befehle von dem Verwalter auszuführen.

Der Verwalter und der Agent nutzen eine Verwaltungsinformationsbasis (MIB) und einen relativ geringen Satz an Befehlen, um Information über entsprechende SNMP-Nachrichten auszutauschen. Die MIB ist in einer Baumstruktur mit individuellen Variablen organisiert, so wie dem Punktstatus oder einer Beschreibung, die als Blätter auf den Zweigen dargestellt werden. Die Information, die zwischen dem SNMP-Verwalter und den Agenden übergeben wird, weist ein oder mehrere MIB-Objekte auf, die in SNMP-Nachrichten verkapselt sind, auch allgemein als Protokolldateneinheiten (Protocol Data Units) oder PDUs bezeichnet. Das SNMP-Nachrichtenformat weist einen Umschlag auf, der eine PDU zusammen mit Nachrichtenkopffeldern einkapselt.

SNMP PDUs sind in Klassen basierend auf ihrer Funktion angeordnet. Tabelle 1 unten zeigt die SNMP PDU (Nachrichten)-Klassen unter der gegenwärtigen Version (SNMPv3) zusammen mit den PDU-Klassen der früheren Version SNMPv1. Es gibt auch drei zusätzliche Klassen (intern, bestätigt und nicht bestätigt), die aus Gründen der Einfachheit in Tabelle 1 nicht gezeigt sind.

Tabelle 1

Wie oben diskutiert, benutzt SNMP an den verwalteten Vorrichtungen MIBs. Dies erfordert es, daß ein SNMP-Agent die Objekte in dem MIB-Element für eine gegebene Vorrichtung verwaltet. Demgemäß ist jeder der proxy-SNMP-Agenten 320 und 322 so gestaltet, daß er als ein SNMP-Agent arbeitet, zusätzlich dazu, daß er SNMP-proxy-Operationen durchführt, die hiernach beschrieben sind.

Unter dem Netzwerkverwaltungs-Referenzmodell 300 wird SNMP-Nachrichtenverkehr nicht zum Senden von Verwaltungsinformation zwischen einer Basisstation und den Teilnehmer, die sie bedient, z.B. MSSn 308 und 310, verwendet. Statt dessen wird ein vereinfachtes Protokoll, das MAC-Verwaltungsnachrichten verwendet, eingesetzt, um diese Information zu überführen.

Jede der mobilen Teilnehmerstationen 308 und 310 implementiert Steuer- und Datenebenenkomponenten, die durch das Protokollschicht-Referenzmodell nach IEEE Std.812.16-2001 definiert sind. Bei diesem Protokollschicht-Referenzmodell weist die MAC-Schicht drei Unterschichten auf. Die für MAC dienstespezifische Konvergenz-Unterschicht (CS – Convergence Sublayer) 330 liefert jegliche Transformation oder Abbildung von externen Netzwerkdaten, die durch den Dienstezugangspunkt (SAP) 322 der CS empfangen worden sind, in MAC-Dienstedateneinheiten (SDUs – Service Data Units), die von der MAC Common Part Unterschicht (MAC CPS – Common Part Sublayer) 334 durch den MAC SAP 336 empfangen worden sind. Dies umfaßt das Klassifizieren von SDUs eines externen Netzwerkes und das Zuweisen derselben an den richtigen MAC-Dienstestrom und Verbindungsidentifizierer. Es kann auch solche Funktionen umfassen, wie das Unterdrücken des Nachrichtenkopfes des Nutzdatenteils. Mehrere Spezifikationen für die CS stehen zur Schnittstellenbildung mit verschiedenen Protokollen zur Verfügung. Das interne Format des Nutzdatenteils der CS ist für die CS eindeutig, und für die MAC CPS ist es nicht erforderlich, das Format zu verstehen oder jegliche Information aus dem Nutzdatenteil der CS syntaktisch zu analysieren.

Die MAC CPS 334 sorgt für die MAC-Kernfunktionalität des Systemzugangs, Bandbreitenzuweisung, Einrichten von Verbindungen und Halten von Verbindungen. Sie empfängt Daten von den verschiedenen CSn durch den MAC SAP 336, klassifiziert auf bestimmte MAC-Verbindungen. Dienstequalität (Quality of Service) wird bei der Sendung und dem Planen von Daten über die PHY angewendet.

Die MAC umfaßt auch eine gesonderte Datenschutz-Unterschicht 338, die für Authentifizierung, sicheren Schlüsselaustausch und Verschlüsselung sorgt. Daten, PHY-Steuerung und Statistiken werden zwischen der MAC CPS und der PHY-Unterschicht 340 über den PHY SAP 372 übertragen.

Jede der mobilen Teilnehmerstationen 308 und 310 implementiert auch Verwaltungsebenenkomponenten, die in dem Protokollschicht-Referenzmodell nach IEEE Std. 802.16-2001 dargestellt sind. Die Verwaltungsebenenelemente umfassen eine MAC CS Verwaltungseinheit 344, eine MAC CPS Verwaltungseinheit 346, eine Verwaltungseinheit 348 für die Datenschutz-Unterschicht und eine Verwaltungseinheit 350 für die PHY-Unterschicht.

Obwohl die voranstehenden Verwaltungsebenenkomponenten als Teil des Protokollschichtreferenzmodells nach IEEE Std. 802.16-2001 enthalten sind (man bemerke, daß in dem Protokollschicht-Referenzmodell die Datenschutz-Unterschicht tatsächlich als Teil der MAC CPS Verwaltungseinheit enthalten ist und nicht getrennt gezeigt ist, wie es hierin veranschaulicht ist), sind die Spezifikationen zum Implementieren der Verwaltungsebene nicht unter den Umfang des IEEE Std. 802.16-2001 oder die gegenwärtige Spezifikation IEEE Std. 802.16-2004 eingeschlossen. Dieses umfaßt weiter Kommunikationseinrichtungen zwischen der Steuer/Datenebene und dem Netzwerkverwaltungssystem (das unter dem Protokollschicht-Referenzmodell nach dem IEEE Std. 802.16-2004 einfach als externes Element veranschaulicht ist) und zwischen der Verwaltungsebene und dem Netzwerkverwaltungssystem. Bei dem Protokollschicht-Referenzmodell mit Netzwerkverwaltung 300 werden diese jeweiligen Kommunikationseinrichtungen durch einen SAP 352 für die Steuerebene und einen SAP 354 für die Verwaltungsebenen zur Verfügung gestellt.

Verwaltungsdaten, in der Form von MIB-Objekten, werden zwischen den Basisstationen und dem Netzwerkverwaltungssystem übertragen, indem SNMP-Nachrichten verwendet werden, welche solche Daten einkapseln. Die MIB-Objekte selbst werden als PDU-variable Bindungen verkörpert, welche eine Bindung zwischen einem Objektnamen und seinem entsprechenden Wert aufweisen. Die Verwaltungsobjekte für eine gegebene Basisstation werden in dem MIB-Element der Basisstation gespeichert, wie es mit den MIB-Elementen 356 und 358 in 3a veranschaulicht ist.

Die 4a–e zeigen verschiedene Ebenen mit Einzelheiten für eine wmanIfMib (Drahtlose MAN-Schnittstelle) MIB-Datenstruktur 400 gemäß einer Ausführungsform. Die MIB-Datenstruktur umfaßt mehrere MIB-Objekte, die in verschiedenen Ebenen (Gruppen) in einer Objekthierarchie eingebettet sind. Am oberen Ende der Hierarchie befindet sich das Objekt wmanifMib, in 4a gezeigt. Die nächste Ebene der Hierarchie umfaßt die Objekte wmanifBs, die Objekte wmanIfSs und die Objekte wmanIfCommon. Die Objekte wmanifBs umfassen eine Gruppe verwalteter Objekte, die von einer Basisstation implementiert werden sollen, Einzelheiten einer Ausführungsform der Objekte wmanifBs sind in den 4b und 4c gezeigt. In ähnlicher Weise umfassen die Objekte wamnIfSs eine Gruppe verwalteter Objekte, die von einer Teilnehmerstation implementiert werden sollen; Einzelheiten einer Ausführungsform der Objekte wmanIfSs sind in der 4e gezeigt. Die Objekte wmanIfCommon umfassen eine Gruppe gemeinsam verwalteter Objekte, die in den Basisstationen und den Teilnehmerstationen implementiert werden sollen; Einzelheiten einer Ausführungsform von Objekten wmanIfCommon sind in 4d gezeigt. In Verbindung mit weiteren SNMP-Verwaltungsarbeitsgängen kann die wmanIfMib-MIB-Datenstruktur 300 als ein Unterbaum unter der Schnittstellengruppe MIB implementiert werden, die im RFC (Request for Comment) 2863 (d.h., http://www.faqs.org/rfcs/rfc2863.html) definiert ist, implementiert werden.

Bei dem herkömmlichen Einsatz, wie er durch die MIB-Entwurfsspezifikation IEEE P802.16f/D2, Dezember 2004, definiert ist, sollen die Objekte wmanIfS von einer Teilnehmerstation implementiert werden. Ähnlich sollen bei dieser MIB-Spezifikation die Objekte wmanIfCommon in Basisstationen und in den Teilnehmerstationen implementiert werden. Unter dem Netzwerkverwaltungs-Referenzmodell 300 jedoch gibt es keine MIB-Elemente, die von den MSSs gehalten werden. Statt dessen werden die Objekte wmanIfSs und der SS-Teil der Objekte wmanIfCommon, die eine gegebene MSS betreffen, in dem MIB-Element für die Basisstation gespeichert, die der MSS Dienste leistet.

Einzelheiten von Arbeitsgängen, die im Zusammenhang mit dem Wiedergewinnen von Betriebsparametern und/oder Parametern für den dynamischen Dienstestrom von einer MSS bei einer Ausführungsform durchgeführt werden, sind in 5 gezeigt, wobei die entsprechende Nachrichtenstromsequenz in 3b veranschaulicht ist. Der Prozeß beginnt bei einem Block 500, wobei ein EMS 312 eine SNMP-Nachricht GetRequest erzeugt, die die MIB-Objekt(e) enthält, welche den MSS-Parametern entsprechen, die das EMS von einer ausgewählten MSS empfangen möchte. Im allgemeinen wird die MSS gegenwärtig von einer der Basisstationen bedient, die von dem Netzwerkverwaltungssystem 302 verwaltet werden, und wird durch einen eindeutigen Identifizierer, so wie ihrer MAC-Adresse, identifiziert werden. Basierend auf aktiver Dienstestrominformation, die in der Dienste-Datenbank 314 und/oder dem MIB 356 gehalten wird, kann die Basisstation, die die MSS bedient, einfach identifiziert werden. Zu Zwecken der Veranschaulichung wird angenommen, daß die MSS die MSS 308 ist und die Dienste leistende Basisstation die Basisstation 304 ist.

Nachdem die SNMP-Nachricht GetRequest erzeugt worden ist, wird sie von dem SNMP-Verwalter 324 über einen SAP der Netzwerkebene und einen IP-Transport 318 zu einem Proxy-SNMP-Agenten 320 an der Basisstation 304 geschickt, wie in einem Block 504 veranschaulicht. Dies ist schematisch in 3b als eine Nachricht 360 GetRequest veranschaulicht. Als Antwort auf den Empfang der Nachricht 360 GetRequest zieht der Proxy-SNMP-Agent 320 die MIB-Objekte (z. B. Namen-Werte-Bindungen) aus der Nachricht heraus und erzeugt geeignete Verwaltungs- und/oder Steuer-MAC-Nachrichten, um die entsprechenden MSS-Parameter in einem Block 504 wiederzugewinnen. Die Art und Anzahl der Nachrichten wird davon abhängen, ob die Parameter von der Verwaltungsebene der MSS oder einer Steuer- und Datenebene benutzt werden und wie viele Parameter angefragt werden.

Wie es durch einen Entscheidungsblock 506 veranschaulicht ist, geht für jede Verwaltung-MAC-Nachricht, die erzeugt wird, die Logik zu einem Block 508 weiter, bei dem der Proxy-SNMP-Agent 320 die Verwaltungs-MAC-Nachricht 362 über den primären Verwaltungs-CID zu einer Verwaltungsebene SAP 354 schickt. Beim Empfang einer Verwaltungs-MAC-Nachricht 362 gewinnt der SAP 354 der Verwaltungsebene die angefragten Parameter von einer oder mehreren geeigneten Verwaltungseinheiten wieder und gibt die wiedergewonnenen Parameter in einer Verwaltungs-MAC-Nachricht 364 über den primären Verwaltungs-CID an den Proxy-SNMP-Agenten 320 zurück.

Der Nachrichtenaustausch für Steuer-MAC-Nachrichten ist ähnlich, mit der Ausnahme, daß die MAC-Nachrichten nun zu dem SAP 352 der Steuerebene geschickt werden und von ihr zurückkehren. In weiteren Einzelheiten richtet für jede Steuer-MAC-Nachricht, die im Block 504 erzeugt worden ist, der Entscheidungsblock 506 den Prozeß zu einem Block 512, bei dem der Proxy-SNMP-Agent 320 eine Steuer-MAC-Nachricht 366 über den primären Verwaltungs-CID an einen SAP 352 der Steuerebene sendet. Beim Empfangen einer Steuer-MAC-Nachricht 366 gewinnt der SAP 352 der Steuerebene die angefragten Parameter von einer oder mehreren geeigneten Steuer- und Datenebenenkomponenten wieder und gibt die wiedergewonnenen Parameter in einer Steuer-MAC-Nachricht 368 über den primären Verwaltungs-CID an den Proxy-SNMP-Agenten 320.

Beim Empfangen der angefragten Parameter für GetRequest 360 über entsprechende Verwaltungs-MAC-Nachrichten 364 und/oder Steuer-MAC-Nachrichten 368 erzeugt der Proxy-SNMP-Agent 320 in einem Block 516 eine SNMP-Antwortnachricht, die das/die MIB-Objekt(e) enthält, die den Parametern entsprechen, welche von den MAC-Nachrichten in den Blöcken 510 und/oder 514 zurückgegeben worden sind. Die SNMP-Antwortnachricht 370 wird dann von Proxy-SNMP-Agenten in einem Block 518 über den IP-Transport 318 und den SAP 316 der Netzwerkebene zu dem SNMP-Verwalter 324 gesendet, um den Wiedergewinnungsprozeß für Parameter des MSS abzuschließen.

Einzelheiten einer Ausführungsform von Nachrichtenformaten, die für Verwaltungs-MAC-Nachrichten und Steuer-MAC-Nachrichten verwendet werden, sind in den 6a und 6b gezeigt. Genauer veranschaulicht 6a das Format einer TLV (Kennung/Länge/Wert – Tag/Length/Value)-Anfrage-(TLV_REQ)-Nachricht, die verwendet werden kann, um für eine MSS eine Anfrage an die Verwaltungsebene 354 oder die Steuerebene 352 zu richten, während die 6b das Format einer TLV-Antwort (TLV_RSP)-Nachricht veranschaulicht, die verwendet werden kann, um eine Verwaltungs- oder Steuer-MAC-Antwortnachricht von der Verwaltungsebene 354 oder der Steuerebene 352 zu dem Proxy-SNMP-Agenten an der Basisstation zurückzugeben. Bei einer Ausführungsform können die Verwaltungs-MAC-Nachrichten, die von der Verwaltungsebene SAP 354 behandelt werden, benutzt werden, um die folgenden, jedoch nicht darauf beschränkten Parameter zu transportieren: Konfigurationsdateicodierungen (Abschnitt 11.2 im IEEE 802.16-2004); globale Parameter (Abschnitt 10.1 im IEEE 802.16-2004); PKM-Parameter (Abschnitt 10.2) im IEEE 802.16-2004); MSS-Trap-Steuerung; MSS-Schwellenwert-Konfiguration; MSS-Leistungsdaten (z. B. FEC-Zähler) und MSS-Ereignisse.

Einzelheiten von Arbeitsgängen, die in Verbindung mit dem Senden von MIB-Objekten durchgeführt werden, um dynamische Diensteströme für BSs zur Verfügung zu stellen und anschließend die Parameter der dynamischen Diensteströme eine MSS zu geben, sind für eine Ausführungsform in 7 gezeigt, während die entsprechende Nachrichtenstromsequenz in 3c veranschaulicht ist. Der Prozeß beginnt mit einem Block 700, wobei das EMS 312 Daten von der Dienste-Datenbank 314 entsprechend dem/den MIB-Objekt(en), das/die geschickt werden soll, wiedergewinnt. Das EMS 312 erzeugt dann eine SNMP-Nachricht 372 SetRequest, welche die MIB-Objekte enthält, in einem Block 702. In einem Block 704 wird die Nachricht 372 SetRequest von dem SNMP-Verwalter 324 über den SAP 316 der Netzwerkebene und den IP-Transport 318 zum Proxy-SNMP-Agenten 320 geschickt, wie in 3c veranschaulicht. Nach dem Empfang der Nachricht 372 SetRequest zieht der SNMP-Agent 320 die MIB-Objekte) heraus und bevölkert geeignete MIB-Unterbäume im MIB-Element 356 entsprechend anwendbaren MB- und (M)SS-MIB-Objekten, wie in einem Block 706 veranschaulicht.

In einem Entscheidungsblock 708 wird eine Feststellung getroffen, ob irgendwelche Parameter an die MSS 308 geschickt werden müssen. Wenn die Antwort NEIN ist, ist der Prozeß beendet. Wenn die Antwort JA ist, geht der Prozeß zu einem Entscheidungsblock 710, in dem eine Entscheidung getroffen wird, ob die Parameter über eine Verwaltungs-MAC-Nachricht oder eine Steuer-MAC-Nachricht verschickt werden sollen. Für jede anwendbare Verwaltungs-MAC-Nachricht erzeugt und sendet der Proxy-SNMP-Agent 320 eine Verwaltungs-MAC-Nachricht 374, die wenigstens Verwaltungsebenenparameter enthalten, über den primären Verwaltungs-CID in einem Block 712 an den SAP 354 der Verwaltungsebene. Der SAP der Verwaltungsebene stellt die geschickten Parameter dann einem oder mehreren ins Ziel gefaßten Verwaltungseinheiten (wie nötig) in der Verwaltungsebene zur Verfügung, wie es in einem Block 714 veranschaulicht ist, was den Prozeß abschließt. Für jede anwendbare Steuer-MAC-Nachricht erzeugt und sendet der Proxy-SNMP-Agent 320 eine Steuer-MAC-Nachricht 376, die Daten/Steuerebenenparameter enthält, über den primären Verwaltungs-CID in einem Block 716 an den SAP 352 der Steuerebene. Die Steuerebene stellt dann die geschickten Parameter einer ins Ziel gefaßten MAC-Komponente in der Steuer-Datenebene zur Verfügung, wie es in einem Block 718 veranschaulicht ist, was den Prozeß abschließt.

8 zeigt ein Ablaufdiagramm, welches Arbeitsgänge veranschaulicht, die durchgeführt werden, um für einen mobilen Teilnehmer gemäß einer Ausführungsform der Erfindung dynamische Diensteströme zur Verfügung zu stellen. Der Prozeß beginnt mit einem Block 800, wobei der Teilnehmer einen drahtlosen Breitbanddienst von einem Diensteprovider kauft, indem Attribute für den dynamischen Dienstestrom in einer Diensteebenenvereinbarung festgelegt werden. Wenn ein Kunde sich bei dem Dienst einschreibt, wird er oder sie dem Dienstesprovider die Information über den dynamischen Dienstestrom kommunizieren, die der gewünschten Diensteebene entspricht, einschließlich der Anzahl der UL/DL-Verbindungen, die angefragt werden, zusammen mit den Datenraten und QoS-Parametern für diese Verbindungen und zusammen damit, welche Art von Anwendung (z.B. Internet, Sprache, Video usw.) er oder sie beabsichtigt zu nutzen. Als Antwort auf die Einträge des Teilnehmers wird der Diensteprovider die Dienste vorab bereitstellen, indem die entsprechenden Attribute des dynamischen Dienstestroms in die Dienstestrom-Datenbank 314 eingegeben werden, wie in einem Block 802 gezeigt ist.

Als Antwort darauf, daß eine MSS in das Abdeckungsgebiet einer BS eintritt, lädt die BS die Parameter für den dynamischen Dienstestrom, die für die MSS bereitgestellt worden sind, in einem Block 804 von der Dienstestrom-Datenbank 314 herunter. Einzelheiten einer Ausführungsform dieser Arbeitsgänge sind in 9 gezeigt.

Der Prozeß beginnt mit einem Block 900, wobei eine MSS eine Abtastoperation durchführt und sich mit der BS synchronisiert. Im allgemeinen wird das Abtasten durchgeführt, um Basisstationen innerhalb des Bereichs der MSS zu identifizieren und die beste BS auszuwählen, die den Dienst für die MSS zur Verfügung stellt. Während des Abtastens tastet eine MSS benachbarte BS ab, um die Stärke des Funksignalempfangs zu messen. In weiteren Einzelheiten wird ein Träger-Interferenz plus Rauschen-Verhältnis (CINR – Carrier to Interference plus Noise Ratio) und/oder ein Indikator für die relative Signalstärke (RSSI – Relative Signal Strength Indicator) mit einer Auflösung von 0.5 Dezibel (dB) gemessen, wobei eine vordefinierte Prozeß- und Nachrichtenaustauschsequenz verwendet wird. Vor dem Durchführen eines Abtastens tauschen eine MSS und ihre Dienste erbringende BS eine MOB_SCN_REQ (Anfrage zum Abtasten durch die mobile Station – Mobile Scan Request)- und MOB_SCN_RSP (Antwort an die mobile Station wegen des Abtastens – Mobile Scan Response)-Nachricht aus, um einen Zeitrahmen für das Durchführen des Abtastens einzurichten. Wenn einmal eine BS ausgewählt ist, um der MSS zu dienen, führen die MSS und die BS eine Synchronisationsoperation durch, um Uplink- und Downlink-Kommunikationskanäle einzurichten.

In einem Block 902 erhält die MSS Uplink- und Downlink-Parameter aus entsprechenden Uplink-Kanaldeskriptor (UDC – Uplink Channel Descriptor) und Downlink-Kanaldeskriptor (DCD – Downlink Channel Descriptor)-Nahrichten. Die MSS führt dann das einleitende Ranging durch, wobei RNG-Nachrichten verwendet werden. Bei diesem Arbeitsgang schickt die MSS eine RNG_REQ-Ranging-Anfragenachricht an eine BS, welche eine RNG_RSP Ranging-Antwortnachricht zurückggibt, welche gegenwärtige Ranging-Information enthält. Nach erfolgreichem Ranging erhält die BSS die MAC (Medienzugangskanal – Media Access Channel)-Adresse der MSS.

In einem Block 905 erzeugt der Proxy-SNMP-Agent der BS ein SNMP-Trap an das EMS 312 über den SNMP-Verwalter 324. Bei dem SNMP-Modell werden SNMP-Traps verwendet, um Information von einem SNMP-Agenten an einen SNMP-Verwalter zu senden (ohne daß der Verwalter um die Information bittet). Der SNMP-Trap identifiziert die Art des Traps und führt eine variable Bindung ein, die die MAC-Adresse der MSS idetifiziert.

In einem Block 906 benutzt das EMS 312 die MAC-Adresse der MSS als einen Nachschlageparameter, um die Dienstestrominformation, die der MSS entspricht (oben im Block 802 eingegeben) von der Dienstestrom-Datenbank 314 unter Verwendung von Nachrichten SetRequest herunterzuladen, um für die MSS an der BS Dienste vorab bereitzustellen. Im Zusammenhang mit den Arbeitsgängen des Blocks 906 wird die wmanIfBsProvisionedSfTable mit der entsprechenden Dienstestrominformation belegt, während entsprechende QoS-Parameter in die wmanIfBsServiceClassTable eingegeben werden und entsprechende Klassifizierregeln in die wmanBsClassifierRuleTable eingegeben werden.

Nachdem die geeigneten MIB-Objekte (z. B. Tabellen) der BS mit den vorab bereitgestellten Dienstestromdaten belegt sind, tauschen die MSS und die BS Nachrichten über die grundlegenden Möglichkeiten des Teilnehmers (SBC – Subscriber Basic Capability) aus, um grundsätzliche Möglichkeiten zu verhandeln, mit denen sowohl die BS als auch die MSS sich einig sind zu arbeiten, wie in einem Block 908 veranschaulicht. Als nächstes, in einem Block 910, benutzen die MSS und die BS Public Key-Verwaltungs (PKM – Public Key Management)-Nachrichten für die Authentifizierung und die Autorisierung der MMS entsprechend der vorläufigen Spezifikation IEEE 802.16e/D5a (Dezember 2004). Wie in einem Block 912 veranschaulicht, schickt dann die MSS eine REG-REQ-Nachricht, um die MSS in der BS zu registrieren, und erhält als Antwort eine REG-RSP-Nachricht von der BS. Die BS gibt dann die MSS in ihre wmanifBsRegisteredSsTable ein, wobei ihre MAC-Adresse verwendet wird, um die MSS zu identifzieren. Basierend auf der MAC-Adresse wird die BS in der Lage sein, die Dienstestrom-Information zu finden, die für die MSS in der wmanIfBsProvisionedSfTable, der wmanIfBsServiceClassTable und der wmanBsClassifierRuleTable vorab bereitgestellt worden ist. Dies schließt die Arbeitsgänge des Ablaufdiagramms der 9 ab, wobei der Prozeß zum Block 804 der 8 zurückgeführt wird, wie es durch einen Rückführblock 914 veranschaulicht ist.

Weiter mit einem Block 806 in 8, nachdem die Arbeitsgänge des Ablaufdiagramms der 9 durchgeführt sind, lädt die BS die Betriebsparameter und die Parameter des dynamischen Dienstestroms, wie sie in dem wmanIfMib definiert sind, zu der MSS herunter. Einzelheiten einer Ausführungsform der Arbeitsgänge für den Block 806 sind in 10 gezeigt.

Der Prozeß beginnt mit einem Block 1000, wobei der Proxy-SNMP-Agent die Betriebsparameter und die Parameter des dynamischen Dienstestroms für die MSS aus dem MIB-Element herauszieht. Als Option können diese Parameter aus der/den SNMP-Nachrichten) SetRequest herausgezogen werden, wenn sie empfangen wird/werden. In einem Block 1002 erzeugt der Proxy-SNMP-Agent auf TLV basierende Nachrichten, welche die Betriebsparameter und die Parameter des dynamischen Dienstestroms enthalten, und sendet die Nachrichten an die MSS, wo sie von dem SAP der Managementebene und/oder dem SAP der Steuerebene, wie zweckmäßig, empfangen werden. Der SAP der Managementebene und/oder der SAP der Steuerebene aktualisieren dann die geeigneten Betriebs- und Dienstestromparameter für die MSS in einem Rückführblock 1004, welcher den Block zu dem Block 808 in 8 zurückführt.

Weiter in einem Block 808, nach dem Beenden des Herunterladens der Betriebsparameter und der Parameter des dynamischen Dienstestroms, benutzt die BS dynamischen Dienstezusatz (DS – Dynamic Service Addition)-Nachrichtenbetrieb zu der MSS, um dynamische Diensteströme mit der vorab bereitgestellten Information über den dynamischen Dienstestrom zu erzeugen, die im Block 804 erhalten worden ist, und erzeugt entsprechende Einträge in der wmanIfCmnCpsServiceFlowTable. Einzelheiten der DSA-Nachrichtensyntax können für die DSA-REQ-Nachricht im Abschnitt 6.3.2.3.10, für die DSA-RSP-Nachricht im Abschnitt 6.3.2.3.11 und für die DSA-ACK-Nachricht im Abschnitt 6.3.2.3.12 im Standard IEEE 802.16-2004 gefunden werden.

Die wmanIfCmnCpsServiceFlowTable enthält sowohl Dienstestrominformation als auch QoS-Parameter. Abhängig von dem Zustand des Netzwerks können die QoS-Parameter in der wmanIfCmnCpsServiceFlowTable einer niedrigeren Diensteebene entsprechen, als der, die für eine gegebene MSS in der wmanIfBsProvisionedSsfTable zuvor bereitgestellt worden ist. Bei einer Ausführungsform werden die Klassifizierregeln in der Klassifizierregeltabelle (nicht gezeigt) in der BS erzeugt werden. Die dynamischen Diensteströme werden dann für den Teilnehmer verfügbar, um Datenverkehr zu senden, wie es durch einen Ende-Block 810 veranschaulicht ist. Als Antwort auf geeignete Bedingungen, die entsprechende Auslöser einbeziehen, werden die zuvor bereitgestellten Diensteströme zu bewilligten und dann zu aktiven Diensteströmen vorbewegt.

Wenn sich eine MSS durch das Abdeckungsgebiet eines Netzwerkes bewegt, wird ihre Signalstärke variieren, so daß ein Übergabeprozeß (HO – Hand Over) berechtigt ist. Genauer ist der HO-Prozeß der Prozeß, unter dem eine MSS von der Funkgrenze, die von einer (gegenwärtig) Dienste leistenden BS zur Verfügung gestellt wird, zu einer Funkgrenze wandert, die von einer Ziel- (für zukünftige Dienste) BS zur Verfügung gestellt wird. Nach dem Abschluß des HO wird die Ziel-BS die neue Dienste leistende BS. Bei einem herkömmlichen HO-Prozeß muß sich die MSS mit dem Downlink-Kanal der Ziel-BS synchronisieren, die Uplink-Parameter erhalten und ihren Prozeß zum Wiedereintritt in das Netzwerk durchführen, einschließlich erneuter Autorisierung, erneuter Registrierung und erneutem Einrichten ihrer IP-Verbindungsfähigkeit in einer Weise, die ähnlich der ist, die für eine neue MSS benutzt wird, welche in das Netzwerk eintritt, entsprechend der vorläufigen Spezifikation IEEE 802.16e/D5a (Dezember 2004). Dieser herkömmliche HO-Prozeß erfordert eine große Menge an Nachrichtenverkehr, was zu einer wesentlichen Zeitverzögerung führt, ebenso wie zu wesentlichen Arbeitsbelastungswerten an den BSs.

Arbeitsgänge und Logik entsprechend einer Ausführungsform eines Übergabeprozesses sind in 11 gezeigt. Eine Übergabe beginnt mit einer Entscheidung einer MSS, ihre Funkgrenze, den Dienstestrom und die Netzanbindung von einer Dienste liefernden BS an eine Ziel-BS zu übergeben. Demgemäß beginnt der HO-Prozeß mit einem Block 1100, wobei eine Feststellung getroffen wird, daß es nötig oder nützlich ist, einen vorliegenden Dienst von einer Dienste leistenden BS an eine neue (Ziel-) BS zu überführen. Die Entscheidung kann entweder von der MSS, der Dienste leistenden BS oder dem Netzwerkverwalter herrühren. Typischerweise wird die HO-Entscheidung basierend auf Dienstekriterien (z.B. welche BS die beste Funkschnittstelle für die MSS zur Verfügung stellen wird) und Betrachtungen über die Verfügbarkeit der Bandbreite der BS getroffen werden. In Verbindung mit dieser Feststellung steht der laufende Prozeß der Zellauswahl.

Zellauswahl bezieht sich auf den Prozeß, daß eine MSS eine oder mehrere BSn abtastet und/oder ranged, um, zusammen mit anderen Leistungsbetrachtungen ihre Geeignetheit für die Netzanbindung oder die Übergabe festzustellen. Die MSS kann Information einbauen, die von einer MOB_NBR-ADV (Nachbarn-Ausschreibung der mobilen Station – Mobile Neighbor Advertisement)-Nachricht erlangt worden ist, um Einsicht in verfügbare benachbarte BSn für die Betrachtung der Zellauswahl zu gewinnen. Wenn sie gegenwärtig mit einer Dienste leistenden BS verbunden ist, wird eine MSS periodische Abtastintervalle oder Schlafintervalle planen, um die Zellauswahl zum Zwecke des Bewertens des Interesses der MSS an der Übergabe an mögliche Ziel-BSn zu führen. Diese Prozedur umfaßt nicht das Beenden existierender Verbindungen zu einer Dienste leistenden BS und ihre Neueröffnung in einer Ziel-BS. Wenn eine Ziel-BS für die Übergabe erfaßt wird, sind jegliche neu zugewiesene grundlegende und primäre CIDs (Verbindungsidentifizierer – Connection Identifiers) für die Ziel-BS spezifisch und ersetzen nicht oder ergänzen nicht die grundlegenden und primären CIDs, die die MSS bei ihrer Kommunikation mit ihrer Dienste leistenden BS benutzt.

Angesichts dieser Arbeitsgänge zur Zellauswahl tastet eine MSS periodisch benachbarte BS ab, um die Stärke des Funksignalempfangs zu messen. Wie oben diskutiert, wird ein CINR und/oder RSSI-Wert gemessen, indem ein vorab definierter Prozeß und eine Nachrichtenaustauschsequenz verwendet werden, in der der zuvor erwähnte MOB_SCN_REQ- und MOB_SCN_RSP-Nachrichtenaustausch abläuft, um einen Zeitrahmen zum Durchführen des Abtastens aufzustellen. Als eine weitere Option kann eine Dienste leistende BS Abtastaktivitäten einleiten, indem an die MSS eine NBR_ADV (Nachbarn-Ausschreibung – Neighbor Advertisement)-Nachricht geschickt wird. Die Nachricht informiert die MSS über eine Anzahl lokaler Nachbarn, von denen sie bessere Dienste erhalten könnte. Als Antwort auf die Nachricht tauschen die MSS und die Dienste leistende BS MOB_SCN_REQ- und MOB_SCN_RSP-Nachrichten aus, und dann tastet die MSS die benachbarten BSn ab, die in der MOB-NBR-ADV-Nachricht identifiziert worden sind. Bei einer Ausführungsform wird die Bestimmung des Blockes 1100 durch eine MSS im Hinblick auf die voranstehenden Abtastoperationen getroffen.

In Verbindung mit der voranstehenden Feststellung einer Übergabe sendet die MSS der Dienste leistenden MBS eine MOB_MSSHO_REQ (Übergabeanfrage der mobilen MSS)-Nachricht, um eine Übergabe anzufragen, oder die Dienste leistende BS leitet in einem Block 1102 eine Übergabe ein. Als Antwort erzeugt der Proxy-SNMP-Agent an der Dienste leistenden BS einen Trap an die EMS 312 (über den SNMP-Verwalter 324), um in einem Block 1104 das Herunterladen von Dienstestrom- und QoS-Parameter and die Ziel-BS auszulösen. Wenn es ausgelöst wird, benutzt das EMS 312 die MAC-Adresse der MSS als einen Nachschlageparameter, um die Dienststrom-Information, die der MSS entspricht (oben im Block 802 eingegeben) von der Dienste-Datenbank unter Verwendung von SetRequest-Nachrichten herunterzuladen, um Dienst für MSS an der Ziel-BS vorab bereitzuhalten. Im Zusammenhang mit den Arbeitsgängen des Blocks 1106 wird die wmanIfBsProvisionedSfTable mit der entsprechenden Dienstestrom-Information belegt, während entsprechende QoS-Parameter in die wmanIfBsServiceClassTable eingegeben werden und entsprechende Klassifizierregeln in die wmanBsClassifierRuleTable eingegeben werden.

An diesem Punkt ist die MSS bereit, die Übergabe ihrer Funkschnittstelle von der Dienste leistenden BS an die Ziel-BS durchzuführen, deren Arbeitsgänge im allgemeinen durch einen Block 1108 veranschaulicht sind, wobei Einzelheiten einer Ausführungsform dieses Prozesses in 12 gezeigt sind. Im allgemeinen sind viele der Arbeitsgänge ähnlich denjenigen, die oben mit Bezug auf die Arbeitsgänge der 9 diskutiert worden sind.

Der Prozeß beginnt mit einem Block 1200, wobei die MSS abtastet und sich mit der Ziel-BS synchronisiert, in einer Weise, die ähnlich der ist, die oben für den Block 900 der 9 beschrieben ist. In einem Block 1202 erhält die MSS dann die Uplink- und Downlink-Parameter über jeweilige OCD- und DCD-Nachrichten in einer Weise ähnlich der, die oben für den Block 902 beschrieben ist. Die MSS führt dann das einleitende Ranging durch, wobei RNG-Nachrichten verwendet werden, und die Ziel-BS erhält die MAC-Adresse der MSS in einem Block 1204 in einer Weise ähnlich dem Arbeitsgang des Blocks 904, wie es oben beschrieben ist. Die MSS und die BS verwenden dann SBC-Nachrichten, um grundlegende Möglichkeiten zu verhandeln und sich über Betriebsparameter zu einigen, in einem Block 1206, und verwenden PKM-Nachrichten für die Authentifizierung und Autorisierung der MSS im Block 1208 in einer Weise ähnlich der, die oben für die jeweiligen Blöcke 906 und 908 beschrieben ist.

In einem Block 1210 ortet die Ziel-BS die vorab bereitgestellte Dienstestrom-Information, die oben im Block 1106 von der Dienste-Datenbank 316 heruntergeladen worden war. Die MSS schickt dann in einem Block 1212 eine REG-Nachricht, um die MSS in der Ziel-BS zu registrieren, und die BS gibt die MSS in ihre wmanIfBsRegisteredSsTable ein. Die Bearbeitung nach 12 wird dann in einem Rückkehrblock 1214 beendet. Nach dem Beenden kehrt die Logik zum Block 1108 zurück.

Nach der Rückkehr geht die Logik zu einem Entscheidungsblock 1110, wo eine Entscheidung getroffen wird, ob die MSS bereits dieselben Parameter des dynamischen Dienstestroms verwendet, wie die, die von der Ziel-BS bereitgehalten werden – mit anderen Worten sind die Parameter für den dynamischen Dienstestrom für die Dienste leistende und die Ziel-BS dieselben. Bei einer Ausführungsform wird dies identifiziert, indem eine Konfigurationskennung verwendet wird. Mit diesem Ansatz hat jede Konfigurationsdatei eine zugewiesene Kennung, welche die Version des Satzes der Betriebsparameter und der Parameter des dynamischen Dienstestroms angibt. Bei einer Ausführungsform wird ein Standardsatz von Konfigurationsdateien definiert, der bei mehreren Basisstationen erneut verwendet werden kann, um die Übergabeprozedur zu vereinfachen. Wenn die Antwort beim Entscheidungsblock 1110 JA ist, geht die Logik direkt zu einem Block 1114, wobei ein Block 1112 übersprungen wird.

Wenn die Antwort am Entscheidungsblock 1110 NEIN ist, besteht das Erfordernis, neue Betriebsparameter und/oder Parameter für den dynamischen Dienstestrom oder die Änderungen gegenüber den gegenwärtig benutzten Parametern zu erhalten. Demgemäß lädt die Ziel-BS derartige Parameter für den dynamischen Dienstestrom in einem Block 1112 herunter. Einzelheiten dieses Prozesses sind in der 13 gezeigt und sind ähnlich denjenigen, die in 10 vorgestellt sind, um Parameter für den dynamischen Dienstestrom an eine MSS zu geben, die in ein drahtloses Breitbandnetzwerk eintritt.

Der Prozeß beginnt mit einem Block 1300, wobei der Proxy-SNMP-Agent die Betriebsparameter und die Parameter des dynamischen Dienstestroms für die MSS aus dem MIB-Element an der Ziel-BS herauszieht. Als Option können diese Parameter aus den SNMP-Nachrichten SetRequest herausgezogen werden, wenn sie empfangen werden. In einem Block 1302 erzeugt der Proxy-SNMP-Agent auf TLV basierende Nachrichten, die die Betriebsparameter und die Parameter des dynamischen Dienstestrom enthalten, und schickt die Nachrichten an die MSS, wo sie von dem SAP der Verwaltungsebene und/oder dem SAP der Steuerebene wie zweckmäßig empfangen werden. Der SAP der Verwaltungsebene und/oder der SAP der Steuerebene aktualisieren dann geeignete Betriebs- und Dienstestromparameter für die MSS in einem Rückführblock 1304, der den Prozeß zum Block 1112 in der 11 zurückführt.

Weiter mit Block 1114 benutzt die Ziel-BS DSA-Nachrichten, um Diensteströme basierend auf der Dienstestrominformation, die im Block 1106 (wenn die Parameter dieselben sind) oder 1112 (wenn die Parameter unterschiedlich sind) erhalten worden ist, zu erzeugen und erzeugt entsprechende Einträge in ihrer wmanIfCmnCpsServiceFlowTable. Wie es durch einen Ende-Block 1116 veranschaulicht ist, beendet dies den Übergabeprozeß, und somit werden die Diensteströme für die MSS nun von der Ziel-BS zur Verfügung gestellt.

Im allgemeinen werden die verschiedenen Arbeitsgänge, die von dem EMS 312 durchgeführt werden, einschließlich denen des SNMP-Verwalters 324, des Proxy-SNMP-Agenten 320, der SAP 354 der Verwaltungsebene und der SAP 352 der Steuerebene, durch entsprechende Softwaremodule und/oder Anwendungen realisiert, die auf einer geeigneten Host-Maschine laufen. Somit können Ausführungsformen dieser Erfindung als oder zur Unterstützung von Software verwendet werden, die auf irgendeiner Form eines Prozessorkerns ausgeführt wird oder auf andere Weise implementiert oder auf oder innerhalb eines maschinenlesbaren Mediums realisiert wird. Ein maschinenlesbares Medium umfaßt irgendeinen Mechanismus zum Speichern oder Senden von Information in einer Form, die von einer Maschine (z.B. einem Computer) lesbar ist. Zum Beispiel kann ein maschinenlesbares Medium beispielsweise einen Nur-Lese-Speicher (ROM – Read Only Memory); einen Speicher mit wahlfreiem Zugriff (RAM – Random Access Memory); ein Magnetplatten-Speichermedium, ein optisches Speichermedium; und ein Flash-Speicherbauteil usw. umfassen. Zusätzlich kann ein maschinenlesbares Medium sich fortpflanzende Signale, so wie elektrische, optische, akustische oder andere Formen sich fortpflanzender Signale (z.B. Trägerwellen, Infrarotsignale, Digitalsignale usw.) umfassen.

Die obige Beschreibung der veranschaulichten Ausführungsformen der Erfindung, einschließlich dem, was in der Zusammenfassung beschrieben ist, ist nicht als erschöpfend oder die Erfindung auf die genauen offenbarten Formen beschränkend gedacht. Obwohl bestimmte Ausführungsformen der und Beispiele für die Erfindung hierin zu veranschaulichten Zwecken beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Umfangs der Erfindung möglich, wie die Fachleute erkennen werden.

Diese Modifikationen können an der Erfindung im Lichte der obigen genauen Beschreibung vorgenommen werden. Die Ausdrücke, die in den folgenden Ansprüchen verwendet werden, sollten nicht so angesehen werden, daß sie die Erfindung auf die in der Beschreibung und in den Zeichnungen offenbarten bestimmten Ausführungsformen beschränken. Statt dessen soll der Umfang der Erfindung vollständig durch die folgenden Ansprüche bestimmt werden, die gemäß den bewährten Lehren der Interpretation von Ansprüchen verstanden werden sollen.

ZUSAMMENFASSUNG

Verfahren und System für die Netzwerkverwaltung und Architekturen für Protokollsoftware für mobile drahtlose Breitbandnetzwerke. Bei einer Ausführungsform benutzt die Softwarearchitektur einen Proxy Simple Network Management Protocol (SNMP)-Agenten an einer Basisstation in dem Neztwerk. Der Proxy-SNMP-Agent kommuniziert mit einem SNMP-Verwalter in einem Netzwerkverwaltungssystem (NMS – Network Management System), wobei SNMP-Nachrichten verwendet werden, um Verwaltungsinformationsbasis (MIB – Management Information Basis)-Objekte zwischen dem NMS und der Basisstation zu verschicken. Der Proxy-SNMP-Agent kommuniziert mit einer mobilen Teilnehmerstation (MSS – Mobile Subscriber Station), wobei Medienzugangssteuerungs (MAC – Media Access Control)-Nachrichten verwendet werden. Die Protokollsoftwarearchitektur umfaßt weiterhin einen Verwaltungsebenen-Dienstezugangspunkt (SAP – Service Access Point) und einen Steuerebenen-SAP, die in der MSS verwendet werden. Die Architektur ermöglicht, daß bestimmte Parameter, die den dynamischen Diensteströmen und der Qualität des Dienstes entsprechen, von einer MSS wiedergewonnen und in eine MSS geschrieben werden können, wobei Proxy-SNMP-Agenten an den Basisstationen verwendet werden.


Anspruch[de]
Softwarearchitektur für ein Breitbandnetzwerk mit drahtlosem Zugang (BWA – Broadband Wireless Access), mit

einem Netzwerkverwaltungssystem (NMS – Network Management System), das einen Simple Network Management Protocol (SNMP)-Verwalter umfaßt;

einer Vielzahl von Proxy-SNMP-Agenten, wobei jeder Proxy-SNMP-Agent an einer jeweiligen Basisstation (BS) in dem BWA-Netzwerk implementiert ist, wobei jeder Proxy-SNMP-Agent in der Lage ist, mit dem SNMP-Verwalter über SNMP-Nachrichten zu kommunizieren, welche Verwaltungsinformationsbasis (MIB – Management Information Base)-Objekte verkapseln, und in der Lage ist, mit einer mobilen Teilnehmerstation (MSS – Mobile Subscriber Station) über einen Verwaltungskanal zu kommunizieren, wobei ein Proxy-SNMP-Agent weiter in der Lage ist, MIB-Objekte, welche in SNMP-Nachrichten verkapselt sind, die von dem SNMP-Verwalter erhalten worden sind, herauszuziehen und Nachrichten an eine MSS über den Verwaltungskanal zu erzeugen und zu verschicken, die Parameter enthalten, welche den MIB-Objekten entsprechen, die herausgezogen sind.
Softwarearchitektur nach Anspruch 1, die weiter aufweist:

einen Dienstezugangspunkt (SAP – Service Access Point) für eine Verwaltungsebene, der in einer MSS implementiert ist, wobei der SAP der Verwaltungsebene Kommunikation zwischen Veraltungsebeneneinheiten in der MSS und dem Proxy-SNMP-Agenten über Verwaltungs-MAC (Medienzugangssteuerung – Media Access Control)-Nachrichten, die über den Verwaltungskanal geschickt werden, unterstützt.
Softwarearchitektur nach Anspruch 1, die weiter aufweist:

einen Dienstezugangspunkt (SAP) für eine Steuerebene, der in einer MSS implentiert ist, wobei der SAP der Steuerebene Kommunikation zwischen Steuer- und/oder Datenebenenkomponenten in der MSS und dem Proxy-SNMP-Agenten über Steuer-MAC (Medienzugangssteuerungs)-Nachrichten, die über den Verwaltungskanal geschickt werden, unterstützt.
Softwarearchitektur nach Anspruch 1, die weiter umfaßt:

einen Dienstezugangspunkt (SAP) für eine Netzwerkebene, um Kommunikation zwischen dem Netzwerkverwaltungssystem und Basisstationen unter Verwendung eines Internet-Protokoll (IP)-Transportes zu unterstützen, über den SNMP-Nachrichten zwischen einem Proxy-SNMP-Agenten und dem SNMP-Verwalter verschickt werden können.
Softwarearchitektur nach Anspruch 1, bei dem das Netzwerkverwaltungssystem aufweist:

ein Elementverwaltungssystem (EMS – Element Management System); und

eine Dienste-Datenbank, die mit dem EMS verbunden ist, um Dienstestromdaten zu speichern, welche Teilnehmer für Dienste betreffen, die von einem Bediener des (BWA)-Netzwerkes zur Verfügung gestellt werden.
Softwarearchitektur nach Anspruch 1, bei der der Proxy-SNMP-Agent weiter in der Lage ist, ein MIB-Element, das dynamische Dienstestrominformation enthält, welche die MSSen betrifft, die gegenwärtig von der Basisstation bedient werden, auf dem der Proxy-SNMP-Agent implementiert ist, zu halten. Softwarearchitektur nach Anspruch 1, bei der eine MSS ein Protokollschicht-Referenzmodell basierend einem Institute of Electrical and Electronic Engineers (IEEE) Std. 802.16, implementiert, welches eine Daten/Steuerebene und eine Verwaltungsebene umfaßt, und der Proxy-SNMP-Agent in der Lage ist, mit jeder, der Daten/Steuerebene und der Verwaltungsebene, über den Verwaltungskanal zu kommunizieren, wobei nach TLV (Typ/Länge/Wert – Type/Length/Value) codierte Nachrichten verwendet werden. Maschinenlesbares Medium zum Speichern einer Vielzahl von Softwaremodulen, einschließlich:

eines Simple Network Management Protocol (SNMP)-Verwaltungsmoduls, das in einem Netzwerkverwaltungssystem für ein Breitbandnetzwerk mit drahtlosem Zugang (BWA) implementiert werden soll;

eines Moduls für einen Proxy-SNMP-Agenten, das an einer Basisstation (BS) in dem BWA-Netzwerk implementiert werden soll, wobei der Proxy-SNMP-Agent in der Lage ist, mit dem SNMP-Verwalter über SNMP-Nachrichten zu kommunizieren, welche Verwaltungsinformationsbasis (MIB)-Objekte verkapseln, und der in der Lage ist, mit einer mobilen Teilnehmerstation (MSS) über eine Verwaltungskanal zu kommunizieren, wobei der Proxy-SNMP-Agent weiter in der Lage ist, MIB-Objekte, die in SNMP-Nachrichten verkapselt sind, welche von dem SNMP-Verwalter empfangen worden sind, herauszuziehen und Nachrichten an eine MSS über den Verwaltungskanal zu erzeugen und zu verschicken, die Parameter enthalten, welche den MIB-Objekten, die herausgezogen sind, entsprechen.
Maschinenlesbares Medium nach Anspruch 8, bei dem die Softwarekomponenten weiter umfassen:

ein Modul für einen Dienstezugangspunkt (SAP) einer Verwaltungsebene, das in einer MSS implementiert werden soll, wobei das Modul für den SAP der Verwaltungsebene Kommunikation zwischen Verwaltungsebeneneinheiten in der MSS und dem Modul für die Proxy-SNMP-Agenten über Verwaltungs-MAC (Medienzugangssteuerung)-Nachrichten, die über den Verwaltungskanal gesendet werden, unterstützt.
Maschinenlesbares Medium nach Anspruch 8, bei dem die Softwarekomponenten weiter umfassen:

ein Modul für den Dienstezugangspunkt (SAP) einer Steuerebene, das in einer MSS implementiert werden soll, wobei das Modul für den SAP der Steuerebene Kommunikation zwischen Steuer/Datenebeneneinheiten in der MSS und in dem Proxy-SNMP-Agentenmodul für MAC (Medienzugangssteuerung)-Nachrichten, die über den Verwaltungskanal gesendet werden, unterstützt.
Maschinenlesbares Medium nach Anspruch 8, bei dem die Softwarekomponenten weiter umfassen:

ein Modul für einen Dienstezugangspunkt (SAP) einer Netzwerkebene, um Kommunikation zwischen dem Netzwerkverwaltungssystem und den Basisstationen zu unterstützen, wobei ein Internetprotokoll (IP)-Transport verwendet wird, über den SNMP-Nachrichten zwischen einem Proxy-SNMP-Agentenmodul und dem SNMP-Verwaltermodul gesendet werden können.
Maschinenlesbares Medium nach Anspruch 8, bei dem die Softwarekomponenten weiter umfassen:

ein Modul für ein Elementverwaltungssystem (EMS), das eine Schnittstelle zu einer Dienste-Datenbank umfaßt, wobei das EMS-Modul Dienstestromdaten wiedergewinnt und speichert, die Teilnehmer für Dienste betrifft, welche von einem Operator des (BWA)-Netzwerkes von der Dienste-Datenbank zur Verfügung gestellt werden.
Maschinenlesbares Medium nach Anspruch 8, bei dem das Modul für die Proxy-SNMP-Agenten weiter in der Lage ist, ein MIB-Element zu halten, das Information über dynamischen Dienststrom enthält, welche MSSn betrifft, die gegenwärtig von der Basisstation bedient werden, auf dem das Modul für den Proxy-SNMP-Agenten implementiert werden soll. Verfahren, das aufweist:

Aktivieren eines Netzwerkverwaltungssystems (NMS) für ein Breitbandnetzwerk mit drahtlosem Zugang (BWA), um mit einer mobilen Teilnehmerstation (MSS) zu kommunizieren, das auf das BWA-Netzwerk über eine Dienste leistende Basisstation (BS) zugreift, indem

ein Simple Network Managment Protocol (SNMP)-Verwalter in dem NMS verwendet wird,

ein Proxy-SNMP-Agent bei der diensteleistenden BS verwendet wird;

Verwaltungsinformationsbasis (MIB)-Objekte, die zum Betrieb der MSS gehören, über SNMP-Nachrichten geschickt werden, in denen die MIB-Objekte eingekapselt sind;

Parameter, die den MIB-Objekten entsprechen, zwischen dem Proxy-SNMP-Agenten und der MSS verschickt werden, wobei ein Verwaltungskanal verwendet wird.
Verfahren nach Anspruch 14, das weiter das Wiedergewinnen von Parametern von einer MSS aufweist, indem Arbeitsgänge durchgeführt werden, die umfassen:

Senden einer SNMP-Nachricht GetRequest von dem SNMP-Verwalter zu dem Proxy-SNMP-Agenten, wobei die Nachricht GetRequest wenigstens ein MIB-Ojekt enthält, das einen oder mehrere Parameter identifiziert, die von der MSS wiedergewonnen werden sollen;

Herausziehen des wenigstens einen MIB-Objektes und des einen oder der mehreren Parameter aus der SNMP-Nachricht GetRequest an den Proxy-SNMP-Agenten;

Erzeugen einer MAC (Medienzugangssteuerung)-Anfragenachricht, die den einen oder die mehreren Parameter identifiziert, die wiedergewonnen werden sollen;

Senden der MAC-Anfragenachricht an die MSS;

Wiedergewinnen des einen oder der mehreren Parameter, die durch die MAC-Anfragenachricht idetifiziert worden sind, von der MSS;

Erzeugen einer MAC-Antwortnachricht, die den einen oder die mehreren Parameter enthält, die wiedergewonnen sind;

Senden der MAC-Antwortnachricht von der MSS an den Proxy-SNMP-Agenten;

Erzeugen einer SNMP-Antwortnachricht, die ein MIB-Objekt umfaßt, welches den einen oder die mehreren Parameter enthält, die wiedergewonnen sind;

Senden der SNMP-Antwortnachricht von dem SNMP-Agenten an den SNMP-Verwalter; und

Herausziehen der Parameter aus dem MIB-Objekt, das in der SNMP-Antwortnachricht enthalten ist.
Verfahren nach Anspruch 15, bei dem der eine oder die mehreren Parameter, die wiedergewonnen sind, sich auf Parameter beziehen, die von einer Verwaltungsebeneneinheit der MSS benutzt werden, und wobei das Verfahren weiter aufweist:

Erzeugen einer Verwaltungs-MAC-Anfragenachricht, die den einen oder die mehreren Parameter identifiziert, die wiedergewonnen werden sollen;

Senden der Verwaltungs-MAC-Anfragenachricht, die von einem Dienstezugangspunkt (SAP) der Verwaltungsebene empfangen werden soll, der auf der MSS implementiert ist;

Wiedergewinnen des einen oder der mehreren Parameter, die durch die Verwaltungs-MAC-Anfragenachricht identifiziert sind, aus wenigstens einer Verwaltungsebeneneinheit über den SAP der Verwaltungsebene;

Erzeugen einer Verwaltungs-MAC-Antwortnachricht, die den einen oder die mehreren Parameter enthält, die wiedergewonnen sind;

Senden der Verwaltungs-MAC-Antwortnachricht von dem SAP der Verwaltungsebene an den Proxy-SNMP-Agenten.
Verfahren nach Anspruch 15, bei dem der eine oder die mehreren Parameter, die wiedergewonnen sind, sich auf Parameter beziehen, die von einer Steuer- oder einer Datenbenenkomponente der MSS benutzt werden, und wobei das Verfahren weiter aufweist:

Erzeugen einer Steuer-MAC-Anfragenachricht, die den einen oder die mehreren Parameter, die wiedergewonnen werden sollen, identifiziert;

Senden der Steuer-MAC-Anfragenachricht, die von einem Dienstezugangspunkt (SAP) einer Steuerebene empfangen werden soll, der auf der MSS implementiert ist;

Wiedergewinnen des einen oder der mehreren Parameter, die von der Steuer-MAC-Anfragenachricht identifiziert sind, von wenigstens einer Steuer- oder Datenebenenkomponente über den SAP der Steuerebene;

Erzeugen einer Steuer-MAC-Antwortnachricht, die den einen oder die mehreren Parameter enthält, die wiedergewonnen sind; und

Senden der Steuer-MAC-Antwortnachricht von dem SAP der Steuerebene an den Proxy-SNMP-Agenten.
Verfahren nach Anspruch 14, das weiter aufweist:

Erfassen eines Eintrages einer MSS in dem BWA-Netzwerk;

Erzeugen eines SNMP-Trap für den SNMP-Verwalter, der die MSS identifiziert;

Herunterladen von Parametern für den Dienstestrom und die Qualität des Dienstes (QoS), die für die MSS von dem NMS bei der Dienste leistenden BS vorab bereitgehalten werden, wobei eine oder mehrere SNMP-Nachrichten verwendet werden;

Belegen eines MIB-Elementes an der diensteleistenden BS mit den Parametern für den Dienstestrom und die QoS für die MSS; und

Senden von Dienstestrom- und QoS-Parametern an die MSS über den Verwaltungskanal.
Verfahren nach Anspruch 14, das weiter aufweist:

Belegen von MIB-Objekten in dem MIB-Element an der Basisstation mit Dienstestrom- und QoS-Parametern für die Basisstation, die gegenwärtigen Diensteströmen entsprechen, die von der diensteleistenden BS für die MSS zur Verfügung gestellt werden; und

Belegen von MIB-Objekten in dem MIB-Element an der Teilnehmerstation mit Dienstestrom- und QoS-Parametern für die Teilnehmerstation, die von der MSS benutzt werden, die den gegenwärtigen Diensteströmen entsprechen, die von der diensteleistenden BS zur Verfügung gestellt werden.
Verfahren nach Anspruch 14, das weiter aufweist:

Feststellen, daß eine Übergabe einer Funkschnittstelle für die MSS von der Dienste leistenden BS an eine Ziel-BS übergeben werden soll;

Senden eines SNMP-Trap von dem Proxy-SNMP-Agenten an der diensteleistenden BS zu dem SNMP-Verwalter; und als Antwort dessen Auslösen;

Herunterladen von Dienstestrom- und Qualität des Dienstes (QoS)-Parametern, die für die MSS von dem NMS bei einem Proxy-SNMP-Agenten vorab bereitgehalten sind, der von der Ziel-BS implementiert ist, wobei eine oder mehrere SNMP-Nachrichten verwendet werden;

Belegen eines MIB-Elementes an der Ziel-BS mit den Dienstestrom- und QoS-Parametern für die MSS; und

Übergeben der Funktschnittstelle für die MSS an die Ziel-BS, wobei Dienstestrom- und QoS-Parameter verwendet werden, die von dem NMS heruntergeladen werden.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com