DE102012220932B4 - Abmildern von Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes - Google Patents

Abmildern von Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes Download PDF

Info

Publication number
DE102012220932B4
DE102012220932B4 DE102012220932.8A DE102012220932A DE102012220932B4 DE 102012220932 B4 DE102012220932 B4 DE 102012220932B4 DE 102012220932 A DE102012220932 A DE 102012220932A DE 102012220932 B4 DE102012220932 B4 DE 102012220932B4
Authority
DE
Germany
Prior art keywords
data
miop
network
rnc
base station
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102012220932.8A
Other languages
English (en)
Other versions
DE102012220932A1 (de
Inventor
Jeremiah D. Carlin
Michael T. Kalmbach
Mark D. Schroeder
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE102012220932A1 publication Critical patent/DE102012220932A1/de
Application granted granted Critical
Publication of DE102012220932B4 publication Critical patent/DE102012220932B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Mobilfunkdatennetz, aufweisend: eine Mehrzahl von Basisstationen, die jeweils mit einer entsprechenden Antenne kommunizieren, die Funksignale an Benutzergeräte sendet und von diesen empfängt, wobei die Mehrzahl von Basisstationen Teil eines Funkzugangsnetzes ist, das mit einem Kernnetz im Mobilfunkdatennetz Daten austauscht; einen Störungsvorhersagemechanismus in einer Basisstation der Mehrzahl von Basisstationen, der aus Verlaufsdaten der Basisstation abgeleitete Verlaufsdatenmuster, örtliche Umgebungsbedingungen der Basisstation und einen örtlichen Wetterbericht verwendet, um eine Störung vorherzusagen; und Ergreifen einer Maßnahme zur Abmilderung der vorhergesagten Störung, bevor eine Störung eintritt, wobei die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme einen Datenaustausch mit Umgebungssystemen aufweist, um Vorbeugungsmaßnahmen zu ergreifen, wobei die Umgebungssysteme ein Umgebungssystem innerhalb der Basisstation aufweisen, das Umgebungsbedingungen innerhalb der Basisstation steuert, und ein Umgebungssystem in einem Breakout-System, das den Störungsvorhersagemechanismus aufweist, und wobei die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme ein allmähliches Beenden des Abzweigens von Daten aller Benutzergeräte und anschließend ein Abschalten des Breakout-Systems aufweist, das den Störungsvorhersagemechanismus aufweist.

Description

  • Hintergrund
  • 1. Technisches Gebiet
  • Diese Offenbarung der Erfindung betrifft Mobilfunksysteme allgemein und insbesondere das Abmildern von Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes.
  • 2. Technischer Hintergrund
  • Mobiltelefone haben sich zu „Smartphones” weiterentwickelt, mit denen ein Benutzer nicht nur telefonieren, sondern auch auf Daten wie beispielsweise eMails, das Internet usw. zugreifen kann. Mobilfunknetze haben sich ebenfalls weiterentwickelt und stellen Datendienste bereit, die von neuen mobilen Einheiten verlangt werden. Beispielsweise bedecken 3G-Netze den größten Teil der USA und ermöglichen Benutzern auf ihren mobilen Einheiten den drahtlosen schnellen Zugriff auf Daten. Darüber hinaus sind Telefone nicht die einzigen Einheiten, die auf Mobilfunkdatennetze zugreifen können. Viele Mobilfunkunternehmen stellen Ausrüstungen und Dienstleistungen bereit, mit deren Hilfe ein Teilnehmer eine Mobilzugangskarte in einen USB-Anschluss (USB = Universal Serial Bus) an einem Notebook-Computer stecken und dem Notebook-Computer über das Mobilfunkdatennetz eine drahtlose Internetverbindung bereitstellen kann. Außerdem können manche neuere Mobiltelefone als drahtloser Hot-Spot fungieren, über den mehrere Notebook-Computer oder andere drahtlose Einheiten mit dem Mobiltelefon verbunden werden können, das wiederum Datendienste über das Mobilfunkdatennetz bereitstellt. Mit fortschreitender Zeit wird die auf Mobilfunkdatennetzen bereitgestellte Datenmenge weiterhin exponentiell wachsen.
  • Mobilfunkdatennetze enthalten sehr teure Hardware und Software, sodass die Erweiterung des Funktionsumfangs bestehender Netze nicht ohne Weiteres zu realisieren ist. Für einen Netzanbieter ist es wegen der Kosten für den Austausch der Ausrüstungen betriebswirtschaftlich nicht durchführbar, alle älteren Ausrüstungen einfach durch neue Ausrüstungen zu ersetzen. In den USA ist das drahtlose Netz der nächsten Generation zum Beispiel das 4G-Netz. Viele Anbieter von Mobilfunkdatennetzen kämpfen immer noch damit, ihr gesamtes System aufzurüsten, um 3G-Datendienste bereitzustellen. Das sofortige Aufrüsten auf 4G-Ausrüstungen ist für die meisten Anbieter von Mobilfunkdatennetzen keine betriebswirtschaftlich realisierbare Option. An vielen Stellen sind Teile des Mobilfunkdatennetzes über Punkt-zu-Punkt-Mikrowellenverbindungen miteinander verbunden. Diese Mikrowellenverbindungen haben eine begrenzte Bandbreite. Um den Durchsatz dieser Verbindungen wesentlich zu erhöhen, müssen die Mikrowellenverbindungen durch Lichtwellenleiterkabel ersetzt werden, aber diese Option ist sehr kostspielig.
  • In einem Mobilfunkdatennetz sind viele Basisstationen mit einem zugehörigen Mobilfunkturm vorhanden. Viele dieser Basisstationen befinden sich an entfernten Standorten, die für den Menschen schlecht oder nur unter Gefahren zu erreichen sind. Die weit verstreuten Basisstationen unterliegen starken klimatischen Schwankungen, die zu einer zeitweiligen Hardwarestörung oder zum vollständigen Ausfall führen können, bis die Basisstation repariert werden kann. Bei der gegenwärtigen Struktur der Netze warten das Kernnetz und die RNC (Radio Network Controller, Netzsteuereinheit), bis eine Störung auftritt (z. B. kann die RNC keine Verbindung zum Turm herstellen), und erst dann werden Wiederherstellungsmaßnahmen eingeleitet. Dies kann zu unnötigen Verzögerungen beim Datenverkehr führen, bis das Netz wiederhergestellt ist. Wenn dies eintritt, stellen Benutzer im Bereich des Turms unter Umständen eine Verschlechterung und/oder den Ausfall des Dienstes fest.
  • Es sind bereits ein Reihe von Dokumenten bekannt, die Mobilfunkdatennetzte beschreiben.
  • Das Dokument WO 2011/034476 A1 beschreibt eine Anordnung in einer Funkbasisstation zum Management von Datenverkehr in einer Zelle einer Funkbasisstation. Die Anordnung weist eine Feststelleinheit auf, die eine maximale Leistung feststellt, welche auf eine verfügbare Leistung für die Basisstation verweist.
  • Im Dokument US 8037749 B2 ist ein Netzwerküberwachungsverfahren beschrieben, durch welches eine Regenmenge in einer Zeitperiode vorhergesagt wird und welches einen Ausfall einer Leitung bedingt durch die vorhergesagte Regenmenge vorhersagt.
  • Dokument US 2010/0228861 A1 beschreibt ein System und ein Verfahren einer Zuweisung für eine Berechnungsaufgabe an einen Satz verteilter Server-Farmen, die jeweils mindesten eine Berechnungseinheit aufweisen.
  • Dokument WO 2010/130270 A1 beschreibt lokalen IP-Zugriff oder Breakout, wobei eine Basisstation einer Verbindungsanforderung, welche von einem Terminal ohne Paketnetzwerkadresse empfangen wurde, eine Paketnetzwerkadresse hinzufügen kann.
  • In der Publikation KR 1020020012358 A des koreanischen Patentamtes ist ein Verfahren zur Überwachung eines Kühlungsteils einer unbemannten Basisstation beschrieben, um die Temperatur der unbemannten Basisstation zu optimieren, um so die Zuverlässigkeit der Basisstation zu erhöhen.
  • In dem Dokument DE 699 34 177 T2 werden Mehrpunkt-Verteilungs/Kommunikationssysteme beschrieben, die bei Millimeter-Wellen-Frequenzen arbeiten, bei denen Verfahren zur Steuerung der Basisstations-Sendeleistung zur Kompensation einer sich zeitlich verändernden Dämpfung auf die drahtlose Verbindungsstrecke zwischen der Basisstation und der Netzwerk-Schnittstelleneinheit an Kundestandorten notwendig sein können.
  • Außerdem offenbart das Dokument WO 99/46921 A2 automatisierte Umgebungsmessstationen, die physisch mit einer Basisstation einer Zellfunksystems verbunden sind. Die Messstationen messen bestimmte Basisphänomene der Atmosphäre und/oder Konzentrationen von bestimmten Substanzen in der Luft.
  • Kurzdarstellung
  • Die Ausrüstung der Basisstationen bei einem Mobilfunkdatennetz ist an vielen entfernten Standorten rauen Umgebungsbedingungen ausgesetzt. Die International Business Machines Corporation (IBM) hat eine Einheit mit der Bezeichnung „Mobile Internet Optimization Platform” (MIOP) auf den Markt gebracht, die im Folgenden als „MIOP@KnotenB” bezeichnet wird. Diese Einheit befindet sich an der Peripherie- oder Basisstation eines Mobilfunkdatennetzes, um eine Plattform zur Unterbringung von Anwendungen bereitzustellen und Dienste des Mobilfunknetzes zu erweitern. Die Einführung einer Peripherieeinheit stellt eine Plattform für zusätzliche Zuverlässigkeitsfunktionen bereit. Wie hier beschrieben mildert ein Störungsvorhersagemechanismus in der Basisstationseinheit die Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes ab. Der Störungsvorhersagemechanismus berücksichtigt Verlaufsdaten, Umgebungsbedingungen, Wetterwarnungen und Wettervorhersagen, um eine Vorbeugungsmaßnahme zur Abwendung eines Teil- oder Totalausfalls der Ausrüstungen der Basisstation zu ergreifen. Die vorgenannten und weitere Merkmale und Vorteile werden anhand der folgenden ausführlicheren Beschreibung deutlich, die in den beigefügten Zeichnungen veranschaulicht ist.
  • Kurzbeschreibung der verschiedenen Ansichten in den Zeichnungen
  • Die Offenbarung der Erfindung wird in Verbindung mit den beigefügten Zeichnungen beschrieben, wobei gleiche Bezeichnungen gleiche Elemente bezeichnen und:
  • 1 ein Blockschaltbild eines dem Stand der Technik entsprechenden Mobilfunkdatennetzes ist;
  • 2 ein Blockschaltbild eines Mobilfunkdatennetzes ist, das einen ersten, zweiten und dritten Dienstmechanismus enthält, die alle über ein Überlagerungsnetz Daten austauschen;
  • 3 ein Blockschaltbild einer möglichen Realisierung von Teilen des in 2 gezeigten Netzes ist, um das Überlagerungsnetz zu veranschaulichen;
  • 4 ein Blockschaltbild der in 2 gezeigten MIOP@KnotenB ist, die einen ersten Dienstmechanismus enthält;
  • 5 ein Blockschaltbild der in 2 gezeigten MIOP@RNC ist, die einen zweiten Dienstmechanismus enthält;
  • 6 ein Blockschaltbild der in 2 gezeigten MIOP@Kern ist, die einen dritten Dienstmechanismus enthält;
  • 7 ein Blockschaltbild eines Verwaltungsmechanismus ist, der mit dem Überlagerungsnetz verbunden ist, das die Funktionen der MIOP@KnotenB, MIOP@RNC und MIOP@Kern verwaltet;
  • 8 ein Ablaufplan des Verfahrens ist, das die in den 2 und 4 gezeigte MIOP@KnotenB durchführt;
  • 9 ein Blockschaltbild ist, das die Abzweigungskriterien (engl. breakout criteria) zeigt, die die MIOP@RNC bei der Entscheidungsfindung darüber verwenden kann, ob Daten abgezweigt werden;
  • 10 ein Ablaufplan eines Verfahrens der MIOP@KnotenB und MIOP@RNC ist, um zu ermitteln, wann Daten abgezweigt werden sollen;
  • 11 ein Ablaufplan eines Verfahrens des ersten Dienstmechanismus in der MIOP@KnotenB ist, um selektiv Daten abzuzweigen, wenn das Abzweigen (engl. breakout) für eine angegebene Teilnehmersitzung zugelassen wurde;
  • 12 ein Ablaufplan eines Verfahrens zum Ermitteln ist, wann MIOP-Dienste für eine angegebene Teilnehmersitzung auszuführen sind; die 13 bis 15 Ablaufpläne sind, die den jeweiligen Datenaustausch zwischen MIOP-Komponenten zeigen, wenn MIOP-Dienste ausgeführt werden;
  • 16 ein Ablaufplan eines Verfahrens zum Verwalten und Anpassen der MIOP-Komponenten ist;
  • 17 ein Blockschaltbild einer bestimmten Realisierung der MIOP@KnotenB und MIOP@RNC ist;
  • die 18 und 19 ein Ablaufplan eines ersten Verfahrens der in 17 gezeigten konkreten Realisierung sind;
  • 20 ein Ablaufplan eines zweiten Verfahrens der in 17 gezeigten konkreten Realisierung ist;
  • 21 ein Ablaufplan eines dritten Verfahrens der in 17 gezeigten konkreten Realisierung ist;
  • 22 ein Ablaufplan eines Verfahrens der in 17 gezeigten konkreten Realisierung ist, um eine Datenanforderung zu verarbeiten, die bei der MIOP@KnotenB zu einem Cachespeicherfehler führt;
  • 23 ein Ablaufplan eines Verfahrens der in 17 gezeigten konkreten Realisierung ist, um eine Datenanforderung zu verarbeiten, die bei der MIOP@KnotenB zu einem Cachespeichertreffer führt;
  • 24 ein Blockschaltbild einer MIOP@KnotenB ist, die Peripherie-Makrodiversität unterstützt;
  • 25 ein Blockschaltbild ist, das den dem Stand der Technik entsprechenden Uplink von Signalisierungsdaten aus mehreren KnotenBs zur RNC veranschaulicht;
  • 26 ein Blockschaltbild ist, das den dem Stand der Technik entsprechenden Downlink von Daten von der RNC zu mehreren KnotenBs veranschaulicht;
  • 27 ein Blockschaltbild ist, das den Uplink von Daten von mehreren KnotenBs zur RNC veranschaulicht;
  • 28 ein Blockschaltbild ist, das den Downlink von Signalisierungsdaten von der RNC zu mehreren KnotenBs veranschaulicht;
  • 29 ein Blockschaltbild ist, das den Downlink von Benutzerdaten von der RNC veranschaulicht;
  • 30 ein Blockschaltbild ist, das ein Beispiel des Uplink-Signalisierungsdatenaustauschs zwischen einer Slave-Basisstation und einer Master-Basisstation und anschließend zur RNC bei Makrodiversität an der Peripherie mit Abzweigung an der Peripherie veranschaulicht;
  • 31 ein Blockschaltbild ist, das ein Beispiel des Downlink-Signalisierungsdatenaustauschs zwischen der RNC und mehreren KnotenBs veranschaulicht;
  • 32 ein Blockschaltbild ist, das ein Beispiel des Downlink-Benutzerdatenaustauschs zwischen der RNC und mehreren KnotenBs veranschaulicht;
  • 33 ein Ablaufplan eines Verfahrens zum Uplink-Signalisierungsdatenaustausch zwischen einer Slave-Basisstation und einer Master-Basisstation und anschließend zur RNC bei Makrodiversität an der Peripherie mit Abzweigung an der Peripherie veranschaulicht;
  • 34 ein Ablaufplan ist, das ein Beispiel des Downlink-Signalisierungsdatenaustauschs zwischen einer RNC und einem Benutzergerät veranschaulicht;
  • 35 ein Ablaufplan eines Verfahrens zur Abwicklung des Aufrechterhaltungs-Datenverkehrs auf einem Funkkanal bei aktiver Makrodiversität an der Peripherie ist;
  • 36 ein Blockschaltbild ist, das mehrere Türme und Basisstationen veranschaulicht, die Daten mit einem Benutzergerät austauschen;
  • 37 ein Blockschaltbild einer Basisstation mit einer MIOP@KnotenB ist, die Nutzungsverlaufsmuster, Umgebungsbedingungen vor Ort und Wettervorhersagen verwendet, um Vorbeugungsmaßnahmen gegen eine Störung zu ergreifen;
  • die 38A bis C Tabellen mit Verlaufsdaten sind, die vom Störungsvorhersagemechanismus erfasst wurden, um zum Ergreifen von Vorbeugungsmaßnahmen gegen eine Störung verwendet zu werden;
  • 39 eine Tabelle mit Verlaufsdatenmustern ist, die vom Störungsvorhersagemechanismus angelegt wurde;
  • 40 ein Ablaufplan eines Verfahrens zum Erzeugen von Nutzungsverlaufsmustern ist: und
  • 41 ein Ablaufplan eines Verfahrens zum Abmildern der Auswirkungen von Störungen aufgrund von Wetterbedingungen in einer Basisstation eines Mobilfunknetzes ist.
  • Detaillierte Beschreibung
  • Die Ansprüche und die hier beschriebene Offenbarung stellen einen Störungsvorhersagemechanismus in der Basisstationseinheit bereit, der die Auswirkungen von wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes abmildert. Der Störungsvorhersagemechanismus berücksichtigt Verlaufsdaten, Umgebungsbedingungen, Wetterwarnungen und Wettervorhersagen, um eine Vorbeugungsmaßnahme zur Abwendung eines Teil- oder Totalausfalls der Ausrüstungen der Basisstation zu ergreifen. Zu den Verlaufsdaten können Störungsverlaufsdaten, Lastverlaufsdaten und Nutzungsverlaufsdatenmuster gehören.
  • Unter Bezugnahme auf 1 ist dort ein dem Stand der Technik entsprechendes Mobilfunkdatennetz 100 gezeigt. Das Mobilfunkdatennetz 100 steht stellvertretend für bekannte 3G-Netze. Das Mobilfunkdatennetz 100 weist vorzugsweise ein Funkzugangsnetz (Radio Access Network, RAN), ein Kernnetz und ein externes Netz auf, wie in 1 gezeigt. Das Funkzugangsnetz weist den Turm 120, die Basisstation 122 mit ihrem entsprechenden KnotenB 130 und eine Funkschnittstelle an einer Funknetzsteuereinheit (Radio Network Controller, RNC) 140 auf. Das Kernnetz weist eine Netzschnittstelle an der Funknetzsteuereinheit 140, den Bedienknoten 150, den Gateway-Knoten 160 und das Anbieterdienstnetz 170 (als Teil des Mobilfunkdatennetzes) auf. Das externe Netz weist ein beliebiges geeignetes Netz auf. Ein geeignetes Beispiel eines externen Netzes ist das Internet 180, wie im konkreten Beispiel in 1 gezeigt.
  • In dem Mobilfunkdatennetz 100 tauscht das Benutzergerät 110 über Funkwellen Daten mit dem Turm 120 aus. Zu Benutzergeräten 110 können beliebige Einheiten gehören, die eine Verbindung zu einem Mobilfunkdatennetz herstellen können, unter anderem ein Mobiltelefon, ein Tablet-Computer, eine mit einem Notebook-Computer verbundene Mobilzugangskarte usw. Der Turm 120 tauscht über eine Netzverbindung Daten mit einer Basisstation 122 aus. Jede Basisstation 122 weist einen KnotenB 130 auf, der mit den Turm 120 und der Funknetzsteuereinheit 140 Daten austauscht. Zu beachten ist, dass eine in 1 nicht dargestellte Ausgangsverzweigung vorhanden ist. Normalerweise sind zehntausende von Türmen 120 vorhanden. Zu jedem Turm 120 gehört normalerweise eine entsprechende Basisstation 122 mit einem KnotenB 130, der mit dem Turm Daten austauscht. Der Datenaustausch des Netzes mit den zehntausenden von Basisstationen 130 wird jedoch durch hunderte von Funknetzsteuereinheiten 140 durchgeführt. Daher kann jede Funknetzsteuereinheit 140 viele KnotenBs 130 in den Basisstationen 120 bedienen. Es können in dem Netz auch andere Elemente zwischen der Basisstation 130 und der Funknetzsteuereinheit 140 vorhanden sein, die in 1 nicht gezeigt sind, beispielsweise Konzentratoren (Konzentrationspunkte) oder RAN-Zusammenfassungseinheiten, die den Datenaustausch mit vielen Basisstationen unterstützen.
  • Die Funknetzsteuereinheit 140 tauscht Daten mit dem Bedienknoten 150 aus. In einem typischen 3G-Netz handelt es sich bei dem Bedienknoten um einen SGSN (Service GPRS Support Node, wobei „GPRS” für „General Packet Radio Service” steht). Der Bedienknoten 150 vermittelt im Auftrag von Mobilfunkteilnehmern den Zugang zu Netzressourcen und realisiert die Richtlinie zur Datenpaketplanung zwischen unterschiedlichen Dienstqualitätsklassen. Außerdem ist er bei einer vorgegebenen Teilnehmersitzung für die Einrichtung des PDP-Kontextes (PDP = Packet Data Protocol) mit dem Gateway-Knoten 160 zuständig. Der Bedienknoten 150 ist in seinem geographischen Dienstbereich für die Übermittlung von Datenpaketen von und zu den Basisstationen zuständig. Zu den Aufgaben des Bedienknotens 150 gehören die Lenkung und Übertragung von Datenpaketen, die Mobilitätsverwaltung (Anschlüsse herstellen und trennen sowie Standortverwaltung), Verwaltung logischer Verbindungen und Funktionen im Zusammenhang mit Authentifizierung und Gebührenberechnung. Der Bedienknoten 150 speichert Standort Informationen und Benutzerprofile aller Teilnehmer, die beim Bedienknoten 150 registriert sind. Zu den Funktionen, die der Bedienknoten normalerweise durchführt, gehören das Tunneln von Datenpaketen unter Verwendung des GTP (GTP = GPRS Tunneling Protocol), die Mobilitätsverwaltung, wenn ein Benutzergerät von einer Basisstation zur nächsten wechselt, und das Abrechnen von Benutzerdaten.
  • Bei einem typischen 3G-Netz ist der Gateway-Knoten 160 ein GGSN (die Abkürzung für „GPRS Support Node”). Der Gateway-Knoten 160 ist für das Zusammenwirken zwischen dem Kernnetz und den externen Netzen zuständig. Aus der Sicht der externen Netze 180 ist der Gateway-Knoten 160 ein Router zu einem Teilnetz, da der Gateway-Knoten 160 die Kernnetz-Infrastruktur vor dem externen Netz „verbirgt”. Wenn der Gateway-Knoten 160 Daten von einem externen Netz (zum Beispiel vom Internet 180) empfängt, die an einen bestimmten Teilnehmer gerichtet sind, leitet der Gateway-Knoten die Daten zum Bedienknoten 150 weiter, der den Teilnehmer bedient. Bei inaktiven Teilnehmern wird Paging ausgelöst. Der Gateway-Knoten 160 wickelt auch die Lenkung der vom Benutzergerät 110 stammenden Datenpakete zu den entsprechenden externen Netzen ab. Als zentraler Punkt unterstützt der Gateway-Knoten 160 die Mobilität des Benutzergerätes 110. Im Wesentlichen sorgt der Gateway-Knoten 160 für die notwendige Lenkung, um die Netzdatenpakete zum Bedienknoten 150 zu tunneln, der ein bestimmtes Benutzergerät 110 bedient.
  • Der Gateway-Knoten 160 wandelt die vom Bedienknoten 150 kommenden Datenpakete in das entsprechende PDP-Format (PDP = Packet Data Protocol) um (z. B. IP oder X.25) und sendet sie an das entsprechende externe Netz. In der anderen Richtung werden PDP-Adressen von Datenpaketen, die vom externen Netz 180 eingehen, in die Adresse des Benutzergerätes 110 des Teilnehmers umgewandelt. Die umadressierten Datenpakete werden an den zuständigen Bedienknoten 150 gesendet. Zu diesem Zweck speichert der Gateway-Knoten 160 die Adresse des aktuellen Bedienknotens des Teilnehmers/der Teilnehmerin und sein bzw. ihr Profil. Der Gateway-Knoten 160 ist für die Zuweisung von IP-Adressen zuständig und der Standard-Router für das Benutzergerät 110 des Teilnehmers. Der Gateway-Knoten 160 führt außerdem Funktionen im Zusammenhang mit Authentifizierung, Gebührenberechnung und Teilnehmerrichtlinien durch. Ein Beispiel einer Teilnehmerrichtlinien-Funktion ist die Bandbreitenbegrenzung zur „fairen Benutzung” und die Sperrung bestimmter Arten des Datenverkehrs wie beispielsweise des Datenverkehrs zwischen gleichberechtigten Einheiten (Peer-to-Peer). Ein weiteres Beispiel einer Teilnehmerrichtlinien-Funktion ist die Verschlechterung auf 2G-Niveau bei einem Teilnehmer, der seine Gebühren im Voraus bezahlt hat (Prepaid), wenn der Wert des Guthabens null beträgt.
  • Ein Next-Hop-Router im Anbieterdienstnetz (Operator Service Network, OSN) empfängt von einem Gateway-Knoten 160 eine Nachricht und leitet den Datenverkehr entweder zum Anbieterdienstnetz 170 oder über einen Internet-Dienstanbieter (Internet Service Provider, ISP) zum Internet 180. Das Anbieterdienstnetz 170 weist in der Regel Betriebslogik auf, die ermittelt, wie der Teilnehmer das Mobilfunkdatennetz 100 nutzen kann. Die Betriebslogik, die den Teilnehmern Dienste bereitstellt, kann als „ummauerter Garten” bezeichnet werden, worunter eine geschlossene oder exklusive Menge von Diensten zu verstehen ist, die Teilnehmern bereitgestellt wird und zu der eine vom Anbieter vorgenommene Steuerung über Anwendungen, Inhalt und Medien auf einem Benutzergerät gehört.
  • Einheiten, die Mobilfunkdatennetze nutzen, benötigen oft den Zugang zu einem externen Netz wie zum Beispiel zum Internet 180. Wenn ein Teilnehmer eine Anforderung auf Daten aus dem Internet eingibt, wird diese Anforderung wie in 1 gezeigt vom Benutzergerät 110 zum Turm 120, zum KnotenB 130 in der Basisstation 122, zur Funknetzsteuereinheit 140, zum Bedienknoten 150, zum Gateway-Knoten 160, zum Anbieterdienstnetz 170 und zum Internet 180 geleitet. Wenn die angeforderten Daten übertragen werden, durchqueren die Daten das gesamte Netz vom Internet 180 bis zum Benutzergerät 110. Die Ressourcen bekannter Mobilfunkdatennetze 100 werden durch das immer weiter anwachsende Volumen von Daten belastet, die zwischen einem Benutzergerät 110 und dem Internet 180 ausgetauscht werden, da alle Daten zwischen den beiden das gesamte Netz durchqueren müssen.
  • Es wurden bisher einige Bemühungen unternommen, um den Internet-Datenverkehr zu verlagern und den Rücktransport von Daten im Mobilfunkdatennetz zu verringern. Zum Beispiel weisen einige Mobilfunkdatennetze einen Knoten mit der Bezeichnung „HomeKnotenB” auf, der einen Teil des Funkzugangsnetzes bildet. Viele Haushalte haben schnelle Internetzugänge, zum Beispiel Direct Subscriber Line (DSL), Kabelfernsehen, drahtlose Zugänge usw. Zum Beispiel nutzt der HomeKnotenB bei einem Privathaushalt mit einem DSL-Anschluss den Vorteil der DSL-Verbindung, indem er Internet-Datenverkehr von und zu einem Benutzergerät direkt zum DSL-Anschluss und nicht über das Mobilfunkdatennetz leitet. Obwohl dies eine effektive Möglichkeit zur Verlagerung des Internet-Datenverkehrs und zur Verringerung des Rücktransports von Daten sein kann, erschwert die HomeKnotenB-Architektur die Bereitstellung vieler Mobilfunknetzdienste wie beispielsweise das rechtmäßige Abfangen, die Mobilität und die Gebührenberechnung im Einklang mit dem 3G- oder 4G-Mobilfunkdatennetz.
  • Unter Bezugnahme auf 2 weist ein Mobilfunkdatennetz 200 Mechanismen auf, die verschiedene Dienste des Mobilfunkdatennetzes in einer Weise bereitstellen, die für die meisten der im Mobilfunkdatennetz vorhandenen Geräte transparent ist. 2 zeigt wie in 1 das Benutzergerät 110, den Turm 120, den KnotenB 130, die Funknetzsteuereinheit 140, den Bedienknoten 150, den Gateway-Knoten 160, den Anbieterdienstknoten 170 und das Internet 180. Zu den Hinzufügungen zum Mobilfunkdatennetz 200 im Vergleich zu dem Mobilfunkdatennetz 100 in 1, das dem Stand der Technik entspricht, gehören die Hinzufügung von drei Komponenten, die Mobilfunknetzdienste im Mobilfunkdatennetz bereitstellen können, zusammen mit einem Netzverwaltungsmechanismus zur Verwaltung der drei Komponenten. Die Mobilfunknetzdienste werden von einer Einheit durchgeführt, die hier als „Mobile Internet Optimization Platform” (MIOP) bezeichnet wird, und die von der Mobile Internet Optimization Platform durchgeführten Dienste werden hier als „MIOP-Dienste” bezeichnet. Die drei MIOP-Komponenten, die diese Mobilfunknetzdienste durchführen, sind in 2 als MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 gezeigt. Ein Netzverwaltungssystem (Network Management System, NMS), das als MIOP@NMS 240 gezeigt ist, verwaltet die gesamte Lösung durch: 1) Verwalten der Funktion der drei MIOP-Komponenten 210, 220 und 230; 2) Ermitteln, welche MIOP@KnotenBs im System über das Überlagerungsnetz zum Zweck der Leistungs-, Fehler- und Konfigurationsverwaltung zu welchen MIOP@RNCs zusammengefasst sind; und 3) Überwachen der Leistungsfähigkeit der MIOP@KnotenBs, um die Mobilfunknetzdienste dynamisch zu ändern und zu konfigurieren. Die MIOP@KnotenB 210, MIOP@RNC 220, MIOP@Kern 230, MIOP@NMS 240 und das Überlagerungsnetz 250 und deren Teilmengen werden hier als „MIOP-Komponenten” bezeichnet.
  • Zu den von der MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 bereitgestellten Mobilfunknetzdiensten gehören beliebige geeignete Dienste im Mobilfunkdatennetz wie beispielsweise Datenoptimierungen, RAN-bezogene Dienste, teilnehmerbezogene Dienste, Anwendungsbereitstellung an der Peripherie, Analysen an der Peripherie usw. Der Begriff „MIOP-Dienste” schließt in dem hier verwendeten Sinn alle Mobilfunknetzdienste ein, die von MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 durchgeführt werden. Außer dass die Dienste in den MIOP-Komponenten MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 angeboten werden, könnten die verschiedenen MIOP-Dienste auch in einer Weise bereitgestellt werden, die auf einer Cloud beruht.
  • Die MIOP@KnotenB 210 weist einen ersten Dienstmechanismus auf und wird als der auf der „Peripherie” beruhende Teil der MIOP-Lösung bezeichnet. Die MIOP@KnotenB 210 befindet sich im Funkzugangsnetz und kann den gesamten Datenverkehr zum und vom KnotenB 130 abfangen. Die MIOP@KnotenB 210 befindet sich vorzugsweise in der Basisstation 222, die durch den gestrichelten Kasten in 2 gezeigt ist. Daher werden alle Daten zum und vom KnotenB 130 zur und von der Funknetzsteuereinheit 140 durch die MIOP@KnotenB 210 geleitet. Die MIOP@KnotenB führt an dem abgefangenen Datenstrom etwas durch, was hier als „Daten abzweigen” bezeichnet wird. Die MIOP@KnotenB überwacht den Signalisierungsdatenverkehr zwischen dem KnotenB und der RNC und fängt bei Verbindungseinrichtung insbesondere die Einrichtung der Transportschicht (Zuordnung des UDP-Ports (UDP = User Datagram Protocol), der IP-Adresse oder des AAL2-Kanals) ab. Bei registrierten Sitzungen wird der Abzweigungsmechanismus (engl. breakout mechanism) 410 so konfiguriert, dass der gesamte Datenverkehr, der zu diesem UDP-Port, dieser IP-Adresse oder diesem AAL2-Kanal gehört, zu einer Datenverlagerungsfunktion weitergeleitet wird. Die MIOP@KnotenB 210 führt somit das Abzweigen von Daten durch, indem ein zuvor bestehender Pfad im Funkzugangsnetz für nicht abgezweigte Daten definiert wird, indem ein neuer zweiter Datenpfad definiert wird, der zuvor nicht für abgezweigte Daten im Funkzugangsnetz bestand, indem Daten als abzuzweigende Daten erkannt werden, die von einem entsprechenden KnotenB empfangen wurden, indem die abzuzweigenden Daten auf dem zweiten Pfad gesendet werden und indem andere Daten weitergeleitet werden, die nicht auf dem ersten Datenpfad abgezweigt werden. Die Signalisierung, die die MIOP@KnotenB 210 vom KnotenB 130 empfängt, wird auf der bestehenden Netzverbindung mit der RNC 140 zur RNC 140 weitergeleitet, selbst wenn der Datenverkehr abgezweigt wird. Somit sieht die RNC 140 den Signalisierungsdatenverkehr und weiß, dass die Teilnehmersitzung aktiv ist, sieht jedoch nicht die Benutzerdaten, die durch die MIOP@KnotenB 210 abgezweigt werden. Die MIOP@KnotenB führt somit je nach den überwachten Datenpaketen zwei getrennte Funktionen durch: 1) Weiterleiten der Datenpakete zur RNC 140 bei Signalisierungsdatenverkehr und Benutzerdaten, die nicht abgezweigt werden (einschließlich von Sprachanrufen); und 2) Umleiten der Datenpakete bei Benutzerdaten, die abgezweigt werden.
  • Sobald die MIOP@KnotenB 210 Benutzerdaten abzweigt, kann sie auf der Grundlage der Art des Datenverkehrs der abgezweigten Daten einen beliebigen geeigneten Dienst durchführen. Da die von der MIOP@KnotenB 210 durchgeführten Dienste im Funkzugangsnetz durchgeführt werden (z. B. an der Basisstation 222), kann die MIOP@KnotenB 210 das Benutzergerät 110 viel schneller bedienen als die Funknetzsteuereinheit 140. Außerdem muss durch das Vorhandensein einer MIOP@KnotenB 210, die zu einem bestimmten KnotenB 130 gehört, eine MIOP@KnotenB nur diejenigen Teilnehmer bedienen, die gegenwärtig mit einem bestimmten KnotenB verbunden sind. Im Gegensatz hierzu muss die Funknetzsteuereinheit, die normalerweise dutzende oder sogar hunderte Basisstationen bedient, alle Teilnehmer bedienen, die auf alle Basisstationen zugreifen, die sie von einem entfernten Standort aus steuert. Infolgedessen ist die MIOP@KnotenB in einer viel besseren Position als die Funknetzsteuereinheit, um Dienste bereitzustellen, die die Dienstqualität und das Betriebsverhalten für die Teilnehmer verbessern.
  • Aufgrund des Abzweigens von Daten im Funkzugangsnetz durch die MIOP@KnotenB 210 können viele unterschiedliche Arten von Diensten im Funkzugangsnetz durchgeführt werden. Zu diesen Diensten können Optimierungen gehören, die den Optimierungen ähneln, die durch im Industriezweig bekannte Lösungen zwischen Funknetzsteuereinheiten und dem Bedienknoten bereitgestellt werden. Die Verlagerung dieser Optimierungen an die Peripherie des Mobilfunkdatennetzes verbessert nicht nur in hohem Maße die Dienstqualität für die Teilnehmer, sondern bildet auch ein Fundament für die Anwendung neuer Arten von Diensten an der Peripherie des Mobilfunkdatennetzes wie zum Beispiel den Abschluss des Maschine-Maschine-Datenverkehrs (Machine-to-Machine, MTM) an der Peripherie (z. B. in der Basisstation), die Unterbringung von Anwendungen an der Peripherie und die Durchführung von Analysen an der Peripherie.
  • Die MIOP@RNC 220 weist einen zweiten Dienstmechanismus im Mobilfunkdatennetz 200 auf. Die MIOP@RNC 220 überwacht den gesamten Datenaustausch zwischen der Funknetzsteuereinheit 140 und dem Bedienknoten 150. Bei dem überwachten Datenaustausch handelt es sich um den gesamten Datenaustausch zur und von der Funknetzsteuereinheit und dem Rest des Kernnetzes. Die MIOP@RNC 220 kann ein oder mehrere Dienste des Mobilfunkdatennetzes bereitstellen. Die MIOP@RNC 220 trifft vorzugsweise die Entscheidung darüber, ob das Abzweigen von Daten möglich ist. Wenn die MIOP@RNC 220 entscheidet, Daten für eine bestimmte Teilnehmersitzung abzuzweigen, kann sie eine Nachricht an die MIOP@KnotenB 210 senden, die zum Abzweigen durch die MIOP@KnotenB 210 berechtigt, oder sie kann je nach den konfigurierten Kriterien für die Abzweigungsentscheidung und dem ausgewählten Funkkanal entscheiden, die Daten an der MIOP@RNC 220 abzuzweigen. Da Nachrichten zum und vom Kernnetz, mit denen der PDP-Kontext für eine bestimmte Teilnehmersitzung eingerichtet wird, durch die MIOP@RNC 220 überwacht werden, wird die Entscheidung darüber, ob Daten abgezweigt werden, in der MIOP@RNC 220 getroffen.
  • Die MIOP@Kern 230 weist einen dritten Dienstmechanismus im Mobilfunkdatennetz 200 auf. Die MIOP@Kern 230 kann dieselben Dienste wie die MIOP@RNC 220 oder eine beliebige geeignete Teilmenge dieser Dienste aufweisen. Wenn entschieden wird, Dienste nicht bei der MIOP@KnotenB 210 oder MIOP@RNC 220 bereitzustellen, können dieselben Dienste sowie noch ausgefeiltere Dienste bei der MIOP@Kern 230 durchgeführt werden. Somit ist das Mobilfunkdatennetz 200 flexibel, da es eine Entscheidung darüber ermöglicht, wo welche Dienste durchgeführt werden sollen. Da die MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 vorzugsweise einige derselben Dienste aufweisen, können die Dienste zwischen Komponenten zusammenwirken (z. B. können die MIOP@KnotenB und MIOP@Kern zusammenwirken, um den TCP-Datenverkehr (TCP = Transfer Control Protocol) zwischen ihnen zu optimieren), oder die Dienste können über das Mobilfunkdatennetz verteilt werden (z. B. führt die MIOP@KnotenB das Abzweigen durch und stellt Dienste für schnellen Datenverkehr bereit, die MIOP@RNC führt das Abzweigen durch und stellt Dienste für langsamen Datenverkehr bereit, und die MIOP@Kern stellt Dienste für nicht abgezweigten Datenverkehr bereit). Die Systemarchitektur der MIOP stellt daher eine sehr leistungsfähige und flexible Lösung bereit, die das dynamische Konfigurieren und Umkonfigurieren während des laufenden Betriebs dahingehend ermöglicht, welche Dienste durch welche MIOP-Komponenten und wo durchgeführt werden. Außerdem können diese Dienste durch die vorteilhafte Nutzung der bestehenden Infrastruktur in einem Mobilfunkdatennetz realisiert werden.
  • Die MIOP@NMS 240 ist ein Netzverwaltungssystem, das die Funktionen der MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 überwacht und steuert. Die MIOP@NMS 240 weist vorzugsweise eine in Echtzeit oder nahezu in Echtzeit ablaufende MIOP-interne Datenüberwachung auf, um zu ermitteln, ob bisherige oder zusätzliche regionale dynamische Änderungen notwendig sind, um Dienste im Mobilfunkdatennetz 200 zu verbessern. Die MIOP@NMS 240 stellt eine Benutzerschnittstelle bereit, über die ein Systemadministrator bewirken und konfigurieren kann, wie die MIOP-Komponenten 210, 220 und 230 funktionieren.
  • Das Überlagerungsnetz 250 ermöglicht den Datenaustausch von MIOP@KnotenB 210, MIOP@RNC 220, MIOP@Kern 230 und MIOP@NMS 240 untereinander. Das Überlagerungsnetz 250 ist vorzugsweise ein virtuelles privates Netz auf einem bestehenden physischen Netz im Mobilfunkdatennetz. Daher handelt es sich bei dieser Darstellung in 2 um eine logische Darstellung, obwohl das Überlagerungsnetz 250 in 2 getrennt von anderen physischen Netzverbindungen gezeigt ist.
  • 3 zeigt eine geeignete Realisierung eines physischen Netzes und des Überlagerungsnetzes in einem beispielhaften Mobilfunkdatensystem. Das bestehende physische Netz in dem Mobilfunkdatennetz vor der Hinzufügung der MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 ist durch die mit Pfeilen versehenen durchgezogenen Linien gezeigt. Dieses konkrete Beispiel in 3 weist viele KnotenBs auf, die in 1 als 130A, 130B, 130C, ..., 130N gezeigt sind. Einige der KnotenBs weisen eine entsprechende MIOP@KnotenB auf. 3 veranschaulicht, dass die MIOP@KnotenBs (wie beispielsweise 210A und 210N) in einer Basisstation mit ihrem entsprechenden KnotenB oder davor im Netz nach dem Konzentrationspunkt angeordnet sein können (wie beispielsweise 210A nach POC3 310). 3 veranschaulicht außerdem, dass eine einzelne MIOP@KnotenB wie beispielsweise die MIOP@KnotenB1 210A zwei unterschiedliche KnotenBs wie beispielsweise KnotenB1 130A und KnotenB2 130B bedienen kann. Ein Teil des Überlagerungsnetzes ist durch die gestrichelten Linien zwischen der MIOP@KnotenB1 210A und dem zweiten Konzentrationspunkt POC2 320, zwischen der MIOP@KnotenB3 210C und dem POC3 315, zwischen der MIOP@KnotenBN 210N und dem POC3 315 und zwischen POC3 315 und POC2 320 gezeigt. Zu beachten ist, dass das Überlagerungsnetz im Funkzugangsnetz-Teil ein virtuelles privates Netz ist, das auf den bestehenden physischen Netzverbindungen realisiert ist. Das Überlagerungsnetz ermöglicht den MIOP@KnotenBs 210A, 210C und 210N, Daten direkt untereinander auszutauschen, wodurch im Mobilfunkdatennetz 200 einige Dienste möglich werden, die zuvor unmöglich waren. 3 zeigt, dass die MIOP@KnotenB1 210A mit einem zweiten Konzentrationspunkt POC2 320 verbunden ist. Die bei POC2 320 von oben ankommenden, teilweise gezeichneten Pfeile stellen Verbindungen zu anderen KnotenBs dar und könnten auch Verbindungen zu anderen MIOP@KnotenBs aufweisen. Ebenso ist POC2 320 mit einem dritten Konzentrationspunkt POC1 330 verbunden, wobei eventuell andere KnotenBs oder MIOP@KnotenBs mit POC1 verbunden sind. Die RNC 140 ist als mit POC1 330 und mit einem ersten Router RT1 340 im Kernnetz verbunden gezeigt. Der Router RT1 340 ist außerdem mit dem SGSN 150 verbunden. Obwohl der SGSN in 3 aus Vereinfachungsgründen nicht gezeigt ist, versteht es sich, dass der SGSN in 3 auch mit den in 2 gezeigten vorgelagerten Kernkomponenten verbunden ist, zu denen der GGSN 160, das OSN 170 und das Internet 180 gehören.
  • Wie in 3 gezeigt ist das Überlagerungsnetz von den KnotenBs zum POC1 330 ein virtuelles privates Netzwerk, das auf bestehenden physischen Netzverbindungen realisiert ist. Das Überlagerungsnetz erfordert jedoch einen zweiten Router RT2 350, der über eine physische Netzverbindung 360 mit dem POC1 330 und über eine physische Netzverbindung 370 mit der MIOP@RNC 220 verbunden ist. Dieser zweite Router RT2 350 kann ein separater Router oder ein innerhalb der MIOP@RNC 220 realisierter Router sein. Die MIOP@RNC 220 ist ebenfalls über eine physische Netzverbindung 380 mit dem Router RT1 340 und darüber hinaus mit der MIOP@Kern 230 verbunden. Die physische Verbindung 380 in 3 ist als punktierte Linie gezeigt, da sie kein Bestandteil des vor dem Hinzufügen der MIOP-Komponenten bereits bestehenden physischen Netzes (Pfeile mit durchgehenden Linien) und kein Bestandteil des Überlagerungsnetzes (Pfeile mit gestrichelten Linien) ist. Zu beachten ist, dass die Verbindung von der MIOP@RNC 220 zur MIOP@Kern 230 über die bestehenden physischen Netze im Kernnetz besteht.
  • An der Konfiguration des physischen Netzes und des Überlagerungsnetzes in 3 ist zu erkennen, dass minimale Änderungen an dem bestehenden Mobilfunkdatennetz notwendig sind, um die MIOP-Komponenten zu installieren. Hauptsächlich hinzugefügt werden müssen ein neuer Router 350 und drei neue physische Netzverbindungen 360, 370 und 380. Sobald ein neuer Router 350 und neue physische Netzverbindungen 360, 370 und 380 installiert sind, werden der Router 350 und MIOP-Komponenten entsprechend konfiguriert, und die im Mobilfunkdatennetz vorhandenen Geräte werden konfiguriert, um das Überlagerungsnetz zu unterstützen, sodass der Betrieb der MIOP-Komponenten für die vorhandenen Netzgeräte vollständig transparent ist.
  • Wie aus 3 zu erkennen ist, werden Daten im Überlagerungsnetz auf bestehenden physischen Netzen von den KnotenBs zum POC1 definiert. Vom POC1 besteht das Überlagerungsnetz auf der Verbindung 360 zum RT2 350, und auf der Verbindung 370 zur MIOP@RNC 220. Daher wird, wenn die MIOP@KnotenB 210 in 2 eine Nachricht an die MIOP@RNC 220 senden muss, die Nachricht gesendet, indem Datenpakete über ein virtuelles privates Netz auf den physischen Netzverbindungen zum POC1, dann an den RT2 350 und anschließend an die MIOP@RNC 220 gesendet werden. Virtuelle private Netze sind nach dem Stand der Technik gut bekannt, sodass sie hier nicht eingehender erörtert werden.
  • Unter Bezugnahme auf 4 weist die MIOP@KnotenB 210 vorzugsweise einen Abzweigungsmechanismus 410, einen Peripherie-Dienstmechanismus 430 und einen Überlagerungsnetzmechanismus 440 auf. Der Abzweigungsmechanismus 410 ermittelt Abzweigungsvoraussetzungen 420, bei deren Erfüllung an diesem Peripherieort Abzweigungen stattfinden dürfen. Der Abzweigungsmechanismus 410 in der MIOP@KnotenB 210 tauscht mit dem in 5 gezeigten Abzweigungsmechanismus 510 in der MIOP@RNC 220 Daten aus, um eine Abzweigungsentscheidung zu erreichen. Der Abzweigungsmechanismus 410 fängt nach dem Empfang einer Nachricht von der MIOP@RNC 220, mit der das Abzweigung nach der Verbindungseinrichtung zugelassen wird, insbesondere die Einrichtung der Transportschicht (Zuordnung des UDP-Ports, der IP-Adresse oder des AAL2-Kanals) ab. Bei berechtigten Sitzungen wird der Abzweigungsmechanismus 410 so konfiguriert, dass der gesamte Datenverkehr, der zu diesem UDP-Port, dieser IP-Adresse oder diesem AAL2-Kanal gehört, zu einer Datenverlagerungsfunktion weitergeleitet wird. Bei Datenverkehr, der nicht abgezweigt werden soll, sendet der Abzweigungsmechanismus 410 die Daten auf dem ursprünglichen Datenpfad im Funkzugangsnetz. Im Wesentlichen fängt die MIOP@KnotenB 210 den gesamten Datenaustausch zur und von der Basisstation 130 ab und kann Dienste „an der Peripherie” durchführen, d. h. an der Peripherie des Funkzugangsnetzes, das sich nahe dem Benutzergerät 110 befindet. Indem Dienste an der Peripherie durchgeführt werden, können die Dienste für Teilnehmer erweitert oder optimiert werden, ohne dass an vorhandenen Geräten im Mobilfunkdatennetz Hardwareänderungen erforderlich sind.
  • Der Abzweigungsmechanismus 410 weist vorzugsweise Abzweigungsvoraussetzungen 420 auf, die ein oder mehrere Kriterien angeben, die erfüllt sein müssen, bevor die Abzweigung von Daten zulässig ist. Ein geeignetes Beispiel von Abzweigungsvoraussetzungen ist die Geschwindigkeit des Kanals. Bei einer möglichen Realisierung werden nur schnelle Kanäle an der MIOP@KnotenB 210 abgezweigt. Somit könnten Abzweigungsvoraussetzungen 420 angeben, dass Teilnehmer auf schnellen Kanälen abgezweigt werden können, während Teilnehmer auf langsamen Kanälen an der MIOP@KnotenB 210 nicht abgezweigt werden. Bei erfüllten Abzweigungsvoraussetzungen 420 registriert die MIOP@KnotenB 210 die Teilnehmersitzung bei der MIOP@RNC 220. Dies ist im Verfahren 800 in 8 gezeigt. Die MIOP@KnotenB 210 fängt den Netzdatenverkehr zum und vom KnotenB (Basisstation) ab und überwacht diesen Datenverkehr (Schritt 810). Wenn der Datenverkehr die Abzweigungsvoraussetzungen (Schritt 820 = NEIN) nicht erfüllt, kehrt das Verfahren 800 zum Schritt 810 zurück. Wenn der Datenverkehr die Abzweigungsvoraussetzungen erfüllt (Schritt 820 = JA), sendet die MIOP@KnotenB 210 auf dem Überlagerungsnetz 250 eine Nachricht an die MIOP@RNC 220, um die Teilnehmersitzung zur Abzweigung zu registrieren (Schritt 830). Nach der Registrierung der Teilnehmersitzung bei der MIOP@RNC 220 ermittelt die MIOP@RNC 220, ob Daten für die Teilnehmersitzung abgezweigt werden sollen und wo die Abzweigung vorgenommen wird, wie nachfolgend eingehender erläutert wird.
  • Unter erneuter Bezugnahme auf 4 weist die MIOP@KnotenB 210 außerdem einen Peripherie-Dienstmechanismus 430 auf. Der Peripherie-Dienstmechanismus 430 stellt ein oder mehrere Dienste des Mobilfunkdatennetzes 200 bereit. Der Peripherie-Dienstmechanismus 430 kann einen beliebigen geeigneten Dienst des Mobilfunkdatennetzes aufweisen, einschließlich und ohne darauf beschränkt zu sein, der Zwischenspeicherung von Daten, von Daten- oder Videokompressionstechniken, von Diensten auf der Grundlage des Push-Verfahrens, der Gebührenberechnung, Bereitstellung von Anwendungen, von Analysen, Sicherheit, Datenfilterung, von neuen Diensten zur Erzielung von Einkünften usw. Der Peripherie-Dienstmechanismus ist der erste von drei Dienstmechanismen in den MIOP-Komponenten. Obwohl der Abzweigungsmechanismus 410 und der Peripherie-Dienstmechanismus 430 in 4 als separate Einheiten gezeigt sind, könnte der erste Dienstmechanismus sowohl den Abzweigungsmechanismus 410 als auch den Peripherie-Dienstmechanismus 430 aufweisen.
  • Die MIOP@KnotenB 210 weist außerdem einen Überlagerungsnetzmechanismus 440 auf. Der Überlagerungsnetzmechanismus 440 stellt eine Verbindung zum Überlagerungsnetz 250 in 2 bereit und ermöglicht dadurch, dass die MIOP@KnotenB 210 mit der MIOP@RNC 220, der MIOP@Kern 230 und der MIOP@NMS 240 Daten austauschen kann. Wie oben erläutert ist das Überlagerungsnetz 250 vorzugsweise ein virtuelles privates Netz auf einem bestehenden physischen Netz im Mobilfunkdatennetz 200.
  • Unter Bezugnahme auf 5 weist die MIOP@RNC 220 vorzugsweise einen Abzweigungsmechanismus 510, einen RNC-Dienstmechanismus 540, einen Überlagerungsnetzmechanismus 550 und ein System zur Analyse und Aufbereitung von Unternehmensdaten (Business Intelligence) 560 auf. Der Abzweigungsmechanismus 510 weist Abzweigungskriterien 520 auf, die ein oder mehrere Kriterien angeben, bei deren Erfüllung die Abzweigung von Daten zulässig ist. Der Teilnehmer-Registrierungsmechanismus 530 empfängt Nachrichten von der MIOP@KnotenB 210 und registriert Teilnehmersitzungen, bei denen die Abzweigungsvoraussetzungen 420 in der MIOP@KnotenB 210 erfüllt sind. Wenn der Abzweigungsmechanismus 510 feststellt, dass die Abzweigungskriterien 520 erfüllt sind, ermittelt der Abzweigungsmechanismus 510 anschließend, wo die Abzweigung stattfinden soll. Wenn die Abzweigung an der MIOP@KnotenB 210 stattfinden kann, sendet die MIOP@RNC 220 auf dem Überlagerungsnetz 250 eine Nachricht an die MIOP@KnotenB 210, mit der das Abzweigen an der MIOP@KnotenB 210 zugelassen wird. Wenn die Abzweigung an der MIOP@RNC 220 stattfinden soll, führt der Abzweigungsmechanismus 510 in der MIOP@RNC 220 die Abzweigung hier auch für den übrigen Datenverkehr durch. Dies ist im Verfahren 1000 in 10 ausführlicher gezeigt. Die MIOP@RNC überwacht den Datenverkehr zwischen der Funknetzsteuereinheit 140 und dem Bedienknoten 150 (Schritt 1010). Wenn der Datenverkehr die Abzweigungsvoraussetzungen (Schritt 1020 = NEIN) nicht erfüllt, kehrt das Verfahren 1000 in der Schleife zum Schritt 1010 zurück. Wenn der Netzdatenverkehr die Abzweigungskriterien erfüllt (Schritt 1020 = JA), ermittelt der Abzweigungsmechanismus 510, ob die Teilnehmersitzung zur Abzweigung registriert ist (Schritt 1030). Eine Teilnehmersitzung ist zur Abzweigung registriert, wenn die MIOP@KnotenB 210 festgestellt hat, dass der Datenverkehr die Abzweigungsvoraussetzungen erfüllt hat und die Teilnehmersitzung zur Abzweigung registriert wurde, wie in
  • 8 gezeigt. Wenn unter erneuter Bezugnahme auf 10 der Teilnehmer zur Abzweigung registriert ist (Schritt 1030 = JA), sendet die MIOP@RNC 220 über das Überlagerungsnetz 250 eine Nachricht an die MIOP@KnotenB 210, mit der das Abzweigen von Datenverkehr für die Teilnehmersitzung zugelassen wird (Schritt 1040). Die MIOP@KnotenB 210 kann dann Datenverkehr für die Teilnehmersitzung abzweigen (Schritt 1050). Wenn der Teilnehmer nicht zur Abzweigung registriert ist (Schritt 1030 = NEIN), prüft das Verfahren 1000, ob die MIOP@RNC im Begriff ist, eine Abzweigung vorzunehmen (Schritt 1060). Wenn nicht (Schritt 1060 = NEIN), ist das Verfahren 1000 beendet. Wenn die MIOP@RNC im Begriff ist, eine Abzweigung vorzunehmen (Schritt 1060 = JA), wird der Datenverkehr an der MIOP@RNC abgezweigt (Schritt 1070).
  • Bei einem konkreten Beispiel geben die Abzweigungsvoraussetzungen an, dass nur schnelle Kanäle an der MIOP@KnotenB 210 abgezweigt werden, und bei Erfüllung der Abzweigungsvoraussetzungen wird die Teilnehmersitzung zur Abzweigung registriert, wie in 8 gezeigt. 10 veranschaulicht, dass die Abzweigung an der MIOP@RNC 220 durchgeführt werden kann, selbst wenn die Abzweigungsvoraussetzungen nicht erfüllt sind. Daher kann die Abzweigung des langsamen Kanals an der MIOP@RNC 220 durchgeführt werden, wenn alle anderen Abzweigungsvoraussetzungen erfüllt sind, selbst wenn die Teilnehmersitzung auf einem langsamen Kanal abgewickelt wird. Das Mobilfunknetzwerk 200 stellt somit eine hohe Flexibilität bei der Ermittlung bereit, wann und wo eine Abzweigung vorgenommen werden soll.
  • Unter erneuter Bezugnahme auf 5 stellt der RNC-Dienstmechanismus 540 einen oder mehrere Dienste für das Mobilfunkdatennetz bereit. Der RNC-Dienstmechanismus 540 ist der zweite von drei Dienstmechanismen in den MIOP-Komponenten. Der RNC-Dienstmechanismus 540 kann einen beliebigen geeigneten Dienst für das Mobilfunkdatennetz aufweisen, einschließlich und ohne darauf beschränkt zu sein, der Zwischenspeicherung von Daten, von Daten- oder Videokompressionstechniken, von Diensten auf der Grundlage des Push-Verfahrens, der Gebührenberechnung, Bereitstellung von Anwendungen, von Analysen, Sicherheit, Datenfilterung, von neuen Diensten zur Erzielung von Einkünften usw.
  • Obwohl der Abzweigungsmechanismus 510 und der RNC-Dienstmechanismus 540 in 5 als separate Einheiten gezeigt sind, könnte der zweite Dienstmechanismus sowohl den Abzweigungsmechanismus 510 als auch den RNC-Dienstmechanismus 540 aufweisen. Der Überlagerungsnetzmechanismus 550 ähnelt dem Überlagerungsnetzmechanismus 440 in 4, der eine logische Netzverbindung zu den anderen MIOP-Komponenten im Überlagerungsnetz 250 in 2 bereitstellt. Die MIOP@RNC 220 weist außerdem eine Business Intelligence 560 auf, aufweisend:
    • 1) Teilnehmer-Verlaufsdaten, die im Laufe der Zeit von dem Mobilfunkdatennetz empfangen wurden, beispielsweise Mobilität und Standort, Mengen, Datenverkehrsarten, verwendete Geräte usw.
    • 2) Netzerkennung einschließlich der KnotenB-Auslastungszustände, des Dienstgebietscodes, der Kanalart, der Anzahl, wie oft die Kanalart während einer PDP-Sitzung umgeschaltet wurde, der Kennung der bedienenden Zelle, der Anzahl von Zeilen und deren Kennungen in der aktiven Gruppe, der Art des PDP-Kontextes, der PDP-Sitzungen je Teilnehmer, der Sitzungsdauer, der Datennutzung, der Liste von URLs (URL = Uniform Resource Locator, Internetadresse) die zur Einordnung von Benutzern durchsucht wurden, der am häufigsten durchsuchten URL, eine Angabe darüber, ob es sich um einen Erstbenutzer oder einen wiederholt auftretenden Benutzer handelt, der Eintrittspunkt-/Verweis-URLs einer bestimmten Website, der Sitzungsüberwachung usw.
    • 3) Zuordnung von Prozeduren zur Ablaufsteuerung zwischen KnotenB und RNC zu Teilnehmern Die Business Intelligence 560 kann vom RNC-Dienstmechanismus 540 genutzt werden, um zu ermitteln, wann und welche Arten von MIOP-Diensten für einen bestimmten Teilnehmer durchzuführen sind. Beispielsweise können sich Dienste für einen Teilnehmer an einem Mobiltelefon von den Diensten für einen Teilnehmer unterscheiden, der einen Notebook-Computer für den Zugang zum Mobilfunkdatennetz nutzt. Bei einem anderen Beispiel könnte eine VOIP-Sitzung (VOIP = Voice Over Internet Protocol) veranlassen, dass Daten abgezweigt werden.
  • Unter Bezugnahme auf 6 weist die MIOP@Kern 230 einen Kern-Dienstmechanismus 610 und einen Überlagerungsnetzmechanismus 620 auf. Der Kern-Dienstmechanismus 610 stellt einen oder mehrere Dienste für das Mobilfunkdatennetz bereit. Der Kern-Dienstmechanismus 610 ist der dritte von drei Dienstmechanismen in den MIOP-Komponenten. Der Kern-Dienstmechanismus 610 kann einen beliebigen geeigneten Dienst für das Mobilfunkdatennetz aufweisen, einschließlich und ohne darauf beschränkt zu sein, der Zwischenspeicherung von Daten, von Daten- oder Videokompressionstechniken, von Diensten auf der Grundlage des Push-Verfahrens, der Gebührenberechnung, Bereitstellung von Anwendungen, von Analysen, Sicherheit, Datenfilterung, von neuen Diensten zur Erzielung von Einkünften usw. Bei einer bestimmten Realisierung ist die MIOP@Kern 230 eine optionale Komponente, da alle benötigten Dienste an der MIOP@KnotenB 210 und MIOP@RNC 220 durchgeführt werden könnten. Bei einer alternativen Realisierung führt die MIOP@Kern 230 einige Dienste durch, während die MIOP@RNC andere Dienste oder keine durchführt. Der Überlagerungsnetzmechanismus 620 ähnelt dem Überlagerungsnetzmechanismus 440 in 4 und 550 in 5, die eine logische Netzverbindung zu den anderen MIOP-Komponenten im Überlagerungsnetz 250 in 2 bereitstellen.
  • Unter Bezugnahme auf 7 ist die MIOP@NMS 240 ein Netzverwaltungssystem, das die Leistungsfähigkeit des Mobilfunkdatennetzes 200 überwacht und verwaltet und die Funktionen der MIOP@KnotenB 210, MIOP@RNC 220 und MIOP@Kern 230 steuert. Die MIOP@NMS 240 weist vorzugsweise einen Netzwerkverwaltungsmechanismus 710, einen Leistungsverwaltungsmechanismus 720, einen Sicherheitsverwaltungsmechanismus 730 und einen Konfigurationsverwaltungsmechanismus 740 auf. Der Netzüberwachungsmechanismus 710 überwacht die Netzzustände wie beispielsweise Alarme im Mobilfunkdatennetz 200. Der Leistungsüberwachungsmechanismus 720 kann bestimmte Dienste aktivieren, deaktivieren oder präzisieren, indem er die Ausführung von Diensten in Echtzeit oder nahezu in Echtzeit unterstützt, die beispielsweise Daten zur Bewertung der Kundenzufriedenheit erfassen. Der Sicherheitsverwaltungsmechanismus 730 verwaltet Sicherheitsprobleme im Mobilfunkdatennetz wie beispielsweise die Erkennung von Angriffen von außen oder zusätzlichen Datenschutz. Der Konfigurationsverwaltungsmechanismus 740 steuert und verwaltet die Konfiguration der MIOP@KnotenB 210, der MIOP@RNC 220 und der MIOP@Kern 230 so, dass diese dynamisch an beliebige geeignete Kriterien angepasst werden, einschließlich Daten, die vom Netzüberwachungsmechanismus empfangen werden, der Tageszeit, von Daten, die von der Business Intelligence 560 empfangen werden, usw.
  • 9 zeigt beispielhafte Abzweigungskriterien 520, die in 5 gezeigt sind und in Schritt 1020 in 10 verwendet werden. Zu geeigneten Abzweigungskriterien 520 gehören der Name des Zugangspunktes, die Kennung des Benutzergerätes, die Art des Benutzergerätes, die Dienstqualität, die Teilnehmerkennung, die Mobilfunk-Ländervorwahl und die Mobilfunknetzvorwahl. Beispielsweise könnten die Abzweigungskriterien 520 angeben, dass MIOP-Dienste bei Teilnehmern des Anbieters durchgeführt und MIOP-Dienste bei Roaming-Kunden nicht durchgeführt werden. Bei einem anderen Beispiel könnten die Abzweigungskriterien 520 angeben, dass nur Videoanforderungen abgezweigt werden. Eine statische Abzweigungsentscheidung wird während der Aktivierung des PDP-Kontextes durchgeführt. Auf der Grundlage von IP-Datenströmen (z. B. oberflächliche Überprüfung der Datenpakete des IP-Quintupels) werden innerhalb dieser PDP-Teilnehmersitzung unter Umständen nur bestimmte IP-Datenströme erkannt und dynamisch abgezweigt (z. B. VOIP-Datenverkehr), wie ausführlicher im Zusammenhang mit 11 erörtert wird. Das Abzweigungskriterium 520 erstreckt sich ausdrücklich auf beliebige geeignete Kriterien zur Entscheidungsfindung über die Abzweigung.
  • Unter erneuter Bezugnahme auf 10 sendet die MIOP@RNC eine Nachricht an die MIOP@KnotenB, mit der das Abzweigen des Datenverkehrs für diese Teilnehmersitzung zugelassen wird (Schritt 1040), wenn der Datenverkehr die Abzweigungskriterien erfüllt (Schritt 1020 = JA) und die Teilnehmersitzung für die Abzweigung registriert ist (Schritt 1030 = JA). Als Reaktion beginnt die MIOP@KnotenB mit dem Entschlüsseln des Trägers, indem die Signalisierung und der durch sie getunnelte IP-Datenverkehr des Benutzers überprüft werden, und kann den Datenverkehr dieser Teilnehmersitzung abzweigen (Schritt 1050). Zu beachten ist jedoch, dass die MIOP@KnotenB nach wie vor entscheiden kann, auf der Grundlage anderer Kriterien wie zum Beispiel der Art der IP-Anforderung, des Ziels des Datenverkehrs oder der Anwendung des entschlüsselten Benutzerdatenverkehrs auf der OSI-Schicht 7 (OSI = Open Systems Interconnect) nicht den gesamten Datenverkehr abzuzweigen. Die Ermittlung der Anwendung kann einfach durch eine Überprüfung des IP-Quintupels oder optional über eine Überprüfung auf der Schicht 7 mithilfe von DPI-Techniken (DPI = Deep Packet Inspection) durchgeführt werden. Dies ist im konkreten Beispiel in 11 gezeigt. Das Verfahren 1050 in 10 ist eine geeignete Realisierung des Schritts 1050 in 10. Die MIOP@KnotenB überwacht IP-Anforderungen vom Teilnehmer (Schritt 1110). Wenn die IP-Anforderung des Benutzerdatenverkehrs mit einem angegebenen Artkriterium übereinstimmt (Schritt 1120 = JA), wird die IP-Sitzung für den Teilnehmer abgezweigt (Schritt 1130). Wenn die IP-Anforderung nicht mit einer angegebenen Kriterienart übereinstimmt (Schritt 1120 = NEIN), wird keine Abzweigung durchgeführt. Beispielsweise wird angenommen, dass IP-Anforderungen des Zugangs auf Video über das RTP-Anwendungsprotokoll (RTP = Rapid Transport Protocol) der Schicht 7 abgezweigt werden, sodass die Videodaten in der MIOP@KnotenB zwischengespeichert werden können, andere Anforderungen wie beispielsweise Google-Suchvorgänge jedoch nicht. Die MIOP@KnotenB überwacht die IP-Anforderungen vom Teilnehmer (Schritt 1110), und wenn die IP-Anforderung der Teilnehmersitzung RTT-Datenverkehr für ein Video transportiert (Schritt 1120 = JA), wird die IP-Sitzung abgezweigt (Schritt 1130). Andernfalls wird die IP-Sitzung nicht an der MIOP@KnotenB abgezweigt. Dies ist ein einfaches Beispiel zur Veranschaulichung der zusätzlichen Flexibilität und Intelligenz innerhalb der MIOP@KnotenB, die ermitteln kann, ob bei einer bestimmten Teilnehmersitzung die Abzweigung an der MIOP@KnotenB vorgenommen werden soll, nachdem die Durchführung der Abzweigung bei dieser Teilnehmersitzung durch die MIOP@RNC zugelassen wurde. Es könnten beliebige geeignete Kriterien verwendet werden, um zu ermitteln, was und wann an der MIOP@KnotenB abzuzweigen ist, sobald die MIOP@KnotenB in Schritt 1040 in 10 zur Abzweigung berechtigt wurde.
  • Unter Bezugnahme auf 12 zeigt das Verfahren 1200 ein Verfahren zum Ermitteln, wann MIOP-Dienste auszuführen sind. Der PDP-Aktivierungskontext bei einem Teilnehmer wird überwacht (Schritt 1210). Ein PDP-Aktivierungskontext wird eingerichtet, wenn das Benutzergerät 110 eine Verbindung zum Turm 120 herstellt und der Teilnehmer eine Anwendung ausführt, die die PDP-Aktivierungsprozedur auslöst. Das Kernnetz ermittelt den Teilnehmer und eventuell ein entsprechendes Benutzergerät. Wenn MIOP-Dienste freigegeben sind (Schritt 1220 = JA), werden Dienste für diese Teilnehmersitzung ausgeführt (Schritt 1230), bis Daten vom Teilnehmer eintreffen. Wenn MIOP nicht zugelassen sind (Schritt 1220 = NEIN), werden keine MIOP-Dienste ausgeführt. Bei einem einfachen Beispiel sind MIOP-Dienste in einem Mobilfunknetz bei berechtigten Teilnehmern zugelassen, aber nicht bei Roaming-Teilnehmern von einem anderen Mobilfunkunternehmen.
  • MIOP-Dienste erfordern unter Umständen den Datenaustausch zwischen MIOP-Komponenten auf dem Überlagerungsnetz. Unter Bezugnahme auf 13 zeigt ein Verfahren 1300 den Datenaustausch der MIOP@KnotenB, wenn MIOP-Dienste ausgeführt werden (Schritt 1310). Wenn der Peripherie-Dienstmechanismus einen Datenaustausch mit der MIOP@RNC (Schritt 1320 = JA) erfordert, tauscht die MIOP@KnotenB über das Überlagerungsnetz Nachrichten mit der MIOP@RNC aus (Schritt 1330). Wenn der Peripherie-Dienstmechanismus einen Datenaustausch mit der MIOP@Kern (Schritt 1340 = JA) erfordert, tauscht die MIOP@KnotenB über das Überlagerungsnetz (Schritt 1350) Nachrichten mit der MIOP@Kern aus. Das Überlagerungsnetz ermöglicht somit den verschiedenen MIOP-Komponenten den Datenaustausch untereinander, wenn MIOP-Dienste ausgeführt werden.
  • 14 zeigt ein Verfahren 1400, das den Datenaustausch der MIOP@RNC zeigt, wenn MIOP-Dienste ausgeführt werden (Schritt 1410). Wenn der RNC-Dienstmechanismus einen Datenaustausch mit der MIOP@KnotenB (Schritt 1420 = JA) erfordert, tauscht die MIOP@RNC über das Überlagerungsnetz Nachrichten mit der MIOP@KnotenB aus (Schritt 1430). Wenn der RNC-Dienstmechanismus einen Datenaustausch mit der MIOP@Kern (Schritt 1440 = JA) erfordert, tauscht die MIOP@RNC über das Überlagerungsnetz Nachrichten mit der MIOP@Kern aus (Schritt 1450).
  • 15 zeigt ein Verfahren 1500, das den Datenaustausch der MIOP@Kern zeigt, wenn MIOP-Dienste ausgeführt werden (Schritt 1510). Wenn der Kern-Dienstmechanismus einen Datenaustausch mit der MIOP@KnotenB (Schritt 1520 = JA) erfordert, tauscht die MIOP@Kern über das Überlagerungsnetz Nachrichten mit der MIOP@KnotenB aus (Schritt 1530), die über die MIOP@RNC geleitet werden. Wenn der Kern-Dienstmechanismus einen Datenaustausch mit der MIOP@RNC (Schritt 1540 = JA) erfordert, tauscht die MIOP@Kern über das Überlagerungsnetz Nachrichten mit der MIOP@RNC aus (Schritt 1550).
  • 16 zeigt ein Verfahren 1600, das vorzugsweise durch die MIOP@NMS 240 in den 2 und 7 durchgeführt wird. Die Leistungsfähigkeit und Effizienz der MIOP-Komponenten, die MIOP-Dienste durchführen, wird überwacht (Schritt 1610). Zu den MIOP-Komponenten, die MIOP-Dienste durchführen, können die MIOP@KnotenB 210, die MIOP@RNC 220 und die MIOP@Kern 230 gehören, wobei angenommen wird, dass alle diese Komponenten im Mobilfunkdatennetz 200 vorhanden sind. Wenn die Leistungsfähigkeit verbessert werden kann (Schritt 1620 = JA), wird die Leistungsfähigkeit der MIOP-Komponenten angepasst (sofern realisiert und anwendbar), indem eine oder mehrere Netznachrichten über das Überlagerungsnetz gesendet werden (Schritt 1630). Zu beachten ist auch, dass ein Bediener die MIOP-Komponenten auch manuell umkonfigurieren könnte, um sie effizienter zu machen.
  • Unter Bezugnahme auf 17 sind dort Realisierungen der MIOP@KnotenB 210 und der MIOP@RNC 220 beispielhaft gezeigt. Im Rahmen des Schutzbereichs der Offenbarung der Erfindung und der hier aufgeführten Ansprüche sind andere Realisierungen möglich. Das Benutzergerät 110 ist mit dem KnotenB 130 verbunden. Zu beachten ist, dass die in 2 gezeigte Antenne 120 in 17 nicht gezeigt ist, aber es versteht sich, dass sie vorhanden ist, um den Datenaustausch zwischen den Benutzergerät 110 und dem KnotenB 130 zu ermöglichen. Die MIOP@KnotenB 210 weist einen Peripherie-Cachemechanismus 1730 auf, bei dem es sich um ein geeignetes Beispiel eines Peripherie-Dienstmechanismus 430 in 4 handelt. Die MIOP@KnotenB 210 weist eine Schnittstelle auf, die hier als „IuB-Datenverlagerungsgateway” (IuB-DOGW) 1710 bezeichnet wird. Dieses Gateway 1710 realisiert den Abzweigungsmechanismus 410 gemäß einer oder mehreren angegebenen Abzweigungsvoraussetzungen 420, die in 4 gezeigt sind. Das IuB-DOGW 1710 weist eine Schaltanwendung 1740, einen Verlagerungs-Datenhandler 1750 und einen RNC-Kanalhandler 1760 auf. Die Schaltanwendung 1740 ist zuständig für die Überwachung von Datenpaketen, die vom KnotenB 130 empfangen werden, leitet entsprechend ihrer Konfiguration die abgezweigten Datenpakete zum Verlagerungs-Datenhandler weiter und sendet die nicht abgezweigten Datenpakete und Datenströme des Steuerungssystems über die ursprünglichen Verbindungen im RAN an die RNC 140 weiter. Obwohl die Schaltanwendung 1740 in 17 in Form zweier getrennter Rechtecke gezeigt ist, um optisch anzuzeigen, dass die Schaltanwendung 1740 Schaltvorgänge an zwei unterschiedlichen Schnittstellen vornimmt, an der Netzschnittstelle und an der Überlagerungsnetzschnittstelle, handelt es sich bei der Schaltanwendung 1740 vorzugsweise um eine einzige Einheit.
  • Wenn eine Abzweigungsentscheidung getroffen wird und die MIOP@RNC 220 eine Nachricht an die MIOP@KnotenB 210 sendet, mit der die Abzweigung zugelassen wird (siehe Schritt 1040 in 10) und wenn die MIOP@KnotenB entscheidet, angegebene Benutzerdaten abzuzweigen, werden die angegebenen Benutzerdaten abgezweigt, die durch die Schaltanwendung 1740 vom KnotenB empfangen wurden, was bedeutet, dass die Schaltanwendung 1740 die angegebenen Benutzerdaten zum Verlagerungs-Datenhandler 1750 leitet, sodass die abgezweigten Daten zu dem für die Abzweigungsdaten festgelegten Datenpfad geleitet werden. Der Verlagerungs-Datenhandler 1750 kann die Daten zwecks Verarbeitung an den Peripherie-Cachemechanismus 1730 senden, der die Daten über das Überlagerungsnetz direkt zur MIOP@RNC 220 leiten kann, wie durch den Pfad mit den Pfeilen gezeigt, die vom KnotenB zur MIOP@RNC 220 verlaufen. Nicht abgezweigte Benutzerdaten und Signalisierungsdatenverkehr werden durch die Schaltanwendung 1740 direkt zur RNC zurückgeleitet. Auf diese Weise gelangen nicht abgezweigte Daten und Signalisierungsdatenverkehr durch das IuB-DOGW 1710 zur RNC 140, während abgezweigte Daten vom IuB-DOGW 1710 zu einem anderen Ziel geleitet werden. Zu beachten ist, dass der Peripherie-Cachemechanismus 1730 wie in 17 gezeigt Nachrichten an die MIOP@RNC 220 senden kann, die abgezweigten Nachrichten selbst aber nicht an die MIOP@RNC 220 gesendet werden.
  • Die MIOP@RNC 220 weist eine Schnittstelle auf, die hier als „IuPS-Datenverlagerungsgateway” (IuPS-DOGW) 1770 bezeichnet wird. Das IuPS-DOGW 1770 leitet den gesamten Signalisierungsdatenverkehr und den gesamten nicht abgezweigten Datenverkehr von der RNC 140 über den GTP-Tunnel zum SGSN 150. Das IuPS-DOGW 1770 weist einen Abzweigungsmechanismus 510, Abzweigungskriterien 520 und einen Teilnehmer-Registrierungsmechanismus 530 auf, die in 5 gezeigt und oben unter Bezugnahme auf 5 erörtert sind. Das IuPS-DOGW 1770 kann mit dem IuB-DOGW 1710 Nachrichten über das Überlagerungsnetz austauschen, um beliebige in der MIOP@KnotenB 210 oder in der MIOP@RNC 220 benötigte Dienste durchzuführen. Obwohl das IuPS-DOGW 1770 in der MIOP@RNC 220 keinen Verlagerungs-Datenhandler aufweist, könnte das IuPS-DOGW 1770 bei der in 17 gezeigten konkreten Realisierung einen Verlagerungs-Datenhandler und eine Schaltanwendung aufweisen, die den in der MIOP@KnotenB 210 gezeigten Einheiten ähneln, wenn die MIOP@RNC 220 ebenfalls das Abzweigen von Daten durchführen soll.
  • Das IuPS-DOGW 1770 weist einen RNC-Kanalhandler 1780 auf. Die RNC-Kanalhandler 1760 in der MIOP@KnotenB 210 und 1780 in der MIOP@RNC 220 überwachen den Datenverkehr zur und von der RNC 140 im Zusammenhang mit einer Abzweigungs-Teilnehmersitzung und stellen einen Keepalive-Mechanismus zur Aufrechterhaltung von Kanälen bereit.
  • In den 18 bis 21 sind bestimmte Verfahren gezeigt, die veranschaulichen, wie die konkrete Realisierung in 17 verwendet werden könnte. Die 18 und 19 zeigen ein Verfahren 1800 zum Einrichten der Abzweigung von Daten. Das Benutzergerät (BG) sendet eine Verbindungsanforderung an die RNC (Schritt 1810). Die RNC richtet eine Funkverbindung über den KnotenB ein (Schritt 1815). Die RNC richtet anschließend eine Netzverbindung mit dem KnotenB ein (Schritt 1820). Das BG und der SGSN tauschen anschließend Daten im Zusammenhang mit der Anschluss- und Authentifizierungsprozedur aus (Schritt 1825). Das IuB-DOGW erkennt die Führungsnachricht in der Anschluss- und Authentifizierungsprozedur und registriert die Teilnehmersitzung beim IuPS-DOGW, wenn die Voraussetzungen erfüllt sind (das BG kann z. B. schnellen Datenverkehr durchzuführen) (Schritt 1830). Während der Anschluss- und Authentifizierungsprozedur überwacht das IuPS-DOGW den vom SGSN an die RNC gesendeten Sicherheitskontext (Schritt 1835). Das IuPS-DOGW sendet dann Schlüssel an das IuB-DOGW (Schritt 1840). Diese Schlüssel werden zur Dechiffrierung (Entschlüsselung) der bevorstehenden Signalisierungsdaten und Uplink-Benutzerdaten sowie zur Chiffrierung (Verschlüsselung) der Downlink-Benutzerdaten benötigt. Das BG fordert dann beim SGSN die PDP-Kontextaktivierung an (Schritt 1845). Als Reaktion richtet der SGSN einen Netztunnel zur RNC ein (Schritt 1850). Das IuPS-DOGW überwacht die Einrichtung des Netztunnels vom SGSN zur RNC und trifft eine Entscheidung „Abzweigung = JA” (Schritt 1855). Das IuPS-DOGW sendet eine Nachricht an das IuB-DOGW, mit der „Abzweigung = JA” angezeigt wird (Schritt 1860). Unter Fortsetzung der Bezugnahme bei 19 sendet der SGSN eine RAB-Zuweisungsanforderung (RAB = Radio Access Bearer, Funkzugangskanal) an das BG (Schritt 1865). Das IuPS-DOGW erkennt die RAB-Zuweisungsanforderung vom SGSN an das BG und ersetzt die Transportadresse des SGSN durch die Transportadresse des IuPS-DOGW (Schritt 1870). Das IuPS-DOGW sendet eine Nachricht an die MIOP@Kern, mit der „Abzweigung = JA” angezeigt wird (Schritt 1875). Die RNC tauscht Daten mit dem KnotenB und dem BG aus, um den Funkkanal für Signalisierung und Daten zu konfigurieren bzw. umzukonfigurieren (Schritt 1880). Die RNC quittiert dem SGSN, wenn die RAB-Zuweisung abgeschlossen ist (Schritt 1885). Der SGSN übernimmt die PDP-Kontextaktivierung, indem er eine Nachricht an das BG sendet (Schritt 1890). BG und SGSN können anschließend Daten zu dem PDP-Kontext austauschen (Schritt 1895).
  • Unter Bezugnahme auf 20 beginnt ein Verfahren 2000, indem ein PDP-Kontext eingerichtet wird (Schritt 2010). Das Verfahren 1800 in den 18 und 19 enthält die ausführlichen Schritte zum Einrichten eines PDP-Kontextes. Bei „Abzweigung = JA” werden RAB-Zuweisungsanforderungen vom SGSN an die RNC durch das IuPS-DOGW überwacht (Schritt 2020). Das IuPS-DOGW ändert beliebige RAB-Zuweisungsannforderungen vom SGSN an die RNC ab, um die Transportadresse des SGSN in der RAB-Zuweisungsanforderung durch die Transportadresse des IuPS-DOGW zu ersetzen (Schritt 2030), wenn Abzweigungskriterien während der Prozedur zur PDP-Kontextaktivierung übereinstimmen. Die Schaltanwendung beim IuB-DOGW wird nach Einrichtung der RAN-Transportschicht konfiguriert, um auf der Grundlage von IP-Adressen und Ports den abgezweigten Datenverkehr zu erkennen, und leitet diesen Datenverkehr zum Verlagerungs-Datenhandler 1765 und nicht abgezweigten Datenverkehr sowie Datenströme des Steuerungssystems zur RNC weiter (Schritt 2040).
  • Unter Bezugnahme auf 21 beginnt ein Verfahren 2100, wenn der KnotenB Daten zur RNC sendet (Schritt 2110). Die Schaltanwendung im IuB-DOGW leitet den abgezweigten Datenverkehr zum Peripherie-Dienstmechanismus (Schritt 2120) um, beispielsweise zum Peripherie-Cachemechanismus 1730 in 17. Die Schaltanwendung leitet außerdem über die ursprünglichen RAN-Verbindungen nicht abgezweigte Daten und Signalisierungsdaten an die RNC weiter (Schritt 2130). Die RNC kann von der MIOP@KnotenB nach wie vor Daten von nicht abgezweigtem Datenverkehr empfangen, wenn „Abzweigung = JA” ist (Schritt 2140). Die RNC sendet dann Datenverkehr vom BG, der nicht von der MIOP@KnotenB abgezweigt wurde, an die Transportadresse des IuPS-DOGW, die in der RAB-Zuweisungsanforderung angegeben ist, wenn „Abzweigung = JA” ist (Schritt 2150).
  • Es folgt ein einfaches Beispiel für die konkrete Realisierung in 17, um zu zeigen, wie Daten durch die MIOP@KnotenB 210 zwischengespeichert und übermittelt werden können. Unter Bezugnahme auf 22 stellt das Verfahren 2200 Schritte dar, die bei der Realisierung in 17 bei einem Cachespeicherfehler durchgeführt werden. Das BG sendet eine Datenanforderung an den KnotenB (Schritt 2010). Der KnotenB sendet die Datenanforderung an das IuB-DOGW (Schritt 2215). Es wird angenommen, dass die angeforderten Daten den Verlagerungskriterien bei der MIOP@KnotenB (Schritt 2220) entsprechen, was bedeutet, dass die MIOP@KnotenB berechtigt worden ist, die Abzweigung durchzuführen und festgestellt hat, dass diese angeforderten Daten abgezweigt werden sollen. Das IuB-DOGW sendet die Datenanforderung an den Peripherie-Cachemechanismus (Schritt 2225). Es wird angenommen, dass die Daten nicht im Peripherie-Cachemechanismus vorhanden sind, sodass der Peripherie-Cachemechanismus wegen des Cachespeicherfehlers die Datenanforderung an das IuB-DOGW zurücksendet (Schritt 2230). Das IuB-DOGW sendet die Datenanforderung dann über das Überlagerungsnetz an die MIOP@RNC (Schritt 2235). Im ungünstigsten Fall, in dem der Inhalt nicht in der MIOP@RNC oder in der MIOP@Kern gespeichert ist, leitet die MIOP@RNC die Datenanforderung über das Überlagerungsnetz zur MIOP@Kern, die die Datenanforderung auf der Leitung zum Internet überträgt, das die angeforderten Daten zur MIOP@Kern übermittelt, die die angeforderten Daten über das Überlagerungsnetz zur MIOP@RNC übermittelt (Schritt 2240). Das IuPS-DOGW sendet dann die angeforderten Daten an das IuB-DOGW (Schritt 2245). Das IuB-DOGW sendet dann die angeforderten Daten an den Peripherie-Cachemechanismus (Schritt 2250). Der Peripherie-Cachemechanismus speichert die angeforderten Daten zwischenzeitlich (Schritt 2255). Der Peripherie-Cachemechanismus sendet die angeforderten Daten an das IuB-DOGW (Schritt 2260). Der Verlagerungs-Datenhandler im IuB-DOGW sendet die angeforderten Daten an den KnotenB (Schritt 2265). Der KnotenB sendet die angeforderten Daten an das BG (Schritt 2270). An diesem Punkt ist das Verfahren 2200 abgeschlossen.
  • Das Verfahren 2300 in 23 zeigt die Schritte, die bei der konkreten Realisierung in 17 bei einem Cachespeichertreffer durchgeführt werden. Das BG sendet die Datenanforderung an den KnotenB (Schritt 2310). Der KnotenB sendet die Datenanforderung an das IuB-DOGW (Schritt 2320). Die angeforderten Daten entsprechen den Verlagerungskriterien bei der MIOP@KnotenB (Schritt 2330). Das IuB-DOGW sendet die Datenanforderung an den Peripherie-Cachemechanismus (Schritt 2340). Wegen eines Cachespeichertreffers sendet der Peripherie-Cachemechanismus die angeforderten Daten aus dem Cachespeicher an das IuB-DOGW (Schritt 2350). Der Verlagerungs-Datenhandler im IuB-DOGW sendet die angeforderten Daten an den KnotenB (Schritt 2360). Der KnotenB sendet dann die angeforderten Daten an das BG (Schritt 2370). Das Verfahren 2300 zeigt beim Zwischenspeichern von Daten bei der MIOP@KnotenB einen großen Vorteil. Bei Daten, die bei der MIOP@KnotenB zwischengespeichert sind, können die Daten ohne Transportaufwand im Kernnetz an das Benutzergerät übermittelt werden. Die Folge ist eine verringerte Netzwerküberlastung im Kernnetz, während gleichzeitig die Dienstqualität für den Teilnehmer verbessert wird.
  • Die in den 18 bis 23 gezeigten Verfahren stellen detaillierte Schritte für die Realisierung in 17 bereit. Andere Realisierungen können detaillierte Schritte aufweisen, die sich von denen in den 18 bis 23 gezeigten Schritten unterscheiden. Diese Schritte sind als Beispiel gezeigt und stellen keine Einschränkung der Offenbarung und der hier aufgeführten Ansprüche dar.
  • Die Architektur des MIOP-Systems ermöglicht die Schichtung oder Verschachtelung von Diensten. Beispielsweise könnte das MIOP-System feststellen, dass an der MIOP@KnotenB Abzweigungen von schnellen Kanälen und an der MIOP@RNC Abzweigungen von langsamen Kanälen vorzunehmen sind. Bei einem weiteren Beispiel kann die MIOP@KnotenB auch einen Cachespeicher aufweisen, und die MIOP@Kern kann ebenfalls einen Cachespeicher aufweisen. Bei einem Cachespeicherfehler an der MIOP@KnotenB könnte der gleich in der MIOP@RNC geprüft werden, gefolgt von einer Prüfung des Cachespeicher in der MIOP@Kern. Somit können entsprechend den sich ändernden Bedingungen Entscheidungen dynamisch getroffen werden, welche Daten wo zwischengespeichert werden sollen.
  • Zur Unterstützung der MIOP-Dienste, die bei dem in 2 gezeigten Mobilfunkdatennetz 200 möglich sind, ist die bevorzugte Konfiguration der MIOP@KnotenB 210 eine Kombination aus Hardware und Software. Die bevorzugte Konfiguration der MIOP@RNC 220 ist ebenfalls eine Kombination aus Hardware und Software. Die bevorzugte Konfiguration der MIOP@Kern 230 besteht nur aus Software und kann auf beliebiger geeigneter Hardware im Kernnetz ausgeführt werden. Die bevorzugte Konfiguration der MIOP@NMS 240 besteht nur aus Software und kann ebenfalls auf beliebiger geeigneter Hardware im Kernnetz ausgeführt werden.
  • Bei der am meisten bevorzugten Realisierung werden die verschiedenen Funktionen der MIOP@KnotenB 210, der MIOP@RNC 220, der MIOP@Kern 230 und der MIOP@NMS 240 in einer Weise durchgeführt, die für vorhandene Ausrüstungen im Mobilfunkdatennetz nahezu transparent ist. Daher haben die Komponenten des dem Stand der Technik entsprechenden Mobilfunkdatennetzes 100, die auch im Mobilfunkdatennetz 200 in 2 gezeigt sind, keine Kenntnis vom Vorhandensein der verschiedenen MIOP-Komponenten, ausgenommen vorhandene Router, die möglicherweise entsprechend den MIOP-Komponenten mit Leitwegeinträgen aktualisiert werden müssen. Die MIOP-Dienste werden durch die MIOP-Komponenten in einer Weise bereitgestellt, die keine Änderungen an der Hardware und nur minimale Änderungen an der Software (d. h. neue Routereinträge) und an beliebigen vorhandenen Ausrüstungen im Mobilfunkdatennetz erfordert, wodurch der Betrieb der MIOP-Komponenten für die vorhandenen Ausrüstungen transparent wird, sobald die MIOP-Komponenten installiert und konfiguriert sind. Das Ergebnis ist ein System zum Aufrüsten von in 1 gezeigten bestehenden Mobilfunkdatennetzen in einer Weise, die bei den vorhandenen Ausrüstungen keine umfangreichen Änderungen an der Hardware oder Software erfordert. Die hier aufgeführten MIOP-Dienste können daher durchgeführt werden, ohne dass erhebliche Investitionen zum Ersatz oder zur Neuprogrammierung vorhandener Ausrüstungen erforderlich sind.
  • Das hier offenbarte Mobilfunkdatennetz 200 weist MIOP-Komponenten auf, die eine Vielfalt unterschiedlicher Dienste bereitstellen, die in dem dem Stand der Technik entsprechenden Mobilfunkdatennetz 100 nicht möglich sind. Bei der am meisten bevorzugten Realisierung betreffen die MIOP-Komponenten nicht den Sprachdatenverkehr im Mobilfunkdatennetz. Außer der Durchführung von Optimierungen, die die Leistungsfähigkeit in Form von verbesserten Geschwindigkeiten beim Herunterladen, kürzeren Verzögerungszeiten beim Zugriff oder einer verbesserten Qualität der Darstellung beim Anzeigen von Multimedia im Mobilfunkdatennetz verbessern, stellt die MIOP-Architektur auch zusätzliche Funktionen bereit, die für den Betreiber möglicherweise neue Aktivitäten zur Erzielung von Einkünften schaffen. Zum Beispiel können bei Teilnehmersitzungen Analysen durchgeführt werden, die es dem Betreiber ermöglichen, bestimmten Teilnehmern zusätzliche Dienste bereitzustellen, um zusätzliche Einkünfte zu erzielen. Beispielsweise könnte Teilnehmern, die bei einer Live-Musikveranstaltung zusammenkommen, Werbung über kostenpflichtige Medien gesendet werden, die im Zusammenhang mit dieser Veranstaltung stehen. Bei einem anderen Beispiel könnte Teilnehmern, die aus einem Eisenbahnzug aussteigen, ein Gutschein mit einer Werbung für ein bestimmtes Nahverkehrsunternehmen gesendet werden, während die Teilnehmer auf dem Bahnsteig in Richtung Straße gehen. Ebenso könnte hochwertiger Webinhalt in Form von Video- oder anderen Multimediainhalten von einem lokalen Speicher bereitgestellt werden, und der Teilnehmer würde für den zusätzlichen Inhalt und die zusätzliche Dienstqualität zahlen.
  • Obwohl das hier erörterte und in 2 gezeigte Mobilfunknetz im Kontext eines 3G-Mobilfunkdatennetzes angesiedelt ist, erstrecken sich die Offenbarung der Erfindung und die Ansprüche ausdrücklich auch auf andere Netze, unter anderem auf LTE-Netze (LTE = Long Term Evolution), flache RAN-Netze und CDMA-Netze (CDMA = Code Division Multiple Access).
  • 24 veranschaulicht eine erweiterte Version der in 4 eingeführten MIOP@KnotenB. Außer dem oben beschriebenen Abzweigungsmechanismus 410, dem Peripherie-Dienstmechanismus 430 und dem Überlagerungsnetzmechanismus 440 weist die MIOP@KnotenB 210 vorzugsweise auch einen Peripherie-Makrodiversitätsmechanismus 2420 mit einem Uplink-Datenkombinationsmechanismus 2430 und Konfigurationsdaten der aktiven Gruppe 2440 auf. Eine MIOP@KnotenB 2410 ist eine Art von Peripherie-Verarbeitungsmechanismus. Der Peripherie-Makrodiversitätsmechanismus 2420, der Uplink-Datenkombinationsmechanismus 2430 und Konfigurationsdaten der aktiven Gruppe 2440 werden nachfolgend ausführlicher beschrieben. Im hier verwendeten Sinn ist ein Peripherie-Verarbeitungsmechanismus ein allgemeiner Begriff für einen Mechanismus, der die Funktionen der hier beschriebenen MIOP@KnotenB durchführt.
  • Unter Bezugnahme auf 24 werden die Konfigurationsdaten der aktiven Gruppe 2440 durch den Peripherie-Makrodiversitätsmechanismus 2420 verwaltet, der eine Kopie der aktiven Gruppe und der Kennung der Master-MIOP@KnotenB enthält. Zur Änderung der aktiven Gruppen bei einem typischen System sendet die RNC eine Nachricht an das BG. Die MIOP@KnotenBs überwachen diese Signalisierungsnachricht, um die aktuellen Mitglieder der aktiven Gruppe für die Konfigurationsdaten der aktiven Gruppe zu ermitteln. Die MIOP@KnotenBs können über das Überlagerungsnetz Konfigurationsinformationen mit anderen MIOP@KnotenBs austauschen, um die Konfigurationsdaten der aktiven Gruppe 2440 zu verwalten.
  • Da die MIOP-Komponenten über das Überlagerungsnetz miteinander verbunden sind, unterstützt diese Architektur in einer MIOP@KnotenB die Durchführung der Makrodiversität an der Peripherie. Beim gegenwärtigen Stand der Technik wurde die Makrodiversität in der RNC 140 abgewickelt. 25 ist ein Blockschaltbild, das dem Stand der Technik entsprechende Uplink-Daten vom Benutzergerät über mehrere KnotenBs zur RNC veranschaulicht. Wie oben erläutert kann ein Benutzergerät wie beispielsweise ein Mobiltelefon Signale von Antennen erkennen, die sich an unterschiedlichen Basisstationen befinden. Bei diesem Beispiel erkennt das Benutzergerät 110 die Antennen von drei Basisstationen mit entsprechenden KnotenBs 130A, 130B und 130C. Die drei KnotenBs 130A, 130B und 130C stellen die aktive Gruppe von Basisstationen für das BG dar, die an der Makrodiversität für eine bestimmte Sitzung teilnimmt. Eine aktive Gruppe ist die Gruppe von KnotenBs, mit denen das BG gleichzeitig verbunden ist. Jeder KnotenB der aktiven Gruppe leitet Datenpakete zur RNC 140 weiter. Die RNC wählen die besten Datenpakete von den drei KnotenBs 130A, 130B und 130C aus, um die Daten vom BG 110 zusammenzusetzen. Die aktive Gruppe wird durch die RNC verwaltet, und alle Makrodiversitätsfunktionen werden durch die RNC durchgeführt. Die Makrodiversität muss zur Durchführung des Signalisierungsdatenverkehrs unterstützt werden, da ansonsten die Gefahr des Verlustes von Signalisierungsdaten besteht. Wenn Signalisierungsnachrichten verloren gehen, verliert die MIOP@KnotenB unter Umständen in Bezug auf dieses BG die Synchronisierung mit dem Netz und kann möglicherweise die Sitzungen dieses BG nicht mehr verwalten.
  • 26 ist ein Blockschaltbild, das den dem Stand der Technik entsprechenden Downlink von Daten von der RNC zu mehreren KnotenBs 130A, 130B und 130C veranschaulicht. Die drei KnotenBs 130A, 130B und 130C stellen die aktive Gruppe von KnotenBs für das BG dar, das an der Makrodiversität teilnimmt. Die RNC 140 leitet Downlink-Daten zu jedem KnotenB der aktiven Gruppe weiter. Die KnotenBs 130A, 130B und 130C senden dann die Downlink-Daten an das BG 110, das die Datenpakete von den KnotenBs der aktiven Gruppe wieder kombiniert.
  • 27 veranschaulicht ein Beispiel von Uplink-Signalisierungsdaten von mehreren KnotenBs, die wie hier beschrieben und beansprucht von mehreren KnotenBs an die RNC gesendet werden. Bei diesem Beispiel erkennt das Benutzergerät 110 die Antennen von drei Basisstationen mit entsprechenden KnotenBs 130A, 130B und 130C. Diese drei KnotenBs stellen die aktive Gruppe in derselben Weise wie beim gegenwärtigen Stand der Technik beschrieben dar. Die drei KnotenBs 130A, 130B, 130C weisen bei diesem Beispiel jedoch jeweils eine entsprechende MIOP@KnotenB 2410A, 2410B, 2410C auf. Wie oben beschrieben stellen die MIOP@KnotenBs durch das Abzweigen von Benutzerdaten Mobilfunkdienste an der Peripherie des Mobilfunkdatennetzes bereit. Die MIOP@KnotenBs 2410A, 2410B und 2410C fangen Uplink-Signalisierungsdaten von ihren entsprechenden KnotenBs 130A, 130B und 130C in der aktiven Gruppe ab. Eine der MIOP@KnotenBs ist als Master festgelegt, während die anderen als Slaves festgelegt sind. Die Slave-MIOP@KnotenBs übermitteln dann empfangene Datenpakete an die Master-MIOP@KnotenB. Bei diesem Beispiel in 27 ist die MIOP@KnotenB 2410B der Master. Die übrigen beiden MIOP@KnotenBs 2410A und 2410C senden ihre Uplink-Daten über das Überlagerungsnetz (z. B. 250 in 2) wie bei 2710 und 2720 in 27 gezeigt an die Master-MIOP@KnotenB 2410B. Der Master 2410B kombiniert dann seine eigenen Uplink-Signalisierungsdaten mit den von den beiden Slave-MIOP@KnotenBs 2410A und 2410C empfangenen Signalisierungsdaten und erzeugt aus diesen kombinierten Daten ein bestes Datenpaket. Jede Slave-MIOP@KnotenB sendet ihre Daten an die Master-MIOP@KnotenB, die die Daten von allen in einem besten Datenpaket kombiniert. Auf diese Weise weist die Master-MIOP@KnotenB exakt dieselben Signalisierungsdaten wie die RNC auf, wenn sie die Datenpakete kombiniert. Dieser Vorgang wird nachfolgend ausführlicher erläutert.
  • 28 veranschaulicht ein Beispiel von Downlink-Signalisierungsdaten von der RNC 140 zu mehreren KnotenBs 130A, 130B und 130C. Die RNC 140 sendet die Downlink-Signalisierungsdaten an alle drei KnotenBs 130A, 130B und 130C, die gegenwärtig (d. h. in der aktiven Gruppe) mit dem BG 110 verbunden sind. Durch die RNC 140 gesendete Signalisierungsdaten werden durch jede MIOP@KnotenB 2410A, 2410B und 2410C empfangen und anschließend ohne Veränderung an die betreffenden KnotenBs 130A, 130B und 130C übermittelt. Die KnotenBs 130A, 130B und 130C senden dann die Downlink-Daten an das BG 110, das die Datenpakete von den KnotenBs der aktiven Gruppe wieder kombiniert. Beim Downlink von Signalisierungsdaten muss die Makrodiversität nicht unterstützt werden, da der Datenaustausch von der RNC zur MIOP@KnotenB über eine robustere Netzverbindung oder eine nicht luftgestützte Schnittstelle stattfindet. Daher müssen die MIOP@KnotenBs die Nachrichten nicht kombinieren, sondern die Nachrichten werden beim BG kombiniert.
  • Wie eingangs bereits unter Bezugnahme auf 17 erläutert tauscht das Benutzergerät 110 Daten mit einem KnotenB 130A aus, der mit einer RNC 140 verbunden ist. Die MIOP@KnotenB 210B befindet sich in einer Leitung zwischen dem KnotenB und der RNC 140, sodass die MIOP@KnotenB den Datenverkehrsstrom überwachen und anschließend Signalisierungsdaten und nicht abgezweigte Benutzerdaten über den ursprünglichen Pfad an die RNC weiterleiten kann. Wenn eine Sitzung wie oben beschrieben abgezweigt wird, tauscht die MIOP@KnotenB 210B über das Überlagerungsnetz 250 Daten mit der MIOP@RNC 220 aus, um die Makrodiversität wie oben beschrieben zu verwalten.
  • 29 veranschaulicht den Downlink von Benutzerdaten. Bei gemeinsam genutzten schnellen Kanälen, die zum Senden von Downlink-Benutzerdaten an das BG verwendet werden, steht die Makrodiversität nicht zur Verfügung. Infolgedessen sendet die RNC 140 die Downlink-Benutzerdaten nur an eine der MIOP@KnotenBs 2410B, die die Downlink-Benutzerdaten an ihren entsprechenden KnotenB 130B sendet, der die Downlink-Benutzerdaten an das Benutzergerät 110 sendet. 29 zeigt lediglich, dass die Makrodiversität bei gemeinsam genutzten schnellen Kanälen nicht zur Verfügung steht, die zum Downlink von Benutzerdaten verwendet werden.
  • 30 ist ein Blockschaltbild, das ein Beispiel des Uplink-Signalisierungsdatenaustauschs zwischen einem BG 110, KnotenBs 130B, 130C, einer Master-MIOP@KnotenB 2410B, einer Slave-MIOP@KnotenB 2410C und der RNC 140 bei Makrodiversität an der Peripherie mit Abzweigung an der MIOP@KnotenB veranschaulicht. Zu beachten ist, dass die MIOP@KnotenBs 2410B und 2410C Instanzen der in 24 gezeigten MIOP@KnotenB 2410 sind, wobei jede einen Peripherie-Makrodiversitätsmechanismus 2420 aufweist. Die Konfiguration in 30 ist eine ausführlichere Darstellung des in 27 gezeigten Beispiels mit der Ausnahme, dass in 30 nur zwei der drei KnotenBs und entsprechende MIOP@KnotenBs gezeigt sind, die in 27 gezeigt sind. Bei dem Beispiel in 30 ist der Makrodiversitätsmechanismus 2420B in dem IuB-DOGW 1710 realisiert, der oben im Zusammenhang mit 17 beschrieben wurde. Es wird angenommen, dass sich eine Sitzung zwischen dem BG 110 und dem ersten KnotenB 130B bereits im Abzweigungszustand über das IuB-Datenverlagerungsgateway 1710 befindet, wie oben unter Bezugnahme auf 17 beschrieben. Eine Sitzung gelangt in einen bedingten Übergabezustand, wenn sich die aktive Gruppe ändert, um einen weiteren KnotenB 130C aufzunehmen. Der Datenstrom bei Uplink-Signalisierungsdaten würde wie folgt verlaufen, wenn sich ein BG 110 im bedingten Übergabezustand befindet. Das BG 110 sendet Signalisierungsdaten 3010 an beide KnotenBs 130B und 130C. Die KnotenBs 130B und 130C senden 3020 die Uplink-Signalisierungsdaten an ihre jeweiligen MIOP@KnotenB 2410B, 2410C. Der Peripherie-Makrodiversitätsmechanismus 2420 erkennt, dass sich die aktive Gruppe ändert, und stellt fest, dass der neue KnotenB 130C in der aktiven Gruppe eine zugehörige MIOP@KnotenB 210C aufweist. Eine der MIOP@KnotenBs ist als Master festgelegt. Bei diesem speziellen Beispiel wird angenommen, dass die MIOP@KnotenB 2410B als Master festgelegt ist, was der MIOP@KnotenB 2410C über das Überlagerungsnetz mitgeteilt wird, wodurch die MIOP@KnotenB 2410C zu einem Slave wird. Die MIOP@KnotenB 2410C sendet Uplink-Signalisierungsdaten 3030 an die Master-MIOP@KnotenB 2410B. Die Uplink-Signalisierungsdaten 3030 von der Slave-MIOP@KnotenB 2410C an die Master-MIOP@KnotenB 2410B werden über das oben beschriebene Überlagerungsnetz 250 transportiert. Die Slave-MIOP@KnotenB 2410C kann ebenfalls Signalisierungsdaten an die RNC 140 senden 3040, um zu gewährleisten, dass die Master-MIOP@KnotenB 2410B und die RNC 140 dasselbe Genauigkeitsniveau in den kombinierten Daten feststellen. Ein Uplinkdaten-Kombinationsmechanismus 2430 kombiniert Uplink-Daten in der Master-MIOP@KnotenB 2410 mit Uplink-Daten, die von allen Slave-MIOP@KnotenBs empfangen wurden, bei diesem Beispiel von der einen Slave-MIOP@KnotenB 2410C, um ein bestes Datenpaket zu erzeugen, sodass die MIOP@KnotenB dieselben Signalisierungsdaten wie die RNC aufweist, wenn sie die Datenpakete kombiniert.
  • 31 ist ein Blockschaltbild, das ein Beispiel des Downlink-Signalisierungsdatenaustauschs zwischen einer RNC 140 und dem BG 110 bei einem System veranschaulicht, das MIOP@KnotenBs für Makrodiversität an der Peripherie mit Abzweigung an einer MIOP@KnotenB aufweist. Die Konfiguration in 31 ist eine ausführlichere Darstellung des in 28 gezeigten Beispiels mit der Ausnahme, dass in 31 nur zwei der drei KnotenBs und entsprechende MIOP@KnotenBs gezeigt sind, die in 28 gezeigt sind. Bei dem Beispiel in 31 werden die Downlink-Signalisierungsdaten 3110 durch die RNC 140 an die Master-MIOP@KnotenB 2410B und die Slave-MIOP@KnotenB 2410C gesendet. Das IuB-DOGW in jeder MIOP@KnotenB 2410B und 2410C leitet diese Daten ohne Änderung an die jeweiligen KnotenBs 130B und 130C weiter. Die KnotenBs 130A, 130B und 130C senden dann die Daten an das BG 110, das die Datenpakete wieder kombiniert, die es von den KnotenBs 130B und 130C empfangen hat.
  • 32 ist ein Blockschaltbild, das ein Beispiel des Uplinks und Downlinks von Benutzerdaten bei einem System veranschaulicht, das MIOP@KnotenBs für Makrodiversität an der Peripherie mit Abzweigung an einer MIOP@KnotenB aufweist. Die Konfiguration in 32 ist eine ausführlichere Darstellung des in 29 gezeigten Beispiels für den Downlink-Fall mit der Ausnahme, dass in 32 nur zwei der drei KnotenBs und entsprechende MIOP@KnotenBs gezeigt sind, die in 29 gezeigt sind. Bei dem Beispiel in 32 ist in dem wie oben im Zusammenhang mit 29 geschilderten Fall von Downlink-Benutzerdaten bei gemeinsam genutzten schnellen Steuerkanälen die Makrodiversität an der Peripherie nicht verfügbar, da die Kanäle nicht zu einem einzelnen BG gehören. Infolgedessen werden die Downlink-Daten 3210 von der RNC 140 an das IuB-DOGW 1710 gesendet, das die Daten zum KnotenB 130B weiterleitet, der die Daten zum Benutzergerät 110 weiterleitet. Die Daten werden nicht zur Slave-MIOP@KnotenB 2410C gesendet, da die Makrodiversität beim Downlink von Benutzerdaten nicht zur Verfügung steht.
  • Beim Uplink von Benutzerdaten im Zusammenhang mit 32 lädt das Benutzergerät 110 die Benutzerdaten 3220 in die KnotenB 130B und 130C hoch. Jeder der KnotenBs 130B und 130C sendet die Uplink-Benutzerdaten 3020 an seine jeweiligen MIOP@KnotenBs 2410B und 2410C. Die Slave-MIOP@KnotenB 2410C leitet die Daten nicht zur RNC 140 weiter. Die Master-MIOP@KnotenB 2410B leitet die Uplink-Benutzerdaten zum Peripherie-Cachemechanismus 1730 weiter. Es wird angenommen, dass das Ergebnis ein Cachespeichertreffer ist, was bedeutet, dass die Daten vom Peripherie-Cachemechanismus 1730 in das Benutzergerät 110 heruntergeladen werden können, ohne dass auf einem öffentlichen Netz auf die Daten zugegriffen werden muss. Als Reaktion sendet der Peripherie-Cachemechanismus 1730 die Downlink-Daten an das IuB-DOGW 1710, das die Daten an den KnotenB 130B sendet. Der KnotenB 130B übermittelt die Downlink-Daten an das BG 110. Da die abgezweigten Daten in den MIOP@KnotenBs wie oben im Zusammenhang mit 17 beschrieben an der RNC 140 nicht zu sehen sind, kann die RNC wegen der Sicht auf abgezweigte Daten, die vor der RNC verborgen wäre, keine Makrodiversität für beliebige KnotenBs durchführen, die einen entsprechenden MIOP@KnotenB aufweisen. Da die RNC diesen abgezweigten Datenverkehr nicht sieht, sendet der RNC-Kanalhandler 1760 in der MIOP@KnotenB Datenverkehr zur Aufrechterhaltung von Kanälen auf der Funkverbindung 3210 an die RNC, sodass die RNC die abgezweigte Sitzung mit dem BG aufrechterhält und die Makrodiversität auf diesen Datenverkehr zur Aufrechterhaltung von Kanälen anwendet.
  • Die Beispiele in den 30 bis 32 veranschaulichen, dass die Makrodiversität an der Peripherie des Mobilfunkdatennetzes (d. h. in einer Master-MIOP@KnotenB) durchgeführt werden kann, selbst wenn eine Abzweigung an der Peripherie des Mobilfunkdatennetzes stattfindet.
  • 33 ist ein Ablaufplan eines Verfahrens 3300 zur Abwicklung des Uplinks von Signalisierungsdaten für die Makrodiversität an der Peripherie bei Abzweigung an der Peripherie. Die Schritte des Verfahrens 3300 werden vorzugsweise durch Einheiten durchgeführt, die oben unter Bezugnahme auf 30 beschrieben sind. Das Verfahren 3300 beginnt mit mindestens einer MIOP@KnotenB in einer aktiven Gruppe einer abgezweigten Teilnehmersitzung. Ein BG sendet Signalisierungsdaten an zwei oder mehr KnotenBs (Schritt 3310). Die KnotenBs senden dann die empfangenen Uplink-Signalisierungsdaten an ihre jeweiligen MIOP@KnotenBs (Schritt 3320). Eine Änderung in der aktiven Gruppe wird erkannt (Schritt 3330). Anhand der Änderung in der aktiven Gruppe wird festgestellt, dass ein neuer KnotenB zur aktiven Gruppe hinzugefügt wurde. Wenn der neue KnotenB keine MIOP@KnotenB aufweist (Schritt 3340 = NEIN), wird die Datenabzweigungssitzung an der Peripherie beendet (Schritt 3350), und das Verfahren 3300 ist abgeschlossen. Wenn der neue KnotenB eine entsprechende MIOP@KnotenB aufweist (Schritt 3340 = JA), wird die neue MIOP@KnotenB als Slave festgelegt (Schritt 3360). Die Slave-MIOP@KnotenB sendet Uplink-Signalisierungsdaten an die Master-MIOP@KnotenB (Schritt 3370). Die Master-MIOP@KnotenB kombiniert dann ihre eigenen Uplink-Signalisierungsdaten mit den von den Slaves empfangenen Uplink-Signalisierungsdaten, um ein bestes Datenpaket zu erzeugen (Schritt 3380). Das Verfahren 3300 ist dann abgeschlossen.
  • 34 ist ein Ablaufplan eines Verfahrens zur Abwicklung des Downlinks von Signalisierungsdaten für die Makrodiversität an der Peripherie bei Abzweigung an der Peripherie. Die RNC sendet Downlink-Signalisierungsdaten an die MIOP@KnotenBs in der aktiven Gruppe (Schritt 3410). Die MIOP-KnotenBs leiten die Downlink-Signalisierungsdaten an ihre entsprechenden KnotenBs weiter (Schritt 3420). Die KnotenBs leiten dann die Downlink-Signalisierungsdaten an das Benutzergerät weiter (Schritt 3430). Das Benutzergerät kombiniert dann die Datenpakete wieder aus den KnotenBs der aktiven Gruppe (Schritt 3440), und das Verfahren 3400 ist abgeschlossen.
  • Unter erneuter Bezugnahme auf 17 wurde oben erläutert, dass die RNC-Kanalhandler 1760 in der MIOP@KnotenB 210 und 1780 in der MIOP@RNC 220 den Datenverkehr zur und von der RNC 140 im Zusammenhang mit einer abgezweigten Teilnehmersitzung überwachen und nach Bedarf Datenverkehr zur Aufrechterhaltung von Kanälen einfügen, um die RNC 140 daran zu hindern, die Teilnehmersitzung von einem schnellen Kanal auf einen langsamen Kanal umzuschalten. Bei Makrodiversität an der Peripherie würde es jedoch unnötigen Transportaufwand im Kernnetz verursachen, wenn alle MIOP@KnotenBs in einer aktiven Gruppe Datenverkehr zur Aufrechterhaltung von Kanälen einfügen würden. Das Verfahren 3500 in 35 verhindert dieses Problem. Das Verfahren 3500 beginnt, wenn Peripherie-Makrodiversität aktiv ist (Schritt 3510). Die Master-MIOP@KnotenB sendet Datenverkehr zur Aufrechterhaltung von Kanälen an die RNC (Schritt 3520), aber die Slave-MIOP@KnotenBs nicht (Schritt 3530). Die Logik zur Aufrechterhaltung von Kanälen innerhalb des IuB-DOGW 1710 berücksichtigt daher, ob Makrodiversität aktiv ist und ob es sich bei der MIOP@KnotenB um einen Master oder einen Slave handelt. Dies verhindert, dass übermäßiger Datenverkehr zur Aufrechterhaltung von Kanälen durch alle KnotenBs in einer aktiven Gruppe eingefügt wird.
  • 36 ist ein Blockschaltbild zur Veranschaulichung eines Mobilfunk-Datenaustauschsystems 3600, das wie hier beansprucht Verlaufsdaten, Umgebungsbedingungen, Wetterwarnungen und Wettervorhersagen verwendet, um Vorbeugungsmaßnahmen gegen eine Störung zu ergreifen. Das Mobilfunk-Datenaustauschsystem 3600 weist mehrere Türme 120A bis 120C und deren zugehörige Basisstationen 222A bis 222C auf. Die Türme 120A bis 120C und Basisstationen 222A bis 222C tauschen wie oben beschrieben Daten mit dem Benutzergerät 110 aus. Jede der Basisstationen 222A bis 222C weist örtliche Umgebungsbedingungen 3610A bis 3610C auf.
  • 37 ist ein Blockschaltbild zur Darstellung einer der drei in 36 gezeigten Basisstationen 222. Die Basisstation 222 weist ein Breakout-System auf, das in dem veranschaulichten Beispiel als „MIOP@KnotenB 210” bezeichnet ist (1). Des Weiteren weist die MIOP@KnotenB 210 einen Störungsvorhersagemechanismus 3710 auf, der Verlaufsdaten 3712, Umgebungsbedingungen (die nachfolgend eingehender beschrieben werden), Wettervorhersagen 3414 und Wetterwarnungen 3716 verwendet, um Vorbeugungsmaßnahmen gegen eine Störung zu ergreifen. Die Verlaufsdaten 3712 werden analysiert, um Verlaufsdatenmuster 3717 zu ermitteln, die ebenfalls gespeichert werden, um Störungen vorherzusagen. Die MIOP@KnotenB 210 weist darüber hinaus einen Verlagerungsmechanismus 3718 auf, um Auslastung auf andere Basisstationen zu verlagern, wie nachfolgend beschrieben wird. Die Basisstation 222 weist vorzugsweise Umgebungssensoren 3720 auf, die Sensoren aufweisen, um örtliche Umgebungsbedingungen 3610 außerhalb der Basisstation 222 und interne Umgebungsbedingungen 3722 innerhalb der Basisstation und/oder innerhalb der MIOP@KnotenB 210 zu überwachen. Die Umgebungssensoren 3720 können Teil der MIOP@KnotenB 210 sein oder sich innerhalb anderer Ausrüstungen in der Basisstation 222 befinden. Die Umgebungssensoren können sich auch an anderen Orten befinden und die Daten an die MIOP@KnotenB gesendet werden. Beispielsweise können sich die Sensoren an oder nahe den Basisstationen oder an einer nahegelegenen Wetterstation (nicht gezeigt) befinden. Die Umgebungssensoren können Sensoren für Temperatur, Feuchte, Windgeschwindigkeit, Luftdruck usw. aufweisen. Die Basisstation 222 kann ferner Umgebungssteuerungssysteme 3724 und Umgebungssysteme 3726 aufweisen. Die Umgebungssteuerungssysteme 3724 ermöglichen dem Störungsvorhersagemechanismus 3710, beliebige Umgebungssysteme 3726 in der Basisstation wie beispielsweise Gebläse, Entfeuchter, Kühlanlagen usw. zu steuern.
  • Unter erneuter Bezugnahme auf 37 erzeugt und verwaltet der Störungsvorhersagemechanismus 3710 die Verlaufsdaten 3712, die in Verbindung mit der örtlichen Wettervorhersage 3714, den Wetterwarnungen 3716 und den Umgebungsbedingungen 3610, 3723 zur Vorhersage möglicher Störungen verwendet werden. Der Störungsvorhersagemechanismus 3710 überwacht über die Zeit solche Bedingungen wie beispielsweise Störungsdaten, Datenlasten und Nutzungsmuster an der Basisstation, um die Verlaufsdaten 3712 zu erzeugen und zu speichern. Die örtliche Wettervorhersage 3714 wird vorzugsweise durch den Störungsvorhersagemechanismus 3710 über Verbindungen der MIOP@KnotenB 210 mit dem Internet empfangen, um eine örtliche Wettervorhersage für das Gebiet zu erhalten, in dem sich die Basisstation befindet. Die von einem entfernten Ort erhaltene örtliche Wettervorhersage könnte in Verbindung mit den örtlichen Umgebungsbedingungen 3610 verwendet werden, die durch die Umgebungssensoren 3720 erfasst wurden. Die Wetterwarnungen 3716 können andere Wetterinformationen sein, die durch den Störungsvorhersagemechanismus bereitgestellt oder erhalten werden. Die Wetterwarnungen 3716 können von anderen Basisstationen oder von vorgelagerten Einrichtungen im Netz wie beispielsweise der RNC empfangen werden. Bei den Wetterwarnungen 3716 könnte es sich beispielsweise um die Warnung vor einem Wirbelsturm, vor einem Feuer oder um eine andere Unwetterwarnung von der RNC oder von einer nahegelegenen Basisstation handeln.
  • 38A ist eine Tabelle mit Verlaufsdaten zur Veranschaulichung eines einfachen Beispiels von Verlaufsdaten, die durch den Störungsvorhersagemechanismus erfasst wurden und verwendet werden, um Vorbeugungsmaßnahmen gegen eine vorhergesagte Störung zu ergreifen. Bei diesem Beispiel in 38A bestehen die Verlaufsdaten aus den Störungsverlaufsdaten 3712A. Der Störungsvorhersagemechanismus überwacht und erfasst Verlaufsdaten, speichert die Verlaufsdaten an einem geeigneten Speicherort wie beispielsweise der MIOP@KnotenB, führt Trendanalysen an den Verlaufsdaten durch und speichert Verlaufsdatenmuster 3717. Diese Schritte werden in 40 ausführlicher beschrieben. Zu den Störungsverlaufsdaten 3712 können das Datum 3810 und die Uhrzeit 3812 der Störung, die Last 3814, Außentemperatur 3816, Feuchte 3818, der Störungszustand 3820, die Windgeschwindigkeit 3822 und die Störungsart 3824 gehören. Die Last 3814 kann wie gezeigt als Faktor oder Prozentwert einer maximalen Last angegeben sein. Bei diesem Beispiel ist in jeder Zeile eine Störung aufgeführt. Der Störungsvorhersagemechanismus könnte an diesen Daten eine Trendanalyse durchführen, um zu ermitteln, wann eine hohe Wahrscheinlichkeit einer Störung besteht. Bei einem ersten Beispiel könnte der Störungsvorhersagemechanismus eine Trendanalyse an den ersten vier Datenzeilen in 38A durchführen, um festzustellen, dass bei Frost von –30°F und darunter und einer Feuchte von 12% und darunter eine hohe Wahrscheinlichkeit einer Störung besteht. Der Störungsvorhersagemechanismus würde dann wie in 39 gezeigt einen ersten Trend 3910 in den Verlaufsdatenmustern speichern. Bei einem zweiten Beispiel könnte der Störungsvorhersagemechanismus eine Trendanalyse durchführen und an den ersten drei Datenzeilen in 38A feststellen, dass bei warmen und feuchten Bedingungen mit einer Temperatur von 97°F und darüber und einer Feuchte von 90% und darüber eine hohe Wahrscheinlichkeit einer wärmebedingten Störung besteht. Der Störungsvorhersagemechanismus würde dann wie in 39 gezeigt einen zweiten Trend 3912 in den Verlaufsdatenmustern 3717 speichern.
  • 38B ist eine Tabelle mit Verlaufsdaten zur Veranschaulichung eines weiteren Beispiels von Verlaufsdaten, die durch den Störungsvorhersagemechanismus erfasst wurden, um zum Ergreifen von Vorbeugungsmaßnahmen gegen eine vorhergesagte Störung verwendet zu werden. 38B zeigt Beispiele von Lastverlaufsdaten 3712B. Bei diesem Beispiel überwacht und speichert der Störungsvorhersagemechanismus wie gezeigt die Daten unabhängig davon, ob eine Störung besteht. Der Störungsvorhersagemechanismus kann dann die Lastverlaufsdaten analysieren und die Beziehung zwischen Temperaturen und Auslastung ermitteln, um eine vorhergesagte Störung zu ermitteln. Zum Beispiel könnten die Daten in 38B verwendet werden, um Zeiträume eines hohen Bedarfs zu ermitteln. Zum Beispiel könnte die durch den Störungsvorhersagemechanismus durchgeführte Analyse der in den letzten zwei Zeilen der 38B gezeigten Daten feststellen, dass an Sonntagnachmittagen um 15:00 Uhr üblicherweise eine Last von 100% auftritt. In diesem Verlaufsdatenmuster 3717 könnte ein Musterdatensatz 3916 gespeichert werden, der diese übliche Datenlast von 100% anzeigt. Außerdem kann der Störungsvorhersagemechanismus anhand der Lastverlaufsdaten in 38B (zweite Zeile) feststellen, dass die Außentemperatur von über 98°F und die Auslastung von 100% zu Innentemperaturen führen, von denen anhand der Störungsverlaufsdaten in 38A bekannt ist, dass sie eine Störung verursachen. Der Störungsvorhersagemechanismus würde dann wie in 39 gezeigt ein Verlaufsdatenmuster 3914 erzeugen. Diese Verlaufsdatenmuster 3914 und 3916 könnten wie folgt verwendet werden. Wenn sich die aktuellen Bedingungen dem Wert von 98°F nähern oder wenn in der Wettervorhersage eine hohe Temperatur von 98°F und darüber vorhergesagt wird und die Datenlast 100% beträgt oder auf der Grundlage eines Verlaufsmusters (3916) ein Wert von 100% vorhergesagt wird, ergreift der Störungsvorhersagemechanismus eine Vorbeugungsmaßnahme, um eine vorhergesagte Störung zu verhindern.
  • 38C ist eine Tabelle mit Verlaufsdatenmustern, die vom Störungsvorhersagemechanismus erfasst wurden. 38C zeigt Beispiele von Nutzungsverlaufsdaten 3712C, die im Zusammenhang mit der Kundenutzung der durch die MIOP@KnotenB bereitgestellten Datendienste stehen. Der Störungsvorhersagemechanismus überwacht und erfasst Nutzungsverlaufsdaten, um die Vorbeugungsmaßnahmen in Erwartung einer vorhergesagten Störung zu ermitteln. Zu den Nutzungsverlaufsdaten können eine Kundenkennung oder Kundennummer 3830, der Datentyp 3832, die Datenübertragungsgeschwindigkeit 3834, das Datum 3810 und die Uhrzeit 3812 gehören. Bei der Datenübertragungsgeschwindigkeit 3834 könnte es sich um einen Höchst- oder Spitzenwert der Datenübertragungsgeschwindigkeit während einer vorgegebenen Zeitdauer handeln. Die Nutzungsverlaufsdaten 3712C können verwendet werden, um die Priorität von Kunden zu ermitteln und die Auslastung auf der MIOP@KnotenB zu verringern. Zum Beispiel kann eine Vorbeugungsmaßnahme, die bei einer vorhergesagten Störung ergriffen wurde, darin bestehen, dass die Systemauslastung verringert wird, um die Temperatur der Ausrüstung der MIOP@KnotenB zu senken, wenn sich die Ausrüstung einer anhand der Verlaufsdatenmuster 3717 kritischen Temperatur nähert. Um die Systemauslastung zu verringern, kann der Störungsvorhersagemechanismus bestimmten Arten von Kunden oder bestimmten Datentypen Priorität verleihen oder diese Kunden oder Datentypen abwehren. Die erfassten Nutzungsmuster könnten Kundenkennungen und die Datennutzung der Kunden nach Datenübertragungsgeschwindigkeit und/oder Datentyp enthalten. Wenn der Störungsvorhersagemechanismus eine Vorbeugungsmaßnahme ergreift, um eine Störung abzuwehren, kann er unter Umständen die Auslastung auf eine benachbarte Arbeitsstation verlagern, wobei der Störungsvorhersagemechanismus in diesem Fall die Auslastung auf der MIOP@KnotenB verringern könnte, indem er einige Kunden auswählt, die nicht abgezweigt werden und daher eine verringerte Dienstqualität hinnehmen müssen, im Gegenzug aber eine Störung verhindert wird. Bei diesem Beispiel könnte der Störungsvorhersagemechanismus Kunden wie beispielsweise dem Kunden 2 3842 und dem Kunden 3 3844, die weniger Daten nutzen, eine höhere Priorität verleihen, indem er Abzweigungsdienste für diese Kunden fortsetzt. Im Gegensatz hierzu würde Kunden wie beispielsweise dem Kunden 1 3840, die höhere Datenübertragungsgeschwindigkeiten nutzen, eine niedrigere Priorität verliehen, und diese Kunden werden unter Umständen nicht abgezweigt. Alternativ kann Kunden Priorität verliehen werden, die bestimmte Datentypen nutzen, um eine Kernfunktion aufrechtzuerhalten. Das Datumsfeld 3810 und das Uhrzeitfeld 38212 stellen weitere Informationen bereit, die die MIOP@KnotenB in die Lage versetzen, intelligente Entscheidungen darüber zu treffen, welche Aspekte der MIOP@KnotenB abzuschalten oder zu verlagern sind, um die Auslastung zu verringern.
  • 39 ist eine Tabelle mit Verlaufsdatenmustern 3717, die vom Störungsvorhersagemechanismus angelegt wurde, um zum Ergreifen von Vorbeugungsmaßnahmen gegen eine vorhergesagte Störung verwendet zu werden. Bei den Verlaufsdatenmustern 3717 handelt es sich um Muster von Verlaufsdaten, die vom Störungsvorhersagemechanismus erfasst wurden und eine Störung des Systems der MIOP@KnotenB oder wichtige Daten im Zusammenhang mit einer eventuellen Störung betreffen. Die Verlaufsdatenmuster 3717 können eine Trendbezeichnung 3920, eine Last 3922, eine Bedingung 3924 und bestimmte gemessene Bedingungen wie zum Beispiel Temperatur 3926 oder Feuchte 3928 aufweisen. Die Verlaufsdatenmuster 3717 können darüber hinaus die Art der Störung 3930 und einen typischen Zeitraum 3932 aufweisen. Die Verlaufsdatenmuster 3910 und 3912 wurden durch den Störungsvorhersagemechanismus wie oben beschrieben aus den Daten in 38A ermittelt. Die Verlaufsdatenmuster 3914 und 3616 wurden durch den Störungsvorhersagemechanismus wie oben beschrieben aus den Daten in 38B ermittelt.
  • Wie hier beschrieben verwendet der Störungsvorhersagemechanismus Verlaufsdaten 3712, Verlaufsdatenmuster 3717, Umgebungsbedingungen von den Umgebungssensoren 3720, Wetterwarnungen 3716 und Wettervorhersagen 3714, um Vorbeugungsmaßnahmen gegen eine Störung zu ergreifen. Die Vorbeugungsmaßnahme kann mehrere unterschiedliche Formen annehmen. Der Störungsvorhersagemechanismus könnte Umgebungssteuerungssysteme der Basisstation oder der MIOP@KnotenB verwenden, um eine Störung durch solche Maßnahmen wie zum Beispiel Erhöhen von Gebläsedrehzahlen oder Erhöhen oder Einschalten anderer, oben eingeführter Umgebungssteuerungssysteme 3726 (37) zu verhindern.
  • Hierzu könnte beispielsweise in Vorbereitung auf einen unnormal heißen Tag das Kühlen des Innenraums außerhalb normaler Bereiche gehören. Wenn zum Beispiel laut örtlichem Wetterbericht die Höchsttemperaturen über 100°F betragen werden und diese MIOP@KnotenB-Einheit in der Vergangenheit bei Temperaturen über 100°F Temperaturgrenzwerte erreicht hat, ist es wahrscheinlich, dass bei der MIOP@KnotenB-Anwendung eine weitere ähnliche Störung auftritt. Daher könnte die Vorbeugungsmaßnahme darin bestehen, in Vorbereitung auf den heißen Tag eine Kühlanlage zu betreiben. Die Vorbeugungsmaßnahme könnte auch darin bestehen, das System abzuschalten. Wenn zum Beispiel die Kühlleistung nicht ausreicht, kann die Vorbeugungsmaßnahme darin bestehen, die Abzweigung aller BGs am System der MIOP@KnotenB allmählich zu beenden und dann die MIOP@KnotenB abzuschalten, um Betriebsstörungen bei Benutzern oder eine dauerhafte Beschädigung der MIOP@KnotenB zu verhindern.
  • Alternativ könnte die Vorbeugungsmaßnahme des Störungsvorhersagemechanismus unter anderem darin bestehen, die Auslastung mithilfe des oben unter Bezugnahme auf 37 eingeführten Verlagerungsmechanismus zu verlagern. Der Verlagerungsmechanismus 3718 ermöglicht der MIOP@KnotenB, Auslastung auf andere MIOP@KnotenBs in derselben Basisstation, in anderen Basisstationen oder auf ein vorgelagertes System oder eine vorgelagerte Ausrüstung im Mobilfunkdatennetz zu verlagern. Der Verlagerungsmechanismus kann den Diversitätsmechanismus und andere, nach dem Stand der Technik bekannte Datenaustauschmittel sowie diejenigen aufweisen, die hier zum Zweck des Datenaustauschs zwischen Basisstationen und vorgelagerten Systemen wie beispielsweise der RNC beschrieben sind. Der Verlagerungsmechanismus ermöglicht dem Störungsvorhersagemechanismus, als Vorbeugungsmaßnahme Auslastung zu verlagern. Beispielsweise könnte der Störungsvorhersagemechanismus über das Überlagerungsnetz Daten mit der Basisstation des Turms einer benachbarten Zelle austauschen, um Auslastung auf andere Basisstationen in der aktiven Gruppe zu verlagern, wie oben im Zusammenhang mit der Makrodiversität beschrieben. Bei einem weiteren Beispiel könnte der Störungsvorhersagemechanismus Auslastung tiefer in das Mobilfunkdatennetz verlagern. Dies könnte zur Folge haben, dass die RNC oder der Kern wieder zusätzliche Kapazität zurückerhalten, um zusätzliche Auslastung zu verarbeiten. Obwohl die Aufwärtsverlagerung von Auslastung im Netz aus der Sicht des Benutzers zu etwas verschlechterten Geschwindigkeiten führen kann, ist eine langsamere Geschwindigkeit einem nicht verfügbaren Dienst als Folge eines plötzlichen Störungszustands vorzuziehen.
  • Es gibt andere Szenarien, in denen der Störungsvorhersagemechanismus Auslastung auf andere MIOP@KnotenBs verlagern könnte. Wenn zum Beispiel ein MIOP@KnotenB eine Wetterwarnung über einen in der Nähe befindlichen Wirbelsturm empfängt, könnte Auslastung auf MIOP@KnotenBs verlagert werden, die sich nicht in der vorhergesagten Zugbahn des Wirbelsturms befinden. Der Störungsvorhersagemechanismus kann eine Warnung über einen Wirbelsturm von einer nahegelegenen Basisstation, von der RNC, einer Wetterstation oder aus einer Wettervorhersage erhalten.
  • Der Störungsvorhersagemechanismus könnte auch zur Wartung der MIOP@KnotenB und anderer Ausrüstungen der Basisstation beitragen, um Störungen vorbeugend zu verhindern. Da die RNC Zugriff auf die Daten von möglicherweise hunderten oder tausenden von KnotenBs hat, könnte sie beispielsweise feststellen, dass es ein Muster von Störungen gibt, die für ein bestimmtes geographisches Gebiet charakteristisch sind. In einem Gebiet mit hoher Feuchte kann zum Beispiel auf die Störung an einer Stromversorgung die Störung an einer anderen Stromversorgung folgen, und Techniker könnten die wahrscheinlich ausfallende andere Hardware vorausschauend ersetzen. Unter Verwendung der durch den Störungsvorhersagemechanismus erfassten Daten könnte eine Vorbeugungsmaßnahme darin bestehen, verdächtige Komponenten vor einem jahreszeitlich bedingten Austausch oder aufgrund einer Wettervorhersage zu ersetzen.
  • 40 ist ein Ablaufplan eines Verfahrens 4000 zum Erzeugen von Verlaufsdaten zum Vorhersagen von Störungen (3712 in 37). Die Schritte des Verfahrens 4000 werden vorzugsweise durch den Störungsvorhersagemechanismus 3710 ausgeführt. Das Verfahren 4000 beginnt mit dem Überwachen von Daten an der Basisstation über einen längeren Zeitraum (Schritt 4010). Als Nächstes werden geeignete Verlaufsdaten zum Vorhersagen von Störungen erfasst (Schritt 4020). Zu den Verlaufsdaten können Störungsverlaufsdaten, Lastverlaufsdaten und Nutzungsverlaufsdaten gehören. Dann werden die Verlaufsdaten in der MIOP@KnotenB gespeichert (Schritt 4030). Als Nächstes werden Trendanalysen an den erfassten Verlaufsdaten über die Zeit und/oder regelmäßig durchgeführt (Schritt 4040), um Verlaufsdatenmuster zu ermitteln. Dann werden die Verlaufsdatenmuster in der MIOP@KnotenB gespeichert (Schritt 4050). Das Verfahren ist dann abgeschlossen.
  • 41 ist ein Ablaufplan eines Verfahrens 4100 zum Abmildern der Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes. Die Schritte des Verfahrens 4100 werden vorzugsweise durch den Störungsvorhersagemechanismus 3710 ausgeführt. Zunächst wird eine Wettervorhersage für das Gebiet der Basisstation erhalten, die den Störungsvorhersagemechanismus enthält (Schritt 4110). Als Nächstes wird eine Wetterwarnung erhalten, sofern verfügbar (Schritt 4120). Dann werden aktuelle Umgebungsbedingungen einschließlich der Bedingungen im Inneren der Basisstation und/oder der MIOP@KnotenB und örtlicher Umgebungsbedingungen der Basisstation erhalten (Schritt 4130). Anschließend werden Verlaufsdatenmuster erhalten (Schritt 4140). Als Nächstes wird unter Verwendung der in den vorhergehenden Schritten erhaltenen Daten ermittelt, ob eine vorhergesagte Störung vorliegt (Schritt 4150). Bei nicht vorhergesagter Störung (Schritt 4150 = Nein) ist das Verfahren abgeschlossen. Bei einer vorhergesagten Störung (Schritt 4150 = Ja) wird eine Vorbeugungsmaßnahme ergriffen (Schritt 4160). Die Vorbeugungsmaßnahme könnte Eines oder Mehreres des Folgenden aufweisen: Verlagern der Auslastung auf eine andere Basisstation, Verlagern von Auslastung auf ein vorgelagertes System im Mobilfunkdatennetz, Verringern der Auslastung, Aktivieren von Umgebungssteuerungssystemen in der MIOP@KnotenB und/oder Aktivieren von Umgebungssteuerungssystemen in der Basisstation. Das Verfahren ist dann abgeschlossen.
  • Fachleuten wird klar sein, dass Aspekte der vorliegenden Erfindung in Form eines Systems, Verfahrens oder Computerprogrammprodukts verkörpert sein können. Dementsprechend können Aspekte der vorliegenden Erfindung die Form einer vollständig in Hardware realisierten Ausführungsform, einer vollständig in Software realisierten Ausführungsform (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführungsform annehmen, die Software- und Hardwareaspekte kombiniert, die im vorliegenden Dokument allgemein als „Schaltung”, „Modul” oder „System” bezeichnet werden. Ferner können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien verkörpert ist, auf denen computerlesbarer Programmcode verkörpert ist.
  • Es können beliebige Kombinationen eines oder mehrerer computerlesbarer Medien verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Zu computerlesbaren Speichermedien können beispielsweise, ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches oder elektromagnetisches System bzw. ein Infrarot- oder Halbleitersystem bzw. eine derartige Vorrichtung oder Einheit oder eine beliebige geeignete Kombination des Vorstehenden gehören. Zu den genaueren Beispielen (unvollständige Liste) computerlesbarer Speichermedien zählen unter anderem folgende: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein Nur-Lese-Speicher in Form einer Compact Disc (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder eine beliebige geeignete Kombination des Vorstehenden. Im Kontext des vorliegenden Dokuments kann ein computerlesbares Speichermedium jedes beliebige vergegenständlichte Medium sein, das ein Programm enthalten oder speichern kann, das von oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung genutzt werden kann.
  • Ein computerlesbares Signalmedium kann unter anderem ein im Basisband oder als Teil einer Trägerwelle übertragenes Datensignal mit darin verkörpertem computerlesbarem Programmcode aufweisen. Ein derartiges übertragenes Signal kann eine beliebige Vielfalt von Formen annehmen, einschließlich, ohne darauf beschränkt zu sein, einer elektromagnetischen oder optischen Form oder einer beliebigen geeigneten Kombinationen davon. Ein computerlesbares Signalmedium kann ein beliebiges computerlesbares Medium sein, bei dem es sich nicht um ein computerlesbares Speichermedium handelt und das ein Programm übertragen, senden oder transportieren kann, das von oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung genutzt werden kann.
  • Auf einem computerlesbaren Medium verkörperter Programmcode kann unter Verwendung jedes beliebigen geeigneten Mediums, einschließlich, ohne darauf beschränkt zu sein, drahtloser, drahtgebundener Medien, Lichtwellenleitern, HF usw., oder unter Verwendung einer beliebigen geeigneten Kombination des Vorstehenden übertragen werden.
  • Computerprogrammcode zum Ausführen von Operationen bei Aspekten der vorliegenden Erfindung kann in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen, darunter in einer objektorientierten Programmiersprache wie Java, Smalltalk, C++ oder dergleichen und in herkömmlichen prozeduralen Programmiersprachen wie der Programmiersprache „C”, Streams Processing Language oder ähnlichen Programmiersprachen geschrieben sein. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Beim letztgenannten Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers über eine beliebige Art von Netzwerk verbunden sein, unter anderem über ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann zu einem externen Computer hergestellt werden (beispielsweise über das Internet unter Nutzung eines Internet-Dienstanbieters (Internet Service Provider)).
  • Im vorliegenden Dokument sind Aspekte der vorliegenden Erfindung unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder und Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaltbildern durch Computerprogrammanweisungen realisiert werden kann bzw. können. Diese Computerprogrammanweisungen können einem Prozessor eines Mehrzweckcomputers, eines Spezialcomputers oder anderen programmierbarer Datenverarbeitungsvorrichtungen bereitstellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, die über den Prozessor des Computers oder anderer programmierbarer Datenverarbeitungsvorrichtungen ausgeführt werden, Mittel zum Realisieren der in einem Block bzw. in den Blöcken des Ablaufplans und/oder des Blockschaltbildes angegebenen Funktionen/Aktionen schaffen.
  • Diese Computerprogrammanweisungen können ebenfalls in einem computerlesbaren Medium gespeichert sein, das einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen oder andere Einheiten anweisen kann, in einer bestimmten Weise zu funktionieren, sodass die im computerlesbaren Medium gespeicherten Anweisungen ein Erzeugnis schaffen, das die Anweisungen aufweist, die die in einem Block bzw. in den Blöcken des Ablaufplans und/oder des Blockschaltbildes angegebene Funktion/Aktion realisieren.
  • Die Computerprogrammanweisungen können auch in einen Computer, in andere programmierbare Datenverarbeitungsvorrichtungen oder in andere Einheiten geladen werden, um zu bewirken, dass auf dem Computer, auf anderen programmierbaren Vorrichtungen oder anderen Einheiten eine Reihe von Arbeitsschritten ausgeführt wird, um einen mittels Computer realisierten Prozess zu schaffen, sodass die Anweisungen, die auf dem Computer oder auf anderen programmierbaren Vorrichtungen ausgeführt werden, Prozesse zur Realisierung der in einem Block bzw. in den Blöcken des Ablaufplans und/oder des Blockschaltbildes angegebenen Funktionen/Aktionen bereitstellen.
  • Die hier offenbarten Verfahren können als Teil der Bereitstellung eines webbasierten Dienstes durchgeführt werden. Ein derartiger Dienst könnte zum Beispiel aufweisen, dass das Verfahren Online-Benutzern gegen Bezahlung angeboten wird.
  • Die Offenbarung und die Ansprüche sind auf einen Störungsvorhersagemechanismus in einer Basisstationseinheit gerichtet, der die Auswirkungen von wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes abmildert. Der Störungsvorhersagemechanismus berücksichtigt Nutzungsmuster, Umgebungsbedingungen und Wettervorhersagen, um eine Vorbeugungsmaßnahme zur Abwendung eines Teil- oder Totalausfalls der Ausrüstungen der Basisstation zu ergreifen und ein robusteres Mobilfunkdatennetz bereitzustellen.
  • Fachleuten wird klar sein, dass viele Variationen im Rahmen des Schutzbereichs der Ansprüche möglich sind. Obwohl die Offenbarung oben ausführlich gezeigt und beschrieben ist, versteht es sich daher für Fachleute, dass diese und andere Änderungen an Form und Einzelheiten im Rahmen des Geltungsbereichs vorgenommen werden können, ohne vom Grundgedanken und Schutzbereich der Ansprüche abzuweichen.

Claims (7)

  1. Mobilfunkdatennetz, aufweisend: eine Mehrzahl von Basisstationen, die jeweils mit einer entsprechenden Antenne kommunizieren, die Funksignale an Benutzergeräte sendet und von diesen empfängt, wobei die Mehrzahl von Basisstationen Teil eines Funkzugangsnetzes ist, das mit einem Kernnetz im Mobilfunkdatennetz Daten austauscht; einen Störungsvorhersagemechanismus in einer Basisstation der Mehrzahl von Basisstationen, der aus Verlaufsdaten der Basisstation abgeleitete Verlaufsdatenmuster, örtliche Umgebungsbedingungen der Basisstation und einen örtlichen Wetterbericht verwendet, um eine Störung vorherzusagen; und Ergreifen einer Maßnahme zur Abmilderung der vorhergesagten Störung, bevor eine Störung eintritt, wobei die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme einen Datenaustausch mit Umgebungssystemen aufweist, um Vorbeugungsmaßnahmen zu ergreifen, wobei die Umgebungssysteme ein Umgebungssystem innerhalb der Basisstation aufweisen, das Umgebungsbedingungen innerhalb der Basisstation steuert, und ein Umgebungssystem in einem Breakout-System, das den Störungsvorhersagemechanismus aufweist, und wobei die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme ein allmähliches Beenden des Abzweigens von Daten aller Benutzergeräte und anschließend ein Abschalten des Breakout-Systems aufweist, das den Störungsvorhersagemechanismus aufweist.
  2. Mobilfunkdatennetz nach Anspruch 1, bei dem zu den örtlichen Umgebungsbedingungen unter anderem Umgebungsbedingungen außerhalb der Basisstation und innerhalb der Basisstation gehören.
  3. Mobilfunkdatennetz nach Anspruch 1, bei dem die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme ein Verlagern von Auslastung auf benachbarte Basisstationen aufweist.
  4. Mobilfunkdatennetz nach Anspruch 1, bei dem die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme ein Verlagern von Auslastung auf ein vorgelagertes System im Mobilfunkdatennetz aufweist
  5. Mobilfunkdatennetz nach Anspruch 1, bei dem die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme eine Erhöhung der Kühlleistung in dem Breakout-System aufweist, das den Störungsvorhersagemechanismus aufweist.
  6. Mobilfunkdatennetz nach Anspruch 1, bei dem die zur Abmilderung der vorhergesagten Störung ergriffene Maßnahme in Vorbereitung auf eine vorhergesagte unnormal heiße Bedingung eine Kühlung der Basisstation außerhalb des normalen Bereiches aufweist.
  7. Mobilfunkdatennetz nach Anspruch 1, bei dem die Verlaufsdaten, die zur Ableitung von Verlaufsdatenmustern verwendet werden, um die Störung vorherzusagen, aufweisen: Störungsverlaufsdaten und Lastverlaufsdaten, und/oder bei dem der Störungsvorhersagemechanismus auch Wetterwarnungen von einer nahegelegenen Basisstation verwendet, um die Störung vorherzusagen.
DE102012220932.8A 2011-11-16 2012-11-15 Abmildern von Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes Active DE102012220932B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/297,852 US9681317B2 (en) 2011-11-16 2011-11-16 Mitigating effects of predicted failures in a mobile network basestation due to weather
US13/297,852 2011-11-16

Publications (2)

Publication Number Publication Date
DE102012220932A1 DE102012220932A1 (de) 2013-05-16
DE102012220932B4 true DE102012220932B4 (de) 2016-03-31

Family

ID=47358598

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012220932.8A Active DE102012220932B4 (de) 2011-11-16 2012-11-15 Abmildern von Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes

Country Status (3)

Country Link
US (2) US9681317B2 (de)
DE (1) DE102012220932B4 (de)
GB (1) GB2496731B (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101310377B1 (ko) * 2008-10-17 2013-09-23 엘지디스플레이 주식회사 영상표시장치
US9692644B2 (en) * 2013-06-18 2017-06-27 Cisco Technology, Inc. Dynamically adjusting network parameters using weather forecasts
US20140029439A1 (en) * 2012-07-24 2014-01-30 At&T Intellectual Property I, L.P. Long term evolution traffic management and event planning
EP3058691A1 (de) * 2013-10-18 2016-08-24 Telefonaktiebolaget LM Ericsson (publ) Klassifizierung von detektierten netzanomalien mithilfe zusätzlicher daten
CA2870080C (en) * 2013-11-08 2017-12-19 Accenture Global Services Limited Network node failure predictive system
US10623258B2 (en) 2015-06-22 2020-04-14 Arista Networks, Inc. Data analytics on internal state
EP3156868A1 (de) * 2015-10-15 2017-04-19 Siemens Aktiengesellschaft Wartungssystem und verfahren zur analyse von funktionsfehlern eines systems
US10819591B2 (en) 2017-05-30 2020-10-27 At&T Intellectual Property I, L.P. Optical transport network design system
US10868471B2 (en) 2018-02-23 2020-12-15 T-Mobile Usa, Inc. Adaptive voltage modification (AVM) controller for mitigating power interruptions at radio frequency (RF) antennas
US11102665B2 (en) 2018-02-23 2021-08-24 T-Mobile Usa, Inc. Supplemental voltage controller for radio frequency (RF) antennas
US10470120B2 (en) * 2018-03-14 2019-11-05 T-Mobile Usa, Inc. Power compensator for cellular communication base station
KR102424694B1 (ko) * 2018-12-26 2022-07-25 삼성전자주식회사 무선 통신 시스템에서 네트워크 장치의 성능을 모니터링 하기 위한 장치 및 방법
US20230291691A1 (en) * 2022-03-09 2023-09-14 International Business Machines Corporation Managing computer network traffic based on weather conditions
CN117528589B (zh) * 2023-12-29 2024-03-22 江西师范大学 一种基于边缘计算的移动感知层次缓存容错方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999046921A2 (en) * 1998-03-09 1999-09-16 Nokia Mobile Phones Limited A system for performing environmental measurements and for transferring measurement results
KR20020012358A (ko) * 2000-08-07 2002-02-16 이계철 무인 국사의 냉방부 제어 방법
DE69934177T2 (de) * 1998-09-16 2007-10-18 Alcatel Canada Inc., Kanata Leistungsregelung von LMDS/LMCS Basisstationen zur Regensfadingskompensation
US20100228861A1 (en) * 2009-03-04 2010-09-09 International Business Machines Corporation Environmental and computing cost reduction with improved reliability in workload assignment to distributed computing nodes
WO2010130270A1 (en) * 2009-05-11 2010-11-18 Nokia Siemens Networks Oy Local breakout and ip address selection
WO2011034476A1 (en) * 2009-09-21 2011-03-24 Telefonaktiebolaget L M Ericsson (Publ) A method and a radio base station for handling of data traffic
US8037749B2 (en) * 2007-08-16 2011-10-18 Nec Corporation Network monitoring method, network monitoring apparatus, line failure prevention system and computer program of network monitoring apparatus

Family Cites Families (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2128553C (en) * 1994-07-21 2000-04-04 Northern Telecom Limited Wireless base station
CA2128554C (en) * 1994-07-21 2002-04-30 Kevin L. Dalgleish Wireless base station
US6058260A (en) 1995-06-12 2000-05-02 The United States Of America As Represented By The Secretary Of The Army Methods and apparatus for planning and managing a communications network
US7590083B2 (en) * 1995-12-07 2009-09-15 Transcore Link Logistics Corp. Wireless packet data distributed communications system
US5709100A (en) * 1996-08-29 1998-01-20 Liebert Corporation Air conditioning for communications stations
US6300871B1 (en) * 1997-11-12 2001-10-09 Headwaters Research & Development, Inc. Multi-station RF thermometer and alarm system
US6169881B1 (en) * 1998-05-04 2001-01-02 Motorola, Inc. Method and apparatus for predicting impending service outages for ground-to-satellite terminal in a satellite communication system
US6380869B1 (en) * 1999-05-19 2002-04-30 Potomac Aviation Technology Corporation Automated air-traffic advisory system and method
US6353902B1 (en) 1999-06-08 2002-03-05 Nortel Networks Limited Network fault prediction and proactive maintenance system
US6519461B1 (en) 1999-10-29 2003-02-11 Telefonaktiebolaget Lm Ericsson (Publ) Channel-type switching from a common channel to a dedicated channel based on common channel load
AU1633902A (en) * 2000-12-15 2002-06-24 Daniel Rosenfeld Location-based weather nowcast system and method
WO2002054654A2 (en) 2001-01-08 2002-07-11 Vextec Corporation Method and apparatus for predicting failure in a system
KR100439674B1 (ko) 2001-09-27 2004-07-12 (주) 엘지텔레콤 신경망을 이용한 기지국 장애예측 장치 및 그 방법
US6574082B2 (en) * 2001-10-09 2003-06-03 Ericsson Inc. Methods and systems for operating temperature controls for electronic equipment
WO2003090433A1 (en) 2002-04-15 2003-10-30 Spatial Wireless, Inc. Method and system for providing authentication of a mobile terminal in a hybrid network for data and voice services
EP1361771A1 (de) 2002-05-06 2003-11-12 Siemens Aktiengesellschaft Verfahren und Funkkommunikationssystem zur Übertragung von Nutzinformationen als Dienst an mehrere Teilnehmerstationen
US7483408B2 (en) 2002-06-26 2009-01-27 Nortel Networks Limited Soft handoff method for uplink wireless communications
JP2004235695A (ja) 2003-01-28 2004-08-19 Evolium Sas Ｃｄｍａ方式移動体無線システムのチャネル切り替え方法、及びｃｄｍａ方式移動体無線システムの基地局
US8009556B2 (en) * 2003-10-17 2011-08-30 Ip Infusion, Inc. System and method for providing redundant routing capabilities for a network node
JP4408224B2 (ja) * 2004-01-29 2010-02-03 富士通株式会社 放熱機能を有する筐体
JP4516358B2 (ja) 2004-05-26 2010-08-04 富士通株式会社 無線基地局装置および無線通信方法
US7499437B2 (en) 2004-09-13 2009-03-03 Alcatel-Lucent Usa Inc. Wireless communications system employing a network active set formed from base stations operable as primary and secondary agents
US7916649B2 (en) 2004-09-30 2011-03-29 Alcatel-Lucent Usa Inc. Apparatus and method for monitoring and analysis of communication over a wireless network
US8115145B2 (en) * 2004-11-29 2012-02-14 Sanmina-Sci Corporation Systems and methods for base station enclosures
AU2006255441A1 (en) 2005-06-06 2006-12-14 Mobidia, Inc. System and method of scheduling delivery of packets
US7970574B2 (en) * 2005-06-22 2011-06-28 The Board Of Trustees Of The Leland Stanford Jr. University Scalable sensor localization for wireless sensor networks
US8457137B2 (en) 2005-10-24 2013-06-04 Mark A. Spencer Branch exchange methods and apparatuses for switching telecommunication signals
US7715307B2 (en) * 2005-12-13 2010-05-11 Alcatel Lucent Communication connection control systems and methods
US20070147233A1 (en) * 2005-12-23 2007-06-28 Tolga Asveren Graceful failover mechanism for SSCOP service access point for SS7 links
US8929360B2 (en) 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
EP2090023B1 (de) * 2006-12-07 2010-06-23 Telefonaktiebolaget LM Ericsson (PUBL) Anordnung und Verfahren zur Netzwerkverwaltung
GB0707387D0 (en) 2007-04-17 2007-05-23 Lucent Technologies Inc Single radio VCC:LTE-VMSC anchor solution
FI20075297A0 (fi) 2007-04-27 2007-04-27 Nokia Siemens Networks Oy Menetelmä, radiojärjestelmä ja tukiasema
US7724707B2 (en) 2007-06-26 2010-05-25 Motorola, Inc. Network for a cellular communication system and a method of operation therefor
US20090049152A1 (en) 2007-08-16 2009-02-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and Apparatus for Collecting Performance Management Data in Communication Networks
FI20075631A0 (fi) 2007-09-10 2007-09-10 Nokia Siemens Networks Oy Menetelmä, radiojärjestelmä ja tukiasema
KR101502887B1 (ko) * 2007-09-22 2015-03-16 주식회사 케이엠더블유 이동통신 기지국 안테나를 이용한 영상 정보 제공 시스템및 방법
US8160752B2 (en) * 2008-09-30 2012-04-17 Zome Networks, Inc. Managing energy usage
US20090141623A1 (en) 2007-11-27 2009-06-04 Hyun Jung Central Antenna Management System With Centralized Database
US20090149200A1 (en) 2007-12-10 2009-06-11 Symbol Technologies, Inc. System and method for device or system location optimization
EP2086186A1 (de) 2008-02-01 2009-08-05 Alcatel Lucent Verkehrssteuerungsvorrichtung, paketbasiertes Netzwerk und Verfahren zur Verkehrskontrolle in einem paketbasierten Netzwerk
US8824305B2 (en) * 2008-07-09 2014-09-02 Qualcomm Incorporated Paging schemes for local network access
CN102171664B (zh) 2008-08-06 2014-12-03 莫维克网络公司 无线电接入网(ran)中的内容高速缓存
US8855138B2 (en) 2008-08-25 2014-10-07 Qualcomm Incorporated Relay architecture framework
US9204313B2 (en) 2008-11-17 2015-12-01 Telefonaktiebolaget L M Ericsson (Publ) Method and node for enabling central processing of local information
US8817699B2 (en) 2008-11-21 2014-08-26 At&T Intellectual Property I, L.P. Service continuity during local breakout in a femtocell
US8385220B2 (en) * 2009-02-24 2013-02-26 Eden Rock Communications, Llc Systems and methods for determining time varying radio frequency isolation characteristics between network cells
US8412272B2 (en) * 2009-07-24 2013-04-02 T-Mobile Usa, Inc. Rectifier circuit management system, such as for use in cell site power systems
JP2013502121A (ja) 2009-08-13 2013-01-17 エヌイーシー ヨーロッパ リミテッド （ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステムおよび方法
US9544913B2 (en) 2009-08-24 2017-01-10 Fraunhofer Gesellschaft Zur Forderung Der Angewandten Forschung E.V. Controlling scheduling decisions in a distributed cooperation system
GB0916239D0 (en) 2009-09-16 2009-10-28 Vodafone Plc Internet breakout in HNB/Femto, UMTS and LTE networks
US8831014B2 (en) 2009-09-26 2014-09-09 Cisco Technology, Inc. Providing services at a communication network edge
US20110090042A1 (en) * 2009-10-21 2011-04-21 Leviton Manufacturing Co., Inc. Wireless demand response system
WO2011053039A2 (en) 2009-11-02 2011-05-05 Lg Electronics Inc. Correlation id for local ip access
US10027711B2 (en) * 2009-11-20 2018-07-17 Alert Enterprise, Inc. Situational intelligence
US10019677B2 (en) * 2009-11-20 2018-07-10 Alert Enterprise, Inc. Active policy enforcement
WO2011063269A1 (en) * 2009-11-20 2011-05-26 Alert Enterprise, Inc. Method and apparatus for risk visualization and remediation
KR20140068261A (ko) 2009-12-04 2014-06-05 인터디지탈 패튼 홀딩스, 인크 하이브리드 네트워크에서 통합 게이트웨이에 대한 확장형 로컬 ｉｐ 액세스
US8792495B1 (en) 2009-12-19 2014-07-29 Cisco Technology, Inc. System and method for managing out of order packets in a network environment
WO2011101131A1 (en) 2010-02-17 2011-08-25 Nec Europe Ltd. A method for operating a mobile network for charging traffic and corresponding mobile network
US8862178B2 (en) * 2010-02-24 2014-10-14 Qualcomm Incorporated Methods and systems for managing participation in multiple wireless networks
US8520615B2 (en) 2010-03-26 2013-08-27 Juniper Networks, Inc. Breakout gateway for mobile data traffic
US8432871B1 (en) 2010-03-26 2013-04-30 Juniper Networks, Inc. Offloading mobile traffic from a mobile core network
EP2403186B1 (de) * 2010-07-02 2017-12-27 Vodafone IP Licensing limited Telekommunikationsnetzwerke
US8787303B2 (en) 2010-10-05 2014-07-22 Cisco Technology, Inc. Methods and apparatus for data traffic offloading at a router
US8743690B1 (en) 2011-06-14 2014-06-03 Cisco Technology, Inc. Selective packet sequence acceleration in a network environment
US8792353B1 (en) 2011-06-14 2014-07-29 Cisco Technology, Inc. Preserving sequencing during selective packet acceleration in a network environment
EP3703418A3 (de) 2011-06-24 2020-11-18 Vodafone IP Licensing limited Telekommunikationsnetzwerke
US8717887B2 (en) 2011-08-08 2014-05-06 Telefonaktiebolaget Lm Ericsson (Publ) Scrambling code planning device and method for using same in wireless communication network
US8493898B2 (en) * 2011-09-15 2013-07-23 International Business Machines Corporation Macro diversity in a mobile data network with edge breakout
US8479271B1 (en) 2011-12-20 2013-07-02 International Business Machines Corporation Hosting edge applications at the edge of a mobile data network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999046921A2 (en) * 1998-03-09 1999-09-16 Nokia Mobile Phones Limited A system for performing environmental measurements and for transferring measurement results
DE69934177T2 (de) * 1998-09-16 2007-10-18 Alcatel Canada Inc., Kanata Leistungsregelung von LMDS/LMCS Basisstationen zur Regensfadingskompensation
KR20020012358A (ko) * 2000-08-07 2002-02-16 이계철 무인 국사의 냉방부 제어 방법
US8037749B2 (en) * 2007-08-16 2011-10-18 Nec Corporation Network monitoring method, network monitoring apparatus, line failure prevention system and computer program of network monitoring apparatus
US20100228861A1 (en) * 2009-03-04 2010-09-09 International Business Machines Corporation Environmental and computing cost reduction with improved reliability in workload assignment to distributed computing nodes
WO2010130270A1 (en) * 2009-05-11 2010-11-18 Nokia Siemens Networks Oy Local breakout and ip address selection
WO2011034476A1 (en) * 2009-09-21 2011-03-24 Telefonaktiebolaget L M Ericsson (Publ) A method and a radio base station for handling of data traffic

Also Published As

Publication number Publication date
GB2496731B (en) 2014-06-11
US20130121175A1 (en) 2013-05-16
US9693241B2 (en) 2017-06-27
US9681317B2 (en) 2017-06-13
DE102012220932A1 (de) 2013-05-16
GB201219155D0 (en) 2012-12-12
GB2496731A (en) 2013-05-22
US20130122894A1 (en) 2013-05-16

Similar Documents

Publication Publication Date Title
DE102012220932B4 (de) Abmildern von Auswirkungen von vorhergesagten wetterbedingten Störungen in einer Basisstation eines Mobilfunknetzes
US10021696B2 (en) Data caching at the edge of a mobile data network
US9030944B2 (en) Aggregated appliance in a mobile data network
US9083603B2 (en) Appliance in a mobile data network that spans multiple enclosures
US8607074B2 (en) States for breakout appliance in a mobile data network
US20130121135A1 (en) Data breakout appliance at the edge of a mobile data network
US9071450B2 (en) Charging and policy for services at the edge of a mobile data network
US9042302B2 (en) Data breakout at the edge of a mobile data network
US8837318B2 (en) Mobile network services in a mobile data network
US8908553B2 (en) IP flow based offload for subscriber data optimization and scheduling at the basestation in a mobile data network
US9042379B2 (en) Network management for wireless appliances in a mobile data network
CN109728947A (zh) 一种基于云计算与网络拓扑图结合的网络性能分析方法
US8913491B2 (en) Overload detection and handling in a data breakout appliance at the edge of a mobile data network
CN101854746B (zh) 家庭基站通信链路的处理方法、处理设备及通信系统
US8837374B2 (en) Subscriber database for services at the edge of a mobile data network

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence
R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

R082 Change of representative

Representative=s name: SPIES & BEHRNDT PATENTANWAELTE PARTG MBB, DE

R020 Patent grant now final