DE102022200847A1

DE102022200847A1 - Bestärkendes lernen für mehrfachzugriffsverkehrsverwaltung

Info

Publication number: DE102022200847A1
Application number: DE102022200847.2A
Authority: DE
Inventors: Shilpa Talwar; Shu-Ping Yeh; Jingwen BAI
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-03-22
Filing date: 2022-01-26
Publication date: 2022-09-22
Also published as: US20220014963A1; CN115119331A

Abstract

Die vorliegende Offenbarung betrifft eine Mehrfachzugriffsverkehrsverwaltung in Edge-Rechenumgebungen und insbesondere Techniken mit künstlicher Intelligenz (KI) und/oder maschinellem Lernen (ML) zur Mehrfachzugriffsverkehrsverwaltung. Es wird eine skalierbare KI/ML-Architektur zur Mehrfachzugriffsverkehrsverwaltung bereitgestellt. Es werden auch Ansätze für bestärkendes Lernen (RL) und/oder tiefgehendes RL (DRL) bereitgestellt, die Richtlinien und/oder Parameter zur Verkehrsverwaltung und/oder zur Verteilung von Mehrfachzugriffsverkehr durch Interagieren mit der Umgebung lernen. Es werden auch Techniken für tiefgehendes RL mit kontextbezogenen Banditen zur intelligenten Verkehrsverwaltung für Edge-Netzwerke bereitgestellt. Weitere Ausführungsformen können beschrieben und/oder beansprucht werden.

Description

VERWANDTE ANMELDUNGEN
Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung Nr. 63/164,440 , eingereicht am 22. März 2021 („[AD2644-Z]“), der vorläufigen US-Anmeldung Nr. 63/165,011 , eingereicht am 23. März 2021 („[AD2794-Z]“) und der vorläufigen US-Anmeldung Nr. 63/165,015 , eingereicht am 23. März 2021 („[AD5127-Z]“), deren Inhalt hiermit durch Bezugnahme in ihren Gesamtheiten aufgenommen wird.
TECHNISCHES GEBIET
Hierin beschriebene Ausführungsformen betreffen allgemein Edge-Computing, Netzwerkkommunikation, Kommunikationssystemimplementierungen und künstliche Intelligenz (KI) und maschinelles Lernen (ML) und insbesondere KI/ML-Techniken zum Verwalten von Verkehr in Mehrfachzugriffskommunikationsnetzen.
STAND DER TECHNIK
Mehrfachzugriffstechnologie involviert zum Beispiel Endgeräte (UE), die mehr als eine Funkschnittstelle aufweisen, die auf mehrere Funkzugangsnetze (RANs) zugreifen können, die unterschiedliche Funkzugangstechnologien (RATs) implementieren. Derzeit fehlen jedoch Strategien zum effizienten Verwalten des Mehrfachzugriffsverkehrs, um verschiedene Dienstgüte(QoS)-Anforderungen verschiedener Anwendungen zu erfüllen.
Figurenliste
In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Zeichen mit unterschiedlichen Buchstabensuffixen können verschiedene Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen werden in den Figuren der begleitenden Zeichnungen beispielhaft und nicht einschränkend dargestellt, in denen gilt:

1a, 1b und 1c zeigen ein beispielhaftes modellfreies Framework für tiefgehendes bestärkendes Lernen für eine Mehrfachzugriffsverkehrsverwaltungsarchitektur (DRL-MTM-Architektur). 2 stellt beispielhaftes kollaboratives Multiagenten-DRL dar. 3 zeigt eine beispielhafte Einzelagenten-DRL-Architektur.
4 stellt ein beispielhaftes Edge-basiertes Mehrfachzugriffsverkehrsverwaltungs-Framework dar. 5 stellt eine beispielhafte Leistungsfähigkeitszusicherung für eine Architektur für bestärkendes Lernen dar.
6 stellt eine intelligente Mehrfachzugriffsverkehrsverwaltungsarchitektur dar.
7 zeigt vollständiges bestärkendes Lernen und kontextbezogene Banditenparadigmen.
8 stellt ein Framework für tiefgehendes bestärkendes Lernen mit kontextbezogenen Banditen dar. 9 stellt eine beispielhafte Systemarchitektur dar. 10a und 10b stellen Leistungsfähigkeitsergebnisse eines beispielhaften Systems für tiefgehendes bestärkendes Lernen mit kontextbezogenen Banditen dar.
11 veranschaulicht eine beispielhafte Edge-Rechenumgebung. 12 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Rechnen. 13 veranschaulicht Betriebsschichten unter Endpunkten, eine Edge-Cloud und Cloud-Rechenumgebungen. 14 veranschaulicht einen beispielhaften Ansatz für Vernetzung und Dienste in einem Edge-Rechensystem. 15 veranschaulicht den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. 16 veranschaulicht verschiedene Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen. 17 veranschaulicht einen Rechen- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Rechensystem involviert. 18 veranschaulicht eine MEC-Systemreferenzarchitektur. 19 veranschaulicht eine beispielhafte MEC-Dienstarchitektur. 20 stellt eine Open-RAN(O-RAN)-Systemarchitektur dar. 21 stellt eine logische Architektur der O-RAN-Systemarchitektur von 20 dar. 22 veranschaulicht eine O-RAN-Architektur, die Nahezu-RT-RIC-Schnittstellen beinhaltet. 23 stellt O-RAN-Architekturen/Frameworks zum Hinzufügen von xApps von Dritten dar. 24 stellt eine interne Nahezu-RT-RIC-Architektur dar.
25 veranschaulicht eine beispielhafte Softwareverteilungsplattform. 26 und 27 stellen beispielhafte Komponenten verschiedener Rechenknoten in einem oder mehreren Edge-Rechensystemen dar.

AUSFÜHRLICHE BESCHREIBUNG
Die folgenden Ausführungsformen betreffen allgemein Datenverarbeitungs-, Dienstverwaltungs-, Ressourcenzuordnungs-, Rechenverwaltungs-, Netzwerkkommunikations-, Anwendungspartitionierungs- und Kommunikationssystemimplementierungen und insbesondere Techniken und Konfigurationen zum Anpassen verschiedener Edge-Rechenvorrichtungen und Entitäten, um mehrere Entitäten (z. B. mehrere Mandanten, Benutzer, Stakeholder, Dienstinstanzen, Anwendungen usw.) in einer verteilten Edge-Rechenumgebung dynamisch zu unterstützen.
1. ARCHITEKTUR FÜR MEHRFACHZURIFFSVERKEHRSVERWALTUNG
Mehrfachzugriffstechnologie wird als ein Schlüssel für Edge-Rechentechnologien der fünften Generation (5G) und aufkommende angesehen. Das Edge-Netzwerk (siehe z. B. ein Edge-Netzwerk 1135 von 11 und/oder eine Edge-Cloud 1210 von 12) bewegt sich näher an Funkzugangsnetzwerke (RAN) (siehe z. B. RANs, die ein oder mehrere NANs 1131-1133 von 11 enthalten), da die Verzögerungsanforderungen für neue Anwendungen strikter werden. Viele Endgeräte (UEs) (z. B. UEs 1121, 1111 von 11) können mehr als eine Funkschnittstelle aufweisen und können unter Verwendung mehrerer Typen von RATs (z. B. 5G/NR, LTE, WiFi usw.) auf mehrere RANs zugreifen. Daher ist es von entscheidender Bedeutung, eine intelligente Mehrfachzugriffsverkehrsverwaltungsstrategie an Edge-Rechenknoten (z. B. dem Edge-Rechenknoten 1136 von 11) zu entwickeln, um die verschiedenen UE-Dienstgüte(QoS)-Anforderungen zu erfüllen (siehe z. B. 11).
Die vorliegende Offenbarung stellt Ausführungsformen und Implementierungen einer skalierbaren Architektur mit künstlicher Intelligenz (KI)/maschinellem Lernen (ML) für eine Mehrfachzugriffsverkehrsverwaltung bereit, indem neue Entwicklungen bei KI/ML-Technologien genutzt werden. Vorherige/existierende Lösungen zur Mehrfachzugriffsverkehrsverwaltung haben sich entweder auf modellbasierte Lösungen oder vordefinierte Richtlinien konzentriert. Zum Beispiel spezifiziert ein TCP-Schicht- oder Anwendungsschicht-Ansatz vorab eine Richtlinie, wie etwa Mehrpfad-TCP (MP-TCP) und Quick UDP (QUIC). Andere Lösungen, wie etwa die internationale Anmeldung Nr. PCT/US2020/066969 , eingereicht am 23. Dezember 2020 („[AC6833PCT]“), die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen ist, beruhen auf Netzwerknutzungsmaximierung, was RAN-Kenntnis, Verkehrsinformationen und dergleichen erfordert. Die vorherigen/existierenden Lösungen beruhen jedoch auf genauen mathematischen Modellen oder vordefinierten Steuerrichtlinien. Im Gegensatz dazu nutzen die hier besprochenen Implementierungen eine neue Entwicklung bei KI/ML, um einen modellfreien Ansatz zu entwickeln, um die beste Strategie einfach durch Interagieren mit der Umgebung und Sammeln der Laufzeitstatistiken zu lernen, ohne auf irgendein Optimierungsmodell oder irgendeine vordefinierte Richtlinie angewiesen zu sein. Ferner involvieren einige existierenden Technologien vorbestimmte Verkehrsroutingregeln, die nicht von RAN-Beobachtugnen abhängen (z. B. prioritätsbasierte Regeln und Regeln für Aktiv-Standby-Access-Traffic Steering, Switching-and Splitting (ATSSS), die vom 3GPP definiert sind). In der vorliegenden Offenbarung werden RAN-Beobachtungen (sowie Beobachtungen des UE 101 und NF-Beobachtungen) in den Verkehrsverwaltungsentscheidungsfindungsprozess eingebunden.
In der vorliegenden Offenbarung wird eine Architektur für tiefgehendes bestärkendes Lernen (DRL) für eine Mehrfachzugriffsverkehrsverwaltung an einem oder mehreren Edge-Rechenknoten bereitgestellt. Insbesondere werden hierin zwei unterschiedliche Architekturen erörtert, um die Skalierbarkeitsprobleme in DRL zu behandeln, um eine beliebige Anzahl von aktiven Mehrfachzugriffs-UEs oder -Abläufen im Netzwerk zu handhaben. Die zwei Architekturen beinhalten Einzelagenten-DRL mit LSTM (Long Short Term Memory) und Multiagenten-DRL. Im Folgenden wird auch ein Erkennungsmechanismus erörtert, der verwendet wird, um einen bestimmten Edge-Knoten (z. B. UEs 1111, 1121 von 11 und/oder dergleichen) auszulösen, um eine Verkehrslenkungs-/Aufteilungsaktualisierung unter Verwendung eines DRL-Frameworks durchzuführen.
Die hierin erörterten KI/ML-Verkehrsverwaltungstechniken können verwendet werden, um Edge-/Cloud-RAN-Intelligenz zu realisieren, die möglicherweise beispiellose QoS-Verbesserungen und Erweiterungen bieten kann. Spezifische Implementierungen der Ausführungsformen hierin können durch verschiedene Standards und/oder Spezifikationen bereitgestellt werden, wie etwa 3GPP, ETSI MEC, Open RAN (O-RAN) Alliance, OpenNESS und/oder dergleichen. Ein Meldungsformat und eine Meldungsaustauschsignalisierung zwischen Edge-/Cloud-Server und RAN-Knoten können zum Beispiel in derartigen Standards/Spezifikationen spezifiziert werden.
1a, 1b und 1c zeigen ein modellfreies Framework für tiefgehendes bestärkendes Lernen für ein Mehrfachzugriffsverkehrsverwaltungs-Framework (DRL-MTM-Framework) 100. In 1a agiert oder betreibt ein Edge-Rechenknoten 140 einen DRL-MTM-Agenten, der hierin als „Agent 140“ bezeichnet werden kann. Der Edge-Rechenknoten 140 betreibt eine intelligente bzw. ein intelligentes Mehrfachzugriffs-Verkehrsverwaltungsentität/-element (iMTM) 114 zum Durchführen verschiedener Mehrfachzugriffsverwaltungsaufgaben/- operationen, wie hierin besprochen. Der Edge-Rechenknoten 140 kann dem Edge-Rechenknoten 1136 aus 11 entsprechen. Als Beispiele kann der Edge-Rechenknoten 140 ein Mehrfachzugriffs-Edge-Rechen(MEC)-Server/Host (z. B. MEC-Host 1802 von 18), eine intelligente O-RAN-RAN-Steuerung (O-RAN-RIC) (z. B. Nicht-RT-RIC 2012 und/oder Nahezu-RT-RIC 2014 von 20 oder dergleichen) und/oder irgendein anderer Edge-Rechenknoten sein, wie etwa die hierin erörterten.
Die Umgebung, mit der Agent 140 interagiert, ist ein Mehrfachzugriffsnetzwerk 100x, in dem UEs 101 mit mehreren Funkschnittstellen vorhanden sind, die in der Lage sind, sich mit mehreren RANs einschließlich eines oder mehrerer RAN-Knoten 130-1, 130-2 und 130-3 zu verbinden (gemeinsam als „RAN-Knoten 130“ oder „RANs 130“ bezeichnet) mit jeweiligen Bedeckungsgebieten 133-1, 133-2 und 133-3 (gemeinsam als „Bedeckungsgebiete 133“ oder „Bedeckungsgebiet 133“ bezeichnet), von denen eine oder mehrere unterschiedliche Funkzugangstechnologien (RATs) nutzen. Die RAN-Knoten 130 in 1a können einem oder mehreren der NANs 1131-1133 von 11 entsprechen, die nachstehend erörtert werden, und die UEs 101 können den UEs 1121a und 1121b und/oder den IoT-Vorrichtungen 1110 von 11 entsprechen.
Für RL, innerhalb einer Episode, wird der Agent 140 mit einem Zustand s seiner Umgebung 100x konfrontiert. Auf Grundlage des aktuellen Zustands s der Umgebung 100x wählt der Agent 140 eine Aktion a aus. Nach dem Auswählen einer Aktion a erhält der Agent 140 einen neuen (nächsten) Zustand s'. Der nächste Zustand s' hängt sowohl von der gewählten Aktion a als auch von Beobachtungen der Umgebung 100x auf Grundlage der durchgeführten Aktion a ab. Die Aktion a ist die Verfahren, Operationen, Aufgaben usw. des Agenten 140, die dem Agenten 140 ermöglichen, mit der Umgebung 100x zu interagieren und diese zu ändern, und deshalb zwischen Zuständen s zu wechseln. In 1a erhält oder identifiziert der Agent 140 einen Zustand s auf Grundlage der Beobachtungen von den UEs 101 und/oder RANs/RAN-Knoten 130 über die Umgebung 100x und ermittelt die Aktion a auf Grundlage des Zustands s. Beispielsweise erhält der Agent 140 Beobachtungsdaten auf Grundlage verschiedener Messungen und/oder kontextbezogener Daten, ermittelt einen Zustand der Umgebung (Zustand s) auf Grundlage der erhaltenen Beobachtungsdaten und wählt dann Betriebsparameter und/oder Verkehrsverwaltungsstrategien (Aktion a) auf Grundlage des Zustands s aus bzw. ermittelt diese. Nach Implementieren und/oder Durchführen der Aktion a erhält der Agent 140 neue Beobachtungsdaten (einen nächsten Zustand s') und wählt dann neue Betriebsparameter und/oder Verkehrsverwaltungsstrategien (z. B. eine nächste Aktion a') aus. Bei manchen Implementierungen können während eines Anfangszustands herkömmliche vorbestimmte Regeln zur Verkehrsverwaltung verwendet werden und das RL-Modell kann in einer späteren Phase angewendet werden (z. B., nachdem ein anfänglicher Satz von Beobachtungsdaten gesammelt wurde).
In dem Beispiel von 1a ist der Agent 140 als Beobachtungsdaten von einem oder mehreren RANs/RAN-Knoten 130 und einem oder mehreren UEs 101 erfassend gezeigt. Zusätzlich oder alternativ dazu können Kernnetzwerkfunktionen dem Agenten 140 Leistungsfähigkeitsindikatoren bereitstellen, die verwendet werden können, um den Zustand der Umgebung 100x zu ermitteln. Zusätzlich zum Sammeln von Beobachtungen von UEs 101, RANs/RAN-Knoten 130 und Kernnetzwerkfunktionen kann der Agent 140 Beobachtungsdaten von anderen Edge-Rechenknoten 140 sammeln, die zusammen mit anderen RANs/RAN-Knoten 130 (in 1a nicht gezeigt) angeordnet sind, um das Bedeckungsgebiet für Verkehrsverwaltungslernen zu erweitern. Eine derartige Erfassung kann für eine gemeinsame Verkehrsverwaltung für ein breiteres Bedeckungsgebiet unter mehreren Edge-Rechenknoten 140 nützlich sein, wobei jeder teilnehmende Edge-Rechenknoten 140 seine Beobachtungsdaten wiederum für zukünftige Episoden, Epochen oder Iterationen der RL-Lern-/Inferenzermittlung weitergeben kann. Bei diesen Implementierungen kann der Agent 140 und/oder ein Repräsentationsnetz (z. B. das Repräsentationsnetz 301 von 3, das Repräsentationsnetz 901 von 9 und/oder dergleichen) mit Beobachtungsdaten trainiert werden, die von den anderen UEs 101, RANs/RAN-Knoten 130 und Kernnetzfunktionen erhalten wurden, die von den anderen Edge-Rechenknoten 140 abgedeckt/versorgt werden. Zusätzlich oder alternativ können verschiedene Edge-Rechenknoten 140 Merkmalsausgaben von ihren Agenten 140 und/oder Repräsentationsnetzen (z. B. Repräsentationsnetz 301 von 3, Repräsentationsnetz 901 von 9 und/oder dergleichen) gemeinsam nutzen, und ein globaler Agent oder ein globales Repräsentationsnetz kann trainiert werden, um die Auswirkung von jeweiligen UEs 101, RANs/RAN-Knoten 130 usw. zu extrahieren, die von verschiedenen Edge-Rechenknoten versorgt werden 140.
Zusätzlich ist das Verhalten (z. B. Verkehrsverwaltungsstrategien, Operationen usw.) jedes Elements/jeder Entität in der Umgebung 100x Teil der Umgebung 100x, die der Agent 140 zu navigieren lernt. Um seine Leistung zu verbessern, wird dem Agenten 140 eine Rückmeldung darüber bereitgestellt, ob der Agent 140 sein Ziel erreicht (z. B. Verbessern von Netzwerkbedingungen, Schonen von Netzwerk- und/oder Rechenressourcen usw.); diese Rückmeldung ist in Form einer Belohnung r, die eine numerische Bewertung ist, die eine Erfüllung eines Ziels repräsentiert. Jede Aktion a, die vom Agenten 140 durchgeführt wurde, bringt eine Belohnung r. Der Agent 140 ändert sein Verhalten, um die Menge an Belohnung, die er akkumuliert, zu erhöhen. Eine Sammlung von einem oder mehreren Zuständen, einer oder mehreren Aktionen und einer oder mehreren Belohnungen kann als Erfahrungsdaten bezeichnet werden. Eine einzige Datenstruktur kann verwendet werden, um die Erfahrungsdaten (z. B. einen Erfahrungspuffer oder Wiedergabepuffer, wie etwa die unten erörterten) aufzunehmen.
In einigen Implementierungen beruht die Entscheidung, welche Aktion a auszuwählen ist, auf einer Richtlinie π, die eine Anleitung zu der einen oder den mehreren optimalen in einem bestimmten Zustand durchzuführenden Aktionen mit dem Ziel bereitstellt, die Gesamtbelohnung zu maximieren. Jeder Zustand ist mit einer Wertefunktion V(s) assoziiert, die die erwartete Menge an einer oder mehreren zukünftigen Belohnungen vorhersagt, die in einem gegebenen Zustand durch Handeln nach der entsprechenden Richtlinie erhalten werden können. Die „Rückgabe“ bei einer Aktion ist eine zukünftige Belohnung, die der Agent nach Durchführung dieser Aktion erhalten kann. Die zukünftige Belohnung oder der zukünftige Ertrag kann als eine Gesamtsumme skontierter Belohnungen in Vorwärtsrichtung berechnet werden. Eine optimale Wertefunktion erzeugt einen maximalen Ertrag und eine optimale Richtlinie erzielt optimale Wertefunktionen. In einigen Implementierungen ist die Richtlinie π eine Abbildung von einem Zustand s auf eine oder mehrere Wahrscheinlichkeiten des Auswählens jeder möglichen Aktion a bei diesem gegebenenen Zustand s. Die Belohnung r ist ein numerischer Wert, der vom Agenten 140 von der Umgebung als eine direkte Reaktion auf die Aktionen a des Agenten 140 erhalten wird. Der Agent 140 versucht, die Gesamtbelohnung zu maximieren, die er während einer Epoche oder Episode empfängt (wobei eine Episode alle Zustände sind, die zwischen einem Anfangszustand und einem Endzustand stattfinden), sodass Belohnungen r die Motivation sind, die der Agent 140 benötigt, um auf eine gewünschte Weise zu agieren. Alle Aktionen bringen Belohnungen r ein, die grob in drei Typen unterteilt werden können, einschließlich positiver Belohnungen, die eine gewünschte Aktion hervorheben, negativer Belohnungen, die eine bestimmte Aktion herabsetzen, und Nullbelohnungen, die eine neutrale Aktion anzeigen.
Die Durchführung der Aktion a beinhaltet das Anweisen der UEs 101 und/oder RANs/RAN-Knoten 130, verschiedene Aktionen/Aufgaben/Operationen durchzuführen. Basierend auf diesen Aktionen/Aufgaben/Operationen wird dem Agenten 140 durch die UEs 101 und/oder RANs/RAN-Knoten 130 ein neuer Zustand s' basierend auf Beobachtungen bereitgestellt. Die Beobachtungen können verschiedene Arten von Daten, wie etwa netzwerkbezogene Daten, Signalmessungen usw., und/oder verschiedene Daten, wie etwa die hierin erörterten, sein.
Unter Bezugnahme auf 1b ist der Agent 140 (oder das iMTM 114) dafür verantwortlich, die Verkehrslenkungs-/-aufteilungsstrategie (z. B. Aktion a) für einzelne Mehrfachzugriffs-UEs 101 und/oder RANs/RAN-Knoten 130 in der Mehrfachzugriffsumgebung 100x basierend auf der Beobachtung zu entscheiden, die von der Umgebung 100x (Zustand s) gesammelt wurde. Nach dem Durchführen der Verkehrslenkungs-/-aufteilungsstrategie, die von dem Agenten 140 empfohlen wird (z. B. Aktion a), kann eine neue Beobachtung (Zustand s oder Zustand s') von der Umgebung 100x gesammelt werden und eine Belohnung r kann in Übereinstimmung mit einer konstruierten Belohnungsfunktion berechnet werden. Bei manchen Implementierungen kann die Belohnungsfunktion eine Zielfunktion sein. Bei manchen Implementierungen kann die Belohnungsfunktion unter Verwendung einer Belohnungsmaschine (RM) erzeugt werden (eine RM nimmt abstrahierte Beschreibungen der Umgebung als Eingabe und gibt eine oder mehrere Belohnungsfunktionen aus). Die Belohnung r kann durch ein oder mehrere Netzwerkelemente aus der Umgebung 100x bereitgestellt werden, vom Edge-Rechenknoten 140 erzeugt werden und/oder durch irgendein anderes Element/irgendeine andere Entität.
Ein tiefgehendes neuronales Netzwerk (DNN) 100b kann als das künstliche Gehirn des Agenten 140 (oder des iMTM 114) verwendet werden, um sehr große und komplizierte Beobachtungsräume zu handhaben. Das DNN 100b bestimmt die Verkehrslenkungs-/- aufteilungsstrategie (z. B. Aktion a) für individuelle Mehrfachzugriffs-UEs 101 und/oder RANs/RAN-Knoten 130. Das DRL-MTM 100 (oder DNN 100b) lernt, die besten oder optimalsten Verkehrsverwaltungsstrategien gemäß Laufzeitstatistiken auszuwählen, ohne auf Optimierungsmodelle oder vordefinierte Richtlinien angewiesen zu sein. Beispiele für den verkehrsverwaltungsbezogenen Aktionsraum a können Verkehrslenkung (z. B. Auswählen einer RAT, durch die der Verkehr zu routen ist), Verkehrsaufteilung (z. B. Aufteilen des Verkehrs auf mehrere RATs) und/oder gemeinsame Verkehrsnutzung (z. B. Senden von Verkehr von mehreren unterschiedlichen Flüssen über denselben Link/denselben Kanal) beinhalten. Bei manchen Implementierungen können die gemeinsamen Verkehrsnutzungsstrategien Definieren einer Funkverknüpfung als eine Standardverknüpfung/- verbindung beinhalten, um mehrere Benutzer und mehrere unterschiedliche Verkehrsflüsse zu unterstützen. Bei manchen Implementierungen kann eine Belohnungsfunktion (z. B. zum Bereitstellen einer Belohnung r) als eine Hilfsfunktion des Netzwerk-QoS-Ziels (z. B. Netzwerkdurchsatz, Paketverzögerung, Jitter, Alpha-Fairness usw.) implementiert werden. Hier erzeugt die Hilfsfunktion einen Hilfswert, der die erwartete unmittelbare Belohnung r zum Ausführen einer Aktion a in irgendeinem Zustand s plus die Summe der Langzeitbelohnungen über den Rest der Lebensdauer des Agenten 140 repräsentiert, unter der Annahme, dass der Agent 140 unter Verwendung der geeigneten (oder optimalen) Richtlinie π agiert. Bei einer Implementierung wird die Belohnung als eine Funktion von QoS-Messungen von allen UEs 101 berechnet, die unter Verwendung der Belohnungsfunktion (RF1) ausgedrückt werden können, und eine beispielhafte Hilfsfunktion pro Benutzer U (i, t) für einen Benutzer i zum Zeitpunkt t kann als Hilfsfunktion (UF1) ausgedrückt werden: $r_{t} = ?_{t} U (i, t)$
$U (i, t) = \frac{1}{d e l a y (i, t)}$
Die Langzeitbelohnungen können durch Summieren aller Belohnungen berechnet werden, die über einen Zeitraum (oder eine gesamte Episode) erzeugt werden. Zusätzlich oder alternativ kann eine Leistungsschwelle für ein aktuelles ML-Modell für Fälle definiert werden, wenn ein beobachteter Zustand s eine schlechte Verkehrsleistung anzeigt. Falls zum Beispiel die beobachtete Leistung unter einer Schwelle liegt, kann ein vorheriges ML-Modell oder ein modellbasierter Verkehrsverwaltungsalgorithmus, der eine relativ gute Leistung bereitgestellt hat, für das aktuelle ML-Modell ausgetauscht werden. Der Beobachtungsraum, der Aktionsraum und die eine oder die mehreren Belohnungen in der DRL-MTM-Architektur 100a werden im Folgenden besprochen.
1c veranschaulicht ein beispielhaftes künstliches neuronales Netz (KNN) 100c, das dem DNN 100b aus 1b entsprechen kann. Zusätzlich oder alternativ dazu kann das KNN 100c zur Verwendung durch eines oder mehrere der Rechensysteme (oder Subsysteme) der verschiedenen hierin erörterten Implementierungen, teilweise implementiert durch einen Hardwarebeschleuniger, und/oder dergleichen geeignet sein. Das KNN 100c kann ein mehrschichtiges neuronales Feedforward-Netz (FNN) sein, das eine Eingabeschicht L_x, eine oder mehrere verborgene Schichten L_a, L_b und L_c und eine Ausgabeschicht L_y (wobei a, b, c, x und y Zahlen sein können) umfasst. Zusätzlich oder alternativ kann das KNN 100c in einem anderen Typ von Topologie (oder einer Kombination von Topologien) sein, wie einem faltenden NN (CNN), einem rekurrenten NN (RNN), einem Long-Short-Term-Memory(LSTM)-Algorithmus, einem tiefen CNN (DCN), einem entfaltenden NN (DNN), einer Gated Recurrent Unit (GRU), einem Deep-Belief-NN, einem Feedforward-NN (FFN), einem tiefen FNN (DFF), einem tiefen Stapelnetz, einer Markov-Kette, einem Perzeptions-NN, einem Bayesschen Netz (BN), einem dynamischen BN (DBN), linearen dynamischen Systemen (LDS), einem Schalt-LDS (SLDS) und so weiter. Bei einer beispielhaften Implementierung ist das KNN 100c ein neuronales Netz eines DRL-Agenten (z. B. DNN 100b und/oder iMTM 114), der als ein oder mehrere Funktionsapproximatoren verwendet wird.
Jede der Schichten L umfasst ein oder mehrere Neuronen 110c (es wird angemerkt, dass der Kürze halber nicht alle Neuronen 110c in 1c beschriftet sind). Die Neuronen 110c können auch als Knoten 110c, Verarbeitungselemente (PEs) 110c oder dergleichen bezeichnet werden. Jedes Neuron 110c weist einen oder mehrere Eingaben auf und produziert eine einzige Ausgabe, die an mehrere andere Neuronen 110c gesendet werden kann (die Eingaben und Ausgaben können als „Signale“ bezeichnet werden). Die Eingaben können die Merkmalswerte einer Probe von externen Daten (z. B. Eingangsvariablen x_i) sein, oder sie können die Ausgaben anderer Neuronen 110c sein. Die Ausgaben der endgültigen Ausgangsneuronen 110c (z. B. Ausgangsvariablen y_j) erzielen die gewünschte/konfigurierte Aufgabe. Die Neuronen 110c und Kanten können auch Gewichtungen aufweisen, die angepasst werden, wenn das Lernen voranschreitet. Die Gewichtung erhöht oder verringert die Stärke des Signals an einer Verbindung. Die Neuronen 110c können eine Schwelle aufweisen, sodass ein Signal nur dann gesendet wird, wenn das aggregierte Signal diese Schwelle überschreitet. Die Neuronen 110c können in eine oder mehrere Schichten L aggregiert oder gruppiert werden, wobei unterschiedliche Schichten L unterschiedliche Transformationen an ihren Eingaben durchführen können.
Signale laufen von der ersten Schicht (der Eingabeschicht L₁) zur letzten Schicht (der Ausgabeschicht L_y), möglicherweise nach mehrmaligem Durchlaufen der Schichten L_a, L_b und L_c. In 1c empfängt die Eingabeschicht L_a Daten von Eingangsvariablen x_i (wobei i = 1, ...,p, wobei p eine Zahl ist). Die verborgenen Schichten L_a, L_b und L_c verarbeiten die Eingaben x_i, und schließlich liefert die Ausgabeschicht L_y Ausgangsvariablen y_j (wobei j = 1, ..., p', wobei p' eine Zahl ist, die gleich p oder davon verschieden ist). Im Beispiel von 1c gibt es zur einfacheren Veranschaulichung nur drei verborgene Schichten L_a, L_b und L_c im KNN 100c, das KNN 100c kann jedoch viel mehr (oder weniger) verborgene Schichten L_a, L_b und L_c enthalten als gezeigt sind. Die Ausgangsvariablen y_j können in Form von Ermittlungen, Inferenzen, Vorhersagen und/oder Bewertungen sein. Die Eingangsvariablen x_i können als ein Vektor festgelegt sein, der die relevanten Daten beinhaltet (z. B. Beobachtungen, ML-Merkmale usw.). Zusätzlich oder alternativ können die Ausgangsvariablen y_j als ein Vektor festgelegt sein, der die relevanten Daten beinhaltet (z. B. Ermittlungen, Inferenzen, Vorhersagen, Bewertungen und/oder dergleichen).
Üblicherweise weisen neuronale Netze feste Eingabe- und Ausgabedimensionen auf. In einem Mehrfachzugriffsnetzwerk können die Anzahl von UEs 101 mit einer oder mehreren Übertragungen und/oder die Anzahl von Verkehrsflüssen für unterschiedliche QoS-Anforderungen im Laufe der Zeit variieren. Falls das DRL-MTM als ein neuronales Netz implementiert ist, dessen Eingabe- und Ausgabedimensionen von der Anzahl aktiver UEs 101 oder Flüsse abhängen, kann das neuronale Netz, das für eine gewisse Anzahl aktiver UEs 101 oder Flüsse konzipiert ist, nicht verwendet werden, wenn sich die Anzahl aktiver UEs 101 oder Flüsse ändert. In einem solchen Fall muss entweder das neuronale Netz mit vollständig unterschiedlicher Größe von Grund auf neu trainiert werden, oder das neuronale Netz kann für eine große Anzahl von UEs 101 oder Flüssen gestaltet sein und die Eingabe kann mit null aufgefüllt werden, falls die tatsächliche Anzahl von UEs 101 oder Flüssen kleiner als die Größe des neuronalen Netzes ist. Diese Strategien sind jedoch nicht sehr skalierbar, um mit variierenden Drahtlosnetzgrößen umzugehen. Im Folgenden werden zwei skalierbare DRL-MTM-Architekturen erörtert, um die Bewegung eines realen dynamischen Benutzers/UE 101 und Verkehrsflussherstellung und -beendigung zu berücksichtigen. Diese skalierbaren DRL-MTM-Architekturen beinhalten kollaboratives Multi-Agenten-DRL (siehe z. B. 2) und Einzelagenten-DRL (siehe z. B. 3). Beide dieser Architekturen können einige oder alle der Aspekte des KNN 100c verwenden, die zuvor besprochen wurden.
1.1. KOLLABORATIVES MULTIAGENTEN-DRL
2 zeigt eine beispielhafte kollaborative Multiagenten-DRL-Architektur 200 nach verschiedenen Ausführungsformen. In der Architektur 200 ist jedes Mehrfachzugriffs-UE 101 als ein Agent konfiguriert, und bei dieser Implementierung kann jeder dieser Agenten als ein „Multiagent 101“ bezeichnet werden. Einige oder alle Multiagenten 101 interagieren mit der Umgebung 100x, um Beobachtungsdaten und/oder Laufzeitstatistiken zu sammeln. Bei manchen Implementierungen ermitteln einzelne Multiagenten 101 einen Zustand der Umgebung 100x. Bei anderen Implementierungen werden die Beobachtungen und/oder Laufzeitstatistiken an eine Koordinatorentität 210 gesendet, die den Zustand der Umgebung 100x ermittelt. Die Koordinatorentität 210 wird als eine zentralisierte Trainings-Engine oder ein zentralisierter Host an einem oder mehreren Edge-Rechenknoten und/oder einer RIC (z. B. Edge-Rechenknoten 140) eingesetzt. Netzwerkparameter 215 (z. B. von einem Kernnetz oder einer oder mehreren Netzwerkfunktionen (NFs)) können auch vom Koordinator 210 für den Zustand der Umgebung 100x verwendet werden. Die Netzwerkparameter 215 können verschiedene Leistungsfähigkeitsindikatoren sein, wie etwa jene, die hierin erörtert werden. Die Zustände werden an der zentralen Trainings-Engine 210 gesammelt und die Multiagenten 101 teilen sich die Belohnung.
Mit einer über alle teilnehmenden Multiagenten 101 verteilten Teambelohnung kann der Koordinator 210 ein gemeinsames Modell (z. B. KNN 100c) zentral trainieren und es auf einem oder mehreren Multiagenten 101 bereitstellen. Dann leiten die Multiagenten 101 eine Aktion basierend auf dem bereitgestellten Modell ab, indem sie die Verkehrslenkung oder das Aufteilungsverhältnis gemäß ihren individuellen Beobachtungen von der Interaktion mit der Umgebung 100x unabhängig vorhersagen. Die zentrale Trainings-Engine 210 trainiert das Modell (z. B. Aktualisieren der Gewichtungen) und das trainierte Modell wird auf den teilnehmenden Multi-Agenten 101 bereitgestellt. In Fällen, in denen der Zustand durch einzelne Multiagenten 101 bestimmt wird, kann jeder Multiagent 101 die Aktion nur basierend auf seinem eigenen beobachteten Zustand unter Verwendung des bereitgestellten Modells ermitteln. Eine derartige Architektur 200 ermöglicht ein zentralisiertes Training und verteilte Inferenzen.
2 zeigt auch eine beispielhafte kollaborative Multiagenten-DRL-Prozedur 220, die bei Operation 221 beginnt, bei der jedes UE 101 Beobachtungen aus der Umgebung sammelt, die für die Zustandseingabe und Belohnungsberechnung für den RL-Agenten verwendet werden. Bei Operation 222 melden einzelne UEs 101 ihre Beobachtungen und die Aktionen, die sie getätigt haben, an den zentralen Koordinator 210. Bei Operation 223 führt der zentrale Koordinator 210 ein zentralisiertes Training basierend auf den Beobachtungen und Aktionen durch, die von einigen oder allen der UEs 101 gemeldet werden. Zur RL-Modellaktualisierung wird eine zentralisierte Belohnung vom Koordinator 210 basierend auf den gesammelten Beobachtungen berechnet. Bei Operation 224 kann der Koordinator 210 das aktualisierte KI/ML-Modell auf einigen oder allen Agenten (z. B. UEs 101) bereitstellen. Bei einigen Implementierungen wird das aktualisierte Modell bereitgestellt, sobald das aktualisierte Modell bestimmte Verifizierungs-/Prüfkriterien erfüllt. Bei Operation 225 aktualisieren die UEs 101 ihr lokales Modell auf das neueste KI/ML-Modell, das vom Koordinator 210 bereitgestellt wird. Die UEs 101 führen Verkehrslenkungs-/-aufteilungsaktionen gemäß der Strategie durch, die vom KI/ML-Modell basierend auf einer oder mehreren aktuellen Beobachtungen berechnet wurde. Nach Operation 225 kann sich der Prozess wiederholen, indem er zu Operation 221 zurückkehrt.
Bei manchen Implementierungen ermöglicht der kollaborative Multiagenten-DRL-Mechanismus, dass Agenten miteinander zusammenarbeiten, während jeder Agent 140 nur die Verkehrsverwaltungsstrategie für ein UE 101 ermittelt. Bei manchen Implementierungen können mehrere Agenten gemeinsam an einem UE 101 oder einem Edge-Rechenknoten 140 angeordnet sein, um die Verkehrsverwaltungsstrategien für mehr als ein UE 101 zu ermitteln.
1.2. EINZELAGENTEN-DRL MIT VARIABLER EINGABEDIMENSION
3 zeigt eine beispielhafte Einzelagenten-DRL-Architektur 300. Bei dieser Ausführungsform wird ein einzelner Agent 140 durch einen Edge-Rechenknoten und/oder eine RIC (z. B. Edge-Rechenknoten 140) implementiert. Der Agent 140 sammelt RAN-Beobachtugnen von RAN-Knoten 130 und/oder direkt von einem oder mehreren UEs 101. Um zuvor besprochene Eingabedimensionsprobleme eines festen neuronalen Netzes zu überwinden, nutzen die Ausführungsformen hierin ein RNN, um Eingaben mit variabler Größe zu nehmen, um eine Repräsentation für manche oder alle aktiven UEs 101 und/oder Flüsse und ihre Dynamik zu lernen. RNNs weisen einen internen Zustand auf, der Kontextinformationen repräsentieren kann. RNNs behalten Informationen über vergangene Eingaben für eine Zeitdauer, die nicht apriori festgelegt ist, sondern stattdessen von ihren Gewichtungen und von den Eingabedaten abhängt.
In diesem Beispiel beinhaltet das RNN ein Repräsentationsnetz 301 (auch als „Merkmalsextrahierungsnetz 301“, „Merkmalslernnetz 301“ oder dergleichen bezeichnet), ein Aktornetz 303 und ein Kritiknetz 305. Das Repräsentationsnetz 301 entdeckt die Repräsentationen, die zur Merkmalsdetektion oder -klassifikation benötigt werden, aus Rohdaten (z. B. den gesammelten Beobachtungsdaten). Das Aktornetz 303 und das Kritiknetz 305 implementieren Aktor-Kritiker-Lernen. Aktor-Kritiker-Lernen ist eine RL-Technik, bei der ein Agent 140 gleichzeitig eine Richtlinienfunktion (Aktornetz 303) und eine Wertefunktion (Kritiknetz 305) lernt. Die Richtlinienfunktion (Aktornetz 303) ist die Entscheidungsfindungsentität mit einem oder mehreren abstimmbaren Parametern, und die Wertefunktion (Kritiknetz 305) bewertet die ermittelte Aktion a, um eine Rückmeldung zu erzeugen, um dabei zu helfen, den Trainingsprozess für die Richtlinienfunktion (Aktornetz 303) zu verbessern. In DRL wird die Richtlinienfunktion und/oder die Wertefunktion durch jeweilige mehrschichtige neuronale Netze berechnet. Die unabhängige Schichtstruktur eines DNN (siehe z. B. das KNN 100c von 1c) ermöglicht die Gradientenberechnungen durch Rückpropagation. Im Kontext von RL bezieht sich Rückpropagation auf eine rechnerische Implementierung der Kettenregel, wobei ein Algorithmus die relevanten partiellen Ableitungen mittels eines Rückwärtsdurchlaufs ermittelt. Bei Ausführungsformen kann jedes der Netze 301, 303 und 305 neuronale Netze sein, wie etwa das KNN 100c von 1c.
Sowohl das Aktornetz 303 als auch das Kritiknetz 305 berechnen Aktionsvorhersagen für einen aktuellen Zustand und erzeugen in jedem Zeitschritt ein Zeitdifferenz(TD)-Fehlersignal. Die Eingabe in das Aktornetz 303 ist ein aktueller Zustand (der eine Repräsentation ist, die durch das Repräsentationsnetz 301 erzeugt wird), und das Aktornetz 303 gibt einen Wert aus, der eine Aktion repräsentiert, die aus einem Aktionsraum (z. B. einem Satz potenzieller Aktionen, die durchzuführen sind) ausgewählt wird. Die Eingabe in das Kritiknetz 305 ist der aktuelle Zustand (der die durch das Repräsentationsnetz 301 erzeugte Repräsentation ist) und das Kritiknetz 305 gibt eine Rückmeldung oder eine Approximation für die vorhergesagte Aktion aus. Die Rückmeldung kann eine Bewertung, ein Rang, ein Grad, eine Beurteilung, eine Qualität oder irgendein anderer Wert sein, der die Angemessenheit oder Überlegenheit der vorhergesagten Aktion in Bezug auf andere potenzielle Aktionen angibt. Die Rückmeldung kann ein Zustandswert aus einer Zustandswertfunktion (z. B. V(s)) oder ein Qualitätswert (ein „Q-Wert“ oder „Aktionswert“) aus einer Q-Wertefunktion (z. B. Q(s, a)) sein. Zusätzlich oder alternativ gibt das Kritiknetz 305 eine Wahrscheinlichkeitsverteilung über verschiedene Aktionen und eine erwartete Rückkehr von der aktuellen Position aus. Zusätzlich oder alternativ gibt das Kritiknetz 305 einen oder mehrere Werte für jedes Zustand-Aktion-Paar aus. In beiden Fällen versucht das Aktornetz 303 wiederum, seine Richtlinie basierend auf der Approximation zu verbessern, die durch das Kritiknetz 305 bereitgestellt wird. Mit anderen Worten bestimmt das Aktornetz 303 die Aktion a, und das Kritiknetz 305 bewertet die Aktion a und ermittelt Anpassungen, die am Aktionsermittlungs-/Lernprozess vorzunehmen sind.
Bei manchen Implementierungen ist der Lernansatz des Aktornetzes 303 und/oder des Kritiknetzes 305 ein Richtliniengradientenlernansatz, wie etwa zum Beispiel eine Kreuzentropie-Verlustfunktion, Monte-Carlo-Richtliniengradient, MDP mit endlichem Horizont, durchschnittliche Belohnung mit unendlichem Horizont, unendlichem Horizont, diskontierte Belohnung mit unendlichem Horizont, deterministischer Richtliniengradient (DPG), tiefgehender DPG (DDPG), DDPG mit doppelter Verzögerung (TD3) und/oder dergleichen. Zusätzlich oder alternativ führt das Kritiknetz 305 Q-Lernen oder tiefgehendes Q-Lernen unter Verwendung von Funktionsapproximations- oder Quantisierungstechniken durch. Wenn das Kritiknetz 305 als ein Funktionenapproximierer agiert, versucht es, eine Wertfunktion einer Richtlinie, die durch das Aktornetz 303 verwendet wird, zu approximieren. Wenn das Kritiknetz 305 Quantisierungstechniken verwendet, sagt es die Belohnungswerte voraus, die unter Verwendung einer speziellen Richtlinie erzeugt werden.
Im Beispiel von 3 umfasst das RNN ein oder mehrere Long-Short-Term-Memory(LSTM)-Netzwerke. Ein LSTM ist ein Typ von RNN, das in der Lage ist, eine Reihenfolgenabhängigkeit in Sequenzvorhersageproblemen zu lernen. Die LSTM-Schicht im Repräsentationsnetz 301 (auch als „LSTM-Schicht 301“ bezeichnet) dient als eine Merkmalsextraktionsschicht, die Auswirkungen abstrahiert, die durch aktive UEs 101 und/oder individuelle Flüsse beigetragen werden. Die LSTM-Schicht 301 beinhaltet LSTM-1 to LSTM-N (wobei N eine Zahl ist), von denen jeder einen Zustand als eine Eingabe (z. B. Zustand $s_{t}^{1}$
bis Zustand $s_{t}^{N},$
wobei $s_{t}^{i}$
ein Zustand zum Zeitpunkt t ist) nimmt und jeweilige Merkmale (z. B. Merkmal $h_{t}^{1}$
bis Merkmal $h_{t}^{N},$
wobei $h_{t}^{i}$
ein Merkmal zum Zeitpunkt t ist und/oder eine erlernte Präferenz zum Auswählen einer Aktion $a_{t}^{i}$
im Zustand $s_{t}^{i}$
) ausgibt. Die Ausgaben der LSTM-Schicht 301 (z. B. Merkmale $h_{t}^{1}$
bis $h_{t}^{N}$
) werden sowohl in ein Aktornetz 303 als auch ein Kritiknetz 305 im Richtliniengradienten-RL-Framework eingegeben.
Eine oder mehrere zusätzliche RNN-Schichten (z. B. LSTM-Schichten) können im Aktornetz 303 und im Kritiknetz 305 für das Richtliniengradienten-RL-Framework hinzugefügt werden, um die Messsequenzkorrelation zu erlernen und diese zur Entscheidungsfindung einzubinden. Zum Beispiel kann die gelernte Messsequenzkorrelation vom Aktornetz 303 verwendet werden, um eine Aktion besser zu ermitteln, und die gelernte Messsequenzkorrelation kann vom Kritiknetz 305 verwendet werden, um die Rückmeldung besser zu ermitteln. Richtliniengradientenverfahren beinhalten direktes Modellieren und Optimieren einer Richtlinie π. Richtliniengradientenverfahren stellen ein Schema zum Abschätzen bereit, in welche Richtung eine oder mehrere Gewichtungen zu verschieben sind, um den Agenten 140 in seiner einen oder mehreren Aufgaben zu verbessern. Anstatt jede Gewichtung zufällig zu verschieben, werden die Erfahrungsdaten analysiert, um abzuschätzen, ob es besser wäre, eine spezielle Gewichtung zu erhöhen oder zu verringern. In diesem Fall kann der Richtliniengradient angeben, ob die Gewichtungen, die bestimmten Verkehrsverwaltungsstrategien zugewiesen sind, angepasst werden sollen, zum Beispiel Erhöhen oder Verringern der Gewichtungen, die einzelnen Verknüpfungen für spezifische Typen von Daten (oder QoS-Anforderungen) zugewiesen sind, und/oder dergleichen.
In einigen Implementierungen ermittelt der LSTM des Aktornetzes 303 (auch als „LSTM-Schicht 303“ bezeichnet) Aktionen A (einschließlich Aktionen A₁ bis A_y, wobei y eine Zahl ist) auf Grundlage der Zustände (einschließlich der Zustände s₁ bis s_x, wobei x eine Zahl ist) und/oder die Repräsentation vom Repräsentationsnetz 301. In einigen Implementierungen ermittelt der LSTM des Kritiknetzes 305 (auch als „LSTM-Schicht 305“ bezeichnet) einen Qualitätswert (oder „Q-Wert“) auf Grundlage einer Q-Funktion (z. B. Q(s, a)) unter Verwendung von Zuständen (einschließlich der Zustände s₁ bis s_x) und Aktionen (einschließlich der Aktionen a₁ bis a_z, wobei z eine Zahl ist) als Eingaben. Der Q-Wert ist ein Maß der insgesamt erwarteten Belohnung r unter der Annahme, dass sich der Agent 140 im Zustand s befindet und Aktion a durchführt und dann bis zum Ende der Episode einer Richtlinie π folgend (auch als eine „Entscheidungsfindungsregel π“ oder „Entscheidungsfindungsregeln π“ bezeichnet) fortfährt. Das Kritiknetz 305 kann Q-Lernen oder tiefgehendes Q-Lernen unter Verwendung von Funktionsapproximations- oder Quantisierungstechniken durchführen. Die LSTM-Schicht 305 erzeugt einen Richtliniengradienten basierend auf dem Q-Wert und stellt den Richtliniengradienten dem Aktornetz 303 bereit, das dann zum Erzeugen zukünftiger Aktionen verwendet wird.
In 3 wird in jeder Episode oder Epoche nur ein Ziel-UE 101 (oder Zielfluss) ausgelöst, um eine Aktionsaktualisierung zu erhalten. Beobachtungsinformationen aktiver UEs 101 (oder Flüsse) werden in der LSTM-Schicht 301 verwendet, um eine Repräsentation der aktuellen Umgebungsdynamik zu lernen. Der Agent 140 wird die gelernte Repräsentation und die Beobachtung des Ziel-UE 101 (oder des Zielflusses) als Eingabe in das Aktornetz 303 und das Kritiknetz 305 kombinieren, ein Richtliniengradientenframework verwenden, um die neuronalen Netze 303 und 305 zu trainieren, und eine Aktion ableiten und die eine oder die mehreren Verkehrslenkungs-/Aufteilungsregeln für das Ziel-UE 101 (oder den Zielfluss) aktualisieren.
Zusätzlich oder alternativ dazu können das RL-Modell und/oder der Agent 140 auf mehrere Edge-Rechenknoten 140 zum verteilten Training und/oder zur verteilten Inferenzermittlung verteilt sein. Zum Beispiel kann ein erster Teil des Trainings an dem ersten Edge-Rechenknoten 140 durchgeführt werden, ein zweiter Teil des Trainings kann an einem zweiten Edge-Rechenknoten 140 durchgeführt werden und so weiter. Drei Arten von verteiltem Training können unter mehreren Edge-Rechenknoten 140 eingesetzt werden. Eine erste verteilte Trainingsimplementierung involviert Partitionieren und/oder Parallelisieren von Daten und Verteilen unterschiedlicher Sätze der partitionierten/parallelisierten Daten auf jeweilige Edge-Rechenknoten 140, und das RL-Modell wird auf einem einzigen Edge-Rechenknoten 140 gehostet. Zum Beispiel können Beobachtungsdaten, die von verschiedenen UEs 101, RAN-Knoten 130 usw. gesammelt werden, in eine Teilmenge von Datenspuren partitioniert werden und ein Edge-Rechenknoten 140 aktualisiert das ML-Modell basierend auf seinem Datenspursatz; danach kann eine zentrale Trainings-Engine, die von einem Edge-Rechenknoten 140 implementiert wird, das aktualisierte Modell oder die Gradientenaktualisierung von mehreren Edge-Rechenknoten 140 sammeln, um eine globale Modellaktualisierung durchzuführen. Eine zweite verteilte Trainingsimplementierung beinhaltet Parallelisieren des RL-Modells und Verteilen des parallelisierten RL-Modells auf verschiedene Edge-Rechenknoten 140. Zum Beispiel können unterschiedliche Phasen des RL-Modells in einem unterschiedlichen Edge-Rechenknoten 140 laufen. Eine dritte verteilte Trainingsimplementierung ist ein hybrider Ansatz, der sowohl die erste als auch die zweite verteilte Trainingsimplementierung beinhaltet. Falls das Training ferner unter Verwendung mehrerer Edge-Rechenknoten 140 erreicht wird, dann sollte die potenzielle Latenz berücksichtigt werden, während das Daten- und/oder Modellparallelitäts-/-teilungsschema gestaltet wird.
1.3. BEOBACHTUNGSDATEN UND AUSLÖSEMECHANISMEN FÜR MODELLAKTUALISIERUNGEN
Wie vorher erwähnt, erhält oder ermittelt der Agent 140 in den 1a-3 einen Zustand s auf Grundlage der Beobachtungen von den UEs 101 und/oder RANs/RAN-Knoten 130, ermittelt und führt eine Aktion a auf Grundlage des Zustands s durch. Beispiele für die Beobachtungen (z. B. Zustand s, s' in 1a-3), die von der Umgebung 100x an eine Trainings-Engine (die z. B. von einem oder mehreren Edge-Rechenknoten 140 und/oder ein Cloud-Rechensystem/einen Cloud-Rechendienst betrieben wird) gesendet werden, können eine oder mehrere andere Messungen beinhalten, wie etwa beliebige der hierin erörterten, Anwendungsanforderungen, Betriebsparameter (z. B. Betriebsinformationen von UEs 101 und/oder RANs 130), Kontextinformationen, Hardwarekonfigurationen der UEs 101 und/oder RANs 130, Ressourcennutzung (an spezifischen Vorrichtungen und/oder Netzwerk-/Funkressourcen) und/oder beliebige andere geeignete Beobachtungen oder Aspekte.
Für die Architekturen 200 und 300 können Mechanismen zum Auslösen von Verkehrsverwaltungsstrategieaktualisierungen für bestimmte UEs 101 eingesetzt werden. Verschiedene Beobachtungen und/oder Messungen können verwendet werden, um die UEs 101 zu detektieren, bei denen Richtlinienaktualisierungen ausgelöst werden müssen. Diese Detektionstechniken können entweder am Edge-Rechenknoten 140 oder am NAN 130 durchgeführt werden, um eine Verkehrsverwaltungsrichtlinienaktualisierung für die qualifizierten und/oder ausgewählten UEs 101 auszulösen.
Bei einigen Ausführungsformen werden zwei Arten von Messrückmeldungen für diese Zwecke verwendet: Messungen/Rückmeldungen pro UE, Messungen/Rückmeldungen pro NAN (z. B. Zentraleinheit (CU), verteilte Einheit (DU), entfernte Einheit (RU) (oder entfernt entfernte Einheit (RRU)), Basisstation (z. B. eNB, gNB usw.), Zugangspunkt usw.).
Beispiele für Messungen/Rückmeldungen pro UE beinhalten verschiedene Arten von Verzögerung (z. B. Paketverzögerung usw.) einschließlich Durchschnittsverzögerung, Verzögerungsschwankung usw.; Paketverlustrate; Paketverwerfungsrate; PHY-Rate; Goodput; UE-Durchsatz (z. B. durchschnittlicher DL-UE-Durchsatz im NAN 130, durchschnittlicher UL-UE-Durchsatz im NAN 130, Verteilung des DL-UE-Durchsatzes im NAN 130, Verteilung des UL-UE-Durchsatzes im NAN 130, Prozentsatz von uneingeschränktem DL-UE-Datenvolumen im NAN 130, Prozentsatz von uneingeschränktem UL-UE-Datenvolumen im NAN 130 usw.); Jitter; Alpha-Fairness („α-Fairness“); mit einem Kanalqualitätsindikator (CQI) verbundene Messungen; mit einem Modulationscodierschema (MCS) verbundene Messungen; und/oder dergleichen. Falls basierend auf den Messungen pro UE ein QoS-Ziel für einen gewissen Zeitraum nicht relativ konsistent erfüllt wird (z. B. verletzt eine Paketverzögerung für ein gewisses UE 101 die Anforderung für einen Zeitraum von 10 s), wird beim UE 101 eine Verkehrsverwaltungsstrategieaktualisierung ausgelöst. Die Aktualisierungsregel kann auch mehrere Metriken berücksichtigen, wie etwa eine hohe Verzögerung, eine hohe Paketverlustrate und/oder dergleichen.
Beispiele für Messungen pro NAN beinhalten physische Ressourcenblock(PRB)-Nutzung, Zellendurchsatz, Funknutzungspegel pro NAN (z. B. physische Funkressourcennutzung und dergleichen), Paketverzögerung, Datenvolumenmessungen, CQIbezogene Messungen, MCS-bezogene Messungen und/oder dergleichen. Basierend auf NANbasierten Messungen kann eine Gruppe von UEs 101, die zu demselben NAN 130 (z. B. DU usw.) gehören (oder von diesem versorgt werden), zur Richtlinienaktualisierung ausgelöst werden, falls das NAN 130 (z. B. DU usw.) konsistent spezifische Bedingungen erlebt, wie etwa zum Beispiel einen hohen PRB-Nutzungspegel, einen niedrigen Durchsatz und/oder dergleichen.
Beispiele für die Paketverzögerungsmessungen für Messungen pro UE und/oder pro NAN beinhalten eine Verteilung einer Verzögerung bei DL an einer Luftschnittstelle (z. B. die Verteilung der Zeit, die die Paketübertragung über die Luftschnittstelle in der Downlink-Richtung benötigt); eine durchschnittliche Verzögerung UL auf der Drahtlosluftschnittstelle (z. B. die durchschnittliche (arithmetisches Mittel) Paketverzögerung über Luft auf dem Uplink); eine durchschnittliche RLC-Paketverzögerung in der UL (z. B. die durchschnittliche (arithmetisches Mittel) RLC-Paketverzögerung auf dem Uplink, die eine Verzögerung innerhalb der gNB-DU sein kann); eine durchschnittliche PDCP-Umordnungsverzögerung in der UL (z. B. die durchschnittliche (arithmetisches Mittel) PDCP-Umordnungsverzögerung auf dem Uplink, die die Verzögerung innerhalb der gNB-CU-UP sein kann), eine Verteilung der DL-Verzögerung zwischen NG-RAN und UE (z. B. eine Verteilung der DL-Paketverzögerung zwischen NG-RAN und UE, die die Verzögerung ist, die im NG-RAN auftritt (einschließlich der Verzögerung an gNB-CU-UP, an F1-U und an gNB-DU) und die Verzögerung über die Uu-Schnittstelle); eine Verteilung der UL-Verzögerung zwischen NG-RAN und UE (z. B. die Verteilung der UL-Paketverzögerung zwischen NG-RAN und UE, die die Verzögerung ist, die im NG-RAN auftritt (einschließlich der Verzögerung an einer CU-UP, an F1-U und an einer DU) und die Verzögerung über die Uu-Schnittstelle); eine DL-Paketverzögerung zwischen NG-RAN und PDU-Sitzungsanker(PSA)-UPF; eine durchschnittliche Verzögerung bei DL in CU-UP (z. B. die durchschnittliche (arithmetisches Mittel) PDCP-SDU-Verzögerung auf dem Downlink innerhalb der gNB-CU-UP für alle PDCP-Pakete); die durchschnittliche Verzögerung bei DL auf F1-U (z. B. die durchschnittliche (arithmetisches Mittel) GTP-Paketverzögerung bei DL auf der F1-U-Schnittstelle); die durchschnittliche Verzögerung bei DL in gNB-DU (z. B. die durchschnittliche (arithmetisches Mittel) RLC-SDU-Verzögerung auf dem Downlink innerhalb der gNB-DU, für anfängliche Übertragung aller RLC-Pakete); eine Verteilung der Verzögerung bei DL in CU-UP (z. B. die Verteilung der PDCP-SDU-Verzögerung auf dem Downlink innerhalb der gNB-CU-UP, für alle PDCP-Pakete); Verteilung der Verzögerung bei DL auf F1-U (z. B. die Verteilung der GTP-Paketverzögerung bei DL auf der F1-U-Schnittstelle); eine Verteilung der Verzögerung bei DL in gNB-DU (z. B. die Verteilung der RLC-SDU-Verzögerung auf dem Downlink innerhalb der gNB-DU, zur anfänglichen Übertragung aller RLC-Pakete); und dergleichen.
Beispiele für die Paketverlustratenmessungen für die Messungen pro UE und/oder pro NAN beinhalten eine UL-PDCP-SDU-Verlustrate (z. B. der Anteil von PDCP-SDU-Paketen, die bei gNB-CU-UP nicht erfolgreich empfangen werden; ein Maß für den UL-Paketverlust einschließlich beliebiger Paketverluste in der Luftschnittstelle, in der gNB-CU und auf der F1-U-Schnittstelle); eine UL-F1-U-Paketverlustrate (z. B. der Anteil von PDCP-SDU-Paketen, die nicht erfolgreich an gNB-CU-UP empfangen werden). Sie ist ein Maß für den UL-Paketverlust an der F1-U-Schnittstelle); eine DL-F1-U-Paketverlustrate (z. B. der Anteil von PDCP-SDU-Paketen, die nicht erfolgreich an der gNB-DU empfangen werden); und dergleichen.
Beispiele für die Paketverwerfungsratenmessungen für die Messungen pro UE und/oder pro NAN beinhalten eine DL-PDCP-SDU-Verwerfungsrate in gNB-CU-UP (z. B. den Anteil von PDCP-SDU-Paketen, die auf dem Downlink aufgrund hoher Verkehrslast verworfen werden, Verkehrsverwaltung usw. in der gNB-CU-UP); eine DL-Paketverwerfungsrate in gNB-DU (z. B. den Anteil von RLC-SDU-Paketen, die auf dem Downlink aufgrund hoher Verkehrslast, Verkehrsverwaltung usw. in der gNB-DU verworfen werden); und dergleichen.
Beispiele für die Datenvolumenmessungen für die Messungen pro UE und/oder pro NAN beinhalten ein DL-PDCP-PDU-Datenvolumen (z. B. das Datenvolumen (Menge von PDCP-PDU-Bits) in dem DL, das von einer CU an eine DU geliefert wird); ein UL-PDCP-PDU-Datenvolumen (z. B. das Datenvolumen (Menge von PDCP-PDU-Bits) in dem UL, das von einer DU an eine CU geliefert wird); ein DL-PDCP-SDU-Datenvolumen (z. B. das Datenvolumen (Menge an PDCP-SDU-Bits) in dem DL, das an die PDCP-Schicht geliefert wird); und/oder ein UL-PDCP-SDU-Datenvolumen pro Schnittstelle (z. B. das Datenvolumen (Menge an PDCP-SDU-Bits) in dem UL, das an eine CU-UP von einer DU (F1-U-Schnittstelle), von außerhalb einer CU-UP (Xn-U-Schnittstelle) und von außerhalb eines eNB (X2-U-Schnittstelle) geliefert wird.
Beispiele für die CQI-bezogenen Messungen für die Messungen pro UE und/oder pro NAN beinhalten eine Breitband-CQI-Verteilung (z. B. die Verteilung von Breitband-CQI, die durch UEs 101 in einer Zelle 133 gemeldet wird). Messungen von CQI, die von den UEs 101 gemeldet werden, sind eine nützliche Metrik, die HF-Signalqualität und Dienstqualität widerspiegelt. Beispiele für die MCS-bezogenen Messungen für die Messungen pro UE und/oder pro NAN beinhalten eine MCS-Verteilung in einem gemeinsam genutzten physischen Downlink-Kanal (PDSCH) (z. B. die Verteilung des MCS, das für PDSCH-RB durch NG-RAN geplant ist); eine MCS-Verteilung in einem gemeinsam genutzten physischen Uplink-Kanal (PUSCH) (z. B. die Verteilung des MCS, das für PUSCH-RB durch NG-RAN geplant ist); die PDSCH-MCS-Verteilung für MU-MIMO (z. B. die Verteilung des MCS, das für PDSCH-RB durch NG-RAN in MU-MIMO-Szenario geplant ist); und/oder die PUSCH-MCS-Verteilung für MU-MIMO (z. B. die Verteilung des MCS, das für PUSCH-RB durch NG-RAN in MU-MIMO-Szenario geplant ist). Zusätzlich oder alternativ dazu können andere Kanalzustandsinformationen (CSI) gemeldet werden, wie etwa zum Beispiel CQI, ein Vorcodiermatrixindikator (PMI), ein CSI-RS-Ressourcenindikator (CRI), ein SS/PBCH-Blockressourcenindikator (SSBRI), ein Schichtindikator (LI), ein Rangindikator (RI), L1-RSRP und/oder L1-SINR.
Zusätzlich oder alternativ können die Messungen für die Beobachtungen und/oder das Auslösen der Richtlinienaktualisierung eine oder mehrere der folgenden Messungen beinhalten: Messungen in Bezug auf den Datenfunkträger (DRB) (z. B. Anzahl von DRBs, deren Einrichtung versucht wurde, Anzahl von DRBs, die erfolgreich eingerichtet wurden, Anzahl von freigegebenen aktiven DRBs, Sitzungsaktivitätszeit für DRB, Anzahl von DRBs, deren Wiederaufnahme versucht wurde, Anzahl von DRBs, die erfolgreich wiederaufgenommen wurden usw.); Messungen in Bezug auf Funkressourcensteuerung (RRC) (z. B. eine mittlere Anzahl von RRC-Verbindungen, eine maximale Anzahl von RRC-Verbindungen, eine mittlere Anzahl von gespeicherten inaktiven RRC-Verbindungen, eine maximale Anzahl von gespeicherten inaktiven RRC-Verbindungen, eine Anzahl von versuchten, erfolgreichen, und/oder fehlgeschlagene RRC-Verbindungaufbauten usw.); Messungen in Bezug auf den UE-Kontext (UECNTX); Messungen in Bezug auf die Funkressourcenausnutzung (RRU) (z. B. DL-PRB-Gesamtnutzung, UL-PRB-Gesamtnutzung, Verteilung der DL-PRB-Gesamtnutzung, Verteilung der UL-PRB-Gesamtnutzung, DL-PRB, der für Datenverkehr verwendet wird, UL-PRB, der für Datenverkehr verwendet wird, gesamt verfügbare DL-PRBs, gesamt verfügbare UL-PRBs usw.); Messungen in Bezug auf Registrierungsverwaltung (RM); Messungen in Bezug auf Sitzungsverwaltung (SM) (z. B. Anzahl von PDU-Sitzungen, die zum Einrichten angefordert werden; eine Anzahl von PDU-Sitzungen, die erfolgreich eingerichtet werden sollen; eine Anzahl von PDU-Sitzungen, die nicht eingerichtet werden sollen usw.); Messungen in Bezug auf GTP-Verwaltung (GTP); Messungen in Bezug auf IP-Verwaltung (IP); Messungen in Bezug auf Richtlinienassoziation (PA); Messungen in Bezug auf Mobilitätsmanagement (MM) (z. B. für Inter-RAT-, Intra-RAT- und/oder Intra/Inter-Frequenz-Handovers und/oder bedingte Übergaben: Anzahl angeforderter, erfolgreicher und/oder gescheiterter Übergabe-Vorbereitungen; Anzahl angeforderter, erfolgreicher und/oder gescheiterter Übergabe-Ressourcenzuweisungen; Anzahl angeforderter, erfolgreicher und/oder gescheiterter Übergabe-Ausführungen; mittlere und/oder maximale Zeit angeforderter Übergabe-Ausführungen; Anzahl erfolgreicher und/oder fehlgeschlagener Übergabe-Ausführungen pro Strahlpaar usw.); Messungen in Bezug auf virtualisierte Ressource(n) (VR); Messungen in Bezug auf Träger (CARR); Messungen in Bezug auf QoS-Flüsse (QF) (z. B. Anzahl freigegebener aktiver QoS-Flüsse, Anzahl freigegebener QoS-Flüsse, die versucht werden, Aktivitätszeit in der Sitzung für QoS-Fluss, Aktivitätszeit in der Sitzung für ein UE 101, Anzahl von QoS-Flüssen, deren Einrichtung versucht wurde, Anzahl von QoS-Flüssen, die erfolgreich eingerichtet wurden, Anzahl von QoS-Flüssen, die nicht eingerichtet wurden, Anzahl von anfänglichen QoS-Flüssen, deren Einrichtung versucht wurde, Anzahl von anfänglichen QoS-Flüssen, Anzahl anfänglicher QoS-Flüsse, deren Einrichtung fehlgeschlagen ist, Anzahl der QoS-Flüsse, deren Modifizierung versucht wurde, Anzahl QoS-Flüsse, die erfolgreich modifiziert wurden, Anzahl QoS-Flüsse, deren Modifizierung fehlgeschlagen ist usw.); Messungen in Bezug auf Anwendungsauslösung (AT); Messungen in Bezug auf einen Kurznachrichtendienst (SMS); Messungen in Bezug auf Leistung, Energie und Umgebung (PEE); Messungen in Bezug auf einen NF-Dienst (NFS); Messungen in Bezug auf eine Paketflussbeschreibung (PFD); Messungen in Bezug auf Direktzugangskanal (RACH); Messungen in Bezug auf einen Messbericht (MR); Messungen in Bezug auf eine Schicht-1-Messung (L1M); Messungen in Bezug auf eine Netzwerksegment-Auswahl (NSS); Messungen in Bezug auf Paging (PAG); Messungen in Bezug auf eine Nicht-IP-Datenlieferung (NIDD); Messungen in Bezug auf externe Parameterbereitstellung (EPP); Messungen in Bezug auf Verkehrseinfluss (TI); Messungen in Bezug auf Verbindungsherstellung (CE); Messungen in Bezug auf Dienstparameterbereitstellung (SPP); Messungen in Bezug auf Hintergrunddatenübertragungsrichtlinie (BDTP); Messungen in Bezug auf Datenverwaltung (DM); und/oder beliebige andere Leistungsfähigkeitsmessungen, wie in [TS28552] erörtert.
Zusätzlich oder alternativ dazu kann die Trainings-Engine und/oder der Agent 140 Leistungsfähigkeitsindikatoren von einem Kernnetz (oder einzelnen NFs) als Teil der Beobachtungsdaten (z. B. Zustandsdaten zum Ermitteln geeigneter Aktionen und/oder zum Auslösen einer Richtlinienaktualisierung) verwenden. Leistungsfähigkeitsindikatoren umfassen Leistungsfähigkeitsdaten, die über eine Gruppe von NFs aggregiert sind, wie etwa zum Beispiel durchschnittliche Latenz entlang eines Netzwerksegments. Die Leistungsfähigkeitsindikatoren können aus Leistungsfähigkeitsmessungen abgeleitet werden, die an bestimmten NFs gesammelt wurden, die zu der Gruppe gehören. Das Aggregationsverfahren ist in der Leistungsindikatordefinition identifiziert. Leistungsfähigkeitsindikatoren auf Netzwerksegment-Subnetzebene können aus den Leistungsfähigkeitsmessungen abgeleitet werden, die an den NFs gesammelt werden, die zu den Netzwerksegment-Subnetzen oder zu den einzelnen Netzwerksegment-Subnetzen gehören. Die Leistungsfähigkeitsindikatoren auf Netzwerksegment-Subnetzebene können über den entsprechenden Leistungsfähigkeitsverwaltungsdienst für ein Netzwerksegment-Subnetz bereitgestellt werden. Die Leistungsfähigkeitsindikatoren auf Netzwerksegment-Ebene können aus den Leistungsfähigkeitsindikatoren auf Netzwerksegment-Subnetzebene abgeleitet werden, die an den konstituierenden Netzwerksegment-Subnetzen und/oder NFs gesammelt werden. Die Leistungsfähigkeitsindikatoren auf Netzwerksegment-Ebene können über den entsprechenden Leistungsfähigkeitsverwaltungsdienst für Netzwerksegment verfügbar gemacht werden.
Zusätzlich oder alternativ dazu können in Fällen, in denen eine Diskrepanz in den Beobachtungsdaten von einem oder mehreren UEs 101, einem oder mehreren RANs 130 und/oder Kernnetzwerk-NFs (z. B. fehlende Berichte, fehlerhafte Daten, usw.) besteht, einfache Anrechnungen durchgeführt werden, um die erhaltenen Beobachtungsdaten zu ergänzen, wie etwa zum Beispiel Substituieren von Werten aus vorherigen Berichten und/oder historischen Daten, Anwenden eines Extrapolationsfilters und/oder dergleichen. Zusätzlich oder alternativ dazu können akzeptable Grenzen für die Beobachtungsdaten vorbestimmt oder konfiguriert werden. Zum Beispiel können CQI- und MCS-Messungen so konfiguriert sein, dass sie nur innerhalb von Bereichen liegen, die durch geeignete 3GPP-Standards definiert sind. In Fällen, in denen ein gemeldeter Datenwert keinen Sinn ergibt (z. B. überschreitet der Wert einen akzeptablen Bereich/akzeptable Grenzen oder dergleichen), können solche Werte für die aktuelle Lern-/Trainingsepisode oder -epoche verworfen werden. Zum Beispiel können Paketlieferverzögerungsgrenzen definiert oder konfiguriert werden, und Pakete, von denen ermittelt wurde, dass sie nach der Paketlieferverzögerungsgrenze empfangen wurden, können verworfen werden.
Bei beliebigen der hierin besprochenen Ausführungsformen können beliebige geeignete Datensammlungs- und/oder Messmechanismen verwendet werden, um die Beobachtungsdaten zu sammeln. Zum Beispiel können Datenmarkierung (z. B. Sequenznummerierung usw.), Paketverfolgung, Signalmessung, Datenabtastung und/oder Zeitstempeltechniken verwendet werden, um beliebige der zuvor genannten Metriken/Beobachtungen zu ermitteln. Die Sammlung von Daten kann auf dem Stattfinden von Ereignissen basieren, die eine Sammlung der Daten auslösen. Zusätzlich oder alternativ kann eine Datensammlung bei der Initiierung oder Beendigung eines Ereignisses erfolgen. Die Datensammlung kann kontinuierlich, diskontinuierlich sein und/oder Start- und Stoppzeiten aufweisen. Die Datensammlungstechniken/-mechanismen können für eine Hardware(HW)-Konfiguration/- Implementierung spezifisch oder nicht HW-spezifisch sein oder können auf verschiedenen Softwareparametern (z. B. Betriebssystemtyp und -version usw.) basieren. Verschiedene Konfigurationen können verwendet werden, um beliebige der vorgenannten Datensammlungsparameter zu definieren. Derartige Konfigurationen können durch geeignete Spezifikationen/Standards, wie etwa 3GPP-, ETSI- und/oder O-RAN-Standards, definiert sein.
2. LEISTUNGSSICHERUNG FÜR BESTÄRKENDES LERNEN IN MEHRFACHZUGRIFFSVERKEHRSVERWALTUNGSDIENSTEN
Da immer mehr Client-Vorrichtungen (z. B. UEs 1111, 1121 von 11) mit mehreren Funkschnittstellen ausgestattet sind, gibt es zunehmend Interesse, mehrere gleichzeitige Verbindungen zwischen einer Mehrfachfunkvorrichtung (z. B. einem Mehrfachzugriffs-UE) und einem Mehrfachzugriffsnetzwerk (z. B. NANs 1131-1133 von 11) für verbesserte Bandbreite und Zuverlässigkeit herzustellen. Die Zunahme von Edge-Computing initiiert ein neues Mehrfachzugriffsverkehrskonvergenzmodell: Konvergieren von Mehrfachzugriffsverkehr an der Edge mit einem intelligenten Verkehrsmanager, der Pakete über mehrere Pfade verteilt, um eine bessere QoS zu erreichen. Aufkommende datengesteuerte KI/ML-Techniken können verwendet werden, um Mehrfachzugriffsverkehrsverteilungsstrategien zu entwickeln.
Die vorliegende Offenbarung erwägt Ansätze für bestärkendes Lernen (RL), die Richtlinien und/oder Parameter zur Verkehrsverwaltung und/oder zur Verteilung von Mehrfachzugriffsverkehr durch Interagieren mit der Umgebung lernen. Schlechte Aktionen während der Erkundung und einer frühen Trainingsphase für Online-RL können jedoch eine ernsthafte Leistungsverschlechterung verursachen. In Mobilfunknetzen können mögliche Folgen darin bestehen, Dienstgütevereinbarungen nicht zu erfüllen, oder eine Beeinträchtigung des Benutzererlebnisses, wie etwa Verbindungsunterbrechung und -ausfall. Die vorliegende Offenbarung stellt Techniken mit künstlicher Intelligenz (KI) und/oder maschinellem Lernen (ML) zur Mehrfachzugriffsverkehrsverwaltung bereit. Die vorliegende Offenbarung stellt verschiedene Mechanismen bereit, um die Leistungsfähigkeit zu verbessern/zu verbessern und/oder sicherzustellen, während RL für Mehrfachzugriffsverkehrsverwaltung angewendet wird.
Existierende Lösungen beinhalten [AC6833PCT], das modellbasierte Lösungen basierend auf einer Netzwerkhilfsprogrammoptimierung für Mehrfachzugriffsverkehrsverteilung beschreiben. Andere vorherige/existierende Lösungen zur Mehrfachzugriffsverkehrsverwaltung erfordern eine vordefinierte Richtlinie. Zum Beispiel spezifiziert ein TCP-Schicht- oder Anwendungsschicht-Ansatz vorab eine Richtlinie, wie etwa Mehrpfad-TCP (MP-TCP) und Quick UDP (QUIC). Es gibt keine anderen Lösungen, die einen RL-basierten Ansatz für Mehrfachzugriffsverkehrsverteilungsprobleme verwenden, oder Lösungen zum Verhindern einer möglichen Leistungsverschlechterung während der Erkundung, wenn RL für Drahtlosnetzwerkprobleme angewendet wird. Die Leistungsfähigkeit modellbasierter Lösungen hängt stark von der Genauigkeit des Modells selbst ab. Außerdem erfordern solche Lösungen eine genaue und umfangreiche Beobachtung der Umgebung, um eine gute Leistungsfähigkeit zu erreichen. Dies kann in vielen Netzwerkbereitstellungssituationen unpraktikabel sein.
Die vorliegende Offenbarung stellt Mechanismen zur Sicherstellung der Leistungsfähigkeit (Netzwerkleistungsfähigkeit) bereit, während bestärkendes Lernen zur Mehrfachzugriffsverkehrsverwaltung angewendet wird. Insbesondere wird RL und/oder DRL verwendet, um Verkehrsverteilungsstrategien zur Mehrfachzugriffsverkehrsverwaltung zu ermitteln. Die vorliegende Offenbarung bespricht (1) geführte Erkundung, (2) Durchsetzen eines Sicherheitsaktionsraums, (3) Leistungsfähigkeitsüberwachung und (4) opportunistische Erkundungstestflüsse. Datengesteuerte KI/ML-Techniken weisen das Potenzial auf, sich besser an unterschiedliche Funkumgebungen anpassen zu können und die Leistungsfähigkeit zu verbessern. Die Ausführungsformen hierin minimieren das Risiko einer Leistungsverschlechterung während des Online-Lernens, wodurch Netzwerkressourcenverbrauchseffizienzen verbessert werden.
Die hierin erörterten KI/ML-Verkehrsverwaltungstechniken können verwendet werden, um Edge-/Cloud-RAN-Intelligenz zu realisieren, die möglicherweise beispiellose QoS-Verbesserungen und Erweiterungen bieten kann. Spezifische Implementierungen der Ausführungsformen hierin können durch verschiedene Standards und/oder Spezifikationen bereitgestellt werden, wie etwa ETSI, 3GPP, O-RAN Alliance, Open RAN, Open Network Edge Services Software (OpenNESS) und/oder dergleichen. Code/APIs, ein Meldungsformat und eine Meldungsaustauschsignalisierung zwischen Edge-/Cloud-Server und RAN-Knoten können zum Beispiel in derartigen Standards/Spezifikationen spezifiziert werden.
4 stellt ein beispielhaftes Edge-basiertes Mehrfachzugriffsverkehrsverwaltungs-Framework 400 dar. In diesem Beispiel können UEs 401 mit mehreren Funkschnittstellen gleichzeitig mehr als eine Verbindung zu dem Edge-Netzwerk herstellen, einschließlich heterogener Funkzugangstechnologien (RATs) (z. B. LTE, 5G/NR, WiFi usw.) als Last-Hop-Konnektivität. Die UEs 401 können die gleichen wie die zuvor besprochenen UEs 101 und/oder die im Folgenden besprochenen UEs 1111, 1112 sein oder diesen ähnlich sein.
Drastisch zunehmende Nachfrage nach Drahtlosdaten und -vorrichtungen hat zu zunehmenden Anforderungen sowohl an Spitzenraten als auch an Flächenspektraleffizienz geführt. Dies hat wiederum zu einer zunehmend dichteren und heterogenen Bereitstellung von drahtloser Infrastruktur geführt, wobei sich die bereitgestellten Netzwerke in verschiedenen Merkmalen unterscheiden, wie etwa Zugangstechnologie (RAT), Bedeckungsgebiet pro Zugangsnetzwerkknoten, bereitgestelltes Frequenzband und Bandbreite und Backhaul-Fähigkeiten. Infolgedessen befinden sich die meisten der UEs 401 in einem dichten Drahtlosnetz üblicherweise in überlappenden Bedeckungsgebieten mehrerer Zugangsnetzknoten unterschiedlicher RATs. UEs 401 mit der Fähigkeit, Verkehr von mehreren Funkverknüpfungen oder RATs (z. B. 5G, LTE, WLAN, WiMAX, Bluetooth® usw.) zu aggregieren, können Multilink-Aggregation nutzen, um ihren Durchsatz und ihre QoS zu verbessern. Der Anstieg an Bereitstellungen von heterogenen Drahtlosnetzwerken (HetNet) mit gemischten Topologien und unterschiedlichen RATs zusammen mit alltäglichen UEs 401 mit mehreren Funkschnittstellen hat Möglichkeiten eröffnet, den Netzwerkdurchsatz und die Zuverlässigkeit durch Übertragen und Aggregieren von Verkehr von mehreren RATs zu erhöhen.
Edge-Rechentechnologien können Anwendungen mit niedrigen Latenzanforderungen und/oder hohen QoS-Anforderungen (z. B. AR/VR, Cloud-Gaming und dergleichen) unterstützen, indem die verteilten Rechen- und Speicherressourcen in der Nähe von Datenanbietern und Verbrauchern platziert werden. Eine derartige aufkommende Edge-Rechentechnologie ist Mehrfachzugriffs-Edge-Computing (MEC) (siehe z. B. [MEC003]). Ein beispielhaftes Edge-Netzwerk 400 ist in 4 gezeigt und kann der Edge-Cloud 1210 aus 12 und/oder den in 11-24 dargestellten Edge-Rechensystem-Konfigurationen entsprechen.
Das Framework 400 beinhaltet UEs 401, die Rechensysteme/-vorrichtungen innerhalb eines Edge-Rechennetzwerks 400 sind, die Rechenarbeitslasten/-aufgaben an den Edge-Rechenknoten 436 auslagern oder anderweitig Dienste vom Edge-Rechennetzwerk und/oder einem Cloud-System erhalten (siehe z. B. Cloud 1144 von 11). Das Edge-Netzwerk beinhaltet Edge-Rechenknoten 436 (oder Edge-Server 436), der ein oder mehrere Rechensysteme oder Server ist, von denen die Rechenknoten 401 Dienste konsumieren. Der Edge-Server 436 kann gemeinsam mit einem oder mehreren NANs 433a, 433b oder 433c (gemeinsam als „NAN 433“ oder „NANs 433“ bezeichnet), die dieselben wie die vorher besprochenen NANs 130 und/oder die NANs 1131, 1132, 1133 von 11 oder diesen ähnlich sein können. Jeweilige Verbindungen 415 können den Edge-Rechenknoten 436 mit einem oder mehreren NANs 433 verbinden oder kommunikativ koppeln. Des Weiteren können die Rechenknoten 401 Dienste von einem Cloud-System über lizenzierten Zugang oder unlizenzierten Zugang über ein Kernnetzwerk (einschließlich Kernnetzwerk(CN)-Server(n)) erhalten. Der lizenzierte Zugang wird durch eine Reihe von Verbindungen/Verknüpfungen repräsentiert, die jeweilige Pfade bilden, und der unlizenzierte Zugang wird durch eine Reihe von Verbindungen/Verknüpfungen repräsentiert, die jeweilige Pfade bilden). Einige Kanäle/Verbindungen können entweder für lizenzierten oder für unlizenzierten Zugang verwendet werden.
Der Edge-Rechenknoten 436 ist ein oder mehrere physische Computersysteme, die eine Edge-Plattform und/oder Virtualisierungsinfrastruktur beinhalten können und Rechen-, Speicherungs- und Netzwerkressourcen für Edge-Rechenanwendungen bereitstellen. Der Edge-Server 436 ist an einem Rand eines entsprechenden Zugangsnetzwerks (z. B. von individuellen NANs 433 bereitgestellten Netzwerken) angeordnet und stellt Rechenressourcen und/oder verschiedene Dienste (z. B. Rechenaufgaben- und/oder Arbeitslastauslagerung, Cloud-Rechenfähigkeiten, IT-Dienste und andere ähnliche Ressourcen und/oder Dienste, wie hierin erörtert) in relativ enger Nähe zu Netzwerkteilnehmern (z. B. Rechenknoten 401, die auch als „UEs“, „Edge-Benutzer“ und/oder dergleichen bezeichnet werden) bereit. Die Virtualisierungsinfrastruktur (VI) der Edge-Server 436 stellt virtualisierte Umgebungen und virtualisierte Ressourcen für die Edge-Hosts (z. B. die Edge-Server 436) bereit, und die Edge-Rechenanwendungen können als VMs und/oder Anwendungscontainer auf der VI laufen. Der Edge-Rechenknoten 436 kann dem Edge-Rechenknoten 1136 von 11 innerhalb des Edge-Systems/Netzwerks 1135 von 11 entsprechen.
Eine beispielhafte Implementierung des Edge-Systems/Netzwerks 400 ist ein Mehrfachzugriffs-Edge-Rechen(MEC)-System/-Framework, wobei der Edge-Server 436 als ein MEC-Host gemäß den MEC-Architekturen implementiert ist (siehe z. B. 18-19, die nachstehend erörtert werden, und/oder 25 bis 41 der vorläufigen US-Anmeldung. Nr. 63/003,834 , eingereicht am 1. April 2020 („[AC6833Z]“), deren Inhalt hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen ist). MEC ist eine Netzwerkarchitektur, die Cloud-Rechenfähigkeiten und Rechendienste ermöglicht, am Rand eines Mobilfunknetzes durchgeführt zu werden, einschließlich Auslagern von Anwendungsberechnung. MEC stellt Mechanismen bereit, die ermöglichen, dass Anwendungen ausgeführt werden und verwandte Verarbeitungsaufgaben näher an Netzwerkteilnehmern (auch als „Edge-Benutzer“, „Edge-Rechenknoten“, „Edge-Knoten“ oder dergleichen bezeichnet) durchgeführt werden. Der eine oder die mehreren MEC-Hosts führen Rechendienste (z. B. „Edge-Dienste“ und/oder „Mikrodienste“) aus. Auf diese Weise kann eine Netzwerküberlastung reduziert werden und Anwendungen können eine bessere Leistungsfähigkeit aufweisen. Die MEC-Technologie ist dazu ausgelegt, an den Mobilfunkbasisstationen implementiert zu werden, und kann einen flexiblen und schnellen Einsatz neuer Anwendungen und Dienste für Teilnehmer ermöglichen. Das Kombinieren von Elementen von Informationstechnologie und Telekommunikationsnetzwerk, MEC, ermöglicht es Mobilfunkbetreibern auch, ihre RANs autorisierten Dritten, wie Anwendungsentwicklern und Inhaltsanbietern, zu öffnen. Andere Edge-Netzwerkimplementierungen können bei anderen Ausführungsformen verwendet werden.
Wenn ein Rechenknoten 401 mehrere Funkschnittstellen (oder mehrere Kommunikationschips/-schaltungsanordnungen) aufweist, kann der Rechenknoten 401 Daten über mehrere Pfade übertragen und/oder empfangen. Dies bedeutet, dass es unterschiedliche Mehrfachfunk- oder Mehrwege-Konvergenzpunkte geben kann, um Verkehr zwischen einer oder mehreren e2e-Kommunikationsverknüpfungen zu aggregieren und/oder zu verteilen. Gemäß verschiedenen Ausführungsformen kann, wenn ein Rechenknoten 401 mehrere Funkschnittstellen aufweist, ein neuer Mehrfachfunkkonvergenzpunkt am Rand des Netzwerks auftreten, um Mehrwegeverkehrsmanagement für Kommunikation mit niedriger Latenz anzubieten, wie für 3GPP-5G/NR-Netzwerke vorgesehen ist (siehe z. B. 23 bis 41 von [AC6833Z]). Mit neuer Intelligenz, die durch Edge-Computing ermöglicht wird, können Multi-RAT-Bereitstellungen effizienter genutzt werden, indem Verkehr basierend auf Edge-Messungen geschickter auf mehrere Netzwerkpfade verteilt wird.
Bei manchen Implementierungen können der Edge-Rechenknoten 436 und die UEs 401 eine geeignete Konvergenztechnologie (z. B. Zhu et al., „Generic Multi-Access (GMA) Convergence Encapsulation Protocols“, IETF INTAREA/Network Working Group, Version 7 (17. Mai 2020) („[GMA]“)) auf Datenebene nutzen, um Verkehr über mehrere Pfade zu verteilen und zu aggregieren. Ein anderes Beispiel ist, dass die UEs 401 Doppelkonnektivität herstellen können, wie in 3GPP spezifiziert, und sich die Edge-Intelligenz in einer CU befindet (siehe z. B. 3GPP TS 37.340 v 16.4.0 (2021-01-06) („[TS37340]“)).
Rechenleistung, die von dem Edge-Rechenknoten 436 angeboten wird, kann genutzt werden, um intelligente Mehrfachzugriffsverkehrsverwaltung zu realisieren. Ein intelligenter Mehrfachzugriffsverkehrsmanager 446, der sich an der Edge 436 befindet, berechnet Verkehrsverteilungsregeln (z. B. Verkehrsverwaltungskonfigurationen 413 in 4) auf Steuerebene 412, die der Datenebene 414 und den UEs 401 bereitgestellt werden, um die Datenebene 414 und die UEs 401 darüber zu informieren, wie Pakete über die mehreren Pfade zu leiten sind. Die Verkehrsverteilungssteuerebene 412 sammelt Rückmeldungen von drahtloser Infrastruktur (z. B RAN-Messungen von einem oder mehr NANs 433) und/oder direkt von Benutzern (z. B. UE-Messungen von einem oder mehreren UEs 401), berücksichtigt Datenfluss-/App-/QoS-Anforderungen 425, die von einer oder mehreren höheren Schichten bereitgestellt werden, und sammelt Telemetriestatistiken 415 von der Datenebene 414, um zu ermitteln, wie Datenflüsse über die mehreren Pfade geleitet werden sollen, um heterogene QoS-Ziele zu erfüllen. Zusätzlich oder alternativ sammelt die Verkehrsverteilungssteuerebene 412 Leistungsfähigkeitsindikatoren von einer oder mehreren Netzwerkfunktionen (NFs) in einem Kernnetz (z. B. CN 1142 oder dergleichen). Edge-Daten 424 und Datennetzwerkdaten 427 werden der Datenebene 414 bereitgestellt, durch einen Paketfilter 418 gefiltert und in eine oder mehrere QoS(Datenfluss)-Warteschlangen 410 sortiert. Eine Netzwerkcodierungs-Engine 417 kann auch verwendet werden, um Daten von den Datenflüssen (Warteschlangen 410) über die Mehrfachpfade zu leiten.
In einer beispielhaften Implementierung kann der intelligente Verkehrsverteiler 446 Teil eines Mehrfachzugriffsmanagementdienst(MAMS)-Servers sein (siehe z. B. Kanugovi et al., „Multi-Access Management Services (MAMS)“, Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (März 2020) („[RFC8743]“)). Bei einer anderen beispielhaften Implementierung kann der intelligente Verkehrsverteiler 446 Teil einer CU einer CU/DU-Aufteilungsarchitektur eines Mobilfunk-RAN sein, das Doppelkonnektivität handhabt.
In einem O-RAN-Framework (siehe z. B. 20-24, die nachstehend erörtert werden) kann die Verkehrsverteilungssteuerebene, die Verkehrsverteilungsregeln berechnet, Teil der intelligenten RAN-Steuerung (RIC) sein. Aufkommende datengesteuerte Maschinenlerntechniken (ML-Techniken) können verwendet werden, um fortschrittliche Mehrfachzugriffsverkehrsverteilungsstrategien zu entwickeln, wie etwa jene, die zuvor in Abschnitt 1 erörtert wurden und/oder in [AD2644-Z] erörtert wurden.
1a und 1b zeigen eine beispielhafte Architektur 100 eines modellfreien Frameworks für tiefgehendes bestärkendes Lernen für ein Mehrfachzugriffsverkehrsverwaltungs-Framework (DRL-MTM-Framework). In 1a und 1b befindet sich der Agent des DRL-MTM an einem Edge-Rechenknoten 436, wie etwa einem MEC-Server/Host, einer intelligenten RAN-Steuerung (RIC), wie in O-RAN Alliance definiert, und/oder einem anderen Edge-Rechenknoten, wie etwa jenen hierin erörterten. Die Umgebung 100x, mit der der Agent 140 interagieren wird, ist ein Mehrfachzugriffsnetz, in dem UEs 101 (oder UEs 401) mit mehreren Funkschnittstellen in der Lage sind, sich mit mehreren RANs 130 (oder RANs 433) zu verbinden, von denen eines oder mehrere unterschiedliche Funkzugangstechnologien (RATs) nutzt. Unter Bezugnahme auf 1b ist der Agent 140 dafür verantwortlich, die Verkehrslenkungs-/Aufteilungsstrategie für jedes der Mehrfachzugriffs-UEs 101 (oder UEs 401) basierend auf der einen oder den mehreren Beobachtungen, die von der Umgebung 100x gesammelt werden, zu entscheiden. Nach dem Durchführen der Verkehrslenkungs-/-aufteilungsstrategie, die von dem Agenten 140 empfohlen wird, kann eine neue Beobachtung von der Umgebung 100x gesammelt werden und eine Belohnung r kann in Übereinstimmung mit einer konstruierten Belohnungsfunktion berechnet werden, wie hierin besprochen.
Online-RL erfordert eine Erkundung mit realen Mobilfunknetzen, was zum Beispiel basierend auf Verbindungsunterbrechungen und -ausfällen das Risiko bieten kann, Dienstgütevereinbarungen (SLAs) nicht zu erfüllen und/oder das Benutzererlebnis (UX) zu verschlechtern. Die vorliegende Offenbarung stellt die folgenden Strategien bereit, um das Risiko einer Leistungsverschlechterung während der Online-Trainingsphase in RL zur Mehrfachzugriffsverkehrsverwaltung zu minimieren: geführte Erkundung; Durchsetzung eines Sicherheitsaktionsraums; Leistungsfähigkeitsüberwachung (Modellüberwachung); und opportunistische Erkundungstestflüsse.
5 veranschaulicht ein beispielhaftes Framework 500 zum Bereitstellen der Leistungsfähigkeitszusicherungsmechanismen für RL. Das Framework 500 beinhaltet eine Umgebung (z. B. Umgebung 100x), die dem Echtzeitagenten 501 einen Zustand s bereitstellt. Der Echtzeitagent 501 beinhaltet einen geführten Erkundungsmechanismus (GE) 502, ein neuronales Netz (NN) 503, einen Ausnutzung-versus-Erkundungs-Mechanismus (EvE) 504, einen opportunistischen Erkundungssteuermechanismus (OEC) 505, einen Mechanismus zur Erzwingung des Sicherheitsaktionsraums (ESAS) 506 und einen Frühwarnmechanismus (EW) 507.
Der Echtzeitagent 501 ermittelt eine Aktion a durch Anwenden des Zustands s auf eine Richtlinie π (z. B. a = π(s), wobei „π(s)“ eine Aktion ist, die im Zustand s unter einer deterministischen Richtlinie π vorgenommen wurde). Der Zustand s wird dem GE 502 bereitgestellt, der eine Erkundungsaktion („a_erkundung“) auf Grundlage des Zustands s und zusätzliche Informationen ausgibt, und die a_erkundung dem EvE 504 zuführt. Der GE 502 kann einen oder mehrere geeignete Erkundungsalgorithmen einsetzen, wie etwa zum Beispiel zufällige Erkundung (z. B. epsilon-greedy, Softmax-Funktion usw.), kuriositätsbasierte Erkundung, obere Konfidenzgrenzen (UCB), Boltzmann-Erkundung, Thompson-Abtastung, Entropieverlustterm, rauschbasierte Erkundung, Erkundung mit intrinsischer Belohnung (Bonus) (z. B. zählerbasierte Erkundung, vorhersagebasierte Erkundung usw.), Erkundung mit Optimismus angesichts von Unsicherheit, Hoeffding-Ungleichung, Zustand-Aktion-Erkundung, Parametererkundung, speicherbasierte Erkundung (z. B. episodische Speichererkundung, Direkterkundung usw.), Q-Wert-Erkundung und/oder dergleichen. Zusätzliche oder alternative Aspekte des GE 502 sind unten in Abschnitt 2.1 besprochen. Der Zustand s wird auch dem NN 503 bereitgestellt, um eine neueste Agentenaktualisierung aus dem Training (z. B. a = π_k(s) zu erhalten), die auch eine Erkundungsaktion („a_erkundung“) ausgibt, die dem EvE 504 bereitgestellt wird.
Der EvE 504 ermittelt eine geeignete Strategie durch Ausgleichen von Ausnutzungsoptionen und Erkundungsoptionen basierend auf den a_erkundungen, die er erhält. Ausnutzung beinhaltet das Treffen der besten (optimalen) Entscheidung angesichts der aktuell verfügbaren Informationen, wohingegen Erkundung das Sammeln von Informationen über unbekannte Optionen beinhaltet, selbst wenn Risiken mit dem Sammeln dieser Informationen verbunden sind. Hier kann die beste (optimale) Langzeitstrategie kurzfristige Opfer (hinsichtlich der Menge der zu erzielenden Belohnung) involvieren. Denn die ergriffenen Aktionen beeinflussen die neuen Beobachtungen, die in einer nächsten Iteration erhalten werden. Für die Analyse Ausnutzung-v-Erkundung kann die EvE 504 einen mehrarmigen Banditenalgorithmus implementieren, wie etwa die Techniken, die in „Adaptive Exploration-Exploitation Tradeoff for Opportunistic Bandits“, Proceedings of the 35th International Conference on Machine Learning (ICMI, 2018), S. 5306-5314, Stockholmsmässan, Stockholm, Schweden, (30. Nov. 2018) erörtert sind. Zusätzliche oder alternative Aspekte des EvE 504 sind unten in Abschnitt 2.2 besprochen.
Der OEC 505 stellt dem EvE 504 Konfigurationen und/oder Steuerelemente (basierend auf zusätzlichen Informationen) bereit, und der EvE 504 analysiert die a_erkundungen basierend auf den Konfigurationen und/oder Steuerelementen. Zum Beispiel kann der OEC 505 den Aktionsraum (oder die Menge potenzieller Aktionen) basierend auf den externen Informationen verfeinern. Zusätzliche oder alternative Aspekte des OEC 505 sind unten in Abschnitt 2.4 besprochen. Die analysierten a_erkundungen werden dem ESAS 506 bereitgestellt, der die Aktion a erzeugt, die zurück an die Umgebung bereitgestellt wird. Der ESAS 506 führt eine Sicherheitsprüfung durch, bevor irgendeine Aktualisierung an Systemkonfigurationen bereitgestellt wird (z. B. bevor eine ausgewählte Aktion an ein oder mehrere UEs 401 bereitgestellt wird). Der ESAS 506 kann in Form eines akzeptablen Bereichs von Aktionen oder eines Satzes von Bedingungen vorliegen, die durch lineare oder nichtlineare Funktionen der Aktionen beschrieben sind.
Zusätzlich erhält der EW 507 den Zustand s und die Belohnung r (falls vorhanden) und stellt einen Hinweis 570 an den Sicherungsmodellspeicher 510 bereit, falls Leistungsfähigkeitsmessungen angeben, dass die eine oder die mehreren Aktionen a zu suboptimalen Leistungsfähigkeitsergebnissen tendieren. Als Reaktion auf den Hinweis 570 wird ein Sicherungsmodell 511 ausgewählt und dem Echtzeitagenten 501 bereitgestellt, um ein aktuell implementiertes Modell (z. B. NN 503) zu ersetzen. Zusätzliche oder alternative Aspekte des EW 507 sind unten in Abschnitt 2.3 besprochen.
Zusätzlich können ein aktueller Zustand s_i, eine aktuelle Aktion a_i, eine aktuelle Belohnung r_i und ein nächster Zustand s_i+1 in einem Erfahrungswiedergabepuffer 530 gespeichert werden. Der Wiedergabepuffer 530 ist ein Puffer vergangener Erfahrungen, der verwendet wird, um das Training zu stabilisieren, indem die Trainingsbeispiele in jedem Batch, der zum Aktualisieren des NN 503 verwendet wird, dekorreliert werden. Der Wiedergabepuffer 530 zeichnet vergangene s_i, die an diesen Zuständen s_i vorgenommenen Aktionen a_i, die aus diesen Aktionen a_i erhaltene Belohnung r_i und den nächsten Zustand s_i+1 auf, der beobachtet wurde. Der Wiedergabepuffer 530 speichert diese Daten als eine Sammlung von Erfahrungstupeln (s_i, a_i, r_i, s_i+1). Die Tupel werden allmählich zum Wiedergabepuffer 530 hinzugefügt, wenn der Agent 501 mit der Umgebung 100x interagiert. Darüber hinaus könnte der Wiedergabepuffer 530 zusätzlich zu den Erfahrungstupeln auch ein Ziel speichern. Eine Implementierung ist ein Wiedergabepuffer 530 fester Größe, wobei neue Daten zum Ende des Wiedergabepuffers 530 hinzugefügt werden, sodass sie die älteste Erfahrung herausschieben. Andere Puffer-/Warteschlangenimplementierungen können ebenfalls verwendet werden, einschließlich Zwischenspeichersystemen und dergleichen. Der Wiedergabepuffer 530 (oder die darin gespeicherten Daten) kann verwendet werden, um zu verhindern, dass Aktionswerte katastrophal oszillieren oder divergieren, indem vergangene Erfahrungen gepuffert und (Trainings-)Daten 531 aus dem Wiedergabepuffer 530 abgetastet werden, anstatt die neueste Erfahrung zu verwenden. Der Vorgang des Abtastens eines kleinen Batchs von Tupeln 531 aus dem Wiedergabepuffer 530 zum Lernen ist als Erfahrungswiedergabe bekannt. Zusätzlich zum Zerschlagen schädlicher Korrelationen ermöglicht die Erfahrungswiedergabe ein mehrmaliges Lernen aus einzelnen Tupeln, ein Abrufen seltener Vorkommnisse und im Allgemeinen eine bessere Nutzung der Erfahrung. Hier werden die (Trainings-)Datenproben 531 dem Agenten 501 für eine nächste Epoche oder Episode (z. B. Agent π_k+1) bereitgestellt, die dann zum Aktualisieren des Agenten 501 verwendet werden.
Bei O-RAN-Framework-Implementierungen (siehe z. B. 20-24) ist der Echtzeitagent bei der Nahezu-Echtzeit(RT)-RIC angeordnet. Modelltraining ist an einer Nicht-RT-RIC für Offline-RL oder an einer Nahezu-RT-RIC für Online-RL angeordnet. Der Echtzeitagent kann als eine einzelne xApp implementiert werden, die ein RL-Inferenzmodell mit den vier zuvor erwähnten Leistungsfähigkeitssicherungsmechanismen integriert. Alternativ dazu kann der Echtzeitagent als mehrere xApps implementiert sein, wobei die vier Leistungsfähigkeitssicherungsmechanismen über xApp-APIs miteinander und mit dem RL-Inferenzmodell kommunizieren.
2.1. GELENKTE ERKUNDUNG
RL verwendet eine Strategie mit systematischem Ausprobieren, um eine Richtlinie zu erlernen, um auf beobachtete Systemzustände zu reagieren. Durch Interagieren mit der Umgebung und Beobachten des Ergebnisses vergangener Aktionen passt der RL-Agent 501 seine Richtlinie π an, sodass die erwartete langfristige Belohnung maximiert wird. Der RL-Agent 501 kann jedoch nicht gut auf Situationen reagieren, die er zuvor nicht erfahren hat. Um so viele Situationen wie möglich zu testen, darf der RL-Agent 501 üblicherweise gelegentlich Erkundungsaktionen vornehmen, die sich von der optimalen Richtlinie unterscheiden, die durch RL erzeugt wird. Das Risiko besteht darin, dass eine schlechte Erkundungsaktion zu katastrophaler Leistungsverschlechterung führen kann. Im Anwendungsfall mit Mehrfachzugriffsverkehrsverwaltung kann zum Beispiel eine schlechte Erkundungsaktion zu einer Überlastung einer Zugangsverknüpfung führen, die bewirkt, dass eine lange Warteschlange (z. B. Warteschlange 410 in 4) Daten akkumuliert, und die Latenzleistung für einen langen Zeitraum verschlechtern.
Gemäß verschiedenen Ausführungsformen werden, anstatt zufällig eine Aktion zu ermitteln, die Erkundungsaktionen (a Erkundung) für RL mit etwas Lenkung ausgewählt. Für die Mehrfachzugriffsverkehrsverwaltung können die Erkundungsaktionen für RL unter Verwendung bestehender Nicht-ML-Algorithmen oder unter Verwendung vortrainierter ML-Algorithmen ausgewählt werden.
Die bestehenden Nicht-ML-Algorithmen, wie etwa regelbasierte oder modellbasierte heuristische Algorithmen, dienen zum Erzeugen eines vorgeschlagenen Satzes von Aktionen, die zur Erkundung auszuwählen sind (z. B. die Ausgabe von GE 502). Beispielsweise können Verkehrsverteilungsregeln, die durch Lösungen bestimmt werden, die in [AC6833PCT] und/oder [AC6833Z] entwickelt wurden, als die gelenkten Erkundungsaktionen verwendet werden.
Die vortrainierten ML-Algorithmen dienen zum Erzeugen eines vorgeschlagenen Satzes von Aktionen, die zur Erkundung ausgewählt werden sollen, wie etwa eines oder mehrere der zuvor erörterten Erkundungsalgorithmen. Die vortrainierten ML-Algorithmen können basierend auf Daten trainiert werden, die von unterschiedlichen Netzwerkumgebungen gesammelt wurden. Die vortrainierten ML-Algorithmen können auch ein Aktionsvorhersagemodell sein, das durch überwachtes Lernen trainiert wurde.
Die Nicht-ML-Algorithmen und/oder die vortrainierten ML-Algorithmen können als separate Mikrodienste (z. B. xApp(s) in O-RAN) implementiert sein und der RL-Agent 501 kann diese Dienste abonnieren, um empfohlene Verkehrsverteilungsaktionen zu erhalten. Die empfohlenen Verkehrsverteilungsaktionen können über eine API gemeinsam genutzt werden. Zusätzlich oder alternativ dazu kann der RL-Agent 501 zusätzliche Zufälligkeit zu den gelenkten Aktionen zur Erkundung hinzufügen. Zum Beispiel kann eine kleine zufällige Variation zu der gelenkten Aktion hinzugefügt werden, die von Nicht-ML- oder ML-Algorithmen empfohlen wird.
2.2. DURCHSETZEN DES SICHERHEITSAKTIONSRAUMS
Wie zuvor erwähnt, kann eine schlechte Aktion zu katastrophaler Leistungsverschlechterung führen. Für RL kann eine schlechte Aktion zum Zweck der Erkundung ergriffen werden oder weil der RL-Algorithmus nicht zu einer hinreichend guten Lösung konvergiert ist. Um das Risiko eines signifikanten Leistungsfähigkeitsverlusts zu vermeiden, sollten zusätzliche Schutzmaßnahmen ergriffen werden, während eine durch den RL-Algorithmus ermittelte Aktion durchgeführt wird. Insbesondere sollte jede durchzuführende Aktion eine Sicherheitsprüfung bestehen (z. B. ESAS 506), bevor irgendeine Aktualisierung der Systemkonfiguration durchgeführt wird. Für eine Mehrfachzugriffsverkehrsverwaltung kann ein Sicherheitsaktionsraum (z. B. ESAS 506) konstruiert werden, wobei der Aktionsraum die Kriterien definiert, die die durch den RL-Algorithmus erzeugten Verkehrsverteilungsregeln erfüllen müssen. Das Sicherheitsaktionsraumkriterium kann eines oder mehrere der folgenden Formate umfassen:
Akzeptabler Aktionsbereich: Für eine Mehrfachzugriffsverkehrsverwaltung kann ein akzeptabler Aktionsbereich der Bereich des Verkehrsverteilungsverhältnisses eines Datenflusses über eine individuelle Strecke sein. Das Verhältnis von Verkehr, der zu Fluss i gehört und über Pfad r geleitet werden soll, wird mit x_i,r bezeichnet. Eine beispielhafte Sicherheitsgrenze kann eine untere Schranke und eine obere Schranke für x_i,r (z. B. x_LB ≤ x_i,r ≤ x_UB) spezifizieren. Der Sicherheitsbereich kann auf einer gelenkten Aktion basieren, die durch Nicht-ML- und/oder andere ML-Algorithmen, wie zuvor beschrieben, erzeugt wird. Zum Beispiel angenommen, die gelenkte Aktion zum Leiten von Fluss i über Pfad r ist $x_{i, r}^{(g)}$
Der Sicherheitsbereich kann $x_{i, r}^{(g)} - δ \leq x_{i, r} \leq x_{i, r}^{(g)} + δ$
sein, wobei δ ein vorbestimmter oder konfigurierter Sicherheitsspielraum ist.
Ein Satz von Bedingungen, die durch lineare oder nichtlineare Funktionen der Aktionen beschrieben sind: Für Mehrfachzugriffsverkehrsverwaltung können erwartete QoS-Metriken über einige mathematischen Modelle abgeschätzt werden. Diese Modelle können verwendet werden, um abzuschätzen, ob die durch RL erzeugte Aktion QoS-Ziele für den Datenfluss erfüllen kann. Beispielhafte Bedingungsfunktionen beinhalten: einen erwarteter Gesamtfunkressourcennutzungspegel, der unter einem gewissen Schwellenwert liegt; einen erwarteten Gesamtfunkressourcennutzungspegel für einen Satz von Flüssen mit gewissen QoS-Pegel, der unter einem Schwellenwert liegt; und/oder einen erwarteten Datenflussdurchsatz, der über einem gewissen Schwellenwert liegt.
Die Sicherheitsbedingungen können über eine A1-Richtlinie von Nicht-Echtzeit-RIC bereitgestellt werden oder durch eine andere xApp über eine xApp-API bereitgestellt werden. Zusätzlich oder alternativ dazu kann Aktionssicherheit durch ein Nahezu-RT-RIC-Plattformmanagementmodul oder durch eine andere xApp (z. B. ESAS 506) durchgesetzt werden. Beispielsweise wird im Framework 500 von 5 eine Aktion a, die vom RL-Agenten 501 erzeugt wurde, an den ESAS 506 gesendet, und der ESAS 506 ermittelt, ob er die empfohlene Aktion a vom RL-Agenten 501 akzeptiert und durchführt. Der ESAS 506 kann als eine xApp oder irgendein anderer Typ von Edge-Anwendung implementiert sein. Zusätzlich oder alternativ kann die Sicherheitsprüfung in den RL-Agenten 501 integriert sein.
2.3. LEISTUNGSFÄHIGKEITS- UND/ODER MODELLÜBERWACHUNG
Die zeitlich variierende Natur der Drahtlosumgebung und der Benutzerverkehrsdynamik macht die Sicherstellung, dass das vorbestimmte Sicherheitsprüfkriterium immer genau ist, zu einer Herausforderung. Daher erfordert es einen zusätzlichen Leistungsfähigkeitsüberwachungsmechanismus, um eine katastrophale Leistungsfähigkeitsverschlechterung durch minderwertige Aktionen, die durch den RL-Agenten erzeugt werden, zu vermeiden.
Hier wird ein Frühwarnmechanismus (z. B. EW 507) zusammen mit Online-RL implementiert, um zu erkennen, ob das durch RL erzeugte Modell zu suboptimalen Lösungen driftet. Zusätzlich zu herkömmlichen KI/ML-Modellüberwachungsmetriken können Leistungsfähigkeitsmessungen, die Drahtlosnetzwerkbedingungen widerspiegeln, einen aufschlussreicheren Hinweis auf die Modelleffektivität bereitstellen. Für die Mehrfachzugriffsverkehrsverwaltung können die folgenden Metriken verwendet werden, um die Leistungsfähigkeit des durch RL erzeugten KI/ML-Modells zu überwachen, um eine Frühwarnung auszulösen: Mittelwert einer Einweg- oder e2e-Verzögerung für einen oder mehrere Datenströme; Verzögerungsvariationstrends; Puffer-Akkumulation (z. B. in der Warteschlange 410); Trends in CQI-Schwankungen; MCS-Verteilungstrends; und/oder dergleichen. Eine Schwelle, die mit einer der Leistungsfähigkeitsmetriken verknüpft ist, kann dem EW 507 über eine KI-Richtlinie von Nicht-RT-RIC oder über eine xApp-API von einem Nahezu-RT-RIC-Verwaltungsmodul oder einer anderen xApp bereitgestellt werden.
Der RL-Trainingsagent 501 bewahrt als Sicherung mindestens eine Kopie mindestens eines zuvor trainierten KI/ML-Modells auf, das eine angemessene gute Leistungsfähigkeit bereitgestellt hat, (z. B. Sicherungsmodelle 511 im Modellspeicher 510). Zusätzlich oder alternativ kann der RL-Trainingsagent 501 die letzten K Versionen eines oder mehrerer KI/ML-Modelle aufbewahren, die während des Online-Trainings erzeugt werden. Sobald die Metriken zur Leistungsfähigkeitsüberwachung eine entsprechende Schwelle verletzen (oder überschreiten), kann der RL-Trainingsagent 501 das aktuelle Modell 503 durch eines der vergangenen trainierten (Sicherungs-)KI/ML-Modelle 511 ersetzen, die eine zufriedenstellende Leistungsfähigkeitsgarantie bereitstellen, und das Online-RL von diesem Modell 511 neu starten.
2.4. OPPORTUNISTISCHE ERKUNDUNGSTESTFLÜSSE
Obwohl das Anwenden der geführten Erkundung 502 und das Durchsetzen des Sicherheitsaktionsraums 506 verhindern können, dass der RL-Agent 501 Aktionen a ausgibt, bei denen wahrscheinlich ist, dass sie eine schlechte Leistungsfähigkeit verursachen, kann die Einschränkung des Aktionsraums zu einem Datenmangel bei der Abdeckung aller möglichen statistischen Szenarien führen und könnte zu suboptimalen RL-Lösungen führen. Dementsprechend wird ein opportunistischer Erkundungsmechanismus 505 verwendet, um risikoreichere Aktionen zu testen, wenn kein Risiko besteht, UEs 101 und/oder Flüsse zu schädigen, die gegenüber der/den Ziel-QoS-Metrik(en) empfindlich sind.
Bei manchen Implementierungen wendet der OEC 505 nur risikoreichere Aktionen auf (1) Testflüsse und/oder (2) Datenflüsse mit weniger strengen QoS-Zielen an. Zusätzlich oder alternativ führt der OEC 505, um zu vermeiden, dass die Leistungsfähigkeit anderer Flüsse mit hohen QoS-Anforderungen geschädigt wird, solche Erkundungsaktionen durch, wenn (1) eine Leistungsfähigkeitszusicherung vorhanden ist, um die QoS für hohe QoS-Flüsse zu gewährleisten, und/oder (2) es keine andauernde Übertragung von hohen QoS-Datenflüssen gibt.
3. TIEFGEHENDES VERSTÄRKENDES LERNEN MIT KONTEXTBEZOGENEN BANDITEN IN MEHRFACHZUGRIFFSVERKEHRSVERWALTUNGSDIENSTEN
Das Aufkommen von Edge-Computing ermöglicht einen neuen Konvergenzpunkt für unterschiedliche drahtlose Zugangstechnologien. Da sich das Edge-Netzwerk näher an das Funkzugangsnetz (RAN) bewegen wird, um die Verzögerungsanforderung neuer Anwendungen zu erfüllen, können intelligente Mehrfachzugriffsverkehrsverwaltungsstrategien an oder durch Edge-Rechenknoten entwickelt werden (z. B. Mehrfachzugriffsrechenserver/- Hosts (MEC-Server/Hosts), um die unterschiedlichen UE-Dienstgüte(QoS)-Anforderungen zu erfüllen, wie in 1a gezeigt, wobei viele UEs 101 mehrere Funkschnittstellen aufweisen können und auf mehrere RANs und/oder RAT-Typen (z. B. LTE, 5G/NR, WiFi, WiMAX, Bluetooth®, DSL usw.) zugreifen können. Die vorliegende Offenbarung stellt Techniken mit künstlicher Intelligenz (KI) und/oder maschinellem Lernen (ML) zur Mehrfachzugriffsverkehrsverwaltung bereit. Insbesondere beinhalten Ausführungsformen hierin tiefgehendes RL mit kontextbezogenen Banditen zur intelligenten Verkehrsverwaltung für Edge-Netzwerke.
Vorherige/existierende Lösungen beinhalten [AC6833PCT], das modellbasierte Lösungen basierend auf einer Netzwerkhilfsprogrammoptimierung für Mehrfachzugriffsverkehrsverteilung beschreiben. Andere vorherige/existierende Lösungen zur Mehrfachzugriffsverkehrsverwaltung erfordern eine vordefinierte Richtlinie. Zum Beispiel spezifiziert ein TCP-Schicht- oder Anwendungsschicht-Ansatz vorab eine Richtlinie, wie etwa Mehrpfad-TCP (MP-TCP) und Quick UDP (QUIC). Die vorherigen/existierenden Lösungen beruhen jedoch auf einem mathematischen Modell oder vordefinierten Steuerrichtlinien. Die Leistungsfähigkeit modellbasierter Lösungen hängt stark von der Genauigkeit des Modells selbst ab. Außerdem erfordern solche Lösungen eine genaue und umfangreiche Beobachtung der Umgebung, um eine gute Leistungsfähigkeit zu erreichen. Dies kann in vielen Netzwerkbereitstellungssituationen unpraktikabel sein.
Die Ausführungsformen hierin nutzen eine neue Entwicklung bei KI/ML, um einen modellfreien Ansatz zu entwickeln, um die beste/optimale Strategie zur Verkehrsverwaltung einfach durch Interagieren mit der Umgebung und Sammeln von Laufzeitstatistiken zu lernen, ohne auf Optimierungsmodelle oder vordefinierte Richtlinien angewiesen zu sein. In Abschnitt 1 und [AD2644-Z] wird RL zur Verkehrsverwaltung durch Modellieren der drahtlosen Multi-RAT-Netzwerkinteraktion als Markov-Entscheidungsprozess erreicht.
Im Folgenden wird eine tiefgehende RL-Architektur mit kontextbezogenen Banditen für Mehrfachzugriffsverkehrsverwaltung besprochen. Bei manchen Implementierungen umfasst die tiefgehende RL-Architektur mit kontextbezogenen Banditen drei Komponenten, einschließlich: (1) Repräsentationslemen, wobei latente Merkmale aus Rohkontexten (z. B. Beobachtung von einer Drahtlosumgebung 100x und/oder anderen Kontextinformationen) extrahiert werden; (2) DRL, wobei ein Agent eine Richtlinie basierend auf einer Belohnung ableitet und aus dem Repräsentationslernen ausgibt; und (3) Design von Zuständen, Aktionen und Belohnungen für die Ausführungsformen des intelligenten Verkehrsmanagements. Bei manchen Implementierungen involviert die tiefgehende RL-Architektur mit kontextbezogenen Banditen einen oder mehrere Edge-Rechenknoten (z. B. Edge-Rechenknoten 140 aus 1, Edge-Rechenknoten 1136 aus 11 usw.), die einen oder mehrere der oben genannten Aspekte der tiefgehenden RL-Architektur mit kontextbezogenen Banditen implementieren. Ausführungsformen beinhalten auch e2e-Training und Inferenz. Die hierin erörterten KI/ML-Verkehrsverwaltungsimplementierungen, einschließlich der tiefgehenden RL-Architektur mit kontextbezogenen Banditen, können verwendet werden, um Edge-/Cloud-RAN-Intelligenz zu realisieren, die möglicherweise beispiellose QoS-Verbesserungen/-Erweiterungen bieten kann.
Die hierin erörterten KI/ML-Verkehrsverwaltungstechniken können eine Komponente zum Realisieren von Edge-/Cloud-RAN-Intelligenz sein, die möglicherweise beispiellose QoS-Verbesserungen und Erweiterungen bieten kann. Spezifische Implementierungen der Ausführungsformen hierin können durch verschiedene Standards und/oder Spezifikationen bereitgestellt werden, wie etwa ETSI, 3GPP, O-RAN Alliance, Open RAN, Open Network Edge Services Software (OpenNESS) (siehe z. B. https://www.openness.org/) und/oder dergleichen. Code/APIs, ein Meldungsformat und eine Meldungsaustauschsignalisierung zwischen Edge-/Cloud-Server und RAN-Knoten können zum Beispiel in derartigen Standards/Spezifikationen spezifiziert werden.
6 stellt eine beispielhafte intelligente Mehrfachzugriffsverkehrsverwaltungsarchitektur 600 dar. Bei verschiedenen Ausführungsformen befindet sich der intelligente Verkehrsverwaltungsagent 640 an einem Edge-Rechenknoten 636, der gleich oder ähnlich wie der eine oder die mehreren Edge-Rechenknoten 140 aus 1, Edge-Rechenknoten 436 aus 4 und/oder Edge-Rechenknoten 1136 aus 11 sein kann. Die Umgebung 600x, mit der der Agent 640 interagiert, ist ein Mehrfachzugriffsnetz, in dem UEs 601 mit mehreren Funkschnittstellen vorhanden sind, die mit mehreren RANs verbunden sind, von denen einige unterschiedliche RATs nutzen. Jedes RAN kann eine DU 630 und eine oder mehrere RUs 633 beinhalten (z. B. DU 630a und RUs 633a1 und 633a2 können zu einem ersten RAN gehören, DU 630b und RUs 633b1 und 633b2 können zu einem zweiten RAN gehören und DU 630c und RUs 633c1 und 633c2 können zu einem dritten RAN gehören). Die RANs (z. B. DUs 630 und/oder RUs 633) in 6 können einem oder mehreren der NANs 130 von 1a, NANs 433 von 4 und/oder NANs 1131-1133 von 11 entsprechen, die nachstehend erörtert werden. Zusätzlich dazu können die UEs 601 den UEs 101 aus 1a, den Rechenknoten 401 aus 4, den UEs 1121a und 1121b und/oder den IoT-Vorrichtungen 1110 aus 11 und/oder dergleichen entsprechen.
Der Agent 640 ist für die Entscheidung der Verkehrsverwaltungsstrategien (z. B., Aktion α ∈ A, wobei A eine Menge aller möglichen/potentiellen Aktionen ist), wie etwa Verkehrslenkungs- und/oder Verkehrsaufteilungsstrategien für die Multi-RAT-UEs 601, basierend auf den Beobachtungen (z. B. Zustand s), die von der Umgebung 600x gesammelt werden, verantwortlich. Nach dem Durchführen der Verkehrslenkungs-/Aufteilungsstrategie, die von dem Agenten 640 empfohlen wird, können neue Beobachtungen von der Umgebung 600x gesammelt werden (z. B. ein neuer Zustand s' ∈ S, wobei S eine Menge aller Zustände ist, die den Endzustand beinhalten können oder nicht), und eine Belohnung r kann gemäß einer konstruierten Belohnungsfunktion berechnet werden.
Der Agent 640, der sich am Edge-Rechenknoten 636 befindet, beinhaltet eine intelligente RAN-Steuerung (RIC) 612a (die der Nicht-RT-RIC 2012 und/oder der Nahezu-RT-RIC 2014 der unten erörterten 20 entsprechen kann), die Verkehrsverteilungsregeln 613 berechnet, die der Zentraleinheit-Steuerebenenentität (CU-CP) 612b bereitgestellt werden, und die CU-CP 612b informiert die Zentraleinheit-Benutzerebenenentität (CU-UP) 614 und die UEs 601 darüber, wie Pakete über die mehreren Pfade (z. B. Pfade zwischen einzelnen UEs 601 und einer oder mehreren RUs 633) zu leiten sind. Die RIC 612a und/oder die CU-CP 612b sammeln Rückmeldungen von drahtloser Infrastruktur (z. B RAN-Messungen von einer oder mehreren DUs 630 und/oder einer oder mehreren RUs 633) und/oder direkt von Benutzern (z. B. UE-Messungen von einem oder mehreren UEs 601) und berücksichtigt Datenfluss-/App-/QoS-Anforderungen 625, die von einer oder mehreren höheren Schichten bereitgestellt werden, um zu ermitteln, wie Datenflüsse über die mehreren Pfade geleitet werden sollen, um heterogene QoS-Ziele zu erfüllen. Zusätzlich oder alternativ sammeln die RIC 612a und/oder die CU-CP 612b Telemetriestatistiken von der CU-UP 614. Zusätzlich oder alternativ sammeln die RIC 612a und/oder CU-CP 612b Leistungsfähigkeitsindikatoren von einer oder mehreren Netzwerkfunktionen (NFs) in einem Kernnetz (z. B. CN 1142 oder dergleichen). Verkehr 625 trifft an der CU-UP 614 ein, wird durch ein Paketfilter 618 gefiltert, in jeweilige QoS(Datenfluss)-Warteschlangen 610 sortiert und dann von den Datenflüssen (Warteschlangen 410) über die Mehrfachpfade zur Lieferung an entsprechende UEs 601 über Verknüpfungen 615 geleitet.
Unter Bezugnahme auf 7, die Beispiele für vollständiges RL 701 und einen kontextbezogenen Banditen 702 zeigt. RL nimmt üblicherweise an, dass die zugrundeliegende Umgebung 600x durch einen Markov-Entscheidungsprozess (MDP) modelliert werden kann. Die sofortige Belohnung 713 für vollständiges RL 701 hängt vom aktuellen Zustand 711 und der durchgeführten Aktion 712 ab, und die Aktion 712 beeinflusst auch den nächsten Zustand 711. Da sich der Einfluss der aktuellen Aktion 712 durch zukünftige Zustände 711 verbreitet, sollte die erwartete langfristige kumulative Belohnung 713 verwendet werden, wenn die Leistungsfähigkeit einer Richtlinie bewertet wird, die die angesichts der Beobachtung des aktuellen Zustands 711 durchzuführende Aktion 712 bestimmt. Für einen vollständigen MDP kann der Zustandsaktionsraum sehr groß sein, daher kann das RL 701 möglicherweise die Abbildung Zustand 711 zu Aktion 712 zu Belohnung 713 nicht lernen und sogar die erlernte Richtlinie π vergessen. Aus diesen Gründen ist das vollständige RL 701 häufig schwierig zu lösen und weist tendenziell eine schlechte Generalisierungsleistungsfähigkeit für verdeckte Umgebungen auf.
Gemäß verschiedenen Ausführungsformen wird ein kontextbezogener Bandit (CB) 702 (der eine Form von RL ist) verwendet. Im CB 702 wird die Belohnung 723 durch das Paar von Zustand 721 und Aktion 722 beeinflusst, aber die Aktion 722 beeinflusst den zukünftigen Zustand 721 nicht. Das Finden der Richtlinie π, die die erwartete durchschnittliche Belohnung 723 für die Beobachtung des aktuellen Zustands 721 maximieren kann, wird das Ziel.
Es wurde beobachtet, dass das Multi-RAT/Mehrfachzugriffsverkehrsverwaltungsproblem als ein Problem mit einem CB 702 modelliert werden kann, da die Verkehrsverwaltungsentscheidungen und QoS-Leistungsfähigkeit durch gewisse Kontexte ermittelt werden können, die nicht durch die Aktion 722 beeinflusst werden. Durch Transformieren des Problems in den CB 702 können eine viel schnellere Trainingskonvergenz und viel bessere Generalisierungsergebnisse für die Inferenz im Vergleich zu existierenden Lösungen erreicht werden.
Bei dem Multi-RAT/Mehrfachzugriffsverkehrsverwaltungsproblem basierend auf [AC6833PCT] wurde identifiziert, dass Verkehrslast, Kanalzustand, Backhaul-Verzögerung Schlüsselmerkmale sind, die grundlegende Auswirkung auf die Verkehrsverwaltungsentscheidungen und QoS-Leistungsfähigkeit aufweisen. Daher können diese Merkmale als die Kontexteingabe in den CB 702 verwendet werden.
8 zeigt beispielhafte Komponenten eines tiefgehenden CB-RL-Frameworks 800, das durch den Agenten 640 aus 6 implementiert werden kann. Hier nimmt eine Repräsentationslernentität 801 Rohkontexte (Kontextdaten) 821 und verwendet einen Codierer 811, um ein oder mehrere latente Merkmale aus den Rohkontexten 821 zu extrahieren. Als Beispiele beinhaltet der Codierer 811 ein LSTM-Netz und/oder eine Grapheneinbettung und/oder ein neuronales Graphennetz und/oder ein Aufmerksamkeitsnetz und/oder dergleichen.
Die DRL-Entität 802 nimmt eine Ausgabe von der Repräsentationslernentität 801 und der einen oder den mehreren Belohnungen 823, die durch Interagieren mit der Umgebung 100x gesammelt werden, und leitet eine Abbildung zwischen dem Zustand (z. B. basierend auf den Rohkontexten 821), der Aktion 822 und der Belohnung 823 ab. Bei Ausführungsformen verwendet die DRL-Entität 802 Aktor-Kritik-RL und einen Richtliniengradienten, wie etwa tiefen deterministischen Richtliniengradienten (DDPG), um die Abbildungen abzuleiten.
Die Gestaltung von Zustand 721/821, Aktion 722/822 und Belohnung 723/823 wird verwendet, um den Kontextraum kontinuierlich (z. B. eine Zeitreihe von Verkehrslast, Kanalzustand und Backhaul-Verzögerung) oder diskret (z. B. mittlere Verkehrslast, Kanalzustand und Backhaul-Verzögerung) zu gestalten. In einigen Ausführungsformen ist der Aktionsraum kontinuierlich gestaltet (z. B. Verkehrsaufteilungsverhältnis). In einigen Ausführungsformen kann die Belohnungsfunktion eine Hilfsfunktion des Netzwerk-QoS-Ziels (z. B. Netzwerkdurchsatz, Paketverzögerung, Jitter, Alpha-Fairness usw.) sein. Für latenzempfindlichen Verkehr kann die Belohnung r zum Beispiel folgendermaßen definiert sein: $r = \frac{1}{\sum d_{i}}$
wobei d_i die durchgehende Paketverzögerung für das i-te Paket ist. Falls das System eine schlechtere PaketverzögerungsQoS erfährt, wird die Belohnung r kleiner, andernfalls verbessert sich die Belohnung r, wenn sich die Verzögerungs-QoS verbessert.
9 stellt eine beispielhafte Systemarchitektur 900 dar, die (zumindest teilweise) durch den Agenten 640 aus 6 implementiert werden kann. Die Architektur 900 beinhaltet ein Repräsentations(Codierer)-Netz 901 (das der Repräsentationslernentität 801 von 8 entsprechen kann), ein DRL-Framework 902 (das dem DRL-Framework 802 von 8 entsprechen kann) und einen Wiedergabepuffer 930 (der gleich oder ähnlich wie der Wiedergabepuffer 530 von 5) sein kann). Das DRL-Framework 902 kann einen Richtliniengradientenlernansatz, wie etwa Aktor-Kritik, DDPG und/oder irgendein anderes Richtliniengradientenverfahren, wie etwa jene hierin erörterten, einsetzen. Das DRL-Framework 902 weist ein Aktornetz 903 und ein Kritiknetz 905 auf. Das Kritiknetz 905 aktualisiert Wertefunktionsparameter w, a und abhängig vom Algorithmus könnten diese Aktionswert Q_w(a|s) oder Zustandswert V_w(s) sein. Das Aktornetz 903 aktualisiert die Richtlinienparameter θ für π_θ(a|s) in der vom Kritiknetz 905 vorgeschlagenen Richtung. Der Wiedergabepuffer 930 kann Erfahrungsdatenstrukturen von beispielsweise (s_t, a_t, r_t, s_t+1) oder dergleichen speichern. Zu jedem Zeitschritt werden das Aktornetz 903 und das Kritiknetz 905 durch gleichmäßiges Abtasten eines Mini-Batchs aus dem Wiedergabepuffer 930 aktualisiert. Ein beispielhafter Trainingsprozess und ein Inferenzprozess für die Systemarchitektur 900 können folgendermaßen durchgeführt werden.
3.1. TRAININGSPROZESS
Während der Trainingsphase können drei neuronale Netze einschließlich des Repräsentations-/Codiernetzes 901, eines Aktornetzes 903 und eines Kritiknetzes 905 trainiert werden. Der Trainingsprozess kann folgendermaßen verlaufen:
Zuerst werden das Kritiknetz 905, das Aktornetz 903 und das Repräsentations-/Codiernetz 901 mit Parametern θ^Q, θ^µ bzw. θ^E zufällig initialisiert (die Parameter θ^Q, θ^µ und θ^E können auch als Gewichtungen θ^Q, θ^µ bzw. θ^E bezeichnet werden). Zusätzlich wird der Wiedergabepuffer 930 initialisiert. Als Zweites wird ein Zufallsprozess zur Aktionserkundung initialisiert.
Als Drittes sammeln alle aktiven UEs 601 Kontexte 921 aus der Umgebung 100x und geben sie an das Repräsentations(Codier)-Netz 901 weiter. Die Kontexte 921 können Beobachtungen, wie etwa gemessene Verkehrslast, PHY-Rate, Signal-Rausch-Verhältnis (SNR), Backhaul-Verzögerung und/oder beliebige andere hierin erörterte Messungen und/oder Informationen, beinhalten. Diese Informationen können von Gruppen von UEs 601 und/oder einem Ziel-UE 601 gesammelt werden, dem der Agent die Aktionsempfehlung bereitstellen wird. Als Viertes erhält das Repräsentationsnetzwerk 901 eine Darstellung der aktuellen Kontexte 921 für die Gruppen von UEs 601 sowie das Ziel-UE 601.
Als Fünftes wählt der Agent eine Aktion gemäß der aktuellen Richtlinie π und dem Erkundungsrauschen aus. Mit einer Wahrscheinlichkeit von ∈ kann der Agent den Aktionsraum zufällig abtasten oder einen existierenden heuristischen Algorithmus verwenden, wobei 1 - ε der Agent die Aktion auswählt, die aus der Richtlinie π plus Aktionsrauschen abgeleitet wird, das aus dem Zufallsprozess generiert wurde. Als Sechstes stellt der Agent dann die Aktion für das Ziel-UE 601 bereit, und die Belohnung wird gesammelt. Die Aktion, der Zustand und der Belohnungsübergang werden (z. B. in einer Erfahrungsdatenstruktur) im Wiedergabepuffer 930 gespeichert.
Als Siebentes wird eine Probe eines Mini-Batches der Größe N zufällig aus dem Wiedergabepuffer 930 genommen, wobei der Index i auf den i-ten Probenwert verweist. Das Ziel für die Zeitdifferenz(TD)-Fehlerberechnung y_i wird aus der unmittelbaren Belohnung für das Problem mit kontexbezogenen Banditen berechnet. Zusätzlich oder alternativ wird die TD-Fehlerberechnung y_i aus der unmittelbaren Belohnung und den Ausgaben der Ziel-Aktor- und Kritiknetze berechnet, die Gewichtungen θ^µ' bzw. θ^Q' aufweisen. Danach wird das Kritiknetz (θ^Q) 905 trainiert, um die folgende Verlustfunktion (LF) zu minimieren: $L = \frac{1}{N} \sum_{i} (y_{i} - Q {(c_{i}, a_{i} | θ^{Q})}^{2})$
In der Verlustfunktion (LF) ist y_i das TD-Ziel, wobei y_i = r_i, r_i die Belohnung ist und c_i der codierte Kontext ist (z. B. codierte Version der Kontexte 921). Als Achtes wird das Aktornetz (θ^µ) 903 auf Grundlage eines Richtliniengradienten trainiert, um die folgende Belohnungsfunktion (RF2) zu maximieren. $J = \frac{1}{N} \sum_{i} (\nabla_{a} Q (c, a | θ^{Q}) |_{c = c_{i,} a = μ (c_{i})}, \nabla_{θ^{μ}} μ (c | θ^{μ}) |_{c = c_{i}}$
In der Belohnungsfunktion (RF) ist ∇_aQ ein Gradient des Kritiknetzes 905 in Bezug auf Aktionen a, und $\nabla_{θ^{μ}} μ$
ist der Richtliniengradient des Aktornetzes 903. Der Gradient ∇_aQ wird verwendet, um die Parameter des Aktornetzes 903 zu aktualisieren, falls die Aktion a einen höheren Q-Wert als eine vorherige Aktion aufweist.
Als Neuntes wird das Codiernetz (θ^E) 901 auf Grundlage des stichprobenweisen Richtliniengradienten w folgendermaßen trainiert: $\begin{array}{l} \nabla_{θ^{E}} j \\ = \frac{1}{N} (\nabla_{a} Q (c, a | θ^{Q}) |_{c = c_{i,} a = μ (c_{i})}, \nabla_{θ^{μ}} μ (c | θ^{μ}) |_{c = E (s_{i})} \nabla_{θ^{E}} E (s | θ^{E}) |_{s = s_{i}} \end{array}$
Im obigen Richtliniengradiententheorem ist s_i der ursprüngliche Eingabekontext (z. B. die Kontexte 921), $\nabla_{θ^{E}} E$
ist der Richtliniengradient für das Codiernetz (θ^E) 901, und $\nabla_{θ^{E}} J$
ist ein Gradient der Belohnung.
3.2. INFERENZPROZESS
Während der Inferenzphase müssen nur das Repräsentationsnetz 901 und das Aktornetz 903 bereitgestellt werden. Der Inferenzprozess kann folgendermaßen verlaufen: Zuerst beobachtet ein UE 601 einen oder mehrere Kontexte von der Umgebung 100x und gibt die beobachteten Kontexte an das Repräsentationsnetz 901 weiter. Als Zweites wird die erlernte Repräsentation der aktuellen Dynamik und des Ziel-UE 601 (z. B. Merkmale $h_{t}^{i},$
wobei i = 1, ..., N) an das Aktornetz 903 weitergeleitet. Als Drittes wird die vom Aktornetz 903 vorhergesagte Aktion 922 für das Ziel-UE 601 (in der Umgebung 100x) bereitgestellt, und das UE 601 führt die vorhergesagte Aktion 922 entsprechend durch.
3.3. SIMULATIONSERGEBNISSE
10a und 10b stellen Leistungsfähigkeitsergebnisse eines beispielhaften tiefgehenden CB-RL-Systems, wie etwa des mit Bezug auf 8-9 beschriebenen Systems, dar. Insbesondere beinhaltet 10a einen DRL-Trainingsleistungsfähigkeitsgraphen, der Bewertungen verschiedener Ansätze versus Trainingsepochen zeigt, und 10b beinhaltet einen DRL-Leistungsfähigkeitsgraphen, der Bewertungen der verschiedenen Ansätze versus Bewertungen für verschiedene Umgebungen zeigt. In den Graphen der 10a und 10b sind Ergebnisse des tiefgehenden CB-RL-Systems mit „DDPG“ gekennzeichnet, einschließlich „DDPG-zufällig“ und „DDPG-RANAware“. DDPG-zufällig gibt eine zufällig ausgewählte Aktion während der Erkundungsphase an, während DDPG-RANAware angibt, dass eine RANAware-Heuristik während der Erkundungsphase verwendet wurde (siehe z. B. [AC6833PCT], [AC6833Z]). „RANAware“, „DelayEqual“ und „zufällig“ sind unterschiedliche heuristische Algorithmen, die mit DDPG verglichen werden. Aus diesen Graphen ist ersichtlich, dass der datengesteuerte Ansatz (DDPG) alle existierenden Lösungen übertreffen kann und eine höhere Bewertung und bessere QoS-Leistungsfähigkeit als die existierenden Lösungen erreichen kann.
4. EDGE-RECHENSYSTEM-KONFIGURATIONEN UND -ANORDNUNGEN
Edge-Rechnen bezieht sich auf allgemeiner Ebene auf die Implementierung, Koordination und Verwendung von Rechnen und Ressourcen an Standorten näher an der „Kante“ oder einer Sammlung von „Kanten“ des Netzwerks. Zweck dieser Anordnung ist es, die Gesamtbetriebskosten zu verbessern, Anwendung und Netzwerklatenz zu reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch zu reduzieren, Dienstfunktionen zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen (insbesondere im Vergleich zu herkömmlichem Cloud-Computing) zu verbessern. Komponenten, die Edge-Rechenoperationen („Edge-Knoten“) durchführen können, können sich an jedem Standort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird (z. B. in einem Hochleistungsrechenzentrum oder einer Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmensserver, einem Straßenrand-Server, einer Fernmeldezentrale; oder einer lokalen oder Peer-an-der-Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert).
Individuelle Rechenplattformen oder andere Komponenten, die Edge-Rechenoperationen durchführen können (als „Edge-Rechenknoten“, „Edge-Knoten“ oder dergleichen bezeichnet), können sich an einem beliebigen Ort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird. In vielen Edge-Rechenarchitekturen werden Edge-Knoten an NANs, Gateways, Netzwerkroutern und/oder anderen Vorrichtungen eingesetzt, die näher an Endpunktvorrichtungen (z. B. UEs, IoT-Vorrichtungen usw.) liegen, die Daten produzieren und verwenden. Als Beispiele können Edge-Knoten in einem Hochleistungsrechenzentrum oder einer Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmens server, einem Straßenrand-Server, einer Fernmeldezentrale; oder einer lokalen oder Peer-an-der-Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert, implementiert sein.
Edge-Rechenknoten können Ressourcen (z. B. Speicher, CPU, GPU, Interruptsteuerung, E/A-Steuerung, Speichersteuerung, Buscontroller, Netzwerkverbindungen oder -sitzungen usw.) partitionieren, wobei jeweilige Partitionierungen Sicherheits- und/oder Integritätsschutzfunktionen enthalten können. Edge-Knoten können auch eine Orchestrierung mehrerer Anwendungen durch isolierte Benutzerrauminstanzen, wie etwa Container, Partitionen, virtuelle Umgebungen (VEs), virtuelle Maschinen (VMs), Funktion-as-a-Service(FaaS)-Engines, Servlets, Server und/oder andere ähnliche Berechnungsabstraktionen bereitstellen. Container sind begrenzte bereitstellbare Softwareeinheiten, die Code und benötigte Abhängigkeiten bieten. Verschiedene Edge-Systemanordnungen/-architekturen behandeln VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich. Die Edge-Knoten werden basierend auf Edge-Bereitstellungsfunktionen koordiniert, während der Betrieb der verschiedenen Anwendungen mit Orchestrierungsfunktionen (zum Beispiel VM oder Container-Engine usw.) koordiniert wird. Die Orchestrierungsfunktionen können verwendet werden, um die isolierten Benutzerrauminstanzen bereitzustellen, die Verwendung spezifischer Hardware, sicherheitsbezogene Funktionen (zum Beispiel Schlüsselverwaltung, Vertrauensankerverwaltung usw.) sowie andere Aufgaben im Zusammenhang mit der Bereitstellung und dem Lebenszyklus isolierter Benutzerräume zu identifizieren und zu planen.
Anwendungen, die für Edge-Rechnen angepasst wurden, beinhalten unter anderem Virtualisierung traditioneller Netzwerkfunktionen (um z. B. Telekommunikations- oder Internetdienste zu betreiben) und die Einführung von Merkmalen und Diensten der nächsten Generation (um z. B. 5G-Netzwerkdienste zu unterstützen). Anwendungsfälle, bei denen projiziert wird, dass sie Edge-Rechnen umfangreich nutzen werden, beinhalten angebundene selbstfahrende Autos, Überwachung, Internet-der-Dinge(IoT)-Vorrichtungsdatenanalytik, Videocodierung und -analytik, ortsbewusste Dienste, Vorrichtungserfassung in Smart Cities, unter vielen anderen Netzwerk- und rechenintensiven Diensten.
Edge-Rechnen kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen oder hosten, um Orchestrierung und Verwaltung von Anwendungen und koordinierten Dienstinstanzen unter vielen Arten von Speicher- und Rechenressourcen zu bieten. Es wird auch erwartet, dass Edge-Rechnen eng mit existierenden Anwendungsfällen und Technologie integriert wird, die für IoT- und Fog-/verteilte Netzwerkkonfigurationen entwickelt wurden, da Endpunktvorrichtungen, Clients und Gateways versuchen, auf Netzwerkressourcen und Anwendungen an Standorten näher am Rand des Netzwerks zuzugreifen.
Die vorliegende Offenbarung stellt spezifische Beispiele bereit, die für Edge-Rechenkonfigurationen relevant sind, die innerhalb von Mehrfachzugriff-Edge-Rechnen (MEC) und 5G-Netzwerkimplementierungen bereitgestellt werden. Viele andere Standards und Netzwerkimplementierungen sind jedoch auf die hierin besprochenen Edge- und Dienstverwaltungskonzepte anwendbar. Zum Beispiel können viele andere Edge-Rechen-/Vernetzungstechnologien auf die vorliegende Offenbarung in verschiedenen Kombinationen und Anordnungen von Vorrichtungen anwendbar sein, die sich am Rand eines Netzwerks befinden. Beispiele für solche anderen Edge-Rechen-/Vernetzungstechnologien beinhalten Content Delivery Networks (CDNs) (auch als „Content Distribution Networks“ oder dergleichen bezeichnet); Mobility-Service-Provider(MSP)-Edge-Rechen- und/oder Mobility-as-a-Service(MaaS)-Anbietersysteme (z. B. in AECC-Architekturen verwendet); Nebula Edge-Cloud-Systeme; Fog-Rechensysteme; Cloudlet Edge-Cloud-Systeme; mobile Cloud-Computing(MCC)-Systeme; Zentrale, die als ein Rechenzentrum umarchitekturiert ist (CORD), mobile CORD- (M-CORD) und/oder konvertierte Mehrfachzugriffs- und Kern(COMAC)-Systeme; und/oder dergleichen. Ferner können sich die hier offenbarten Techniken auf andere IoT-Edge-Netzwerksysteme und -Konfigurationen beziehen, und es können auch andere Zwischenverarbeitungsentitäten und Architekturen für Zwecke der vorliegenden Offenbarung verwendet werden.
11 veranschaulicht eine beispielhafte Edge-Rechenumgebung 1100. 11 veranschaulicht insbesondere die unterschiedlichen Kommunikationsschichten, die innerhalb der Umgebung 1100 auftreten, beginnend mit Endpunktsensoren- oder Ding-Schichten 1110 (zum Beispiel die in einer Internet-der-Dinge-Netzwerktopologie (IoT-Netzwerktopologie) arbeiten), die eine oder mehrere IoT-Vorrichtungen 1111 (auch als Edge-Endpunkte 1110 oder dergleichen bezeichnet) umfassen; mit wachsender Ausgereiftheit bis zu Gateways oder einer Zwischenknotenschicht 1120, die ein oder mehrere Endgeräte (UEs) 1121a und 1121b (auch als Zwischenknoten 1120 oder dergleichen bezeichnet) umfassen, die das Sammeln und Verarbeiten von Daten von Endpunkten 1110 erleichtern; mit wachsender Verarbeitungs- und Konnektivitätsausgereiftheit bis zur Zugangsknotenschicht 1130 (oder „Edge-Knotenschicht 1130“), die eine Vielzahl von Netzwerkzugangsknoten (NANs) 1131, 1132 und 1133 (gemeinsam als „NANs 1131-1133“ oder dergleichen bezeichnet) umfasst und eine Vielzahl von Edge-Rechenknoten 1136a-c (kollektiv als „Edge-Rechenknoten 1136“ oder dergleichen bezeichnet) innerhalb eines Edge-Rechensystems 1135; und wachsender Konnektivitäts- und Verarbeitungsausgereiftheit bis zu einer Backend-Schicht 1110, die ein Kernnetz (CN) 1142 und eine Cloud 1144 umfasst. Die Verarbeitung an der Backend-Schicht 1110 kann von Netzwerkdiensten verbessert werden, wie sie von einem oder mehreren Fernanwendungs-(App)-Servern 1150 und/oder anderen Cloud-Diensten ausgeführt werden. Einige oder alle dieser Elemente können mit einigen oder allen hierin besprochenen Merkmalen und/oder Funktionen ausgestattet sein oder diese anderweitig umsetzen.
Es ist gezeigt, dass die Umgebung 1100 Endbenutzervorrichtungen, wie Zwischenknoten 1120 und Endpunkte 1110 beinhaltet, die ausgelegt sind, um sich basierend auf unterschiedlichen Zugangstechnologien (oder „Funkzugangstechnologien“) zum Zugreifen auf Anwendungsdienste mit einem oder mehreren Kommunikationsnetzwerken (auch als „Zugangsnetzwerke“, „Funkzugangsnetzwerke“ oder dergleichen bezeichnet) zu verbinden (oder kommunikativ mit diesen zu koppeln). Diese Zugangsnetzwerke können einen oder mehrere der NANs 1131, 1132 und/oder 1133 beinhalten. Die NANs 1131-1133 sind ausgelegt, den Endbenutzervorrichtungen über jeweilige Verknüpfungen 1103, 1107 zwischen den einzelnen NANs und dem einen oder den mehreren UEs 1111, 1121 Netzwerkkonnektivität bereitzustellen.
Als Beispiele können die Kommunikationsnetzwerke und/oder Zugangstechnologien zellulare Technologie, Mobilfunktechnologie, wie LTE, MuLTEfire und/oder NR/5G (wie z. B. von Funkzugangsnetzwerkknoten (RAN-Knoten) 1131 und/oder RAN-Knoten 1132 bereitgestellt), WiFi- oder drahtlose lokale Netzwerktechnologien (WLAN-Technologien) (wie z. B. von einem Zugangspunkt (AP) 1133 und/oder RAN-Knoten 1132 bereitgestellt) und/oder dergleichen beinhalten. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistung in unterschiedlichen Szenarien hängt von der Auswahl der Zugangsnetzwerke (z. B. WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokolle (z. B. Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) ab.
Die Zwischenknoten 1120 beinhalten UE 1121a und UE 1121b (kollektiv als „UE 1121“ oder „UEs 1121“ bezeichnet). In diesem Beispiel ist das UE 1121a als ein Fahrzeug-UE veranschaulicht und das UE 1121b ist als ein Smartphone (z. B. eine tragbare mobile Rechenvorrichtung mit Berührungsbildschirm, die mit einem oder mehreren Mobilfunknetzen verbindbar ist) veranschaulicht. Diese UEs 1121 können jedoch eine beliebige mobile oder nicht mobile Rechenvorrichtung, wie etwa Tablet-Computer, tragbare Vorrichtungen, PDAs, Pager, Desktop-Computer, Laptop-Computer, drahtlose Handapparate, unbemannte Fahrzeuge oder Drohnen, und/oder eine beliebige Art von Rechenvorrichtung einschließlich einer drahtlosen Kommunikationsschnittstelle umfassen.
Die Endpunkte 1110 beinhalten UEs 1111, die IoT-Vorrichtungen (auch als „IoT-Vorrichtungen 1111“ bezeichnet) sein können, die eindeutig identifizierbare eingebettete Rechenvorrichtungen (z. B. innerhalb der Internet-Infrastruktur) sind, die eine Netzwerkzugangsschicht umfassen, die für Niedrigenergie-IoT-Anwendungen ausgelegt ist, die kurzlebige UE-Verbindugnen nutzen. Die IoT-Vorrichtungen 1111 sind beliebige physische oder virtualisierte Vorrichtungen, Sensoren oder „Dinge“, die mit Hardware- und/oder Softwarekomponenten eingebettet sind, die den Objekten, Vorrichtungen, Sensoren oder „Dingen“ ermöglichen, dass sie fähig sind, mit einem Ereignis assoziierte Daten zu erfassen und/oder aufzuzeichnen, und fähig sind, derartige Daten über ein Netzwerk mit wenig oder keinem Benutzereingriff mit einer oder mehreren anderen Vorrichtungen zu kommunizieren. Als Beispiele können die IoT-Vorrichtungen 1111 abiotische Vorrichtungen sein, wie etwa autonome Sensoren, Messgeräte, Zähler, Bilderfassungsvorrichtungen, Mikrofone, lichtemittierende Vorrichtungen, audioemittierende Vorrichtungen, Audio- und/oder Videowiedergabevorrichtungen, elektromechanische Vorrichtungen (z. B. Schalter, Aktuator usw.), EEMS, ECUs, ECMs, eingebettete Systeme, Mikrocontroller, Steuermodule, vernetzte oder „intelligente“ Geräte, MTC-Vorrichtungen, M2M-Vorrichtungen und/oder dergleichen. Die IoT-Vorrichtungen 1111 können Technologien, wie etwa M2M oder MTC, zum Austauschen von Daten mit einem MTC-Server (z. B. einem Server 1150), einem Edge-Server 1136 und/oder Edge-Rechensystem 1135 oder einer Vorrichtung über eine PLMN-, ProSe- oder D2D-Kommunikation, Sensornetzwerke oder IoT-Netzwerke nutzen. Der M2M- oder MTC-Datenaustausch kann ein maschineninitiierter Datenaustausch sein.
Die IoT-Vorrichtungen 1111 können Hintergrundanwendungen ausführen (z. B. Keep-Alive-Nachrichten, Statusaktualisierungen usw.), um die Verbindungen des IoT-Netzwerks zu ermöglichen. Wenn die IoT-Vorrichtungen 1111 Sensorvorrichtungen sind oder in diese eingebettet sind, kann das IoT-Netzwerk ein WSN sein. Ein IoT-Netzwerk beschreibt miteinander verbundene IoT-UEs, wie etwa die IoT-Vorrichtungen 1111, die über jeweilige direkte Verknüpfungen 1105 miteinander verbunden sind. Die IoT-Vorrichtungen können eine beliebige Anzahl unterschiedlicher Typen von Vorrichtungen beinhalten, die in verschiedenen Kombinationen gruppiert sind (als eine „IoT-Gruppe“ bezeichnet), die IoT-Vorrichtungen beinhalten können, die einen oder mehrere Dienste für einen bestimmten Benutzer, Kunden, Organisationen usw. bereitstellen. Ein Dienstanbieter (z. B. ein Eigentümer/Betreiber des Servers 1150, des CN 1142 und/oder der Cloud 1144) kann die IoT-Vorrichtungen in der IoT-Gruppe in einem bestimmten Bereich (z. B. einer Geolokalisierung, einem Gebäude usw.) bereitstellen, um den einen oder die mehreren Dienste anzubieten. Bei manchen Implementierungen kann das IoT-Netzwerk ein Mesh-Netzwerk von IoT-Vorrichtungen 1111 sein, die als Fog-Vorrichtung, Fog-System oder Fog bezeichnet werden können, die am Rand der Cloud 1144 arbeiten. Der Fog beinhaltet Mechanismen, um Cloud-Rechenfunktionalität näher an Datengeneratoren und -konsumenten zu bringen, wobei verschiedene Netzwerkvorrichtungen Cloud-Anwendungslogik auf ihrer nativen Architektur ausführen. Fog-Computing ist eine horizontale Architektur auf Systemebene, die Ressourcen und Dienste von Computing, Speicherung, Steuerung und Vernetzung überall entlang des Kontinuums von der Cloud 1144 bis hin zu Dingen (z. B. IoT-Vorrichtungen 1111) verteilt. Der Fog kann gemäß Spezifikationen eingerichtet werden, die unter anderem von der OFC, der OCF, veröffentlicht wurden. Zusätzlich oder alternativ dazu kann der Fog ein Tangle sein, wie sie von der IOTA-Foundation definiert ist.
Der Fog kann verwendet werden, um Berechnung/Aggregation mit niedriger Latenz an den Daten durchzuführen, während sie zu einem Edge-Cloud-Rechendienst (z. B. Edge-Knoten 1130) und/oder einem zentralen Cloud-Rechendienst (z. B. Cloud 1144) geleitet werden, um schwere Berechnungen oder rechenaufwändige Aufgaben durchzuführen. Andererseits konsolidiert Edge-Cloud-Rechnen menschlich betriebene, willkürliche Ressourcen als eine Cloud. Diese freiwilligen Ressourcen können unter anderem Zwischenknoten 1120 und/oder Endpunkte 1110, Desktop-PCs, Tablets, Smartphones, Nano-Rechenzentren und dergleichen beinhalten. Bei verschiedenen Implementierungen können sich Ressourcen in der Edge-Cloud in einer Nähe von einem bis zwei Hops zu den IoT-Vorrichtungen 1111 befinden, was zu einer Reduzierung von Mehraufwand in Bezug auf die Verarbeitung von Daten führen kann und Netzwerkverzögerung reduzieren kann.
Zusätzlich oder alternativ dazu kann der Fog eine Konsolidierung von IoT-Vorrichtungen 1111 und/oder Vernetzungsvorrichtungen, wie etwa Routern und Switches, mit hohen Rechenfähigkeiten und der Fähigkeit sein, Cloud-Anwendungslogik auf ihrer nativen Architektur auszuführen. Fog-Ressourcen können von Cloud-Anbietern hergestellt, verwaltet und bereitgestellt werden, und sie können mittels zuverlässiger Hochgeschwindigkeitsverknüpfungen miteinander verbunden sein. Darüber hinaus sind die Fog-Ressourcen im Vergleich zu Edge-Systemen weiter vom Rand des Netzwerks entfernt, aber näher als eine zentrale Cloud-Infrastruktur angeordnet. Fog-Vorrichtungen werden verwendet, um rechenintensive Aufgaben oder Arbeitslasten, die von Edge-Ressourcen ausgelagert werden, effektiv zu handhaben.
Zusätzlich oder alternativ kann der Fog am Rand der Cloud 1144 arbeiten. Der Fog, der am Rand der Cloud 1144 arbeitet, kann mit einem Edge-Netzwerk 1130 der Cloud 1144 überlappen oder in dieses zusammengefasst werden. Das Edge-Netzwerk der Cloud 1144 kann mit dem Fog überlappen oder ein Teil des Fog werden. Ferner kann der Fog ein Edge-Fog-Netzwerk sein, das eine Edge-Schicht und eine Fog-Schicht beinhaltet. Die Edge-Schicht des Edge-Fog-Netzwerks beinhaltet eine Sammlung lose gekoppelter, freiwilliger und vom Menschen betriebener Ressourcen (z. B. die oben erwähnten Edge-Rechenknoten 1136 oder Edge-Vorrichtungen). Die Fog-Schicht befindet sich über der Edge-Schicht und ist eine Konsolidierung von Vernetzungsvorrichtungen, wie etwa den Zwischenknoten 1120 und/oder Endpunkten 1110 von 11.
Daten können zwischen den IoT-Vorrichtungen 1111 oder zum Beispiel zwischen den Zwischenknoten 1120 und/oder Endpunkten 1110, die direkte Verknüpfungen 1105 miteinander aufweisen, wie in 11 gezeigt, erfasst, gespeichert/aufgezeichnet und kommuniziert werden. Eine Analyse des Verkehrsflusses und der Steuerschemata kann durch Aggregatoren implementiert werden, die über ein Mesh-Netzwerk mit den IoT-Vorrichtungen 1111 und miteinander in Kommunikation stehen. Die Aggregatoren können ein Typ von IoT-Vorrichtung 1111 und/oder ein Netzwerkgerät sein. In dem Beispiel von 11 können die Aggregatoren Edge-Knoten 1130 oder ein oder mehrere designierte Zwischenknoten 1120 und/oder Endpunkte 1110 sein. Daten können über den Aggregator in die Cloud 1144 hochgeladen werden und Befehle können von der Cloud 1144 durch Gateway-Vorrichtungen empfangen werden, die mit den IoT-Vorrichtungen 1111 und den Aggregatoren über das Mesh-Netzwerk in Kommunikation stehen. Im Gegensatz zum herkömmlichen Cloud-Rechenmodell kann die Cloud 1144 bei manchen Implementierungen geringe oder keine Rechenfähigkeiten aufweisen und dient nur als ein Repositorium zum Archivieren von Daten, die durch den Fog aufgezeichnet und verarbeitet werden. Bei diesen Implementierungen zentralisiert die Cloud 1144 das Datenspeicherungssystem und stellt Zuverlässigkeit und Zugriff auf Daten durch die Rechenressourcen im Fog und/oder in Edge-Vorrichtungen bereit. Der Datenspeicher der Cloud 1144, der den Kern der Architektur bildet, ist sowohl für Edge- als auch Fog-Schichten des oben erwähnten Edge-Fog-Netzwerks zugänglich.
Wie zuvor erwähnt, stellen die Zugangsnetze Netzwerkkonnektivität über jeweilige NANs 1131-1133 an die Endbenutzervorrichtungen 1120, 1110 bereit. Die Zugangsnetze können Funkzugangsnetzwerke (RANs) sein, wie etwa ein NG-RAN oder ein 5G-RAN für ein RAN, das in einem 5G/NR-Mobilfunknetzwerk arbeitet, ein E-UTRAN für ein RAN, das in einem LTE- oder 4G-Mobilfunknetzwerk arbeitet, oder ein Legacy-RAN, wie etwa ein UTRAN oder GERAN für GSM- oder CDMA-Mobilfunknetzwerke. Das Zugangsnetz oder RAN kann für WiMAX Implementierungen als ein Zugangsdienstnetz bezeichnet werden. Zusätzlich oder alternativ dazu können alle oder Teile des RAN als eine oder mehrere Softwareentitäten implementiert sein, die auf Servercomputern als Teil eines virtuellen Netzwerks laufen, das als Cloud-RAN (CRAN), Cognitive Radio (CR), virtueller Basisbandeinheitspool (vBBUP) und/oder dergleichen bezeichnet werden kann. Zusätzlich oder alternativ dazu kann das CRAN, CR oder vBBUP eine RAN-Funktionsaufteilung implementieren, wobei eine oder mehrere Kommunikationsprotokollschichten durch das CRAN/CR/vBBUP betrieben werden und andere Kommunikationsprotokollentitäten durch individuelle RAN-Knoten 1131, 1132 betrieben werden. Dieses virtualisierte Framework ermöglicht den freigegebenen Prozessorkernen der NANs 1131, 1132, andere virtualisierte Anwendungen durchzuführen, wie etwa virtualisierte Anwendungen für verschiedene hierin erörterte Elemente.
Die UEs 1121, 1111 können jeweilige Verbindungen (oder Kanäle) 1103 nutzen, von denen jede eine physische Kommunikationsschnittstelle oder -schicht umfasst. Die Verbindungen 1103 sind als eine Luftschnittstelle veranschaulicht, um eine kommunikative Kopplung in Übereinstimmung mit Mobilfunk-Kommunikationsprotokollen, wie etwa 3GPP-LTE, 5G/NR, Push-to-Talk (PTT) und/oder PTT over Cellular (POC), UMTS, GSM, CDMA und/oder beliebigen der anderen hierin besprochenen Kommunikationsprotokolle, zu ermöglichen. Zusätzlich oder alternativ kommunizieren (übertragen und empfangen) die UEs 1111, 1121 und die NANs 1131-1133 Daten über ein lizenziertes Medium (auch als das „lizenzierte Spektrum“ und/oder das „lizenzierte Band“ bezeichnet) und ein unlizenziertes gemeinsam genutztes Medium (auch als das „unlizenzierte Spektrum“ und/oder das „unlizenzierte Band“ bezeichnet). Um in dem unlizenzierten Spektrum zu arbeiten, können die UEs 1111, 1121 und NANs 1131-1133 unter Verwendung von LAA-, enhanced LAA- (eLAA- ) und/oder weiteren eLAA- (feLAA-) Mechanismen arbeiten. Die UEs 1121, 1111 können ferner Kommunikationsdaten direkt über jeweilige direkte Verknüpfungen 1105 austauschen, die LTE/NR-Proximity-Services(ProSe)-Verknüpfungen oder PC5-Schnittstellen/Verknüpfungen oder WiFi-basierte Verknüpfungen oder Verknüpfungen auf persönlicher Netzwerkbasis (PAN) sein können (z. B. IEEE 802.15.4-basierte Protokolle einschließlich ZigBee, IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread usw.; WiFi-direct; Bluetooth/Bluetooth-Niedrigenergie(BLE)-Protokolle).
Zusätzlich oder alternativ dazu stellen einzelne UEs 1121, 1111 Funkinformationen an ein oder mehrere NANs 1131-1133 und/oder einen oder mehrere Edge-Rechenknoten 1136 (z. B. Edge-Server/Hosts usw.) bereit. Die Funkinformationen können in Form eines oder mehrerer Messberichte vorliegen und/oder können zum Beispiel Signalstärkemessungen, Signalqualitätsmessungen und/oder dergleichen beinhalten. Jeder Messbericht wird mit einem Zeitstempel und dem Ort der Messung (z. B. der aktuelle Ort der UEs 1121, 1111) markiert. Als Beispiele können die von den UEs 1121, 1111 gesammelten und/oder in den Messberichten enthaltenen Messungen eines oder mehrere der Folgenden beinhalten: Bandbreite (BW), Netzwerk- oder Zellenbelastung, Latenz, Jitter, Umlaufzeit (RTT), Anzahl von Interrupts, Außer-Reihenfolge-Lieferung von Datenpaketen, Sendeleistung, Bitfehlerrate, Bitfehlerverhältnis (BER), Blockfehlerrate (BLER), Paketverlustrate, Paketempfangsrate (PRR), e2e-Verzögerung, Signal-Rausch-Verhältnis (SNR), Signal-Rausch-und-Interferenz-Verhältnis (SINR), Signal-plus-Rausch-plus-Verzerrung-zu-Rausch-plus-Verzerrung-Verhältnis (SINAD-Verhältnis), Träger-zu-Interferenz-plus-Rausch-Verhältnis (CINR), additives weißes gaußsches Rauschen (AWGN), Energie-pro-Bit-zu-Rauschleistungsdichte-Verhältnis (Eb/N0), Energie-pro-Bit-zu-Interferenzleistungsdichte-Verhältnis (Ec/10), Spitzenzu-Durchschnittsleistungsverhältnis (PAPR), Referenzsignalempfangsleistung (RSRP), Empfangssignalstärkeindikator (RSSI), Referenzsignalempfangsqualität (RSRQ), GNSS-Timing von Zellenframes zur UE-Positionierung für E-UTRAN oder 5G/NR (z. B. ein Timing zwischen einer AP- oder RAN-Knoten-Referenzzeit und einer GNSS-spezifischen Referenzzeit für ein gegebenes GNSS), GNSS-Code-Messungen (z. B. die GNSS-Code-Phase (ganzzahlige und Bruchteile) des Spreizcodes des i-ten GNSS-Satellitensignals), GNSS-Trägerphasenmessungen (z. B. die Anzahl von Trägerphasenzyklen (ganzzahlige und Bruchteile) des i-ten GNSS-Satellitensignals, gemessen seit dem Erfassen des Signals; auch als akkumulierter Deltabereich (ADR) bezeichnet), Kanalinterferenzmessung, thermische Rauschleistungsmessung, empfangene Interferenzleistungsmessung und/oder andere ähnliche Messungen. Die RSRP-, RSSI- und/oder RSRQ-Messungen können RSRP-, RSSI- und/oder RSRQ-Messungen zellenspezifischer Referenzsignale, Kanalzustandsinformationsreferenzsignale (CSI-RS) und/oder Synchronisationssignale (SS) oder SS-Blöcke für 3GPP-Netzwerke (z. B. LTE oder 5G/NR) und RSRP-, RSSI- und/oder RSRQ-Messungen verschiedener Beacon-, Fast-Initial-Link-Setup(FILS)-Entdeckungsframes oder Sondierungsantwortframes für IEEE 802.11 WLAN/WiFi-Netze beinhalten. Andere Messungen können zusätzlich oder alternativ verwendet werden, wie etwa jene, die in 3GPP TS 36.214 v16.2.0 (2021-03-31) („[TS36214]“), 3GPP TS 38.215 v16.4.0 (2020-12) ( „[TS38215]“), IEEE 802.11-2020, „IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications“ (2021-02-26) („[IEEE80211]“) und/oder dergleichen besprochen sind. Zusätzlich oder alternativ dazu kann eine beliebige der oben erwähnten Messungen (oder Kombination von Messungen) durch ein oder mehrere NANs 1131-1133 gesammelt und an den einen oder die mehreren Edge-Rechenknoten 1136 bereitgestellt werden.
Die Funkinformationen können als Reaktion auf ein Auslöseereignis und/oder periodisch gemeldet werden. Zusätzlich oder alternativ melden einzelne UEs 1121, 1111 Funkinformationen entweder mit einer niedrigen Periodizität oder einer hohen Periodizität in Abhängigkeit von einem Datentransfer, der stattfinden soll, und/oder anderen Informationen über den Datentransfer.
Zusätzlich oder alternativ dazu können der eine oder die mehreren Rechenknoten 1136 die Messungen von den NANs 1131-1133 mit niedriger oder hoher Periodizität anfordern, oder die NANs 1131-1133 können die Messungen dem einen oder den mehreren Edge-Rechenknoten 1136 mit niedriger oder hoher Periodizität bereitstellen. Zusätzlich oder alternativ dazu können der eine oder die mehreren Rechenknoten 1136 andere relevante Daten von einem oder mehreren anderen Edge-Rechenknoten 1136, Kernnetzwerkfunktionen (NFs), Anwendungsfunktionen (AFs) und/oder anderen UEs 1111, 1121, wie etwa Leistungskennzahlen (KPIs), mit den Messberichten oder getrennt von den Messberichten erhalten.
Das UE 1121b ist der Darstellung nach dazu konfiguriert, über eine Verbindung 1107 auf einen Zugangspunkt (AP) 1133 zuzugreifen. In diesem Beispiel ist gezeigt, dass der AP 1133 mit dem Internet verbunden ist, ohne mit dem CN 1142 des Drahtlossystems verbunden zu sein. Die Verbindung 1107 kann eine lokale drahtlose Verbindung umfassen, wie etwa eine Verbindung, die mit einem beliebigen IEEE-802.11-Protokoll übereinstimmt, wobei der AP 1133 einen Wireless-Fidelity(WiFi®)-Router umfassen würde. Zusätzlich oder alternativ dazu können die UEs 1121 und die IoT-Vorrichtungen 1111 dazu ausgelegt sein, unter Verwendung geeigneter Kommunikationssignale miteinander oder mit einem beliebigen der AP 1133 über einen Einzel- oder Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie etwa unter anderem einer orthogonalen Frequenzmultiplex(OFDM)-Technik, einer Einzelträger-Frequenzmultiplex(SC-FDMA)-Kommunikationstechnik und/oder dergleichen, obwohl der Schutzumfang der vorliegenden Offenbarung in dieser Hinsicht nicht beschränkt ist. Die Kommunikationstechnik kann ein geeignetes Modulationssystem wie Complementary Code Keying (CCK); Phasenumtasten (PSK) wie binäres PSK (BPSK), Quadratur-PSK (QPSK), differentielles PSK (DPSK) usw.; oder Quadraturamplitudenmodulation (QAM) wie M-QAM; und/oder dergleichen beinhalten.
Das eine oder die mehreren NANs 1131 und 1132, die Verbindungen 1103 aktivieren, können als „RAN-Knoten“ oder dergleichen bezeichnet werden. Die RAN-Knoten 1131, 1132 können Bodenstationen (z. B. terrestrische Zugangspunkte) oder Satellitenstationen umfassen, die eine Bedeckung innerhalb eines geografischen Gebiets (z. B. einer Zelle) bereitstellen. Die RAN-Knoten 1131, 1132 können als eine dedizierte physische Vorrichtung, wie etwa eine Makrozellenbasisstation, und/oder eine Niederleistungsbasisstation zum Bereitstellen von Femtozellen, Pikozellen oder anderen ähnlichen Zellen mit kleineren Bedeckungsgebieten, kleineren Benutzerkapazitäten oder höheren Bandbreiten im Vergleich zu Makrozellen implementiert sein. In diesem Beispiel ist der RAN-Knoten 1131 als ein NodeB, erweiterter NodeB (eNB) oder ein NodeB der nächsten Generation (gNB) umgesetzt, und die RAN-Knoten 1132 sind als Relaisknoten, verteilte Einheiten oder Straßenrandeinheiten (RSUs) umgesetzt. Eine beliebige andere Art von NANs kann verwendet werden.
Jeder der RAN-Knoten 1131, 1132 kann das Luftschnittstellenprotokoll abschließen und kann der erste Kontaktpunkt für die UEs 1121 und die IoT-Vorrichtungen XE111 sein. Zusätzlich oder alternativ dazu kann jeder der RAN-Knoten 1131, 1132 verschiedene logische Funktionen für das RAN erfüllen, einschließlich unter anderem eine oder mehrere RAN-Funktionen (z. B. Funknetzwerksteuerungs(RNC)-Funktionen und/oder NG-RAN-Funktionen) für Funkressourcenverwaltung, Zulassungssteuerung, dynamische Uplink- und Downlink-Ressourcenzuweisung, Funkträgerverwaltung, Datenpaketplanung usw. Zusätzlich oder alternativ dazu können die UEs 1111, 1121 dazu ausgelegt sein, unter Verwendung von OFDM-Kommunikationssignalen miteinander oder mit einem beliebigen der NANs 1131, 1132 über einen Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie etwa unter anderem einer OFDM-Kommunikationtsechnik (z. B. für Downlink-Kommunikationen) und/oder einer SC-FDMA-Kommunikationstechnik (z. B. für Uplink- und ProSe- oder Sidelink-Kommunikationen), obwohl der Schutzumfang der vorliegenden Offenbarung in dieser Hinsicht nicht beschränkt ist.
Für die meisten Mobilfunkkommunikationssysteme organisieren die eine oder die mehreren RAN-Funktionen, die durch das RAN oder einzelne NANs 1131-1132 betrieben werden, Downlink-Übertragungen (z. B. von einem beliebigen der RAN-Knoten 1131, 1132 zu den UEs 1111, 1121) und Uplink-Übertragungen (z. B. von den UEs 1111, 1121 zu RAN-Knoten 1131, 1132) in Funkframes (oder einfach „Frames“) mit einer Dauer von 10 Millisekunden (ms), wobei jeder Frame zehn 1-ms-Subframes beinhaltet. Jede Übertragungsrichtung weist ihr eigenes Ressourcenraster aufweist, das physikalische Ressourcen in jedem Schlitz anzeigt, wobei jede Spalte und jede Zeile eines Ressourcenrasters einem Symbol bzw. einem Unterträger entspricht. Die Dauer des Ressourcenrasters im Zeitbereich entspricht einem Schlitz in einem Funkframe. Die Ressourcenraster umfassen eine Reihe von Ressourcenblöcken (RBs), die eine Abbildung bestimmter physischer Kanäle auf Ressourcenelemente (REs) beschreiben. Jeder RB kann ein physikalischer RB (PRB) oder ein virtueller RB (VRB) sein und umfasst eine Sammlung von REs. Ein RE ist die kleinste Zeit-Frequenz-Einheit in einem Ressourcenraster. Die eine oder die mehreren RNC-Funktionen weisen jedem UE 1111, 1121 in jedem Übertragungszeitintervall (TTI) Ressourcen (z. B. PRBs und Modulations- und Codierungsschemata (MCS)) dynamisch zu. Ein TTI ist die Dauer einer Übertragung auf einer Funkverknüpfung 1103, 1105 und bezieht sich auf die Größe der Datenblöcke, die von höheren Netzwerkschichten an die Funkverknüpfungsschicht weitergeleitet werden.
Die NANs 1131/1132 können dazu ausgelegt sein, über jeweilige Schnittstellen oder Verknüpfungen (nicht gezeigt) miteinander zu kommunizieren, wie etwa eine X2-Schnittstelle für LTE-Implementierungen (z. B., wenn das CN 1142 ein Evolved Packet Core (EPC) ist), eine Xn-Schnittstelle für 5G-oder NR-Implementierungen (z. B., wenn das CN 1142 ein Kern der fünften Generation (5GC) ist) oder dergleichen. Die NANs 1131 und 1132 sind auch kommunikativ mit dem CN 1142 gekoppelt. Zusätzlich oder alternativ kann das CN 1142 ein EPC-Netzwerk (Evolved Packet Core), ein NPC-Netzwerk (NextGen Packet Core), ein 5G-Kernnetz (5GC-Netz) oder eine andere Art von CN sein. Das CN 1142 kann eine Vielzahl von Netzwerkelementen umfassen, die dazu ausgelegt sind, Verbrauchern/Teilnehmern (z. B. Benutzern von UEs 1121 und IoT-Vorrichtungen 1111), die über ein RAN mit dem CN 1142 verbunden sind, verschiedene Daten- und Telekommunikationsdienste anzubieten. Die Komponenten des CN 1142 können in einem physischen Knoten oder separaten physischen Knoten implementiert sein, einschließlich Komponenten zum Lesen und Ausführen von Anweisungen von einem maschinenlesbaren oder computerlesbaren Medium (z. B. einem nichttransitorischen maschinenlesbaren Speichermedium). Zusätzlich oder alternativ kann eine Netzwerkfunktionsvirtualisierung (NFV) genutzt werden, um eine oder alle der vorstehend beschriebenen Netzwerkknotenfunktionen über ausführbare Anweisungen, die in einem oder mehreren computerlesbaren Speichermedien gespeichert sind (nachstehend ausführlicher beschrieben), zu virtualisieren. Eine logische Instanziierung des CN 1142 kann als ein Netzwerksegment bezeichnet werden und eine logische Instanziierung eines Teils des CN 1142 kann als ein Netzwerk-Subsegment bezeichnet werden. NFV-Architekturen und - Infrastrukturen können verwendet werden, um eine oder mehrere Netzwerkfunktionen, die alternativ durch proprietäre Hardware durchgeführt werden, auf physischen Ressourcen zu virtualisieren, die eine Kombination aus Industriestandard-Serverhardware, Speicherhardware oder Switches umfassen. Anders ausgedrückt können NFV-Systeme verwendet werden, um virtuelle oder rekonfigurierbare Implementierungen einer oder mehrerer Komponenten/Funktionen des CN 1142 auszuführen.
Das CN 1142 ist als kommunikativ mit einem Anwendungsserver 1150 und einem Netzwerk 1150 über eine IP-Kommunikationsschnittstelle 1155 gekoppelt gezeigt. Der eine oder die mehreren Server 1150 umfassen ein oder mehrere physische und/oder virtualisierte Systeme zum Bereitstellen von Funktionalität (oder Diensten) an einen oder mehrere Clients (z. B. die UEs 1121 und IoT-Vorrichtungen 1111) über ein Netzwerk. Der eine oder die mehreren Server 1150 können verschiedene Computervorrichtungen mit einer oder mehreren Rack-Rechenarchitekturkomponenten, Turm-Rechenarchitekturkomponenten, Blade-Rechenarchitekturkomponenten und/oder dergleichen beinhalten. Der eine oder die mehreren Server 1150 können ein Cluster von Servern, eine Serverfarm, einen Cloud-Rechendienst oder eine andere Gruppierung oder einen anderen Serverbestand darstellen, die sich in einem oder mehreren Datenzentren befinden können. Der eine oder die mehreren Server 1150 können auch mit einer oder mehreren Datenspeicherungsvorrichtungen (nicht gezeigt) verbunden oder anderweitig mit diesen assoziiert sein. Darüber hinaus können der eine oder die mehreren Server 1150 ein Betriebssystem (OS) beinhalten, das ausführbare Programmanweisungen für die allgemeine Verwaltung und den allgemeinen Betrieb der einzelnen Servercomputervorrichtungen bereitstellt, und können ein computerlesbares Medium beinhalten, das Anweisungen speichert, die, wenn sie durch einen Prozessor der Server ausgeführt werden, den Servern ermöglichen können, ihre beabsichtigten Funktionen durchzuführen. Geeignete Implementierungen für das OS und die allgemeine Funktionalität von Servern sind bekannt oder kommerziell erhältlich und werden von Durchschnittsfachleuten leicht implementiert. Allgemein bieten der eine oder die mehreren Server 1150 Anwendungen oder Dienste an, die IP/Netzwerkressourcen verwenden. Als Beispiele können der eine oder die mehreren Server 1150 Verkehrsverwaltungsdienste, Cloud-Analytik, Inhalts-Streaming-Dienste, immersive Spielerfahrungen, soziales Networking und/oder Mikroblogging-Dienste und/oder andere ähnliche Dienste bereitstellen. Zusätzlich dazu können die verschiedenen Dienste, die durch den einen oder die mehreren Server 1150 bereitgestellt werden, Initiieren und Steuern von Software- und/oder Firmware-Aktualisierungen für Anwendungen oder einzelne Komponenten, die durch die UEs 1121 und IoT-Vorrichtungen 1111 implementiert werden, beinhalten. Der eine oder die mehreren Server 1150 können zudem dazu konfiguriert sein, einen oder mehrere Kommunikationsdienste (z. B. Voice-over-Internet Protocol (VoIP)-Sitzungen, PTT-Sitzungen, Gruppenkommunikationssitzungen, soziale Netzwerkdienste usw.) für die UEs 1121 und IoT-Vorrichtungen 1111 über das CN 1142 zu unterstützen.
Die Funkzugangstechnologien (RATs), die von den NANs 1131-1133, den UEs 1121, 1111 und den anderen Elementen in 11 eingesetzt werden, können eine oder mehrere V2X-RATs beinhalten, die diesen Elementen ermöglichen, direkt miteinander, mit Infrastrukturgeräten (z. B. den NANs 1131-1133) und anderen Vorrichtungen zu kommunizieren. Eine beliebige Anzahl von V2X-RATs kann für V2X-Kommunikation verwendet werden. Bei manchen Implementierungen können mindestens zwei unterschiedliche V2X-RATs verwendet werden, einschließlich WLAN-V2X(W-V2X)-RAT basierend auf IEEE V2X-Technologien (z. B. DSRC für die USA und ITS-G5 für Europa) und 3GPP C-V2X-RAT (z. B. LTE, 5G/NR und darüber hinaus).
Die W-V2X-RATs beinhalten zum Beispiel IEEE 1609.0-2019, „IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture“ (2019-04-10) („[IEEE16090]“), SAE Int'1, „V2X Communications Message Set Dictionary“ (früher „Dedicated Short Range Communication (DSRC) Message Set Dictionary“) (2020-07-23) („[J2735_202007]“), Intelligente Transportsysteme im 5-GHz-Frequenzband (ITS-G5), das IEEE 802.11p-Protokoll (das der Teil der Schicht 1 (L1) und Schicht 2 (L2) von WAVE, DSRC und ITS-G5 ist) und mitunter IEEE 802.16-2017, „IEEE Standard for Air Interface for Broadband Wireless Access Systems“ (mitunter als „Worldwide Interoperability for Microwave Access“ oder „WiMAX“ bezeichnet) (2018-03-02) („[WiMAX]“). Der Begriff „DSRC“ betrifft Fahrzeugkommunikationen im 5,9-GHz-Frequenzband, das im Allgemeinen in den Vereinigten Staaten verwendet wird, während „ITS-G5“ Fahrzeugkommunikationen im 5,9-GHz-Frequenzband in Europa betrifft. Da eine beliebige Anzahl unterschiedlicher RATs anwendbar ist (einschließlich IEEE 802.11p-basierter RATs), die in einem beliebigen geografischen oder politischen Gebiet verwendet werden können, können die Begriffe „DSRC“ (unter anderen Gebieten in den USA verwendet) und „ITS-G5“ (unter anderen Gebieten in Europa verwendet) durch diese Offenbarung hindurch austauschbar verwendet werden. Die Zugangsschicht für die ITS-G5-Schnittstelle ist in ETSI EN 302 663 V1.3.1 (2020-01) (im Folgenden „[EN302663]“) umrissen und beschreibt die Zugangsschicht der ITS-S-Referenzarchitektur. Die ITS-G5-Zugangsschicht umfasst (die nun IEEE 802.11p beinhaltet) und IEEE 802.2 Logical Link Control (LLC) („[IEEE8022]“) und/oder IEEE/ISO/IEC 8802-2-1998-Protokolle sowie Merkmale für Decentralized-Congestion-Control-Verfahren (DCC-Verfahren), die in ETSI TS 102 687 V1.2.1 (2018-04) („[TS102687]“) erörtert sind. Die Zugangsschicht für eine oder mehrere 3GPP LTE-V2X-basierte Schnittstellen ist unter anderem in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS 23.285 v16.2.0 (2019-12) umrissen; und 3GPP 5G/NR-V2X ist unter anderem in 3GPP TR 23.786 v16.1.0 (2019-06) und 3GPP TS 23.287 v16.2.0 (2020-03) umrissen.
Die Cloud 1144 kann eine Cloud-Rechenarchitektur/-Plattform darstellen, die einen oder mehrere Cloud-Rechendienste bereitstellt. Cloud-Computing bezieht sich auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Bestand von gemeinsam nutzbaren Rechenressourcen mit Selbstbedienungsbereitstellung und -verwaltung bei Bedarf und ohne aktives Management durch Benutzer. Rechenressourcen (oder einfach „Ressourcen“) sind eine beliebige physische oder virtuelle Komponente oder Verwendung solcher Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Ressourcen beinhalten Nutzung/Zugriff auf Server, Prozessor(en), Speicherungsgeräte, Speichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, Eingabe/Ausgabe(Peripherie)-Vorrichtungen, mechanische Vorrichtungen, Netzwerkverbindungen (z. B. Kanäle/Verknüpfungen, Anschlüsse, Netzwerksockel usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen. Cloud-Computing stellt Cloud-Rechendienste (oder Cloud-Dienste) bereit, bei denen es sich um eine oder mehrere über Cloud-Computing angebotene Fähigkeiten handelt, die unter Verwendung einer definierten Schnittstelle (z. B. einer API oder dergleichen) aufgerufen werden. Manche Fähigkeiten der Cloud 1144 beinhalten einen Anwendungsfähigkeitentyp, Infrastrukturfähigkeitentyp und Plattformfähigkeitentyp. Ein Cloud-Fähigkeitentyp ist eine Klassifizierung der Funktionalität, die einem Cloud-Dienstkunden (z. B. einem Benutzer der Cloud 1144) durch einen Cloud-Dienst bereitgestellt wird, basierend auf den verwendeten Ressourcen. Der Anwendungsfähigkeitentyp ein Cloud-Fähigkeitentyp ist, bei dem der Cloud-Dienstkunde die Anwendungen des Cloud-Dienstanbieters verwenden kann; der Infrastrukturfähigkeitentyp ist ein Cloud-Fähigkeitentyp, bei dem der Cloud-Dienstkunde Verarbeitungs-, Speicherungs- oder Vernetzungsressourcen bereitstellen und verwenden kann; und der Plattformfähigkeitentyp ist ein Cloud-Fähigkeitentyp, bei dem der Cloud-Dienstkunde vom Kunden erstellte oder vom Kunden erworbene Anwendungen unter Verwendung einer oder mehrerer Programmiersprachen und einer oder mehrerer Ausführungsumgebungen, die vom Cloud-Dienstanbieter unterstützt werden, einsetzen, verwalten und ausführen kann. Cloud-Dienste können in Kategorien gruppiert werden, die eine gemeinsame Gruppe von Qualitäten besitzen. Manche Cloud-Dienstkategorien, die die Cloud 1144 bereitstellen kann, beinhalten zum Beispiel:
Kommunikation-as-a-Service (CaaS), was eine Cloud-Dienstkategorie ist, die Echtzeitinteraktions- und -kollaborationsdienste beinhaltet; Computing-as-a-Service (CompaaS), was eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Verarbeitungsressourcen beinhaltet, die benötigt werden, um Software einzusetzen und auszuführen; Datenbank-as-a-Service (DaaS), was eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Datenbanksystemverwaltungsdiensten involviert; Datenspeicherung-as-a-Service (DSaaS), was eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Datenspeicherung und verwandten Fähigkeiten involviert; Firewall-as-a-Service (FaaS), was eine Cloud-Dienstkategorie ist, die die Bereitstellung von Firewall- und Netzwerkverkehrsverwaltungsdiensten involviert; Infrastruktur-as-a-Service (IaaS), was eine Cloud-Dienstkategorie ist, die einen Infrastrukturfähigkeitentyp beinhaltet; Netzwerk-as-a-Service (NaaS), was eine Cloud-Dienstkategorie ist, die Transportkonnektivität und verwandte Netzwerkfähigkeiten beinhaltet; Plattform-as-a-Service (PaaS), was eine Cloud-Dienstkategorie ist, die den Plattformfähigkeitentyp involviert; Software-as-a-Service (SaaS), was eine Cloud-Dienstkategorie ist, die den Anwendungsfähigkeitentyp involviert; Sicherheitas-a-Service, was eine Cloud-Dienstkategorie ist, die das Bereitstellen von Netzwerk- und Informationssicherheitsdiensten (Infosec) beinhaltet; und/oder andere ähnliche Cloud-Dienste.
Zusätzlich oder alternativ kann die Cloud 1144 ein Netzwerk darstellen, wie etwa das Internet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), ein drahtloses lokales Netzwerk (WLAN) oder ein drahtloses Weitverkehrsnetzwerk (WWAN), einschließlich proprietärer und/oder Unternehmensnetzwerke für eine Firma oder Organisation oder Kombinationen davon.
Hier beinhaltet die Cloud 1144 ein oder mehrere Netzwerke, die Computer, Netzwerkverbindungen zwischen den Computern und Softwareroutinen zum Ermöglichen einer Kommunikation zwischen den Computern über Netzwerkverbindungen umfassen. In dieser Hinsicht umfasst die Cloud 1144 ein oder mehrere Netzwerkelemente, die einen oder mehrere Prozessoren, Kommunikationssysteme (z. B. einschließlich Netzwerkschnittstellensteuerungen, eines oder mehrerer Sender/Empfänger, die mit einer oder mehreren Antennen verbunden sind usw.) und computerlesbare Medien beinhalten können. Beispiele für derartige Netzwerkelemente können drahtlose Zugangspunkte (WAPs), Heim-/Geschäftsserver (mit oder ohne HF-Kommunikationsschaltungsanordnung), Router, Switches, Hubs, Funk-Beacons, Basisstationen, Pikozellen- oder Kleinzellenbasisstationen, Backbone-Gateways und/oder eine beliebige andere ähnliche Netzwerkvorrichtung beinhalten. Eine Verbindung mit der Cloud 1144 kann über eine drahtgebundene oder eine drahtlose Verbindung unter Verwendung der verschiedenen im Folgenden erörterten Kommunikationsprotokolle erfolgen. Mehr als ein Netzwerk kann an einer Kommunikationssitzung zwischen den veranschaulichten Vorrichtungen beteiligt sein. Eine Verbindung mit der Cloud 1144 kann erfordern, dass die Computer Softwareroutinen ausführen, die zum Beispiel die sieben Schichten des OSI-Modells einer Computervernetzung oder eines Äquivalents in einem drahtlosen (Mobilfunk-)Telefonnetzwerk ermöglichen. Die Cloud 1144 kann verwendet werden, um eine Kommunikation mit relativ großer Reichweite, wie etwa zum Beispiel zwischen dem einen oder den mehreren Servern 1150 und einem oder mehreren UEs 1121 und IoT-Vorrichtungen 1111, zu ermöglichen. Zusätzlich oder alternativ dazu kann die Cloud 1144 das Internet, ein oder mehrere Mobilfunknetzwerke, lokale Netzwerke oder Weitverkehrsnetzwerke einschließlich proprietärer und/oder Unternehmensnetzwerke, eines TCP/Internetprotokoll (IP)-basierten Netzwerks oder Kombinationen davon darstellen. Bei diesen Implementierungen kann die Cloud 1144 mit einem Netzwerkbetreiber assoziiert sein, der Geräte und andere Elemente besitzt oder steuert, die notwendig sind, um netzwerkbezogene Dienste bereitzustellen, wie etwa eine oder mehrere Basisstationen oder Zugangspunkte, einen oder mehrere Server zum Leiten digitaler Daten oder Telefonanrufe (z. B. ein Kernnetz oder Backbone-Netzwerk) usw. Die Backbone-Verknüpfungen 1155 können eine beliebige Anzahl drahtgebundener oder drahtloser Technologien beinhalten und können Teil eines LAN, eines WAN oder des Internets sein. In einem Beispiel sind die Backbone-Verknüpfungen 1155 Backbone-Faserverknüpfungen, die niedrigere Ebenen von Dienstanbietern mit dem Internet, wie etwa dem CN 1112 und der Cloud 1144, koppeln.
Zusätzlich oder alternativ können die verschiedenen Zugangstechnologien Mobilfunktechnologie, wie LTE, MuLTEfire und/oder NR/5G (wie z. B. von Funkzugangsnetzwerkknoten (RAN-Knoten) 1131-1132 bereitgestellt), WLAN-(z. B. WiFi®- )Technologien (wie z.B. von einem Zugangspunkt (AP) 1133 bereitgestellt) und/oder dergleichen umfassen. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistung in unterschiedlichen Szenarien hängt von der Auswahl der Zugangsnetzwerke (z. B. WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokolle (z. B. Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) ab.
Die Edge-Rechenknoten 1136 können ein Edge-System 1135 (oder Edge-Netzwerk 1135) umfassen oder Teil davon sein. Die Edge-Rechenknoten 1136 können auch als „Edge-Hosts 1136“ oder „Edge-Server 1136“ bezeichnet werden. Das Edge-System 1135 umfasst eine Sammlung von Edge-Servern 1136 (z. B. MEC-Hosts/Servern 1136-1 und 1136-2 von Figur XP1) und Edge-Verwaltungssystemen (in 11 nicht dargestellt), die notwendig sind, um Edge-Rechenanwendungen (z. B. MEC-Anwendungen XP136 von Figur XP1) innerhalb eines Betreibernetzwerks oder einer Teilmenge eines Betreibernetzwerks auszuführen. Die Edge-Server 1136 sind physische Computersysteme, die eine Edge-Plattform (z. B. MEC-Plattform XP137 von Figur XP1) und/oder Virtualisierungsinfrastruktur (z. B. VI XP138 von Figur XP1) umfassen und Rechen-, Speicher- und Netzwerkressourcen für Edge-Rechenanwendungen bereitstellen können. Jeder der Edge-Server 1136 ist an einem Rand eines entsprechenden Zugangsnetzwerks angeordnet und dazu eingerichtet, Rechenressourcen und/oder verschiedene Dienste (z. B. Rechenaufgaben- und/oder Arbeitslastauslagerung, Cloud-Rechenfähigkeiten, IT-Dienste und andere ähnliche Ressourcen und/oder Dienste, wie hierin erörtert) in relativ enger Nähe zu Zwischenknoten 1120 und/oder Endpunkten 1110 bereitzustellen. Die VI der Edge-Server 1136 stellen virtualisierte Umgebungen und virtualisierte Ressourcen für die Edge-Hosts bereit, und die Edge-Rechenanwendungen können als VMs und/oder Anwendungscontainer auf den VI laufen. Eine beispielhafte Implementierung des Edge-Systems 1135 ist ein MEC-System 1135, das im Folgenden mit Bezug auf die Figuren XP1-XP2 ausführlicher erörtert wird. Es versteht sich, dass die offenbarten MEC-Systeme und Dienstbereitstellungsbeispiele nur ein veranschaulichendes Beispiel von Edge-Rechensystemen/-netzwerken 1135 sind, und dass die vorliegende Offenbarung auf viele andere Edge-Rechen-/-Netzwerktechnologien in verschiedenen Kombinationen und Anordnungen von Vorrichtungen anwendbar sein kann, die sich am Rand eines Netzwerks befinden, einschließlich der verschiedenen Edge-Rechennetzwerke/-Systeme, die hierin beschrieben sind. Ferner können sich die hier offenbarten Techniken auf andere IoT-Edge-Netzwerksysteme und -Konfigurationen beziehen, und es können auch andere Zwischenverarbeitungsentitäten und Architekturen auf die vorliegende Offenbarung anwendbar sein.
Wie durch 11 dargestellt, ist jeder der NANs 1131, 1132 und 1133 ortsgleich mit den Edge-Rechenknoten (oder „Edge-Servern“) 1136a, 1136b bzw. 1136c angeordnet. Diese Implementierungen können Kleinzellen-Clouds (SCCs) sein, bei denen ein Edge-Rechenknoten 1136 ortsgleich mit einer Kleinzelle (z. B. Pikozelle, Femtozelle usw.) angeordnet ist, oder sie können mobile Mikro-Clouds (MCCs) sein, bei denen ein Edge-Rechenknoten 1136 ortsgleich mit einer Makrozelle (z. B. einem eNB, gNB usw.) angeordnet ist. Der Edge-Rechenknoten 1136 kann in einer Vielzahl anderer Anordnungen als der in 11 gezeigten bereitgestellt werden. In einem ersten Beispiel sind mehrere NANs 1131-1133 ortsgleich mit einem Edge-Rechenknoten 1136 angeordnet oder anderweitig damit kommunikativ gekoppelt. In einem zweiten Beispiel können die Edge-Server 1136 ortsgleich angeordnet sein oder durch RNCs betrieben werden, was für Alt-Netzwerkbereitstellungen, wie etwa 3G-Netzwerke, der Fall sein kann. In einem dritten Beispiel können die Edge-Server 1136 an Zellenaggregationsstellen oder an Multi-RAT-Aggregationspunkten eingesetzt werden, die sich entweder innerhalb eines Unternehmens befinden oder in öffentlichen Bedeckungsgebieten befinden können. In einem vierten Beispiel können die Edge-Server 1136 am Rand des CN 1142 bereitgestellt werden. Diese Implementierungen können in Follow-Me-Clouds (FMC) verwendet werden, wobei Cloud-Dienste, die an verteilten Rechenzentren laufen, den UEs 1121 folgen, während sie durch das Netzwerk roamen.
Bei beliebigen der hierin besprochenen Implementierungen stellen die Edge-Server 1136 eine verteilte Rechenumgebung für Anwendungs-und Diensthosting bereit und stellen auch Speicherungs- und Verarbeitungsressourcen bereit, sodass Daten und/oder Inhalte in unmittelbarer Nähe zu Teilnehmern (z. B. Benutzern von UEs 1121, 1111) für schnellere Antwortzeiten verarbeitet werden können. Die Edge-Server 1136 unterstützen auch eine oder mehrere Multi-Mandanten-Laufzeit- und Hosting-Umgebungen für Anwendungen, einschließlich virtueller Geräteanwendungen, die unter anderem als verpackte Abbilder einer virtuellen Maschine (VM), Middleware-Anwendungs- und Infrastrukturdienste, Inhaltslieferdienste einschließlich Zwischenspeichern von Inhalten, mobile Massendatenanalytik und rechnerisches Abladen geliefert werden können. Das Auslagern von Berechnungen involviert das Auslagern von Berechnungen, Arbeitslasten, Anwendungen und/oder Diensten von den UEs 1111/1121, dem CN 1142, der Cloud 1144 und/oder dem oder den Servern 1150 auf die Edge-Server 1136 oder umgekehrt. Zum Beispiel kann eine Vorrichtungsanwendung oder Client-Anwendung, die in einem UE 1121, 1111 betrieben wird, Anwendungsaufgaben oder Arbeitslasten an einen oder mehrere Edge-Server 1136 auslagern. Bei einem anderen Beispiel kann ein Edge-Server 1136 Anwendungsaufgaben oder Arbeitslasten an ein oder mehrere UEs 1121, 1111 auslagern (zum Beispiel für verteilte ML-Berechnung oder dergleichen).
12 ist ein Blockdiagramm 1200, das einen Überblick über eine Konfiguration für Edge-Rechnen zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als eine „Edge-Cloud“ bezeichnet wird. Wie gezeigt befindet sich die Edge-Cloud 1210 gemeinsam an einem Edge-Standort, wie einem Netzwerkzugangsknoten (NAN) 1240 (z. B. einem Zugangspunkt oder einer Basisstation), einem lokalen Verarbeitungs-Hub 1250 oder einer Zentrale 1220, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 1210 befindet sich viel näher an den EndpunktDatenquellen 1260 (Verbraucher und Erzeuger) (z. B. autonome Fahrzeuge 1261, Endgerät 1262, Geschäfts- und Industriegerät 1263, Videoaufnahmevorrichtungen 1264, Drohnen 1265, Vorrichtungen für Smart Cities und Buildings 1266, Sensoren und IoT-Vorrichtungen 1267 usw.) als das Cloud-Rechenzentrum 1230. Rechen-, Speicher- und Speicherungsressourcen, die an den Edges in der Edge-Cloud 1210 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 1260 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 1210 zum Cloud-Rechenzentrum 1230, wodurch Energieverbrauch und Gesamtnetzwerknutzungen verbessert werden, unter anderen Vorteilen.
Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (wobei z. B. weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen verfügbar sind als an einer Basisstation, als an einer Zentrale). Je näher sich der Edge-Standort jedoch am Endpunkt (z. B. Endgerät (UE)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Rechnen die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen zu reduzieren, die sich sowohl geografisch als auch in der Netzwerkzugriffszeit näher befinden. Auf diese Weise versucht Edge-Rechnen, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere potenzielle Bereitstellungen abdeckt und Einschränkungen behandelt, die manche Netzbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten: Konfigurationsschwankungen basierend auf dem Edge-Standort (weil Edges auf Basisstationsebene zum Beispiel mehr eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art der Berechnung, des Speichers, der Speicherung, der Fabric, der Beschleunigung oder ähnlicher Ressourcen, die Edge-Standorten, Ebenen von Standorten oder Gruppen von Standorten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und verwandte Ziele zum Erreichen einer Nutzbarkeit und Leistung von Enddiensten. Diese Bereitstellungen können ein Verarbeiten in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Zeitgebungsmerkmalen als „Near Edge“-, „Close Edge“-, „Local Edge“-, „Middle Edge“- oder „Far Edge“-Schichten betrachtet werden können.
Edge-Rechnen ist ein sich entwickelndes Paradigma, bei dem die Berechnung an oder näher am „Rand“ eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer angemessen angeordneten Rechenplattform (z. B. x86-, ARM-, Nvidia- oder einer anderen CPU/GPU-basierten Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die sich viel näher an Endpunktvorrichtungen befinden, die Daten erzeugen und verbrauchen. Beispielsweise können Edge-Gatewayserver mit Beständen von Arbeitsspeicher- und Speicherungsressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Anwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für angebundene Client-Vorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für angebundene Endgeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Oder als weiteres Beispiel kann zentrale Büronetzwerkverwaltungshardware durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucheranwendungen für angebundene Vorrichtungen bietet. Alternativ kann auch eine Anordnung mit Hardware kombiniert mit virtualisierten Funktionen, allgemein als Hybrid-Anordnung bezeichnet, erfolgreich implementiert werden. Innerhalb von Edge-Rechennetzen kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien geben, in denen die Daten zur Rechenressource „verschoben“ werden. Oder als ein Beispiel können Basisstationsberechnungs-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf durch Aktivieren ruhender Kapazität (Subskription, bedarfsgesteuerte Kapazität) zu skalieren, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
13 veranschaulicht Betriebsschichten unter Endpunkten, eine Edge-Cloud und Cloud-Rechenumgebungen. Insbesondere stellt 13 Beispiele für Rechenanwendungsfälle 1305 dar, die die Edge-Cloud 1210 unter mehreren veranschaulichenden Schichten der Netzwerkberechnung nutzen. Die Schichten beginnen an einer Endpunkt-Schicht (Vorrichtungen und Dinge) 1300, die auf die Edge-Cloud 1210 zugreift, um Datenerzeugungs- , Analyse- und Datenverbrauchsaktivitäten durchzuführen. Die Edge-Cloud 1210 kann mehrere Netzwerkschichten umspannen, wie etwa eine Edge-Vorrichtungsschicht 1310 mit Gateways, Servern vor Ort oder Netzwerkgeräten (Knoten 1315), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 1320, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionale Rechenzentren (DC) oder lokale Netzwerkgeräte (Geräte 1325); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 1312, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 1210 und inmitten der verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
Beispiele für Latenz, die aus Netzwerkkommunikationsdistanz- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn inmitten der Endpunktschicht 1300, unter 5 ms an der Edge-Vorrichtungsschicht 1310, bis sogar zwischen 10 und 40 ms reichen, wenn mit Knoten an der Netzwerkzugangsschicht 1320 kommuniziert wird. Jenseits der Edge-Cloud 1210 befinden sich Schichten des Kernnetzes 1330 und des Cloud-Rechenzentrums 1340, jeweils mit zunehmender Latenz (z. B. zwischen 50-60 ms an der Kernnetzschicht 1330, bis 100 oder mehr ms an der Cloud-Rechenzentrumsschicht). Infolgedessen werden Operationen in einem Kernnetz-Rechenzentrum 1335 oder einem Cloud-Rechenzentrum 1345 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Anwendungsfälle 1305 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. In manchen Beispielen können jeweilige Abschnitte des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als Schichten „Close Edge“, „Local Edge“, „Near Edge“, „Middle Edge“ oder „Far Edge“ kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetz-Rechenzentrums 1335 oder eines Cloud-Rechenzentrums 1345 ein Zentralen- oder Inhaltsdatennetzwerk als innerhalb einer „Near Edge“-Schicht („nahe“ an der Cloud, mit hohen Latenzwerten beim Kommunizieren mit den Vorrichtungen und Endpunkten der Anwendungsfälle 1305) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Server vor Ort oder ein Netzwerk-Gateway als innerhalb einer „Far Edge“-Schicht („fern“ von der Cloud entfernt, mit niedrigen Latenzwerten beim Kommunizieren mit den Vorrichtungen und Endpunkten der Anwendungsfälle 1305) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als eine „Close“, „Local“, „Near“, „Middle“ oder „Far“ Edge bildend auf Latenz, Entfernung, Anzahl von Netzwerksprüngen oder anderen messbaren Charakteristiken basieren können, wie von einer Quelle in einer beliebigen der Netzwerkschichten 1300-1340 gemessen.
Die diversen Anwendungsfälle 1305 können auf Ressourcen unter Nutzungsdruck von eingehenden Strömen aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 1210 ausgeführt werden, variierende Anforderungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS) (z. B. Verkehr für ein autonomes Fahrzeug kann hinsichtlich der Antwortzeitanforderung eine höhere Priorität als ein Temperatursensor aufweisen; oder eine Leistungsfähigkeitsempfindlichkeit/ein Leistungsfähigkeitsengpass kann an einer Rechen-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource in Abhängigkeit von der Anwendung existieren); (b) Zuverlässigkeit und Widerstandsfähigkeit (z. B. müssen manche Eingangsströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wohingegen manche anderen Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physikalische Beschränkungen (z. B. Leistung, Kühlung und Formfaktor).
Die Ende-zu-Ende-Dienstansicht für diese Anwendungsfälle beinhaltet den Begriff eines Dienstflusses und ist einer Transaktion zugeordnet. Die Transaktion gibt die Gesamtdienstanforderung für die Entität an, die den Dienst verbraucht, sowie die zugehörigen Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Geschäftsfunktions- und Geschäftsebenenanforderungen. Die Dienste, die mit den beschriebenen „Bedingungen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, sodass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihre vereinbarte SLA verfehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten im System zu erweitern, um die Gesamttransaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
Dementsprechend kann unter Berücksichtigung dieser Abweichungen und Dienstmerkmale Edge-Rechnen innerhalb der Edge-Cloud 1210 die Fähigkeit bereitstellen, mehrere Anwendungen der Anwendungsfälle 1305 (z. B. Objektverfolgung, Videoüberwachung, angebundene Fahrzeuge usw.) in Echtzeit oder nahezu Echtzeit zu bedienen und auf diese zu reagieren und Anforderungen in Bezug auf ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (virtuelle Netzwerkfunktionen (VNFs), Funktion-as-a-Service (FaaS), Edge-as-a-Service (EaaS), Standardprozesse usw.), die herkömmliches Cloud-Computing aufgrund von Latenz- oder anderen Einschränkungen nicht nutzen können.
Bei den Vorteilen des Edge-Rechnens gibt es jedoch die folgenden Vorbehalte. Die an der Edge befindlichen Geräte sind häufig ressourcenbeschränkt, und deshalb besteht Druck auf die Nutzung von Edge-Ressourcen. Typischerweise wird dies durch das Zusammenfassen von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Die Edge kann in Leistung und Kühlung eingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen berücksichtigt werden muss, die die meiste Leistung verbrauchen. Es kann inhärente Leistungs-Leistungsfähigkeits-Kompromisse in diesen gebündelten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen für mehr Leistung eine größere Speicherbandbreite notwendig ist. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Funktionen mit Stammvertrauenstellung ebenfalls erforderlich, da Edge-Standorte unbemannt sein können und sogar genehmigten Zugriff benötigen können (z. B. wenn sie an einem Standort von Drittanbietern untergebracht sind). Derartige Probleme werden in der Edge-Cloud 1210 in einer Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffssituation vergrößert, bei der Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere, da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Beteiligten, Anwendungsfälle und Dienste ändert.
Auf einer mehr generischen Ebene kann ein Edge-Rechensystem so beschrieben werden, dass es eine beliebige Anzahl von Bereitstellungen in den zuvor besprochenen Schichten umfasst, die in der Edge-Cloud 1210 arbeiten (Netzwerkschichten 1300-1340), die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gatewayknoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kernrechenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), eines Internet-der-Dinge-Dienstanbieters, eines Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Rechensystems können dynamisch bereitgestellt werden, wie zum Beispiel, bei Orchestrierung, um Dienstziele zu erfüllen.
Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -vorrichtung, -gerät oder anderem Ding ausgebildet sein, die bzw. das fähig ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Hier bezieht sich ein „Produzent“ auf eine Entität oder ein Element, die/das andere Entitäten oder Elemente auf demselben Randknoten oder auf unterschiedlichen Randknoten einen Dienst bereitstellt, und ein „Verbraucher“ bezieht sich auf eine Entität oder ein Element, die/das Endbenutzerverkehr und/oder Benutzerdienste von einem Produzenten auf demselben oder unterschiedlichen Randknoten verbrauchen kann. Zum Beispiel kann eine Erzeuger-App Standortdienste, Abbildungsdienste, Transcodierungsdienste, KI/ML-Dienste und/oder andere ähnliche Dienste bereitstellen. Zusätzlich oder alternativ dazu kann eine Verbraucher-App ein Content-Delivery-Network (CDN)-Knoten, AR- oder VR-Apps, Spiele-Apps und/oder eine andere Art von App sein. Ferner bedeutet die Kennzeichnung „Knoten“ oder „Gerät“, wie es im Edge-Rechensystem verwendet wird, nicht notwendigerweise, dass ein derartiger Knoten oder derartiges Gerät in einer Client- oder Agent-/Minion-/Folgerrolle arbeitet; vielmehr bezeichnen beliebige der Knoten oder Vorrichtungen im Edge-Rechensystem einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 1210 zu ermöglichen oder zu verwenden.
Als solche ist die Edge-Cloud 1210 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die durch und innerhalb von Edge-Gatewayknoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 1310-1330 betrieben werden. Die Edge-Cloud 1210 kann somit als eine beliebige Art von Netzwerk ausgebildet sein, das Edge-Rechen- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z. B. Mobilrechenvorrichtungen, IoT-Vorrichtungen, Smartvorrichtungen usw.) befinden, die hierin besprochen sind. Anders ausgedrückt kann man sich die Edge-Cloud 1210 als ein „Rand“ vorstellen, der die Endpunktvorrichtungen und herkömmliche Netzwerkzugangspunkte verbindet, die als ein Zugriffspunkt zu Kernnetzen von Dienstanbietern dienen, einschließlich Netzwerken von mobilen Trägern (z. B. Netzwerke des Global System for Mobile Communications (GSM), Long-Term-Evolution(LTE)-Netzwerke, 5G/6G-Netzwerke usw.), während er auch Speicher- oder Rechenfunktionen bereitstellt. Andere Arten und Formen des Netzwerkzugriffs (z. B. WiFi, drahtlose, verdrahtete Langstreckennetze einschließlich optischer Netzwerke) können auch anstatt oder in Kombination mit derartigen 3GPP-Trägernetzen eingesetzt werden.
Die Netzwerkkomponenten der Edge-Cloud 1210 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 1210 eine Geräterechenvorrichtung beinhalten, die eine eigenständige elektronische Vorrichtung einschließlich einer Einhausung, eines Chassis, eines Gehäuses oder einer Hülle ist. Unter einigen Umständen kann die Einhausung für Portabilität dimensioniert sein, sodass es von einem Menschen getragen und/oder versandt werden kann. Alternativ kann es sich beispielsweise um ein kleineres Modul handeln, das zum Einbau in ein Fahrzeug geeignet ist. Beispielhafte Einhausungen können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (z. B. EMI, Vibration, extreme Temperaturen) beinhalten kann und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Einhausungen können Leistungsschaltungsanordnungen beinhalten, um Leistung für stationäre und/oder tragbare Implementierungen bereitzustellen, wie etwa Wechselstromeingänge, Gleichstromeingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnungen, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Kleinere modulare Implementierungen können auch eine erweiterbare oder eingebettete Antennenanordnung für drahtlose Kommunikation beinhalten. Beispielhafte Einhausungen und/oder Oberflächen davon können Montagehardware beinhalten oder mit dieser verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (z. B. Masten, Antennenstrukturen usw.) und/oder Racks (z.B. Server-Racks, Bladebefestigungen usw.), zu ermöglichen. Beispielhafte Einhausungen und/oder Oberflächen davon können einen oder mehrere Sensoren (z. B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, kapazitive Sensoren, Näherungssensoren und/oder Sensoren 2772 von 27 und/oder dergleichen) unterstützen. Ein oder mehrere derartige Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderweitig eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Einhausungen und/oder Oberflächen davon können mechanische Konnektivität unterstützen, wie etwa Antriebshardware (z. B. Räder, Propeller, Aktuatoren (z. B. Aktuatoren 2774 von 27) usw.) und/oder Gelenkhardware (z. B. Roboterarme, schwenkbare Fortsätze usw.). Unter manchen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellenhardware (z. B. Tasten, Schalter, Wählscheiben, Schieber usw.). Unter manchen Umständen beinhalten beispielhafte Einhausungen Ausgabevorrichtungen, die in, getragen durch, eingebettet darin und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Anschlüsse (z. B. USB) usw. beinhalten. Unter manchen Umständen sind Edge-Vorrichtungen Vorrichtungen, die im Netzwerk für einen spezifischen Zweck (z. B. eine Verkehrsampel) präsentiert werden, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Derartige Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und können mit einer Einhausung versehen sein, die einen Formfaktor aufweist, der für seinen primären Zweck geeignet ist; aber dennoch für andere Rechenaufgaben verfügbar ist, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Vorrichtungen des Internets der Dinge. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Angelegenheiten, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Stromangelegenheiten, physische und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 27 beschrieben. Die Edge-Cloud 1210 kann auch einen oder mehrere Server und/oder einen oder mehrere Multi-Mandanten-Server beinhalten. Ein derartiger Server kann ein Betriebssystem beinhalten und eine virtuelle Rechenumgebung implementieren. Eine virtuelle Rechenumgebung kann einen Hypervisor beinhalten, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (z. B. erzeugt, einsetzt, zerstört usw.). Derartige virtuelle Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, anderer Code oder andere Skripte ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
In 14 tauschen verschiedene Client-Endpunkte 1410 (in der Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 1410 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 1422 durch ein Vor-Ort-Netzwerksystem 1432 ausgetauscht werden. Manche Client-Endpunkte 1410, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 1424 durch einen Zugangspunkt (z. B. Mobilfunknetzturm) 1434 ausgetauscht werden. Manche Client-Endpunkte 1410, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anfragen und Antworten 1426 über ein drahtloses Fahrzeugnetzwerk durch ein auf Straßen angeordnetes Netzwerksystem 1436 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 1442, 1444 innerhalb der Edge-Cloud 1210 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 1210 verschiedene Rechen- und Speicherressourcen einsetzen, wie etwa an Edge-Aggregationsknoten 1440, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 1440 und andere Systeme der Edge-Cloud 1210 sind mit einer Cloud oder einem Rechenzentrum 1460 verbunden, das ein Backhaul-Netzwerk 1450 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Rechenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 1440 und der Aggregationspunkte 1442, 1444, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 1210 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
15 veranschaulicht Bereitstellung und Orchestrierung für virtualisierte und containerbasierte Edge-Konfigurationen über ein Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten (z. B. Benutzern, Anbietern), die solche Edge-Knoten verwenden, betrieben wird. Insbesondere stellt 15 eine Koordination eines ersten Edge-Knotens 1522 und eines zweiten Edge-Knotens 1524 in einem Edge-Rechensystem 1500 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 1510 (z. B. Smart Cities/Gebäudesysteme, Mobilvorrichtungen, Rechenvorrichtungen, Geschäfts-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hier stellen die virtuellen Edge-Instanzen 1532, 1534 Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf eine Cloud/ein Rechenzentrum 1540 für Anforderungen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
In 15 beinhalten diese virtuellen Edge-Instanzen: eine erste virtuelle Edge 1532, die einem ersten Mandanten (Mandanten 1) angeboten wird, der eine erste Kombination von Edge-Speicherung, Berechnung und Diensten anbietet; und eine zweite virtuelle Edge 1534, die eine zweite Kombination von Edge-Speicherung, Berechnung und Diensten anbietet. Die virtuellen Edge-Instanzen 1532, 1534 sind unter den Edge-Knoten 1522, 1524 verteilt und können Szenarien beinhalten, in denen eine Anforderung und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 1522, 1524 zum Arbeiten auf eine verteilte, aber koordinierte Weise findet basierend auf Edge-Bereitstellungsfunktionen 1550 statt. Die Funktionalität der Edge-Knoten 1522, 1524 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 1560 statt.
Einige der Vorrichtungen 1510 sind Multi-Mandanten-Vorrichtungen, wobei Mandant 1 innerhalb eines Mandanten-1-.Segments' funktionieren kann, während ein Mandant 2 innerhalb eines Mandanten-2-,Segments' funktionieren kann (und in weiteren Beispielen können zusätzliche oder Sub-Mandanten existieren; und jeder Mandant kann sogar spezifisch berechtigt und transaktionell an einen spezifischen Satz von Merkmalen bis hin zu spezifischen Hardwaremerkmalen gebunden sein). Eine vertrauenswürdige Multi-Mandanten-Vorrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, sodass die Kombination aus Schlüssel und Segment als eine „Stammvertrauenstellung“ (RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner dynamisch unter Verwendung einer DICE-Architektur (Device Identity Composition Engine) berechnet werden, sodass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zur Schichtung von Vorrichtungsfähigkeiten (wie etwa ein feldprogrammierbares Gatearray (FPGA)) zu konstruieren. Die RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um eine „Ausfächerung“ zu ermöglichen, die zum Unterstützen einer Multi-Mandantenfähigkeit nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 1522, 1524 als Sicherheitsmerkmaldurchsetzungspunkte für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugewiesen sind. Zusätzlich dazu können Mandantenlaufzeit-und Anwendungsausführung (z. B. in den Fällen 1532, 1534) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hostingplattformen umspannen. Schließlich können die Orchestrierungsfunktionen 1560 an einer Orchestrierungsentität als ein Sicherheitsmerkmals-Durchsetzungspunkt zum Lenken von Ressourcen entlang Mandantengrenzen fungieren.
Edge-Rechenknoten können Ressourcen (Speicher, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interruptsteuerung, Eingabe/Ausgabe(E/A)-Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionen eine RoT-Fähigkeit enthalten können und wobei Ausfächerung und Schichtung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Rechenknoten verwenden oft Container, FaaS-Engines, Servlets, Server oder eine andere Berechnungsabstraktion, die gemäß einer DICE-Schichtungs- und Ausfächerungsstruktur partitioniert werden können, um für jede der Abstraktionen einen RoT -Kontext zu unterstützen. Dementsprechend können die jeweiligen Vorrichtungen 1510, 1522 und 1540, die RoTs umspannen, die Einrichtung einer verteilten vertrauenswürdigen Rechenbasis (DTCB) koordinieren, sodass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente durchgehend verbindet, eingerichtet werden kann.
Ferner versteht es sich, dass ein Container daten- oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuerung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Ziel-Edge-Knoten-Pod-Steuerung erhalten, wobei der Migrationsschlüssel zum Verpacken der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zum Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuerung offenbart, die dann die verpackten Schlüssel entschlüsselt. Die Schlüssel können nun zur Durchführung von Operationen an containerspezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt bestätigte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
In weiteren Beispielen wird ein Edge-Rechensystem erweitert, um eine Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer geschlossenen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Umgebung mit mehreren Eigentümern und mehreren Mandanten bereitzustellen. Ein Multi-Mandanten-Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen ,Segment‘-Konzepts in 15 durchzuführen. Beispielsweise kann ein Edge-Rechensystem ausgelegt sein, Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Rechenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z. B. erweiterte Realität (AR)/virtuelle Realität (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Rechen-Auslagerung) gleichzeitig unterstützen. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z. B. normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Vernetzungsanwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geografischen Standorten (oder jeweilige Rechensysteme und Ressourcen, die von mehreren Eigentümern gemeinsam besessen oder gemeinsam verwaltet werden) verteilt sein.
Beispielsweise kann jeder Edge-Knoten 1522, 1524 die Verwendung von Containern implementieren, wie etwa durch die Verwendung eines Container-„Pods“ 1526, 1528, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einer Einstellung, die eine oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z. B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Segmente 1532, 1534 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
Bei der Verwendung von Container-Pods beaufsichtigt eine Pod-Steuerung die Partitionierung und Zuordnung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (z. B. dem Orchestrator 1560), die die Steuerung darüber anweisen, wie physische Ressourcen am besten und für welche Dauer zu partitionieren sind, wie etwa durch Empfangen von Leistungskennzahl-Zielen (KPI-Zielen) basierend auf SLA-Verträgen. Die Pod-Steuerung ermittelt, welcher Container welche Ressourcen und wie lange benötigt, um die Arbeitslast abzuschließen und die SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Containerlebenszyklusoperationen, wie etwa: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam an einer verteilten Anwendung arbeiten, Abbauen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung in einer Sicherheitsrolle dienen, die eine Zuordnung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Bestätigungsergebnis erfüllt ist.
Auch bei der Verwendung von Container-Pods können dennoch Mandantengrenzen existieren, aber im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, gibt es eine gemeinsam genutzte Pod-Steuerung, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Bestätigung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise kann der Orchestrator 1560 lokalen Pod-Steuerungen, die eine Bestätigungsprüfung durchführen, eine Bestätigungsprüfungsrichtlinie bereitstellen. Falls eine Bestätigung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der sie erfüllt. Alternativ dazu kann die Ausführung des ersten Pods erlaubt werden und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
16 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen. Als ein vereinfachtes Beispiel stellen die Systemanordnungen 1610, 1620 Situationen dar, in denen eine Pod-Steuerung (z. B. Containermanager 1611, 1621 und ein Containerorchestrator 1631) dazu ausgelegt ist, containerisierte Pods, Funktionen und Funktionen-as-a-Service-Instanzen durch Ausführung über Rechenknoten 1615 in Anordnung 1610 zu starten oder separat containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten 1623 in Anordnung 1620 auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in einer Systemanordnung 1630 (unter Verwendung von Rechenknoten 1637) angepasst, wobei containerisierte Pods (z. B. Pods 1612), Funktionen (z. B. Funktionen 1613, VNFs 1622, 1636) und Funktionen-as-a-Service-Instanzen (z. B. FaaS-Instanz 1614) innerhalb virtueller Maschinen (z. B. VMs 1634, 1635 für Mandanten 1632, 1633) gestartet werden, die spezifisch für jeweilige Mandanten sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in einer Systemanordnung 1640 angepasst, die Container 1642, 1643 oder eine Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf Rechenknoten 1644 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 1641 koordiniert.
Die in 16 dargestellten Systemanordnungen von stellen eine Architektur bereit, die VMs, Container und Funktionen gleichermaßen hinsichtlich der Anwendungszusammensetzung behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger-Komponenten (FPGA, ASIC) als ein lokales Backend involvieren. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
Im Kontext von 16 können die Pod-Steuerung/der Containermanager, der Containerorchestrator und die einzelnen Knoten einen Sicherheitsdurchsetzungspunkt bereitstellen. Die Mandantentrennung kann jedoch orchestriert werden, wo sich die Ressourcen, die einem Mandanten zugewiesen sind, von Ressourcen unterscheiden, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass Ressourcenzuweisungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuweisungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ auf Subskriptions- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Zusammenhängen können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemata von Edge-Eigentümern verwendet werden, um den Mandantenzustand durchzusetzen. Andere Isolationsumgebungen können beinhalten: (dedizierte) Bare-Metal-Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
In weiteren Beispielen können Aspekte von softwaredefinierter oder softwaregesteuerter Siliziumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Rechensystems integrieren. Softwaredefiniertes Silizium (SDSi) kann verwendet werden, um die Fähigkeit sicherzustellen, dass irgendein Ressourcen- oder Hardwarebestandteil einen Vertrag oder eine Dienstgütevereinbarung erfüllt, basierend auf der Fähigkeit des Bestandteils, einen Abschnitt von sich selbst oder der Arbeitslast zu korrigieren (z. B. durch eine Hochrüstung, eine Neukonfiguration oder eine Bereitstellung neuer Funktionen innerhalb der Hardwarekonfiguration selbst).
17 zeigt eine beispielhafte Anordnung, bei der die hierin besprochenen Edge-Rechensysteme und Anordnungen bei verschiedenen Lösungen, Diensten und/oder Anwendungsfällen anwendbar sein können, die Mobilität involvieren. 17 zeigt einen Fahrzeugberechnungs- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Rechensystem 1700 involviert, das eine Edge-Cloud 1210 implementiert. In diesem Anwendungsfall können die jeweiligen Client-Rechenknoten 1710 als fahrzeuginterne Rechensysteme (z. B. fahrzeuginterne Navigations- und/oder Infotainmentsysteme) ausgebildet sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gatewayknoten 1720 während des Durchfahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gatewayknoten 1720 in einem Schrank am Straßenrand oder einer anderen Einhausung befinden, die in eine Struktur eingebaut ist, die einen anderen, separaten, mechanischen Nutzen aufweist und entlang der Straße, an Kreuzungen der Straße oder anderen Standorten nahe der Straße platziert werden kann. Wenn jeweilige Fahrzeuge entlang der Straße fahren, kann die Verbindung zwischen ihrem Client-Rechenknoten 1710 und einer ermittelten Edge-Gateway-Vorrichtung 1720 propagieren, sodass eine konsistente Verbindung und ein konsistenter Kontext für den Client-Rechenknoten 1710 aufrechterhalten werden. Gleichermaßen können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsanforderungen für den zugrundeliegenden Dienst bzw. die zugrundeliegenden Dienste aggregieren (z. B. im Fall von Drohnen). Die jeweiligen Edge-Gateway-Vorrichtungen 1720 beinhalten eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und daher können etwas Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 1710 auf einem oder mehreren der Edge-Gateway-Vorrichtungen 1720 durchgeführt werden.
Die Edge-Gateway-Vorrichtungen 1720 können mit einem oder mehreren Edge-Ressourcenknoten 1740 kommunizieren, die veranschaulichend als Rechenserver, Geräte oder Komponenten umgesetzt sind, die sich an oder in einem Netzwerkzugangsknoten (NAN) 1742 (z. B. einer Basisstation eines Mobilfunknetzes) befinden. Wie oben besprochen, beinhalten die jeweiligen Edge-Ressourcenknoten 1740 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, sodass etwas der Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 1710 an dem Edge-Ressourcenknoten 1740 durchgeführt werden können. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den Edge-Ressourcenknoten 1740 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Vorrichtungen 1720 durchgeführt werden kann (in Abhängigkeit beispielsweise von den Fähigkeiten jeder Komponente oder Informationen in der Anforderung, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenposition oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Gleichermaßen können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (z. B. durch einen lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um den neuen Bedarf zu erfüllen (z. B. Anpassen der Rechenressourcen an die Arbeitslastdaten).
Der eine oder die mehreren Edge-Ressourcenknoten 1740 kommunizieren auch mit dem Kernrechenzentrum 1750, das Rechenserver, Geräte und/oder andere Komponenten beinhalten kann, die sich an einem zentralen Standort (z. B. einer Zentrale eines Mobilfunkkommunikationsnetzes) befinden. Das Kernrechenzentrum 1750 kann ein Gateway zur globalen Netzwerk-Cloud 1760 (z. B. dem Internet) für die Operationen der Edge-Cloud 1210 bereitstellen, das durch den einen oder die mehreren Edge-Ressourcenknoten 1740 und die Edge-Gateway-Vorrichtungen 1720 gebildet wird. Zusätzlich kann das Kernrechenzentrum 1750 in manchen Beispielen eine Menge an Verarbeitungs- und Speicherungsfunktionen beinhalten und somit kann etwas der Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kernrechenzentrum 1750 durchgeführt werden (z. B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
Die Edge-Gatewayknoten 1720 oder die Edge-Ressourcenknoten 1740 können die Verwendung zustandsorientierter Anwendungen 1732 und einer geografisch verteilten Datenbank 1734 anbieten. Obwohl die Anwendungen 1732 und die Datenbank 1734 als horizontal in einer Schicht der Edge-Cloud 1210 verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste oder andere Komponenten der Anwendung vertikal in der gesamten Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, die an dem Client-Rechenknoten 1710 ausgeführt wird, anderer Teile an den Edge-Gatewayknoten 1720 oder den Edge-Ressourcenknoten 1740 usw.). Zusätzlich dazu kann es, wie zuvor angegeben, Peer-Beziehungen auf einer beliebigen Ebene geben, um Dienstziele und Verpflichtungen zu erfüllen. Ferner können sich die Daten für einen ermittelten Client oder eine bestimmte Anwendung basierend auf sich ändernden Bedingungen (z. B. basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.) von Edge zu Edge bewegen. Beispielsweise kann basierend auf der „Abklingrate“ des Zugangs eine Vorhersage getroffen werden, um den nächsten Eigentümer zum Fortsetzen zu identifizieren, oder wann die Daten oder der rechnerische Zugang nicht mehr praktikabel sein werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die notwendig ist, um die Transaktion konform und verlustfrei zu halten.
In weiteren Szenarien kann ein Container 1736 (oder ein Pod von Containern) flexibel von einem Edge-Knoten 1720 zu anderen Edge-Knoten (z. B. 1720, 1740 usw.) migriert werden, sodass der Container mit einer Anwendung und Arbeitslast nicht rekonstituiert, neu kompiliert, neu interpretiert werden muss, damit die Migration funktioniert. In derartigen Szenarien können jedoch einige abhelfende oder „Swizzling“-Übersetzungsoperationen angewendet werden. Zum Beispiel kann sich die physische Hardware am Knoten 1740 vom Edge-Gatewayknoten 1720 unterscheiden und daher wird die Hardware-Abstraktionsschicht (HAL), die die untere Edge des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann irgendeine Form einer späten Bindungstechnik beinhalten, wie etwa binäre Übersetzung der HAL von dem nativen Containerformat in das physische Hardwareformat, oder kann eine Abbildung von Schnittstellen und Operationen beinhalten. Eine Pod-Steuerung kann verwendet werden, um die Schnittstellenabbildung als Teil des Containerlebenszyklus zu lenken, was eine Migration zu/von verschiedenen Hardwareumgebungen beinhaltet.
Die Szenarien, die 17 umfasst, können verschiedene Arten von mobilen Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Auto/Lastkraftwagen/Straßenbahn/Eisenbahn) gehostet ist, oder eine andere mobile Einheit, da sich der Edge-Knoten zu anderen geografischen Standorten entlang der Plattform, die ihn hostet, bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (z. B. um Zwischenspeichern, Berichterstellung, Datenaggregation usw. durchzuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Szenarien verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunktvorrichtungen oder den Edge-Gatewayknoten 1720, einigen anderen an dem Edge-Ressourcenknoten 1740 und anderen in dem Kernrechenzentrum 1750 oder der globalen Netzwerk-Cloud 1760.
In weiteren Konfigurationen kann das Edge-Rechensystem FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen implementieren. Bei einem Beispiel schreibt ein Entwickler Funktionscode (hierin z. B. „Computercode“), der eine oder mehrere Computerfunktionen repräsentiert, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel durch einen Edge-Knoten oder ein Rechenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstanwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
Bei einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (z. B. eine Anwendung, die durch einen Drittanbieter bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernete-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Rechensystems werden verschiedene Rechenzenten-, Edge- und Endpunktvorrichtungen (einschließlich Mobilvorrichtungen) verwendet, um Funktionen „hochzufahren“ (z. B. Funktionsaktionen zu aktivieren und/oder zuzuweisen), die auf Abruf skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (z. B. Edge-Rechenknoten) und darunterliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container auf der Infrastruktur als Reaktion darauf, dass die Ausführung abgeschlossen ist, „heruntergefahren“ (z. B. deaktiviert und/oder freigegeben).
Weitere Aspekte von FaaS können eine Bereitstellung von Edge-Funktionen auf Dienstweise ermöglichen, einschließlich einer Unterstützung jeweiliger Funktionen, die Edge-Rechnen-as-a-Service (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können beinhalten: eine granuläre Abrechnungskomponente, die Kunden (z. B. Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen einzelnen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits eingesetzt oder betrieben werden, versus „kalter“ Container, die eine Initialisierung, Bereitstellung oder Konfiguration erfordern).
Das Edge-Rechensystem 1700 kann einen Edge-Bereitstellungsknoten 1744 beinhalten oder mit diesem in Kommunikation stehen. Der Edge-Bereitstellungsknoten 1744 kann Software, wie etwa die beispielhaften computerlesbaren Anweisungen 2782 von 27, an verschiedene Empfangsteilnehmer zum Implementieren eines beliebigen der hierin beschriebenen Verfahren verteilen. Der beispielhafte Edge-Bereitstellungsknoten 1744 kann durch einen beliebigen Computerserver, einen beliebigen Heimserver, ein beliebiges Inhaltsübermittlungsnetzwerk, einen beliebigen virtuellen Server, ein beliebiges Softwareverteilungssystem, eine beliebige zentrale Einrichtung, eine beliebige Speicherungsvorrichtung, eine beliebige Speicherungsplatte, einen beliebigen Speicherungsknoten, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, der bzw. das bzw. die in der Lage ist, Softwareanweisungen (z. B. Code, Skripte, ausführbare Binärdateien, Container, Pakete, komprimierte Dateien und/oder Ableitungen davon) zu speichern und/oder an andere Rechenvorrichtungen zu übertragen. Eine oder mehrere Komponenten des beispielhaften Edge-Bereitstellungsknotens 644 können sich in einer Cloud, in einem lokalen Netzwerk, in einem Edge-Netzwerk, in einem Fernnetz, im Internet und/oder an einem beliebigen anderen Standort befinden, der kommunikativ an die eine oder mehreren Empfangsparteien gekoppelt ist. Die Empfangsteilnehmer können Konsumenten, Kunden, Assoziierte, Benutzer usw. der Entität sein, die den Edge-Bereitstellungsknoten 1744 besitzt und/oder betreibt. Beispielsweise kann die Entität, die den Edge-Bereitstellungsknoten 1744 besitzt und/oder betreibt, ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber (oder ein Kunde und/oder Verbraucher davon) von Softwareanweisungen wie etwa der beispielhaften computerlesbaren Anweisungen 2782 von 27 sein. Die Empfangsteilnehmer können Verbraucher, Dienstanbieter, Benutzer, Einzelhändler, OEMs usw. sein, die die Softwareanweisungen zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren.
Bei einem Beispiel beinhaltet der Edge-Bereitstellungsknoten 1744 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen/Platten. Die Speicherungsvorrichtungen und/oder Speicherungsplatten hosten computerlesbare Anweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 2782 von 27, wie unten beschrieben. Ähnlich den oben beschriebenen Edge-Gateway-Vorrichtungen 1720 stehen der eine oder die mehreren Server des Edge-Bereitstellungsknotens 1744 in Kommunikation mit einem NAN 1742 oder einer anderen Netzwerkkommunikationsentität. In manchen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Softwareanweisungen als Teil einer kommerziellen Transaktion an eine anfordernde Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Softwareanweisungen kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittanbieter-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 2782 von dem Edge-Bereitstellungsknoten 1744 herunterzuladen. Zum Beispiel können die Softwareanweisungen, die den beispielhaften computerlesbaren Anweisungen 2782 von 27 entsprechen können, auf die eine oder die mehreren beispielhaften Prozessorplattformen heruntergeladen werden, die die computerlesbaren Anweisungen 2782 ausführen sollen, um die hierin beschriebenen Verfahren zu implementieren.
In manchen Beispielen können sich die Prozessorplattform(en), die die computerlesbaren Anweisungen 2782 ausführen, physisch an verschiedenen geografischen Standorten, in verschiedenen gesetzlichen Zuständigkeitsbereichen usw. befinden. In manchen Beispielen bieten, übertragen und/oder erzwingen ein oder mehrere Server des Edge-Bereitstellungsknotens 1744 periodisch Aktualisierungen der Softwareanweisungen (z. B. der beispielhaften computerlesbaren Anweisungen 2782 von 27), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Softwareanweisungen angewendet werden, die an den Endbenutzervorrichtungen implementiert sind. In manchen Beispielen können unterschiedliche Komponenten der computerlesbaren Anweisungen 2782 von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt sein; zum Beispiel können unterschiedliche Bibliotheken, Plug-ins, Komponenten und andere Typen von Rechenmodulen, ob kompiliert oder interpretiert, von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt sein. Zum Beispiel kann ein Teil der Softwareanweisungen (z. B. ein Skript, das an sich nicht ausführbar ist) von einer ersten Quelle verteilt werden, während ein Interpreter (der in der Lage ist, das Skript auszuführen) von einer zweiten Quelle verteilt werden kann.
4.1. Mehrfachzugriffs-Edge-Computing-Aspekte (MEC-Aspekte)
18 veranschaulicht eine MEC-Systemreferenzarchitektur (oder MEC-Architektur) 1800, die Funktionalitäten gemäß ETSI GS MEC 003 v2.1.1 (2019-01) („[MEC003]“); ETSI GS MEC 009 V2.1.1 (2019-01) („[MEC009]“); ETSI GS MEC 011 V1.1.1 (2017-07) („[MEC011]“); ETSI GS MEC 012 V2.1.1 (2019-12) („[MEC012]“); ETSI GS MEC 013 v2.1.1 (2019-09) („[MEC013]“); ETSI GS MEC 014 VI.1.1 (2018-02) („[MEC014]“); ETSI GS MEC 015 v2.1.1 (2020-06) („[MEC015]“); ETSI GS MEC 028 v2.1.1 (2020-06) („[MEC028]“); ETSI GS MEC 029 v2.1.1 (2019-07) („[MEC029]“); ETSI MEC GS 030 v2.1.1 (2020-04) („[MEC030]“); unter vielen anderen ETSI-MEC-Standards bereitstellt. MEC bietet Anwendungsentwicklern und Inhaltsanbietern Cloud-Rechenfähigkeiten und eine IT-Dienstumgebung am Rand des Netzwerks. Diese Umgebung zeichnet sich durch ultraniedrige Latenz und hohe Bandbreite sowie Echtzeitzugang auf Funknetzinformationen aus, die durch Anwendungen genutzt werden können. Die MEC-Technologie ermöglicht eine flexible und schnelle Bereitstellung innovativer Anwendungen und Dienste für Mobilteilnehmer, Unternehmen und vertikale Segmente. Insbesondere müssen, was den Automobilsektor betrifft, Anwendungen, wie etwa V2X (z. B. IEEE 802.11p-basierte Protokolle, wie etwa DSRC/ITS-G5- oder 3GPP-C-V2X-basierte Protokolle), Daten austauschen, Daten für Aggregationspunkte bereitstellen und auf Daten in Datenbanken zugreifen, die einen Überblick über die lokale Situation bereitstellen, die von einer Vielzahl von Sensoren (durch verschiedene Autos, Straßenrandeinheiten usw.) abgeleitet wird.
Die MEC-Architektur 1800 beinhaltet MEC-Hosts 1802, einen Virtualisierungsinfrastrukturmanager (VIM) 1808, einen MEC-Plattformmanager 1806, einen MEC-Orchestrator 1810, ein Operationsunterstützungssystem (OSS) 1812, einen Benutzer-App-Proxy 1814, eine UE-App 1818, die auf dem UE 1820 läuft, und ein CFS-Portal 1816. Der MEC-Host 1802 kann eine MEC-Plattform 1832 mit einer Filterregelsteuerkomponente 1840, eine DNS-Handhabungskomponente 1842, eine Dienstregistrierungsdatenbank 1838 und MEC-Dienste 1836 beinhalten. Die MEC-Dienste 1836 können mindestens einen Planer beinhalten, der verwendet werden kann, um Ressourcen zum Instanziieren von MEC-Apps (oder NFVs) 1826 auf einer Virtualisierungsinfrastruktur (VI) 1822 auszuwählen. Die MEC-Apps 1826 können dazu ausgelegt sein, Dienste 1830 bereitzustellen, die Verarbeiten von Netzwerkkommunikationsverkehr unterschiedlicher Typen, die mit einer oder mehreren Drahtlosverbindungen (z. B. Verbindungen mit einem oder mehreren RANs oder Kernnetzwerkfunktionen) assoziiert sind, und/oder manche anderen Dienste, wie etwa jene hierin erörterten, beinhalten können. Der andere MEC-Host 1802 kann eine gleiche oder eine ähnliche Konfiguration/Implementierung wie der MEC-Host 1802 aufweisen, und die andere MEC-App 1826, die innerhalb des anderen MEC-Hosts 1802 instanziiert ist, kann den MEC-Apps 1826 ähnlich sein, die innerhalb des MEC-Hosts 1802 instanziiert sind. Die VI 1822 beinhaltet eine Datenebene 1824, die über eine MP2-Schnittstelle mit der MEC-Plattform 1822 gekoppelt ist. Zusätzliche Schnittstellen zwischen verschiedenen Netzwerkentitäten der MEC-Architektur 1800 sind in 18 veranschaulicht.
Das MEC-System 1800 beinhaltet drei Gruppen von Bezugspunkten, einschließlich „Mp“-Bezugspunkten bezüglich der MEC-Plattformfunktionalität; „Mm“-Bezungspunkten, die Verwaltungsbezugspunkte sind; und „Mx“-Bezugspunkten, die MEC-Entitäten mit externen Entitäten verbinden. Die Schnittstellen/Bezugspunkte im MEC-System 1800 können IP-basierte Verbindungen beinhalten und können verwendet werden, um Dienste zum Representational State Transfer (REST oder RESTful) bereitzustellen, und die unter Verwenden der Bezugspunkte/Schnittstellen übermittelten Nachrichten können in XML, HTML, JSON oder einem anderen gewünschten Format, wie den hierin erörterten, vorliegen. Ein geeignetes Authentifizierungs-, Autorisierungs- und Protokollierungsprotokoll (AAA-Protokoll), wie etwa das Radius- oder das Diameter-Protokoll, kann auch zum Kommunizieren über die Bezugspunkte/Schnittstellen verwendet werden.
Die logischen Verbindungen zwischen verschiedenen Entitäten der MEC-Architektur 1800 können zugriffsagnostisch sein und nicht von einer bestimmten Bereitstellung abhängen. MEC ermöglicht die Umsetzung von MEC-Apps 1826 als reine Software-Entitäten, die auf einer VI 1822 laufen, die sich in oder nahe der Netzwerk-Edge befindet. Eine MEC-App 1826 ist eine Anwendung, die auf einem MEC-Host 1802 innerhalb des MEC-Systems 1800 instanziiert werden kann und potenziell MEC-Dienste 1836 bereitstellen oder verbrauchen kann.
Die in 18 abgebildeten MEC-Entitäten können in eine MEC-Systemebene, MEC-Hostebene und Entitäten auf Netzwerkebene (nicht gezeigt) gruppiert werden. Die (nicht gezeigte) Netzwerkebene beinhaltet verschiedene externe Netzwerkebenenentitäten, wie etwa ein 3GPP-Netzwerk, ein lokales Netzwerk (zum Beispiel ein LAN, WLAN, PAN, DN, LADN usw.) und ein oder mehrere externe Netzwerke. Die MEC-Systemebene beinhaltet MEC-Systemebenen-Verwaltungsentitäten und UE 1820 und wird im Folgenden ausführlicher besprochen. Die MEC-Hostebene beinhaltet einen oder mehrere MEC-Hosts 1802, 1804 und MEC-Verwaltungsentitäten, die Funktionalität bereitstellen, um MEC-Anwendungen 1826 innerhalb eines Betreibernetzwerks oder einer Teilmenge eines Betreibernetzwerks auszuführen. Die MEC-Verwaltungsentitäten beinhalten verschiedene Komponenten, die die Verwaltung der MEC-spezifischen Funktionalität einer bestimmten MEC-Plattform 1832, eines MEC-Hosts 1802 und der MEC-Anwendungen 1826, die ausgeführt werden sollen, handhaben.
Der MEC-Plattformmanager 1806 ist eine MEC-Verwaltungsentität, die eine MEC-Plattformelementverwaltungskomponente 1844, eine MEC-App-Regel- und Anforderungsverwaltungskomponente 1846 und eine MEC-App-Lebenszyklusverwaltungskomponente 1848 beinhaltet. Die verschiedenen Entitäten innerhalb der MEC-Architektur 1800 können Funktionalitäten ausführen, wie in [MEC003] besprochen. Die Remote-App 1850 ist dazu ausgelegt, mit dem MEC-Host 1802 (zum Beispiel mit den MEC-Apps 1826) über den MEC-Orchestrator 1810 und den MEC-Plattformmanager 1806 zu kommunizieren.
Der MEC-Host 1802 ist eine Entität, die eine MEC-Plattform 1832 und die VI 1822 enthält, die Rechen-, Speicherungs- und Netzwerkressourcen zum Zweck des Ausführens von MEC-Apps 1826 bereitstellt. Die VI 1822 beinhaltet eine Datenebene (DP) 1824, die Verkehrsregeln 1840 ausführt, die von der MEC-Plattform 1832 empfangen werden, und den Verkehr zwischen MEC-Anwendungen 1826, MEC-Diensten 1836, DNS-Server/Proxy (siehe zum Beispiel über DNS-Handhabungsentität 1842), 3GPP-Netzwerk, lokalen Netzwerken und externen Netzwerken routet. Die MEC-DP 1824 kann mit den (R)AN-Knoten und dem 3GPP-Kernnetzwerk verbunden sein und/oder kann mit einem Zugangspunkt über ein breiteres Netzwerk, wie etwa dem Internet, einem Unternehmensnetzwerk oder dergleichen, verbunden sein.
Die MEC-Plattform 1832 ist eine Sammlung wesentlicher Funktionalität, die erforderlich ist, um MEC-Anwendungen 1826 auf einer bestimmten VI 1822 auszuführen und es ihnen zu ermöglichen, MEC-Dienste 1836 bereitzustellen und zu verbrauchen, und die sich selbst eine Anzahl von MEC-Diensten 937a bereitstellen kann. Die MEC-Plattform 1832 kann auch verschiedene Dienste und/oder Funktionen bereitstellen, wie etwa Anbieten einer Umgebung, in der die MEC-Anwendungen 1826 MEC-Dienste 1836 (im Folgenden besprochen) entdecken, ankündigen, verbrauchen und anbieten können, einschließlich MEC-Dienste 1836, die über andere Plattformen verfügbar sind, wenn sie unterstützt werden. Die MEC-Plattform 1832 kann in der Lage sein, es autorisierten MEC-Apps 1826 zu erlauben, mit Drittpartei-Servern zu kommunizieren, die sich in externen Netzwerken befinden. Die MEC-Plattform 1832 kann Verkehrsregeln von dem MEC-Plattformmanager 1806, Anwendungen oder Dienste empfangen und die Datenebene entsprechend anweisen (siehe z. B. Verkehrsregelsteuerung 1840). Die MEC-Plattform 1832 kann innerhalb der VI 1822 über den Mp2-Bezugspunkt Anweisungen an die DP 1824 senden. Der Mp2-Bezugspunkt zwischen der MEC-Plattform 1832 und der DP 1824 der VI 1822 kann verwendet werden, um die DP 1834 darüber anzuweisen, wie Verkehr zwischen Anwendungen, Netzwerken, Diensten usw. zu routen ist. Die MEC-Plattform 1832 kann Token, die UEs 1820, UE-Apps, individuelle Sitzungen und/oder individuelle Flüsse innerhalb einer Sitzung in den Verkehrsregeln darstellen, in spezifische Netzwerkadressen (zum Beispiel IP-Adressen oder dergleichen) übersetzen. Die MEC-Plattform 1832 empfängt auch DNS-Datensätze vom MEC-Plattformmanager 1806 und konfiguriert einen DNS-Proxy/Server entsprechend. Die MEC-Plattform 1832 hostet MEC-Dienste 1836, einschließlich der nachstehend besprochenen Mehrfachzugriffs-Edge-Dienste, und stellt Zugang zu persistenten Speicherungs- und Tageszeitinformationen bereit. Darüber hinaus kann die MEC-Plattform 1832 mit anderen MEC-Plattformen 1832 anderer MEC-Server 1802 über den Mp3-Bezugspunkt kommunizieren. Bei Empfang einer Aktualisierung, Aktivierung oder Deaktivierung von Verkehrsregeln von dem MEC-Plattformmanager 1806, Apps oder Diensten, weist die MEC-Plattform 1832 die Datenebene 1824 entsprechend an. Die MEC-Plattform 1832 empfängt auch DNS-Datensätze vom MEC-Plattformmanager 1806 und verwendet diese, um einen DNS-Proxy/Server 1842 zu konfigurieren. Die Verkehrsregelsteuerung 1840 erlaubt der MEC-Plattform 1832, Verkehrsrouting, einschließlich Verkehrsregelaktualisierung, -aktivierung und -deaktivierung, auszuführen. Zusätzlich oder alternativ ermöglicht die Verkehrsregelsteuerung 1840 der MEC-Plattform 1832, Verkehrslenkung auszuführen, indem zum Beispiel Datenpakete über eine oder mehrere Zugangsnetzwerkverbindungen in einer Mehrfachzugangsumgebung gelenkt werden, die mehrere Zugangsnetzwerke umfasst, von denen jedes mehrere Zugangsnetzwerkverbindungen aufweisen kann und/oder unterschiedliche Zugangstechnologien umsetzen kann.
Die VI 1822 stellt die Gesamtheit aller Hardware- und Softwarekomponenten dar, die die Umgebung aufbauen, in der MEC-Anwendungen 1826 und/oder die MEC-Plattform 1832 eingesetzt, verwaltet und ausgeführt werden. Die VI 1822 kann sich über mehrere Standorte erstrecken und das Netzwerk, das Konnektivität zwischen diesen Standorten bereitstellt, wird als Teil der VI 1822 angesehen. Die physischen Hardwareressourcen der VI 1822 beinhalten Rechen-, Speicherungs- und Netzwerkressourcen, die die Verarbeitung, Speicherung und Konnektivität für die MEC-Apps 1826 und/oder die MEC-Plattform 1832 durch eine Virtualisierungsschicht (zum Beispiel einen Hypervisor, VM-Monitor (VMM) oder dergleichen) bereitstellen. Die Virtualisierungsschicht kann die physischen Hardwareressourcen des MEC-Servers 1802 als eine Hardware-Abstraktionsschicht abstrahieren und/oder logisch partitionieren. Die Virtualisierungsschicht kann es der Software, die die MEC-Apps 1826 und/oder die MEC-Plattform 1832 umsetzt, auch ermöglichen, die zugrunde liegende VI 1822 zu verwenden, und kann virtualisierte Ressourcen für die MEC-Apps 1826 und/oder die MEC-Plattform 1832 bereitstellen, sodass die MEC-Apps 1826 und/oder die MEC-Plattform 1832 ausgeführt werden können.
Die MEC-Apps 1826 sind Anwendungen, die auf einem MEC-Host/Server 1802 innerhalb des MEC-Systems 1800 instanziiert werden können und potenziell MEC-Dienste 1836 bereitstellen oder verwenden können. Der Begriff „MEC-Dienst“ bezeichnet einen Dienst, der über eine MEC-Plattform 1832 entweder von der MEC-Plattform 1832 selbst oder von einer MEC-App 1826 bereitgestellt wird. Die MEC-Apps 1826 können als VM auf der VI 1822 laufen, die von dem MEC-Server 1802 bereitgestellt wird, und können mit der MEC-Plattform 1832 interagieren, um die MEC-Dienste 1836 zu nutzen und bereitzustellen. Der Mp1-Bezugspunkt zwischen der MEC-Plattform 1832 und den MEC-Apps 1826 wird zum Verwenden und Bereitstellen dienstspezifischer Funktionalität verwendet. Mp1 stellt Dienstregistrierung 1838, Dienstentdeckung und Kommunikationsunterstützung für verschiedene Dienste bereit, wie etwa die MEC-Dienste 1836, die von dem MEC-Host 1802 bereitgestellt werden. Mp1 kann auch Anwendungsverfügbarkeit, Sitzungsstatusumlagerungs-Unterstützungsprozeduren, Verkehrsregel- und DNS-Regel-Aktivierung, Zugriff auf persistente Speicherungs- und Tageszeitinformationen und/oder dergleichen bereitstellen. Zusätzlich oder alternativ können die MEC-Apps 1826 mit der MEC-Plattform 1832 unter Verwenden der MEC-APIs kommunizieren, die in ETSI GS MEC 011 V2.1.1 (2019-11) erörtert sind.
Die MEC-Anwendungen 1826 werden auf der VI 1822 des MEC-Servers 1802 basierend auf einer Konfiguration oder Anforderungen instanziiert, die von der MEC-Verwaltung (zum Beispiel dem MEC-Plattformmanager 1806) validiert werden. Die MEC-Apps 1826 können auch mit der MEC-Plattform 1832 interagieren, um bestimmte Unterstützungsprozeduren in Bezug auf den Lebenszyklus der MEC-Apps 1826 durchzuführen, wie etwa Anzeigen von Verfügbarkeit, Vorbereiten der Verlagerung des Benutzerzustands usw. Die MEC-Anwendungen 1826 können eine bestimmte Anzahl von Regeln und Anforderungen aufweisen, die mit ihnen assoziiert sind, wie etwa erforderliche Ressourcen, maximale Latenz, erforderliche oder nützliche Dienste usw. Diese Anforderungen können durch die MEC-Verwaltung validiert werden und ihnen können Standardwerte zugewiesen werden, falls sie fehlen. MEC-Dienste 1836 sind Dienste, die entweder von der MEC-Plattform 1832 und/oder MEC-Anwendungen 1826 bereitgestellt und/oder genutzt werden. Die Dienstverbraucher (z. B. die MEC-Apps 1826 und/oder die MEC-Plattform 1832) können mit bestimmten MEC-Diensten 1836 über individuelle APIs (einschließlich MEC-V2X-API und der anderen hierin besprochenen MEC-APIs) kommunizieren. Wenn er von einer Anwendung bereitgestellt wird, kann ein MEC-Dienst 1836 in einer Liste von Diensten in den Dienstregistrierungsdatenbanken 1838 zu der MEC-Plattform 1832 über den Mp1-Bezugspunkt registriert werden. Zusätzlich kann eine MEC-Anwendung 1826 einen oder mehrere Dienste 1830/1836 abonnieren, für die sie über den Mp1-Bezugspunkt autorisiert ist.
Beispiele für MEC-Dienste 1836 beinhalten V2X-Informationsdienste (VIS), RNIS (siehe z. B. [MEC012], Standortdienste [MEC013], UE-Identitätsdienste [MEC014], Verkehrsverwaltungsdienste (TMS) und BWMS [MEC015], WLAN-Zugangsinformations(WAI)-Dienste [MEC028], Festzugangsinformations(FAI)-Dienste [MEC029] und/oder andere MEC-Dienste. Der RNIS stellt, falls verfügbar, autorisierte MEC-Apps 1826 mit funknetzbezogenen Informationen bereit und deckt für die MEC-Apps 1826 geeignete aktuelle Funknetzinformationen auf. Die RNI können unter anderem Funknetzbedingungen, Mess- und Statistikinformationen im Zusammenhang mit dem UP, Informationen im Zusammenhang mit UEs 1820, die von dem einen oder den mehreren Funkknoten bedient werden, die mit dem MEC-Host 1802 assoziiert sind (zum Beispiel UE-Kontext und Funkzugangsträger), Änderungen an Informationen im Zusammenhang mit UEs 1820, die von dem einen oder den mehreren Funkknoten bedient werden, die mit dem MEC-Host XE136 assoziiert sind, und/oder dergleichen beinhalten. Die RNI können mit der relevanten Granularität (zum Beispiel pro UE 1820, pro Zelle, pro Zeitraum) bereitgestellt werden.
Die Dienstverbraucher (zum Beispiel MEC-Apps 1826, MEC-Plattform 1832 usw.) können mit dem RNIS über eine RNI-API kommunizieren, um Kontextinformationen von einem entsprechenden RAN zu erhalten. RNI können den Dienstverbrauchern über ein NAN (zum Beispiel (R)AN-Knoten, RRH, AP usw.) bereitgestellt werden. Die RNI-API kann sowohl Anfrage- als auch Subskriptions-basierte (zum Beispiel Pub/Sub) Mechanismen unterstützen, die über eine Representational State Transfer-API (RESTful-API) oder über einen Nachrichtenbroker der MEC-Plattform 1832 (nicht gezeigt) verwendet werden. Eine MEC-App 1826 kann Informationen über einen Nachrichten-Broker über eine Transportinformationsabfrageprozedur abfragen, wobei die Transportinformationen der MEC-App 1826 über einen geeigneten Konfigurationsmechanismus im Vorfeld bereitgestellt werden können. Die verschiedenen Nachrichten, die über die RNI-API kommuniziert werden, können in XML, JSON, Protobuf oder einem anderen geeigneten Format vorliegen.
Der VIS stellt verschiedene V2X-Anwendungen bereit, einschließlich der routenbewussten QoS-Vorhersagen, unter vielen anderen. Die RNI können von den MEC-Apps 1826 und der MEC-Plattform 1832 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen über Funkbedingungen basieren. Als ein Beispiel kann eine MEC-App 1826 RNI verwenden, um aktuelle Dienste, wie eine Videodurchsatzanleitung, zu optimieren. Bei der Durchsatzanleitung kann eine Funkanalytik-MEC-App 1826 MEC-Dienste verwenden, um einem Backend-Videoserver eine Nahechtzeitangabe über den Durchsatz bereitzustellen, von dem geschätzt wird, dass er an der Funk-DL-Schnittstelle zu einem nächsten Zeitpunkt verfügbar ist. Die Durchsatzanleitungs-Funkanalytikanwendung berechnet eine Durchsatzanleitung basierend auf den erforderlichen Funknetzinformationen, die sie von einem Mehrfachzugriffs-Edge-Dienst, der auf dem MEC-Server 1802 läuft, erhält. RNI können von der MEC-Plattform 1832 auch verwendet werden, um die Mobilitätsprozeduren zu optimieren, die zur Unterstützung der Dienstkontinuität erforderlich sind, beispielsweise, wenn eine bestimmte MEC-App 1826 eine einzelne Information unter Verwenden eines einfachen Anfrage-Antwort-Modells (zum Beispiel unter Verwenden von RESTful-Mechanismen) anfordert, während andere MEC-Apps 1826 mehrere unterschiedliche Benachrichtigungen im Zusammenhang mit Informationsänderungen (zum Beispiel unter Verwenden eines Pub/Sub-Mechanismus und/oder Nachrichtenbroker-Mechanismen) abonnieren.
Wenn verfügbar, kann der LS autorisierte MEC-Apps 1826 mit ortsbezogenen Informationen versorgen und derartige Informationen für die MEC-Apps 1826 offenlegen. Mit ortsbezogenen Informationen führen die MEC-Plattform 1832 oder eine oder mehrere MEC-Apps 1826 eine aktive Vorrichtungsortsverfolgung, ortsbasierte Dienstempfehlungen und/oder andere ähnliche Dienste aus. Der LS unterstützt den Standortabrufmechanismus, zum Beispiel wird der Standort nur einmal für jede Standortinformationsanforderung gemeldet. Der LS unterstützt zum Beispiel einen Standortteilnehmermechanismus, wobei der Standort mehrere Male für jede Standortanfrage gemeldet werden kann, periodisch oder basierend auf spezifischen Ereignissen, wie etwa Standortänderung. Die Standortinformationen können unter anderem den Standort spezifischer UEs 1820, die aktuell von dem oder den Funkknoten(en) bedient werden, die mit dem MEC-Server 1802 assoziiert sind, Informationen über den Standort aller UEs 1820, die aktuell von dem einen oder den mehreren Funkknoten bedient werden, die mit dem MEC-Server XE136 assoziiert sind, Informationen über den Standort einer ermittelten Kategorie von UEs 1820, die gegenwärtig von dem einen oder den mehreren Funkknoten bedient werden, die mit dem MEC-Server XE136 assoziiert sind, eine Liste von UEs 1820 an einem ermittelten Standort, Informationen über den Standort aller Funkknoten, die gegenwärtig mit dem MEC-Host 1802 assoziiert sind, und/oder dergleichen beinhalten. Die Standortinformationen können in Form einer Geolokation, einer Koordinate des globalen Navigationssatellitensystems (GNSS-Koordinate), einer Zellenidentität (Zellen-ID) und/oder dergleichen vorliegen. Der LS ist über die API zugänglich, die in der Spezifikation der Open Mobile Alliance (OMA) „RESTful-Network API for Zonal Preference“ OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C definiert ist. Der Zonenpräsenzdienst nutzt das Konzept einer „Zone“, wobei eine Zone verwendet werden kann, um alle Funkknoten, die mit einem MEC-Host 1802 assoziiert sind, oder eine Teilmenge davon, gemäß einer gewünschten Bereitstellung zu gruppieren. In diesem Hinblick stellt die OMA-Zonenpräsenz-API Mittel für MEC-Apps 1826 bereit, um Informationen über eine Zone, die mit den Zonen assoziierten Zugangspunkte und die Benutzer, die mit den Zugangspunkten verbunden sind, abzurufen. Zusätzlich erlaubt die OMA-Zonenpräsenz-API, dass eine autorisierte Anwendung einen Benachrichtigungsmechanismus abonniert, wobei sie Benutzeraktivitäten innerhalb einer Zone meldet. Ein MEC-Server 1802 kann unter Verwenden der OMA-Zonenpräsenz-API auf Ortsinformationen oder Zonenpräsenzinformationen einzelner UEs 1820 zugreifen, um den relativen Standort oder die relativen Positionen der UEs 1820 zu identifizieren.
Der TMS ermöglicht es Edge-Anwendungen, über verschiedene Verkehrsverwaltungsfähigkeiten und Mehrfachzugriffsnetzwerkverbindungsinformationen informiert zu werden, und ermöglicht es Edge-Anwendungen, Anforderungen, z. B. Verzögerung, Durchsatz, Verlust, zum Beeinflussen von Verkehrsverwaltungsoperationen bereitzustellen. Bei manchen Implementierungen beinhaltet der TMS Mehrfachzugriffsverkehrslenkung (MTS), die nahtlos Lenken, Aufteilen und Duplizieren von Anwendungsdatenverkehr über Mehrfachzugriffsnetzverbindungen durchführt. Der BWMS stellt die Zuweisung von Bandbreite zu bestimmtem Verkehr bereit, der zu und von MEC-Apps 1826 geroutet wird, und spezifiziert statische/dynamische Aufwärts/Abwärts-Bandbreitenressourcen, einschließlich Bandbreitengröße und Bandbreitenpriorität. Die MEC-Apps 1826 können den BWMS verwenden, um Bandbreiteninformationen zu/von der MEC-Plattform 1832 zu aktualisieren/zu empfangen. Unterschiedliche MEC-Anwendungen 1826, die parallel auf demselben MEC-Server 1802 laufen, können spezifische statische, dynamische Aufwärts/Abwärts-Bandbreitenressourcen zugewiesen werden, einschließlich Bandbreitengröße und Bandbreitenpriorität. Das BWMS beinhaltet eine Bandbreitenverwaltungs(BWM)-API, um registrierten Anwendungen zu ermöglichen, sich statisch und/oder dynamisch für spezifische Bandbreitenzuweisungen pro Sitzung/Anwendung zu registrieren. Die BWM-API beinhaltet HTTP-Protokollbindungen für BWM-Funktionalität unter Verwendung von RESTfül-Diensten oder einem anderen geeigneten API-Mechanismen. Der BWM-Dienst dient zum Zuweisen/Anpassen von BW-Ressourcen für MEC-Apps und ermöglicht MEC-Apps, ihre BW-Anforderungen bereitzustellen.
Verschiedene MEC-Anwendungen(-Apps), die parallel auf demselben MEC-Host laufen, können spezifische statische/dynamische Aufwärts-/Abwärts-Bandbreitenressourcen (BW-Ressourcen) erfordern, einschließlich BW-Größe und BW-Priorität. Teilweise können verschiedene Sitzungen, die auf derselben App parallel laufen, jeweils spezifische BW-Anforderungen aufweisen. Zusätzlich dazu können Sitzungen, die von Apps gesteuert werden, die näher an Endbenutzern (z. B. kürzere RTT) ausgeführt werden, einen unfairen Vorteil gegenüber Sitzungen erhalten, die von Apps gesteuert werden, die an entfernten Standorten (z. B. außerhalb des RAN) ausgeführt werden. Um potentielle Ressourcenkonflikte zwischen solchen konkurrierenden Anwendungen zu lösen, können BWM und/oder Mehrfachzugriffsverkehrslenkungs(MTS)-Dienste verwendet werden.
Die MTS-Dienste können als Teil des BWMS oder getrennt vom BWMS bereitgestellt werden. Der MTS-Dienst dient zum nahtlosen Lenken/Aufteilen/Duplizieren von App-Datenverkehr über Mehrfachzugriffsnetzwerkverbindungen. Der MTS-Dienst erlaubt es Apps/MEC-Apps, über verschiedene MTS-Fähigkeiten und MX-Netzwerkverbindungs-Info informiert zu werden. Das MTS ermöglicht MEC-Apps auch, Anforderungen (z. B. Verzögerung, Durchsatz, Verlust usw.) zum Beeinflussen von Verkehrsverwaltungsoperationen bereitzustellen. Die spezifische Sitzung oder App/MEC-App kann unter Verwendung eines Satzes von Filtern und/oder Identifikatoren (IDs) innerhalb der Ressourcenanforderung identifiziert werden.
Der Zweck des UE-Identitätsmerkmals besteht darin, UE-spezifische Verkehrsregeln in dem MEC-System 1800 zu erlauben. Wenn das MEC-System 1800 das UE-Identitätsmerkmal unterstützt, stellt die MEC-Plattform 1832 die Funktionalität (zum Beispiel eine UE-Identitäts-API) für eine MEC-App 1826 bereit, um ein Tag, das ein UE 1820 darstellt, oder eine Liste von Tags, die jeweilige UEs 1820 darstellen, zu registrieren. Jedes Tag wird in ein spezifisches UE 1820 in dem System des MNO abgebildet, und die Abbildungsinformationen werden der MEC-Plattform 1832 bereitgestellt. Die UE-Identitätstag-Registrierung löst die MEC-Plattform 1832 aus, um die eine oder mehreren entsprechenden Verkehrsregeln 1840, die mit dem Tag verknüpft sind, zu aktivieren. Die MEC-Plattform 1832 stellt auch die Funktionalität (zum Beispiel eine UE-Identitäts-API) für eine MEC-App 1826 bereit, um eine Abmeldeprozedur aufzurufen, um die Verwendung der Verkehrsregel für diesen Benutzer zu deaktivieren oder anderweitig zu stoppen.
Der WAIS ist ein Dienst, der Dienstverbrauchern innerhalb des MEC-Systems 1800 mit einem WLAN-Zugriff verbundene Informationen bereitstellt. Der WAIS ist für autorisierte MEC-Apps 1826 verfügbar und wird über den Mp1-Bezugspunkt entdeckt. Die Granularität der WLAN-Zugriffsinformationen kann basierend auf Parametern, wie etwa Informationen pro Station, pro NAN/AP oder pro mehreren APs (Multi-AP), angepasst werden. Die WLAN-Zugangsinformationen können von den Dienstkonsumenten genutzt werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen von WLAN-APs basieren, möglicherweise kombiniert mit den Informationen wie RNI oder Festzugangsnetzwerkinformationen. Der WAIS definiert Protokolle, Datenmodelle und Schnittstellen in Form von RESTfül-APIs. Informationen über die APs und Clientstationen können entweder durch Abfragen oder durch Subskribieren von Benachrichtigungen angefordert werden, die jeweils Attribut-basierte Filterung und Attribut-Selektoren beinhalten.
Der FAIS ist ein Dienst, der Dienstverbrauchern innerhalb des MEC-Systems 1800 mit Festzugangsnetzinformationen (oder FAI) bereitstellt. Der FAIS ist für die autorisierten MEC-Apps 1826 verfügbar und wird über den Mp1-Bezugspunkt entdeckt. Die FAI kann von den MEC-Apps 1826 und der MEC-Plattform 1832 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen vom festen Zugang (zum Beispiel NANs) basieren, möglicherweise kombiniert mit anderen Informationen, wie etwa RI- oder WLAN-Informationen, von anderen Zugangstechnologien. Dienstverbraucher interagieren mit dem FAIS über die FAI-API, um Kontextinformationen vom Festzugangsnetzwerk zu erhalten. Sowohl die MEC-Apps 1826 als auch die MEC-Plattform 1832 können den FAIS verbrauchen; und sowohl die MEC-Plattform 1832 als auch die MEC-Apps 1826 können die Anbieter der FAI sein. Die FAI-API unterstützt sowohl Anfragen als auch Subskriptionen (Pub/Sub-Mechanismus), die über die RESTful-API oder über alternative Transportwege, wie einen Nachrichtenbus, verwendet werden. Alternative Transportwege können auch verwendet werden.
Die MEC-Verwaltung umfasst MEC-Systemebenenverwaltung und MEC-Hostebenenverwaltung. Die MEC-Verwaltung umfasst den MEC-Plattformmanager 1806 und den VI-Manager (VIM) 1808 und handhabt die Verwaltung der MEC-spezifischen Funktionalität eines bestimmten MEC-Servers 1802 und der darauf laufenden Anwendungen. Bei einigen Implementierungen können einige oder alle der Mehrfachzugriffs-Edge-Verwaltungskomponenten von einem oder mehreren Server umgesetzt werden, die sich in einem oder mehreren Rechenzentren befinden, und können Virtualisierungsinfrastruktur verwenden, die mit NFV-Infrastruktur verbunden ist, die zum Virtualisieren von NFs verwendet wird, oder dieselbe Hardware wie die NFV-Infrastruktur verwenden.
Der MEC-Plattformmanager 1806 ist für das Verwalten des Lebenszyklus von Anwendungen zuständig, einschließlich Informieren des MEC-Orchestrators (MEC-O) 1810 über relevante anwendungsbezogene Ereignisse. Der MEC-Plattformmanager 1806 kann der MEC-Plattform 1832 auch MEC-Plattformelement-Verwaltungsfunktionen 1844 bereitstellen, MEC-App-Regeln und Anforderungen 1846 einschließlich Dienstberechtigungen, Verkehrsregeln, DNS-Konfiguration und Lösen von Konflikten verwalten sowie die MEC-App-Lebenszyklusverwaltung 1848 verwalten. Der MEC-Plattformmanager 1806 kann auch virtualisierte Ressourcen, Fehlermeldungen und Leistungsfähigkeitsmessungen vom VIM 1808 zur weiteren Verarbeitung empfangen. Der Mm5-Bezugspunkt zwischen dem MEC-Plattformmanager 1806 und der MEC-Plattform 1832 wird verwendet, um Plattformkonfiguration, Konfiguration der MEC-Plattformelementverwaltung 1844, MEC-App-Regeln und -Anforderungen 1846, MEC-App-Lebenszyklusverwaltung 1848 und Verwaltung der Anwendungsumlagerung auszuführen.
Der VIM 1808 kann eine Entität sein, die virtualisierte (Rechen-, Speicher- und Vernetzungs-)Ressourcen der VI 1822 zuweist, verwaltet und freigibt und die VI 1822 auf Ausführung eines Softwareabbilds vorbereitet. Dazu kann der VIM 1808 mit der VI 1822 über den Mm7-Bezugspunkt zwischen dem VIM 1808 und der VI 1822 kommunizieren. Das Vorbereiten der VI 1822 kann das Konfigurieren der VI 1822 und Empfangen/Speichern des Softwareabbilds beinhalten. Wenn unterstützt, kann der VIM 1808 eine schnelle Bereitstellung von Anwendungen bereitstellen, wie etwa in „Openstack++ for Cloudlet Deployments“ beschrieben, das unter http://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf verfügbar ist. Der VIM 1808 kann auch Leistungsfähigkeits- und Fehlerinformationen über die virtualisierten Ressourcen sammeln und melden und eine Anwendungsumlagerung durchführen, wenn unterstützt. Zur Anwendungsumlagerung von/zu externen Cloud-Umgebungen kann der VIM 1808 mit einem externen Cloud-Manager interagieren, um die Anwendungsumlagerung auszuführen, zum Beispiel unter Verwendung des in „Adaptive VM Handoff Across Clouds“ beschriebenen Mechanismus und/oder möglicherweise durch einen Proxy. Darüber hinaus kann der VIM 1808 mit dem MEC-Plattformmanager 1806 über den Mm6-Bezugspunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen zu verwalten, um zum Beispiel die Anwendungslebenszyklusverwaltung zu realisieren. Darüber hinaus kann der VIM 1808 mit dem MEC-0 1810 über den Mm4-Bezugspunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen des MEC-Servers 1802 zu verwalten und Anwendungsabbilder zu verwalten. Das Verwalten der virtualisierten Ressourcen kann das Verfolgen verfügbarer Ressourcenkapazität usw. beinhalten.
Die MEC-Systemebenenverwaltung beinhaltet den MEC-0 1810, der einen Überblick über das vollständige MEC-System 1800 aufweist. Der MEC-0 1810 kann eine Gesamtansicht des MEC-Systems 1800 basierend auf bereitgestellten MEC-Hosts 1802, verfügbaren Ressourcen, verfügbaren MEC-Diensten 1836 und Topologie führen. Der Mm3-Bezugspunkt zwischen dem MEC-0 1810 und dem MEC-Plattformmanager 1806 kann für die Verwaltung des Anwendungslebenszyklus, der Anwendungsregeln und -anforderungen sowie für das Verfolgen verfügbarer MEC-Dienste 1836 verwendet werden. Der MEC-O 1810 kann mit dem Benutzeranwendungslebenszyklusverwaltungs-Proxy (UALMP) 1814 über den Mm9-Bezugspunkt kommunizieren, um MEC-Apps 1826 zu verwalten, die von der UE-App 1818 angefordert werden.
Der MEC-0 1810 kann auch für das Onboarding von Anwendungspaketen verantwortlich sein, einschließlich für das Überprüfen der Integrität und Authentizität der Pakete, Validieren von Anwendungsregeln und Anforderungen sowie, falls notwendig, Anpassen derselben, um Betreiberrichtlinien zu erfüllen, Führen von Aufzeichnungen über Pakete mit abgeschlossenem Onboarding und Vorbereiten des einen oder der mehreren VIMs 1808 zum Handhaben der Anwendungen. Der MEC-0 1810 kann einen oder mehrere geeignete MEC-Hosts 901 zur Anwendungsinstanziierung basierend auf Einschränkungen, wie Latenz, verfügbaren Ressourcen und verfügbaren Diensten, auswählen. Der MEC-0 1810 kann auch Anwendungsinstanziierung und -beendigung auslösen sowie Anwendungsumlagerung nach Bedarf und bei Unterstützung auslösen.
Das Betriebsunterstützungssystem (OSS) 1812 ist das OSS eines Betreibers, der Anfragen über das kundenseitige Dienstportal (CFS-Portal) 1816 über den Mx1-Bezugspunkt und von UE-Apps 1818 zur Instanziierung oder Beendigung von MEC-Apps 1826 empfängt. Das OSS 1812 entscheidet über die Gewährung dieser Anforderungen. Das CFS-Portal 1816 (und die M×1-Schnittstelle) kann von Drittparteien verwendet werden, um das MEC-System 1800 aufzufordern, Apps 1818 in dem MEC-System 1800 auszuführen. Gewährte Anforderungen können an den MEC-O 1810 zur weiteren Verarbeitung weitergeleitet werden. Sofern unterstützt, empfängt das OSS 1812 auch Anforderungen von UE-Apps 1818 zum Umlagern von Anwendungen zwischen externen Clouds und dem MEC-System 1800. Der Mm2-Bezugspunkt zwischen dem OSS 1812 und dem MEC-Plattformmanager 1806 wird für das Konfigurations-, Fehler- und Leistungsfähigkeitsmanagement des MEC-Plattformmanagers 1806 verwendet. Der Mm1-Bezugspunkt zwischen dem MEC-0 1810 und dem OSS 1812 wird zum Auslösen der Instanziierung und dem Beenden von MEC-Apps 1826 in dem MEC-System 1800 verwendet.
Die eine oder die mehreren UE-Apps 1818 (auch als „Vorrichtungsanwendungen“ oder dergleichen bezeichnet) sind eine oder mehrere Apps, die in einer Vorrichtung 1820 ausgeführt werden, die die Fähigkeit aufweist, mit dem MEC-System 1800 über den Benutzeranwendungslebenszyklusverwaltungs-Proxy 1814 zu interagieren. Die eine oder die mehreren UE-Apps 1818 können eine oder mehrere Client-Anwendungen sein, beinhalten oder mit diesen interagieren, bei denen es sich im Kontext von MEC um Anwendungssoftware handelt, die auf der Vorrichtung 1818 läuft, die Funktionalität nutzt, die von einer oder mehreren spezifischen MEC-Apps 1826 bereitgestellt wird. Der Benutzer-App-LZM-Proxy 1814 kann Anforderungen von UE-Apps 1818 im UE 1820 autorisieren und interagiert mit dem OSS 1812 und dem MEC-0 1810 zur weiteren Verarbeitung dieser Anforderungen. Der Begriff „Lebenszyklusverwaltung“ betrifft im Kontext von MEC einen Satz von Funktionen, die erforderlich sind, um die Instanziierung, Pflege und Beendigung einer Instanz einer MEC-App 1826 zu verwalten. Der Benutzer-App-LZM-Proxy 1814 kann über den Mm8-Bezugspunkt mit dem OSS 1812 interagieren und wird verwendet, um Anforderungen des UE 1818 zum Ausführen von Anwendungen im MEC-System 1800 zu handhaben. Eine Benutzer-App kann eine MEC-App 1826 sein, die im MEC-System 1800 als Reaktion auf eine Anforderung eines Benutzers über eine Anwendung instanziiert wird, die in dem UE 1820 läuft (zum Beispiel UE-App 1818). Der Benutzer-App-LZM-Proxy 1814 ermöglicht es UE-Apps 1818, Onboarding, Instanziierung, Beendigung von Benutzeranwendungen und, wenn unterstützt, eine Umlagerung von Benutzeranwendungen in das MEC-System 1800 hinein und aus diesem heraus anzufordern. Sie erlaubt auch ein Informieren der Benutzer-Apps über den Zustand der Benutzer-Apps. Der Benutzer-App-LZM-Proxy 1814 ist nur innerhalb des mobilen Netzwerks zugänglich und ist möglicherweise nur verfügbar, wenn er vom MEC-System 1800 unterstützt wird. Eine UE-App 1818 kann den Mx2-Bezugspunkt zwischen dem Benutzer-App-LZM-Proxy 1814 und der UE-App 1818 verwenden, um das MEC-System 1800 aufzufordern, eine Anwendung in dem MEC-System 1800 auszuführen oder eine Anwendung in das MEC-System 1800 hinein oder aus diesem heraus zu bewegen. Der Mx2-Bezugspunkt kann nur innerhalb des mobilen Netzwerks zugänglich sein und kann nur verfügbar sein, wenn er vom MEC-System 1800 unterstützt wird.
Um eine MEC-Anwendung 1826 im MEC-System 1800 auszuführen, empfängt der MEC-O 1810 Anfragen, die von dem OSS 1812, einer Drittpartei oder einer UE-Anwendung 1818 ausgelöst werden. Als Reaktion auf den Empfang derartiger Anforderungen, wählt der MEC-0 1810 einen MEC-Server/Host 1802 aus, um die MEC-Anwendung 1826 zum rechnerischen Auslagern usw. zu hosten. Diese Anforderungen können Informationen über die auszuführende Anwendung und möglicherweise andere Informationen, wie etwa den Standort, an dem die Anwendung aktiv sein muss, andere Anwendungsregeln und -anforderungen sowie den Standort des Anwendungsabbildes, falls es sich noch nicht in dem MEC-System 1800 befindet, beinhalten.
Der MEC-O 1810 kann einen oder mehrere MEC-Server 1802 für rechenintensive Aufgaben auswählen. Der eine oder die mehreren ausgewählten MEC-Server XE136 können Rechenaufgaben einer UE-App 1818 basierend auf verschiedenen Betriebsparametern, wie etwa Netzwerkfähigkeiten und -bedingungen, Rechenfähigkeiten und -bedingungen, Anwendungsanforderungen und/oder anderen ähnlichen Betriebsparametern, auslagern. Die Anwendungsanforderungen können Regeln und Anforderungen sein, die mit einer oder mehreren MEC-Anwendungen 1826 assoziiert sind, wie etwa ein Bereitstellungsmodell der Anwendung (ob es zum Beispiel eine Instanz pro Benutzer, eine Instanz pro Host, eine Instanz auf jedem Host usw. ist); erforderliche virtualisierte Ressourcen (zum Beispiel Rechen-, Speicher-, Netzwerkressourcen, einschließlich spezifischer Hardwareunterstützung); Latenzanforderungen (zum Beispiel maximale Latenz, wie streng die Latenzbeschränkungen sind, Latenzfairness zwischen Benutzern); Anforderungen in Bezug auf den Standort; Mehrfachzugriffs-Edge-Dienste, die erforderlich und/oder nützlich sind, damit die MEC-Anwendungen 1826 laufen können; Mehrfachzugriffs-Edge-Dienste, die die MEC-Anwendungen 1826 nutzen können, falls verfügbar; Konnektivität oder Mobilitätsunterstützung/-anforderungen (zum Beispiel Anwendungszustandsumlagerung, Anwendungsinstanzumlagerung); erforderliche Mehrfachzugriffs-Edge-Merkmale, wie etwa VM-Umlagerungsunterstützung oder UE-Identität; erforderliche Netzwerkkonnektivität (zum Beispiel Konnektivität mit Anwendungen innerhalb des MEC-Systems 1800, Konnektivität mit lokalen Netzwerken oder mit dem Internet); Informationen über die Bereitstellung des MEC-Systems 1800 des Betreibers oder die Bereitstellung des des mobilen Netzwerks (zum Beispiel Topologie, Kosten); Anforderungen an den Zugriff auf Benutzerverkehr; Anforderungen an eine dauerhafte Speicherung; Verkehrsregeln 1840; DNS-Regeln 1842; usw.
Der MEC-0 1810 berücksichtigt die oben aufgelisteten Anforderungen und Informationen sowie Informationen über die aktuell im MEC-System 1800 verfügbaren Ressourcen, um einen oder mehrere MEC-Server 1802 zum Hosten von MEC-Anwendungen 1826 und/oder zum rechnerischen Auslagern auszuwählen. Nachdem ein oder mehrere MEC-Server XE136 ausgewählt wurden, fordert der MEC-O 1810 den oder die ausgewählten MEC-Hosts 1802 auf, die eine oder die mehreren Anwendungen oder Anwendungsaufgaben zu instanziieren. Der tatsächliche Algorithmus, der zum Auswählen der MEC-Server 1802 verwendet wird, hängt von der Implementierung, Konfiguration und/oder Betreiberbereitstellung ab. Der eine oder die mehreren Auswahlalgorithmen können auf den Aufgaben-Auslagerungskriterien/-parametern basieren, indem zum Beispiel Netzwerk-, Rechen- und Energieverbrauchsanforderungen zum Ausführen von Anwendungsaufgaben sowie Netzwerkfunktionalitäten, Verarbeiten und Auslagerungs-Codes/Codierungen oder Unterscheiden von Verkehr zwischen verschiedenen RATs berücksichtigt werden. Unter gewissen Umständen (zum Beispiel UE-Mobilitätsereignisse, die zu erhöhter Latenz führen, Lastausgleichsentscheidungen usw.), und, sofern unterstützt, kann der MEC-O 1810 entscheiden, einen oder mehrere neue MEC-Hosts 1802 auszuwählen, die als ein Primär-/Quellknoten fungieren sollen, und initiiert die Übertragung einer Anwendungsinstanz oder anwendungsbezogener Zustandsinformationen von dem einen oder den mehreren Quell-MEC-Hosts 1802 zu dem einen oder den mehreren Ziel-MEC-Hosts 1802.
Bei einer ersten Implementierung wird eine UPF des 5GS als die MEC-Datenebene 1824 in die MEC-Architektur 1800 abgebildet. Bei dieser Implementierung handhabt die UPF den UP-Pfad von PDU-Sitzungen. Außerdem stellt die UPF die Schnittstelle zu einem Datennetzwerk bereit und unterstützt die Funktionalität eines PDU-Sitzungsankers.
Bei einer zweiten Implementierung wird eine Anwendungsfunktion (AF) des 5GS als die MEC-Plattform 1832 in die MEC-Architektur 1800 abgebildet. Bei diesen Implementierungen ist die AF konfigurierbar oder betreibbar, um einen Anwendungseinfluss auf Verkehrsrouten durchzuführen, auf eine Netzwerkfähigkeitsoffenlegung zuzugreifen und mit dem Richtlinienrahmen zur Richtliniensteuerung zu interagieren. Die zweite Implementierung kann mit der ersten Implementierung kombiniert werden oder kann eine eigenständige Implementierung sein. Da Benutzerverkehr bei der ersten und/oder zweiten Implementierung zu dem lokalen DN geleitet wird, können die MEC-Apps 1826, 1827 und/oder 1828 in oder auf das DN des 5GS abgebildet werden.
Bei einer dritten Implementierung kann das RAN von 5GS ein virtuelles RAN basierend auf einer VNF sein, und die UPF ist konfigurierbar oder funktionsfähig, um als die MEC-Datenebene 1824 innerhalb einer NF-Virtualisierungsinfrastruktur (NFVI) (z. B. VI 1822) zu fungieren. Bei diesen Implementierungen kann die AF als MEC-Plattform-VNF mit MEC-APIs, MEC-App-Aktivierungsfunktionalität (siehe z. B. [MEC009]) und API-Prinzipienfunktionalität (siehe z. B. [MEC009]) konfiguriert sein. Zusätzlich dazu kann das lokale DN die MEC-Apps 1826, 1827 und/oder 1828 beinhalten, die als VNFs instanziiert sind. Diese Implementierung kann ausgelegt sein, Funktionalitäten gemäß [MEC003] und/oder ETSI GR MEC 017 V1.1.1 (2018-02) („[MEC017]“) bereitzustellen. Die dritte Implementierung kann mit der ersten Implementierung und/oder der zweiten Implementierung kombiniert werden oder kann eine eigenständige Implementierung sein.
Zusätzlich oder alternativ kann die Zugangsebenen-Edge (zum Beispiel die verschiedenen hierin besprochenen NANs und/oder (R)ANs) eine oder mehrere APIs verwenden, um mit Edge-Netzwerken auf lokaler/regionaler Ebene zu kommunizieren. Die Edge-Netzwerke auf lokaler/regionaler Ebene können Netzwerkknoten beinhalten, die entsprechende Anwendungen verwenden, um mit einem Edge-Netzwerk auf nationaler Ebene zu kommunizieren. Die Edge auf nationaler Ebene kann verschiedene NANs beinhalten, die Anwendungen zum Zugreifen auf eine oder mehrere entfernte Clouds innerhalb der Edge auf globaler Ebene verwenden. Die NANs sind auch für vertikale Segmentverwaltung und SLA-Einhaltung konfigurierbar oder betreibbar. Zusätzlich oder alternativ dazu kann die MEC-Bereitstellung auf der Definition von „Edge“ basieren, um MNOs Freiheitsgrade bereitzustellen, insbesondere wenn MEC in einer NFV-Uumgebung bereitgestellt wird (MEC-Entitäten können z. B. können als virtualisierte NFs (VNFs) instanziiert werden, somit mit hoher Flexibilität hinsichtlich der Bereitstellung für den Bediener).
Zusätzlich oder alternativ dazu kann das MEC-System 1800 in Abhängigkeit vom Anwendungsfall/vom vertikalen Segment/von den zu verarbeitenden Informationen flexibel eingesetzt werden. Manche Komponenten des MEC-Systems 1800 können gemeinsam mit anderen Elementen des Systems angeordnet sein. Als ein Beispiel muss eine MEC-App 1826 in bestimmten Anwendungsfällen (z. B. Unternehmen) möglicherweise einen MEC-Dienst lokal konsumieren, und es kann effizient sein, einen MEC-Host lokal bereitzustellen, der mit dem benötigten Satz von APIs ausgestattet ist. In einem anderen Beispiel muss das Bereitstellen eines MEC-Servers 1802 einem Rechenzentrum (das von dem Zugangsnetzwerk entfernt sein kann) möglicherweise einige APIs nicht hosten, wie die RNI-API (die zum Sammeln von Funknetzwerkinformationen von der Funkbasisstation verwendet werden kann). Andererseits können RNI-Informationen in den Cloud-RAN-Umgebungen (CRAN-Umgebungen) am Aggregationspunkt ausgearbeitet und bereitgestellt werden, wodurch die Ausführung geeigneter funkbewusster Verkehrsverwaltungsalgorithmen ermöglicht wird. Zusätzlich oder alternativ kann eine Bandbreitenverwaltungs-API sowohl auf der Zugriffsebene-Edge als auch an entfernteren Edge-Standorten vorhanden sein, um Transportnetze (z. B. für CDN-basierte Dienste) einzurichten.
19 veranschaulicht eine beispielhafte MEC-Dienstarchitektur 1900. Die MEC-Dienstarchitektur 1900 beinhaltet den MEC-Dienst 1905, die ME-Plattform 1910 (die der MEC-Plattform 1832 entspricht) sowie Anwendungen (Apps) 1 bis N (wobei N eine Zahl ist). Als ein Beispiel kann die App 1 ein(e) CDN-App/Dienst sein, die (der) 1 bis n Sitzungen hostet (wobei n eine Zahl ist, die gleich oder von N unterschiedlich ist), App 2 kann ein(e) Gaming-App/Dienst sein, die (der) als zwei Sitzungen hostend gezeigt ist, und App N kann irgendein(e) andere(r) App/Dienst sein, die (der) als eine einzelne Instanz (zum Beispiel keine Sitzungen hostend) gezeigt ist. Jede App kann eine verteilte Anwendung sein, die Aufgaben und/oder Arbeitslasten zwischen Ressourcenanbietern (zum Beispiel Servern, wie etwa der ME-Plattform 1910) und Verbrauchern (zum Beispiel UEs 101, Benutzerapps, die von einzelnen UEs 101 instanziiert werden, anderen Servern/Diensten, Netzwerkfunktionen, Anwendungsfunktionen usw.) partitioniert. Jede Sitzung stellt einen interaktiven Informationsaustausch zwischen zwei oder mehr Elementen dar, wie etwa einer clientseitigen App und ihrer entsprechenden serverseitigen App, einer von einem UE 101 instanziierten Benutzerapp und einer von der ME-Plattform 1910 instanziierten MEC-App und/oder dergleichen. Eine Sitzung kann beginnen, wenn die App-Ausführung gestartet oder initiiert wird, und enden, wenn die App die Ausführung verlässt oder beendet. Zusätzlich oder alternativ kann eine Sitzung beginnen, wenn eine Verbindung aufgebaut wird, und enden, wenn die Verbindung beendet wird. Jede App-Sitzung kann einer aktuell laufenden App-Instanz entsprechen. Zusätzlich oder alternativ dazu kann jede Sitzung einer Protokolldateneinheits(PDU)-Sitzung oder Mehrfachzugriffs(MA)-PDU-Sitzung entsprechen. Eine PDU-Sitzung ist eine Assoziation zwischen einem UE 1111, 1121 und einem DN, das einen PDU-Konnektivitätsdienst bereitstellt, der ein Dienst ist, der den Austausch von PDUs zwischen einem UE 1111, 1121 und einem Datennetzwerk bereitstellt. Eine MA-PDU-Sitzung ist eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der jeweils ein Zugangsnetzwerk oder gleichzeitig ein 3GPP-Zugangsnetzwerk 110A und ein Nicht-3GPP-Zugangsnetzwerk 110B verwenden kann. Ferner kann jede Sitzung mit einer Sitzungskennung (ID) assoziiert sein, die Daten sind, die eindeutig eine Sitzung identifizieren, und jede App (oder App-Instanz) kann mit einer App-ID (oder APP-Instanz-ID) assoziiert sein, die Daten sind, die eindeutig eine App (oder App-Instanz) identifizieren.
Der MEC-Dienst 1905 stellt MEC-Dienstverbrauchern (zum Beispiel Apps 1 bis N) einen oder mehrere MEC-Dienste 1836 bereit. Der MEC-Dienst 1905 kann optional als Teil der Plattform (zum Beispiel ME-Plattform 1910) oder als Anwendung (zum Beispiel ME-App) laufen. Unterschiedliche Apps 1 bis N, unabhängig davon, ob sie eine einzige Instanz oder mehrere Sitzungen verwalten (zum Beispiel ein CDN), können spezifische Dienstinfo gemäß ihren Anforderungen für die gesamte Anwendungsinstanz oder unterschiedliche Anforderungen pro Sitzung anfordern. Der MEC-Dienst 1905 kann alle Anforderungen aggregieren und auf eine Weise agieren, die helfen wird, die BW-Nutzung zu optimieren und Erlebnisqualität (QoE) für Anwendungen zu verbessern.
Der MEC-Dienst 1905 stellt eine MEC-Dienst-APIbereit, die sowohl Anfragen als auch Subskriptionen (zum Beispiel Pub/Sub-Mechanismus) unterstützt, die über eine Representational-State-Transfer-API („REST“ oder „RESTful“-API) oder über alternative Transporte, wie etwa einen Nachrichtenbus, verwendet werden. Für den RESTful-Architekturstil enthalten die MEC-APIs die HTTP-Protokollbindungen für Verkehrsverwaltungsfunktionalität.
Jede Hypertext-Transfer-Protocol-Nachricht (HTTP-Nachricht) ist entweder eine Anfrage oder eine Antwort. Ein Server hört eine Verbindung auf eine Anforderung hin ab, parst jede empfangene Nachricht, interpretiert die Nachrichtensemantik in Bezug auf das identifizierte Anforderungsziel und beantwortet diese Anforderung mit einer oder mehreren Antwortnachrichten. Ein Client konstruiert Anforderungsnachrichten, um spezifische Absichten zu kommunizieren, untersucht empfangene Antworten, um zu sehen, ob die Absichten ausgeführt wurden, und ermittelt, wie die Ergebnisse interpretiert werden sollen. Das Ziel einer HTTP-Anforderung wird als „Ressource“ bezeichnet. Zusätzlich oder alternativ ist eine „Ressource“ ein Objekt mit einem Typ, assoziierten Daten, einem Satz von Verfahren, die diese bearbeiten, und gegebenenfalls Beziehungen zu anderen Ressourcen. Jede Ressource wird von mindestens einem Uniform Ressource Identifier (URI) identifiziert, und ein Ressource-URI identifiziert maximal eine Ressource. Ressourcen werden von der RESTful-API mit HTTP-Verfahren (zum Beispiel POST, GET, PUT, DELETE usw.) bearbeitet. Bei jedem HTTP-Verfahren wird ein Ressource-URI in der Anforderung zur Adressierung einer ermittelten Ressource übermittelt. Operationen auf Ressourcen beeinflussen den Zustand der entsprechenden verwalteten Entitäten.
In Anbetracht dessen, dass eine Ressource beliebig sein könnte, und dass die einheitliche Schnittstelle, die von HTTP bereitgestellt wird, einem Fenster ähnlich ist, durch das ein derartiges Ding nur durch die Kommunikation von Nachrichten an irgendeinem unabhängigen Akteur auf der anderen Seite beobachten und darauf einwirken kann, ist eine Abstraktion erforderlich, um den aktuellen oder gewünschten Zustand dieses Dings in unserer Kommunikation darzustellen („an Stelle treten von“). Diese Abstraktion wird als eine Repräsentation bezeichnet. Für die Zwecke von HTTP ist eine „Repräsentation“ Informationen, die einen vergangenen, aktuellen oder gewünschten Zustand einer gegebenen Ressource in einem Format widerspiegeln soll, das leicht über das Protokoll kommuniziert werden kann. Eine Darstellung umfasst einen Satz von Repräsentationsmetadaten und einen potenziell unbegrenzten Strom von Repräsentationsdaten. Zusätzlich oder alternativ ist eine Ressourcenrepräsentation eine Serialisierung eines Ressourcenzustands in einem bestimmten Inhaltsformat.
Ein Ursprungsserver könnte mit mehreren Repräsentationen versehen sein oder in der Lage sein, mehrere Repräsentationen zu erzeugen, die jeweils den aktuellen Zustand einer Zielressource widerspiegeln sollen. In solchen Fällen wird irgendein Algorithmus vom Ursprungsserver verwendet, um eine dieser Repräsentationen als am besten für eine gegebene Anforderung anwendbar auszuwählen, üblicherweise basierend auf Inhaltsverhandlung. Diese „ausgewählte Repräsentation“ wird verwendet, um die Daten und Metadaten zum Auswerten bedingter Anforderungen bereitzustellen, die die Nutzlast für Antwortnachrichten konstruieren (z. B. 200 OK, 304 Nicht modifiziert Antworten auf GET und dergleichen). Eine Ressourcenrepräsentation ist im Nutzlastkörper einer HTTP-Anforderung oder Antwortnachricht enthalten. Ob eine Repräsentation in einer Anfrage erforderlich ist oder nicht erlaubt ist, hängt vom verwendeten HTTP-Verfahren ab (siehe z. B. Fielding et al., „Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content“, IETF RFC 7231 (Juni 2014)).
Die MEC-API-Ressourcen-Universal-Resource-Indicators (URIs) sind in verschiedenen ETSI-MEC-Standards besprochen, wie etwa den hierin erwähnten. Die MTS-API unterstützt zusätzliche anwendungsbezogene Fehlerinformationen, die in der HTTP-Antwort bereitgestellt werden sollen, wenn ein Fehler auftritt (siehe z. B. Klausel 6.15 von ETSI GS MEC 009 V2.1.1 (2019-01) („[MEC009]“)). Die Syntax jeder Ressourcen-URI folgt [MEC009] sowie Berners-Lee et al., „Uniform Resource Identifier (URI): Generic Syntax“, IETF Network Working Group, RFC 3986 (Januar 2005), und/oder Nottingham, „URI Design and Ownership“, IETF RFC 8820 (Juni 2020). In den RESTful-MEC-Dienst-APIs, einschließlich der VIS-API, weist die Ressourcen-URI-Struktur für jede API die folgende Struktur auf: {apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}
Hier beinhaltet „apiRoot“ das Schema („https“), den Host und den optionalen Port sowie eine optionale Präfixzeichenfolge. Der „apiName“ definiert den Namen der API (zum Beispiel MTS-API, RNI-API usw.). „apiVersion“ stellt die Version der API dar, und die „apiSpecificSuffixes“ definieren den Baum von Ressourcen-URIs in einer bestimmten API. Die Kombination von „apiRoot“, „apiName“ und „apiVersion“ wird als Stamm-URI bezeichnet. „apiRoot“ steht unter der Kontrolle der Bereitstellung, während die übrigen Teile des URI unter der Kontrolle der API-Spezifikation stehen. In der obigen Wurzel werden „apiRoot“ und „apiName“ unter Verwenden der Dienstregistrierungsdatenbank (siehe zum Beispiel Dienstregistrierungsdatenbank 1838 in 18) entdeckt. Es beinhaltet das Schema („http“ oder „https“), den Host und den optionalen Port sowie eine optionale Präfixzeichenfolge. Für eine gegebene MEC-API kann der „apiName“ auf „mec“ gesetzt werden, und „apiVersion“ kann auf eine geeignete Versionsnummer gesetzt werden (zum Beispiel „v1“ für Version 1). Die MEC-APIs unterstützen HTTP über TLS (auch als HTTPS bekannt). Alle Ressourcen-URIs in den MEC-API-Prozeduren sind relativ zum obigen Root-URI definiert.
Das JSON-Inhaltsformat kann auch unterstützt werden. Das JSON-Format wird durch den Inhaltstyp „application/json“ signalisiert. Die MTS-API kann den OAuth-2.0-Client-Berechtigungsnachweiserteilungstyp mit Träger-Token verwenden (siehe z. B. [MEC009]). Der Token-Endpunkt kann als Teil der in [MEC009] definierten Dienstverfügbarkeitsabfrageprozedur entdeckt werden. Die Client-Zugangsdaten können unter Verwendung bekannter Bereitstellungsmechanismen in die MEC-App bereitgestellt werden.
4.2. Open-RAN(O-RAN)-Aspekte
20 veranschaulicht eine beispielhafte Open-RAN(O-RAN)-Systemarchitektur 2000 gemäß verschiedenen Ausführungsformen. Die O-RAN-Architektur 2000 beinhaltet vier O-RAN-definierte Schnittstellen - nämlich die A1-Schnittstelle, die O1-Schnittstelle, die O2-Schnittstelle und die Open-Fronthaul-Management(M)-Ebenen-Schnittstelle -, die das Dienstverwaltungs- und Orchestrierungs-Framework (SMO) 2002 mit O-RAN-Netzwerkfunktionen (NFs) 2004 und der O-Cloud 2006 verbinden.
Die O1-Schnittstelle ist eine Schnittstelle zwischen Orchestrierungs- und Verwaltungsentitäten (Orchestrierung/NMS) und O-RAN-verwalteten Elementen für Betrieb und Verwaltung, durch die FCAPS-Verwaltung, Softwareverwaltung, Dateiverwaltung und andere ähnliche Funktionen erreicht werden sollen (siehe z. B. O-RAN Alliance Working Group (WG) 1, „O-RAN Architecture Description“ v04.00 (März 2021) („[O-RAN.WGl.O-RAN-Architecture-Description-v04.00]“), O-RAN Alliance WG6, „Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN“ v02.01 (Juli 2020) („[O-RAN.WG6.CAD-v02.01]“). Die 02-Schnittstelle ist eine Schnittstelle zwischen dem Dienstverwaltungs- und Orchestrierungs-Framework und der O-Cloud (siehe z. B. [O-RAN.WG1.0-RAN-Architecture-Description-v04.00], [0-RAN.WG6.CAD-v02.01]). Die A1-Schnittstelle ist eine Schnittstelle zwischen der intelligenten O-RAN-Nicht-Echzeit(RT)-Steuerung (RIC) 2012 und der Nahezu-RT-RIC 2014, um eine richtliniengesteuerte Führung von Nahezu-RT-RIC-Anwendungen/Funktionen zu ermöglichen und einen KI/ML-Arbeitsablauf zu unterstützen.
Das SMO 2002 (siehe z. B. O-RAN Alliance WG1, „O-RAN Operations and Maintenance Interface Specification“ v04.00 (Nov. 2020) („[O-RAN. WG1.O1-Interface.0-v04.00]“)) ist auch mit einem externen System 2010 verbunden, das dem SMO 2002 Anreicherungsdaten bereitstellt. 20 veranschaulicht auch, dass die A1-Schnittstelle an einer intelligenten O-RAN-Nicht-Echzeit(RT)-Steuerung (RIC) 2012 in oder an dem SMO 2002 und an der O-RAN Nahezu-RT RIC 2014 in oder an den O-RAN-NFs 2004 endet. Die O-RAN-NFs 2004 können VNFs sein, wie etwa VMs oder Container, die über der O-Cloud 2006 sitzen, und/oder physische Netzwerkfunktionen (PNFs), die angepasste Hardware nutzen. Es wird erwartet, dass alle O-RAN-NFs 2004 die O1-Schnittstelle unterstützen, wenn sie über eine Schnittstelle an das SMO 2002 anbinden.Die O-RAN-NFs 2004 sind über die NG-Schnittstelle (die eine von 3GPP definierte Schnittstelle ist) mit dem NG-Kern 2008 verbunden. Die Open-Fronthaul-M-Ebenen-Schnittstelle zwischen dem SMO 2002 und der O-RAN-Funkeinheit (O-RU) 2016 unterstützt die Verwaltung der O-RU 2016 im O-RAN-Hybridmodell, wie in O-RAN Alliance WG4, O-RAN Fronthaul Management Plane Specification, Version 2.0 (Juli 2019) ( „[ORAN-WG4.MP.O-v02.00.00]“) spezifiziert. Die Open-Fronthaul-M-Ebenen-Schnittstelle ist eine optionale Schnittstelle mit dem SMO 2002, die zu Rückwärtskompatibilitätszwecken gemäß [ORAN-WG4.MP.0-v02.00.00] enthalten ist und nur zur Verwaltung der O-RU 2016 im Hybridmodus bestimmt ist. Die Verwaltungsarchitektur von Flachmodus-O-RAN-Alliance WG1, „O-RAN Operations and Maintenance Architecture Specification“ v04.00 (Nov. 2020) („[O-RAN.WG1,OAM-Architecture-v04,00]“) und deren Beziehung zu der O1-Schnittstelle für die O-RU 2016 ist Aufgabe zukünftiger Untersuchungen. Der Abschluss der O-RU 2016 der O1-Schnittstelle zum SMO 2002 hin, wie in [O-RAN.WG1.OAM-Architecture-v04.00] spezifiziert.
21 veranschaulicht eine logische Architektur 2100 der O-RAN-Systemarchitektur 2000 von 20. In 21 entspricht das SMO 2102 dem SMO 2002, die O-Cloud 2106 entspricht der O-Cloud 2006, die Nicht-RT-RIC 2112 entspricht der Nicht-RT-RIC 2012, die Nahezu-RT-RIC 2114 entspricht der Nahezu-RT-RIC 2014 bzw. die O-RU 2116 entspricht der O-RU 2016 aus 21. Die logische O-RAN-Architektur 2100 beinhaltet einen Funkabschnitt und einen Verwaltungsabschnitt.
Der Verwaltungsabschnitt/die Verwaltungsseite der Architekturen 2100 beinhaltet das SMO 2102, das die Nicht-RT-RIC 2112 enthält, und kann die O-Cloud 2106 beinhalten. Die O-Cloud 2106 ist eine Cloud-Rechenplattform, die eine Sammlung physischer Infrastrukturknoten zum Hosten der relevanten O-RAN-Funktionen (z. B. die Nahezu-RT-RIC 2114, die O-CU-CP 2121, die O-CU-UP 2122 und die O-DU 2115), von unterstützenden Softwarekomponenten (z. B. OSs, VMMs, Container-Laufzeit-Engines, ML-Engines usw.) und geeigneten Verwaltungs- und Orchestrierungsfunktionen beinhaltet.
Der Funkabschnitt/die Funkseite der logischen Architektur 2100 beinhaltet die Funktionen der Nahezu-RT-RIC 2114, der verteilten O-RAN-Einheit (O-DU) 2115, der O-RU 2116, der O-RAN-Zentraleinheit - Steuerebene (O-CU-CP) 2121 und der O-RAN-Zentraleinheit - Benutzerebene (O-CU-UP) 2122. Der Funkabschnitt/die Funkseite der logischen Architektur 2100 kann auch den O-e/gNB 2110 beinhalten.
Die O-DU 2115 ist ein logischer Knoten, der Entitäten/Elemente der RLC-, MAC- und höheren PHY-Schichten (High-PHY-Schichten) basierend auf einer Funktionsaufteilung einer niedrigeren Schicht hostet. Die O-RU 2116 ist ein logischer Knoten, der Entitäten/Elemente einer unteren PHY-Schicht (niedrige PHY-Schicht) (z. B. FFT/iFFT, PRACH-Extrahierung usw.) und HF-Verarbeitungselemente basierend auf einer Funktionsaufteilung einer niedrigeren Schicht hostet. Die Virtualisierung der O-RU 2116 ist FFS. Die O-CU-CP 2121 ist ein logischer Knoten, der den RRC- und den Steuerebenen(CP)-Teil des PDCP-Protokolls hostet. Die O-CU-UP 2122 ist ein logischer Knoten, der den Benutzerebenenteil des PDCP-Protokolls und des SDAP-Protokolls hostet.
Eine E2-Schnittstelle endet an einer Vielzahl von E2-Knoten. Die E2-Schnittstelle verbindet die Nahezu-RT-RIC 2114 und eine oder mehrere O-CU-CP 2121, eine oder mehrere O-CU-UP 2122, eine oder mehrere O-DU 2115 und einen oder mehrere O-e/gNB 2110. Die E2-Knoten sind logische Knoten/Entitäten, die die E2-Schnittstelle abschließen. Für NR/5G-Zugriff beinhalten die E2 Knoten die O-CU-CP 2121, die O-CU-UP 2122, die O-DU 2115 oder eine beliebige Kombination von Elementen, wie in -RAN Alliance WG3, „O-RAN Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles“ v01.01 (Juli 2020) („[0-RAN.WG3.E2GAP-v01.01]“) definiert. Für E-UTRA-Zugang weisen die E2-Knoten den O-e/gNB 2110 auf. Wie in 21 gezeigt, verbindet die E2-Schnittstelle auch den O-e/gNB 2110 mit der Nahezu-RT-RIC 2114. Die Protokolle über die E2-Schnittstelle basieren ausschließlich auf Steuerebenen(CP)-Protokollen. Die E2-Funktionen sind in die folgenden Kategorien gruppiert: (a) Dienste für die Nahezu-RT-RIC 2114 (REPORT, INSERT, CONTROL und POLICY, wie in [O-RAN.WG3.E2GAP-v01.01] beschrieben); und (b) Unterstützungsfunktionen für die Nahezu-RT-RIC 2114, die E2-Schnittstellenverwaltung (E2-Einrichtung, E2-Rücksetung, Melden allgemeiner Fehlersituationen usw.) und Nahezu-RT-RIC-Dienstaktualisierung (z. B. Fähigkeitsaustausch in Bezug auf die Liste von E2-Knotenfunktionen, die über E2 freigegeben werden) beinhalten. Ein RIC-Dienst ist ein Dienst, der auf einem E2-Knoten bereitgestellt wird, um Zugriff auf Nachrichten und Messungen bereitzustellen und/oder die Steuerung des E2-Knotens von der Nahezu-RT-RIC zu ermöglichen.
21 zeigt die Uu-Schnittstelle zwischen einem UE 2101 und O-e/gNB 2110 sowie zwischen dem UE 2101 und O-RAN-Komponenten. Die Uu-Schnittstelle ist eine von 3GPP definierte Schnittstelle (siehe z. B. Abschnitte 5.2 und 5.3 von 3GPP TS 38.401 v16.3.0 (2020-10-02) („[TS38401]“)), die einen vollständigen Protokollstapel von L1 bis L3 beinhaltet und im NG-RAN oder E-UTRAN endet. Der O-e/gNB 2110 ist ein LTE-eNB (siehe z. B. 3GPP TS 36.401 v16.0.0 (2020-07-16)), ein 5G-gNB oder ng-eNB 3GPP TS 38.300 v16.3.0 (2020-10-02) („[TS38300]“), der die E2-Schnittstelle unterstützt.
Der O-e/gNB 2110 kann gleich oder ähnlich wie die NANs 1131-1133 sein und das UE 2101 kann gleich oder ähnlich wie beliebige der mit Bezug auf 11 besprochenen UEs 1121, 1111 und/oder dergleichen sein. Es kann mehrere UEs 2101 und/oder mehrere O-e/gNB 2110 geben, die jeweils über jeweilige Uu-Schnittstellen miteinander verbunden sein können. Obwohl dies in 21 nicht gezeigt ist, unterstützt der O-e/gNB 2110 die O-DU 2115 und die O-RU 2116 mit einer Open-Fronthaul-Schnittstelle zwischen ihnen.
Die eine oder die mehreren Open-Fronthaul(OF)-Schnittstellen sind zwischen Funktionen der O-DU 2115 und der O-RU 2116 angeordnet (siehe z. B. [ORAN-WG4.MP.0-v02.00.00], O-RAN Alliance WG4, „O-RAN Fronthaul Control, User and Synchronization Plane Specification 6.0“ v06.00 (März 2021) („[O-RAN-WG4.CUS.0-v06.00]“). Die eine oder die mehreren Schnittstellen beinhalten die Steuerbenutzersynchronisations(CUS)-Ebene und eine Verwaltungsebene (M-Ebene). 20 und 21 zeigen auch, dass die O-RU 2116 die M-Ebenen-Schnittstelle zur O-DU 2115 und optional zum SMO 2102 hin abschließt, wie in [ORAN-WG4.MP.0-v02.00.00] spezifiziert. Die O-RU 2116 schließt die CUS-Ebenenschnittstelle zur O-DU 2115 und zum SMO 2102 hin ab.
Die F1-c-Schnittstelle verbindet die O-CU-CP 2121 mit der O-DU 2115. Wie von 3GPP definiert, befindet sich die F1-c-Schnittstelle zwischen der gNB-CU-CP und gNB-DU-Knoten [TS38401], 3GPP TS 38.470 v16.3.0 (2020-10-02) („[TS38470]“). Für Zwecke des O-RAN wird die F1-c-Schnittstelle jedoch zwischen der O-CU-CP 2121 und den Funktionen der O-DU 2115 übernommen, während die von 3GPP definierten Prinzipien und Protokollstapel und die Definition von Interoperabilitätsprofilspezifikationen wiederverwendet werden.
Die F1-u-Schnittstelle verbindet die O-CU-UP 2122 mit der O-DU 2115. Wie von 3GPP definiert, befindet sich die F1-u-Schnittstelle zwischen der gNB-CU-UP und gNB-DU-Knoten [TS38401], [TS38470]). Für Zwecke des O-RAN wird die F1-u-Schnittstelle jedoch zwischen der O-CU-UP 2122 und den Funktionen der O-DU 2115 übernommen, während die von 3GPP definierten Prinzipien und Protokollstapel und die Definition von Interoperabilitätsprofilspezifikationen wiederverwendet werden.
Die NG-c-Schnittstelle ist von 3GPP als eine Schnittstelle zwischen der gNB-CU-CP und der AMF im 5GC definiert [TS38300]. Das NG-c wird auch alsN2-Schnittstelle bezeichnet (siehe [TS38300]). Die NG-u-Schnittstelle ist von 3GPP als eine Schnittstelle zwischen der gNB-CU-UP und der UPF im 5GC definiert (siehe z. B. [TS38300]). Die NG-u-Schnittstelle wird als N3-Schnittstelle bezeichnet (siehe z. B. [TS38300]). In O-RAN werden NG-c- und NG-u-Protokollstapel, die von 3GPP definiert sind, wiederverwendet und können für O-RAN-Zwecke angepasst werden.
Die X2-c-Schnittstelle ist in 3GPP zum Übertragen von Steuerebeneninformationen zwischen eNBs oder zwischen eNB und en-gNB in EN-DC definiert. Die X2-u-Schnittstelle ist in 3GPP zum Übertragen von Benutzerebeneninformationen zwischen eNBs oder zwischen eNB und en-gNB in EN-DC definiert (siehe z. B. 3GPP TS 36.420 v16.0.0 (2020-07-17), [TS38300]). In O-RAN werden X2-c-und X2-u-Protokollstapel, die von 3GPP definiert sind, wiederverwendet und können für O-RAN-Zwecke angepasst werden.
Die Xn-c-Schnittstelle ist in 3GPP zum Übertragen von Steuerebeneninformationen zwischen gNBs, ng-eNBs oder zwischen einem ng-eNB und gNB definiert. Die Xn-u-Schnittstelle ist in 3GPP zum Übertragen von Benutzerebeneninformationen zwischen gNBs, ng-eNBs oder zwischen ng-eNB und gNB definiert (siehe z. B. [TS38300], 3GPP TS 38.420 v16.0.0 (2020-07-16)). In O-RAN werden Xn-c- und Xn-u-Protokollstapel, die von 3GPP definiert sind, wiederverwendet und können für O-RAN-Zwecke angepasst werden.
Die E1-Schnittstelle ist von 3GPP als eine Schnittstelle zwischen der gNB-CU-CP (z. B. gNB-CU-CP 3728) und gNB-CU-UP definiert (siehe z. B. [TS38401], 3GPP TS 38.460 v16.1.0 (2020-07-17)). In O-RAN werden E1-Protokollstapel, die von 3GPP definiert sind, wiederverwendet und als eine Schnittstelle zwischen den Funktionen der O-CU-CP 2121 und der O-CU-UP 2122 angepasst.
Die intelligente Nicht-Echtzeit(RT)-O-RAN-Steuerung (RIC) 2112 ist eine logische Funktion innerhalb des SMO 2002, 2102, die eine Nicht-Echtzeitsteuerung und Optimierung von RAN-Elementen und Ressourcen; einen oder mehrere Arbeitsabläufe für KI/maschinelles Lernen (ML) einschließlich Modelltraining, Inferenzen und Aktualisierungen; und eine richtlinienbasierte Lenkung von Anwendungen/Merkmalen in der Nahezu-RT-RIC 2114 ermöglicht.
Die O-RAN-Nahezu-RT-RIC 2114 ist eine logische Funktion, die eine Steuerung und Optimierung von RAN-Elementen und Ressourcen nahe Echtzeit über feinkörnige Datensammlung und Aktionen über die E2-Schnittstelle ermöglicht. Die Nahezu-RT-RIC 2114 kann einen oder mehrere KI/ML-Arbeitsabläufe beinhalten, einschließlich Modelltraining, Inferenzen und Aktualisierungen.
Die Nicht-RT-RIC 2112 kann ein ML-Trainingshost zum Hosten des Trainings eines oder mehrerer ML-Modelle sein. Das ML-Training kann offline unter Verwendung von Daten durchgeführt werden, die von der RIC, der O-DU 2115 und der O-RU 2116 gesammelt werden. Für überwachtes Lernen ist die Nicht-RT-RIC 2112 Teil des SMO 2102 und der ML-Trainingshost und/oder ML-Modellhost/-Aktor können Teil der Nicht-RT-RIC 2112 und/oder der Nahezu-RT-RIC 2114 sein. Für unüberwachtes Lernen könnender ML-Trainingshost und der ML-Modellhost/-Aktor Teil der Nicht-RT-RIC 2112 und/oder der Nahezu-RT-RIC 2114 sein. Für bestärkendes Lernen könnender ML-Trainingshost und der ML-Modellhost/-Aktor als Teil der Nicht-RT-RIC 2112 und/oder der Nahezu-RT-RIC 2114 gemeinsam angeordnet sein. Bei manchen Implementierungen kann die Nicht-RT-RIC 2112 ein ML-Modelltraining in den Trainingshosts anfordern oder auslösen, unabhängig davon, wo das Modell bereitgestellt und ausgeführt wird. ML-Modelle können trainiert und gegenwärtig nicht bereitgestellt werden.
Bei manchen Implementierungen stellt die Nicht-RT-RIC 2112 einen abfragbaren Katalog für einen ML-Designer/Entwickler bereit, um trainierte ML-Modelle (z. B. ausführbare Softwarekomponenten) zu veröffentlichen/zu installieren. Bei diesen Implementierungen kann die Nicht-RT-RIC 2112 einen Entdeckungsmechanismus bereitstellen, falls ein bestimmtes ML-Modell in einem Ziel-ML-Inferenzhost (MF) ausgeführt werden kann, und bereitstellen, welche Anzahl und welche Art von ML-Modellen im MF ausgeführt werden können. Zum Beispiel kann es drei Typen von ML-Katalogen geben, die durch die Nicht-RT-RIC 2112 entdeckbar gemacht werden: ein Gestaltungszeitkatalog (der sich z. B. außerhalb der Nicht-RT-RIC 2112 befindet und von einer oder mehreren anderen ML-Plattformen gehostet wird), ein Trainings-/Einsatzzeitkatalog (der sich z. B. innerhalb der Nicht-RT-RIC 2112 befindet) und ein Laufzeitkatalog (der sich z. B. innerhalb der Nicht-RT-RIC 2112 befindet). Die Nicht-RT-RIC 2112 unterstützt notwendige Fähigkeiten für eine ML-Modellinferenz zur Unterstützung von ML-unterstützten Lösungen, die in der Nicht-RT-RIC 2112 oder irgendeinem anderen ML-Inferenzhost laufen. Diese Fähigkeiten ermöglichen, dass ausführbare Software installiert wird, wie etwa VMs, Container usw. Die Nicht-RT-RIC 2112 kann auch eine oder mehrere ML-Engines beinhalten und/oder betreiben, die verpackte softwareausführbare Bibliotheken sind, die Methoden, Routinen, Datentypen usw. bereitstellen, die zum Ausführen von ML-Modellen verwendet werden. Die Nicht-RT-RIC 2112 kann auch Richtlinien zum Wechseln und Aktivieren von ML-Modellinstanzen unter unterschiedlichen Betriebsbedingungen implementieren.
Die Nicht-RT-RIC 2112 ist in der Lage, auf Rückmeldungsdaten (z. B. FM- und PM-Statistiken) über die ML-Modellleistungsfähigkeit über die O1-Schnittstelle zuzugreifen und notwendige Auswertungen durchzuführen. Falls das ML-Modell während der Laufzeit versagt, kann ein Alarm als Rückmeldung an die Nicht-RT-RIC 2112 erzeugt werden. Wie gute die Leistung des ML-Modells hinsichtlich der Vorhersagegenauigkeit oder anderer Betriebsstatistiken ist, kann auch über O1 an die Nicht-RT-RIC 2112 gesendet werden. Die Nicht-RT-RIC 2112 kann auch ML-Modellinstanzen, die in einem Ziel-MF laufen, über die O1-Schnittstelle skalieren, indem Ressourcennutzung im MF beobachtet wird. Die Umgebung, in der die ML-Modellinstanz läuft (z. B. dem MF), überwacht Ressourcennutzung des laufenden ML-Modells. Dies kann zum Beispiel unter Verwendung einer ORAN-SC-Komponente, die ResourceMonitor genannt wird, in der Nahezu-RT-RIC 2114 und/oder in der Nicht-RT-RIC 2112 erfolgen, die die Ressourcennutzung kontinuierlich überwacht. Falls Ressourcen niedrig sind oder unter eine gewisse Schwelle fallen, stellt die Laufzeitumgebung in der Nahezu-RT-RIC 2114 und/oder der Nicht-RT-RIC 2112 einen Skalierungsmechanismus bereit, um mehr ML-Instanzen hinzuzufügen. Der Skalierungsmechanismus kann einen Skalierungsfaktor beinhalten, wie etwa eine Anzahl, einen Prozentsatz und/oder andere ähnliche Daten, die zum Auf-AAbskalieren der Anzahl von ML-Instanzen verwendet werden. ML-Modellinstanzen, die in den Ziel-ML-Inferenzhosts laufen, können automatisch skaliert werden, indem die Ressourcennutzung im MF beobachtet wird. Zum Beispiel stellt die Laufzeitumgebung Kubernetes® (K8s) typischerweise ein Autoskalierungsmerkmal bereit.
Die A1-Schnittstelle befindet sich zwischen der Nicht-RT-RIC 2112 (innerhalb oder außerhalb des SMO 2102) und der Nahezu-RT-RIC 2114. Die A1-Schnittstelle unterstützt drei Arten von Diensten, wie in -RAN Alliance WG2, „O-RAN A1 interface: General Aspects and Principles 2.02“ v02.02 (März 2021) („[O-RAN.WG2.A1GAP-v02.02]“) definiert, einschließlich eines Richtlinienverwaltungsdienstes, eines Anreicherungsinformationsdienstes und eines ML-Modellverwaltungsdienstes. A1-Richtlinien weisen im Vergleich zur persistenten Konfiguration die folgenden Charakteristiken auf (siehe z. B. [O-RAN.WG2.A1GAP-v02.02]): A1-Richtlinien sind für Verkehr nicht kritisch; A1-Richtlinien weisen temporäre Gültigkeit auf; A1-Richtlinien können einzelne UE oder dynamisch definierte Gruppen von UEs handhaben; A1-Richtlinien wirken innerhalb der Konfiguration und haben Vorrang vor dieser; und A1-Richtlinien sind nicht persistent, z. B. überleben einen Neustart der Nahezu-RT-RIC nicht. O-RAN entwickelt gegenwärtig ein Framework zum Hinzufügen von xApps Dritter zu einem Basisstationsprodukt, das aus Komponenten unterschiedlicher Anbieter zusammengesetzt ist.
22 veranschaulicht eine beispielhafte O-RAN-Architektur 2200, die Nahezu-RT-RIC-Schnittstellen beinhaltet. Die Nahezu-RT-RIC 2214 ist über die A1-Schnittstelle mit der NON-RT-RIC 2212 verbunden (siehe z. B. [O-RAN.WG2.A1GAP-v02.02]). Die Nahezu-RT-RIC 2214 ist ein logischer Netzwerkknoten, der zwischen den E2 Knoten und der Dienstverwaltungs- & Orchestrierungsschicht (SMO) 2202 platziert ist, die die NON-RT-RIC 2212 hostet. Die Nahezu-RT-RIC 2214 kann gleich oder ähnlich wie die Nahezu-RT-RIC 2014 und die Nahezu-RT-RIC 2114 der 20 und 21 sein, und die Nicht-RT-RIC 2212 kann gleich oder ähnlich wie die Nicht-RT-RIC 2012 und/oder die Nicht-RT-RIC 2112 der 20 und 21 sein. Das SMO 2202 kann gleich oder ähnlich dem SMO 2002 und/oder dem SMO 2102 aus 20 und 21 sein. Eine Nahezu-RT-RIC 2214 ist mit nur einer Nicht-RT-RIC 2212 verbunden.
Wie zuvor erwähnt, ist E2 eine logische Schnittstelle, die die Nahezu-RT-RIC 2214 mit einem E2-Knoten verbindet. Die Nahezu-RT-RIC 2214 ist mit der O-CU-CP 2221 verbunden, die Nahezu-RT-RIC 2214 ist mit der O-CU-UP 2222 verbunden, die Nahezu-RT-RIC 2214 ist mit der O-DU 2215 verbunden und die Nahezu-RT-RIC 2214 ist mit dem O-e/gNB 2210 verbunden. Die O-DU 2215 ist mit der O-RU 2216 verbunden. Die O-CU-CP 2221, die O-CU-UP 2222, die O-DU 2215 und der O-e/gNB 2210 können gleich oder ähnlich der O-CU-CP 2121, der O-DU 2115 und dem O-e/gNB 2110 aus 21 sein. Die O-RU 2216 kann gleich oder ähnlich der O-RU 2016 und/oder der O-RU 2116 der 20 und 21 sein.
Ein E2-Knoten ist mit nur einer Nahezu-RT-RIC 2214 verbunden. Eine Nahezu-RT-RIC 2214 kann mit mehreren E2 Knoten (z. B. mehreren O-CU-CPs 2221, O-CU-UPs 2222, O-DUs 2215 und O-e/gNBs 2210) verbunden sein. F1 (z. B. Fl-Steuerebene (F1-C) und F1-Benutzerebene (F1-U)) und E1 sind logische 3GPP-Schnittstellen, deren Protokolle, Abschlusspunkte und Kardinalitäten in [TS38401] spezifiziert sind. Außerdem weisen die Nahezu-RT-RIC 2214 und andere RAN-Knoten O1-Schnittstellen wie in [O-RAN.WGl.OAM-Architecture-v04.00] und [0-RAN.WG1.0-RAN-Architecture-Description-v04.00] definiert auf. Zusätzlich ist die O-CU-CP 2221 über eine N2-Schnittstelle mit dem 5G-Kernnetzwerk (5GC) 2242b verbunden, die O-CU-UP 2222 ist über eine N3-Schnittstelle mit dem 5GC 2242b verbunden und die O-gNBs 2210 sind über eine Xn-Steuerebenenschnittstelle (Xn-C) mit der O-CU-CP 2221 verbunden und sind über eine Xn-Benutzerebenenschnittstelle (Xn-U) mit der O-CU-UP 2222 verbunden; diese Schnittstellen sind in 3GPP TS 23.501 v17.1.1 (2021-06-24) („[TS23501]“), 3GPP TS 38.300 v16.6.0 (2021-07-06) („[TS38300]“) und anderen 3GPP-Standards definiert. Ferner sind die O-eNBs 2210 über S1-Steuerungsplatz- (S1-C) und S1-Benutzerebenen(S1-U)-Schnittstellen mit einem Evolved Packet Core (EPC) 2242a verbunden, und die O-eNBs 2210 sind über eine X2-Steuerebenenschnittstelle (X2-C) und/oder eine Xn-Steuerebenenschnittstelle (Xn-C) mit der O-CU-CP 2221 verbunden und sind über eine X2-Benutzerebenenschnittstelle (X2-U) und/oder eine Xn-Benutzerebenenschnittstelle (Xn-U) mit der O-CU-UP 2222 verbunden; diese Schnittstellen sind in 3GPP TS 36.300 v16.6.0 (2021-07-06) („[TS36300]“) und/oder anderen 3GPP-Standards erörtert.
Die Nahezu-RT-RIC 2214 hostet eine oder mehrere xApps, die die E2-Schnittstelle verwenden, um Informationen in nahezu Echtzeit (z. B. auf UE-Basis, Zellenbasis) zu sammeln und Mehrwertdienste bereitzustellen. Die Nahezu-RT-RIC 2214 kann deklarative Richtlinien empfangen und Datenanreicherungsinformationen über die A1-Schnittstelle erhalten (siehe z. B. [O-RAN.WG2.A1GAP-v02.02]).
Die Protokolle über die E2-Schnittstelle basieren auf Steuerebenenprotokollen und sind in O-RAN Alliance WG1, „Near-Real-time RAN Intelligent Controller, E2 Application Protocol (E2AP)“ v01.01 (Juli 2020) („[O-RAN.WG3.E2AP-v01.01“) definiert. Bei Ausfall von E2 oder der Nahezu-RT-RIC 2214 ist der E2-Knoten in der Lage, Dienste bereitzustellen, aber es kann einen Ausfall für gewisse Mehrwertdienste geben, die möglicherweise nur unter Verwendung der Nahezu-RT-RIC 2214 bereitgestellt werden.
Die Nahezu-RT-RIC 2214 stellt eine Datenbankfunktion bereit, die die Konfigurationen in Bezug auf E2-Knoten, Zellen, Träger, Flüsse, UEs und die Abbildungen zwischen ihnen speichert. Die Nahezu-RT-RIC 2214 stellt ML-Werkzeuge bereit, die Daten-Pipelining unterstützen. Die Nahezu-RT-RIC 2214 stellt eine Nachrichtenübermittlungsinfrastruktur bereit. Die Nahezu-RT-RIC 2214 stellt Protokollierung, Verfolgung und Metriksammlung vom Framework der Nahezu-RT-RIC 2214 und xApps an das SMO bereit. Die Nahezu-RT-RIC 2214 stellt Sicherheitsfunktionen bereit. Die Nahezu-RT-RIC 2214 unterstützt eine Konfliktlösung, um die potenziellen Konflikte oder Überlappungen zu lösen, die durch die Anforderungen von xApps verursacht werden können.
Die Nahezu-RT-RIC 2214 stellt auch eine offene API bereit, die das Hosten von xApps von Dritten und xApps vom Plattformanbieter der Nahezu-RT-RIC 2214 ermöglicht. Die Nahezu-RT-RIC 2214 stellt auch eine offene API bereit, die von spezifischen Implementierungslösungen entkoppelt ist, einschließlich einer gemeinsam genutzten Datenschicht (SDL), die als eine Überlagerung für zugrundeliegende Datenbanken arbeitet und einen vereinfachten Datenzugriff ermöglicht.
Eine xApp ist eine Anwendung, die dazu ausgelegt ist, auf der Nahezu-RT-RIC 2214 ausgeführt zu werden. Eine solche Anwendung beinhaltet wahrscheinlich einen oder mehrere Mikrodienste oder stellt diese bereit und identifiziert zum Zeitpunkt des Onboarding, welche Daten sie konsumiert und welche Daten sie bereitstellt. Eine xApp ist unabhängig von der Nahezu-RT-RIC 2214 und kann von einer beliebigen Drittpartei bereitgestellt werden. E2 ermöglicht eine direkte Assoziation zwischen der xApp und der RAN-Funktionalität. Eine RAN-Funktion ist eine spezifische Funktion in einem E2-Knoten; Beispiele beinhalten X2AP- , F1AP-, E1AP-, S1AP-, NGAP-Schnittstellen und RAN-interne Funktionen, die UEs, Zellen usw. behandeln.
Die Architektur einer xApp umfasst den Code, der die Logik der xApp implementiert, und die RIC-Bibliotheken, die es der xApp ermöglichen: Nachrichten zu senden und zu empfangen; Benachrichtigungen aus der SDL-Schicht zu lesen, zu schreiben und von dieser zu erhalten; und Protokollnachrichten zu schreiben. Zusätzliche Bibliotheken werden in zukünftigen Versionen verfügbar sein, einschließlich Bibliotheken zum Setzen und Rücksetzen von Alarmen und Senden von Statistiken. Des Weiteren können xApps Zugriffsbibliotheken verwenden, um auf spezifische Namensräume in der SDL-Schicht zuzugreifen. Zum Beispiel kann die R-NIB, die Informationen darüber bereitstellt, mit welchen E2-Knoten (z. B. CU/DU) die RIC verbunden ist und welche SMs von jedem E2-Knoten unterstützt werden, unter Verwendung der R-NIB-Zugriffsbibliothek gelesen werden.
Die O-RAN-Standardschnittstellen (z. B. O1, A1 und E2) werden für die xApps folgendermaßen offengelegt: xApp empfängt seine Konfiguration über K8s-ConfigMap - die Konfiguration kann aktualisiert werden, während die xApp läuft, und die xApp kann über diese Modifikation unter Verwendung von inotify() benachrichtigt werden; xApp kann Statistiken (PM) senden, indem entweder (a) sie sie direkt an den VES-Sammler im VES-Format sendet, oder (b) durch Offenlegen von Statistiken über eine REST-Schnittstelle zum Sammeln durch Prometheus; die xApp empfängt eine AI-Richtlinienlenkung über eine RMR-Nachricht einer spezifischen Art (Richtlinieninstanzerstellungs- und -löschoperationen); und die xApp kann E2-Ereignisse subskribieren, indem sie die E2-Subskriptions-ASN.1-Nutzdaten konstruiert und sie als eine Nachricht (RMR) sendet, die xApp empfängt E2-Nachrichten (z. B. E2-INDICATION) als RMR-Nachrichten mit den ASN.1-Nutzdaten. Gleichermaßen kann die xApp E2-Steuernachrichten ausgeben.
Zusätzlich zu A1- und E2-bezogenen Nachrichten können xApps Nachrichten senden, die Prozesse von anderen xApps sind, und können Nachrichten empfangen, die durch andere xApps erzeugt werden. Die Kommunikation innerhalb der RIC ist richtliniengesteuert, das heißt, eine xApp kann das Ziel einer Nachricht nicht spezifizieren. Sie sendet einfach eine Nachricht eines bestimmten Typs und die für die RIC-Instanz spezifizierten Routing-Richtlinien ermitteln, an welche Ziele diese Nachricht geliefert wird (logisches Pub/Sub).
Logisch ist eine xApp eine Entität, die eine wohldefinierte Funktion implementiert. Mechanisch ist eine xApp ein K8s-Pod, der einen oder mehrere Container beinhaltet. Damit eine xApp bereitgestellt werden kann, muss sie einen xApp-Deskriptor (z. B. JSON) aufweisen, der die Konfigurationsparameter der xApp und Informationen beschreibt, die die RIC-Plattform benötigt, um die RIC-Plattform für die xApp zu konfigurieren. Der xApp-Entwickler muss auch ein JSON-Schema für den Deskriptor bereitstellen.
Zusätzlich zu diesen grundlegenden Anforderungen kann eine xApp beliebiges von Folgendem vornehmen: Lesen anfänglicher Konfigurationsparameter (im xApp-Deskriptor übergeben); Empfangen aktualisierter Konfigurationsparameter; Senden und Empfangen von Nachrichten; Lesen und Schreiben in einen persistenten gemeinsam genutzten Datenspeicher (Schlüsselwertspeicher); Empfangen von A1-P-Richtlinienlenkungsnachrichten - insbesondere Operationen zum Erzeugen oder Löschen einer Richtlinieninstanz (JSON-Nutzlast auf einer RMR-Nachricht) in Bezug auf einen gegebenen Richtlinientyp; Definieren eines neuen A1-Richtlinientyps; Subskribieren über eine E2-Schnittstelle zum RAN, Empfangen von E2-INDICATION-Nachrichten vom RAN und Ausgeben von E2-POLICY- und CONTROL-Nachrichten an das RAN; und Meldungsmetriken in Bezug auf ihre eigene Ausführung oder beobachtete RAN-Ereignisse.
Der Lebenszyklus der xApp-Entwicklung und Bereitstellung besteht aus den folgenden Zuständen: Entwicklung (Design, Implementierung, lokales Testen); Freigegeben (der xApp-Code und der xApp-Deskriptor werden in das LF-Gerrit-Repo übermittelt und in eine O-RAN-Release aufgenommen. Die xApp wird als Docker-Container verpackt und ihr Abbild an die LF-Release-Registrierungsdatenbank ausgegeben); Onboarded/verteilt (der xApp-Deskriptor (und potenziell Helm-Charts) wird für eine gegebene RIC-Umgebung angepasst und das resultierende angepasste Helm-Chart wird in einem lokalen Helm-Chart-Repository gespeichert, das vom xApp-Manager der RIC-Umgebung verwendet wird); Laufzeitparameterkonfiguration (bevor die xApp eingesetzt werden kann, werden Laufzeit-Helm-Chart-Parameter durch den Bediener bereitgestellt, um die xApp-Kubernetes-Bereitstellungsinstanz anzupassen. Diese Prozedur wird hauptsächlich verwendet, um eindeutige Laufzeit-Helm-Chart-Parameter zu konfigurieren, wie etwa eine Instanz-UUID, Lebendigkeitsprüfung, nach Osten gerichtete und nach Norden gerichtete Dienstendpunkte (z. B. DBAAS-Eintrag, VES-Sammlerendpunkt) und so weiter); und eingesetzt (die xApp wurde über den xApp-Manager eingesetzt und der xApp-Pod läuft auf einer RIC-Instanz. Für xApps, bei denen es sinnvoll ist, kann der bereitgestellte Zustand ferner in zusätzliche Zustände unterteilt werden, die über xApp-Konfigurationsaktualisierungen gesteuert werden. Zum Beispiel Laufen, Angehalten).
Die allgemeinen Prinzipien, die Definition der Nahezu-RT-RIC-Architektur sowie die Schnittstellen zwischen Nahezu-RT-RIC 2214, E2-Knoten und Dienstverwaltung und - Orchestrierung leiten, sind die folgenden: Nahezu-RT-RIC-Funktionen 2214 und E2 sind vollständig von Transportfunktionen getrennt. Das Adressierungssystem, das in der Nahezu-RT-RIC 2214 verwendet wird, und die E2-Knoten sollen nicht an die Adressierungssysteme von Transportfunktionen gebunden sein; die E2-Knoten unterstützen alle Protokollschichten und Schnittstellen, die innerhalb von 3GPP-Funktzugangsnetzen definiert sind, die eNB für E-UTRAN und gNB/ng-eNB für NG-RAN beinhalten; Nahezu-RT-RIC 2214 und gehostete „xApp“-Anwendungen sollen einen Satz von Diensten verwenden, die durch einen E2-Knoten offengelegt werden, der durch eine Reihe von RAN-Funktions- und Funkzugangstechnologie(RAT)-abhängigen E2-Dienstmodellen beschrieben wird; und die Schnittstellen der Nahezu-RT-RIC 2214 sind nach den folgenden Prinzipien definiert: die funktionale Aufteilung über die Schnittstellen so wenige Optionen wie möglich auf; Schnittstellen basieren auf einem logischen Modell der Entität, die durch diese Schnittstelle gesteuert wird; und ein physisches Netzwerkelement kann mehrere logische Knoten implementieren.
xApps können die RRM-Fähigkeiten der Nahezu-RT-RIC 2214 verbessern. xApps stellen Protokollierung, Verfolgung und Metriksammlung für die Nahezu-RT-RIC 2214 bereit. xApps beinhalten einen xApp-Deskriptor und ein xApp-Abbild. Das xApp-Abbild ist das Softwarepaket. Das xApp-Abbild enthält alle Dateien, die zum Bereitstellen einer xApp benötigt werden. Eine xApp kann mehrere Versionen des xApp-Abbildes aufweisen, die durch die xApp-Abbildversionsnummer markiert sind.
Der xApp-Deskriptor beschreibt das Verpackungsformat des xApp-Abbildes. Der xApp-Deskriptor stellt auch die notwendigen Daten bereit, um ihre Verwaltung und Orchestrierung zu ermöglichen. Der xApp-Deskriptor stellt xApp-Verwaltungsdienste mit notwendigen Informationen für die LZM von xApps bereit, wie etwa Bereitstellung, Löschen, Upgrade usw. Der xApp-Deskriptor stellt auch zusätzliche Parameter in Bezug auf die Gesundheitsverwaltung der xApps bereit, wie etwa Autoskalierung, wenn die Last von xApp zu schwer ist, und Autoheilung, wenn die xApp funktionsuntüchtig wird. Der xApp-Deskriptor stellt xApps FCAPS- und Steuerparameter bereit, wenn die xApp gestartet wird.
Die Definition des xApp-Deskriptors beinhaltet: grundlegende xApp-Informationen, FCAPS-Verwaltungsspezifikationen und Steuerspezifikationen. Die grundlegenden Informationen der xApp beinhalten Name, Version, Anbieter, URL des xApp-Abbilds, virtuelle Ressourcenanforderungen (z. B. CPU) usw. Die grundlegenden Informationen der xApp werden verwendet, um das LZM von xApps zu unterstützen. Zusätzlich oder alternativ dazu beinhalten die grundlegenden Informationen der xApp-Konfiguration, Metriken und Steuerdaten über eine xApp oder geben diese an. Die FCAPS-Verwaltungsspezifikationen spezifizieren die Optionen der Konfiguration, Leistungsfähigkeitsmetriksammlung usw. für die xApp. Die Steuerspezifikationen spezifizieren die Datentypen, die von der xApp für Steuerfähigkeiten konsumiert und bereitgestellt werden (z. B. Leistungsfähigkeitsverwaltungs(PM)-Daten, die die xApp subskribiert, den Nachrichtentyp von Steuernachrichten).
Zusätzlich oder alternativ beinhalten die xApp-Deskriptorkomponenten eine xApp-Konfiguration, xApp-Steuerspezifikation und xApp-Metriken. Die xApp-Konfigurationsspezifikation beinhaltet ein Datenwörterbuch für die Konfigurationsdaten (z. B. Metadaten, wie etwa eine YANG-Definition oder eine Liste von Konfigurationsparametern und deren Semantik). Zusätzlich dazu kann die xApp-Konfiguration eine anfängliche Konfiguration von xApps beinhalten. Die xApp-Steuerspezifikation beinhaltet die Datentypen, die sie konsumiert und bereitstellt, die Steuerfähigkeiten ermöglichen (z. B. xApp-URL, Parameter, Eingabe/Ausgabe-Typ). Die xApp-Metrikspezifikation soll eine Liste von Metriken (z. B. Metrikname, Typ, Einheit und Semantik) beinhalten, die von der xApp bereitgestellt werden.
23 stellt eine O-RAN-Architektur/ein O-RAN-Framework 2300 zum Hinzufügen von xApps Dritter dar, und 24 stellt eine interne Nahezu-RT-RIC-Architektur 2400 dar. In diesen Beispielen hostet die Nahezu-RT-RIC die folgenden Funktionen: Datenbank-Funktionalität, die Lesen und Schreiben von RAN/UE-Informationen ermöglicht; xApp-Subskriptionsverwaltung, die Subskriptionen von verschiedenen xApps zusammenführt und xApps eine einheitliche Datenverteilung bereitstellt; Konfliktlösung, die potenziell überlappende oder widersprüchliche Anforderungen von mehreren xApps löst; Nachrichtenübermittlungsinfrastruktur, die eine Nachrichteninteraktion zwischen internen Nahezu-RT-RIC-Funktionen ermöglicht; Sicherheit, die das Sicherheitsschema für die xApps bereitstellt; und
Verwaltungsdienste, beinhaltend: Fehlerverwaltung, Konfigurationsverwaltung und Leistungsfähigkeitsverwaltung als ein Diensterzeuger für SMO; Lebenszyklusverwaltung von xApps; und Protokollierung, Verfolgung und Metriksammlung, die den Status von Nahezu-RT-RIC-Interna erfassen, überwachen und sammeln und zur weiteren Auswertung an ein externes System transferiert werden können; und
Schnittstellenabschluss, beinhaltend: E2-Abschluss, der die E2-Schnittstelle von einem E2-Knoten abschließt; A1-Abschluss, der die A1-Schnittstelle von der Nicht-RT-RIC abschließt; und O1-Abschluss, der die O1-Schnittstelle von SMO abschließt; und
Funktionen, die von xApps gehostet werden, die ermöglichen, dass Dienste an der Nahezu-RT-RIC ausgeführt werden und die Ergebnisse über die E2-Schnittstelle an die E2-Knoten gesendet werden.
xApps können UE-bezogene Informationen bereitstellen, die in der UE-NIB(UE-Netzwerkinformationsbasis)-Datenbank gespeichert werden sollen. Die UE-NIB führt eine Liste von UEs und assoziierten Daten. Die UE-NIB pflegt die Verfolgung und Korrelation der UE-Identitäten, die mit den angebundenen E2-Knoten assoziiert sind.
xApps können funkzugangsnetzwerkbezogene Informationen bereitstellen, die in der R-NIB(Funknetzinformationsbasis)-Datenbank gespeichert werden sollen. Die R-NIB speichert die Konfigurationen und Nahechtzeitinformationen bezüglich angebundener E2-Knoten und der Abbildungen zwischen ihnen.
Die xApp-Subskriptionsverwaltung verwaltet Subskriptionen von den xApps zu den E2-Knoten. Die xApp-Subskriptionsverwaltung erzwingt eine Autorisierung von Richtlinien, die den xApp-Zugriff auf Nachrichten steuern. Die xApp-Subskriptionsverwaltung ermöglicht das Zusammenführen identischer Subskriptionen von verschiedenen xApps zu einer einzigen Subskription für den E2 Knoten.

Unter Bezugnahme auf 20-24 kann das O-RAN-System/die O-RAN-Architektur/das O-RAN-Framework ein oder mehrere E2-Dienstmodelle (E2SMs) bereitstellen (siehe z. B. O-RAN Near-Real-time RAN Intelligent Controller E2 Service Model 1.0 (Februar 2020) („[ORAN-WG3.E2SM-v01.00.00]“)). Ein E2SM ist eine Beschreibung der Dienste, die von einer spezifischen RAN-Funktion innerhalb eines E2-Knotens über die E2-Schnittstelle zum Nahezu-RT-RIC 2014 hin offengelegt werden. Eine gegebene RAN-Funktion bietet einen Satz von Diensten an, die über den E2 (REPORT, INSERT, CONTROL und/oder POLICY) unter Verwendung von durch E2AP (siehe z. B. [O-RAN.WG3.E2AP-v01.01) definierten Prozeduren offengelegt werden sollen. Jede der in Tabelle 1 aufgelisteten E2AP-Prozeduren enthält spezifische E2-Knoten-RAN-funktionsabhängige Informationselemente (IEs). Tabelle 1: Beziehung zwischen E2SM-Diensten und E2AP-IEs

RAN-funktionsspezifische E2SM-Informationselemente	E2AP-Informationselementreferenz	Verwandte E2AP-Prozeduren
RIC-Ereignisauslδsungsdefinitions-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.9	RIC-SUBSKRIPTION
RIC-Aktionsdefinitions-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.12	RIC-SUBSKRIPTION
RIC-Hinweiskopf-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.17	RIC-HINWEIS
RIC-Hinweisnachricht-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.16	RIC-HINWEIS
RIC-Aufruf-Prozess-ID-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.18	RIC-HINWEIS RIC-STEUERUNG
RIC-Steuerkopf-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.20	RIC-STEUERUNG
RIC-Steuernachrichten-IE	[O-RAN.WG3. E2AP-v01.01,	RIC-STEUERUNG
	Abschnitt 9.2.19
RAN-Funktionsdefinitions-IE	[O-RAN.WG3. E2AP-v01.01, Abschnitt 9.2.23	E2 SETUP RIC-DIENSTAKTUALISIERUNG

Alle diese RAN-funktionsspezifischen IEs sind in [O-RAN.WG3.E2AP-v01.01 als „OKTETT-STRING“ definiert. Die E2SMs beinhalten Stiltypen und Formattypen. In diesem Zusammenhang ist ein „Stiltyp“ eine Kennung, die verwendet wird, um einen spezifischen Ansatz oder Stil zu nominieren, der verwendet wird, um einen gegebenen RIC-Dienst (REPORT, INSERT, CONTROL und POLICY) offenzulegen. Dasselbe E2SM kann mehr als einen Stil für jeden RIC-Dienst unterstützen. Ein „Formattyp“ ist eine Kennung, die verwendet wird, um einen spezifischen Formatierungsansatz zu nominieren, der verwendet wird, um eines der in diesem E2SM definierten E2AP-IEs zu codieren. Dasselbe E2SM kann mehr als ein Codierungsformat für jedes E2AP-IE unterstützen und jedes E2AP-IE-Nachrichtencodierungsformat kann von einem oder mehreren RIC-Dienststilen verwendet werden. Beispielhafte E2SMs beinhalten E2SM-Schlüsselleistungsfähigkeitsmessung (E2SM-KPM) und E2SM-RAN-Steuerung (E2SM-RC).
4.2.1. E2SM für Schlüsselleistungsfähigkeitsmessungen (E2SM-KPM)
E2SM-KPM ist für die RAN-Funktionshandhabungsmeldung der Leistungsfähigkeitsmessungen auf Zellenebene für 5G-Netzwerke, die in 3GPP TS 28.552 v17.3.1 (2021-06-24) („[TS28552]“) definiert sind, und für EPC-Netzwerke, die in 3GPP TS 32.425 v17.1.0 (2021-06-24) („[TS32425]“) definiert sind, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen werden, und deren mögliche Anpassung von Messungen auf UE-Ebene oder QoS-Fluss-Ebene. Die RAN-Funktions-Schlüsselleistungsfähigkeitsmessung (KPM) wird verwendet, um eine RIC-Dienstoffenlegung der logischen Leistungsfähigkeitsmessfunktion der E2-Knoten bereitzustellen. Basierend auf der O-RAN-Bereitstellungsarchitektur könnten verfügbare Messungen unterschiedlich sein. 22 zeigt eine Bereitstellungsarchitektur für E2SM-KPM, wobei die E2-Knoten mit dem EPC 2242a und dem 5GC 2242b verbunden sind, wie zuvor besprochen. Für jede logische Funktion verwendet der E2-Knoten das RAN-Funktionsdefinitions-IE, um die Liste der verfügbaren Messungen und einen Satz unterstützter RIC-Dienste (REPORT) zu deklarieren. Die Inhalte dieser Felder für den spezifischen RAN-Funktions-KPM-Monitor werden im Folgenden erörtert.
Die E2SM-KPM unterstützt O-CU-CP, O-CU-UP und O-DU als Teil eines mit 5GC verbundenen NG-RAN oder als Teil eines mit EPC verbundenen E-UTRAN. Der E2-Knoten hostet die RAN-Funktion „KPM-Monitor“, die die folgenden Funktionalitäten durchführt: Offenlegung verfügbarer Messungen von O-DU, O-CU-CP und/oder O-CU-UP über das RAN-Funktionsdefinitions-IE; und periodisches Melden von Messungen, die von der Nahezu-RT-RIC abonniert sind.
Die E2SM-KPM legt auch einen Satz von Diensten einschließlich Meldediensten offen. Eine KPM-Meldung ist die Leistungsfähigkeitsmessungen für 4G-LTE- und 5G-NR-Netzwerkfunktionen. Die RAN-Funktion „KPM-Monitor“ stellt die folgenden REPORT-Dienste bereit: E2-Knotenmessung; E2-Knotenmessung für ein einzelnes UE; und bedingungsbasierte E2-Knotenmessung auf UE-Ebene. Diese Dienste können initiiert werden gemäß: einem periodischen Ereignis.
RAN-Funktionsbeschreibung: Die [O-RAN.WG3.E2AP-v01.01-Prozeduren, E2 SETUP und RIC SERVICE UPDATE, werden verwendet, um das RAN-Funktionsdefinitions-IE zu transportieren. In diesem E2SM-KPM soll das RAN-Funktionsdefinitions-IE die folgenden Informationen bereitstellen: RAN-Funktionsname zusammen mit assoziierten Informationen über die E2SM-Definition; Ereignisauslösungs-Stilliste zusammen mit dem entsprechenden Codierungstyp für jedes assoziierte E2AP-IE; und RIC-REPORT-Dienststillliste zusammen mit dem entsprechenden Codierungstyp für jedes assoziierte E2AP-IE.
RAN-Funktionsname: RAN-Funktionskurzname „ORAN-E2SM-KPM“. RAN-Funktionsbeschreibung „KPM-Monitor“. RAN-Funktionsinstanz, erforderlich, falls und wenn ein E2-Knoten mehr als eine Instanz einer RAN-Funktion basierend auf diesem E2SM aufdeckt.

Unterstützte RIC-Ereignisauslösungs-Stile beinhalten Ereignisauslösungs-Stil 1, was eine periodische Meldung ist. Das RIC-Ereignisauslösungsdefinitions-IE basiert auf einer Meldeperiode. Der Ereignisauslösungs-Stil 1 soll die KPM-Meldeperiode festlegen und verwendet das RIC-Ereignisauslösungsdefinitions-IE-Format 1 (siehe Tabelle 2). Tabelle 2: E2SM-KPM-Ereignisauslösungsdefinitionsformat 1

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und - Referenz	Semantikbeschreibung
Meldeperiode	M		GANZZAHL (1..42949672 95)	Die Meldeperiode wird in einer Einheit von 1 Millisekunde ausgedrückt.

Unterstützte RIC-REPORT-Dienststile beinhalten: RIC-Stiltyp 1: E2-Knoten-Messung (wird zum Übertragen eines Messberichts von einem Ziel-E2-Knoten verwendet); RIC-Stiltyp 2: E2-Knoten-Messung für ein einzelnes UE (wird zum Übertragen eines Messberichts für ein einzelnes interessierendes UE von einem Ziel-E2-Knoten verwendet); und RIC-Stiltyp 2: bedingungsbasierte E2-Knoten-Messung auf UE-Ebene (wird zum Übertragen eines Messberichts auf UE-Ebene für eine Gruppe von UEs, die subskribierten Zuständen entsprechen, von einem Ziel-E2-Knoten verwendet).

Der RIC-REPORT-Dienststiltyp 1 stellt die Leistungsfähigkeitsmessungs-Informationssammlung von einem E2-Knoten bereit. Der RIC-REPORT-Dienststiltyp 1 abonniert die in [TS28552] und [TS32425] definierten Messungen und verwendet das RIC-Aktionsdefinitions-IE-Format 1 (siehe Tabelle 3a und Tabelle 3b). Tabelle 3: E2SM-KPM-Aktionsdefinitionsformat 1

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und -Referenz	Semantikbeschreib ung
Messinformationsliste		1.. <maxnoofMeas urementInfo>
>AUSWAHL Messungstyp
»Messungsbezeichnung	M		8.3.9 Messungstypenname
»Messungs-ID	M		8.3.10 Messungstyp-ID
>Liste der Bezeichnungen		1.. <maxnoofLabell nfo>
>>Bezeichnungs-Informationen	M		8.3.11 MessungsBezeichnung
Granularitätsperiode	M		8.3.8 Granularitätsperiode	Sammelintervall von Messungen
Globale Zellen-ID	O		8.3.20 Globale Zellen-ID	Zeigt auf eine spezifische Zelle zum Generieren von Messungen, die durch das Messungsinformation slisten-IE subskribiert sind

Tabelle 3b

Bereichsgrenze	Erklärung
maxnoofMeasurementlnfo	Maximale Anzahl von Messtypen, die durch eine einzige Meldung gemeldet werden können. Der Wert beträgt <65535>.
maxnoofLabellnfo	Maximale Anzahl von Messwerten, die für einen einzigen Messungstyp gemeldet werden können. Der Wert beträgt <2147483647>.

Das REPORT-Dienst-RIC Aktionsdefinitions-IE enthält Messtypen, deren Subskription die Nahezu-RT-RIC anfordert, gefolgt von einer Liste von Kategorien oder Teilzählern, die für jeden Messtyp gemessen werden sollen, und eine Granularitätsperiode, die ein Sammelintervall dieser Messungen angibt. Das IE kann auch eine Zellenkennung enthalten, um auf eine spezifische Zelle zum Sammeln von Messungen innerhalb des E2-Knotens zu zeigen. Eine Mess-ID kann zur Subskription anstelle eines Messtyps verwendet werden, falls eine Kennung eines ermittelten Messtyps von einem E2-Knoten über das RAN-Funktionsdefinitions-IE offengelegt wurde.

Zusätzlich oder alternativ dazu verwendet der RIC-REPORT-Dienststiltyp 1 das RIC-Hinweiskopf-IE-Format 1 (siehe Tabelle 4), das eine Messsammlungsstartzeit als UTC-Format enthält. Das REPORT-Dienst-RIC-Hinweiskopj-IE kann Dateiformatversion, Sendername, Sendertyp und Anbietername als druckbare Strings tragen. Tabelle 4: E2SM-KPM-Hinweiskopfformat1

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und -Referenz	Semantikbeschr eibung
Startzeit der Sammlung	M		8.3.12 Zeitstempel
Dateiformatversion	O		PrintableString (GRÖSSE (0..15), ...)
Sendername	O		PrintableString (GRÖSSE (0..400), ...)
Sendertyp	O		PrintableString (GRÖSSE (0..8), ...)
Anbietername	O		PrintableString (GRÖSSE (0..32), ...)

Zusätzlich oder alternativ dazu verwendet der RIC-REPORT-Dienststiltyp 1 das RIC-Hinweisnachricht-IE-Format 1 (8.2.1.4.1). Das REPORT-Dienst-RIC-Himveisnachricht-IE trägt einen Satz von Messdaten, die von einem E2-Knoten gemeldet werden. Die gemeldeten Daten enthalten einen Satz von Messdatensätzen, die jeweils bei jeder Granularitätsperiode während der Meldungsperiode gesammelt werden. Falls der E2-Knoten nicht in der Lage ist, zuverlässige Daten für eine Granularitätsperiode während der Meldeperiode bereitzustellen, kann er das optionale Unvollständig-Flag-IE beinhalten, das angibt, dass der entsprechende Messdatensatz in den gemeldeten Daten nicht zuverlässig ist. Das REPORT-Dienst-RIC-Hinweisnachricht-IE trägt optional Subskriptionsinformationen, z. B. Messinformationslisten-IE, das die Reihenfolge von Messwerten für jeden Messdatensatz in den gemeldeten Daten oder ihre Granularitätsperiode angibt. Falls nicht vorhanden, sollen die ursprünglichen Subskriptionsinformationen gelten.

Der RIC-REPORT-Dienststiltyp 2 stellt die Leistungsfähigkeitsmessungs-Informationssammlung für ein einzelnes interessierendes UE von einem E2-Knoten bereit. Der RIC-REPORT-Dienststiltyp 2 verwendet das RIC-Aktionsdefinitions-IE-Format 2 (siehe Tabelle 5), wobei die enthaltene UE-ID ein spezifisches UE von Interesse zur Messsammlung angibt. Tabelle 5: E2SM-KPM-Aktionsdefinitionsformat 2

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und -Referenz	Semantikbeschrei bung
UE-ID	M		8.3.24	Zeigt auf ein spezifisches UE von Interesse
Subskriptionsinformationen	M		8.2.1.2.1 E2SM-KPM-Aktionsdefinitionsform at 1

Der Rest der Subskriptionsinformationen folgt dem Gleichen wie für das REPORT-Dienst-RIC-Aktionsdefinitions-IE beschrieben. Zusätzlich oder alternativ dazu verwendet der RIC-REPORT-Dienststiltyp 2 das RIC-Hinweiskopf-IE-Format 1 (siehe Tabelle 4), wie für das REPORT-Dienst-RIC-Himveiskopf-IE beschrieben. Zusätzlich oder alternativ dazu verwendet der RIC-REPORT-Dienststiltyp 2 das RIC-Hinweisnachricht-IE-Format 1 (siehe Tabelle 6a und Tabelle 6b), wie für das REPORT-Dienst-RIC-Hinweisnachricht-JE beschrieben, wobei die gemeldeten Messdaten nur mit einem spezifischen UE assoziiert sind, das subskribiert wurde. Tabelle 6a: E2SM-KPM-Hinweisnachrichtenformat 1

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und -Referenz	Semantikbeschrei bung
Messdaten		1.. <maxnoofMeas urementRecord >
>Messdatensatz		1.. <maxnoofMeas urementValue>		Enthält gemessene Werte in der gleichen Reihenfolge wie im Messinformationslis ten-IE, falls vorhanden, andernfalls in der Reihenfolge, die in der Subskription definiert ist, die durch die Subskriptions-I D identifiziert wird.
>AUSWAHL Gemessener Wert
»>ganzzahliger Wert	M		GANZZAHL (0..4294967295)
>>>reeller Wert	M		REELL
»>Kein Wert	M		NULL
>Unvollständig-Flag	O		NUMMERIERT (true, ...)	Gibt an, dass der Messdatensatz nicht zuverlässig ist.
Messinformationsliste		0.. <maxnoofMeas urementInfo>
>AUSWAHL Messungstyp
»Messungsbezeichnung	M		8.3.9 Messungstypenname
»Messungs-ID	M		8.3.10 Messungstyp-ID
>Liste der Bezeichnungen		1.. <maxnoofLabell nfo>
»Bezeichnungs-Informationen	M		8.3.11 MessungsBezeichnung
Granularitätsperiode	O		8.3.8 Granularitätsperiode	Sammelintervall von Messungen

Tabelle 6b

Bereichsgrenze	Erklärung
maxnoofMeasurementlnfo	Maximale Anzahl von Messtypen, die durch eine einzige Meldung gemeldet werden können. Der Wert beträgt <65535>.
maxnoofLabellnfo	Maximale Anzahl von Messwerten, die für einen einzigen Messungstyp gemeldet werden können. Der Wert beträgt <2147483647>.
maxnoofMeasurementRecord	Maximale Anzahl von Messungsdatensätzen, die durch einen einzigen Bericht gemeldet werden können. Der Wert beträgt
	<65535>.
maxnoofMeasurementValue	Maximale Anzahl von Messwerten, die in einem einzigen Messdatensatz getragen werden können. Der Wert beträgt <2147483647>.

Der RIC-REPORT-Dienststiltyp 3 stellt die Leistungsfähigkeitsmessungs-Informationssammlung auf UE-Ebene für eine Gruppe von UEs bereit, die mit subskribierten Zuständen von einem E2-Knoten übereinstimmt. Der RIC-REPORT-Dienst-Stiltyp 3 verwendet das RIC-Aktionsdefinitions-IE-Format 3 (siehe Tabelle 7a und Tabelle 7b), wobei für jede angeforderte Messung innerhalb des Messinformationsbedingungslisten-IE das Übereinstimmende-Bedingung-IE als eine Bedingung dient, die Messwerte der angepassten UEs in den Bericht aufzunehmen. Tabelle 7a: E2SM-KPM-Aktionsdefinitionsformat 3

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und -Referenz	Semantikbeschrei bung
Messinformationsliste		1.. <maxnoofMeas urementInfo>
>AUSWAHL Messungstyp
»Messungsbezeichnung	M		8.3.9 Messungstypenname
»Messungs-ID	M		8.3.10 Messungstyp-ID
>Übereinstimmende Bedingung		1.. <maxnoofCondi tionInfo>		Die übereinstimmende Bedingung stellt den booleschen Ausdruck dar, dessen Komponenten mit einem logischen UND verbunden sind.
»AUSWAHL Bedingungstyp	M
»>Bezeichnungs-Informationen			8.3.11 MessungsBezeichnung
»>Testinformationen			8.3.22 Testbedingungsinform ationen
Granularitätsperiode	M		8.3.8 Granularitätsperiode	Sammelintervall von Messungen
Globale Zellen-ID	O		8.3.20 Globale Zellen-ID	Zeigt auf eine spezifische Zelle zum Generieren von Messungen, die das Messungsinformati onslisten-IE subskribiert hat

Tabelle 7b

Bereichsgrenze	Erklärung
maxnoofMeasurementlnfo	Maximale Anzahl von Messtypen, die durch eine einzige Meldung gemeldet werden können. Der Wert beträgt <65535>.
maxnoofConditionlnfo	Maximale Anzahl von Zuständen, die für einen einzigen Messungstyp abonniert werden können. Der Wert beträgt <32768>.

Das Übereinstimmende-Bedingung-IE kann durch eine Liste von Teilzählern, die gemessen werden sollen (z. B. als eine Liste von Bezeichnungen), oder durch eine Liste von Testbedingungen, die bestanden werden müssen, oder durch eine Kombination von beidem ausgedrückt werden. Der Rest der Subskriptionsinformationen folgt dem Gleichen wie für das REPORT-Dienst-RIC Aktionsdefinitions-IE beschrieben.

Der RIC-REPORT-Dienst-Stiltyp 3 das RIC-Hinweiskopf-TE-Format 1 (8.2.1.3.1), wie für das REPORT-Dienst-RIC-Hinweiskopf-IE beschrieben. Zusätzlich oder alternativ dazu verwendet der RIC-REPORT-Dienst-Stiltyp 3 das RIC-Hinweisnachricht-IE-Format 2 (siehe Tabelle 8a und Tabelle 8b). Tabelle 8a: E2SM-KPM-Hinweisnachrichtenformat 2

IE/Gruppenname	Vorhande nsein	Bereich	IE-Typ und -Referenz	Semantikbeschreib ung
Messdaten		1.. <maxnoofMeas urementRecord >
>Messdatensatz		1.. <maxnoofMeas urementValue>		Enthält gemessene Werte in der gleichen Reihenfolge wie im Messinformationsbe dingungs-UE-Listen-IE.
>AUSWAHL Gemessener Wert
»>ganzzahliger Wert	M		GANZZAHL (0..4294967295)
>>>reeller Wert	M		REELL
»>Kein Wert	M		NULL
>Unvollständig-Flag	O		NUMMERIERT (true, ...)	Gibt an, dass der Messdatensatz nicht zuverlässig ist.
Messinformationsbedingung s-UE-Liste		1.. <maxnoofMeas urementInfo>
>AUSWAHL Messungstyp
»Messungsbezeichnung	M		8.3.9 Messungstypenname
»Messungs-ID	M		8.3.10 Messungstyp-ID
>Übereinstimmende Bedingung		1.. <maxnoofCondi tionInfo>
»AUSWAHL Bedingungstyp	M
»>Bezeichnungs-Informationen			8.3.11 MessungsBezeichnung
»>Testinformationen			8.3.22 Testbedingungsinform ationen
>Liste übereingestimmter UE-IDs		0.. <maxnoofUEID >
»UE-ID	M		8.3.24
Granularitätsperiode	O		8.3.8	Sammelintervall von
			Granularitätsperiode	Messungen

Tabelle 8b

Bereichsgrenze	Erklärung
maxnoofMeasurementlnfo	Maximale Anzahl von Messtypen, die durch eine einzige Meldung gemeldet werden können. Der Wert beträgt <65535>.
maxnoofConditionlnfo	Maximale Anzahl von Zuständen, die für einen einzigen Messungstyp abonniert werden können. Der Wert beträgt <32768>.
maxnoofUEID	Maximale Anzahl von UE-IDs, die für einen einzigen Zustand gemeldet werden können. Der Wert beträgt <65535>.
maxnoofMeasurementRecord	Maximale Anzahl von Messungsdatensätzen, die durch einen einzigen Bericht gemeldet werden können. Der Wert beträgt <65535>.
maxnoofMeasurementValue	Maximale Anzahl von Messwerten, die in einem einzigen Messdatensatz getragen werden können. Der Wert beträgt <2147483647>.

Das REPORT-Dienst-RICHimveisnachricht-IE trägt einen Satz von Messdaten auf UE-Ebene, die subskribierten Bedingungen entsprechen. Das enthaltene Messinformationsbedingungs-UE-Listen-TE gibt die Reihenfolge von Messwerten für jeden Messdatensatz in den gemeldeten Daten an - eine Liste von UE-IDS, die das subskribierte Übereinstimmende-Bedingung-IE für jede angeforderte Messung erfüllen.
In jeder Granularitätsperiode, während der ein UE, das mit einer subskribierten Bedingung übereinstimmt, in dem E2-Knoten verbleibt und den RRC _CONNECTED- oder RRC_INACTIVE-Zustand beibehält, sammelt der E2-Knoten die zugehörigen Daten und meldet sie am Ende der Meldeperiode. In den Granularitätsperioden, in denen das UE nicht im RRC _CONNECTED- oder RRC INACTIVE-Zustand erscheint (z. B. zu RRC_IDLE übergegangen oder die UE-Identitätsspur ging verloren), sammelt der E2-Knoten die zugehörigen Daten nicht, und NULL wird für diese Granularitätsperioden bis zum Ende der Meldeperiode gemeldet. In diesem Fall stoppt der E2-Knoten das Melden von Messungen in Bezug auf dieses UE in den anschließenden Meldeperioden. Die Liste abgeglichener UE-IDs kann für eine gewisse subskribierte Bedingung weggelassen werden, falls keines der UEs während der Meldeperiode übereinstimmt. Der Rest der Informationen folgt dem Gleichen wie für das REPORT-Dienst-RIC-Hinweisnachricht-IE beschrieben.

Die Umwandlung der Definitionen der Messungen, die in [TS28552] und [TS32425] bereitgestellt sind, erfolgt gemäß den Regeln in Tabelle 9. Tabelle 9: Umwandlung für Messungen auf UE-Ebene und QoS-Fluss-Ebene

Der Typ der ursprünglichen Messungen	Die entsprechenden Messungen pro UE und pro UE pro Segment	Die entsprechenden Messungen pro QoS-Fluss und pro Segment pro QoS-Fluss	Anmerkungen
Durchsatz Verzögerung Datenvolumen Aktivitätszeit in Sitzung	Gemessen pro UE	Gemessen pro QoS-Fluss	Für die Durchsatz- und Datenvolumenmessungen werden die in 3GPP spezifizierten Formeln mit Beschränkung auf das
			individuelle UE oder den individuellen QoS-Fluss und auch basierend auf Abschnitt 7.9.1. verwendet.
PDCP-Verlustrate IP-Latenz	Gemessen pro UE	Gemessen pro QoS-Fluss	Für die Durchsatz- und Datenvolumenmessungen werden die in 3GPP spezifizierten Formeln mit Beschränkung auf das individuelle UE oder den individuellen QoS-Fluss verwendet.
Funkressourcennutzung	Gemessen pro UE	k.A.	Die in 3GPP angegebenen Formeln werden unter Beschränkung auf das individuelle UE verwendet.
In Bezug auf RRC-Verbindungen In Bezug auf PDU-Sitzungen In Bezug auf DRBs In Bezug auf QoS-Flüsse	Gemessen pro UE	k.A.
Mobilitätsverwaltung	Gemessen pro UE	k.A.
In Bezug auf CQI In Bezug auf MCS	Gemessen pro UE	k.A.
In Bezug auf PEE	k.A.	k.A.
Verteilung normal/anormal freigegebener Aufrufe	Gemessen pro UE	k.A.

Die Einheiten der folgenden Messungen in [TS28552] und [TS32425] werden durch neuere Einheiten ersetzt, wie in Tabelle 10 gezeigt. Tabelle 10: Änderungen der Messeinheiten bei Übernahme für E2SM-KPM

Messungstyp	Messungsbezeichnung	Datentyp	In 3GPP verwendete Einheit	In E2SM-KPM verwendete Einheit
DL-Zellen-PDCP-SDU-Datenvolumen, definiert in [TS28552] Klausel 5.1.2.1.2.1.	DRB.PdcpSduVolumeDL_Filter	GANZZAHL	Mbit	Kbit
UL-Zellen-PDCP-SDU-Datenvolumen, definiert in [TS28552] Klausel 5.1.2.1.2.2.	DRB.PdcpSduVolumeUL_Filter	GANZZAHL	Mbit	Kbit
DL-PDCP-PDU-Datenvolumen, definiert in [TS28552] Klausel 5.1.3.6.1.1.	QosFlow.PdcpPduVolumeDL_Filter	GANZZAHL	Mbit	Kbit
UL-PDCP-PDU-Datenvolumen, definiert in [TS28552] Klausel 5.1.3.6.1.2.	QosFlow.PdcpPduVolumeUL_Filter	GANZZAHL	Mbit	Kbit
DL-PDCP-SDU-Datenvolumen, definiert in [TS28552] Klausel 5.1.3.6.2.1.	QosFlow.PdcpSduVolumeDI_Filter	GANZZAHL	Mbit	Kbit
UL-PDCP-SDU-Datenvolumen, definiert in [TS28552] Klausel 5.1.3.6.2.2.	QosFlow.PdcpSduVolumeUI_Filter	GANZZAHL	Mbit	Kbit
DL-Zellen-PDCP-SDU-Datenvolumen auf X2-Schnittstelle, definiert in [TS28552] Klausel 5.1.2.1.1.2.	DRB.PdcpSduVolumeX2DL_Filter	GANZZAHL	Mbit	Kbit
UL-Zellen-PDCP-SDU-Datenvolumen auf X2-Schnittstelle, definiert in [TS28552] Klausel 5.1.2.1.2.2.	DRB.PdcpSduVolumeX2UL_Filter	GANZZAHL	Mbit	Kbit
DL-Zellen-PDCP-SDU-Datenvolumen auf Xn-Schnittstelle, definiert in [TS28552] Klausel 5.1.2.1.1.3.	DRB.PdcpSduVolumeXnDL_Filter	GANZZAHL	Mbit	Kbit
UL-Zellen-PDCP-PDU-Datenvolumen auf Xn-Schnittstelle, definiert in [TS28552] Klausel 5.1.2.1.2.3.	DRB.PdcpSduVolumeXnUL_Filter	GANZZAHL	Mbit	Kbit
DL-PDCP-SDU-Datenvolumen pro Schnittstelle, definiert in [TS28552] Klausel 5.1.3.6.2.3.	DRB.F1uPdcpSduVolumeDI.QoS, DRB.X2uPdcpSduVolumeDI.QoS, DRB.XnuPdcpSduVolumeDI.QoS	GANZZAHL	Mbit	Kbit
UL-PDCP-SDU-Datenvolumen pro Schnittstelle, definiert in [TS28552] Klausel 5.1.3.6.2.4.	DRB.F1uPdcpSduVolumeUI.QoS, DRB.X2uPdcpSduVolumeUI.QoS, DRB.XnuPdcpSduVolumeUI.QoS	GANZZAHL	Mbit	Kbit
DL-Zellen-PDCP-SDU-Datenvolumen, definiert in [TS32425] Klausel 4.4.7.1.	DRB.PdcpSduVolumeDI_Filter	GANZZAHL	Mbit	Kbit
UL-Zellen-PDCP-SDU-Datenvolumen, definiert in [TS32425] Klausel 4.4.7.2.	DRB.PdcpSduVolumeUI_Filter	GANZZAHL	Mbit	Kbit
Aktivitätszeit in Sitzung für UE, definiert in [TS28552] Klausel 5.1.1.13.2.2.	QF.SessionTimeUE	GANZZAHL	s	ms
Aktivitätszeit in Sitzung für DRB, definiert in [TS28552] Klausel 5.1.1.10.4.	DRB.SessionTime.5QI, DRB.SessionTime.SNSSAI	GANZZAHL	s	ms
Aktivitätszeit in Sitzung für QoS-Fluss, definiert in [TS28552] Klausel 5.1.1.13.2.1.	QF.SessionTimeQoS.QoS	GANZZAHL	s	ms
Aktivitätszeit in Sitzung für UE, definiert in [TS32425] Klausel 4.2.4.1.	ERAB.SessionTimeUE	GANZZAHL	s	ms
Aktivitätszeit in Sitzung für E-RABs, definiert in [TS32425] Klausel 4.2.4.2.	ERAB.SessionTimeQCI.QCI	GANZZAHL	s	ms
IP-Durchsatz in UL, definiert in [TS32425] Klausel 4.4.6.2.	DRB.IPThpUI.QCI	REELL	Kbit	Kbit/s

Die Änderungen in den Einheiten der in der obigen Tabelle gezeigten Messungen sollen verhindern, dass die gemeldeten Werte als 0 gemeldet werden, was durch Abrunden der Genauigkeit in den Dezimalen verursacht wird, um sie als ganze Zahl zu melden, mit Ausnahme der letzten Zeile von „IP-Durchsatz in UL“, die die falsche Einheit beheben soll.
Bei manchen Implementierungen können die eine oder die mehreren zuvor besprochenen E2SM-KPM-RIC-Stil-Nachrichten verwendet werden, um einem Agenten (z. B. dem Agenten 140, Edge-Intelligenzelement 446, Echtzeitagenten 501, Agenten 640 usw.) Beobachtungen bereitzustellen. Zum Beispiel kann eine CU (z. B. O-CU-CP 2121 und/oder O-CU-UP 2122) eine oder mehrere E2SM-KPM-RIC-Stil-Nachrichten verwenden, um einer RIC (z. B. der Nahezu-RT-RIC 2114 und/oder Nicht-RT RIC 2112) Datenvolumenmessungen (auf pro QoS-Ebene) (z. B. die PDCP-PDU-Datenvolumenmessungen, die zuvor besprochen wurden; siehe z.B. [TS28552] § 5.1.3.6.1), eine CU-UP-Verzögerung (z. B. Durchschnitt und/oder Verteilung der Paketverzögerung auf der CU-UP; siehe z. B. [TS28552] § 5.1.3.3) und/oder eine FI-U-Verzögerung (z. B. Durchschnitt und/oder Verteilung der Paketverzögerung auf der F1-U) und/oder dergleichen zu übermitteln. In einem anderen Beispiel kann eine DU (z. B. O-DU 2115) eine oder mehrere E2SM-KPM-RIC-Stil-Nachrichten verwenden, um einer RIC (z. B. der Nahezu-RT-RIC 2114 und/oder der Nicht-RT RIC 2112) Messungen des Durchsatzes pro UE (z. B. Durchschnitt und/oder Verteilung des UE-Durchsatzes in NAN (z. B. gNB); siehe z. B. [TS28552] § 5.1.1.3), pro UE-CQI/MCSbezogene Messungen (siehe z. B. [TS28552] § 5.1.1.11 und [TS28552] § 5.1.1.12), eine gNB-DU-Verzögerung (siehe z. B. [TS28552] § 5.1.3.3.3) zu übermitteln. Zusätzliche Aspekte von E2SM-KPM sind in O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller E2 Service Model (E2SM) KPM v01.00 (Februar 2020) („[ORAN-WG3.E2SM-KPM-v01.00]“) erörtert.
4.2.2. E2SM für die Nahezu-RT-RIC-RAN-Steuerinteraktion (E2SM-RC)
Für die Zwecke der E2SM-RC wird angenommen, dass der E2-Knoten, der die E2-Schnittstelle abschließt, eine oder mehrere Instanzen der RAN-Funktion „RAN-Steuerung“ hostet, die die folgenden Funktionalitäten durchführt: E2-Berichtsdienste, die verwendet werden, um RAN-Steuerungs- und UE-Kontextinformationen offenzulegen; E2-Einfügungsdienste, die verwendet werden, um mit RAN-Steuerung verbundene Aufrufprozesse auszusetzen; E2-CONTROL-Dienste, die verwendet werden, um mit RAN-Steuerung verbundene Aufrufprozesse wiederaufzunehmen oder zu initiieren, RANkonfigurationsbezogene und/oder E2-dienstbezogene UE-Kontextinformationen zu modifizieren; und E2-POLICY-Dienste, die verwendet werden, um das Verhalten von mit RAN-Steuerung verbundenen Prozessen zu modifizieren.

Die E2SM-RC beinhaltet auch einen Satz von RAN-Funktionsoffenlegungsdiensten, die nachstehend beschrieben sind, wobei das gleiche E2SM verwendet werden kann, um entweder eine einzige RAN-Funktion in dem E2-Knoten, der alle RAN-steuerungsbezogenen Aufrufprozesse handhabt, oder mehr als eine RAN-Funktion in dem E2-Knoten zu beschreiben, wobei jede Instanz eine Teilmenge der RAN-steuerungsbezogenen Aufrufprozesse auf dem E2-Knoten handhabt. Die E2SM-RC unterstützt die durch Tabelle 11 zusammengefassten Ereignisauslöse-Definitions-IE-Stile. Tabelle 11: RIC-Ereignisauslösungsdefinitions-IE-Stilliste

RIC-Stilty P	Stil-Name	Unterstützter RIC-Dienststil			Stil-Beschreibung
RIC-Stilty P	Stil-Name	Berich t	Einfügun g	Richtlini e	Stil-Beschreibung
1	Nachrichtenereignis	1	8	1-7	Auslösebedingungen basieren auf dem Eintreffen oder Verlassen einer Netzwerkschnittstellennachricht oder RRC-Nachricht.
2	Aufrufprozessunterbrechungsp unkt	2	1-7	1-7	Auslösebedingungen basieren auf einem Aufrufprozessunterbrechungspu nkt.
3	E2-Knoteninformationsänderung	3	-	-	Auslösebedingungen basieren auf einer Änderung von E2-Knoten- oder zellenbezogenen Konfigurationsinformationen.
4	UE-Informationsänderung	4	-	-	Auslösebedingungen basieren auf einer Änderung von UE-Informationen.
5	Bei Bedarf	5	-	-	Ein Ereignis wird sofort ausgelöst, wenn eine RIC-Subskription mit diesem Ereignisauslöser akzeptiert wird.

Bei manchen Implementierungen kann RIC-Stiltyp 1 zur Funkträgersteuerung verwendet werden. Die Nachricht vom RIC-Stiltyp 1 kann eine Steueraktions-ID 5 beinhalten, um anzugeben, dass die Nachricht zur DRB-Abschlusssteuerung dient, und/oder die Nachricht vom RIC-Stiltyp 1 kann eine Steueraktions-ID 6 beinhalten, um anzugeben, dass die Nachricht zur DRB-Aufteilungsverhältnissteuerung dient.
Die RAN-Funktionsoffenlegungsdienste für E2SM-RC beinhalten REPORT-Dienste, INSERT-Dienste, CONTROL-Dienste und POLICY-Dienste.
4.2.2.1. REPORT-Dienst
Die E2SM-RC-RAN-Funktion stellt eine selektive Unterstützung der folgenden REPORT-Dienste bereit: Kopieren einer Abgeschlossen-Nachricht (von einer Netzwerkschnittstelle oder RRC), die zum Überwachen von POLICY-Diensten verwendet wird, Datensammeln (um die Nahezu-RT-RIC-UE-NIB- und/oder ML-Dienst-Datenpipeline zu befüllen), usw.; Aufrufprozessergebnis mit assoziierten Informationen über UE-Kontext- und/oder RAN-Statusinformationen, die zum Überwachen von [CONTROL- und] POLICY-Diensten, Datensammlung (um die Nahezu-RT-RIC-UE-NIB- und/oder ML-Dienst-Datenpipeline zu befüllen) verwendet werden, usw.; E2-Knoten-Informationen und zellenbezogene Informationen, die zum Überwachen von E2-Knoten- und Zellenkonfigurationsänderungen, Auslösen von POLICY-Löschung, Ändern von Benachrichtigungen (um Nahezu-RT-RIC-Optimierungsdienste zurückzusetzen) usw. verwendet werden; UE-Informationen, die zum Überwachen von UE-Informationsänderungen, Auslösen von E2-Steuerung, Standortverfolgung usw. verwendet werden; und Bericht auf Abruf, der zum Melden von zellenbezogenen, E2-knotenbezogenen und UE-bezogenen Informationen an eine Nahezu-RT-RIC verwendet wird, wenn von der Nahezu-RT-RIC angefordert. Bei manchen Implementierungen kann nur das UE mit Benutzergenehmigung dazu konfiguriert sein, Standortinformationen zu melden.
Die E2SM-RC-REPORT-Dienstanforderungen werden unter Verwendung eines Satzes von REPORT-Stilen angeboten. Alle REPORT-Stile werden unter Verwendung eines Satzes von IEs für Aktionsdefinition, RIC-Hinweiskopf und RIC-Hinweisnachricht implementiert und weisen einen spezifischen Ereignisauslöseransatz auf. Für jeden Meldungsstil wird eine einzige RAN-Parametertabelle verwendet, um die erforderlichen zu meldenden Informationen zu spezifizieren.
Die folgenden REPORT-Stile werden unterstützt: Nachrichtenkopie (dieser REPORT-Stil wird durch „Nachrichtenereignis“-Ereignisauslöser initiiert und wird verwendet, um eine vollständige NI - oder RRC-Nachricht zusammen mit UE-assoziierten Informationen zu melden, wenn die Ereignisauslöserbedingungen erfüllt sind); Aufrufprozessergebnis (dieser REPORT-Stil wird durch den entsprechenden „Aufrufprozessunterbrechungspunkt“-Ereignisauslöser initiiert und wird verwendet, um das Ergebnis eines Aufrufprozesses zu melden, der Informationen über aktuelle und in bestimmten Fällen vorherige UE- oder E2-Knoten-Informationen in Abhängigkeit von der Natur des Zielaufrufprozesses bereitstellt); E2-Knoteninformationen (dieser REPORT-Stil wird durch einen „E2-Knoteninformationsänderung“-Ereignisauslöser initiiert und wird verwendet, um zellenbezogene und E2-knotenbezogene Informationen zu melden, wenn Ereignisauslöserbedingungen erfüllt sind); UE-Informationen (dieser REPORT-Stil wird durch einen „UE-Informationsänderung“-Ereignisauslöser initiiert und wird verwendet, um UE-bezogene Informationen und UE-Zustandsvariablen zu melden, wenn die Ereignisauslöserbedingungen erfüllt sind); und Bericht auf Abruf (dieser REPORT-Stil wird durch einen „Auf Abruf“-Ereignisauslöser initiiert und wird verwendet, um zellenbezogene und UE-bezogene Informationen auf einer Adhoc-Basis auf Anfrage von Nahezu-RT-RIC zu melden).
4.2.2.2. INSERT-Dienst
Die E2SM-RC-RAN-Funktion bietet eine selektive Unterstützung der folgenden INSERT-Dienste: Funkträgersteueranforderung, verwendet zum Auffordern, dass die RIC eine DRB-QoS-Modifikation, QoS-Fluss-auf-DRB (Neu-)Abbildung, Logikkanal-(Neu- )Konfiguration, Funkträgerzugangssteuerung, Splitträger-und PDCP-Duplizierungssteuerung usw. steuert; Funkressourcenzuweisungssteueranforderung, die zum Anfordern verwendet wird, dass die RIC diskontinuierlichen Empfang (DRX), eine Planungsanforderung (SR), eine semipersistente Planung (SPS), eine konfigurierte Bewilligung, eine PRB-Quote auf Segmentebene, eine Kanalqualitätsindikator(CQI)-Tabelle usw. steuert; Mobilitätssteueranforderung im verbundenen Modus, die zum Anfordern verwendet wird, dass die RIC Operationen von Handover (HO), Conditional Handover (CHO), Dual Active Protocol Stack (DAPS) HO usw. steuert; Funkzugangssteueranforderung, die zum Anfordern verwendet wird, dass die RIC Parameter in Bezug auf RACH-Back-off, RRC-Verbindungsabweisung, RRC-Verbindungsfreigabe, Zugangssperre, UE-Zulassung usw. steuert; Doppelkonnektivitäts(DC)-Steueranforderung, zum Anfordern verwendet wird, dass die RIC Operationen von Doppelkonnektivität (DC) zu steuern, einschließlich einer Änderung des Trägerendpunkts (MN oder SN) und/oder von Trägertypen, usw.; Trägeraggregations(CA)-Steueranforderung, die zum Anfordern verwendet wird, dass die RIC Operationen der Trägeraggregation (CA) steuert, die eine Sekundärzellen-Neuauswahl involvieren; und Leerlaufmodus-Mobilitätssteueranforderung, die zum Anfordern verwendet wird, dass die RIC Intrafrequenz-, Interfrequenz-, Inter-RAT-Zellen-Neuauswahlpriorität, Leerlauftimer usw. steuert.
Die in Abschnitt 6.2.2. definierten E2SM-RC-INSERT-Dienstanforderungen werden unter Verwendung eines Satzes von INSERT-Stilen angeboten. Jeder Stil entspricht einem Satz von „INSERT-Hinweisen“, wobei sich jeder „INSERT-Hinweis“ auf eine spezifische Funktionalität bezieht und einen Satz assoziierter RAN-Parameter aufweist, die in einer Abbildungstabelle bereitgestellt sind. Alle INSERT-Dienststile werden unter Verwendung eines Satzes von IEs implementiert, die „Aktionsdefinition“, „RIC-Hinweiskopf“ und „RIC-Hinweisnachricht“ bilden, um RAN-steuerungsbezogene INSERT-Dienste zu liefern. Jeder INSERT-Dienststil ist mit einem spezifischen „Ereignisauslöser“-Ansatz assoziiert. Ein „INSERT-Hinweis“ wird verwendet, um die RIC aufzufordern, eine Funktionalität zu steuern, die mit dem jeweiligen INSERT-Dienststil assoziiert ist, und die Werte eines oder mehrerer assoziierter RAN-Parameter festzulegen oder zu modifizieren.
Als ein Beispiel kann der E2-Knoten bei Ankunft eines RRC-Messberichts in dem E2-Knoten aufgrund des Auftretens eines A3-Ereignisses, das ein UE betrifft (was den Ereignisauslöser darstellt), eine Nachricht an die RIC unter Verwendung des „Mobilität im verbundenen Modus“-INSERT-Dienststils und des „Handover-Steueranforderungs“ -INSERT-Hinweises zusammen mit dem „Zielzellen-ID“-Parameter senden. Diese RIC sollte dann die „Handover-Steueranforderung“ akzeptieren/verweigern, und falls sie sie akzeptiert, sollte sie den Wert des „Zielzellen-ID“-Parameters festlegen und eine CONTROL-Aktion zurück an die RIC senden. Bis dahin suspendiert der E2-Knoten die laufende Aufrufverarbeitung für das UE.
Für den INSERT-Dienst sendet die RIC eine „CONTROL-Aktion“, die den eingehenden „INSERT-Hinweis“, der eine „Handover-Steuerung“ anfordert, zusammen mit dem Wert der „Ziel-Primärzelle“ akzeptiert/verweigert. Als ein anderes Beispiel kann die RIC auch asynchron eine „CONTROL-Aktion“ senden, die den E2-Knoten auffordert, das UE im Trägeraggregationsmodus zu konfigurieren und für das UE eine oder mehrere Sekundärzellen einzurichten, deren Werte durch die RIC über die „CONTROL-Aktion“ zugewiesen werden.
4.2.2.3. CONTROL-Dienst
Die E2SM-RC-RAN-Funktion bietet eine selektive Unterstützung der folgenden CONTROL-Dienste: Funkträgersteuerung, verwendet für DRB-QoS-Modifikation, QoS-Fluss-auf-DRB (Neu-)Abbildung, (Neu-)Konfiguration eines logischen Kanals, Funkträgerzugangssteuerung, Splitträger-und PDCP-Duplizierungssteuerung usw.; Funkressourcenzuweisungssteuerung, verwendet zum Steuern von diskontinuierlichem Empfang (DRX), einer Planungsanforderung (SR), einer semipersistenten Planung (SPS), einer konfigurierten Bewilligung, einer PRB-Quote auf Segmentebene, einer Kanalqualitätsindikator(CQI)-Tabelle usw.; Mobilitätssteuerung im verbundenen Modus, verwendet zum Steuern von Operationen von Handover (HO), Conditional Handover (CHO), Dual Active Protocol Stack (DAPS) HO usw.; Funkzugangssteuerung, verwendet zur Modifikation von Parametern in Bezug auf RACH-Back-off, RRC-Verbindungsabweisung, RRC-Verbindungsfreigabe, Zugangssperre, UE-Zulassung usw. steuert; Doppelkonnektivitäts(DC)-Steuerung, verwendet zum Steuern von Operationen von Doppelkonnektivität (DC), einschließlich einer Änderung des Trägerendpunkts (MN oder SN) und/oder von Trägertypen, usw.; Trägeraggregations(CA)-Steuerung, verwendet zum Steuern von Operationen der Trägeraggregation (CA); und Leerlaufmodus-Mobilitätssteuerung, verwendet zur Modifikation von Intrafrequenz-, Interfrequenz-, Inter-RAT-Zellen-Neuauswahlpriorität, Leerlauftimer usw.; und UE-zu-RAN-UE-Gruppenzuordnung, verwendet zur Unterstützung von POLICY-Diensten.

Die E2SM-RC-CONTROL-Dienstanforderungen werden unter Verwendung eines Satzes von CONTROL-Stilen angeboten. Jeder Stil entspricht einem Satz von „CONTROL-Aktionen“, wobei sich jede „CONTROL-Aktion“ auf eine spezifische Funktionalität bezieht und einen Satz assoziierter RAN-Parameter aufweist, die in einer Abbildungstabelle bereitgestellt sind. Alle CONTROL-Dienststile werden unter Verwendung eines Satzes von IEs implementiert, die „RIC-Steuerungsanforderungskopf“ und „RIC-Steuerungsanforderungsnachricht“ bilden, um RAN-steuerungsbezogene CONTROL-Dienste zu liefern. Eine „CONTROL-Aktion“, die einen oder mehrere RAN-Parameter und ihre assoziierten Werte enthält, kann entweder von der RIC entweder asynchron an den E2-Knoten oder als eine Reaktion auf einen vorherigen „INSERT-Hinweis“ von dem E2-Knoten gesendet werden. Tabelle 12 zeigt die unterstützten CONTROL-Dienst-Stiltypen. Tabelle 12: CONTROL-Dienst-Stiltypen

RIC-Stiltyp	Stil-Name	Stil-Beschreibung
1	Funkträgersteuerung	Verwendet zum Modifizieren der Konfiguration der Funkträgersteuerungs(RBC)-bezogenen Parameter und/oder der Verhaltensweisen am E2-Knoten für ein spezifisches UE
2	Funkressourcenzuweisungssteuerung	Verwendet zum Modifizieren der Konfiguration der Funkressourcenzuweisungssteuerungs-bezogenen Parameter und/oder Verhaltensweisen am E2-Knoten für einen spezifischen E2-Knoten, eine spezifische Zelle, ein spezifisches Segment, UE und/oder QoS
3	Mobilitätssteuerung im verbundenen Modus	Verwendet zum Initiieren einer Verbindungsmodus-Mobilitätsprozedur (Handover oder Conditional-Handover), optional mit Dual Active Protocol Stack (DAPS), für ein spezifisches UE entweder zu einer Zielzelle (für HO) oder einer Liste von Kandidatenzellen (für CHO)
4	Funkzugangssteuerung	Verwendet zum Modifizieren von funkzugangsbezogenen Funktionen zum Steuern des UE-Zugriffs auf Zellen
5	Doppelkonnektivitäts(DC)-Steuerung	Verwendet zum Initiieren von Doppelkonnektivitäts(DC)-Mechanismen
6	Trägeraggregations(CA)-Steuerung	Verwendet zum Initiieren von Trägeraggregations(CA)-Mechanismen
7	Mobilitätssteuerung im Leerlaufmodus	Verwendet zum Modifizieren von mobilitätsbezogenen Funktionen im Leerlaufmodus zum Steuern der UE-Neuauswahl von Zellen
8	UE-Informationen und -Zuordnung	Verwendet für Explizit-UE-Listen-Zuordnung, UE-Informationsberichtgenerierung und zum Abschließen der UE-Identifikation. Diese Dienste werden zur Unterstützung anderer RIC-Dienste verwendet.

Jeder der in Tabelle 12 aufgelisteten Steuerdienstzustände 1-8 beinhaltet die folgenden gemeinsamen Merkmale: Steueraktions-ID (die Index-ID für die individuelle Steueraktion unter einem gegebenen Steuerdienststil), Steueraktionsname (gibt die Funktionalität des E2-Knotens an, der durch die Nahezu-RT-RIC gesteuert wird), Steueraktionsbeschreibung (beschreibt die Steueraktion und Funktionalität des E2-Empfangsknotens) und assoziierte RAN-Parameter (identifiziert die RAN-Parameter, die durch die Nahezu-RT-RIC zu steuern sind, die zu der gegebenen Steueraktion gehören).
Der CONTROL-Dienststil 1 (Funkträgersteuerung) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines funkträgersteuerungsbezogenen Prozesses unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: DRB-QoS-Modifikation, um QoS-bezogene Parameter auf DRB-Ebene abzustimmen, um die QoS-Optimierungsziele zu erfüllen; QoS-Fluss-(Neu-)Abbildung, um die Abbildungsbeziehung zwischen QoS-Flüssen und DRBs anzupassen; Logikkanal-(Neu- )Konfiguration; Funkträgerzugangssteuerung, um eine DRB-Zugangssteuerung zu konfigurieren, wobei etwa Ablehnung oder Freigabe angewendet werden kann; und Splitträger-und PDCP-Duplizierungssteuerung.
Der CONTROL-Dienststil 2 (Funkressourcenzuweisungssteuerung) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines funkressourcenzuweisungssteuerungsbezogenen Prozesses unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: diskontinuierliche Empfangs(DRX)-Steuerung; Planungsanforderungs(SR)-Steuerung; Steuerung der semipersistenten Planung (SPS); Steuerung von konfigurierten Bewilligungen; PRB-Quote auf Segmentebene; und Kanalqualitätsindikator(CQI)-Tabelle.
Der CONTROL-Dienststil 3 (Mobilitätssteuerung im verbundenen Modus) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines mobilitätssteuerungsbezogenen Prozesses im verbundenen Modus unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: Handover(HO)-Initiierung für ein ausgewähltes UE in Richtung einer Zielzelle; Initiierung eines bedingten Handovers (CHO) für ein ausgewähltes UE in Richtung einer Liste von einer oder mehreren Kandidatenzellen; und Handover(HO)-Initiierung mit Dual Active Protocol Stack (DAPS) für ein ausgewähltes UE in Richtung einer Zielzelle.
Der CONTROL-Dienststil 4 (Funkzugangssteuerung) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines funkzugangssteuerungsbezogenen Prozesses unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: RACH-Back-off; RRC-Verbindungsablehnung; RRC-Verbindungsfreigabe; Zugangssperre; und UE-Zulassung.
Der CONTROL-Dienststil 5 (DC-Steuerung) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines doppelkonnektivitätsbezogenen Prozesses unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf-IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: Initiierung von Doppelkonnektivität (EN-DC, MR-DC oder NR-NR DC) für ein ausgewähltes UE in Richtung einer Zielsekundärzelle (PScell); Sekundärzellenwechsel für ein ausgewähltes UE in Richtung einer Zielsekundärzelle (PScell); Modifikation von Doppelkonnektivität (EN-DC, MR-DC oder NR-NR DC) für ein ausgewähltes UE; Freigabeinitiierung von Doppelkonnektivität (EN-DC, MR-DC oder NR-NR DC) für ein ausgewähltes UE; und Änderung des Trägerendpunkts (MN oder SN) und/oder von Trägertypen für ein ausgewähltes UE.
Der CONTROL-Dienststil 6 (CA-Steuerung) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines trägeraggregationsbezogenen Prozesses unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf-IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: CA-Initiierung für ein ausgewähltes UE in Richtung einer Sekundärzielzelle oder von Sekundärzielzellen; Sekundärzellenänderung für ein ausgewähltes UE in Richtung einer Sekundärzielzelle oder von Sekundärzielzellen; CA-Modifikation für ein ausgewähltes UE; und CA-Freigabeinitiierung für ein ausgewähltes UE.
Der CONTROL-Dienststil 7 (Mobilitätssteuerung im Leerlaufmodus) stellt einen Mechanismus zum Initiieren oder Wiederaufnehmen eines mobilitätssteuerungsbezogenen Prozesses im Leerlaufmodus unter Verwendung des RIC-Steuernachrichten-IE und des assoziierten RIC-Steuerkopf-IE und des optionalen RIC-Aufruf-Prozess-ID-IE bereit, die verwendet werden, wenn ein Aufrufprozess anschließend an einen vorherigen INSERT-Dienst wiederaufgenommen wird. Anwendungen dieses Dienstes beinhalten: Intrafrequenz-, Interfrequenz-, Inter-RAT-Zellen-Neuauswahlpriorität; und Leerlauftimer.
Der CONTROL-Dienststil 8 (UE-Informationen und -Zuordnung) stellt einen Mechanismus bereit, um UE-Informationen sowohl direkt als auch indirekt zu überwachen und zu steuern und explizite UE-Zuordnungen zu expliziten UE-Listen hinzuzufügen oder zu entfernen. Anwendungen dieses Dienstes beinhalten: UE-zu-Explizit-UE-Listenzuordnungsbefehl: verwendet zum Hinzufügen oder Entfernen des nominierten UE zum Explizit-UE-Liste-Namen, auch verwendet zum Anfordern einer Liste unterstützter Explizit-UE-Listen; UE-Informationsanforderung: Verwendet zum Erhalten von UE-Informationen einschließlich einer Liste von Explizit-UE-Listen-Zuordnungen; und UE-Identifikationsanforderung: verwendet, um die UE-Identifikation abzuschließen.
4.2.2.4. POLICY-Dienst
Die E2SM-RC-RAN-Funktion bietet eine selektive Unterstützung der folgenden POLICY-Dienste: Funkträgerrichtlinie, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf DRB-QoS-Steuerung, QoS-Fluss-auf-DRB-Abbildung, Logikkanal-Konfiguration, Funkträgerzugangssteuerung, Splitträger- und PDCP-Duplizierungssteerung usw.; Funkressourcenzuweisungsrichtlinie, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf DRX, SR, SPS, konfigurierte Bewilligung, PRB-Quote auf Segmentebene, CQI-Tabelle usw.; Mobilitätsrichtlinie im verbundenen Modus, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf HO, CHO, DAPS HO usw. sowohl für Versorgungs- als auch für Ziel-RAN-Knoten; Funkzugangsrichtlinie, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf RACH-Back-off, RRC-Verbindungsablehnung, RRC-Verbindungsfreigabe, Zugangssperrung, UE-Zulassung usw.; Doppelkonnektivitäts(DC)-Richtlinie, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf DC-bezogene Operationen sowohl für Master- als auch sekundäre RAN-Knoten, Änderung des Trägerterminationspunkts (MN oder SN) und/oder von Trägertypen usw.; Trägeraggregations(CA)-Richtlinie, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf CA-bezogene Operationen sowohl für Primär- als auch Sekundärzellen; und Mobilitätsrichtlinie im Leerlaufmodus, verwendet zum Modifizieren des Verhaltens von Aufrufprozessen in Bezug auf Intrafrequenz- , Inter-Frequenz-, Inter-RAT-Zellen-Neuauswahlpriorität, Inaktivitätstimer usw.
Die in Abschnitt 6.2.4. definierten E2SM-RC-POLICY-Dienstanforderungen werden unter Verwendung eines Satzes von POLICY-Stilen angeboten. Jeder Stil wird unter Verwendung mehrerer „Richtlinienansatz“-Strategien implementiert, jeweils mit einer spezifischen Methodik, die definiert ist, um die E2AP-IE-„Aktionsdefinition“ zu verwenden, um RAN-steuerungsbezogene POLICY-Dienste zu liefern.
Es sind die folgenden Richtlinienansätze definiert: Steuerung und Offset. Eine Steuerrichtlinie für eine gegebene Stil- und Aktions-ID ist als ein einziger Fall einer spezifischen Richtlinienbedingung definiert, wobei die entsprechende Richtlinienaktion unter Verwendung derselben Datenstruktur wie CONTROL definiert ist, das verwendet werden würde, um standardmäßiges RAN-Verhalten zu ersetzen. Eine Offset-POLICY für eine gegebene Stil- und Aktions-ID ist als eine Menge von verschiedenen Fällen definiert, die auf eine Reihe von unterschiedlichen Richtlinienbedingungen anwendbar sind, wobei die entsprechende Richtlinienaktion unter Verwendung der dedizierten Datenstruktur definiert ist, die für POLICY definiert ist, das verwendet werden würde, um standardmäßiges RAN-Verhalten zu modifizieren.
Der Richtlinienansatz „Steuern“ ähnelt dem CONTROL-Dienst, wobei statische Bedingungen und Aktionen in der RIC-Subskription zum Auswählen einer geeigneten CONTROL-Aktion verwendet werden. Wenn ein Satz von Richtlinienbedingungen erfüllt ist, dann wird ein E2-Knoten angewiesen, eine Richtlinienaktion mit einem Satz von ergänzenden oder standardmäßigen Satz von RAN-Parametern auszuführen.
Eine einzige Richtlinienaktion soll ein Ergebnis der Ausführung mehrerer Richtlinienbedingungen sein. Jede Richtlinienbedingung wird unter Verwendung einer Kombination von RAN-Parametern und bedingten Tests definiert, die mit UE- und aufrufprozessbezogenen Informationen assoziiert sind. Jede Richtlinienaktion ist mit einer einzigen Richtlinienaktions-ID (Befehl) definiert, die den E2-Knoten anweist, eine gewisse Aktion durchzuführen, wenn die Bedingungen erfüllt sind. Die Richtlinienaktions-ID soll mit einem Satz von RAN-Parametern ergänzt werden, die verwendet werden können, um Informationen über Standardwerte an den E2-Knoten zu liefern.
Ein Beispiel beinhaltet Mobilitätsrichtlinie im verbundenen Modus, Handover-Ausführung: ein Nachrichtenankunfts-Unterbrechungspunktereignisauslöser ist definiert, um den Richtliniendienst zu initiieren. Beim Eintreffen des A3-Messberichts kommt der Richtliniendienst zur Anwendung. Der Richtliniendienst installiert einen Satz von Richtlinienbedingungen, wie RSRP > ,x‘ db + Zielknotenlast < ,x‘-Wert + Anzahl erfolgreicher HO zu Zielknoten > ,x‘-Wert. Wenn diese Richtlinienbedingungen erfüllt sind, dann Durchführen einer Richtlinienaktion -„HO ausführen“, die im CONTROL-Dienst in Abschnitt 6.5 definiert ist. Die Richtlinienaktion kann als eine eigenständige Richtlinienaktions-ID „HO ausführen“ ohne RAN-Parameter bereitgestellt werden. Alternativ dazu kann die Richtlinienaktion „HO ausführen“ mit Standard-RAN-Parametern ergänzt werden, wie etwa Nur-Handover-QCI-5- und -9-Trägern.
Ein anderes Beispiel beinhaltet CA-Richtlinie, CA-Freigabeentscheidung: ein Aufrufprozess-Unterbrechungspunktereignisauslöser ist definiert, um den POLICY-Dienst zu initiieren. Der Aufrufprozessunterbrechungspunkt soll Bedingungen für eine Pufferbelegung definieren. Ein Aufrufprozess-Unterbrechungspunktereignis soll ausgelöst werden, wenn die Pufferbelegung (BO) < ,x‘ KB ist. In diesem Szenario erfüllt der Ereignisauslöser die Richtlinienbedingung. Daher besteht keine Notwendigkeit, eine Richtlinienbedingung in dem Richtliniendienst zu definieren, wenn BO < ,x‘ KB wirksam wird, dann soll die Richtlinienaktion den E2-Knoten anweisen, „Scell freigeben“.
Der „Offset“-Richtlinienansatz basiert auf der Gestaltungsannahme, dass das Richtlinienaktions-IE verwendet wird, um einen oder mehrere RAN-Parameter zu tragen, die verwendet werden, um standardmäßiges E2-Knotenverhalten über die Hinzufügung eines „Offset“ zu modifizieren, der auf eine gegebene Zielschwelle oder einen anderen Parameter anzuwenden ist, die bzw. der im Zielaufrufprozess verwendet wird.
Die anwendbare Richtlinienaktion hängt von einem Satz von Richtlinienbedingungen ab und ein gegebener POLICY-Dienst kann eine oder mehrere Richtlinienbedingungen unterstützen und somit eine zielgerichtete Richtlinienaktion für einen Bereich unterschiedlicher spezifischer Fälle bereitstellen, die jeweils unter Verwendung einer eindeutigen Richtlinienbedingung definiert sind, wobei: jede Richtlinienbedingung unter Verwendung einer Kombination von RAN-Parametern und bedingten Tests definiert ist, die mit UE- und aufrufprozessbezogenen Informationen assoziiert sind. Die erste positive Übereinstimmung in einer Liste von Richtlinienbedingungen wird verwendet, um die entsprechende Richtlinienaktion auszuwählen. Zusätzlich oder alternativ wird jede Richtlinienaktion unter Verwendung einer Liste von RAN-Parametern vom Datentyp GANZZAHL oder REELL definiert, die direkt für Standardwerte vom Typ GANZZAHL oder REELL (z. B. Standardwert + Offset) und indirekt für Standardwerte vom Typ AUFZÄHLUNG verwendet werden können (z. B. Auswählen eines Werts in der Liste, der vor oder nach dem Standardwert versetzt ist).
Ein Beispiel beinhaltet Mobilitätsrichtlinie im verbundenen Modus, Handover-Entscheidung: Ein Aufrufprozess-Unterbrechungspunktereignisauslöser ist definiert, um den POLICY-Dienst von innerhalb des Aufrufprozesses zu initiieren, der UE-Messberichte in Bezug auf Handover-Entscheidungen für ein spezifisches Zielsegment und eine spezifische Primärzelle handhabt, die gegenwärtig einer Verkehrslenkungsführung unterliegen. Die Richtlinienbedingungsliste von RAN-Parametern unterstützt die Definition unterschiedlicher A3-Messschwellenkriterium-Offsetwerte, die auf UEs mit einer spezifischen Kombination aus Segment-ID, aktiven QoS-Trägern, Geschwindigkeit und Durchsatz anzuwenden sind und insgesamt E2-Knoten-Last- und Zellenebenenlastausgleichanforderungen unterliegen. Ein Handover wird akzeptiert, falls die gemeldete A3-Messung größer als die standardmäßige A3-Messschwelle + Offset ist.
Ein anderes Beispiel beinhaltet Trägeraggregationsrichtlinie, CA-Freigabeentscheidung: Ein Aufrufprozess-Unterbrechungspunktereignisauslöser ist definiert, um den POLICY-Dienst von innerhalb des Aufrufprozesses in Bezug auf Trägeraggregations(CA)-Freigabeentscheidungen für ein spezifisches Zielsegment und eine spezifische Primärzelle zu initiieren, die gegenwärtig einer QoE-Lenkung unterliegen. Die Richtlinienbedingungsliste von RAN-Parametern unterstützt die Definition unterschiedlicher CA-Freigabeschwellenkriterium-Offsetwerte, die auf UEs mit einer spezifischen Kombination aus Segment-ID, aktiven QoS-Trägern, Geschwindigkeit und Durchsatz anzuwenden sind und insgesamt E2-Knoten-Last- und Zellenebenenlastausgleichanforderungen unterliegen. Die CA-Freigabe wird initiiert, falls der UE-Durchsatz kleiner als die Standard-UE-Durchsatzschwelle + Offset ist.
4.2.2.5. RAN-Parameter für Steueraktionen
Die RAN-Parameter, die mit jeder Steueraktion assoziiert sind, die durch die Nahezu-RT-RIC gesteuert wird, die in Abschnitt 7.6 beschrieben ist, sind aufgelistet. Jeder RAN-Parameter gehört zu einem der folgenden Wertetypen:
ELEMENT: eine Einelementvariable, der keine anderen RAN-Parameter zugeordnet sind.
STRUKTUR: eine Folge von RAN-Parametern, von denen jeder entweder ein ELEMENT oder eine STRUKTUR oder eine LISTE sein kann.
LISTE: eine Liste von STRUKTUREN, wobei jede STRUKTUR wie oben definiert ist. Die Folge von RAN-Parametern ist über alle STRUKTUREN innerhalb der Liste hinweg gleich.
Auf die entsprechenden 3GPP-Standarddefinitionen dieser RAN-Parameter (falls verfügbar) wird in den folgenden Tabellen unter der Spalte „RAN-Parameterdefinition“ verwiesen. Diese RAN-Parameter mit 3GPP-Standarddefinitionen sind hier nicht neu definiert oder umdefiniert.
Es ist anzumerken, dass nur jene RAN-Parameter, die als ELEMENT identifiziert werden, durch die Nahezu-RT-RIC gesteuert werden. Es wird angemerkt, dass ein RAN-Parameter als ein Schlüssel assoziiert sein kann, bei dem sein entsprechendes Schlüssel-Flag auf „WAHR“ gesetzt ist. Diese RAN-Parameter dienen als ein Verweis auf andere RAN-Parameter innerhalb einer Struktur, die Teil der LISTE sein kann, um dem E2-Knoten zu ermöglichen, den Umfang von RAN-Parametern zu interpretieren, die durch die Nahezu-RT-RIC gesteuert werden.
4.2.2.5.1. Funkträgersteuerung
DRB-QoS-Konfiguration: Nach Empfangen der RIC-Steueranforderungs-Nachricht ruft der E2-Knoten Prozeduren in Bezug auf eine DRB-QoS-Konfiguration auf, wie etwa Trägerkontextverwaltung, UE-Kontextverwaltung, RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen Schnittstellennachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler. Nach Empfangen der RIC-Steueranforderungs-Nachricht ruft der E2-Knoten Prozeduren in Bezug auf eine QoS-Fluss-Abbildungs-Konfiguration auf, wie etwa Trägerkontextverwaltung, UE-Kontextverwaltung, RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen Schnittstellennachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler.
Logikkanal-Konfiguration: Nach Empfangen der RIC-Steueranforderungs-Nachricht ruft der E2-Knoten Prozeduren in Bezug auf eine Logikkanal-Konfiguration auf, wie etwa RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen RRC-Nachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler.
Funkträgerzulassungssteuerung: Nach Empfangen der RIC-Steueranforderungs-Nachricht ruft der E2-Knoten Prozeduren in Bezug auf eine Funkträgerzulassungssteuerung auf, wie etwa Trägerkontextverwaltung, UE-Kontextverwaltung, RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen Schnittstellennachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler.

DRB-Abschlusssteuerung: Nach Empfangen der RIC-Steueranforderungs-Nachricht ruft der E2-Knoten Prozeduren in Bezug auf eine DRB-Abschlussänderung auf, wie etwa Doppelkonnektivitäts-Sekundärknotenmodifikation (MN/SN-initiiert), UE-Kontextverwaltung, RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen Schnittstellennachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler. Bei manchen Implementierungen kann die RIC-Steuerungsanforderungs-Nachricht in Bezug auf die DRB-Abschlussänderung zur Trägerankerknotenauswahl verwendet werden. Tabelle 13 zeigt RAN-Parameter für die DRB-Abschlusssteuerung. Tabelle 13

RAN-Parameter-ID	RAN-Parameter	RAN-Parameterwertetyp	Schlüsselparam	RAN-Parameterdefinition	Semantikbeschreibung
1	Liste von DRBs, die auf SN-Abschluss zu modifizieren sind	LISTE			Zu-modifizierende-DRBs-IE in 3GPP TS 38.423 v16.6.0 (2021-07-01) („[TS38423]“), Abschnitt 9.2.1.11
2	>DRB-Element, das auf SN-Abschluss zu modifizieren ist	STRUKTUR			Zu-modifizierende-DRBs-Element-IE in [TS38423], Abschnitt 9.2.1.11
3	>>DRB-ID	ELEMENT	TRUE	DRS-/D-IE in [TS38423], Abschnitt 9.2.3.33
4	>>Logikkanal-ID	ELEMENT	FALSE	LCID-IE in TS [TS38423], Abschnitt 9.2.3.70
5	>>RLC-Status	ELEMENT	FALSE	RLC-Status-IE in [TS38423], Abschnitt 9.2.3.80
6	>>Liste von QoS-Flüssen, die auf SN-Abschluss zu modifizieren sind	LISTE			QoS-Flussliste-IE in [TS38423], Abschnitt 9.2.1.15
7	>>>QoS-Flusselement	STRUKTUR			QoS-Flusselement-IE in [TS38423], Abschnitt 9.2.1.15
8	>>>QoS-Fluss-ID	ELEMENT	TRUE	QoS-Flussidentifikator-IE in [TS38423], Abschnitt 9.2.1.15
9	>>>QoS-Flussabbild ungshinwei s	ELEMENT	FALSE	QoS-Flussabbildungshin weis-IE in [TS38423], Abschnitt 9.2.1.15
10	Liste von DRBs, die auf MN-Abschluss zu modifizieren ist	LISTE			Zu-modifizierende-DRBs-IE in [TS38423], Abschnitt 9.2.1.9
11	>DRB-Element, das auf MN-Abschluss zu modifizieren ist	STRUKTUR			Zu-modifizierende-DRBs-Element-IE in [TS38423], Abschnitt 9.2.1.9
12	>>DRB-ID	ELEMENT	TRUE	DRS-/D-IE in [TS38423], Abschnitt 9.2.3.33
13	>>Logikkanal-ID	ELEMENT	FALSE	LCID-IE in [TS38423], Abschnitt 9.2.3.70
14	>>RLC-Status	ELEMENT	FALSE	RLC-Status-IE in [TS38423], Abschnitt 9.2.3.80
15	>>Liste von QoS-Flüssen, die auf SN-Abschluss zu modifizieren sind	LISTE			QoS-Flussliste-IE in [TS38423], Abschnitt 9.2.1.15
16	>>>QoS-Flusselement	STRUKTUR			QoS-Flusselement-IE in [TS38423], Abschnitt 9.2.1.15
17	>>>QoS-Fluss-ID	ELEMENT	TRUE	QoS-Flussidentifikator-IE in [TS38423], Abschnitt 9.2.1.15
18	>>>QoS-Flussabbild ungshinwei s	ELEMENT	FALSE	QoS-Flussabbildungshin weis-IE in [TS38423], Abschnitt 9.2.1.15

DRB-Aufteilungsverhältnissteuerung: Nach Empfangen der RIC-Steuerungsanforderungs-Nachricht soll der E2-Knoten bei Vorhandensein eines Downlink-PDCP-Datenaufteilungs-IE den Downlink-PDCP-Verkehr zwischen dem Master-Knoten und dem Sekundärknoten über die X2/Xn-Schnittstelle basierend auf dem empfohlenen Verhältnis aufteilen. Nach Empfangen des Uplink-PDCP-Datenaufteilungsschwellen-IE ruft der E2-Knoten Prozeduren in Bezug auf eine DRB-Aufteilungsverhältnissteuerung auf, wie etwa Trägerkontextverwaltung, UE-Kontextverwaltung, RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen Schnittstellennachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler. Bei manchen Implementierungen kann die RIC-Steuerungsanforderungs-Nachricht in Bezug auf die DRB-Aufteilungsverhältnissteuerung für das Aufteilungsverhältnis für den Aufteilungsträger verwendet werden. Tabelle 14 zeigt RAN-Parameter für die DRB-Aufteilungsverhältnissteuerung. Tabelle 14

RAN-Parameter-ID	RAN-Parameter	RAN-Parameterwertetyp	Schlüsse I-Flag	RAN-Parameterdefinition	Semantikbeschreibung
1	DRB-ID	ELEMENT	TRUE	DRB-ID-IE in 3GPP TS 38.463 v16.6.0 (2021-07-01) („[TS38463]“), Abschnitt 9.3.1.16
2	Uplink-PDCP-Datenaufteilungssch welle	ELEMENT	FALSE	UL-Datenaufteilungssc hwelle-IE in [TS38463], Abschnitt 9.3.1.43
3	Downlink-PDCP-Datenaufteilung	ELEMENT	FALSE	GANZZAHL (0..100) Definiert in [TS38463], Abschnitt 9.4.2	Gibt den Prozentsatz von PDCP-Verkehr an, den das MN mit dem SN aufteilen muss.

PDCP-Duplikationssteuerung: Nach Empfangen der RIC-Steueranforderungs-Nachricht ruft der E2-Knoten Prozeduren in Bezug auf eine PDCP-Duplikationssteuerung auf, wie etwa Trägerkontextverwaltung, UE-Kontextverwaltung, RRC-Nachrichtentransfer usw., und nimmt die IEs, die einem oder mehreren der unten beschriebenen Parameter entsprechen, in den zugehörigen Schnittstellennachrichten auf. Falls die DRB-ID in der RIC-Steueranforderungs-Nachricht fehlt, sendet der E2-Knoten einen RIC-Steuerungsfehler.
5. HARDWAREKOMPONENTEN, KONFIGURATIONEN UND ANORDNUNGEN
25 veranschaulicht eine Softwareverteilungsplattform 2505 zum Verteilen von Software 2560, wie etwa den beispielhaften computerlesbaren Anweisungen 2760 von 27, an eine oder mehrere Vorrichtungen, wie etwa beispielhafte Prozessorplattform(en) 2500 und/oder beispielhafte verbundene Edge-Vorrichtungen 2762 (siehe z. B. 27) und/oder beliebige der anderen hier erörterten Rechensysteme/Vorrichtungen. Die beispielhafte Softwareverteilungsplattform 2505 kann durch einen beliebigen Computerserver, eine beliebige Datenanlage, einen beliebigen Cloud-Dienst usw. implementiert werden, der bzw. die in der Lage ist, Software zu speichern und an andere Rechenvorrichtungen (z. B. Drittparteien, die beispielhaften verbundenen Edge-Vorrichtungen 2762 von 27) zu übertragen. Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (z. B. Server), Dritte (z. B. Kunden einer Entität, die die Softwareverteilungsplattform 2505 besitzt und/oder betreibt) sein. Beispielhafte verbundene Edge-Geräte können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. In manchen Beispielen ist eine Drittpartei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa den beispielhaften computerlesbaren Anweisungen 2760 von 27. Die Drittparteien können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren. In manchen Beispielen bewirkt verteilte Software, dass eine Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs) die eine oder die mehreren Vorrichtungen (z. B. angebundene Edge-Vorrichtungen) geographisch und/oder logisch voneinander getrennt identifiziert (z. B. physisch getrennte IoT-Vorrichtungen, gekennzeichnet durch die Verantwortung von Wasserverteilungssteuerung (z. B. Pumpen), Stromverteilungssteuerung (z. B. Relais) usw.).
In 25 beinhaltet die Softwareverteilungsplattform 2505 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen. Die Speicherungsvorrichtungen speichern computerlesbare Anweisungen 2560, die den beispielhaften computerlesbaren Anweisungen 2760 von 27 entsprechen können, wie oben beschrieben. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 2505 stehen in Kommunikation mit einem Netzwerk 2510, das einem beliebigen oder mehreren beliebigen des Internets und/oder beliebigen der hierin beschriebenen beispielhaften Netzwerke entsprechen kann. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Software als Teil einer kommerziellen Transaktion an eine anfordernde Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittanbieter-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 2560 von der Softwareverteilungsplattform 2505 herunterzuladen. Zum Beispiel kann die Software 2560, die den beispielhaften computerlesbaren Anweisungen 2760 von 27 entsprechen kann, auf die eine oder die mehreren beispielhaften Prozessorplattformen 2500 heruntergeladen werden, die die computerlesbaren Anweisungen 2560 ausführen sollen, um Funk-Apps zu implementieren.
In manchen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 2505 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 2560 laufen müssen. In einigen Beispielen bieten ein oder mehrere Server des Softwareverteilungsplattform 2505 periodisch Aktualisierungen an der Software (z. B. den beispielhaften computerlesbaren Anweisungen 2760 von 27) an, übertragen und/oder erzwingen diese, um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewendet werden.
In 25 sind die computerlesbaren Anweisungen 2560 auf Speicherungsvorrichtungen der Softwareverteilungsplattform 2505 in einem bestimmten Format gespeichert. Ein Format von computerlesbaren Anweisungen beinhaltet unter anderem eine bestimmte Codesprache (z. B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen speziellen Codezustand (z. B. uncompilierten Code (z. B. ASCII), interpretierten Code, gelinkten Code, ausführbaren Code (z. B. eine Binärdatei) usw.). In manchen Beispielen befinden sich die computerlesbaren Anweisungen D182, die in der Softwareverteilungsplattform 2505 gespeichert sind, in einem ersten Format, wenn sie an die eine oder die mehreren beispielhaften Prozessorplattformen 2500 übertragen werden. In einigen Beispielen ist das erste Format eine ausführbare Binärdatei, in der bestimmte Typen der einen oder mehreren Prozessorplattformen 2500 ausgeführt werden können. In einigen Beispielen ist das erste Format jedoch uncompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, um eine Ausführung auf der einen oder den mehreren beispielhaften Prozessorplattformen 2500 zu ermöglichen. Beispielsweise müssen die eine oder die mehreren empfangenden Prozessorplattformen 2500 möglicherweise die computerlesbaren Anweisungen 2560 im ersten Format compilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der auf der einen oder den mehreren Prozessorplattformen 2500 ausgeführt werden kann. In noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der einen oder der mehreren Prozessorplattformen 2500 durch einen Interpreter interpretiert wird, um die Ausführung von Anweisungen zu ermöglichen.
26 und 27 stellen weitere Beispiele für Edge-Rechensysteme und Umgebungen dar, die beliebige der hierin besprochenen Rechenknoten oder Vorrichtungen erfüllen können. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, das bzw. der in der Lage ist, mit anderen Edge-, Netzwerk- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System ausgebildet sein, die bzw. das in der Lage ist, die beschriebenen Funktionen durchzuführen.
In 26 beinhaltet ein Edge-Rechenknoten 2600 eine Rechen-Engine (hierin auch als „Rechenschaltungsanordnung“ bezeichnet) 2602, ein Eingabe/Ausgabe(E/A)-Subsystem 2608, eine Datenspeicherung 2610, ein Kommunikationsschaltungsanordnungssubsystem 2612 und optional eine oder mehrere Peripherievorrichtungen 2614. In anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Komponenten enthalten, wie diejenigen, die üblicherweise in einem Computer zu finden sind (z. B. eine Anzeige, periphere Vorrichtungen usw.). Eine oder mehrere der illustrativen Komponenten können zusätzlich in einigen Beispielen in eine andere Komponente eingebunden sein oder anderweitig einen Teil dieser bilden. Zusätzlich oder alternativ kann der Edge-Rechenknoten 2600 (oder können Teile davon) in einem Gehäuse, einem Chassis, einer Verkleidung oder einer Hülle enthalten sein, wie etwa jenen, die zuvor im Zusammenhang mit der Geräterechenvorrichtung der Edge-Cloud 1210 von 12 besprochen wurden.
Der Rechenknoten 2600 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen ausgebildet sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. Der Rechenknoten 2600 kann den UEs 101, RAN-Knoten 130, Edge-Rechenknoten 140 von 1; Koordinator 210 von 2; UEs 401, NANs 433, Edge-Rechenknoten 436, Echtzeitagent 501 von 5; UEs 601, DUs 630, RUs 633 und/oder Edge-Rechenknoten 436 und/oder Agent 640 von 6; UEs 1111, 1121a, NANs 1131-1133, Edge-Rechenknoten 1136, CN 1142 (oder Rechenknoten darin) und/oder Cloud 1144 (oder Rechenknoten darin) von 11; Edge-Cloud 1210 (oder Systemen/Vorrichtungen darin), Zentrale 1220 (oder Systemen/Vorrichtungen darin), NAN 1240, Verarbeitungshub 1250 und/oder Endpunktvorrichtungen 1260 von 12; Anwendungsfallsvorrichtungen 1305, Netzwerkgeräten (Knoten) 1315, Gerät 1325 von 13; Client-Endpunkten 1410, Vor-Ort-Netzwerksystem 1432, Zugangspunkt 1434, Aggregationspunkten 1442, 1444, Edge-Aggregationsknoten 1440 und/oder Rechenzentrum 1460 (oder Systemen/Vorrichtungen darin) von 14; Vorrichtungen 1510, Edge-Knoten 1522, 1524 und/oder Cloud/Rechenzentrum 1540 von 15; Containermanager 1611, 1621, Containerorchestrator 1631 und/oder Rechenknoten 1615, 1623 von 16; Client-Rechenknoten 1710, Edge-Gateway-Vorrichtungen 1720, Edge-Ressourcenknoten 1740, NAN 1742, Kerndatenzentrum 1750 (oder Systemen/Vorrichtungen darin) von 17; UE 1820, MEC-Host 1802 (oder Systemen/Vorrichtungen darin), OSS 1812 (oder Systemen/Vorrichtungen darin) von 18; ME-Plattform 1910 von 19; SMO 2002, O-RAN-NFs 2004, O-Cloud 2006, NG-Core 2008, dem externen System 2010, Nicht-RT-RIC 2012, Nahezu-RT-RIC 2014, O-RU 2016 aus 20; UE 2101, SMO 2102, O-Cloud 2106, O-e/gNB 2110, Nicht-RT-RIC 2112, Nahezu-RT-RIC 2114, O-DU 2115, O-RU 2116, O-CU-CP 2121, O-CU-UP 2122 und/oder 21; E2-Knoten von 22; Softwareverteilungsplattform 2505 und/oder Prozessorplattform(en) 2500 von 25; und/oder einer beliebigen anderen Komponente, Vorrichtung und/oder einem beliebigen anderen hierin erörterten System entsprechen.
In einigen Beispielen kann der Rechenknoten 2600 als eine einzelne Vorrichtung wie ein integrierter Schaltkreis, ein eingebettetes System, ein FPGA, ein Ein-Chip-System (SoC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung ausgebildet sein. Der Rechenknoten 2600 weist einen Prozessor 2604 und einen Speicher 2606 auf oder ist als diese ausgebildet. Der Prozessor 2604 kann als ein beliebiger Typ von Prozessor ausgebildet sein, der die hierin beschriebenen Funktionen (z. B. Ausführen einer Anwendung) durchführen kann. Der Prozessor 2604 kann als ein oder mehrere Mehrkernprozessoren, ein Mikrocontroller oder ein anderer Prozessor oder Verarbeitungs-/Steuerschaltkreis ausgebildet sein.
Bei einigen Beispielen kann der Prozessor 2604 als ein FPGA, ein anwendungsspezifischer integrierter Schaltkreis (ASIC), eine neu konfigurierbare Hardware oder Hardwareschaltungsanordnung oder eine andere spezialisierte Hardware ausgebildet sein, diese enthalten oder an diese gekoppelt sein, um eine Durchführung der hierin beschriebenen Funktionen zu ermöglichen. In manchen Beispielen kann der Prozessor 2604 auch als eine spezialisierte x-Verarbeitungseinheit (xPU) ausgebildet sein, die auch als eine Datenverarbeitungseinheit (DPU), eine Infrastrukturverarbeitungseinheit (IPU) oder eine Netzwerkverarbeitungseinheit (NPU) bekannt ist. Eine derartige xPU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungspaket ausgebildet sein, innerhalb eines SOC integriert sein oder mit einer Vernetzungsschaltungsanordnung (z. B. in einer SmartNIC oder erweiterten SmartNIC), einer Beschleunigungsschaltungsanordnung, Speicherungsvorrichtungen, Speicherungsplatten oder KI-Hardware (z. B. GPUs oder programmierte FPGAs) integriert sein. Eine derartige xPU kann ausgelegt sein, eine Programmierung zu empfangen, um einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme durchzuführen (wie etwa Hosten von Mikrodiensten, Durchführen von Dienstverwaltung oder Orchestrierung, Organisieren oder Verwalten von Server- oder Rechenzentrums-Hardware, Verwalten von vermaschten Dienstnetzwerken oder Sammeln und Verteilen von Telemetrie), außerhalb der CPU oder außerhalb von Allzweckverarbeitungshardware. Es versteht sich jedoch, dass eine xPU, ein SOC, eine CPU und andere Variationen des Prozessors 2604 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb und im Auftrag des Rechenknotens 2600 auszuführen.
Der Arbeitsspeicher 2606 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischem Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder Datenspeicher ausgebildet sein, der fähig ist, die hierin beschriebenen Funktionen durchzuführen. Flüchtiger Speicher kann ein Speicherungsmedium sein, das Energie erfordert, um den Zustand von vom Medium gespeicherten Daten zu bewahren. Nicht einschränkende Beispiele von flüchtigem Speicher können verschiedene Arten von Direktzugriffsspeicher (RAM) wie DRAM oder statischen Direktzugriffsspeicher (SRAM) enthalten. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
In einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie diejenigen, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine dreidimensionale Koppelpunktspeichervorrichtung (z. B. Intel® 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Speichervorrichtungen zum Schreiben an Ort und Stelle beinhalten. Die Speichervorrichtung kann den Chip selbst und/oder ein verpacktes Speicherprodukt bezeichnen. In einigen Beispielen kann der 3D-Koppelpunkt-Speicher (z. B. Intel® 3D XPoint™-Speicher) eine transistorlose stapelbare Koppelpunkt-Architektur umfassen, in der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und individuell adressierbar sind und in der eine Bitspeicherung auf einer Änderung im Bulkwiderstand basiert. In einigen Beispielen kann der gesamte oder ein Teil des Hauptspeichers 2606 in den Prozessor 2604 integriert sein. Der Hauptspeicher 2606 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
Die Rechenschaltungsanordnung 2602 ist über das E/A-Subsystem 2608 kommunikativ an andere Komponenten des Rechenknotens 2600 gekoppelt, das als Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 2602 (z. B. mit dem Prozessor 2604 und/oder dem Hauptspeicher 2606) und anderen Komponenten der Rechenschaltungsanordnung 2602 zu ermöglichen. Das E/A-Subsystem 2608 kann beispielsweise als Arbeitsspeichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmwarevorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verknüpfungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Bahnen auf gedruckten Leiterplatten usw.) und/oder andere Komponenten und Subsysteme ausgebildet sein oder diese anderweitig enthalten, um die Eingabe/Ausgabe-Operationen zu ermöglichen. Bei einigen Beispielen kann das E/A-Subsystem 2608 einen Abschnitt eines SoC bilden und zusammen mit einem oder mehreren des Prozessors 2604, des Hauptspeichers 2606 und anderer Komponenten der Rechenschaltungsanordnung 2602 in die Rechenschaltungsanordnung 2602 eingebunden sein.
Die eine oder mehreren veranschaulichenden Datenspeicherungsvorrichtungen/Datenspeicherungsplatten 2610 können als ein oder mehrere beliebige Typen von physischen Vorrichtungen ausgebildet sein, die zur kurzfristigen oder langfristigen Speicherung von Daten konfiguriert sind, wie zum Beispiel Speichervorrichtungen, Speicher, Schaltungsanordnungen, Speicherkarten, Flashspeicher, Festplattenlaufwerke, Festkörperlaufwerke (SSDs) und/oder andere Datenspeicherungsvorrichtungen/-platten. Individuelle Datenspeicherungsvorrichtungen/- platten 2610 können eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung/-platte 2610 speichert. Individuelle Datenspeicherungsvorrichtungen/-platten 2610 können auch eine oder mehrere Betriebssystempartitionen beinhalten, die Dateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel dem Typ des Rechenknotens 2600 speichern.
Die Kommunikationsschaltungsanordnung 2612 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder -sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 2602 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gatewayknoten oder dergleichen) zu ermöglichen. Die Kommunikationsschaltungsanordnung 2612 kann ausgelegt sein, eine oder mehrere beliebige Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein Mobilfunkvernetzungsprotokoll, wie etwa einen 3GPP-4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/WiFi®, ein drahtloses Funkfernnetzprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, Niedrigenergieweitverkehrnetz(LPWAN)- oder Low-Power-Wide-Area(LPWA)-Protokolle usw.) zu verwenden, um eine derartige Kommunikation zu bewirken.
Die Kommunikationsschaltungsanordnung 2612 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 2620, die auch als eine Host-Fabric-Schnittstelle (HFI) bezeichnet werden kann. Die NIC 2620 kann als ein oder mehrere Zusatzplatinen, untergeordnete Karten, Netzwerkschnittstellenkarten, Steuerchips, Chipsätze oder andere Vorrichtungen ausgebildet sein, die vom Rechenknoten 2600 verwendet werden können, um an eine andere Rechenvorrichtung anzubinden. In einigen Beispielen kann die NIC 2620 als ein Teil eines Ein-Chip-Systems (SoC) ausgebildet sein, das einen oder mehrere Prozessoren beinhaltet, oder in einem Mehrchipgehäuse enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. In einigen Beispielen kann die NIC 2620 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) enthalten, die beide lokal zur NIC 2620 sind. In derartigen Beispielen kann der lokale Prozessor der NIC 2620 fähig sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltungsanordnung 2602 durchzuführen. Zusätzlich oder alternativ kann der lokale Arbeitsspeicher der NIC 2620 in derartigen Beispielen in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chipebene und/oder anderen Ebenen integriert sein. Zusätzlich oder alternativ dazu kann die Kommunikationsschaltungsanordnung 2612 einen oder mehrere Sendeempfänger (TRx) 2621 beinhalten, die jeweils verschiedene Hardwarevorrichtungen/- komponenten, wie etwa einen oder mehrere Basisbandprozessoren, Schalter, Filter, Verstärker, Antennenelemente und dergleichen, beinhalten, um Kommunikationen über eine Luftschnittstelle zu ermöglichen.
Zusätzlich kann in manchen Beispielen ein jeweiliger Computerknoten 2600 eine oder mehrere Peripherievorrichtungen 2614 beinhalten. Derartige Peripherievorrichtungen 2614 können eine beliebige Art von Peripherievorrichtung beinhalten, die in einer Rechenvorrichtung oder einem Server gefunden wird, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe/Ausgabevorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 2600. In weiteren Beispielen kann der Rechenknoten 2600 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Rechensystem (z. B. Client-Rechenknoten, Edge-Gatewayknoten, Edge-Aggregationsknoten, V-ITS-Ss, die zuvor erörtert wurden, usw.) oder ähnlichen Formen von Geräten, Computern, Subsystemen, Schaltungsanordnungen oder anderen Komponenten ausgebildet sein.
27 veranschaulicht ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Rechenknoten 2750 zum Implementieren der hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methodiken) vorhanden sein können. Der Edge-Rechenknoten 2750 kann den UEs 101, RAN-Knoten 130, Edge-Rechenknoten 140 von 1; Koordinator 210 von 2; UEs 401, NANs 433, Edge-Rechenknoten 436, Echtzeitagent 501 von 5; UEs 601, DUs 630, RUs 633 und/oder Edge-Rechenknoten 436 und/oder Agent 640 von 6; UEs 1111, 1121a, NANs 1131-1133, Edge-Rechenknoten 1136, CN 1142 (oder Rechenknoten darin) und/oder Cloud 1144 (oder Rechenknoten darin) von 11; Edge-Cloud 1210 (oder Systemen/Vorrichtungen darin), Zentrale 1220 (oder Systemen/Vorrichtungen darin), NAN 1240, Verarbeitungshub 1250 und/oder Endpunktvorrichtungen 1260 von 12; Anwendungsfallsvorrichtungen 1305, Netzwerkgeräten (Knoten) 1315, Gerät 1325 von 13; Client-Endpunkten 1410, Vor-Ort-Netzwerksystem 1432, Zugangspunkt 1434, Aggregationspunkten 1442, 1444, Edge-Aggregationsknoten 1440 und/oder Rechenzentrum 1460 (oder Systemen/Vorrichtungen darin) von 14; Vorrichtungen 1510, Edge-Knoten 1522, 1524 und/oder Cloud/Rechenzentrum 1540 von 15; Containermanager 1611, 1621, Containerorchestrator 1631 und/oder Rechenknoten 1615, 1623 von 16; Client-Rechenknoten 1710, Edge-Gateway-Vorrichtungen 1720, Edge-Ressourcenknoten 1740, NAN 1742, Kerndatenzentrum 1750 (oder Systemen/Vorrichtungen darin) von 17; UE 1820, MEC-Host 1802 (oder Systemen/Vorrichtungen darin), OSS 1812 (oder Systemen/Vorrichtungen darin) von 18; ME-Plattform 1910 von 19; SMO 2002, O-RAN-NFs 2004, O-Cloud 2006, NG-Core 2008, dem externen System 2010, Nicht-RT-RIC 2012, Nahezu-RT-RIC 2014, O-RU 2016 aus 20; UE 2101, SMO 2102, O-Cloud 2106, O-e/gNB 2110, Nicht-RT-RIC 2112, Nahezu-RT-RIC 2114, O-DU 2115, O-RU 2116, O-CU-CP 2121, O-CU-UP 2122 und/oder 21; E2-Knoten von 22; Softwareverteilungsplattform 2505 und/oder Prozessorplattform(en) 2500 von 25; Rechenknoten 2600 von 26; und/oder einer beliebigen anderen Komponente, Vorrichtung und/oder einem beliebigen anderen hierin erörterten System entsprechen.
Der Edge-Rechenknoten 2750 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 2600 bereit, wenn er als oder als Teil einer Rechenvorrichtung (z. B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway, ein Gerät, ein Edge-Rechenknoten usw.) implementiert wird. Der Edge-Rechenknoten 2750 kann beliebige Kombinationen der hier referenzierten Hardware oder logischen Komponenten beinhalten und er kann eine beliebige Vorrichtung beinhalten oder an eine solche koppeln, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination derartiger Netzwerke verwendbar ist. Die Komponenten können als ICs, Abschnitte davon, diskrete elektronische Vorrichtungen oder andere Module, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die im Edge-Rechenknoten 2750 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems integriert sind, implementiert sein.
Der Edge-Rechenknoten 2750 weist eine Verarbeitungsschaltungsanordnung in Form eines oder mehrerer Prozessoren 2752 auf. Die Prozessorschaltungsanordnung 2752 beinhaltet eine Schaltungsanordnung, wie etwa unter anderem einen oder mehrere Prozessorkerne und eines oder mehrere von Zwischenspeicher, Low-Drop-Out-Spannungsreglern (LDOs), Unterbrechungssteuerungen, seriellen Schnittstellen, wie etwa SPI, I2C oder eine universelle programmierbare serielle Schnittstellenschaltung, Echtzeituhr (RTC), Zeitgeber-Zähler einschließlich Intervall- und Watchdog-Zeitgebern, Allzweck-E/A, Speicherkartensteuerungen, wie etwa Secure Digital/Multimedia Card (SD/MMC) oder dergleichen, Schnittstellen, Mobile-Industry-Processor-Interface(MIPI)-Schnittstellen und Joint-Test-Access-Group(JTAG)-Testzugangsanschlüsse. Bei manchen Implementierungen kann die Prozessorschaltungsanordnung 2752 einen oder mehrere Hardwarebeschleuniger (z. B. gleich oder ähnlich der Beschleunigungsschaltungsanordnung 2764) beinhalten, die Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen (z. B. FPGA, ASIC usw.) oder dergleichen sein können. Der eine oder die mehreren Beschleuniger können zum Beispiel Beschleuniger für Computervision und/oder tiefgehendes Lernen beinhalten. Bei manchen Implementierungen kann die Prozessorschaltungsanordnung 2752 eine chipinterne Speicherschaltungsanordnung beinhalten, die einen beliebigen geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flashspeicher, Festkörperspeicher und/oder einen beliebigen anderen Typ von Speichervorrichtungstechnologie, wie etwa jene hier erörterten, beinhalten kann.
Die Prozessorschaltungsanordnung 2752 kann zum Beispiel ein oder mehrere Prozessorkerne (CPUs), Anwendungsprozessoren, GPUs, RISC-Prozessoren, Acorn-RISC-Machine(ARM)-Prozessoren, CISC-Prozessoren, ein oder mehrere DSPs, ein oder mehrere FPGAs, eine oder mehrere PLDs, eine oder mehrere ASICs, ein oder mehrere Basisbandprozessoren, eine oder mehrere integrierte Funkfrequenzschaltungen (RFIC), ein oder mehrere Mikroprozessoren oder Steuerungen, ein Mehrkernprozessor, ein Multithreadprozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder beliebige andere bekannte Verarbeitungselemente oder eine beliebige geeignete Kombination davon sein. Die Prozessoren (oder Kerne) 2752 können mit Arbeitsspeicher/Speicher gekoppelt sein oder diesen aufweisen und können konfiguriert sein, im Arbeitsspeicher/Speicher gespeicherte Anweisungen auszuführen, um verschiedenen Anweisungen oder Betriebssystemen zu ermöglichen, auf der Plattform 2750 zu laufen. Der Prozessor (oder die Kerne) 2752 ist (bzw. sind) dazu ausgelegt, Anwendungssoftware zu betreiben, um einem Benutzer der Plattform 2750 einen spezifischen Dienst bereitzustellen. Zusätzlich oder alternativ dazu können der eine oder die mehreren Prozessoren 2752 ein oder mehrere Spezialprozessoren/-steuerungen sein, die dazu konfiguriert (oder konfigurierbar) sind, gemäß den hierin besprochenen Elementen, Merkmalen und Implementierungen zu arbeiten.
Als Beispiele können der eine oder die mehreren Prozessoren 2752 einen Intel® Architecture Core™-basierten Prozessor, wie etwa einen i3-, einen i5-, einen i7-, einen i9-basierten Prozessor; einen Intel® Mikrocontroller-basierten Prozessor, wie etwa einen Quark™-, einen Atom™- oder einen anderen MCU-basierten Prozessor; einen oder mehrere Pentium®-Prozessoren, einen oder mehrere Xeon®-Prozessoren oder einen anderen solchen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa eine oder mehrere Advanced Micro Devices (AMD) Zen®-Architekturen, wie etwa ein oder mehrere Ryzen®- oder EPYC®-Prozessoren, beschleunigte Verarbeitungseinheiten (APUs), MxGPUs, ein oder mehrere Epyc®-Prozessoren oder dergleichen; ein oder mehrere A5-A12- und/oder S1-S4-Prozessoren von Apple® Inc., ein oder mehrere Snapdragon™- oder Centriq™-Prozessoren von Qualcomm® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™-Prozessoren; ein MIPS-basiertes Design von MIPS Technologies, Inc. wie Prozessoren der MIPS Warrior M-Klasse, Warrior I-Klasse und Warrior P-Klasse; ein ARM-basiertes Design, lizenziert von ARM Holdings, Ltd., wie die ARM Cortex-A, Cortex-R und Cortex-M-Prozessorfamilie; das von Cavium™, Inc. bereitgestellte ThunderX2®; oder dergleichen. In einigen Implementierungen können der eine oder die mehreren Prozessoren 2752 ein Teil eines Ein-Chip-Systems (SoC), System-in-Package (SiP), ein Mehrchipgehäuse (MCP) und/oder dergleichen sein, in dem der eine oder die mehreren Prozessoren 2752 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel® Corporation. Andere Beispiele für den einen oder die mehreren Prozessoren 2752 sind an anderer Stelle der vorliegenden Offenbarung erwähnt.
Der eine oder die mehreren Prozessoren 2752 können über eine Zwischenverbindung (IX) 2756 mit einem Systemspeicher 2754 kommunizieren. Eine beliebige Anzahl an Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) in Übereinstimmung mit einem Design des Joint Electron Devices Engineering Council (JEDEC) sein, wie etwa den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In ermittelten Beispielen kann eine Speicherkomponente einen von JEDEC veröffentlichten DRAM-Standard erfüllen, 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 Niedrigenergie-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Andere RAM-Typen, wie etwa dynamischer RAM (DRAM), synchroner DRAM (SDRAM) und/oder dergleichen, können ebenfalls enthalten sein. Derartige Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die derartige Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichervorrichtungen aus einer beliebigen Anzahl von verschiedenen Gehäusetypen sein, wie ein Ein-Rohchip-Gehäuse (SDP), Doppel-Rohchip-Gehäuse (DDP) oder Quad-Rohchip-Gehäuse (Q17P). Diese Einrichtungen können in einigen Beispielen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit niedrigerem Profil zu bieten, während die Einrichtungen in anderen Beispielen als ein oder mehrere Speichermodule ausgelegt sind, die wiederum durch ein bestimmtes Verbindungsstück an die Hauptplatine koppeln. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann eine Speicherung 2758 auch über die IX 2756 an den Prozessor 2752 gekoppelt sein. In einem Beispiel kann die Speicherung 2758 über ein Festkörperplattenlaufwerk (SSDD) und/oder einen elektrisch löschbaren Hochgeschwindigkeitsspeicher (allgemein als „Flashspeicher“ bezeichnet) implementiert sein. Andere Vorrichtungen, die für die Speicherung 2758 verwendet werden können, beinhalten Flashspeicherkarten, wie etwa SD-Karten, microSD-Karten, eXtreme-Digital(XD)-Bildkarten und dergleichen und USB-Flash-Laufwerke. Bei einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder solche enthalten, die Chalkogenglas, NAND-Flashspeicher mit mehreren Schwellenpegeln, NOR-Flashspeicher, Phasenwechselspeicher (PCM) mit einem oder mehreren Pegeln, einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistorspeicher mit Direktzugriff (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Speicher mit Direktzugriff (MRAM), der Memristortechnologie einbindet, Phasenwechsel-RAM (PRAM), resistiven Speicher einschließlich Metalloxidbasis, Sauerstoffleerstellenbasis und Leiterbrückenarbeitsspeicher mit Direktzugriff (CB-RAM) oder Spin-Transfer-Torque(STT)-MRAM, eine Vorrichtung auf Spintronik-Magnetübergang-Speicherbasis, eine Vorrichtung auf Magnettunnelübergangsbasis (MTJ-Basis), eine Vorrichtung auf Domänenwand(DW)- und Spin-Orbit-Transfer(SOT)-Basis, eine Speichervorrichtung auf Thyristorbasis oder eine Kombination von beliebigen der obigen oder einen anderen Speicher einsetzen. Die Speicherschaltungsanordnung 2754 und/oder die Speicherungsschaltungsanordnung 2758 können auch dreidimensionale (3D) Crosspoint(XPOINT)-Speicher von Intel® und Micron® beinhalten.
Bei Niedrigleistungsimplementierungen kann die Speicherung 2758 ein chipinterner Speicher oder Register sein, die mit dem Prozessor 2752 assoziiert sind. In manchen Beispielen kann die Speicherung 2758 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 2758 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandsänderungsspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher.
Die Komponenten der Edge-Rechenvorrichtung 2750 können über eine Zwischenverbindung (IX) 2756 kommunizieren. Die IX 2756 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich ISA, erweiterte ISA, I2C, SPI, Punkt-zu-Punkt-Schnittstellen, Leistungsverwaltungsbus (PMBus), PCI, PCIe, PCIx, Intel® UPI, Intel® Accelerator Link, Intel® CXL, CAPI, OpenCAPI, Intel® QPI, UPI, Intel ® OPA IX, RapidIO™-System-IXs, CCIX, Gen-Z-Consortium-IXs, eine HyperTransport-Zwischenverbidnung, NVLink, das von NVIDIA® bereitgestellt wird, ein Time-Triggered-Protocol(TTP)-System, ein FlexRay-System, PROFIBUS und/oder eine beliebige Anzahl anderer IX-Technologien. Die IX 2756 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
Die IX 2756 koppelt den Prozessor 2752 mit einer Kommunikationsschaltungsanordnung 2766 zur Kommunikation mit anderen Vorrichtungen, wie etwa einem entfernten Server (nicht gezeigt) und/oder den angebundenen Edge-Vorrichtungen 2762. Die Kommunikationsschaltungsanordnung 2766 ist ein Hardwareelement oder eine Sammlung von Hardwareelementen, das/die zum Kommunizieren über ein oder mehrere Netzwerke (z. B. die Cloud 2763) und/oder mit anderen Vorrichtungen (z. B. den Edge-Vorrichtungen 2762) verwendet wird/werden. Die Sammlung von Hardwareelementen beinhaltet Hardwarevorrichtungen, wie etwa Basisbandschaltungsanordnung 276x, Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu erleichtern).
Der Sendeempfänger 2766 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa unter anderem Übertragungen auf 2,4 Gigahertz (GHz) unter dem IEEE 802.15.4-Standard unter Verwendung des Bluetooth®-Niederenergie(BLE)-Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen mit den verbundenen Edge-Vorrichtungen 2762 verwendet werden. Zum Beispiel kann eine Drahtlos-Lokalnetz(WLAN)-Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronic Engineers (IEEE) zu implementieren. Außerdem können Funkfernnetzkommunikationen, z. B. in Übereinstimmung mit einem Mobilfunk- oder anderen Funkfernnetzprotokoll über eine Funkfernnetz(WWAN)-Einheit stattfinden.
Die Kommunikationsschaltungsanordnung 2766 (oder mehrere Sendeempfänger 2766) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Zum Beispiel kann die Kommunikationsschaltungsanordnung 2766 eine Kurzstrecken-RAT-Schaltungsanordnung 276y zum Kommunizieren mit relativ nahen Vorrichtungen (z. B. innerhalb von etwa 10 Metern) basierend auf BLE oder einem anderen Niedrigleistungsfunkgerät beinhalten, um Leistung zu sparen. Entferntere verbundene Edge-Vorrichtungen 2762 (z. B. innerhalb von etwa 50 Metern) können über eine ZigBee®-Schaltungsanordnung 276y und/oder andere Funkgeräte mit mittlerer Leistung 276y erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät 276y mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Sendeempfänger 276y stattfinden, zum Beispiel einen lokalen Sendeempfänger 276y, der BLE verwendet, und einen separaten vermaschten Sendeempfänger 276y, der ZigBee® verwendet.
Ein Drahtlosnetzwerk-Sendeempfänger 276z kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 2763 über lokale oder Fernnetzprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 276z kann unter anderem ein LPWA-Sendeempfänger sein, der den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Rechenknoten 2750 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa Zeitschlitz-Kanalspringen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerk-Sendeempfänger 276z erwähnten Systemen verwendet werden, wie hierin beschrieben. Der Sendeempfänger 276z kann zum Beispiel einen Mobilfunk-Sendeempfänger beinhalten, der Frequenzspreiz(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Sendeempfänger 276z kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen kompatibel sind, wie etwa LTE- und 5G/NR-Kommunikationssystemen, die am Ende der vorliegenden Offenbarung ausführlicher besprochen werden.
Eine Netzwerkschnittstellensteuerung (NIC) 2768 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 2763 oder zu anderen Vorrichtungen bereitzustellen, wie etwa den angebundenen Edge-Vorrichtungen 2762 (die z. B. in einem vermaschten Netz arbeiten). Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+ oder PROFINET unter vielen anderen. Eine zusätzliche NIC 2768 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 2768 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 2768 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine beliebige oder mehrere beliebige der Komponenten 2764, 2766, 2768 oder 2770 beinhalten oder durch diese ausgebildet sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Übertragen usw.) durch eine derartige Kommunikationsschaltungsanordnung ausgebildet sein.
Der Edge-Rechenknoten 2750 kann eine Beschleunigungsschaltungsanordnung 2764 beinhalten oder an eine solche gekoppelt sein, die durch einen oder mehrere KI-Beschleuniger, einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, einen oder mehrere SoCs (einschließlich programmierbarer SoCs), eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs (einschließlich programmierbarer ASICs), PLDs wie CPLDs oder HCPLDs und/oder andere Formen spezialisierter Prozessoren oder Schaltungsanordnungen ausgebildet sein kann, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterkennung, Regelanalyse oder dergleichen beinhalten. Bei FPGA-basierten Implementierungen kann die Beschleunigungsschaltungsanordnung 2764 Logikblöcke oder Logik-Fabric und andere miteinander verbundene Ressourcen umfassen, die programmiert (konfiguriert) werden können, um verschiedene Funktionen durchzuführen, wie etwa die hierin besprochenen Prozeduren, Verfahren, Funktionen usw. In derartigen Implementierungen kann die Beschleunigungsschaltungsanordnung 2764 auch Speicherzellen (z. B. EPROM, EEPROM, Flashspeicher, statischen Speicher (z. B. SRAM, Anti-Fuses usw.) beinhalten, die zum Speichern von Logikblöcken, Logik-Fabric, Daten usw. in LUTs und dergleichen verwendet werden.
Die IX 2756 koppelt auch den Prozessor 2752 an einen Sensor-Hub oder eine externe Schnittstelle 2770, der bzw. die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die zusätzlichen/externen Vorrichtungen können Sensoren 2772, Aktuatoren 2774 und eine Positionierungsschaltungsanordnung 2775 beinhalten.
Die Sensorschaltungsanordnung 2772 beinhaltet Vorrichtungen, Module oder Subsysteme, deren Zweck darin besteht, Ereignisse oder Änderungen in ihrer Umgebung zu detektieren und die Informationen (Sensordaten) über die detektierten Ereignisse an irgendeine andere Vorrichtung, irgendein anderes Modul, irgendein anderes Subsystem usw. zu senden. Beispiele für derartige Sensoren 2772 beinhalten unter anderem Trägheitsmesseinheiten (IMU), die Beschleunigungsmesser, Gyroskope und/oder Magnetometer umfassen; mikroelektromechanische Systeme (MEMS) oder nanoelektromechanische Systeme (NEMS), die 3-Achsen-Beschleunigungsmesser, 3-Achsen-Gyroskope und/oder Magnetometer umfassen; Füllstandssensoren; Durchflusssensoren; Temperatursensoren (z. B. Thermistoren); Drucksensoren; Barometerdrucksensoren; Gravimeter; Höhenmesser; Bilderfassungsvorrichtungen (z. B. Kameras); Lichtdetektions- und Entfernungsmesssensoren (LiDAR); Näherungssensoren (z. B. Infrarotstrahlungsdetektor und dergleichen); Tiefensensoren, Umgebungslichtsensoren; optische Lichtsensoren; Ultraschallsendeempfänger; Mikrofone; und dergleichen.
Die Aktuatoren 2774 ermöglichen es der Plattform 2750, ihren Zustand, ihre Position und/oder ihre Orientierung zu ändern oder einen Mechanismus oder ein System zu bewegen oder zu steuern. Die Aktuatoren 2774 umfassen elektrische und/oder mechanische Vorrichtungen zum Bewegen oder Steuern eines Mechanismus oder Systems und wandeln Energie (z. B. elektrischen Strom oder sich bewegende Luft und/oder Flüssigkeit) in irgendeine Art von Bewegung um. Die Aktuatoren 2774 können eine oder mehrere elektronische (oder elektrochemische) Vorrichtungen beinhalten, wie etwa piezoelektrische Biomorphe, Festkörperaktuatoren, Festkörperrelais (SSRs), Aktuatoren auf Basis einer Formgedächtnislegierung, Aktuatoren auf Basis eines elektroaktiven Polymers, integrierte Relaistreiberschaltungen (Relaistreiber-ICs) und/oder dergleichen. Die Aktuatoren 2774 können eine oder mehrere elektromechanische Vorrichtungen beinhalten, wie etwa pneumatische Aktuatoren, hydraulische Aktuatoren, elektromechanische Schalter einschließlich elektromechanischer Relais (EMRs), Motoren (z. B. Gleichstrommotoren, Schrittmotoren, Servomechanismen usw.), Leistungsschalter, Ventilaktuatoren, Räder, Triebwerke, Propeller, Klauen, Klemmen, Haken, Hörschallgeneratoren, visuelle Warnvorrichtungen und/oder andere ähnliche elektromechanische Komponenten. Die Plattform 2750 kann dazu ausgelegt sein, einen oder mehrere Aktuatoren 2774 basierend auf einem oder mehreren erfassten Ereignissen und/oder Anweisungen oder Steuersignalen, die von einem Dienstanbieter und/oder verschiedenen Clientsystemen empfangen werden, zu betreiben.
Die Positionierungsschaltungsanordnung 2775 beinhaltet eine Schaltungsanordnung zum Empfangen und Decodieren von Signalen, die durch ein Positionierungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/rundgesendet werden. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) beinhalten das globale Positionierungssystem (GPS) der Vereinigten Staaten, das globale Navigationssystem (GLONASS) von Russland, das Galileo-System der Europäischen Union, das Navigationssatellitensystem BeiDou von China, ein regionales Navigationssystem oder GNSS-Erweiterungssystem (z. B. Navigation with Indian Constellation (NAVIC), Quasi-Zenit-Satelliten-System (QZSS) von Japan, Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) usw.) oder dergleichen. Die Positionierungsschaltungsanordnung 2775 umfasst verschiedene Hardwareelemente (z. B. einschließlich Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen), um mit Komponenten eines Positionierungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. Zusätzlich oder alternativ dazu kann die Positionierungsschaltungsanordnung 2775 eine Mikrotechnologie zur Positionierung, Navigation und Timing (Micro-PNT) -IC beinhalten, die einen Master-Timing-Taktgeber verwendet, um eine Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen. Die Positionierungsschaltungsanordnung 2775 kann auch Teil der Kommunikationsschaltungsanordnung 2766 sein oder mit dieser interagieren, um mit den Knoten und Komponenten des Positionierungsnetzwerks zu kommunizieren. Die Positionierungsschaltungsanordnung 2775 kann auch Positionsdaten und/oder Zeitdaten an die Anwendungsschaltungsanordnung liefern, die die Daten verwenden kann, um Operationen mit verschiedenen Infrastrukturen (z. B. Funkbasisstationen) zur Navigation mit Routenführung oder dergleichen zu synchronisieren. Wenn kein GNSS-Signal verfügbar ist oder wenn die GNSS-Positionsgenauigkeit für eine bestimmte Anwendung oder einen bestimmten Dienst nicht ausreicht, kann eine Positionierungserweiterungstechnologie verwendet werden, um erweiterte Positionierungsinformationen und -daten an die Anwendung oder den Dienst bereitzustellen. Eine derartige Positionierungserweiterungstechnologie kann zum Beispiel satellitenbasierte Positionierungserweiterung (z. B. EGNOS) und/oder bodenbasierte Positionierungserweiterung (z. B. DGPS) beinhalten. In einigen Implementierungen ist oder beinhaltet die Positionierungsschaltungsanordnung 2775 ein INS, das ein System oder eine Vorrichtung ist, das/die eine Sensorschaltungsanordnung 2772 (zum Beispiel Bewegungssensoren, wie etwa Beschleunigungsmesser, Rotationssensoren, wie etwa Gyroskope, und Höhenmesser, Magnetsensoren, und/oder dergleichen) verwendet, um kontinuierlich (zum Beispiel unter Verwenden von Dead-by-Dead-Reckoning, Triangulation oder dergleichen) eine Position, Orientierung und/oder Geschwindigkeit (einschließlich Richtung und Geschwindigkeit der Bewegung) der Plattform 2750 ohne die Notwendigkeit externer Referenzen zu berechnen.
In einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb des Edge-Rechenknotens 2750 vorhanden oder mit diesem verbunden sein, die in 27 als Eingabeschaltungsanordnung 2786 und Ausgabeschaltungsanordnung 2784 bezeichnet werden. Die Eingabeschaltungsanordnung 2786 und die Ausgabeschaltungsanordnung 2784 beinhalten eine oder mehrere Benutzerschnittstellen, die dazu ausgelegt sind, eine Benutzerinteraktion mit der Plattform 2750 zu ermöglichen, und/oder Peripheriekomponentenschnittstellen, die dazu ausgelegt sind, eine Peripheriekomponenteninteraktion mit der Plattform 2750 zu ermöglichen. Die Eingabeschaltungsanordnung 2786 kann ein beliebiges physisches oder virtuelles Mittel zum Annehmen einer Eingabe beinhalten, darunter unter anderem eine oder mehrere physische oder virtuelle Tasten (zum Beispiel eine Rücksetztaste), eine physische Tastatur, ein Tastenfeld, eine Maus, ein Touchpad, einen Berührungsbildschirm, Mikrofone, einen Scanner, ein Headset und/oder dergleichen. Die Ausgabeschaltungsanordnung 2784 kann enthalten sein, um Informationen zu zeigen oder anderweitig Informationen zu übermitteln, wie etwa Sensormesswerte, eine oder mehrere Aktuatorpositionen oder andere ähnliche Informationen. Daten und/oder Grafiken können auf einer oder mehreren Benutzeroberflächenkomponenten der Ausgabeschaltungsanordnung 2784 angezeigt werden. Eine Ausgabeschaltungsanordnung 2784 kann eine beliebige Anzahl und&oder Kombinationen einer Audio- oder visuellen Anzeige beinhalten, einschließlich unter anderem eine oder mehrere einfache visuelle Ausgaben/Indikatoren (z. B. binäre Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visuelle Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigevorrichtungen oder Berührungsbildschirme (z. B. Flüssigkristallanzeige(LCD)-Bildschirme, LED-Anzeigen, Quantenpunktanzeigen, Projektoren usw.), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb der Plattform 2750 generiert oder erzeugt wird. Die Ausgabeschaltungsanordnung 2784 kann auch Lautsprecher oder andere audioemittierende Vorrichtungen, einen oder mehrere Drucker und/oder dergleichen beinhalten. Zusätzlich oder alternativ dazu kann die Sensorschaltungsanordnung 2772 als die Eingabeschaltungsanordnung 2784 (z. B. eine Bilderfassungsvorrichtung, Bewegungserfassungsvorrichtung oder dergleichen) verwendet werden, und ein oder mehrere Aktuatoren 2774 können als die Ausgabevorrichtungsschaltungsanordnung 2784 (z. B. ein Aktuator zum Bereitstellen einer haptischen Rückmeldung oder dergleichen) verwendet werden. Bei einem anderen Beispiel kann eine Nahfeldkommunikations(NFC)-Schaltungsanordnung, die eine NFC-Steuerung umfasst, die mit einem Antennenelement und einer Verarbeitungsvorrichtung gekoppelt ist, enthalten sein, um elektronische Tags zu lesen und/oder an eine andere NFC-fähige Vorrichtung anzubinden. Peripheriekomponentenschnittstellen können unter anderem einen nichtflüchtigen Speicheranschluss, einen USB-Anschluss, eine Audiobuchse, eine Stromversorgungsschnittstelle usw. enthalten. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Rechensystems zu empfangen; Komponenten oder Dienste eines Edge-Rechensystems zu verwalten; einen Zustand einer Edge-Rechenkomponente oder eines Edge-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstanwendungsfällen durchzuführen.
Eine Batterie 2776 kann den Edge-Rechenknoten 2750 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Rechenknoten 2750 an einem festen Standort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Ausfallsicherheit oder für temporäre Funktionen verwendet werden kann. Die Batterie 2776 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie (z. B. eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie usw.), ein oder mehrere Kondensatoren und dergleichen sein.
Eine Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 kann im Edge-Rechenknoten 2750 enthalten sein, um den Ladezustand (SoCh) der Batterie 2776, falls enthalten, zu verfolgen. Die Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 kann verwendet werden, um andere Parameter der Batterie 2776 zu überwachen, um Ausfallvorhersagen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 2776 bereitzustellen. Die Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor in Phoenix, Arizona, oder einen IC der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Die Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 kann die Informationen über die Batterie 2776 über die IX 2756 an den Prozessor 2752 kommunizieren. Die Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 kann auch einen Analog-digitalWandler (ADC) beinhalten, der es dem Prozessor 2752 ermöglicht, die Spannung der Batterie 2776 oder den Stromfluss von der Batterie 2776 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu ermitteln, die der Edge-Rechenknoten 2750 durchführen kann, wie etwa Übertragungsfrequenz, vermaschten Netzbetrieb, Abtastfrequenz und dergleichen. In einigen Implementierungen können die Batterie 2776 und/oder die Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 in Abhängigkeit von dem Verwendungsfall/der Implementierung in unterschiedliche Leistungsdomänen unterteilt sein, wobei unterschiedliche Batterien 2776 für unterschiedliche Leistungsdomänen verwendet werden und jede Leistungsdomäne unterschiedliche Komponenten/Vorrichtungen des Edge-Rechenknotens 2750 mit Leistung versorgen kann.
Ein Leistungsblock 2780 oder eine andere Leistungsversorgung, die an ein Netz gekoppelt ist, kann an die Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 gekoppelt sein, um die Batterie 2776 zu laden. In einigen Beispielen kann der Leistungsblock 2780 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel über eine Schleifenantenne im Edge-Rechenknoten 2750 zu beziehen. Eine drahtlose Batterieladeschaltung, wie etwa unter anderem ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in der Batterieüberwachungsvorrichtung/Ladevorrichtung 2778 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 2776 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Standards Airfuel, des vom Wireless Power Consortium veröffentlichten Drahtlosladestandards Qi oder des von der Alliance for Wireless Power veröffentlichten Ladestandards Rezence durchgeführt werden.
Die Speicherung 2758 kann Anweisungen 2782 in der Form von Software, Firmware oder Hardwarebefehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl derartige Anweisungen 2782 als Codeblöcke gezeigt sind, die in dem Speicher 2754 und der Speicherung 2758 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC) eingebaut sind.
Bei einem Beispiel können die Anweisungen 2782, die über den Speicher 2754, die Speicherung 2758 oder den Prozessor 2752 bereitgestellt werden, als ein nicht transitorisches maschinenlesbares Medium 2760 ausgebildet sein, das Code beinhaltet, um den Prozessor 2752 anzuweisen, elektronische Operationen im Edge-Rechenknoten 2750 durchzuführen. Der Prozessor 2752 kann über die IX 2756 auf das nicht transitorische maschinenlesbare Medium 2760 zugreifen. Beispielsweise kann das nicht transitorische maschinenlesbare Medium 2760 durch Vorrichtungen ausgebildet sein, die für die Speicherung 2758 beschrieben sind, oder kann spezifische Speicherungseinheiten beinhalten, wie etwa Speicherungsvorrichtungen und/oder Speicherungsplatten, die optische Platten (z. B. Digital Versatile Disk (DVD), Compact Disk (CD), CD-ROM, Blu-ray-Disk), Flash-Laufwerke, Disketten, Festplatten (z. B. SSDs) oder eine beliebige Anzahl anderer Hardwarevorrichtungen, in denen Informationen für eine beliebige Dauer (z. B. für längere Zeiträume, permanent, für kurze Instanzen, zum temporären Puffern und/oder Zwischenspeichern) gespeichert sind. Das nicht transitorische, maschinenlesbare Medium 2760 kann Anweisungen beinhalten, um den Prozessor 2752 anzuweisen, eine spezifische Sequenz oder einen spezifischen Ablauf von Handlungen durchzuführen, wie zum Beispiel in Bezug auf das eine oder die mehreren oben gezeigten Ablaufdiagramme und Blockdiagramme von Operationen und Funktionalität beschrieben. Die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ sind austauschbar. Der Begriff „nicht transitorisches computerlesbares Medium“ ist ausdrücklich definiert, alle Typen von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu enthalten und sich ausbreitende Signale auszuschließen und Sendemedien auszuschließen.
In weiteren Beispielen beinhaltet ein maschinenlesbares Medium ein beliebiges greifbares Medium, das fähig ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu codieren oder auszuführen, und die bewirken, dass die Maschine eine oder mehrere der Methodiken der vorliegenden Offenbarung durchzuführen, oder das fähig ist, von solchen Anweisungen genutzte oder mit diesen verbundene Datenstrukturen zu speichern, zu codieren oder zu tragen. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Spezifische Beispiele maschinenlesbarer Medien beinhalten nichtflüchtigen Speicher, einschließlich unter anderem beispielsweise von Halbleiter-Speichervorrichtungen (z. B. elektrisch programmierbarer schreibgeschützter Speicher (EPROM), elektrisch löschbarer programmierbarer schreibgeschützter Speicher (EEPROM)) und Flashspeichervorrichtungen; Magnetplatten, wie z. B. interne Festplatten und Wechselplatten; magneto-optischen Platten; und CD-ROM- und DVD-ROM-Platten. Die Anweisungen, die durch ein maschinenlesbares Medium ausgebildet sind, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z. B. HTTP) nutzt.
Ein maschinenlesbares Medium kann durch eine Speicherungsvorrichtung oder eine andere Einrichtung bereitgestellt werden, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Bei einem Beispiel können Informationen, die auf einem maschinenlesbaren Medium gespeichert oder anderweitig bereitgestellt sind, Anweisungen repräsentieren, 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), verpackte Anweisungen (z. B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die Informationen, die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können durch eine Verarbeitungsschaltungsanordnung zu den Anweisungen verarbeitet werden, um beliebige der hierin besprochenen Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z. B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes beinhalten: Kompilieren (z. B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statisches Linken), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
Bei einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z. B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus irgendeinem Zwischenformat oder irgendeinem vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarem Binär-Code usw.) auf einem oder mehreren entfernten Servern befinden. Die Quellcodepakete können verschlüsselt werden, wenn sie sich über ein Netzwerk bewegen, und entschlüsselt, entkomprimiert, bei Bedarf zusammengesetzt (z. B. gelinkt) und an einer lokalen Maschine kompiliert oder interpretiert (z. B. in eine Bibliothek, eigenständige ausführbare Datei usw.) und von der lokalen Maschine ausgeführt werden.
Die Veranschaulichungen der 26 und 27 sollen eine Ansicht auf hoher Ebene von Komponenten einer variierenden Vorrichtung, eines variierenden Subsystems oder einer variierenden Anordnung eines Edge-Rechenknotens darstellen. Es wird jedoch klar sein, 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 stattfinden kann. Ferner sind diese Anordnungen in einer Vielzahl von Anwendungsfällen und Umgebungen verwendbar, einschließlich jener, die unten erörtert werden (z. B. ein mobiles UE beim industriellen Rechnen für Smart Cities oder intelligente Fabriken, unter vielen anderen Beispielen).
Die jeweiligen Rechenplattformen der 26 und 27 können mehrere Edge-Instanzen (z. B. Edge-Cluster) durch Verwenden von Mandanten-Containern unterstützen, die auf einer einzigen Rechenplattform ausgeführt werden. Gleichermaßen können mehrere Edge-Knoten als Unterknoten existieren, die auf Mandanten innerhalb derselben Rechenplattform ausgeführt werden. Dementsprechend kann basierend auf verfügbarer Ressourcenpartitionierung ein einzelnes System oder eine einzelne Rechenplattform in mehrere unterstützende Mandanten- und Edge-Knoteninstanzen partitioniert oder unterteilt werden, von denen jede mehrere Dienste und Funktionen unterstützen kann - selbst während sie potenziell in mehreren Rechenplattforminstanzen durch mehrere Besitzer betrieben oder gesteuert wird. Diese verschiedenen Arten von Partitionen können komplexe Multi-Mandanten und viele Kombinationen von Multi-Stakeholdern durch die Verwendung eines LSM oder einer anderen Implementierung einer Isolations-/Sicherheitsrichtlinie unterstützen. Hinweise auf die Verwendung eines LSM und Sicherheitsmerkmale, die derartige Sicherheitsmerkmale verstärken oder implementieren, werden daher in den folgenden Abschnitten angemerkt. Gleichermaßen können Dienste und Funktionen, die diese verschiedene Typen von Multi-Entitätspartitionen bearbeiten, lastausgeglichen, migriert und orchestriert werden, um notwendige Dienstziele und -operationen zu erreichen.
26 und 27 stellen Beispiele für Edge-Rechensysteme und Umgebungen dar, die beliebige der hierin besprochenen Rechenknoten oder Vorrichtungen erfüllen können. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, das bzw. der in der Lage ist, mit anderen Edge-, Netzwerk- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System ausgebildet sein, die bzw. das in der Lage ist, die beschriebenen Funktionen durchzuführen.
6. IMPLEMENTIERUNGSBEISPIELE
Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht einschränkenden Implementierungen. Jedes der folgenden nicht einschränkenden Beispiele kann alleine stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen unten oder in der gesamten vorliegenden Offenbarung bereitgestellten Beispiele kombiniert werden.
Beispiel A01 beinhaltet ein Verfahren zum Bereitstellen von Verkehrsverwaltungsstrategien auf Grundlage von bestärkendem Lernen, wobei das Verfahren umfasst: Sammeln von Beobachtungsdaten von einer oder mehreren Datenquellen innerhalb einer Umgebung; Ermitteln eines Zustands der Umgebung auf Grundlage der gesammelten Beobachtungsdaten; und Betreiben eines Modells für bestärkendes Lernen (RLM) zum Ermitteln einer oder mehrerer Handlungen auf Grundlage des ermittelten Zustands, wobei die ermittelten einen oder mehreren Handlungen jeweilige Verkehrsverwaltungsstrategien für entsprechende Mehrfachzugriffs-UEs beinhalten und die eine oder die mehreren Handlungen bewirken sollen, dass die entsprechenden Mehrfachzugriffs-UEs eine oder mehrere Operationen in Übereinstimmung mit den jeweiligen Verkehrsverwaltungsstrategien durchführen.
Beispiel A02 beinhaltet das Verfahren des Beispiels A01 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei jede der jeweiligen Verkehrsverwaltungsstrategien eine Verkehrslenkungsstrategie und/oder eine Verkehrsaufteilungsstrategie beinhaltet.
Beispiel A03 beinhaltet das Verfahren des Beispiels A01 oder A02 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei das eine oder die mehreren UEs konfigurierte Agenten sind, die mit der Umgebung interagieren, um Beobachtungsdaten zu sammeln, und das Betreiben des RLM zur Ermittlung der einen oder der mehreren Aktionen umfasst: Erhalten von Aktionsdaten mit den Beobachtungsdaten, wobei die Aktionsdaten eine oder mehrere andere von den entsprechenden Mehrfachzugriffs-UEs vorgenommene Aktionen beinhalten; Trainieren des RLM auf Grundlage der Beobachtungsdaten und der Aktionsdaten; und Bereitstellen des RLM an die entsprechenden Mehrfachzugriffs-UEs, wobei das bereitgestellte RLM zur Ableitung der Aktionen durch die entsprechenden Mehrfachzugriffs-UEs dient.
Beispiel A04 beinhaltet das Verfahren des Beispiels A03 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei die entsprechenden Mehrfachzugriffs-UEs das bereitgestellte RLM verwenden, um die jeweiligen Verkehrsverwaltungsstrategien gemäß ihren individuell gesammelten Beobachtungen aus Interaktionen mit der Umgebung unabhängig vorherzusagen.
Beispiel A05 beinhaltet das Verfahren der Beispiele A03-A04 und/oder eines anderen oder einiger anderer Beispiele hierin, ferner umfassend: Berechnen eines Belohnungswerts basierend auf den gesammelten Beobachtungsdaten; Aktualisieren des RLM basierend auf dem berechneten Belohnungswert; und Verteilen des aktualisierten RLM an die entsprechenden Mehrfachzugriffs-UEs.
Beispiel A06 beinhaltet das Verfahren des Beispiels A05 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei das Verteilen des aktualisierten RLM ferner Folgendes umfasst: Verteilen des aktualisierten RLM an die entsprechenden Mehrfachzugriffs-UEs, wenn das aktualisierte RLM einen Verifizierungsprozess besteht.
Beispiel A07 beinhaltet das Verfahren des Beispiels A01 oder A02 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei das Betreiben des RLM zur Ermittlung der einen oder der mehreren Aktionen umfasst: Betreiben eines Repräsentationsnetzes, um basierend auf den gesammelten Beobachtungsdaten eine Repräsentation der Umgebung zu generieren; Betreiben eines Kritiknetzes, um eine Rückmeldung für die eine oder die mehreren Aktionen zu ermitteln; und Betreiben eines Aktornetzes, um die eine oder die mehreren Aktionen basierend auf der erzeugten Repräsentation und der Rückmeldung vom Kritiknetz zu ermitteln.
Beispiel A08 beinhaltet das Verfahren des Beispiels A07 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei die Rückmeldung ein Zustandswert der einen oder der mehreren Aktionen von einer Zustandswertfunktion, ein Qualitätswert (Q-Wert) der einen oder der mehreren Aktionen von einer Q-Wertfunktion ist.
Beispiel A09 beinhaltet das Verfahren des Beispiels A07 oder A08 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei die Rückmeldung eine Wahrscheinlichkeitsverteilung der einen oder mehreren Aktionen mit einer erwarteten Rückgabe vom ermittelten Zustand umfasst.
Beispiel A10 beinhaltet das Verfahren der Beispiele A01-A09 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei das Repräsentationsnetz ein rekurrentes neuronales Netz (RNN) umfasst und das Betreiben des Repräsentationsnetzes umfasst: Betreiben des RNN zum Lernen der Repräsentation für die entsprechenden Mehrfachzugriffs-UEs basierend auf Eingaben mit variablen Größen.
Beispiel A11 beinhaltet das Verfahren eines der Beispiele A07-A10 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei das Kritiknetz ein RNN umfasst, das ausgelegt ist, eine Messsequenzkorrelation zur Ermittlung der Rückmeldung zu lernen.
Beispiel A12 beinhaltet das Verfahren eines der Beispiele A07-A11 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei das Aktornetz ein RNN umfasst, das ausgelegt ist, eine Messsequenzkorrelation zur Ermittlung der einen oder mehreren Aktionen zu lernen.
Beispiel A13 beinhaltet das Verfahren nach einem der Beispiele A10-A12 und/oder einem oder mehreren anderen Beispielen hierin, wobei das RNN ein Long-Short-Term-Memory(LSTM)-Netz ist.
Beispiel A14 beinhaltet das Verfahren von Beispiel A01 und/oder eines anderen oder einiger anderer Beispiele hierin, ferner umfassend: Kommunizieren der einen oder der mehreren Aktionen an die entsprechenden Mehrfachzugriffs-UEs.
Beispiel A15 beinhaltet das Verfahren der Beispiele A01-A14 und/oder eines anderen oder einiger anderer Beispiele hierin, ferner umfassend: Auslösen der einen oder der mehreren Datenquellen innerhalb der Umgebung, um die Beobachtungsdaten bereitzustellen, wenn eine Auslösebedingung erfüllt ist.
Beispiel A16 beinhaltet das Verfahren des Beispiels A15 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei die Auslösebedingung ein Ablaufen eines Zeitgebers und/oder ein Erreichen eines Schwellenwerts durch einen Messwert beinhaltet.
Beispiel A17 beinhaltet das Verfahren des Beispiels A15 oder A16 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei die eine oder die mehreren Datenquellen ein oder mehrere Mehrfachzugriffs-UEs und/oder einen oder mehrere Netzwerkzugangsknoten (NANs) beinhalten.
Beispiel A18 beinhaltet das Verfahren der Beispiele A01-A17 und/oder eines anderen oder einiger anderer Beispiele hierin, ferner umfassend: Betreiben des RLM, zum Lernen der jeweiligen Verkehrsverwaltungsstrategien, ohne auf Optimierungsmodelle oder vordefinierte Richtlinien angewiesen zu sein.
Beispiel A19 beinhaltet das Verfahren der Beispiele A05-A18 und/oder eines anderen oder einiger anderer Beispiele hierin, ferner umfassend: Berechnen des Belohnungswerts unter Verwendung einer Belohnungsfunktion basierend auf den gesammelten Beobachtungsdaten.
Beispiel A20 beinhaltet das Verfahren des Beispiels A19 und/oder eines anderen oder einiger anderer Beispiele hierin, wobei die Belohnungsfunktion eine Hilfsfunktion eines Netzwerk-Dienstqualitätsziels (QoS-Ziels) ist.
Beispiel A21 beinhaltet das Verfahren von Beispiel A20 und/oder einem oder einigen anderen Beispielen hierin, wobei Eingaben in die Hilfsfunktion einen oder mehrere QoS-Parameter beinhalten, wobei der eine oder die mehreren QoS-Parameter eines oder mehrere von Paketverzögerung, Paketverlustrate, Paketverwerfungsrate, physische (PHY) Rate; Goodput; UE-Durchsatz, Zellendurchsatz, Jitter, Alpha-Fairness, Kanalqualitätsindikator(CQI)-bezogene Messwerte, Modulationscodierungsschema(MCS)-bezogene Messwerte, physische Ressourcenblock(PRB)-Nutzung, Funknutzungspegel pro NAN und Datenvolumen beinhalten.
Beispiel B01 beinhaltet das Verfahren der Beispiele A01-A21 und/oder einem oder einigen anderen Beispielen hierin, wobei das RLM ein RL-Agent ist und der RL-Agent einen oder mehrere Leistungsfähigkeitszusicherungsmechanismen umfasst.
Beispiel B02 beinhaltet das Verfahren von Beispiel B01 und/oder einem oder einigen anderen Beispielen hierin, wobei der eine oder die mehreren Leistungsfähigkeitszusicherungsmechanismen einen Mechanismus für gelenkte Erkundung, einen Mechanismus zum Erzwingen eines sicheren Aktionsraums, einen Frühwarnmechanismus und einen opportunistischen Erkundungssteuerungs(OEC)-Mechanismus beinhalten.
Beispiel B03 beinhaltet das Verfahren von Beispiel B02 und/oder einem oder einigen anderen Beispielen hierin, wobei der Mechanismus für gelenkte Erkundung einen oder mehrere regelbasierte Algorithmen, einen oder mehrere modellbasierte heuristische Algorithmen oder einen oder mehrere vortrainierte Algorithmen für maschinelles Lernen beinhaltet.
Beispiel B04 beinhaltet das Verfahren der Beispiele B02-B03 und/oder von einem oder einigen anderen Beispielen hierin, wobei der ESAS-Mechanismus einen akzeptablen Aktionsbereich oder einen Satz von Einschränkungen umfasst, die durch eine oder mehrere lineare oder nichtlineare Funktionen der einen oder der mehreren Aktionen beschrieben werden.
Beispiel B05 beinhaltet das Verfahren der Beispiele B02-B04 und/oder von einem oder einigen anderen Beispielen hierin, ferner umfassend: Betreiben des Frühwarnmechanismus, um eine Implementierung eines Reservemodells auszulösen, wenn eine oder mehrere Leistungsfähigkeitsmetriken einen entsprechenden Schwellenwert erfüllen oder überschreiten.
B06 beinhaltet das Verfahren der Beispiele B02-B04 und/oder von einem oder einigen anderen Beispielen hierin, wobei die eine oder die mehreren Leistungsfähigkeitsmetriken einen Mittelwert einer Einwegeverzögerung für einen oder mehrere Datenflüsse, einen Mittelwert der durchgehenden (e2e)-Verzögerung für einen oder mehrere Datenflüsse, einen Verzögerungsschwankungstrend, eine Pufferakkumulation; einen Kanalqualitätsindikator(CQI)-Schwankungstrend; und eine Modulation und einen Codierungsschema(MCS)-Verteilungstrend beinhalten.
Beispiel B06 beinhaltet das Verfahren der Beispiele B01-B05 und/oder und/oder von einem oder einigen anderen Beispielen hierin, ferner umfassend: Betreiben des OEC-Mechanismus, um eine oder mehrere risikoreiche Aktionen der einen oder der mehreren Aktionen zu identifizieren, und Anwenden der einen oder der mehreren risikoreichen Aktionen, um Flüsse oder Flüsse mit weniger strengen QoS-Zielen als andere Flüsse zu testen.
Beispiel C01 beinhaltet das Verfahren nach einem der Beispiele A07-A21 und/oder einem oder mehreren anderen Beispielen hierin, wobei das RLM ein Maschinenlernmodell mit kontextbezogenen Banditen ist.
Beispiel C02 beinhaltet das Verfahren von Beispiel C01 und/oder einem oder einigen anderen Beispielen hierin, ferner umfassend: des Kritiknetzes, des Aktornetzes und des Repräsentationsnetzes mit Parametern θ^Q, θ^µ bzw. θ^E; Initialisieren eines Wiedergabepuffers; und Initialisieren eines Zufallsprozesses zur Aktionserkundung.
Beispiel C03 beinhaltet das Verfahren von Beispiel C02 und/oder einem oder einigen anderen Beispielen hierin, ferner umfassend: Betreiben des Repräsentationsnetzes, um eine Repräsentation der Beobachtungsdaten für ein Ziel-UE zu erhalten, dem eine Aktionsempfehlung bereitgestellt werden soll, wobei das Ziel-UE zu den entsprechenden Mehrfachzugriffs-UEs gehört.
Beispiel C04 beinhaltet das Verfahren von Beispiel C03 und/oder einem oder einigen anderen Beispielen hierin, ferner umfassend: Betreiben des Agentennetzes, um eine Aktion in Übereinstimmung mit einer aktuellen Richtlinie und einem Erkundungsrauschen auszuwählen und die ausgewählte Aktion auf dem Ziel-UE bereitzustellen; Kassieren einer Belohnung basierend auf der Durchführung der ausgewählten Aktion; und Speichern der Aktion, des Zustands und der kassierten Belohnung in dem Wiedergabepuffer.
Beispiel C05 beinhaltet das Verfahren von Beispiel C04 und/oder einem oder einigen anderen Beispielen hierin, wobei das Auswählen der Aktion umfasst: zufälliges Abtasten eines Aktionsraums für die Aktion unter Verwendung einer Wahrscheinlichkeit; oder unter Verwendung eines existierenden heuristischen Algorithmus zum Auswählen der Aktion.
Beispiel C06 beinhaltet das Verfahren von Beispiel C05 und/oder einem oder einigen anderen Beispielen hierin, ferner umfassend: zufälliges Abtasten eines Ministapels aus dem Wiedergabepuffer; Ermitteln eines Ziels für eine zeitliche Differenzfehlerberechnung aus der kassierten Belohnung; und Trainieren des Kritiknetzes, um eine Verlustfunktion zu minimieren.
Beispiel C07 beinhaltet das Verfahren von Beispiel C06 und/oder einem oder einigen anderen Beispielen hierin, ferner umfassend: Trainieren des Aktornetzes unter Verwendung eines Richtliniengradienten, um die Belohnungsfunktion zu maximieren.
Beispiel C08 beinhaltet das Verfahren von Beispiel C07 und/oder einem oder einigen anderen Beispielen hierin, wobei der Richtliniengradient vom Kritiknetz erzeugt wird.
Beispiel C09 beinhaltet das Verfahren von Beispiel C07 oder C08 und/oder einem oder einigen anderen Beispielen hierin, ferner umfassend: Trainieren des Repräsentationsnetzes unter Verwendung des Richtliniengradienten.
Beispiel D01 beinhaltet das Verfahren der Beispiele A01-C09, wobei die Beobachtungsdaten eines oder mehrere von Paketverzögerung, Paketverlustrate, Paketverwerfungsrate, PHY-Rate; Goodput; UE-Durchsatz, Zellendurchsatz, Jitter, Alpha-Fairness, CQI-bezogenen Messwerten, MCS-bezogenen Messwerten, PRB-Nutzung, Funknutzungspegel pro NAN und Datenvolumen beinhalten.
Beispiel D02 beinhaltet das Verfahren der Beispiele A01-D01 und/oder von einem oder einigen anderen Beispielen hierin, wobei das Verfahren von einem Mehrfachzugriffs-Edge-Rechen(MEC)-Server/-Host oder eine intelligente Funkzugangsnetz(RAN)-Steuerung (RIC) der Open RAN Alliance (O-RAN) durchgeführt wird.
Beispiel Z01 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei eine Ausführung der Anweisungen durch eine Prozessorschaltungsanordnung zu bewirken hat, dass die Prozessorschaltungsanordnung das Verfahren von einem der Beispiele A01-D02 und/oder einen beliebigen anderen hierin besprochenen Aspekt durchführt.
Beispiel Z02 beinhaltet ein Computerprogramm, das die Anweisungen von Beispiel Z01 umfasst.
Beispiel Z03 beinhaltet eine Anwendungsprogrammierschnittstelle, die Funktionen, Verfahren, Variablen, Datenstrukturen und/oder Protokolle für das Computerprogramm von Beispiel Z02 definiert.
Beispiel Z04 beinhaltet eine Einrichtung, die eine Schaltungsanordnung umfasst, die mit den Anweisungen von Beispiel Z01 geladen ist.
Beispiel Z05 beinhaltet eine Einrichtung, die eine Schaltungsanordnung umfasst, die betreibbar ist, die Anweisungen von Beispiel Z01 auszuführen.
Beispiel Z06 beinhaltet eine integrierte Schaltung, die die Prozessorschaltungsanordnung von Beispiel Z01 und/oder das eine oder die mehreren computerlesbaren Medien von Beispiel Z01 umfasst.
Beispiel Z07 beinhaltet ein Rechensystem, das das eine oder die mehreren computerlesbaren Medien und die Prozessorschaltungsanordnung von Beispiel Z01 umfasst.
Beispiel Z08 beinhaltet eine Einrichtung, die Mittel zum Ausführen der Anweisungen von Beispiel Z01 umfasst.
Beispiel Z09 beinhaltet ein Signal, das als ein Ergebnis des Ausführens der Anweisungen von Beispiel Z01 generiert wird.
Beispiel Z10 beinhaltet eine Dateneinheit, die als ein Ergebnis des Ausführens der Anweisungen von Beispiel Z01 generiert wird.
Beispiel Z11 beinhaltet die Dateneinheit von Beispiel Z10, wobei die Dateneinheit ein Datagramm, ein Netzwerkpaket, einen Datenframe, ein Datensegment, eine Protokolldateneinheit (PDU), eine Dienstdateneinheit (SDU), eine Nachricht oder ein Datenbankobjekt ist.
Beispiel Z12 beinhaltet ein Signal, das mit der Dateneinheit von Beispiel Z10 oder Z11 codiert ist.
Beispiel Z13 beinhaltet ein elektromagnetisches Signal, das die Anweisungen von Beispiel Z01 trägt.
Beispiel Z14 enthält eine Einrichtung, die Mittel zum Durchführen des Verfahrens von einem der Beispiele A01-D02 umfasst.
7. TERMINOLOGIE
Wie hier verwendet, sollen die Singularformen „ein“, „eine“ und „der“, „die“, „das“ die Pluralformen ebenfalls beinhalten, sofern der Zusammenhang nicht eindeutig etwas anderes angibt. Es ist ferner offensichtlich, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten spezifizieren, aber nicht die Anwesenheit oder das Hinzufügen von einem oder mehreren anderen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon ausschließen. Der Ausdruck „A und/oder B“ bedeutet (A), (B) oder (A und B). Zum Zwecke der vorliegenden Offenbarung bedeutet der Ausdruck „A, B und/oder C“ (A), (B), (C), (A und B), (A und C), (B und C) oder (A, B und C). In der Beschreibung können die Ausdrücke „in einer Ausführungsform“ oder „in einigen Ausführungsformen“ verwendet werden, die jeweils auf eine oder mehrere der gleichen oder verschiedenen Ausführungsformen verweisen können. Weiterhin sind die Ausdrücke „umfassend“, „beinhaltend“, „aufweisend“ und dergleichen, wie sie mit Bezug auf die vorliegende Offenbarung verwendet werden, synonym.
Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“, gemeinsam mit Ableitungen davon, werden hierin verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander stehen, kann bedeuten, dass zwei oder mehr Elemente einander indirekt berühren aber dennoch zusammenwirken oder miteinander interagieren, und/oder kann bedeuten, dass ein oder mehrere andere Elemente zwischen den Elementen gekoppelt oder angebunden sind, von denen gesagt wird, dass sie aneinander gekoppelt sind. Der Ausdruck „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt miteinander stehen. Der Begriff „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente durch ein Kommunikationsmittel einschließlich durch einen Draht oder eine andere Zwischenverbindung, durch einen Drahtloskommunikationskanal oder -verknüpfung und/oder dergleichen miteinander in Kontakt stehen können.
Der Begriff „Schaltungsanordnung“ verweist zumindest bei manchen Ausführungsformen auf einen Schaltkreis oder ein System mehrerer Schaltkreise, der bzw. das dazu konfiguriert ist, eine bestimmte Funktion in einer elektronischen Vorrichtung durchzuführen. Der Schaltkreis oder das System von Schaltkreisen kann Teil einer oder mehrerer Hardwarekomponenten sein, wie etwa eines Logikschaltkreises, eines Prozessors (gemeinsam genutzt, dediziert oder Gruppe) und/oder eines Speichers (gemeinsam genutzt, dediziert oder Gruppe), eines ASIC, eines FPGA, einer programmierbaren Logiksteuerung (PLC), eines SoC, eines SiP, eines Mehrchipgehäuses (MCP), eines DSP usw., die dazu konfiguriert sind, die beschriebene Funktionalität bereitzustellen, oder kann diese beinhalten. Außerdem kann sich der Begriff „Schaltungsanordnung“ auch auf eine Kombination eines oder mehrerer Hardwareelemente mit dem Programmcode beziehen, der zum Ausführen der Funktionalität dieses Programmcodes verwendet wird. Einige Arten von Schaltungsanordnung können ein oder mehrere Software- oder Firmware-Programme ausführen, um wenigstens etwas der beschriebenen Funktionalität bereitzustellen. Eine solche Kombination von Hardwareelementen und Programmcode kann als ein bestimmter Schaltungsanordnungstyp bezeichnet werden.
Es versteht sich, dass die in dieser Beschreibung beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um ihre Implementierungsunabhängigkeit genauer hervorzuheben. Derartige Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen realisiert sein. Eine Komponente oder ein Modul kann zum Beispiel als ein Hardware-Schaltkreis implementiert werden, der maßgeschneiderte Very-Large-Scale-Integration(VLSI)-Schaltkreise oder Gatearrays, handelsübliche Halbleiter wie Logikchips, Transistoren oder andere diskrete Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwareeinrichtungen wie Field Programmable Gate Arrays, programmierbarer Arraylogik, programmierbaren Logikeinrichtungen oder Ähnlichem implementiert sein. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert sein. Eine identifizierte Komponente oder ein identifiziertes Modul mit ausführbarem Code kann beispielsweise ein oder mehrere physische oder logische Blöcke mit Computeranweisungen umfassen, die zum Beispiel als ein Objekt, eine Prozedur oder eine 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 getrennte Befehle umfassen, die an verschiedenen Orten gespeichert sind, die, wenn sie logisch zusammengefügt werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.
Tatsächlich kann eine Komponente oder ein Modul mit ausführbarem Code eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über mehrere Arbeitsspeichereinrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können manche Aspekte des beschriebenen Prozesses (wie etwa Codeumschreiben und Codeanalyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Rechenzentrum) als dem stattfinden, in dem der Code bereitgestellt wird (z. B. in einem Computer, der in einem Sensor oder Roboter eingebettet ist). Gleichermaßen können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und dargestellt sein und können auf eine geeignete Form ausgeführt sein und innerhalb einer geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz gesammelt sein oder können über verschiedene Stellen einschließlich über verschiedene Speichereinrichtungen verteilt sein und können zumindest teilweise nur 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 die gewünschten Funktionen auszuführen.
Der Begriff „Prozessorschaltungsanordnung“ bezieht sich zumindest bei manchen Ausführungsformen auf, ist Teil davon oder beinhaltet eine Schaltungsanordnung, die in der Lage ist, sequenziell und automatisch eine Sequenz arithmetischer oder logischer Operationen oder Aufzeichnen, Speichern und/oder Übertragen digitaler Daten auszuführen. Der Begriff „Prozessorschaltungsanordnung“ bezieht sich zumindest bei manchen Ausführungsformen auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische CPU, einen Einzelkernprozessor, einen Doppelkernprozessor, einen Dreikernprozessor, einen Vierkernprozessor und/oder eine beliebige andere Vorrichtung, die in der Lage ist, computerausführbare Anweisungen auszuführen oder anderweitig zu betreiben, wie etwa Programmcode, Softwaremodule und/oder funktionale Prozesse. Die Begriffe „Anwendungsschaltungsanordnung“ und/oder „Basisbandschaltungsanordnung“ können als synonym angesehen werden und können als „Prozessorschaltungsanordnung“ bezeichnet werden.
Der Begriff „Speicher“ und/oder „Speicherschaltungsanordnung“ bezieht sich zumindest bei manchen Ausführungsformen auf eine oder mehrere Hardwarevorrichtungen zum Speichern von Daten, einschließlich RAM, MRAM, PRAM, DRAM und/oder SDRAM, Kernspeicher, ROM, Magnetplattenspeicherungsmedien, optische Speicherungsmedien, Flashspeichervorrichtungen oder andere maschinenlesbare Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann unter anderem Speicher, tragbare oder feste Speicherungsvorrichtungen, optische Speicherungsvorrichtungen und verschiedene andere Medien beinhalten, die in der Lage sind, Anweisungen oder Daten zu speichern, aufzunehmen oder zu tragen.
Der Begriff „Schnittstellenschaltungsanordnung“ verweist zumindest bei manchen Ausführungsformen auf, ist Teil davon oder beinhaltet eine Schaltungsanordnung, die den Austausch von Informationen zwischen zwei oder mehr Komponenten oder Vorrichtungen ermöglicht. Der Begriff „Schnittstellenschaltungsanordnung“ bezieht sich zumindest bei manchen Ausführungsformen auf eine oder mehrere Hardwareschnittstellen, zum Beispiel Busse, E/A-Schnittstellen, Peripheriekomponentenschnittstellen, Netzwerkschnittstellenkarten und/oder dergleichen.
Der Begriff „Element“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Einheit, die auf einem gegebenen Abstraktionsniveau unteilbar ist und eine klar definierte Grenze aufweist, wobei ein Element eine beliebige Art von Entität sein kann, die zum Beispiel eine oder mehrere Vorrichtungen, Systeme, Steuerungen, Netzwerkelemente, Module usw. oder Kombinationen davon beinhaltet. Der Begriff „Vorrichtung“ bezieht sich zumindest bei manchen Ausführungsformen auf eine physische Entität, die innerhalb einer anderen physischen Entität in ihrer Nähe eingebettet oder an dieser angebracht ist, mit Fähigkeiten, digitale Informationen von oder zu dieser physischen Entität zu übertragen. Der Begriff „Entität“ bezieht sich zumindest bei manchen Ausführungsformen auf eine individuelle Komponente einer Architektur oder Vorrichtung oder als Nutzlast übertragene Informationen. Der Begriff „Steuerung“ bezieht sich zumindest bei manchen Ausführungsformen auf ein Element oder eine Entität, das/die die Fähigkeit aufweist, eine physische Entität zu beeinflussen, wie etwa durch Ändern ihres Zustands oder Bewirken, dass sich die physische Entität bewegt.
Der Begriff „Edge-Rechnen“ umfasst viele Implementierungen von verteiltem Rechnen, die Verarbeitungsaktivitäten und -ressourcen (z. B. Berechnung, Speicherung, Beschleunigungsressourcen) in Richtung des „Randes“ des Netzwerks bewegen, in einem Bestreben, Latenz zu reduzieren und den Durchsatz für Endpunktbenutzer (Client-Vorrichtungen, Endgeräte usw.) zu erhöhen. Derartige Edge-Rechenimplementierungen beinhalten typischerweise das Anbieten solcher Aktivitäten und Ressourcen in Cloud-ähnlichen Diensten, Funktionen, Anwendungen und Subsystemen von einem oder mehreren Standorten, auf die über drahtlose Netzwerke zugegriffen werden kann. Somit sind die Verweise auf einen „Rand“ eines Netzwerks, Clusters, einer Domäne, eines Systems oder einer Rechenanordnung, die hierin verwendet werden, Gruppen oder Gruppierungen funktioneller verteilter Rechenelemente und stehen daher allgemein nicht mit „Kanten“ (Verknüpfungen oder Verbindungen) in Beziehung, wie sie in der Graphentheorie verwendet werden. Bestimmte Anordnungen von Edge-Rechenanwendungen und Diensten, die über mobile Drahtlosnetzwerke (z. B. Mobilfunk- und WiFi-Datennetze) zugänglich sind, können als „mobiles Edge-Computing“ oder „Mehrfahrzugriffs-Edge-Computing“ bezeichnet werden, was durch das Akronym „MEC“ referenziert werden kann. Die Verwendung von „MEC“ hierin kann sich auch auf eine standardisierte Implementierung beziehen, die vom Europäischen Institut für Telekommunikationsnormen (ETSI) verbreitet wird und als „ETSI-MEC“ bezeichnet wird. Terminologie, die von der ETSI-MEC-Spezifikation verwendet wird, wird hierin im Allgemeinen durch Bezugnahme aufgenommen, es sei denn, eine widersprüchliche Definition oder Verwendung wird hierin bereitgestellt.
Der Begriff „Rechenknoten“ oder „Rechenvorrichtung“ bezieht sich zumindest bei manchen Ausführungsformen auf eine identifizierbare Entität, die einen Aspekt von Edge-Rechenoperationen implementiert, sei es, ob ein Teil eines größeren Systems, eine verteilte Sammlung von Systemen oder eine eigenständige Einrichtung. In manchen Beispielen kann ein Rechenknoten als „Edge-Knoten“, „Edge-Vorrichtung“, „Edge-System“ bezeichnet werden, je nachdem, ob er als Client, Server oder Zwischenentität in Betrieb ist. Spezifische Implementierungen eines Computerknotens können in einen Server, eine Basisstation, ein Gateway, eine Straßenseiteneinheit, eine Einheit vor Ort, ein UE oder eine Endverbrauchsvorrichtung oder dergleichen integriert sein.
Der Begriff „Computersystem“ bezieht sich zumindest bei manchen Ausführungsformen auf eine beliebige Art von miteinander verbundenen elektronischen Vorrichtungen, Computervorrichtungen oder Komponenten davon. Zusätzlich verweisen die Begriffe „Computersystem“ und/oder „System“ zumindest bei manchen Ausführungsformen auf verschiedene Komponenten eines Computers, die kommunikativ miteinander gekoppelt sind. Ferner verweist der Begriff „Computersystem“ und/oder „System“ zumindest bei manchen Ausführungsformen auf mehrere Computervorrichtungen und/oder mehrere Computersysteme, die kommunikativ miteinander gekoppelt und dazu ausgelegt sind, Rechen- und/oder Vernetzungsressourcen gemeinsam zu nutzen.
Der Begriff „Architektur“ bezieht sich zumindest in manchen Ausführungsformen auf eine Computerarchitektur oder eine Netzwerkarchitektur. Eine „Netzwerkarchitektur“ ist eine physische und logische Gestaltung oder Anordnung von Software- und/oder Hardwareelementen in einem Netzwerk einschließlich Kommunikationsprotokollen, Schnittstellen und Medienübertragung. Eine „Computerarchitektur“ ist eine physische und logische Gestaltung oder Anordnung von Software- und/oder Hardwareelementen in einem Computersystem oder einer Computerplattform einschließlich Technologiestandards für Interaktionen dazwischen.
Der Begriff „Gerät“, „Computergerät“ oder dergleichen bezieht sich zumindest bei manchen Ausführungsformen auf eine Computervorrichtung oder ein Computersystem mit Programmcode (z. B. Software oder Firmware), der spezifisch dazu ausgelegt ist, eine spezifische Rechenressource bereitzustellen. Ein „virtuelles Gerät“ ist ein virtuelles Maschinenabbild, das durch eine Hypervisor-ausgestattete Vorrichtung zu implementieren ist, die ein Computergerät virtualisiert oder emuliert oder anderweitig dediziert ist, eine spezifische Rechenressource bereitzustellen.
Der Begriff „Endgerät“ oder „UE“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Vorrichtung mit Funkkommunikationsfähigkeiten und kann einen entfernten Benutzer von Netzwerkressourcen in einem Kommunikationsnetzwerk beschreiben. Der Begriff „Endgerät“ oder „UE“ kann als synonym angesehen werden zu und kann als Client, Mobilgerät, Mobilvorrichtung, Mobilendgerät, Benutzerendgerät, Mobileinheit, Station, Mobilstation, Mobilbenutzer, Teilnehmer, Benutzer, Fernstation, Zugriffsagent, Benutzeragent, Empfänger, Funkgerät, rekonfigurierbares Funkgerät, rekonfigurierbares Mobilgerät usw. bezeichnet werden. Ferner kann der Begriff „Endgerät“ oder „UE“ eine beliebige Art von drahtloser/drahtgebundener Vorrichtung oder eine beliebige Rechenvorrichtung einschließlich einer drahtlosen Kommunikationsschnittstelle beinhalten. Der Begriff „Station“ oder „STA“ bezieht sich zumindest bei manchen Ausführungsformen auf eine logische Entität, die eine einzeln adressierbare Instanz einer Medienzugriffssteuerung (MAC) und einer Bitübertragungsschicht(PHY)-Schnittstelle zu dem drahtlosen Medium (WM) ist. Der Begriff „drahtloses Medium“ oder „WM“ bezieht sich zumindest bei manchen Ausführungsformen auf das Medium, das verwendet wird, um die Übertragung von Protokolldateneinheiten (PDUs) zwischen Peer-Bitübertragungsschicht(PHY)-Entitäten eines drahtlosen lokalen Netzwerks (LAN) zu implementieren.
Der Begriff „Netzwerkelement“ bezieht sich zumindest bei manchen Ausführungsformen auf ein physisches oder virtualisiertes Gerät und/oder eine physische oder virtualisierte Infrastruktur, die verwendet werden, um drahtgebundene oder drahtlose Kommunikationsnetzdienste bereitzustellen. Der Begriff „Netzwerkelement“ kann synonym zu und/oder als ein vernetzter Computer, eine Vernetzungshardware, ein Netzwerkgerät, ein Netzwerkknoten, ein Router, ein Switch, ein Hub, eine Brücke, eine Funknetzwerksteuerung, eine RAN-Vorrichtung, ein RAN-Knoten, ein Gateway, ein Server, eine virtualisierte VNF, NFVI und/oder dergleichen angesehen werden oder als solche bezeichnet werden.
Der Begriff „Zugangspunkt“ oder „AP“ verweist zumindest bei einigen Ausführungsformen auf eine Entität, die eine Station (STA) enthält und Zugang zu den Verteilungsdiensten über das drahtlose Medium (WM) für assoziierte STAs bereitstellt. Ein AP umfasst eine STA und eine Verteilungssystemzugangsfunktion (DSAF).
Der Begriff „Basisstation“ verweist mindestens bei einigen Ausführungsformen auf ein Netzwerkelement in einem Funkzugangsnetzwerk (RAN), wie etwa einem Mobilkommunikationsnetzwerk der vierten Generation (4G) oder der fünften Generation (5G), das für die Übertragung und den Empfang von Funksignalen in einer oder mehreren Zellen zu oder von einem Endgerät (UE) zuständig ist. Eine Basisstation kann eine integrierte Antenne aufweisen oder über Zubringerkabel mit einem Antennenarray verbunden sein. Eine Basisstation verwendet spezialisierte digitale Signalverarbeitungs- und Netzwerkfunktionshardware. In einigen Beispielen kann die Basisstation für Flexibilität, Kosten und Leistungsfähigkeit in mehrere Funktionsblöcke aufgeteilt sein, die in Software arbeiten. In manchen Beispielen kann eine Basisstation einen Evolved Node-B (eNB) oder einen Node-B der nächsten Generation (gNB) beinhalten. In manchen Beispielen kann die Basisstation Rechenhardware betreiben oder beinhalten, um als ein Rechenknoten zu arbeiten. In vielen der hierin besprochenen Szenarien kann jedoch ein RAN-Knoten mit einem Zugangspunkt (zum Beispiel Drahtlosnetzwerkzugangspunkt) oder einer anderen Netzwerkzugangs-Hardware ersetzt werden.
Der Begriff „E-UTEAN-NodeB“, „eNodeB“ oder „eNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der E-UTRA-Benutzerebenen-Protokollabschlüsse (PDCP/RLC/MAC/PHY) und Steuerebenen-Protokollabschlüsse(RRC-Protokollabschlüsse) zu einem UE bereitstellt und über eine S1-Schnittstelle mit dem Evolved Packet Core (EPC) verbunden ist. Zwei oder mehr eNBs sind mittels einer X2-Schnittstelle miteinander (und/oder mit einem oder mehreren en-gNBs) verbunden.
Der Begriff „eNB der nächsten Generation“ oder „ng-eNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der E-UTRA-Benutzerebenen- und Steuerebenen-Protokollabschlüsse zu einem UE bereitstellt und über die NG-Schnittstelle mit dem 5GC verbunden ist. Zwei oder mehr ng-eNBs sind über eine Xn-Schnittstelle miteinander (und/oder mit einem oder mehreren gNBs) verbunden.
Der Begriff „NodeB der nächsten Generation“, „gNodeB“ oder „gNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der NR-Benutzerebenen- und Steuerebenen-Protokollabschlüsse zu einem UE bereitstellt und über die NG-Schnittstelle mit dem 5GC verbunden ist. Zwei oder mehr gNBs sind über eine Xn-Schnittstelle miteinander (und/oder mit einem oder mehreren ng-eNBs) verbunden.
Der Begriff „E-UTRA-NR gNB“ oder „en-gNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der NR-Benutzerebenen- und Steuerebenen-Protokollabschlüsse zu einem UE hin bereitstellt und als ein Sekundärknoten in E-UTRA-NR-Doppelkonnektivitäts-Szenarien (EN-DC-Szenarien) fungiert (siehe zum Beispiel 3GPP TS 37.340 v16.6.0 (2021-07-09)). Zwei oder mehr en-gNBs sind über eine X2-Schnittstelle miteinander (und/oder mit einem oder mehreren eNBs) verbunden.
Der Begriff „RAN-Knoten der nächsten Generation“ oder „NG-RAN-Knoten“ verweist mindestens bei einigen Ausführungsformen entweder auf einen gNB oder auf einen ng-eNB.
Der Begriff „Zentraleinheit“ oder „CU“ verweist mindestens bei einigen Ausführungsformen auf einen logischen Knoten, der Funkressourcensteuerung (RRC), Dienstdatenanpassungsprotokoll (SDAP) und/oder Paketdatenkonvergenzprotokoll (PDCP)-Protokolle/Schichten eines NG-RAN-Knotens hostet, oder RRC- und PDCP-Protokolle des en-gNB, der den Betrieb einer oder mehrerer DUs steuert; eine CU schließt eine F1-Schnittstelle ab, die mit einer DU verbunden ist, und kann mit mehreren DUs verbunden sein.
Der Begriff „verteilte Einheit“ oder „DU“ verweist mindestens bei einigen Ausführungsformen auf einen logischen Knoten, der Funkverknüpfungssteuerung (RLC), Medienzugriffssteuerung (MAC) und Bitübertragungsschichten (PHY) des NG-RAN-Knotens oder en-gNB hostet, und ihr Betrieb wird teilweise von einer CU gesteuert; eine DU unterstützt eine oder mehrere Zellen, und eine Zelle wird von nur einer DU unterstützt; und eine DU schließt die F1-Schnittstelle ab, die mit einer CU verbunden ist.
Der Begriff „Residential Gateway“ oder „RG“ verweist wenigstens bei einigen Ausführungsformen auf eine Vorrichtung, die zum Beispiel Sprache, Daten, Rundfunkvideo, Video auf Abruf zu anderen Vorrichtungen an Kundenstandorten bereitstellt. Der Begriff „Wireline-5G-Zugangsnetz“ oder „W-5GAN“ verweist mindestens bei einigen Ausführungsformen auf ein Wireline-AN, das über N2- und N3-Bezugspunkte mit einem 5GC verbunden ist. Das W-5GAN kann sowohl ein W-5GBAN als auch ein W-5GCAN sein. Der Begriff „Wireline 5G Cable Access Network“ oder „W-5GCAN“ bezieht sich zumindest in manchen Ausführungsformen auf ein Zugangsnetz, das in/durch CableLabs definiert ist. Der Begriff „Wireline BBF Cable Access Network“ oder „W-5GBAN“ bezieht sich zumindest in manchen Ausführungsformen auf ein Zugangsnetz, das in/durch das Broadband Forum (BBF) definiert ist. Der Begriff „Wireline Access Gateway Function“ oder „W-AGF“ bezieht sich zumindest in manchen Ausführungsformen auf eine Netzwerkfunktion in W-5GAN, die Konnektivität zu einem 3GPP-5G-Kernnetz (5GC) mit 5G-RG und/oder FN-RG bereitstellt. Der Begriff „5G-RG“ bezieht sich zumindest in manchen Ausführungsformen auf ein RG, das in der Lage ist, sich mit einem 5GC zu verbinden, das die Rolle eines Endgeräts in Bezug auf das 5GC spielt; es unterstützt ein sicheres Element und tauscht N1-Signalgebung mit dem 5GC aus. Das 5G-RG kann sowohl ein 5G-BRG als auch ein 5G-CRG sein.
Der Begriff „Zentrale“ (oder CO) gibt einen Aggregationspunkt für eine Telekommunikationsinfrastruktur innerhalb eines zugänglichen oder definierten geographischen Gebiets an, wo Telekommunikationsdienstanbieter traditionell oft Vermittlungseinrichtungen für einen oder mehrere Typen von Zugangsnetzen angeordnet haben. Die CO kann physisch gestaltet sein, um Telekommunikationsinfrastrukturgeräte oder Rechen-, Datenspeicherungs- und Netzwerkressourcen aufzunehmen. Die CO muss jedoch kein designierter Standort eines Telekommunikationsdienstleisters sein. Die CO kann eine beliebige Anzahl von Rechenvorrichtungen für Edge-Anwendungen und -Dienste oder sogar lokale Implementierungen von Cloud-ähnlichen Diensten hosten.
Der Begriff „Cloud-Computing“ oder „Cloud“ bezieht sich zumindest in manchen Ausführungsformen auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Bestand von gemeinsam nutzbaren Rechenressourcen mit Selbstbedienungsbereitstellung und -verwaltung bei Bedarf und ohne aktives Management durch Benutzer. Cloud-Computing stellt Cloud-Rechendienste (oder Cloud-Dienste) bereit, bei denen es sich um eine oder mehrere über Cloud-Computing angebotene Fähigkeiten handelt, die unter Verwendung einer definierten Schnittstelle (z. B. einer API oder dergleichen) aufgerufen werden. Der Begriff „Rechenressource“ oder einfach „Ressource“ bezieht sich zumindest bei manchen Ausführungsformen auf eine beliebige physische oder virtuelle Komponente oder Verwendung solcher Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Rechenressourcen beinhalten Nutzung/Zugriff auf Server, Prozessor(en), Speicherungsgeräte, Speichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, Eingabe/Ausgabe(Peripherie)-Vorrichtungen, mechanische Vorrichtungen, Netzwerkverbindungen (z. B. Kanäle/Verknüpfungen, Anschlüsse, Netzwerksockel usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen. Eine „Hardwareressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die durch ein oder mehrere physische Hardwareelemente bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicherungs- und/oder Netzwerkressourcen beziehen, die einer Anwendung, einer Vorrichtung, einem System usw. durch eine Virtualisierungsinfrastruktur bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, auf die Computervorrichtungen/Systeme über ein Kommunikationsnetzwerk zugreifen können. Der Begriff „Systemressourcen“ kann sich auf eine beliebige Art gemeinsam genutzter Entitäten beziehen, um Dienste bereitzustellen, und kann Rechen- und/oder Netzwerkressourcen beinhalten. Systemressourcen können als ein Satz von kohärenten Funktionen, Netzwerkdatenobjekten oder Diensten betrachtet werden, auf die durch einen Server zugegriffen werden kann, wo sich solche Systemressourcen auf einem einzigen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind.
Der Begriff „Arbeitslast“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Menge an Arbeit, die durch ein Computersystem, eine Vorrichtung, eine Entität usw. während eines Zeitraums oder zu einem bestimmten Zeitpunkt durchgeführt wird. Eine Arbeitslast kann als eine Richtgröße repräsentiert werden, wie etwa eine Reaktionszeit, ein Durchsatz (z. B. wie viel Arbeit über einen Zeitraum erreicht wird) und/oder dergleichen. Zusätzlich oder alternativ dazu kann die Arbeitslast als eine Speicherarbeitslast (z. B. eine Menge an Speicherplatz, der zur Programmausführung benötigt wird, um temporäre oder permanente Daten zu speichern und Zwischenberechnungen durchzuführen), eine Prozessorarbeitslast (z. B. eine Anzahl an Anweisungen, die von einem Prozessor während einer gegebenen Zeitspanne oder zu einem bestimmten Zeitpunkt ausgeführt werden), eine E/A-Arbeitslast (z. B. eine Anzahl von Ein- und Ausgaben oder Systemzugriffen während eines gegebenen Zeitraums oder zu einem bestimmten Zeitpunkt), Datenbankarbeitslasten (z. B. eine Anzahl von Datenbankabfragen während eines Zeitraums), eine netzwerkbezogene Arbeitslast (z. B. eine Anzahl von Netzwerkanhängen, eine Anzahl von Mobilitätsaktualisierungen, eine Anzahl von Funkverknüpfungsausfällen, eine Anzahl von Handovers, eine Menge von über eine Luftschnittstelle zu übertragenden Daten usw.) und/oder dergleichen. Verschiedene Algorithmen können verwendet werden, um eine Arbeitslast und/oder Arbeitslastmerkmale zu ermitteln, die auf einem beliebigen der zuvor genannten Arbeitslasttypen basieren können.
Der Begriff „Cloud-Dienstanbieter“ (oder CSP) bezeichnet eine Organisation, die typischerweise großformatige „Cloud“-Ressourcen betreibt, die aus zentralisierten, regionalen und Edge-Rechenzentren (wie z. B. im Kontext der öffentlichen Cloud verwendet) bestehen. In anderen Beispielen kann ein CSP auch als Cloud-Dienstbetreiber (CSO) bezeichnet werden. Verweise auf „Cloud-Computing“ beziehen sich allgemein auf Rechenressourcen und -dienste, die von einem CSP oder einem CSO an entfernten Standorten mit zumindest etwas erhöhter Latenz, Entfernung oder Einschränkungen relativ zu Edge-Computing angeboten werden.
Der Begriff „Rechenzentrum“ bezieht sich zumindest bei manchen Ausführungsformen auf eine zweckentworfene Struktur, die mehrere Hochleistungsberechnungs- und Datenspeicherungsknoten beherbergen soll, sodass eine große Menge an Rechen-, Datenspeicherungs- und Netzwerkressourcen an einem einzigen Standort vorhanden ist. Dabei handelt es sich häufig um spezialisierte Rack- und Gehäusesysteme, geeignete Heiz-, Kühl-, Lüftungs-, Sicherheits-, Brandunterdrückungs- und Stromversorgungssysteme. Der Begriff kann in manchen Zusammenhängen auch auf einen Rechen- und Datenspeicherungsknoten verweisen. Ein Rechenzentrum kann im Maßstab zwischen einem zentralisierten oder Cloud-Rechenzentrum (z. B. am größten), einem regionalen Rechenzentrum und einem Edge-Rechenzentrum (z. B. am kleinsten) variieren.
Der Begriff „Zugangs-Edge-Schicht“ gibt die Unterschicht der Infrastruktur-Edge an, die dem Endbenutzer oder Gerät am nächsten ist. Eine solche Schicht kann zum Beispiel von einem Edge-Rechenzentrum erfüllt werden, das an einem Mobilfunknetz-Standort eingesetzt wird. Die Zugriffs-Edge-Schicht fungiert als die vorderste Front der Infrastruktur-Edge und kann mit einer Aggregations-Edge-Schicht verbunden sein, die in der Hierarchie höher ist.
Der Begriff „Aggregations-Edge-Schicht“ bezeichnet die einen Sprung von der Zugriffs-Edge-Schicht entfernte Schicht der Infrastruktur-Edge. Diese Schicht kann entweder als ein Rechenzentrum im mittleren Maßstab an einem einzigen Standort existieren oder kann aus mehreren miteinander verbundenen Mikrorechenzentren gebildet sein, um eine hierarchische Topologie mit der Zugriffs-Edge zu bilden, um eine größere Kollaboration, eine größere Arbeitslastausfallsicherheit und Skalierbarkeit als die Zugriffs-Edge allein zu ermöglichen.
Der Begriff „Netzwerkfunktionsvirtualisierung“ (oder NFV) gibt die Migration von NFs von eingebetteten Diensten innerhalb proprietärer Hardwaregeräte zu softwarebasierten virtualisierten NFs (oder VNFs) an, die auf standardisierten CPUs (z. B. innerhalb standardmäßiger x86®-und ARM®-Server, wie etwa jene einschließlich Intel®-Xeon™- oder AMD®-Epyc™- oder Opteron™-Prozessoren) unter Verwendung von Virtualisierungs- und Cloud-Rechentechnologien nach Industriestandard laufen. Zusätzlich oder alternativ dazu werden NFV-Verarbeitung und Datenspeicherung an den Edge-Rechenzentren stattfinden, die direkt mit dem lokalen Mobilfunkstandort verbunden sind, innerhalb der Infrastruktur-Edge.
Der Begriff „virtualisierte NF“ (oder VNF) gibt eine softwarebasierte NF an, die auf Multifunktions-Mehrzweck-Rechenressourcen (z. B. x86, ARM-Verarbeitungsarchitektur) arbeitet, die von NFV anstelle dedizierter physischer Geräte verwendet werden. Zusätzlich oder alternativ arbeiten mehrere VNFs in einem Edge-Rechenzentrum an der Infrastruktur-Edge.
Der Begriff „Edge-Rechenknoten“ verweist mindestens bei einigen Ausführungsformen auf eine reale, logische oder virtualisierte Implementierung eines rechenfähigen Elements in Form einer Vorrichtung, eines Gateways, einer Brücke, eines Systems oder eines Subsystems, einer Komponente, egal ob es in einem Server-, Client-, Endpunkt- oder Peer-Modus arbeitet und ob es sich an einer „Edge“ eines Netzwerks oder an einem verbundenen Ort weiter innerhalb des Netzwerks befindet. Bezugnahmen auf einen „Knoten“, die hierin verwendet werden, sind im Allgemeinen mit „Vorrichtung“, „Komponente“ und „Subsystem“ austauschbar; Bezugnahmen auf ein „Edge-Rechensystem“ verweisen jedoch im Allgemeinen auf eine verteilte Architektur, Organisation oder Sammlung mehrerer Knoten und Vorrichtungen, die organisiert ist, um einen gewissen Aspekt von Diensten oder Ressourcen in einer Edge-Rechenumgebung zu erreichen oder anzubieten.
Der Begriff „Cluster“ verweist mindestens bei einigen Ausführungsformen auf einen Satz oder eine Gruppierung von Entitäten als Teil eines Edge-Rechensystems (oder von Edge-Rechensystemen) in der Form physischer Entitäten (zum Beispiel unterschiedlicher Rechensysteme, Netzwerke oder Netzwerkgruppen), logischer Entitäten (zum Beispiel Anwendungen, Funktionen, Sicherheitskonstrukten, Containern) und dergleichen. An einigen Stellen wird ein „Cluster“ auch als eine „Gruppe“ oder eine „Domäne“ bezeichnet. Die Mitgliedschaft des Clusters kann basierend auf Bedingungen oder Funktionen modifiziert oder beeinflusst werden, einschließlich aus dynamischer oder eigenschaftsbasierter Mitgliedschaft, aus Netzwerk- oder Systemverwaltungsszenarien oder aus verschiedenen unten besprochenen Beispieltechniken, die eine Entität in einem Cluster hinzufügen, modifizieren oder entfernen können. Cluster können auch mehrere Schichten, Ebenen oder Eigenschaften beinhalten oder damit assoziiert sein, einschließlich Variationen in Sicherheitsmerkmalen und Ergebnissen basierend auf solchen Schichten, Ebenen oder Eigenschaften.
Der Begriff „Funktechnologie“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Technologie zum drahtlosen Senden und/oder Empfangen von elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugangstechnologie“ oder „RAT“ bezieht sich zumindest bei manchen Ausführungsformen auf die Technologie, die für die zugrundeliegende physische Verbindung mit einem funkbasierten Kommunikationsnetz verwendet wird. Der „RAT-Typ“ identifiziert die Übertragungstechnik, die in einem Zugangsnetzwerk verwendet wird, zum Beispiel neuen Funk (NR), Schmalband-IoT (NB-IOT), Untrusted Non-3GPP, Trusted Non-3GPP, Trusted IEEE 802.11, Non-3GPP-Zugriff, Wireline, Wireline-Kabel, Wireline-Broadband-Forum (wireline-BBF) usw.
Der Begriff „V2X“ bezieht sich zumindest bei manchen Ausführungsformen auf Fahrzeug-zu-Fahrzeug(V2V)-, Fahrzeug-zu-Infrastruktur(V2I)-, Infrastruktur-zu-Fahrzeug(I2V)-, Fahrzeug-zu-Netzwerk(V2N)- und/oder Netzwerk-zu-Fahrzeug(N2V)-Kommunikationen und assoziierte Funkzugangstechnologien.
Der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) bezieht sich zumindest bei manchen Ausführungsformen auf einen Satz standardisierter Regeln oder Anweisungen, die durch eine Kommunikationsvorrichtung und/oder ein Kommunikationssystem implementiert werden, um mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, einschließlich Anweisungen zum Paketieren/Depaketieren von Daten, Modulieren/Demodulieren von Signalen, Implementieren von Protokollstapeln und/oder dergleichen. Beispiele von Drahtloskommunikationsprotokollen beinhalten eine Funkkommunikationstechnologie nach Global System for Mobile Communications (GSM), eine Funkkommunikationstechnologie nach General Packet Radio Service (GPRS), eine Funkkommunikationstechnologie nach Enhanced Data Rates for GSM Evolution (EDGE) und/oder eine Funkkommunikationstechnologie des Third Generation Partnership Project (3GPP) einschließlich beispielsweise 3GPP Fifth Generation (5G) oder New Radio (NR), Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), Long Term Evolution (LTE), LTE-Advanced (LTE Advanced), LTE Extra, LTE-A Pro, cdmaOne (2G), Code Division Multiple Access 2000 (CDMA 2000), Cellular Digital Packet Data (CDPD), Mobitex, Circuit Switched Data (CSD), High-Speed CSD (HSCSD), Wideband Code Division Multiple Access (W-CDM), High Speed Packet Access (HSPA), HSPA Plus (HSPA+), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), LTE LAA, MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UTRA (E-UTRA), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (AMPS), Digital AMPS (D-AMPS), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Push-to-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), Cellular Digital Packet Data (CDPD), DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Personal Handy-phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), auch als ein generisches 3GPP-Zugangsnetz- oder GAN-Standard bezeichnet), Bluetooth®, Bluetooth Low Energy (BLE), IEEE 802.15.4-basierte Protokolle (z. B. IPv6 over Low power Wireless Personal Area Networks (6LoMTAN), WirelessHART, MiWi, Thread, 802.11a usw.) WiFi-direct, ANT/ANT+, ZigBee, Z-Wave, 3GPP device-to-device (D2D) or Proximity Services (ProSe), Universal Plug and Play (UPnP), Low-Power Wide-Area-Network (LPWAN), Long Range Wide Area Network (LoRA) oder LoRaWAN™, das von Semtech und der LoRa Alliance entwickelt wurde, Digital Enhanced Cordless Telecommunications (DECT), DECT Ultra Low Energy (DECT ULE), DECT-2020, Sigfox, Wireless Gigabit Alliance (WiGig) Standard, Worldwide Interoperability for Microwave Access (WiMAX), mmWave-Standards im Allgemeinen (z. B. Drahtlossysteme, die bei 10-300 GHz und darüber arbeiten, wie WiGig, IEEE 802.11 ad, IEEE 802.11ay usw.), V2X-Kommunikation einschließlich C-V2X, WAVE, 802.11bd, Dedicated Short Range Communications (DSRC), Intelligent - Transport-Systems (ITS) einschließlich des europäischen ITS-G5, ITS-G5B, ITS-G5C usw., Dezimeterwellen(UHF)-Kommunikation, Ultrakurzwellen(UKW)-Kommunikation. Zusätzlich zu den oben aufgelisteten Standards kann eine beliebige Anzahl von Satelliten-Uplink-Technologien für Zwecke der vorliegenden Offenbarung verwendet werden, einschließlich zum Beispiel Funkgeräten, die mit Standards konform sind, die unter anderem von der International Telecommunication Union (ITU) oder der ETSI ausgegeben werden. Die hierin bereitgestellten Beispiele werden somit derart verstanden, dass sie auf verschiedene andere Kommunikationstechnologien anwendbar sind, die sowohl existieren als auch noch nicht formuliert sind.
Der Begriff „Kanal“ verweist mindestens bei einigen Ausführungsformen auf ein beliebiges Übertragungsmedium, sei es konkret oder nicht, das verwendet wird, um Daten oder einen Datenstrom zu kommunizieren. Der Begriff „Kanal“ kann synonym zu und/oder gleichbedeutend sein mit „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugriffskanal“, „Datenzugriffskanal“, „Verknüpfung“, „Datenverknüpfung“, „Träger“, „Hochfrequenzträger“ und/oder jedem anderen ähnlichen Begriff, der einen Pfad oder ein Medium bezeichnet, über den/das Daten kommuniziert werden. Zusätzlich verweist der Begriff „Verknüpfung“ mindestens bei einigen Ausführungsformen auf eine Verbindung zwischen zwei Vorrichtungen durch eine RAT zum Zweck des Übertragens und Empfangens von Informationen.
Der Begriff „Dienstqualität“ oder „QoS“ bezieht sich zumindest in einigen Ausführungsformen auf eine Beschreibung oder Messung der Gesamtleistungsfähigkeit eines Dienstes (z. B. Telefonie und/oder Mobilfunkdienst, Netzwerkdienst, Drahtloskommunikations-/Konnektivitätsdienst, Cloud-Rechendienst usw.). In einigen Fällen kann die QoS aus der Perspektive der Benutzer dieses Dienstes beschrieben oder gemessen werden, und entsprechend kann QoS der kollektive Effekt der Dienst-Leistungsfähigkeit sein, die den Grad der Zufriedenheit eines Benutzers dieses Dienstes bestimmt. In anderen Fällen bezieht sich QoS zumindest in einigen Ausführungsformen auf Verkehrspriorisierungs- und Ressourcenreservierungssteuermechanismen anstelle der erreichten Wahrnehmung der Dienstqualität. In diesen Fällen ist QoS die Fähigkeit, für verschiedene Anwendungen, Benutzer oder Abläufe unterschiedliche Prioritäten bereitzustellen oder für einen Ablauf ein gewisses Leistungsniveau zu garantieren. In beiden Fällen ist QoS durch die kombinierten Aspekte von Leistungsfaktoren gekennzeichnet, die auf einen oder mehrere Dienste anwendbar sind, wie beispielsweise Dienstoperabilitätsleistung, Dienstzugänglichkeitsleistung, Dienstbeibehaltungsfähigkeitsleistung, Dienstzuverlässigkeitsleistung, Dienstintegritätsleistung und andere Faktoren, die für jeden Dienst spezifisch sind. Mehrere verwandte Aspekte des Dienstes können berücksichtigt werden, wenn die QoS quantifiziert wird, einschließlich Paketverlustraten, Bitraten, Durchsatz, Übertragungsverzögerung, Verfügbarkeit, Zuverlässigkeit, Jitter, Signalstärke und/oder Qualitätsmessungen und/oder anderer Messungen, wie etwa der hierin erörterten.
Die Begriffe „Beamforming“ und „Strahllenkung“ verweisen mindestens bei einigen Ausführungsformen auf einen räumlichen Filtermechanismus, der an einem Sender (Tx) verwendet wird, um die empfangene Signalleistung, das Signal-Rausch-Verhältnis (SNR) oder irgendeine andere Signalgebungsmetrik an einem beabsichtigten Empfänger (Rx) zu verbessern. Der Begriff „Beamformer“ bezieht sich zumindest bei manchen Ausführungsformen auf eine STA, die eine PDU der physikalischen Schicht (PPDU) unter Verwendung einer Beamforming-Lenkmatrix überträgt. Der Begriff „Beamforming-Lenkmatrix“ verweist mindestens bei einigen Ausführungsformen auf eine Matrix, die unter Verwendung der Kenntnis des Kanals zwischen einem Tx und einem beabsichtigten Rx ermittelt wird, der von Raum-Zeit-Strömen auf Sendeantennen abgebildet ist, mit dem Ziel, die Signalleistung, das SNR, und/oder irgendeine andere Signalgebungsmetrik bei dem beabsichtigten Rx zu verbessern.
Der Begriff „Basisdienstgruppe“ oder „BSS“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Gruppe von STAs, die sich erfolgreich unter Verwendung der JOIN-Dienstprimitiven synchronisiert haben, und eine STA, die das START-Primitiv verwendet hat. Alternativ dazu eine Gruppe von STAs, die das START-Primitiv verwendet haben, das übereinstimmende Mesh-Profile spezifiziert, wobei die Übereinstimmung der Mesh-Profile über die Abtastprozedur verifiziert wurde. Die Mitgliedschaft an einer BSS impliziert nicht, dass eine drahtlose Kommunikation mit allen anderen Mitgliedern der BSS möglich ist.
Der Begriff „Koordinationsfunktion“ bezieht sich zumindest bei manchen Ausführungsformen auf eine logische Funktion, die bestimmt, wann eine STA PDUs über ein WM übertragen darf. Der Begriff „verteilte Koordinationsfunktion“ oder „DCF“ verweist mindestens bei einigen Ausführungsformen auf eine Klasse von Koordinationsfunktion(en), bei der in jeder STA einer Basisdienstgruppe (BSS) immer dann dieselbe Koordinationsfunktionslogik aktiv ist, wenn das Netzwerk in Betrieb ist. Der Begriff „Verteilungsdienst“ verweist mindestens bei einigen Ausführungsformen auf einen Dienst, der unter Verwenden von Assoziationsinformationen Medium-Access-Control-Diensttupel (MAC-Diensttupel) innerhalb eines Verteilungssystems (DS) liefert. Der Begriff „Verteilungssystem“ oder „DS“ verweist mindestens bei einigen Ausführungsformen auf ein System, das verwendet wird, um einen Satz von Basisdienstgruppen (BSS) und integrierten lokalen Netzwerken (LANs) miteinander zu verbinden, um eine erweiterte Dienstgruppe (ESS) zu erzeugen.
Der Begriff „Clear Channel Assessment-Funktion (CCA-Funktion)“ verweist mindestens bei einigen Ausführungsformen auf eine logische Funktion in der Bitübertragungsschicht (PHY), die den aktuellen Nutzungszustand eines WM bestimmt.
Die Begriffe „Instanziieren“, „Instantiierung“ und dergleichen verweisen mindestens bei einigen Ausführungsformen auf die Erzeugung einer Instanz. Eine „Instanz“ verweist mindestens bei einigen Ausführungsformen auch auf ein konkretes Auftreten eines Objekts, das zum Beispiel während der Ausführung von Programmcode auftreten kann. Der Begriff „Informationselement“ verweist mindestens bei einigen Ausführungsformen auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff „Feld“ verweist mindestens bei einigen Ausführungsformen auf individuelle Inhalte eines Informationselements oder eines Datenelements, das Inhalte enthält. Der Begriff „Datenbankobjekt“, „Datenstruktur“ oder dergleichen kann auf jede Darstellung von Informationen verweisen, die in Form eines Objekts, Attribut-Wert-Paars (AVP), Schlüssel-Wert-Paars (KVP), Tupels usw. vorliegen, und kann Variablen, Datenstrukturen, Funktionen, Verfahren, Klassen, Datenbankdatensätze, Datenbankfelder, Datenbankentitäten, Assoziationen zwischen Daten und/oder Datenbankentitäten (auch als „Beziehung“ bezeichnet), Blöcke und Verknüpfungen zwischen Blöcken in Blockchain-Umsetzungen und/oder dergleichen umfassen. Der Begriff „Datenelement“ oder „DE“ verweist mindestens bei einigen Ausführungsformen auf einen Datentyp, der ein einziges Datenstück enthält. Der Begriff „Datenframe“ oder „DF“ verweist mindestens bei einigen Ausführungsformen auf einen Datentyp, der mehr als ein Datenelement in einer vordefinierten Reihenfolge enthält.
Der Begriff „Datagramm“ verweist mindestens bei einigen Ausführungsformen auf eine Basisübertragungseinheit, die mit einem paketvermittelten Netzwerk assoziiert ist; ein Datagramm kann strukturiert sein, um Kopf- und Nutzdatenabschnitte aufzuweisen. Der Begriff „Datagramm“ kann mindestens bei einigen Ausführungsformen als „Dateneinheit“ oder dergleichen bezeichnet werden.
Der Begriff „Subframe“ verweist mindestens bei einigen Ausführungsformen auf ein Zeitintervall, in dem ein Signal signalisiert wird. Bei einigen Implementierungen ist ein Subframe gleich 1 Millisekunde (ms). Der Begriff „Zeitschlitz“ verweist mindestens bei einigen Ausführungsformen auf ein ganzzahliges Vielfaches aufeinanderfolgender Subframes. Der Begriff „Superframe“ verweist mindestens bei einigen Ausführungsformen auf ein Zeitintervall, das zwei Zeitschlitze umfasst.
Der Begriff „Interoperabilität“ verweist mindestens bei einigen Ausführungsformen auf die Fähigkeit von STAs, die ein Kommunikationssystem oder RAT nutzen, mit anderen STAs zu kommunizieren, die ein anderes Kommunikationssystem oder eine andere RAT nutzen. Der Begriff „Koexistenz“ verweist mindestens bei einigen Ausführungsformen auf das Teilen oder Zuordnen von Hochfrequenzressourcen unter STAs, die entweder Kommunikationssystem oder RAT verwenden.
Der Begriff „Zuverlässigkeit“ verweist mindestens bei einigen Ausführungsformen auf die Fähigkeit einer computerbezogenen Komponente (zum Beispiel Software, Hardware oder Netzwerkelement/Entität), konsistent eine gewünschte Funktion auszuführen und/oder gemäß einer Spezifikation zu arbeiten. Zuverlässigkeit im Kontext von Netzwerkkommunikationen (zum Beispiel „Netzwerkzuverlässigkeit“) kann auf die Fähigkeit eines Netzwerks zum Ausführen von Kommunikation verweisen. Netzwerkzuverlässigkeit kann auch die (oder ein Maß der) Wahrscheinlichkeit sein, dass eine spezifizierte Datenmenge von einer Quelle an ein Ziel (oder eine Senke) übermittelt wird.
Der Begriff „Benutzer“ im Kontext umkonfigurierbarer Funkgeräte/-Systeme verweist mindestens bei einigen Ausführungsformen auf eine abstrakte Darstellung einer beliebigen Instanz, die Befehlsanforderungen (zum Beispiel unter Verwenden der Dienste) an den Multifunkcomputer ausgibt. Drei Arten von Benutzern werden basierend auf der Art der verwendeten Dienste unterschieden: Administrator für Multifunkverwaltungsebene, Mobilitätsrichtlinienmanager für Steuerungsebene und Vernetzungsstapel für Benutzerebene.
Der Begriff „Anwendungsfall“ verweist zumindest bei einigen Ausführungsformen auf eine Beschreibung eines Systems aus der Perspektive eines Benutzers. Anwendungsfälle behandeln mitunter ein System als eine Blackbox, und die Interaktionen mit dem System, einschließlich Systemantworten, werden als von außerhalb des Systems wahrgenommen. Anwendungsfälle vermeiden typischerweise technischen Jargon und bevorzugen stattdessen die Sprache des Endnutzers oder Domänenfachmanns.
Der Begriff „Qualität“ verweist zumindest bei einigen Ausführungsformen auf eine Eigenschaft, einen Charakter, ein Attribut oder ein Merkmal als etwas Positives oder Negatives und/oder einen Vortrefflichkeitsgrad davon. Zusätzlich oder alternativ verweist der Begriff „Qualität“ zumindest bei einigen Ausführungsformen im Kontext von Datenverarbeitungssystemen auf einen Zustand qualitativer und/oder quantitativer Aspekte von Daten, Prozessen und/oder einigen anderen Aspekten von Datenverarbeitungssystemen.
Der Begriff „Anwendung“ kann auf ein Computerprogramm verweisen, das dazu ausgelegt ist, eine andere spezifische Aufgabe als eine, die sich auf den Betrieb des Computers selbst bezieht, auszuführen. Zusätzlich oder alternativ kann sich der Begriff „Anwendung“ auf eine vollständiges und einsetzbares Paket, eine Umgebung beziehen, um eine gewisse Funktion in einer Betriebsumgebung zu erreichen. Der Begriff „KI/ML-Anwendung“ oder dergleichen kann eine Anwendung sein, die einige KI/ML-Modelle und Beschreibungen auf Anwendungsebene enthält.
Der Begriff „maschinelles Lernen“ oder „ML“ verweist mindestens bei einigen Ausführungsformen auf die Verwendung von Computersystemen zur Optimierung eines Leistungskriteriums anhand beispielhafter (Trainings-)Daten und/oder vergangener Erfahrung. Bei ML werden Algorithmen zur Ausführung einer oder mehrerer spezifischer Aufgaben verwendet, ohne explizite Anweisungen zur Ausführung der einen oder mehreren spezifischen Aufgaben zu verwenden, sondern stattdessen auf Grundlage erlernter Muster und/oder Inferenzen. ML verwendet Statistiken, um ein oder mehrere mathematische Modelle (auch als „ML-Modelle“ oder einfach „Modelle“ bezeichnet) zu erstellen, um Vorhersagen oder Entscheidungen basierend auf Musterdaten (zum Beispiel Trainingsdaten) zu treffen. Das Modell ist definiert, einen Satz von Parametern aufzuweisen, und Lernen ist die Ausführung eines Computerprogramms zum Optimieren der Parameter des Modells unter Verwenden der Trainingsdaten oder der vergangenen Erfahrung. Das trainierte Modell kann ein prädiktives Modell, das Vorhersagen basierend auf einem Eingabedatensatz trifft, ein beschreibendes Modell, das Wissen aus einem Eingabedatensatz gewinnt, oder sowohl prädiktiv als auch beschreibend sein. Sobald das Modell erlernt (trainiert) ist, kann es verwendet werden, um Rückschlüsse (zum Beispiel Vorhersagen) zu treffen. ML-Algorithmen führen einen Trainingsprozess an einem Trainingsdatensatz aus, um ein zugrunde liegendes ML-Modell zu abzuschätzen. Ein ML-Algorithmus ist ein Computerprogramm, das aus Erfahrung in Bezug auf eine oder einige Aufgaben und eine oder einige Leistungsfähigkeitsmessungen/-metriken lernt, und ein ML-Modell ist ein Objekt oder eine Datenstruktur, das/die erzeugt wird, nachdem ein ML-Algorithmus mit Trainingsdaten trainiert wurde. Mit anderen Worten kann der Begriff „ML-Modell“ oder „Modell“ die Ausgabe eines ML-Algorithmus beschreiben, der mit Trainingsdaten trainiert wird. Nach dem Training kann ein ML-Modell verwendet werden, um Vorhersagen über neue Datensätze zu treffen. Zusätzlich können separat trainierte KI/ML-Modelle während der Inferenz- oder Prognoseerzeugung in einer KI/ML-Pipeline miteinander verkettet werden. Obwohl der Begriff „ML-Algorithmus“ mindestens bei einigen Ausführungsformen auf unterschiedliche Konzepte als den Begriff „ML-Modell“ verweist, können diese Begriffe austauschbar für die Zwecke der vorliegenden Offenbarung verwendet werden. ML-Techniken fallen im Allgemeinen in die folgenden Haupttypen von Lernproblemkategorien: überwachtes Lernen, unüberwachtes Lernen und bestärkendes Lernen.
Der Begriff „überwachtes Lernen“ verweist mindestens bei einigen Ausführungsformen auf eine ML-Technik, die darauf abzielt, eine Funktion zu erlernen oder ein ML-Modell zu erzeugen, das mit einem gegebenen gekennzeichneten Datensatz eine Ausgabe erzeugt. Überwachte Lernalgorithmen bauen Modelle aus einem Datensatz auf, der sowohl die Eingaben als auch die gewünschten Ausgaben enthält. Überwachtes Lernen beinhaltet zum Beispiel Lernen einer Funktion oder eines Modells, das eine Eingabe auf eine Ausgabe basierend auf beispielhaften Eingabe-Ausgabe-Paaren oder irgendeiner anderen Form von gekennzeichneten Trainingsdaten einschließlich eines Satzes von Trainingsbeispielen abbildet. Jedes Eingabe-Ausgabe-Paar beinhaltet ein Eingabeobjekt (zum Beispiel einen Vektor) und ein gewünschtes Ausgabeobjekt oder einen gewünschten Ausgabewert (als ein „Überwachungssignal“ bezeichnet). Überwachtes Lernen kann in Klassifikationsalgorithmen, Regressionsalgorithmen und instanzbasierte Algorithmen gruppiert werden.
Der Begriff „Klassifikation“ im Zusammenhang mit ML kann auf eine ML-Technik zum Ermitteln der Klassen verweisen, zu denen verschiedene Datenpunkte gehören. Hier kann der Begriff „Klasse“ oder „Klassen“ auf Kategorien verweisen, die mitunter als „Ziele“ oder „Kennzeichnungen“ bezeichnet. Eine Klassifizierung wird verwendet, wenn die Ausgaben auf einen begrenzten Satz quantifizierbarer Eigenschaften beschränkt sind. Klassifikationsalgorithmen können eine individuelle (Daten-)Instanz beschreiben, deren Kategorie unter Verwenden eines Merkmalsvektors vorhergesagt werden soll. Als ein Beispiel kann, wenn die Instanz eine Sammlung (einen Korpus) von Text beinhaltet, jedes Merkmal in einem Merkmalsvektor die Häufigkeit sein, mit der spezifische Wörter in dem Korpus von Text erscheinen. Bei der ML-Klassifizierung werden Kennzeichnungen zu Instanzen zugewiesen, und Modelle werden trainiert, um die zuvor zugewiesenen Kennzeichnungen aus den Trainingsbeispielen korrekt vorherzusagen. ML-Algorithmen zur Klassifizierung können als „Klassifikator“ bezeichnet werden. Beispiele für Klassifikatoren beinhalten lineare Klassifikatoren, k-Nearest-Neighbours (kNN), Entscheidungsbäume, Random Forests, Support Vector Machines (SVMs), bayessche Klassifikatoren, Faltungs-Neuronalnetzwerke (CNNs), unter vielen anderen (es wird angemerkt, dass einige dieser Algorithmen auch für andere ML-Aufgaben verwendet werden können).
Die Begriffe „Regressionsalgorithmus“ und/oder „Regressionsanalyse“ im Kontext von ML können auf eine Menge statistischer Prozesse zum Schätzen der Beziehungen zwischen einer abhängigen Variablen (oft als „Ergebnisvariable“ bezeichnet) und einer oder mehreren unabhängigen Variablen (oft als „Prädiktoren“, „Kovariate“ oder „Merkmale“ bezeichnet) verweisen. Beispiele für Regressionsalgorithmen/-modelle beinhalten logistische Regression, lineare Regression, Gradientenverfahren (GD), stochastisches GD (SGD) und dergleichen.
Die Begriffe „instanzbasiertes Lernen“ oder „speicherbasiertes Lernen“ im Kontext von ML können auf eine Familie von Lernalgorithmen verweisen, die anstelle einer expliziten Verallgemeinerung neue Probleminstanzen mit im Training betrachteten Instanzen vergleicht, die im Speicher gespeichert wurden. Beispiele für instanzbasierte Algorithmen beinhalten k-Nearest-Neighbour und dergleichen), Entscheidungsbaum-Algorithmen (zum Beispiel Classification And Regression Tree (CART), Iterative Dichotomiser 3 (ID3), C4.5, Chi-Square Automatic Interaction Detection (CHAID) usw.), Fuzzy Decision Tree (FDT), und dergleichen), Support Vector Machines (SVM), bayessche Algorithmen (zum Beispiel bayessches Netzwerk (BN), ein dynamisches BN (DBN), Naive Bayes und dergleichen) und Ensemble-Algorithmen (zum Beispiel Extreme Gradient Boosting, Voting Ensemble, Bootstrap-Aggregation („Bagging“), Random Forest und dergleichen.
Der Begriff „Merkmal“ bezeichnet im Zusammenhang mit ML eine individuelle messbare Eigenschaft, quantifizierbare Eigenschaft oder Charakteristik eines beobachteten Phänomens. Merkmale werden üblicherweise unter Verwenden von Zahlen/Ziffern (zum Beispiel Ganzzahlen), Zeichenketten, Variablen, Ordinalen, reellen Werten, Kategorien und/oder dergleichen repräsentiert. Ein Satz von Merkmalen kann als ein „Merkmalsvektor“ bezeichnet werden. Ein „Vektor“ kann sich auf ein Tupel aus einem oder mehreren Werten beziehen, die Skalare genannt werden, und ein „Merkmalsvektor“ kann ein Vektor sein, der ein Tupel aus einem oder mehreren Merkmalen beinhaltet.
Der Begriff „unüberwachtes Lernen“ verweist mindestens bei einigen Ausführungsformen auf eine ML-Technik, die darauf abzielt, eine Funktion zum Beschreiben einer verborgenen Struktur aus nicht gekennzeichneten Daten zu lernen. Unüberwachte Lernalgorithmen bauen Modelle aus einem Datensatz auf, der nur Eingaben und keine gewünschten Ausgabekennzeichnungen enthält. Unüberwachte Lernalgorithmen werden verwendet, um Struktur in den Daten zu finden, wie etwa Gruppieren oder Clustern von Datenpunkten. Beispiele für unüberwachtes Lernen sind unter vielen anderen K-Means-Clustering, Hauptkomponentenanalyse (HKA) und Themenmodellierung. Der Begriff „halbüberwachtes Lernen verweist mindestens bei einigen Ausführungsformen auf ML-Algorithmen, die ML-Modelle aus unvollständigen Trainingsdaten entwickeln, wobei ein Teil der Mustereingabe keine Kennzeichnungen beinhaltet.
Der Begriff „bestärkendes Lernen“ oder „RL“ verweist mindestens bei einigen Ausführungsformen auf eine zielorientierte Lerntechnik, die auf einer Interaktion mit einer Umgebung basiert. Bei RL zielt ein Agent darauf ab, ein Langzeitziel zu optimieren, indem er mit der Umgebung basierend auf einem systematischen Ausprobierprozess interagiert. Beispiele für RL-Algorithmen beinhalten Markov-Entscheidungsprozess, Markov-Kette, Q-Lernen, Lernen mit mehrarmigen Banditen und tiefgehendes RL. Der Begriff „Problem des mehrarmigen Banditen“, „Problem des K-armigen Banditen“, „Problem des N-armigen Banditen“ oder „kontextbezogener Bandit“ verweist mindestens bei einigen Ausführungsformen auf ein Problem, bei dem ein fest begrenzter Satz von Ressourcen zwischen konkurrierenden (alternativen) Auswahlmöglichkeiten auf eine Weise zugeordnet werden muss, die ihren erwarteten Gewinn maximiert, wenn die Eigenschaften jeder Auswahl zur Zeit der Zuweisung nur teilweise bekannt sind, und mit der Zeit oder durch Zuweisen von Ressourcen zur Auswahl besser verstanden werden können. Der Begriff „Problem des kontextbezogenen mehrarmigen Banditen“ oder „kontextbezogener Bandit“ verweist mindestens bei einigen Ausführungsformen auf eine Version eines mehrarmigen Banditen, bei der bei jeder Iteration ein Agent zwischen Armen auswählen muss; vor dem Treffen der Auswahl sieht der Agent einen d-dimensionalen Merkmalsvektor (Kontextvektor), der mit einer aktuellen Iteration assoziiert ist, der Lernende verwendet diese Kontextvektoren zusammen mit den Belohnungen der in der Vergangenheit gespielten Arme, um die Auswahl des Arms zu treffen, der in der aktuellen Iteration gespielt werden soll, und das Ziel des Lernenden besteht im Laufe der Zeit darin, genügend Informationen darüber zu sammeln, wie die Kontextvektoren und Belohnungen miteinander in Beziehung stehen, sodass es den nächstbesten Arm vorhersagen kann, der gespielt werden soll, indem man die Merkmalsvektoren betrachtet. Zusätzliche Aspekte von RL und Problemen mit mehrarmigen Banditen werden in Sutton et al., „Reinforcement Learning: An Introduction“, 2. Aufl., MIT Press (2018), besprochen.
Der Begriff „Belohnungsfunktion“ verweist im Kontext von RL mindestens bei einigen Ausführungsformen auf eine Funktion, die einen Belohnungswert basierend auf einer oder mehreren Belohnungsvariablen ausgibt; der Belohnungswert stellt eine Rückmeldung für eine RL-Strategie bereit, so dass ein RL-Agent ein wünschenswertes Verhalten lernen kann. Der Begriff „Belohnungsformen“ verweist im Kontext von RL mindestens bei einigen Ausführungsformen auf ein Anpassen oder Ändern einer Belohnungsfunktion, um eine positive Belohnung für wünschenswertes Verhalten und eine negative Belohnung für unerwünschtes Verhalten auszugeben.
Die Begriffe „künstliches neuronales Netz“, „neuronales Netz“ oder „NN“ verweisen auf eine ML-Technik, die eine Sammlung verbundener künstlicher Neuronen oder Knoten umfasst, die (in etwa) Neuronen in einem biologischen Gehirn modellieren, die Signale an andere arterielle Neuronen oder Knoten übertragen können, wobei Verbindungen (oder Kanten) zwischen den künstlichen Neuronen oder Knoten (in etwa) nach Synapsen eines biologischen Gehirns modelliert werden. Die künstlichen Neuronen und Kanten weisen typischerweise eine Gewichtung auf, die mit fortschreitendem Lernen angepasst wird. Die Gewichtung erhöht oder verringert die Stärke des Signals an einer Verbindung. Die Neuronen können eine Schwelle aufweisen, sodass ein Signal nur dann gesendet wird, wenn das aggregierte Signal diese Schwelle überschreitet. Die künstlichen Neuronen können in eine oder mehrere Schichten aggregiert oder gruppiert werden, wobei unterschiedliche Schichten unterschiedliche Transformationen an ihren Eingaben durchführen können. Signale laufen von der ersten Schicht (der Eingabeschicht) zur letzten Schicht (der Ausgabeschicht), möglicherweise nach mehrmaligem Durchlaufen der Schichten. NNs werden üblicherweise für überwachtes Lernen verwendet, können aber auch für unüberwachtes Lernen verwendet werden. Beispiele für NNs beinhalten ein tiefes NN (DNN), ein Feedforward-NN (FFN), ein tiefes FNN (DFF), ein faltendes NN (CNN), ein tiefes CNN (DCN), ein entfaltendes NN (DNN), ein Deep-Belief-NN, ein Perception-NN, ein rekurrentes NN (RNN) (zum Beispiel einschließlich Long Short Term Memory-Algorithmus (LSTM-Algorithmus), Gated Recurrent Unit (GRU), usw..), Deep Stacking Network (DSN).
Der Begriff „Sitzung“ verweist mindestens bei einigen Ausführungsformen auf einen temporären und interaktiven Informationsaustausch zwischen zwei oder mehr Kommunikationsvorrichtungen, zwei oder mehr Anwendungsinstanzen, zwischen einem Computer und einem Benutzer oder zwischen zwei oder mehr beliebigen Entitäten oder Elementen.
Der Begriff „Datennetzwerk“ oder „DN“ verweist mindestens bei einigen Ausführungsformen auf ein Netzwerk, das datenzentrische Dienste hostet, wie etwa zum Beispiel Betreiberdienste, das Internet, Dienste von Dritten oder Unternehmensnetzwerke. Zusätzlich oder alternativ verweist ein DN mindestens bei einigen Ausführungsformen auf Dienstnetzwerke, die einem Betreiber oder einer Drittpartei gehören, die einem Client oder einem Endgerät (UE) als ein Dienst angeboten werden. DNs werden mitunter als „Paketdatennetze“ oder „PDNs“ bezeichnet. Der Begriff „lokales Datennetz“ oder „LADN“ verweist mindestens bei einigen Ausführungsformen auf ein DN, auf das das UE nur an spezifischen Orten zugreifen kann, der Konnektivität mit einem spezifischen DNN bereitstellt und dessen Verfügbarkeit dem UE bereitgestellt wird.
Der Begriff „PDU-Konnektivitätsdienst“ verweist mindestens bei einigen Ausführungsformen auf einen Dienst, der einen Austausch von Protokolldateneinheiten (PDUs) zwischen einem UE und einem DN bereitstellt. Der Begriff „PDU-Sitzung“ verweist mindestens bei einigen Ausführungsformen auf eine Assoziation zwischen einem UE und einem DN, die einen PDU-Konnektivitätsdienst bereitstellt. Ein PDU-Sitzungstyp kann IPv4, IPv6, IPv4v6, Ethernet, unstrukturiert oder ein beliebiger anderer Netzwerk-/Verbindungstyp, wie etwa die hierin besprochenen, sein. Der Begriff „MA-PDU-Sitzung“ verweist mindestens bei einigen Ausführungsformen auf eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der gleichzeitig ein Zugangsnetzwerk oder mehrere Zugangsnetzwerke simultan verwenden kann.
Der Begriff „Verkehrsformen“ verweist mindestens bei einigen Ausführungsformen auf eine Bandbreitenverwaltungstechnik, die eine Datenübertragung verwaltet, um einem gewünschten Verkehrsprofil oder einer gewünschten Dienstklasse zu entsprechen. Das Verkehrsformen stellt eine ausreichende Netzwerkbandbreite für zeitsensitive kritische Anwendungen unter Verwendung von Richtlinienregeln, Datenklassifizierung, Warteschlangen, QoS und anderen Techniken sicher. Der Begriff „Drosseln“ verweist mindestens bei einigen Ausführungsformen auf die Regelung von Strömen in ein Netzwerk oder daraus heraus oder in eine spezifische Vorrichtung oder Element oder daraus heraus.
Der Begriff „Netzwerkadresse“ verweist mindestens bei einigen Ausführungsformen auf eine Kennung für einen Knoten oder Host in einem Computernetzwerk und kann eine eindeutige Kennung über ein Netzwerk hinweg und/oder für einen lokal verwalteten Teil des Netzwerks eindeutig sein. Beispiele für Netzwerkadressen beinhalten eine geschlossene Zugangsgruppenkennung (CAG-ID), eine Bluetooth-Hardwarevorrichtungsadresse (BDADDR), eine Mobilfunknetzadresse (z. B. einen Zugangspunktnamen (APN), eine AMF-Kennung (AMF-ID), eine AF-Dienstkennung, eine Edge-Anwendungsserver(EAS)-ID, eine Datennetzwerkzugangskennung (DNAI), einen Datennetzwerknamen (DNN), eine EPS-Trägerkennung (EBI), ein Geräteidentitätsregister (EIR) und/oder 5G-EIR, eine erweiterte eindeutige Kennung (EUI), eine Gruppen-ID zur Netzwerkauswahl (GIN), eine generische öffentliche Teilnehmerkennung (GPSI), eine globale eindeutige AMF-Kennung (GUAMI), eine globale eindeutige temporäre Kennung (GUTI) und/oder 5G-GUTI, eine International Mobile Equipment Identity (IMEI), einen IMEI-Typ-Zuordnungscode (IMEA/TAC), eine internationale Mobilfunk-Teilnehmerkennung (IMSI), eine lokale Datennetz(LADN)-DNN, eine mobile Teilnehmeridentifikationsnummer (MSIN), eine mobile Teilenhmer/Station-ISDN-Nummer (MSISDN), eine Netzwerkkennung (NID), eine Netzwerk-Slice-Instanz(NSI)-ID, Permanentgerätekennung (PEI), eine öffentliche terrestrische Mobilfunknetz(PLMN)-ID, eine QOS-Fluss-ID (QFI) und/oder 5G-QoS-Kennung (5QI), eine RAN-ID, einen Routing-Indikator, eine SMS-Funktions(SMSF)-ID, eine eigenständige nichtöffentliche Netzwerk(SNPN)-ID, eine verdeckte Teilnehmerkennung (SUCI), eine permanente Teilnehmerkennung (SUPI), eine temporäre mobile Teilnehmerkennung (TMSI) und Varianten davon, UE-Zugriffskategorie und -kennung und/oder andere mobilfunknetzbezogene Kennungen), eine E-Mail-Adresse, eine Unternehmensanwendungsserver(EAS)-ID, eine Endpunktadresse, einen elektronischen Produktcode (EPC), wie durch den EPCglobal Tag Data Standard definiert, einen Fully Qualified Domain Name (FQDN), eine Internet-Protocol(IP)-Adresse in einem IP-Netzwerk (z. B. IP-Version 4 (Ipv4), IP-Version 6 (IPv6) usw.), eine Internet-Packet-Exchange(IPX)-Adresse, eine ID eines lokalen Netzes (LAN), eine Media-Access-Control(MAC)-Adresse, eine ID eines persönlichen Netzwerks, eine Anschlussnummer (z. B. eine Transmission-Control-Protocol(TCP)-Anschlussnummer, eine User-Datagram-Protocol(UDP)-Anschlussnummer), eine QUIC-Verbindungs-ID, einen RFID-Tag, einen Service Set Identifier (SSID) und Varianten davon, Telefonnummern in einem öffentlichen Telefonnetz (PTSN), einen Universally Unique Identifier (UUID) (wie z. B. in ISO/IEC 11578:1996 spezifiziert), einen Uniform Resource Locator (URL) und/oder Uniform Resource Identifier (URI), eine virtuelle LAN(VLAN)-ID, eine X.21-Adresse, eine X.25-Adresse, eine Zigbee®-ID, eine Zigbee®-Vorrichtungsnetz-ID und/oder eine beliebige geeignete Netzwerkadresse oder Komponenten davon. Der Begriff „Anwendungskennung“, „Anwendungs-ID“ oder „App-ID“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Kennung, die auf eine spezifische Anwendung oder Anwendungsinstanz abgebildet werden kann; im Kontext von 3GPP-5G/NR-Systemen kann sich eine „Anwendungskennung“ auf eine Kennung beziehen, die auf eine spezifische Anwendungsverkehrsdetektionsregel abgebildet werden kann. Eine „Endpunktadresse“ kann sich auf eine Adresse beziehen, die verwendet wird, um den Host/Autoritätsteil eines Ziel-URI zu ermitteln, wobei der Ziel-URI verwendet wird, um auf einen NF-Dienst (z. B. um Dienstoperationen aufzurufen) eines NF-Diensterzeuger oder für Benachrichtigungen an einen NF-Dienstverbraucher zuzugreifen. Der Begriff „CAG-ID“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Kennung einer geschlossenen Zugangsgruppe (CAG) und der Begriff „geschlossene Zugangsgruppe“ oder „CAG“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Gruppe von Listen von Benutzern, denen es erlaubt ist, sich mit einem spezifischen Netzwerk, einem spezifischen Zugangsnetzwerk zu verbinden und/oder darauf zuzugreifen und/oder an eine spezifische Zelle oder einen spezifischen Netzwerkzugangsknoten anzubinden. Geschlossene Zugangsgruppen (CAGs) werden manchmal als Zugangskontrolllisten (ACLs), geschlossene Teilnehmergruppen (CSGs), geschlossene Benutzergruppen (CUGs) und dergleichen bezeichnet. Der Begriff „Anschluss“, wie hier verwendet (z. B. im Kontext von Computernetzen), bezieht sich zumindest bei manchen Ausführungsformen auf einen Kommunikationsendpunkt, eine virtuelle Datenverbindung zwischen zwei oder mehr Entitäten und/oder einen virtuellen Punkt, an dem Netzwerkverbindungen beginnen und enden; zusätzlich oder alternativ dazu ist ein „Anschluss“ mit einem spezifischen Prozess oder Dienst assoziiert.
Der Begriff „Subnetzwerk“ oder „Subnetz“ bezieht sich zumindest bei manchen Ausführungsformen auf eine logische Unterteilung eines Netzwerks, wie etwa eines IP-Netzwerks. Die Praxis, ein Netzwerk in zwei oder mehr Netzwerke aufzuteilen, wird als „Subnetting“ bezeichnet. Der Begriff „Netzmaske“ oder „Subnetzmaske“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Bitmaske, die durch bitweise UND-Operationen auf eine Netzwerkadresse (z. B. eine IP-Adresse in einem IP-Netzwerk) angewendet wird, um ein Routing-Präfix zu erhalten, und/oder ist eine 32-Bit-„Maske“, die verwendet wird, um eine IP-Adresse in Subnetze aufzuteilen und die verfügbaren Hosts des Netzwerks zu spezifizieren.
Der Begriff „kryptographische Hashfunktion“, „Hashfunktion“ oder „Hash“ verweist zumindest bei manchen Ausführungsformen auf einen mathematischen Algorithmus, der Daten beliebiger Größe (manchmal als eine „Nachricht“ bezeichnet) auf ein Bitarray einer festen Größe (manchmal als ein „Hashwert“, „Hash“ oder „Nachrichtendigest“ bezeichnet) abbildet. Eine kryptographische Hash-Funktion ist üblicherweise eine Einwegfunktion, die eine Funktion ist, die praktisch nicht invertierbar ist. Der Begriff „Integrität“ bezieht sich zumindest bei manchen Ausführungsformen auf einen Mechanismus, der sicherstellt, dass Daten nicht ungenehmigt geändert wurden. Beispiele für kryptographische Mechanismen, die zum Integritätsschutz verwendet werden können, beinhalten digitale Signaturen, Nachrichtenauthentifizierungscodes (MAC) und sichere Hashes.
Der Begriff „Fluss“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Sequenz von Daten und/oder Dateneinheiten (z. B. Datagramme, Pakete oder dergleichen) von einer Quellenentität/einem Quellenelement zu einer Zielentität/einem Zielelement. Zusätzlich oder alternativ beziehen sich die Begriffe „Fluss“ oder „Verkehrsfluss“ zumindest bei manchen Ausführungsformen auf ein künstliches und/oder logisches Äquivalent zu einem Anruf, einer Verbindung oder einer Verknüpfung. Zusätzlich oder alternativ beziehen sich die Begriffe „Fluss“ oder „Verkehrsfluss“ zumindest bei manchen Ausführungsformen auf eine Sequenz von Paketen, die von einer bestimmten Quelle zu einem bestimmten Unicast-, Anycast- oder Multicastziel gesendet werden, die die Quelle als einen Fluss kennzeichnen möchte; von einem Gesichtspunkt einer oberen Schicht kann ein Fluss alle Pakete in einer spezifischen Transportverbindung oder einem Medienstrom beinhalten, jedoch ist ein Fluss nicht notwendigerweise 1:1 auf eine Transportverbindung abgebildet. Zusätzlich oder alternativ verweisen die Begriffe „Fluss“ oder „Verkehrsfluss“ zumindest bei manchen Ausführungsformen auf einen Satz von Daten und/oder Dateneinheiten (z. B. Datagramme, Pakete oder dergleichen), die einen Beobachtungspunkt in einem Netzwerk während eines gewissen Zeitintervalls passieren. Zusätzlich oder alternativ verweist der Begriff „Fluss“ zumindest bei manchen Ausführungsformen auf eine Datenverknüpfung auf Benutzerebene, die an eine Assoziation angehängt ist. Beispiele sind leitungsvermittelter Telefonanruf, Voiceover-IP-Anruf, Empfang einer SMS, Senden einer Kontaktkarte, PDP-Kontext für Internetzugang, Demultiplexen eines TV-Kanals aus einem Kanalmultiplex, Berechnen von Positionskoordinaten aus Geopositionierungssatellitensignalen usw. Für Zwecke der vorliegenden Offenbarung können die Begriffe „Verkehrsfluss“, „Daten-Fluss“, „Datenfluss“, „Paketfluss“, Netzwerkfluss und/oder „Fluss“ austauschbar verwendet werden, obwohl sich diese Begriffe auf unterschiedliche Konzepte beziehen können.
Der Begriff „Datenstrom“ bezieht sich zumindest in manchen Ausführungsformen auf eine Sequenz von Datenelementen, die über die Zeit zur Verfügung gestellt werden. Funktionen, die einen Datenstrom bearbeiten, was einen anderen Datenstrom erzeugen kann, werden zumindest bei manchen Ausführungsformen als „Filter“ bezeichnet und können analog zur Funktionszusammensetzung in Pipelines geschaltet werden. Filter können jeweils an einem Element eines Datenstroms arbeiten oder können ein Ausgabeelement auf mehreren Eingabeelementen basieren, wie etwa einem gleitenden Mittelwert.
Der Begriff „verteilte Berechnungen“ bezieht sich zumindest in manchen Ausführungsformen auf ein Modell, in dem Komponenten, die sich auf vernetzten Computern befinden, kommunizieren und ihre Aktionen koordinieren, indem sie Nachrichten weiterleiten, die miteinander interagieren, um ein gemeinsames Ziel zu erreichen.
Der Begriff „Mikrodienst“ bezieht sich zumindest bei manchen Ausführungsformen auf einen oder mehrere Prozesse, die über ein Netzwerk kommunizieren, um ein Ziel unter Verwendung technologieagnostischer Protokolle (z. B. HTTP oder dergleichen) zu erfüllen. Zusätzlich oder alternativ bezieht sich der Begriff „Mikrodienst“ zumindest bei manchen Ausführungsformen auf Dienste, die relativ klein in der Größe, nachrichtenfähig, durch Kontexte begrenzt, autonom entwickelt, unabhängig bereitstellbar, dezentral und/oder mit automatisierten Prozessen aufgebaut und freigegeben sind. Zusätzlich oder alternativ bezieht sich der Begriff „Mikrodienst“ zumindest bei manchen Ausführungsformen auf ein in sich geschlossenes Stück an Funktionalität mit klaren Schnittstellen, das eine Schichtarchitektur durch seine eigenen internen Komponenten implementieren kann. Der Begriff „Mikrodienstarchitektur“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Variante des strukturellen Typs der dienstorientierten Architektur (SOA), wobei Anwendungen als eine Sammlung lose gekoppelter Dienste (z. B. feinkörnige Dienste) angeordnet sind und leichtgewichtige Protokolle verwenden können.
Der Begriff „Time to Live“ (oder „TTL“) oder „Hop-Grenze“ bezieht sich zumindest bei manchen Ausführungsformen auf einen Mechanismus, der die Lebensdauer oder Lebenszeit von Daten in einem Computer oder Netzwerk begrenzt. TTL kann als ein Zähler oder Zeitstempel implementiert sein, der an die Daten angehängt oder in diese eingebettet ist. Sobald die vorgeschriebene Ereigniszählung oder Zeitspanne abgelaufen ist, werden Daten verworfen oder erneut validiert.
Der Begriff „Warteschlange“ verweist zumindest bei manchen Ausführungsformen auf eine Sammlung von Entitäten (z. B. Daten, Objekte, Ereignisse usw.), die gespeichert und gehalten werden, um später verarbeitet zu werden, die in einer Sequenz beibehalten werden und durch das Hinzufügen von Entitäten an einem Ende der Sequenz und das Entfernen von Entitäten von dem anderen Ende der Sequenz modifiziert werden können; das Ende der Sequenz, an der Elemente hinzugefügt werden, kann als „hinten“, „Ende“ oder „Rückseite“ der Warteschlange bezeichnet werden, und das Ende, an dem Elemente entfernt werden, kann als „Kopf“ oder „vorne“ der Warteschlange bezeichnet werden. Zusätzlich dazu kann eine Warteschlange die Funktion eines Puffers durchführen und die Begriffe „Warteschlange“ und „Puffer“ können in der gesamten vorliegenden Offenbarung austauschbar verwendet werden. Der Begriff „Einreihen in eine Warteschlange“ bezieht sich zumindest bei manchen Ausführungsformen auf eine oder mehrere Operationen des Hinzufügens eines Elements zum Ende einer Warteschlange. Der Begriff „Entfernen aus der Warteschlange“ bezieht sich zumindest bei manchen Ausführungsformen auf eine oder mehrere Operationen zum Entfernen eines Elements von der Vorderseite einer Warteschlange.
Der Begriff „Warteschlangenverzögerung“ bezieht sich zumindest bei manchen Ausführungsformen auf eine Zeitdauer, in der ein Job in einer Warteschlange wartet, bis dieser Job ausgeführt werden kann. Zusätzlich oder alternativ verweist der Begriff „Warteschlangenverzögerung“ mindestens bei einigen Ausführungsformen auf eine Zeitdauer, während der ein Paket in einer Warteschlange wartet, bis es verarbeitet und/oder übertragen werden kann. Der Begriff „Paketverzögerung“ verweist mindestens bei einigen Ausführungsformen auf die Zeit, die benötigt wird, um ein beliebiges Paket von einem Punkt zu einem anderen zu übertragen. Zusätzlich oder alternativ verweist der Begriff „Paketverzögerung“ oder „Verzögerung pro Paket“ mindestens bei einigen Ausführungsformen auf die Differenz zwischen einer Paketempfangszeit und einer Paketübertragungszeit. Zusätzlich oder alternativ kann die „Paketverzögerung“ oder „Verzögerung pro Paket“ gemessen werden, indem die Paketsendezeit von der Paketempfangszeit subtrahiert wird, zu der der Sender und der Empfänger mindestens etwas synchronisiert sind. Der Begriff „Verarbeitungsverzögerung“ verweist mindestens bei einigen Ausführungsformen auf eine Zeitdauer, die benötigt wird, um ein Paket in einem Netzwerkknoten zu verarbeiten. Der Begriff „Übertragungsverzögerung“ verweist mindestens bei einigen Ausführungsformen auf eine Zeitdauer, die benötigt wird (oder notwendig ist), um ein Paket (oder alle Bits eines Pakets) in ein Übertragungsmedium zu pushen. Der Begriff „Propagationsverzögerung“ verweist mindestens bei einigen Ausführungsformen auf die Zeitdauer, die der Kopf eines Signals benötigt, um sich von einem Sender zu einem Empfänger zu bewegen. Der Begriff „Netzwerkverzögerung“ verweist mindestens bei einigen Ausführungsformen auf die Verzögerung einer Dateneinheit innerhalb eines Netzwerks (zum Beispiel eines IP-Pakets innerhalb eines IP-Netzwerks).
Der Begriff „Verzögerungsgrenze“ verweist mindestens bei einigen Ausführungsformen auf einen vorbestimmten oder konfigurierten akzeptablen Verzögerungsbetrag. Der Begriff „Verzögerungsgrenze pro Paket“ verweist mindestens bei einigen Ausführungsformen auf einen vorbestimmten oder konfigurierten akzeptablen Verzögerungsbetrag, wobei Pakete, die nicht innerhalb der Verzögerungsgrenze verarbeitet und/oder übertragen werden, als Lieferausfälle betrachtet werden und verworfen oder fallen gelassen werden.
Der Begriff „Paketverwerfungsrate“ verweist mindestens bei einigen Ausführungsformen auf einen Anteil von Paketen, die aufgrund hoher Verkehrslast oder Verkehrsverwaltung nicht an das Ziel gesendet wurden und als Teil der Paketverlustrate angesehen werden sollte. Der Begriff „Paketverlustrate“ verweist mindestens bei einigen Ausführungsformen auf einen Anteil von Paketen, die von dem Ziel nicht empfangen werden konnten, einschließlich Paketen, die verworfen werden, Paketen, die bei der Übertragung verloren gehen, und Paketen, die in falschem Format empfangen werden. Der Begriff „Latenz“ verweist mindestens bei einigen Ausführungsformen auf die Zeitdauer, die benötigt wird, um eine erste/anfängliche Dateneinheit in einem Daten-Burst von einem Punkt zu einem anderen zu übertragen.
Der Begriff „Leistungsfähigkeitsindikator“ verweist mindestens bei einigen Ausführungsformen auf über eine Gruppe von Netzwerkfunktionen (NFs) aggregierte Leistungsfähigkeitsdaten, die aus an den NFs, die zu der Gruppe gehören, gesammelten Leistungsfähigkeitsmessungen gemäß dem in einer Leistungsfähigkeitsindikator-Definition identifizierten Aggregationsverfahren abgeleitet werden.
Der Begriff „physische Rate“ oder „PHY-Rate“ verweist mindestens bei einigen Ausführungsformen auf eine Geschwindigkeit, mit der ein oder mehrere Bits tatsächlich über ein Übertragungsmedium gesendet werden. Zusätzlich oder alternativ verweist der Begriff „physische Rate“ oder „PHY-Rate“ mindestens bei einigen Ausführungsformen auf eine Geschwindigkeit, mit der sich Daten über eine drahtlose Verbindung zwischen einem Sender und einem Empfänger bewegen können.
Der Begriff „Durchsatz“ oder „Netzdurchsatz“ verweist mindestens bei einigen Ausführungsformen auf eine Produktionsrate oder die Rate, mit der etwas verarbeitet wird. Zusätzlich oder alternativ verweist der Begriff „Durchsatz“ oder „Netzwerkdurchsatz“ mindestens bei einigen Ausführungsformen auf eine Rate einer erfolgreichen Nachricht-Lieferung (Datum-Lieferung) über einen Kommunikationskanal. Der Begriff „Goodput“ verweist mindestens bei einigen Ausführungsformen auf eine Anzahl von nützlichen Informationsbits, die von dem Netzwerk an ein bestimmtes Ziel pro Zeiteinheit geliefert werden.
Obwohl viele der vorherigen Beispiele unter Verwendung spezifischer Mobilfunk-/Mobilnetzwerkterminologie bereitgestellt sind, einschließlich unter Verwendung von 4G/5G-3GPP-Netzwerkkomponenten (oder erwarteten terahertzbasierten 6G/6G+-Technologien), versteht es sich, dass diese Beispiele auf viele andere Anwendungen von Fern- und lokalen drahtlosen Netzwerken sowie die Integration von drahtgebundenen Netzwerken (einschließlich optischer Netzwerke und assoziierter Fasern, Sendeempfängern usw.) angewendet werden können. Ferner können verschiedene Standards (z. B. 3GPP, ETSI usw.) verschiedene Nachrichtenformate, PDUs, Container, Frames usw. als eine Sequenz von optionalen oder obligatorischen Datenelementen (DEs), Datenframe (DFs), Informationselementen (IEs) und/oder dergleichen umfassend definieren. Es versteht sich jedoch, dass die Anforderungen eines beliebigen bestimmten Standards die hierin besprochenen Ausführungsformen nicht einschränken sollten und daher eine beliebige Kombination von Containern, Frames, DFs, DEs, IEs, Werten, Aktionen und/oder Merkmalen in verschiedenen Ausführungsformen möglich ist, einschließlich einer beliebigen Kombination von Containern, DEs, Werten, Aktionen und/oder Merkmalen, die streng befolgt werden müssen, um derartige Standards einzuhalten, oder einer beliebigen Kombination von Containern, Frames, DFs, DEs, IEs, Werten, Aktionen und/oder Merkmalen, die stark empfohlen werden und/oder mit oder in Anwesenheit/Abwesenheit optionaler Elemente verwendet werden.
Obwohl diese Implementierungen unter Bezugnahme auf spezifische beispielhafte Aspekte beschrieben wurden, versteht es sich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzbereich der vorliegenden Offenbarung abzuweichen. Viele der hierin beschriebenen Anordnungen und Prozesse können in Kombination oder in parallelen Implementierungen verwendet werden, um eine größere Bandbreite/einen größeren Durchsatz bereitzustellen und Edge-Dienstauswahlen zu unterstützen, die den zu bedienenden Edge-Systemen zur Verfügung gestellt werden können. Die Beschreibung und Zeichnungen sollen dementsprechend in einem illustrierenden Sinn statt in einem einschränkenden Sinn betrachtet werden. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen zur Veranschaulichung und nicht zur Einschränkung spezifische Aspekte, in denen der Gegenstand umgesetzt werden kann. Die veranschaulichten Aspekte sind hinreichend ausführlich beschrieben, um es Fachleuten zu ermöglichen, die hierin offenbarten Lehren umzusetzen. Andere Aspekte können genutzt und daraus abgeleitet werden, sodass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Diese ausführliche Beschreibung ist daher nicht in einem einschränkenden Sinne aufzufassen und der Schutzumfang verschiedener Aspekte wird nur durch die angehängten Ansprüche gemeinsam mit dem vollen Bereich von Äquivalenten, auf die derartige Ansprüche Anspruch haben, definiert.
Auf derartige Aspekte des Erfindungsgegenstands kann hierin einzeln und/oder kollektiv, lediglich der Einfachheit halber und ohne die Absicht, den Schutzumfang dieser Anmeldung willentlich auf einen einzigen Aspekt oder Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart ist, Bezug genommen werden. Obwohl hierin spezifische Aspekte dargestellt und beschrieben wurden, versteht sich daher, dass eine beliebige Anordnung, die berechnet wurde, um den gleichen Zweck zu erreichen, die gezeigten spezifischen Aspekte ersetzen kann. Diese Offenbarung soll beliebige und alle Anpassungen oder Variationen verschiedener Aspekte abdecken. Kombinationen der obigen Aspekte und anderer hier nicht spezifisch beschriebener Aspekte werden für Fachleute beim Überprüfen der obigen Beschreibung offensichtlich sein.
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 63/164440 [0001]
US 63/165011 [0001]
US 63/165015 [0001]
US 2020/066969 PCT [0007]
US 63003834 [0061]

Claims

Verfahren zum Bereitstellen von auf bestärkendem Lernen (RL) basierenden Verkehrsverwaltungsstrategien, wobei das Verfahren umfasst: Sammeln von Beobachtungsdaten von einer oder mehreren Datenquellen innerhalb einer Umgebung; Ermitteln eines Zustands der Umgebung auf Grundlage der gesammelten Beobachtungsdaten; und Betreiben eines Modells für bestärkendes Lernen (RLM) zum Ermitteln einer oder mehrerer Aktionen auf Grundlage des ermittelten Zustands, wobei: die eine oder die mehreren ermittelten Aktionen jeweilige Verkehrsverwaltungsstrategien für entsprechende Mehrfachzugriffs-UEs beinhalten, wobei jede der jeweiligen Verkehrsverwaltungsstrategien eine Verkehrslenkungsstrategie und/oder eine Verkehrsaufteilungsstrategie beinhaltet, und wobei die eine oder die mehreren Aktionen bewirken sollen, dass die entsprechenden Mehrfachzugriffs-UEs eine oder mehrere Operationen in Übereinstimmung mit den jeweiligen Verkehrsverwaltungsstrategien durchführen.
Verfahren nach Anspruch 1, wobei das eine oder die mehreren UEs konfigurierte Agenten sind, die mit der Umgebung interagieren, um Beobachtungsdaten zu sammeln, und das Betreiben des RLM zur Ermittlung der einen oder der mehreren Aktionen umfasst: Erhalten von Aktionsdaten mit den Beobachtungsdaten, wobei die Aktionsdaten eine oder mehrere andere von den entsprechenden Mehrfachzugriffs-UEs vorgenommene Aktionen beinhalten; Trainieren des RLM auf Grundlage der Beobachtungsdaten und der Aktionsdaten; und Bereitstellen des RLM an die entsprechenden Mehrfachzugriffs-UEs, wobei das bereitgestellte RLM zur Ableitung der Aktionen durch die entsprechenden Mehrfachzugriffs-UEs dient, wobei die entsprechenden Mehrfachzugriffs-UEs das bereitgestellte RLM verwenden, um die jeweiligen Verkehrsverwaltungsstrategien gemäß ihren individuell gesammelten Beobachtungen aus Interaktionen mit der Umgebung unabhängig vorherzusagen.
Verfahren nach Anspruch 2, ferner umfassend: Berechnen eines Belohnungswerts basierend auf den gesammelten Beobachtungsdaten; Aktualisieren des RLM basierend auf dem berechneten Belohnungswert; und Verteilen des aktualisierten RLM an die entsprechenden Mehrfachzugriffs-UEs, wenn das aktualisierte RLM einen Verifizierungsprozess besteht.
Verfahren nach Anspruch 1, wobei das Betreiben des RLM zur Ermittlung der einen oder der mehreren Aktionen umfasst: Betreiben eines Repräsentationsnetzes, um basierend auf den gesammelten Beobachtungsdaten eine Repräsentation der Umgebung zu generieren; Betreiben eines Kritiknetzes, um eine Rückmeldung für die eine oder die mehreren Aktionen zu ermitteln; und Betreiben eines Aktornetzes, um die eine oder die mehreren Aktionen basierend auf der erzeugten Repräsentation und der Rückmeldung vom Kritiknetz zu ermitteln.
Verfahren nach Anspruch 4, wobei die Rückmeldung eines oder beides von Folgendem beinhaltet: einen Zustandswert der einen oder der mehreren Aktionen von einer Zustandswertfunktion, einen Qualitätswert (Q-Wert) der einen oder der mehreren Aktionen von einer Q-Wertfunktion; und eine Wahrscheinlichkeitsverteilung der einen oder mehreren Aktionen mit einer erwarteten Rückgabe vom ermittelten Zustand.
Verfahren nach den Ansprüchen 4-5, wobei das Repräsentationsnetz ein rekurrentes neuronales Netz (RNN) umfasst und das Betreiben des Repräsentationsnetzes umfasst: Betreiben des RNN zum Lernen der Repräsentation für die entsprechenden Mehrfachzugriffs-UEs basierend auf Eingaben mit variablen Größen.
Verfahren nach den Ansprüchen 4-6, wobei: das Kritiknetz ein RNN umfasst, das dazu ausgelegt ist, eine Messsequenzkorrelation zur Ermittlung der Rückmeldung zu lernen; und das Aktornetz ein RNN umfasst, das dazu ausgelegt ist, eine Messsequenzkorrelation zur Ermittlung der einen oder mehreren Aktionen zu lernen.
Verfahren nach Anspruch 7, wobei das RNN des Repräsentationsnetzes ein Long-Short-Term-Memory(LSTM)-Netz ist, das RNN des Kritiknetzes ein LSTM-Netz ist oder das RNN des Aktornetzes ein LSTM ist.
Verfahren nach Anspruch 1, ferner umfassend: Kommunizieren der einen oder der mehreren Aktionen an die entsprechenden Mehrfachzugriffs-UEs.
Verfahren nach den Ansprüchen 1-9, ferner umfassend: Auslösen der einen oder der mehreren Datenquellen innerhalb der Umgebung, um die Beobachtungsdaten bereitzustellen, wenn eine Auslösebedingung erfüllt ist, wobei die Auslösebedingung ein Ablaufen eines Zeitgebers und/oder ein Erreichen eines Schwellenwerts durch einen Messwert beinhaltet.
Verfahren nach Anspruch 10, wobei die eine oder die mehreren Datenquellen ein oder mehrere Mehrfachzugriffs-UEs und/oder einen oder mehrere Netzwerkzugangsknoten (NANs) beinhalten.
Verfahren nach den Ansprüchen 1-11, ferner umfassend: Betreiben des RLM zum Lernen der jeweiligen Verkehrsverwaltungsstrategien, ohne auf Optimierungsmodelle oder vordefinierte Richtlinien angewiesen zu sein.
Verfahren nach den Ansprüchen 4-12, ferner umfassend: Berechnen des Belohnungswerts unter Verwendung einer Belohnungsfunktion basierend auf den gesammelten Beobachtungsdaten.
Verfahren nach Anspruch 13, ferner umfassend: Trainieren des Aktornetzes unter Verwendung eines Richtliniengradienten, um die Belohnungsfunktion zu maximieren, wobei der Richtliniengradient durch das Kritiknetz erzeugt wird; und Trainieren des Repräsentationsnetzes unter Verwendung des Richtliniengradienten.
Verfahren nach den Ansprüchen 13-14, wobei die Belohnungsfunktion eine Hilfsfunktion eines Netzwerk-Dienstqualitätsziels (QoS-Ziels) ist, wobei Eingaben in die Hilfsfunktion einen oder mehrere QoS-Parameter beinhalten, wobei der eine oder die mehreren QoS-Parameter eines oder mehrere von Paketverzögerung, Paketverlustrate, Paketverwerfungsrate, physische (PHY) Rate, Goodput, UE-Durchsatz, Zellendurchsatz, Jitter, Alpha-Fairness, Kanalqualitätsindikator(CQI)-bezogene Messwerte, Modulationscodierungsschema(MCS)-bezogene Messwerte, physische Ressourcenblock(PRB)-Nutzung, Funknutzungspegel pro NAN und Datenvolumen beinhalten.
Verfahren nach den Ansprüchen 1-15, wobei das RLM ein RL-Agent ist und der RL-Agent einen oder mehrere Leistungsfähigkeitszusicherungsmechanismen umfasst, wobei der eine oder die mehreren Leistungsfähigkeitszusicherungsmechanismen einen Mechanismus für gelenkte Erkundung, einen Mechanismus zum Erzwingen eines sicheren Aktionsraums, einen Frühwarnmechanismus und einen opportunistischen Erkundungssteuerungs(OEC)-Mechanismus beinhalten.
Verfahren nach Anspruch 16, wobei der Mechanismus für gelenkte Erkundung einen oder mehrere regelbasierte Algorithmen, einen oder mehrere modellbasierte heuristische Algorithmen oder einen oder mehrere vortrainierte Algorithmen für maschinelles Lernen beinhaltet und wobei der ESAS-Mechanismus einen akzeptablen Aktionsbereich oder einen Satz von Einschränkungen umfasst, die durch eine oder mehrere lineare oder nichtlineare Funktionen der einen oder der mehreren Aktionen beschrieben werden.
Verfahren nach den Ansprüchen 16-17, ferner umfassend: Betreiben des Frühwarnmechanismus, um eine Implementierung eines Reservemodells auszulösen, wenn eine oder mehrere Leistungsfähigkeitsmetriken einen entsprechenden Schwellenwert erfüllen oder überschreiten, wobei die eine oder die mehreren Leistungsfähigkeitsmetriken einen Mittelwert einer Einwegeverzögerung für einen oder mehrere Datenflüsse, einen Mittelwert der durchgehenden (e2e)-Verzögerung für einen oder mehrere Datenflüsse, einen Verzögerungsschwankungstrend, eine Pufferakkumulation; einen Kanalqualitätsindikator(CQI)-Schwankungstrend; und eine Modulation und einen Codierungsschema(MCS)-Verteilungstrend beinhalten.
Verfahren nach den Ansprüchen 16-18, ferner umfassend: Betreiben des OEC-Mechanismus, um eine oder mehrere risikoreiche Aktionen der einen oder der mehreren Aktionen zu identifizieren, und Anwenden der einen oder der mehreren risikoreichen Aktionen, um Flüsse oder Flüsse mit weniger strengen QoS-Zielen als andere Flüsse zu testen.
Verfahren nach den Ansprüchen 13-15, wobei das RLM ein Maschinenlernmodell mit kontextbezogenen Banditen ist und das Verfahren umfasst: zufälliges Initialisieren des Kritiknetzes, des Aktornetzes und des Repräsentationsnetzes mit Parametern θ^Q, θ^µ bzw. θ^E; Initialisieren eines Wiedergabepuffers; und Initialisieren eines Zufallsprozesses zur Aktionserkundung.
Verfahren nach Anspruch 20, ferner umfassend: Betreiben des Repräsentationsnetzes, um eine Repräsentation der Beobachtungsdaten für ein Ziel-UE zu erhalten, dem eine Aktionsempfehlung bereitgestellt werden soll, wobei das Ziel-UE zu den entsprechenden Mehrfachzugriffs-UEs gehört; Betreiben des Aktornetzes, um eine Aktion in Übereinstimmung mit einer aktuellen Richtlinie und einem Erkundungsrauschen auszuwählen und die ausgewählte Aktion auf dem Ziel-UE bereitzustellen; Kassieren einer Belohnung basierend auf der Durchführung der ausgewählten Aktion; und Speichern der Aktion, des Zustands und der kassierten Belohnung in dem Wiedergabepuffer.
Verfahren nach Anspruch 21, wobei das Auswählen der Aktion umfasst: zufälliges Abtasten eines Aktionsraums für die Aktion unter Verwendung einer Wahrscheinlichkeit oder unter Verwendung eines existierenden heuristischen Algorithmus zum Auswählen der Aktion; zufälliges Abtasten eines Minibatchs aus dem Wiedergabepuffer; und Ermitteln eines Ziels für eine zeitliche Differenzfehlerberechnung aus der kassierten Belohnung.
Verfahren nach Anspruch 22, ferner umfassend: Trainieren des Aktornetzes unter Verwendung eines Richtliniengradienten, um die Belohnungsfunktion zu maximieren; und Trainieren des Kritiknetzes, um eine Verlustfunktion zu minimieren.
Verfahren nach den Ansprüchen 1-23, wobei die Beobachtungsdaten eines oder mehrere von Paketverzögerung, Paketverlustrate, Paketverwerfungsrate, PHY-Rate, Goodput, UE-Durchsatz, Zellendurchsatz, Jitter, Alpha-Fairness, CQI-bezogenen Messwerten, MCSbezogenen Messwerten, PRB-Nutzung, Funknutzungspegel pro NAN und Datenvolumen beinhalten.
Edge-Rechenknoten, der eine Schaltungsanordnung umfasst, die dazu ausgelegt ist, das Verfahren nach einem oder mehreren der Ansprüche 1-24 durchzuführen, wobei der Edge-Rechenknoten ein Mehrfachzugriffs-Edge-Rechenserver/-Host oder eine intelligente Funkzugangsnetz(RAN)-Steuerung (RIC) der Open RAN Alliance (O-RAN) ist.
Computerlesbares Medium oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei eine Ausführung der Anweisungen durch eine Prozessorschaltungsanordnung zu bewirken hat, dass die Prozessorschaltungsanordnung das Verfahren nach einem oder mehreren der Ansprüche 1-24 durchführt.