DE112020002310T5 - V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen - Google Patents

V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen Download PDF

Info

Publication number
DE112020002310T5
DE112020002310T5 DE112020002310.9T DE112020002310T DE112020002310T5 DE 112020002310 T5 DE112020002310 T5 DE 112020002310T5 DE 112020002310 T DE112020002310 T DE 112020002310T DE 112020002310 T5 DE112020002310 T5 DE 112020002310T5
Authority
DE
Germany
Prior art keywords
mec
information
service
vue
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112020002310.9T
Other languages
English (en)
Inventor
Miltiadis Filippou
Dario Sabella
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112020002310T5 publication Critical patent/DE112020002310T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0226—Traffic management, e.g. flow control or congestion control based on location or mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/024—Guidance services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters
    • H04W4/026—Services making use of location information using location based information parameters using orientation information, e.g. compass
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters
    • H04W4/027—Services making use of location information using location based information parameters using movement velocity, acceleration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/18—Communication route or path selection, e.g. power-based or shortest path routing based on predicted events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Offenbarte Ausführungsformen betreffen Techniken zum Implementieren von Vehicle-to-Everything(V2X)-Kommunikationen in Mehrfachzugriffs-Edge-Computing- bzw. MEC(Multi-Access Edge Computing)-Systemen und -Netzwerken. V2X-Systemszenarien sind durch hohe Mobilität und dynamische Topologien gekennzeichnet, wobei die Genauigkeit und Zeitigkeit von Funknetzinformationen, Standortinformationen durch Umgebungsbedingungen und Einsatzdichte der Netzwerkinfrastruktur behindert werden können. Die offenbarten Ausführungsformen stellen ein V2X-Informationsdienst(VIS)-Framework zur kooperativen Erfassung, Partitionierung und Verteilung von Informationen für effiziente, fahrtspezifische Dienstgüte(QoS)-Vorhersagen bereit. Das VIS-Framework identifiziert Raum/Zeit-Korrelationen zwischen in einem oder mehreren V2X-Systemen erfassten Funkzustands-/-qualitätsdaten und einer geplanten Fahrt eines Fahrzeugs zur besseren Vorhersage der Funkzustände/-qualität des Kommunikationsnetzwerks entlang der vorgesehenen Route. Infolgedessen kann das VIS autorisierten Vorrichtungen fahrtspezifische Informationen über die QoS-Vorhersage offenlegen. Andere Ausführungsformen können beschrieben und/oder beansprucht sein.

Description

  • VERWANDTE ANMELDUNGEN
  • Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung 62/844,413 , eingereicht am 7. Mai 2019, und der vorläufigen US-Anmeldung 62/854,871 , eingereicht am 30. Mai 2019, deren Inhalt hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
  • TECHNISCHES GEBIET
  • Hier beschriebene Ausführungsformen betreffen allgemein Edge-Computing-, Netzwerkkommunikations- und Kommunikationssystemimplementierungen und insbesondere Techniken zum Implementieren von Vehicle-to-Everything(V2X)-Kommunikationen in MEC-Systemen und -Netzwerken (MEC: Multi-access Edge Computing).
  • HINTERGRUND
  • Internet-der-Dinge(IoT)-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktuatoren und andere Eingabe/Ausgabe-Komponenten beinhalten können, etwa zum Erfassen von Daten oder Durchführen von Aktionen aus einer realen Umgebung. IoT-Vorrichtungen können zum Beispiel Vorrichtungen mit niedriger Leistung beinhalten, die in alltäglichen Dingen eingebettet oder daran angeschlossen sind, wie etwa Gebäuden, Fahrzeugen, Paketen usw., um ein zusätzliches Niveau künstlicher Sinneswahrnehmung dieser Dinge bereitzustellen. In letzter Zeit sind IoT-Vorrichtungen immer beliebter geworden und daher haben sich Anwendungen, die diese Vorrichtungen verwenden, vermehrt. Der Einsatz von IoT-Vorrichtungen und MEC-Diensten (MEC: Multi-Access Edge Computing) hat eine Reihe von fortgeschrittenen Verwendungsfälle und Szenarien eingeführt, die am Rand des Netzwerks auftreten oder diesen anderweitig involvieren.
  • Diese fortgeschrittenen Verwendungsfälle haben jedoch unter vielen anderen Problemen auch eine Reihe entsprechender technischer Herausforderungen eingeführt, die Sicherheit, Verarbeitungs-/Rechenressourcen, Netzwerkressourcen, Dienstverfügbarkeit und Effizienz betreffen. In Bezug auf Vehicle-to-Everything(V2X)-Dienste gibt es derzeit keine Mechanismen zum effizienten Vorhersagen der Dienstgüte (QoS: Quality of Service) entlang einer geplanten Trajektorie oder Fahrtroute eines Fahrzeugs.
  • Figurenliste
  • In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Ziffern mit verschiedenen angehängten Buchstaben können verschiedene Instanzen ähnlicher Komponenten repräsentieren. Einige Ausführungsformen sind beispielhaft und nicht beschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in denen gilt:
    • 1A und 1B zeigen ein beispielhaftes V2X-Kommunikationssystem, das MEC-Technologie nutzt, die Unterstützung für V2X-Anwendungen bereitstellt, gemäß verschiedenen Ausführungsformen. 2 zeigt ein beispielhaftes V2X-System, das eine MEC-Systemarchitektur beinhaltet, gemäß verschiedenen Ausführungsformen. 3 zeigt eine beispielhafte Architektur, die eine Kommunikation zwischen dem V2X-Informationsdienst (VIS) und einer V2X-Steuerfunktion ermöglicht, gemäß verschiedenen Ausführungsformen. 4 zeigt ein beispielhaftes V2X-Systemszenario, bei dem ein MEC-Host zusammen mit einem Netzwerkzugangsknoten (NAN) angeordnet ist, der V2X-Kommunikationsdienste für Fahrzeugbenutzergeräte (UEs) bereitstellt, gemäß verschiedenen Ausführungsformen. 5 zeigt einen beispielhaften fahrtspezifischen QoS-Prozess gemäß verschiedenen Ausführungsformen.
    • 7 zeigt einen beispielhaften fahrtspezifischen QoS-Benachrichtigungsprozess gemäß einer ersten Ausführungsform. 8 zeigt ein anderes beispielhaftes Szenario eines MEC-Hosts, der zusammen mit einem NAN angeordnet ist, der V2X-Kommunikationsdienste bereitstellt, gemäß verschiedenen Ausführungsformen. 8 zeigt ein beispielhaftes geschichtetes MEC-System, das einen Master-MEC-Host, der zusammen mit einem NAN angeordnet ist, und fahrzeuginterne MEC-Hosts, die zusammen mit einem jeweiligen vUE angeordnet sind, umfasst. 9 zeigt ein Informationserfassungsframework gemäß den verschiedenen Ausführungsformen. 10 zeigt einen beispielhaften QoS-Benachrichtigungsprozess gemäß einer zweiten Ausführungsform. 11 zeigt beispielhafte V2X-Prozeduren gemäß verschiedenen Ausführungsformen. 12 zeigt eine beispielhafte Universalressourcenindikator(URI)-Struktur einer VIS-API gemäß verschiedenen Ausführungsformen.
    • 13 veranschaulicht eine beispielhafte 5G-Systemarchitektur, die in einem Edge-Computing-System einsetzbar ist. 14 veranschaulicht eine 5G-dienstbasierte Architektur und eine MEC-Architektur, die in einem beispielhaften Edge-Computing-System einsetzbar sind, und einen integrierten MEC-Einsatz in einem 5G-Netzwerk, das mit einem beispielhaften Edge-Computing-System verwendbar ist. 15 veranschaulicht eine beispielhafte MEC-Systemreferenzarchitektur. 16 veranschaulicht eine MEC-Referenzarchitektur in einer Netzwerkfunktionsvirtualisierungs(NFV)-Umgebung, die von einem beispielhaften Edge-Computing-System einsetzbar ist.
    • 17A, 17B und 17C zweigen Beispiele für Edge-Computing-Hardwarekonfigurationen. 18 und 19 zeigen beispielhafte Komponenten verschiedener Rechenknoten in einem oder mehreren Edge-Computing-Systemen. 20 zeigt eine beispielhafte mobile Rechenvorrichtung in einem Edge-Computing-System. 21 zeigt ein Beispiel für ein konfigurierbares Server-Rack in einem Edge-Computing-System.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgenden Ausführungsformen betreffen allgemein Datenverarbeitungs-, Dienstverwaltungs-, Ressourcenzuweisungs-, Rechenverwaltungs-, Netzwerkkommunikations-, Anwendungspartionierungs- und Kommunikationssystemimplementierungen, und insbesondere Techniken und Konfigurationen zum Anpassen verschiedener Edge-Computing-Vorrichtungen und - Entitäten, um mehrere Entitäten (z. B. mehrere Mandanten, Benutzer, Stakeholder, Dienstinstanzen, Anwendungen usw.) in einer verteilten Edge-Computing-Umgebung dynamisch zu unterstützen. Insbesondere betreffen offenbarte Ausführungsformen Techniken zum Implementieren von Vehicle-to-Everything(V2X)-Kommunikationen in Mehrfachzugriffs-Edge-Computing(MEC)-Systemen. V2X-Systemszenarien sind durch hohe Mobilität und dynamische Topologien gekennzeichnet, wobei die Genauigkeit und Zeitigkeit von Funknetzinformationen, Standortinformationen durch Umgebungsbedingungen und Einsatzdichte der Netzwerkinfrastruktur behindert werden können. Die offenbarten Ausführungsformen stellen ein V2X-Informationsdienst(VIS)-Framework zur kooperativen Erfassung, Partitionierung und Verteilung von Informationen für effiziente, fahrtspezifische Dienstgüte(QoS)-Vorhersagen bereit. Das VIS-Framework identifiziert Raum/Zeit-Korrelationen zwischen in einem oder mehreren V2X-Systemen erfassten Funkzustands-/-qualitätsdaten und einer geplanten Fahrt eines Fahrzeugs zur besseren Vorhersage der Funkzustände/-qualität des Kommunikationsnetzwerks entlang der vorgesehenen Route. Infolgedessen kann das VIS autorisierten Vorrichtungen fahrtspezifische Informationen über die QoS-Vorhersage offenlegen. Andere Ausführungsformen können beschrieben und/oder beansprucht sein. Genaue und rechtzeitige Vorhersagen der Funkumgebung an verschiedenen Zwischenstandorten entlang einer geplanten Route/Fahrt können eine Freigabe/Aktivierung bestimmter V2X-Funktionalitäten und/oder Datentransfers zwischen Benutzergerät (UE) und Netzwerkinfrastruktur (einschließlich Downlink(DL)- und Uplink(UL)-Datentransfers) entweder auslösen, modifizieren oder verschieben. Andere Ausführungsformen können beschrieben und/oder beansprucht sein.
  • I. MEC-V2X-INFORMATIONSDIENSTE (VIS)
  • Die Vehicle-to-Everything(V2X)-Anwendungen (einfach als „V2X“ bezeichnet) beinhalten die folgenden vier Arten von Kommunikationen: Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Infrastruktur (V2I); Fahrzeug-zu-Netzwerk (V2N) und Fahrzeug-zu-Fußgänger-Kommunikationen (V2P). V2X-Anwendungen können kooperatives Bewusstsein verwenden, um intelligentere Dienste für Endbenutzer bereitzustellen. Dies bedeutet, dass Entitäten, wie etwa Fahrzeugstationen oder Fahrzeugbenutzergeräte (vUEs), Straßenrandinfrastruktur oder Straßenrandeinheiten (RSUs), Anwendungsserver und Fußgängervorrichtungen (z. B. Smartphones, Tablets usw.), Kenntnis ihrer lokalen Umgebung erlangen (z. B. Informationen, die von anderen Fahrzeugen oder Sensorgeräten in der Nähe empfangen werden), um diese Kenntnis zu verarbeiten und gemeinsam zu nutzen, um intelligentere Dienste bereitzustellen, wie etwa kooperative Wahrnehmung, Manöverkoordination und dergleichen, die für Kollisionswarnsysteme, autonomes Fahren und/oder dergleichen verwendet werden. V2X-Anwendungen nutzen eine zugrundeliegende Zugangstechnologie oder Funkzugangstechnologie (RAT), um Nachrichten für kooperatives Bewusstsein zu übermitteln. Diese RATs können zum Beispiel IEEE-802.11p-basierte Protokolle, wie etwa DSRC und ITS-G5, 3GPPzellenbasierte Protokolle, wie etwa 5G-V2X- und/oder LTE-V2X-Protokolle, beinhalten. Obwohl die Ausführungsformen hierin im Zusammenhang mit Kraftfahrzeugen erörtert werden, können die Ausführungsformen auch auf andere Arten von Fahrzeugen zutreffen, einschließlich Luftfahrzeugen, Wasserfahrzeugen und/oder dergleichen.
  • Mehrfachzugriffs-Edge-Computing (MEC) ist eine Technologie, die ermöglicht, dass Anwendungen am Rand eines Zugangsnetzwerks instanziiert werden, und Benutzergeräten (UEs) eine niedrige Latenz und eine Umgebung in unmittelbarer Nähe bereitstellt. Infolgedessen wird erwartet, dass vertikale Industrien, wie etwa die Automobilindustrie, signifikant von dem Einsatz von MEC-Infrastruktur zusammen mit dem Einsatz von Funkzugangsnetzen (RANs) profitieren. Diese RANs können durch unterschiedliche MNOs betrieben werden und/oder unterschiedliche RATs betreiben.
  • Drahtlose Kommunikation ist eine zentrale Enabling-Technologie kooperativer intelligenter Transportsysteme (ITS). Verkehrsteilnehmer (z. B. Fahrzeuge, Radfahrer und Fußgänger), die an V2X-Kommunikation beteiligt sind, können Dienste verwenden, die von verschiedenen Betreibern bereitgestellt werden, die verschiedene Netzwerke bereitstellen und/oder verschiedene Funkzugangstechnologien (RATs) verwenden. Umgebungen, die Netzwerke beinhalten, die durch unterschiedliche Operationen bereitgestellt werden, und die unterschiedliche RATs beinhalten, werden als „Mehrfachanbieter-, Mehrfachnetzwerk- und Mehrfachzugriffsumgebungen“ bezeichnet. Beispiele für Mehrfachanbieter-, Mehrfachnetzwerk- und Mehrfachzugriffsumgebungen sind in 1A und 1B gezeigt.
  • 1A zeigt ein beispielhaftes V2X-Kommunikationssystem 100, das MEC-Technologie nutzt, die Unterstützung für V2X-Anwendungen bereitstellt. Insbesondere zeigt 1A ein V2X-Kommunikationssystem 100, das die Verwendung eines MEC-Systems involviert, wobei ein Straßenbetreiber (oder ein ITS-Betreiber) darauf abzielt, V2X-Dienste in einer länderübergreifenden, betreiberübergreifenden, anbieterübergreifenden Umgebung anzubieten. Das MEC-System unterstützt und/oder liefert verschiedene Dienste an Endpunktvorrichtungen (z. B. Fahrzeug-UEs (vUEs) 101 in 1A), die jeweils unterschiedliche Anforderungen oder Einschränkungen aufweisen können. Zum Beispiel können manche Dienste Prioritäts- oder Dienstgüte(QoS)-Einschränkungen (z. B. können Verkehrsdaten für autonome vUEs 101 eine höhere Priorität als Infotainmentdaten aufweisen), Zuverlässigkeits- und Belastbarkeits- (z. B. können Verkehrsdaten missionskritische Zuverlässigkeit erfordern, während Infotainmentdaten möglicherweise eine gewisse Fehlervarianz aufweisen dürfen) sowie Leistungs-, Kühlungs- und Formfaktoreinschränkungen aufweisen. Verschiedene Schnittstellen werden von einer UE-Anwendung (App) verwendet, um das MEC-System aufzufordern, eine App (z. B. MEC-App) in dem MEC-System auszuführen oder eine App in das oder aus dem MEC-System zu bewegen. Solche Schnittstellen beinhalten zum Beispiel den Mp3-Referenzpunkt, der für eine interne MEC-Verwaltung verwendet wird, die zum Steuern einer Kommunikation zwischen MEC-Plattformen verwendet wird, und den Mx2-Referenzpunkt, der für einen externen Zugriff verwendet wird.
  • In dem typischen Mehrfachoperatorszenario stellen mehrere Operatoren (z. B. MNO-1 und MNO-2 in 1) Infrastruktur bereit, um Netzwerkkonnektivität für Fahrzeugbenutzergeräte (vUEs) 101 (auch als „Fahrzeugstationen“, „Fahrzeug-ITS-Stationen“ oder „V-ITS-S“ bezeichnet) bereitzustellen, darunter zum Beispiel Netzwerkzugangsknoten (NAN) 110-1 und Kernnetzwerk 150-1, bereitgestellt durch MNO-1, und NAN 110-2 und Kernnetzwerk 150-2, bereitgestellt durch MNO-2. Ein „Betreiber“ bezieht sich auf eine Entität oder Organisation, die Infrastrukturgeräte (einschließlich Funkinfrastruktur, Kernnetzwerk und/oder Backhaul-Infrastruktur und dergleichen) besitzt oder steuert, die notwendig sind, um Kommunikationen und/oder netzwerkbezogene Dienste bereitzustellen, einschließlich Funkspektrumzuweisung, die eine oder mehrere Funkspektrumlizenzen von einer Regulierungsbehörde beinhaltet, abrechnungs- und subskriptionsbezogener Dienste, Vorrichtungsbereitstellung und/oder anderer ähnlicher Dienste. Ein Betreiber stellt technische Fähigkeiten zum Zugreifen auf ein Mobilnetzwerk oder eine Drahtlosumgebung unter Verwendung eines Over-the-Air(OTA)- oder Drahtloskommunikationskanals bereit. Der Begriff „Betreiber“, wie er hier verwendet wird, kann als synonym zu einem Netzwerkbetreiber, Mobilnetzwerkbetreiber (MNO), Mobilfunknetzbetreiber, Drahtlosdienstanbieter, Drahtlosträger, Mobilnetzwerkträger, virtueller MNO und/oder dergleichen angesehen und/oder als solcher bezeichnet werden.
  • Des Weiteren können die NANs 110-1 und 110-2 Makrozellenbasisstationen, Remote Radio Heads (RRHs), Klein- und/oder Mikrozellenbasisstationen, Zugangspunkte (APs) und/oder andere ähnliche Netzwerkelemente sein. Die APs können zum Beispiel Drahtlosrouter, Straßenrand-ITS-Stationen oder Straßenrandeinheiten, Gatewayeinrichtungen, zentrale Hubs oder dergleichen sein. Die Basisstationen können zum Beispiel 3GPP-Long-Term-Evolution(LTE)-evolved-NodeBs (eNBs), 3GPP-5G/NR-Next-Generation-NodeBs (gNBs) und/oder dergleichen sein. Eine Sammlung von NANs 110 kann als „Zugangsebenen-Edge-Netzwerk“ oder „Zugangsebenen-Edge“ bezeichnet werden. Die NANs 110 sind konfigurierbar oder betreibbar zum Durchführen einer Einrichtung von Transportressourcen (z. B. für CDN-Dienste und/oder andere Anwendungsebenendienste) sowie Planungssignalisierungsressourcen zum Bereitstellen eines Netzwerkdienstes des zugrundeliegenden Zugangsnetzwerks/RAT.
  • In dem Beispiel von 1A ist NAN 110-1 zusammen mit einem MEC-Host 140-1 angeordnet und NAN 110-2 zusammen mit einem MEC-Host 140-2 angeordnet. Die MEC-Hosts 140 sind Entitäten, die eine MEC-Plattform und eine Virtualisierungsinfrastruktur enthalten, um MEC-Apps Rechen-, Speicher- und Netzwerkressourcen bereitzustellen. Eine MEC-Plattform ist eine Sammlung von Funktionalität (einschließlich Hardware- und Softwareelementen), die benötigt wird, um MEC-Apps auf einer Virtualisierungsinfrastruktur eines spezifischen MEC-Hosts 140 auszuführen und ihnen zu ermöglichen, MEC-Dienste bereitzustellen und zu konsumieren, und die sich selbst eine Anzahl von MEC-Diensten bereitstellen kann. MEC-Apps sind Anwendungen, die auf einem MEC-Host 140 innerhalb des MEC-Systems 100 instanziiert werden können und potenziell MEC-Dienste bereitstellen oder konsumieren, und MEC-Dienste sind Dienste, die über eine MEC-Plattform entweder durch die MEC-Plattform selbst oder durch eine MEC-App bereitgestellt werden. Die MEC-Hosts 140 können durch MNO-1 bzw. MNO-2 bereitgestellt werden, oder die MEC-Hosts 140 können durch einen separaten Edge-Networking-Dienstanbieter bereitgestellt werden. Bei diesem Beispiel ist das vUE 101 bei T1 in der Lage, Netzwerkkonnektivität von MNO-1 über den NAN 110-1 und das Kernnetzwerk 150-1 zu empfangen, und ist in der Lage, Dienste von dem Fernanwendungsserver 160 über die MNO-1-Infrastruktur zu empfangen. Während sich das vUE 101 fortbewegt, erfährt das vUE 101 bei T2 eine temporäre Abwesenheit einer Funkabdeckung, was zu einer Roaming-Situation führt, und ist dann in der Lage, einen Dienst über die MNO-2-Infrastruktur (z. B. der NAN 110-2 und das Kernnetzwerk 150-2) zu empfangen. Die Kernnetzwerke 150 können zum Beispiel LTE- oder SG/NR-Kernnetzwerke sein.
  • Eine herausfordernde Situation ist, wenn ITS-Betreiber versuchen, den gleichen oder kontinuierlichen V2X-Dienst an vUEs 101, die mit verschiedenen Betreibern (z. B. MNO-1 und MNO-2) verbunden sind, selbst bei vorübergehender Abwesenheit einer Funkabdeckung bereitzustellen. Dieser Verwendungsfall ist aufgrund des Vorhandenseins mehrerer MEC-Anbieter kompliziert, was zu der Notwendigkeit führt, eine Kommunikation zwischen verschiedenen MEC-Systemen zu ermöglichen. Dieser Verwendungsfall ist ferner kompliziert, wenn UE-Apps relativ hohe QoS-Einschränkungen aufweisen. Des Weiteren garantiert die Zuweisung ausreichender Funkressourcen innerhalb eines Zellenabdeckungsbereichs eines NAN 110 nicht notwendigerweise eine bestimmte QoS (oder QoS-Leistungsfähigkeit) in V2X-Kommunikationen. Eine schlechte QoS-Leistungsfähigkeit ist auch mit schlechtem Signalempfang aufgrund fehlender Abdeckung, Signalstörung, ineffizienter Handover-Mechanismen und inadäquaten Übertragungsleistungsverwaltungs- und Handover-Mechanismen in den NANs 110 verknüpft.
  • Wie in 1B gezeigt, wird in einem traditionellen V2X-System (ohne VIS-Dienst) die Verbindung zwischen MNOs (z. B. MNO-1 und MNO-2) auf der entfernten Seite (z. B. Fernanwendungsserver 160) beendet, mit deutlichen Nachteilen hinsichtlich einer hohen Ende-zu-Ende(e2e)-Latenz. Andererseits kann durch Nutzung des VIS-Dienstes, der eine „horizontale Kommunikation“ über die Verbindung 188 zwischen MEC-Systemen 140 ermöglicht, die Verbindung zwischen NMOs mit niedriger e2e-Latenz realisiert werden. VIS zeigt Informationen über PC5-Konfigurationsparameter zusammen mit Informationen bezüglich der Uu-Schnittstelle (z. B. Unicast and Multimedia Broadcast Multicast Service (MBMS)) und verwaltet Multi-Operator Umgebungen, was ermöglicht, dass vUEs 101, die den Abdeckungsbereich eines MNO-1 verlassen und in den Abdeckungsbereich eines anderen MNO-2 eintreten, weiterhin einen Dienst ohne jegliche Dienststörung und unter Garantie einer e2e-Leistungsfähigkeit empfangen.
  • V2X-Anwendungen und -Dienste beinhalten zum Beispiel Sicherheits-Apps/Dienste, Komfort-Apps/Dienste, Fahrassistenz-Apps/Dienste und Gefährdete-Verkehrsteilnehmer(VRU: Vulnerable Road User)-Apps/Dienste unter vielen anderen. Beispiele für die Sicherheits-Apps/Dienste umfassen Interection Movement Assist (IMA) und Stauwarnung (QW: Queue Warning). IMA ist dazu ausgelegt, Zusammenstöße an Kreuzungen zu vermeiden, indem Fahrer von Fahrzeugen, die sich an einer Kreuzung aus seitlicher Richtung nähern, gewarnt werden. Zu Zusammenstößen an Kreuzungen gehören Kreuzungs-, kreuzungsbezogene, Einfahrt-/Zufahrt- und einfahrtzugangsbezogene Zusammenstöße. Eine QW-Fahrzeugschlange auf der Straße kann eine potenzielle Gefahr darstellen und eine Verkehrsverzögerung verursachen (z. B. wenn sich eine Abbiegeschlange auf andere Spuren ausweitet). Unter Verwendung der V2X-Dienste können die Stauinformationen zuvor anderen vUEs 101 zur Verfügung gestellt werden, was die Wahrscheinlichkeit von Zusammenstößen minimiert und Abschwächungsmaßnahmen ermöglicht.
  • Komfort-Apps/Dienste beinhalten zum Beispiel Telematik, Softwareaktualisierungen, Infotainment und dergleichen. Einige dieser Apps/Dienste können mit bestehender Zugangstechnologie implementiert werden und werden teilweise bereits von einigen Automobilherstellern unterstützt. Diese Gruppe von V2X-Verwendungsfällen erfordert, dass eine kostengünstige Kommunikation zwischen den vUEs 101 und Backend-Servern/Diensten ermöglicht wird.
  • Fahrassistenz-Apps/Dienste (auch als „Fahrerassistenzsysteme“ oder „FAS“ bezeichnet) sind elektronische Systeme (umfassend Hardware- und Softwareelemente), die einem Fahrzeugführer beim Fahren oder Parken eines Fahrzeugs helfen, und setzen typischerweise verschiedene Mikrocontroller, elektronische Steuereinheiten (ECUs: Electronic Control Units), Sensoren und/oder Leistungshalbleitervorrichtungen/-systeme (hier kollektiv als „Fahrsteuereinheiten“ oder „DCUs“ bezeichnet) ein, die in dem Fahrzeug implementiert sind. Diese Apps/Dienste sind auch auf Autonomfahr-Apps/Dienste anwendbar. Diese V2X-Apps/Dienste können eine parallele Verteilung einer relativ großen Datenmenge mit hoher Zuverlässigkeit und niedriger Latenz erfordern und profitieren üblicherweise von prädiktiver Zuverlässigkeit. Dies bedeutet, dass die vUEs 101, die FAS nutzen, die Möglichkeit haben sollten, eine Vorhersage über die Netzwerkverfügbarkeit und/oder -QoS zu erhalten, die vorausschauend zu planen. Echtzeitsituationsbewusstsein ist für autonome Fahrzeuge essentiell, insbesondere bei kritischen Straßensegmenten in Fällen sich ändernder Straßenzustände (z. B. neue Objekte/Hindernisse, die vor einiger Zeit durch ein anderes Fahrzeug detektiert wurden, sich ändernde Wetter- und/oder Umweltbedingungen und dergleichen).Zu diesem und anderen Zwecken müssen die relevanten hochauflösenden (lokalen) Karten über Herunterladen von einem Backend-Server/Dienst (z. B. Fernanwendungsserver 160) verfügbar gemacht werden. Der Verwendungsfall für Echtzeitsituationsbewusstsein und hochauflösende (lokale) Karten sollte nicht nur als ein Fall zum Verteilen von Informationen über sich relativ langsam ändernde Straßenzustände angesehen werden. Der Fall sollte auf Verteilung und Aggregierung lokal verfügbarer Informationen in Echtzeit über Straßenrandeinheiten an die Verkehrsteilnehmer erweitert werden. Eine andere FAS-App/ein anderer FAS-Dienst ist See-Through (bzw. High Definition Sensor Sharing). Bei dieser Art von Verwendungsfällen müssen Fahrzeuge wie Lastkraftwagen, Minivans, Autos usw. in Platoons Sensordaten, wie etwa Bilder/Videos von Straßenzuständen vor ihnen, mit Fahrzeugen hinter ihnen zu teilen.
  • Zusätzlich dazu können FAS- und/oder Autonomfahr-Apps/Dienste die Verwendung von Künstliche-Intelligenz(AI)-Agenten und/oder Maschinenlern(ML)-Modellen beinhalten, die dahingehend betreibbar sind, Umgebungsbedingungen zu beobachten und Maßnahmen zu bestimmen, die zur Förderung eines bestimmten Ziels zu ergreifen sind. Die zu beobachtenden speziellen Umgebungsbedingungen und die zu ergreifenden Maßnahmen können auf einer Betriebsgestaltungsdomäne (ODD: Operational Design Domain) basieren. Eine ODD beinhaltet die Betriebsbedingungen, unter denen ein gegebener AI-Agent/ein gegebenes ML-Modell oder ein Merkmal davon spezifisch entwurfsgemäß funktioniert. Eine ODD kann Betriebseinschränkungen, wie etwa Umgebungs-, geographische und Tageszeiteinschränkungen, und/oder das erforderliche Vorhandensein oder Fehlen bestimmter Verkehrs- oder Straßeneigenschaften beinhalten. In Ausführungsformen sind einzelne AI-Agenten und/oder trainierte ML-Modelle/Algorithmen dahingehend konfigurierbar oder betreibbar, jeweilige Steuersysteme/DCUs eines Host-vUE 101 zu steuern. Bei diesen Ausführungsformen können die zu ergreifenden Maßnahmen und die speziellen Ziele, die erreicht werden sollen, basierend auf dem Steuersystem selbst und/oder beteiligten DCUs spezifisch oder individualisiert sein. Zusätzlich dazu können manche der Maßnahmen oder Ziele dynamische Fahraufgaben (DDT: Dynamic Drive Tasks), Objekt- und Ereignisdetektions- und -Antwortaufgaben (OEDR: Object and Event Detection and Response) oder andere nicht fahrzeugbetriebsbezogene Aufgaben in Abhängigkeit von dem speziellen Kontext sein, in dem ein AI-Agent und/oder trainierte ML-Modelle/Algorithmen implementiert sind. DDTs beinhalten alle operativen und taktischen Echtzeit-Funktionen, die erforderlich sind, um ein vUE 101 im Straßenverkehr zu betreiben, ausgenommen die strategischen Funktionen (z. B. Tourenplanung und Auswahl von Zielen und Wegpunkten). DDTs beinhalten taktische und operative Aufgaben wie seitliche Fahrzeugbewegungssteuerung über Lenken (operativ); Fahrzeuglängsbewegungssteuerung über Beschleunigung und Abbremsung (operativ); Überwachen der Fahrumgebung über Objekt- und Ereignisdetektion, -erkennung, -klassifizierung und -reaktionsvorbereitung (operativ und taktisch); Objekt- und Ereignisreaktionsausführung (operativ und taktisch); Manöverplanung (taktisch); und Verbesserung der Auffälligkeit mittels Beleuchtung, Signalisierung und Gestik usw. (taktisch). OEDR-AUFGABEN können Teilaufgaben von DDTs sein, die das Überwachen der Fahrumgebung (z. B. Detektieren, Erkennen und Klassifizieren von Objekten und Ereignissen und Vorbereiten einer Reaktion nach Bedarf) und Ausführen einer geeigneten Reaktion auf solche Objekte und Ereignisse, zum Beispiel, nach Bedarf, um die DDT oder Fallback-Aufgabe abzuschließen, beinhalten. Manche dieser Merkmale können durch den involvierten AI-Agenten/das involvierte ML-Modell ausgelöst werden oder können durch eine externe Entität, wie etwa den Fernanwendungsserver 160 und/oder den/die MEC-Host(s) 140, ausgelöst werden. Die Ereignisse/Auslöser können AI-Agent/ML-Modell-spezifisch sein und können in Abhängigkeit von der bestimmten Ausführungsform variieren.
  • Bei VRUs handelt es sich um sowohl nichtmotorisierte Verkehrsteilnehmer als auch Führer von VRU-Fahrzeugen. Eine „VRU-Vorrichtung“ bezieht sich auf eine tragbare Vorrichtung, die durch eine VRU verwendet wird, die eine Standard-ITS-Station integriert (z. B. Smartphone, Tablets, Wearables usw.), obwohl sich der Begriff „VRU“ allein sowohl auf einen VRU als auch eine VRU-Vorrichtung beziehen kann. VRU-bezogene V2X-Apps/Dienste nutzen Informationen, die von VRUs zum Zweck der Verkehrssicherheit bereitgestellt werden (z. B. Kollisionsvermeidung usw.). Diese Apps/Dienste erfordern üblicherweise eine hohe Genauigkeit von durch diese Verkehrsteilnehmer bereitgestellten Positionsbestimmungsinformationen. Ein zusätzliches Mittel zum Verwenden verfügbarer Informationen für eine bessere und zuverlässige Genauigkeit ist entscheidend, um eine Nutzung von Informationen, die von VRUs gemeinsam genutzt werden, in der realen Welt zu ermöglichen. Die Kooperation zwischen Fahrzeugen und VRUs über ihre VRU-Vorrichtungen ist ein wichtiges Schlüsselelement zur Verbesserung der Verkehrssicherheit und zur Vermeidung von Unfällen.
  • Für diese V2X-Apps/Dienste liefert (liefern) das MEC-System 100 (bzw. die MEC-Hosts 140) Rückmeldeinformationen von dem Netzwerk an das vUE 101 zur Unterstützung von V2X-Funktionen/Apps/Diensten, wobei vorhergesagt wird, ob ein Kommunikationskanal gegenwärtig zuverlässig ist oder nicht (z. B. hinsichtlich Latenzanforderungen, Paketankunftsraten, QoS für Datendienst/-konnektivität und/oder dergleichen). Das MEC-System 100 stellt auch Interoperabilität bereit, indem V2X-Informationsaustausch zwischen vUEs 101 und/oder anderen Verkehrsteilnehmern (z. B. VRUs usw.) unterstützt wird, die durch verschiedene Stations-/Gerätetypen/-plattformen, Zugangstechnologien, Netzwerke oder NMOs verbunden sind, und ein Multi-Operatorbetrieb für V2X-Apps/Dienste und/oder einzelne vUEs 101 ermöglicht wird, um Dienstkontinuität über Zugangsnetzwerkabdeckungsbereiche hinweg landesweit und über Grenzen verschiedener MNO-Netzwerke bereitzustellen. Das MEC-System 100 (oder einzelne MEC-Hosts 140) muss möglicherweise eine zeitgenaue Positionsbestimmung, die durch verfügbare Positionsbestimmungstechnologien einschließlich Funknetzfunktionen unterstützt wird, und/oder prädiktive qualitätsbezogene Informationen an das Fahrzeug liefern, wenn sich die verschiedenen Konnektivitätsparameter (wie Latenz, PER, Signalstärke usw.) ändern werden.
  • MEC beinhaltet eine V2X-Informationsdienst(VIS)-Anwendungsprogrammierschnittstelle (API), die dazu ausgelegt ist, eine V2X-Interoperabilität in Mehrfachanbieter-, Mehrfachnetzwerk- und Mehrfachzugriffsumgebungen für Automobilverwendungsfälle zu ermöglichen. Diese Verwendungsfälle können unterschiedliche Fahrzeughersteller, Erstausrüster(OEM: Original Equipment Manufacturer)-Lieferanten, Netzwerkinfrastrukturanbieter, MEC-Anbieter, Anwendungs-/Inhaltsanbieter und andere Stakeholder beinhalten.
  • MNOs sind typischerweise gebietsspezifisch oder länderspezifisch und stellen ihren eigenen Kunden (Teilnehmern) direkt Dienste bereit, während sie Kommunikationen an Kunden anderer MNOs auf Kernnetzwerkebene unter Verwendung von Interworking zwischen den Netzwerken der NMOs bereitstellen. Jedes MNO betreibt sein eigenes Public Land Mobile Network (PLMN), das aus Sicht der Teilnehmer eines bestimmten MNO häufig als Home-PLMN (HPLMN) oder aus Sicht von Benutzern, die keine Teilnehmer des bestimmten MNO sind, als Visiting-PLMN (VPLMN), bezeichnet wird. Für Fahrzeuganwendungen wird das Beibehalten der V2X-Dienstkontinuität (oft mit niedriger Latenzanforderung) für Verkehrsteilnehmer herausfordernd, insbesondere wenn sich solche Verkehrsteilnehmer von einem Abdeckungsbereich eines MNO zu einem Abdeckungsbereich eines anderen MNO bewegen.
  • Das Interworking auf Mobilnetzwerkebene zwischen verschiedenen PLMNs wird verwendet, um Dienstkontinuität in solchen Verwendungsfällen zu ermöglichen, wie sie in 3GPP-Spezifikationen spezifiziert sind, wie etwa ETSI GS MEC 003 v2.1.1 (2019-01) („[R05]“) [R05], ETSI GS MEC 011 V1.1.1 (2017-07) („[R08]“), ETSI GS MEC 013 v1.1.1 (2017-07) („[R10]“), ETSI GS MEC 014 VI.1.1 (2018-02) („[R11]“) und ETSI GS MEC 015 VI.1.1 (2017-10) („[R12]“). Des Weiteren ist eine Inter-MEC-Systemkoordination auch erforderlich, um UEs im Transit vorzubereiten (z. B. basierend auf den Vereinbarungen zwischen MNOs, Roaming und/oder Handover zu einem neuen PLMN) und Unterbrechungszeit zu reduzieren.
  • Die Dienstkonsumenten kommunizieren mit dem VIS 280 über die V2X-API, um die notwendigen V2X-Dienstbereitstellungsinformationen für das Visiting-PLMN zur Unterstützung der Inter-PLMN-Dienstkontinuität zu erhalten. Sowohl MEC-Anwendungen (Apps) als auch MEC-Plattformen können den VIS 280 nutzen; und sowohl MEC-Plattformen als auch die MEC-Apps können die Bereitsteller der V2X-Informationen sein. Die V2X-API kann auch als „VIS-API“ oder dergleichen bezeichnet werden. MEC-Apps und MEC-Plattformen werden unten ausführlicher mit Bezug auf 14, 15 und 16 besprochen.
  • 2 veranschaulicht ein beispielhaftes V2X-System 200, das eine MEC-Systemarchitektur gemäß verschiedenen Ausführungsformen beinhaltet. Die MEC-Systemarchitektur beinhaltet jeden der mehreren MEC-Hosts 240 (einschließlich des MEC-Hosts 240-1 und des MEC-Hosts 240-2), von denen jeder den MEC-Hosts 1502 in dem MEC-System 1500 von 15 entsprechen kann. Wie zuvor erwähnt, bietet MEC Anwendungsentwicklern und Inhaltanbietern Cloud-Computing-Fähigkeiten und eine IT-Dienstumgebung am Rand des Netzwerks an. Diese Umgebung zeichnet sich durch ultraniedrige Latenz und hohe Bandbreite sowie Echtzeitzugriff auf Funknetzinformationen aus, die durch Anwendungen genutzt werden können. Die MEC-Technologie ermöglicht einen flexiblen und schnellen Einsatz innovativer Anwendungen und Dienste gegenüber mobilen Teilnehmern, Unternehmen und vertikalen Segmenten. Insbesondere müssen Anwendungen, wie etwa V2X-Anwendungen, in Bezug auf den Automobilsektor Daten austauschen, Daten an Aggregationspunkte liefern und auf Daten in Datenbanken zugreifen, die einen Überblick über die lokale Situation bereitstellen, abgeleitet von einer Vielzahl von Sensoren (durch verschiedene Autos, Straßenrandeinheiten usw.).
  • Das V2X-System 200 involviert mehrere MEC-Hosts 240 (einschließlich MEC-Host 240-1 und MEC-Host 240-2) und die Verwendung des MEC-VIS 280. Das vUE 201, die NANs 210 (einschließlich NAN 210-1 und NAN 210-2), die MEC-Hosts 240 und die Remote-Cloud 260 können dem/den vUE(s) 101, NANs 110 bzw. MEC-Hosts 140 aus 1A und 1B entsprechen. Jedes der Paare aus MEC-Host 240 und NAN 210 kann eine jeweilige Edge-Cloud bilden und die Remote-Cloud 260 kann einen oder mehrere Fernanwendungsserver (z. B. Fernanwendungsserver 160 aus 1A und 1B) beinhalten.
  • Bei verschiedenen Ausführungsformen können das MEC-System 200 (und einzelne MEC-Hosts 240) das Feature V2XService unterstützen. Wenn das MEC-System 200 das Feature V2XService unterstützt, beinhaltet das MEC-System 200 die Fähigkeit, Rückmeldungsinformationen von dem Netzwerk (z. B. den MNO-Netzwerken in 1a-1b und/oder den Edge-Clouds in 2) zur Unterstützung von V2X-Funktionen an das vUE 201 zu liefern, was beim Vorhersagen hilft, ob ein Kommunikationskanal gegenwärtig zuverlässig ist oder nicht (zum Beispiel hinsichtlich des Erfüllens von Latenzanforderungen und/oder einer Schwellenpaketankunft). Das MEC-System 200, das V2XService unterstützt, beinhaltet die Fähigkeit, dem Fahrzeug von dem Netzwerk qualitätsbezogene Informationen darüber bereitzustellen, wann sich die verschiedenen Konnektivitätsparameter (wie Latenz, PER, Signalstärke usw.) ändern werden. Das MEC-System 200, das V2XService unterstützt, beinhaltet die Fähigkeit, eine Interoperabilität bereitzustellen, indem ein V2X-Informationsaustausch zwischen Verkehrsteilnehmern unterstützt wird, die durch unterschiedliche Zugangstechnologien, Netzwerke und/oder MNOs verbunden sind. Das MEC-System 200, das V2XService unterstützt, ermöglicht einen Multi-Operatorbetrieb für V2X-Stationen/Geräte, um Dienstkontinuität über Zugangsnetzwerkabdeckung landesweit und über Grenzen von Netzwerken verschiedener Betreiber bereitzustellen. Das MEC-System 200, das V2XService unterstützt, beinhaltet die Fähigkeit, Interoperabilität in Multi-Operator-Szenarien bereitzustellen, wodurch ermöglicht wird, dass MEC-Apps in verschiedenen Systemen sicher miteinander kommunizieren, um eine Synchronisation in Multi-Operatorsystemen auch in Abwesenheit von zellulärer Abdeckung (außerhalb der 3GPP-Domäne) zu ermöglichen. Das MEC-System 200, das V2X-Service unterstützt, beinhaltet die Fähigkeit, Interoperabilität in Multi-Operator-Szenarien bereitzustellen, wodurch ermöglicht wird, dass MEC-Apps sicher mit den logischen Funktionen des V2X-bezogenen 3GPP-Kernnetzwerks (z. B. V2X-Steuerfunktion 350 von 3 und/oder anderen Kernnetzwerkfunktionen) kommunizieren und PC5-V2X-relevante Informationen (z. B. PC5-Konfigurationsparameter) aus dem 3GPP-Netzwerk erfasst werden.
  • Im Framework von V2X-Diensten hostet das vUE 201 eine Client-App (UE-App 202 in 2) und ist mit einem bestimmten MEC-Host 240 (und einer zugehörigen MEC-App 228) verbunden. In Gegenwart mehrerer MEC-Hosts 240 ermöglicht das VIS 280 das Offenlegen von Informationen zwischen MEC-Apps 228, die auf verschiedenen MEC-Hosts 240 laufen. Jeder der MEC-Hosts 240 kann einem anderen Betreiber oder Dienstanbieter (z. B. einem MEC-Anbieter oder einer dritten Partei) gehören bzw. durch diesen verwaltet werden. MEC-Apps 228, die auf dem MEC-Host 240-1 und dem MEC-Host 240-2 instanziiert sind, können verwendet werden, um V2X-bezogene Dienste bereitzustellen, und können durch den Mobildienstbetreiber, durch einen MEC-Anbieter oder durch eine dritte Partei (z. B. OEM oder OEM-Lieferant oder Systemintegrator) betrieben werden. Zusätzlich dazu können sich andere Fernanwendungsserverinstanzen an anderer Stelle, wie etwa in der Remote-Cloud 260, befinden. Die Remote-Cloud 260 kann eine beliebige Art von Cloud-Infrastruktur sein, zum Beispiel eine oder mehrere private Clouds, die einem Betreiber oder einem OEM gehören. Die Remote-Cloud 260 betreibt auch eine oder mehrere Remote-Apps 265. Der VIS 280 kann durch die MEC-Plattform 230 oder durch die MEC-App 228 erzeugt werden.
  • Bei einigen Aspekten kann die MEC-Plattform 230 (die der MEC-Plattform 1532 und/oder der MEC-Plattform-VNF 1602 von 16 entspricht) eine MEC-V2X-API beinhalten, die den MEC-VIS 280 bereitstellt. Der VIS 280/die V2X-API unterstützt sowohl Anfragen als auch Subskriptionen (z. B. Pub/Sub-Mechanismus), die über eine Repräsentationszustandstransfer(„REST“ bzw. „RESTful“)-API oder über alternative Transporte, wie etwa einen Nachrichtenbus, verwendet werden. Für RESTful-Architekturen können HTTP-Protokoll-Bindungen für die VIS-API definiert werden. Insbesondere gestattet der VIS 280 eine Informationsoffenlegung, betreffend die Unterstützung von Automobilverwendungsfällen, gegenüber MEC-App-Instanzen. Der VIS 280 gestattet es auch einem einzelnen ITS-Betreiber, V2X-Anwendungen/Dienste über ein Gebiet anzubieten, das verschiedene Länder überspannen und mehrere Netzwerkbetreiber, MEC-Systeme und MEC-App-Anbieter einschließen kann. Dazu kann der VIS 280 folgende Funktionalitäten aufweisen: (a) Sammeln von PCS-V2X-relevanten Informationen aus dem 3GPP-Netzwerk zum Zweck des Durchführens einer UE-Autorisierung für V2X-Kommunikationen (z. B. Erhalten einer Liste von V2X-autorisierten UEs, erhalten relevanter Informationen über die Autorisierung basierend auf UE-Subskription und Erhalten von V2X-Konfigurationsparametern, wie etwa einem gemeinsamen Satz von V2X-Konfigurationsparametern, die PC5-Konfigurationsparameter beinhalten können); (b) Offenlegen der in (a) erhaltenen Informationen gegenüber MEC-Apps 228 in demselben MEC-Host 240 oder MEC-Apps 228 in anderen MEC-Hosts 240; (c) Ermöglichen, dass die MEC-Apps 228 sicher mit den logischen Funktionen des V2X-bezogenen 3GPP-Kernnetzwerks kommunizieren (z. B. Ermöglichen einer Kommunikation zwischen einem MEC-Host 240 und einer V2X-Steuerfunktion in dem Kernnetzwerk); (d) Ermöglichen, dass MEC-Apps 228 in verschiedenen MEC-Systemen 240 sicher miteinander kommunizieren, und (e) Sammeln und Verarbeiten von Informationen, die in anderen MEC-Hosts/Systemen verfügbar sind, unter Verwendung geeigneter MEC-APIs (z. B. Sammeln und Verarbeiten von Informationen, die über die V2X(VIS)-API, eine Funknetzinformations(RNI)-API (siehe z. B. ETSI GS MEC 012 VI.1.1 (2017-07) („[R09]“)), eine Standort-API [R10], eine UE-Identitäts(UE_ID)-API [R11], eine Bandbreitenverwaltungs(BWM)-API [R12], eine WLAN-Zugangsinformations(WAI)-API, eine Festzugangsinformations(FAI)-API ETSI GS MEC 029 v2.1.1 (2019-07) („[R13]“) und andere ähnliche APIs zum Zugreifen auf andere MEC-Dienste 236, die innerhalb der MEC-Plattform 230 implementiert sein können), um eine Funknetzüberlastung vorherzusagen und geeignete Benachrichtigungen an das UE 201 zu liefern. Die Dienstregistrierungsdatenbank 238, die Filterungsregelsteuerung 231, die DNS-Handhabung 232, die Datenebene 224 und die Virtualisierungsinfrastruktur 222 werden unten mit Bezug auf 15 und 16 ausführlicher besprochen.
  • Aus dieser Perspektive ist der VIS 280 für Mp1- und Mp3-Referenzpunkte in der MEC-Architektur relevant (siehe z. B. 14, 15 und 16). Insbesondere werden relevante Informationen von verschiedenen Diensten 228 und 236 über den Mp1-Referenzpunkt gegenüber MEC-Apps 228 offengelegt. Der Mp3-Referenzpunkt ermöglicht den Transfer dieser Informationen zwischen verschiedenen MEC-Plattformen 230. Beispielsweise kann der zweite MEC-Host 240-2 auch eine MEC-V2X-API implementieren, die eine Schnittstelle zu einer oder mehreren der MEC-Apps 228 bereitstellen kann, die innerhalb des MEC-Hosts 240-2 instanziiert sind. In dieser Hinsicht können der MEC-Host 240-2 und der MEC-Host 240-1 über die Mp3-Schnittstelle sowie die MEC-V2X-APIs miteinander kommunizieren. Zusätzlich dazu können eine oder mehrere der Apps 228, die innerhalb des MEC-Hosts 240-1 instanziiert sind, mit einer oder mehreren der MEC-Apps 228, die innerhalb des MEC-Hosts 240-2 instanziiert sind, über die MEC-V2X-APIs sowie die Schnittstelle zwischen dem MEC-Host 240-1 und dem MEC-Host 240-2 kommunizieren.
  • Die MEC-VIS-API stellt MEC-Apps 228 auf standardisierte Weise Informationen bereit, die Interoperabilität in Multi-Anbieter-Szenarien bereitstellen. Dennoch können die MEC-Apps 228 auf direkte Weise kommunizieren (z. B. ohne die Verwendung der MEC-Plattform 230). Bei einigen Ausführungsformen kann eine systemübergreifende Kommunikation zwischen MEC-Orchestratoren (MEOs) realisiert werden. Zusätzlich oder alternativ dazu können mögliche Mp3-Verbesserungen (oder neue Referenzpunkte zwischen MEC-Systemen 240) für die Kommunikation der MEC-App 228 definiert werden.
  • Die MEC-V2X-APIs (z. B. um VIS 280 offenzulegen) können als ein allgemeiner Middleware-Dienst bereitgestellt werden, der Informationen bereitstellt, die von Fahrzeugen 201 und anderen V2X-Elementen gesammelt 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 228, die innerhalb der Hosts instanziiert sind) offengelegt werden. Bei einigen Aspekten können die MEC-V2X-APIs dazu konfiguriert sein, Informationen und Daten von diversen Sensoren zu sammeln. In dieser Hinsicht gewährleistet der Einsatz der MEC-V2X-APIs Kontinuität des Dienstes über verschiedene Mobilnetzwerke hinweg für denselben OEM (z. B. Automobilhersteller). Wird eine Standardimplementierung einer V2X-API eingeführt (z. B. durch ETSI-MEC), so kann diese Funktionalität für alle OEMs in einem 5G-Kommunikationssystem mit MEC-Funktionalitäten die gleichen grundlegenden V2X-Diensteigenschaften gewährleisten.
  • Die VIS-API/V2X-API beinhaltet Ressourcen und Operationen. Eine „Ressource“ ist ein Objekt mit einem Typ, assoziierten Daten, einem Satz von Verfahren, die darauf arbeiten, und Beziehungen zu anderen Ressourcen, falls zutreffend. Eine Ressource ist ein Grundkonzept in einer RESTful-API. Ressourcen werden von der RESTful-API unter Verwendung von HTTP-Verfahren (z. B. POST, GET, PUT, DELETE, etc.) bearbeitet. Operationen an Ressourcen beeinflussen den Zustand der entsprechenden verwalteten Entitäten. Einige Prozeduren/Operationen der VIS-API sind in 11 gezeigt. 12 veranschaulicht eine Universalressourcenindikator(URI)-Struktur der VIS-API gemäß verschiedenen Ausführungsformen. Tabelle 7.2-1 gibt einen Überblick über die Ressourcen und die anwendbaren durch die VIS-API definierten HTTP-Verfahren. Die VIS-API unterstützt zusätzliche anwendungsbezogene Fehlerinformationen, die in der HTTP-Antwort bereitgestellt werden, wenn ein Fehler auftritt (siehe z. B. Abschnitt 6.15 von ETSI GS MEC 009 V2.1.1 (2019-01) („[R06]“)). Tabelle 7.2-1: Beispielhafte VIS-API-Ressourcen und -Verfahren
    Ressourcenbezeichnung RESSOURCEN-URI HTTP-Verfahren Bedeutung
    Uu-Unicast-Bereitstellungsinformationen /queries/uu_unicast_provisioning _info GET Abrufen von Bereitstellungsinformati onen, die für V2X-Kommunikation erforderlich sind, über Uu-Unicast.
    Uu-MBMS-Bereitstellungsinformationen /queries/uu_mbms_provisioning_ info GET Abrufen von Bereitstellungsinformati onen, die für V2X-Kommunikation erforderlich sind, über Uu-MBMS.
    PC5-Bereitstellungsinformationen /queries/pc5_provisioning_info GET Abrufen von Bereitstellungsinformati onen, die für V2X-Kommunikation erforderlich sind, über PC5.
    Aufgabe Bereitstellen einer vorhergesagten QoS /provide_predicted_qos POST Bereitstellen einer vorhergesagten QoS basierend auf Routeninformationen.
    Aufgabe Veröffentlichen /publish_v2x_message POST Veröffentlichen einer
    einer V2X-Nachricht V2X-Nachricht an VIS.
    alle Subskriptionen für einen Teilnehmer /subscriptions GET Abrufen einer Liste aktiver Subskriptionen für diesen Teilnehmer.
    POST Erstellen einer neuen Subskription.
    existierende Subskription /subscriptions/{subscriptionld} GET Abrufen von Informationen über aktuelle spezifische Subskription.
    PUT Modifizieren einer bestehenden Subskription durch Senden einer neuen Datenstruktur.
    DELETE Löschen der bestehenden Subskription.
    Benachrichtigungsrückruf Von Client bereitgestellte Rückrufreferenz POST Senden einer Benachrichtiun.
  • Die Syntax jedes Ressourcen-URI folgt [R06], sowie IETF RFC 3986 (2005-01) oder IETF RFC 7320 (2014-07). In den RESTful-MEC-DIENST-APIs, einschließlich der VIS-API, weist die Ressourcen-URI-Struktur für jede API die folgende Struktur auf:
    • {apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}
  • Hier beinhaltet „apiRoot“ das Schema („https“), den Host und den optionalen Port und eine optionale Präfixkette. „apiName“ definiert die Bezeichnung der API (z. B. VIS/V2X-API, RNI-API usw.). „apiVersion“ repräsentiert die Version der API, und „apiSpecificSuffixes“ definieren den Baum von Ressourcen-URIs in einer bestimmten API. Die Kombination von „apiRoot“, „apiName“ und „apiVersion“ wird als Stamm-URI bezeichnet. „apiRoot“ steht unter der Kontrolle des Einsatzes, während die übrigen Teile des URI unter der Kontrolle der API-Spezifikation stehen. In dem obigen Stammverzeichnis werden „apiRoot“ und „apiName“ unter Verwendung der Dienstregistrierungsdatenbank 238 entdeckt. Es beinhaltet das Schema („http“ oder „https“), den Host und den optionalen Port und eine optionale Präfixkette. Für die VIS-API kann „apiName“ auf „vis“ gesetzt werden und „apiVersion“ kann auf eine geeignete Versionsnummer gesetzt werden (z. B. „v1“ für Version 1). Die MEC-APIs unterstützen HTTP über TLS (auch als HTTPS bekannt). Alle Ressourcen-URIs in den VIS-Prozeduren (siehe z. B. 11) sind relativ zu der obigen Stamm-URI definiert.
  • Das JSON-Inhaltsformat kann auch unterstützt werden. Das JSON-Format wird durch den Inhaltstyp „application/json“ signalisiert. Die VIS-API kann den OAuth-2.0-Client-Zugangsberechtigungsnachweisgewährungs-Typ mit Träger-Tokens verwenden (siehe z. B. [R06]). Der Token-Endpunkt kann als Teil der in [R08] definierten Dienstverfügbarkeitsabfrageprozedur entdeckt werden. Die Client-Zugangsdaten können unter Verwendung bekannter Bereitstellungsmechanismen in die MEC-App geliefert werden.
  • Bei einigen Ausführungsformen können die MEC-Apps 228 in ihren jeweiligen MEC-Hosts 240 die entsprechenden MEC-V2X-APIs verwenden, um Informationen aus dem 3GPP-Netzwerk abzurufen. Bei einigen Ausführungsformen können die MEC-Apps 228 in ihren jeweiligen MEC-Hosts 240 dazu konfiguriert sein, V2X-Konfigurationsparameter, wie etwa PC5-Konfigurationsparameter (oder einen gemeinsamen Satz von V2X-Konfigurationsparametern, die innerhalb einer Multi-PLMN-Kommunikationsumgebung verfügbar sein können), zu hosten. Die Verfügbarkeit dieser V2X-Konfigurationsparameter auch ohne Netzabdeckung wird durch die Verwendung einer Mp3-Schnittstelle (oder einer anderen Art von Schnittstelle) zwischen den Hosts sichergestellt. Bei einigen Aspekten kann die MEC-App 228 in dem MEC-Host 240-1 dazu konfiguriert sein, sich mit dem MEC-Host 240-2 (über die V2X-MEC-API in dem MEC-Host 240-2) zu verbinden, und die MEC-App 228 in dem MEC-Host 240-2 kann dazu konfiguriert sein, sich mit dem MEC-Host 240-1 (über die V2X-MEC-API in dem MEC-Host 240-1) zu verbinden. Im Fall einer Multi-Operator-Architektur können mehrere MEC-Hosts 240 dazu konfiguriert sein, über die MEC-V2X-APIs miteinander zu kommunizieren und sich zu synchronisieren, um die relevanten V2X-Konfigurationsparameter zu übertragen, sodass sie über die Multi-Operator-Architektur bei Fehlen zellulärer Abdeckung (z. B. außerhalb der 3GPP-Domäne) verfügbar sein können. Auf diese Weise kann ein UE (z. B. vUE 201) Zugriff auf V2X-Konfigurationsparameter haben, selbst wenn sich das UE nicht unter Abdeckung seines 3GPP-Netzwerks befindet.
  • In einigen Ausführungsformen können eine oder mehrere MEC-Apps 228 innerhalb eines MEC-Hosts 240 instanziiert werden, um Funktionalitäten einer V2X-Anwendungsfunktion durchzuführen, was das Bereitstellen von VIS 280 beinhalten kann. Zusätzlich dazu können die MEC-Hosts 240 MEC-V2X-APIs verwenden, um verschiedene V2X- oder VIS-280-Funktionen durchzuführen. Insbesondere können eine oder mehrere MEC-Apps 228 innerhalb eines MEC-Hosts 240 instanziiert werden, um Funktionalitäten durchzuführen, die mit einer V2X-Anwendungsfunktion assoziiert sind, wie in 3 gezeigt ist. Diese MEC-Apps 228 können dazu konfiguriert sein, eine oder mehrere der folgenden V2X-Anwendungsfunktionen durchzuführen: Erhalten von V2X-Subskriptionsinformationen für ein vUE 201, Bestimmen, ob das vUE 201 dazu autorisiert ist, V2X-Kommunikationen durchzuführen, als Reaktion auf eine Anforderung von V2X-Diensten, Kommunizieren von V2X-Konfigurationsparametern, wie etwa einem gemeinsamen Satz von V2X-Konfigurationsparametern, und so weiter.
  • 3 zeigt eine beispielhafte Architektur 300, die eine Kommunikation zwischen dem VIS (z. B. VIS 280 von 2) und der V2X-Steuerfunktion 350 ermöglicht. In diesem Beispiel wird der VIS in der MEC-Plattform 322 des MEC-Hosts 340-1 und/oder des MEC-Hosts 340-2 eingesetzt. In einem 3GPP-Netzwerk können V2X-Anwendungen auf einem oder mehreren V2X-Anwendungsservern (V2X-AS) 328 eingesetzt werden. Bei 3GPP-V2X gibt es zwei Betriebsmodi für die V2X-Kommunikation, nämlich über die PC5-Schnittstelle und über die LTE/5G-Uu-Schnittstelle. Die UU-Schnittstelle kann Unicast und/oder MBMS sein. Diese zwei Betriebsmodi können durch ein UE (z. B. vUEs 101 und 201 in 1A, 1B und 2) unabhängig für Übertragung und Empfang verwendet werden. Zum Beispiel kann ein UE MBMS zum Empfang verwenden, ohne die Uu-Schnittstelle zur Übertragung zu verwenden. Das UE kann auch V2X-Nachrichten über den UU-Schnittstellen-Unicast-DL empfangen.
  • Der V2X-AS 328 kann UL-Daten von einem oder mehreren UEs über Unicast empfangen und Daten unter Verwendung von Unicast-Lieferung und/oder MBMS-Lieferung an das eine oder die mehreren UEs in einem Zielgebiet liefern. Der V2X-AS 328 kann von geografischen Standortinformationen auf geeignete Ziel-MBMS-SAI(s) für Broadcast abbilden, von geografischen Standortinformationen auf geeignete Ziel-3GPP-Identitäten abbilden, wie etwa E-UTRAN-Cell-Global-Identifier(s) (ECGI) und/oder NR-Cell-Global-Identifier(s) (NCGI) für den Broadcast; und von UE-bereitgestellten ECGI/NCGI auf geeignete Ziel-MBMS-Service-Area-Identifier(s) (SAI(s)) für den Broadcast abbilden. Der V2X-AS 328 kann auch die geeignete(n) ECGI(s)/NCGI(s) und/oder MBMS-SAI(s) an das Broadcast-Multicast-Service-Center (BM-SC) zum Planen und Übertragen von Broadcast/Multicast-Inhalt, Abrechnen, für Dienstankündigungen, Sicherheit und Inhaltssynchronisation bereitstellen.
  • Die V2X-Steuerfunktion 350 ist eine Netzwerkfunktion (NF) im Kernnetzwerk, die für netzwerkbezogene Aktionen verwendet wird, die für V2X benötigt werden. Die V2X-Steuerfunktion 350 wird verwendet, um einem UE (z. B. vUEs 101 und 201) notwendige Parameter bereitzustellen, um V2X-Kommunikation zu verwenden, wie etwa PLMNspezifische Parameter, die es dem UE ermöglichen, V2X in einem spezifischen PLMN zu verwenden. Die V2X-Steuerfunktion 350 wird auch verwendet, um dem UE Parameter bereitzustellen, die benötigt werden, wenn das UE „nicht durch E-UTRAN bedient“ oder „nicht durch NG-RAN bedient“ wird. Die V2X-Steuerfunktion 350 kann auch verwendet werden, um V2X-USDs für UEs zu erhalten, um MBMS-basierten V2X-Verkehr über den V2-Referenzpunkt von dem V2X-AS 328 zu empfangen. Die V2X-Steuerfunktion 350 kann auch die Parameter, die für V2X-Kommunikationen über den PC5-Referenzpunkt benötigt werden, von dem V2X-AS 328 über den V2-Referenzpunkt erhalten. Der V2-Bezugspunkt ist ein Bezugspunkt zwischen dem V2X-AS 328 und der V2X-Steuerfunktion 350 im Netzwerk des Betreibers.
  • Die V2X-Steuerfunktion 350 eines HPLMN wird durch Interaktion mit einer DNS-Funktion (DNS: Domain Name Service) entdeckt. Der Fully Qualified Domain Name (FQDN) einer V2X-Steuerfunktion 350 in dem HPLMN kann entweder in dem UE vorkonfiguriert, durch das Netzwerk bereitgestellt oder durch das UE selbst konstruiert sein (z. B. abgeleitet von der PLMN-ID des HPLMN oder dergleichen). Die IP-Adresse einer V2X-Steuerfunktion 350 in dem HPLMN kann auch in dem oder an das UE bereitgestellt werden. Der Home Subscriber Server (HSS) in einem LTE-Kernnetzwerk und/oder eine Unified-Data-Management(UDM)-NF in einem 5G-Kernnetzwerk (5GC) stellt eine Liste der PLMNs bereit, wobei ein UE (z. B. vUEs 101 und 201 von 1A, 1B, und 2) dazu autorisiert ist, eine V2X-Kommunikation über den PC5-Referenzpunkt zu der V2X-Steuerfunktion 350 durchzuführen (siehe z. B. 3GPP TS 23.285 v16.0.0 (2019-03-25) und ETSI TS 123 285 V14.2.0 (2017-05) (zusammen „[R04]“)).
  • Bei manchen Implementierungen kann ein V2X-AS 328 (oder eine V2X-AS-Logik) gemeinsam mit einer RSU angeordnet sein. Das VIS 280, das in MEC definiert ist, wird verwendet, um V2X-Interoperabilität in einer Mehrfachanbieter-, Mehrfachnetzwerk- und Mehrfachzugriffsumgebung zu ermöglichen. Der VIS 280 oder generische Teile davon können in der MEC-Plattform 330 eingesetzt werden (die Filterungsregelsteuerung 331, die DNS-Handhabung 332 und die Dienstregistrierungsdatenbank 338 können jeweils der Filterungsregelsteuerung 231, der DNS-Handhabung 232 und der Dienstregistrierungsdatenbank 238 von 2 entsprechen). Daher kann das VIS 280 verwendet werden, um Subskriptionsdaten eines UE (z. B. zu PC5-basierter V2X-Kommunikation zugelassenes PLMN) von der V2X-Steuerfunktion 350 zu erhalten. Da der V2X-AS 328 mehrere V2X-Anwendungen trägt (oder bedient), kann er in der MEC-Plattform 330 als eine oder mehrere MEC-Apps 228 eingesetzt werden (siehe z. B. 2). Der VIS 280 kann mit dem V2X-AS 328 über die Mp1-Schnittstelle kommunizieren, und er kann die V2X-Subskriptionsdaten des UE von der V2X-Steuerfunktion 350 über den V2X-AS 328 erhalten. Bei einigen Ausführungsformen können die V2- und Mp1-Referenzpunkte verbessert werden, um die sichere Übertragung von Subskriptionsdaten zwischen der V2X-Steuerfunktion 350 und dem VIS 280 zu unterstützen. Zudem definieren aktuelle 3GPP-Spezifikationen weder eine Schnittstelle zwischen zwei oder mehr V2XAS 328 noch die Verfahren zum Nachrichtenaustausch zwischen V2X-AS 328. In einigen Ausführungsformen kann der Mp1-Referenzpunkt verbessert werden, um die sichere Übertragung von Daten zwischen zwei oder mehr V2X-AS 328, die durch denselben MEC-Host 340 implementiert werden, zu unterstützen, und der Mp3-Referenzpunkt kann verbessert werden, um die sichere Übertragung von Daten zwischen zwei oder mehr V2X-AS 328, die durch unterschiedliche MEC-Hosts 340 implementiert werden, zu unterstützen. Bei diesen Ausführungsformen können die V2X-API und/oder der VIS 280 ein Mittel zum Austauschen solcher Informationen zwischen V2X-AS 328 bereitstellen.
  • Eine V2X-MEC-App (z. B. MEC-App 228 und/oder V2X-AS 328) kann erforderlich sein, um mit ihren Peer-Anwendungen in anderen MEC-Systemen zu kommunizieren, um den beabsichtigten Zweck des Anwendungsverwendungsfalls zu erfüllen. Die beteiligten MEC-Systeme gestatten den autorisierten Anwendungen in einem MEC-System, mit ihren Peers in einem anderen MEC-System zu kommunizieren. Das Auffinden der Anwendungspeers kann durch den VIS 280 und/oder die V2X-API (oder VIS-API) ermöglicht werden, indem die verfügbaren Kommunikationsendpunktinformationen für Peer-to-Peer-Konnektivität offengelegt werden. Alternativ dazu können die konfigurierten Verkehrsregeln (z. B. Filterungsregelsteuerung 231/331) für die V2X-MEC-App zusammen mit den zugrundeliegenden Inter-MEC-System-Konnektivitätsanordnungen die Kommunikation der Anwendungs-Peers unterstützen. Zusätzlich oder alternativ dazu kann die V2X-MEC-App für ihre Peer-Entdeckung auf nicht MEC-spezifische Mittel angewiesen sein und dann für die Kommunikation auf ihren autorisierten Zugriff auf eine externe Schnittstelle angewiesen sein. Die erforderlichen Anordnungen zwischen den involvierten MEC-Systemen zum Realisieren sicherer Konnektivität mit den anwendungsspezifischen Anforderungen können anwendungs- und/oder einsatzspezifisch sein und können von Ausführungsform zu Ausführungsform variieren.
  • Zusätzlich dazu muss eine V2X-MEC-App (z. B. MEC-App 228 und/oder V2X-AS 328) in einem MEC-System möglicherweise einen Dienst in einem anderen MEC-System nutzen, um den beabsichtigten Zweck des Anwendungsverwendungsfalls zu erfüllen. In diesem Fall entdeckt die V2X-MEC-App den betreffenden Dienst in der Dienstregistrierungsdatenbank in ihrem lokalen MEC-Host 240/340. Die erforderlichen Anordnungen zwischen den beteiligten MEC-Systemen zum Abbilden eines Dienstes, der in einem MEC-System erzeugt wird, auf einen Endpunkt in einem anderen MEC-System können anwendungs- und/oder einsatzspezifisch sein und können von Ausführungsform zu Ausführungsform variieren.
  • Wie zuvor angedeutet, stellen die MEC-Hosts 240/340 auch einen RNI-Dienst (RNIS) bereit. Der RNIS ist ein Dienst, der MEC-Apps (z. B. MEC-App 228 und/oder V2X-AS 328) und MEC-Plattformen 230/330 funknetzbezogene Informationen bereitstellt. Der RNIS steht für autorisierte MEC-Apps zur Verfügung und wird über den Mp1-Referenzpunkt entdeckt. Die Granularität der Funknetzinformationen kann basierend auf Parametern, wie etwa Informationen pro Zelle, pro UE, pro QoS-Klasse (oder QoS-Klassenkennung (QCI: QoS Class Identifier), angepasst werden oder sie kann über einen Zeitraum hinweg angefordert werden. Die RNI können von den MEC-Apps 228 und MEC-Plattformen 230/330 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen über Funkbedingungen basieren. Die bereitstellbaren RNI können beispielsweise aktuelle Funknetzinformationen bezüglich Funknetzbedingungen; Messinformationen bezüglich der Benutzerebene basierend auf 3GPP-Spezifikationen; WLAN-Messungen; Informationen über UEs, die mit dem/den Funkknoten verbunden sind, der/die mit dem MEC-Host (z. B. NANs 110, 210) assoziiert ist/sind, deren UE-Kontext und die zugehörigen Funkzugangsträger; Änderungen an Informationen im Zusammenhang mit UEs, die mit dem/den Funkknoten verbunden sind, der/die mit dem MEC-Host assoziiert ist/sind, ihrem UE-Kontext und dem zugehörigen Funkzugangsträger.
  • Bei den verschiedenen Ausführungsformen hierin (z. B. der ersten Ausführungsform und der zweiten Ausführungsform, die unten besprochen sind) kann, da der RNIS Informationen über die vUEs 101/201 bereitstellt, die mit einem gegebenen NAN 110/210 verbunden sind, die Art von Informationen, die durch mehrere NANs 110/210 „en route“ bereitgestellt werden, zum Erreichen von Echtzeit-Verkehrsflussvorhersagen für ein gegebenes vUE 101/201 führen. Solche Informationen können dann für Routenplanung/-aktualisierungen berücksichtigt werden.
  • Des Weiteren sollten zelluläre Handover nicht die Notwendigkeit erzeugen, die fahrtbewusste vUE-QoS-Vorhersageprozedur von Anfang an auszulösen (z. B. Schritt 1 oben), da die geplante Fahrt und die Datentransfers (z. B. installierte SW-Paketversionen usw.) während der geplanten Fahrt von dem (Master-)MEC-Host 140/240 zu dem (Master-)MEC-Host 140/240 (z. B. über eine X2- oder Xn-Schnittstelle zwischen RAN-Knoten oder dergleichen) übergeben oder übertragen werden können. Eine solche „Datenweiterleitung“ ist möglich, da der MEC-Orchestrator (im Folgenden besprochen) des MEC-Systems MEC-Host-Einsatzspezifikationen kennt. Die Kommunikationen zwischen MEC-Hosts 140/240 und vUEs 101/201 und/oder zwischen mehreren MEC-Hosts 140/240 können Sicherheitsprozeduren/-protokolle verwenden, wie zum Beispiel OAuth2.0-Autorisierungsframework, das es einer Drittanwendung ermöglicht, begrenzten Zugriff auf einen HTTP-Dienst (https://restfulapi.net/security-essentials/) zu erhalten; Transport Layer Security (TLS), bei dem es sich um ein kryptografisches Protokoll handelt, das Kommunikationssicherheit über ein Computernetzwerk bereitstellt (https://blog.restcase.com/introduction-torest-api-security/); HTTPS, das die Übertragung der Nachricht über das Netzwerk sichert und dem Client eine gewisse Sicherheit über die Identität des Servers bereitstellt; und/oder beliebige andere geeignete Kommunikationsmechanismen.
  • II. MEC- VIS FÜR ROUTENSPEZIFISCHE QoS-VORHERSAGEN
  • Ausführungsformen hierin betreffen V2X-Dienste und QoS-Vorhersagen entlang geplanter Trajektorien von Fahrzeugen (z. B. Fahrzeug-UEs (vUEs), Fahrzeug-ITS-Stationen (V-ITS-S) und dergleichen), unter Annahme des Einsatzes von MEC-Infrastruktur neben RANs (und/oder individuellen RAN-Knoten), wie etwa 3GPP-RANs der fünften Generation (5G), 3GPP-LTE-E-UTRANs, WiFi-Drahtloszugangspunkten (WAPs), Intelligent-Transport-System(ITS)-Straßenrandgeräten (R-ITS-S) und/oder dergleichen. Bei Ausführungsformen können genaue und rechtzeitige Vorhersagen der Funkumgebung an Orten, die von Fahrzeugen besucht werden sollen, (i) die Anwendung bestimmter V2X-Funktionalitäten und/oder (ii) das Herunterladen von Softwarepaketen, die Lieferung von Inhalt (z. B. Streaming-Medien) und/oder dergleichen entweder auslösen, modifizieren oder verschieben. Mehrfachzugriffs-Edge-Computing (MEC) ist eine Technologie, die ermöglicht, dass Anwendungen am Rand des Zugangsnetzwerks instanziiert werden, und Endgeräten/UEs eine Umgebung mit niedriger Latenz und unmittelbarer Nähe bereitstellt. Infolgedessen wird erwartet, dass vertikale Industrien, wie etwa die Automobilindustrie, signifikant von dem Einsatz einer MEC-Infrastruktur zusammen mit dem RAN profitieren.
  • 4 veranschaulicht ein beispielhaftes V2X-Systemszenario 400, bei dem ein MEC-Host 440 in Kollokation mit einem Netzwerkzugangsknoten (NAN) 410 eingesetzt wird, der Abdeckung bereitstellt (z. B. V2X-Kommunikationsdienste). Der NAN 410 kann eine Straßenrandeinheit (RSU) oder eine Straßenrand-ITS-Station (R-ITS-S), eine zelluläre Basisstation (z. B. eine evolved NodeB (eNB), eine Next Generation NodeB (gNB) oder dergleichen) oder ein anderes Netzwerkelement sein, das eine Netzwerkabdeckung (z. B. V2X-Kommunikationsdienste) für die vUEs 101 bereitstellt (einschließlich eines ersten vUE 401-1 und eines zweiten vUE 401-2). Der MEC-Host 440 stellt unter anderem VIS, RNI-Dienste (RNIS), Standortdienste (LS), UE ID-Dienste, BWM-Dienste (BWMS), WAI-Dienste (WAIS), FAI-Dienste (FAIS) und/oder andere MEC-Dienste bereit. In 4 sind eine geplante Trajektorie des ersten vUE 401-1 und des zweiten vUE 401-2 an dem NAN 410 oder dem MEC-Host 440 nicht bekannt. Da V2X-Systemszenarien jedoch durch hohe Mobilität und dynamische Topologie gekennzeichnet sind, werden die Genauigkeit und die Zeitigkeit von Informationen (z. B. Funknetz, Standortinformationen usw.), wenn sie zentral durch einen MEC-Host 440 gesammelt werden, durch die Umgebungssituation (z. B. das Auftreten von Netzwerküberlastungsereignissen, wenn mehrere vUEs 401 versuchen, Funkmessungen an den NAN 410, der zusammen mit dem MEC-Host 440 angeordnet ist, bereitzustellen), sowie durch die Einsatzdichte des zellulären Netzwerks zusammen mit den Fähigkeiten der eingesetzten MEC-Infrastruktur beeinträchtigt.
  • Ein Beispiel, das die Auswirkung der oben erwähnten Einschränkungen auf die Systemleistungsfähigkeit veranschaulicht, ist das eines Fahrzeugs, das einer Trajektorie von einem ersten Ort („Ort A“) zu einem zweiten Ort („Ort B“) folgen soll, und einer zugehörigen MEC-App, die „en route“ vor der Passierzeit des vUE 401 über Funkbedingungen informiert werden müsste, bevor eine Entscheidung getroffen wird. Die „Entscheidungen“ können zum Beispiel Aktivieren/Deaktivieren von Autonomfahrmerkmalen, Herunterladen von Infotainmentinhalten (z. B. Medien-Streaming, Immersive Gaming und dergleichen), Planen von Software-Over-The-Air(SOTA)- und/oder Firmware-Over-The-Air(FOTA)-Aktualisierungen (z. B. relevant für Fahrsicherheits-/Komfortzwecke) und dergleichen beinhalten. In aktuellen MEC-Systemen stehen fahrtsspezifische Umgebungs-/Situationsinformationen den vUEs 401 nur zusammen mit einer Menge für die geplante Route irrelevanter Daten zur Verfügung. Mit anderen Worten sind die verteilten Daten mit nutzlosen Informationen „kontaminiert“, was aus einer Verzögerungssicht nachteilig ist, da mehr Zeit benötigt wird, um unter der Annahme derselben Datenübertragungsrate eine große Datei herunterzuladen.
  • Um solche Herausforderungen zu adressieren, unterstützt der VIS der vorliegenden Ausführungsformen beim Implementieren eines Frameworks für kooperative Erfassung, Partitionierung und Verteilung von Informationen für effiziente, fahrtspezifische QoS-Vorhersage. Das heißt, der VIS kann genutzt werden, um Raum/Zeit-Korrelationen zwischen Funkqualitätsdaten, die durch verschiedene vUEs 401 in einem V2X-System gesammelt werden, und einer geplanten Fahrt eines spezifischen vUEs 401 zur besseren Vorhersage der Qualität des Kommunikationsnetzwerks entlang der designierten Route zu identifizieren. Infolgedessen kann der VIS relevante (z. B. fahrtspezifische) Informationen über die QoS-Vorhersage gegenüber autorisierten vUEs 401 offenlegen.
  • Aktuelle/vorherige Lösungen der oben genannten Probleme schließen die in Filippou et al., ETSI-MEC(18)000227r2, „MEC002 - In-vehicle MEC hosts supporting automotive workloads“, MEC#104-Tech (12. Juni 2018) („[R01]“) besprochenen ein, worin ein neuer MEC-Verwendungsfall auf fahrzeuginternen MEC-Hosts, die Automobilarbeitslasten unterstützen, vorgeschlagen wird. Insbesondere erörtert [R01] eine MEC-Architektur, die mittels MEC-Hosts realisiert wird, die an Bord von vUEs 401 eingesetzt werden, die Inhaltsspeicherungs- und Speicherfähigkeiten bietet und Kontextbewusstsein über Nutzung von Funknetz-, Standort- und/oder beliebigen anderen Informationen, die für die sich ändernde Umgebung während der Fahrtzeit relevant sind, verbessern kann. Ferner wird erwähnt, dass, unter anderem, mögliche Arten von Arbeitslasten, die durch MEC-Apps gehostet werden sollen, die auf fahrzeuginternen MEC-Hosts instanziiert sind, maschinelles Lernen (ML), Datenanalytik, Sensorfusionsmessungen und/oder andere Arbeitslastarten beinhalten können. Infolgedessen beinhaltet ETSI GS MEC 002 v2.1.1 (2018-10) („[R02]“) einen Verwendungsfall eines fahrzeuginternen MEC-Host, der Automobilarbeitslasten unterstützt, zusammen mit einem Satz damit verbundener Anforderungen. Ausführungsformen, die sich auf fahrzeuginterne MEC-Hosts beziehen, werden im Folgenden ebenfalls ausführlicher erörtert. Die MEC-Technologiekomponenten und Mechanismen zum Verbessern von Kontextbewusstsein und prädiktiver QoS sind jedoch in [R01] und [R02] nicht erläutert. [R01] und [R02] erwähnen auch nicht, ob und wie erwartet wird, dass ein solcher Paradigmenwechsel beim MEC-Einsatz (und möglicherweise bei der MEC-Architektur) die Genauigkeit und Zeitigkeit des Erfassens und sogar des Vorhersagens von Funknetzinformationen verbessert, wenn V2X-Szenarien betrachtet werden. Des Weiteren ermöglichen die Lösungen von [R01] und [R02] nicht, dass vUEs 401 ohne fahrzeuginterne MEC-Hosts die Vorteile eines verbesserten Kontextbewusstseins und/oder einer fahrtspezifischen prädiktiven QoS ausnutzen.
  • Das Thema intelligenter, datenzentrischer Entscheidungsfindung für effiziente V2X-Kommunikation wurde auch in akademischen Schriften behandelt, wie etwa Ye et al. „Machine Learning for Vehicular Networks“, arXiv: 1712.07143v2 (26. Feb. 2018) („[R03]“), worin ein Überblick über jüngste Fortschritte von ML zur Lösung von Problemen von V2X-Kommunikationssystemen, wie Verkehrsflussvorhersage, Staukontrolle und lokale Datenspeicherungsaspekte, gegeben ist. Ein praktischer Lösungsaufbau wurde jedoch in [R03] nicht vorgeschlagen. Stattdessen betrifft [R03] das Anpassen bestehender Lernverfahren oder das Entwickeln V2X-spezifischer Lernalgorithmen, um solche Charakteristiken besser zu handhaben, bleibt eine herausfordernde Aufgabe, und praktische Überlegungen, die zu beachten sind, bevor ein ML-Verfahren zur Unterstützung der Entscheidungsfindung angewandt wird. Zu den praktischen Überlegungen zählen die erhöhte Dynamik der Netzwerktopologie, Drahtloskanäle und das Verkehrsprofil, Algorithmuskomplexitätsprobleme, da die Verarbeitungsleistung an einem Fahrzeug im Allgemeinen begrenzt ist, während eine Cloud-basierte Lösung möglicherweise große Latenzen verursachen würde, sowie die Herausforderungen verteilter lernbasierter Lösungen. Zudem diskutiert [R03] nicht die praktische Dimension des Problems in Bezug auf MEC-Infrastruktur und Informationsaustauscheinrichtungen/-protokolle (z. B. MEC-APIs und/oder relevante MEC-Apps).
  • Die Ausführungsformen hierin betreffen fahrtbewusste QoS-Vorhersage für vUEs. Insbesondere beinhalten Ausführungsformen ein V2X-System, das von MEC-Hosts überlagert ist. In einer ersten Ausführungsform (Ausführungsform 1) werden MEC-Hosts nur auf der Netzwerkinfrastrukturseite eingesetzt. Bei einer zweiten Ausführungsform (Ausführungsform 2) werden die MEC-Hosts auf der Netzwerkinfrastrukturseite und auf der vUE-Seite eingesetzt (z. B. „fahrzeuginterne MEC-Hosts“). Ausführungsformen hierin beinhalten auch ein Framework für kooperative Erfassung, Partitionierung und Verteilung von Informationen für effiziente, fahrtspezifische QoS-Vorhersage.
  • Aus technischer Sicht erreicht ein erster Vorteil des MEC-basierten Frameworks für kooperative Erfassung, Partitionierung und Verteilung von Informationen für effiziente, fahrtspezifische QoS-Vorhersage im Voraus korrekte Entscheidungen (z. B. zum Optimieren von FOTA/SOTA-Downloads, Inhalt-Streaming und/oder einer beliebigen Art von Inhalttransfer). Solche Entscheidungen basieren auf fahrtspezifischen RNI und nicht auf globalen Informationen, die für eine gegebene geplante Route, der ein vUE folgen soll, wenig bis keine Relevanz bereitstellen können. Außerdem kann mit Bezug auf Ausführungsform 2 die erhaltene RNI-Informationspartition für prädiktive QoS-Zwecke genutzt und auch als Verlaufsinformationen gespeichert werden, die beim nächsten Mal, wenn ein vUE der gleichen oder einer ähnlichen Route folgt (z. B. Büro-Pendeln), herangezogen werden können. Diese historischen Informationen können verwendet werden, um Rechenoverhead zu reduzieren, wenn Ressourcen zu vUEs zugewiesen werden, die die gleichen oder ähnliche Routen nehmen.
  • Die folgende Diskussion beschreibt die Ausführungsformen des kooperativen RNI-Vorhersage- und -Inhaltslieferungsentscheidungsframework in Bezug auf SOTA/FOTA-Aktualisierungen. Die Ausführungsformen hierin sind jedoch auch auf andere Arten von Inhalt-/Datenlieferung zusätzlich zu oder alternativ zu SOTA/FOTA-Aktualisierungen anwendbar, darunter Aktivieren/Deaktivieren von Autonomfahrmerkmalen, Herunterladen von Infotainmentinhalt, rechnerisches Offloading, kooperatives ML und/oder andere ähnliche Datenübermittlungen, wie etwa gemäß anderen hier besprochenen beispielhaften Verwendungsfällen.
  • II.A. BEISPIELHAFTE PROZEDUR ZUR FAHRTSPEZIFISCHEN QOS-VORHERSAGE & AUFGABENENTSCHEIDUNG
  • 5 zeigt einen beispielhaften Prozess 500 zur fahrtbewussten (oder routenbewussten) QoS-Vorhersage für die erste und zweite Ausführungsform. Der Prozess 500 kann verwendet werden, um verschiedene durchzuführende Aufgaben und/oder Entscheidungen, diese Aufgaben zu übernehmen, basierend auf vorhergesagter, fahrtspezifischer QoS zu bestimmen. Der Prozess 500 wird mit Bezug auf das Erhalten/Herunterladen von SW/FW-Paketaktualisierungen besprochen, jedoch können die Ausführungsformen hierin zum Erhalten anderer Arten von Daten/Inhalten (z. B. Entscheidungen/Aufgaben zum Streamen von Inhalt, wie etwa Videodaten, AR/VR oder andere interaktive Gaming-Daten usw.) oder zum Bestimmen anderer Entscheidungen/Aufgaben (z. B. ob Automatisierungsaufgaben aktiviert oder deaktiviert werden sollen, ob Betriebsparameter des vUE oder der Komponente(n) darin geändert werden sollen usw.) verwendet werden. Unter Bezugnahme auf 1A, 1B, 2, 3 und 4 kann ein beispielhafter Prozess 500 gemäß den Ausführungsformen hierin die folgenden Operationen beinhalten.
  • Der Prozess 500 beginnt bei Operation 505, bei der jede Client-App (z. B. UE-App 202), die auf jeweiligen vUEs (z. B. vUEs 101, 201, 301, 401) läuft, die auf einem NAN (z. B. NAN 110, 210, 410) campen, ihre Geplante-Fahrt-Informationen (z. B. Kartenkoordinaten und/oder Routendaten) an einen MEC-Host (z. B. MEC-Host 140, 240, 340, 440) meldet. Der MEC-Host kann zusammen mit einem NAN (RAN-Knoten oder einem anderen Netzwerkelement) angeordnet sein und kann auch einen (Geo-)Lokalisierungsdienst und/oder andere Dienste ausführen. Die Geplante-Fahrt-Informationen können durch Information über den/die während der geplanten Fahrt stattfindenden Datenransfer(s) ergänzt werden. Wenn das vUE zum Beispiel ein aktualisiertes SW/FW-Paket erhalten soll, können die Informationen eine Version eines SW/FW-Pakets beinhalten, das gegenwärtig auf dem vUE installiert ist oder läuft. Das SW/FW-Paket kann die Client-App selbst oder ein anderes SW/FW-Paket sein.
  • Als Nächstes liefert bei Operation 510 jedes vUE Funkinformationen an den MEC-Host. Bei Ausführungsformen meldet jedes vUE Funkinformationen entweder mit einer niedrigen Periodizität oder einer hohen Periodizität in Abhängigkeit von dem Datentransfer, der stattfinden soll, und/oder anderen Informationen über den Datentransfer. Zum Beispiel kann die SW/FW-Paket-Versionsnummer verwendet werden, um zu bestimmen, ob die Funkinformationen mit einer niedrigen oder hohen Periodizität bereitgestellt werden sollten. Die Funkinformationen können in Form eines oder mehrerer Messberichte vorliegen und/oder können zum Beispiel Signalstärkemessungen, Signalqualitätsmessungen und/oder dergleichen beinhalten. Jeder Messbericht wird mit einem Zeitstempel und dem Ort der Messung (z. B. der aktuelle Standort des vUE) markiert.
  • Als Beispiele können die durch die vUEs erfassten und/oder in den Messberichten enthaltenen Messungen eines oder mehrere der Folgenden beinhalten: Bandbreite (BW), Netzwerk- oder Zelllast, Latenz, Jitter, Umlaufzeit (RTT), Anzahl von Interrupts, Out-oforder-Lieferung von Datenpaketen, Sendeleistung, Bitfehlerrate, Bitfehlerverhältnis (BER), Blockfehlerrate (BLER), Paketverlustrate, Paketempfangsrate (PRR), e2e-Verzögerung, Signal-Rausch-Verhältnis (SNR), Signal-Rausch-und-Störung-Verhältnis (SINR), Signal-plus-Rausch-plus-Verzerrung-zu-Rausch-plus-Verzerrung(SINAD)-Verhältnis, Träger-zu-Störung-plus-Rausch-Verhältnis (CINR), Additives weißes Gaußsches Rauschen (AWGN), Energie-pro-Bit-zu-Rauschleistungsdichte-Verhältnis (Eb/N0), Energie-pro-Bit-zu-Störleistungsdichte-Verhältnis (Ec/I0), Spitzen-zu-Mittlerer-Leistung-Verhältnis (PAPR), Referenzsignalempfangsleistung (RSRP), Referenzsignalstärkeindikator (RSSI), Referenzsignalempfangsqualität RSRQ, GNSS-Timing von Zellenframes zur UE-Positionsbestimmung für E-UTRAN oder 5G/NR (z. B. ein Timing zwischen einer AP- oder RAN-Knoten-Referenzzeit und einer GNSS-spezifischen Referenzzeit für ein gegebenes GNSS), GNSS-Codemessungen (z. B. die GNSS-Codephase (Ganzzahl- und Nachkommaanteile) des Spreizcodes des i-ten GNSS-Satellitensignals), GNSS-Trägerphasenmessungen (z. B. die Anzahl von Trägerphasenzyklen (Ganzzahl- und Nachkommaanteile) des i-ten GNSS-Satellitensignals, gemessen seit Einkoppeln des Signals; auch als Accumulated Delta Range (ADR) bezeichnet), Kanalstörungsmessung, Wärmerauschleistungsmessung, Empfangsstörleistungsmessung und/oder andere ähnliche Messungen. Die RSRP-, RSSI- und/oder RSRQ-Messungen können RSRP-, RSSI- und/oder RSRQ-Messungen zellenspezifischer Referenzsignale, Kanalzustandsinformationsreferenzsignale (CSI-RS) und/oder Synchronisationssignale (SS) oder SS-Blöcke für 3GPP-Netzwerke (z. B. LTE oder 5G/NR) und RSRP-, RSSI- und/oder RSRQ-Messungen verschiedener Beacon-, Fast-Initial-Link-Setup(FILS)-Entdeckungsframes oder Sondierungsantwortframes für IEEE-802.11-WLAN/WiFi-Netzwerke beinhalten. Andere Messungen können zusätzlich oder alternativ verwendet werden, wie etwa jene, die in 3GPP TS 36.214 v15.3.0 (2018-09-27) („[R15]“), 3GPP TS 38.215 v15.4.0 (2019-01-11) („[R16]“), IEEE 802.11, Teil 11: „Wireless LAN Medium Access Control (MAC) und Physical Layer (PHY) specifications, IEEE Std.“ („[R17]“) und/oder dergleichen besprochen werden. Zusätzlich oder alternativ dazu kann eine beliebige der zuvor genannten Messungen (oder Kombination von Messungen) durch einen oder mehrere NANs erfasst und dem MEC-Host bereitgestellt werden. Bei diesen Ausführungsformen kann der MEC-Host die Messungen von den NANs mit niedriger oder hoher Periodizität anfordern, oder die NANs können die Messungen dem MEC-Host mit niedriger oder hoher Periodizität bereitstellen. Zusätzlich oder alternativ dazu kann der MEC-Host andere relevante Daten von anderen MEC-Hosts, Kernnetzwerkfunktionen und/oder anderen vUEs erhalten, um die QoS-Vorhersagen zu bestimmen und/oder die zusammengesetzten Informationen zu erzeugen. Zum Beispiel können andere Leistungskennzahlen (KPIs: Key Performance Indicators) von anderen MEC-Hosts über geeignete MEC-APIs und/oder von Kernnetzwerkfunktionen über Netzwerkoffenlegungsfunktionen erfasst und zum Vorhersagen der QoS entlang der geplanten Route und/oder zum Erzeugen zusammengesetzter Informationen (im Folgenden besprochen) verwendet werden. Zusätzlich oder alternativ dazu können die vUEs die anderen relevanten Informationen erhalten und diese Informationen mit den Messberichten oder getrennt von den Messberichten an den MEC-Host liefern.
  • Bei Operation 515 kompiliert der MEC-Host QoS-Vorhersagen und/oder zusammengesetzte Informationen basierend auf der geplanten Route jedes vUE und/oder den Messberichten oder erzeugt diese anderweitig. Die QoS-Vorhersagen können eine vorhergesagte QoS für verschiedene Punkte entlang der geplanten Route des vUE beinhalten. Die zusammengesetzten Informationen können zum Beispiel Empfehlungen darüber, ob Datentransfers an den verschiedenen Punkten auf der geplanten Route durchgeführt werden sollen, und/oder Inhalt, der basierend auf der vorhergesagten QoS auf der geplanten Fahrt an das vUE geliefert werden soll, beinhalten. In einigen Ausführungsformen kann der MEC-Host einen trainierten ML-Algorithmus betreiben, um die QoS entlang der geplanten Route vorherzusagen und/oder die zusammengesetzten Informationen zu erzeugen. Beispielsweise kann ein trainiertes neuronales Netz, wie etwa neuronale Faltungsnetze und/oder rekurrente neuronale Netze, Inferenzen unter Verwendung von Eingangsdaten, die zeitlich variierende Funkmessungen und Standortinformationen angeben, bestimmen. Die konkret verwendeten ML-Modelle/Algorithmen können von Ausführungsform zu Ausführungsform variieren.
  • Wenn zusammengesetzte Informationen erzeugt werden, partitioniert oder repartitioniert der MEC-Host die zusammengesetzten Informationen in einzelne Datenblöcke, Chunks oder Partitionen, von denen jede(r) für eine bestimmte geplante Route, ein bestimmtes vUE oder ein Cluster oder eine Gruppe von vUEs relevant ist, die planen, derselben oder einer ähnlichen Route/Fahrt zu folgen (z. B. ein Fahrzeug-Platoon). Information(neu-)partitionierung ist eine Vorverarbeitungsstufe, um einen Nutzdatensatz zu erhalten, der für fahrtspezifische QoS-Vorhersagen verwendet werden soll. Die zusammengeführten Informationen an einem Master-MEC-Host werden gemäß der Relevanz für die geplanten Fahrten der vUEs partitioniert, unabhängig davon, ob fahrzeuginterne MEC-Hosts existieren, nicht existieren oder an den vUEs nicht verfügbar sind. Zusätzlich oder alternativ dazu werden zusammengeführte Informationen an fahrzeuginternen MEC-Hosts gemäß der Relevanz für die zuvor erfassten geplanten Fahrten der vUEs partitioniert.
  • Beliebige geeignete Datenfusions- oder Datenintegrationstechnik(en) können verwendet werden, um die zusammengesetzten Informationen zu erzeugen. Zum Beispiel kann die Datenfusionstechnik eine direkte Fusionstechnik oder eine indirekte Fusionstechnik sein. Direkte Fusion kombiniert Daten, die direkt von mehreren vUEs oder Sensoren erfasst werden, die gleich oder ähnlich sein können (z. B. alle vUEs oder Sensoren führen die gleiche Art von Messung durch) oder verschieden sein können (z. B. verschiedene vUEs oder Sensortypen, historische Daten usw.). Indirekte Fusion nutzt historische Daten und/oder bekannte Umgebungseigenschaften und/oder menschliche Eingaben, um einen verfeinerten Datensatz zu erzeugen. Zusätzlich dazu kann die Datenfusionstechnik einen oder mehrere Fusionsalgorithmen beinhalten, wie etwa einen Glättungsalgorithmus (z. B. Schätzen eines Werts unter Verwendung mehrerer Messungen in Echtzeit oder nicht in Echtzeit), einen Filteralgorithmus (z. B. Schätzen eines Zustands einer Entität mit aktuellen und vergangenen Messungen in Echtzeit), und/oder einen Vorhersagezustandsschätzalgorithmus (z. B. Analysieren historischer Daten (z. B. Standort, Geschwindigkeit, Richtung und Signalmessungen) in Echtzeit, um einen Zustand (z. B. eine zukünftige Signalstärke/-qualität an einer bestimmten Standortkoordinate vorherzusagen). Somit kann bei manchen Ausführungsformen eine Datenfusion verwendet werden, um verschiedene vUE-Parameter zu schätzen, die nicht durch dieses vUE bereitgestellt werden, sowie um QoS und/oder Signalqualität einer bestimmten Fahrt oder Route vorherzusagen. Als Beispiele kann der Datenfusionsalgorithmus ein strukturbasierter Algorithmus (z. B. baumbasierter (z. B. Minimum Spanning Tree (MST)), clusterbasierter, gitterbasierter und/oder zentralisierter), ein strukturfreier Datenfusionsalgorithmus, ein Kalman-FilterAlgorithmus, ein Fuzzy-basierter Datenfusionsalgorithmus, ein Ant-Colony-Optimization(ACO)-Algorithmus, ein Fehlererkennungsalgorithmus, ein Dempster-Shafer(D-S)-Argumentationsbasierter Algorithmus, ein Gaußsches-Mischmodell-Algorithmus, ein triangulationsbasierter Fusionsalgorithmus und/oder ein beliebiger anderer ähnlicher Datenfusionalgorithmus sein oder diese beinhalten.
  • Bei Operation 520 verarbeitet eine MEC-App an dem MEC-Host (zusammen mit dem NAN und/oder dem fahrzeuginternen MEC-Host angeordnet) jede Partition in Abhängigkeit von der Existenz oder Abwesenheit von fahrzeuginternen MEC-Hosts an jedem vUE. Bei Ausführungsformen kann die MEC-App durch eine Angabe der Verfügbarkeit eines neuen SW/FW-Pakets ausgelöst werden, um mit der Verarbeitung jeder Partition zu beginnen. Die Partitionen werden gemäß einer ersten Ausführungsform verarbeitet, wenn die vUEs keine fahrzeuginternen MEC-Hosts hosten. Die Partitionen werden gemäß einer zweiten Ausführungsform verarbeitet, wenn die vUEs fahrzeuginterne MEC-Hosts hosten.
  • Bei der ersten Ausführungsform (wenn es keine fahrzeuginternen MEC-Hosts gibt oder die fahrzeuginternen MEC-Hosts nicht verfügbar sind) werden die zusammengesetzten Informationen in fahrt-/routenspezifische Partitionen partitioniert, die Funksignalqualität für jede geplante Fahrt/Route umfassen. Die fahrtspezifischen Partitionen werden zusammen mit den SW/FW-Paketversionen, die auf jedem der vUEs laufen, als Eingaben zur Entscheidungsfindung (z. B. zum Bestimmen fahrtspezifischer QoS-Vorhersagen) verwendet. Nachdem eine fahrtspezifische QoS-Vorhersage am MEC-Host durchgeführt wurde, wird die Entscheidung des Empfehlens des Starts/Herunterladens einer SW/FW-Aktualisierung durch die MEC-App am MEC-Host getroffen. Dann wird bei Operation 525 die Empfehlung mittels Unicast- oder Multicastübertragungen an die Client-Apps weitergeleitet, die auf dem (den) vUE(s) laufen, die (i) eine geplante Route aufweisen, die auf eine fahrtspezifische Partition zugeschnitten ist, (ii) veraltete SW/FW-Pakete ausführen und (iii) voraussichtlich günstige Funkbedingungen entlang ihrer geplanten Route erfahren.
  • Bei der zweiten Ausführungsform (wenn fahrzeuginterne MEC-Hosts verfügbar sind) werden die zusammengesetzten Informationen in fahrt-/routenspezifische RNI partitioniert, die bei Operation 525 verpackt und an individuelle Client-Apps an den vUEs übertragen werden. Hier kann Operation 525 Unicastübertragungen zu einzelnen vUEs oder Multicastübertragung(en) zu einem Cluster oder einer Gruppe von vUEs, die eine gleiche oder eine ähnliche geplante Route aufweisen, einschließen. Jede Client-App führt anhand der empfangenen fahrtspezifischen RNI und der Version des aktuell installierten SW/FW-Pakets eine fahrtspezifische QoS-Prädiktion durch. Jede Client-App kann auch eine oder mehrere andere lokal laufende Anwendungen sowie andere Betriebsparameter (z. B. Ressourcennutzung und dergleichen) berücksichtigen. Jede Client-App entscheidet über Planungsaufgaben (z. B. SW/FW-Aktualisierungen/Paketdownloads) unter Verwendung einer RNI-Analytik-MEC-Anwendung, die an dem fahrzeuginternen MEC-Host instanziiert ist, während der Fahrt zum Ziel.
  • Wenn der MEC-Host oder das vUE eine Änderung der geplanten Fahrt detektiert, wird der Prozess 500 mit aktualisierten Fahrtinformationen wiederholt. Die Änderung der geplanten Fahrt/Route kann auf Sensordaten, GPS-Daten, 5G/LTE-Standortdienstdaten, Daten von einer oder mehreren Anwendungen und/oder dergleichen basieren. Jede Client-App an jedem vUE kann eine geeignete API, einen geeigneten Treiber usw. verwenden, um mit den Sensoren, GPS-Schaltungsanordnungen und/oder anderen Anwendungen zu interagieren, um Daten zum Vornehmen einer solchen Bestimmung zu erhalten.
  • II. B. AUSFÜHRUNGSFORM 1
  • Die erste Ausführungsform bezieht sich auf Implementierungen, bei denen MEC-Hosts (z. B. MEC-Hosts 140, 240, 340, 440 aus 1A, 1B, 2, 3 und 4; MEC-Host 1502 aus 15 oder dergleichen) an einem oder mehreren NANs (z. B. NANs 110, 210, 410 aus 1A, 1B, 2 und 4) eingesetzt oder gemeinsam mit diesen angeordnet sind.
  • Die folgenden Datenstrukturen können verwendet werden, um das kooperative RNI-Prädiktions- und Inhaltlieferungsentscheidungsframework zu implementieren. Wie in Schritt 1 der fahrtbewussten vUE-QoS-Vorhersage- und -Aufgabenentscheidungsprozedur erwähnt, meldet jede Client-App, die in einem vUE läuft, geplante Fahrt-/Routeninformationen an einen MEC-Host. Eine Datenstruktur für die geplanten Routeninformationen mit einer Kennung (ID) wie „UE_ID“ beinhaltet die Koordinaten der folgenden Orte: des Ursprungsorts, der sich auf Punkt A in einer Route von Punkt A zu Punkt B bezieht (z. B. „Ursprung A“); des Zielorts, der sich auf Punkt B in einer Route von Punkt A zu Punkt B bezieht (z. B. „Ziel B“); und einer Anzahl von Zwischenorten, die die Trajektorie oder Route widerspiegeln, zu denen oder durch die das vUE auf der Route fahren soll (z. B. spezifische Straßen, Schnellstraßen usw.). Tabelle 1 zeigt eine beispielhafte Datenstruktur, mit der diese Ortsinformation übermittelt werden können. Tabelle 1
    UE_ID Routenpunkte Geografischer Standort
    Ausgangspunkt A 41 °24'12.2"N, 2°10'26.5"E
    Zwischenort 1 41 °23'14.9"N, 2°12'32.7"E
    Zwischenort 2 41 °22'31.8"N, 2°14'21.8"E
    ...
    Zwischenort N 41°17'16.2"N, 2°19'34.1"E
    Ziel B 41°15'23.6"N, 2°24'18.1"E
  • Eine Datenstruktur, die das Format einer Nachricht repräsentiert, die periodisch durch die vUE in Schritt 2 der fahrtbewussten vUE-QoS-Vorhersageprozedur übertragen und durch den NAN, der zusammen mit dem MEC-Host angeordnet ist, empfangen wird. Die unterschiedlichen Attribute der Nachricht können Folgendes beinhalten: die ID des Fahrzeugs „UE_ID“, die Nachrichtenübertragungszeit oder den Zeitstempel („TS“), den Standort des vUE zur Übertragungszeit („UE Loc“) und lokale Funkmessungen an dem vUE (z. B. die RSRP/RSRQ-Werte, die über ein Zeitfenster akkumuliert wurden, das zum Zeitpunkt TS endet (z. B. die Nachrichtenübertragungszeit)). Ein Beispiel für ein solches Nachrichtenformat ist in Tabelle 2 dargestellt. Tabelle 2
    UE_ID TS UE_Loc Messungen
  • Eine Datenstruktur für die Nachricht, die durch die RSU/eNB übertragen wird, um das betreffende UE (z. B. über eine Unicastübertragung) oder den betreffenden Cluster von UEs (z. B. über eine Multicastübertragung) in Schritt 4a der fahrtbewussten vUE-QoS-Vorhersageprozedur zu informieren. Diese Nachricht wird verwendet, um die Verfügbarkeit einer aktualisierten SW-Paketversion mit ID „SW_Ver_New“, der empfohlenen Zeit des Downloadstarts „DL_Start_Time“ und der erwarteten Dauer des Downloads „DL_Exp_Dur“ basierend auf den vorhergesagten Funkbedingungen entlang der Route des Fahrzeugs bzw. der Fahrzeuge anzugeben. Tabelle 3
    SW_Ver_New DL_Start_Time DL_Exp_Dur
  • 6 zeigt einen beispielhaften Prozess 600 gemäß der ersten Ausführungsform. Der Prozess 600 ist ein einziger Entscheidungszyklus, der durch einen MEC-Host 440 durchgeführt werden kann, der zusammen mit dem NAN 410 und einem vUE 401 innerhalb des Abdeckungsbereichs des NAN 410 angeordnet ist (siehe z. B. 4). Der Prozess 600 wird gemäß Beschreibung verwendet, um eine Entscheidung darüber zu treffen, ob Software(SW)- und/oder Firmware(FW)-Aktualisierungen heruntergeladen werden sollen, jedoch kann der Prozess 600 verwendet werden, um Entscheidungen über andere Arten von Datentransferverwendungsfällen, wie etwa die hier besprochenen, zu treffen.
  • Die Prozedur 600 beginnt bei Operation 601, bei der der MEC-Host 440 einen aktuellen/aktualisierten Fahrtplan von dem vUE 401 zusammen mit der Version seiner laufenden SW und/oder FW zu dem MEC-Host 440 über den gemeinsam damit angeordneten/verbundenen NAN 410 empfängt. Bei Operation 602 bestimmt der MEC-Host 440, ob eine neue SW/FW-Paketversion für das vUE verfügbar ist. Falls der MEC-Host 440 bestimmt, dass keine neue SW/FW-Paketversion für das vUE verfügbar ist, geht der MEC-Host 440 zu Operation 603 über, bei der der MEC-Host 440 von dem vUE periodisch lokal erfahrene Funkqualitätsinformationen an dem vUE 401 empfängt. Dies kann eine relativ niedrige Abtast-/Nachrichtenübermittlungsrate (z. B. L < K Zyklen, wobei L und K Zahlen sind) beinhalten. Bei Operation 604 partitioniert der MEC-Host 440 die erfassten Mehrfahrzeuginformationen gemäß Kontext (z. B. Relevanz für die geplanten Routen der unter Abdeckung stehenden vUEs) erneut, und bei Operation 605 empfiehlt der MEC-Host 440 das Starten/Verschieben von SW-OTA(SOTA)/FW-OTA(FOTA)-Aktualisierungen und informiert die unter Abdeckung stehenden vUEs, die diese Aktualisierungen benötigen. Falls bei manchen Ausführungsformen ein aktuell installiertes SW-Paket für ein gegebenes vUE 401 die neueste Version dieses SW-Pakets ist, dann muss bei Operation 605 keine Empfehlung durch das Netzwerk über den MEC-Host 440 bereitgestellt werden. Nach Operation 515 endet die Prozedur 600.
  • Erneut Bezug nehmend auf Operation 602 geht, falls der MEC-Host 440 bestimmt, dass eine neue SW/FW-Paketversion für das vUE 401 verfügbar ist, der MEC-Host 440 zu Operation 606 über, bei der der MEC-Host 440 von dem vUE periodisch lokal erfahrene Funkqualitätsinformationen an dem vUE 401 empfängt. Dies kann eine hohe Abtast-/Nachrichtenübermittlungsrate (z. B. K Zyklen, wobei K eine Anzahl ist) beinhalten. Mit anderen Worten, wenn die gegenwärtig installierte Version des SW/FW-Pakets die aktuellste und/oder neueste Version ist, werden Messungen mit einer niedrigen Rate bereitgestellt (siehe z. B. Operation 603); umgekehrt, wenn die gegenwärtig installierte Version des SW/FW-Pakets nicht die aktuellste und/oder neueste Version ist (wird z. B. keine SW/FW-Paketaktualisierung benötigt oder gewünscht), sollten Messungen mit einer höheren Rate bereitgestellt werden (siehe z. B. Operation 606). Bei Operation 607 partitioniert der MEC-Host 440 die erfassten Mehrfahrzeuginformationen gemäß Kontext (z. B. Relevanz für die geplanten Routen der abdeckenden vUEs) erneut. Bei Operation 608 meldet das vUE 401 seine geplante Fahrt nach der Informationsneupartitionierung an dem MEC-Host 440.
  • Bei manchen Ausführungsformen führt der MEC-Host 440, nachdem der aktualisierte Fahrtplan durch das vUE 401 kommuniziert wurde, keine weitere Informationpartitionierung durch. Stattdessen verknüpft oder assoziiert der MEC-Host 440 die geeignetste Partition (z. B. die am höchsten kontextuell korrelierte Partition) mit dem vUE 401 (siehe z. B. Operation 610) und führt dann fahrtspezifische QoS-Vorhersagen durch und stellt Empfehlungen basierend auf den fahrtspezifischen QoS-Vorhersagen bereit (siehe z. B. Operation 611).
  • Bei Operation 609 bestimmt der MEC-Host 440, ob die geplante Route des vUE 401 noch gültig ist. Falls der MEC-Host 440 bestimmt, dass die geplante Route des vUE 401 nicht mehr gültig ist, dann geht der MEC-Host 440 zu Operation 610 über, um den aktualisierten Fahrtplan mit der höchsten (räumlich) korrelierten Mehrfahrzeuginformationenpartition zu verknüpfen. Dann wertet der MEC-Host 440 bei Operation 611 die erwarteten Bedingungen aus, empfiehlt unter Berücksichtigung der Größe des Pakets das Starten/Verschieben der SOTA/FOTA-Aktualisierung und informiert das vUE. Falls bei Operation 609 der MEC-Host 440 bestimmt, dass die geplante Route des vUE 401 noch gültig ist, dann geht der MEC-Host 440 dazu über, Operationen 611 durchzuführen, ohne Operation 610 durchzuführen. Bei Operation 612 entscheidet das vUE 401, ob der Download gemäß funktionalen Bedürfnissen, Richtlinien, Präferenzen usw. gestartet/verschoben werden soll, oder der MEC-Host 440 bestimmt, ob der Download auf das vUE 401 gemäß funktionalen Bedürfnissen, Richtlinien, Präferenzen usw. des vUE 401 oder des MEC-Hosts 440 gestartet/verschoben werden soll. Nach Operation 612 kann die Prozedur 600 enden.
  • 7 stellt ein beispielhaftes Szenario 700 dar, bei dem ein MEC-Host 740 (der gleich oder ähnlich wie der MEC-Host 440 von 4 ist), der zusammen mit einem NAN 710 (der gleich oder ähnlich wie der NAN 410 von 4 ist) angeordnet ist, und drei vUEs 701 (einschließlich vUE 701-1, vUE 701-2 und vUE 701-3, die gleich oder ähnlich wie die vUEs 401 von 4 sind) unter Abdeckung des NAN 710 stehen (oder auf dem NAN 710 campen). Der NAN 710 kann ein Funkinfrastrukturknoten (z. B. RSU oder R-ITS-S), ein Funkzugangspunkt (RAP), der einen ITS-G5- und/oder DSRC-Netzwerkdienst bereitstellt, oder ein RAN-Knoten, der einen zellulären Netzwerkdienst bereitstellt (z. B. eine eNB, gNB oder dergleichen) sein. In dem Szenario 700 weisen das vUE 701-1 und das vUE 701-2 eine gleiche geplante Route von Ort A zu Ort B auf und das vUE 701-3 hat eine andere Route von Ort C zu Ort D geplant. In diesem Beispiel versucht jedes vUE 701, SOTA- und/oder FOTA-Aktualisierungen zu erhalten, wobei vUE 701-1 eine aktuellste Version (z. B. v1.3) eines spezifischen SW-Pakets installiert hat und vUE 701-2 und vUE 701-3 eine veraltete Version (z. B. v1.2) installiert haben. Damit das vUE 701-2 und das vUE 701-3 eine Empfehlung zum Starten oder Verschieben des SW-Paketdownloads erhalten, kann der Prozess 600 von 6 durchgeführt werden, der wie folgt aussehen kann.
  • Bei Operation 1 meldet das vUE 701-1 dem MEC-Host 740 über eine Übertragung an den NAN 710 eine geplante Fahrt von Ort A zu Ort B und gibt an, dass das SW-Paket v1.3 auf dem vUE 701-1 installiert ist. Bei Operation 2 meldet das vUE 701-2 dem MEC-Host 740 über eine Übertragung an den NAN 710 eine geplante Fahrt von Ort A zu Ort B und gibt an, dass das SW-Paket v1.2 auf dem vUE 701-2 installiert ist. Bei Operation 3 meldet das vUE 701-3 dem MEC-Host 740 über eine Übertragung an den NAN 710 eine geplante Fahrt von Ort C zu Ort D und gibt an, dass das SW-Paket v1.2 auf dem vUE 701-3 installiert ist. Bei Operation 4 laden sowohl das vUE 701-1, das vUE 701-2 als auch das vUE 701-3 jeweilige Funksignalqualitätsmessungen hoch, die auf vUE-Standorte und Zeitstempel zugeschnitten sind. Bei diesem Beispiel lädt das vUE 701-1 im Vergleich zu dem vUE 701-2 und dem vUE 701-3 weniger markierte Messungen hoch, da es (derzeitig) keine SW-Paketaktualisierung benötigt. Bei Operation 5 erfasst und repartitioniert der MEC-Host 740 alle Rohdaten gemäß einem fahrtbasierten Kriterium; es werden zwei Datenpartitionen erhalten: eine relevant für die Route zwischen den Orten A und B und eine relevant für die Route zwischen den Orten C und D.
  • Bei Operation 6 sagt der MEC-Host 740 basierend auf der ersten Datenpartition (bezogen durch vUE 701-1 und vUE 701-2) und zum Beispiel unter Verwendung statistischer Werkzeuge, ML/AI-Algorithmen usw. die Funksignalqualität voraus, die das vUE 701-2 voraussichtlich erfährt, und empfiehlt unter Berücksichtigung der Größe des SW-Pakets, dass das vUE 701-2 den Download startet oder verschiebt. Im Falle eines empfohlenen Starts wird auch die Startzeit des Downloads empfohlen. Bei Operation 7 sagt der MEC-Host 740 die Funksignalqualität voraus, die das vUE 701-3 voraussichtlich erfährt, und empfiehlt unter Berücksichtigung der Größe des SW-Pakets, dass das vUE 701-3 den Download startet oder verschiebt. Die Vorhersage basiert auf der zweiten Datenpartition, die mit vergangenen erhaltenen Messungen angereichert sein kann, die für die Route zwischen den Orten C und D relevant sind. Im Falle eines empfohlenen Starts wird auch die Startzeit des Downloads empfohlen.
  • Obwohl Ausführungsform 1 als durch MEC-Hosts implementiert erörtert wird, die zusammen mit der Netzwerkzugangsinfrastruktur angeordnet sind, könnte bei manchen Implementierungen ein fahrzeuginterner MEC-Host (siehe z. B. 8-9) fahrtspezifische QoS-Vorhersagen für seine eigenen lokalen MEC-Apps oder für andere MEC-Hosts (einschließlich anderer fahrzeuginterner MEC-Hosts) bereitstellen, falls Fahrzeug-zu-Fahrzeug(V2V)-Kommunikation möglich ist, z. B. durch Nutzen von Sidelink-/Kurzstreckenkonnektivität.
  • II. C. AUSFÜHRUNGSFORM 2
  • Die zweite Ausführungsform betrifft MEC-Systemimplementierungen, bei denen MEC-Hosts an einem oder mehreren NANs eingesetzt werden oder gemeinsam mit diesen angeordnet sind, und MEC-Hosts, die gemeinsam an vUEs angeordnet sind oder durch diese implementiert werden. Die NANs können die gleichen oder ähnlich wie die NANs 110, 210, 410 und 710 der zuvor besprochenen 1A-6 sein, und die MEC-Hosts können die gleichen oder ähnlich wie die MEC-Hosts 140, 240, 340, 440 und 740 der 1A-6 und/oder der MEC-Host 1502 der 15 oder dergleichen sein. MEC-Hosts, die an vUEs gemeinsam angeordnet sind oder durch diese implementiert werden, werden als „fahrzeuginterne MEC-Hosts“ oder dergleichen bezeichnet.
  • Heutige Personenkraftwagen beinhalten eine diverse eingebettete Rechenumgebung, die für die Handhabung verschiedener Funktionalitäten unterschiedlicher Art verantwortlich ist. Eine solche Umgebung setzt sich aus Verarbeitungseinheiten und Prozessen zusammen, bei denen Informationen mittels spezieller industrieller Nachrichtenbusse ausgetauscht werden, sie ist jedoch eher komplex, kaum rekonfigurierbar und auch stark spezialisiert, um unterschiedliche Funktionen zu versorgen. Um solchen Problemen abzuhelfen, besteht der vorgeschlagene Verwendungsfall in der Verfügbarkeit von fahrzeuginternen MEC-Hosts, die Automobilarbeitslasten unterstützen, die in einem Personenkraftwagen erfahren werden. Solche Arbeitslasten können auf mehrere ähnliche oder diverse Funktionen (z. B. relevant für Sicherheit, Telematik, hochauflösende Karten zur Navigation sowie Video- und andere Infotainmentanwendungen) zugeschnitten sein, die unterschiedliche On-Board-Einheiten (OBUs), zum Beispiel Motorsteuereinheiten (ECUs) eines Personenkraftwagens, beeinflussen. Als ein Beispiel veranschaulicht 8 ein Systemszenario 800, gemäß dem zwei vUEs 801, die unterschiedliche Anwendungen ausführen, mit einem gegebenen Funkknoten 810 (z. B. zelluläre Konnektivität) verbunden sind. Jede Anwendung läuft auf einem MEC-Host 841, der innerhalb des entsprechenden vUE 841 eingebettet ist.
  • 8 zeigt ein beispielhaftes geschichtetes MEC-System 800, das einen Master-MEC-Host 810, der zusammen mit einem NAN 810 (z. B. RAP oder RAN-Knoten) angeordnet ist, und fahrzeuginterne MEC-Hosts 841, die zusammen mit einem jeweiligen vUE 801 unter Abdeckung angeordnet sind, umfasst. Beispielsweise ist der fahrzeuginterne MEC-Host 841-1 gemeinsam mit dem vUE 801-1 angeordnet, der fahrzeuginterne MEC-Host 841-2 gemeinsam mit dem vUE 801-2 angeordnet und der fahrzeuginterne MEC-Host 841-3 gemeinsam mit dem vUE 801-3 angeordnet.
  • Da ein neuerer Trend in der Automobilindustrie darin besteht, die Softwarearchitektur unter Nutzung weniger Verarbeitungseinheiten und unter Einbundung von mehr Betriebssystemen zu entwickeln, kann die MEC-Technologie konstruktiv zu einem solchen Trend beisteuern, da sie eine offene standardisierte Umgebung zum effizienten Integrieren von Anwendungen, die auf einem Personenkraftwagen laufen, bietet. Zusätzlich dazu kann eine MEC-Architektur, die mittels MEC-Hosts realisiert wird, die an Bord von Personenkraftwagen eingesetzt werden, Inhaltsablage- und -speicherfähigkeiten anbieten und das Kontextbewusstsein über Nutzung eines Funknetzes, eines Standorts und/oder beliebiger anderer Informationen, die für die sich ändernde Umgebung während der Fahrtzeit relevant sind, verbessern. Es sei angemerkt, dass die schwankenden Konnektivitätsbedingungen, die ein fahrzeuginterner MEC-Host erfahren kann, zusammen mit seinen möglicherweise begrenzten Verarbeitungs-, Speicher- und Ablagefähigkeiten und Fahrzeugbesitzaspekten seine effiziente Verwaltung beeinflussen können. In dem Beispiel von 8 führen die drei vUEs 801 unterschiedliche Anwendungen aus. Heutige Personenkraftwagen integrieren eine diverse eingebettete Rechenumgebung, die für die Handhabung verschiedener Funktionalitäten unterschiedlicher Art verantwortlich ist. Eine solche Umgebung setzt sich aus Verarbeitungseinheiten und Prozessen zusammen, bei denen Informationen mittels spezieller industrieller Nachrichtenbusse ausgetauscht werden, sie ist jedoch eher komplex, kaum rekonfigurierbar und auch stark spezialisiert, um unterschiedliche Funktionen zu versorgen. Um solchen Problemen abzuhelfen, unterstützen die fahrzeuginternen MEC-Hosts 841 Automobilarbeitslasten, die in V2X-Anwendungen erfahren werden. Solche Arbeitslasten können auf mehrere ähnliche oder diverse Funktionen (z. B. relevant für Sicherheit, Telematik, hochauflösende Karten zur Navigation sowie Video- und andere Infotainmentanwendungen) zugeschnitten sein, die unterschiedliche On-Board-Einheiten (OBUs), zum Beispiel die Motorsteuereinheit (ECU) eines Personenkraftwagens, beeinflussen. Als ein Beispiel veranschaulicht 1 ein Systemszenario, gemäß dem zwei Personenkraftwagen, die unterschiedliche Anwendungen ausführen, mit einem gegebenen Funkknoten (zelluläre Konnektivität) verbunden sind. Jede Anwendung läuft auf einem MEC-Host, der innerhalb des entsprechenden Personenkraftwagens eingebettet ist.
  • Die Funktionalitäten für fahrzeuginterne MEC-Hosts 841 können gehostete MEC-Apps beinhalten, die unterschiedliche Arten von Arbeitslasten ausführen (z. B. maschinelles Lernen (ML), Datenanalytik, Sensormessfusion von Fahrzeugen und der Umgebung, Datenschutzdurchsetzung für Datenströme, die für eine Cloud bestimmt sind (z. B. Gesichtsunschärfe in Videoströmen von fahrzeuginternen Kameras), und/oder dergleichen). Unterschiedliche MEC-Apps können Daten entweder direkt oder auch über die MEC-V2X-API austauschen. Die fahrzeuginternen MEC-Hosts 841 können auch das Offloading von verarbeitungsfordernden Aufgaben von vUEs 801 auf das Netzwerk ermöglichen (z. B. relevant für rechenaufwendige Anwendungen, wie etwa Augmented Reality (AR), Virtual Reality (VR), künstliche Intelligenz (AI) usw.). Die fahrzeuginternen MEC-Hosts 841 können auch ein gemeinsames Anwendungsframework für unabhängigen Einsatz über Dienstanbieter bereitstellen, durch die Annahme interoperierbarer RESTful-APIs, wodurch auch eine kostengünstige und effiziente Anwendungslebensdauer und V2X-Dienstebereitstellung ermöglicht werden.
  • In diesem Beispiel führt der Master-MEC-Host 840 verschiedene erweiterte (z. B. zellen-/abdeckungsbereichsweite) MEC-Dienste über jeweilige MEC-APIs (nachfolgend als „Master-MEC-APIs“, „Master-APIs“ oder dergleichen bezeichnet) aus und/oder stellt diese bereit. Andere Entitäten, wie etwa die vUEs 801, fahrzeuginterne MEC-Hosts 841, fahrzeuginterne MEC-Apps, andere MEC-Hosts 840, Fernanwendungsserver oder dergleichen, verwenden die Master-MEC-APIs, um auf Informationen/Dienste von dem Master-MEC-Host 840 zuzugreifen. Auf die Master-MEC-APIs wird weiter unten näher eingegangen.
  • Zusätzlich führt jedes vUE 841 lokale UE-MEC-Dienste aus und/oder stellt diese bereit, die UE-basierte Versionen der MEC-Dienste sein können, auf die über jeweilige MEC-APIs (nachfolgend als „UE-MEC-APIs“, „UE-APIs“ oder dergleichen bezeichnet) zugegriffen werden kann. Andere Entitäten, wie NAN 810, Master-MEC-Host 840, andere vUEs 801, andere fahrzeuginterne MEC-Hosts 841, MEC-Apps, die von dem fahrzeuginternen MEC-Host 841 gehostet werden, externe MEC-Apps, andere MEC-Hosts 840, Fernanwendungsserver oder dergleichen, verwenden die UE-MEC-APIs, um auf Informationen/Dienste von einem fahrzeuginternen MEC-Host 841 zuzugreifen. Auf die UE-MEC-APIs wird weiter unten näher eingegangen.
  • Die Prozedur zum Zugreifen auf und/oder Bereitstellen von fahrtspezifischen QoS-Vorhersagen für die zweite Ausführungsform ähnelt der Prozedur der ersten Ausführungsform, mit dem Unterschied, dass die Entscheidung, eine Aktion (z. B. Inhaltslieferung, SW-Aktualisierungen usw.) zu starten/verschieben, nicht zentral an dem MEC-Host 840, der zusammen mit dem NAN 810 angeordnet ist, getroffen wird, sondern stattdessen an den jeweiligen fahrzeuginternen MEC-Hosts 841 über eine Analytik-MEC-App, wie etwa eine spezialisierte RNI-Analytik-MEC-App, bestimmt wird. Auf diese Weise kann jedes vUE 801 seine eigene Vernetzungs- und Verarbeitungsleistungsfähigkeit basierend auf fahrtspezifischen Partitionen von zellen/regions/bereichsweiten Messungen, die auf der Netzwerkseite gesammelt werden, steuern.
  • 9 zeigt ein Informationserfassungsframework 900 gemäß der zweiten Ausführungsform. Bei dieser Ausführungsform ist der Master-MEC-Host 940 (entsprechend dem Master-MEC-Host 840 von 8) zusammen mit dem NAN 910 (entsprechend dem NAN 810 von 8) angeordnet. Zusätzlich hostet das vUE 901 (entsprechend einem beliebigen der vUEs 801 von 8) einen fahrzeuginternen MEC-Host 941 (entsprechend einem beliebigen der fahrzeuginternen MEC-Hosts 841 von 8).
  • Der Master-MEC-Host 940 hostet oder implementiert MEC-Apps 9408 (die beliebigen der hier besprochenen MEC-Apps entsprechen) und MEC-Plattformen 9403. Der fahrzeuginterne MEC-Host 941 hostet oder implementiert lokale Instanzen von MEC-Apps 9418 (die beliebigen der hier besprochenen MEC-Apps entsprechen) und MEC-Plattformen 9413. Die MEC-Hosts 940, 941 weisen jeweils ihre eigene Virtualisierungsinfrastruktur 922 und ihre eigenen Datenebeneninstanzen 924 auf. Die MEC-Plattformen 9403, 9413 beinhalten jeweilige Instanzen einer Dienstregistrierungsdatenbank 938, einer Filterungsregelsteuerung 931, einer DNS-Handhabung 932 und verschiedener MEC-APIs.
  • Wie zuvor erwähnt, stellt der Master-MEC-Host 940 verschiedene MEC-Dienste bereit, einschließlich zum Beispiel des VIS, RNIS, BWMS, LS, WIS, FAIS und/oder anderer ähnlicher Dienste. Zugang zu den MEC-Diensten wird durch jeweilige MEC-APIs, wie etwa Standort-API 9400 (die Zugang zu dem LS bereitstellt), Master-RNI-API 9401 (die Zugang zu dem RNIS bereitstellt), Master-V2X-API 9402 (die Zugang zu dem VIS bereitstellt) und andere Master-MEC-APIs 9403 bereitgestellt. Die anderen Master-MEC-APIs 9403 können zum Beispiel die UE_ID-API (die Zugang zu den UE_ID-Diensten bereitstellt), BWM-API (die Zugang zu dem BWMS bereitstellt), WAI-API (die Zugang zu dem WAIS bereitstellt), FAI-API (die Zugang zu dem FAIS bereitstellt) und/oder andere ähnliche APIs beinhalten. Bei manchen Ausführungsformen kann die Master-V2X-API 9402 eine Ressourcen-URI-Struktur, wie in 12 und durch die in Tabelle 7.2-1 oben gezeigten Verfahren dargestellt, aufweisen.
  • Zusätzlich dazu führt der fahrzeuginterne MEC-Host 941 lokale UE-MEC-Dienste aus und/oder stellt diese bereit, die UE-basierte Versionen des/der VIS, RNIS, LS, BWMS, UE_ID-Dienste, WAIS, FAIS und/oder dergleichen sein können, auf die unter Verwendung jeweiliger UE-RNI-APIs, wie etwa der UE-Standort-API 9410, der UE-RNI-API 9411, der UE-V2X-API 9412 und anderer UE-MEC-APIs 9413 zugegriffen werden kann. Die anderen UE-MEC-APIs 9412 können zum Beispiel UE-basierte UE ID-API, BWM-API, WAI-API, FAI-API und/oder dergleichen beinhalten. Die UE-MEC-APIs können dieselben wie die Master-MEC-APIs sein, oder die UE-MEC-APIs können speziell auf fahrzeuginterne MEC-Hosts 941 angepasst/zugeschnitten sein. Bei manchen Ausführungsformen kann die UE-V2X-API 9412 eine Ressourcen-URI-Struktur, wie in 12 und durch die in Tabelle 7.2-1 oben gezeigten Verfahren dargestellt, aufweisen.
  • Bei verschiedenen Ausführungsformen erfasstder Master-MEC-Host 940 unter Verwendung der Master-V2X-API 9402 (oder UE-V2X-API 9412) periodisch UE-Informationen (z. B. RNI, Standort, UE-Identität, V2X-Informationen, usw.) von allen vUEs 901 unter Netzwerkabdeckung des NAN 910, während jeder fahrzeuginterne MEC-Host 941 lokale Informationen erfasst, die über die UE-MEC-APIs (z. B. UE-V2X-API 9412 und/oder Master-V2X-API 9402) an den Master-MEC-Host zurückgemeldet werden sollen. Der Master-MEC-Host 940 verwendet die erfassten Informationen, um die Partitionen zu erzeugen, wie zuvor besprochen, und die fahrzeuginternen MEC-Hosts 941 verarbeiten eine fahrtbezogene Informationspartition, die von dem Master-MEC-Host 940 empfangen wird, mit dem Ziel, eine Entscheidung zu erreichen, eine bestimmte Aktion (z. B. Herunterladen von SOTA/ FOTA-Aktualisierungen, Streaming von Inhalt mit einer bestimmten Datenrate, Puffern von Datendownloads an einem bestimmten Ort/Zeitpunkt und/oder dergleichen) zustarten/verschieben. Diese Entscheidung wird durch eine lokal instanziierte MEC-App 9418 an dem fahrzeuginternen MEC-Host 941 getroffen, wie etwa eine RNI-Analytik-MEC-App 9418 oder dergleichen.
  • Bei Schritt 4b der fahrtbewussten vUE-QoS-Vorhersageprozedur instanziiert zum Beispiel der fahrzeuginterne MEC-Host 941 bei einer oder mehreren Inhaltslieferungsanforderungen (z. B. SOTA/FOTA-Aktualisierungen) eine RNI-Analytik-MEC-App 9418, die fahrtspezifische Teile der durch den Master-MEC-Host 940 verteilten erfassten zusammengesetzten UE-Kontextinformationen aufnimmt. Die RNI-Analytik-MEC-App 9418 plant Inhaltslieferungsanforderungen und/oder empfiehlt die Aktivierung/Deaktivierung von bestimmten V2X-Anwendungsmerkmalen (z. B. Autonomfahrmerkmalen usw.) in Abhängigkeit von der erhaltenen fahrtspezifischen Partition der zusammengesetzten RNI-Informationen. Diese Ausführungsformen können nützlich sein, wenn sich ein vUE 901 aus der Netzwerk (z. B. zellulären) -Abdeckung bewegt, da die erfassten RNI, die sich auf solche geografischen Bereiche beziehen (möglicherweise durch fähigere UEs), bereits im Voraus bekannt sein werden. Daher wird das vUE 901 in der Lage sein, seinen Betrieb (z. B. Verschieben oder Reduzieren der Downloadraten, um sich an ungünstige Funkbedingungen anzupassen) selbst ohne Netzwerk- (z. B. zelluläre) Abdeckung durch einen oder mehrere NANs 910 anzupassen.
  • Beispielhafte Datenstrukturen. Die Daten-/Informationsstrukturen können die gleichen oder ähnlich wie in der ersten Ausführungsform beschrieben sein, wobei ein Unterschied in der Nachricht besteht, die durch den NAN 910 in Schritt 4b der fahrtbewussten vUE-QoS-Vorhersageprozedur übertragen wird. Bei dieser Ausführungsform wird, da die Entscheidung an dem fahrzeuginternen MEC-Host 941 getroffen werden soll, ein fahrtspezifischer Satz von Messungen (z. B. Informationspartition) von dem NAN 910 unter Verwendung von Unicastübertragung ausschließlich an ein vUE 901 oder mittels Multicastübertragung an einen Cluster von vUEs 801/801 übertragen. Ein Beispiel für eine solche Datenstruktur ist in Tabelle 4 gezeigt. Tabelle 4
    Routenpunkt Messzeitstempel Messort Messwert
    1 TS_1 Loc_1 Meas_1
    2 TS_2 LOC_2 Meas_2
    ... ... ... ...
    S TS_S Loc_S Meas_S
  • Die Datenstruktur aus Tabelle 4 stellt jeweils einen Messzeitstempel, einen Messort und einen Messwert für jeweilige Routenpunkte 1 bis S bereit, wobei S eine Zahl ist. In dem Beispiel von Tabelle 4 verweist „TS“ auf einen speziellen Zeitstempelwert, „Loc“ auf einen speziellen Standortwert und „Meas“ auf einen speziellen Funkmesswert. Der Zeitstempel bezieht sich auf eine Zeit, zu der eine Messung vorgenommen wird, wie durch das vUE 801/801 in Bezug auf eine Referenzzeit bestimmt wird, die auf einer geeigneten internen oder externen Uhr basieren kann, die die Referenzzeit bereitstellt. Der Zeitstempel kann eine Universal-Uhr-Anzeige und/oder der TimeStamp-Datentyp sein, bereitgestellt durch den MEC-LS über die Standort-API 9400, 9410. Der Messort ist ein Ort (z. B. geografischer Standort, Zellenort oder dergleichen), an dem die Messung vorgenommen wurde, und kann unter Verwendung einer beliebigen geeigneten Standort-/Geostandortangabe ausgedrückt werden, wie etwa des Locationlnfo-Datentyps, bereitgestellt durch den MEC-LS über die Standort-API 9400, 9410 (z. B. GPS/GNSS-Koordinaten basierend auf dem World Geodetic System 1984 (WGS 84) und/oder 3GPP-basierte Standortdienste (siehe z. B. [R10] und ETSI TS 123 032 V15.1.0 (2018-09)). Zusätzlich oder alternativ können WLAN-Standortdienste für den Messort verwendet werden. Zum Beispiel können die koordinatenbasierten geografischen Standorte des vUE 901 auf Dynamic Host Configuration Protocol (z. B. DHCPv4 und DHCPv6) verwendet werden, die Standortkonfigurationsinformationen (LCI: Location Configuration Information) beinhalten, und die LCI beinhalten Breiten-, Längen- und Höhendaten/-koordinaten mit Auflösungs- oder Unsicherheitsindikatoren für jedes Datenelement/jede Koordinate (siehe z. B. IETF RFC 6225 (2011-07)). Die Messwerte können beliebige der oben genannten Messtypen davon (z. B. RSRP, RSRQ usw.) oder Kombinationen sein. Bei manchen Ausführungsformen können die Messwerte durch einen beliebigen der in [R09] besprochenen UE-Messberichte bereitgestellt werden, zum Beispiel durch Schicht-2-Messinformationen (L2Meas), 5G-UE-Messbericht (NrMeasRepUeSubscription) und/oder dergleichen. Zusätzlich oder alternativ dazu kann die Datenstruktur der Tabelle 4 die RNIS-Messberichte sein oder diese beinhalten, die durch den RNIS bereitgestellt werden, darunter Zeitstempel- und Zell-ID-Informationen. Zusätzlich oder alternativ dazu können die durch den RNIS bereitgestellten Messberichte zusätzliche oder ergänzende Standortinformationen beinhalten, die durch den MEC-LS bereitgestellt werden, um einen präziseren (geografischen) Standort der vUEs 901 bereitzustellen.
  • 10 zeigt einen beispielhaften Prozess 1000 gemäß der zweiten Ausführungsform. Die Prozedur von 10 ist ein einziger Entscheidungszyklus, der durch einen MEC-Host 940, der zusammen mit einem NAN 910 und/oder einem oder mehreren vUEs 901 mit fahrzeuginternen MEC-Hosts 941 innerhalb des Abdeckungsbereichs des NAN 910 angeordnet ist, durchgeführt werden kann. Der Prozess 900 wird gemäß Beschreibung verwendet, um eine Entscheidung darüber zu treffen, ob SW- und/oder FW-Aktualisierungen heruntergeladen werden sollen, jedoch kann der Prozess 1000 verwendet werden, um Entscheidungen über andere Arten von Datentransferverwendungsfällen, wie etwa die hier besprochenen, zu treffen.
  • Die Prozedur 1000 beginnt bei Operation 1001, bei der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) eine Meldung des aktuellen und/oder aktualisierten Fahrtplans des vUE 901 zusammen mit der Version seines laufenden SW/FW empfängt. (Bei Durchführung durch einen fahrzeuginternen MEC-Host 941 kann das vUE 901, dessen Route analysiert wird, das vUE 901 sein, in dem der fahrzeuginterne MEC-Host 901 angeordnet ist, oder ein anderes vUE 901, das einen anderen fahrzeuginternen MEC-Host 941 implementiert; in letzterem Fall wird angenommen, dass V2V-Kommunikation durchführbar ist (z. B. Sidelink-/Kurzstreckenkommunikation). Bei Operation 1002 bestimmt der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941), ob eine neue SW/FW-Paketversion für das vUE 901 verfügbar ist. Falls keine neue SW/FW-Paketversion für das vUE 901 verfügbar ist, liefert das vUE 901 bei Operation 1003 periodisch lokal erfahrene Funkqualitätsinformationen an den MEC-Host 940 mit einer niedrigen Abtast-/Nachrichtenübermittlungsrate. Bei Ausführungsformen meldet das vUE 901 seine Funkmessungen mit einer niedrigen Abtast-/Nachrichtenübermittlungsrate (z. B. L < K Zyklen, wobei K und L Zahlen sind). Bei Operation 1004 partitioniert der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) die erfassten Mehrfahrzeuginformationen gemäß Kontext (z. B. Relevanz für die geplanten Routen der abgedeckten vUEs 901) erneut, und bei Operation 1005 überträgt der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) jede Informationspartition über Unicast-/Multicastübertragungen (und/oder Sideline-/PC5-Übertragung(en) bei Durchführung durch den fahrzeuginternen MEC-Host 941) an das/die relevantesten vUE(s) 901. Hier können das oder die relevantesten vUE(s) 901 auf den Kontextinformationen (z. B. Relevanz für die geplanten Routen der vUEs 901) basieren. Zusätzlich dazu verarbeitet bei oder nach Operation 1005 jedes vUE 901, das eine SW/FW-Aktualisierung benötigt, die empfangene Informationspartition an einem jeweiligen fahrzeuginternen MEC-Host 941. Bei Ausführungsformen entscheidet eine RNI-Analytik-MEC-App 9418 über die Startzeit, den Ort und/oder das Verschieben (falls notwendig) des Downloads. Nach Durchführung der Operation 1005 endet die Prozedur 1000.
  • Unter erneuter Bezugnahme auf Operation 1002 empfängt, wenn der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) bestimmt, dass eine neue SW/FW-Paketversion für das vUE 901 verfügbar ist, der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) bei Operation 1006 periodisch Funkmessungen mit einer hohen Abtast-/Nachrichtenübermittlungsrate. Bei Ausführungsformen liefert das vUE 901 periodisch Informationen über lokal erfahrene Funkqualität an den Master-MEC-Host 940 (oder fahrzeuginternen MEC-Host 941) mit der hohen Abtast-/Nachrichtenübermittlungsrate (z. B. K Zyklen, wobei K eine Zahl ist). Mit anderen Worten, wenn die gegenwärtig installierte Version des SW/FW-Pakets die aktuellste und/oder neueste Version ist, werden Messungen mit einer niedrigen Rate bereitgestellt (siehe z. B. Operation 1003); umgekehrt, wenn die gegenwärtig installierte Version des SW/FW-Pakets nicht die aktuellste und/oder neueste Version ist (wird z. B. eine SW/FW-Paketaktualisierung benötigt oder gewünscht), werden Messungen mit einer höheren Rate bereitgestellt (siehe z. B. Operation 1006). Bei Operation 1007 partitioniert der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) die erfassten Mehrfahrzeuginformationen gemäß Kontext (z. B. Relevanz für die geplanten Routen der Fahrzeuge unter Abdeckung) erneut, und bei Operation 1008 empfängt der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) die geplante Fahrt des vUE 901 nach der Informationsneupartitionierung. Bei Ausführungsformen meldet das vUE 901 seine geplante Fahrt nach der Informationsneupartitionierung an dem Master-MEC-Host 940 (oder fahrzeuginternen MEC-Host 941).
  • Bei Operation 1009 bestimmt der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941), ob die geplante Route des vUE 901 immer noch gültig ist, basierend auf den aktualisierten Fahrtinformationen, die bei Operation 1008 erhalten werden. Falls die geplante Route des vUE 901 nicht mehr gültig ist, geht der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) zu Operation 1010 über, bei der der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) die am meisten geeignete Partition (z. B. die am höchsten kontextuell korrelierte Partition) mit dem betreffenden vUE 901 (z. B. dem vUE 901, dessen Route analysiert/verarbeitet wird) verknüpft oder assoziiert. Bei manchen Ausführungsformen führt der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941), nachdem der aktualisierte Fahrtplan durch das vUE 901 kommuniziert wurde, keine weitere Informationspartition durch; stattdessen führt der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) die Operation 1010 durch.
  • Unter erneuter Bezugnahme auf Operation 1009 geht, wenn der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) bestimmt, dass die geplante Route des betreffenden vUE 901 noch gültig ist, der Master-MEC-Host 940 (oder fahrzeuginterne MEC-Host 941) direkt zu Operation 1011 über, um die fahrtspezifische Informationspartition über eine Unicast- oder Multicastübertragung an das betreffende vUE 901 zu übertragen. Nach Operation 1009 oder 1010 überträgt der Master-MEC-Host 940 bei Operation 1011 die fahrtspezifische Informationspartition über eine Unicast- oder Multicastübertragung (und/oder Sidelink-/PC5-Übertragung(en) bei Durchführung durch den fahrzeuginternen MEC-Host 941) an das betreffende vUE 901. Zusätzlich führt das vUE 901 (oder eine RNI-Analytik-MEC-App 9418, die an dem fahrzeuginternen MEC-Host 941 instanziiert ist) bei oder nach Operation 1011 fahrtspezifische QoS-Vorhersagen durch und stellt Empfehlungen basierend auf den fahrtspezifischen QoS-Vorhersagen bereit. Hier entscheidet das vUE 901 (oder eine RNI-Analytik-MEC-App 9418, die an dem fahrzeuginternen MEC-Host 941 instanziiert ist) über die Startzeit, den Ort und/oder die Verschiebung (falls notwendig) des Downloads oder anderen Datentransfers. Nach Durchführung der Operation 1011 endet die Prozedur 1000.
  • II.D. MEC-VIS-GEPLANTE ROUTENBEWUSSTE QOS-BENACHRICHTIGUNGEN
  • Bei den oben besprochenen Ausführungsformen wird die Nutzbarkeit der MEC-VIS-API im Hinblick auf das Erhalten fahrtbewusster QoS-Vorhersagen hervorgehoben. Diese Vorhersagen werden von MEC-Apps verwendet, die vor der Passierzeit eines vUE über Funkbedingungen „en route“ informiert werden müssen, bevor eine Entscheidung darüber erreicht wird, ob Daten in einer oder beiden der DL- oder UL-Richtungen übertragen werden sollen (z. B. Aktivieren/Deaktivieren von Autonomfahrmerkmalen, Herunterladen von Infotainmentinhalt, Planung von SOTA/FOTA-Aktualisierungen usw.). Eine Herausforderung für den MEC-VIS (z. B. VIS 280 von 2) besteht darin, Raum/Zeit-Korrelationen zwischen Funkdaten (RNI), die durch verschiedene vUEs in einem V2X (z. B. C-V2X) -System gesammelt werden, und einer geplanten Fahrt/Route eines spezifischen vUE zur besseren Vorhersage der Qualität des Kommunikationsnetzes (z. B. Funkbedingungen, QoS usw.) entlang der designierten Route zu identifizieren. Um rechtzeitige und genaue QoS-Vorhersagen entlang einer geplanten vUE-Route zu erhalten, muss die VIS-API möglicherweise Informationen sammeln und verarbeiten, die durch andere MEC-APIs verfügbar sind (siehe z. B. 2, 3 und 8). Infolgedessen werden neue VIS-API-Ressourcenelemente benötigt, um Informationen zu sammeln und zu verarbeiten, die durch andere MEC-API verfügbar sind, von denen jede für einen Verwendungsfall/Satz von V2X-Verwendungsfällen nützlich sein kann.
  • Derzeit wurden keine Lösungen vorgeschlagen, um die Raum-Zeit-Korrelationen zwischen RNI, die durch vUEs unter Netzwerk- (z. B. zellulärer) Abdeckung kommuniziert werden, und den geplanten Routen dieser vUEs (oder anderer vUEs unter Netzwerkabdeckung) auszunutzen, damit das System fahrtspezifische QoS-Nachrichten erzeugt. Darüber hinaus wurden bei keinen Lösungen Prozesse/Prozeduren und/oder Datentypen vorgeschlagen, um diese Aufgaben zu erfüllen.
  • Die vorliegenden Ausführungsformen betonen die Rolle des VIS bei der Erstellung von fahrtspezifischen QoS-Benachrichtigungen. Um eine solche Aufgabe zu erfüllen, stellen vorliegende Ausführungsformen Prozeduren und/oder Prozesse (z. B. Sequenzdiagramme) und einen Datentyp bereit, der die geplante Fahrt eines vUE widerspiegelt. Die vorliegenden Ausführungsformen stellen ein Framework zur kooperativen Erfassung, Partitionierung und Verteilung von Informationen zur fahrtspezifischen QoS-Vorhersage in MEC-Implementierungen bereit. Gemäß verschiedenen Ausführungsformen sendet ein VIS-Konsument (z. B. eine MEC-App oder eine MEC-Plattform) eine Anforderung an den VIS, geplante Routeninformationen eines bestimmten vUE zu empfangen. Ein oder mehrere Datentypen, die die Informationen der geplanten Route (z. B. Standortinformationen) eines vUE repräsentieren, werden auch bereitgestellt. Diese Informationen liegen pro UE vor (z. B. zugeschnitten auf eine spezifische UE-Identität). Attribute des Datentyps beziehen sich auf interessierende Zeiten und Standorte für ein gegebenes Fahrzeug-UE. Die hier erörterten Prozeduren/Prozesse und Datentypen können in den ETSI-MEC-V2X-Dienst(VIS)-Spezifikationen enthalten sein. Die Ausführungsformen können auch Teil von Dienstsubskriptionen/-benachrichtigungen und dem Ressourcenbaum der MEC-VIS-API sein. Die vorliegenden Ausführungsformen stellen Energieeffizienz in V2X-Kommunikationen bereit, indem sie eine Kommunikations-/Signalisierungsressourcenbewahrung durch Ressourcenzuweisung über große Bereiche/Regionen sowie bessere QoE (Quality of Experience) für V2X-Benutzer ermöglichen.
  • Die oben diskutierten Ausführungsformen 1 und 2 konzentrieren sich auf die Rolle des VIS bei der Erstellung von fahrtspezifischen QoS-Vorhersagen. Die MEC-VIS-Benachrichtigung-Ausführungsformen können in den Ausführungsformen 1 und 2 verwendet werden, um andere relevante Informationen für die fahrtspezifischen QoS-Vorhersagen und Aufgabenentscheidungen auszutauschen. Die MEC-VIS-Benachrichtigung-Ausführungsformen beinhalten beispielhafte Prozeduren/Prozesse, gemäß denen ein Dienstkonsument (z. B., MEC-Anwendungen 1526 und/oder MEC-Plattform 1532 von 15) eine Anforderung für Informationen einer geplanten Route eines bestimmten vUE sendet, und beispielhafte Datentyp(en), die Informationen einer geplanten Route (Standortinformationen) des vUE repräsentieren. Diese Informationen liegen pro vUE vor (z. B. zugeschnitten auf eine spezifische UE-Identität). Attribute des oder der Datentypen beziehen sich auf interessierende Zeiten und Standorte für ein gegebenes vUE. 11 veranschaulicht beispielhafte V2X/VIS-API-Prozeduren 1101, 1102 und 1103 gemäß verschiedenen Ausführungsformen. In den Prozeduren von 11 sendet ein Dienstkonsument (z. B. ein VIS-Konsument, wie etwa eine MEC-App oder eine MEC-Plattform) eine Anforderung für Informationen eines bestimmten vUE (z. B. vUEs 101, 201, 401, 701, 801, 901, die zuvor besprochen wurden). Als Reaktion auf die Anforderung erzeugt ein Dienstanbieter, der ein VIS ist (z. B. VIS 280 aus 2, VIS, der durch die V2X-APIs 9402 und 9412 aus 9 bereitgestellt wird, und dergleichen), eine Antwort, die angeforderten Informationen beinhaltet, und sendet die Antwort an den Dienstkonsument. Der Dienstkonsument erhält die Antwort mit der angeforderten Information von dem VIS.
  • 11 beinhaltet eine erste Prozedur 1101, die eine Prozedur ist, bei der der Dienstkonsument die Informationen der geplanten Route eines bestimmten vUE anfordert. Prozedur 1101 beginnt bei Operation 1101-1, bei der Dienstkonsument (oder VIS-Konsument) eine Anforderungsnachricht an den VIS sendet, der der Diensterzeuger (oder „VIS-Erzeuger“) ist. Bei dieser Ausführungsform ist der VIS eine Ressource, die die Informationen der geplanten Route repräsentiert, und der VIS-Konsument verwendet das GET-Verfahren, um die Ressource der Informationen der geplanten Route zu erhalten (z. B. zu lesen). Bei Ausführungsformen enthält die Anforderung UE-Identitätsinformationen des vUE als einen Eingabeparameter. Die Anforderungsnachricht kann eine HTTP-GET-Nachricht mit der Anforderungszeile „GET ../planned_route_info?ue_id“ sein, wobei es sich bei dem Parameter „ue id“ um die UE-Identitätsinformationen handelt. Der Ressourcen-URI ist hier „{apiRoot}/vis/v1/planned_route_info?ue_id“. Bei manchen Ausführungsformen kann die Anforderung eine Dienstkonsumenteninstanz-ID als einen Eingabeparameter beinhalten, der in einem Nachrichtenrumpf der Anforderungsnachricht enthalten sein kann.
  • Bei Operation 1101-2 antwortet der Dienstersteller (z. B. der VIS) mit einer Antwort/Antwortnachricht, die einen Nachrichtenrumpf beinhaltet, der die Informationen der geplanten Route enthält. Bei dieser Ausführungsform ist die Antwortnachricht eine HTTP-Antwortnachricht, die den Statuscode „200 OK“ in dem Header der HTTP-Nachricht beinhaltet, der angibt, dass die Anforderung des Dienstkonsumenten erfolgreich war. Zusätzlich dazu ist die angeforderte Datenstruktur der Informationen der geplanten Route (PlannedRoutelnfo) in dem Rumpf der HTTP-Antwortnachricht enthalten. Bei manchen Ausführungsformen kann die Antwortnachricht ein PlannedRoutelnfo-IE, -Feld, - Datenfeld, -Datenelement oder dergleichen beinhalten, um die PlannedRoutelnfo-Datenstruktur zu beinhalten. Bei dieser Ausführungsform wird das GET-Verfahren verwendet, um die Informationen der geplanten Route anzufordern, die den potenziellen Routen des vUE entsprechen, dessen ID in der Anforderung bereitgestellt ist. Dieses Verfahren unterstützt die in den Tabellen 5 und 6 spezifizierten URI-Abfrageparameter, Anforderungs- und Antwortdatenstrukturen und Antwortcodes. Tabelle 5: URI-Abfrageparameter, unterstützt durch das GET-Verfahren auf PlannedRoutelnfo-Ressource
    Bezeic nung Daten typ Kardinalit ät Anmerkungen
    ue_id Zeich enkett e 1 Kommagetrennte Liste von Standorten zum Identifizieren einer Zelle einer Basisstation oder eines bestimmten geografischen Bereichs, formatiert wie folgt für die zwei Fälle.
    .../planned_route_info?ue_id,{String}
    Wobei die Zeichenkette aus 1 bis N kommagetrennten ue_id-Werten besteht, wobei jeder Wert einem bestimmten Fahrzeug-UE entspricht.
    Tabelle 6: Datenstrukturen, unterstützt durch die PlannedRoutelnfo-GET-Ressourcen
    Datentyp Kardinalit ät Antwortcodes Anmerkungen
    PlannedRoutelnfo 1 200 OK Bei Erfolg wird ein Antwortkörper, der die Informationen der geplanten Route enthält, die potenziellen Routen eines vUE entsprechen, zurückgegeben.
    ProblemDetails 0..1 400 Bad Request Verwendet, um anzuzeigen, dass falsche Parameter an die Anforderung übergeben wurden. In der zurückgegebenen ProblemDetails-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    ProblemDetails 0..1 401 Unauthorized Verwendet, wenn der Client keine Berechtigungsnachweise übermittelt hat. In der zurückgegebenen ProblemDetails-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    ProblemDetails 1 403 Forbidden Gibt an, dass die Operation bei dem aktuellen Status der Ressource nicht zulässig ist. In dem Attribut „detail“ der „ProblemDetails“-Struktur sollen mehr Informationen bereitgestellt werden.
    ProblemDetails 0..1 404 Not Found Verwendet, wenn ein Client einen URI bereitgestellt hat, der nicht auf einen gültigen Ressourcen-URI abgebildet werden kann. In der zurückgegebenen ProblemDetails-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
  • PlannedRouteInfo ist ein Ressourcendatentyp. Der PlannedRouteInfo-Typ repräsentiert die Informationen der geplanten Route (Standortinformation) eines vUE. Diese Informationen liegen pro UE vor (z. B. zugeschnitten auf eine spezifische UE-Identität). Die Attribute des PlannedRouteInfo können den in Tabelle 7 bereitgestellten Angaben folgen. Tabelle 7: Attribute von PlannedRoutelnfo
    Attributbezeichnung Datentyp Kardinalität Beschreibung
    origin LocationInfo 1 Ausgangspunkt der Route.
    destination LocationInfo 1 Routenziel.
    intermediateLocations Structure (inlined) 0..N Satz von Zwischenstandorten, die durch das Fahrzeug-UE besucht werden sollen.
    >intermediateLocation LocationInfo 1 Ein Zwischenstandort aus dem Satz von Zwischenstandorten, der durch das Fahrzeug-UE besucht werden soll.
    timeJourneyStart TimeStamp 0..1 Zeit des Fahrtbeginns.
    timeJourneyEnd TimeStamp 0..1 Erwartete Zeit des Fahrtendes.
  • 11 beinhaltet auch eine zweite Prozedur 1102, bei der der Dienstkonsument die Informationen der geplanten Route eines speziellen vUE anfordert. Die Prozedur 1102 ist ein Szenario, bei dem der Dienstkonsument (z. B. eine V2X-Anwendung, MEC-App usw.) eine Anforderung an den VIS sendet, vorhergesagte QoS zu empfangen, die potenziellen Routen eines vUE entspricht, und eine Antwort empfängt, die die erforderlichen/angeforderten Informationen (z. B. die vorhergesagten QoS-Informationen) enthält.
  • Prozedur 1102 beginnt bei Operation 1102-1, bei der der Dienstkonsument (z. B. VIS-Konsument) eine Anforderungsnachricht an den VIS sendet, der der Diensterzeuger (oder „VIS-Erzeuger“) ist. Bei dieser Ausführungsform ist das VIS eine Ressource, die die Informationen der geplanten Route und/oder vorhergesagte QoS für das relevante vUE repräsentiert. Der (Anforderungs-)Nachrichtenrumpf enthält die Datenstruktur für die vorhergesagte QoS, die für potenzielle Routen des Fahrzeug-UE relevant ist (nachfolgend erörtert). Bei der Anforderungsnachricht kann es sich um eine HTTP-POST-Nachricht mit der Anforderungszeile „POST ../provide_predicted_qos“ handeln. Der Ressourcen-URI ist hier „{apiRoot}/vis/v1/provide_predicted_qos“. Bei manchen Ausführungsformen kann die Anforderung auch eine Dienstkonsumenteninstanz-ID als einen Eingabeparameter beinhalten, der in einem Nachrichtenrumpf der Anforderungsnachricht enthalten sein kann.
  • Bei Operation 110"-2 antwortet der Dienstersteller (z. B. der VIS) mit einer Antwort/Antwortnachricht, die einen Nachrichtenrumpf beinhaltet, der die vorhergesagte QoS-Informationsdatenstruktur (PredictedQoS) enthält. Bei dieser Ausführungsform ist die Antwortnachricht eine HTTP-Antwortnachricht, die den Statuscode „200 OK“ in dem Header der HTTP-Nachricht beinhaltet, der angibt, dass die Anforderung des Dienstkonsumenten erfolgreich war. Zusätzlich dazu ist der angeforderte PredictedQoS in dem Rumpf der HTTP-Antwortnachricht enthalten. Bei manchen Ausführungsformen kann die Antwortnachricht ein PredictedQoS-IE, -Feld, -Datenfeld, -Datenelement oder dergleichen beinhalten, um die PredictedQoS-Datenstruktur zu beinhalten.
  • Bei dieser Ausführungsform wird das POST-verfahren verwendet, um die vorhergesagte QoS anzufordern, die potenziellen Routen eines vUE entspricht. Dieses Verfahren unterstützt die in Tabelle 8 spezifizierten URI-Abfrageparameter, Anforderungs- und Antwortdatenstrukturen und Antwortcodes. Tabelle 8: Datenstrukturen, unterstützt durch die PredictedQoS-POST-Anforderuno/Antwort
    Anforder ungsrum pf Datentyp Kardinalität Anmerkungen
    PredictedQos 1 Ein Entitätsrumpf in der Anforderung enthält die vorhergesagte QoS wie vom VIS-Konsument angefordert.
    Antwortr umpf Datentyp Kardinalität Antwortcod es Anmerkungen
    PredictedQos 1 200 OK Der Antwortkörper enthält die vorhergesagte QoS, die potenziellen Routen eines Fahrzeug-UE entspricht.
    Problem Details 0..1 400 Bad Request Verwendet, um anzuzeigen, dass falsche Parameter an die Anforderung übergeben wurden. In der zurückgegebenen Problem Details-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    Problem Details 0..1 401 Unauthorize d Verwendet, wenn der Client keine Berechtigungsnachweise übermittelt hat. In der zurückgegebenen Problem Details-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    Problem Details 1 403 Forbidden Gibt an, dass die Operation bei dem aktuellen Status der Ressource nicht zulässig ist. In dem Attribut „detail“ der „ProblemDetails“-Struktur sollen mehr Informationen bereitgestellt werden.
    Problem Details 0..1 404 Not Found Verwendet, wenn ein Client einen URI bereitgestellt hat, der nicht auf einen gültigen Ressourcen-URI abgebildet werden kann. In der zurückgegebenen Problem Details-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
  • PredictedQos ist ein Ressourcendatentyp. Der PredictedQos-Typ repräsentiert die vorhergesagte QoS eines Fahrzeug-UE. Diese Informationen liegen pro potenzieller UE-Route vor. Die Attribute des PredictedQos können den in Tabelle 9 bereitgestellten Angaben folgen. Tabelle 9: Attribute des PredictedQos
    Bezeichnung Datentyp Kardinalität Anmerkungen
    timeGranularity TimeStamp 0..1 Zeitgranularität des Besuchens eines Orts.
    locationGranularity Zeichen kette 1 Granularität eines besuchten Orts. Gemessen in Metern.
    routes Structure (inlined) 1..N Informationen bezüglich der potenziellen Route eines Fahrzeug-UE.
    >routeInfo Structure (inlined) 2..N Informationen bezüglich einer bestimmte Route. Die erste Struktur bezieht sich auf den Routenausgangspunkt und die letzte auf das Routenziel. Es können auch Wegpunkt-Zwischenstandorte bereitgestellt werden.
    >>location LocationInfo 1 Standort eines Fahrzeug-UE.
    >>time TimeStamp 0..1 Geschätzte Zeit am Standort.
    >>rsrp Uint8 0..1 RSRP wie in [R15], [R16] definiert; nur in der Antwort enthalten.
    >>rsrq Uint8 0..1 RSRQ wie in [R15], [R16] definiert; nur in der Antwort enthalten.
    HINWEIS: Der Datentyp locationGranularity ist eine Zeichenkette, die die Granularität eines besuchten Orts mittels Breiten- und Längenspannen angibt.
    HINWEIS: Der Datentyp von Uint8 ist eine vorzeichenlose ganze Zahl von 8 Bit.
  • In dem Beispiel von Tabelle 9 sind die rsrp- und rsrq-Attribute nur in der Antwortnachricht enthalten.Attribute Bei anderen Ausführungsformen könnten die rsrp- und rsrq-Attribute auch in der Anforderungsnachricht enthalten sein, und die RSRP- und RSRQ-Werte, die darin enthalten sind, könnten für fahrtspezifische QoS-Vorhersagen verwendet werden. Zum Beispiel könnten diese RSRP- und RSRQ-Werte als die Funkinformationen verwendet werden, die in Schritt 2 der in Abschnitt II.A oben besprochenen fahrtspezifischen QoS-Vorhersageprozedur gemeldet werden. In diesem Beispiel werden die RSRP- und/oder RSRQ-Werte mit dem LocationInfo und dem TimeStamp in den Standort- und Zeitdatenelementen „markiert“. Wie zuvor erwähnt, könnten bei anderen Ausführungsformen zusätzlich oder alternativ andere Arten von Messungen in den Anforderungs- oder Antwortnachrichten enthalten sein.
  • Bei manchen Ausführungsformen kann das Zeitattribut enthalten sein, um eine tatsächliche Zeit des Besuchens eines bestimmten Orts, der durch den LocationInfo angegeben wird, oder eine vorhergesagte Zeit, zu der erwartet wird, dass das vUE den bestimmten Ort besucht, anzugeben. Zum Beispiel kann die erste routelnfo-Struktur in Bezug auf den Routenausgangspunkt eine tatsächliche Zeit beinhalten, zu der sich das vUE an dem Routenausgangspunkt befand, und die letzte routelnfo-Struktur in Bezug auf den Routenzielpunkt kann eine vorhergesagte oder erwartete Zeit sein, zu der das vUE an dem Zielpunkt ankommen soll. Zwischen-routelnfo-Strukturen, die Wegpunktstandorten entsprechen, können tatsächliche Zeiten, zu denen das vUE diese Wegpunktstandorte besucht, vorhergesagte/erwartete Zeiten des Ankommens an den Wegpunktstandorten oder eine Kombination davon beinhalten.
  • 11 beinhaltet auch eine beispielhafte Prozedur 1103 zum Anfordern von PC5-Bereitstellungsinformationen gemäß verschiedenen Ausführungsformen. Bei Prozedur 1103 sendet der Dienstkonsument (oder ein VIS-Konsument) (z. B. eine MEC-Anwendung oder eine MEC-Plattform) eine Anforderung zum Empfangen von Bereitstellungsinformationen für V2X-Kommunikation über die PC5-Schnittstelle für einen bestimmten Standort, und die Antwort enthält die erforderlichen Informationen.
  • Die Prozedur 1103 beginnt bei Operation 1103-1, bei der der Dienstkonsument (oder VIS-Konsument) eine Anforderungsnachricht an einen Diensterzeuger (oder VIS-Erzeuger) sendet. Das VIS ist eine Ressource, die PC5-Bereitstellungsinformationen repräsentiert. Bei Ausführungsformen sind die Standortinformationen (z. B. die Dienstzellen-ID oder die geografischen Bereichsinformationen des UE) ein Eingabeparameter. In diesem Beispiel kann die Anforderungsnachricht eine HTTP-GET-Nachricht mit der Anforderungszeile „GET .../pro_info_PC5?location_info“ sein, wobei es sich bei dem Parameter „Location _info“ um die Standortinformationen handelt. Hier ist der Ressourcen-URI „{apiRoot }/vis/v1/queries/pc5_rovisioning_info“. Bei manchen Ausführungsformen kann die Anforderung eine Dienstkonsumenteninstanz-ID als einen Eingabeparameter beinhalten, der in einem Nachrichtenrumpf der Anforderungsnachricht enthalten sein kann.
  • Bei Operation 1103-2 antwortet der Diensterzeuger (z. B. der VIS) mit einer Antwort/Antwortnachricht, die den Nachrichtenrumpf beinhaltet, der die PC5-Bereitstellungsinformationen enthält. Bei einer Ausführungsform ist die Antwortnachricht eine HTTP-Antwortnachricht, die den Statuscode „200 OK“ in dem Header der HTTP-Nachricht beinhaltet, der angibt, dass die Anforderung des Dienstkonsumenten erfolgreich war. Zusätzlich dazu sind die angeforderten Informationen der geplanten Route ( „PC5ProvisioningInfo“) in dem Rumpf der HTTP-Antwortnachricht zum Beispiel in einem PC5Provisioninglnfo-IE, -Feld, -Datenelement oder einer anderen ähnlichen Datenstruktur enthalten.
  • Bei dieser Ausführungsform wird das GET-Verfahren verwendet, um Bereitstellungsinformationen für V2X-Kommunikation über PC5 anzufordern. Dieses Verfahren unterstützt die in den Tabellen 10 und 11 spezifizierten URI-Abfrageparameter, Anforderungs- und Antwortdatenstrukturen und Antwortcodes, wie . Tabelle 10: URI-Abfrageparameter, unterstützt durch das PC5Provisioninglnfo-GET-Verfahren
    Bezeichnung Datentyp Kardinalität Anmerkungen
    location_info Zeichenkett e 1 Kommagetrennte Liste von Standorten zum Identifizieren einer Zelle einer Basisstation oder eines bestimmten geografischen Bereichs, formatiert wie folgt für die zwei Fälle.
    .../pc5_provisioning_info?location_info=ecgi,{String }
    Wobei die Zeichenkette aus 1 bis N kommagetrennten ecgi-Werten besteht.
    .../pc5_provisioning_info?location_info=latitude,{Str ing},longitude,{String}
    Wobei die beiden Zeichenketten aus 1 bis N kommagetrennten Breiten- bzw. Längengradwerten bestehen (Referenzabschnitt 6.5.3), sodass die Anzahl der Breiten- und Längengradwerte gleich ist.
    Beispiele für Abfrageformate bei N=2 Standorten sind im Folgenden gegeben:
    .../pc5_provisioning_info?location_info=ecgi, 13579 24680,1357924681
    .../pc5_provisioning_info?location_info=latitude,000 .000,001.000,longitude,000.000,001.000
    Tabelle 11: Datenstrukturen, unterstützt durch die PC5Provisioninglnfo-GET-Antwort
    Datentyp Kardinalität Antwortcodes Anmerkungen
    Pc5ProvisioningInfo 1 200 OK Bei Erfolg wird ein Antwortkörper, der diePC5-Bereitstellungsinformationen enthält, zurückgegeben.
    Problem Details 0..1 400 Bad Request Verwendet, um anzuzeigen, dass falsche Parameter an die Anforderung übergeben wurden. In der zurückgegebenen ProblemDetails-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    Problem Details 0..1 401 Unauthorized Verwendet, wenn der Client keine Berechtigungsnachweise übermittelt hat. In der zurückgegebenen Problem Details-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    Problem Details 1 403 Forbidden Die Operation ist bei dem aktuellen Status der Ressource nicht zulässig. In dem Attribut „detail“ der „ProblemDetails“-Struktur sollen mehr Informationen bereitgestellt werden.
    Problem Details 0..1 404 Not Found Verwendet, wenn ein Client einen URI bereitgestellt hat, der nicht auf einen gültigen Ressourcen-URI abgebildet werden kann. In der zurückgegebenen Problem Details-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    Problem Details 0..1 406 Not Acceptable Verwendet, um anzuzeigen, dass der Server keines der durch den Client unterstützten Inhaltsformate bereitstellen kann. In der zurückgegebenen ProblemDetails-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
    Problem Details 0..1 429 Too Many Requests Verwendet, wenn ein Ratenbegrenzer ausgelöst hat. In der zurückgegebenen Problem Details-Struktur sollte das Attribut „detail“ mehr Informationen über den Fehler übermitteln.
  • Pc5ProvisioningInfo ist ein Ressourcendatentyp. Der Pc5ProvisioningInfo-Typ repräsentiert die Bereitstellungsinformationen, die für die V2X-Kommunikation über PC5 benötigt werden. Diese Informationen liegen pro Standort vor (z. B. eine Zelle einer Basisstation, RSU, WAP/RAP oder ein geografischer Bereich). Die Attribute des Pc5ProvisioningInfo können den in Tabelle 12 bereitgestellten Angaben folgen und wie in [R04], 3GPP TS 36.300 v15.5.0 (2019-04-17), 3GPP TS 38.300 v15.5.0 (2019-04-09), 3GPP TS 36.321 v15.5.0 (2019-04-11) („[R18]“), 3GPP TS 38.321 v15.5.0 (2019-04-09) („[R19]“), 3GPP TS 36.331 v15.5.1 (2019-04-22) („[R20]“) und 3GPP TS 38.331 v15.5.1 (2019-04-16) („[R21]“) definiert sein. Tabelle 12: Attribute des Pc5Provisioninlnfo
    Attributbezeichnung Datentyp Kardinalität Beschreibung
    timeStamp TimeStamp 0..1 Zeitstempel.
    proInfoPc5 Structure (inlined) 1..N Die Bereitstellungsinformationen pro Standort wie unten definiert.
    >locationlnfo LocationInfo 1 Standortinformationen zum Identifizieren einer Zelle einer Basisstation oder eines bestimmten geografischen Bereichs.
    >dstLayer2ld Zeichen kette 1 Für Sidelink-Kommunikation wird die Ziel-Schicht-2-ID auf die ProSe-Schicht-2-Gruppen-ID oder Prose-UE-ID gesetzt, siehe z. B. [R18], [R19]. PLMN-Operatoren koordinieren, um sicherzustellen, dass Ziel-Schicht-2-ID(s) für verschiedene V2X-Dienste auf eine konsistente Weise konfiguriert werden.
    >neighbourCelllnfo Pc5NeighbourCelllnfo 0..N Die Informationen der Nachbarzellen in einem Visiting-PLMN, die V2X-Kommunikation über PC5 unterstützen.
  • Das Pc5NeighbourCellInfb-Attribut in Tabelle 12 kann eine PLMN-ID, eine ECGI/NCGI und SystemInformationBlockType21, wie in [R20] und/oder [R21] definiert, beinhalten.
  • Gemäß verschiedenen Ausführungsformen verwendet der Dienst(VIS)-Konsument die bereitgestellten Informationen, um die erfassten Funkqualitätsinformationen gemäß einem fahrtspezifischen Kriterium (z. B. wie zuvor diskutiert) zu partitionieren. Dadurch werden mittels der Verarbeitung jeder Funkinformationspartition fahrtspezifische QoS-Vorhersagebenachrichtigungen an das entsprechende vUE (z. B. über eine Unicastübertragung) oder an einen Cluster von vUEs (z. B. über eine Multicastübertragung) gesendet, die durch ähnliche geplante Routen gekennzeichnet sind.
  • Wie zuvor erwähnt, sind PlannedRouteInfo, PredictedQos und Pc5ProvisioningInfo jeweils Ressourcendatentypen. Eine Ressource ist ein Objekt mit einem Typ, assoziierten Daten, Beziehungen zu anderen Ressourcen und einem Satz von Verfahren, die auf der Ressource arbeiten. Tabellen 7, 9 und 12 definieren die Datentypen und Attribute, die für jede der Ressourcendarstellungen verwendet werden können. Ein Datentyp ist eine bestimmte Art von Datenelement, das durch die Werte, die es annehmen kann, und/oder die Operationen, die an ihm ausgeführt werden können, definiert ist. Wie durch die Tabellen 7, 9 und 12 gezeigt, weisen manche dieser Attribute einfache Datentypen, bei denen jedes Datenelement jeweils nur einen Wert speichern kann (z. B. Zeichenketten, vorzeichenlose ganze Zahlen („Uint“) usw.), und strukturierte Datentypen, bei denen jedes Datenelement eine Sammlung anderer Datenelemente ist, auf. Einige der strukturierten Datentypen sind durch Attribute definiert, die in derselben Tabelle aufgeführt sind (bezeichnet als „Structured (inline)“). In Tabelle 9 ist das routes-Attribut zum Beispiel ein strukturierter Datentyp, der ein oder mehrere routelnfo-Attribute beinhaltet, und jedes routeInfo-Attribut beinhaltet location- und time-Attribute und rsrp- und rsrq-Attribute, falls sie in einer Antwortnachricht enthalten sind. Manche der strukturierten Datentypen sind jedem Ressourcendatentyp gemeinsam, wie etwa der TimeStamp-Datentyp und der LocationInfo-Datentyp. Die Attribute des TimeStamp-Datentyps und des Locationlnfo-Datentyps können den in Tabelle 13 bzw. Tabelle 14 bereitgestellten Angaben folgen. Tabelle 13: Attribute des TimeStamp
    Attributbezeichnung Datentyp Kardinalität Beschreibung
    seconds Uint32 1 Der Sekundenanteil der Zeit. Die Zeit ist als Unix-Zeit seit 1. Januar 1970 00:00:00 UTC definiert.
    nanoSeconds Uint32 1 Der Nanosekundenanteil der Zeit. Die Zeit ist als Unix-Zeit seit 1. Januar 1970 00:00:00 UTC definiert.
    HINWEIS: Der Datentyp von Uint32 ist eine vorzeichenlose ganze Zahl von 32 Bit
    Tabelle 14: Attribute des Locationlnfo
    Attributbezeichnung Datentyp Kardinalität Beschreibung
    ecgi ECGI 0..1 E-UTRAN-Cell-Global-Identifier der versorgenden Zelle.
    ncgi NCGI 0..1 5G/NR-Cell-Global-Identity der versorgenden Zelle.
    geoArea Structure (inlined) 0..1 Informationen eines geografischen Bereichs.
    >Iatitude Float 1 Breitengrad (DATUM = WGS84) -90 bis 90 im Dezimalgradformat DDD.ddd
    >longitude Float 1 Längengrad (DATUM = WGS84) -180 bis 180 im Dezimalgradformat DDD.ddd
    HINWEIS: Es sollen entweder ecgi/ncgi oder geoArea vorhanden sein, aber nicht beide.
  • In Tabelle 14 bezieht sich „ECGI“ auf einen E-UTRAN-Cell-Global Identifier, der zum globalen Identifizieren von Zellen verwendet wird. Der ECGI ist aus einem Mobile Country Code (MCC), Mobile Network Code (MNC) und dem E-UTRAN Cell Identifier (ECI) aufgebaut. „NCGI“ bezieht sich auf einen NR/5G-Cell-Global-Identifier, der verwendet wird, um Zellen global zu identifizieren, obwohl eine gNB mehrere NCGIs beinhalten kann. Die NCGI ist eine Verkettung der PLMN-Kennung (PLMN-Id) und der 36-Bit-NR-Cell-Identity (NCI).
  • In jeder der Prozeduren von 11 kann die HTTP-Antwortnachricht, wenn die Anforderung erfolglos ist, fehlschlägt oder (einen) Fehler beinhaltet, andere HTTP-Statuscodes beinhalten, wie etwa einen Bad-Request-Statuscode (400) (z. B. wenn falsche Parameter in der Anforderung weitergeleitet werden), einen Not-Found-Statuscode (404) (z. B. wenn ein URI, der in der Anforderung bereitgestellt wird, nicht auf einen gültigen Ressourcen-URI abgebildet werden kann), einen Forbidden-Statuscode (403) (z. B. wenn die Operation bei dem aktuellen Status der Ressource nicht zulässig ist) und/oder andere ähnliche HTTP-Statuscodes. In den zuvor genannten Beispielen kann der Antwortrumpf ein ProblemDetails-IE, -Feld, -Datenelement oder eine andere ähnliche Datenstruktur beinhalten, die Informationen über den speziellen Fehler angibt/beinhaltet. Andere Nachrichtenformate können in anderen Ausführungsformen verwendet werden, und die Anforderungs-/Antwortdaten können sich in dem Header oder dem Rumpf solcher Nachrichten befinden.
  • III. BEISPIELHAFTE EDGE-COMPUTING-SYSTEMKONFIGURATIONEN UND - ANORDNUNGEN
  • Edge-Computing bezieht sich auf die Implementierung, Koordination und Verwendung von Berechnung und Ressourcen an Orten näher an dem „Rand“ oder der Ansammlung von „Rändern“ eines Netzwerks. Das Einsetzen von Rechenressourcen am Rand des Netzwerks kann Anwendungs- und Netzwerklatenz reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch reduzieren, Dienstfähigkeiten verbessern, die Einhaltung von Sicherheits- oder Datenschutzanforderungen verbessern (insbesondere im Vergleich zu herkömmlichem Cloud-Computing) und die Total Cost of Ownership verbessern.
  • Individuelle Rechenplattformen oder andere Komponenten, die Edge-Computing-Operationen durchführen können (als „Edge-Computing-Knoten“, „Edge-Knoten“ oder dergleichen bezeichnet), können sich an jedem Ort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird. In vielen Edge-Computing-Architekturen werden Edge-Knoten an NANs, Gateways, Netzwerkroutern und/oder anderen Vorrichtungen eingesetzt, die näher an Endpunktvorrichtungen (z. B. UEs, IoT-Vorrichtungen usw.) liegen, die Daten produzieren und konsumieren. Als Beispiele können Edge-Knoten in einem Hochleistungsrechenzentrum oder einer Hochleistungs-Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmensserver, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert.
  • Edge-Computing-Knoten können Ressourcen (z. B. Speicher, CPU, GPU, Interruptsteuerungen, E/A-Steuerungen, Speichersteuerung, Bussteuerungen, Netzwerkverbindungen oder -sitzungen usw.) partitionieren, wobei jeweilige Partitionierungen Sicherheits- und/oder Integritätsschutzfähigkeiten enthalten können. Edge-Knoten können auch Orchestrierung mehrerer Anwendungen über isolierte Benutzerrauminstanzen, wie etwa Container, Partitionen, virtuelle Umgebungen (VEs), virtuelle Maschinen (VMs), FaaS-Engines (FaaS: Function-as-a-Service), Servlets, Server und/oder andere ähnliche Rechenabstraktionen bereitstellen. Container sind einsetzbare Softwareeinheiten, die Code und benötigte Abhängigkeiten bereitstellen. Verschiedene Edge-Systemanordnungen/-architektur behandeln VMs, Container und funktionieren gleichermaßen hinsichtlich der Anwendungszusammensetzung. Die Edge-Knoten werden basierend auf Edge-Bereitstellungsfunktionen koordiniert, während der Betrieb der verschiedenen Anwendungen mit Orchestrierungsfunktionen (z. B. VM oder Container-Engine usw.) koordiniert wird. Die Orchestrierungsfunktionen können verwendet werden, um die isolierten Benutzerrauminstanzen einzusetzen, die die Verwendung spezifischer Hardware, sicherheitsbezogene Funktionen (z. B. Schlüsselverwaltung, Vertrauensankerverwaltung usw.) und andere Aufgaben in Bezug auf die Bereitstellung und den Lebenszyklus isolierter Benutzerräume identifizieren und planen.
  • Anwendungen, die für Edge-Computing angepasst wurden, beinhalten unter anderem Virtualisierung traditioneller Netzwerkfunktionen, darunter zum Beispiel softwaredefinierte Vernetzung (SDN), Netzwerkfunktionsvirtualisierung (NFV), verteilte RAN-Einheiten und/oder RAN-Clouds und dergleichen. Zusätzliche beispielhafte Verwendungsfälle für Edge-Computing beinhalten rechnerisches Offloading, Content-Data-Network(CDN)-Dienste (z. B. Video in Demand, Content-Streaming, Sicherheitsüberwachung, Alarmsystemüberwachung, Gebäudezugang, Daten-/Content-Caching usw.), Gaming-Dienste (z. B. AR/VR usw.), beschleunigtes Browsen, IoT- und Industrieanwendungen (z. B. Fabrikautomatisierung), Medienanalytik, Live-Streaming/Transcodierung und V2X-Anwendungen (z. B. Fahrassistenz- und/oder Autonomfahranwendungen).
  • Die vorliegende Offenbarung stellt spezifische Beispiele bereit, die für Edge-Computing-Konfigurationen relevant sind, die innerhalb von Mehrfachzugriffs-Edge-Computing(MEC)- und 5G-Netzwerkimplementierungen bereitgestellt werden. Viele andere Standards und Netzwerkimplementierungen sind jedoch auf die hier besprochenen Edge- und Dienstverwaltungskonzepte anwendbar. Zum Beispiel können die hier besprochenen Ausführungsformen auf viele andere Edge-Computing-/Netzwerktechnologien in verschiedenen Kombinationen und Layouts von Vorrichtungen anwendbar sein, die sich am Rand eines Netzwerks befinden. Beispiele für solche anderen Edge-Computing-/Netzwerktechnologien, die die vorliegenden Ausführungsformen implementieren können, beinhalten Content Delivery Networks (CDNs) (auch als „Content Distribution Networks“ oder dergleichen bezeichnet); Mobility-Service-Provider(MSP)-Edge-Computing- und/oder Mobility-as-a-Service(MaaS)-Providersysteme (z. B. verwendet in AECC-Architekturen); Nebula-Edge-Cloud-Systeme; Fog-Rechensysteme; Cloudlet-Edge-Cloud-Systeme; Mobile-Cloud-Computing(MCC)-Systeme; Central Office Re-architected as a Datacenter (CORD), Mobile-CORD (M-CORD) und/oder Converged-Multi-Access-and-Core(COMAC)-Systeme; und/oder dergleichen. Ferner können sich die hierin offenbarten Techniken auf andere IoT-Edge-Netzwerksysteme und -konfigurationen beziehen und andere zwischengeschaltete Verarbeitungsentitäten und Architekturen können ebenfalls verwendet werden, um die hierin beschriebenen Ausführungsformen umzusetzen.
  • 13 veranschaulicht eine Nicht-Roaming-5G-Systemarchitektur 1300 in einer Referenzpunktdarstellung gemäß verschiedenen Ausführungsformen. In 13 steht das UE 1366 in Kommunikation mit einem RAN 1368 sowie einer oder mehreren anderen 5GC-Entitäten. Das 5G-System 1300 beinhaltet mehrere Netzwerkfunktionen (NFs), wie etwa eine Zugangs- und Mobilitätsverwaltungsfunktion (AMF) 1362, eine Sitzungsverwaltungsfunktion (SMF) 1360, eine Richtliniensteuerfunktion (PCF) 1358, eine Anwendungsfunktion (AF) 1364, eine Benutzerebenenfunktion (UPF) 1370 und 1374, eine Netzwerk-Slice-Auswahlfunktion (NSSF) 1342, eine Authentifizierungsserverfunktion (AUSF) 1344 und Unified Data Management (UDM) 1346. Das 5G-System 1300 beinhaltet auch einen Anwendungsserver (AS) 1348 und einen oder mehrere MEC-Hosts 1336, die gleich oder ähnlich einem beliebigen der zuvor besprochenen MEC-Hosts 140, 240, 340, 440, 740, 840, 841, 940 und/oder 941 sein können.
  • Das (R)AN 1368 kann ein RAN der nächsten Generation (NG-RAN) sein, das mehrere Knoten beinhaltet, wie etwa Next Generation NodeBs (gNBs) und NG-Evolved-Node-Bs (NG-eNBs). Die AMF 1362 und die UPF 1370 können über jeweilige NG-Schnittstellen (nicht gezeigt) kommunikativ mit den gNBs und/oder den NG-eNBs gekoppelt sein. Die gNBs beinhalten einen oder mehrere Knoten, die NR/5G-Benutzerebenen- und Steuerebenenabschlüsse zu dem UE 1366 bereitstellen, und NG-eNBs beinhalten einen oder mehrere Knoten, die Evolved-Universal-Terrestrial-Radio-Access(E-UTRA)-Benutzerebenen- und Steuerebenen-Protokollabschlüsse zu dem UE 1366 bereitstellen und über die NG-Schnittstelle mit dem 5GC verbunden sind. Insbesondere können die gNBs und/oder NG-eNBs durch NG-C-Schnittstellen mit der AMF 1362 und durch NG-U-Schnittstellenmit der UPF 1370 verbunden sein. Die gNBs und die NG-eNBs können über jeweilige XN-Schnittstellen miteinander gekoppelt sein. Das NG-RAN kann auch Referenzpunkte zwischen verschiedenen Knoten verwenden, wie durch 3GPP TS 23.501 v16.0.2 (2019-04-01) („[R14]“) bereitgestellt.
  • Die UPF 1370, 1374 agiert als ein Ankerpunkt für Intra-RAT- und Inter-RAT-Mobilität. ein externer PDU-Sitzung-Verbindungspunkt mit einem lokalen Datennetzwerk (DN) 1372 und/oder einem zentralen DN 1376, von denen jedes zum Beispiel Operatordienste, Internetzugang oder Drittdienste beinhalten kann. Die DNs 1372, 1376 können einen oder mehrere zuvor besprochene Anwendungsserver 1348 beinhalten oder diesen ähnlich sein. Die UPF 1370, 1374 kann auch Paketrouting und -weiterleitung durchführen, Paketinspektion durchführen, den Benutzerebenenteil der Richtlinien durchsetzen, Pakete rechtmäßig abfangen, Verkehrsnutzungsmeldung durchführen, QoS-Handhabung für die Benutzerebene durchführen, UL-Verkehrsverifikation durchführen, Transportebenenpaketmarkierung im UL und DL und DL-Paketpuffern und DL-Datenbenachrichtigungsauslösung durchführen. Die UPF 1370 kann über einen N4-Referenzpunkt zwischen der SMF 1360 mit der SMF 1360 interagieren. Die UPF 1370 kann sich über eine N9-Schnittstelle mit einer anderen UPF 1374 verbinden, die über eine N6-Schnittstelle mit einem zentralen DN 1376 verbunden ist. Die UPF 1370, 1374 kann in einer oder mehreren Konfigurationen gemäß dem gewünschten Diensttyp eingesetzt werden.
  • Die AUSF 1344 speichert Daten zur Authentifizierung des UE 1366 und Handhabung authentifizierungsbezogener Funktionalität. Die AUSF 1344 kann einen gemeinsames Authentifizierungsframework für verschiedene Zugriffstypen ermöglichen. Die AUSF 1344 kann mit der AMF 1362 über einen N12-Referenzpunkt zwischen der AMF 1362 und der AUSF 1344 kommunizieren; und kann mit dem UDM 1346 über einen N13-Referenzpunkt zwischen dem UDM 1346 und der AUSF 1344 kommunizieren. Zusätzlich dazu kann die AUSF 1344 einen Nausf-SBI aufweisen.
  • Das UDM 1346 behandelt subskriptionsbezogene Informationen (z. B. Teilnehmerprofile und Daten), um die Handhabung von Kommunikationssitzungen durch die Netzwerkentitäten (ähnlich einem HSS in 4G-Systemen) zu unterstützen. Subskriptionsdaten können zwischen dem UDM 1346 und der AMF 1362 über einen N8-Referenzpunkt kommuniziert werden. Das UDM 1346 kann über einen N10-Referenzpunkt mit der SMF 1360 interagieren. Das UDM 1346 kann auch über den Sh-Referenzpunkt mit dem AS 1348 gekoppelt sein. Der AS 1348 kann ein Telefonieanwendungsserver (TAS), ein MEC-Host (z. B. MEC-Host 140, 240, 340, 440, 740, 840, 841, 940 und/oder 941, der zuvor erörtert wurde, oder derselbe wie oder ähnlich MEC-Host(s) 1336) sein oder diesen beinhalten. Das 5G-System 1300 kann einen oder mehrere MEC-Hosts 1336 verwenden, um eine Schnittstelle und eine Offload-Verarbeitung von Drahtloskommunikationsverkehr bereitzustellen. Zum Beispiel und wie in 13 veranschaulicht, kann ein MEC-Host 1336 eine Verbindung zwischen dem RAN 1368 und dem UPF 1370 in dem 5GC bereitstellen. Der MEC-Host 1336 kann eine oder mehrere NFV-Instanzen verwenden, die auf einer Virtualisierungsinfrastruktur innerhalb des MEC-Hosts 1336 instanziiert sind, um drahtlose Verbindungen zu und von dem RAN 1368 und der UPF 1370 zu verarbeiten.
  • Die AMF 1362 ist verantwortlich für Registrierungsverwaltung (z. B. zum Registrieren des UE 1366 bei dem 5G-Netzwerk), Verbindungsverwaltung, Erreichbarkeitsverwaltung, Mobilitätsverwaltung und Zugangsauthentifizierung und - autorisierung. Die AMF 1362 ist für die Beendigung von RAN-Steuerebenen- und NAS-Prozeduren verantwortlich, und somit ist die AMF 1362 der Endpunkt für die RAN-Steuerebenen(CP)-Schnittstelle (N2-Referenzpunkt) und ist auch der Endpunkt für Non-Access-Stratum(NAS)-Signalisierung mit dem UE 1366(N1-Referenzpunkt). Die AMF 1362 ist auch dafür verantwortlich, die Integrität der Signalisierung zu schützen, sich mit einer beliebigen Abfangfunktion für Zugangs- und Mobilitätsereignisse zu verknüpfen, Authentifizierung und Autorisierung für die Zugangsschicht bereitzustellen und die Sicherheitsanker-Funktionalität (SEAF) zu hosten. Die AMF 1412 stellt Kommunikations- und Erreichbarkeitsdienste für andere NFs bereit und kann gestatten, dass Subskriptionen Benachrichtigungen bezüglich Mobilitätsereignissen empfangen. Die AMF 1362 stellt auch externe Parameter (z. B. Erwartetes-UE-Verhalten-Parameter oder Netzwerkkonfigurationsparameter) bereit.
  • Die AMF 1362 ist auch der Endpunkt für den an N11-Referenzpunkt, der für Interaktionen mit der SMF 1360 verwendet wird, was der AMF 1362 ermöglicht, Transport für Sitzungsverwaltungs(SM)-Nachrichten zwischen dem UE 1366 und der SMF 1360 bereitzustellen. Die AMF 1362 kann auch einen Transport für SMS-Nachrichten zwischen dem UE 1366 und einer Kurznachrichtendienstfunktion (SMSF: Short Message Service Function) bereitstellen (in 13 nicht gezeigt). Die SMSF ist für SMS-Subskriptionsprüfung und -verifikation und Weiterleiten von SM-Nachrichten zu/von dem UE 1366 zu/von anderen SMS-Entitäten verantwortlich. Die AMF 1362 ist auch ein Endpunkt für einen N14-Referenzpunkt zwischen zwei AMFs 1362 und ein N17-Referenzpunkt zwischen der AMF 1362 und einem 5G-EIR (in 13 nicht gezeigt). Zusätzlich zu den oben beschriebenen Funktionalitäten der AMF kann die AMF andere Funktionalitäten beinhalten, wie in [R14] und 3GPP TS 23.503 v16.0.0 (2019-03-26) beschrieben.
  • Die SMF 1360 kann verantwortlich sein für SM-Funktionalität (z. B. Sitzungsaufbau, -modifizierung und -freigabe, einschließlich Tunnelerhaltung zwischen UPF 1370 und (R)AN 1368); IP-Adresszuweisung und -Verwaltung (einschließlich optionaler Autorisierung); Dynamisches-Host-Konfigurationsprotokoll(DHCP)-Dienste; (Neu-)Auswahl und Steuerung von UPFs 1370; Konfigurieren von Verkehrssteuerregeln an der UPF 1370, um Verkehr zu einem richtigen Ziel zu leiten; Abfangen für SM-Ereignisse; Abschluss von Schnittstellen zu Richtliniensteuerfunktionen; Steuern eines Teils der Richtliniendurchsetzung und QoS; Abschluss von SM-Teilen von NAS-Nachrichten; DL-Datenbenachrichtigung; Initiieren (R)AN-1368-spezifischer SM-Informationen, die über die AMF 1362 über N11 und dann N2 an (R)AN 1368 gesendet werden; und Bestimmen des SSC-Modus einer Sitzung. SM kann sich auf die Verwaltung einer PDU-Sitzung beziehen und eine PDU-Sitzung oder „Sitzung“ kann sich auf einen PDU-Konnektivitätsdienst beziehen, der den Austausch von PDUs zwischen einem UE 1366 und einem DN 1372, 1376, identifiziert durch einen Datennetzwerknamen (DNN), bereitstellt oder ermöglicht. Da MEC-Dienste sowohl in zentralisierten als auch verteilten Edge-Systemen angeboten werden können, kann die SMF 1414 dazu konfiguriert sein, die UPF 1370 auszuwählen und zu steuern sowie ihre Regeln zur Verkehrssteuerung zu konfigurieren. Die SMF 1414 ist auch dazu ausgelegt, Dienstoperationen offenzulegen, um zu ermöglichen, dass MEC als eine 5G-AF 1364 die PDU-Sitzungen verwaltet, die Richtlinieneinstellungen und Verkehrsregeln zu steuern sowie Benachrichtigungen über Sitzungsverwaltungsereignisse zu abonnieren.
  • Die PCF 1358 stellt Richtlinienregeln an CP-Funktion(en) bereit, um sie durchzusetzen, und unterstützt auch ein vereinheitlichtes Richtlinienframework, um das Netzwerkverhalten zu regeln (ähnlich PCRF in 4G-Systemen). Die PCF 1358 kann über einen N15-Referenzpunkt mit der AMF 1362 kommunizieren. Die PCF 1358 kann über einen N5-Referenzpunkt mit der AF 1364 und über einen N7-Referenzpunkt mit der SMF 1360 kommunizieren.
  • Die AF 1364 stellt einen Anwendungseinfluss auf Verkehrsrouting bereit, stellt Zugang zu der NEF (z. B. NEF 1418 von 14) bereit und interagiert mit dem Richtlinienframework zur Richtliniensteuerung. Die AF 1364 kann Anforderungen zum Beeinflussen von Routing-Entscheidungen der SMF 1360 für den Verkehr einer PDU-Sitzung senden. Die Anforderungen der AF 1364 können die UPF 1370, 1374 (Neu-)Auswahl beeinflussen und Routing von Benutzerverkehr zu einem lokalen Zugang zu einem DN 1372, 1376 (identifiziert durch eine DNAI) ermöglichen. Für Edge-Computing werden Betreiber- und Drittdienste nahe dem Anschlusspunkt des UE 1366 (z. B. (R)AN 1368) gehostet, um eine effiziente Dienstlieferung durch die reduzierte e2e-Latenz und Last auf dem Transportnetzwerk zu erreichen. Das 5GC wählt eine UPF 1370, 1374 nahe dem UE aus und führt die Verkehrssteuerung von der UPF 1370, 1374 zu dem lokalen DN 1372 über die N6-Schnittstelle aus. Dies kann auf den Subskriptionsdaten, dem UE-Standort, Informationen von der AF 1364, der Richtlinie und/oder anderen verbundenen Verkehrsregeln basieren. Manche AFs 1364 dürfen möglicherweise nicht direkt auf NFs zugreifen und müssen das externe Belichtungsframework über die NEF 1418 verwenden, um mit relevanten NFs zu interagieren.
  • Die NSSF 1342 wählt einen Satz von Netzwerk-Slice-Instanzen aus, die das UE 1366 versorgen. Die NSSF 1342 kann bei Bedarf auch zulässige NSSAI und die Abbildung auf die abonnierten S-NSSAIs bestimmen. Die NSSF 1342 kann auch den AMF-1362-Satz, der verwendet werden soll, um das UE 1366 zu versorgen, oder eine Liste von Kandidaten-AMF(s) 1362 basierend auf einer geeigneten Konfiguration und möglicherweise durch Abfragen einer NRF bestimmen (siehe z. B. NRF 1420 von 14). Die Auswahl eines Satzes von Netzwerk-Slice-Instanzen für das UE 1366 kann durch die AMF 1362 ausgelöst werden, bei der das UE 1366 registriert ist, indem es mit der NSSF 1342 interagiert, was zu einer Änderung der AMF 1362 führen kann. Die NSSF 1342 kann mit der AMF 1362 über einen N22-Referenzpunkt zwischen AMF 1362 und NSSF 1342 interagieren; und kann über einen N31-Referenzpunkt (nicht gezeigt) mit einer anderen NSSF 1342 in einem besuchten Netzwerk kommunizieren. Zusätzlich dazu kann die NSSF 1342 eine NNSSF-SBI aufzeigen.
  • 13 veranschaulicht eine Referenzpunktdarstellung eines 5G-Netzwerks. Eine Referenzpunktdarstellung zeigt, dass eine Interaktion zwischen entsprechenden NF-Diensten bestehen kann. 13 beinhaltet folgende Referenzpunkte: N1 (zwischen dem UE 1366 und der AMF 1362), N2 (zwischen dem RAN 1368 und der AMF 1362), N3 (zwischen dem RAN 1368 und der UPF 1370), N4 (zwischen der SMF 1360 und der UPF 1370), N5 (zwischen dem PCF 1358 und der AF 1364), N6 (zwischen dem UPF 1370 und der DN 1372, 1376), N7 (zwischen der SMF 1360 und der PCF 1358), N8 (zwischen dem UDM 1346 und der AMF 1362), N9 (zwischen UPFs 1370 und 1374), N10 (zwischen dem UDM 1346 und der SMF 1360), N11 (zwischen der AMF 1362 und der SMF 1360), N12 (zwischen der AUSF 1344 und der AMF 1362), N13 (zwischen der AUSF 1344 und dem UDM 1346), N14 (zwischen zwei AMFs 1362), N15 (zwischen der PCF 1358 und der AMF 1362 im Fall eines Nicht-Roaming-Szenarios, oder zwischen der PCF 1358 in einem besuchten Netzwerk und der AMF 1362 im Fall eines Roaming-Szenarios), N16 (zwischen zwei SMFs 1360, nicht gezeigt) und N22 (zwischen AMF 1362 und NSSF 1344). Es kann zahlreiche andere Referenzpunkte zwischen den NFs geben; diese Referenzpunkte wurden jedoch aus Gründen der Übersichtlichkeit in 13 weggelassen. Zusätzlich dazu kann das 5G-System 1300 auch andere Elemente beinhalten, die in 13 nicht gezeigt sind, wie etwa ein Datenspeicherungssystem/eine Datenspeicherungsarchitektur, 5G-EIR, SEPP, SMSF und dergleichen.
  • 14 veranschaulicht einen nicht-integrierten MEC-Einsatz 14A, einschließlich einer 5G-dienstbasierten Architektur 1400 und einer MEC-Architektur 1490, und einen integrierten MEC-Einsatz 14B, einschließlich eines MEC-Systems 1491 in einem 5G-Netzwerk 1401, wobei einige der funktionalen Entitäten des MEC-Systems 1491 mit den NFs des 5G-Netzwerks interagieren. Unter Bezugnahme auf den Einsatz 14A ist die 5G-Systemarchitektur 1400 in einer dienstbasierten Darstellung veranschaulicht und kann im Wesentlichen der Systemarchitektur 1300 aus 13 ähnlich (oder gleich) sein. Zum Beispiel beinhaltet die 5G-Systemarchitektur 1400 die folgenden Entitäten, die auch in der Systemarchitektur 1400 vorhanden sind: NSSF 1416, PCF 1422, UDM 1424, AF 1426, AUSF 1410, AMF 1412, SMF 1414, UE 1402, RAN 1404, UPF 1406 und DN 1408. Zusätzlich zu diesen Netzwerkentitäten weist die 5G-Systemarchitektur 2800 auch eine Netzwerkoffenlegungsfunktion (NEF: Network Exposition Function) 1418 und eine Netzwerkrepositoriumsfunktion (NRF: Network Repository Function) 1420 auf. Die 5G-Systemarchitekturen können dienstbasiert sein und eine Interaktion zwischen NFs kann durch entsprechende Punkt-zu-Punkt-Referenzpunkte Ni (wie in 13 veranschaulicht) oder als SBIs (wie in 14 veranschaulicht) repräsentiert werden.
  • Das 5G-System 1400 in 14 ist eine dienstbasierte Repräsentation, die verwendet wird, um NFs innerhalb der CP zu repräsentieren, die es anderen autorisierten NFs ermöglichen, auf ihre Dienste zuzugreifen. Das 5G-System 1400 umfasst die folgenden dienstbasierten Schnittstellen (SBIs): Namf (eine SBI, die von der AMF 1412 aufgezeigt wird), Nsmf (eine SBI, die von der SMF 1414 aufgezeigt wird), Nnef (eine SBI, die von der NEF 1318 aufgezeigt wird), Npcf (eine SBI, die von der PCF 1422 aufgezeigt wird), Nudm (eine SBI, die von dem UDM 1424 aufgezeigt wird), Naf (eine SBI, die von der AF 1426 aufgezeigt wird), Nnrf (eine SBI, die von der NRF 1420 aufgezeigt wird), Nnssf (eine SBI, die von der NSSF 1416 aufgezeigt wird), Nausf (eine SBI, die von der AUSF 1410 aufgezeigt wird). Andere SBIs, die in 14 nicht gezeigt sind, können ebenfalls verwendet werden (z. B. Nudr, N5g-eir und Nudsf).
  • Die NEF 1318 stellt Mittel zum sicheren Offenlegen der Dienste und Fähigkeiten bereit, die durch 3GPP-NFs für Internoffenlegungs-/Neuoffenlegungs-Dritt-AFs 1464, Edge-Computing- oder Fog-Computing-Systeme usw. bereitgestellt werden. Die NEF 1318 kann die AFs 1464 authentifizieren, autorisieren und/oder drosseln. Die NEF 1318 kann auch Informationen, die mit der/den AF(s) 1464 ausgetauscht werden, und Informationen, die mit internen NFs ausgetauscht werden, übersetzen. Die NEF 1318 kann auch Informationen von anderen NFs basierend auf offengelegten Fähigkeiten anderer NFs empfangen. Diese Informationen können in der NEF 1318 als strukturierte Daten oder in einer Datenspeicherungs-NF unter Verwendung standardisierter Schnittstellen gespeichert werden. Die gespeicherten Informationen können dann durch die NEF 1318 anderen NFs und AFs erneut offengelegt werden und/oder für andere Zwecke, wie etwa Analytik, verwendet werden. In diesem Beispiel stellt die NEF 1318 eine Schnittstelle zu einem MEC-Host in einem MEC-System 1490, 1491 bereit, die verwendet werden kann, um drahtlose Verbindungen mit dem RAN 1404 zu verarbeiten.
  • Die NRF 1420 unterstützt Dienstentdeckungsfunktionen, empfängt NF-Entdeckungsanforderungen von NF-Instanzen oder dem SCP 1428 und liefert die Informationen der entdeckten (oder zu entdeckenden) NF-Instanzen an die NF-Instanzen oder den SCP 1428. Die NRF 1420 führt NF-Profile verfügbarer NF-Instanzen und ihrer unterstützten Dienste (z. B. NF-Instanz-ID, NF-Typ, PLMN-ID, FQDN oder IP-Adresse von NF, NF-Kapazitätsinformationen, NF-Prioritätsinformationen usw.). Der SCP 1428 (oder einzelne Instanzen des SCP 1428) unterstützt indirekte Kommunikation (siehe z. B. [R14] Abschnitt 7.1.1) zwischen zwei oder mehr NFs; delegierte Entdeckung (siehe z. B. [R14] Abschnitt 7.1.1); Nachrichtenweiterleitung und -Routing zu Ziel-NF/NF-Dienst(en), Kommunikationssicherheit (z. B. Autorisierung des NF-Dienstkonsumenten zum Zugreifen auf die NF-Diensterzeuger-API (siehe z. B. 3GPP TS 33.501), Lastausgleich, Überwachung, Überlaststeuerung usw.; und Entdeckungs- und Auswahlfunktionalität für UDM(s), AUSF(s), UDR(s), PCF(s) mit Zugriff auf Subskriptionsdaten, die in dem UDR gespeichert sind, basierend auf SUPI, SUCI oder GPSI des UE (siehe z. B. [R14] Abschnitt 6.3). Lastausgleichs-, Überwachungs-, Überlaststeuerfunktionalität, die durch den SCP 1428 bereitgestellt wird, kann implementierungsspezifisch sein. Der SCP 1428 kann verteilt eingesetzt werden. Im Kommunikationspfad zwischen verschiedenen NF-Diensten können mehr als ein SCP 1428 vorhanden sein. Der SCP 1428 kann, obwohl keine NF-Instanz, auch verteilt, redundant und skalierbar eingesetzt werden.
  • Das MEC-System 1490 kann einen MEC-Orchestrator 1470 (der auf einer Systemebene arbeitet) sowie die folgenden MEC-Entitäten, die auf einer verteilten Host-Ebene arbeiten, beinhalten: eine oder mehrere Apps 1472, einen oder mehrere Dienste 1474, eine Virtualisierungsinfrastruktur 1476, eine MEC-Plattform 1478 und einen MEC-Plattform-Manager 1480. Auf Komponenten des MEC-Systems 1490 wird weiter unten näher eingegangen.
  • Der integrierte MEC-Einsatz 14B beinhaltet die gleichen MEC- und 5GC-NFs wie in dem zuvor besprochenen nicht-integrierten Einsatz 14A. Bei dieser Implementierung befindet sich der integrierte MEC-Einsatz 14B zumindest teilweise innerhalb des 5G-Netzwerks 1401. Das 5G-Netzwerk 1401 ist das gleiche oder ähnlich dem 5G-System 1400, jedoch sind nicht alle NFs in dem 5G-Netzwerk 1401 gezeigt. Der integrierte MEC-Einsatz 14B kann unter Verwendung einer oder mehrerer der folgenden Techniken konfiguriert werden: (1) Lokales Routing und Verkehrssteuerung; (2) Die Fähigkeit einer AF 1426, die UPF-1406-(Neu-)Auswahl und Verkehrs-Routing direkt über die PCF 1422 oder indirekt über die NEF 1418 in Abhängigkeit von den Richtlinien des Betreibers zu beeinflussen; (3) Die Sitzungs- und Dienstkontinuität(SSC: Session and Service Continuity)-Modi für das UE 1402 und Anwendungsmobilitätsszenarien; (4) Unterstützung des lokalen Datennetzwerks (LADN: Local Area Data Network) 1408 durch das 5G-Netzwerk 1401 durch Bereitstellen von Unterstützung zum Verbinden mit dem LADN 1408 in einem gewissen Bereich, in dem die Apps 1472 eingesetzt werden. Der Zugang zu einem LADN 1408 kann in einem spezifischen LADN-Dienstbereich verfügbar sein, der als ein Satz von Verfolgungsbereichen in dem bedienenden PLMN des UE definiert ist. Das LADN 1408 kann als ein Dienst konfiguriert sein, der durch das bedienende PLMN des UE bereitgestellt wird. Für lokales Routing und Verkehrssteuerung kann das 5G-Netzwerk 1401 dazu ausgelegt sein, Verkehr auszuwählen, der zu den Apps 1472 in der LADN 1408 zu routen ist, die Teil des MEC-Systems 1491 sein kann. Eine PDU-Sitzung kann mehrere N6-Schnittstellen zum Datennetzwerk 1408 aufweisen. Die UPFs 1406, die diese Schnittstellen abschließen, können dazu konfiguriert sein, PDU-Sitzungsankerfunktionalität zu unterstützen. Verkehrssteuerung durch die UPF 1406 wird durch UL-Klassifikatoren unterstützt, die an einem Satz von Verkehrsfiltern arbeiten, die mit dem gesteuerten Verkehr übereinstimmen, oder alternativ dazu durch IPv6-Multi-Homing, wobei mehrere IPv6-Präfixe mit der betreffenden PDU-Sitzung assoziiert wurden.
  • Die NFs innerhalb des 5G-Netzwerks 1401 und die Dienste, die sie erzeugen, sind in der NRF 1420 registriert, während in dem MEC-System 1491 die Dienste, die durch die MEC-Anwendungen 1472 erzeugt werden, in der Dienstregistrierungsdatenbank der MEC-Plattform 1478 registriert sind. Eine Dienstregistrierung kann Teil der Anwendungsfreigabefunktionalität sein. Um den Dienst zu verwenden, kann, falls autorisiert, eine NF direkt mit der NF interagieren, die den Dienst erzeugt. Die Liste verfügbarer MEC-Dienste kann von der NRF 1420 entdeckt werden. Manche der Dienste können über die NEF 1418 zugänglich sein, die auch nicht-vertrauenswürdigen Entitäten, die sich außerhalb der Domäne befinden, verfügbar ist, um auf den Dienst zuzugreifen. Anders ausgedrückt kann die NEF 1418 als ein zentralisierter Punkt zur Dienstoffenlegung fungieren und hat auch eine Schlüsselrolle beim Autorisieren aller Zugriffsanfragen, die von außerhalb des Systems stammen. Prozeduren in Bezug auf Authentifizierung können durch die AUSF 1410 bedient werden.
  • Das 5G-Netzwerk 1401 kann Netzwerk-Slicing verwenden, das die Zuordnung der erforderlichen Merkmale und Ressourcen von den verfügbaren NFs zu verschiedenen Diensten oder zu Mandanten, die Dienste nutzen, ermöglicht. Die Netzwerk-Slice-Auswahlfunktion (NSSF: Network Slice Selection Function) 1416 kann dazu ausgelegt sein, bei der Auswahl geeigneter Netzwerk-Slice-Instanzen für Benutzer und bei der Zuweisung der notwendigen AMF 1412 zu assistieren. Eine MEC-App 1472 (z. B. eine in der verteilten Cloud des MEC-Systems 1490 gehostete Anwendung) kann zu einem oder mehreren Netzwerk-Slices gehören, die in dem 5G-Netzwerk 1401 konfiguriert wurden.
  • Die PCF 1422 ist auch die Funktion, deren Dienste eine AF 1426, wie etwa eine MEC-Plattform 1478, anfordert, um die Verkehrssteuerungsregeln zu beeinflussen. Auf die PCF 1422 kann entweder direkt oder über die NEF 1418 zugegriffen werden, in Abhängigkeit davon, ob die AF 1426 als vertrauenswürdig angesehen wird oder nicht, und im Fall einer Verkehrssteuerung, ob die entsprechende PDU-Sitzung zum Zeitpunkt der Anforderung bekannt ist. Das UDM 1424 ist für nutzer- und subskriptionsbezogene Dienste zuständig. Zum Beispiel kann das UDM 1424 dazu ausgelegt sein, 3GPP-Authentifizierungs- und Schlüsselvereinbarungs(AKA)-Authentifizierungsberechtigungsnachweise zu erzeugen, benutzeridentifizierungsbezogene Informationen zu handhaben, Zugangsautorisierung (z. B. Roaming-Beschränkungen) zu verwalten, die Benutzer-Dienst-NFs (versorgende AMF 1412, SMF 1414) zu registrieren, SMF/DNN-Zuweisungen zu unterstützen, Abfangprozeduren bei abgehendem Roaming durch Fungieren als Kontaktpunkt zu unterstützen und Sunskriptionsverwaltungsprozeduren durchzuführen.
  • Die UPF 1406 kann dazu konfiguriert sein, bei einem integrierten MEC-Einsatz in dem 5G-Netzwerk 1401 zu assistieren. UPFs 1406 können aus Sicht des MEC-Systems 1491 als eine verteilte und konfigurierbare Datenebene betrachtet werden. Die Steuerung dieser Datenebene, wie etwa in einer Verkehrsregelkonfiguration, kann der NEF-PCF-SMF-Kommunikationsroute folgen. Folglich kann die lokale UPF 1406 Teil der MEC-Implementierung sein, wie bei Einsatz 14B veranschaulicht.
  • Der MEC-Orchestrator 1470 in Einsatz 14B ist eine funktionale Entität auf MEC-Systemebene, die, als AF fungierend, mit der NEF 1418 oder in manchen Szenarien direkt mit den Ziel-5G-NFs interagieren kann. Auf der verteilten Host-Ebene (oder „MEC-Host-Ebene“) kann die MEC-Plattform 1478 dazu ausgelegt sein, mit den 5G-NFs zu interagieren, wiederum in der Rolle einer AF 1426. Der MEC-Host (siehe z. B. MEC-Host 1502 in 15) und/oder andere Host-Ebenen-Funktionsentitäten können in einem Datennetzwerk (z. B. 1408) in dem 5G-System eingesetzt werden. Während die NEF 1418 als eine 5GC-NF eine Entität auf Systemebene ist, die zentral zusammen mit ähnlichen NFs eingesetzt wird, kann eine Instanz der NEF 1418 auch in der Edge eingesetzt werden, um einen Dienstzugriff mit niedriger Latenz und hohem Durchsatz von einem MEC-Host zu ermöglichen.
  • Bei Einsatz 14B wird das MEC-System 1491 auf dem N6-Referenzpunkt des UPF 1406 eingesetzt, der sich in einem Datennetzwerk 1408 außerhalb des 5G-Systems 1401 befinden kann. Diese Funktionalität kann durch Flexibilität beim Lokalisieren der UPF 1406 ermöglicht werden. Der verteilte MEC-Host kann neben den MEC-Apps 1472 einen Nachrichtenbroker als MEC-Plattformdienst 1474 und einen anderen MEC-Plattformdienst zum Steuern von Verkehr zu lokalen Beschleunigern aufnehmen. Die Wahl, einen Dienst als MEC-App oder als Plattformdienst auszuführen, kann implementierungsspezifisch sein und die Ebene der gemeinsamen Nutzung und Authentifizierung berücksichtigen, die für den Zugriff auf den Dienst erforderlich ist. Ein MEC-Dienst, wie etwa ein Nachrichtenbroker, könnte zunächst als eine MEC-App 1472 eingesetzt werden und dann als ein MEC-Plattformdienst 1474 verfügbar werden.
  • MEC-Hosts des MEC-Systems 1491 werden in der Edge oder in einem zentralen Datennetzwerk eingesetzt. Die UPF 1406 kann dazu konfiguriert sein, das Steuern des Benutzerebenenverkehrs zu den betreffenden MEC-Apps 1472 in dem DN 1408 zu verwalten. Die Standorte des/der DN(s) 1408 und der UPF(s) 1406 sind eine Auswahl des Netzwerkbetreibers und der Netzwerkbetreiber kann auswählen, die physischen Rechenressourcen basierend auf technischen und Geschäftsparametern, wie etwa verfügbaren Standorteinrichtungen, unterstützten Anwendungen und ihren Anforderungen, gemessener oder geschätzter Benutzerauslastung usw., zu platzieren. Das MEC-Verwaltungssystem, das den Betrieb von MEC-Hosts und Anwendungen orchestriert, kann dynamisch entscheiden, wo die MEC-Apps 1472 einzusetzen sind. Hinsichtlich des physischen Einsatzes von MEC-Hosts können die folgenden Optionen bei verschiedenen Aspekten verwendet werden: (1) der MEC-Host und das lokale UPF 1406 sind zusammen mit der Basisstation einer Basisstation-Edge-Schicht angeordnet; (2) der MEC-Host ist zusammen mit einem Übertragungsknoten angeordnet, der eine lokale UPF 1406 beinhalten kann; (3) der MEC-Host und die lokale UPF 1406 sind zusammen mit einem Netzwerkaggregationspunkt angeordnet; und (4) der MEC-Host ist zusammen mit den 5G-Kern-NFs (z. B. in demselben Datenzentrum) angeordnet.
  • 15 veranschaulicht eine MEC-Systemreferenzarchitektur (oder MEC-Architektur) 1500, die Funktionalitäten gemäß [R05] bereitstellt. MEC bietet Anwendungsentwicklern und Inhaltsanbietern Cloud-Rechenfähigkeiten und eine IT-Dienstumgebung am Rand des Netzwerks. Diese Umgebung zeichnet sich durch ultraniedrige Latenz und hohe Bandbreite sowie Echtzeitzugriff auf Funknetzinformationen aus, die durch Anwendungen genutzt werden können. Die MEC-Technologie gestattet einen flexiblen und schnellen Einsatz innovativer Anwendungen und Dienste bei mobilen Teilnehmern, Unternehmen und vertikalen Segmenten. Insbesondere müssen, in Bezug auf den Automobilsektor, Anwendungen wie V2X (z. B. IEEE 802. 11p basierte Protokolle, wie etwa DSRC/ITS-G5- oder 3GPP-C-V2X-basierte Protokolle) Daten austauschen, Aggregationspunkten Daten und Zugriff auf Daten in Datenbanken bereitstellen, die einen Überblick über die lokale Situation bereitstellen, abgeleitet von einer Vielzahl von Sensoren (durch verschiedene Autos, Straßenrandeinheiten usw.).
  • Die MEC-Architektur 1500 weist MEC-Hosts 1502, einen Virtualisierungsinfrastruktur-Manager (VIM) 1508, einen MEC-Plattform-Manager 1506, einen MEC-Orchestrator 1510, ein Operationsunterstützungssystem (OSS) 1512, einen Benutzer-App-Proxy 1514, eine UE-App 1518, die auf dem UE 1520 läuft, und ein CFS-Portal 1516 auf. Der MEC-Host 1502 kann eine MEC-Plattform 1532 mit Filterungsregelsteuerkomponente 1540, eine DNS-Handhabungskomponente 1542, eine Dienstregistrierungsdatenbank 1538 und MEC-Dienste 1536 beinhalten. Die MEC-Dienste 1536 können mindestens einen Scheduler beinhalten, der verwendet werden kann, um Ressourcen zum Instanziieren von MEC-Apps (oder NFVs) 1526 auf der Virtualisierungsinfrastruktur (VI) 1522 auszuwählen. Die MEC-Apps 1526 können dazu ausgelegt sein, Dienste 1530, darunter Verarbeiten von Netzwerkkommunikationsverkehr verschiedener Typen, die mit einer oder mehreren drahtlosen Verbindungen (z. B. Verbindungen zu einem oder mehreren RANs oder Kernnetzwerkfunktionen) assoziiert sind, und/oder andere Dienste, wie etwa die hierin besprochenen, bereitzustellen. Der andere MEC-Host 1502 kann eine gleiche oder eine ähnliche Konfiguration/Implementierung wie der MEC-Host 1502 aufweisen, und die andere MEC-App 1526, die innerhalb des anderen MEC-Hosts 1502 instanziiert ist, kann den MEC-Apps 1526, die innerhalb des MEC-Hosts 1502 instanziiert sind, ähnlich sein. Die VI 1522 beinhaltet eine Datenebene 1524, die über eine MP2-Schnittstelle mit der MEC-Plattform 1522 gekoppelt ist. Zusätzliche Schnittstellen zwischen verschiedenen Netzwerkentitäten der MEC-Architektur 1500 sind in 15 veranschaulicht.
  • Das MEC-System 1500 beinhaltet drei Gruppen von Referenzpunkten, einschließlich „Mp“-Referenzpunkten bezüglich der MEC-Plattformfunktionalität; „Mm“-Referenzpunkten, die Verwaltungsreferenzpunkte sind; und „Mx“-Referenzpunkten, die MEC-Entitäten mit externen Entitäten verbinden. Die Schnittstellen/Referenzpunkte in dem MEC-System 1500 können IP-basierte Verbindungen beinhalten und können verwendet werden, um Repräsentationszustandstransfer-(REST oder RESTful-)Dienste bereitzustellen, und die unter Verwendung der Referenzpunkte/Schnittstellen übermittelten Nachrichten können in XML, HTML, JSON oder einem anderen gewünschten Format, wie etwa jenen hierin besprochenen, vorliegen. Ein geeignetes Authentifizierungs-, Autorisierungs- und Abrechnungsprotokoll (AAA), wie das Radius- oder Diameter-Protokoll, kann bei anderen Ausführungsformen auch zum Kommunizieren über die Referenzpunkte/Schnittstellen verwendet werden.
  • Die logischen Verbindungen zwischen verschiedenen Entitäten der MEC-Architektur 1500 können zugriffsagnostisch sein und nicht von einem bestimmten Einsatz abhängen. MEC ermöglicht die Implementierung von MEC-Apps 1526 als Nur-Software-Entitäten, die auf einer VI 1522 laufen, die sich in oder nahe dem Netzwerkrand befindet. Eine MEC-App 1526 ist eine Anwendung, die auf einem MEC-Host 1502 innerhalb des MEC-Systems 1500 instanziiert werden kann und potenziell MEC-Dienste 1536 bereitstellen oder konsumieren kann.
  • Die in 15 dargestellten MEC-Entitäten können in eine MEC-Systemebene, MEC-Host-Ebene und Entitäten auf Netzwerkebene (nicht gezeigt) gruppiert werden. Die (nicht gezeigte) Netzwerkebene beinhaltet verschiedene externe Netzwerkebenenentitäten, wie etwa ein 3GPP-Netzwerk, ein lokales Netzwerk (z. B. ein LAN, WLAN, PAN, DN, LADN usw.) und ein oder mehrere externe Netzwerke. Die MEC-Systemebene beinhaltet MEC-Systemebenen-Verwaltungsentitäten und UE 1520 und wird im Folgenden ausführlicher besprochen. Die MEC-Host-Ebene beinhaltet einen oder mehrere MEC-Hosts 1502, 1504 und MEC-Verwaltungsentitäten, die Funktionalität bereitstellen, um MEC-Anwendungen 1526 innerhalb eines Betreibernetzwerks oder einer Teilmenge eines Betreibernetzwerks auszuführen. Die MEC-Verwaltungsentitäten beinhalten verschiedene Komponenten, die die Verwaltung der MEC-spezifischen Funktionalität einer speziellen MEC-Plattform 1532, eines MEC-Hosts 1502 und der MEC-Apps 1526, die ausgeführt werden sollen, handhaben.
  • Der MEC-Plattformmanager 1506 ist eine MEC-Verwaltungsentität, die eine MEC-Plattformelement-Verwaltungskomponente 1544, eine MEC-App-Regel- und - Anforderungsverwaltungskomponente 1546 und eine MEC-App-Lebenszyklusverwaltungskomponente 1548 beinhaltet. Die verschiedenen Entitäten innerhalb der MEC-Architektur 1500 können Funktionalitäten durchführen, wie in [R05] besprochen. Die Remote-App 1550 ist dazu ausgelegt, mit dem MEC-Host 1502 (z. B. mit den MEC-Apps 1526) über den MEC-Orchestrator 1510 und den MEC-Plattform-Manager 1506 zu kommunizieren.
  • Der MEC-Host 1502 ist eine Entität, die eine MEC-Plattform 1532 und VI 1522 enthält, die Rechen-, Speicherungs- und Netzwerkressourcen zum Zweck des Ausführens der MEC-Apps 1526 bereitstellt. Die VI 1522 beinhaltet eine Datenebene (DP) 1524, die Verkehrsregeln 1540 ausführt, die durch die MEC-Plattform 1532 empfangen werden, und den Verkehr zwischen MEC-Apps 1526, MEC-Diensten 1536, DNS-Server/Proxy (siehe z. B. über DNS-Handhabungsentität 1542), 3GPP-Netzwerk, lokalen Netzwerken und externen Netzwerken routet. Das MEC-DP 1524 kann mit den (R)AN-Knoten und dem 3GPP-Kernnetzwerk verbunden sein und/oder kann mit einem Zugangspunkt über ein breiteres Netzwerk, wie etwa das Internet, ein Unternehmensnetzwerk oder dergleichen, verbunden sein.
  • Die MEC-Plattform 1532 ist eine Sammlung essentieller Funktionalität, die erforderlich ist, um MEC-Apps 1526 auf einer bestimmten VI 1522 auszuführen und ihnen zu ermöglichen, MEC-Dienste 1536 bereitzustellen und zu konsumieren, und die sich selbst eine Anzahl von MEC-Diensten 937a bereitstellen kann. Die MEC-Plattform 1532 kann auch verschiedene Dienste und/oder Funktionen bereitstellen, wie etwa Anbieten einer Umgebung, in der die MEC-Apps 1526 MEC-Dienste 1536 (im Folgenden besprochen) entdecken, ankündigen, konsumieren und anbieten können, darunter MEC-Dienste 1536, die über andere Plattformen verfügbar sind, wenn sie unterstützt werden. Die MEC-Plattform 1532 kann in der Lage sein, autorisierten MEC-Anwendungen 1526 zu ermöglichen, mit Drittservern zu kommunizieren, die sich in externen Netzwerken befinden. Die MEC-Plattform 1532 kann Verkehrsregeln von dem MEC-Plattform-Manager 1506, Anwendungen oder Diensten empfangen und die Datenebene entsprechend anweisen (siehe z. B., Verkehrsregelsteuerung 1540). Die MEC-Plattform 1532 kann Anweisungen an die DP 1524 innerhalb der VI 1522 über den Mp2-Referenzpunkt senden. Der Mp2-Referenzpunkt zwischen der MEC-Plattform 1532 und der DP 1524 der VI 1522 kann verwendet werden, um die DP 1534 darüber anzuweisen, wie Verkehr zwischen Anwendungen, Netzwerken, Diensten usw. zu routen ist. Die MEC-Plattform 1532 kann Token, die UEs 1520 in den Verkehrsregeln repräsentieren, in spezifische IP-Adressen übersetzen. Die MEC-Plattform 1532 empfängt auch DNS-Aufzeichnungen von dem MEC-Plattform-Manager 1506 und konfiguriert einen DNS-Proxy/Server entsprechend. Die MEC-Plattform 1532 hostet MEC-Dienste 1536 einschließlich der nachstehend besprochenen Mehrfachzugriffs-Edge-Dienste und stellt Zugang zu persistenten Speicherungs- und Tageszeitinformationen bereit. Des Weiteren kann die MEC-Plattform 1532 mit anderen MEC-Plattformen 1532 anderer MEC-Server 1502 über den Mp3-Referenzpunkt kommunizieren.
  • Die VI 1522 repräsentiert die Gesamtheit aller Hardware- und Softwarekomponenten, die die Umgebung aufbauen, in der MEC-Anwendungen 1526 und/oder MEC-Plattform 1532 eingesetzt, verwaltet und ausgeführt werden. Die VI 1522 kann sich über mehrere Orte erstrecken und das Netzwerk, das Konnektivität zwischen diesen Orten bereitstellt, wird als Teil der VI 1522 angesehen. Die physischen Hardwareressourcen der VI 1522 beinhalten Rechen-, Speicherungs- und Netzwerkressourcen, die Verarbeitung, Speicherung und Konnektivität für MEC-Anwendungen 1526 und/oder MEC-Plattform 1532 durch eine Virtualisierungsschicht (z. B. einen Hypervisor, VM-Monitor (VMM) oder dergleichen) bereitstellen. Die Virtualisierungsschicht kann die physischen Hardwareressourcen des MEC-Servers 1502 als eine Hardware-Abstraktionsschicht abstrahieren und/oder logisch partitionieren. Die Virtualisierungsschicht kann es der Software, die die MEC-Anwendungen 1526 und/oder die MEC-Plattform 1532 implementiert, auch ermöglichen, die zugrundeliegende VI 1522 zu verwenden, und kann virtualisierte Ressourcen für die MEC-Anwendungen 1526 und/oder die MEC-Plattform 1532 bereitstellen, sodass die MEC-Anwendungen 1526 und/oder die MEC-Plattform 1532 ausgeführt werden können.
  • Die MEC-Anwendungen 1526 sind Anwendungen, die auf einem MEC-Host/Server 1502 innerhalb des MEC-Systems 1500 instanziiert werden können und potenziell MEC-Dienste 1536 bereitstellen oder konsumieren können. Der Begriff „MEC-Dienst“ bezieht sich auf einen Dienst, der über eine MEC-Plattform 1532 entweder durch die MEC-Plattform 1532 selbst oder durch eine MEC-App 1526 bereitgestellt wird. MEC-Anwendungen 1526 können als VM auf der VI 1522 laufen, die durch den MEC-Server 1502 bereitgestellt wird, und können mit der MEC-Plattform 1532 interagieren, um die MEC-Dienste 1536 zu konsumieren und bereitzustellen. Der Mp1-Referenzpunkt zwischen der MEC-Plattform 1532 und den MEC-Anwendungen 1526 wird zum Konsumieren und Bereitstellen dienstspezifischer Funktionalität verwendet. Mp1 stellt Dienstregistrierung 1538, Dienstentdeckung und Kommunikationsunterstützung für verschiedene Dienste, wie etwa die MEC-Dienste 1536, die durch den MEC-Host 1502 bereitgestellt werden, bereit. Mp1 kann auch Anwendungsverfügbarkeit, Sitzungsstatusverlagerungsunterstützungsprozeduren, Verkehrsregel- und DNS-Regel-Aktivierung, Zugriff auf persistente Speicherungs- und Tageszeitinformationen und/oder dergleichen bereitstellen.
  • Die MEC-Anwendungen 1526 werden auf der VI 1522 des MEC-Servers 1502 basierend auf Konfiguration oder Anforderungen instanziiert, die durch die MEC-Verwaltung (z. B. MEC-Plattform-Manager 1506) validiert werden. Die MEC-Anwendungen 1526 können auch mit der MEC-Plattform 1532 interagieren, um gewisse Unterstützungsprozeduren in Bezug auf den Lebenszyklus der MEC-Apps 1526 durchzuführen, wie etwa Anzeigen einer Verfügbarkeit, Vorbereiten einer Verlagerung eines Benutzerzustands usw. Die MEC-Anwendungen 1526 können eine gewisse Anzahl von Regeln und Anforderungen aufweisen, die mit ihnen assoziiert sind, wie etwa erforderliche Ressourcen, maximale Latenz, erforderliche oder nützliche Dienste usw. Diese Anforderungen können durch die MEC-Verwaltung validiert werden und können Standardwerten zugewiesen werden, falls sie fehlen. MEC-Dienste 1536 sind Dienste, die entweder durch die MEC-Plattform 1532 und/oder MEC-Apps 1526 bereitgestellt und/oder konsumiert werden. Die Dienstkonsumenten (z. B. MEC-Anwendungen 1526 und/oder MEC-Plattform 1532) können mit bestimmten MEC-Diensten 1536 über einzelne APIs (darunter MEC-V2X-API und die anderen MEC-APIs, die hier besprochen sind) kommunizieren. Wenn durch eine Anwendung bereitgestellt, kann ein MEC-Dienst 1536 in einer Liste von Diensten in den Dienstregistrierungsdatenbanken 1538 bei der MEC-Plattform 1532 über den Mp1-Referenzpunkt registriert werden. Zusätzlich dazu kann eine MEC-App 1526 einen oder mehrere Dienste 1530/1536 abonnieren, für die sie über den Mp1-Referenzpunkt autorisiert ist.
  • Beispiele für MEC-Dienste 1536 beinhalten den VIS, RNIS [R09], LS [R10], UE ID-Dienste [R11], BWMS [R12], WAIS, FAIS [R13] und/oder andere MEC-Dienste. Der RNIS stellt, wenn verfügbar, autorisierte MEC-Apps 1526 mit funknetzbezogenen Informationen bereit und legt den MEC-Anwendungen 1526 geeignete aktuelle Funknetzinformationen offen. Die RNI können unter anderem Funknetzbedingungen, Mess- und Statistikinformationen in Bezug auf die Benutzerebene, Informationen in Bezug auf UEs 1520, die durch den oder die Funkknoten bedient werden, die mit dem MEC-Host 1502 assoziiert sind (z. B. UE-Kontext und Funkzugangsträger), Änderungen an Informationen in Bezug auf UEs 1520, die durch den oder die Funkknoten bedient werden, die mit dem MEC-Host XE136 assoziiert sind, und/oder dergleichen beinhalten. Die RNI können mit der relevanten Granularität (z. B. pro UE 1520, pro Zelle, pro Zeitperiode) bereitgestellt werden.
  • Die Dienstkonsumenten (z. B. MEC-Anwendungen 1526, MEC-Plattform 1532 usw.) können mit dem RNIS über eine RNI-API kommunizieren, um Kontextinformationen von einem entsprechenden RAN zu erhalten. RNI können den Dienstkonsumenten über ein NAN (z. B. (R)AN-Knoten, RRH, AP usw.) bereitgestellt werden. Die RNI-API kann sowohl Abfrage- als auch Subskriptions(z. B. Pub/Sub)-basierte Mechanismen unterstützen, die über eine Repräsentationszustandstransfer(RESTful)-API oder über einen Nachrichtenbroker der MEC-Plattform 1532 (nicht gezeigt) verwendet werden. Eine MEC-App 1526 kann Informationen über einen Nachrichtenbroker über eine Transportinformationsabfrageprozedur abfragen, wobei die Transportinformationen der MEC-App 1526 über einen geeigneten Konfigurationsmechanismus vorab bereitgestellt werden können. Die verschiedenen Nachrichten, die über die RNI-API kommuniziert werden, können in XML, JSON, Protobuf oder einem anderen geeigneten Format vorliegen.
  • Der VIS stellt verschiedene V2X-Anwendungen einschließlich der fahrtbewussten QoS-Vorhersagen gemäß den verschiedenen hierin besprochenen Ausführungsformen bereit. Die RNI können von den MEC-Apps 1526 und der MEC-Plattform 1532 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen über Funkbedingungen basieren. Als ein Beispiel kann eine MEC-App 1526 RNI verwenden, um aktuelle Dienste, wie etwa Videodurchsatzempfehlung, zu optimieren. Bei der Durchsatzempfehlung kann eine Funkanalytik-MEC-App 1526 MEC-Dienste verwenden, um einem Backend-Videoserver eine Nahechtzeitangabe über den Durchsatz bereitzustellen, der an der Funk-DL-Schnittstelle zu einem nächsten Zeitpunkt voraussichtlich verfügbar ist. Die Durchsatzempfehlungs-Funkanalytikanwendung berechnet eine Durchsatzempfehlung basierend auf den erforderlichen Funknetzinformationen, die sie von einem Mehrfachzugriffs-Edge-Dienst erhält, der auf dem MEC-Server 1502 läuft. RNI können auch durch die MEC-Plattform 1532 verwendet werden, um die Mobilitätsprozeduren zu optimieren, die erforderlich sind, um Dienstkontinuität zu unterstützen, wie etwa wenn eine bestimmte MEC-App 1526 eine einzelne Information unter Verwendung eines einfachen Anforderung-Antwort-Modells anfordert (z. B. unter Verwendung von RESTful-Mechanismen), während andere MEC-Anwendungen 1526 mehrere unterschiedliche Benachrichtigungen bezüglich Informationsänderungen abonnieren (z. B. unter Verwendung eines Pub/Sub-Mechanismus und/oder Nachrichtenbroker-Mechanismus).
  • Der LS kann, wenn verfügbar, autorisierte MEC-Apps 1526 mit standortbezogenen Informationen versorgen und solche Informationen den MEC-Anwendungen 1526 offenlegen. Mit standortbezogenen Informationen führen die MEC-Plattform 1532 oder eine oder mehrere MEC-Anwendungen 1526 aktive Vorrichtungsstandortverfolgung, standortbasierte Diensteempfehlungen und/oder andere ähnliche Dienste durch. Der LS unterstützt den Standortabrufmechanismus, z. B. wird der Standort nur einmal für jede Standortinformationsanforderung gemeldet. Der LS unterstützt zum Beispiel einen Standortteilnehmermechanismus, wobei der Standort mehrere Male für jede Standortanforderung, periodisch oder basierend auf spezifischen Ereignissen, wie etwa Standortänderung, gemeldet werden kann. Die Standortinformationen können unter anderem den Standort spezifischer UEs 1520, die gegenwärtig von dem oder den Funkknoten bedient werden, die mit dem MEC-Server 1502 assoziiert sind, Informationen über den Standort sämtlicher UEs 1520, die aktuell von dem oder den Funkknoten bedient werden, die mit dem MEC-Server XE136 assoziiert sind, Informationen über den Standort einer gewissen Kategorie von UEs 1520, die gegenwärtig durch den oder die Funkknoten bedient werden, die mit dem MEC-Server XE136 assoziiert sind, eine Liste von UEs 1520 an einem bestimmten Standort, Informationen über den Standort sämtlicher Funkknoten, die gegenwärtig mit dem MEC-Host 1502 assoziiert sind, und/oder dergleichen beinhalten. Die Standortinformationen können in Form eines geografischen Standorts, einer GNSS-Koordinate (GNSS: Global Navigation Satellite Service), einer Zellenidentität (Zellen-ID) und/oder dergleichen vorliegen. Der LS ist über die API zugänglich, die in der Open-Mobile-Alliance(OMA)-Spezifikation „RESTful-Network API for Zonal Presence“ OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C definiert ist. Der Zonal-Presence-Dienst nutzt das Konzept einer „Zone“, wobei eine Zone verwendet werden kann, um alle Funkknoten, die mit einem MEC-Host 1502 assoziiert sind, oder eine Teilmenge davon, gemäß einem gewünschten Einsatz zu gruppieren. In dieser Hinsicht stellt die OMA-Zonal-Presence-API Mittel für MEC-Apps1526 bereit, um Informationen über eine Zone, die mit den Zonen assoziierten Zugangspunkte und die Benutzer, die mit den Zugangspunkten verbunden sind, abzurufen. Zusätzlich ermöglicht die OMA-Zonal-Presence-API, dass eine autorisierte Anwendung einen Benachrichtigungsmechanismus abonniert, wobei sie Benutzeraktivitäten innerhalb einer Zone meldet. Ein MEC-Server 1502 kann unter Verwendung der OMA-Zonal-Presence-API auf Standortinformationen oder Zonenpräsenzinformationen einzelner UEs 1520 zugreifen, um den relativen Standort oder die relativen Positionen der UEs 1520 zu identifizieren.
  • Der BWMS sorgt für die Zuweisung von Bandbreite zu einem gewissen Verkehr, der zu und von MEC-Apps 1526 geroutet wird, und spezifiziert statische/dynamische Aufwärts/Abwärts-Bandbreitenressourcen, einschließlich Bandbreitengröße und Bandbreitenpriorität. Die MEC-Apps 1526 können den BWMS verwenden, um Bandbreiteninformationen zu/von der MEC-Plattform 1532 zu aktualisieren/zu empfangen. Verschiedenen MEC-Apps 1526, die parallel auf demselben MEC-Server 1502 laufen, können spezifische statische, dynamische Aufwärts/Abwärts-Bandbreitenressourcen zugewiesen werden, einschließlich Bandbreitengröße und Bandbreitenpriorität. Der BWMS beinhaltet eine Bandbreitenverwaltungs(BWM)-API, um registrierten Anwendungen zu ermöglichen, sich statisch und/oder dynamisch für spezifische Bandbreitenzuweisungen pro Sitzung/Anwendung zu registrieren. Die BWM-API beinhaltet HTTP-Protokollbindungen für BWM-Funktionalität unter Verwendung von RESTful-Diensten oder einem anderen geeigneten API-Mechanismus.
  • Der Zweck des UE-Identitätsmerkmals besteht darin, UE-spezifische Verkehrsregeln in dem MEC-System 1500 zuzulassen. Wenn das MEC-System 1500 das UE-Identitätsmerkmal unterstützt, stellt die MEC-Plattform 1532 die Funktionalität (z. B. UE-Identität-API) für eine MEC-App 1526 bereit, um ein Tag, das ein UE 1520 repräsentiert, oder eine Liste von Tags, die jeweilige UEs 1520 repräsentieren, zu registrieren. Jedes Tag wird in ein spezifisches UE 1520 in dem System des MNO abgebildet und der MEC-Plattform 1532 werden die Abbildungsinformationen bereitgestellt. Die UE-Identität-Tag-Registrierung triggert die MEC-Plattform 1532 dazu, die entsprechende(n) Verkehrsregel(n) 1540, die mit dem Tag verknüpft sind, zu aktivieren. Die MEC-Plattform 1532 stellt auch die Funktionalität (z. B. UE-Identität-API) für eine MEC-App 1526 bereit, um eine Abmeldeprozedur aufzurufen, um die Verwendung der Verkehrsregel für diesen Benutzer zu deaktivieren oder anderweitig zu stoppen.
  • Der WAIS ist ein Dienst, der Dienstkonsumenten innerhalb des MEC-Systems 1500 mit WLAN-Zugriff in Zusammenhang stehende Informationen bereitstellt. Der WAIS steht für autorisierte MEC-Apps 1526 zur Verfügung und wird wie in [R03] spezifiziert über den Mp1-Referenzpunkt entdeckt. Die Granularität der WLAN-Zugriffsinformationen kann basierend auf Parametern, wie etwa Informationen pro Station, pro NAN/AP oder pro mehreren APs (Multi-AP), angepasst werden. Die WLAN-Zugangsinformationen können von den Dienstkonsumenten genutzt werden, um die bestehenden Dienste zu optimieren und neuartige Dienste bereitzustellen, die auf aktuellen Informationen von WLAN-APs basieren, möglicherweise kombiniert mit den Informationen wie RNI oder Festzugangsnetzwerkinformationen. Der WAIS definiert Protokolle, Datenmodelle und Schnittstellen in Form von RESTful-APIs. Informationen über die APs und Clientstationen können entweder durch Abfragen oder durch Subskribieren von Benachrichtigungen angefordert werden, die jeweils attributbasierte Filterung und Attributselektoren beinhalten.
  • FAIS ist ein Dienst, der Dienstkonsumenten innerhalb des MEC-SystemS 1500 Festzugangsnetzwerkinformationen (oder FAI) bereitstellt. Der FAIS steht für die autorisierten MEC-Apps 1526 zur Verfügung und wird über den Mp1-Referenzpunkt entdeckt. Der FAI kann durch die MEC-Apps 1526 und die MEC-Plattform 1532 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen von dem festen Zugang (z. B. NANs) basieren, möglicherweise kombiniert mit anderen Informationen, wie etwa RNI oder WLAN-Informationen von anderen Zugangstechnologien. Dienstkonsumenten interagieren mit dem FAIS über die FAI-API, um Kontextinformationen von dem Festzugangsnetzwerk zu erhalten. Sowohl die MEC-Apps 1526 als auch die MEC-Plattform 1532 können den FAIS konsumieren; und sowohl die MEC-Plattform 1532 als auch die MEC-Apps 1526 können die Anbieter des FAI sein. Die FAI-API unterstützt sowohl Abfragen als auch Subskriptionen (Pub/Sub-Mechanismus), die über die RESTful-API oder über alternative Transporte wie einen Nachrichtenbus verwendet werden. Alternative Transporte können auch verwendet werden.
  • Die MEC-Verwaltung umfasst MEC-Systemebenenverwaltung und MEC-Host-Ebenenverwaltung. Die MEC-Verwaltung umfasst den MEC-Plattform-Manager 1506 und den VI-Manager (VIM) 1508 und behandelt die Verwaltung der MEC-spezifischen Funktionalität eines bestimmten MEC-Servers 1502 und der darauf laufenden Anwendungen. Bei manchen Implementierungen können manche oder alle der Mehrfachzugriffs-Edge-Verwaltungskomponenten durch einen oder mehrere Server implementiert werden, die sich in einem oder mehreren Datenzentren befinden, und können Virtualisierungsinfrastruktur verwenden, die mit NFV-Infrastruktur verbunden ist, die zum Virtualisieren von NFs verwendet wird, oder dieselbe Hardware wie die NFV-Infrastruktur verwenden.
  • Der MEC-Plattform-Manager 1506 ist für das Verwalten des Lebenszyklus von Anwendungen verantwortlich, einschließlich Informieren des MEC-Orchestrators (MEC-O) 1510 über relevante anwendungsbezogene Ereignisse. Der MEC-Plattform-Manager 1506 kann der MEC-Plattform 1532 auch MEC-Plattformelementverwaltungsfunktionen 1544 bereitstellen, MEC-App-Regeln und -Anforderungen 1546 einschließlich Dienstautorisierungen, Verkehrsregeln, DNS-Konfiguration und Auflösung von Konflikten verwalten und MEC-App-Lebenszyklusverwaltung 1548 verwalten. Der MEC-Plattform-Manager 1506 kann auch virtualisierte Ressourcen, Fehlermeldungen und Leistungsfähigkeitsmessungen von dem VIM 1508 zur weiteren Verarbeitung empfangen. Der Mm5-Referenzpunkt zwischen dem MEC-Plattform-Manager 1506 und der MEC-Plattform 1532 wird verwendet, um Plattformkonfiguration, Konfiguration der MEC-Plattformelementverwaltung 1544, MEC-App-Regeln und -Anforderungen 1546, MEC-App-Lebenszyklusverwaltung 1548 und Verwaltung von Anwendungsverlagerung durchzuführen.
  • Der VIM 1508 kann eine Entität sein, die virtualisierte (Rechen-, Speicherungs- und Vernetzungs-) Ressourcen der VI 1522 zuweist, verwaltet und freigibt und die VI 1522 zur Ausführung eines Softwareabbilds vorbereitet. Dazu kann der VIM 1508 mit der VI 1522 über den Mm7-Referenzpunkt zwischen dem VIM 1508 und der VI 1522 kommunizieren. Das Vorbereiten der VI 1522 kann Konfigurieren der VI 1522 und Empfangen/Speichern des Softwareabbilds beinhalten. Wenn unterstützt, kann der VIM 1508 eine schnelle Bereitstellung von Anwendungen bereitstellen, wie etwa in „Openstack++ for Cloudlet Deployments“, verfügbar auf http://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf, beschrieben. Der VIM 1508 kann auch Leistungsfähigkeits- und Fehlerinformationen über die virtualisierten Ressourcen erfassen und melden und Anwendungsverlagerung durchführen, wenn es unterstützt wird. Zur Anwendungsverlagerung von/zu externen Cloud-Umgebungen kann der VIM 1508 mit einem externen Cloud-Manager interagieren, um die Anwendungsverlagerung durchzuführen, zum Beispiel unter Verwendung des in „Adaptive VM Handoff Across Cloudlets“ beschriebenen Mechanismus und/oder möglicherweise durch einen Proxy. Des Weiteren kann der VIM 1508 mit dem MEC-Plattform-Manager 1506 über den Mm6-Referenzpunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen zu verwalten, um zum Beispiel die Anwendungslebenszyklusverwaltung zu realisieren. Darüber hinaus kann der VIM 1508 mit dem MEC-O 1510 über den Mm4-Referenzpunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen des MEC-Servers 1502 zu verwalten und Anwendungsabbilder zu verwalten. Das Verwalten der virtualisierten Ressourcen kann Verfolgen verfügbarer Ressourcenkapazität usw. beinhalten.
  • Die MEC-Systemebenenverwaltung beinhaltet den MEC-O 1510, der einen Überblick über das gesamte MEC-System 1500 hat. Der MEC-O 1510 kann eine Gesamtansicht des MEC-Systems 1500 basierend auf eingesetzten MEC-Hosts 1502, verfügbaren Ressourcen, verfügbaren MEC-Diensten 1536 und Topologie beibehalten. Der Mm3-Referenzpunkt zwischen dem MEC-O 1510 und dem MEC-Plattformmanager 1506 kann für die Verwaltung des Anwendungslebenszyklus, der Anwendungsregeln und - anforderungen und das Verfolgen verfügbarer MEC-Dienste 1536 verwendet werden. Der MEC-O 1510 kann mit dem Benutzeranwendungslebenszyklysverwaltungsproxy (UALMP) 1514 über den Mm9-Referenzpunkt kommunizieren, um MEC-Apps 1526 zu verwalten, die von der UE-App 1518 angefordert werden.
  • Der MEC-O 1510 kann auch für das Eingliedern von Anwendungspaketen verantwortlich sein, einschließlich Überprüfen der Integrität und Authentizität der Pakete, Validieren von Anwendungsregeln und -anforderungen und erforderlichenfalls Anpassen derselben, um Betreiberrichtlinien zu erfüllen, Führen einer Aufzeichnung von eingegliederten Paketen und Vorbereiten des/der VIM(s) 1508 zum Handhaben der Anwendungen. Der MEC-O 1510 kann einen oder mehrere geeignete MEC-Host(s) 901 zur Anwendungsinstanziierung basierend auf Einschränkungen, wie etwa Latenz, verfügbaren Ressourcen und verfügbaren Diensten, auswählen. Der MEC-O 1510 kann auch Anwendungsinstanziierung und -beendigung auslösen sowie Anwendungsverlagerung nach Bedarf und bei Unterstützung auslösen.
  • Das Betriebsunterstützungssystem (OSS) 1512 ist das OSS eines Betreibers, der Anforderungen über das Customer-Facing-Service(CFS)-Portal 1516 über den Mx1-Referenzpunkt und von UE-Apps 1518 zur Instanziierung oder Beendigung von MEC-Apps 1526 empfängt. Das OSS 1512 entscheidet über die Gewährung dieser Anforderungen. Das CFS-Portal 1516 (und die Mx1-Schnittstelle) kann von Dritten verwendet werden, um das MEC-System 1500 aufzufordern, Apps 1518 in dem MEC-System 1500 auszuführen. Gewährte Anforderungen können an den MEC-O 1510 zur weiteren Verarbeitung weitergeleitet werden. Wenn unterstützt, empfängt der OSS 1512 auch Anforderungen von UE-Apps 1518 zum Verlagern von Anwendungen zwischen externen Clouds und dem MEC-System 1500. Der Mm2-Referenzpunkt zwischen dem OSS 1512 und dem MEC-Plattform-Manager 1506 wird zur Konfigurations-, Fehler- und Leistungsfähigkeitsverwaltung des MEC-Plattform-Managers 1506 verwendet. Der Mm1-Referenzpunkt zwischen dem MEC-O 1510 und dem OSS 1512 wird zum Auslösen der Instanziierung und der Beendigung von MEC-Apps 1526 in dem MEC-System 1500 verwendet.
  • Die UE-App(s) 1518 (auch als „Vorrichtungsanwendungen“ oder dergleichen bezeichnet) ist eine oder mehrere Apps, die auf einer Vorrichtung 1520 ausgeführt werden, die die Fähigkeit aufweist, mit dem MEC-System 1500 über den Benutzeranwendungslebenszyklusverwaltungsproxy 1514 zu interagieren. Die UE-App(s) 1518 kann/können eine oder mehrere Client-Anwendungen sein, beinhalten oder mit diesen interagieren, bei denen es sich im Kontext von MEC um Anwendungssoftware handelt, die auf der Vorrichtung 1518 läuft und Funktionalität nutzt, die durch eine oder mehrere spezifische MEC-Apps 1526 bereitgestellt wird. Der Benutzer-App-LCM-Proxy 1514 kann Anforderungen von UE-Apps 1518 in dem UE 1520 autorisieren und interagiert mit dem OSS 1512 und dem MEC-O 1510 zur weiteren Verarbeitung dieser Anforderungen. Der Begriff „Lebenszyklusverwaltung“ bezieht sich im Kontext von MEC auf einen Satz von Funktionen, die erforderlich sind, um die Instanziierung, Wartung und Beendigung einer MEC-App-1526-Instanz zu verwalten. Der Benutzer-App-LCM-Proxy 1514 kann über den Mm8-Referenzpunkt mit dem OSS 1512 interagieren und wird verwendet, um Anforderungen des UE 1518 zum Ausführen von Anwendungen in dem MEC-System 1500 zu handhaben. Eine Benutzer-App kann eine MEC-App 1526 sein, die in dem MEC-System 1500 als Reaktion auf eine Anforderung eines Benutzers über eine Anwendung, die auf dem UE 1520 läuft (z. B. UE-App 1518), instanziiert wird. Der Benutzer-App-LCM-Proxy 1514 ermöglicht es UE-Apps 1518, Eingliederung, Instanziierung, Beendigung von Benutzeranwendungen und, wenn unterstützt, Verlagerung von Benutzeranwendungen in das MEC-System 1500 hinein und aus diesem heraus anzufordern. Sie ermöglicht es auch, Benutzer-Apps über den Zustand der Benutzer-Apps zu informieren. Der Benutzer-App-LCM-Proxy 1514 ist nur von innerhalb des Mobilnetzwerks zugänglich und kann nur verfügbar sein, wenn er von dem MEC-System 1500 unterstützt wird. Eine UE-App 1518 kann den Mx2-Referenzpunkt zwischen dem Benutzer-App-LCM-Proxy 1514 und der UE-App 1518 verwenden, um das MEC-System 1500 aufzufordern, eine Anwendung in dem MEC-System 1500 auszuführen oder eine Anwendung in das MEC-System 1500 hinein oder aus diesem heraus zu verlagern. Der Mx2-Referenzpunkt kann nur innerhalb des Mobilnetzwerks zugänglich sein und kann nur verfügbar sein, wenn er durch das MEC-System 1500 unterstützt wird.
  • Um eine MEC-Anwendung 1526 in dem MEC-System 1500 auszuführen, empfängt der MEC-O 1510 Anforderungen, die durch das OSS 1512, einen Dritten oder eine UE-App 1518 ausgelöst werden. Als Reaktion auf den Empfang solcher Anforderungen wählt der MEC-O 1510 einen MEC-Server/Host 1502 aus, um die MEC-App 1526 zum rechnerischen Offloading usw. zu hosten. Diese Anforderungen können Informationen über die auszuführende Anwendung und möglicherweise andere Informationen, wie etwa den Standort, an dem die Anwendung aktiv sein muss, andere Anwendungsregeln und - anforderungen sowie den Standort des Anwendungsabbilds, falls es noch nicht in dem MEC-System 1500 eingegliedert ist, beinhalten.
  • Der MEC-O 1510 kann einen oder mehrere MEC-Server 1502 für rechenintensive Aufgaben auswählen. Der eine oder die mehreren ausgewählten MEC-Server XE136 können Rechenaufgaben einer UE-App 1518 basierend auf verschiedenen Betriebsparametern wie Netzwerkfähigkeiten und -bedingungen, Rechenfähigkeiten und - bedingungen, Anwendungsanforderungen und/oder anderen ähnlichen Betriebsparametern abladen. Die Anwendungsanforderungen können Regeln und Anforderungen sein, die mit einer oder mehreren MEC-Apps 1526 assoziiert sind, wie etwa ein Einsatzmodell der Anwendung (z. B. ob es eine Instanz pro Benutzer, eine Instanz pro Host, eine Instanz auf jedem Host usw. ist); erforderliche virtualisierte Ressourcen (z. B. Rechen-, Speicherungs-, Netzwerkressourcen, einschließlich spezifischer Hardwareunterstützung); Latenzanforderungen (z. B. maximale Latenz, wie streng die Latenzbeschränkungen sind, Latenzfairness zwischen Benutzern); Anforderungen hinsichtlich des Standorts; Mehrfachzugriff-Edge-Dienste, die erforderlich und/oder nützlich sind, damit die MEC-Apps 1526 ausgeführt werden können; Mehrfachzugriffs-Edge-Dienste, die MEC-Apps 1526 nutzen können, falls verfügbar; Konnektivität oder Mobilitätsunterstützung/- anforderungen (z. B. Anwendungszustandsverlagerung, Anwendungsinstanzverlagerung); erforderliche Mehrfachzugriffs-Edge-Merkmale, wie etwa VM-Verlagerungsunterstützung oder UE-Identität; erforderliche Netzwerkkonnektivität (z. B. Konnektivität mit Anwendungen innerhalb des MEC-Systems 1500, Konnektivität mit lokalen Netzwerken oder mit dem Internet); Informationen über den Einsatz des MEC-Systems 1500 oder den Einsatz des Mobilnetzwerks des Betreibers (z. B. Topologie, Kosten); Anforderungen hinsichtlich Zugriff auf Benutzerverkehr; Anforderungen hinsichtlich persistenter Speicherung; Verkehrsregeln 1540; DNS-Regeln 1542; usw.
  • Der MEC-0 1510 berücksichtigt die oben aufgelisteten Anforderungen und Informationen und Informationen über die aktuell im MEC-System 1500 verfügbaren Ressourcen, um einen oder mehrere MEC-Server 1502 zum Hosten von MEC-Apps 1526 und/oder zum rechnerischen Offloading auszuwählen. Nachdem ein oder mehrere MEC-Server XE136 ausgewählt wurden, fordert der MEC-0 1510 den oder die ausgewählten MEC-Hosts 1502 an, die Anwendung(en) oder Anwendungsaufgaben zu instanziieren. Der tatsächliche Algorithmus, der zum Auswählen der MEC-Server 1502 verwendet wird, hängt von der Implementierung, Konfiguration und/oder dem Betreibereinsatz ab. Der eine oder die mehreren Auswahlalgorithmen können auf den Aufgaben-Offloading-Kriterien/- parametern basieren, indem zum Beispiel Netzwerk-, Rechen- und Energieverbrauchsanforderungen zum Durchführen von Anwendungsaufgaben sowie Netzwerkfunktionalitäten, Verarbeitungs- und Offloading-Codierung/Codierungen berücksichtigt werden oder Verkehr zwischen verschiedenen RATs unterschieden wird. Unter gewissen Umständen (z. B. UE-Mobilitätsereignisse, die zu einer erhöhten Latenz führen, Lastausgleichsentscheidungen usw.), und falls unterstützt, kann der MEC-O 1510 entscheiden, einen oder mehrere neue MEC-Hosts 1502 auszuwählen, um als ein Master-Knoten zu fungieren, und initiiert die Übertragung einer Anwendungsinstanz oder anwendungsbezogener Zustandsinformationen von dem einen oder den mehreren Quellen-MEC-Hosts 1502 zu dem einen oder den mehreren Ziel-MEC-Hosts 1502.
  • Bei einer ersten Implementierung wird die UPF 1374 des 5G-Systems 1300 in die MEC-Architektur 1500 als die MEC-Datenebene 1524 abgebildet. Bei diesen Implementierungen behandelt die UPF 1374 den Benutzerebenenpfad von PDU-Sitzungen. Zusätzlich stellt UPF 1374 die Schnittstelle zu einem Datennetzwerk (z. B. DNs 1372, 1376) bereit und unterstützt die Funktionalität eines PDU-Sitzungsankers.
  • Bei einer zweiten Implementierung wird die AF 1364 des 5G-Systems 1300 in die MEC-Architektur 1500 als die MEC-Plattform 1532 abgebildet. Bei diesen Implementierungen ist die AF 1364 dazu konfigurierbar oder betreibbar, einen Anwendungseinfluss auf Verkehrsrouting, Zugangsnetzwerkfähigkeitsoffenlegung durchzuführen und mit dem Richtlinienframework zur Richtliniensteuerung zu interagieren. Die zweite Implementierung kann mit der ersten Implementierung kombiniert werden oder kann eine eigenständige Implementierung sein. Da Benutzerverkehr zu dem lokalen DN 1372 geleitet wird, können bei der ersten und/oder zweiten Implementierung MEC-Apps 1526, 1527 und/oder 1528 in oder auf das DN 1372 und/oder 1376 des 5G-Systems 1300 abgebildet werden.
  • Bei einer dritten Implementierung kann das RAN 1368 des 5G-Systems 1300 ein virtuelles RAN basierend auf einer VNF sein, und die UPF 1374 ist dazu konfigurierbar oder betreibbar, als die MEC-Datenebene 1524 innerhalb einer NF-Virtualisierungsinfrastruktur (NFVI) zu fungieren (z. B. VI 1522). Bei diesen Implementierungen kann die AF 1364 als MEC-Plattform-VNF (siehe z. B. Diskussion von 16, mit MEC-APIs, MEC-Anwendungsfreigabefunktionalität (siehe z. B. [R08]) und API-Prinzipienfunktionalität (siehe z. B. [R06]) konfiguriert sein. Zusätzlich dazu kann das lokale DN 1372 MEC-Apps 1526, 1527 und/oder 1528 beinhalten, die als VNFs instanziiert sind. Diese Implementierung kann dazu konfiguriert sein, Funktionalitäten gemäß [R05] und/oder ETSI GR MEC 017 VI. 1.1 (2018-02) („[R07]“) bereitzustellen. Die dritte Implementierung kann mit der ersten Implementierung und/oder der zweiten Implementierung kombiniert werden oder kann eine eigenständige Implementierung sein.
  • Zusätzlich oder alternativ dazu kann die Edge auf Zugriffsebene (z. B. die NANs 2128, 2130 und 2132 aus 21 und/oder die anderen NANs, die zuvor erörtert wurden) eine oder mehrere APIs verwenden, um mit Edge-Netzwerken auf lokaler/regionaler Ebene zu kommunizieren. Die Edge-Netzwerke auf lokaler/regionaler Ebene können Netzwerkknoten beinhalten, die entsprechende Anwendungen verwenden, um mit einem Edge-Netzwerk auf nationaler Ebene zu kommunizieren. Die Edge auf nationaler Ebene kann verschiedene NANs beinhalten, die Anwendungen zum Zugreifen auf eine oder mehrere Remote-Clouds innerhalb der Edge auf globaler Ebene verwenden. Die NANs sind auch für vertikale Segmentverwaltung und SLA-Einhaltung konfigurierbar oder betreibbar. Zusätzlich oder alternativ dazu kann MEC-Einsatz auf der Definition von „Edge“ basieren, NMOs Freiheitsgrade bereitzustellen, insbesondere wenn MEC in einer NFV-Umgebung eingesetzt wird (z. B. können MEC-Entitäten als virtualisierte NFs (VNFs) instanziiert werden, also mit hoher Flexibilität hinsichtlich des Einsatzes für den Betreiber).
  • Bei manchen Ausführungsformen kann das MEC-System 1500 flexibel in Abhängigkeit von dem Verwendungsfall/vertikalen Segment/zu verarbeitenden Informationen eingesetzt werden. Manche Komponenten des MEC-Systems 1500 können gemeinsam mit anderen Elementen des Systems angeordnet sein. Als ein Beispiel muss eine MEC-App 1526 in bestimmten Verwendungsfällen (z. B. Unternehmen) einen MEC-Dienst lokal verbrauchen, und es kann effizient sein, einen MEC-Host einzusetzen, der lokal mit dem benötigten Satz von APIs ausgestattet ist. Bei einem anderen Beispiel muss das Einsetzen eines MEC-Servers 1502 in einem Datenzentrum (das von dem Zugangsnetzwerk entfernt sein kann) möglicherweise nicht einige APIs hosten, wie etwa die RNI-API (die zum Sammeln von Funknetzinformationen von der Funkbasisstation verwendet werden kann). Andererseits können RNI-Informationen in den Cloud-RAN(CRAN)-Umgebungen an dem Aggregationspunkt entwickelt und bereitgestellt werden, wodurch die Ausführung geeigneter funkbewusster Verkehrsverwaltungsalgorithmen ermöglicht wird. Bei einigen anderen Aspekten kann eine Bandbreitenverwaltungs-API sowohl an der Edge auf Zugriffsebene als auch an entfernteren Edge-Orten vorhanden sein, um Transportnetzwerke (z. B. für CDN-basierte Dienste) einzurichten.
  • 16 veranschaulicht eine MEC-Referenzarchitektur 1600 in einer NFV-Umgebung. Die MEC-Architektur 1600 kann dazu ausgelegt sein, Funktionalitäten gemäß [R07] bereitzustellen. Die MEC-Architektur 1600 weist eine MEC-Plattform 1602, eine MEC-Plattform-Manager-NFV (MEPM-V) 1614, eine Datenebene 1608, eine NFV-Infrastruktur (NFVI) 1610, VNF-Manager (VNFMs) 1620 und 1622, NFV-Orchestrator (NFVO) 1624, einen MEC-App-Orchestrator (MEAO) 1626, einen OSS 1628, einen Benutzer-App-LCM-Proxy 1630, eine UE-App 1634 und ein CFS-Portal 1632 auf. Der MEC-Plattform-Manager 1614 kann eine MEC-Plattformelementverwaltung 1616 und eine MEC-App-Regel- und -Anforderungsverwaltung 1618 beinhalten. Die MEC-Plattform 1602 kann über eine MP3-Schnittstelle mit einer anderen MEC-Plattform 1606 gekoppelt sein.
  • Bei diesen Ausführungsformen wird die MEC-Plattform 1602 als eine VNF eingesetzt. Die MEC-Anwendungen 1604 können gegenüber den ETSI-NFV-Verwaltungs- und -Orchestrierungs(MANO)-Komponenten wie VNFs wirken. Dies ermöglicht eine Wiederverwendung von ETSI-NFV-MANO-Funktionalität. Der gesamte Satz an MANO-Funktionalität kann ungenutzt sein und es kann eine gewisse zusätzliche Funktionalität benötigt werden. Eine solche spezifische MEC-App wird als „MEC-App-VNF“ oder „MEA-VNF“ bezeichnet. Die Virtualisierungsinfrastruktur wird als eine NFVI 1610 eingesetzt und ihre virtualisierten Ressourcen werden durch den Virtualisierungsinfrastruktur-Manager (VIM) 1612 verwaltet. Dazu können eine oder mehrere der durch ETSI-NFV-Infrastrukturspezifikationen definierten Prozeduren verwendet werden (siehe z. B. ETSI GS NFV-INF 003 V2.4.1 (2018-02), ETSI GS NFV-INF 004 V2.4.1 (2018-02), ETSI GS NFV-INF 005 V3.2.1 (2019-04), und ETSI GS NFV-IFA 009 V1.1.1 (2016-07) (zusammen „[R31]“). Die MEA-VNF 1604 werden wie einzelne VNFs verwaltet, was ermöglicht, dass ein MEC-in-NFV-Einsatz bestimmte Orchestrierungs- und LCM-Aufgaben an den NFVO 1624 und die VNFMs 1620 und 1622 delegieren kann, wie durch ETSI-NFV-MANO definiert.
  • Wenn eine MEC-Plattform als eine VNF (z. B. MEC-Plattform-VNF 1602) implementiert ist, kann die MEPM-V 1614 dazu konfiguriert sein, als ein Element-Manager (EM) zu fungieren. Der MEAO 1626 verwendet den NFVO 1624 zur Ressourcenorchestrierung und zur Orchestrierung des Satzes von MEA-VNFs 1604 als einen oder mehrere NFV-Netzwerkdienste (NSs). Die MEPM-V 1614 delegiert den LCM-Teil an einen oder mehrere VNFMs 1620 und 1622. Ein spezieller oder generischer VNFM 1620, 1622 wird/werden verwendet, um LCM durchzuführen. Die MEPM-V 1614 und der VNFM (ME-Plattform-LCM) 1620 können als ein einziges Paket gemäß dem Ensemblekonzept in 3GPP TR 32.842 v13.1.0 (2015-12-21) („[R32]“) eingesetzt werden, oder dass der VNFM ein generischer VNFM gemäß [R31] ist und die MEC-Plattform-VNF 1602 und die MEPM-V 1614 von einem einzigen Anbieter bereitgestellt werden.
  • Der Mp1-Referenzpunkt zwischen einer MEC-App 1604 und der MEC-Plattform 1614 kann für die MEC-App 1604 optional sein, es sei denn, es handelt sich um eine Anwendung, die einen MEC-Dienst bereitstellt und/oder konsumiert. Der Mm3*-Referenzpunkt zwischen MEAO 1626 und der MEPM-V 1614 basiert auf dem Mm3-Referenzpunkt (siehe z. B. [R05]). Änderungen können zu diesem Referenzpunkt konfiguriert werden, um für die Aufteilung zwischen MEPM-V 1614 und VNFM (ME-Anwendungs-LCM) 1622 zu sorgen. Die folgenden neuen Referenzpunkte (Mv1, Mv2 und Mv3) werden zwischen Elementen der ETSI-MEC-Architektur und der ETSI-NFV-Architektur eingeführt, um die Verwaltung von ME-App-VNFs 1604 zu unterstützen.
  • Die folgenden Referenzpunkte beziehen sich auf existierende NFV-Referenzpunkte, aber nur eine Teilmenge der Funktionalität kann für ETSI-MEC verwendet werden und Erweiterungen können notwendig sein. Mv1 ist ein Referenzpunkt, der den MEAO 1626 und den NFVO 1624 verbindet, und bezieht sich auf den Os-Ma-nfvo-Referenzpunkt, wie in ETSI NFV definiert. Mv2 ist ein Referenzpunkt, der den VNFM 1622, der das LCM der MEC-App-VNFs 1604 durchführt, mit der MEPM-V 1614 verbindet, um zu ermöglichen, dass LCM-bezogene Benachrichtigungen zwischen diesen Entitäten ausgetauscht werden. Mv2 bezieht sich auf den Ve-Vnfm-em-Referenzpunkt, wie in ETSI NFV definiert, kann aber möglicherweise Ergänzungen beinhalten und möglicherweise nicht alle Funktionalität verwenden, die von dem Ve-Vnfm-em angeboten wird. Mv3 ist ein Referenzpunkt, der den VNFM 1622 mit der ME-App-VNF-1604-Instanz verbindet, um den Austausch von Nachrichten (z. B. bezogen auf MEC-App-LCM oder anfängliche einsatzspezifische Konfiguration) zu ermöglichen. Mv3 bezieht sich auf den Ve-Vnfm-vnf-Referenzpunkt, wie in ETSI NFV definiert, kann aber Ergänzungen beinhalten und möglicherweise nicht alle Funktionalität verwenden, die von Ve-Vnfm-vnf angeboten wird.
  • Folgende Referenzpunkte werden verwendet, wie sie durch ETSI NFV definiert sind: Nf-Vn-Referenzpunkt verbindet jede ME-App-VNF 1604 mit der NFVI 1610. DerNf-Vi-Referenzpunkt verbindet die NFVI 1610 und den VIM 1612. Der Os-Ma-nfvo-Referenzpunkt verbindet den OSS 1628 und den NFVO 1624 und wird hauptsächlich verwendet, um NSs zu verwalten (z. B. eine Anzahl von VNFs, die verbunden und orchestriert sind, um einen Dienst zu liefern). Der Or-Vnfm-Referenzpunkt verbindet den NFVO 1624 und den VNFM (MEC-Plattform-LCM) 1620 und wird hauptsächlich für den NFVO 1624 verwendet, um VNF-LCM-Operationen aufzurufen. Vi-Vnfm-Referenzpunkt verbindet den VIM 1612 und den VNFM (MEC-Plattform-LCM) 1620 und wird primär von dem VNFM 1620 verwendet, um Ressourcenverwaltungsoperationen aufzurufen, um Cloud-Ressourcen zu verwalten, die von der VNF benötigt werden (bei NFV-basiertem MEC-Einsatz wird angenommen, dass dieser Referenzpunkt 1:1 Mm6 entspricht). Der Or-Vi-Referenzpunkt verbindet den NFVO 1624 und den VIM 1612 und wird primär von dem NFVO 1624 verwendet, um Cloud-Ressourcenkapazität zu verwalten. Der Ve-Vnfm-em-Referenzpunkt verbindet den VNFM (MEC-Plattform-LCM) 1620 mit der MEPM-V 1614. Der Ve-Vnfm-vnf-Referenzpunkt verbindet den VNFM (MEC-Plattform-LCM) 1620 mit der MEC-Plattform-VNF 1602.
  • III.C. HARDWAREKOMPONENTEN
  • 17A veranschaulicht eine erste Edge-Computing-Hardwarekonfiguration, die verschiedene Architekturaspekte einer Edge-Plattform 1710 (z. B. Rechenhardware, Netzwerkmerkmale, Leistungsverwaltungsmerkmale usw.) auf spezifische Edge-Plattformfähigkeiten 1720 (z. B. E/A-Pooling, Beschleunigungspooling, Speicherpooling, Beschleunigungstechnologien, Speicherfähigkeiten) abbildet. Um die Edge-Konfiguration als eine Gesamtlösung für Dienste anzubieten, werden die Arbeitslasten oder Basishardwarekomponenten für Dienste und Dienstanforderungen/-einschränkungen (z. B. Netzwerk und E/A, Plattformbeschleunigung, Leistung) angesichts verfügbarer Architekturaspekte (z. B. Pooling, Speicherung usw.) betrachtet.
  • Innerhalb der Edge-Plattformfähigkeiten 1720 können spezifische Beschleunigungstypen konfiguriert oder identifiziert werden, um sicherzustellen, dass die Dienstdichte über die Edge-Cloud hinweg erfüllt ist. Insbesondere können vier primäre Beschleunigungstypen in einer Edge-Cloud-Konfiguration eingesetzt werden: (1) Allgemeine Beschleunigung (z. B. FPGAs) zum Implementieren von Basisblöcken, wie etwa einer schnellen Fouriertransformation (FFT), einem k-Nearest-Neighbors-Algorithmus (KNN) und Maschinenlernarbeitslasten; (2) Bild-, Video- und Transcodierungsbeschleuniger; (3) Inferenzbeschleuniger; (4) krypto- und kompressionsbezogene Arbeitslasten (implementiert wie in Intel® QuickAssist™-Technologie). Somit kann die spezielle Gestaltung oder Konfiguration der Edge-Plattformfähigkeiten 1720 berücksichtigen, welches der richtige Typ von Beschleunigungs- und Plattformproduktmodellen ist, der ausgewählt werden muss, um die Dienst- und Durchsatzdichte sowie verfügbare Leistung zu gewährleisten.
  • 17B veranschaulicht eine zweite Edge-Computing-Hardwarekonfiguration, die eine zweite Edge-Plattform 1730 mit einem zweiten Satz von Edge-Plattform-Fähigkeiten 1740 bietet. Diese Konfiguration kann als eine Lösung mit niedriger Leistung aber höherer Dienstdichte einsetzbar sein. Dieser Ansatz zielt darauf ab, eine Lösung mit niedrigerer Leistung zu definieren, die Beschleunigungsschemata verwendet, um eine bessere Dienstdichte oder einen besseren Dienstdurchsatz pro Watt zu erreichen. Dieser Hauptdesignkompromiss führt zu einer Plattform, die allgemeine Berechnung zugunsten spezialisierter Hardware (z. B. FPGAs, Inferenzbeschleuniger) verwendet opfert, die die gleiche Arbeit mit einem besseren Leistungsfähigkeit-Pro-Watt-Verhältnis durchführen kann. In diesem Beispiel ermöglicht eine „dienstdichte“ Lösung mehr Dienstaktionen pro Plattform und pro Watt oder kann mehr Durchsatz pro Watt auf Dienstebene treiben.
  • Die Plattformfähigkeiten 1740 können so gestaltet sein, dass sie sowohl hinsichtlich der Leistungseinhüllenden als auch hinsichtlich des physischen Raums günstig sind. Infolgedessen kann die Konfiguration von 17B ein geeignetes Ziel für Basisstationseinsätze bereitstellen. Die Plattformfähigkeiten 1740 können jedoch Kompromisse aufweisen, darunter: (1) Anforderungen hinsichtlich Orchestrierung, Wartung und Systemverwaltung (die in OPEX/TCO-Kosten umgesetzt werden können); (2) Erfordern eines Betreiberökosystems, um zu ermöglichen, dass alle Systemstapel mit unterschiedlichen Beschleunigern zu arbeiten, die offengelegt sind. Diese Nachteile können jedoch mit einer entwickelten Softwareabstraktionsschicht abgeschwächt werden.
  • 17C veranschaulicht eine dritte Edge-Computing-Hardwarekonfiguration, die eine dritte Edge-Plattform 1750 mit einem zweiten Satz von Edge-Plattform-Fähigkeiten 1760 anbietet. Diese Konfiguration bietet eine leistungsstarke und dennoch homogene und generische Architektur. 17C stellt einen Ansatz bereit, der im Vergleich zu 17B entgegengesetzt ist, um eine Plattformarchitektur mit reduzierter Heterogenität in den verschiedenen Ressourcenarten bereitzustellen, mit denen ein Betreiber oder Edge-Eigentümer in Bezug auf Verwaltung, Wartung und Orchestrierung umgehen muss. Das Entfernen von Beschleunigern zugunsten der Homogenität geht jedoch auf Kosten einer geringeren Dienstdichte und eines geringeren Dienstdurchsatzes pro Watt auf Plattformebene. Bei weiteren Beispielen können die Edge-Plattformfähigkeiten 1760 eine Allzweckbeschleunigung implementieren (wie etwa in der Form von FPGAs).
  • Weitere Ableitungsfunktionen der in den 17A-C gezeigten Edge-Plattformen können auch angepasst werden. Beispielsweise kann die Plattform dahingehend dimensioniert und ausgestaltet sein, neue Bestandteile einzuarbeiten, die sie dienst- und durchsatzdichter machen, aber homogener halten, indem sie beispielsweise Beschleuniger innerhalb der Plattform oder auf dem Die enthalten, um sie für die Betreiber nahtlos verwaltbar zu machen.
  • 18 und 19 stellen weitere Beispiele für Edge-Computing-Systeme und -Umgebungen dar, die beliebige der hier besprochenen Rechenknoten oder Vorrichtungen erfüllen können. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, der/die/das in der Lage ist, mit anderen Edge-, Vernetzungs- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System umgesetzt sein, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen.
  • In 18 weist ein Edge-Rechenknoten 1800 eine Rechen-Engine (hier auch als „Rechenschaltungsanordnung“ bezeichnet) 1802, ein Eingabe/Ausgabe(E/A)-Subsystem 1808, eine Datenspeicherung 1810, ein Kommunikationsschaltungsanordnungs-Subsystem 1812 und optional eine oder mehrere Peripherievorrichtungen 1814 auf. Bei anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Komponenten beinhalten, wie etwa jene, die typischerweise in einem Computer zu finden sind (z. B. eine Anzeige, Peripherievorrichtungen usw.). Zusätzlich dazu können bei manchen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderweitig einen Teil davon bilden.
  • Der Rechenknoten 1800 kann als ein beliebiger Typ von Engine, Vorrichtung, oder Sammlung von Vorrichtungen ausgeführt sein, die zum Durchführen verschiedener Rechenfunktionen in der Lage ist. Bei manchen Beispielen kann der Rechenknoten 1800 als eine einzelne Vorrichtung umgesetzt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein FPGA, ein System-on-Chip (SoC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. Der Rechenknoten 1800 weist einen Prozessor 1804 und einen Speicher 1806 auf oder ist als dieser umgesetzt. Der Prozessor 1804 kann als ein beliebiger Typ von Prozessor umgesetzt sein, der die hierin beschriebenen Funktionen (z. B. Ausführen einer Anwendung) durchführen kann. Der Prozessor 1804 kann zum Beispiel als (ein) Mehrkernprozessor(en), ein Mikrocontroller oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung umgesetzt sein. Bei einigen Beispielen kann der Prozessor 1804 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), eine rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder eine andere spezialisierte Hardware umgesetzt sein, diese enthalten oder an diese gekoppelt sein, um eine Durchführung der hierin beschriebenen Funktionen zu ermöglichen.
  • Der Hauptspeicher 1806 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder Datenspeicherung ausgeführt sein, der/die dazu in der Lage ist, die hier beschriebenen Funktionen durchzuführen. Ein flüchtiger Speicher kann ein Speicherungsmedium sein, das Leistung zum Aufrechterhalten des Zustands von durch das Medium gespeicherten Daten benötigt. Nichtbeschränkende Beispiele für flüchtigen Speicher können verschiedene Typen von Direktzugriffsspeicher (RAM), wie etwa DRAM oder statischen Direktzugriffsspeicher (SRAM), einschließen. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
  • Bei einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie etwa jene auf NAND- oder NOR-Technologien basierte. Eine Speichervorrichtung kann auch eine dreidimensionale Koppelpunktspeichervorrichtung (z. B. Intel® 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Speichervorrichtungen zum Schreiben an Ort und Stelle beinhalten. Die Speichervorrichtung kann sich auf den Die selbst und/oder auf ein gehäustes Speicherprodukt beziehen. Bei einigen Beispielen kann der 3D-Koppelpunktspeicher (z. B. Intel® 3D XPoint™-Speicher) eine transistorlose stapelbare Koppelpunkt-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und individuell adressierbar sind, und bei der eine Bitspeicherung auf einer Änderung des Bulkwiderstands basiert. Bei manchen Beispielen kann der gesamte oder ein Teil des Hauptspeichers 1806 in dem Prozessor 1804 integriert sein. Der Hauptspeicher 1806 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie beispielsweise eine oder mehrere Anwendungen, Daten, die von der (den) Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
  • Die Rechenschaltungsanordnung 1802 ist über das E/A-Subsystem 1808, das als eine Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, kommunikativ mit anderen Komponenten des Rechenknotens 1800 gekoppelt, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 1802 (z. B. mit dem Prozessor 1804 und/oder dem Hauptspeicher 1806) und anderen Komponenten der Rechenschaltungsanordnung 1802 zu ermöglichen. Das E/A-Subsystem 1808 kann zum Beispiel als Speichersteuerungs-Hubs, Eingabe/Ausgabe-Steuerungs-Hubs, integrierte Sensor-Hubs, Firmwarevorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Subsysteme umgesetzt sein oder diese anderweitig beinhalten, um die Eingabe/Ausgabe-Operationen zu ermöglichen. Bei manchen Beispielen kann das E/A-Subsystem 1808 einen Teil eines System-On-a-Chip (SoC) bilden und zusammen mit dem Prozessor 1804, dem Hauptspeicher 1806 und/oder anderen Komponenten der Rechenschaltungsanordnung 1802 in der Rechen-Engine 1802 eingebunden sein.
  • Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen 1810 können als eine beliebige Art von Vorrichtungen umgesetzt sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert sind, wie zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeicherungsvorrichtungen. Individuelle Datenspeicherungsvorrichtungen 1810 können eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung 1810 speichert. Individuelle Datenspeicherungsvorrichtungen 1810 können auch eine oder mehrere Betriebssystempartitionen beinhalten, die Dateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel dem Typ des Rechenknotens 1800 speichern.
  • Die Kommunikationsschaltungsanordnung 1812 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder Sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 1802 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway-Knoten oder dergleichen) zu ermöglichen. Die Kommunikationsschaltungsanordnung 1812 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechniken (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein zelluläres Vernetzungsprotokoll, wie etwa einen 3GPP-4G- oder 5G-Standard, ein Wireless-Local-Area-Network-Protokoll, wie etwa IEEE 802.11/Wi-Fi®, ein Wireless-Wide-Area-Network-Protokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, Low-Power-Wide-Area-Network(LPWAN)- oder Low-Power-Wide-Area(LPWA)-Protokolle usw.), um eine solche Kommunikation zu umzusetzen.
  • Die veranschaulichende Kommunikationsschaltungsanordnung 1812 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 1820, die auch als eine Host-Fabric-Schnittstelle (HFI: Host Fabric Interface) bezeichnet werden kann. Die NIC 1820 kann als ein oder mehrere Add-In-Boards, Tochterplatinen, Netzwerkkarten, Steuerungschips, Chipsätze oder andere Vorrichtungen umgesetzt sein, die durch den Rechenknoten 1800 verwendet werden können, um eine Verbindung mit einer anderen Rechenvorrichtung herzustellen. Bei manchen Beispielen kann die NIC 1820 als Teil eines System-on-a-Chip (SoC) umgesetzt sein, das einen oder mehrere Prozessoren beinhaltet, oder auf einem Mehrchip-Package enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. Bei manchen Beispielen kann die NIC 1820 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide lokal zur NIC 1820 sind. Bei derartigen Beispielen kann der lokale Prozessor der NIC 1820 fähig sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltungsanordnung 1802 durchzuführen. Zusätzlich oder alternativ dazu kann bei solchen Beispielen der lokale Speicher der NIC 1820 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
  • Zusätzlich kann bei manchen Beispielen ein jeweiliger Rechenknoten 1800 eine oder mehrere Peripherievorrichtungen 1814 beinhalten. Solche Peripherievorrichtungen 1814 können eine beliebige Art von Peripherievorrichtung beinhalten, die in einer Rechenvorrichtung oder einem Server zu finden ist, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe/Ausgabe-Vorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 1800. Bei weiteren Beispielen kann der Rechenknoten 1800 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Computing-System (z. B. Client-Rechenknoten, Edge-Gateway-Knoten, Edge-Aggregationsknoten, zuvor besprochene vUEs usw.) oder ähnliche Formen von Geräten, Computern, Subsystemen, Schaltungsanordnungen oder anderen Komponenten umgesetzt sein.
  • 19 veranschaulicht ein Beispiel für Komponenten, die in einem Edge-Computing-Knoten 1950 zum Implementieren der hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methoden) vorhanden sein können. Dieser Edge-Computing-Knoten 1950 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 1900 bereit, wenn er als oder als Teil einer Rechenvorrichtung (z. B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert wird. Der Edge-Computing-Knoten 1950 kann beliebige Kombinationen der hier referenzierten Hardware oder logischen Komponenten beinhalten, und er kann eine beliebige Vorrichtung beinhalten oder mit dieser gekoppelt sein, die mit einem Edge-Kandkommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendbar ist. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 1950 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems integriert sind, implementiert sein.
  • Der Edge-Computing-Knoten 1950 weist eine Verarbeitungsschaltungsanordnung in Form eines oder mehrerer Prozessoren 1852 auf. Die Prozessorschaltungsanordnung 1952 beinhaltet eine Schaltungsanordnung, wie etwa unter anderem einen oder mehrere Prozessorkerne und eines oder mehrere von Cache-Speicher, Low-Drop-Out-Spannungsreglern (LDOs), Interrupt-Steuerungen, seriellen Schnittstellen, wie etwa SPI, I2C oder universelle programmierbare serielle Schnittstellenschaltung, Echtzeituhr (RTC), Timer-Zähler einschließlich Intervall- und Watchdog-Timern, Allzweck-E/A, Speicherkartensteuerungen, wie etwa Secure Digital/Multimedia Card (SD/MMC) oder dergleichen, Schnittstellen, Mobile-Industry-Processor-Interface(MIPI)-Schnittstellen und Joint-Test-Access-Group(JTAG)-Testzugangsports. Bei manchen Implementierungen kann die Prozessorschaltungsanordnung 1952 einen oder mehrere Hardwarebeschleuniger (z. B. gleich oder ähnlich der Beschleunigungsschaltungsanordnung 1964) beinhalten, die Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen (z. B. FPGA, ASIC usw.) oder dergleichen sein können. Der eine oder die mehreren Beschleuniger können zum Beispiel Computervision- und/oder Deep-Learning-Beschleuniger beinhalten. Bei manchen Implementierungen kann die Prozessorschaltungsanordnung 1952 eine On-Chip-Speicherschaltungsanordnung beinhalten, die einen beliebigen geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flash-Speicher, Festkörperspeicher und/oder einen beliebigen anderen Typ von Speichervorrichtungstechnologie, wie etwa jene hierin besprochenen, beinhalten kann.
  • Die Prozessorschaltungsanordnung 1952 kann zum Beispiel einen oder mehrere Prozessorkerne (CPUs), Anwendungsprozessoren, GPUs, RISC-Prozessoren, Acorn-RISC-Machine(ARM)-Prozessoren, CISC-Prozessoren, einen oder mehrere DSPs, ein oder mehrere FPGAs, eine oder mehrere PLDs, einen oder mehrere ASICs, einen oder mehrere Basisbandprozessoren, eine oder mehrere integrierte Hochfrequenzschaltungen (RFIC), einen oder mehrere Mikroprozessoren oder -steuerungen, einen Mehrkernprozessor, einen Multithread-Prozessor, einen Ultra-Low-Voltage-Prozessor, einen eingebetteten Prozessor oder beliebige andere bekannte Verarbeitungselemente oder eine beliebige geeignete Kombination davon beinhalten. Die Prozessoren (oder Kerne) 1952 können mit Speicher/Speicherung gekoppelt sein oder diese beinhalten und können dazu konfiguriert sein, Anweisungen auszuführen, die in dem Speicher/der Speicherung gespeichert sind, um zu ermöglichen, dass verschiedene Anwendungen oder Betriebssysteme auf der Plattform 1950 ausgeführt werden. Der Prozessor (oder die Kerne) 1952 ist dazu ausgelegt, Anwendungssoftware zu betreiben, um einem Benutzer der Plattform 1950 einen spezifischen Dienst bereitzustellen. Bei manchen Ausführungsformen können der eine oder die mehreren Prozessoren 1952 Spezialprozessor(en)/-steuerung(en) sein, der (die) dazu konfiguriert (oder konfigurierbar) ist (sind), gemäß den verschiedenen Ausführungsformen hierin zu arbeiten.
  • Als Beispiele können der eine oder die mehreren Prozessoren 1952 einen Intel® Architecture Core™-basierten Prozessor, wie etwa einen i3-, einen i5-, einen i7-, einen i9-basierten Prozessor; einen Intel® Mikrocontroller-basierten Prozessor, wie etwa einen Quark™, einen Atom™ oder einen anderen MCU-basierten Prozessor; einen oder mehrere Pentium®-Prozessoren, Xeon®-Prozessoren oder einen anderen solchen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie eine oder mehrere von Advanced Micro Devices (AMD)-Zen®-Architektur, wie Ryzen®- oder EPYC®-Prozessor(en), beschleunigte Verarbeitungseinheiten (APUs), 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)™-Prozessor(en); ein MIPS-basiertes Design von MIPS Technologies, Inc. wie MIPS Warrior M-Klasse, Warrior I-Klasse und Warrior P-Klasse-Prozessoren; ein ARM-basiertes Design, lizenziert von ARM Holdings, Ltd., wie die ARM Cortex-A, Cortex-R und Cortex-M-Prozessorfamilie; das von Cavium™, Inc. bereitgestellte ThunderX2®; oder dergleichen. Bei manchen Implementierungen können der eine oder die mehreren Prozessoren 1952 ein Teil eines System-on-a-Chip (SoC), System-in-Package (SiP), eines Multi-Chip-Package (MCP) und/oder dergleichen sein, in dem der eine oder die mehreren Prozessoren 1952 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Package ausgebildet sind, wie etwa den Edison™- oder Galileo™-SoC-Platinen von der Intel® Corporation. Andere Beispiele für den einen oder die mehreren Prozessoren 1952 sind an anderer Stelle der vorliegenden Offenbarung erwähnt.
  • Der eine oder die mehreren Prozessoren 1952 können über einen Interconnect (IX) 1956 mit dem Systemspeicher 1954 kommunizieren. Eine beliebige Anzahl an Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder Mobil-DDDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). Bei bestimmten Beispielen kann eine Speicherkomponente einem durch JEDEC veröffentlichten DRAM-Standard entsprechen, wie etwa ESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low-Power-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3, und JESD209-4 für LPDDR4. Andere RAM-Typen, wie etwa dynamischer RAM (DRAM), synchroner DRAM (SDRAM) und/oder dergleichen, können ebenfalls enthalten sein. Solche Standards (und ähnliche Standards) können als DDRbasierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die solche Standards implementieren, können als DDRbasierte Schnittstellen bezeichnet werden. Bei diversen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von verschiedenen Package-Typen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (QDP). Diese Vorrichtungen können bei manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual Inline Memory Modules (DIMMs) verschiedener Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
  • Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann eine Speicherung 1958 auch über das IX 1956 mit dem Prozessor 1952 gekoppelt sein. Bei einem Beispiel kann die Speicherung 1958 über ein Festkörperplattenlaufwerk (SSDD) und/oder einen elektrisch löschbaren Hochgeschwindigkeitsspeicher (allgemein als „Flash-Speicher“ bezeichnet) implementiert werden. Andere Vorrichtungen, die für die Speicherung 1958 verwendet werden können, umfassen Flash-Speicherkarten, wie etwa SD-Karten, MicroSD-Karten, XD-Bildkarten und dergleichen und USB-Flash-Laufwerke. In einem Beispiel kann die Speichervorrichtung eine Speichervorrichtung sein oder umfassen, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Phasenwechselspeicher mit einer oder mehreren Ebenen (PCM), einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristor-Technologie umfasst, Phasenwechsel-RAM (PRAM), resistiven Speicher auf Metalloxidbasis, Sauerstoffleerstellenbasis und Conductive-Brige-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque(STT)-MRAM, eine Vorrichtung auf der Basis eines Spintronik-Speichers mit magnetischem Übergang, eine Vorrichtung auf der Basis eines magnetischen Tunnelübergangs (MTJ - Magnetic Tunneling Junction), eine Vorrichtung auf Domänenwand- und SOT(Spin Orbit Transfer)-Basis, eine Speichervorrichtung Thyristorbasis oder eine Kombination beliebiger der obigen oder anderen Speicher einsetzt. Die Speicherschaltungsanordnung 1954 und/oder die Speicherschaltungsanordnung 1958 können auch dreidimensionale (3D) Crosspoint(XPOINT)-Speicher von Intel® und Micron® beinhalten.
  • In Niederleistungsimplementierungen kann die Speicherung 1958 ein On-Die-Speicher oder -Register sein, der/das mit dem Prozessor 1952 assoziiert ist. Bei manchen Beispielen kann die Speicherung 1858 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (Mikro-HDD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 1958 zusätzlich zu den, oder anstelle der, beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
  • Die Komponenten der Edge-Computing-Vorrichtung 1950 können über das IX 1956 kommunizieren. Das IX 1956 kann eine beliebige Anzahl von Technologien beinhalten, darunter ISA, erweiterte ISA, I2C, SPI, Punkt-zu-Punkt-Schnittstellen, Leistungsmanagementbus (PMBus), PCI, PCIe, PCIx, Intel® UPI, Intel® Accelerator Link, Intel® CXL, CAPI, OpenCAPI, Intel® QPI, UPI, Intel® OPA IX, RapidIO™-System-IXs, CCIX, Gen-Z-Consortium-IXs, ein HyperTransport-Interconnect, NVLink von NVIDIA®, ein Time-Trigger-Protocol(TTP)-System, ein FlexRay-System, PROFIBUS und/oder eine beliebige Anzahl anderer IX-Technologien. Das IX 1956 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
  • Das IX 1956 koppelt den Prozessor 1952 mit einer Kommunikationsschaltungsanordnung 1966 zur Kommunikation mit anderen Vorrichtungen, wie etwa einem Fernserver (nicht gezeigt) und/oder den verbundenen Edge-Vorrichtungen 1962. Die Kommunikationsschaltungsanordnung 1966 ist ein Hardwareelement oder eine Sammlung von Hardwareelementen, das/die zum Kommunizieren über ein oder mehrere Netzwerke (z. B. Cloud 1963) und/oder mit anderen Vorrichtungen (z. B. Edge-Vorrichtungen 1962) verwendet wird/werden.
  • Der Sendeempfänger 1966 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z. B. unter anderem 2,4-Gigahertz(GHz)-Übertragungen nach dem IEEE-802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy(BLE)-Standards, wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 1962 verwendet werden. Zum Beispiel kann eine Wireless-Local-Area-Network(WLAN)-Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronic Engineers (IEEE) zu implementieren. Außerdem können Wireless-Wide-Area-Kommunikationen, z. B. gemäß einem zellulären oder anderen Wireless-Wide-Area-Protokoll über eine Wireless-Wide-Area-Network(WWAN)-Einheit stattfinden.
  • Der Drahtlosnetzwerksendeempfänger 1966 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen mit unterschiedlicher Reichweite kommunizieren. Zum Beispiel kann der Edge-Computing-Knoten 1950 mit nahegelegenen Vorrichtungen, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder eines anderen Niederleistungsfunkgeräts kommunizieren, um Energie zu sparen. Entferntere verbundene Edge-Vorrichtungen 1962, z. B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Mittelleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät auf unterschiedlichen Leistungspegeln stattfinden, oder sie können über separate Sendeempfänger stattfinden, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Mesh-Sendeempfänger, der ZigBee® verwendet.
  • Ein Drahtlosnetzwerksendeempfänger 1966 (z. B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 1963 über Local- oder Wide-Area-Network-Protokolle zu kommunizieren. Der Drahtlosnetzwerksendeempfänger 1966 kann ein LPWA-Sendeempfänger sein, der unter anderem die Standards IEEE 802.15.4 oder IEEE 802.15.4g befolgt. Der Edge-Computing-Knoten 1963 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wurde, kommunizieren. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa Zeitschlitz-Kanalspringen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist.
  • Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den Systemen verwendet werden, die für den Drahtlosnetzwerksendeempfänger 1966 erwähnt wurden, wie hierin beschrieben. Zum Beispiel kann der Sendeempfänger 1966 einen zellulären Sendeempfänger beinhalten, der Spreizspektrum(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Sendeempfänger 1966 kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen kompatibel sind, wie etwa LTE und 5G/NR-Kommunikationssysteme, die am Ende der vorliegenden Offenbarung ausführlicher besprochen werden. Eine Netzwerkschnittstellensteuerung (NIC) 1968 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 1963 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 1962 (die z. B. in einem Mesh arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann unter vielen anderen auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+ oder PROFINET. Eine zusätzliche NIC 1968 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 1968 Kommunikationen mit dem Cloud über Ethernet bereitstellt und eine zweite NIC 1968 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
  • Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine beliebige oder mehrere beliebige der Komponenten 1964, 1966, 191868 oder 1970 beinhalten oder durch diese umgesetzt sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltungsanordnung umgesetzt werden.
  • Der Edge-Computing-Knoten 1950 kann eine Beschleunigungsschaltungsanordnung 1964 beinhalten oder mit dieser gekoppelt sein, die durch einen oder mehrere AI-Beschleuniger, einen Neuronalrechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, ein oder mehrere SoCs (einschließlich programmierbarer SoCs), eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs (einschließlich programmierbarer ASICs), PLDs, wie etwa CPLDs oder HCPLDs, und/oder andere Formen spezialisierter Prozessoren oder Schaltungsanordnungen, die dazu ausgelegt sind, eine oder mehrere spezialisierte Aufgaben zu erfüllen, umgesetzt werden. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten. Bei FPGA-basierten Implementierungen kann die Beschleunigungsschaltungsanordnung 1964 Logikblöcke oder Logik-Fabric und andere miteinander verbundene Ressourcen umfassen, die dazu programmiert (konfiguriert) sein können, verschiedene Funktionen durchzuführen, wie etwa die Prozeduren, Verfahren, Funktionen usw. der verschiedenen hier besprochenen Ausführungsformen. Bei solchen Implementierungen kann die Beschleunigungsschaltungsanordnung 1964 auch Speicherzellen (z. B. EPROM, EEPROM, Flash-Speicher, statischer Speicher (z. B. SRAM, Anti-Fuses usw.)) beinhalten, die zum Speichern von Logikblöcken, Logik-Fabric, Daten usw. in LUTs und dergleichen verwendet werden.
  • Das IX 1956 koppelt auch den Prozessor 1952 mit einem Sensorhub oder einer externen Schnittstelle 1970, die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die zusätzlichen/externen Vorrichtungen können Sensoren 1972, Aktuatoren 1974 und Positionsbestimmungsschaltungsanordnungen 1945 beinhalten.
  • Die Sensorschaltungsanordnung 1972 beinhaltet Vorrichtungen, Module oder Subsysteme, deren Zweck darin besteht, Ereignisse oder Änderungen in ihrer Umgebung zu detektieren und die Informationen (Sensordaten) über die detektierten Ereignisse an irgendeine andere Vorrichtung, ein anderes Modul, ein anderes Subsystem usw. zu senden. Beispiele für solche Sensoren 1972 beinhalten unter anderem Trägheitsmesseinheiten (IMU), die Beschleunigungsmesser, Gyroskope und/oder Magnetometer umfassen; mikroelektromechanische Systeme (MEMS) oder nanoelektromechanische Systeme (NEMS), die 3-Achsen-Beschleunigungsmesser, 3-Achsen-Gyroskope und/oder Magnetometer umfassen; Füllstandsensoren; Strömungssensoren; Temperatursensoren (z. B. Thermistoren); Drucksensoren; barometrische Drucksensoren; Gravimeter; Höhenmesser; Bilderfassungsvorrichtungen (z. B. Kameras); Lichtdetektions- und Entfernungsmessung(LiDAR)-Sensoren; Näherungssensoren (z. B. Infrarotstrahlungsdetektor und dergleichen); Tiefensensoren, Umgebungslichtsensoren; optische Lichtsensoren; Ultraschallsendeempfänger; Mikrofone; und dergleichen.
  • Die Aktuatoren 1974 ermöglichen, dass die Plattform 1950 ihren Zustand, ihre Position und/oder ihre Orientierung ändert oder einen Mechanismus oder ein System bewegt oder steuert. Die Aktuatoren 1974 umfassen elektrische und/oder mechanische Vorrichtungen zum Bewegen oder Steuern eines Mechanismus oder Systems und wandeln Energie (z. B. elektrischen Strom oder sich bewegende Luft und/oder Flüssigkeit) in irgendeine Art von Bewegung um. Die Aktuatoren 1974 können eine oder mehrere elektronische (oder elektrochemische) Vorrichtungen beinhalten, wie etwa piezoelektrische Biomorphe, Festkörperaktuatoren, Festkörperrelais (SSRs), formgedächtnislegierungsbasierte Aktuatoren, elektroaktive polymerbasierte Aktuatoren, integrierte Relaistreiberschaltungen (ICs) und/oder dergleichen. Die Aktuatoren 1974 können eine oder mehrere elektromechanische Vorrichtungen beinhalten, wie etwa pneumatische Aktuatoren, hydraulische Aktuatoren, elektromechanische Schalter einschließlich elektromechanischer Relais (EMRs), Motoren (z. B. Gleichstrommotoren, Schrittmotoren, Servomechanismen usw.), Leistungsschaltern, Ventilaktuatoren, Rädern, Schubdüsen, Propellern, Klauen, Klemmen, Haken, Generatoren hörbaren Schalls, visuellen Warnvorrichtungen und/oder anderen ähnlichen elektromechanischen Komponenten. Die Plattform 1950 kann dazu ausgelegt sein, einen oder mehrere Aktuatoren 1974 basierend auf einem oder mehreren erfassten Ereignissen und/oder Anweisungen oder Steuersignalen, die von einem Dienstanbieter und/oder verschiedenen Client-Systemen empfangen werden, zu betreiben.
  • Die Positionsbestimmungsschaltungsanordnung 1945 beinhaltet eine Schaltungsanordnung zum Empfangen und Decodieren von Signalen, die durch ein Positionsbestimmungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/gesendet werden. Zu Beispielen für Navigationssatellitenkonstellationen (oder GNSS) gehören das Global Positioning System (GPS) der Vereinigten Staaten, das Global Navigation System (GLONASS) von Russland, das Galileo-System der Europäischen Union, das BeiDou Navigation Satellite System von China, ein regionales Navigationssystem oder GNSS-Erweiterungssystem (z. B. Navigation with Indian Constellation (NAVIC), das Quasi-Zenith Satellite System (QZSS) von Japan, das Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) von Frankreich usw.) oder dergleichen. Die Positionsbestimmungsschaltungsanordnung 1945 umfasst verschiedene Hardwareelemente (darunter z. B. Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen), um mit Komponenten eines Positionsbestimmungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. Bei einigen Ausführungsformen kann die Positionsbestimmungsschaltungsanordnung 1945 eine Micro-PNT-IC (Micro-PNT: Mikrotechnologie für Positionsbestimmung, Navigation und Timing) beinhalten, die einen Master-Timing-Takt verwendet, um eine Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen. Die Positionsbestimmungsschaltungsanordnung 1945 kann auch Teil der Kommunikationsschaltungsanordnung 1966 sein oder mit dieser interagieren, um mit den Knoten und Komponenten des Positionsbestimmungsnetzwerks zu kommunizieren. Die Positionsbestimmungsschaltungsanordnung 1945 kann auch Positionsdaten und/oder Zeitdaten an die Anwendungsschaltungsanordnung liefern, die die Daten verwenden kann, um Operationen mit verschiedenen Infrastrukturen (z. B. Funkbasisstationen) für eine Turnby-Turn-Navigation oder dergleichen zu synchronisieren. Wenn kein GNSS-Signal verfügbar ist oder wenn GNSS-Positionsgenauigkeit für eine bestimmte Anwendung oder einen bestimmten Dienst nicht ausreicht, kann eine Positionsbestimmungserweiterungstechnologie verwendet werden, um erweiterte Positionsbestimmungsinformationen und -daten an die Anwendung oder den Dienst zu liefern. Eine solche Positionsbestimmungserweiterungstechnologie kann zum Beispiel satellitenbasierte Positionsbestimmungserweiterung (z. B. EGNOS) und/oder bodenbasierte Positionsbestimmungserweiterung (z. B. DGPS) beinhalten. Bei manchen Implementierungen ist oder beinhaltet die Positionsbestimmungsschaltungsanordnung 1945 ein INS, das ein System oder eine Vorrichtung ist, das/die eine Sensorschaltungsanordnung 1972 (z. B. Bewegungssensoren, wie etwa Beschleunigungsmesser, Rotationssensoren wie Gyroskope, und Höhenmesser, magnetische Sensoren, und/oder dergleichen) verwendet, um kontinuierlich eine Position, Ausrichtung und/oder Geschwindigkeit (einschließlich Bewegungsrichtung und -geschwindigkeit) der Plattform 1950 ohne die Notwendigkeit externer Referenzen zu berechnen (z. B. unter Verwendung von Dead-by-Dead-Reckoning, Triangulation oder dergleichen).
  • Bei manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb des Edge-Computing-Knotens 1950 vorhanden oder mit diesem verbunden sein, die in 19 als Eingabeschaltungsanordnung 1986 und Ausgabeschaltungsanordnung 1984 bezeichnet werden. Die Eingabeschaltungsanordnung 191886 und die Ausgabeschaltungsanordnung 1984 beinhalten eine oder mehrere Benutzerschnittstellen, die dazu ausgelegt sind, eine Benutzerinteraktion mit der Plattform 1950 zu ermöglichen, und/oder Peripheriekomponentenschnittstellen, die dazu ausgelegt sind, eine Peripheriekomponenteninteraktion mit der Plattform 1950 zu ermöglichen. Die Eingabeschaltungsanordnung 1986 kann ein beliebiges physisches oder virtuelles Mittel zum Annehmen einer Eingabe beinhalten, darunter unter anderem eine oder mehrere physische oder virtuelle Tasten (z. B. eine Rücksetztaste), eine physische Tastatur, ein Tastenfeld, eine Maus, ein Touchpad, ein Touchscreen, Mikrofone, ein Scanner, ein Headset und/oder dergleichen. Die Ausgabeschaltungsanordnung 1984 kann enthalten sein, um Informationen zu zeigen oder anderweitig Informationen zu übermitteln, wie etwa Sensorablesungen, Aktuatorposition(en) oder andere ähnliche Informationen. Daten und/oder Grafiken können auf einer oder mehreren Benutzeroberflächenkomponenten der Ausgabeschaltungsanordnung 1984 angezeigt werden. Die Ausgabeschaltungsanordnung 1984 kann eine beliebige Anzahl und/oder Kombinationen von Audio- oder visueller Anzeige beinhalten, darunter unter anderem eine oder mehrere einfache visuelle Ausgaben/Indikatoren (z. B. binäre Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visuelle Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigevorrichtungen oder Touchscreens (z. B. Liquid Chrystal Displays (LCD), LED-Anzeigen, Quantenpunktanzeigen, Projektoren usw.), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen anhand des Betriebs der Plattform 1950 generiert oder erzeugt wird. Die Ausgabeschaltungsanordnung 1984 kann auch Lautsprecher oder andere Audioausgabevorrichtungen, Drucker und/oder dergleichen beinhalten. Bei manchen Ausführungsformen kann die Sensorschaltungsanordnung 191872 als die Eingabeschaltungsanordnung 1984 (z. B. eine Bilderfassungsvorrichtung, Bewegungserfassungsvorrichtung oder dergleichen) verwendet werden und können ein oder mehrere Aktuatoren 1974 als die Ausgabevorrichtungsschaltungsanordnung 1984 (z. B. ein Aktuator zum Bereitstellen einer haptischen Rückmeldung oder dergleichen) verwendet werden. Bei einem anderen Beispiel kann eine Nahfeldkommunikations(NFC)-Schaltungsanordnung, die eine NFC-Steuerung umfasst, die mit einem Antennenelement und einer Verarbeitungsvorrichtung gekoppelt ist, enthalten sein, um elektronische Tags zu lesen und/oder eine Verbindung mit einer anderen NFC-fähigen Vorrichtung herzustellen. Zu Peripheriekomponentenschnittstellen können unter anderem ein nichtflüchtiger Speicheranschluss, ein USB-Anschluss, eine Audiobuchse, eine Stromversorgungsschnittstelle usw. gehören. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Computing-Systems zu empfangen; Komponenten oder Dienste eines Edge-Computing-Systems zu verwalten; einen Zustand einer Edge-Computing-Komponente oder eines Edge-Computing-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstverwendungsfällen durchzuführen.
  • Eine Batterie 1976 kann den Edge-Rechenknoten 1950 speisen, obwohl sie in Beispielen, in denen der Edge-Computing-Knoten 1950 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie kann als Ausfallsicherheit oder für temporäre Funktionen verwendet werden. Die Batterie 1976 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
  • Eine Batterieüberwachungs-/-ladeeinrichtung 1978 kann in dem Randrechenknoten 1950 enthalten sein, um den Ladezustand (SoCh) der Batterie 1976, falls enthalten, zu verfolgen. Die Batterieüberwachungs-/-ladeeinrichtung 1978 kann verwendet werden, um andere Parameter der Batterie 1976 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 1976. Die Batterieüberwachungs-/-ladeeinrichtung 1978 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor in Phoenix, Arizona oder einen IC aus der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Die Batterieüberwachungs-/-ladeeinrichtung 1978 kann die Informationen über die Batterie 1976 über das IX 1956 an den Prozessor 1952 kommunizieren. Die Batterieüberwachungs-/-ladeeinrichtung 1978 kann auch einen Analog-Digital-Wandler (ADC) beinhalten, der es dem Prozessor 1952 ermöglicht, die Spannung der Batterie 1976 oder den Stromfluss von der Batterie 1976 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Computing-Knoten 1950 durchführen kann, wie etwa Übertragungsfrequenz, Maschennetzwerkbetrieb, Erfassungsfrequenz und dergleichen.
  • Ein Leistungsblock 1980 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit der Batterieüberwachungs-/-ladeeinrichtung 1978 gekoppelt sein, um die Batterie 1976 zu laden. Bei manchen Beispielen kann der Leistungsblock 1980 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos zu erhalten, zum Beispiel über eine Schleifenantenne in dem Edge-Computing-Knoten 1950. Eine Drahtlosbatterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in der Batterieüberwachungs-/-ladeeinrichtung 1978 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1976 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Standards Airfuel, des vom Wireless Power Consortium veröffentlichten Drahtlosladestandards Qi oder des von der Alliance for Wireless Power veröffentlichten Ladestandards Rezence durchgeführt werden.
  • Die Speicherung 1958 kann Anweisungen 1982 in der Form von Software, Firmware oder Hardwarebefehlen zum Implementieren der hier beschriebenen Techniken beinhalten. Obwohl solche Anweisungen 1982 als Codeblöcke gezeigt sind, die in dem Speicher 1954 und der Speicherung 1958 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC: Application Specific Integrated Circuit) eingebaut sind.
  • Bei einem Beispiel können die Anweisungen 1882, die über den Speicher 1954, die Speicherung 1958 oder den Prozessor 1952 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 1960 umgesetzt sein, das Code beinhaltet, um den Prozessor 1952 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten 1950 durchzuführen. Der Prozessor 1952 kann über das IX 1956 auf das nichtflüchtige maschinenlesbare Medium 1960 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 1960 durch Vorrichtungen umgesetzt sein, die für die Speicherung 1958 beschrieben sind, oder kann spezifische Speicherungseinheiten, wie etwa optische Datenträger, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichtflüchtige, maschinenlesbare Medium 1960 kann Anweisungen beinhalten, um den Prozessor 1952 anzuweisen, eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das/die Flussdiagramm(e) und Blockdiagramm(e) von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
  • In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch ein beliebiges greifbares Medium, das zum Speichern, Codieren oder Führen von Anweisungen zur Ausführung durch eine Maschine imstande ist und das bewirkt, dass die Maschine beliebige einer oder mehrerer der Methodologien der vorliegenden Offenbarung durchführt, oder das zum Speichern, Codieren oder Führen von Datenstrukturen imstande ist, die von solchen Anweisungen genutzt werden oder damit assoziiert sind. Ein „maschinenlesbares Medium“ kann somit Solid-State-Speicher und optische und magnetische Medien umfassen, ist jedoch nicht darauf beschränkt. Spezielle Beispiele für maschinenlesbare Medien beinhalten nichtflüchtigen Speicher, darunter unter anderem Halbleiterspeichervorrichtungen (z. B. elektrisch programmierbarer Nurlesespeicher (EPROM), elektrisch löschbarer programmierbarer Nurlesespeicher (EEPROM)) und Flash-Speichervorrichtungen; Magnetplatten wie zum Beispiel interne Festplatten und Wechselplatten; magnetooptische Platten; und CD-ROM- und DVD-ROM-Platten. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z. B. HTTP) nutzt.
  • Ein maschinenlesbares Medium kann durch eine Speicherungsvorrichtung oder eine andere Einrichtung bereitgestellt werden, die dazu in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Bei einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen Anweisungen repräsentieren, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z. B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z. B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die die Anweisungen repräsentierenden Informationen in dem maschinenlesbaren Medium können durch eine Verarbeitungsschaltungsanordnung in die Anweisungen zum Implementieren beliebiger der hierin besprochenen Operationen verarbeitet werden. Das Ableiten der Anweisungen aus den Informationen (z. B. Verarbeitung durch die Verarbeitungsschaltungsanordnung) kann beispielsweise Folgendes beinhalten: Kompilieren (z. B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitig Manipulieren der Informationen in die Anweisungen.
  • Bei einem Beispiel kann die Ableitung der Anweisungen Zusammenstellung, Kompilierung oder Interpretation der Informationen (z. B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder vorverarbeiteten Format, das durch das maschinenlesbare Medium bereitgestellt wird, zu erzeugen. Wenn die Informationen in mehreren Teilen bereitgestellt werden, können sie kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarer Binär-Code usw.) auf einem oder mehreren Fernservern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk übertragen werden, und können an einer lokalen Maschine falls notwendig entschlüsselt, dekomprimiert, zusammengesetzt (z. B. verknüpft) und kompiliert oder interpretiert (z. B. in eine Bibliothek, selbständige ausführbare Datei usw.) werden und durch die lokale Maschine ausgeführt werden.
  • 20 stellt Kommunikationskomponenten innerhalb einer beispielhaften mobilen Vorrichtung 1832 dar. Diese mobile Vorrichtung 1832 stellt eine nähere Ansicht der Kommunikationsverarbeitungskomponenten des Knotens 1800 oder der Vorrichtung 1850 bei Implementierung als ein Benutzergerät oder eine Komponente eines Benutzergeräts bereit. Die mobile Einrichtung 1832 kann eine Funk-Frontend-Modul(Funk-FEM)-Schaltungsanordnung 1834, eine Funk-IC-Schaltungsanordnung 1836 und eine Basisbandverarbeitungsschaltungsanordnung 1838 beinhalten. Die mobile Vorrichtung 1832 beinhaltet, wie gezeigt, sowohl Wireless-Local-Area-Network(WLAN)-Funktionalität als auch Bluetooth(BT)-Funktionalität, obwohl Aspekte der Vorrichtung nicht darauf beschränkt sind und andere hier besprochene Funktechnologien durch ähnliche Schaltungsanordnungen implementiert werden können. Die FEM-Schaltungsanordnung 1834 kann zum Beispiel eine WLAN- oder Wi-Fi-FEM-Schaltungsanordnung 1834A und eine Bluetooth(BT)-FEM-Schaltungsanordnung 1834B beinhalten. Die WLAN-FEM-Schaltungsanordnung 1834A kann einen Empfangssignalpfad beinhalten, der eine Schaltungsanordnung umfasst, die ausgelegt ist zum Arbeiten an WLAN-HF-Signalen, die von einer oder mehreren Antennen 1831A empfangen werden, zum Verstärken der empfangenen Signale und zum Bereitstellen der verstärkten Versionen der empfangenen Signale an die WLAN-Funk-IC-Schaltungsanordnung 1836A zur weiteren Verarbeitung. Die BT-FEM-Schaltungsanordnung 1834B kann einen Empfangssignalpfad beinhalten, der eine Schaltungsanordnung beinhalten kann, die ausgelegt ist zum Arbeiten an BT-HF-Signalen, die von einer oder mehreren Antennen 1831B empfangen werden, zum Verstärken der empfangenen Signale und zum Bereitstellen der verstärkten Versionen der empfangenen Signale an die BT-Funk-IC-Schaltungsanordnung 1836B zur weiteren Verarbeitung. Die FEM-Schaltungsanordnung 1834A kann auch einen Übertragungssignalpfad beinhalten, der eine Schaltungsanordnung beinhalten kann, die dazu ausgelegt ist, WLAN-Signale, die durch die Funk-IC-Schaltungsanordnung 1836A zur drahtlosen Übertragung durch eine oder mehrere der Antennen 1831A bereitgestellt werden, zu verstärken. Außerdem kann die FEM-Schaltungsanordnung 1834B auch einen Übertragungssignalpfad beinhalten, der eine Schaltungsanordnung beinhalten kann, die dazu ausgelegt ist, BT-Signale, die durch die Funk-IC-Schaltungsanordnung 1836B zur drahtlosen Übertragung durch die eine oder die mehreren Antennen 1831B bereitgestellt werden, zu verstärken. Obwohl FEM 1834A und FEM 1834B bei dem Beispiel von 20 als voneinander verschieden gezeigt sind, sind Aspekte der vorliegenden Offenbarung nicht darauf beschränkt und schließen die Verwendung eines FEM (nicht gezeigt), das einen Sendepfad und/oder einen Empfangspfad sowohl für WLAN- als auch BT-Signale umfasst, oder die Verwendung einer oder mehrerer FEM-Schaltungsanordnungen, wobei mindestens einige der FEM-Schaltungsanordnungen Sende- und/oder Empfangssignalpfade sowohl für WLAN- als auch BT-Signale gemeinsam nutzen, in ihren Schutzumfang ein.
  • Die Funk-IC-Schaltungsanordnung 1836 kann, wie gezeigt, eine WLAN-Funk-IC-Schaltungsanordnung 1836A und eine BT-Funk-IC-Schaltungsanordnung 1836B beinhalten. Die WLAN-Funk-IC-Schaltungsanordnung 1836A kann einen Empfangssignalpfad beinhalten, der eine Schaltungsanordnung zum Abwärtswandeln von WLAN-HF-Signalen, die von der FEM-Schaltungsanordnung 1834A empfangen werden, und zum Liefern von Basisbandsignalen an die WLAN-Basisbandverarbeitungsschaltungsanordnung 1838A beinhalten kann. Die BT-Funk-IC-Schaltungsanordnung 1836B kann wiederum einen Empfangssignalpfad beinhalten, der eine Schaltungsanordnung zum Abwärtswandeln von BT-HF-Signalen, die von der FEM-Schaltungsanordnung 1834B empfangen werden, und zum Liefern von Basisbandsignalen an die BT-Basisbandverarbeitungsschaltungsanordnung 1838B beinhalten kann. Die WLAN-Funk-IC-Schaltungsanordnung 1836A kann auch einen Übertragungssignalpfad beinhalten, der eine Schaltungsanordnung zum Aufwärtswandeln von WLAN-Basisbandsignalen, die durch die WLAN-Basisbandverarbeitungsschaltungsanordnung 1838A bereitgestellt werden, und zum Liefern von WLAN-HF-Ausgangssignalen an die FEM-Schaltungsanordnung 183 A zur anschließenden drahtlosen Übertragung durch die eine oder die mehreren Antennen 1831A beinhalten kann. Die BT-Funk-IC-Schaltungsanordnung 1836B kann auch einen Übertragungssignalpfad beinhalten, der eine Schaltungsanordnung zum Aufwärtswandeln von BT-Basisbandsignalen, die durch die BT-Basisbandverarbeitungsschaltungsanordnung 1838B bereitgestellt werden, und zum Liefern von BT-HF-Ausgangssignalen an die FEM-Schaltungsanordnung 1834B zur anschließenden drahtlosen Übertragung durch die eine oder die mehreren Antennen 1831B beinhalten kann. Obwohl die Funk-IC-Schaltungsanordnungen 1836A und 1836B bei dem Beispiel von 20 als voneinander verschieden gezeigt sind, sind Aspekte der vorliegenden Offenbarung nicht darauf beschränkt und schließen die Verwendung einer Funk-IC-Schaltungsanordnung (nicht gezeigt), die einen Übertragungssignalpfad und/oder einen Empfangssignalpfad für sowohl WLAN- als auch BT-Signale umfasst, oder die Verwendung einer oder mehrerer Funk-IC-Schaltungsanordnung, wobei mindestens einige der Funk-IC-Schaltungsanordnung Übertragungs- und/oder Empfangssignalpfade für sowohl WLAN- als auch BT-Signale gemeinsam nutzen, in ihren Schutzumfang ein.
  • Die Basisbandverarbeitungsschaltungsanordnung 1838 kann eine WLAN-Basisbandverarbeitungsschaltungsanordnung 1838A und eine BT-Basisbandverarbeitungsschaltungsanordnung 1838B beinhalten. Die WLAN-Basisbandverarbeitungsschaltungsanordnung 1838A kann einen Speicher beinhalten, wie zum Beispiel einen Satz von RAM-Arrays in einem (nicht gezeigten) Schnelle-Fourier-Transformation- oder Inverse-Schnelle-Fourier-Transformation-Block der WLAN-Basisbandverarbeitungsschaltungsanordnung 1838A. Sowohl die WLAN-Basisbandschaltungsanordnung 1838A als auch die BT-Basisbandschaltungsanordnung 1838B können ferner einen oder mehrere Prozessoren und Steuerlogik beinhalten, um die von dem entsprechenden WLAN- oder BT-Empfangssignalpfad der Funk-IC-Schaltungsanordnung 1836 empfangenen Signale zu verarbeiten und auch entsprechende WLAN- oder BT-Basisbandsignale für den Übertragungssignalpfad der Funk-IC-Schaltungsanordnung 1836 zu erzeugen. Jede der Basisbandverarbeitungsschaltungsanordnungen 1838A und 1838B kann ferner eine Bitübertragungsschicht(PHY)- und eine Medienzugriffssteuerungsschicht(MAC)-Schaltungsanordnung beinhalten und kann ferner eine Schnittstelle mit dem Anwendungsprozessor 1851 (oder bei anderen Beispielen der Prozessorschaltungsanordnung 1850) zur Erzeugung und Verarbeitung der Basisbandsignale und zum Steuern von Operationen der Funk-IC-Schaltungsanordnung 1836 bilden.
  • Unter weiterer Bezugnahme auf 20 kann die WLAN-BT-Koexistenzschaltungsanordnung 1843 gemäß den veranschaulichten Aspekten Logik beinhalten, die eine Schnittstelle zwischen der WLAN-Basisbandschaltungsanordnung 1838A und der BT-Basisbandschaltungsanordnung 1838B bereitstellt, um Verwendungsfälle zu ermöglichen, die eine Koexistenz von WLAN und BT erfordern. Außerdem kann ein Schalter 1833 zwischen der WLAN-FEM-Schaltungsanordnung 1834A und der BT-FEM-Schaltungsanordnung 1834B bereitgestellt sein, um ein Umschalten zwischen dem WLAN- und dem BT-Funkgerät gemäß Anwendungsbedürfnissen zu ermöglichen. Obwohl die Antennen 1831A, 1831B als mit der WLAN-FEM-Schaltungsanordnung 1834A bzw. der BT-FEM-Schaltungsanordnung 1834B verbunden dargestellt sind, schließen Aspekte der vorliegenden Offenbarung außerdem eine gemeinsame Nutzung einer oder mehrerer Antennen zwischen dem WLAN- und dem BT-FEM oder das Bereitstellen von mehr als einer mit jedem des FEM 1834A bzw. 1834B verbundenen Antenne in ihren Schutzumfang ein.
  • Bei manchen Aspekten der vorliegenden Offenbarung können die Frontend-Modul-Schaltungsanordnung 1834, die Funk-IC-Schaltungsanordnung 1836 und die Basisbandverarbeitungsschaltungsanordnung 1838 auf einer einzigen Funkkarte bereitgestellt sein. Bei anderen Aspekten können die eine oder die mehreren Antennen 1831A, 1831B, die FEM-Schaltungsanordnung 1834 und die Funk-IC-Schaltungsanordnung 1836 auf einer einzigen Funkkarte bereitgestellt sein. Bei manchen anderen Aspekten der vorliegenden Offenbarung können die Funk-IC-Schaltungsanordnung 1836 und die Basisbandverarbeitungsschaltungsanordnung 1838 auf einem einzigen Chip oder einer integrierten Schaltung (IC) bereitgestellt sein.
  • 21 veranschaulicht RSD-Komponenten (RSD: Rack Scale Design), die in einem Teil eines Servers oder eines anderen diskreten Computerknotens in einer Edge-Plattformarchitektur enthalten sein können. Diese Anordnung stellt eine nähere Ansicht der konfigurierbaren Verarbeitungskomponenten des Knotens 1800 oder der Vorrichtung 1950 bei Implementierung als ein Server (z. B. in einem Server-Rack, -Blade usw.) bereit. Diese konfigurierbare Architektur unterscheidet sich von einigen anderen durch Disaggregation von FPGA- (Feldprogrammierbares Gate-Array), NVMe- (Non-Volatile Memory express) E/A- (Eingabe/Ausgabe)-Pooling-Ressourcen. Die FPGA- und NVMe-Ressourcen stellen Elemente bereit, die für einen beliebigen Typ von Edge-Diensten verwendet werden können, wie etwa Video- oder Sprachanalytik. E/A-Pooling kann verwendet werden, um flexible NFs bereitzustellen. Diese Architektur ermöglicht das Skalieren von Netzwerkschnittstellen gemäß der erwarteten Datenrate oder Netzwerklast für eine bestimmte VNF Diese Architektur ermöglicht auch Flexibilität, verschiedene Netzwerkkarten in Abhängigkeit von der Art der Netzwerkverarbeitung, die an einem gegebenen Knoten stattfindet, auf Rechenknoten abzubilden.
  • Die veranschaulichte RSD-Architektur weist einen POD(Point-Of- Delivery)-Manager 2142 auf. Der POD-Manager 2142 ist für das Verwalten der Ressourcen-einschließlich Rechen- und disaggregierter Ressourcen-innerhalb eines POD (z. B. eines oder mehrerer Racks) verantwortlich. Der POD-Manager 2142 legt einem Orchestrator Schnittstellen offen, um zusammengesetzte Knoten zu erstellen, zu verwalten oder zu zerstören. Das Verwalten eines zusammengesetzten Knotens beinhaltet das Merkmal des Herauf- oder Herunterskalierens der Menge gepoolter Ressourcen 2148, die mit einem speziellen Rechenschlitten 2140 verbunden sind. Der POD-Manager 2142 läuft typischerweise auf einer Knotensteuerung. Der POD-Manager 2142 ist für die Entdeckung von Ressourcen in dem POD, das Konfigurieren und Verwalten der Ressourcen und das Zusammenstellen eines logischen Servers verantwortlich. Bei einem Beispiel ist der POD-Manager 2142 eine optionale separate Komponente und wird nicht im Rack benötigt. In einem Beispiel ist jedoch, um „RSD-konform“ zu sein, ein Rack durch einen zertifizierten POD-Manager verwaltbar.
  • Im Folgenden werden einige beispielhafte Attribute eines POD-Managers 2142 angegeben. Zum Beispiel kann ein Rack einen Satz von Rechenschlitten 2140 beinhalten, die zum Ausführen von Edge-Diensten und anderen verwandten Systemsoftwarestapeln (wie z. B. Orchestrierungs- oder andere Systemdienste) verwendet werden. Ein Typ von Rechenschlitten 2140 kann ein Pooled-Resources-Schlitten sein. Dieser Rechenschlitten 2140 kann einen Satz von disaggregierten Ressourcen verwalten. Hier kann ein Rechenschlitten 1840 eine gepoolte Systemverwaltungs-Engine-Software (PSME) 2141 beinhalten. Die PSME 2141 stellt eine Verwaltungsschnittstelle bereit, um die Module oder Blades auf Schubladenebene zu verwalten. Bei einem Beispiel enthält ein Rack eine oder mehrere logische PSME(s). Zum Beispiel kann jede Schublade eine PSME aufweisen oder Serverschubladen können sich eine PSME teilen oder eine PSME kann auf einem Top-of-Rack(TOR)-2144-Switch oder auf einem separaten Host laufen. Bei einem Beispiel unterstützt die PSME 2141 die RSD-APIs.
  • Bei einem Beispiel kann der Rechenschlitten 2140 Prozessoren (z. B. CLX) beinhalten, um einen RSD-Softwarestapel auszuführen, der NVM-oF oder FPGA-oF als Zielsystem implementiert und einen Satz disaggregierter Ressourcen verwaltet. In einem Beispiel sind die Prozessoren unter Verwendung des PCIe x16-Gabelungsports mit einem PCIe-Switch 2146 verbunden, der Zugriff auf die Zielressourcen (FPGA oder NVME im RSD 2148) bereitstellt.
  • Verschiedene RSD-Edge-zusammengesetzte Knoten-Flavors können in dem Rechenschlitten 2140 verwendet werden, um Edge-Dienste auszuführen. Dienste, die auf diesen Knoten ausgeführt werden, können Client-Software-Bibliotheken oder -Treiber verwenden, um transparenten Zugriff auf die disaggregierten FPGAs und NVMe in dem RSD 2148 bereitzustellen. Bei einem weiteren Beispiel beinhaltet das Rack einen oder mehrere PCIe-Switches, die Rechenschlitten 2140 mit einem Satz von disaggregierten Ressourcen (z. B. RSD 2148) verbinden.
  • Die Veranschaulichungen der 18, 19, 20 und 21 sollen eine abstrahierte Ansicht von Komponenten einer variierenden Vorrichtung, eines variierenden Subsystems oder einer variierenden Anordnung eines Edge-Rechenknotens darstellen. Jedoch versteht es sich, dass manche der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können und eine unterschiedliche Anordnung der gezeigten Komponenten in anderen Implementierungen auftreten kann. Ferner sind diese Anordnungen in einer Vielzahl von Verwendungsfällen und Umgebungen verwendbar, einschließlich jenen, die unten erörtert werden (z. B. ein mobiles UE in industrieller Berechnung für eine Smart-Stadt oder Smart-Fabrik, unter vielen anderen Beispielen).
  • Die jeweiligen Rechenplattformen der 18, 19, 20 und 21 können mehrere Edge-Instanzen (z. B. Edge-Cluster) unter Verwendung von Mandantencontainern, die auf einer einzigen Rechenplattform laufen, unterstützen. Gleichermaßen können mehrere Edge-Knoten als Unterknoten existieren, die auf Mandanten innerhalb derselben Rechenplattform laufen. Dementsprechend kann basierend auf verfügbarer Ressourcenpartitionierung ein einzelnes System oder eine einzelne Rechenplattform in mehrere unterstützende Mandanten- und Edge-Knoteninstanzen partitioniert oder unterteilt werden, von denen jede mehrere Dienste und Funktionen unterstützen kann - selbst während sie potenziell in mehreren Rechenplattforminstanzen durch mehrere Besitzer betrieben oder gesteuert wird. Diese verschiedenen Arten von Partitionen können komplexe Multi-Mandanten und viele Kombinationen von Multi-Stakeholdern durch die Verwendung eines LSM oder einer anderen Implementierung einer Isolations-/Sicherheitsrichtlinie unterstützen. Hinweise auf die Verwendung eines LSM und Sicherheitsmerkmale, die solche Sicherheitsmerkmale verbessern oder implementieren, werden daher in den folgenden Abschnitten erwähnt. Gleichermaßen können Dienste und Funktionen, die an diesen verschiedenen Typen von Mehrentitätspartitionen arbeiten, lastausgeglichen, migriert und orchestriert werden, um notwendige Dienstziele und -operationen zu erreichen.
  • IV. BEISPIELHAFTE IMPLEMENTIERUNGEN
  • Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht-einschränkenden Implementierungen. Jedes der folgenden nicht einschränkenden Beispiele kann für sich allein stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen Beispiele, die unten oder in der gesamten vorliegenden Offenbarung bereitgestellt werden, kombiniert werden.
  • Beispiel 1 beinhaltet ein Verfahren zum Betreiben eines MEC-Hosts, der zusammen mit einer Netzwerkzugangsinfrastruktur angeordnet ist, wobei das Verfahren Folgendes umfasst: Empfangen einer Anforderungsnachricht für eine vorhergesagte Dienstgüte (QoS: Quality of Service) für einen Drahtloskommunikationsdienst entlang einer geplanten Route eines Fahrzeugbenutzergeräts (vUE), wobei die Anforderungsnachricht Standortinformationen (LocationInfo) für jeden Punkt von mindestens zwei Punkten entlang der geplanten Route und einen Zeitstempel für jeden Punkt der mindestens zwei Punkte beinhaltet; und Bestimmen, als Reaktion auf den Empfang der Anforderungsnachricht, der vorhergesagten QoS für den Drahtloskommunikationsdienst für das vUE entlang der geplanten Route basierend auf dem Standort und dem Zeitstempel für jeden Punkt.
  • Beispiel 2a beinhaltet das Verfahren von Beispiel 1 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Anforderungsnachricht ferner ein Routendatenelement umfasst, wobei das Routendatenelement Informationen bezüglich einer potenziellen Route des vUE beinhaltet.
  • Beispiel 2b beinhaltet das Verfahren von Beispiel 2a und/oder einem oder mehreren anderen Beispielen hierin, wobei die Anforderungsnachricht ferner eine Vorhersage-QoS-Datenstruktur umfasst und die Vorhersage-QoS-Datenstruktur das Routendatenelement beinhaltet.
  • Beispiel 3a beinhaltet das Verfahren der Beispiele 1-2a und/oder eines oder mehrerer anderer Beispiele hierin, wobei das Routendatenelement ein Routeninformations(routeInfo)-Datenelement für jeden Punkt der mindestens zwei Punkte umfasst.
  • Beispiel 3b beinhaltet das Verfahren von Beispiel 2b und/oder einem oder mehreren anderen Beispielen hierin, wobei die Vorhersage-QoS-Datenstruktur das Routendatenelement und ein routeInfo-Datenelement für jeden Punkt der mindestens zwei Punkte beinhaltet.
  • Beispiel 4 beinhaltet das Verfahren der Beispiele 3a-3b und/oder eines oder mehrerer anderer Beispiele hierin, wobei ein erstes routeInfo-Datenelement, das in dem Routendatenelement enthalten ist, einem Ausgangspunkt der geplanten Route entspricht und ein letztes routeInfo-Datenelement, das in dem Routendatenelement enthalten ist, einem Ziel der geplanten Route entspricht.
  • Beispiel 5 beinhaltet das Verfahren von Beispiel 4 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Routendatenelement ferner ein oder mehrere routeInfo-Zwischendatenelemente umfasst, von denen jedes einem jeweiligen Zwischenpunkt zwischen dem Ausgangspunkt der geplanten Route und dem Ziel der geplanten Route entspricht.
  • Beispiel 6 beinhaltet das Verfahren der Beispiele 3a-5 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das routeInfo-Datenelement für jeden Punkt ein Standortdatenelement einschließlich des LocationInfo und ein Zeitdatenelement einschließlich des Zeitstempels umfasst.
  • Beispiel 7 beinhaltet das Verfahren von Beispiel 6 und/oder einem oder mehreren anderen Beispielen hierin, wobei das LocationInfo Breiten- und Längenkoordinaten oder eine globale Zellenkennung einer versorgenden Zelle beinhaltet, mit der das vUE verbunden ist, und der Zeitstempel eine geschätzte Zeit an einem Standort ist, der durch das LocationInfo angegeben wird.
  • Beispiel 8a beinhaltet das Verfahren der Beispiele 3a-6 und/oder eines oder mehrerer anderer Beispiele hierin, wobei die Anforderungsnachricht ferner ein Zeitgranularitätsdatenelement und ein Standortgranularitätsdatenelement umfasst, wobei das Zeitgranularitätsdatenelement einen Zeitstempelwert enthält, der eine Zeitgranularität des Aufenthalts an einem Standort angibt, und das Standortgranularitätsdatenelement eine Zeichenkette enthält, die eine Granularität eines besuchten Standorts durch in Metern gemessene Breiten- und Längenspannen angibt.
  • Beispiel 8b beinhaltet das Verfahren von Beispiel 8a und/oder einem oder mehreren anderen Beispielen hierin, wobei das Zeitgranularitätsdatenelement und das Standortgranularitätsdatenelement in der vorhergesagten QoS-Datenstruktur enthalten sind.
  • Beispiel 9a beinhaltet das Verfahren der Beispiele 1-8b und/oder eines oder mehrerer anderer Beispiele hierin, das ferner Folgendes umfasst: Erzeugen einer Antwortnachricht, die eine Funkmessung für jeden Punkt entlang der geplanten Route beinhaltet; und Übertragen der Antwortnachricht an das vUE.
  • Beispiel 9b beinhaltet das Verfahren von Beispiel 9a und/oder einem oder mehreren anderen Beispielen hierin, das ferner Folgendes umfasst: derartiges Erzeugen der Antwortnachricht, dass sie eine andere Vorhersage-QoS-Datenstruktur beinhaltet, wobei die andere Vorhersage-QoS-Datenstruktur die Funkmessung für jeden Punkt entlang der geplanten Route beinhaltet.
  • Beispiel 10a beinhaltet das Verfahren der Beispiele 9a-9b und/oder eines oder mehrerer anderer Beispiele hierin, wobei die Antwortnachricht ferner ein anderes Routendatenelement umfasst, das andere Routendatenelement ein anderes routeInfo-Datenelement für jeden Punkt der mindestens zwei Punkte umfasst, und das routeInfo-Datenelement für jeden Punkt ein Standortdatenelement, das LocationInfo eines entsprechenden Punkts der mindestens zwei Punkte beinhaltet, ein Referenzsignal-Empfangsleistungs(rsrp)-Datenelement, das einen vorhergesagten rsrp-Wert für den entsprechenden Punkt beinhaltet, und ein Referenzsignal-Empfangsqualitäts(rsrq)-Datenelement, das einen vorhergesagten rsrq-Wert für den entsprechenden Punkt beinhaltet, umfasst.
  • Beispiel 10b beinhaltet das Verfahren von Beispiel 10a und/oder einem oder mehreren anderen Beispielen hierin, wobei die andere Vorhersage-QoS-Datenstruktur das andere Routendatenelement umfasst.
  • Beispiel 11 beinhaltet das Verfahren von Beispiel 10 und/oder einem oder mehreren anderen Beispielen hierin, wobei ein erstes anderes routeInfo-Datenelement, das in dem anderen Routendatenelement enthalten ist, einem Ausgangspunkt der geplanten Route entspricht, ein letztes anderes routeInfo-Datenelement, das in dem anderen Routendatenelement enthalten ist, einem Ziel der geplanten Route entspricht, und ein oder mehrere andere routeInfo-Zwischendatenelemente, die in dem anderen Routendatenelement enthalten sind, jeweiligen Zwischenpunkten zwischen dem Ausgangspunkt der geplanten Route und dem Ziel der geplanten Route entsprechen.
  • Beispiel 12 beinhaltet das Verfahren der Beispiele 9-11, wobei die Anforderung und die Antwort über eine VIS-Anwendungsprogrammierschnittstelle (VIS-API) kommuniziert werden.
  • Beispiel 13 beinhaltet das Verfahren der Beispiele 1-12 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das Bestimmen der vorhergesagten QoS für das vUE entlang der geplanten Route Folgendes umfasst: Identifizieren von Raum-Zeit-Korrelationen zwischen durch ein oder mehrere andere vUEs erfassten Funkinformationen und den mindestens zwei Punkten entlang der geplanten Route.
  • Beispiel 14a beinhaltet das Verfahren der Beispiele 1-13 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das Bestimmen der vorhergesagten QoS für das vUE für den Drahtloskommunikationsdienst für das vUE entlang der geplanten Route Folgendes umfasst: Anfordern von Informationen von einem MEC-Informationsdienst über eine entsprechende MEC-API; Empfangen der angeforderten Informationen von dem MEC-Informationsdienst; und Vorhersagen der Funksignalqualität an jedem Punkt der mindestens zwei Punkte unter Verwendung der empfangenen Informationen, wobei der MEC-Informationsdienst ein Funknetzinformationsdienst, ein MEC-Standortdienst, ein Benutzeridentitätsdienst, ein Bandbreitenverwaltungsdienst, ein Wireless-Local-Area-Network-Zugangsinformationsdienst oder ein Fixed-Access-Information-Dienst ist. Beispiel 14b beinhaltet das Verfahren von Beispiel 14a und/oder einem oder mehreren anderen Beispielen hierin, wobei die Funksignalqualitätsvorhersage ein Ausmaß oder eine Menge an Netzwerküberlastung angibt.
  • Beispiel 15 beinhaltet ein Verfahren zum Betreiben eines vUE, wobei das Verfahren Folgendes umfasst: Erzeugen einer Anforderungsnachricht zum Anfordern einer Dienstgüte(QoS: Quality of Service)-Vorhersage für Vehicle-to-Everything(V2X)-Dienste entlang einer geplanten Route, wobei die Anforderungsnachricht eine Vorhersage-QoS-Datenstruktur beinhaltet, wobei die Vorhersage-QoS-Datenstruktur Standortinformationen (LocationInfo) für jeden Punkt von mindestens zwei Punkten entlang der geplanten Route und einen Zeitstempel für jeden Punkt der mindestens zwei Punkte beinhaltet; und Übertragen der Anforderungsnachricht an einen Mehrfachzugriffs-Edge-Computing bzw. MEC-Host (MEC: Multi Access Edge Computing) über eine V2X-Informationdienst(VIS)-Anwendungsprogrammierschnittstelle (API); und Empfangen einer Antwortnachricht von dem MEC-Host über die VIS-API, wobei die Antwortnachricht eine andere Vorhersage-QoS-Datenstruktur beinhaltet, die eine vorhergesagte QoS für die V2X-Dienste für jeden Punkt der mindestens zwei Punkte beinhaltet.
  • Beispiel 16 beinhaltet das Verfahren von Beispiel 15 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Vorhersage-QoS-Datenstruktur ein Routendatenelement umfasst, wobei das Routendatenelement ein Routeninformations(routeInfo)-Datenelement für einen entsprechenden Punkt der mindestens zwei Punkte beinhaltet und das routeInfo-Datenelement für den entsprechenden Punkt ein Standortdatenelement einschließlich des LocationInfo des entsprechenden Punkts und ein Zeitdatenelement einschließlich des Zeitstempels für den entsprechenden Punkt umfasst.
  • Beispiel 17 beinhaltet das Verfahren von Beispiel 16 und/oder einem oder mehreren anderen Beispielen hierin, wobei der entsprechende Punkt eines ersten routeInfo-Datenelements, das in dem Routendatenelement enthalten ist, ein Ausgangspunkt der geplanten Route ist und der entsprechende Punkt eines letzten routeInfo-Datenelements, das in dem Routendatenelement enthalten ist, ein Zielpunkt der geplanten Route ist.
  • Beispiel 18 beinhaltet das Verfahren von Beispiel 17 und/oder einem oder mehreren anderen Beispielen hierin, wobei der Zeitstempel für den Ausgangspunkt eine Zeit ist, zu der sich das vUE an einem Standort aufgehalten hat, der durch das LocationInfo in dem ersten routeInfo-Datenelement angegeben wird, und der Zeitstempel für den Zielpunkt eine vorhergesagte Zeit ist, zu der sich das vUE an einem Standort aufhalten wird, der durch das LocationInfo in dem letzten routeInfo-Datenelement angegeben wird.
  • Beispiel 19 beinhaltet das Verfahren der Beispiele 17-18 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das Routendatenelement ferner ein oder mehrere routeInfo-Zwischendatenelemente umfasst, wobei jedes routeInfo-Zwischendatenelement des einen oder der mehreren routeInfo-Zwischendatenelemente einem Wegpunkt zwischen dem Ausgangspunkt und dem Zielpunkt entspricht.
  • Beispiel 20 beinhaltet das Verfahren von Beispiel 19 und/oder einem oder mehreren anderen Beispielen hierin, wobei der Zeitstempel für mindestens einen Wegpunkt eine Zeit ist, zu der sich das vUE an einem Standort aufgehalten hat, der durch das LocationInfo in dem routeInfo-Zwischendatenelement angegeben wird, das dem mindestens einen Wegpunkt entspricht, und der Zeitstempel für einen anderen Wegpunkt eine vorhergesagte Zeit ist, zu der sich das vUE an einem Standort aufhalten wird, der durch das LocationInfo in dem routeInfo-Datenelement angegeben wird, das dem anderen Wegpunkt entspricht.
  • Beispiel 21 beinhaltet das Verfahren der Beispiele 16-20 und/oder eines oder mehrerer anderer Beispiele hierin, wobei die andere Vorhersage-QoS-Datenstruktur ein anderes Routendatenelement beinhaltet, wobei das andere Routendatenelement ein anderes routeInfo-Datenelement für den entsprechenden Punkt der mindestens zwei Punkte beinhaltet, und das routeInfo-Datenelement für den entsprechenden Punkt Folgendes umfasst: ein Standortdatenelement, das das LocationInfo des entsprechenden Punkts beinhaltet, ein Zeitdatenelement, das den Zeitstempel für den entsprechenden Punkt beinhaltet, ein Referenzsignal-Empfangsleistungs(rsrp)-Datenelement, das einen vorhergesagten rsrp-Wert an einem Standort, der durch das LocationInfo des entsprechenden Punkts und während einer Zeit des Zeitstempels in dem Zeitdatenelement angegeben wird, beinhaltet, und ein Referenzsignal-Empfangsqualität(rsrq)-Datenelement, das einen vorhergesagten rsrq-Wert an dem durch das LocationInfo des entsprechenden Punkts und während der Zeit des Zeitstempels in dem Zeitdatenelement angegebenen Standort enthält.
  • Beispiel 22 beinhaltet ein Verfahren zum Erhalten fahrtspezifischer QoS-Vorhersagen für V2X-Dienste, wobei das Verfahren Folgendes umfasst: Übertragen, durch ein vUE, einer Anforderung für die fahrtspezifischen QoS-Vorhersagen an einen MEC-Host über eine VIS-API, wobei die Anforderung eine geplante Route angibt, die einen Ausgangspunkt, einen Zielpunkt, und null oder mehr Wegpunkte zwischen dem Ausgangspunkt und dem Zielpunkt beinhaltet; und Empfangen, durch das vUE, einer Antwortnachricht von dem MEC-Host über die VIS-API, wobei die Antwortnachricht eine vorhergesagte QoS für V2X-Dienste für den Ausgangspunkt, den Zielpunkt und jeden der null oder mehr Wegpunkte beinhaltet.
  • Beispiel 23a beinhaltet das Verfahren von Beispiel 22 und/oder einem oder mehrerer anderen Beispielen hierin, das ferner Folgendes beinhaltet: in jeder Periode einer bestimmten Funkinformationsmeldeperiodizität, Erfassen von Funkinformationen einschließlich eines oder mehrerer Funkmessberichte; und Übertragen der Funkinformationen an den MEC-Host über die VIS-API oder eine andere MEC-API.
  • Beispiel 23b beinhaltet das Verfahren der Beispiele 22-23a und/oder eines oder mehrerer anderer Beispiele hierin, das ferner Folgendes umfasst: Bestimmen, ob ein Datentransfer an jedem Punkt der mindestens zwei Punkte durchgeführt werden soll, basierend auf der vorhergesagten QoS für jeden Punkt.
  • Beispiel 24 beinhaltet ein Verfahren, das Anweisungen zum Bereitstellen fahrtspezifischer QoS-Vorhersagen für einen Netzwerkdienst umfasst, wobei das Verfahren Folgendes umfasst: Empfangen, durch einen MEC-Host, einer Anforderung für die fahrtspezifischen QoS-Vorhersagen von einem Fahrzeugbenutzergerät (vUE) über eine Vehicle-to-Everything-Informationsdienst(VIS)-Anwendungsprogrammierschnittstelle (API), wobei die Anforderung eine geplante Route des vUE angibt, wobei die geplante Route einen Ausgangspunkt, einen Zielpunkt und null oder mehr Wegpunkte, die gemäß Planung zu bestimmten Zeitpunkten zwischen dem Ausgangspunkt und dem Zielpunkt besucht werden sollen, beinhaltet; Erhalten, durch den MEC-Host, von Funkinformationen von einem oder mehreren vUEs und anderen Informationen von einem oder mehreren anderen MEC-Hosts unter Verwendung einer entsprechenden MEC-API; Bestimmen, durch den MEC-Host, einer vorhergesagten QoS für einen Netzwerkdienst jeweils für den Ausgangspunkt, den Zielpunkt, und die null oder mehr Wegpunkte basierend auf den Funkinformationen und den anderen Informationen; und Senden, durch den MEC-Host, einer Antwortnachricht an das vUE über die VIS-API, wobei die Antwortnachricht die vorhergesagte QoS für einen Netzwerkdienst an dem Ausgangspunkt, dem Zielpunkt und den null oder mehr Wegpunkten zu den Zeiten von Interesse beinhaltet.
  • Beispiel 25 beinhaltet das Verfahren von Beispiel 24 und/oder einem oder mehreren anderen Beispielen hierin, wobei es sich bei den anderen Informationen um Funknetzinformationen (RNI), die von einem RNI-Dienst erhalten werden, und/oder Standortinformationen, die von einem Standortdienst erhalten werden, und/oder Benutzeridentitätsinformationen, die von einem Benutzeridentitätsdienst erhalten werden, und/oder Bandbreitenverwaltungs(BWM)-Informationen, die von einem BWM-Dienst erhalten werden, und/oder Wireless-Local-Area-Network-Zugangsinformationen (WAI), die von einem WAI-Dienst erhalten werden, und/oder Fixed Access Information (FAI), die von einem FAI-Dienst erhalten werden, handelt.
  • Eine beispielhafte Implementierung ist ein Edge-Computing-System, das jeweilige Edge-Verarbeitungsvorrichtungen und -Knoten zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hierin beschriebener Gegenstände beinhaltet. Eine andere beispielhafte Implementierung ist ein Client-Endpunktknoten, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hier beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Aggregationsknoten, Netzwerkhubknoten, Gateway-Knoten oder Kerndatenverarbeitungsknoten, innerhalb oder gekoppelt mit einem Edge-Computing-System, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hierin beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Zugangspunkt, eine Basisstation, eine Wegrandeinheit, eine Straßenrandeinheit oder eine Vor-Ort-Einheit, innerhalb oder gekoppelt mit einem Edge-Computing-System, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hierin beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Edge-Bereitstellungsknoten, ein Dienstorchestrierungsknoten, ein Anwendungsorchestrierungsknoten oder ein Mehrmandantenverwaltungsknoten, innerhalb oder gekoppelt mit einem Edge-Computing-System, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hierin beschriebener Gegenstände.
  • Eine andere beispielhafte Implementierung ist ein Edge-Knoten, der einen Edge-Bereitstellungsdienst, eine Edge-Anwendung oder einen Edge-Dienst-Orchestrierungsdienst, einen Virtuelle-Maschine-Einsatz, einen Container-Einsatz, einen Funktionseinsatz und eine Rechenverwaltung betreibt, innerhalb oder gekoppelt mit einem Edge-Computing-System, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hierin beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das als ein Edge-Mesh, als ein Edge-Mesh mit Side-Car-Loading oder mit Mesh-zu-Mesh-Kommunikationen betreibbar ist, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele 1-25 oder anderer hierin beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das Aspekte von Netzwerkfunktionen, Beschleunigungsfunktionen, Beschleunigungshardware, Speicherungshardware oder Rechenhardwareressourcen beinhaltet, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele 1-25 oder anderer hier beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das zum Unterstützen von Client-Mobilität, Fahrzeug-zu-Fahrzeug(V2V)-, Vehicle-to-Everything(V2X)- oder Fahrzeug-zu-Infrastruktur(V2I)-Szenarien ausgelegt ist und optional gemäß ETSI-MEC-Spezifikationen arbeitet, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele 1-25 oder anderer hier beschriebener Gegenstände. Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das für mobile drahtlose Kommunikationen ausgelegt ist, einschließlich Konfigurationen gemäß 3GPP-4G/LTE- oder 5G-Netzwerkfähigkeiten, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele 1-25 oder anderer hier beschriebener Gegenstände.
  • Beispiel Z01 beinhaltet eine Einrichtung, die Mittel zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem beliebigen der Beispiele 1-25 beschrieben ist oder mit diesem in Zusammenhang steht, oder eines beliebigen anderen hier beschriebenen Verfahrens oder Prozesses, umfasst. Beispiel Z02 beinhaltet ein oder mehrere nichtflüchtige computerlesbare Medien, die Anweisungen umfassen, wobei eine Ausführung der Anweisungen durch eine elektronische Vorrichtung betreibbar ist, zu bewirken, dass die elektronische Vorrichtung ein oder mehrere Elemente eines Verfahrens, das in einem beliebigen der Beispiele 1-25 beschrieben ist oder mit diesem in Zusammenhang steht, und/oder eines beliebigen anderen hier beschriebenen Verfahrens oder Prozesses, durchführt. Beispiel Z03 beinhaltet ein Computerprogramm, das Anweisungen umfasst, wobei die Ausführung des Programms durch ein Verarbeitungselement betreibbar ist, zu bewirken, dass das Verarbeitungselement das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele 1-25 und/oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend, ausführt. Beispiel Z04 beinhaltet eine Einrichtung, die Logik, Module oder Schaltungsanordnungen zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem beliebigen der Beispiele 1-25 beschrieben ist oder mit diesen in Zusammenhang steht, und/oder eines beliebigen anderen hier beschriebenen Verfahrens oder Prozesses, umfasst. Beispiel Z05 beinhaltet eine Einrichtung, ausgelegt zum Durchführen eines oder mehrerer Elemente eines Verfahrens, das in einem der Beispiele 1-25 beschrieben ist oder mit diesen in Zusammenhang steht, und/oder eines beliebigen anderen hier beschrieben Verfahrens oder Prozesses.
  • Beispiel Z06 beinhaltet ein Verfahren, eine Technik oder einen Prozess, wie in einem der Beispiele 1-25 und/oder Abschnitten oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend. Beispiel Z07 beinhaltet eine Einrichtung, die Folgendes umfasst: eine Prozessorschaltungsanordnung und computerlesbare Medien, die Anweisungen umfassen, wobei der eine oder die mehreren Prozessoren dazu konfigurierbar sind, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele 1-25 und/oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend, durchzuführen. Beispiel Z08 beinhaltet ein Signal, wie in einem der Beispiele 1-25 und/oder Abschnitten oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend. Beispiel Z09 beinhaltet ein Datagramm, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht, wie in einem der Beispiele 1-25 oder Abschnitten oder Teilen davon beschrieben oder damit in Zusammenhang stehend und/oder anderweitig in der vorliegenden Offenbarung beschrieben. Beispiel Z10 beinhaltet ein Signal, das mit einem Datagramm, Paket, Rahmen, Segment, einer PDU oder Nachricht codiert ist, wie in einem der Beispiele 1-25 oder Abschnitten oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend oder anderweitig in der vorliegenden Offenbarung beschrieben.
  • Beispiel Z11 beinhaltet ein Signal, das mit Daten codiert ist, wie in einem der Beispiele 1-25 oder Abschnitten oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend oder anderweitig in der vorliegenden Offenbarung beschrieben. Beispiel Z12 beinhaltet ein elektromagnetisches Signal, das computerlesbare Anweisungen transportiert, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren dahingehend betreibbar oder konfigurierbar ist, zu bewirken, dass der eine oder die mehreren Prozessoren ein Verfahren, eine Technik oder einen Prozess, wie in einem der Beispiele 1-25 oder Teilen davon beschrieben oder damit in Zusammenhang stehend, durchführen. Beispiel Z13 beinhaltet eine API oder Spezifikation, die Funktionen, Verfahren, Variablen, Datenstrukturen, Protokolle usw. definiert, die die Verwendung von einem beliebigen der Beispiele 1-25 oder Teilen davon definieren oder beinhalten oder anderweitig mit einem beliebigen der Beispiele 1-25 oder Teilen davon in Zusammenhang stehen. Beispiel Z14 beinhaltet einen Mehrfachzugriffs-Edge Computing(MEC)-Host, der einen Dienst als Teil einer oder mehrerer MEC-Anwendungen ausführt, die auf einer Virtualisierungsinfrastruktur instanziiert sind, wobei der Dienst mit einem beliebigen der Beispiele 1-25 oder Teilen davon in Zusammenhang steht, und wobei der MEC-Host dazu ausgelegt ist, gemäß einem Standard aus einer oder mehreren ETSI-MEC-Standardfamilien zu arbeiten.
  • Beispiel Z15 beinhaltet ein Signal in einem Drahtlosnetzwerk, wie hier gezeigt und beschrieben. Beispiel Z16 beinhaltet ein Verfahren zum Kommunizieren in einem Drahtlosnetzwerk, wie hier gezeigt und beschrieben. Beispiel Z17 beinhaltet ein System zum Bereitstellen drahtloser Kommunikation, wie hier gezeigt und beschrieben. Beispiel Z18 beinhaltet eine Vorrichtung zum Bereitstellen drahtloser Kommunikation, wie hier gezeigt und beschrieben.
  • V. TERMINOLOGIE
  • So wie sie hierin verwendet werden, sollen die Singularformen „ein“, „eine“ und „der/die/das“ auch Pluralformen umfassen, es sei denn, dass der Zusammenhang eindeutig etwas anderes angibt. Es versteht sich ferner, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn in dieser Patentschrift verwendet, das Vorhandensein aufgeführter Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten spezifiziert, aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon ausschließt. Der Ausdruck „A und/oder B“ bedeutet (A), (B) oder (A und B). Für die 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 verwendet möglicherweise die Ausdrücke „bei einer Ausführungsform“ oder „bei manchen Ausführungsformen“, die jeweils auf eine oder mehrere derselben oder verschiedene Ausführungsformen verweisen. Weiterhin sind die Begriffe „umfassend“, „beinhaltend“, „aufweisend“ und dergleichen, wie sie mit Bezug auf Ausführungsformen der vorliegenden Offenbarung verwendet werden, synonym.
  • Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“ zusammen mit Ableitungen davon werden hierin verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass sich zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander befinden, er kann bedeuten, dass zwei oder mehr Elemente indirekt miteinander in Kontakt stehen, aber immer noch miteinander zusammenwirken oder interagieren, und/oder er kann bedeuten, dass ein oder mehrere andere Elemente zwischen die Elemente gekoppelt oder geschaltet sind, die als miteinander gekoppelt bezeichnet werden. Der Begriff „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt miteinander stehen. Der Begriff „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente durch ein Kommunikationsmittel, unter anderem durch einen Draht oder eine andere Zwischenverbindung, durch einen Drahtloskommunikationskanal oder eine Drahtloskommunikationstinte und/oder dergleichen miteinander in Kontakt stehen können.
  • Der Begriff „Schaltungsanordnung“ bezieht sich auf eine Schaltung oder ein System mehrerer Schaltungen, die bzw. das dazu konfiguriert ist, eine spezielle Funktion in einer elektronischen Vorrichtung durchzuführen. Die Schaltung oder das System von Schaltungen kann Teil einer oder mehrerer Hardwarekomponenten sein oder diese umfassen, wie etwa eine Logikschaltung, ein Prozessor (gemeinsam genutzt, dediziert oder Gruppe) und/oder ein Speicher (gemeinsam genutzt, dediziert oder als Gruppe), ein ASIC, ein FPGA, eine programmierbare Logiksteuerung (PLC), SoC, SiP, ein Mehrchipgehäuse (MCP), DSP usw., die dazu konfiguriert sind, die beschriebene Funktionalität bereitzustellen. Außerdem kann sich der Begriff „Schaltungsanordnung“ auch auf eine Kombination eines oder mehrerer Hardwareelemente mit dem Programmcode beziehen, der zum Ausführen der Funktionalität dieses Programmcodes verwendet wird. Einige Arten von Schaltungsanordnungen können ein oder mehrere Software- oder Firmware-Programme ausführen, um wenigstens einen Teil der beschriebenen Funktionalität bereitzustellen. Eine solche Kombination von Hardwareelementen und Programmcode kann als ein bestimmter Schaltungstyp bezeichnet werden.
  • Es versteht sich, dass die in dieser Schrift beschriebenen funktionalen Einheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um insbesondere ihre Implementierungsunabhängigkeit hervorzuheben. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen verkörpert werden. Beispielsweise kann eine Komponente oder ein Modul als Hardware-Schaltung implementiert werden, die angepasste Very-Large-Scale-Integration(VLSI)-Schaltungen oder Gatterarrays, handelsübliche Halbleiter, wie etwa Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert werden, wie beispielsweise feldprogrammierbare Gatterarrays, programmierbare Arraylogik, programmierbare Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert werden. Eine identifizierte Komponente oder ein identifiziertes Modul aus ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Elemente einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen lokalisiert sein, sondern können ungleiche Anweisungen umfassen, die an verschiedenen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden sind, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erfüllen.
  • Tatsächlich kann eine Komponente oder ein Modul eines ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und sogar kann über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über einige Speichervorrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können manche Aspekte des beschriebenen Prozesses (wie Codeumschreiben und Codeanalyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Datenzentrum) als jenem stattfinden, in dem der Code eingesetzt wird (z. B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Auf ähnliche Weise können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und dargestellt werden und können in einer beliebigen geeigneten Form ausgeführt und in einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als einziger Datensatz erfasst werden oder können über verschiedene Orte, einschließlich über verschiedene Speicherungsvorrichtungen, verteilt werden und können zumindest teilweise lediglich als elektronische Signale in einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die dazu betreibbar sind, gewünschte Funktionen auszuführen.
  • Der Begriff „Prozessorschaltungsanordnung“, wie hierin verwendet, bezieht sich auf eine Schaltungsanordnung, die zum sequenziellen und automatischen Ausführen einer Sequenz arithmetischer oder logischer Operationen oder Aufzeichnen, Speichern und/oder Übertragen digitaler Daten in der Lage ist, ist Teil davon oder umfasst eine solche. Der Begriff „Prozessorschaltungsanordnung“ kann sich auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische CPU, einen Einkernprozessor, einen Doppelkernprozessor, einen Dreikernprozessor, einen Vierkernprozessor und/oder eine beliebige andere Vorrichtung beziehen, die in der Lage ist, computerausführbare Anweisungen, wie etwa Programmcode, Softwaremodule und/oder Funktionsprozesse, auszuführen oder anderweitig zu betreiben. Die Begriffe „Anwendungsschaltungsanordnung“ und/oder „Basisbandschaltungsanordnung“ können als Synonyme für „Prozessorschaltungsanordnung“ angesehen und so bezeichnet werden.
  • Der Begriff „Speicher“ und/oder „Speicherschaltungsanordnung“, wie hierin verwendet, bezieht sich auf eine oder mehrere Hardwarevorrichtungen zum Speichern von Daten, einschließlich RAM, MRAM, PRAM, DRAM und/oder SDRAM, Kernspeicher, ROM, Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen oder andere maschinenlesbare Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann unter anderem Speicher, tragbare oder feste Speicherungsvorrichtungen, optische Speicherungsvorrichtungen und verschiedene andere Medien umfassen, die zum Speichern, Enthalten oder Transportieren von Anweisungen in der Lage sind.
  • Der Begriff „Schnittstellenschaltungsanordnung“, wie hierin verwendet, bezieht sich auf eine Schaltungsanordnung, die den Austausch von Informationen zwischen zwei oder mehr Komponenten oder Vorrichtungen ermöglicht, ist Teil davon oder umfasst eine solche. Der Begriff „Schnittstellenschaltungsanordnung“ kann sich auf eine oder mehrere Hardwareschnittstellen beziehen, zum Beispiel Busse, E/A-Schnittstellen, Peripheriekomponentenschnittstellen, Netzwerkschnittstellenkarten und/oder dergleichen.
  • Der Begriff „Element“ bezieht sich auf eine Einheit, die bei einem gegebenen Abstraktionsniveau unteilbar ist und eine klar definierte Grenze aufweist, wobei ein Element eine beliebige Art von Entität sein kann, die zum Beispiel eine oder mehrere Vorrichtungen, Systeme, Steuerungen, Netzwerkelemente, Module usw. oder Kombinationen davon umfasst. Der Begriff „Vorrichtung“ bezieht sich auf eine physische Entität, die innerhalb einer anderen physischen Entität in ihrer Nähe eingebettet oder an dieser angebracht ist, mit Fähigkeiten zum Übermitteln von digitalen Informationen von oder zu dieser physischen Entität. Der Begriff „Entität“ bezieht sich auf eine individuelle Komponente einer Architektur oder Vorrichtung oder als Nutzlast übertragene Informationen. Der Begriff „Steuerung“ bezieht sich auf ein Element oder eine Entität, das/die die Fähigkeit aufweist, eine physische Entität zu beeinflussen, wie etwa durch Ändern ihres Zustands oder Veranlassen der physischen Entität, sich zu bewegen.
  • Wie hierin verwendet, umfasst der Begriff „Edge-Computing“ viele Implementierungen verteilter Berechnung, die in einem Bestreben, die Latenz zu reduzieren und den Durchsatz für Endpunktbenutzer (Client-Vorrichtungen, Benutzergeräte usw.) zu erhöhen, Verarbeitungsaktivitäten und -ressourcen (z. B. Rechen-, Speicherungs-, Beschleunigungsressourcen) an den Rand (die „Edge“) des Netzwerks bewegen. Solche Edge-Computing-Implementierungen umfassen typischerweise das Anbieten solcher Aktivitäten und Ressourcen in Cloud-ähnlichen Diensten, Funktionen, Anwendungen und Subsystemen von einem oder mehreren Orten, auf die über drahtlose Netzwerke zugegriffen werden kann. Somit sind die Verweise auf eine „Edge (einen Rand)“ eines Netzwerks, Clusters, einer Domäne, eines Systems oder einer Rechenanordnung, die hierin verwendet werden, Gruppen oder Gruppierungen funktioneller verteilter Rechenelemente und stehen daher im Allgemeinen nicht mit „Edges (Kanten)“ (Verknüpfungen oder Verbindungen), wie sie in der Graphentheorie verwendet werden, in Zusammenhang. Spezifische Anordnungen von Edge-Computing-Anwendungen und -Diensten, die über Mobilfunknetzwerke (z. B. zelluläre und WiFi-Datennetzwerke) zugänglich sind, können als „Mobile Edge Computing“ oder „Multi-Access Edge Computing“ bezeichnet werden, worauf mit dem Akronym „MEC“ Bezug genommen werden kann. Die Verwendung von „MEC“ hierin kann sich auch auf eine standardisierte Implementierung beziehen, die vom European Telecommunications Standards Institute (ETSI) veröffentlicht und als „ETSI-MEC“ bezeichnet wird. Die in der ETSI-MEC-Spezifikation verwendete Terminologie wird hierin im Allgemeinen durch Bezugnahme aufgenommen, es sei denn, es wird hierin eine widersprüchliche Definition oder Verwendung angegeben.
  • Wie hierin verwendet, bezieht sich der Begriff „Rechenknoten“ oder „Rechenvorrichtung“ auf eine identifizierbare Entität, die einen Aspekt von Edge-Rechenoperationen implementiert, sei es als Teil eines größeren Systems, einer verteilten Sammlung von Systemen oder eine eigenständige Einrichtung. In einigen Beispielen kann ein Rechenknoten als ein „Edge-Knoten“, eine „Edge-Vorrichtung“, ein „Edge-System“ bezeichnet werden, sei es im Einsatz als Client, Server oder Zwischenentität. Spezifische Implementierungen eines Computerknotens können in einen Server, eine Basisstation, ein Gateway, eine Straßenrandeinheit, eine Vor-Ort-Einheit, ein UE oder eine Endverbrauchsvorrichtung oder dergleichen integriert sein.
  • Der Begriff „Computersystem“, wie hierin verwendet, bezieht sich auf jede Art von miteinander verbundenen elektronischen Vorrichtungen, Computervorrichtungen oder Komponenten davon. Außerdem 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 Computersysteme beziehen, die kommunikativ miteinander gekoppelt und dazu ausgelegt sind, Rechen- und/oder Vernetzungsressourcen gemeinsam zu nutzen.
  • Der Begriff „Architektur“, wie hierin verwendet, bezieht sich auf eine Computerarchitektur oder eine Netzwerkarchitektur. Eine „Netzwerkarchitektur“ ist eine physische und logische Struktur oder Anordnung von Software- und/oder Hardwareelementen in einem Netzwerk mit Kommunikationsprotokollen, Schnittstellen und Medienübertragung. Eine „Computerarchitektur“ ist eine physische und logische Struktur oder Anordnung von Software- und/oder Hardwareelementen in einem Computersystem oder einer Computerplattform mit Technologiestandards für Interaktionen dazwischen.
  • Der Begriff „Gerät“, „Computergerät“ oder dergleichen, wie hierin verwendet, bezieht sich auf eine Computervorrichtung oder ein Computersystem mit Programmcode (z. B. Software oder Firmware), der speziell zum Bereitstellen einer spezifischen Rechenressource konzipiert ist. Ein „virtuelles Gerät“ ist ein virtuelles Maschinenabbild, das durch eine mit einem Hypervisor ausgestattete Vorrichtung zu implementieren ist, die ein Computergerät virtualisiert oder emuliert oder anderweitig dazu bestimmt ist, eine spezifische Rechenressource bereitzustellen.
  • Der Begriff „Benutzergerät“ oder „UE“, wie hierin verwendet, bezieht sich auf eine Vorrichtung mit Funkkommunikationsfähigkeiten und kann einen Remotebenutzer von Netzwerkressourcen in einem Kommunikationsnetzwerk beschreiben. Der Begriff „Benutzergerät“ oder „UE“ kann als Synonym für Client, Mobilteil, Mobilvorrichtung, Mobilendgerät, Benutzerendgerät, Mobileinheit, Station, Mobilstation, Mobilbenutzer, Teilnehmer, Benutzer, Remotestation, Zugriffsagent, Benutzeragent, Empfänger, Funkgerät, rekonfigurierbares Funkgerät, rekonfigurierbare Mobilvorrichtung usw. angesehen und als solche bezeichnet werden. Des Weiteren kann der Begriff „Benutzergerät“ oder „UE“ jede Art von drahtloser/drahtgebundener Vorrichtung oder jede Rechenvorrichtung mit einer drahtlosen Kommunikationsschnittstelle umfassen. Der Begriff „Station“ oder „STA“ bezieht sich auf eine logische Entität, die eine einzeln adressierbare Instanz einer Medienzugangssteuerung(MAC)- und einer Bitübertragungsschicht(PHY)-Schnittstelle zum drahtlosen Medium (WM) ist. Der Begriff „drahtloses Medium“ oder „WM“ bezieht sich auf das Medium, das verwendet wird, um die Übertragung von Protokolldateneinheiten (PDUs) zwischen Peer-Bitübertragungsschicht(PHY)-Entitäten eines drahtlosen lokalen Netzwerks (LAN) zu implementieren.
  • Der Begriff „Netzwerkelement“, wie hierin verwendet, bezieht sich auf physisches oder virtualisiertes Gerät und/oder eine physische oder virtualisierte Infrastruktur, die zum Bereitstellen von drahtgebundenen oder drahtlosen Kommunikationsnetzdiensten verwendet werden. Der Begriff „Netzwerkelement“ kann als Synonym für einen vernetzten Computer, eine vernetzte Hardware, ein Netzwerkgerät, einen Netzwerkknoten, einen Router, einen Switch, einen Hub, eine Brücke, eine Funknetzsteuerung, eine RAN-Vorrichtung, einen RAN-Knoten, ein Gateway, einen Server, eine virtualisierte VNF, NFVI und/oder dergleichen angesehen und/oder als solche bezeichnet werden.
  • Wie hierin verwendet, bezieht sich der Begriff „Zugangspunkt“ oder „AP“ auf eine Entität, die eine Station (STA) enthält und über das drahtlose Medium (WM) Zugriff für assoziierte STAs auf die Verteilungsdienste bereitstellt. Ein AP umfasst eine STA und eine Verteilsystemzugangsfunktion (DSAF). Wie hierin verwendet, bezieht sich der Begriff „Basisstation“ auf ein Netzwerkelement in einem Funkzugangsnetzwerk (RAN), wie etwa einem Mobilkommunikationsnetzwerk der vierten Generation (4G) oder der fünften Generation (5G), das für die Übertragung und den Empfang von Funksignalen in einer oder mehreren Zellen zu oder von einem Benutzergerät (UE) verantwortlich ist. Eine Basisstation kann eine integrierte Antenne aufweisen oder über Zubringerkabel mit einem Antennenarray verbunden sein. Eine Basisstation verwendet spezialisierte digitale Signalverarbeitung und Netzwerkfunktionshardware. Bei manchen Beispielen kann die Basisstation für Flexibilität, Kosten und Leistungsfähigkeit in mehrere Funktionsblöcke aufgeteilt sein, die in Software arbeiten. Bei manchen Beispielen kann eine Basisstation eine evolved node-B (eNB) oder eine Next Generation node-B (gNB) beinhalten. Bei manchen Beispielen kann die Basisstation Rechenhardware betreiben oder beinhalten, um als ein Rechenknoten zu arbeiten. Bei vielen der hierin besprochenen Szenarien kann jedoch eine RAN-Basisstation durch einen Zugangspunkt (z. B. Drahtlosnetzwerkzugangspunkt) oder eine andere Netzwerkzugangshardware ersetzt werden.
  • Wie hierin verwendet, bezeichnet der Begriff „Zentrale“ (oder CO) einen Aggregationspunkt für eine Telekommunikationsinfrastruktur innerhalb eines zugänglichen oder definierten geografischen Gebiets, an dem Telekommunikationsdienstanbieter traditioneller Weise häufig Vermittlungseinrichtungen für einen oder mehrere Typen von Zugangsnetzwerken angeordnet haben. Die CO kann physisch ausgelegt sein, um Telekommunikationsinfrastrukturgeräte oder Rechen-, Datenspeicherungs- und Netzwerkressourcen unterzubringen. Die CO muss jedoch kein designierter Ort eines Telekommunikationsdienstanbieters sein. Die CO kann eine beliebige Anzahl von Rechenvorrichtungen für Edge-Anwendungen und -Dienste oder sogar lokale Implementierungen von Cloud-ähnlichen Diensten hosten.
  • Der Begriff „Cloud-Computing“ oder „Cloud“ bezieht sich auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Pool von gemeinsam nutzbaren Rechenressourcen mit Self-Service-Bereitstellung und -Verwaltung bei Bedarf und ohne aktive Verwaltung durch Benutzer Cloud-Computing stellt Cloud-Computing-Dienste (oder Cloud-Dienste) bereit, bei denen es sich um eine oder mehrere über Cloud-Computing angebotene Fähigkeiten handelt, die unter Verwendung einer definierten Schnittstelle (z. B. einer API oder dergleichen) aufgerufen werden. Der Begriff „Rechenressource“ oder einfach „Ressource“ bezieht sich auf eine beliebige physische oder virtuelle Komponente oder Verwendung solcher Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Ressourcen umfassen Nutzung von/Zugriff auf Server, Prozessor(en), Datenspeichergeräte, Arbeitsspeichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, (periphere) Eingabe-/Ausgabevorrichtungen, mechanische Vorrichtungen, Netzwerkverbindungen (z. B. Kanäle/Links, Ports, Netzwerkbuchsen usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen für eine Zeitdauer. Eine „Hardwareressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die durch eine oder mehrere physische Hardwareelemente bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die durch eine Virtualisierungsinfrastruktur für eine Anwendung, eine Vorrichtung, ein System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, auf die Computervorrichtungen/Systeme über ein Kommunikationsnetzwerk zugreifen können. Der Begriff „Systemressourcen“ kann sich auf eine jede Art gemeinsam genutzter Entitäten zum Bereitstellen von Diensten beziehen und Rechen- und/oder Netzwerkressourcen umfassen. Systemressourcen können als ein Satz von kohärenten Funktionen, Netzwerkdatenobjekten oder Diensten betrachtet werden, auf die durch einen Server zugegriffen werden kann, wenn sich solche Systemressourcen auf einem einzigen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind.
  • Der Begriff „Arbeitslast“ bezieht sich auf eine Menge an Arbeit, die durch ein Datenverarbeitungssystem, eine Vorrichtung, eine Entität usw. während eines Zeitraums oder zu einem bestimmten Zeitpunkt durchgeführt wird. Eine Arbeitslast kann als ein Benchmark dargestellt werden, wie etwa eine Reaktionszeit, ein Durchsatz (z. B. wie viel Arbeit über einen Zeitraum durchgeführt wird) und/oder dergleichen. Zusätzlich oder alternativ dazu kann die Arbeitslast als eine Speicherarbeitslast (z. B. eine Menge an Speicherplatz, der zur Programmausführung benötigt wird, um temporäre oder permanente Daten zu speichern und Zwischenberechnungen durchzuführen), eine Prozessorarbeitslast (z. B. eine Anzahl an Anweisungen, die von einem Prozessor während einer gegebenen Zeitspanne oder zu einem bestimmten Zeitpunkt ausgeführt werden), eine E/A-Arbeitslast (z. B. eine Anzahl von Ein- und Ausgaben oder Systemzugriffen während eines gegebenen Zeitraums oder zu einem bestimmten Zeitpunkt), Datenbankarbeitslasten (z. B. eine Anzahl von Datenbankabfragen während eines Zeitraums), eine netzwerkbezogene Arbeitslast (z. B. eine Anzahl von Netzwerkanbindungen, eine Anzahl von Mobilitätsaktualisierungen, eine Anzahl von Funkverbindungsfehlern, eine Anzahl von Handovers, eine Menge von über eine Luft Schnittstelle zu übertragenden Daten usw.) und/oder dergleichen dargestellt werden. Verschiedene Algorithmen können verwendet werden, um eine Arbeitslast und/oder Arbeitslastcharakteristiken zu bestimmen, die auf einem beliebigen der zuvor genannten Arbeitslasttypen basieren können.
  • Wie hierin verwendet, bezeichnet der Begriff „Cloud-Dienstanbieter“ (oder CSP) eine Organisation, die typischerweise umfangreiche „Cloud“-Ressourcen betreibt, die zentralisierte, regionale und Edge-Datenzentren (z. B. wie im Kontext der öffentlichen Cloud verwendet) umfassen. In anderen Beispielen kann ein CSP auch als Cloud-Dienstbetreiber (CSO) bezeichnet werden. Verweise auf „Cloud-Computing“ beziehen sich im Allgemeinen auf Rechenressourcen und -dienste, die von einem CSP oder einem CSO an entfernten Orten mit zumindest etwas erhöhter Latenz, Entfernung oder Beschränkung im Verhältnis zu Edge-Computing angeboten werden.
  • Wie hierin verwendet, bezieht sich der Begriff „Datenzentrum“ auf eine zweckbestimmte Struktur, die mehrere Hochleistungs-Rechen- und -Datenspeicherknoten beherbergen soll, so dass eine große Menge an Rechen-, Datenspeicher- und Netzwerkressourcen an einem einzigen Ort vorhanden ist. Dabei handelt es sich häufig um spezialisierte Rack- und Gehäusesysteme, geeignete Heiz-, Kühl-, Lüftungs-, Sicherheits-, Brandunterdrückungs- und Stromversorgungssysteme. Der Begriff kann sich in einigen Zusammenhängen auch auf einen Rechen- und Datenspeicherknoten beziehen. Ein Datenzentrum kann im Maßstab zwischen einem (z. B. größten) zentralisierten oder Cloud-Datenzentrum, einem regionalen Datenzentrum und einem (z. B. kleinsten) Edge-Datenzentrum variieren.
  • Wie hierin verwendet, bezeichnet der Begriff „Edge-Zugriffsschicht“ die Unterschicht des Infrastrukturrands, die dem Endbenutzer oder der Endvorrichtung am nächsten ist. Eine solche Schicht kann zum Beispiel durch ein Edge-Datenzentrum verwirklicht werden, das an einem zellulären Netzwerkstandort bereitgestellt wird. Die Edge-Zugriffsschicht fungiert als die vordere Linie des Infrastrukturrands und kann eine Verbindung mit einer Edge-Aggregationsschicht herstellen, die in der Hierarchie höher ist.
  • Wie hierin verwendet, bezeichnet der Begriff „Edge-Aggregationsschicht“ die einen Sprung von der Edge-Zugriffsschicht entfernte Schicht des Infrastrukturrands. Diese Schicht kann entweder als ein Datenzentrum mittleren Maßstabs an einem einzigen Ort existieren oder aus mehreren miteinander verbundenen Mikrodatenzentren gebildet sein, um eine hierarchische Topologie mit der Edge-Zugriffschicht zu bilden, um bessere Zusammenarbeit, Arbeitslastausfallsicherung und Skalierbarkeit als die Edge-Zugriffschicht allein zu ermöglichen.
  • Wie hierin verwendet, bezeichnet der Begriff „Netzwerkfunktionsvirtualisierung“ (oder NFV) die Migration von NFs von eingebetteten Diensten innerhalb proprietärer Hardwaregeräte zu softwarebasierten virtualisierten NFs (oder VNFs), die auf standardisierten CPUs (z. B. innerhalb standardmäßiger x86®- und ARM®-Server wie etwa jenen, die Intel® Xeon™- oder AMD® Epyc™- oder Opteron™-Prozessoren umfassen) unter Verwendung von Virtualisierungs- und Cloud-Rechentechnologien nach Industriestandard ausgeführt werden. Bei einigen Aspekten finden NFV-Verarbeitung und -Datenspeicherung an den Edge-Datenzentren statt, die direkt mit dem lokalen zellularen Standort innerhalb des Infrastrukturrands verbunden sind.
  • Wie hierin verwendet, bezeichnet der Begriff „virtualisierte NF“ (oder VNF) eine softwarebasierte NF, die auf Multifunktions-Mehrzweck-Rechenressourcen (z. B. x86, ARM-Verarbeitungsarchitektur) arbeitet, die von NFV anstelle dedizierter physischer Ausrüstung verwendet werden. Bei einigen Aspekten arbeiten mehrere VNFs an einem Edge-Datenzentrum am Infrastrukturrand.
  • Wie hierin verwendet, bezieht sich der Begriff „Edge-Rechenknoten“ auf eine logische oder virtualisierte Implementierung eines rechenfähigen Elements der realen Welt in Form einer Vorrichtung, eines Gateways, einer Brücke, eines Systems oder eines Subsystems, einer Komponente, sei es dass es in einem Server-, Client-, Endpunkt- oder Peer-Modus arbeitet und sei es dass es sich an einem Rand eines Netzwerks oder an einem verbundenen Ort weiter innerhalb des Netzwerks befindet. Bezugnahmen auf einen „Knoten“, die hierin verwendet werden, sind im Allgemeinen mit „Vorrichtung“, „Komponente“ und „Subsystem“ austauschbar; Bezugnahmen auf ein „Edge-Computing-System“ beziehen sich jedoch im Allgemeinen auf eine verteilte Architektur, Organisation oder Sammlung mehrerer Knoten und Vorrichtungen, die organisiert ist, um einen gewissen Aspekt von Diensten oder Ressourcen in einer Edge-Computing-Umgebung zu erreichen oder anzubieten.
  • Wie hierin verwendet, bezieht sich der Begriff „Cluster“ auf einen Satz oder eine Gruppierung von Entitäten als Teil eines Edge-Computing-Systems (oder von Edge-Computing-Systemen) in Form von physischen Entitäten (z. B. verschiedenen Computersystemen, Netzwerken oder Netzwerkgruppen), logischen Entitäten (z. B. Anwendungen, Funktionen, Sicherheitskonstrukten, Containern) und dergleichen. An einigen Stellen wird „Cluster“ auch als „Gruppe“ oder eine „Domäne“ bezeichnet. Die Zugehörigkeit zu einem Cluster kann basierend auf Bedingungen oder Funktionen modifiziert oder beeinflusst werden, darunter dynamische oder eigenschaftsbasierte Zugehörigkeit, Netzwerk- oder Systemverwaltungsszenarien oder verschiedene unten erörterte beispielhafte Techniken, die eine Entität in einem Cluster hinzufügen, modifizieren oder entfernen können. Cluster können auch mehrere Schichten, Ebenen oder Eigenschaften, die Variationen von Sicherheitsmerkmalen und Ergebnissen umfassen, die auf solchen Schichten, Ebenen oder Eigenschaften basieren, umfassen oder damit assoziiert sein.
  • Wie hierin verwendet, bezieht sich der Begriff „Funktechnologie“ auf Technologie für drahtloses Senden und/oder Empfangen elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugangstechnologie“ oder „RAT“ bezieht sich auf die Technologie, die für die zugrundeliegende physikalische Verbindung zu einem funkbasierten Kommunikationsnetzwerk verwendet wird. Der Begriff „V2X“ bezieht sich auf Kommunikationen von Fahrzeug zu Fahrzeug (V2V), Fahrzeug zu Infrastruktur (V2I), Infrastruktur zu Fahrzeug (I2V), Fahrzeug zu Netzwerk (V2N) und/oder Netzwerk zu Fahrzeug (N2V) und assoziierte Funkzugangstechnologien (RATs).
  • Wie hierin verwendet, bezieht sich der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) auf einen Satz standardisierter Regeln oder Anweisungen, die durch eine Kommunikationsvorrichtung und/oder ein Kommunikationssystem implementiert werden, um mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, und die Anweisungen zum Paketieren/Depaketieren von Daten, Modulieren/Demodulieren von Signalen, Implementieren von Protokollstapeln und/oder dergleichen umfassen. Der Begriff „Kanal“, wie hierin verwendet, bezieht sich auf ein jedes gegenständliche oder nichtgegenständliche Übertragungsmedium, das verwendet wird, um Daten oder einen Datenstrom zu kommunizieren. Der Begriff „Kanal“ kann synonym zu und/oder gleichbedeutend mit „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugriffskanal“, „Datenzugriffskanal“, „Link“, „Datenlink“, „Träger“, „Hochfrequenzträger“ und/oder jedem anderen ähnlichen Begriff sein, der einen Pfad oder ein Medium bezeichnet, über den/das Daten kommuniziert werden. Außerdem bezieht sich der Begriff „Link“, wie hierin verwendet, auf eine Verbindung zwischen zwei Vorrichtungen durch eine RAT zum Zweck des Sendens und Empfangens von Informationen.
  • Der Begriff „Dienstgüte“ oder „QoS (Qualtity of Service“ bezieht sich auf eine Beschreibung oder Messung der Gesamtleistungsfähigkeit eines Dienstes (z. B. Fernsprech- und/oder zellulärer Dienst, Netzwerkdienst, Drahtloskommunikations-/Konnektivitätsdienst, Cloud-Rechendienst usw.). Bei manchen Fällen kann die QoS aus der Perspektive der Benutzer dieses Dienstes beschrieben oder gemessen werden, und somit kann QoS der kollektive Effekt der Dienstleistungsfähigkeit sein, der den Grad der Zufriedenheit eines Benutzers dieses Dienstes bestimmt. In anderen Fällen bezieht sich QoS auf Verkehrspriorisierungs- und Ressourcenreservierungssteuermechanismen anstelle der erreichten Wahrnehmung der Dienstqualität. In diesen Fällen ist QoS die Fähigkeit, unterschiedliche Anwendungen, Benutzern oder Datenflüssen mit unterschiedlichen Prioritäten zu versehen oder einem Datenfluss einen gewissen Leistungsfähigkeitsgrad zu garantieren. In beiden Fällen ist QoS durch die kombinierten Aspekte von Leistungsfähigkeitsfaktoren gekennzeichnet, die für einen oder mehrere Dienste gelten, wie zum Beispiel Dienstoperabilitätsleistungsfähigkeit, Dienstzugänglichkeitsleistungsfähigkeit, Dienstbeibehaltungsfähigkeitsleistungsfähigkeit, Dienstzuverlässigkeitsleistungsfähigkeit, Dienstintegritätsleistungsfähigkeit und andere Faktoren, die für jeden Dienst spezifisch sind. Mehrere verwandte Aspekte des Dienstes können berücksichtigt werden, wenn die QoS quantifiziert wird, einschließlich Paketverlustraten, Bitraten, Durchsatz, Übertragungsverzögerung, Verfügbarkeit, Zuverlässigkeit, Jitter, Signalstärke und/oder Qualitätsmessungen und/oder andere Messungen, wie etwa den hierin besprochenen.
  • Die Begriffe „Instanziieren“, „Instanziierung“ und dergleichen, wie hierin verwendet, beziehen sich auf die Erzeugung einer Instanz. Eine „Instanz“ bezieht auch auf ein konkretes Auftreten eines Objekts, das zum Beispiel während der Ausführung von Programmcode auftreten kann. Der Begriff „Informationselement“ bezieht sich auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff „Feld“ bezieht sich auf individuelle Inhalte eines Informationselements oder eines Datenelements, das Inhalte enthält. Der Begriff „Datenbankobjekt“, „Datenstruktur“ oder dergleichen kann sich auf jede Darstellung von Informationen beziehen, die in Form eines Objekts, Attributwertepaars (AVP), Schlüsselwertepaars (KVP), Tupels usw. vorliegen, und kann Variablen, Datenstrukturen, Funktionen, Verfahren, Klassen, Datenbankaufzeichnungen, Datenbankfelder, Datenbankentitäten, Assoziationen zwischen Daten und/oder Datenbankentitäten (auch als „Beziehung“ bezeichnet), Blöcke und Verknüpfungen zwischen Blöcken in Blockchain-Implementierungen und/oder dergleichen umfassen. Der Begriff „Datenelement“ oder „DE“ bezieht sich auf einen Datentyp, der ein einziges Datenelement enthält. Der Begriff „Datenrahmen“ oder „DF“ (Data Frame) bezieht sich auf einen Datentyp, der mehr als ein Datenelement in einer vorgegebenen Reihenfolge enthält.
  • Wie hierin verwendet, bezieht sich der Begriff „Zuverlässigkeit“ auf die Fähigkeit einer computerbezogenen Komponente (z. B. Software, Hardware oder Netzwerkelement/- entität), konsistent eine gewünschte Funktion durchzuführen und/oder gemäß einer Spezifikation zu arbeiten. Zuverlässigkeit im Kontext von Netzwerkkommunikationen (z. B. „Netzwerkzuverlässigkeit“) kann sich auf die Fähigkeit eines Netzwerks zum Durchführen von Kommunikation beziehen. Netzwerkzuverlässigkeit kann auch die (oder ein Maß der) Wahrscheinlichkeit sein, dass eine spezifizierte Datenmenge von einer Quelle an ein Ziel (oder einer Senke) übermittelt wird.
  • Der Begriff „Anwendung“ kann sich auf eine vollständige und bereitstellbare Paketumgebung zum Ausführen einer bestimmte Funktion in einer Betriebsumgebung beziehen. Der Begriff „AI/ML-Anwendung“ oder dergleichen kann eine Anwendung sein, die einige AI/ML-Modelle und Beschreibungen auf Anwendungsebene enthält. Der Begriff „maschinelles Lernen“ oder „ML“ bezieht sich auf die Verwendung von Computersystemen, die Algorithmen und/oder statistische Modelle implementieren, um eine oder mehrere spezifische Aufgaben durchzuführen, wobei keine expliziten Anweisungen verwendet werden, sondern stattdessen auf Muster und Inferenzen gebaut wird. ML-Algorithmen erstellen oder schätzen mathematische Modell(e) (als „ML-Modelle“ oder dergleichen bezeichnet) basierend auf Sample-Daten (als „Trainingsdaten“, „Modelltrainingsinformationen“ oder dergleichen bezeichnet), um Vorhersagen oder Entscheidungen zu treffen, ohne zum Durchführen solcher Aufgaben explizit programmiert zu sein. Im Allgemeinen ist ein ML-Algorithmus ein Computerprogramm, das aus Erfahrung in Bezug auf irgendeine Aufgabe und irgendeine Leistungsmaßnahme lernt, und ein ML-Modell kann ein beliebiges Objekt oder eine beliebige Datenstruktur sein, die erzeugt werden, nachdem ein ML-Algorithmus mit einem oder mehreren Trainingsdatensätzen trainiert wurde. Nach dem Training kann ein ML-Modell verwendet werden, um Vorhersagen über neue Datensätze zu treffen. Obwohl sich der Begriff „ML-Algorithmus“ auf andere Konzepte als der Begriff „ML-Modell“ bezieht, können diese Begriffe, wie hierin erörtert, für die Zwecke der vorliegenden Offenbarung austauschbar verwendet werden.
  • Obwohl viele der vorherigen Beispiele unter Verwendung spezieller zellulärer/mobiler Netzwerkterminologie bereitgestellt wurden, einschließlich der Verwendung von 4G/5G-3GPP-Netzwerkkomponenten (oder erwarteten 6G/6G+ Technologien auf Terahertzbasis), versteht es sich, dass diese Beispiele auf viele andere Bereitstellungen von Weiterverkehrs- und lokalen drahtlosen Netzwerken sowie die Integration von drahtgebundenen Netzwerken (einschließlich optischer Netzwerke und zugehöriger Fasern, Sendeempfänger usw.) angewendet werden können.
  • Obwohl diese Implementierungen unter Bezugnahme auf spezifische beispielhafte Aspekte beschrieben wurden, versteht es sich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzumfang der vorliegenden Offenbarung abzuweichen. Viele der hierin beschriebenen Anordnungen und Prozesse können in Kombination oder in parallelen Implementierungen verwendet werden, um eine größere Bandbreite/einen größeren Durchsatz bereitzustellen und Edge-Dienst-Auswahlmöglichkeiten zu unterstützen, die den zu bedienenden Edge-Systemen zur Verfügung gestellt werden können. Entsprechend sind die Beschreibung und die Zeichnungen in einem veranschaulichenden und nicht in einem einschränkenden Sinne aufzufassen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen spezielle Aspekte, in denen der Gegenstand ausgeführt werden kann, als Veranschaulichung und nicht als Beschränkung. Die veranschaulichten Aspekte sind hinreichend detailliert beschrieben, um einen Fachmann zu befähigen, die hierin offenbarten Lehren in die Praxis umzusetzen. Andere Aspekte können genutzt und aus diesen abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne den Schutzumfang dieser Offenbarung zu verlassen. Diese ausführliche Beschreibung ist daher nicht in einem beschränkenden Sinn aufzufassen und der Schutzumfang verschiedener Aspekte ist nur durch die angehängten Ansprüche, zusammen mit dem vollen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigt sind, definiert.
  • Solche Aspekte des Erfindungsgegenstands können hierin lediglich der Einfachheit halber und ohne die Absicht, den Schutzumfang dieser Anmeldung willentlich auf einen einzigen Aspekt oder Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart sind, einzeln oder zusammen erwähnt sein. Obwohl spezielle Aspekte hierin veranschaulicht und beschrieben wurden, sollte man daher verstehen, dass eine beliebige Einrichtung, die berechnet ist, um denselben Zweck zu erfüllen, die gezeigten speziellen Ausführungsformen ersetzen kann. Diese Offenbarung soll jegliche und alle Anpassungen oder Variationen verschiedener Aspekte abdecken. Kombinationen der obigen Aspekte und andere Aspekte, die hierin nicht speziell beschrieben sind, ergeben sich für Fachleute bei der Durchsicht der oben stehenden Beschreibung.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62/844413 [0001]
    • US 62/854871 [0001]

Claims (25)

  1. Einrichtung zum Einsatz als Mehrfachzugriffs-Edge-Computing(MEC)-Host, der zusammen mit einer Netzwerkzugangsinfrastruktur angeordnet ist, wobei die Einrichtung Folgendes umfasst: eine Schnittstellenschaltungsanordnung, ausgelegt zum Empfangen einer Anforderungsnachricht für eine vorhergesagte Dienstgüte (QoS: Quality of Service) für einen Drahtloskommunikationsdienst entlang einer geplanten Route eines Fahrzeugbenutzergeräts (vUE), wobei die Anforderungsnachricht Standortinformationen (LocationInfo) für jeden Punkt von mindestens zwei Punkten entlang der geplanten Route und einen Zeitstempel für jeden Punkt der mindestens zwei Punkte beinhaltet; und eine Prozessorschaltungsanordnung, die kommunikativ mit der Schnittstellenschaltungsanordnung gekoppelt ist, wobei die Prozessorschaltungsanordnung ausgelegt ist zum Bestimmen, als Reaktion auf den Empfang der Anforderungsnachricht, der vorhergesagten QoS für den Drahtloskommunikationsdienst für das vUE entlang der geplanten Route basierend auf dem Standort und dem Zeitstempel für jeden Punkt.
  2. Einrichtung nach Anspruch 1, wobei die Anforderungsnachricht ferner ein Routendatenelement umfasst, wobei das Routendatenelement Informationen bezüglich einer potenziellen Route des vUE beinhaltet.
  3. Einrichtung nach Anspruch 2, wobei das Routendatenelement ein Routeninformations(routeInfo)-Datenelement für jeden Punkt der mindestens zwei Punkte umfasst.
  4. Einrichtung nach Anspruch 3, wobei ein erstes routeInfo-Datenelement, das in dem Routendatenelement enthalten ist, einem Ausgangspunkt der geplanten Route entspricht und ein letztes routeInfo-Datenelement, das in dem Routendatenelement enthalten ist, einem Ziel der geplanten Route entspricht.
  5. Einrichtung nach Anspruch 4, wobei das Routendatenelement ferner ein oder mehrere routeInfo-Zwischendatenelemente umfasst, von denen jedes einem jeweiligen Zwischenpunkt zwischen dem Ausgangspunkt der geplanten Route und dem Ziel der geplanten Route entspricht.
  6. Einrichtung nach einem der Ansprüche 3-5, wobei das routeInfo-Datenelement für jeden Punkt ein Standortdatenelement einschließlich des LocationInfo und ein Zeitdatenelement einschließlich des Zeitstempels umfasst.
  7. Einrichtung nach Anspruch 6, wobei das LocationInfo Breiten- und Längenkoordinaten oder eine globale Zellenkennung einer versorgenden Zelle beinhaltet, mit der das vUE verbunden ist, und der Zeitstempel eine geschätzte Zeit an einem Standort ist, der durch das LocationInfo angegeben wird.
  8. Einrichtung nach Anspruch 3, wobei die Anforderungsnachricht ferner ein Zeitgranularitätsdatenelement und ein Standortgranularitätsdatenelement umfasst, wobei das Zeitgranularitätsdatenelement einen Zeitstempelwert enthält, der eine Zeitgranularität des Aufenthalts an einem Standort angibt, und das Standortgranularitätsdatenelement eine Zeichenkette enthält, die eine Granularität eines besuchten Standorts durch in Metern gemessene Breiten- und Längenspannen angibt.
  9. Einrichtung nach einem der Ansprüche 1-5, wobei: die Prozessorschaltungsanordnung zum Erzeugen einer Antwortnachricht, die eine Funkmessung für jeden Punkt entlang der geplanten Route beinhaltet, eingerichtet ist; und die Schnittstellenschaltungsanordnung zum Senden der Antwortnachricht an das vUE eingerichtet ist.
  10. Einrichtung nach Anspruch 9, wobei die Antwortnachricht ferner ein anderes Routendatenelement umfasst, das andere Routendatenelement ein anderes routeInfo-Datenelement für jeden Punkt der mindestens zwei Punkte umfasst, und das routeInfo-Datenelement für jeden Punkt ein Standortdatenelement, das LocationInfo eines entsprechenden Punkts der mindestens zwei Punkte beinhaltet, ein Referenzsignal-Empfangsleistungs(rsrp)-Datenelement, das einen vorhergesagten rsrp-Wert für den entsprechenden Punkt beinhaltet, und ein Referenzsignal-Empfangsqualitäts(rsrq)-Datenelement, das einen vorhergesagten rsrq-Wert für den entsprechenden Punkt beinhaltet, umfasst.
  11. Einrichtung nach Anspruch 10, wobei ein erstes anderes routeInfo-Datenelement, das in dem anderen Routendatenelement enthalten ist, einem Ausgangspunkt der geplanten Route entspricht, ein letztes anderes routeInfo-Datenelement, das in dem anderen Routendatenelement enthalten ist, einem Ziel der geplanten Route entspricht, und ein oder mehrere andere routeInfo-Zwischendatenelemente, die in dem anderen Routendatenelement enthalten sind, jeweiligen Zwischenpunkten zwischen dem Ausgangspunkt der geplanten Route und dem Ziel der geplanten Route entsprechen.
  12. Einrichtung nach Anspruch 9, wobei die Anforderung und die Antwort über eine Vehicle-to-Everything-Informationsdienst(VIS)-Anwendungsprogrammierschnittstelle (API) kommuniziert werden.
  13. Einrichtung nach Anspruch 1, wobei die Prozessorschaltungsanordnung zum Bestimmen der vorhergesagten QoS für das vUE entlang der geplanten Route zu Folgendem eingerichtet ist: Identifizieren von Raum-Zeit-Korrelationen zwischen durch ein oder mehrere andere vUEs erfassten Funkinformationen und den mindestens zwei Punkten entlang der geplanten Route.
  14. Einrichtung nach Anspruch 1 oder 13, wobei die Prozessorschaltungsanordnung zum Bestimmen der vorhergesagten QoS für den Drahtloskommunikationsdienst für das vUE entlang der geplanten Route zu Folgendem eingerichtet ist: Anfordern von Informationen von einem MEC-Informationsdienst über eine entsprechende MEC-API; Empfangen der angeforderten Informationen von dem MEC-Informationsdienst; und Vorhersagen der Funksignalqualität an jedem Punkt der mindestens zwei Punkte unter Verwendung der empfangenen Informationen, wobei der MEC-Informationsdienst ein Funknetzinformationsdienst, ein MEC-Standortdienst, ein Benutzeridentitätsdienst, ein Bandbreitenverwaltungsdienst, ein Wireless-Local-Area-Network-Zugangsinformationsdienst oder ein Fixed-Access-Information-Dienst ist.
  15. Einrichtung zur Verwendung in einem Fahrzeugbenutzergerät (vUE), wobei die Einrichtung Folgendes umfasst: eine Prozessorschaltungsanordnung, eingerichtet zum Erzeugen einer Anforderungsnachricht zum Anfordern einer Dienstgüte(QoS: Quality of Service)-Vorhersage für Vehicle-to-Everything(V2X)-Dienste entlang einer geplanten Route, wobei die Anforderungsnachricht eine Vorhersage-QoS-Datenstruktur beinhaltet, wobei die Vorhersage-QoS-Datenstruktur Standortinformationen (LocationInfo) für jeden Punkt von mindestens zwei Punkten entlang der geplanten Route und einen Zeitstempel für jeden Punkt der mindestens zwei Punkte beinhaltet; und eine Kommunikationsschaltungsanordnung, die kommunikativ mit der Prozessorschaltungsanordnung gekoppelt ist, wobei die Kommunikationsschaltungsanordnung zu Folgendem eingerichtet ist: Übertragen der Anforderungsnachricht an einen Mehrfachzugriffs-Edge-Computing bzw. MEC-Host über eine V2X-Informationdienst(VIS)-Anwendungsprogrammierschnittstelle (API); und Empfangen einer Antwortnachricht von dem MEC-Host über die VIS-API, wobei die Antwortnachricht eine andere Vorhersage-QoS-Datenstruktur beinhaltet, die eine vorhergesagte QoS für die V2X-Dienste für jeden Punkt der mindestens zwei Punkte beinhaltet.
  16. Einrichtung nach Anspruch 1, wobei die Vorhersage-QoS-Datenstruktur ein Routendatenelement umfasst, wobei das Routendatenelement ein Routeninformations(routeInfo)-Datenelement für einen entsprechenden Punkt der mindestens zwei Punkte beinhaltet und das routeInfo-Datenelement für den entsprechenden Punkt ein Standortdatenelement einschließlich des LocationInfo des entsprechenden Punkts und ein Zeitdatenelement einschließlich des Zeitstempels für den entsprechenden Punkt umfasst.
  17. Einrichtung nach Anspruch 16, wobei der entsprechende Punkt eines ersten routeInfo-Datenelements, das in dem Routendatenelement enthalten ist, ein Ausgangspunkt der geplanten Route ist und der entsprechende Punkt eines letzten routeInfo-Datenelements, das in dem Routendatenelement enthalten ist, ein Zielpunkt der geplanten Route ist.
  18. Einrichtung nach Anspruch 17, wobei der Zeitstempel für den Ausgangspunkt eine Zeit ist, zu der sich das vUE an einem Standort aufgehalten hat, der durch das LocationInfo in dem ersten routeInfo-Datenelement angegeben wird, und der Zeitstempel für den Zielpunkt eine vorhergesagte Zeit ist, zu der sich das vUE an einem Standort aufhalten wird, der durch das LocationInfo in dem letzten routeInfo-Datenelement angegeben wird.
  19. Einrichtung nach Anspruch 17 oder 18, wobei das Routendatenelement ferner ein oder mehrere routeInfo-Zwischendatenelemente umfasst, wobei jedes routeInfo-Zwischendatenelement des einen oder der mehreren routeInfo-Zwischendatenelemente einem Wegpunkt zwischen dem Ausgangspunkt und dem Zielpunkt entspricht.
  20. Einrichtung nach Anspruch 19, wobei der Zeitstempel für mindestens einen Wegpunkt eine Zeit ist, zu der sich das vUE an einem Standort aufgehalten hat, der durch das LocationInfo in dem routeInfo-Zwischendatenelement angegeben wird, das dem mindestens einen Wegpunkt entspricht, und der Zeitstempel für einen anderen Wegpunkt eine vorhergesagte Zeit ist, zu der sich das vUE an einem Standort aufhalten wird, der durch das LocationInfo in dem routeInfo-Datenelement angegeben wird, das dem anderen Wegpunkt entspricht.
  21. Einrichtung nach Anspruch 16, wobei die andere Vorhersage-QoS-Datenstruktur ein anderes Routendatenelement beinhaltet, wobei das andere Routendatenelement ein anderes routeInfo-Datenelement für den entsprechenden Punkt der mindestens zwei Punkte beinhaltet, und das routeInfo-Datenelement für den entsprechenden Punkt Folgendes umfasst: ein Standortdatenelement, das das LocationInfo des entsprechenden Punkts beinhaltet, ein Zeitdatenelement, das den Zeitstempel für den entsprechenden Punkt beinhaltet, ein Referenzsignal-Empfangsleistungs(rsrp)-Datenelement, das einen vorhergesagten rsrp-Wert an einem Standort, der durch das LocationInfo des entsprechenden Punkts und während einer Zeit des Zeitstempels in dem Zeitdatenelement angegeben wird, beinhaltet, und ein Referenzsignal-Empfangsqualität(rsrq)-Datenelement, das einen vorhergesagten rsrq-Wert an dem durch das LocationInfo des entsprechenden Punkts und während der Zeit des Zeitstempels in dem Zeitdatenelement angegebenen Standort enthält.
  22. Ein oder mehrere computerlesbare Medien (CRM), die Anweisungen zum Erhalten von fahrtspezifischen Dienstgüte(QoS)-Vorhersagen für Vehicle-to-Everything(V2X)-Dienste umfassen, wobei die Ausführung der Anweisungen durch einen oder mehrere Prozessoren eines Fahrzeugbenutzergeräts (vUE) dazu betreibbar ist, zu bewirken, dass das vUE Folgendes durchführt: Übertragen einer Anforderung für die fahrtspezifischen QoS-Vorhersagen an einen Mehrfachzugriffs-Edge-Computing(MEC)-Host über eine V2X-Informationsdienst(VIS)-Anwendungsprogrammierschnittstelle (API), wobei die Anforderung eine geplante Route angibt, die einen Ausgangspunkt, einen Zielpunkt, und null oder mehr Wegpunkte zwischen dem Ausgangspunkt und dem Zielpunkt beinhaltet; und Empfangen einer Antwortnachricht von dem MEC-Host über die VIS-API, wobei die Antwortnachricht eine vorhergesagte QoS für V2X-Dienste an dem Ausgangspunkt, dem Zielpunkt und jedem der null oder mehr Wegpunkte beinhaltet.
  23. Eine oder mehrere CRM nach Anspruch 22, wobei die Ausführung der Anweisungen dazu betreibbar ist, zu bewirken, dass das vUE Folgendes durchführt: in jeder Periode einer bestimmten Funkinformationsmeldeperiodizität, Erfassen von Funkinformationen einschließlich eines oder mehrerer Funkmessberichte, und Übertragen der Funkinformationen an den MEC-Host über die VIS-API oder eine andere MEC-API; und Bestimmen, ob ein Datentransfer an jedem Punkt der mindestens zwei Punkte durchgeführt werden soll, basierend auf der vorhergesagten QoS für V2X-Dienste für jeden Punkt.
  24. Ein oder mehrere computerlesbare Medien (CRM), die Anweisungen zum Bereitstellen von fahrtspezifischen Dienstgüte(QoS)-Vorhersagen für einen Netzwerkdienst umfassen, wobei die Ausführung der Anweisungen durch einen oder mehrere Prozessoren eines Mehrfachzugriffs-Edge-Computing(MEC)-Hosts dazu betreibbar ist, zu bewirken, dass der MEC-Host Folgendes durchführt: Empfangen einer Anforderung für die fahrtspezifischen QoS-Vorhersagen für einen Netzwerkdienst von einem Fahrzeugbenutzergerät (vUE) über eine Vehicle-to-Everything-Informationsdienst(VIS)-Anwendungsprogrammierschnittstelle (API), wobei die Anforderung eine geplante Route des vUE angibt, wobei die geplante Route einen Ausgangspunkt, einen Zielpunkt und null oder mehr Wegpunkte zwischen dem Ausgangspunkt und dem Zielpunkt beinhaltet; Erhalten von Funkinformationen von einem oder mehreren vUEs und anderen Informationen von einem oder mehreren anderen MEC-Hosts unter Verwendung einer entsprechenden MEC-API; Bestimmen einer vorhergesagten QoS für einen Netzwerkdienst jeweils an dem Ausgangspunkt, dem Zielpunkt, und den null oder mehr Wegpunkten basierend auf den Funkinformationen und den anderen Informationen; und Übertragen einer Antwortnachricht an das vUE über die VIS-API, wobei die Antwortnachricht die vorhergesagte QoS für einen Netzwerkdienst für den Ausgangspunkt, den Zielpunkt und die null oder mehr Wegpunkte beinhaltet.
  25. Ein oder mehrere CRM nach Anspruch 24, wobei es sich bei den anderen Informationen um Funknetzinformationen (RNI), die von einem RNI-Dienst erhalten werden, und/oder Standortinformationen, die von einem Standortdienst erhalten werden, und/oder Benutzeridentitätsinformationen, die von einem Benutzeridentitätsdienst erhalten werden, und/oder Bandbreitenverwaltungs(BWM)-Informationen, die von einem BWM-Dienst erhalten werden, und/oder Wireless-Local-Area-Network-Zugangsinformationen (WAI), die von einem WAI-Dienst erhalten werden, und/oder Fixed Access Information (FAI), die von einem FAI-Dienst erhalten werden, handelt.
DE112020002310.9T 2019-05-07 2020-05-06 V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen Pending DE112020002310T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962844413P 2019-05-07 2019-05-07
US62/844,413 2019-05-07
US201962854871P 2019-05-30 2019-05-30
US62/854,871 2019-05-30
PCT/US2020/031715 WO2020227435A1 (en) 2019-05-07 2020-05-06 V2x services for providing journey-specific qos predictions

Publications (1)

Publication Number Publication Date
DE112020002310T5 true DE112020002310T5 (de) 2022-02-17

Family

ID=73050836

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020002310.9T Pending DE112020002310T5 (de) 2019-05-07 2020-05-06 V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen

Country Status (4)

Country Link
US (1) US20230074288A1 (de)
CN (1) CN113661721A (de)
DE (1) DE112020002310T5 (de)
WO (1) WO2020227435A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022115190A1 (de) 2022-06-17 2024-01-11 Cariad Se Verfahren und Steuerschaltung zum Auswählen von einer aus zumindest zwei verfügbaren Prozessorschaltungen für eine Prozessierung zumindest eines Datensatzes für eine Betriebsfunktion eines Kraftfahrzeugs sowie Kraftfahrzeug und Prozessierungssystem

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112752327B (zh) * 2019-10-29 2023-10-20 上海华为技术有限公司 功率调节方法和接入网设备
US11968660B2 (en) * 2019-12-16 2024-04-23 T-Mobile Usa, Inc. Optimizing licensed and unlicensed spectrum allocation
US20220141641A1 (en) * 2020-10-29 2022-05-05 Tracfone Wireless, Inc. System and Process for Configuring a Dynamic Roaming Public Land Mobile Network (PLMN)
CN112464116B (zh) * 2020-11-18 2024-03-01 金蝶云科技有限公司 页面显示方法、装置、计算机设备和存储介质
US11528642B2 (en) * 2020-12-21 2022-12-13 Verizon Patent And Licensing Inc. Method and system for SLA-based network slice control service
US20210112441A1 (en) * 2020-12-23 2021-04-15 Dario Sabella Transportation operator collaboration system
US11882623B2 (en) * 2021-02-17 2024-01-23 Charter Communications Operating, Llc Subscriber information management in a network
US11477719B1 (en) * 2021-03-05 2022-10-18 Sprint Communications Company L.P. Wireless communication service responsive to an artificial intelligence (AI) network
CN112996071B (zh) * 2021-03-11 2021-12-31 北京交通大学 一种基于用户业务感知的车辆垂直切换方法及系统
CN117322131A (zh) * 2021-04-12 2023-12-29 交互数字专利控股公司 利用部署在mno边缘计算基础结构中的mec平台的受约束设备发现和互操作
CN113240917B (zh) * 2021-05-08 2022-11-08 广州隧华智慧交通科技有限公司 一种将深度神经网络应用于智慧交通的交通管理系统
US12005924B2 (en) 2021-06-15 2024-06-11 International Business Machines Corporation Dynamic route recommendation based on mobile computation
CN113283669B (zh) * 2021-06-18 2023-09-19 南京大学 一种主动与被动相结合的智慧规划出行调研方法及系统
US12010189B2 (en) * 2021-08-17 2024-06-11 The Regents Of The University Of Michigan Roadside edge node central management
DE102021209065A1 (de) 2021-08-18 2023-02-23 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Fernsteuern eines Fahrzeugs
EP4164194A1 (de) * 2021-10-06 2023-04-12 Robert Bosch GmbH Verfahren und vorrichtungen zur funkkommunikation
US20230144248A1 (en) * 2021-11-08 2023-05-11 Verizon Patent And Licensing Inc. Dynamic quality of service traffic steering in a multi-access edge computing environment
GB202117853D0 (en) * 2021-12-10 2022-01-26 British Telecomm Service provision
FR3130487A1 (fr) * 2021-12-10 2023-06-16 Orange Procédé de prédiction d’une variation de qualité de service dans un réseau de communication V2X, dispositif de prédiction et programme d’ordinateur correspondants.
CN113923694B (zh) * 2021-12-14 2022-05-03 网络通信与安全紫金山实验室 网络资源编排方法、系统、装置及存储介质
CN114323271B (zh) * 2021-12-29 2024-04-12 广汽丰田汽车有限公司 车辆前照灯路面照度测量方法、装置、测量设备及介质
US20230254786A1 (en) * 2022-02-09 2023-08-10 Qualcomm Incorporated Method and apparatus for c-v2x synchronization
US20230262791A1 (en) * 2022-02-17 2023-08-17 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Method of Setting Up Connections Between Edge Sites in a 5G Communications Network
CN115004744B (zh) * 2022-02-17 2024-04-26 香港应用科技研究院有限公司 一种在5g通信网络的边缘站点之间建立连接的方法
CN114647805A (zh) * 2022-04-13 2022-06-21 长江大学 一种显著提升MATLAB Web App线上访问速度的方法
US11968566B2 (en) * 2022-05-09 2024-04-23 Verizon Patent And Licensing Inc. Systems and methods for inter-entity system configuration management using distributed ledger system
US20230370338A1 (en) * 2022-05-16 2023-11-16 T-Mobile Usa, Inc. Machine learning monitoring of wireless network infrastructure application servers
CN114815852B (zh) * 2022-06-14 2023-02-03 北京航空航天大学 一种基于空间离散化的cacc车队轨迹规划方法
EP4297440A1 (de) * 2022-06-22 2023-12-27 Volkswagen Aktiengesellschaft Verfahren, fahrzeug, server, computerprogramm und vorrichtung zum datenaustausch zwischen einer fahrzeugflotte und einem flotten-backend
US12013691B2 (en) * 2022-06-23 2024-06-18 GM Global Technology Operations LLC Method and system for performing vehicle computing tasks in a remote computing system or a vehicle
CN115065683B (zh) * 2022-07-27 2023-12-26 多伦互联网技术有限公司 基于车辆聚类的车辆边缘网络任务分配卸载方法
CN116208669B (zh) * 2023-04-28 2023-06-30 湖南大学 基于智慧灯杆的车载异构网络协同任务卸载方法及系统
CN117149443B (zh) * 2023-10-30 2024-01-26 江西师范大学 一种基于神经网络的边缘计算服务部署方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS62251381A (ja) * 1986-04-22 1987-11-02 有限会社　浦野製作所 コンテナ用ロツク金具
WO2011010462A1 (ja) * 2009-07-23 2011-01-27 日本電気株式会社 ネットワーク状態予測装置、移動通信システム、移動通信方法および記憶媒体
JP5696541B2 (ja) * 2011-03-16 2015-04-08 富士通株式会社 通信制御装置及び方法並びに無線通信システム
US20140089384A1 (en) * 2012-09-27 2014-03-27 International Business Machines Corporation Server resource selection on a network for a mobile client
TW201633825A (zh) * 2015-01-29 2016-09-16 Ｖｉｄ衡器股份有限公司 增強無線網路應用QoE之頻寬預測及預取
EP3858009A1 (de) * 2018-09-27 2021-08-04 Telefonaktiebolaget LM Ericsson (publ) Sidelink-ressourcenzuweisung für verbesserte mobilität

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022115190A1 (de) 2022-06-17 2024-01-11 Cariad Se Verfahren und Steuerschaltung zum Auswählen von einer aus zumindest zwei verfügbaren Prozessorschaltungen für eine Prozessierung zumindest eines Datensatzes für eine Betriebsfunktion eines Kraftfahrzeugs sowie Kraftfahrzeug und Prozessierungssystem

Also Published As

Publication number Publication date
US20230074288A1 (en) 2023-03-09
CN113661721A (zh) 2021-11-16
WO2020227435A1 (en) 2020-11-12

Similar Documents

Publication Publication Date Title
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
US11234204B2 (en) Server selection for vehicle communications and applications
EP3968675A1 (de) Lokales ausbrechen für kantenberechnung
DE102022200847A1 (de) Bestärkendes lernen für mehrfachzugriffsverkehrsverwaltung
US11627444B2 (en) Vehicle-to-everything session and service continuity in automotive edge computing systems
US11751042B2 (en) Multi-access edge computing service for mobile user equipment method and apparatus
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE112020003766T5 (de) Linkleistungsprognose und Medienstreaming-Technologien
US20220038359A1 (en) Link performance prediction technologies
DE102021208087A1 (de) Kontextbewusstes Handover
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
DE112020007003T5 (de) Multi-funkzugangstechnologie-verkehrsverwaltung
DE102019217367A1 (de) VERWALTUNG DER DIENSTQUALITÄT (QoS) IN EDGE-COMPUTING-UMGEBUNGEN
DE102022202872A1 (de) Neuronales graphennetzwerk und bestärkendes-lernen-techniken zur verbindungsverwaltung
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
DE112019002913T5 (de) Verwaltung von zuweisungen bevorzugter kanäle zwischendrahtloskommunikationsbändern
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
DE112018005693T5 (de) Multi-access edge computing (mec)-basierte mehrbetreiberunterstützung für cellular vehicle-to-everything (c-v2x) systeme
KR20220027818A (ko) 분산 컴퓨팅을 위한 자동화된 리소스 관리
US20220167262A1 (en) Server selection for vehicle communications and applications
DE102022200588A1 (de) Überlastungs- und mehrkanalsteuerung eines verkehrstelematiksystems
DE102019123244A1 (de) Verbesserungen der verfolgung von multi-access-edgecomputing (mec)-gebührenerfassung und -abrechnung
DE102022211605A1 (de) Zuverlässigkeitsverbesserungen für mehrfachzugangsverkehrsverwaltung
DE112020003201T5 (de) Ressourcenzuweisungsmanagement für Gleichkanalkoexistenz in intelligenten Transportsystemen