DE112021003825T5

DE112021003825T5 - Föderiertes lernen für mehrfachzugang-funkressourcenverwaltungsoptimierungen

Info

Publication number: DE112021003825T5
Application number: DE112021003825.7T
Authority: DE
Inventors: Mustafa Riza Akdeniz; Nageen Himayat; Ravikumar Balakrishnan; Sagar Dhakal; Mark R. Eisen; Navid Naderializadeh
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-07-17
Filing date: 2021-06-26
Publication date: 2023-05-11
Also published as: WO2022015487A8; WO2022015487A1; US20230189319A1

Abstract

In einer Ausführungsform wird ein Maschinenlernmodell (ML-Modell) zum Bestimmen von Funkressourcenverwaltung(RRM)-Entscheidungen aktualisiert, wobei ML-Modellparameter zwischen RRM-Entscheidern geteilt werden, um das Modell zu aktualisieren. Die Aktualisierungen können lokale Operationen (zwischen einem Paar aus AP und UE) zum Aktualisieren lokaler primaler und dualer Parameter des ML-Modells und globale Operationen (zwischen anderen Vorrichtungen im Netzwerk) zum Austauschen/Aktualisieren globaler Parameter des ML-Modells beinhalten.

Description

VERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht den Nutzen und die Priorität der vorläufigen US-Patentanmeldung Nr. 63/053,547 mit dem Titel „FEDERATED LEARNING FOR MULTIPLE ACCESS RADIO RESOURCE MANAGEMENT OPTIMIZATIONS“ und eingereicht am 17 Juli 2020, deren gesamte Offenbarung hiermit durch Bezugnahme aufgenommen wird.
HINTERGRUND
Edge-Computing auf allgemeiner Ebene bezieht sich auf die Implementierung, Koordination und Verwendung von Computing und Ressourcen an Orten näher am „Edge“ (Rand) oder einer Sammlung von „Edges“ des Netzwerks. Zweck dieser Anordnung ist es, die Gesamtkosten der Eigentümerschaft zu verbessern, Anwendungs- und Netzwerklatenz zu reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzvoraussetzungen (insbesondere gegenüber herkömmlichem Cloud-Computing) zu verbessern. Komponenten, die Edge-Rechenoperationen durchführen können („Edge-Knoten“), können sich an jedem Standort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird (z. B. in einem Hochleistungsrechendatenzentrum oder einer Cloud-Installation; einem designierten Edge-Knotenserver, einem Unternehmens server, einem Straßenrand-Server, einer Fernmeldezentrale; oder einer lokalen oder Peer-am-Edge-Vorrichtung, die mit Edge-Diensten versorgt wird und diese konsumiert).
Anwendungen, die für Edge-Computing angepasst wurden, beinhalten unter anderem die Virtualisierung herkömmlicher Netzwerkfunktionen (z. B. um Telekommunikations- oder Internetdienste zu betreiben) und die Einführung von Merkmalen und Diensten der nächsten Generation (z. B. um 5G-Netzdienste zu unterstützen). Verwendungsfälle, deren Planung weitgehendes Nutzen von Edge-Computing vorsieht, beinhalten unter vielen anderen Netzwerken und rechenintensiven Diensten vernetzte selbstfahrende Autos, Überwachung, Intemet-der-Dinge-Vorrichtungsdatenanalytik (IoT-Vorrichtungsdatenanalytik), Videocodierung und -analytik, ortsbewusste Dienste und Vorrichtungserfassung in Smart-Städten.
Edge-Computing kann bei einigen Szenarien einen Cloud-ähnlichen verteilten Dienst anbieten oder hosten, um Orchestrierung und Verwaltung für Anwendungen, koordinierte Dienstinstanzen und maschinelles Lernen, wie etwa föderiertes maschinelles Lernen, unter vielen Arten von Speicherungs- und Rechenressourcen anzubieten. Es ist zu erwarten, dass Edge-Computing auch fest in existierende Anwendungsfälle und Technologien integriert wird, die für IoT- und Fog- sowie verteilte Netzwerkkonfigurationen entwickelt wurden, da Endpunktvorrichtungen, Clients und Gateways versuchen, auf Netzwerkressourcen und Anwendungen an Orten zuzugreifen, die näher am Edge (Rand) des Netzwerks liegen.
Figurenliste
In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Ziffern mit verschiedenen angehängten Buchstaben können verschiedene Instanzen ähnlicher Komponenten repräsentieren. Einige Ausführungsformen sind beispielhaft und nicht beschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in denen gilt:

1 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing.
2 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen.
3 veranschaulicht einen beispielhaften Ansatz für Networking und Dienste in einem Edge-Rechensystem.
4 veranschaulicht den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird.
5 veranschaulicht verschiedene Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen.
6 veranschaulicht einen Rechen- und Kommunikationsverwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Rechensystem involviert.
7A stellt einen Überblick über beispielhafte Komponenten zur Berechnung bereit, die an einem Rechenknoten in einem Edge-Rechensystem eingesetzt werden.
7B stellt einen weiteren Überblick über beispielhafte Komponenten innerhalb einer Rechenvorrichtung in einem Edge-Rechensystem bereit.
8 veranschaulicht ein beispielhaftes System, das eine zentralisierte NN-basierte RRM-Optimierungstechnik implementiert.
9 veranschaulicht ein beispielhaftes Modell für eine zentralisierte NN-basierte RRM-Optimierungstechnik.
10 veranschaulicht ein beispielhaftes System, das eine verteilte NN-basierte RRM-Optimierungstechnik für Downlink-Kommunikationen implementiert.
11 veranschaulicht ein beispielhaftes Modell eines verteilten Richtlinienherstellers für eine verteilte NN-basierte RRM-Optimierungstechnik.
12 veranschaulicht beispielhafte lokale Operationen, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Downlink-Kommunikationen stattfinden können.
13 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen, die in einer verteilten NN-basierten RRM-Optimierungstechnik für Downlink-Kommunikationen stattfinden können.
14 veranschaulicht erweiterte beispielhafte lokale Operationen, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Downlink-Kommunikationen stattfinden können.
15-17 veranschaulichen beispielhafte Simulationsergebnisse, die eine zentralisierte RRM-Optimierungstechnik und unterschiedliche Ausführungsformen einer verteilten RRM-Optimierungstechnik vergleichen.
18 veranschaulicht ein beispielhaftes System, das eine verteilte NN-basierte RRM-Optimierungstechnik für Uplink-Kommunikationen implementiert.
19 veranschaulicht beispielhafte lokale Operationen, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Uplink-Kommunikationen stattfinden können.
20 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen, die in einer verteilten NN-basierten RRM-Optimierungstechnik für Uplink-Kommunikationen stattfinden können.
21 veranschaulicht erweiterte beispielhafte lokale Operationen, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Uplink-Kommunikationen stattfinden können.
22 veranschaulicht ein beispielhaftes System, das eine verteilte NN-basierte RRM-Optimierungstechnik in einem Ad-hoc-Netzwerk implementiert.
23 veranschaulicht beispielhafte lokale Operationen, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Ad-hoc-Netzwerke stattfinden können.
24 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen, die in einer verteilten NN-basierten RRM-Optimierungstechnik für Ad-hoc-Netzwerke stattfinden können.
25 veranschaulicht einen Satz von Voraktualisierungsoperationen 2500, die für eine verteilte NN-basierte RRM-Optimierungstechnik durchgeführt werden können.
26 veranschaulicht einen Satz von Nachaktualisierungsoperationen 2600, die für eine verteilte NN-basierte RRM-Optimierungstechnik durchgeführt werden können.
27 veranschaulicht erweiterte beispielhafte lokale Operationen, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Ad-hoc-Netzwerke stattfinden können.
28 veranschaulicht ein anderes beispielhaftes System, das eine verteilte NN-basierte RRM-Optimierungstechnik implementiert.
29 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen für das System von 29.
30 veranschaulicht ein anderes beispielhaftes System, das eine verteilte NN-basierte RRM-Optimierungstechnik implementiert.

AUSFÜHRLICHE BESCHREIBUNG
1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als eine „Edge-Cloud“ bezeichnet wird. Wie gezeigt, ist die Edge-Cloud 110 an einem Edge-Ort kolokalisiert, wie etwa an einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungshub 150 oder einer Zentrale 120, und kann somit mehrere Entitäten, Vorrichtungen und Ausrüstungsinstanzen beinhalten. Die Edge-Cloud 110 befindet sich viel näher an den Endpunkt(Verbraucher und Erzeuger)-Datenquellen 160 (z. B. autonome Fahrzeuge 161, Benutzergeräte 162, Unternehmens- und Industrieausrüstung 163, Videoaufnahmevorrichtungen 164, Drohnen 165, Smart-Städte- und -Gebäude-Vorrichtungen 166, Sensoren und IoT-Vorrichtungen 167 usw.) als das Cloud-Datenzentrum 130. Rechen-, Speicher- und Speicherungsressourcen, die an den Edges in der Edge-Cloud 110 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zu dem Cloud-Datenzentrum 130, wodurch Energieverbrauch und Gesamtnetzwerknutzungen unter anderen Vorteilen verbessert werden.
Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit von dem Edge-Ort 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-Ort jedoch am Endpunkt (z. B. Benutzergerät (UE)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Computing die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sich sowohl geographisch als auch in der Netzwerkzugriffszeit näher befinden, zu reduzieren. Auf diese Weise versucht Edge-Computing, 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 Einsätze abdeckt und Einschränkungen anspricht, die manche Netzwerkbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten Variation von Konfigurationen basierend auf dem Edge-Ort (weil Edges auf einer Basisstationsebene zum Beispiel mehr eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art von Berechnung, Speicher, Speicherung, Fabric, Beschleunigung oder ähnlichen Ressourcen, die Edge-Orten, Stufen von Orten oder Gruppen von Orten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und zugehörige Ziele zum Erreichen der Nutzbarkeit und Leistungsfähigkeit von Enddiensten. Diese Einsätze können eine Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Timing-Charakteristiken als „Near-Edge“-, „Close-Edge“-, „Local-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten betrachtet werden können.
Edge-Computing ist ein sich entwickelndes Paradigma, bei dem das Computing an oder näher an dem „Rand“ eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z. B. x86 oder ARM-Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert wird, die sich viel näher an Endpunktvorrichtungen befinden, die die Daten produzieren und verbrauchen (z. B. an einem „Local Edge“, „Close Edge“ oder „Near Edge“). Edge-Gateway-Server können zum Beispiel mit Pools von Speicher- und Speicherungsressourcen ausgestattet sein, um Rechenaufgaben in Echtzeit für Anwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Benutzergeräte direkt zu verarbeiten, ohne ferner Daten über Backhaul-Netzwerke zu kommunizieren. Oder als ein anderes Beispiel kann Zentralen-Netzwerkverwaltungshardware durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen anbietet. Innerhalb von Edge-Rechennetzwerken kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien geben, in denen die Daten zu der Rechenressource „verschoben“ werden. Oder als ein Beispiel können Basisstationsrechen-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um die Arbeitslastbedürfnisse nach Bedarf durch Aktivieren ruhender Kapazität (Subskription, Kapazität nach Bedarf) zu skalieren, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
2 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen. Insbesondere stellt 2 Beispiele für Rechenverwendungsfälle 205 dar, die die Edge-Cloud 110 unter mehreren veranschaulichenden Schichten des Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunkt(Vorrichtungen und Dinge)-Schicht 200, die auf die Edge-Cloud 110 zugreift, um Datenerzeugungs-, Analyse- und Datenkonsumierungsaktivitäten durchzuführen. Die Edge-Cloud 110 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Vorrichtungsschicht 210 mit Gateways, Vor-Ort-Servern oder Netzwerkgeräten (Knoten 215), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 220, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerkhubs, regionale Datenzentren (DZ) oder lokale Netzwerkgeräte (Geräte 225); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 212, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 110 und zwischen den 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 sich aus Beschränkungen der Netzwerkkommunikationsentfernung und -verarbeitungszeit ergibt, können von weniger als einer Millisekunde (ms) reichen, wenn sie sich in der Endpunktschicht 200 befinden, unter 5 ms an der Edge-Vorrichtungsschicht 210 (z. B. einer „Near Edge“- oder „Close Edge“-Schicht), bis zu sogar zwischen 10 und 40 ms, wenn mit Knoten an der Netzwerkzugangsschicht 220 (z. B. einer „Middle Edge“-Schicht) kommuniziert wird. Jenseits des Edge-Cloud 110 befinden sich Schichten des Kernnetzwerks 230 und des Cloud-Datenzentrums 240, jeweils mit zunehmender Latenz (z. B. zwischen 50-60 ms an der Kernnetzwerkschicht 230, bis zu 100 oder mehr ms an der Cloud-Datenzentrumsschicht, die beide als eine „Far-Edge“-Schicht angesehen werden können). Infolgedessen werden Operationen an einem Kernnetzwerk-Datenzentrum 235 oder einem Cloud-Datenzentrum 245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Verwendungsfälle 205 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.
Die diversen Verwendungsfälle 205 können aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, auf Ressourcen unter Nutzungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 110 ausgeführt werden, variierende Voraussetzungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS: Quality of Service) (z. B. kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Antwortzeitvoraussetzung aufweisen; oder eine Leistungsfähigkeitsempfindlichkeit/-engstelle 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 Verwendungsfälle beinhaltet das Konzept eines Dienstflusses und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstvoraussetzung für die Entität an, die den Dienst konsumiert, sowie die assoziierten Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Unternehmensfunktions- und Unternehmensebenenvoraussetzungen. Die Dienste, die mit den beschriebenen „Begriffen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihr vereinbartes SLA fehlt, 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 in dem System zu erweitern, um das gesamte Transaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 110 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 205 (z. B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu versorgen und auf diese zu reagieren und Voraussetzungen für ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (virtuelle Netzwerkfunktionen (VNFs), Function 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.
Mit den Vorteilen von Edge-Computing ergeben sich jedoch die folgenden Vorbehalte. Die am Edge befindlichen Vorrichtungen sind häufig ressourcenbeschränkt, sodass Druck auf die Nutzung von Edge-Ressourcen besteht. Typischerweise wird dies durch das Pooling von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Der Edge kann leistungs- und kühlungseingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen berücksichtigt werden muss, die die meiste Leistung verbrauchen. Es kann inhärente Leistung-Leistungsfähigkeit-Kompromisse in diesen gepoolten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen höhere Leistung eine größere Speicherbandbreite benötigt. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Root-of-Trust-Funktionen auch erforderlich, da Edge-Orte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (z. B. wenn sie an einem Drittparteistandort untergebracht sind). Derartige Probleme werden in der Edge-Cloud 110 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 generischeren Ebene kann ein Edge-Rechensystem so beschrieben werden, dass es eine beliebige Anzahl von Einsätzen an den zuvor besprochenen Schichten umfasst, die in der Edge-Cloud 110 arbeiten (Netzwerkschichten 200-240), die eine Koordination vom Client und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kerndatenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), Internet-der-Dinge-Dienstanbieters, Cloud-Dienstanbieters (CSP), Unternehmens entität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Rechensystems können dynamisch bereitgestellt werden, wie etwa, wenn orchestriert, 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 anderer Sache umgesetzt sein, die/das dazu in der Lage ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie im Edge-Rechensystem verwendet, nicht notwendigerweise, dass ein solcher Knoten oder eine solche Vorrichtung in einer Client- oder Slave-Rolle arbeitet; vielmehr beziehen sich beliebige der Knoten oder Vorrichtungen im Edge-Rechensystem auf einzelne Entitäten, Knoten oder Teilsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 110 zu ermöglichen oder zu verwenden.
Von daher ist die Edge-Cloud 110 aus Netzwerkkomponenten und Funktionsmerkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 210-230 betrieben werden. Die Edge-Cloud 110 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, Smart-Vorrichtungen usw.) befinden, die hierin besprochen sind. Mit anderen Worten kann die Edge-Cloud 110 als ein „Edge“ angesehen werden, der die Endpunktvorrichtungen und traditionelle Netzwerkzugangspunkte, die als ein Eingangspunkt in Dienstanbieter-Kernnetzwerke dienen, verbindet, einschließlich Mobilträgernetzen (z. B. GSM(Global System for Mobile Communications)-Netze, LTE(Long-Term Evolution)-Netze, 5G/6G-Netze usw.), während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (z. B. WiFi, Long-Range-Wireless, drahtgebundene Netzwerke einschließlich optischer Netzwerke) können auch anstelle von oder in Kombination mit solchen 3GPP-Trägernetzen genutzt werden.
Die Netzwerkkomponenten der Edge-Cloud 110 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 110 eine Geräterechenvorrichtung sein, das ein eigenständiges Verarbeitungssystem einschließlich eines Gehäuses, einer Einhausung oder einer Hülle ist. In einigen Fällen sind Edge-Vorrichtungen Vorrichtungen, die in dem Netzwerk für einen spezifischen Zweck (z. B. eine Ampel) vorhanden sind, die aber Verarbeitungs- oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Solche Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für seinen primären Zweck geeignet ist; dennoch für andere Rechenaufgaben verfügbar ist, die seine primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Intemet-der-Dinge-Vorrichtungen. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Probleme, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Leistungsprobleme, physische Sicherheit und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 7B beschrieben. Die Edge-Cloud 110 kann auch einen oder mehrere Server und/oder einen oder mehrere Multi-Mandanten-Server beinhalten. Ein solcher Server kann eine virtuelle Rechenumgebung implementieren, wie etwa einen Hypervisor zum Einsetzen virtueller Maschinen, ein Betriebssystem, das Container implementiert usw. Solche virtuellen Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen isoliert sind.
In 3 tauschen verschiedene Client-Endpunkte 310 (in Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Unternehmens-Rechenausrüstung, industrieller Verarbeitungsausrüstung) Anfragen und Antworten aus, die für die Art der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 310 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 322 durch ein Vor-Ort-Netzwerksystem 332 ausgetauscht werden. Manche Client-Endpunkte 310, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 324 durch einen Zugangspunkt (z. B. Mobilfunkturm) 334 ausgetauscht werden. Manche Client-Endpunkte 310, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anforderungen und Antworten 326 über ein drahtloses Fahrzeugnetzwerk durch ein Straßennetzwerksystem 336 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 342, 344 innerhalb der Edge-Cloud 110 einsetzen, um Verkehr und Anforderungen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 110 verschiedene Rechen- und Speicherungsressourcen einsetzen, wie etwa bei Edge-Aggregationsknoten 340, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 340 und andere Systeme der Edge-Cloud 110 sind mit einer Cloud oder einem Datenzentrum 360 verbunden, die/das ein Backhaul-Netzwerk 350 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 340 und der Aggregationspunkte 342, 344, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 110 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
4 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen über ein Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. Insbesondere stellt 4 eine Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Rechensystem 400 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 410 (z. B. Smart-Städte / -Gebäude-Systeme, Mobilvorrichtungen, Rechenvorrichtungen, Unternehmens-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hier stellen die virtuellen Edge-Instanzen 432, 434 Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf eine Cloud/ein Datenzentrum 440 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 dem Beispiel von 4 beinhalten diese virtuellen Edge-Instanzen: einen ersten virtuellen Edge 432, der einem ersten Mandanten (Mandant 1) angeboten wird und eine erste Kombination von Edge-Speicherung, -Berechnung und -Diensten anbietet; und einen zweiten virtuellen Edge 434, der eine zweite Kombination von Edge-Speicherung, -Berechnung und -Diensten anbietet. Die virtuellen Edge-Instanzen 432, 434 sind unter den Edge-Knoten 422, 424 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 422, 424 zum Arbeiten auf eine verteilte, aber koordinierte Weise findet basierend auf Edge-Bereitstellungsfunktionen 450 statt. Die Funktionalität der Edge-Knoten 422, 424 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 460 statt.
Es versteht sich, dass manche der Vorrichtungen in 410 Multi-Mandanten-Vorrichtungen sind, wobei Mandant 1 innerhalb eines Mandant1-„Slice“ funktionieren kann, während ein Mandant 2 innerhalb eines Mandant2-Slice 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 Slice als eine „Root of Trust“ (RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner dynamisch unter Verwendung einer DICE-Architektur (DICE: Device Identity Composition Engine) berechnet werden, sodass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein feldprogrammierbares Gate-Array (FPGA)) zu konstruieren. Die RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um einen „Fan-Out“ zu ermöglichen, der zum Unterstützen von Multi-Mandanten nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 422, 424 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 432, 434) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 460 an einer Orchestrierungsentität als ein Sicherheitsmerkmaldurchsetzungspunkt zum Marshalling von Ressourcen entlang Mandantengrenzen arbeiten.
Edge-Rechenknoten können Ressourcen (Speicher, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interrupt-Steuerung, Eingabe/Ausgabe(E/A)-Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionierungen eine RoT-Fähigkeit enthalten können und wobei Fan-Out und Schichtbildung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Rechenknoten, die aus Containern, FaaS-Engines, Servlets, Servern oder einer anderen Berechnungsabstraktion bestehen, können gemäß einer DICE-Schichtbildungs- und Fan-Out-Struktur partitioniert werden, um jeweils einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen Vorrichtungen 410, 422 und 440, die RoTs überspannen, die Erstellung einer verteilten vertrauenswürdigen Rechenbasis (DTCB: Distributed Trusted Computing Base) koordinieren, sodass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente Ende-zu-Ende verknüpft, erstellt 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 Wrappen der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zu dem Ziel-Edge-Knoten migriert wird, wird der Unwrapping-Schlüssel der Pod-Steuerung preisgegeben, die dann die gewrappten 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 attestierte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
In weiteren Beispielen wird ein Edge-Rechensystem erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer eingebundenen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung 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 „Slice“-Konzepts in 4 durchzuführen. Beispielsweise kann ein Edge-Rechensystem dazu konfiguriert sein, Anforderungen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Datenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z. B. Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Rechen-Offload) 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; Networking-Anwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geographischen Orten (oder jeweilige Rechensysteme und Ressourcen, den mehreren Eigentümern gemeinsam gehören oder gemeinsam von diesen verwaltet werden) gespannt sein.
Beispielsweise kann jeder Edge-Knoten 422, 424 die Verwendung von Containern implementieren, wie etwa unter Verwendung eines Container-„Pods“ 426, 428, 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-Slices 432, 434 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
Bei der Verwendung von Container-Pods übersieht eine Pod-Steuerung die Partitionierung und Zuweisung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (z. B. Orchestrator 460), die Steuerung darüber anzuweisen, wie und für welche Dauer physische Ressourcen am besten zu partitionieren sind, wie etwa durch Empfangen von KPI(Key Performance Indicator)-Zielen basierend auf SLA-Verträgen. Die Pod-Steuerung bestimmt, welcher Container welche Ressourcen und für wie lange benötigt, um die Arbeitslast abzuschließen und das SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Container-Lebenszyklusvorgänge, wie etwa: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die auf einer verteilten Anwendung zusammenarbeiten, Zerlegen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung eine Sicherheitsrolle spielen, die eine Zuweisung von Ressourcen verhindert, bis sich der rechte Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Attestierungsergebnis erfüllt ist.
Auch bei der Verwendung von Container-Pods können Mandantengrenzen weiterhin existieren, jedoch im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, wird es eine gemeinsam genutzte Pod-Steuerung geben, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Attestierung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise kann der Orchestrator 460 lokalen Pod-Steuerungen, die eine Attestierungsverifizierung durchführen, eine Attestierungsverifizierungsrichtlinie bereitstellen. Falls eine Attestierung 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 ihn erfüllt. Alternativ dazu kann dem ersten Pod erlaubt werden, ausgeführt zu werden, und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
5 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen. Als ein vereinfachtes Beispiel stellen die Systemanordnungen 510, 520 Einstellungen dar, bei denen eine Pod-Steuerung (z. B. Container-Manager 511, 521 und Container-Orchestrator 531) dazu ausgelegt ist, containerisierte Pods, Funktionen und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten (515 in Anordnung 510) zu starten oder containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (523 in Anordnung 520) separat auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in der Systemanordnung 530 (unter Verwendung von Rechenknoten 536) eingerichtet, wobei containerisierte Pods (z. B. Pods 512), Funktionen (z. B. Funktionen 513, VNFs 522, 536) und Functions-as-a-Service-Instanzen (z. B. FaaS-Instanz 514) innerhalb virtueller Maschinen (z. B. VMs 534, 535 für Mandanten 532, 533) gestartet werden, die für jeweilige Mandanten spezifisch sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in der Systemanordnung 540 eingerichtet, die Container 542, 543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 544 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 541 koordiniert.
Die in 5 dargestellten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger(FPGA, ASIC)-Komponenten als ein lokales Backend beinhalten. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
Im Kontext von 5 können die Pod-Steuerung/der Container-Manager, der Container-Orchestrator und die einzelnen Knoten einen Sicherheitsvollzugspunkt bereitstellen. Die Mandantenisolation kann jedoch orchestriert werden, wobei sich die Ressourcen, die einem Mandanten zugewiesen sind, von Ressourcen unterscheiden, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um zu gewährleisten, dass Ressourcenzuweisungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuweisungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ über eine Subskriptions- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Zusammenhängen können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemen von Edge-Eigentümern verwendet werden, um die Mandanten zu vollziehen. Andere Isolationsumgebungen können beinhalten: Bare-Metal(dedizierte)-Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
Bei weiteren Beispielen können Aspekte von softwaredefinierter oder gesteuerter Siliziumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Rechensystems integrieren. Softwaredefiniertes Silizium kann verwendet werden, um zu gewährleisten, dass mancher Ressourcen- oder Hardwarebestandteil einen Vertrag oder ein Service-Level-Agreement erfüllen kann, basierend auf der Fähigkeit des Bestandteils, einen Teil von sich selbst oder die Arbeitslast zu beheben (z. B. durch ein Upgrade, eine Rekonfiguration oder eine Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst).
Es versteht sich, dass die hierin besprochenen Edge-Rechensysteme und -Anordnungen bei verschiedenen Lösungen, Diensten und/oder Verwendungsfällen anwendbar sein können, die Mobilität involvieren. Als ein Beispiel zeigt 6 einen vereinfachten Fahrzeugberechnungs- und Kommunikationsverwendungsfall, der einen mobilen Zugriff auf Anwendungen in einem Edge-Rechensystem 600 involviert, das eine Edge-Cloud 110 implementiert. In diesem Verwendungsfall können jeweilige Client-Rechenknoten 610 als fahrzeuginterne Rechensysteme (z. B. fahrzeuginterne Navigations- und/oder Infotainment-Systeme) umgesetzt sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gateway-Knoten 620 während des Fahrens entlang einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 620 in einem Schaltschrank 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 Orten nahe der Straße platziert werden kann. Während jeweilige Fahrzeuge entlang der Straße fahren, kann die Verbindung zwischen ihrem Client-Rechenknoten 610 und einer speziellen Edge-Gateway-Vorrichtung 620 propagieren, um eine konsistente Verbindung und einen konsistenten Kontext für den Client-Rechenknoten 610 aufrechtzuerhalten. Gleichermaßen können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsvoraussetzungen für den einen oder die mehreren zugrundeliegenden Dienste aggregieren (z. B. im Fall von Drohnen). Die jeweiligen Edge-Gateway-Vorrichtungen 620 beinhalten eine Menge an Verarbeitungs- und Speicherungsfähigkeiten und daher kann ein Teil der Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 610 auf einer oder mehreren der Edge-Gateway-Vorrichtungen 620 durchgeführt werden.
Die Edge-Gateway-Vorrichtungen 620 können mit einem oder mehreren Edge-Ressourcenknoten 640 kommunizieren, die veranschaulichend als Rechenserver, -geräte oder -komponenten umgesetzt sind, die sich an oder in einer Kommunikationsbasisstation 642 (z. B. einer Basisstation eines zellularen Netzwerks) befinden. Wie oben besprochen, beinhalten die jeweiligen Edge-Ressourcenknoten 640 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und somit kann ein Teil der Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 610 auf dem Edge-Ressourcenknoten 640 durchgeführt werden. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den Edge-Ressourcenknoten 640 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Vorrichtungen 620 durchgeführt werden kann (in Abhängigkeit von zum Beispiel den Fähigkeiten jeder Komponente oder Informationen in der Anforderung, die die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenort 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 640 kommunizieren auch mit dem Kerndatenzentrum 650, das Rechenserver, -geräte und/oder andere Komponenten beinhalten kann, die sich an einem Zentralort (z. B. einer Zentrale eines zellularen Kommunikationsnetzes) befinden. Das Kerndatenzentrum 650 kann ein Gateway zu der globalen Netzwerk-Cloud 660 (z. B. dem Internet) für die Operationen der Edge-Cloud 110 bereitstellen, die durch den einen oder die mehreren Edge-Ressourcenknoten 640 und die Edge-Gateway-Vorrichtungen 620 gebildet werden. Zusätzlich kann das Kerndatenzentrum 650 in manchen Beispielen eine Menge an Verarbeitungs- und Speicherungsfähigkeiten beinhalten und somit kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kerndatenzentrum 650 durchgeführt werden (z. B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
Die Edge-Gateway-Knoten 620 oder die Edge-Ressourcenknoten 640 können die Verwendung zustandsbehafteter Anwendungen 632 und einer geographisch verteilten Datenbank 634 anbieten. Obwohl die Anwendungen 632 und die Datenbank 634 als horizontal auf einer Schicht der Edge-Cloud 110 verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste oder andere Komponenten der Anwendung vertikal über die Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, der an dem Client-Rechenknoten 610 ausgeführt wird, anderer Teile an den Edge-Gateway-Knoten 620 oder den Edge-Ressourcenknoten 640 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 speziellen Client oder eine spezielle Anwendung basierend auf sich ändernden Bedingungen von Edge zu Edge bewegen (z. B. basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.). Beispielsweise kann basierend auf der „Abklingrate“ des Zugangs eine Vorhersage getroffen werden, um den nächsten fortsetzenden Eigentümer zu identifizieren, oder wann die Daten oder der rechnerische Zugang nicht mehr umsetzbar sein werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die benötigt wird, um die Transaktion konform und verlustfrei zu halten.
Bei weiteren Szenarien kann ein Container 636 (oder ein Pod von Containern) flexibel von einem Edge-Knoten 620 zu anderen Edge-Knoten (z. B. 620, 640 usw.) migriert werden, sodass der Container mit einer Anwendung und Arbeitslast nicht rekonstituiert, rekompiliert, reinterpretiert werden muss, damit die Migration funktioniert. In solchen Einstellungen kann es jedoch einige angewendete Abhilfe- oder „Swizzling“-Übersetzungsoperationen geben. Zum Beispiel kann sich die physische Hardware am Knoten 640 vom Edge-Gateway-Knoten 620 unterscheiden und daher wird die Hardwareabstraktionsschicht (HAL), die den unteren 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 Abbildungsschnittstellen und -operationen beinhalten. Eine Pod-Steuerung kann verwendet werden, um die Schnittstellenabbildung als Teil des Container-Lebenszyklus anzusteuern, was Migration zu/von verschiedenen Hardwareumgebungen beinhaltet.
Die Szenarien, die von 6 eingeschlossen werden, können verschiedene Arten von mobilen Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Auto/Lastkraftwagen/Straßenbahn/Zug) gehostet wird, oder eine andere mobile Einheit, da sich der Edge-Knoten zu anderen geografischen Orten 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 Caching, Berichterstellung, Datenaggregation usw. durchzuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Einstellungen verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunktvorrichtungen oder den Edge-Gateway-Knoten 620, einigen anderen an dem Edge-Ressourcenknoten 640 und anderen in dem Kerndatenzentrum 650 oder der globalen Netzwerk-Cloud 660.
Bei weiteren Konfigurationen kann das Edge-Rechensystem FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen implementieren. In einem Beispiel schreibt ein Entwickler Funktionscode (hier 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 Datenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstverwendungsfall 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 eine Drittpartei 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 Kubernetes-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Rechensystems werden verschiedene Datenzentrum-, Edge- und Endpunktvorrichtungen (einschließlich Mobilvorrichtungen) verwendet, um Funktionen „hochzufahren“ (z. B. Funktionshandlungen zu aktivieren und/oder zuzuweisen), die nach Bedarf skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (z. B. Edge-Rechenknoten) und zugrundeliegenden 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 das Einsetzen von Edge-Funktionen auf eine Dienstweise ermöglichen, einschließlich einer Unterstützung jeweiliger Funktionen, die Edge-Computing als einen Dienst unterstützen (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 Funktionsspeicherräumen; 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, gegenüber „kalten“, die Initialisierung, Einsatz oder Konfiguration erfordern).
In weiteren Beispielen können beliebige der Rechenknoten oder -vorrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Computing-Systeme und -Umgebung besprochen wurden, basierend auf den Komponenten, die in den 7A und 7B dargestellt sind, verwirklicht werden. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, der/die/das in der Lage ist, mit anderen Edge-, Networking- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smart-Gerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem), eine eigenständige Vorrichtung mit einer äußeren Einhausung, Hülle usw. oder eine andere Vorrichtung oder ein anderes System umgesetzt sein, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen.
In dem vereinfachten Beispiel, das in 7A dargestellt ist, beinhaltet ein Edge-Rechenknoten 700 eine Rechen-Engine (hierin auch als „Rechenschaltungsanordnung“ bezeichnet) 702, ein Eingabe/Ausgabe(E/A)-Subsystem 708, eine Datenspeicherung 710, ein Kommunikationsschaltungsanordnungssubsystem 712 und optional eine oder mehrere Peripherievorrichtungen 714. In anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Komponenten beinhalten, wie etwa jene, die man typischerweise in einem Computer vorfindet (z. B. eine Anzeige, Peripherievorrichtungen usw.). Zusätzlich dazu können in manchen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderweitig einen Teil davon bilden.
Der Rechenknoten 700 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen umgesetzt sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. Bei manchen Beispielen kann der Rechenknoten 700 als eine einzige Vorrichtung ausgeführt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. Bei dem veranschaulichenden Beispiel beinhaltet der Rechenknoten 700 einen Prozessor 704 oder einen Speicher 706 oder ist als diese ausgefiihrt. Der Prozessor 704 kann als eine beliebige Art von Prozessor umgesetzt sein, der in der Lage ist, die hierin beschriebenen Funktionen (z. B. Ausführen einer Anwendung) durchzuführen. Der Prozessor 704 kann zum Beispiel als ein oder mehrere Mehrkernprozessoren, ein Mikrocontroller oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung umgesetzt sein. Bei manchen Beispielen kann der Prozessor 704 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder andere spezialisierte Hardware umgesetzt sein, diese beinhalten oder mit diesen gekoppelt sein, um eine Leistungsfähigkeit der hierin beschriebenen Funktionen zu ermöglichen.
Der Speicher 706 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder flüchtiger oder nichtflüchtiger Datenspeicherung umgesetzt sein, der/die in der Lage ist, die hierin beschriebenen Funktionen durchzuführen. Ein flüchtiger Speicher kann ein Speicherungsmedium sein, das Leistung zum Aufrechterhalten des Zustands von durch das Medium gespeicherten Daten benötigt. Nichtbeschränkende Beispiele für flüchtigen Speicher können verschiedene Typen von Direktzugriffsspeicher (RAM), wie etwa DRAM oder statischen Direktzugriffsspeicher (SRAM), einschließen. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
Bei einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine dreidimensionale Crosspoint-Speichervorrichtung (z. B. Intel(k 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Speichervorrichtungen mit ortsfestem Schreiben beinhalten. Die Speichervorrichtung kann sich auf den Die selbst und/oder auf ein gekapseltes Speicherprodukt beziehen. Bei manchen Beispielen kann der 3D-Crosspoint-Speicher (z. B. Intel® 3D XPoint™ Speicher) eine transistorlose stapelbare Crosspoint-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und bei der die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert. Bei manchen Beispielen kann der gesamte oder ein Teil des Speichers 706 in den Prozessor 704 integriert sein. Der Speicher 706 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 702 ist über das E/A-Subsystem 708, das als eine Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, kommunikativ mit anderen Komponenten des Rechenknotens 700 gekoppelt, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 702 (z. B. mit dem Prozessor 704 und/oder dem Hauptspeicher 706) und anderen Komponenten der Rechenschaltungsanordnung 702 zu ermöglichen. Das E/A-Untersystem 708 kann zum Beispiel als Speichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmwarevorrichtungen, Kommunikationslinks (z. B. Punkt-zu-Punkt-Links, Buslinks, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Untersysteme umgesetzt sein oder diese anderweitig beinhalten, um die Eingabe/Ausgabe-Operationen zu erleichtern. Bei manchen Beispielen kann das E/A-Untersystem 708 einen Teil eines System-on-Chip (SoC) bilden und zusammen mit dem Prozessor 704 und/oder dem Speicher 706 und/oder anderen Komponenten der Rechenschaltungsanordnung 702 in die Rechenschaltungsanordnung 702 integriert sein.
Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen 710 können als eine beliebige Art von Vorrichtungen umgesetzt sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert sind, wie etwa zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Solid-State-Laufwerke oder andere Datenspeicherungsvorrichtungen. Einzelne Datenspeicherungsvorrichtungen 710 können eine Systempartitionierung beinhalten, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung 710 speichert. Einzelne Datenspeicherungsvorrichtungen 710 können auch eine oder mehrere Betriebssystempartitionierungen beinhalten, die Datendateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel der Art des Rechenknotens 700 speichern.
Die Kommunikationsschaltungsanordnung 712 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder -sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 702 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway eines implementierenden Edge-Rechensystems) zu ermöglichen. Die Kommunikationsschaltungsanordnung 712 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein zellulares Networking-Protokoll, wie etwa einen 3GPP-, 4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/Wi-Fi®, ein drahtloses Weitverkehrsnetzwerkprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, LPWAN(Low-Power Wide Area Network)- oder LPWA(Low-Power Wide Area)-Protokolle usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
Die veranschaulichende Kommunikationsschaltungsanordnung 712 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 720, die auch als eine Host-Fabric-Schnittstelle (HFI: Host Fabric Interface) bezeichnet werden kann. Die NIC 720 kann als eine oder mehrere Add-In-Platinen, Tochterkarten, Netzwerkschnittstellenkarten, Steuerungschips, Chipsätze oder andere Vorrichtungen umgesetzt sein, die durch den Rechenknoten 700 verwendet werden können, um sich mit einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway-Knoten) zu verbinden. Bei manchen Beispielen kann die NIC 720 als Teil eines System-on-Chip (SoC) umgesetzt sein, das einen oder mehrere Prozessoren beinhaltet, oder kann auf einem Mehrchip-Package enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. Bei manchen Beispielen kann die NIC 720 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide lokal für die NIC 720 sind. Bei solchen Beispielen kann der lokale Prozessor der NIC 720 dazu in der Lage sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltungsanordnung 702 durchzuführen. Zusätzlich oder alternativ dazu kann in solchen Beispielen der lokale Speicher der NIC 720 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Socket-Ebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
Zusätzlich kann in manchen Beispielen ein jeweiliger Rechenknoten 700 eine oder mehrere Peripherievorrichtungen 714 beinhalten. Solche Peripherievorrichtungen 714 können eine beliebige Art von Peripherievorrichtung beinhalten, die in einer Rechenvorrichtung oder einem Server gefunden wird, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe/Ausgabe-Vorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 700. In weiteren Beispielen kann der Rechenknoten 700 durch einen jeweiligen Edge-Rechenknoten (egal ob ein Client, Gateway oder Aggregationsknoten) in einem Edge-Rechensystem oder ähnlichen Formen von Geräten, Computern, Untersystemen, Schaltungsanordnungen oder anderen Komponenten umgesetzt sein.
In einem ausführlicheren Beispiel veranschaulicht 7B ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Rechenknoten 750 zum Implementieren der hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methoden) vorhanden sein können. Dieser Edge-Rechenknoten 750 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 700 bereit, wenn er als oder als Teil einer Rechenvorrichtung (z. B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert wird. Der Edge-Rechenknoten 750 kann beliebige Kombinationen der hierin genannten Hardware- oder Logikkomponenten beinhalten, und er kann eine beliebige Vorrichtung, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendbar ist, beinhalten oder mit dieser gekoppelt sein. Die Komponenten können als integrierte Schaltungen (ICs), Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Anweisungssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die im Edge-Rechenknoten 750 angepasst sind, oder als Komponenten, die anderweitig in ein Gehäuse eines größeren Systems integriert sind, implementiert sein.
Die Edge-Rechenvorrichtung 750 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 752 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 752 kann ein Teil eines System-on-Chip (SoC) sein, in dem der Prozessor 752 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Package ausgebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien, USA. Als ein Beispiel kann der Prozessor 752 einen auf Intel® Architecture Core™ basierenden CPU-Prozessor, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, einen i9- oder einen MCU-Klasse-Prozessor oder einen anderen solchen Prozessor, der von Intel® verfügbar ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa erhältlich von der Firma Advanced Micro Devices, Inc. (AMD®) aus Sunnyvale, Kalifornien, USA, ein MIPS®-basiertes Design der Firma MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, USA, ein ARM®-basiertes Design, lizenziert von ARM Holdings, Ltd. oder ein Kunde davon, oder deren Lizenznehmer oder Adopter. Die Prozessoren können Einheiten beinhalten, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcommon® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. Der Prozessor 752 und die begleitende Schaltungsanordnung können in einem einzigen Socket-Formfaktor, mehreren Socket-Formfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 7B gezeigten Elemente beinhalten.
Der Prozessor 752 kann über ein Interconnect 756 (z. B. einen Bus) mit einem Systemspeicher 754 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher 754 Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Speicherkomponente einem von JEDEC vertriebenen DRAM-Standard entsprechen, wie etwa JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low-Power-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. Bei diversen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von verschiedenen Package-Typen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Vorrichtungen können bei manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die der Reihe nach durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual Inline Memory Modules (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 758 auch über das Interconnect 756 mit dem Prozessor 752 gekoppelt sein. Bei einem Beispiel kann der Speicher 758 über ein Solid-State-Laufwerk (SSDD) implementiert werden. Andere Vorrichtungen, die für die Speicherung 758 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa Secure-Digital(SD)-Karten, microSD-Karten, eXtreme-Digital-(XD)-Bildkarten und dergleichen und Universal-Serial-Bus(USB)-Flash-Laufwerke. Bei einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder beinhalten, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Einzel- oder Mehrfachpegel-Phasenwechselspeicher (PCM), einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher (MRAM), Speicher, der Memristortechnologie beinhaltet, resistiven Speicher einschließlich der Metalloxid-Basis, der Sauerstoffleerstellenbasis und den Leitfähige-Brücke-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque(STT)-MRAM, einer auf spintronischen Magnetübergangsspeicher basierte Vorrichtung, eine Magnettunnelübergang(MTJ)-basierte Vorrichtung, eine DW(Domänenwand)- und SOT(Spin-Orbit-Transfer)-basierte Vorrichtung, eine thyristorbasierte Speichervorrichtung oder eine Kombination von beliebigen der obigen oder eines anderen Speichers verwenden.
In Niederleistungsimplementierungen kann die Speicherung 758 ein On-Die-Speicher oder Register sein, die mit dem Prozessor 752 assoziiert sind. Bei manchen Beispielen kann die Speicherung 758 jedoch unter Verwendung eines Mikro-Festplattenlaufwerks (HDD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 758 zusätzlich zu den, oder anstelle der, beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
Die Komponenten können über das Interconnect 756 kommunizieren. Das Interconnect 756 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industry Standard Architecture (ISA), extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Das Interconnect 756 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine Inter-Integrated-Circuit(I2C)-Schnittstelle, eine Serial-Peripheral-Interface(SPI)-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Das Interconnect 756 kann den Prozessor 752 mit einem Sendeempfänger 766 koppeln, um mit den verbundenen Edge-Vorrichtungen 762 zu kommunizieren. Der Sendeempfänger 766 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z. B. 2,4-Gigahertz (GHz)-Übertragungen nach dem IEEE-802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy(BLE)-Standards, wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards unter anderem. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 762 verwendet werden. Zum Beispiel kann eine WLAN-Einheit (WLAN: Wireless Local Area Network - drahtloses Lokalnetzwerk) verwendet werden, um WiFi® -Kommunikationen gemäß dem IEEE (Institute of Electrical and Electronics Engineers) 802.11-Standard zu implementieren. Außerdem können Drahtlos-Weitbereichskommunikationen, z. B. gemäß einem zellularen oder anderen Drahtlos-Weitbereichsprotokoll über eine Drahtlos-Weitbereichsnetzwerk(WWAN)-Einheit stattfmden.
Der Drahtlosnetzwerksendeempfänger 766 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen mit einer anderen Reichweite kommunizieren. Beispielsweise kann der Edge-Rechenknoten 750 mit nahen Vorrichtungen, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf Bluetooth Low Energy (BLE) oder eines anderen Niedrigleistungsfunkgeräts kommunizieren, um Leistung zu sparen. Entferntere verbundene Edge-Vorrichtungen 762, z. B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Zwischenleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Sendeempfänger stattfinden, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Mesh-Sendeempfänger, der ZigBee® verwendet.
Ein Drahtlosnetzwerksendeempfänger 766 (z. B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 795 über Lokal- oder Weitbereichsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerksendeempfänger 766 kann ein LPWA-Sendeempfänger (LPWA: Low Power Wide Area) sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Rechenknoten 750 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wurde, kommunizieren. 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, wie beispielsweise Kanalspringen mit Zeitschlitzen, das in der Spezifikation IEEE 802.15.4e beschrieben ist, verwendet werden.
Eine beliebige Anzahl anderer Funkkommunikationen und -protokolle kann zusätzlich zu den für den Drahtlosnetzwerksendeempfänger 766 erwähnten Systemen verwendet werden, wie hierin beschrieben. Zum Beispiel kann der Sendeempfänger 766 einen zellularen Sendeempfänger umfassen, der Spreizspektrum(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa WiFi®-Netze für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzkommunikationen. Der Sendeempfänger 766 kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP(Third Generation Partnership Project)-Spezifikationen kompatibel sind, wie etwa Long Term Evolution (LTE) und Kommunikationssysteme der 5. Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher besprochen werden. Eine Netzwerkschnittstellensteuerung (NIC) 768 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 795 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 762 (die z. B. in einem Mesh arbeiten), bereitzustellen. 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+, PROFIBUS oder PROFINET, unter vielen anderen. Eine zusätzliche NIC 768 kann enthalten sein, um eine Verbindung mit einem zweiten Netzwerk zu ermöglichen, beispielsweise eine erste NIC 768, die Kommunikationen zu der Cloud über Ethernet bereitstellt, und eine zweite NIC 768, die Kommunikationen zu anderen Vorrichtungen über einen anderen Netzwerktyp bereitstellt.
Angesichts der Vielfalt von Arten anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann zutreffende Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine oder mehrere der Komponenten 764, 766, 768 oder 770 beinhalten oder durch diese verkörpert sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltungsanordnung verkörpert werden.
Der Edge-Rechenknoten 750 kann eine Beschleunigungsschaltungsanordnung 764 beinhalten oder mit dieser gekoppelt sein, die durch einen oder mehrere Beschleuniger für künstliche Intelligenz (KI), einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, ein oder mehrere SoCs, eine oder mehrere CPUs, einen oder mehrere Digitalsignalprozessoren, dedizierte ASICs oder andere Formen spezialisierter Prozessoren oder Schaltungsanordnungen umgesetzt werden, die dazu ausgebildet sind, eine oder mehrere spezialisierte Aufgaben zu erfüllen. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten.
Das Interconnect 756 kann den Prozessor 752 mit einem Sensorhub oder einer externen Schnittstelle 770 koppeln, der/die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die Vorrichtungen können Sensoren 772, wie etwa Beschleunigungsmesser, Pegelsensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z. B. GPS), Drucksensoren, barometrische Drucksensoren und dergleichen beinhalten. Der Hub oder die Schnittstelle 770 kann ferner verwendet werden, um den Edge-Rechenknoten 750 mit Aktoren 774 zu verbinden, wie etwa Leistungsschaltern, Ventilaktoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen.
Bei manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb des Edge-Rechenknotens 750 vorhanden sein oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige oder eine andere Ausgabevorrichtung 784 enthalten sein, um Informationen, wie etwa Sensorablesungen oder Aktorposition, zu zeigen. Eine Eingabevorrichtung 786, wie beispielsweise ein Touchscreen oder ein Tastenfeld, kann enthalten sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 784 kann eine beliebige Anzahl von Formen einer akustischen oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie binärer Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie Anzeigebildschirme (z. B. Flüssigkristallanzeige(LCD)-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Rechenknotens 750 generiert oder erzeugt wird. Eine Anzeigen- 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 776 kann den Edge-Rechenknoten 750 mit Leistung versorgen, wobei sie in Beispielen, in denen der Edge-Rechenknoten 750 an einem festen Ort montiert ist, eine Leistungsversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie kann als ein Backup oder für temporäre Funktionen verwendet werden. Die Batterie 776 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie, wie beispielsweise eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen sein.
Ein Batterieüberwachungs-/-ladegerät 778 kann in dem Edge-Rechenknoten 750 enthalten sein, um den Ladezustand (SoCh: State of Charge) der Batterie 776, falls enthalten, zu verfolgen. Das Batterieüberwachungs-/-ladegerät 778 kann dazu verwendet werden, andere Parameter der Batterie 776 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH: State of Health) und den Funktionszustand (SoF: State of Function) der Batterie 776. Das Batterieüberwachungs-/-ladegerät 778 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor aus Phoenix, Arizona, USA, oder einen IC der UCD90xxx-Familie von Texas Instruments aus Dallas, TX, USA. Das Batterieüberwachungs-/-ladegerät 778 kann die Informationen über die Batterie 776 über das Interconnect 756 an den Prozessor 752 kommunizieren. Das Batterieüberwachungs-/-ladegerät 778 kann auch einen Analog-Digital-Wandler (ADC) beinhalten, der es dem Prozessor 752 ermöglicht, die Spannung der Batterie 776 oder den Stromfluss von der Batterie 776 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Rechenknoten 750 ausführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzwerkoperation, Erfassungsfrequenz und dergleichen.
Ein Leistungsblock 780 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit dem Batterieüberwachungs-/-ladegerät 778 gekoppelt werden, um die Batterie 776 zu laden. Bei einigen Beispielen kann der Leistungsblock 780 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Schleifenantenne im Edge-Rechenknoten 750, zu erhalten. Eine Drahtlosbatterieladeschaltung, wie etwa unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann im Batterieüberwachungs-/-ladegerät 778 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 776 und somit dem erforderlichen Strom ausgewählt werden. Das Aufladen kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
Die Speicherung 758 kann Anweisungen 782 in Form von Software-, Firmware- oder Hardwarebefehlen enthalten, um die hierin beschriebenen Techniken zu implementieren. Obwohl solche Anweisungen 782 als Codeblöcke gezeigt sind, die in dem Speicher 754 und der Speicherung 758 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: Application Specific Integrated Circuit) eingebaut sind.
Bei einem Beispiel können die Anweisungen 782, die über den Speicher 754, die Speicherung 758 oder den Prozessor 752 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 760 umgesetzt sein, das Code beinhaltet, um den Prozessor 752 anzuweisen, elektronische Operationen in dem Edge-Rechenknoten 750 durchzuführen. Der Prozessor 752 kann über das Interconnect 756 auf das nichtflüchtige maschinenlesbare Medium 760 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 760 von Vorrichtungen umgesetzt werden, die für die Speicherung 758 beschrieben sind, oder kann spezifische Speichereinheiten, wie etwa optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichtflüchtige, maschinenlesbare Medium 760 kann Anweisungen beinhalten, um den Prozessor 752 anzuweisen, eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
Auch in einem spezifischen Beispiel können die Anweisungen 782 auf dem Prozessor 752 (separat oder in Kombination mit den Anweisungen 782 des maschinenlesbaren Mediums 760) die Ausführung oder Operation einer vertrauenswürdigen Ausführungsumgebung (TEE) 790 konfigurieren. In einem Beispiel arbeitet die TEE 790 als ein geschützter Bereich, der für den Prozessor 752 zur sicheren Ausführung von Anweisungen und zum sicheren Zugriff auf Daten zugänglich ist. Verschiedene Implementierungen der TEE 790 und eines begleitenden sicheren Bereichs in dem Prozessor 752 oder dem Speicher 754 können beispielsweise durch Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardwaresicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte von Sicherheitsverhärtung, Hardware-Rootsof-Trust und vertrauenswürdigen oder geschützten Operationen können in der Vorrichtung 750 durch die TEE 790 und den Prozessor 752 implementiert werden.
In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch irgendein greifbares Medium, das zum Speichern, Codieren oder Führen von Anweisungen zur Ausführung durch eine Maschine imstande ist und das bewirkt, dass die Maschine beliebige einer oder mehrerer der Methodologien der vorliegenden Offenbarung durchführt, oder das zum Speichern, Codieren oder Führen von Datenstrukturen imstande ist, die von solchen Anweisungen genutzt werden oder damit assoziiert sind. Ein „maschinenlesbares Medium“ kann somit Solid-State-Speicher und optische und magnetische Medien umfassen, ist jedoch nicht darauf beschränkt. Zu spezifischen Beispielen für maschinenlesbare Medien zählen nichtflüchtiger Speicher, wie zum Beispiel Halbleiterspeichervorrichtungen (z. B. elektrisch programmierbarer Nurlesespeicher (Electrically Programmable Read-Only Memory, EPROM), elektrisch löschbarer programmierbarer Nurlesespeicher (Electrically Erasable Programmable Read-Only Memory, EEPROM)) und Flash-Speichervorrichtungen, Magnetplatten, wie zum Beispiel interne Festplatten und austauschbare Speicherplatten, magnetooptische Speicherplatten und CD-ROM- und DVD-ROM-Speicherplatten. Die Anweisungen, die durch ein maschinenlesbares Medium umgesetzt 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. Hypertext Transfer Protocol (HTTP)) nutzt.
Ein maschinenlesbares Medium kann durch eine Speicherungsvorrichtung oder eine andere Einrichtung bereitgestellt werden, die dazu in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Bei einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen die Anweisungen repräsentieren, wie etwa die 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 die Anweisungen repräsentierenden Informationen im maschinenlesbaren Medium können durch eine Verarbeitungsschaltungsanordnung in die Anweisungen zum Implementieren beliebige der hierin besprochenen Operationen verarbeitet werden. Das Ableiten der Anweisungen aus den Informationen (z. B. Verarbeitung durch die Verarbeitungsschaltungsanordnung) kann beispielsweise beinhalten: Kompilieren (z. B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitig Manipulieren der Informationen in die Anweisungen.
Bei einem Beispiel kann die Ableitung der Anweisungen Zusammenstellung, Kompilierung oder Interpretation der Informationen (z. B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder vorverarbeiteten Format, das durch das maschinenlesbare Medium bereitgestellt wird, zu erzeugen. Wenn die Informationen in mehreren Teilen bereitgestellt werden, können sie 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ührbarer Binär-Code usw.) auf einem oder mehreren Fernservern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk übertragen werden, und können an einer lokalen Maschine falls notwendig entschlüsselt, dekomprimiert, zusammengesetzt (z. B. verknüpft) und kompiliert oder interpretiert (z. B. in eine Bibliothek, selbständige ausführbare Datei usw.) werden und durch die lokale Maschine ausgeführt werden.
FÖDERIERTES LERNEN FÜR FUNKRESSOURCENVERWALTUNG
Aspekte der vorliegenden Offenbarung können Trainingsverfahren mit föderiertem maschinellem Lernen (ML) für Mehrzellen-Funkressourcenmanagement (RRM) anwenden. Die hierin beschriebenen Ansätze für föderiertes Lernen (FL) können ein vorrichtungsinternes Online-RRM-Trainingsverfahren implementieren, das nicht nur das Lernen gemäß der sich ändernden Umgebung anpasst, sondern auch den ressourcenintensiven Austausch von Kanalzustandsinformationen zwischen den Clients und dem Netzwerk vermeidet. Beispielsweise kann bei bestimmten Ausführungsformen ein verteilter Ansatz implementiert werden, wobei Edge-Vorrichtungen lokal die Ressourcenzuweisungsrichtlinie (z. B. Leistungszuweisungsrichtlinie) lernen und diese lokalen Richtlinienempfehlungen mit dem Netzwerk austauschen. Das Netzwerk kombiniert dann diese lokalen Empfehlungen, um eine Gesamtrichtlinie zu bestimmen. Simulationsergebnisse zeigen, dass diese Richtlinienempfehlungen im Vergleich zu der regulären Meldung von Kanalzustandsinformationen, die für herkömmliche zentralisierte Ansätze erforderlich sein können, ohne signifikante Auswirkung auf die Leistungsfähigkeit mit signifikant reduzierter Frequenz ausgetauscht werden können. In bestimmten Ausführungsformen wird ein zentralisierter ML-basierter Ansatz implementiert, der Trainieren eines neuronalen Netzwerks (NN) über ein Primal-Dual-Training beinhalten kann, um in einem nicht vertrauenswürdigen/föderierten Umfeld zu arbeiten. Es kann viele Lösungen für eine Mehrzellen-Funkressourcenverwaltung geben, da die optimale Lösung schwierig zu lösen ist. In letzter Zeit wurden jedoch ML-Tools erfolgreich angewendet, um die Leistungsfähigkeit solcher Lösungen zu verbessern.
Bei aktuellen NN-basierten Lösungen kann das NN zentralisiert sein und es wird angenommen, dass die Kanalzustands(CSI)-Messungen von allen Empfängern von dem Netzwerk an einem zentralen Knoten gesammelt werden, um dem zentralen Knoten (CN) zu ermöglichen, Entscheidungen über die RRM-Richtlinie zu treffen, die innerhalb dieser Kohärenzzeit des Netzwerks ausgeführt wird. Der CN leitet dann die Richtlinie/Entscheidung an alle Sender und Empfänger im Netzwerk weiter. Falls die Kohärenzzeit jedoch zu kurz ist (z. B. aufgrund hoher Mobilität), kann sich der Kanal ändern, bis die vollständig zentrale Lösung Sender und Empfänger erreicht, wodurch die Entscheidung ungültig gemacht wird. Ferner beruht eine solche zentrale Lösung auf umfangreicher CSI-Meldung, die in Kommunikation und Berechnung nicht skaliert, wenn der geografische Implementierungsbereich breiter wird oder wenn Knoten in das Netzwerk eintreten bzw. aus diesem austreten.
Anstatt eine RRM-Entscheidungsstruktur für ein ganzes Netzwerk in einem zentralen Knoten wie in aktuellen Systemen aufzuweisen, schlagen Ausführungsformen der vorliegenden Offenbarung vor, eine individuelle RRM-Entscheidungsteilstruktur für jeden Link auf der Vorrichtungsseite (entweder als Sender oder Empfänger) aufzuweisen, sodass sowohl Inferenz als auch Training lokaler Parameter basierend auf neuen Kanalmessungen auf eine Online-Weise an der Edge-Vorrichtung fortgesetzt werden können. Aspekte der vorliegenden Offenbarung können mit einer verteilten entkoppelten NN-Struktur arbeiten und Zwischenoptimierungsparameter einführen und können ermöglichen, dass eine Gradientenaktualisierungsfrequenz von Optimierungsparametern für eine verfügbare Bandbreite des CN und die gewünschte Leistungsfähigkeit abgestimmt wird. Die Schrittgröße dieser Parameter kann in Abhängigkeit von der Aktualisierungsperiode angepasst werden. Des Weiteren können unsere vorgeschlagenen Verfahren leicht auf Ad-hoc-Netzwerke erweitert werden sowie auf einer höheren Schicht des Kommunikationsstapels arbeiten.
In bestimmten Ausführungsformen der vorliegenden Offenbarung kann es Vorrichtungen mit heterogenen Berechnungsfähigkeiten erlaubt sein, eine RRM-Lösung auf eine föderierte Weise zu entwickeln, was reduzierte Rückmeldungen sowie Online-Lösungsansätze ermöglicht, die sich besser an lokale Bedingungen anpassen können, im Gegensatz zu einem zentralisierten Lösungsframework wie in aktuellen NN-basierten Systemen. Des Weiteren können leistungsfähigere Clients bessere Entscheidungen treffen (z. B. mit tieferen lokalen neuronalen Netzwerken (NNs)).
8 veranschaulicht ein beispielhaftes System 800, das eine zentralisierte NN-basierte RRM-Optimierungstechnik implementiert. Wie in 8 gezeigt und oben beschrieben, müssen Kanalmessungen und RRM-Entscheidungen möglicherweise so oft wie einmal in einer Kanalkohärenzperiode für zentralisierte Techniken ausgetauscht werden. Von daher kann dieses Framework gegenüber der Latenz im Backhaul empfindlich sein. Beispielsweise werden in dem beispielhaften System 800 Kanalmessungen von Benutzergerätevorrichtungen (UEs) 808 über die Basisstationen (BS) 806 und das Gateway 804 an ein zentralisiertes NN 802 gesendet. Das zentralisierte NN 802 kann am Gateway 804 oder in einem anderen zentralen Knoten oberhalb des Gateways 804 in der Netzwerkarchitektur existieren. Das zentralisierte NN 802 kann die Kanalmessungen als Eingaben nutzen, um zu RRM-Entscheidungen für die BS-UE-Links zu gelangen. Die RRM-Entscheidungen können hinunter an die BS 806 geleitet werden, die solche Entscheidungen implementieren kann. Wie oben beschrieben, können sich Kanalmessungen oder andere Bedingungen während dieser Zeit jedoch ändern, was potenziell nicht optimale RRM verursacht.
Wie beobachtet werden kann, kann 8 ein Framework repräsentieren, um den obigen Algorithmus zu realisieren, und genauso wie jede andere umsetzbare Realisierung erfordert er jedoch den Austausch von Kanalmessungen über den drahtlosen Link und das Backhaul sowohl für Training als auch Inferenz. Dementsprechend müssen die Kanalmessungen immer dann ausgetauscht werden, wenn sie erhalten werden, was aus den zuvor beschriebenen Gründen problematisch sein kann. Als ein Beispiel können sich die Kanalbedingungen geändert haben, bis eine RRM-Entscheidung durch das zentrale NN 802 getroffen wird.
Dementsprechend können in Ausführungsformen der vorliegenden Offenbarung, anstatt ein zentrales NN (z. B. 802) aufzuweisen, mehrere „lokale“ NNs genutzt werden, die lokal für die Links sind, für die die RRM-Entscheidung getroffen werden soll (z. B. ein NN in dem UE oder ein NN in dem AP/der BS). Optimierungsparameter werden definiert, die Störung oder andere Kanalmessungen zwischen UEs, APs usw. erfassen. Diese Optimierungsparameter können zwischen den NNs in dem System anstelle der Kanalmessungen wie in dem System von 8 gemeinsam genutzt werden. Dies ist vorteilhaft, da die Optimierungsparameter kleiner als die Kanalmessungsmatrix sind, sodass weniger Daten über das Netzwerk ausgetauscht werden.
In bestimmten Ausführungsformen kann ein Primal-Dual-Optimierungsproblem für bestimmte RRM-Entscheidungen definiert werden, z. B. eine Sendeleistung für einen TX, die primale Variablen (z. B. θ und x, die weiter unten beschrieben sind) und duale Variablen (z. B. λ^□ und µ^□, die weiter unten beschrieben sind) beinhaltet, ähnlich vorherigen RRM-Optimierungsansätzen. Die vorliegende Offenbarung stellt jedoch eine neue primale Variable (z. B. ρ, wie weiter unten beschrieben) bereit, die eine erwartete Leistungsausgabe eines Senders repräsentiert, und eine entsprechende duale Variable (z. B. v, wie weiter unten beschrieben), die repräsentiert, wie empfindlich ein Empfänger gegenüber anderen Sendern ist.
Eine Anzahl lokaler Aktualisierungen kann auf den lokalen NNs (z. B. an dem UE oder dem AP/der BS) durchgeführt werden. Jede lokale Aktualisierungsoperation hält die globale primale Variable (ρ) und die globale duale Variable (v) konstant (z. B. von vorherigen Iterationen), und die lokalen Aktualisierungsoperationen können mehrmals ausgeführt werden, um eine entsprechende Anzahl von RRM-Entscheidungen (z. B. Übertragungsleistung) (π) zu treffen. Funktionsschätzungen können in bestimmten Fällen während der lokalen Aktualisierungsoperationen aktualisiert werden (können z. B. für leistungsfähigere Vorrichtungen durchgeführt werden und für weniger leistungsfähige Vorrichtungen nicht durchgeführt werden). Die lokalen Aktualisierungsoperationen können durchgeführt werden, um die lokalen primalen Variablen (z. B. θ und x, die weiter unten beschrieben sind) und lokale duale Variablen (z. B. λ^□ und µ^□, die weiter unten beschrieben sind) des Optimierungsproblems basierend auf Kanalmessungen zu aktualisieren, die durch das lokale NN für Link(s) zwischen der Vorrichtung, die das NN hostet, und anderen Knoten des Systems erhalten werden.
Wie hierin verwendet, können Kanalmessungen auf eine Messung der Bedingung eines Drahtloskanals zwischen einem Sender (TX) und einem Empfänger (RX) (z. B. zwischen einem AP/einer BS und einem UE) verweisen. Kanalmessungen können zum Beispiel Kanalqualitätsinformationen, Kanalzustandsinformationen, Empfangssignalstärke, Signal-Rausch-Verhältnis, Zeitverzögerung, Phasendifferenz zwischen TX und RX beinhalten. Die Kanalmessungen können pro Antenne, pro Port oder pro Vorrichtung vorliegen. Die Kanalmessungen können in Form eines Satzes von Skalaren, eines Vektors oder einer Matrix für ein einzelnes TX-RX-Paar vorliegen. Die Kanalmesswerte können reell oder komplex sein. Zur Erklärung halber wird bei hierin beschriebenen Beispielen angenommen, dass die Kanalmesswerte reelle Skalarwerte sind.
Nach einer gewissen Anzahl von lokalen Aktualisierungsoperationsrunden kann die globale primale Variable (ρ) aktualisiert und an einen Gateway-Knoten (z. B. einen zentralen Knoten in dem System) gesendet werden. Die aktualisierten globalen primalen Variablen (ρ) können auch mit den anderen lokalen NNs des Systems ausgetauscht werden. Das Gateway kann die globalen dualen Variablen (v) basierend auf den aktualisierten globalen primalen Variablen (ρ) aktualisieren, die von jedem lokalen NN empfangen werden, und kann die aktualisierten globalen dualen Variablen (v) zu jedem der lokalen NNs des Systems übertragen, das dann die aktualisierten globalen primalen Variablen (ρ) und globalen dualen Variablen (v) verwenden kann, um zusätzliche Runden lokaler Aktualisierungsoperationen durchzuführen.
Primale und duale Parameter können wie folgt interpretiert werden: einer von ihnen ist der Wert der durchschnittlichen Leistung, mit der ein Knoten erwartet, dass andere Kommunikationslinks kommunizieren sollten, und der andere ist, was der Knoten glaubt, was andere Knoten von dem Knoten erwarten, wenn er zwischen seinen TXi und RXi kommuniziert. Welcher als „primal“ und welcher als „dual“ angesehen wird, kann davon abhängen, wie das Problem formuliert wird (ein Beispiel ist unten ausführlicher beschrieben). Es kann folglich einen eindeutigen Satz primaler und dualer Parameter für jedes Linkpaar oder jedes TXj-RXi-Paar geben, egal ob ein Kommunikationslink zwischen ihnen besteht oder nicht. Und jeder der primalen/dualen Parameter für ein einzelnes TXj-RXi-Paar ist (als ein reelles Skalar angenommen, aber kann der Vollständigkeit halber auch) komplex und ein Vektor (sein).
Leistungsverwaltung in zellularem Downlink-Kanal
Legacy-Leistungssteuerlösungen in zellularen Downlink-Kanälen basieren auf einem gewünschten Signal-Rausch-Verhältnis (SNR) an dem Benutzergerät (UE), das der Empfänger (RX) der Downlink-Datenkommunikation ist. Sie berücksichtigen üblicherweise nicht die Störung, die sie von anderen Basisstationen (BS) hören, oder die Störung, die sie für benachbarte UEs verursachen. In zentralisierten Lösungen, wie etwa der in 8 gezeigten, können RRM-Entscheidungen mit einem ML-basierten Richtlinienhersteller an einem zentralen Knoten (CN) (z. B. Gateway 804) getroffen werden. RRM-Probleme dieser Art können wie folgt formuliert werden: $\begin{array}{l} P_{θ}^{*} : = max_{θ, x \in X} \sum_{i = 1}^{m} w^{i} x^{i} \\ s, t, x^{i} \leq E_{H} [log (1 + \frac{h^{i i} π^{i} (H, θ)}{Σ_{j \neq i} h^{j i} π^{j} (H, θ) + N^{i}})], \forall i \\ E_{H} [π^{i} (H, θ)] \leq p_{m a x}^{i} \forall i \end{array}$
wobei H = [h¹, h²,..., h^m] , hⁱ = [h¹ⁱ, ..., h^ji,..., h^mi]^T der Vektor von Kanalverstärkungen von allen TXs zu RXi ist, wobei h^ji die Kanalverstärkung von TXj zu RXi repräsentiert, θ der Vektor von Parametern ist, die den Richtlinienhersteller repräsentieren, πⁱ(H, θ) die Leistungsentscheidung für TXi ist, xⁱ der erreichbare Durchsatzdes Links i ist, wⁱ das Gewicht des Links i im gesamten Netzwerkdienstprogramm ist und $p_{m a x}^{i}$
die Konstante ist, die die maximale Leistungsbeschränkung für den TX repräsentiert. Der Richtlinienhersteller kann ein neuronales Netzwerk (NN) sein, das wie in 9 gezeigt modelliert ist. In dem in 9 gezeigten beispielhaften NN-System 900 empfängt das NN 902 die oben beschriebenen Vektoren h^ji und produziert den oben beschriebenen Vektor von Parametern πⁱ, (H,θ).
Das Einführen von Lagrange-Variablen in das Optimierungsproblem und das Abwechseln von Aktualisierungen an primalen und dualen Variablen stellt einen Online- und adaptiven Algorithmus sowohl zum Lernen als auch zum Inferieren einer Leistungsrichtlinie bereit. In manchen Ausführungsformen kann das Min-Max-Problem zum Beispiel gegeben sein als: $\begin{matrix} D_{θ}^{*} : = min_{λ, μ} max_{θ, x} \sum_{i = 1}^{m} w^{i} x^{i} + \sum_{i = 1}^{m} λ^{i} (F^{i} (h^{i}, π (H, θ)) - x^{i}) \\ - \sum_{i}^{m} μ^{i} (G^{i} (π^{i} (H, θ^{i})) - p_{m a x}^{i}) \end{matrix}$
wobei $F^{i} (h^{i}, π (H, θ)) = E_{H} [log (1 + \frac{h^{i i} π^{i} (H, θ)}{Σ_{j \neq i} h^{j i} π^{j} (H, θ) + N^{i}})], G^{i} (π^{i} (H, θ)) = E_{H} [π^{i} (H, θ)]$
und λⁱ und µⁱ Lagrange-Variablen sind, die Beschränkungen in dem Optimierungsproblem entsprechen.
Dann können abwechselnde Aktualisierungen wie folgt implementiert werden: $θ_{k + 1} = θ_{k} + γ_{θ, k} [λ_{k}^{i} \nabla_{θ} F^{i} (h_{k}^{i}, π (H_{k}, θ_{k})) - μ_{k}^{i} \nabla_{θ} G^{i} (π^{i} (H_{k}, θ_{k}))]$
$\begin{array}{l} x_{k + 1}^{i} = P_{X} [x_{k}^{i} + γ_{x, k} (w^{i} - λ_{k}^{i})] \\ λ_{k + 1}^{i} = {[λ_{k}^{i} - γ_{λ, k} ({\hat{F}}^{i} (h_{k}^{i}, π (H_{k}, θ_{k + 1})) - x_{k + 1}^{i})]}_{+} \\ μ_{k + 1}^{i} = {[μ_{k}^{i} + γ_{μ, k} ({\hat{G}}^{i} (π^{i} (H_{k}, θ_{k + 1})) - p_{m a x}^{i})]}_{+} \end{array}$
wobei P_X[.] eine Projektion auf den konvexen Satz von Raten repräsentiert, die durch verfügbare MCS-Schemen unterstützt werden, und [.]₊ eine Projektion auf nicht negative reelle Zahlen repräsentiert. γ_.,k ist die Lernrate für die gegebene Variable bei Iteration k.
10 veranschaulicht ein beispielhaftes System 1000, das eine verteilte NN-basierte RRM-Optimierungstechnik für Downlink-Kommunikationen implementiert. UEs können in dem Downlink-Beispiel als RXs des Netzwerks angesehen werden und die BSs können als Sender (TX) angesehen werden. Jeder TXi sendet drahtlos Daten an RXi, während RXj (∀j ≠ i) gestört wird. Daher beeinflusst eine Sendeleistungsentscheidung eines TXi sowohl den Durchsatz bei RXj als auch den Durchsatz bei RXi. Alle TXs sind auch über ein Backhaul-Netzwerk verbunden und kommunizieren miteinander (z. B. über eine X2-Schnittstelle). Dementsprechend können sie sich Steuersignale teilen.
In dem gezeigten Beispiel ähnelt die Systemarchitektur jener von 8 mit der Ausnahme, dass jedes UE (RX) 1008 sein eigenes NN 1010 implementiert. Die UEs 1008 erzeugen Optimierungsparameter, die über das Backhaul an die BS 1006, das Gateway 1004, den Aggregator 1002 und andere UEs 1008 verteilt werden. Die NNs 1010 können im Gegenzug die gemeinsam genutzten Optimierungsparameter einsetzen, um zu RRM-Entscheidungen zu gelangen. Die Optimierungsparameter können in manchen Fällen so oft wie einmal in einer Kanalkohärenzperiode gemeinsam genutzt werden. Diese Optimierungsparameter können weniger Bandbreite nutzen als die oben beschriebenen Kanalmessungen, und können folglich einen oder mehrere Vorteile gegenüber zentralisierten RRM-Optimierungstechniken bereitstellen. Obwohl RRM-Entscheidungen häufig ausgetauscht werden können, müssen sie nicht über das Backhaul ausgetauscht werden, wie bei den oben beschriebenen Techniken, z. B. mit Bezug auf 8.
Problemlockerung und die verteilte Lösung
Um den Algorithmus zu verteilen, wird zuerst die oben mit Bezug auf die 8-9 beschriebene NN-Struktur modifiziert. Insbesondere kann ein NN-basierter Entscheider für jeden Link designiert sein, d. h. es kann separate neuronale Netzwerke (NN) für jeden BS-UE-Link geben, wie in 10 gezeigt. Obwohl in 10 als am UE befindlich veranschaulicht, können sich die NNs in gewissen Ausführungsformen an einer BS befinden, sodass eine Inferenz immer dann stattfinden kann, wenn Kanalmessungen vorgenommen werden.
11 veranschaulicht ein beispielhaftes Modell 1100 eines verteilten Richtlinienherstellers für eine verteilte NN-basierte RRM-Optimierungstechnik. In dem gezeigten Beispiel empfängt jedes jeweilige verteilte NN 1102 die Vektoren h^ji und produziert den Vektor von Parametern πⁱ(H, θ). Unter dieser neuen Struktur kann das Optimierungsproblem wie folgt sein: $\begin{array}{l} P_{θ}^{*} : = max_{θ, x \in X} \sum_{i = 1}^{m} w^{i} x^{i} \\ s . t . x^{i} \leq E_{h} [log (1 + \frac{h^{i i} π^{i} (h^{i}, θ^{i})}{Σ_{j \neq i} h^{j i} π^{j} (h^{j}, θ^{j}) + N^{i}})], \forall i \\ E_{h^{i}} [π^{i} (h^{i}, θ^{i})] \leq p_{m a x}^{i} \forall i \end{array}$
Um die Störung zu entkoppeln, kann das Problem weiter gelockert werden, indem ein neuer Satz von Variablen, ρ^ij, eingeführt wird, die die maximal erwartete Sendeleistung repräsentieren, die für TXj durch RXi erlaubt ist, wenn i ≠ j. Dann kann das Problem wie folgt werden: $\begin{array}{l} P_{θ}^{*} : = max_{θ, x, ρ \in X} \sum_{i = 1}^{m} w^{i} x^{i} \\ s . t . x^{i} \leq E_{h^{i}} [log (1 + \frac{h^{i i} π^{i} (h^{i}, θ^{i})}{Σ_{j \neq i} h^{j i} ρ^{j i} + N^{i}})], \forall i \\ E_{h^{i}} [π^{i} (h^{i}, θ^{i})] \leq p_{m a x}^{i}, \forall i \\ E_{h^{j}} [π^{j} (h^{j}, θ^{j})] \leq ρ^{j i}, \forall i, j \neq i \end{array}$
Lagrange-Variablen und eine abwechselnde Aktualisierung von primalen und dualen Parametern können, ähnlich der oben beschriebenen zentralisierten Technik, wie folgt eingeführt werden: $\begin{matrix} D_{θ}^{*} : = min_{λ, μ, ν} max_{θ, x, P} \sum_{i = 1}^{m} w^{i} x^{i} + \sum_{i = 1}^{m} λ^{i} (F^{i} (h^{i}, π^{i} (h^{i}, θ^{i}), ρ^{i}) - x^{i}) \\ - \sum_{i}^{m} μ^{i} (G^{i} (π^{i} (h^{i}, θ^{i})) - p_{m a x}^{i}) \\ - \sum_{j}^{m} \sum_{i \neq j}^{m} ν^{j i} (G^{j} (π^{j} (h^{j}, θ^{j})) - ρ^{j i}) \end{matrix}$
wobei $F^{i} (h^{i}, π^{i} (h^{i}, θ^{i}), ρ^{i}) = E_{h^{i}} [log (1 + \frac{h^{i i} π^{i} (h^{i}, θ^{i})}{Σ_{j \neq i} h^{j i} ρ^{j i} + N^{i}})], und G^{i} (π^{i} (h^{i}, θ^{i})) = E_{h^{i}} [π^{i} (h^{i}, θ^{i})] .$
Die Aktualisierung kann dementsprechend wie folgt werden: $\begin{matrix} θ_{k + 1}^{i} = θ_{k}^{i} + γ_{θ, k} [λ_{k}^{i} \nabla_{θ^{i}} F^{i} (h_{k}^{i}, π^{i} (h_{k}^{i}, θ_{k}^{i}), ρ_{k}^{i}) - μ_{k}^{i} \nabla_{θ^{i}} G^{i} (π^{i} (h_{k}^{i}, θ_{k}^{i})) \\ - \sum_{j \neq i} ν_{k}^{i j} \nabla_{θ^{i}} G^{i} (π^{i} (h_{k}^{i}, θ_{k}^{i}))] \end{matrix}$
$x_{k + 1}^{i} = P_{X} [x_{k}^{i} + γ_{x, k} (w^{i} - λ_{k}^{i})]$
$ρ_{k + 1}^{j i} = {[ρ_{k}^{j i} + γ_{P, k} [λ_{k}^{i} \nabla_{ρ^{j i}} F^{i} (h_{k}^{i}, π^{i} (h_{k}^{i}, θ_{k}^{i}), ρ_{k}^{i}) + ν_{k}^{j i}]]}_{+}$
$λ_{k + 1}^{i} = {[λ_{k}^{i} - γ_{λ, k} ({\hat{F}}^{i} (h_{k}^{i}, π^{i} (h_{k}^{i}, θ_{k + 1}^{i}), ρ_{k}^{i}) - x_{k + 1}^{i})]}_{+}$
$μ_{k + 1}^{i} = {[μ_{k}^{i} + γ_{μ, k} ({\hat{G}}^{i} (π^{i} (h_{k}^{i}, θ_{k + 1}^{i})) - p_{m a x}^{i})]}_{+}$
$ν_{k + 1}^{j i} = {[ν_{k}^{j i} + γ_{N, k} ({\hat{G}}^{j} (π^{j} (h_{k}^{j}, θ_{k + 1}^{j})) - ρ_{k + 1}^{j i})]}_{+}$
Solange der Richtlinienhersteller (NN) i Zugriff auf ρⁱ = [ρ¹ⁱ,...,ρ^ji, ...,ρ^mi]^T und [vⁱ¹,..., v^ij,...,v^im] hat, kann er $θ_{k + 1}^{i}, x_{k + 1}^{i}, λ_{k + 1}^{i} und μ_{k + 1}^{i}$
lokal aktualisieren, ohne dass ein Informationsaustausch erforderlich ist. Daher können die primalen Parameter (θⁱ, xⁱ) und die dualen Parameter (λⁱ, µⁱ) in diesem Beispiel als lokale Parameter angesehen werden. Um $ρ_{k + 1}^{j i} und v_{k + 1}^{i j}$
zu aktualisieren, müssen Informationen jedoch möglicherweise zwischen anderen Richtlinienherstellern (NNs 1102) ausgetauscht werden. Dementsprechend können ρⁱ und vⁱ als globale Parameter betrachtet werden, die zwischen BSs ausgetauscht werden müssen. Zum Beispiel kann der Link i die Informationen darüber speichern, wie viel TX-Leistung von den Sendern erwartet wird, die RXi $(ρ_{k + 1}^{j i})$
stören, sowie wie sehr die Empfänger eine Störung von TXi $(v_{k + 1}^{i j})$
erwarten, um die Leistungsentscheidung für den Link i zu bestimmen.
Da der Austausch zwischen den Richtlinienherstellern länger dauern kann, kann er seltener stattfinden, was bedeutet, dass Aktualisierungen der lokalen Parameter $θ_{k + 1}^{i}, x_{k + 1}^{i}, λ_{k + 1}^{i} und μ_{k + 1}^{i}$

unmittelbar stattfinden können, nachdem ein neuer Satz von Kanalmessungen vorgenommen wurde, wohingegen die Aktualisierungen der globalen Parameter $ρ_{k + 1}^{j i}$
und $v_{k + 1}^{i j}$
seltener stattfinden können. Das lokale Halten der NN-Parameter kann dabei helfen, dass die Inferenz schneller erfolgt, und dass das Training an diesen Parametern so schnell wie eine Ankunftsrate von Kanalmessungen erfolgt.
Vorgeschlagenes Framework zur Downlink-Steuerung
12 veranschaulicht beispielhafte lokale Operationen 1200, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Downlink-Kommunikationen stattfinden können. Für den oben beschriebenen verteilten Algorithmus kann ein Steuersignalisierungsframework, wie in 12 gezeigt, zwischen TX 1210 (BS für Downlink) und RX 1220 (UE für Downlink) in einem Paar und zwischen TXs (BSs) implementiert werden. Wie in 12 gezeigt, aktualisiert es, sobald der RX 1220 bei 1222 den aktuellen Kanal misst und Kanalmessungen $h_{k}^{i}$
erhält, bei 1224 lokale Parameter $(θ_{k}^{i}, x_{k}^{i}, λ_{k}^{i} und μ_{k}^{i})$

lokal unter Verwendung des NN bei dem RX 1220. Der RX 1220 ruft dann die Richtlinienentscheidung $(π_{k}^{i})$
ab, die auf dem NN getroffen wird, und leitet sie bei 1226 an den TX 1210 (BS) weiter. Daten können dann bei 1212 mit dem Leistungspegel übertragen werden, der durch das NN entschieden wird (d. h. basierend auf der Richtlinienentscheidung $(π_{k}^{i})$
Nach der Datenübertragung bei 1212 können die Schätzungen von Funktionen bei der Aktualisierung der globalen Parameter $(ρ_{k}^{j i} und v_{k}^{i j})$
bei 1214, 1228 durch den TX 1210 bzw. RX 1220 verwendet werden. Obwohl diese globalen Parameter nicht notwendigerweise bei jeder Iteration aktualisiert werden, beinhalten Funktionen, die für ihre Aktualisierung erforderlich sind, Schätzungen von Erwartungen über Kanalinstanzen, die bei jeder neuen Kanalbeobachtung lokal aktualisiert werden können. In Abhängigkeit von der Verfügbarkeit der erforderlichen Informationen und den Berechnungsfähigkeiten können diese Schätzungen entweder auf der TX/BS-Seite oder auf der RX/UE-Seite berechnet werden. Für die folgende Erörterung können die in 12 gezeigten lokalen Signalisierungen und lokalen Berechnungen als „lokale Operationen“ bezeichnet werden. Die in 12 gezeigten lokalen Operationen können mehrmals bis zur nächsten globalen Aktualisierung wiederholt werden, was unten unter Bezugnahme auf 13 beschrieben ist.
13 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen 1300, die in einer verteilten NN-basierten RRM-Optimierungstechnik für Downlink-Kommunikationen stattfinden können. Insbesondere veranschaulicht 13 beispielhafte Informationen, die zwischen BSs während des globalen Parameteraktualisierungsprozesses ausgetauscht werden können. Bei dem Downlink-Leistungssteuerproblem werden globale Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
in BSi oder UEi, ∀j gehalten. Die Aktualisierung von $ρ_{k + 1}^{j i}$
erfordert jedoch $v_{k}^{j i},$
was möglicherweise nicht an der BSi vorhanden ist, und die Aktualisierung von $v_{k + 1}^{i j}$
erfordert $ρ_{k + 1}^{i j},$
was möglicherweise nicht an der BSi vorhanden ist. Diese Parameter können daher unmittelbar nach ihrer Aktualisierung ausgetauscht werden. Aufgrund der hierin beschriebenen der Primal-Dual-Aktualisierungstechnik kann die globale Aktualisierungsperiode eine Aktualisierung und einen Austausch primaler Parameter und eine Aktualisierung und einen Austausch dualer Parameter beinhalten. Nach diesen Austauschen können lokale Operationen wieder fortgesetzt werden. Während globaler Austausche kann der Schritt des Aktualisierens lokaler Parameter jedoch in den lokalen Operationen übersprungen werden. Ein Vorteil eines derartigen Frameworks besteht darin, dass es eine schnellere Inferenz ermöglichen kann, da NN-Parameter (θⁱ) und Eingaben (hⁱ) lokal sind und das Training an NN-Parametern fortgesetzt werden kann, wenn neue Daten eintreffen.
In dem in 13 gezeigten Beispiel führt jedes Paar aus Zugangspunkt (AP) 1310 (der z. B. eine BS sein kann, wie in dem vorherigen Beispiel) und UE 1320 zuerst lokale Operationen 1312 durch, um lokale primale und duale Parameter für ein NN-basiertes Modell zu aktualisieren. In manchen Ausführungsformen können die lokalen Operationen 1312 die oben mit Bezug auf 12 beschriebenen Operationen beinhalten. Die lokalen Operationen 1312 können, wie gezeigt, mehrmals durchgeführt werden.
Nachdem eine Menge an Zeit oder eine bestimmte Anzahl lokaler Operationen durchgeführt wurde, werden die globalen Parameter $ρ_{k}^{j i}$
zwischen dem AP-UE-Paar bei 1314 aktualisiert und dann werden die globalen Parameter $ρ_{k}^{j i}$
bei 1302 durch die APs 1310 mit einem zentralen Gateway (GW) 1301 ausgetauscht. In manchen Ausführungsformen kann sich das zentrale Gateway 1301 entfernt vom Edge befinden, wie etwa zum Beispiel in der Zentrale 120 oder der Cloud 130 von 1, der Cloud 360 von 3 oder dem Kerndatenzentrum 650 oder der Cloud 660 von 6. Das Gateway 1301 verwendet die globalen Parameter $ρ_{k}^{j i},$
um die globalen Parameter $v_{k}^{i j}$
bei 1304 zu aktualisieren, und tauscht dann bei 1306 die globalen Parameter $v_{k}^{i j}$
mit den APs 1310 aus. Die APs 1310 leiten dann bei 1314 die aktualisierten globalen Parameter $v_{k}^{i j}$
an die UEs 1320 weiter. Danach führen die AP-UE-Paare einen anderen Satz lokaler Operationen 1316 unter Verwendung der aktualisierten globalen Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
durch. Die lokalen Operationen 1316 können gleich oder ähnlich den lokalen Operationen 1312 sein.
Erweiterungen für lokale Operationen
In manchen Fällen können zusätzliche Eingaben als Eingabe in das NN bereitgestellt werden, nicht nur die Kanalmessungen von der RX-Seite. Zum Beispiel können in manchen Ausführungsformen Kanalmessungen von der TX-Seite dem NN zusätzlich zu den Kanalmessungen von der RX-Seite bereitgestellt werden.
14 veranschaulicht erweiterte beispielhafte lokale Operationen 1400, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Downlink-Kommunikationen stattfinden können. In dem in 14 gezeigten Beispiel misst der RX 1420 (der in diesem Beispiel ein UE ist) bei 1422 den aktuellen Kanal. Außerdem misst der TX 1410 (der in diesem Beispiel eine BS ist) bei 1412 den aktuellen Kanal und stellt bei 1413 die Kanalmessungen an den RX 1420 bereit. Der RX 1420 aktualisiert die lokalen Parameter $(θ_{k}^{i}, x_{k}^{i}, λ_{k}^{i} und μ_{k}^{i})$
bei 1424 unter Verwendung der Kanalmessungen von sowohl dem TX 1410 als auch dem RX 1420. Der RX 1420 ruft dann die Richtlinienentscheidung $(π_{k}^{i})$
ab, die an dem NN des RX 1420 getroffen wird, und leitet sie bei 1426 an den TX 1410 (BS) weiter. Daten können dann bei 1414 mit dem Leistungspegel übertragen werden, der durch das NN entschieden wird (d. h. basierend auf der Richtlinienentscheidung $(π_{k}^{i})$
). Nach der Datenübertragung bei 1412 können die Schätzungen von Funktionen bei der Aktualisierung globaler Parameter ( $ρ_{k}^{j i}$
und $v_{k}^{i j}$
) bei 1416, 1428 durch den TX 1410 bzw. RX 1420 verwendet werden, wie oben beschrieben.
Außerdem kann das NN in manchen Fällen auch vergangene Beobachtungen berücksichtigen. Vergangene Entscheidungen anderer NNs können zum Beispiel verwendet werden, wenn zukünftige Leistungspegel entschieden werden, falls sie durch das NN beobachtet werden können. Ferner muss das NN die Sendeleistung nicht nur wie oben beschrieben ausgeben - es kann auch eine Entscheidung über andere Drahtloskommunikationsressourcen bereitstellen, wie etwa Frequenzbänder, auf denen übertragen werden soll usw.
Obwohl ein NN oben in den obigen Beispielen als der Richtlinienhersteller/Entscheider beschrieben ist, kann die Richtlinien-/Entscheidungsfindung in einigen Fällen durch eine parametrisierte Funktion durchgeführt werden, deren Parameter unter Verwendung eines Gradientenabstiegsprozesses (d. h. differenzierbar) optimiert werden können.
Simulationsergebnisse
Eine Simulation, die das oben beschriebene verteilte Modell mit einem zentralisierten Modell vergleicht, zeigt positive Ergebnisse. Für die Simulationseinrichtung wurde ein Störkanal mit 2 TXs und 2 RXs ausgewählt, wobei Kanäle IID mit Rayleigh (σ=1) sind, der Rauschpegel 0 dBm beträgt und die maximale TX-Leistung 10 dBm beträgt. Da die Störung höher als das Rauschen sein kann, wird das erwartete Ergebnis eine Zeitteilung zwischen 2 Links sein. Es wurden 32 + 16 verborgene Einheiten bei jedem Richtlinienhersteller verwendet. Die Backhaul-Verzögerung wurde ignoriert, um sich speziell auf die Leistungsfähigkeit des Algorithmus zu konzentrieren. Die Schrittgrößen wurden als γ_θ,k = γ_x,k = γ_x,k = γ_µ,k = 0.01 und γ_P,k = γ_N,k = 0.01 E ausgewählt, wobei E die Anzahl von Aktualisierungen lokaler Parameter ist, die vor einer globalen Aktualisierung vorgenommen wurden. Der Begriff „föderiert“ wird im Folgenden und in den 15-17 immer dann verwendet, wenn E größer als eins ist, um hervorzuheben, dass das Lernen (θ-Aktualisierung) fortgesetzt wird, wenn neue Daten eintreffen, selbst wenn diese Aktualisierungen nicht durch eine zentrale Synchronisation abgeschlossen werden.
Wie in den 15-16 gezeigt, folgen die sofortigen Entscheidungen und die resultierende Kapazität ähnlichen Tendenzen für den zentralen Algorithmus und verteilten Algorithmus für E ∈ {1,2,5,10,20}. Wenn jedoch E 50 oder 100 ist, folgt sie einer anderen Zeitteilungsrichtlinie, bei der die Periodizität viel höher ist. Betrachtet man die durchschnittliche Rate über 4000 Simulationsmale (Anzahl an Kanalmessungen) in 17, beeinflusst die Auswahl von E die Leistungsfähigkeit aufgrund der Lernratenanpassung globaler Variablen nicht. Die Summenratendifferenz zwischen zentralen und verteilten Lösungen beruht auf einer langsameren Konvergenzrate zur Richtlinie. Während des langsamen Starts bei der Konvergenz mit verteiltem Algorithmus ergreifen Richtlinien für beide Vorrichtungen konservative Schritte in Richtung der optimalen Richtlinie.
Beispielhafte Implementierungen
Bei manchen Implementierungsbeispielen nutzt ein Richtlinienhersteller für RRM-Entscheidungen (z. B. eine BS oder eine rechnerisch fähigere Seite des Downlinks) Parameter, die über einen Gradientenabstiegsprozess trainiert werden, um die RRM-Entscheidungen zu treffen. Der Richtlinienhersteller kann in einigen Fällen ein neuronales Netzwerk oder eine parametrisierte Funktion sein, deren Parameter unter Verwendung eines Gradientenabstiegsprozesses optimiert werden können. Eingaben in den Richtlinienhersteller oder Eingaben in die Richtlinienhersteller-Gradientenaktualisierungsfunktion können unter anderem lokale Kanalbeobachtungen, vergangene lokale Entscheidungen, lokal beobachtbare vergangene Entscheidungen anderer Richtlinienhersteller, lokale Beschränkungen und globale Rückmeldung, die sie von anderen Richtlinienherstellern empfangen, beinhalten. Jeder Richtlinienhersteller kann unabhängig so viele Störer auswählen, wie er ein neuronales Netzwerk (NN) (z. B. ein faltendes neuronales Netzwerk (CNN)) oder einen beliebigen anderen Maschinenlernalgorithmus (ML-Algorithmus) verfolgen und anwenden kann, um permutierte störende Kanaldaten zu nutzen. Der Richtlinienhersteller kann lokale Parameteraktualisierungen über Gradientenabstieg nach Kanalmessungen oder Messrückmeldung und vor dem Treffen der RRM-Entscheidung für diese Kanalbedingungen aufweisen. Der Richtlinienhersteller oder die BS kann vordefinierte RRM-Funktionswerte basierend auf den aktuellen und vorherigen Entscheidungen und Leistungsfähigkeiten aktualisieren.
Bei manchen Implementierungsbeispielen beinhaltet eine globale Aktualisierungsperiode für das gesamte Netzwerk die folgenden Operationen. Lokale Parameter können vor einer globalen Parameteraktualisierungsperiode (z. B. der globalen Aktualisierungsperiode, die in 13 gezeigt ist, einschließlich der Operationen 1302, 1304, 1306) liegen (oder bleiben während dieser unverändert). Globale Parameterinformationen können an der BS berechnet werden oder können vor der BS-zu-GW-Kommunikation durch das UE berechnet und an die BS gesendet werden. Die globalen Parameterinformationen können durch die BS mit dem GW geteilt werden und können durch das GW in Bezug auf globale Parameterinformationen, die Anzahl lokaler Aktualisierungen seit der letzten globalen Aktualisierung und/oder die seit der letzten Aktualisierung verstrichene Zeit aktualisiert werden. Die aktualisierten globalen Parameter können danach mit relevanten APs geteilt werden und können mit dem UE (falls es der Richtlinienhersteller für die RRM-Entscheidungen ist) geteilt werden.
Leistungsverwaltung in einem zellularen Uplink-Kanal
Legacy-Leistungssteuerlösungen in einem zellularen Uplink-Kanal basieren auf einem gewünschten SNR an der Basisstation (BS), die der Empfänger (RX) der Uplink-Datenkommunikation ist. Sie berücksichtigen normalerweise nicht die Störung, die sie von einem anderen Benutzergerät (UE) hören, oder die Störung, die sie für benachbarte BSs verursachen. Eine Erweiterung der oben für Downlink-Kommunikationen beschriebenen Techniken kann auf Uplink-Kommunikationen angewendet werden.
18 veranschaulicht ein beispielhaftes System 1800, das eine verteilte NN-basierte RRM-Optimierungstechnik für Uplink-Kommunikationen implementiert. In dem gezeigten Beispiel ähnelt die Systemarchitektur jener von 10 mit der Ausnahme, dass jedes BS (RX) 1806 sein eigenes NN 1810 implementiert. Die BS 1806 erzeugt Optimierungsparameter, die über das Backhaul an die andere BS 1806 und an das Gateway 1804 und den Aggregator 1802 verteilt werden. Die NNs 1810 können im Gegenzug die gemeinsam genutzten Optimierungsparameter einsetzen, um zu RRM-Entscheidungen zu gelangen. Die Optimierungsparameter können in manchen Fällen so oft wie einmal in einer Kanalkohärenzperiode gemeinsam genutzt werden. Diese Optimierungsparameter können weniger Bandbreite nutzen als das gemeinsame Nutzen von Kanalmessungen, die oben mit Bezug auf die zentralisierten Techniken beschrieben sind, und können folglich einen oder mehrere Vorteile gegenüber zentralisierten RRM-Optimierungstechniken bereitstellen. RRM-Entscheidungen müssen immer noch oft ausgetauscht werden, müssen aber nicht wie bei den zentralisierten Techniken über das Backhaul ausgetauscht werden.
In manchen Ausführungsformen kann ein Steuersignalisierungsframework 1900, wie in 19 gezeigt, zwischen TX (UE) 1910 und RX (BS) 1920 in einem Paar und zwischen RXs (BSs) genutzt werden. Wie in 19 gezeigt, aktualisiert es, sobald der RX 1920 (BS in Uplink-Ausführungsform) den aktuellen Kanal bei 1922 misst, lokale Parameter $(θ_{k}^{i}, x_{k}^{i}, λ_{k}^{i} und μ_{k}^{i})$
bei 1924 lokal und ruft dann die Entscheidung, die über das aktualisierte NN getroffen wird (die Richtlinienentscheidung $(π_{k}^{i})$
) ab und leitet sie bei 1926 an den TX (UE) 1910 weiter. Danach können Daten bei 1912 mit dem Leistungspegel übertragen werden, der durch das NN entschieden wird (z. B. basierend auf der Richtlinienentscheidung $(π_{k}^{i})$
).
Nach der Datenübertragung bei 1912 können die Schätzungen von Funktionen bei der Aktualisierung globaler Parameter $(ρ_{k}^{j i} und v_{k}^{i j})$
bei 1928 durch den RX (BS) 1920 verwendet werden. Obwohl diese globalen Parameter nicht notwendigerweise bei jeder Iteration aktualisiert werden, beinhalten Funktionen, die für ihre Aktualisierung erforderlich sind, Schätzungen von Erwartungen über Kanalinstanzen, die bei jeder neuen Kanalbeobachtung lokal aktualisiert werden können. Unter der Annahme, dass die BS hinsichtlich der Berechnung fähiger ist und näher am Rest der Arbeit liegt, können diese Schätzungen an der BS berechnet werden. Wie zuvor können diese in 19 gezeigten lokalen Signalisierungen und lokalen Berechnungen als „lokale Operationen“ bezeichnet werden. Die in 19 gezeigten lokalen Operationen können mehrmals bis zur nächsten globalen Aktualisierung wiederholt werden, was unten unter Bezugnahme auf 20 beschrieben ist.
Wie in dem obigen Downlink-Fall, können einige Informationen zwischen BSs während der globalen Parameteraktualisierung ausgetauscht werden. 20 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen 2000, die in einer verteilten NN-basierten RRM-Optimierungstechnik für Uplink-Kommunikationen stattfinden können. Bei dem Uplink-Leistungssteuerproblem werden globale Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
in der BSi, ∀j gehalten. Die Aktualisierung von $ρ_{k + 1}^{j i}$
erfordert jedoch $v_{k}^{j i},$
was möglicherweise nicht an der BSi vorhanden ist, und die Aktualisierung von $v_{k + 1}^{i j}$
erfordert $ρ_{k + 1}^{i j},$
was möglicherweise nicht an der BSi vorhanden ist. Diese Parameter können daher unmittelbar nach ihrer Aktualisierung ausgetauscht werden. Aufgrund der der Primal-Dual-Aktualisierungstechnik kann die globale Aktualisierungsperiode eine Aktualisierung und einen Austausch primaler Parameter und eine Aktualisierung und einen Austausch dualer Parameter beinhalten. Nach diesen Austauschen können lokale Operationen wie beschrieben fortgesetzt werden. Während globaler Austausche kann der Schritt zum Aktualisieren lokaler Parameter jedoch in den lokalen Operationen übersprungen werden. 20 zeigt die globale Aktualisierungsperiode, in der diese Berechnungen und dieser Austausch stattfinden. Einige Vorteile, ein solches Framework aufzuweisen, können beinhalten, dass es eine schnellere Inferenz ermöglicht, da NN-Parameter (θⁱ) und Eingaben (hⁱ) lokal sind, und dass das Training an NN-Parametern fortgesetzt werden kann, wenn neue Daten eintreffen, ähnlich dem Downlink.
In dem in 20 gezeigten Beispiel führt jedes Paar aus Zugangspunkt (AP) 2010 (z. B. BS) und UE 2020 zuerst die lokalen Operationen 2012 durch, um lokale primale und duale Parameter für ein NN-basiertes Modell zu aktualisieren. In manchen Ausführungsformen können die lokalen Operationen 2012 die oben mit Bezug auf 19 beschriebenen Operationen beinhalten. Die lokalen Operationen 2012 können, wie gezeigt, mehrmals durchgeführt werden.
Nach einer gewissen Menge an Zeit oder einer gewissen Anzahl von Iterationen der lokalen Operationen 2012 werden die globalen Parameter $ρ_{k}^{j i}$
zwischen dem AP-UE-Paar bei 2014 aktualisiert und dann werden die globalen Parameter $ρ_{k}^{j i}$
bei 2002 durch die APs 2010 mit einem zentralen Gateway 2001 ausgetauscht. Das Gateway 2001 verwendet die globalen Parameter $ρ_{k}^{j i},$
um die globalen Parameter $v_{k}^{i j}$
bei 2004 zu aktualisieren, und tauscht dann bei 2006 die globalen Parameter $v_{k}^{i j}$
mit den APs 2010 aus. Danach führen die AP-UE-Paare einen anderen Satz lokaler Operationen 2016 unter Verwendung der aktualisierten globalen Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
durch. Die lokalen Operationen 2016 können gleich oder ähnlich den lokalen Operationen 2012 sein.
Erweiterungen für lokale Operationen
Zusätzliche Eingaben können als Eingabe in das NN bereitgestellt werden, nicht nur die Kanalmessungen von der RX-Seite. Zum Beispiel können in manchen Ausführungsformen Kanalmessungen von der TX-Seite dem NN zusätzlich zu den Kanalmessungen von der RX-Seite bereitgestellt werden.
21 veranschaulicht erweiterte beispielhafte lokale Operationen 2100, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Uplink-Kommunikationen stattfinden können. In dem in 21 gezeigten Beispiel misst der RX 2120 bei 2122 den aktuellen Kanal. Gleichermaßen misst der TX 2110 bei 2112 den aktuellen Kanal und stellt bei 2113 die Kanalmessungen an den RX 2120 bereit. Der RX 2120 aktualisiert lokale Parameter $(θ_{k}^{i}, x_{k}^{i}, λ_{k}^{i} und μ_{k}^{i})$
lokal bei 2124 unter Verwendung der Kanalmessungen von sowohl dem TX 2110 als auch dem RX 2120. Der RX 2120 ruft dann die Entscheidung über das aktualisierte NN ab (die Richtlinienentscheidung $(π_{k}^{i})$
) und leitet sie bei 2126 an den TX 2110 (UE) weiter. Daten können dann bei 2114 mit dem Leistungspegel übertragen werden, der durch das NN entschieden wird (d. h. basierend auf der Richtlinienentscheidung $(π_{k}^{i})$
). Nach der Datenübertragung bei 2112 können die Schätzungen von Funktionen bei der Aktualisierung globaler Parameter ( $ρ_{k}^{j i}$
und $v_{k}^{i j}$
) bei 2128 durch den RX 2120 verwendet werden, wie oben beschrieben.
Außerdem kann das NN in manchen Fällen auch vergangene Beobachtungen berücksichtigen. Vergangene Entscheidungen anderer NNs können zum Beispiel verwendet werden, wenn zukünftige Leistungspegel entschieden werden, falls sie durch das NN beobachtet werden können. Ferner muss das NN die Sendeleistung nicht nur wie oben beschrieben ausgeben. Es kann auch eine Entscheidung über andere Drahtloskommunikationsressourcen bereitstellen, wie etwa Frequenzbänder, auf denen übertragen werden soll usw.
Obwohl ein NN oben in den obigen Beispielen als der Richtlinienhersteller/Entscheider beschrieben ist, kann die Richtlinien-/Entscheidungsfindung in einigen Fällen durch eine parametrisierte Funktion durchgeführt werden, deren Parameter unter Verwendung eines Gradientenabstiegsprozesses (d. h. differenzierbar) optimiert werden können.
Beispielhafte Implementierungen
Bei manchen Implementierungsbeispielen nutzt ein Richtlinienhersteller für RRM-Entscheidungen (z. B. eine BS oder eine rechnerisch fähigere Seite des Downlinks) Parameter, die über einen Gradientenabstiegsprozess trainiert werden, um die RRM-Entscheidungen zu treffen. Der Richtlinienhersteller kann in einigen Fällen ein neuronales Netzwerk oder eine parametrisierte Funktion sein, deren Parameter unter Verwendung eines Gradientenabstiegsprozesses optimiert werden können. Eingaben in den Richtlinienhersteller oder Eingaben in die Richtlinienhersteller-Gradientenaktualisierungsfunktion können unter anderem lokale Kanalbeobachtungen, vergangene lokale Entscheidungen, lokal beobachtbare vergangene Entscheidungen anderer Richtlinienhersteller, lokale Beschränkungen und globale Rückmeldung, die sie von anderen Richtlinienherstellern empfangen, beinhalten. Jeder Richtlinienhersteller kann unabhängig so viele Störer auswählen, wie er ein CNN oder einen beliebigen anderen ML-Algorithmus verfolgen und anwenden kann, um permutierte störende Kanaldaten zu nutzen. Der Richtlinienhersteller kann lokale Parameteraktualisierungen über Gradientenabstieg nach Kanalmessungen oder Messrückmeldung und vor dem Treffen der RRM-Entscheidung für diese Kanalbedingungen aufweisen. Der Richtlinienhersteller (z. B. BS) kann vordefinierte RRM-Funktionswerte basierend auf den aktuellen und vorherigen Entscheidungen und Leistungsfähigkeiten aktualisieren.
Bei manchen Implementierungsbeispielen beinhaltet eine globale Aktualisierungsperiode für das gesamte Netzwerk die folgenden Operationen. Lokale Parameter können vor einer globalen Parameteraktualisierungsperiode (z. B. der globalen Aktualisierungsperiode, die in 20 gezeigt ist, einschließlich der Operationen 2002, 2004, 2006) aktualisiert werden (oder während dieser unverändert bleiben). Globale Parameterinformationen können an der BS berechnet werden und können mit dem GW geteilt werden. Globale Parameter können durch das GW in Bezug auf globale Parameterinformationen, die Anzahl lokaler Aktualisierungen seit der letzten globalen Aktualisierung und/oder die Zeit, die seit der letzten Aktualisierung verstrichen ist, aktualisiert werden. Die aktualisierten globalen Parameter können mit anderen BSs geteilt werden.
Leistungssteuerung in drahtlosen Ad-hoc-Umgebungen
Das oben beschriebene verteilte Framework kann für Verwendungsfälle erweitert werden, die auch drahtlose Ad-hoc-Netzwerkverbindungen beinhalten. Anstatt zum Beispiel eine RRM-Entscheidungsstruktur für ein gesamtes Netzwerk in einem zentralen Knoten aufzuweisen, können manche Ausführungsformen eine individuelle RRM-Entscheidungsteilstruktur für jeden Link auf der Vorrichtungsseite (entweder als Sender oder Empfänger) nutzen, sodass sowohl Inferenz als auch Training lokaler Parameter basierend auf neuen Kanalmessungen auf eine Online-Weise an der Edge-Vorrichtung fortgesetzt werden können. Obwohl den obigen Ansätzen ähnlich, kann die dezentralisierte Technik auf Ad-hoc-Netzwerke erweitert werden, indem parameterspezifische Aggregatoren anstelle eines einzigen Aggregators (z. B. Aggregatoren 1002, 1802) vorhanden sind. Jeder Aggregator kann für die Aktualisierung eines anderen Satzes von Parametern zuständig sein.
22 veranschaulicht ein beispielhaftes System 2200, das eine verteilte NN-basierte RRM-Optimierungstechnik in einem Ad-hoc-Netzwerk implementiert. In dem gezeigten Beispiel befinden sich alle Aggregatoren 2210 auf TX-Knoten 2206 des Ad-hoc-Netzwerksystems 2200 (das gezeigte Beispiel bezieht sich auf die Downlink-Implementierung). Jeder Aggregator 2210 kann für einen einzelnen Satz von Aktualisierungen von Primal-Dual-Variablen zuständig sein. Da die Parameterabhängigkeit durch den Drahtlos-Interferenzgraphen bestimmt wird, kann es ausreichend sein, direkte Kommunikationslinks zwischen störenden TX-Knoten 2206 aufzuweisen. Diese Struktur kann bei der Skalierbarkeit der vorgeschlagenen Architektur helfen. Ansonsten kann das System 2200 ähnlich dem System 1000 von 10 funktionieren. Das heißt, die RX-Knoten 2208 erzeugen Optimierungsparameter, die an die TX-Knoten 2206 und die Aggregatoren 2210 verteilt werden. Die NNs 2210 können im Gegenzug die gemeinsam genutzten Optimierungsparameter einsetzen, um zu RRM-Entscheidungen zu gelangen. Die Optimierungsparameter können in manchen Fällen so oft wie einmal in einer Kanalkohärenzperiode gemeinsam genutzt werden. Obwohl die NNs 2210 in 22 als sich bei den RXs 2208 befindlich veranschaulicht sind, können sich eines oder mehrere der NNs 2210 stattdessen an den TXs 2206 befinden. Beispielsweise kann sich ein NN 2210a bei RX 2208a befinden, wie gezeigt, während sich NN 2210b bei TX 2206b befinden kann. Gleichermaßen können sich in manchen Ausführungsformen alle NNs 2210 an den TXs 2206 befinden.
Wie in den anderen Ausführungsformen kann diese Ausführungsform Vorrichtungen mit heterogenen Berechnungsfähigkeiten ermöglichen, eine RRM-Lösung auf eine föderierte Weise zu entwickeln, was reduzierte Rückmeldung sowie Online-Lösungsansätze ermöglicht, die sich im Gegensatz zu dem Framework für die zentrale Lösung besser an lokale Bedingungen anpassen können. Des Weiteren können solche Ausführungsformen beim Skalieren der drahtlosen Ad-hoc-Netzwerke helfen, während Störungen berücksichtigt werden.
In manchen Ausführungsformen kann ein Steuersignalisierungsframework, wie in 23 gezeigt, zwischen dem TX 2310 und dem RX 2320 genutzt werden. Bei dem gezeigten Beispiel kann sich die Sendervorrichtung (TX) auf die Sendeseite der drahtlosen Datenübertragung beziehen. Sie kann sowohl Übertragungs- als auch Empfangsfähigkeiten aufweisen, wenn Steuersignale, ein Pilotsignal oder Kanalzustandsinformationen ausgetauscht werden. Ferner kann sich die Empfängervorrichtung (RX) auf die Empfangsseite der drahtlosen Datenübertragung beziehen. Sie kann sowohl Übertragungs- als auch Empfangsfähigkeiten aufweisen, wenn Steuersignale, ein Pilotsignal oder Kanalzustandsinformationen ausgetauscht werden.
Wie in 23 gezeigt, aktualisiert sie, sobald der RX 2320 bei 2322 den aktuellen Kanal misst, bei 2324 lokale Parameter ( $θ_{k}^{i}, x_{k}^{i}, λ_{k}^{i}$
und $μ_{k}^{i}$
) lokal, ruft die Entscheidung über das aktualisierte NN ab und leitet sie bei 2326 an den TX 2310 weiter. Daten können dann bei 2312 mit dem Leistungspegel übertragen werden, der durch das NN entschieden wird. Nach der Datenübertragung 2312 können die Schätzungen von Funktionen bei der Aktualisierung globaler Parameter ( $ρ_{k}^{j i}$
und $v_{k}^{i j}$
) bei 2314, 2328 durch den TX 2310 bzw. RX 2320 verwendet werden. Obwohl diese globalen Parameter nicht notwendigerweise bei jeder Iteration aktualisiert werden, beinhalten Funktionen, die für ihre Aktualisierung erforderlich sind, Schätzungen von Erwartungen über Kanalinstanzen, die bei jeder neuen Kanalbeobachtung lokal aktualisiert werden können. In Abhängigkeit von der Verfügbarkeit der erforderlichen Informationen und den Berechnungsfähigkeiten können diese Schätzungen entweder auf der TX-Seite oder auf der RX-Seite berechnet werden. Wie oben beschrieben, können die in 23 gezeigten lokalen Signalisierungen und lokalen Berechnungen als „lokale Operationen“ bezeichnet werden. Die lokalen Operationen können immer wieder wiederholt werden, bis die nächste globale Aktualisierung durchgeführt wird, wie unten beschrieben.
Wie bei den oben beschriebenen Techniken können manche Informationen zwischen Zugangspunkten (AP) während der globalen Parameteraktualisierung ausgetauscht werden. In einem verallgemeinerten Netzwerkkontext (einschließlich Ad-hoc-, zellularen, WiFi-Netzwerken usw.) kann sich ein Zugangspunkt (AP) auf einen Knoten (entweder TX oder RX) in einem Datentransfer beziehen, der einen kürzeren Pfad zu Zugangspunkten anderer Datenübertragungsknoten aufweist. WiFi-Zugangspunkte sind zum Beispiel 1 Sprung näher an anderen WiFi-Zugangspunkten als ihre Clients an anderen WiFi-Zugangspunkten. Basisstationen in einem zellularen Netzwerk sind ein anderes Beispiel. Fahrzeuge in einem Mesh-Netzwerk können bei diesem Konzept auch als Zugangspunkte angesehen werden, bei denen Backhaul-Kommunikation über eine V2V-Kommunikation oder über installierte stationäre Ausrüstung an den Straßen gehandhabt wird. Ferner kann sich in dem verallgemeinerten Kontext ein Benutzergerät (UE) auf einen Knoten (entweder TX oder RX) in dem Datentransfer beziehen, der kein AP ist, wie etwa WiFi-Benutzer oder zellulare UEs. IoT-Vorrichtungen (oder handgehaltene Vorrichtungen) in einem Fahrzeug, die drahtlos mit dem Modem des Fahrzeugs verbunden sind, sind ein anderes Beispiel für ein UE in diesem Kontext. Ein zentraler Knoten (CN) in dem verallgemeinerten Kontext kann sich auf einen Knoten in dem Netzwerk beziehen, der einen Link zu mehr als einem AP aufweist. Die Links von jedem AP zu dem zentralen Knoten können eine niedrigere Latenz als die Links zwischen APs aufweisen. Es kann in einigen Fällen mehr als einen zentralen Knoten geben (z. B. wie in 30 gezeigt).
Ein Richtlinienhersteller kann sich auf eine parametrisierte Funktion beziehen, die die lokale RRM-Richtlinie (eine für jedes TX-RX-Paar) angesichts aller aktuellen und vergangenen Beobachtungen über den Kanalzustand und vergangenen Richtlinienentscheidungen bestimmt. Der Richtlinienhersteller kann in Bezug auf seine Parameter unterscheidbar sein, und das Ergebnis der Richtlinie muss nicht deterministisch sein. Es kann sich um Parameter einer bestimmten Wahrscheinlichkeitsverteilung handeln, aus der die RRM-Entscheidung gesampelt wird. Der Richtlinienhersteller kann sich in Abhängigkeit von Berechnungsfähigkeiten von Knoten entweder bei TX oder bei RX befinden. Der Knoten (TX oder RX) mit mehr Berechnungsressourcen kann in einigen Fällen der Richtlinienhersteller sein. Er kann sich auch entweder am UE oder am AP befinden (obwohl es in einigen Fällen bevorzugt sein kann, ihn am AP zu haben, z. B. um die Anzahl von Kommunikationsschritten zu reduzieren, die während der globalen Aktualisierungsperiode erforderlich sind). Globale Parameterinformationen können sich auf eine beliebige Information über den globalen Parameter beziehen. Das heißt, sie können den Gradientenwert, die Schrittgröße, Komponenten für den Gradienten oder den globalen Parameter selbst beinhalten.
Bei dem Leistungssteuerproblem werden globale Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
in APi oder UEi, ∀j gehalten. Die Aktualisierung von $ρ_{k + 1}^{j i}$
erfordert jedoch $v_{k}^{j i},$
was möglicherweise nicht am APi vorhanden ist, und die Aktualisierung von $v_{k + 1}^{i j}$
erfordert $ρ_{k + 1}^{i j},$
was möglicherweise nicht am APi vorhanden ist. Daher müssen diese Parameter unmittelbar nach ihrer Aktualisierung ausgetauscht werden. Aufgrund des Primal-Dual-Aktualisierungsverfahrens in der vorliegenden Offenbarung kann die globale Aktualisierungsperiode eine Aktualisierung und einen Austausch für primale Parameter und eine Aktualisierung und einen Austausch für duale Parameter beinhalten. Nach diesen Austauschen können lokale Operationen wie unten beschrieben fortgesetzt werden. In einigen Fällen kann während globaler Austausche der Schritt zum Aktualisieren lokaler Parameter in den lokalen Operationen übersprungen werden.
24 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen 2400, die in einer verteilten NN-basierten RRM-Optimierungstechnik für Ad-hoc-Netzwerke stattfinden können. Insbesondere veranschaulicht 24 eine beispielhafte globale Aktualisierungsperiode, in der diese Berechnungen und dieser Austausch stattfinden. Im Gegensatz zu den oben mit Bezug auf die 8-21 beschriebenen Techniken kann es mehrere zentrale Knoten (CNs) oder mehrere APs geben, die als zentrale Knoten arbeiten können. Ein Vorteil eines solchen Frameworks besteht darin, dass es eine schnellere Inferenz ermöglichen kann, da NN-Parameter (θⁱ) und Eingaben (hⁱ) lokal sind und das Training an NN-Parametern fortgesetzt werden kann, wenn neue Daten eintreffen.
In dem in 24 gezeigten Beispiel führt jedes Paar aus AP 2410 und UE 2420 zuerst die lokalen Operationen 2412 durch, um lokale primale und duale Parameter für ein NN-basiertes Modell zu aktualisieren. In manchen Ausführungsformen können die lokalen Operationen 2412 die oben mit Bezug auf 23 beschriebenen Operationen beinhalten. Die lokalen Operationen 2412 können, wie gezeigt, mehrmals durchgeführt werden.
Nach einer gewissen Menge an Zeit oder einer gewissen Anzahl von Iterationen der lokalen Operationen 2412 werden die globalen Parameter $ρ_{k}^{j i}$
zwischen dem AP-UE-Paar bei 2414 aktualisiert und dann werden die globalen Parameter $ρ_{k}^{j i}$
bei 2402 unter den APs ausgetauscht. Die APs verwenden dann die globalen Parameter $ρ_{k}^{j i},$
um die globalen Parameter $v_{k}^{i j}$
bei 2416 zu aktualisieren, und tauschen dann bei 2406 die globalen Parameter $v_{k}^{i j}$
mit den anderen APs 2410 aus. In einigen Fällen können den APs 2410 jeweils ein jeweiliger Teilsatz der globalen Parameter zur Aktualisierung zugewiesen werden. Danach führen die AP-UE-Paare einen anderen Satz lokaler Operationen 2418 unter Verwendung der aktualisierten globalen Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
durch. Die lokalen Operationen 2418 können gleich oder ähnlich den lokalen Operationen 2412 sein.
Voraktualisierungsoperationen
25 veranschaulicht einen Satz von Voraktualisierungsoperationen 2500, die für eine verteilte NN-basierte RRM-Optimierungstechnik durchgeführt werden können. Die Voraktualisierungsoperationen können ein anfänglicher Teil einer globalen Aktualisierungsperiode sein, in der Informationen über globale Parameter an einem AP erhalten werden. Falls sich der Richtlinienhersteller an dem AP befindet oder falls ausreichend RRM-Funktionsaktualisierungen in lokalen Operationen in dem AP durchgeführt werden, dann können die Informationen direkt an dem AP berechnet werden. Andernfalls können sie (zumindest teilweise) an dem UE berechnet und an den AP gesendet werden. Zum Beispiel unter Bezugnahme auf 25 führt das UE 2520 einen Teil einer globalen Parameterinformationsberechnung durch und überträgt die Informationen bei 2526 zu dem AP 2510, wodurch der AP 2510 die verbleibenden globalen Parameterinformationsberechnungen durchführt.
Globaler Parameterinformationsaustausch
Sobald berechnet, können die globalen Parameterinformationen zwischen den APs eines Netzwerks ausgetauscht werden, um globale Parameter zu aktualisieren, für die sie verantwortlich sind. Zusammen mit diesen Informationen kann jeder AP die Anzahl lokaler Parameteraktualisierungen, die stattgefunden haben, und die Zeit, die seit der letzten globalen Aktualisierung verstrichen ist, senden. In bestimmten Fällen kann der AP auch andere Hyperparameter senden, die seit der letzten Aktualisierung verwendet wurden oder die in den nächsten Aktualisierungen verwendet werden. Diese Übertragungen können in Abhängigkeit von der Art der Informationen Multicast, Unicast oder Broadcast sein. Sie können auch durch Zwischenknoten (wie etwa einen zentralen Knoten in einem System) erfolgen. Jeder AP kann den Teilsatz von APs (z. B. dominante Störer für ihre Datenübertragung) auswählen, wenn die Beschränkungen für das Problem auferlegt werden, und dann nur zwischen ihnen kommunizieren. Sobald alle Komponenten empfangen wurden, können die APs die globale Parameteraktualisierung durchführen. Falls die Aktualisierung für globale Parameter eines AP durch einen CN gehandhabt wird (z. B. wie oben beschrieben), dann tauschen andere APs globale Parameterinformationen mit diesem zentralen Knoten aus.
Es können zwei Sätze von Informationen ausgetauscht werden, um eine aufeinanderfolgende Primal-Dual-Aktualisierung in dem Algorithmus zu ermöglichen. Beim ersten Austausch werden $λ_{k}^{i} \nabla_{ρ^{j i}} F^{i} (h_{k}^{i}, π^{i} (h_{k}^{i}, θ_{k}^{i}), ρ_{k}^{i})$
und $v_{k}^{j i}$
mit Aggregatorknoten (entweder dem zentralen Knoten oder anderen APs) gemeinsam genutzt. Beim zweiten werden $ρ_{k + 1}^{i j}$
mit APs gemeinsam genutzt. In einigen Fällen können die APs die globale Parameteraktualisierung vornehmen. In manchen Fällen können sie diese Aufgabe an ihre UEs oder an einen CN auslagern.
Nachaktualisierungsoperationen
26 veranschaulicht einen Satz von Nachaktualisierungsoperationen 2600, die für eine verteilte NN-basierte RRM-Optimierungstechnik durchgeführt werden können. Sobald die APs Informationen über globale Parameter empfangen, die durch das Netzwerk aktualisiert werden und die durch ihre Richtlinie benötigt werden, können sie die dualen Parameter aktualisieren und diese Parameter an ihre UEs weiterleiten, falls sich der Richtlinienhersteller auf der UE-Seite befindet, oder die dualen Parameter am UE aktualisieren. Zum Beispiel, wie in 26 gezeigt, führt der AP 2610 bei 2612 einen Teil der globalen Parameteraktualisierung durch und sendet bei 2626 die aktualisierten globalen Parameter an das UE 2620. Das UE 2626 führt dann bei 2622 die verbleibenden Teile der globalen Parameteraktualisierung durch.
Erweiterungen für lokale Operationen
Zusätzliche Eingaben können als Eingabe in das NN bereitgestellt werden, nicht nur die Kanalmessungen von der RX-Seite. Zum Beispiel können in manchen Ausführungsformen Kanalmessungen von der TX-Seite dem NN zusätzlich zu den Kanalmessungen von der RX-Seite bereitgestellt werden.
27 veranschaulicht erweiterte beispielhafte lokale Operationen 2700, die zwischen einem TX und RX in einer verteilten NN-basierten RRM-Optimierungstechnik für Ad-hoc-Netzwerke stattfinden können. In dem in 27 gezeigten Beispiel misst der RX 2720 bei 2722 den aktuellen Kanal. Gleichermaßen misst der TX 2710 bei 2712 den aktuellen Kanal und stellt bei 2713 die Kanalmessungen an den RX 2720 bereit. Der RX 2720 aktualisiert lokale Parameter ( $θ_{k}^{i}, x_{k}^{i}, λ_{k}^{i}$
und $μ_{k}^{i}$
) lokal bei 2724 unter Verwendung der Kanalmessungen von sowohl dem TX 2710 als auch dem RX 2720. Der RX 2720 ruft dann die Entscheidung über das aktualisierte NN ab und leitet sie bei 2726 an den TX 2710 (UE) weiter. Daten können dann bei 2714 mit dem Leistungspegel übertragen werden, der durch das NN entschieden wird. Nach der Datenübertragung bei 2712 können die Schätzungen von Funktionen bei der Aktualisierung globaler Parameter ( $ρ_{k}^{j i}$
und $v_{k}^{i j}$
) bei 2728 durch den RX 2720 und bei 2716 durch den TX 2710 verwendet werden.
Außerdem kann das NN in manchen Fällen auch vergangene Beobachtungen berücksichtigen. Vergangene Entscheidungen anderer NNs können zum Beispiel verwendet werden, wenn zukünftige Leistungspegel entschieden werden, falls sie durch das NN beobachtet werden können. Ferner muss das NN die Sendeleistung nicht nur wie oben beschrieben ausgeben. Es kann auch eine Entscheidung über andere Drahtloskommunikationsressourcen bereitstellen, wie etwa Frequenzbänder, auf denen übertragen werden soll usw.
Obwohl ein NN oben in den obigen Beispielen als der Richtlinienhersteller/Entscheider beschrieben ist, kann die Richtlinien-/Entscheidungsfindung in einigen Fällen durch eine parametrisierte Funktion durchgeführt werden, deren Parameter unter Verwendung eines Gradientenabstiegsprozesses (d. h. differenzierbar) optimiert werden können.
28 veranschaulicht ein anderes beispielhaftes System 2800, das eine verteilte NN-basierte RRM-Optimierungstechnik implementiert. In dem gezeigten Beispiel ähnelt die Systemarchitektur jener von 10, mit der Ausnahme, dass die Verantwortlichkeiten des Aggregators zwischen dem Aggregator 2802a an dem Gateway 2804 und dem Aggregator 2802b an der Basisstation/dem AP 2806m geteilt werden. Jedes UE 2808 implementiert sein eigenes NN 2810. Die UEs 2808 erzeugen Optimierungsparameter, die an die BS 2806 verteilt werden. Die NNs 2810 können die gemeinsam genutzten Optimierungsparameter nutzen, um zu RRM-Entscheidungen zu gelangen.
29 veranschaulicht beispielhafte globale Parameteraktualisierungsoperationen 2900 für das System 2800 von 29. In dem in 29 gezeigten Beispiel führt jedes Paar aus AP 2910 und UE 2920 zuerst die lokalen Operationen 2912 durch, wie oben beschrieben. Nach einer Menge an Zeit werden Voraktualisierungsoperationen bei 2914 durch das AP-UE-Paar durchgeführt. Globale Parameter $ρ_{k}^{j i}$
können zum Beispiel aktualisiert werden, z. B. wie oben mit Bezug auf 25 beschrieben. Als Nächstes werden dann die globalen Parameter $ρ_{k}^{j i}$
bei 2902 durch die APs 2910 mit dem zentralen Knoten 2901 (z. B. einem Gateway) ausgetauscht. Der CN 2901 verwendet die globalen Parameter $ρ_{k}^{j i};$
um die globalen Parameter $v_{k}^{i j}$
bei 2904 zu aktualisieren, und tauscht dann bei 2906 die globalen Parameter $v_{k}^{i j}$
mit den APs 2910 aus. Die APs 2910 führen dann bei 2916 Nachaktualisierungsoperationen durch. Zum Beispiel können die globalen Parameter $v_{k}^{i j}$
aktualisiert werden, wie oben mit Bezug auf 26 beschrieben. Die aktualisierten globalen Parameter können auch während der Nachaktualisierungsoperationen (z. B. wenn sich die Richtlinienhersteller an den UEs befinden) an die UEs 2920 weitergeleitet werden. Danach führen die AP-UE-Paare einen anderen Satz lokaler Operationen 2918 unter Verwendung der aktualisierten globalen Parameter $ρ_{k}^{j i}$
und $v_{k}^{i j}$
durch.
30 veranschaulicht ein anderes beispielhaftes System 3000, das eine verteilte NN-basierte RRM-Optimierungstechnik implementiert. Das gezeigte Beispiel ähnelt jenem von 10, mit der Ausnahme, dass anstelle eines einzigen Aggregators, der die Aktualisierung aller Parameter handhabt, mehrere Aggregatoren 3002 vorhanden sind, die für die Aktualisierung unterschiedlicher Sätze von Parametern verantwortlich sind. Bei manchen Implementierungen sind die Aggregatoren 3002 für das Überschneiden von Clustern (Teilsatz) von Aktualisierungen von Primal-Dual-Variablen verantwortlich und befinden sich alle auf den Zentralknoten-Gateways 3004. Da die Parameterabhängigkeit durch den Interferenzgraphen bestimmt werden kann, kann es ausreichend sein, einen direkten Kommunikationslink zwischen Edge-Benutzern und Nachbarzellen aufzuweisen. Diese Struktur kann dabei helfen, die Skalierbarkeit der veranschaulichten Architektur zu verbessern.
Beispielhafte Implementierungen
Bei manchen Implementierungsbeispielen nutzt ein Richtlinienhersteller für RRM-Entscheidungen (z. B. eine BS oder eine rechnerisch fähigere Seite des Downlinks) Parameter, die über einen Gradientenabstiegsprozess trainiert werden, um die RRM-Entscheidungen zu treffen. Der Richtlinienhersteller kann in einigen Fällen ein neuronales Netzwerk oder eine parametrisierte Funktion sein, deren Parameter unter Verwendung eines Gradientenabstiegsprozesses optimiert werden können. Eingaben in den Richtlinienhersteller oder Eingaben in die Richtlinienhersteller-Gradientenaktualisierungsfunktion können unter anderem lokale Kanalbeobachtungen, vergangene lokale Entscheidungen, lokal beobachtbare vergangene Entscheidungen anderer Richtlinienhersteller, lokale Beschränkungen und globale Rückmeldung, die sie von anderen Richtlinienherstellern empfangen, beinhalten. Jeder Richtlinienhersteller kann unabhängig so viele Störer auswählen, wie er ein CNN oder einen beliebigen anderen ML-Algorithmus verfolgen und anwenden kann, um permutierte störende Kanaldaten zu nutzen. Der Richtlinienhersteller kann lokale Parameteraktualisierungen über Gradientenabstieg nach Kanalmessungen oder Messrückmeldung und vor dem Treffen der RRM-Entscheidung für diese Kanalbedingungen aufweisen. Entweder der Richtlinienhersteller oder der AP (oder beide) können vordefinierte RRM-Funktionswerte basierend auf den aktuellen und vorherigen Entscheidungen und Leistungsfähigkeiten aktualisieren.
Bei manchen Implementierungsbeispielen beinhaltet eine globale Aktualisierungsperiode für das gesamte Netzwerk die folgenden Operationen. Lokale Parameter können vor einer globalen Parameteraktualisierungsperiode liegen (oder während dieser unverändert bleiben). Globale Parameterinformationen können an einer BS berechnet werden oder können an einem UE vor der AP-zu-GW-Kommunikation berechnet und durch diesen an eine BS gesendet werden. Globale Parameterinformationen können mit dem GW geteilt werden und globale Parameter können durch das GW in Bezug auf globale Parameterinformationen, die Anzahl lokaler Aktualisierungen seit der letzten globalen Aktualisierung und/oder die Zeit, die seit der letzten Aktualisierung verstrichen ist, aktualisiert werden. Die aktualisierten globalen Parameter können mit relevanten APs oder mit UEs, falls sie den Richtlinienhersteller enthalten, geteilt werden.
Bei manchen Implementierungsbeispielen kann das Netzwerk in Teilsätze von APs partitioniert werden, wobei jeder Teilsatz starke gegenseitige Störer enthält, und nur diese APs (oder ihre CNs) im Teilsatz können bei der Optimierung und dem Informationsaustausch berücksichtigt werden. Ein dynamischer Partitionsalgorithmus kann auch implementiert werden, bei dem Netzwerkverhalten untersucht wird, um einen Interferenzgraphen als Funktion der Zeit zu bilden. Graphenpartitionen könnten auf APs (und UEs) mit den stärksten störenden Links basieren. Manche Telemetriedaten könnten genutzt werden, um die Langzeitstörung zwischen APs zu bestimmen, oder Standortinformationen können auch die Partition ansteuern.
BEISPIELHAFTE EDGE-COMPUTING-IMPLEMENTIERUNGEN
Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht beschränkenden Implementierungen. Jedes der folgenden nicht einschränkenden Beispiele kann für sich allein stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren beliebigen der anderen Beispiele, die unten oder in der gesamten vorliegenden Offenbarung bereitgestellt werden, kombiniert werden.
Wie nachfolgend Bezug genommen wird, soll sich eine „Einrichtung eines“ Servers oder „Einrichtung eines“ Clients oder einer „Einrichtung“ eines Edge-Rechenknotens auf eine „Komponente“ eines Servers oder Clients oder Edge-Rechenknotens beziehen, wie die Komponente oben definiert ist. Die „Einrichtung“, wie hierin Bezug genommen wird, kann zum Beispiel eine Rechenschaltungsanordnung beinhalten, wobei die Rechenschaltungsanordnung zum Beispiel eine Verarbeitungsschaltungsanordnung und einen damit gekoppelten Speicher beinhaltet.
Beispiel 1 beinhaltet eine Einrichtung eines Zugangspunkt(AP)-Knotens eines Netzwerks, wobei die Einrichtung eine Interconnect-Schnittstelle zum Verbinden der Einrichtung mit einer oder mehreren Komponenten des AP-Knotens und einen Prozessor für Folgendes beinhaltet: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Aktualisierungsoperationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit dem aktualisierten ersten Satz von Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll.
Beispiel 2 beinhaltet den Gegenstand des Beispiels 1, wobei der Prozessor ferner ausgelegt ist zum Durchführen globaler Aktualisierungsoperationen für das ML-Modell, wobei die globalen Aktualisierungsoperationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten eines aktualisierten dritten Parameters des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Beispiel 3 beinhaltet den Gegenstand des Beispiels 2, wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Beispiel 4 beinhaltet den Gegenstand des Beispiels 2, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen anderen AP-Knoten beinhalten.
Beispiel 5 beinhaltet den Gegenstand des Beispiels 1 oder 2, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Beispiel 6 beinhaltet den Gegenstand des Beispiels 5, wobei erste Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Beispiel 7 beinhaltet den Gegenstand des Beispiels 5, wobei die zweiten Parameter des ML-Modells globale primale Parameter (p^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Beispiel 8 beinhaltet den Gegenstand eines der Beispiele 5-7, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel 9 beinhaltet den Gegenstand eines der Beispiele 2-8, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel 10 beinhaltet den Gegenstand eines der Beispiele 1-9, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter basierend auf einer Gradientenabstiegsanalyse.
Beispiel 11 beinhaltet den Gegenstand eines der Beispiele 1-10, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter des ML-Modells ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel 12 beinhaltet den Gegenstand eines der Beispiele 1-11, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel 13 beinhaltet den Gegenstand eines der Beispiele 1-12, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Beispiel 14 beinhaltet den Gegenstand eines der Beispiele 1-13, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Beispiel 15 beinhaltet den Gegenstand eines der Beispiele 1-14, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel 16 beinhaltet den Gegenstand eines der Beispiele 1-15, wobei der AP-Knoten eine Basisstation eines zellularen Netzwerks ist.
Beispiel 17 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch einen oder mehrere Prozessoren eines Zugangspunkt(AP)-Knotens eines Netzwerks ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Aktualisierungsoperationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit dem aktualisierten ersten Satz von Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll.
Beispiel 18 beinhaltet den Gegenstand des Beispiels 17, wobei die Anweisungen ferner bewirken sollen, dass der eine oder die mehreren Prozessoren globale Aktualisierungsoperationen für das ML-Modell durchführen, wobei die globalen Aktualisierungsoperationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten eines aktualisierten dritten Parameters des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Beispiel 19 beinhaltet den Gegenstand des Beispiels 18, wobei die Anweisungen ferner bewirken sollen, dass der eine oder die mehreren Prozessoren zusätzliche Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern durchführen.
Beispiel 20 beinhaltet den Gegenstand des Beispiels 18, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen anderen AP-Knoten beinhalten.
Beispiel 21 beinhaltet den Gegenstand des Beispiels 17 oder 18, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Beispiel 22 beinhaltet den Gegenstand des Beispiels 21, wobei die ersten Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Beispiel 23 beinhaltet den Gegenstand des Beispiels 21, wobei die zweiten Parameter des ML-Modells globale primale Parameter (ρ^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Beispiel 24 beinhaltet den Gegenstand eines der Beispiele 21-23, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel 25 beinhaltet den Gegenstand eines der Beispiele 18-24, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel 26 beinhaltet den Gegenstand eines der Beispiele 17-25, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter basierend auf einer Gradientenabstiegsanalyse.
Beispiel 27 beinhaltet den Gegenstand eines der Beispiele 17-26, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter des ML-Modells ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel 28 beinhaltet den Gegenstand eines der Beispiele 17-27, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel 29 beinhaltet den Gegenstand eines der Beispiele 17-28, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Beispiel 30 beinhaltet den Gegenstand eines der Beispiele 17-29, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Beispiel 31 beinhaltet den Gegenstand eines der Beispiele 17-30, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel 32 beinhaltet den Gegenstand eines der Beispiele 17-31, wobei der AP-Knoten eine Basisstation eines zellularen Netzwerks ist.
Beispiel 33 beinhaltet ein Verfahren, das Folgendes umfasst: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Aktualisierungsoperationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit dem aktualisierten ersten Satz von Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll.
Beispiel 34 beinhaltet den Gegenstand des Beispiels 33, ferner umfassend Durchführen globaler Aktualisierungsoperationen für das ML-Modell, wobei die globalen Aktualisierungsoperationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten eines aktualisierten dritten Parameters des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Beispiel 35 beinhaltet den Gegenstand des Beispiels 34, ferner umfassend Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Beispiel 36 beinhaltet den Gegenstand des Beispiels 34, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen anderen AP-Knoten beinhalten.
Beispiel 37 beinhaltet den Gegenstand des Beispiels 33 oder 34, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Beispiel 38 beinhaltet den Gegenstand des Beispiels 37, wobei die ersten Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Beispiel 39 beinhaltet den Gegenstand des Beispiels 37, wobei die zweiten Parameter des ML-Modells globale primale Parameter (ρ^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Beispiel 40 beinhaltet den Gegenstand eines der Beispiele 37-39, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel 41 beinhaltet den Gegenstand eines der Beispiele 34-40, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel 42 beinhaltet den Gegenstand eines der Beispiele 33-41, wobei das Aktualisieren der ersten Parameter auf einer Gradientenabstiegsanalyse basiert.
Beispiel 43 beinhaltet den Gegenstand eines der Beispiele 33-42, wobei das Aktualisieren der ersten Parameter des ML-Modells ferner auf einem oder mehreren der Folgenden basiert: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel 44 beinhaltet den Gegenstand eines der Beispiele 33-43, wobei das Aktualisieren der ersten Parameter ferner auf zusätzlichen Kanalmessungen basiert, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel 45 beinhaltet den Gegenstand eines der Beispiele 33-44, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Beispiel 46 beinhaltet den Gegenstand eines der Beispiele 33-45, ferner umfassend, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Beispiel 47 beinhaltet den Gegenstand eines der Beispiele 33-46, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel 48 beinhaltet den Gegenstand eines der Beispiele 33-47, wobei der AP-Knoten eine Basisstation eines zellularen Netzwerks ist.
Beispiel 49 beinhaltet eine Einrichtung einer Benutzergerätevorrichtung (UE) eines Netzwerks, wobei die Einrichtung eine Interconnect-Schnittstelle zum Verbinden der Einrichtung mit einer oder mehreren Komponenten der UE-Vorrichtung und einen Prozessor für Folgendes beinhaltet: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten ersten Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink-Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll.
Beispiel 50 beinhaltet den Gegenstand des Beispiels 49, wobei der Prozessor ferner ausgelegt ist zum Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter dritter Parameter des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Beispiel 51 beinhaltet den Gegenstand des Beispiels 50, wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Aktualisierungsoperationen basierend auf den aktualisierten zweiten Parametern und aktualisierten dritten Parametern.
Beispiel 52 beinhaltet den Gegenstand des Beispiels 50, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen AP-Knoten des Netzwerks beinhalten.
Beispiel 53 beinhaltet den Gegenstand des Beispiels 50 oder 51, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Beispiel 54 beinhaltet den Gegenstand des Beispiels 53, wobei erste Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Beispiel 55 beinhaltet den Gegenstand des Beispiels 53, wobei die zweiten Parameter des ML-Modells globale primale Parameter (p^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Beispiel 56 beinhaltet den Gegenstand eines der Beispiele 53-55, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel 57 beinhaltet den Gegenstand eines der Beispiele 50-56, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel 58 beinhaltet den Gegenstand eines der Beispiele 49-57, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter basierend auf einer Gradientenabstiegsanalyse.
Beispiel 59 beinhaltet den Gegenstand eines der Beispiele 49-58, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel 60 beinhaltet den Gegenstand eines der Beispiele 49-59, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter zu dem ML-Modell ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel 61 beinhaltet den Gegenstand eines der Beispiele 49-60, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Beispiel 62 beinhaltet den Gegenstand eines der Beispiele 49-61, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Beispiel 63 beinhaltet den Gegenstand eines der Beispiele 49-62, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel 64 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten ersten Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink-Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll.
Beispiel 65 beinhaltet den Gegenstand des Beispiels 64, wobei der Prozessor ferner ausgelegt ist zum Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter dritter Parameter des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Beispiel 66 beinhaltet den Gegenstand des Beispiels 65, wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Aktualisierungsoperationen basierend auf den aktualisierten zweiten Parametern und aktualisierten dritten Parametern.
Beispiel 67 beinhaltet den Gegenstand des Beispiels 65, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen AP-Knoten des Netzwerks beinhalten.
Beispiel 68 beinhaltet den Gegenstand des Beispiels 65 oder 66, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Beispiel 69 beinhaltet den Gegenstand des Beispiels 68, wobei die ersten Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Beispiel 70 beinhaltet den Gegenstand des Beispiels 68, wobei die zweiten Parameter des ML-Modells globale primale Parameter (p^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Beispiel 71 beinhaltet den Gegenstand eines der Beispiele 68-70, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel 72 beinhaltet den Gegenstand eines der Beispiele 65-71, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel 73 beinhaltet den Gegenstand eines der Beispiele 64-72, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter basierend auf einer Gradientenabstiegsanalyse.
Beispiel 74 beinhaltet den Gegenstand eines der Beispiele 64-73, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel 75 beinhaltet den Gegenstand eines der Beispiele 64-74, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter zu dem ML-Modell ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel 76 beinhaltet den Gegenstand eines der Beispiele 64-75, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Beispiel 77 beinhaltet den Gegenstand eines der Beispiele 64-76, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Beispiel 78 beinhaltet den Gegenstand eines der Beispiele 64-77, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel 80 beinhaltet ein Verfahren, das Folgendes umfasst: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten ersten Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink-Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll.
Beispiel 81 beinhaltet den Gegenstand des Beispiels 80, ferner umfassend Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter dritter Parameter des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Beispiel 82 beinhaltet den Gegenstand des Beispiels 81, ferner umfassend Durchführen zusätzlicher Runden der lokalen Aktualisierungsoperationen basierend auf den aktualisierten zweiten Parametern und aktualisierten dritten Parametern.
Beispiel 83 beinhaltet den Gegenstand des Beispiels 81, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen AP-Knoten des Netzwerks beinhalten.
Beispiel 84 beinhaltet den Gegenstand des Beispiels 81 oder 82, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Beispiel 85 beinhaltet den Gegenstand des Beispiels 84, wobei die ersten Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Beispiel 86 beinhaltet den Gegenstand des Beispiels 84, wobei die zweiten Parameter des ML-Modells globale primale Parameter (p^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Beispiel 87 beinhaltet den Gegenstand eines der Beispiele 84-86, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel 88 beinhaltet den Gegenstand eines der Beispiele 81-87, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel 89 beinhaltet den Gegenstand eines der Beispiele 80-88, wobei das Aktualisieren der ersten Parameter auf einer Gradientenabstiegsanalyse basiert.
Beispiel 90 beinhaltet den Gegenstand eines der Beispiele 80-89, wobei das Aktualisieren der ersten Parameter ferner auf zusätzlichen Kanalmessungen basiert, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel 91 beinhaltet den Gegenstand eines der Beispiele 80-90, wobei das Aktualisieren der ersten Parameter zu dem ML-Modell ferner auf einem oder mehreren der Folgenden basiert: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel 92 beinhaltet den Gegenstand eines der Beispiele 80-91, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Beispiel 93 beinhaltet den Gegenstand eines der Beispiele 80-92, ferner umfassend, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Beispiel 94 beinhaltet den Gegenstand eines der Beispiele 80-93, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel U1 beinhaltet eine Einrichtung eines Zugangspunkt(AP)-Knotens eines Netzwerks, wobei die Einrichtung eine Interconnect-Schnittstelle zum Verbinden der Einrichtung mit einer oder mehreren Komponenten des AP-Knotens und einen Prozessor für Folgendes beinhaltet: Durchführen lokaler Operationen für eine Anzahl von Runden, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren lokaler primaler Parameter (θⁱ, xⁱ) und lokaler dualer Parameter (λⁱ, µⁱ) eines Maschinenlernmodells (ML-Modells) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit den aktualisierten lokalen primalen Parametern und aktualisierten lokalen dualen Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll; und Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren globaler primaler Parameter (ρ^ji) des ML-Modells; Veranlassen, dass die aktualisierten globalen primalen Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter globaler dualer Parameter (v^ji) des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern; wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Beispiel U2 beinhaltet den Gegenstand des Beispiels U1, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Beispiel U3 beinhaltet den Gegenstand des Beispiels U1, wobei die lokalen und globalen dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel U4 beinhaltet den Gegenstand des Beispiels U1, wobei die globalen primalen Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die globalen dualen Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel U5 beinhaltet den Gegenstand des Beispiels U1, wobei der Prozessor ausgelegt ist zum Aktualisieren der lokalen primalen und dualen Parameter zu dem ML-Modell ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel U6 beinhaltet den Gegenstand des Beispiels U1, wobei der Prozessor ausgelegt ist zum Aktualisieren der lokalen primalen und dualen Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel U7 beinhaltet den Gegenstand des Beispiels U1, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Operationen, Aktualisieren von Schätzungen von Funktionen, die in dem Optimierungsproblem verwendet werden.
Beispiel U8 beinhaltet den Gegenstand des Beispiels U1, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Beispiel U9 beinhaltet den Gegenstand des Beispiels U1, wobei der Prozessor ausgelegt ist zum Aktualisieren der lokalen primalen und dualen Parameter basierend auf einer Gradientenabstiegsanalyse.
Beispiel U10 beinhaltet den Gegenstand des Beispiels U1, wobei der AP-Knoten eine Basisstation eines zellularen Netzwerks ist.
Beispiel U11 beinhaltet den Gegenstand des Beispiels U1, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen anderen AP-Knoten beinhalten.
Beispiel U12 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Durchführen lokaler Operationen für eine Anzahl von Runden, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren lokaler primaler Parameter (θⁱ, xⁱ) und lokaler dualer Parameter (λⁱ, µⁱ) eines Maschinenlernmodells (ML-Modells) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit den aktualisierten lokalen primalen Parametern und aktualisierten lokalen dualen Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll; und Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren globaler primaler Parameter (ρ^ji) des ML-Modells; Veranlassen, dass die aktualisierten globalen primalen Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter globaler dualer Parameter (v^ji) des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern; wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Beispiel U13 beinhaltet den Gegenstand des Beispiels U12, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Beispiel U14 beinhaltet den Gegenstand des Beispiels U12, wobei die lokalen und globalen dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel U15 beinhaltet den Gegenstand des Beispiels U12, wobei das Aktualisieren der lokalen primalen und dualen Parameter zu dem ML-Modell ferner auf einem oder mehreren der Folgenden basiert: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel U16 beinhaltet den Gegenstand des Beispiels U12, wobei das Aktualisieren der lokalen primalen und dualen Parameter ferner auf zusätzlichen Kanalmessungen basiert, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel U17 beinhaltet eine Einrichtung einer Benutzergerätevorrichtung (UE) eines Netzwerks, wobei die Einrichtung eine Interconnect-Schnittstelle zum Verbinden der Einrichtung mit einer oder mehreren Komponenten der UE-Vorrichtung und einen Prozessor für Folgendes beinhaltet: Durchführen lokaler Operationen für eine Anzahl von Runden, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren lokaler primaler Parameter (θⁱ, xⁱ) und lokaler dualer Parameter (λⁱ, µⁱ) eines Maschinenlernmodells (ML-Modells) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten lokalen primalen Parametern und aktualisierten lokalen dualen Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll; und Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren globaler primaler Parameter (ρ^ji) des ML-Modells; Veranlassen, dass die aktualisierten globalen primalen Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter globaler dualer Parameter (v^ji) des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern; wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Beispiel U18 beinhaltet den Gegenstand des Beispiels U17, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Beispiel U19 beinhaltet den Gegenstand des Beispiels U17, wobei die lokalen und globalen dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel U20 beinhaltet den Gegenstand des Beispiels U17, wobei die globalen primalen Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die globalen dualen Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel U21 beinhaltet den Gegenstand des Beispiels U17, wobei der Prozessor ausgelegt ist zum Aktualisieren der lokalen primalen und dualen Parameter zu dem ML-Modell ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Beispiel U22 beinhaltet den Gegenstand des Beispiels U17, wobei der Prozessor ausgelegt ist zum Aktualisieren der lokalen primalen und dualen Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Beispiel U23 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Durchführen lokaler Operationen für eine Anzahl von Runden, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren lokaler primaler Parameter (θⁱ, xⁱ) und lokaler dualer Parameter (λⁱ, µⁱ) eines Maschinenlernmodells (ML-Modells) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten lokalen primalen Parametern und aktualisierten lokalen dualen Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll; und Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren globaler primaler Parameter (ρ^ji) des ML-Modells; Veranlassen, dass die aktualisierten globalen primalen Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter globaler dualer Parameter (v^ji) des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern; wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Beispiel U24 beinhaltet den Gegenstand des Beispiels U23, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Beispiel U25 beinhaltet den Gegenstand des Beispiels U23 oder U24, wobei die lokalen und globalen dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Beispiel P1 beinhaltet ein Verfahren, das an einer Einrichtung eines Edge-Rechenknotens in einem Edge-Computing-Netzwerk durchzuführen ist, wobei das Verfahren Folgendes beinhaltet: Durchführen lokaler Aktualisierungsoperationen, die Folgendes beinhalten: Erhalten von Kanalmessungen (h^ij); Aktualisieren lokaler primaler Parameter (θⁱ, xⁱ) und lokaler dualer Parameter (λⁱ, µⁱ) zu einem Maschinenlernmodell eines Optimierungsproblems basierend auf den Kanalmessungen und eines Teilsatzes globaler primaler Parameter (ρⁱ) und globaler dualer Parameter (vⁱ), wobei die lokalen und globalen dualen Parameter Lagrange-Variablen beinhalten, die Beschränkungen des Optimierungsproblems entsprechen; Bestimmen einer Funkressourcenverwaltung(RRM)-Entscheidung für einen Link zwischen dem Edge-Rechenknoten und einem anderen Edge-Rechenknoten basierend auf dem aktualisierten Maschinenlernmodell; und Initiieren einer Datenübertragung basierend auf der RRM-Entscheidung. Das Verfahren beinhaltet auch Durchführen globaler Aktualisierungsoperationen, einschließlich: Austauschen globaler primaler Parameterinformationen (p^ji) mit einem oder mehreren Aggregatoren an anderen Knoten des Edge-Computing-Netzwerks; Erhalten von Aktualisierungen der globalen dualen Parameter (v^ji) von den Aggregatoren; und Aktualisieren des Maschinenlernmodells basierend auf den aktualisierten globalen primalen und dualen Parametern.
Beispiel P2 beinhaltet den Gegenstand des Beispiels P1 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die globalen primalen Parameter erwartete Leistungsausgaben für einen Sender in dem Edge-Computing-Netzwerk angeben und die globalen dualen Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Beispiel P3 beinhaltet den Gegenstand des Beispiels P1 oder P2 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional das Erhalten von Kanalmessungen Erhalten zusätzlicher Kanalmessungen von einem anderen Knoten des Edge-Computing-Systems beinhaltet und die lokalen Parameter ferner basierend auf den zusätzlichen Kanalmessungen aktualisiert werden.
Beispiel P4 beinhaltet den Gegenstand eines der Beispiele P1-P3 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional das Aktualisieren der lokalen primalen und dualen Parameter für den Maschinenlernmodell ferner auf einem oder mehreren der Folgenden basiert: vorherigen RRM-Entscheidungen für den Link, vorherigen RRM-Entscheidungen für andere Links des Edge-Computing-Systems, Beschränkungen für einen oder beide Edge-Rechenknoten des Links, und Informationen von anderen RRM-Entscheidern des Edge-Computing-Systems.
Beispiel P5 beinhaltet den Gegenstand eines der Beispiele P1-P4 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional das Aktualisieren der lokalen primalen und dualen Parameter auf einer Gradientenabstiegsanalyse basiert.
Beispiel P6 beinhaltet den Gegenstand eines der Beispiele P1-P5 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die lokalen Aktualisierungsoperationen ferner Aktualisieren von Schätzungen von Funktionen, die in dem Optimierungsproblem verwendet werden, umfassen.
Beispiel P7 beinhaltet den Gegenstand eines der Beispiele P1-P6 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional der Edge-Rechenknoten ein Zugangspunkt (AP) oder eine Basisstation (BS) eines Edge-Computing-Systems ist.
Beispiel P8 beinhaltet den Gegenstand des Beispiels P7 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die Datenübertragung eine Uplink-Übertragung von dem AP oder der BS zu einer Benutzergerät(UE)-Vorrichtung des Edge-Computing-Systems ist.
Beispiel P9 beinhaltet den Gegenstand eines der Beispiele P1-P6 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional der Edge-Rechenknoten eine Benutzergerät(UE)-Vorrichtung eines Edge-Computing-Systems ist.
Beispiel P10 beinhaltet den Gegenstand des Beispiels P9 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die Datenübertragung eine Downlink-Übertragung von der UE-Vorrichtung zu einem Zugangspunkt (AP) oder einer Basisstation (BS) eines Edge-Computing-Systems ist.
Beispiel P11 beinhaltet den Gegenstand des Beispiels P9 oder P10 und/oder eines oder mehrerer anderer Beispiele hierin, und optional ferner umfassend Veranlassen, dass die aktualisierten globalen dualen Parameter an die UE-Vorrichtung gesendet werden.
Beispiel P12 beinhaltet den Gegenstand eines der vorstehenden Beispiele und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die globalen primalen Parameterinformationen mit einem Aggregator an einem zentralen Knoten des Edge-Computing-Systems ausgetauscht werden.
Beispiel P13 beinhaltet den Gegenstand eines der vorstehenden Beispiele und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional globale primale Parameterinformationen mit einem Aggregator an einem Zugangspunkt (AP) oder einer Basisstation (BS) des Edge-Computing-Systems ausgetauscht werden.
Beispiel P14 beinhaltet den Gegenstand eines der vorstehenden Beispiele und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die globalen primalen Parameterinformationen mit mehreren Aggregatoren an jeweiligen Knoten des Edge-Computing-Netzwerks ausgetauscht werden, wobei jeder Aggregator für die Aktualisierung eines jeweiligen Teilsatzes der globalen dualen Parameter verantwortlich ist.
Beispiel P15 beinhaltet den Gegenstand des Beispiels P14 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei sich optional ein erster Aggregator an einem zentralen Knoten des Edge-Computing-Systems befindet und sich ein zweiter Aggregator an einem Zugangspunkt des Edge-Computing-Systems befindet.
Beispiel P16 beinhaltet den Gegenstand des Beispiels P14 und/oder eines oder mehrerer anderer Beispiele hierin, wobei sich optional ein erster Aggregator an einem ersten Zugangspunkt (AP) des Edge-Computing-Systems befindet und sich ein zweiter Aggregator an einem zweiten AP des Edge-Computing-Systems befindet.
Beispiel P17 beinhaltet den Gegenstand des Beispiels P14 und/oder eines oder mehrerer anderer Beispiele hierin, und wobei sich optional ein erster Aggregator an einem ersten zentralen Knoten (CN) des Edge-Computing-Systems befindet und sich ein zweiter Aggregator an einem zweiten CN des Edge-Computing-Systems befindet.
Beispiel P18 beinhaltet den Gegenstand eines der vorstehenden Beispiele und/oder eines oder mehrerer anderer Beispiele hierin, und wobei optional die lokalen Aktualisierungsoperationen in mehreren Runden durchgeführt werden, bevor die globalen Aktualisierungsoperationen durchgeführt werden.
Beispiel P19 beinhaltet den Gegenstand eines der vorstehenden Beispiele und/oder eines oder mehrerer anderer Beispiele hierin, und optional ferner umfassend Durchführen der lokalen Aktualisierungsoperationen, nachdem die globalen Aktualisierungsoperationen durchgeführt wurden.
Beispiel P20 beinhaltet eine Einrichtung, die Mittel zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem der obigen Beispiele P1-P19 beschrieben ist oder mit diesen in Zusammenhang steht, oder eines beliebigen anderen Verfahrens oder Prozesses, das/der hierin beschrieben ist, umfasst.
Beispiel P21 beinhaltet ein oder mehrere nichtflüchtige computerlesbare Medien, die Anweisungen umfassen, um zu veranlassen, dass eine elektronische Vorrichtung bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung ein oder mehrere Elemente eines Verfahrens, das in einem der Beispiele P1-P19 beschrieben ist oder damit in Zusammenhang steht, oder eines beliebigen anderen Verfahrens oder Prozesses, das/der hierin beschrieben ist, durchführt.
Beispiel P22 beinhaltet eine Einrichtung, die Logik, Module oder Schaltungsanordnungen zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem der Beispiele P1-P19 beschrieben ist oder damit in Zusammenhang steht, oder eines beliebigen anderen Verfahrens oder Prozesses, das/der hierin beschrieben ist, umfasst.
Beispiel P23 beinhaltet ein Verfahren, eine Technik oder einen Prozess, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Abschnitte oder Teile davon.
Beispiel P24 beinhaltet eine Einrichtung, die Folgendes umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, veranlassen, dass der eine oder die mehreren Prozessoren das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Teile davon durchführen.
Beispiel P25 beinhaltet ein Signal, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Abschnitte oder Teile davon.
Beispiel P26 beinhaltet ein Datagramm, ein Paket, einen Frame, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Abschnitte oder Teile davon, oder wie anderweitig in der vorliegenden Offenbarung beschrieben.
Beispiel P27 beinhaltet ein Signal, das mit Daten codiert ist, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Abschnitte oder Teile davon, oder wie anderweitig in der vorliegenden Offenbarung beschrieben.
Beispiel P28 beinhaltet ein Signal, das mit einem Datagramm, einem Paket, einem Frame, einem Segment, einer Protokolldateneinheit (PDU) oder einer Nachricht codiert ist, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Abschnitte oder Teile davon, oder wie anderweitig in der vorliegenden Offenbarung beschrieben.
Beispiel P29 beinhaltet ein elektromagnetisches Signal, das computerlesbare Anweisungen führt, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren veranlassen soll, dass der eine oder die mehreren Prozessoren das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Teile davon durchführen.
Beispiel P30 beinhaltet ein Computerprogramm, das Anweisungen umfasst, wobei die Ausführung des Programms durch ein Verarbeitungselement veranlassen soll, dass das Verarbeitungselement das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele P1-P19 beschrieben oder damit in Zusammenhang stehend, oder Teile davon aus führt.
Beispiel P31 beinhaltet ein Signal in einem Drahtlosnetzwerk, wie hierin gezeigt und beschrieben.
Beispiel P32 beinhaltet ein Verfahren zum Kommunizieren in einem Drahtlosnetzwerk, wie hierin gezeigt und beschrieben.
Beispiel P33 beinhaltet ein System zum Bereitstellen einer Drahtloskommunikation, wie hierin gezeigt und beschrieben.
Beispiel P34 beinhaltet eine Vorrichtung zum Bereitstellen einer Drahtloskommunikation, wie hierin gezeigt und beschrieben.
Eine beispielhafte Implementierung ist ein Edge-Computing-System, das jeweilige Edge-Verarbeitungsvorrichtungen und Knoten zum Aufrufen oder Durchführen der Operationen der Beispiele P1-P19 oder eines anderen hierin beschriebenen Gegenstands beinhaltet.
Eine andere beispielhafte Implementierung ist ein Client-Endpunktknoten, der betreibbar ist, um die Operationen der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Aggregationsknoten, ein Netzwerkhubknoten, ein Gateway-Knoten oder ein Kerndatenverarbeitungsknoten, in oder gekoppelt mit einem Edge-Computing-System, der betreibbar ist, um die Operationen der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Zugangspunkt, eine Basisstation, eine Straßenrandeinheit, eine Stadtstraßenrandeinheit oder eine Vor-Ort-Einheit, in oder gekoppelt mit einem Edge-Computing-System, der/die betreibbar ist, um die Operationen der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführe.
Eine andere beispielhafte Implementierung ist ein Edge-Bereitstellungsknoten, ein Dienstorchestrierungsknoten, ein Anwendungsorchestrierungsknoten oder ein Multi-Mandanten-Verwaltungsknoten, in oder gekoppelt mit einem Edge-Computing-System, der betreibbar ist, um die Operationen der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Edge-Knoten, der einen Edge-Bereitstellungsdienst, eine Anwendung oder einen Dienstorchestrierungsdienst, einen Virtuelle-Maschine-Einsatz, einen Container-Einsatz, einen Funktionseinsatz und eine Rechenverwaltung in oder gekoppelt mit einem Edge-Computing-System betreibt, der betreibbar ist, um die Operationen der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das als ein Edge-Mesh, als ein Edge-Mesh mit Side-Car-Loading oder mit Mesh-zu-Mesh-Kommunikationen betreibbar ist und betreibbar ist, um die Operationen der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das Aspekte von Netzwerkfunktionen, Beschleunigungsfunktionen, Beschleunigungshardware, Speicherungshardware oder Berechnungshardwareressourcen beinhaltet, das betreibbar ist, um die hierin besprochenen Verwendungsfälle unter Verwendung der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das zum Unterstützen von Client-Mobilitäts-, Fahrzeug-zu-Fahrzeug(V2V)-, Fahrzeug-zu-Allem(V2X)- oder Fahrzeug-zu-Infrastruktur(V2I)-Szenarien ausgelegt ist und optional gemäß ETSI-MEC-Spezifikationen arbeitet, das betreibbar ist, um die hierin besprochenen Verwendungsfälle unter Verwendung der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das für mobile Drahtloskommunikationen ausgelegt ist, einschließlich Konfigurationen gemäß 3GPP-4G/LTE-, 5G- oder ORAN(Open RAN)-Netzwerkfähigkeiten, das betreibbar ist, um die hierin besprochenen Verwendungsfälle unter Verwendung der Beispiele P1-P19 oder einen anderen hierin beschriebenen Gegenstand aufzurufen oder durchzuführen.
Ein beliebiges der oben beschriebenen Beispiele kann mit einem beliebigen anderen Beispiel (oder einer beliebigen Kombination von Beispielen) kombiniert werden, sofern nicht explizit anders angegeben. Hierin beschriebene Aspekte können auch eine hierarchische Anwendung des Schemas implementieren, zum Beispiel durch Einführen einer hierarchischen Priorisierung der Verwendung für verschieden Arten von Benutzern (z. B. niedrige/mittlere/hohe Priorität usw.), basierend auf dem priorisierten Zugang zu dem Spektrum, z. B. mit höchster Priorität für Stufe-1-Benutzer, gefolgt von Stufe-2-, dann Stufe-3-Benutzer usw. Manche der Merkmale in der vorliegenden Offenbarung sind für Netzwerkelemente (oder Netzwerkausrüstung) definiert, wie etwa Zugangspunkte (APs), eNBs, gNBs, Kernnetzwerkelemente (oder Netzwerkfunktionen), Anwendungsserver, Anwendungsfunktionen usw. Eine beliebige Ausführungsform, die hierin als durch ein Netzwerkelement durchgeführt erörtert wird, kann zusätzlich oder alternativ durch ein UE durchgeführt werden, oder das UE kann die Rolle des Netzwerkelements übernehmen (z. B. manche oder alle Merkmale, die für Netzwerkausrüstung definiert sind, können durch ein UE implementiert 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 von dem breiteren Schutzumfang 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 die Auswahl von Edge-Diensten zu unterstützen, die den zu versorgenden Edge-Systemen zur Verfügung gestellt werden können. Entsprechend sind die Beschreibung und die Zeichnungen in einem veranschaulichenden und nicht in einem einschränkenden Sinne aufzufassen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen spezielle Aspekte, in denen der Gegenstand ausgeführt werden kann, als Veranschaulichung und nicht als Beschränkung. Die veranschaulichten Aspekte sind hinreichend detailliert beschrieben, um einen Fachmann zu befähigen, die hierin offenbarten Lehren auszuüben. Andere Aspekte können genutzt und aus diesen abgeleitet werden, sodass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne den Schutzumfang dieser Offenbarung zu verlassen. Diese ausführliche Beschreibung ist daher nicht in einem beschränkenden Sinn aufzufassen und der Schutzumfang verschiedener Aspekte ist nur durch die angehängten Ansprüche, zusammen mit dem vollen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigt sind, definiert.
Auf solche Aspekte des erfindungsgemäßen Gegenstands kann hierin einzeln und/oder kollektiv lediglich der Einfachheit halber und ohne beabsichtigt zu sein, den Schutzumfang dieser Anmeldung freiwillig auf einen beliebigen einzelnen Aspekt oder einen beliebigen einzelnen Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart ist, in Bezug genommen werden. Obwohl spezielle Aspekte hierin veranschaulicht und beschrieben wurden, sollte man daher verstehen, dass eine beliebige Einrichtung, die berechnet ist, um denselben Zweck zu erfüllen, die gezeigten speziellen Ausführungsformen ersetzen kann. Diese Offenbarung soll jegliche und alle Anpassungen oder Variationen verschiedenster Aspekte abdecken. Kombinationen der obigen Aspekte und andere Aspekte, die hierin nicht speziell beschrieben sind, ergeben sich für Fachleute bei der Durchsicht der oben stehenden Beschreibung.
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 63053547 [0001]

Claims

Einrichtung eines Zugangspunkt(AP)-Knotens eines Netzwerks, wobei die Einrichtung eine Interconnect-Schnittstelle zum Verbinden der Einrichtung mit einer oder mehreren Komponenten des AP-Knotens und einen Prozessor beinhaltet zum: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Aktualisierungsoperationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit dem aktualisierten ersten Satz von Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll.
Einrichtung nach Anspruch 1, wobei der Prozessor ferner ausgelegt ist zum Durchführen globaler Aktualisierungsoperationen für das ML-Modell, wobei die globalen Aktualisierungsoperationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten eines aktualisierten dritten Parameters des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Einrichtung nach Anspruch 2, wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Einrichtung nach Anspruch 2, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen anderen AP-Knoten beinhalten.
Einrichtung nach Anspruch 2, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Einrichtung nach Anspruch 5, wobei erste Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Einrichtung nach Anspruch 5, wobei die zweiten Parameter des ML-Modells globale primale Parameter (ρ^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Einrichtung nach Anspruch 5, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Einrichtung nach Anspruch 2, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Einrichtung nach einem der Ansprüche 1-9, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter basierend auf einer Gradientenabstiegsanalyse.
Einrichtung nach einem der Ansprüche 1-9, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter des ML-Modells ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Einrichtung nach einem der Ansprüche 1-9, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Einrichtung nach einem der Ansprüche 1-9, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Einrichtung nach einem der Ansprüche 1-9, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Einrichtung nach einem der Ansprüche 1-9, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Einrichtung nach einem der Ansprüche 1-9, wobei der AP-Knoten eine Basisstation eines zellularen Netzwerks ist.
Verfahren, das Folgendes umfasst: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Aktualisierungsoperationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen dem AP-Knoten und Benutzergerät(UE)-Vorrichtungen; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Uplink-Übertragung von einer bestimmten UE-Vorrichtung zu dem AP-Knoten basierend auf dem ML-Modell mit dem aktualisierten ersten Satz von Parametern; und Veranlassen, dass die RRM-Entscheidung zu der bestimmten UE-Vorrichtung übertragen wird, wobei die RRM-Entscheidung durch die bestimmte UE-Vorrichtung für die Uplink-Datenübertragung von der bestimmten UE-Vorrichtung zu dem AP-Knoten implementiert werden soll.
Verfahren nach Anspruch 17, ferner umfassend Durchführen globaler Aktualisierungsoperationen für das ML-Modell, wobei die globalen Aktualisierungsoperationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten eines aktualisierten dritten Parameters des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Verfahren nach Anspruch 18, ferner umfassend Durchführen zusätzlicher Runden der lokalen Operationen basierend auf den aktualisierten globalen primalen Parametern und aktualisierten globalen dualen Parametern.
Verfahren nach Anspruch 18, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen anderen AP-Knoten beinhalten.
Verfahren nach Anspruch 18, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Verfahren nach Anspruch 21, wobei die ersten Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Verfahren nach Anspruch 21, wobei die zweiten Parameter des ML-Modells globale primale Parameter (ρ^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Verfahren nach Anspruch 21, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Verfahren nach Anspruch 18, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Verfahren nach einem der Ansprüche 17-25, wobei das Aktualisieren der ersten Parameter auf einer Gradientenabstiegsanalyse basiert.
Verfahren nach einem der Ansprüche 17-25, wobei das Aktualisieren der ersten Parameter des ML-Modells ferner auf einem oder mehreren der Folgenden basiert: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Verfahren nach einem der Ansprüche 17-25, wobei das Aktualisieren der ersten Parameter ferner auf zusätzlichen Kanalmessungen basiert, die durch andere AP-Knoten des Netzwerks erhalten werden.
Verfahren nach einem der Ansprüche 17-25, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Uplink-Datenübertragung oder ein Frequenzband zum Übertragen der Uplink-Datenübertragung ist.
Verfahren nach einem der Ansprüche 17-25, ferner umfassend, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Verfahren nach einem der Ansprüche 17-25, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Verfahren nach einem der Ansprüche 17-25, wobei der AP-Knoten eine Basisstation eines zellularen Netzwerks ist.
Einrichtung einer Benutzergerätevorrichtung (UE) eines Netzwerks, wobei die Einrichtung eine Interconnect-Schnittstelle zum Verbinden der Einrichtung mit einer oder mehreren Komponenten der UE-Vorrichtung und einen Prozessor für Folgendes beinhaltet: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten ersten Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink-Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll.
Einrichtung nach Anspruch 33, wobei der Prozessor ferner ausgelegt ist zum Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter dritter Parameter des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Einrichtung nach Anspruch 34, wobei der Prozessor ferner ausgelegt ist zum Durchführen zusätzlicher Runden der lokalen Aktualisierungsoperationen basierend auf den aktualisierten zweiten Parametern und aktualisierten dritten Parametern.
Einrichtung nach Anspruch 34, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen AP-Knoten des Netzwerks beinhalten.
Einrichtung nach Anspruch 34 oder 35, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Einrichtung nach Anspruch 37, wobei erste Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Einrichtung nach Anspruch 37, wobei die zweiten Parameter des ML-Modells globale primale Parameter (ρ^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Einrichtung nach Anspruch 37, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Einrichtung nach Anspruch 34, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Einrichtung nach einem der Ansprüche 33-41, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter basierend auf einer Gradientenabstiegsanalyse.
Einrichtung nach einem der Ansprüche 33-41, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter ferner basierend auf zusätzlichen Kanalmessungen, die durch andere AP-Knoten des Netzwerks erhalten werden.
Einrichtung nach einem der Ansprüche 33-41, wobei der Prozessor ausgelegt ist zum Aktualisieren der ersten Parameter zu dem ML-Modell ferner basierend auf einem oder mehreren der Folgenden: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Einrichtung nach einem der Ansprüche 33-41, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Einrichtung nach einem der Ansprüche 33-41, wobei der Prozessor ferner ausgelegt ist zum, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Einrichtung nach einem der Ansprüche 33-41, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
Verfahren, das Folgendes umfasst: Durchführen lokaler Aktualisierungsoperationen für ein Maschinenlernmodell (ML-Modell) eines Funkressourcenverwaltung(RRM)-Optimierungsproblems, wobei die lokalen Operationen Folgendes umfassen: Erhalten von Kanalmessungen (h^ij) für drahtlose Links zwischen der UE-Vorrichtung und Zugangspunkt(AP)-Knoten des Netzwerks; Aktualisieren erster Parameter des ML-Modells basierend auf den Kanalmessungen; Bestimmen einer RRM-Entscheidung für eine Downlink-Übertragung von einem bestimmten AP-Knoten zu der UE-Vorrichtung basierend auf dem ML-Modell mit den aktualisierten ersten Parametern; und Veranlassen, dass die RRM-Entscheidung zu dem bestimmten AP-Knoten übertragen wird, wobei die RRM-Entscheidung durch den bestimmten AP-Knoten für die Downlink-Datenübertragung von dem bestimmten AP-Knoten zu der UE-Vorrichtung implementiert werden soll.
Verfahren nach Anspruch 48, ferner umfassend Durchführen globaler Operationen nach der Anzahl von Runden lokaler Operationen, wobei die globalen Operationen Folgendes umfassen: Aktualisieren zweiter Parameter des ML-Modells; Veranlassen, dass die aktualisierten zweiten Parameter zu einem oder mehreren Aggregatorknoten des Netzwerks übertragen werden; und Erhalten aktualisierter dritter Parameter des ML-Modells von einem oder mehreren Aggregatorknoten des Netzwerks basierend auf den aktualisierten globalen primalen Parametern.
Verfahren nach Anspruch 49, ferner umfassend Durchführen zusätzlicher Runden der lokalen Aktualisierungsoperationen basierend auf den aktualisierten zweiten Parametern und aktualisierten dritten Parametern.
Verfahren nach Anspruch 49, wobei der eine oder die mehreren Aggregatorknoten des Netzwerks einen zentralen Knoten des Netzwerks oder einen AP-Knoten des Netzwerks beinhalten.
Verfahren nach Anspruch 49 oder 50, wobei das RRM-Optimierungsproblem ein Primal-Dual-Optimierungsproblem ist.
Verfahren nach Anspruch 52, wobei die ersten Parameter des ML-Modells lokale primale Parameter (θⁱ, xⁱ) und lokale duale Parameter (λⁱ, µⁱ) des ML-Modells beinhalten.
Verfahren nach Anspruch 52, wobei die zweiten Parameter des ML-Modells globale primale Parameter (ρ^ji) des ML-Modells beinhalten und die dritten Parameter des ML-Modells globale duale Parameter (v^ji) des ML-Modells beinhalten.
Verfahren nach Anspruch 52, wobei die dualen Parameter Lagrange-Variablen sind, die Beschränkungen des RRM-Optimierungsproblems entsprechen.
Verfahren nach Anspruch 49, wobei die zweiten Parameter erwartete Leistungsausgaben für Sender in dem Netzwerk angeben und die dritten Parameter Empfindlichkeiten von Empfängern gegenüber anderen Sendern angeben.
Verfahren nach einem der Ansprüche 48-56, wobei das Aktualisieren der ersten Parameter auf einer Gradientenabstiegsanalyse basiert.
Verfahren nach einem der Ansprüche 48-56, wobei das Aktualisieren der ersten Parameter ferner auf zusätzlichen Kanalmessungen basiert, die durch andere AP-Knoten des Netzwerks erhalten werden.
Verfahren nach einem der Ansprüche 48-56, wobei das Aktualisieren der ersten Parameter zu dem ML-Modell ferner auf einem oder mehreren der Folgenden basiert: vorherigen RRM-Entscheidungen für den Link zwischen der bestimmten UE-Vorrichtung und dem AP-Knoten, vorherigen RRM-Entscheidungen für andere AP-UE-Links des Netzwerks, Beschränkungen für den AP und/oder die bestimmte UE-Vorrichtung, und Informationen von anderen RRM-Entscheidern des Netzwerks.
Verfahren nach einem der Ansprüche 48-56, wobei das RRM-Optimierungsproblem für eine Sendeleistung für eine Downlink-Datenübertragung oder ein Frequenzband zum Übertragen der Downlink-Datenübertragung ist.
Verfahren nach einem der Ansprüche 48-56, ferner umfassend, in den lokalen Aktualisierungsoperationen, Aktualisieren von Schätzungen von Funktionen, die in dem RRM-Optimierungsproblem verwendet werden.
Verfahren nach einem der Ansprüche 48-56, wobei das ML-Modell ein neuronales Netzwerk (NN) ist.
System, das Mittel zum Durchführen eines oder mehrerer Elemente eines Verfahrens nach einem der Ansprüche 17-32 und 48-62 umfasst.
Maschinenlesbare Speicherung, die maschinenlesbare Anweisungen beinhaltet, die, wenn sie ausgeführt werden, das Verfahren nach einem der Ansprüche 17-32 und 48-62 implementieren.