DE112020001183T5

DE112020001183T5 - Multi-slice-unterstützung für mec-fähige 5g-implementierungen

Info

Publication number: DE112020001183T5
Application number: DE112020001183.6T
Authority: DE
Inventors: Dario Sabella; Miltiadis Filippou
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-03-11
Filing date: 2020-03-10
Publication date: 2022-03-17
Also published as: WO2020185794A1; US20220086864A1; US11700628B2; US12047986B2; US20230403731A1

Abstract

Ein System, das konfiguriert ist, um Netzwerk-Slicing-Operationen innerhalb eines 5G-Kommunikationsnetzwerks zu verfolgen, beinhaltet Verarbeitungsschaltungen, die konfiguriert sind, um eine Netzwerk-Slice-Instanz (NSI) zu bestimmen, die einem QoS-Fluss eines UE zugeordnet ist. Der NSI kommuniziert Daten für eine Network Function Virtualization (NFV)-Instanz eines Multi-Access Edge Computing (MEC)-Systems innerhalb des 5G-Kommunikationsnetzwerks. Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen, die von dem NSI verwendet werden, werden abgerufen. Die Vielzahl von Kommunikationsverbindungen beinhaltet einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen, die dem MEC-System zugeordnet sind. Eine Slice-Konfigurationsrichtlinie wird basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI generiert. Die vom NSI verwendeten Netzwerkressourcen des 5G-Kommunikationsnetzwerks werden basierend auf der generierten Slice-Konfigurationsrichtlinie neu konfiguriert.

Description

PRIORITÄTSANSPRUCH
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldung mit der Seriennummer 62/816,616 , eingereicht am 11. März 2019, mit dem Titel „E2E MULTI-SLICE SUPPORT FOR MEC-ENABLED 5G DEPLOYMENTS“, deren Anmeldung hier durch Bezugnahme eingeschlossen ist in ihrer Gänze.
TECHNISCHEN BEREICH
Hierin beschriebene Ausführungsformen beziehen sich im Allgemeinen auf Datenverarbeitung, Netzwerkkommunikation und Kommunikationssystemimplementierungen und insbesondere auf Techniken zur Implementierung von End-to-End (E2E)-Unterstützung für Multi-Access-Edge-Computing (MEC)-fähige 5G-Bereitstellungen.
HINTERGRUND
Internet-of-Things (IoT)-Geräte sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktoren und andere Eingabe-/Ausgabekomponenten umfassen können, um beispielsweise Daten zu sammeln oder Aktionen aus der realen Umgebung auszuführen. IoT-Geräte können beispielsweise Endpunktgeräte mit geringem Stromverbrauch umfassen, die in alltägliche Dinge wie Gebäude, Fahrzeuge, Pakete usw. eingebettet oder daran angebracht sind, um eine zusätzliche Ebene der künstlichen sensorischen Wahrnehmung dieser Dinge bereitzustellen. In letzter Zeit sind IoT-Geräte immer beliebter geworden und daher haben sich Anwendungen, die diese Geräte verwenden, vermehrt.
Edge Computing bezieht sich auf einer allgemeineren Ebene auf die Verlagerung von Rechen- und Speicherressourcen näher an oder in intelligente Endgeräte, um die Gesamtbetriebskosten zu optimieren, die Anwendungslatenz zu reduzieren, die Servicefähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen zu verbessern. Edge Computing kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung für Anwendungen zwischen vielen Arten von Speicher- und Rechenressourcen bietet. Edge-Computing kann weiter in Anwendungsfälle und Technologien integriert werden, die für das IoT- und Fog-Networking entwickelt wurden, da Endpunktgeräte und Gateways versuchen, auf Netzwerkressourcen und -anwendungen an Standorten zuzugreifen, die näher am „Edge“ (Rand) des Netzwerks liegen.
MEC umfasst Architekturen, die Cloud-Computing-Funktionalität oder Informationstechnologie-(IT-)Dienste an den Netzwerkrändern (z.B. Mobilfunknetzen) ermöglichen. MEC kann eine Netzwerküberlastung reduzieren, indem Anwendungen, Daten, Erkennung usw. näher an den Benutzer (z.B. Mobilgerät, Benutzergerät (UE), Station (STA) usw.) verschoben werden. Einige MEC-Details, die sich mit Sicherheit (z.B. sowohl Benutzersicherheit als auch Anwendungsintegrität), Funknutzung usw. befassen, wurden vom European Telecommunications Standards Institute (ETSI) veröffentlicht, wie z.B. im „Mobile Edge Computing Introductory Technical White Paper“ beschrieben “, veröffentlicht am 1. September 2014. Eine Reihe von Spezifikationen und Whitepapers mit weiteren Details und Anwendungsfällen für die Implementierung von MEC-Szenarien wird von ETSI als Teil der ETSI MEC Industry Specification Group (ISG) kontinuierlich entwickelt und veröffentlicht.
Die MEC-Umgebung zeichnet sich durch extrem niedrige Latenz und hohe Bandbreite sowie Echtzeitzugriff auf Funknetzinformationen aus, die von Anwendungen genutzt werden können. Die MEC-Technologie ermöglicht es Betreibern, innovative Anwendungen und Dienste für Mobilfunkteilnehmer, Unternehmen und vertikale Segmente flexibel und schnell bereitzustellen. MEC soll die Entwicklung mobiler Anwendungsfälle von Edge-Computing unterstützen, um Anwendungsentwicklern und Inhaltsanbietern den Zugriff auf Rechenkapazitäten und eine IT-Service-Umgebung in dynamischen Umgebungen am Rand des Netzwerks zu ermöglichen. In diesen und anderen Umgebungen versucht Edge Computing, eine reduzierte Latenz, eine erhöhte Reaktionsfähigkeit und mehr verfügbare Rechenleistung zu bieten, als sie in herkömmlichen Cloud-Netzwerkdiensten und Weitverkehrsnetzverbindungen angeboten wird. Trotz der rasanten Aktivität bei der Entwicklung von Standards und Architekturen, die diese Technologien einbeziehen, gibt es immer noch viele Einschränkungen und technische Probleme beim Design und der Verwendung von IoT, MEC und Edge-Netzwerken der nächsten Generation.
Figurenliste
In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu sind, können gleiche Bezugszeichen ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen:

1A eine MEC-Kommunikationsinfrastruktur mit einem gemeinsamen Kernnetzwerk veranschaulicht, wobei die MEC-Infrastruktur gemäß einem Beispiel Slice-Management, Ressourcenmanagement und Rückverfolgbarkeitsfunktionen umfasst;
1B einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing gemäß einem Beispiel veranschaulicht;
2A eine beispielhafte zellulare Internet-of-Things-(CIoT)-Netzwerkarchitektur mit einem MEC-Host unter Verwendung eines MEC-QoS-Managers gemäß einem Beispiel veranschaulicht;
2B eine beispielhafte Service Capability Exposure Function (SCEF), die von der CIoT-Netzwerkarchitektur von 2A verwendet wird, gemäß einem Beispiel veranschaulicht;
3A ein vereinfachtes Diagramm einer beispielhaften Systemarchitektur der nächsten Generation (NG) mit einem MEC-Host mit einem MEC-QoS-Manager, nach einem Beispiel ist;
3B eine beispielhafte funktionale Aufteilung zwischen dem Funkzugangsnetz der nächsten Generation (NG-RAN) und dem SG-Kernnetz (5GC) in Verbindung mit der NG-Systemarchitektur von 3A nach einem Beispiel veranschaulicht;
3C und 3D SG-Systemarchitekturen ohne Roaming mit einem MEC-Host unter Verwendung von Ressourcenmanagement- und Rückverfolgbarkeitsfunktionen nach einem Beispiel darstellen;
3E Komponenten einer beispielhaften 5G-NR-Architektur mit einer Trennung von Steuereinheit-Steuerebene (CU-CP) - Steuereinheit-Benutzerebene (CU-UP) gemäß einem Beispiel veranschaulicht;
3F einen Protokollstapel auf Benutzerebene gemäß einem Beispiel veranschaulicht;
3G Beispiele von Netzwerk-Slices gemäß einem Beispiel veranschaulicht;
4A eine MEC-Netzwerkarchitektur, die zum Unterstützen von Slice-Management-, Ressourcen-Management- und Verfolgbarkeitsfunktionen modifiziert ist, gemäß einem Beispiel veranschaulicht;
4B eine MEC-Referenzarchitektur in einer Network Function Virtualization (NFV)-Umgebung gemäß einem Beispiel veranschaulicht;
5 eine MEC- und FOG-Netzwerktopologie gemäß einem Beispiel veranschaulicht;
6 die Verarbeitungs- und Speicherschichten in einem MEC- und FOG-Netzwerk gemäß einem Beispiel veranschaulicht;
7 eine Domänentopologie für jeweilige Internet-of-Things-(IoT)-Netzwerke, die über Links mit jeweiligen Gateways gekoppelt sind, gemäß einem Beispiel veranschaulicht;
8 ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von Computergeräten, die als Fog-Geräte am Rand des Cloud-Computing-Netzwerks arbeiten, gemäß einem Beispiel veranschaulicht;
9 ein Blockdiagramm eines Cloud-Computing-Netzwerks in Kommunikation mit mehreren Computergeräten gemäß einem Beispiel veranschaulicht;
10A eine Übersicht über beispielhafte Komponenten, die in einem Rechenknotensystem bereitgestellt werden, gemäß einem Beispiel veranschaulicht;
10B eine weitere Übersicht über Beispielkomponenten innerhalb eines Computergeräts zum Implementieren der hierin beschriebenen Techniken (z.B. Operationen, Prozesse, Verfahren und Methodiken) gemäß einem Beispiel veranschaulicht;
11 eine 3GPP-basierte 5G-Systemarchitektur und ein Beispiel der Abbildung von MEC- Entitäten auf einige der 5G-Systemkomponenten (nämlich AF und UPF) gemäß einem Beispiel veranschaulicht;
12 Aspekte der offenbarten Techniken für die E2E-Mehr-Slice-Unterstützung für MEC-fähige 5G-Bereitstellungen gemäß einem Beispiel veranschaulicht;
13 ein Flussdiagramm offenbarter Techniken für die Slice-bewusste VM-Zuweisung in MEC-fähigen 5G-Systembereitstellungen gemäß einem Beispiel veranschaulicht;
14 ein Nachrichtensequenzdiagramm ist, das die verschiedenen Latenzkomponenten während der direkten Kommunikation zwischen einem UE-Client und einer MEC-App am Edge (die einige auf der MEC-Plattform ausgeführte MEC-Dienste konsumiert) gemäß einem Beispiel veranschaulicht;
15 ein Nachrichtensequenzdiagramm ist, das eine beispielhafte Kommunikation zum Ableiten und Implementieren einer Slice-bewussten VM-Zuweisungsrichtlinie gemäß einem Beispiel veranschaulicht; und
16A - 16H verschiedene Beispiel- und Implementierungsaspekte von hierin offenbarten Techniken veranschaulichen.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden Verfahren, Konfigurationen und zugehörige Vorrichtungen offenbart für die Unterstützung für Multi-Slice-Unterstützung für MEC-fähige 5G-Bereitstellungen. Als Überblick integrieren die hierin offenbarten technologischen Lösungen MEC mit verschiedenen Arten von Implementierungen sowie dynamisches Netzwerk-Slicing und Ressourcennutzungsmanagement. Diese können einer Vielzahl von Anwendungsfällen zugutekommen, wie der Netzwerkkommunikation der fünften Generation (5G) zwischen Fahrzeuggeräten, einschließlich der Anwendungsfälle, die als Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Infrastruktur (V21) und Fahrzeug- zu-alles (V2X). Wie bei den meisten MEC-Installationen besteht das Ziel bei den vorliegenden Konfigurationen darin, die Anwendungsendpunkte so nah wie möglich an die Fahrzeugumgebung oder andere Endpunkte zu bringen und die Rechenressourcen sowie die von einem oder mehreren Netzwerk- (etwa 5G-)Slices verwendeten Ressourcen dynamisch anzupassen, um Dienste mit geringer Latenz oder hoher Bandbreite mit optimaler QoS zu ermöglichen. Diese Systeme und Techniken können in virtualisierten Umgebungen implementiert oder erweitert werden, die in verschiedenen Arten von MEC, Netzwerkfunktionsvirtualisierung (NFV) oder vollständig virtualisierten 5G-Netzwerkumgebungen implementiert werden können.
Wie es hier verstanden wird, bieten MEC-Architekturen Anwendungsentwicklern und Inhaltsanbietern Cloud-Computing-Funktionen und eine IT-Service-Umgebung am Rand des Netzwerks. Diese Umgebung bietet eine extrem niedrige Latenz und einen hohen Bandbreitendurchsatz sowie Echtzeitzugriff auf Funknetzinformationen, die von Anwendungen genutzt werden können. Die MEC-Technologie ermöglicht eine flexible und schnelle Bereitstellung innovativer Anwendungen und Dienste für Mobilfunkteilnehmer, Unternehmen oder vertikale Segmente.
Die vorliegenden Techniken und Konfigurationen können in Verbindung mit vielen Aspekten aktueller Netzwerksysteme verwendet werden, werden jedoch unter Bezugnahme auf IoT-, MEC- und NFV-Implementierungen bereitgestellt. Die vorliegenden Techniken und Konfigurationen können speziell (müssen aber nicht) relevant sein für die Standards und Ansätze, die in ETSI GS MEC-003 „Mobile Edge Computing (MEC); Framework and Reference Architecture“ (z.B. V2.0.3); ETSI GR MEC-024 „Unterstützung für Netzwerk-Slicing“; ETSI GS NFV-SEC 013 „Network Functions Virtualization (NFV) Release 3; Security; Security Management and Monitoring“ (z.B. v. 3.1.1) und zugehörigen MEC, NFV oder vernetzten Betriebsimplementierungen veröffentlicht sind. Während die vorliegenden Techniken und Konfigurationen jedoch MEC-Architekturen und anderen IoT-Gerätenetzwerkarchitekturen erhebliche Vorteile bieten können, kann die Anwendbarkeit der vorliegenden Techniken und Konfigurationen auf eine beliebige Anzahl von Edge-Computing-Geräten oder Fog-Computing-Plattformen ausgedehnt werden.
Im Folgenden werden diese Techniken innerhalb bestimmter Systeme und Dienste ausführlich erläutert, die jedoch auf den größeren Kontext von IoT-, Fog-Netzwerk- und Edge-Computing-Bereitstellungen zutreffen. Ferner stellen die offenbarten MEC-Architekturen und Dienstbereitstellungsbeispiele ein veranschaulichendes Beispiel eines Fog-Geräts oder eines Fog-Systems bereit, aber viele andere Kombinationen und Anordnungen von Vorrichtungen und Systemen, die sich am Rand eines Netzwerks befinden, können bereitgestellt werden. Ferner können sich die hierin offenbarten Techniken auf andere IoT- und 5G-Netzwerkkommunikationsstandards und -konfigurationen und andere zwischengeschalteteProzessierungsentitäten und Architekturen beziehen.
Die hierin offenbarten Techniken konzentrieren sich auf die Rolle von Multi-Access Edge Computing (MEC) bei der Unterstützung von 5G-Netzwerk-Slicing. In einigen Aspekten können hierin offenbarte Techniken verwendet werden, um E2E-Latenzanforderungen eines Netzwerk-Slice zu erreichen und zu garantieren, wenn sie in MEC-fähigen 5G-Implementierungen unter Verwendung einer Slice Control Function (SCF) innerhalb einer Network Function Virtualization (NFV)-Domäne (auch bezeichnet als NFV-SCF) instanziiert werden. Die diskutierten Kommunikationssysteme beinhalten ein MEC-System, dessen Architektur (einschließlich der verschiedenen MEC-bezogenen Schnittstellen und Referenzpunkte) in ETSI GS MEC-003 und ETSI GR MEC-024 spezifiziert ist, eingesetzt in einem 5G-System (das virtualisiert sein kann oder nicht), deren Systemarchitektur mindestens in 3GPP TS 23.501 spezifiziert ist. In einigen Aspekten kann das 5G-System vollständig virtualisiert sein, wobei alle logischen Funktionen (d.h. Netzwerkfunktionen (NFs) und auch Anwendungsfunktionen (AFs)) virtualisiert werden. Verschiedene hier diskutierte MEC-bezogene Schnittstellen und Referenzpunkte werden in den folgenden ETSI-bezogenen technischen Spezifikationen näher definiert: Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024.
Genauer gesagt ist das NFV-SCF dazu konfiguriert, eine E2E-Latenzfunktionsmodellierung und -bewertung unter Verwendung von Latenzinformationen durchzuführen, die von Netzwerkverwaltungsknoten des 5G-Systems sowie des MEC-Systems erhalten wurden, und Verzögerungsengpässe im Zusammenhang mit E2E-Kommunikationen innerhalb eines Netzwerkabschnitts zu identifizieren. Der NFV-SCF generiert außerdem eine Slice-Konfigurationsrichtlinie, um die Instanziierung von MEC-Anwendungen (Apps) und der Zuweisung virtualisierter Ressourcen (z.B. virtuelle Maschinen oder VMs) in der Edge-Cloud gemäß einer Slice-aware-Strategie basierend auf der E2E-Latenzfunktionsmodellierung und -bewertung zu optimieren. In dieser Hinsicht kann die NFV-SCF verwendet werden, um Netzwerkressourcen, die von Netzwerk-Slice-Instanzen verwendet werden, dynamisch zu überwachen und neu zu konfigurieren, um die E2E-Leistungsanforderungen der Slice zu erfüllen (die Teil einer Service Level Agreement (SLA) zwischen dem Netzwerkbetreiber und einer vertikalen Industrie sein kann).
1A veranschaulicht eine MEC-Kommunikationsinfrastruktur 100A mit einem gemeinsamen Kernnetzwerk, wobei die MEC-Infrastruktur gemäß einem Beispiel Slice-Management, Ressourcenmanagement und Rückverfolgbarkeitsfunktionen umfasst. Die Verbindungen, die durch irgendeine Form einer gestrichelten Linie dargestellt sind (wie in der Legende in 1A angegeben) können gemäß einer Spezifikation aus einer ETSI MEC-Standardfamilie definiert sein.
Die MEC-Kommunikationsinfrastruktur 100A kann Entitäten aus einer MECbasierten Architektur sowie Entitäten aus einer auf Partnerschaftsprojekten (3GPP) basierenden Architektur der dritten Generation umfassen. Zum Beispiel kann die MEC-Kommunikationsinfrastruktur 100A eine Vielzahl von MEC-Hosts beinhalten, wie etwa die MEC-Hosts 102 und 104, einen MEC-Plattformmanager 106 und einen MEC-Orchestrator 108. Die 3GPP-basierten Entitäten können ein zentralisiertes Kernnetz (CN) 110 umfassen, das über das Netz 112 (z.B. das Internet) mit einem Anwendungsserver 114 gekoppelt ist, sowie Funkzugangsnetze (RANs), die durch Basisstationen 148 und 150 dargestellt werden, die mit entsprechenden Benutzergeräten (UEs) 152 und 154 verbunden sind. Die Basisstationen 148 und 150 können weiterentwickelte Node-Bs (eNBs), Next Generation Node-Bs (gNBs) oder andere Arten von Basisstationen umfassen, die in Verbindung mit einer 3GPP-Funkstandardfamilie oder einer anderen Art von Funkstandard arbeiten.
In einigen Aspekten kann die MEC-Kommunikationsinfrastruktur 100A von verschiedenen Netzbetreibern im selben Land und/oder in verschiedenen Ländern unter Verwendung verschiedener Netzverkehrstypen implementiert sein. Zum Beispiel kann das der Basisstation 148 (mit einem Abdeckungsbereich 149) zugeordnete Funkzugangsnetz innerhalb eines ersten öffentlichen Landmobilnetzes (PLMN) sein (d.h., einem ersten Mobilfunkanbieter oder -betreiber und einem ersten Netzverkehrstyp zugeordnet) sein., und die Basisstation 150 (mit einem Abdeckungsbereich 151) kann sich innerhalb eines zweiten öffentlichen Land-Mobilfunknetzes (PLMN) befinden (d.h., einem zweiten Mobilfunkdienstanbieter oder -betreiber und einem zweiten Netzverkehrstyp zugeordnet). Die hier verwendeten Begriffe „Anbieter von Mobilfunkdiensten“ und „Betreiber von Mobilfunkdiensten“ sind austauschbar..
In dieser Hinsicht kann die MEC-Kommunikationsinfrastruktur 100A einem Multi-Operator-Szenario zugeordnet sein, das aus zwei Abdeckungsgebieten 149 und 151 besteht, in denen Kommunikationsdienste (z.B. V2X-Dienste) bereitgestellt werden können, wobei jedes Abdeckungsgebiet von einem Mobilfunkbetreiber betrieben wird. Außerdem kann jedes der UEs 152 und 154 für den Netzwerk-Slice-Betrieb konfiguriert werden, wobei jedes UE einen oder mehrere Typen von Netzwerk-Slice-Instanzen verwenden kann, die z.B. durch das Kernnetzwerk 110 unter Verwendung der Slice-Verwaltungsfunktionalität 164 in Koordination mit einem oder mehr Entitäten der MEC-Kommunikationsinfrastruktur 100A, wie etwa die MEC-Netzwerkfunktionsvirtualisierungs-(NFV-)Slice-Control-Funktion (SCF) (MEC-NFV-SCF) (z.B. 121 und 131). Hierin offenbarte Techniken können verwendet werden, um E2E-Mehrschichtunterstützung für MEC-fähige 5G-Implementierungen unter Verwendung des MEC NFV-SCF bereitzustellen. In einigen Aspekten kann sich das MEC NFV-SCF 121 in einem NFV Orchestrator (NFVO) 160 befinden, der mit dem MEC Orchestrator 108 sowie mit anderen MEC- Entitäten gekoppelt sein kann, wie in 4B, 11 und 12 dargestellt.
Die durchgezogenen Linienverbindungen in 1A stellen Nicht-MEC-Verbindungen (oder Referenzpunkte) dar, wie beispielsweise die Verwendung von 3GPP-Mobilfunknetzverbindungen S1, S1-AP usw. Andere Verbindungstechniken (z.B. Protokolle) und Verbindungen können ebenfalls verwendet werden. Dementsprechend sind in dem Szenario von 1A die MEC-Systementitäten (z.B. der MEC-Orchestrator 108, der MEC-Plattformmanager 106, die MEC-Hosts 102, 104) durch logische MEC-(oder NFV-)Links (durch gestrichelte Linien gekennzeichnet) verbunden, zusätzlich zu Netzwerkinfrastruktur-Links (z.B. ein 5G-Long-Term-Evolution-(LTE)-Netzwerk, wie es unter den UEs 152, 154, eNBs 148, 150, einem CN-Standort 110 usw. bereitgestellt wird (mit durchgezogenen Linien angezeigt). Eine weitere Verbindung zu Cloud-Diensten (z.B. Zugriff auf einen Anwendungsserver 114 über das Netzwerk 112) kann auch über Backhaul-Netzwerkinfrastrukturverbindungen verbunden sein.
Hierin offenbarte Techniken gelten für 2G/3G/4G/LTE/LTE-A (LTE Advanced) und 5G-Netzwerke, wobei die offenbarten Beispiele und Aspekte 4G/LTE-Netzwerke verwenden. In einigen Aspekten kann das CN 110 ein weiterentwickeltes Paketkern-(EPC-)Netz, ein NextGen-Paketkern-(NPC-)Netz (z.B. ein 5G-Netz) oder eine andere Art von CN sein (z.B. wie unter Bezugnahme auf 2A-3E). In einem EPC (Evolved Packet Core), der 4G/LTE zugeordnet ist, kann das CN 110 ein Serving Gateway (S-GW oder SGW) 138, ein Paketdatennetzwerk (PDN) Gateway (P-GW oder PGW) 140, eine Mobilitätsverwaltungseinheit (mobility management entity, MME) 142 und einen Heimatteilnehmerserver (HSS) 144 enthalten, die mit einer V2X-Steuerungsfunktion 146 gekoppelt sind. Bei 5G wird das Kernnetzwerk als NextGen Packet Network (NPC) bezeichnet. In NPC (und wie in 3A-3D dargestellt) wird das S/P-GW durch eine Benutzerebenenfunktion (UPF) ersetzt und die MME wird durch zwei einzelne Funktionskomponenten ersetzt, die Zugriffsverwaltungsfunktion (AMF) und die Sitzungsverwaltungsfunktion (SMF). Das 4G HSS ist bei 5G in verschiedene Entitäten aufgeteilt: die Authentication Server Function (AUSF) und das Universal Data Management (UDM), wobei die Abonnementdaten über die Universal Data Management (UDM)-Funktion verwaltet werden. In EPC kann die S1-Schnittstelle in zwei Teile aufgeteilt werden: die S1-U-Schnittstelle (Benutzerebene), die Verkehrsdaten zwischen den eNBs 148, 150 und dem S-GW 138 über die MEC-Hosts 102, 104 überträgt, und die S1- AP-Schnittstelle (Steuerungsebene), die eine Signalisierungsschnittstelle zwischen den eNBs 148, 150 und der MME 142 ist.
Die MME 142 kann in ihrer Funktion der Steuerebene von Legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN) ähnlich sein. Die MME 142 kann Mobilitätsaspekte beim Zugriff verwalten, wie etwa die Gateway-Auswahl und die Verfolgungsbereichslistenverwaltung (tracking area list). Das HSS 144 kann eine Datenbank für Netzwerkbenutzer umfassen, einschließlich Abonnement-bezogener Informationen, um die Handhabung von Kommunikationssitzungen durch die Netzwerkentitäten zu unterstützen, einschließlich Abonnementinformationen, die mit V2X-Kommunikationen verbunden sind. Der CN 110 kann einen oder mehrere HSS 144 umfassen, abhängig von der Anzahl der Mobilfunkteilnehmer, von der Kapazität der Ausrüstung, von der Organisation des Netzwerks, usw. Zum Beispiel kann der HSS 144 Unterstützung für Routing/Roaming, Authentifizierung, Autorisierung (z.B. V2X-Kommunikationsautorisierung), Namens-/Adressierungsauflösung, Standortabhängigkeiten usw. bereitstellen.
Das S-GW 138 kann die S1-Schnittstelle 413 in Richtung der RANs der eNBs 148, 150 terminieren und Datenpakete zwischen den RANs und dem CN 110 routen. Außerdem kann das S-GW 138 ein lokaler Mobilitätsankerpunkt für Inter-RAN-Knoten-Handovers sein und kann auch einen Anker für Inter-3GPP-Mobilität bereitstellen. Andere Zu den weiteren Aufgaben können das Aufladen und die Durchsetzung einiger Richtlinien gehören.
Das P-GW 140 kann eine SGi-Schnittstelle zu einem PDN terminieren. Das P-GW 140 kann Datenpakete zwischen den RANs und externen Netzwerken wie einem Netzwerk, das den Anwendungsserver (AS) 114 (alternativ als Anwendungsfunktion (AF) bezeichnet) enthält, über eine Internetprotokoll-(IP)-Schnittstelle (z.B. eine Schnittstelle zum Netzwerk 112, das mit dem AS 114 gekoppelt ist) routen. Das P-GW 140 kann auch Daten an andere externe Netze übermitteln, die das Internet, ein IP-Multimedia-Subsystem-(IPS)-Netz und andere Netze umfassen können. Im Allgemeinen kann der Anwendungsserver 114 ein Element sein, das Anwendungen anbietet, die IP-Trägerressourcen mit dem Kernnetz verwenden (z.B. UMTS-Paketdienste(PS)-Domäne, LTE-PS-Datendienste usw.). Der Anwendungsserver 114 kann auch konfiguriert sein, um einen oder mehrere Kommunikationsdienste (z.B. Voice-over-Internet Protocol (VoIP)-Sitzungen, PTT-Sitzungen, Gruppenkommunikationssitzungen, soziale Netzwerkdienste usw.) für die UEs 152, 154 über dem CN 110 und einem oder mehreren der MEC-Hosts 102, 104 zu unterstützen.
Das P-GW 140 kann ferner einen Knoten zur Richtliniendurchsetzung und zur Erhebung von Gebührendaten umfassen. Eine Policy and Charging Enforcement Function (PCRF) (in 1A) kann das Regel- und Gebührensteuerelement des CN 110 sein. In einem Nicht-Roaming-Szenario kann es eine einzelne PCRF in dem Home Public Land Mobile Network (HPLMN) geben, die einer Sitzung des Internet Protocol Connectivity Access Network (IP-CAN) eines UE zugeordnet ist. In einem Roaming-Szenario mit einer lokalen Unterbrechung des Verkehrs können zwei PCRFs mit einer IP-CAN-Sitzung eines UE verknüpft sein: ein Home-PCRF (H-PCRF) innerhalb eines HPLMN und ein Visited PCRF (V-PCRF) innerhalb eines besuchten öffentlichen Landes Mobilfunknetz (VPLMN). Die PCRF kann über das P-GW 140 kommunikativ an den Anwendungsserver 114 gekoppelt sein. Der Anwendungsserver 114 kann der PCRF signalisieren, einen neuen Dienstfluss anzuzeigen und die geeignete Dienstgüte (QoS) und Gebührenparameter auszuwählen.
Die V2X-Steuerungsfunktion 146 wird in Verbindung mit der Autorisierung von UEs verwendet, um V2X-Dienste basierend auf HSS-Informationen (z.B. vom HSS 144 verwaltete Abonnementinformationen) zu verwenden, um eine oder mehrere UEs beim Erhalten der Netzwerkadresse eines Anwendungsservers (z.B. 114) oder eines V2X-Anwendungsservers zu unterstützen sowie die Bereitstellung von V2X-Konfigurationsparametern für die direkte Kommunikation (d.h., die Kommunikation von Gerät zu Gerät). Die Schnittstelle für die direkte Kommunikation von Gerät zu Gerät wird als PC5 bezeichnet. Die PC5-Parameter können von der V2X-Steuerungsfunktion 146 einem oder mehreren UEs bereitgestellt werden, um die V2X-Kommunikation zwischen den UEs zu konfigurieren.
Die Slice-Verwaltungsfunktion 164 kann zum Konfigurieren einer oder mehrerer Netzwerk-Slice-Instanzen (NSIs) (z.B. 5G-Slices oder 5G-NSIs) zur Verwendung durch UEs oder andere Geräte innerhalb der Kommunikationsarchitektur 100A verwendet werden, wobei die Slice-Konfiguration möglicherweise mit Hilfe des MEC NFV-SCF (z.B. 121 und 131) erfolgen kann, wie hierin diskutiert.
Die MEC-Hosts 102, ..., 104 können gemäß den Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024 konfiguriert sein. Der MEC-Host 102 kann eine MEC-Plattform 118 beinhalten, die an eine oder mehrere MEC-Anwendungen (Apps) wie etwa MEC-Apps 116A, ..., 116N (zusammen die MEC-App 116) und an eine MEC-Datenebene 122 gekoppelt sein kann. Der MEC-Host 104 kann eine MEC-Plattform 126 beinhalten, die mit einer MEC-App 116 und einer MEC-Datenebene 130 gekoppelt sein kann. Der MEC-Plattformmanager 106 kann ein MEC-Plattformelementverwaltungsmodul 132, ein MEC-Anwendungsregel- und Anforderungsverwaltungsmodul 134 und ein MEC-Anwendungslebenszyklusverwaltungsmodul 136 beinhalten. Der MEC-Host 102 beinhaltet auch MEC-Hardware 123, wie etwa Netzwerkschnittstellen (z.B. Netzwerkschnittstellenkarten oder NICs) 125A, ..., 125N, eine oder mehrere CPUs 127 und Speicher 129. Eine zusätzliche Beschreibung der MEC-bezogenen Entitäten 102, 104, 106 und 108 wird im Folgenden in Verbindung mit . 4A und 4A und 4B bereitgestellt.
In einigen Aspekten können die MEC-Apps 116A, ..., 116N jeweils eine NFV-Instanz bereitstellen, die dazu konfiguriert ist, Netzwerkverbindungen zu verarbeiten, die einem bestimmten Netzwerkverkehrstyp (z.B. 2G, 3G, 4G, 5G oder ein anderer Netzwerkverkehrstyp) zugeordnet sind, der einem UE Dienstgüte (QoS)-Fluss für eine Netzwerk-Slice-Instanz zugeordnet ist. In diesem Zusammenhang werden die Begriffe „MEC-App“ und „NFV“ (oder „MEC NFV“) synonym verwendet. Außerdem werden die Begriffe „NFV“ und „NFV-Instanz“ austauschbar verwendet. Die MEC-Plattform 118 kann ferner einen oder mehrere Scheduler 120A, ..., 120N (zusammen einen Scheduler 120) umfassen. Jeder der Scheduler 120A, ..., 120N kann geeignete Schaltungen, Logik, Schnittstellen und/oder Code umfassen und ist konfiguriert, um die Instanziierung von NFVs (z.B. als MEC-Apps) 116A, ..., 116N (zusammen ein NFV 116) zu verwalten. Insbesondere kann ein Scheduler 120 eine CPU (z.B. eine der CPUs 127) und/oder andere Netzwerkressourcen zum Ausführen/Instanziieren des NFV 116 auswählen. Da jedes der NFVs 116A, ..., 116N mit der Verarbeitung eines anderen Netzwerkverkehrstyps verknüpft ist, kann der Scheduler 120 außerdem eine NIC (z.B. aus den verfügbaren NICs 125A, ..., 125N) zur Verwendung durch das NFV 116 auswählen. Jeder der Scheduler 120A, ..., 120N kann einen anderen Typ von SLA- und QoS-Anforderungen aufweisen, basierend auf dem Netzwerkverkehrstyp, der von dem zugehörigen NFV verarbeitet wird. Zum Beispiel hat jeder Verkehrstyp (z.B. 2G, 3G, 4G, 5G oder jeder andere Typ einer drahtlosen Verbindung zum MEC-Host) eine zugeordnete Dienstklasse (CloS) (z.B. 2G_low, 2G_mid, 2G_high usw.), die im MEC-Host vorkonfiguriert werden kann und CloS-spezifische Ressourcenanforderungen (d.h., E/A, Speicher, Verarbeitungsleistung usw.) für verschiedene Lasten dieses bestimmten Verkehrstyps definieren.
1A stellt ferner den MEC-Host 104 dar, der die MEC-Hardware 133, ein MEC-NFV-SCF 131 und die Scheduler 128A, ..., 128N umfasst, die die gleiche Funktionalität wie die MEC-Hardware 123 haben können, das MEC NFV-SCF 121 und den im Zusammenhang mit dem MEC-Host 102 beschriebenen Schedulern 120A, ..., 120N,. Obwohl das MEC NFV-SCF 121 als in der MEC-Plattform 118 implementiert dargestellt ist, ist die vorliegende Offenbarung diesbezüglich nicht beschränkt und eine oder mehrere Komponenten des MEC NFV-SCF 121 können in anderen Modulen des MEC-Hosts 102 (wie die MEC-Datenebene 122), eine Netzwerkfunktions-Virtualisierungsinfrastruktur, einem Netzwerkfunktions-Virtualisierungs-Orchestrator (z.B. NFVO 160), dem MEC-Orchestrator 108, dem MEC-Plattform-Manager 106 oder einer anderen Entität innerhalb der Architektur 100A oder als eigenständiger Knoten implementiert werden.
In einigen Aspekten kann die MEC-Architektur 100A (oder eine der hierin erörterten MEC-Architekturen) konfiguriert sein, um Funktionalitäten gemäß der ETSI GS MEC-003-Spezifikation, der ETSI GR MEC-024-Spezifikation und/oder der ETSI GR MEC-017-Spezifikation bereitzustellen.
1B ist ein Blockdiagramm 100B, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht umfasst, die in vielen der aktuellen Beispiele als „Edge-Cloud“ bezeichnet wird. Diese Netzwerktopologie, die mehrere herkömmliche Netzwerkschichten (einschließlich der hier nicht gezeigten) umfassen kann, kann durch die Verwendung von E2E-Multi-Slice-Unterstützung zum Konfigurieren von Netzwerkressourcen, die mit Netzwerk-Slice-Instanzen (NSIs) in MEC-fähigen 5G-Kommunikationssystemen verbunden sind, erweitert werden, um die Instanziierung von MEC-Apps und virtualisierten Ressourcen im Zusammenhang mit dem NSI zu optimieren.
Wie gezeigt, befindet sich die Edge-Cloud 110B an einem Edge-Standort, wie etwa der Basisstation 140B, einem lokalen Verarbeitungs-Hub 150B oder einer Zentrale 120B und kann somit mehrere Entitäten, Geräte und Ausrüstungsinstanzen umfassen. Die Edge-Cloud 110B befindet sich viel näher an den Endpunktdatenquellen (Verbraucher und Hersteller) 160B (z.B. autonome Fahrzeuge 161B, Benutzergeräte 162B, Geschäfts- und Industriegeräte 163B, Videoaufnahmegeräte 164B, Drohnen 165B, intelligente Städte und Gebäudegeräte 166B, Sensoren und IoT-Geräte 167B usw.) als das Cloud-Rechenzentrum 130B. Rechen-, Arbeitsspeicher- und Speicherressourcen, die an den Edges in der Edge-Cloud 110B angeboten werden, sind entscheidend für die Bereitstellung extrem niedriger Latenz-Antwortzeiten für Dienste und Funktionen, die von den Endpunkt-Datenquellen 160B verwendet werden, sowie für die Reduzierung des Netzwerk-Backhaul-Datenverkehrs von der Edge-Cloud 110B in Richtung Cloud-Rechenzentrum 130, wodurch neben anderen Vorteilen der Energieverbrauch und die Gesamtnetznutzung verbessert werden.
Rechenleistung, Arbeitsspeicher und Speicher sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (z.B. sind weniger Verarbeitungsressourcen an Verbraucherendpunktgeräten verfügbar als an einer Basisstation oder einer Zentrale). Je näher jedoch die Edge-Position am Endpunkt (z.B. UEs) liegt, desto mehr sind Platz und Leistung eingeschränkt. Somit versucht Edge Computing als allgemeines Entwurfsprinzip, die Anzahl der für Netzwerkdienste benötigten Ressourcen durch die Verteilung von mehr Ressourcen zu minimieren, die sowohl geografisch als auch in Bezug auf die Netzwerkzugriffszeit näher liegen.
Im Folgenden werden Aspekte einer Edge-Cloud-Architektur beschrieben, die mehrere potenzielle Implementierungen abdeckt und Einschränkungen anspricht, die einige Netzbetreiber oder Dienstanbieter in ihren Infrastrukturen haben können. Diese umfassen Variationen von Konfigurationen basierend auf dem Edge-Ort (weil beispielsweise Edges auf Basisstationsebene eine stärker eingeschränkte Leistung aufweisen können); Konfigurationen basierend auf der Art von Rechenleistung, Arbeitsspeicher, Speicher, Fabric, Beschleunigung oder ähnlichen Ressourcen, die für Edge-Standorte, Standortstufen oder Standortgruppen verfügbar sind; die Service-, Sicherheits-, Management- und Orchestrierungsfunktionen; und damit verbundene Ziele, um die Benutzerfreundlichkeit und Leistung der Enddienste zu erreichen.
Edge-Computing ist ein sich entwickelndes Paradigma, bei dem das Computing am oder näher am „Rand“ eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform, die in Basisstationen, Gateways, Netzwerkroutern oder anderen Geräten implementiert ist, die viel näher an Endpunktgeräten sind, die Daten produzieren und konsumieren. Beispielsweise können Edge-Gateway-Server mit Pools von Speicher- und Speicherressourcen ausgestattet sein, um Berechnungen in Echtzeit für Anwendungsfälle mit geringer Latenz (z.B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Geräte durchzuführen. Oder es können beispielsweise Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für die angeschlossenen Benutzergeräte direkt zu verarbeiten, ohne weitere Daten über Backhaul-Netzwerke zu übertragen. Oder als weiteres Beispiel kann die Netzwerkverwaltungshardware der Zentrale durch Rechenhardware ersetzt werden, die virtualisierte Netzfunktionen ausführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Geräte anbietet. Diese und andere Szenarien können die Verwendung einer Plattformressourcenverwaltung beinhalten, wie in der folgenden Diskussion bereitgestellt.
Im Gegensatz zur Netzwerkarchitektur von 1A sind herkömmliche Endpunktanwendungen (z.B. UE, Vehicle-to-Vehicle (V2V), Vehicle-to-Everything (V2X) usw.) auf lokale Geräte- oder Remote-Cloud-Datenspeicherung und -verarbeitung angewiesen, um Informationen auszutauschen und zu koordinieren. Eine Cloud-Datenanordnung ermöglicht eine langfristige Datenerfassung und -speicherung, ist aber nicht optimal für zeitlich stark schwankende Daten, wie z. B. eine Kollision, eine Ampelschaltung usw., und kann bei der Bewältigung von Latenzproblemen versagen..
Abhängig von den Echtzeitanforderungen in einem Kommunikationskontext kann eine hierarchische Struktur von Datenverarbeitungs- und Speicherknoten in einer Edge-Computing-Implementierung definiert werden. Eine solche Implementierung kann beispielsweise lokale Verarbeitung mit extrem niedriger Latenz, regionale Speicherung und Verarbeitung sowie Speicherung und Verarbeitung in einem Remote-Cloud-Rechenzentrum umfassen. Key Performance Indicators (KPIs) können verwendet werden, um festzustellen, wo Sensordaten am besten übertragen und wo sie verarbeitet oder gespeichert werden. Dies hängt typischerweise von der Abhängigkeit der Daten von der ISO-Schicht ab. Beispielsweise ändern sich Daten einer niedrigeren Schicht (PHY, MAC, Routing usw.) in der Regel schnell und werden besser lokal verarbeitet, um die Latenzanforderungen zu erfüllen. Daten höherer Schichten wie Daten der Anwendungsschicht sind in der Regel weniger zeitkritisch und können in einem Remote-Cloud-Rechenzentrum gespeichert und verarbeitet werden.
2A veranschaulicht eine beispielhafte zellulare Internet-of-Things-(CIoT)-Netzwerkarchitektur mit einem MEC-Host unter Verwendung eines MEC-QoS-Managers gemäß einem Beispiel. Bezugnehmend auf 2A kann die CIoT-Architektur 200A das UE 202 und das RAN 204 umfassen, die mit einer Vielzahl von Kernnetzwerkentitäten gekoppelt sind. In einigen Aspekten kann das UE 202 ein Maschinentyp-Kommunikations-(MTC)-UE sein. Die CIoT-Netzwerkarchitektur 200A kann ferner eine Mobilfunkvermittlungsstelle (MSC) 206, MME 208, einen bedienenden GPRS-Unterstützungsknoten (SGSN) 210, ein S-GW 212, ein IP-Short-Message-Gateway (IP-SM-GW) 214, ein Short Message Service-Service Center (SMS-SC)/Gateway Mobile Service Center (GMSC)/Interworking MSC (IWMSC) 216, MTC-Interworking-Funktion (MTC-IWF) 222, eine Service Capability Exposure Function (SCEF) 220, einen Gateway-GPRS-Unterstützungsknoten (GGSN)/Paket-GW (P-GW) 218, eine Gebührendatenfunktion (CDF)/Ladegatewayfunktion (CGF) 224, einen Heimatteilnehmerserver (HSS)/ein Heimatregister (HLR) 226, Kurznachrichtenentitäten (SME) 228, MTC-Autorisierungs-, Authentifizierungs- und Abrechnungsserver (MTC AAA) 230, einen Dienstfähigkeitsserver (SCS) 232 und Anwendungsserver (AS) 234 und 236 beinhalten. In einigen Aspekten kann die SCEF 220 konfiguriert sein, um Dienste und Fähigkeiten sicher bereitzustellen, die von verschiedenen 3GPP-Netzwerkschnittstellen bereitgestellt werden. Das SCEF 220 kann auch Mittel zum Auffinden der exponierten Dienste und Fähigkeiten bereitstellen sowie Zugriff auf Netzwerkfähigkeiten über verschiedene Netzwerkanwendungsprogrammierschnittstellen (z.B. API-Schnittstellen zum SCS 232).
2A veranschaulicht ferner verschiedene Referenzpunkte (oder Schnittstellen) zwischen verschiedenen Servern, Funktionen oder Kommunikationsknoten der CIoT-Netzwerkarchitektur 200A. Einige beispielhafte Referenzpunkte in Bezug auf MTC-IWF 222 und SCEF 220 umfassen Folgendes: Tsms (ein Referenzpunkt, der von einer Entität außerhalb des 3GPP-Netzwerks verwendet wird, um mit UEs zu kommunizieren, die für MTC über SMS verwendet werden), Tsp (ein Referenzpunkt, der von einem SCS verwendet wird, um mit der MTC-IWF-bezogenen Signalisierung auf der Steuerebene zu kommunizieren), T4 (eine Referenz zwischen MTC-IWF 222 und SMS-SC 216 im HPLMN verwendeter Punkt), T6a (ein zwischen SCEF 220 und MME 208 verwendeter Referenzpunkt), T6b (ein zwischen SCEF 220 und SGSN 210 verwendeter Referenzpunkt), T8 (ein Referenzpunkt, der zwischen dem SCEF 220 und dem SCS/AS 234, 236 verwendet wird), S6m (ein Referenzpunkt, der von MTC-IWF 222 verwendet wird, um HSS/HLR 226 abzufragen), S6n (ein Referenzpunkt, der vom MTC-AAA-Server 230 verwendet wird, um HSS/HLR 226 abzufragen) und S6t (ein Referenzpunkt, der zwischen SCEF 220 und HSS/HLR 226 verwendet wird).
In einigen Aspekten kann das UE 202 konfiguriert sein, um mit einer oder mehreren Entitäten innerhalb der CIoT-Architektur 200A über das RAN 204 (z.B. CloT RAN) gemäß einem Non-Access Stratum (NAS)-Protokoll und unter Verwendung einer oder mehrerer Funkzugangskonfigurationen, wie z. B. einer Schmalband-Luftschnittstelle, zu kommunizieren, die beispielsweise auf einer oder mehreren Kommunikationstechnologien, wie z. B. Orthogonal Frequency-Division Multiplexing (OFDM)-Technologie, basiert.. Der hier verwendete Begriff „CloT UE“ bezieht sich auf ein UE, das als Teil einer CIoT-Kommunikationsarchitektur zu CIoT-Optimierungen in der Lage ist.. In einigen Aspekten kann das NAS-Protokoll einen Satz von NAS-Nachrichten für die Kommunikation zwischen dem UE 202 und einer Mobile Management Entity (MME) 208 Evolved Packet System (EPS) und SGSN 210 unterstützen. In einigen Aspekten kann die CIoT-Netzwerkarchitektur 200A ein Paketdatennetzwerk, ein Betreibernetzwerk oder ein Cloud-Dienstnetzwerk umfassen, das beispielsweise unter anderem Server wie den Service Capability Server (SCS) 232, den AS 234, oder einen oder mehrere andere externe Server oder Netzwerkkomponenten aufweist.
Das RAN 204 kann mit den HSS/HLR-Servern 226 und den AAA-Servern 230 unter Verwendung eines oder mehrerer Referenzpunkte gekoppelt werden, einschließlich beispielsweise einer Luftschnittstelle basierend auf einem S6a-Referenzpunkt, und kann konfiguriert sein, um das CIoT-UE 202 fzu authentifizieren/autorisieren, auf das CloT-Netzwerk zuzugreifen. Das RAN 204 kann mit der CIoT-Netzwerkarchitektur 200A unter Verwendung eines oder mehrerer anderer Referenzpunkte gekoppelt werden, einschließlich beispielsweise einer Luftschnittstelle, die einer SGi/Gi-Schnittstelle für 3GPP-Zugriffe entspricht. Das RAN 204 kann mit dem SCEF 220 gekoppelt werden, indem zum Beispiel eine Luftschnittstelle basierend auf einem T6a/T6b-Referenzpunkt verwendet wird, um die Servicefähigkeit offenzulegen. In einigen Aspekten kann die SCEF 220 als ein API GW gegenüber einem Anwendungsserver eines Drittanbieters, wie etwa dem Server 234, fungieren. Das SCEF 220 kann unter Verwendung eines S6t-Referenzpunkts mit den Servern HSS/HLR 226 und MTC AAA 230 gekoppelt werden und kann ferner eine Anwendungsprogrammierschnittstelle Netzwerkfähigkeiten bereitstellen.
In bestimmten Beispielen können eines oder mehrere der hierin offenbarten CIoT-Geräte, wie das UE 202, das RAN 204 usw., ein oder mehrere andere Nicht-CIoT-Geräte oder Nicht-CIoT-Geräte umfassen, die als CIoT-Geräte fungieren oder Funktionen eines CIoT-Geräts aufweisen. Zum Beispiel kann das UE 202 ein Smartphone, einen Tablet-Computer oder ein oder mehrere andere elektronische Geräte umfassen, die als CIoT-Gerät für eine bestimmte Funktion fungieren, während es über andere zusätzliche Funktionen verfügt. In einigen Aspekten kann das RAN 204 einen CloT Enhanced Node B (CloT eNB) beinhalten, der kommunikativ mit einem CloT Access Network Gateway (CloT GW) gekoppelt ist. In bestimmten Beispielen kann das RAN 204 mehrere Basisstationen (z.B. CIoT-eNBs oder andere Arten von Basisstationen) beinhalten, die mit dem CloT GW verbunden sind, was MSC 206, MME 208, SGSN 210 oder S-GW 212 beinhalten kann. In bestimmten Beispielen kann die interne Architektur des RAN 204 und des CloT GW der Implementierung überlassen werden und muss nicht standardisiert werden.
In einigen Aspekten kann die CIoT-Architektur 200A einen oder mehrere MEC-Hosts umfassen, die eine Kommunikationsverbindung zwischen verschiedenen Komponenten der CIoT-Architektur bereitstellen können. Zum Beispiel kann der MEC-Host 102 zwischen dem RAN 204 und dem S-GW 212 gekoppelt sein. In diesem Fall kann der MEC-Host 102 eine oder mehrere NFV-Instanzen verwenden, um drahtlose Verbindungen mit dem RAN 204 und dem S-GW 212 zu verarbeiten. Der MEC-Host 102 kann auch zwischen dem P-GW 218 und dem Anwendungsserver 236 gekoppelt sein. In diesem Fall kann der MEC-Host 102 eine oder mehrere NFV-Instanzen verwenden, um drahtlose Verbindungen zu verarbeiten, die mit einer oder mehreren Netzwerk-Slice-Instanzenverbunden sind, die von dem P-GW 218 und dem Anwendungsserver 236 ausgehen oder dort enden. In einigen Aspekten beinhaltet der MEC-Host 102 ein MEC-NFV-SCF-Modul 121, das gemäß hierin offenbarten Techniken konfiguriert ist, um Multi-Slice-Unterstützung für die eine oder mehreren Netzwerk-Slice-Instanzen in MEC-fähigen 5G-Bereitstellungen bereitzustellen.
2B veranschaulicht eine beispielhafte Service Capability Exposure Function (SCEF), die von der CIoT-Netzwerkarchitektur der 2A verwendet wird, gemäß einem Beispiel. Bezugnehmend auf 2B kann die SCEF 220 so konfiguriert sein, dass sie Dienste und Fähigkeiten, die von 3GPP-Netzwerkschnittstellen bereitgestellt werden, externen Dienstanbieterservern von Drittanbietern bereitstellt, die verschiedene Anwendungen hosten. In einigen Aspekten kann ein 3GPP-Netzwerk wie die CIoT-Architektur 200A die folgenden Dienste und Fähigkeiten bereitstellen: einen Home Subscriber Server (HSS) 256A, eine Policy and Charging Rules Function (PCRF) 256B, eine Packet Flow Description Function (PFDF) 256C, ein MME/SGSN 256D, ein Broadcast Multicast Service Center (BM-SC) 256E, eine Serving Call Server Control Function (S-CSCF) 256F, eine RAN Congestion Awareness Function (RCAF) 256G und eine oder mehrere andere Netzwerkentitäten 256H . Die oben erwähnten Dienste und Fähigkeiten eines 3GPP-Netzwerks können mit dem SCEF 220 über eine oder mehrere Schnittstellen kommunizieren, wie in 2B dargestellt. Die SCEF 220 kann konfiguriert sein, um die 3GPP-Netzwerkdienste und -fähigkeiten einer oder mehreren Anwendungen bereitzustellen, die auf einem oder mehreren Service Capability Servern (SCS)/Anwendungsservern (AS) wie SCS/AS 254A, 254B, ..., 254N ausgeführt werden. Jeder der SCS/AS 254A - 254N kann mit dem SCEF 220 über Anwendungsprogrammierschnittstellen (APIs) 252A, 252B, 252C, ..., 252N kommunizieren, wie in 2B dargestellt.
3A ist ein vereinfachtes Diagramm einer beispielhaften Systemarchitektur der nächsten Generation (Next Generation, NG) mit einem MEC-Host unter Verwendung eines MEC-QoS-Managers gemäß einem Beispiel. Bezugnehmend auf 3A beinhaltet die NG-Systemarchitektur 300A NG-RAN 304 und einen 5G-Netzwerkkern (5GC) 306. Das NG-RAN 304 kann eine Vielzahl von NG-RAN-Knoten beinhalten, zum Beispiel gNBs 308 und 310 und NG-eNBs 312 und 314. Die gNBs 308/310 und die NG-eNBs 312/314 können über eine drahtlose Verbindung mit dem UE 302 kommunikativ gekoppelt werden. Das Kernnetzwerk 306 (z.B. ein SG-Kernnetzwerk oder 5GC) kann eine Zugriffs- und Mobilitätsverwaltungsfunktion (AMF) 316 oder eine Benutzerebenenfunktion (UPF) 318 beinhalten. Der AMF 316 und der UPF 318 können über NG-Schnittstellen kommunikativ mit den gNBs 308/310 und den NG-eNBs 312/314 gekoppelt werden. Insbesondere können in einigen Aspekten die gNBs 308/310 und die NG-eNBs 312/314 mit der AMF 316 durch einen N2-Referenzpunkt und mit der UPF 318 durch einen N3-Referenzpunkt verbunden sein. Die gNBs 308/310 und die NG-eNBs 312/314 können über Xn-Schnittstellen miteinander gekoppelt werden.
In einigen Aspekten kann ein gNB 308 einen Knoten beinhalten, der eine New Radio (NR) User Plane und Control Plane Protocol Termination in Richtung des UE bereitstellt und kann über die NG-Schnittstelle mit dem 5GC 306 verbunden sein. In einigen Aspekten kann ein NG-eNB 312/314 einen Knoten beinhalten, der E-UTRA-Benutzerebenen- und Steuerebenenprotokollabschlüsse in Richtung des UE bereitstellt und über die NG-Schnittstelle mit dem 5GC 306 verbunden ist. In einigen Aspekten kann jeder der gNBs 308/310 und der NG-eNBs 312/314 als eine Basisstation (BS), ein mobiler Edge-Server, eine kleine Zelle, ein Heimat-eNB implementiert werden, obwohl die Aspekte nicht darauf beschränkt sind.
In einigen Aspekten kann die NG-Systemarchitektur 300A einen oder mehrere MEC-Hosts umfassen, die eine Kommunikationsverbindung zwischen verschiedenen Komponenten der NG-Architektur bereitstellen können. Zum Beispiel kann der MEC-Host 102 eine Schnittstelle zwischen dem AMF 316 (oder der UPF 318) in der 5GC 306 und dem Anwendungsserver 114 bereitstellen. Der MEC-Host 102 kann eine oder mehrere NFV-Instanzen verwenden, um drahtlose Verbindungen, die Netzwerk-Slice-Instanzen zugeordnet sind, mit dem 5GC 306 und dem Anwendungsserver 114 zu verarbeiten. Der MEC-Host 102 kann auch zwischen einem oder mehreren der gNBs (z.B. gNB 308) und dem AMF/UPF in der 5GC 306 gekoppelt sein. In diesem Fall kann der MEC-Host 102 eine oder mehrere NFV-Instanzen verwenden, um drahtlose Verbindungen der NSIs zu verarbeiten, die von dem gNB 308 und dem 5GC 306 stammen oder dort enden.
In einigen Aspekten umfasst der MEC-Host 102 ein MEC-NFV-SCF-Modul 121, das gemäß hierin offenbarten Techniken konfiguriert ist, um E2E-Multi-Slice-Unterstützung für die Konfiguration von Netzwerkressourcen, die mit Netzwerk-Slice-Instanzen in MEC-fähigen 5G-Kommunikationssystemen verbunden sind, bereitzustellen, um die Instanziierung von MEC-Apps und virtualisierten Ressourcen im Zusammenhang mit dem NSI zu optimieren. In einigen Aspekten kann das MEC-NFV-SCF-Modul 121 als eigenständiger Server oder als Anwendung, die auf einer virtuellen Maschine ausgeführt wird und auf den sowohl der 5G-Kern 306 als auch der MEC-Host 102 zugreifen können, integriert werden. In einigen Aspekten kann der 5G-Kern 306 Slice-Management-Funktionalitäten bereitstellen, die von dem Slice-Management-Modul 164 ausgeführt werden, wie hierin offenbart und mit Hilfe des MEC NFV-SCF.
In einigen Aspekten kann die Systemarchitektur 300A (die die gleiche wie 100A sein kann) eine 5G-NR-Systemarchitektur sein, die Netzwerk-Slicing bereitstellt und Richtlinienkonfiguration und Durchsetzung zwischen Netzwerk-Slices gemäß Service Level Agreements (SLAs) innerhalb des RAN 304 (oder 204) unterstützt. Zusätzlich und wie detaillierter in 3E dargestellt, kann das RAN 304 eine Trennung der Funktionalitäten der Zentraleinheitssteuerebene (CU-CP) und der Zentraleinheitsbenutzerebene (CU-UP) bereitstellen und gleichzeitig Netzwerk-Slicing unterstützen (z. B. unter Verwendung von Informationen zur Ressourcenverfügbarkeit und Latenzzeit über verschiedene RAN-Schnittstellen (oder Referenzpunkte), wie E1-, F1-C- und F1-U-Schnittstellen). In einigen Aspekten kann das UE 302 (oder 152) RRC-Signalisierung an den gNB 308 kommunizieren, um eine Verbindung mit einer Entität (z.B. UPF 318) des 5GC 306 aufzubauen. Der gNB 308 kann separate verteilte Einheiten (DUs), CU-CP- und CU-UP- Entität (wie in 3e dargestellt). Die CU-CP- Entität kann Ressourcennutzungs- und Latenzzeitinformationen von den DU- und CU-UP- Entitäten erhalten und ein DU/CU-UP-Paar basierend auf diesen Informationen zum Zweck der Konfiguration des Netzwerk-Slice auswählen. Netzwerk-Slice-Konfigurationsinformationen, die dem konfigurierten Netzwerk-Slice zugeordnet sind (einschließlich Ressourcen zur Verwendung während der Kommunikation über den Slice) können dem UE 302 bereitgestellt werden, um eine Datenkommunikation mit der 5GC-UPF-Entitäten 318 unter Verwendung des Netzwerk-Slice zu initiieren.
3B veranschaulicht eine beispielhafte funktionale Aufteilung zwischen dem Funkzugangsnetz der nächsten Generation (NG-RAN) und dem SG-Kernnetz (5GC) in Verbindung mit der NG-Systemarchitektur von 3A, gemäß einem Beispiel. 3B veranschaulicht einige der Funktionalitäten, die die gNBs 308/310 und die NG-eNBs 312/314 innerhalb des NG-RAN 304 ausführen können, sowie die AMF 316, der UPF 318 und eine Sitzungsverwaltungsfunktion (SMF) 326 (nicht dargestellt in 3A) innerhalb des 5GC 306. In einigen Aspekten kann das 5GC 306 einem oder mehreren Geräten über das NG-RAN 304 Zugriff auf ein Netzwerk 330 (z.B. das Internet) bereitstellen.
In einigen Aspekten können die gNBs 308/310 und die NG-eNBs 312/314 konfiguriert sein, um die folgenden Funktionen zu hosten: Funktionen für die Funkressourcenverwaltung (z.B. Funkressourcenverwaltung 320A zwischen Zellen, Funkträgersteuerung 320B, Verbindungsmobilitätssteuerung). 320C, Funkzugangskontrolle 320D, Mess- und Messberichtskonfiguration für Mobilität und Planung 320E und dynamische Zuweisung von Ressourcen zu UEs sowohl in Uplink als auch Downlink (Planung/Scheduling) 320F ; IP-Header-Komprimierung; Verschlüsselung und Integritätsschutz von Daten; Auswahl einer AMF am UE-Anschluss, wenn kein Routing zu einer AMF aus den von der UE bereitgestellten Informationen bestimmt werden kann; Routing von Benutzerebenendaten zu UPF(s); Routing von Steuerebenen--Informationen zu AMF; Verbindungsaufbau und -freigabe; Planung und Übertragung von Paging-Nachrichten (von der AMF stammend); Planung und Übertragung von Systemrundfunkinformationen (hervorgegangen aus der AMF oder Operation and Maintenance); Paketmarkierung auf Transportebene im Uplink; Sitzungsverwaltung; Unterstützung von Network-Slicing; QoS-Flussmanagement und Zuordnung zu Datenfunkträgern; Unterstützung von UEs im RRC_INACTIVE-Zustand; Verteilungsfunktion für Non-Access Stratum (NAS)-Nachrichten; gemeinsame Nutzung von Funkzugangsnetzen; duale Konnektivität; und enge Zusammenarbeit zwischen NR und E-UTRA, um nur einige zu nennen.
In einigen Aspekten kann die AMF 316 konfiguriert sein, um die folgenden Funktionen zu hosten, zum Beispiel die Beendigung der NAS-Signalisierung; NAS-Signalisierungssicherheit 322A; Zugangsschicht-(AS)-Sicherheitskontrolle; Inter-Core-Network (CN)-Knoten-Signalisierung für Mobilität zwischen 3GPP-Zugangsnetzen; Mobilitätshandhabung 322B im Ruhezustand/Modus, einschließlich mobiler Geräte, wie etwa einer UE-Erreichbarkeit (z.B. Steuerung und Ausführung einer Paging-Neuübertragung); Verwaltung des Registrierungsbereichs; Unterstützung der Intra-System- und Inter-System-Mobilität; Zugangsauthentifizierung; Zugangsberechtigung einschließlich Prüfung der Roaming-Rechte; Steuerung des Mobilitätsmanagements (Abonnement und Richtlinien); Unterstützung von Network-Slicing; oder SMF-Auswahl, neben anderen Funktionen.
Die UPF 318 kann konfiguriert sein, um die folgenden Funktionen zu hosten, zum Beispiel Mobilitätsverankerung 324A (z.B. Ankerpunkt für Intra-/Inter-RAT-Mobilität); Paketdateneinheit (PDU), die 324B handhabt (z.B. externer PDU-Sitzungspunkt der Verbindung zum Datennetz); Paket-Routing und -Weiterleitung; Paketinspektion und Benutzerebene als Teil der Durchsetzung von Richtlinienregeln; Berichterstattung über die Verkehrsnutzung; Uplink-Klassifizierer, um das Routing von Verkehrsflüssen zu einem Datennetz zu unterstützen; Verzweigungspunkt zur Unterstützung einer mehrfach vernetzten PDU-Sitzung; QoS-Handling für Benutzerebene, z.B. Paketfilterung, Gating, UL/DL-Ratenerzwingung; Uplink-Verkehrsüberprüfung (SDF-zu-QoS-Flow-Mapping); oder Downlink-Paketpufferung und Downlink-Datenbenachrichtigungs-Triggerung, neben anderen Funktionen.
Die Sitzungsverwaltungsfunktion (SMF) 326 kann konfiguriert sein, um die folgenden Funktionen zu hosten, beispielsweise Sitzungsverwaltung; Zuweisung und Verwaltung von UE-IP-Adressen 328A; Auswahl und Steuerung der User-Plane-Funktion (UPF); PDU-Sitzungssteuerung 328B, einschließlich Konfigurieren der Verkehrssteuerung am UPF 318, um Verkehr an das richtige Ziel zu leiten; einen Teil der Richtliniendurchsetzung und QoS kontrollieren; oder Downlink-Datenbenachrichtigung, neben anderen Funktionen.
3C und 3D veranschaulichen beispielhafte 5G-Systemarchitekturen ohne Roaming mit einem MEC-Host unter Verwendung eines MEC-QoS-Managers, gemäß einem Beispiel. Bezugnehmend auf 3C ist eine beispielhafte SG-Systemarchitektur 300C in einer Referenzpunktdarstellung veranschaulicht. Genauer gesagt kann das UE 302 mit dem RAN 304 sowie mit einer oder mehreren anderen 5G-Kern-(5GC-) Netzwerkentitäten in Kommunikation stehen. Die SG-Systemarchitektur 300C umfasst eine Vielzahl von Netzwerkfunktionen (NFs), wie z.B. eine Zugriffs- und Mobilitätsverwaltungsfunktion (AMF) 316, eine Sitzungsverwaltungsfunktion (SMF) 326, eine Richtliniensteuerungsfunktion (PCF) 332, eine Anwendungsfunktion (AF) 352, Benutzerebenenfunktion (UPF) 318, Netzwerk-Slice-Auswahlfunktion (NSSF) 334, Authentifizierungsserverfunktion (AUSF) 336 und Unified Data Management (UDM) 338.
Die UPF 318 kann eine Verbindung zu einem Datennetz (DN) 354 bereitstellen, das zum Beispiel Betreiberdienste, Internetzugang oder Dienste Dritter umfassen kann. Die AMF 316 kann verwendet werden, um Zugangskontrolle und Mobilität zu verwalten und kann auch eine Netzwerk-Slice-Auswahlfunktionalität umfassen. Die SMF 326 kann so konfiguriert werden, dass sie verschiedene Sitzungen gemäß den Netzwerkrichtlinien einrichtet und verwaltet. Die UPF 318 kann je nach gewünschtem Diensttyp in einer oder mehreren Konfigurationen bereitgestellt werden. Die PCF 332 kann konfiguriert werden, um einen Richtlinienrahmen bereitzustellen, der Netzwerk-Slicing, Mobilitätsmanagement und Roaming verwendet (ähnlich wie bei PCRF in einem 4G-Kommunikationssystem). Das UDM 338 kann konfiguriert sein, um Teilnehmerprofile und Daten zu speichern (ähnlich einem HSS in einem 4G-Kommunikationssystem), wie beispielsweise V2X-Abonnementinformationen oder eine andere Art von Abonnementinformationen für Dienste, die innerhalb der Architektur 300C verfügbar sind.
In einigen Aspekten umfasst die 5G-Systemarchitektur 300C ein IP-Multimedia-Subsystem (IMS) 342 sowie eine Vielzahl von IP-Multimedia-Kernnetzwerk-Subsystem-Entitäten, wie etwa Anrufsitzungs-Steuerungsfunktionen (CSCFs). Insbesondere beinhaltet das IMS 342 eine CSCF, die als Proxy-CSCF (P-CSCF) 344 fungieren kann, eine bedienende CSCF (S-CSCF) 346, eine Notfall-CSCF (E-CSCF) (in 3C dargestellt) oder abfragende CSCF (I-CSCF) 348. Die P-CSCF 344 kann als erster Kontaktpunkt für das UE 302 innerhalb des IMS 342 konfiguriert werden. Die S-CSCF 346 kann so konfiguriert werden, dass sie die Sitzungszustände im Netzwerk verarbeitet, und die E-CSCF kann so konfiguriert werden, dass sie bestimmte Aspekte von Notfallsitzungen verarbeitet, wie z. B. die Weiterleitung eines Notrufs an die richtige Notrufzentrale oder den öffentlichen Notrufempfänger (PSAP). Die I-CSCF 348 kann so konfiguriert werden, dass sie als Kontaktpunkt innerhalb eines Netzes eines Betreibers für alle IMS-Verbindungen dient, die für einen Teilnehmer dieses Netzbetreibers oder einen Roaming-Teilnehmer bestimmt sind, der sich derzeit im Dienstbereich dieses Netzbetreibers befindet. In einigen Aspekten kann die I-CSCF 348 mit einem anderen IP-Multimedia-Netzwerk 350 verbunden sein, z.B. einem IMS, das von einem anderen Netzwerkbetreiber betrieben wird.
In einigen Aspekten kann der UDM 338 mit einem Anwendungsserver 340 gekoppelt sein, der einen Telefonieanwendungsserver (TAS) oder einen anderen Anwendungsserver (AS) mit einem MEC-Host umfassen kann. Die AS 340 kann über die S-CSCF 346 oder die I-CSCF 348 an das IMS 342 angekoppelt werden. In einigen Aspekten kann die 5G-Systemarchitektur 300C einen oder mehrere MEC-Hosts verwenden, um eine Schnittstelle bereitzustellen und die Verarbeitung des drahtlosen Kommunikationsverkehrs auszulagern. Beispielsweise und wie in 3C dargestellt, kann der MEC-Host 102 eine Verbindung zwischen dem RAN 304 und der UPF 318 im Kernnetzwerk bereitstellen. Der MEC-Host 102 kann eine oder mehrere NFV-Instanzen verwenden, die auf der Virtualisierungsinfrastruktur innerhalb des Hosts instanziiert sind, um drahtlose Verbindungen einer oder mehrerer Netzwerk-Slice-Instanzen zu und von dem RAN 304 und der UPF 318 zu verarbeiten. Außerdem kann der MEC-Host 102 das MEC-NFV-SCF-Modul 121 verwenden, das gemäß hierin offenbarten Techniken konfiguriert ist, um bereitzustellen E2E-Multi-Slice-Unterstützung zum Konfigurieren von Netzwerkressourcen, die mit Netzwerk-Slice-Instanzen in MEC-fähigen 5G-Kommunikationssystemen verbunden sind, um die Instanziierung von MEC-Apps und virtualisierten Ressourcen im Zusammenhang mit dem NSI zu optimieren.
3D veranschaulicht eine beispielhafte 5G-Systemarchitektur 300D in einer dienstbasierten Darstellung. Die Systemarchitektur 300D kann der Systemarchitektur 300C im Wesentlichen ähnlich (oder gleich) sein. Zusätzlich zu den in 3C kann die Systemarchitektur 300D auch eine Netzwerk-Expositionsfunktion (NEF) 356 und eine Netzwerk-Repository-Funktion (NRF) 358 beinhalten. In einigen Aspekten können 5G-Systemarchitekturen dienstbasiert sein und die Interaktion zwischen Netzwerkfunktionen kann durch entsprechende Punkt-zu-Punkt-Referenzpunkte Ni (wie in 3C dargestellt) oder als servicebasierte Schnittstellen oder Referenzpunkte (wie in 3D dargestellt).
Eine Referenzpunktdarstellung zeigt, dass eine Interaktion zwischen entsprechenden NF-Diensten bestehen kann. Zum Beispiel veranschaulicht 3C die folgenden Referenzpunkte: N1 (zwischen UE 302 und AMF 316), N2 (zwischen RAN 304 und AMF 316), N3 (zwischen RAN 304 und UPF 318), N4 (zwischen SMF 326 und UPF 318), N5 (zwischen PCF 332 und AF 352), N6 (zwischen UPF 318 und DN 354), N7 (zwischen SMF 326 und PCF 332), N8 (zwischen UDM 338 und AMF 316), N9 (zwischen zwei UPFs 318), N10 (zwischen UDM 338 und SMF 326), N11 (zwischen AMF 316 und SMF 326), N12 (zwischen AUSF 336 und AMF 316), N13 (zwischen AUSF 336 und UDM 338), N14 (zwischen zwei AMFs 316), N15 (zwischen der PCF 332 und der AMF 316 im Fall eines Nicht-Roaming-Szenarios oder zwischen der PCF 332 und einem besuchten Netz und AMF 316 im Fall eines Roaming-Szenarios), N16 (zwischen zwei SMFs; nicht gezeigt), N22 (zwischen AMF 316 und NSSF 334) und N33 (zwischen NEF und AF; nicht gezeigt). Andere Referenzpunktdarstellungen, die in 3C nicht gezeigt sind, können ebenfalls verwendet werden und sind in der folgenden 3GPP-Spezifikation definiert: TS 23.501, TS 22.261, TS 28.531, TS 28.532 und 38.300.
In einigen Aspekten, wie in 3D dargestellt, können dienstbasierte - Darstellungen verwendet werden, um Netzwerkfunktionen innerhalb der Steuerungsebene darzustellen, die es anderen autorisierten Netzwerkfunktionen ermöglichen, auf ihre Dienste zuzugreifen. In dieser Hinsicht kann die 5G-Systemarchitektur 300D die folgenden servicebasierten Schnittstellen umfassen: Namf 364A (eine servicebasierte Schnittstelle, die von der AMF 316 bereitgestellt wird), Nsmf 364B (eine servicebasierte Schnittstelle, die von der SMF 326 bereitgestellt wird), Nnef 364C (eine servicebasierte Schnittstelle, die von der NEF 356 bereitgestellt wird), Npcf 364D (eine servicebasierte Schnittstelle, die von der PCF 332 bereitgestellt wird), Nudm 364E (eine servicebasierte Schnittstelle, die von dem UDM 338 bereitgestellt wird), Naf 364F (eine servicebasierte Schnittstelle, die von der AF 352 bereitgestellt wird), Nnrf 364G (eine servicebasierte Schnittstelle, die von der NRF 358 bereitgestellt wird), Nnssf 364H (eine servicebasierte Schnittstelle, die von der NSSF 334 bereitgestellt wird), Nausf 364I (eine servicebasierte Schnittstelle, die von der AUSF 360 bereitgestellt wird). Andere dienstbasierte Schnittstellen (z.B. Nudr, N5g-eir und Nudsf), die in 1 nicht gezeigt sind. 3D kann auch verwendet werden.
In einigen Aspekten kann die NEF 356 eine Schnittstelle für einen MEC-Host, wie etwa den MEC-Host 102, bereitstellen, die verwendet werden kann, um drahtlose Verbindungen mit dem RAN 304 zu verarbeiten. In einigen Aspekten kann der MEC-Host 102 verwendet werden, um NFV-SCF-Funktionen zu implementieren und bereitzustellen E2E-Multi-Slice-Unterstützung zum Konfigurieren von Netzwerkressourcen, die mit Netzwerk-Slice-Instanzen in MEC-fähigen 5G-Kommunikationssystemen verbunden sind, um die Instanziierung von MEC-Apps und virtualisierten Ressourcen im Zusammenhang mit dem NSI zu optimieren.
3E veranschaulicht Komponenten einer beispielhaften 5G-NR-Architektur mit einer Trennung von Steuereinheit-Steuerebene (CU-CP) - Steuereinheit-Benutzerebene (CU-UP) gemäß einem Beispiel. Bezugnehmend auf 3E kann die 5G-NR-Architektur 300E einen 5G-Kern (5GC) 306 und NG-RAN 304 beinhalten. Das NG-RAN 304 kann einen oder mehrere gNBs beinhalten, wie etwa gNB 308 und 310. In einigen Aspekten können Netzwerkelemente des NG-RAN 304 in zentrale und verteilte Einheiten aufgeteilt werden, und verschiedene zentrale und verteilte Einheiten oder Komponenten der zentralen und verteilten Einheiten können zum Ausführen verschiedener Protokollfunktionen konfiguriert sein (z.B. verschiedene Protokollfunktionen der Protokollschichten).
In einigen Aspekten kann der gNB 308 eine oder mehrere von einer gNB-Zentraleinheit (gNB-CU) 322E und einer oder mehreren verteilten gNB-Einheit(en) (gNB-DU) 324E, 326E umfassen oder in diese aufgeteilt sein. Außerdem kann der gNB 308 eine oder mehrere von einer gNB-CU-Steuerungsebene (gNB-CU-CP) 328E und einer gNB-CU-Benutzerebene (gNB-CU-UP) 330E umfassen oder in diese aufgeteilt sein. Die gNB-CU 322E ist ein logischer Knoten, der konfiguriert ist, um die Funkressourcensteuerungs-(RRC-) Schicht, die Dienstdatenanpassungsprotokoll-(SDAP-) Schicht und die Paketdatenkonvergenz-Protokollschicht-(PDCP-)-Protokolle des gNB oder RRC und PDCP-Protokolle von die E-UTRA-NR gNB (en-gNB), die den Betrieb einer oder mehrerer gNB-DUs steuert, zu hosten. Die gNB-DU (z.B. 324E oder 326E) ist ein logischer Knoten, der konfiguriert ist, um die Funkverbindungssteuerungsschicht (RLC), die Medienzugriffssteuerungsschicht (MAC) und die physikalischen Schichten (PHY) der gNB 128A, 128B oder en- gNB zu hosten -, und sein Betrieb wird zumindest teilweise von gNB-CU 322E gesteuert. In einigen Aspekten kann eine gNB-DU (z.B. 324E) eine oder mehrere Zellen unterstützen.
Die gNB-CU 322E umfasst eine gNB-CU-Steuerungsebenen-(gNB-CU-CP)-Einheit 328E und eine gNB-CU-Benutzerebenen-Einheit (gNB-CU-UP) 330E. Die gNB-CU-CP 328E ist ein logischer Knoten, der konfiguriert ist, um den RRC und den Steuerungsebenenteil des PDCP-Protokolls der gNB-CU 322E für einen en-gNB oder einen gNB zu hosten. Die gNB-CU-UP 330E ist ein logischer (oder physischer) Knoten, der konfiguriert ist, um den Benutzerebenenteil des PDCP-Protokolls der gNB-CU 322E für einen en-gNB und den Benutzerebenenteil des PDCP-Protokolls und die SDAP-Protokoll des gNB-CU 322E für einen gNB zu hosten.
Die gNB-CU 322E und die gNB-DUs 324E, 326E können über die F1-Schnittstelle kommunizieren, und die gNB 308 kann mit der gNB-CU 322E über die Xn-C-Schnittstelle kommunizieren. Die gNB-CU-CP 328E und die gNB-CU-UP 330E können über die E1-Schnittstelle(n) kommunizieren. Darüber hinaus können die gNB-CU-CP 328E und die gNB-DUs 324E, 326E über die F1-C-Schnittstelle kommunizieren, und die gNB-DUs 324E, 326E und die gNB-CU-UP 330E können über die F1-U Schnittstelle kommunizieren.
In einigen Aspekten beendet die gNB-CU 322E die F1-Schnittstelle, die mit den gNB-DUs 324E, 326E verbunden ist, und in anderen Aspekten beenden die gNB-DUs 324E, 326E die F1-Schnittstelle, die mit der gNB-CU 322E verbunden ist. In einigen Aspekten schließt die gNB-CU-CP 328E die mit der gNB-CU-UP 330E verbundene E1-Schnittstelle und die mit den gNB-DUs 324E, 326E verbundene F1-C-Schnittstelle ab. In einigen Aspekten schließt die gNB-CU-UP 330E die E1-Schnittstelle, die mit der gNB-CU-CP 328E verbunden ist, und die F1-U-Schnittstelle, die mit den gNB-DUs 324E, 326E verbunden ist, ab.
In einigen Aspekten ist die F1-Schnittstelle eine Punkt-zu-Punkt-Schnittstelle zwischen Endpunkten und unterstützt den Austausch von Signalisierungsinformationen zwischen Endpunkten und die Datenübertragung an die jeweiligen Endpunkte. Die F1-Schnittstelle kann die Trennung von Steuerungsebene und Benutzerebene unterstützen und die Funknetzwerkschicht und die Transportnetzwerkschicht trennen. In einigen Aspekten ist die E1-Schnittstelle eine Punkt-zu-Punkt-Schnittstelle zwischen einer gNB-CU-CP und einer gNB-CU-UP und unterstützt den Austausch von Signalisierungsinformationen zwischen Endpunkten. Die E1-Schnittstelle kann die Funknetzwerkschicht und die Transportnetzwerkschicht trennen, und in einigen Aspekten kann die E1-Schnittstelle eine Steuerschnittstelle sein, die nicht für die Benutzerdatenweiterleitung verwendet wird.
Unter Bezugnahme auf das NG-RAN 304 können die gNBs 308, 310 des NG-RAN 304 über die NG-Schnittstellen mit dem 5GC 306 kommunizieren und können über die Xn-Schnittstelle mit anderen gNBs verbunden werden. In einigen Aspekten können die gNBs 308, 310 so konfiguriert sein, dass sie den FDD-Modus, den TDD-Modus oder den Dual-Modus-Betrieb unterstützen. In bestimmten Aspekten können für EN-DC die S1-U-Schnittstelle und eine X2-Schnittstelle (z.B. X2-C-Schnittstelle) für einen gNB, bestehend aus einer gNB-CU und gNB-DUs, in der gNB-CU enden.
In einigen Aspekten umfasst die gNB 310, die die CP/UP-Trennung unterstützt, eine einzelne CU-CP-Entität 328E, mehrere CU-UP- Entitäten 330E und mehrere DU- Entitäten 324E, ..., 326E, wobei alle Entitäten für den Netzwerk-Slice-Betrieb konfiguriert sind. Wie in 3E dargestellt, kann jede DU- Entität 324E, ..., 326E eine einzelne Verbindung mit dem CU-CP 328E über eine F1-C-Schnittstelle haben. Jede DU-Entität 324E, ..., 326E kann mit mehreren CU-UP- Entitäten 330E unter Verwendung von F1-U-Schnittstellen verbunden werden. Die CU-CP- Entität 328E kann über E1-Schnittstellen mit mehreren CU-UP- Entitäten 330E verbunden werden. Jede DU-Entität 324E, ..., 326E kann mit einem oder mehreren UEs verbunden sein, und die CU-UP-Entitäten 330E können mit einer User-Plane-Funktion (UPF) und dem 5G-Kern 306 verbunden sein.
In einigen Aspekten können Entitäten innerhalb des gNB 310 eine oder mehrere Prozeduren durchführen, die mit Schnittstellen oder Funkträgern innerhalb des NG-RAN 304 mit der Trennung von CP/UP verbunden sind. NG-RAN 304 kann beispielsweise die folgenden Verfahren im Zusammenhang mit der Netzwerk-Slice-Konfiguration unterstützen:

Einrichtung der E1-Schnittstelle: Dieses Verfahren ermöglicht die Einrichtung der E1-Schnittstelle und beinhaltet den Austausch der für den Schnittstellenbetrieb erforderlichen Parameter. Das E1-Setup wird vom CU-CP 328E initiiert;
E1-Schnittstellen-Reset: Dieses Verfahren ermöglicht das Zurücksetzen der E1-Schnittstelle, einschließlich Änderungen der Konfigurationsparameter. Der Reset der E1-Schnittstelle wird entweder von der CU-CP 328E oder der CU-UP 330E eingeleitet;
E1-Fehleranzeige: Dieses Verfahren ermöglicht die Meldung erkannter Fehler in einer eingehenden Nachricht. Der Reset der E1-Schnittstelle wird entweder von der CU-CP 328E oder der CU-UP 330E eingeleitet;
E1-Lastinformation: Dieses Verfahren ermöglicht es CU-UP 328E, CU-CP 328E, periodisch über den aktuellen Lastzustand zu informieren. Das gleiche Verfahren könnte auch verwendet werden, um die Überlast des CU-UP 330E mit Überlaststatus (Start/Stopp) anzuzeigen;
E1-Konfigurationsaktualisierung: Dieses Verfahren unterstützt Aktualisierungen in der CU-UP 330E-Konfiguration, wie z.B. Kapazitätsänderungen;
Einrichtung des Datenfunkträgers (DRB): Dieses Verfahren ermöglicht es der CU-CP 328E, DRBs in der CU-CP einzurichten, einschließlich der Sicherheitsschlüsselkonfiguration und des Dienstqualitätsflusses (QoS) zur DRB-Zuordnungskonfiguration;
DRB-Modifikation: Diese Prozedur ermöglicht es der CU-CP 328E, DRBs in der CU-CP zu modifizieren, einschließlich der Modifikation der Sicherheitsschlüsselkonfiguration und der Modifikation des QoS-Flusses zur DRB-Zuordnungskonfiguration;
DRB-Freigabe: Dieses Verfahren ermöglicht es dem CU-CP 328E, DRBs im CU-CP freizugeben; und
Downlink-Datenbenachrichtigung (DDN): Diese Prozedur ermöglicht es CU-UP 330E, CU-CP 328E aufzufordern, eine Paging-Prozedur auszulösen, um den RRCinaktiven Zustand zu unterstützen.

In einigen Aspekten kann das NG-RAN 304 konfiguriert sein, um E1-Schnittstellenverwaltungsprozeduren für Netzwerk-Slicing zu unterstützen, einschließlich Ressourcenverfügbarkeitsanzeige von der CU-UP 330E, Ressourcenverwaltung in CU-UP 330E und Latenzanzeige von der CU-UP 330E.
In einigen Aspekten kann das NG-RAN 304 konfiguriert sein, um F1-C-Schnittstellenverwaltungsverfahren für Netzwerk-Slicing zu unterstützen, einschließlich der Anzeige der Ressourcenverfügbarkeit von den DU- Entitäten 324E, ... 326E, der Ressourcenverwaltung in den DU-Entitäten 324E, ..., 326E und Latenzanzeige von den DU-Entitäten 324E, ..., 326E.
In einigen Aspekten kann das NG-RAN 304 so konfiguriert sein, dass es Latenzmessungen über die F1-U-Schnittstelle unterstützt, sodass die UP-Elemente einschließlich DU- Entitäten (324E, ..., 326E) und CU-UP-Entitäten 330E Latenzinformationen an andere benachbarte UP-Elemente übermitteln können. In dieser Hinsicht kann Network Slicing im NG-RAN 304 mit der Trennung von CP/UP unterstützt werden. In einigen Aspekten können eine Isolation auf Slice-Ebene und eine verbesserte Ressourcennutzung durch den zentralen RRM im CU-CP 328E bereitgestellt werden.
In einigen Aspekten umfassen die hierin erörterte Prozeduren, die mit dem Network Slicing verbunden sind, Operationen und Kommunikationen über die E1-Schnittstelle, die F1-C-Schnittstelle und die F1-U-Schnittstelle. Mit diesen Prozeduren kann der CU-CP 328E die geeigneten DU- und CU-UP- Entitäten auswählen, um die spezifische Netzwerk-Slicing-Anforderung zu bedienen, die mit einer bestimmten Dienstgütevereinbarung (SLA) verbunden ist.
In einigen Aspekten kann die Prozedur über die E1-Schnittstelle Informationen umfassen, die von den CU-UP- Entitäten 330E gesammelt wurden, und die Ressourcenverwaltung in der CU-CP 328E. Insbesondere können die gesammelten Informationen eine Ressourcenverfügbarkeitsanzeige und eine Latenzanzeige umfassen, während die Ressourcenverwaltung eine Ressourcenzuweisung und eine Ressourcenfreigabe umfassen kann. Der CU-CP 328E kann konfiguriert sein, um die Informationen von den CU-UP-Entitäten 330E periodisch zu sammeln oder eine bedarfsabhängige Abfrage basierend auf einer Netzwerk-Slice-Anforderung auszugeben. In einigen Aspekten kann eine Ressourcenverfügbarkeitsanzeigeprozedur den CU-UP-Entitäten 330E ermöglichen, den CU-CP 328E über die Verfügbarkeit von Ressourcen zu informieren, um eine Netzwerk-Slicing-Anforderung zu verarbeiten. Zum Beispiel kann die Angabe der verfügbaren Ressource den CU-CP 328E dabei unterstützen, zu bestimmen, ob die spezifische CU-UP die spezifische Netzwerk-Slice-Anforderung bedienen kann, die mit einer bestimmten SLA verknüpft ist.
In einigen Aspekten kann eine Ressourcenzuweisungsprozedur dem CU-CP 328E ermöglichen, die Ressource in der CU-UP 330E zuzuweisen, die einem bestimmten Slice zugeordnet ist. Beim Empfang einer Anforderung für eine Netzwerk-Slice-Erstellung kann die CU-CP 328E die CU-UP 330E (z.B. eine der CU-UP-Einheiten) nach dem angegebenen SLA auswählen und die Ressource in der ausgewählten CU-UP dem Network-Slice zuweisen. In einigen Aspekten kann eine Ressourcenfreigabeprozedur dem CU-CP 328E ermöglichen, die Ressource in der CU-UP freizugeben, die einem eingerichteten Netzwerk-Slice zugewiesen ist. Nach dem Entfernen des Slice kann der CU-CP 328E die entsprechende CU-UP benachrichtigen, die von dem entfernten Netzwerk-Slice verwendete Ressource freizugeben.
3F veranschaulicht einen Protokollstapel 300F auf Benutzerebene in Verbindung mit einem 5G-Kommunikationssystem gemäß einem Beispiel. Bezugnehmend auf 3F, entspricht die PDU-Schicht der PDU, die zwischen dem UE und dem DN über die PDU-Sitzung übertragen wird. Wenn der PDU-Sitzungstyp IPv4 oder IPv6 oder IPv4v6 ist, entspricht er IPv4-Paketen oder IPv6-Paketen oder beiden. Wenn der PDU-Sitzungstyp Ethernet ist, entspricht er Ethernet-Frames usw.
Das GPRS-Tunneling-Protokoll für die Benutzerebene (GTP-U) unterstützt das Multiplexen des Datenverkehrs verschiedener PDU-Sitzungen (möglicherweise entsprechend unterschiedlichen PDU-Sitzungstypen) durch Tunneln von Benutzerdaten über N3 (d.h., zwischen dem 5G-Access Network (5G-AN)-Knoten und der UPF) und N9 (d.h., zwischen verschiedenen UPFs des 5GC) im Backbone-Netzwerk. GTP kann alle Endbenutzer-PDUs kapseln. Es bietet Kapselung pro PDU-Sitzungsebene. Diese Schicht trägt auch die Markierung, die einem QoS-Fluss eines UE zugeordnet ist, wobei der QoS-Fluss einer Netzwerk-Slice-Instanz und einer MEC-App zugeordnet ist, die Daten für den NSI kommuniziert.
5G-AN-Protokollstack: Dieser Satz von Protokollen/Schichten hängt vom AN ab. Wenn das 5G-AN ein 3GPP NG-RAN ist, sind diese Protokolle/Schichten in TS 38.401 definiert. Das Funkprotokoll zwischen dem UE und dem 5G-AN-Knoten (eNodeB oder gNodeB) ist in TS 36.300 und TS 38.300 spezifiziert. Wenn es sich bei dem AN um einen nicht vertrauenswürdigen Nicht-3GPP-Zugang zum 5GC handelt, hat das 5G-AN eine Schnittstelle mit dem 5GC an einem N3IWF..
UDP/IP sind die Backbone-Netzwerkprotokolle. Die Anzahl der UPF im Datenpfad wird nicht durch 3GPP-Spezifikationen eingeschränkt. Im Datenpfad einer PDU-Sitzung können 0, 1 oder mehrere UPF vorhanden sein, die eine PDU-Sitzungsanker-Funktionalität für diese PDU-Sitzung nicht unterstützen. Der in 3F dargestellte „Nicht-PDU-Sitzungsanker“ UPF ist optional.. Die N9 Anhaltspunkt kann Intra-PLMN oder Inter-PLMN sein (im Fall von Home Routed-Bereitstellung).
Wenn es einen UL CL (Uplink Classifier) oder einen Verzweigungspunkt im Datenpfad einer PDU-Sitzung gibt, fungiert der UL CL oder der Verzweigungspunkt als der Nicht-PDU-Sitzungsanker-UPF von 1 . 3F. In diesem Fall verzweigen mehrere N9 Referenzpunkte aus dem UL CL / Branching Point, die jeweils zu unterschiedlichen PDU-Session-Ankern führen.
3G veranschaulicht ein Diagramm 300G mit Beispielen von Netzwerk-Slice-Instanzen (oder NSIs) 308G und 310G gemäß einem Beispiel. Der hier verwendete Begriff „Network-Slicing“ bezieht sich auf die Aufteilung des physischen Netzwerks in mehrere virtuelle Netzwerke, die eingerichtet sind, um verschiedene vertikale Anforderungen zu erfüllen. Network Slicing kann für Rel. 15 und höher relevant sein, und relevante 3GPP-Spezifikationen umfassen TS 23.501 (5GS Archit.), TS 22.261 (5G-Anforderungen) und TS 28.531/28.532 (5G Slice Management).
In einigen Aspekten hängt die Einführung von 5G von der Fähigkeit ab, Kommunikationsdienstanbietern (CSPs) die Möglichkeit zu geben, mehrere virtuelle Netzwerke über eine gemeinsame physische (drahtlose und drahtgebundene) Netzwerkinfrastruktur bereitzustellen, zu verwalten, anzupassen und zu betreiben. End-to-End-Netzwerk-Slice-Instanzen (oder „Slices“) bilden virtuelle logische Netzwerke unter Verwendung physischer Computer- und Netzwerkressourcen. Jede Netzwerk-Slice-Instanz kann spezifisch konfiguriert werden, um die Leistung in Bezug auf den unterstützten Dienst zu unterstützen, einschließlich Kapazität, Sicherheitsstufen, geografische Abdeckung und Latenz. Netzwerk-Slice-Instanzen umfassen die Partitionierung des drahtlosen Funks des Radio Access Network (RAN), der Kerninfrastruktur einschließlich des Evolved Packet Core (EPC) sowie der Switches und Rechenzentrumsserver, auf denen die 5G-Mobilanwendungen und -Inhalte gehostet werden können. Darüber hinaus können auch 5G-Edge-Geräte in den Slice einbezogen werden, abhängig von den Anforderungen an die Dienstlatenz.
In einigen Aspekten werden SG-Netzwerk-Slice-Instanzen eine breite Palette von Anwendungen unterstützen, von (semi-)autonomen Fahrzeugen, Remote-Gesundheitsüberwachung und First-Responder-Anwendungen, die die beste Sicherheit/Rückverfolgbarkeit erfordern, bis hin zu abgestuften Smartphone-Plänen und IoT-Geräten, die ohne zusätzliche Rückverfolgbarkeit der Ressourcen in Ordnung sein können..
Herkömmliche Netzwerk-Slice-Techniken verwenden Netzwerk-Slice-Instanzen, die statisch bereitgestellt werden, d.h. als Pipe zu einem Unternehmen. In einigen Aspekten kann Network Slicing von der 5G-Funkzugriffsschicht bis zur Unternehmensanwendungsschicht konfiguriert werden. Eine Netzwerk-Slice-Instanz kann in sich abgeschlossen sein, nicht gemeinsam genutzt oder aufgeteilt werden, um mehr Slices zu erstellen, und nicht für einzelne Anwendungen dynamisch skaliert werden.
EIN RAN 304G kann eine differenzierte Verarbeitung von Verkehr zwischen vorkonfigurierten, isolierten RAN-NSIs (oder RAN-Slices) 308G und 310G unterstützen. Die Auswahl des RAN-Slice kann auf IDs basieren (bei denen es sich um den oben definierten Slice-Diensttyp und Slice-Unterscheidungsmerkmal handeln kann), die von der Vorrichtung (z.B. UE 302G) oder dem Kernnetzwerk bereitgestellt werden. Ein RAN NSI kann an einem gegebenen Standort verfügbar sein oder nicht. In einigen Aspekten kann das RAN 304G (oder eine andere Netzwerkentität innerhalb des 5G-Systems, wie etwa eine MEC-Entität, wenn das 5G-System MEC-fähig ist, wie hierin nachstehend erörtert wird) Netzwerkressourcen konfigurieren, die einen NSI bilden. Zum Beispiel kann RAN 304G gemeinsame Netzwerkfunktionen (NFs) 306G (einschließlich NSSF, NRF und AMF NFs) auswählen, die mehreren NSIs (wie den NSIs 308G und 310G) gemeinsam sein können. Jeder der NSIs 308G und 310G kann basierend auf zusätzlichen NFs gebildet werden, wie beispielsweise SMF, NRF, PCF und UPF, wie in 3G dargestellt.
In einigen Aspekten kann auch eine QoS-Unterscheidung innerhalb einer RAN-NSI unterstützt werden. In dieser Hinsicht können die NSIs 308G und 310G vom UE verwendet werden, um separate QoS-Flüsse zu bedienen und Daten mit einer oder mehreren NFV-Instanzen zu kommunizieren, die von einer oder mehreren MEC-Apps bereitgestellt werden, unter Verwendung virtueller Ressourcen (z.B. VMs) der Datennetzwerke 312G, 314G.
Bezugnehmend auf 3G unterstützt die Network Slice Selection Function (NSSF) die Auswahl der Network Slice-Instanzen, um das UE zu bedienen, das Bestimmen der zulässigen NSSAI (Network Slice Selection Assistance Information) und das Bestimmen des AMF-Satzes, der verwendet werden soll, um das UE zu bedienen (NSSF ist eine neue Funktionalität, die im EPC nicht existiert).
In einigen Aspekten kann eine Netzwerk-Slice-Vorlage (NST) als eine Teilmenge von Attributwerten definiert werden, die für die Erzeugung von Instanzen der Netzwerk-Slice-Informationsobjektklasse (IOC) verwendet wird. Der Inhalt von NST ist möglicherweise nicht von 3GPP standardisiert, d.h., er kann von MNO und Anbieter definiert werden. In einigen Aspekten umfassen die vom NSI angegebenen slice-spezifischen Attribute eines oder mehrere der folgenden Elemente: eine Ende-zu-Ende-(E2E)-Latenzanforderung in Verbindung mit der Kommunikation von Daten innerhalb der NSI, eine minimal verfügbare Bandbreitenanforderung für die Vielzahl von Kommunikationsverbindungen der NSI N, und eine Kommunikationsdurchsatzanforderung von mindestens einer der Vielzahl von Kommunikationsverbindungen des NSI.
In einigen Aspekten wird die Slice-Auswahl durch das Netzwerk (AMF oder NSSF) basierend auf der Netzwerk-Slice-Richtlinie mit den vom UE gesendeten unterstützten Informationen (NSSAI) bestimmt. In einigen Aspekten können maximal 8 Netzwerkabschnitte pro UE verwendet werden, wobei jeder Abschnitt in Verbindung mit einem separaten QoS-Fluss des UE verwendet werden kann.
Verschiedene hier diskutierte 3GPP-bezogene Schnittstellen und Referenzpunkte werden in den folgenden 3GPP-bezogenen technischen Spezifikationen (TS) näher definiert: TS 23.501, TS 22.261, TS 28.531, TS 28.532 und 38.300. Verschiedene hier diskutierte MEC-bezogene Schnittstellen und Referenzpunkte werden in den folgenden ETSI-bezogenen technischen Spezifikationen näher definiert: Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024.
4A zeigt eine modifizierte MEC-Netzwerkarchitektur 400 zur Unterstützung von Slice-Management und Ressourcenmanagement, gemäß einem Beispiel. 4A veranschaulicht speziell eine MEC-Architektur 400 mit MEC-Hosts 402 und 404, die Funktionalitäten gemäß den Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024 bereitstellen, wobei die schattierten Blöcke dazu dienen, um Verarbeitungsaspekte für die hier beschriebene MEC-Architekturkonfiguration in Verbindung mit Slice- und Ressourcenmanagementfunktionen anzuzeigen . Insbesondere können Verbesserungen der MEC-Plattform 432 und des MEC-Plattform-Managers 406 verwendet werden, um Slice- und Ressourcenverwaltungsfunktionen innerhalb der MEC-Architektur 400 bereitzustellen. Dies kann die Bereitstellung einer oder mehrerer Netzwerk-Slice-Instanzen, die dynamische Verwaltung von Ressourcen, die von den Netzwerk-Slices verwendet werden, einschließlich des Generierens und Implementierens einer oder mehrerer Slice-Konfigurationsrichtlinien basierend auf der Utility-Funktionsmodellierung und der Bewertung der Latenz oder anderer Eigenschaften von MEC und Nicht-MEC Kommunikationsverbindungen für einen bestimmten NSI, der in einem MEC-fähigen 5G-Kommunikationsnetzwerk konfiguriert ist, umfassen.
Bezugnehmend auf 4A kann die MEC-Netzwerkarchitektur 400 MEC-Hosts 402 und 404, einen Virtualisierungsinfrastrukturmanager (VIM) 408, einen MEC-Plattformmanager 406, einen Mobile Edge Application Orchestrator (MEAO) 410, ein Betriebsunterstützungssystem (OSS) 412, einen Benutzer-App-Proxy 414, eine UE-App 418, die auf dem UE 420 ausgeführt wird, und das CFS-Portal 416 umfassen. Der MEC-Host 402 kann eine MEC-Plattform 432 mit einem Filterregel-Steuermodul 440, einem DNS-Handhabungsmodul 442, einer Dienstregistrierung 438 und MEC-Diensten 436 beinhalten. Der MEC-Host 404 kann Ressourcen beinhalten, die zum Instanziieren von MEC-Apps 405 verwendet werden. Die MEC-Dienste 436 können mindestens einen Scheduler 437 beinhalten, der verwendet werden kann, um Ressourcen zum Instanziieren von MEC-Apps (oder NFVs) 426 und 428 auf der Virtualisierungsinfrastruktur 422 auszuwählen, die eine Datenebene 424 beinhaltet. Die MEC-Apps 426 und 428 können so konfiguriert sein, dass sie Dienste 430/431 bereitstellen, die die Verarbeitung von Netzwerk-Kommunikationsverkehr verschiedener Typen in Verbindung mit einer oder mehreren drahtlosen Verbindungen umfassen kann (z. B. Verbindungen zu einer oder mehreren RAN- oder Kernnetzeinheiten, wie in 1-3D dargestellt). Die MEC-Plattform 432 kann Filterregelsteuerfunktionen 440, DNS-Handhabungsfunktionen 442 und Dienstregistrierungsfunktion 438 bereitstellen. Die MEC-Hardware 433 und der mindestens eine Scheduler 437 können der MEC-Hardware 123 und dem Scheduler 120 ähneln, die in Verbindung mit 1A erörtert wurden.
Der MEC-Plattform-Manager 406 kann ein MEC-PlattformelementVerwaltungsmodul 444, ein MEC-App-Regel- und Anforderungsverwaltungsmodul 446 und ein MEC-App-Lebenszyklus-Verwaltungsmodul 448 beinhalten. Die verschiedenen Einheiten innerhalb der MEC-Architektur 400 können Funktionalitäten ausführen, wie sie in den Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024 offenbart sind.
In einigen Aspekten kann das UE 420 dazu konfiguriert sein, über eine oder mehrere der Netzwerk-Slice-Instanzen 480 mit einem oder mehreren der Kernnetzwerke 482 zu kommunizieren. In einigen Aspekten können die Kernnetzwerke 482 Slice-Verwaltungsfunktionen (z.B. wie vom Slice-Verwaltungsmodul 164 bereitgestellt) verwenden, um NSIs 480 dynamisch zu konfigurieren, einschließlich einer dynamischen Zuweisung eines Slice an ein UE, Konfigurieren von mit dem Slice verknüpften Netzwerkfunktionen, Konfigurieren eines MEC App zum Kommunizieren von Daten unter Verwendung des Slice, Neuzuordnen eines Slice zu einem UE, dynamisches Zuweisen oder Neuzuordnen von Ressourcen, die von einem oder mehreren der Slices 480 verwendet werden, oder andere Slice-bezogene Verwaltungsfunktionen. Eine oder mehrere der im Zusammenhang mit der Slice-Verwaltung ausgeführten Funktionen können basierend auf Benutzeranfragen (z.B. über ein UE), basierend auf einer Anfrage durch einen Dienstanbieter oder möglicherweise automatisch in Verbindung mit einem bestehenden Service Level Agreement (SLA)) mit abschnittsbezogenen Leistungszielen initiiert werden. In einigen Aspekten können die Slice-Verwaltungsfunktionen in Verbindung mit Netzwerk-Slices 480 durch E2E-Multi-Slice-Unterstützungsfunktionen für MEC-fähige 5G-Bereitstellungen erleichtert werden, die von der MEC NFV-SCF 434 innerhalb des MEC-Hosts 402, dem MEC-Plattform-Manager 406 bereitgestellt werden, oder innerhalb einer anderen MEC-Einheit.
In einigen Aspekten kann sich das MEC NFV-SCF 434 innerhalb eines NFV-Orchestrators (NFVO) 435 befinden, der mit dem MEC-Orchestrator 410 sowie mit anderen MEC-Einheiten gekoppelt sein kann, wie in 4B und 11 dargestellt. Zusätzliche Multi-Slice-Unterstützungsfunktionalitäten und Anwendungsfälle werden in Verbindung mit 11,. 12, 13, 14, 15 und 16A - 16H veranschaulicht.
4B veranschaulicht eine MEC-Referenzarchitektur 400B in einer Network Function Virtualization (NFV)-Umgebung gemäß einem Beispiel. Die MEC-Architektur 400B kann so konfiguriert werden, dass sie Funktionalitäten gemäß der Spezifikation ETSI GR MEC-017 bereitstellt.
In einigen Aspekten kann ETSI MEC in einer NFV-Umgebung eingesetzt werden, wie in 4B dargestellt. In einigen Aspekten wird die MEC-Plattform als virtualisierte Netzwerkfunktion (VNF) bereitgestellt. Die MEC-Anwendungen können gegenüber den ETSI NFV Management and Orchestration (MANO)-Komponenten wie VNFs erscheinen (z.B. VIM 408, MEAO 410 und NFVO 435). Dies ermöglicht die Wiederverwendung der ETSI NFV MANO-Funktionalität. In einigen Aspekten kann der vollständige Satz der MANO-Funktionalität ungenutzt sein und es können bestimmte zusätzliche Funktionen erforderlich sein. Eine solche spezifische MEC-Anwendung wird mit dem Namen „MEC-App-VNF“ (oder ME-App-VNF) wie hierin erörtert bezeichnet. In einigen Aspekten wird die Virtualisierungsinfrastruktur als NFVI bereitgestellt und ihre virtualisierten Ressourcen werden vom virtualisierten Infrastrukturmanager (VIM) verwaltet. Zu diesem Zweck können eines oder mehrere der durch die ETSI NFV-Infrastrukturspezifikationen definierten Verfahren verwendet werden, d.h., ETSI GS NFV-INF 003, ETSI GS NFV-INF 004 und ETSI GS NFV-INF 005.
In einigen Aspekten werden die VNFs der MEC-Anwendung (oder der App) wie einzelne VNFs verwaltet, sodass eine MEC-in-NFV-Bereitstellung bestimmte Orchestrierungs- und Life Cycle Management (LCM)-Aufgaben wie definiert an die NFVO- und VNFM-Funktionsblöcke delegieren kann von ETSI NFV MANO.
In einigen Aspekten kann der Mobile Edge Platform Manager (MEPM) 406 in einen „Mobile Edge Platform Manager - NFV“ (MEPM-V) umgewandelt werden, der den LCM-Teil an einen oder mehrere Virtual Network Function Manager(s) (VNFM(s)). Der Mobile Edge Orchestrator (MEO), wie in der MEC-Referenzarchitektur ETSI GS MEC-003 definiert, kann in einen „Mobile Edge Application Orchestrator“ (MEAO) 410 umgewandelt werden, der die NFVO 435 für die Ressourcenorchestrierung und die Orchestrierung des Sets von MEC-App-VNFs als einen oder mehrere NFV-Netzwerkdienste (NSs) Verwendet.
In einigen Aspekten können die Mobile Edge Platform VNF, das MEPM-V und das VNFM (ME-Plattform LCM) als einzelnes Paket gemäß dem Ensemble-Konzept in 3GPP TR 32.842 bereitgestellt werden, oder das VNFM ist ein generisches VNFM gemäß ETSI GS NFV-IFA 009 und die Mobile Edge Platform VNF und das MEPM-V werden von einem einzigen Anbieter bereitgestellt.
In einigen Aspekten kann der Mp1-Referenzpunkt zwischen einer MEC-Anwendung und der ME-Plattform für die MEC-Anwendung optional sein, es sei denn, es handelt sich um eine Anwendung, die einen ME-Dienst bereitstellt und/oder konsumiert. Verschiedene hier diskutierte MEC-bezogene Schnittstellen und Referenzpunkte werden in den folgenden ETSI-bezogenen technischen Spezifikationen näher definiert: Spezifikationen ETSI GS MEC-003 und ETSI GR MEC-024.
Der MP1-Referenzpunkt ist ein Referenzpunkt zwischen der Mobile-Edge-Plattform und den Mobile-Edge-Anwendungen. Der MP1-Referenzpunkt bietet Dienstregistrierung, Diensterkennung und Kommunikationsunterstützung für Dienste. Es bietet auch andere Funktionen wie Anwendungsverfügbarkeit, Unterstützungsverfahren für die Verlagerung des Sitzungszustands, Verkehrsregeln und Aktivierung von DNS-Regeln, Zugriff auf dauerhaften Speicher und Tageszeitinformationen usw. Dieser Bezugspunkt kann zum Konsumieren und Bereitstellen dienstspezifischer Funktionen verwendet werden.
Der MP2-Referenzpunkt ist ein Referenzpunkt zwischen der mobilen Edge-Plattform und der Datenebene der Virtualisierungsinfrastruktur. Der MP2-Referenzpunkt wird verwendet, um die Datenebene anzuweisen, wie der Verkehr zwischen Anwendungen, Netzwerken, Diensten usw.
Der MP3-Referenzpunkt ist ein Referenzpunkt zwischen mobilen Edge-Plattformen und wird für die Steuerungskommunikation zwischen mobilen Edge-Plattformen verwendet.
In einigen Aspekten basiert der Mm3*-Referenzpunkt zwischen dem MEAO 410 und dem MEPM-V 406 auf dem Mm3-Referenzpunkt, wie durch ETSI GS MEC-003 definiert. Änderungen an diesem Referenzpunkt können konfiguriert werden, um die Aufteilung zwischen MEPM-V und VNFM (MEC-Anwendungen LCM) zu berücksichtigen.
In einigen Aspekten werden die folgenden neuen Referenzpunkte (Mv1, Mv2 und Mv3) zwischen Elementen der ETSI-MEC-Architektur und der ETSI-NFV-Architektur eingeführt, um die Verwaltung von MEC-App-VNFs zu unterstützen. Die folgenden Referenzpunkte beziehen sich auf bestehende NFV-Referenzpunkte, jedoch kann nur ein Teil der Funktionalität für ETSI MEC verwendet werden, und es können Erweiterungen erforderlich sein: Mv1 (dieser Referenzpunkt verbindet die MEAO und das NFVO; er steht in Beziehung zum Os-Ma-nfvo-Referenzpunkt, wie in ETSI NFV definiert); Mv2 (dieser Referenzpunkt verbindet den VNF-Manager, der das LCM der MEC-App-VNFs durchführt, mit dem MEPM-V, um den Austausch von LCM-bezogenen Benachrichtigungen zwischen diesen Entitäten zu ermöglichen; er bezieht sich auf den Ve-Vnfm-em-Referenzpunkt, wie in ETSI NFV, kann jedoch Ergänzungen enthalten und möglicherweise nicht alle von Ve-Vnfm-em angebotenen Funktionen nutzen); Mv3 (dieser Referenzpunkt verbindet den VNF-Manager mit der MEC-App-VNF-Instanz, um den Austausch von Nachrichten zu ermöglichen, wie in ETSI NFV definiert, kann jedoch Ergänzungen enthalten und möglicherweise nicht alle von Ve-Vnfm-vnf angebotenen Funktionen nutzen.
In einigen Aspekten werden die folgenden Referenzpunkte verwendet, wie sie von ETSI NFV definiert sind: Nf-Vn (dieser Referenzpunkt verbindet jede MEC-App-VNF mit dem NFVI); Nf-Vi (dieser Bezugspunkt verbindet das NFVI und das VIM); Os-Ma-nfvo (dieser Bezugspunkt verbindet das OSS und das NFVO. Es wird hauptsächlich verwendet, um NSs zu verwalten, d.h., mehrere VNFs, die verbunden und koordiniert sind, um einen Dienst bereitzustellen); Or-Vnfm (dieser Referenzpunkt verbindet das NFVO und das VNFM; er wird hauptsächlich für das NFVO verwendet, um VNF-LCM-Operationen aufzurufen); Vi-Vnfm (dieser Referenzpunkt verbindet das VIM und das VNFM; er wird hauptsächlich vom VNFM verwendet, um Ressourcenverwaltungsvorgänge aufzurufen, um die vom VNF benötigten Cloud-Ressourcen zu verwalten. In einer NFV-basierten MEC-Bereitstellung wird davon ausgegangen, dass dies Bezugspunkt 1:1 Mm6 entspricht); und Or-Vi (dieser Referenzpunkt verbindet die NFVO und das VIM; er wird hauptsächlich von der NFVO verwendet, um die Kapazität von Cloud-Ressourcen zu verwalten).
5 veranschaulicht eine MEC- und FOG-Netzwerktopologie 500 gemäß einem Beispiel. Bezugnehmend auf 5 kann die Netzwerktopologie 500 mehrere herkömmliche Netzwerkschichten umfassen, die durch die Verwendung eines hierin erörterten MEC-QoS-Managers erweitert werden können. Insbesondere die Beziehungen zwischen Endpunkten (bei Endpunkten/Dingen-Netzwerkschicht 550), Gateways (bei Gateway-Schicht 540), Zugangs- oder Edge-Computing-Knoten (z.B. bei Nachbarschaftsknotenschicht 530), Kernnetzwerk oder Routern (z.B. bei regionalen oder zentralen Office-Schicht 520), kann durch die Verwendung von Daten dargestellt werden, die über MEC-Hosts kommuniziert werden, die MEC-QoS-Manager verwenden, die sich an verschiedenen Knoten innerhalb der Topologie 500 befinden können.
Ein FOG-Netzwerk (z.B. eingerichtet auf der Gateway-Schicht 540) kann eine dichte geografische Verteilung von benutzernahen Edge-Geräten (z.B. FOG-Knoten) darstellen, die mit Speicherfähigkeiten ausgestattet sind (z.B. um die Notwendigkeit zu vermeiden, Daten in Cloud-Rechenzentren zu speichern)., Kommunikationsfähigkeiten (z.B. eher als über das Internet-Backbone geroutet), Steuerfähigkeiten, Konfigurationsfähigkeiten, Mess- und Verwaltungsfähigkeiten (und nicht in erster Linie von Netzwerk-Gateways wie im LTE-Kernnetz gesteuert), unter anderem. In diesem Zusammenhang zeigt 5 eine allgemeine Architektur, die mehrere MEC- und FOG-Knoten integriert - kategorisiert in verschiedene Schichten (basierend auf ihrer Position, Konnektivität und Verarbeitungsfähigkeiten usw.), wobei jeder Knoten eine MEC V2X-API implementiert, die es einer MEC-Anwendung oder einer anderen Entität eines MEC-fähigen Knotens ermöglicht, mit anderen Knoten zu kommunizieren.. Es versteht sich jedoch, dass solche FOG-Knoten durch Edge-Computing-Verarbeitungsknoten ersetzt oder erweitert werden können.
FOG-Knoten können je nach Topologie und Schicht, in der sie sich befinden, kategorisiert werden. Im Gegensatz dazu kann aus einer MEC-Standardperspektive jeder FOG-Knoten als MEC-Host oder als einfache Entität betrachtet werden, die eine MEC-App und eine leichtgewichtige MEC-Plattform hostet.
In einem Beispiel kann ein MEC- oder FOG-Knoten als eine Anwendungsinstanz definiert werden, die mit einem Gerät (MEC-Host) verbunden ist oder darauf läuft, das eine MEC-Plattform hostet. Hier verbraucht die Anwendung MEC-Dienste und ist einem MEC-Host im System zugeordnet. Die Knoten können migriert werden, mit verschiedenen MEC-Hosts verbunden sein oder MEC-Dienste von anderen (z.B. lokalen oder entfernten) MEC-Plattformen konsumieren.
Im Gegensatz zu diesem Ansatz sind herkömmliche V2V-Anwendungen für den Austausch und die Koordinierung von Informationen auf die Speicherung und Verarbeitung von Daten in der Cloud angewiesen. Eine Cloud-Datenanordnung ermöglicht eine langfristige Datenerfassung und -speicherung, ist jedoch nicht optimal für stark zeitvariable Daten wie Kollisionen, Ampelwechsel usw. und kann bei Latenzherausforderungen wie dem Anhalten eines Fahrzeugs möglicherweise fehlschlagen, wenn ein Kind auf die Straße rennt.
In einigen Aspekten können die MEC- oder FOG-Einrichtungen verwendet werden, um MEC- oder FOG-Knoten lokal zu erstellen, zu warten und zu zerstören, um über NFVs ausgetauschte Daten zu hosten und unter Verwendung von Ressourcen, die von einem MEC-QoS-Manager verwaltet werden, je nach Bedarf. Abhängig von den Echtzeitanforderungen in einem Fahrzeugkommunikationskontext kann eine hierarchische Struktur von Datenverarbeitungs- und Speicherknoten definiert werden. Zum Beispiel, einschließlich lokaler Verarbeitung mit extrem niedriger Latenz, regionaler Speicherung und Verarbeitung sowie Remote-Speicherung und -Verarbeitung in Cloud-Rechenzentren. Key Performance Indicators (KPIs) können verwendet werden, um festzustellen, wo Sensordaten am besten übertragen und wo sie verarbeitet oder gespeichert werden. Dies hängt typischerweise von der Abhängigkeit der Daten von der ISO-Schicht ab. Beispielsweise ändern sich die Daten der unteren Schicht (PHY, MAC, Routing usw.) in der Regel schnell und werden besser lokal verarbeitet, um die Latenzanforderungen zu erfüllen. Daten höherer Schichten wie Daten der Anwendungsschicht sind in der Regel weniger zeitkritisch und können in einem Remote-Cloud-Rechenzentrum gespeichert und verarbeitet werden. In einigen Aspekten sind die KPIs Metriken oder Betriebsparameter, die die räumliche Nähe zu einem V2X-bezogenen Zielereignis (z.B. Unfall usw.) umfassen können; physische Nähe zu anderen Objekten (z.B. wie viel Zeit erforderlich ist, um Daten von einem Daten- oder Anwendungsobjekt zu einem anderen Objekt zu übertragen); verfügbare Rechenleistung; oder aktuelle Last des Ziel-(Netzwerk-)Knotens und entsprechende Verarbeitungslatenz. In einigen Aspekten können die KPIs verwendet werden, um die automatisierte Lokalisierung und Verlagerung von Daten in einer MEC-Architektur zu erleichtern.
6 veranschaulicht die Verarbeitungs- und Speicherschichten in einem MEC- und FOG-Netzwerk 600 gemäß einem Beispiel. Die dargestellte Datenspeicher- oder Verarbeitungshierarchie 610 relativ zu den Cloud- und Fog-/Edge-Netzwerken ermöglicht eine dynamische Neukonfiguration von Elementen, um Latenz- und Datenverarbeitungsparameter zu erfüllen, wodurch E2E-Mehrschichtunterstützung für MEC-fähige 5G-Kommunikationsnetzwerke ermöglicht wird.
Die unterste Hierarchieebene befindet sich auf Fahrzeugebene. Auf dieser Ebene werden Daten zu früheren Beobachtungen oder Daten von anderen Fahrzeugen gespeichert. Die zweite Hierarchieebene ist die verteilte Lagerung auf mehrere Fahrzeuge. Diese verteilte Speicherung kann sich je nach Fahrzeugnähe zueinander oder einem Zielort (z.B. in der Nähe eines Unfalls) kurzfristig ändern. Die dritte Hierarchieebene befindet sich in einem lokalen Ankerpunkt, beispielsweise einer MEC-Komponente, die von einem Fahrzeug getragen wird, um Fahrzeuge in einem Fahrzeugpool zu koordinieren. Die vierte Ebene der Hierarchie ist der von MEC-Komponenten gemeinsam genutzte Speicher. Beispielsweise werden Daten zwischen verschiedenen Fahrzeugpools geteilt, die sich in Reichweite voneinander befinden.
Die fünfte Ebene der Hierarchie ist der feste Infrastrukturspeicher, beispielsweise in RSUs. Diese Ebene kann Daten von Entitäten in den Hierarchieebenen 1-4 aggregieren. Die sechste Ebene der Hierarchie ist die Speicherung in der festen Infrastruktur. Diese Ebene kann sich beispielsweise im Kernnetz eines Telekommunikationsnetzes oder einer Unternehmens-Cloud befinden. Andere Arten von Schichten und Schichtverarbeitung können aus diesem Beispiel folgen.
Auch wenn hierin offenbarte Techniken für Network Slicing, Ressourcenmanagement und Blockchain-Rückverfolgbarkeit in Verbindung mit MEC-bezogenen Architekturen diskutiert werden, bei denen mindestens eine MEC- Entität vorhanden ist, ist die Offenbarung diesbezüglich nicht beschränkt und die offenbarten Techniken können in Architekturen verwendet werden, die keine MEC-Entitäten verwenden. Zum Beispiel können Techniken im Zusammenhang mit Network Slicing, Ressourcenmanagement und Blockchain-Rückverfolgbarkeit auch in Nicht-MEC-Architekturen ausgeführt werden.
Obwohl hierin offenbarte Techniken in Verbindung mit einer MEC-Architektur und einer 5G-Architektur beschrieben sind, ist die Offenbarung diesbezüglich nicht beschränkt und die offenbarten Techniken können mit anderen Arten von drahtlosen Architekturen (z.B. 2G, 3G, 4G usw.) verwendet werden, die eine oder mehrere MEC-Entitäten verwenden.
Jede der hierin beschriebenen Funkverbindungen kann gemäß einer oder mehreren der folgenden Funkkommunikationstechnologien und/oder -standards betrieben werden, einschließlich, aber nicht beschränkt auf: eine Global System for Mobile Communications (GSM)-Funkkommunikationstechnologie, eine General Packet Radio Service (GPRS)-Funkkommunikationstechnologie, eine Enhanced Data Rates for GSM Evolution (EDGE)-Funkkommunikationstechnologie und/oder eine Third Generation Partnership Project (3GPP) Funkkommunikationstechnologie, zum Beispiel Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code Division Multiple Access 2000 (CDMA2000), Cellular Digitale Paketdaten (CDPD), Mobitex, dritte Generation (3G), leitungsvermittelte Daten (CSD), leitungsvermittelte Hochgeschwindigkeitsdaten (HSCSD), Universal Mobile Telecommunications System (dritte Generation) (UMTS (3G)), Breitbandcode Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS)), High Speed Packet Access (HSPA), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), High Speed Packet Access s Plus (HSPA), Universal Mobile Telecommunications System-Time-Division Duplex (UMTS-TDD), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-CDMA), 3. Generation Partnerschaftsprojekt Release 8 (vor der 4. Generation) (3GPP Rel. 8 (Pre-4G)), 3GPP rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10), 3GPP rel. 11 (3rd Generation Partnership Project Release 11), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3. Generation Partnership Project Release 14), 3GPP Rel. 15 (3rd Generation Partnership Project Release 15), 3GPP Rel. 16 (3rd Generation Partnership Project Release 16), 3GPP Rel. 17 (3rd Generation Partnership Project Release 17) und nachfolgende Releases (wie Rel. 18, rel. 19 usw.), 3GPP 5G, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed-Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4. Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (Dritte Generation) (CDMA2000 (3G)), Evolution-Data Optimized oder Evolution-Data Only (EV-DO), Advanced Mobile Phone System (1. Generation) (AMPS (1G)), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Digitales AMPS (2. Generation) (D-AMPS (2G)), Push-to- talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (norwegisch für Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (schwedische Abkürzung für Mobiltelefonisystem D, oder Mobiltelefonsystem D), Public Automated Land Mobile (Autotel/PALM), ARP (finnisch für Autoradiopuhelin, „Autoradiotelefon“), NMT (Nordic Mobilfunk), Hochleistungsversion von NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handy-Phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), auch als 3GPP Generic Access Network oder GAN-Standard bezeichnet), Zigbee, Bluetooth(r), Wireless Gigabit Alliance (WiGig)-Standard, mmWave-Standards im Allgemeinen (drahtlose Systeme, die mit 10-300 GHz und höher arbeiten, wie WiGig, IEEE 802.11ad, IEEE 802.11ay usw.), Technologien, die über 300 GHz arbeiten und THz-Bänder (3GPP/LTE-basiert oder IEEE 802.11p und andere) Fahrzeug-zu-Fahrzeug (V2V) und Fahrzeug-zu-X (V2X) und Fahrzeug-zu-Infrastruktur (V21) und Infrastruktur-zu-Fahrzeug (12V) Kommunikationstechnologien, 3GPP Cellular V2X, DSRC (Dedicated Short Range Communications) Kommunikationssysteme wie such Intelligent-Transport-Systems und andere (in der Regel mit 5850 MHz bis 5925 MHz betrieben), das europäische ITS-G5-System (d.h., die europäische Variante des auf IEEE 802.11p basierenden DSRC, einschließlich ITS-G5A (d.h., Betrieb von ITS-G5 in europäischen) ITS-Frequenzbänder für ITS für sicherheitsrelevante Anwendungen im Frequenzbereich 5.875 GHz bis 5.905 GHz), ITS-G5B (d.h., Betrieb in europäischen ITS-Frequenzbändern für nicht sicherheitsrelevante ITS-Anwendungen im Frequenzbereich 5.855 GHz bis 5.875 GHz), ITS-G5C (d. h. Betrieb von ITS-Anwendungen im Frequenzbereich 5.470 GHz bis 5.725 GHz)), DSRC in Japan im 700-MHz-Band (einschließlich 715 MHz bis 725 MHz) usw.
Die hierin beschriebenen Aspekte können im Kontext jedes Spektrumverwaltungsschemas verwendet werden, einschließlich eines dedizierten lizenzierten Spektrums, unlizenzierten Spektrums, (lizenzierten) gemeinsam genutzten Spektrums (wie LSA = Licensed Shared Access in 2,3-2,4 GHz, 3,4-3,6 GHz, 3,6-3,8 GHz und weiteren Frequenzen und SAS = Spectrum Access System / CBRS = Citizen Broadband Radio System in 3,55-3,7 GHz und weiteren Frequenzen). Anwendbare Frequenzbänder umfassen IMT-Spektrum (International Mobile Telecommunications) sowie andere Arten von Frequenzen/Bändern, z.B. Bänder mit nationaler Zuteilung (einschließlich 450 - 470 MHz, 902-928 MHz (Hinweis: Zugeteilt z.B. in den USA (FCC Part 15 Part)), 863-868,6 MHz (Anmerkung: z.B. in der Europäischen Union (ETSI EN 300 220) vergeben), 915,9-929,7 MHz (Anmerkung: z.B. in Japan vergeben), 917-923,5 MHz (Anmerkung: z.B. vergeben in Süd allocated Korea), 755-779 MHz und 779-787 MHz (Hinweis: z.B. in China vergeben), 790 - 960 MHz, 1710 - 2025 MHz, 2110 - 2200 MHz, 2300 - 2400 MHz, 2,4-2,4835 GHz (Hinweis: it ist ein ISM-Band mit globaler Verfügbarkeit und wird von der Wi-Fi-Technologiefamilie (11b/g/n/ax) und auch von Bluetooth verwendet), 2500 - 2690 MHz, 698-790 MHz, 610 - 790 MHz, 3400 - 3600 MHz, 3400 - 3800 MHz, 3,55-3,7 GHz (Anmerkung: Zugeteilt z.B. in den USA für Citizen Broadband Radio Service), 5,15-5,25 GHz und 5,25-5,35 GHz und 5,47-5,725 GHz und 5,725-5,85 GHz Bänder (Anmerkung: zugewiesen für Beispiel in den USA (FCC Teil 15), besteht aus vier U-NII-Bändern insgesamt 500 MHz Spektrum), 5,725-5,875 GHz (Hinweis: z.B. in der EU vergeben (ETSI EN 301 893)), 5,47-5,65 GHz (Hinweis : Zugeteilt z.B. in Südkorea, 5925-7125 MHz und 5925-6425 MHz Band (Anmerkung: in den USA bzw. der EU in Erwägung), IMT-Advanced-Spektrum, IMT-2020-Spektrum (voraussichtlich 3600-3800 MHz, 3,5 GHz Bänder, 700-MHz-Bänder, Bänder im Bereich von 24,25-86 GHz usw.), Frequenzen, die im Rahmen der 5G-Initiative „Spectrum Frontier“ der FCC zur Verfügung gestellt werden (einschließlich 27,5 - 28,35 GHz, 29,1 - 29,25 GHz, 31 - 31,3 GHz, 37 - 38,6 GHz, 38,6 - 40 GHz, 42 - 42,5 GHz, 57 - 64 GHz, 71 - 76 GHz, 81 - 86 GHz und 92 - 94 GHz usw.), das ITS-Band (Intelligent Transport Systems) von 5,9 GHz (typischerweise 5,85 -5,925 GHz) und 63-64 GHz, derzeit WiGig zugewiesene Bänder wie WiGig Band 1 (57,24-59,40 GHz), WiGig Band 2 (59,40-61,56 GHz) und WiGig Band 3 (61,56-63,72 GHz) und WiGig Band 4 (63,72-65,88 GHz), 57-64/66 GHz (z.B. havin g Near-globale Bezeichnung für Multi-Gigabit Wireless Systems (MGWS)/WiGig; in den USA (FCC part 15) als gesamtes 14-GHz-Spektrum zugeteilt, während in der EU (ETSI EN 302 567 und ETSI EN 301 217-2 für festes P2P) als insgesamt 9-GHz-Spektrum zugewiesen wurde), das 70,2 GHz - 71 GHz-Band, jedes Band zwischen 65,88 GHz und 71 GHz, Bänder, die derzeit Automobil-Radaranwendungen zugewiesen sind, wie 76-81 GHz, und zukünftige Bänder einschließlich 94-300 GHz und darüber. Darüber hinaus kann das Schema sekundär auf Bändern wie den TV-White-Space-Bändern (typischerweise unter 790 MHz) verwendet werden, wobei insbesondere die 400-MHz- und 700-MHz-Bänder vielversprechende Kandidaten sind. Neben Mobilfunkanwendungen können auch spezielle Anwendungen für vertikale Märkte wie PMSE (Program Making and Special Events), Medizin, Gesundheit, Chirurgie, Automobil, Low-Latency, Drohnen usw. angesprochen werden.
Hierin beschriebene Aspekte können auch eine hierarchische Anwendung des Schemas implementieren, indem z.B. eine hierarchische Priorisierung der Nutzung für verschiedene Benutzertypen (z.B. niedrige/mittlere/hohe Priorität usw.) basierend auf einem priorisierten Zugriff auf das Spektrum eingeführt wird, z.B. mit der höchsten Priorität für Tier-1-Benutzer, gefolgt von Tier-2, dann Tier-3-Benutzern usw.
Die hier beschriebenen Aspekte können auch auf verschiedene Single Carrier- oder OFDM-Varianten (CP-OFDM, SC-FDMA, SC-OFDM, filterbankbasierte Multicarrier (FBMC), OFDMA usw.) und insbesondere 3GPP NR (New Radio) angewendet werden. durch Zuweisen der OFDM-Trägerdatenbitvektoren zu den entsprechenden Symbolressourcen. Einige der Merkmale in diesem Dokument sind für die Netzseite definiert, wie Access Points, eNodeBs, New Radio (NR) oder Node-Bs der nächsten Generation (gNodeB oder gNB), wie sie im Kontext von 3GPP der fünften Generation verwendet werden (5G) Kommunikationssysteme, usw. Dennoch kann ein Benutzergerät (UE) auch diese Rolle übernehmen und als Zugangspunkte, eNodeBs, gNodeBs usw. fungieren. Dementsprechend können einige oder alle Merkmale, die für Netzwerkgeräte definiert sind, durch ein UE implementiert werden oder ein mobiles Computergerät.
In weiteren Beispielen können die vorhergehenden Beispiele von Netzwerkkommunikationen und -operationen in IoT und ähnliche gerätebasierte Netzwerkarchitekturen integriert werden. 7 veranschaulicht eine beispielhafte Domänentopologie für jeweilige IoT-Netzwerke, die über Links mit jeweiligen Gateways gekoppelt sind. Das IoT ist ein Konzept, bei dem eine große Anzahl von Computergeräten miteinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung auf sehr niedrigem Niveau bereitzustellen. Somit kann, wie hierin verwendet, ein Computergerät ein halbautonomes Gerät umfassen, das eine Funktion ausführt, wie unter anderem das Erfassen oder Steuern, in Kommunikation mit anderen Computergeräten und einem breiteren Netzwerk, wie dem Internet.
Es wurde beabsichtigt, MEC-Anwendungsfälle in mehrere Netzwerk- und Anwendungseinstellungen zu integrieren, einschließlich derjenigen, die Netzwerkarrangements von IoT-Bereitstellungen unterstützen. Computergeräte sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können (normalerweise am Rand oder Endpunkt eines Netzwerks) und können Sensoren, Aktoren und andere Eingabe-/Ausgabekomponenten umfassen, wie z.B. eine reale Umwelt. Zum Beispiel können Computergeräte Geräte mit niedrigem Stromverbrauch umfassen, die eingebettet oder an alltäglichen Dingen wie Gebäuden, Fahrzeugen, Paketen usw. angebracht sind, um Erfassungs-, Daten- oder Verarbeitungsfunktionalität bereitzustellen. In letzter Zeit sind Computergeräte populärer geworden und daher haben Anwendungen und Anwendungsfälle, die diese Geräte verwenden, stark zugenommen.
Es wurden verschiedene Standards vorgeschlagen, um Computergeräte und Anwendungsfälle für IoT-Netzwerke effektiver zu verbinden und zu betreiben, einschließlich solcher mit MEC- und Mobilnetzwerkarchitekturen. Einige der relevanten Kommunikations- und Netzwerkarchitekturstandards umfassen diejenigen, die von Gruppen wie ETSI, 3rd Generation Partnership Project (3GPP), Institute of Electrical and Electronics Engineers (IEEE) vertrieben werden, zusätzlich zu spezialisierten IoT-Anwendungsinteraktionsarchitekturen und Konfigurationsstandards, die von Working vertrieben werden Gruppen wie der Open Connectivity Foundation (OCF).
Computergeräte sind häufig in Bezug auf Speicher, Größe oder Funktionalität beschränkt, sodass eine größere Anzahl zu ähnlichen Kosten wie eine kleinere Anzahl größerer Geräte bereitgestellt werden kann. Ein Computergerät kann jedoch ein Smartphone, ein Laptop, ein Tablet, ein PC oder ein anderes größeres Gerät sein. Ferner kann ein Computergerät ein virtuelles Gerät sein, wie etwa eine Anwendung auf einem Smartphone oder einem anderen Computergerät. Computergeräte können IoT-Gateways beinhalten, die verwendet werden, um Computergeräte mit anderen Computergeräten und mit Cloud-Anwendungen zu koppeln, zur Datenspeicherung, Prozesssteuerung und dergleichen.
Netzwerke von Computergeräten können kommerzielle und Heimautomatisierungsgeräte umfassen, wie beispielsweise Wasserverteilungssysteme, elektrische Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Auf die Computergeräte kann über entfernte Computer, Server und andere Systeme zugegriffen werden, um beispielsweise Systeme zu steuern oder auf Daten zuzugreifen.
Das zukünftige Wachstum des Internets und ähnlicher Netzwerke kann eine sehr große Anzahl von Computergeräten umfassen. Dementsprechend werden im Kontext der hier diskutierten Techniken mehrere Innovationen für eine solche zukünftige Vernetzung der Notwendigkeit Rechnung tragen, dass alle diese Schichten ungehindert wachsen, verbundene Ressourcen entdecken und zugänglich machen und die Fähigkeit unterstützen, verbundene Ressourcen zu verbergen und zu unterteilen. Eine beliebige Anzahl von Netzwerkprotokollen und Kommunikationsstandards kann verwendet werden, wobei jedes Protokoll und jeder Standard entworfen ist, um spezifische Ziele zu adressieren. Darüber hinaus sind die Protokolle Teil der Struktur, die für Menschen zugängliche Dienste unterstützt, die unabhängig von Ort, Zeit oder Raum funktionieren. Zu den Innovationen gehören die Servicebereitstellung und die zugehörige Infrastruktur wie Hardware und Software; Sicherheitsverbesserungen; und die Bereitstellung von Diensten auf der Grundlage von Dienstgütebedingungen (QoS), die in Dienstgüte- und Dienstbereitstellungsvereinbarungen festgelegt sind. Es versteht sich, dass die Verwendung von Computervorrichtungen und Netzwerken mehrere neue Herausforderungen in einem heterogenen Konnektivitätsnetzwerk mit sich bringt, das eine Kombination aus drahtgebundenen und drahtlosen Technologien umfasst.
7 stellt insbesondere eine vereinfachte Zeichnung einer Domänentopologie bereit, die für mehrere IoT-Netzwerke verwendet werden kann, die Computervorrichtungen 704 umfassen, wobei die IoT-Netzwerke 756, 758, 760, 762 über Backbone-Links 702 mit jeweiligen Gateways 754 gekoppelt sind. Zum Beispiel können mehrere Computervorrichtungen 704 mit einem Gateway 754 und miteinander durch das Gateway 754 kommunizieren. Um die Zeichnung zu vereinfachen, ist nicht jedes Computergerät 704 oder jede Kommunikationsverbindung (z.B. Verbindung 716, 722, 728 oder 732) gekennzeichnet. Die Backbone-Links 702 können eine beliebige Anzahl von drahtgebundenen oder drahtlosen Technologien umfassen, einschließlich optischer Netzwerke, und können Teil eines lokalen Netzwerks (LAN), eines Weitverkehrsnetzwerks (WAN) oder des Internets sein. Außerdem erleichtern solche Kommunikationsverbindungen optische Signalwege zwischen den Computergeräten 704 und den Gateways 754, einschließlich der Verwendung von MUXing/DeMUXing-Komponenten, die die Verbindung der verschiedenen Geräte erleichtern.
Die Netzwerktopologie kann eine beliebige Anzahl von Typen von IoT-Netzwerken beinhalten, wie etwa ein Mesh-Netzwerk, das mit dem Netzwerk 756 unter Verwendung von Bluetooth Low Energy (BLE)-Links 722 bereitgestellt wird. Andere Arten von IoT-Netzwerken, die vorhanden sein können, umfassen ein drahtloses lokales Netzwerk (WLAN)-Netzwerk 758, das verwendet wird, um mit Computergeräten 704 über IEEE 802.11 (Wi-Fi®)-Verbindungen 728 zu kommunizieren, ein Mobilfunknetz 760, das verwendet wird, um mit Computergeräten 704 über ein LTE/LTE-A (4G)- oder 5G-Mobilfunknetz zu kommunizieren und ein Low-Power-Wide-Area-Netz (LPWA) 762, ein LPWA-Netz, das mit der von der LoRa-Allianz veröffentlichten LoRaWan-Spezifikation kompatibel ist, oder ein IPv6 over Low Power Wide-Area Networks (LPWAN)-Netzwerk, das mit einer von der Internet Engineering Task Force (IETF) veröffentlichten Spezifikation kompatibel ist. Darüber hinaus können die jeweiligen IoT-Netzwerke mit einem externen Netzwerkanbieter (z.B. einem Tier-2- oder Tier-3-Anbieter) unter Verwendung einer beliebigen Anzahl von Kommunikationsverbindungen kommunizieren, wie beispielsweise einer LTE-Mobilfunkverbindung, einer LPWA-Verbindung oder einer Verbindung basierend auf IEEE 802.15 .4 Standard, wie Zigbee®. Die jeweiligen IoT-Netzwerke können auch unter Verwendung einer Vielzahl von Netzwerk- und Internetanwendungsprotokollen wie dem Constrained Application Protocol (CoAP) betrieben werden. Die jeweiligen IoT-Netzwerke können auch mit Koordinatorgeräten integriert werden, die eine Kette von Links bereitstellen, die den Clusterbaum von verbundenen Geräten und Netzwerken bilden.
Jedes dieser IoT-Netzwerke kann Möglichkeiten für neue technische Funktionen bieten, wie beispielsweise die hierin beschriebenen. Die verbesserten Technologien und Netzwerke können das exponentielle Wachstum von Geräten und Netzwerken ermöglichen, einschließlich der Verwendung von IoT-Netzwerken in Nebelgeräten oder -systemen. Da die Verwendung solcher verbesserter Technologien zunimmt, können die IoT-Netzwerke für Selbstverwaltung, funktionale Weiterentwicklung und Zusammenarbeit entwickelt werden, ohne dass ein direkter menschlicher Eingriff erforderlich ist. Verbesserte Technologien können es IoT-Netzwerken sogar ermöglichen, ohne zentralisierte kontrollierte Systeme zu funktionieren. Dementsprechend können die hierin beschriebenen verbesserten Technologien verwendet werden, um Netzwerkmanagement- und Betriebsfunktionen weit über aktuelle Implementierungen hinaus zu automatisieren und zu verbessern.
In einem Beispiel kann die Kommunikation zwischen Computergeräten 704, wie beispielsweise über die Backbone-Links 702, durch ein dezentralisiertes System zur Authentifizierung, Autorisierung und Abrechnung (AAA) geschützt werden. In einem dezentralisierten AAA-System können verteilte Zahlungs-, Kredit-, Audit-, Autorisierungs- und Authentifizierungssysteme über die miteinander verbundene heterogene Netzwerkinfrastruktur implementiert werden. Dies ermöglicht es Systemen und Netzwerken, sich in Richtung eines autonomen Betriebs zu bewegen. Bei solchen autonomen Operationen können Maschinen sogar Personalverträge abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Dies kann das Erreichen beiderseitiger Ziele und eine ausgewogene Servicebereitstellung gemäß skizzierten, geplanten Service-Level-Agreements ermöglichen sowie Lösungen erreichen, die Messungen, Messungen, Rückverfolgbarkeit und Nachverfolgbarkeit ermöglichen. Die Schaffung neuer Supply-Chain-Strukturen und - Methoden kann es ermöglichen, eine Vielzahl von Dienstleistungen ohne menschliches Zutun zu erstellen, nach Wert zu schürfen und zusammenzubrechen.
Solche IoT-Netzwerke können durch die Integration von Sensortechnologien wie Ton, Licht, elektronischer Verkehr, Gesichts- und Mustererkennung, Geruch, Vibration in die autonomen Organisationen zwischen den Computergeräten weiter verbessert werden. Die Integration sensorischer Systeme kann eine systematische und autonome Kommunikation und Koordination der Servicebereitstellung im Hinblick auf vertragliche Serviceziele, Orchestrierung und QoS-basiertes Schwärmen und Verschmelzen von Ressourcen ermöglichen. Einige der einzelnen Beispiele der netzwerkbasierten Ressourcenverarbeitung umfassen Folgendes.
Das Maschennetz 756 kann zum Beispiel durch Systeme erweitert werden, die Inline-Transformationen von Daten in Informationen durchführen. Zum Beispiel können sich selbst bildende Ketten von Verarbeitungsressourcen, die ein Multilink-Netzwerk umfassen, die Umwandlung von Rohdaten in Informationen auf effiziente Weise verteilen und die Fähigkeit, zwischen Vermögenswerten und Ressourcen und deren zugehörige Verwaltung zu unterscheiden. Darüber hinaus können die richtigen Komponenten von Infrastruktur- und ressourcenbasierten Vertrauens- und Dienstindizes eingefügt werden, um die Datenintegrität, Qualität und Sicherheit zu verbessern und eine Metrik des Datenvertrauens bereitzustellen.
Das WLAN-Netzwerk 758 kann zum Beispiel Systeme verwenden, die eine Standardkonvertierung durchführen, um eine Multistandard-Konnektivität bereitzustellen, wodurch Computervorrichtungen 704, die unterschiedliche Protokolle verwenden, kommunizieren können. Weitere Systeme können eine nahtlose Interkonnektivität über eine Multistandard-Infrastruktur bereitstellen, die sichtbare Internet-Ressourcen und versteckte Internet-Ressourcen umfasst.
Kommunikationen in dem zellularen Netzwerk 760 können zum Beispiel durch Systeme verbessert werden, die Daten auslagern, Kommunikationen auf weitere entfernte Geräte ausdehnen oder beides. Das LPWA-Netzwerk 762 kann Systeme umfassen, die Nicht-Internet-Protokoll-(IP)-zu-IP-Verbindungen, Adressierung und Routing durchführen. Ferner kann jede der Computervorrichtungen 704 den geeigneten Transceiver für die Weitverkehrskommunikation mit dieser Vorrichtung umfassen. Ferner kann jede Computervorrichtung 704 andere Transceiver für die Kommunikation unter Verwendung zusätzlicher Protokolle und Frequenzen umfassen. Dies wird in Bezug auf die Kommunikationsumgebung und die Hardware einer in 9 und 10A-10B dargestellten IoT-Verarbeitungsvorrichtung weiter erörtert..
Schließlich können Cluster von Computergeräten ausgestattet sein, um mit anderen Computergeräten sowie mit einem Cloud-Netzwerk zu kommunizieren. Dies kann es den Computergeräten ermöglichen, ein Ad-hoc-Netzwerk zwischen den Geräten zu bilden, was ihnen ermöglicht, als ein einzelnes Gerät zu funktionieren, das als Fog (Nebel-)-Gerät, Fog-Plattform oder Fog-Netzwerk bezeichnet werden kann. Diese Konfiguration wird weiter unter Bezugnahme auf 4 diskutiert. 8 unten.
8 veranschaulicht ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von Computergeräten (Geräte 802), die als Fog-Geräte am Rand des Cloud-Computing-Netzwerks arbeiten, gemäß einem Beispiel. Das Mesh-Netzwerk von Computergeräten kann als Fog-Netzwerk 820 bezeichnet werden, das aus einem Netzwerk von Geräten aufgebaut wird, die am Rand der Cloud 800 betrieben werden. Um das Diagramm zu vereinfachen, ist nicht jedes Computergerät 802 beschriftet.
Das Nebelnetzwerk 820 kann als ein massiv verbundenes Netzwerk angesehen werden, in dem mehrere Computervorrichtungen 802 miteinander kommunizieren, zum Beispiel über Funkverbindungen 822. Das Fog-Netzwerk 820 kann eine horizontale, physische oder virtuelle Ressourcenplattform einrichten, die als zwischen IoT-Edge-Geräten und Cloud- oder Rechenzentren angesiedelt betrachtet werden kann. Ein Fog-Netzwerk kann in einigen Beispielen vertikal isolierte, latenzempfindliche Anwendungen durch geschichtete, föderierte oder verteilte Rechen-, Speicher- und Netzwerkkonnektivitätsvorgänge unterstützen. Ein Fog-Netzwerk kann jedoch auch verwendet werden, um Ressourcen und Dienste am und zwischen dem Edge und der Cloud zu verteilen. Somit sind Bezugnahmen in dem vorliegenden Dokument auf „Edge“, „Fog“ und „Cloud“ nicht notwendigerweise getrennt oder schließen sich gegenseitig aus.
Als ein Beispiel kann das Fog-Netzwerk 820 unter Verwendung einer Verbindungsspezifikation ermöglicht werden, die von der Open Connectivity Foundation TM (OCF) veröffentlicht wurde. Dieser Standard ermöglicht es Geräten, sich gegenseitig zu erkennen und Verbindungen für Verbindungen herzustellen. Es können auch andere Verbindungsprotokolle verwendet werden, darunter zum Beispiel das optimierte Link State Routing (OLSR) Protocol, der bessere Ansatz für das mobile Ad-hoc Networking (BATMAN) Routing Protocol oder das OMA Lightweight M2M (LWM2M) Protokoll, unter anderem.
In diesem Beispiel sind drei Typen von Computergeräten 802 gezeigt, Gateways 804, Datenaggregatoren 826 und Sensoren 828, obwohl beliebige Kombinationen von Computergeräten 802 und Funktionalität verwendet werden können. Die Gateways 804 können Edge-Geräte sein, die Kommunikationen zwischen der Cloud 800 und dem Fog 820 bereitstellen und können auch die Back-End-Prozessfunktion für Daten bereitstellen, die von Sensoren 828 erhalten werden, wie etwa Bewegungsdaten, Strömungsdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren 826 können Daten von einer beliebigen Anzahl der Sensoren 828 sammeln und die Back-End-Verarbeitungsfunktion für die Analyse durchführen. Die Ergebnisse, Rohdaten oder beides können über die Gateways 804 an die Cloud 800 weitergegeben werden. Die Sensoren 828 können beispielsweise vollständige Rechenvorrichtungen 802 sein, die in der Lage sind, sowohl Daten zu sammeln als auch die Daten zu verarbeiten. In einigen Fällen kann die Funktionalität der Sensoren 828 eingeschränkter sein, zum Beispiel das Sammeln der Daten und das Aktivieren der Datenaggregatoren 826 oder Gateways 804 zum Verarbeiten der Daten.
Kommunikationen von einer beliebigen der Computervorrichtungen 802 können entlang eines geeigneten Pfads (z.B. einem günstigsten Pfad) zwischen einer der Computervorrichtungen 802 weitergeleitet werden, um die Gateways 804 zu erreichen. In diesen Netzwerken stellt die Anzahl der Verbindungen eine erhebliche Redundanz bereit, die es ermöglicht, die Kommunikation aufrechtzuerhalten, selbst wenn mehrere Computergeräte 802 verloren gehen. Darüber hinaus kann die Verwendung eines Mesh-Netzwerks die Verwendung von Computergeräten 802 ermöglichen, die sehr stromsparend sind oder sich in einer Entfernung von der Infrastruktur befinden, da die Reichweite zum Verbinden mit einem anderen Computergerät 802 viel geringer sein kann als die Reichweite zum Verbinden mit der Gateways 804.
Der von diesen Computergeräten 802 bereitgestellte Fog 820 kann Geräten in der Cloud 800, wie etwa einem Server 806, als ein einzelnes Gerät präsentiert werden, das sich am Rand der Cloud 800 befindet, z.B. ein Fog-Gerät. In diesem Beispiel können die von der Fog-Vorrichtung kommenden Warnungen gesendet werden, ohne dass sie als von einer bestimmten Rechenvorrichtung 802 innerhalb des Fogs 820 stammend identifiziert werden. Auf diese Weise kann der Fog 820 als eine verteilte Plattform betrachtet werden, die Rechen- und Speicherressourcen bereitstellt, um unter anderem verarbeitungs- oder datenintensive Aufgaben wie Datenanalyse, Datenaggregation und maschinelles Lernen durchzuführen.
In einigen Beispielen können die Computergeräte 802 unter Verwendung eines zwingenden Programmierstils konfiguriert sein, z.B. wobei jedes Computergerät 802 eine spezifische Funktion und Kommunikationspartner hat. Die Computervorrichtungen 802, die die Fog-Vorrichtung bilden, können jedoch in einem deklarativen Programmierstil konfiguriert sein, der es den Computervorrichtungen 802 ermöglicht, ihre Operationen und Kommunikationen neu zu konfigurieren, wie zum Beispiel benötigte Ressourcen als Reaktion auf Bedingungen, Abfragen und Gerätefehler zu bestimmen. Als ein Beispiel kann eine Anfrage eines Benutzers, der sich bei einem Server 806 befindet, zu den Operationen einer Teilmenge von Geräten, die von den Computergeräten 802 überwacht werden, dazu führen, dass das Fog-Gerät 820 die Computergeräte 802 wie etwa bestimmte Sensoren 828 auswählt, die zum Antworten benötigt werden die Abfrage. Die Daten von diesen Sensoren 828 können dann durch eine beliebige Kombination der Sensoren 828, Datenaggregatoren 826 oder Gateways 804 aggregiert und analysiert werden, bevor sie von der Fog-Vorrichtung 820 an den Server 806 gesendet werden, um die Abfrage zu beantworten. In diesem Beispiel können die Rechenvorrichtungen 802 im Nebel 820 die verwendeten Sensoren 828 basierend auf der Abfrage auswählen, wie etwa das Hinzufügen von Daten von Durchflusssensoren oder Temperatursensoren. Wenn einige der Rechenvorrichtungen 802 nicht betriebsbereit sind, können ferner andere Rechenvorrichtungen 802 in der Fog-Vorrichtung 820 analoge Daten bereitstellen, falls verfügbar.
In anderen Beispielen können die oben beschriebenen Operationen und Funktionen durch eine Computervorrichtungsmaschine in der beispielhaften Form eines elektronischen Verarbeitungssystems verkörpert werden, in dem ein Satz oder eine Folge von Anweisungen ausgeführt werden kann, um das elektronische Verarbeitungssystem zu veranlassen, eine der folgenden Aufgaben auszuführen: die hierin erörterten Methodiken gemäß einem Beispiel. Die Maschine kann ein Computergerät oder ein IoT-Gateway sein, einschließlich einer Maschine, die durch Aspekte eines Personal Computers (PC), eines Tablet-PCs, eines Personal Digital Assistant (PDA), eines Mobiltelefons oder Smartphones oder einer anderen Maschine verkörpert wird, die in der Lage ist, Folgendes auszuführen: Anweisungen (sequentiell oder anderweitig), die von dieser Maschine auszuführende Aktionen spezifizieren.
Darüber hinaus sollen diese und ähnliche Beispiele für ein prozessorbasiertes System jeden Satz von einer oder mehreren Maschinen umfassen, die von einem Prozessor, einem Satz von Prozessoren oder einer Verarbeitungsschaltung gesteuert oder betrieben werden (z.B. eine Maschine in Form von einen Computer, ein UE, ein MEC-Verarbeitungsgerät, ein IoT-Verarbeitungsgerät usw.), um einzeln oder gemeinsam Anweisungen auszuführen, um eine oder mehrere der hierin erörterten Methodiken auszuführen. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Verarbeiten (z.B. Verarbeiten, Steuern, Erzeugen, Auswerten usw.) durch eine solche Verarbeitungsschaltung verkörpert werden.
9 veranschaulicht ein Blockdiagramm eines Cloud-Computing-Netzwerks oder einer Cloud 900 in Kommunikation mit mehreren Computergeräten gemäß einem Beispiel. Das Cloud-Computing-Netzwerk (oder „Cloud“) 900 kann das Internet darstellen oder möglicherweise ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), wie beispielsweise ein proprietäres Netzwerk für ein Unternehmen. Die Computergeräte können eine beliebige Anzahl unterschiedlicher Gerätetypen umfassen, die in verschiedenen Kombinationen gruppiert sind. Zum Beispiel kann eine Verkehrssteuerungsgruppe 906 Computergeräte entlang der Straßen in einer Stadt beinhalten. Diese Rechengeräte können Ampeln, Verkehrsflussmonitore, Kameras, Wettersensoren und dergleichen umfassen. Die Verkehrssteuerungsgruppe 906 oder andere Untergruppen können über drahtgebundene oder drahtlose Verbindungen 908 wie etwa LPWA-Verbindungen, optische Verbindungen und dergleichen mit der Cloud 900 kommunizieren. Ferner kann ein drahtgebundenes oder drahtloses Unternetzwerk 912 den Computervorrichtungen ermöglichen, miteinander zu kommunizieren, wie beispielsweise über ein lokales Netzwerk, ein drahtloses lokales Netzwerk und dergleichen. Die Computergeräte können ein anderes Gerät verwenden, wie etwa ein Gateway 910 oder 928, um mit entfernten Standorten wie etwa der Cloud 900 zu kommunizieren; die Computervorrichtungen können auch einen oder mehrere Server 930 verwenden, um die Kommunikation mit der Cloud 900 oder mit dem Gateway 910 zu ermöglichen. Zum Beispiel können der eine oder die mehreren Server 930 als zwischengeschalteter Netzwerkknoten arbeiten, um eine lokale Edge-Cloud- oder Fog-Implementierung in einem lokalen Netzwerk zu unterstützen. Ferner kann das abgebildete Gateway 928 in einer Cloud-zu-Gateway-zu-viele-Edge-Geräte-Konfiguration betrieben werden, wie beispielsweise mit den verschiedenen Computergeräten 914, 920, 924, die auf eine Zuweisung und Nutzung von Ressourcen in der Umgebung beschränkt oder dynamisch sind Cloud 900.
Andere beispielhafte Gruppen von Computervorrichtungen können unter anderem entfernte Wetterstationen 914, lokale Informationsterminals 916, Alarmsysteme 918, Geldautomaten 920, Alarmtafeln 922 oder sich bewegende Fahrzeuge, wie etwa Rettungsfahrzeuge 924 oder andere Fahrzeuge 926, beinhalten. Jedes dieser Computergeräte kann mit anderen Computergeräten, mit Servern 904, mit einer anderen IoT-Fog-Plattform oder -System oder einer Kombination davon kommunizieren. Die Gruppen von Computergeräten können in verschiedenen Wohn-, Gewerbe- und Industrieumgebungen (einschließlich sowohl in privaten als auch in öffentlichen Umgebungen) eingesetzt werden.
Wie aus 9 ersichtlich, kann eine große Anzahl von Computergeräten über die Cloud 900 kommunizieren. Dies kann es verschiedenen Computergeräten ermöglichen, autonom Informationen an andere Geräte anzufordern oder bereitzustellen. Zum Beispiel kann eine Gruppe von Computergeräten (z.B. die Verkehrssteuerungsgruppe 906) eine aktuelle Wettervorhersage von einer Gruppe von entfernten Wetterstationen 914 anfordern, die die Vorhersage ohne menschliches Eingreifen bereitstellen können. Ferner kann ein Notfallfahrzeug 924 von einem Geldautomaten 920 gewarnt werden, dass ein Einbruch im Gange ist. Wenn das Rettungsfahrzeug 924 zum Geldautomaten 920 fährt, kann es auf die Verkehrskontrollgruppe 906 zugreifen, um eine Freigabe für den Standort anzufordern, beispielsweise indem die Ampel rot wird, um den Querverkehr an einer Kreuzung zu blockieren ungehinderten Zugang zur Kreuzung haben.
Cluster von Computergeräten, wie etwa die entfernten Wetterstationen 914 oder die Verkehrssteuerungsgruppe 906, können ausgestattet sein, um mit anderen Computergeräten sowie mit der Cloud 900 zu kommunizieren. Dies kann es den Computergeräten ermöglichen, ein Ad-hoc-Netzwerk zwischen den Geräten zu bilden, was ihnen ermöglicht, als ein einzelnes Gerät zu funktionieren, das als Fog-Plattform oder -system bezeichnet werden kann (z.B. wie oben in Bezug auf 8).
Beispiel-Computergeräte
In weiteren Beispielen kann jeder der Rechenknoten oder -vorrichtungen, die bezüglich der vorliegenden Edge-Computing-Systeme und -Umgebung erörtert wurden, basierend auf den in den 10A und 10B und dargestellten Komponenten erfüllt werden.. Jeder Edge-Rechenknoten kann als eine Art von Gerät, Gerät, Computer oder anderes „Ding“ verkörpert sein, das mit anderen Edge-, Netzwerk- oder Endpunktkomponenten kommunizieren kann. Zum Beispiel kann ein Edge-Rechengerät als ein Smartphone, ein mobiles Computergerät, ein intelligentes Gerät, ein fahrzeuginternes Computersystem (z.B. ein Navigationssystem) oder ein anderes Gerät oder System verkörpert sein, das die beschriebenen Funktionen ausführen kann.
In dem vereinfachten Beispiel, das in 10A abgebildet ist, beinhaltet ein Edge-Rechenknoten 1000 eine Rechenmaschine (hier auch als „Rechenschaltung“ bezeichnet) 1002, ein Eingabe/Ausgabe-(I/O)-Subsystem 1008, einen Datenspeicher 1010, ein Kommunikationsschaltungs-Subsystem 1012 und optional ein oder mehrere Peripheriegeräte 1014. In anderen Beispielen kann jedes Computergerät andere oder zusätzliche Komponenten umfassen, wie beispielsweise diejenigen, die in Personal- oder Server-Computersystemen verwendet werden (z.B. eine Anzeige, Peripheriegeräte usw.). Außerdem können in einigen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderweitig einen Teil davon bilden.
Der Rechenknoten 1000 kann als jede Art von Maschine, Gerät oder Sammlung von Geräten verkörpert sein, die verschiedene Rechenfunktionen ausführen können. In einigen Beispielen kann der Rechenknoten 1000 als ein einzelnes Gerät verkörpert sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder andere integrierte System oder Gerät. In dem veranschaulichenden Beispiel beinhaltet der Rechenknoten 1000 einen Prozessor 1004 und einen Speicher 1006 oder ist als solche verkörpert. Der Prozessor 1004 kann als jede Art von Prozessor verkörpert sein, der in der Lage ist, die hierin beschriebenen Funktionen auszuführen (z.B. eine Anwendung auszuführen). Zum Beispiel kann der Prozessor 1004 als Mehrkernprozessor(en), ein Mikrocontroller oder ein anderer Prozessor oder eine Verarbeitungs-/Steuerschaltung ausgeführt sein. In einigen Beispielen kann der Prozessor 1004 als FPGA, als anwendungsspezifischer integrierter Schaltkreis (ASIC), rekonfigurierbare Hardware oder Hardware-Schaltung oder andere spezialisierte Hardware verkörpert sein, umfassen oder mit diesem gekoppelt sein, um die Ausführung der hierin beschriebenen Funktionen zu erleichtern.
Der Hauptspeicher 1006 kann als ein beliebiger Typ eines flüchtigen (z.B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtiger Speicher oder Datenspeicher ausgeführt sein, der die hier beschriebenen Funktionen ausführen kann. Ein flüchtiger Speicher kann ein Speichermedium sein, das Strom benötigt, um den Zustand der durch das Medium gespeicherten Daten aufrechtzuerhalten. Nicht einschränkende Beispiele für flüchtigen Speicher können verschiedene Arten von Direktzugriffsspeichern (RAM) umfassen, wie beispielsweise DRAM oder statische Direktzugriffsspeicher (SRAM). Ein bestimmter DRAM-Typ, der in einem Speichermodul verwendet werden kann, ist ein synchroner dynamischer Direktzugriffsspeicher (SDRAM).
In einem Beispiel ist das Speichergerät ein blockadressierbares Speichergerät, wie beispielsweise solche, die auf NAND- oder NOR-Technologien basieren. Ein Speicherbauelement kann auch ein dreidimensionales Koppelpunktspeicherbauelement (z.B. Intel 3D XPoint TM -Speicher) oder andere byteadressierbare, vor Ort beschreibbare nichtflüchtige Speicherbauelemente umfassen. Die Speichervorrichtung kann sich auf den Chip selbst und/oder auf ein verpacktes Speicherprodukt beziehen. In einigen Beispielen kann ein 3D-Crosspoint-Speicher (z.B. Intel 3D XPoint™-Speicher) eine stapelbare Crosspoint-Architektur ohne Transistoren umfassen, in der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und in der Bitspeicherung basiert auf einer Änderung des Schüttwiderstandes. In einigen Beispielen kann der gesamte oder ein Teil des Hauptspeichers 1006 in den Prozessor 1004 integriert sein. Der Hauptspeicher 1006 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie beispielsweise eine oder mehrere Anwendungen, Daten, die von der Anwendung(en), Bibliotheken und Treibern bearbeitet werden.
Die Rechenschaltung 1002 ist kommunikativ mit anderen Komponenten des Rechenknotens 1000 über das E/A-Subsystem 1008 gekoppelt, das als Schaltung und/oder Komponenten verkörpert sein kann, um Eingabe-/Ausgabeoperationen mit der Rechenschaltung 1002 (z.B. mit dem Prozessor 1004 und/oder den Hauptspeicher 1006) zu erleichtern und andere Komponenten der Rechenschaltung 1002. Zum Beispiel kann das E/A-Subsystem 1008 als Speichercontroller-Hubs, Eingabe-/Ausgabe-Steuerungs-Hubs, integrierte Sensor-Hubs, Firmware-Geräte, Kommunikationsverbindungen (z.B. Kabel, Lichtleiter, Leiterbahnen von gedruckten Leiterplatten usw.) und/oder andere Komponenten und Subsysteme, um die Eingabe-/Ausgabevorgänge zu erleichtern. In einigen Beispielen kann das E/A-Subsystem 1008 einen Teil eines System-on-a-Chip (SoC) bilden und zusammen mit einem oder mehreren des Prozessors 1004, des Hauptspeichers 1006 und anderer Komponenten der Rechenschaltkreis 1002 in den Rechenschaltkreis 1002 eingegliedert sein.
Das eine oder die mehreren veranschaulichenden Datenspeichergeräte 1010 können als jede Art von Gerät verkörpert sein, das für die Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert ist, wie zum Beispiel Speichergeräte und -schaltungen, Speicherkarten, Festplattenlaufwerke, Solid-State- Laufwerke oder andere Datenspeichergeräte. Jede Datenspeichervorrichtung 1010 kann eine Systempartition beinhalten, die Daten und Firmware-Code für die Datenspeichervorrichtung 1010 speichert. Jede Datenspeichervorrichtung 1010 kann auch eine oder mehrere Betriebssystempartitionen beinhalten, die Datendateien und ausführbare Dateien für Betriebssysteme speichern, beispielsweise abhängig von der Art des Rechenknotens 1000.
Die Kommunikationsschaltung 1012 kann als eine beliebige Kommunikationsschaltung, Vorrichtung oder Sammlung davon verkörpert sein, die Kommunikationen über ein Netzwerk zwischen der Rechenschaltung 1002 und einer anderen Rechenvorrichtung (z.B. einem Edge-Gateway-Knoten 612 des Edge-Computing-Systems 600) ermöglichen kann. Die Kommunikationsschaltung 1012 kann konfiguriert sein, um eine oder mehrere Kommunikationstechnologien (z.B. drahtgebundene oder drahtlose Kommunikation) und zugehörige Protokolle (z.B. ein zellulares Netzwerkprotokoll wie einen 3GPP 4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll wie z.B. IEEE 802.11/Wi-Fi®, ein drahtloses Weitverkehrsnetzprotokoll, Ethernet, Bluetooth® usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
Die beispielhafte Kommunikationsschaltung 1012 umfasst einen Netzwerkschnittstellencontroller (NIC) 1020, der auch als Host-Fabric-Interface (HFI) bezeichnet werden kann. Die NIC 1020 kann als eine oder mehrere Add-In-Boards, Tochterkarten, Netzwerkschnittstellenkarten, Controller-Chips, Chipsätze oder andere Geräte verkörpert sein, die vom Rechenknoten 1000 verwendet werden können, um eine Verbindung mit einem anderen Rechengerät (z.B. ein Edge-Gateway-Knoten 612) herzustellen. In einigen Beispielen kann die NIC 1020 als Teil eines System-on-a-Chip (SoC) verkörpert sein, das einen oder mehrere Prozessoren umfasst oder in einem Multichip-Package enthalten ist, das auch einen oder mehrere Prozessoren enthält. In einigen Beispielen kann die NIC 1020 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher und Speicher (nicht gezeigt) beinhalten, die lokal für die NIC 1020 sind. In solchen Beispielen kann der lokale Prozessor der NIC 1020 (der Allzweckbeschleuniger oder spezifische Beschleuniger umfassen kann) in der Lage sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltung 1002 auszuführen. Zusätzlich oder in solchen Beispielen kann der lokale Speicher der NIC 1020 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chipebene und/oder anderen Ebenen integriert sein.
Zusätzlich kann in einigen Beispielen jeder Rechenknoten 1000 ein oder mehrere Peripheriegeräte 1014 beinhalten. Solche Peripheriegeräte 1014 können jede Art von Peripheriegerät umfassen, die in einem Computergerät oder einem Server zu finden ist, wie beispielsweise Audioeingabegeräte, ein Display, andere Eingabe-/Ausgabegeräte, Schnittstellengeräte und/oder andere Peripheriegeräte, abhängig von der jeweiligen Art des Geräts Rechenknoten 1000. In weiteren Beispielen kann der Rechenknoten 1000 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Rechensystem (z.B. Client-Rechenknoten 602, Edge-Gateway-Knoten 612, Edge-Aggregationsknoten 622) oder ähnliche Formen von Geräten, Computern, Subsystemen, Schaltung oder andere Komponenten.
In einem detaillierteren Beispiel zeigt 10B ein Blockdiagramm eines Beispiels von Komponenten, die in einem Edge-Computing-Gerät (oder Knoten) 1050 zum Implementieren der hierin beschriebenen Techniken (z.B. Operationen, Prozesse, Verfahren und Methodiken) vorhanden sein können. Der Edge-Computing-Knoten 1050 kann beliebige Kombinationen der oben genannten Komponenten umfassen, und er kann ein beliebiges Gerät umfassen, das mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendbar ist. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 1050 angepasst sind, oder als Komponenten implementiert werden, die anderweitig in ein Gehäuse eines größeren Systems eingebaut sind
Der Edge-Computing-Knoten 1050 kann eine Verarbeitungsschaltung in Form eines Prozessors 1052 umfassen, der ein Mikroprozessor, ein Multi-Core-Prozessor, ein Multithread-Prozessor, ein Ultra-Low-Voltage-Prozessor, ein eingebetteter Prozessor oder andere bekannte Verarbeitungselemente sein können. Der Prozessor 1052 kann ein Teil eines System-on-a-Chip (SoC) sein, in dem der Prozessor 1052 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzelnen Gehäuse gebildet sind, wie beispielsweise die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien. Als Beispiel kann der Prozessor 1052 einen Prozessor auf Basis von Intel® Architecture Core™ umfassen, wie etwa einen Quark™, einen Atom™, einen i3-, einen i5-, einen i7-, einen i9- oder einen MCU-Klasse-Prozessor oder einen anderen solchen Prozessor von Intel® erhältlich. Es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie z.B. erhältlich von Advanced Micro Devices, Inc. (AMD), in Sunnyvale, Kalifornien, ein MIPS-basiertes Design von MIPS Technologies, Inc,. in Sunnyvale, Kalifornien, ein ARM-basiertes Design lizenziert von ARM Holdings, Ltd., oder einem Kunden davon, oder deren Lizenznehmern oder Adoptern. Die Prozessoren können Einheiten wie einen A5-A12-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc., beinhalten.
Der Prozessor 1052 kann mit einem Systemspeicher 1054 über eine Verbindung 1056 (z.B. einen Bus) kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher ein Direktzugriffsspeicher (RAM) gemäß einem Entwurf des Joint Electron Devices Engineering Council (JEDEC) sein, wie etwa die DDR- oder mobile DDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Speicherkomponente einem von JEDEC promulgierten DRAM-Standard entsprechen, wie JESD79F für DDR SDRAM, JESD79-2F für DDR2 SDRAM, JESD79-3F für DDR3 SDRAM, JESD79-4A für DDR4 SDRAM, JESD209 für Low Power DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speichervorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichervorrichtungen eine beliebige Anzahl unterschiedlicher Gehäusetypen sein, wie beispielsweise ein Einzelchip-Gehäuse (SDP), ein Doppelchip-Gehäuse (DDP) oder ein Quad-Die-Gehäuse (Q17P). Diese Geräte können in einigen Beispielen direkt auf ein Motherboard gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Geräte in anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum durch einen gegebenen Verbinder mit dem Motherboard verbunden sind. Es kann eine beliebige Anzahl anderer Speicherimplementierungen verwendet werden, wie beispielsweise andere Typen von Speichermodulen, beispielsweise Dual-Inline-Speichermodule (DIMMs) verschiedener Arten, einschließlich, aber nicht beschränkt auf microDIMMs oder MiniDIMMs.
Um eine dauerhafte Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen usw. bereitzustellen, kann ein Speicher 1058 auch über die Verbindung 1056 mit dem Prozessor 1052 verbunden sein. In einem Beispiel kann der Speicher 1058 über ein Solid-State-Disk-Laufwerk (SSDD) implementiert werden. Andere Geräte, die für den Speicher 1058 verwendet werden können, umfassen Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, XD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. In einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder beinhalten, die Chalkogenidglas verwenden, NAND-Flash-Speicher mit mehreren Schwellenwerten, NOR-Flash-Speicher, Phasenänderungsspeicher (PCM) mit einer oder mehreren Ebenen, ein Widerstandsspeicher, Nanodrahtspeicher, ferroelektrischer Transistor Random Access Memory (FeTRAM), antiferroelektrischer Speicher, magnetoresistiver Random Access Memory (MRAM) Speicher mit Memristor-Technologie, resistiver Speicher mit Metalloxidbasis, Sauerstoffleerstelle und leitfähiger Brücke Random Access Memory (CB-RAM .)) oder Spin-Transfer-Torque-(STT)-MRAM, ein auf Spintronik-Magnetübergang basierendes Gerät, ein auf magnetischem Tunnelübergang (MTJ) basierendes Gerät, ein DW-(Domain Wall) und SOT-(Spin-Orbit-Transfer)-basiertes Gerät, thyristorbasierte Speichervorrichtung oder eine Kombination aus einem der obigen oder andere Speicher.
In Implementierungen mit niedrigem Stromverbrauch kann der Speicher 1058 ein Speicher auf dem Chip oder Register sein, die dem Prozessor 1052 zugeordnet sind. In einigen Beispielen kann der Speicher 1058 jedoch unter Verwendung eines Mikro-Festplattenlaufwerks (HDD) oder eines Solid-State-Laufwerks (SSD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für den Speicher 1058 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandsänderungsspeicher, Phasenänderungsspeicher, holographische Speicher oder chemische Speicher.
Die Komponenten können über die Zwischenverbindung 1056 kommunizieren. Die Verbindung 1056 kann eine beliebige Anzahl von Technologien umfassen, einschließlich einer Industriestandard-Architektur (ISA), einer erweiterten ISA (EISA), einer peripheren Komponentenverbindung (PCI), einer erweiterten peripheren Komponentenverbindung (PCIx), PCI Express (PCIe) oder einer beliebigen Anzahl von andere Technologien. Die Verbindung 1056 kann ein proprietärer Bus sein, der beispielsweise in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Die Verbindung 1056 kann den Prozessor 1052 an einen Transceiver 1066 koppeln, um mit den verbundenen Edge-Geräten 1062 zu kommunizieren. Der Transceiver 1066 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z.B. 2,4 Gigahertz (GHz)-Übertragungen nach dem IEEE 802.15.4-Standard unter Verwendung des Bluetooth® Low Energy (BLE)-Standards, wie von der Bluetooth® Special Interest Group definiert, oder unter anderem den ZigBee®-Standard. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Geräten 1062 verwendet werden. Zum Beispiel kann eine drahtlose lokale Netzwerkeinheit (WLAN) verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronics Engineers (IEEE) zu implementieren. Auch können drahtlose Weitverkehrskommunikationen, z.B. gemäß einem zellularen oder anderen drahtlosen Weitverkehrsprotokoll, über eine drahtlose Weitverkehrsnetz-(WWAN)-Einheit erfolgen.
Der Funknetz-Transceiver 1066 (oder mehrere Transceiver) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Zum Beispiel kann der Edge-Computing-Knoten 1050 mit nahegelegenen Geräten kommunizieren, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Transceivers basierend auf BLE oder eines anderen Funkgeräts mit geringer Leistung, um Energie zu sparen. Weiter entfernte verbundene Edge-Geräte 1062, z.B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät mit unterschiedlichen Leistungspegeln oder über separate Transceiver erfolgen, beispielsweise einen lokalen Transceiver, der BLE verwendet, und einen separaten Mesh-Transceiver, der ZigBee verwendet.
Ein drahtloser Netzwerk-Transceiver 1066 (z.B. ein Funk-Transceiver) kann enthalten sein, um mit Geräten oder Diensten in der Edge-Cloud 1090 über lokale oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Funknetz-Transceiver 1066 kann ein LPWA-Transceiver sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 1050 kann unter Verwendung von LoRaWAN TM (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wurde, über einen weiten Bereich kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Transceiver verwendet werden, die Kommunikationen mit großer Reichweite und geringer Bandbreite implementieren, wie beispielsweise Sigfox und andere Technologien. Ferner können andere Kommunikationstechniken, wie beispielsweise zeitgeschlitztes Kanalspringen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist, verwendet werden.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den Systemen verwendet werden, die für den drahtlosen Netzwerk-Transceiver 1066 erwähnt wurden, wie hierin beschrieben. Zum Beispiel kann der Transceiver 1066 einen zellularen Transceiver umfassen, der Spreizspektrum-(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzwerkkommunikationen. Der Transceiver 1066 kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP (Third Generation Partnership Project)-Spezifikationen kompatibel sind, wie etwa Long Term Evolution (LTE) und 5. Generation (5G) Kommunikationssystemen, die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden. Ein Netzwerkschnittstellencontroller (NIC) 1068 kann enthalten sein, um eine drahtgebundene Kommunikation mit Knoten der Edge-Cloud 1090 oder anderen Geräten bereitzustellen, wie beispielsweise den verbundenen Edge-Geräten 1062 (z.B. die in einem Mesh arbeiten). Die kabelgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder auf anderen Arten von Netzwerken basieren, wie z.B. Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway, PROFIBUS oder PROFINET, Time Sensitive Networks (TSN) unter vielen anderen. Eine zusätzliche NIC 1068 kann enthalten sein, um eine Verbindung mit einem zweiten Netzwerk zu ermöglichen, beispielsweise eine erste NIC 1068, die Kommunikationen mit der Cloud über Ethernet bereitstellt, und eine zweite NIC 1068, die Kommunikationen mit anderen Geräten über einen anderen Netzwerktyp bereitstellt.
Angesichts der Vielfalt von Arten anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk können anwendbare Kommunikationsschaltungen, die von der Vorrichtung verwendet werden, eine oder mehrere der Komponenten 1064, 1066, 1068 oder 1070 beinhalten oder von diesen verkörpert sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z.B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltung verkörpert werden.
Der Edge-Computing-Knoten 1050 kann eine Beschleunigungsschaltung 1064 umfassen oder mit dieser gekoppelt sein, die durch einen oder mehrere KI-Beschleuniger, einen neuronalen Computing-Stick, neuromorphe Hardware, einen FPGA, eine Anordnung von GPUs, einen oder mehrere SoCs, einen oder mehrere verkörpert sein kann CPUs, ein oder mehrere digitale Signalprozessoren, dedizierte ASICs oder andere Formen von spezialisierten Prozessoren oder Schaltungen, die entworfen sind, um eine oder mehrere spezialisierte Aufgaben zu erfüllen. Diese Aufgaben können KI-Verarbeitung (einschließlich maschinellem Lernen, Training, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterkennung, Regelanalyse oder dergleichen umfassen. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zur Beschleunigung durch eine solche Beschleunigungsschaltung verkörpert werden.
Die Verbindung 1056 kann den Prozessor 1052 mit einem Sensor-Hub oder einer externen Schnittstelle 1070 koppeln, die verwendet wird, um zusätzliche Geräte oder Subsysteme zu verbinden. Die Vorrichtungen können Sensoren 1072 beinhalten, wie Beschleunigungsmesser, Niveausensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Positionierungssystems (GPS), Drucksensoren, Luftdrucksensoren und dergleichen. Der Hub oder die Schnittstelle 1070 kann ferner verwendet werden, um den Edge-Computing-Knoten 1050 mit Aktoren 1074 zu verbinden, wie etwa Leistungsschaltern, Ventilaktoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen.
In einigen optionalen Beispielen können verschiedene Eingabe-/Ausgabe(I/O)-Geräte innerhalb des Edge-Computing-Knotens 1050 vorhanden sein oder mit ihm verbunden sein. Zum Beispiel kann eine Anzeige oder ein anderes Ausgabegerät 1084 enthalten sein, um Informationen anzuzeigen, wie etwa Sensormesswerte oder Aktorposition. Eine Eingabevorrichtung 1086, wie beispielsweise ein Touchscreen oder eine Tastatur, kann enthalten sein, um Eingaben zu akzeptieren. Eine Ausgabevorrichtung 1084 kann eine beliebige Anzahl von Formen von Audio- oder visueller Anzeige umfassen, einschließlich einfacher visueller Ausgaben wie binäre Statusanzeigen (z.B. LEDs) und visuelle Mehrzeichenausgaben oder komplexere Ausgaben wie z.B. LCD Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Computing-Knotens 1050 generiert oder erzeugt wird.
Eine Batterie 1076 kann den Edge-Computing-Knoten 1050 mit Strom versorgen, obwohl er in Beispielen, in denen der Edge-Computing-Knoten 1050 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die an ein Stromnetz gekoppelt ist. Die Batterie 1076 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie sein, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen.
Ein Batteriemonitor/Ladegerät 1078 kann in dem Edge-Computing-Knoten 1050 enthalten sein, um den Ladezustand (SoCh) der Batterie 1076 zu verfolgen. Der Batteriemonitor/das Ladegerät 1078 kann verwendet werden, um andere Parameter der Batterie 1076 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 1076. Das Batterieüberwachungs-/Ladegerät 1078 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor, Phoenix Arizona, oder einen IC der UCD90xxx-Familie von Texas Instruments, Dallas, TX. Der Batteriemonitor/das Ladegerät 1078 kann die Informationen über die Batterie 1076 über die Verbindung 1056 an den Prozessor 1052 übermitteln. Der Batteriemonitor/das Ladegerät 1078 kann auch einen Analog-Digital-(ADC)-Wandler beinhalten, der es dem Prozessor 1052 ermöglicht, die Spannung der Batterie 1076 oder den Stromfluss von der Batterie 1076 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Computing-Knoten 1050 ausführen kann, wie etwa Übertragungsfrequenz, Maschennetzbetrieb, Erfassungsfrequenz und dergleichen.
Ein Stromblock 1080 oder eine andere Stromversorgung, die an ein Netz gekoppelt ist, kann mit dem Batteriemonitor/Ladegerät 1078 gekoppelt sein, um die Batterie 1076 zu laden. In einigen Beispielen kann der Leistungsblock 1080 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu erhalten, zum Beispiel über eine Schleifenantenne im Edge-Computing-Knoten 1050. Eine drahtlose Batterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in dem Batteriemonitor/Ladegerät 1078 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1076 und somit dem erforderlichen Strom ausgewählt werden. Das Aufladen kann unter anderem mit dem von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
Der Speicher 1058 kann Anweisungen 1082 in Form von Software-, Firmware- oder Hardwarebefehlen enthalten, um die hierin beschriebenen Techniken zu implementieren. Obwohl solche Befehle 1082 als Codeblöcke dargestellt sind, die in dem Speicher 1054 und dem Speicher 1058 enthalten sind, versteht es sich, dass jeder der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden kann, die beispielsweise in eine anwendungsspezifische integrierte Schaltung (ASIC) eingebaut sind.
In einem Beispiel können die über den Speicher 1054, den Speicher 1058 oder den Prozessor 1052 bereitgestellten Anweisungen 1082 als ein nicht flüchtiges, maschinenlesbares Medium 1060 verkörpert sein, das Code enthält, um den Prozessor 1052 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten durchzuführen 1050. Der Prozessor 1052 kann über die Verbindung 1056 auf das nichtflüchtige, maschinenlesbare Medium 1060 zugreifen. Zum Beispiel kann das nichtflüchtige, maschinenlesbare Medium 1060 durch für den Speicher 1058 beschriebene Geräte verkörpert sein oder kann spezifische Speichereinheiten wie optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwaregeräte umfassen. Das nichtflüchtige, maschinenlesbare Medium 1060 kann Anweisungen enthalten, um den Prozessor 1052 anzuweisen, eine spezifische Sequenz oder einen spezifischen Aktionsfluss durchzuführen, wie zum Beispiel in Bezug auf das/die Flussdiagramm(e) und das/die Blockdiagramm(e) der oben dargestellten Operationen und Funktionen beschrieben. Die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ sind, wie sie in verwendet werden, austauschbar.
In einem Beispiel kann die Rechenvorrichtung 1050 unter Verwendung von Komponenten/Modulen/Blöcken 1052 - 1086 implementiert werden, die als IP-Blöcke konfiguriert sind. Jeder IP-Block kann einen Hardware-RoT (z.B. Device Identifier Composition Engine oder DICE) enthalten, wobei ein DICE-Schlüssel verwendet werden kann, um die IP-Block-Firmware für einen Peer-IP-Block oder aus der Ferne für eine oder mehrere Komponenten/Module/Blocks 1062-1080 zu identifizieren und zu bestätigen .
In weiteren Beispielen umfasst ein maschinenlesbares Medium auch jedes materielle Medium, das Anweisungen zur Ausführung durch eine Maschine speichern, codieren oder tragen kann und die die Maschine veranlassen, eine oder mehrere der Methodiken der vorliegenden Offenbarung auszuführen, oder das in der Lage ist, Datenstrukturen zu speichern, zu codieren oder zu tragen, die von solchen Befehlen verwendet werden oder diesen zugeordnet sind. Ein „maschinenlesbares Medium“ kann somit Festkörperspeicher und optische und magnetische Medien umfassen, ist jedoch nicht darauf beschränkt. Spezifische Beispiele für maschinenlesbare Medien umfassen nichtflüchtige Speicher, einschließlich, aber nicht beschränkt auf, beispielsweise Halbleiterspeichervorrichtungen (z.B. elektrisch programmierbarer Festwertspeicher (EPROM), elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM)) und Flash-Speichergeräte; Magnetplatten wie interne Festplatten und Wechselplatten; magnetooptische Platten; und CD-ROM- und DVD-ROM-Platten. Die von einem maschinenlesbaren Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung unter Verwendung eines beliebigen von mehreren Übertragungsprotokollen (z.B. HTTP) übertragen oder empfangen werden.
Ein maschinenlesbares Medium kann durch eine Speichervorrichtung oder eine andere Vorrichtung bereitgestellt werden, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. In einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen für Anweisungen repräsentativ sein, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), gepackte Anweisungen (z.B. in mehrere Pakete aufgeteilt) oder dergleichen umfassen. Die Informationen, die die Anweisungen in dem maschinenlesbaren Medium darstellen, können durch Verarbeitungsschaltungen in die Anweisungen verarbeitet werden, um jede der hierin erörterten Operationen zu implementieren. Das Ableiten der Anweisungen aus den Informationen (z.B. Verarbeitung durch die Verarbeitungsschaltung) kann beispielsweise umfassen: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in den Anweisungen.
In einem Beispiel kann die Ableitung der Anweisungen das Zusammenstellen, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltung) umfassen, um die Anweisungen aus einem Zwischen- oder vorverarbeiteten Format zu erzeugen, das von dem maschinenlesbaren Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erstellen. Zum Beispiel können die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binärem ausführbarem Code usw.) auf einem oder mehreren entfernten Servern vorliegen. Die Quellcodepakete können bei der Übertragung über ein Netzwerk verschlüsselt und bei Bedarf entschlüsselt, dekomprimiert, assembliert (z.B. verlinkt) und auf einem lokalen Rechner kompiliert oder interpretiert (z.B. in eine Bibliothek, eigenständige ausführbare Datei usw.), und vom lokalen Computer ausgeführt.
Jedes der Blockdiagramme der 10A und 10B sollen eine Ansicht auf hoher Ebene von Komponenten einer Vorrichtung, eines Subsystems oder einer Anordnung eines Edge-Computing-Knotens darstellen. Es versteht sich jedoch, dass einige der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können und eine andere Anordnung der gezeigten Komponenten in anderen Implementierungen auftreten kann.
Die Entwicklung von MEC-fähigen 5G-Kommunikationssystemen kann von der Fähigkeit abhängen, Kommunikationsdienstanbietern (CoSPs) die Möglichkeit zu geben, mehrere Netzwerk-Slice-Instanzen unter Verwendung virtueller Netzwerke über einen gemeinsamen Satz physischer (drahtloser und kabelgebundener) Netzwerkinfrastruktur bereitzustellen, zu verwalten, anzupassen und zu betreiben. E2E-Netzwerk-Slice-Instanzen können virtuelle Ressourcen (z.B. Ressourcen, die virtuelle logische Netzwerke bilden) herausarbeiten, indem physische Computer- und Netzwerkressourcen der MEC-fähigen 5G-Kommunikationssysteme verwendet werden. Jede Netzwerk-Slice-Instanz kann spezifisch konfiguriert werden, um Leistung in Bezug auf einen QoS-Fluss eines UE zu unterstützen, einschließlich Kapazität, Sicherheitsstufen, geografische Abdeckung und Latenz. Netzwerk-Slice-Instanzen können die Partitionierung von RAN-Funktionalitäten, der Kerninfrastruktur einschließlich des Evolved Packet Core (EPC) sowie der Switches und Rechenzentrumsserver umfassen, auf denen die mobilen 5G-Anwendungen und -Inhalte gehostet werden können (z. B. als VNFs, die von MEC-Anwendungen bereitgestellt werden, die auf Ressourcen eines MEC-Systems innerhalb des 5G-Kommunikationsnetzes ausgeführt werden). Darüber hinaus können 5G EDGE-Geräte in Abhängigkeit von den Service-Latenz-Anforderungen ebenfalls in den Slice aufgenommen werden. Hierin offenbarte Techniken kann die Bereitstellung einer oder mehrerer Netzwerk-Slice-Instanzen und die dynamische Verwaltung von Ressourcen umfassen, die von den Netzwerk-Slices verwendet werden, einschließlich der Generierung und Implementierung einer oder mehrerer Slice-Konfigurationsrichtlinien, basierend auf der Utility-Funktionsmodellierung und der Bewertung der Latenz oder anderer Eigenschaften von MEC und Nicht-MEC Kommunikationsverbindungen für einen bestimmten NSI, der in einem MEC-fähigen 5G-Kommunikationsnetzwerk konfiguriert ist.
In einigen Aspekten werden 5G-Netzwerk-Slices eine breite Palette von Anwendungen unterstützen, von (semi-)autonomen Fahrzeugen, Remote-Gesundheitsüberwachung und Ersthelferanwendungen, die die beste Sicherheit/Rückverfolgbarkeit erfordern, bis hin zu mehrstufigen Smartphone-Plänen und IoT-Geräten, die ohne zusätzliche Rückverfolgbarkeit der Ressourcen in Ordnung sein können.
11 veranschaulicht ein MEC-fähiges 5G-Kommunikationssystem 1100 und ein Beispiel für die Abbildung von MEC-Entitäten auf einige der 5G-Systemkomponenten (nämlich AF und UPF) gemäß einem Beispiel. Das MEC-fähige 5G-Kommunikationssystem 1100 kann so konfiguriert werden, dass es Funktionalitäten gemäß der Spezifikation ETSI GS MEC-003, der Spezifikation ETSI GR MEC-017 und/oder der Spezifikation ETSI GS MEC-024 bereitstellt.
Die Abbildung von MEC- Entitäten in ein 5G-System ist in 11 dargestellt. Insbesondere: eine MEC-Plattform wird als eine bestimmte Anwendungsfunktion (AF) in 3GPP implementiert; die Data Plane in der MEC-Architektur entspricht einer User Plane Function (UPF) in 3GPP, und die MEC-Apps werden in 3GPP auf den lokalen DN (Data Network) abgebildet.
Wie in 11 dargestellt, ist das UE 1102 über einen Remote Radio Head (RRH) 1104 an das RAN 1106 gekoppelt. Das RAN 1106 kommuniziert mit einer MEC-Datenebene 1110 innerhalb von NFVI 1108. Die MEC-Datenebene 1110 innerhalb des NFVI 1108 ist über einen N6-Referenzpunkt mit einem lokalen Datennetzwerk 1112 der MEC-Plattform 1118 gekoppelt. Die MEC-Plattform 1118 ist über einen MEC-Referenzpunkt Mp1 mit dem lokalen Datennetzwerk 1112 gekoppelt. Die MEC-Plattform 1118 kann als VNF instanziiert sein und kann MEC-APIs 1120 und 1122 vier Kommunikation mit MEC-Apps 1114 und 1116, die als VNFs instanziiert sind, innerhalb des lokalen Datennetzwerks 1112 beinhalten. Die MEC-Plattform 1118 kann ferner API-Konfigurationsinformationen 1124 (z.B. wie durch die ETSI MEC-009-Spezifikation bereitgestellt) und Anwendungsaktivierungsfunktionen 1126 (z.B. wie durch die ETSI MEC-011-Spezifikation bereitgestellt) umfassen. Die MEC-Plattform 1118 ist mit 3GPP-Netzwerkfunktionen wie NEF 1130, PCF 1128, SMF 1132 und UPF 1134 gekoppelt. Die MEC-Datenebene 1110 ist mit den 3GPP-Netzwerkfunktionen SMF 1132 und der UPF 1134 gekoppelt. Sowohl die MEC-Plattform 1118 als auch die MEC-Datenebene 1110 sind über den UPF 1134 mit dem zentralen Datennetzwerk 1136 und dem Anwendungsserver 1138 gekoppelt.
In einigen Aspekten kann das RAN 1106 vollständig virtualisiert sein (z.B. als ein VNF, der Ressourcen des MEC-Systems verwendet). In einigen Aspekten kann das MEC-fähige 5G-Kommunikationssystem 1100 ein MEC NFV-SCF verwenden, um E2E-Mehrschichtunterstützung bereitzustellen, einschließlich Generieren und Implementieren einer oder mehrerer Slice-Konfigurationsrichtlinien basierend auf Utility-Funktionsmodellierung und Bewertung der Latenz oder anderer Eigenschaften von MEC- und Nicht-MEC-Kommunikationsverbindungen für einen bestimmten NSI, der in einem MEC-fähigen 5G-Kommunikationsnetzwerk konfiguriert ist. Zum Beispiel kann ein QoS-Fluss des UE 1102 einer Netzwerk-Slice-Instanz zugeordnet sein, die ein virtuelles RAN 1106 umfasst, wobei die MEC-Datenebene 1110 als eine 5G-UPF-Netzwerkfunktion fungiert, eine MEC-App wie 1114 innerhalb des lokalen Datennetzwerks 1112, und die MEC-Plattform VNF 1118, die als 5G-AF-Netzwerkfunktion fungiert. In dieser Hinsicht umfasst eine spezifische NSI, die einer QoS des UE 1102 zugeordnet ist, Nicht-MEC-Referenzpunkte (z.B. drahtlose physikalische Verbindungen zwischen dem UE 1102, dem RRH 1104 und dem virtuellen RAN 1106 sowie dem N3 und N6 5G Referenzpunkte. Der NSI kann ferner MEC-Referenzpunkte beinhalten, wie etwa die Mp1-Referenzpunkte zwischen der MEC-App 1114 innerhalb des lokalen Datennetzwerks 1112 und der MEC-Plattform-VNF 1118. Ein MEC NFV-SCF (z.B. wie in Verbindung mit 12 - 15 dargestellt) kann konfiguriert sein, um eine Slice-Konfigurationsrichtlinie basierend auf einer Utility-Funktionsmodellierung und Bewertung von Latenz-assoziierten sowohl der MEC- als auch der Nicht-MEC-Referenzpunkte, die von dem Slice verwendet werden, zu generieren und die generierte Slice-Konfigurationsrichtlinie an eine andere Verwaltungsentität (z.B. einen Virtualisierungsinfrastrukturmanager), um zu bestimmen, ob die generierte Slice-Konfigurationsrichtlinie basierend auf verfügbaren Ressourcen innerhalb des MEC-fähigen 5G-Kommunikationsnetzwerks 1100 implementiert werden soll.
In einigen Aspekten kann die Slice-Konfigurationsrichtlinie eine Ressourcenzuweisungsrichtlinie zum Zuweisen von Ressourcen zu einem neuen NSI oder zum Neuzuordnen von Ressourcen, die von einem bestehenden NSI verwendet werden, umfassen. In anderen Aspekten kann die Slice-Konfigurationsrichtlinie eine VM-Zuweisungs- und Übergaberichtlinie umfassen. Der hier verwendete Begriff „VM-Zuweisung“ bezieht sich auf die Zuweisung von Netzwerkressourcen zu virtuellen Ressourcen eines MEC-Systems (z.B. einer verwendeten VM), wobei die Ressourcen z.B. zum Ausführen einer MEC-App oder zum Instanziieren einer VNF verwendet werden, um verschiedene Netzwerkfunktionen wie eine RAN- oder eine MEC-Plattform durchzuführen. Der hier verwendete Begriff“VM-Übergabe“ ähnelt dem Konzept einer Übergabe und beinhaltet das Beenden einer vorhandenen virtuellen Ressource (z.B. an einem ersten Standort), die zum Instanziieren einer VNF verwendet wird, die bestimmte Netzwerkfunktionen (z. B. RAN-Funktionen, MEC-Plattformfunktionen, MEC-Anwendungsfunktionen usw.), und die Konfiguration einer anderen virtuellen Ressource (z. B. an einem zweiten Standort zur Instanziierung derselben VNF). Das Konzept des VM-Handoffs wird in Verbindung mit 16A - 16H ausführlicher dargestellt..
In einigen Aspekten besteht ein Ausgangspunkt für die Bestimmung der Slice-Konfigurationsrichtlinie durch das NFV-SCF darin, zu berücksichtigen, dass die End-to-End (E2E) 5G-Systemleistung nicht nur von der Leistung des Funkzugangsnetzes (RAN) und des Kernnetzes abhängt (CN)-Systemkomponenten allein, sondern auch von der Leistung der MEC-Funktionseinheiten. Zum Beispiel setzt sich die E2E-Latenz (d.h., zwischen dem UE 1102 und der MEC-Anwendung 1114) aus dem Packet Delay Budget (PDB) zusammen (in den 5G-Spezifikationen als E2E-Verzögerung zwischen dem UE und UPF definiert, mit einer Konfidenz von 98%) und die zusätzliche Verzögerung zwischen der UPF und dem lokalen DN 1112 (wo sich die MEC-Apps befinden). Diese zweite Latenzkomponente wird von den Eigenschaften des 5G QoS Class Identifier (5QI) in 3GPP nicht berücksichtigt, obwohl sie für die Leistungsoptimierung wichtig ist, da sie eng mit der Instanziierung der MEC-Anwendungen zusammenhängt. Da sich der Endpunkt des Benutzerverkehrs bei der MEC-App 1114 (befindet sich im DN 1112) befindet, sind daher netzwerkslice-relevante Leistungsmetriken (wie die PDB) nicht ausreichend, um die E2E-Gesamtleistung und die Gesamtlatenz für alle Kommunikationsverbindungen des NSI zu beschreiben. Stattdessen können die MEC-Anwendungsinstanzierung und die zugehörige Zuweisung der virtuellen Maschine (VM) in Betracht gezogen werden (wie hierin in Verbindung mit Funktionalitäten des MEC NFV-SCF erörtert), um die gesamte E2E-Latenzzeit gemäß den Slice-Anforderungen zu optimieren.
Die offenbarten Techniken umfassen die Bereitstellung eines MEC-Systems in einem (vollständig virtualisierten) 5G-System (z.B. RAN 1106 ist ein virtuelles RAN oder als VNF instanziiertes vRAN), das mehrere Netzwerk-Slice-Instanzen aufnehmen kann. Diese Bereitstellung umfasst die Optimierung der Instanziierung von MEC-Apps und die Zuweisung von VMs in der Edge-Cloud gemäß einer Slice-Aware-Strategie mit einem MEC NFV-SCF. Das Ziel dieser Zuweisung besteht darin, die E2E-Leistungsanforderungen der Netzwerk-Slice-Instanz (die Teil einer Service Level Agreement (SLA) zwischen dem Netzwerkbetreiber und einem vertikalen Branchenanbieter sein kann) zu erfüllen.
Wie oben erwähnt, spezifizieren einige 3GPP-Standards für 5G-Netzwerke das PDB (Paketverzögerungsbudget) als die obere Grenze für die Zeit, die ein Paket zwischen dem UE und der UPF verzögert werden kann, wobei der letzte Teil des Verkehrspfads auf Benutzerebene nicht berücksichtigt wird (d.h., über den N6-Referenzpunkt vom UPF zur MEC-App, wie in 11). Genauer gesagt, definiert die PDB eine obere Grenze für die Zeit, die ein Paket zwischen dem UE und der UPF verzögert werden darf (bei GBR-Strömen ist der PDB als maximale Verzögerung mit einem Konfidenzniveau von 98 % zu interpretieren, wenn der QoS-Strom den GFBR nicht überschreitet). Bei einem verzögerungskritischen GBR-QoS-Fluss wird ein Paket, das mehr als der Wert der PDB verzögert ist, als verloren gezählt (es kann je nach Implementierung entweder zugestellt oder verworfen werden), wenn der übertragene Datenburst kleiner als das maximale Datenburstvolumen innerhalb des Zeitraums ist der PDB überschreitet der QoS-Fluss die GFBR nicht. Bei Nicht-GBR-Flows kann es in nicht überlasteten Szenarien bei 98 Prozent der Pakete zu keiner Verzögerung kommen, die die PDB des 5QI überschreitet.
In dieser Hinsicht gibt es in 3GPP keine Standardmittel/Parameter, um eine vollständige E2E-Leistung sicherzustellen, da die MEC-App eine Einheit außerhalb des 3GPP-Netzwerks ist. Darüber hinaus gibt es bei der Instanziierung eines bestimmten Netzwerk-Slice immer noch keine Standarddefinition einer (logischen) Schnittstelle zwischen einem MEC-System, das in einem 5G-Netzwerk bereitgestellt werden soll, und dem 5G-Netzwerk-Orchestrator, um eine Slice-spezifische VM-Zuweisung und Übergabe über den MEC durchzuführen und 3GPP-relevanten Entitäten und von Slice-Performance-konformem Mobility Management anzuwenden.
12 veranschaulicht Aspekte der offenbarten Techniken für E2E-Mehrschichtunterstützung für MEC-fähige 5G-Bereitstellungen gemäß einem Beispiel. Bezugnehmend auf 12 enthält das Diagramm 1200 mehrere Entitäten aus der Architektur 1100, die zum Implementieren von hierin offenbarten Techniken für die E2E-Mehrschichtunterstützung verwendet werden können.
Die offenbarten Techniken beinhalten ein iteratives Verfahren (z.B. wie in 13 - 15 dargestellt), die sowohl 3GPP (d.h., das Operations Support System (OSS) 1202 eines MNO) als auch ETSI MEC-Einheiten (d.h., den Multi-Access Edge Orchestrator (MEAO) 1204 des MEC-Systems und den Network Function Virtualization Orchestrator (NFVO) 1206) umfasst., dessen Ziel eine Slice-effiziente Zuweisung von VMs ist, insbesondere bei der Existenz von UE-Mobilität.
Das oben erwähnte iterative Verfahren soll von der MEC NFV-SCF 1208 gesteuert werden, die innerhalb der NFVO 1206 implementiert werden kann. Alternativ könnte die Funktion NFV-SCF eine von der NFVO getrennte Instanz sein, z.B. im OSS oder eine unabhängige Instanz, die von einem Dritten verwaltet wird. Die Rolle von NFV-SCF 1208 ähnelt der Rolle der Policy Control Function (PCF) in einer 5G-Architektur. Der grundlegende Unterschied besteht jedoch darin, dass der NFV-SCF 1208, der innerhalb der NFV-Domäne (und nicht der 3GPP-Systemdomäne) implementiert ist, anstelle von Verkehrssteuerung und Richtlinien- und Gebührensteuerung (PCC) so konfiguriert sein, dass sie eine Slice-bezogene VM-Zuweisungspolitik formuliert, die Eingaben vom 5GS (OSS 1202), wie z. B. die Netzwerk-Slice-Vorlage (NST) 1212, die Slice-spezifische Eingaben und Attribute enthält, sowie Machbarkeitsrückmeldungen vom Virtualized Infrastructure Manager (VIM) 1210 des Systems berücksichtigt. Die offenbarten Techniken können Anwendung finden, wenn es um einzelne und mehrere MNOs und MEC-Systeme geht.
Der Vorteil der vorgeschlagenen Techniken besteht darin, dass durch die Nutzung der Slice-spezifischen Konfigurierbarkeit des virtualisierten, MEC-fähigen 5G-Kommunikationssystems eine vollständige Integration von MEC in 5G-Systeme erreicht werden kann, indem der Standard aus Managementsicht beeinflusst wird. Die offenbarten Techniken können verwendet werden, um die Einführung von MEC-Einsätzen in 5G-Systemen zu erleichtern. Folglich können die offenbarten Techniken (sofern standardisiert) Verbesserungen einführen, die mit dem langfristigen Einsatz von MEC verbunden sind.
13 veranschaulicht ein Flussdiagramm 1300 offenbarter Techniken für die Slice-bewusste VM-Zuweisung in MEC-fähigen 5G-Systembereitstellungen gemäß einem Beispiel.
Das Ziel der offenbarten Techniken besteht darin, die Slice-Stabilität unter dem Gesichtspunkt der QoS-Garantie zu erreichen und aufrechtzuerhalten (d.h., wenn eine SLA zwischen einem Netzbetreiber und einem Dienstanbieter oder dem Endanwendungsverbraucher erreicht wird). Wie im Flussdiagramm 1300 ausgeführt, kann ein Slice-Aware-Optimierungsframework basierend auf der Kommunikation zwischen dem MEC-System und dem 3GPP-basierten 5G-System verwendet werden, um eine Slicezentrierte VM-Zuweisung zu realisieren. Unter der Annahme eines gegebenen Satzes von Netzwerk-Slice-Instanzen, UEs, sowie mehreren N_KNIRPS QoS-Flüsse pro UE (d.h., QoS-Fluss 0, 1, ..., N_KNIRPS - 1) werden die offenbarten Techniken in der folgenden iterativen Prozedur zusammengefasst, die auch in 13 beschrieben ist.
Die Verarbeitung kann bei Operation 1302 beginnen (der erste QoS-Fluss wird als QF-i bezeichnet, mit i = 0). Ein einzelnes UE kann verschiedenen PDU-Sitzungen zugeordnet sein, die mehrere QoS-Flüsse enthalten. Mehrere UEs können von einer Netzwerk-Slice-Instanz bedient werden (die für ein bestimmtes UE nicht spezifisch ist). Außerdem können mehrere Netzwerk-Slice-Instanzen innerhalb des MEC-fähigen 5G-Kommunikationsnetzwerks (z.B. 1100) vorhanden sein.
13 veranschaulicht Verarbeitungsfunktionen, die einer äußeren Schleife und einer inneren Schleife zugeordnet sind. Die äußere Schleife analysiert alle QoS-Flüsse (einschließlich neuer).
Die äußere Schleife kann bei Operation 1304 beginnen, wenn das UE auf QoS-Fluss QF-i überprüft wird. Der QoS-Flow kann ein vorhandener (also mit einem bereits zugeordneten Anwendungsendpunkt auf der MEC-Seite) oder ein neuer sein. Wenn dies ein neuer QoS-Fluss ist, kann eine neue MEC-App instanziiert und für die Datenkommunikation mit dem UE über die zugewiesene NSI verwendet werden. Ein bestimmter NSI kann dem neuen QoS-Fluss zugeordnet sein oder ein neuer NSI kann für den QoS-Fluss konfiguriert werden. Andernfalls (im Falle eines existierenden Flusses) können neue QoS-Messungen (oder QoS-Vorhersagen) eine Änderung der Netzwerk-Slice-Instanz (die diesem QoS-Flow zugeordnet ist) oder die Instanziierung einer neuen Slice auslösen. Zusammenfassend kann die NFV-SCF 1208 gemäß den obigen Annahmen eine Netzwerk-Slice-Instanz identifizieren (und anschließend erstellen), die mit dem QoS-Fluss QF-j verknüpft ist, was bei Operation 1310 durchgeführt wird. Die spezifische Implementierung einer Erzeugung/Instanziierung einer Netzwerk-Slice-Instanz liegt außerhalb des Umfangs der offenbarten Techniken.
Bei Operation 1306 wird bestimmt, ob das Ende der QoS-Flussliste erreicht ist (z.B. i = N_KNIRPS). Wenn alle QoS-Flüsse im System (sowohl vorhandene als auch neue) analysiert wurden, endet die äußere Iteration bei Operation 1308.
Bei Operation 1310 wird eine Netzwerk-Slice-Instanzidentifizierung durchgeführt. Genauer gesagt kann die NFV-SCF 1208 einen Netzwerk-Slice NS-j (der eine bestimmte Branche bedient, z.B. Automobil, Industrieautomation usw.) und ihre E2E-Leistungsanforderung(en) identifizieren (und anschließend erzeugen). Das 3GPP-Verwaltungssystem bestimmt die Liste von UEs, die diesem Slice zugeordnet sind, und ob die UEs die Instanziierung neuer MEC-Anwendungen erfordern, die über diesen Slice verbunden sind.
Die innere Schleife umfasst die Operationen 1312 - 1318. Die innere Schleife bezieht sich auf die Identifizierung einer geeigneten MEC-App-Instanziierung und endet, nachdem das VIM 1210 die abgeleitete Slice-Konfigurationsrichtlinie implementiert hat (die eine VM-Zuweisungs- und Übergaberichtlinie umfassen kann).
Bei Operation 1312 wird eine E2E-Nutzenfunktionsmodellierung und - bewertung durchgeführt, die im Folgenden ausführlicher erläutert wird. Die scheibenspezifische MEC-App (z.B. 1114), deren Instanziierung möglicherweise den gesamten E2E-Leistungsbedarf des Dienstes erfüllen muss, wird identifiziert. Anschließend wird, unterstützt durch einen Signalisierungsrahmen zwischen dem OSS 1202 des 3GPP 5G-Systems, der MEAO 1204 des MEC-Systems und der NFVO 1206, der Beitrag jeder (virtualisierten) MEC- und 3GPP 5G-Systemeinheit zur gesamten E2E-Slice-Leistung, d.h., zwischen den UE und die aktuelle lokale DN 1112, ausgewertet. Die Nutzenfunktion kann durch die NFV-SCF 1208 innerhalb der NFVO 1206 modelliert werden. In einigen Aspekten kann die Nutzenfunktion basierend auf einer bestehenden SLA oder einer anderen vorkonfigurierten Nutzenfunktionsauswahl ausgewählt werden.
Bei Vorgang 1314 kann ein schnittbewusster Entwurf einer MEC-App-Instanziierungsrichtlinie durchgeführt werden und eine Slice-Konfigurationsrichtlinie kann von der NFV-SCF 1208 generiert werden. Unter Ausnutzung der entworfenen Nutzenfunktion entwirft der NFV-SCF 1208 die Slice-Konfigurationsrichtlinie, die eine VM-Zuweisungs- und Handoff-Sequenzrichtlinie über die virtualisierten MEC- und 3GPP-5G-Entitäten umfassen kann, die die E2E-Slice-Anforderung erfüllt.
Bei Operation 1316 können Richtlinienimplementierungsanweisungen erzeugt werden. Genauer gesagt weist die NFVO 1206 (oder die NFV-SCF 1208) das VIM 1210 an, eine solche Richtlinie zu implementieren, nachdem sie bei Operation 1314 eine Slice-bewusste, eine optimale Slice-Konfigurationsrichtlinie (z.B. einschließlich einer VM-Zuweisungs- und Übergaberichtlinie) abgeleitet hat.
Operation 1318 ist mit der Kommunikation von Feedback verbunden (z.B. vom VIM 1210 an die NFVO 1206). Die folgenden zwei Feedback-Optionen können verwendet werden.
(a) Umsetzung der Richtlinien. In diesem Fall kann die NFV-SCF 1208 (oder die NFVO 1206)-Anforderung erfüllt werden (z.B. bestimmt das VIM 1210, dass genügend Netzwerkressourcen vorhanden sind, um einen NSI neu zu konfigurieren oder eine VM-Übergabe durchzuführen, um von dem NSI verwendete Ressourcen umzustrukturieren). Das VIM 1210 übermittelt dann ein Bestätigungssignal (oder ein „positives“ Rückkopplungssignal) an das NFVO 1206 und implementiert die Slice-Konfigurationsrichtlinie. Die innere Schleife endet dann, der Index i wird bei Operation 1320 inkrementiert (was einen neuen QoS-Fluss anzeigt) und Operation 1304 wird erneut besucht, um zu prüfen, ob der neue QoS-Fluss existiert.
(b) VIM fordert eine Zurückweisung und Neuberechnung der Slice-Konfigurationsrichtlinie an. In diesem Fall kann die Anforderung zum Implementieren der bestimmten Slice-Konfigurationsrichtlinie vom VIM 1210 nicht erfüllt werden (z.B. basierend auf unzureichenden Netzwerkressourcen). Das VIM 1210 sendet dann ein „negatives“ Feedback-Signal zurück an das NFVO, das versucht, ein Gleichgewicht zwischen der Befriedigung des Leistungsbedarfs der Slice-E2E und der Verfügbarkeit der VM-Ressourcen herzustellen. Die Verarbeitung kann dann bei Operation 1312 wieder aufgenommen werden, um eine neue Slice-Konfigurationsrichtlinie zu bestimmen.
In einigen Aspekten kann die innere Verarbeitungsschleife basierend auf Fall (b) oben, sofern die NFVO-Anforderung nicht erfüllt wird, ohne eine bestimmte Austrittsbedingung (nicht wünschenswert) fortgesetzt werden. Nichtsdestotrotz könnte es mehrere Mechanismen geben, um eine endlose innere Schleifenverarbeitung zu vermeiden, die hier nicht erörtert werden. Einige Beispiele werden durch die folgenden Austrittsbedingungen gegeben: eine maximale Anzahl von Iterationen bei einem bestimmten Zeitbudget, die maximale Anzahl akzeptabler Lösungen, bevor die Anfrage abgelehnt und QoS neu ausgehandelt wird, usw. Als Beispiel kann die QoS-Aushandlung mit dem vertikalen Segment schnell eine Einigung erzielen (und somit die innere Schleife beenden), wenn die SLA-Compliance-Flexibilität durch ein Konfidenzniveau ausgedrückt wird (z.B. SLA-Compliance, wenn eine E2E-Latenzanforderung für mindestens 95% der gesamten Aktivitätszeit des Slice erfüllt ist).
Verarbeitungsfunktionen, die den Operationen 1312 und 1314 zugeordnet sind, werden weiter unten in Bezug auf 14 bzw. 15 genauer beschrieben.
14 ist ein Nachrichtensequenzdiagramm 1400 , das die verschiedenen Latenzkomponenten während der direkten Kommunikation zwischen einem UE-Client (z.B. UE 1102) und einer MEC-App am Rand wie der MEC-App 1114 (die einige auf der MEC-Plattform ausgeführte MEC-Dienste nutzt) darstellt 1118) darstellt, gemäß einem Beispiel.
Bezugnehmend auf 14 ist ein Kommunikationsaustausch zwischen einem UE 1402, einer Basisstation 1404 (z.B. virtuelles RAN 1106), einer MEC-Datenebene 1406 (oder 1110), einer MEC-App 1408 in einem lokalen Datennetzwerk (z.B. MEC-App 1114' im lokalen Datennetz 1112) und MEC-APIs 1410 (z.B. MEC-API 1120 auf der MEC-Plattform 1118) dargestellt.
14 veranschaulicht die verschiedenen Latenzen, die mit Kommunikations- und Verarbeitungsverzögerungen zwischen verschiedenen Netzwerkknoten 1402 - 1410 verbunden sind. Nicht-MEC-Schnittstellen (oder Referenzpunkte) umfassen die drahtlose physische Verbindung zwischen dem UE 1402 und der Basisstation 1404, den N3-Referenzpunkt zwischen der Basisstation 1404 und der MEC-Datenebene 1406 und den N6-Referenzpunkt zwischen der MEC-Datenebene 1406 und die MEC-App 1408. MEC-Referenzpunkte beinhalten den MP1-Referenzpunkt zwischen der MEC-App 1408 und der MEC-API 1410.
E2E-Nutzenfunktionsmodellierung und -bewertung Operation 1312 in FIG. 13)
Ausgangspunkt für die Bewertung der E2E-Performance (z.B. bezüglich der Gesamtlatenzzeit des UE) ist die Betrachtung aller an der Round Trip Time (RTT) des Nutzerverkehrs beteiligten Entitäten, die sich auf den Betrieb 1312 der in 13 dargestellten Funktionalitäten bezieht.
Wie in 14 zu sehen ist, kann zusätzlich zu der typischen Latenz, die durch die 3GPP-Netzscheibe (UE-UPF) gegeben ist, die Verzögerung zwischen der UE 1402 und der MEC-Datenebene (DP) 1406 berücksichtigt werden, zusätzlich zu der Zeit, die die MEC-App 1408 benötigt, um Informationen (bei Operation 1420) von der MEC-Plattform (vorzugsweise in einem lokalen DN instanziiert) zu sammeln/zu konsumieren, also in der Nähe der MEC-App, und die Ausgabe über den Mp1-Referenzpunkt bereitzustellen. Das Paketverzögerungsbudget (PDB) des 5G-Kommunikationssystems umfasst PDB 1412 für die Aufwärtsstrecke und PDB 1434 für die Abwärtsstrecke. Bei der Bestimmung der Gesamtlatenz können jedoch auch zusätzliche Verarbeitungsverzögerungen berücksichtigt werden (z. B. Berücksichtigung der Zeitverzögerung zwischen dem Zeitpunkt t2, zu dem die MEC-Datenebene 1406 die Kommunikation mit der MEC-App 1408 einleitet, und dem Zeitpunkt t8, zu dem die MEC-Datenebene 1406 die Kommunikation mit der Basisstation 1404 einleitet..
Beispiele für solche Informationen, die von der MEC-API 1410 auf der MEC-Plattform gesammelt werden können, umfassen z.B. Funknetzinformationen (RNI), Standortinformationen oder andere scheibenspezifische Informationen (z.B. ein Paket, das Informationen über PC5 trägt, Konfigurationsparameter), im MEC-Server gespeichert, der über eine für eine Fahrzeuganwendung relevante V2X-API verfügbar ist, oder ein Paket, das Informationen über IoT-Kommunikationsparameter enthält, die über eine mögliche „IoT-API“ verfügbar sind).
Daher wird die RTT für ein UE, das einen Dienst ausführt, der zu einer bestimmten Netzwerk-Slice-Instanz gehört, wie folgt ausgedrückt: RTT = d_3GPPd_MEC, wo d_3GPP ist die Verzögerung vom Zeitpunkt t0 (wenn das UE 1402 die Kommunikation mit der Basisstation 1404) bis zum Zeitpunkt t3 (wenn die MEC-App 1408 die Operation 1420 bildet) und vom Zeitpunkt t7 (wenn die MEC-App 1408 die Kommunikation mit der MEC-Datenebene 1406 initiiert) bis zum Zeitpunkt t10 (wenn das UE 1402 eine Kommunikation von der Basisstation 1404 empfängt); und d_MEC ist die Verzögerung vom Zeitpunkt t3 (wenn die MEC-App 1408 die Operation 1420 durchführt) bis zum Zeitpunkt t7 (wobei die MEC-App 1408 die Kommunikation mit der MEC-Datenebene 1406 einleitet).
Nachdem die verschiedenen Komponenten der E2E-Leistung des Slice modelliert und bewertet wurden, z.B. hinsichtlich der Latenz, wie in 14 gezeigt, können die Verwaltungsentitäten des 3GPP 5G-Systems (d.h., des OSS 1202) und des MEC-Systems (d.h., der MEAO 1204 und der NFVO 1206) interagieren, um die MEC-App zu instanziieren (z.B. 1408 oder 1114). Als Ergebnis der Interaktion kann die NFVO 1206 die Werte der beteiligten Latenzkomponenten erhalten - bezogen auf sowohl relevante 3GPP- als auch MEC-Referenzpunkte. Dann kann das NFV-SCF 1208 diese Informationen erhalten, die Latenz-„Engpässe“ identifizieren und basierend auf einer Nutzenfunktion eine Slice-Konfigurationsrichtlinie (z.B. eine VM-Zuweisungsrichtlinie) bestimmen. Beispiele für Nutzenfunktionen (die basierend auf einem SLA ausgewählt oder vorkonfiguriert werden können) umfassen die folgenden:

(a) 5G-System (5GS) effizienzzentrierte Nutzenfunktion. Das Ziel ist die Minimierung der durch die 3GPP 5GS-Komponenten eingeführten E2E-Verzögerung, die sich auf die Slice-QoS auswirkt, vorbehaltlich einer maximal tolerierbaren RTT-Beschränkung. τ_slice (mit einem gewissen Vertrauen in die Zufriedenheit, z.B. für mehr als 95 % der Aktivitätszeit des Slices) und eine feste Verzögerung der ETSI MEC-Systemkomponenten, d _3GPP. Mathematisch wird dies wie folgt ausgedrückt: $\begin{array}{l} m i n i m i z e d_{3 G P P} \\ s . t . P r o b (R T T > τ_{s l i c e}) < p, d_{M E C} = {\bar{d}}_{M E C} . \end{array}$
(b) effizienzzentrierter ETSI MEC-Nutzungsgrad. Das Ziel ist die Minimierung der durch die ETSI MEC-Komponenten eingeführten E2E-Verzögerung, die die Slice-QoS beeinflusst, vorbehaltlich einer maximal tolerierbaren RTT-Beschränkung. τ_slice (mit einem gewissen Vertrauen in die Zufriedenheit, z.B. für mehr als 95 % der Aktivitätszeit des Slice) und eine feste Verzögerung der 3GPP 5GS-Komponenten, d _3GPP. Mathematisch wird dies wie folgt ausgedrückt: $\begin{array}{l} m i n i m i z e d_{M E C} \\ s . t . P r o b (R T T > τ_{s l i c e}) < p, d_{3 G P P} = {\bar{d}}_{3 G P P} . \end{array}$
(c) Gesamtwirkungsgradnutzen. Unter der Annahme, dass Latenzbeiträge die gleiche Priorität haben, besteht das Ziel darin, Slice-SLA-Verstöße zu minimieren, daher: $m i n i m i z e P r o b (R T T > τ_{s l i c e}) .$

15 ist ein Nachrichtensequenzdiagramm 1500, das eine beispielhafte Kommunikation zum Ableiten und Implementieren einer Slice-bewussten VM-Zuweisungsrichtlinie gemäß einem Beispiel veranschaulicht. Bezugnehmend auf 15 kann der beispielhafte Kommunikationsaustausch zwischen dem OSS 1502 (oder 1202), dem MEAO 1504 (oder 1204), dem NFVO 1506 (oder 1206) und dem VIM 1508 (oder 1210) stattfinden.
Slice-aware MEC App Instantiation Policy Design (Operation 1314 in FIG. 13)
Wie in 15 dargestellt, ruft das NFVO 1506 (oder das NFV-SCF 1208 innerhalb des NFVO) Latenzinformationen 1510 ab, die Nicht-MEC-Kommunikationsverbindungen zugeordnet sind (z.B. PDB-Latenz sowie Latenz auf dem N6-Referenzpunkt) sowie Latenzinformationen 1512, die mit verknüpft sind MEC-Kommunikationsverbindungen wie der MP1-Referenzpunkt. Bei Operation 1514 vergleicht die NFV-SCF Latenzkomponenten, identifiziert Verzögerungsengpässe und generiert eine Slice-Konfigurationsrichtlinie (die eine VM-Zuweisungs- und Übergaberichtlinie beinhalten kann, die virtuelle Ressourcen des MEC-Systems zur Verlagerung oder Übergabe an ein anderes MEC-System angibt). Das NFV-SCF 1208 kommuniziert die Slice-Konfigurationsrichtlinie bei Operation 1516 an das VIM 1508. Bei 1518 bewertet das VIM 1508 die Sichtbarkeit der Slice-Konfigurationsrichtlinie, berücksichtigt verfügbare Netzwerkressourcen und bereitet Feedback für die Kommunikation an die NFVO 1506 vor. Bei Operation 1520 wird eine positive Rückkopplung (wie hierin oben in Verbindung mit 13) wird der NFVO 1506 mitgeteilt. Bei Operation 1522 implementiert das VIM 1508 die empfohlene Slice-Konfigurationsrichtlinie.
Als Konsequenz des vorgeschlagenen NFV-SCF zum Entwerfen der E2E-Slice-aware Utility-Funktion und zum Vorschlagen einer VM-Migrationsrichtlinie kann die NFVO 1506 (über die NFV-SCF) so konfiguriert werden, dass sie das VIM anweist, diese Richtlinie zu implementieren. Die Schritte der Prozedur, die sich auf die Operationen 1314-1318 von 13 beziehen, sind in 15 dargestellt, wobei der Schwerpunkt auf dem Fall liegt, in dem das VIM positives Feedback an das NFVO liefert und die empfohlene Richtlinie umsetzt. In Aspekten, in denen das VIM 1508 negatives Feedback liefert, werden die 3GPP 5G (OSS 1502) und die MEC-Verwaltungseinheiten (MEAO 1504) erneut über die NFVO 1506 interagieren, um einen Kompromiss zu erzielen, daher wird eine neue (innere) Iteration ausgeführt, und es kann eine neue Slice-Konfigurationsrichtlinie erstellt werden.
16A - 16H veranschaulichen verschiedene Implementierungsaspekte 1600A, 1600B, 1600C, 1600D, 1600E, 1600F, 1600G und 1600H von hierin offenbarten Techniken in Verbindung mit einem Automobilbeispiel einer Computervorrichtung (z.B. UE 1602) in einem sich bewegenden Fahrzeug.
In dem mit 16A - 16 H assoziierten Beispiel muss ein Fahrzeug möglicherweise gleichzeitig eine Verbindung zu mehreren Netzwerk-Slice-Instanzen herstellen, die zu verschiedenen Slice/Service-Typen (SSTs) gehören, um unterschiedliche Leistungsanforderungen mehrerer Automobil-Anwendungsfälle zu unterstützen. Anwendungsfälle für Software-Updates und teleoperiertes Fahren könnten beispielsweise mit einer erweiterten Mobile-Breitband-(eMBB-)Netzwerk-Slice-Instanz bzw. einer ultrazuverlässigen Low-Latency-Communication-(URLLC)-Netzwerk-Slice-Instanz basierend auf ihren KPI-Anforderungen verknüpft werden.
Zwei Beispiele sind in den 16A-16H angegeben., entsprechend zwei Anwendungsfällen in MEC-fähigen 5G-Systemen (und zugehörigen Netzwerk-Slices): extrem niedrige Latenz (für einen Automotive-Slice) und Maschinenkommunikationsdienste mit massiver Konnektivität (für einen IoT-Slice).
Beispiel Automotive Slice Processing
16A - 16 H sind einem Mobilitätsszenario zugeordnet, ausgelöst durch sich ändernde Funkbedingungen. Ein Überblick über das Systemszenario ist in den 16A-16H dargestellt.. 16A veranschaulicht die Netzwerkeinheiten, die wiederholt werden, und die verbleibenden 16B - 16 H. Bezugnehmend auf 16A umfasst ein erstes MEC-fähiges 5G-Kommunikationssystem RRH 1604, ein virtuelles RAN 1606, eine MEC-Datenebene 1608 innerhalb von NFVI 1610, ein lokales Datennetzwerk 1612 mit einer MEC-App 1614 und eine MEC-Plattform 1616 mit MEC-APIs 1618 und 1620.
Das zweite MEC-fähige 5G-Kommunikationssystem umfasst RRH 1624, ein virtuelles RAN (vRAN) 1626, eine MEC-Datenebene 1628 innerhalb von NFVI 1630, ein lokales Datennetzwerk 1632 mit einer MEC-App 1634 und eine MEC-Plattform 1636 mit MEC-APIs 1638 und 1630.
Zum Zeitpunkt t0 (16A und 16B), ist das UE an RRH 1604 angehängt, das vRAN 1606 ist der MEC-Plattform 1616 zugeordnet und die MEC-App 1614 wird bei der lokalen DN 1612 instanziiert.
Zum Zeitpunkt t1 (16C) kommuniziert das UE 1602 über den Kommunikationspfad 1603, während es mit dem RRH 1624 verbunden ist, wobei das vRAN 1626 der MEC-Plattform 1616 zugeordnet ist und die MEC-App 1614 bei der lokalen DN 1612 instanziiert ist. In diesem Fall erzeugen das NFV-SCF 1208 und eine Slice-Konfigurationsrichtlinie, die eine Übergabe einer virtuellen Maschine empfiehlt, was zu einer vRAN-Übergabe führen kann (z.B. werden virtuelle Ressourcen des vRAN 1606 beendet und virtuelle Ressourcen für das vRAN 1626 werden instanziiert, um die Kommunikationsverbindung 1603 des sich bewegenden UE 1602 zu bedienen).
Zum Zeitpunkt t2 (16D) ist das UE mit dem RRH 1624 verbunden, und das vRAN 1626 ist immer noch mit der MEC-Plattform 1616 und der am lokalen DN 1612 instanziierten MEC-App verbunden.. In diesem Fall wird eine VM-Übergabe (z.B. basierend auf einer neuen Slice-Konfigurationsrichtlinie, die von der NFV-SCF 1208) generiert wird, von UPF (oder MEC-Datenebene) 1608 zu UPF (oder MEC-Datenebene) 1628 durchgeführt.
Wie in 16E dargestellt, kommuniziert zum Zeitpunkt t2 das UE 1602 über den Kommunikationspfad 1605, während sowohl der UPF 1608 als auch der UPF 1628 die Konnektivität mit dem lokalen DN 1612 aufrechterhalten.
Zum Zeitpunkt t3 (16F), ist das UE 1602 mit RRH 1624 verbunden und das vRAN 1626 ist immer noch mit der MEC-Plattform 1616 verbunden. Das UE 1602 ist jedoch jetzt mit der MEC-App 1634 verknüpft, die im lokalen DN 1632 nach einer VM-Übergabe, die mit der MEC-App verknüpft ist, instanziiert ist (die MEC-App wird zuerst von der MEC-Mobilität beeinflusst und die MEC-App kommuniziert über einen MP3-Referenzpunkt).
16G veranschaulicht die Zuordnungen nach der MEC-App-Migration und nach der Übergabe von VMs von der MEC-Plattform 1616 an die MEC-Plattform 1636.
Zum Zeitpunkt t4 (16H) kommuniziert das UE 1602 über den Kommunikationspfad 1607, während es mit dem RRH 1624 und dem vRAN 1626 verbunden ist, das mit der MEC-Plattform 1636 und der MEC-App, die bei der lokalen DN 1632 instanziiert ist, verknüpft ist. 16H veranschaulicht den Abschluss der VM-Migrationsprozedur basierend auf beispielsweise einer Slice-Konfigurationsrichtlinie, die von der NFV-SCF 1208 unter Verwendung der offenbarten Techniken erzeugt wird.
Beispiel für die industrielle IoT-Slice-Verarbeitung
Gemäß diesem Beispiel und mit Fokus auf privater Netzwerkbereitstellung nehmen wir an, dass zu Beginn (d.h., zum Zeitpunkt t0) ein Ultra-Reliable Low Latency Communication (URLLC)-Slice aktiv ist. Beispiele umfassen Automatisierungsprozess-/Maschinensteuerung, Roboterarmbedienung und andere. Zu einem späteren Zeitpunkt (d.h., zum Zeitpunkt t1) wird jedoch ein anderer Slice aktiviert (z.B. ein eMBB-Dienst), was die Notwendigkeit mit sich bringt, eine neue MEC-Anwendung für die lokale Videoverarbeitung zu instanziieren, z.B. für die teleoperative Fehlerbehebung. Ziel des Systemdesigns ist daher die effiziente, vollständige Instanziierung des zweiten (eMBB) Slice für High-Throughput-Videostreaming zusätzlich zum URLLC-Slice für den Produktionsbetrieb (mit anderen Worten: Multi-Slice-Koexistenz in einer virtualisierten Umgebung).
In diesem Fall wird das iterative Verfahren von 12-13 implementiert werden können, indem zwei verschiedene E2E-Nutzenfunktionen modelliert und bewertet werden, eine pro Netzwerk-Slice-Instanz, d. h.: (a) eine Nutzenfunktion, die sich auf die E2E-Latenz (RTT) konzentriert, die das URLLC-UE erfährt (z.B. ein Roboterarm oder ein Aktuator); und (b) eine Nutzenfunktion, die sich auf die Datenrate konzentriert, die das eMBB-UE erfährt (z.B. eine drahtlose Kamera, die zur Fehlersuche eingesetzt wird).
Als Ergebnis kann die von den 3GPP 5G/MEC-Systemverwaltungsentitäten zu berücksichtigende Gesamtnutzenfunktion eine Synthese der beiden scheibenspezifischen Nutzfunktionen sein, auch unter Berücksichtigung der Kosten von VM-Migrationen (gemäß dem beispielhaften oben offenbarten Nutzfunktionen).
Es versteht sich, dass die in dieser Spezifikation beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder bezeichnet werden können, um insbesondere ihre Implementierungsunabhängigkeit hervorzuheben. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen verkörpert werden. Beispielsweise kann eine Komponente oder ein Modul als Hardware-Schaltung implementiert werden, die kundenspezifische Schaltungen mit sehr großer Integration (VLSI) oder Gate-Arrays, handelsübliche Halbleiter wie etwa Logikchips, Transistoren oder andere diskrete Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert sein, wie beispielsweise feldprogrammierbare Gate-Arrays, programmierbare Array-Logik, programmierbare Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert werden. Eine identifizierte Komponente oder ein Modul ausführbaren Codes kann beispielsweise einen oder mehrere physikalische oder logische Blöcke von Computerbefehlen umfassen, die beispielsweise als Objekt, Prozedur oder Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Dateien einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen angeordnet sein, sondern können unterschiedliche Anweisungen umfassen, die an verschiedenen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden sind, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erfüllen.
Tatsächlich kann eine Komponente oder ein Modul ausführbaren Codes ein einzelner Befehl oder viele Befehle sein und kann sogar über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über mehrere Speichervorrichtungen oder Verarbeitungssysteme verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie Code-Rewriting und Code-Analyse) auf einem anderen Verarbeitungssystem (z Computer, eingebettet in einen Sensor oder Roboter). In ähnlicher Weise können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und dargestellt werden und können in jeder geeigneten Form verkörpert und in jeder geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als einzelner Datensatz gesammelt werden oder können über verschiedene Orte, einschließlich über verschiedene Speichergeräte, verteilt werden und können zumindest teilweise lediglich als elektronische Signale in einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die betreibbar sind, um gewünschte Funktionen auszuführen.
Zusätzliche Hinweise und Beispiele
Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen umfassen die folgenden, nicht einschränkenden Konfigurationen. Jedes der folgenden nicht einschränkenden Beispiele kann für sich allein stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen Beispiele, die unten oder in der gesamten vorliegenden Offenbarung bereitgestellt werden, kombiniert werden.
Beispiel 1 ist ein System, das konfiguriert ist, um Netzwerk-Slicing-Operationen innerhalb eines Kommunikationsnetzwerks der fünften Generation (5G) zu verfolgen, wobei das System umfasst: Speicher; und mit dem Speicher gekoppelte Verarbeitungsschaltungen, wobei die Verarbeitungsschaltungen konfiguriert sind, um eine Netzwerk-Slice-Instanz (NSI) zu bestimmen, die einem Dienstgüte-(QoS-)Fluss einer Benutzerausrüstung (UE) zugeordnet ist, wobei die NSI Daten für eine Netzwerkfunktionsvirtualisierung (NFV) - Instanz eines Multi-Access Edge Computing (MEC)-Systems innerhalb des 5G-Kommunikationsnetzes; Abrufen von Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen, die von dem NSI verwendet werden, wobei die Vielzahl von Kommunikationsverbindungen einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen, die mit dem MEC-System verbunden sind; Generieren einer Slice-Konfigurationsrichtlinie basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI; und Rekonfigurieren von Netzwerkressourcen des 5G-Kommunikationsnetzwerks, das von dem NSI verwendet wird, basierend auf der erzeugten Slice-Konfigurationsrichtlinie.
In Beispiel 2 beinhaltet der Gegenstand von Beispiel 1 einen Gegenstand, bei dem die NFV-Instanz von einer MEC-Anwendung bereitgestellt wird, die dem QoS-Fluss zugeordnet ist, wobei die MEC-Anwendung auf virtuellen Ressourcen einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) des MEC-Systems ausgeführt wird.
In Beispiel 3 umfasst der Gegenstand von Beispiel 2 einen Gegenstand, bei dem das MEC-System einen MEC-Host umfasst, der die NFV-Instanz ausführt.
In Beispiel 4 umfasst der Gegenstand von Beispiel 3 einen Gegenstand, bei dem der MEC-Host konfiguriert ist, um gemäß einem Standard aus einer MEC-Standardfamilie des European Telecommunications Standards Institute (ETSI) zu arbeiten.
In Beispiel 5 umfasst der Gegenstand der Beispiele 3-4 einen Gegenstand, bei dem die Slice-Konfigurationsrichtlinie eine Zuweisungs- und Übergaberichtlinie für virtuelle Maschinen (VM) umfasst, und um die Netzwerkressourcen neu zu konfigurieren, ist die Verarbeitungsschaltung so konfiguriert, dass sie zusätzliche Netzwerkressourcen der 5G-Kommunikationsnetzwerk zum MEC-Host basierend auf der VM-Zuweisungs- und Übergaberichtlinie zuweist.
In Beispiel 6 umfasst der Gegenstand von Beispiel 5 einen Gegenstand, bei dem die Netzwerkressourcen neu zu konfigurieren sind, die Verarbeitungsschaltung ferner konfiguriert ist, um eine VM-Übergabe durchzuführen, um die MEC-Anwendung zu verlagern, um sie auf virtuellen Ressourcen eines zweiten NFVI des MEC-Systems basierend auf der VM-Zuweisungs- und Übergaberichtlinie auszuführen.
In Beispiel 7 umfasst der Gegenstand der Beispiele 2-6 einen Gegenstand, bei dem der erste Satz von Nicht-MEC-Kommunikationsverbindungen umfasst: eine Kommunikationsverbindung zwischen dem UE und dem RAN; eine Kommunikationsverbindung, die einem N3-Referenzpunkt zwischen dem RAN und einer MEC-Datenebene des MEC-Systems zugeordnet ist, wobei die MEC-Datenebene eine Benutzerebenenfunktion des 5G-Kommunikationsnetzwerks ausführt; und eine Kommunikationsverbindung, die einem N6-Referenzpunkt zwischen der MEC-Datenebene und einem lokalen Datennetzwerk zugeordnet ist, das die virtuellen Ressourcen des NFVI enthält.
In Beispiel 8 umfasst der Gegenstand von Beispiel 7 einen Gegenstand, bei dem der zweite Satz von MEC-Kommunikationsverbindungen mindestens eine Kommunikationsverbindung umfasst, die einem MPI-Referenzpunkt der MEC-Anwendung zugeordnet ist.
In Beispiel 9 umfasst der Gegenstand von Beispiel 8 einen Gegenstand, bei dem die mindestens eine dem Mp1-Referenzpunkt zugeordnete Kommunikationsverbindung eine Kommunikationsverbindung zwischen der MEC-Anwendung und einer MEC-Anwendungsprogrammierschnittstelle (API) innerhalb einer MEC-Plattform des MEC ist System.
In Beispiel 10 beinhaltet der Gegenstand von Beispiel 9 einen Gegenstand, bei dem die Latenzinformationen eine Verarbeitungsverzögerung beinhalten, die mit dem Erhalten von Funknetzinformationen (RNI) oder Standortinformationen durch die MEC API verbunden ist, basierend auf einer Anfrage von der MEC-Anwendung, die mit dem QoS-Fluss verbunden ist.
In Beispiel 11 beinhaltet der Gegenstand der Beispiele 1-10 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist, um: einen ersten Teil der Latenzinformationen, die dem ersten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks abzurufen.
In Beispiel 12 beinhaltet der Gegenstand von Beispiel 11 einen Gegenstand, bei dem die Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks ein Operations-Support-System (OSS) des 5G-Kommunikationsnetzwerks ist.
In Beispiel 13 umfasst der Gegenstand der Beispiele 11-12 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist zum: Abrufen eines zweiten Teils der Latenzinformationen, die dem zweiten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des MEC-Systems.
In Beispiel 14 umfasst der Gegenstand von Beispiel 13 einen Gegenstand, bei dem die Dienstkoordinierungsentität des MEC-Systems ein Multi-Access Edge Orchestrator (MEAO) des MEC-Systems ist.
In Beispiel 15 umfasst der Gegenstand der Beispiele 1-14 einen Gegenstand, bei dem die Slice-spezifischen Attribute des NSI eines oder mehrere der folgenden umfassen: eine End-to-End-(E2E-) Latenzanforderung in Verbindung mit der Kommunikation von Daten innerhalb des NSI; eine minimale verfügbare Bandbreitenanforderung für die Vielzahl von Kommunikationsverbindungen des NSI; und eine Kommunikationsdurchsatzanforderung von mindestens einer der Vielzahl von Kommunikationsverbindungen des NSI.
In Beispiel 16 umfasst der Gegenstand der Beispiele 1-15 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist zum: Auswählen einer Nutzenfunktion aus einer Vielzahl von verfügbaren Nutzenfunktionen basierend auf einer dem NSI zugeordneten Slice Service Level Agreement (SLA); und Erzeugen der Slice-Konfigurationsrichtlinie weiterhin basierend auf dem Minimieren der ausgewählten Nutzenfunktion.
In Beispiel 17 umfasst der Gegenstand von Beispiel 16 einen Gegenstand, bei dem die Nutzenfunktion eine der folgenden ist: eine effizienzorientierte 5G-Nutzfunktion zum Minimieren einer Ende-zu-Ende-(E2E-)Verzögerung innerhalb des 5G-Kommunikationsnetzes; eine MEC-effizienzzentrierte Nutzenfunktion zum Minimieren der E2E-Verzögerung innerhalb des MEC-Systems; und eine Gesamteffizienz-Nutzfunktion zum Minimieren von Verletzungen des Slice-SLA.
Beispiel 18 ist ein Computergerät in einem Multi-Access Edge Computing (MEC)-fähigen Kommunikationsnetzwerk der fünften Generation (5G), wobei das Gerät umfasst: eine Netzwerkschnittstellenkarte (NIC); und mit der NIC gekoppelte Verarbeitungsschaltungen, wobei die Verarbeitungsschaltungen konfiguriert sind, um Operationen durchzuführen, um eine Netzwerk-Slice-Instanz (NSI) zu bestimmen, die mit einem Dienstqualitäts-(QoS-)Fluss einer Benutzereinrichtung (UE) verknüpft ist, wobei die NSI Daten für eine Netzwerkfunktion-Virtualisierungsinstanz (NFV) eines Multi-Access Edge Computing (MEC)-Systems innerhalb des 5G-Kommunikationsnetzes kommuniziert; über die NIC Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen abzurufen, die von der NSI verwendet werden, wobei die Vielzahl von Kommunikationsverbindungen einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen umfasst, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen, die dem MEC-System zugeordnet sind; eine Slice-Konfigurationsrichtlinie basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI zu erstellen, und Netzwerkressourcen des 5G-Kommunikationsnetzwerks zu rekonfigurieren, das von dem NSI verwendet wird, basierend auf der generierten Slice-Konfigurationsrichtlinie.
In Beispiel 19 beinhaltet der Gegenstand von Beispiel 18 einen Gegenstand, bei dem die NFV-Instanz von einer MEC-Anwendung bereitgestellt wird, die dem QoS-Fluss zugeordnet ist, wobei die MEC-Anwendung auf virtuellen Ressourcen einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) des MEC-Systems ausgeführt wird.
In Beispiel 20 umfasst der Gegenstand von Beispiel 19 einen Gegenstand, bei dem das MEC-System einen MEC-Host umfasst, der die NFV-Instanz ausführt, und wobei die Computervorrichtung einen zweiten MEC-Host umfasst, der als Network Function Virtualization Orchestrator (NFVO) des MEC-Systems konfiguriert ist, wobei das NFVO eine NFV-Slice-Steuerfunktion (NFV-SCO) enthält, die die Slice-Konfigurationsrichtlinie erzeugt.
In Beispiel 21 umfasst der Gegenstand von Beispiel 20 einen Gegenstand, bei dem der MEC-Host und der zweite MEC-Host konfiguriert sind, um gemäß einem Standard aus einer MEC-Standardfamilie des European Telecommunications Standards Institute (ETSI) zu arbeiten.
In Beispiel 22 umfasst der Gegenstand der Beispiele 20-21 einen Gegenstand, bei dem die Slice-Konfigurationsrichtlinie eine Zuweisungs- und Übergaberichtlinie für virtuelle Maschinen (VM) umfasst, und um die Netzwerkressourcen neu zu konfigurieren, ist die Verarbeitungsschaltung so konfiguriert, dass sie zusätzliche Netzwerkressourcen der 5G-Kommunikationsnetzwerk zum MEC-Host basierend auf der VM-Zuweisungs- und Übergaberichtlinie zuweist.
In Beispiel 23 umfasst der Gegenstand von Beispiel 22 einen Gegenstand, bei dem die Netzwerkressourcen neu zu konfigurieren sind, die Verarbeitungsschaltung ferner konfiguriert ist, um eine VM-Übergabe durchzuführen, um die MEC-Anwendung zu verlagern, um sie auf virtuellen Ressourcen eines zweiten NFVI des MEC-Systems basierend auf der VM-Zuweisungs- und Übergaberichtlinie auszuführen.
In Beispiel 24 umfasst der Gegenstand der Beispiele 19-23 einen Gegenstand, bei dem der erste Satz von Nicht-MEC-Kommunikationsverbindungen umfasst: eine Kommunikationsverbindung zwischen dem UE und dem RAN; eine Kommunikationsverbindung, die einem N3-Referenzpunkt zwischen dem RAN und einer MEC-Datenebene des MEC-Systems zugeordnet ist, wobei die MEC-Datenebene eine Benutzerebenenfunktion des 5G-Kommunikationsnetzwerks ausführt; und eine Kommunikationsverbindung, die einem N6-Referenzpunkt zwischen der MEC-Datenebene und einem lokalen Datennetzwerk zugeordnet ist, das die virtuellen Ressourcen des NFVI enthält.
In Beispiel 25 umfasst der Gegenstand von Beispiel 24 einen Gegenstand, bei dem der zweite Satz von MEC-Kommunikationsverbindungen mindestens eine Kommunikationsverbindung umfasst, die einem MPI-Referenzpunkt der MEC-Anwendung zugeordnet ist.
In Beispiel 26 umfasst der Gegenstand von Beispiel 25 einen Gegenstand, bei dem die mindestens eine dem Mp1-Referenzpunkt zugeordnete Kommunikationsverbindung eine Kommunikationsverbindung zwischen der MEC-Anwendung und einer MEC-Anwendungsprogrammierschnittstelle (API) innerhalb einer MEC-Plattform des MEC-Systems ist.
In Beispiel 27 umfasst der Gegenstand von Beispiel 26 einen Gegenstand, bei dem die Latenzinformationen eine Verarbeitungsverzögerung beinhalten, die mit dem Erhalten von Funknetzinformationen (RNI) oder Standortinformationen durch die MEC-API verbunden ist, basierend auf einer Anfrage von der MEC-Anwendung, die mit dem QoS-Fluss verbunden ist.
In Beispiel 28 beinhaltet der Gegenstand der Beispiele 18-27 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist zum: Abrufen eines ersten Teils der Latenzinformationen, die dem ersten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks.
In Beispiel 29 beinhaltet der Gegenstand von Beispiel 28 einen Gegenstand, bei dem die Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks ein Operations-Support-System (OSS) des 5G-Kommunikationsnetzwerks ist.
In Beispiel 30 umfasst der Gegenstand der Beispiele 28-29 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist zum: Abrufen eines zweiten Teils der Latenzinformationen, die dem zweiten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des MEC-Systems.
In Beispiel 31 umfasst der Gegenstand von Beispiel 30 einen Gegenstand, bei dem die Dienstkoordinierungsentität des MEC-Systems ein Multi-Access Edge Orchestrator (MEAO) des MEC-Systems ist.
In Beispiel 32 umfasst der Gegenstand der Beispiele 18-31 einen Gegenstand, bei dem die Slice-spezifischen Attribute des NSI eines oder mehrere der folgenden umfassen: eine End-to-End-(E2E-) Latenzanforderung in Verbindung mit der Kommunikation von Daten innerhalb des NSI; eine minimale verfügbare Bandbreitenanforderung für die Vielzahl von Kommunikationsverbindungen des NSI; und eine Kommunikationsdurchsatzanforderung von mindestens einer der Vielzahl von Kommunikationsverbindungen des NSI.
In Beispiel 33 umfasst der Gegenstand der Beispiele 18-32 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist zum: Auswählen einer Nutzenfunktion aus einer Vielzahl von verfügbaren Nutzenfunktion basierend auf einer dem NSI zugeordneten Slice Service Level Agreement (SLA); und Erzeugen der Slice-Konfigurationsrichtlinie weiterhin basierend auf dem Minimieren der ausgewählten Nutzenfunktion.
In Beispiel 34 umfasst der Gegenstand von Beispiel 33 einen Gegenstand, bei dem die Nutzenfunktion eine der folgenden ist: eine SG-effizienzorientierte Nutzenfunktion zum Minimieren der Ende-zu-Ende-(E2E)-Verzögerung innerhalb des 5G-Kommunikationsnetzes; eine MEC-effizienzzentrierte Nutzenfunktion zum Minimieren der E2E-Verzögerung innerhalb des MEC-Systems; und eine Gesamteffizienz-Nutzfunktion zum Minimieren von Verletzungen des Slice-SLA.
Beispiel 35 ist mindestens ein nichtflüchtiges maschinenlesbares Speichermedium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie von einer Verarbeitungsschaltung einer Computervorrichtung ausgeführt werden, die in einem Multi-Access Edge Computing (MEC)-fähigen der fünften Generation (5G) Kommunikationsnetzwerk betrieben werden kann, veranlassen, dass die Verarbeitungsschaltung Operationen durchführt, die: eine Netzwerk-Slice-Instanz (NSI) bestimmen, die einem Dienstgüte-(QoS-)Fluss einer Benutzerausrüstung (UE) zugeordnet ist, wobei der NSI Daten für eine Netzwerkfunktions-Virtualisierungs-(NFV)-Instanz eines Multi-Access Edge Computing (MEC)-Systems innerhalb des 5G-Kommunikationsnetzes kommuniziert; Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen, die von dem NSI verwendet werden, abrufen, wobei die Vielzahl von Kommunikationsverbindungen einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen umfasst, die mit dem MEC-System verbunden sind; eine Slice-Konfigurationsrichtlinie basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI erstellen, und Netzwerkressourcen des 5G-Kommunikationsnetzwerks, das von dem NSI verwendet wird, basierend auf der erstellten Slice-Konfigurationsrichtlinie rekonfigurieren.
In Beispiel 36 beinhaltet der Gegenstand von Beispiel 35 einen Gegenstand, bei dem die NFV-Instanz von einer MEC-Anwendung bereitgestellt wird, die dem QoS-Fluss zugeordnet ist, wobei die MEC-Anwendung auf virtuellen Ressourcen einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) des MEC-Systems ausgeführt wird.
In Beispiel 37 umfasst der Gegenstand von Beispiel 36 einen Gegenstand, bei dem das MEC-System einen MEC-Host umfasst, der die NFV-Instanz ausführt, und wobei die Computervorrichtung einen zweiten MEC-Host umfasst, der als Network Function Virtualization Orchestrator (NFVO) des MEC-Systems konfiguriert ist, wobei das NFVO eine NFV-Slice-Steuerfunktion (NFV-SCO) enthält, die die Slice-Konfigurationsrichtlinie erzeugt.
In Beispiel 38 umfasst der Gegenstand von Beispiel 37 einen Gegenstand, bei dem der MEC-Host und der zweite MEC-Host konfiguriert sind, um gemäß einem Standard aus einer MEC-Standardfamilie des European Telecommunications Standards Institute (ETSI) zu arbeiten.
In Beispiel 39 umfasst der Gegenstand der Beispiele 37-38 einen Gegenstand, bei dem die Slice-Konfigurationsrichtlinie eine Zuweisungs- und Übergaberichtlinie für virtuelle Maschinen (VM) umfasst, und wobei, um die Netzwerkressourcen neu zu konfigurieren, die Anweisungen weiterhin die Verarbeitungsschaltung veranlassen: zusätzliche Netzwerkressourcen des 5G-Kommunikationsnetzwerks an den MEC-Host basierend auf der VM-Zuweisungs- und Übergaberichtlinie zuzuweisen.
In Beispiel 40 beinhaltet der Gegenstand von Beispiel 39 einen Gegenstand, wobei die Netzwerkressourcen neu zu konfigurieren sind, wobei die Anweisungen ferner bewirken, dass die Verarbeitungsschaltung eine VM-Übergabe durchführt, um die MEC-Anwendung zur Ausführung auf virtuellen Ressourcen eines zweiten NFVI des MEC-Systems zu verlagern, basierend auf der VM-Zuweisungs- und Übergaberichtlinie.
In Beispiel 41 umfasst der Gegenstand der Beispiele 36-40 einen Gegenstand, bei dem der erste Satz von Nicht-MEC-Kommunikationsverbindungen umfasst: eine Kommunikationsverbindung zwischen dem UE und dem RAN; eine Kommunikationsverbindung, die einem N3-Referenzpunkt zwischen dem RAN und einer MEC-Datenebene des MEC-Systems zugeordnet ist, wobei die MEC-Datenebene eine Benutzerebenenfunktion des 5G-Kommunikationsnetzwerks ausführt; und eine Kommunikationsverbindung, die einem N6-Referenzpunkt zwischen der MEC-Datenebene und einem lokalen Datennetzwerk zugeordnet ist, das die virtuellen Ressourcen des NFVI enthält.
In Beispiel 42 umfasst der Gegenstand von Beispiel 41 einen Gegenstand, bei dem der zweite Satz von MEC-Kommunikationsverbindungen mindestens eine Kommunikationsverbindung umfasst, die einem MPI-Referenzpunkt der MEC-Anwendung zugeordnet ist.
In Beispiel 43 umfasst der Gegenstand von Beispiel 42 einen Gegenstand, bei dem die mindestens eine dem Mp1-Referenzpunkt zugeordnete Kommunikationsverbindung eine Kommunikationsverbindung zwischen der MEC-Anwendung und einer MEC-Anwendungsprogrammierschnittstelle (API) innerhalb einer MEC-Plattform des MEC Systems ist.
In Beispiel 44 beinhaltet der Gegenstand von Beispiel 43 einen Gegenstand, bei dem die Latenzinformationen eine Verarbeitungsverzögerung beinhalten, die mit dem Erhalten von Funknetzinformationen (RNI) oder Standortinformationen durch die MEC API verbunden ist, basierend auf einer Anfrage von der MEC-Anwendung, die mit dem QoS-Fluss verbunden ist.
In Beispiel 45 umfasst der Gegenstand der Beispiele 35-44 einen Gegenstand, bei dem die Anweisungen die Verarbeitungsschaltung weiter veranlassen: einen ersten Teil der Latenzinformationen, die dem ersten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks abzurufen.
In Beispiel 46 beinhaltet der Gegenstand von Beispiel 45 einen Gegenstand, bei dem die Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks ein Operations-Support-System (OSS) des 5G-Kommunikationsnetzwerks ist.
In Beispiel 47 umfasst der Gegenstand der Beispiele 45-46 einen Gegenstand, bei dem die Anweisungen die Verarbeitungsschaltung weiterhin veranlassen: einen zweiten Teil der Latenzinformationen, die mit dem zweiten Satz von Kommunikationsverbindungen verknüpft sind, von einer Dienstkoordinierungsentität des MEC-Systems abzurufen.
In Beispiel 48 umfasst der Gegenstand von Beispiel 47 einen Gegenstand, bei dem die Dienstkoordinierungsentität des MEC-Systems ein Multi-Access Edge Orchestrator (MEAO) des MEC-Systems ist.
In Beispiel 49 umfasst der Gegenstand der Beispiele 35-48 einen Gegenstand, bei dem die Slice-spezifischen Attribute des NSI eines oder mehrere der folgenden umfassen: eine End-to-End-(E2E-) Latenzanforderung in Verbindung mit der Kommunikation von Daten innerhalb des NSI; eine minimale verfügbare Bandbreitenanforderung für die Vielzahl von Kommunikationsverbindungen des NSI; und eine Kommunikationsdurchsatzanforderung von mindestens einer der Vielzahl von Kommunikationsverbindungen des NSI.
In Beispiel 50 umfasst der Gegenstand der Beispiele 35-49 einen Gegenstand, bei dem die Verarbeitungsschaltung konfiguriert ist zum: Auswählen einer Nutzenfunktion aus einer Vielzahl von verfügbaren Nutzenfunktionen basierend auf einer dem NSI zugeordneten Slice Service Level Agreement (SLA); und Erzeugen der Slice-Konfigurationsrichtlinie weiterhin basierend auf dem Minimieren der ausgewählten Nutzenfunktion.
In Beispiel 51 umfasst der Gegenstand von Beispiel 50 einen Gegenstand, bei dem die Nutzenfunktion eine der folgenden ist: eine effizienzorientierte 5G-Nutzfunktion zum Minimieren einer Ende-zu-Ende-(E2E-)Verzögerung innerhalb des 5G-Kommunikationsnetzes; eine MEC-effizienzzentrierte Nutzenfunktion zum Minimieren der E2E-Verzögerung innerhalb des MEC-Systems; und eine Gesamteffizienz-Nutzfunktion zum Minimieren von Verletzungen des Slice-SLA.
Beispiel 52 ist mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die, wenn sie von einer Verarbeitungsschaltung ausgeführt werden, die Verarbeitungsschaltung veranlassen, Operationen zum Implementieren eines der Beispiele 1-51 auszuführen.
Beispiel 53 ist eine Vorrichtung, die Mittel zum Implementieren eines der Beispiele 1-51 umfasst.
Beispiel 54 ist ein System zur Implementierung eines der Beispiele 1-51.
Beispiel 55 ist ein Verfahren zum Implementieren eines der Beispiele 1-51.
Obwohl ein Aspekt bezüglich spezifischer beispielhafter Aspekte beschrieben wurde, ist offensichtlich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzumfang der vorliegenden Offenbarung abzuweichen. Dementsprechend sind die Beschreibung und die Zeichnungen eher in einem veranschaulichenden als in einem einschränkenden Sinne zu betrachten. Die beigefügten Zeichnungen, die einen Teil hiervon bilden, zeigen zur Veranschaulichung und nicht zur Einschränkung spezifische Aspekte, in denen der Gegenstand praktiziert werden kann. Die dargestellten Aspekte werden ausreichend detailliert beschrieben, um es dem Fachmann zu ermöglichen, die hier offenbarten Lehren zu praktizieren. Andere Aspekte können verwendet und daraus abgeleitet werden, so dass strukturelle und logische Ersetzungen und Änderungen vorgenommen werden können, ohne vom Umfang dieser Offenbarung abzuweichen. Diese ausführliche Beschreibung ist daher nicht in einem einschränkenden Sinne zu verstehen, und der Umfang verschiedener Aspekte wird nur durch die beigefügten Ansprüche zusammen mit dem vollen Bereich von Äquivalenten definiert, auf die diese Ansprüche Anspruch haben.
Auf solche Aspekte des erfinderischen Gegenstands kann hierin einzeln und/oder kollektiv Bezug genommen werden, lediglich der Einfachheit halber und ohne die Absicht, den Umfang dieser Anmeldung freiwillig auf einen einzelnen Aspekt oder ein erfinderisches Konzept zu beschränken, wenn mehr als einer offenbart ist. Obwohl hierin spezifische Aspekte dargestellt und beschrieben wurden, sollte daher beachtet werden, dass jede Anordnung, die berechnet wurde, um den gleichen Zweck zu erreichen, die gezeigten spezifischen Aspekte ersetzen kann. Diese Offenbarung soll alle Anpassungen oder Variationen verschiedener Aspekte abdecken. Kombinationen der obigen Aspekte und anderer Aspekte, die hierin nicht speziell beschrieben sind, werden dem Fachmann bei Durchsicht der obigen Beschreibung offensichtlich sein.
Die Zusammenfassung der Offenlegung wird bereitgestellt, damit der Leser die Art der technischen Offenlegung schnell erkennen kann. Sie wird mit dem Verständnis vorgelegt, dass sie nicht dazu verwendet wird, den Umfang oder die Bedeutung der Ansprüche zu interpretieren oder einzuschränken. Außerdem ist aus der vorstehenden ausführlichen Beschreibung ersichtlich, dass verschiedene Merkmale in einem einzigen Aspekt gruppiert sind, um die Offenbarung zu rationalisieren. Dieses Offenbarungsverfahren ist nicht so zu interpretieren, dass es die Absicht widerspiegelt, dass die beanspruchten Aspekte mehr Merkmale erfordern, als in jedem Anspruch ausdrücklich aufgeführt sind. Wie die folgenden Ansprüche widerspiegeln, liegt der Erfindungsgegenstand vielmehr in weniger als allen Merkmalen eines einzigen offenbarten Aspekts. Somit werden die folgenden Ansprüche hiermit in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als separater Aspekt steht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/816616 [0001]

Claims

System, das konfiguriert ist, um Netzwerk-Slicing-Operationen innerhalb eines Kommunikationsnetzwerks der fünften Generation (5G) zu verfolgen, wobei das System Folgendes umfasst: einen Speicher; und eine Verarbeitungsschaltung, die mit dem Speicher gekoppelt ist, wobei die Verarbeitungsschaltung konfiguriert ist zum: Bestimmen einer Netzwerk-Slice-Instanz (NSI), die mit einem Dienstqualitäts-(QoS-)Fluss eines Benutzergeräts (UE) verknüpft ist, wobei der NSI Daten für eine Netzwerkfunktions-Virtualisierungs-(NFV-) Instanz eines Multi-Access-Edge-Computing-(MEC-)Systems innerhalb des 5G-Kommunikationsnetzes kommuniziert; Abrufen von Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen, die von dem NSI verwendet werden, wobei die Vielzahl von Kommunikationsverbindungen einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen umfasst, die mit dem MEC-System verbunden sind; Erstellen einer Slice-Konfigurationsrichtlinie basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI; und Rekonfigurieren von Netzwerkressourcen des 5G-Kommunikationsnetzwerks, das vom NSI verwendet wird, basierend auf der erstellten Slice-Konfigurationsrichtlinie.
System nach Anspruch 1, wobei die NFV-Instanz von einer dem QoS-Fluss zugeordneten MEC-Anwendung bereitgestellt wird, wobei die MEC-Anwendung auf virtuellen Ressourcen einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) des MEC-Systems ausgeführt wird.
System nach Anspruch 2, wobei das MEC-System einen MEC-Host umfasst, der die NFV-Instanz ausführt.
System nach Anspruch 3, wobei die Slice-Konfigurationsrichtlinie eine Zuweisungs- und Übergaberichtlinie für virtuelle Maschinen (VM) umfasst und, um die Netzwerkressourcen neu zu konfigurieren, die Verarbeitungsschaltung konfiguriert ist, um : dem MEC-Host basierend auf der VM-Zuweisungs- und Übergaberichtlinie zusätzliche Netzwerkressourcen des 5G-Kommunikationsnetzwerks zuzuweisen.
System nach Anspruch 4, wobei, um die Netzwerkressourcen neu zu konfigurieren, die Verarbeitungsschaltung konfiguriert ist, um: eine VM-Übergabe durchzuführen, um die MEC-Anwendung zu verlagern, um sie auf virtuellen Ressourcen eines zweiten NFVI des MEC-Systems basierend auf der VM-Zuweisungs- und Übergaberichtlinie auszuführen.
System nach Anspruch 2, wobei der erste Satz von Nicht-MEC-Kommunikationsverbindungen umfasst: eine Kommunikationsverbindung zwischen dem UE und dem RAN; eine Kommunikationsverbindung, die einem N3-Referenzpunkt zwischen dem RAN und einer MEC-Datenebene des MEC-Systems zugeordnet ist, wobei die MEC-Datenebene eine Benutzerebenenfunktion des 5G-Kommunikationsnetzwerks ausführt; und eine Kommunikationsverbindung, die einem N6-Referenzpunkt zwischen der MEC-Datenebene und einem lokalen Datennetzwerk zugeordnet ist, das die virtuellen Ressourcen des NFVI enthält.
System nach Anspruch 6, wobei der zweite Satz von MEC-Kommunikationsverbindungen wenigstens eine Kommunikationsverbindung umfasst, die einem MPI-Referenzpunkt der MEC-Anwendung zugeordnet ist.
System nach Anspruch 7, wobei die mindestens eine dem Mp1-Referenzpunkt zugeordnete Kommunikationsverbindung eine Kommunikationsverbindung zwischen der MEC-Anwendung und einer MEC-Anwendungsprogrammierschnittstelle (API) innerhalb einer MEC-Plattform des MEC-Systems ist.
System nach Anspruch 8, wobei die Latenzinformationen eine Verarbeitungsverzögerung beinhalten, die mit dem Erhalten von Funknetzinformationen (RNI) oder Standortinformationen durch die MEC API verbunden ist, basierend auf einer Anfrage von der MEC-Anwendung, die mit dem QoS-Fluss verbunden ist.
System nach Anspruch 1, wobei die Verarbeitungsschaltung konfiguriert ist, um: einen ersten Teil der Latenzinformationen, die dem ersten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des 5G-Kommunikationsnetzes abzurufen.
System nach Anspruch 10, wobei die Dienstkoordinierungsentität des 5G-Kommunikationsnetzwerks ein Operations- Support- System (OSS) des 5G-Kommunikationsnetzwerks ist.
System nach Anspruch 10, wobei die Verarbeitungsschaltung konfiguriert ist, um: einen zweiten Teil der Latenzzeitinformationen, die dem zweiten Satz von Kommunikationsverbindungen zugeordnet sind, von einer Dienstkoordinierungsentität des MEC-Systems abzurufen.
System nach Anspruch 12, wobei die Dienstkoordinierungsentität des MEC-Systems ein Multi-Access Edge Orchestrator (MEAO) des MEC-Systems ist.
Rechenknoten in einem Multi-Access Edge Computing (MEC)-fähigen Kommunikationsnetzwerk der fünften Generation (5G), wobei der Knoten umfasst: eine Netzwerkschnittstellenkarte (NIC); und eine Verarbeitungsschaltung, die mit der NIC gekoppelt ist, wobei die Verarbeitungsschaltung dazu konfiguriert ist, Operationen auszuführen, um: eine Netzwerk-Slice-Instanz (NSI) zu bestimmen, die mit einem Dienstqualitäts-(QoS-)Fluss eines Benutzergeräts (UE) verknüpft ist, wobei der NSI Daten für eine Netzwerkfunktions-Virtualisierungs-(NFV-) Instanz eines Multi-Access-Edge-Computing-(MEC-) Systems innerhalb des 5G-Kommunikationsnetzes kommuniziert; über die NIC Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen abzurufen, die von der NSI verwendet werden, wobei die Vielzahl von Kommunikationsverbindungen einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen umfasst, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen, die dem MEC-System zugeordnet sind; eine Slice-Konfigurationsrichtlinie basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI zu erstellen; und Netzwerkressourcen des 5G-Kommunikationsnetzwerks zu rekonfigurieren, das vom NSI verwendet wird, basierend auf der erstellten Slice-Konfigurationsrichtlinie.
Computerknoten nach Anspruch 14, wobei die NFV-Instanz durch eine dem QoS-Fluss zugeordnete MEC-Anwendung bereitgestellt wird, wobei die MEC-Anwendung auf virtuellen Ressourcen einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) des MEC-Systems ausgeführt wird.
Rechenknoten nach Anspruch 14, wobei die Verarbeitungsschaltung konfiguriert ist, um: eine Nutzenfunktion aus einer Vielzahl von verfügbaren Nutzenfunktionen basierend auf einer dem NSI zugeordneten Slice Service Level Agreement (SLA) auszuwählen; und die Slice-Konfigurationsrichtlinie weiterhin basierend auf dem Minimieren der ausgewählten Nutzenfunktion zu erstellen.
Rechenknoten nach Anspruch 16, wobei die Nutzenfunktion eine der folgenden ist: eine effizienzorientierte 5G- Nutzenfunktion zur Minimierung der End-to-End-Verzögerung (E2E) innerhalb des 5G-Kommunikationsnetzes; eine MEC-effizienzzentrierte Nutzenfunktion zum Minimieren der E2E-Verzögerung innerhalb des MEC-Systems; und eine Gesamteffizienz-Nutzfunktion zum Minimieren von Verletzungen des Slice-SLA.
Mindestens ein nichtflüchtiges maschinenlesbares Speichermedium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie von einer Verarbeitungsschaltung einer Computervorrichtung ausgeführt werden, die in einem Multi-Access Edge Computing (MEC)-fähigen Kommunikationsnetzwerk der fünften Generation (5G) betrieben wird, die Verarbeitungsschaltung zum Ausführen von Operationen veranlassen zum: Bestimmen einer Netzwerk-Slice-Instanz (NSI), die mit einem Dienstqualitäts-(QoS-)Fluss eines Benutzergeräts (UE) verknüpft ist, wobei der NSI Daten für eine Netzwerkfunktions-Virtualisierungs-(NFV-)Instanz eines Multi-Access-Edge-Computing-(MEC-)Systems innerhalb des 5G-Kommunikationsnetzes kommuniziert; Abrufen von Latenzinformationen für eine Vielzahl von Kommunikationsverbindungen, die von dem NSI verwendet werden, wobei die Vielzahl von Kommunikationsverbindungen einen ersten Satz von Nicht-MEC-Kommunikationsverbindungen, die einem Funkzugangsnetz (RAN) des 5G-Kommunikationsnetzes zugeordnet sind, und einen zweiten Satz von MEC-Kommunikationsverbindungen umfasst, die mit dem MEC-System verbunden sind; Erstellen einer Slice-Konfigurationsrichtlinie basierend auf den abgerufenen Latenzinformationen und Slice-spezifischen Attributen des NSI; und Rekonfigurieren von Netzwerkressourcen des 5G-Kommunikationsnetzwerks, das vom NSI verwendet wird, basierend auf der erstellten Slice-Konfigurationsrichtlinie.
Nichtflüchtiges maschinenlesbares Speichermedium nach Anspruch 18, wobei die NFV-Instanz von einer MEC-Anwendung bereitgestellt wird, die dem QoS-Fluss zugeordnet ist, wobei die MEC-Anwendung auf virtuellen Ressourcen einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) des MEC-Systems ausgeführt wird.
Nichtflüchtiges maschinenlesbares Speichermedium nach Anspruch 18, wobei die Verarbeitungsschaltung dazu konfiguriert ist: Auswählen einer Nutzenfunktion aus einer Vielzahl von verfügbaren Nutzenfunktionen basierend auf einer dem NSI zugeordneten Slice Service Level Agreement (SLA); und Generieren der Slice-Konfigurationsrichtlinie weiterhin basierend auf dem Minimieren der ausgewählten Nutzenfunktion.