DE102021211176A1 - Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen - Google Patents

Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen Download PDF

Info

Publication number
DE102021211176A1
DE102021211176A1 DE102021211176.9A DE102021211176A DE102021211176A1 DE 102021211176 A1 DE102021211176 A1 DE 102021211176A1 DE 102021211176 A DE102021211176 A DE 102021211176A DE 102021211176 A1 DE102021211176 A1 DE 102021211176A1
Authority
DE
Germany
Prior art keywords
edge
mec
service
network
api
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
DE102021211176.9A
Other languages
English (en)
Inventor
Danny Moses
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 DE102021211176A1 publication Critical patent/DE102021211176A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H04L12/1407—Policy-and-charging control [PCC] architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/50—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for cross-charging network operators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66—Policy and charging system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die vorliegende Offenbarung betrifft Edge-Computing-Frameworks und Systeme und insbesondere Interworking zwischen unterschiedlichen Edge-Computing-Technologien (ECTs). Die vorliegende Offenbarung stellt ein flexibles Framework bereit, das ein Gateway (GW) eines API-Diensts (edgeXapis) beinhaltet, das interoperable und sichere Kommunikation zwischen den mehreren unterschiedlichen ECTs über Attestierung ermöglicht und die Verbindung zwischen den mehreren unterschiedlichen ECTs unterstützt. Das edgeXapis-GW stellt auch Aufdeckung gegenüber Edge-Apps der vollen Liste von Anwendungsprogrammierungsschnittstellen (APIs) von jedem der mehreren unterschiedlichen ECTs bereit. Das edgeXapis-GW stellt auch einen interoperablen Edge-Dienstverbrauch von den mehreren unterschiedlichen ECTs bereit, einschließlich APIs, die von jeder der mehreren unterschiedlichen ECTs aufgedeckt werden, um verschiedene alternative Transportprotokolle für jede andere ECT für den Edge-Dienstverbrauch verfügbar zu machen. Andere Ausführungsformen können beschrieben und/oder beansprucht werden.

Description

  • VERWANDTE ANMELDUNGEN
  • Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung. Nr. 63/130 317 , eingereicht am 23. Dezember 2020 („[AD4420-Z]“), deren Inhalt hiermit vollumfänglich durch Bezugnahme aufgenommen wird.
  • TECHNISCHES GEBIET
  • Hierin beschriebene Ausführungsformen betreffen allgemein Edge-Computing-, Netzwerkkommunikations- und Kommunikationssystem-Umsetzungen und insbesondere Technologien zum Harmonisieren von Edge-Computing-Standards und -Frameworks.
  • HINTERGRUND
  • Die Informations- und Kommunikationstechnologie-Industrie (ICT-Industrie) diskutiert seit vielen Jahren das Edge-Computing. Mit wachsender Marktnachfrage, die von Anwendungen stammt, die niedrige Latenz erfordern, und mit neueren Entwicklungen bei Standards und Produkten, ist die Möglichkeit, Edge-Computing im vollen Ausmaß einzusetzen, jetzt da und bringt erhebliches Marktwachstum. Mobile Netzwerkinfrastrukturen bieten einen beschleunigten Einsatzweg für Edge-Cloud-Infrastrukturen. Zu diesem Trend tragen zwei Faktoren bei.
  • Auf der Nachfrageseite gibt es, wo sich das industrielle Internet der Dinge (Internet of Things - IIoT) jetzt etabliert, mehrere kommerziell realisierbare Verwendungsfälle, die eine Datenverarbeitung an der Edge benötigen, um strenge Latenzanforderungen zu adressieren und ein Überlasten von Netzwerken zu vermeiden. Andere Anwendungen, die Edge-Computing-Fähigkeiten fordern, beinhalten Augmented Reality (AR) und/oder Virtual Reality (VR), Gaming und Vehicle-To-Everything-Kommunikation (V2X-Kommunikation) (wie etwa Fahrzeug-zu-Fahrzeug, Fahrzeug-zu-Infrastruktur,Fahrzeug-zu-Netzwerk oder Fahrzeug-zu-Fußgänger) und alle kommen auf dem Markt derzeit in Schwung.
  • Auf der Versorgungsseite stellt sich das Aufbauen einer verteilten Cloud-Computing-Infrastruktur dank geografisch dichter Präsenzpunkte (Points of Presence - PoP) von Mobilfunkbetreibern (MNOs) als eine realisierbare Geschäftsgelegenheit heraus. Cloud-Anbieter suchen auch nach Möglichkeiten und Partnerschaften, Edge-Cloud-Infrastrukturen aufzubauen. MNO-Präsenzpunkte sind bei der Auseinandersetzung mit den Näherungserfordernissen anspruchsvollster Anwendungsfälle mit Einsatzmöglichkeiten im Bereich von tiefer und entfernter Edge (jeweils bis zu 5 km bzw. 10 km vom Endbenutzer) bis zu aggregierter Edge (bis zu 30 km) einzigartig. Mit der 5G, die umfangreich in mehreren Geografien eingesetzt wird, erfordern neue Merkmale, wie etwa Ultraverlässliche Niederlatenzkommunikation (Ultra-Reliable Low Latency Communications - URLLC) und massive Maschinenkommunikation (Machine Type Communication - mMTC), komplementäre Edge-Computing-Fähigkeiten, um das volle Marktpotenzial der 5G zu realisieren. Heute ist das Einsetzen von Cloud-Computing an der Edge ein Markt und geschäftlich unerlässlich.
  • Figurenliste
  • In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Ziffern ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in welchen:
    • 1 eine Synergized-Mobile-Edge-Cloud-Architektur, die unterschiedliche Betriebsmodi unterstützt, gemäß unterschiedlichen Ausführungsformen veranschaulicht. 2 eine Referenzplattform- und Edge-Service-Anwendungsprogrammierschnittstellen-Aufdeckung (API-Aufdeckung) veranschaulicht. 3 eine beispielhafte Architektur für eine Netzwerkaufdeckungsfunktion in einer Referenzpunktdarstellung veranschaulicht. 4 eine beispielhafte CAPIF-Funktionsarchitektur, die unterschiedliche Systeme verbindet, veranschaulicht. 5 Optionen für Einsatz von MEC und Common API Framework (CAPIF) veranschaulicht. 6 Szenarien zum Cross-Verbrauch von Edge-Dienst-APIs in hybriden MEC-Umsetzungen von Edge-Plattformen veranschaulicht. Die 7a, 7b und 7c Architekturen zum Umsetzen der verschiedenen hierin besprochenen Ausführungsformen veranschaulicht. 8 Attestierungsaspekte veranschaulicht. 9 ein Attestierungsobjekt-Layout, das die enthaltenen Authenticator-Daten (die attestierte Berechtigungsnachweisdaten enthalten) und Attestierungsaussagen beinhaltet, veranschaulicht. 10 ein Beispiel für eine Authentifizierung eines Angriffs durch Fehlen eines Attestierungsmechanismus veranschaulicht. 11 ein Beispiel für einen Authentifizierungsangriff, der mit einem Attestierungsmechanismus geschützt ist, veranschaulicht.
    • 12 eine beispielhafte Edge-Computing-Umgebung veranschaulicht. 13 einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing veranschaulicht. 14 Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen veranschaulicht. 15 einen beispielhaften Ansatz für Networking und Dienste in einem Edge-Computing-System veranschaulicht. 16 den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird, veranschaulicht. 17 verschiedene Recheneinrichtungen, die Container in einem Edge-Computing-System einsetzen, veranschaulicht. 18 einen Rechen- und Kommunikationsnutzungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System involviert, veranschaulicht.
    • 19 eine Übersicht über 3GPP-Edge-Computing abbildet. 20 ein beispielhaftes Peer-to-Peer (P2P) -Edge-Computing-Verwaltungseinsatzszenario gemäß verschiedenen Ausführungsformen zeigt. 21 eine Anwendungsarchitektur zum Ermöglichen von Edge-Anwendungen gemäß verschiedenen Ausführungsformen zeigt. Die 22a und 22b Aspekte eines Edge-9-Referenzpunktes zeigen. 23 die Rollen und Beziehung von Dienstanbietern, die an dem Einsatz von Edge-Computing-Diensten beteiligt sind, zeigt. 24 eine beispielhafte MEC-Systemreferenzarchitektur veranschaulicht. 25 eine MEC-Referenzarchitekturvariante zum Einsatz in einer Netzwerkfunktions-Virtualisierungsumgebung (Network Function Virtualization - NFV) veranschaulicht. 26 eine MEC-Referenzarchitekturvariante für MEC-Verband veranschaulicht. 27 eine 5G-dienstbasierte Architektur und eine MEC-Architektur, die in einem beispielhaften Edge-Computing-System einsetzbar sind, sowie einen integrierten MEC-Einsatz in einem 5G-Netzwerk, das mit einem beispielhaften Edge-Computing-System verwendbar ist, veranschaulicht. 28 eine beispielhafte MEC-Dienstarchitektur veranschaulicht. 29 eine beispielhafte Netzwerkarchitektur veranschaulicht. 30 eine beispielhafte Softwareverteilungsplattform veranschaulicht. Die 31 und 32 beispielhafte Komponenten verschiedener Rechenknoten in einem oder mehreren Edge-Computing-Systemen abbilden. 33 verschiedene Prozesse zum Betreiben der verschiedenen hierin besprochenen Ausführungsformen abbildet.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgenden Ausführungsformen betreffen allgemein Datenverarbeitungs-, Dienstverwaltungs-, Ressourcenzuordnungs-, Rechenverwaltungs-, Netzwerkkommunikations-, Anwendungspartitionierungs- und Kommunikationssystemumsetzungen und insbesondere Techniken und Konfigurationen zum Anpassen verschiedener Edge-Computing-Vorrichtungen und Entitäten, um mehrere Entitäten (zum Beispiel mehrere Mandanten, Benutzer, Stakeholder, Dienstinstanzen, Anwendungen usw.) in einer verteilten Edge-Computing-Umgebung dynamisch zu unterstützen.
  • Internet-of-Things-Vorrichtungen (IoT-Vorrichtungen) sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können, und Sensoren, Aktuatoren und andere Eingabe-/Ausgabekomponenten beinhalten können, wie etwa zum Sammeln von Daten oder Ausfü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, Fahrzeuge, Paketen usw., um ein zusätzliches Niveau an künstlicher Sinneswahrnehmung dieser Dinge bereitzustellen. Kürzlich sind IoT-Vorrichtungen immer beliebter geworden, und daher haben sich Anwendungen, die diese Vorrichtungen verwenden, vermehrt. Der Einsatz von IoT-Vorrichtungen und MEC-Diensten (Multi-Access Edge-Computing - MEC) hat eine Reihe fortgeschrittener Verwendungsfälle und Szenarien eingeführt, die am Rand des Netzwerks auftreten oder diesen anderswie involvieren.
  • Industrielles IoT (IIoT) betrifft miteinander verbundene Sensoren, Instrumente und andere Vorrichtungen, die gemeinsam mit industriellen Anwendungen von Computern vernetzt sind, einschließlich Herstellung und Energiemanagement. Diese Konnektivität erlaubt Datensammlung, Austausch und Analyse, was potenziell Verbesserungen der Produktivität und Effizienz sowie anderer wirtschaftlicher Vorteile ermöglicht. Das IIoT ist eine Evolution eines verteilten Steuersystems (Distributed Control System - DCS), das einen höheren Automatisierungsgrad erlaubt, indem Cloud-Computing verwendet wird, um die Prozesssteuerungen zu verfeinern und zu optimieren. Die IIoT-Industrie 4.0 weist einen weiten Geltungsbereich und eine große Anzahl von Nutzungsfällen auf. Aufgrund der geringen Latenzanforderungen, die von diesen Verwendungsfällen eingeführt werden, und aufgrund ihres Bedarfs an vertrauenswürdiger Berechnung, ist das Verwenden zentraler Clouds häufig keine Option mehr, so dass Edge-Cloud als die einzige realisierbare Option verbleibt. Mit der 5G, die in öffentlichen und privaten Netzwerken eingesetzt wird, ist das Kombinieren von 5G (und 4G) mit Edge-Cloud eine natürliche Architekturoption, um industrielles IoT zu unterstützen.
  • Edge-Computing betrifft auf einer allgemeinen Ebene die Umsetzung, Koordination und Verwendung von Rechnen und Ressourcen an Orten näher an der „Edge“ oder Sammlung von „Edges“ des Netzwerks. Zweck dieser Anordnung ist es, die Gesamtkosten der Eigentümerschaft zu verbessern, Anwendungs- und Netzwerklatenz zu reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen (insbesondere im Vergleich zu herkömmlichem Cloud-Computing) zu verbessern. Komponenten, die Edge-Computing-Operationen ausführen können („Edge-Knoten“), können sich an jedem Ort, den die Systemarchitektur oder der Ad-hoc-Dienst benötigen, befinden (zum Beispiel in einem Hochleistungsrechenzentrum oder einer Hochleistungs-Cloud-Installation; einem bezeichneten Edge-Knoten-Server, einem Unternehmensserver, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-an-der Edge-Vorrichtung, die bedient wird und Edge-Dienste verbraucht).
  • Anwendungen, die für Edge-Computing angepasst wurden, beinhalten unter anderem Virtualisierung traditioneller Netzwerkfunktionen (um zum Beispiel Telekommunikations- oder Internetdienste zu betreiben) und die Einführung von Merkmalen und Diensten der nächsten Generation (um zum Beispiel 5G-Netzwerkdienste zu unterstützen). Verwendungsfälle, deren Planung weitgehendes Nutzen von Edge-Computing vorsieht, beinhalten unter vielen anderen Netzwerken und rechenintensiven Diensten vernetzte selbstfahrende Autos, Überwachung, Internet-der-Dinge-Vorrichtungsdatenanalytik (IoT-Vorrichtungsdatenanalytik), Videocodierung und -analytik, ortsbezogene Dienste, Vorrichtungsabtastung in Smart Cities.
  • Edge-Computing kann bei einigen Szenarien einen Cloud-ähnlichen verteilten Dienst anbieten oder hosten, um Orchestrierung und Verwaltung für Anwendungen und koordinierte Dienstinstanzen unter vielen Arten von Speicherungs- und Rechenressourcen anzubieten. Es wird auch erwartet, dass Edge-Computing eng mit existierenden Verwendungsfällen und Technologie integriert ist, die für IoT- und Fog-/verteilte Networking-Konfigurationen entwickelt wurden, da Endpunktvorrichtungen, Clients und Gateways versuchen, auf Netzwerkressourcen und Anwendungen an Orten zuzugreifen, die näher am Rand des Netzwerks liegen.
  • Häufig sind Normen erforderlich, wenn Lösungen mit mehreren Stakeholdern aufgebaut werden müssen. Sie sind auch vorteilhaft, um Größenvorteile zu realisieren, Einrasten zu vermeiden und zu ermöglichen, dass Mehrverkäufer-Lösungen gebaut werden, die die beste Sorte von Komponenten von jedem Anbieter nutzen. Beispiele dafür, wo Standards spezifisch benötigt werden, wenn Edge-Computing in Verbindung mit MNO-Infrastrukturen eingesetzt wird, beinhalten:
    • • Gemeinsame Infrastrukturfähigkeiten, um Entwicklern/Kunden dabei zu helfen, über die Edge-Infrastruktur der MNOs auf ihre Software zuzugreifen und diese einzusetzen (zum Beispiel Anwendungen, Plattformen usw.).
    • • Intelligente Anwendungsplatzierung, um den optimierten Einsatz von Anwendungen an der Edge-Infrastruktur basierend auf Kriterien, wie etwa verfügbaren Ressourcen, geografischen Gebieten, Kosten- und Latenzanforderungen, zu erlauben.
    • • Entdeckung von und optimales (Neu-)Routing zu einer Edge-Cloud, die in der Lage ist, Anwendungs-Clients (die auf Vorrichtungen laufen) zu bedienen. Wenn ein Anwendungs-Client eine Serveranwendung erreichen möchte, besteht die Notwendigkeit, die optimale Edge-Cloud zu entdecken, die Instanzen der Serveranwendung ausführt, die notwendigen Ressourcen (CPU, GPU usw.) aufweist und die niedrigste Netzwerklatenz bereitstellt.
    • • Dienstkontinuität: wenn Mobilität auftritt, wird es vorteilhaft sein, den Kontext nahtlos von einer zustandsabhängigen Anwendungsinstanz in einer Edge-Cloud zu einer Instanz derselben Anwendung in einer Ziel-Edge-Cloud zu transferieren, zum Beispiel zu einer, die eine niedrigere Latenz bereitstellt.
    • • Cloud-Anwendungen würden die Benutzererfahrung verbessern, wenn sie Dienste, die von dem Netzwerk angeboten werden, nutzen könnten: Zugreifen auf Informationen und Dienste, die von den Edge-Diensten bereitgestellt werden, wie etwa der Vorrichtungsort oder QoS-Schlüssel, um die Benutzererfahrung zu verbessern.
    • • Edge-Verband über mehrere MNOs: erlaubt, dass MNOs den Entwicklern/Kunden die Möglichkeit bieten, ihre Software über mehrere Domänen hinweg einzusetzen und Dienstkontinuität beim Roaming in alternativen Netzwerken sicherzustellen.
  • Um diesen Fähigkeiten Interaktionen zwischen der Edge-Cloud-Middleware zu bieten (Ermöglichen von auf der Edge laufenden Anwendungen), werden die Anwendungen (ob ob sie nun auf Geräten oder auf der Edge-Cloud laufen) und die Netzwerke benötigt. Im Zusammenhang mit diesen Interaktionen hebt dieses Dokument die relevanten Standardinitiativen, deren Wertvorschläge und deren komplementäre Beschaffenheit in den Vordergrund.
  • Open Source spielt auch beim Formen und Beschleunigen des Einsatzes von Edge-Clouds eine wichtige Rolle. Eine Vielfalt offener Open Source-Projekten, die die Cloud betreffen, gelten im Allgemeinen gleichermaßen für Edge-Clouds. Dazu zählen diejenigen, die hohen Durchsatz, niedrige Latenz, hohe Verfügbarkeit, horizontale Skalierbarkeit usw. bieten. Zusätzlich dazu treten andere Open Source-Initiativen hervor, um laufende Standards für Edge-Cloud-Einsätze in Verbindung mit Mobilfunknetzwerken spezifisch zu unterstützen. Ihre Wertvorschläge betreffen die Unterstützung von Entwicklern und die Beschleunigung der Zeit bis zum Einsatz. Vertikale spezifische Open Source-Komponenten können auch Edge-Cloud-Einsätze verbessern, indem spezifische Mikrodienste angeboten werden, die von Anwendungsentwicklern über Anwendungsprogrammierungsschnittstellen (Application Programming Interfaces - APIs) verwendet werden können.
  • Die verschiedenen hierin besprochenen Ausführungsformen sind auf eine beliebige Art von drahtlosem Gerät anwendbar, einschließlich Prozessoren/CPUs mit Konnektivitätsmerkmalen, Mobilvorrichtungen, (zum Beispiel Smartphones, Feature-Phones, Tablets, Wearables, zum Beispiel Smartwatches oder dergleichen), IoT-Produkt und/oder IoT-Vorrichtungen, Laptops, Drahtlosausrüstung in Fahrzeugen, Industrieautomatisierungsausrüstung usw.), Netzwerk- oder Infrastrukturausrüstung (zum Beispiel Macro-/Micro-/Femto-/Pico-Basisstationen, Repeater, Relaisstationen, WiFi-Zugangspunkte, RSUs, RAN-Knoten, Backbone-Ausrüstung, Routing-Ausrüstung, eine beliebige Art von Informations- und Kommunikationstechnologie-Geräten (Information and Communications Technology ICT), eine beliebige Art von Informationstechnologie-Geräten (IT-Geräten) usw.) und Systemen/Anwendungen, die nicht klassisch Teil eines Kommunikationsnetzwerks sind (zum Beispiel medizinische Systeme/Anwendungen (zum Beispiel Fernchirurgie, Robotik usw.), taktile Internetsysteme/-anwendungen, Satellitensysteme/-anwendungen, Luftfahrtsysteme/- anwendungen, Fahrzeugkommunikationssysteme/-anwendungen, autonome Fahrsysteme/- anwendungen, industrielle Automatisierungssysteme/-anwendungen, Robotersysteme/- anwendungen usw.). Die Ausführungsformen führen Hierarchieebenen für verschiedene Arten von Geräten ein, zum Beispiel kann das Netzwerkgerät im Vergleich zu UEs eine höhere Hierarchieebene aufweisen oder umgekehrt. In Abhängigkeit von der Hierarchieebene können einige Geräte bevorzugt behandelt werden (weniger Verzögerung) oder Zugriff auf mehr Informationen/Daten als andere Geräte haben.
  • 1. AUSFÜHRUNGSBEISPIELE
  • 1 veranschaulicht eine Synergized-Mobile-Edge-Cloud-Architektur 100, die unterschiedliche Betriebsmodi unterstützt und ein 3GPP (Third Generation Partnership Project) und ETSI (European Telecommunications Standards Institute) Industry Specification Group (ISG) Multi-Access Computing (MEC) nutzt. 1 zeigt auch eine Beziehung zwischen 3GPP-EDGEAPP und ETSI-MEC-Architekturen.
  • In 1 betreiben Vorrichtungen (zum Beispiel UE 2101) Anwendungs-Clients (Application Clients - ACs) 2111, die entweder ein Domain Name System (DNS) verwenden, um Anwendungsserver, wie etwa den Edge-Application-Server (Edge-Anwendungs-Server - EAS) 2150 in 3GPP-Dienst- und Systemaspekten (Service and System Aspects - SA) Working Group 6 (SA6), oder eine MEC-Anwendung (MEC-Anwendung - MEC-App) 2426 in ETSI-MEC zu entdecken, und/oder verwenden den Edge-Enabler-Client (EEC) 2115, um die Entdeckung gemäß der 3GPPSA6 EDGEAPP-Architektur auszuführen (siehe zum Beispiel 19 bis 23). 3GPPSA6 definiert eine 3GPP-Architektur zum Aktivieren von EDGEAPP (Edge-Applications EDGEAPP), insbesondere durch die Spezifikation einer Aktivierungsschicht zum Ermöglichen von Kommunikation zwischen Anwendungs-Clients und Anwendungen, die an der Edge eingesetzt werden. Während indirekte Unterstützung für Edge-unbewussten Anwendungs-Clients geboten wird, bietet EDGEAPP zusätzliche Vorteile für Edge-bewusste Anwendungen durch direkte Interaktion mit dem Gerät-gehosteten Edge-Enabler-Client. Die EDGEAPP-Architektur ermöglicht es auch, das Common API Framework (CAPIF) als standardisiertes Mittel zum Bereitstellen und Zugreifen auf APIs in der Edge-Cloud zu nutzen. Das UE 2101 kann dasselbe wie die UEs 1221, 1211 der 12, das UE/die Vorrichtung 2420 der 24, das UE 2902 der 29 und/oder andere UEs, Mobilvorrichtungen und/oder Clients, die hierin besprochen sind, sein.
  • Bei einigen Umsetzungen sind der EAS 2150 und die MEC-App 2426 Anwendungsserver und können ähnliche anwendungsspezifische Funktionalitäten bereitstellen. Das EAS 2150 nutzt Dienste des EES 2155, wohingegen die MEC-App 2426 die Dienste nutzt, die von der MEC-Plattform 2432 bereitgestellt werden, wie in [MEC003] spezifiziert. Das EAS 2150 und die MEC-App 2426 können sich bei einigen Umsetzungen an demselben Ort befinden.
  • Eine Edge-Plattform (zum Beispiel ein Edge-Enabler-Server - EES) 2155 in 3GPPSA6 und/oder MEC-Plattform 2432 in ETSI-MEC) stellt Funktionalität bereit, die das Vermitteln von Zugang zu Netzwerkdiensten, Anwendungsautorisierung, Anwendungsdienstregistrierung, Anwendungsdienstentdeckung, Kontextübertragung und/oder andere ähnliche Funktionalität und/oder Dienste betrifft. Sowohl der EES 2155 als auch die MEC-Plattform 2432 stellen Anwendungsunterstützungsfähigkeiten gegenüber den Anwendungsservern (zum Beispiel EAS 2150 bzw. MEC-App 2426) bereit. Wie der EES 2155 und die MEC-Plattform 2432 umgesetzt oder ausgerichtet sind, kann umsetzungsspezifisch sein. Der EES 2155 und die MEC-Plattform 2432 können sich bei einer Umsetzung an demselben Ort befinden. Zum Beispiel könnten die APIs, die von dem EES 2155 zur Unterstützung der EASs 2150 bereitgestellt werden, von einer Umsetzung angeboten und/oder aufgedeckt werden, die sowohl Fähigkeiten des EES 2155 als auch der MEC-Plattform 2432 zur Unterstützung der EASs 2150 und der MEC-Apps 2426 bietet. Ebenso können sich ein EAS 2150 und eine MEC-App 2426 bei einer Umsetzung an demselben Ort befinden (wie auch in dem Informationsanhang C von [TS23558] angegeben), um die Dienste zu nutzen, die sowohl von dem EES als auch von der MEC-Plattform angeboten werden. Zusammenfassend können Umsetzungen, insbesondere jene, bei welchen sich ein EES 2155 und MEP 2432 an demselben Ort befinden, mit der 3GPP-EDGEAPP-Spezifikation [TS23558], den ETSI-MEC-Spezifikationen oder beiden Spezifikationssätzen konform sein. Umsetzungen, die mit beiden Sätzen von Spezifikationen konform sind, ermöglichen das Anbieten von Fähigkeiten beider Edge-Computing-Technologien (ECTs) und können eine potenzielle Duplizierung des separaten Einsatzes der EESs 2155 und MEPs 2432 vermeiden.
  • Eine gegebene Umsetzung kann Funktionen/Dienste, die von ETSI-MEC spezifiziert werden, und Funktionen/Dienste, die von 3GPPSA6 Edge-Computing spezifiziert werden, kombinieren. Die Edge-Plattform Deckt APIs mit Edge-Cloud-Anwendungen (zum Beispiel MEC-App 2426 oder EAS 2150) auf. Die Edge-3- und Mp1-Referenzpunkte bieten komplementäre und/oder ähnliche API-Funktionen, so dass die Edge-3- und Mp1-Referenzpunkte aus Anwendungsentwicklersicht als Teil eines einzigen Referenzpunktes 205 angesehen werden können.
  • Funktionalitäten, die von ETSI-MEC spezifiziert werden, beinhalten Verwaltung und Orchestrierung der Funktionen der MEC-Plattformen 2406 und OSS 2412, die Zugriff auf Portale unterstützen, die Anwendungsdienstanbietern angeboten werden (siehe zum Beispiel [MEC003]). In der ETSI-MEC können die MEC-Apps 2426 und die MEC-Plattform 2432 Dienste aufdecken, die Netzwerkdienste beinhalten können, die von ihrer Verfügbarkeit auf Kern- oder Zugangsnetzwerkebene abhängen. Die Orchestrierungs- und Verwaltungsaspekte der Architektur zum Ermöglichen von Edge-Anwendungen sind in 3GPPSA5-Spezifikationen spezifiziert. Die MEC-Plattform 2432 bietet MEC-Apps 2426 (ähnlich den EASs 2150, wobei beide als Anwendungsserver in der 3GPP-Nomenklatur betrachtet werden können) über den Mp1-Referenzpunkt Unterstützung an; sie ist auch an der MEC-App-Verwaltung durch Konnektivität mit dem MEC-Plattformmanager 2406 über den Mm5-Referenzpunkt beteiligt. Während die MEC-Plattform 2432 nicht direkt mit den UEs interagiert, kann eine Vorrichtungsanwendung (gehostet in einer Vorrichtung, für die ein UE 2101 als ein Beispiel bereitgestellt ist) eine Anforderung (über einen Mx2-Referenzpunkt zu dem UALCMP 2414) ausgeben, eine Anwendung in dem MEC-System 2400 zu instanziieren oder eine instanziiert Anwendung in das MEC-System 2400 hinein oder aus diesem heraus zu bewegen. Einzelheiten über MEC-Entitäten (zum Beispiel MEC-Plattform 2432, MEC-App 2426, MEC-Plattformmanager 2406, MEC-Orchestrator 2410, OSS 2412 und CFS-Portal (Customer Facing Service) 2416) sind unten im Zusammenhang mit den 24 - 28 besprochen und befinden sich in [MEC003].
  • Die Edge-3 und Mp1 stellen Dienstregistrierungs- und Dienstentdeckungsmerkmale bereit, die es einer Edge-Cloud-Anwendung erlauben, Dienste, die von dieser Anwendung offengelegt werden, und deren anschließende Entdeckung und Verwendung durch andere Anwendungen zu registrieren. Die aufgedeckten Dienste können Netzwerkdienste, abhängig von ihrer Verfügbarkeit auf Kern- oder Zugangsnetzwerkebene, betreffen. Die gemeinsamen Fähigkeiten können durch Annahme des Common API Framework (CAPIF), wie in [TS23222] spezifiziert, harmonisiert werden.
  • Edge-9 und Mp3 befinden sich beide im frühen Entwicklungsstadium. Beide sollen bei der Kontextmigration helfen. Die folgenden Schnittstellen befassen sich mit einfacher Billigung von SA2-Schnittstellen (zum Beispiel Network Exposure Function/Service Capability Exposure Function, NEF/SCEF): Edge-2, Edge-7, Edge-8, M3GPP-1.
  • Gemäß 3GPPSA6-Standards werden Edge-Dienste den Anwendungs-Clients von dem Edge-Konfigurationsserver (ECS) 2160 und der EES 2155 über den EEC 2115 in dem UE 2101 aufgedeckt. Jeder EEC 2115 ist mit der Adresse des ECS 2160 konfiguriert, die entweder von dem MNO oder von dem Edge-Computing Service Provider (ECSP) bereitgestellt wird (siehe zum Beispiel ECSP 2310 der 23). Einsatzoptionen können alle oder einen Teilsatz der Merkmale der synergistischen Architektur umsetzen, wie in nachfolgenden Abschnitten gezeigt.
  • Die vorliegende Offenbarung berücksichtigt das Edge-Rechenreferenzszenario, wie in ETSI White Paper #36, „Harmonization Standards for Edge Computing - A synergized architecture leveraging ETSI ISG MEC and 3GPP-Spezifikationen“ (Juli 2020) („[ETSIWP36]“), veröffentlicht von sowohl ETSI MEC als auch 3GPPSA6-Vertretern und -Mitgliedern, beschrieben. Die Studie hat eine Synergien nutzende Architektur eingeführt, die ETSI-MEC-Standards (siehe zum Beispiel [MEC003]) und 3GPP-Spezifikationen (siehe zum Beispiel 3GPP-TS 23.558 v1.2.0 (2020-12-07) („[TS23558]“)) nutzt, indem der Wertvorschlag unterschiedlicher Standardströme hervorgehoben wird und wie, was Anwendung betrifft, diese Standards kombiniert werden können.
  • Hinsichtlich des Abgleichs zwischen ETSI-MEC- und 3GPPSA6 EDGEAPP-Standards bestand ausgehend von der anfänglichen Analyse, die in der neueren ETSI-Studie ausgeführt wurde, der Schwerpunkt im Vergleichen der Definition der MEC-Plattform 2432 in ETSI und der EES 2155 in SA6, um möglicherweise Ähnlichkeiten und Lücken zu identifizieren. Ein Ziel ist es nämlich sicherzustellen, dass beide SDOs die Umsetzung einer einzigen Plattform als Produkt gemäß beiden Standards erlauben. Für eine Produktumsetzung sollen drei Haupt-„Einsatzvarianten“ möglich sein. In Abhängigkeit von den verschiedenen Einsatzmöglichkeiten und Kundenerfordernissen sollte ein einziges Produkt in der Lage sein, 3GPP, ETSI-MEC oder beides zu erfüllen.
  • Als eine auf die Edge-Plattform fokussierte Voranalyse definieren die beiden Standardgruppen (ETSI MEC und 3GPP SA6) auf hoher Ebene dieselben grundlegenden Plattformmerkmale. Hauptsächlich sind die zwei Sätze von APIs, die mit Edge-Diensten verwandt sind, die den Apps aufgedeckt werden, komplementär. Dies kann insbesondere für Produkte, die beiden Normen entsprechen, ein großer Mehrwert sein.
  • Basierend auf diesem Zusammenhang stellt die vorliegende Offenbarung ein flexibles Framework für den Verbrauch von Edge-APIs in Gegenwart hybrider MEC-Umsetzungen von Edge-Plattformen (die zum Beispiel mit beiden Standards übereinstimmen), wie etwa die Architektur der 1 und das Referenzplattform- und Edge-Dienst-API-Aufdeckungs-Framework200, die in 2 gezeigt sind, bereit. Die Ausführungsformen hierin ermöglichen es Edge-Anwendungen, Edge-APIs aus beiden Standards (zum Beispiel ETSI-MEC- und 3GPP-EDGEAPP-Standards) zu verbrauchen.
  • Die vorliegende Offenbarung befasst sich mit Edge-Plattformen, die sowohl mit ETSI-MEC- als auch mit 3GPPSA6-Standards konform sind, wobei die Edge-Plattform Funktionalitäten und APIs umsetzt, die mit den beiden Standards konform sind. Die Ausführungsformen hierin ermöglichen Edge-Anwendungen im Dual-Mode-Edge-APIs Verbrauch beider Standards. Die Ausführungsformen hierin stellen einen interoperablen Mechanismus bereit, der es derselben Anwendung (zum Beispiel an Bord entweder als MEC-Anwendungen 2426 oder EAS 2150) ermöglichen kann, Edge-Dienst-APIs in einem derartigen hybriden Szenario zu verbrauchen, um von dem gesamten Portfolio von Funktionalitäten, die an der Edge angeboten werden, zu profitieren.
  • Das hier erörterte flexible Framework stellt die folgenden Technologiekomponenten bereit: eine Definition eines Edge-API-Diensts-Gateway (edgeXapis-Gateway) (GW) als eine Funktion, die eine interoperable und sichere Kommunikation über Attestierung ermöglicht und die Verbindung zwischen MEC und 3GPP-CAPIF unterstützt; Aufdeckung gegenüber Edge-Apps der vollen Liste von APIs von sowohl MEC- als auch 3GPP-Systemen, mittels ordnungsgemäßer Signalisierung (unterstützt von der edgeXapis-GW-Funktion) der CAPIF-Kernfunktion (zum Beispiel CCF 405 der 4) und der MEC-Plattform 2432; interoperabler Edge-Dienstverbrauch von MEC und 3GPP, einschließlich APIs, die von beiden Systemen aufgedeckt werden; und Mechanismen, um EASs 2150 auch alternative Transportprotokolle für den MEC-APIs Dienstverbrauch verfügbar zu machen. Die vorliegende Offenbarung beinhaltet Umsetzungen der MEC-Plattform 2432 und des EES 2155, die diesen Dual-Mode-API-Verbrauch ermöglichen, einschließlich der Edge-Plattform-Umsetzungen.
  • Bei einigen Aspekten soll der Ausgangspunkt eine App bereits an Bord und entweder als ETSI oder als 3GPP in Betrieb haben. In beiden Fällen werden als erste Arbeitsannahme die Onboarding-Mechanismen nicht verändert. Die Ausführungsformen hierin stellen diese Kreuzaufdeckung von einer App zur Verfügung.
  • Der ETSI-MEC-Beitrag [MEC(20)000390r1] stellt einen visuellen Vergleich der beiden Standards, die mit Edge-Plattformen zusammenhängen (zum Beispiel zwischen ETSI-MEC und 3GPP), der auch von Tabelle 1 gezeigt ist, bereit. Dies zeigte eine gute Ausrichtung der beiden Standards sowie eine gute Komplementarität von APIs, die von den beiden SDOs angeboten werden, zeigt aber noch nicht im Detail, wie Edge-Anwendungen beide Sätze von APIs verbrauchen können. Tabelle 1
    Merkmal/ Fähigkeit EES (3GPP SA6) MEC-Plattform (ETSI MEC) Kommentare
    Allgemeine r Zweck • Bereitstellung von Informationen für EAS 2150-Entdeckung zu EEC 2115. • Bereitstellen der App-Lookup-Vorgehensweise durch UALCMP. Im Allgemeinen definieren die beiden Standardgruppen dieselben grundlegenden Plattformmerkmale.
    • Bereitstellen von MEC-Diensten durch APIs zu MEC-Anwendungen, die sich an demselben Ort befinden oder entfernt sind.
    • Bereitstellung von Edge-Diensten durch APIs zu EASs 2150 an demselben Ort.
    • Unterstützung der Anwendungskontextübertragung
    • Unterstützung von Anwendungskontextübertragung
    • Unterstützung der allgemeinen Dienstentdeckung
    • Unterstützung der MEC-Dienstentdeckung
    (über Dienstregistrierung)
    Edge-App-Entdeckun g EEC 2115/EES 2155-Interaktion Auch DNS-basiert ist möglich ([ETSIWP36], Abschnitt 3.3.1) DNS-basiert Während die App-Entdeckung in ETSI MEC nur auf DNS basiert, sieht der SA6-Standard auch ein anderes vorrichtungsbasiertes Verfahren voraus.
    Dienst-APIs APIs für EAS 2150-Registrierung APIs zur gemeinsamen Nutzung von EAS 2150-Profilen APIs zur Bereitstellung von 3GPP-Kerndiensten an EASs 2150 APIs für UE-Identifikation und UEbezogene Ereignisse MEC-Anwendungunterstützungs-API (siehe zum Beispiel [MEC011]) MEC-Dienstverwaltungs-API (siehe zum Beispiel [MEC011]) Hauptsächlich sind die 2 Sätze von APIs (die sich auf Edge-Dienste beziehen, die den Apps aufgedeckt werden) komplementär. Dies kann insbesondere für Produkte, die beiden Normen entsprechen, ein großer Mehrwert sein.
    RNI-API (siehe zum Beispiel [MEC012]) Location-API (siehe zum Beispiel [MEC013]) UE-Identity-API (siehe zum Beispiel [MEC014]) UE-App-Interface-API (siehe zum Beispiel [MEC016]) Fixed-Access-Info-API (siehe zum Beispiel [MEC029]) Traffic-Mgmt-APIs (siehe zum Beispiel [MEC015]) WLAN-Info-API (siehe zum Beispiel [MEC028]) V2X-Info-Dienst-API (siehe zum Beispiel [MEC030])
    Anwendun gskontextü bertragung APIs zur Subskription für UE-Mobilitätsereignisse APIs unterstützen die Entdeckung von Ziel-EASs 2150 (Interaktion mit anderen EESs 2155). APIs zur Beeinflussung von 3GPP core User Plain path settings APP-Mobilitätsdienst-API (siehe zum Beispiel [MEC021]) Anwendungslebenszyklus-, Regel- und Anforderungsmanagement (siehe zum Beispiel [MEC010-2])
    Allgemeine Entdeckun 9 Ermöglicht es EASs, Dienste über CAPIF anzukündigen ETSI-MEC abgeglichen mit CAPIF (siehe zum Beispiel [MEC031]) Gute Ausrichtung
  • [MEC011] definiert sowohl eine MEC-Anwendungunterstützungs-API (zum Beispiel MEC-Anwendungsassistenz, anwendungsspezifisches Verkehrsrouten (zum Beispiel Aktualisierungen, Aktivierung, Deaktivierung), DNS-Regeln (zum Beispiel Aktivierung, Deaktivierung) als auch Timing (zum Beispiel Bereitstellen von bisherigem Zugriff, Zeitzonen- und/oder Tageszeitinformationen) sowie ordnungsgemäßes Herunterfahren/Stoppen) und einer MEC-Dienstverwaltungs-API (zum Beispiel MEC-Dienstassistenz und assoziierte Diensttransportinformationen). Die MEC-Anwendungsassistenzfunktionalität kann zum Beispiel MEC-Anwendungsstartvorgehensweise(en) und/oder ordnungsgemäßes MEC-Anwendungs-Herunterfahren/Stoppen beinhalten. Die MEC-Dienstassistenzfunktionalität kann zum Beispiel Authentifizierung und Autorisierung des Erzeugens und Verbrauchens von MEC-Diensten 2436; ein Mittel zum Diensterzeugen von MEC-Apps 2426 zum Registrieren/Abmelden bei der MEC-Plattform 2432 beinhalten, die MEC-Dienste 2436, die sie bereitstellen, und die MEC-Plattform 2432 über Änderungen der MEC-Diensteverfügbarkeit zu aktualisieren; ein Mittel zum Benachrichtigen der relevanten MEC-App 2426 über Änderungen der MEC-Diensteverfügbarkeit; und Entdecken verfügbarer MEC-Dienste 2436.
  • Die Diensttransportinformationen können Informationen über verfügbare Transporte, Informationen bezüglich eines bestimmten von einem Dienst verwendeten Transports, eine Transport-ID (eine Kennung des von dem Dienst zu verwendenden Transports), einen Transportnamen, eine menschenlesbare Beschreibung dieses Transports, die Art des Transports, einen Transportprotokollnamen und eine Transportprotokollversion, Informationen über den Endpunkt zum Zugreifen auf den Transport, Informationen über die von dem Transport verwendete Sicherheit (zum Beispiel OAuth 2.0, TLS usw.), zusätzliche umsetzungsspezifische Einzelheiten des Transports und/oder andere ähnliche Informationen beinhalten. Das Bereitstellen eines MEC-Diensts 2436 bedeutet die Verwendung eines Transports zum Liefern des MEC-Diensts 2436 an die MEC-Apps 2426, die den MEC-Dienst 2436 verbrauchen. Jeder MEC-Dienst 2436 ist an einen Transport gebunden, der entweder von der MEC-Plattform 2432 oder von der MEC-App 2426 selbst bereitgestellt wird. Transporte, die für Zwecke der vorliegenden Offenbarung verwendet werden können, beinhalten ein beliebiges Protokoll, das Kommunikation zwischen Instanzen der MEC-App 2426 und der MEC-Plattform 2432 oder zwischen Instanzen der MEC-App 2426 unterstützt. Beispiele für Transporte, die unter Verwenden der hierin beschriebenen Mechanismen verwendet und/oder angegeben werden können, beinhalten REST-HTTP (RESTful-API unter Verwenden von HTTP (wie in IETF RFC 7230 und verwandten Spezifikationen definiert), möglicherweise auch unter Verwenden von TLS; auf Themen basierte Nachrichtenbusse (Protokolle, die Nachrichten zu Empfängern basierend auf Subskriptionen routen, falls ein an die Subskription weitergeleitetes Muster mit dem Thema der Nachricht übereinstimmt; zum Beispiel, Message Queue Telemetry Transport (MQTT), Apache™ Kafka usw.); auf Routing basierter Nachrichtenbus (Protokolle, die Nachrichten an Empfänger basierend auf Subskriptionen routen, falls ein Schlüssel, der an die Subskription weitergeleitet wird, gleich dem Schlüssel der Nachricht ist); Publish-Subscribe-Nachrichtenbusse (Pub/Sub-Nachrichtenbusse) (Protokolle, die Nachrichten an alle Teilnehmer verteilen); Remote-Procedure-Call-Frameworks (RPC-Frameworks) (zum Beispiel gRPC™, Apache™ Thrift usw.); RPC-Streaming-Frameworks (RPC-Frameworks, die Streams von Anfragen und Antworten unterstützen, wie etwa gRPC™ und dergleichen); Web-Socket (Web-Sockets, wie in IETF RFC 6455 definiert); Zenoh-Transportprotokoll, das von der Eclipse Foundation™ bereitgestellt wird; und/oder ein beliebiges anderes ähnliches Protokoll, wie etwa die hierin erläuterten. Die in [MEC011] beschriebene Transportinformationsanfrage stellt ein standardisiertes Mittel für MEC-Apps 2426 bereit, um verfügbare Transporte von einer MEC-Plattform 2432 zu entdecken.
  • 1.1. AUFDECKUNGSASPEKTE DER EDGE-DIENST-APIs
  • 3 veranschaulicht eine beispielhafte Architektur 300 für Netzwerkaufdeckungsfunktion (Network Exposure Function - NEF) 2952 in einer Referenzpunktdarstellung. In 3 ist die Vertrauensdomäne für die NEF 2952 gleich der Vertrauensdomäne für die Dienstleistungsfähigkeitsaufdeckungsfunktion (Service Capability Exposure Function - SCEF), wie in 3GPP TS 23.682 v16.8.0 (2020-09-24) („[TS23682]“) erläutert. Die 3GPP-Schnittstelle zwischen den NEFs 2952 und den 5GC 2940 Netzwerkfunktionen (NFs) 1-n stellt eine oder mehrere Southbound-Schnittstellen (zum Beispiel N29-Schnittstelle zwischen NEF 2952 und SMF 2946, N30-Schnittstelle zwischen NEF 2952 und PCF 2956 usw.) dar. Die Southbound-Schnittstellen aus dem NEF 2952 sind der Einfachheit halber nicht gezeigt.
  • Gemäß [TS23501] ist die NEF 2952 für Dienstaufdeckung sowohl für AFs 2960 innerhalb als auch außerhalb der vertrauenswürdigen 3GPP-Domäne zuständig. Zur Aufdeckung von Fähigkeiten und Ereignissen können NF-Fähigkeiten und Ereignisse sicher von der NEF 2952, zum Beispiel der Drittpartei, AFs 2960 und Edge-Computing, wie in Klausel 5.13 von [TS23501] beschrieben, aufgedeckt werden. Die NEF 2952 stellt auch ein Mittel für die AFs 2960 zum sicheren Bereitstellen von Informationen an das 3GPP-Netzwerk (zum Beispiel erwartetes UE-Verhalten, 5G-VN-Gruppeninformationen, Zeitsynchronisationsdienstinformationen und dienstspezifische Informationen) bereit. In diesem Fall kann die NEF 2952 die AFs 2960 authentifizieren und autorisieren und beim Drosseln unterstützen. Die NEF 2952 übersetzt auch zwischen Informationen, die mit einer AF 2960 ausgetauscht werden, und Informationen, die mit den internen NFs ausgetauscht werden. Zum Beispiel übersetzt die NEF 2952 zwischen einer AF-Service-Kennung und internen 5G-Kerninformationen, wie etwa DNN, S-NSSAI, wie in Klausel 5.6.7 von [TS23501] beschrieben. Insbesondere handhabt die NEF 2952 das Maskieren von Netzwerk- und benutzersensitiven Informationen zu externen AFs 2960 gemäß der Netzwerkrichtlinie. Andere Aspekte der NEF 2952 sind in [TS23501] erläutert. Zusätzliche Aspekte im Zusammenhang mit der NEF 2952 und ihrer Beziehung mit dem MEC-System 2400 finden sich in ETSI-GR MEC 031 V2.1.1 (2020-10) („[MEC031]“).
  • Die NEF 2952 ist die 5G-NF, der es obliegt, die Netzwerkfähigkeiten und Ereignisse zu AFs und anderen Verbrauchern sicher aufzudecken, wie in [TS23501], Klausel 6.2.5 definiert. Zwei Typen von AFs 2960 sind möglich: vertrauenswürdige AFs 2960 und nicht vertrauenswürdige AFs 2960. AFs 2960, welchen der Bediener direkten Zugriff auf die Ziel-NFs nicht erlaubt, verwenden die NEF 2952 für ihre Interaktionen. Während die NEF 2952 für nicht vertrauenswürdige AFs 2960 verwendet wird, kann eine vertrauenswürdige AF 2960 über die NEF 2952 mit 5GS-Funktionen eine Schnittstelle bilden, oder direkt mit 5GS-Funktionen, wie etwa SMF 2946 usw., eine Schnittstelle bilden. Die Einzelheiten der externen Aufdeckung der Fähigkeiten sind in [TS23501] definiert. Die Restful APIs zur Fähigkeitsaufdeckung sind in ETSI TS 129 522 V16.4.0 (2020-08) und/oder [TS29522] definiert.
  • Eine AF 2960 kann Dienste von mehreren NEFs 2952 beziehen, und eine NEF 2952 kann mehrere AFs 2960 Dienst bereitstellen. Eine beliebige Instanz einer NEF 2952 kann nur einen Teilsatz oder die gesamte verfügbare NEF-Funktionalität unterstützen. Eine NEF 2952 kann CAPIF-Funktionalität und insbesondere die CAPIF-API-Providerdomänenfunktionen für externe Aufdeckung ETSI TS 123 222 V15.2.0 (2018-07) und/oder [TS23222] unterstützen. Darüber hinaus sind zusätzliche Aspekte im Zusammenhang mit 3GPP-CAPIF in [MEC031] erläutert.
  • 4 bildet eine beispielhafte CAPIF-Funktionsarchitektur 400 ab, die die Verbindung zwischen unterschiedlichen Systemen zeigt, wobei API-Aufdeckungsfunktionen (AEFs) 401, die zu unterschiedlichen Domänen gehören, durch das Vorhandensein einer CAPIF-Kernfunktion (CAPIF Core Function - CCF) 405 interagieren können. Das CAPIF ist ein Framework, das gemeinsame API-Aspekte umfasst, die benötigt werden, um Dienst-APIs zu unterstützen. 3GPP hat die Entwicklung eines gemeinsamen API-Framework (CAPIF) für 3GPP Northbound-APIs betrachtet, das gemeinsame Aspekte beinhaltet, die für beliebige Northbound-Dienst-APIs gelten. Im Kontext von CAPIF ist die Northbound-API eine Dienst-API, die API-Aufrufern 410 höherer Schicht aufgedeckt ist. Das CAPIF-Funktionsmodell 400 ist in Funktionsentitäten organisiert, um eine Funktionsarchitektur zu beschreiben, die es einem API-Aufrufer 410 ermöglicht, auf Dienst-APIs zuzugreifen und diese aufzurufen, und AEFs 401 beim Veröffentlichen der API gegenüber den API-Aufrufern 410 unterstützt. Die Begriffe „Funktionsarchitektur“ und „Funktionsmodell“ haben dieselbe Bedeutung und wurden in dieser Beschreibung austauschbar verwendet.
  • Die CAPIF-Funktionsarchitektur 400 ist dienstbasiert, und Interaktionen zwischen den CAPIF-Funktionen werden auf zwei Weisen dargestellt: als dienstbasierte Darstellung, wobei es CAPIF-Funktionen anderen autorisierten CAPIF-Funktionen ermöglichen, auf ihre Dienste zuzugreifen; und als eine Referenzpunktdarstellung, wobei Interaktionen zwischen beliebigen zwei CAPIF-Funktionen (zum Beispiel CCF 405, AEF 401 usw.) von einem zweckdienlichen Punkt-zu-Punkt-Referenzpunkt (zum Beispiel CAPIF-3 und dergleichen) gezeigt werden. Die CAPIF-Funktionsarchitektur 400 kann von einer beliebigen 3GPP-Funktionalität, die Dienst-APIs bereitstellt, und/oder 3GPP-Northbound-Dienst-APIs übernommen werden. Von der CAPIF angebotene Dienste sind in [TS29222] erläutert.
  • Die AEFs 401 sind Entitäten, die den Dienstkommunikationseintrittspunkt für Dienst-APIs bereitstellen. AEFs 401 sind Anbieter der Dienst-APIs und auch der DienstkommunikationsEintrittspunkt der Dienst-API zu den API-Aufrufern 410. Die AEFs 401 beinhalten die folgenden Fähigkeiten: Authentifizieren des API-Aufrufs 410 basierend auf der Identität und anderen Informationen, die für die Authentifizierung des API-Aufrufs 410 erforderlich sind, die von der CCF 405 bereitgestellt werden; Validieren der Autorisierung, die von der CCF 405 bereitgestellt wird; und Protokollieren der Dienst-API-Aufrufe an der CCF 405. Jede AEF 401 ist mit einem AEF-Ort assoziiert, der die Ortsinformationen (zum Beispiel zivile (physische) Adresse, GPS-Koordinaten, Datenzentrum-ID und/oder eine andere Netzwerkkennung) umfasst, an denen sich die AEF 401, die die Dienst-API bereitstellt, befindet.
  • Die API-Veröffentlichungsfunktion (APF) 402 ermöglicht es dem API-Anbieter, die Dienst-APIs-Informationen zu veröffentlichen, um die Entdeckung von Dienst-APIs durch den API-Aufrufer 410 zu ermöglichen. Die APF 402 beinhaltet die folgenden Fähigkeiten: Veröffentlichen der Dienst-API-Informationen des API-Anbieters an die CCF 405.
  • Die API-Verwaltungsfunktion (AMGF) 403 ermöglicht es dem API-Anbieter, eine Verwaltung der Dienst-APIs auszuführen. Die AMGF 403 beinhaltet die folgenden Fähigkeiten: Auditieren der von der CCF 405 empfangenen Dienst-API-Aufrufprotokolle; Überwachen der von der CCF 405 gemeldeten Ereignisse; Konfigurieren der API-Anbieterstrategien zu der CCF 405; Überwachen des Status der Dienst-APIs; Onboarding der neuen API-Aufrufer 410 und Offboard der API-Aufrufer 410; und Registrieren und Führen von Registrierungsinformationen der API-Anbieter-Domainfunktionen auf der CCF 405. Der Begriff „Onboarding“ betrifft mindestens bei einigen Ausführungsformen einen einmaligen Registrierungsprozess, der es dem API-Aufrufer 410to ermöglicht, anschließend auf die CAPIF und die Dienst-APIs zuzugreifen.
  • Die AEF 401, die APF 402 und die AMGF 403 sind Teil der API-Anbieterdomäne, die von einer SCEF (Service Capability Exposure Function) in 3GPP-LTE-Systemen und/oder einer NEF (Network Exposure Function) 2952 in einem 5GC umgesetzt werden kann (siehe zum Beispiel 3 und 29).
  • Die CCF 405 beinhaltet die folgenden Fähigkeiten: Authentifizieren des API-Aufrufs 410 basierend auf der Identität und anderen Informationen, die zur Authentifizierung des API-Aufrufs 410 benötigt werden; Unterstützen einer gegenseitigen Authentifizierung mit dem API-Aufrufer 410; Bereitstellen einer Autorisierung für den API-Aufrufer 410 vor dem Zugreifen auf die Dienst-API; Veröffentlichen, Speichern und Unterstützen der Entdeckung von Dienst-API-Informationen; Steuern des Dienst-API-Zugriffs basierend auf durch den PLMN-Betreiber 2315 konfigurierten Richtlinien; Speichern der Protokolle für die Dienst-API-Aufrufe und Bereitstellen der Dienst-API-Aufruf-Protokolle für autorisierte Entitäten; basierend auf den Protokollen Laden der Dienst-API-Aufrufe; Überwachen der Dienst-API-Aufrufe; Onboarding eines neuen API-Aufrufs 410 und Offboarding eines API-Aufrufs 410; Speichern von Strategienkonfigurationen in Bezug auf CAPIF- und Dienst-APIs; Unterstützen des Zugriffs auf die Protokolle zum Auditieren (zum Beispiel Erfassen von Missbrauch); und Unterstützen des Veröffentlichens, Entdeckens von Dienst-APIs-Informationen mit einer anderen CCF 405 in der CAPIF-Interconnect.
  • Der API-Anbieter (zum Beispiel API-Anbieterdomäne 1 und/oder API-Anbieterdomäne 2 in 4) hostet eine oder mehrere Dienst-APIs und weist eine Dienst-API-Anordnung mit einem CAPIF-Anbieter auf, um die Dienst-APIs einem oder mehreren API-Aufrufern 410 anzubieten. Eine Dienst-API ist eine Schnittstelle, über die eine Komponente des Systems ihre Dienste API-Aufrufern 410 durch Abstrahieren der Dienste von den zugrunde liegenden Mechanismen aufgedeckt.
  • Ein API-Aufrufer 410 ist eine Instanz, die die CAPIF- oder Dienst-APIs aufruft. Der API-Aufrufer 410 wird typischerweise von einem Drittpartei-Anwendungsanbieter bereitgestellt, der Dienstvereinbarung mit dem PLMN-Betreiber 2315 hat. Der API-Aufrufer 410 unterstützt die folgenden Fähigkeiten: Unterstützen der Authentifizierung durch Bereitstellen der API-Aufruferidentität (ID) und anderer Informationen, die zur Authentifizierung des API-Aufrufers 410 benötigt werden; Unterstützen einer gegenseitigen Authentifizierung mit CAPIF; Erhalten der Autorisierung vor dem Zugreifen auf die Dienst-API; Entdecken von Dienst-API-Informationen; und Aufrufen der Dienst-APIs. Die API-Aufrufer 410 können ein API-Aufruferprofil beinhalten, das ein Satz von Informationen ist, die mit einem API-Aufrufer 410 assoziiert sind, der es diesem API-Aufrufer 410 erlaubt, CAPIF-APIs und Dienst-APIs zu nutzen.
  • Die CAPIF wird innerhalb eines öffentlichen terrestrischen Mobilfunknetz-Betreibernetzwerks (Public Land Mobile Network - PLMN-Betreibernetzwerks 420 gehostet. Der API-Aufrufer 410 wird typischerweise von einem Drittpartei-Anwendungsanbieter bereitgestellt, der eine Dienstvereinbarung mit dem PLMN-Betreiber 2315 und/oder einem CAPIF-Anbieter hat. Der API-Aufrufer 410 kann sich innerhalb derselben Vertrauensdomäne wie das PLMN-Betreibernetzwerk 2315 (zum Beispiel PLMN-Vertrauensdomäne 420) befinden. Die PLMN-Vertrauensdomäne 420 betrifft Entitäten, die durch ausreichende Sicherheit geschützt sind und von dem PLMN-Betreiber oder einer vertrauenswürdigen Drittpartei des PLMN gesteuert werden. Die Vertrauensdomäne 430 der Drittpartei verweist auf Entitäten, die durch ausreichende Sicherheit geschützt sind und von einer entsprechenden Drittpartei gesteuert werden. Der CAPIF-Anbieter und der API-Anbieter können Teil derselben Organisation (zum Beispiel PLMN-Betreiber 2315) sein, wobei in diesem Fall die Geschäftsbeziehung zwischen beiden innerhalb einer einzigen Organisation liegt. Der CAPIF-Anbieter und der API-Anbieter können Teil unterschiedlicher Organisationen sein, wobei dann die Geschäftsbeziehung zwischen beiden bestehen muss.
  • In einem referenzpunktbasierten Modell interagiert der API-Aufrufer 410 innerhalb der PLMN-Vertrauensdomäne 420 (zum Beispiel API-Aufrufer 410-2 in 4) mit der CAPIF über die CAPIF-1- und CAPIF-2-Referenzpunkte. Der API-Aufrufer 410 von außerhalb der PLMN-Vertrauensdomäne (zum Beispiel API-Aufrufer 410-1 und/oder 410-3 in 4) interagiert mit der CAPIF über CAPIF-1e und CAPIF-2e. Die AEF 401, die APF 402 und die AMGF 403 der API-Anbieterdomäne (gemeinsam als die „API-Anbieterdomänenfunktionen“ bekannt) innerhalb der PLMN-Vertrauensdomäne 420 interagieren mit der CCF 405 jeweils über die CAPIF-3-, CAPIF-4-bzw. CAPIF-5-Referenzpunkte.
  • Der CAPIF-1-Referenzpunkt verbindet einen API-Aufrufer 410-2 innerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405 über CAPIF-APIs. Der CAPIF-2-Referenzpunkt verbindet einen API-Aufrufer 410-2 innerhalb der PLMN-Vertrauensdomäne 420 mit der AEF 401 innerhalb der PLMN-Vertrauensdomäne 420. Der CAPIF-3-Referenzpunkt verbindet die AEF 401 innerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405. Der CAPIF-4-Referenzpunkt verbindet die APF 402 innerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405. Der CAPIF-5 Referenzpunkt verbindet die AMGF 403 innerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405.
  • Die CCF 405 in der PLMN-Vertrauensdomäne 420 unterstützt Dienst-APIs sowohl der PLMN-Vertrauensdomäne 420 als auch der Vertrauensdomäne 430 der Drittpartei, die eine Geschäftsbeziehung mit der PLMN-Vertrauensdomäne 420 aufweisen. Die API-Aufrufer 410 können innerhalb der PLMN-Vertrauensdomäne 420 (zum Beispiel API-Aufrufer 410-2), innerhalb der Vertrauensdomäne 430 der Drittpartei (zum Beispiel API-Aufrufer 410-3) oder außerhalb sowohl der PLMN-Vertrauensdomäne 420 als auch der Vertrauensdomäne 430 der Drittpartei (zum Beispiel API-Aufrufer 410-1) existieren.(
  • Der CAPIF-1e-Referenzpunkt verbindet API-Aufrufer 410-1, 410-3 außerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405. Der CAPIF-2e-Referenzpunkt verbindet einen API-Aufrufer 410-2 innerhalb der PLMN-Vertrauensdomäne 420 mit der AEF 401 außerhalb der PLMN-Vertrauensdomäne 420, verbindet einen API-Aufrufer 410-3 außerhalb der PLMN-Vertrauensdomäne 420 mit der AEF 401 innerhalb der PLMN-Vertrauensdomäne 420 und verbindet API-Aufrufer 410-1, 410-3 außerhalb der Drittpartei-Vertrauensdomäne 430 mit der AEF 401 innerhalb der Drittpartei-Vertrauensdomäne 430. Der CAPIF-3e-Referenzpunkt verbindet die AEF 401 außerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405. Der CAPIF-4e-Referenzpunkt verbindet die APF 402 außerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405. Der CAPIF-5e-Referenzpunkt verbindet die AMGF 403 außerhalb der PLMN-Vertrauensdomäne 420 mit der CCF 405.
  • Der CAPIF-7- (in 4 nicht gezeigt) und der CAPIF-7e-Referenzpunkt verbinden die AEF 401 innerhalb der PLMN-Vertrauensdomäne 420 und die AEF 401 außerhalb der PLMN-Vertrauensdomäne 420. [TS23222] spezifiziert ein Funktionsmodell für Interaktionen zwischen den AEFs 401. Obwohl dies in 4 nicht gezeigt ist, kann CAPIF-4 zusätzlich auch CAPIF-6- und CAPIF-6e-Referenzpunkte beinhalten. Die CAPIF-6- und CAPIF-5e-Referenzpunkte verbinden zwei CCFs 405, die sich jeweils in der gleichen oder in unterschiedlichen PLMN-Vertrauensdomänen 420 befinden. Die CAPIF-6/6e-Referenzpunkte erlauben es API-Aufrufern 410 eines CAPIF 400-Anbieters, die Dienst-APIs von dem CAPIF-Anbieter der Drittpartei oder einem anderen CAPIF-Anbieter innerhalb der Vertrauensdomäne(n) zu nutzen.
  • Verschiedene zusätzliche Aspekte der CAPIF 400 sind ausführlicher in [TS29222] und [TS23222] erläutert. Der Cross-Verbrauch von APIs ist theoretisch möglich, aber nicht spezifiziert. Darüber hinaus wird, was die spezifische Abbildung zwischen CAPIF- und MEC-Funktionalitäten betrifft, kein eigentlicher Mechanismus definiert.
  • 1.2. 3GPP-SA6-MECHANISMEN FÜR DIENST-API A UFDECKUNG.
  • Dienst-APIs können von dem Edge-Enabler-Server (EES) 2155 unter Verwenden des CAPIF-Framework 400 aufgedeckt werden. Das CAPIF-Framework 400 führt die folgenden Funktionen ein: AEF 401 (die Entität, die Dienste über API bereitstellt); API-Aufrufer 410 (die Entität, die diese API verwendet); APF 402 (die Entität, die APIs an alle potenziellen API-Aufrufer 410 veröffentlicht); AMGF 403 (führt eine Verwaltung der Dienst-APIs (zum Beispiel Auditieren, Überwachen usw.) aus); und die CCF 405 (die Funktion, die das CAPIF-Framework 400 verwaltet).
  • Für Edge-Datennetzwerke (Edge Data Networks - EDNs) kann der EES 2155 die CCF 405 hosten. Der EES 2155 dient auch als AEF 401 und AMGF 403 und dient auch als eine NEF 2952, die APIs EASs 2150 aufgedeckt. Die SA6-Edge-Umgebung unterstützt auch spezielle EASs 2150, die anderen EASs 2150 Dienste bereitstellen. In diesem Hinblick werden diese Dienste durch Veröffentlichen von APIs zu der CCF 405 in den EES 2155 bereitgestellt, und die CCF 405 führt diese APIs allen EASs 2150 zu.
  • Gemäß Anhang A.4.3 von [TS23558] stellt nichtnormative Informationen darüber bereit, Dienste verschiedener vertikaler Elemente (zum Beispiel V2X Server, V2X Anwendungsfreigabeserver usw.) anderen EASs 2150 bereitzustellen, einschließlich: der EES 2155 kann als die CCF 405 fungieren, und der vertikale Anwendungsfreigabeserver tritt für die AEF 401 auf und veröffentlicht die APIs des vertikalen Anwendungsfreigabeservers zu dem EES 2155. Weiter werden die APIs des vertikalen Anwendungsfreigabe-Servers von den EASs 2150, die als der API-Aufrufer 410 fungieren, während der Dienst-API-Entdeckungvorgehensweise entdeckt, wie in [TS23222] spezifiziert.
  • Dennoch geben aktuelle Spezifikationen nicht an, wie diese Aufdeckung ermöglicht wird. Darüber hinaus berücksichtigt die vorliegende Offenbarung den spezifischen Fall des EES 2155 nicht, der als die CCF 405 agiert, sondern stellt einen allgemeineren Fall bereit, bei dem die zwei Entitäten getrennt sind (und über den CAPIF-3-Referenzpunkt verbunden sind). Die Ausführungsformen hierin sind auf die Fälle anwendbar, in denen der EES 2155 als die CCF 405 agiert.
  • 1.3. MEC-PLATTFORM IN CAPIF
  • Die aktuellen/existierenden Lösungen (zum Beispiel hauptsächlich 3GPPSA6 und ETSI-MEC) definieren keine spezifischen Mechanismen zum Zweck des gezielten Cross-API-Verbrauchs für Edge-Systeme. Tatsächlich befasst sich die aktuelle SA6-Spezifikation einerseits nicht mit Unterstützung für eine Nicht-3GPP-Dienstaufdeckung. Dieses Problem wird von unserer Erfindung gelöst (indem sie zum Beispiel ETSI-MEC-Dienste von einem „PSEUDO-EAS“ bereitstellt, das seine Dienste über APIs an die CCF 405 in dem EES 2155 veröffentlicht).
  • Aktuelle ETSI-MEC-Spezifikationen beschreiben nicht, wie eine MEC-App 2426 direkt 3GPP-Dienste verbrauchen kann. Die MEC-Apps 2426 befinden sich nämlich gewöhnlich in einer nicht vertrauenswürdigen Umgebung. Somit sollte dieser Verbrauchsmechanismus idealerweise von einer ordnungsgemäßen 3GPP-Funktionalität oder von einer Art Überbrückungsentität verwaltet werden, die eine Autorisierung zum Verbrauchen dieser Dienste von MEC-Apps 2426 zu 3GPP-Funktionen gewährleisten kann. Es gibt High-Level-Szenarien, die in [MEC031] beschrieben sind, die beschreiben, wie CAPIF und MEC gekoppelt werden sollen (siehe zum Beispiel 5). Dennoch werden keine technischen Angaben dazu gemacht, wie dies praktisch erfolgen kann.
  • 5 zeigt verschiedene Einsatzmöglichkeiten 501, 502 und 503 zur Integration der MEC und CAPIF. In 3GPP gibt es mehrere Northbound-API-bezogene Spezifikationen (zum Beispiel APIs für SCEF, API für die Schnittstelle zwischen MBMS-Dienstanbieter und BM-SC, APIs für NEF). Um Duplizierung und Inkonsistenz des Ansatzes zwischen unterschiedlichen API-Spezifikationen zu vermeiden, hat 3GPP die Entwicklung der CAPIF für Northbound-3GPP-APIs betrachtet, die gemeinsame Aspekte beinhaltet, die auf beliebige Northbound-Dienst-APIs anwendbar sind.
  • Die Beziehung zwischen dem MEC-API-Framework und der CAPIF kann beinhalten, dass die MEC-Plattform 2432 API-bezogene Plattformfunktionalität, wie etwa Dienstregistrierung (zum Beispiel Dienstregistrierung 2438 in 24), beinhaltet. Zusätzlich dazu kann die MEC-Plattform 2432 auch MEC-Dienst-APIs zum Verbrauch durch MEC-Apps 2426 aufdecken. Die API-Anbieterdomäne in CAPIF stellt kollektiv die Dienst-APIs, die zum Verbrauch in einer beliebigen 5G NF und einer beliebigen vertrauenswürdigen Drittpartei-AF 2960 verfügbar sind, dar. Ein MEC-Dienst 2436, der von einer MEC-App 2426 oder von der MEC-Plattform 2432 erzeugt wird, kann in der CAPIF in die API-Anbieterdomäne abgebildet werden. Eine MEC-App 2426 oder MEC-Plattform 2432, die einen Dienst verbraucht, ist ein API-Aufrufer 410 in der CAPIF 400. Die bestehende Funktionalität der MEC-Plattform 2432 in Bezug auf die API-Freigabe kann in die CCF 405 abgebildet werden.
  • Die MEC-Plattform 2432 unterstützt auch die Verkehrsregelsteuerung 2440 und DNS-Handhabung 2442 (siehe zum Beispiel 24). Bei 5GS wurde die Verkehrsregelsteuerung von einer AF 2960 als eine Prozedur zwischen der AF 2960 und der SMF 2946, möglicherweise unter Beteiligung der NEF, definiert, wie in Klausel 4.3.6 von ETSI TS 123 502 v16.7.0 (2021-01) und/oder [TS23502] definiert.
  • Insbesondere ist
  • die Einsatzoption 501 ist ein lose gekoppelter Einsatz von CAPIF und MEC, der Zugang zu MEC-APIs über eine externe CAPIF-Instanz bereitstellt. Bei dieser Option wird davon ausgegangen, dass eine MEC-Plattform und ein CAPIF-Einsatz in dem Netzwerk koexistieren, und dass CAPIF-API-Aufrufer 410 auf MEC-Dienste 2436 zugreifen wollen, die von der MEC-Plattform 2432 oder von MEC-Apps 2426 über die RESTful MEC-Dienst-APIs bereitgestellt werden. Dabei gilt: MEC-APIs sollen in der CAPIF-REGISTRY ankündigbar sein; und die CAPIF-Registrierung soll beim Zugriff auf MEC-APIs nutzbar sein. Dies könnte über ein Gateway oder durch Aktualisieren der MEC-API, die Funktionen aufgedeckt, um die CAPIF-Sorte von Autorisierung zu verstehen, realisiert werden. Dieser Anwendungsfall kann erfüllt werden, indem sowohl in der Registrierung der CCF 405 in dem Netzwerk als auch in den Registrierungen in der oder den MEC-Plattform(en) 2432 dieselbe Dienst-API redundant angekündigt wird. In der MEC kommt es auf den Ort des API-Produzenten an. Wie mehrere Instanzen desselben Dienstes bei Verwendung von CAPIF an unterschiedlichen Orten (zum Beispiel unterschiedliche MEC-Plattformen 2432) verfügbar sind, wurde nicht erstellt.
  • Bei der Einsatzoption 501 unterstützt der MEC-Referenzpunkt Mp1 Veröffentlichung von MEC-Diensten („M-Veröffentlichung“), Entdeckung/Ankündigung von MEC-Diensten („M-Entdeckung“) und weitere MEC-Anwendungsunterstützung („Support“), wie etwa Aktivierung von Verkehrsregeln 2440 und dergleichen. Die CCF 405 unterstützt Publikation („C-Publication“) und Entdeckung („C-Discovery“) von CAPIF-APIs. Die einfachste Integrationsmöglichkeit besteht darin, die MEC-Dienst-APIs über CAPIF neu zu veröffentlichen.
  • Einsatzoption 502 ist ein vollständig integrierter hybrider Einsatz von CAPIF und MEC. Bei der Einsatzoption 502 wird davon ausgegangen, dass ein Einsatz existiert, der MEC und CAPIF vereint. Bei einer derartigen Realisierung ersetzt CAPIF jene Mp1 -Teile, die sich mit CAPIF überlappen (wie etwa die MEC-Dienstregistrierung 2438 von RESTful MEC-Diensten). Die Registrierung 2438 für die MEC-Dienste 2436 basiert auf CAPIF; gleiches gilt für die Autorisierung. Die MEC-Plattform 2432 kann von einer weiteren Unterstützung der CCF 405 profitieren, wie etwa Protokollieren. Alle Aufrufe von RESTful-APIs werden mit CAPIF ermöglicht. Dies bedeutet, dass MEC-Apps 2426 MEC-APIs unter Verwenden von CAPIF-Unterstützung verbrauchen müssten und die Autorisierung des CAPIF unterstützen müssten. Zusätzlich wird noch eine weitere Unterstützung der MEC-App 2426 („Support“) bereitgestellt. Die Entität, die Schnittstellen aufgedeckt, ist eine Anwendung, die Fähigkeiten, die für die MEC-Plattform 2432 definiert sind, und Fähigkeiten, die für die CCF 405 definiert sind, kombiniert.
  • Die vollständig integrierte Bereitstellung 502 würde jedoch das MEC-Konzept alternativer Transporte nicht unterstützen; sie würde nur für RESTful APIs gelten. Zur zusätzlichen Unterstützung alternativer Transporte müsste noch ein MEC-Dienstregister 2438 unterstützt werden. Es besteht jedoch kein Bedarf an Redundanz, im Gegensatz zu der Einsatzoption 501 werden alle RESTful Dienst-APIs über CAPIF veröffentlicht und entdeckt; diejenigen Dienste, auf die über alternative Transporte zugegriffen wird, sind Teil des MEC-Dienstregisters 2438. Die Einsatzoption 503 ist ein hybrider Einsatz von CAPIF und MEC mit Unterstützung für MEC-Alternativtransporte. Eine Alternative ist die Entwicklung von CAPIF durch Hinzufügen eines Erweiterungsmechanismus, der es MEC ermöglichen würde, alternative Transporte als MECspezifische CAPIF-Erweiterung zu spezifizieren. Für diesen Zweck wäre eine Interaktion mit 3GPP erforderlich.
  • Gemäß existierenden Lösungen liefert keines der Szenarien Details dazu, wie ein Cross-Verbrauch von Edge-Dienst-APIs in hybriden MEC-Umsetzungen von Edge-Plattformen (zum Beispiel konform mit beiden Standards) ermöglicht werden soll. Tatsächlich ist gemäß [MEC031] der Verbrauch/Aufruf von APIs in diesen Figuren außerhalb des Schutzumfangs und müsste separat angesprochen werden.
  • Schließlich zeigt eine Abbildung von CAPIF-APIs und MEC-Dienstmanagement-APIs, wie von Tabelle 2 gezeigt, dass nicht immer alle Funktionalitäten in den beiden Standards übereinstimmen. Insbesondere steht die Möglichkeit, Transportprotokolle (siehe zum Beispiel [MEC011]) zu entdecken, nicht zur Verfügung, wenn CAPIF-APIs-Dienstverbrauch betrachtet wird (siehe zum Beispiel die Ressource-URI „mec_service_mgmt/vl/transports“ und die eine Liste von MEC-TRANSPORTEN enthält). Tabelle 2
    MEC-Ressourcenname MEC-Ressourcen-URI CAPIF-Ressourcenname CAPIF-Ressourcen-URI
    Abrufen von Informationen über eine Liste von mecService-Ressourcen
    Eine Liste von mecService mec_service_mgmt/v1/service CAPIF_Discover_Service_API : Alle veröffentlichten Dienst-APIs /serviceapis/v1 /allServiceApi s
    Eine Liste von meService mec_service_mgmt/v1/service Alle veröffentlichten Dienst-APIs /service-apis/ v1/allServiceApis
    Abrufen von Informationen über eine mecService-Ressource
    individueller mecService mec_service_mgmt/v1/services /{serviceld} - (siehe Anmerkung) - (siehe Anmerkung)
    Individueller meService mec_service_mgmt/v1/servi ces/{serviceld} - -
    Abrufen von Informationen über die verfügbaren Transporte
    Eine Liste von mecTransport mec_service_mgmt/v1/transpor ts - (Teilsatz ist Teil von Dienst-API-Informationen) -
    Eine Liste von meTransport- mec_service_mgmt/v1/trans Ports - (Teilsatz ist Teil von Dienst-API-Informationen) -
    Abrufen von Informationen über eine Liste von mecService-Ressourcen einer Anwendungsinstanz
    Eine Liste von mecService einer Anwendungsinstanz mec_service_mgmt/v1/applicati ons/{appInstanceldj/services CAPIF_Publish_Service_API: APF-veröffentlichte APIs /publishedapis/v1/{apfld}/ service-apis
    Eine Liste von meService einer Anwendungsinstanz mec_service_mgmt/v1/applicati ons/{applnstanceld}/services APF-veröffentlichte APIs /publishedapis/v1/{apfld}/ service-apis
    Abrufen von Informationen über eine mecService-Ressource einer Anwendungsinstanz
    Individueller mecService einer Anwendungsinstanz mec_service_mgmt/v1/applicati ons/{applnstanceldj/services/{s erviceld} CAPIF_Publish_Service_API: Individuelle APF-veröffentlichte API /publishedapis/v1/{apfld}/ service-apis/{serviceApild}
    Individueller meService einer Anwendungsinstanz mec_service_mgmt/v1/applicati ons/{applnstanceld}/services/{s erviceld} Individuelle APF veröffentlicht API /publishedapis/v1/{apfld}/servic e-apis/{serviceApild}
    Abrufen von Informationen über eine Liste von mecSrvMgmtSubscription-Ressourcen für diesen Teilnehmer
    Eltern-Ressource aller mecSrvMgmtSubscri ption eines Teilnehmers mec_service_mgmt/v1/applicati ons/{applnstanceld}/subscriptio ns CAPIF_Events_API: CAPIF Event-Subskriptionen /capifevents/v1 /{subscriber Id}/ subscriptions/
    Eltern-Ressource aller meMp1 Subscription eines Teilnehmers mec_service_mgmt/v1/appli cations/{applnstanceld}/subscri ptions CAPIF Event-Subskriptionen /capifevents/v1 /{subs criberld}/subscription s/
    Abrufen von Informationen über eine mecSrvMgmtSubscri ption-Ressource für diesen Teilnehmer
    Individuelle mecSrvMgmtSubscri ption mec_service_mgmt/v1/applicati ons/{applnstanceld}/subscriptio ns/{subscriptionld} CAPIF_Events_API: Individuelle CAPIF-Events-Subskription /capifevents/v1/{subscriber Id}/ subscriptions/{subscri ptionld}
    Individuell meMp1 Subscription mec_service_mgmt/v1/applicati ons/{applnstanceld}/subscriptio ns/{subscriptionld} Individuelle CAPIF-Events Subskription /capifevents/v1/{subs criberld}/subscription s/{subscriptionld}
    HINWEIS: Obwohl in CAPIF für einzelne Dienste keine Ressource definiert ist, ist die Abfrage eines bestimmten Dienstes durch Verwenden geeigneter Filterparameter mit den CAPIF-APIs möglich.
  • Die vorliegende Offenbarung stellt einen interoperablen Mechanismus zur Cross-Aufdeckung von APIs für den Anwendungsverbrauch bereit. Dieser Mechanismus erlaubt auch die Verwendung unterschiedlicher Transportprotokolle und die Möglichkeit für MEC-Dienste 2436, ihr eigenes Protokoll zu der MEC-Plattform 2432 zu bringen. Darüber hinaus können in bestimmten Fällen (um zum Beispiel die Sicherheit zu verbessern) einige Erweiterungen für alternative Transportmechanismen in MEC vorgesehen sein (siehe zum Beispiel [MEC011]), und diese Erweiterungen würden von dem tatsächlich verwendeten Transport abhängen. Derartige Erweiterungen können zum Beispiel verwendet werden, um die notwendigen Parameter für den Client zu signalisieren, TLS-basierte Autorisierung zu verwenden, die für alternative Transporte definiert ist (siehe zum Beispiel [MEC009]). Dementsprechend kann es vorteilhaft sein, einen derartigen Cross-API-Verbrauch für Edge-Anwendungen zuzulassen. Schließlich kann, wie im vorhergehenden Abschnitt erläutert, der EES 2155 CAPIF-Funktionalität beinhalten und dann als die CCF 405 fungieren (siehe zum Beispiel Anhang A.4.3, [TS23558]); oder der EES 2155 auf deckt, wenn er eingesetzt wird, seine APIs der CCF 405 über den CAPIF-3-Referenzpunkt.
  • Die vorliegende Offenbarung betrachtet den Fall, dass EES 2155 und CCF 405 getrennte Entitäten sind, da sie im ersten Fall stattdessen in eine einzige Entität kollabieren würden. Die vorliegende Offenbarung betrachtet ein MEC-Szenario basierend auf Edge-Plattformen, die sowohl ETSI-MEC- als auch 3GPPSA6-Standards entsprechen, wobei die Plattform Funktionalitäten und APIs umsetzt, die den 2 jeweiligen Standards entsprechen. Wie aktiviert man von Edge-Anwendungen einen Dualmodus-Edge-APIs-Verbrauch von beiden Standards? Wie soll ein interoperabler Mechanismus bereitgestellt werden, der es der gleichen Anwendung (Onboarding entweder als MEC-App oder EAS 2150) ermöglichen kann, Edge-Dienst-APIs in einem derartigen hybriden Szenario zu verbrauchen, um von dem gesamten Portfolio von Funktionalitäten zu profitieren, die an der Edge von den Mehrfach-Edge-Computing-Technologien angeboten werden.
  • Das hierin eingeführte flexible Framework stellt die folgenden Technologiekomponenten bereit: die Definition eines edgeXapis-GW als eine Funktion, die interoperable und sichere Kommunikation über Attestierung ermöglicht und die Verbindung zwischen MEC und 3GPP-CAPIF unterstützt; Aufdeckung gegenüber Edge-Apps der vollen Liste von APIs sowohl der MEC- als auch der 3GPP-Systeme, mittels ordnungsgemäßer Signalisierung (unterstützt von der edgeXapis-GW-Funktion) CAPIF-Kernfunktion und der MEC-Plattform; interoperabler Edge-Dienstverbrauch von MEC und 3GPP, einschließlich APIs, die von beiden Systemen aufgedeckt werden; und Mechanismen, um für EASs 2150 auch alternative Transportprotokolle für den MEC-APIs Dienstverbrauch verfügbar zu machen.
  • Als eine allgemeine Annahme abstrahieren die Ausführungsformen hierin sowohl von der speziellen Anwendungsprogrammsprache als auch zum Beispiel von der Art der Virtualisierungstechnologie (zum Beispiel virtuelle Maschinen (VMs), Container usw.). Allgemein kann die Anwendung entweder monolithisch sein oder einen oder mehrere Mikrodienste umfassen. Zusätzlich sind Edge-Anwendungsinstanziierungsmechanismen in der ETSI-MEC in der [MEC010-2] lieferbar und in [MEC(20)000390r1] definiert.
  • Die vorliegende Offenbarung stellt eine „Anlagenschicht“ für API-Cross-Aufdeckung zwischen vertrauenswürdiger 3GPP-Domäne und externen MEC-Systemen bereit und kann als eine CCF 405 Erweiterung/Verbesserung angesehen werden, die von einem Gateway zwischen den zwei Plattformen (und den zugehörigen Sätzen von APIs) unterstützt wird, um eine Edge-Dienstaufdeckung zwischen der Plattform und dem daraus folgenden Verbrauch autorisierter Anwendungen zu erlauben.
  • Die Ausführungsformen hierin können als Teil der CCF 405 in 3GPP-Systemen umgesetzt werden, sie können aber auch eine Softwarefunktionalität als Verbesserung (SW-Update) gegenwärtiger Umsetzungen der CCF 405 sein. Die Ausführungsformen beinhalten Mittel zum Signalisieren der Notwendigkeit, eine Beziehung zwischen dem MEC-System und dem 3GPP-CAPIF herzustellen (zum Beispiel über den CAPIF-3e-Referenzpunkt). Die übermittelten Zusatzinformationen sind in den von MEC an das CAPIF bereitgestellten Transportprotokollinformationen enthalten. Ausführungsbeispiele beinhalten auch für die im letzten Abschnitt der vorliegenden Ausführungsformen beschriebene Kommunikation relevante Nachrichtenfolgen und Datenstrukturen.
  • Unter Bezugnahme auf 6 involvieren die Ausführungsformen hierin zwei Szenarien und zielen darauf ab, den Cross-Verbrauch von Edge-Dienst-APIs in hybriden Umsetzungen von Edge-Plattformen (zum Beispiel konform mit mehreren Standards) zu ermöglichen, zum Beispiel (1) Edge-Apps, die in dem ETSI-MEC-System 2400 registriert sind, und APIs von sowohl der ETSI-MEC-Plattform 2432 (zum Beispiel MEC-API(s) 630) als auch 3GPP-APIs (zum Beispiel APIs 620 zum Bereitstellen von 3GPP-Kerndiensten für EASs 2150); und (2) Edge-Apps, die in dem EDGEAPP-System registriert sind, und Verbrauchen von APIs sowohl von der ETSI-MEC-Plattform 2432 (zum Beispiel MEC-API(s) 630) als auch von 3GPP-APIs (zum Beispiel APIs 620 zum Bereitstellen von 3GPP-Kerndiensten für EAS 2150s). Eine Basisannahme betrachtet MEC-Apps 2426 und den EAS 2150 als ähnliche Entitäten und im Rest des vorliegenden Dokuments wird jedes dieser Elemente als „Edge-Apps“ oder dergleichen bezeichnet. Wie bereits erläutert, kann in beiden Fällen die tatsächliche Umsetzung der Anwendung gleich sein. Der einzige Unterschied besteht darin, dass dieselbe Anwendungsinstanz entweder als 3GPP-Anwendung oder als ETSI-Anwendung registriert wird. Bei einigen Umsetzungen werden diese Anwendungen Mp1 verwenden, um ETSI-MEC-APIs zu verbrauchen, und EDGE-3 verwenden, um 3GPP-APIs zu verbrauchen.
  • 1.4. AUSFÜHRUNGSFORM 1
  • Eine erste Ausführungsform ist auf MEC-Systeme 2400 anwendbar, die mit 3GPP-Systemen 2900 verbunden sind, oder in allgemeinen Fällen, in denen sich ein Edge-Computing-System außerhalb der PLMN-Vertrauensdomäne 420 befindet. Dieses Szenario kann insbesondere auch in MEC-Verbanden nützlich sein, wie unten erörtert und in [ETSIWP36] beschrieben ist, wo unterschiedliche Stakeholder (zum Beispiel MNOs, Hyperskalierer und Drittparteien) möglicherweise ihre Edge-Dienste zusammenlegen und einander aufdecken müssen.
  • 7a zeigt eine Architektur 700a gemäß der ersten Ausführungsform und 7b zeigt eine Architektur 700b gemäß der ersten Ausführungsform. Die Architekturen 700a-700b beinhalten mehrere Enabler und Betriebsschritte. In Architektur 700a befindet sich die edgeXapis-GW-Funktion 710 in der CCF 405, während in Architektur 700b die edgeXapis-GW-Funktion 710 von der CCF 405 getrennt ist. Der spezifische Einsatz kann umsetzungsspezifisch sein. In beiden Architekturen 700a und 700b ist der edgeXapis 710 ein Funktionsblock für das Verwalten der Interoperabilität mit dem ETSI-MEC-System als ein Edge-Computing-System außerhalb der PLMN-Vertrauensdomäne 420 zuständig.
  • Bei Schritt 0 findet eine Verbindung zwischen MEC und CAPIF statt, die von dem edgeXapis-GW 710 als eine Unterstützungsfunktion unterstützt wird, die eine interoperable und sichere Kommunikation über eine Attestierung ermöglicht. Wenn die MEC-Plattform 2432 mit der CCF 405 verbunden wird, sollte sich die MEC-Plattform 2432 der CCF 405 bewusst sein und in ihrer Konfiguration die Root-URL der CCF 405 beinhalten. Ebenso kann die CCF 405 über CAPIF-3e mit der MEC-Plattform 2432 verbunden sein und über HTPP die Anforderungen empfangen, die von der MEC-Plattform 2432 kommen. Bei einigen Umsetzungen ist die CCF 405 ein HTTP-Server und dementsprechend kann sich ein beliebiger HTTP-Client, der eine Sicherheitsauthentifizierung bereitstellt, mit der CCF 405 verbinden.
  • Bei Schritt 0 wird eine Verbindung zwischen der MEC-Plattform 2432 und der CCF ausgeführt und hergestellt, einschließlich Autorisierung und Authentifizierung über den CAPIF-3e-Referenzpunkt. Die edgeXapis-GW-Funktion 710 stellt die benötigten Attestierungsmittel bereit, um Sicherheit für Autorisierung und Authentifizierung und Nutzung der Fähigkeiten der MEC-Plattform 2432 in der 3GPP-Domäne (und umgekehrt) sicherzustellen. Dieser Schritt involviert vorläufig die Kommunikation der MEC-Plattform 2432 und CCF 405 über CAPIF-3e und auch die edgeXapis-GW-Funktion 710 zur Sicherheitsattestierung (siehe zum Beispiel 8). Bei diesem Schritt sendet die MEC-Plattform 2432 zu der CCF 405 eine Liste von APIs, die von der MEC CAPIF aufgedeckt werden. In der 3GPP-Terminologie agiert die MEC-Plattform 2432 als CAPIF-AEF 401.
  • 8 zeigt eine beispielhafte Authentifizierung mit Attestierungsvorgehensweisen, die für die MEC-Plattform 2432 verwendet werden können, mit zwei Optionen, einschließlich OAuth2 + Attestierung 801 und/oder Transportschichtsicherheit (Transport Layer Security - TLS) + Explicit Attestierung 802. Bei beiden Optionen agiert das edgeXapis-GW 710 (siehe zum Beispiel 7) als ein Verifizierer (zum Beispiel der Verifizierungsteil des AS + Verifizierers 812 der 8), zur Unterstützung der CCF 405 (zum Beispiel der AS-Teil des AS + Verifizierers 812 der 8).
  • Bei der OAuth2 + Attestierung 801 stellt der Client + Attester 811 Authentifizierungs- + Attestierungsinformationen an den AS + Verifizierer 812 bereit, und der AS + Verifizierer 812 stellt dem Client + Attester 811 ein Token bereit. Der Client + Attester 811 stellt das Token zu dem Server (vertrauende Partei) 813 bereit. Auch zwischen dem AS + Verifizieren 812 und dem Server (vertrauende Partei) 813 wird ein Vertrauensanker eingerichtet. Zusätzliche Aspekte des OAuth2 + Attestierungs-Prozessen 801 sind in Hardt, „The Oauth 2.0 Authorization Framework“, IETF RFC 6749 (Oktober 2012) besprochen.
  • In TLS + Explicit Attestierung 802 sendet der AS + Verifizierer 812 eine Client-Hello-Anforderungsnachricht mit einer Attestierungsanforderung an den Client-Attester 811, und der Client-Attester 811 stellt dem AS + Verifizierer 812 eine Client-Hello-Nachricht mit Attestierungsnachweis bereit. Der AS + Verifizierer 812 sendet eine Server-Hallo-Nachricht mit Attestierungsergebnissen zu dem Client + Attester 811 und richtet eine TLS-Sitzung mit dem Client + Attester 811 ein. Der Client + Attester 811 ruft dann einen API-Aufruf auf, der an den AS + Verifier 812 und an den Server (vertrauende Partei) 813 weitergeleitet wird.
  • In 8 entspricht die MEC-Plattform 2432 (agiert als AEF 401 und kommuniziert über CAPIF-3e) dem Client + Attester 811, und das edgeXapis-GW 710 stellt Attestierung zur Unterstützung der Legacy-CCF 405 Authentifizierungs- und Autorisierungsfunktionalitäten bereit (wie von [TS33122], Klausel 4.6 gefordert). Derzeit gibt 3GPP nur an, wie Nachrichten oder Zertifikate für den CAPIF-3e-Referenzpunkt gesichert werden sollen. Zum Beispiel kann gemäß [TS33122] Sicherheit der Schnittstellen zwischen CAPIF-Entitäten zwischen unterschiedlichen vertrauenswürdigen Domänen (zum Beispiel CCF 405-Domäne und API-Anbieter-Domäne), nämlich CAPIF-3e, CAPIF-4e und CAPIF-5e, sicherzustellen, 3GPP TS 33.210 v16.4.0 (2020-07-10) („[TS33210]“) auf sichere Nachrichten auf den anderswie spezifizierten Referenzpunkten angewandt werden; und 3GPP TS 33.310 v16.6.0 (2020-12-16) kann hinsichtlich der Verwendung von Zertifikaten mit den Sicherheitsmechanismen von [TS33210] angewandt werden. Es gibt jedoch keine Angabe, wie Authentifizierungs- und Autorisierungsfunktionalitäten mit Attestierung zu verwalten sind, und die edgeXapis-GW-Funktion 710 übernimmt hier die Rolle.
  • Nach Authentifizierung und Autorisierung (verstärkt durch Attestierung) weist die CCF 405 nun eine zusätzliche Liste von APIs auf, die von der MEC-Plattform 2432 kommend angezeigt werden können. Die vollständige Liste in der CCF 405 beinhaltet sowohl APIs des EES 2155 als auch APIs der MEC-Plattform 2432. Eine Sicherheitsattestierung der MEC-APIkann auch mittels ordnungsgemäßer Kommunikation mit der edgeXapis-GW-Funktion 710 gewährleistet werden.
  • Unter Rückkehr zu den 7a-7b beinhaltet Schritt 1 Aufdeckung der ETSI-MEC-Dienst-APIs 630 gegenüber EASs 2150 in 3GPP über die CCF 405. Wenn ein EAS 2150 gestartet wird, fragt er die CCF 405 als einen API-Aufrufer 410 ab, um die aufgedeckte API zu erhalten. Dank des vorhergehenden Schritts 0 empfängt der EAS 2150 eine Liste von APIs, die der CCF 405 bekannt sind, einschließlich sowohl der APIs des EES 2155 als auch der MEC-Plattform 2432. Außerdem aktualisiert die edgeXapis-GW-Funktion 710 bei diesem Schritt eine Liste von EASs 2150, die auf einige oder alle der API-liste zugreifen. Diese EASs 2150 werden autorisiert, MEC-Dienst-API zu verbrauchen, und dann wird eine Liste dieser EASs 2150 über CAPIF-3e an die MEC-Plattform 2432 gesendet.
  • Die Schritte 2a und 2b beinhalten einen interoperablen Edge-Dienstverbrauch von MEC und 3GPP. Der EAS 2150 kann nun eine beliebige bekannt gemachte API aufrufen, entweder als eine API des EES 2155 (zum Beispiel Schritt 2a in 7a-7b) oder eine beliebige bekannt gemachte MEC-Plattform 2432 API (zum Beispiel Schritt 2b in 7a-7b).
  • Im Fall von Schritt 2a wird angenommen, dass der EAS 2150 von dem EES 2155 autorisiert wurde, EES 2155-Dienste zu verwenden. Im Fall von 2b wird angenommen, dass der EAS 2150 bei Schritt 1 von der MEC-Plattform 2432 autorisiert wurde, MEC-Dienste zu verwenden. Der EAS 2150 ist ein API-Aufrufer 410, sollte aber auch von der MEC-Plattform 2432 als autorisierter Verbraucher der MEC-Dienst-API gesehen werden. Die Liste autorisierter EASs 2150 ist in der edgeXapis-GW-Funktion 710 enthalten und wird über das CAPIF-3e zu der MEC-Plattform 2432 kommuniziert. Getrenntes Edge-App-Onboarding (zu EES 2155 oder zu MEC-Plattform 2432) kann verwendet werden. Zusätzlich oder alternativ ist ein duales Onboarding zu den EES 2155 und der MEC-Plattform 2432 möglich. Darüber hinaus kann die Kommunikation bei Schritt 2b RESTful-Nachrichten zum Dialog mit der MEC-Plattform 2432 verwenden (Transportentdeckungsfunktion 720).
  • Schritt 3 beinhaltet einen Mechanismus, um EASs 2150 auch alternative Transportprotokolle für den Dienstverbrauch MEC-APIs zur Verfügung zu stellen. CAPIF unterstützt gegenwärtig die Aufdeckung von API entweder unter Verwenden von HTTP V1. 1 oder HTTP V2.0, unterstützt aber keine anderen Transporte. Die MEC-Plattform 2432 unterstützt jedoch einen größeren Satz von Transporten, aber es gibt keine Möglichkeit, sie über CAPIF aufzudecken. Um sich APIs unter Verwenden anderer Protokolle bewusst zu sein, muss der EAS 2150 (oder die MEC-App 2426) den Transportentdeckungsdienst der MEC-Plattform 2432 verwenden. Dazu deckt die MEC-Plattform 2432 die Transport-Discovery-API als RESTful-API (Schritt 2b) auf. Dadurch wird die Transport-Discovery-API von der MEC-Plattform 2432 als Teil der zuvor beschriebenen API-Aufdeckung aufgedeckt(Schritt 0) und von der EAS 2150 (oder MEC-Anwendung) aufgedeckt (Schritt 1).
  • Um APIs unter Verwenden unterschiedlicher Transporte zu erhalten (Schritt 3), erhält die EAS 2150 (oder MEC-App 2426) die APIs, die unterschiedliche Transporte unterstützen, von dem Transport-Discovery-Service (Schritt 3). Von nun an kann die Kommunikation, die über Mp1 ausgeführt wird, unterschiedliche Transportprotokolle, wie von der ausgewählten API definiert, verwenden. Bei diesem Schritt erreicht der EAS 2150 als ein API-Aufrufer 410 und auch als ein autorisierter MEC-API-Dienstverbraucher die MEC-Plattform 2432 unter Verwenden einer Mp1-Schnittstelle (zum Beispiel MEC-Dienstverwaltungs-API), um verfügbare Transportprotokolle zu entdecken (dieser Schritt erfolgt durch Befolgen des [MEC011]-Standards, die schließlich einige ETSI-MEC-Verbesserungen in der MEC-Plattform 2432 beinhalten kann, da die Edge-App möglicherweise keine „reine“ MEC-App 2426 ist, sondern stattdessen als EAS 2150 registriert ist).
  • Nach den Schritten 0 bis 3 kann die Edge-App die MEC-Dienste 2436 unter Verwenden der Mp1-Schnittstelle (zum Beispiel MEC-Anwendungsunterstützungs-API) und auch unter Verwenden des spezifischen Transports, der von diesem spezifischen Dienst zur Verfügung gestellt wird, verbrauchen (dieser Schritt erfolgt durch Befolgen des [MEC011] -Standards, die schließlich einige ETSI-MEC-Verbesserungen in der MEC-Plattform 2432 beinhalten können, da die Edge-App möglicherweise keine „reine“ MEC-App 2426 ist, sondern stattdessen als EAS 2150 registriert ist).
  • 1.5. AUSFÜHRUNGSFORM 2
  • Eine zweite Ausführungsform involviert Verbessern der CAPIF und Verbessern der ersten Ausführungsform, um zusätzliche Transportinformationen bereitzustellen. Bei dieser Ausführungsform werden alle Schritte wie bei Ausführungsform 1 ausgeführt, mit dem Unterschied, dass Schritt 0 wie folgt verbessert wird: Bei Schritt 0 richten der EES 2155 und MEC-Plattformen 2432 vorab durch das edgeXapis-GW 710 als eine Funktion aus, die eine Interoperabilität zwischen CAPIF und MEC ermöglicht und zusätzliche Transporte in der CCF 405 unterstützt.
  • Das edgeXapis-GW 710 weist eine zusätzliche Rolle in einer Vorausrichtungsphase zwischen EES 2155 und MEC-Plattform 2432 auf, wo die Liste verfügbarer Transporte aufgedeckt und zentralisiert an das edgeXapis-GW 710 übertragen wird, um Transporte von allen verfügbaren API-Aufdeckungsfunktionen zu allen möglichen API-Aufrufern 410 besser zu verwalten.
  • Bei dieser Ausführungsform, die sich mit den anderen hierin besprochenen Ausführungsformen nicht gegenseitig ausschließt, wird das CAPIF verbessert, um die Transportinformationen als Teil der API-Ankündigung zu unterstützen. Hier beinhaltet das CAPIF die Fähigkeit, Transportinformationen von der MEC-Plattform 2432 zu empfangen, wenn die MEC-Plattform 2432 (die als eine AEF 401 agiert) die APIs der CCF 405 bei Schritt 0 aufgedeckt. Zusätzlich oder alternativ weist die CCF 405 die Fähigkeit auf, dem Transport von der MEC-Plattform 2432 Info zu dem API-Aufrufer 410 bereitzustellen, wenn der API-Aufrufer 410 APIs bei Schritt 1 entdeckt.
  • Um diese neue Funktionalität zu unterstützen, beinhalten einige Umsetzungen ein zusätzliches Informationselement (IE), um diese neuen Informationen zu unterstützen. Ziffer 8.2.4.1 von [TS29222] spezifiziert das Anwendungsdatenmodell, das von der CAPIF_Publish_Service_API unterstützt wird (für diese API gelten auch Datentypen, die in Ziffer 7.2 von [TS29222] aufgeführt sind). Tabelle 8.2.4.1-1 in Ziffer 8.2.4.1 von [TS29222] gibt die spezifisch für den CAPIF_Publish_Service_API-Dienst definierten Datentypen an und definiert die Datenelemente, die von der AEF 401 bereitgestellt werden. Bei dieser Ausführungsform wird ein neues Datenelement „TransportName“ hinzugefügt, um die Aufdeckung von APIs unter Verwenden unterschiedlicher Transporte zu unterstützen, wie in Tabelle 3 gezeigt ist. Tabelle 3: CAPIF _Publish _Service_API-spezifische Datentypen
    Datentyp [TS29222] Abschnitt definiert Beschreibung Anwendbarkeit
    AefProfile Ziffer 8.2.4.2.4 AEF-PROFIL
    Kommunikationstyp Ziffer 8.2.4.3.5 Kommunikationstyp der Ressource
    CustomOperation Ziffer 8.2.4.2.7 Customisierter Betrieb
    DataFormat Ziffer 8.2.4.3.4 Datenformat
    InterfaceDescription Ziffer 8.2.4.2.3 Beschreibung der API-Schnittstelle
    Betrieb Ziffer 8.2.4.3.7 HTTP-Verfahren (zum Beispiel PUT)
    Protokoll Ziffer 8.2.4.3.3 Von der API verwendetes Protokoll
    PublishedApiPath Ziffer 8.2.4.2.9 Veröffentlichter API-Pfad innerhalb derselben CAPIF-Anbieterdomäne.
    Ressource Ziffer 8.2.4.2.6 API-Ressource
    SecurityMethod Ziffer 8.2.4.3.6 Sicherheitsverfahren (zum Beispiel PKI)
    ServiceAPIDescription Ziffer 8.2.4.2.2 Beschreibung einer Dienstleistungs-API, wie von der APF veröffentlicht.
    Shareablelnformation Ziffer 8.2.4.2.8 Informationen darüber, ob eine Dienst-API und/oder eine Dienst-API-kategorie zu anderen CCFs veröffentlicht werden kann.
    Version Ziffer 8.2.4.2.5 API-Versionsinformation
    TransportName Neues Element Der Name des mit dieser API assoziierten Transports
  • Die CAPIF veröffentlichen Dienst-APIs, wie in [TS23222] definiert, erlauben es der APF 402, veröffentlichte Dienst-APIs an der CCF 405 über die CAPIF-4- und CAPIF-4e-Referenzpunkte zu veröffentlichen und zu verwalten, und erlauben es der CCF 405, veröffentlichte Dienst-APIs an anderen CCFs 405 über die CAPIF-6- und CAPIF-5e-Referenzpunkte zu veröffentlichen und zu verwalten. Verbraucher und/oder Initiatoren der CAPIF_Publish_Service_API beinhalten die APF 402 und die CCF 405. Die für die CAPIF _Publish_Service API definierten Dienstoperationen sind in Tabelle 4 gezeigt. Tabelle 4: Operationen der CAPIF _Publish _Service API
    Dienstoperationsname Beschreibung [TS29222] Abschnitt definiert
    Publish_Service_API Diese Dienstoperation wird von einer API-Veröffentlichungsfunktion verwendet, um Dienst-APIs auf der CAPIF-Kernfunktion zu veröffentlichen. Diese Dienstoperation wird auch von der CAPIF-Kernfunktion verwendet, um Dienst-APIs auf einer anderen CAPIF-Kernfunktion zu veröffentlichen. 5.3.2.2
    Unpublish_Service_API Diese Dienstoperation wird von einer API-Veröffentlichungsfunktion verwendet, um Dienst-APIs von der CAPIF-Kernfunktion aufzuheben. Diese Dienstoperation wird auch von der CAPIF-Kernfunktion verwendet, um Dienst-APIs auf einer anderen CAPIF-Kernfunktion aufzuheben. 5.3.2.3
    Get_Service_API Diese Dienstoperation wird von einer API-Veröffentlichungsfunktion verwendet, um Dienst-APIs aus der CAPIF-Kernfunktion abzurufen. Diese Dienstoperation wird auch von der CAPIF-Kernfunktion verwendet, um Dienst-APIs auf einer anderen CAPIF-Kernfunktion abzurufen. 5.3.2.4
    Update_Service_API Diese Dienstoperation wird von einer API-Veröffentlichungsfunktion verwendet, um veröffentlichte Dienst-APIs auf der CAPIF-Kernfunktion zu aktualisieren. Diese Dienstoperation wird auch von der CAPIF-Kernfunktion verwendet, um veröffentlichten Dienst-APIs auf einer anderen CAPIF-Kernfunktion zu aktualisieren. 5.3.2.5
  • Die Anfrage-URIs, die in HTTP-Anfragen von der APF 402 zu der CCF 405 verwendet werden, weisen folgende Ressource-URI-Struktur auf: {apiRoot}/publishedapis/v1/<apiSpecificSuffixes> wobei die <apiSpecificSuffixes> wie in der Ziffer 8.2.2 von [TS29222]) beschrieben sind. Tabelle 5 gibt einen Überblick über die Ressourcen und anwendbaren HTTP-Verfahren. Das „apiRoot“ wird durch Mittel außerhalb des Schutzumfangs der vorliegenden Offenbarung konfiguriert und beinhaltet das Schema („https“), Host und optionalen Port sowie eine optionale Präfix-Zeichenfolge. Eine unterschiedliche Wurzelstruktur kann verwendet werden, wenn der Ressource-URI in der API-aufrufenden Instanz 410 vorkonfiguriert ist. Tabelle 5: Übersicht über Ressourcen und Verfahren
    Ressourcenname Ressourcen-URI HTTP Verfahren oder kundenspezifische Operation Beschreibung
    APF-veröffentlichte APIs /{apfld}/service-apis POST Neue API veröffentlichen
    GET Abrufen aller veröffentlichten Dienst-APIs
    Individuelle APF-veröffentlichte API /{apfld}/service-apis/{serviceApild} GET Abrufen einer veröffentlichten Dienst-API
    PUT Veröffentlichte Dienst-API aktualisieren
    DELETE veröffentlichten Dienst-API aufheben
  • Die APF-veröffentlichte APIs-Ressource stellt alle veröffentlichten Dienst-APIs einer API-Veröffentlichungsfunktion dar. Die Ressource-URI {apiRoot}/publishedapis/<apiVersion>/{apfld}/service-apis. Die apfId identifiziert die APF 402. Für CAPIF-Interconnect-Fälle identifiziert diese Zeichenfolge auch die CCF 405, die die Dienst-API veröffentlicht.
  • Zusätzlich spezifiziert Ziffer 8.1.4 von [TS29222] das Anwendungsdatenmodell, das von der CAPIF_Discover_Service_API unterstützt wird (Datentypen, die in Ziffer 7.2 von [TS29222] aufgelistet sind, gelten auch für diese API), und Ziffer 8.1.4.2.2 von [TS29222] spezifiziert die Definition der Dienst-API „DiscoveredAPIs“. Der DiscoveredAPIs-Typ beinhaltet das Attribut serviceAPIDescriptions, das den Datentyp beinhaltet: „Array(ServiceAPIDescription)“, das eine Beschreibung der Dienst-API, wie von dem Dienst veröffentlicht, bereitstellt. Für die CAPIF_Discover_Service_API werden die supportedFeatures-Attribute des ServiceAPIDescription-Datentyps in der HTTP-GET-Antwort einer erfolgreichen Abfrage bereitgestellt. Zusätzlich kann das supportedFeatures-Attribut ein oder mehrere unterstützte(s) Merkmal(e) beinhalten, wie in Ziffer 8.1.6 von [TS29222] definiert. Das supportedFeatures-Attribut kann das Merkmal „ApiSupportedFeatureQuery“ beinhalten, das die Unterstützung des Abfragefilters angibt, das/die unterstützte(n) Merkmal(e) einer Dienst-API angibt. Darüber hinaus definiert Tabelle 8.1.2.2.3.1-1 in Ziffer 8.1.2.2.3.1 von [TS29222] die Datenelemente, die von der CCF 405 zu API-Aufrufern 410 als Teil der API-Entdeckung (CAPIF _Discover_Service_API) bereitgestellt werden. Bei dieser Ausführungsform wird ein neues Datenelement, „Transportname“, hinzugefügt, um die Entdeckung von APIs unter Verwenden unterschiedlicher Transporte, wie in Tabelle 6 gezeigt, zu unterstützen. Tabelle 6: Auf dieser Ressource von dem GET-Verfahren unterstützte URI-Abfrageparameter
    Name Datentyp P Kardinalitä t Beschreibung Anwendbark eit
    api-invoker-id Zeichenfolge M 1 Eine Zeichenfolge, die den API-Aufrufer 410 identifiziert, der von der CAPIF-Kernfunktion zugewiesen wird. Sie stellt auch die CCF-Kennung im CAPIF-6/6e-Referenzpunkt dar.
    api-name Zeichenfolge O 0..1 Enthält den API-Namen als {apiName}-Teil der URI-Struktur, wie in Ziffer 4.4 von 3GPP TS 29.501 definiert.
    api-version Zeichenfolge O 0..1 Enthält die API-Hauptversion, die in dem URI (zum Beispiel v1) übermittelt wird.
    comm-type Kommunikationstyp O 0..1 Kommunikationstyp, der von der API verwendet wird (zum Beispiel REQUEST RESPONSE).
    protocol Protokoll O 0..1 Protokoll, das von der API verwendet wird.
    af-id Zeichenfolge O 0..1 AEF identifier.
    Datenformat DataFormat O 0..1 Datenformat, das von der API verwendet wird (zum Beispiel Serialisierungsprotokoll JSON).
    api-cat Zeichenfolge O 0..1 die Dienst-API-Kategorie, zu der die Dienst-API gehört.
    Unterstützte Merkmale SupportedFeatures O 0..1 Zum Filtern irrelevanter Antworten im Zusammenhang mit nicht unterstützten Merkmalen.
    api-supportedfeatures SupportedFeatures C 0..1 Merkmale, die von der entdeckten Dienst-API unterstützt werden, die mit API-Namenparameter angegeben werden. Dies darf nur dann vorliegen, falls der API-Namen-Abfraqeparameter vorliegt. ApiSupported FeatureQuery
    transport-name Zeichenfolge O 0..1 Der Name des mit dieser API assoziierten Transports
  • Die CAPIF-Entdeckungsdienst-APIs, wie in [TS23222] definiert, erlauben es API-Aufrufern 410, einen oder mehrere Dienst-API(s), die an der CCF 405 verfügbar sind, über die CAPIF-1/1e-Referenzpunkte zu entdecken, und erlauben es der CCF 405, eine oder mehrere Dienst-API(s), die an anderen CCFs 405 verfügbar sind, über die CAPIF-6- und CAPIF-6e-Referenzpunkte zu entdecken. Zu Verbrauchern des CAPIF_Discover_Service_API-Diensts gehören der API-Aufrufer 410 und die CCF 405. Um Dienst-APIs, die an der CCF 405 verfügbar sind, zu entdecken, sendet der Verbraucher (zum Beispiel API-Aufrufer 410) eine HTTP-GET-Nachricht mit der API-Aufrufer-ID oder CCF-ID sowie Abfrageparametern an die CCF 405, wie in Ziffer 8.1.2.2.3.1 von [TS29222] spezifiziert.
  • Beim Empfangen der oben erwähnten HTTP-GET-Nachricht verifiziert die CCF 405 die Identität des Verbrauchers (zum Beispiel API-Aufrufer 410) und prüft, ob der Verbraucher autorisiert ist, die Dienst-APIs zu entdecken. Wenn der Verbraucher autorisiert ist, die Dienst APIs zu entdecken, durchsucht die CCF 405 die CCF 405 (API-Register) nach APIs, die mit den Abfragekriterien übereinstimmen; wendet die Entdeckungsstrategie, falls vorhanden, auf den Suchergebnissen an und filtert die Suchergebnisse, um die Liste der Dienst-API-Beschreibung oder die Informationen der CCF 405 zu erhalten, die zum Auffinden der Dienst-API weiter kontaktiert werden müssen; und sendet die gefilterten Suchergebnisse oder die Informationen der CCF 405 in der Antwortnachricht zurück. Bei einigen Umsetzungen wird die shareablelnformation für jeden von serviceAPIDescription nicht in den gefilterten Suchergebnissen bereitgestellt.
  • 1.6. AUSFÜHRUNGSFORM 3
  • 7c stellt die Architektur 700c gemäß einer dritten Ausführungsform dar, die die erste und die zweite Ausführungsform verbessert. Bei der dritten Ausführungsform können die MEC-Apps 2426 3GPP-Dienste verbrauchen, indem sie von den zuvor beschriebenen Mechanismen und der unterstützenden Rolle der edgeXapis-GW-Funktion 710 beim Sichern der Kommunikation zwischen der MEC-Plattform 2432 und dem 3GPP-EES 2155 profitieren.
  • Dieser Dienstverbrauch wird ermöglicht, indem ein vorläufiger Informationsaustausch bei Schritt 0 in 7c zwischen der CCF 405 und der MEC-Plattform 2432 vorgesehen wird, so dass die MEC-Plattform 2432 in dem Dienstregister eine vollständige Liste von Diensten darstellt, die bei Schritt 2b in 7c verfügbar sind. Dieser Schritt nimmt auch an, dass bei den vorhergehenden Ausrichtungsschritten der EES 2155 die MEC-App 2426 bereits als autorisierten API-Aufrufer 410 betrachtet. Dann kann die MEC-App 2426 die APIs, die von dem EES 2155 freigelegt werden, verbrauchen, wie bei Schritt 3 in 7c abgebildet.
  • 1.7.ATTESTIERUNGS- UND SICHERHEITSASPEKTE
  • 9 zeigt ein Layout eines Attestierungsobjekts 900, das die enthaltenen Authenticator-Daten 901 (die attestierte Berechtigungsnachweisinformationen enthalten) und eine Attestierungsaussage 902 veranschaulicht. Allgemein ist die Attestierung eine Aussage, die dazu dient, zu bezeugen, zu bestätigen oder zu authentifizieren. In dem Web-Authentifizierungskontext (WebAuthn-Kontext) wird eine Attestierung eingesetzt, um die Herkunft eines Authenticators und der Daten, die er ausgibt, zu attestieren; einschließlich zum Beispiel von Berechtigungsnachweis-IDs, Berechtigungsnachweisschlüsselpaaren, Signaturzählern usw. Ein Berechtigungsnachweis ist Daten, die eine Instanz einer anderen präsentieren, um Ersteres gegenüber Letzterem zu authentifizieren. Eine Berechtigungsnachweis-ID ist eine probabilistisch eindeutige Bytefolge, die eine Berechtigungsnachweis-Quelle mit öffentlichem Schlüssel und ihre Authentifizierungsaussagen identifiziert, und ein Berechtigungsnachweisschlüsselpaar ist ein Paar asymmetrischer kryptographischer Schlüssel, das von einem Authenticator erzeugt wird und an eine spezifische WebAuthn-vertrauende Partei gerichtet sind. Ein Berechtigungsnachweisschlüsselpaar ist ein Teil eines Berechtigungsnachweises mit öffentlichem Schlüssel (oder „öffentlicher Berechtigungsnachweisschlüssel“). Der Begriff Berechtigungsnachweise mit öffentlichen Schlüssel verweist auf eine Quelle eines Berechtigungsnachweises mit öffentlichem Schlüssel, wobei der Berechtigungsnachweis mit öffentlichem Schlüssel, der möglicherweise attestiert ist, dem Berechtigungsnachweis mit öffentlichem Schlüssel entspricht, oder eine Authentifizierungsaussage. Ein privater Berechtigungsnachweisschlüssel ist der der private Schlüsselteil eines Berechtigungsnachweisschlüsselpaars; ein privater Berechtigungsnachweisschlüssel ist an einen bestimmten Authenticator (seinen verwaltenden Authenticator) gebunden, und es wird erwartet, dass er niemals einer anderen Partei ausgesetzt ist, nicht einmal dem Eigentümer/Betreiber des Authenticators. In einem Attestierungsobjekt 900 wird während der Registrierung eine Attestierungsaussage 902 übermittelt (siehe zum Beispiel § 6.5 Attestation in „Web Authentication: An API for accessing Public Key Credentials Level 2“, Web Authentication Working Group W3C Recommendation, (8. Apr. 2021), erhältlich bei: https://www.w3.org/TR/webauthn-2/ („[W3CWebAuthn]“)).
  • Ein Authenticator ist eine kryptographische Entität, die in Hardware und/oder Software existiert, die einen Benutzer bei einer gegebenen vertrauenswürdigen Partei registrieren und später den Besitz des registrierten öffentlichen Schlüssels bestätigen kann und optional den Benutzer verifizieren kann, wenn er von der vertrauenden Partei angefordert wird. Authenticators können Informationen über ihre Art und Sicherheitsmerkmale über eine Attestierung während der Registrierung melden. Die vertrauende Partei ist eine Entität, deren Anwendung (zum Beispiel eine Web-App und/oder dergleichen) einen Authentifizierungsmechanismus (zum Beispiel die in [W3CWebAuthn] erwartete WEB-Authentifizierungs-API und/oder die hier besprochenen Oauth-Mechanismen und/oder TLS-Mechanismen) nutzt, um Benutzer zu registrieren und zu authentifizieren. Jeder Authenticator weist eine AAGUID auf, die eine 128-Bit-Kennung ist, die den Typ (zum Beispiel Fabrikat und Modell) des Authenticator angibt. Ob oder wie der Client (zum Beispiel Authenticator) die Attestierungsanweisung 902 und die AAGUID-Teile des Attestierungsobjekts 900 an die vertrauende Partei übermittelt, wird von Attestierungsübermittlung beschrieben.
  • Authenticators sollten nach Möglichkeit irgendeine Form von Attestierung bereitstellen. Falls ein Authenticator dies tut, ist die grundlegende Anforderung, dass der Authenticator für jeden öffentlichen Berechtigungsnachweisschlüssel eine Attestierungsaussage 902 erzeugen kann, die von der WebAuthn-vertrauenden Partei verifizierbar ist. Typischerweise enthält diese Attestierungsaussage 902 eine Signatur durch einen privaten Attestierungsschlüssel über den attestierten öffentlichen Berechtigungsnachweisschlüssel und eine Herausforderung sowie ein Zertifikat (zum Beispiel X.509-Zertifikat) oder ähnliche Daten, die Herkunftsinformationen für den öffentlichen Attestierungsschlüssel bereitstellen, wodurch es der vertrauenden Partei ermöglicht wird, eine Vertrauensentscheidung zu treffen. Falls jedoch kein Attestierungsschlüsselpaar verfügbar ist, kann der Authenticator entweder eine Selbstattestierung des öffentlichen Berechtigungsnachweisschlüssels mit dem entsprechenden privaten Berechtigungsnachweisschlüssel ausführen oder ansonsten keine Attestierung ausführen. All diese Informationen werden von Authenticators jedes Mal zurückgegeben, wenn ein neuer öffentlicher Berechtigungsnachweis mit öffentlichem Schlüssel erzeugt wird, in der Gesamtform eines Attestierungsobjekts. Die Beziehung des Attestierungsobjekts 900 mit Authenticator-Daten 901 (die attestierte Berechtigungsnachweisinformationen enthalten) und der Attestierungsaussage 902 wird von 9 veranschaulicht. Falls ein Authenticator Selbstattestierung oder keine Attestierung einsetzt, dann werden keine Begleitinformationen für die vertrauende Partei bereitgestellt, um eine Vertrauensentscheidung zu begründen. In diesen Fällen stellt der Authenticator dem vertrauenden Teil keine Garantie über seinen Betrieb bereit.
  • Die Authenticator-Datenstruktur 901 codiert kontextuelle Bindungen, die der Authenticator vornimmt. Diese Bindungen werden von dem Authenticator selbst gesteuert und leiten ihr Vertrauen von der Beurteilung der Sicherheitseigenschaften des Authenticators durch die WebAuthn-vertrauende Partei ab. In einigen Fällen kann der Authenticator in den Client eingebettet sein, und seine Bindungen sind möglicherweise nicht vertrauenswürdiger als die Client-Daten. Zusätzlich oder alternativ kann der Authenticator eine getrennte Entität mit Hardware und Software hoher Sicherheit sein, die über einen sicheren Kanal mit dem Client verbunden ist. In beiden Fällen empfängt die vertrauende Partei die Authenticatordaten in demselben Format und verwendet ihre Kenntnis des Authenticators, um Vertrauensentscheidungen zu treffen. Die Authenticator-Datenstruktur 901 beinhaltet unter anderem, dass die überprüften Berechtigungsnachweisinformationen ein Byte-Array variabler Länge sind, das zu den Authenticator-Daten hinzugefügt wird, wenn ein Attestierungsobjekt 900 für einen gegebenen Berechtigungsnachweis erzeugt wird; sein Format ist in Tabelle 3 in [W3CWebAuthn] § 6.5.1 gezeigt.
  • Die Attestierungsaussage 902 ist ein spezifischer Typ von signiertem Datenobjekt, das Aussagen über einen Berechtigungsnachweis mit öffentlichem Schlüssel selbst und den Authenticator, der ihn erzeugt hat, enthält. Sie enthält eine Attestierungssignatur, die unter Verwenden des Schlüssels der Attestierungsbehörde erzeugt wird (außer für den Fall einer Selbstattestierung, wenn sie unter Verwenden des privaten Berechtigungsnachweisschlüssels erzeugt wird). Um eine Attestierungsaussage 902 korrekt zu interpretieren, muss eine vertrauende Partei die folgenden zwei Aspekte der Attestierung verstehen: das Attestierungsaussageformat und den Attestierungstyp.
  • Das Attestierungsaussageformat ist die Art, wie die Signatur dargestellt wird und die verschiedenen kontextbezogenen Bindungen von dem Authenticator in die Attestierungsaussage 902 aufgenommen werden. Mit anderen Worten definiert dies die Syntax der Aussage. Verschiedene existierende Komponenten und OS-Plattformen (wie zum Beispiel TPMs und das Android-OS) haben zuvor Attestierungsaussageformate definiert. Diese Spezifikation unterstützt eine Vielfalt derartiger Formate auf erweiterbare Weise, wie in [W3CWebAuthn] § 6.5.2 Attestation Statement Formats definiert. Die Formate selbst werden von Zeichenfolgen identifiziert, wie in [W3CWebAuthn] § 8.1 Attestation Statement Format Identifiers beschrieben.
  • Der Attestierungstyp definiert die Semantik von Attestierungsaussagen 902 und deren zugrunde liegende Vertrauensmodellen. Insbesondere definiert der Attestierungstyp, wie eine vertrauende Partei ein Vertrauen in einer speziellen Attestierungsaussage 902 herstellt, nachdem sie verifiziert hat, dass sie kryptografisch gültig ist. Verschiedene unterstützte Attestierungstypen sind in [W3CWebAuthn] § 6.5.3 Attestation Types beschrieben.
  • Das Attestierungszertifikat kann ein X.509-Zertifikat für das Attestierungsschlüsselpaar sein, das von einem Authenticator verwendet wird, um seine Herstellung und Fähigkeiten zu attestieren. Zur Registrierungszeit verwendet der Authenticator den privaten Attestierungsschlüssel, um den öffentlichen Schlüssel für vertrauende Parteien (und zusätzliche Daten) zu signieren, den er erzeugt und über die authenticatorMakeCredential-Operation zurückgibt. Vertrauende Parteien verwenden den öffentlichen Attestierungsschlüssel, der in dem Attestierungszertifikat übermittelt wird, um die Attestierungssignatur zu verifizieren. Es wird angemerkt, dass der Authenticator im Fall einer Selbstattestierung weder ein getrenntes Attestierungsschlüsselpaar noch ein Attestierungszertifikat aufweist. Bei Selbstattestierung, auch als Surrogate Basic Attestation bekannt (siehe zum Beispiel Lindemann et al., „FIDO UAF Protocol Specification v1.0“, FIDO Alliance Proposed Standard (08 Dezember 2014), erhältlich bei: https://fidoalliance.org/specs/fido-uaf-vl.0-ps-20141208/fido-uaf-protokoll-v1.0-ps-20141208.html („[UAFProtocol]“) weist der Authenticator kein spezifisches Attestierungsschlüsselpaar auf, er verwendet stattdessen den privaten Berechtigungsnachweisschlüssel, um die Attestierungssignatur zu anzulegen. Authenticators ohne sinnvolle Schutzmaßnahmen für einen privaten Attestierungsschlüssel verwenden typischerweise diesen Attestierungstyp.
  • 10 zeigt einen beispielhaften Authentifizierungsangriff durch Fehlen eines Attestierungsmechanismus. Dieses Beispiel beginnt bei Schritt 1001, bei dem ein Authentifizierungsserver 1050 eine Authentifizierungsanforderungsnachricht an den Client 1010 sendet (der gleich oder ähnlich der UE 2101, den UEs 1221, 1211 der 12, der UE/der Vorrichtung 2420 der 24, der UE 2902 der 29 und/oder anderen UEs, Mobilvorrichtungen und/oder Clients sein kann, die hier besprochen werden). Bei Schritt 1002 erhält der Client 1010 Authentifizierungsnachweise (zum Beispiel Schlüssel, Biometrie, Geheimnisse, Zertifikate usw.) von der sicheren Speicherung 1012, und bei Schritt 1003 stellt der Client 1010 die Authentifizierungsnachweise dem Authentifizierungsserver 1050 in einer Authentifizierungsantwortnachricht bereit. Bei Schritt 1004 stellt der Authentifizierungsserver 1050 dem Client 1010 ein Authentifizierungs-Token bereit. Bei Schritt 1005 stellt der Client 1010 dem Dienst 1020 eine Dienstanforderung mit dem Authentifizierungs-Token bereit, und als Reaktion stellt der Dienst 1020 dem Client 1010 bei Schritt 1006 eine Dienstantwort bereit. Währenddessen erhält ein Angreifer 1015 zu irgendeinem Zeitpunkt während der Schritte 1001 bis 1006 die Authentifizierungsnachweise von dem Client 1010 und/oder von der sicheren Speicherung 1012 bei Schritt 1007 und bei 1008 stellt der Angreifer 1015 eine illizite Dienstanforderung unter Verwenden eines Tokens (das auf eine gleiche oder ähnliche Weise erhalten wird wie im Zusammenhang mit den Schritten 1001 bis 1006 beschrieben) bereit, um persönliche und/oder vertrauliche Daten zu erhalten, die den Client 1010 betreffen.
  • 11 zeigt einen beispielhaften Authentifizierungsangriff, der mit einer Attestierung erweitert ist. Dieses Beispiel beginnt bei Schritt 1101, bei dem ein Authentifizierungsserver 1150 (der eine MEC-Plattform 2432 sein kann) eine Authentifizierungsanforderungsnachricht an den Client 1010 (der ein MEC-Verbraucher sein kann, wie etwa das UE 2101, das UEs 1221, 1211 der 12, das UE/die Vorrichtung 2420 der 24, das UE 2902 der 29 und/oder andere UEs, Mobilvorrichtungen und/oder Clients, die hierin besprochen sind) sendet.
  • Bei Schritt 1102 erhält der Client 1110 Authentifizierungsberechtigungsnachweise (zum Beispiel Schlüssel, Biometrie, Geheimnisse, Zertifikate usw.) von der sicheren Speicherung 1112, und bei Schritt 1103 führt der Client 1010 einen Beurteilungsschutzmechanismus (zum Beispiel Attestierung) mit dem Vertrauensanker 1115 (der ein Hardware- und/oder Softwareelement sein kann) aus. Bei Schritt 1104 stellt der Vertrauensanker 1115 dem Client 1110 einen Attestierungsbericht bereit. Bei Schritt 1104 liefert der Client 1110 den Attestierungsbericht an den Authentifizierungsserver 1150 in einer Authentifizierungsantwortnachricht. Bei Schritt 1106 bewertet der Authentifizierungsserver 1150 die Attestierungsmeldung, und bei Schritt 1107 stellt der Authentifizierungsserver 1150 dem Client 1010 ein Authentifizierungs-Token bereit (zum Beispiel bei erfolgreicher Validierung/Verifizierung der Attestierungsberichts). Bei Schritt 1105 stellt der Client 1010 dem Dienst 1120 (der ein MEC-Erzeugerelement sein kann) eine Dienstanforderung mit dem Authentifizierungs-Token bereit, und als Reaktion stellt der Dienst 1120 dem Client 1010 bei Schritt 1109 eine Dienstantwort bereit.
  • 2. EDGE-COMPUTING-SYSTEM-KONFIGURATIONEN UND -ANORDNUNGEN
  • Edge-Computing betrifft auf einer allgemeinen Ebene die Umsetzung, Koordination und Verwendung von Rechnen und Ressourcen an Orten näher an der „Edge“ oder Sammlung von „Edges“ des Netzwerks. Zweck dieser Anordnung ist es, die Gesamtkosten der Eigentümerschaft zu verbessern, Anwendungs- und Netzwerklatenz zu reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen (insbesondere im Vergleich zu herkömmlichem Cloud-Computing) zu verbessern. Komponenten, die Edge-Computing-Operationen ausführen können („Edge-Knoten“), können sich an jedem Ort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird (zum Beispiel in einem Hochleistungsrechenzentrum oder einer Hochleistungs-Cloud-Installation; einem bezeichneten 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 verbraucht).
  • Individuelle Computing-Plattformen oder andere Komponenten, die Edge-Computing-Operationen ausfü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 (zum Beispiel 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 bezeichneten Edge-Knoten-Server, einem Unternehmens server, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert, umgesetzt werden.
  • Edge-Computing-Knoten können Ressourcen (zum Beispiel Speicher, CPU, GPU, Interruptsteuervorrichtungen, E/A-Steuervorrichtungen, Speichersteuervorrichtung, Bussteuervorrichtungen, 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 (Function-as-a-Service - FaaS), Servlets, Server und/oder andere ähnliche Rechenabstraktionen bereitstellen. Container sind begrenzte 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 (zum Beispiel VM oder Container-Engine usw.) koordiniert wird. Die Orchestrierungsfunktionen können verwendet werden, um die isolierten Benutzerrauminstanzen einzusetzen, die Verwendung spezifischer Hardware, sicherheitsbezogene Funktionen (zum Beispiel Schlüsselverwaltung, Vertrauensankerverwaltung usw.) sowie andere Aufgaben im Zusammenhang mit der Bereitstellung und dem Lebenszyklus isolierter Benutzerräume zu identifizieren und zu planen.
  • Anwendungen, die für Edge-Computing angepasst wurden, beinhalten unter anderem Virtualisierung traditioneller Netzwerkfunktionen (um zum Beispiel Telekommunikations- oder Internetdienste zu betreiben) und die Einführung von Merkmalen und Diensten der nächsten Generation (um zum Beispiel 5G-Netzwerkdienste zu unterstützen). Verwendungsfälle, deren Planung weitgehendes Nutzen von Edge-Computing vorsieht, beinhalten vernetzte selbstfahrende Autos, Überwachung, Internet-der-Dinge-Vorrichtungsdatenanalytik (IoT-Vorrichtungsdatenanalytik), Videocodierung und -analytik, ortsbezogene Dienste, Vorrichtungsabtastung in Smart Cities, unter vielen anderen Netzwerken und rechenintensiven Diensten.
  • Edge-Computing kann bei einigen Szenarien einen Cloud-ähnlichen verteilten Dienst anbieten oder hosten, um Orchestrierung und Verwaltung für Anwendungen und koordinierte Dienstinstanzen unter vielen Arten von Speicherungs- und Rechenressourcen anzubieten. Es wird auch erwartet, dass Edge-Computing eng mit existierenden Verwendungsfällen und Technologie integriert ist, die für IoT- und Fog-/verteilte Networking-Konfigurationen entwickelt wurden, da Endpunktvorrichtungen, Clients und Gateways versuchen, auf Netzwerkressourcen und Anwendungen an Orten zuzugreifen, die näher am Rand des Netzwerks liegen.
  • Die vorliegende Offenbarung stellt spezifische Beispiele bereit, die für Edge-Computing-Konfigurationen relevant sind, die innerhalb von Mehrfachzugriffs-Edge-Computing(MEC)- und 5G-Netzwerkumsetzungen bereitgestellt werden. Viele andere Standards und Netzwerkumsetzungen sind jedoch auf die hier besprochenen Edge- und Dienstverwaltungskonzepte anwendbar. Zum Beispiel können viele andere Edge-Computing-/Networking-Technologien auf die vorliegende Offenbarung in verschiedenen Kombinationen und Layouts von Vorrichtungen anwendbar sein, die sich am Rand eines Netzwerks befinden. Beispiele für derartige anderen Edge-Computing-/Networking-Technologien 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) -Anbietersysteme (zum Beispiel verwendet in ACC-Architekturen); Nebula Edge-Cloud-Systemen; Fog-Computersystemen; Cloudlet Edge-Cloud-Systemen; Mobile Cloud Computing (MCC) -Systemen; Central Office Re-architected as a Datacenter (CORD), ein Mobile CORD (M-CORD) und/oder Converged Multi-Access and Core-Systeme (COMAC-Systeme ausgebildet sind; und/oder dergleichen.) Weiter können die hierin offenbarten Techniken andere IoT-Edge-Netzwerksysteme und -konfigurationen betreffen und andere Zwischenverarbeitungsentitäten und Architekturen können auch für Zwecke der vorliegenden Offenbarung verwendet werden.
  • 12 veranschaulicht eine beispielhafte Edge-Computing-Umgebung 1200. 12 veranschaulicht insbesondere die unterschiedlichen Kommunikationsschichten, die innerhalb der Umgebung 1200 auftreten, beginnend mit Endpunktsensoren- oder Dinge-Schichten 1210 (zum Beispiel die in einer Internet-der-Dinge-Netzwerktopologie (IoT-Netzwerktopologie) arbeiten), die eine oder mehrere IoT-Vorrichtungen 1211 (auch als Edge-Endpunkte 1210 oder dergleichen bezeichnet) umfassen; Erhöhen der Ausgereiftheit an Gateways oder Zwischenknotenschicht 1220, die ein oder mehrere Benutzergeräte (UEs) 1221a und 1221b (auch als Zwischenknoten 1220 oder dergleichen bezeichnet) umfassen, die das Sammeln und Verarbeiten von Daten von Endpunkten 1210 erleichtern; Erhöhen des Verarbeitungs- und Konnektivitätsaufwandes mit der Zugangsknotenschicht 1230 (oder „Edge-Knotenschicht 1230“), die eine Vielzahl von Netzwerkzugangsknoten (NANs) 1231, 1232 und 1233 (gemeinsam als „NANs 1231 bis 1233“ bezeichnet) umfasst oder dergleichen) und eine Vielzahl von Edge-Computing-Knoten 1236a bis c (kollektiv als „Edge-Computing-Knoten 1236“ oder dergleichen bezeichnet) innerhalb eines Edge-Computing-Systems 1235; und Erhöhen der Konnektivität und des Verarbeitungsaufwands zu einer Backend-Schicht 1210, die ein Kernnetzwerk (CN) 1242 und eine Cloud 1244 umfasst. Die Verarbeitung an der Backend-Schicht 1210 kann von Netzwerkdiensten, wie sie von einer oder mehreren Fernanwendungs-(App)-Server 1250 und/oder anderen Cloud-Dienste ausgeführt werden, verbessert werden. Einige oder alle dieser Elemente können mit einigen oder allen hierin besprochenen Merkmalen und/oder Funktionalität ausgestattet sein oder diese anderswie umsetzen.
  • Es ist gezeigt, dass die Umgebung 1200 Endbenutzervorrichtungen, wie Zwischenknoten 1220 und Endpunkte 1210 beinhaltet, die konfiguriert sind, um basierend auf unterschiedlichen Zugangstechnologien (oder „Funkzugangstechnologien“) zum Zugreifen auf Anwendungsdienste eine Verbindung mit einem oder mehreren Kommunikationsnetzwerken (auch als „Zugangsnetzwerke“, „Funkzugangsnetzwerke“ oder dergleichen bezeichnet) herzustellen (oder kommunikativ damit zu koppeln). Diese Zugangsnetzwerke können eines oder mehrere der NANs 1231, 1232 und/oder 1233 beinhalten. Die NANs 1231 bis 1233 sind eingerichtet, um den Endbenutzervorrichtungen über jeweilige Verbindungen 1203, 1207 zwischen den einzelnen NANs und dem einen oder den mehreren UEs 1211, 1221 Netzwerkkonnektivität bereitzustellen.
  • Als Beispiele können die Kommunikationsnetzwerke und/oder Zugangstechnologien zellulare Technologie, wie etwa LTE, MuLTEfire und/oder NR/5G (wie zum Beispiel von dem Funkzugangsnetzwerk (RAN) -Knoten 1231 und/oder RAN-Knoten 1232 bereitgestellt), WiFi oder Wireless Local Area Network-Technologien (WLAN-Technologien) (wie zum Beispiel von dem Zugangspunkt (AP) 1233 und/oder RAN-Knoten 1232 bereitgestellt) und/oder dergleichen beinhalten. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistungsfähigkeit in unterschiedlichen Szenarien wird von der Auswahl der Zugangsnetzwerke (zum Beispiel WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokolle (zum Beispiel Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path-TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) abhängig.
  • Die Zwischenknoten 1220 beinhalten UE 1221a und UE 1221b (gemeinsam als „UE 1221“ oder „UEs 1221“ bezeichnet). Bei diesem Beispiel ist das UE 1221a als ein Fahrzeug-UE veranschaulicht und ist das UE 1221b als ein Smartphone (zum Beispiel Handheld-Touchscreen-Mobilrechenvorrichtung, die mit einem oder mehreren zellularen Netzwerken verbindbar ist) veranschaulicht. Diese UEs 1221 können jedoch eine beliebige mobile oder nicht-mobile Rechenvorrichtung, wie Tablet-Computer, tragbare Vorrichtungen, PDAs, Pager, Desktop-Computer, Laptop-Computer, drahtlose Handapparate, unbemannte Fahrzeuge oder Drohnen, und/oder eine beliebige Art von Rechenvorrichtung, einschließlich einer drahtlosen Kommunikationsschnittstelle, umfassen.
  • Die Endpunkte 1210 beinhalten UEs 1211, die IoT-Vorrichtungen (auch als „IoT-Vorrichtungen 1211“ bezeichnet) sein können, die eindeutig identifizierbare eingebettete Rechenvorrichtungen (zum Beispiel innerhalb der Internetinfrastruktur) sind, die eine Netzwerkzugangsschicht umfassen, die für IoT-Anwendungen mit niedriger Leistung ausgelegt ist, die kurzlebige UE-Verbindungen nutzen. Die IoT-Vorrichtungen 1211 sind beliebige physische oder virtualisierte Vorrichtungen, Sensoren oder „Dinge“, die in Hardware- und/oder Softwarekomponenten eingebettet sind, die die Objekte, Vorrichtungen, Sensoren oder „Dinge“ aktivieren, die in der Lage sind, mit einem Ereignis assoziierte Daten zu erfassen und/oder aufzuzeichnen, und in der Lage sind, derartige Daten über ein Netzwerk mit wenig oder keinem Benutzereingriff mit einer oder mehreren anderen Vorrichtungen auszutauschen. Als Beispiele können IoT-Vorrichtungen 1211 abiotische Vorrichtungen sein, wie etwa autonome Sensoren, Messgeräte, Zähler, Bildaufzeichnungsvorrichtungen, Mikrofone, Licht emittierende Vorrichtungen, Audio emittierende Vorrichtungen, Audio- und/oder Videowiedergabevorrichtungen, elektromechanische Vorrichtungen (zum Beispiel Schalter, Aktuator usw.), EEMS, ECUs, ECMs, eingebettete Systeme, Mikrocontroller, Steuermodule, vernetzte oder „intelligente“ Geräte, MTC-Vorrichtungen, M2M-Vorrichtungen und/oder dergleichen. Die IoT-Vorrichtungen 1211 können Technologien, wie etwa M2M oder MTC, zum Austauschen von Daten mit einem MTC-Server (zum Beispiel einem Server 1250), einem Edge-Server 1236 und/oder einem Edge-Computing-System 1235 oder einer Vorrichtung über eine PLMN-, ProSe- oder D2D-Kommunikation, Sensornetzwerke oder IoT-Netzwerke nutzen. Der M2M- oder MTC-Austausch von Daten kann ein maschineninitiierter Datenaustausch sein.
  • Die IoT-Vorrichtungen 1211 können Hintergrundanwendungen (zum Beispiel Keep-Alive-Nachrichten, Statusaktualisierungen usw.) ausführen, um die Verbindungen des IoT-Netzwerks zu erleichtern. Wenn die IoT-Vorrichtungen 1211 Sensorvorrichtungen sind oder in diese eingebettet sind, kann das IoT-Netzwerk ein WSN sein. Ein IoT-Netzwerk beschreibt miteinander verbundene IoT-UEs, wie etwa die IoT-Vorrichtungen 1211, die über jeweilige direkte Verbindungen 1205 miteinander verbunden sind. Die IoT-Vorrichtungen können eine beliebige Anzahl unterschiedlicher Typen von Vorrichtungen beinhalten, die in verschiedenen Kombinationen gruppiert sind (als eine „IoT-Gruppe“ bezeichnet), die IoT-Vorrichtungen beinhalten können, die einen oder mehrere Dienste für einen bestimmten Benutzer, Kunden, Organisationen usw. bereitstellen. Ein Dienstanbieter (zum Beispiel ein Eigentümer/Betreiber des Servers 1250, CN 1242 und/oder die Cloud 1244) kann die IoT-Vorrichtungen in der IoT-Gruppe in einem bestimmten Bereich (zum Beispiel in einer Geolokalisierung, einem Gebäude usw.) einsetzen, um den einen oder die mehreren Dienste bereitzustellen. Bei einigen Umsetzungen kann das IoT-Netzwerk ein Mesh-Netzwerk von IoT-Vorrichtungen 1211 sein, das als eine Fog-Vorrichtung, ein Fog-System oder Fog bezeichnet werden kann, die/das am Rand der Cloud 1244 arbeiten. Bei einigen Umsetzungen kann das IoT-Netzwerk ein Mesh-Netzwerk von IoT-Vorrichtungen 1211 sein, die als Fog-Vorrichtung, Fog-System oder Fog bezeichnet werden können, die am Rand der Cloud 1244 arbeiten. Fog-Computing ist eine horizontale Architektur auf Systemebene, die Rechen-, Speicherungs-, Steuer- und Vernetzungsressourcen und Dienste überall entlang des Kontinuums von der Cloud 1244 zu Dingen (zum Beispiel IoT-Vorrichtungen 1211) verteilt. Der Fog kann gemäß Spezifikationen festgelegt werden, die, unter anderen, von OFC, OCF herausgeben werden. Zusätzlich oder alternativ kann der Fog ein Tangle sein, wie sie von der IOTA-Foundation definiert ist.
  • Der Fog kann verwendet werden, um Berechnung/Aggregation mit niedriger Latenz auf den Daten auszuführen, während sie zu einem Edge-Cloud-Computing-Dienst (zum Beispiel Edge-Knoten 1230) und/oder einem zentralen Cloud-Computing-Dienst (zum Beispiel Cloud 1244) geleitet werden, um umfangreiche Berechnungen oder rechnerisch aufwändige Aufgaben auszuführen. Andererseits schließt Edge-Cloud-Computing von Menschen betriebene, freiwillige Ressourcen als eine Cloud zusammen. Diese freiwilligen Ressourcen können unter anderem Zwischenknoten 1220 und/oder Endpunkte 1210, Desktop-PCs, Tablets, Smartphones, Nanodatenzentren und dergleichen beinhalten. Bei verschiedenen Umsetzungen können sich Ressourcen in der Edge-Cloud in Ein- bis Zwei-Hops-Nähe von den IoT-Vorrichtungen 1211 befinden, was zum Reduzieren von Overhead in Bezug im Zusammenhang mit Datenverarbeitung führen kann und Netzwerkverzögerung reduzieren kann.
  • Zusätzlich oder alternativ kann der Fog eine Konsolidierung von IoT-Vorrichtungen 1211 und/oder Networking-Vorrichtungen, wie etwa Routern und Switches, mit hohen Rechenfähigkeiten und der Fähigkeit sein, Cloud-Anwendungslogik auf ihrer nativen Architektur auszuführen. Fog-Ressourcen können von Cloud-Anbietern hergestellt, verwaltet und eingesetzt werden, und sie können mittels zuverlässiger Hochgeschwindigkeitsverbindungen miteinander verbunden sein. Darüber hinaus liegen Fog-Ressourcen im Vergleich zu Edge-Systemen weiter vom Rand des Netzwerks entfernt, aber näher als eine zentrale Cloud-Infrastruktur. Fog-Vorrichtungen werden verwendet, um rechenintensive Aufgaben oder Arbeitslasten, die von Edge-Ressourcen abgeladen werden, effektiv zu handhaben.
  • Zusätzlich oder alternativ kann der Fog am Rand der Cloud 1244 arbeiten. Der Fog, der am Rand der Cloud 1244 arbeitet, kann mit einem Edge-Netzwerk 1230 der Cloud 1244 überlappen oder in dieses subsumiert werden. Das Edge-Netzwerk der Cloud 1244 kann mit dem Fog überlappen oder ein Teil des Fog werden. Darüber hinaus kann der Fog ein Edge-Fog-Netzwerk sein, das eine Edge-Schicht und eine Fog-Schicht beinhaltet. Die Edge-Schicht des Edge-Fog-Netzwerks beinhaltet eine Sammlung lose gekoppelter, freiwilliger und von Menschen betriebener Ressourcen (zum Beispiel die oben erwähnten Edge-Computing-Knoten 1236 oder Edge-Vorrichtungen). Die Fog-Schicht befindet sich oben auf der Edge-Schicht und ist ein Zusammenschluss von Networking-Vorrichtungen, wie etwa den Zwischenknoten 1220 und/oder Endpunkten 1210 der 12.
  • Daten können zwischen den IoT-Vorrichtungen 1211 oder zum Beispiel zwischen den Zwischenknoten 1220 und/oder Endpunkten 1210, die direkte Verbindungen 1205 miteinander aufweisen, wie in 12 gezeigt, erfasst, gespeichert/aufgezeichnet und kommuniziert werden. Eine Analyse des Verkehrsflusses und der Steuerschemata kann durch Aggregatoren umgesetzt werden, die über ein Mesh-Netzwerk mit den IoT-Vorrichtungen 1211 und miteinander in Kommunikation stehen. Die Aggregatoren können ein Typ einer IoT-Vorrichtung 1211 und/oder einer Netzwerkeinrichtung sein. In dem Beispiel der 12 können die Aggregatoren Edge-Knoten 1230 oder ein oder mehrere festgelegte Zwischenknoten 1220 und/oder Endpunkte 1210 sein. Daten können über den Aggregator zu der Cloud 1244 hochgeladen werden, und Befehle können von der Cloud 1244 von Gateway-Vorrichtungen empfangen werden, die mit den IoT-Vorrichtungen 1211 und den Aggregatoren durch das Mesh-Netzwerk in Kommunikation stehen. Anders als das herkömmliche Cloud-Rechenmodell, kann die Cloud 1244 bei einigen Umsetzungen geringe oder keine Rechenfähigkeiten aufweisen und dient nur als ein Repositorium zum Archivieren von Daten, die von dem Fog aufgezeichnet und verarbeitet werden. Bei diesen Umsetzungen zentralisiert die Cloud 1244 das Datenspeicherungssystem und stellt Zuverlässigkeit und Zugriff auf Daten durch die Rechenressourcen in den Fog- und/oder Edge-Vorrichtungen bereit. Der Data Store, der sich im Kern der Architektur der Cloud 1244 befindet, ist sowohl für Edge- als auch für Fogschichten des oben erwähnten Edge-Fog-Netzwerks zugänglich.
  • Wie zuvor erwähnt, stellen die Zugangsnetzwerke Netzwerkkonnektivität über jeweilige NANs 1231 bis 1233 für die Endbenutzervorrichtungen 1220, 1210 bereit. Die Zugangsnetzwerke können Funkzugangsnetzwerke (RANs) sein, wie etwa ein NG-RAN oder ein 5G-RAN für ein RAN, das in einem 5G/NR-Zellulametzwerk arbeitet, ein E-UTRAN für ein RAN, das in einem LTE- oder 4G-Zellularnetzwerk arbeitet, oder ein Legacy-RAN, wie etwa ein UTRAN oder GERAN für GSM- oder CDMA-Zellularnetzwerke. Das Zugangsnetzwerk oder RAN kann für WiMAX Umsetzungen als ein Zugangsdienstnetzwerk bezeichnet werden. Zusätzlich oder alternativ können alle oder Teile des RAN als eine oder mehrere Softwareentitäten umgesetzt sein, die auf Servercomputern als Teil eines virtuellen Netzwerks laufen, das als Cloud-RAN (CRAN), Cognitive Radio (CR), ein virtueller Basisbandeinheitspool (Virtual Baseband Unit Pool - vBUP) und/oder dergleichen bezeichnet werden kann. Zusätzlich oder alternativ kann das CRAN, CR oder vBBUP eine RAN-Funktionsaufteilung umsetzen, wobei eine oder mehrere Kommunikationsprotokollschichten von dem CRAN/CR/vBBUP betrieben werden und andere Kommunikationsprotokollinstanzen von einzelnen RAN-Knoten 1231, 1232 betrieben werden. Dieses virtualisierte Framework erlaubt es den freigegebenen Prozessorkernen der NANs 1231, 1232, andere virtualisierte Anwendungen auszuführen, wie virtualisierte Anwendungen für verschiedene hierin besprochene Elemente.
  • Die UEs 1221, 1211 können jeweilige Verbindungen (oder Kanäle) 1203 nutzen, von denen jede(r) eine physische Kommunikationsschnittstelle oder -schicht umfasst. Die Verbindungen 1203 sind als eine Luftschnittstelle veranschaulicht, um eine kommunikative Kopplung im Einklang mit zellularen Kommunikationsprotokollen, wie 3GPP-LTE, 5G/NR, Push-to-Talk (PTT) und/oder PTT over Cellular (POC), UMTS, GSM, CDMA und/oder beliebigen der anderen hierin erläuterten Kommunikationsprotokolle, zu ermöglichen. Zusätzlich oder alternativ kommunizieren die UEs 1211, 1221 und die NANs 1231 bis 1233 Daten (senden und empfangen zum Beispiel) über ein lizenziertes Medium (auch als das „lizenzierte Spektrum“ und/oder das „lizenzierte Band“ bezeichnet) und ein nicht lizenziertes gemeinsam genutztes Medium (auch als das „nicht lizenzierte Spektrum“ und/oder das „nicht lizenzierte Band“ bezeichnet). Um in dem unlizenzierten Spektrum zu arbeiten, können die UEs 1211, 1221 und NANs 1231 bis 1233 unter Verwenden von LAA-, Enhanced-LAA- (eLAA-) und/oder weiteren eLAA-(feLAA)-Mechanismen arbeiten. Die UEs 1221, 1211 können weiter Kommunikationsdaten direkt über jeweilige direkte Verbindungen 1205 austauschen, die ein LTE/NR-Proximity-Services-Link (ProSe-Link) oder PC5-Schnittstellen/-Verbindungen oder WiFi-basierte Verbindungen oder auf einem Personal Area Network (PAN) basierende Verbindungen (zum Beispiel auf IEEE 802.15.4 basierende Protokolle, einschließlich ZigBee, IPv6 über Low-Power-Wireless-Personal-Area-Networks (6LoWPAN), WirelessHART, MiWi, Thread usw.; WiFi-direct; Bluetooth/Bluetooth Low Energy (BLE)-Protokolle) sein können.
  • Zusätzlich oder alternativ liefern einzelne UEs 1221, 1211 Funkinformationen an ein oder mehrere NANs 1231 bis 1233 und/oder einen oder mehrere Edge-Computing-Knoten 1236 (zum Beispiel Edge-Server/Hosts usw.). 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 markiert (zum Beispiel der aktuelle Ort der UEs 1221, 1211). Als Beispiele können die von den UEs 1221, 1211 gesammelten und/oder in den Messberichten enthaltenen Messungen eines oder mehrere der Folgenden beinhalten: Bandbreite (BW), Netzwerk- oder Zelllast, Latenz, Jitter, Umlaufzeit (Round-Trip-Time - RTT), Anzahl von Interrupts, Out-of-Order-Lieferung von Datenpaketen, Sendeleistung, Bitfehlerrate, Bitfehlerverhältnis (BER), Block Fehlerrate (BLER), Paketverlustrate, Paketempfangsrate (PRR), e2e-Verzögerung, Signal-Rauschverhältnis (SNR), Signal-Rausch- und -Interferenz-Verhältnis (SINR), Signal-plus-Rausch-plus-Distortion-zu-Rausch-plus-Distortion-Verhältnis (SINAD), Träger-zu-Interferenz-plus-Rauschverhältnis (CINR), Additives weißes Gauß'sches Rauschen (AWGN), Energie-zu-Rausch-Leistungsdichte-Verhältnis (Eb/N0), Energie-zu-Bit-Interferenz-Leistungsdichte-Verhältnis (Ec/I0), Spitzen-zu-Durchschnitts-Leistungsverhältnis (PAPR), Referenzsignal-Empfangsleistung (Reference Signal Received Power - RSRP), RSSI (Received Signal Strength Indicator - RSSI), RSRQ (Reference Signal Received Quality - RSRQ), GNSS-Timing von Zellenrahmen zur UE-Positionierung für E-UTRAN oder 5G/NR (zum Beispiel ein Timing zwischen einer AP- oder RAN-Knoten-Referenzzeit und einer GNSS-spezifischen Referenzzeit für ein gegebenes GNSS), GNSS-Code-Messungen (zum Beispiel Die GNSS-Code-Phase (ganzzahlige und gebrochene Teile) des Spreizcodes des i-ten GNSS-Satellitensignals), GNSS-Trägerphasenmessungen (zum Beispiel die Anzahl von Trägerphasenzyklen (ganzzahligen und gebrochenen Teilen) des i-ten GNSS-Satellitensignals, gemessen seit dem Einrasten auf dem Signal; auch als Accumulated Delta Range (ADR) bezeichnet), Kanalstörungsmessung, thermische Rauschleistungsmessung, Empfangsstörungsleistungsmessung und/oder andere ähnliche Messungen. Die RSRP-, RSSI- und/oder RSRQ-Messungen können RSRP-, RSSI- und/oder RSRQ-Messungen zellspezifischer Referenzsignale, Kanalzustandsinformationsreferenzsignale (Channel State Information Reference Signals - CSI-RS) und/oder Synchronisationssignale (SS) oder SS- für 3GPP-Netzwerke (zum Beispiel LTE oder 5G/NR) und RSRP-, RSSI- und/oder RSRQ-Messungen verschiedener Beacon-, Fast Initial Link Setup-Entdeckungsrahmen (FILS-Entdeckungsrahmen) oder Sondenantwortrahmen 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 v16.2.0 (2021-03-31) („[TS36214]“), 3GPP TS 38.215 v16.4.0 (2020-12) („[TS38215]“), IEEE 802.11-2020, „IEEE Standard for Information Technology-Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks-Specific Requirements - Teil 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications“ (2021-02-26) („[EEEE80211]“) und/oder dergleichen. Zusätzlich oder alternativ kann eine beliebige der oben erwähnten Messungen (oder Kombination von Messungen) von einem oder mehreren NANs 1231 bis 1233 gesammelt und an den einen oder die mehreren Edge-Computing-Knoten 1236 geliefert werden.
  • Die Funkinformation kann als Reaktion auf ein Triggerereignis und/oder periodisch gemeldet werden. Zusätzlich oder alternativ melden einzelne UEs 1221, 1211 Funkinformationen entweder mit einer niedrigen Periodizität oder einer hohen Periodizität in Abhängigkeit von einem Datentransfer, der stattfinden soll, und/oder von anderen Informationen über den Datentransfer.
  • Zusätzlich oder alternativ können der oder die Edge-Computing-Knoten 1236 die Messungen von den NANs 1231 bis 1233 mit niedriger oder hoher Periodizität anfordern, oder die NANs 1231 bis 1233 können die Messungen an den oder die Edge-Computing-Knoten 1236 mit niedriger oder hoher Periodizität liefern. Zusätzlich oder alternativ können der oder die Edge-Computing-Knoten 1236 andere relevante Daten von anderen Edge-Computing-Knoten 1236, Kernnetzwerkfunktionen (NFs), Anwendungsfunktionen (AFs) und/oder anderen UEs 1211, 1221, wie etwa Key Performance Indicators (KPIs), mit den Messberichten oder getrennt von den Messberichten erhalten.
  • Das UE 1221b ist als zum Zugreifen auf einen Zugangspunkt (AP) 1233 über eine Verbindung1207 konfiguriert gezeigt. Bei diesem Beispiel ist gezeigt, dass der AP 1233 mit dem Internet verbunden ist, ohne sich mit dem CN 1242 des Drahtlossystems zu verbinden. Die Verbindung 1207 kann eine lokale Drahtlosverbindung, wie etwa eine einem beliebigen IEEE-802.11-Protokoll entsprechende Verbindung, umfassen, wobei der AP 1233 einen Wireless-Fidelity-Router (WiFi®-Router) umfassen würde. Zusätzlich oder alternativ können die UEs 1221 und die IoT-Vorrichtungen 1211 dazu konfiguriert sein, unter Verwenden geeigneter Kommunikationssignale miteinander oder mit einem beliebigen der AP 1233 über einen Einzel- oder Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie etwa unter anderem eine OFDM-Kommunikationstechnik (Orthogonal Frequency Division Multiplexing - OFDM), eine SC-FDMA-Kommunikationstechnik (Single Carrier Frequency Division Multiple Access Kommunikationstechnik) und/oder dergleichen, obwohl der Schutzumfang der vorliegenden Offenbarung in dieser Hinsicht nicht beschränkt ist. Die Kommunikationstechnik kann ein geeignetes Modulationsschema, wie etwa komplementäre Code-Umtastung (Complementary Code Keying - CCK); Phasenumtastung (Phase-Shift Keying - PSK), wie etwa Binär-PSK (BPSK), Quadratur-PSK (QPSK), Differenz-PSK (DPSK) usw., oder Quadratur-Amplitudenmodulation (QAM), wie etwa M-QAM; und/oder dergleichen umfassen.
  • Das eine oder die mehreren NANs 1231 und 1232, die Verbindungen 1203 aktivieren, können als „RAN-Knoten“ oder dergleichen bezeichnet werden. Die RAN-Knoten 1231, 1232 können Bodenstationen (zum Beispiel terrestrische Zugangspunkte) oder Satellitenstationen umfassen, die eine Abdeckung innerhalb eines geografischen Gebiets (zum Beispiel einer Zelle) bereitstellen. Die RAN-Knoten 1231, 1232 können als eine dedizierte physische Vorrichtung, wie eine Makrozellenbasisstation, und/oder eine Niederleistungsbasisstation zum Bereitstellen von Femtozellen, Pikozellen oder anderen ähnlichen Zellen mit kleineren Abdeckungsbereichen, kleineren Benutzerkapazitäten oder höheren Bandbreiten im Vergleich zu Makrozellen umgesetzt sein. Bei diesem Beispiel ist der RAN-Knoten 1231 als ein NodeB, evolvierter NodeB (eNB) oder ein NodeB der nächsten Generation (gNB) verkörpert, wobei die RAN-Knoten 1232 als Relaisknoten, verteilte Einheiten oder Straßenseiteneinheiten (Road Side Units - RSU) verkörpert sind. Jede andere Art von NANs kann verwendet werden.
  • Jeder der RAN-Knoten 1231, 1232 kann das Luftschnittstellenprotokoll beenden und kann der erste Kontaktpunkt für die UEs 1221 und die IoT-Vorrichtungen XE111 sein. Zusätzlich oder alternativ kann jeder der RAN-Knoten 1231, 1232 verschiedene logische Funktionen für das RAN erfüllen, einschließlich unter anderem RAN-Funktion(en) (zum Beispiel Funknetzsteuervorrichtungsfunktionen (Radio Network Controller - RNC-Funktionen) und/oder NG-RAN-Funktionen) für Funkressourcenverwaltung, Zulassungssteuerung, dynamische Uplink- und Downlink-Ressourcenzuordnung, Funkträgerverwaltung, Datenpaketplanung usw. Zusätzlich oder alternativ können die UEs 1211, 1221 dazu konfiguriert sein, unter Verwenden von OFDM-Kommunikationssignalen miteinander oder mit einem beliebigen der NANs 1231, 1232 über einen Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie etwa unter anderem eine OFDMA-Kommunikationstechnik (zum Beispiel für Downlink-Kommunikationen) und/oder eine SC-FDMA-Kommunikationstechnik (zum Beispiel für Uplink- und ProSe- oder Sidelink-Kommunikationen), obwohl der Schutzumfang der vorliegenden Offenbarung in dieser Hinsicht nicht beschränkt ist.
  • Für die meisten zellularen Kommunikationssysteme organisieren die RAN-Funktion(en), die von dem RAN oder einzelnen NANs 1231-1232 betrieben werden, Downlink-Übertragungen (zum Beispiel von einem der RAN-Knoten 1231, 1232 zu den UEs 1211, 1221) und Uplink-Übertragungen (zum Beispiel von den UEs 1211, 1221 zu den RAN-Knoten 1231, 1232) in Funkrahmen (oder einfach „Rahmen“) mit einer Dauer von 10 Millisekunden (ms), wobei jeder Rahmen zehn 1-ms-Subrahmen beinhaltet. Jede Übertragungsrichtung hat ihr eigenes Ressourcengitter, das physische Ressourcen in jedem Slot angibt, wobei jede Spalte und jede Zeile eines Ressourcengitters einem Symbol bzw. einem Unterträger entspricht. Die Dauer des Ressourcengitters in der Zeitdomäne entspricht einem Schlitz in einem Funkrahmen. Die Ressourcengitter umfassen eine Anzahl von Ressourcenblöcken (RBs), die die Abbildung bestimmter physischer Kanäle auf Ressourcenelemente (REs) beschreiben. Jeder RB kann ein physischer RB (PRB) oder ein virtueller RB (VRB) sein und umfasst eine Sammlung von REs. Ein RE ist die kleinste Zeit-Frequenz-Einheit in einem Ressourcengitter. Die RNC-Funktion(en) ordnet (ordnen) Ressourcen (zum Beispiel PRBs und Modulations- und Codierungsschemata (MCS)) jedem UE 1211, 1221 in jedem Übertragungszeitintervall (TTI) dynamisch zu. Ein TTI ist die Dauer einer Übertragung auf einer Funkverbindung 1203, 1205 und betrifft die Größe der Datenblöcke, die von höheren Netzwerkschichten an die Funkverbindungsschicht weitergeleitet werden.
  • Die NANs 1231/1232 können derart konfiguriert sein, dass sie miteinander über entsprechende Schnittstellen oder Verbindungen (nicht gezeigt) kommunizieren, wie über eine X2-Schnittstelle für LTE-Umsetzungen (zum Beispiel wenn CN 1242 ein Evolved Packet Core (EPC) ist), eine Xn-Schnittstelle für 5G- oder NR-Umsetzungen (zum Beispiel, wenn CN 1242 ein Kern der fünften Generation (5GC) ist) oder dergleichen. Die NANs 1231 und 1232 sind auch kommunikativ mit CN 1242 gekoppelt. Zusätzlich oder alternativ kann das CN 1242 ein Evolved-Packet-Core-Netzwerk (EPC-Netzwerk), ein NextGen Packet Core-Netzwerk (NPC-Netzwerk), ein 5G-Kern (5GC) oder eine andere Art von CN sein. Das CN 1242 kann eine Vielzahl von Netzwerkelementen umfassen, die dazu konfiguriert sind, Kunden/Teilnehmern (zum Beispiel Benutzern von UEs 1221 und IoT-Vorrichtungen 1211), die über ein RAN mit dem CN 1242 verbunden sind, verschiedene Daten- und Telekommunikationsdienste anzubieten. Die Komponenten des CN 1242 können in einem physischen Knoten oder separaten physischen Knoten umgesetzt sein, einschließlich Komponenten zum Lesen und Ausführen von Anweisungen aus einem maschinenlesbaren oder computerlesbaren Medium (zum Beispiel einem nichtflüchtigen maschinenlesbaren Speichermedium). Zusätzlich oder alternativ kann Netzwerkfunktionsvirtualisierung (NFV) genutzt werden, um beliebige oder alle der oben beschriebenen Netzwerkknotenfunktionen über ausführbare Anweisungen zu virtualisieren, die in einem oder mehreren computerlesbaren Speichermedien gespeichert sind (unten ausführlicher beschrieben). Eine logische Instanziierung des CN 1242 kann als ein Netzwerk-Slice bezeichnet werden und eine logische Instanziierung eines Teils des CN 1242 kann als ein Netzwerk-Sub-Slice bezeichnet werden. NFV-Architekturen und Infrastrukturen können verwendet werden, um eine oder mehrere Netzwerkfunktionen, die alternativ von proprietärer Hardware ausgeführt werden, auf physischen Ressourcen, die eine Kombination von Industriestandardserver-Hardware, Speicher-Hardware oder Switches umfassen, zu virtualisieren. Mit anderen Worten können NFV-Systeme verwendet werden, um virtuelle oder umkonfigurierbare Umsetzungen einer oder mehrerer Komponenten/Funktionen des CN 1242 auszuführen.
  • Das CN 1242 ist als kommunikativ mit einem Anwendungsserver 1250 und einem Netzwerk 1250 über eine IP-Kommunikationsschnittstelle 1255 verbunden gezeigt. Der eine oder die mehreren Server 1250 umfassen ein oder mehrere physische und/oder virtualisierte Systeme zum Bereitstellen von Funktionalität (oder Diensten) zu einem oder mehreren Clients (zum Beispiel UEs 1221 und IoT-Vorrichtungen 1211) über ein Netzwerk. Der eine oder die mehreren Server 1250 können verschiedene Computervorrichtungen mit Rack-Computing-Architekturkomponente(n), Tower-Computing-Architekturkomponente(n), Blade-Computing-Architekturkomponente(n) und/oder dergleichen beinhalten. Der eine oder die mehreren Server 1250 können ein Cluster von Servern, eine Serverfarm, einen Cloud-Computing-Dienst oder eine andere Gruppierung oder einen anderen Pool von Servern, die sich in einem oder mehreren Datenzentren befinden können, darstellen. Der eine oder die mehreren Server 1250 können auch mit einer oder mehreren Datenspeichervorrichtungen (nicht gezeigt) verbunden oder anderswie damit assoziiert sein. Zudem können der eine oder die mehreren Server 1250 ein Betriebssystem (OS) beinhalten, das ausführbare Programmanweisungen für die allgemeine Verwaltung und den Betrieb der einzelnen Servercomputervorrichtungen bereitstellt, und können ein computerlesbares Medium beinhalten, das Anweisungen speichert, die, wenn sie von einem Prozessor der Server ausgeführt werden, es den Servern erlauben können, ihre beabsichtigten Funktionen auszuführen. Geeignete Umsetzungen für das OS und die allgemeine Funktionalität von Servern sind bekannt oder im Handel erhältlich und werden von Durchschnittsfachleuten ohne Weiteres umgesetzt. Allgemein bieten der oder die Server 1250 Anwendungen oder Dienste an, die IP/Netzwerkressourcen verwenden. Als Beispiele können der eine oder die mehreren Server 1250 Verkehrsverwaltungsdienste, Cloud-Analytik, Inhalt-Streaming-Dienste, immersive Gaming-Erfahrungen, soziales Networking und/oder Mikroblog-Dienste und/oder andere ähnliche Dienste bereitstellen. Zusätzlich können die verschiedenen Dienste, die von dem einen oder den mehreren Server 1250 bereitgestellt werden, Initiieren und Steuern von Software- und/oder Firmware-Aktualisierungen für Anwendungen oder einzelne Komponenten, die von den UEs 1221 und den IoT-Vorrichtungen 1211 umgesetzt werden, beinhalten. Der eine oder die mehreren Server 1250 können auch dazu konfiguriert sein, einen oder mehrere Kommunikationsdienste (zum Beispiel Voice-over-Internet-Protokoll (VoIP)-Sitzungen, PTT-Sitzungen, Gruppenkommunikationssitzungen, soziale Networking-Dienste usw.) für die UEs 1221 und IoT-Vorrichtungen 1211 über den CN 1242 zu unterstützen.
  • Die Funkzugangstechnologien (RATs), die von den NANs 1231 bis 1233, den UEs 1221, 1211 und in den anderen Elemente in 12 eingesetzt werden, können eine oder mehrere V2X RATs beinhalten, die es diesen Elementen erlauben, direkt miteinander, mit Infrastrukturgeräten (zum Beispiel NANs 1231 bis 1233) und anderen Vorrichtungen zu kommunizieren. Eine beliebige Anzahl von V2X RATs kann für V2X-Kommunikation verwendet werden. Bei einigen Umsetzungen können mindestens zwei getrennte V2X RATs verwendet werden, einschließlich WLAN V2X-RAT (W-V2X-RAT) basierend auf IEEE-V2X-Technologien (zum Beispiel DSRC für die USA und ITS-G5 für Europa) und 3GPP C-V2X-RAT (zum Beispiel LTE, 5G/NR und darüber).
  • Die W-V2X-RATs beinhalten zum Beispiel IEEE 1609.0-2019, „IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture“ (2019-04-10) („[IEEE16090]“), SAE Int'l, „V2X Communications Message Set Dictionary“ (früher „Dedicated Short Range Communication (DSRC) Message Set Dictionary“) (2020-07-23) („[J2735_202007]“), Intelligente Transportsysteme im 5-GHz-Frequenzband (ITS-G5), das IEEE 802.11p-Protokoll (das der Teil der Schicht 1 (L1) und Schicht 2 (L2) von WAVE, DSRC und ITS-G5 ist) und mitunter IEEE 802.16-2017, „IEEE Standard for Air Interface for Broadband Wireless Access Systems“ (mitunter als „Worldwide Interoperability for Microwave Access“ oder „WiMAX“ bezeichnet) (2018-03-02) („[WiMAX]“). Der Begriff „DSRC“ betrifft Fahrzeugkommunikationen im 5,9-GHz-Frequenzband, das im Allgemeinen in den Vereinigten Staaten verwendet wird, während „ITS-G5“ Fahrzeugkommunikationen im 5,9-GHz-Frequenzband in Europa betrifft. Da eine beliebige Anzahl unterschiedlicher RATs anwendbar ist (einschließlich IEEE 802.11p-basierter RATs), die in einem beliebigen geografischen oder politischen Gebiet verwendet werden können, können die Begriffe „DSRC“ (unter anderen Gebieten in den USA verwendet) und „ITS-G5“ (unter anderen Gebieten in Europa verwendet) durch diese Offenbarung hindurch austauschbar verwendet werden. Die Zugangsschicht für die ITS-G5-Schnittstelle ist in ETSI EN 302 663 V1.3.1 (2020-01) (im Folgenden „[EN302663]“) umrissen und beschreibt die Zugangsschicht der ITS-S-Referenzarchitektur. Die ITS-G5-Zugangsschicht umfasst (die nun IEEE 802.11p beinhaltet) und IEEE 802.2 Logical Link Control (LLC) („[IEEE8022]“) und/oder IEEE/ISO/IEC 8802-2-1998-Protokolle sowie Merkmale für Decentralized-Congestion-Control-Verfahren (DCC-Verfahren), die in ETSI TS 102 687 V1.2.1 (2018-04) („ [TS102687]“) erörtert sind. Die Zugangsschicht für 3GPP LTE-V2X-basierte (n) Schnittstelle(n) ist (sind) unter anderem in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS 23.285 v16.2.0 (2019-12) umrissen; und 3GPP 5G/NR-V2X ist unter anderem in 3GPP TR 23.786 v16.1.0 (2019-06) und 3GPP TS 23.287 v16.2.0 (2020-03) umrissen.
  • Die Cloud 1244 kann eine Cloud-Computing-Architektur/-Plattform darstellen, die einen oder mehrere Cloud-Computing-Dienste bereitstellt. Cloud-Computing verweist auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Pool gemeinsam nutzbarer Rechenressourcen mit Selbstbedienungsbereitstellung und -Verwaltung bei Bedarf und ohne aktives Management durch Benutzer. Rechenressourcen (oder einfach „Ressourcen“) sind eine beliebige physische oder virtuelle Komponente oder Verwendung derartiger Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Ressourcen beinhalten Nutzung/Zugriff auf Server, Prozessor(en), Speicherungsgeräte, Speichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, Eingabe/Ausgabe-Vorrichtungen (Peripherie-Vorrichtungen), mechanische Vorrichtungen, Netzwerkverbindungen (zum Beispiel Kanäle/Links, Ports, Netzwerkbuchsen usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen. 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 Verwenden einer definierten Schnittstelle (zum Beispiel einer API oder dergleichen) aufgerufen werden. Einige Fähigkeiten der Cloud 1244 beinhalten Anwendungsfähigkeitentyp, Infrastrukturfähigkeitentyp und Plattformfähigkeitentyp. Ein Cloud-Fähigkeitentyp ist eine Klassifizierung der Funktionalität, die einem Cloud-Dienst-Kunden (zum Beispiel einem Benutzer der Cloud 1244) von einem Cloud-Dienst bereitgestellt wird, basierend auf den verwendeten Ressourcen. Der Anwendungsfähigkeitentyp ist ein Cloud-Fähigkeitentyp, bei dem der Cloud-Fähigkeitentyp die Anwendungen des Cloud-Dienstanbieters verwenden kann; der Infrastrukturfähigkeitentyp ist ein Cloud-Fähigkeitentyp, bei dem der Cloud-Fähigkeitentyp Verarbeitungs-, Speicherungs- oder Networking-Ressourcen bereitstellen und verwenden kann; und der Plattformfähigkeitentyp ist ein Cloud-Fähigkeitentyp ist, bei dem der Cloud-Dienstkunde vom Kunden erstellte oder vom Kunden erworbene Anwendungen unter Verwenden einer oder mehrerer Programmiersprachen und einer oder mehrerer Ausführungsumgebungen, die vom Cloud-Dienstanbieter unterstützt werden, einsetzen, verwalten und ausführen kann. Cloud-Dienste können in Kategorien gruppiert werden, die einen gemeinsamen Satz von Qualitäten besitzen.
  • Einige Cloud-Dienstkategorien, die Cloud 1244 bereitstellen können, beinhalten zum Beispiel
  • Communications as a Service(CaaS), der eine Cloud-Dienstkategorie ist, die Echtzeitinteraktions- und Zusammenarbeitdienste beinhaltet; Compute as a Service(CompaaS), der eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Verarbeitungsressourcen beinhaltet, die benötigt werden, um Software einzusetzen und auszuführen; Database as a Service (DaaS), der eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Datenbanksystem-Verwaltungsdiensten beinhaltet; Data Storage as a Service (DSaaS), der eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Datenspeicherung und verwandten Fähigkeiten beinhaltet; Firewall as a Service (FaaS), der eine Cloud-Dienstkategorie ist, die die Bereitstellung von Firewall und Netzwerkverkehrsverwaltungsdiensten beinhaltet; Infrastructure as a Service (IaaS), der eine Cloud-Dienstkategorie ist, die Infrastrukturfähigkeitentyp beinhaltet; Network as a Service (NaaS), der eine Cloud-Dienstkategorie ist, die Transportkonnektivität und verwandte Netzwerkfähigkeiten beinhaltet; Platform as a Service (PaaS), der eine Cloud-Dienstkategorie ist, die den Plattformfähigkeitentyp beinhaltet; Software as a Service (SaaS), der eine Cloud-Dienstkategorie ist, die den Anwendungsfähigkeitentyp beinhaltet; Security as a Service, der eine Cloud-Dienstkategorie ist, die das Bereitstellen von Netzwerk- und Informationssicherheitsdiensten (Infosec) beinhaltet; und/oder andere ähnliche Cloud-Dienste.
  • Zusätzlich oder alternativ kann die Cloud 1244 ein Netzwerk darstellen, wie etwa das Internet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), ein drahtloses lokales Netzwerk (WLAN) oder ein drahtloses Weitverkehrsnetzwerk (WWAN), einschließlich proprietärer und/oder Unternehmensnetzwerke für eine Firma oder Organisation oder Kombinationen davon.
  • Hier beinhaltet die Cloud 1244 ein oder mehrere Netzwerke, die Computer, Netzwerkverbindungen zwischen den Computern und Softwareroutinen umfassen, um eine Kommunikation zwischen den Computern über Netzwerkverbindungen zu ermöglichen. In dieser Hinsicht umfasst die Cloud 1244 ein oder mehrere Netzwerkelemente, die einen oder mehrere Prozessoren, Kommunikationssysteme (die zum Beispiel Netzwerkschnittstellensteuervorrichtungen, einen oder mehrere Sender/Empfänger, die mit einer oder mehreren Antennen verbunden sind usw. umfassen) und computerlesbare Medien umfassen können. Beispiele für derartige Netzwerkelemente können drahtlose Zugangspunkte (WAPs), Heim-/Geschäftsserver (mit oder ohne HF-Kommunikationsschaltanordnung), Router, Switches, Hubs, Funkbaken, Basisstationen, Picocell- oder Small-Cell-Basisstationen, Backbone-Gateways und/oder eine beliebige andere ähnliche Netzwerkvorrichtung beinhalten. Eine Verbindung mit der Cloud 1244 kann über eine drahtgebundene oder eine drahtlose Verbindung unter Verwenden der verschiedenen im Folgenden erörterten Kommunikationsprotokolle erfolgen. Mehr als ein Netzwerk kann an einer Kommunikationssitzung zwischen den veranschaulichten Vorrichtungen beteiligt sein. Eine Verbindung mit der Cloud 1244 kann erfordern, dass die Computer Softwareroutinen ausführen, die zum Beispiel die sieben Schichten des OSI-Modells eines Computer-Networking oder eines Äquivalents in einem drahtlosen (zellularen) Telefonnetzwerk ermöglichen. Die Cloud 1244 kann verwendet werden, um Kommunikation mit relativ großer Reichweite, wie etwa zum Beispiel zwischen dem einen oder den mehreren Servern 1250 und einem oder mehreren UEs 1221 und IoT-Vorrichtungen 1211, zu ermöglichen. Zusätzlich oder alternativ kann die Cloud 1244 das Internet, ein oder mehrere zellulare Netzwerke, lokale Netzwerke oder Weitverkehrsnetzwerke, einschließlich proprietärer und/oder Unternehmensnetzwerke, TCP/Internetprotokoll-basiertes (IP-basiertes) Netzwerk oder Kombinationen davon darstellen. Bei diesen Umsetzungen kann die Cloud 1244 mit einem Netzwerkbetreiber assoziiert sein, der Geräte und andere Elemente besitzt oder steuert, die notwendig sind, um netzwerkbezogene Dienste bereitzustellen, wie etwa eine oder mehrere Basisstationen oder Zugangspunkte, einen oder mehrere Server zum Routen digitaler Daten oder Telefonanrufe (zum Beispiel ein Kernnetzwerk oder Backbone-Netzwerk) usw. Die Backbone-Links 1255 können eine beliebige Anzahl drahtgebundener oder drahtloser Technologien beinhalten und können Teil eines LAN, eines WAN oder des Internets sein. Bei einem Beispiel sind die Backbone-Links1255 Backbone-Faser-Links, die niedrigere Ebenen von Dienstanbietern mit dem Internet, wie etwa dem CN 1212 und der Cloud 1244, koppeln.
  • Zusätzlich oder alternativ können die diversen Zugangstechnologien zellulare Technologie, wie LTE, MuLTEfire und/oder NR/5G (zum Beispiel wie von Funkzugangsnetzwerk-Knoten (RAN-Knoten) 1231-1232 bereitgestellt, WLAN, (zum Beispiel WiFi®)-Technologien (zum Beispiel wie von einem Zugangspunkt (AP) 1233 bereitgestellt) und/oder dergleichen beinhalten. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistungsfähigkeit in unterschiedlichen Szenarien wird von der Auswahl der Zugangsnetzwerke (zum Beispiel WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokolle (zum Beispiel Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path-TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) abhängig.
  • Die Edge-Computing-Knoten 1236 können ein Edge-System 1235 (oder ein Edge-Netzwerk 1235) beinhalten oder Teil davon sein. Die Edge-Computing-Knoten 1236 können auch als „Edge-Hosts 1236“ oder „Edge-Server 1236“ bezeichnet werden. Das Edge-System 1235 beinhaltet eine Sammlung von Edge-Servern 1236 (zum Beispiel MEC-Hosts/Servern 2402 der 24) und Edge-Verwaltungssystemen (nicht von 12 gezeigt), die notwendig sind, um Edge-Computing-Anwendungen (zum Beispiel MEC-Anwendungen 2426 der 24) innerhalb eines Betreibernetzwerks oder eines Teilsatzes eines Betreibernetzwerks auszuführen. Die Edge-Server 1236 sind physische Computersysteme, die eine Edge-Plattform (zum Beispiel MEC-Plattform 2432 der 24) und/oder Virtualisierungsinfrastruktur (zum Beispiel VI 2422 der 24) beinhalten können und Rechen-, Speicherungs- und Netzwerkressourcen für Edge-Computing-Anwendungen bereitstellen. Jeder der Edge-Server 1236 ist an einem Rand eines entsprechenden Zugangsnetzwerks angeordnet und ist dazu eingerichtet, Rechenressourcen und/oder verschiedene Dienste (zum Beispiel Rechenaufgaben- und/oder Arbeitslastabladung, Cloud-Computing-Fähigkeiten, IT-Dienste und andere ähnliche Ressourcen und/oder Dienste, wie hierin erörtert) in relativ enger Nähe zu Zwischenknoten 1220 und/oder Endpunkten 1210 bereitzustellen. Die VIs der Edge-Server 1236 stellen virtualisierte Umgebungen und virtualisierte Ressourcen für die Edge-Hosts bereit, und die Edge-Computing-Anwendungen können als VMs und/oder Anwendungscontainer auf der VI laufen. Eine beispielhafte Umsetzung des Edge-Systems 1235 ist ein MEC-System 1235, das im Folgenden im Zusammenhang mit den 24 bis 28 ausführlicher erörtert wird. Es versteht sich, dass die offenbarten MEC-Systeme und Diensteinsatzbeispiele nur ein veranschaulichendes Beispiel von Edge-Computing-Systemen/Netzwerken 1235 sind, und dass die vorliegende Offenbarung auf viele andere Edge-Computing/Networking-Technologien in verschiedenen Kombinationen und Layouts von Vorrichtungen, die sich am Rand eines Netzwerks befinden, einschließlich der verschiedenen Edge-Computing Netzwerke/Systeme, die hier beschrieben sind, anwendbar sein kann. Weiter können die hierin offenbarten Techniken andere IoT-Edge-Netzwerksysteme und Konfigurationen betreffen und andere Zwischenverarbeitungsentitäten und Architekturen können auch auf die vorliegende Offenbarung anwendbar sein.
  • Wie von 12 gezeigt, befindet sich jedes der NANs 1231, 1232 und 1233 gemeinsam mit den Edge-Computing-Knoten (oder „Edge-Servern“) Edge-Server, 1236b bzw. 1236c. Diese Umsetzungen können Small-Cell-Clouds (SCCs) sein, bei denen ein Edge-Computing-Knoten 1236 gemeinsam mit einer Small Cell (zum Beispiel Piko-Zelle, Femto-Zelle usw.) angeordnet ist, oder können Mobile Micro-Clouds (MCCs) sein, bei denen ein Edge-Computing-Knoten 1236 gemeinsam mit einer Makrozelle (zum Beispiel einem eNB, gNB usw.) angeordnet ist. Der Edge-Computing-Knoten 1236 kann in einer Vielzahl anderer Anordnungen als der in 12 gezeigten eingesetzt werden. Bei einem ersten Beispiel liegen mehrere NANs 1231 bis 1233 gemeinsam an einem Ort mit einem Edge-Computing-Knoten Edge-Servern gekoppelt oder anderswie kommunikativ gekoppelt. Bei einem zweiten Beispiel können die Edge-Server 1236 gemeinsam angeordnet oder von RNCs betrieben werden, was für Legacy-Netzwerkeinsätze, wie 3G-Netzwerke, der Fall sein kann. Bei einem dritten Beispiel können die Edge-Server Edge-Server 1236 an Zellaggregationsstellen oder an Multi-RAT-Aggregationspunkten eingesetzt werden, die sich entweder innerhalb eines Unternehmens befinden oder in öffentlichen Abdeckungsbereichen verwendet werden können. Bei einem vierten Beispiel können die Edge-Server 1236 an der Edge des CN 1242 eingesetzt werden. Diese Umsetzungen können in Follow-Me-Clouds (FMC) verwendet werden, wobei Cloud-Dienste, die an verteilten Datenzentren laufen, den UEs 1221 folgen, während sie durch das Netzwerk roamen.
  • Bei beliebigen der hierin besprochenen Umsetzungen stellen die Edge-Server 1236 eine verteilte Rechenumgebung für Anwendungs- und Dienst-Hosting bereit und stellen auch Speicherungs- und Verarbeitungsressourcen bereit, so dass Daten und/oder Inhalt in unmittelbarer Nähe zu Teilnehmern (zum Beispiel Benutzern von UEs 1221, 1211) für schnellere Antwortzeiten verarbeitet werden können. Die Edge-Server 1236 unterstützen auch Multi-Tenance-Laufzeit- und Hosting-Umgebung(en) für Anwendungen, einschließlich virtueller Geräteanwendungen, die als Bilder einer verpackten virtuellen Maschine (VM) geliefert werden können, Middleware-Anwendungs- und Infrastrukturdienste, Inhaltslieferdienste, einschließlich Inhalts-Caching, mobile Big-Data-Analytik und rechnerisches Abladen unter anderem. Das Rechenabladen involviert das Abladen rechnerischer Aufgaben, Arbeitslasten, Anwendungen und/oder Dienste von den UEs 1211, 1221, dem CN 1242, der Cloud 1244 und/oder den Server(n) 1250 auf die Edge-Server 1236 oder umgekehrt. Zum Beispiel kann eine Vorrichtungsanwendung oder Client-Anwendung, die in einem UE 1221, 1211 betrieben wird, Anwendungsaufgaben oder Arbeitslasten auf einen oder mehrere Edge-Server abladen. Bei einem anderen Beispiel kann ein Edge-Server 1236 Anwendungsaufgaben oder Arbeitslasten auf ein oder mehrere UEs 1221, 1211 abladen (zum Beispiel für verteilte ML-Berechnung oder dergleichen).
  • 13 ist ein Blockdiagramm 1300, das einen Überblick über eine Konfiguration zum Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als eine „Edge-Cloud“ bezeichnet wird. Wie gezeigt, befindet sich die Edge-Cloud 1310 gemeinsam an einem Edge-Ort, wie etwa einem Netzwerkzugangsknoten (NAN) 1340 (zum Beispiel Zugangspunkt oder Basisstation), einem lokalen Verarbeitungsknoten 1350 oder einer Zentrale 1320, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 1310 befindet sich viel näher an den Endpunkt-Datenquellen (Verbraucher- und Erzeuger-Datenquellen) 1360 (zum Beispiel autonome Fahrzeuge 1361, Benutzergerät 1362, Geschäfts- und Industriegerät 1363, Videoaufnahmevorrichtungen 1364, Drohnen 1365, intelligente Städten und Gebäudevorrichtungen 1366, Sensoren und IoT-Vorrichtungen 1367 usw.) als das Cloud-Datenzentrum 1330. Rechen-, Speicher- und Speicherungsressourcen, die an den Rändern in der Edge-Cloud 1310 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die von den Endpunktdatenquellen 1360 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 1310 zu dem Cloud-Datenzentrum 1330, wodurch Energieverbrauch und Gesamtnetzwerknutzungen unter anderen Vorteilen verbessert werden.
  • Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit von dem Edge-Ort ab (wobei zum Beispiel weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen verfügbar sind als an einer Basisstation als an einer Zentrale). Je näher sich der Edge-Ort jedoch am Endpunkt (zum Beispiel Benutzereinrichtung (UE)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Computing, die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sich sowohl geografisch als auch in der Netzwerkzugriffszeit näher befinden, zu reduzieren. Auf diese Weise versucht Edge-Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
  • Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere potenzielle Einsätze abdeckt und Einschränkungen anspricht, die einige Netzwerkbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Hierzu zählen Variation von Konfigurationen basierend auf dem Edge-Ort (da Edges auf einer Basisstationsebene, beispielsweise in einem Multi-Mandanten-Szenario, eingeschränktere Leistungsfähigkeit und Fähigkeiten aufweisen können); Konfigurationen basierend auf der Art von Rechen-, Kurzzeitspeicher-, Langzeitspeicher-, Fabric-, Beschleunigungs- oder ähnlichen Ressourcen, die Edge-Orten, Ebenen von Orten oder Gruppen von Orten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- sowie Orchestrierungsfähigkeiten; und zugehörige Zielsetzungen zum Erreichen der Nutzbarkeit und Leistung von Enddiensten. Diese Einsätze können eine Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Timing-Charakteristiken als „Near-Edge“-, „Close-Edge“-, „Lokal-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten betrachtet werden können.
  • Edge-Computing ist ein sich entwickelndes Paradigma, bei dem das Rechnen an oder näher an der „Edge“ eines Netzwerks ausgeführt wird, typischerweise durch die Verwendung einer zweckdienlich angeordneten Computing-Plattform (zum Beispiel x86, ARM, Nvidia oder einer anderen CPU/GPU-basierten Rechen-Hardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen umgesetzt ist, die sich viel näher an Endpunktvorrichtungen befinden, die Daten produzieren und verbrauchen. Edge-Gateway-Server können zum Beispiel mit Pools von Speicher- und Speicherungsressourcen ausgestattet sein, um Rechnen in Echtzeit für Verwendungsfälle mit niedriger Latenz (zum Beispiel autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen auszuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Nutzergeräte direkt zu verarbeiten, ohne weitere Daten über Backhaul-Netzwerke zu kommunizieren. Oder als ein anderes Beispiel kann Zentralamtnetzwerkverwaltungs-Hardware mit standardisierter Rechen-Hardware ersetzt werden, die virtualisierte Netzwerkfunktionen ausführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen anbietet. Alternativ kann auch eine Anordnung mit Hardware kombiniert mit virtualisierten Funktionen, allgemein als Hybrid-Anordnung bezeichnet, erfolgreich umgesetzt werden. Innerhalb von Edge-Rechennetzwerken kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „bewegt“ wird, sowie Szenarien, in denen die Daten zu der Rechenressource „bewegt“ werden. Oder als ein Beispiel können Basisstationsrechen-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um gemäß Arbeitslastbedürfnissen nach Bedarf durch Aktivieren inaktiver Kapazität (Subskription, Kapazität nach Bedarf) zu skalieren, um Ausnahmefälle und Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren umsetzten Lebenszyklus bereitzustellen.
  • 14 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. Insbesondere stellt 14 Beispiele für Rechennutzungsfälle 1405 dar, die Edge-Cloud 1310 unter mehreren veranschaulichenden Schichten von Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunktschicht (Vorrichtungen- und Dinge-Schicht) 1400, die auf die Edge-Cloud 1310 zugreift, um Datenanlegungs-, Analyse- und Datenverbrauchsaktivitäten auszuführen. Die Edge-Cloud 1310 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Vorrichtungen-Schicht 1410 mit Gateways, On-Premise-Servern oder Netzwerkgeräten (Knoten 1415), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 1420, die Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionale Datenzentren (DC) oder lokales Netzwerkgerät (Gerät 1425) umfasst; und beliebige Geräte, Vorrichtungen oder Knoten, die dazwischen liegen (in Schicht 1412, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 1310 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht abgebildet sind.
  • Beispiele für Latenz, die aus Netzwerkkommunikationsentfernungs- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn inmitten der Endpunktschicht 1400, unter 5 ms an der Edge-Vorrichtungen-Schicht 1410, bis sogar zwischen 10 und 40 ms reichen, wenn mit Knoten der Netzwerkzugangsschicht 1420 kommuniziert wird. Jenseits der Edge-Cloud 1310 befinden sich Schichten des Kernnetzwerks 1430 und des Cloud-Datenzentrums 1440, jeweils mit zunehmender Latenz (zum Beispiel zwischen 50 bis 60 ms an der Kernnetzwerkschicht 1430 bis 100 oder mehr ms an der Cloud-Datenzentrumsschicht). Infolgedessen werden Operationen in einem Kernnetzwerk-Datenzentrum 1435 oder einem Cloud-Datenzentrum 1445 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Verwendungsfälle 1405 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und - technologien die Latenzen weiter reduzieren kann. Bei einigen Beispielen können jeweilige Teile des Netzwerks in Bezug auf eine Netzwerkquelle und einen Netzwerkzielort als „Close-Edge“-, „Lokal-Edge“-, „Middle-Edge“-Schichten oder „Far-Edge“-Schichten kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetzwerk-Datenzentrums 1435 oder eines Cloud-Datenzentrums 1445 ein Zentralamt- oder Inhaltsdatennetzwerk als innerhalb einer „Near-Edge“-Schicht („nahe“ an der Cloud, mit hohen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Nutzungsfälle 1405 kommuniziert) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Vor-Ort-Server oder ein Netzwerk-Gateway als innerhalb einer „Far-Edge“-Schicht („fern“ von der Cloud entfernt, mit niedrigen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Nutzungsfälle 1405 kommuniziert) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als eine „nahe“, „lokale“, „nahe“,„ mittlere“ oder „ferne“ Edge bildend auf Latenz, Entfernung, Anzahl von Netzwerksprüngen oder anderen messbaren Charakteristiken basieren können, wie von einer Quelle in einer beliebigen der Netzwerkschichten 1400 bis 1440 gemessen.
  • Die diversen Nutzungsfälle 1405 können aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, auf Ressourcen unter Nutzungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 1310 ausgeführt werden, variierende Anforderungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS: Quality of Service) (zum Beispiel kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Antwortzeitanforderung aufweisen; oder eine Leistungsfähigkeitsempfindlichkeit/-engstelle kann an einer Rechen-/Beschleuniger-, Kurzzeitspeicher-, Langzeitspeicher- oder Netzwerkressource in Abhängigkeit von der Anwendung existieren); (b) Zuverlässigkeit und Widerstandsfähigkeit (zum Beispiel müssen einige Eingangsströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wohingegen einige andere Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physische Beschränkungen (zum Beispiel Leistung, Kühlung und Formfaktor).
  • Die Ende-zu-Ende-Dienstansicht für diese Nutzungsfälle beinhaltet das Konzept eines Dienstflusses und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstanforderung für die Instanz an, die den Dienst beansprucht, sowie die assoziierten Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Geschäftsfunktions- und Geschäftsebenenanforderungen. Die Dienste, die mit den beschriebenen „Begriffen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn eine Komponente in der Transaktion ihre vereinbarte SLA verfehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten in dem System zu erweitern, um die gesamte Transaktions-SLA wiederaufzunehmen, und (3) Schritte umzusetzen, um Abhilfe zu schaffen.
  • Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 1310 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 1405 (zum Beispiel Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu bedienen und auf diese zu reagieren und Anforderungen an ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganze neue Klasse von Anwendungen (VNFs (Virtual Network Functions), Function as a Service (FaaS), Edge as a Service (EaaS), Standardprozesse usw.), die ein herkömmliches Cloud-Computing aufgrund von Latenz oder anderen Einschränkungen nicht nutzen können.
  • Mit den Vorteilen der Edge-Computing ergeben sich jedoch die folgenden Vorbehalte. Die am Rand befindlichen Geräte sind häufig ressourcenbeschränkt, so dass Druck auf die Nutzung von Edge-Ressourcen besteht. Typischerweise wird dies durch das Zusammenlegen von Speicher und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Die Edge kann hinsichtlich von Leistung und Kühlung eingeschränkt sein, so dass der Leistungsverbrauch durch die Anwendungen, die am meisten Leistung verbrauchen, berücksichtigt werden muss. Es kann bei diesen gepoolten Speicherressourcen inhärente Leistungsleistungsfähigkeits-Kompromisse geben, da viele von ihnen wahrscheinlich entstehende Speichertechnologien verwenden, bei welchen mehr Leistung eine größere Speicherbandbreite benötigt. Ebenso sind verbesserte Sicherheit von Hardware und Vertrauensankerfunktionen auch erforderlich, weil Edge-Orte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (zum Beispiel wenn sie an einem Drittparteiort untergebracht sind). Derartige Probleme werden in der Edge-Cloud 1310 in einer Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffseinstellung verstärkt, in der Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Stakeholder, Verwendungsfälle und Dienste ändert.
  • Auf einer generischeren Ebene kann ein Edge-Computing-System derart beschrieben werden, dass es eine beliebige Anzahl von Einsätzen an den zuvor besprochenen Schichten umfasst, die in der Edge-Cloud 1310 arbeiten (Netzwerkschichten 1400 bis 1440), die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kerndatenzentren können über Schichten des Netzwerks verteilt sein, um eine Umsetzung des Edge-Datenverarbeitungssystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („telco“ oder „TSP“), Internet-der-Dinge-Dienstanbieter, Cloud-Dienstanbieter (CSP), Unternehmensentität oder eine beliebige andere Anzahl von Entitäten bereitzustellen. Verschiedene Umsetzungen und Konfigurationen des Edge-Computing-Systems können dynamisch bereitgestellt werden, wie etwa wenn orchestriert, um Dienstzielsetzungen zu erfüllen.
  • Im Einklang mit den vorliegend bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -einrichtung, -gerät oder andere Sache verkörpert sein, die in der Lage ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Hier verweist ein „Erzeuger“ auf eine Entität oder ein Element, die/das andere Entitäten oder Elemente auf demselben Edge-Knoten oder auf unterschiedlichen Edge-Knoten einen Dienst bereitstellt, und ein „Verbraucher“ verweist auf eine Entität oder ein Element, die/das Endbenutzerverkehr und/oder Benutzerdienste von einem Erzeuger auf demselben oder unterschiedlichen Edge-Knoten verbrauchen kann. Zum Beispiel kann eine Erzeuger-App Ortsdienste, Abbildungsdienste, Transcodierungsdienste, AI/ML-Dienste und/oder andere ähnliche Dienste bereitstellen. Zusätzlich oder alternativ kann eine Verbraucher-App ein Content-Delivery-Network-Knoten (CDN-Knoten), AR- oder VR-Apps, Gaming-Apps und/oder eine andere Art von App sein. Weiter bedeutet das Label „Knoten“ oder „Vorrichtung“, wie es in dem Edge-Computing-System verwendet wird, nicht notwendigerweise, dass ein derartiger Knoten oder dieses Gerät in einer Client- oder Agent-/Minion-/Folgerrolle arbeitet; vielmehr verweisen beliebige der Knoten oder Vorrichtungen in dem Edge-Computing-System auf einzelne Entitäten, Knoten oder Subsysteme, die getrennte oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 1310 zu erleichtern oder zu verwenden.
  • Daher ist die Edge-Cloud 1310 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die von und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Computing-Knoten unter den Netzwerkschichten 1410-1430 betrieben werden. Die Edge-Cloud 1310 kann somit als eine beliebige Art von Netzwerk verkörpert sein, das Edge-Computing- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von funkzugangsnetzwerkfähigen (RAN-fähigen) Endpunktvorrichtungen (zum Beispiel Mobilcomputervorrichtungen, IoT-Vorrichtungen, Smartvorrichtungen usw.) befinden, die hierin besprochen werden. Mit anderen Worten kann die Edge-Cloud 1310 als ein „Rand“ gedacht werden, der die Endpunkteinrichtungen und traditionelle Netzwerkzugangspunkte, die als ein Eingangspunkt in Dienstanbieter-Kernnetzwerke dienen, verbindet, einschließlich Mobilträgernetzwerken (zum Beispiel Global System for Mobile Communications-Netzwerke (GSM-Netzwerke), Long-Term Evolution-Netzwerke (LTE-Netzwerke), 5G/6G-Netzwerke usw.), während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (zum Beispiel WiFi, Langstrecken-Wireless, verdrahtete Netzwerke, einschließlich optischer optischer Netzwerke) können auch an Stelle von oder in Kombination mit derartigen 3GPP-Trägernetzen genutzt werden.
  • Die Netzwerkkomponenten der Edge-Cloud 1310 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Datenverarbeitungsvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 1310 eine Geräterechenvorrichtung beinhalten, die eine eigenständige elektronische Einrichtung mit einem Gehäuse, einem Chassis, einer Verkleidung oder einer Schale ist. Unter Umständen kann das Gehäuse für Portabilität derart dimensioniert sein, dass es von einem Menschen getragen und/oder versandt werden kann. Alternativ kann es sich beispielsweise um ein kleineres Modul handeln, das zum Einbau in ein Fahrzeug geeignet ist. Beispielhafte Gehäuse können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (zum Beispiel EMI, Vibration, extreme Temperaturen) beinhalten kann und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Gehäuse können Leistungsschaltkreise beinhalten, um Leistung für stationäre und/oder tragbare Umsetzungen bereitzustellen, wie etwa AC-Leistungseingänge, DC-Leistungseingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltkreise, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Kleinere modulare Umsetzungen können auch eine erweiterbare oder eingebettete Antennenanordnung für drahtlose Kommunikation beinhalten. Beispielhafte Gehäuse und/oder Oberflächen davon können Montage-Hardware beinhalten oder mit dieser verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (zum Beispiel Masten, Antennenstrukturen usw.) und/oder Racks (zum Beispiel Server-Racks, Blade-Befestigungen usw.), zu ermöglichen. Beispielhafte Gehäuse und/oder Oberflächen davon können einen oder mehrere Sensoren (zum Beispiel Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, kapazitive Sensoren, Näherungssensoren usw.) unterstützen. Ein oder mehrere derartige Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderswie eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Gehäuse und/oder Oberflächen davon können mechanische Konnektivität unterstützen, wie etwa Antriebs-Hardware (zum Beispiel Räder, Propeller usw.) und/oder Gelenk-Hardware (zum Beispiel Roboterarme, schwenkbare Fortsätze usw.). Unter einigen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellen-Hardware zum Beispiel Tasten, Schalter, Wählscheiben, Schieber usw.). Unter einigen Umständen beinhalten beispielhafte Gehäuse Ausgabevorrichtungen, die in diesen enthalten, von diesen getragen, in diese eingebettet und/oder an diesen angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Ports (zum Beispiel USB) usw. beinhalten. Unter einigen Umständen sind Edge-Vorrichtungen Vorrichtungen, die in dem Netzwerk für einen spezifischen Zweck (zum Beispiel eine Ampel) präsentiert werden, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Derartige Edge-Einrichtungen können unabhängig von anderen vernetzten Einrichtungen sein und können mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für seinen primären Zweck geeignet ist; aber dennoch für andere Rechenaufgaben, die ihre primäre Aufgabe nicht stören, verfügbar ist. Edge-Vorrichtungen umfassen auch Internet-der-Dinge-Vorrichtungen. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Probleme, wie etwa Vorrichtungstemperatur, Vibration, Ressourcennutzung, Aktualisierungen, Stromprobleme, physische und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Umsetzen einer Geräterechenvorrichtung ist in Verbindung mit 32 beschrieben. Die Edge-Cloud 1310 kann auch einen oder mehrere Server und/oder einen oder mehrere Server mit mehreren Mandanten beinhalten. Ein derartiger Server kann ein Betriebssystem beinhalten und eine virtuelle Rechenumgebung umsetzen. Eine virtuelle Rechenumgebung kann einen Hypervisor beinhalten, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (zum Beispiel Hervorbringen, Einsetzen, Zerstören usw.). Derartige virtuellen Computing-Umgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, Code oder Skripte ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
  • In 15 tauschen verschiedene Client-Endpunkte 1510 (in Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 1510 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 1522 durch ein Vor-Ort-Netzwerksystem 1532 ausgetauscht werden. Einige Client-Endpunkte 1510, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 1524 durch einen Zugangspunkt zum Beispiel Mobilfunkturm) 1534 ausgetauscht werden. Einige Client-Endpunkte 1510, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anfragen und Antworten 1526 über ein drahtloses Fahrzeugnetzwerk durch ein Straßennetzwerksystem 1536 erhalten. Ungeachtet der Art des Netzwerkzugangs, kann der TSP jedoch Aggregationspunkte 1542, 1544 innerhalb der Edge-Cloud 1310 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 1310 verschiedene Rechen- und Speicherressourcen einsetzen, wie etwa an Edge-Aggregationsknoten 1540, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 1540 und andere Systeme der Edge-Cloud 1310 sind mit einer Cloud oder einem Datenzentrum 1560 verbunden, die/das ein Backhaul-Netzwerk 1550 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 1540 und der Aggregationspunkte 1542, 1544, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 1310 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
  • 16 veranschaulicht Einsatz und Orchestrierung für virtualisierte und containerbasierte Edge-Konfigurationen über ein Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten (zum Beispiel Benutzern, Anbietern), die derartige Edge-Knoten verwenden, betrieben wird. Insbesondere bildet 16 eine Koordination eines ersten Edge-Knotens 1622 und eines zweiten Edge-Knotens 1624 in einem Edge-Computing-System 1600 ab, um Anforderungen und Antworten für verschiedene Client-Endpunkte 1610 (zum Beispiel Smart-Städte / -Gebäudesysteme, Mobilvorrichtungen, Rechenvorrichtungen, Geschäfts-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hier stellen die virtuellen Edge-Instanzen 1632, 1634 Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf ein Cloud-/Datenzentrum 1640 für Anfragen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Instanzen.
  • In 16 beinhalten diese virtuellen Edge-Instanzen: eine erste virtuelle Edge-11632, die einem ersten Mandanten (Mandanten 1) angeboten wird, der eine erste Kombination aus Edge-Speicherung, Berechnung und Diensten anbietet; und eine zweite virtuelle Edge 1634, die eine zweite Kombination aus Edge-Speicherung, Berechnung und Diensten anbietet. Die virtuellen Edge-Instanzen 1632, 1634 sind unter den Edge-Knoten 1622, 1624 verteilt und können Szenarien beinhalten, in denen eine Anforderung und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 1622, 1624 zum Arbeiten auf verteilte, aber koordinierte Weise erfolgt auf Grundlage von Edge-Bereitstellungsfunktionen 1650. Die Funktionalität der Edge-Knoten 1622, 1624 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 1660 statt.
  • Einige der Vorrichtungen 1610 sind Multi-Mandanten-Vorrichtungen, wobei Mandant 1 innerhalb eines Tenantl-„Slice“ funktionieren kann, während ein Mandant 2 innerhalb eines Tenant2-Slice funktionieren kann (und bei weiteren Beispielen zusätzliche oder Unter-Mandanten existieren können; und jeder Mandant sogar spezifisch berechtigt und transaktionell an einen spezifischen Satz von Merkmalen durchgehend an spezifische Hardwaremerkmale gebunden sein kann). Eine vertrauenswürdige Multi-Mandanten-Vorrichtung kann weiter einen mandantenspezifischen kryptografischen Schlüssel enthalten, sodass die Kombination aus Schlüssel und Slice als ein Vertrauensanker (eine „Root of Trust“ - RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann weiter dynamisch unter Verwenden einer DICE-Architektur (Device Identity Composition Engine-Architektur) berechnet werden, so dass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein frei programmierbares Gate-Array (FPGA)) aufzubauen. Die RoT kann weiter für einen vertrauenswürdigen Rechenkontext verwendet werden, um einen „Fan-Out“ zu ermöglichen, der zum Unterstützen von Multi-Mandanten-Fähigkeit nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 1622, 1624 als Sicherheitsmerkmal-Durchsetzungspunkte für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugeordnet sind. Zusätzlich können Mandantenlaufzeit- und Anwendungsausführung (zum Beispiel in den Instanzen 1632, 1634) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 1660 an einer Orchestrierungsinstanz als ein Sicherheitsmerkmal-Durchsetzungspunkt zum Ordnen von Ressourcen entlang Mandantengrenzen arbeiten.
  • Edge-Computing-Knoten können Ressourcen (Speicher, Zentraleinheit (CPU), Grafikverarbeitungseinheit (GPU), Interrupt-Steuervorrichtung, Eingabe/Ausgabe-Steuervorrichtung (E/A-Steuervorrichtung), Speichersteuervorrichtung, Bussteuervorrichtung usw.) partitionieren, wobei jeweilige Partitionierungen eine RoT-Fähigkeit umfassen können und wobei Fan-Out und Schichtung gemäß einem DICE-Modell weiter auf Edge-Knoten angewandt werden können. Cloud-Rechenknoten verwenden häufig Container, FaaS-Engines, Servlets, Server oder eine andere Berechnungsabstraktion, die gemäß einer DICE-Schichtung und Fan-Out-Struktur partitioniert werden können, um jeweils einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen RoTs-Überspannvorrichtungen 1610, 1622 und 1640, die RoTs überspannen, die Erstellung einer verteilten vertrauenswürdigen Rechenbasis (Distributed Trusted Computing Base DTCB) derart koordinieren, dass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente Ende-zu-Ende verknüpft, erstellt werden kann.
  • Weiter versteht es sich, dass ein Container daten- oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorhergehenden Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuervorrichtung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Ziel-Edge-Knoten-Pod-Steuervorrichtung erhalten, wobei der Migrationsschlüssel zum Verpacken der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zum Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuervorrichtung offenbart, die dann die verpackten Schlüssel entschlüsselt. Die Schlüssel können nun zur Ausführung von Operationen auf containerspezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt attestierte Edge-Knoten und Pod-Manager (wie oben beschrieben) torgesteuert werden.
  • Bei weiteren Beispielen wird ein Edge-Computing-System erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer geschlossenen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung bereitzustellen. Ein mandantenfähiger Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen „Slice“-Konzepts in 16 auszuführen. Beispielsweise kann ein Edge-Computing-System dazu konfiguriert sein, Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einem Cloud- oder Remote-Datenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (zum Beispiel Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Rechen-Offload) gleichzeitig unterstützen. Weiter kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (zum Beispiel normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Networking-Anwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geografischen Orten (oder jeweiligen Rechensysteme und Ressourcen, die von mehreren Eigentümern gemeinsam besessen oder gemeinsam verwaltet werden) verteilt sein.
  • Beispielsweise kann jeder Edge-Knoten 1622, 1624 die Verwendung von Containern umsetzen, wie etwa unter Verwenden eines Container-„Pods“ 1626, 1628, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einem Szenario, das einen oder mehrere Container-Pods verwendet, ist eine Pod-Steuervorrichtung oder ein Pod-Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (zum Beispiel Speicherung, Rechnen, Dienste, dargestellt mit Sechsecken), die für die jeweiligen Edge-Segmente 1632, 1634 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
  • Bei der Verwendung von Container-Pods beaufsichtigt eine POD-Steuerung die Partitionierung und Zuordnung von Containern und Ressourcen. Die Pod-Steuervorrichtung empfängt Anweisungen von einem Orchestrator (zum Beispiel Orchestrator 1660), die die Steuervorrichtung darüber anweisen, wie physische Ressourcen am besten zu partitionieren sind und für welche Dauer, wie etwa durch Empfangen von Leistungsfähigkeits-Indikator-Zielen (KPI-Zielen) basierend auf SLA-Verträgen. Die Pod-Steuervorrichtung bestimmt, welcher Container welche Ressourcen und wie lange benötigt, um die Arbeitslast zu vollenden und die SLA zu erfüllen. Die Pod-Steuervorrichtung verwaltet auch Containerlebenszyklusoperationen, wie: Anlegen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam an einer verteilten Anwendung arbeiten, Abbauen von Containern, wenn die Arbeitslast vollendet ist, und dergleichen. Zusätzlich kann eine Pod-Steuervorrichtung in einer Sicherheitsrolle dienen, die eine Zuweisung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Attestierungsergebnis erfüllt ist.
  • Auch bei der Verwendung von Container-Pods können immer noch Mandantengrenzen existieren, aber im Kontext jedes Pod von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuervorrichtung aufweist, gibt es eine gemeinsam genutzte Pod-Steuerung, die Ressourcenzuordnungsanfragen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Attestierung und Vertrauenswürdigkeit des Pods und der Pod-Steuervorrichtung sicherzustellen. Beispielsweise kann der Orchestrator 1660 lokalen Pod-Steuerungen, die eine Attestierungsprüfung ausführen, eine Attestierungsprüfungsrichtlinie bereitstellen. Falls eine Attestierung eine Richtlinie für eine erste Mandanten-Pod Steuervorrichtung, aber nicht eine zweite Mandanten-POD-Steuervorrichtung erfüllt, könnte der zweite Pod zu einem unterschiedlichen Edge-Knoten, der ihn erfüllt, migriert werden. Alternativ kann die Ausführung des ersten Pod erlaubt werden, und eine unterschiedliche gemeinsam genutzte Pod-Steuervorrichtung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
  • 17 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Computing-System einsetzen. Als ein vereinfachtes Beispiel bilden die Systemanordnungen 1710, 1720 Einstellungen ab, bei denen eine Pod-Steuervorrichtung (zum Beispiel Containermanager 1711, 1721 und Containerorchestrator 1731) dazu angepasst ist, containerisierte Pods, Funktionen, und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten 1715 in Anordnung 1710 getrennt auszuführen oder containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten 1723 in Anordnung 1720 getrennt auszuführen. Diese Anordnung ist zur Verwendung von Multi-Mandanten in der Systemanordnung 1730 (unter Verwenden von Rechenknoten 1737) angepasst, wobei containerisierte Pods (zum Beispiel Pods 1712), Funktionen (zum Beispiel Funktionen 1713, VNFs 1722, 1736), und Funktions-as-a-Service-Instanzen (zum Beispiel FaaS-Instanz 1714) innerhalb virtueller Maschinen (zum Beispiel VMs 1734, 1735 für Mandanten 1732, 1733) gestartet werden, die für jeweilige Mandanten spezifisch sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist weiter zur Verwendung in der Systemanordnung 1740 angepasst, die Container 1742, 1743 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 1744 bereitstellt, wie von einem containerbasierten Orchestrierungssystem 1741 koordiniert.
  • Die in 17 abgebildeten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen gleichermaßen hinsichtlich der Anwendungszusammensetzung behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger-Komponenten (FPGA, ASIC) als ein lokales Backend beinhalten. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer koordiniert von einem Orchestrator aufgeteilt werden,.
  • In dem Kontext der 17 können die Pod-Steuervorrichtung/der Containermanager, der Containerorchestrator und die individuellen Knoten einen Sicherheitsdurchsetzungspunkt bereitstellen. Die Mandantentrennung kann jedoch orchestriert werden, wo die Ressourcen, die einem Mandanten zugeordnet werden, von Ressourcen getrennt sind, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass Ressourcenzuordnungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuordnungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ über eine Subskriptions- oder Transaktions-/Vertragsbasis erlauben könnten. In diesen Kontexten können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemata von Edge-Eigentümern verwendet werden, um den Mandantenzustand durchzusetzen. Andere Isolationsumgebungen können beinhalten: (dedizierte) Bare-Metal-Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
  • Bei weiteren Beispielen können Aspekte von softwaredefinierter oder -gesteuerter Eigentümer-Hardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Computing-Systems integrieren. Softwaredefiniertes Silizium (Software Defined Silicon - SDSi) kann verwendet werden, um die Fähigkeit für einige Ressourcen- oder Hardwarebestandteile sicherzustellen, einen Vertrag oder eine Dienstgütevereinbarung, basierend auf der Fähigkeit des Bestandteils, einen Teil seiner selbst oder die Arbeitslast nachzubessern (zum Beispiel durch eine Aktualisierung, Neukonfiguration oder Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst), zu erfüllen.
  • 18 zeigt eine beispielhafte Anordnung, bei der die hierin besprochenen Edge-Computing-Systeme und Anordnungen bei verschiedenen Lösungen, Diensten und/oder Verwendungsfällen, die Mobilität involvieren, anwendbar sein können. 18 zeigt einen Fahrzeugberechnungs- und Kommunikationsnutzungsfall, der mobilen Zugriff auf Anwendungen in einem Edge-Computing-System 1800, das eine Edge-Cloud 1310 umsetzt, involviert. Bei diesem Verwendungsfall können jeweilige Client-Rechenknoten 1810 als fahrzeuginterne Rechensysteme (zum Beispiel fahrzeuginterne Navigations- und/oder Infotainmentsysteme) verkörpert sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gateway-Knoten 1820 während des Befahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 1820 in einem Schrank am Straßenrand oder einem anderen Gehäuse befinden, das in eine Struktur eingebaut ist, die einen anderen, separaten, mechanischen Nutzen aufweist, das entlang der Straße, an Kreuzungen der Straße oder anderen Orten nahe der Straße platziert werden kann. Wenn jeweilige Fahrzeuge entlang der Straße fahren, kann sich die Verbindung zwischen ihrem Client-Rechenknoten 1810 und einer speziellen Edge-Gateway-Vorrichtung 1820 propagieren, um eine konsistente Verbindung und einen konsistenten Kontext für den Client-Rechenknoten 1810 aufrechtzuerhalten. Ebenso können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsanforderungen für den oder die zugrunde liegenden Dienste aggregieren (zum Beispiel im Fall von Drohnen). Die jeweiligen Edge-Gateway-Vorrichtungen 1820 beinhalten eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und daher können einige Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 1810 auf einer oder mehreren der Edge-Gateway-Vorrichtungen 1820 ausgeführt werden.
  • Die Edge-Gateway-Vorrichtungen 1820 können mit einem oder mehreren Edge-Ressourcenknoten 1840 kommunizieren, die veranschaulichend als Rechenserver, -geräte oder - komponenten verkörpert sind, die sich an oder in einem Netzwerkzugangsknoten (NAN) 1842 (zum Beispiel einer Basisstation eines zellularen Netzwerks) befinden. Wie oben besprochen, beinhalten die jeweiligen Edge-Ressourcenknoten 1840 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und somit können einige Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 1810 auf dem Edge-Ressourcenknoten 1840 ausgeführt werden. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, von dem Edge-Ressourcenknoten 1840 ausgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, von den Edge-Gateway-Vorrichtungen 1820 ausgeführt werden kann (zum Beispiel in Abhängigkeit von den Fähigkeiten jeder Komponente oder von Informationen in der Anforderung, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenort oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Ebenso können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (zum Beispiel von einem lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um dem neuen Bedarf zu gerecht zu werden (zum Beispiel Anpassen der Rechenressourcen an die Arbeitslastdaten).
  • Der eine oder die mehreren Edge-Ressourcenknoten 1840 kommunizieren auch mit dem Kernrechenzentrum 1850, das Rechenserver, Geräte und/oder andere Komponenten beinhalten kann, die sich an einem zentralen Ort (zum Beispiel einer Zentrale eines Mobilfunkkommunikationsnetzwerks) befinden. Das Kerndatenzentrum 1850 kann ein Gateway zu der globalen Netzwerk-Cloud 1860 (zum Beispiel Internet) für die Operationen der Edge-Cloud 1310, die von dem einen oder den mehreren Edge-Ressourcenknoten 1840 und der Edge-Gateway-Vorrichtungen 1820 gebildet werden, bereitstellen. Zusätzlich kann das Kerndatenzentrum 1850 bei einigen Beispielen eine Menge an Verarbeitungs- und Speicherungsfähigkeiten beinhalten, und somit kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kerndatenzentrum 1850 ausgeführt werden (zum Beispiel Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
  • Die Edge-Gateway-Knoten 1820 oder die Edge-Ressourcenknoten 1840 können die Verwendung zustandsorientierter Anwendungen 1832 und einer geografischen verteilten Datenbank 1834 anbieten. Obwohl die Anwendungen 1832 und die Datenbank 1834 als horizontal auf einer Schicht der Edge-Cloud 1310 verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste, oder andere Komponenten der Anwendung vertikal über die Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, die an dem Client-Rechenknoten 1810 ausgeführt wird, anderer Teile an den Edge-Gateway-Knoten 1820 oder den Edge-Ressourcen-Knoten 1840 usw.). Wie außerdem zuvor erwähnt, kann es auf jeder Ebene Peer-Beziehungen geben, um Dienstzielsetzungen und Verpflichtungen zu erfüllen. Weiter können sich die Daten für einen speziellen Client oder eine spezielle Anwendung basierend auf sich ändernden Bedingungen von Edge zu Edge bewegen (zum Beispiel basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.). Beispielsweise kann basierend auf der „Abklingrate“ des Zugriffs eine Vorhersage getroffen werden, um den nächsten Eigentümer zu identifizieren, der fortsetzen soll, oder wann die Daten oder der rechnerische Zugang nicht mehr sinnvoll sein werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die benötigt wird, um die Transaktion konform und verlustfrei zu halten.
  • Bei weiteren Szenarien kann ein Container 1836 (oder ein Pod von Containern) flexibel von einem Edge-Knoten 1820 zu anderen Edge-Knoten (zum Beispiel 1820, 1840 usw.) migriert werden, so dass der Container mit einer Anwendung und Arbeitslast nicht rekonstituiert, rekompiliert, reinterpretiert werden muss, damit Migration funktioniert. Bei derartigen Einstellungen kann es jedoch einige Abhilfe oder „Swizzling“-Übersetzungsoperationen geben, die angewandt werden. Zum Beispiel kann sich die physische Hardware an dem Knoten 1840 von dem Edge-Gateway-Knoten 1820 unterscheiden, und daher wird die Hardware-Abstraktionsschicht (HAL), die den unteren Rand des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann irgendeine Form einer späten Bindungstechnik beinhalten, wie etwa binäre Übersetzung der HAL von dem nativen Containerformat in das physische Hardwareformat, oder kann Abbildungsschnittstellen und - Operationen beinhalten. Eine Pod-Steuervorrichtung kann verwendet werden, um die Schnittstellenabbildung als Teil des Containerlebenszyklus zu treiben, was Migration zu/von unterschiedlichen Hardwareumgebungen beinhaltet.
  • Die Szenarien, die in 18 umfasst sind, können verschiedene Arten mobiler Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Pkw/Lastkraftwagen/Straße/Zug) gehostet ist, oder eine andere mobile Einheit, da sich der Edge-Knoten zu anderen geografischen Orten entlang der Plattform, die ihn hostet, bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (um zum Beispiel Caching, Berichten, Datenaggregation usw. auszuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Einstellungen verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunkteinrichtungen oder den Edge-Gateway-Knoten 1820, einigen anderen an dem Edge-Ressourcenknoten 1840 und anderen in dem Kerndatenzentrum 1850 oder der globalen Netzwerk-Cloud 1860.
  • Bei weiteren Konfigurationen kann das Edge-Computing-System FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen umsetzen. Bei einem Beispiel schreibt ein Entwickler Funktionscode (hier zum Beispiel „Computercode“), der eine oder mehrere Computerfunktionen darstellt, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel von einem Edge-Knoten oder einem Datenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstanwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
  • Bei einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (zum Beispiel eine Anwendung, die von einem Drittanbieter bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie ein Prozess, ein Docker- oder Kubernetes-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Computing-Systems werden verschiedene Rechenzentrum-, Edge- und Endpunktvorrichtungen (einschließlich Mobileinrichtungen) verwendet, um Funktionen „hochzufahren“ (zum Beispiel Funktionshandlungen zu aktivieren und/oder zuzuordnen), die nach Bedarf skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (zum Beispiel Edge-Computing-Knoten) und darunterliegenden virtualisierten Containern ausgeführt. Schließlich wird Container auf der Infrastruktur als Reaktion darauf, dass die Ausführung abgeschlossen ist, „heruntergefahren“ (zum Beispiel deaktiviert und/oder freigegeben).
  • Weitere Aspekte von FaaS können das Einsetzen von Edge-Funktionen auf eine Dienstart ermöglichen, einschließlich einer Unterstützung jeweiliger Funktionen, die Edge-Computing als einen Dienst unterstützen (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können beinhalten: eine granuläre Abrechnungskomponente, die es Kunden (zum Beispiel Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen individuellen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, bereits eingesetzt oder betrieben, versus „kalt“, die Initialisierung, Einsatz oder Konfiguration erfordern).
  • Das Edge-Computing-System 1800 kann einen Edge-Bereitstellungsknoten 1844 beinhalten oder mit diesem in Kommunikation stehen. Der Edge-Bereitstellungsknoten 1844 kann Software, wie etwa die beispielhaften computerlesbaren Anweisungen 3282 der 32, an verschiedene Empfangsteilnehmer zum Umsetzen eines beliebigen der hierin beschriebenen Verfahren verteilen. Der beispielhafte Edge-Bereitstellungsknoten 1844 kann von einem beliebigen Computerserver, einem beliebigen Heimserver, einem beliebigen Inhaltslieferungsnetzwerk, einem virtuellen Server, einem Softwareverteilungssystem, einer zentralen Einrichtung, einer Speichervorrichtung, einer Speicherplatte, einem beliebigen Speicherknoten, Dateneinrichtung, Cloud-Dienst usw., die in der Lage sind, Softwareanweisungen (zum Beispiel Code, Skripte, ausführbare Binärprogramme, Container, Pakete, komprimierte Dateien und/oder Ableitungen davon) zu anderen Rechenvorrichtungen zu speichern und/oder zu übertragen, umgesetzt werden. Komponente(n) des beispielhaften Edge-Bereitstellungsknotens 644 können sich in einer Cloud, in einem lokalen Netzwerk, in einem Edge-Netzwerk, in einem Weitverkehrsnetzwerk, im Internet und/oder an einem beliebigen anderen Ort, der kommunikativ mit der/den Empfangspartei(en) gekoppelt ist, befinden. Die Empfangsteilnehmer können Kunden, Clients, Partner, Benutzer usw. der Entität sein, die den Edge-Bereitstellungsknoten 1844 besitzt und/oder betreibt. Beispielsweise kann die Entität, die den Edge-Bereitstellungsknoten 1844 besitzt und/oder betreibt, ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber (oder ein Kunde und/oder Verbraucher davon) von Softwareanweisungen, wie etwa den beispielhaften computerlesbaren Anweisungen 3282 der 32, sein. Die Empfangsteilnehmer können Verbraucher, Dienstanbieter, Benutzer, Einzelhändler, OEMs usw. sein, die die Softwareanweisungen zur Verwendung erwerben und/oder in Lizenz vergeben und/oder weiterverkaufen und/oder oder in Unterlizenz vergeben.
  • Bei einem Beispiel beinhaltet der Edge-Bereitstellungsknoten 1844 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen/-platten. Die Speichervorrichtungen und/oder Speicherplatten hosten computerlesbare Anweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 3282 der 32, wie unten beschrieben. Ähnlich den oben beschriebenen Edge-Gateway-Vorrichtungen 1820, stehen der eine oder die mehreren Server des Edge-Bereitstellungsknotens 1844 in Kommunikation mit einem NAN 1842 oder einer anderen Netzwerkkommunikationsentität. Bei einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Softwareanweisungen als Teil einer kommerziellen Transaktion an eine anfordernde Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Softwareanweisungen kann von dem einen oder den mehreren Servern der Softwareverteilungsplattform und/oder über eine Drittpartei-Zahlungsentität gehandhabt werden. Die Server ermöglichen es Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 3282 von dem Edge-Bereitstellungsknoten 1844 herunterzuladen. Zum Beispiel können die Softwareanweisungen, die den beispielhaften computerlesbaren Anweisungen 3282 der 32 entsprechen können, auf die beispielhafte(n) Prozessorplattform(en) heruntergeladen werden, die die computerlesbaren Anweisungen 3282 ausführen sollen, um die hierin beschriebenen Verfahren umzusetzen.
  • Bei einigen Beispielen können sich die Prozessorplattform(en), die die computerlesbaren Anweisungen 3282 ausführen, physisch an unterschiedlichen geografischen Orten, gerichtlichen Zuständigkeiten usw. befinden. Bei einigen Beispielen bieten ein oder mehrere Server des Edge-Bereitstellungsknotens 1844 periodisch Aktualisierungen an, übertragen und/oder erzwingen Aktualisierungen an den Softwareanweisungen (zum Beispiel die beispielhaften computerlesbaren Anweisungen 3282 der 32), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Softwareanweisungen, die an den Endbenutzervorrichtungen umsetzt sind, angewandt werden. Bei einigen Beispielen können unterschiedliche Komponenten der computerlesbaren Anweisungen 3282 von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden; zum Beispiel können unterschiedliche Bibliotheken, Plug-ins, Komponenten und andere Typen von Rechenmodulen, ob kompiliert oder interpretiert, von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden. Zum Beispiel kann ein Teil der Softwareanweisungen (zum Beispiel ein Skript, das an sich nicht ausführbar ist) von einer ersten Quelle verteilt werden, während ein Interpreter (der in der Lage ist, das Skript auszuführen) von einer zweiten Quelle verteilt werden kann.
  • 2.1. 3GPP-EDGE-COMPUTING-ASPEKTE
  • 5G-Netzwerke erstrecken sich über die traditionellen mobilen Breitbanddienste hinaus, um verschiedene neue Dienste bereitzustellen, wie etwa IoT, industrielle Steuerung, autonomes Fahren, missionskritische Kommunikationen usw., die aufgrund von Sicherheits- und Leistungsfähigkeitsbedenken ultraniedrige Latenz, ultrahohe Zuverlässigkeit und hohe Datenkapazitätsanforderungen aufweisen können. Das Edge-Computing-Merkmal wurde in der 5GC-Systemarchitektur in 3GPP TS 23.501 v16.7.0 (2020-12-17) („[TS23501]“) hinzugefügt, um derartige Dienste durch Hosten einiger Anwendungen näher im lokalen Datennetzwerk zu unterstützen, um die Ende-zu-Ende-Latenz und die Last im Transportnetzwerk zu reduzieren.
  • 19 bildet eine Übersicht über eine 3GPP-Edge-Computing 1900 ab, die Edge-Computing-Fähigkeiten beinhaltet, die von 3GPP unterstützt werden. Zum Edge-Computing sind die Anwendungs-Clients (ACs) in der Lage, einen am besten geeigneten Anwendungsserver, der in dem Edge-Datennetzwerk (EDN) verfügbar ist, in Abhängigkeit von den Erfordernissen der Anwendung zu lokalisieren und mit diesem zu verbinden. Die Edge-Enabler-Schicht 1910 deckt APIs auf, um die Edge-Computing-Fähigkeiten zu unterstützen. Die Anwendungsschicht 1920 ist ein Verbraucher 3GPP-spezifizierter Edge-Computing-Fähigkeiten. Die 3GPP-Edge-Computing-Fähigkeiten können wie folgt organisiert sein: Edge-Aktivierungsschicht 1910 (siehe zum Beispiel [TS23558]); Edge-Hosting-Umgebung 1930; 3GPP-Transportschicht 1940 (siehe zum Beispiel 3GPP-TS 23.401 v16.9.0 (2020-12-17)und [TS23501]); und Edge-Verwaltungsschicht 1950. Die Merkmale der Edge-Aktivierungsschicht 1910 beinhalten Dienstbereitstellung, Registrierung, EAS-Entdeckung, Fähigkeitsaufdeckung gegenüber EAS, Sicherheit und dynamische EAS-Installation 2150.
  • Dienstbereitstellungsvorgehensweisen liefern die Informationen, die von einem UE 111 benötigt werden, um auf die Edge-Dienste zuzugreifen. Die Prozedur berücksichtigt den Ort des UE 111, Dienstanforderungen, Dienstepräferenzen und Konnektivitätsinformationen, um die erforderliche Konfiguration bereitzustellen. Dienstbereitstellungsvorgehensweisen sind in Klausel 8.3 von [TS23558] spezifiziert. Registrierungsvorgehensweisen, die in Klausel 8.4 von [TS23558] spezifiziert sind, erlauben es Entitäten (zum Beispiel UE 111 und Anwendungsserver) in der Edge-Aktivierungsschicht 1910, Informationen über sich selbst anderen Entitäten der Edge-Aktivierungsschicht 1910 bereitzustellen. Die Entdeckungsvorgehensweisen des EAS 2150 ermöglichen dem UE 111, Informationen über geeignete EAS 2150 von Interesse (zum Beispiel spezifiziert als Entdeckungsfilter) in der EDN zu erhalten; Entdeckungsvorgehensweisen von EAS 2150 sind in Klausel 8.5 von [TS23558] spezifiziert.
  • Die Fähigkeitsaufdeckung gegenüber dem EAS 2150 beinhaltet, dass die Edge-Enable-Schicht 1910 Dienste gegenüber den EASs 2150 aufgedeckt. Die aufgedeckten Fähigkeiten beinhalten die Dienste der Edge-Enable-Schicht 1910 und die erneut aufgedeckten und verstärkten Dienste des 3GPP-Kernnetzwerks 2920. Die von der Edge-Enable-Schicht 1910 aufgedeckten Fähigkeiten sind in Klausel 8.6 von [TS23558] spezifiziert, und die 3GPP-Netzwerkfähigkeitsaufdeckung ist in Klausel 8.7 von [TS23558] spezifiziert. Andere Fähigkeiten der Anwendungsschicht 1920, wie Anwendungsfreigabedienste und Dienstfreigabearchitekturschicht-Dienste (Service Enabler Architecture Layer - SEAL-Dienste), können über die Edge-Freigabeschicht 1910 gemäß einem Common API Framework (CAPIF), wie in Anhang A.4 von [TS23558] besprochen, aufgedeckt werden. Die CAPIF ermöglicht ein vereinheitlichtes Northbound-API Framework über 3GPP-Netzwerkfunktionen und stellt sicher, dass es einen einzigen und harmonisierten Ansatz für ihre Entwicklung gibt (siehe zum Beispiel 3GPP TS 23.222 v17.5.0 (2021-06-24) („[TS23222]“), TS 33.122 v16.3.0 (2020-07-10) („TS33122]“) und 3GPP TS 29.222 v17.1.0 (2021-06-25) („[TS29222]“), die jeweils hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen werden).
  • Wenn sich ein UE 111 zu einem neuen Ort bewegt, können unterschiedliche EASs 2150 zum Bedienen des UE 111 besser geeignet sein. Derartige Übergänge können auch aus einem Nichtmobilitätsereignis resultieren, das Unterstützung von der Edge-Enable-Schicht 1910 erfordert, um die Kontinuität des Dienstes aufrechtzuerhalten. Unterstützung für Dienstkontinuität stellt mehrere Merkmale zum Minimieren der Anwendungsschichtdienstunterbrechung bereit, indem die S-EAS, die mit der AC in dem UE 111 verbunden ist, durch eine T-EAS ersetzt wird. Die Unterstützung der Dienstkontinuität ist weiter in Klausel 8.8 von [TS23558] spezifiziert.
  • Zur Sicherheit unterstützt die Edge-Aktivierungsschicht 1910 sichere Kommunikation zwischen den Aktivierungsschichtentitäten. Klausel 8.11 von [TS23558] stellt Details zur EEC 2115 Authentifizierung und Autorisierung bereit. Zur dynamischen Installation des EAS 2150 kann die Edge-Enable-Schicht 1910 mit dem Verwaltungssystem des EAS 2150 interagieren, um eine Instanziierung eines geeigneten EAS 2150 gemäß Anwendungsbedürfnissen auszulösen; Einzelheiten der EAS 2150 Instanziierungsauslösung sind in Klausel 8.12 von [TS23558] spezifiziert.
  • Der Einsatz von Edge-Computing in 3GPP-Netzwerken kann eine Kooperation mit anderen SDOs erfordern, da AFs und AS keine 3GPP-definierten Knoten sind. [MEC003], ETSI GS MEC 010-1 vi. 1.1 (2017-10) („[MEC010-1]“) und ETSI GS MEC 010-2 v2.1.1 (2019-11) („MEC010-2]“) stellen einige Informationen über Nicht-3GPP-Edge-Rechenverwaltungssysteme bereit. Der Einsatz von Netzwerkfunktionen in 3GPP-Netzwerken und Nicht-3GPP-Netzwerken zur Unterstützung von Edge-Computing erfordert Kommunikation zwischen 3GPP-Managementsystem und Nicht-3GPP-Managementsystemen, wie etwa ETSI GS NFV-MAN 001 v1.1.1 (2014-12) („[NFVMAN]“) und [MEC003].
  • 20 zeigt ein beispielhaftes Peer-to-Peer-Edge-Computing-Verwaltungseinsatzszenario (P2P-Edge-Computing-Verwaltungseinsatzszenario) 2000, bei dem der Einsatz von Edge-Computing in 3GPP-Netzwerken Kommunikation zwischen 3GPP-Verwaltungssystem (3GPPms) 2015 in einem Betriebsunterstützungssystem (OSS) 2010, Nicht-3GPPms 2020, einschließlich eines Edge-Computing-Verwaltungssystems (ECMS) 2027 und ETSI-NFV-MANO 2025, beinhaltet. Das 3GPP-Verwaltungssystem 2015 kann den Edge-Computing-Einsatz durch Auffordern des ECMS 2027, den lokalen DN 2936 einzusetzen, und NFVO, die UPF 2948 und das lokale Datennetzwerk mit der QoS für N6-Anforderungen für die Verbindung (zum Beispiel virtuelle Verbindung) zwischen UPF 2948 und dem lokalen Datennetzwerk zu verbinden, initiieren. Das ECMS 2027 kann den Edge-Computing-Einsatz initiieren, indem es anfordert, dass das 3GPP-Verwaltungssystem die UPF 2948 einsetzt, und NFVO die UPF 2948 und das lokale Datennetzwerk mit den QoS-Anforderungen für die Verbindung zwischen der UPF 2948 und dem lokalen Datennetzwerk verbinden.
  • 21 zeigt eine Referenzpunktdarstellung einer Architektur 2100 zum Ermöglichen von Edge-Anwendungen. Das Edge-Datennetzwerk (EDN) 2105 ist ein lokales Datennetzwerk (zum Beispiel DN 2936 der 29 unten). Der (die) Edge-Anwendungsserver (Edge-Application-Server - EAS) 2150 und Edge-Enabler-Server (EES) 2155 sind in der EDN enthalten. Der Edge-Konfigurationsserver (ECS) 2160 stellt Konfigurationen im Zusammenhang mit dem EES 2155 bereit, einschließlich Details des Edge-Datennetzwerks, das den EES 2155 hostet. Das UE 2101 enthält einen oder mehrere Anwendungs-Client(s) (AC(s)) 2111 und den Edge-Enabler-Client (EEC) 2115. Die EAS(s) 2150, die EES(s) 2155 und das ECS 2160 können mit dem 3GPPCN 2920 interagieren.
  • Die Interaktionen im Zusammenhang mit dem Ermöglichen von Edge-Computing zwischen dem/den EES(s) 2155 und dem EEC 2115 werden von dem EDGE-1-Referenzpunkt unterstützt. Der EDGE-1-Referenzpunkt unterstützt Registrierung und Abmelden der EEC 2115 bei dem EES 2155; Abrufen und Bereitstellen von Konfigurationsinformationen für das UE 2101; und Entdecken von EAS(s) 2150, die in dem EDN 2105 verfügbar sind.
  • Die Interaktionen im Zusammenhang mit der Edge-Aktivierungsschicht 1910 zwischen dem EES 2155 und dem 3GPP-Netzwerk werden von dem EDGE-2-Referenzpunkt unterstützt. EDGE-2-Referenzpunkt unterstützt: Zugriff auf 3GPP-Netzwerkfunktionen und APIs zum Abrufen von Netzwerkfähigkeitsinformationen, zum Beispiel, über SCEF und NEF-APIs, wie in [TS23501], 3GPP TS 23.502 v16.7.0 (2020-12-17) („[TS23502]“), 3GPP TS 29.522 v17.6.0 (2021-06-25) („[TS29522]“), 3GPP TS 29.122 v17.2.0 (2021-06-25) („[TS29122]“) definiert, und wobei der EES 2155 als vertrauenswürdiger AF in 5GC agiert (siehe Klausel 5.13 von [TS23501]). Der EDGE-2-Referenzpunkt verwendet SA2-definierte 3GPP-Referenzpunkte, N33 oder Schnittstellen von EPS oder 5GS unter Berücksichtigung unterschiedlicher Einsatzmodelle weiter.
  • Die Interaktionen im Zusammenhang mit der Edge-Enabler-Schicht 1910 zwischen dem EES 2155 und den EASs 2150 werden von dem EDGE-3-Referenzpunkt unterstützt. EDGE-3-Referenzpunkt unterstützt: Registrierung der EASs 2150 mit Verfügbarkeitsinformationen (zum Beispiel Zeitbeschränkungen, Ortsbeschränkungen); Abmelden der EASs 2150 von dem EES 2155; und Bereitstellen von Zugang zu Netzwerkfähigkeitsinformationen (zum Beispiel Ortsbeschränkungen). Für EDGE-3 (zwischen EAS 2150 und EES 2155) gelten die folgenden Kardinalitätsregeln: a) ein EAS 2150 kann mit nur einem EES 2155 kommunizieren; und b) ein EES 2155 kann gleichzeitig mit einem oder mehreren EAS(s) 2150 kommunizieren.
  • Die Interaktionen im Zusammenhang mit der Edge-Aktivierungsschicht 1910 zwischen dem Konfigurationsserver des EDN 2105 und dem EEC 2115 werden von dem EDGE-4-Referenzpunkt unterstützt. EDGE-4-Referenzpunkt unterstützt: Bereitstellen von EDN 2105 Konfigurationsinformationen an die EEC 2115 in dem UE 2101.
  • Die Interaktionen zwischen AC(s) 2111 und dem EEC 2115 in dem UE 2101 werden von dem EDGE-5-Referenzpunkt unterstützt. EDGE-5 Referenzpunkt unterstützt: Das Erhalten von Informationen über EASs 2150, die der Anwendungs-Client verbinden muss; Benachrichtigungen über Ereignisse, die die Verbindung zwischen Anwendungs-Clients und ihren entsprechenden EASs 2150 betreffen, wie etwa: wann sich ein Anwendungs-Client wieder mit einem unterschiedlichen Edge-Anwendungsserver verbinden muss; Bereitstellen von Anwendungs-Client-Informationen (wie etwa dessen Profil), die für verschiedene Aufgaben zu verwenden sind, wie etwa Identifizieren der geeigneten Edge-Anwendungsserver-Instanz, mit der verbunden werden soll; und Bereitstellen der Identität des gewünschten Edge-Anwendungsservers an den EEC 2115, um es ihm zu ermöglichen, diese Identität als ein Filter zu verwenden, wenn Informationen über die EASs 2150 angefordert werden.
  • Die Interaktionen in Bezug auf die Edge-Aktivierungsschicht 1910 zwischen dem Edge-Datennetzwerkkonfigurationsserver und dem EES 2155 werden von dem Edge-6-Referenzpunkt unterstützt. EDGE-6 Referenzpunkt unterstützt: Registrierung von Information des EES 2155 beim Edge-Enabler-Netzwerkkonfigurationsserver.
  • Die Interaktionen im Zusammenhang mit der Edge-Aktivierungsschicht 1910 zwischen dem EES 2155 und dem 3GPP-Netzwerk werden von dem EDGE-2-Referenzpunkt (oder EDGE-7-Referenzpunkt) unterstützt. EDGE-7 Referenzpunkt unterstützt: Zugriff auf 3GPP-Netzwerkfunktionen und APIs zum Abrufen von Netzwerkfähigkeitsinformationen, zum Beispiel, über SCEF- und NEF-APIs, wie in [TS23501], [TS23502], [TS29522], [TS29122] definiert, und wobei der EAS 2150 als vertrauenswürdige AF in 5GC agiert (siehe zum Beispiel Klausel 5.13 von [TS23501]). EDGE-7-Referenzpunkt verwendet SA2-definierte 3GPP-Referenzpunkte, N6 oder Schnittstellen von EPS oder 5GS unter Berücksichtigung unterschiedlicher Einsatzmodelle weiter.
  • Die Interaktionen zwischen dem Datennetzwerk-Konfigurationsserver und dem 3GPP-Netzwerk werden von dem EDGE-8-Referenzpunkt unterstützt. EDGE-8-Referenzpunkt unterstützt: Edge-Daten-Netzwerk-Konfigurationen, die dem 3GPP-Netzwerk unter Verwenden von Netzwerkaufdeckungsdiensten bereitgestellt werden.
  • EDGE-9-Referenzpunkt ermöglicht Wechselwirkungen zwischen zwei EES(s) 2155. Der EDGE-9-Referenzpunkt kann zwischen EES 2155 innerhalb unterschiedlicher EDN und innerhalb derselben EDN bereitgestellt sein.
  • Der EES 2155 stellt unterstützende Funktionen bereit, die für EASs 2150 und EEC 2115 benötigt werden. Funktionalitäten von EES 2155 sind: a) Bereitstellen von Konfigurationsinformationen an EEC 2115, wodurch ein Austausch von Anwendungsdatenverkehr mit dem Edge-Anwendungsserver ermöglicht wird; b) Unterstützen der Funktionalitäten des API-Aufrufs 410 und der API-Aufdeckungsfunktion, wie in [TS23222] spezifiziert; C) Interagieren mit einem 3GPP-Kernnetzwerk zum Zugreifen auf die Fähigkeiten von Netzwerkfunktionen entweder direkt (zum Beispiel über PCF) oder indirekt (zum Beispiel über SCEF/NEF/SCEF+NEF); und d) Unterstützen der Funktionalitäten der Anwendungskontextübertragung.
  • Die folgenden Kardinalitätsregeln gelten für EES 2155: a) Ein oder mehrere EES(s) 2155 können sich in einem EDN befinden; b) Ein oder mehrere EES(s) 2155 können sich in einem EDN 2105 pro ECSP befinden (siehe zum Beispiel ECSP 2310 der 23).
  • Der EAS 2150 ist der Anwendungsserver, der sich in dem EDN 2105 befindet und die Serverfunktionen ausführt. Der Anwendungs-Client verbindet sich mit dem Edge-Anwendungsserver, um die Dienste der Anwendung mit Vorteilen des Edge-Computing zur Verfügung zu stellen. Es ist möglich, dass die Serverfunktionen einer Anwendung nur als EAS 2150 zur Verfügung stehen. Falls die Serverfunktionen der Anwendung jedoch sowohl als EAS 2150 als auch als ein Anwendungsserver verfügbar sind, der sich in der Cloud befindet, ist es möglich, dass die Funktionen des EAS 2150 und des Anwendungsservers nicht dieselben sind.
  • Zusätzlich kann, falls die Funktionen des EAS 2150 und des Anwendungsservers unterschiedlich sind, der Anwendungsdatenverkehr auch unterschiedlich sein.
  • Der EAS 2150 kann die 3GPP-Kernnetzwerkfähigkeiten auf unterschiedliche Weisen verbrauchen, wie etwa: a) er kann 3GPP-Kernnetzwerkfunktions-APIs direkt aufrufen, falls er eine Entität ist, der das 3GPP-Kernnetzwerk vertraut; b) es kann 3GPP-Kernnetzwerkfähigkeiten durch den EES 2155 aufrufen; und c) es kann es die 3GPP-Kernnetzwerkfähigkeit durch die Fähigkeitsaufdeckungsfunktionen (zum Beispiel SCEF oder NEF) aufrufen.
  • Für EAS 2150 gelten folgende Kardinalitätsregeln: a) Ein oder mehrere EAS(s) können sich in einem EDN befinden. Die EAS(s), die zu derselben EAS-ID gehören, können von mehreren ECSP(s) 2310 in einem EDN bereitgestellt werden.
  • Der EES 2155 ID (EESID) ist das FQDN dieses EES 2155, und jede EES 2155 ID ist innerhalb der PLMN-Domäne eindeutig.
  • Die EAS-Identität (EASID) identifiziert eine spezielle Anwendung für zum Beispiel, SA6Video, SA6Game usw. Zum Beispiel nutzen alle Edge-SA6-Videoserver dieselbe EASID gemeinsam. Tabelle 7 zeigt EAS 2150 Profil-IEs. Tabelle 7: Edge-Anwendungsserverprofil
    Informationselement Status Beschreibung
    EAS-D M Die Kennung des EAS 2150
    EAS-Endpunkt M Endpunktinformationen (zum Beispiel URI, FQDN, Netzwerkadresse (zum Beispiel IP-Adresse)), die zum Kommunizieren mit dem EAS verwendet werden. Diese Informationen können von dem EEC 2115 entdeckt und Anwendungs-Clients aufgedeckt werden, so dass Anwendungs-Clients Kontakt mit dem EAS herstellen können.
    Anwendungs-CLIENT-ID(s) O Identifiziert den oder die Anwendungs-Client(s), der (die) von dem EAS 2150 bedient werden kann (können)
    EAS-Anbieterkennung O Die Kennung des EAS-Anbieters
    EAS-Typ O Kategorie oder Typ des EAS 2150 (zum Beispiel V2X)
    EAS-Beschreibung O Für Menschen lesbare Beschreibung des EAS 2150
    EAS-Planung O Der Verfügbarkeitsplan für den EAS 2150 (zum Beispiel Zeitfenster)
    EAS-Servicebereich O Der geografische Dienstbereich, den der EAS 2150 bedient
    EAS-Dienst KPls O Dienstmerkmale, die von dem EAS bereitgestellt werden, ausführlich in Tabelle 8.2.5-1 erläutert
    Dienst-Kontinuitätsunterstützun q O Gibt an, ob der EAS 2150 Dienstkontinuität unterstützt oder nicht.
    EAS Verfügbarkeitsberichtpe riode O Die Verfügbarkeitsberichtperiode (zum Beispiel Herzschlagperiode), die dem EES angibt, wie oft es die Verfügbarkeit des EAS nach einer erfolgreichen Registrierung prüfen muss.
    Vom EAS geforderte Dienst-APIs O Eine Liste der Dienst-APIs, die von dem EAS benötigt werden
    EAS-Status O Der Status des EAS 2150 (zum Beispiel aktiviert, deaktiviert usw.)
  • Tabelle 8 zeigt die Dienst-KPIs des EAS 2150, die Informationen über Dienstcharakteristiken bereitstellen, die von dem EAS 2150 bereitgestellt werden. Tabelle 8 Edse-Anwendunssserver-Dienst-KPIs
    Informationselement Status Beschreibung
    Maximale Anforderungsrate O Maximale Anforderungsrate des von dem Server unterstützten Anwendungs-Client.
    Maximale Ansprechzeit O Die maximal angekündigte Antwortzeit für die Dienstanforderungen des Anwendungs-Client.
    Verfügbarkeit O Angekündigter Zeit-Prozentsatz, während dem der Server für die Nutzung des Anwendungs-Client zur Verfügung steht.
    Verfügbares Rechnen O Die für den Anwendungs-Client maximal verfügbare Rechenressource.
    Verfügbares graphisches Rechnen O Die maximale grafische Rechenressource, die dem Anwendungs-Client zur Verfügung steht.
    Verfügbarer Speicher O Die für den Anwendungs-Client maximal zur Verfügung stehende Speicherressource.
    Verfügbare Speicherung O Die für den Anwendungs-Client maximal verfügbare Speicherungsressource.
    Verbindungsbandbreite O Die Verbindungsbandbreite in Kbit/s, die für die Nutzung des Anwendungs-Client angekündigt wird.
    HINWEIS: Die maximale Antwortzeit beinhaltet die Umlaufzeit des Anforderungs- und Antwortpakets, die Verarbeitungszeit an dem Server und die Zeit, die der Server benötigt, um 3GPP-Kernnetzwerkfähigkeiten, falls vorhanden, zu verbrauchen.
  • Tabelle 9 zeigt IEs des Profils des EES 2155, die Informationen über den EES 2155 und die von ihm bereitgestellten Dienste beinhalten. Tabelle 9: Edge-Enabler-Serverprofil
    Informationselement Status Beschreibung
    EES-ID M Die Kennung des EES 2155
    EES-Endpunkt M Endpunktinformationen (zum Beispiel URI, FQDN, IP-Adresse), die zum Kommunizieren mit dem EES verwendet werden. Diese Informationen werden dem EEC 2115 zur Verbindung mit dem EES 2155 bereitqestellt.
    Edge-Anwendungs-Serverprofile M Liste der bei dem EES 2155 registrierten EASs 2150.
    EES-Anbieterkennung O Die Kennung des EES-Anbieters (wie etwa ECSP)
  • Die Netzfähigkeitsaufdeckung gegenüber EAS(s) 2150 hängt von den Einsatzszenarien und der Geschäftsbeziehung des ASP 2305 und/oder ECSP 2310 mit dem PLMN-Betreiber 2315 ab. Es werden folgende Mechanismen unterstützt: Direkte Netzwerkfähigkeitsaufdeckung und/oder Netzwerkfähigkeitsaufdeckung über EES 2155.
  • Bei einigen Umsetzungen hängt die Netzwerkfähigkeitsaufdeckung gegenüber EAS(s) von den Einsatzszenarien und der Geschäftsbeziehung der ASP 2305 und/oder des ECSP 2310 mit dem PLMN-Betreiber 2315 ab. Es werden folgende Mechanismen unterstützt: Direkte Netzwerkfähigkeitsaufdeckung und/oder Netzwerkfähigkeitsaufdeckung über EES 2155. Bei einigen Umsetzungen liegen die Abrechnungsfunktionalitäten mit unterschiedlichen Einsatzmöglichkeiten in Abhängigkeit von Geschäftsbeziehungen zwischen Edge-ASP (siehe zum Beispiel ASP 2305 der 23), ECSP (siehe zum Beispiel ECSP 2310 der 23) und SFC-Dienstanbieter außerhalb des Schutzumfangs der vorliegenden Offenbarung (SA5-Studie).
  • Der EDGE-9-Referenzpunkt ermöglicht Wechselwirkungen zwischen zwei EES(s) 2155. Der EDGE-9-Referenzpunkt kann zwischen EESs 2155 innerhalb unterschiedlicher EDNs 2105, wie in 22a gezeigt, und innerhalb desselben EDN 2105, wie in 22b gezeigt, bereitgestellt werden.
  • 23 zeigt die Aufgaben und Beziehung von Dienstanbietern, die an der Erbringung von Edge-Computing-Diensten beteiligt sind (siehe zum Beispiel Anhang B in [TS23558]). Der Anwendungsanbieter (ASP) 2305 ist für die Anlegung von EAS(s) 2150 und ACs 2111 zuständig. Der ECSP 2310 ist für den Einsatz von EDNs 2105 zuständig, die EAS 2150 und EES 2155 enthalten, die Konfigurationsinformationen an den EEC 2115 liefern, wodurch es dem AC ermöglicht wird, Anwendungsdatenverkehr mit dem EAS auszutauschen. Der PLMN-Betreiber 2315 ist für den Einsatz von 5G-Netzwerkfunktionen, wie etwa 5GC und 5GNR, zuständig.
  • Der Endnutzer ist der Verbraucher der von dem ASP bereitgestellten Anwendungen/Dienste und kann eine ASP-Dienstvereinbarung mit einem einzelnen oder mehreren Anwendungsdienstanbietern haben. Der Endbenutzer weist eine PLMN-Subskriptionsvereinbarung mit dem PLMN-Betreiber 2315 auf. Das vom Endbenutzer verwendete UE darf im PLMN-Betreibernetzwerk 2315 registriert werden. Der ASP verbraucht die Edge-Dienste (zum Beispiel Infrastruktur, Plattform usw.), die von dem Edge-Rechendienstanbieter (ECSP) 2310 bereitgestellt werden, und kann ECSP-Dienstvereinbarung(en) mit einem einzelnen oder mehreren ECSPs 2310 aufweisen. Der ECSP 2310 kann ein Mobilfunknetzbetreiber oder ein Dienstanbieter der Drittpartei sein, der Edge-Computing-Dienste anbietet. Ein einzelner PLMN-Betreiber 2315 kann die Dienstvereinbarung des PLMN-Betreibers 2315 mit einem einzelnen oder mehreren ECSP 2310 haben. Ein einziger ECSP 2310 kann eine Dienstvereinbarung des PLMN Operators 2315 mit einem einzigen oder mehreren PLMN-Betreibern 2315, die Edge-Computing-Unterstützung bereitstellen, aufweisen. Der ECSP 2310 und der PLMN-Betreiber 2315 können Teil derselben Organisation oder unterschiedlicher Organisationen sein.
  • Die folgende Diskussion stellt spezifische Beispiele bereit, die für Edge-Computing-Konfigurationen relevant sind, die innerhalb von MEC (Multi-Access Edge-Computing) und 5G-Netzwerkumsetzungen bereitgestellt werden. Viele andere Standards und Netzwerkumsetzungen sind jedoch auf die hier besprochenen Edge- und Dienstverwaltungskonzepte anwendbar. Zum Beispiel können die hierin besprochenen Ausführungsformen auf viele andere Edge-Computing-/Networking-Technologien in verschiedenen Kombinationen und Layouts von Vorrichtungen, die sich am Rand eines Netzwerks befinden, anwendbar sein. Beispiele für derartige anderen Edge-Computing-/Networking-Technologien, die die vorliegenden Ausführungsformen umsetzen können, beinhalten Content Delivery Networks (CDNs) (auch als „Content Distribution Networks“ oder dergleichen bezeichnet); Mobility-Service-Provider-Edge-Computing-(MSP-Edge-Computing-) und/oder Mobility-as-a-Service-Anbietersysteme (MaaS-Anbietersysteme) (zum Beispiel in AECC-Architekturen verwendet); Nebula-Edge-Cloud-Systeme; Fog-Computing-Systeme; Cloudlet-Edge-Cloud-Systeme; Mobile-Cloud-Computing-Systeme (MCC-Systeme); Central Office Re-Architected as a Datacenter (CORD), Mobile-CORD (M-CORD) und/oder Converged-Multi-Access-and-Core-Systeme (COMAC-Systeme); und/oder dergleichen. Weiter können hierin offenbarte Techniken andere IoT-Edge-Netzwerksysteme und -konfigurationen betreffen und andere zwischengeschaltete Verarbeitungsentitäten und Architekturen können ebenfalls verwendet werden, um die hierin beschriebenen Ausführungsformen umzusetzen.
  • 2.2. MULTI-ZUGRIFF-EDGE-COMPUTING -ASPEKTE (MEC-ASPEKTE)
  • 24 veranschaulicht eine MEC-System-Referenzarchitektur (oder MEC-Architektur) 2400, die Funktionalitäten gemäß ETSI GS MEC 003 v2.1.1 (2019-01) („[MEC003]“); ETSI GS MEC 009 V2.1.1 (2019-01) („[MEC009]„); ETSI GS MEC 011 V1.1.1 (2017-07) („[MEC011]“); ETSI GS MEC 012 V2.1.1 (2019-12) („[MEC012]“); ETSI GS MEC 013 v2.1.1 (2019-09) („[MEC013]“) bereitstellt; ETSI GS MEC 014 VI.1.1 (2018-02) („[MEC014]“); ETSI GS MEC 015 v2.1.1 (2020-06) („[MEC015]“); ETSI GS MEC 016 V2.2.1 (2020-04) („[MEC016]“); ETSI GS MEC 021 V2.1.1 (2020-01) („[MEC021]“); ETSI GS MEC 028 v2.1.1 (2020-06) („[MEC028]“); ETSI GS MEC 029 v2.1.1 (2019-07) („[MEC029]“); ETSI MEC GS 030 v2.1.1 (2020-04) („[MEC030]“); unter vielen anderen ETSI MEC-Standards bereitstellt. MEC bietet Anwendungsentwicklern und Inhaltsanbietern Cloud-Computing-Fähigkeiten und eine IT-Service-Umgebung an der Edge des Netzwerks an. Diese Umgebung zeichnet sich durch ultraniedrige Latenz und hohe Bandbreite sowie Echtzeitzugriff auf Funknetzinformationen aus, die von 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, was den Automobilsektor betrifft, Anwendungen wie V2X (zum Beispiel auf IEEE 802.11p basierende Protokolle, wie etwa DSRC/ITS-G5- oder auf 3GPP-C-V2X basierende Protokolle) Daten austauschen, Daten zu Aggregationspunkten und Zugang zu Daten in Datenbanken bereitgestellt werden, die einen Überblick über die lokale Situation bereitstellen, abgeleitet von einer Vielzahl von Sensoren (durch verschiedene Autos, Straßenrandeinheiten usw.).
  • Die MEC-Architektur 2400 beinhaltet MEC-Hosts 2402, einen Virtualisierungsinfrastrukturmanager (VIM) 2408, einen MEC-Plattformmanager 2406, einen MEC-Orchestrator 2410, ein Operationsunterstützungssystem (OSS) 2412, einen User Application Life Cycle Management-Proxy (UALCMP-Proxy) 2414, eine UE-APP 2418, die auf dem UE 2420 läuft, und ein CFS-Portal 2416. Der MEC-Host 2402 kann eine MEC-Plattform 2432 mit Filterungsregel-Steuerkomponenten 2440, eine DNS-Handhabungskomponente 2442, eine Dienstregistrierungsdatenbank 2438 und MEC-Dienste 2436 beinhalten. Die MEC-Dienste 2436 können mindestens einen Scheduler beinhalten, der verwendet werden kann, um Ressourcen zum Instanziieren von MEC-Apps (oder NFVs) 2426 auf der Virtualisierungsinfrastruktur (VI) 2422 auszuwählen. Die MEC-Apps 2426 können dazu konfiguriert sein, Dienste 2430, darunter Verarbeiten von Netzwerkkommunikationsverkehr unterschiedlicher Typen, die mit einer oder mehreren drahtlosen Verbindungen (zum Beispiel Verbindungen zu einem oder mehreren RANs oder Kernnetzwerkfunktionen) assoziiert sind, und/oder andere Dienste, wie etwa die hierin besprochenen, bereitzustellen. Der andere MEC-Host 2402 kann eine gleiche oder eine ähnliche Konfiguration/Umsetzung wie der MEC-Host 2402 aufweisen, und die andere MEC-App 2426, die innerhalb des anderen MEC-Hosts 2402 instanziiert ist, kann den MEC-Apps 2426, die innerhalb des MEC-Hosts 2402 instanziiert sind, ähnlich sein. Die VI 2422 beinhaltet eine Datenebene 2424, die über eine MP2-Schnittstelle mit der MEC-Plattform 2422 gekoppelt ist. Zusätzliche Schnittstellen zwischen verschiedenen Netzwerkentitäten der MEC-Architektur 2400 sind in 24 veranschaulicht.
  • Das MEC-System 2400 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 2400 können IPbasierte Verbindungen beinhalten und können verwendet werden, um Dienste zum Representational State Transfer (REST oder RESTful) bereitzustellen, und die unter Verwenden der Referenzpunkte/Schnittstellen übermittelten Nachrichten können in XML, HTML, JSON oder einem anderen gewünschten Format, wie den hierin erörterten, vorliegen. Ein geeignetes Authentifizierungs-, Autorisierungs- und Abrechnungsprotokoll (AAA), wie etwa das Radius- oder das Durchmesserprotokoll, kann auch zum Kommunizieren über die Referenzpunkte/Schnittstellen verwendet werden.
  • Die logischen Verbindungen zwischen verschiedenen Entitäten der MEC-Architektur 2400 können zugriffsagnostisch sein und nicht von einem bestimmten Einsatz abhängen. MEC ermöglicht die Umsetzung von MEC-Apps 2426 als Nur-Software-Entitäten, die auf einer VI 2422 laufen, die sich in oder nahe dem Netzwerkrand befindet. Eine MEC-App 2426 ist eine Anwendung, die auf einem MEC-Host 2402 innerhalb des MEC-Systems 2400 instanziiert werden kann und potenziell MEC-Dienste 2436 bereitstellen oder verbrauchen kann.
  • Die in 24 abgebildeten MEC-Entitäten können in eine MEC-Systemebene, MEC-Hostebene und Entitäten auf Netzwerkebene (nicht gezeigt) gruppiert werden. Die (nicht gezeigte) Netzwerkebene beinhaltet verschiedene externe Netzwerkebenenentitäten, wie etwa ein 3GPP-Netzwerk, ein lokales Netzwerk (zum Beispiel ein LAN, WLAN, PAN, DN, LADN usw.) und ein oder mehrere externe Netzwerke. Die MEC-Systemebene beinhaltet MEC-Systemebenen-Verwaltungsentitäten und UE 2420 und wird im Folgenden ausführlicher besprochen. Die MEC-Hostebene beinhaltet einen oder mehrere MEC-Hosts 2402, 2404 und MEC-Verwaltungsentitäten, die Funktionalität bereitstellen, um MEC-Anwendungen 2426 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 2432, eines MEC-Hosts 2402 und der MEC-Anwendungen 2426, die ausgeführt werden sollen, handhaben.
  • Der MEC-Plattformmanager 2406 ist eine MEC-Verwaltungsentität, die eine MEC-Plattformelementverwaltungskomponente 2444, eine MEC-App-Regel- und Anforderungsverwaltungskomponente 2446 und eine MEC-App-Lebenszyklusverwaltungskomponente 2448 beinhaltet, ausführen. Die verschiedenen Entitäten innerhalb der MEC-Architektur 2400 können Funktionalitäten, wie in [MEC003] besprochen, ausführen. Die Remote-App 2450 ist dazu konfiguriert, mit dem MEC-Host 2402 (zum Beispiel mit den MEC-Apps 2426) über den MEC-Orchestrator 2410 und den MEC-Plattform-Manager 2406 zu kommunizieren.
  • Der MEC-Host 2402 ist eine Entität, die eine MEC-Plattform 2432 und VI 2422 enthält, die Rechen-, Speicher- und Netzwerkressourcen zum Ausführen von MEC-Apps 2426 bereitstellt. Die VI 2422 beinhaltet eine Datenebene (DP) 2424, die Verkehrsregeln 2440 ausführt, die von der MEC-Plattform 2432 empfangen werden, und den Verkehr zwischen MEC-Anwendungen 2426, MEC-Diensten 2436, DNS-Server/Proxy (siehe zum Beispiel über DNS-Handhabungsentität 2442), 3GPP-Netzwerk, lokalen Netzwerken und externen Netzwerken routet. Die MEC-DP 2424 kann mit den (R)A-Knoten und dem 3 GPP-Kernnetzwerk verbunden sein und/oder kann mit einem Zugangspunkt über ein weiteres Netzwerk, wie etwa das Internet, ein Unternehmensnetzwerk oder dergleichen, verbunden sein.
  • Die MEC-Plattform 2432 ist eine Sammlung wesentlicher Funktionalität, die erforderlich ist, um MEC-Anwendungen 2426 auf einer bestimmten VI 2422 auszuführen und es ihnen zu ermöglichen, MEC-Dienste 2436 bereitzustellen und zu verbrauchen, und die sich selbst eine Anzahl von MEC-Diensten 937a bereitstellen kann. Die MEC-Plattform 2432 kann auch verschiedene Dienste und/oder Funktionen bereitstellen, wie etwa Anbieten einer Umgebung, in der die MEC-Anwendungen 2426 MEC-Dienste 2436 (im Folgenden besprochen) entdecken, ankündigen, verbrauchen und anbieten können, einschließlich MEC-Dienste 2436, die über andere Plattformen verfügbar sind, wenn sie unterstützt werden. Die MEC-Plattform 2432 kann in der Lage sein, es autorisierten MEC-Apps 2426 zu erlauben, mit Drittpartei-Servern zu kommunizieren, die sich in externen Netzwerken befinden. Die MEC-Plattform 2432 empfängt Verkehrsregeln von dem MEC-Plattformmanager 2406, Anwendungen oder Diensten und weist die Datenebene entsprechend an (siehe zum Beispiel Verkehrsregelsteuerung 2440). Die MEC-Plattform 2432 kann Anweisungen an das DP 2424 innerhalb der VI 2422 über den Mp2-Referenzpunkt senden. Der Mp2-Referenzpunkt zwischen der MEC-Plattform 2432 und dem DP 2424 der VI 2422 kann verwendet werden, um die DP 2434 darüber anzuweisen, wie Verkehr zwischen Anwendungen, Netzwerken, Diensten usw. zu routen ist. Die MEC-Plattform 2432 kann Token, die UEs 2420, UE-Apps, individuelle Sitzungen und/oder individuelle Flüsse innerhalb einer Sitzung in den Verkehrsregeln darstellen, in spezifische Netzwerkadressen (zum Beispiel IP-Adressen oder dergleichen) übersetzen. Die MEC-Plattform 2432 empfängt auch DNS-Aufzeichnungen von dem MEC-Plattform-Manager 2406 und konfiguriert einen DNS-Proxy /Server entsprechend. Die MEC-Plattform 2432 hostet MEC-Dienste 2436, einschließlich der nachstehend besprochenen Mehrfachzugriffs-Edge-Dienste, und stellt Zugang zu persistenten Speicherungs- und Tageszeitinformationen bereit. Darüber hinaus kann die MEC-Plattform 2432 mit anderen MEC-Plattformen 2432 anderer MEC-Server 2402 über den MP3-Referenzpunkt kommunizieren. Bei Empfang einer Aktualisierung, Aktivierung oder Deaktivierung von Verkehrsregeln von dem MEC-Plattformmanager 2406, Apps oder Diensten, weist die MEC-Plattform 2432 die Datenebene 2424 entsprechend an. Die MEC-Plattform 2432 empfängt auch DNS-Aufzeichnungen von dem MEC-Plattformmanager 2406 und verwendet diese, um einen DNS-Proxy/Server 2442 zu konfigurieren. Die Verkehrsregelsteuerung 2440 erlaubt es der MEC-Plattform 2432, Verkehrsrouten, einschließlich Verkehrsregelaktualisierung, -aktivierung und - deaktivierung, auszuführen. Zusätzlich oder alternativ erlaubt es die Verkehrsregelsteuerung 2440 der MEC-Plattform 2432, Verkehrslenkung auszuführen, indem zum Beispiel Datenpakete über eine oder mehrere Zugangsnetzwerkverbindungen in einer Mehrfachzugangsumgebung geleitet werden, die mehrere Zugangsnetzwerke umfasst, von denen jedes mehrere Zugangsnetzwerkverbindungen aufweisen kann und/oder unterschiedliche Zugangstechnologien umsetzen kann.
  • Zusätzlich oder alternativ bietet die MEC-Plattform 2432 eine Umgebung an, in der MEC-Apps 2426 MEC-Dienste 2436 entdecken, ankündigen, verbrauchen und anbieten können. Bei Empfang einer Aktualisierung, Aktivierung oder Deaktivierung von Verkehrsregeln von dem MEC-Plattformmanager 2406, Anwendungen 2426 oder Diensten 2436, weist die MEC-Plattform 2432 die Datenebene 2424 entsprechend an. Die MEC-Plattform 2432 empfängt auch DNS-Aufzeichnungen von dem MEC-Plattformmanager 2406 und verwendet diese, um einen DNS-Proxy/Server zu konfigurieren (zum Beispiel DNS-Handhabung 2442).
  • Zusätzlich oder alternativ kann die MEC-Plattform 2432 von API-Gateway-Funktionalität begleitet werden, die den Empfang einer Dienst-API-Anforderung von MEC-Apps 2426 über einen stabilen Dienstverbindungsendpunkt unterstützt. Die Änderung der Netzwerkadresse (zum Beispiel IP-Adresse) von MEC-Dienstinstanzen führt nicht zu der Aktualisierung der Dienstverbindungsendpunktinformationen. Die API-Gateway-Funktionalität unterstützt auch Lastausgleich für mehrere Backend-MEC-Dienstinstanzen, Drosseln von API-Anforderungen für besseren Durchsatz basierend auf der Konfiguration und Überwachen von API-Anforderungen. Die API-Gateway-Funktionalität kann zur Statistik und Gebührenerhebung verwendet werden.
  • Die VI 2422 stellt die Gesamtheit aller Hardware- und Softwarekomponenten dar, die die Umgebung aufbauen, in der MEC-Anwendungen 2426 und/oder MEC-Plattform 2432 eingesetzt, verwaltet und ausgeführt werden. Die VI 2422 kann sich über mehrere Orte erstrecken und das Netzwerk, das Konnektivität zwischen diesen Orten bereitstellt, wird als Teil der VI 2422 angesehen. Die physischen Hardware-Ressourcen der VI 2422 beinhalten Rechen-, Speicher- und Netzwerkressourcen, die die Verarbeitung, Speicherung und Konnektivität für MEC-Apps 2426 und/oder MEC-Plattform 2432 durch eine Virtualisierungsschicht (zum Beispiel einen Hypervisor, VM-Monitor (VMM) oder dergleichen) bereitstellen. Die Virtualisierungsschicht kann die physischen Hardware-Ressourcen des MEC-Servers 2402 als eine Hardware-Abstraktionsschicht abstrahieren und/oder logisch partitionieren. Die Virtualisierungsschicht kann es der Software, die die MEC-Apps 2426 und/oder die MEC-Plattform 2432 umsetzt, auch ermöglichen, die zugrunde liegende VI 2422 zu verwenden, und kann virtualisierte Ressourcen für die MEC-Apps 2426 und/oder die MEC-Plattform 2432 derart bereitstellen, dass die MEC-Apps 2426 und/oder die MEC-Plattform 2432 ausgeführt werden können.
  • Die MEC-Anwendungen 2426 sind Anwendungen, die auf einem MEC-Host/Server 2402 innerhalb des MEC-Systems 2400 instanziiert werden können und potenziell MEC-Dienste 2436 bereitstellen oder verbrauchen können. Der Begriff „MEC-Dienst“ verweist auf einen Dienst, der über eine MEC-Plattform 2432 entweder von der MEC-Plattform 2432 selbst oder von einer MEC-Anwendung 2426 bereitgestellt wird. MEC-Anwendungen 2426 können als VM auf der VI 2422 laufen, die von dem MEC-Server 2402 bereitgestellt wird, und können mit der MEC-Plattform 2432 interagieren, um die MEC-Dienste 2436 zu verbrauchen und bereitzustellen. Der Mp1-Referenzpunkt zwischen der MEC-Plattform 2432 und den MEC-Anwendungen 2426 wird zum Verbrauchen und Bereitstellen dienstspezifischer Funktionalität verwendet. Mp1 stellt Dienstregistrierung 2438, Dienstentdeckung und Kommunikationsunterstützung für verschiedene Dienste, wie etwa die MEC-Dienste 2436, die von dem MEC-Host 2402 bereitgestellt werden, bereit. Mp1 kann auch Anwendungsverfügbarkeit, Sitzungsstatusumlagerungs-Unterstützungsvorgehensweisen, Verkehrsregel- und DNS-Regel-Aktivierung, Zugriff auf persistente Speicherungs- und Tageszeitinformationen und/oder dergleichen bereitstellen.
  • Zusätzlich oder alternativ können die MEC-Anwendungen 2426 mit der MEC-Plattform 2432 unter Verwenden der MEC-APIs die in ETSI GS MEC 011 V2.1.1 (2019-11) erörtert sind, kommunizieren,.
  • Die MEC-Anwendungen 2426 werden auf der VI 2422 des MEC-Servers 2402 basierend auf Konfiguration oder Anforderungen instanziiert, die von der MEC-Verwaltung (zum Beispiel MEC-Plattformmanager 2406) validiert werden. Die MEC-Anwendungen 2426 können auch mit der MEC-Plattform 2432 interagieren, um bestimmte Unterstützungsvorgehensweisen im Zusammenhang mit dem Lebenszyklus der MEC Apps 2426 auszuführen, wie etwa Angeben einer Verfügbarkeit, Vorbereiten einer Umlagerung eines Benutzerzustands usw. Die MEC-Anwendungen 2426 können eine bestimmte Anzahl von Regeln und Anforderungen aufweisen, die mit ihnen assoziiert sind, wie etwa erforderliche Ressourcen, maximale Latenz, erforderliche oder nützliche Dienste usw. Diese Anforderungen können von der MEC-Verwaltung validiert werden und, falls sie fehlen, können sie Standardwerten zugewiesen werden. MEC-Dienste 2436 sind Dienste, die entweder von der MEC-Plattform 2432 und/oder MEC-Anwendungen 2426 bereitgestellt und/oder verbraucht werden. Die Dienstverbraucher (zum Beispiel MEC-Anwendungen 2426 und/oder MEC-Plattform 2432) können mit bestimmten MEC-Diensten 2430/2436 über einzelne APIs (einschließlich der verschiedenen hierin besprochenen MEC-API(s) 630) kommunizieren. Wenn er von einer Anwendung bereitgestellt, kann ein MEC-Dienst 2436 in einer Liste von Diensten in den Dienstregistern 2438 zu der MEC-Plattform 2432 über den Mp1-Referenzpunkt registriert werden. Zusätzlich kann eine MEC-Anwendung 2426 einen oder mehrere Dienste 2430/2436, für die sie über den Mp1-Referenzpunkt autorisiert ist, abonnieren. Beispiele für MEC-Dienste 2430/2436 beinhalten MEC-Anwendungsunterstützung [MEC011], MEC-Diensteverwaltung [MEC011], RNIS (siehe zum Beispiel [MEC012], Ortsdienste [MEC013], UE-Identitätsdienste [MEC014], Verkehrsverwaltungsdienste (TMS) und BWMS [MEC015], Geräteanwendungsschnittstelle [MEC016], WLAN-Zugangsinformationendienste (WAI-Dienste) [MEC028], FAI-Dienste (FAI-Dienste) [MEC029], V2X-Informationsdienste (VIS) [MEC030] und/oder andere MEC-Dienste 2430/2436. Jeder dieser MEC-Dienste 2430/2436 wird unter Verwenden einer entsprechenden MEC-API 630 bereitgestellt.
  • Der RNIS stellt, falls verfügbar, autorisierte MEC-Apps 2426 mit funknetzbezogenen Informationen bereit und entdeckt den MEC-Apps 2426 geeignete aktuelle Funknetzinformationen auf. Die RNI können unter anderem Funknetzbedingungen, Mess- und Statistikinformationen im Zusammenhang mit dem UP, Informationen im Zusammenhang mit UEs 2420, die von dem einen oder den mehreren Funkknoten bedient werden, die mit dem MEC-Host 2402 assoziiert sind (zum Beispiel UE-Kontext und Funkzugangsträger), Änderungen an Informationen im Zusammenhang mit UEs 2420, die von dem einen oder den mehreren Funkknoten bedient werden, die mit dem MEC-Host XE136 assoziiert sind, und/oder dergleichen beinhalten. Die RNI können mit der relevanten Granularität (zum Beispiel pro UE 2420, pro Zelle, pro Zeitraum) bereitgestellt werden.
  • Die Dienstverbraucher (zum Beispiel MEC-Anwendungen 2426, MEC-Plattform 2432 usw.) können mit dem RNIS über eine RNI-API kommunizieren, um Kontextinformationen von einem entsprechenden RAN zu erhalten. RNI können den Dienstverbrauchern über ein NAN (zum Beispiel (R)AN-Knoten, RRH, AP usw.) bereitgestellt werden. Die RNI-API kann sowohl Anfrage- als auch Subskriptions-basierter (zum Beispiel ein Pub/Sub) Mechanismus unterstützen, die über eine Representational State Transfer-API (RESTful-API) oder über einen Nachrichtenbroker der MEC-Plattform 2432 (nicht gezeigt) verwendet werden. Eine MEC-App 2426 kann Informationen über einen Nachrichten-Broker über eine Transportinformationsabfragevorgehensweise abfragen, wobei die Transportinformationen der MEC-App 2426 über einen geeigneten Konfigurationsmechanismus im Vorfeld bereitgestellt werden können. Die verschiedenen Nachrichten, die über die RNI-API kommuniziert werden, können in XML, JSON, Protobuf oder einem anderen geeigneten Format vorliegen.
  • Das VIS stellt verschiedene V2X-Anwendungen bereit, einschließlich, unter vielen anderen, der reisebewussten QoS-Vorhersagen. Die RNI können von den MEC-Apps 2426 und der MEC-Plattform 2432 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 2426 RNI verwenden, um aktuelle Dienste, wie eine Videodurchsatzanleitung, zu optimieren. Bei der Durchsatzanleitung kann eine Funkanalytik-MEC-Anwendung 2426 MEC-Dienste verwenden, um einem Backend-Videoserver eine Nahechtzeitangabe über den Durchsatz bereitzustellen, von dem geschätzt wird, dass er an der Funk-DL-Schnittstelle zu einem nächsten Zeitpunkt verfügbar ist. Die Durchsatzanleitungs-Funkanalytikanwendung berechnet eine Durchsatzanleitung basierend auf den erforderlichen Funknetzinformationen, die sie von einem Mehrfachzugriffs-Edge-Dienst, der auf dem MEC-Server 2402 läuft, erhält. RNI können von der MEC-Plattform 2432 auch verwendet werden, um die Mobilitätsvorgehensweisen zu optimieren, die zur Unterstützung der Dienstkontinuität erforderlich sind, beispielsweise, wenn eine bestimmte MEC-App 2426 eine einzelne Information unter Verwenden eines einfachen Anfrage-Antwort-Modells (zum Beispiel unter Verwenden von RESTful-Mechanismen) anfordert, während andere MEC-Apps 2426 mehrere unterschiedliche Benachrichtigungen im Zusammenhang mit Informationsänderungen (zum Beispiel unter Verwenden eines Pub/Sub-Mechanismus und/oder Message-Broker-Mechanismen) abonnieren.
  • Wenn verfügbar, kann die LS autorisierte MEC-Anwendungen 2426 mit ortsbezogenen Informationen versorgen und derartige Informationen zu den MEC-Anwendungen 2426 ausgeben. Mit ortsbezogenen Informationen führen die MEC-Plattform 2432 oder eine oder mehrere MEC-Apps 2426 aktive Vorrichtungsortsverfolgung, ortsbasierte Dienstempfehlungen und/oder andere ähnliche Dienste aus. Die LS unterstützen den Ortsabrufmechanismus, zum Beispiel wird der Ort nur einmal für jede Ortsinformationsanforderung gemeldet. Die LS unterstützen zum Beispiel einen Ortsabonnierungsmechanismus, wobei der Ort mehrere Male für jede Ortsanfrage periodisch oder basierend auf spezifischen Ereignissen, wie eine Ortsänderung, gemeldet werden kann. Die Ortsinformationen können unter anderem den Ort spezifischer UEs 2420, die aktuell von dem oder den Funkknoten(en) bedient werden, die mit dem MEC-Server 2402 assoziiert sind, Informationen über den Ort aller UEs 2420, die aktuell von dem oder den Funkknoten(en) bedient werden, die mit dem MEC-Server XE136 assoziiert sind, Informationen über den Ort einer bestimmten Kategorie von UEs 2420, die gegenwärtig von dem oder den Funkknoten bedient werden, die mit dem MEC-Server XE136 assoziiert sind, eine Liste von UEs 2420 an einem bestimmten Ort, Informationen über den Ort aller Funkknoten, die gegenwärtig mit dem MEC-Host 2402 assoziiert sind, und/oder dergleichen. Die Ortsinformationen können in Form einer Geolokation, einer Global-Navigation-Satellite-Service-Koordinate (GNSS-Koordinate), einer Zellenidentität (Cell Identity - ID) und/oder dergleichen vorliegen. Die LS ist über die API zugänglich, die in der Spezifikation Open Mobile Alliance (OMA) „RESTful-Network API for Zonal Preference“ OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C definiert ist. Der Zonenpräsenzdienst nutzt das Konzept einer „Zone“, wobei eine Zone verwendet werden kann, um alle Funkknoten, die mit einem MEC-Host 2402 assoziiert sind, oder einen Teilsatz davon, gemäß einem gewünschten Einsatz zu gruppieren. In diesem Hinblick stellt die OMA-Zonal-Presence-API Mittel für MEC-Anwendungen 2426 bereit, um Informationen über eine Zone, die mit den Zonen assoziierten Zugangspunkte und die Benutzer, die mit den Zugangspunkten verbunden sind, abzurufen. Zusätzlich erlaubt die OMA-Zonal-Presence-API, dass eine autorisierte Anwendung einen Benachrichtigungsmechanismus abonniert, wobei sie Benutzeraktivitäten innerhalb einer Zone meldet. Ein MEC-Server 2402 kann unter Verwenden der OMA-Zonenpräsenz-API auf Ortsinformationen oder Zonenpräsenzinformationen einzelner UEs 2420 zugreifen, um den relativen Ort oder die relativen Positionen der UEs 2420 zu identifizieren.
  • Der TMS erlaubt es Edge-Apps, über verschiedene Verkehrsverwaltungsfähigkeiten und Mehrfachzugriffsnetzwerkverbindungsinformationen informiert zu werden, und erlaubt es Edge-Anwendungen, Anforderungen, zum Beispiel Verzögerung, Durchsatz, Verlust, zum Beeinflussen von Verkehrsverwaltungsvorgängen bereitzustellen. Bei einigen Umsetzungen beinhaltet der TMS Mehrfachzugriffsverkehrslenkung (Multi-Access Traffic Steering - MTS), die nahtlos Lenken, Aufteilen und Duplizieren von Anwendungsdatenverkehr über Mehrfachzugriffsnetzverbindungen ausführt. Der BWMS stellt die Zuordnung von Bandbreite zu einem bestimmten Verkehr bereit, der zu und von MEC-Anwendungen 2426 geroutet wird, und statische/dynamische Aufwärts/Abwärts-Bandbreitenressourcen spezifiziert, einschließlich Bandbreitengröße und Bandbreitenpriorität. Die MEC-Apps 2426 können den BWMS verwenden, um Bandbreiteninformationen zu/von der MEC-Plattform 2432 zu aktualisieren/zu empfangen. Unterschiedlichen MEC-Anwendungen 2426, die parallel auf demselben MEC-Server 2402 laufen, können spezifische statische, dynamische Aufwärts/Abwärts-Bandbreitenressourcen, einschließlich Bandbreitengröße und Bandbreitenpriorität, zugewiesen werden. Der BWMS beinhaltet eine Bandbreitenverwaltungs-API (BWMAPI), um es registrierten Anwendungen zu erlauben, sich statisch und/oder dynamisch für spezifische Bandbreitenzuordnungen pro Sitzung/Anwendung zu registrieren. Die BWM-API beinhaltet HTTP-Protokollbindungen für BWM-Funktionalität unter Verwenden von RESTful-Diensten oder einem anderen geeigneten API-Mechanismus. Der BWM-Dienst dient zum Zuordnen/Anpassen von BW-Ressourcen für MEC-Apps und erlaubt es MEC-Apps, ihre BW-Anforderungen bereitzustellen.
  • Unterschiedliche MEC-Anwendungen 2426, die parallel auf demselben MEC-Host laufen, können spezifische statische/dynamische Aufwärts-/Abwärtsbandbreiten-Ressourcen (BW-Ressourcen), einschließlich BW-GRÖSSE und BW-Priorität, erfordern. Teilweise können unterschiedliche Sessions, die parallel auf derselben App laufen, jeweils spezifische BW-Anforderungen aufweisen. Zusätzlich können Sitzungen, die von Apps getrieben werden, die von näher an Endbenutzern (zum Beispiel kürzere RTT) laufen, einen unfairen Vorteil gegenüber Sitzungen empfangen, die von Apps getrieben werden, die von entfernten Orten (zum Beispiel außerhalb des RAN) laufen. Um potenzielle Ressourcenkonflikte zwischen derartigen konkurrierenden Anwendungen zu lösen, können BWM und/oder Multi-Access-TrafficSteering-Dienste (MTS-Dienste) verwendet werden. Die MTS-Dienste können als Teil des BWMS oder getrennt vom BWMS bereitgestellt werden. Der MTS-Dienst dient zum nahtlosen Lenken/Teilen/Duplizieren von App Datenverkehr über Mehrfachzugangsnetzwerkverbindungen. Der MTS-Dienst erlaubt es Apps/MEC-Apps, über verschiedene MTS-Fähigkeiten und MX-Netzwerkverbindungs-Info informiert zu werden. Der MTS erlaubt es MEC-Apps auch, Anforderungen (zum Beispiel Verzögerung, Durchsatz, Verlust usw.) zum Beeinflussen von Verkehrsmanagementvorgängen bereitzustellen. Die spezifische Sitzung oder App/MEC-App kann unter Verwenden eines Satzes von Filtern und/oder Identifikatoren (IDs) innerhalb der Ressourcenanforderung identifiziert werden.
  • Der Zweck des UE-Identitätsmerkmals besteht darin, UE-spezifische Verkehrsregeln in dem MEC-System 2400 zu erlauben. Wenn das MEC-System 2400 das UE-Identitätsmerkmal unterstützt, stellt die MEC-Plattform 2432 die Funktionalität (zum Beispiel UE-Identitäts-API) für eine MEC-App 2426 bereit, um ein Tag, das ein UE 2420 darstellt, oder eine Liste von Tags, die jeweilige UEs 2420 darstellen, zu registrieren. Jedes Tag wird in ein spezifisches UE 2420 in dem System des MNO abgebildet, und die MEC-Plattform 2432 wird mit den Abbildungsinformationen versehen. Die UE-Identität-Tag-Registrierung löst die MEC-Plattform 2432 aus, um die entsprechende(n) Verkehrsregel(n) 2440, die mit dem Tag verknüpft ist (sind), zu aktivieren. Die MEC-Plattform 2432 stellt auch die Funktionalität (zum Beispiel UE-Identität-API) für eine MEC-Anwendung 2426 bereit, um eine Abmeldevorgehensweise aufzurufen, um die Verwendung der Verkehrsregel für diesen Benutzer zu deaktivieren oder anderswie zu stoppen.
  • Der WAIS ist ein Dienst, der Dienstverbraucher innerhalb des MEC-Systems 2400 mit WLAN-Zugriff zusammenhängende Informationen bereitstellt. Der WAIS ist für autorisierte MEC-Apps 2426 verfügbar und wird ü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 Client-Stationen können entweder durch Abfragen oder durch Subskribieren von Benachrichtigungen angefordert werden, die jeweils attributbasierte Filterung und Attributselektoren beinhalten.
  • Der FAIS ist ein Dienst, der Dienstverbraucher innerhalb des MEC-Systems 2400 mit Festzugangsnetzinformationen (oder FAI) versorgt. Der FAIS ist für die autorisierten MEC-Apps 2426 verfügbar und wird über den Mp1-Referenzpunkt entdeckt. Die FAI kann von den MEC-Anwendungen 2426 und der MEC-Plattform 2432 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen von dem festen Zugang (zum Beispiel NANs) basieren, möglicherweise kombiniert mit anderen Informationen, wie etwa RI- oder WLAN-Informationen, von anderen Zugangstechnologien. Dienstverbraucher interagieren mit dem FAIS über die FAI-API, um Kontextinformationen von dem Festzugangsnetzwerk zu erhalten. Sowohl die MEC-Anwendungen 2426 als auch die MEC-Plattform 2432 können den FAIS verbrauchen; und sowohl die MEC-Plattform 2432 als auch die MEC-Anwendungen 2426 können die Anbieter der FAI sein. Die FAI-API unterstützt sowohl Anfragen als auch Subskriptionen (Pub/Sub-Mechanismus), die über die RESTful API oder über alternative 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-Plattformmanager 2406 und den VI-Manager (VIM) 2408 und handhabt die Verwaltung der MEC-spezifischen Funktionalität eines bestimmten MEC-Servers 2402 und der darauf laufenden Anwendungen. Bei einigen Umsetzungen können einige oder alle der Mehrfachzugriffs-Edge-Verwaltungskomponenten von einem oder mehreren Server umgesetzt 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-Plattformmanager 2406 ist für das Verwalten des Lebenszyklus von Anwendungen zuständig, einschließlich Informieren des MEC-Orchestrators (MEC-O) 2410 über relevante anwendungsbezogene Ereignisse. Der MEC-Plattformmanager 2406 kann der MEC-Plattform 2432 auch MEC-Plattformelement-Verwaltungsfunktionen 2444 bereitstellen, MEC-App-Regeln und Anforderungen 2446 einschließlich Dienstberechtigungen, Verkehrsregeln, DNS-Konfiguration und Lösen von Konflikten verwalten sowie die MEC-App-Lebenszyklenverwaltung 2448 verwalten. Der MEC-Plattformmanager 2406 kann auch virtualisierte Ressourcen, Fehlermeldungen und Leistungsfähigkeitsmessungen von dem VIM 2408 zur weiteren Verarbeitung empfangen. Der Mm5-Referenzpunkt zwischen dem MEC-Plattformmanager 2406 und der MEC-Plattform 2432 wird verwendet, um Plattformkonfiguration, Konfiguration der MEC-Plattformelementverwaltung 2444, MEC-App-Regeln und - Anforderungen 2446, MEC-App-Lebenszyklenverwaltung 2448 und Verwaltung der Anwendungsumlagerung auszuführen.
  • Der 2408 kann eine Entität sein, die virtualisierte (Rechen-, Speicher- und Networking-) Ressourcen der VI 2422 zuweist, verwaltet und freigibt und die VI 2422 auf das Ausführen eines Softwarebildes vorbereitet. Dazu kann der VIM 2408 mit der VI 2422 über den Mm7-Referenzpunkt zwischen dem VIM 2408 und der VI 2422 kommunizieren. Das Vorbereiten der VI 2422 kann das Konfigurieren der VI 2422 und Empfangen/Speichern des Softwarebildes beinhalten. Sofern unterstützt, kann der VIM 2408 eine schnelle Bereitstellung von Anwendungen bereitstellen, wie in „Openstack++ for Cloudlet Deployments“, erhältlich bei http://reportsarchive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf, beschrieben. Der VIM 2408 kann auch Leistungsfähigkeits- und Fehlerinformationen über die virtualisierten Ressourcen sammeln und melden sowie eine Anwendungsumlagerung ausführen, wenn dies unterstützt wird. Zur Anwendungsumlagerung von/zu externen Cloud-Umgebungen kann der VIM 2408 mit einem externen Cloud-Manager interagieren, um die Anwendungsumlagerung auszuführen, zum Beispiel unter Verwenden des in „Adaptive VM Handoff Across Clouds“ beschriebenen Mechanismus und/oder möglicherweise durch einen Proxy. Darüber hinaus kann der VIM 2408 mit dem MEC-Plattform-Manager 2406 ü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 2408 mit dem MEC-0 2410 über den Mm4-Referenzpunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen des MEC-Servers 2402 zu verwalten und Anwendungsbilder zu verwalten. Das Verwalten der virtualisierten Ressourcen kann das Verfolgen verfügbarer Ressourcenkapazität usw. beinhalten.
  • Die MEC-Systemebenenverwaltung beinhaltet den MEC-0 2410, der einen Überblick über das vollständige MEC-System 2400 hat. Der MEC-0 2410 kann eine Gesamtansicht des MEC-Systems 2400 basierend auf eingesetzten MEC-Hosts 2402, verfügbaren Ressourcen, verfügbaren MEC-Diensten 2436 und Topologie führen. Der Mm3-Referenzpunkt zwischen dem MEC-0 2410 und dem MEC-Plattformmanager 2406 kann für das Management des Anwendungslebenszyklus, der Anwendungsregeln und -anforderungen sowie für das Verfolgen verfügbarer MEC-Dienste 2436 verwendet werden. Der MEC-0 2410 kann mit dem UALCMP 2414 über den Mm9-Referenzpunkt kommunizieren, um MEC-Anwendungen 2426 zu verwalten, die von der UE-Anwendung 2418 angefordert werden.
  • Der MEC-0 2410 kann auch für das Onboarding von Anwendungspaketen verantwortlich sein, einschließlich für das Überprüfen der Integrität und Authentizität der Pakete, Validieren von Anwendungsregeln und Anforderungen sowie, falls notwendig, das Anpassen derselben, um Betreiberrichtlinien zu erfüllen, wobei Onboard-Pakete protokolliert werden und der (die) VIM(s) 2408 zum Handhaben der Anwendungen vorbereitet wird (werden). Der MEC-0 2410 kann einen oder mehrere geeignete MEC-Host(s) 901 zur Anwendungsinstanziierung basierend auf Einschränkungen, wie Latenz, verfügbaren Ressourcen und verfügbaren Diensten, auswählen. Der MEC-0 2410 kann auch eine Anwendungsinstanziierung und -beendigung auslösen sowie eine Anwendungsumlagerung nach Bedarf und sofern unterstützt auslösen.
  • Das Operations Support System (OSS) 2412 ist das OSS eines Betreibers, der Anfragen über das Customer-Facing-Service-Portal (CFS-Portal) 2416 über den Mx1-Referenzpunkt und von UE-Apps 2418 zur Instanziierung oder Beendigung von MEC-Apps 2426 empfängt. Der OSS 2412 entscheidet über die Gewährung dieser Anforderungen. Das CFS-Portal 2416 (und die Mx1-Schnittstelle) kann von Drittparteien verwendet werden, um das MEC-System 2400 aufzufordern, Apps 2418 in dem MEC-System 2400 auszuführen. Gewährte Anforderungen können an den MEC-0 2410 zur weiteren Verarbeitung weitergeleitet werden. Sofern unterstützt, empfängt der OSS 2412 auch Anforderungen von UE-Apps 2418 zum Umlagern von Anwendungen zwischen externen Clouds und dem MEC-System 2400. Der Mm2-Referenzpunkt zwischen dem OSS 2412 und dem MEC-Plattform-Manager 2406 wird für das Konfigurations-, Fehler- und Leistungsfähigkeitsmanagement des MEC-Plattform-Managers 2406 verwendet. Der Mm1-Referenzpunkt zwischen dem MEC-0 2410 und dem OSS 2412 wird zum Auslösen der Instanziierung und des Abschlusses von MEC-Apps 2426 in dem MEC-System 2400 verwendet.
  • Die UE-APP(s) 2418 (auch als „Vorrichtungsanwendungen“ oder dergleichen bezeichnet) ist eine oder mehrere Apps, die in einer Vorrichtung 2420 laufen, die die Fähigkeit aufweist (aufweisen), mit dem MEC-System 2400 über den UALCMP 2414 zu interagieren. Die UE-APP(s) 2418 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 2418 läuft, die Funktionalität nutzt, die von einer oder mehreren spezifischen MEC-Anwendungen 2426 bereitgestellt wird. Der UALCMP 2414 kann Anfragen von UE-Apps 2418 in dem UE 2420 autorisieren und interagiert mit dem OSS 2412 und dem MEC-0 2410 zur weiteren Verarbeitung dieser Anfragen. Der Begriff „Lebenszyklusverwaltung“ betrifft im Kontext von MEC einen Satz von Funktionen, die erforderlich sind, um die Instanziierung, Führung und Beendigung einer MEC-App 2426-Instanz zu verwalten. Der UALCMP 2414 kann über den Mm8-Referenzpunkt mit dem OSS 2412 interagieren und wird verwendet, um Anfragen des UE 2418 zum Ausführen von Anwendungen in dem MEC-System 2400 zu handhaben. Eine Benutzer-App kann eine MEC-App 2426 sein, die in dem MEC-System 2400 als Reaktion auf eine Anforderung eines Benutzers über eine Anwendung instanziiert wird, die in dem UE 2420 läuft, (zum Beispiel UE-APP 2418). Der UALCMP 2414 erlaubt UE-Apps 2418 Onboarding, Instanziierung, Beendigung von Benutzeranwendungen und, sofern unterstützt, Umlagerung von Benutzeranwendungen in das MEC-System 2400 hinein und aus diesem heraus anzufordern. Er erlaubt es auch, Benutzer-Apps über den Zustand der Benutzer-Apps zu informieren. Der UALCMP 2414 ist nur von innerhalb des Mobilfunknetzwerks zugänglich und kann nur verfügbar sein, wenn er von dem MEC-System 2400 unterstützt wird. Eine UE-APP 2418 kann den Mx2-Referenzpunkt zwischen dem UALCMP 2414 und der UE-APP 2418 verwenden, um das MEC-System 2400 aufzufordern, eine Anwendung in dem MEC-System 2400 auszuführen oder eine Anwendung in das oder aus dem MEC-System 2400 zu bewegen. Der Mx2-Referenzpunkt kann nur innerhalb des Mobilfunknetzwerks zugänglich sein und kann nur verfügbar sein, wenn er von dem MEC-System 2400 unterstützt wird.
  • Um eine MEC-Anwendung 2426 in dem MEC-System 2400 auszuführen, empfängt der MEC-0 2410 Anfragen, die von dem OSS 2412, einer Drittpartei oder einer UE-Anwendung 2418 ausgelöst werden. Als Reaktion auf den Empfang derartiger Anforderungen, wählt der MEC-O 2410 einen MEC-Server/Host 2402 aus, um die MEC-Anwendung 2426 zum rechnerischen Abladen usw. zu hosten. Diese Anforderungen können Informationen über die auszuführende Anwendung und möglicherweise andere Informationen, wie etwa den Ort, an dem die Anwendung aktiv sein muss, andere Anwendungsregeln und -anforderungen sowie den Ort des Anwendungsbildes, falls es sich noch nicht in dem MEC-System 2400 befindet, beinhalten.
  • Der MEC-0 2410 kann einen oder mehrere MEC-Server 2402 für rechenintensive Aufgaben auswählen. Der eine oder die mehreren ausgewählten MEC-Server XE136 können Rechenaufgaben einer UE-APP 2418 basierend auf verschiedenen Betriebsparametern, wie etwa 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-Anwendungen 2426 assoziiert sind, wie etwa ein Einsatzmodell der Anwendung (ob es zum Beispiel eine Instanz pro Benutzer, eine Instanz pro Host, eine Instanz auf jedem Host usw. ist); erforderliche virtualisierte Ressourcen (zum Beispiel Berechnen, Speichern, Netzwerkressourcen, einschließlich spezifischer Hardwareunterstützung); Latenzanforderungen (zum Beispiel maximale Latenz, wie streng die Latenzbeschränkungen sind, Latenzfaimess zwischen Benutzern); Anforderungen vor Ort; Mehrfachzugriffs-Edge-Dienste, die erforderlich und/oder nützlich sind, damit die MEC-Anwendungen 2426 laufen können; Mehrfachzugriffs-Edge-Dienste, die die MEC-Anwendungen 2426 nutzen können, falls verfügbar; Konnektivität oder Mobilitätsunterstützung/anforderungen (zum Beispiel Anwendungszustandsumlagerung, Anwendungsinstanzumlagerung); erforderliche Mehrfachzugriffs-Edge-Merkmale, wie etwa VM-Umlagerungsunterstützung oder UE-Identität; erforderliche Netzwerkkonnektivität (zum Beispiel Konnektivität mit Anwendungen innerhalb des MEC-Systems 2400, Konnektivität mit lokalen Netzwerken oder mit dem Internet); Informationen über den Einsatz des MEC-Systems 2400 oder den Einsatz des Mobilfunknetzwerks des Betreibers (zum Beispiel Topologie, Kosten); Anforderungen an den Zugriff auf Benutzerverkehr; Anforderungen an eine dauerhafte Speicherung; Verkehrsregeln 2440; DNS-Regeln 2442; usw.
  • Der MEC-0 2410 berücksichtigt die oben aufgelisteten Anforderungen und Informationen sowie Informationen über die aktuell im MEC-System 2400 verfügbaren Ressourcen, um einen oder mehrere MEC-Server 2402 zum Hosten von MEC-Anwendungen 2426 und/oder zum rechnerischen Abladen auszuwählen. Nachdem ein oder mehrere MEC-Server XE136 ausgewählt wurden, fordert der MEC-0 2410 den oder die ausgewählten MEC-Hosts 2402 auf, die Anwendung(en) oder Anwendungsaufgaben zu instanziieren. Der tatsächliche Algorithmus, der zum Auswählen der MEC-Server 2402 verwendet wird, hängt von der Umsetzung, Konfiguration und/oder dem Bedienereinsatz ab. Der eine oder die mehreren Auswahlalgorithmen können auf den Aufgaben-Offloading-Kriterien/-parametern basieren, indem zum Beispiel Netzwerk-, Rechen- und Energieverbrauchsanforderungen zum Ausfü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 (zum Beispiel UE-Mobilitätsereignisse, die zu erhöhter Latenz führen, Lastausgleichsentscheidungen usw.), und, sofern unterstützt, kann der MEC-0 2410 entscheiden, einen oder mehrere neue MEC-Hosts 2402 auszuwählen, die als ein Primär-/Quellknoten fungieren sollen, und initiiert die Übertragung einer Anwendungsinstanz oder anwendungsbezogener Zustandsinformationen von dem einen oder den mehreren Quell-MEC-Hosts 2402 zu dem einen oder den mehreren Ziel-MEC-Hosts 2402.
  • Bei einer ersten Umsetzung wird eine UPF 2948 des 5GS als die MEC-Datenebene 2424 in die MEC-Architektur 2400 abgebildet. Bei dieser Umsetzung behandelt die UPF 2948 den Up-Pfad von PDU-Sitzungen. Zusätzlich stellt die UPF 2948 die Schnittstelle zu einem Datennetzwerk bereit und unterstützt die Funktionalität eines PDU-Sitzungsankers.
  • Bei einer zweiten Umsetzung wird eine Anwendungsfunktion (AF) des 5GS in die MEC-Architektur 2400 als die MEC-Plattform 2432 abgebildet. Bei diesen Umsetzungen ist die AF konfigurierbar oder betreibbar, um einen Anwendungseinfluss auf Verkehrsrouten, Zugangsnetzwerkfähigkeitsaufdeckung auszuführen und mit dem Richtlinien-Framework zur Framework-Steuerung zu interagieren. Die zweite Umsetzung kann mit der ersten Umsetzung kombiniert werden oder kann eine eigenständige Umsetzung sein. Da Benutzerverkehr zu dem lokalen DN geleitet wird, können bei der ersten und/oder zweiten Umsetzung MEC-Apps 2426, 2427 und/oder 2428 in oder zu dem DN des 5GS abgebildet werden.
  • Bei einer dritten Umsetzung kann das RAN von 5GS ein virtuelles RAN basierend auf einer VNF sein, und die UPF 2948 ist konfigurierbar oder funktionsfähig, um als die MEC-Datenebene 2424 innerhalb einer NF-Virtualisierungsinfrastruktur (NF Virtualization Infrastructure) zu fungieren (zum Beispiel VI 2422). Bei diesen Umsetzungen kann die AF als MEC-Plattform-VNF mit MEC-APIs, MEC-App-Aktivierungsfunktionalität und API-Prinzipienfunktionalität konfiguriert sein. Außerdem beinhalten die lokalen DN MEC-Apps 2426, 2427 und/oder 2428, die als VNFs instanziiert sind. Diese Umsetzung kann dazu konfiguriert sein, Funktionalitäten gemäß [MEC003] und/oder ETSI GR MEC 017 VI. 1.1 (2018-02) („[MEC017]“) bereitzustellen. Die dritte Umsetzung kann mit der ersten Umsetzung und/oder der zweiten Umsetzung kombiniert werden oder kann eine eigenständige Umsetzung sein.
  • Zusätzlich oder alternativ kann die Zugangsebenen-Edge (zum Beispiel die verschiedenen hierin besprochenen NANs und/oder (R)ANs) eine oder mehrere APIs verwenden, um mit Edge-Netzwerken auf lokaler/regionaler Ebene zu kommunizieren. Die Edge-Netzwerke auf lokaler/regionaler Ebene können Netzwerkknoten beinhalten, die entsprechende Anwendungen verwenden, um mit einem Edge-Netzwerk auf nationaler Ebene zu kommunizieren. Die Edge auf nationaler Ebene kann verschiedene NANs beinhalten, die Anwendungen zum Zugreifen auf eine oder mehrere entfernte Clouds innerhalb der Edge auf globaler Ebene verwenden. Die NANs sind auch für vertikale Segmentverwaltung und SLA-Einhaltung konfigurierbar oder betreibbar. Zusätzlich oder alternativ kann MEC-Einsatz auf der Definition von „Edge“ basieren, um MNOs Freiheitsgrade bereitzustellen, insbesondere wenn MEC in einer NFV-Umgebung eingesetzt wird (zum Beispiel MEC-Entitäten können als Virtualisierte NFs (VNFs) instanziiert werden, somit mit hoher Flexibilität hinsichtlich des Einsatzes für den Bediener).
  • Zusätzlich oder alternativ kann das MEC-System 2400 flexibel in Abhängigkeit von dem Verwendungsfall/vertikalen Segment/zu verarbeitenden Informationen eingesetzt werden. Einige Komponenten des MEC-Systems 2400 können gemeinsam mit anderen Elementen des Systems angeordnet sein. Als ein Beispiel muss eine MEC-App 2426 in bestimmten Verwendungsfällen (zum Beispiel 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 braucht das Einsetzen eines MEC-Servers 2402 in einem Datenzentrum (das von dem Zugangsnetzwerk entfernt sein kann) eventuell nicht einige APIs zu hosten, wie etwa die RNI-API (die zum Sammeln von Funknetzwerkinformationen von der Funkbasisstation verwendet werden kann). Andererseits können RNI-Informationen in den Cloud-RAN-Umgebungen (CRAN-Umgebungen) an dem Aggregationspunkt entwickelt und bereitgestellt werden, wodurch die Ausführung geeigneter funkbewusster Verkehrsverwaltungsalgorithmen ermöglicht wird. Zusätzlich oder alternativ kann eine Bandbreitenverwaltungs-API sowohl auf der Zugriffsebenen-Edge als auch an entfernteren Edge-Orten vorhanden sein, um Transportnetzwerke (zum Beispiel für CDN-basierte Dienste) einzurichten.
  • 25 veranschaulicht eine MEC-Referenzarchitektur 2500 in einer NFV-Umgebung. Die MEC-Architektur 2500 weist eine MEC-Plattform 2502, eine MEC-Plattform-Manager-NFV (MEPM-V) 2514, eine Datenebene 2508, eine NFV-Infrastruktur (NFVI) 2510, VNF-Manager (VNFMs) 2520 und 2522, NFV-Orchestrator (NFVO) 2524, einen MEC-App-Orchestrator (MEAO) 2526, ein OSS 2528, einen Benutzer-App-LCM-Proxy 2530, eine UE-App 2534 und ein CFS-Portal 2532 auf. Der MEC-Plattform-Manager 2514 kann eine MEC-Plattformelementverwaltung 2516 und eine MEC-App-Regel- und -Anforderungsverwaltung 2518 beinhalten. Die MEC-Plattform 2502 kann über eine MP3-Schnittstelle mit einer anderen MEC-Plattform 2506 gekoppelt sein.
  • Bei diesen Ausführungsformen wird die MEC-Plattform 2502 als eine VNF eingesetzt. Die MEC-Anwendungen 2504 können gegenüber den ETSI-NFV-Verwaltungs- und -Orchestrierungs-Komponenten (MANO-Komponenten) wie VNFs wirken. Dies erlaubt eine Wiederverwendung von ETSI-NFV-MANO-Funktionalität. Der gesamte Satz an MANO-Funktionalität kann ungenutzt sein, und es kann eine bestimmte zusätzliche Funktionalität benötigt werden. Eine derartige spezifische MEC-App wird als „MEC-App-VNF“ oder „MEA-VNF“ bezeichnet. Die Virtualisierungsinfrastruktur wird als eine NFVI 2510 eingesetzt, und ihre virtualisierten Ressourcen werden von dem Virtualisierungsinfrastruktur-Manager (VIM) 2512 verwaltet. Hierzu können eine oder mehrere der von ETSI-NFV-Infrastrukturspezifikationen definierten Vorgehensweisen verwendet werden (siehe zum Beispiel 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) (zusammenfassend „[ETSINFV]“)). Die MEA-VNF 2504 werden wie individuelle VNFs verwaltet, was es erlaubt, dass ein MEC-in-NFV-Einsatz bestimmte Orchestrierungs- und LCM-Aufgaben an den NFVO 2524 und die VNFMs 2520 und 2522, wie von ETSI-NFV-MANO definiert, delegieren kann.
  • Wenn eine MEC-Plattform als eine VNF (zum Beispiel MEC-Plattform VNF 2502) umgesetzt ist, kann die MEPM-V 2514 dazu konfiguriert sein, als ein Elementmanager (EM) zu fungieren. Der MEAO 2526 verwendet den NFVO 2524 zur Ressourcenorchestrierung und zur Orchestrierung des Satzes von MEA-VNFs 2504 als einen oder mehrere NFV-Netzwerkdienste (NSs). Die MEPM-V 2514 delegiert den LCM-Teil an einen oder mehrere VNFMs 2520 und 2522. Ein spezieller oder generischer VNFM 2520, 2522 wird/werden verwendet, um LCM auszuführen. Die MEPM-V 2514 und der VNFM (ME-Plattform LCM) 2520 können als ein einziges Paket gemäß dem Ensemblekonzept in 3GPP TR 32.842 v13.1.0 (2015-12-21) („[TR32842]“) eingesetzt werden, oder dass der VNFM ein generisches VNFM gemäß [ETSINFV] ist und die MEC-Plattform VNF 2502 und die MEPM-V 2514 von einem einzigen Anbieter bereitgestellt werden.
  • Der Mp1-Referenzpunkt zwischen einer MEC-App 2504 und der MEC-Plattform 2514 kann für die MEC-App 2504 optional sein, es sei denn, es handelt sich um eine Anwendung, die einen MEC-Dienst bereitstellt und/oder verbraucht. Der Mm3*-Referenzpunkt zwischen MEAO 2526 und der MEPM-V 2514 basiert auf dem Mm3-Referenzpunkt (siehe zum Beispiel [MEC003]). Änderungen können zu diesem Referenzpunkt konfiguriert werden, um für die Aufteilung zwischen MEPM-V 2514 und VNFM (ME-Anwendungs-LCM) 2522 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 2504 zu unterstützen.
  • Die folgenden Referenzpunkte betreffen existierende NFV-Referenzpunkte, aber nur ein Teilsatz der Funktionalität kann für ETSI-MEC verwendet werden und Erweiterungen können notwendig sein. Mv1 ist ein Referenzpunkt, der den MEAO 2526 und den NFVO 2524 verbindet, und betrifft den Os-Ma-nfvo-Referenzpunkt, wie in ETSI NFV definiert. Mv2 ist ein Referenzpunkt, der den VNFM 2522, der das LCM der MEC-App-VNFs 2504 ausführt, mit der MEPM-V 2514 verbindet, um zu erlauben, dass LCM-bezogene Benachrichtigungen zwischen diesen Entitäten ausgetauscht werden. Mv2 betrifft den Ve-Vnfm-em-Referenzpunkt, wie in ETSI NFV definiert, kann aber möglicherweise Ergänzungen beinhalten und verwendet eventuell nicht alle Funktionalität, die von dem Ve-Vnfm-em angeboten wird. Mv3 ist ein Referenzpunkt, der den VNFM 2522 mit der ME-APP VNF-Instanz 2504 verbindet, um den Austausch von Nachrichten (zum Beispiel im Zusammenhang mit MEC-App LCM oder anfänglicher einsatzspezifischer Konfiguration) zu erlauben. Mv3 betrifft den Ve-Vnfm-vnf-Referenzpunkt, wie in ETSI NFV definiert, kann aber Ergänzungen beinhalten und verwendet eventuell nicht die gesamte Funktionalität, die von Ve-Vnfm-vnf angeboten wird.
  • Folgende Referenzpunkte werden verwendet, wie sie von ETSI NFV definiert sind: Der Nf-Vn-Referenzpunkt verbindet jede ME-App-VNF 2504 mit der NFVI 2510. Der Nf-Vi-Referenzpunkt verbindet die NFVI 2510 und den VIM 2512. Der Os-Ma-nfvo-Referenzpunkt verbindet den OSS 2528 und den NFVO 2524 und wird hauptsächlich verwendet, um NSs zu verwalten (zum Beispiel eine Anzahl von VNFs, die verbunden und orchestriert sind, um einen Dienst zu liefern). Der Or-Vnfm-Referenzpunkt verbindet den NFVO 2524 und den VNFM (MEC-Plattform-LCM) 2520 und wird hauptsächlich für den NFVO 2524 verwendet, um VNF-LCM-Operationen aufzurufen. Der Vi-Vnfm-Referenzpunkt verbindet den VIM 2512 und den VNFM (MEC-Plattform-LCM) 2520 und wird primär von dem VNFM 2520 verwendet, um Ressourcenverwaltungsoperationen aufzurufen, um Cloud-Ressourcen zu verwalten, die von der VNF benötigt werden (bei NFV-basiertem MEC-Einsatz wird davon ausgegangen, dass dieser Referenzpunkt 1:1 Mm6 entspricht). Der Or-Vi-Referenzpunkt verbindet den NFVO 2524 und den VIM 2512 und wird primär von dem NFVO 2524 verwendet, um Cloud-Ressourcenkapazität zu verwalten. Der Ve-Vnfm-em-Referenzpunkt verbindet den VNFM (MEC-Plattform-LCM) 2520 mit der MEPM-V 2514. Der Ve-Vnfm-vnf-Referenzpunkt verbindet den VNFM (MEC-Plattform-LCM) 2520 mit der MEC-Plattform-VNF 2502.
  • 26 stellt eine Variante der Mehrfachzugriffs-Edge-Systemreferenzarchitektur für den Einsatz in einem MEC-Verbund dar. Zusätzlich zu den Definitionen für die MEC-Referenzarchitektur 2400 der 24 (siehe auch Klausel 6.1 von [MEC003]) wird eine zusätzliche MEC-Verbundverwaltungsstufe zu der MEC-Referenzarchitektur 2400 hinzugefügt, die zwei Entitäten beinhaltet: einen MEC-Verbund-Broker (MEFB) 2610 und einen MEC-Verbundmanager (MEFM) 2620. Der MEFM 2620 ist in einem MEC-System 2400 enthalten, um einen Verbund mit einem anderen System, wie etwa einem anderen MEC-System 2400 oder einem Cloud-System/einer Edge-Cloud 2650 (das/die dem Edge-System 1235, der Cloud 1244, der Edge-Cloud 1310 und/oder dergleichen entsprechen kann) einzurichten. Der MEFM 2620 ist für das Veröffentlichen von Details der Fähigkeiten verantwortlich, die das MEC-System 2400 bereitstellt, während dem MEC-System 2400 ein Zugangspunkt für die Fähigkeiten und Ressourcen anderer Systeme bereitgestellt wird. Wenn der MEFB 2610 vorhanden ist, wird der MEFB 2610 zwischen MEFMs 2620 platziert. Der MEFB 2610 dient dazu, als ein einziger Zugangspunkt für jeden MEFM 2620 zu fungieren, wodurch die Komplexität der MEC-Verbundeinrichtung, die viele MEC-Systeme 2400 involviert, reduziert wird. Die MEFM-Entitäten 2620 unterschiedlicher MEC-Systeme 2400 sind über den MFF-gespeisten Referenzpunkt verbunden, falls es keinen MEFB 2610 gibt, wenn es jedoch einen MEFB 2610 gibt, so kann sich jeder MEFM 2620 stattdessen über den MFF-gespeisten Referenzpunkt damit verbinden. Im Fall einer Verbindung zwischen einem MEC-System mit einem externen Cloud-System 2650 können dieselben Mff-Feed-Referenzpunktdefinitionen wiederverwendet werden. Der Mfm-gespeiste Referenzpunkt verbindet den MEO 2410 des MEC-Systems mit seinem MEFM 2620.
  • 27 eine 5G-dienstbasierte Architektur und eine MEC-Architektur, die in einem beispielhaften Edge-Computing-System einsetzbar sind, sowie einen integrierten MEC-Einsatz in einem 5G-Netzwerk, das mit einem beispielhaften Edge-Computing-System verwendbar ist, veranschaulicht.
  • 27 veranschaulicht einen nicht-integrierten MEC-Einsatz 27A, einschließlich einer 5G-dienstbasierten Architektur 2700 und einer MEC-Architektur 2790, und einen integrierten MEC-Einsatz 27B, einschließlich eines MEC-Systems 2791 in einem 5G-Netzwerk 2701, wobei einige der funktionalen Entitäten des MEC-Systems 2791 mit den NFs des 5G-Netzwerks interagieren. Unter Bezugnahme auf den Einsatz 27A ist die 5G-Systemarchitektur (5GS) 2700 in einer dienstbasierten Darstellung veranschaulicht und beinhaltet Elemente, die gleich oder ähnlich den verschiedenen Elementen der 29 sind. Zum Beispiel beinhaltet das 5GS 2700 die folgenden Entitäten, die auch in der Systemarchitektur 2900 der 29 erscheinen: NSSF 2716, PCF 2722, UDM 2724, AF 2726, AUSF 2710, AMF 2712, SMF 2714, UE 2702, RAN 2704, UPF 2706 und DN 2708. Zusätzlich zu diesen NFs weist die 5GS-Architektur 2800 auch eine Netzwerkaufdeckungsfunktion (Network Exposition Function - NEF) 2718 und eine Netzwerk-Repository-Function (Network Repository Function - NRF) 2720 auf. Die 5GS-Architekturen können dienstbasiert sein und eine Interaktion zwischen NFs kann von entsprechenden Punkt-zu-Punkt-Referenzpunkten Ni oder als SBIs (wie in 27 veranschaulicht) dargestellt werden.
  • Das 5GS 2700 in 27 ist eine dienstbasierte Darstellung, die verwendet wird, um NFs innerhalb der CP darzustellen, die es anderen autorisierten NFs ermöglichen, auf ihre Dienste zuzugreifen. Das 5GS 2700 umfasst folgende dienstbasierte Schnittstellen (SBIs): Namf (eine SBI, die von der AMF 2712 aufgezeigt wird), Nsmf (eine SBI, die von der SMF 2714 aufgezeigt wird), Nnef (eine SBI, die von der NEF 2718 aufgezeigt wird), Npcf (eine SBI, die von der PCF 2722aufgezeigt wird), Nudm (eine SBI, die von dem UDM 2724 aufgezeigt wird), Naf (eine SBI, die von der AF 2726 aufgezeigt wird), Nnrf (eine SBI, die von der NRF 2720 aufgezeigt wird), Nnssf (eine SBI, die von der NSSF 2716 aufgezeigt wird), Nausf (eine SBI, die von der AUSF 2710 aufgezeigt wird). Andere SBIs, die in 27 nicht gezeigt sind, können ebenfalls verwendet werden (zum Beispiel Nudr, N5g-eir und Nudsf).
  • Die NEF 2718 stellt Mittel zum sicheren Aufdecken der Dienste und Fähigkeiten bereit, die von 3GPP-NFs für Drittparteien, interne Aufdeckung/Wiederaufdeckung, AFs 2764, Edge-Computing- oder Fog-Computersysteme usw. bereitgestellt werden. Die NEF 2718 kann die AFs 2764 authentifizieren, autorisieren und/oder drosseln. Die NEF 2718 kann auch Informationen, die mit der/den AF(s) 2764 ausgetauscht werden, und Informationen, die mit internen NFs ausgetauscht werden, übersetzen. Die NEF 2718 kann auch Informationen von anderen NFs basierend auf aufgedeckten Fähigkeiten anderer NFs empfangen. Diese Informationen können in der NEF 2718 als strukturierte Daten oder in einer Datenspeicherungs-NF unter Verwenden standardisierter Schnittstellen gespeichert werden. Die gespeicherten Informationen können dann von der NEF 2718 zu anderen NFs und AFs erneut aufgedeckt werden und/oder für andere Zwecke, wie etwa Analytik, verwendet werden. Bei diesem Beispiel stellt die NEF 2718 eine Schnittstelle zu einem MEC-Host in einem MEC-System 2790, 2791 bereit, die verwendet werden kann, um drahtlose Verbindungen mit dem RAN 2704 zu verarbeiten.
  • Die NRF 2720 unterstützt Dienstentdeckungsfunktionen, empfängt NF-Entdeckungsanforderungen von NF-Instanzen oder dem SCP 2728 und liefert die Informationen der entdeckten (oder zu entdeckenden) NF-Instanzen an die NF-Instanzen oder den SCP 2728. Die NRF 2720 führt NF-Profile verfügbarer NF-Instanzen und ihrer unterstützten Dienste (zum Beispiel NF-Instanz-ID, NF-Typ, PLMN-ID, FQDN oder IP-Adresse von NF, NF-Kapazitätsinformationen, NF-Prioritätsinformationen usw.). Der SCP 2728 (oder einzelne Instanzen des SCP 2728) unterstützt indirekte Kommunikation (siehe zum Beispiel [TS23501] Abschnitt 7.1.1) zwischen zwei oder mehr NFs; delegierte Entdeckung (siehe zum Beispiel [TS23501] Abschnitt 7.1.1); Nachrichtenweiterleitung und -Routing zu Ziel-NF/NF-Dienst(en), Kommunikationssicherheit (zum Beispiel Autorisierung des NF-Dienstverbrauchers zum Zugreifen auf die NF-Diensterzeuger-API (siehe zum Beispiel 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 zum Beispiel [TS23501] Abschnitt 6.3). Lastausgleichs-, Überwachungs-, Überlaststeuerfunktionalität, die von dem SCP 2728 bereitgestellt wird, kann umsetzungsspezifisch sein. Der SCP 2728 kann verteilt eingesetzt werden. Im Kommunikationspfad zwischen verschiedenen NF-Diensten kann mehr als ein SCP 2728 vorhanden sein. Der SCP 2728 kann, obwohl er keine NF-Instanz ist, auch verteilt, redundant und skalierbar eingesetzt werden.
  • Das MEC-System 2790 kann einen MEC-Orchestrator 2770 (der auf einer Systemebene arbeitet) sowie die folgenden MEC-Entitäten, die auf einer verteilten Host-Ebene arbeiten, beinhalten: eine oder mehrere Apps 2772, einen oder mehrere Dienste 2774, eine Virtualisierungsinfrastruktur 2776, eine MEC-Plattform 2778 und einen MEC-Plattformmanager 2780. Auf Komponenten des MEC-Systems 2790 wird weiter unten näher eingegangen.
  • Der integrierte MEC-Einsatz 27B beinhaltet die gleichen MEC- und 5GC-NFs wie in dem zuvor besprochenen nicht-integrierten Einsatz 27A. Bei dieser Umsetzung befindet sich der integrierte MEC-Einsatz 27B mindestens teilweise innerhalb des 5G-Netzwerks 2701. Das 5G-Netzwerk 2701 ist dasselbe wie oder ähnlich wie das 5GS 2700 (und beinhaltet dieselben oder ähnliche NFs), jedoch sind der Übersichtlichkeit halber nicht alle NFs in dem 5G-Netzwerk 2701 gezeigt. Der integrierte MEC-Einsatz 27B kann unter Verwenden einer oder mehrerer der folgenden Techniken konfiguriert werden: (1) Lokales Routing und Verkehrslenkung; (2) Die Fähigkeit einer AF 2726, die UPF 2706 (Neu-)Auswahl und Verkehrslenkung direkt über die PCF 2722 oder indirekt über die NEF 2718 in Abhängigkeit von den Richtlinien des Betreibers zu beeinflussen; (3) Die Sitzungs- und Dienstkontinuitätsmodi (Session and Service Continuity - SSC-Modi) für UE 2702 und Anwendungsmobilitätsszenarien; (4) Unterstützung des lokalen Datennetzwerks (Local Area Data Network - LADN) 2708 durch das 5G-Netzwerk 2701 durch Bereitstellen von Unterstützung zum Verbinden mit dem LADN 2708 in einem bestimmten Bereich, in dem die Apps 2772 eingesetzt werden. Der Zugang zu einem LADN 2708 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 2708 kann als ein Dienst konfiguriert sein, der von dem bedienenden PLMN des UE bereitgestellt wird. Für lokales Routing und Verkehrssteuerung kann das 5G-Netzwerk 2701 dazu konfiguriert sein, Verkehr auszuwählen, der zu den Apps 2772 in der LADN 2708 zu routen ist, die Teil des MEC-Systems 2791 sein kann. Eine PDU-Sitzung kann mehrere N6-Schnittstellen zu dem Datennetzwerk 2708 aufweisen. Die UPFs 2706, die diese Schnittstellen abschließen, können dazu konfiguriert sein, PDU-Sitzungsankerfunktionalität zu unterstützen. Verkehrssteuerung durch die UPF 2706 wird von UL-Klassifikatoren unterstützt, die an einem Satz von Verkehrsfiltern arbeiten, die mit dem gesteuerten Verkehr übereinstimmen, oder alternativ durch IPv6-Multi-Homing, wobei mehrere IPv6-Präfixe mit der betreffenden PDU-Sitzung assoziiert wurden.
  • Die NFs innerhalb des 5G-Netzwerks 2701 und die Dienste, die sie erzeugen, sind in der NRF 2720 registriert, während in dem MEC-System 2791 die Dienste, die von den MEC-Anwendungen 2772 erzeugt werden, in der Dienstregistrierungsdatenbank der MEC-Plattform 2778 registriert sind. Eine Dienstregistrierung kann Teil der Anwendungsfreigabefunktionalität sein. Um den Dienst zu verwenden, kann eine NF, falls autorisiert, direkt mit der NF, die den Dienst erzeugt, interagieren,. Die Liste verfügbarer MEC-Dienste kann von der NRF 2720 entdeckt werden. Einige der Dienste können über die NEF 2718 zugänglich sein, die auch für nicht-vertrauenswürdige Entitäten, die sich außerhalb der Domäne befinden, verfügbar ist, um auf den Dienst zuzugreifen. Anders ausgedrückt kann die NEF 2718 als ein zentralisierter Punkt zur Dienstaufdeckung fungieren und spielt auch eine Schlüsselrolle beim Autorisieren aller Zugriffsanfragen, die von außerhalb des Systems stammen. Vorgehensweisen in Bezug auf Authentifizierung können von der AUSF 2710 bedient werden.
  • Das 5G-Netzwerk 2701 kann Netzwerk-Slicing verwenden, das die Zuordnung der erforderlichen Merkmale und Ressourcen von den verfügbaren NFs zu unterschiedlichen Diensten oder zu Mandanten, die Dienste nutzen, erlaubt. Die Netzwerk-Slice-Auswahlfunktion (Network Slice Selection Function - NSSF) 2716 kann dazu konfiguriert sein, bei der Auswahl geeigneter Netzwerk-Slice-Instanzen für Benutzer und bei der Zuweisung der notwendigen AMF 2712 zu assistieren. Eine MEC-App 2772 (zum Beispiel eine in der verteilten Cloud des MEC-Systems 2790 gehostete Anwendung) kann zu einem oder mehreren Netzwerk-Slices gehören, die in dem 5G-Netzwerk 2701 konfiguriert wurden.
  • Die PCF 2722 ist auch die Funktion, deren Dienste eine AF 2726, wie etwa eine MEC-Plattform 2778, anfordert, um die Verkehrssteuerungsregeln zu beeinflussen. Auf die PCF 2722 kann entweder direkt oder über die NEF 2718 in Abhängigkeit davon zugegriffen werden, ob die AF 2726 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 2724 ist für nutzer- und subskriptionsbezogene Dienste zuständig. Zum Beispiel kann der UDM 2724 dazu konfiguriert sein, 3GPP-Authentifizierungs- und Schlüsselvereinbarungs-Authentifizierungsberechtigungsnachweise (AKA-Authentifizierungsberechtigungsnachweise) zu erzeugen, benutzeridentifizierungsbezogene Informationen zu handhaben, Zugangsautorisierung (zum Beispiel Roaming-Beschränkungen) zu verwalten, die Benutzer-Dienst-NFs (versorgende AMF 2712, SMF 2714) zu registrieren, SMF/DNN-Zuweisungen zu unterstützen, Abfangvorgehensweisen bei abgehendem Roaming durch Fungieren als Kontaktpunkt zu unterstützen und Subskriptionsverwaltungsvorgehensweisen auszuführen.
  • Die UPF 2706 kann dazu konfiguriert sein, um bei einem integrierten MEC-Einsatz in dem 5G-Netzwerk 2701 zu assistieren. UPFs 2706 können aus Sicht des MEC-Systems 2791 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 2706 Teil der MEC-Umsetzung sein, wie bei Einsatz 27B veranschaulicht.
  • Der MEC-Orchestrator 2770 im Einsatz 27B ist eine funktionale Entität auf MEC-Systemebene, die als eine AF 2726 fungiert, mit der NEF 2718 oder in einigen Szenarien direkt mit den Ziel-5G-NFs interagieren kann. Auf der verteilten Host-Ebene (oder „MEC-Host-Ebene“) kann die MEC-Plattform 2778 dazu konfiguriert sein, mit den 5G-NFs wiederum in der Rolle einer AF 2726 zu interagieren. Der MEC-Host (siehe zum Beispiel MEC-Host 2402 in 24) und/oder andere Host-Level-Funktionsentitäten können in einem Datennetzwerk (oder LADN) 2708 in dem 5GS 2700 eingesetzt werden. Während die NEF 2718 als eine 5GC-NF eine Entität auf Systemebene ist, die zentral gemeinsam mit ähnlichen NFs eingesetzt wird, kann eine Instanz der NEF 2718 auch in der Edge eingesetzt werden, um einen Dienstzugriff mit niedriger Latenz und hohem Durchsatz von einem MEC-Host zu erlauben.
  • Beim Einsatz 27B wird das MEC-System 2791 auf dem N6-Referenzpunkt der UPF 2706 eingesetzt, der sich in einem Datennetzwerk 2708 außerhalb des 5GS 2701 befinden kann. Diese Funktionalität kann durch Flexibilität beim Lokalisieren der UPF 2706 ermöglicht werden. Der verteilte MEC-Host kann neben den MEC-Apps 2772 einen Nachrichtenbroker als MEC-Plattformdienst 2774 und einen anderen MEC-Plattformdienst 2774 zum Lenken von Verkehr zu lokalen Beschleunigern aufnehmen. Die Wahl, einen Dienst als MEC-App oder als Plattformdienst auszuführen, kann umsetzungsspezifisch sein und die Ebene der gemeinsamen Nutzung und Authentifizierung berücksichtigen, die für den Zugriff auf den Dienst erforderlich ist. Ein MEC-Dienst 2774, wie etwa ein Nachrichtenbroker, könnte zunächst als eine MEC-App 2772 eingesetzt werden und dann als ein MEC-Plattformdienst 2774 verfügbar werden. Zusätzlich oder alternativ kann ein MEC-Dienst 2774 verwendet werden, um Aspekte der hierin besprochenen Ausführungsformen umzusetzen.
  • MEC-Hosts des MEC-Systems 2791 werden in der Edge oder in einem zentralen Datennetzwerk eingesetzt. Die UPF 2706 kann dazu konfiguriert sein, das Lenken des Aufwärtsverkehrs zu den anvisierten MEC-Apps 2772 in dem DN 2708 zu verwalten. Die Orte des (der) DN(s) 2708 und der UPF(s) 2706 sind eine Auswahl des Netzwerkbetreibers, und der Netzwerkbetreiber kann auswählen, die physischen Rechenressourcen basierend auf technischen und Geschäftsparametern, wie etwa verfügbaren Ortseinrichtungen, 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 2772 einzusetzen sind. Hinsichtlich des physischen Einsatzes von MEC-Hosts können die folgenden Optionen bei unterschiedlichen Aspekten verwendet werden: (1) der MEC-Host und die lokale UPF 2706 sind gemeinsam mit der Basisstation einer Basisstation-Edge-Schicht angeordnet; (2) der MEC-Host ist gemeinsam mit einem Übertragungsknoten angeordnet, der eine lokale UPF 2706 beinhalten kann; (3) der MEC-Host und die lokale UPF 2706 sind gemeinsam mit einem Netzwerkaggregationspunkt angeordnet; und (4) der MEC-Host ist gemeinsam mit den 5G-Kern-NFs (zum Beispiel in demselben Datenzentrum) angeordnet.
  • 28 veranschaulicht eine beispielhafte MEC-Dienstarchitektur 2800. Die MEC-Dienstarchitektur 2800 beinhaltet den MEC-Dienst 2805, die ME-Plattform 2810 (die der MEC-Plattform 2432 entspricht) sowie Anwendungen (Apps) 1 bis N (wobei N eine Zahl ist). Als ein Beispiel kann die App 1 ein(e) CDN-APP/Dienst sein, die (der) 1 bis n Sitzungen hostet (wobei n eine Zahl ist, die gleich oder von N unterschiedlich ist), App 2 kann ein(e) Gaming-App/Dienst sein, die (der) als zwei Sitzungen hostend gezeigt ist, und App N kann irgendein(e) andere(r) App/Dienst sein, die (der) als eine einzelne Instanz (zum Beispiel keine Sitzungen hostend) gezeigt ist. Jede Anwendung kann eine verteilte Anwendung sein, die Aufgaben und/oder Arbeitslasten zwischen Ressourcenanbietern (zum Beispiel Servern, wie etwa der ME-Plattform 2810) und Verbrauchern (zum Beispiel UEs 101, Benutzeranwendungen, die von einzelnen UEs 101 instanziiert werden, anderen Servern/Diensten, Netzwerkfunktionen, Anwendungsfunktionen usw.) partitioniert. Jede Sitzung stellt einen interaktiven Informationsaustausch zwischen zwei oder mehr Elementen dar, wie etwa einer clientseitigen App und ihrer entsprechenden serverseitigen App, einer von einem UE 101 instanziierten Benutzerapp und einer der ME-Plattform 2810 instanziierten MEC-App und/oder dergleichen. Eine Sitzung kann beginnen, wenn die App-Ausführung gestartet oder initiiert wird, und enden, wenn die App die Ausführung verlässt oder beendet. Zusätzlich oder alternativ kann eine Sitzung beginnen, wenn eine Verbindung eingerichtet wird, und enden, wenn die Verbindung beendet wird. Jede App-Sitzung kann einer aktuell laufenden App-Instanz entsprechen. Zusätzlich oder alternativ kann jede Sitzung einer Protocol Data Unit-Sitzung (PDU-Sitzung) oder Mehrfachzugriff-PDU-Sitzung (MA-PDU-Sitzung) entsprechen. Eine PDU-Sitzung ist eine Assoziation zwischen einem UE 1211, 1221 und einem DN, das einen PDU-Konnektivitätsdienst bereitstellt, der ein Dienst ist, der den Austausch von PDUs zwischen einem UE 1211, 1221 und einem Datennetzwerk bereitstellt. Eine MA-PDU-Sitzung ist eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der jeweils ein Zugangsnetzwerk oder gleichzeitig ein 3GPP-Zugangsnetzwerk 110A und ein Nicht-3GPP-Zugangsnetzwerk 110B verwenden kann. Darüber hinaus kann jede Sitzung mit einer Sitzungskennung (ID) assoziiert sein, die aus Daten besteht, die eine Sitzung eindeutig identifizieren, und jede App (oder App-Instanz) kann mit einer APP-ID (oder APP-Instanz-ID) assoziiert sein, die aus Daten besteht, die eine App (oder App-Instanz) eindeutig identifizieren.
  • Der MEC-Dienst 2805 stellt MEC-Dienstverbrauchern (zum Beispiel Apps 1 bis N) einen oder mehrere MEC-Dienste 2436 bereit. Der MEC-Dienst 2805 kann optional als Teil der Plattform (zum Beispiel ME-Plattform 2810) oder als Anwendung (zum Beispiel ME-APP) laufen. Unterschiedliche Anwendungen 1 bis N, unabhängig davon, ob sie eine einzige Instanz oder mehrere Sitzungen verwalten (zum Beispiel CDN), können spezifische Dienstinfo gemäß ihren Anforderungen für die gesamte Anwendungsinstanz oder unterschiedliche Anforderungen pro Sitzung anfordern. Der MEC-Dienst 2805 kann alle Anforderungen aggregieren und auf eine Weise agieren, die helfen wird, die BW-Nutzung zu optimieren und Erfahrungsqualität (QoE) für Anwendungen zu verbessern.
  • Der MEC-Dienst 2805 stellt eine MEC-Dienst-API bereit, die sowohl Anfragen als auch Subskriptionen (zum Beispiel Pub/Sub-Mechanismus) unterstützt, die über eine Representational-State-Transfer-API („REST“ oder „RESTful-“-API) oder über alternative Transporte, wie etwa einen Nachrichtenbus, verwendet werden. Für den RESTful-Architekturstil enthalten die MEC-APIs die HTTP-Protokollbindungen für Verkehrsmanagementfunktionalität.
  • Jede Hypertext-Transfer-Protocol-Nachricht (HTTP-Nachricht) ist entweder eine Anfrage oder eine Antwort. Ein Server hört eine Verbindung auf eine Anforderung hin ab, parst jede empfangene Nachricht, interpretiert die Nachrichtensemantik in Bezug auf das identifizierte Anforderungsziel und beantwortet diese Anforderung mit einer oder mehreren Antwortnachrichten. Ein Client konstruiert Anforderungsnachrichten, um spezifische Absichten zu kommunizieren, untersucht empfangene Antworten, um zu sehen, ob die Absichten ausgeführt wurden, und bestimmt, wie die Ergebnisse interpretiert werden sollen. Das Ziel einer HTTP-Anforderung wird als „Ressource“ bezeichnet. Zusätzlich oder alternativ ist eine „Ressource“ ein Objekt mit einem Typ, assoziierten Daten, einem Satz von Verfahren, die darauf arbeiten, und Beziehungen zu anderen Ressourcen, falls anwendbar. Jede Ressource wird von mindestens einem Uniform Ressource Identifier (URI) identifiziert, und ein Ressource-URI identifiziert höchstens eine Ressource. Ressourcen werden von der RESTful-API mit HTTP-Verfahren (zum Beispiel POST, GET, PUT, DELETE usw.) beaufschlagt. Bei jedem HTTP-Verfahren wird ein Ressource-URI in der Anforderung zur Adressierung einer bestimmten Ressource durchlaufen. Operationen auf Ressourcen beeinflussen den Zustand der entsprechenden verwalteten Entitäten.
  • In Anbetracht dessen, dass eine Ressource irgendetwas sein könnte, und dass die einheitliche Schnittstelle, die von HTTP bereitgestellt wird, einem Fenster ähnlich ist, durch das ein derartiges Ding nur durch die Kommunikation von Nachrichten zu irgendeinem unabhängigen Akteur auf der anderen Seite beobachten und darauf einwirken kann, ist eine Abstraktion erforderlich, um den aktuellen oder gewünschten Zustand dieses Themas in unserer Kommunikation darzustellen („an Stelle treten von“). Diese Abstraktion wird als eine Darstellung bezeichnet. Für die Zwecke von HTTP ist eine „Darstellung“ Informationen, die einen vergangenen, aktuellen oder gewünschten Zustand einer gegebenen Ressource in einem Format widerspiegeln soll, das leicht über das Protokoll kommuniziert werden kann. Eine Darstellung umfasst einen Satz von Darstellungsmetadaten und einen potenziell unbegrenzten Strom von Darstellungsdaten. Zusätzlich oder alternativ ist eine Ressourcendarstellung eine Serialisierung eines Ressourcenzustands in einem bestimmten Inhaltsformat.
  • Einem Ursprungsserver könnten mehrere Darstellungen bereitgestellt werden, oder er könnte in der Lage sein, mehrere Darstellungen zu erzeugen, die jeweils den aktuellen Zustand einer Zielressource widerspiegeln sollen. In derartigen Fällen wird etwas Algorithmus von dem Ursprungsserver verwendet, um eine dieser Darstellungen als am besten für eine gegebene Anforderung anwendbar auszuwählen, üblicherweise basierend auf Inhaltsverhandlung. Diese „ausgewählte Darstellung“ wird verwendet, um die Daten und Metadaten zum Bewerten bedingter Anforderungen bereitzustellen, die Nutzlast für Antwortnachrichten konstruieren (zum Beispiel 200 OK, 304 Nicht Modifizierte Antworten zu GET, und dergleichen). Eine Ressourcendarstellung ist im Payload-Körper einer HTTP-Anfrage- oder Antwortnachricht enthalten. Ob eine Darstellung in einer Anfrage erforderlich oder nicht erlaubt ist, hängt von dem verwendeten HTTP-Verfahren ab (siehe zum Beispiel Fielding et al., „Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content“, IETF RFC 7231 (Juni 2014)).
  • Die MEC-API-Ressourcen-Universalressourcenkennungen (Universal Resource Indicators - URIs) sind in verschiedenen ETSI-MEC-Standards, wie etwa den hier erwähnten, besprochen. Die MTS-API unterstützt zusätzliche anwendungsbezogene Fehlerinformationen, die in der HTTP-Antwort bereitgestellt werden sollen, wenn ein Fehler auftritt (siehe zum Beispiel Klausel 6.15 von [MEC009]). Die Syntax jeder Ressource-URI folgt [MEC009], sowie Berners-Lee et al., „Uniform Resource Identifier (URI): Generic Syntax“, IETF Network Working Group, RFC 3986 (Januar 2005) und/oder Nottingham, „URI Design and Ownership“, IETF RFC 8820 (Juni 2020). In den RESTful-MEC-Dienst-APIs, einschließlich der VIS-API, weist die Ressource-URI-Struktur für jede API die folgende Struktur auf:
    {apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}
  • Hier beinhaltet „apiRoot“ das Schema („https“), den Host und den optionalen Port sowie eine optionale Präfixzeichenfolge. Der „apiName“ definiert den Namen der API (zum Beispiel MTS-API, RNI-API usw.). „apiVersion“ stellt die Version der API dar, und die „apiSpecificSuffixe“ 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 der URI unter der Kontrolle der API-Spezifikation stehen. In der obigen Wurzel werden „apiRoot“ und „apiName“ unter Verwenden des Dienstregisters (siehe zum Beispiel Dienstregister 2438 in 24) entdeckt. Es beinhaltet das Schema („http“ oder „https“), den Host und den optionalen Port sowie eine optionale Präfixzeichenfolge. Für eine gegebene MEC-API kann der „apiName“ auf „mec“ gesetzt werden, und „apiVersion“ kann auf eine geeignete Versionsnummer gesetzt werden (zum Beispiel „v1“ für Version 1). Die MEC-APIs unterstützen HTTP über TLS (auch als HTTPS bekannt). Alle Ressource-URIs in den MEC-API-Vorgehensweisen sind relativ zu der obigen Stamm-URI definiert.
  • Das JSON-Inhaltsformat kann auch unterstützt werden. Das JSON-Format wird von dem Inhaltstyp „application/json“ signalisiert. Die MTS-API kann den OAuth2.0 Client-Berechtigungsnachweisgewährungstyp mit Träger-Token verwenden (siehe zum Beispiel [MEC009]). Der Token-Endpunkt kann als Teil der in [MEC009] definierten Dienstverfügbarkeitsabfragevorgehensweise entdeckt werden. Die Client-Berechtigungsnachweise können unter Verwenden bekannter Bereitstellungsmechanismen in die MEC-App geliefert werden.
  • 2. COMPUTING-SYSTEM UND HARDWARE-KOMPONENTEN, KONFIGURATIONEN UND ANORDNUNGEN
  • 29 veranschaulicht eine beispielhafte Netzwerkarchitektur 2900 gemäß verschiedenen Ausführungsformen. Das Netzwerk 2900 kann auf eine Weise arbeiten, die mit technischen 3GPP-Spezifikationen für LTE oder 5G/NR-Systeme übereinstimmt. Die Ausführungsbeispiele sind jedoch in dieser Hinsicht nicht beschränkt, und die beschriebenen Ausführungsformen können auf andere Netzwerke zutreffen, die von den hierin beschriebenen Prinzipien profitieren, wie etwa zukünftige 3GPP-Systeme oder dergleichen.
  • Das Netzwerk 2900 beinhaltet ein UE 2902, das eine beliebige mobile oder nicht-mobile Rechenvorrichtung ist, die dazu ausgelegt ist, mit einem RAN 2904 über eine Luftverbindung zu kommunizieren. Das UE 2902 ist kommunikativ mit dem RAN 2904 durch eine Uu-Schnittstelle gekoppelt, die sowohl auf LTE als auch NR-Systeme anwendbar sein kann. Beispiele für das UE 2902 beinhalten unter anderem ein Smartphone, einen Tablet-Computer, einen Wearable-Computer, einen Desktop-Computer, einen Laptop-Computer, ein fahrzeuginternes Infotainmentsystem, ein fahrzeuginternes Unterhaltungssystem, ein Kombiinstrument, ein Head-Up-Display (HUD), eine Borddiagnosevorrichtung, ein mobiles Armaturenbrettgerät, ein mobiles Datenendgerät, ein elektronisches Motorverwaltungssystem, Elektronik-/Motorsteuergerät, Elektronik-/Motorsteuermodul, eingebettetes System, einen Sensor, Mikrocontroller, ein Steuermodul, Motormanagementsystem, vernetztes Gerät, eine Maschinentypkommunikationsvorrichtung, Maschinen-zu-Maschine (M2M), Vorrichtung-zu-Vorrichtung (D2D), Maschinentypkommunikationsvorrichtung (MTC-Vorrichtung), Internet-der-Dinge-Vorrichtung (IoT-Vorrichtung) und/oder dergleichen. Das Netzwerk 2900 kann eine Vielzahl von UEs 2902 beinhalten, die über eine D2D-, ProSe-, PC5- und/oder Sidelink-Schnittstelle (SL-Schnittstelle) direkt miteinander gekoppelt sind. Diese UEs 2902 können M2M/D2D/MTC/IoT-Vorrichtungen und/oder Fahrzeugsysteme sein, die unter Verwenden physischer Sidelink-Kanäle kommunizieren, wie unter anderem PSBCH, PSDCH, PSSCH, PSCCH, PSFCH usw. Das UE 2902 kann Blinddecodierungsversuche von SL-Kanälen/Links gemäß den verschiedenen Ausführungsformen hierin ausführen.
  • Bei einigen Ausführungsformen kann das UE 2902 zusätzlich über eine OTA-Verbindung (Over The Air-Verbindung) mit einem AP 2906 kommunizieren. Der AP 2906 verwaltet eine WLAN-Verbindung, die dazu dienen kann, einen Teil/den gesamten Netzwerkverkehr von dem RAN 2904 abzuladen. Die Verbindung zwischen dem UE 2902 und dem AP 2906 kann mit einem beliebigen IEEE-802.11-Protokoll übereinstimmen. Zusätzlich dazu können das UE 2902, das RAN 2904 und der AP 2906 zellulare WLAN-Aggregation/Integration (zum Beispiel LWA/LWIP) nutzen. Zellulare WLAN-Aggregation kann beinhalten, dass das UE 2902 von dem RAN 2904 dazu konfiguriert wird, sowohl zellulare Funkressourcen als auch WLAN-Ressourcen zu nutzen.
  • Das RAN 2904 weist einen oder mehrere Zugangsnetzknoten (Access Network Nodes - ANs) 2908 auf. Die ANs 2908 beenden Luftschnittstelle(n) für das UE 2902 durch Bereitstellen von Zugriffsschichtprotokollen, einschließlich RRC-, PDCP-, RLC-, MAC- und PHY/L1-Protokollen. Auf diese Weise ermöglicht das AN 2908 eine Daten-/Sprachkonnektivität zwischen CN 2920 und dem UE 2902. Die ANs 2908 können eine Makrozellen-Basisstation oder eine Niederleistungs-Basisstation zum Bereitstellen von Femtozellen, Pikozellen oder anderen ähnlichen Zellen mit kleineren Abdeckungsbereichen, geringerer Benutzerkapazität oder höherer Bandbreite im Vergleich zu Makrozellen sein; oder eine Kombination davon. Bei diesen Umsetzungen wird ein AN 2908 als BS, gNB, RAN-Knoten, eNB, ng-eNB, NodeB, RSU, TRxP usw. bezeichnet.
  • Eine beispielhafte Umsetzung ist eine „CU/DU-Split“-Architektur, bei der die ANs 2908 als eine gNB-Zentraleinheit (CU) verkörpert sind, die kommunikativ mit einer oder mehreren gNB-verteilten Einheiten (DUs) gekoppelt ist, wobei jede DU kommunikativ mit einer oder mehreren Funkeinheiten (RUs) (auch als RRHs, RRUs oder dergleichen bezeichnet) gekoppelt sein kann (siehe zum Beispiel 3GPP TS 38.401 v16.1.0 (2020-03)). Bei einigen Umsetzungen können die eine oder die mehreren RUs individuelle RSUs sein. Bei einigen Umsetzungen kann die CU/DU-Aufteilung eine ng-eNB-CU und eine oder mehrere ng-eNB-DUs an Stelle oder zusätzlich zu den gNB-CU bzw. gNB-DUs beinhalten. Die ANs 2908, die als die CU eingesetzt werden, können in einer diskreten Vorrichtung oder als eine oder mehrere Softwareentitäten umgesetzt sein, die auf Server-Computern als Teil zum Beispiel eines virtuellen Netzwerks einschließlich einer virtuellen Basisbandeinheit (BBU) oder eines BBU-Pools laufen, Cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), zentralisiertes RAN (C-RAN), virtualisiertes RAN (vRAN) und/oder dergleichen (obwohl sich diese Begriffe auf unterschiedliche Umsetzungskonzepte verweisen können). Eine beliebige andere Art von Architekturen, Anordnungen und/oder Konfigurationen kann verwendet werden.
  • Die Vielzahl von ANs kann über eine X2-Schnittstelle (falls das RAN 2904 ein LTE-RAN oder Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 2910 ist) oder eine XN-Schnittstelle (falls das RAN 2904 ein NG-RAN 2914 ist) miteinander gekoppelt sein. Die X2/Xn-Schnittstellen, die bei einigen Ausführungsformen in Steuer-/Benutzerebenenschnittstellen getrennt sein können, können es den ANs erlauben, Informationen im Zusammenhang mit Handovers, Daten-/Kontextübertragungen, Mobilität, Lastverwaltung, Interferenzkoordination usw. zu kommunizieren.
  • Die ANs des RAN 2904 können jeweils eine oder mehrere Zellen, Zellengruppen, Komponententräger usw. verwalten, um dem UE 2902 eine Luftschnittstelle für Netzwerkzugriff bereitzustellen. Das UE 2902 kann gleichzeitig mit einer Vielzahl von Zellen verbunden sein, die von demselben oder unterschiedlichen ANs 2908 des RAN 2904 bereitgestellt werden. Zum Beispiel können das UE 2902 und das RAN 2904 Trägeraggregation verwenden, um es dem UE 2902 zu erlauben, sich mit einer Vielzahl von Komponententrägern zu verbinden, die j eweils einer Pcell oder Scell entsprechen. In dualen Konnektivitätsszenarien kann ein erster AN 2908 ein Master-Knoten sein, der eine MCG bereitstellt, und ein zweiter AN 2908 kann ein sekundärer Knoten sein, der eine SCG bereitstellt. Der erste/zweite AN 2908 kann eine beliebige Kombination von eNB, gNB, ng-eNB usw. sein.
  • Das RAN 2904 kann die Luftschnittstelle über ein lizenziertes Spektrum oder ein unlizenziertes Spektrum bereitstellen. Um in dem unlizenzierten Spektrum zu arbeiten, können die Knoten LAA-, eLAA- und/oder feLAA-Mechanismen basierend auf CA-Technologie mit PCells/Scells verwenden. Vor dem Zugreifen auf das unlizenzierte Spektrum können die Knoten Medium/Träger-Erfassungsoperationen basierend zum Beispiel auf einem LBT-Protokoll (Listen-Before-Talk - LBT-Protokoll ausführen.
  • In V2X Szenarien kann das UE 2902 oder AN 2908 eine Straßenrandeinheit (RSU) sein oder als diese fungieren, die auf eine beliebige Transportinfrastruktureinheit, die für V2X-Kommunikationen verwendet wird, verweisen kann. Eine RSU kann in oder von einem geeigneten AN oder einem stationären (oder relativ stationären) UE umgesetzt sein. RSU, die in oder von Folgendem umgesetzt ist: ein UE kann als „RSU vom UE-Typ“ bezeichnet werden; ein eNB kann als „RSU vom eNB-Typ“ bezeichnet werden; ein gNB kann als „RSU vom gNB-Typ“ bezeichnet werden; und dergleichen. Bei einem Beispiel ist eine RSU eine Rechenvorrichtung, die mit einer Hochfrequenzschaltungsanordnung gekoppelt ist, die sich an einem Straßenrand befindet, die Konnektivitätsunterstützung für vorbeifahrende Fahrzeug-UEs bereitstellt. Die RSU kann auch interne Datenspeicherungsschaltungsanordnungen beinhalten, um Kreuzungskartengeometrie, Verkehrsstatistiken, Medien sowie Anwendungen/Software zu speichern, um laufenden Fahrzeug- und Fußgängerverkehr zu erfassen und zu steuern. Die RSU kann Kommunikationen mit sehr niedriger Latenz bereitstellen, die für Hochgeschwindigkeitsereignisse, wie etwa Crash-Vermeidung, Verkehrswarnungen und dergleichen erforderlich sind. Zusätzlich oder alternativ kann die RSU andere Zellular-/WLAN-Kommunikationsdienste bereitstellen. Die Komponenten der RSU können in einem wetterfesten Einschluss verpackt sein, das zur Installation im Freien geeignet ist, und können eine Netzwerkschnittstellensteuervorrichtung beinhalten, um eine drahtgebundene Verbindung (zum Beispiel Ethernet) zu einer Verkehrssignalsteuervorrichtung oder einem Backhaul-Netzwerk bereitzustellen.
  • Bei einigen Ausführungsformen kann das RAN 2904 ein E-UTRAN 2910 mit einem oder mehreren eNBs 2912 sein. Das eine E-UTRAN 2910 stellt eine LTE-Luftschnittstelle (Uu) mit folgenden Eigenschaften bereit: SCS von 15 kHz; CP-OFDM-Wellenform für DL und SC-FDMA-Wellenform für UL; Turbo-Codes für Daten und TBCC zur Steuerung usw. Die LTE-Luftschnittstelle kann auf CSI-RS für CSI-Erfassung und Strahlverwaltung; PDSCH/PDCCH-DMRS für PDSCH/PDCCH-Demodulation; und CRS für Zellsuche und anfängliche Erfassung, Kanalqualitätsmessungen und Kanalschätzung für kohärente Demodulation/Erfassung an dem UE angewiesen sein. Die LTE-Luftschnittstelle kann auf Sub6GHz-Bändern arbeiten.
  • Bei einigen Ausführungsformen kann das RAN 2904 ein Next Generation (NG)-RAN 2914 mit einem oder mehreren gNB 2916 und/oder einem oder mehreren ng-eNB 2918 sein. Der gNB 2916 verbindet sich mit 5G-fähigen UEs 2902 unter Verwenden einer 5G-NR-Schnittstelle. Der gNB 2916 verbindet sich mit einem 5GC 2940 durch eine NG-Schnittstelle, die eine N2-Schnittstelle oder eine N3-Schnittstelle beinhaltet. Der ng-eNB 2918 verbindet sich auch über eine NG-Schnittstelle mit dem 5GC 2940, kann aber über die Uu-Schnittstelle mit einem UE 2902 verbunden sein. Der gNB 2916 und der ng-eNB 2918 können über eine Xn-Schnittstelle miteinander verbunden sein.
  • Bei einigen Ausführungsformen kann die NG-Schnittstelle in zwei Teile aufgeteilt sein, eine NG-Benutzerebenen-Schnittstelle (NG-U-Schnittstelle), die Verkehrsdaten zwischen den Knoten des NG-RAN 2914 und einer UPF 2948 (zum Beispiel N3-Schnittstelle) trägt, und eine NG-Steuerebenen- (NG-C) -Schnittstelle, die eine Signalisierungsschnittstelle zwischen den Knoten des NG-RAN 2914 und einer AMF 2944 (zum Beispiel N2-Schnittstelle) ist.
  • Das NG-RAN 2914 kann eine 5G-NR Luftschnittstelle (die auch als Uu-Schnittstelle bezeichnet werden kann) mit den folgenden Charakteristiken bereitstellen: Variable SCS; CP-OFDM für DL, CP-OFDM und DFT-s-OFDM für UL; Polar-, Wiederholungs-, Simplex- und Reed-Muller-Codes für Steuerung und LDPC für Daten. Die 5G-NR Luftschnittstelle kann auf CSI-RS, PDSCH/PDCCH DMRS ähnlich der LTE-Luftschnittstelle angewiesen sein. Die 5G-NR Luftschnittstelle verwendet möglicherweise kein CRS, sondern kann PBCH-DMRS zur PBCH-DEMODULATION; PTRS zur Phasenverfolgung für PDSCH; und Tracking-Referenzsignal zur Zeitverfolgung verwenden. Die 5G-NR Luftschnittstelle kann auf FR1-Bändern, die Sub-6-GHz-Bänder beinhalten, oder FR2-Bändern, die Bänder von 24,25 GHz bis 52,6 GHz beinhalten, arbeiten. Die 5G-NR Luftschnittstelle kann einen SSB beinhalten, der ein Bereich eines Downlink-Ressourcengitters ist, der PSS/SSS/PBCH beinhaltet.
  • Die 5G-NR Luftschnittstelle kann BWPs für verschiedene Zwecke nutzen. Zum Beispiel kann BWP zur dynamischen Anpassung des SCS verwendet werden. Zum Beispiel kann das UE 2902 mit mehreren BWPs konfiguriert sein, wobei jede BWP-Konfiguration ein unterschiedliches SCS aufweist. Wenn dem UE 2902 eine BWP-Änderung angegeben wird, wird auch das SCS der Übertragung geändert. Ein anderes Anwendungsfallbeispiel für BWP hängt mit Leistungseinsparung zusammen. Insbesondere können mehrere BWPs für das UE 2902 mit einer unterschiedlichen Menge an Frequenzressourcen (zum Beispiel PRBs) konfiguriert sein, um eine Datenübertragung unter unterschiedlichen Verkehrslastszenarien zu unterstützen. Ein BWP, der eine geringere Anzahl an PRBs enthält, kann zur Datenübertragung mit geringer Verkehrslast verwendet werden, während eine Leistungseinsparung an dem UE 2902 und in einigen Fällen an dem gNB 2916 erlaubt wird. Ein BWP, der eine größere Anzahl an PRBs enthält, kann für Szenarien mit höherer Verkehrslast verwendet werden.
  • Das RAN 2904 ist kommunikativ mit dem CN 2920 gekoppelt, das Netzwerkelemente und/oder Netzwerkfunktionen (NFs) beinhaltet, um verschiedene Funktionen bereitzustellen, um Kunden/Teilnehmern (zum Beispiel UE 2902) Daten und Telekommunikationsdienste zu unterstützen. Die Komponenten des CN 2920 können in einem physischen Knoten oder separaten physischen Knoten umgesetzt sein. Bei einigen Ausführungsformen kann NFV genutzt werden, um eine beliebige oder alle der Funktionen, die von den Netzwerkelementen des CN 2920 bereitgestellt werden, auf physische Rechen-/Speicherressourcen in Servern, Switches usw. zu virtualisieren. Eine logische Instanziierung des CN 2920 kann als ein Netzwerk-Slice bezeichnet werden und eine logische Instanziierung eines Teils des CN 2920 kann als ein Netzwerk-Sub-Slice bezeichnet werden.
  • Das CN 2920 kann ein LTE-CN 2922 (auch als Evolved Packet Core (EPC) 2922 bezeichnet) sein. Der EPC 2922 kann MME 2924, SGW 2926, SGSN 2928, HSS 2930, PGW 2932 und PCRF 2934 beinhalten, die über Schnittstellen (oder „Referenzpunkte“), wie gezeigt, miteinander gekoppelt sind. Die NFs im EPC 2922 werden wie folgt kurz vorgestellt.
  • Die MME 2924 setzt Mobilitätsmanagementfunktionen um, um einen aktuellen Ort des UE 2902 zu verfolgen, um Paging, Trägeraktivierung/-deaktivierung, Handover, Gateway-Auswahl, Authentifizierung usw. zu erleichtern.
  • Das SGW 2926 schließt eine S1-Schnittstelle zu dem RAN 2910 hin ab und leitet Datenpakete zwischen dem RAN 2910 und dem EPC 2922 weiter. Die SGW 2926 kann ein lokaler Mobilitätsankerpunkt für Inter-RAN-Knoten-Handover sein und kann auch einen Anker für Inter-3GPP-Mobilität bereitstellen. Andere Zuständigkeitsbereiche können gesetzmäßiges Abfangen, Verrechnung und eine gewisse Richtlinienerzwingung beinhalten.
  • Der SGSN 2928 verfolgt einen Ort des UE 2902 und führt Sicherheitsfunktionen und Zugangskontrolle aus. Der SGSN 2928 führt auch Inter-EPC-Knoten-Signalisierung für Mobilität zwischen unterschiedlichen RAT-Netzwerken aus; PDN- und S-GW-Auswahl, wie von MME 2924 spezifiziert; MME 2924 Auswahl für Handover usw. Der S3-Referenzpunkt zwischen der MME 2924 und dem SGSN 2928 ermöglicht einen Benutzer- und Trägerinformationsaustausch für eine Inter-3GPP-Zugangsnetzwerkmobilität in Ruhe-/Aktivzuständen.
  • Der HSS 2930 beinhaltet eine Datenbank für Netzwerkbenutzer, die teilnehmerbezogene Informationen zum Unterstützen der Handhabung von Kommunikationssitzungen der Netzwerkentitäten beinhaltet. Der HSS 2930 kann Unterstützung für Routing/Roaming, Authentifizierung, Autorisierung, Benennungs-/Adressierungsauflösung, Ortsabhängigkeiten usw. bereitstellen. Ein S6a-Referenzpunkt zwischen dem HSS 2930 und der MME 2924 kann eine Übertragung von Subskriptions- und Authenticator-Daten zum Authentifizieren/Autorisieren von Benutzerzugang zu dem EPC 2920 ermöglichen.
  • Das PGW 2932 kann eine SGi-Schnittstelle zu einem Datennetzwerk (DN) 2936 hin abschließen, das einen Anwendungsserver (App-Server)/Inhaltsserver 2938 beinhalten kann. Das PGW 2932 leitet Datenpakete zwischen dem EPC 2922 und dem Datennetzwerk 2936 weiter. Das PGW 2932 ist kommunikativ mit dem SGW 2926 von einem S5-Referenzpunkt gekoppelt, um ein Tunneln und Tunnelmanagement auf Benutzerebene zu ermöglichen. Das PGW 2932 kann weiter einen Knoten zur Richtliniendurchsetzung und Gebührenverrechnungsdatensammlung (zum Beispiel PCEF) beinhalten. Zusätzlich kann der SGi-Referenzpunkt das PGW 2932 kommunikativ mit demselben oder einem unterschiedlichen Datennetzwerk 2936 koppeln. Das PGW 2932 kann über einen Gx-Referenzpunkt kommunikativ mit einer PCRF 2934 gekoppelt sein.
  • Die PCRF 2934 ist das Richtlinien- und Gebührensteuerelement des EPC 2922. Die PCRF 2934 ist kommunikativ mit dem App-/Inhaltsserver 2938 gekoppelt, um geeignete QoS- und Gebührenparameter für Dienstflüsse zu bestimmen. Die PCRF 2932 stellt auch assoziierte Regeln in eine PCEF (über Gx-Referenzpunkt) mit geeignetem TFT und QCI bereit.
  • Das CN 2920 kann ein 5GC 2940 einschließlich einer AUSF 2942, AMF 2944, SMF 2946, UPF 2948, NSSF 2950, NEF 2952, NRF 2954, PCF 2956, UDM 2958 und AF 2960 sein, die, wie gezeigt, über verschiedene Schnittstellen miteinander gekoppelt sind. Die NFs im 5GC 2940 werden wie folgt kurz vorgestellt.
  • Die AUSF 2942 speichert Daten zur Authentifizierung des UE 2902 und handhabungsauthentifizierungsbezogene Funktionalität. Die AUSF 2942 kann ein gemeinsames Authentifizierungs-Framework für verschiedene Zugangstypen ermöglichen.
  • Die AMF 2944 erlaubt, dass andere Funktionen des 5GC 2940 mit dem UE 2902 und dem RAN 2904 kommunizieren und Benachrichtigungen über Mobilitätsereignisse im Zusammenhang mit dem UE 2902 abonnieren. Die AMF 2944 ist auch für Registrierungsmanagement (zum Beispiel zum Registrieren des UE 2902), Verbindungsmanagement, Erreichbarkeitsmanagement, Mobilitätsmanagement, rechtmäßiges Abfangen AMF-bezogener Ereignisse und Zugangsauthentifizierung und -autorisierung zuständig. Die AMF 2944 stellt einen Transport für SM-Nachrichten zwischen dem UE 2902 und der SMF 2946 bereit und agiert als ein transparenter Proxy zum Routen von SM-Nachrichten. Die AMF 2944 stellt auch einen Transport für SMS-Nachrichten zwischen dem UE 2902 und einer SMSF bereit. Die AMF 2944 interagiert mit der AUSF 2942 und dem UE 2902, um verschiedene Sicherheitsanker- und Kontextverwaltungsfunktionen auszuführen. Darüber hinaus ist die AMF 2944 ein Endpunkt einer RAN-CP-Schnittstelle, die den N2-Referenzpunkt zwischen dem RAN 2904 und der AMF 2944 beinhaltet. Die AMF 2944 ist auch ein Endpunkt einer NAS-Signalisierung (N1-Signalisierung) und führt NAS-Verschlüsselung und Integritätsschutz aus.
  • Die AMF 2944 unterstützt auch NAS-Signalisierung mit dem UE 2902 über eine N3IWF-Schnittstelle. Die N3IWF stellt Zugriff auf nicht vertrauenswürdige Entitäten bereit. Die N3IWF kann ein Endpunkt für die N2-Schnittstelle zwischen dem (R)AN 2904 und der AMF 2944 für die Steuerebene sein, und kann ein Endpunkt für den N3-Referenzpunkt zwischen dem (R)AN 2914 und dem 2948 für die Benutzerebene sein. Daher handhabt die AMF 2944 N2-Signalisierung von der SMF 2946 und der AMF 2944 für PDU-Sitzungen und QoS, verkapselt/entkapselt Pakete für IPSec und N3-Tunneln, markiert N3-Benutzerebenenpakete im Uplink und erzwingt QoS gemäß N3-Paketmarkierung unter Berücksichtigung von QoS-Anforderungen, die mit einer derartigen Markierung assoziiert sind, die über N2 empfangen werden. N3IWF kann auch UL- und DL-Steuerebenen-NAS-Signalisierung zwischen dem UE 2902 und der AMF 2944 über einen N1-Referenzpunkt zwischen dem UE 2902 und der AMF 2944 weiterleiten und Uplink- und Downlink-Benutzerebenen-Pakete zwischen dem UE 2902 und der UPF 2948 weiterleiten. Die N3IWF stellt auch Mechanismen zur IPsec-Tunnelherstellung mit dem UE 2902 bereit. Die AMF 2944 kann eine Namf-dienstbasierte Schnittstelle aufweisen und kann ein Abschlusspunkt für einen N14-Referenzpunkt zwischen zwei AMFs 2944 und einem N17-Referenzpunkt zwischen der AMF 2944 und einem 5G-EIR (in 29 nicht gezeigt) sein.
  • Die SMF 2946 ist zuständig für SM (zum Beispiel Sitzungseinrichtung, Tunnelverwaltung zwischen UPF 2948 und einem 2908); UE-IP-Adresszuweisung und -Verwaltung (einschließlich optionaler Autorisierung); Auswahl und Steuerung einer UP-Funktion; Konfigurieren von Verkehrslenkung bei UPF 2948, um Verkehr zu einem geeigneten Ziel zu lenken; Beenden von Schnittstellen zu Richtliniensteuerfunktionen; Steuern eines Teils von Richtliniendurchsetzung, - für Rechnung und QoS; rechtmäßiges Abfangen (für Sm-ereignisse und Schnittstelle zu LI-System); Beenden von SM-Teilen von NAS-Nachrichten; Downlink-Datenbenachrichtigung; Initiieren einer spezifischen SM-Information, die über AMF 2944 über N2 zu einem 2908 gesendet wird; und Bestimmen eines SSC-Modus einer Sitzung. SM verweist auf die Verwaltung einer PDU-Sitzung, und eine PDU-Sitzung oder „Sitzung“ verweist auf einen PDU-Konnektivitätsdienst, der den Austausch von PDUs zwischen dem UE 2902 und dem DN 2936 bereitstellt oder ermöglicht.
  • Die UPF 2948 fungiert als ein Ankerpunkt für Intra-RAT- und Inter-RAT-Mobilität, einen externen PDU-Sitzungspunkt des Interconnect mit dem Datennetzwerk 2936 und einen Verzweigungspunkt zum Unterstützen einer Multihomed-PDU-Sitzung. Die UPF 2948 führt auch Paketrouting und -weiterleiten aus, Paketinspektion, setzt einen Teil der Richtlinienregeln auf Benutzerebene durch, fängt Pakete rechtmäßig ab (UP-Sammlung), führt Verkehrsnutzungsberichte aus, führt QoS-Handhabung für eine Benutzerebene aus (zum Beispiel Paketfiltern, Gating, UL/DL-Ratendurchsetzung), führt eine Uplink-Verkehrsprüfung (zum Beispiel SDF-zu-QoS-Flussabbildung), eine Transportniveaupaketmarkierung im Uplink und Downlink aus und führt eine Downlink-Paketpufferung und Downlink-Datenbenachrichtigungsauslösung aus. Die UPF 2948 kann einen Uplink-Klassifizierer zum Unterstützen von Routing-Verkehrsflüssen zu einem Datennetzwerk beinhalten.
  • Die NSSF 2950 wählt einen Satz von Netzwerk-Slice-Instanzen aus, die das UE 2902 bedienen. Die NSSF 2950 bestimmt auch erlaubte NSSAI und die Abbildung auf die abonnierten S-NSSAIs, falls erforderlich. Die NSSF 2950 bestimmt auch einen AMF-Satz, der verwendet werden soll, um das UE 2902 zu bedienen, oder eine Liste von Kandidaten-AMFs 2944 basierend auf einer geeigneten Konfiguration und möglicherweise durch Abfragen der NRF 2954. Die Auswahl eines Satzes von Netzwerk-Slice-Instanzen für das UE 2902 kann von der AMF 2944 ausgelöst werden, bei der das UE 2902 registriert ist, indem sie mit der NSSF 2950 interagiert; dies kann zu einer Änderung der AMF 2944 führen. Die NSSF 2950 interagiert mit der AMF 2944 über einen N22-Referenzpunkt; und kann mit einer anderen NSSF in einem besuchten Netzwerk über einen N31-Referenzpunkt (nicht gezeigt) kommunizieren.
  • Die NEF 2952 deckt sicher Dienste und Fähigkeiten auf, die von 3GPP-NFs bereitgestellt werden, für Dritte, interne Aufdeckung/Wiederaufdeckung, AFs 2960, Edge-Computing- oder Fog-Computing-Systeme (zum Beispiel Edge-Computing-Knoten usw.). Bei derartigen Ausführungsformen kann die NEF 2952 die AFs authentifizieren, autorisieren oder drosseln. Die NEF 2952 kann auch Informationen, die mit der AF 2960 ausgetauscht werden, und Informationen, die mit internen Netzwerkfunktionen ausgetauscht werden, übersetzen. Zum Beispiel kann die NEF 2952 zwischen einer AF-Dienst-Kennung und internen 5GC-Informationen übersetzen. Die NEF 2952 kann auch Informationen von anderen NFs basierend auf aufgedeckten Fähigkeiten anderer NFs empfangen. Diese Informationen können an der NEF 2952 als strukturierte Daten oder an einer Datenspeicherung NF unter Verwenden standardisierter Schnittstellen gespeichert werden. Die gespeicherten Informationen können dann von der NEF 2952 anderen NFs und AFs erneut aufgedeckt werden oder für andere Zwecke, wie etwa Analytik, verwendet werden.
  • Die NRF 2954 unterstützt Dienstentdeckungsfunktionen, empfängt Nf-Entdeckungsanfragen von Nf-Instanzen und liefert Informationen über die entdeckten Nf-Instanzen an die anfordernden NF-Instanzen. Die NRF 2954 führt auch Informationen verfügbarer NF-Instanzen und ihrer unterstützten Dienste. Die NRF 2954 unterstützt auch Dienstentdeckungsfunktionen, wobei die NRF 2954 eine Nf-Entdeckungsanfrage von einer NF-Instanz oder einem SCP (nicht gezeigt) empfängt und Informationen über die entdeckten NF-Instanzen an die NF-Instanz oder den SCP liefert.
  • Die PCF 2956 stellt Richtlinienregeln bereit, um Ebenenfunktionen zu steuern, um sie durchzusetzen, und kann auch ein vereinheitlichtes Richtlinien-Framework unterstützen, um das Netzwerkverhalten zu regeln. Die PCF 2956 kann auch ein Frontend umsetzen, um auf Subskriptionsinformationen zuzugreifen, die für Richtlinienentscheidungen in einem UDR des UDM 2958 relevant sind. Zusätzlich zu dem Kommunizieren mit Funktionen über Referenzpunkte, wie gezeigt, weist die PCF 2956 eine Npcf dienstbasierte Schnittstelle auf.
  • Der UDM 2958 handhabt subskriptionsbezogene Informationen, um die Handhabung von Kommunikationssitzungen der Netzwerkentitäten zu unterstützen, und speichert Subskriptionsdaten des UE 2902. Zum Beispiel können Subskriptionsdaten über einen N8-Referenzpunkt zwischen dem UDM 2958 und der AMF 2944 kommuniziert werden. Der UDM 2958 kann zwei Teile, ein Anwendungs-Frontend und ein UDR, beinhalten. Das UDR kann Subskriptionsdaten und Richtliniendaten für den UDM 2958 und die PCF 2956 und/oder strukturierte Daten zur Aufdeckung und Anwendungsdaten (einschließlich PFDs zur Anwendungserfassung, Anwendungsanforderungsinformationen für mehrere UEs 2902) für die NEF 2952 speichern. Die nudr-dienstbasierte Schnittstelle kann von dem UDR 221 gezeigt werden, um es dem UDM 2958, der PCF 2956 und NEF 2952 zu erlauben, auf einen speziellen Satz der gespeicherten Daten zuzugreifen, sowie eine Benachrichtigung über relevante Datenänderungen in dem UDR zu lesen, zu aktualisieren (zum Beispiel hinzuzufügen, zu modifizieren), zu löschen und zu abonnieren. Der UDM kann eine UDM-FE beinhalten, das für die Verarbeitung von Berechtigungsnachweisen, Ortsverwaltung, Subskriptionsverwaltung und so weiter zuständig ist. Mehrere unterschiedliche Frontends können denselben Benutzer in unterschiedlichen Transaktionen bedienen. Das UDM-FE greift auf Subskriptionsinformationen zu, die in dem UDR gespeichert sind, und führt Authentifizierungsberechtigungsnachweisverarbeitung, Benutzeridentifikationshandhabung, Zugangsberechtigung, Registrierung/Mobilitätsverwaltung und Subskriptionsverwaltung aus. Zusätzlich zum Kommunizieren mit anderen NFs über Referenzpunkte, wie gezeigt, kann der UDM 2958 die dienstbasierte NuDM-Schnittstelle aufzeigen.
  • Die AF 2960 stellt einen Anwendungseinfluss auf das Verkehrsrouten bereit, stellt Zugang zu der NEF 2952 bereit und interagiert mit dem Richtlinien-Framework zur Richtliniensteuerung. Die AF 2960 kann die UPF 2948 (Neu-)Auswahl und Verkehrsführung beeinflussen. Basierend auf dem Betreibereinsatz, wenn die AF 2960 als vertrauenswürdige Entität angesehen wird, kann der Netzwerkbetreiber ermöglichen, dass die AF 2960 direkt mit relevanten NFs interagiert. Zusätzlich dazu kann die AF 2960 für Edge-Computing-Umsetzungen verwendet werden,
  • Der 5GC 2940 kann Edge-Computing ermöglichen, indem Betreiber/Drittpartei-Dienste derart ausgewählt werden, dass sie geografisch nahe an einem Punkt liegen, an dem das UE 2902 mit dem Netzwerk verbunden ist. Dies kann Latenz und Belastung des Netzwerks reduzieren. Bei Edge-Computing-Umsetzungen kann der 5GC 2940 eine UPF 2948 nahe dem UE 2902 auswählen und Verkehrslenken von der UPF 2948 zu DN 2936 über die N6-Schnittstelle ausführen. Dies kann auf den UE-Subskriptionsdaten, dem UE-Ort und Informationen, die von der AF 2960 bereitgestellt werden, basieren, was es der AF 2960 erlaubt, UPF (Wieder)auswahl und Verkehrslenkung zu beeinflussen.
  • Das Datennetzwerk (DN) 2936 kann verschiedene Netzwerkbetreiberdienste, Internetzugangs- oder Drittparteidienste darstellen, die von einem oder mehreren Server, einschließlich zum Beispiel Anwendungs (App-)/Inhaltsserver 2938, bereitgestellt werden können. Das DN 2936 kann eine Betreiber-externe Öffentlichkeit, ein privates PDN oder ein Betreiber-internes Paketdatennetzwerk sein, zum Beispiel zur Bereitstellung von IMS-Diensten. Bei dieser Ausführungsform kann der App-Server 2938 über eine S-CSCF oder die 1-CSCF mit einem IMS gekoppelt sein. Bei einigen Umsetzungen kann das DN 2936 eine oder mehrere lokale Bereich-DNs (LADNs) darstellen, die DNs 2936 (oder DN-Namen (DNNs)) sind, auf die ein UE 2902 in einem oder mehreren spezifischen Bereichen zugreifen kann/können. Außerhalb dieser spezifischen Bereiche ist das UE 2902 nicht in der Lage, auf das LADN/DN 2936 zuzugreifen.
  • Zusätzlich oder alternativ kann das DN 2936 ein Edge-DN 2936 sein, das ein (lokales) Datennetzwerk ist, das die Architektur zum Aktivieren von Edge-Anwendungen unterstützt. Bei diesen Ausführungsformen kann der App-Server 2938 die physischen Hardwaresysteme/- vorrichtungen, die App-Server-Funktionalität bereitstellen, und/oder die Anwendungssoftware darstellen, die sich in der Cloud oder an einem Edge-Computing-Knoten befindet, der Serverfunktion(en) ausführt(ausführen). Bei einigen Ausführungsformen stellt der App/Inhaltsserver 2938 eine Edge-Hosting-Umgebung bereit, die Unterstützung bereitstellt, die für die Ausführung des Edge-Anwendungsservers erforderlich ist.
  • Bei einigen Ausführungsformen kann der 5GS einen oder mehrere Edge-Computing-Knoten verwenden, um eine Schnittstelle bereitzustellen und eine Verarbeitung von drahtlosem Kommunikationsverkehr abzuladen. Bei diesen Ausführungsformen können die Edge-Computing-Knoten in einem oder mehreren RAN 2910, 2914 enthalten sein oder gemeinsam mit diesen angeordnet sein. Zum Beispiel können die Edge-Computing-Knoten eine Verbindung zwischen dem RAN 2914 und der UPF 2948 in dem 5GC 2940 bereitstellen. Die Edge-Computing-Knoten können eine oder mehrere NFV-Instanzen verwenden, die auf einer Virtualisierungsinfrastruktur innerhalb der Edge-Computing-Knoten instanziiert sind, um drahtlose Verbindungen zu und von dem RAN 2914 und der UPF 2948 zu verarbeiten.
  • Die Schnittstellen des 5GC 2940 umfassen Referenzpunkte und dienstbasierte Schnittstellen. Die Referenzpunkte umfassen: N1 (zwischen dem UE 2902 und der AMF 2944), N2 (zwischen RAN 2914 und AMF 2944), N3 (zwischen RAN 2914 und UPF 2948), N4 (zwischen der SMF 2946 und UPF 2948), N5 (zwischen PCF 2956 und AF 2960), N6 (zwischen UPF 2948 und DN 2936), N7 (zwischen SMF 2946 und PCF 2956), N8 (zwischen UDM 2958 und AMF 2944), N9 (zwischen zwei UPF 2948), N10 (zwischen dem UDM 2958 und der SMF 2946), N11 (zwischen der AMF 2944 und der SMF 2946), N12 (zwischen AUSF 2942 und AMF 2944), N13 (zwischen AUSF 2942 und UDM 2958), N14 (zwischen zwei AMFs 2944; nicht gezeigt), N15 (zwischen PCF 2956 und AMF 2944 im Fall eines Nicht-Roaming-Szenarios, oder zwischen der PCF 2956 in einem besuchten Netzwerk und der AMF 2944 im Fall eines Roamingszenarios), N16 (zwischen zwei SMFs 2946; nicht gezeigt) und N22 (zwischen AMF 2944 und NSSF 2950). Es können auch andere in 29 nicht gezeigte Referenzpunktdarstellungen verwendet werden. Die dienstbasierte Darstellung der 29 stellt NFs innerhalb der Steuerebene, die es anderen autorisierten NFs ermöglichen, auf ihre Dienste zuzugreifen, dar. Die dienstbasierten Schnittstellen (SBIs) beinhalten: Namf (SBI dargelegt von AMF 2944), Nsmf (SBI dargelegt von SMF 2946), Nnef (SBI dargelegt von NEF 2952), Npcf (SBI dargelegt von PCF 2956), Nudm (SBI dargelegt von UDM 2958), Naf (SBI dargelegt von AF 2960), Nnrf (SBI dargelegt von NRF 2954), Nnssf (SBI dargelegt von NSSF 2950), Nausf (SBI dargelegt von AUSF 2942). Andere dienstbasierte Schnittstellen (zum Beispiel Nudr, N5g-eir und Nudsf), die in 29 nicht gezeigt sind, können ebenfalls verwendet werden. Bei einigen Ausführungsformen kann die NEF 2952 eine Schnittstelle zu Edge-Computing-Knoten 2936x bereitstellen, die verwendet werden können, um drahtlose Verbindungen mit dem RAN 2914 zu verarbeiten.
  • Bei einigen Umsetzungen kann das System 2900 eine SMSF beinhalten, die für SMS-Subskriptionsprüfung und -verifizierung zuständig ist, und SM-Nachrichten zu/von dem UE 2902 zu/von anderen Entitäten, wie etwa einem SMS-GMSC/IWMSC/SMS-Router, weiterzuleiten. Das SMS kann auch mit AMF 2942 und UDM 2958 für eine Benachrichtigungsvorgehensweise interagieren, dass das UE 2902 für SMS-Transfer verfügbar ist (zum Beispiel setzen eines UE-Nicht-Erreichbar-Flags und Benachrichtigen des UDM 2958, wenn das UE 2902 für SMS verfügbar ist).
  • Das 5GS kann auch ein SCP (oder einzelne Instanzen des SCP) beinhalten, das indirekte Kommunikation unterstützt (siehe zum Beispiel 3GPP TS 23.501 Abschnitt 7.1.1); delegierte Entdeckung (siehe zum Beispiel 3GPP TS 23.501 Abschnitt 7.1.1); Nachrichtenweiterleitung und Routing zu Ziel-NF/NF-Dienst(en), Kommunikationssicherheit (zum Beispiel Autorisierung des NF-Dienstverbrauchers zum Zugreifen auf die NF-Dienstproduktor-API) (siehe zum Beispiel 3GPP TS 33.501), Lastausgleich, Überwachung, Überlastkontrolle 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 zum Beispiel [TS23501] Abschnitt 6.3). Lastausgleichs-, Überwachungs-, Überlaststeuerfunktionalität, die von dem SCP bereitgestellt wird, kann umsetzungsspezifisch sein. Der SCP kann verteilt eingesetzt werden. In dem Kommunikationspfad zwischen verschiedenen NF-Diensten kann mehr als ein SCP vorhanden sein. Der SCP kann, obwohl er keine NF-Instanz ist, auch verteilt, redundant und skalierbar eingesetzt werden.
  • 30 veranschaulicht eine Softwareverteilungsplattform 3005 zum Verteilen von Software 3060, wie etwa der beispielhaften computerlesbaren Anweisungen 3260 der 32, zu einer oder mehreren Vorrichtungen, wie etwa beispielhafte Prozessorplattform(en) 3000 und/oder beispielhafte verbundene Edge-Vorrichtungen 3262 (siehe zum Beispiel 32) und/oder beliebige der anderen hierin besprochenen Rechensysteme/Vorrichtungen. Die beispielhafte Softwareverteilungsplattform 3005 kann von einem beliebigen Computerserver, einer beliebigen Dateneinrichtung, einem beliebigen Cloud-Dienst usw. umgesetzt werden, die/der in der Lage ist, Software zu speichern und zu anderen Rechenvorrichtungen (zum Beispiel an Drittparteien, die beispielhaften verbundenen Edge-Vorrichtungen 3262 der 32) zu übertragen. Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (zum Beispiel Server), Dritte sein (zum Beispiel Kunden einer Entität, die Softwareverteilungsplattform 3005 besitzt und/oder betreibt). Beispielhafte verbundene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. Bei einigen Beispielen ist eine Drittpartei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa die beispielhaften computerlesbaren Anweisungen 3260 der 32. Die Drittparteien können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung kaufen und/oder in Lizenz vergeben und/oder weiterverkaufen und/oder in Unterlizenz vergeben. Bei einigen Beispielen bewirkt verteilte Software, dass eine Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs) die eine oder die mehreren Vorrichtungen (zum Beispiel verbundene Edge-Vorrichtungen) geografisch und/oder logisch voneinander getrennt (zum Beispiel physisch getrennte IoT-Geräte, belegt mit der Zuständigkeit für Wasserverteilungssteuerung (zum Beispiel Pumpen), Stromverteilungssteuerung (zum Beispiel Relais) usw.) zu identifizieren.
  • In 30 beinhaltet die Softwareverteilungsplattform 3005 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen. Die Speichervorrichtungen speichern die computerlesbaren Anweisungen 3060, die den beispielhaften computerlesbaren Anweisungen 3260 der 32 entsprechen können, wie oben beschrieben. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 3005 stehen in Kommunikation mit einem Netzwerk 3010, das einem oder mehreren beliebigen des Internets und/oder beliebigen der beispielhaften Netzwerke, wie hierin beschrieben, entsprechen kann. Bei einigen Beispielen reagieren der eine oder die mehreren Server auf Anfragen, die Software als Teil einer kommerziellen Transaktion an eine anfragende Partei zu übertragen. Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann von dem einen oder den mehreren Server der Softwareverteilungsplattform und/oder über eine Drittpartei-Zahlungsentität gehandhabt werden. Die Server ermöglichen es Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 3060 von der Softwareverteilungsplattform 3005 herunterzuladen. Zum Beispiel kann die Software 3060, die den beispielhaften computerlesbaren Anweisungen 3260 der 32 entsprechen kann, auf die beispielhafte(n) Prozessorplattform(en) 3000 heruntergeladen werden, die die computerlesbaren Anweisungen 3060 ausführen soll/sollen, um Funk-Apps umzusetzen.
  • Bei einigen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 3005 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 3060 durchgehen müssen. Bei einigen Beispielen bieten ein oder mehrere Server der Softwareverteilungsplattform 3005 periodisch Aktualisierungen an, übertragen und/oder erzwingen Aktualisierungen an die Software (zum Beispiel die beispielhaften computerlesbaren Anweisungen 3260 der 32), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewandt werden.
  • In 30 sind die computerlesbaren Anweisungen 3060 auf Speichervorrichtungen der Softwareverteilungsplattform 3005 in einem bestimmten Format gespeichert. Ein Format computerlesbarer Anweisungen beinhaltet unter anderem eine spezielle Codesprache (zum Beispiel Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen speziellen Codezustand (zum Beispiel uncompilierter Code (zum Beispiel ASCII), interpretierter Code, verknüpfter Code, ausführbarer Code (zum Beispiel einen Binärprogramm) usw.). Bei einigen Beispielen befinden sich die computerlesbaren Anweisungen D182, die in der Softwareverteilungsplattform 3005 gespeichert sind, in einem ersten Format, wenn sie an die beispielhafte(n) Prozessorplattform(en) 3000 übertragen werden. Bei einigen Beispielen ist das erste Format ein ausführbares Binärprogramm, in dem bestimmte Arten der Prozessorplattform(en) 3000 ausgeführt werden können. Bei einigen Beispielen ist das erste Format jedoch uncompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, um Ausführung auf der (den) beispielhaften Prozessorplattform(en) 3000 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 3000 die computerlesbaren Anweisungen 3060 in dem ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der in der Lage ist, auf der (den) Prozessorplattform(en) 3000 ausgeführt zu werden. Bei noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der Prozessorplattform(en) 3000 von einem Interpreter interpretiert wird, um die Ausführung von Anweisungen zu erleichtern.
  • Die 31 und 32 bilden weitere Beispiele für Edge-Computing-Systeme und - umgebungen ab, die beliebige der hierin besprochenen Rechenknoten oder Vorrichtungen erfüllen können. Jeweilige Edge-Computing-Knoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ verkörpert sein, das in der Lage ist, mit anderen Edge-, Networking- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Computing-Vorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (zum Beispiel ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen auszuführen, verkörpert sein.
  • In 31 weist ein Edge-Computing-Knoten 3100 eine Rechen-Engine (hier auch als „Rechenschaltungsanordnung“ bezeichnet) 3102, ein Eingabe/Ausgabe-Subsystem (E/A-Subsystem) 3108, eine Datenspeicherung 3110, ein Kommunikationsschaltungsanordnungs-Subsystem 3112 und optional eine oder mehrere Peripherievorrichtungen 3114 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 (zum Beispiel eine Anzeige, Peripherievorrichtungen usw.). Zusätzlich können bei einigen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderswie einen Teil davon bilden. Zusätzlich oder alternativ kann der Edge-Computing-Knoten 3100 (oder können Teile davon) in einem Gehäuse, einem Chassis, einer Verkleidung oder einer Schale enthalten sein, wie etwa jenen, die zuvor im Zusammenhang mit der Geräterechenvorrichtung der Edge-Cloud 1310 der 13 besprochen wurden.
  • Der Rechenknoten 3100 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen verkörpert sein, die in der Lage sind, verschiedene Rechenfunktionen auszuführen. Der Rechenknoten 3100 kann den UEs 1211, 1221a, NANs 1231 bis 1233, Edge-Computing-Knoten 1236, CN 1242 (oder Rechenknoten) darin) und/oder Cloud 1244 (oder Rechenknoten) darin) der 12; Edge-Cloud 1310 (oder Systemen/Vorrichtungen darin), Zentrale 1320 (oder Systemen/Vorrichtungen darin), NAN 1340, dem Verarbeitungs-Hub 1350, und/oder Endpunktvorrichtungen 1360 der 13; Verwendungsfallvorrichtungen 1405, Netzwerkausrüstungen (Knoten) 1415, Ausrüstung 1425 der 14; Client-Endpunkten 1510, einem Vor-Ort-Netzwerksystem 1532, Zugangspunkt 1534, Aggregationspunkte 1542, 1544, Edge-Aggregationsknoten 1540 und/oder Datenzentrum 1560 (oder Systemen/Vorrichtungen darin) der 15; Vorrichtungen 1610, Edge-Knoten 1622, 1624 und/oder Cloud/Datenzentrum 1640 der 16; Containermanager 1711, 1721, Containerorchestrator 1731 und/oder Rechenknoten 1715, 1723 der 17; Client-Rechenknoten 1810, Edge-Gateway-Vorrichtungen 1820, Edge-Ressourcenknoten 1840, NAN 1842, Kerndatenzentrum 1850 (oder Systemen/Vorrichtungen darin) der 18; UE 2101, EES 2155, und/oder ECS 2160 der 21; UE 2420, MEC-Host 2402 (oder Systemen/Vorrichtungen darin), MEC-Plattform 2432, OSS 2412 (oder Systemen/Vorrichtungen darin) der 24; MEC-Plattform 2810 der 28; Softwareverteilungsplattform 3005 und/oder Prozessorplattform(en) 3000 der 30; und/oder einer beliebigen anderen Komponente, Vorrichtung und/oder einem beliebigen anderen System, die/das hier erörtert wird.
  • Bei einigen Beispielen kann der Rechenknoten 3100 als eine einzelne Vorrichtung verkörpert 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 3100 weist einen Prozessor 3104 und einen Speicher 3106 auf oder ist als dieser verkörpert. Der Prozessor 3104 kann als eine beliebige Art von Prozessor verkörpert sein, der in der Lage ist, die hier beschriebenen Funktionen (zum Beispiel Ausführen einer Anwendung) auszuführen. Der Prozessor 3104 kann zum Beispiel als (ein) Mehrkernprozessor(en), ein Mikrocontroller oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung verkörpert sein.
  • Bei einigen Beispielen kann der Prozessor 3104 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), eine rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder eine andere spezialisierte Hardware verkörpert sein, diese enthalten oder an diese gekoppelt sein, um eine Ausführung der hierin beschriebenen Funktionen zu ermöglichen. Bei einigen Beispielen kann der Prozessor 3104 auch als eine spezialisierte x-Verarbeitungseinheit (xPU) verkörpert sein, die auch als eine Datenverarbeitungseinheit (DPU), eine Infrastrukturverarbeitungseinheit (IPU) oder eine Netzwerkverarbeitungseinheit (NPU) bekannt ist. Eine derartige xPU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungs-Package verkörpert sein, innerhalb eines SOC integriert sein oder mit einer Networking-Schaltungsanordnung (zum Beispiel in einem SmartNIC oder einem erweiterten SmartNIC), einer Beschleunigungsschaltungsanordnung, Speicherungsvorrichtungen, Speicherungsplatten oder AI-Hardware (zum Beispiel GPUs oder programmierte FPGAs) integriert sein. Eine derartige xPU kann ausgelegt sein, um eine Programmierung zu empfangen, um einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Handlungen für die Datenströme auszuführen (wie Hosten von Mikrodiensten, Ausführen von Dienstverwaltung oder Orchestrierung, Organisieren oder Verwalten von Server- oder Datenzentrums-Hardware, Verwalten von vermaschten Dienstnetzwerken oder Sammeln und Verteilen von Telemetrie), außerhalb der CPU oder außerhalb von Allzweckverarbeitungs-Hardware. Es versteht sich jedoch, dass eine xPU, ein SOC, eine CPU und andere Variationen des Prozessors 3104 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb und im Auftrag des Rechenknotens 3100 auszuführen.
  • Der Speicher 3106 kann als ein beliebiger Typ flüchtiger (zum Beispiel dynamischer Direktzugriffsspeicher (DRAM: Dynamic Random Access Memory) usw.) oder nichtflüchtiger Speicher oder nichtflüchtiger Datenspeicher verkörpert sein, der in der Lage ist, die hier beschriebenen Funktionen auszuführen. Flüchtiger Speicher kann ein Speichermedium sein, das Leistung benötigt, um den Zustand von durch das Medium gespeicherten Daten aufrechtzuerhalten. Nichtbeschränkende Beispiele für flüchtigen Speicher können diverse Typen von Direktzugriffsspeicher (RAM), wie DRAM oder statischen Direktzugriffsspeicher (SRAM), beinhalten. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM: Synchronous Dynamic Random Access Memory).
  • Bei einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichereinrichtung kann auch eine dreidimensionale Koppelpunkt-Speichereinrichtung (zum Beispiel Intel® 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige Speichereinrichtungen 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-Koppelpunkt-Speicher (zum Beispiel 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 einigen Beispielen kann der gesamte oder ein Teil des Hauptspeichers 3106 in dem Prozessor 3104 integriert sein. Der Hauptspeicher 3106 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 3102 ist über das E/A-Subsystem 3108, das als eine Schaltungsanordnung und/oder Komponenten verkörpert sein kann, kommunikativ mit anderen Komponenten des Rechenknotens 3100 gekoppelt, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 3102 (zum Beispiel mit dem Prozessor 3104 und/oder dem Hauptspeicher 3106) und anderen Komponenten der Rechenschaltungsanordnung 3102 zu ermöglichen. Das E/A-Subsystem 3108 kann zum Beispiel als Speichersteuervorrichtungs-Hubs, Eingabe/Ausgabe-Steuerungs-Hubs, integrierte Sensor-Hubs, Firmwarevorrichtungen, Kommunikationsverbindungen zum Beispiel Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Subsysteme verkörpert sein oder diese anderswie beinhalten, um die Eingabe/Ausgabe-Operationen zu erleichtern. Bei einigen Beispielen kann das E/A-Subsystem 3108 einen Teil eines SoC bilden und zusammen mit dem Prozessor 3104 und/oder dem Hauptspeicher 3106 und/oder anderen Komponenten der Rechenschaltungsanordnung 3102 in die Rechenschaltungsanordnung 3102 integriert sein.
  • Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen/-platten 3110 können als eine oder mehrere beliebige Arten von physischer Vorrichtung bzw. physischen Vorrichtungen verkörpert sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert ist bzw. sind, wie etwa zum Beispiel Speichervorrichtungen, Speicherschaltungsanordnungen, Speicherkarten, Flash-Speicher, Festplattenlaufwerke, Festkörperlaufwerke (SSDs) und/oder andere Datenspeicherungsvorrichtungen bzw. -platten. Individuelle Datenspeicherungsvorrichtungen/-platten 3110 können eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung/-platte 3110 speichert. Individuelle Datenspeicherungsvorrichtungen/-platten 3110 können auch eine oder mehrere Betriebssystempartitionen beinhalten, die Dateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel der Art des Computerknotens 3100 speichern.
  • Die Kommunikationsschaltungsanordnung 3112 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder Sammlung davon verkörpert sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 3102 und einer anderen Rechenvorrichtung (zum Beispiel einem Edge-Gateway-Knoten oder dergleichen) zu ermöglichen. Die Kommunikationsschaltungsanordnung 3112 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (zum Beispiel drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle zum Beispiel ein zellulares Networking-Protokoll, wie etwa einen 3GPP-4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/WiFi®, ein Wireless Wide Area Network Protocol, 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 derartige Kommunikation zu bewirken.
  • Die Kommunikationsschaltungsanordnung 3112 beinhaltet eine Netzwerkschnittstellensteuervorrichtung (NIC) 3120, die auch als Host-Fabric-Schnittstelle (HFI) bezeichnet werden kann. Die NIC 3120 kann als ein oder mehrere Add-In-Boards, Tochterplatinen, Netzwerkkarten, Steuerungschips, Chipsätze oder andere Vorrichtungen verkörpert sein, die von dem Rechenknoten 3100 verwendet werden können, um eine Verbindung mit einer anderen Rechenvorrichtung herzustellen. Bei einigen Beispielen kann die NIC 3120 als Teil eines System-on-a-Chip (SoC) verkörpert sein, das einen oder mehrere Prozessoren beinhaltet, oder auf einem Multi-Chip-Package enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. Bei einigen Beispielen kann die NIC 3120 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide zur NIC 3120 lokal sind. Bei derartigen Beispielen kann der lokale Prozessor der NIC 3120 dazu in der Lage sein, eine oder mehrere der Funktionen der hier beschriebenen Rechenschaltungsanordnung 3102 auszuführen. Zusätzlich oder alternativ kann in derartigen Beispielen der lokale Speicher der NIC 3120 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chip-Ebene und/oder anderen Ebenen integriert sein. Zusätzlich oder alternativ kann die Kommunikationsschaltungsanordnung 3112 einen oder mehrere Transceiver (TRx) 3121 beinhalten, die jeweils verschiedene Hardwarevorrichtungen/-komponenten, wie etwa einen oder mehrere Basisbandprozessoren, Schalter, Filter, Verstärker, Antennenelemente und dergleichen, beinhalten, um Kommunikationen über eine Luftschnittstelle zu ermöglichen.
  • Zusätzlich kann bei einigen Beispielen ein jeweiliger Computerknoten 3100 eine oder mehrere Peripherievorrichtungen 3114 beinhalten. Derartige Peripherievorrichtungen 3114 können eine beliebige Art von Peripherievorrichtung beinhalten, die man in einer Rechenvorrichtung oder einem Server antrifft, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe-/Ausgabevorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 3100. In weiteren Beispielen kann der Computerknoten 3100 von einem jeweiligen Edge-Computing-Knoten in einem Edge-Computing-System (zum Beispiel Client-Computerknoten, Edge-Gateway-Knoten, Edge-Aggregationsknoten, V-ITS-Ss, die zuvor besprochen wurden, usw.) oder ähnliche Formen von Geräten, Computern, Subsystemen, Schaltungen oder anderen Komponenten verkörpert sein.
  • 32 veranschaulicht ein Beispiel für Komponenten, die in einem Edge-Computing-Knoten 3250 zum Umsetzen der hierin beschriebenen Techniken (zum Beispiel Operationen, Prozesse, Verfahren und Methoden) vorhanden sein können. Der Edge-Computing-Knoten 3250 kann den UEs 1211, 1221 a, NANs 1231 bis 1233, Edge-Computing-Knoten 1236, CN 1242 (oder Rechenknoten) darin) und/oder Cloud 1244 (oder Rechenknoten) darin) der 12; Edge-Cloud 1310 (oder Systemen/Vorrichtungen darin), Zentrale 1320 (oder Systemen/Vorrichtungen darin), NAN 1340, Verarbeitungsknoten 1350, und/oder Endpunktvorrichtungen 1360 der 13; Verwenden von Fallvorrichtungen 1405, Netzwerkausrüstungen (Knoten) 1415, Ausrüstung 1425 der 14; Client-Endpunkte 1510, ein Vor-Ort-Netzwerksystem 1532, Zugangspunkt 1534, Aggregationspunkte 1542, 1544, Edge-Aggregationsknoten 1540 und/oder Datenzentrum 1560 (oder Systeme/Vorrichtungen darin) der 15; Vorrichtungen 1610, Edge-Knoten 1622, 1624 und/oder Cloud/Datenzentrum 1640 der 16; Containermanager 1711, 1721, Containerorchestrator 1731 und/oder Rechenknoten 1715, 1723 der 17; Client-Rechenknoten 1810, Edge-Gateway-Vorrichtungen 1820, Edge-Ressourcenknoten 1840, NAN 1842, Kerndatenzentrum 1850 (oder Systeme/Vorrichtungen darin) der 18; UE 2101, EES 2155 und/oder ECS 2160 der 21; UE 2420, MEC-Host 2402 (oder Systeme/Vorrichtungen darin), MEC-Plattform 2432, OSS 2412 (oder Systeme/Vorrichtungen darin) der 24; MEC-Plattform 2810 der 28; Softwareverteilungsplattform 3005 und/oder Prozessorplattform(en) 3000 der 30; Computerknoten 3100 der 31; und/oder eine beliebige andere Komponente, Vorrichtung und/oder ein beliebiges anderes hierin besprochenes System, entsprechen.
  • Der Edge-Computing-Knoten 3250 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 3100 bereit, wenn er als oder als Teil einer Rechenvorrichtung (zum Beispiel als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway, ein Gerät, ein Edge-Computing-Knoten usw.) umgesetzt wird. Der Edge-Computing-Knoten 3250 kann beliebige Kombinationen der hierin referenzierten Hardware oder logischen Komponenten beinhalten, und er kann eine beliebige Vorrichtung beinhalten oder mit dieser koppeln, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination derartiger 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 3250 angepasst sind, oder als Komponenten, die anderswie in einem Chassis eines größeren Systems integriert sind, umgesetzt sein.
  • Der Edge-Computing-Knoten 3250 weist eine Verarbeitungsschaltungsanordnung in der Form eines oder mehrerer Prozessoren 3252 auf. Die Prozessorschaltungsanordnung 3252 beinhaltet Schaltanordnungen, wie einen oder mehrere Prozessorkerne und eines oder mehrere von Cache-Speicher, Low-Drop-Out-Spannungsregler (LDOs), Interrupt-Steuerungen, seriellen Schnittstellen, wie SPI, I2C, oder eine universelles programmierbares serielles Schnittstellenschaltung, Echtzeittakt (RTC), Timer-Zähler, einschließlich Intervall- und Watchdog-Timern, Allzweck-E/A, Speicherkartensteuerungen wie Secure Digital/MultiMediaCard (SD/MMC) oder ähnlichen, Schnittstellen, mobile Industrie-Prozessorschnittstellen (MIPI-Schnittstellen) und Joint-Test-Access-Group (JTAG)-Testzugangsports ein, ohne darauf beschränkt zu sein. Bei einigen Umsetzungen kann die Prozessorschaltungsanordnung 3252 einen oder mehrere Hardwarebeschleuniger (zum Beispiel gleich oder ähnlich der Beschleunigungsschaltungsanordnung 3264) beinhalten, die Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen (zum Beispiel 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 einigen Umsetzungen kann die Prozessorschaltungsanordnung 3252 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 die hierin besprochenen, beinhalten kann.
  • Die Prozessorschaltungsanordnung 3252 kann zum Beispiel ein oder mehrere Prozessorkerne (CPUs), Anwendungsprozessoren, GPUs, RISC-Prozessoren, Acorn-RISC-Maschinenprozessoren (ARM-Prozessoren), CISC-Prozessoren, ein oder mehrere DSPs, ein oder mehrere FPGAs, ein oder mehrere PLDs, ein oder mehrere ASICs, ein oder mehrere Basisbandprozessoren, ein oder mehrere integrierte Hochfrequenzschaltungen (RFIC), ein oder mehrere Mikroprozessoren oder Steuervorrichtungen, ein Mehrkernprozessor, ein Multithreaded Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder beliebige andere bekannte Verarbeitungelemente oder eine beliebige geeignete Kombination davon sein. Die Prozessoren (oder Kerne) 3252 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 3250 laufen. Der Prozessor (oder die Kerne) 3252 ist (sind) dazu konfiguriert, Anwendungssoftware zu betreiben, um einem Benutzer der Plattform 3250 einen spezifischen Dienst bereitzustellen. Zusätzlich oder alternativ können der eine oder die mehreren Prozessoren 3252 Spezialprozessor(en)/-steuervorrichtung(en) sein, der (die) dazu konfiguriert (oder konfigurierbar) ist (sind), gemäß den hierin besprochenen Elementen, Merkmalen und Umsetzungen zu arbeiten.
  • Als Beispiele können der eine oder die mehreren Prozessoren 3252 einen Core™-basierten Intel®-Architekturprozessor, wie etwa einen i3-, einen i5-, einen i7-, einen i9-basierten Prozessor; einen Mikrocontroller-basierten Intel®-Prozessor, wie etwa einen Quark™-, einen Atom™- oder einen anderen MCU-basierten Prozessor; einen oder mehrere Pentiumprozessoren, Xeon ®-Prozessor oder einen anderen derartigen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa eine oder mehrere Advanced Micro Devices-Zen®-Architekturen (AMD-Zen®-Architekturen), wie etwa Ryzen®- oder EPYC®-Prozessor(en), Accelerated Processing Units (APUs), MxGPUs, Epyc®-Prozessor(en) oder dergleichen; A5-A12- und/oder S1-S4-Prozessor(en) von Apple® Inc., Snapdragon™- oder Centriq™-Prozessor(en) von QualCommon® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™-Prozessor(en); ein MIPS-basiertes Design von MIPS Technologies, Inc. wie MIPS Warrior-M-class-, Warrior I-class- und Warrior P-class-Prozessoren; ein ARM-basiertes Design, lizenziert von ARM Holdings, Ltd., wie die ARM Cortex-A-, Cortex-R- und Cortex-M-Prozessorfamilie; der von Cavium™, Inc. bereitgestellte ThunderX2®; oder dergleichen. Bei einigen Umsetzungen können der eine oder die mehreren Prozessoren 3252 ein Teil eines System-on-Chip (SoC), System-in-Package (SiP), eines Multi-Chip-Package (MCP) und/oder dergleichen sein, in dem der eine oder die mehreren Prozessoren 3252 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse, wie etwa den Edison™- oder Galileo™-SoC-Platinen von Intel® Corporation, gebildet sind. Andere Beispiele für den einen oder die mehreren Prozessoren 3252 sind an anderer Stelle der vorliegenden Offenbarung erwähnt.
  • Der eine oder die mehreren Prozessoren 3252 können über ein Interconnect (IX) 3256 mit dem Systemspeicher 3254 kommunizieren. Eine beliebige Anzahl von 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 die DDR- oder mobilen DDDR-Standards (zum Beispiel LPDDR, LPDDR2, LPDDR3 oder LPDDR4). Bei bestimmten Beispielen kann eine Speicherkomponente einem von JEDEC vertriebenen DRAM-Standard entsprechen, wie etwa JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low Power DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Andere RAM-Typen, wie etwa dynamischer RAM (DRAM), synchroner DRAM (SDRAM) und/oder dergleichen, können ebenfalls enthalten sein. Derartige Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden, und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die derartige Standards umsetzen, können als DDR-basierte Schnittstellen bezeichnet werden. Bei diversen Umsetzungen können die einzelnen Speichervorrichtungen aus einer beliebigen Anzahl von unterschiedlichen Gehäusetypen bestehen, wie etwa Single-Die-Package (SDP), Dual-Die-Package (DDP) oder Quad-Die-Package (Q17P). Diese Vorrichtungen können bei einigen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit einem niedrigeren Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum von einem gegebenen Steckverbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherumsetzungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, zum Beispiel Dual-Inline-Speichermodule (DIMMs) unterschiedlicher Sorten, 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 3258 auch über das IX 3256 mit dem Prozessor 3252 gekoppelt sein. Bei einem Beispiel kann die Speicherung 3258 über ein Festkörperplattenlaufwerk (SSDD) und/oder einen elektrisch löschbaren Hochgeschwindigkeitsspeicher (allgemein als „Flash-Speicher“ bezeichnet) umgesetzt werden. Andere Vorrichtungen, die für die Speicherung 3258 verwendet werden können Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, eXtreme Digital-Bildkarten (XD-Bildkarten) und dergleichen, und USB-Flash-Laufwerke beinhalten. Bei 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, Sauerstoff-Vakanz-Basis und Conductive-Bridge-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque-MRAM (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 Domain-Wall- und SOT-Basis (Spin Orbit Transfer-Basis), eine Speichervorrichtung auf Thyristorbasis oder eine Kombination beliebiger der obigen oder anderen Speicher einsetzt. Die Speicherschaltungsanordnung 3254 und/oder die Speicherschaltungsanordnung 3258 können auch dreidimensionale (3D) Crosspoint-Speicher (XPOINT-Speicher) von Intel® und Micron® beinhalten.
  • Bei Niederleistungsumsetzungen kann die Speicherung 3258 ein On-Die-Speicher oder - register sein, der/die mit dem Prozessor 3252 assoziiert ist. Bei einigen Beispielen kann die Speicherung 3258 jedoch unter Verwenden eines Mikrofestplattenlaufwerks (Mikro-HDD) umgesetzt werden. Weiter kann eine beliebige Anzahl neuer Technologien für die Speicherung 3258 zusätzlich zu den oder an Stelle der beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
  • Die Komponenten der Edge-Computing-Vorrichtung 3250 können über eine Zwischenverbindung (IX) 3256 kommunizieren. Die IX 3256 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich 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, RapidlO™-System IXs, CCIX, Gen-Z-Consortium-IXs, eines HyperTransport-Interconnect, NVLink, von NVIDIA ® bereitgestellt, einem Time-Trigger Protocol-System (TTP-System), einem FlexRay-System, PROFIBUS und/oder einer beliebigen Anzahl anderer IX-Technologien. Der IX 3256 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
  • Der IX 3256 koppelt den Prozessor 3252 mit einer Kommunikationsschaltungsanordnung 3266 zur Kommunikation mit anderen Vorrichtungen, wie etwa einem Fernserver (nicht gezeigt) und/oder den verbundenen Edge-Vorrichtungen 3262. Die Kommunikationsschaltungsanordnung 3266 ist ein Hardwareelement oder eine Sammlung von Hardwareelementen, das/die zum Kommunizieren über ein oder mehrere Netzwerke (zum Beispiel Cloud 3263) und/oder mit anderen Vorrichtungen (zum Beispiel Edge-Vorrichtungen 3262) verwendet wird/werden. Die Sammlung von Hardwareelementen beinhaltet Hardwarevorrichtungen, wie etwa Basisbandschaltungsanordnung 326x, Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu erleichtern).
  • Der Transceiver 3266 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa 2,4 GigaHertz-Übertragungen (2,4-GHz-Übertragungen) unter dem IEEE 802.15.4-Standard unter Verwenden des Bluetooth®-Niederenergie-Standards (BLE-Standards), wie unter anderem 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 3262 verwendet werden. Zum Beispiel kann eine WLAN-Einheit (Wireless Local Area Network - WLAN) verwendet werden, um Wi-Fi®-Kommunikation gemäß dem IEEE 802.11-Standard (Institute of Electrical and Electronics Engineers - IEEE) umzusetzen. Zusätzlich kann Drahtlos-Weitverkehrskommunikation, zum Beispiel gemäß einem zellenbasierten oder anderen Drahtlos-Weitverkehrsprotokoll über eine Drahtlos-Weitverkehrsnetzwerkeinheit (WWAN-Einheit) stattfinden.
  • Die Kommunikationsschaltungsanordnung 3266 (oder mehrerer Transceiver 3266) kann unter Verwenden mehrerer Standards oder Funkgeräte für Kommunikationen in unterschiedlicher Reichweite kommunizieren. Zum Beispiel kann die Kommunikationsschaltungsanordnung 3266 eine Kurzstrecken-RAT-Schaltungsanordnung 326y beinhalten, um mit relativ nahen Vorrichtungen (zum Beispiel innerhalb von etwa 10 Metern) basierend auf BLE oder einem anderen Niederleistungsfunkgerät zu kommunizieren, um Leistung zu sparen. Weiter entfernte verbundene Edge-Vorrichtungen 3262 (zum Beispiel innerhalb von etwa 50 Metern) können über ZigBee®-Schaltungsanordnung 326y und/oder andere Zwischenleistungsfunkgeräte 326y erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät 326y mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Transceiver 326y stattfinden, zum Beispiel einen lokalen Transceiver 326y, der BLE verwendet, und einen separaten Mesh-Transceiver 326y, der ZigBee® verwendet.
  • Ein Drahtlosnetzwerktransceiver 326z kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 3263 über lokale oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerktransceiver 326z kann ein LPWA-Transceiver sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 3250 kann über einen weiten Bereich unter Verwenden von LoRaWAN™ (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wird, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Transceiver verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite umsetzen, wie etwa Sigfox, und andere Technologien. Weiter können andere Kommunikationstechniken, wie etwa zeitgeschlitztes Kanalspringen, die in der IEEE 802.15.4e-Spezifikation beschrieben sind, verwendet werden.
  • Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann, wie hierin beschrieben, zusätzlich zu den für den Drahtlosnetzwerktransceiver 326z erwähnten Systemen verwendet werden. Der Transceiver 326z kann zum Beispiel einen zellularen Transceiver beinhalten, der Spreizspektrum-Kommunikationen (SPA/SAS-Kommunikationen) zum Umsetzen von Hochgeschwindigkeitskommunikationen verwendet. Weiter kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Transceiver 326z 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 Netzwerkschnittstellensteuervorrichtung (NIC) 3268 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 3263 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 3262 (die zum Beispiel in einem Netz arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf vielen 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 3268 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 3268 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 3268 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 der Komponenten 3264, 3266, 3268 oder 3270 beinhalten oder von diesen verkörpert sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (zum Beispiel Empfangen, Übertragen usw.) von einer derartigen Kommunikationsschaltungsanordnung verkörpert werden.
  • Der Edge-Computing-Knoten 3250 kann eine Beschleunigungsschaltungsanordnung 3264 beinhalten oder mit dieser gekoppelt sein, die von einem oder mehreren AI-Beschleunigern, einem Neuronalrechenstick, neuromorpher Hardware, einem FPGA, einer Anordnung von GPUs, einem oder mehreren SoCs (einschließlich programmierbarer SoCs), einer oder mehreren CPUs, einem oder mehreren digitalen Signalprozessoren, dedizierten ASICs (einschließlich programmierbarer ASICs), PLDs, wie etwa CPLDs oder HCPLDs, und/oder anderen Formen spezialisierter Prozessoren oder Schaltungsanordnungen, die dazu ausgelegt sind, eine oder mehrere spezialisierte Aufgaben zu erfüllen, verkörpert werden. Diese Aufgaben können AI-Verarbeitung (einschließlich Operationen zum Maschinellen Lernen, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterfassung, Regelanalyse oder dergleichen beinhalten. Bei FPGA-basierten Umsetzungen kann die Beschleunigungsschaltungsanordnung 3264 Logikblöcke oder Logik-Fabric und andere miteinander verbundene Ressourcen umfassen, die programmiert (konfiguriert) werden können, um verschiedene Funktionen auszuführen, wie etwa die hierin besprochenen Vorgehensweisen, Verfahren, Funktionen usw. Bei derartigen Umsetzungen kann die Beschleunigungsschaltungsanordnung 3264 auch Speicherzellen (zum Beispiel EPROM, EEPROM, Flash-Speicher, statischen Speicher (zum Beispiel SRAM, Anti-Fuses usw.)) beinhalten, die zum Speichern von Logikblöcken, Logik-Fabric, Daten usw. in LUTs und dergleichen verwendet werden.
  • Das IX 3256 koppelt auch den Prozessor 3252 mit einem Sensor-Hub oder einer externen Schnittstelle 3270, die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die zusätzlichen/externen Vorrichtungen können Sensoren 3272, Aktuatoren 3274 und Positionsbestimmungsschaltungsanordnungen 3275 beinhalten.
  • Die Sensorschaltungsanordnung 3272 beinhaltet Vorrichtungen, Module oder Subsysteme, deren Zweck darin besteht, Ereignisse oder Änderungen in ihrer Umgebung zu Erfassen und die Informationen (Sensordaten) über die erfassten Ereignisse an eine andere Vorrichtung, ein Modul, ein Subsystem usw. zu senden. Beispiele für derartige Sensoren 3272 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; Niveausensoren; Strömungssensoren; Temperatursensoren (zum Beispiel Thermistoren); Drucksensoren; barometrische Drucksensoren; Gravimeter; Höhenmesser; Bilderfassungsvorrichtungen (zum Beispiel Kameras); Lichterfassungs- und Entfernungsmessungssensoren (LiDAR); Näherungssensoren (zum Beispiel Infrarotstrahlungsdetektor und dergleichen); Tiefensensoren, Umgebungslichtsensoren; optische Lichtsensoren; Ultraschall-Transceiver; Mikrofone; und dergleichen.
  • Die Aktuatoren 3274 erlauben es der Plattform 3250, ihren Zustand, ihre Position und/oder ihre Orientierung zu ändern oder einen Mechanismus oder ein System zu bewegen oder zu steuern. Die Aktuatoren 3274 umfassen elektrische und/oder mechanische Vorrichtungen zum Bewegen oder Steuern eines Mechanismus oder Systems und wandeln Energie (zum Beispiel elektrischen Strom oder sich bewegende Luft und/oder Flüssigkeit) in irgendeine Art von Bewegung um. Die Aktuatoren 3274 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 3274 können eine oder mehrere elektromechanische Vorrichtungen beinhalten, wie etwa pneumatische Aktuatoren, hydraulische Aktuatoren, elektromechanische Schalter einschließlich elektromechanischer Relais (EMRs), Motoren (zum Beispiel Gleichstrommotoren, Schrittmotoren, Servomechanismen usw.), Leistungsschalter, Ventilaktuatoren, Räder, Schubdüsen, Propeller, Klauen, Klemmen, Haken, Generatoren hörbaren Schalls, visuelle Warnvorrichtungen und/oder andere ähnliche elektromechanische Komponenten. Die Plattform 3250 kann dazu konfiguriert sein, einen oder mehrere Aktuatoren 3274 basierend auf einem oder mehreren aufgenommenen Ereignissen und/oder Anweisungen oder Steuersignalen, die von einem Dienstanbieter und/oder verschiedenen Client-Systemen empfangen werden, zu betreiben.
  • Die Positionierungsschaltungsanordnung 3275 beinhaltet eine Schaltungsanordnung zum Empfangen und Decodieren von Signalen, die von einem Positionierungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/gesendet werden. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) beinhalten Global Positioning System (GPS) der United States, Global Positioning System (GLONASS) von Russland, Galileo-System der Europäischen Union, Navigationssatellitensystem BeiDou von China, ein regionales Navigationssystem oder GNSS-Erweiterungssystem (zum Beispiel Navigation with Indian Constellation (NAVIC), Quasi-Zenith Satellite System (QZSS), Doppler Orbitography and Radio-Positioning Integrated by Satellite (DORIS) aus Frankreich usw.) oder dergleichen. Die Positionierungsschaltungsanordnung 3275 umfasst verschiedene Hardwareelemente (zum Beispiel einschließlich Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen), um mit Komponenten eines Positionierungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. Zusätzlich oder alternativ kann die Positionierungsschaltungsanordnung 3275 eine Micro-PNT-IC (Micro-Technology for Positioning, Navigation and Timing - Micro-PNT-IC) beinhalten, die einen Master-Timing-Takt verwendet, um eine Positionsverfolgung/Schätzung ohne GNSS-Unterstützung auszuführen. Die Positionierungsschaltungsanordnung 3275 kann auch Teil der Kommunikationsschaltungsanordnung 3266 sein oder mit dieser interagieren, um mit den Knoten und Komponenten des Positionierungsnetzwerks zu kommunizieren. Die Positionierungsschaltungsanordnung 3275 kann auch Positionsdaten und/oder Zeitdaten an die Anwendungsschaltlogik bereitstellen, die die Daten verwenden kann, um Operationen mit verschiedener Infrastruktur (zum Beispiel Funkbasisstationen) für die Turn-by-Turn-Navigation oder dergleichen zu synchronisieren. Wenn kein GNSS-Signal verfügbar ist oder wenn eine GNSS-Positionsgenauigkeit für eine bestimmte Anwendung oder einen bestimmten Dienst nicht ausreicht, kann eine Positionierungserweiterungstechnologie verwendet werden, um erweiterte Positionierungsinformationen und -daten für die Anwendung oder den Dienst bereitzustellen. Eine derartige Positionierungserweiterungstechnologie kann zum Beispiel satellitenbasierte Positionierungserweiterung (zum Beispiel EGNOS) und/oder bodenbasierte Positionierungserweiterung (zum Beispiel DGPS) beinhalten. Bei einigen Umsetzungen ist oder beinhaltet die Positionierungsschaltungsanordnung 3275 ein INS, das ein System oder eine Vorrichtung ist, das/die eine Sensorschaltungsanordnung 3272 (zum Beispiel Bewegungssensoren, wie etwa Beschleunigungsmesser, Rotationssensoren, wie etwa Gyroskope, und Höhenmesser, Magnetsensoren, und/oder dergleichen) verwendet, um kontinuierlich (zum Beispiel unter Verwenden von Dead-by-Dead-Reckoning, Triangulation oder dergleichen) eine Position, Orientierung und/oder Geschwindigkeit (einschließlich Richtung und Geschwindigkeit der Bewegung) der Plattform 3250 ohne die Notwendigkeit externer Referenzen zu berechnen.
  • Bei einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe-Vorrichtungen (E/A-Vorrichtungen) innerhalb des Edge-Computing-Knotens 3250 vorhanden oder mit diesem verbunden sein, die in 32 als Eingabeschaltungsanordnung 3286 und Ausgabeschaltungsanordnung 3284 bezeichnet werden. Die Eingabeschaltungsanordnung 3286 und die Ausgabeschaltungsanordnung 3284 beinhalten eine oder mehrere Benutzerschnittstellen, die dazu ausgelegt sind, eine Benutzerinteraktion mit der Plattform 3250 zu ermöglichen, und/oder Peripheriekomponentenschnittstellen, die dazu ausgelegt sind, eine Peripheriekomponenteninteraktion mit der Plattform 3250 zu ermöglichen. Die Eingabeschaltungsanordnung 3286 kann ein beliebiges physisches oder virtuelles Mittel zum Annehmen einer Eingabe beinhalten, darunter unter anderem eine oder mehrere physische oder virtuelle Tasten (zum Beispiel eine Rücksetztaste), eine physische Tastatur, ein Tastenfeld, eine Maus, ein Touchpad, ein Touchscreen, Mikrofone, ein Scanner, ein Headset und/oder dergleichen. Die Ausgabeschaltungsanordnung 3284 kann enthalten sein, um Informationen zu zeigen oder anderswie 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 3284 angezeigt werden. Die Ausgabeschaltungsanordnung 3284 kann eine beliebige Anzahl und/oder Kombinationen von Audio- oder visueller Anzeige beinhalten, darunter unter anderem eine oder mehrere einfache visuelle Ausgaben/Indikatoren (zum Beispiel binäre Statusindikatoren (zum Beispiel Leuchtdioden (LEDs)) und visuelle Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigevorrichtungen oder Touchscreens (zum Beispiel Liquid Crystal Displays (LCD), LED-Anzeigen, Quantenpunktanzeigen, Projektoren usw.), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen anhand des Betriebs der Plattform 3250 generiert oder erzeugt wird. Die Ausgabeschaltungsanordnung 3284 kann auch Lautsprecher oder andere Audioausgabevorrichtungen, Drucker und/oder dergleichen beinhalten. Zusätzlich oder alternativ kann die Sensorschaltungsanordnung 3272 als die Eingabeschaltungsanordnung 3284 (zum Beispiel eine Bildaufzeichnungsvorrichtung, Bewegungsaufzeichnungsvorrichtung oder dergleichen) verwendet werden, und können ein oder mehrere Aktuatoren 3274 als die Ausgabevorrichtungsschaltungsanordnung 3284 (zum Beispiel ein Aktuatoren zum Bereitstellen einer haptischen Rückmeldung oder dergleichen) verwendet werden. Bei einem anderen Beispiel kann eine Nahfeldkommunikation-Schaltungsanordnung (NFC-Schaltungsanordnung), die eine NFC-Steuervorrichtung umfasst, die mit einem Antennenelement und einer Verarbeitungsvorrichtung gekoppelt ist, enthalten sein, um elektronische Tags zu lesen und/oder mit einer anderen NFC-fähigen Vorrichtung zu verbinden. Peripheriekomponentenschnittstellen können unter anderem einen nichtflüchtigen Speicheranschluss, einen USB-Anschluss, eine Audio-Buchse, eine Stromversorgungsschnittstelle usw. umfassen. Eine Anzeige- oder Konsolen-Hardware kann in dem Kontext des vorliegenden Systems verwendet werden, um Ausgaben bereitzustellen und Eingaben 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 Management- oder Verwaltungsfunktionen oder Dienstanwendungsfällen auszuführen.
  • Eine Batterie 3276 kann den Edge-Computing-Knoten 3250 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Computing-Knoten 3250 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetzwerk gekoppelt ist, oder die Batterie als Backup oder für temporäre Fähigkeiten verwendet werden kann. Die Batterie 3276 kann eine Lithium-Ion-Batterie oder eine Metall-Luft-Batterie (zum Beispiel eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie usw.), ein oder mehrere Kondensatoren und dergleichen sein.
  • Eine Batterieüberwachungsvorrichtung/Ladevorrichtung 3278 kann in dem Edge-Computing-Knoten 3250 enthalten sein, um den Ladezustand (SoCh) der Batterie 3276, falls enthalten, zu verfolgen. Die Batterieüberwachungsvorrichtung/Ladevorrichtung 3278 kann verwendet werden, um andere Parameter der Batterie 3276 zu überwachen, um Ausfallvorhersagen, wie etwa den Gesundheitszustand (SoH: State of Health) und den Funktionszustand (SoF: State of Function), der Batterie 3276 bereitzustellen. Die Batterieüberwachungs-/Ladevorrichtung 3278 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa eine LTC4020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor, Phoenix Arizona, oder eine IC der UCD90xxx-Familie von Texas Instruments of Dallas, TX. Die Batterieüberwachungs-/- ladevorrichtung 3278 kann die Informationen über die Batterie 3276 über das IX 3256 an den Prozessor 3252 kommunizieren. Die Batterieüberwachungsvorrichtung/Ladevorrichtung 3278kann auch einen Analog-Digital-Wandler (ADC) beinhalten, der es dem Prozessor 3252 ermöglicht, die Spannung der Batterie 3276 oder den Stromfluss von der Batterie 3276 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Handlungen zu bestimmen, die der Edge-Computing-Knoten 3250 ausführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Abtastfrequenz und dergleichen. Bei einigen Umsetzungen kann die Batterie 3276 und/oder die Batterieüberwachungs-/Ladevorrichtung 3278 in Abhängigkeit von dem Verwendungsfall/der Umsetzung in unterschiedliche Leistungsbereiche unterteilt sein, wobei unterschiedliche Batterien 3276 für unterschiedliche Leistungsbereiche verwendet werden und jeder Leistungsbereich unterschiedliche Komponenten/Vorrichtungen des Edge-Computing-Knotens 3250 mit Leistung versorgen kann.
  • Ein Leistungsblock 3280 oder eine andere Leistungsversorgung, die mit einem Stromnetzwerk gekoppelt ist, kann mit der Batterieüberwachungsvorrichtung/Ladevorrichtung 3278 gekoppelt sein, um die Batterie 3276 zu laden. Bei einigen Beispielen kann der Leistungsblock 3280 mit einem Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Schleifenantenne in dem Edge-Computing-Knoten 3250, zu erhalten. Eine drahtlose Batterieladeschaltung, wie etwa unter anderem ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in der Batterieüberwachungs-/Ladevorrichtung 3278 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 3276 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwenden des von der Airfuel Alliance veröffentlicht Airfuel-Standards, des von dem Wireless Power Consortium veröffentlichten Qi-Drahtlosladestandards oder des von der Alliance für Wireless Power veröffentlichten Rezence Ladestandards ausgeführt werden.
  • Die Speicherung 3258 kann Anweisungen 3282 in der Form von Software-, Firmware- oder Hardwarebefehlen zum Umsetzen der hierin beschriebenen Techniken beinhalten. Obwohl derartige Anweisungen 3282 als Codeblöcke gezeigt sind, die in dem Speicher 3254 und der Speicherung 3258 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch fest verdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (Application Specific Integrated Circuit - ASIC) eingebaut sind.
  • Bei einem Beispiel können die Anweisungen 3282, die über den Speicher 3254, die Speicherung 3258 oder den Prozessor 3252 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 3260 verkörpert sein, das Code beinhaltet, um den Prozessor 3252 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten 3250 auszuführen. Der Prozessor 3252 kann über das IX 3256 auf das nichtflüchtige maschinenlesbare Medium 3260 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 3260 durch Vorrichtungen verkörpert sein, die für die Speicherung 3258 beschrieben sind, oder kann spezifische Speichereinheiten beinhalten, wie etwa Speichervorrichtungen und/oder Speicherplatten, die optische Platten (zum Beispiel Digital Versatile Disk (DVD), Compact Disk (CD), CD-ROM, Blu-Ray-Disk), Flash-Laufwerke, Floppy-Disks, Festplatten (zum Beispiel SSDs) oder eine beliebige Anzahl anderer Hardware-Vorrichtungen, in denen Informationen für eine beliebige Dauer (zum Beispiel für längere Zeiträume, dauerhaft, für kurze Fälle, zum temporären Puffern und/oder Caching) gespeichert sind. Das nichtflüchtige, maschinenlesbare Medium 3260 kann Anweisungen beinhalten, um den Prozessor 3252 anzuweisen, eine spezifische Folge oder einen spezifischen Ablauf von Aktionen auszuführen, wie zum Beispiel im Zusammenhang mit dem Ablaufdiagramm bzw. den Ablaufdiagrammen und Blockdiagrammen von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ sind austauschbar. Der Begriff „nichtflüchtiges computerlesbares Medium“ ist ausdrücklich derart definiert, dass er eine beliebige Art von computerlesbarer Speicherungsvorrichtung und/oder Speicherplatte umfasst und sich propagierende Signale ausschließt und Übertragungsmedien ausschließt.
  • Bei weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch ein beliebiges konkretes Medium, das in der Lage ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu codieren oder zu tragen, und die bewirken, dass die Maschine eines oder mehrere der Verfahren der vorliegenden Offenbarung ausführt, oder das in der Lage ist, Datenstrukturen zu speichern, zu codieren oder zu tragen, die von derartigen Anweisungen genutzt werden oder mit diesen assoziiert sind. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Spezifische Beispiele für maschinenlesbare Medien beinhalten nichtflüchtigen Speicher, einschließlich unter anderem Halbleiterspeichervorrichtungen (zum Beispiel elektrisch programmierbarer Nurlesespeicher (EPROM), elektrisch löschbarer programmierbarer nur-lese Speicher (EEPROM)) und Flash-Speichervorrichtungen; Magnetplatten, wie zum Beispiel interne Festplatten und herausnehmbare Platten; magneto-optische Platten; und CD-ROM- und DVD-ROM-Platten. Die Anweisungen, die von einem maschinenlesbaren Medium verkörpert werden, können weiter über ein Kommunikationsnetzwerk unter Verwenden eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung, die ein beliebiges einer Anzahl von Übertragungsprotokollen (zum Beispiel HTTP) nutzt, übertragen oder empfangen werden.
  • Ein maschinenlesbares Medium kann von einer Speicherungsvorrichtung oder einer anderen Einrichtung, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten, bereitgestellt werden. Bei einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderswie bereitgestellte Informationen Anweisungen darstellen, wie 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 (zum Beispiel in komprimierter oder verschlüsselter Form), verpackte Anweisungen (zum Beispiel aufgeteilt in mehrere Pakete) oder dergleichen beinhalten. Die Informationen, die Anweisungen in dem maschinenlesbaren Medium darstellen, können von einer Verarbeitungsschaltungsanordnung zu den Anweisungen verarbeitet werden, um beliebige der hierin besprochenen Operationen umzusetzen. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (zum Beispiel Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes beinhalten: Kompilieren (zum Beispiel aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (zum Beispiel dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderswie Manipulieren der Informationen in die Anweisungen.
  • Bei einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (zum Beispiel durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format, das von dem maschinenlesbaren Medium bereitgestellt wird, zu erzeugen. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Zum Beispiel können die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binärem ausführbaren Code usw.) auf einem oder mehreren entfernten Servern vorliegen. Die Quellcodepakete können verschlüsselt werden, wenn sie sich über ein Netzwerk bewegen, und entschlüsselt, dekomprimiert, bei Bedarf assembliert (zum Beispiel verknüpft) und an einer lokalen Maschine kompiliert oder interpretiert (zum Beispiel in eine Bibliothek, eigenständiges ausführbares Programm usw.) werden und von der lokalen Maschine ausgeführt werden.
  • Die Darstellungen der 31 und 32 sollen eine Ansicht auf hoher Ebene von Komponenten einer unterschiedlichen Vorrichtung, eines unterschiedlichen Subsystems oder einer unterschiedlichen Anordnung eines Edge-Computing-Knotens abbilden. Es versteht sich jedoch, dass einige der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können und eine unterschiedliche Anordnung der gezeigten Komponenten bei anderen Umsetzungen auftreten kann. Weiter sind diese Anordnungen in einer Vielzahl von Verwendungsfällen und Umgebungen verwendbar, einschließlich in jenen, die unten erörtert sind (zum Beispiel, unter vielen anderen Beispielen, ein mobiles UE in industrieller Berechnung für eine Smart-Stadt oder Smart-Fabrik).
  • Die jeweiligen Computing-Plattformen der 31 und 32 können mehrere Edge-Instanzen (zum Beispiel Edge-Cluster) durch Verwenden von Mandanten-Containern, die auf einer einzigen Computing-Plattform ausgeführt werden, unterstützen. Ebenso können mehrere Edge-Knoten als Unterknoten existieren, die auf Mandanten innerhalb derselben Computing-Plattform laufen. Dementsprechend kann basierend auf Partitionierung verfügbarer Ressourcen ein einzelnes System oder eine einzelne Computing-Plattform 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 Computing-Plattforminstanzen von mehreren Eigentümer 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 Umsetzung einer Isolations-/Sicherheitsrichtlinie unterstützen. Hinweise auf die Verwendung eines LSM und Sicherheitsmerkmale, die derartige Sicherheitsmerkmale verbessern oder umsetzen, werden daher in den folgenden Abschnitten erwähnt. Ebenso können Dienste und Funktionen, die an diesen verschiedenen Typen von Multi-Entitätspartitionen arbeiten, lastausgeglichen, migriert und orchestriert werden, um notwendige Dienstzielsetzungen und - operationen zu erreichen.
  • Die 31 und 32 bilden Beispiele für Edge-Computing-Systeme und Umgebungen ab, die beliebige der hierin besprochenen Rechenknoten oder Vorrichtungen erfüllen können. Jeweilige Edge-Computing-Knoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ verkörpert sein, das in der Lage ist, mit anderen Edge-, Networking- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Computing-Vorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (zum Beispiel ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen auszuführen, verkörpert sein.
  • 3. UMSETZUNGSBEISPIELE
  • 33 zeigt Prozesse 3301, 3302 und 3303, die verwendet werden können, um die verschiedenen hierin besprochenen Ausführungsformen umzusetzen. Der Prozess 3301 ist ein Prozess zum Betreiben eines edgeXapis-GW 710, der eine Operation 3311 beinhaltet, bei der das edgeXapis-GW 710 über einen ersten Referenzpunkt eine erste Verbindung mit einer ersten Edge-Computing-Plattform (ECP) herstellt, die eine erste Edge-Computing-Technologie (ECT) umsetzt. Das edgeXapis-GW 710 kann die eingerichtete erste Verbindung verwenden, um mit der ersten ECP zu kommunizieren. Bei Operation 3312 stellt das edgeXapis-GW 710 über einen zweiten Referenzpunkt eine zweite Verbindung mit einer zweiten ECP her, die eine zweite ECT umsetzt, die sich von der ersten ECT unterscheidet. Bei Operation 3313 deckt das edgeXapis-GW 710 zu der zweiten ECP über den zweiten Referenzpunkt einen Satz erster APIs, die von der ersten ECP aufgedeckt werden, auf. Das edgeXapis-GW 710 verwendet die hergestellte zweite Verbindung, um den Satz erster APIs an die zweite ECP zu kommunizieren.
  • Der Prozess 3302 ist ein Prozess zum Betreiben einer ersten ECP, die eine erste ECT umsetzt, die den Vorgang 3321 beinhaltet, bei dem die erste ECP über einen ersten Referenzpunkt eine erste Verbindung mit einem edgeXapis-GW 710 herstellt. Bei Operation 3322 erzeugt die erste ECP einen Satz erster APIs, die von der ersten ECP aufgedeckt werden. Bei Operation 3323 sendet die erste ECP über den ersten Referenzpunkt den Satz erster APIs, die von der ersten ECP zur Aufdeckung des Satzes erster APIs aufgedeckt werden, an eine zweite ECT, die sich von der ersten ECT unterscheidet, durch das edgeXapis-GW. Der erste ECP kann die eingerichtete erste Verbindung verwenden, um den Satz erster APIs an das edgeXapis-GW 710 zu kommunizieren, und das edgeXapis-GW 710 kann eine eingerichtete zweite Verbindung mit einem zweiten ECP verwenden, um den Satz erster APIs zu kommunizieren und der zweiten ECP darzustellen.
  • Der Prozess 3303 ist ein Prozess zum Betreiben einer zweiten ECP, die eine zweite ECT umsetzt, die den Vorgang 3331 beinhaltet, bei dem der zweite ECP über einen zweiten Referenzpunkt eine zweite Verbindung mit einem edgeXapis-GW 710 einrichtet. Das edgeXapis-GW 710 stellt auch eine erste Verbindung mit einer ersten ECP her, die eine erste ECT umsetzt, die sich von der zweiten ECT unterscheidet. Bei Operation 3332 betreibt die zweite ECP eine zweite Edge-App, um über den zweiten Referenzpunkt eine Anfrage nach einer Liste aufgedeckter APIs an das edgeXapis-GW 710 zu senden. Bei Operation 3333 empfängt die zweite ECP über den zweiten Referenzpunkt von dem edgeXapis-GW710 die Liste der aufgedeckten APIs. Die Liste aufgedeckten APIs beinhaltet einen Satz erster APIs, die von der ersten ECP aufgedeckt werden, und einen Satz zweiter APIs, die von der zweiten ECP aufgedeckt werden. Die zweite ECP kann die eingerichtete zweite Verbindung verwenden, um die Liste aufgedeckter APIs von dem edgeXapis-GW 710 zu erhalten, und das edgeXapis-GW 710 kann eine eingerichtete erste Verbindung mit der ersten ECP verwenden, um den Satz erster APIs von der ersten ECP zu erhalten.
  • Bei einem Beispiel für die Prozesse 3301, 3302 und 3303 ist die erste ECP eine MEC-Plattform 2422 in einem MEC-Framework 2400. Zusätzlich oder alternativ ist die zweite ECP ein EES 2155 in einem 3GPP-Edge-Computing-Framework 2100, die zweite Edge-App ist ein EAS 2150, und die MEC-Plattform 2422 setzt eine MEC-App 2426, die als ein Anwendungsserver eingesetzt wird, um. Zusätzlich oder alternativ sind die MEC-Plattform 2422 und die EES 2155 dazu konfiguriert, über eine Mp1-Schnittstelle und/oder einen Edge-3-Referenzpunkt miteinander zu kommunizieren.
  • Bei einem anderen Beispiel für Prozesse 3301, 3302 und 3303 ist die erste ECP ein EES 2155 in einem 3GPP-Edge-Computer-Framework 2100, und die zweite ECP ist eine MEC-Plattform 2422 in einem MEC-Framework 2400. Zusätzlich oder alternativ ist der EES 2155 dazu konfiguriert, einen EAS 2150 zu betreiben, und die zweite Edge-App ist eine MEC-App 2426, die als ein Anwendungsserver eingesetzt wird.
  • Zusätzlich oder alternativ zu den oben genannten Beispielen für Prozesse 3301, 3302 und 3303 ist das edgeXapis-GW 710 in einem CAPIF 400 enthalten oder mit diesem verbunden, und das edgeXapis-GW 710 ist dazu konfiguriert, mit der ersten ECP und/oder der zweiten ECP über einen CAPIF-2e-Referenzpunkt, einen CAPIF-3e-Referenzpunkt und/oder einen CAPIF-7E-Referenzpunkt zu kommunizieren. Zusätzlich oder alternativ ist das edgeXapis-GW 710 in einer CCF 405 enthalten. Alternativ dazu ist das edgeXapis-GW 710 außerhalb der CCF 405 und kommunikativ mit der CCF 405 gekoppelt. Zusätzlich oder alternativ ist die erste ECP dazu konfiguriert, als CAPIF-AEF 401 zu fungieren. Zusätzlich oder alternativ ist der erste Referenzpunkt ein CAPIF-1e-Referenzpunkt oder ein CAPIF-3e-Referenzpunkt. Zusätzlich oder alternativ ist der zweite Referenzpunkt ein CAPIF-1-Referenzpunkt oder ein CAPIF-3-Referenzpunkt.
  • Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht einschränkenden Umsetzungen.
  • 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 durch die gesamte vorliegende Offenbarung bereitgestellt werden, kombiniert werden.
  • Beispiel 1 beinhaltet ein Verfahren zum Betreiben eines Edge-Anwendungsprogrammierungsschnittstellendienst-Gateway (edgeXapis-Gateway - GW), wobei das Verfahren Folgendes umfasst: Einrichten, über einen ersten Referenzpunkt, einer ersten Verbindung mit einer ersten Edge-Computing-Plattform (ECP), die eine erste Edge-Computing-Technologie (ECT) umsetzt; Einrichten, über einen zweiten Referenzpunkt, einer zweiten Verbindung mit einer zweiten ECP, die eine zweite ECT umsetzt, die sich von der ersten ECT unterscheidet; und Aufdecken gegenüber der zweiten ECP über den zweiten Referenzpunkt, eines Satzes erster Anwendungsprogrammierschnittstellen (APIs), die von der ersten ECP aufgedeckt werden.
  • Beispiel 2 beinhaltet das Verfahren des Beispiels 1 und/oder einiger anderer Beispiele hierin, wobei das Einrichten der ersten Verbindung mit der ersten ECP Folgendes umfasst: Empfangen, von der ersten ECP über den ersten Referenzpunkt, des Satzes erster APIs, die von der ersten ECP freigelegt werden.
  • Beispiel 3 beinhaltet das Verfahren der Beispiele 1-2 und/oder einiger anderer Beispiele hierin, wobei das Einrichten der ersten Verbindung mit der ersten ECP umfasst: Authentifizieren und Verifizieren der ersten ECP unter Verwenden eines Authentifizierungs- und Attestierungsmechanismus.
  • Beispiel 4 beinhaltet das Verfahren des Beispiels 3 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Authentifizieren und Verifizieren von Anforderungen, die von der ersten ECP empfangen werden, unter Verwenden des Authentifizierungs- und Attestierungsmechanismus.
  • Beispiel 5 beinhaltet das Verfahren der Beispiele 3-4 und/oder einiger anderer Beispiele hierin, wobei der Authentifizierungs- und Attestierungsmechanismus eines oder beide von OAuth2 und Transportschichtsicherheit (TLS) ist.
  • Beispiel 6 beinhaltet das Verfahren der Beispiele 1 bis 5 und/oder einiger anderer Beispiele hierin, wobei das Einrichten der zweiten Verbindung mit der zweiten ECP Folgendes umfasst: Empfangen, über den zweiten Referenzpunkt von einer zweiten Edge-Anwendung (App), die von der zweiten ECP umgesetzt wird, einer Anfrage nach einer Liste aufgedeckter APIs; Erzeugen der Liste aufgedeckter APIs, wobei die Liste aufgedeckter APIs den Satz erster APIs, die von der ersten ECP aufgedeckt werden, und einen Satz zweiter APIs, die von der zweiten ECP aufgedeckt werden, enthält; und Senden, über den zweiten Referenzpunkt an die zweite Edge-App, der Liste aufgedeckter APIs.
  • Beispiel 7 beinhaltet das Verfahren des Beispiels 6 und/oder einiger anderer Beispiele hierin, das weiter Folgendes beinhaltet: Aktualisieren einer Liste von Edge-Apps, die Zugriff auf die Liste aufgedeckter APIs haben, um die zweite Edge-App zu beinhalten; und Senden der Liste von Edge-Apps an die erste ECP über den ersten Referenzpunkt.
  • Beispiel 8 beinhaltet das Verfahren der Beispiele 6-7 und/oder einiger anderer Beispiele hierin, wobei die zweite Edge-App in der Lage ist, erste Transportinformationen von der ersten ECP zu erhalten, wobei die ersten Transportinformationen Transportprotokolle angeben, die von der ersten ECP unterstützt werden.
  • Beispiel 9 beinhaltet das Verfahren der Beispiele 2 bis 7 und/oder einiger anderer Beispiele hierin, wobei das Einrichtender ersten Verbindung mit der ersten ECP weiter Folgendes umfasst: Empfangen erster Transportinformationen von der ersten ECP über den ersten Referenzpunkt, wenn die erste ECP den Satz erster APIs dem edgeXapis-GW aufgedeckt, wobei die ersten Transportinformationen Transportprotokolle angeben, die von der ersten ECP unterstützt werden.
  • Beispiel 10 beinhaltet das Verfahren des Beispiels 9 und/oder einiger anderer Beispiele hierin, weiter umfassend: Aufdecken, gegenüber der zweiten ECP über den zweiten Referenzpunkt, der ersten Transportinformation, wenn der Satz erster APIs gegenüber der zweiten ECP aufgedeckt wird.
  • Beispiel 11 beinhaltet das Verfahren der Beispiele 8 bis 10 und/oder eines oder mehrerer anderer Beispiele hierin, wobei die zweite Edge-App in der Lage ist, beliebige angekündigte API in der Liste aufgedeckter APIs aufzurufen.
  • Beispiel 12 beinhaltet das Verfahren des Beispiels 11 und/oder einiger anderer Beispiele hierin, wobei die zweite Edge-App in der Lage ist, mit einer ersten Edge-App, die von der ersten ECP umgesetzt wird, über einen dritten Referenzpunkt unter Verwenden eines Transportprotokolls, das von der aufgerufenen API definiert wird, zu kommunizieren.
  • Beispiel 13 beinhaltet ein Verfahren zum Betreiben einer ersten Edge-Computing-Plattform (ECP), die eine erste Edge-Computing-Technologie (ECT) umsetzt, wobei das Verfahren umfasst: Einrichten, über einen ersten Referenzpunkt, einer ersten Verbindung mit einem Edge-Anwendungsprogrammierschnittstellendienst-Gateway (edgeXapis-Gateway - GW); Erzeugen eines Satzes erster Anwendungsprogrammierschnittstellen (APIs), die von der ersten ECP aufgedeckt werden; und Senden, von der ersten ECP über den ersten Referenzpunkt, des Satzes erster APIs, die von der ersten ECP aufgedeckt werden, zum Aufdecken des Satzes erster APIs gegenüber einer zweiten ECT, die sich von der ersten ECT unterscheidet, durch das edgeXapis-GW.
  • Beispiel 14 beinhaltet das Verfahren des Beispiels 13 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW eine zweite Verbindung mit der zweiten ECP über einen zweiten Referenzpunkt herstellen soll und den Satz erster APIs der zweiten ECP über den zweiten Referenzpunkt aufdecken soll.
  • Beispiel 15 beinhaltet das Verfahren der Beispiele 13-14 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW die erste ECP unter Verwenden eines Authentifizierungs- und Attestierungsmechanismus authentifizieren und verifizieren soll.
  • Beispiel 16 beinhaltet das Verfahren des Beispiels 15 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW Anforderungen, die von der ersten ECP empfangen werden, unter Verwenden des Authentifizierungs- und Attestierungsmechanismus authentifizieren und verifizieren soll.
  • Beispiel 17 beinhaltet das Verfahren der Beispiele 15-16 und/oder einiger anderer Beispiele hierin, wobei der Authentifizierungs- und Attestierungsmechanismus eines oder beide von OAuth2 und Transportschichtsicherheit (TLS) ist.
  • Beispiel 18 beinhaltet das Verfahren der Beispiele 14 bis 17 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW eine Anfrage nach einer Liste aufgedeckter APIs über den zweiten Referenzpunkt von einer zweiten Edge-Anwendung (App) empfangen soll, die von der zweiten ECP umgesetzt wird, die Liste aufgedeckter APIs erzeugen soll, wobei die Liste aufgedeckter APIs den Satz erster APIs, die von der ersten ECP aufgedeckt werden, und einen Satz zweiter APIs, die von der zweiten ECP aufgedeckt werden, beinhaltet, und Senden der Liste aufgedeckter APIs über den zweiten Referenzpunkt an die zweite Rand App.
  • Beispiel 19 beinhaltet das Verfahren des Beispiels 18 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das edgeXapis-GW weiter dazu dient, eine Liste von Edge-Apps, die Zugriff auf die Liste aufgedeckter APIs haben, zu aktualisieren, um die zweite Edge-Apps zu beinhalten, und die Liste von Edge-Apps über den ersten Referenzpunkt an die erste ECP zu senden.
  • Beispiel 20 beinhaltet das Verfahren der Beispiele 18-19 und/oder einiger anderer Beispiele hierin, weiter umfassend: Umsetzen einer ersten Edge-App, um als ein Anwendungsserver zu fungieren.
  • Beispiel 21 beinhaltet das Verfahren der Beispiele 18 bis 20 und/oder einiger anderer Beispiele hierin, das weiter beinhaltet: Erzeugen erster Transportinformationen, die Informationen über Transportprotokolle beinhalten, die von der ersten ECP unterstützt werden; und Senden der ersten Transportinformationen über den zweiten Referenzpunkt an die zweite Edge-App.
  • Beispiel 22 beinhaltet das Verfahren der Beispiele 13 bis 20 und/oder einiger anderer Beispiele hierin, wobei das Einrichten der ersten Verbindung mit dem edgeXapis-GW weiter umfasst: Erzeugen erster Transportinformationen, die Informationen über Transportprotokolle beinhalten, die von der ersten ECP unterstützt werden; und Senden der ersten Transportinformationen über den ersten Referenzpunkt, wenn der Satz erster APIs dem edgeXapis-GW ausgesetzt wird.
  • Beispiel 23 beinhaltet das Verfahren des Beispiels 22 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das edgeXapis-GW die ersten Transportinformationen der zweiten ECP über den zweiten Referenzpunkt aufdecken soll, wenn das edgeXapis-GW den Satz erster APIs der zweiten ECP aufgedeckt.
  • Beispiel 24 beinhaltet das Verfahren der Beispiele 18 bis 23 und/oder eines oder mehrerer anderer Beispiele hierin, wobei die zweite Edge-App in der Lage ist, beliebige angekündigte API in der Liste aufgedeckter APIs aufzurufen.
  • Beispiel 25 beinhaltet das Verfahren des Beispiels 24 und/oder einiger anderer Beispiele hierin, wobei die zweite Edge-App in der Lage ist, mit einer ersten Edge-App, die von der ersten ECP umgesetzt wird, über einen dritten Referenzpunkt unter Verwenden eines Transportprotokolls, das von der aufgerufenen API definiert wird, zu kommunizieren.
  • Beispiel 26 beinhaltet ein Verfahren zum Betreiben einer zweiten Edge-Computing-Plattform (ECP), die eine zweite Edge-Computing-Technologie (ECT) umsetzt, wobei das Verfahren umfasst: Einrichten, über einen zweiten Referenzpunkt, einer zweiten Verbindung mit einem Gateway (GW) eines Edge-Application Programming Interface Service (edgeXapis), wobei das edgeXapis-GW eine erste Verbindung mit einer ersten ECP herstellen soll, die eine erster ECT umsetzt, die sich von der zweiten ECT unterscheidet; Betreiben einer zweiten Edge-Anwendung (App), um eine Anfrage nach einer Liste aufgedeckter Anwendungsprogrammierschnittstellen (APIs) über den zweiten Referenzpunkt an das edgeXapis-GW zu senden; und Empfangen, über den zweiten Referenzpunkt von dem edgeXapis-GW, der Liste aufgedeckter APIs, wobei die Liste aufgedeckter APIs einen Satz erster APIs, die von der ersten ECP aufgedeckt werden, und einen Satz zweiter APIs, die von der zweiten ECP aufgedeckt werden, beinhaltet.
  • Beispiel 27 beinhaltet das Verfahren des Beispiels 26 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW den Satz erster APIs, die von der ersten ECP aufgedeckt werden, von der ersten ECP über den ersten Referenzpunkt empfangen soll.
  • Beispiel 28 beinhaltet das Verfahren der Beispiele 26-27 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW weiter die erste ECP unter Verwenden eines Authentifizierungs- und Attestierungsmechanismus authentifizieren und verifizieren soll.
  • Beispiel 29 beinhaltet das Verfahren des Beispiels 28 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW weiter Anfragen, die von der ersten ECP empfangen werden, unter Verwenden des Authentifizierungs- und Attestierungsmechanismus authentifizieren und verifizieren soll.
  • Beispiel 30 beinhaltet das Verfahren der Beispiele 28-29 und/oder einiger anderer Beispiele hierin, wobei der Authentifizierungs- und Attestierungsmechanismus eines oder beide von OAuth2 und Transportschichtsicherheit (TLS) ist.
  • Beispiel 31 beinhaltet das Verfahren der Beispiele 26 bis 30 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW weiter eine Liste von Edge-Apps mit Zugriff auf die Liste aufgedeckter APIs aktualisieren soll, um die zweite Edge-Apps zu beinhalten, und zum Senden der Liste von Edge-Apps an die erste ECP über den ersten Referenzpunkt.
  • Beispiel 32 beinhaltet das Verfahren der Beispiele 26 bis 31 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Betreiben der zweiten Edge-App, um erste Transportinformationen von der ersten ECP zu erhalten, wobei die ersten Transportinformationen Transportprotokolle angeben, die von der ersten ECP unterstützt werden.
  • Beispiel 33 beinhaltet das Verfahren der Beispiele 26-31 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW weiter erste Transportinformationen von der ersten ECP über den ersten Referenzpunkt empfangen soll, wenn die erste ECP den Satz erster APIs dem edgeXapis-GW auf deckt, wobei die ersten Transportinformationen Transportprotokolle angeben, die von der ersten ECP unterstützt werden.
  • Beispiel 34 beinhaltet das Verfahren des Beispiels 33 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Erhalten der ersten Transportinformationen von dem edgeXapis-GW über den zweiten Referenzpunkt, wenn der Satz erster APIs der zweiten ECP aufgedeckt wird.
  • Beispiel 34 beinhaltet das Verfahren der Beispiele 33-34 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Betreiben der zweiten Edge-App, um eine angekündigte API in der Liste aufgedeckter APIs aufzurufen.
  • Beispiel 35 beinhaltet das Verfahren des Beispiels 34 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Betreiben der zweiten Edge-App zum Kommunizieren mit einer ersten Edge-App, die von der ersten ECP umgesetzt wird, über einen dritten Referenzpunkt unter Verwenden eines Transportprotokolls, das von der aufgerufenen API definiert wird.
  • Beispiel 36 beinhaltet das Verfahren der Beispiele 12, 25 und 35 und/oder einiger anderer Beispiele hierin, wobei die erste ECP eine MEC-Plattform (MEC: Multi-Access Edge-Computing) in einem MEC-Framework ist und der dritte Referenzpunkt eine Mp1-Schnittstelle ist.
  • Beispiel 37 beinhaltet das Verfahren des Beispiels 36 und/oder einiger anderer Beispiele hierin, wobei die zweite ECP ein Edge-Enabler-Server (EES) in einem Edge-Computing Framework der dritten Generation Partnership Project (3GPP) ist, die zweite Edge-App ein Edge-Anwendungs-Server (EAS) ist und die erste Edge-App eine MEC-App ist, die als ein Anwendungsserver eingesetzt wird.
  • Beispiel 38 beinhaltet das Verfahren der Beispiele 12, 25 und 35 und/oder einiger anderer Beispiele hierin, wobei die erste ECP ein EES in einem 3GPP-Edge-Computing-Framework ist und der dritte Referenzpunkt ein Edge-3-Referenzpunkt ist.
  • Beispiel 39 beinhaltet das Verfahren des Beispiels 38 und/oder eines oder mehrerer anderer Beispiele hierin, wobei die zweite ECP eine MEC-Plattform in einem MEC-Framework ist, die erste Edge-App ein EAS ist und die zweite Edge-App eine MEC-App ist, die als ein Anwendungsserver eingesetzt wird.
  • Beispiel 40 beinhaltet das Verfahren der Beispiele 12, 25 und 35 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das edgeXapis-GW in einem gemeinsamen API-Framework (CAPIF) enthalten oder mit diesem verbunden ist, und der dritte Referenzpunkt ein CAPIF-2e-Referenzpunkt, ein CAPIF-3e-Referenzpunkt oder ein CAPIF-7E-Referenzpunkt ist.
  • Beispiel 41 beinhaltet das Verfahren der Beispiele 1 bis 40 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW in einem CAPIF enthalten oder mit diesem verbunden ist, und die erste ECP als eine CAPIF-API-Aufdeckungsfunktion (AEF) fungiert.
  • Beispiel 42 beinhaltet das Verfahren des Beispiels 41 und/oder einiger anderer Beispiele hierin, wobei das edgeXapis-GW Teil der CAPIF-Kernfunktion (CCF) der CAPIF ist.
  • Beispiel 43 beinhaltet das Verfahren des Beispiels 41 und/oder einiger anderer Beispiele hierin, wobei sich das edgeXapis-GW außerhalb einer CCF der CAPIF befindet.
  • Beispiel 44 beinhaltet das Verfahren der Beispiele 42-43 und/oder einiger anderer Beispiele hierin, wobei eine erste ECP-Konfiguration der ersten ECP einen Root-Uniform Resource Locator (URL) der CCF beinhaltet.
  • Beispiel 45 beinhaltet das Verfahren der Beispiele 41 bis 44 und/oder einiger anderer Beispiele hierin, wobei der erste Referenzpunkt ein CAPIF-1e-Referenzpunkt oder ein CAPIF-3e-Referenzpunkt ist.
  • Beispiel 46 beinhaltet das Verfahren der Beispiele 41 bis 45 und/oder einiger anderer Beispiele hierin, wobei der zweite Referenzpunkt ein CAPIF-1-Referenzpunkt oder ein CAPIF-3-Referenzpunkt ist.
  • Beispiel 47 beinhaltet ein Verfahren zum Umsetzen von Funktionalitäten und APIs, die zwei oder mehr Systemen entsprechen, die jeweilige Edge-Computing- und/oder Drahtloskommunikationsstandards umsetzen.
  • Beispiel 48 beinhaltet das Verfahren des Beispiels 47 und/oder eines oder mehrerer anderer Beispiele hierin, das weiter umfasst: eine Definition eines edgeXapis-GW als eine Funktion, die eine interoperable und sichere Kommunikation über eine Attestierung ermöglicht und die Verbindung zwischen den zwei oder mehr Systemen unterstützt.
  • Beispiel 49 beinhaltet das Verfahren der Beispiele 47-48 und/oder eines oder mehrerer anderer Beispiele hierin, das weiter umfasst: Aufdecken einer vollständigen Liste von APIs der zwei oder mehr Systeme an Edge-Apps mittels Signalisierung (unterstützt von der edgeXapis-GW-Funktion) der CAPIF-Kernfunktion und der MEC-Plattform.
  • Beispiel 50 beinhaltet das Verfahren der Beispiele 47 bis 49 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Bereitstellen eines interoperablen Edge-Dienstverbrauchs der zwei oder mehr Systeme, einschließlich APIs, die von beiden Systemen aufgedeckt werden.
  • Beispiel 51 beinhaltet das Verfahren der Beispiele 47 bis 50 und/oder einiger anderer Beispiele hierin, das weiter umfasst: Bereitstellen für EASs alternativer Transportprotokolle für den MEC-APIs-Dienstverbrauch.
  • Beispiel 52 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei die Ausführung der Anweisungen durch die Prozessorschaltungsanordnung bewirken soll, dass die Prozessorschaltungsanordnung das Verfahren nach einem der Beispiele 1 bis 51 ausführt. Beispiel 53 beinhaltet ein Computerprogramm, das die Anweisungen des Beispiels 52 umfasst. Beispiel 54 beinhaltet eine Anwendungsprogrammierschnittstelle, die Funktionen, Verfahren, Variablen, Datenstrukturen und/oder Protokolle für das Computerprogramm des Beispiels 53 definiert. Beispiel 55 beinhaltet eine Einrichtung, die eine Schaltungsanordnung umfasst, die mit den Anweisungen des Beispiels 52 geladen ist. Beispiel 56 beinhaltet eine Einrichtung, die eine Schaltungsanordnung umfasst, die dazu betreibbar ist, die Anweisungen des Beispiels 52 auszuführen. Beispiel 57 beinhaltet eine integrierte Schaltung, die die Prozessorschaltungsanordnung des Beispiels 52 und/oder das eine oder die mehreren computerlesbaren Medien des Beispiels 52 umfasst. Beispiel 58 beinhaltet ein Rechensystem, das das eine oder die mehreren computerlesbaren Medien und die Prozessorschaltungsanordnung des Beispiels 52 umfasst. Beispiel 58 beinhaltet eine Einrichtung, die Mittel zum Ausführen der Anweisungen des Beispiels 52 umfasst. Beispiel 60 beinhaltet ein Signal, das als ein Ergebnis des Ausführens der Anweisungen des Beispiels 52 erzeugt wird. Beispiel 61 beinhaltet eine Dateneinheit, die als ein Ergebnis des Ausführens der Anweisungen des Beispiels 52 erzeugt wird. Beispiel 62 beinhaltet die Dateneinheit des Beispiels 56, wobei die Dateneinheit ein Datagramm, ein Netzwerkpaket, ein Datenrahmen, ein Datensegment, eine PDU, eine Dienstdateneinheit, „SDU“, eine Nachricht oder ein Datenbankobjekt ist. Beispiel 63 beinhaltet ein Signal, das mit der Dateneinheit des Beispiels61 oder 62 codiert ist. Beispiel 64 beinhaltet ein elektromagnetisches Signal, das die Anweisungen des Beispiels 52 trägt. Beispiel 65 beinhaltet eine Einrichtung, die Mittel zum Ausführen des Verfahrens nach einem der Beispiele 1 bis 51 umfasst.
  • Eine beispielhafte Umsetzung ist ein Edge-Computing-System, das jeweilige Edge-Verarbeitungsvorrichtungen und Knoten zum Aufrufen oder Ausführen der Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände beinhaltet. Eine andere beispielhafte Umsetzung ist ein Client-Endpunktknoten, der zum Aufrufen oder Ausführen der Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände betreibbar ist. Eine andere beispielhafte Umsetzung ist ein Aggregationsknoten, Netzwerk-Hub-Knoten, Gateway-Knoten oder Kerndatenverarbeitungsknoten, innerhalb oder gekoppelt mit einem Edge-Datenverarbeitungssystem, der zum Aufrufen oder Ausführen der Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände betreibbar ist. Eine andere beispielhafte Umsetzung ist ein Zugangspunkt, eine Basisstation, eine Landstraßenrandeinheit, eine Straßenrandeinheit oder eine Vor-Ort-Einheit, innerhalb oder gekoppelt mit einem Edge-Computing-System, der zum Aufrufen oder Ausführen der Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände betreibbar ist. Eine andere beispielhafte Umsetzung ist ein Edge-Bereitstellungsknoten, ein Dienstorchestrierungsknoten, ein Anwendungsorchestrierungsknoten oder ein Multi-Mandanten-Verwaltungsknoten, innerhalb oder gekoppelt mit einem Edge-Computing-System, der zum Aufrufen oder Ausführen der Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände betreibbar ist.
  • Eine andere beispielhafte Umsetzung ist ein Edge-Knoten, der einen Edge-Bereitstellungsdienst, eine Anwendung oder einen Dienstorchestrierungsdienst, einen Virtuelle-Maschine-Einsatz, einen Container-Einsatz, einen Funktionseinsatz und eine Rechenverwaltung innerhalb oder gekoppelt mit einem Edge-Computing-System betreibt, der betreibbar ist, um die Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände aufzurufen oder auszuführen. Eine andere beispielhafte Umsetzung ist ein Edge-Computing-System, das als ein Edge-Mesh, als ein Edge-Mesh mit fahrzeugseitigem Laden oder mit Mesh-zu-Mesh-Kommunikationen betreibbar ist, das zum Aufrufen oder Ausführen der Operationen der Beispiele XYZ oder anderer hierin beschriebener Gegenstände betreibbar ist. Eine andere beispielhafte Umsetzung ist ein Edge-Computing-System, das Aspekte von Netzwerkfunktionen, Beschleunigungsfunktionen, Beschleunigungs-Hardware, Speicher-Hardware oder Rechen-Hardwareressourcen beinhaltet, die betreibbar sind, um die hierin besprochenen Verwendungsfälle unter Verwenden von Beispielen XYZ oder anderen hierin beschriebenen Gegenständen aufzurufen oder auszuführen. Ein anderes Umsetzungsbeispiel ist ein Edge-Computing-System, das zum Unterstützen von Client-Mobilität, Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Alles (V2X) oder Fahrzeug-zu-Infrastruktur-Szenarien (V2I-Szenarien) angepasst ist und optional gemäß ETSI-MEC-Spezifikationen arbeitet, das zum Aufrufen oder Ausführen der hierin besprochenen Verwendungsfälle unter Verwenden von Beispielen XYZ oder anderer hier beschriebener Gegenstände betreibbar ist. Ein anderes Umsetzungsbeispiel ist ein Edge-Computing-System, das für mobile drahtlose Kommunikationen angepasst ist, einschließlich Konfigurationen gemäß 3GPP-4G/LTE oder 5G-Netzwerkfähigkeiten, das betreibbar ist, um die hierin besprochenen Verwendungsfälle unter Verwenden von Beispielen XYZ oder anderer hierin beschriebener Gegenständen aufzurufen oder auszuführen. Ein anderes Umsetzungsbeispiel ist ein Edge-Computing-System, das zum Betrieb gemäß O-RAN-Spezifikationen angepasst ist und betreibbar ist, um die hierin besprochenen Verwendungsfälle unter Verwenden von Beispielen XYZ oder anderer hier beschriebener Gegenstände aufzurufen oder auszuführen.
  • Beispiel Z01 beinhaltet eine Einrichtung, die Mittel zum Ausführen eines oder mehrerer Elemente eines in einem beliebigen der Beispiele XYZ beschriebenen oder mit diesem in Zusammenhang stehenden Verfahrens oder eines beliebigen anderen hierin beschriebenen Verfahrens oder Prozesses umfasst. Beispiel Z02 beinhaltet ein oder mehrere nichtflüchtige computerlesbare Medien, die Anweisungen umfassen, wobei die Ausführung der Anweisungen von einer elektronischen Vorrichtung betreibbar ist, um zu bewirken, dass die elektronische Vorrichtung ein oder mehrere Elemente eines Verfahrens, das in einem beliebigen der Beispiele XYZ beschrieben ist oder mit diesem in Zusammenhang steht, und/oder eines beliebigen anderen Verfahrens oder Prozesses, das hier beschrieben ist, ausführt. Beispiel Z03 beinhaltet ein Computerprogramm, das Anweisungen umfasst, wobei die Ausführung des Programms durch ein Verarbeitungselement betreibbar ist, um zu bewirken, dass das Verarbeitungselement das Verfahren, die Techniken oder den Prozess, wie in einem beliebigen der Beispiele XYZ beschrieben oder mit diesen in Zusammenhang stehend, und/oder Teilen davon ausführt. Beispiel Z04 beinhaltet eine Einrichtung, die Logik, Module oder Schaltungsanordnungen zum Ausführen eines oder mehrerer Elemente eines Verfahrens, das in einem beliebigen der Beispiele XYZ beschrieben ist oder mit diesem in Zusammenhang steht, und/oder eines beliebigen anderen Verfahrens oder Prozesses, das bzw. der hier beschrieben ist, umfasst. Beispiel Z05 beinhaltet eine Einrichtung, die dazu konfiguriert ist, ein oder mehrere Elemente eines Verfahrens, das in einem beliebigen der Beispiele XYZ beschrieben ist oder damit zusammenhängt, und/oder ein beliebiges anderes Verfahren oder einen beliebigen anderen Prozess, das/der hierin beschrieben ist, auszuführen.
  • Beispiel Z06 beinhaltet ein Verfahren, eine Technik oder einen Prozess, wie in einem beliebigen der Beispiele XYZ und/oder Abschnitten oder Teilen davon beschrieben oder mit diesen in Zusammenhang stehend. Beispiel Z07 beinhaltet eine Einrichtung, die umfasst: Prozessorschaltungsanordnungen und computerlesbare Medien, die Anweisungen umfassen, wobei der eine oder die mehreren Prozessoren konfigurierbar sind, um das Verfahren, die Techniken oder den Prozess, wie in einem beliebigen der Beispiele XYZ beschrieben oder mit diesen in Zusammenhang stehend, und/oder Teilen davon auszuführen. Beispiel Z08 beinhaltet ein Signal, wie in einem beliebigen der Beispiele XYZ beschrieben oder mit diesem in Zusammenhang stehend, und/oder Abschnitten oder Teilen davon. Beispiel Z09 beinhaltet ein Datagramm, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht, wie in einem der Beispiele XYZ oder in Abschnitten oder Teilen davon beschrieben oder damit in Zusammenhang stehend und/oder anderswie in der vorliegenden Offenbarung beschrieben. Beispiel Z10 beinhaltet ein Signal, das mit einem Datagramm, Paket, Frame, Segment, einer PDU oder Nachricht codiert ist, wie in einem der Beispiele XYZ oder Abschnitten oder Teilen davon oder anderswie in der vorliegenden Offenbarung beschrieben oder mit diesen in Zusammenhang steht.
  • Beispiel Z11 beinhaltet ein Signal, das mit Daten codiert ist, wie in einem der Beispiele XYZ oder Abschnitten oder Teilen davon oder anderswie in der vorliegenden Offenbarung beschrieben oder mit diesen in Zusammenhang steht. Beispiel Z12 beinhaltet ein elektromagnetisches Signal, das computerlesbare Anweisungen trägt, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren betreibbar oder konfigurierbar ist, um zu bewirken, dass der eine oder die mehreren Prozessoren ein Verfahren, eine Technik oder einen Prozess, wie in einem beliebigen der Beispiele XYZ oder Teilen davon beschrieben oder damit in Zusammenhang stehend, ausführt. Beispiel Z13 beinhaltet eine API oder Spezifikation, die Funktionen, Verfahren, Variablen, Datenstrukturen, Protokolle usw. definiert, die die Verwendung eines beliebigen der Beispiele XYZ oder Teilen davon definieren oder beinhalten oder anderswie mit einem beliebigen der Beispiele XYZ oder Teilen davon in Zusammenhang stehen. Beispiel Z14 beinhaltet einen MEC-Host (MEC: Multi-Access Edge-Computing), der einen Dienst als Teil einer oder mehrerer MEC-Anwendungen ausführt, die auf einer Virtualisierungsinfrastruktur instanziiert sind, wobei sich der Dienst mit einem beliebigen der Beispiele XYZ oder Teile davon zusammenhängt, und wobei der MEC-Host dazu konfiguriert 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 Z17beinhaltet 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.
  • 4. 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 weiter, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn in dieser Patentschrift verwendet werden, das Vorhandensein aufgeführter Merkmale, von Ganzzahlen, Schritten, Operationen, Elementen und/oder Komponenten spezifiziert, nicht aber das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, von Ganzzahlen, Schritten, Operationen, Elementen, 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 kann die Ausdrücke „bei einer Ausführungsform“ oder „bei einigen Ausführungsformen“ verwenden, die jeweils eine oder mehrere der gleichen oder unterschiedlichen Ausführungsformen betreffen können. Darüber hinaus sind die Begriffe „umfassend“, „beinhaltend“, „aufweisend“ und dergleichen, wie mit Bezug auf die vorliegende Offenbarung verwendet, synonym.
  • Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“ gemeinsam 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, einschließlich über einen Draht oder eine andere Interconnect-Verbindung, durch einen Drahtloskommunikationskanal oder einen Drahtloskommunikationslink und/oder dergleichen miteinander in Kontakt stehen können.
  • Der Begriff „Schaltungsanordnung“ verweist mindestens bei einigen Ausführungsformen auf eine Schaltung oder ein System mehrerer Schaltungen, die dazu konfiguriert ist/sind, eine spezielle Funktion in einer elektronischen Vorrichtung auszuführen. Die Schaltung oder das System von Schaltungen kann Teil einer oder mehrerer Hardwarekomponenten sein oder diese beinhalten, wie etwa eine Logikschaltung, ein Prozessor (gemeinsam genutzt, dediziert oder Gruppe) und/oder ein Speicher (gemeinsam genutzt, dediziert oder als Gruppe), eine ASIC, ein FPGA, eine programmierbare logische Steuervorrichtung (PLC), SoC, SiP, ein Multi-Chipgehäuse (MCP), DSP usw., die dazu konfiguriert sind, die beschriebene Funktionalität bereitzustellen. Zusätzlich kann der Begriff „Schaltungsanordnung“ auch auf eine Kombination eines oder mehrerer Hardwareelemente mit dem Programmcode, der zum Ausführen der Funktionalität dieses Programmcodes verwendet wird, verweisen. Einige Arten von Schaltungen können ein oder mehrere Software- oder Firmware-Programme ausführen, um mindestens etwas der beschriebenen Funktionalität bereitzustellen. Eine derartige Kombination von Hardwareelementen und Programmcode kann als ein spezieller Schaltungstyp bezeichnet werden.
  • Es versteht sich, dass die in dieser Beschreibung beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um insbesondere ihre Umsetzungsunabhängigkeit hervorzuheben. Derartige Komponenten können von einer beliebigen Anzahl von Software- oder Hardwareformen verkörpert werden. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardwareschaltung umgesetzt sein, die angepasste VLSI-Schaltungen (Very-Large-Scale-Integration - VLSI) oder Gate-Arrays, handelsübliche Halbleiter, wie etwa Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen umgesetzt sein, wie in etwa feldprogrammierbaren Gate-Arrays, programmierbarer Array-Logik, programmierbaren Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren umgesetzt sein. Eine identifizierte Komponente oder ein identifiziertes Modul von ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Vorgehensweise oder eine Funktion organisiert sein können. Dennoch müssen die ausführbaren Dateien einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch an einem Ort sein, sondern können disparate Anweisungen umfassen, die an unterschiedlichen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.
  • Tatsächlich kann eine Komponente oder ein Modul ausführbaren Codes eine einzelne Anweisung oder viele Anweisungen sein und kann sogar über mehrere unterschiedliche Codesegmente, über unterschiedliche Programme und über mehrere Speichervorrichtungen oder Verarbeitungssysteme verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie etwa Codeumschreiben und Codeanalyse) auf einem unterschiedlichen Verarbeitungssystem (zum Beispiel in einem Computer in einem Datenzentrum) als dem stattfinden, in dem der Code eingesetzt wird (zum Beispiel in einem Computer, der in einem Sensor oder Roboter eingebettet ist). Ebenso können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht werden und können in einer beliebigen geeigneten Form verkörpert und innerhalb einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz gesammelt werden oder können über unterschiedliche Orte, einschließlich über verschiedene Speichervorrichtungen, verteilt sein und können mindestens 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 zum Ausführen gewünschter Funktionen funktionsfähig sind.
  • Der Begriff „Prozessorschaltungsanordnung“ verweist mindestens bei einigen Ausführungsformen auf, ist Teil davon oder beinhaltet eine Schaltungsanordnung, die in der Lage ist, sequenziell und automatisch eine Folge arithmetischer oder logischer Operationen oder Aufzeichnung, Speichern und/oder Übertragen digitaler Daten auszuführen. Der Begriff „Prozessorschaltungsanordnung“ verweist mindestens bei einigen Ausführungsformen auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische CPU, einen Einzelkernprozessor, einen Doppelkernprozessor, einen Drei-Kern-Prozessor, einen Vier-Kern-Prozessor und/oder eine beliebige andere Vorrichtung, die in der Lage ist, computerausführbare Anweisungen auszuführen oder anderswie zu betreiben, wie etwa Programmcode, Softwaremodule und/oder Funktionsprozesse. Die Begriffe „Anwendungsschaltungsanordnung“ und/oder „Basisbandschaltungsanordnung“ können als Synonyme für „Prozessorschaltungsanordnung“ angesehen und so bezeichnet werden.
  • Der Begriff „Speicher“ und/oder „Speicherschaltungsanordnung“ verweist mindestens bei einigen Ausführungsformen 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 Speichervorrichtungen, optische Speichervorrichtungen und verschiedene andere Medien beinhalten, die in der Lage sind, Anweisungen oder Daten zu speichern, zu enthalten oder zu tragen.
  • Der Begriff „Schnittstellenschaltungsanordnung“ verweist mindestens bei einigen Ausführungsformen auf, ist Teil davon oder beinhaltet eine Schaltungsanordnung, die den Austausch von Informationen zwischen zwei oder mehr Komponenten oder Vorrichtungen ermöglicht. Der Begriff „Schnittstellenschaltungsanordnung“ verweist mindestens bei einigen Ausführungsformen auf eine oder mehrere Hardwareschnittstellen, zum Beispiel Busse, E/A-Schnittstellen, Peripheriekomponentenschnittstellen, Netzwerkschnittstellenkarten und/oder dergleichen.
  • Der Begriff „Element“ verweist mindestens bei einigen Ausführungsformen auf eine Einheit, die bei einem gegebenen Abstraktionsniveau teilbar 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, Steuervorrichtungen, Netzwerkelemente, Module usw. oder Kombinationen davon beinhaltet. Der Begriff „Vorrichtung“ verweist mindestens bei einigen Ausführungsformen auf eine physische Entität, die innerhalb einer anderen physischen Entität in ihrer Nähe eingebettet oder an dieser angebracht ist, mit Fähigkeiten, digitale Informationen von oder zu dieser physischen Entität zu übertragen. Der Begriff „Entität“ verweist mindestens bei einigen Ausführungsformen auf eine getrennte Komponente einer Architektur oder Vorrichtung oder als Nutzlast übertragene Informationen. Der Begriff „Steuerung“ verweist mindestens bei einigen Ausführungsformen auf ein Element oder eine Entität, das/die Fähigkeit aufweist, eine physische Entität zu beeinflussen, wie etwa durch Ändern ihres Zustands oder Bewirken, dass sich die physische Entität bewegt.
  • Der Begriff „Edge-Computing“ umfasst viele Umsetzungen verteilten Rechnens, die Verarbeitungsaktivitäten und -ressourcen (zum Beispiel Berechnung, Speicherung, Beschleunigungsressourcen) in Richtung der „Edge“ des Netzwerks bewegen, in einem Bestreben, Latenz zu reduzieren und den Durchsatz für Endpunktbenutzer (Client-Vorrichtungen, Benutzergeräte usw.) zu erhöhen. Derartige Edge-Computing-Umsetzungen beinhalten typischerweise das Anbieten derartiger 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“ eines Netzwerks, Clusters, einer Domäne, eines Systems oder einer Rechenanordnung, die hier verwendet werden, Gruppen oder Gruppierungen funktioneller verteilter Rechenelemente und daher allgemein nicht mit „Edge“ (Links oder Verbindungen) in Beziehung, wie sie in der Graphentheorie verwendet werden. Spezifische Anordnungen von Edge-Computing-Anwendungen und Diensten, die über Mobilfunknetzwerke (zum Beispiel zellulare und WiFi-Datennetzwerke) zugänglich sind, können als „mobile Edge-Computing“ oder „Multi-Access-Edge-Computing“ bezeichnet werden, was mit dem Akronym „MEC“ referenziert werden kann. Die Verwendung von „MEC“ kann hierin auch auf eine standardisierte Umsetzung verweisen, die von dem European Telecommunications Standards Institute (ETSI) vertrieben wird und als „ETSI-MEC“ bezeichnet wird. Terminologie, die von der ETSI-MEC-Spezifikation verwendet wird, wird hierin im Allgemeinen durch Bezugnahme aufgenommen, es sei denn, eine widersprüchliche Definition oder Verwendung wird hierin bereitgestellt.
  • Der Begriff „Rechenknoten“ oder „Rechenvorrichtung“ verweist mindestens bei einigen Ausführungsformen auf eine identifizierbare Entität, die einen Aspekt von Edge-Rechenoperationen umsetzt, ob es sich nun um einen Teil eines größeren Systems, eine verteilte Sammlung von Systemen oder eine eigenständige Einrichtung handelt. Bei einigen Beispielen kann ein Rechenknoten als „Edge-Knoten“, „Edge-Vorrichtung“, „Edge-System“ bezeichnet werden, ob er nun als ein Client, Server oder eine Zwischenentität in Betrieb ist. Spezifische Umsetzungen eines Rechenknotens können in einen Server, eine Basisstation, ein Gateway, eine Straßenrandeinheit, einer Vor-Ort-Einheit, einer UE oder einer Endverbrauchsvorrichtung oder dergleichen integriert sein.
  • Der Begriff „Computersystem“ verweist mindestens bei einigen Ausführungsformen auf eine beliebige Art von miteinander verbundenen elektronischen Vorrichtungen, Computervorrichtungen oder Komponenten davon. Zusätzlich verweisen die Begriffe „Computersystem“ und/oder „System“ mindestens bei einigen Ausführungsformen auf verschiedene Komponenten eines Computers, die kommunikativ miteinander gekoppelt sind. Darüber hinaus verweist der Begriff „Computersystem“ und/oder „System“ mindestens bei einigen Ausführungsformen auf mehrere Computervorrichtungen und/oder mehrere Computersysteme, die kommunikativ miteinander gekoppelt und dazu konfiguriert sind, Rechen- und/oder Networking-Ressourcen gemeinsam zu nutzen.
  • Der Begriff „Architektur“ verweist mindestens bei einigen Ausführungsformen 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 verweist mindestens bei einigen Ausführungsformen auf eine Computervorrichtung oder ein Computersystem mit Programmcode (zum Beispiel Software oder Firmware), der speziell dazu ausgelegt ist, eine spezifische Rechenressource bereitzustellen. Ein „virtuelles Gerät“ ist ein virtuelles Maschinenbild, das von einer mit einem Hypervisor ausgestatteten Vorrichtung umgesetzt werden soll, die ein Computergerät virtualisiert oder emuliert oder anderswie dazu bestimmt ist, eine spezifische Rechenressource bereitzustellen.
  • Der Begriff „Benutzergerät“ oder „UE“ verweist mindestens bei einigen Ausführungsformen auf eine Vorrichtung mit Funkkommunikationsfähigkeiten und kann einen von Netzwerkressourcen in einem Kommunikationsnetzwerk entfernten Benutzer 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, Remote-Station, Zugriffsagent, Benutzeragent, Empfänger, Funkgerät, umkonfigurierbares Funkgerät, umkonfigurierbare Mobilvorrichtung usw. angesehen und als derartige bezeichnet werden. Darüber hinaus 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“ verweist mindestens bei einigen Ausführungsformen auf eine logische Entität, die eine einzeln adressierbare Instanz einer Medienzugriffssteuerung (MAC) und einer zwischen Schnittstelle einer physischen Schicht (PHY-Schnittstelle) zu dem drahtlosen Medium (WM) ist. Der Begriff „drahtloses Medium“ oder „WM“ verweist mindestens bei einigen Ausführungsformen auf das Medium, das verwendet wird, um die Übertragung von Protokolldateneinheiten (PDUs) zwischen Peer-Physical-Layer-Entitäten (PHY-Entitäten eines drahtlosen lokalen Netzwerks (LAN) umzusetzen).
  • Der Begriff „Netzwerkelement“ verweist mindestens bei einigen Ausführungsformen auf ein physisches oder virtualisiertes Gerät und/oder Infrastruktur, die verwendet werden, um drahtgebundene oder drahtlose Kommunikationsnetzdienste bereitzustellen. Der Begriff „Netzwerkelement“ kann synonym zu und/oder als ein vernetzter Computer, eine Networking-Hardware, ein Netzwerkgerät, ein Netzwerkknoten, ein Router, ein Switch, ein Hub, eine Brücke, eine Funknetzwerksteuerung, eine RAN-Vorrichtung, ein RAN-Knoten, ein Gateway, ein Server, eine virtualisierte VNF, NFVI und/oder dergleichen angesehen werden.
  • Der Begriff „Zugangspunkt“ oder „AP“ verweist mindestens bei einigen Ausführungsformen auf eine Entität, die eine Station (STA) enthält und Zugang zu den Verteilungsdiensten über das drahtlose Medium (WM) für assoziierte STAs bereitstellt. Ein AP umfasst eine STA und eine Verteilungssystemzugangsfunktion (DSAF).
  • Der Begriff „Basisstation“ verweist mindestens bei einigen Ausführungsformen auf ein Netzwerkelement in einem Funkzugangsnetzwerk (RAN), wie etwa einem Mobilkommunikationsnetzwerk der vierten Generation (4G) oder der fünften Generation (5G), das für die Übertragung und den Empfang von Funksignalen in einer oder mehreren Zellen zu oder von einem Benutzergerät (UE) zuständig ist. Eine Basisstation kann eine integrierte Antenne aufweisen oder über Feeder-Kabel mit einem Antennenarray verbunden sein. Eine Basisstation verwendet spezialisierte digitale Signalverarbeitung und Netzwerkfunktions-Hardware. Bei einigen Beispielen kann die Basisstation für Flexibilität, Kosten und Leistungsfähigkeit in mehrere Funktionsblöcke aufgeteilt sein, die in Software arbeiten. Bei einigen Beispielen kann eine Basisstation eine evolved-Node-B (eNB) oder eine Next-Generation-Node-B (gNB) beinhalten. Bei einigen Beispielen kann die Basisstation Rechen-Hardware betreiben oder beinhalten, um als ein Rechenknoten zu arbeiten. In vielen der hierin besprochenen Szenarien kann jedoch ein RAN-Knoten mit einem Zugangspunkt (zum Beispiel Drahtlosnetzwerkzugangspunkt) oder einer anderen Netzwerkzugangs-Hardware ersetzt werden.
  • Der Begriff „E-UTEAN-NodeB“, „eNodeB“ oder „eNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der E-UTRA-Benutzerebenen-Protokollabschlüsse (PDCP/RLC/MAC/PHY) und Steuerebenen-Protokollabschlüsse(RRC-Protokollabschlüsse) zu einem UE bereitstellt und über eine S1-Schnittstelle mit dem Evolved Packet Core (EPC) verbunden ist. Zwei oder mehr eNBs sind mittels einer X2-Schnittstelle miteinander (und/oder mit einem oder mehreren en-gNBs) verbunden.
  • Der Begriff „eNB der nächsten Generation“ oder „ng-eNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der E-UTRA-Benutzerebenen- und Steuerebenen-Protokollabschlüsse zu einem UE bereitstellt und über die NG-Schnittstelle mit dem 5GC verbunden ist. Zwei oder mehr ng-eNBs sind über eine XN-Schnittstelle miteinander (und/oder mit einem oder mehreren gNBs) verbunden.
  • Der Begriff „NodeB der nächsten Generation“, „gNodeB“ oder „gNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der NR-Benutzerebenen- und Steuerebenen-Protokollabschlüsse zu einem UE bereitstellt und über die NG-Schnittstelle mit dem 5GC verbunden ist. Zwei oder mehr gNBs sind über eine XN-Schnittstelle miteinander (und/oder mit einem oder mehreren ng-eNBs) verbunden.
  • Der Begriff „E-UTRA-NR gNB“ oder „en-gNB“ verweist mindestens bei einigen Ausführungsformen auf einen RAN-Knoten, der NR-Benutzerebenen- und Steuerebenen-Protokollabschlüsse gegenüber einem UE bereitstellt und als ein Sekundärknoten in E-UTRA-NR Dual Connectivity-Szenarien (EN-DC-Szenarien) fungiert (siehe zum Beispiel 3GPP TS 37.340 v16.6.0 (2021-07-09)). Zwei oder mehr en-gNBs sind über eine X2-Schnittstelle miteinander (und/oder mit einem oder mehreren eNBs) verbunden.
  • Der Begriff „RAN-Knoten der nächsten Generation“ oder „NG-RAN-Knoten“ verweist mindestens bei einigen Ausführungsformen entweder auf einen gNB oder auf einen ng-eNB.
  • Der Begriff „Zentraleinheit“ oder „CU“ verweist mindestens bei einigen Ausführungsformen auf einen logischen Knoten, der Funkressourcensteuerung (RRC), Dienstdatenanpassungsprotokoll (SDAP) und/oder Paketdatenumwandlungsprotokoll (PDCP) - Protokolle/Schichten eines NG-RAN-Knotens hostet, oder RRC- und PDCP Protokolle des en-gNB, die den Betrieb einer oder mehrerer DUs steuern; eine CU schließt eine F1-Schnittstelle ab, die mit einer DU verbunden ist, und kann mit mehreren DUs verbunden sein.
  • Der Begriff „verteilte Einheit“ oder „DU“ verweist mindestens bei einigen Ausführungsformen auf einen logischen Knoten, der Funkverbindungssteuerung (RLC), Medienzugriffssteuerung (MAC) und physische (PHY) Schichten des NG-RAN-Knotens oder en-gNB hostet, und sein Betrieb wird teilweise von einer CU gesteuert; eine DU unterstützt eine oder mehrere Zellen, und eine Zelle wird von nur einer DU unterstützt; und eine DU schließt die F1-Schnittstelle, die mit einer CU verbunden ist, ab.
  • Der Begriff „Residential Gateway“ oder „RG“ verweist wenigstens bei einigen Ausführungsformen auf eine Vorrichtung, die zum Beispiel Sprache, Daten, Rundfunkvideo, Video auf Abruf zu anderen Vorrichtungen in Kundenorten bereitstellt. Der Begriff „Wireline-5G-Zugangsnetz“ oder „W-5GAN“ verweist mindestens bei einigen Ausführungsformen auf ein Wireline AN, das über N2 und N3 Referenzpunkte mit einem 5GC verbunden ist. Das W-5GAN kann sowohl ein W-5GBAN als auch ein W-5GCAN sein. Der Begriff „Wireline 5G Cable Access Network“ oder „W-5GCAN“ verweist mindestens bei einigen Ausführungsformen auf ein Zugangsnetz, das in/von CableLabs definiert ist. Der Begriff „Wireline BBF Access Network“ oder „W-5GBAN“ verweist mindestens bei einigen Ausführungsformen auf ein Zugangsnetz, das in/von dem Broadband Forum (BBF) definiert ist. Der Begriff „Wireline Access Gateway Function“ oder „W-AGF“ verweist mindestens bei einigen Ausführungsformen auf eine Netzwerkfunktion in W-5GAN, die Konnektivität zu einem 3GPP-5G-Kernnetzwerk (5GC) mit 5G-RG und/oder FN-RG bereitstellt. Der Begriff „5G-RG“ verweist mindestens bei einigen Ausführungsformen auf ein RG, das in der Lage ist, sich mit einem 5GC zu verbinden, das die Rolle eines Benutzergeräts in Bezug auf das 5GC innehat; es unterstützt ein sicheres Element und tauscht N1-Signalisierung mit dem 5GC aus. Bei dem 5G-RG kann es sich entweder um ein 5G-BRG oder 5G-CRG handeln.
  • Der Begriff „Zentrale“ (oder CO) gibt einen Aggregationspunkt für eine Telekommunikationsinfrastruktur innerhalb eines zugänglichen oder definierten geografischen Bereichs an, in dem Telekommunikationsdienstanbieter traditionell Vermittlungseinrichtungen für einen oder mehrere Typen von Zugangsnetzwerken lokalisiert haben. Das CO kann physisch gestaltet sein, um Telekommunikationsinfrastrukturgeräte oder Rechen-, Datenspeicherungs- und Netzwerkressourcen aufzunehmen. Das CO muss jedoch kein designierter Ort eines Telekommunikationsanbieters sein. Das CO kann eine beliebige Anzahl von Rechenvorrichtungen für Edge-Anwendungen und Dienste oder sogar lokale Umsetzungen von Cloud-ähnlichen Diensten hosten.
  • Der Begriff „Cloud-Computing“ oder „Cloud“ verweist mindestens bei einigen Ausführungsformen auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Pool von gemeinsam nutzbaren Rechenressourcen mit Selbstbedienungsbereitstellung und -Verwaltung bei Bedarf und ohne aktives Management 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 Verwenden einer definierten Schnittstelle (zum Beispiel einer API oder dergleichen) aufgerufen werden. Der Begriff „Rechenressource“ oder einfach „Ressource“ verweist mindestens bei einigen Ausführungsformen auf eine beliebige physische oder virtuelle Komponente oder Verwendung derartiger Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Ressourcen umfassen Nutzung für einen Zeitraum von/Zugriff auf Server, Prozessor(en), Datenspeichergeräte, Arbeitsspeichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, (periphere) Eingabe-/Ausgabevorrichtungen, mechanische Vorrichtungen, Netzwerkverbindungen (zum Beispiel Kanäle/Links, Ports, Netzwerkbuchsen usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen. Eine „Hardwareressource“ kann auf Rechen-, Speicher- und/oder Netzwerkressourcen verweisen, die von einem oder mehreren physischen Hardwareelementen bereitgestellt werden. Eine „virtualisierte Ressource“ kann auf Rechen-, Speicher- und/oder Netzwerkressourcen verweisen, die von einer Virtualisierungsinfrastruktur für eine Anwendung, eine Vorrichtung, ein System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann auf Ressourcen verweisen, auf die Computervorrichtungen/Systeme über ein Kommunikationsnetzwerk zugreifen können. Der Begriff Systemressourcen kann auf jede Art gemeinsam genutzter Entitäten zum Bereitstellen von Diensten verweisen und Rechen- und/oder Netzwerkressourcen umfassen. Systemressourcen können als ein Satz kohärenter Funktionen, Netzwerkdatenobjekte oder Dienste betrachtet werden, auf die von einem Server zugegriffen werden kann, wenn sich derartige Systemressourcen auf einem einzigen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind. Zusätzlich oder alternativ verweist der Begriff „Ressource“ mindestens bei einigen Ausführungsformen auf ein Objekt oder eine Komponente der API, auf die die Operationen einwirken.
  • Der Begriff „Arbeitslast“ verweist mindestens bei einigen Ausführungsformen auf eine Menge an Arbeit, die von einem Computersystem, einer Vorrichtung, einer Entität usw. während eines Zeitraums oder zu einem bestimmten Zeitpunkt ausgeführt wird. Eine Arbeitslast kann als ein Benchmark dargestellt werden, wie etwa eine Reaktionszeit, ein Durchsatz (zum Beispiel wie viel Arbeit über einen Zeitraum ausgeführt wird) und/oder dergleichen. Zusätzlich oder alternativ kann die Arbeitslast als eine Speicherarbeitslast (zum Beispiel eine Menge an Speicherplatz, der zur Programmausführung benötigt wird, um temporäre oder permanente Daten zu speichern und Zwischenberechnungen auszuführen), eine Prozessorarbeitslast (zum Beispiel eine Anzahl von Anweisungen, die von einem Prozessor während einer gegebenen Zeitspanne oder zu einem bestimmten Zeitpunkt ausgeführt werden), eine E/A-Arbeitslast (zum Beispiel eine Anzahl von Ein- und Ausgaben oder Systemzugriffen während eines gegebenen Zeitraums oder zu einem bestimmten Zeitpunkt), Datenbankarbeitslasten (zum Beispiel eine Anzahl von Datenbankabfragen während eines Zeitraums), eine netzwerkbezogene Arbeitslast (zum Beispiel eine Anzahl von Netzwerkanbindungen, eine Anzahl von Mobilitätsaktualisierungen, eine Anzahl von Funkverbindungsfehlern, eine Anzahl von Handovers, eine Menge von über eine Luftschnittstelle 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 oben genannten Arbeitslasttypen basieren können.
  • Der Begriff „Cloud-Dienstanbieter“ (oder CSP) gibt eine Organisation an, die typischerweise großformatige „Cloud“-Ressourcen betreibt, die aus zentralisierten, regionalen und Edge-Datenzentren (zum Beispiel wie im Kontext der öffentlichen Cloud verwendet) bestehen. Bei anderen Beispielen kann ein CSP auch als Cloud Service Operator (CSO) bezeichnet werden. Verweise auf „Cloud-Computing“ verweisen allgemein auf Rechenressourcen und -dienste, die von einem CSP oder einem CSO an entfernten Orten mit mindestens etwas erhöhter Latenz, Entfernung oder Einschränkungen im Vergleich zum Edge-Computing angeboten werden.
  • Der Begriff „Datenzentrum“ verweist mindestens bei einigen Ausführungsformen auf eine zweckentworfene Struktur, die mehrere Hochleistungsrechen- und Datenspeicherungsknoten beherbergen soll, so dass eine große Menge an Rechen-, Datenspeicherungs- und Netzwerkressourcen an einem einzigen Ort vorhanden ist. Das bringt oft spezialisierte Rack- und Gehäusesysteme, geeignete Heiz-, Kühl-, Lüftungs-, Sicherheits-, Brandschutz- und Stromversorgungssysteme mit sich. Der Begriff kann bei einigen Zusammenhängen auch auf einen Rechen- und Datenspeicherknoten verweisen. Ein Datenzentrum kann im Maßstab zwischen einem zentralisierten oder Cloud-Datenzentrum (zum Beispiel das größte), regionalen Datenzentrum und Edge-Datenzentrum (zum Beispiel das kleinste) variieren.
  • Der Begriff „Zugangs-Edge-Schicht“ gibt die Unterschicht der Infrastruktur-Edge an, die dem Endbenutzer oder Gerät am nächsten ist. Eine derartige Schicht kann zum Beispiel von einem Edge-Datenzentrum erfüllt werden, das an einem zellularen Netzwerkort eingesetzt wird. Die Zugriffs-Edge-Schicht fungiert als die Frontlinie der Infrastruktur-Edge und kann sich mit einer Aggregations-Edge-Schicht verbinden, die in der Hierarchie höher liegt.
  • Der Begriff „Aggregations-Edge-Schicht“ gibt die Schicht der Infrastruktur-Edge einen Sprung von der Zugriffs-Edge-Schicht entfernt. Diese Schicht kann entweder als ein Datenzentrum mittlerer Größe an einem einzigen Ort existieren oder kann aus mehreren miteinander verbundenen Mikrodatenzentren gebildet sein, um eine hierarchische Topologie mit der Zugangs-Edge zu bilden, um eine größere Zusammenarbeit, eine größere Arbeitslastausfallsicherheit und Skalierbarkeit als die Zugangs-Edge allein zu erlauben.
  • Der Begriff „Netzwerkfunktionsvirtualisierung“ (oder NFV) gibt die Migration von NFs eingebetteter Dienste innerhalb proprietärer Hardwaregeräte zu softwarebasierten virtualisierten NFs (oder VNFs) an, die auf standardisierten CPUs (zum Beispiel innerhalb standardmäßiger x86 ®- und ARM®-Server, wie etwa jene einschließlich Intel®-Xeon™- oder AMD®-Epyc™- oder Opteron™-Prozessoren) unter Verwenden von Industriestandardvirtualisierungs- und Cloud-Rechentechnologien. Zusätzlich oder alternativ werden NFV-Verarbeitung und Datenspeicherung an den Edge-Datenzentren stattfinden, die direkt mit dem lokalen zellularen Ort, innerhalb der Infrastruktur-Edge, verbunden sind.
  • Der Begriff „virtualisierte NF“ (oder VNF) gibt eine softwarebasierte NF an, die auf Multifunktions- Mehrzweck-Rechenressourcen (zum Beispiel x86, ARM-Verarbeitungsarchitektur) arbeitet, die von NFV an Stelle dedizierter physischer Ausrüstung verwendet werden. Zusätzlich oder alternativ werden mehrere VNFs in einem Edge-Datenzentrum an der Infrastruktur-Edge arbeiten.
  • Der Begriff „Edge-Computing-Knoten“ verweist mindestens bei einigen Ausführungsformen auf eine reale, logische oder virtualisierte Umsetzung eines rechenfähigen Elements in Form einer Vorrichtung, eines Gateways, einer Brücke, eines Systems oder eines Subsystems, einer Komponente, ob in einem Server-, Client-, Endpunkt- oder Peer-Modus gearbeitet wird und ob sich an einer „Edge“ eines Netzwerks oder an einem verbundenen Ort weiter innerhalb des Netzwerks befindet. Verweise auf einen „Knoten“, die hierin verwendet werden, sind im Allgemeinen mit „Vorrichtung“, „Komponente“ und „Subsystem“ austauschbar; Verweise auf ein „Edge-Computing-System“ verweisen jedoch im Allgemeinen auf eine verteilte Architektur, Organisation oder Sammlung mehrerer Knoten und Vorrichtungen, die organisiert ist, um einen gewissen Aspekt von Diensten oder Ressourcen in einer Edge-Computing-Umgebung zu erreichen oder anzubieten.
  • Der Begriff „Cluster“ verweist mindestens bei einigen Ausführungsformen auf einen Satz oder eine Gruppierung von Entitäten als Teil eines Edge-Computing-Systems (oder von Edge-Computing-Systemen) in der Form physischer Entitäten (zum Beispiel unterschiedlicher Rechensysteme, Netzwerke oder Netzwerkgruppe), logischer Entitäten (zum Beispiel Anwendungen, Funktionen, Sicherheitskonstrukten, Containern) und dergleichen. An einigen Stellen wird ein „Cluster“ auch als eine „Gruppe“ oder eine „Domäne“ bezeichnet. Die Mitgliedschaft an einem Cluster kann basierend auf Bedingungen oder Funktionen modifiziert oder beeinflusst werden, einschließlich aus dynamischer oder eigenschaftsbasierter Mitgliedschaft, aus Netzwerk- oder Systemverwaltungsszenarien oder aus verschiedenen unten besprochenen beispielhaften Techniken, die eine Entität in einem Cluster hinzufügen, modifizieren oder entfernen können. Cluster können auch mehrere Schichten, Ebenen oder Eigenschaften beinhalten oder damit assoziiert sein, einschließlich Variationen von Sicherheitsmerkmalen und Ergebnissen basierend auf derartigen Schichten, Ebenen oder Eigenschaften.
  • Der Begriff „Funktechnologie“ verweist mindestens bei einigen Ausführungsformen auf eine Technologie zum drahtlosen Senden und/oder Empfangen elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugangstechnologie“ oder „RAT“ verweist mindestens bei einigen Ausführungsformen auf die Technologie, die für die zugrunde liegende physische Verbindung mit einem funkbasierten Kommunikationsnetzwerk verwendet wird. Der „RAT-Typ“ identifiziert die Übertragungstechnik, die in einem Zugangsnetzwerk verwendet wird, zum Beispiel New Radio (NR), Schmalband-IoT (NB-IOT), Untrustetd-Non-3GPP, Trusted-Non-3GPP, Trusted-IEEE 802.11, Non-3GPP-Zugang, Wireline, Wireline-Kabel, Wireline-Broadband-Forum (wireline-BBF) usw.
  • Der Begriff „V2X“ verweist mindestens bei einigen Ausführungsformen auf Fahrzeug-zu-Fahrzeug-Kommunikationen (V2V), Fahrzeug-zu-Infrastruktur (V2I), Infrastruktur zu Fahrzeug (I2V), Fahrzeug-zu-Netzwerk (V2N) und/oder Netzwerk-zu-Fahrzeug (N2V) und assoziierte Funkzugangstechnologien.
  • Der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) verweist mindestens bei einigen Ausführungsformen auf einen Satz standardisierter Regeln oder Anweisungen, die von einer Kommunikationsvorrichtung und/oder einem Kommunikationssystem umgesetzt werden, um mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, einschließlich Anweisungen zum Packen/Entpacken von Daten, Modulieren/Demodulieren von Signalen, Umsetzen von Protokollstapeln und/oder dergleichen. Beispiele für Drahtloskommunikationsprotokolle beinhalten eine Global System for Mobile Communications-Funkkommunikationstechnologie (GSM-Funkkommunikationstechnologie), eine GPRS-Funkkommunikationstechnologie (General Packet Radio Service-Funkkommunikationstechnologie), eine Edge-Funkkommunikationstechnologie (Enhanced Data Rates for GSM Evolution-Funkkommunikationstechnologie), und/oder Third Generation Partner HIP Project--Funkkommunikationstechnologie (3GPP-Funkkommunikationstechnologie), die zum Beispiel 3GPP fünfter Generation (5G) oder New Radio (NR), Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), Long Term Evolution (LTE), LTE-Advanced (LTE Advanced), LTE-EXTRA, LTE-A Pro, cdmaOne (2 G), Code Division Multiple Access 2000 (CDMA 2000), Cellular Digital Packet Data (CDPD), Mobitex, Circuit Switched Data (CSD), High Speed CSD (HSCSD), Wideband Code Division Multiplex Multipe Access (W-CDM), High Speed Packet Access (HSPA), HSPA Plus (HSPA+), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), LTE LAA, MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UTRA (E-UTRA), Evolution-Data Optimized oder Evolution-Data Only (EV-DO), Advanced Mobile Phone System (AMPS), Digital AMPS (D-AMPS), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Pushto-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), Cellular Digital Packet Data (CDPD), DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Personal Handy Phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), auch als 3GPP-Generic Access Network oder GAN-STANDARD bezeichnet), Bluetooth ®, Bluetooth Low Energy (BLE), IEEE 802.15.4 basierte Protokolle (zum Beispiel IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread, 802.11a usw.) WiFi-direct, ANT/ANT+, ZigBee, Z-Wave, 3GPP-Device-to-Device (D2D) oder Proximity Services (ProSe), Universal Plug and Play (UPnP), Low-Power Wide-Area-Network (LPWAN), Long Range Wide Area Network (LoRA) oder LoRaWAN™ entwickelt von Semtech und LoRa Alliance, Digital Enhanced Cordless Telecommunications (DECT), DECT Ultra Low Energy (DECT ULE), DECT-2020, Sigfox, Wireless Gigabit Alliance (WiGig) Standard, Worldwide Interoperability for Microwave Access (WiMAX), allgemein mmWave Standards (zum Beispiel drahtlose Systeme, die bei 10 bis -300 GHz und darüber arbeiten, wie etwa WiGig, IEEE 802.11ad, IEEE 802.11ay usw.), V2X-Kommunikation einschließlich C-V2X, WAVE, 802.11bd, Dedicated Short Range Communications (DSRC), Intelligent-Transport-Systems (ITS) einschließlich der europäischen ITS-G5, ITS-G5B, ITS-G5C usw. Ultra High Frequency (UHF) -Kommunikation, Very High Frequency (UHF) -Kommunikation. Zusätzlich zu den oben aufgelisteten Standards kann eine beliebige Anzahl von Satelliten-Uplink-Technologien für Zwecke der vorliegenden Offenbarung verwendet werden, einschließlich zum Beispiel Funkgeräten, die unter anderem mit Standards konform sind, die von der International Telecommunication Union (ITU) oder der ETSI ausgegeben werden. Die hierin bereitgestellten Beispiele werden somit derart verstanden, dass sie auf verschiedene andere Kommunikationstechnologien anwendbar sind, die sowohl existieren als auch noch nicht formuliert sind.
  • Der Begriff „Kanal“ verweist mindestens bei einigen Ausführungsformen auf ein beliebiges Übertragungsmedium, sei es konkret oder nicht, das verwendet wird, um Daten oder einen Datenstrom zu kommunizieren. Der Begriff „Kanal“ kann synonym zu und/oder gleichbedeutend sein mit „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“ , „Datenübertragungskanal“, „Zugriffskanal“, „Datenzugriffskanal“, „Link“, „Datenlink“, „Träger“, „Hochfrequenzträger“ und/oder jedem anderen ähnlichen Begriff, der einen Pfad oder ein Medium bezeichnet, über den/das Daten kommuniziert werden. Zusätzlich verweist der Begriff „Link“ mindestens bei einigen Ausführungsformen auf eine Verbindung zwischen zwei Vorrichtungen durch eine RAT zum Zweck des Übertragens und Empfangens von Informationen.
  • Der Begriff „lokalisiertes Netzwerk“, wie hierin verwendet, kann auf ein lokales Netzwerk verweisen, das eine begrenzte Anzahl verbundener Fahrzeugen in einen bestimmten Bereich oder einer bestimmten Region abdeckt. Der Begriff „verteiltes Rechnen“, wie hierin verwendet, kann auf Rechenressourcen verweisen, die geografisch in der Nähe von Abschlüssen eines oder mehrerer lokalisierter Netzwerke verteilt sind. Der Begriff „lokale Datenintegrationsplattform“, wie hierin verwendet, kann auf eine Plattform, eine Vorrichtung, ein System, ein Netzwerk oder Element(e) verweisen, die lokale Daten durch Nutzen einer Kombination eines oder mehrerer lokalisierter Netzwerke und verteilter Berechnung integrieren.
  • Der Begriff „Dienstqualität“ oder „QoS“ verweist mindestens bei einigen Ausführungsformen auf eine Beschreibung oder Messung der Gesamtleistung eines Dienstes (zum Beispiel Telefonie und/oder zellularer Dienst, Netzwerkdienst, Drahtloskommunikations-/Konnektivitätsdienst, Cloud-Rechendienst usw.). In einigen Fällen kann die QoS aus der Perspektive der Benutzer dieses Dienstes beschrieben oder gemessen werden, und somit kann QoS der kollektive Effekt der Dienstleistungsfähigkeit sein, die den Grad der Zufriedenheit eines Benutzers dieses Dienstes bestimmen. In anderen Fällen verweist QoS mindestens bei einigen Ausführungsformen auf Verkehrspriorisierungs- und Ressourcenreservierungssteuermechanismen an Stelle der erreichten Wahrnehmung der Dienstqualität. In diesen Fällen ist QoS die Fähigkeit, unterschiedlichen Anwendungen, Benutzern oder Flüssen unterschiedliche Prioritäten bereitzustellen oder einem Fluss ein bestimmtes Leistungsniveau 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 die hierin besprochenen.
  • Die Begriffe „Strahlformung“ und „Strahllenkung“ verweisen mindestens bei einigen Ausführungsformen auf einen räumlichen Filtermechanismus, der an einem Sender (Tx) verwendet wird, um die Empfangssignalleistung, das Signal-Rauschverhältnis (SNR) oder irgendeine andere Signalisierungsmetrik an einem beabsichtigten Empfänger (Rx) zu verbessern. Der Begriff „Strahlformer“ verweist mindestens bei einigen Ausführungsformen auf eine STA, die eine PDU der physischen Schicht (PPDU) unter Verwenden einer Strahlformungssteuermatrix überträgt. Der Begriff „Strahlformungssteuermatrix“ verweist mindestens bei einigen Ausführungsformen auf eine Matrix, die unter Verwenden von Kenntnis des Kanals zwischen einer Tx und einer beabsichtigten Rx bestimmt wird, die von Raum-Zeit-Strömen zu Übertragungsantennen mit dem Ziel abbildet, die Signalleistung, SNR, und/oder einige anderen Signalisierungsmetriken bei der beabsichtigten Rx zu verbessern.
  • Der Begriff „Basisdienstsatz“ oder „BSS“ verweist mindestens bei einigen Ausführungsformen auf einen Satz von STAs, die sich erfolgreich unter Verwenden der JOIN-Dienst-Primitive synchronisiert haben, und eine STA, die START-Primitive verwendet hat. Alternativ dazu spezifiziert ein Satz von STAs, die das START-Primitiv verwendet haben, übereinstimmende Mesh-Pofile, wobei die Übereinstimmung der Mesh-Profile über die Scanvorgehensweise verifiziert wurde. Die Mitgliedschaft bei einem BSS impliziert nicht, dass eine drahtlose Kommunikation mit allen anderen Mitgliedern des BSS möglich ist.
  • Der Begriff „Koordinationsfunktion“ verweist mindestens bei einigen Ausführungsformen auf eine logische Funktion, die bestimmt, wann eine STA PDUs über eine WM übertragen darf. Der Begriff „verteilte Koordinationsfunktion“ oder „DCF“ verweist mindestens bei einigen Ausführungsformen auf eine Klasse von Koordinationsfunktion(en), bei der in jeder STA eines Basic Service Set (BSS) immer dann dieselbe Koordinationsfunktionslogik aktiv ist, wenn das Netzwerk in Betrieb ist. Der Begriff „Verteilungsdienst“ verweist mindestens bei einigen Ausführungsformen auf einen Dienst, der unter Verwenden von Assoziationsinformationen Media Access Control-Diensttupel (MAC-Diensttupel) innerhalb eines Verteilungssystems (DS) liefert. Der Begriff „Verteilungssystem“ oder „DS“ verweist mindestens bei einigen Ausführungsformen auf ein System, das verwendet wird, um einen Satz von Basic Service Sets (BSS) und integrierten lokalen Netzwerken (LANs) miteinander zu verbinden, um ein erweitertes Service Set (ESS) zu erzeugen.
  • Der Begriff „Clear Channel Assessment-Funktionen (CCA-Funktion“ verweist mindestens bei einigen Ausführungsformen auf eine logische Funktion in der physischen Schicht (PHY), die den aktuellen Nutzungszustand einer WM bestimmt.
  • Die Begriffe „Instanziieren“, „Instantiierung“ und dergleichen verweisen mindestens bei einigen Ausführungsformen auf die Erzeugung einer Instanz. Eine „Instanz“ verweist mindestens bei einigen Ausführungsformen auch auf ein konkretes Auftreten eines Objekts, das zum Beispiel während der Ausführung von Programmcode auftreten kann. Der Begriff „Informationselement“ verweist mindestens bei einigen Ausführungsformen auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff „Feld“ verweist mindestens bei einigen Ausführungsformen auf individuelle Inhalte eines Informationselements oder eines Datenelements, das Inhalt enthält. Der Begriff „Datenbankobjekt“, „Datenstruktur“ oder dergleichen kann auf jede Darstellung von Informationen verweisen, 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-Umsetzungen und/oder dergleichen umfassen. Der Begriff „Datenelement“ oder „DE“ verweist mindestens bei einigen Ausführungsformen auf einen Datentyp, der ein einziges Datum enthält. Der Begriff „Datenrahmen“ oder „DF“verweist mindestens bei einigen Ausführungsformen auf einen Datentyp, der mehr als ein Datenelement in einer vordefinierten Reihenfolge enthält.
  • Der Begriff „Datagramm“ verweist mindestens bei einigen Ausführungsformen auf eine Basisübertragungseinheit, die mit einem paketvermittelten Netzwerk assoziiert ist; ein Datagramm kann strukturiert sein, um Kopf- und Nutzdatenabschnitte aufzuweisen. Der Begriff „Datagramm“ kann mindestens bei einigen Ausführungsformen als „Dateneinheit“ oder dergleichen bezeichnet werden.
  • Der Begriff „Subrahmen“ verweist mindestens bei einigen Ausführungsformen auf ein Zeitintervall, in dem ein Signal signalisiert wird. Bei einigen Umsetzungen ist ein Subrahmen gleich 1 Millisekunde (ms). Der Begriff „Zeitschlitz“ verweist mindestens bei einigen Ausführungsformen auf ein ganzzahliges Vielfaches aufeinanderfolgender Subrahmen. Der Begriff „Superrahmen“ verweist mindestens bei einigen Ausführungsformen auf ein Zeitintervall, das zwei Zeitschlitze umfasst.
  • Der Begriff „Interoperabilität“ verweist mindestens bei einigen Ausführungsformen auf die Fähigkeit von STAs, die ein Kommunikationssystem oder RAT nutzen, mit anderen STAs zu kommunizieren, die ein anderes Kommunikationssystem oder eine andere RAT nutzen. Der Begriff „Koexistenz“ verweist mindestens bei einigen Ausführungsformen auf das Teilen oder Zuordnen von Hochfrequenzressourcen unter STAs, die entweder Kommunikationssystem oder RAT verwenden.
  • Der Begriff „Zuverlässigkeit“ verweist mindestens bei einigen Ausführungsformen auf die Fähigkeit einer computerbezogenen Komponente (zum Beispiel Software, Hardware oder Netzwerkelement/Entität), konsistent eine gewünschte Funktion auszuführen und/oder gemäß einer Spezifikation zu arbeiten. Zuverlässigkeit im Kontext von Netzwerkkommunikationen (zum Beispiel „Netzwerkzuverlässigkeit“) kann auf die Fähigkeit eines Netzwerks zum Ausführen von Kommunikation verweisen. Netzwerkzuverlässigkeit kann auch die (oder ein Maß der) Wahrscheinlichkeit sein, dass eine spezifizierte Datenmenge von einer Quelle an ein Ziel (oder einer Senke) übermittelt wird.
  • Der Begriff „Benutzer“ im Kontext umkonfigurierbarer Funkgeräte/-Systeme verweist mindestens bei einigen Ausführungsformen auf eine abstrakte Darstellung einer beliebigen Instanz, die Befehlsanforderungen (zum Beispiel unter Verwenden der Dienste) an den Multifunkcomputer ausgibt. Drei Arten von Benutzern werden basierend auf der Art der verwendeten Dienste unterschieden: Administrator für Multifunkverwaltungsebene, Mobilitätsrichtlinienmanager für Steuerungsebene und Networking-Stapel für Benutzerebene.
  • Der Begriff „Nutzungsfall“ verweist mindestens bei einigen Ausführungsformen auf eine Beschreibung eines Systems aus der Perspektive eines Benutzers. Anwendungsfälle behandeln mitunter ein System als eine Blackbox, und die Interaktionen mit dem System, einschließlich Systemantworten, werden als von außerhalb des Systems wahrgenommen. Nutzungsfälle vermeiden typischerweise technischen Jargon und bevorzugen stattdessen die Sprache des Endnutzers oder Domänenfachmanns.
  • Der Begriff „Qualität“ verweist mindestens bei einigen Ausführungsformen auf eine Eigenschaft, ein Zeichen, ein Attribut oder ein Merkmal als etwas Positives oder Negatives und/oder einen Vortrefflichkeitsgrad davon. Zusätzlich oder alternativ verweist der Begriff „Qualität“ mindestens bei einigen Ausführungsformen im Kontext von Datenverarbeitungssystemen auf einen Zustand qualitativer und/oder quantitativer Aspekte von Daten, Prozessen und/oder einigen anderen Aspekten von Datenverarbeitungssystemen.
  • Der Begriff „Anwendung“ kann auf ein Computerprogramm verweisen, das dazu ausgelegt ist, eine andere spezifische Aufgabe als eine, die sich auf den Betrieb des Computers selbst bezieht, auszuführen. Zusätzlich oder alternativ kann sich der Begriff „Anwendung“ auf eine vollständige und einsetzbare Paketumgebung beziehen, um eine gewisse Funktion in einer Betriebsumgebung zu erreichen. 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“ verweist mindestens bei einigen Ausführungsformen auf die Verwendung von Computersystemen zur Optimierung eines Leistungskriteriums anhand beispielhafter (Trainings-) Daten und/oder vergangener Erfahrung. Bei ML werden Algorithmen zur Ausführung bestimmter Aufgabe(en) verwendet, ohne explizite Anweisungen zur Ausführung der bestimmten Aufgabe(en) zu verwenden, sondern stattdessen auf erlernte Muster und/oder Inferenzen angewiesen. ML verwendet Statistiken, um (ein) mathematische(s) Modell(e) aufzubauen (auch als „ML-Modelle“ oder einfach „Modelle“ bezeichnet), um Vorhersagen oder Entscheidungen basierend auf Musterdaten (zum Beispiel Trainingsdaten) zu treffen. Das Modell ist derart definiert, dass es einen Satz von Parametern aufweist, und Lernen ist die Ausführung eines Computerprogramms zum Optimieren der Parameter des Modells unter Verwenden der Trainingsdaten oder vergangener Erfahrung. Das trainierte Modell kann ein prädiktives Modell, das Vorhersagen basierend auf einem Eingabedatensatz trifft, ein beschreibendes Modell, das Wissen aus einem Eingabedatensatz gewinnt, oder sowohl prädiktiv als auch beschreibend sein. Sobald das Modell gelernt (trainiert) ist, kann es verwendet werden, um Rückschlüsse zu machen (zum Beispiel Vorhersagen). ML-Algorithmen führen einen Trainingsprozess an einem Trainingsdatensatz aus, um ein zugrunde liegendes ML-Modell zu schätzen. Ein ML-Algorithmus ist ein Computerprogramm, das aus Erfahrung bezüglich einiger Aufgabe(n) und einiger Leistungsmessung(en)/Metrik(en) lernt, und ein ML-Modell ist ein Objekt oder eine Datenstruktur, das/die erzeugt wird, nachdem ein ML-Algorithmus mit Trainingsdaten trainiert wurde. Mit anderen Worten kann der Begriff „ML-Modell“ oder „Modell“ die Ausgabe eines ML-Algorithmus beschreiben, der mit Trainingsdaten trainiert wird. Nach dem Training kann ein ML-Modell verwendet werden, um Vorhersagen über neue Datensätze zu treffen. Zusätzlich können separat trainierte AI/ML-Modelle während der Inferenz- oder Prognoseerzeugung in einer AI/ML-Pipeline miteinander verkettet werden. Obwohl der Begriff „ML-Algorithmus“ mindestens bei einigen Ausführungsformen auf unterschiedliche Konzepte als den Begriff „ML-Modell“ verweist, können diese Begriffe austauschbar für die Zwecke der vorliegenden Offenbarung verwendet werden. ML-Techniken fallen im Allgemeinen in die folgenden Haupttypen von Lernproblemkategorien: überwachtes Lernen, unüberwachtes Lernen und verstärkendes Lernen.
  • Der Begriff „überwachtes Lernen“ verweist mindestens bei einigen Ausführungsformen auf eine ML-Technik, die darauf abzielt, eine Funktion zu lernen oder ein ML-Modell zu erzeugen, das bei einem bezeichneten Datensatz eine Ausgabe erzeugt. Überwachte Lernalgorithmen bauen Modelle aus einem Datensatz auf, der sowohl die Eingaben als auch die gewünschten Ausgaben enthält. Überwachtes Lernen beinhaltet zum Beispiel Lernen einer Funktion oder eines Modells, das eine Eingabe auf eine Ausgabe basierend auf beispielhaften Eingabe-Ausgabe-Paaren oder irgendeiner anderen Form bezeichnete Trainingsdaten einschließlich eines Satzes von Trainingsbeispielen abbildet. Jedes Eingabe-Ausgabe-Paar beinhaltet ein Eingabeobjekt (zum Beispiel einen Vektor) und ein gewünschtes Ausgabeobjekt oder einen gewünschten Ausgabewert (als ein „Überwachungssignal“ bezeichnet). Überwachtes Lernen kann in Klassifikationsalgorithmen, Regressionsalgorithmen und instanzbasierte Algorithmen gruppiert werden.
  • Der Begriff „Klassifikation“ im Zusammenhang mit ML kann auf eine ML-TECHNIK verweisen, um die Klassen zu bestimmen, zu denen verschiedene Datenpunkte gehören. Hier kann der Begriff „Klasse“ oder „Klassen“ auf Kategorien verweisen mitunter als „Ziele“ oder „Bezeichnungen“ bezeichnet. Eine Klassifizierung wird verwendet, wenn die Ausgaben auf einen begrenzten Satz quantifizierbarer Eigenschaften beschränkt sind. Klassifikationsalgorithmen können eine individuelle (Daten-) Instanz beschreiben, deren Kategorie unter Verwenden eines Merkmalvektors vorhergesagt werden soll. Als ein Beispiel kann, wenn die Instanz eine Sammlung (Korpus) von Text beinhaltet, jedes Merkmal in einem Merkmalvektor die Häufigkeit sein, mit der spezifische Wörter in dem Korpus von Text erscheinen. Bei der ML-Klassifizierung werden Bezeichnung zu Instanzen zugewiesen, und Modelle werden trainiert, um die zuvor zugewiesenen Bezeichnungen aus den Trainingsbeispielen korrekt vorherzusagen. ML-Algorithmen zur Klassifizierung können als „Klassifikator“ bezeichnet werden. Beispiele für Klassifikatoren beinhalten lineare Klassifikatoren, k-Nearest-Neighbours (kNN), Entscheidungsbäume, Zufallswald, Support Vector Machines (SVMs), Bayes'sche Klassifikatoren, Faltungs-Neuronalnetzwerke (CNNs) unter vielen anderen (es wird angemerkt, dass einige dieser Algorithmen auch für andere ML-Aufgaben verwendet werden können).
  • Die Begriffe „Regressionsalgorithmus“ und/oder „Regressionsanalyse“ im Kontext von ML können auf eine Menge statistischer Prozesse zum Schätzen der Beziehungen zwischen einer abhängigen Variablen (oft als ,Ergebnisvariable“ bezeichnet) und einer oder mehreren unabhängigen Variablen (oft als „Prädiktoren“, „Kovariate“ oder „Merkmale“ bezeichnet) verweisen. Beispiele für Regressionsalgorithmen/-modelle beinhalten logistische Regression, lineare Regression, Gradientenabstieg (GD), stochastischen GD (SGD) und dergleichen.
  • Die Begriffe „instanzbasiertes Lernen“ oder „speicherbasiertes Lernen“ im Kontext von ML können auf eine Familie von Lernalgorithmen verweisen, die an Stelle einer expliziten Verallgemeinerung neue Probleminstanzen mit im Training betrachteten Instanzen vergleicht, die im Speicher gespeichert wurden. Beispiele für instanzbasierte Algorithmen beinhalten k-Nearest-Neighbour und dergleichen), Entscheidungsbaum-Algorithmen (zum Beispiel Classification And Regression Tree (CART), Iterative Dichotomiser 3 (ID3), C4.5, Chi-Square Automatic Interaction Detection (CHAID) usw.), Fuzzy Decision Tree (FDT), und dergleichen), Support Vector Machines (SVM), Bayes'sche Algorithmen (zum Beispiel Bayes'sches Netzwerk (BN), ein dynamisches BN (DBN), Naive Bayes und dergleichen) und Ensemble-Algorithmen (zum Beispiel Extreme Gradient Boosting, Voting Ensemble, Bootstrap-Aggregation („Bagging“), Random Forest und dergleichen.
  • Der Begriff „Merkmal“ bezeichnet im Zusammenhang mit ML eine individuelle messbare Eigenschaft, quantifizierbare Eigenschaft oder Charakteristik eines beobachteten Phänomens. Merkmale werden üblicherweise unter Verwenden von Zahlen/Zahlen (zum Beispiel Ganzzahlen), Ketten, Variablen, Ordinalen, reellen Werten, Kategorien und/oder dergleichen repräsentiert. Ein Satz von Merkmalen kann als ein „Merkmalvektor“ bezeichnet werden. Ein „Vektor“ kann sich auf ein Tupel aus einem oder mehreren Werten beziehen, die Skalare genannt werden, und ein „Merkmalvektor“ kann ein Vektor sein, der ein Tupel aus einem oder mehreren Merkmalen beinhaltet.
  • Der Begriff „unüberwachtes Lernen“ verweist mindestens bei einigen Ausführungsformen auf eine ML-Technik, die darauf abzielt, eine Funktion zum Beschreiben einer verborgenen Struktur aus unmarkierten Daten zu lernen. Unüberwachte Lernalgorithmen bauen Modelle aus einem Datensatz auf, der nur Eingaben und keine gewünschten Ausgabebezeichnungen enthält. Unüberwachte Lernalgorithmen werden verwendet, um Struktur in den Daten zu finden, wie etwa Gruppieren oder Clustern von Datenpunkten. Beispiele für unüberwachtes Lernen sind unter vielen anderen K-Means-Clustering, Hauptkomponentenanalyse (Principal Component Analysis - PCA) und Themenmodellierung. Der Begriff „halbüberwachtes Lernen verweist mindestens bei einigen Ausführungsformen auf ML-Algorithmen, die ML-Modelle aus unvollständigen Trainingsdaten entwickeln, wobei ein Teil der Mustereingabe keine Bezeichnungen beinhaltet.
  • Der Begriff „Verstärkungslernen“ oder „RL“ verweist mindestens bei einigen Ausführungsformen auf eine zielorientierte Lerntechnik, die auf einer Interaktion mit einer Umgebung basiert. Bei RL zielt ein Agent darauf ab, ein Langzeitziel zu optimieren, indem er mit der Umgebung basierend auf einem Test- und-Error-Prozess interagiert. Beispiele für RL-Algorithmen beinhalten Markov-Entscheidungsprozess, Markov-Kette, Q-Lernen, Multi-Arm-Bandit-Lernen und Deep RL. Der Begriff „Multi-Armed Bandit Problem“, „K-Armed Bandit Problem“, „N-Armed Bandit Problem“ oder „Contextual Bandit“ verweist mindestens bei einigen Ausführungsformen auf ein Problem, bei dem ein fest begrenzter Satz von Ressourcen zwischen konkurrierenden (alternativen) Auswahlen auf eine Weise zugeordnet werden muss, die ihren erwarteten Gewinn maximiert, wenn die Eigenschaften jeder Auswahl zur Zeit der Zuweisung nur teilweise bekannt sind, und können besser verstanden werden, wenn die Zeit verstreicht oder Ressourcen der Auswahl zugewiesen werden. Der Begriff „Contextual Multi-Armed Bandit Problem“ oder „Contextual Bandit“ verweist mindestens bei einigen Ausführungsformen auf eine Version eines Multi-Armed-Bandit, bei der bei jeder Iteration ein Agent zwischen Armen auswählen muss; vor dem Treffen der Auswahl sieht der Agent einen d-dimensionalen Merkmalvektor (Context Vector), der mit einer aktuellen Iteration assoziiert ist, der Lernende verwendet diese Kontextvektoren zusammen mit den Belohnungen der in der Vergangenheit abgespielten Arme, um die Auswahl des Arms zu treffen, der in der aktuellen Iteration abgespielt werden soll, und das Ziel des Lernenden besteht im Laufe der Zeit darin, genügend Informationen darüber zu sammeln, wie die Kontextvektoren und Belohnungen miteinander in Beziehung stehen, so dass es den nächstbesten Arm vorhersagen kann, der abgespielt werden soll, indem man die Merkmalvektoren betrachtet.
  • Der Begriff „Belohnungsfunktion“ verweist im Kontext von RL mindestens bei einigen Ausführungsformen auf eine Funktion, die einen Belohnungswert basierend auf einer oder mehreren Belohnungsvariablen ausgibt; der Belohnungswert stellt eine Rückmeldung für eine RL-Strategie bereit, so dass ein RL-Agent ein wünschenswertes Verhalten lernen kann. Der Begriff „Belohnungsformen“ verweist im Kontext von RL mindestens bei einigen Ausführungsformen auf ein Anpassen oder Ändern einer Belohnungsfunktion, um eine positive Belohnung für wünschenswertes Verhalten und eine negative Belohnung für unerwünschtes Verhalten auszugeben.
  • Die Begriffe „künstliches neuronales Netzwerk“, „neuronales Netzwerk“ oder „NN“ verweisen auf eine ML-Technik, die eine Sammlung verbundener künstlicher Neuronen oder Knoten umfasst, die (in etwa) Neuronen in einem biologischen Gehirn modellieren, die Signale an andere arterielle Neuronen oder Knoten übertragen können, wobei Verbindungen (oder Edge) zwischen den künstlichen Neuronen oder Knoten (in etwa) Synapsen eines biologischen Gehirns modelliert werden. Die künstlichen Neuronen und Edges weisen typischerweise ein Gewicht auf, das sich mit fortschreitendem Lernen anpasst. Das Gewicht erhöht oder verringert die Stärke des Signals an einer Verbindung. Neuronen können eine Schwelle derart aufweisen, dass ein Signal nur dann gesendet wird, wenn das Summensignal diese Schwelle überschreitet. Die künstlichen Neuronen können in eine oder mehrere Schichten aggregiert oder gruppiert werden, wobei unterschiedliche Schichten unterschiedliche Transformationen an ihren Eingängen ausführen können. Signale wandern von der ersten Schicht (der Eingabeschicht) zur letzten Schicht (der Ausgabeschicht), gegebenenfalls nach mehrmaligem Durchlaufen der Schichten. NNs werden üblicherweise für überwachtes Lernen verwendet, können aber auch für unüberwachtes Lernen verwendet werden. Beispiele für NNs beinhalten Deep NN (DNN), Feed Forward NN (FFN), ein Deep FNN (DFF), Convolutional NN (CNN), Deep CNN (DCN), Deconvolutional NN (DNN), ein Deep Belief NN, ein Perception NN, Recurrent NN (RNN) (zum Beispiel einschließlich Long Short Term Memory-Algorithmus (LSTM-Algorithmus), Gated Recurrent Unit (GRU), usw..), Deep Stacking Network (DSN).
  • Der Begriff „Sitzung“ verweist mindestens bei einigen Ausführungsformen auf einen temporären und interaktiven Informationsaustausch zwischen zwei oder mehr Kommunikationsvorrichtungen, zwei oder mehr Anwendungsinstanzen, zwischen einem Computer und einem Benutzer oder zwischen zwei oder mehr beliebigen Entitäten oder Elementen.
  • Der Begriff „Datennetzwerk“ oder „DN“ verweist mindestens bei einigen Ausführungsformen auf ein Netz, das datenzentrische Dienste hostet, wie etwa zum Beispiel Betreiberdienste, das Internet, Drittparteidienste oder Unternehmensnetzwerke. Zusätzlich oder alternativ verweist ein DN mindestens bei einigen Ausführungsformen auf Dienstnetzwerke, die einem Betreiber oder einer Drittpartei gehören, die einem Client oder einem Benutzergerät (UE) als ein Dienst angeboten werden. DNs werden mitunter als „Packet Data Networks“ oder „PDNs“ bezeichnet. Der Begriff „Local Area Data Network“ oder „LADN“ verweist mindestens bei einigen Ausführungsformen auf ein DN, auf das das UE nur an spezifischen Orten zugreifen kann, der Konnektivität mit einem spezifischen DNN bereitstellt und dessen Verfügbarkeit dem UE bereitgestellt wird.
  • Der Begriff „PDU-Connectivity Service“ verweist mindestens bei einigen Ausführungsformen auf einen Dienst, der einen Austausch von Protokolldateneinheiten (PDUs) zwischen einem UE und einem DN bereitstellt. Der Begriff „PDU-Sitzung“ verweist mindestens bei einigen Ausführungsformen auf eine Assoziation zwischen einem UE und einem DN, die einen PDU-Konnektivitätsdienst bereitstellt. Ein PDU-Sitzungstyp kann IPv4, IPv6, IPv4v6, Ethernet, unstrukturiert oder ein beliebiger anderer Netzwerk-/Verbindungstyp, wie etwa die hierin besprochenen, sein. Der Begriff „MA-PDU-Sitzung“ verweist mindestens bei einigen Ausführungsformen auf eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der gleichzeitig ein Zugangsnetzwerk oder mehrere Zugangsnetzwerke simultan verwenden kann.
  • Der Begriff „Verkehrsforen“ verweist mindestens bei einigen Ausführungsformen auf eine Bandbreitenverwaltungstechnik, die eine Datenübertragung verwaltet, um einem gewünschten Verkehrsprofil oder einer gewünschten Dienstklasse zu entsprechen. Das Verkehrsformen stellt eine ausreichende Netzwerkbandbreite für zeitsensitive kritische Anwendungen unter Verwenden von Richtlinienregeln, Datenklassifizierung, Warteschlangen, QoS und anderen Techniken sicher. Der Begriff „Drosseln“ verweist mindestens bei einigen Ausführungsformen auf die Regelung von Strömen in ein Netzwerk oder daraus heraus oder in eine spezifische Vorrichtung Element daraus.
  • Der Begriff „Netzwerkadresse“ verweist mindestens bei einigen Ausführungsformen auf eine Kennung für einen Knoten oder Host in einem Computernetzwerk und kann eine eindeutige Kennung über ein Netzwerk hinweg und/oder für einen lokal verwalteten Teil des Netzwerks eindeutig sein. Beispiele für Netzwerkadressen beinhalten eine Closed Access Group Identifier (CAG-ID), eine BD_ADDR (Bluetooth Hardware Device Address), eine zellulare Netzwerkadresse (zum Beispiel APN (Access Point Name), eine AF-Kennung (ID), eine EAS-ID (Edge-Application Server -Kennung), eine DNAI (Data Network Access Identifier), Data Network Name Name (DNN), EPS Bearer Identity (EBI), Equipment Identity Register (EIR) und/oder 5G-EIR, Extended Unique Identifier (EUI), Group ID for Network Selection (GIN), Generic Public Subscription Identifier (GPSI), Global Unique AMF Identifier (GUAMI), Global Unique Temporary Identifier (GUTI) und/oder 5G-GUTI, International Mobile Equipment Identity (IMEI), IMEI-TYP-Type Allocation Code (IMEA/TAC), International Mobile Subscriber Identity (IMSI), Local Area Data Network (LADN) DNN, Mobile Subscriber Identification Number (MSIN), Mobile Subscriber/Station ISDN Number (MSISDN), Network Identifier (NID), Network Slice Instance (NSI) -ID, Permanent Equipment Identifier (PEI), Public Land Mobile Network (PLMN) -ID, Qo Flow ID (QFI) und/oder 5G-QoS Identifier (5QI), RAN-ID, Routing Indicator, SMS Function (SMSF) -ID, Stand-alone Non-Public Network (SNPN) -ID, Subscription Concealed Identifier (SUCI), Subscription Permanent Identifier (SUPI), Temporary Mobile Subscriber Identity (TMSI) und Varianten davon, UE-Access Category and Identit und/oder andere mobilfunknetz-bezogene Kennungen), eine E-Mail-Adresse, eine Enterprise Application Server-ID, eine Endpunktadresse, einen Electronic Product Code (EPC), wie von dem EPCglobal Tag Data Standard definiert, einen FQDN (Fully Qualified Domain Name), eine IP-Adresse (Internet Protocol Address) in einem IP-Netzwerk, (zum Beispiel IP Version 4 (Ipv4), IP Version 6 (IPv6) etc.), eine IPX-Adresse (Internet Packet Exchange-Address), LAN-ID (Local Area Network ID), eine MAC-Adresse (Media Access Control Address)), Personal Area Network-ID (PAN-ID), eine Port Nummer (zum Beispiel Transmission Control Protocol-Port-Nr. (TCP Port Number), User Datagram Protocol-Port-Nr. (UDP Port Number), QUIC Connection ID, RFID Tag, Service Set Identifier (SSID) und Varianten davon, Telefonnummern in einem öffentlichen Telefonnetz (PTSN), Universally Unique Identifier (UUID) (zum Beispiel wie in ISO/IEC 11578:1996 spezifiziert), ein Universal Resource Locator (URL) und/oder Universal Resource Identifier (URI), Virtual LAN (VLAN) -ID, eine X.21-Adresse, eine X.25-Adresse, Zigbee® -ID, Zigbee® -Device Network-ID und/oder eine beliebige andere geeignete Netzwerkadresse und Komponenten davon. Der Begriff „Anwendungskennung“, „Anwendungs-ID“ oder „APP-ID“ verweist mindestens bei einigen Ausführungsformen auf eine Kennung, die auf eine spezifische Anwendung oder Anwendungsinstanz abgebildet werden kann; im Kontext von 3GPP-5G/NR-Systemen kann eine „Anwendungskennung“ auf eine Kennung verweisen, die auf eine spezifische Anwendungsverkehrsdetektionsregel abgebildet werden kann. Eine „Endpunktadresse“ kann auf eine Adresse verweisen, die verwendet wird, um den Host/Autoritätsteil einer Ziel-URI zu bestimmen, wobei die Ziel-URI verwendet wird, um auf einen NF-Dienst (zum Beispiel um Dienstoperationen aufzurufen) eines NF-Diensteproduzenten oder für Benachrichtigungen an einen Nf-Dienstverbraucher zuzugreifen. Der Begriff „CAG-ED“ verweist mindestens bei einigen Ausführungsformen auf eine Kennung einer geschlossenen Zugangsgruppe (Closed Access Group - CAG), und der Begriff „geschlossene Zugangsgruppe“ oder „CAG“ verweist mindestens bei einigen Ausführungsformen auf eine Gruppe von Liste von Benutzern, denen es erlaubt ist, sich mit einem spezifischen Netzwerk, einem spezifischen Zugangsnetzwerk und/oder einer Anbindung an eine spezifische Zelle oder einen spezifischen Netzwerkzugangsknoten zu verbinden und/oder darauf zuzugreifen. Geschlossene Zugangsgruppen (CAGs) werden mitunter als Zugangskontrolllisten (Access Control Lists - ACLs), geschlossene Teilnehmergruppen (Closed Subscriber Groups - CSGs), geschlossene Benutzergruppen (Closed Unser Groups - CUGs) und dergleichen bezeichnet. Der Begriff „Port“, wie hierin verwendet (zum Beispiel im Kontext von Computernetzwerken), verweist mindestens bei einigen Ausführungsformen auf einen Kommunikationsendpunkt, eine virtuelle Datenverbindung zwischen zwei oder mehr Entitäten und/oder einen virtuellen Punkt, an dem Netzwerkverbindungen beginnen und enden; zusätzlich oder alternativ ist ein „Port“ mit einem spezifischen Prozess oder Dienst assoziiert.
  • Der Begriff „Teilnetzwerk“ oder „Sub-Netzwerk“ verweist mindestens bei einigen Ausführungsformen auf eine logische Subdivision eines Netzwerks, wie etwa eines IP-Netzwerks. Die Praxis des Teilens eines Netzwerks in zwei oder mehr Netzwerke wird als „Sub-Netzwerk“ bezeichnet. Der Begriff „Netzwerkmaske“ oder „Sub-Netzwerkmaske“ verweist mindestens bei einigen Ausführungsformen auf eine Bitmaske, die durch bitweise UND-Verknüpfungen auf eine Netzwerkadresse (zum Beispiel eine IP-Adresse in einem IP-Netzwerk) angewandt wird, um ein Routing-Präfix zu erhalten, und/oder ist eine 32-Bit-„Maske“, die verwendet wird, um eine IP-Adresse in Sub-Netzwerke aufzuteilen und die verfügbaren Hosts des Netzwerks zu spezifizieren.
  • Der Begriff „kryptographische Hashfunktion“, „Hashfunktion“ oder „Hash“) verweist mindestens bei einigen Ausführungsformen auf einen mathematischen Algorithmus, der Daten beliebiger Größe (mitunter als eine „Nachricht“ bezeichnet) auf ein Bit-Array einer festen Größe (mitunter als ein „Hashwert“, „Hash“ oder „Nachrichten-Digest“ bezeichnet) abbildet. Eine kryptographische Hash-Funktion ist üblicherweise eine Einwegfunktion, die eine Funktion ist, die praktisch nicht invertierbar ist. Der Begriff „Integrität“ verweist mindestens bei einigen Ausführungsformen auf einen Mechanismus, der sicherstellt, dass Daten nicht ungenehmigt geändert wurden. Beispiele für kryptographische Mechanismen, die zum Integritätsschutz verwendet werden können, beinhalten digitale Signaturen, Nachrichtenauthentifizierungscodes (MAC) und sichere Hashs.
  • Der Begriff „Fluss“ verweist mindestens bei einigen Ausführungsformen auf eine Folge von Daten und/oder Dateneinheiten (zum Beispiel Datagramme, Pakete oder dergleichen) von einer Quellenentität/einem Quellenelement zu einer Zielentität/einem Zielelement. Zusätzlich oder alternativ verweisen die Begriffe „Fluss“ oder „Verkehrsfluss“ mindestens bei einigen Ausführungsformen auf ein künstliches und/oder logisches Äquivalent zu einem Anruf, einer Verbindung oder einem Link. Zusätzlich oder alternativ verweisen die Begriffe „Fluss“ oder „Verkehrsfluss“ mindestens bei einigen Ausführungsformen auf eine Folge von Paketen, die von einer bestimmten Quelle zu einem bestimmten Unicast-, Anycast- oder Multicast-Ziel gesendet werden, die die Quelle als einen Fluss kennzeichnen möchte; von einem Sichtpunkt der oberen Schicht kann ein Fluss alle Pakete in einer spezifischen Transportverbindung oder einem Medienstrom beinhalten, jedoch ist ein Fluss nicht notwendigerweise 1:1 auf eine Transportverbindung abgebildet. Zusätzlich oder alternativ verweisen die Begriffe „Fluss“ oder „Verkehrsfluss“ mindestens bei einigen Ausführungsformen auf einen Satz von Daten und/oder Dateneinheiten (zum Beispiel Datagramme, Pakete oder dergleichen), die einen Beobachtungspunkt in einem Netzwerk während eines gewissen Zeitintervalls passieren. Zusätzlich oder alternativ verweist der Begriff „Fluss“ mindestens bei einigen Ausführungsformen auf einen Benutzerebenen-Datenlink, der an eine Assoziation angehängt ist. Beispiele sind leitungsvermittelter Telefonanruf, Voice-Over-IP-Anruf, Empfang einer SMS, Senden einer Kontaktkarte, PDP-Kontext für Internetzugang, Demultiplexen eines Tv-Kanals aus einem Kanalmultiplex, Berechnen von Positionskoordinaten aus Geopositionierungssatellitensignalen usw. Für Zwecke der vorliegenden Offenbarung können die Begriffe „Verkehrsfluss“, „Daten-Fluss“, „Datenfluss“, „Paketfluss“, „Netzwerkfluss“ und/oder „Fluss“ austauschbar verwendet werden, obwohl sich diese Begriffe auf unterschiedliche Konzepte beziehen können.
  • Der Begriff„ „Stream“ verweist mindestens bei einigen Ausführungsformen auf eine Folge von Datenelementen, die über die Zeit zur Verfügung gestellt werden. Funktionen, die an einem Strom arbeiten, der einen anderen Strom erzeugen kann, werden mindestens bei einigen Ausführungsformen als „Filter“ bezeichnet und können analog zur Funktionszusammensetzung in Pipelines geschaltet werden. Filter können jeweils an einem Element eines Stroms arbeiten oder können ein Ausgabeelement auf mehreren Eingabeelementen basieren, wie etwa einem gleitenden Mittelwert.
  • Der Begriff „verteiltes Rechnen“ verweist mindestens bei einigen Ausführungsformen auf ein Modell, in dem Komponenten, die sich auf vernetzten Computern befinden, kommunizieren und ihre Aktionen koordinieren, indem sie Nachrichten weiterleiten, die miteinander interagieren, um ein gemeinsames Ziel zu erreichen.
  • Der Begriff „Mikrodienst“ verweist mindestens bei einigen Ausführungsformen auf einen oder mehrere Prozesse, die über ein Netzwerk kommunizieren, um ein Ziel unter Verwenden technologieagnostischer Protokolle (zum Beispiel HTTP oder dergleichen) zu erfüllen. Zusätzlich oder alternativ verweist der Begriff „Mikrodienst“ mindestens bei einigen Ausführungsformen auf Dienste, die relativ klein in der Größe, nachrichtenfähig, durch Kontexte begrenzt, autonom entwickelt, unabhängig einsetzbar, dezentral und/oder mit automatisierten Prozessen aufgebaut und freigegeben sind. Zusätzlich oder alternativ verweist der Begriff „Mikrodienst“ mindestens bei einigen Ausführungsformen auf ein in sich geschlossenes Funktionalitätsstück mit klaren Schnittstellen und kann eine Schichtarchitektur durch ihre eigenen internen Komponenten umsetzen. Der Begriff „Mikrodienstarchitektur“ verweist mindestens bei einigen Ausführungsformen auf eine Variante des strukturellen Typs der diensteorientierten Architektur (SOA), wobei Anwendungen als eine Sammlung lose gekoppelter Dienste (zum Beispiel feinkörnige Dienste) angeordnet sind und leichte Protokolle verwenden können.
  • Der Begriff „Time to Live“ (oder „TTL“) oder „Hop Limit“ verweist mindestens bei einigen Ausführungsformen auf einen Mechanismus, der den Lebenszeitraum oder die Lebensdauer von Daten in einem Computer oder Netzwerk begrenzt. TTL kann als ein Zähler oder Zeitstempel, der an die Daten angehängt oder in diese eingebettet ist, umgesetzt werden. Sobald die vorgeschriebene Ereigniszählung oder der Zeitraum abgelaufen ist, werden Daten verworfen oder neu validiert.
  • Der Begriff „Warteschlange“ verweist mindestens bei einigen Ausführungsformen auf eine Sammlung von Entitäten (zum Beispiel Daten, Objekte, Ereignisse usw.), die gespeichert und gehalten werden, um später verarbeitet zu werden, die in einer Folge gehalten werden und durch das Hinzufügen von Entitäten an einem Ende der Folge und das Entfernen von Entitäten von dem anderen Ende der Folge modifiziert werden können; das Ende der Folge, an der Elemente hinzugefügt werden, kann als „hinten“, „End-“ oder „Rück“ der Warteschlange bezeichnet werden, und das Ende, an dem Elemente entfernt werden, kann als „Kopf“ oder „Anfang“ der Warteschlange bezeichnet werden. Zusätzlich dazu kann eine Warteschlange die Funktion eines Puffers ausführen und die Begriffe „Warteschlange“ und „Puffer“ können durch die vorliegende Offenbarung hindurch austauschbar verwendet werden. Der Begriff „Einreihen in eine Warteschlange“ verweist mindestens bei einigen Ausführungsformen auf eine oder mehrere Operationen des Hinzufügens eines Elements hinten an einer Warteschlange. Der Begriff „Ausreihen aus der Warteschlange“ verweist mindestens bei einigen Ausführungsformen auf eine oder mehrere Operationen zum Ausreihen eines Elements vom Anfang einer Warteschlange.
  • Der Begriff „Warteschlangenverzögerung“ verweist mindestens bei einigen Ausführungsformen auf eine Zeitdauer, in der ein Auftrag in einer Warteschlange wartet, bis dieser Auftrag ausgeführt werden kann. Zusätzlich oder alternativ verweist der Begriff „Warteschlangenverzögerung“ mindestens bei einigen Ausführungsformen auf eine Zeitdauer, während der ein Paket in einer Warteschlange wartet, bis es verarbeitet und/oder übertragen werden kann. Der Begriff „Paketverzögerung“ verweist mindestens bei einigen Ausführungsformen auf die Zeit, die benötigt wird, um ein beliebiges Paket von einem Punkt zu einem anderen zu übertragen. Zusätzlich oder alternativ verweist der Begriff „Paketverzögerung“ oder „pro Paketverzögerung“ mindestens bei einigen Ausführungsformen auf die Differenz zwischen einer Paketempfangszeit und einer Paketübertragungszeit. Zusätzlich oder alternativ kann die „Paketverzögerung“ oder „pro Paketverzögerung“ gemessen werden, indem die Paketsendezeit von der Paketempfangszeit subtrahiert wird, zu der der Sender und der Empfänger mindestens etwas synchronisiert sind. Der Begriff „Verarbeitungsverzögerung“ verweist mindestens bei einigen Ausführungsformen auf eine Zeitdauer, die benötigt wird, um ein Paket in einem Netzwerkknoten zu verarbeiten. Der Begriff „Übertragungsverzögerung“ verweist mindestens bei einigen Ausführungsformen auf eine Zeitdauer, die benötigt wird (oder notwendig ist), um ein Paket (oder alle Bits eines Pakets) in ein Übertragungsmedium zu pushen. Der Begriff „Propagationsverzögerung“ verweist mindestens bei einigen Ausführungsformen auf die Zeitdauer, die der Header eines Signals benötigt, um sich von einem Sender zu einem Empfänger zu bewegen. Der Begriff „Netzwerkverzögerung“ verweist mindestens bei einigen Ausführungsformen auf die Verzögerung einer Dateneinheit innerhalb eines Netzwerks (zum Beispiel eines IP-Pakets innerhalb eines IP-Netzwerks).
  • Der Begriff „Verzögerungsgrenze“ verweist mindestens bei einigen Ausführungsformen auf eine vorbestimmte oder konfigurierte Menge akzeptabler Verzögerung. Der Begriff „pro Paketverzögerungsgrenze“ verweist mindestens bei einigen Ausführungsformen auf eine vorbestimmte oder konfigurierte Menge akzeptabler Paketverzögerung, wobei Pakete, die nicht innerhalb der Verzögerungsgrenze verarbeitet und/oder übertragen werden, als Lieferausfälle betrachtet werden und verworfen oder fallen gelassen werden.
  • Der Begriff „Paketabfallrate“ verweist mindestens bei einigen Ausführungsformen auf einen Anteil von Paketen, die aufgrund hoher Verkehrslast oder Verkehrsverwaltung nicht an das Ziel gesendet wurden und als Teil der Paketabfallrate angesehen werden sollte. Der Begriff „Paketverlustrate“ verweist mindestens bei einigen Ausführungsformen auf einen Anteil von Paketen, die von dem Ziel nicht empfangen werden konnten, einschließlich Paketen, die verworfen werden, Paketen, die bei der Übertragung verloren gehen und Paketen, die in falschem Format empfangen werden. Der Begriff „Latenz“ verweist mindestens bei einigen Ausführungsformen auf die Zeitdauer, die benötigt wird, um eine erste/anfängliche Dateneinheit in einem Daten-Burst von einem Punkt zu einem anderen zu übertragen.
  • Der Begriff „Leistungsfähigkeitsindikator“ verweist mindestens bei einigen Ausführungsformen auf über eine Gruppe von Netzwerkfunktionen (NFs) aggregierte Leistungsfähigkeitsdaten, die aus an den NFs, die zu der Gruppe gehören, gesammelten Leistungsfähigkeitsmessungen gemäß dem in einer Leistungsfähigkeitsindikator-Definition identifizierten Aggregationsverfahren abgeleitet werden.
  • Der Begriff „physische Rate“ oder „PHY-Rate“ verweist mindestens bei einigen Ausführungsformen auf eine Geschwindigkeit, mit der ein oder mehrere Bits tatsächlich über ein Übertragungsmedium gesendet werden. Zusätzlich oder alternativ verweist der Begriff „physische Rate“ oder „PHY-Rate“ mindestens bei einigen Ausführungsformen auf eine Geschwindigkeit, mit der sich Daten über eine drahtlose Verbindung zwischen einem Sender und einem Empfänger bewegen können.
  • Der Begriff „Durchsatz“ oder „Netzdurchsatz“ verweist mindestens bei einigen Ausführungsformen auf eine Produktionsrate oder die Rate, mit der etwas verarbeitet wird. Zusätzlich oder alternativ verweist der Begriff „Durchsatz“ oder „Netzwerkdurchsatz“ mindestens bei einigen Ausführungsformen auf eine Rate einer erfolgreichen Nachricht-Lieferung (Datum-Lieferung) über einen Kommunikationskanal. Der Begriff „Goodput“ verweist mindestens bei einigen Ausführungsformen auf eine Anzahl von Nutzinformationsbits, die von dem Netzwerk an ein bestimmtes Ziel pro Zeiteinheit geliefert werden.
  • Der Begriff „Einrichten“ oder „Einrichtung“ verweist mindestens bei einigen Ausführungsformen auf (teilweise oder vollständig) Handlungen, Aufgaben, Operationen usw., die auf das Bringen oder die Bereitschaft zum Bringen von etwas entweder aktiv oder passiv zum (Beispiel Aufdecken einer Vorrichtungsidentität oder Entitätsidentität) verweisen. Zusätzlich oder alternativ verweist der Begriff „Einrichten“ oder „Einrichtung“ mindestens bei einigen Ausführungsformen auf (teilweise oder vollständig) Handlungen, Aufgaben, Operationen usw., die auf Initiieren, Starten oder Erwärmen einer Kommunikation oder Initiieren, Starten oder Erwärmen einer Beziehung zwischen zwei Entitäten oder Elementen verweisen (zum Beispiel Einrichten einer Sitzung, Einrichten einer Sitzung usw.). Zusätzlich oder alternativ verweist der Begriff „Einrichten“ oder „Einrichtung“ mindestens bei einigen Ausführungsformen auf das Initiieren von etwas zu einem Zustand der Arbeitsbereitschaft. Der Begriff „eingerichtet“ verweist mindestens bei einigen Ausführungsformen auf einen betriebsbereiten oder gebrauchsfertigen Zustand (zum Beispiel vollständige Etablierung). Darüber hinaus kann eine beliebige Definition für den Begriff „Einrichten“ oder „Einrichtung“, die in einer beliebigen Spezifikation oder einem beliebigen Standard definiert ist, für Zwecke der vorliegenden Offenbarung verwendet werden, und derartige Definitionen werden nicht von einer der oben genannten Definitionen verworfen.
  • Obwohl viele der vorstehenden Beispiele unter Verwenden spezieller zellularer / mobiler Netzwerkterminologie bereitgestellt sind, einschließlich unter Verwenden von 4G/5G-3GPP-Netzwerkkomponenten (oder erwarteten terahertzbasierten 6G/6G+ Technologien), versteht es sich, dass diese Beispiele auf viele andere Anwendungen großflächiger und lokaler drahtloser Netzwerken sowie die Integration drahtgebundener Netzwerke (einschließlich optischer Netzwerke und assoziierter Fasern, Transceiver usw.) angewandt werden können. Darüber hinaus können verschiedene Standards (zum Beispiel 3GPP, ETSI usw.) verschiedene Nachrichtenformate, PDUs, Container, Rahmen usw. als eine Folge optionaler oder obligatorischer Datenelementen (DEs), Datenrahmen (DFs), Informationselemente (IEs) und/oder dergleichen umfassend definieren. Es versteht sich jedoch, dass die Anforderungen eines beliebigen speziellen Standards die hierin besprochenen Ausführungsformen nicht einschränken sollten und daher eine beliebige Kombination von Containern, Rahmen, DFs, DEs, IEs, Werten, Handlungen und/oder Merkmalen in verschiedenen Ausführungsformen möglich ist, einschließlich einer beliebigen Kombination von Containern, DEs, Werten, Aktionen und/oder Merkmalen, die streng befolgt werden müssen, um derartige Standards oder irgendeine Kombination von Containern, Rahmen, DFs, DEs, IEs, Werten, Aktionen und/oder Merkmalen einzuhalten, die stark empfohlen werden und/oder mit oder in Anwesenheit/Abwesenheit optionaler Elemente verwendet werden.
  • Obwohl diese Umsetzungen unter Bezugnahme auf spezifische beispielhafte Aspekte beschrieben wurden, versteht es sich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzbereich der vorliegenden Offenbarung abzuweichen. Viele der hierin beschriebenen Anordnungen und Prozesse können in Kombination oder in parallelen Umsetzungen verwendet werden, um eine größere Bandbreite/einen größeren Durchsatz bereitzustellen und Edge-Dienstauswahlen zu unterstützen, die den zu bedienenden Edge-Systemen zur Verfügung gestellt werden können. Dementsprechend sind die Spezifikation und die Zeichnungen in einem veranschaulichenden statt in einem beschränkenden Sinn anzusehen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen zur Veranschaulichung und nicht zur Einschränkung spezifische Aspekte, in denen der Gegenstand umgesetzt werden kann. Die veranschaulichten Aspekte sind hinreichend ausführlich beschrieben, um es Fachleuten zu ermöglichen, die hier offenbarten Lehren umzusetzen. Andere Aspekte können genutzt und daraus abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Diese ausführliche Beschreibung ist daher nicht in einem beschränkenden Sinne aufzufassen und der Schutzumfang verschiedener Aspekte wird nur durch die angehängten Ansprüche gemeinsam mit dem vollen Bereich von Äquivalenten, auf die derartige Ansprüche Anspruch haben, definiert.
  • Auf derartige Aspekte des Erfindungsgegenstands kann hierin einzeln und/oder kollektiv, lediglich der Einfachheit halber und ohne die Absicht, den Schutzumfang dieser Anmeldung willentlich auf einen einzigen Aspekt oder Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart ist, Bezug genommen werden. Obwohl spezielle Aspekte hierin veranschaulicht und beschrieben wurden, versteht sich daher, dass jegliche Anordnung, die dafür berechnet ist, denselben Zweck zu erfüllen, die gezeigten speziellen Aspekte decken kann. Diese Offenbarung bezweckt, beliebige und alle Anpassungen oder Variationen verschiedener Aspekte abzudecken. Kombinationen der obigen Aspekte und anderer hierin nicht speziell beschriebener Aspekte werden für Fachleute beim Überprüfen der obigen Beschreibung offensichtlich sein.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 63/130317 [0001]

Claims (25)

  1. Verfahren zum Betreiben eines Gateways (GW) eines Edge-Application Programming Interface Service (edgeXapis), wobei das Verfahren umfasst: Initiieren, über einen ersten Referenzpunkt, des Einrichtens einer ersten Verbindung mit einer ersten Edge-Computing-Plattform (ECP), die eine erste Edge-Computing-Technologie (ECT) umsetzt; Initiieren, über einen zweiten Referenzpunkt, einer Einrichtung einer zweiten Verbindung mit einem zweiten ECP, die eine zweite ECT umsetzt, die sich von der ersten ECT unterscheidet; und Aufdecken gegenüber der zweiten ECP über den zweiten Referenzpunkt, eines Satzes erster Anwendungsprogrammierschnittstellen (APIs), die von der ersten ECP aufgedeckt werden.
  2. Verfahren nach Anspruch 1, wobei das Einrichten der ersten Verbindung mit der ersten ECP umfasst: Empfangen, von der ersten ECP über den ersten Referenzpunkt, des Satzes erster APIs, die von der ersten ECP aufgedeckt werden.
  3. Verfahren nach den Ansprüchen 1-2, wobei das Einrichten der ersten Verbindung mit der ersten ECP Folgendes umfasst: Authentifizieren und Verifizieren der ersten ECP unter Verwenden eines Authentifizierungs- und Attestierungsmechanismus.
  4. Verfahren nach Anspruch 3, das weiter umfasst: Authentifizieren und Verifizieren von Anforderungen, die von der ersten ECP empfangen werden, unter Verwenden des Authentifizierungs- und Attestierungsmechanismus.
  5. Verfahren nach den Ansprüchen 3-4, wobei der Authentifizierungs- und Attestierungsmechanismus einer oder beide von OAuth2 und Transportschichtsicherheit (TLS) ist.
  6. Verfahren nach den Ansprüchen 1 bis 5, wobei das Einrichten der zweiten Verbindung mit der zweiten ECP umfasst: Empfangen, über den zweiten Referenzpunkt, von einer zweiten Edge-Anwendung (App), die von der zweiten ECP umgesetzt wird, einer Anfrage nach einer Liste aufgedeckter APIs; Erzeugen der Liste aufgedeckter APIs, wobei die Liste aufgedeckter APIs den Satz erster APIs, die von der ersten ECP aufgedeckt werden, und einen Satz zweiter APIs, die von der zweiten ECP aufgedeckt werden, beinhaltet; und Senden der Liste aufgedeckter APIs über den zweiten Referenzpunkt an die zweite Edge-App.
  7. Verfahren nach Anspruch 6, das weiter umfasst: Aktualisieren einer Liste von Edge-Apps, die Zugriff auf die Liste aufgedeckter APIs haben, um die zweite Edge-App zu beinhalten; und Senden der Liste von Edge-Apps an die erste ECP über den ersten Referenzpunkt.
  8. Verfahren nach den Ansprüchen 6-7, wobei die zweite Edge-App in der Lage ist, erste Transportinformationen von der ersten ECP zu erhalten, wobei die ersten Transportinformationen Transportprotokolle angeben, die von der ersten ECP unterstützt werden.
  9. Verfahren nach den Ansprüchen 2-7, wobei das Einrichten der ersten Verbindung mit der ersten ECP weiter umfasst: Empfangen erster Transportinformationen von der ersten ECP über den ersten Referenzpunkt, wenn die erste ECP den Satz erster APIs Gegenüber dem edgeXapis-GW aufdeckt, wobei die ersten Transportinformationen Transportprotokolle angeben, die von der ersten ECP unterstützt werden.
  10. Verfahren nach Anspruch 9, das weiter umfasst: Aufdecken, gegenüber der zweiten ECP über den zweiten Referenzpunkt, der ersten Transportinformation, wenn der Satz erster APIs gegenüber der zweiten ECP aufgedeckt wird.
  11. Verfahren nach den Ansprüchen 8 bis 10, wobei die zweite Edge-App in der Lage ist, eine angekündigte API in der Liste aufgedeckter APIs aufzurufen.
  12. Verfahren nach Anspruch 11, wobei die zweite Edge-App in der Lage ist, mit einer von der ersten ECP umsetzten ersten Edge-App über einen dritten Referenzpunkt unter Verwenden eines von der aufgerufenen API definierten Transportprotokolls zu kommunizieren.
  13. Verfahren nach den Ansprüchen 1 bis 12, wobei die erste ECP eine Mehrfachzugriffs-Edge-Computing-Plattform (MEC-Plattform) in einem MEC-Framework ist und der dritte Referenzpunkt eine Mpl-Schnittstelle ist.
  14. Verfahren nach Anspruch 13, wobei die zweite ECP ein Edge-Enabler-Server (EES) in einem Edge-Computing-Framework des Third Generation Partnership Project (3GPP) ist, die zweite Edge-App ein Edge-Anwendungsserver (EAS) ist, und die erste Edge-App eine MEC-App ist, die als ein Anwendungsserver eingesetzt wird.
  15. Verfahren nach den Ansprüchen 1 bis 12, wobei die erste ECP ein EES in einem 3GPP-Edge-Computing-Framework ist, und der dritte Referenzpunkt ein EDGE-3-Referenzpunkt ist.
  16. Verfahren nach Anspruch 15, wobei die zweite ECP eine MEC-Plattform in einem MEC-Framework ist, die erste Edge-App ein EAS ist, und die zweite Edge-App eine MEC-App ist, die als ein Anwendungsserver eingesetzt wird.
  17. Verfahren nach den Ansprüchen 1 bis 15, wobei das edgeXapis-GW in einem gemeinsamen API-Framework(CAPIF) enthalten oder mit diesem verbunden ist, und der dritte Referenzpunkt ein CAPIF-2e-Referenzpunkt, ein CAPIF-3e-Referenzpunkt oder ein CAPIF-7E-Referenzpunkt ist.
  18. Verfahren nach Anspruch 17, wobei die erste ECP als CAPIF-API-Aufdeckungsfunktion (AEF) agiert.
  19. Verfahren nach Anspruch 18, wobei das edgeXapis-GW Teil einer CAPIF-Kernfunktion (CCF) der CAPIF ist.
  20. Verfahren nach Anspruch 18, wobei sich das edgeXapis-GW außerhalb einer CCF der CAPIF befindet.
  21. Verfahren nach den Ansprüchen 18 und 19, wobei eine erste ECP-Konfiguration der ersten ECP einen Root-Uniform Resource Locator (URL) der CCF beinhaltet.
  22. Verfahren nach Anspruch 18 bis 21, wobei der erste Referenzpunkt ein CAPIF-le-Referenzpunkt oder ein CAPIF-3e-Referenzpunkt ist, und wobei der zweite Referenzpunkt ein CAPIF-1-Referenzpunkt oder ein CAPIF-3-Referenzpunkt ist.
  23. Ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei die Ausführung der Anweisungen durch die Prozessorschaltungsanordnung die Prozessorschaltungsanordnung veranlassen soll, das Verfahren nach einem der Ansprüche 1 bis 22 ausführt.
  24. Integrierte Schaltung, die eine oder mehrere der Prozessorschaltungsanordnung nach Anspruch 23 und das eine oder die mehreren computerlesbaren Medien nach Anspruch 23 umfasst.
  25. Einrichtung, die Mittel zum Ausführen des Verfahrens nach einem der Ansprüche 1 bis 23 aufweist.
DE102021211176.9A 2020-12-23 2021-10-04 Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen Pending DE102021211176A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202063130317P 2020-12-23 2020-12-23
US63/130,317 2020-12-23
US17/484,719 2021-09-24
US17/484,719 US20220086218A1 (en) 2020-12-23 2021-09-24 Interoperable framework for secure dual mode edge application programming interface consumption in hybrid edge computing platforms

Publications (1)

Publication Number Publication Date
DE102021211176A1 true DE102021211176A1 (de) 2022-06-23

Family

ID=80625870

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021211176.9A Pending DE102021211176A1 (de) 2020-12-23 2021-10-04 Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen

Country Status (3)

Country Link
US (1) US20220086218A1 (de)
KR (1) KR20220092366A (de)
DE (1) DE102021211176A1 (de)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11575564B2 (en) * 2018-10-31 2023-02-07 Intel Corporation Deploying edge computing
WO2020156673A1 (en) * 2019-01-31 2020-08-06 Nokia Technologies Oy A method, apparatus and computer program product for management of mobile entities
CN114698022A (zh) * 2019-04-01 2022-07-01 华为技术有限公司 获取数据包延迟参数的方法、系统和装置
CN110290140B (zh) * 2019-06-28 2021-09-24 腾讯科技（深圳）有限公司 多媒体数据处理方法及装置、存储介质、电子设备
US11470017B2 (en) * 2019-07-30 2022-10-11 At&T Intellectual Property I, L.P. Immersive reality component management via a reduced competition core network component
US11979367B2 (en) * 2019-09-18 2024-05-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for local application server discovery in mobile edge computing
EP4115595A1 (de) * 2020-03-05 2023-01-11 Telefonaktiebolaget LM Ericsson (publ) Anwendungsausgelöste einrichtung eines verteilten ankers zur edge-computing
US20230059465A1 (en) * 2021-02-05 2023-02-23 Jonathan SIEGEL System and method for an electronic signature device
US11895508B1 (en) 2021-03-18 2024-02-06 Amazon Technologies, Inc. Demand-based allocation of ephemeral radio-based network resources
US11641600B2 (en) * 2021-03-26 2023-05-02 Nokia Solutions And Networks Oy Bandwidth throttling in a radio access network
CN113271221B (zh) * 2021-04-28 2022-05-24 北京邮电大学 网络能力开放方法、系统及电子设备
US11641630B2 (en) * 2021-05-18 2023-05-02 Qualcomm Incorporated Time-sensitive networking support over sidelink
US11546243B1 (en) 2021-05-28 2023-01-03 T-Mobile Usa, Inc. Unified interface and tracing tool for network function virtualization architecture
US11509704B1 (en) 2021-05-28 2022-11-22 T-Mobile Usa. Inc. Product validation based on simulated enhanced calling or messaging communications services in telecommunications network
US11490432B1 (en) * 2021-05-28 2022-11-01 T-Mobile Usa, Inc. Unified query tool for network function virtualization architecture
US11716252B2 (en) 2021-07-14 2023-08-01 Oracle International Corporation Methods, systems, and computer readable media for generating network function (NF) set load information aware NF discovery response
US11671369B2 (en) * 2021-07-14 2023-06-06 Oracle International Corporation Methods, systems, and computer readable media for generating and using network function (NF) set overload control information (OCI) and load control information (LCI) at service communication proxy (SCP)
US11558466B1 (en) 2021-07-19 2023-01-17 Cisco Technology, Inc. Packet forwarding control protocol (PFCP) message service using a remote procedure call (RPC) based protocol suitable for PFCP connection sharing
US11895504B2 (en) * 2021-09-03 2024-02-06 Cisco Technology, Inc. Federated multi-access edge computing availability notifications
US11936736B2 (en) * 2021-11-10 2024-03-19 Electronics And Telecommunications Research Institute Interworking method between different 5G multi-access edge computing (MEC) platforms using common application programing interface framework (CAPIF)
US11765030B2 (en) * 2021-12-02 2023-09-19 Oracle International Corporation Methods, systems, and computer readable media for registering application functions using common application programming interface framework
US11709725B1 (en) 2022-01-19 2023-07-25 Oracle International Corporation Methods, systems, and computer readable media for health checking involving common application programming interface framework
CN116847427A (zh) * 2022-03-25 2023-10-03 中国电信股份有限公司 用户面流量路由配置方法、装置和系统
EP4262269A1 (de) * 2022-04-14 2023-10-18 Mitsubishi Electric R&D Centre Europe B.V. Ursp-aktualisierung im grenz-szenario
US20230370825A1 (en) * 2022-05-10 2023-11-16 Electronics And Telecommunications Research Institute Method of performing dynamic edge application server (eas) instantiation triggering and apparatus for performing the same
CN114900522B (zh) * 2022-05-11 2024-03-12 重庆大学 一种基于蒙特卡洛树搜索的服务功能链迁移方法
WO2023244311A1 (en) * 2022-06-16 2023-12-21 Microsoft Technology Licensing, Llc Managing cloud-native virtual network functions
US20240031254A1 (en) * 2022-07-20 2024-01-25 Wheel Health Inc. Scheduling method and system for middleware-mediated user-to-user service
KR20240021529A (ko) * 2022-08-10 2024-02-19 삼성전자주식회사 무선 통신 시스템에서 단말 성능에 기반한 ar 컨텐츠 서비스를 제공하기 위한 장치 및 방법
WO2024076126A1 (ko) * 2022-10-04 2024-04-11 삼성전자주식회사 에지 컴퓨팅 연동 컨텍스트 재배치 방법
US11995478B2 (en) * 2022-10-06 2024-05-28 Confluent, Inc. Cluster deployment across multiple private cloud environments
CN115604013B (zh) * 2022-10-21 2023-05-23 北京珞安科技有限责任公司 一种工业数据交互平台及交互方法
US11972310B1 (en) * 2023-01-16 2024-04-30 Sap Se Multi-resource operations in an analytics computing system
CN117014487B (zh) * 2023-09-28 2023-12-15 中国电子科技集团公司第二十八研究所 一种面向高机动环境的终端自适应就近连接边缘云方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9755858B2 (en) * 2014-04-15 2017-09-05 Cisco Technology, Inc. Programmable infrastructure gateway for enabling hybrid cloud services in a network environment
US10110500B2 (en) * 2016-11-03 2018-10-23 Ciena Corporation Systems and methods for management of cloud exchanges
US10904323B2 (en) * 2017-06-08 2021-01-26 F5 Networks, Inc. Methods for server load balancing in a cloud environment using dynamic cloud pricing and devices thereof
US10523493B2 (en) * 2018-04-30 2019-12-31 Oracle International Corporation Cross-cloud operation management
US20220038554A1 (en) * 2020-08-21 2022-02-03 Arvind Merwaday Edge computing local breakout

Also Published As

Publication number Publication date
KR20220092366A (ko) 2022-07-01
US20220086218A1 (en) 2022-03-17

Similar Documents

Publication Publication Date Title
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
US20220014963A1 (en) Reinforcement learning for multi-access traffic management
US20220038902A1 (en) Technologies for radio equipment cybersecurity and multiradio interface testing
US11924060B2 (en) Multi-access edge computing (MEC) service contract formation and workload execution
US11751042B2 (en) Multi-access edge computing service for mobile user equipment method and apparatus
US11627444B2 (en) Vehicle-to-everything session and service continuity in automotive edge computing systems
US11736942B2 (en) Multi-domain trust establishment in edge cloud architectures
US11234204B2 (en) Server selection for vehicle communications and applications
US11244242B2 (en) Technologies for distributing gradient descent computation in a heterogeneous multi-access edge computing (MEC) networks
US11423254B2 (en) Technologies for distributing iterative computations in heterogeneous computing environments
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
DE102021208087A1 (de) Kontextbewusstes Handover
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
DE102022202872A1 (de) Neuronales graphennetzwerk und bestärkendes-lernen-techniken zur verbindungsverwaltung
DE112019002913T5 (de) Verwaltung von zuweisungen bevorzugter kanäle zwischendrahtloskommunikationsbändern
US20220232423A1 (en) Edge computing over disaggregated radio access network functions
DE112020003766T5 (de) Linkleistungsprognose und Medienstreaming-Technologien
DE112020002323T5 (de) Container-first-architektur
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
DE112020007003T5 (de) Multi-funkzugangstechnologie-verkehrsverwaltung
DE102022211605A1 (de) Zuverlässigkeitsverbesserungen für mehrfachzugangsverkehrsverwaltung
US20230006889A1 (en) Flow-specific network slicing
DE102022211529A1 (de) Methoden zum einreihen und neuordnen für mehrfachzugangsverwaltungsdienste
DE102022202963A1 (de) Verkehrsaufteilungs- und neuübertragungsmechanismen mit schichtübergreifender und zugangsübergreifender technologie