DE112013000423T5

DE112013000423T5 - Funktionsübergreifende Virtualisierung eines Telekommunikationskernnetzes

Info

Publication number: DE112013000423T5
Application number: DE112013000423.2T
Authority: DE
Inventors: Rajendra S. Yavatkar; Christian Maciocco; Jeffrey Jackson; Daniel J. Dahle; Ashok Sunder Rajan; Richard A. Uhlig; Tsung-Yuan C. Tai
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-10-16
Filing date: 2013-10-16
Publication date: 2014-10-30
Anticipated expiration: 2033-10-17
Also published as: US20220171643A1; WO2014062796A1; CN104012066B; US9817684B2; US10558481B2; CN104012066A; US20200174811A1; US20140310707A1; DE112013000423B4; US11301275B2; US11829789B2; US20180225136A1

Abstract

In der vorliegenden Offenbarung befinden sich Funktionen im Zusammenhang mit der Zentrale eines Evolved-Packet-Core-Netzwerkes durch virtualisierte Funktionsinstanzen gemeinsam auf einer Computerplattform oder Unterkomponenten. Dies verringert und/oder eliminiert die physischen Schnittstellen zwischen Geräten und gestattet das Stattfinden des funktionalen Betriebes des Evolved-Packet-Core an einem Netzrand.

Description

Diese Anmeldung beansprucht gemäß 35 USC 119(e) Priorität gegenüber der vorläufigen US-Patentanmeldung mit der Serien-Nr. 61/714,518, eingereicht am 16. Oktober 2012, welche durch Verweis in ihrer Gesamtheit hierin eingefügt ist.
ALLGEMEINER STAND DER TECHNIK
Die derzeitige Nachfrage nach Daten in drahtlosen Netzwerken wächst signifikant. Anbieter drahtloser Netzdienste sind darum bemüht, dieser Nachfrage durch den Ausbau ihrer Funkabdeckung und Effizienz nachzukommen. Eine weniger bekannte Anstrengung der Betreiber ist der Kapazitätsausbau, der an dem Netzkern stattfinden muss, über welchen sich sämtliche Funkzugangsgeräte verbinden.
Fortschritte in der Funkzugangstechnologie machen die Spektrumsausnutzung zunehmend effizient, d. h. eine erhöhte Anzahl an Trägerkanälen für eine gegebene Bandbreite des Funkspektrums. Dies gestattet es Betreibern drahtloser Netze, ihr Netz mit einem feinen Granularitätsgrad zu skalieren, um Datenanforderungen genau zu bestimmen und sich damit zu befassen. Technologieverbesserungen am Netzkern gestatten jedoch nicht den gleichen Grad granularer Skalierbarkeit, d. h. die Kapazitätssteigerungen am Kern sind in viel größeren Schritten möglich als die, welche im Funkzugangsnetz möglich sind. Dadurch ergeben sich für die Betreiber drahtloser Netze finanziell ineffiziente Kapitalinvestitionen (CAPEX – capital expenditure) an der Netzkerninfrastruktur. Zur Verschlimmerung dieses Problems trägt bei, dass sich Fortschritte bei der Kernnetzgerätetechnologie weiterhin auf proprietären Pfaden bewegen, ohne die Vorteile aus den enormen Fortschritten zu nutzen, die bei Rechenzentrumstechnologien gemacht werden. Dies belastet die Betreiber drahtloser Netze mit Betriebsausgaben (OPEXs – operating expenditures), die zu hoch sind, als dass sie eine flexible Skalierung aus dem Netzkern, zugeschnitten auf die Anforderungen pro Marktsegment (Verkehrsarten), gestatten würden.
Bisher haben sich Ansätze auf eine Steigerung der Leistung von jedem der Geräte in der Netzkerninfrastruktur konzentriert. Meist handelte es sich dabei um eine Leistungsabstimmung der Stacks der Datenebene dieser Geräte. Während dadurch besser funktionierende Hardwareeinheiten bei nahezu gleichen Kosten bereitgestellt werden, bietet dies keine Hilfe bei der Behandlung der CAPEX/OPEX-Probleme, denen sich Betreiber drahtloser Netze bei der Skalierung ihrer Netze nach außen gegenüber sehen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Merkmale und Vorteile des beanspruchten Gegenstandes werden aus der folgenden detaillierten Beschreibung von damit konsistenten Ausführungsformen offensichtlich, wobei die Beschreibung unter Bezugnahme auf die beigefügten Zeichnungen gesehen werden sollte, wobei:
1 eine herkömmliche Telekommunikationsnetzarchitektur veranschaulicht;
2 eine skalierbare Hardwareplattform gemäß der vorliegenden Offenbarung veranschaulicht; und
3 eine Telekommunikationsnetzarchitektur gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
Obwohl die folgende detaillierte Beschreibung unter Bezugnahme auf veranschaulichende Ausführungsformen erfolgt, werden dem Fachmann auf dem Gebiet viele Alternativen, Modifikationen und Variationen davon offensichtlich sein.
DETAILLIERTE BESCHREIBUNG
In der vorliegenden Offenbarung befinden sich Funktionen im Zusammenhang mit der Zentrale eines EPC-Netzes durch virtualisierte Funktionsinstanzen gemeinsam auf einer Computerplattform oder Unterkomponenten. Dies verringert und/oder eliminiert die physischen Verflechtungen zwischen Geräten, wodurch ein Integrationslevel gestattet wird, welches Leistungsverbesserungen und Skalierbarkeit ermöglicht, die derzeit nicht erreicht werden können.
1 zeigt ein konventionelles drahtloses Telekommunikationsnetzsystem 100. Das System 100 beinhaltet im Allgemeinen ein Funkzugangsnetz (RAN – radio access network) 102 und eine Zentrale 104. Das System 100 beinhaltet mehrere Hardwaregeräte, Hardwareplattformen und damit im Zusammenhang stehende Signalisierung, Funktionalität, und eine Definition, welche im Allgemeinen dem 3GPP (Third Generation Partnership Project) LTE (Long Term Evolution) und/oder LTE-A(LTE-Advanced)-basierten drahtlosen Netzstandard, einschließlich aktueller, vorhergehender und zukünftiger Versionen dieses Standards, entspricht oder anderweitig damit kompatibel ist. Dazu können zum Beispiel 3GPP TS 36.212: „Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding”, 3GPP TS 36.211: „Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation”, 3GPP TS 23.221, 3GPP TS 24.301, 3GPP TS 36.413, 3GPP TS 33.401 usw. zählen. Der Verweis auf Hardwareplattformen (z. B. UE, eNodeB, MME, SGW, HSS, PGW, PCRF usw.) und damit im Zusammenhang stehende Signalisierung und Funktionalität, wie hierin verwendet, kann im Allgemeinen durch die zuvor genannten 3GPP-Standards und/oder Ableitungen davon definiert sein.
Das System 100 ist zum Austausch von Befehlen und/oder Daten mit anderen Servern/Systemen/Geräten über das Netz 106 und zum Austausch von Befehlen und/oder Daten mit verschiedenen Plattformen in der Zentrale 104 und/oder dem RAN 102 konfiguriert. Das System 100 kann mittels eines Switched-Fabric-Kommunikationsprotokolls, zum Beispiel ein Ethernet-Kommunikationsprotokoll usw., kommunizieren. Das Ethernet-Kommunikationsprotokoll kann in der Lage sein, Kommunikation mittels eines TCP/IP (Transmission Control Protocol/Internet Protocol) bereitzustellen. Das Ethernet-Protokoll kann dem Ethernet-Standard, veröffentlicht durch das IEEE (Institute of Electrical and Electronics Engineers) mit dem Titel „IEEE 802.3 Standard”, veröffentlicht im März 2002 und/oder späteren Versionen dieses Standards, zum Beispiel dem IEEE 802.3 Standard für Ethernet, veröffentlicht 2012, entsprechen oder damit kompatibel sein. Natürlich kann das Switched-Fabric-Kommunikationsprotokoll ein nutzerdefiniertes und/oder proprietäres Switched-Fabric-Kommunikationsprotokoll beinhalten. Der Nutzerebenen-Protokoll-Stack 118 und der Steuerungsebenen-Protokoll-Stack 120 sind auch in 1 für verschiedene Geräte im RAN 102 und in der Zentrale 104 veranschaulicht. Der Stack 118 und/oder 120 ist/sind im Allgemeinen kompatibel mit dem zuvor genannten 3GPP-Standard und/oder Ethernet-Protokoll.
Das RAN 102 beinhaltet im Allgemeinen mehrere Endnutzergeräte (UEs – end-user devices), Mobilfunktürme und lokale Knoten (eNodeB), welche zusammengenommen einen Teil des lokalen drahtlosen Netzwerkes bilden. Zu den UEs können zum Beispiel drahtlose Handgeräte (z. B. iPad^® usw.), Smartphones (z. B. iPhone^®, Galaxy^® usw.) gehören. Die Türme sind, wie gezeigt, jeweils zum Kommunizieren mit eNodeB-Systemen konfiguriert. Jeder/s Turm und/oder eNodeB-Gerät kann einen Rand des Netzsystems 100 bilden. Die Sammlung von Geräten in dem RAN 102 ist zum Kommunizieren mit der Zentrale 104 konfiguriert. Die Zentrale 104 (hierin auch als ein EPC (Evolved Packet Core) bezeichnet) ist im Allgemeinen derart konfiguriert, dass sie eine Vielzahl von Funktionen im Zusammenhang mit dem Einsatz und dem Management des drahtlosen Systems und drahtloser Geräte durchführt. Zu diesem Zweck beinhaltet die Zentrale 104, im konventionellen System, mehrere unabhängige Hardwaresysteme zum Bereitstellen der Funktionalität, die durch das Netz benötigt wird. Zum Beispiel kann eine typische Zentrale 104 eine MME (Mobility Management Entity)-Plattform 108 beinhalten, welche für die Signalisierung, Träger- und Zustandsmanagementfunktionen der Zentrale 104 konfiguriert ist, zu welchen zum Beispiel das Management der Anzahl an Geräten (z. B. Geräte im RAN 102) verbunden mit den Netzwerk 100, die Identifizierung des Mobilfunkturmes, mit welchem jedes Gerät verbunden ist, das Verwalten spezifischer Dienstanfragen von einem oder mehreren der Geräte, das Verwalten einer ruhenden oder aktiven Verbindung von Geräten, das Verwalten der Bewegung von Geräten zwischen Türmen/eNodeBs usw. und/oder andere Funktionalität, wie sie durch die zuvor genannten 3GPP-Standards definiert sein kann, zählen können.
Die Zentrale 104 beinhaltet üblicherweise auch eine SGW (Serving Gateway)-Plattform 110, welche zur Dienst-(Träger-)Verhandlung konfiguriert ist und im Allgemeinen als ein Hochleistungs-Dienstaggregations-Router arbeitet, der primär für hohen Datendurchsatz ausgelegt ist. Zum Beispiel ist das SGW 110 zum Austausch von Befehlen und Daten mit der MME 108 konfiguriert, wenn sich ein Gerät mit einem eNodeB verbindet, bei einer spezifischen Dienstanfrage, bei einer Ferngerätübergabe usw. Das SGW 110 ist auch zum Bereitstellen von Benutzerebenen-Abschlusspunkten für jedes eNodeB-Gerät, den Austausch von Befehlen und Daten mit dem Packet-Gateway (PGW, unten diskutiert) 114 zum Einrichten der Nutzerebene für akzeptierte Träger und zum Leiten von Nutzerebenen-Befehlsströmen zwischen dem eNodeB und dem PGW 114 usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert.
Die Zentrale 104 beinhaltet üblicherweise auch einen HSS (Home Subscription Server) 112, bei welchem es sich um eine Datenbank zum Speichern von Profil- und Berechtigungsinformationen für jedes UE (und/oder jeden Teilnehmer) usw. handelt, und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann. Die Zentrale 104 beinhaltet üblicherweise auch ein PGW 114, welches zum Bereitstellen eines Gateways zwischen dem System 100 und dem Netzwerk 106 (z. B. Internet) konfiguriert ist. Das PGW 114 ist im Allgemeinen zum Bereitstellen von Decodierung von eNodeB-Daten (z. B. GTP-U-Nutzlasten) auf Netzrouter (nicht gezeigt) zum Übertragen der Daten auf ein oder mehrere externe Netzwerke 106, von Codierung eingehenden Verkehrs vom Netzwerk 106 in GTP-U-Nutzlasten durch Codierung von Ziel-eNodeB-Adressinformationen und von Routing von GTP-U-Datenströmen zu einer geeigneten Schnittstelle des SGW 110 usw. und/oder anderer Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert. Die Zentrale 104 beinhaltet üblicherweise auch ein PCRF (Policy and Rules Function)-Gerät 116, welches zum Verwalten von Strategie und/oder spezifischen Regeln für jedes UE (und/oder jeden Teilnehmer) usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert ist. Durch konstruktive Maßnahmen wird jede der Plattformen der herkömmlichen Telekommunikationsarchitektur 100 auf unabhängigen Hardwaresystemen eingesetzt, wie im Allgemeinen in 1 gezeigt, und diese Plattformen kommunizieren üblicherweise mittels dem zuvor genannten Ethernet-Kommunikationsprotokoll (und/oder einem proprietären Switched-Packet-Kommunikationsprotokoll) miteinander.
1 veranschaulicht auch Details einer typischen drahtlosen EPS(End-to-End Evolved Packet System)-Netzkonfiguration. In dieser Konfiguration etabliert ein eNodeB (bei welchem es sich um die Funkzugangsnetztürme oder kleine Funkzugangspunkte handelt) einen Träger oder Pfad zum Internet für die Geräte (UEs), welche sich mit diesen verbinden. Der Träger ist spezifisch für die Art des Verkehrs, welchen er trägt. Zum Beispiel benötigen Browsing und E-Mail üblicherweise Standardträger, während Audio- oder Videostreaming spezielle Träger benötigen. Ein UE, verbunden mit einem eNodeB, kann mehrere Träger im Zusammenhang mit einer oder mehreren Anwendungssitzungen, welche auf dem UE ausgeführt werden, etablieren. Sowohl die Art des Trägers als auch die Zahl der Träger, die durch ein UE etabliert werden, müssen durch die Zentrale 104 verhandelt werden. Bei einer erfolgreichen Verhandlung eines Trägers stellt das PGW 114 externen Internetzugang durch die Anwendung, welche auf dem UE läuft, bereit.
Die Trägerverhandlung erfolgt üblicherweise beim Anwendungsstart und setzt sich während der gesamten Dauer der Anwendungsausführung fort. Dies gestattet a) dem UE, sich über eNodeBs hinweg zu bewegen (d. h. Übergabe) und b) Anwendungsfülle, z. B. eine Browseranwendung zum Starten eines Audio- oder Videostreams. Im System 100 wird die Trägerverhandlung im Allgemeinen durch Signalisierungsnachrichten, die über IP übertragen werden, bereitgestellt, wie durch die zuvor genannten 3GPP-Standards definiert sein kann. Diese Signalisierungsnachrichten sind üblicherweise kurz, z. B. 50 bis 100 Bytes, liegen jedoch üblicherweise in einer hohen Zahl vor, in Abhängigkeit von der Zahl der laufenden Anwendungen und der Anzahl an UEs im System 100. Die Signalisierungsnachrichten von den eNodeBs/UEs werden an die Zentrale 104 übermittelt (üblicherweise übermittelt an die MME 108 und das SGW 110), üblicherweise mit 10 bis 50 us Intervallen in einer gegebenen Netzkonfiguration. Die Geräte der Zentrale 104 werden über einen Netzanbieter oder Träger-Backbone verbunden und die gesamte Signalisierung sowie der Anwendungsverkehr werden von dem eNodeB auf dem Metro-Ethernet zurückübertragen. Die Anwendungsnutzlast wird nur an den Internet-Backbone bereitgestellt, wenn sämtliche Signalisierungsprüfungen durch die Zentrale 104 auf dem Träger-Backbone erfüllt werden.
Wie oben beschrieben, ist die Trägerverhandlung über physisch getrennte Elemente hinweg verteilt, daher ist die funktionale Skalierbarkeit und Leistung des EPC 104 begrenzt. Zum Beispiel: wenn kleine Zellen zu Adress-Hotspots des lokalen Datenbedarfs hinzugefügt werden, wird die Zahl der Teilnehmer (oder Geräte), welche eine MME 108 handhaben kann, erheblich beeinträchtigt, und das SGW 110 ist ein Hochleistungs-Dienstaggregations-Router, der primär für hohen Datendurchsatz ausgelegt ist (z. B. 80 Tbps). Der Signalisierungsverkehr, welchen er empfängt, setzt üblicherweise signifikant seine Kapazität herab. Dieser Mangel an Funktions- und Leistungsskalierbarkeit des EPC 104 ist der Grund für die hohen OPEX (in einigen Fällen mehr als 80%) von Netzbetreibern.
2 veranschaulicht eine skalierbare Hardwareplattform 200 gemäß der vorliegenden Offenbarung. In der vorliegenden Offenbarung ist die Hardwareplattform 200 zum Beherbergen virtualisierter Instanzen der verschiedenen Hardwaresysteme der Zentrale 104 konfiguriert. Somit kann, anstelle des Erfordernisses für mehrere Hardwareplattformen, eine einzelne Hardwareplattform für die gesamte oder einen Teil der Funktionalität der Zentrale 104 verwendet werden. Durch die Virtualisierung der verschiedenen Funktionen der Zentrale 104 stellt die vorliegende Offenbarung Skalierbarkeit auf der Grundlage anwendungsspezifischer Eigenschaften bereit und verringert oder eliminiert den Nachteil im Zusammenhang mit physischen Schnittstellen (wie durch den konventionellen Ansatz erforderlich).
Die Plattform 200 beinhaltet einen Systemprozessor 202 (z. B. ein Mehrkern-Mehrzweck-Prozessor, wie z. B. diejenigen bereitgestellt durch die Intel Corp. usw.), Systemspeicher 204, RAN-Schnittstellenschaltungen 206 und Netzschnittstellenschaltungen 208. Die RAN-Schnittstelle 206 ist zum Bereitstellen einer Schnittstelle zwischen den mehreren virtuellen Maschinen(VM – virtual machine)-Instanzen konfiguriert, welche im Speicher 204 und dem Funknetz 102 untergebracht sind. Die RAN-Schnittstelle 206 und die Signalisierung zwischen dem RAN 102 und der Plattform 200 können den zuvor genannten 3GPP-Standards entsprechen. Die Netzschnittstellenschaltungen 208 sind zum Bereitstellen einer Schnittstelle zwischen den Netzwerk 106 und der Plattform 200 konfiguriert. Die Netzschnittstellenschaltungen 208 und die Signalisierung zwischen den Netzschnittstellenschaltungen 208 und der Plattform 200 können dem zuvor genannten IEEE-Ethernet-Standard entsprechen. Der Speicher 204 ist zum Speichern mehrerer virtueller Maschinen(VM)-Module konfiguriert, wie unten detaillierter beschrieben werden wird.
Die im Speicher 204 gespeicherten VM-Module beinhalten ein VM-Bereitstellungsmodul 222, welches zum Bereitstellen von Hardwareressourcen im Zusammenhang mit der Plattform 200 und Zuweisen der Hardwareressourcen zu einem oder mehreren der mehreren VM-Module 210–220 konfiguriert ist. Die Hardwareressourcen können zum Beispiel einen oder mehrere Kerne im Zusammenhang mit dem Prozessor 202, der RAN-Schnittstelle 206, der Netzschnittstelle 208, der Größe des Speichers 204 usw. beinhalten. Ein virtualisierender Hypervisor 224 ist zum Abstrahieren der Hardwareressourcen der Plattform 200, welche durch die VM-Module 210–220 genutzt werden sollen, konfiguriert.
Zum Bereitstellen der Virtualisierung der Funktionalität der Zentrale 104 beinhaltet die Plattform 200 der vorliegenden Offenbarung ein Signalisierungs-VM-Modul 210, welches im Allgemeinen derart konfiguriert ist, dass es zumindest einen Teil der Funktionalität der MME 108 und zumindest einen Teil der Funktionalität des SGW 110 von 1, wie oben beschrieben, bereitstellt. Zum Beispiel kann das Signalisierungs-VM-Modul 210 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung der Signalisierungs-VM 210 laufen) beinhalten, welche derart konfiguriert sind, dass sie die Abfrage einer Teilnehmerdatenbank-VM 220 (unten diskutiert) und/oder einer Strategieentscheidungs-VM 218 (unten diskutiert) zum Authentifizieren eines Gerätes (UE) zum Zuordnen eines Trägers und/oder einer Bestimmung, wie viele UEs mit dem System 100 verbunden sind, bereitstellen. Das Signalisierungs-VM-Modul 210 kann auch zum Bestimmen einer Identität eines Mobilfunkturmes, über welchen jedes UE mit dem System 100 verbunden ist, konfiguriert sein. Das Signalisierungs-VM-Modul 210 kann auch derart konfiguriert sein, dass es spezifische Dienstanfragen von einem oder mehreren UE parst. Das Signalisierungs-VM-Modul 210 kann auch zum Bestimmen eines aktiven oder ruhenden Zustandes von einem oder mehreren UEs in dem System 100 konfiguriert sein. Das Signalisierungs-VM-Modul 210 kann auch zum Bestimmen von Bewegung eines UE von einem eNodeB/Turm zu einem anderen eNodeB/Turm konfiguriert sein. Das Signalisierungs-VM-Modul 210 kann auch zum Cachen aktiver UE-Gerätezustandsinformationen zum Bereitstellen eines schnelleren Zugangs zu UE-Gerätezustandsinformationen (im Gegensatz zu einer Datenbanksuche) konfiguriert sein. Das Signalisierungs-VM-Modul 210 kann auch zum Aktualisieren einer Gerätezustandsdatenbank-Management-VM 216 (unten diskutiert) usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards für Signalisierungs- und Zustandsmanagementfunktionen der Zentrale definiert sein kann, konfiguriert sein.
Die Plattform 200 der vorliegenden Offenbarung beinhaltet auch ein Trägermanagement-VM-Modul 212, welches im Allgemeinen zum Bereitstellen von mindestens einem Teil der Funktionalität des SGW 110 und mindestens einem Teil der Funktionalität der MME 108, wie oben beschrieben, konfiguriert ist. Zum Beispiel kann das Trägermanagement-VM-Modul 212 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung der Trägermanagement-VM 212 laufen) beinhalten, welche zum Bereitstellen eines Abschlusspunktes an einen eNodeB für den Datenverkehr von einem UE (Nutzerebene) und/oder zum Leiten von Nutzerebenen-Datenströmen zwischen einem eNodeB und dem Netzwerk/Routing-Management-VM-Modul 114 (unten diskutiert) konfiguriert sind. Das Trägermanagement-VM-Modul 212 kann auch zum Kommunizieren mit dem Signalisierungs-VM-Modul 210 für das UE-Management konfiguriert sein, wenn sich ein oder mehrere UEs mit einem eNodeB verbinden, wenn ein UE eine spezifische Dienstanfrage kommuniziert und/oder wenn sich ein UE zwischen einem Turm/eNodeB (z. B. Übergabeoperationen) bewegt. Das Trägermanagement-VM-Modul 212 kann auch zum Kommunizieren mit dem Netzwerk/Routing-Management-VM-Modul 114 (unten diskutiert) zum Etablieren einer Nutzerebene für einen oder mehrere akzeptierte Träger usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards für Dienst-(Träger-)Verhandlung und/oder Routing-Funktionen der Zentrale definiert sein kann, konfiguriert sein.
Zusätzlich, und im Gegensatz zur/m konventionellen MME 108 und SGW 110, kann das Trägermanagement-VM-Modul 212 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung der Trägermanagement-VM 212 laufen) beinhalten, welche zum Bereitstellen von Decodierung von eNodeB-Daten (z. B. GTP-U-Nutzlasten) auf Netzrouter (nicht gezeigt) zum Übertragen der Daten an ein oder mehrere externe Netzwerke 106, von Codierung eingehenden Verkehrs vom Netzwerk 106 in GTP-U-Nutzlasten durch Codierung von Ziel-eNodeB-Adressinformationen und von Routing von GTP-U-Datenströmen an eine geeignete RAN-Schnittstelle 206, zum Bereitstellen einer Abfrage der Gerätezustandsdatenbank-Management-VM 216 (unten diskutiert) und/oder einer Strategieentscheidungs-VM 218 (unten diskutiert) zum Reagieren auf spezifische Trägeranfragen, zum Beispiel QoS-Anfragen, spezifische Trägeranfragen, zusätzliche Trägeranfragen usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert sind.
Die Plattform 200 der vorliegenden Offenbarung beinhaltet auch ein Netzwerk/Routing-Management-VM-Modul 214, welches im Allgemeinen zum Bereitstellen von zumindest einem Teil der Funktionalität des PGW 114 von 1, wie oben beschrieben, konfiguriert ist. Zum Beispiel kann das Trägermanagement-VM-Modul 214 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung des Netzwerk/Routing-Management-VM-Moduls 214 laufen) beinhalten, welche zum Bereitstellen von Decodierung von eNodeB-Daten (z. B. GTP-U-Nutzlasten) auf Netzrouter (nicht gezeigt) zum Übertragen der Daten an ein oder mehrere externe Netzwerke 106, von Codierung von eingehendem Verkehr von dem Netzwerk 106 in GTP-U-Nutzlasten durch Codierung von Ziel-eNodeB-Adressinformationen und von Routing von GTP-U-Datenströmen an eine geeignete Schnittstelle des SGW 110 konfiguriert sind. Das Netzwerk/Routing-Management-VM-Modul 212 kann auch zum Bereitstellen einer Abfrage der Gerätezustandsdatenbank-Management-VM 216 (unten diskutiert) usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert sein.
Die Plattform 200 der vorliegenden Offenbarung beinhaltet auch ein Gerätezustandsdatenbank-Management-VM-Modul 216, welches im Allgemeinen zum Bereitstellen von zumindest einem Teil der Funktionalität des SGW 110 und des HSS 112 von 1, wie oben beschrieben, konfiguriert ist. Zusätzlich, und im Gegensatz zum konventionellen SGW 110 und HSS 112, kann das Gerätezustandsdatenbank-Management-VM-Modul 216 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung des Gerätezustandsdatenbank-Management-VM-Moduls 216 laufen) beinhalten, welche zum Bereitstellen von Datenbankspeicherung des Zustandes aktiver und inaktiver UEs im Netzwerk konfiguriert sind. Das Gerätezustandsdatenbank-Management-VM-Modul 216 kann auch zum Kommunizieren mit dem Signalisierungs-VM-Modul 210 zum Aktualisieren von aktiven Gerätezustandsinformationen, zum Kommunizieren mit dem Trägermanagement-VM-Modul 212 zum Bereitstellen von Gerätezustandsinformationen zum Zulassen zusätzlicher Dienstanfragen von einem oder mehreren UEs und zum Kommunizieren mit dem Teilnehmerdatenbank-VM-Modul 220 (unten beschrieben) zum Bestimmen, ob ein oder mehrere UEs ordnungsgemäß für die Zulassung im Netzwerk angemeldet sind, usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert sein.
Die Plattform 200 der vorliegenden Offenbarung beinhaltet auch ein Strategieentscheidungs-VM-Modul 218, welches im Allgemeinen zum Bereitstellen von zumindest einem Teil der Funktionalität der PCRF 116 von 1, wie oben beschrieben, konfiguriert ist. Zum Beispiel kann das Strategieentscheidungs-VM-Modul 218 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung des Strategieentscheidungs-VM-Moduls 218 laufen) beinhalten, welche zum Verwalten von Strategie und/oder spezifischen Regeln für jedes UE (und/oder jeden Teilnehmer) usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert sind. Die Plattform 200 der vorliegenden Offenbarung beinhaltet auch ein Teilnehmerdatenbank-VM-Modul 220, welches im Allgemeinen zum Bereitstellen von zumindest einem Teil der Funktionalität des HSS 112 von 1, wie oben beschrieben, konfiguriert ist. Zum Beispiel kann das Teilnehmerdatenbank-VM-Modul 220 eine oder mehrere Anwendungen (die in einer virtualisierten Umgebung des Teilnehmerdatenbank-VM-Moduls 220 laufen) beinhalten, welche zum Speichern von Profil- und Berechtigungsinformationen für jedes UE (und/oder jeden Teilnehmer) usw. und/oder andere Funktionalität, wie durch die zuvor genannten 3GPP-Standards definiert sein kann, konfiguriert sind.
Vorteilhafterweise sieht die vorliegende Offenbarung virtualisierte Instanzen zum Bereitstellen verschiedener hierin beschriebener Funktionalität vor, und die Kommunikation zwischen zwei oder mehr VM-Modulen kann mittels Softwareprozeduraufrufen (z. B. Semaphore (ein Synchronisationsmechanismus etabliert zwischen zwei Threads oder Prozessen zum Synchronisieren des Zugangs zu gemeinsam genutzten Ressourcen) usw.) anstelle von Ethernet- (oder anderen) Kommunikationen etabliert werden, welche notwendigerweise Stack-Protokolle (z. B. Nutzerebenen-Stack, Steuerungsebenen-Stack usw.) erfordern. Somit kann die Kommunikation zwischen VM-Modulen der vorliegenden Offenbarung viel schneller (z. B. Speichergeschwindigkeit anstelle von Netzgeschwindigkeit) und mit signifikant verringertem Mehraufwand im Vergleich zu den konventionellen Kommunikationssystemen zwischen Plattformen der konventionellen Zentrale 104 stattfinden.
In einigen Ausführungsformen weisen die VM-Instanzen durch das VM-Bereitstellungsmodul gemeinsam genutzten Zugang zu Ressourcenpools auf. Im Betrieb treten der Signalisierungs- sowie der Anwendungsverkehr in den Träger-Backbone ein, und zwar über die Netzschnittstelle 208 und/oder die RAN-Schnittstelle 206. Jedoch werden, anstatt dass Signalisierungsnachrichten zwischen unterschiedlichen physischen Elementen hin und her pendeln, Nachrichten durch Softwareprozesse initiiert an einem oder mehreren VM-Modulen 210–220 geparst. Die VM-Module 210-222 können gleichzeitig laufen. Die Trägerverhandlungssignalisierung erfolgt durch einen Satz Softwaresemaphore. Erfolgreiches Schließen aller Signalisierungssemaphore und/oder Fernprozeduraufrufe (z. B. RAPI usw.) gestattet den Anwendungsnutzlasten das Verlassen auf den Internet-Backbone. Eine Verringerung der Signalisierungsnachrichtverarbeitung zu Softwaresemaphoren eliminiert signifikant den Verarbeitungsmehraufwand im Zusammenhang mit dem Einrichten der IP-Transporte der konventionellen EPC-Architektur. Der Datentransfer zwischen verschiedenen Elementen der Netzwerkpipeline kann mit Speichergeschwindigkeitstransfer anstatt Netzgeschwindigkeitstransfer stattfinden. Das VM-Bereitstellungsmodul 222 kann zum Kommunizieren mit Anwendungsdienstanbietern, z. B. YouTube, Fox, ESPN usw., zum Bereitstellen einer skalierbaren Bereitstellung virtualisierter Funktionen im Zusammenhang mit den VM-Modulen 210–220 konfiguriert sein. Dies kann ein anwendungsspezifisches Zuschneiden der Infrastruktur der Zentrale ermöglichen, welches bisher mit den verpackten Funktionen und physischen Schnittstellen nicht möglich war.
Außerdem stellt die Instanziierung der Funktionen den VM-Modulen 210–220 eine skalierbare Bereitstellung von Hardwareressourcen für jedes der VM-Module 210–220 bereit. Die Leistung von jedem VM-Modul kann auf die Funktionsanforderungen abgestimmt werden, indem zusätzliche VMs, wie benötigt, instanziiert werden, um die Kapazität auf der Grundlage der Lastanforderung des RAN 102, des Netzwerkes 106 und/oder verfügbarer Hardwareressourcen der Plattform 200 zu skalieren. Die skalierbare Bereitstellung ist durch die schattierten Balken 226–236 innerhalb jedes entsprechenden VM-Moduls 210–220 dargestellt.
Auch können die virtualisierten Instanzen der hierin beschriebenen VM-Module vorteilhafterweise als Reaktion auf den Netzbedarf an verschiedenen Orten eingesetzt werden. Dementsprechend kann, während 2 die Plattform 200 mit den VM-Modulen 210–222 darstellt, in einigen Ausführungsformen ein Subset dieser Module an jedem Ort innerhalb des Netzsystems eingesetzt werden, als Reaktion auf den Lastbedarf zum Bereitstellen eines vorteilhaften lokalen Einsatzes verschiedener Funktionen. Diese Merkmale können die virtualisierten Instanzen ausgewählter VM-Module zum Bereitstellen einer höheren Reaktionsfähigkeit auf Verkehrs-/Lastbedingungen an einem spezifizierten Ort ermöglichen. Außerdem kann die hierin beschriebene, auf virtuellen Maschinen basierende Funktionalitätsbereitstellung eine Dezentralisierung des Kernnetzes 104 bereitstellen, wodurch es Instanzen gestattet wird, direkt an gezielten Rändern zu laufen, z. B. Unternehmens- oder Maschine-zu-Maschine-(M2M)Randknoten. Zum Beispiel können das Signalisierungs-VM-Modul 210, das Trägermanagement-VM-Modul 212 und/oder das Netzwerk/Routing-Management-VM-Modul 214 an einer eNodeB-/Turm-Position instanziiert werden (z. B. eingesetzt an einem Netzrand), als Reaktion auf hohen Verkehrsbedarf usw.
3 veranschaulicht eine Telekommunikationsnetzarchitektur 300 gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung. Die Telekommunikationsnetzarchitektur 300 beinhaltet verschiedene Hardware- und Netztopologie-Komponenten (z. B. eNodeB, Mobilfunktürme, Netzwerk, UEs usw.) wie das konventionelle Telekommunikationsnetz 100, und bestimmte Gegenstände in 3 sind graphisch gleich wie in 1 dargestellt, und somit sollen die zuvor beschriebenen Gegenstände in 3 die gleiche Definition/Beschreibung aufweisen, wie oben bezugnehmend auf 1 beschrieben. Die Telekommunikationsnetzarchitektur 300 entspricht im Allgemeinen, oder ist kompatibel mit den zuvor genannten 3GPP-Standards. Weiter bezugnehmend auf 1 und 2 beinhaltet das Netzwerk 300 eine VM-Bereitstellungsplattform 302, einen Kern-Backbone 304, ein RAN 306 und mehrere Anwendungs-/Inhaltsserver 308. Die VM-Bereitstellungsplattform 202 ist zum Kommunizieren mit den Anwendungs-/Inhaltsservern 308 (z. B. Google, YouTube, ESPN, FOX usw.) und Erzeugen von einer oder mehreren VM-Modul-Instanzen an einem ausgewählten Ort des RAN 306 konfiguriert, zum Beispiel wie durch Referenzziffer 200' eingesetzt auf einer ausgewählten Plattform im RAN 306 dargestellt. In diesem Fall wird die Referenzziffer 200' verwendet, um anzuzeigen, dass ein Subset der in 2 dargestellten VM-Instanzen eingesetzt werden kann. Der Kern-Backbone 304 kann ein oder mehrere Plattformsysteme beinhalten, welche zum Beherbergen von Instanzen zentralisierter Funktionen, z. B. das Strategieentscheidungs-VM-Modul 218 und/oder das Teilnehmerdatenbank-VM-Modul 220, konfiguriert sind.
In einigen Ausführungsformen kann die VM-Bereitstellungsplattform 302 zum Bereitstellen von Instanzen der VM-Module an Bereiche mit Ereignisbedarf, zum Beispiel wie bei 200' dargestellt, konfiguriert sein. Somit können zum Beispiel das Signalisierungs-VM-Modul 210, das Trägermanagement-VM-Modul 212, das Netzwerk/Routing-Management-VM-Modul 214 und/oder das Gerätezustandsdatenbank-Management-VM-Modul 218 an einer Netzrandposition 200' instanziiert werden, zum Beispiel auf der Grundlage des Lastbedarfs an einem Ort. Zentralisierte Funktionen können auf der Backbone-Plattform 304 instanziiert werden. Somit kann in der vorliegenden Offenbarung die Funktionalität verteilt sein und/oder sich gemeinsam an einer Netzrandposition (oder einer anderen Position mit erhöhten Lastanforderungen) befinden, während andere Funktionalität zentraler positioniert bleiben kann. Die Funktionen können zum Beispiel auf der Grundlage von Lastbedingungen, verfügbaren HW-Ressourcen usw. instanziiert werden.
Das Instanziieren ausgewählter VM-Module kann es Netzbetreibern oder Netzanbietern auch ermöglichen, diese VM-Module in dem Netzwerk basierend auf Netzwerkanalytik dynamisch zu bewegen und neu zu positionieren, d. h. die Signalisierungs-VMs dorthin zu bewegen, wo zu einer bestimmten Zeit der meiste Verkehr stattfinden wird, z. B. 8:00 Uhr US EST vs. 5:00 Uhr PST, um den Backhaul-Verkehr zu verringern, Energie zu sparen und Echtzeitreaktionen usw. zu verbessern. In einigen Ausführungsformen kann die VM-Bereitstellungsplattform 302 zum Optimieren der Positionierung eines VM-Moduls durch das Analysieren von Netzstatistiken konfiguriert sein, sodass das VM-Modul näher an die Datenquelle bewegt wird, d. h. die Mehrzahl der Anrufer an einem bestimmten Knoten.
Das Vorstehende basiert auf Beispielsystemarchitekturen und -methoden, jedoch sind Modifikationen an der vorliegenden Offenbarung möglich. Zum Beispiel kann die Plattform 200 Chipsatzschaltungen, verschiedene Busschaltungen, E/A-Schaltungen usw. beinhalten. Der Hostprozessor 202 kann einen oder mehrere Prozessorkerne beinhalten und kann zum Ausführen von Systemsoftware konfiguriert sein. Systemsoftware kann zum Beispiel Betriebssystem-Code (z. B. BS-Kernel-Code) und LAN(Local Area Network)-Treibercode beinhalten. LAN-Treibercode kann, zumindest teilweise, zum Steuern des Betriebes der Netzschnittstelle 208 konfiguriert sein. Der Systemspeicher kann E/A-Speicherpuffer beinhalten, welche zum Speichern eines oder mehrerer Datenpakete, die durch den Netzcontroller 104 gesendet oder empfangen werden sollen, konfiguriert sind. Chipsatzschaltungen können im Allgemeinen „North Bridge”-Schaltungen (nicht gezeigt) zum Steuern der Kommunikation zwischen dem Prozessor 202, der Netzschnittstelle 208, der RAN-Schnittstelle 206 und dem Systemspeicher 204 beinhalten.
In einigen Ausführungsformen kann die Netzschnittstelle 208 eine Netzschnittstellenkarte (NIC – network interface card) gekoppelt an die Plattform 200 über einen Bus (nicht gezeigt) sein. Der Bus kann einen Bus umfassen, welcher der PCI (Peripheral Component Interconnect) Express^TM Base Specification Revision 1.0, veröffentlicht am 22. Juli 2002, erhältlich von der PCI Special Interest Group, Portland, Oregon, USA (im Folgenden als ein „PCI Express^TM Bus” bezeichnet) entspricht. Alternativ dazu kann der Bus stattdessen einen Bus umfassen, welcher der PCI-X Specification Rev. 1.0a, 24. Juli 2000, erhältlich von der vorbenannten PCI Special Interest Group, Portland, Oregon, USA (im Folgenden als ein „PCI-X Bus” bezeichnet) entspricht. Auch alternativ dazu kann der Bus andere Arten und Konfigurationen von Bussystemen umfassen, ohne sich von dieser Ausführungsform zu entfernen.
Die Plattform 200 kann ferner ein Betriebssystem (BS, nicht gezeigt) zum Verwalten von Systemressourcen und Steuerungsaufgaben, welche z. B. auf der Plattform 200 laufen, beinhalten. Zum Beispiel kann das BS mittels Microsoft Windows, HP-UX, Linux oder UNIX implementiert werden, obwohl auch andere Betriebssysteme verwendet werden können. In einigen Ausführungsformen kann das BS durch einen virtuellen Maschinenmonitor (oder Hypervisor) ersetzt werden, welcher eine Abstraktionsschicht für zugrundeliegende Hardware an verschiedene Betriebssysteme (virtuelle Maschinen), welche auf einer oder mehreren Verarbeitungseinheiten laufen, bereitstellen kann. Das Betriebssystem und/oder die virtuelle Maschine kann einen oder mehrere Protokoll-Stacks implementieren. Ein Protokoll-Stack kann ein oder mehrere Programme zum Verarbeiten von Paketen ausführen. Ein Beispiel eines Protokoll-Stacks ist ein TCP/IP(Transport Control Protocol/Internet Protocol)-Protokoll-Stack, welcher ein oder mehrere Programme zum Handling (z. B. Verarbeitung oder Erzeugung) von Paketen zum Senden und/oder Empfangen über ein Netzwerk umfasst. Ein Protokoll-Stack kann sich alternativ dazu auf einem dedizierten Subsystem befinden, wie zum Beispiel eine TCP-Offload-Engine und/oder die Netzschnittstelle 208. Die Schaltungen der TCP-Offload-Engine können zum Bereitstellen von zum Beispiel Pakettransport, Paketsegmentierung, Paketneuordnung, Fehlerprüfung, Sendebestätigungen, Sendewiederholungen usw. konfiguriert sein, ohne das Erfordernis einer Host-CPU- und/oder Software-Beteiligung.
Der Systemspeicher kann eine oder mehrere der folgenden Speicherarten umfassen: Halbleiter-Firmware-Speicher, programmierbarer Speicher, nichtflüchtiger Speicher, Nur-Lese-Speicher, elektrisch programmierbarer Speicher, Zufallszugriffsspeicher, Flash-Speicher, Magnetplattenspeicher und/oder optischer Plattenspeicher. Jeder zusätzliche oder alternative Systemspeicher kann auch andere und/oder später entwickelte Arten von computerlesbarem Speicher umfassen.
Ausführungsformen der hierin beschriebenen Operationen können in ein System implementiert sein, welches ein oder mehrere Speichergeräte beinhaltet, auf welchen, einzeln oder in Kombination, Befehle speichert sind, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, die Operationen durchführen. Der Prozessor kann zum Beispiel eine Verarbeitungseinheit und/oder programmierbare Schaltungen in der Netzplattform 200 und/oder eine andere Verarbeitungseinheit oder programmierbare Schaltungen beinhalten. Somit ist es beabsichtigt, dass Operationen gemäß der hierin beschriebenen Verfahren über mehrere physische Geräte verteilt sein können, wie z. B. Verarbeitungsstrukturen an mehreren unterschiedlichen physischen Positionen. Das Speichergerät kann jede Art eines greifbaren, nichttransitorischen Speichergerätes, zum Beispiel jede Art Platte, einschließlich Disketten, optische Platten, CD-ROMs, CD-RWs und magnetoptische Platten, Halbleitergeräte, wie z. B. Nur-Lese-Speicher (ROMs), Zufallszugriffsspeicher (RAMs), wie z. B. dynamische und statische RAMs, löschbare programmierbare Nur-Lese-Speicher (EPROMs), elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROMs), Flash-Speicher, magnetische oder optische Karten, oder jede Art von Speichergeräten, die zum Speichern elektronischer Befehle geeignet sind, beinhalten.
„Modul”, wie hierin verwendet, kann einzeln oder in jeder Kombination Code und/oder Befehlssätze (z. B. Software, Firmware usw.) umfassen, welche zum Ausführen und Laufen lassen durch ein Verarbeitungsgerät konfiguriert sind.
Dementsprechend sieht die vorliegende Offenbarung eine Plattform für ein drahtloses Telekommunikationsnetzsystem vor. Die Plattform beinhaltet einen Prozessor zum Ausführen von Befehlen im Zusammenhang mit mehreren virtuellen Maschinen(VM)-Modulen; Speicher zum Speichern der mehreren virtuellen Maschinen-Module; eine erste Schnittstelle zum Austauschen von Befehlen und Daten zwischen mindestens einem VM-Modul und mindestens einem anderen Nutzergerät (UE) in Kommunikation mit der Plattform; und eine zweite Schnittstelle zum Austauschen von Befehlen und Daten zwischen mindestens einem VM-Modul und einem Netzwerk in Kommunikation mit der Plattform. Die VM-Module beinhalten ein Signalisierungs-VM-Modul für, zumindest teilweise, das Zustandsmanagement des mindestens einen UE; und ein Netzwerk/Routing-Management-VM-Modul für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk.
Die vorliegende Offenbarung sieht auch eine Computerplattform zum Beherbergen einer virtuellen Maschinen(VM)-Umgebung zum Austauschen von Befehlen und Daten im Zusammenhang mit mindestens einem Nutzergerät (UE) in Kommunikation mit der Computerplattform und zum Austauschen von Befehlen und Daten im Zusammenhang mit einem Netzwerk in Kommunikation mit der Computerplattform vor. Die Computerplattform beinhaltet ein Signalisierungs-VM-Modul für, zumindest teilweise, das Zustandsmanagement von mindestens einem UE; ein Netzwerk-/Routing-Management-VM-Modul für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk; und ein VM-Bereitstellungsmodul für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit der Computerplattform und das Zuweisen der Hardwareressourcen zu mindestens entweder dem Signalisierungs-VM-Modul oder dem Netzwerk/Routing-Management-VM-Modul. Das VM-Bereitstellungsmodul dient ferner dem Skalieren der Hardwareressourcen bereitgestellt an das Signalisierungs-VM-Modul oder das Netzwerk/Routing-Management-VM-Modul auf der Grundlage, zumindest teilweise, von Lastanforderungen des mindestens einen UE oder des Netzwerkes.
Die vorliegende Offenbarung sieht auch ein Verfahren zum Virtualisieren eines EPC (Evolved Packet Core) eines drahtlosen Telekommunikationsnetzwerkes auf eine Computerplattform vor, wobei die Computerplattform dem Austauschen von Befehlen und Daten im Zusammenhang mit mindestens einem Nutzergerät (UE) in Kommunikation mit der Computerplattform und dem Austauschen von Befehlen und Daten im Zusammenhang mit einem Netzwerk in Kommunikation mit der Computerplattform dient. Das Verfahren beinhaltet das Erzeugen eines Signalisierungs-VM-Moduls für, zumindest teilweise, das Zustandsmanagement von mindestens einem UE; das Erzeugen eines Netzwerk/Routing-Management-VM-Moduls für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk; und das Erzeugen eines VM-Bereitstellungsmoduls für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit der Computerplattform und das Zuweisen der Hardwareressourcen zu mindestens entweder dem Signalisierungs-VM-Modul oder dem Netzwerk/Routing-Management-VM-Modul. Das VM-Bereitstellungsmodul dient ferner dem Skalieren der Hardwareressourcen bereitgestellt an das Signalisierungs-VM-Modul oder das Netzwerk/Routing-Management-VM-Modul auf der Grundlage, zumindest teilweise, der Lastanforderungen des mindestens einen UE oder des Netzwerkes.
Die vorliegende Offenbarung sieht auch ein Beispielsystem vor, welches ein Computerplattformsystem zum Virtualisieren eines EPC (Evolved Packet Core) eines drahtlosen Telekommunikationsnetzwerkes auf eine Computerplattform beinhaltet, wobei die Computerplattform dem Austauschen von Befehlen und Daten im Zusammenhang mit mindestens einem Nutzergerät (UE) in Kommunikation mit der Computerplattform und dem Austauschen von Befehlen und Daten im Zusammenhang mit einem Netzwerk in Kommunikation mit der Computerplattform dient. Das Computerplattformsystem beinhaltet ein oder mehrere Speichergeräte, auf welchen, einzeln oder in Kombination, Befehle gespeichert sind, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, in den folgenden Operationen resultieren, einschließlich des Erzeugens eines Signalisierungs-VM-Moduls für, zumindest teilweise, das Zustandsmanagement von mindestens einem UE; des Erzeugens eines Netzwerk/Routing-Management-VM-Moduls für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk; und des Erzeugens eines VM-Bereitstellungsmoduls für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit dem Computerplattformsystem und des Zuweisens der Hardwareressourcen zu mindestens entweder dem Signalisierungs-VM-Modul oder dem Netzwerk/Routing-Management-VM-Modul. Das VM-Bereitstellungsmodul dient ferner dem Skalieren der Hardwareressourcen bereitgestellt an das Signalisierungs-VM-Modul oder das Netzwerk/Routing-Management-VM-Modul auf der Grundlage, zumindest teilweise, der Lastanforderungen des mindestens einen UE oder des Netzwerkes.
Die Begriffe und Ausdrücke, welche hierin eingesetzt wurden, sind als Beschreibungs- und nicht als Einschränkungsbegriffe verwendet, und es besteht bei der Verwendung derartiger Begriffe und Ausdrücke nicht die Absicht, Äquivalente der gezeigten und beschriebenen Merkmale (oder Teile davon) auszuschließen, und es wird erkannt, dass verschiedene Modifikationen innerhalb des Umfangs der Ansprüche möglich sind. Dementsprechend sollen die Ansprüche alle derartigen Äquivalente abdecken.
Verschiedene Merkmale, Aspekte und Ausführungsformen wurden hierin beschrieben. Die Merkmale, Aspekte und Ausführungsformen können miteinander kombiniert sowie variiert und modifiziert werden, wie durch den Fachmann auf dem Gebiet verstanden werden wird. Die vorliegende Offenbarung sollte daher als derartige Kombinationen, Variationen und Modifikationen einschließend angesehen werden.

Claims

Plattform für ein drahtloses Telekommunikationsnetzsystem, welche Folgendes umfasst: einen Prozessor zum Ausführen von Befehlen im Zusammenhang mit mehreren virtuellen Maschinen(VM)-Modulen; Speicher zum Speichern der mehreren virtuellen Maschinenmodule; eine erste Schnittstelle zum Austauschen von Befehlen und Daten zwischen mindestens einem VM-Modul und mindestens einem Nutzergerät (UE – user equipment) in Kommunikation mit der Plattform; und eine zweite Schnittstelle zum Austauschen von Befehlen und Daten zwischen mindestens einem VM-Modul und einem Netzwerk in Kommunikation mit der Plattform; und wobei die VM-Module Folgendes umfassen: ein Signalisierungs-VM-Modul für, zumindest teilweise, das Zustandsmanagement des mindestens einen UE; und ein Netzwerk/Routing-Management-VM-Modul für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk.
Plattform nach Anspruch 1, wobei die VM-Module ferner Folgendes umfassen: ein Trägermanagement-VM-Modul für, zumindest teilweise, das Trägermanagement des mindestens einen UE.
Plattform nach Anspruch 1, wobei die VM-Module ferner Folgendes umfassen: ein Gerätezustandsdatenbank-Management-VM-Modul für, zumindest teilweise, das Management von Gerätezustandsdaten im Zusammenhang mit dem mindestens einen UE.
Plattform nach Anspruch 1, wobei die VM-Module ferner Folgendes umfassen: ein Strategieentscheidungs-VM-Modul für, zumindest teilweise, das Management der Dienststrategie und -regeln im Zusammenhang mit dem mindestens einen UE.
Plattform nach Anspruch 1, wobei die VM-Module ferner Folgendes umfassen: ein Teilnehmerdatenbank-VM-Modul für, zumindest teilweise, das Management von Profil- und Berechtigungsdaten im Zusammenhang mit dem mindestens einen UE.
Plattform nach Anspruch 1, wobei die VM-Module ferner Folgendes umfassen: ein VM-Bereitstellungsmodul für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit der Plattform und Zuweisen der Hardwareressourcen zu einem oder mehreren der mehreren VM-Module.
Plattform nach Anspruch 6, wobei das VM-Bereitstellungsmodul ferner dem Skalieren der Hardwareressourcen bereitgestellt an das mindestens eine VM-Modul auf der Grundlage, zumindest teilweise, der Lastanforderungen des mindestens einen UE oder des Netzwerkes dient.
Plattform nach Anspruch 1, wobei die Plattform ein einzelnes Computersystem ist.
Computerplattform zum Beherbergen einer virtuellen Maschinen(VM)-Umgebung zum Austauschen von Befehlen und Daten im Zusammenhang mit mindestens einem Nutzergerät (UE) in Kommunikation mit der Computerplattform und zum Austauschen von Befehlen und Daten im Zusammenhang mit einem Netzwerk in Kommunikation mit der Computerplattform, wobei die Computerplattform Folgendes umfasst: ein Signalisierungs-VM-Modul für, zumindest teilweise, das Zustandsmanagement von mindestens einem UE; ein Netzwerk/Routing-Management-VM-Modul für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk; und ein VM-Bereitstellungsmodul für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit der Computerplattform und Zuweisen der Hardwareressourcen zu mindestens entweder dem Signalisierungs-VM-Modul oder dem Netzwerk/Routing-Management-VM-Modul; wobei das VM-Bereitstellungsmodul ferner dem Skalieren der Hardwareressourcen bereitgestellt an das Signalisierungs-VM-Modul oder das Netzwerk/Routing-Management-VM-Modul auf der Grundlage, zumindest teilweise, der Lastanforderungen des mindestens einen UE oder des Netzwerkes dient.
Computerplattform nach Anspruch 9, welche ferner Folgendes umfasst: ein Trägermanagement-VM-Modul für, zumindest teilweise, das Trägermanagement des mindestens einen UE.
Computerplattform nach Anspruch 9, welche ferner Folgendes umfasst: ein Gerätezustandsdatenbank-Management-VM-Modul für, zumindest teilweise, das Management von Gerätezustandsdaten im Zusammenhang mit dem mindestens einen UE.
Computerplattform nach Anspruch 9, welche ferner Folgendes umfasst: ein Strategieentscheidungs-VM-Modul für, zumindest teilweise, das Management von Dienststrategie und -regeln im Zusammenhang mit dem mindestens einen UE.
Computerplattform nach Anspruch 9, welche ferner Folgendes umfasst: ein Teilnehmerdatenbank-VM-Modul für, zumindest teilweise, das Management von Profil- und Berechtigungsdaten im Zusammenhang mit dem mindestens einen UE.
Verfahren zum Virtualisieren eines EPC (Evolved Packet Core) eines drahtlosen Telekommunikationsnetzes auf eine Computerplattform, wobei die Computerplattform dem Austauschen von Befehlen und Daten im Zusammenhang mit mindestens einem Nutzergerät (UE) in Kommunikation mit der Computerplattform und zum Austauschen von Befehlen und Daten im Zusammenhang mit einem Netzwerk in Kommunikation mit der Computerplattform dient, wobei das Verfahren Folgendes umfasst: Erzeugen eines Signalisierungs-VM-Moduls für, zumindest teilweise, das Zustandsmanagement von mindestens einem UE; das Erzeugen eines Netzwerk/Routing-Management-VM-Moduls für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk; und das Erzeugen eines VM-Bereitstellungsmoduls für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit der Computerplattform und das Zuweisen der Hardwareressourcen zu mindestens entweder dem Signalisierungs-VM-Modul oder dem Netzwerk-/Routing-Management-VM-Modul; wobei das VM-Bereitstellungsmodul ferner dem Skalieren der Hardwareressourcen bereitgestellt an das Signalisierungs-VM-Modul oder das Netzwerk/Routing-Management-VM-Modul auf der Grundlage, zumindest teilweise, der Lastanforderungen des mindestens einen UE oder des Netzwerkes dient.
Verfahren nach Anspruch 14, welches ferner das Erzeugen eines Trägermanagement-VM-Moduls für, zumindest teilweise, das Trägermanagement des mindestens einen UE umfasst.
Verfahren nach Anspruch 14, welches ferner das Erzeugen eines Gerätezustandsdatenbank-Management-VM-Moduls für, zumindest teilweise, das Management von Gerätezustandsdaten im Zusammenhang mit dem mindestens einen UE umfasst.
Verfahren nach Anspruch 14, welches ferner das Erzeugen eines Strategieentscheidungs-VM-Moduls für, zumindest teilweise, das Management von Dienststrategie und -regeln im Zusammenhang mit dem mindestens einen UE umfasst.
Verfahren nach Anspruch 14, welches ferner das Erzeugen eines Teilnehmerdatenbank-VM-Moduls für, zumindest teilweise, das Management von Profil- und Berechtigungsdaten im Zusammenhang mit dem mindestens einen UE umfasst.
Computerplattformsystem zum Virtualisieren eines EPC (Evolved Packet Core) eines drahtlosen Telekommunikationsnetzwerkes auf eine Computerplattform, wobei die Computerplattform dem Austauschen von Befehlen und Daten im Zusammenhang mit mindestens einem Nutzergerät (UE) in Kommunikation mit der Computerplattform und zum Austauschen von Befehlen und Daten im Zusammenhang mit einem Netzwerk in Kommunikation mit der Computerplattform dient, wobei das Computerplattformsystem ein oder mehrere Speichergeräte umfasst, auf welchen, einzeln oder in Kombination, Befehle gespeichert sind, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, in den folgenden Operationen resultieren, welche Folgendes umfassen: das Erzeugen eines Signalisierungs-VM-Moduls für, zumindest teilweise, das Zustandsmanagement von mindestens einem UE; das Erzeugen eines Netzwerk/Routing-Management-VM-Moduls für, zumindest teilweise, das Leiten von Datenpaketen zwischen dem mindestens einen UE und dem Netzwerk; und das Erzeugen eines VM-Bereitstellungsmoduls für, zumindest teilweise, das Bereitstellen von Hardwareressourcen im Zusammenhang mit dem Computerplattformsystem und das Zuweisen der Hardwareressourcen zu mindestens entweder dem Signalisierungs-VM-Modul oder dem Netzwerk/Routing-Management-VM-Modul; wobei das VM-Bereitstellungsmodul ferner dem Skalieren der Hardwareressourcen bereitgestellt an das Signalisierungs-VM-Modul oder das Netzwerk/Routing-Management-VM-Modul auf der Grundlage, zumindest teilweise, der Lastanforderungen des mindestens einen UE oder des Netzwerkes dient.
Computerplattformsystem nach Anspruch 19, wobei die Befehle, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, in den folgenden zusätzlichen Operationen resultieren, welche Folgendes umfassen: das Erzeugen eines Trägermanagement-VM-Moduls für, zumindest teilweise, das Trägermanagement des mindestens einen UE.
Computerplattformsystem nach Anspruch 19, wobei die Befehle, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, in den folgenden zusätzlichen Operationen resultieren, welche Folgendes umfassen: das Erzeugen eines Management-VM-Moduls für, zumindest teilweise, das Management von Gerätezustandsdaten im Zusammenhang mit dem mindestens einen UE.
Computerplattformsystem nach Anspruch 19, wobei die Befehle, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, in den folgenden zusätzlichen Operationen resultieren, welche Folgendes umfassen: das Erzeugen eines Strategieentscheidungs-VM-Moduls für, zumindest teilweise, das Management von Dienststrategie und -regeln im Zusammenhang mit dem mindestens einen UE.
Computerplattformsystem nach Anspruch 19, wobei die Befehle, welche, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, in den folgenden zusätzlichen Operationen resultieren, welche Folgendes umfassen: das Erzeugen eines Teilnehmerdatenbank-VM-Moduls für, zumindest teilweise, das Management von Profil- und Berechtigungsdaten im Zusammenhang mit dem mindestens einen UE.