DE112019002913T5 - Verwaltung von zuweisungen bevorzugter kanäle zwischendrahtloskommunikationsbändern - Google Patents

Abstract

Es werden verschiedene Systeme und Verfahren zum Herstellen, Konfigurieren und Betreiben von Mehrfachzugriff-Edge-Computing-Kommunikationen (MEC-Kommunikationen), wie etwa in Verbindung mit der Verwaltung von Zuweisungen bevorzugter Kanäle zwischen zwei oder mehr Vehicle-to-everything-Funkzugriffstechnologien (V2X RATs), hierin erläutert. In Ausführungsformen wird eine Ressourcenzuweisung (zum Beispiel Kanalzuweisungen) für Fahrzeugnutzergeräte (vUEs) basierend auf einer Anzahl an vUEs bestimmt, die jede von einer oder mehreren V2X RATs unterstützen, die in einem oder mehreren Abdeckungsbereichen von einer oder mehreren straßenseitigen Einheiten (RSUs) detektiert werden. Es werden andere Ausführungsformen beschrieben und/oder beansprucht.

Description

• VERWANDTE ANMELDUNGEN
• Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung Nr. 62/682,732 , eingereicht am 8. Juni 2018, deren Inhalt durch Bezugnahme vollständig aufgenommen ist.
• TECHNISCHES GEBIET
• Die hierin beschriebenen Ausführungsformen beziehen sich allgemein auf Datenverarbeitung, Netzwerkkommunikation und Kommunikationssystemimplementierungen, und insbesondere auf Techniken zum Herstellen und Implementieren von Kommunikationen in Mehrfachzugriff-Edge-Computing-Vorrichtungsnetzwerken (MEC-Vorrichtungsnetzwerken) und Internet-of-Things-Vorrichtungsnetzwerken (IoT-Vorrichtungsnetzwerken).
• ALLGEMEINER STAND DER TECHNIK
• Internet-of-Things-Vorrichtungen (IoT-Vorrichtungen) sind physische oder virtualisierte Objekte, die auf einem Netzwerk kommunizieren können, und können Sensoren, Aktoren und sonstige Eingabe-/Ausgabekomponenten aufweisen, wie etwa zum Sammeln von Daten oder Durchführen von Aktionen aus einer realen Umgebung. Zum Beispiel können IoT-Vorrichtungen gering bestromte Vorrichtungen umfassen, die in Alltagsdingen, wie etwa Gebäuden, Fahrzeugen, Packages usw. eingebettet oder mit diesen verbunden sind, um eine zusätzliche Ebene von künstlicher Sensorwahrnehmung jener Dinge bereitzustellen. In jüngster Zeit sind IoT-Vorrichtungen beliebter geworden und haben somit Anwendungen, die diese Vorrichtungen verwenden, stark zugenommen. Der Einsatz von IoT-Vorrichtungen und Mehrfachzugriff-Edge-Computing-Diensten (MEC-Diensten) hat eine Anzahl an fortgeschrittenen Nutzungsfällen und Szenarien, die an dem Rand des Netzwerks auftreten oder diesen anderweitig beinhalten, eingeführt.
• Diese fortgeschrittenen Nutzungsfälle haben jedoch unter vielen anderen Problemen auch einige entsprechende technische Herausforderungen in Bezug auf die Sicherheit, Verarbeitungs-/Rechenressourcen, Netzwerkressourcen, Dienstverfügbarkeit und -effizienz eingeführt.
• MEC bietet Anwendungsentwicklern und Content Providern Cloud-Computing-Fähigkeiten und eine Informationstechnologiedienstumgebung (IT-Dienstumgebung) am Rand des Netzwerks. Diese Umgebung ist durch eine sehr geringe Latenz und eine hohe Bandbreite sowie Echtzeitzugriff auf Funknetzwerkinformationen, die sich Edge-Anwendungen (z. B. MEC-Anwendungen) zunutze machen können, gekennzeichnet. Die MEC-Technologie erlaubt einen flexiblen und schnellen Einsatz von innovativen Anwendungen und Diensten für Mobilfunkteilnehmer, Unternehmen und vertikale Segmente.
• Figurenliste
• In den Zeichnungen, welche nicht notwendigerweise maßstabsgetreu dargestellt sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Bezugszeichen, die unterschiedliche Buchstabensuffixe aufweisen, können unterschiedliche Instanzen von ähnlichen Komponenten darstellen. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen veranschaulicht:
• 1 stellt eine beispielhafte Edge-Computing-Umgebung, die eine Vielzahl an Schichten aufweist, gemäß verschiedenen Ausführungsformen dar. 2 stellt beispielhafte Komponenten einer Computerplattform gemäß verschiedenen Ausführungsformen dar. 3 stellt ein Beispiel von Infrastrukturgeräten gemäß verschiedenen Ausführungsformen dar. 4 stellt eine beispielhafte Mehrfachzugriff-Edge-Computing-Systemarchitektur (MEC-Systemarchitektur), in welcher eine oder mehrere der Techniken (z. B. Operationen, Prozesse, Verfahren und Methodologien), die hierin erläutert werden, durchgeführt werden können, gemäß verschiedenen Ausführungsformen dar.
• 5 veranschaulicht ein Beispiel von mehreren Kanälen, die für Vehicle-toeverything-Kommunikationen (V2X-Kommunikationen) verfügbar sind, gemäß einer beispielhaften Ausführungsform. Die 6 - 9 veranschaulichen verschiedene Szenarien zum Konfigurieren von Infrastrukturausrüstung zum Unterstützen/Bereitstellen von anwendbaren V2X-Funkzugriffstechnologie-Ressourcenzuweisungen (RAT-Ressourcenzuweisungen) gemäß einer beispielhaften Ausführungsform.
• 10 veranschaulicht ein V2X-Dienstverfahren gemäß einer beispielhaften Ausführungsform. 11 veranschaulicht ein beispielhaftes V2X-Nachrichtenweiterleitungsverfahren gemäß einer beispielhaften Ausführungsform. 12 veranschaulicht eine grundlegende Konvention für die Spezifikation von Paketformaten und eine grundlegende Konvention für das Header-Format für ein Paket gemäß einer beispielhaften Ausführungsform. 13 veranschaulicht ein beispielhaftes Verfahren zum Praktizieren der verschiedenen Ausführungsformen hierin.
• AUSFÜHRLICHE BESCHREIBUNG
• In der folgenden Beschreibung werden Verfahren, Konfigurationen und damit verbundene Vorrichtungen zur Verwaltung der Koexistenz und Interoperabilität zwischen mehreren Fahrzeugkommunikationssystemen (oder -standards) einschließlich Zuweisungen bevorzugter Kanäle zwischen mehreren Funkkommunikationstechnologien in Verbindung mit Mehrfachzugriff-Edge-Computing-Diensten (MEC-Diensten) und Kommunikationsarchitekturen offenbart.
• Aktuell sind zwei konkurrierende Fahrzeugkommunikationssysteme (oder Vehicleto-everything-Funkzugriffstechnologien (V2X RATs)) vorhanden; ein System ist das Institute of Electrical and Electronics Engineers (IEEE) 802.11p, wie etwa dedizierte Kurzreichweitenkommunikation (DSRC, Dedicated Short Range Communication) und intelligente Transportsysteme in dem 5-Gigahertz-Frequenzband (5 GHz-Frequenzband), und das andere System ist die zelluläre Langzeitentwicklungs-V2X-Kommunikation (LTE C-V2X-Kommunikation). So wie er hierin verwendet wird, bezieht sich der Begriff „DSRC“ auf Fahrzeugkommunikationen im 5,9 GHz-Frequenzband. Diese Systeme weisen keine Mechanismen zum Koexistieren miteinander auf und sind für gewöhnlich nicht miteinander interoperabel.
• „Interoperabilität“ bezieht sich auf die Fähigkeit von Fahrzeug-UEs (vUEs, Vehicle UEs) und straßenseitiger Ausrüstung (z. B. straßenseitige Einheiten (RSUs, Road Side Units)), die ein Fahrzeugkommunikationssystem verwenden, um mit vUEs und straßenseitiger Ausrüstung unter Verwendung des anderen Fahrzeugkommunikationssystems zu kommunizieren. „Koexistenz“ bezieht sich auf das Teilen oder Zuweisen von Funkfrequenzressourcen unter vUEs und straßenseitiger Ausrüstung unter Verwendung jedes Fahrzeugkommunikationssystems. Ein Koexistenzansatz ist der Ansatz des „bevorzugten Kanals“, welcher ein dynamisches Zuweisen von Kanälen, die exklusiv von einem System oder exklusiv von dem anderen System zu verwenden sind, beinhaltet. Ein anderer Koexistenzansatz ist der „Ko-Kanal-Existenz-“ - Ansatz, welcher das Zuweisen beider Systeme zu einem Kanal während unterschiedlichen Zeitschlitzen beinhaltet.
• Als Kontext für die anwendbare Regulierung und Standardisierung werden jeweils drei Sicherheitskanäle mit 10 Megahertz (MHz) in dem 5,9 GHz-ITS-Band zugewiesen. Die 5G Automotive Association (5GAA) hat einen sogenannten Safe-Harbor-Ansatz vorgeschlagen, bei welchem ein Kanal DSRC/ITS-G5 und ein Kanal LTE C-V2X auf eine feste Art (obere/untere Kanäle) zugewiesen wird. Der mittlere Kanal sollte kurzfristig unbenutzt bleiben. Dieser Vorschlag ist von dem Conference of Postal and Telecommunications Administrations (CEPT) Electronic Communication Committee (ECC), „SRDMG(17)136 ITS Background - Short Prel Action Plan and Background“ sowie der Mitteilung von ECC#46 („SRDMG“) abgelehnt worden, da eine Regulierung technologieneutral sein muss. SRDMG hat stattdessen dargelegt, dass der Ansatz des bevorzugten Kanals durchführbar sein kann. Anstatt einer festen Zuweisung von Kanälen zu DSRC/ITS-G5 und LTE C-V2X, kann eine solche Zuweisung dynamisch zwischen den betroffenen Systemen verhandelt werden. Ferner wird, wenngleich es möglich ist, das DSRC/ITS-G5 und LTE C-V2X in demselben Kanal koexistieren (z. B. auf Listen Before Talk (LBT) basierender Kanalzugriff), aufgrund des verschiedenen Wesens der Kanalzugriffsprotokolle von DSRC/ITS-G5 und LTE C-V2X dieser Ansatz als sehr ineffizient betrachtet.
• Der hierin erläuterte technische Ansatz sieht keine fixe Zuweisung für zwei oder mehr unterschiedliche Fahrzeugkommunikationstechnologien (z. B. DSRC/ITS-G5 und LTE C-V2X), die auf dasselbe Band zugreifen, vor. Stattdessen bestimmt die Edge-Netzwerkinfrastruktur (z. B. eine RSU oder ein kollokierter MEC-Server/- Host) die benötigte Menge an Spektrum für jedes Fahrzeugkommunikationssystem basierend auf der Anzahl an vUEs, die jede Art von Fahrzeugkommunikationstechnologie verwenden, weist dynamisch (oder halbstatisch) eine Zuweisung eines bevorzugten Kanals (je nach den lokalen Anforderungen) zu und leitet die Zuweisung (oder eine Angabe der Zuweisungsentscheidung) an eine benachbarte Infrastruktur (z. B. eine oder mehrere RSUs) weiter. In einer alternativen Ausführungsform senden die vUEs Anforderungen bezüglich einer spezifischen Fahrzeugkommunikationstechnologie und weist die Edge-Netzwerkinfrastruktur dynamisch (oder halbstatisch) Ressourcen basierend auf der Anzahl an Anforderungen für jeden Typ von Kommunikationstechnologie zu.
• Die folgende Erläuterung führt einen Ansatz zum Verwenden von MEC- und Edge-Netzwerkentitäten bei der Unterstützung des Ansatzes bevorzugter Kanäle und der dynamischen Zuweisung von Kanälen unter mehreren Fahrzeug-RATs (auch als „V2X RATs“ bezeichnet), wie etwa DSRC/ITS-G5 und LTE C-V2X, ein. Der hierin erläuterte technische Ansatz kann von Regulierungsbehörden (diese erlauben eine dynamische Zuweisung, einen sogenannten Ansatz „bevorzugter Kanäle“) akzeptiert werden und führt zu einer hocheffizienten Gesamtlösung, die viel effizienter ist, als wenn beide Systeme in demselben Kanal vorhanden sind. Ferner wird das Anbieten einer Lösung, die die Aufnahme dieser beiden alternativen Technologien (z. B. der sogenannte technologieneutrale Ansatz) berücksichtigt, eine bessere Interoperabilität in dem V2X-Ökosystem sowie die Möglichkeit, V2X/ITS-Dienste über breitere Einsatzgebiete hinweg zu bieten, bereitstellen.
• Die folgende Beschreibung stellt eine ausführliche Erläuterung dieser Techniken innerhalb von MEC-Systemen und -Diensten bereit, die bei dem größeren Kontext von Einsätzen des Internets der Dinge (IoT, Internet of Things) und Fog-Netzwerks angewendet werden können. Es versteht sich, dass das offenbarte MEC-System und die offenbarten Diensteinsatz-Beispiele ein veranschaulichendes Beispiel einer Fog-Vorrichtung oder eines Fog-Systems bereitstellen, dass jedoch viele andere Kombinationen und Layouts von Vorrichtungen, die an dem Rand eines Netzwerks liegen, bereitgestellt werden können. Ferner können sich die hierin offenbarten Techniken auf andere IoT-Standards und -Konfigurationen und andere Zwischenverarbeitungsentitäten und -architekturen beziehen. Die vorliegenden Techniken und Konfigurationen können deutliche Vorteile für MEC-Architekturen und andere IoT-Vorrichtungsnetzwerkarchitekturen bieten, die eine beliebige Anzahl an Edge-Computing-Vorrichtungen oder Fog-Computing-Plattformen beinhalten.
• Zu Veranschaulichungszwecken wird die folgende Beschreibung für Einsatzszenarien bereitgestellt, die Fahrzeuge (einschließlich computerunterstützter und/oder autonomer Fahrzeuge) in einer zweidimensionalen Umgebung (2D-Umgebung) einer Autobahn/Schnellstraße/Fahrbahn, wo die Fahrzeuge Autos sind, aufweisen. Die hierin beschriebenen Ausführungsformen sind jedoch auch bei anderen Arten von Fahrzeugen, wie etwa Lastkraftwagen, Bussen, Motorbooten, Motorrädern, elektrischen Personentransportern und/oder beliebigen sonstigen motorisierten Vorrichtungen, die in der Lage sind, Personen oder Güter zu transportieren, anwendbar. Die hierin beschriebenen Ausführungsformen sind auch bei Social Networking zwischen Fahrzeugen verschiedener Fahrzeugtypen anwendbar. Die hierin beschriebenen Ausführungsformen können auch bei dreidimensionalen Einsatzszenarien (3D-Einsatzszenarien), wo einige oder alle der Fahrzeuge als fliegende Objekte, wie etwa Flugzeuge, Drohnen, unbemannte Luftfahrzeuge (UVAs, Unmanned Aerial Vehicles), implementiert sind, und/oder bei beliebigen sonstigen ähnlichen motorisierten Vorrichtungen angewendet werden.
• Unter Bezugnahme nunmehr auf 1 veranschaulicht diese eine Mehrfachzugriff-Edge-Computing-Umgebung (MEC-Umgebung) 100 gemäß verschiedenen Ausführungsformen. 1 veranschaulicht spezifisch die unterschiedlichen Kommunikationsschichten, die innerhalb der Umgebung 100 auftreten, angefangen von Endpunktsensoren oder einer Dingeschicht 110 (die z. B. in einer IoT-Netzwerktopologie agieren), die eine oder mehrere IoT-Vorrichtungen 111 (auch als Edge-Endpunkte 110 oder dergleichen bezeichnet) aufweisen; mit zunehmender Ausgereiftheit zu Gateways oder einer Zwischenknotenschicht 120, die ein oder mehrere Nutzerendgeräte (UEs, User Equipment) 121a und 121b (auch als Zwischenknoten 120 oder dergleichen bezeichnet) aufweisen, welche das Sammeln und Verarbeiten von Daten von Endpunkten 110 ermöglichen; mit zunehmender Verarbeitungs- und Konnektivitätsausgereiftheit zu einer Zugriffs- oder Edge-Knotenschicht 130, die eine Vielzahl von Zugriffsknoten (Ans, Access Nodes) 131, 132 und 133 (auch als Edge-Rechenknoten 130 oder dergleichen bezeichnet) aufweisen; und mit zunehmender Konnektivitäts- und Verarbeitungsausgereiftheit zu einer Backend-Schicht 110, die ein Kernnetzwerk (CN, Core Network) 142 und eine Cloud 144 aufweist. Die Verarbeitung an der Backend-Schicht 110 kann durch Netzwerkdienste verstärkt werden, wie sie von einem Remote-Anwendungsserver 150 und/oder anderen Cloud-Diensten durchgeführt werden.
• Eine Endnutzervorrichtung, wie etwa ein Zwischenknoten 120 oder Endpunkt 110, hat Zugriff auf mehrere Kommunikationsnetzwerke basierend auf verschiedenen Technologien, zum Beispiel LTE- oder NR/5G-Mobilfunktechnologie (wie z. B. durch den AN 131 und/oder die ANs 132 bereitgestellt), WiFi (wie z. B. durch den AN 133 und/oder die ANs 132 bereitgestellt), DSL, MuLTEfire usw. zum Zugreifen auf Anwendungsdienste. Unterschiedliche Technologien zeigen Vorteile und Beschränkungen in unterschiedlichen Szenarien, und die Anwendungsleistung in unterschiedlichen Szenarien wird von der Wahl der Zugriffsnetzwerke (z. B. WiFi, LTE usw.) und den verwendeten Netzwerk- und Transportprotokollen (z. B. VPN, MPTCP, GRE usw.) abhängig. Zum Beispiel kann WiFi einen hohen Durchsatz für die Zwischenknoten 120 und die Endpunkte 110 bereitstellen, wenn sie sich unter einer relativ guten Abdeckung befinden, jedoch verschlechtert sich der Durchsatz deutlich, wenn sich der Nutzer näher an den Rand des WiFi-Abdeckungsbereichs bewegt oder wenn ein AN 133 eine relativ große Nutzerpopulation bedient (z. B. aufgrund eines wettbewerbsbasierten WiFi-Zugriffsschemas). Bei LTE- oder NR-Netzwerken ist die Kapazität oft durch die beschränkte Verfügbarkeit des lizenzierten Spektrums beschränkt, jedoch ist die Qualität des Dienstes selbst in Mehrfachnutzerszenarien aufgrund der Exklusivität des lizenzierten Spektrums und der gesteuerten Planung, die von einer bedienenden Basisstation bereitgestellt wird, vorhersagbar.
• Im Gegensatz zu LTE- und NR-Netzwerken, die ein lizenziertes Spektrum verwenden, ist WiFi ein geteiltes Medium, das in der unlizenzierten Funkfrequenz (RF, Radiofrequency) von 2,4 GHz- und 5GHz-Bereichen agiert. Die 3GPP-Variante von unlizenziertem Zugriff wird LAA genannt. LAA zielt darauf ab, LTE- und/oder NR-Spezifikationen für globale Harmonisierung zu gestalten, die eine faire Koexistenz mit WiFi und anderen Netzwerken in einem geteilten Medium erlauben. LAA setzt ein Medienzugriffsschema ein, das ähnlich wie EDCA von WiFi ist. Die Koexistenzauswirkung auf die Fairness und den Durchsatz in Bezug auf LTE und/oder NR ist auch eine aktuelle Herausforderung für beide Standards. Ein Problem, das auftreten kann, wenn Netzwerktechnologien verwendet werden, die in einem geteilten Medium funktionierten, ist, dass Pakete während der Übertragung zum Beispiel aufgrund von temporärer Interferenz, Paketkollisionen, Stau und Pufferüberlauf verloren gehen können. Bei aktuellen WiFi-basierten Protokollen unterstützen MAC-Protokolle beschränkte Weiterleitungen, um verlorengegangene Pakete wiederherzustellen. Insbesondere wird ein WiFi-Sender ein Paket aufgeben und fallen lassen, wenn eine maximale Weiterleitungsgrenze erreicht ist. Zusätzlich ist das WiFi-basierte Weiterleitungsverfahren nicht anwendbar, wenn ein Paket fallen gelassen wird, aufgrund von temporärem Stau und/oder Pufferüberlauf. Ähnlich verwendet LAA eine Wettbewerbsfenstergröße (CWS, Contention Window Size) zum Weiterleiten von verlorenen Paketen, wobei sich das CWS auf eine exponentielle Art basierend auf der HARQ-ACK in der MAC-Schicht vergrößert.
• Wieder unter Bezugnahme auf 1 ist die Umgebung 100 derart gezeigt, dass sie ein UE 121a und ein UE 121b aufweist (die gemeinsam als „UE 121“ oder UEs 121" bezeichnet werden). In diesem Beispiel ist das UE 121a als ein Fahrzeug-UE veranschaulicht und ist das UE 121b als ein Smartphone (z. B. eine handgehaltene mobile Touchscreen-Rechenvorrichtung, die mit einem oder mehreren zellulären Netzwerken verbunden werden kann) veranschaulicht. Diese UEs 121 können jedoch eine beliebige mobile oder nicht-mobile Rechenvorrichtung, wie etwa Tablet-Computer, Wearable-Vorrichtungen, PDAs, Pager, Desktop-Computer, Laptop-Computer, drahtlose Handsets, unbemannte Fahrzeuge oder Drohnen, IVIs, ICEs, Instrument-Cluster, HUDs, OBDs, DMEs, MDTs, OBUs, EMS, EEMS, ECUs, ECMs, eingebettete Systeme, Mikrocontroller, Steuermodule, vernetzte oder „intelligente“ Geräte, MTC-Vorrichtungen, M2M, IoT-Vorrichtungen und/oder eine beliebige Art von Rechenvorrichtung einschließlich einer Drahtloskommunikationsschnittstelle, umfassen.
• Die Umgebung 100 weist auch IoT-Vorrichtungen 111 auf, welche eindeutig identifizierbare, eingebettete Rechenvorrichtungen sind (z. B. innerhalb der Internet-Infrastruktur), die eine Netzwerkzugriffsschicht aufweisen, die für IoT-Anwendungen mit geringer Leistung unter Verwendung von kurzweiligen UE-Verbindungen gestaltet ist. Die IoT-Vorrichtungen 111 können beliebige Objekte, Vorrichtungen, Sensoren oder „Dinge“ sein, die mit Hardware- und/oder Softwarekomponenten eingebettet sind, die den Objekten, Vorrichtungen, Sensoren oder „Dingen“ ermöglichen, in der Lage zu sein, Daten, die mit einem Ereignis verknüpft sind, aufzunehmen und/oder aufzuzeichnen, und in der Lage zu sein, solche Daten mit einer oder mehreren anderen Vorrichtungen über ein Netzwerk mit geringer oder keiner Nutzerintervention zu kommunizieren. Zum Beispiel können in verschiedenen Ausführungsformen die IoT-Vorrichtungen 111 abiotische Vorrichtungen, wie etwa autonome Sensoren, Messinstrumente, Messgeräte, Bildaufnahmevorrichtungen, Mikrofone, Leuchtvorrichtungen, Audio-Ausgabevorrichtungen, Audio- und/oder Video-Wiedergabevorrichtungen, elektromechanische Vorrichtungen (z. B. Schalter, Aktor usw.) und dergleichen, sein. Die IoT-Vorrichtungen 111 können Technologien, wie etwa M2M oder MTC, zum Austauschen von Daten mit einem MTC-Server (z. B. einem Server 150), einem MEC-Server 136 und/oder MEC-System, oder einer Vorrichtung über ein PLMN, ProSe- oder D2D-Kommunikation, Sensornetzwerke oder IoT-Netzwerke verwenden. Der M2M- oder MTC-Datenaustausch kann ein von einer Maschine initiierter Datenaustausch sein.
• Die IoT-Vorrichtungen 111 können Hintergrundanwendungen (z. B. Keepalive-Nachrichten, Status-Updates usw.) ausführen, um die Verbindungen des IoT-Netzwerks zu ermöglichen. Wenn die IoT-Vorrichtungen 111 Sensorvorrichtungen sind oder in diesen eingebettet sind, kann das IoT-Netzwerk ein WSN sein. Ein IoT-Netzwerk beschreibt eine Verschaltung von IoT UEs, wie etwa der IoT-Vorrichtungen 111, die über jeweilige direkte Verknüpfungen 105 miteinander verbunden sind. Die IoT-Vorrichtungen können eine beliebige Anzahl an verschiedenen Arten von Vorrichtungen aufweisen, die in verschiedene Kombinationen gruppiert sind (als eine „IoT-Gruppe“ bezeichnet), die IoT-Vorrichtungen aufweisen können, die einen oder mehrere Dienste für einen konkreten Nutzer, Kunden, Organisationen usw. bereitstellen. Ein Dienstanbieter (z. B. ein Eigentümer/Betreiber des Servers 150, des CN 412 und/oder der Cloud 144) kann die IoT-Vorrichtungen in der IoT-Gruppe in einem konkreten Bereich (z. B. einer Geolokalisierung, einem Gebäude usw.) einsetzen, um den einen oder die mehreren Dienste bereitzustellen. Bei einigen Implementierungen kann das IoT-Netzwerk ein Mesh-Netzwerk der IoT-Vorrichtungen 111 sein, welches als eine Fog-Vorrichtung, ein Fog-System oder Fog bezeichnet werden kann, das an dem Rand der Cloud 144 agiert. Der Fog beinhaltet Mechanismen, um Cloud-Computing-Funktionalität näher an Datenerzeuger und -verbraucher zu bringen, wobei verschiedene Netzwerkvorrichtungen eine Cloud-Anwendungslogik auf ihrer nativen Architektur ausführen. Fog-Computing ist eine horizontale Systemebenenarchitektur, die Ressourcen und Dienste des Berechnens, Speicherns, Steuerns und Vernetzens überall entlang des Kontinuums von der Cloud 144 zu den Dingen (z. B. den IoT-Vorrichtungen 111) verteilt. Der Fog kann gemäß Spezifikationen festgelegt werden, die unter anderem von der OFC, der OCF herausgegeben werden. In einigen Ausführungsformen kann der Fog ein Tangle sein, wie er von der IOTA-Stiftung definiert ist.
• Der Fog kann verwendet werden, um eine Berechnung/Aggregation mit geringer Latenz bei den Daten durchzuführen, während er sie zu einem Edge-Cloud-Computing-Dienst (z. B. den Edge-Knoten 130) und/oder einem zentralen Cloud-Computing-Dienst (z. B. der Cloud 144) zum Durchführen von hohen Rechenleistungen oder rechenintensiven Aufgaben weiterleitet. Andererseits konsolidiert Edge-Cloud-Computing von Menschen betriebene, freiwillige Ressourcen als eine Cloud. Diese freiwilligen Ressourcen können unter anderem die Zwischenknoten 120 und/oder die Endpunkte 110, Desktop-PCs, Tablets, Smartphones, Nanodatenzentren und dergleichen umfassen. Bei verschiedenen Implementierungen können Ressourcen in der Edge-Cloud in einer Nähe von einem bis zwei Sprüngen zu den IoT-Vorrichtungen 111 vorliegen, was zu einer Verringerung der Belastung in Verbindung mit der Verarbeitung von Daten führen kann und die Netzwerkverzögerung verringern kann.
• In einigen Ausführungsformen kann der Fog eine Konsolidierung der IoT-Vorrichtungen 111 und/oder Netzwerkvorrichtungen, wie etwa Router und Schalter, mit hohen Rechenfähigkeiten und der Fähigkeit, eine Cloud-Anwendungslogik auf ihrer nativen Architektur auszuführen, sein. Fog-Ressourcen können von Cloud-Anbietern hergestellt, verwaltet und eingesetzt werden und können mit zuverlässigen Hochgeschwindigkeitsverknüpfungen verbunden werden. Ferner befinden sich Fog-Ressourcen weiter von dem Rand des Netzwerks entfernt im Vergleich zu Edge-Systemen, jedoch näher als eine zentrale Cloud-Infrastruktur. Fog-Vorrichtungen werden verwendet, um rechenintensive Aufgaben oder Auslastungen, die von Edge-Ressourcen abgegeben werden, effektiv handzuhaben.
• In Ausführungsformen kann der Fog an dem Rand der Cloud 144 agieren. Der Fog, der an dem Rand der Cloud 144 agiert, kann sich mit einem Edge-Netzwerk 130 der Cloud 144 überlappen oder mit diesem zusammengefasst werden. Das Edge-Netzwerk der Cloud 144 kann sich mit dem Fog überlappen oder ein Teil des Fogs werden. Ferner kann der Fog ein Edge-Fog-Netzwerk sein, das eine Edge-Schicht und eine Fog-Schicht aufweist. Die Edge-Schicht des Edge-Fog-Netzwerks weist eine Sammlung von lose gekoppelten, freiwilligen und von Personen bedienten Ressourcen (z. B. die zuvor genannten Edge-Rechenknoten oder Edge-Vorrichtungen) auf. Die Fog-Schicht liegt über der Edge-Schicht und ist eine Konsolidierung von Netzwerkvorrichtungen, wie etwa der Zwischenknoten 120 und/oder Endpunkte 110 von 1.
• Es können Daten erfasst, gespeichert/aufgezeichnet und unter den IoT-Vorrichtungen 4804 (oder zum Beispiel unter den Zwischenknoten 120 und/oder Endpunkten 110, die direkte Verknüpfungen 105 miteinander aufweisen, wie durch 1 gezeigt) kommuniziert werden. Es kann eine Analyse des Traffic-Flusses und der Steuerschemen durch Aggregatoren implementiert werden, die durch ein Mesh-Netzwerk mit den IoT-Vorrichtungen 111 und miteinander in Verbindung stehen. Die Aggregatoren können eine Art von IoT-Vorrichtung 111 und/oder Netzwerkgerät sein. In dem Beispiel von 1 können die Aggregatoren Edge-Knoten 130 oder ein oder mehrere designierte Zwischenknoten 120 und/oder Endpunkte 110 sein. Es können Daten über den Aggregator in die Cloud 144 hochgeladen werden und es können Befehle von der Cloud 144 durch Gateway-Vorrichtungen erhalten werden, die durch das Mesh-Netzwerk mit den IoT-Vorrichtungen 111 und den Aggregatoren in Verbindung stehen. Im Gegensatz zu dem herkömmlichen Cloud-Computing-Modell kann bei einigen Implementierungen die Cloud 144 geringe oder keine Rechenfähigkeiten aufweisen und dient nur als eine Ablage zum Archivieren von Daten, die von dem Fog aufgezeichnet und verarbeitet werden. Bei diesen Implementierungen ist die Cloud 144 ein zentralisiertes Datenspeichersystem und stellt Zuverlässigkeit und Zugriff auf Daten durch die Rechenressourcen in den Fog- und/oder Edge-Vorrichtungen bereit. Indem sie sich an dem Kern der Architektur befinden, ist die Datenablage der Cloud 144 sowohl von Edge- als auch Fog-Schichten des zuvor genannten Edge-Fog-Netzwerks zugänglich.
• Die UEs 121 und die IoT-Vorrichtungen 111 können konfiguriert sein, um sich mit einem Funkzugriffsnetzwerk (RAN, Radio Access Network), das einen oder mehrere der ANs 131, 132 und/oder 133 aufweist, zu verbinden, zum Beispiel kommunikativ mit diesen zu koppeln. In Ausführungsformen kann das RAN ein NG RAN oder ein 5G RAN, ein E-UTRAN oder ein älteres RAN, wie etwa ein UTRAN oder GERAN, sein. So wie er hierin verwendet wird, kann sich der Begriff „NG RAN“ auf ein RAN beziehen, dass in einem NR- oder 5G-System agiert, und kann sich der Begriff „E-UTRAN“ oder dergleichen auf ein RAN beziehen, das in einem LTE- oder 4G-System agiert. Die UEs 121 und die IoT-Vorrichtungen 111 können jeweils jeweilige Verbindungen (oder Kanäle) 103 verwenden, die jeweils eine physische Kommunikationsschnittstelle oder -schicht aufweisen. In diesem Beispiel sind die Verbindungen 103 als eine Luftschnittstelle zum Ermöglichen von einer kommunikativen Kopplung veranschaulicht und können zellulären Kommunikationsprotokollen, wie etwa einem GSM-Protokoll, einem CDMA-Netzwerkprotokoll, einem PTT-Protokoll, einem POC-Protokoll, einem UMTS-Protokoll, einem 3GPP LTE-Protokoll, einem 5G-Protokoll, einem NR-Protokoll, und/oder einem beliebigen der anderen hierein erläuterten Kommunikationsprotokolle entsprechen.
• In Ausführungsformen können die UEs 121 und die IoT-Vorrichtungen 111 ferner direkt Kommunikationsdaten über jeweilige direkte Schnittstellen (oder Verknüpfungen) 105 austauschen. Bei einigen Implementierungen können die Schnittstellen 105 eine WiFi-basierte Verknüpfung oder eine auf einem persönlichen Netzwerk (PAN, Personal Area Network) basierte Verknüpfung (z. B. IEEE 802.15.4-basierte Protokolle einschließlich ZigBee, IPv6 über drahtlose persönliche Netzwerke mit geringer Leistung (6LoWPAN), WirelessHART, MiWi, Thread usw.; WiFi-direct; Bluetooth/Bluetooth Low Energy-Protokolle (BLE-Protokolle) sein. Bei anderen Implementierungen kann die Schnittstelle 105 eine LTE/NR ProSe-Verknüpfung (LTE/NR Proximity Services link) oder PC5-Schnittstelle sein.
• Gemäß verschiedenen Ausführungsformen kommunizieren (z. B. senden und empfangen) die UEs 121 und die IoT-Vorrichtungen 111 und die RAN-Knoten 131/132 Daten über ein lizenziertes Medium (auch als das „lizenzierte Spektrum“ und/oder das „lizenzierte Band“ bezeichnet) und ein unlizenziertes geteiltes Medium (auch als das „unlizenzierte Spektrum“ und/oder das „unlizenzierte Band“ bezeichnet). Das lizenzierte Spektrum kann Kanäle aufweisen, die in dem Frequenzbereich von ungefähr 100 MHz bis ungefähr 3,8 GHz agieren, während das unlizenzierte Spektrum das 5 GHz-Band aufweisen kann. Um in dem unlizenzierten Spektrum zu agieren, können die UEs 121 und die IoT-Vorrichtungen 111 und die RAN-Knoten 131/132 unter Verwendung von LAA-Mechanismen, verbesserten LAA-Mechanismen (eLAA-Mechanismen) und/oder weiteren eLAA-Mechanismen (feLAA-Mechanismen) agieren. Bei diesen Implementierungen können die UEs 121 und die IoT-Vorrichtungen 111 und die RAN-Knoten 131/132 eine oder mehrere bekannte Medienerfassungsoperationen und/oder Trägererfassungsoperationen durchführen, um zu bestimmen, ob ein oder mehrere Kanäle in dem unlizenzierten Spektrum nicht verfügbar sind oder anderweitig vor dem Senden in dem unlizenzierten Spektrum belegt sind. Die Medium-/Trägererfassungsoperationen können gemäß einem Listen-Before-Talk-Protokoll (LBT-Protokoll) durchgeführt werden. LBT ist ein Mechanismus, wo die Ausrüstung (z. B. die UEs 121 und die IoT-Vorrichtungen 111, die RAN-Knoten 131/132 usw.) ein Medium (zum Beispiel ein Kanal oder eine Trägerfrequenz) erfasst und sendet, wenn das Medium als inaktiv erfasst wird (oder wenn ein spezifischer Kanal in dem Medium als unbelegt erfasst wird). Die Medienerfassungsoperation kann CCA umfassen, welche mindestens ED verwendet, um das Vorhandensein oder Fehlen von anderen Signalen auf einem Kanal zu bestimmen, um zu bestimmen, ob ein Kanal belegt oder frei ist. Dieser LBT-Mechanismus erlaubt zellulären/LAA-Netzwerken, mit vorherrschenden Systemen in dem unlizenzierten Spektrum und mit anderen LAA-Netzwerken zu koexistieren. ED kann das Erfassen von RF-Energie über ein vorgesehenes Übertragungsband während eines Zeitraums und das Vergleichen der erfassten HF-Energie mit einem vorab definierten oder konfigurierten Schwellenwert umfassen.
• Das UE 121b ist derart gezeigt, dass es konfiguriert ist, um auf einen Zugangspunkt (AP, Access Point) 133 über eine Verbindung 107 zuzugreifen. Die Verbindung 107 kann eine lokale drahtlose Verbindung, wie etwa eine Verbindung, die einem beliebigen IEEE 802.11-Protokoll entspricht, aufweisen, wobei der AP 133 einen Wireless Fidelity-Router (WiFi®-Router) umfassen würde. In diesem Beispiel ist der AP 133 als mit dem Internet verbunden, ohne mit dem CN 142 des Drahtlossystems verbunden zu sein, gezeigt. In verschiedenen Ausführungsformen können das UE 121b, die RAN-Knoten 131/132 und der AP 106 konfiguriert sein, um einen LWA-Betrieb und/oder einen LWIP-Betrieb zu verwenden. Der LWA-Betrieb kann beinhalten, dass das UE 121b durch einen RAN-Knoten 131/132 konfiguriert ist, um Funkressourcen des LTE/NR und WLAN zu verwenden. Der LWIP-Betrieb kann beinhalten, dass das UE 121b WLAN-Funkressourcen (z. B. die Verbindung 107) über IPsec-Protokolltunneln zum Authentizieren und Verschlüsseln von Paketen (z. B. IP-Paketen), die über die Verbindung 107 gesendet werden, verwendet. IPsec-Tunneln umfasst das Einkapseln der gesamten ursprünglichen IP-Pakete und Hinzufügen eines neuen Paketheaders, wodurch der ursprüngliche Header der IP-Pakete geschützt wird.
• Das RAN kann einen oder mehrere AN-Knoten oder RAN-Knoten 131 und 132 aufweisen (die gemeinsam als „die RAN-Knoten“ oder „der RAN-Knoten“ bezeichnet werden), die die Verbindungen 103 ermöglichen. So wie sie hierin verwendet werden, können die Begriffe „Zugangsknoten“, „Zugangspunkt“ oder dergleichen eine Ausrüstung beschreiben, die die Funkbasisbandfunktionen für Daten- und/oder Sprachkonnektivität zwischen einem Netzwerk und einem oder mehreren Nutzern bereitstellt.
• In diesem Beispiel ist der RAN-Knoten 131 als ein NodeB, evolved NodeB (eNB) oder ein Next Generation NodeB (gNB) ausgeführt und sind die RAN-Knoten 132 als straßenseitige Einheiten (RSUs) ausgeführt. Es kann eine beliebige sonstige Art von ANs verwendet werden, und die ANs können Bodenstationen (z. B. terrestrische Zugangspunkte) oder Satellitenstationen, die eine Abdeckung innerhalb eines geographischen Bereichs (z. B. einer Zelle) bereitstellen, umfassen. So wie er hierin verwendet wird, kann sich der Begriff „NG RAN-Knoten“ oder dergleichen auf einen RAN-Knoten 111 beziehen, der in einem NR- oder 5G-System agiert (zum Beispiel ein gNB), und kann sich der Begriff „E-UTRAN-Knoten“ oder dergleichen auf einen RAN-Knoten 131 beziehen, der in einem LTE- oder 4G-System arbeitet (z. B. ein eNB). Gemäß verschiedenen Ausführungsformen können die RAN-Knoten 131 als eine oder mehrere einer dedizierten physischen Vorrichtung, wie etwa eine Makrozellenbasisstation, und/oder eine Basisstation mit geringer Leistung zum Bereitstellen von Femtozellen, Pikozellen oder sonstigen ähnlichen Zellen, die kleinere Abdeckungsbereiche, eine geringere Nutzerkapazität oder eine höhere Bandbreite im Vergleich zu Makrozellen aufweisen, implementiert werden.
• In einigen Ausführungsformen können alle RAN-Knoten 131/132 oder Teile davon als eine oder mehrere Softwareentitäten implementiert sein, die auf Servercomputern als Teil eines virtuellen Netzwerks ausgeführt werden, welche als ein Cloud RAN (CRAN), Kognitiver Funk (CR, Cognitive Radio) und/oder ein virtueller Basisbandeinheitspool (vBBUP, Virtual Baseband Unit Pool) bezeichnet werden können. In diesen Ausführungsformen kann das CRAN, der CR oder der vBBUP eine RAN-Funktionsaufteilung, wie etwa eine PDCP-Aufteilung, wobei RRC- und PDCP-Schichten von dem CRAN/vBBUP betrieben werden und andere L2-Protokollentitäten von einzelnen RAN-Knoten 131/132 betrieben werden; eine MAC/PHY-Aufteilung, wobei RRC-, PDCP-, RLC- und MAC-Schichten von dem CRAN/vBBUP betrieben werden und die PHY-Schicht von einzelnen RAN-Knoten 131/132 betrieben wird; oder eine „untere PHY“-Aufteilung, wobei RRC-, PDCP-, RLC-, MAC-Schichten und obere Teile der PHY-Schicht von dem CRAN/vBBUP betrieben werden und untere Teile der PHY-Schicht von einzelnen RAN-Knoten 131/132 betrieben werden, implementieren. Dieses virtualisierte Framework erlaubt den freigewordenen Prozessorkernen der RAN-Knoten 131/132, andere virtualisierte Anwendungen durchzuführen. Bei einigen Implementierungen kann ein einzelner RAN-Knoten 131/132 einzelne gNB-DUs darstellen, die über einzelne Schnittstellen mit einer gNB-CU verbunden sind (nicht durch 1 gezeigt). Bei diesen Implementierungen weisen die gNB-DUs einen oder mehrere entfernte Radio Heads oder RFEMs auf (siehe z. B. die 6-XS2 weiter unten) und kann die gNB-CU von einem Server, der in dem RAN liegt (nicht gezeigt), oder von einem Server-Pool auf eine ähnliche Art wie das CRAN/vBBUP betrieben werden. Zusätzlich oder alternativ können einer oder mehrere der RAN-Knoten 131/132 Next Generation eNBs (ng-eNBs) sein, welche RAN-Knoten 131/132 sind, die E-UTRA-Nutzerebenen- und Steuerebenen-Protokollterminierungen zu den UEs 121 hin bereitstellen und mit einem 5GC über eine NG-Schnittstelle verbunden sind.
• Ein beliebiger der RAN-Knoten 131/132 kann das Luftschnittstellenprotokoll beenden und kann die erste Kontaktstelle für die UEs 121 und die IoT-Vorrichtungen 111 sein. In einigen Ausführungsformen kann ein beliebiger der RAN-Knoten 131/132 verschiedene logische Funktionen für das RAN einschließlich Funknetzwerksteuerungsfunktionen(RNC-Funktionen, Radio Network Controller functions), wie etwa Funkträgerverwaltung, dynamische Uplink- und Downlink-Funkressourcenverwaltung und Datenpaketplanung und Mobilitätsverwaltung, ohne jedoch darauf beschränkt zu sein, erfüllen. In Ausführungsformen können die UEs 121 und die IoT-Vorrichtungen 111 konfiguriert sein, unter Verwendung von OFDM-Kommunikationssignalen miteinander oder mit einem beliebigen der RAN-Knoten 131/132 über einen Mehrfachträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken, wie etwa eine OFDMA-Kommunikationstechnik (z. B. für Downlink-Kommunikationen) und/oder eine SC-FDMA-Kommunikationstechnik (z. B. für Uplink- und ProSe- oder Sidelink-Kommunikationen), ohne jedoch darauf beschränkt zu sein, zu kommunizieren, wenngleich der Umfang der Ausführungsformen nicht diesbezüglich beschränkt ist.
• Die RAN-Knoten 131/132 können konfiguriert sein, um über jeweilige Schnittstellen oder Verknüpfungen (nicht gezeigt), wie etwa eine X2-Schnittstelle für LTE-Implementierungen (wenn z. B. das CN 142 ein entwickelter Paketkern (EPC, Evolved Packet Core) ist), eine Xn-Schnittstelle für 5G- oder NR-Implementierungen (wenn z. B. das CN 142 ein Kern der fünften Generation (5GC, Fifth Generation Core) ist), oder dergleichen zu kommunizieren.
• Die ANs 131 und 132 sind kommunikativ mit dem CN 142 gekoppelt. In Ausführungsformen kann das CN 142 ein fortentwickeltes Paketkernnetzwerk(EPC-Netzwerk), ein NextGen-Paketkernnetzwerk(NPC-Netzwerk), ein 5G-Kern (5GC) oder irgendeine andere Art von CN sein. Das CN 142 kann eine Vielzahl an Netzwerkelementen aufweisen, welche konfiguriert sind, um verschiedene Daten- und Telekommunikationsdienste Kunden/Teilnehmern (z. B. Nutzern der UEs 121 und der IoT-Vorrichtungen 111), die mit dem CN 142 über ein RAN verbunden sind, anzubieten. Die Komponenten des CN 142 können in einem physischen Knoten oder separaten physischen Knoten einschließlich Komponenten zum Lesen und Ausführen von Anweisungen von einem maschinenlesbaren oder computerlesbaren Medium (z. B. einem nichtflüchtigen maschinenlesbaren Speichermedium) implementiert werden. In einigen Ausführungsformen kann die Netzwerkfunktionsvirtualisierung (NFV) verwendet werden, um eine oder alle der zuvor beschriebenen Netzwerkknotenfunktionen über ausführbare Anweisungen, die in einem oder mehreren computerlesbaren Speichermedien (weiter unten ausführlicher beschrieben) gespeichert sind, zu virtualisieren. Eine logische Instantiierung des CN 142 kann als ein Netzwerkstück bezeichnet werden, und eine logische Instantiierung eines Teils des CN 142 kann als ein Netzwerk-Teilstück bezeichnet werden. Es können NFV-Architekturen und -Infrastrukturen verwendet werden, um eine oder mehrere Netzwerkfunktionen, die alternativ durch proprietäre Hardware durchgeführt werden, auf physische Ressourcen, die eine Kombination von Industriestandard-Serverhardware, Speicherhardware oder Schaltern aufweisen, zu virtualisieren. Mit anderen Worten können NFV-Systeme verwendet werden, um virtuelle oder neukonfigurierbare Implementierungen von einem oder mehreren Komponenten/Funktionen des CN 142 auszuführen.
• Das CN 142 ist derart gezeigt, dass es über eine IP-Kommunikationsschnittstelle 155 kommunikativ mit einem Anwendungsserver 150 und einem Netzwerk 150 gekoppelt ist, wobei der eine oder die mehreren Server 150 ein oder mehrere physische und/oder virtualisierte Systeme zum Bereitstellen von Funktionalität (oder Diensten) für einen oder mehrere Clients (z. B. die UEs 121 und die IoT-Vorrichtungen 111) über ein Netzwerk (z. B. die Cloud 144) aufweisen. Der/die Server 150 kann/können verschiedene Computervorrichtungen mit (einer) Rack-Computing-Architekturkomponente(n), Tower-Computing-Architekturkomponente(n), Blade-Computing-Architekturkomponente(n) und/oder dergleichen aufweisen. Der/die Server 150 kann/können ein Cluster von Servern, eine Serverfarm, einen Cloud-Computing-Dienst oder eine sonstige Gruppierung oder einen sonstigen Pool von Servern, welche in einem oder mehreren Datenzentren liegen können, darstellen. Der/die Server 130 kann/können auch mit einer oder mehreren Datenspeichervorrichtungen (nicht gezeigt) verbunden oder anderweitig verknüpft sein. Ferner kann/können der/die Server 150 ein Betriebssystem (OS, Operating System) aufweisen, das ausführbare Programmanweisungen für die allgemeine Verwaltung und Bedienung der einzelnen Server-Computervorrichtungen bereitstellt, und ein computerlesbares Medium aufweisen, das Anweisungen speichert, die, wenn sie von einem Prozessor der Server ausgeführt werden, erlauben können, dass die Server ihre vorgesehenen Funktionen durchführen. Geeignete Implementierungen für das OS und allgemeine Funktionalität von Servern sind bekannt oder auf dem Markt verfügbar und werden leicht von einem Fachmann implementiert. Im Allgemeinen bietet/bieten der/die Server 150 Anwendungen oder Dienste an, die IP-/Netzwerkressourcen verwenden. Als Beispiel kann/können der/die Server 150 Traffic-Verwaltungsdienste, Cloud-Analysen, Content-Streaming-Dienste, immersive Spielerlebnisse, Social Networking-Dienste und/oder Microblogging-Dienste und/oder sonstige ähnliche Dienste bereitstellen. Zusätzlich können die verschiedenen Dienste, die von dem/den Server(n) 150 bereitgestellt werden, das Initiieren und Steuern von Software- und/oder Firmwareupdates für Anwendungen oder einzelne Komponenten, die von den UEs 121 und den IoT-Vorrichtungen 111 implementiert werden, umfassen. Der/die Server 150 kann/können auch konfiguriert sein, um einen oder mehrere Kommunikationsdienste (z. B. VoIP-Sitzungen (Voice-over-Internet Protocol-Sitzungen), PTT-Sitzungen, Gruppenkommunikationssitzungen, Social-Networking-Dienste usw.) für die UEs 121 und die IoT-Vorrichtungen 111 über das CN 142 zu unterstützen.
• Die Cloud 144 kann einen Cloud-Computing-Dienst, das Internet, ein lokales Netzwerk (LAN, Local Area Network) oder ein Großraumnetzwerk (WAN, Wide Area Network) einschließlich proprietärer Netzwerke und/oder Firmennetzwerke für ein Unternehmen oder eine Organisation oder Kombinationen davon darstellen. Die Cloud 144 kann ein Netzwerk sein, das Computer, Netzwerkverbindungen unter den Computern und Softwareroutinen zum Ermöglichen von Kommunikation zwischen den Computern über Netzwerkverbindungen aufweist. Diesbezüglich weist die Cloud 144 ein oder mehrere Netzwerkelemente auf, die einen oder mehrere Prozessoren, Kommunikationssysteme (die z. B. Netzwerkschnittstellensteuerungen, einen oder mehrere Sender/Empfänger, die mit einer oder mehreren Antennen verbunden sind, usw.) und computerlesbare Medien aufweisen können. Beispiele für solche Netzwerkelemente können drahtlose Zugangspunkte (WAPs, Wireless Access Points), Heim-/Geschäftsserver (mit oder ohne HF-Kommunikationsschaltungsanordnung), Router, Schalter, Hubs, Funkbaken, Basisstationen, Pikozellen- oder Kleinzellenbasisstationen, Backbone-Gateways und/oder eine beliebige sonstige ähnliche Netzwerkvorrichtung umfassen. Die Verbindung mit der Cloud 144 kann über eine drahtgebundene oder eine drahtlose Verbindung unter Verwendung der verschiedenen weiter unten erläuterten Kommunikationsprotokolle erfolgen. Es können mehr als ein Netzwerk an einer Kommunikationssitzung zwischen den veranschaulichten Vorrichtungen beteiligt sein. Die Verbindung mit der Cloud 144 kann erfordern, dass die Computer Softwareroutinen ausführen, welche zum Beispiel die sieben Schichten des OSI-Modells der Computervernetzung oder eines Äquivalents in einem drahtlosen (zellulären) Mobilfunknetzwerk ermöglichen. Die Cloud 144 kann verwendet werden, um eine Kommunikation mit einer relativ großen Reichweite, wie zum Beispiel zwischen dem einen oder den mehreren Server(n) 150 und einem oder mehreren UEs 121 und IoT-Vorrichtungen 111, zu ermöglichen. In einigen Ausführungsformen kann die Cloud 144 das Internet, ein oder mehrere zelluläre Netzwerke, lokale Netzwerke oder Großraumnetzwerke einschließlich proprietärer Netzwerke und/oder Firmennetzwerke, ein übertragungssteuerungsprotokollbasiertes (TCPbasiertes)/internetprotokollbasiertes (IP-basiertes) Netzwerk oder Kombinationen davon darstellen. In solchen Ausführungsformen kann die Cloud 144 mit dem Netzwerkbetreiber verknüpft sein, der die Geräte und andere Elemente zum Bereitstellen von netzwerkbezogenen Diensten besitzt oder steuert, wie etwa eine oder mehrere Basisstationen oder Zugangspunkte, ein oder mehrere Server zum Leiten von digitalen Daten oder Telefonanrufen (z. B. ein Kernnetzwerk oder Backbone-Netzwerk) usw. Die Backbone-Verknüpfungen 155 können eine beliebige Anzahl an drahtgebundenen oder drahtlosen Technologien aufweisen und können Teil eines lokalen Netzwerks (LAN), eines Großraumnetzwerks (WAN) oder des Internets sein. In einem Beispiel sind die Backbone-Verknüpfungen 155 Faser-Backbone-Verknüpfungen, die untere Ebenen von Dienstanbietern mit dem Internet koppeln, wie etwa das CN 412 und die Cloud 144.
• In einigen Ausführungsformen können mindestens einige der Edge-Knoten 120 ein MEC-System 135 aufweisen oder Teil davon sein. Das MEC-System 135 weist eine Sammlung von MEC-Servern 136 (einschließlich des MEC-Servers 136a und des MEC-Servers 136b in 1) und MEC-Verwaltungssystemen (nicht durch 1 gezeigt) auf, die notwendig sind, um MEC-Anwendungen (z. B. die MEC-Apps 436 von 4) innerhalb eines Betreibernetzwerks oder einer Untergruppe eines Betreibernetzwerks auszuführen. Die MEC-Server 136a, 136b, 136c (gemeinsam als „die MEC-Server 136“ oder „der MEC-Server 136“ bezeichnet) sind physische Computersysteme (z. B. Server-Rechenknoten), die eine MEC-Plattform (z. B. die MEC-Plattform 437 von 4) und eine Virtualisierungsinfrastruktur (z. B. die VI 438 von 4) aufweisen und Rechen-, Speicher- und Netzwerkressourcen MEC-Anwendungen bereitstellen. Jeder der MEC-Server 136 ist an einem Rand eines entsprechenden Kommunikationsnetzwerks (oder Zugriffsnetzwerks) angeordnet und eingerichtet, um Rechenressourcen und/oder verschiedene Dienste (z. B. Rechenaufgaben-/ und oder Auslastungsabgabe, Cloud-Computing-Fähigkeiten, Informationstechnologiedienste (IT-Dienste) und sonstige ähnliche Ressourcen und/oder Dienste, wie hierin erläutert) in relativ nächster Nähe zu den Zwischenknoten 120 und/oder Endpunkten 110 bereitzustellen. Die MEC-Server 136 können auch als „MEC-Hosts 136“ oder „Edge-Server“ bezeichnet werden. Die VI der MEC-Server 136 stellen virtualisierte Umgebungen und virtualisierte Ressourcen (z. B. eine „virtualisierte Infrastruktur“) für die MEC-Hosts 136 bereit, und die MEC-Anwendungen können als virtuelle Maschinen (VMs) und/oder Anwendungscontainer auf der VI ausgeführt werden. Die Komponenten und/oder Entitäten des MEC-Systems 135 werden weiter unten unter Bezugnahme auf die 4 - 11 ausführlicher erläutert.
• Wie durch 1 gezeigt ist, liegen jeder der (R)AN-Knoten 131/132 und der AP 133 jeweils am selben Ort wie die MEC-Server 136a, 136b und 136c. Diese Implementierungen können Kleinzellenclouds (SCCs, Small-Cell Clouds) sein, wo ein MEC-Server 136 an derselben Stelle wie eine kleine Zelle (z. B. Pikozelle, Femtozelle usw.) liegt, oder mobile Mikroclouds (MCCs), wo ein MEC-Server 136 an derselben Stelle wie eine Mikrozelle (z. B. ein eNB, gNB usw.) liegt, sein. Die MEC-Server 136 können in einer Vielzahl an anderen Anordnungen als den durch 1 gezeigten eingesetzt werden. In einem ersten Beispiel können die MEC-Server 136 an derselben Stelle wie die RNCs liegen oder von diesen betrieben werden, was bei Einsätzen von älteren Netzwerken, wie etwa 3G-Netzwerken, der Fall sein kann. In einem zweiten Beispiel können die MEC-Server 136 an Zellenaggregationsorten oder an Mehrfach-RAT-Aggregationspunkten, die entweder innerhalb eines Unternehmens liegen können oder in öffentlichen Abdeckungsbereichen verwendet werden, eingesetzt werden. In einem dritten Beispiel können die MEC-Server 136 an dem Rand des CN 142 eingesetzt werden. Diese Implementierungen können in Follow-me-Clouds (FMC) verwendet werden, wo Cloud-Dienste, die an verteilten Datenzentren ausgeführt werden, den UEs 121 folgen, wenn sie durch das Netzwerk roamen.
• Gemäß verschiedenen Ausführungsformen kann die Aufgabenabgabe „opportunistisch“ sein, wobei das MEC-System 135 (oder ein konkreter MEC-Server 136, der als ein Master-Knoten in dem Beispiel von 1 ausgewählt ist) Anwendungsaufgaben an ein oder mehrere UEs 121 unter Berücksichtigung der Rechenkomplexität der Aufgaben und/oder der Menge von Rechen- und Netzwerk-/Signalisierungsressourcen, die bei den UEs 121/111 (oder den MEC-Servern 836) verfügbar sind, abladen kann. Zum Beispiel kann ein MEC-Server 136 eine gewisse Anzahl und/oder Art von Aufgaben basierend auf der Qualität oder Stärke der Verknüpfungen 103, 105 und/oder 107, der Stärke oder Qualität der Rechenressourcen, die bei den UEs 121 verfügbar sind, einer Menge an verfügbarem Speicher oder einer aktuellen Speicherverwendung der UEs 121 und/oder basierend auf anderen Betriebsparametern der UEs 121 (oder auf anderen von den UEs 121 erfahrenen Betriebsparametern) abladen. In einigen Ausführungsformen kann das MEC-System 135 (oder ein konkreter MEC-Server 136, der als ein Master-Knoten ausgewählt ist) einen oder mehrere MEC-Server 136 auswählen, an welche ein UE 121/111 Anwendungsaufgaben oder Auslastungen abgeben kann. In einigen Ausführungsformen kann eine Vorrichtungsanwendung oder Client-Anwendung, die in einem UE 121/111 ausgeführt wird, Anwendungsaufgaben an einen oder mehrere MEC-Server 136 abgeben. Für einige gekennzeichnete Aufgaben kann das MEC-System 135 (oder die Vorrichtungs-/Client-Anwendung an dem UE 121/111) die Abgabemöglichkeit (z. B. den „Tausch“) in Bezug auf verfügbare UEs 121/111 (oder den/die MEC-Server 136) auswerten, wobei in diesem Fall das MEC-System 135 Aufgaben an bestimmte UEs 121/111 (oder den/die MEC-Server 136) abgeben kann, die in der Lage sind, Ausgabedaten anhand der Durchführung ihrer jeweiligen Aufgaben wieder dem MEC-Server 136 (oder UE 121/111) in einem gewünschten Zeitraum bereitzustellen. Basierend auf den zuvor erläuterten Betriebsparametern kann ein Abgabetausch ausgewertet werden und können optimale oder beste Abgabemöglichkeiten basierend auf dem Tausch bestimmt werden.
• 2 veranschaulicht ein Beispiel einer Plattform 200 (auch als „System 200“, „Vorrichtung 200“, „Gerät 200“ oder dergleichen bezeichnet) gemäß verschiedenen Ausführungsformen. In Ausführungsformen kann die Plattform 200 zur Verwendung als Zwischenknoten 120 und/oder Endpunkte 110 von 1 und/oder ein beliebiges sonstiges Element/Vorrichtung, das/die hierin unter Bezug auf eine beliebige sonstige Figur erläutert ist, die hierin gezeigt und beschrieben ist, geeignet sein. Die Plattform 200 kann auch in einem Servercomputersystem oder einem anderen Element, einer anderen Vorrichtung oder einem anderen System, die hierin erläutert werden, oder als diese implementiert werden. Die Plattform 200 kann beliebige Kombinationen der Komponenten aufweisen, die in dem Beispiel gezeigt sind. Die Komponenten der Plattform 200 können als integrierte Schaltungen (ICs, Integrated Circuits), Teile davon, diskrete elektronische Vorrichtungen oder sonstige Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in der Computerplattform 200 angepasst sind, oder als Komponenten, die anderweitig innerhalb eines Rahmens eines größeren Systems aufgenommen sind, implementiert werden. Das Beispiel von 2 soll einen Überblick der Komponenten der Computerplattform 200 zeigen. Allerdings können einige der gezeigten Komponenten weggelassen werden, können zusätzliche Komponenten vorhanden sein und kann eine andere Anordnung der gezeigten Komponenten bei anderen Implementierungen erfolgen.
• Die Plattform 200 weist eine Prozessorschaltungsanordnung 202 auf. Die Prozessorschaltungsanordnung 202 weist eine Schaltungsanordnung, wie etwa einen oder mehrere Prozessorkerne und einen oder mehrere Cache-Speicher, Spannungsregler mit niedriger Abfallspannung (LDOs, Low Drop-Out Voltage Regulators), Unterbrechungssteuerungen, serielle Schnittstellen, wie etwa eine serielle periphere Schnittstelle (SPI, Serial Peripheral Interface), inter-integrierte Schaltung (I²C) oder eine universelle programmierbare serielle Schnittstellenschaltung, eine Echtzeituhr (RTC, Real Time Clock), Zeitgeber-Zähler einschließlich Intervall- und Überwachungszeitgebern, eine Universal-Eingabe-Ausgabe (IO, Input-Output), Speicherkartensteuerungen, wie etwa eine sichere digitale/Multi-Media-Karte(SD/MMC, Secure Digital/Multi-Media Card) oder ähnliches, universelle serielle Bus-Schnittstellen (USB-Schnittstellen), MIPI-Schnittstellen (Mobile Industry Processor Interface) und JTAG-Testzugangsanschlüsse (Joint Test Access Group) auf, ohne jedoch auf diese beschränkt zu sein. Bei einigen Implementierungen kann die Prozessorschaltungsanordnung 202 einen oder mehrere Hardwarebeschleuniger aufweisen, welche Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen (z. B. FPGA, ASIC usw.) oder dergleichen sein können. Der eine oder die mehreren Hardwarebeschleuniger können zum Beispiel Computer-Vision-, Machine-Learning- und/oder Deep-Learning-Beschleuniger umfassen. Bei einigen Implementierungen kann die Prozessorschaltungsanordnung 202 eine On-Chip-Speicherschaltungsanordnung aufweisen, welche einen beliebigen geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flash-Speicher, Festkörperspeicher und/oder eine beliebige sonstige Art von Speichervorrichtungstechnologie, wie etwa die hierin erläuterten, aufweisen kann.
• Der/die Prozessor(en) der Prozessorschaltungsanordnung 202 kann/können zum Beispiel einen oder mehrere Prozessorkerne (CPUs, Central Processing Units), einen oder mehrere Anwendungsprozessoren, eine oder mehrere Grafikverarbeitungseinheiten (GPUs, Graphics Processing Units), einen oder mehrere Prozessoren mit verringerter Befehlssatzberechnung (RISC, Reduced Instruction Set Computing), einen oder mehrere ARM-Prozessoren (Acorn RISC Machine processors), einen oder mehrere Prozessoren mit komplexer Befehlssatzberechnung (CISC, Complex Instruction Set Computing), einen oder mehrere digitale Signalprozessoren (DSP), ein oder mehrere FPGAs, eine oder mehrere PLDs, eine oder mehrere ASICs, einen oder mehrere Basisbandprozessoren, eine oder mehrere integrierte Funkfrequenzschaltungen (RFIC, Radio-Frequency Integrated Circuit), einen oder mehrere Mikroprozessoren oder Controller oder eine beliebige geeignete Kombination davon umfassen. Die Prozessoren (oder Kerne) der Prozessorschaltungsanordnung 202 können mit dem Speicher/der Ablage gekoppelt sein oder diese aufweisen und konfiguriert sein, um Anweisungen auszuführen, die in dem Speicher/der Ablage gespeichert sind, um verschiedenen Anwendungen oder Betriebssystemen zu ermöglichen, auf der Plattform 200 ausgeführt zu werden. In diesen Ausführungsformen sind die Prozessoren (oder Kerne) der Prozessorschaltungsanordnung 202 konfiguriert, um Anwendungssoftware zu betreiben, um einen spezifischen Dienst einem Nutzer der Plattform 200 bereitzustellen. In einigen Ausführungsformen kann die Prozessorschaltungsanordnung 202 ein Sonderzweckprozessor/-controller sein, um gemäß den verschiedenen Ausführungsformen hierin zu agieren.
• Als Beispiele kann die Prozessorschaltungsanordnung 202 einen Intel® Architecture Core™-basierten Prozessor, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, oder einen MCU-Klasse-Prozessor, (einen) Pentium®-Prozessor(en), (einen) Xeon®-Prozessor(en) oder einen anderen derartigen Prozessor, der bei Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, aufweisen. Es kann jedoch eine beliebige Anzahl an sonstigen Prozessoren verwendet werden, wie etwa einer oder mehrere von Advanced Micro Devices (AMD) Zen® Core Architecture, wie etwa Ryzen®- oder EPYC®-Prozessor(en), beschleunigte Verarbeitungseinheiten (APUs, Accelerated Processing Units), MxGPUs, Epyc®-Prozessor(en), oder dergleichen; A5-A12- und/oder S1-S4-Prozessor(en) von Apple® Inc., Snapdragon™- oder Centriq™-Prozessor(en) von Qualcomm® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™-Processor(en); ein MIPS-basiertes Design von MIPS Technologies, Inc., wie etwa MIPS Warrior M-Klasse-, Warrior I-Klasse- und Warrior P-Klasse-Prozessoren; ein ARM-basiertes Design, das von ARM Holdings, Ltd. lizenziert ist, wie etwa die ARM Cortex-A-, Cortex-R- und Cortex-M-Familie der Prozessoren; der ThunderX2®, der von Cavium™, Inc. bereitgestellt wird; oder dergleichen. Bei einigen Implementierungen kann die Prozessorschaltungsanordnung 202 ein Teil eines Systems auf einem Chip (SoC, System on a Chip), System-in-Package (SiP), eines Mehrfach-Chip-Package (MCP) und/oder dergleichen sein, wo die Prozessorschaltungsanordnung 202 und sonstige Komponenten zu einer einzelnen integrierten Schaltung oder einem einzelnen Package, wie etwa den Edison™- oder Galileo™-SoC-Boards von der Intel® Corporation, gebildet sind. Andere Beispiele der Prozessorschaltungsanordnung 202 werden an einer anderen Stelle in der vorliegenden Offenbarung erwähnt.
• Zusätzlich oder alternativ kann die Prozessorschaltungsanordnung 202 eine Schaltungsanordnung, wie etwa eine oder mehrere FPDs, wie etwa FPGAs und dergleichen; PLDs, wie etwa CPLDs, HCPLDs, und dergleichen; ASICs, wie etwa strukturierte ASICs und dergleichen; PSoCs; und dergleichen, ohne jedoch darauf beschränkt zu sein, aufweisen. In solchen Ausführungsformen kann die Schaltungsanordnung der Prozessorschaltungsanordnung 202 Logikblöcke oder ein Logikfabric einschließlich anderer verschalteter Ressourcen, die programmiert werden können, um verschiedene Funktionen, wie etwa die Verfahren, Methoden, Funktionen usw. der verschiedenen hierin erläuterten Ausführungsformen durchzuführen, aufweisen. In solchen Ausführungsformen kann die Schaltungsanordnung der Prozessorschaltungsanordnung 202 Speicherzellen (z. B. EPROM, EEPROM, Flash-Speicher, statischer Speicher (z. B. SRAM, Antischmelzsicherungen usw.) aufweisen, die verwendet werden, um Logik-Blöcke, Logik-Fabric, Daten usw. in LUTs und dergleichen zu speichern.
• Die Prozessorschaltungsanordnung 202 kann mit der Systemspeicherschaltungsanordnung 204 über eine Verschaltung 206 (z. B. einen Bus) kommunizieren. Es kann eine beliebige Anzahl an Speichervorrichtungen verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann die Speicherschaltungsanordnung 204 ein Direktzugriffsspeicher (RAM, Random Access Memory) gemäß einem Joint Electron Devices Engineering Council-Design (JEDEC-Design), wie etwa den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3, oder LPDDR4), dynamischer RAM (DRAM) und/oder synchroner DRAM (SDRAM)) sein. Die Speicherschaltungsanordnung 204 kann auch einen nichtflüchtigen Speicher (NVM, Non-Volatile Memory), wie etwa einen elektrisch löschbaren Hochgeschwindigkeitsspeicher (üblicherweise als „Flash-Speicher“ bezeichnet), einen Phasenwechsel-RAM (PRAM), einen resistiven Speicher, wie etwa einen magnetoresistiven Direktzugriffsspeicher (MRAM), usw. aufweisen und kann dreidimensionale Kreuzpunktspeicher (3D XPOINT-Speicher) von Intel® und Micron® enthalten. Die Speicherschaltungsanordnung 204 kann auch Dauerspeichervorrichtungen aufweisen, welche ein temporärer und/oder dauerhafter Speicher einer beliebigen Art sein können, einschließlich eines nichtflüchtigen Speichers, eines optischen, magnetischen und/oder Festkörpermassenspeichers, und so weiter, ohne jedoch auf diese beschränkt zu sein.
• Die einzelnen Speichervorrichtungen der Speicherschaltungsanordnung 204 können als eine oder mehrere von gepackten integrierten Solder-Down-Schaltungen, gesockelten Speichermodulen und Plug-in-Speicherkarten implementiert sein. Die Speicherschaltungsanordnung 204 kann als eine beliebige Anzahl an unterschiedlichen Package-Arten, wie etwa ein einzelnes Die-Package (SDP, Single Die Package), ein duales Die-Package (DDP) oder ein Quad-Die-Package (Q17P), implementiert werden. Diese Vorrichtungen können in einigen Beispielen direkt auf ein Motherboard gelötet werden, um eine Lösung mit geringerem Profil bereitzustellen, während in anderen Beispielen die Vorrichtungen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum mit dem Motherboard durch einen gegebenen Stecker gekoppelt sind. Es kann eine beliebige Anzahl an anderen Speicherimplementierungen verwendet werden, wie etwa andere Arten von Speichermodulen, z. B. duale Inline-Speichermodule (DIMMs, Dual Inline Memory Modules) von verschiedenen Varianten einschließlich microDIMMs oder MiniDIMMs, ohne jedoch auf diese beschränkt zu sein. Speicherschaltungsanordnung 204. In Ausführungsformen kann die Speicherschaltungsanordnung 204 in oder auf einem selben Die oder Package wie die Prozessorschaltungsanordnung 202 angeordnet sein (z. B. einem selben SoC, einem selben SiP, oder auf einem selben MCP wie die Prozessorschaltungsanordnung 202 gelötet sein).
• Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssysteme (OS, Operating Systems) und so weiter bereitzustellen, kann eine Ablageschaltungsanordnung 208 auch mit der Prozessorschaltungsanordnung 202 über das Interconnect 206 gekoppelt sein. In einem Beispiel kann die Ablageschaltungsanordnung 208 über ein Solid-State-Laufwerk (SSDD, Solid-State Disk Drive) implementiert werden. Andere Vorrichtungen, die für die Ablageschaltungsanordnung 208 verwendet werden können, umfassen Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, xD-Bildkarten und dergleichen und USB-Flash-Laufwerke. Bei Implementierungen mit geringer Leistung kann die Ablageschaltungsanordnung 208 ein On-Die-Speicher oder Register, die mit der Prozessorschaltungsanordnung 202 verknüpft sind, sein. In einigen Beispielen kann jedoch die Ablageschaltungsanordnung 208 unter Verwendung einer Mikrofestplatte (Mikro-HDD) implementiert werden. Ferner kann eine beliebige Anzahl an neuen Technologien für die Ablageschaltungsanordnung 208 zusätzlich zu den beschriebenen Technologien, oder anstelle von diesen, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher, verwendet werden.
• Die Ablageschaltungsanordnung 208 speichert die Rechenlogik 283 (oder „-module 283“) in Form von Software-, Firmware- oder Hardwarebefehlen zum Implementieren der hierin beschriebenen Techniken. Die Rechenlogik 283 kann eingesetzt werden, um Arbeitskopien und/oder permanente Kopien von Computerprogrammen oder Daten zum Erstellen der Computerprogramme zum Betreiben von verschiedenen Komponenten der Plattform 200 (z. B. Treiber usw.), eines Betriebssystems der Plattform 200, einer oder mehrerer Anwendungen und/oder zum Ausführen der hierin erläuterten Ausführungsformen zu speichern. Die Rechenlogik 283 kann in der Speicherschaltungsanordnung 204 als Anweisungen 282 oder Daten zum Erstellen der Anweisungen 282 zum Ausführen durch die Prozessorschaltungsanordnung 202 zum Bereitstellen der hierin beschriebenen Funktionen gespeichert oder in diese geladen werden. Die verschiedenen Elemente können durch Assembler-Anweisungen, die von der Prozessorschaltungsanordnung 202 unterstützt werden, oder Hochebenensprachen, die zu solchen Anweisungen (z. B. den Anweisungen 270, oder Daten zum Erstellen der Anweisungen 270) kompiliert werden können, implementiert werden. Die permanente Kopie der Programmieranweisungen kann in die dauerhaften Speichervorrichtungen der Ablageschaltungsanordnung 208 in der Fabrik oder auf dem Feld, zum Beispiel durch ein Verteilungsmedium (nicht gezeigt), durch eine Kommunikationsschnittstelle (z. B. von einem Verteilungsserver (nicht gezeigt)) oder über die Luft (OTA, Over-the-Air), platziert werden.
• Die Anweisungen 282 und/oder Module 283 (auch als „Programmcode“ oder „Programmieranweisungen“ bezeichnet), die über die Speicherschaltungsanordnung 204 und/oder die Ablageschaltungsanordnung 208 von 2 bereitgestellt werden, sind als ein oder mehrere nicht-flüchtige computerlesbare Speichermedien (NTCRSM, Non-Transistory Computer Readable Storage Media) 260 einschließlich Programmcode, eines Computerprogrammprodukts oder Daten zum Erstellen des Computerprogramms, mit dem Computerprogramm oder Daten zum Ausrichten der Prozessorschaltungsanordnung 202 der Plattform 200 zum Durchführen von elektronischen Operationen in der Plattform 200 und/oder zum Durchführen einer spezifischen Sequenz oder eines spezifischen Flusses von Aktionen, wie zum Beispiel unter Bezugnahme auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme der Operationen und der Funktionalität, die durch die 1 und 4 - 13 dargestellt sind, ausgeführt.
• In einigen Ausführungsformen können die auszuführenden Programmieranweisungen (oder Daten zum Erstellen der Programmieranweisungen) in einer vorab konfigurierten Form vorliegen, die Konfigurationsanweisungen zum Installieren oder Bereitstellen der Programmieranweisungen für eine Vorrichtung (wie etwa einer der hierin beschriebenen Vorrichtungen/Komponenten/Systeme) erfordern kann. Wenn sie installiert/bereitgestellt, konfiguriert und ausgeführt sind, können die Programmieranweisungen verschiedene Programmieroperationen in Verbindung mit Betriebssystemfunktionen, einer oder mehreren Anwendungen und/oder Aspekten der vorliegenden Offenbarung (einschließlich verschiedener Programmieroperationen in Verbindung mit den 1 und 4 - 13) abschließen oder durchführen.
• In alternativen Ausführungsformen können Programmieranweisungen (oder Daten zum Erstellen der Anweisungen) auf mehreren NTCRSM 260 angeordnet sein. In alternativen Ausführungsformen können Programmieranweisungen (oder Daten zum Erstellen der Anweisungen) auf computerlesbaren flüchtigen Speichermedien, wie etwa Signalen, angeordnet werden. Die Anweisungen, die von einem maschinenlesbaren Medium ausgeführt werden, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung, die ein beliebiges einer Anzahl an Übertragungsprotokollen (z. B. HTTP) verwendet, gesendet oder empfangen werden. Es kann eine beliebige Kombination von einem oder mehreren von einem Computer verwendbaren oder computerlesbaren Medium/Medien verwendet werden. Das von einem Computer verwendbare oder computerlesbare Medium kann zum Beispiel ein oder mehrere elektronische, magnetische, optische, elektromagnetische, Infrarot- oder Halbleitersysteme, -vorrichtungen, -geräte oder -verbreitungsmedien sein, ohne jedoch auf diese beschränkt zu sein. Zum Beispiel können die NTCRSM 260 von Vorrichtungen ausgeführt werden, die für die Ablageschaltungsanordnung 208 und/oder die Speicherschaltungsanordnung 204 beschrieben sind. Mehr spezifische Beispiele (eine nicht-abschließende Liste) eines computerlesbaren Mediums würden Folgendes umfassen: eine elektrische Verbindung, die einen oder mehrere Drähte aufweist, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM, Random Access Memory), einen Nur-Lese-Speicher (ROM, Read-Only Memory), einen löschbaren programmierbaren Nurlesespeicher (EPROM (Erasable Programmable Read-Only-Memory), Flash-Speicher usw.), eine Glasfaser, einen tragbaren Compact Disk-Nur-Lese-Speicher (CD-ROM (Compact Disk Read-Only Memory)), eine optische Speichervorrichtung und/oder optische Platten, ein Übertragungsmedium, wie etwa jene, die das Internet oder ein Intranet unterstützen, eine Magnetspeichervorrichtung oder eine beliebige Anzahl an sonstigen Hardwarevorrichtungen. Es sei darauf hingewiesen, dass das von einem Computer verwendbare oder computerlesbare Medium sogar Papier oder ein anderes geeignetes Medium sein könnte, auf welchem das Programm (oder Daten zum Erstellen des Programms) gedruckt wird, da das Programm (oder Daten zum Erstellen des Programms) elektronisch über zum Beispiel optisches Abtasten des Papiers oder eines anderen Mediums erfasst, dann kompiliert, interpretiert oder anderweitig auf eine geeignete Art verarbeitet werden kann, falls nötig, und dann in einem Computerspeicher (wobei es in einem oder mehreren Zwischenspeichermedien zwischengespeichert worden ist oder nicht) gespeichert werden kann. Im Kontext dieses Dokuments kann ein von einem Computer verwendbares oder computerlesbares Medium ein beliebiges Medium sein, das das Programm (oder Daten zum Erstellen des Programms) zur Verwendung von oder in Verbindung mit dem Anweisungsausführungssystem, -vorrichtung oder -gerät enthalten, speichern, kommunizieren, verbreiten oder transportieren kann. Das von einem Computer verwendbare Medium kann ein verbreitetes Datensignal, mit dem der von einem Computer verwendbare Programmcode (oder Daten zum Erstellen des Programmcodes) ausgeführt ist, entweder in einem Basisband oder als Teil einer Trägerwelle aufweisen. Der von einem Computer verwendbare Programmcode (oder Daten zum Erstellen des Programms) kann unter Verwendung eines beliebigen geeigneten Mediums, einschließlich drahtlos, drahtgebunden, Glasfaserkabel, HF usw., ohne jedoch darauf beschränkt zu sein, übertragen werden.
• In verschiedenen Ausführungsformen kann der Programmcode (oder Daten zum Erstellen des Programmcodes), der hierin beschrieben ist, in einem oder mehreren eines komprimierten Formats, eines verschlüsselten Formats, eines fragmentierten Formats, eines gepackten Formats usw. gespeichert werden. Programmcode (oder Daten zum Erstellen des Programmcodes), wie er hierin beschrieben ist, kann eine oder mehrere einer Installation, Modifikation, Anpassung, Aktualisierung, Kombinierung, Ergänzung, Konfigurierung, Entschlüsselung, Dekomprimierung, Entpackung, Verteilung, Neuzuweisung usw. erfordern, um ihn direkt durch eine Rechenvorrichtung und/oder sonstige Maschine lesbar und/oder ausführbar zu machen. Zum Beispiel kann der Programmcode (oder Daten zum Erstellen des Programmcodes) in mehreren Teilen gespeichert werden, welche einzeln komprimiert, verschlüsselt und auf separaten Rechenvorrichtungen gespeichert werden, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz von ausführbaren Anweisungen bilden, die den Programmcode (die Daten zum Erstellen des Programmcodes, wie etwa den hierin beschriebenen) implementieren. In einem anderen Beispiel kann der Programmcode (oder Daten zum Erstellen des Programmcodes) in einem Zustand gespeichert werden, in welchem er von einem Computer gelesen werden kann, jedoch das Hinzufügen einer Bibliothek (z. B. einer dynamisch gelinkten Bibliothek), eines Software-Entwicklungskits (SDK, Software Development Kit), einer Anwendungsprogrammierschnittstelle (API, Application Programming Interface), usw. erfordert, um die Anweisungen auf einer konkreten Rechenvorrichtung oder einer sonstigen Vorrichtung auszuführen. In einem anderen Beispiel muss der Programmcode (oder die Daten zum Erstellen des Programmcodes) möglicherweise konfiguriert werden (z. B. gespeicherte Einstellungen, Dateneingabe, aufgezeichnete Netzwerkadressen usw.), bevor der Programmcode (oder die Daten zum Erstellen des Programmcodes) ganz oder zum Teil ausgeführt/verwendet werden können. In diesem Beispiel kann der Programmcode (oder die Daten zum Erstellen des Programmcodes) entpackt, zur geeigneten Ausführung konfiguriert und an einem ersten Ort gespeichert werden, wobei sich die Konfigurationsanweisungen, die sich an einem zweiten Ort befinden, von dem ersten Ort unterscheiden. Die Konfigurationsanweisungen können durch eine Aktion, Auslösung oder Anweisung initiiert werden, die nicht an derselben Stelle an dem Speicher- oder Ausführungsort liegt, wobei die Anweisungen die offenbarten Techniken ermöglichen. Dementsprechend soll der offenbarte Programmcode (oder Daten zum Erstellen des Programmcodes) solche maschinenlesbaren Anweisungen und/oder (ein) Programm(e) (oder Daten zum Erstellen solcher maschinenlesbarer Anweisungen und/oder Programme) unabhängig von dem konkreten Format oder Zustand der maschinenlesbaren Anweisungen und/oder Programm(e) umfassen, wenn er gespeichert wird oder anderweitig ruht oder sich auf dem Transportweg befindet.
• Der Computerprogrammcode zum Ausführen der Operationen der vorliegenden Offenbarung (z. B. die Rechenlogik 283, die Anweisungen 282, 270, die zuvor erläutert wurden) kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen einschließlich einer objektorientierten Programmiersprache, wie etwa Python, Ruby, Scala, Smalltalk, Java™, C++, C# oder dergleichen; einer prozeduralen Programmiersprache, wie etwa der „C“-Programmiersprache, der Go-Programmiersprache (oder „Golang“-Programmiersprache) oder dergleichen; einer Skriptsprache, wie etwa JavaScript, Server-Side JavaScript (SSJS), JQuery, PHP, Pearl, Python, Ruby on Rails, Accelerated Mobile Pages Script (AMPscript), Mustache Template Language, Handlebars Template Language, Guide Template Language (GTL), PHP, Java und/oder Java Server Pages (JSP), Node.js, ASP.NET und/oder dergleichen; einer Markup-Sprache, wie etwa Hypertext Markup Language (HTML), Extensible Markup Language (XML), Java Script Object Notion (JSON), Apex®, Cascading Stylesheets (CSS), JavaServer Pages (JSP), MessagePack™, Apache® Thrift, Abstract Syntax Notation One (ASN. 1), Google® Protocol Buffers (protobuf) oder dergleichen; anderer geeigneter Programmiersprachen einschließlich proprietärer Programmiersprachen und/oder Entwicklungstools, oder beliebiger sonstiger Sprachtools geschrieben sein. Der Computerprogrammcode zum Ausführen von Operationen der vorliegenden Offenbarung kann auch in einer beliebigen Kombination der hierin erläuterten Programmiersprachen geschrieben werden. Der Programmcode kann ganz auf dem System 200 ausgeführt werden, teilweise auf dem System 200 ausgeführt werden, als ein alleinstehendes Softwarepackage ausgeführt werden, teilweise auf dem System 200 und teilweise auf einem entfernten Computer oder ganz auf dem entfernten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernte Computer durch eine beliebige Art von Netzwerk, einschließlich eines LAN oder WAN, mit dem System 200 verbunden sein oder kann die Verbindung zu einem externen Computer (z. B. durch das Internet unter Verwendung eines Internet Service Providers) hergestellt werden.
• In einem Beispiel können die Anweisungen 270 auf der Prozessorschaltungsanordnung 202 (separat oder in Kombination mit den Anweisungen 282 und/oder der Logik/den Modulen 283, die in computerlesbaren Speichermedien gespeichert sind) die Ausführung oder den Betrieb einer vertrauenswürdigen Ausführungsumgebung (TEE, Trusted Execution Environment) 290 konfigurieren. Die TEE 290 funktioniert als ein geschützter Bereich, auf den die Prozessorschaltungsanordnung 202 zugreifen kann, um einen sicheren Zugriff auf Daten und eine sichere Ausführung von Anweisungen zu ermöglichen. In einigen Ausführungsformen kann die TEE 290 eine physische Hardwarevorrichtung sein, die separat von anderen Komponenten des Systems 200, wie etwa einer sicheren eingebetteten Steuerung, eines dedizierten SoC oder eines manipulationssicheren Chipsatzes oder Mikrocontrollers mit eingebetteten Verarbeitungsvorrichtungen und Speichervorrichtungen, ist. In anderen Ausführungsformen kann die TEE 290 als sichere Enklaven implementiert werden, welche isolierte Regionen von Code und/oder Daten innerhalb des Speichers des Systems 200 sind. Nur Code, der innerhalb einer sicheren Enklave eingebettet ist, kann auf Daten innerhalb derselben sicheren Enklave zugreifen, und die sichere Enklave kann nur unter Verwendung der sicheren Anwendung (welche von einem Anwendungsprozessor oder einem manipulationssicheren Mikrocontroller implementiert werden kann) zugänglich sein. Es können verschiedene Implementierungen der TEE 290 und ein begleitender sicherer Bereich in der Prozessorschaltungsanordnung 202 oder der Speicherschaltungsanordnung 204 und/oder der Ablageschaltungsanordnung 208 bereitgestellt werden, zum Beispiel durch die Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone®-Hardware-Sicherheitserweiterungen; einer Desktop and mobile Architecture Hardware (DASH) entsprechenden Netzwerkschnittstellenkarte (NIC, Network Interface Card), Intel® Management/Manageability Engine, Intel® Converged Security Engine (CSE) oder einer Converged Security Management/Manageability Engine (CSME), Trusted Execution Engine (TXE), die von Intel® bereitgestellt wird, welche jeweils in Verbindung mit Intel® Active Management Technology (AMT) und/oder Intel® vPro™-Technologie arbeiten können; AMD® Platform Security coProcessor (PSP), einer beschleunigten Verarbeitungseinheit (APU, Accelerated Processing Unit) der AMD® PRO A-Series mit DASH-Verwaltbarkeit, den kyptografischen Coprozessoren IBM® Crypto Express3®, IBM® 4807, 4808, 4809, und/oder 4765, dem IBM® Baseboard Management Controller (BMC) mit intelligenter Plattformverwaltungsschnittstelle (IPMI, Intelligent Platform Management Interface), Dell™ Remote Assistant Card II (DRAC II), integrierter Dell™ Remote Assistant Card (iDRAC) und dergleichen. Andere Aspekte der Sicherheitsverstärkung, Hardware-Vertrauensanker und vertrauenswürdiger oder geschützter Operationen können in der Vorrichtung 200 durch die TEE 290 und die Prozessorschaltungsanordnung 202 implementiert werden.
• Wenngleich die Anweisungen 282 als Codeblöcke gezeigt sind, die in der Speicherschaltungsanordnung 204 enthalten sind, und die Rechenlogik 283 als Codeblöcke in der Ablageschaltungsanordnung 208 gezeigt sind, versteht sich, dass ein beliebiger der Codeblöcke durch hartverdrahtete Schaltungen ersetzt werden kann, die zum Beispiel in eine FPGA, ASIC oder eine andere geeignete Schaltungsanordnung eingebaut sind. Wenn zum Beispiel die Prozessorschaltungsanordnung 202 (z. B. FPGA-basierte) Hardwarebeschleuniger sowie Prozessorkerne aufweist, können die Hardwarebeschleuniger (z. B. die FPGA-Zellen) vorab mit der zuvor genannten Rechenlogik zum Durchführen einiger oder aller der zuvor erläuterten Funktionen (anstelle des Einsatzes von Programmieranweisungen, die von dem/den Prozessorkern(en) auszuführen sind) konfiguriert werden (z. B. mit geeigneten Bit-Strömen).
• Die Speicherschaltungsanordnung 204 und/oder die Ablageschaltungsanordnung 208 können Programmcode eines Betriebssystems (OS) speichern, welches ein Universal-OS oder ein OS, das spezifisch für die Rechenplattform 200 geschrieben und maßgeschneidert ist, sein kann. Zum Beispiel kann das OS Unix oder ein Unixartiges OS, wie etwa Linux, das von Red Hat Enterprise bereitgestellt wird, Windows 10™, das von Microsoft Corp.® bereitgestellt wird, macOS, das von Apple Inc.® bereitgestellt wird, oder dergleichen sein. In einem anderen Beispiel kann das OS ein mobiles OS, wie etwa Android®, das von Google Inc.® bereitgestellt wird, iOS®, das von Apple Inc.® bereitgestellt wird, Windows 10 Mobile®, das von Microsoft Corp.® bereitgestellt wird, KaiOS, das von KaiOS Technologies Inc. bereitgestellt wird, oder dergleichen sein. In einem anderen Beispiel kann das OS ein Echtzeit-OS (RTOS, Real-Time OS), wie etwa Apache Mynewt, das von der Apache Software Foundation® bereitgestellt wird, Windows 10 For IoT®, das von der Microsoft Corp.® bereitgestellt wird, Micro-Controller Operating Systems („MicroC/OS“ oder „µC/OS“), die von Micrium®, Inc. bereitgestellt werden, FreeRTOS, VxWorks®, das von Wind River Systems, Inc.® bereitgestellt wird, PikeOS, das von Sysgo AG® bereitgestellt wird, Android Things®, das von Google Inc.® bereitgestellt wird, QNX® RTOS, das von BlackBerry Ltd. bereitgestellt wird, oder irgendein sonstiges geeignetes RTOS, wie etwa die hierin offenbarten, sein.
• Das OS kann einen oder mehrere Treiber aufweisen, die betrieben werden, um konkrete Vorrichtungen zu steuern, die in der Plattform 200 eingebettet sind, mit der Plattform 200 verbunden sind oder anderweitig kommunikativ mit der Plattform 200 gekoppelt sind. Die Treiber können individuelle Treiber umfassen, die anderen Komponenten der Plattform 200 ermöglichen, mit verschiedenen E/A-Vorrichtungen, die innerhalb der Plattform 200 vorhanden oder mit dieser verbunden sein können, zu interagieren oder diese zu steuern. Zum Beispiel können die Treiber einen Display-Treiber zum Steuern und Erlauben von Zugriff auf eine Anzeigevorrichtung, einen Touchscreen-Treiber zum Steuern und Erlauben von Zugriff auf eine Touchscreen-Schnittstelle der Plattform 200, Sensortreiber zum Erhalten von Sensorwerten der Sensorschaltungsanordnung 221 und Steuern und Erlauben von Zugriff auf die Sensorschaltungsanordnung 221, Aktortreiber zum Erhalten von Aktorpositionen der Aktoren 222 und/oder Steuern und Erlauben von Zugriff auf die Aktoren 222, einen Kameratreiber zum Steuern und Erlauben von Zugriff auf eine eingebettete Bildaufnahmevorrichtung, Audio-Treiber zum Steuern und Erlauben von Zugriff auf eine oder mehrere Audio-Vorrichtungen umfassen. Die OSs können auch eine oder mehrere Bibliotheken, Treiber, APIs, Firmware, Middleware, Softwareklebstoff usw. aufweisen, welche Programmcode und/oder Softwarekomponenten für eine oder mehrere Anwendungen bereitstellen, um die Daten von der TEE 290 zu erhalten und zu verwenden.
• Die Komponenten können über das Interconnect 206 kommunizieren. Das Interconnect 206 kann eine beliebige Anzahl an Technologien einschließlich der Industriestandardarchitektur (ISA), der erweiterten ISA (EISA, Extended ISA), periphere Komponentenverschaltung (PCI, Peripheral Componente Interconnect), erweiterte periphere Komponentenverschaltung (PCIx, Peripheral Component Interconnect extended), PCI express (PCIe), oder eine beliebige Anzahl an sonstigen Technologien aufweisen. Das Interconnect 206 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird. Es können andere Bussysteme enthalten sein, wie etwa unter anderem eine I²C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
• Das Interconnect 206 koppelt die Prozessorschaltungsanordnung 202 mit der Kommunikationsschaltungsanordnung 209 zur Kommunikation mit anderen Vorrichtungen. Die Kommunikationsschaltungsanordnung 209 ist ein Hardwareelement oder eine Sammlung von Hardwareelementen, die verwendet werden, um über ein oder mehrere Netzwerke (z. B. die Cloud 201) und/oder mit anderen Vorrichtungen (z. B. die Mesh-Vorrichtungen/der Fog 264) zu kommunizieren. Die Kommunikationsschaltungsanordnung 209 weist die Basisbandschaltungsanordnung 210 (oder das „Modem 210“) und die Hochfrequenzschaltungsanordnung (HF-Schaltungsanordnung) 211 und 212 auf.
• Die Basisbandschaltungsanordnung 210 weist eine oder mehrere Verarbeitungsvorrichtungen (z. B. Basisbandprozessoren) auf, um verschiedene Protokoll- und Funksteuerfunktionen auszuführen. Die Basisbandschaltungsanordnung 210 kann sich mit der Anwendungsschaltungsanordnung der Plattform 200 (z. B. einer Kombination der Prozessorschaltungsanordnung 202, der Speicherschaltungsanordnung 204 und/oder der Ablageschaltungsanordnung 208) zum Erzeugen und Verarbeiten von Basisbandsignalen und zum Steuern von Operationen der HF-Schaltungsanordnung 211 oder 212 verbinden. Die Basisbandschaltungsanordnung 210 kann verschiedene Funksteuerfunktionen handhaben, die die Kommunikation mit einem oder mehreren Funknetzwerken über die HF-Schaltungsanordnung 211 oder 212 ermöglichen. Die Basisbandschaltungsanordnung 210 kann eine Schaltungsanordnung, wie etwa einen oder mehrere Einzelkern- oder Mehrkernprozessoren (z. B. ein oder mehrere Basisbandprozessoren) oder eine Steuerlogik zum Verarbeiten von Basisbandsignalen, die von einem Empfangssignalpfad der HF-Schaltungsanordnung 211 und/oder 212 empfangen werden, und zum Erzeugen von Basisbandsignalen, die der HF-Schaltungsanordnung 211 oder 212 über einen Übertragungssignalpfad bereitzustellen sind, aufweisen, ohne jedoch auf diese beschränkt zu sein. In verschiedenen Ausführungsformen kann die Basisbandschaltungsanordnung 210 ein Echtzeit-OS (RTOS) implementieren, um Ressourcen der Basisbandschaltungsanordnung 210 zu verwalten, Aufgaben zu planen usw. Beispiele des RTOS können Operating System Embedded (OSE)™, das von Enea® bereitgestellt wird, Nucleus RTOS™ , das von Mentor Graphics® bereitgestellt wird, Versatile Real-Time Executive (VRTX), das von Mentor Graphics® bereitgestellt wird, ThreadX™, das von Express Logic® bereitgestellt wird, FreeRTOS, REX OS, das von Qualcomm® bereitgestellt wird, OKL4, das von Open Kernel (OK) Labs® bereitgestellt wird, oder irgendein sonstiges geeignetes RTOS, wie etwa die hierin erläuterten, umfassen.
• Wenngleich es nicht durch 2 gezeigt ist, weist in einer Ausführungsform die Basisbandschaltungsanordnung 210 (eine) einzelne Verarbeitungsvorrichtung(en) zum Betreiben eines oder mehrerer Drahtloskommunikationsprotokolle (z. B. ein „Mehrfachprotokoll-Basisbandprozessor“ oder eine „Protokollverarbeitungsschaltungsanordnung“) und (eine) einzelne Verarbeitungsvorrichtung(en) zum Implementieren von PHY-Funktionen auf. In dieser Ausführungsform betreibt oder implementiert die Protokollverarbeitungsschaltungsanordnung verschiedene Protokollschichten/- entitäten von einem oder mehreren Drahtloskommunikationsprotokollen. In einem ersten Beispiel kann die Protokollverarbeitungsschaltungsanordnung LTE-Protokollentitäten und/oder 5G/NR-Protokollentitäten betreiben, wenn die Kommunikationsschaltungsanordnung 209 ein zelluläres Funkfrequenzkommunikationssystem, wie etwa eine Millimeterwellenkommunikationsschaltungsanordnung (mmWave-Kommunikationsschaltungsanordnung) oder eine andere geeignete zelluläre Kommunikationsschaltungsanordnung, ist. In dem ersten Beispiel würde die Protokollverarbeitungsschaltungsanordnung 202 MAC-, RLC-, PDCP-, SDAP-, RRC- und NAS-Funktionen betreiben. In einem zweiten Beispiel kann die Protokollverarbeitungsschaltungsanordnung ein oder mehrere IEEE-basierte Protokolle betreiben, wenn die Kommunikationsschaltungsanordnung 209 ein WiFi-Kommunikationssystem ist. In dem zweiten Beispiel würde die Protokollverarbeitungsschaltungsanordnung WiFi MAC- und LLC-Funktionen betreiben. Die Protokollverarbeitungsschaltungsanordnung kann eine oder mehrere Speicherstrukturen (nicht gezeigt) aufweisen, um Programmcode und Daten zum Betreiben der Protokollfunktionen sowie einen oder mehrere Verarbeitungskerne (nicht gezeigt) zum Ausführen des Programmcodes und Durchführen verschiedener Operationen unter Verwendung der Daten aufweisen. Die Protokollverarbeitungsschaltungsanordnung stellt Steuerfunktionen für die Basisbandschaltungsanordnung 210 und/oder die HF-Schaltungsanordnung 211 und 212 bereit. Die Basisbandschaltungsanordnung 210 kann auch Funkkommunikationen für mehr als ein Drahtlosprotokoll unterstützen.
• Mit der zuvor genannten Ausführungsform fortfahrend weist die Basisbandschaltungsanordnung 210 (eine) einzelne Verarbeitungsvorrichtung(en) zum Implementieren von PHY- einschließlich HARQ-Funktionen, Verschlüsseln und/oder Entschlüsseln, Codieren und/oder Decodieren, Schicht-Mapping und/oder -Demapping, Modulationssymbolmapping, Bestimmung von erhaltenem Symbol und/oder Bitmetrik, Mehrfachantennenanschlussvorcodierung und/oder - decodierung, welche eine oder mehrere von Zeit-Raum-, Zeit-Frequenz- oder räumliche Codierung umfassen kann, Referenzsignalerzeugung und/oder - erfassung, Präambelsequenzerzeugung und/oder -decodierung, Synchronisierungssequenzerzeugung und/oder -erfassung, Steuerkanalsignalblinddecodierung, Funkfrequenzverschiebung und sonstige diesbezügliche Funktionen usw. auf. Die Modulations-/Demodulationsfunktionalität kann die Fast-Fourier-Transformation (FFT), Vorcodierung oder Konstellationsmapping-/-demappingfunktionalität umfassen. Die Codierungs-/Decodierungsfunktionalität kann Faltung, Tail-Biting-Faltung, Turbocodierung, Viterbi-Codierung oder Low Density Parity Check-Codierung (LDPC-Codierung) umfassen. Die Ausführungsformen der Modulierung/Demodulierung und Codierer-/Decodiererfunktionalität sind nicht auf diese Beispiele beschränkt und können eine andere geeignete Funktionalität in anderen Ausführungsformen aufweisen.
• Die Kommunikationsschaltungsanordnung 209 weist auch eine HF-Schaltungsanordnung 211 und 212 auf, um eine Kommunikation mit Drahtlosnetzwerken unter Verwendung von modulierter elektromagnetischer Strahlung durch ein nicht-festes Medium zu ermöglichen. Jede der HF-Schaltungsanordnung 211 und 212 weist einen Empfangssignalpfad auf, welcher eine Schaltungsanordnung zum Umwandeln von analogen HF-Signalen (z. B. eine vorhandene oder empfangene modulierte Wellenform) in digitale Basisbandsignale, die der Basisbandschaltungsanordnung 210 bereitzustellen sind, aufweisen kann. Jede der HF-Schaltungsanordnung 211 und 212 weist auch einen Übertragungssignalpfad auf, welcher eine Schaltungsanordnung aufweisen kann, die konfiguriert ist, um digitale Basisbandsignale umzuwandeln, die von der Basisbandschaltungsanordnung 210 bereitgestellt werden, die in analoge HF-Signale (z. B. modulierte Wellenform) umzuwandeln sind, die über eine Antennenanordnung verstärkt und übertragen werden, die ein oder mehrere Antennenelemente aufweist (nicht gezeigt). Die Antennenanordnung kann eine Vielzahl von Mikrostreifenantennen oder gedruckten Antennen sein, die auf der Oberfläche von einer oder mehreren gedruckten Leiterplatten hergestellt sind. Die Antennenanordnung kann als ein Patch aus Metallfolie (z. B. eine Patch-Antenne) in einer Vielfalt von Formen gebildet sein und mit der HF-Schaltungsanordnung 211 oder 212 unter Verwendung von Metallübertragungsleitungen oder dergleichen gekoppelt sein.
• Die HF-Schaltungsanordnung 211 (auch als ein „Mesh-Transceiver“ bezeichnet) wird für Kommunikationen mit anderen Mesh- oder Fog-Vorrichtungen 264 verwendet. Der Mesh-Transceiver 211 kann eine beliebige Anzahl an Frequenzen und Protokollen, wie etwa unter anderem 2,4-Gigahertz-Übertragungen (2,4 GHz-Übertragungen) unter dem Standard IEEE 802.15.4, unter Verwendung des Standards Bluetooth® low energy (BLE), wie durch die Bluetooth® Special Interest Group definiert, oder des Standards ZigBee®, verwenden. Es kann eine beliebige Anzahl der HF-Schaltungsanordnung 211, die für ein konkretes Drahtloskommunikationsprotokoll konfiguriert ist, für die Verbindungen mit den Mesh-Vorrichtungen 264 verwendet werden. Zum Beispiel kann eine WLAN-Einheit verwendet werden, um WiFi™-Kommunikationen gemäß dem IEEE 802.11-Standard zu implementieren. Zusätzlich können drahtlose Großraumkommunikationen, zum Beispiel gemäß einem zellulären oder sonstigen drahtlosen Großraumprotokoll, über eine WWAN-Einheit erfolgen.
• Der Mesh-Transceiver 211 kann unter Verwendung von mehreren Standards oder Funkgeräten für Kommunikationen mit verschiedenen Reichweiten kommunizieren. Zum Beispiel kann die Plattform 200 mit nahegelegenen/nächsten Vorrichtungen, z. B. innerhalb von ungefähr 10 Metern, unter Verwendung eines lokalen Transceivers basierend auf BLE, oder einem anderen Funkgerät mit geringer Leistung, zum Sparen von Strom kommunizieren. Weiter entfernte Mesh-Vorrichtungen 264, z. B. innerhalb von ungefähr 20 Metern, können über ZigBee oder sonstige Zwischenleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit verschiedenen Leistungspegeln stattfinden oder können über separate Transceiver, zum Beispiel einen lokalen Transceiver, der BLE verwendet, und einen separaten Mesh-Transceiver, der ZigBee verwendet, stattfinden.
• Die HF-Schaltungsanordnung 212 (auch als ein „Drahtlosnetzwerktransceiver“, ein „Cloud-Transceiver“ oder dergleichen bezeichnet) kann aufgenommen werden, um mit Vorrichtungen oder Diensten in der Cloud 201 über lokale Netzwerkprotokolle oder Großraumnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerktransceiver 212 weist ein oder mehrere Funkgeräte auf, um mit Vorrichtungen in der Cloud 201 zu kommunizieren. Die Cloud 201 kann dieselbe oder ähnlich wie die zuvor erläuterte Cloud 144 sein. Der drahtlose Netzwerktransceiver 212 kann ein LPWA-Transceiver sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt, wie etwa die hierin erläuterten. Die Plattform 200 kann über einen großen Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wird, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl an anderen Cloud-Transceivern, die Kommunikationen mit großer Reichweite und geringer Bandbreite, wie etwa Sigfox, implementieren, und sonstigen Technologien verwendet werden. Ferner können andere Kommunikationstechniken, wie etwa Time-Slotted Channel Hopping, das in der Spezifikation IEEE 802.15.4 beschrieben ist, verwendet werden.
• Bei einer beispielhaften Implementierung kann die Kommunikationsschaltungsanordnung 209 ein softwaredefiniertes Funkgerät (SDR, Software Defined Radio) sein oder aufweisen, bei welchem HF-Betriebsparameter einschließlich dem Frequenzbereich, der Modulationsart und/oder der Ausgabeleistung durch Software und/oder die Technik, durch welche dies erzielt wird, ohne jedoch auf diese beschränkt zu sein, eingestellt oder geändert werden können. Zusätzlich oder alternativ kann die Kommunikationsschaltungsanordnung 209 ein softwaredefiniertes Mehrfachfunkgerät (SDMR, Software Defined Multiradio) sein oder aufweisen, welches eine Vorrichtung oder eine Technologie ist, wo mehrere Funktechnologien (oder RATs) koexistieren und sich ihre Drahtlosübertragungs- und/oder -empfangsfähigkeiten teilen, einschließlich geregelter Parameter, ohne jedoch auf diese beschränkt zu sein, indem sie unter einem gemeinsamen Softwaresystem betrieben werden. Bei jeder dieser beispielhaften Implementierungen kann jeder der Transceiver 211 und 212 Funkanwendungen sein, welche eine Softwareanwendung sind, die in einem SDR oder SDMR ausgeführt wird. Funkanwendungen sind typischerweise ausgelegt, um (ein) gewisse(s) HF-Band/-Bänder unter Verwendung von vereinbarten Schemen für Mehrfachzugriff, Modulation, Kanal- und Datencodierung sowie Steuerprotokolle für alle Funkschichten, die benötigt werden, um Nutzerdatenverknüpfungen zwischen benachbarten Funkgeräten zu verwalten, welche dieselbe Funkanwendung ausführen, zu verwenden.
• Es kann eine beliebige Anzahl an anderen Funkkommunikationen und -protokollen zusätzlich zu den für den Mesh-Transceiver 211 und den Drahtlosnetzwerktransceiver 212 erwähnten Systemen verwendet werden, wie hierin beschrieben ist. Zum Beispiel können die Funk-Transceiver 211 und 212 einen LTE- oder sonstigen zellulären Transceiver umfassen, der Spreizbandkommunikationen (SPA/SAS-Kommunikationen) zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl an anderen Protokollen verwendet werden, wie etwa WiFi®-Netzwerke für Mediengeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Die Transceiver 211 und 212 können Funkgeräte aufweisen, die mit einer oder mehreren der folgenden Funkkommunikationstechnologien und/oder -standards einschließlich der hierin erläuterten, ohne jedoch auf diese beschränkt zu sein, kompatibel sind und/oder gemäß diesen funktionieren können.
• Die Netzwerkschnittstellenschaltungsanordnung/-steuerung (NIC, Network Interfac Circuitry/Controller) 216 kann aufgenommen sein, um eine drahtgebundene Kommunikation der Cloud 201 oder anderen Vorrichtungen, wie etwa den Mesh-Vorrichtungen 264, unter Verwendung eines Standardnetzwerkschnittstellenprotokolls bereitzustellen. Das Standardnetzwerkschnittstellenprotokoll kann Ethernet, Ethernet over GRE Tunnels, Ethernet over Multiprotocol Label Switching (MPLS), Ethernet over USB aufweisen oder kann auf anderen Arten von Netzwerkprotokollen, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, oder PROFINET, unter vielen anderen, basieren. Es kann Netzwerkkonnektivität der Plattform 200 oder von dieser über die NIC 216 unter Verwendung einer physischen Verbindung, welche elektrisch (z. B. ein „Kupfer-Interconnect“) oder optisch sein kann, bereitgestellt werden. Die physische Verbindung weist auch geeignete Eingabeanschlüsse (z. B. Ports, Anschlussbuchsen, Steckdosen usw.) und Ausgabeanschlüsse (z. B. Stecker, Pins usw.) auf. Die NIC 216 kann einen oder mehrere dedizierte Prozessoren und/oder FPGAs zum Kommunizieren unter Verwendung von einem oder mehreren der zuvor genannten Netzwerkschnittstellenprotokolle aufweisen. Bei einigen Implementierungen kann die NIC 216 mehrere Steuerungen zum Bereitstellen von Konnektivität für andere Netzwerke unter Verwendung derselben oder anderer Protokolle aufweisen. Zum Beispiel kann die Plattform 200 eine erste NIC 216, die Kommunikationen für die Cloud über Ethernet bereitstellt, und eine zweite NIC 216, die Kommunikationen für andere Vorrichtungen über eine andere Art von Netzwerk bereitstellt, aufweisen.
• Das Interconnect 206 kann die Prozessorschaltungsanordnung 202 mit einer externen Schnittstelle 218 (auch als „E/A-Schnittstellenschaltungsanordnung“ oder dergleichen bezeichnet) koppeln, die verwendet wird, um externe Vorrichtungen oder Teilsysteme zu verbinden. Die externen Vorrichtungen weisen unter anderem eine Sensorschaltungsanordnung 221, Aktoren 222 und eine Positionierungsschaltungsanordnung 245 auf. Die Sensorschaltungsanordnung 221 kann Vorrichtungen, Module oder Teilsysteme aufweisen, deren Ziel es ist, Ereignisse oder Veränderungen in ihrer Umgebung zu erkennen und die Informationen (Sensordaten) über die erkannten Ereignisse zu einer anderen Vorrichtung, einem anderen Modul, einem anderen Teilsystem usw. zu senden. Beispiele für solche Sensoren 221 umfassen unter anderem Trägheitsmesseinheiten (IMU, Inertia Measurement Units), die Beschleunigungsmesser aufweisen, Gyroskope und/oder Magnetometer; mikroelektromechanische Systeme (MEMS) oder nanoelektromechanische Systeme (NEMS), die 3-Achsen-Beschleunigungsmesser, 3-Achsen-Gyroskope und/oder Magnetfeldstärkenmessgeräte aufweisen; Füllstandsensoren; Flusssensoren; Temperatursensoren (z. B. Temperaturfühler); Drucksensoren; Luftdrucksensoren; Gravimeter; Höhenmesser; Bildaufnahmevorrichtungen (z. B. Kameras); Lichterkennungs- und Abstandsmessungssensoren (LiDAR-Sensoren); Näherungssensoren (z. B. Infrarotstrahlungsdetektor und dergleichen), Tiefensensoren, Umgebungslichtsensoren, Ultraschalltransceiver; Mikrofone usw.
• Die externe Schnittstelle 218 verbindet die Plattform 200 mit den Aktoren 222, erlaubt der Plattform 200, ihren Zustand, ihre Position und/oder Ausrichtung zu ändern oder einen Mechanismus oder ein System zu bewegen oder zu steuern. Die Aktoren 222 weisen elektrische und/oder mechanische Vorrichtungen zum Bewegen oder Steuern eines Mechanismus oder Systems auf und wandeln Energie (z. B. elektrischen Strom oder sich bewegende Luft und/oder Flüssigkeit) in eine Art von Bewegung um. Die Aktoren 222 können eine oder mehrere elektronische (oder elektrochemische) Vorrichtungen, wie etwa piezoelektrische Biomorphe, Festkörperaktoren, Festkörperrelais (SSRs, Solid State Relays), formgedächtnislegierungsbasierte Aktoren, elektroaktive polymerbasierte Aktoren, integrierte Relais-Treiber-Schaltungen (Relais-Treiber-ICs) und/oder dergleichen, umfassen. Die Aktoren 222 können eine oder mehrere elektromechanische Vorrichtungen, wie etwa pneumatische Aktoren, hydraulische Aktoren, elektromechanische Schalter, die elektromechanische Relais (EMRs) aufweisen, Motoren (z. B. Gleichstrommotoren, Schrittmotoren, Servomechanismen usw.), Räder, Schubdüsen, Propeller, Klauen, Klemmen, Haken, einen Generator von hörbaren Geräuschen und/oder sonstige ähnliche elektromechanische Komponenten umfassen. Die Plattform 200 kann konfiguriert sein, um einen oder mehrere Aktoren 222 basierend auf einem oder mehreren aufgenommenen Ereignissen und/oder Anweisungen oder Steuersignalen, die von einem Dienstanbieter und/oder verschiedenen Client-Systemen empfangen werden, zu betreiben.
• Die Positionierungsschaltungsanordnung 245 weist eine Schaltungsanordnung auf, um Signale, die von einem Positionierungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/ausgestrahlt werden, zu empfangen und decodieren. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) umfassen das globale Positionierungssystem (GPS) der USA, Russlands globales Navigationssystem (GLONASS), das Galileo-System der Europäischen Union, Chinas BeiDou-Navigationssatellitensystem, ein regionales Navigationssystem oder GNSS-Vergrößerungssystem (z. B. Navigation with Indian Constellation (NAVIC), Japans Quasi-Zenith-Satellitensystem (QZSS), Frankreichs Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS) usw.) oder dergleichen. Die Positionierungsschaltungsanordnung 245 weist verschiedene Hardwareelemente (z. B. einschließlich Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen) auf, um mit Komponenten eines Positionierungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. In einigen Ausführungsformen kann die Positionierungsschaltungsanordnung 245 eine IC mit Mikrotechnologie zur Positionierung, Navigation und Zeitsteuerung (Micro-PNT, Micro-Technology for Positioning, Navigation and Timing) aufweisen, die einen Master-Zeitgebertakt verwendet, um Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen. Die Positionierungsschaltungsanordnung 245 kann auch Teil der Kommunikationsschaltungsanordnung 209 sein oder mit dieser interagieren, um mit den Knoten und Komponenten des Positionierungsnetzwerks zu kommunizieren. Die Positionierungsschaltungsanordnung 245 kann auch Positionsdaten und/oder Zeitdaten der Anwendungsschaltungsanordnung bereitstellen, welche die Daten zum Synchronisieren von Operationen mit verschiedener Infrastruktur (z. B. Funkbasisstationen) zur Turn-by-Turn-Navigation oder dergleichen verwenden kann.
• In einigen Beispielen können verschiedene E/A-Vorrichtungen innerhalb der Plattform 200 vorhanden oder mit dieser verbunden sein, welche als Eingabevorrichtungsschaltungsanordnung 286 und Ausgabevorrichtungsschaltungsanordnung 284 in 1 bezeichnet werden. Die Eingabevorrichtungsschaltungsanordnung 286 und die Ausgabevorrichtungsschaltungsanordnung 284 weisen eine oder mehrere Nutzerschnittstellen, die ausgestaltet sind, um eine Nutzerinteraktion mit der Plattform 200 zu ermöglichen, und/oder Peripheriekomponentenschnittstellen, die ausgestaltet sind, um eine Peripheriekomponenteninteraktion mit der Plattform 200 zu ermöglichen, auf. Die Eingabevorrichtungsschaltungsanordnung 286 kann ein physisches oder virtuelles Mittel zum Akzeptieren einer Eingabe, unter anderem eine oder mehrere physische oder virtuelle Tasten (z. B. eine Reset-Taste), eine physische Tastatur, ein Keypad, eine Maus, ein Touchpad, ein Touchscreen, Mikrofone, ein Scanner, ein Headset und/oder dergleichen aufweisen.
• Die Ausgabevorrichtungsschaltungsanordnung 284 kann aufgenommen sein, um Informationen zu zeigen oder anderweitig Informationen, wie etwa Sensorwerte, Aktorposition(en) oder sonstige ähnliche Informationen, zu transportieren. Daten und/oder Grafik können auf einer oder mehreren Nutzerschnittstellenkomponenten der Ausgabevorrichtungsschaltungsanordnung 284 angezeigt werden. Die Ausgabevorrichtungsschaltungsanordnung 284 kann eine beliebige Anzahl und/oder Kombinationen von Audio oder visueller Anzeige einschließlich unter anderem einer oder mehreren einfachen visuellen Ausgaben/Indikatoren (z. B. Binärstatusindikatoren (z. B. Leuchtdioden (LEDs, Light Emitting Diodes)) und visueller Mehrfachcharakterausgaben oder komplexerer Ausgaben, wie etwa Anzeigevorrichtungen oder Touchscreens (z. B. Flüssigkristallanzeigen (LCD, Liquid Crystal Displays), LED-Anzeigen, Quantum-dot-Anzeigen, Projektoren usw.), aufweisen, ohne dass die Ausgabe von Zeichen, Grafiken, Multimedia-Objekten und dergleichen anhand des Betriebs der Plattform 200 erzeugt oder produziert wird. Die Ausgabevorrichtungsschaltungsanordnung 284 kann auch Lautsprecher oder sonstige Audio-Ausgabevorrichtungen, (einen) Drucker und/oder dergleichen aufweisen. In einigen Ausführungsformen kann die Sensorschaltungsanordnung 221 als die Eingabevorrichtungsschaltungsanordnung 286 (z. B. eine Bildaufnahmevorrichtung, Bewegungsaufnahmevorrichtung oder dergleichen) verwendet werden und können ein oder mehrere Aktoren 222 als die Ausgabevorrichtungsschaltungsanordnung 284 (z. B. ein Aktor zum Bereitstellen von haptischem Feedback oder dergleichen) verwendet werden. In einem anderen Beispiel kann eine Nahfeldkommunikationsschaltungsanordnung (NFC-Schaltungsanordnung), die eine NFC-Steuerung aufweist, die mit einem Antennenelement und einer Verarbeitungsvorrichtung gekoppelt ist, aufgenommen sein, um elektronische Etiketten zu lesen und/oder sich mit einer anderen NFCfähigen Vorrichtung zu verbinden. Periphere Komponentenschnittstellen können einen nichtflüchtigen Speicherport, einen universellen seriellen Busport (USB-Port), einen Klinkenstecker, eine Stromversorgungsschnittstelle usw. umfassen, ohne jedoch darauf beschränkt zu sein.
• Es kann eine Batterie 224 mit der Plattform 200 gekoppelt sein, um die Plattform 200 zu bestromen, welche in Ausführungsformen verwendet werden kann, wo sich die Plattform 200 nicht an einem festen Standort befindet. Die Batterie 224 kann eine Lithiumionenbatterie, eine Bleisäureautobatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie, eine Lithium-Polymer-Batterie und/oder dergleichen, sein. In Ausführungsformen, wo die Plattform 200 an einem fixen Standort montiert ist, kann die Plattform 200 eine Stromversorgung aufweisen, die an ein Stromnetz gekoppelt ist. In diesen Ausführungsformen kann die Plattform 200 eine Power-Tee-Schaltungsanordnung aufweisen, um elektrischen Strom bereitzustellen, der von einem Netzwerkkabel aufgenommen wird, um sowohl eine Stromversorgung als auch Datenkonnektivität der Plattform 200 unter Verwendung eines einzigen Kabels bereitzustellen.
• Die integrierte Leistungsverwaltungsschaltungsanordnung (PMIC, Power Management Integrated Circuitry) 226 kann in der Plattform 200 enthalten sein, um den Ladezustand (SoCh, State of Charge) der Batterie 224 zu verfolgen und das Laden der Plattform 200 zu steuern. Die PMIC 226 kann verwendet werden, um andere Parameter der Batterie 224 zum Bereitstellen von Fehlervorhersagen zu überwachen, wie etwa den Gesundheitszustand (SoH, State of Health) und den Funktionszustand (SoF, State of Function) der Batterie 224. Die PMIC 226 kann Spannungsregler, Überspannungsschutzvorrichtungen und eine Leistungsalarmerkennungsschaltungsanordnung aufweisen. Die Leistungsalarmerkennungsschaltungsanordnung kann eine oder mehrere von Brown-Out-Bedingungen (Unterspannungsbedingungen) und Surge-Bedingungen (Überspannungsbedingungen) erkennen. Die PMIC 226 kann die Informationen bezüglich der Batterie 224 der Prozessorschaltungsanordnung 202 über das Interconnect 206 mitteilen. Die PMIC 226 kann auch einen Analog-DigitalWandler (ADC, Analog-to-Digital Convertor) aufweisen, der der Prozessorschaltungsanordnung 202 erlaubt, die Spannung der Batterie 224 oder den Stromfluss von der Batterie 224 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die die Plattform 200 durchführen kann, wie etwa die Übertragungsfrequenz, der Mesh-Netzwerkbetrieb, die Erfassungsfrequenz und dergleichen. Als ein Beispiel kann die PMIC 226 eine integrierte Batterieüberwachungsschaltung, wie etwa eine LTC5020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor aus Phoenix, Arizona, oder eine IC von der UCD90xxx-Familie von Texas Instruments aus Dallas, TX, sein.
• Ein Netzgerät 228 oder eine sonstige Stromversorgung, die mit einem Stromnetz gekoppelt ist, kann mit der PMIC 226 gekoppelt werden, um die Batterie 224 zu laden. In einigen Beispielen kann das Netzgerät 228 durch einen drahtlosen Stromempfänger zum drahtlosen Erhalten des Stroms, zum Beispiel durch eine Loop-Antenne in der Plattform 200, ersetzt werden. Eine drahtlose Batterieladeschaltung, wie etwa unter anderem ein LTC5020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in der PMIC 226 aufgenommen sein. Die spezifischen gewählten Ladeschaltungen hängen von der Größe der Batterie 224 und somit dem benötigten Strom ab. Das Laden kann unter Verwendung unter anderem des Airfuel-Standards, der von der Airfuel Alliance veröffentlicht ist, des Qi-Drahtlosladestandards, der von dem Wireless Power Consortium veröffentlicht ist, oder des Rezence-Ladestandards, der von der Alliance for Wireless Power veröffentlicht ist, durchgeführt werden.
• 3 veranschaulicht ein Beispiel der Infrastrukturausrüstung 300 gemäß verschiedenen Ausführungsformen. Die Infrastrukturausrüstung 300 (oder das „System 300“) kann als eine Basisstation, ein Radio Head, ein Zugriffsnetzwerkknoten (z. B. die Edge-Knoten 130, die in 1 gezeigt sind), MEC-Server 136, (ein) Server 150 und/oder ein beliebiges sonstiges Element/Vorrichtung, die hierin erläutert werden, implementiert werden. In anderen Beispielen könnte das System 300 in einem Zwischenknoten 120 oder Endpunkt 110 oder von diesen implementiert werden.
• Das System 300 weist eine Anwendungsschaltungsanordnung 305, eine Basisbandschaltungsanordnung 310, ein oder mehrere Funk-Front-End-Module (RFEMs, Radio Front End Modules) 315, eine Speicherschaltungsanordnung 320, eine integrierte Leistungsverwaltungsschaltungsanordnung (PMIC, Power ManagementIntegrated Circuitry) 325, eine Power-Tee-Schaltungsanordnung 330, eine Netzwerksteuerungsschaltungsanordnung 335, einen Netzwerkschnittstellenanschluss 340, eine Positionierungsschaltungsanordnung 345 und eine Nutzerschnittstelle 350 auf. In einigen Ausführungsformen kann die Vorrichtung 300 zusätzliche Elemente, wie zum Beispiel einen Speicher/Ablage, eine Anzeige, eine Kamera, einen Sensor oder eine E/A-Schnittstelle, aufweisen. In anderen Ausführungsformen können die nachstehend beschriebenen Komponenten in mehr als einer Vorrichtung enthalten sein. Zum Beispiel können die Schaltungsanordnungen separat in mehr als einer Vorrichtung für CRAN, CR, vBBU oder sonstige ähnliche Implementierungen enthalten sein.
• Die Anwendungsschaltungsanordnung 305 weist eine Schaltungsanordnung, wie etwa einen oder mehrere Prozessoren (oder Prozessorkerne), einen Cache-Speicher, und einen oder mehrere Spannungsregler mit niedriger Abfallspannung (LDOs, Low Drop-Out Voltage Regulators), Unterbrechungssteuerungen, serielle Schnittstellen, wie etwa eine serielle periphere Schnittstelle (SPI, Serial Peripheral Interface), eine inter-integrierte Schaltung (I²C) oder ein universelles programmierbares serielles Schnittstellenmodul, eine Echtzeituhr (RTC, Real Time Clock), Zeitgeber-Zähler einschließlich Intervall- und Überwachungszeitgebern, eine Universal-Eingabe-Ausgabe (IO, Input-Output), Speicherkartensteuerungen, wie etwa eine sichere digitale/Multi-Media-Karte (SD/MMC) oder ähnliches, universelle serielle Bus-Schnittstellen (USB-Schnittstellen), MIPI-Schnittstellen (Mobile Industry Processor Interface) und JTAG-Testzugangsanschlüsse (Joint Test Access Group) auf, ohne jedoch auf diese beschränkt zu sein. Die Prozessoren (oder Kerne) der Anwendungsschaltungsanordnung 305 können mit Speicher-/Ablageelementen gekoppelt sein oder diese aufweisen und konfiguriert sein, um Anweisungen auszuführen, die in dem Speicher/der Ablage gespeichert sind, um verschiedenen Anwendungen oder Betriebssystemen zu ermöglichen, auf dem System 300 ausgeführt zu werden. Bei einigen Implementierungen können die Speicher-/Ablageelemente eine On-Chip-Speicherschaltungsanordnung sein, welche einen beliebigen geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flash-Speicher, Festkörperspeicher und/oder eine beliebige sonstige Art von Speichervorrichtungstechnologie, wie etwa die hierin erläuterten, aufweisen kann.
• Der/die Prozessor(en) der Anwendungsschaltungsanordnung 305 kann/können zum Beispiel einen oder mehrere Prozessorkerne (CPUs), einen oder mehrere Anwendungsprozessoren, eine oder mehrere Grafikverarbeitungseinheiten (GPUs), eine oder mehrere Prozessoren mit verringerter Befehlssatzberechnung (RISC), einen oder mehrere ARM-Prozessoren (Acorn RISC Machine processors), einen oder mehrere Prozessoren mit komplexer Befehlssatzberechnung (CSIC), einen oder mehrere DSPs, ein oder mehrere FPGAs, eine oder mehrere PLDs, eine oder mehrere ASICs, einen oder mehrere Mikroprozessoren oder Controller oder eine beliebige geeignete Kombination davon aufweisen. In einigen Ausführungsformen kann die Anwendungsschaltungsanordnung 305 einen Sonderzweckprozessor/- controller aufweisen oder sein, um gemäß den verschiedenen Ausführungsformen hierin zu arbeiten. Als Beispiele kann/können der/die Prozessor(en) der Anwendungsschaltungsanordnung 305 einen oder mehrere Intel Pentium®-, Core®- oder Xeon®-Prozessor(en); Advanced Micro Devices (AMD) Ryzen®-Prozessor(en), beschleunigte Verarbeitungseinheiten (APUs) oder Epyc®-Prozessoren; ARM-basierte(n) Prozessor(en), die von ARM Holdings, Ltd. lizenziert werden, wie etwa die ARM Cortex-A-Familie von Prozessoren und der ThunderX2®, bereitgestellt von Cavium, Inc.; ein MIPS-basiertes Design von MIPS Technologies, Inc., wie etwa MIPS Warrior P-Klasse-Prozessoren; und/oder dergleichen umfassen. In einigen Ausführungsformen verwendet das System 300 möglicherweise nicht die Anwendungsschaltungsanordnung 305 und kann stattdessen einen Sonderzweckprozessor/-controller zum Verarbeiten von IP-Daten, die zum Beispiel von einem EPC oder 5GC erhalten werden, aufweisen.
• Bei einigen Implementierungen kann die Anwendungsschaltungsanordnung 305 einen oder mehrere Hardwarebeschleuniger aufweisen, welche Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen oder dergleichen sein können. Der eine oder die mehreren Hardwarebeschleuniger können zum Beispiel Computer-Vision-Beschleuniger (CV-Beschleuniger) und/oder Deep-Learning-Beschleuniger (DL-Beschleuniger) umfassen. Als Beispiele können die programmierbaren Verarbeitungsvorrichtungen ein oder mehrere feldprogrammierbare Gatteranordnungen (FPGAs, Field-Programmable Gate Arrays); programmierbare Logik-Vorrichtungen (PLDs, Programmable Logic Devices), wie etwa komplexe PLDs (CPLDs, Complex PLDs), PLDs mit hoher Kapazität (HCPLDs, High-Capacity PLDs) und dergleichen; ASICs, wie etwa strukturierte ASICs und dergleichen; programmierbare SoCs (PSoCs); und/oder dergleichen sein. Bei solchen Implementierungen kann die Schaltungsanordnung der Prozessorschaltungsanordnung 305 Logikblöcke oder ein Logikfabric und andere verschaltete Ressourcen, die programmiert werden können, um verschiedene Funktionen, wie etwa die Verfahren, Methoden, Funktionen usw. der verschiedenen hierin erläuterten Ausführungsformen, durchzuführen, aufweisen. In solchen Ausführungsformen kann die Schaltungsanordnung der Anwendungsschaltungsanordnung 305 Speicherzellen (z. B. einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM, Erasable Programmable Read-Only Memory), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM, Electrically Erasable Programmable Read-Only), einen Flash-Speicher, einen statischen Speicher (z. B. einen statischen Direktzugriffsspeicher (SRAM, Static Random Access Memory), Antischmelzsicherungen usw.)) aufweisen, die verwendet werden, um Logik-Blöcke, ein Logik-Fabric, Daten usw. in Look-up-Tabellen (LUTs) und dergleichen zu speichern.
• Bei einigen Implementierungen, wie etwa Implementierungen, wo Teilsysteme der Edge-Knoten 130, Zwischenknoten 120 und/oder Endpunkte 110 von 1 einzelne Softwareagenten oder AI-Agenten sind, ist jeder Agent in einem jeweiligen Hardwarebeschleuniger implementiert, die mit (einem) geeigneten Bit-Stream(s) oder Logik-Blöcken konfiguriert sind, um ihre jeweiligen Funktionen durchzuführen. Bei diesen Implementierungen kann/können der/die Prozessor(en) und/oder Hardwarebeschleuniger der Anwendungsschaltungsanordnung 305 spezifisch zum Betreiben der Agenten und/oder zur Machine Learning-Funktionalität, wie etwa ein Cluster von AI GPUs, Tensor Processing Units (TPUs), von Google® Inc. entwickelt, Real AI Processors (RAPs™), die von AlphaICs® bereitgestellt werden, Nervana™ Neural Network Processors (NNPs), die von Intel® Corp. bereitgestellt werden, Intel® Movidius™ Myriad™ X Vision Processing Unit (VPU), NVIDIA® PX™-basierte GPUs, der NM500-Chip, der von General Vision® bereitgestellt wird, Hardware 3, die von Tesla®, Inc. bereitgestellt wird, ein Epiphany™-basierter Prozessor, der von Adapteva® bereitgestellt wird, oder dergleichen, maßgeschneidert sein. In einigen Ausführungsformen kann der Hardwarebeschleuniger als ein AI-beschleunigender Co-Prozessor, wie etwa der Hexagon 685 DSP, der von Qualcomm® bereitgestellt wird, der PowerVR 2NX Neural Net Accelerator (NNA), der von Imagination Technologies Limited® bereitgestellt wird, der Neural Engine-Kern innerhalb des Apple® A11 oder A12 Bionic SoC, die neurale Verarbeitungseinheit innerhalb des HiSilicon Kirin 970, der von Huawei® bereitgestellt wird, und/oder dergleichen implementiert werden.
• Die Basisbandschaltungsanordnung 310 kann zum Beispiel als ein Solder-Down-Substrat einschließlich einer oder mehrerer integrierter Schaltungen, einer einzelnen gepackten integrierten Schaltung, die an eine Hauptplatine gelötet ist, oder eines Mehrfach-Chip-Moduls, das zwei oder mehr integrierte Schaltungen enthält, implementiert sein. Die Basisbandschaltungsanordnung 310 weist eine oder mehrere Verarbeitungsvorrichtungen (z. B. Basisbandprozessoren) auf, um verschiedene Protokoll- und Funksteuerfunktionen auszuführen. Die Basisbandschaltungsanordnung 310 kann mit der Anwendungsschaltungsanordnung des Systems 300 zur Erzeugung und Verarbeitung der Basisbandsignale und zur Steuerung von Operationen der RFEMs 315 verbunden sein. Die Basisbandschaltungsanordnung 310 kann verschiedene Funksteuerfunktionen handhaben, die die Kommunikation mit einem oder mehreren Funknetzwerken über die RFEMs 315 ermöglichen. Die Basisbandschaltungsanordnung 310 kann eine Schaltungsanordnung, wie etwa einen oder mehrere Einzelkern- oder Mehrkernprozessoren (z. B. ein oder mehrere Basisbandprozessoren) oder eine Steuerlogik, ohne jedoch auf diese beschränkt zu sein, zum Verarbeiten von Basisbandsignalen, die von einem Empfangssignalpfad der RFEMs 315 empfangen werden, und zum Erzeugen von Basisbandsignalen, die den RFEMs 315 über einen Übertragungssignalpfad bereitzustellen sind, aufweisen. In verschiedenen Ausführungsformen kann die Basisbandschaltungsanordnung 310 ein Echtzeit-OS (RTOS) implementieren, um Ressourcen der Basisbandschaltungsanordnung 310 zu verwalten, Aufgaben zu planen usw. Beispiele des RTOS können Operating System Embedded (OSE)™, das von Enea® bereitgestellt wird, Nucleus RTOS™ , das von Mentor Graphics® bereitgestellt wird, Versatile Real-Time Executive (VRTX), das von Mentor Graphics® bereitgestellt wird, ThreadX™, das von Express Logic® bereitgestellt wird, FreeRTOS, REX OS, das von Qualcomm® bereitgestellt wird, OKL4, das von Open Kernel (OK) Labs® bereitgestellt wird, oder irgendein sonstiges geeignetes RTOS, wie etwa die hierin erläuterten, umfassen.
• Wenngleich es nicht durch 3 gezeigt ist, weist in einer Ausführungsform die Basisbandschaltungsanordnung 310 (eine) einzelne Verarbeitungsvorrichtung(en) zum Betreiben von einem oder mehreren Drahtloskommunikationsprotokollen (z. B. einen „Mehrfachprotokoll-Basisbandprozessor“ oder eine „Protokollverarbeitungsschaltungsanordnung“) und (eine) einzelne Verarbeitungsvorrichtung(en) zum Implementieren von Physical-Layer-Funktionen (PHY-Funktionen) auf. In dieser Ausführungsform betreibt oder implementiert die Protokollverarbeitungsschaltungsanordnung verschiedene Protokollschichten/-entitäten von einem oder mehreren Drahtloskommunikationsprotokollen. In einem ersten Beispiel kann die Protokollverarbeitungsschaltungsanordnung LTE-Protokollentitäten und/oder 5G/NR-Protokollentitäten betreiben, wenn die RFEMs 315 ein zelluläres Funkfrequenzkommunikationssystem, wie etwa eine Millimeterwellenkommunikationsschaltungsanordnung (mmWave-Kommunikationsschaltungsanordnung) oder eine andere geeignete zelluläre Kommunikationsschaltungsanordnung, sind. In dem ersten Beispiel würde die Protokollverarbeitungsschaltungsanordnung MAC-, RLC-, PDCP-, SDAP-, RRC- und NAS-Funktionen ausführen. In einem zweiten Beispiel kann die Protokollverarbeitungsschaltungsanordnung ein oder mehrere IEEE-basierte Protokolle ausführen, wenn die RFEMs 315 ein WiFi-Kommunikationssystem sind. In dem zweiten Beispiel würde die Protokollverarbeitungsschaltungsanordnung WiFi MAC- und LLC-Funktionen ausführen. Die Protokollverarbeitungsschaltungsanordnung kann eine oder mehrere Speicherstrukturen (nicht gezeigt) aufweisen, um Programmcode und Daten zum Ausführen der Protokollfunktionen sowie einen oder mehrere Verarbeitungskerne (nicht gezeigt) zum Ausführen des Programmcodes und Durchführen verschiedener Operationen unter Verwendung der Daten aufweisen. Die Protokollverarbeitungsschaltungsanordnung stellt Steuerfunktionen für die Basisbandschaltungsanordnung 310 und/oder die RFEMs 315 bereit. Die Basisbandschaltungsanordnung 310 kann auch Funkkommunikationen für mehr als ein Drahtlosprotokoll unterstützen.
• Mit der zuvor genannten Ausführungsform fortfahrend weist die Basisbandschaltungsanordnung 310 (eine) einzelne Verarbeitungsvorrichtung(en) zum Implementieren von PHY- einschließlich HARQ-Funktionen, Verschlüsseln und/oder Entschlüsseln, Codieren und/oder Decodieren, für Schicht-Mapping und/oder -Demapping, Modulationssymbolmapping, Bestimmung von erhaltenem Symbol und/oder Bitmetrik, Mehrfachantennenanschlussvorcodierung und/oder - decodierung, welche eine oder mehrere von Zeit-Raum-, Zeit-Frequenz- oder räumliche Codierung umfassen kann, Referenzsignalerzeugung und/oder - erfassung, Präambelsequenzerzeugung und/oder -decodierung, Synchronisierungssequenzerzeugung und/oder -erfassung, Steuerkanalsignalblinddecodierung, Funkfrequenzverschiebung und sonstige diesbezügliche Funktionen usw. auf. Die Modulations-/Demodulationsfunktionalität kann die Fast-Fourier-Transformation (FFT), Vorcodierung oder Konstellationsmapping-/-demappingfunktionalität umfassen. Die Codierungs-/Decodierungsfunktionalität kann Faltung, Tail-Biting-Faltung, Turbocodierung, Viterbi-Codierung oder Low Density Parity Check-Codierung (LDPC-Codierung) umfassen. Die Ausführungsformen der Modulierung/Demodulierung und Codierer-/Decodiererfunktionalität sind nicht auf diese Beispiele beschränkt und können eine andere geeignete Funktionalität in anderen Ausführungsformen aufweisen.
• Die Nutzerschnittstellenschaltungsanordnung 350 kann eine oder mehrere Nutzerschnittstellen, die ausgelegt sind, um eine Nutzerinteraktion mit dem System 300 zu ermöglichen, oder periphere Komponentenschnittstellen, die ausgelegt sind, um eine periphere Komponenteninteraktion mit dem System 300 zu ermöglichen, aufweisen. Die Nutzerschnittstellen können eine oder mehrere physische oder virtuelle Tasten (z. B. eine Reset-Taste), einen oder mehrere Indikatoren (z. B. Leuchtdioden (LEDs)), eine physische Tastatur oder ein physisches Keypad, eine Maus, ein Touchpad, einen Touchscreen, Lautsprecher oder sonstige Audio-Ausgabevorrichtungen, Mikrofone, einen Drucker, einen Scanner, ein Headset, einen Anzeigebildschirm oder eine Anzeigevorrichtung usw. umfassen, ohne jedoch auf diese beschränkt zu sein. Die peripheren Komponentenschnittstellen können einen nichtflüchtigen Speicherport, einen universellen seriellen Busport (USB-Port), einen Klinkenstecker, eine Stromversorgungsschnittstelle usw. umfassen, ohne jedoch auf diese beschränkt zu sein.
• Die Funk-Frontend-Module (RFEMs) 315 können ein Millimeterwellen-RFEM (mmWave-RFEM) und eine oder mehrere integrierte Sub-mmWellen-Funkfrequenzschaltungen (Sub-mmWave-RFICs) aufweisen. Bei einigen Implementierungen können die eine oder die mehreren Sub-mmWave-RFICs physisch von dem mmWave-RFEM getrennt sein. Die RFICs können Verbindungen mit einer oder mehreren Antennen oder Antennenanordnungen aufweisen, und das RFEM kann mit mehreren Antennen verbunden sein. Bei alternativen Implementierungen können sowohl mmWave- als auch Sub-mmWave-Funkfunktionen in demselben physischen RFEM 315 implementiert sein, in welchem sowohl mmWave-Antennen als auch Sub-mmWave-Antennen aufgenommen sind. Die Antennenanordnung weist ein oder mehrere Antennenelemente auf, von welchen jedes zum Umwandeln von elektrischen Signalen in Funkwellen zum Fortbewegen durch die Luft und zum Umwandeln von empfangenen Funkwellen in elektrische Signale konfiguriert ist. Zum Beispiel werden digitale Basisbandsignale, die von der Basisbandschaltungsanordnung 310 bereitgestellt werden, in analoge HF-Signale (z. B. modulierte Wellenform) umgewandelt, die über die Antennenelemente der Antennenanordnung, die ein oder mehrere Antennenelemente (nicht gezeigt) aufweist, verstärkt und übertragen werden. Die Antennenelemente können Rundstrahlantennenelemente, Richtantennenelemente oder eine Kombination davon sein. Die Antennenelemente können in einer Vielzahl an Anordnungen gebildet sein, wie sie bekannt und/oder hierin erläutert sind. Die Antennenanordnung kann Mikrostreifenantennen oder gedruckte Antennen aufweisen, die auf der Oberfläche von einer oder mehreren gedruckten Leiterplatten hergestellt sind. Die Antennenanordnung kann als ein Patch aus Metallfolie (z. B. eine Patch-Antenne) in einer Vielfalt von Formen gebildet sein und mit der HF-Schaltungsanordnung unter Verwendung von Metallübertragungsleitungen oder dergleichen gekoppelt sein.
• Die Speicherschaltungsanordnung 320 kann einen oder mehrere eines flüchtigen Speichers einschließlich eines dynamischen Direktzugriffsspeichers (DRAM, Dynamic Random Access Memory) und/oder synchronen dynamischen Direktzugriffsspeichers (SDRAM), und nichtflüchtigen Speichers (NVM, Nonvolatile Memory) einschließlich eines elektrisch löschbaren Hochgeschwindigkeitsspeichers (allgemein als Flash-Speicher bezeichnet), Phasenwechseldirektzugriffsspeichers (PRAM, Phase Change Random Access Memory), magnetoresistiven Direktzugriffsspeichers (MRAM, Magnetoresistive Random Access Memory) usw. aufweisen und kann die dreidimensionalen Cross-Point-Speicher (3D XPOINT-Speicher) von Intel® und Micron® enthalten. Die Speicherschaltungsanordnung 320 kann als eine oder mehrere gepackte integrierte Solder-Down-Schaltungen, gesockelte Speichermodule und Plug-in-Speicherkarten implementiert sein.
• Die Speicherschaltungsanordnung 320 ist konfiguriert, um eine Rechenlogik (oder „-module“) in Form von Software-, Firmware- oder Hardwarebefehlen zum Implementieren der hierin beschriebenen Techniken zu speichern. Die Rechenlogik oder die Rechenmodule können unter Verwendung einer geeigneten Programmiersprache oder von geeigneten Entwicklungstools, wie etwa eine beliebige Programmiersprache oder ein beliebiges Entwicklungstool, die hierin erläutert werden, entwickelt werden. Die Rechenlogik kann eingesetzt werden, um Arbeitskopien und/oder permanente Kopien von Programmieranweisungen für die Bedienung von verschiedenen Komponenten der Geräteinfrastrukturausrüstung 300, eines Betriebssystems der Infrastrukturausrüstung 300, einer oder mehrerer Anwendungen und/oder zum Ausführen der hierin erläuterten Ausführungsformen eingesetzt werden. Die Rechenlogik kann in einer Speicherschaltungsanordnung 320 als Anweisungen zur Ausführung durch die Prozessoren der Anwendungsschaltungsanordnung 305 zum Bereitstellen oder Durchführen der hierin beschriebenen Funktionen gespeichert oder in diese geladen werden. Die verschiedenen Elemente können durch Assembleranweisungen, die von Prozessoren der Anwendungsschaltungsanordnung 305 unterstützt werden, oder Hochebenensprachen, die zu solchen Anweisungen kompiliert werden können, implementiert werden. Die permanente Kopie der Programmieranweisungen kann in die dauerhaften Speichervorrichtungen der Speicherschaltungsanordnung 320 in der Fabrik während der Herstellung oder auf dem Feld, zum Beispiel durch ein Verteilungsmedium (nicht gezeigt), durch eine Kommunikationsschnittstelle (z. B. von einem Verteilungsserver) und/oder über die Luft (OTA, Over-the-Air), platziert werden.
• Wie weiter unten ausführlicher erläutert wird, kann die Infrastrukturausrüstung 300 konfiguriert sein, um eine konkrete V2X RAT basierend auf der Anzahl an vUEs 121 zu unterstützen, die die konkrete V2X RAT unterstützen (oder in der Lage sind, diese zu kommunizieren). In Ausführungsformen kann die Speicherschaltungsanordnung 320 ein RAT-Konfigurationssteuermodul zum Steuern der (Neu-)Konfiguration der Infrastrukturausrüstung 300 zum Unterstützen einer konkreten RAT und/oder V2X RAT speichern. Das Konfigurationssteuermodul stellt eine Schnittstelle zum Auslösen von (Neu-)Konfigurationsaktionen bereit. In einigen Ausführungsformen kann die Speicherschaltungsanordnung 320 auch ein RAT-Software-Verwaltungsmodul (RAT SW-Verwaltungsmodul) zum Implementieren von SW-Laden oder Bereitstellen von Verfahren und (De)aktivierung von SW in der Infrastrukturausrüstung 300 speichern. In jeder dieser Ausführungsformen kann die Speicherschaltungsanordnung 320 eine Vielzahl von V2X RAT-Softwarekomponenten speichern, von welchen jede Programmcode, Anweisungen, Module, Baugruppen, Packages, Protokollstapel, (eine) Softwareengine(s) usw. zum Betreiben der Infrastrukturausrüstung 300 oder von Komponenten davon (z. B. die RFEMs 315) gemäß einer entsprechenden V2X RAT aufweisen. Wenn eine V2X RAT-Komponente durch die Anwendungsschaltungsanordnung 305 und/oder die Basisbandschaltungsanordnung 310 konfiguriert oder ausgeführt wird, funktioniert die Infrastrukturausrüstung 300 gemäß jener V2X RAT-Komponente.
• In einem ersten Beispiel kann eine erste V2X RAT-Komponente eine LTE C-V2X-Komponente sein, welche LTE- und/oder C-V2X-Protokollstapel aufweist, die der Infrastrukturausrüstung 300 erlauben, LTE C-V2X zu unterstützen und/oder Funk-Zeit-/Frequenzressourcen gemäß LTE- und/oder LTE C-V2X-Standards bereitzustellen. Solche Protokollstapel können einen Steuerebenenprotokollstapel, der ein Non-Access Stratum (NAS), Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC) und physische Schicht-Entitäten (PHY-Schicht-Entitäten) aufweist; und einen Nutzerebenenprotokollstapel, der das General Packet Radio Service (GPRS) Tunneling Protocol für die Nutzerebenenschicht (GTP-U), das User Datagram Protocol (UDP), das Internetprotokoll (IP), PDCP-, RLC-, MAC- und PHY-Schicht-Entitäten aufweist, aufweisen. Diese Steuerebenen- und Nutzerebenenprotokollentitäten werden in der technischen Spezifikation (TS) von 3GPP 36.300 Version (v) 15.1.0 (2018-03) sowie anderen 3GPP-Spezifikationen ausführlicher erläutert. In einigen Ausführungsformen kann die IP-Schicht-Entität durch eine Zuweisungs- und Erhaltungsprioritätsschichtentität (ARP-Schicht-Entität, Allocation and Retention Priority layer entity) oder eine andere Nicht-IP-Protokoll-Schicht-Entität ersetzt werden. Einige oder alle der zuvor genannten Protokollschichtentitäten können „Relais“-Versionen je nachdem, ob die Infrastrukturausrüstung 300 als ein Relais agiert, sein. In einigen Ausführungsformen kann der Nutzerebenenprotokollstapel der PC5-Nutzerebenenprotokollstapel (PC5-U-Protokollstapel) sein, der in 3GPP TS 23.303 v15.1.0 (2018-06) erläutert wird.
• In einem zweiten Beispiel kann eine zweite V2X RAT-Komponente eine DSRC/ITS-G5-Komponente sein, welche unter anderem DSRC/ITS-G5 (IEEE 802.11p)-Protokollstapel und/oder Protokollstapel mit drahtlosem Zugriff in Fahrzeugumgebungen (WAVE, Wireless Access in Vehicular Environments) (IEEE 1609.4) sein können, die der Infrastrukturausrüstung erlauben, DSRC/ITS-G5-Kommunikationen zu unterstützen und/oder Funk-Zeit-/Frequenzressourcen gemäß DSCR/ITS-G5 und/oder sonstigen WiFi-Standards bereitzustellen. Die DSRC/ITS-G5- und WAVE-Protokollstapel weisen unter anderem DSRC/WAVE PHY- und MAC-Schicht-Entitäten auf, die auf dem IEEE 802.11p-Protokoll basieren. Die DSRC/WAVE PHY-Schicht ist für das Erhalten von Daten zum Übertragen über DSRC/ITS-G5-Kanälen von höheren Schichten sowie das Erhalten von Rohdaten über die DSRC/ITS-G5-Kanäle und das Bereitstellen von Daten für obere Schichten zuständig. Die MAC-Schicht organisiert die Datenpakete in Netzwerk-Frames. Die MAC-Schicht kann in eine untere DSRC/WAVE MAC-Schicht basierend auf IEEE 802.11p und eine obere WAVE MAC-Schicht (oder eine WAVE-Mehrfachkanalschicht) basierend auf IEEE 1609.4 aufgeteilt werden. IEEE 1609 baut auf IEEE 802.11p auf und definiert eine oder mehrere der anderen höheren Schichten. Die DSRC/ITS-G5-Komponente kann auch eine logische Link-Steuer-Schicht-Entität (LLC-Schicht-Entität) zum Durchführen von Layer 3-Multiplex- und Demultiplex-Operationen (L3-Multiplex- und Demultiplex-Operationen) aufweisen. Die LLC-Schicht (z. B. IEEE 802.2) erlaubt mehreren Netzwerk-L3-Protokollen, über dieselbe physische Verknüpfung zu kommunizieren, indem den L3-Protokollen erlaubt wird, in LLC-Feldern spezifiziert zu werden.
• Zusätzlich zu den V2X RAT-Komponenten kann die Speicherschaltungsanordnung 320 auch eine RAT-Übersetzungskomponente speichern, welche eine Softwareengine, API, Bibliothek, (ein) Objekt(e), (eine) Engine(s) oder sonstige funktionelle Einheit zum Bereitstellen von Übersetzungsdiensten für die vUEs 121, die mit verschiedenen V2X-Fähigkeiten ausgestattet sind, ist. Zum Beispiel kann die RAT-Übersetzungskomponente, wenn sie konfiguriert oder ausgeführt wird, bewirken, dass die Infrastrukturausrüstung 300 eine erste Nachricht, die gemäß der ersten V2X RAT (z. B. LTE C-V2X) erhalten wird, in eine zweite Nachricht zur Übertragung unter Verwendung einer zweiten V2X RAT (z. B. DSRC/ITS-G5) umwandelt oder übersetzt. In einem Beispiel kann die RAT-Übersetzungskomponente die Übersetzung oder Umwandlung durch Extrahieren von Daten aus einem oder mehreren Feldern der ersten Nachricht und Einfügen der extrahierten Daten in entsprechende Felder der zweiten Nachricht durchführen. Es können auch andere Übersetzungs-/Umwandlungsverfahren in anderen Ausführungsformen verwendet werden. In einigen Ausführungsformen kann die RAT-Übersetzungskomponente einen geeigneten Übersetzer zum Übersetzen von einer oder mehreren Quellnachrichten in einem Quellformat in eine oder mehrere Zielnachrichten in einem Zielformat einsetzen und beliebige geeignete Kompilierungsstrategien für die Übersetzung verwenden. Der Übersetzer kann auch verschiedene Implementierungen je nach der Art von V2X RATs, die von der Infrastrukturausrüstung 300 unterstützt werden (z. B. Speicherkarte, Befehlssatz, Programmiermodell usw.) aufweisen.
• Die PMIC 325 kann Spannungsregler, Überspannungsschutzvorrichtungen, eine Leistungsalarmerkennungsschaltungsanordnung und eine oder mehrere Notstromquellen, wie etwa eine Batterie oder ein Kondensator, aufweisen. Die Leistungsalarmerkennungsschaltungsanordnung kann eine oder mehrere von Brown-Out-Bedingungen (Unterspannungsbedingungen) und Surge-Bedingungen (Überspannungsbedingungen) erkennen. Die Power-Tee-Schaltungsanordnung 330 kann elektrischen Strom bereitstellen, der von einem Netzwerkkabel aufgenommen wird, um der Infrastrukturausrüstung 300 unter Verwendung eines einzigen Kabels sowohl eine Stromversorgung als auch Datenkonnektivität bereitzustellen.
• Die Netzwerksteuerungsschaltungsanordnung 335 stellt einem Netzwerk unter Verwendung eines Standard-Netzwerkschnittstellenprotokolls, wie etwa Ethernet, Ethernet over GRE Tunnels, Ethernet over Multiprotocol Label Switching oder ein anderes geeignetes Protokoll, wie etwa die hierin erläuterten, Konnektivität bereit. Es kann Netzwerkkonnektivität über den Netzwerkschnittstellenanschluss 340 unter Verwendung einer physischen Verbindung, welche elektrisch (allgemein als ein „Kupfer-Interconnect“ bezeichnet), optisch oder drahtlos sein kann, der Infrastrukturausrüstung 300 oder von dieser bereitgestellt werden. Die Netzwerksteuerungsschaltungsanordnung 335 kann einen oder mehrere dedizierte Prozessoren und/oder FPGAs zum Kommunizieren unter Verwendung von einem oder mehreren der zuvor genannten Protokolle aufweisen. Bei einigen Implementierungen kann die Netzwerksteuerungsschaltung sanordnung 335 mehrere Steuerungen aufweisen, um anderen Netzwerken unter Verwendung von gleichen oder unterschiedlichen Protokollen Konnektivität bereitzustellen. In verschiedenen Ausführungsformen ermöglicht die Netzwerksteuerungsschaltungsanordnung 335 eine Kommunikation mit verknüpften Geräten und/oder mit einem Backend-System (z. B. der/die Server 130 von 1), welche über eine geeignete Gateway-Vorrichtung stattfinden kann.
• Die Positionierungsschaltungsanordnung 345 weist eine Schaltungsanordnung auf, um Signale, die von einem Positionierungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/ausgestrahlt werden, zu empfangen und decodieren. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) umfassen das globale Positionierungssystem (GPS) der USA, Russlands globales Navigationssystem (GLONASS), das Galileo-System der Europäischen Union, Chinas BeiDou-Navigationssatellitensystem, ein regionales Navigationssystem oder GNSS-Vergrößerungssystem (z. B. Navigation with Indian Constellation (NAVIC), Japans Quasi-Zenith-Satellitensystem (QZSS), Frankreichs Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS) usw.) oder dergleichen. Die Positionierungsschaltungsanordnung 345 weist verschiedene Hardwareelemente (z. B. einschließlich Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen) auf, um mit Komponenten eines Positionierungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. In einigen Ausführungsformen kann die Positionierungsschaltungsanordnung 345 eine IC mit Mikrotechnologie zur Positionierung, Navigation und Zeitsteuerung (Micro-PNT), die einen Master-Zeitgebertakt verwendet, um Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen, aufweisen. Die Positionierungsschaltungsanordnung 345 kann auch Teil der Basisbandschaltungsanordnung 310 und/oder der RFEMs 315 sein oder mit diesen interagieren, um mit den Knoten und Komponenten des Positionierungsnetzwerks zu kommunizieren. Die Positionierungsschaltungsanordnung 345 kann auch Positionsdaten und/oder Zeitdaten der Anwendungsschaltungsanordnung 305 bereitstellen, welche die Daten zum Synchronisieren von Operationen mit verschiedenen anderen Infrastrukturgeräten oder dergleichen verwenden kann.
• Die durch 3 gezeigten Komponenten können unter Verwendung der Schnittstellenschaltungsanordnung 306 oder des Interconnects (IX) 306, welche eine beliebige Anzahl an Bus-Technologien und/oder Interconnect-Technologien (IX-Technologien), wie etwa der Industriestandardarchitektur (ISA), der erweiterten ISA (EISA, Extended ISA), der integrierten Zwischenschaltung (I²C), einer seriellen peripheren Schnittstelle (SPI, Serial Peripheral Interface), Punktzu-Punkt-Schnittstellen, Leistungsverwaltungsbus (PMBus, Power Management Bus), peripheres Komponenten-Interconnect (PCI, Peripheral Component Interconnect), PCI express (PCIe), Intel® Ultra Path Interface (UPI), Intel® Accelerator Link (IAL), Common Application Programming Interface (CAPI), Intel® QuickPath interconnect (QPI), Ultra Path Interconnect (UPI), Intel® Omni-Path Architecture (OPA) IX, RapidIO™-System-IXs, Cache Coherent Interconnect for Accelerators (CCIA), Gen-Z Consortium IXs, Open Coherent Accelerator Processor Interface (OpenCAPI) IX, ein HyperTransport-Interconnect, und/oder eine beliebige Anzahl an anderen IX-Technologien, aufweisen kann, miteinander kommunizieren. Die IX-Technologie kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
• 4 stellt ein Blockdiagramm für eine beispielhafte MEC-Systemarchitektur 400 gemäß verschiedenen Ausführungsformen bereit. MEC bietet Anwendungsentwicklern und Content Providern Cloud-Computing-Fähigkeiten und eine IT-Dienstumgebung am Rand des Netzwerks. Diese Umgebung ist durch eine sehr geringe Latenz und eine hohe Bandbreite sowie Echtzeitzugriff auf Funknetzwerkinformationen, die sich Anwendungen zunutze machen können, gekennzeichnet. Die MEC-Technologie erlaubt einen flexiblen und schnellen Einsatz von innovativen Anwendungen und Diensten für Mobilfunkteilnehmer, Unternehmen und vertikale Segmente. Insbesondere müssen in Bezug auf die Automobilbranche Anwendungen, wie etwa V2X (z. B. IEEE 802.11p-basierte Protokolle, wie etwa DSRC/ITS-G5, oder 3GPP LTE-V2X-basierte Protokolle), Daten austauschen, Daten Aggregationspunkten bereitstellen und auf Daten in Datenbanken zugreifen, welche eine Übersicht der lokalen Situation, die von einer Vielzahl an Sensoren (von verschiedenen Autos, straßenseitigen Einheiten usw.) abgeleitet ist, bereitstellen.
• Die veranschaulichten logischen Verbindungen zwischen verschiedenen Entitäten der MEC-Architektur 400 können zugriffsagnostisch sein und hängen möglicherweise nicht von einem konkreten Einsatz ab. MEC ermöglicht die Implementierung von MEC-Anwendungen (die MEC-Apps) 436-1 und 436-2 (gemeinsam als „MEC-Apps 436“ oder dergleichen bezeichnet) als rein softwarebasierte Entitäten, die auf einer Virtualisierungsinfrastruktur (VI) 438-1 und 438-2 ausgeführt werden (gemeinsam als „VI 438“ oder dergleichen bezeichnet), welche an oder nahe bei dem Netzwerkrand liegt. Eine MEC-App 436 ist eine Anwendung, die auf einem MEC-Host 136 innerhalb des MEC-Systems 400 instantiiert werden kann und möglicherweise MEC-Dienste 437a bereitstellen oder konsumieren kann. Der Begriff „Nutzeranwendung“ im Zusammenhang mit MEC bezieht sich auf eine MEA 436, die in dem MEC-System 400 als Reaktion auf eine Anforderung von einem Nutzer (z. B. das vUE 125) über eine Vorrichtungsanwendung instantiiert wird. 4 zeigt die allgemeinen Entitäten, die beteiligt sind, wobei diese Entitäten in Entitäten auf Mehrfachzugriff-Edge-Systemebene 402, Mehrfachzugriff-Edge-Host-Ebene 401 und Netzwerkebene (nicht gezeigt) gruppiert werden können. Die Mehrfachzugriff-Edge-Host-Ebene 401 weist einen MEC-Host 1 und einen MEC-Host 2 (welche dieselben oder ähnlich wie die MEC-Server 136, die zuvor erläutert wurden, sind, und gemeinsam als „MEC-Host 136“ oder dergleichen bezeichnet werden) und eine Mehrfachzugriff-Edge-Verwaltung (ME-Verwaltung) 430, welche eine Funktionalität zum Ausführen der MEC-Apps 436 innerhalb eines Betreibernetzwerks oder einer Untergruppe eines Betreibernetzwerks bereitstellt, auf. Die Mehrfachzugriff-Edge-System-Ebene 402 weist die Mehrfachzugriff-Edge-System-Ebenenverwaltung 402, das UE 420 (welches dasselbe oder ähnlich wie die Zwischenknoten 120 und/oder die Endpunkte 110, die hierin erläutert sind, ist) und Dritt-Entitäten auf. Die Netzwerkebene (nicht gezeigt) weist verschiedene externe Netzwerkebenenentitäten, wie etwa ein 3GPP-Netzwerk (z. B. das CN 142 von 1), ein lokales Netzwerk (z. B. ein LAN, WLAN, PAN usw.) und ein externes Netzwerk (z. B. das CN 142 und/oder die Cloud 144 von 1) auf. Die Mehrfachzugriff-Edge-Host-Ebene 401 weist die Mehrfachzugriff-Edge-Host-Ebenenverwaltung und einen oder mehrere MEC-Hosts 136 auf. Die Mehrfachzugriff-Edge-Host-Ebenenverwaltung kann verschiedene Komponenten aufweisen, die die Verwaltung der spezifischen Mehrfachzugriff-Edge-Funktionalität einer konkreten MEC-Plattform 437, des MEC-Hosts 136 und der MEC-Apps 436, die auszuführen sind, handhaben. Der MEC-Host 136 weist die MEC-Plattform 437, die MEC-Apps 436 und die VI 438 auf.
• Das MEC-System 400 weist drei Gruppen von Referenzpunkten einschließlich „Mp“-Referenzpunkten bezüglich der Mehrfachzugriff-Edge-Plattformfunktionalität; „Mm“-Referenzpunkten, welche Verwaltungsreferenzpunkte sind; und „Mx“-Referenzpunkten, welche MEC-Entitäten mit externen Entitäten verbinden, auf. Die Schnittstellen/Referenzpunkte in dem MEC-System 400 können IP-basierte Verbindungen aufweisen und können verwendet werden, um Representational State Transfer-Dienste (REST- oder RESTful-Dienste) bereitzustellen, und die Nachrichten, die unter Verwendung der Referenzpunkte/Schnittstellen transportiert werden, können in XML, HTML, JSON oder einem anderen gewünschten Format, wie etwa den hierin erläuterten, vorliegen. Ein geeignetes Authentifizierungs-, Autorisierungs- und Accounting-Protokoll (AAA-Protokoll), wie etwa die Radius- oder Durchmesserprotokolle, kann auch zum Kommunizieren über die Referenzpunkte/Schnittstellen in anderen Ausführungsformen verwendet werden.
• Der MEC-Host 136 ist eine Entität, die eine MEC-Plattform 437 und eine VI 438 enthält, welche Rechen-, Speicher- und Netzwerkressourcen zum Zwecke der Ausführung der MEC-Apps 436 bereitstellt. Jede der VIs 438 weist eine jeweilige Datenebene (DP, Data Plane) 439 (einschließlich der DP 439-1 und der 439-2) auf, die jeweilige Traffic-Regeln 437-1b und 437-2b ausführt (die gemeinsam als „Traffic-Regeln 437b“ bezeichnet werden), die von der MEC-Plattform 437 erhalten werden, und leitet den Traffic unter Anwendungen (z. B. den MEC-Apps 436), den MEC-Diensten 437-1a und 437-2a (gemeinsam als „MEC-Dienste 437a“ bezeichnet), dem DNS-Server/Proxy (siehe z. B. über die DNS-Handhabungsentitäten 437-1c und 437-2c), einem 3 GPP-Netzwerk, lokalen Netzwerken und externen Netzwerken. Die MEC DP 438a kann mit den (R)AN-Knoten 131 und dem CN 142 von 1 verbunden sein und/oder mit dem AP 133 von 1 über ein breiteres Netzwerk, wie etwa das Internet, ein Firmennetzwerk oder dergleichen, verbunden sein. Die anderen Entitäten, die hierin dargestellt und/oder erläutert werden, können dieselben oder ähnlich wie die unter Bezugnahme auf 1 erläuterten sein.
• Die MEC-Plattformen 437-1 und 437-2 (gemeinsam als „MEC-Plattform 437“ oder dergleichen bezeichnet) innerhalb eines MEC-Hosts 136 können eine Sammlung der wesentlichen Funktionalität sein, die benötigt wird, um die MEC-Apps 436 auf einer konkreten VI 438 auszuführen und diesen zu ermöglichen, die MEC-Dienste 437a bereitzustellen und zu konsumieren, und die selbst eine Anzahl an MEC-Diensten 937a bereitstellen können. Die MEC-Plattform 437 kann auch verschiedene Dienste und/oder Funktionen bereitstellen, wie etwa das Anbieten einer Umgebung, wo die MEC-Apps 436 MEC-Dienste 437a (weiter unten erläutert) einschließlich der MEC-Dienste 437a, die über andere Plattformen verfügbar sind, wenn diese unterstützt werden, entdecken, bewerben, konsumieren und anbieten. Die MEC-Plattform 437 kann in der Lage sein, berechtigten MEC-Apps 436 zu erlauben, mit Dritt-Servern zu kommunizieren, die sich in externen Netzwerken befinden. Die MEC-Plattform 437 kann Traffic-Regeln von dem MEC-Plattform-Manager 431, Anwendungen oder Diensten erhalten und die Datenebene entsprechend anweisen (siehe z. B. die Traffic-Regel-Steuerung 437b). Die MEC-Plattform 437 kann Anweisungen zu der DP 438 innerhalb der VI 438 über den Mp2-Referenzpunkt senden. Der Mp2-Referenzpunkt zwischen der MEC-Plattform 437 und der DP 438 der VI 438 kann verwendet werden, um die DP 438 dahingehend anzuweisen, wie der Traffic unter Anwendungen, Netzwerken, Diensten usw. zu leiten ist. Bei einigen Implementierungen kann die MEC-Plattform 437 Tokens, die UEs XP01 in den Traffic-Regeln darstellen, in spezifische IP-Adressen übersetzen. Die MEC-Plattform 437 erhält auch DNS-Aufzeichnungen von dem MEC-Plattform-Manager 431 und konfiguriert dementsprechend einen DNS-Proxy/-Server. Die MEC-Plattform 437 hostet die MEC-Dienste 437a einschließlich der Mehrfachzugriff-Edge-Dienste, die weiter unten erläutert werden, und bietet Zugriff auf Informationen in Bezug auf die Tageszeit und dauerhafte Speicherung. Ferner kann die MEC-Plattform 437 mit anderen MEC-Plattformen 437 anderer MEC-Server 136 über den Mp3-Referenzpunkt kommunizieren.
• Die VI 438 kann die Gesamtheit aller Hardware- und Softwarekomponenten darstellen, welche die Umgebung aufbauen, in welcher die MEC-Apps 436 und/oder die MEC-Plattform 437 eingesetzt, verwaltet und ausgeführt werden. Die VI 438 kann sich über mehrere Standorte erstrecken, und das Netzwerk, das Konnektivität zwischen diesen Standorten bereitstellt, wird als Teil der VI 438 betrachtet. Die physischen Hardwareressourcen der VI 438 umfassen Rechen-, Speicher- und Netzwerkressourcen, die eine Verarbeitung, Speicherung und Konnektivität den MEC-Apps 436 und/oder der MEC-Plattform 437 durch eine Virtualisierungsschicht (z. B. ein Hypervisor, ein VM-Überwacher (VMM, VM Monitor) oder dergleichen) bereitstellen. Die Virtualisierungsschicht kann die physischen Hardwareressourcen des MEC-Servers 136 als eine Hardwareabstraktionsschicht abstrahieren und/oder logisch aufteilen. Die Virtualisierungsschicht kann auch der Software, die die MEC-Apps 436 und/oder die MEC-Plattform 437 implementiert, ermöglichen, die zugrundeliegende VI 438 zu verwenden, und kann virtualisierte Ressourcen den MEC-Apps 436 und/oder der MEC-Plattform 437 bereitstellen, so dass die MEC-Apps 436 und/oder die MEC-Plattform 437 ausgeführt werden können.
• Die MEC-Apps 436 sind Anwendungen, die auf einem MEC-Host/-Server 136 innerhalb des MEC-Systems 400 instantiiert werden können und möglicherweise MEC-Dienste 437a bereitstellen oder konsumieren können. Der Begriff „MEC-Dienst“ bezieht sich auf einen Dienst, der über eine MEC-Plattform 937 entweder von der MEC-Plattform 937 selbst oder von einer MEC-App 936 bereitgestellt wird. Die MEC-Apps 436 können als VM auf der VI 438, die von dem MEC-Server 136 bereitgestellt wird, ausgeführt werden und können mit der MEC-Plattform 437 interagieren, um die MEC-Dienste 437a zu konsumieren und bereitzustellen. Die MEC-Apps 436 werden auf der VI 438 des MEC-Servers 136 basierend auf einer Konfiguration oder Anfragen, die von der ME-Verwaltung 430 validiert werden, instantiiert. In einigen Ausführungsformen können die MEC-Apps 436 auch mit der MEC-Plattform 437 interagieren, um bestimmte Unterstützungsverfahren in Bezug auf den Lebenszyklus der MEC-Apps 436 durchzuführen, wie etwa das Angeben der Verfügbarkeit, das Vorbereiten der Verlagerung des Nutzerzustands usw. Die MEC-Apps 436 können eine bestimmte Anzahl an Regeln und Anforderungen aufweisen, die mit diesen verknüpft sind, wie etwa benötigte Ressourcen, maximale Latenz, benötigte oder nützliche Dienste usw. Diese Anforderungen können von der ME-Verwaltung 430 validiert werden und vorab festgelegten Werten zugewiesen werden, falls diese fehlen. Die MEC-Dienste 437-1a und 437-2a (gemeinsam als „MEC-Dienste 437a“ oder dergleichen bezeichnet) sind Dienste, die von der MEC-Plattform 437 und/oder den MEC-Apps 436 bereitgestellt und/oder konsumiert werden. Die Dienstkonsumenten (z. B. die MEC-Apps 436 und die MEC-Plattform 437) können mit konkreten MEC-Diensten 437a über einzelne APIs (einschließlich MEC V2X API 451-1, 451-2 und verschiedene APIs 453-1, 453-2 in 4) kommunizieren. Wenn er von einer Anwendung bereitgestellt wird, kann ein MEC-Dienst 437a in einer Liste von Diensten in den Dienstregistern 437-ld und 437-2d (gemeinsam als „Dienstregister 437d“ oder dergleichen bezeichnet) für eine jeweilige der MEC-Plattform 437 über den Mp1-Referenzpunkt registriert werden. Zusätzlich können die MEC-Apps 436 an einem oder mehreren Diensten 437a teilnehmen, für welche sie über den Mp1-Referenzpunkt berechtigt sind.
• Das MEC-System 400 kann eine Funktion unterstützen, die UserApps genannt wird. Wenn das MEC-System 400 die Funktion UserApps unterstützt, kann die ME-Verwaltung 430 die Instantiierung der MEC-Apps 436 (oder von Nutzeranwendungen) auf mehreren MEC-Hosts 136 auf eine einzelne Instantiierungsanforderung folgend und, falls dies von dem Betreiber benötigt wird, als Reaktion auf eine Anforderung durch den Nutzer unterstützen. Die Anwendungsinstanz muss möglicherweise eine Anzahl an potentiellen Beschränkungen einhalten, die vorab für die Anwendung 405 definiert werden. Nachdem sie instantiiert ist, kann eine Konnektivität zwischen dem UE 420 und der Anwendungsinstanz hergestellt werden. Potentielle Beschränkungen können die Latenz, den Standort, Rechenressourcen, Speicherressourcen, die Netzwerkfähigkeit, Sicherheitsbedingungen und dergleichen umfassen. Als Teil der Instantiierung der Nutzeranwendung (oder MEC-App 436) wird das MEC-System 400 einen zugehörigen Anwendungskontext erstellen, den das MEC-System 400 während der Lebensdauer der Nutzeranwendung (oder der MEC-App 436) beibehält. Der Anwendungskontext ist ein Satz von Referenzdaten über eine Anwendungsinstanz, die verwendet werden, um sie zu kennzeichnen, Lebenszyklusverwaltungsoperationen zu ermöglichen und sie mit ihrer Vorrichtungsanwendung zu verknüpfen. Der Begriff „Nutzerkontext“ im Kontext von MEC bezieht sich auf anwendungsspezifische Laufzeitdaten, die von einer MEC-App 436 verwaltet werden, welche mit einem Nutzer jener Anwendung verknüpft ist. Der Anwendungskontext enthält Informationen, die für die Anwendungsinstanz spezifisch sind, wie etwa ihre eindeutige Kennung innerhalb des MEC-Systems 400 und die Adresse (z. B. URI oder dergleichen), die für Clients (z. B. das UE 420) bereitgestellt wird, die bezüglich des MEC-Systems 400 extern sind, um mit der Nutzeranwendung zu interagieren.
• Wenn das MEC-System 400 die Funktion UserApps unterstützt, kann das System 400 als Reaktion auf eine Anforderung durch einen Nutzer das Herstellen der Konnektivität zwischen dem UE 420 und einer Instanz einer spezifischen MEC-App 436, die die Anforderungen der MEC-App 436 hinsichtlich des UE 420 unterstützt. Wenn keine Instanz der MEC-App 436, die diese Anforderungen erfüllt, aktuell ausgeführt wird, kann die Mehrfachzugriff-Edge-Systemverwaltung eine neue Instanz der Anwendung 405 auf einem MEC-Host 136 erstellen, die die Anforderungen der Anwendung 405 erfüllt. Nachdem sie instantiiert ist, wird eine Konnektivität zwischen dem UE 420 und der neuen Instanz der MEC-App 436 hergestellt. Anforderungen der Anwendung können die Latenz, den Standort, Rechenressourcen, Speicherressourcen, die Netzwerkfähigkeit, Sicherheitsbedingungen und dergleichen umfassen. Wenn das MEC-System 400 die Funktion UserApps unterstützt, kann das System 400 das On-Boarding der MEC-Apps 436 während der Ausführung einer Instantiierungsanforderung unterstützen, das Herstellen einer Konnektivität zwischen dem UE 420 und einer spezifischen Instanz einer MEC-App 436 erlauben, die Fähigkeit, die Instanz der MEC-App 436 zu beenden, unterstützen, wenn kein UE 420 mehr mit ihr verbunden ist, und die Beendigung der MEC-App 436, die auf mehreren MEC-Servern 136 ausgeführt wird, einer einzelnen Beendigungsanforderung folgend unterstützen.
• Wie durch 4 gezeigt ist, liegt der Mp1-Referenzpunkt zwischen der MEC-Plattform 437 und den MEC-Apps 436. Der Mpl-Referenzpunkt kann die Dienstregistrierung 437d, die Dienstentdeckung und Kommunikationsunterstützung für verschiedene Dienste, wie etwa die MEC-Dienste 437-1a, die von dem MEC-Host 1 bereitgestellt werden, und die MEC-Dienste 437-2a, die von dem MEC-Host 2 bereitgestellt werden (gemeinsam als „MEC-Dienste 437a“ oder dergleichen bezeichnet), bereitstellen. Zusätzlich kann die Mpl-Schnittstelle eine Anwendungsverfügbarkeit, Sitzungszustandsverlagerungsunterstützungsverfahren, Traffic-Regeln- und die Aktivierung von DNS-Regeln, Zugriff auf Informationen in Bezug auf die Tageszeit und dauerhaften Speicher und/oder dergleichen bereitstellen. Der Mp1-Referenzpunkt kann zum Konsumieren und Bereitstellen von dienstspezifischer Funktionalität verwendet werden.
• Beispiele für die MEC-Dienste 437a umfassen den Funknetzwerkinformationsdienst (RNIS, Radio Network Information Service), Standortdienste und Bandbreitenverwaltungsdienste. Der RNIS, wenn verfügbar, stellt berechtigten MEC-Apps 436 funknetzwerkbezogene Informationen zur Verfügung und gibt den MEC-Apps 436 geeignete aktualisierte Funknetzwerkinformationen preis. Die Funknetzwerkinformationen (RNI) können unter anderem Funknetzwerkbedingungen, Mess- und Statistikinformationen bezüglich der Nutzerebene, Informationen bezüglich der UEs 420, die von dem/den Funkknoten bedient werden, die mit dem MEC-Host 136 verknüpft sind (z. B. UE-Kontext und Funkzugriffsträger), Änderungen bezüglich der Informationen in Bezug auf die UEs 420, die von dem/den Funkknoten bedient werden, die mit dem MEC-Host 136 verknüpft sind, und/oder dergleichen. Die RNI können mit der relevanten Granularität (z. B. pro UE 420, pro Zelle, pro Zeitraum) bereitgestellt werden.
• Die Dienstkonsumenten (z. B. die MEC-Apps 436 und die MEC-Plattform 437) können mit dem RNIS über eine RNI API 453 kommunizieren, um Kontextinformationen von einem entsprechenden RAN zu erhalten. Die RNI können den Dienstkonsumenten über einen Zugriffsknoten (z. B. die (R)AN-Knoten 131, 132 oder der AP 133 von 1) bereitgestellt werden. Die RNI API 453 kann sowohl anfrage- als auch teilnahmebasierte (z. B. ein pub/sub) Mechanismen unterstützen, die über eine Representational State Transfer API (RESTful API) 453 oder über einen Message Broker der MEC-Plattform 437 (nicht durch 4 gezeigt) verwendet werden. Eine MEC-App 436 kann Informationen über einen Message Broker über ein Transportinformationsanfrageverfahren abfragen, wobei die Transportinformationen vorab der MEC-App 436 über einen geeigneten Konfigurationsmechanismus bereitgestellt werden können. Die verschiedenen Nachrichten, die über die RNI API 453 kommuniziert werden, können in XML, JSON, Protobuf oder einem anderen geeigneten Format vorliegen.
• Die RNI können von den MEC-Apps 436 und der MEC-Plattform 437 verwendet werden, um die vorhandenen Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktualisierten Informationen über Funkbedingungen basieren. Als ein Beispiel kann eine MEC-App 436 die RNI verwenden, um aktuelle Dienste, wie etwa Videodurchlaufführung, zu optimieren. Bei der Durchlaufführung kann eine Funkanalyse-MEC-App 436 MEC-Dienste verwenden, um einem Backend-Video-Server eine nahe Echtzeitangabe bezüglich des Durchlaufs, der als an der Funk-Downlink-Schnittstelle zu einem nächsten Zeitpunkt verfügbar geschätzt wird, bereitzustellen. Die Durchlaufführungsfunkanalyseanwendung 436 berechnet die Durchlaufführung basierend auf den benötigten Funknetzwerkinformationen, die sie von einem Mehrfachzugriff-Edge-Dienst erhält, der auf dem MEC-Server 136 ausgeführt wird. Die RNI können auch von der MEC-Plattform 437 verwendet werden, um die Mobilitätsverfahren zu optimieren, die benötigt werden, um Dienstkontinuität zu unterstützen, wie etwa, wenn eine bestimmte MEC-App 436 eine einzige Information unter Verwendung eines einfachen Anforderungsantwortmodells (z. B. unter Verwendung von RESTful-Mechanismen) anfordert, während andere MEC-Apps 436 an mehreren verschiedenen Benachrichtigungen bezüglich Informationsänderungen (z. B. unter Verwendung eines pub/sub-Mechanismus und/oder Message Broker-Mechanismen) teilnehmen.
• Die Standortdienste (LS, Location Services) können, wenn sie verfügbar sind, berechtigten MEC-Apps 436 standortbezogene Informationen bereitstellen und solche Informationen den MEC-Apps 436 preisgeben. Mit den standortbezogenen Informationen führen die MEC-Plattform 437 oder eine oder mehrere MEC-Apps 436 eine aktive Vorrichtungsstandortsnachverfolgung, standortbasierte Dienstempfehlungen und/oder sonstige ähnliche Dienste durch. Der LS unterstützt den Standortabrufmechanismus, z. B. wird der Standort nur einmal für jede Standortinformationsanforderung mitgeteilt. Der LS unterstützt einen Standorteilnahmemechanismus, zum Beispiel kann der Standort mehrere Male für jede Standortanforderung periodisch oder basierend auf spezifischen Ereignissen, wie etwa einer Standortänderung, mitgeteilt werden. Die Standortinformationen können unter anderem den Standort von spezifischen UEs 420, die aktuell von dem/den Funkknoten bedient werden, die mit dem MEC-Server 136 verknüpft sind, Informationen über den Standort aller UEs 420, die aktuell von dem/den Funkknoten bedient werden, die mit dem MEC-Server 136 verknüpft sind, Informationen über den Standort einer bestimmten Kategorie der UEs 420, die aktuell von dem/den Funkknoten bedient werden, die mit dem MEC-Server 136 verknüpft sind, eine Liste von UEs 420 an einem konkreten Standort, Informationen über den Standort aller Funkknoten, die aktuell mit dem MEC-Server 136 verknüpft sind, und/oder dergleichen umfassen. Die Standortinformationen können in Form einer Geolokalisierung, einer globalen Navigationssatellitendienstkoordinate (GNSS-Koordinate), einer Zellenidentität (ID) und/oder dergleichen vorliegen. Der LS ist durch die API zugänglich, die in der Spezifikation „RESTful Network API for Zonal Presence“ OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C der Open Mobile Alliance (OMA) definiert ist. Der Zonenpräsenzdienst verwendet das Konzept der „Zone“, wo sich eine Zone dazu eignet, verwendet zu werden, um alle Funkknoten, die mit einem MEC-Host oder einem MEC-Server 136 oder einer Untergruppe davon verknüpft sind, gemäß einem gewünschten Einsatz zu gruppieren. Diesbezüglich stellt die OMA-Zonenpräsenz-API 453 Mittel für die MEC-Apps 436 bereit, um Informationen über eine Zone, die Zugangspunkte, die mit den Zonen verknüpft sind, und die Nutzer, die mit den Zugangspunkten verbunden sind, abzurufen. Zusätzlich erlaubt die OMA-Zonenpräsenz-API 453 einer berechtigten Anwendung, an einem Benachrichtigungsmechanismus teilzunehmen, der über Nutzeraktivitäten innerhalb einer Zone benachrichtigt. In verschiedenen Ausführungsformen kann ein MEC-Server 136 auf Standortinformationen oder Zonenpräsenzinformationen einzelner UEs 420 unter Verwendung der OMA-Zonenpräsenz-API 453 zum Identifizieren des relativen Standorts oder der relativen Positionen der UEs 420 zugreifen.
• Die Bandbreitenverwaltungsdienste (BWMS, Bandwidth Management Services) stellen die Zuweisung der Bandbreite zu bestimmtem Traffic, der zu und von den MEC-Apps 436 geleitet wird, bereit und spezifizieren statische/dynamische Aufwärts-/Abwärtsbandbreitenressourcen einschließlich der Bandbreitengröße und der Bandbreitenpriorität. Die MEC-Apps 436 können die BWMS verwenden, um Bandbreiteninformationen zu/von der MEC-Plattform 437 zu aktualisieren/empfangen. In einigen Ausführungsformen können verschiedene MEC-Apps 436, die parallel auf demselben MEC-Server 136 ausgeführt werden, spezifischen statischen, dynamischen Aufwärts-/Abwärtsbandbreitenressourcen einschließlich der Bandbreitengröße und der Bandbreitenpriorität zugewiesen werden. Die BWMS weisen eine Bandbreitenverwaltungs-API (BWM API, Bandwidth Management API) 453a auf, um registrierten Anwendungen zu erlauben, sich statisch und/oder dynamisch für spezifische Bandbreitenzuweisungen pro Sitzung/Anwendung zu registrieren. Die BWM API 453 weist HTTP-Protokollverbindungen für BWM-Funktionalität unter Verwendung von RESTful-Diensten oder einem anderen geeigneten API-Mechanismus auf.
• Erneut unter Bezugnahme auf 4 umfasst die Mehrfachzugriff-Edge-Verwaltung Mehrfachzugriff-Edge-Systemebenenverwaltung und die Mehrfachzugriff-Edge-Host-Ebenenverwaltung 430. Die ME-Verwaltung 430 weist den MEC-Plattform-Manager 431 und den VI-Manager (VIM) 432 auf und handhabt die Verwaltung der MEC-spezifischen Funktionalität eines konkreten MEC-Servers 136 und der Anwendungen, die auf diesem ausgeführt werden. Bei einigen Implementierungen können einige oder alle der Mehrfachzugriff-Edge-Verwaltungskomponenten von einem oder mehreren Servern implementiert werden, die sich in einem oder mehreren Datenzentren befinden, und eine Virtualisierungsinfrastruktur verwenden, die mit der Netzwerkfunktionsvirtualisierungsinfrastruktur (NFV-Infrastruktur) verbunden ist, die verwendet wird, um Kernnetzwerkelemente zu virtualisieren, oder unter Verwendung derselben Hardware wie die NFV-Infrastruktur.
• Der MEC-Plattform-Manager 431 ist für die Verwaltung des Lebenszyklus von Anwendungen einschließlich des Informierens des Mehrfachzugriff-Edge-Orchestrators (MEC-O) 421 über relevante anwendungsbezogene Ereignisse zuständig. Der MEC-Plattform-Manager 431 kann auch MEP-Element-Verwaltungsfunktionen 431a der MEC-Plattform 437 bereitstellen, MEC-App-Regeln und -anforderungen 431b einschließlich Dienstautorisierungen, Traffic-Regeln, DNS-Konfiguration und Lösen von Konflikten verwalten und Lebenszyklen der MEC-App 436 (MEALC-Verwaltung 431c) verwalten. Der MEC-Plattform-Manager 431 kann auch Fehlerberichte zu virtualisierten Ressourcen und Leistungsmessungen von dem VIM 432 zur weiteren Verarbeitung erhalten. Der Mm5-Referenzpunkt zwischen dem MEC-Plattform-Manager 431 und der MEC-Plattform 437 wird verwendet, um eine Plattformkonfiguration, eine Konfiguration der MEPE-Verwaltung 431a, der MERR-Verwaltung 431b, der MEALC-Verwaltung 431c, der Verwaltung der Anwendungsverlagerung usw. durchzuführen.
• Der VIM 432 kann eine Entität sein, die virtualisierte Ressourcen (Rechen-, Speicher- und Vernetzungsressourcen) der VI 438 zuweist, verwaltet und freigibt, und die VI 438 vorbereitet, um ein Softwarebild auszuführen. Dazu kann der VIM 432 mit der VI 438 über den Mm7-Referenzpunkt zwischen dem VIM 432 und der VI 438 kommunizieren. Das Vorbereiten der VI 438 kann das Konfigurieren der VI 438 und Erhalten/Speichern des Softwarebilds umfassen. Wenn es unterstützt wird, kann der VIM 432 eine schnelle Bereitstellung von Anwendungen bereitstellen, wie etwa in „Openstack++ for Cloudlet Deployments“ beschrieben ist, das auf http://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf verfügbar ist. Der VIM 432 kann auch Leistungs- und Fehlerinformationen über die virtualisierten Ressourcen sammeln und mitteilen und eine Anwendungsverlagerung durchführen, wenn dies unterstützt wird. Zur Anwendungsverlagerung von/zu externen Cloud-Umgebungen kann der VIM 432 mit einem externen Cloud-Manager interagieren, um die Anwendungsverlagerung durchzuführen, zum Beispiel unter Verwendung des Mechanismus, der in „Adaptive VM Handoff Across Cloudlets“ beschrieben ist, und/oder möglicherweise durch einen Proxy. Ferner kann der VIM 432 mit dem MEC-Plattform-Manager 431 über den Mm6-Referenzpunkt kommunizieren, welcher verwendet werden kann, um virtualisierte Ressourcen zu verwalten, um zum Beispiel die Anwendungslebenszyklusverwaltung zu realisieren. Ferner kann der VIM 432 mit dem MEC-O 421 über den Mm4-Referenzpunkt kommunizieren, welcher verwendet werden kann, um virtualisierte Ressourcen des MEC-Servers 136 zu verwalten und Anwendungsbilder zu verwalten. Das Verwalten der virtualisierten Ressourcen kann das Nachverfolgen der verfügbaren Ressourcenkapazität usw. umfassen.
• Die Mehrfachzugriff-Edge-Systemebenenverwaltung weist den MEC-O 421 als eine Kernkomponente auf, welcher eine Übersicht des gesamten MEC-Systems 400 aufweist. Der MEC-O 421 kann eine Übersicht des MEC-Systems 400 basierend auf den eingesetzten Mehrfachzugriff-Edge-Hosts 901, den verfügbaren Ressourcen, den verfügbaren MEC-Diensten 437a und der Topologie beibehalten. Der Mm3-Referenzpunkt zwischen dem MEC-O 421 und dem MEC-Plattform-Manager 431 kann für die Verwaltung des Anwendungslebenszyklus, der Anwendungsregeln und -anforderungen und dem Nachverfolgen der verfügbaren MEC-Dienste 437a verwendet werden. Der MEC-O 421 kann mit dem Nutzeranwendungslebenszyklusverwaltungsproxy (UALMP, User Application Lifecycle Management Proxy) 425 über den Mm9-Referenzpunkt kommunizieren, um die MEC-Apps 436 zu verwalten, die von der UE-Anwendung 405 angefordert werden.
• Der MEC-O 421 kann auch für das On-Boarding von Anwendungspackages einschließlich des Überprüfens der Integrität und Authentizität der Packages, des Validierens von Anwendungsregeln und -anforderungen und, falls notwendig, des Anpassens von diesen, um Betreiberrichtlinien zu entsprechen, das Führen einer Aufzeichnung von on-geboardeten Packages und das Vorbereiten des/der VIM(s) 402 zum Handhaben der Anwendungen zuständig sein. Der MEC-O 421 kann (einen) geeignete(n) MEC-Host(s) 901 zur Anwendungsinstantiierung basierend auf Beschränkungen, wie etwa Latenz, verfügbare Ressourcen und verfügbare Dienste, auswählen. Der MEC-O 421 kann auch eine Anwendungsinstantiierung und -beendigung auslösen und eine Anwendungsverlagerung auslösen, wenn dies benötigt und unterstützt wird.
• Das Operationsunterstützungssystem (OSS, Operations Support System) 422 bezieht sich auf das OSS eines Betreibers, der Anforderungen über das Customer Facing Service Portal (CFS-Portal) 406 (und über den Mxl-Referenzpunkt) und von UE-Anwendungen 405 zur Instantiierung oder Beendigung der MEC-Apps 436 erhält und hinsichtlich der Gewährung dieser Anforderungen entscheidet. Das CFS-Portal 406 (und die Mx1-Schnittstelle) können von Dritten verwendet werden, um das MEC-System 400 aufzufordern, die Anwendungen 406 in dem MEC-System 400 auszuführen. Die gewährten Anforderungen können zur weiteren Verarbeitung zu dem MEC-O 421 weitergeleitet werden. Wenn dies unterstützt wird, erhält das OSS 422 auch Anforderungen von den UE-Anwendungen 405 bezüglich des Verlagerns von Anwendungen zwischen externen Clouds und dem MEC-System 400. Der Mm2-Referenzpunkt zwischen dem OSS 422 und dem MEC-Plattform-Manager 431 wird für die Konfiguration, die Fehler- und Leistungsverwaltung des MEC-Plattform-Managers 431 verwendet. Der Mm1-Referenzpunkt zwischen dem MEC-O 421 und dem OSS 422 wird zum Auslösen der Instantiierung und der Beendigung der Mehrfachzugriff-Edge-Anwendungen 436 in dem MEC-System 400 verwendet.
• Die UE-App(s) 405 (auch als „Vorrichtungsanwendungen“ oder dergleichen bezeichnet) ist/sind eine oder mehrere Anwendungen, die in einer Vorrichtung, einem Rechensystem usw. (z. B. das UE 420) ausgeführt werden, die bzw. das die Fähigkeit aufweist, mit dem MEC-System 900 über den Nutzeranwendungslebenszyklusverwaltungsproxy 425 zu interagieren. Die UE-App(s) 405 kann/können eine oder mehrere Client-Anwendungen sein, diese umfassen oder mit diesen interagieren, welche im Zusammenhang mit MEC eine Anwendungssoftware sind, die auf einer Vorrichtung, einem Rechensystem usw. ausgeführt wird, die eine Funktionalität verwenden, die von einer oder mehreren spezifischen MEC-Anwendung(en) 436 bereitgestellt wird. Der Nutzeranwendungslebenszkylusverwaltungsproxy („Nutzer-App-LCM-Proxy“) 425 kann Anforderungen von den UE-Anwendungen 405 in dem UE autorisieren und interagiert mit dem OSS 422 und dem MEC-O 421 zur weiteren Verarbeitung dieser Anforderungen. Der Begriff „Lebenszyklusverwaltung“ im Kontext von MEC bezieht sich auf eine Gruppe von Funktionen, die zum Verwalten der Instantiierung, Verwaltung und Beendigung einer Instanz der MEC-Anwendung 436 benötigt werden. Der Nutzerapp-LCM-Proxy 425 kann mit dem OSS 422 über den Mm8-Referenzpunkt interagieren und wird verwendet, um Anforderungen der UE-Anwendungen 405 in Bezug auf das Ausführen von Anwendungen in dem MEC-System 400 handzuhaben. Eine Nutzeranwendung 405 kann eine MEC-App 436 sein, die in dem MEC-System 400 instantiiert wird als Reaktion auf eine Anforderung eines Nutzers über eine Anwendung, die in dem UE 420 läuft (z. B. die UE-Anwendung 405). Der Nutzer-App-LCM-Proxy 425 erlaubt den UE-Anwendungen 405, ein On-Boarding, eine Instantiierung, eine Beendigung von Nutzeranwendungen, und wenn diese unterstützt werden, eine Verlagerung von Nutzeranwendungen in und aus dem MEC-System 400 heraus anzufordern. Er erlaubt auch das Informieren der UE-Anwendungen 405 hinsichtlich des Zustands der Nutzeranwendungen 405. Der Nutzerapp-LCM-Proxy 425 ist nur von innerhalb des mobilen Netzwerks aus zugänglich und ist möglicherweise nur verfügbar, wenn er von dem MEC-System 400 unterstützt wird. Eine UE-Anwendung 405 kann den Mx2-Referenzpunkt zwischen dem Nutzer-App-LCM-Proxy 425 und der UE-Anwendung 405 zum Auffordern des MEC-Systems 400, eine Anwendung in dem MEC-System 400 auszuführen oder eine Anwendung in oder aus dem MEC-System 400 heraus zu bewegen, verwenden. Der Mx2-Referenzpunkt ist möglicherweise nur innerhalb des mobilen Netzwerks zugänglich und ist möglicherweise nur verfügbar, wenn er von dem Mehrfachzugriff-Edge-System unterstützt wird.
• Um eine MEC-App 436 in dem MEC-System 400 auszuführen, erhält der MEC-O 421 Anforderungen, die von dem OSS 422, einem Dritten, oder einer UE-Anwendung 405 ausgelöst werden. Als Reaktion auf den Erhalt solcher Aufforderungen wählt der MEC-O 421 einen MEC-Server 136 aus, um die MEC-App 436 zur Rechenabgabe zu hosten. Diese Aufforderungen können Informationen über die Anwendung, die auszuführen ist, und möglicherweise andere Informationen, wie etwa den Standort, wo die Anwendung aktiv sein muss, andere Anwendungsregeln und -anforderungen, sowie den Standort des Anwendungsbilds, wenn er noch nicht in dem MEC-System 400 on-geboardet ist, umfassen.
• In verschiedenen Ausführungsformen wählt die MEC-O 421 einen oder mehrere MEC-Server 136 für rechenintensive Aufgaben aus. Der ausgewählte eine oder die ausgewählten mehreren MEC-Server 136 können Rechenaufgaben einer UE-Anwendung 405 basierend auf verschiedenen Betriebsparametern, wie etwa Netzwerkfähigkeiten und -bedingungen, Rechenfähigkeiten und -bedingungen, Anwendungsanforderungen und/oder sonstigen ähnlichen Betriebsparametern abgeben. Die Anwendungsanforderungen können Regeln und Anforderungen sein, die mit einer oder mehreren MEC-Apps 436 verknüpft sind, wie etwa das Einsatzmodell der Anwendung (z. B. ob es sich um eine Instanz pro Nutzer, eine Instanz pro Host, eine Instanz auf jedem Host usw. handelt); benötigte virtualisierte Ressourcen (z. B. Rechen-, Speicher-, Netzwerkressourcen einschließlich spezifischer Hardwareunterstützung); Latenzanforderungen (z. B. maximale Latenz, wie streng die Latenzbeschränkungen sind, Latenzfairness zwischen Nutzern); Anforderungen in Bezug auf den Standort; Mehrfachzugriff-Edge-Dienste, die benötigt werden und/oder nützlich sind, damit die MEC-Apps 436 ausgeführt werden können; Mehrfachzugriff-Edge-Dienste, die sich die MEC-Apps 436 zunutze machen können, falls verfügbar; Konnektivitäts- oder Mobilitätsunterstützung/-anforderungen (z. B. Anwendungszustandsverlagerung, Anwendungsinstanzverlagerung); benötigte Mehrfachzugriff-Edge-Funktionen, wie etwa VM-Verlagerungsunterstützung oder UE-Identität; benötigte Netzwerkkonnektivität (z. B. Konnektivität mit Anwendungen innerhalb des Mehrfachzugriff-Edge-Systems, Konnektivität mit lokalen Netzwerken oder mit dem Internet); Informationen über den MEC-System-Einsatz oder Mobilnetzwerkeinsatz des Betreibers (z. B. Topologie, Kosten); Anforderungen bezüglich des Zugriffs auf Nutzer-Traffic; Anforderungen bezüglich der dauerhaften Speicherung; Traffic-Regeln 437b; DNS-Regeln 437c; usw.
• Der MEC-O 421 berücksichtigt die Anforderungen und Informationen, die zuvor aufgelistet wurden, und Informationen bezüglich der Ressourcen, die aktuell in dem MEC-System 400 verfügbar sind, um einen oder mehrere MEC-Server 136 innerhalb des MEC-Systems 901 auszuwählen, um die MEC-Apps 436 zu hosten und/oder zur Rechenabgabe. Nachdem ein oder mehrere MEC-Server 136 ausgewählt sind, fordert der MEC-O 421 den oder die ausgewählten MEC-Host(s) 901 auf, die Anwendung(en) oder Anwendungsaufgaben zu instantiieren. Der tatsächliche Algorithmus, der verwendet wird, um die MEC-Server 136 auszuwählen, hängt von der Implementierung, Konfiguration und/oder dem Betreibereinsatz ab. In verschiedenen Ausführungsformen kann der Auswahlalgorithmus auf den Aufgabenabgabeausführungsformen basieren, die hierin erläutert sind, zum Beispiel unter Berücksichtigung von Netzwerk-, Rechen- und Energieverbrauchsanforderungen zum Durchführen von Aufgaben von Anwendungsaufgaben, sowie Netzwerkfunktionalitäten, Verarbeitung und Abgabe von Codierung/Codierungen oder Unterscheidung von Traffic zwischen verschiedenen RATs. Unter gewissen Umständen (z. B. UE-Mobilitätsereignisse, die zu erhöhter Latenz, Lastausgleichsentscheidungen usw. führen), und falls dies unterstützt wird, kann der MEC-O 421 entscheiden, einen oder mehrere neue MEC-Server 136 auszuwählen, um als ein Master-Knoten zu agieren, und initiiert er die Übertragung einer Anwendungsinstanz oder von anwendungsbezogenen Zustandsinformationen von dem einen oder den mehreren Quell-MEC-Servern 136 zu dem einen oder den mehreren Ziel-MEC-Servern 136.
• Zusätzlich bietet die MEC-System-Architektur 400 auch Unterstützung für Anwendungen. In dem Kontext von 4 ist die UE-App 405 eine Anwendungsinstanz, die auf einem Fahrzeug oder einem vUE 420 ausgeführt wird und V2X-Dienst von dem System anfordert. Die MEC-Hosts 136 befinden sich an derselben Stelle wie die Edge-Infrastruktur (z. B. die RSUs 632a-c von 6) und kommunizieren durch die Mp3-Schnittstelle miteinander. Das Beispiel von 4 verwendet auch V2X-Informationsdienste (VIS, V2X Information Services) 452-1 und 452-1 (gemeinsam als „MEC VIS 452“ bezeichnet). 4 ist ein Beispiel für Anwendungsinstanzen in einem V2X-Dienst mit der MEC V2X API 451a und 451b (gemeinsam als „MEC V2X API 451“ bezeichnet). Im Rahmen von V2X-Diensten hostet ein Fahrzeug-UE 420 eine Client-Anwendung und ist mit einem bestimmten MEC-Host 136 (und einer verbundenen MEC-App 436) verbunden. Wenn mehrere MEC-Hosts/-Server 136 vorhanden sind, erlauben die VIS 452, Informationen zwischen MEC-Apps 436, die auf unterschiedlichen MEC-Hosts 136 ausgeführt werden, preiszugeben. Zusätzlich können andere entfernte Anwendungsserverinstanzen an einer anderen Stelle liegen (z. B. private Clouds, die der Betreiber oder der OEM besitzt, wie etwa die Cloud 144). Der VIS 452 kann von der MEC-Plattform 437 oder von den MEC-Apps 436 produziert werden.
• Insbesondere erlaubt der VIS 452 Informationspreisgabe, die der Unterstützung von Automobilnutzfällen entspricht, gegenüber MEC-Anwendungsinstanzen. Der VIS 452 erlaubt auch einem einzelnen V2X/ITS-Betreiber, (einen) V2X-Dienst(e) über eine Region anzubieten, die verschiedene Länder umfassen und mehrere Netzwerkbetreiber, MEC-Systeme 400 und Anbieter von MEC-Apps 436 beinhalten kann. Zu diesem Zweck weist der MEC VIS 452 folgende Funktionalitäten auf.
• In einigen Aspekten kann die MEC-Plattform 437 eine MEC V2X API 451 aufweisen und den MEC VIS 452 bereitstellen, welcher die folgenden Funktionalitäten aufweisen kann: (a) Erhalten von PC5 V2X-relevanten Informationen von dem 3 GPP-Netzwerk zum Durchführen von UE-Autorisierung für V2X-Kommunikationen (z. B. das Erhalten einer Liste von V2X-berechtigten UEs 420, Erhalten von relevanten Informationen über die Berechtigung basierend auf der UE-Teilnahme, und Erhalten von V2X-Konfigurationsparametern, wie etwa ein gemeinsamer Satz von V2X-Konfigurationsparametern, welcher PC5-Konfigurationsparameter aufweisen kann); (b) Preisgeben der Informationen, die in (a) erhalten werden, gegenüber den MEC-Apps 436 in demselben Host oder MEC-Apps in anderen MEC-Hosts; (c) Ermöglichen der MEC-Apps 436, sicher mit den V2X-bezogenen 3GPP-Kernnetzwerklogikfunktionen zu kommunizieren (z. B. Ermöglichen einer Kommunikation zwischen dem MEC-Host und einer V2X-Steuerfunktion in dem Kernnetzwerk); (d) Ermöglichen der MEC-Apps 436 in verschiedenen MEC-Systemen 400, sicher miteinander zu kommunizieren; und (e) Erhalten und Verarbeiten von Informationen, die in anderen MEC APIs 453 verfügbar sind (z. B. Erhalten und Verarbeiten von Informationen, die von einer RNI API, Standort-API, WLAN-API und sonstigen APIs, die innerhalb der MEC-Plattform 437 implementiert werden können, erhalten werden), um Funknetzwerkkonkurrenz vorherzusagen und dem UE 420 geeignete Benachrichtigungen bereitzustellen.
• Aus dieser Perspektive ist der VIS 452 relevant für die Mp1- und Mp3-Referenzpunkte in der MEC-Architektur 400. Insbesondere werden die relevanten Informationen gegenüber den MEC-Apps 436 über den Mp1-Referenzpunkt preisgegeben und kann der Mp3-Referenzpunkt die Möglichkeit bieten, diese Informationen zwischen verschiedenen MEC-Plattformen 437 zu übertragen. Die MEC V2X API 451 stellt den MEC-Apps 436 auf eine standardisierte Art Informationen zur Verfügung, welche eine Interoperabilität in Mehrfachanbieterszenarien bereitstellen. Nichtsdestotrotz können die MEC-Apps 436 auf direktem Wege (z. B. ohne die Verwendung der MEC-Plattform 437) kommunizieren. Es kann eine Kommunikation zwischen Systemen zwischen den MEC-Orchestratoren 421 realisiert werden. Als Alternative oder zusätzlich dazu können mögliche Mp3-Verbesserungen (oder neue Referenzpunkte zwischen den MEC-Systemen 400) definiert werden.
• In einigen Aspekten kann der MEC-Host 2 in 4 auch eine MEC V2X API 451-2 implementieren, welche einer oder mehreren der Apps, die innerhalb des MEC-Hosts 2 instantiiert werden, wie etwa der MEC-App 436-2b, eine Schnittstelle bereitstellen kann. Diesbezüglich können der MEC-Host 1 und der MEC-Host 2 über die Mp3-Schnittstelle sowie die MEC V2X APIs 451-1, 451-2 miteinander kommunizieren. Zusätzlich können eine oder mehrere der MEC-Apps 436-1, die innerhalb des MEC-Hosts 1 instantiiert werden, mit einer oder mehreren der MEC-Apps 436-2, die innerhalb des MEC-Hosts 2 instantiiert werden, über die MEC V2X APIs 451-1, 451-2 sowie die Mp3-Schnittstelle zwischen dem MEC-Host 1 und dem MEC-Host 2 kommunizieren.
• In einigen Aspekten kann jeder der MEC-Hosts 136 von einem anderen Mobildienstbetreiber besessen/verwaltet werden (während er direkt von einem MEC-Anbieter oder einem Dritten betrieben werden kann). In einigen Aspekten können die MEC-Apps 436, die auf dem MEC-Host 1 und dem MEC-Host 2 instantiiert werden, verwendet werden, um V2X-bezogene Dienste bereitzustellen, und können von dem Mobildienstbetreiber, von einem MEC-Anbieter oder von einem Dritten (z. B. OEM oder OEM-Lieferant oder Systemintegrator) betrieben werden.
• In einigen Aspekten können die MEC V2X APIs 451 als ein allgemeiner Middleware-Dienst bereitgestellt werden, der Informationen liefert, die von Fahrzeugen und sonstigen V2X-Elementen erhalten werden, und als ein Dienst innerhalb der Hosts (z. B. als eine RESTful API) für die höheren Schichten (z. B. die MEC-Apps, die innerhalb der Hosts instantiiert werden) offengelegt werden. In einigen Aspekten können die MEC V2X APIs 451 konfiguriert sein, um Informationen und Daten von Sensoren zu erhalten. Diesbezüglich stellt der Einsatz der MEC V2X APIs 451 die Kontinuität des Dienstes über verschiedene mobile Netzwerke für denselben OEM (z. B. Automobilhersteller) sicher. Wenn eine Standardimplementierung einer V2X API 451 eingeführt wird (z. B. durch ETSI MEC), kann diese Funktionalität dieselben grundlegenden V2X-Dienstmerkmale für alle OEMs in einem 5G-Kommunikationssystem mit MEC-Funktionalitäten sicherstellen.
• In einigen Aspekten können die MEC-App 436a und die MEC-App 436b die entsprechenden MEC V2X APIs 451 verwenden, um Informationen von dem 3GPP-Netzwerk abzurufen. In einigen Aspekten können die MEC-Apps 436 konfiguriert werden, um V2X-Konfigurationsparameter, wie etwa PC5-Konfigurationsparameter (oder eine gemeinsame Gruppe von V2X-Konfigurationsparametern, die innerhalb einer Mehrfach-PLMN-Kommunikationsumgebung verfügbar sein können), zu hosten. Die Verfügbarkeit dieser V2X-Konfigurationsparameter auch bei fehlender Netzabdeckung wird durch die Verwendung einer Mp3-Schnittstelle (oder einer anderen Art von Schnittstelle) zwischen den Hosts sichergestellt. In einigen Aspekten kann die MEC-App 436-1 konfiguriert sein, um sich mit dem MEC-Host 2 (durch die V2X MEC API 451-2 in dem MEC-Host 2) zu verbinden, und kann die MEC-App 436-2 konfiguriert sein, um sich mit dem MEC-Host 1 (durch die V2X MEC API 451-1 in dem MEC-Host 1) zu verbinden. Im Falle einer Mehrfachbetreiberarchitektur können mehrere MEC-Hosts konfiguriert werden, um über die MEC V2X APIs 451 miteinander zu kommunizieren und synchronisiert zu werden, um die relevanten V2X-Konfigurationsparameter zu übertragen, so dass sie über die Mehrfachbetreiberarchitektur bei fehlender zellulärer Abdeckung (z. B. außerhalb der 3GPP-Domäne) verfügbar sein können. Dadurch kann ein UE 420 Zugriff auf V2X-Konfigurationsparameter haben, selbst wenn sich das UE nicht unter der Abdeckung seines 3GPP-Netzwerks befindet.
• In einigen Aspekten können eine oder mehrere ME-Apps innerhalb eines MEC-Hosts 136 instantiiert werden, um Funktionalitäten einer V2X-Anwendungsfunktion durchzuführen, welche das Bereitstellen des VIS 452 umfassen können. Zusätzlich können die MEC-Hosts die MEC V2X APIs 451 verwenden, um verschiedene V2X-Funktionen oder Funktionen des VIS 452 durchzuführen. Insbesondere können eine oder mehrere ME-Apps innerhalb eines MEC-Hosts instantiiert werden, um Funktionalitäten durchzuführen, die mit einer V2X-Anwendungsfunktion verknüpft sind. In einigen Aspekten können diese ME-Apps konfiguriert sein, um die folgenden V2X-Anwendungsfunktionen durchzuführen: Erhalten von V2X-Teilnahmeinformationen für ein vUE 420, Bestimmen, ob das vUE 420 berechtigt ist, um V2X-Kommunikationen als Reaktion auf eine Anforderung in Bezug auf V2X-Dienste durchzuführen, Mitteilen von V2X-Konfigurationsparametern, wie etwa ein gemeinsamer Satz von V2X-Konfigurationsparametern, und so weiter.
• 5 veranschaulicht ein Szenario 500, das mehrere Kanäle aufweist, die für V2X-Kommunikationen verfügbar sind. Wie hierin erläutert wird, behandeln die vorliegenden Techniken das Problem, über mehrere lizenzfreie V2X-Kommunikationskanäle in dem 5,9 GHz-Band, zum Beispiel drei 10 MHz-Kanäle für sicherheitsbezogene Anwendungen, wie durch 5 gezeigt ist, zu verfügen.
• Wie zuvor angeführt wurde, müssen mindestens zwei verschiedene V2X-Technologien (oder V2X RATs) in den verfügbaren Kanälen koexistieren. Wenngleich 5 drei V2X-Kanäle zeigt, kann eine beliebige Anzahl an Kanälen für eine beliebige Anzahl an V2X-Technologien verwendet werden. In einem Beispiel umfassen die mindestens zwei verschiedenen V2X-Technologien IEEE 802.11p-basierte V2X-Technologien (z. B. DSRC für die USA und ITS-G5 für Europa) und 3GPP LTE C-V2X. Diese V2X-Technologien sind nicht ausgelegt, um miteinander zu interagieren und zu koexistieren.
• Ein Koexistenzansatz ist der Ansatz des „bevorzugten Kanals“, welcher das dynamische Zuweisen eines ersten Kanals (z. B. Kanal 1 in 5), der exklusiv von einer V2X RAT (z. B. LTE C-V2X) zu verwenden ist, und Zuweisen eines zweiten Kanals (z. B. Kanal 3 in 5), der exklusiv von einer anderen V2X RAT (z. B. DSRC/ITS-G5) zu verwenden ist, beinhaltet. Ein anderer Koexistenzansatz ist der „Co-Kanal-Existenz“-Ansatz, welcher das Zuweisen beider Systeme zu einem Kanal (z. B. Kanal 2 in 5) während verschiedenen Zeitschlitzen, zum Beispiel das Zuweisen des Kanals, der von einer V2X RAT (z. B. LTE C-V2X) während eines ersten Zeitraums zu verwenden ist, und das Zuweisen des Kanals, der von einer anderen V2X RAT (z. B. DSRC/ITS-G5) während eines zweiten Zeitraums zu verwenden ist, beinhaltet. Es hat sich jedoch gezeigt, dass der Betrieb der mindestens zwei V2X-Technologien in demselben Kanal (Co-Kanal-Koexistenz) sehr ineffizient ist. Ferner kann der Bedarf an Spektralressourcen für eine der V2X-Technologien über einen geographischen Bereich und die Zeit deutlich variieren. Zum Beispiel können einige Länder eine konkrete V2X-Technologie früher als andere einführen oder sind in einigen Bereichen Fahrzeuge mit einer V2X-Technologie ausgestattet und andere Fahrzeuge mit einer anderen V2X-Technologie ausgestattet.
• In diesem Zusammenhang stellt die vorliegende Offenbarung zwei alternative Ausführungsformen bereit. In einer ersten Ausführungsform erkennt die Edge-Infrastrukturausrüstung (z. B. eine oder mehrere RSUs 632a-c von 6) die Art von V2X RAT(s), die von Fahrzeugen (z. B. den vUEs 61a-b von 6) in jeweiligen Abdeckungsbereichen verwendet werden. In dieser Ausführungsform misst die Edge-Infrastrukturausrüstung die Signalisierung, die in ihrem Abdeckungsbereich stattfindet, und bestimmt die Anzahl an Fahrzeugen, die eine erste V2X RAT verwenden, die Anzahl an Fahrzeugen, die eine zweite V2X RAT verwenden, und so weiter, bis zu der Anzahl an Fahrzeugen, die eine N-te V2X RAT unterstützen, wobei N eine Zahl ist. Zum Beispiel kann die Edge-Infrastrukturausrüstung Sidelink-Kommunikationen beobachten oder messen, die von Fahrzeugen in ihren jeweiligen Abdeckungsbereichen ausgehen, und kann die betroffene Edge-Infrastrukturausrüstung annehmen, dass eine beliebige V2X RAT, die von Fahrzeugen für Sidelink-Kommunikationen verwendet wird, auch von der Edge-Infrastrukturausrüstung selbst unterstützt werden sollte. Dieses Beispiel ist in Szenario 700 von 7 veranschaulicht. Ein anderes Beispiel der ersten Ausführungsform ist bezüglich 8 gezeigt und beschrieben.
• In einer zweiten Ausführungsform fordern Fahrzeuge Unterstützung für eine spezifische V2X-Technologie/RAT an. In dieser Ausführungsform geht die Edge-Infrastruktur-Ausrüstung oder das zelluläre Zielnetzwerk, die die Anforderungen erhalten, näher auf die Anforderungen ein, um das System geeignet zu konfigurieren, und bestätigen den Erhalt der Anforderung mit einer geeigneten Nachricht an das Fahrzeug. In einem Beispiel können die Fahrzeuge, die sich durch die jeweiligen Abdeckungsbereiche fortbewegen, die konkreten V2X RATs mitteilen, die sie unterstützen, zum Beispiel UE-Fähigkeitsinformationen während eines Registrierungs- oder Verbindungsverfahrens mit einem zellulären Netzwerk (z. B. das CN 142 von 1), und kann die Edge-Infrastrukturausrüstung diese Informationen von dem zellulären Netzwerk erhalten. Ein Beispiel der zweiten Ausführungsform ist bezüglich 9 gezeigt und beschrieben.
• In jeder Ausführungsform interagiert die Edge-Infrastrukturausrüstung mit der benachbarten Edge-Infrastrukturausrüstung (z. B. direkt oder über Edge-Server), (dem) zellulären Netzwerk(en) (z. B. das CN 142 von 1) und/oder einem Cloud-Computing-Dienst (z. B. die Cloud 144 von 1), um Konfigurationsinformationen bezüglich V2X RAT-Unterstützung und/oder Ressourcenzuweisungen zu teilen.
• Entweder in der ersten Ausführungsform oder der zweiten Ausführungsform unterstützt die Edge-Infrastrukturausrüstung möglicherweise nur die V2X RATs, die lokal benötigt werden. Wenn sich zum Beispiel nur DSRC/ITS-G5-vUEs lokal auf der Straße befinden, dann wird die Edge-Infrastrukturausrüstung konfiguriert werden, um nur DSRC/ITS-G5-Ressourcen bereitzustellen/zu unterstützen. Wenn sich in einem anderen Beispiel nur LTE C-V2X-vUEs lokal auf der Straße befinden, dann wird die Edge-Infrastrukturausrüstung konfiguriert werden, um nur C-V2X-Ressourcen bereitzustellen/zu unterstützen. In jeder Ausführungsform wird, wenn vUEs vorhanden sind, die unterschiedliche V2X RATs auf der Straße unterstützen (z. B. ein oder mehrere vUEs, die DSRC/ITS-G5 unterstützen, und mindestens ein anderes vUE, das LTE C-V2X unterstützt), dann die Edge-Infrastrukturausrüstung konfiguriert werden, um jede der V2X RATs im Verhältnis zu der Menge an Ressourcen, die zum Aufnehmen der Kommunikationen benötigt werden, unter Verwendung der unterschiedlichen V2X RATs bereitzustellen/zu unterstützen.
• Zum Beispiel kann die Unterstützung für jede V2X RAT auf der Anzahl an vUEs, die jede V2X RAT unterstützen, basieren oder entsprechend dieser sein.
• 6 stellt ein gemischtes V2X RAT-Szenario 600, welches eine beispielhafte V2X-Ressourcenkonfiguration 601 aufweist, gemäß verschiedenen Ausführungsformen dar. Das Szenario 600 ist sowohl auf die erste als auch die zweite Ausführungsform, die zuvor erläutert wurden, anwendbar. Das Szenario 600 beinhaltet vUEs 621 und 622, welche dieselben oder ähnlich wie das vUE 121a von 1 und/oder das UE 420 von 4 sein können; Sidelink-Kanäle 605, 606, welche dieselben oder ähnlich wie der Sidelink-Kanal 105 von 1 sein können; einen RAN-Knoten 631, welcher derselbe oder ähnlich wie der RAN-Knoten 131 von 1 sein kann; und RSUs 632, welche dieselben oder ähnlich wie die ANs 132 von 1 sein können.
• Das Szenario 600, das durch 6 dargestellt ist, zeigt einen Nutzungsfall, der einen Großteil von vUEs 621, die ausgestattet sind, um gemäß einer ersten V2X RAT zu kommunizieren, und ein einzelnes vUE 622, das ausgestattet ist, um gemäß einer zweiten V2X RAT zu kommunizieren, aufweist. Zusätzlich können die RSUs 632 konfiguriert sein, um erste V2X RAT-Kommunikationsdienste oder zweite V2X RAT-Kommunikationsdienste bereitzustellen. Als ein Beispiel ist die erste V2X RAT LTE C-V2X und ist die zweite V2X RAT DSRC/ITS-G5.
• Gemäß verschiedenen Ausführungsformen weist eine integrierte Schaltung (IC) zum Verwalten von Kommunikationen der vUEs 621, 622 eine Schnittstellenschaltungsanordnung zum Koppeln der IC mit einer oder mehreren RSUs 632 und/oder dem RAN-Knoten 631 auf, wobei jede RSU 632 und/oder der RAN-Knoten 631 eingerichtet sind, um mit einem oder mehreren vUEs 621, 622, die sich durch jeweilige Abdeckungsbereiche der einen oder mehreren RSU 632 und/oder des RAN-Knotens 631 fortbewegen, zu kommunizieren. Die IC weist auch eine Prozessorschaltungsanordnung auf, die mit der Schnittstellenschaltungsanordnung gekoppelt ist, wobei die Prozessorschaltungsanordnung eingerichtet ist, um: eine erste Anzahl an ersten vUEs 621 und eine zweite Anzahl an zweiten vUEs 622, die in den jeweiligen Abdeckungsbereichen des RAN-Knotens 631 und/oder der RSUs 632 während jeweiligen Dienstzeiträumen (oder Zeiträumen) zu bedienen sind oder bedient werden, zu bestimmen; V2X RATs zu bestimmen, die während den jeweiligen Dienstzeiträumen (oder Zeiträumen) zu unterstützen sind; und Kommunikationsressourcen basierend auf den bestimmten Ressourcenzuweisungen zuzuweisen. Dies kann das Bestimmen und Zuweisen von einzelnen Kanälen (oder Teilen davon), die zum Bereitstellen von ersten V2X RAT-Kommunikationsdiensten zu verwenden sind, zu den ersten vUEs 621 basierend auf der ersten Anzahl an vUEs 621 während eines ersten Dienstzeitraums (oder Zeitraum), und das Bestimmen und Zuweisen von einzelnen Kanälen, die für zweite V2X RAT-Kommunikationsdienste zu verwenden sind, zu den zweiten vUEs 622 basierend auf der zweiten Anzahl an vUEs 622 während eines zweiten Dienstzeitraums (oder Zeitraum) umfassen. In einigen Ausführungsformen können die bestimmte V2X-Konfiguration und/oder Ressourcenzuweisung (z. B. die Ressourcenzuweisung 601) unter dem RAN-Knoten 631 und/oder den RSUs 632 zum Konfigurieren des RAN-Knotens 631 und/oder der RSUs 632 zum Bereitstellen der V2X RAT-Dienste während des Dienstzeitraums (oder Zeitraum) kommuniziert werden. In dem Szenario 600 werden die RSUs 632 konfiguriert werden, um einen Großteil der ersten V2X RAT-Kanäle und einen kleineren Teil der zweiten V2X RAT-Kanäle zu den vUEs 621, 622 zu unterstützen. Dies ist durch die Ressourcenkonfiguration 601 gezeigt, welche den Kanal 1 und den Kanal 2, die für erste V2X RAT-Kommunikationen („V2X RAT 1“ in 6) zu verwenden sind, und den Kanal 3, der für zweite V2X RAT-Kommunikationen („V2X RAT 2“ in 6) zu verwenden ist, zuweist. In einigen Ausführungsformen sind die RSUs 632 und/oder der RAN-Knoten 631 mit Übersetzungsfähigkeiten ausgestattet und stellen Nachrichtenübersetzungen unter den vUEs 621, 622 bereit. In diesen Ausführungsformen kann die IC in dem RAN-Knoten 631, einer der RSUs 632, einem oder mehreren an derselben Stelle liegenden Edge-Servern (z. B. die MEC-Server 136), einem Cloud-Computing-Dienst (z. B. die Cloud 144 von 1), einem Kernnetzwerk NF (z. B. NF innerhalb des CN 142 von 1) und/oder dergleichen implementiert oder von diesen gehostet werden.
• Zusätzlich oder alternativ ist die Prozessorschaltungsanordnung der IC eingerichtet, um: eine erste Gruppe von vUEs (z. B. die vUEs 621) und eine zweite Gruppe von vUEs (z. B. die vUEs 622), die in den jeweiligen Abdeckungsbereichen des RAN-Knotens 631 und/oder der RSUs 632 während jeweiligen Dienstzeiträumen (oder Zeiträumen) zu bedienen sind oder bedient werden, zu kennzeichnen. Die Kennzeichnung der vUE-Gruppen kann auf einem oder mehreren Kriterien/Qualifizierungen basieren (z. B. der Art von V2X RATs, die von den vUEs verwendet werden, und/oder sonstige vUE-Fähigkeiten). Die Prozessorschaltungsanordnung der IC ist auch eingerichtet, um Kommunikationsressourcen zwischen den ersten und zweiten Gruppen von vUEs während der jeweiligen Dienstzeiträumen (oder Zeiträumen) zuzuweisen. Die Zuweisung von Ressourcen kann dieselbe oder ähnlich wie zuvor erläutert sein.
• Zusätzlich werden eine oder mehrere Verknüpfungen 617 zwischen dem RAN-Knoten 631 und den RSUs 632 hergestellt und werden die Verknüpfungen 603 verwendet, um einige erste V2X RAT vUEs 621 zu bedienen, die sich relativ nahe bei dem RAN-Knoten 631 für eine bessere Abdeckung als jener, die den vUEs 621 bereitgestellt wird, die weiter von dem RAN-Knoten 631 entfernt sind, befinden (z. B. in einem anderen Band). Die RSUs 632 sind durch jeweilige Verknüpfungen 618 miteinander verbunden, die die Kommunikation zwischen einzelnen RSUs 632 erlauben. In einigen Ausführungsformen können die Verknüpfungen 618 unter den RSUs 632 aktiv gehalten werden. Die Verknüpfungen 617, 618 können drahtgebundene oder drahtlose Verknüpfungen sein. Zusätzlich können direkte Vorrichtung-Vorrichtung-Verknüpfungen (D2D-Verknüpfungen) 605 (auch als „Sidelinks 605“ bezeichnet) unter dem Großteil von ersten V2X RAT vUEs 621 einschließlich jener, die nicht direkt von dem RAN-Knoten 631 bedient werden, hergestellt werden. Ferner verwendet das zweite V2X RAT vUE 622 den kleineren Teil der zweiten V2X RAT-Kanäle.
• In einem ersten Beispiel, wo die erste V2X RAT LTE C-V2X ist, können die Verknüpfungen 603 und 617 LTE-Uu-Schnittstellenkanäle (oder NR-Uu-Schnittstellenkanäle) sein und können die Sidelinks 605 LTE PC5-Schnittstellenkanäle (oder NR PC5-Schnittstellenkanäle) sein. In einem zweiten Beispiel, wo die erste V2X RAT LTE C-V2X ist, ist/sind die Verknüpfungen 603 LTE-Uu-Schnittstellenkanäle (oder NR-Uu-Schnittstellenkanäle), können die Sidelinks 605 LTE PC5-Schnittstellenkanäle (oder NR PC5-Schnittstellenkanäle) sein und ist/sind die Verknüpfungen 617 S1-Anwendungsprotokollschnittstellen (S1-AP-Schnittstellen) für LTE-Implementierungen, eine NG-Anwendungsprotokollschnittstelle (NG-AP-Schnittstelle) für 5G/NR-Implementierungen oder Mp3-Schnittstellen für MEC-Implementierungen.
• In einem dritten Beispiel, welches mit dem ersten Beispiel oder dem zweiten Beispiel, die zuvor erläutert wurden, kombiniert werden kann, sind die Verknüpfungen 618 zwischen den RSUs 632 drahtgebundene Verknüpfungen und können S1-AP-Schnittstellen bei LTE-Implementierungen, NG-AP-Schnittstellen bei 5G-/NR-Implementierungen, Mp3-Schnittstellen für MEC-Implementierungen und/oder dergleichen sein oder diese darstellen. In dem ersten, dem zweiten und dem dritten Beispiel kann eine beliebige der zuvor genannten Schnittstellen auf einer oder mehreren vorhandenen Netzwerktechnologien, wie etwa Ethernet, Glasfaser und/oder dergleichen, funktionieren.
• In einem vierten Beispiel, welches mit dem ersten Beispiel oder dem zweiten Beispiel, die zuvor erläutert wurden, kombiniert werden kann, sind die Verknüpfungen 618 zwischen den RSUs 632 drahtlose Verknüpfungen und können drahtlose S1-AP-Schnittstellen, wenn die RSUs 632 Relais-Knoten bei LTE-Implementierungen sind, drahtlose Backhaul-Verknüpfungen, wenn die RSUs 632 IAB-Knoten (Integrated Access and Backhaul nodes) bei 5G/NR IAB-Implementierungen sind, WLAN- und/oder DSRC-Drahtlosverknüpfungen bei DSRC/ITS-G5-Implementierungen und/oder dergleichen sein oder diese darstellen. Bei einem der zuvor genannten Beispielen ist die zweite V2X RAT DSRC/ITS-G5 und ist die Verknüpfung 606 eine DSRC-Verknüpfung.
• In einigen Ausführungsformen kann die Edge-Infrastrukturausrüstung (z. B. der RAN-Knoten 631, die RSUs 632 und/oder die an derselben Stelle liegenden MEC-Server 136) sich selbst (neu) konfigurieren, um eine konkrete V2X RAT zu unterstützen oder Kommunikationsdienste den vUEs 621, 622 bereitzustellen und eine entsprechende Neukonfiguration der benachbarten Edge-Infrastrukturausrüstung durchzusetzen. In einigen Ausführungsformen ist jede Edge-Infrastrukturausrüstung für die Neukonfiguration von sich selbst gemäß den geteilten Konfigurationsinformationen zuständig und koordiniert die Zuweisung von Funkfrequenzressourcen zueinander gemäß der konfigurierten V2X RAT. In einigen Ausführungsformen kann eine einzelne Edge-Infrastrukturausrüstung den Zeitraum, während welchem die einzelne und/oder benachbarte Edge-Infrastrukturausrüstung mit der geeigneten V2X RAT konfiguriert werden sollte, zum Beispiel basierend auf Signalabtastung, historischen Daten der vUEs 621, 622, die sich durch jeweilige Abdeckungsbereiche während eines Abtastzeitraums fortbewegen, und/oder unter Verwendung anderer Verfahren hochrechnen oder vorhersagen.
• In einigen Ausführungsformen kann die Edge-Infrastrukturausrüstung die Konfigurationsinformationen und/oder Ressourcenzuweisung direkt zu der benachbarten Edge-Infrastrukturausrüstung über direkte drahtgebundene oder drahtlose Verknüpfungen 617, 618 unter Verwendung von bekannter Signalisierung/Nachrichten übertragen. In einigen Ausführungsformen befinden sich der RAN-Knoten 631 und/oder die RSUs 632 an derselben Stelle wie ein MEC-Server 136 (nicht durch 6 gezeigt) und geben Informationen bezüglich der V2X RAT-Konfiguration an eine lokal anwendbare Edge-Infrastrukturausrüstung durch eine V2X API 451 preis. Folglich können die MEC-Apps 436 (die auf bestimmten MEC-Servern 136 ausgeführt werden) Informationen durch Gewinnen von Informationen von ihren jeweiligen lokalen MEC-Plattformen 437 oder von anderen MEC-Plattformen 437 durch die Mp3-Schnittstelle austauschen und diese Informationen durch geeigneten Nachrichtenversand/Signalisierung austauschen (siehe z. B. die 10 - 11, weiter unten erläutert). In einigen Ausführungsformen kann eine konkrete MEC-App 436 die Art von V2X RAT bestimmen, die konfiguriert werden sollte, und ihren an derselben Stelle liegenden RAN-Knoten 631 und/oder die RSUs 632 mit jener V2X RAT konfigurieren.
• In einigen Ausführungsformen können einige oder alle der zuvor genannten Funktionen von anderen Elementen oder Entitäten durchgeführt werden. Zum Beispiel können in einer Ausführungsform der RAN-Knoten 631 und/oder die RSUs 632 die Signalisierung messen oder detektieren, die in ihren jeweiligen Abdeckungsbereichen stattfindet, und Mess- und/oder Detektionsinformationen einem Cloud-Computing-System (z. B. der Cloud 144 von 1) bereitstellen, welches den RAN-Knoten 631 und/oder die RSUs 632 konfiguriert, um konkrete V2X RATs für einen gegebenen Dienstzeitraum (oder Zeitraum) bereitzustellen/zu unterstützen.
• In einigen Ausführungsformen kann das Nachrichtenformat für die Edge-Infrastruktur zum Kommunizieren der (Neu-)Konfigurationsinformationen und/oder Ressourcenzuweisungen zur lokal anwendbaren Edge-Infrastruktur proprietär sein und keiner Standardisierung unterliegen. Alternativ können Informationen, die Anwendungen durch die MEC V2X API 451 verfügbar gemacht sind, standardisiert werden, um eine Interoperabilität unter verschiedenen Systemen sicherzustellen. Ein Beispiel der Daten/Informationen, die in diesen Nachrichten für jede Ausführungsform enthalten sind, kann eine oder mehrere der Folgenden aufweisen: die Anzahl der gesamten Kanäle, die durch die Edge-Infrastrukturausrüstung (oder durch die Gruppe von RAN-Knoten 631 und/oder die RSUs 632, die mit jener MEC-Plattform 437 verknüpft sind) verfügbar sind; für jede Edge-Infrastrukturausrüstung, die Bandbreite und der Frequenzträger jedes Kanals und die jeweilige bevorzugte Nutzung; für jede Edge-Infrastrukturausrüstung: die Anzahl an Fahrzeugen, die die erste V2X RAT unterstützen, die Anzahl an Fahrzeugen, die die zweite V2X RAT unterstützen, und so weiter bis zu der Anzahl an Fahrzeugen, die eine N-te V2X RAT unterstützen, wobei N eine Zahl ist; und/oder einen durchschnittlichen Zeitraum der vorherigen Messungen. Beispielhafte Nachrichtenformate sind durch 12 gezeigt, die weiter unten erläutert wird.
• Es sind andere Konfigurationen und Variationen der Edge-Infrastruktur und Frequenzkanalkonfiguration 601 für die RAN-Knoten 631 und/oder die RSUs 632 je nach dem konkreten Infrastruktureinsatz, dem Nutzungsfall (den Nutzungsfällen) und sonstigen Faktoren möglich. Solche Variationen können Szenarien, wie etwa Folgende, aufweisen:
1. (1) Es sind nur zweite V2X RAT vUEs 622 (z. B. DSRC/ITS-G5) lokal auf der Straße oder in einem konkreten Abdeckungsbereich (oder einer Gruppe von Abdeckungsbereichen) vorhanden. Hier kann die Infrastrukturausrüstung konfiguriert sein, um nur die zweite V2X RAT zu den vUEs 622 hin zu unterstützen; zusätzlich werden die drahtlosen/drahtgebundenen Verknüpfungen 617 zwischen den RSUs 632 und dem RAN-Knoten 631 hergestellt, werden die drahtlosen/drahtgebundenen Verknüpfungen 618 unter allen anderen RSUs 632 immer aktiv gehalten, und können die direkten zweiten V2X RAT-Verknüpfungen 606 (z. B. die DSRC-Verknüpfungen 606) unter allen vUEs 622 hergestellt werden.
2. (2) Es sind nur erste V2X RAT vUEs 621 (z. B. LTE C-V2X) lokal auf der Straße vorhanden. Hier kann die Infrastrukturausrüstung konfiguriert sein, um nur die erste V2X RAT zu den vUEs 621 zu unterstützen; zusätzlich werden die drahtlosen/drahtgebundenen Verknüpfungen 617 zwischen den RSUs 632 und dem RAN-Knoten 631 hergestellt, und auch möglicherweise die ersten V2XRAT vUES 621 für eine bessere Abdeckung (in einem anderen Band) bedienen; die drahtgebundenen/drahtlosen Verknüpfungen 618 unter allen RSUs 632 werden immer aktiv gehalten; und es können direkte Verknüpfungen 606 der ersten V2X RAT (z. B. die PC5-Verknüpfungen 605) unter allen vUEs 621 hergestellt werden.
3. (3) Es ist ein Großteil von zweiten V2X RAT (z. B. DSRC/ITS-G5) vUEs 622 lokal auf der Straße vorhanden. Hier kann die Infrastrukturausrüstung konfiguriert sein, um einen Großteil von zweiten V2X RAT-Kanälen und einen kleineren Teil von ersten V2X RAT-Kanälen (z. B. LTE C-V2X) zu den vUEs 621 hin zu unterstützen; zusätzlich sind drahtlose/drahtgebundene Verknüpfungen 617 zwischen den RSUs 632 und dem RAN-Knoten 631 hergestellt, welcher auch die ersten V2X RAT vUEs 621 (in einem anderen Band) bedient; die drahtgebundenen/drahtlosen Verknüpfungen 618 unter allen anderen RSUs 632 werden immer aktiv gehalten; und die direkten zweiten V2X RAT-Verknüpfungen 606 können unter dem Großteil an zweiten V2X RAT vUEs 622 (DSRC/ITS-G5) hergestellt werden, während die anderen wenigen verbleibenden Autos den kleineren Teil der ersten V2X RAT-Kanäle verwenden werden. Zusätzlich wird die Infrastrukturausrüstung mit Übersetzungsfähigkeiten ausgestattet sein und Nachrichtenübersetzungen unter den vUEs 621 und 622 bereitstellen.
• Allgemeiner kann im Falle einer ausgeglicheneren Mischung von ersten und zweiten V2X RAT vUEs 621/622 lokal auf der Straße die Infrastrukturausrüstung konfiguriert (z. B. halbstatisch) sein, um die Bandbreitenbedürfnisse für alle vUEs 621, 622 aufzunehmen. In diesen Ausführungsformen kann die Infrastrukturausrüstung einen bekannten Frequenzkanalplanungsalgorithmus zur dynamischen Kanalzuweisung implementieren.
• Unter Bezugnahme nunmehr auf 7 veranschaulicht diese ein Szenario 700, das Interaktionen zwischen Edge-Infrastrukturgeräten gemäß der ersten Ausführungsform beinhaltet. Das Szenario 700 beinhaltet eine Sidelink-Kommunikation, die über einen Sidelink-Kanal 705 übertragen wird, der von dem vUE 721a ausgeht und an dem vUE 721b endet. Die vUEs 721a-b können dieselben oder ähnlich wie die vUEs 621, 622 von 6 sein; der Sidelink-Kanal 705 kann derselbe oder ähnlich wie die Sidelink-Kanäle 605, 606 von 6 sein; und die RSUs 732a-c können dieselben oder ähnlich wie die RSUs 632 von 6 sein. Die RSUs 732a-c sind kommunikativ über die Verknüpfungen 718 gekoppelt, welche dieselben oder ähnlich wie die Verknüpfungen 618 von 6 sein können.
• In dem Szenario 700 können die RSUs 732a-c konfiguriert sein, um erste V2X RAT-Kommunikationsdienste oder zweite V2X RAT-Kommunikationsdienste in jeweiligen Abdeckungsbereichen 738a, 738b und 738c bereitzustellen. Gemäß verschiedenen Ausführungsformen beobachtet mindestens eine der RSUs 732a-c das Vorhandensein der Sidelink-Kommunikationen, die über den Sidelink 705 stattfinden, bestimmt die konkrete Art von V2X RAT, die für die Sidelink-Kommunikation verwendet wird, konfiguriert sich selbst neu, um die konkrete V2X RAT zu unterstützen oder um Kommunikationsdienste den vUEs 721a-b unter Verwendung der erkannten V2X RAT bereitzustellen, und führt die entsprechende Neukonfiguration der benachbarten RSUs 732a-c durch. In einigen Ausführungsformen kann die Beobachtung von Kommunikationen, die in den Abdeckungsbereichen 738 stattfinden, das Aufnehmen oder anderweitige Erhalten von Nachrichten, die von den vUEs 721 kommuniziert werden, und Bestimmen der V2X RAT, die verwendet wird, basierend auf dem Header (oder konkreten Daten, die in dem Header enthalten sind) solcher Nachrichten umfassen. In diesen Ausführungsformen können die RSUs 732a-c dann die Anzahl an Nachrichten, die erste V2X RAT-Header aufweisen, die Anzahl an Nachrichten, die zweite V2X RAT-Header aufweisen, und so weiter bis zu der Anzahl an Nachrichten, die N-te V2X RAT-Header aufweisen, zählen. Basierend auf der Anzahl an Nachrichten von jeder V2X RAT können die RSUs 732a-c entscheiden, ob eine konkrete V2X RAT unterstützt wird, und/oder das Verhältnis der Ressourcen zum Zuweisen zu jeder V2X RAT entscheiden.
• In dem Beispiel von 7 sind die vUEs 721a und 721b in der Lage, unter Verwendung der ersten V2X RAT (z. B. LTE C-V2X) zu kommunizieren, und sind die RSUs 732a-c anfangs konfiguriert, um zweite V2X RAT-Dienste/-Ressourcen (z. B. DSRC/ITS-G5) bereitzustellen. Die RSU 732a bestimmt, dass die Sidelink-Kommunikation über die Verknüpfung 705 unter Verwendung der ersten V2X RAT (z. B. LTE C-V2X) stattfindet, konfiguriert sich selbst neu, um erste V2X RAT-Ressourcen/-Dienste bereitzustellen, und kommuniziert diese Konfigurationsinformationen an die RSUs 732b und 732c. Dann konfigurieren sich die RSUs 732b und 732c neu, um erste V2X/RAT-Ressourcen/-Dienste bereitzustellen.
• 8 veranschaulicht ein Szenario 800, welches eine beispielhafte Interaktion einer Edge-Infrastrukturausrüstung gemäß der ersten Ausführungsform ist. Insbesondere beinhaltet die erste Ausführungsform, dass die Infrastrukturausrüstung (z. B. die RSUs, die RAN-Knoten usw.) die Art(en) von V2X RAT-Ressourcen/-Diensten detektiert, die in einem designierten Bereich unterstützt werden müssen. Das Szenario 800 beinhaltet vUEs 821, welche dieselben oder ähnlich wie die vUEs 721a und 721b von 7 sein können; RSUs 832a, 832b und 832c, welche jeweils dieselben oder ähnlich wie die RSUs 732a, 732b und 732c von 7 sein können; und Abdeckungsbereiche 838a, 838b und 838c, welche jeweils dieselben oder ähnlich wie die Abdeckungsbereiche 738a, 738b und 738c von 7 sein können. Das Szenario 800 beinhaltet auch die RSU 832d, die den Abdeckungsbereich 838d bereitstellt, und beinhaltet die RSU 832e, die den Abdeckungsbereich 838e bereitstellt. Die RSUs 832d-e können dieselben oder ähnlich wie die RSUs 832a-c sein, und die Abdeckungsbereiche 838d-e können dieselben oder ähnlich wie die Abdeckungsbereiche 838a-c sein. Die RSUs 832a-e sind kommunikativ über die Verknüpfungen 818 gekoppelt, welche dieselben oder ähnlich wie die Verknüpfungen 718 von 7 sein können.
• In diesem Szenario sind die RSUs 832a-c anfangs konfiguriert, um Dienste/Ressourcen der zweiten V2X (z. B. DSRC/ITS-G5) bereitzustellen, und sind die RSUs 832d und 832e anfangs konfiguriert, um sowohl Dienste/Ressourcen der zweiten V2X (z. B. DSRC/ITS-G5) als auch Dienste/Ressourcen der ersten V2X (z. B. LTE C-V2X) bereitzustellen. Als Nächstes bestimmt die RSU 832e, dass sich das vUE 821 mit Fähigkeit für die erste V2X RAT in einen Bereich hinein bewegt, der noch nicht erste V2X RAT-Dienste/-Ressourcen bereitstellt (wie durch den Pfeil 810 in 8 angegeben ist), und informiert benachbarte RSUs 832a-c über jeweilige Verknüpfungen 818 in Bezug auf die Anforderung des Unterstützens der ersten V2X RAT-Dienste/-Ressourcen für das vUE 821, welches bald in deren Abdeckungsbereichen 838b-c ankommen wird. Ähnlich wie bei dem Szenario 700 von 7 werden sich die benachbarten RSUs 832a-c selbst neu konfigurieren, um die ersten V2X RAT-Dienste/-Ressourcen zu unterstützen/bereitzustellen.
• Wie zuvor dargelegt wurde, ist der Anfangsschritt das Erfassen der Fahrzeuge 821 in einem Abdeckungsbereich 838 durch eine RSU 832. Es können mehrere Fälle auftreten, und diese sollten geeignet von dem System durch eine geeignete Edge-Infrastruktur und eine geeignete Frequenzkanalkonfiguration für die RSUs 832 (je nach dem Nutzungsfall, wie etwa die zuvor erläuterten) verwaltet werden.
• 9 stellt ein Szenario 900 gemäß der zweiten Ausführungsform dar. Insbesondere beinhaltet die zweite Ausführungsform, dass die vUEs 921 anfordern, dass (eine) konkrete V2X RAT(s) unterstützt werden. Das Szenario 900 beinhaltet vUEs 921, welche dieselben oder ähnlich wie die vUEs 821 von 8 sein können; RSUs 932a, 932b, 932c, 932d und 932e, welche jeweils dieselben oder ähnlich wie die RSUs 832a, 832b, 832c, 832d und 832e von 8 sein können; und Abdeckungsbereiche 938a, 938b, 938c, 938d und 938e, welche jeweils dieselben oder ähnlich wie die Abdeckungsbereiche 838a, 838b, 838c, 838d und 838e von 8 sein können. Die RSUs 932a-e sind kommunikativ über die Verknüpfungen 918 miteinander gekoppelt, welche dieselben oder ähnlich wie die Verknüpfungen 818 von 8 sein können. Das Szenario 900 beinhaltet auch, dass ein RAN-Knoten 931, welcher derselbe oder ähnlich wie der RAN-Knoten 631 von 6 sein kann, einen Abdeckungsbereich 950 (oder eine „Zelle 950“) bereitstellt. Die RSUs 932a-e sind über die Verknüpfungen 917 (von welchen nicht alle durch 9 gezeigt sind) kommunikativ mit dem RAN-Knoten 931 gekoppelt, welche dieselben oder ähnlich wie die Verknüpfungen 617 von 6 sein können.
• In dem Szenario 900 sind die RSUs 932d-e konfiguriert, um eine erste V2X RAT (z. B. LTE-C V2X) und eine zweite V2X RAT (z. B. DSRC/ITS-G5) zu unterstützen. Das vUE 921, das die erste V2X RAT (z. B. LTE-C V2X) unterstützt, entdeckt (z. B. durch Abtasten der geeigneten ersten V2X RAT-Kanäle (z. B. in dem 5,9-GHz-Band)), dass die erste V2X RAT aktuell nicht von den RSUs 931a-c bedient wird. In der zweiten Ausführungsform setzt das vUE 921 eine Kommunikationsverknüpfung/-verbindung mit dem RAN-Knoten 931 ein, dessen Abdeckungsbereich 950 ein viel größerer Bereich als die Abdeckungsbereiche 938a-e ist, die von den RSUs 932a-e bereitgestellt werden. Als ein Beispiel kann diese Kommunikationsverknüpfung/-verbindung eine LTE-Uu-Verbindung sein, wenn der RAN-Knoten 931 ein eNB ist, und/oder wenn die erste V2X RAT LTE C-V2X ist. Als weiteres Beispiel kann diese Kommunikationsverknüpfung/- verbindung eine NR-Uu-Verbindung sein, wenn der RAN-Knoten 931 ein gNB oder ein ng-eNB ist. Als weiteres Beispiel kann diese Kommunikationsverknüpfung/-verbindung eine NR-Uu-Verbindung sein, wenn der RAN-Knoten 931 ein WiFi AP ist und/oder wenn die erste V2X RAT DSRC/ITS-G5 ist.
• Das vUE 921 verwendet die Kommunikationsverknüpfung/-verbindung mit dem RAN-Knoten 931, um eine lokale Unterstützung der ersten V2X RAT anzufordern. Der RAN-Knoten 931 erhält die Anforderung, verarbeitet die Anforderung, und sendet eine entsprechende Bestätigungsnachricht (ACK-Nachricht) oder Negativ-ACK-Nachricht (NACK-Nachricht) zurück zu dem vUE 921. Wenn der Empfang der Anforderung bestätigt wird (z. B. unter Verwendung der ACK-Nachricht), werden eine Kanalanzahl und/oder sonstige ähnliche Informationen zurück zu dem anfordernden vUE 921 in der ACK-Nachricht kommuniziert. Zusätzlich sendet der RAN-Knoten 931 eine Konfigurationsnachricht zu den RSUs 932a-c, um die RSUs 932a-c neu zu konfigurieren, um erste V2 RAT-Ressourcen/-Dienste bereitzustellen, und werden sich die RSUs 932a-c selbst neu konfigurieren, um den Kanal zu unterstützen, der durch die ACK-Nachricht angegeben wird.
• In dem zuvor genannten Beispiel wird die Anforderung von dem vUE 921 durch das zelluläre Netzwerk durchgeführt. In einem anderen Beispiel kann das vUE 921 die Anforderungsnachricht zu einer oder mehreren RSUs 932a-e übertragen oder senden und kann eine RSU 932a-e, die die Anforderungsnachricht erhält, die Anforderungsnachricht zu dem RAN-Knoten 931 über jeweilige Verknüpfungen 918, 917 weiterleiten. In einem anderen Beispiel unterstützt das vUE 921 möglicherweise nur die zweite V2X RAT (z. B. DSRC/ITS-G5), und kann die Anforderungsnachricht zu einer RSU 932a-e übertragen oder senden. Die RSU 932a-e erhält die Anforderung, geht auf diese näher ein, um das System geeignet zu konfigurieren, und bestätigt den Empfang der Anforderung mit einer geeigneten ACK-Nachricht, die zu dem vUE 921 gesendet wird.
• In einem Beispiel weist ein Nachrichtenformat, das in den Szenarien 600 - 900 verwendet wird, die Konvention für die Paketdefinition auf, die durch ETSI TS 102 636-4-1 V1.1.1 (2011-06) erläutert wird. Beispielhafte Nachrichtenformate für diesen Zweck sind durch 12 gezeigt. Die Nachrichten können direkt zwischen Fahrzeugen und/oder RSUs durch Zwischenrelaisstationen (oder Relais) ausgetauscht werden, wie durch 11 veranschaulicht ist.
• 10 veranschaulicht ein V2X-Dienst-Verfahren (V2XS-Verfahren) 1000 gemäß verschiedenen Ausführungsformen, wobei ein V2XS-Konsument Konfigurations- und/oder Ressourcenzuweisungen (auch als RSU-Kanalnutzungsinformationen‟ bezeichnet) von einem V2XS-Produzenten anfordert. In Ausführungsformen kann der V2XS-Konsument einer des RAN-Knotens 631 und/oder der RSUs 632 von 6, der RSUs 732a-c von 7, der RSUs 832a-e von 8, oder des RAN-Knotens 931 und/oder der RSUs 932a-e von 9 sein; und kann der V2XS-Produzent ein anderer des/der zuvor genannten RAN-Knoten(s) oder RSUs sein. Aus Sicht des V2XS-Konsumenten ist der V2XS-Produzent eine Ressource, die die RSU-Kanalnutzungsinformationen darstellt.
• Das Verfahren 1000 beginnt bei der Operation 1003, wo der V2XS-Konsument eine Anforderungsnachricht zu dem V2XS-Produzenten sendet. In einer Ausführungsform kann die Anforderungsnachricht eine HTTP GET-Nachricht mit der Anforderungszeile „GET ../rsu_channels_info“ oder dergleichen sein. Zusätzlich weist die Anforderung eine Instanzkennung (ID) der MEC-App 436 als einen Eingangsparameter auf, welche in einem Nachrichtenbody der Anforderungsnachricht enthalten sein kann. Bei der Operation 1005 antwortet der V2XS-Produzent mit dem Nachrichtenbody, der die RSU-Kanalnutzungsinformationen enthält. In einer Ausführungsform ist die Antwortnachricht eine HTTP-Antwortnachricht, die den Statuscode „200 OK“ im Header der HTTP-Nachricht aufweist, welcher angibt, dass die Anforderung des V2XS-Konsumenten Erfolg hatte. Zusätzlich sind die angeforderten RSU-Kanalnutzungsinformationen („RsuChannelsInfo“) in dem Body der HTTP-Antwortnachricht enthalten. In dieser Ausführungsform kann die HTTP-Antwortnachricht andere HTTP-Statuscodes aufweisen, wie etwa einen Bad-Request-Statuscode (400) (z. B. wenn falsche Parameter in der Anforderung übergeben werden), einen Not-found-Statuscode (404) (z. B. wenn ein universeller Ressourcenindikator (URI), der in der Anforderung bereitgestellt wird, nicht mit einer gültigen Ressource URI gemappt werden kann), einen verbotenen Statuscode (403) (z. B. wenn die Operation aufgrund des aktuellen Status der Ressource nicht erlaubt ist), und/oder sonstige ähnliche HTTP-Statuscodes. In den zuvor erwähnten Beispielen kann der Antwortbody einen Datentyp ProblemDetails aufweisen, der Informationen über den konkreten Fehler anzeigt/aufweist. Es können andere Nachrichtenformate in anderen Ausführungsformen verwendet werden, und die Anforderungs-/Antwortdaten können sich in dem Header oder Bodyteil solcher Nachrichten befinden.
• Nach der Detektion interagiert die Edge-Infrastruktur (z. B. die einzelnen RSUs 732a-c und/oder die einzelnen MEC-Hosts 135) mit der benachbarten Edge-Infrastruktur (z. B. den einzelnen RSUs 732a-c), um Konfigurationsinformationen über ihre V2X RAT-Unterstützung zu teilen. In solchen Ausführungsformen wird die Edge-Infrastruktur (z. B. die einzelnen RSUs 732a-c und/oder die einzelnen MEC-Hosts 135), die einen aktuellen Abdeckungsbereich 738a-c abdeckt, die Entitäten der benachbarten Edge-Infrastruktur (z. B. die einzelnen RSUs 832a-c und/oder die einzelnen MEC-Hosts 135) über ein aufkommendes Bedürfnis nach der Unterstützung (einer) bestimmter/bestimmten V2X RAT(s) informieren. Dies sollte eine Nachricht umfassen, die das Bedürfnis nach (einer) bestimmten V2X RAT(s) und einen Vorschlag (oder Anweisungen/Befehle) für eine Frequenzbandzuweisung zwischen der/den V2X RAT(s) anzeigt.
• In einigen Ausführungsformen unterliegt das Nachrichtenformat für eine Edge-Infrastruktur (z. B. die einzelnen RSUs 732a-c und/oder die einzelnen MEC-Hosts 135) zum Mitteilen einer Neukonfiguration (z. B. Unterstützung von einer oder mehreren V2X RAT(s)) an eine andere anwendbare Edge-Infrastruktur (z. B. die einzelnen RSUs 732a-c und/oder die einzelnen MEC-Hosts 135) keiner Standardisierung. Stattdessen registrieren sich in solchen Ausführungsformen die MEC-Apps 436 bei den MEC-Diensten 437, die auf anderen MEC-Hosts ausgeführt werden, und rufen die geeigneten Informationen durch die MEC V2X API ab. Dieser Registrierungsmechanismus kann derselbe oder ähnlich wie der Registrierungsmechanismus sein, der in der Spezifikation der European Telecommunications Standards Institute (ETSI) Industry Group (ISG) MEC 011 v1.1.1 (2017-07) erläutert wird.
• 11 veranschaulicht ein Weiterleitungsverfahren 1100 gemäß verschiedenen Ausführungsformen. Das Verfahren 1100 kann verwendet werden, um Nachrichten direkt zwischen vUEs und der Infrastrukturausrüstung oder durch Zwischenweiterleitungen auszutauschen. Insbesondere zeigt das Verfahren 1100 eine Anforderungs- und Antwortnachrichtenweiterleitung zwischen einer Quelle und einem Ziel über zwei Weiterleitungen. Die Quelle ist eine sendende (übertragende) Entität, die eine Nachricht oder ein Paket erzeugt. Das Ziel ist eine Empfängerentität, die eine Nachricht oder ein Paket verarbeitet und sie bzw. es oberen Protokollentitäten liefert, jedoch die Nachricht oder das Paket nicht an andere Entitäten weiterleitet. Die Weiterleitungen (einschließlich der Weiterleitung 1 und der Weiterleitung 2 in 11) sind Entitäten, die eine Nachricht oder ein Paket verarbeiten und die Nachricht oder das Paket zu anderen Entitäten weiterleiten.
• Das Verfahren 1100 beginnt bei der Operation 1105, wo eine Quelle eine Anforderungsnachricht (RSU_REQUEST) erzeugt und zu einer ersten Weiterleitung (die Weiterleitung 1) sendet. Bei der Operation 1108 leitet die Weiterleitung 1 die Anforderungsnachricht zu einer zweiten Weiterleitung (die Weiterleitung 2) weiter, und bei der Operation 1110 leitet die Weiterleitung 2 die Anforderungsnachricht zu dem Zielknoten weiter. Bei der Operation 1113 erzeugt der Zielknoten eine Antwortnachricht (RSU_REPLY) und sendet diese zu der Weiterleitung 2. Bei der Operation 1115 leitet die Weiterleitung 2 die Antwortnachricht zu der Weiterleitung 2 weiter, und bei der Operation 1118 leitet die Weiterleitung 1 die Antwortnachricht zu dem Quellknoten weiter.
• In verschiedenen Ausführungsformen können die Quelle, das Ziel und die Weiterleitungen vUEs oder eine Infrastrukturausrüstung, wie etwa die zuvor unter Bezugnahme auf die 1 - 9 erläuterten, sein.
• In einem ersten Beispiel ist der Quellknoten ein vUE und sind die Weiterleitungen und der Zielknoten RSUs. In diesem Beispiel ist die Anforderungsnachricht eine V2X-Nachricht, die für ein anderes vUE bestimmt ist, und wird diese unter Verwendung einer konkreten Art von V2X RAT übertragen. Diese Anforderungsnachricht wird von der Weiterleitung 1 erfasst oder anderweitig erhalten, zu der Weiterleitung 2 und dann zu dem Zielknoten weitergeleitet. Der Zielknoten verwendet die erfasste Nachricht, um die Art von V2X RAT zu bestimmen, die von den vUEs verwendet wird, und bestimmt eine geeignete V2X RAT-Konfiguration für alle der RSUs. In diesem Beispiel kann die Antwortnachricht eine ACK-Nachricht zum Bestätigen des Erhalts der Anforderungsnachricht sein, oder es wird keine Antwortnachricht bei den Operationen 1113 - 1118 gesendet.
• In einem zweiten Beispiel ist der Quellknoten ein vUE und sind die Weiterleitungen und der Zielknoten RSUs. In diesem Beispiel ist die Anforderungsnachricht eine Anforderung bezüglich der Unterstützung einer konkreten Art von V2X RAT oder umfasst diese. Diese Anforderungsnachricht wird von der Weiterleitung 1 erfasst oder anderweitig erhalten, zu der Weiterleitung 2 und dann zu dem Zielknoten weitergeleitet. Der Zielknoten verwendet die Anforderungsnachricht (zusammen mit anderen Anforderungsnachrichten von anderen vUEs), um eine geeignete V2X RAT-Konfiguration für alle der RSUs zu bestimmen. In diesem Beispiel ist die Antwortnachricht eine ACK-Nachricht, um den Empfang der Anforderungsnachricht zu bestätigen.
• In einem dritten Beispiel sind der Quellknoten, die Weiterleitungen und der Zielknoten RSUs. In diesem Beispiel ist die Anforderungsnachricht eine Anforderung bezüglich einer V2X-Konfiguration und/oder einer Ressourcenzuweisung oder weist diese auf und ist die Antwortnachricht die angeforderte Konfiguration oder Ressourcenzuweisung oder weist diese auf.
• Bei einigen Implementierungen können die Quelle, das Ziel und die Weiterleitungen GeoAdhoc-Router sein oder diese implementieren. GeoAdhoc-Router sind Adhoc-Router, die das GeoNetworking-Protokoll (GN-Protokoll) implementieren, wie durch ETSI TS 102 636-4-1 V1.1.1 (2011-06) erläutert wird. Bei diesen Implementierungen sind die Anforderungsnachricht und die Antwortnachricht GN-Pakete oder Protokolldateneinheiten (PDUs, Protocol Data Units). Das GN-Protokoll ist ein Netzwerkprotokoll, das sich in der ITS-Netzwerk- und Transportschicht befindet (durch ETSI EN 302 665 erläutert) und in einem Ad hoc-Router, wie etwa dem GeoAdhoc-Router, ausgeführt wird. Das GeoNetworking-Protokoll stellt den Transport von Paketen in dem ITS-ad hoc-Netzwerk bereit, wie durch ETSI TS 102 636-1, ETSI TS 102 636-2 und ETSI TS 102 636-3 erläutert wird.
• Das GN-Protokoll stellt Dienste oberen Protokollentitäten bereit, zum Beispiel das ITS-Transport-Protokoll, wie etwa das Basistransportprotokoll (BTP) (durch ETSI TS 102 636-5-1 erläutert), und das GeoNetworking to IPv6 Adaption Sub-Layer (GN6ASL) (durch ETSI TS 102 636-6-1 erläutert). Die Dienste werden über eine GN_SAP-Entität unter Verwendung von Dienstprimitiven verschiedener Arten, die Parameter transportieren, und die PDU der oberen Protokollentität, zum Beispiel die T/GN6 PDU (siehe z. B. 1 in ETSI TS 102 636-4-1) bereitgestellt. Die PDUs der Transportprotokolle werden als SDUs in dem GN-Protokoll betrachtet. Die SDU wird mit Protokollsteuerinformationen (PCI, Protocol Control Information) ergänzt und als GN PDU zu der Peer-Entität übertragen. Um seine Pakettransportdienste bereitzustellen, verwendet das GNg-Protokoll die Dienste der ITS-Zugriffsschicht.
• 12 veranschaulicht eine PDU 1200 und einen PDU-Header 1201 gemäß verschiedenen Ausführungsformen. Die PDU 1200 ist eine grundlegende Konvention für die Spezifikation von Paketformaten. Die Bits sind in Bytes gruppiert. Die Bits eines Oktetts sind immer horizontal gezeigt und von 0 bis 7 nummeriert. Bis zu 4 Oktette sind horizontal gezeigt; mehrere Gruppen von 4 Oktetten sind vertikal gruppiert. Die Oktette sind von 1 bis N nummeriert. Die Oktette werden in einer aufsteigenden numerischen Reihenfolge übertragen; innerhalb eines Oktetts wird das Bit 0 zuerst übertragen. Wenn ein Feld innerhalb eines einzigen Oktetts enthalten ist, stellt die höchste Bitzahl des Felds den Wert niedrigster Ordnung dar, z. B. das Bit mit dem niedrigsten Stellenwert (LSB, Least Significant Bit). Wenn ein Feld mehr als ein Oktett umfasst, erhöht sich die Reihenfolge von Bitwerten innerhalb jedes Oktetts progressiv mit zunehmender Oktettanzahl, z. B. stellt die höchste Bitzahl des Mehrfachoktettfelds das LSB dar.
• Der PDU-Header 1201 ist eine grundlegende Konvention für das Header-Format für ein Paket. In einem Beispiel ist der PDU-Header 1201 ein gewöhnlicher Header, der in jedem GN-Paket vorhanden ist und die in 12 dargestellten Felder aufweist. Die Felder des PDU-Headers 1201 sind durch Tabelle 1 beschrieben. Tabelle 1: Felder des PDU-Headers 1201

  Feld-Nr.	Feldname	Oktett/BitPosition		Typ	Einheit	Beschreibung
  		Erstes	Letztes
  1	Version	Oktett 0 Bit 0	Oktett 0 Bit 3	4-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Kennzeichnet die Version des GeoN etworking-Protokolls
  2	NH	Oktett 0 Bit 4	Oktett 0 Bit 7	4-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Kennzeichnet den Typ des unmittelbar folgenden Headers; Kennzeichnet den Typ von Header, der unmittelbar auf den GeoN etworking-Header folgt, wie in Tabelle 5 von ETSI TS 102 636-4-1 und/oder den folgenden Werten spezifiziert wird: „0000“ = RSU REQUEST „0001“ = RSU ­_RESPONSE „1111“ = Fehler usw.
  3	HT	Oktett 1 Bit 0	Oktett 1 Bit 3	4-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Kennzeichnet den Typ des GeoAdhoc-Headertyps, wie in Tabelle 6 von ETSI TS 102 636-4-1 und/oder den folgenden Werten spezifiziert wird: „0000“ = RSU_REQUEST „0001“ = RSU_RESPONSE „1111“ = Fehler usw.
  4	HST	Oktett 1 Bit 4	Oktett 1 Bit 7	4-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Gibt eine spezifische Anforderung, eine spezifische Antwort usw. an. Kennzeichnet den Teil-Typ des GeoAdhoc-Headertyps, wie in Tabelle 6 von ETSI TS 102 636-4-1 und/oder den folgenden Werten spezifiziert wird: „0000“ = Antwort mit beschränkter Gültigkeit „0001“ = Antwort mit erweiterter Gültigkeit, usw.
  5	Reserviert	Oktett 2	Oktett 2		keine Angabe	Für medienabhängige Funktionalität reserviert.
  6	Etiketten	Oktett 3	Oktett 3	Bit-Feld	keine Angabe	Bit 0 bis 5: Reserviert. Auf 0 setzen. Bit 6: Typ, wenn ITS-Station. Bit 7: Reserviert. Auf 0 setzen.
  7	PL	Oktett 4	Oktett 5	16-Bit-Ganzzahl ohne Vorzeichen	[Sprünge]	Länge der Netzwerkheadernutz daten, d. h., der Rest des Pakets, der auf den gesamten GeoNetworking-Header folgt, in Oktetten.
  8	TC	Oktett 6	Oktett 6	Vier Teilfelder: 1-Bit-Ganzzahl ohne Vorzeichen, 3-Bit-Ganzzahl ohne Vorzeichen, 2-Bit-Selektor, 2-Bit-Selektor	keine Angabe	Traffic-Klasse, die Facility-Schicht-Anforderungen bezüglich des Pakettransports darstellt. Aus vier Teilfeldern zusammengesetzt (9 von ETSI TS 102 636-4-1): Bit 0: Reserviert. Auf 0 setzen. Bit 1 bis 3: Relevanz Die Relevanz drückt die Relevanz oder Wichtigkeit einer Nachricht aus, die von der oberen Protokollentität gegeben wird. Die Relevanz einer Nachricht sollte so codiert werden, wie in dem Abschnitt 8.5.6.1 von ETSI TS 102 636-4-1 definiert ist. Bit 4 bis 5: Zuverlässigkeit Mit Zuverlässigkeit ist die relative Wahrscheinlichkeit, ein Paket korrekt in einem geografischen Bereich zu erhalten, der durch einen 2-Bit-Selektor codiert ist, gemeint, wie in Tabelle 7 von ETSI TS 102 636-4-1 detailliert aufgeführt ist. Bit 6 bis 7: Latenz Latenz drückt die relative Paketlieferlatenz in einem geografischen Bereich aus, der durch einen 2-Bit-Selektor codiert ist, wie in Tabelle 8 von ETSI TS 102 636-4-1 detailliert aufgeführt ist.
  9	HL	Oktett 7	Oktett 7	8-Bit-Ganzzahl ohne Vorzeichen		Sprunggrenze, wenn z. B. Relais verwendet werden, sind wie viele Sprünge erlaubt? „0000“ gibt an, dass keine Sprünge erlaubt sind, z. B. muss die Kommunikation eine direkte Kommunikation Fahrzeug - RSU (oder umgekehrt) sein. Um 1 verkleinert durch jeden GeoAdhoc- Router, der das Paket weiterleitet. Das Paket darf nicht weitergeleitet werden, wenn die Sprunggrenze auf Null verringert wird.
  10	SE PV	Oktett 8	Oktett 35	Langer Positionsve ktor		Langer Positionsvektor des Senders. Er soll die Felder transportieren, wie in Absatz 8.4.2 von ETSI TS 102 636-4-1 spezifiziert ist (Langer Positionsvektor). Länge: 28 Oktette.

• In einem Beispiel wird ein „RSU_REQUEST“-Nachrichtenformat für ein vUE 121 verwendet, um mit einem RAN-Knoten 131 zu kommunizieren, um anzufordern, dass die lokale Edge-Infrastruktur (z. B. die RSU(s) 132 von 1) eine konkrete V2X RAT unterstützen sollten. Die Felder des „RSU_REQUEST“-Paketheaders können die durch Tabelle 2 beschriebenen aufweisen. Tabelle 2

  Feld -Nr.	Feldname	Oktett/BitPosition		Typ	Einheit	Beschreibung
  		Erstes	Letztes
  1	Gemeinsamer Header	Oktett 0	Oktett 35	Gemeinsamer Header	keine Angabe	Gemeinsamer Header.
  2	TID (Technologie-ID)	Oktett 36	Oktett 36	8-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Technologie-ID, z. B. „0000“ = DSRC/ITS-G5, „0001“ = LTE C-V2X, „0010“ = 5G NR, usw.
  3	RT (Anforderungsty P)	Oktett 37	Oktett 37	8-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Typ der Anforderung, z. B. „0000“ = Transcodieru ng beenden, „0001“ = Transcodieru ng von DSRC/ITS-G5 zu LTE C-V2X anfordern, „0010“ = Transcodieru ng von DSRC/ITS-G5 zu 5G NR anfordern, „0011“ = Transcodieru ng von LTE C-V2X zu DSRC/ITS-G5 anfordern, „0100“ = Transcodieru ng von 5G NR zu DSRC/ITS-G5 anfordern usw.

• In einem Beispiel wird ein „RSU_REPLY“- oder „RSU_RESPONSE“-Nachrichtenformat für einen RAN-Knoten 131 verwendet, um eine ACK + einen zugewiesenen Kanal oder eine NACK-Nachricht zurück zu dem betreffenden vUE 121 zu kommunizieren. Die Felder des „RSU_RESPONSE“-Paketheaders können die durch Tabelle 3 beschriebenen aufweisen. Tabelle 3

  Feld-Nr.	Feldname	Oktett/BitPosition		Typ	Einheit	Beschreibung
  		Erstes	Letztes
  1	Gemeinsamer Header	Oktett 0	Oktett 35	Gemeinsamer Header	keine Angabe	Gemeinsamer Header.
  2	TID (Technologie-ID)	Oktett 36	Oktett 36	8-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Technologie-ID, z. B. „0000“ = DSRC/ITS-G5, „0001“ = LTE C-V2X, „0010“ = 5G NR, usw.
  3	ResT (Antworttyp)	Oktett 37	Oktett 37	8-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Typ von Antwort, z. B. „0000“ = Transcodierung beenden, „0001“ = Erhalt von Transcodierung von DSRC/ITS-G5 zu LTE C-V2X bestätigen, „0010“ = Erhalt von Transcodierung von DSRC/ITS-G5 zu 5G NR bestätigen, „0011“ = Erhalt von Transcodierung von LTE C-V2X zu DSRC/ITS-G5 bestätigen, „0100“ = Erhalt von Transcodierung von 5G NR zu DSRC/ITS-G5 bestätigen, „1111“ = Fehler usw.

• In einem Beispiel wird ein „RSU_CONFIGURATION“-Paket-Header für einen RAN-Knoten 131 verwendet, um eine Neukonfiguration (z. B. die Unterstützung der Technologie „T1“) einer lokal anwendbaren Edge-Infrastrukturausrüstung (z. B. der/den RSU(s) 132) mitzuteilen. Die Felder des „RSU-CONFIGURATION“-Paket-Headers können die durch Tabelle 4 beschriebenen aufweisen. Tabelle 4

  Feld-Nr.	Feldname	Oktett/BitPosition		Typ	Einheit	Beschreibung
  		Erstes	Letztes
  1	Gemeinsamer Header	Oktett 0	Oktett 35	Gemeinsamer Header	keine Angabe	Gemeinsamer Header.
  2	TID (Technolog ie-ID)	Oktett 36	Oktett 36	8-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Technologie-ID, z. B. „0000“ = DSRC/ITS-G5, „0001“ = LTE C-V2X, „0010“ = 5G NR, usw.
  3	ConfT (Antwortty P)	Oktett 37	Oktett 37	8-Bit-Ganzzahl ohne Vorzeichen	keine Angabe	Typ von Konfigurationsnachr icht, z. B. „0000“ = Transcodierung beendet, „0001“ = Erhalt von Transcodierung von DSRC/ITS-G5 zu LTE C-V2X bestätigen, „0010“ = Erhalt von Transcodierung von DSRC/ITS-G5 zu 5G NR bestätigen, „0011“ = Erhalt von Transcodierung von LTE C-V2X zu DSRC/ITS-G5 bestätigen, „0100“ = Erhalt von Transcodierung von 5G NR zu DSRC/ITS-G5 bestätigen, „1111“ = Fehler usw.

• 13 stellt einen beispielhaften Prozess 1300 zum Praktizieren der verschiedenen Ausführungsformen, die hierin erläutert sind, dar. Insbesondere kann der Prozess 1300 von einem Rechensystem zum dynamischen Zuweisen von V2X-Ressourcen (siehe z. B. die Ressourcenzuweisung 601 von 6) zu vUEs durchgeführt werden. Zu Veranschaulichungszwecken sind die verschiedenen Operationen der Prozesse 1300 derart beschrieben, als dass sie von einem Rechensystem durchgeführt werden, welches ein Zugriffs-/Edge-Knoten 130 (z. B. ein MEC-Server 136, ein RAN-Knoten 111, AN (oder RSU) 132 oder AP 133) oder Backend-Knoten 140 (z. B. eine Netzwerkfunktion oder ein Netzwerkelement des CN 142, der Cloud 144 oder des (der) Server(s) 150) von 1 oder Elemente davon (z. B. Komponenten, die unter Bezugnahme auf die Infrastrukturausrüstung 300 von 3 erläutert sind) sein kann. Wenngleich konkrete Beispiele und Reihenfolgen von Operationen in den 10 - 11 veranschaulicht sind, sollten die dargestellten Reihenfolgen von Operationen nicht derart betrachtet werden, als dass sie den Umfang der Ausführungsformen in irgendeiner Art beschränken. Stattdessen können die dargestellten Operationen neu geordnet, in zusätzliche Operationen aufgeteilt, kombiniert und/oder alle zusammen weggelassen werden, während sie innerhalb des Wesens und Umfangs der vorliegenden Offenbarung bleiben.
• Das Verfahren 1300 beginnt bei der Operation 1305, wo das Rechensystem eine erste Anzahl an ersten vUEs und eine zweite Anzahl an zweiten vUEs, die von einer oder mehreren RSUs (z. B. den RSUs 632, 732, 832 und 932 der 6 - 9) in jeweiligen Abdeckungsbereichen (z. B. den Abdeckungsbereichen 738, 838 und 938 der 7 - 9) während jeweiligen Dienstzeiträumen (oder Zeiträumen) zu bedienen sind, bestimmt. Die ersten vUEs (z. B. die vUEs 121, 621, 721, 821 und 921 von 1 und 6 - 9) sind konfiguriert, unter Verwendung einer ersten V2X RAT zu kommunizieren, und die zweiten vUEs (z. B. die vUEs 121, 622, 721, 821 und 921 von 1 und 6 - 9) sind konfiguriert, unter Verwendung einer zweiten V2X RAT zu kommunizieren.
• Gemäß einer ersten Ausführungsform umfasst das Bestimmen der ersten Anzahl das Bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Nachrichten ist, die von vUEs in einem ersten Frequenzband erhalten wird; und umfasst das Bestimmen der ersten Anzahl das Bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Nachrichten ist, die von vUEs in einem zweiten Frequenzband erhalten wird.
• Gemäß einer zweiten Ausführungsform umfasst das Bestimmen der Anzahl an ersten vUEs und der Anzahl an zweiten vUEs das Erhalten von Anforderungsnachrichten von entsprechenden ersten vUEs und entsprechenden zweiten vUEs. Die Anforderungsnachrichten, die von den ersten vUEs erhalten werden, können Anforderungen bezüglich erster V2X RAT-Kommunikationsdienste sein, und die Anforderungsnachrichten, die von den zweiten vUEs erhalten werden, können Anforderungen bezüglich zweiter V2X RAT-Kommunikationsdienste sein. In dieser Ausführungsform bestimmt das Rechensystem, dass die erste Anzahl der ersten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der ersten vUEs erhalten wird, und dass die zweite Anzahl der zweiten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der zweiten vUEs erhalten wird.
• Bei der Operation 1310 weist das Rechensystem Ressourcen für die erste V2X RAT und die zweite V2X RAT basierend auf der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs zu. In einigen Ausführungsformen umfasst das Zuweisen der Ressourcen das Bestimmen eines ersten Kanals, der zum Bereitstellen der ersten V2X RAT-Kommunikationsdienste zu verwenden ist (z. B. der Kanal 1 oder der Kanal 2 der Ressourcenzuweisung 601 von 6), und eines zweiten Kanals (z. B. der Kanal 3 der Ressourcenzuweisung 601 von 6), der zum Bereitstellen der zweiten V2X RAT-Kommunikationsdienste zu verwenden ist, das Zuweisen des ersten Kanals für die ersten v2X RAT-Kommunikationsdienste und das Zuweisen der zweiten Kanäle für die zweiten V2X RAT-Kommunikationsdienste.
• In einigen Ausführungsformen umfasst das Zuweisen der Ressourcen das Bestimmen eines dritten Kanals (z. B. der Kanal 2 der Ressourcenzuweisung 601 von 6), der zum Bereitstellen sowohl der ersten V2X RAT-Kommunikationsdienste als auch der zweiten V2X RAT-Kommunikationsdienste zu verwenden ist, und das Zuweisen des dritten Kanals für die ersten V2X RAT-Kommunikationsdienste und die zweiten V2X RAT-Kommunikationsdienste. In diesen Ausführungsformen umfasst das Zuweisen der Ressourcen das Zuweisen des dritten Kanals für die ersten V2X RAT-Kommunikationsdienste während eines ersten Dienstzeitraums (oder Zeitraum) der jeweiligen Dienstzeiträume (oder Zeiträume) und das Zuweisen des dritten Kanals für die zweiten V2X RAT-Kommunikationsdienste während eines zweiten Dienstzeitraums (oder Zeitraum) der jeweiligen Dienstzeiträume (oder Zeiträume).
• Bei der Operation 1315 bestimmt das Rechensystem eine V2X-Konfiguration basierend auf den zugewiesenen Ressourcen, wobei die V2X-Konfiguration angibt, wann erste V2X RAT-Kommunikationsdienste den ersten vUEs bereitzustellen sind und zweite V2X RAT-Kommunikationsdienste den zweiten vUEs bereitzustellen sind.
• In einigen Ausführungsformen gibt die V2X-Konfiguration ferner eine erste Zeit, während welcher die ersten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, und eine zweite Zeit, während welcher die zweiten V2X RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, an.
• In einigen Ausführungsformen umfasst das Zuweisen der Ressourcen und/oder Erzeugen der V2X-Konfiguration das Erzeugen einer V2X-Konfigurationsnachricht (oder Ressourcenzuweisungsnachricht) zum Aufnehmen verschiedener Informationen/Daten zum Bereitstellen der ersten und zweiten V2X-Kommunikationsdienste. Diese Informationen können zum Beispiel einen oder mehrere einer Gesamtzahl an verfügbaren Kanälen, einer Bandbreite und eines Frequenzträgers jedes Kanals, einer bevorzugten Nutzung für jede RSU der einen oder mehreren RSUs, der ersten Anzahl der ersten vUEs, der zweiten Anzahl der zweiten vUEs und/oder einen Zeitraum, während welchem die erste Anzahl und die zweite Anzahl bestimmt wurden, umfassen. Diese Informationen können von der einen oder den mehreren RSUs verwendet werden, um die zugewiesenen Ressourcen zu bestimmen oder anderweitig die V2X-Kommunikationsdienste für die erste und die zweite V2X RATs bereitzustellen. In einigen Ausführungsformen kann die V2X-Konfigurationsnachricht (oder Ressourcenzuweisungsnachricht) zum Aufnehmen einer Angabe der zugewiesenen Ressourcen erzeugt werden.
• Bei der Operation 1315 sendet das Rechensystem die V2X-Konfiguration zu der einen oder den mehreren RSUs. In einigen Ausführungsformen umfasst das Senden der Konfiguration zu der einen oder den mehreren RSUs das Senden der V2X-Konfigurationsnachricht (oder Ressourcenzuweisungsnachricht) zu der einen oder den mehreren RSUs über jeweilige drahtgebundene oder drahtlose Verknüpfungen.
• Zusätzlich oder alternativ zu dem Senden der V2X-Konfigurationsnachricht kann das Rechensystem die eine oder die mehreren RSUs mit einer ersten V2X RAT-Komponente während eines ersten Dienstzeitraums der jeweiligen Dienstzeiträume konfigurieren und die eine oder die mehreren RSUs mit der zweiten V2X RAT-Komponente während eines zweiten Dienstzeitraums der jeweiligen Dienstzeiträume konfigurieren. Zusätzlich oder alternativ kann das Rechensystem mindestens eine RSU der einen oder mehreren RSUs mit der ersten V2X RAT-Komponente konfigurieren und mindestens eine andere RSU der einen oder mehreren RSUs mit der zweiten V2X RAT-Komponente konfigurieren. In diesen Ausführungsformen ermöglicht die erste V2X RAT-Komponente der einen oder den mehreren RSUs, die ersten RAT-Kommunikationsdienste bereitzustellen, und ermöglicht die zweite V2X RAT-Komponente der einen oder den mehreren RSUs, die zweiten V2X RAT-Kommunikationsdienste bereitzustellen.
• In einigen Ausführungsformen ist das Rechensystem ein Controller (oder eine Prozessorschaltungsanordnung) für eine einzelne RSU der einen oder mehreren RSUs, welcher eine Schnittstellenschaltungsanordnung aufweist, die das Rechensystem und/oder die einzelne RSU kommunikativ mit einem oder mehreren RFEMs koppelt. In diesen Ausführungsformen beinhaltet die Operation 1320 das Laden der ersten V2X RAT-Komponente und der zweiten V2X RAT-Komponente aus der Speicher-/Ablageschaltungsanordnung des Rechensystems in die RFEMs, um jeweils die ersten V2X RAT- und die zweiten V2X RAT-Kommunikationsdienste bereitzustellen.
• In einigen Ausführungsformen ist das Rechensystem ein Edge-Server (z. B. ein MEC-Server 136), der an derselben Stelle wie mindestens eine RSU der einen oder mehreren RSUs liegt, und andere RSUs der einen oder mehreren RSUs liegen an derselben Stelle wie andere Edge-Server (z. B. die MEC-Server 136). In diesen Ausführungsformen beinhaltet die Operation 1320 das Senden der V2X-Konfigurationsnachricht (oder der ersten V2X RAT-Komponente und der zweiten V2X RAT-Komponente) zu den anderen Edge-Servern über jeweilige Schnittstellen (z. B. die Mp3-Schnittstelle zwischen einem oder mehreren MEC-Servern 136).
• In einigen Ausführungsformen ist das Rechensystem ein Rechensystem oder Cloud-Computing-Ressourcen eines Cloud-Computing-Dienstes, die kommunikativ mit der einen oder den mehreren RSUs oder an derselben Stelle liegenden Edge-Knoten 130 über jeweilige Backhaul-Verknüpfungen gekoppelt sind. In diesen Ausführungsformen beinhaltet die Operation 1320 das Senden der V2X-Konfigurationsnachricht (oder der ersten V2X RAT-Komponente und der zweiten V2X RAT-Komponente) zu der einen oder den mehreren RSUs und/oder den an derselben Stelle liegenden Edge-Servern über die Backhaul-Verknüpfungen.
• Die Implementierung der vorherigen Techniken kann durch eine beliebige Anzahl an Spezifikationen, Konfigurationen oder beispielhaften Einsätzen von Hardware und Software erzielt werden. Es versteht sich, dass die funktionellen Einheiten oder Fähigkeiten, die in dieser Spezifikation beschrieben sind, eventuell als Komponenten oder Module bezeichnet oder gekennzeichnet worden sind, um deren Implementierungsunabhängigkeit genauer zu betonen. Solche Komponenten können von einer beliebigen Anzahl an Software- oder Hardwareformen ausgeführt werden. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardwareschaltung implementiert sein, die maßgeschneiderte Großintegrationsschaltungen (VLSI-Schaltungen) oder Gate-Anordnungen, Offthe-shelf-Halbleiter, wie etwa Logik-Chips, Transistoren oder sonstige diskrete Komponenten, aufweist. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen, wie etwa feldprogrammierbaren Gate-Anordnungen, programmierbarer Array-Logik, programmierbaren Logik-Vorrichtungen oder dergleichen, implementiert werden. Die Komponenten oder die Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert sein. Eine gekennzeichnete Komponente oder ein gekennzeichnetes Modul von ausführbarem Code kann zum Beispiel einen oder mehrere physische oder logische Blöcke von Computeranweisungen aufweisen, welche zum Beispiel als ein Objekt, ein Verfahren oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Programme einer gekennzeichneten Komponente oder eines gekennzeichneten Moduls nicht physikalisch zusammen angeordnet sein, sondern können disparate Anweisungen beinhalten, die in unterschiedlichen Bereichen gespeichert sind, welche, wenn sie logisch miteinander verknüpft werden, die Komponente oder das Modul beinhalten und den genannten Zweck für die Komponente oder das Modul erreichen.
• In der Tat kann eine Komponente oder ein Modul eines ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere verschiedene Codesegmente unter verschiedenen Programmen und über mehrere Speichervorrichtungen oder Verarbeitungssysteme verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie etwa Code-Umschreibung und Code-Analyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Datenzentrum) als jenem, in welchem der Code eingesetzt wird (z. B. in einem Computer, der in einem Sensor oder einem Roboter eingebettet ist), stattfinden. Ähnlich können Betriebsdaten hierin innerhalb von Komponenten oder Modulen gekennzeichnet und veranschaulicht sein und in einer beliebigen geeigneten Form ausgeführt und innerhalb einer beliebigen Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz gesammelt werden oder können über verschiedene Orte einschließlich über verschiedene Speichervorrichtungen verteilt werden und können mindestens teilweise nur als elektronische Signale auf einem System oder Netzwerk vorhanden sein. Die Komponenten oder die Module können passiv oder aktiv sein, einschließlich Agenten, die betrieben werden können, um gewünschte Funktionen durchzuführen.
• Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen weisen die folgenden nichteinschränkenden Konfigurationen auf. Jedes der nichteinschränkenden Beispiele kann für sich alleine stehen oder in einer beliebigen Vertauschung oder Kombination mit einem oder mehreren der anderen Beispiele, die nachstehend oder in der gesamten vorliegenden Offenbarung bereitgestellt sind, kombiniert werden.
• Beispiel A01 umfasst ein Verfahren zum Verwalten von Fahrzeugnutzergerätkommunikationen (vUE-Kommunikationen), wobei das Verfahren Folgendes umfasst: Bestimmen einer ersten Anzahl an ersten vUEs und einer zweiten Anzahl an zweiten vUEs, die in jeweiligen Abdeckungsbereichen von einer oder mehreren von einer oder mehreren straßenseitigen Einheiten (RSUs) während jeweiligen Dienstzeiträumen zu bedienen sind, wobei die ersten vUEs gemäß einer ersten Funkzugriffstechnologie (RAT) kommunizieren und die zweiten vUEs gemäß einer zweiten RAT kommunizieren; Bestimmen von Ressourcenzuweisungen zum Bereitstellen von ersten RAT-Kommunikationsdiensten für die ersten vUEs und zweiten RAT-Kommunikationsdiensten für die zweiten vUEs basierend auf der ersten Anzahl und der zweiten Anzahl; und Zuweisen der Ressourcen basierend auf den bestimmten Ressourcenzuweisungen.
• Beispiel A02 umfasst das Verfahren von Beispiel A01 und/oder von (einem) anderen Beispiel(en) hierin, wobei die Bestimmung der Ressourcenzuweisungen umfasst, zu bestimmen, dass ein erster Kanal zum Bereitstellen der ersten RAT-Kommunikationsdienste zu verwenden ist und ein zweiter Kanal zum Bereitstellen der zweiten RAT-Kommunikationsdienste zu verwenden ist.
• Beispiel A03 umfasst das Verfahren der Beispiele A01-A02 und/oder von (einem) anderen Beispiel(en) hierin, wobei die Zuweisung der Ressourcen umfasst, den ersten Kanal für die ersten RAT-Kommunikationsdienste zuzuweisen und die zweiten Kanäle für die zweiten RAT-Kommunikationsdienste zuzuweisen.
• Beispiel A04 umfasst das Verfahren der Beispiele A02-A03 und/oder von (einem) anderen Beispiel(en) hierin, wobei die Bestimmung der Ressourcenzuweisungen umfasst, zu bestimmen, dass ein dritter Kanal zum Bereitstellen sowohl der ersten RAT-Kommunikationsdienste als auch der zweiten RAT-Kommunikationsdienste zu verwenden ist.
• Beispiel A05 umfasst das Verfahren der Beispiele A02-A04 und/oder von (einem) anderen Beispiel(en) hierin, wobei die Zuweisung der Ressourcen das Zuweisen des dritten Kanals für die ersten RAT-Kommunikationsdienste und die zweiten RAT-Kommunikationsdienste umfasst.
• Beispiel A06 umfasst das Verfahren von Beispiel A05 und/oder von (einem) anderen Beispiel(en) hierin, wobei die Bestimmung der Ressourcenzuweisung das Bestimmen eines ersten Dienstzeitraums der jeweiligen Dienstzeiträume, während welchem die ersten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, und eines zweiten Dienstzeitraums der jeweiligen Dienstzeiträume, während welchem die zweiten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, umfasst.
• Beispiel A07 umfasst das Verfahren der Beispiele A03-A06 und/oder von (einem) anderen Beispiel(en) hierin, wobei die Zuweisung der Ressourcen das Zuweisen des dritten Kanals für die ersten RAT-Kommunikationsdienste während des ersten Dienstzeitraums und das Zuweisen des dritten Kanals für die zweiten RAT-Kommunikationsdienste während des zweiten Dienstzeitraums umfasst.
• Beispiel A08 umfasst das Verfahren der Beispiele A01-A07 und/oder von (einem) anderen Beispiel(en) hierin, wobei es ferner Folgendes umfasst: Senden einer Ressourcenzuweisungsnachricht zu der einen oder den mehreren RSUs über jeweilige drahtgebundene oder drahtlose Verknüpfungen zwischen einem System, das die IC hostet, und der einen oder den mehreren RSUs.
• Beispiel A09 umfasst das Verfahren von Beispiel A08 und/oder von (einem) anderen Beispiel(en) hierin, das ferner das Erzeugen der Ressourcenzuweisungsnachricht zum Aufnehmen einer Gesamtzahl an verfügbaren Kanälen, einer Bandbreite und eines Frequenzträgers jedes Kanals, einer bevorzugten Nutzung für jede RSU der einen oder mehreren RSUs, der ersten Anzahl der ersten vUEs, der zweiten Anzahl der zweiten vUEs, oder eines Zeitraums, während welchem die erste Anzahl und die zweite Anzahl bestimmt wurden, umfasst.
• Beispiel A10 umfasst das Verfahren der Beispiele A01-A09 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs Folgendes umfasst. Messen von Signalen, die von den ersten vUEs und den zweiten vUEs übertragen werden; Bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an gemessenen Signalen ist, die in einem ersten Frequenzband übertragen werden; und Bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an gemessenen Signalen ist, die in einem zweiten Frequenzband übertragen werden.
• Beispiel A11 umfasst das Verfahren der Beispiele A01-A09 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs Folgendes umfasst: Erhalten von Anforderungsnachrichten von den ersten vUEs und den zweiten vUEs; Bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der ersten vUEs erhalten wird; und Bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der zweiten vUEs erhalten wird.
• Beispiel A12 umfasst das Verfahren der Beispiele A01-A11 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Zuweisen der Ressourcen Folgendes umfasst: Konfigurieren von mindestens einer RSU der einen oder mehreren RSUs mit einem ersten RAT-Modul (auch als eine „erste RAT-Komponente“ bezeichnet), um die ersten RAT-Kommunikationsdienste bereitzustellen; und Konfigurieren von mindestens einer anderen RSU der einen oder mehreren RSUs mit einem zweiten RAT-Modul (auch als eine „zweite RAT-Komponente“ bezeichnet), um die zweiten RAT-Kommunikationsdienste bereitzustellen.
• Beispiel A13 umfasst eine integrierte Schaltung (IC), die eine Schnittstellenschaltungsanordnung, die eingerichtet ist, um die IC mit einer oder mehreren straßenseitigen Einheiten (RSUs) zu koppeln, wobei jede RSU der einen oder mehreren RSUs eingerichtet ist, um mit einem oder mehreren Fahrzeugnutzergeräten (vUEs) zu kommunizieren, die sich durch jeweilige Abdeckungsbereiche der einen oder mehreren RSUs fortbewegen; und eine Prozessorschaltungsanordnung, die mit der Schnittstellenschaltungsanordnung gekoppelt ist, aufweist, wobei die Prozessorschaltungsanordnung eingerichtet ist, um das Verfahren der Beispiele A01-A12 und/oder von (einem) anderen Beispiel(en) hierin durchzuführen.
• Beispiel A14 umfasst die IC von Beispiel A12 und/oder von (einem) anderen Beispiel(en) hierin, wobei es ferner Folgendes aufweist: eine Speicherschaltungsanordnung, die kommunikativ mit der Prozessorschaltungsanordnung gekoppelt ist, wobei die Speicherschaltungsanordnung eingerichtet ist, um Programmcode eines ersten RAT-Moduls (bzw. -Komponente) und eines zweiten RAT-Moduls (bzw. - Komponente) zu speichern.
• Beispiel A15 umfasst die IC von Beispiel A14 und/oder von (einem) anderen Beispiel(en) hierin, wobei eine RSU die IC hostet oder die IC von einem Rechensystem eines Cloud-Computing-Dienstes gehostet wird.
• Beispiel B01 umfasst ein Verfahren, das von einem Fahrzeugnutzergerät (vUE) durchzuführen ist, wobei das Verfahren Folgendes umfasst: Erzeugen einer Nachricht gemäß einer Vehicle-to-everything-Funkzugriffstechnologie (V2X RAT); und Übertragen der Nachricht zu einem Zielknoten gemäß dem V2X RAT-Protokoll, wobei die Nachricht bewirkt, dass der eine oder die mehreren RAN-Knoten einen oder mehrere Frequenzkanäle für V2X RAT-Kommunikationen zuweisen.
• Beispiel B02 umfasst das Verfahren von Beispiel B01 und/oder von (einem) anderen Beispiel(en) hierin, wobei die V2X RAT eine erste V2X RAT ist und das Übertragen der Nachricht unter Verwendung von ersten Kommunikationsmitteln durchzuführen ist, und wobei das Verfahren ferner Folgendes umfasst: Kommunizieren unter Verwendung von zweiten Kommunikationsmitteln gemäß einer zweiten V2X RAT, die sich von der ersten V2X RAT unterscheidet.
• Beispiel B03 umfasst das Verfahren von Beispiel B02 und/oder von (einem) anderen Beispiel(en) hierin, wobei der Zielknoten ein anderes vUE oder ein Funkzugriffsnetzwerkknoten (RAN-Knoten) ist, und wobei das Verfahren das Erzeugen der Nachricht zum Aufnehmen von einer oder mehreren vUE-Fähigkeiten umfasst, wobei die eine oder die mehreren vUE-Fähigkeiten die Unterstützung für die erste V2X RAT und die zweite V2X RAT angeben.
• Beispiel B04 umfasst das Verfahren der Beispiele B01-B03 und/oder von (einem) anderen Beispiel(en) hierin, wobei der Zielknoten ein RAN-Knoten ist, und wobei das Verfahren das Erzeugen der Nachricht zum Aufnehmen einer Anforderung in Bezug auf die Unterstützung der V2X RAT umfasst.
• Beispiel B05 umfasst das Verfahren von Beispiel B04 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Verfahren das Erhalten einer Bestätigungsnachricht (ACK-Nachricht) von dem RAN-Knoten, die den Erhalt der Nachricht bestätigt, und das Kommunizieren mit einem oder mehreren anderen vUEs gemäß der V2X RAT basierend auf dem Erhalt der ACK-Nachricht umfasst.
• Beispiel C01 umfasst ein Verfahren zum dynamischen Zuweisen von Vehicle-to-everything-Ressourcen (V2X-Ressourcen) zu Fahrzeugnutzergeräten (vUEs), wobei das Verfahren Folgendes umfasst: Bestimmen einer ersten Anzahl an ersten vUEs und einer zweiten Anzahl an zweiten vUEs, die von einer oder mehreren straßenseitigen Einheiten (RSUs) in jeweiligen Abdeckungsbereichen während jeweiligen Dienstzeiträumen zu bedienen sind, wobei die ersten vUEs konfiguriert sind, unter Verwendung einer ersten V2X-Funkzugriffstechnologie (V2X RAT) zu kommunizieren, und die zweiten vUEs konfiguriert sind, unter Verwendung einer zweiten V2X RAT zu kommunizieren; Zuweisen von Ressourcen für die erste V2X RAT und die zweite V2X RAT basierend auf der ersten Anzahl und der zweiten Anzahl; Bestimmen einer V2X-Konfiguration basierend auf den zugewiesenen Ressourcen, wobei die V2X-Konfiguration angibt, wann erste V2X RAT-Kommunikationsdienste den ersten vUEs bereitzustellen sind und zweite V2X RAT-Kommunikationsdienste den zweiten vUEs bereitzustellen sind; und Senden der V2X-Konfiguration zu der einen oder den mehreren RSUs.
• Beispiel C02 umfasst das Verfahren von Beispiel C01 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Zuweisen der Ressourcen das Bestimmen eines ersten Kanals, der zum Bereitstellen der ersten V2X RAT-Kommunikationsdienste zu verwenden ist, und eines zweiten Kanals, der zum Bereitstellen der zweiten V2X RAT-Kommunikationsdienste zu verwenden ist; das Zuweisen des ersten Kanals für die ersten V2X RAT-Kommunikationsdienste; und das Zuweisen der zweiten Kanäle für die zweiten V2X RAT-Kommunikationsdienste umfasst.
• Beispiel C03 umfasst das Verfahren von Beispiel C02 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Zuweisen der Ressourcen das Bestimmen eines dritten Kanals, der zum Bereitstellen sowohl der ersten V2X RAT-Kommunikationsdienste als auch der zweiten V2X RAT-Kommunikationsdienste zu verwenden ist; und das Zuweisen des dritten Kanals für die ersten V2X RAT-Kommunikationsdienste und die zweiten V2X RAT-Kommunikationsdienste umfasst.
• Beispiel C04 umfasst das Verfahren von Beispiel C03 und/oder von (einem) anderen Beispiel(en) hierin, wobei die V2X-Konfiguration ferner einen ersten Dienstzeitraum der jeweiligen Dienstzeiträume, während welchem die ersten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, und einen zweiten Dienstzeitraum der jeweiligen Dienstzeiträume, während welchem die zweiten V2X RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, angibt, und wobei das Zuweisen der Ressourcen das Zuweisen des dritten Kanals für die ersten V2X RAT-Kommunikationsdienste während des ersten Dienstzeitraums und das Zuweisen des dritten Kanals für die zweiten V2X RAT-Kommunikationsdienste während des zweiten Dienstzeitraums umfasst.
• Beispiel C05 umfasst das Verfahren der Beispiele C01-C04 und/oder von (einem) anderen Beispiel(en) hierin, wobei es ferner Folgendes umfasst: Erzeugen einer V2X-Konfigurationsnachricht zum Aufnehmen einer Gesamtzahl an verfügbaren Kanälen, einer Bandbreite und eines Frequenzträgers jedes Kanals, einer bevorzugten Nutzung für jede RSU der einen oder mehreren RSUs, der ersten Anzahl der ersten vUEs, der zweiten Anzahl der zweiten vUEs, oder eines Zeitraums, während welchem die erste Anzahl und die zweite Anzahl bestimmt wurden; und Senden der V2X-Konfigurationsnachricht zu der einen oder den mehreren RSUs über jeweilige drahtgebundene oder drahtlose Verknüpfungen.
• Beispiel C06 umfasst das Verfahren der Beispiele C01-C05 und/oder von (einem) anderen Beispiel(en) hierin, wobei es ferner Folgendes umfasst: Konfigurieren der einen oder mehreren RSUs mit einer ersten V2X RAT-Komponente (auch als ein „erstes V2X RAT-Modul“ bezeichnet) während eines ersten Dienstzeitraums der jeweiligen Dienstzeiträume, wobei die erste V2X RAT-Komponente der einen oder den mehreren RSUs ermöglicht, die ersten RAT-Kommunikationsdienste bereitzustellen; und Konfigurieren der einen oder mehreren RSUs mit der zweiten V2X RAT-Komponente (auch als ein „zweites V2X RAT-Modul“ bezeichnet) während eines zweiten Dienstzeitraums der jeweiligen Dienstzeiträume, wobei die zweite V2X RAT-Komponente der einen oder den mehreren RSUs ermöglicht, die zweiten V2X RAT-Kommunikationsdienste bereitzustellen.
• Beispiel C07 umfasst das Verfahren der Beispiele C01-C06 und/oder von (einem) anderen Beispiel(en) hierin, wobei es ferner Folgendes umfasst: Konfigurieren mindestens einer RSU der einen oder mehreren RSUs mit einer ersten V2X RAT-Komponente, wobei die erste V2X RAT-Komponente der mindestens einen RSU ermöglicht, die ersten RAT-Kommunikationsdienste bereitzustellen; und Konfigurieren von mindestens einer anderen RSU der einen oder mehreren RSUs mit einer zweiten V2X RAT-Komponente, wobei die zweite V2X RAT-Komponente der mindestens einen anderen RSU ermöglicht, die zweiten V2X RAT-Kommunikationsdienste bereitzustellen.
• Beispiel C08 umfasst das Verfahren von Beispiel C07 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs Folgendes umfasst: Bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Nachrichten ist, die von vUEs in einem ersten Frequenzband erhalten wird; und Bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Nachrichten ist, die von vUEs in einem zweiten Frequenzband erhalten wird.
• Beispiel C09 umfasst das Verfahren von Beispiel C07 und/oder von (einem) anderen Beispiel(en) hierin, wobei das Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs Folgendes umfasst: Erhalten von Anforderungsnachrichten von den ersten vUEs und den zweiten vUEs; Bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der ersten vUEs erhalten wird; und Bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der zweiten vUEs erhalten wird.
• Beispiel C10 umfasst ein oder mehrere computerlesbare Speichermedien, die Anweisungen aufweisen, wobei die Ausführung der Anweisungen durch einen oder mehrere Prozessoren bewirkt, dass ein Rechensystem das Verfahren von einem der Beispiele A01-A10, B01-B05 und/oder C01-C09 durchführt.
• Beispiel Z01 kann eine Vorrichtung umfassen, die Mittel zum Durchführen von einem oder mehreren Elementen eines Verfahrens, das in einem der Beispiele A01-A14, B01-B05, C01-C10 beschrieben ist oder mit diesen in Verbindung steht, oder irgendeines anderen hierin beschriebenen Verfahrens oder Prozesses aufweist. Beispiel Z02 kann ein oder mehrere nichtflüchtige computerlesbare Medien umfassen, die Anweisungen aufweisen, um zu bewirken, dass eine elektronische Vorrichtung nach der Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung ein oder mehrere Elemente eines Verfahrens, das in einem der Beispiele A01-A14, B01-B05, C01-C10 beschrieben ist oder mit diesen in Verbindung steht, oder irgendeines anderen hierin beschriebenen Verfahrens oder Prozesses durchführt. Beispiel Z03 kann eine Vorrichtung umfassen, die eine Logik, Module oder eine Schaltungsanordnung zum Durchführen von einem oder mehreren Elementen eines Verfahrens, das in einem der Beispiele A01-A14, B01-B05, C01-C10 beschrieben ist oder mit diesen in Verbindung steht, oder irgendeines anderen hierin beschriebenen Verfahrens oder Prozesses aufweist. Beispiel Z04 kann ein Verfahren, eine Technik oder einen Prozess, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Abschnitten oder Teilen davon beschrieben ist oder in Verbindung mit diesen umfassen. Beispiel Z05 kann eine Vorrichtung umfassen, die Folgendes aufweist: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Befehle aufweisen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, bewirken, dass der eine oder die mehreren Prozessoren das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Abschnitten oder Teilen davon beschrieben ist, oder in Verbindung mit diesen durchführt. Beispiel Z06 kann ein Signal, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Abschnitten oder Teilen davon beschrieben ist, und in Verbindung mit diesen umfassen. Beispiel Z07 kann ein Datenpaket, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Teilen oder Abschnitten davon beschrieben ist oder anderweitig in der vorliegenden Offenbarung beschrieben ist, umfassen.
• Beispiel Z08 kann ein Signal umfassen, das mit Daten codiert ist, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Teilen oder Abschnitten davon beschrieben ist oder in Verbindung mit diesen oder anderweitig in der vorliegenden Offenbarung beschrieben ist. Beispiel Z09 kann ein Signal umfassen, das mit einem Datenpaket, einem Paket, einem Rahmen, einem Segment, einer Protokolldateneinheit (PDU) oder einer Nachricht, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Teilen oder Abschnitten davon beschrieben ist oder in Verbindung mit diesen oder anderweitig in der vorliegenden Offenbarung beschrieben ist, codiert ist. Beispiel Z10 kann ein elektromagnetisches Signal umfassen, das computerlesbare Anweisungen transportiert, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren bewirkt, dass der eine oder die mehreren Prozessoren das Verfahren, die Techniken oder den Prozess durchführen, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Abschnitten davon beschrieben ist oder in Bezug auf diese. Beispiel Z11 kann ein Computerprogramm umfassen, das Anweisungen aufweist, wobei die Ausführung des Programms durch ein Verarbeitungselement bewirkt, dass das Verarbeitungselement das Verfahren, die Techniken oder den Prozess ausführt, wie in einem der Beispiele A01-A14, B01-B05, C01-C10 oder Abschnitten davon beschrieben ist oder in Bezug auf diese. Beispiel Z12 kann ein Signal in einem Drahtlosnetzwerk, wie hierin gezeigt und beschrieben, umfassen. Beispiel Z13 kann ein Verfahren zum Kommunizieren in einem Drahtlosnetzwerk, wie hierin gezeigt und beschrieben, umfassen. Beispiel Z14 kann ein System zum Bereitstellen von Drahtloskommunikation, wie hierin gezeigt und beschrieben, umfassen. Beispiel Z15 kann eine Vorrichtung zum Bereitstellen von Drahtloskommunikation, wie hierin gezeigt und beschrieben, umfassen. Ein beliebiges der zuvor beschriebenen Beispiele kann mit einem beliebigen anderen Beispiel (bzw. Kombination von Beispielen) kombiniert werden, solange nicht ausdrücklich das Gegenteil angegeben wird.
• Die vorliegende Offenbarung ist unter Bezugnahme auf Flussdiagrammveranschaulichungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und/oder Computerprogrammprodukten gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben worden. In den Zeichnungen können einige strukturelle Merkmale oder Verfahrensmerkmale in spezifischen Anordnungen und/oder Reihenfolgen gezeigt sein. Es sei jedoch darauf hingewiesen, dass solche spezifischen Anordnungen und/oder Reihenfolgen möglicherweise nicht erforderlich sind. Stattdessen können in solchen Ausführungsformen solche Merkmale in einer anderen Art und/oder Reihenfolge als der in den veranschaulichenden Figuren gezeigten angeordnet sein. Zusätzlich soll die Aufnahme eines strukturellen Merkmals oder Verfahrensmerkmals in eine konkrete Figur nicht implizieren, dass solch ein Merkmal in allen Ausführungsformen benötigt wird, und ist dieses in einigen Ausführungsformen möglicherweise nicht aufgenommen oder kann mit anderen Merkmalen kombiniert werden.
• Die hierin verwendete Terminologie dient nur dem Beschreiben konkreter Ausführungsformen und soll die Offenbarung nicht einschränken. So wie sie hierin verwendet werden, sollen die Einzahlformen „ein“, „eine“ und „der/die/das“ auch Mehrzahlformen umfassen, soweit der Kontext nicht eindeutig das Gegenteil angibt. Es versteht sich ferner, dass die Begriffe „umfasst/aufweist“ und/oder „umfassend“, wenn sie in der vorliegenden Beschreibung verwendet werden, das Vorhandensein von genannten Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten spezifizieren, jedoch nicht das Vorhandensein oder das Hinzufügen von einem oder mehreren anderen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon ausschließen.
• Zum Zwecke der vorliegenden Offenbarung bedeutet der Ausdruck „A und/oder B“ (A), (B) oder (A und B). Zum Zwecke der vorliegenden Offenbarung bedeutet der Ausdruck „A, B und/oder C“ (A), (B), (C), (A und B), (A und C), (B und C) oder (A, B und C). Die Beschreibung kann die Ausdrücke „in einer Ausführungsform“ oder „in einigen Ausführungsformen“ verwenden, welche sich jeweils auf eine oder mehrere derselben oder verschiedener Ausführungsformen beziehen können. Ferner sind die Begriffe „umfassen“, „beinhalten“, „aufweisen“ und dergleichen, so wie sie bezüglich Ausführungsformen der vorliegenden Offenbarung verwendet werden, gleichbedeutend.
• Der Begriff „Schaltungsanordnung“ bezieht sich auf eine Schaltung oder ein System von mehreren Schaltungen, die oder das konfiguriert ist, um eine konkrete Funktion in einer elektronischen Vorrichtung durchzuführen. Die Schaltung oder das System von Schaltungen kann Teil von einer oder mehreren Hardwarekomponenten, wie etwa einer Logikschaltung, eines Prozessors (gemeinsam, dediziert oder Gruppe) und/oder eines Speichers (gemeinsam, dediziert oder Gruppe), einer anwendungsspezifischen integrierten Schaltung (ASIC, Application Specific Integrated Circuit), eines feldprogrammierbaren Gate-Arrays (FPGA), einer programmierbaren Logikvorrichtung (PLD, Programmable Logic Device), einer komplexen PLD (CPLD, Complex PLD), einer PLD mit hoher Kapazität (HCPLD, High-Capacity PLD), eines System-on-Chips (Soc), eines System-in-Packages (SiP), eines Mehrfach-Chip-Packages (MCP), eines digitalen Signalprozessors (DSP) usw. sein oder diese aufweisen, die konfiguriert sind, um die beschriebene Funktionalität bereitzustellen. Zusätzlich kann sich der Begriff „Schaltungsanordnung“ auch auf eine Kombination von einem oder mehreren Hardwareelementen mit dem Programmcode beziehen, die verwendet wird, um die Funktionalität dieses Programmcodes auszuführen. Einige Arten von Schaltungsanordnung können ein oder mehrere Software- oder Firmwareprogramme ausführen, um mindestens einen Teil der beschriebenen Funktionalität bereitzustellen. Solch eine Kombination von Hardwareelementen und Programmcode kann als eine konkrete Art von Schaltungsanordnung bezeichnet werden.
• Der Begriff „Prozessorschaltungsanordnung“, wie er hierin verwendet wird, bezieht sich auf eine Schaltungsanordnung, die zum sequentiellen und automatischen Ausführen einer Sequenz von arithmetischen oder logischen Operationen oder Aufzeichnen, Speichern und/oder Übertragen von digitalen Daten in der Lage ist, ist Teil von dieser oder weist diese auf. Der Begriff „Prozessorschaltungsanordnung“ kann sich auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische zentrale Verarbeitungseinheit (CPU, Central Processing Unit), einen Einkern-Prozessor, einen Dual-Kern-Prozessor, einen Dreifach-Kern-Prozessor, einen Vierfach-Kern-Prozessor und/oder eine beliebige sonstige Vorrichtung, die in der Lage ist, von einem Computer ausführbare Anweisungen, wie etwa Programmcode, Softwaremodule und/oder funktionelle Prozesse, auszuführen oder anderweitig zu betreiben, beziehen. Die Begriffe „Anwendungsschaltungsanordnung“ und/oder „Basisbandschaltungsanordnung“ können als Synonyme für „Prozessorschaltungsanordnung“ betrachtet und als diese bezeichnet werden.
• Der Begriff „Speicher“ und/oder „Speicherschaltungsanordnung“, wie hierin verwendet, bezieht sich auf eine oder mehrere Hardwarevorrichtungen zum Speichern von Daten, einschließlich eines Direktzugriffsspeichers (RAM), magnetoresistiven RAM (MRAM), Phasenwechseldirektzugriffsspeichers (PRAM), dynamischen Direktzugriffsspeichers (DRAM) und/oder synchronen dynamischen Direktzugriffsspeichers (SDRAM), Kernspeichers, Nur-Lese-Speichers (ROM), Magnetplattenspeichermedien, optischen Speichermedien, Flash-SpeicherVorrichtungen oder sonstigen maschinenlesbaren Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann einen Speicher, tragbare oder fixe Speichervorrichtungen, optische Speichervorrichtungen, und verschiedene sonstige Medien, die geeignet sind, Anweisungen oder Daten zu speichern, aufzunehmen oder zu übermitteln, umfassen, ohne jedoch darauf beschränkt zu sein.
• Der Begriff „Schnittstellenschaltungsanordnung“, wie er hierin verwendet wird, bezieht sich auf eine Schaltungsanordnung, die den Austausch von Informationen zwischen zwei oder mehr Komponenten oder Vorrichtungen ermöglicht, ist Teil von dieser oder weist diese auf. Der Begriff „Schnittstellenschaltungsanordnung“ kann sich auf eine oder mehrere Hardwareschnittstellen, zum Beispiel Busse, E/A-Schnittstellen, periphere Komponentenschnittstellen, Netzwerkschnittstellenkarten und/oder dergleichen, beziehen.
• Der Begriff „Nutzergerät“ oder „UE“, wie er hierin verwendet wird, bezieht sich auf eine Vorrichtung mit Funkkommunikationsfähigkeiten und kann einen entfernten Nutzer von Netzwerkressourcen in einem Kommunikationsnetzwerk beschreiben. Der Begriff „Nutzergerät“ oder „UE“ kann als Synonym für Client, Mobiltelefon, Mobilvorrichtung, mobiles Endgerät, Nutzerendgerät, mobile Einheit, Mobilstation, mobiler Nutzer, Teilnehmer, Nutzer, entfernte Station, Zugriffsagent, Nutzeragent, Empfänger, Funkausrüstung, neukonfigurierbare Funkausrüstung, neukonfigurierbare mobile Vorrichtung usw. betrachtet und so bezeichnet werden. Ferner kann der Begriff „Nutzergerät“ oder „UE“ eine beliebige Art von drahtloser/drahtgebundener Vorrichtung oder eine beliebige Rechenvorrichtung einschließlich einer drahtlosen Kommunikationsschnittstelle umfassen.
• Der Begriff „Netzwerkelement“, wie er hierin verwendet wird, bezieht sich auf eine physische oder virtualisierte Ausrüstung und/oder Infrastruktur, die verwendet wird, um drahtgebundene oder drahtlose Kommunikationsnetzwerkdienste bereitzustellen. Der Begriff „Netzwerkelement“ kann als Synonym für einem vernetzten Computer, einer Vernetzungshardware, einer Netzwerkausrüstung, einem Netzwerkknoten, einem Router, einem Schalter, einem Hub, einer Brücke, einer Funknetzwerksteuerung, einer RAN-Vorrichtung, einem RAN-Knoten, einem Gateway, einem Server, einem virtualisierten VNF, NFVI usw. betrachtet werden und/oder so bezeichnet werden.
• Der Begriff „Computersystem“, wie er hierin verwendet wird, bezieht sich auf eine beliebige Art von verschalteten elektronischen Vorrichtungen, Computervorrichtungen oder Komponenten davon. Zusätzlich kann sich der Begriff „Computersystem“ und/oder „System“ auf verschiedene Komponenten eines Computers beziehen, die kommunikativ miteinander gekoppelt sind. Ferner kann sich der Begriff „Computersystem“ und/oder „System“ auf mehrere Computervorrichtungen und/oder mehrere Rechensysteme beziehen, die kommunikativ miteinander gekoppelt und konfiguriert sind, um Rechen- und/oder Vernetzungsressourcen zu teilen.
• Der Begriff „Architektur“, wie er hierin verwendet wird, bezieht sich auf eine Computerarchitektur oder eine Netzwerkarchitektur. Eine „Netzwerkarchitektur“ ist ein physisches und logisches Design oder eine physische und logische Anordnung von Software- und/oder Hardwareelementen in einem Netzwerk einschließlich Kommunikationsprotokollen, Schnittstellen und Medienübertragung. Eine „Computerarchitektur“ ist ein physisches und logisches Design oder eine physische und logische Anordnung von Software- und/oder Hardwareelementen in einem Rechensystem oder einer Rechenplattform einschließlich Technologiestandards für Interaktionen zwischen diesen.
• Der Begriff „Gerät“, „Computergerät“ oder dergleichen, wie er hierin verwendet wird, bezieht sich auf eine Computervorrichtung oder ein Computersystem mit Programmcode (z. B. Software oder Firmware), die bzw. das spezifisch ausgelegt ist, um eine spezifische Rechenressource bereitzustellen. Ein „virtuelles Gerät“ ist ein virtuelles Maschinenbild, das von einer mit einem Hypervisor ausgestatteten Vorrichtung zu implementieren ist, die ein Computergerät virtualisiert oder emuliert oder anderweitig zum Bereitstellen einer spezifischen Rechenressource bestimmt ist.
• Der Begriff „Element“ bezieht sich auf eine Einheit, die auf einer gegebenen Abstraktionsebene unteilbar ist und eine klar definierte Grenze aufweist, wobei ein Element eine beliebige Art von Entität einschließlich zum Beispiel einer oder mehrerer Vorrichtungen, Systeme, Steuerungen, Netzwerkelemente, Module usw. oder Kombinationen davon sein kann. Der Begriff „Vorrichtung“ bezieht sich auf eine physische Entität, die innerhalb einer anderen physischen Entität in ihrer Nähe eingebettet ist oder mit dieser verbunden ist, mit Fähigkeiten, digitale Informationen von oder zu dieser physischen Entität zu transportieren. Der Begriff „Entität“ bezieht sich auf eine unterschiedliche Komponente einer Architektur oder Vorrichtung oder auf Informationen, die als Nutzdaten übertragen werden. Der Begriff „Steuerung“ bezieht sich auf ein Element oder eine Entität, die die Fähigkeit haben, eine physische Entität zu beeinflussen, wie etwa durch Ändern ihres Zustands oder durch Bewirken, dass sich die physische Entität bewegt.
• Der Begriff „Ressource“, wie er hierin verwendet wird, bezieht sich auf eine physische oder virtuelle Vorrichtung, eine physische oder virtuelle Komponente innerhalb einer Rechenumgebung, und/oder eine physische oder virtuelle Komponente innerhalb einer konkreten Vorrichtung, wie etwa Computervorrichtungen, mechanische Vorrichtungen, Speicherplatz, Prozessor-/CPU-Zeit, Prozessor-/CPU-Nutzung, Prozessor- und Beschleunigerauslastungen, Hardwarezeit oder -nutzung, elektrischer Strom, Eingabe-/Ausgabeoperationen, Ports oder Netzwerksockel, Kanal-/Verknüpfungszuweisung, Durchsatz, Speichernutzung, Speicher, Netzwerk, Datenbank und Anwendungen, Auslastungseinheiten und/oder dergleichen. Eine „Hardwareressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die von (einem) physischen Hardwareelement(en) bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die von einer Virtualisierungsinfrastruktur einer Anwendung, einer Vorrichtung, einem System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, die durch Computervorrichtungen/-systeme über ein Kommunikationsnetzwerk zugänglich sind. Der Begriff „Systemressourcen“ kann sich auf eine beliebige Art von gemeinsamen Entitäten zum Bereitstellen von Diensten beziehen und kann Rechen- und/oder Netzwerkressourcen umfassen. Systemressourcen können als eine Gruppe von kohärenten Funktionen, Netzwerkdatenobjekten oder Diensten betrachtet werden, auf die durch einen Server zugegriffen werden kann, wobei sich solche Systemressourcen auf einem einzelnen Host oder mehreren Hosts befinden und eindeutig gekennzeichnet werden können.
• So wie er hierin verwendet wird, bezieht sich der Begriff „Rechenabgabe“ oder „Abgabe“ auf die Übertragung von ressourcenintensiven Rechenaufgaben oder Auslastungen von einer Vorrichtung, einem Rechensystem usw. an eine externe Plattform, wie etwa einen Edge-Knoten/-Server, ein Cluster, Gitter, einen Cloud-Rechendienst, und/oder dergleichen.
• So wie er hierin verwendet wird, kann sich der Begriff „Auslastung“ auf eine Menge an Arbeit beziehen, die von einem Rechensystem, einer Vorrichtung, Entität usw. während eines Zeitraums oder zu einem konkreten Zeitpunkt durchgeführt wird. Eine Auslastung kann als eine Benchmark, wie etwa eine Antwortzeit, ein Durchsatz (z. B. wie viel Arbeit während eines Zeitraums bewerkstelligt wird) und/oder dergleichen, dargestellt werden. Zusätzlich oder alternativ kann die Auslastung als eine Speicherauslastung (z. B. eine Menge an Speicherplatz, der zur Programmausführung zum Speichern von temporären oder dauerhaften Daten und zum Durchführen von Zwischenberechnungen benötigt wird), Prozessorauslastung (z. B. eine Anzahl an Anweisungen, die von dem Prozessor 102 während eines gegebenen Zeitraums oder zu einem konkreten Zeitpunkt ausgeführt werden), eine E/A-Auslastung (z. B. eine Anzahl an Eingaben und Ausgaben oder Systemzugriffen während eines gegebenen Zeitraums oder zu einem konkreten Zeitpunkt), Datenbankauslastungen (z. B. eine Anzahl an Datenbankabfragen während eines Zeitraums), eine netzwerkbezogene Auslastung (z. B. eine Anzahl an Netzwerkverbindungen, eine Anzahl an Mobilitätsaktualisierungen, eine Anzahl an Funkverbindungsfehlern, eine Anzahl an Übergaben, eine Menge von Daten, die über eine Luftschnittstelle zu übertragen sind, usw.) und/oder dergleichen dargestellt werden. Es können verschiedene Algorithmen verwendet werden, um eine Auslastung und/oder Auslastungsmerkmale zu bestimmen, welche auf einer der zuvor genannten Auslastungsarten basieren können.
• Der Begriff „Kanal“, wie er hierin verwendet wird, bezieht sich auf ein beliebiges Übertragungsmedium, entweder greifbar oder nicht-greifbar, welches zum Kommunizieren von Daten oder eines Datenstroms verwendet wird. Der Begriff „Kanal“ kann Synonym für und/oder äquivalent zu „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugriffskanal“, „Datenzugriffskanal“, „Verknüpfung“, „Datenverknüpfung“, „Träger“, „Funkfrequenzträger“ und/oder einem beliebigen sonstigen ähnlichen Begriff sein, der einen Pfad oder ein Medium bezeichnet, durch welchen bzw. welches Daten kommuniziert werden. Zusätzlich bezieht sich der Begriff „Verknüpfung“, wie er hierin verwendet wird, auf eine Verbindung zwischen zwei Vorrichtungen durch eine RAT zum Zwecke des Übertragens und Empfangens von Informationen.
• So wie er hierin verwendet wird, bezieht sich der Begriff „Funktechnologie“ auf Technologie zum drahtlosen Übertragen und/oder Empfangen von elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugriffstechnologie“ oder „RAT“ bezieht sich auf die Technologie, die für die zugrundeliegende physische Verbindung mit einem funkbasierten Kommunikationsnetzwerk verwendet wird.
• So wie er hierin verwendet wird, bezieht sich der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) auf eine Gruppe von standardisierten Regeln oder Anweisungen, die von einer Kommunikationsvorrichtung und/oder einem Kommunikationssystem zum Kommunizieren mit anderen Vorrichtungen und/oder Systemen implementiert werden, einschließlich Anweisungen zum Paketieren/Entpaketieren von Daten, Modulieren/Demodulieren von Signalen, Implementieren von Protokollstapeln und/oder dergleichen. Beispiele für Drahtloskommunikationsprotokolle können in verschiedenen Ausführungsformen einschließlich einer GSM-Funkkommunikationstechnologie (Global System for Mobile Communications radio communication technology), einer GPRS-Funkkommunikationstechnologie (General Packet Radio Service radio communication technology), einer EDGE-Funkkommunikationstechnologie (Enhanced Data Rates for GSM Evolution radio communication technology) und/oder einer 3GPP-Funkkommunikationstechnologie (Third Generation Partnership Project radio communication technology) einschließlich zum Beispiel 3GPP Fifth Generation (5G) oder New Radio (NR), Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), Long Term Evolution (LTE), LTE-Advanced (LTE Advanced), LTE Extra, LTE-A Pro, cdmaOne (2G), Code Division Multiple Access 2000 (CDMA 2000), Cellular Digital Packet Data (CDPD), Mobitex, Circuit Switched Data (CSD), High-Speed CSD (HSCSD), Universal Mobile Telecommunications System (UMTS), Wideband Code Division Multiple Access (W-CDM), High Speed Packet Access (HSPA), HSPA Plus (HSPA+), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), LTE LAA, MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UTRA (E-UTRA), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (AMPS), Digital AMPS (D-AMPS), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Push-totalk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), Cellular Digital Packet Data (CDPD), DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Personal Handy-phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA) (auch als 3GPP Generic Access Network-Standard oder GAN-Standard bezeichnet), Bluetooth®, Bluetooth Low Energy (BLE), IEEE 802.15.4-basierte Protokolle (z. B. IPv6 over Low power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread, 802.11a usw.) WiFi-direct, ANT/ANT+, ZigBee, Z-Wave, 3GPP device-to-device (D2D) oder Proximity Services (ProSe), Universal Plug and Play (UPnP), Low-Power Wide-Area-Network (LPWAN), Long Range Wide Area Network (LoRA) oder LoRaWAN™, entwickelt von Semtech und der LoRa-Allianz, Sigfox, der Standard Wireless Gigabit Alliance (WiGig), Worldwide Interoperability for Microwave Access (WiMAX), mmWave-Standards im Allgemeinen (z. B. drahtlose Systeme, die mit 10 - 300 GHz und darüber funktionieren, wie etwa WiGig, IEEE 802.11ad, IEEE 802.11ay usw.), V2X-Kommunikationstechnologien (einschließlich 3GPP C-V2X), DSRC-Kommunikationssysteme (Dedicated Short Range Communications communication systems), wie etwa intelligente Transportsysteme (ITS) einschließlich der europäischen ITS-G5, ITS-G5B, ITS-G5C usw. Zusätzlich zu den zuvor aufgeführten Standards kann eine beliebige Anzahl an Satelliten-Uplink-Technologien zum Zwecke der vorliegenden Offenbarung, einschließlich zum Beispiel Funkgeräte, die Standards entsprechen, die unter anderem von der International Telecommunication Union (ITU) oder dem European Telecommunications Standards Institute (ETSI) herausgegeben werden, verwendet werden. Die hierin bereitgestellten Beispiele werden somit derart verstanden, dass sie bei verschiedenen anderen Kommunikationstechnologien, sowohl vorhandenen als auch noch zu formulierenden, angewendet werden können.
• Die Begriffe „instantiieren“, „Instantiierung“ und dergleichen, wie sie hierin verwendet werden, beziehen sich auf die Erstellung einer Instanz. Eine „Instanz“ bezieht sich auch auf ein konkretes Auftreten eines Objekts, was zum Beispiel während der Ausführung von Programmcode auftreten kann. Der Begriff „Informationselement“ bezieht sich auf ein strukturelles Element, das ein oder mehrere Felder enthält. Der Begriff „Feld“ bezieht sich auf einzelnen Content eines Informationselements oder ein Datenelement, das Content enthält. So wie sie hierin verwendet werden, können sich ein „Datenbankobjekt“, eine „Datenstruktur“ oder dergleichen auf eine beliebige Darstellung von Informationen beziehen, die in Form eines Objekts, Attribut-Wert-Paars (AVP, Attribute-Value Pair), Schlüssel-Wert-Paar (KVP, Key-Value Pair), Tupel usw. vorliegt, und können Variablen, Datenstrukturen, Funktionen, Verfahren, Klassen, Datenbankaufzeichnungen, Datenbankfelder, Datenbankentitäten, Verknüpfungen zwischen Daten und/oder Datenbankentitäten (auch als eine „Beziehung“ bezeichnet), Blöcke und Verknüpfungen zwischen Blöcken in Blockkettenimplementierungen und/oder dergleichen umfassen.
• Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“, zusammen mit Ableitungen davon, werden hierin verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt zueinander stehen, dass sich zwei oder mehr Elemente indirekt einander berühren, jedoch immer noch miteinander kooperieren oder interagieren, und/oder dass ein oder mehr andere Elemente zwischen den Elementen, die miteinander gekoppelt sein sollen, gekoppelt oder verbunden sind. Der Ausdruck „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt zueinander stehen. Der Ausdruck „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente durch eine Kommunikation einschließlich durch einen Draht oder eine sonstige Interconnectverbindung, durch einen Drahtloskommunikationskanal oder eine Drahtloskommunikationsverknüpfung und/oder dergleichen in Kontakt zueinander stehen können.
• Der Begriff „lokalisiertes Netzwerk“, wie er hierin verwendet wird, kann sich auf ein lokales Netzwerk beziehen, das eine beschränkte Anzahl an verbundenen Fahrzeugen in einem bestimmten Bereich oder einer bestimmten Region abdeckt. Der Begriff „verteiltes Rechnen“, wie er hierin verwendet wird, kann sich auf Rechenressourcen beziehen, die geografisch innerhalb der Nähe von einer oder mehreren lokalisierten Netzwerkendungen verteilt sind. Der Ausdruck „Plattform zur Integration von lokalen Daten“, wie er hierin verwendet wird, kann sich auf eine Plattform, eine Vorrichtung, ein System, ein Netzwerk, oder (ein) Element(e) beziehen, die lokale Daten durch Verwenden einer Kombination von (einem) lokalisierten Netzwerk(en) und verteilter Berechnung integrieren, beziehen.
• Die vorherige Beschreibung stellt eine Veranschaulichung und Beschreibung verschiedener beispielhafter Ausführungsformen bereit, soll jedoch nicht abschließend sein oder den Umfang der Ausführungsformen auf die genauen offenbarten Formen beschränken. Modifikationen und Variationen sind im Lichte der vorherigen Lehren möglich oder können anhand der Anwendung verschiedener Ausführungsformen erhalten werden. Dort, wo spezifische Details dargelegt sind, um beispielhafte Ausführungsformen der Offenbarung zu beschreiben, sollte für einen Fachmann offensichtlich sein, dass die Offenbarung ohne diese spezifischen Details oder mit einer Abänderung dieser spezifischen Details praktiziert werden kann. Es versteht sich jedoch, dass die Konzepte der vorliegenden Offenbarung nicht auf die konkreten offenbarten Formen beschränkt werden sollen, sondern im Gegenteil alle Modifikationen, Äquivalente und Alternativen, die in Einklang mit der vorliegenden Offenbarung und den beigefügten Ansprüchen stehen, von der Erfindung abgedeckt werden sollen.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• US 62/682732 [0001]

Claims (25)

1. Integrierte Schaltung (IC) zum Verwalten von Fahrzeugnutzergerätkommunikationen (vUE-Kommunikationen), wobei die IC Folgendes aufweist: eine Schnittstellenanordnung, die eingerichtet ist, um die IC mit einer oder mehreren straßenseitigen Einheiten (RSUs) zu koppeln, wobei jede RSU der einen oder mehreren RSUs eingerichtet ist, um mit einem oder mehreren Fahrzeugnutzergeräten (vUEs) zu kommunizieren, die sich durch jeweilige Abdeckungsbereiche der einen oder mehreren RSUs fortbewegen; und eine Prozessorschaltungsanordnung, die mit der Schnittstellenschaltungsanordnung gekoppelt ist, wobei die Prozessorschaltungsanordnung eingerichtet ist, um: eine erste Anzahl an ersten vUEs und eine zweite Anzahl an zweiten vUEs, die in den jeweiligen Abdeckungsbereichen während jeweiligen Dienstzeiträumen zu bedienen sind, zu bestimmen, wobei die ersten vUEs gemäß einer ersten Funkzugriffstechnologie (RAT) kommunizieren und die zweiten vUEs gemäß einer zweiten RAT kommunizieren; Ressourcenzuweisungen zum Bereitstellen von ersten RAT-Kommunikationsdiensten für die ersten vUEs und zweiten RAT-Kommunikationsdiensten für die zweiten vUEs basierend auf der ersten Anzahl und der zweiten Anzahl zu bestimmen; und Ressourcen basierend auf den bestimmten Ressourcenzuweisungen zuzuweisen.
2. IC nach Anspruch 1, wobei: die Bestimmung der Ressourcenzuweisungen umfasst, zu bestimmen, dass ein erster Kanal zum Bereitstellen der ersten RAT-Kommunikationsdienste zu verwenden ist und ein zweiter Kanal zum Bereitstellen der zweiten RAT-Kommunikationsdienste zu verwenden ist; und die Zuweisung der Ressourcen umfasst, den ersten Kanal für die ersten RAT-Kommunikationsdienste zuzuweisen und die zweiten Kanäle für die zweiten RAT-Kommunikationsdienste zuzuweisen.
3. IC nach Anspruch 2, wobei: die Bestimmung der Ressourcenzuweisungen umfasst, zu bestimmen, dass ein dritter Kanal zum Bereitstellen sowohl der ersten RAT-Kommunikationsdienste als auch der zweiten RAT-Kommunikationsdienste zu verwenden ist, und die Zuweisung der Ressourcen umfasst, den dritten Kanal für die ersten RAT-Kommunikationsdienste und die zweiten RAT-Kommunikationsdienste zuzuweisen.
4. IC nach Anspruch 3, wobei: die Bestimmung der Ressourcenzuweisung umfasst, einen ersten Dienstzeitraum der jeweiligen Dienstzeiträume, während welchem die ersten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, und einen zweiten Dienstzeitraum der jeweiligen Dienstzeiträume, während welchem die zweiten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, zu bestimmen; und die Zuweisung der Ressourcen umfasst, den dritten Kanal für die ersten RAT-Kommunikationsdienste während des ersten Dienstzeitraums zuzuweisen und den dritten Kanal für die zweiten RAT-Kommunikationsdienste während des zweiten Dienstzeitraums zuzuweisen.
5. IC nach Anspruch 1, wobei die Prozessorschaltungsanordnung ferner eingerichtet ist, um die Schnittstellenschaltungsanordnung zu verwenden, um eine Ressourcenzuweisungsnachricht zu der einen oder den mehreren RSUs über jeweilige drahtgebundene oder drahtlose Verknüpfungen zwischen einem System, das die IC hostet, und der einen oder den mehreren RSUs zu senden.
6. IC nach Anspruch 5, wobei die Prozessorschaltungsanordnung ferner eingerichtet ist, um: die Ressourcenzuweisungsnachricht zum Aufnehmen einer Gesamtzahl an verfügbaren Kanälen, einer Bandbreite und eines Frequenzträgers jedes Kanals, einer bevorzugten Nutzung für jede RSU der einen oder mehreren RSUs, der ersten Anzahl der ersten vUEs, der zweiten Anzahl der zweiten vUEs, oder eines Zeitraums, während welchem die erste Anzahl und die zweite Anzahl bestimmt wurden, zu erzeugen.
7. IC nach Anspruch 6, wobei zum Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs die Prozessorschaltungsanordnung eingerichtet ist, um: Signale zu messen, die von den ersten vUEs und den zweiten vUEs übertragen werden; zu bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an gemessenen Signalen ist, die in einem ersten Frequenzband übertragen wird; und zu bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an gemessenen Signalen ist, die in einem zweiten Frequenzband übertragen wird.
8. IC nach Anspruch 6, wobei zum Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs die Prozessorschaltungsanordnung eingerichtet ist, um: Anforderungsnachrichten von den ersten vUEs und den zweiten vUEs zu erhalten; zu bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der ersten vUEs erhalten wird; und zu bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der zweiten vUEs erhalten wird.
9. IC nach einem der Ansprüche 1-8, die ferner Folgendes aufweist: eine Speicherschaltungsanordnung, die kommunikativ mit der Prozessorschaltungsanordnung gekoppelt ist, wobei die Speicherschaltungsanordnung eingerichtet ist, um Programmcode eines ersten RAT-Moduls und eines zweiten RAT-Moduls zu speichern, und wobei zum Zuweisen der Ressourcen die Prozessorschaltungsanordnung ferner eingerichtet ist, um: mindestens eine RSU der einen oder mehreren RSUs mit dem ersten RAT-Modul zu konfigurieren, um die ersten RAT-Kommunikationsdienste bereitzustellen; und mindestens eine andere RSU der einen oder mehreren RSUs mit dem zweiten RAT-Modul zu konfigurieren, um die zweiten RAT-Kommunikationsdienste bereitzustellen.
10. IC nach Anspruch 9, wobei eine straßenseitige Einheit (RSU) die IC hostet oder die IC von einem Rechensystem eines Cloud-Computing-Dienstes gehostet wird.
11. Fahrzeugnutzergerät (vUE), das Folgendes aufweist: Nachrichtenerzeugungsmittel zum Erzeugen einer Nachricht gemäß einer Vehicle-to-everything-Funkzugriffstechnologie (V2X RAT); und Kommunikationsmittel zum Übertragen der Nachricht zu einem Zielknoten gemäß dem V2X RAT-Protokoll, wobei die Nachricht bewirkt, dass der eine oder die mehreren RAN-Knoten einen oder mehrere Frequenzkanäle für V2X RAT-Kommunikationen zuweisen.
12. vUE nach Anspruch 11, wobei die V2X RAT eine erste V2X RAT ist, und wobei das Kommunikationsmittel ein erstes Kommunikationsmittel ist, und wobei das vUE ferner Folgendes aufweist: ein zweites Kommunikationsmittel zum Kommunizieren gemäß einer zweiten V2X RAT, die sich von der ersten V2X RAT unterscheidet.
13. vUE nach Anspruch 12, wobei der Zielknoten ein anderes vUE oder ein Funkzugriffsnetzwerkknoten (RAN-Knoten) ist, und das Nachrichtenerzeugungsmittel dem Erzeugen der Nachricht zum Aufnehmen von einer oder mehreren vUE-Fähigkeiten dient, wobei die eine oder die mehreren vUE-Fähigkeiten eine Unterstützung für die erste V2X RAT und die zweite V2X RAT angeben.
14. vUE nach Anspruch 11, wobei der Zielknoten ein RAN-Knoten ist und das Nachrichtenerzeugungsmittel dem Erzeugen der Nachricht zum Aufnehmen einer Anforderung in Bezug auf die Unterstützung der V2X RAT dient.
15. vUE nach Anspruch 14, wobei das Kommunikationsmittel ferner dem Erhalten einer Empfangsbestätigungsnachricht (ACK-Nachricht) von dem RAN-Knoten, die den Erhalt der Nachricht bestätigt, und dem Kommunizieren mit einem oder mehreren anderen vUEs gemäß der V2X RAT basierend auf dem Erhalt der ACK-Nachricht dient.
16. Verfahren zum dynamischen Zuweisen von Vehicle-to-everything-Ressourcen (V2X-Ressourcen) zu Fahrzeugnutzergeräten (vUEs), wobei das Verfahren Folgendes umfasst: Bestimmen einer ersten Anzahl an ersten vUEs und einer zweiten Anzahl an zweiten vUEs, die von einer oder mehreren straßenseitigen Einheiten (RSUs) in jeweiligen Abdeckungsbereichen während jeweiligen Dienstzeiträumen zu bedienen sind, wobei die ersten vUEs konfiguriert sind, unter Verwendung einer ersten V2X-Funkzugriffstechnologie (V2X RAT) zu kommunizieren, und die zweiten vUEs konfiguriert sind, unter Verwendung einer zweiten V2X RAT zu kommunizieren; Zuweisen von Ressourcen für die erste V2X RAT und die zweite V2X RAT basierend auf der ersten Anzahl und der zweiten Anzahl; Bestimmen einer V2X-Konfiguration basierend auf den zugewiesenen Ressourcen, wobei die V2X-Konfiguration angibt, wann erste V2X RAT-Kommunikationsdienste den ersten vUEs bereitzustellen sind und zweite V2X RAT-Kommunikationsdienste den zweiten vUEs bereitzustellen sind; und Senden der V2X-Konfiguration zu der einen oder den mehreren RSUs.
17. Verfahren nach Anspruch 16, wobei das Zuweisen der Ressourcen das Bestimmen eines ersten Kanals, der zum Bereitstellen der ersten V2X RAT-Kommunikationsdienste zu verwenden ist, und eines zweiten Kanals, der zum Bereitstellen der zweiten V2X RAT-Kommunikationsdienste zu verwenden ist; das Zuweisen des ersten Kanals für die ersten V2X RAT-Kommunikationsdienste; und das Zuweisen des zweiten Kanals für die zweiten V2X RAT-Kommunikationsdienste umfasst.
18. Verfahren nach Anspruch 17, wobei das Zuweisen der Ressourcen das Bestimmen eines dritten Kanals, der zum Bereitstellen sowohl der ersten V2X RAT-Kommunikationsdienste als auch der zweiten V2X RAT-Kommunikationsdienste zu verwenden ist; und das Zuweisen des dritten Kanals für die ersten V2X RAT-Kommunikationsdienste und die zweiten V2X RAT-Kommunikationsdienste umfasst.
19. Verfahren nach Anspruch 18, wobei die V2X-Konfiguration ferner einen ersten Dienstzeitraum der jeweiligen Dienstzeiträume, während welchem die ersten RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, und einen zweiten Dienstzeitraum der jeweiligen Dienstzeiträume, während welchem die zweiten V2X RAT-Kommunikationsdienste in dem dritten Kanal bereitzustellen sind, angibt, und wobei das Zuweisen der Ressourcen das Zuweisen des dritten Kanals für die ersten V2X RAT-Kommunikationsdienste während des ersten Dienstzeitraums und das Zuweisen des dritten Kanals für die zweiten V2X RAT-Kommunikationsdienste während des zweiten Dienstzeitraums umfasst.
20. Verfahren nach Anspruch 16, das ferner Folgendes umfasst: Erzeugen einer V2X-Konfigurationsnachricht zum Aufnehmen einer Gesamtzahl von verfügbaren Kanälen, einer Bandbreite und eines Frequenzträgers jedes Kanals, einer bevorzugten Nutzung für jede RSU der einen oder mehreren RSUs, der ersten Anzahl der ersten vUEs, der zweiten Anzahl der zweiten vUEs, oder eines Zeitraums, während welchem die erste Anzahl und die zweite Anzahl bestimmt wurden; und Senden der V2X-Konfigurationsnachricht zu der einen oder den mehreren RSUs über jeweilige drahtgebundene oder drahtlose Verknüpfungen.
21. Verfahren nach Anspruch 16, das ferner Folgendes umfasst: Konfigurieren der einen oder mehreren RSUs mit einer ersten V2X RAT-Komponente während eines ersten Dienstzeitraums der jeweiligen Dienstzeiträume, wobei die erste V2X RAT-Komponente der einen oder den mehreren RSUs ermöglicht, die ersten RAT-Kommunikationsdienste bereitzustellen; und Konfigurieren der einen oder mehreren RSUs mit der zweiten V2X RAT-Komponente während eines zweiten Dienstzeitraums der jeweiligen Dienstzeiträume, wobei die zweite V2X RAT-Komponente der einen oder den mehreren RSUs ermöglicht, die zweiten V2X RAT-Kommunikationsdienste bereitzustellen.
22. Verfahren nach Anspruch 16, das ferner Folgendes umfasst: Konfigurieren mindestens einer RSU der einen oder mehreren RSUs mit einer ersten V2X RAT-Komponente, wobei die erste V2X RAT-Komponente der mindestens einen RSU ermöglicht, die ersten RAT-Kommunikationsdienste bereitzustellen; und Konfigurieren mindestens einer anderen RSU der einen oder mehreren RSUs mit einer zweiten V2X RAT-Komponente, wobei die zweite V2X RAT-Komponente der mindestens einen anderen RSU ermöglicht, die zweiten V2X RAT-Kommunikationsdienste bereitzustellen.
23. Verfahren nach Anspruch 22, wobei das Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs Folgendes umfasst: Bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Nachrichten ist, die von vUEs in einem ersten Frequenzband erhalten wird; und Bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Nachrichten ist, die von vUEs in einem zweiten Frequenzband erhalten wird.
24. Verfahren nach Anspruch 22, wobei zum Bestimmen der ersten Anzahl der ersten vUEs und der zweiten Anzahl der zweiten vUEs die Prozessorschaltungsanordnung eingerichtet ist, um: Anforderungsnachrichten von den ersten vUEs und den zweiten vUEs zu erhalten; zu bestimmen, dass die erste Anzahl der ersten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der ersten vUEs erhalten wird; und zu bestimmen, dass die zweite Anzahl der zweiten vUEs eine Anzahl an Anforderungsnachrichten ist, die von entsprechenden der zweiten vUEs erhalten wird.
25. Ein oder mehrere computerlesbare Speichermedien, die Anweisungen aufweisen, wobei die Ausführung der Anweisungen durch einen oder mehrere Prozessoren bewirkt, dass ein Rechensystem das Verfahren nach einem der Ansprüche 16-24 durchführt.

Images