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;
4a–4e 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.