DE102020202398A1 - Edge-server-cpu mit dynamischer deterministischer skalierung - Google Patents

Edge-server-cpu mit dynamischer deterministischer skalierung Download PDF

Info

Publication number
DE102020202398A1
DE102020202398A1 DE102020202398.0A DE102020202398A DE102020202398A1 DE 102020202398 A1 DE102020202398 A1 DE 102020202398A1 DE 102020202398 A DE102020202398 A DE 102020202398A DE 102020202398 A1 DE102020202398 A1 DE 102020202398A1
Authority
DE
Germany
Prior art keywords
network
processor cores
virtual
mec
edge
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
DE102020202398.0A
Other languages
English (en)
Inventor
Vasudevan Srinivasan
Christopher MacNamara
Edwin Verplanke
Lokpraveen Mosur
Nikhil Gupta
Sarita Maini
Stephen T. Palermo
Abhishek Khade
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 DE102020202398A1 publication Critical patent/DE102020202398A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7867—Architectures of general purpose stored program computers comprising a single central processing unit with reconfigurable architecture
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/084—Load balancing or load distribution among network function virtualisation [NFV] entities; among edge computing entities, e.g. multi-access edge computing
    • 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/4557—Distribution of virtual machine instances; Migration and load balancing
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/501—Performance criteria
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Verfahren, Vorrichtungen, Systeme und maschinenlesbare Speicherungsmedien eines Edge-Computing-Geräts durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung werden offenbart. Eine Verarbeitungsschaltungsanordnung beinhaltet eine Verarbeitungsschaltung mit Prozessorkernen, die mit einer Mittenbasisfrequenz arbeiten, und Speicher. Der Speicher beinhaltet Anweisungen zum Konfigurieren der Verarbeitungsschaltung, um einen ersten Satz der Prozessorkerne der CPU zu konfigurieren, um den Betrieb mit der Mittenbasisfrequenz auf den Betrieb mit einer ersten modifizierten Basisfrequenz umzuschalten, und einen zweiten Satz der Prozessorkerne zu konfigurieren, um den Betrieb mit der Mittenbasisfrequenz auf den Betrieb mit einer zweiten modifizierten Basisfrequenz umzuschalten. Ein gleicher Prozessorkern innerhalb des ersten Satzes oder des zweiten Satzes kann dazu konfiguriert sein, zwischen der ersten modifizierten Basisfrequenz oder der zweiten modifizierten Basisfrequenz umzuschalten.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht den Nutzen der Priorität zu den folgenden vorläufigen Anmeldungen:
  • Vorläufige Patentanmeldung der Vereinigten Staaten, Seriennummer 62/827,494, eingereicht am 1. April 2019, und betitelt „EDGE-SERVER-CPU MIT DYNAMISCHER DETERMINISTISCHER SKALIERUNG“; und
    vorläufige Patentanmeldung der Vereinigten Staaten, Seriennummer 62/830,946, eingereicht am 8. April 2019, und betitelt „EDGE-SERVER-CPU MIT DYNAMISCHER DETERMINISTISCHER SKALIERUNG“.
  • Jede der oben aufgelisteten vorläufigen Patentanmeldungen wird hierin durch Bezugnahme in ihrer Gesamtheit eingegliedert.
  • TECHNISCHES GEBIET
  • Die hierin beschriebenen Ausführungsformen beziehen sich im Allgemeinen auf Datenverarbeitungs-, Netzwerkkommunikations- und Kommunikationssystem-Implementierungen, und insbesondere auf Techniken zum Implementieren einer Edge-Server-Central-Processing-Unit (CPU), die dynamische deterministische Skalierung von Prozessorkernen unterstützt.
  • HINTERGRUND
  • Edge-Computing bezieht sich auf einem allgemeinem Niveau auf den Übergang von Rechen- und Speicherungsressourcen näher an Endpunktgeräte (zum Beispiel Verbraucher-Computing-Geräte, Benutzerausrüstung, usw.), um die Gesamtbetriebskosten zu optimieren, die Anwendungslatenz zu reduzieren, die Service-Fähigkeiten zu verbessern, und die Konformität mit Sicherheits- oder Datenschutzanforderungen zu verbessern. In einigen Szenarien kann Edge-Computing einen Cloud-ähnlichen verteilten Service bereitstellen, der Orchestrierung und Management für Anwendungen unter vielen Typen von Speicherungs- und Rechenressourcen anbietet. Infolgedessen wurden einige Implementierungen von Edge-Computing als die „Edge Cloud“ oder der „Fog“ bezeichnet, da leistungsstarke Computing-Ressourcen, die bisher nur in großen entfernt angeordneten Datenzentren verfügbar waren, näher an Endpunkte bewegt und für die Verwendung durch Verbraucher an dem „Rand“ des Netzwerks verfügbar gemacht wurden.
  • Edge-Computing-Anwendungsfälle in Mobilfunknetzwerkeinstellungen wurden für die Integration in Multi-Access-Edge-Computing (MEC) - Ansätze, auch bekannt als „Mobile-Edge-Computing“, entwickelt. MEC-Ansätze sind so entworfen, dass sie Anwendungsentwicklern und Inhaltsanbietern den Zugang zu Computing-Fähigkeiten und eine Information-Technology (IT) -Service-Umgebung in dynamischen Mobilfunknetzwerkeinstellungen an dem Rand des Netzwerks ermöglichen. Durch die Industry-Specification-Group (ISG) des European-Telecommunications-Standards-Institute (ETSI) wurden begrenzte Standards entwickelt, in einem Versuch, gemeinsame Schnittstellen für den Betrieb von MEC-Systemen, -Plattformen, -Hosts, -Services und - Anwendungen zu definieren.
  • Edge-Computing, MEC und verwandte Technologien versuchen, eine verringerte Latenz, erhöhte Reaktionsfähigkeit und mehr verfügbare Rechenleistung bereitzustellen, als bei herkömmlichen Cloud-Network-Services und Wide-Area-Network-Verbindungen angeboten. Die Integration von Mobilität und dynamisch gestarteten Services in einige Anwendungsfälle für mobile Verwendung und Geräteverarbeitung hat jedoch zu Beschränkungen bei der Orchestrierung, der funktionalen Koordination und dem Ressourcen-Management geführt, insbesondere in komplexen Mobilitätseinstellungen, wo viele Teilnehmer (Geräte, Hosts, Mandanten, Service-Anbieter, Bediener) einbezogen werden. Edge-Computing und MEC-Ansätze, insbesondere wenn zur Bereitstellung von Mobilfunkteilnehmer-Services verwendet, sind typischerweise auf die Menge an Rechenkapazität und Leistungsbeschränkungen des jeweiligen Edge-Servers beschränkt. Mobile Services, einschließlich Sprache, Daten und Video, unterliegen außerdem Latenz- und Bandbreitenanforderungen, die zur Bereitstellung der Service-Qualität für Endbenutzer erforderlich sind. Das Scoping und die Dimensionierung von Edge-Servern für eine bestimmte Anzahl von Teilnehmern unter Berücksichtigung der Unsicherheit hinsichtlich der tatsächlichen Services, die die Mobilfunkteilnehmer ausführen werden, erhöht auch die Herausforderung richtiger Dimensionierungslösungen. Insgesamt wird durch diese Offenbarung eine größere Rechenkapazität angesprochen, während die deterministische Latenz innerhalb einer bestimmten Leistungshüllkurve aufrechterhalten wird. Speziell wird durch das Ermöglichen, dass eine Gruppe von CPU-Kernen mit einer höheren deterministischen Frequenz ohne größere Leistungssteigerung ausgeführt wird, eine zusätzliche Kapazität für Support-Bursts von Services für Mobilfunkteilnehmer, die denselben Edge-MEC-Server benutzen, ermöglicht.
  • 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 Buchstabenanhängen können unterschiedliche Fälle ähnlicher Komponenten darstellen. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen veranschaulicht, in denen gilt:
    • 1A veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing, gemäß einem Beispiel;
    • 1B veranschaulicht eine MEC-Kommunikationsinfrastruktur mit einem gemeinsamen Core-Network, wobei die MEC-Infrastruktur eine oder mehrere Edge-Server-CPU mit dynamischer deterministischer Skalierung verwendet, gemäß einem Beispiel;
    • 2A veranschaulicht eine beispielhafte Cellular-Internet-of-Things (CIoT) - Netzwerkarchitektur mit einem MEC-Host durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel;
    • 2B veranschaulicht eine beispielhafte Service-Capability-Exposure-Function (SCEF), die durch die CIoT-Netzwerkarchitektur von 2B verwendet wird, gemäß einem Beispiel;
    • 3A ist ein vereinfachtes Diagramm einer beispielhaften Next-Generation (NG) - Systemarchitektur mit einem MEC-Host durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel;
    • 3B veranschaulicht eine beispielhafte funktionale Aufteilung zwischen einem Next-Generation-Radio-Access-Network (NG-RAN) und dem 5G-Core-Network (5GC) in Verbindung mit der NG-Systemarchitektur von 3A, gemäß einem Beispiel;
    • 3C und 3D veranschaulichen Non-Roaming-5G-Systemarchitekturen mit einem MEC-Host durch Verwenden einer Edge-Server-CPU, gemäß einem Beispiel.
    • 3E veranschaulicht Komponenten einer beispielhaften 5G-NR-Architektur mit einer Control-Unit-Control-Plane (CU-CP) - Control-Unit-User-Plane (CU-UP) -Trennung, gemäß einem Beispiel;
    • 3F veranschaulicht Beispiele von Netzwerk-Slices, gemäß einem Beispiel;
    • 4A veranschaulicht eine MEC Netzwerkarchitektur, die zur Unterstützung einer Edge-Server-CPU mit dynamischer deterministischer Skalierung modifiziert ist, gemäß einem Beispiel;
    • 4B veranschaulicht eine MEC-Referenzarchitektur in einer Network-Function-Virtualization (NFV) -Umgebung durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel;
    • 5 veranschaulicht eine Domänentopologie für jeweilige Internet-of-Things (IoT) -Netzwerke, die durch Verbindungen mit jeweiligen Gateways gekoppelt sind, gemäß einem Beispiel;
    • 6 veranschaulicht ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von Edge-/IoT-Verarbeitungsgeräten, die als Fog-Geräte an dem Rand des Cloud-Computing-Netzwerks arbeiten, gemäß einem Beispiel;
    • 7 veranschaulicht ein Blockdiagramm eines Cloud-Computing-Netzwerks in Kommunikation mit einer Anzahl von Edge-/IoT-Verarbeitungsgeräten, gemäß einem Beispiel;
    • 8 stellt einen Überblick über Schichten verteilter Berechnungen bereit, die in einem Edge-Computing-System eingesetzt werden, gemäß einem Beispiel;
    • 9 stellt einen Überblick über beispielhafte Komponenten für die Berechnung bereit, die an einem Rechenknoten in einem Edge-Computing-System eingesetzt werden, gemäß einem Beispiel;
    • 10 stellt einen weiteren Überblick über beispielhafte Komponenten innerhalb eines Computing-Geräts in einem Edge-Computing-System zum Implementieren der hierin beschriebenen Techniken (zum Beispiel Operationen, Prozesse, Verfahren und Methoden) bereit, gemäß einem Beispiel;
    • 11 veranschaulicht eine 3GPPbasierte 5G-Systemarchitektur durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, und Beispiele für das Abbilden von MEC-Entitäten zu einigen Komponenten des 5G-Systems (nämlich AF und UPF), gemäß einem Beispiel;
    • 12 veranschaulicht die Nutzung von Prozessorkernen mit derselben Basisfrequenz, gemäß einem Beispiel;
    • 13 veranschaulicht die Nutzung von zwei verschiedenen Sätzen von Prozessorkernen, wobei die zwei Sätze unterschiedliche Basisfrequenzen haben, gemäß einem Beispiel;
    • 14 veranschaulicht ein Host-Gerät, das eine Edge-Server-CPU mit dynamischer Basisfrequenz und Kernnutzung verwendet, gemäß einem Beispiel;
    • 15 veranschaulicht das Bewegen von Teilnehmeranwendungen zwischen Kernen mit niedrigerer Frequenz und Kernen mit höherer Frequenz basierend auf einem vorgegebenen Schwellenwert, gemäß einem Beispiel;
    • 16 veranschaulicht die Cloudifizierung eines Netzwerks durch Verwenden eines Edge-Servers mit einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel;
    • 17 veranschaulicht einen Vergleich zwischen einer Legacy-CPU mit fester Kernnutzung und einer Edge-Server-CPU mit dynamischer deterministischer Skalierung durch Verwenden mehrerer Sätze von Kernen, wobei jeder Satz eine unterschiedliche Basisfrequenz verwendet, gemäß einem Beispiel;
    • 18 veranschaulicht einen 5G-Edge-Server und einen 5G-Core-Server, die mehrere Virtualized-Network-Functions (VNF) auf Kernen mit niedrigerer Frequenz (L) oder Kernen mit höherer Frequenz (H) ausführen, gemäß einem Beispiel;
    • 19 veranschaulicht einen 5G-Edge-Server und einen 5G-Core-Server, die VNF ausführen, die L-Kerne und H-Kerne umspannen können, gemäß einem Beispiel; und
    • 20 veranschaulicht 5G-Edge-/Core-Server, die VNF durch Verwenden von Prozessorkernen ausführen, die in einer Kernbasisfrequenz arbeiten können, oder eine Kombination von hohen und niedrigen Basisfrequenzen durch Verwenden von CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung werden Verfahren, Konfigurationen und verwandte Vorrichtungen für eine Edge-Computing-Server-CPU offenbart, die mit einer dynamischen deterministischen Skalierung von Prozessorkernressourcen konfiguriert ist. Diese können einer Vielzahl von Anwendungsfällen nützen, wie zum Beispiel der Netzwerkkommunikation der fünften Generation (5G) zwischen Automobilgeräten, einschließlich jener Anwendungsfälle, die als Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) und Vehicle-to-Everything (V2X) bezeichnet werden. Wie bei den meisten Edge-Computing- und MEC-Installationen, ist es das Ziel bei den vorliegenden Konfigurationen, die Anwendungsendpunkte so nahe wie möglich an die Fahrzeugumgebung oder andere Endpunkte zu bringen, und die Rechenressourcen sowie die durch ein oder mehrere Netzwerk (zum Beispiel 5G) -Slices verwendeten Ressourcen, einschließlich der Verantwortlichkeit für die Ressourcennutzung durch Verwenden von Blockchain-Rückverfolgbarkeitstechniken, dynamisch anzupassen, um Services mit geringer Latenz oder hoher Bandbreite mit optimaler QoS zu ermöglichen. Diese Systeme und Techniken können in virtualisierten Umgebungen, die innerhalb verschiedener Typen von MEC-, Network-Function-Virtualization (NFV)-, Cloud-Native-, oder vollständig virtualisierten 5G-Netzwerkumgebungen implementiert werden können, implementiert werden oder diese erweitern.
  • Die vorliegenden Techniken und Konfigurationen können in Verbindung mit vielen Aspekten aktueller Netzwerksysteme verwendet werden, werden jedoch unter Bezugnahme auf IoT-, MEC- und NFV-Einsätze bereitgestellt. Die vorliegenden Techniken und Konfigurationen können speziell für die in ETSI GS MEC-003 „Mobile Edge Computing (MEC); Framework- und Referenzarchitektur“ (zum Beispiel V2.0.3); ETSI GS NFV-SEC 013 „Network Functions Virtualization (NFV) Release 3; Sicherheit; Sicherheitsmanagement und - Überwachung“ (zum Beispiel Version 3.1.1) und verwandten MEC-, NFV- oder vernetzten betrieblichen Implementierungen veröffentlichten Standards und Ansätze relevant sein (müssen es aber nicht sein). Jedoch kann, während die vorliegenden Techniken und Konfigurationen erhebliche Vorteile für MEC-Architekturen und andere IoT-Gerätenetzwerkarchitekturen bieten können, die Anwendbarkeit der vorliegenden Techniken und Konfigurationen auf jegliche Anzahl von Edge-Computing-Geräten oder Fog-Computing-Plattformen erweitert werden.
  • Das Folgende stellt eine detaillierte Diskussion dieser Techniken innerhalb spezifischer Systeme und Services bereit, die jedoch auf den größeren Zusammenhang von IoT-, Fog-Netzwerk- und Edge-Computing-Einsätzen anwendbar sind. Ferner stellen die offenbarten MEC-Architekturen und Service-Bereitstellungsbeispiele ein veranschaulichendes Beispiel eines Fog-Geräts oder Fog-Systems bereit, es können jedoch viele andere Kombinationen und Layouts von an dem Rand eines Netzwerks platzierten Geräten und Systemen bereitgestellt werden. Ferner können sich die hierin offenbarten Techniken auf andere IoT- und Netzwerkkommunikationsstandards und Konfigurationen, sowie andere Zwischenverarbeitungsentitäten und Architekturen beziehen.
  • In einigen Aspekten können hierin offenbarte Techniken in Verbindung mit einer Edge-Server-CPU verwendet werden, die dazu geeignet ist, Prozessorkernressourcen zu skalieren, um flexible deterministische Computing-Ressourcen für die Kapazität von Kommunikations-Service-Anbietern, insbesondere für die Entwicklung von 5G-Architekturen, bereitzustellen. 5G-Architekturen, Kapazitätsplanung und Standards entwickeln sich weiter. Communication-Service-Provider (CoSP) können damit herausgefordert werden, wieviel Rechenkapazität an dem Rand und in dem Kern angebracht werden muss. 5G erfordert eine geringe Gerätelatenz (1-4ms) und eine hohe Gerätedichte (zum Beispiel eine Million verbundene Geräte pro Quadratkilometer), die feste und drahtlose Geräte unterstützen.
  • Hierin offenbarte Techniken beinhalten eine Workload-optimierte Edge-Server-CPU, die einen Mechanismus zum Unterstützen von mindestens zwei Gruppen (oder Sätzen) von Kernen mit unterschiedlichen garantierten Frequenzen und ein Verfahren zum Orchestrieren von Kommunikationsdienstleistungsanwendungen (Virtual-Network-Functions oder VNF) enthält, was erforderlich ist, um die Flexibilität zu bieten, das Problem unklarer Kapazitätsanforderungen für 5G-Architekturen anzusprechen. Service-Anbieter können hierin offenbarte Techniken verwenden, um die Notwendigkeit einer Überkompensation wegen unbekannter Bedürfnisse von Mobilfunkteilnehmern zu reduzieren und die Netzwerkkapazität für die Effizienz dynamisch zu reduzieren. Insbesondere können unterschiedliche Sätze derselben Prozessorkerne in derselben CPU dazu ausgelegt sein, mit zwei (oder mehr) unterschiedlichen Basisfrequenzen (zum Beispiel einer hohen Basisfrequenz und einer niedrigen Basisfrequenz) zu arbeiten, und NFV-Instanzen können instanziiert werden (zum Beispiel durch Verwenden virtueller Ressourcen) durch Verwenden derselben Prozessorkerne in derselben CPU, die mit der niedrigen Basisfrequenz, der hohen Basisfrequenz oder den Prozessorkernen arbeitet, die mit beiden Basisfrequenzen arbeiten. In dieser Hinsicht kann derselbe Prozessorkern in derselben CPU auf ein deterministisches Leistungsniveau (das heißt einen deterministischen Turbo) skaliert werden und dazu ausgelegt sein, mit einer unterschiedlichen Basisfrequenz (zum Beispiel niedrig, hoch oder jeglicher anderen Anzahl von Basisfrequenzen) zu arbeiten.
  • Zum Beispiel können alle Prozessorkerne einer CPU ursprünglich dazu ausgelegt sein, mit einer Mittenbasisfrequenz zu arbeiten. Als Reaktion auf eine Anforderung/einen Befehl für einen Kernbetrieb mit mehreren Frequenzen (zum Beispiel um eine oder mehrere der hierin diskutierten Prozessorkern-Management- und Konfigurationsfunktionalitäten auszulösen), ist ein erster Satz der Prozessorkerne (auch bezeichnet als „Kerne mit niedriger Priorität“) dazu ausgelegt, mit einer ersten modifizierten Basisfrequenz zu arbeiten, und ein zweiter Satz der Prozessorkerne (auch bezeichnet als „Kerne mit hoher Priorität“) ist dazu ausgelegt, mit einer zweiten modifizierten Basisfrequenz zu arbeiten (zum Beispiel ist die erste modifizierte Basisfrequenz niedriger als die Mittenbasisfrequenz, und die zweite modifizierte Basisfrequenz ist höher als die Mittenbasisfrequenz). Zusätzlich können Telemetrieparameter (zum Beispiel eine Anzahl aktiver Netzwerkteilnehmer, die aktuell mit einem Netzwerk-Host kommunizieren, minimale Netzwerkressourcenanforderungen für eine MEC-Anwendung oder virtuelle CPU (zum Beispiel für eine virtuelle Maschine), die eine NFV-Instanz als einen virtuellen Service ausführt, einschließlich der Mindestanforderungen an den Prozessorkern und der Basisfrequenzanforderungen des Prozessorkerns, der Bandbreitenverwendung, usw.) wieder abgerufen und verwendet werden, um einen oder mehrere der Kerne mit niedriger Priorität und/oder Kerne mit hoher Priorität als virtuelle CPU-Kerne zum Ausführen der MEC-Anwendung oder NFV-Instanz zu pinnen (oder zuzuweisen). Die Verwendung der Kerne kann dynamisch angepasst werden (zum Beispiel kann die Ausführung der instanziierten NFV-Instanz von hoch nach niedrig oder umgekehrt bewegt werden), zum Beispiel basierend auf der Nutzung eines der NFV zugeordneten Netzwerk-Services, wie durch den der NFV zugeordneten Netzwerkverkehr, die Anzahl der Teilnehmer, die dem durch die NFV bereitgestellten Netzwerk-Service zugeordnet sind, eine Anzahl von Prozessorkernen, die zum Ausführen der NFV verwendet werden, und so weiter, angezeigt. In dieser Hinsicht kann die Leistungsnutzung durch die Prozessorkerne bei Funktionieren mit der Mittenbasisfrequenz ungefähr dieselbe sein, wie bei Aktivierung der Kerne mit hoher und niedriger Priorität, aber die Verarbeitungseffizienz bei Verwendung der Kerne mit hoher und niedriger Priorität ist höher, als wenn alle Kerne mit der Mittenbasisfrequenz arbeiten.
  • 1A ist Blockdiagramm 100A, das eine Übersicht über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als eine „Edge-Cloud“ bezeichnet wird. Wie gezeigt, ist Edge-Cloud 170 an einem Randstandort platziert, gemeinsam mit zum Beispiel Basisstation 176, lokalem Verarbeitungs-Hub 178 oder Zentrale 172, und kann somit mehrere Entitäten, Geräte und Ausrüstungsinstanzen beinhalten. Die Edge-Cloud 170 ist viel näher an Endpunkt (Verbraucher und Hersteller) -Datenquellen 180 (zum Beispiel autonome Fahrzeuge 182, Benutzergeräte 184, Geräte für Unternehmen und Industrie 186, Videoaufnahmegeräte 188, Drohnen 190, Geräte für intelligente Städte und Gebäude 192, Sensoren und IoT-Geräte 194, usw.) platziert als Cloud-Datenzentrum 174. Rechen-, Speicher- und Speicherungsressourcen (einschließlich Prozessorkernressourcen durch Verwenden der hierin diskutierten Kernskalierungstechniken), die an den Rändern in der Edge-Cloud 170 angeboten werden, sind kritisch für die Bereitstellung von Antwortzeiten mit extrem geringer Latenz für Services und Funktionen, die durch die Endpunktdatenquellen 180 verwendet werden, und reduzieren den Netzwerkrücktransportverkehr von der Edge-Cloud 170 zu dem Cloud-Datenzentrum 174, wodurch unter anderen Vorteilen der Energieverbrauch und die allgemeine Netzwerknutzung verbessert werden.
  • Rechenleistung, Speicher und Speicherung sind knappe Ressourcen, und nehmen im Allgemeinen abhängig von dem Randstandort ab (zum Beispiel sind weniger Verarbeitungsressourcen auf Verbraucherendgeräten verfügbar als an einer Basisstation oder in einer Zentrale). Je näher der Randstandort jedoch zu dem Endpunkt (zum Beispiel UE) ist, desto mehr werden Platz und Leistung eingeschränkt. Daher versucht Edge-Computing als ein allgemeines Designprinzip, die Anzahl der für Netzwerk-Services erforderlichen Ressourcen zu minimieren, indem mehr Ressourcen verteilt werden, die sowohl geografisch als auch für In-Netzwerkzugangszeit näher platziert sind.
  • Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere potenzielle Einsätze abdeckt, und spricht Beschränkungen an, die einige Netzwerkbetreiber oder Service-Anbieter in ihren eigenen Infrastrukturen haben können. Diese beinhalten eine Variation von Konfigurationen basierend auf dem Randstandort (da Ränder auf einer Basisstationsebene beispielsweise eine eingeschränktere Leistung haben können); Konfigurationen basierend auf dem Typ der Berechnung, des Speichers, der Speicherung, der Struktur, der Beschleunigung oder ähnlichen Ressourcen, die für Randstandorte, Standortlagen oder Standortgruppen verfügbar sind; auf den Service-, Sicherheits- und Management- und Orchestrierungsfähigkeiten; und auf verwandten Zielen zum Erreichen der Verwendbarkeit und Leistung von End-Services.
  • Edge-Computing ist ein sich entwickelndes Paradigma, bei dem das Computing am oder näher zu dem „Rand“ eines Netzwerks ausgeführt wird, typischerweise durch die Verwendung einer Rechenplattform, die an Basisstationen, Gateways, Netzwerk-Routern oder anderen Geräten implementiert ist, die viel näher an Endgeräten sind, die die Daten produzieren und verbrauchen. Zum Beispiel können Edge-Gateway-Server mit Pools von Speicher- und Speicherungsressourcen ausgestattet sein, um Berechnungen in Echtzeit für Anwendungsfälle mit geringer Latenz (zum Beispiel autonomes Fahren oder Videoüberwachung) für verbundene Kundengeräte auszuführen. Oder es können als ein Beispiel Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Service-Workloads für verbundene Benutzerausrüstung direkt zu verarbeiten, ohne Daten über Rücktransportnetzwerke weiter zu kommunizieren. Oder es kann als ein anderes Beispiel die Netzwerk-Management-Hardware der Zentrale durch Computer-Hardware ersetzt werden, die virtualisierte Netzwerkfunktionen ausführt und Rechenressourcen für die Ausführung von Services und Verbraucherfunktionen für verbundene Geräte anbietet. Diese und andere Szenarien können die Verwendung einer koordinierten Beschleunigung, wie in der Diskussion unten bereitgestellt, einbeziehen.
  • 1B veranschaulicht eine MEC-Kommunikationsinfrastruktur mit einem gemeinsamen Core-Network, wobei die MEC-Infrastruktur eine oder mehrere Edge-Server-CPU mit dynamischer deterministischer Skalierung verwendet, gemäß einem Beispiel. Die Verbindungen, die durch eine Form einer gestrichelten Linie (wie in der Legende in 1B angegeben) dargestellt sind, können gemäß einer Spezifikation von einer ETSI-MEC-Standard-Familie definiert werden.
  • MEC-Kommunikationsinfrastruktur 100B kann Entitäten von einer MEC-basierten Architektur sowie Entitäten von einer auf einem Third-Generation-Partnership-Project (3GPP) basierenden Architektur beinhalten. Zum Beispiel kann die MEC-Kommunikationsinfrastruktur 100B mehrere MEC-Hosts, wie zum Beispiel MEC-Hosts 102 und 104, MEC-Plattformmanager 106 und MEC-Orchestrator 108 beinhalten. Die 3GPP-basierten Entitäten können zentrales Core-Network (CN) 110, das über Netzwerk 112 (zum Beispiel das Internet) mit Anwendungsserver 114 verbunden ist, sowie Radio-Access-Networks (RAN), die durch Basisstationen 148 und 150 dargestellt werden, die mit entsprechenden Benutzerausrüstungen (UE) 152 und 154 gekoppelt sind, beinhalten. Die Basisstationen 148 und 150 können evolved Node-B (eNB), Next-Generation-Node-B (gNB) oder andere Typen von Basisstationen beinhalten, die in Verbindung mit einer 3GPP-Familie von Drahtlosstandards oder einem anderen Typ von Drahtlosstandard arbeiten.
  • In einigen Aspekten kann die MEC-Kommunikationsinfrastruktur 100B durch unterschiedliche Netzwerkbetreiber in demselben Land und/oder in unterschiedlichen Ländern durch Verwenden unterschiedlicher Netzwerkverkehrstypen implementiert werden. Zum Beispiel kann das der Basisstation 148 zugeordnete Funkzugangsnetz (mit Abdeckungsbereich 149) innerhalb eines ersten Public-Land-Mobile-Network (PLMN) sein (das heißt einem ersten Mobilfunk oder - Betreiber und einem ersten Netzwerkverkehrstyp zugeordnet sein), und die Basisstation 150 (mit Abdeckungsbereich 151) kann innerhalb eines zweiten Public-Land-Mobile-Network (PLMN) sein (das heißt einem zweiten Mobilfunk-Service-Anbieter oder -Betreiber und einem zweiten Netzwerkverkehrstyp zugeordnet sein). Wie hierin verwendet, sind die Begriffe „Mobilfunk-Service-Anbieter“ und „Mobilfunk-Service-Betreiber“ austauschbar.
  • In dieser Hinsicht kann die MEC-Kommunikationsinfrastruktur 100B einem Mehrbetreiberszenario zugeordnet sein, das aus zwei Abdeckungsbereichen 149 und 151 besteht, wobei Kommunikations-Services (zum Beispiel V2X-Services) bereitgestellt werden können, wobei jeder Abdeckungsbereich durch einen Mobilfunk-Service-Betreiber betrieben wird. Zusätzlich kann jede der UE 152 und 154 für den Netzwerk-Slice-Betrieb konfiguriert sein, wobei jede UE einen oder mehrere Typen von Netzwerk-Slices verwenden kann, die zum Beispiel durch das Core-Network 110 durch Verwenden von Slice-Management-Funktionalität 162 in Koordination mit einer oder mehreren Entitäten der MEC-Kommunikationsinfrastruktur 100B konfiguriert sind.
  • Die Verbindungen mit durchgezogenen Linien in 1B stellen Nicht-MEC-Verbindungen dar, wie zum Beispiel die Nutzung von 3GPP-Mobilfunknetzwerkverbindungen S1, S1-AP, usw. Andere Verbindungstechniken (zum Beispiel Protokolle) und Verbindungen können ebenfalls verwendet werden. Dementsprechend sind in dem Szenario von 1B die System-Entitäten (zum Beispiel der MEC-Orchestrator 108, der MEC-Plattformmanager 106, die MEC-Hosts 102, 104) durch MEC (oder NFV) -Logikverbindungen verbunden (angezeigt mit gestrichelten Linien), zusätzlich zu Netzwerkinfrastrukturverbindungen (zum Beispiel ein 5G-Long-Term-Evolution (LTE) -Netzwerk, wie zum Beispiel zwischen den UE 152, 154, den eNBs 148, 150, einem CN-Standort 110, usw., bereitgestellt) (angezeigt mit durchgezogenen Linien). Eine weitere Verbindung zu Cloud-Services (zum Beispiel Zugang zu einem Anwendungsserver 114 über das Netzwerk 112) kann auch über Rücktransportnetzwerkinfrastrukturverbindungen verbunden sein.
  • Hierin offenbarte Techniken gelten für 2G/3G/4G/LTE/LTE-A (LTE Advanced) und 5G-Netzwerke, wobei die Beispiele und Aspekte durch Verwenden von 4G/LTE-Netzwerken offenbart werden. In Aspekten kann das CN 110 ein Evolved-Packet-Core (EPC) -Netzwerk, ein NextGen-Packet-Core (NPC) -Netzwerk (zum Beispiel ein 5G-Netzwerk) oder ein anderer Typ von CN (zum Beispiel wie unter Bezugnahme auf die 2A-3E veranschaulicht) sein. In einem EPC (Evolved-Packet-Core oder Distributed-EPC), das 4G/LTE zugeordnet ist, kann das CN 110 Serving-Gateway (S-GW oder SGW) 138, Packet-Data-Network (PDN) -Gateway (P-GW oder PGW) 140, Mobility-Management-Entity (MME) 142 und Home-Subscriber-Server (HSS) 144, der mit V2X-Steuerungsfunktion 146 gekoppelt ist, beinhalten. In 5G wird das Core-Network als das NextGen-Packet-Network (NPC) bezeichnet. In NPC (und wie in den 3A-3D veranschaulicht) wird das S/P-GW durch eine User-Plane-Function (UPF) ersetzt, und die MME wird durch zwei einzelne funktionelle Komponenten, die Access-Management-Function (AMF) und die Session-Management-Function (SMF), ersetzt. Der 4G-HSS ist in 5G in unterschiedliche Entitäten aufgeteilt: die Authentication-Server-Function (AUSF) und das Universal-Data-Management (UDM), wobei die Teilnahmedaten über die Universal-Data-Management (UDM) -Funktion verwaltet werden. In EPC kann die S1-Schnittstelle in zwei Teile aufgeteilt werden: die S1-U (Benutzerebene) -Schnittstelle, die Verkehrsdaten zwischen den eNB 148, 150 und dem S-GW 138 über die MEC-Hosts 102, 104 trägt, und die S1-AP (Steuerebene) - Schnittstelle, die eine Signalisierungsschnittstelle zwischen den eNB 148, 150 und der MME 142 ist.
  • Die MME 142 kann in ihrer Funktion ähnlich der Steuerungsebene älterer Serving-General-Packet-Radio-Service (GPRS) Support-Nodes (SGSN) sein. Die MME 142 kann Mobilitätsaspekte beim Zugang, wie zum Beispiel die Gateway-Auswahl und das Management von Verfolgungsbereichslisten, verwalten. Der HSS 144 kann eine Datenbank für Netzwerkbenutzer umfassen, einschließlich teilnahmebezogener Informationen, um die Handhabung von Kommunikationssitzungen durch die Netzwerkentitäten, einschließlich Teilnahmeinformationen, die V2X-Kommunikationen zugeordnet sind, zu unterstützen. Das CN 110 kann einen oder einige HSS 144 umfassen, abhängig von der Anzahl der Mobilfunkteilnehmer, von der Kapazität der Ausrüstung, von der Organisation des Netzwerks, usw. Zum Beispiel kann der HSS 144 Unterstützung für Routing/Roaming, Authentifizierung, Autorisierung (zum Beispiel V2X-Kommunikationsautorisierung), Namens-/Adressierungsauflösung, Standortabhängigkeiten, usw., bereitstellen.
  • Das S-GW 138 kann S1-Schnittstelle 413 in Richtung der RAN der eNB 148, 150 beenden und Datenpakete zwischen den RAN und dem CN 110 weiterleiten. Zusätzlich kann das S-GW 138 ein lokaler Mobilitätsankerpunkt für Inter-RAN-Knotenübergaben sein, und kann auch einen Anker für Inter-3GPP-Mobilität bereitstellen. Andere Verantwortlichkeiten können Gebührenerfassung und die Durchsetzung einiger Richtlinien umfassen.
  • Das P-GW 140 kann eine SGi-Schnittstelle in Richtung eines PDN beenden. Das P-GW 140 kann Datenpakete zwischen den RAN und externen Netzwerken, wie zum Beispiel einem Netzwerk einschließlich des Anwendungsservers (AS) 114 (alternativ bezeichnet als Anwendungsfunktion (AF)) über eine Internet-Protocol (IP) -Schnittstelle (zum Beispiel eine Schnittstelle zu dem mit dem AS 114 verbundenen Netzwerk 112) weiterleiten. Das P-GW 140 kann auch Daten an andere externe Netzwerke, die das Internet, IP-Multimedia-Subsystem (IPS) -Netzwerk und andere Netzwerke beinhalten können, kommunizieren. Im Allgemeinen kann der Anwendungsserver 114 ein Element sein, das Anwendungen anbietet, die IP-Trägerressourcen mit dem Core-Network (zum Beispiel UMTS-Packet-Services (PS) - Domäne, LTE-PS-Daten-Services, usw.) verwenden. Der Anwendungsserver 114 kann auch dazu ausgelegt sein, einen oder mehrere Kommunikations-Services (zum Beispiel Voice-over-Internet-Protocol (VoIP)-Sitzungen, PTT-Sitzungen, Gruppenkommunikationssitzungen, soziale Netzwerk-Services, usw.) für die UE 152, 154 über das CN 110 und einen oder mehrere der MEC-Hosts 102, 104 zu unterstützen.
  • Das P-GW 140 kann ferner einen Knoten zur Durchsetzung von Richtlinien und zur Sammlung von Gebührendaten beinhalten. Eine Policy-and-Charging-Enforcement-Function (PCRF) (nicht veranschaulicht in 1B) kann das Richtlinien- und Gebührensteuerungselement des CN 110 sein. In einem Nicht-Roaming-Szenario kann es eine einzelne PCRF in dem Home-Public-Land-Mobile-Network (HPLMN) geben, die der Internet-Protocol-Connectivity-Access-Network (IP-CAN) -Sitzung einer UE zugeordnet ist. In einem Roaming-Szenario mit einem lokalen Verkehrsausbruch können zwei PCRF mit der IP-CAN-Sitzung einer UE verbunden sein: ein Home-PCRF (H-PCRF) innerhalb eines HPLMN und ein Visited-PCRF (V-PCRF) innerhalb eines Visited-Public-Land-Mobile-Network (VPLMN). Die PCRF kann über das P-GW 140 kommunizierend mit dem Anwendungsserver 114 gekoppelt sein. Der Anwendungsserver 114 kann der PCRF signalisieren, einen neuen Servicefluss anzuzeigen und die geeigneten Quality-of-Service (QoS) und Gebührenparameter auszuwählen.
  • Die V2X-Steuerungsfunktion 146 wird in Verbindung mit der Autorisierung von UE verwendet, um V2X-Services basierend auf HSS-Informationen (zum Beispiel Teilnahmeinformationen, die durch den HSS 144 verwaltet werden) zu verwenden, eine oder mehrere UE beim Erhalten der Netzwerkadresse eines Anwendungsservers (zum Beispiel 114) oder eines V2X-Anwendungsservers zu unterstützen, sowie V2X-Konfigurationsparameter für direkte Kommunikation (das heißt Kommunikation von Gerät zu Gerät) bereitzustellen. Die Schnittstelle für die direkte Kommunikation von Gerät zu Gerät wird als PC5 bezeichnet. Die PC5-Parameter können durch die V2X-Steuerungsfunktion 146 an eine oder mehrere UE bereitgestellt werden, um die V2X-Kommunikation zwischen den UE zu konfigurieren.
  • Die Slice-Management-Funktion 162 kann zum Konfigurieren eines oder mehrerer Netzwerk-Slices (zum Beispiel 5G-Slices) zur Verwendung durch UE oder andere Geräte innerhalb der Kommunikationsarchitektur 100B verwendet werden.
  • Die MEC-Hosts 102, ..., 104 können gemäß der ETSI GS MEC-003-Spezifikation konfiguriert werden. Der MEC-Host 102 kann MEC-Plattform 118 beinhalten, die mit einer oder mehreren MEC-Anwendungen (Apps), wie zum Beispiel MEC-Apps 116A,..., 116N (zusammen MEC-App 116) und MEC-Datenebene 122 gekoppelt sein kann. Der MEC-Host 104 kann MEC-Plattform 126 beinhalten, die mit einer MEC-App 116 und MEC-Datenebene 130 gekoppelt sein kann. Der MEC-Plattformmanager 106 kann MEC-Plattformelement-Management-Modul 132, MEC-Anwendungsregel- und Anforderungs-Management-Modul 134 und MEC-Anwendungslebenszyklus-Management-Modul 136 beinhalten. Der MEC-Host 102 beinhaltet auch MEC-Hardware 123, wie zum Beispiel Netzwerkschnittstellen (zum Beispiel Network-Interface-Cards oder NIC) 125A,..., 125N, eine oder mehrere CPU, wie zum Beispiel Edge-Server-CPU 121, und Speicher 129. Eine zusätzliche Beschreibung der MEC-verwandten Entitäten 102, 104, 106 und 108 wird nachfolgend in Verbindung mit 4A bereitgestellt.
  • In einigen Aspekten können die MEC-Apps 116A, ..., 116N jeweils eine NFV-Instanz bereitstellen, die dazu ausgelegt ist, Netzwerkverbindungen zu verarbeiten, die einem spezifischen Netzwerkverkehrstyp (zum Beispiel 2G, 3G, 4G, 5G oder einem anderen Netzwerkverkehrstyp) zugeordnet sind. In dieser Hinsicht werden die Begriffe „MEC-App“ und „NFV“ (oder „MEC-NFV“) austauschbar verwendet. Zusätzlich werden die Begriffe „NFV“ und „NFV-Instanz“ austauschbar verwendet. Die MEC-Plattform 118 kann ferner einen oder mehrere Planer 120A, ..., 120N (zusammen Planer 120) beinhalten. Jeder der Planer 120A, ..., 120N kann geeignete Schaltungen, Logik, Schnittstellen und/oder Code umfassen, und ist dazu ausgelegt, die Instanziierung der NFV 116A, ..., 116N (zusammen NFV 116) zu verwalten. Insbesondere kann ein Planer 120 eine CPU (zum Beispiel eine der CPU 121) und/oder andere Netzwerkressourcen zum Ausführen/Instanziieren der NFV 116 auswählen. Zusätzlich kann, da jede der NFV 116A, ..., 116N der Verarbeitung eines unterschiedlichen Netzwerkverkehrstyps zugeordnet ist, der Planer 120 ferner eine NIC (zum Beispiel von den verfügbaren NIC 125A, ..., 125N) zur Verwendung durch die NFV 116 auswählen. Jeder der Planer 120A,..., 120N kann einen unterschiedlichen Typ von SLA- und QoS-Anforderungen haben, basierend auf dem durch die zugeordnete NFV gehandhabten Netzwerkverkehrstyp. Zum Beispiel ist jedem Verkehrstyp (zum Beispiel 2G, 3G, 4G, 5G oder jeglicher anderen Art von drahtloser Verbindung zu dem MEC-Host) eine Class-of-Service (CloS) (zum Beispiel 2G low, 2G mid, 2G_high, usw.) zugeordnet, die in dem MEC-Host vorkonfiguriert werden kann, die CloS-spezifische Ressourcenanforderungen (das heißt I/O, Speicher, Verarbeitungsleistung, usw.) für unterschiedliche Lasten dieses bestimmten Verkehrstyps definiert.
  • 1B veranschaulicht ferner den MEC-Host 104, einschließlich MEC-Hardware 133, Edge-Server-CPU 131 (die Teil der Hardware 133 sein kann) und Planer 128A,..., 128N, die die gleiche Funktionalität wie die MEC-Hardware 123, die Edge-Server-CPU 121 und die Planer 120A,..., 120N, die in Verbindung mit dem MEC-Host 102 beschrieben sind, haben können.
  • In einigen Aspekten kann die MEC-Architektur 100B (oder jegliche der hierin diskutierten MEC-Architekturen) dazu ausgelegt sein, Funktionalitäten gemäß der ETSI GS MEC-003-Spezifikation und/oder der ETSI GR MEC-017-Spezifikation bereitzustellen.
  • In einigen Aspekten kann die MEC-Architektur 100B Netzwerkressourcen mit einer Edge-Server-CPU (wie zum Beispiel der Edge-Server-CPU 121) verwenden, die für eine dynamische deterministische Skalierung von Verarbeitungsressourcen, wie zum Beispiel Prozessorkernen, konfiguriert ist. Zum Beispiel kann die Edge-Server-CPU 121 durch einen oder mehrere Netzwerkknoten innerhalb der MEC-Architektur 100B verwendet werden, einschließlich MEC-Hosts (wie zum Beispiel 102 und 104) oder Netzwerkknoten, die zum Ausführen des MEO 108, von NFVO 160, des MEC-Plattformmanagers 106 oder anderer Netzwerkknoten verwendet werden, die dem Kommunikationsverkehr zwischen den UE und einer oder mehreren anderen Entitäten der MEC-Architektur 100B zugeordnet sind. Die Funktionalitäten der Edge-Server-CPU 121 werden nachfolgend unter Bezugnahme auf 11-20 weiter diskutiert.
  • 2A veranschaulicht eine beispielhafte Cellular-Internet-of-Things (CIoT) - Netzwerkarchitektur mit einem MEC-Host durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel. Bezugnehmend auf 2A kann CIoT-Architektur 200A UE 202 und RAN 204 beinhalten, die mit mehreren Core-Network-Entitäten gekoppelt sind. In einigen Aspekten kann die UE 202 eine Machine-Type-Communication (MTC) -UE sein. Die CIoT-Netzwerkarchitektur 200A kann ferner Mobile-Services-Switching-Center (MSC) 206, MME 208, Serving-GPRS-Support-Node (SGSN) 210, S-GW 212, IP-Short-Message-Gateway (IP-SM-GW) 214, Short-Message-Service-Service-Center (SMS-SC)/Gateway-Mobile-Service-Center (GMSC)/Interworking-MSC (IWMSC) 216, MTC-Interworking-Function (MTC-IWF) 222, Service-Capability-Exposure-Function (SCEF) 220, Gateway-GPRS-Support-Node (GGSN)/Packet-GW (P-GW) 218, Charging-Data-Function (CDF)/Charging-Gateway-Function (CGF) 224, Home-Subscriber-Server (HSS)/Home-Location-Register (HLR) 226, Short-Message-Entities (SME) 228, MTC-Authorization, Authentication, and Accounting (MTC AAA) -Server 230, Service-Capability-Server (SCS) 232 und Anwendungsserver (AS) 234 und 236 beinhalten. In einigen Aspekten kann die SCEF 220 dazu ausgelegt sein, Services und Fähigkeiten, die durch verschiedene 3GPP-Netzwerkschnittstellen bereitgestellt werden, sicher freizulegen. Die SCEF 220 kann auch Mittel für die Entdeckung der freigelegten Services und Fähigkeiten, sowie Zugang zu Netzwerkfähigkeiten durch verschiedene Programmierschnittstellen für Netzwerkanwendungen (zum Beispiel API-Schnittstellen zu dem SCS 232) bereitstellen.
  • 2A veranschaulicht ferner verschiedene Referenzpunkte zwischen unterschiedlichen Servern, Funktionen oder Kommunikationsknoten der CIoT-Netzwerkarchitektur 200A. Einige beispielhafte Referenzpunkte bezogen auf MTC-IWF 222 und SCEF 220 beinhalten die folgenden: Tsms (ein Referenzpunkt, der durch eine Entität außerhalb des 3GPP-Netzwerks zur Kommunikation mit UE verwendet wird, die für MTC über SMS verwendet werden), Tsp (ein Referenzpunkt, der durch einen SCS zur Kommunikation mit der MTC-IWFbezogenen Steuerungsebenensignalisierung verwendet wird), T4 (ein Referenzpunkt, der zwischen MTC-IWF 222 und SMS-SC 216 in dem HPLMN verwendet wird), T6a (ein Referenzpunkt, der zwischen SCEF 220 und Serving-MME 208 verwendet wird), T6b (ein Referenzpunkt, der zwischen SCEF 220 und Serving-SGSN 210 verwendet wird), T8 (ein Referenzpunkt, der zwischen SCEF 220 und SCS/AS 234, 236 verwendet wird), S6m (ein Referenzpunkt, der durch MTC-IWF 222 zum Abfragen von HSS/HLR 226 verwendet wird), S6n (ein Referenzpunkt, der durch MTC-AAA-Server 230 zum Abfragen von HSS/HLR 226 verwendet wird) und S6t (ein Referenzpunkt, der zwischen SCEF 220 und HSS/HLR 226 verwendet wird).
  • In einigen Aspekten kann die UE 202 dazu ausgelegt sein, mit einer oder mehreren Entitäten innerhalb der CIoT-Architektur 200A über das RAN 204 (zum Beispiel CIoT-RAN) gemäß einem Non-Access-Stratum (NAS) -Protokoll und durch Verwenden eines oder mehrerer Funkzugangskonfiguration, wie zum Beispiel einer Schmalband-Luftschnittstelle, die zum Beispiel auf einer oder mehreren Kommunikationstechnologien, wie zum Beispiel der Orthogonal-Frequency-Division-Multiplexing (OFDM) -Technologie basiert, zu kommunizieren. Wie hierin verwendet, bezieht sich der Begriff „CIoT-UE“ auf eine UE, die zu CIoT-Optimierungen geeignet ist, als Teil einer CIoT-Kommunikationsarchitektur. In einigen Aspekten kann das NAS-Protokoll einen Satz von NAS-Nachrichten für die Kommunikation zwischen der UE 202 und einer Evolved-Packet-System (EPS) -Mobile-Management-Entity (MME) 208 und SGSN 210 unterstützen. In einigen Aspekten kann die CIoT-Netzwerkarchitektur 200A ein Paketdatennetzwerk, ein Betreibernetzwerk oder ein Cloud-Service-Netzwerk beinhalten, das zum Beispiel unter anderem Server, wie zum Beispiel den Service-Capability-Server (SCS) 232, den AS 234 oder einen oder mehrere andere externe Server oder Netzwerkkomponenten, hat.
  • Das RAN 204 kann mit den HSS/HLR-Servern 226 und den AAA-Servern 230 durch Verwenden eines oder mehrerer Referenzpunkte, einschließlich zum Beispiel einer auf einem S6a-Referenzpunkt basierenden Luftschnittstelle, gekoppelt sein, und dazu ausgelegt sein, CIoT-UE 202 zu authentifizieren/autorisieren, um auf das CIoT-Netzwerk zuzugreifen. Das RAN 204 kann mit der CIoT-Netzwerkarchitektur 200A durch Verwenden eines oder mehrerer anderer Referenzpunkte, einschließlich zum Beispiel einer Luftschnittstelle, die einer SGi/Gi-Schnittstelle für 3GPP-Zugänge entspricht, gekoppelt werden. Das RAN 204 kann mit der SCEF 220 gekoppelt werden, indem zum Beispiel eine Luftschnittstelle verwendet wird, die auf einem T6a/T6b-Referenzpunkt basiert, um die Servicefähigkeit freizulegen. In einigen Aspekten kann die SCEF 220 als ein API-GW in Richtung eines Anwendungsservers eines Drittanbieters, wie zum Beispiel des Servers 234, agieren. Die SCEF 220 kann durch Verwenden eines S6t-Referenzpunkts mit den HSS/HLR 226 und MTC-AAA 230 -Servern gekoppelt werden, und kann ferner eine Anwendungsprogrammierungsschnittstelle zu Netzwerkfähigkeiten freilegen.
  • In bestimmten Beispielen können eine oder mehrere der hierin offenbarten CIoT-Geräte, wie zum Beispiel die UE 202, das RAN 204, usw., ein oder mehrere andere Nicht-CIoT-Geräte oder Nicht-CIoT-Geräte mit Funktionen eines CIoT-Geräts beinhalten. Zum Beispiel kann die UE 202 ein Smartphone, einen Tablet-Computer oder ein oder mehrere andere elektronische Geräte beinhalten, die als ein CIoT-Gerät für eine spezifische Funktion agieren, während sie andere zusätzliche Funktionalität haben. In einigen Aspekten kann das RAN 204 einen CIoT-enhanced-Node-B (CIoT-eNB) beinhalten, der kommunizierend mit einem CIoT-Access-Network-Gateway (CIoT-GW) gekoppelt ist. In bestimmten Beispielen kann das RAN 204 mehrere Basisstationen (zum Beispiel CIoT-eNB oder andere Typen von Basisstationen) beinhalten, die mit dem CIoT-GW verbunden sind, die MSC 206, MME 208, SGSN 210 oder S-GW 212 beinhalten können. In bestimmten Beispielen kann die interne Architektur des RAN 204 und das CIoT-GW der Implementierung überlassen bleiben, und muss nicht standardisiert werden.
  • In einigen Aspekten kann die CIoT-Architektur 200A einen oder mehrere MEC-Hosts beinhalten, die eine Kommunikationsverbindung zwischen unterschiedlichen Komponenten der CIoT-Architektur bereitstellen können. Zum Beispiel kann der MEC-Host 102 zwischen dem RAN 204 und dem S-GW 212 gekoppelt werden. In diesem Fall kann der MEC-Host 102 eine oder mehrere NFV-Instanzen verwenden, um drahtlose Verbindungen mit dem RAN 204 und dem S-GW 212 zu verarbeiten. Der MEC-Host 102 kann auch zwischen dem P-GW 218 und dem Anwendungsserver 236 gekoppelt werden. In diesem Fall kann der MEC-Host 102 die eine oder mehreren NFV-Instanzen verwenden, um drahtlose Verbindungen zu verarbeiten, die von dem P-GW 218 und dem Anwendungsserver 236 stammen oder dort beendet werden. In einigen Aspekten beinhaltet der MEC-Host 102 eine Edge-Server-CPU 121, die gemäß den hierin offenbarten Techniken dazu ausgelegt ist, eine dynamische deterministische Skalierung von Prozessorressourcen (zum Beispiel Prozessorkernen) bereitzustellen.
  • 2B veranschaulicht eine beispielhafte Service-Capability-Exposure-Function (SCEF), die durch die CIoT-Netzwerkarchitektur von 2B verwendet wird, gemäß einem Beispiel. Bezugnehmend auf 2B kann die SCEF 220 dazu ausgelegt sein, Services und Fähigkeiten freizulegen, die durch 3GPP-Netzwerkschnittstellen externen Servern von Drittanbietern, auf denen verschiedene Anwendungen gehostet werden, bereitgestellt werden. In einigen Aspekten kann ein 3GPP-Netzwerk wie die CIoT-Architektur 200A die folgenden Services und Fähigkeiten freilegen: Home-Subscriber-Server (HSS) 256A, Policyand-Charging-Rules-Function (PCRF) 256B, Packet-Flow-Description-Function (PFDF) 256C, MME/SGSN 256D, Broadcast-Multicast-Service-Center (BM-SC) 256E, Serving-Call-Server-Control-Function (S-CSCF) 256F, RAN-Congestion-Awareness-Function (RCAF) 256G und ein oder mehrere andere Netzwerk-Entitäten 256H. Die oben erwähnten Services und Fähigkeiten eines 3GPP-Netzwerks können mit der SCEF 220 über eine oder mehrere Schnittstellen kommunizieren, wie in 2B veranschaulicht. Die SCEF 220 kann dazu ausgelegt sein, die 3GPP-Netzwerk-Services und -Fähigkeiten zu einer oder mehreren Anwendungen freizulegen, die auf einem oder mehreren Service-Capability-Servern (SCS)/Anwendungsservern (AS), wie zum Beispiel SCS/AS 254A, 254B,..., 254N, ausgeführt werden. Jeder der SCS/AS 254A-254N kann mit der SCEF 220 über Application-Programming-Interfaces (API) 252A, 252B, 252C, ..., 252N kommunizieren, wie in 2B zu sehen.
  • 3A ist ein vereinfachtes Diagramm einer beispielhaften Next-Generation (NG) - Systemarchitektur mit einem MEC-Host durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel. Bezugnehmend auf 3A beinhaltet NG-Systemarchitektur 300A NG-RAN 304 und 5G-Core-Network (5GC) 306. Das NG-RAN 304 kann mehrere NG-RAN-Knoten beinhalten, zum Beispiel gNB 308 und 310 und NG-eNB 312 und 314. Die gNB 308/310 und die NG-eNB 312/314 können über eine drahtlose Verbindung kommunizierend mit UE 302 verbunden werden. Das Core-Network 306 (zum Beispiel ein 5G-Core-Network oder 5GC) kann Access-and-Mobility-Management-Function (AMF) 316 oder User-Plane-Function (UPF) 318 beinhalten. Die AMF 316 und die UPF 318 können kommunizierend mit den gNB 308/310 und den NG-eNB 312/314 über NG-Schnittstellen gekoppelt werden. Insbesondere können in einigen Aspekten die gNB 308/310 und die NG-eNB 312/314 mit der AMF 316 durch N2-Schnittstelle, und mit der UPF 318 durch N3-Schnittstelle verbunden werden. Die gNB 308/310 und die NG-eNB 312/314 können miteinander über Xn-Schnittstellen verbunden werden.
  • In einigen Aspekten kann ein gNB 308 einen Knoten beinhalten, der eine New-Radio (NR) - Benutzerebenen- und Steuerungsebenenprotokoll-Beendigung in Richtung der UE bereitstellt, und kann über die NG-Schnittstelle mit dem 5GC 306 verbunden werden. In einigen Aspekten kann ein NG-eNB 312/314 einen Knoten beinhalten, der Evolved-Universal-Terrestrial-Radio-Access (E-UTRA)-Benutzerebenen- und Steuerungsebenenprotokoll-Beendigungen für die UE bereitstellt und ist über die NG-Schnittstelle mit dem 5GC 306 verbunden. In einigen Aspekten kann jeglicher der gNB 308/310 und der NG-eNB 312/314 als eine Basisstation (BS), ein mobiler Edge-Server, eine kleine Zelle, ein Home-eNB implementiert werden, obwohl Aspekte nicht so beschränkt sind.
  • In einigen Aspekten kann die NG-Systemarchitektur 300A einen oder mehrere MEC-Hosts beinhalten, die eine Kommunikationsverbindung zwischen unterschiedlichen Komponenten der NG-Architektur bereitstellen können. Zum Beispiel kann der MEC-Host 102 eine Schnittstelle zwischen der AMF 316 (oder UPF 318) in dem 5GC 306 und dem Anwendungsserver 114 bereitstellen. Der MEC-Host 102 kann eine oder mehrere NFV-Instanzen verwenden, um drahtlose Verbindungen mit dem 5GC 306 und dem Anwendungsserver 114 zu verarbeiten. Der MEC-Host 102 kann auch zwischen einem oder mehreren der gNB (zum Beispiel gNB 308) und der AMF/UPF in dem 5GC 306 gekoppelt werden. In diesem Fall kann der MEC-Host 102 die eine oder mehreren NFV-Instanzen verwenden, um drahtlose Verbindungen zu verarbeiten, die von dem gNB 308 und dem 5GC 306 stammen oder dort beendet werden.
  • In einigen Aspekten beinhaltet der MEC-Host 102 eine Edge-Server-CPU 121, die gemäß den hierin offenbarten Techniken dazu ausgelegt ist, eine dynamische deterministische Skalierung von Prozessorressourcen, wie zum Beispiel Prozessorkernen, bereitzustellen. Insbesondere können unterschiedliche Sätze von Prozessorkernen der CPU dazu ausgelegt sein, mit unterschiedlichen Basisfrequenzen (zum Beispiel einer hohen Basisfrequenz und einer niedrigen Basisfrequenz) zu arbeiten, und die NFV-Instanzen können instanziiert werden (zum Beispiel durch Verwenden virtueller Ressourcen) durch Verwenden von Prozessorkernen, die mit der niedrigen Basisfrequenz, der hohen Basisfrequenz oder mit beiden Basisfrequenzen arbeitenden Kernen arbeiten. Die Verwendung der Kerne kann dynamisch angepasst werden, zum Beispiel basierend auf der Nutzung eines dem NFV zugeordneten Netzwerk-Services, des dem NFV zugeordneten Netzwerkverkehrs, der Anzahl von Teilnehmern, die dem durch die NFV bereitgestellten Netzwerk-Service zugeordnet sind, und so weiter. In einigen Aspekten kann das 5G-Core-Network 306 Slice-Management-Funktionalitäten bereitstellen, die durch die Slice-Management-Funktion 162 ausgeführt werden.
  • In einigen Aspekten kann die Systemarchitektur 300A (die dieselbe sein kann wie 100B) eine 5G-NR-Systemarchitektur sein, die Netzwerk-Slicing bereitstellt und die Richtlinienkonfiguration und -Durchsetzung zwischen Netzwerk-Slices gemäß Service-Level-Agreements (SLA) innerhalb das RAN 304 (oder 204) unterstützt. Zusätzlich, und wie detaillierter in 3E veranschaulicht, kann das RAN 304 eine Trennung von Central-Unit-Control-Plane (CU-CP) und Central-Unit-User-Plane (CU-UP)-Funktionalitäten bereitstellen, während das Netzwerk-Slicing unterstützt wird (zum Beispiel durch Verwenden der Ressourcenverfügbarkeits- und Latenzinformationskommunikation über unterschiedliche RAN-Schnittstellen, wie zum Beispiel E1-, F1-C- und F1-U-Schnittstellen). In einigen Aspekten kann die UE 302 (oder 152) eine RRC-Signalisierung an den gNB 308 kommunizieren, um eine Verbindung mit einer Entität (zum Beispiel UPF 318) des 5GC 306 einzurichten. Der gNB 308 kann separate Distributed-Units (DU), CU-CP und CU-UP-Entitäten beinhalten (wie in 3E veranschaulicht). Die CU-CP-Entität kann Ressourcennutzungs- und Latenzinformationen von den DU- und CU-UP-Entitäten erhalten und basierend auf solchen Informationen ein DU/CU-UP-Paar zu Zwecken des Konfigurierens des Netzwerk-Slices auswählen. Netzwerk-Slice-Konfigurationsinformationen, die dem konfigurierten Netzwerk-Slice zugeordnet sind (einschließlich Ressourcen zur Verwendung während der Kommunikation über das Slice), können der UE 302 zu Zwecken des Initiierens von Datenkommunikation mit der 5GC-UPF-Entität 318 durch Verwenden des Netzwerk-Slice bereitgestellt werden.
  • 3B veranschaulicht eine beispielhafte funktionale Aufteilung zwischen einem Next-Generation-Radio-Access-Network (NG-RAN) und dem 5G-Core-Network (5GC) in Verbindung mit der NG-Systemarchitektur von 3A, gemäß einem Beispiel. 3B veranschaulicht einige der Funktionalitäten, die die gNB 308/310 und die NG-eNB 312/314 innerhalb des NG-RAN 304 ausführen können, sowie die AMF 316, die UPF 318 und Session-Management-Function (SMF) 326 (nicht veranschaulicht in 3A) innerhalb des 5GC 306. In einigen Aspekten kann das 5GC 306 Zugang zu Netzwerk 330 (zum Beispiel das Internet) für ein oder mehrere Geräte über das NG-RAN 304 bereitstellen.
  • In einigen Aspekten können die gNB 308/310 und die NG-eNB 312/314 dazu ausgelegt sein, die folgenden Funktionen zu hosten: Funktionen für das Funkressourcen-Management (zum Beispiel zellenübergreifendes Funkressourcen-Management 320A, Funkträgersteuerung 320B), Verbindungsmobilitätssteuerung 320C, Funkzugangssteuerung 320D, Mess- und Messberichterstellungskonfiguration für Mobilität und Planung 320E, und dynamische Zuweisung von Ressourcen zu UE sowohl in Aufwärts- als auch in Abwärtsverbindung (Planung) 320F); IP-Header-Komprimierung; Verschlüsselung und Integritätsschutz von Daten; Auswahl einer AMF an UE-Anhang, wenn von den durch die UE bereitgestellten Informationen kein Weiterleiten zu einer AMF bestimmt werden kann; Weiterleiten von Daten der Benutzerebene an UPF; Weiterleitung von Steuerungsebeneninformationen an AMF; Verbindungseinrichtung und -Freigabe; Planung und Übertragung von Paging-Nachrichten (von der AMF stammend); Planung und Übertragung von System-Broadcast-Informationen (von der AMF oder Operation und Wartung stammend); Paketmarkierung auf Transportebene in der Aufwärtsverbindung; Sitzungs-Management; Unterstützung von Netzwerk-Slicing; QoS-Flussmanagement und Zuordnung zu Datenfunkträgern; Unterstützung von UE in RRC_INACTIVE-Status; Verteilungsfunktion für Non-Access-Stratum (NAS) -Nachrichten; gemeinsame Nutzung eines Funkzugangsnetzwerks; duale Konnektivität; und enge Zusammenarbeit zwischen NR und E-UTRA, um einige zu nennen.
  • In einigen Aspekten kann die AMF 316 dazu ausgelegt sein, die folgenden Funktionen zu hosten, zum Beispiel: NAS-Signalisierungsbeendigung; NAS-Signalisierungssicherheit 322A; Access-Stratum (AS) - Sicherheitskontrolle; Inter-Core Network (CN) - Knotensignalisierung für Mobilität zwischen 3GPP-Zugangsnetzwerken; Leerlaufzustand/Modus-Mobilitätshandhabung 322B, einschließlich eines mobilen Geräts, wie zum Beispiel einer UE-Erreichbarkeit (zum Beispiel Steuerung und Ausführung einer Paging-Neuübertragung) ; Management des Registrierungsbereichs; Unterstützung der systeminternen und systemübergreifenden Mobilität; Zugangsauthentifizierung; Zugangsberechtigung einschließlich Überprüfung von Roaming-Rechten; Mobilitäts-Management-Steuerung (Teilnahme und Richtlinien); Unterstützung von Netzwerk-Slicing; oder SMF-Auswahl, unter anderen Funktionen.
  • Die UPF 318 kann dazu ausgelegt sein, die folgenden Funktionen zu hosten, zum Beispiel: Mobilitätsverankerung 324A (zum Beispiel Ankerpunkt für Intra-/Inter-RAT-Mobilität); Packet-Data-Unit (PDU) - Handhabung 324B (zum Beispiel externer PDU-Sitzungspunkt der Verbindung zu Datennetzwerk); Paketweiterleitung und -Beförderung; Paketprüfung und Benutzerebenenteil der Durchsetzung von Richtlinienregeln; Berichterstattung über Verkehrsnutzung; Aufwärtsverbindungs-Klassifizierer zur Unterstützung des Weiterleitens von Verkehrsflüssen zu einem Datennetzwerk; Verzweigungspunkt zur Unterstützung einer Multi-Homed-PDU-Sitzung; QoS-Handhabung für Benutzerebene, zum Beispiel Paketfilterung, Gating, Durchsetzung der UL/DL-Rate; Aufwärtsverbindungs-Verkehrsüberprüfung (SDF-QoS-Flussabbildung); oder Abwärtsverbindungs-Paketpufferung und Auslösen der Abwärtsverbindungs-Datenbenachrichtigung, unter anderen Funktionen.
  • Session-Management-Function (SMF) 326 kann dazu ausgelegt sein, die folgenden Funktionen zu hosten, zum Beispiel: Sitzungs-Management; UE-IP-Adresszuweisung und -Management 328A; Auswahl und Steuerung der User-Plane-Function (UPF); PDU-Sitzungssteuerung 328B, einschließlich Konfigurieren der Verkehrslenkung bei UPF 318, um den Verkehr zum richtigen Bestimmungsort zu leiten; Kontrolle eines Teils der Durchsetzung von Richtlinien und der QoS; oder Abwärtsverbindungs-Datenbenachrichtigung, unter anderen Funktionen.
  • 3C und 3D veranschaulichen beispielhafte Non-Roaming-SG-Systemarchitekturen mit einem MEC-Host durch Verwenden einer Edge-Server-CPU, gemäß einem Beispiel. Bezugnehmend auf 3C ist beispielhafte 5G-Systemarchitektur 300C in einer Referenzpunktdarstellung veranschaulicht. Insbesondere kann UE 302 mit RAN 304 sowie einer oder mehreren anderen 5G-Core-Network (5GC) -Entitäten in Kommunikation sein. Die 5G-Systemarchitektur 300C beinhaltet mehrere Network-Functions (NF), wie zum Beispiel Access-and-Mobility-Management-Function (AMF) 316, Session-Management-Function (SMF) 326, Policy-Control-Function (PCF) 332, Anwendungsfunktion (AF) 352 , User-Plane-Function (UPF) 318, Network-Slice-Selection-Function (NSSF) 334, Authentication-Server-Function (AUSF) 336 und Unified-Data-Management (UDM) 338.
  • Die UPF 318 kann eine Verbindung zu Datennetzwerk (DN) 354 bereitstellen, das zum Beispiel Betreiber-Services, Internetzugang oder Services von Drittanbietern beinhalten kann. Die AMF 316 kann zum Management der Zugangskontrolle und Mobilität verwendet werden, und kann auch Funktionalität zur Auswahl von Netzwerk-Slices beinhalten. Die SMF 326 kann dazu ausgelegt sein, verschiedene Sitzungen gemäß der Netzwerkrichtlinie einzurichten und zu verwalten. Die UPF 318 kann gemäß dem gewünschten Servicetyp in einer oder mehreren Konfigurationen bereitgestellt werden. Die PCF 332 kann dazu ausgelegt sein, einen Richtlinienrahmen durch Verwenden von Netzwerk-Slicing, Mobilitäts-Management und Roaming bereitzustellen (ähnlich zu PCRF in einem 4G-Kommunikationssystem). Das UDM 338 kann dazu ausgelegt sein, Teilnehmerprofile und -Daten (ähnlich einem HSS in einem 4G-Kommunikationssystem) zu speichern, wie zum Beispiel V2X-Teilnahmeinformationen oder einen anderen Typ von Teilnahmeinformationen für innerhalb der Architektur 300C verfügbare Services.
  • In einigen Aspekten beinhaltet die 5G-Systemarchitektur 300C IP-Multimedia-Subsystem (IMS) 342 sowie mehrere IP-Multimedia-Core-Network-Subsystem-Entitäten, wie zum Beispiel Call-Session-Control-Functions (CSCF). Insbesondere beinhaltet das IMS 342 eine CSCF, die als Proxy-CSCF (P-CSCF) 344 agieren kann, Serving-CSCF (S-CSCF) 346, Emergency-CSCF (E-CSCF) (nicht veranschaulicht in 3C) oder Interrogating-CSCF (I-CSCF) 348. Die P-CSCF 344 kann dazu ausgelegt sein, der erste Kontaktpunkt für die UE 302 innerhalb des IMS 342 zu sein. Die S-CSCF 346 kann dazu ausgelegt sein, die Sitzungszustände in dem Netzwerk zu handhaben, und die E-CSCF kann dazu ausgelegt sein, bestimmte Aspekte von Notfallsitzungen, wie zum Beispiel das Weiterleiten einer Notfallanforderung an die richtige Notrufzentrale oder den Public-Safety-Answering-Point (PSAP), zu handhaben. Die I-CSCF 348 kann dazu ausgelegt sein, als Kontaktpunkt innerhalb des Netzwerks eines Betreibers für alle IMS-Verbindungen zu funktionieren, die an einen Teilnehmer dieses Netzwerkbetreibers oder einen Roaming-Teilnehmer gerichtet sind, der aktuell innerhalb des Service-Bereichs dieses Netzwerkbetreibers platziert ist. In einigen Aspekten kann die I-CSCF 348 mit einem anderen IP-Multimedia-Netzwerk 350, zum Beispiel einem durch einen unterschiedlichen Netzwerkbetreiber betriebenen IMS, verbunden sein.
  • In einigen Aspekten kann das UDM 338 mit Anwendungsserver 340 gekoppelt sein, der einen Telephony-Application-Server (TAS) oder einen anderen Anwendungsserver (AS), einschließlich eines MEC-Hosts, beinhalten kann. Der AS 340 kann über die S-CSCF 346 oder die I-CSCF 348 mit dem IMS 342 verbunden sein. In einigen Aspekten kann die 5G-Systemarchitektur 300C einen oder mehrere MEC-Hosts verwenden, um eine Schnittstelle bereitzustellen und die Verarbeitung des drahtlosen Kommunikationsverkehrs auszulagern. Zum Beispiel, und wie in 3C veranschaulicht, kann der MEC-Host 102 eine Verbindung zwischen dem RAN 304 und der UPF 318 in dem Core-Network bereitstellen. Der MEC-Host 102 kann eine oder mehrere NFV-Instanzen, die in der Virtualisierungsinfrastruktur innerhalb des Hosts instanziiert sind, verwenden, um drahtlose Verbindungen zu und von dem RAN 304 und der UPF 318 zu verarbeiten. Zusätzlich kann der MEC-Host 102 die Edge-Server-CPU 121 verwenden, die gemäß den hierin offenbarten Techniken dazu ausgelegt ist, eine dynamische deterministische Skalierung von Prozessorressourcen, wie zum Beispiel Prozessorkernen, bereitzustellen.
  • 3D veranschaulicht beispielhafte 5G-Systemarchitektur 300D in einer Service-basierten Darstellung. Die Systemarchitektur 300D kann im Wesentlichen ähnlich (oder dieselbe) wie die Systemarchitektur 300C sein. Zusätzlich zu den in 3C veranschaulichten Netzwerk-Entitäten kann die Systemarchitektur 300D auch Network-Exposure-Function (NEF) 356 und Network-Repository-Function (NRF) 358 beinhalten. In einigen Aspekten können 5G-Systemarchitekturen Service-basiert sein, und die Interaktion zwischen Netzwerkfunktionen kann durch entsprechende Punkt-zu-Punkt-Referenzpunkte Ni (wie in 3C veranschaulicht), oder als Service-basierte Schnittstellen (wie in 3D veranschaulicht) dargestellt werden.
  • Eine Referenzpunktdarstellung zeigt, dass eine Interaktion zwischen entsprechenden NF-Services existieren kann. Zum Beispiel veranschaulicht 3C die folgenden Referenzpunkte: N1 (zwischen der UE 302 und der AMF 316), N2 (zwischen dem RAN 304 und der AMF 316), N3 (zwischen dem RAN 304 und der UPF 318), N4 (zwischen der SMF 326 und der UPF 318), N5 (zwischen der PCF 332 und der AF 352), N6 (zwischen der UPF 318 und dem DN 354), N7 (zwischen der SMF 326 und der PCF 332), N8 (zwischen dem UDM 338 und der AMF 316), N9 (zwischen zwei UPF 318), N10 (zwischen dem UDM 338 und der SMF 326), N11 (zwischen der AMF 316 und der SMF 326), N12 (zwischen der AUSF 336 und der AMF 316), N13 (zwischen der AUSF 336 und dem UDM 338), N14 (zwischen zwei AMF 316), N15 (zwischen der PCF 332 und der AMF 316 im Fall eines Nicht-Roaming-Szenarios, oder zwischen der PCF 332 und einem besuchten Netzwerk und AMF 316 im Fall eines Roaming-Szenarios) N16 (zwischen zwei SMF; nicht gezeigt) und N22 (zwischen AMF 316 und NSSF 334). Andere nicht in 3C gezeigte Referenzpunktdarstellungen können ebenfalls verwendet werden.
  • In einigen Aspekten, wie in 3D veranschaulicht, können Service-basierte Darstellungen verwendet werden, um Netzwerkfunktionen innerhalb der Steuerungsebene darzustellen, die es anderen autorisierten Netzwerkfunktionen ermöglichen, auf ihre Services zuzugreifen. In dieser Hinsicht kann die 5G-Systemarchitektur 300D die folgenden Service-basierten Schnittstellen beinhalten: Namf 364A (eine durch die AMF 316 vorgelegte Service-basierte Schnittstelle), Nsmf 364B (eine durch die SMF 326 vorgelegte Service-basierte Schnittstelle), Nnef 364C (eine durch die NEF 356 vorgelegte Service-basierte Schnittstelle), Npcf 364D (eine durch die PEF 332 vorgelegte Service-basierte Schnittstelle), Nudm 364E (eine durch das UDM 338 vorgelegte Service-basierte Schnittstelle), Naf 364F (eine durch die AF 352 vorgelegte Service-basierte Schnittstelle), Nnrf 364G (eine durch die NRF 358 vorgelegte Service-basierte Schnittstelle), Nnssf 364H (eine durch die NSSF 334 vorgelegte Service-basierte Schnittstelle), Nausf 3641 (eine durch die AUSF 360 vorgelegte Service-basierte Schnittstelle). Andere Service-basierte Schnittstellen (zum Beispiel Nudr, N5g-eir und Nudsf), die in 3D nicht gezeigt sind, können ebenfalls verwendet werden.
  • In einigen Aspekten kann die NEF 356 eine Schnittstelle zu einem MEC-Host, wie zum Beispiel dem MEC-Host 102 mit einer Edge-Server-CPU durch Verwenden der hierin diskutierten Techniken für die Prozessorkernskalierung, bereitstellen, die zum Verarbeiten von drahtlosen Verbindungen mit dem RAN 304 verwendet werden können.
  • 3E veranschaulicht Komponenten einer beispielhaften 5G-NR-Architektur mit einer Control-Unit-Control-Plane (CU-CP) - Control-Unit-User-Plane (CU-UP) -Trennung, gemäß einem Beispiel. Bezugnehmend auf 3E kann 5G-NR-Architektur 300E einen 5G-Kern (5GC) 306 und ein NG-RAN 304 beinhalten. Das NG-RAN 304 kann einen oder mehrere gNB, wie zum Beispiel gNB 308 und 310, beinhalten. In einigen Aspekten können Netzwerkelemente des NG-RAN 304 in zentrale und verteilte Einheiten aufgeteilt werden, und unterschiedliche zentrale und verteilte Einheiten oder Komponenten der zentralen und verteilten Einheiten können dazu ausgelegt sein, unterschiedliche Protokollfunktionen (zum Beispiel unterschiedliche Protokollfunktionen der Protokollschichten) auszuführen.
  • In einigen Aspekten kann der gNB 308 eine oder mehrere gNB-Central-Unit (gNB-CU) 322E und gNB-Distributed-Unit(s) (gNB-DU) 324E, 326E umfassen, oder in diese aufgeteilt sein. Zusätzlich kann der gNB 308 eine oder mehrere von gNB-CU-Cotrol-Plane (gNB-CU-CP) 328E und gNB-CU-User-Plane (gNB-CU-UP) 330E umfassen, oder in diese aufgeteilt sein. Die gNB-CU 322E ist ein logischer Knoten, der dazu ausgelegt ist, die Protokolle der Radio-Resource-Control (RRC) - Schicht, der Service-Data-Adaptation-Protocol (SDAP) - Schicht und der Packet-Data-Convergence-Protocol (PDCP) -Schicht der gNB- oder RRC- und PDCP-Protokolle des E-UTRA-NR-gNB (en-gNB), der den Betrieb einer oder mehrerer gNB-DU steuert, zu hosten. Die gNB-DU (zum Beispiel 324E oder 326E) ist ein logischer Knoten, der dazu ausgelegt ist, die Schichten der Radio-Link-Control (RLC) -Schicht, der Medium-Access-Control (MAC) -Schicht und der Physical (PHY) -Schicht der gNB 128A, 128B oder des en-gNB zu hosten, und sein Betrieb wird mindestens teilweise durch gNB-CU 322E gesteuert. In einigen Aspekten kann eine gNB-DU (zum Beispiel 324E) eine oder mehrere Zellen unterstützen.
  • Die gNB-CU 322E umfasst eine gNB-CU-Control-Plane (gNB-CU-CP) -Entität 328E und eine gNB-CU-User-Plane (gNB-CU-UP) -Entität 330E. Die gNB-CU-CP 328E ist ein logischer Knoten, der dazu ausgelegt ist, die RRC und den Steuerungsebenenteil des PDCP-Protokolls der gNB-CU 322E für einen en-gNB oder einen gNB zu hosten. Die gNB-CU-UP 330E ist ein logischer (oder physikalischer) Knoten, der dazu ausgelegt ist, den Teil der Benutzerebene des PDCP-Protokolls der gNB-CU 322E für einen en-gNB und den Teil der Benutzerebene des PDCP-Protokolls und des SDAP-Protokolls der gNB-CU 322E für einen gNB zu hosten.
  • Die gNB-CU 322E und die gNB-DU 324E, 326E können über die F1-Schnittstelle kommunizieren, und der gNB 308 kann mit der gNB-CU 322E über die Xn-C-Schnittstelle kommunizieren. Die gNB-CU-CP 328E und die gNB-CU-UP 330E können über die E1-Schnittstelle(n) kommunizieren. Zusätzlich können die gNB-CU-CP 328E und die gNB-DU 324E, 326E über die F1-C-Schnittstelle kommunizieren, und die gNB-DU 324E, 326E und die gNB-CU-UP 330E können über die F1-U-Schnittstelle kommunizieren.
  • In einigen Aspekten beendet die gNB-CU 322E die mit den gNB-DU 324E, 326E verbundene F1-Schnittstelle, und in anderen Aspekten beenden die gNB-DU 324E, 326E die mit der gNB-CU 322E verbundene F1-Schnittstelle. In einigen Aspekten beendet die gNB-CU-CP 328E die mit der gNB-CU-UP 330E verbundene E1-Schnittstelle und die mit den gNB-DU 324E, 326E verbundene F1-C-Schnittstelle. In einigen Aspekten beendet die gNB-CU-UP 330E die mit der gNB-CU-CP 328E verbundene E1-Schnittstelle und die mit den gNB-DU 324E, 326E verbundene F1-U-Schnittstelle.
  • In einigen Aspekten ist die F1-Schnittstelle eine Punkt-zu-Punkt-Schnittstelle zwischen Endpunkten und unterstützt den Austausch von Signalisierungsinformationen zwischen Endpunkten und die Datenübertragung zu den jeweiligen Endpunkten. Die F1-Schnittstelle kann die Trennung von Steuerungsebene und Benutzerebene unterstützen und die Funknetzwerkschicht und die Transportnetzwerkschicht trennen. In einigen Aspekten ist die E1-Schnittstelle eine Punkt-zu-Punkt-Schnittstelle zwischen einer gNB-CU-CP und einer gNB-CU-UP und unterstützt den Austausch von Signalisierungsinformationen zwischen Endpunkten. Die E1-Schnittstelle kann die Funknetzwerkschicht und die Transportnetzwerkschicht trennen, und in einigen Aspekten kann die E1-Schnittstelle eine Steuerungsschnittstelle sein, die nicht für die Beförderung von Benutzerdaten verwendet wird.
  • Bezugnehmend auf das NG-RAN 304 können die gNB 308, 310 des NG-RAN 304 über die NG-Schnittstellen mit dem 5GC 306 kommunizieren, und können über die Xn-Schnittstelle mit anderen gNB verbunden sein. In einigen Aspekten können die gNB 308, 310 dazu ausgelegt sein, den FDD-Modus, den TDD-Modus oder den Dual-Mode-Betrieb zu unterstützen. In bestimmten Aspekten können für EN-DC die S1-U-Schnittstelle und eine X2-Schnittstelle (zum Beispiel X2-C-Schnittstelle) für einen gNB, bestehend aus einer gNB-CU und gNB-DU, in der gNB-CU enden.
  • In einigen Aspekten beinhaltet der gNB 310, der die CP/UP-Trennung unterstützt, eine einzelne CU-CP-Entität 328E, mehrere CU-UP-Entitäten 330E und mehrere DU-Entitäten 324E,..., 326E, wobei alle Entitäten für einen Netzwerk-Slice-Betrieb konfiguriert sind. Wie in 3E veranschaulicht, kann jede DU-Entität 324E,..., 326E über eine F1-C-Schnittstelle eine einzelne Verbindung mit der CU-CP 328E haben. Jede DU-Entität 324E,..., 326E kann über F1-U-Schnittstellen mit mehreren CU-UP-Entitäten 330E verbunden sein. Die CU-CP-Entität 328E kann über E1-Schnittstellen mit mehreren CU-UP-Entitäten 330E verbunden sein. Jede DU-Entität 324E,..., 326E kann mit einer oder mehreren UE verbunden sein, und die CU-UP-Entitäten 330E können mit einer User-Plane-Function (UPF) und dem 5G-Core 306 verbunden sein.
  • In einigen Aspekten kann das NG-RAN 304 dazu ausgelegt sein, Latenzmessungen über die F1-U-Schnittstelle zu unterstützen, sodass die UP-Elemente, einschließlich DU-Entitäten (324E,..., 326E) und CU-UP-Entitäten 330E, Latenzinformationen an andere benachbarte UP-Elemente übertragen können. In dieser Hinsicht kann Netzwerk-Slicing in dem NG-RAN 304 mit der Trennung von CP/UP unterstützt werden. In einigen Aspekten kann die Isolation auf Slice-Ebene und eine verbesserte Ressourcennutzung durch das zentrale RRM in der CU-CP 328E bereitgestellt werden.
  • In einigen Aspekten umfassen dem Netzwerk-Slicing zugeordnete Prozeduren Operationen und Kommunikationen über die E1-Schnittstelle, die F1-C-Schnittstelle und die F1-U-Schnittstelle. Mit diesen Prozeduren kann die CU-CP 328E die geeigneten DU- und CU-UP-Entitäten auswählen, um die spezifische Netzwerk-Slicing-Anforderung zu bedienen, die einem bestimmten Service-Level-Agreement (SLA) zugeordnet ist.
  • In einigen Aspekten kann die Prozedur über die E1-Schnittstelle das Sammeln von Informationen von den CU-UP-Entitäten 330E und das Ressourcen-Management in der CU-CP 328E beinhalten. Insbesondere kann die Informationssammlung eine Ressourcenverfügbarkeitsanzeige und eine Latenzanzeige beinhalten, während das Ressourcen-Management eine Ressourcenzuweisung und eine Ressourcenfreigabe beinhalten kann. Die CU-CP 328E kann dazu ausgelegt sein, die Informationen von den CU-UP-Entitäten 330E periodisch zu sammeln, oder eine On-Demand-Abfrage basierend auf einer Netzwerk-Slice-Anforderung auszugeben. In einigen Aspekten kann eine Prozedur zur Ressourcenverfügbarkeitsanzeige es den CU-UP-Entitäten 330E ermöglichen, die CU-CP 328E über die Verfügbarkeit von Ressourcen zum Verarbeiten einer Netzwerk-Slicing-Anforderung zu informieren. Zum Beispiel kann die Anzeige der verfügbaren Ressource die CU-CP 5 328E unterstützen, zu bestimmen, ob die spezifische CU-UP die spezifische, einem bestimmten SLA zugeordnete Netzwerk-Slice-Anforderung bedienen kann.
  • In einigen Aspekten kann eine Ressourcenzuweisungsprozedur es der CU-CP 328E ermöglichen, die Ressource in der CU-UP 330E zuzuweisen, die einem spezifischen Slice zugeordnet ist. Mit dem Empfang einer Anforderung für eine Netzwerk-Slice-Erzeugung kann die CU-10 CP 328E die dem angezeigten SLA folgende CU-UP 330E (zum Beispiel eine der CU-UP-Entitäten) auswählen, und die Ressource in der ausgewählten CU-UP dem Netzwerk-Slice zuweisen. In einigen Aspekten kann eine Ressourcenfreigabeprozedur es der CU-CP 328E ermöglichen, die Ressource in der CU-UP, die einem eingerichteten Netzwerk-Slice zugewiesen ist, freizugeben. Mit dem Entfernen des Slice kann die CU-CP 328E die entsprechenden CU-UP benachrichtigen, die durch den entfernten Netzwerk-Slice verwendete Ressource freizugeben.
  • 3F veranschaulicht Diagramm 300F mit Beispielen von Netzwerk-Slices, gemäß einem Beispiel. Ein RAN kann eine differenzierte Handhabung des Datenverkehrs zwischen vorkonfigurierten, isolierten RAN-Slices unterstützen. Wie dies auszuführen ist, kann der Implementierung überlassen werden. Die Auswahl des RAN-Slice basiert auf ID (die der oben definierte Slice-Service-Typ und Slice-Differenzierer sein können), die durch das Gerät oder Core-Network bereitgestellt werden. Ein RAN-Slice kann an einem gegebenen Standort verfügbar sein oder nicht. Das RAN wählt den Core-Network-Slice aus. Die QoS-Differenzierung innerhalb eines RAN-Slice wird ebenfalls unterstützt.
  • Wie hierin verwendet, bezieht sich der Begriff „Netzwerk-Slicing“ auf die Aufteilung des physikalischen Netzwerks in mehrere virtuelle Netzwerke, die angepasst sind, um einen verschiedenartigen Satz vertikaler Anforderungen zu erfüllen. Netzwerk-Slicing kann für 3GPP Rel. 15 und darüber hinaus relevant sein, und relevante 3GPP-Spezifikationen beinhalten TS 23.501 (5GS-Architektur), TS 22.261 (5G-Anforderungen) und TS 28.531/28.532 (5G-Slice-Management).
  • Bezugnehmend auf 3F, unterstützt die Network-Slice-Selection-Function (NSSF) das Auswählen der Netzwerk-Slice-Instanzen, um die UE zu bedienen, das Bestimmen der erlaubten NSSAI (Network-Slice-Selection-Assistance-Information) und das Bestimmen des AMF-Satzes, der zum Bedienen der UE verwendet werden soll. NSSF ist eine neue Funktionalität, die in EPC nicht vorhanden ist. Ein Network-Slice-Template (NST) ist als ein Untersatz der Werte von Attributen definiert, die zum Erzeugen von Instanzen der Information-Object-Class (IOC) des Netzwerk-Slices verwendet werden. Der Inhalt von NST kann nicht durch 3GPP standardisiert werden, das heißt er kann durch MNO und Verkäufer definiert werden.
  • In einigen Aspekten wird die Slice-Auswahl durch das Netzwerk (AMF oder NSSF) bestimmt, basierend auf der Netzwerk-Slice-Richtlinie mit den durch die UE gesendeten unterstützten Informationen (NSSAI). In einigen Aspekten können maximal 8 Netzwerk-Slices pro UE verwendet werden.
  • Automobilbeispiel: Es kann erforderlich sein, dass ein Fahrzeug gleichzeitig mit mehreren Slice-Instanzen verbunden ist, die zu unterschiedlichen Slice/Service-Typen (SST) gehören, um unterschiedliche Leistungsanforderungen mehrerer Automobilanwendungsfälle zu unterstützen. Zum Beispiel können Anwendungsfälle für Softwareupdates und ferngesteuertes Fahren basierend auf ihren KPI-Anforderungen mit eMBB-Slice bzw. URLLC-Slice verbunden sein.
  • 4A veranschaulicht MEC Netzwerkarchitektur 400, modifiziert zur Unterstützung einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel. 4A veranschaulicht spezifisch eine MEC-Architektur 400 mit MEC-Hosts 402 und 404, die Funktionalitäten gemäß der ETSI GS MEC-003-Spezifikation bereitstellen, wobei die schattierten Blöcke verwendet werden, um Verarbeitungsaspekte für die hierin beschriebene MEC-Architekturkonfiguration in Verbindung mit einer dynamischen deterministischen Skalierung der Prozessorressourcen anzuzeigen. Insbesondere können Verbesserungen an MEC-Plattform 432 und MEC-Hardware 433 verwendet werden, um eine dynamische deterministische Skalierung der Prozessorressourcen innerhalb der MEC-Architektur 400 bereitzustellen. Dies kann das Umschalten der Verarbeitung von Netzwerkverkehr oder Netzwerkanwendungen, die UE oder anderen Teilnehmern innerhalb der MEC-Netzwerkarchitektur 400 zugeordnet sind, zwischen unterschiedlichen Sätzen von Prozessorkernen beinhalten, wobei jeder Satz von Prozessorkernen einer unterschiedlichen Basisfrequenz zugeordnet ist.
  • Bezugnehmend auf 4A, kann die MEC-Netzwerkarchitektur 400 die MEC-Hosts 402 und 404, Virtualization-Infrastructure-Manager (VIM) 408, MEC-Plattformmanager 406, MEC-Orchestrator 410, NFV-Orchestrator (NFVO) 435, Betriebsunterstützungssystem 412, Benutzer-App-Proxy 414, UE-App 418, die auf UE 420 ausgeführt wird, und CFS-Gateway 416 beinhalten. Der MEC-Host 402 kann eine MEC-Plattform 432 mit Filterregelsteuerungsmodul 440, DNS-Handhabungsmodul 442, Service-Registrierung 438 und MEC-Services 436 beinhalten. Die MEC-Services 436 können mindestens einen Planer 437 beinhalten, der verwendet werden kann, um Ressourcen zum Instanziieren von MEC-Apps (oder NFV-Instanzen oder NFV) 426 und 428 auf Virtualisierungsinfrastruktur 422 auszuwählen. Die MEC-Apps 426 und 428 können dazu ausgelegt sein, Services 430/431 bereitzustellen, die das Verarbeiten von Netzwerkkommunikationsverkehr unterschiedlicher Typen beinhalten können, die einer oder mehreren drahtlosen Verbindungen zugeordnet sind (zum Beispiel Verbindungen zu einer oder mehreren RAN- oder Core-Network-Entitäten, wie in den 1B-3D veranschaulicht).
  • Die MEC-Hardware 433 und der mindestens eine Planer 437 können ähnlich der in Verbindung mit 1B diskutierten MEC-Hardware 123 und dem Planer 120A sein. In einigen Aspekten kann die MEC-Hardware 433 Edge-Server-CPU 434 beinhalten, die ähnlich der oben erwähnten Edge-Server-CPU 121 sein kann, und kann in Verbindung mit einer dynamischen deterministischen Skalierung von Verarbeitungsressourcen verwendet werden. In einigen Aspekten kann die MEC-Hardware 433 für die MEC-Plattform 432 Edge-Server-Telemetriemodul 441 beinhalten, das dazu ausgelegt sein kann, den Kommunikationsverkehr, sowie verschiedene andere Telemetrieparameter (zum Beispiel eine Anzahl aktiver Netzwerkteilnehmer, die aktuell in Kommunikation mit dem MEC-Host 402 sind, minimale Anforderungen an Netzwerkressourcen für eine MEC-App, einschließlich minimaler Prozessorkernanforderungen und Prozessorkernbasisfrequenz, Bandbreitennutzung für eine MEC-App, usw.) zu überwachen.
  • Die Edge-Server-CPU 434 kann dazu ausgelegt sein, mit dem Telemetriemodul 441 zu kommunizieren, um solche Netzwerktelemetrieparameter zu erhalten, und die Prozessorkernnutzung basierend auf den erhaltenen Informationen dynamisch zu skalieren. Zum Beispiel kann die CPU 434 mit einem ersten Satz von Prozessorkernen konfiguriert sein, die dazu ausgelegt sind, mit einer niedrigen Basisfrequenz (was als ein Satz von Kernen mit niedriger Priorität erachtet werden kann) zu arbeiten, und einem zweiten Satz von Prozessorkernen, die dazu ausgelegt sind, mit einer hohen Basisfrequenz (das heißt höher als die Basisfrequenz des ersten Satzes von Prozessorkernen) (was als ein Satz von Kernen mit hoher Priorität erachtet werden kann) zu arbeiten. In dieser Hinsicht kann die Verarbeitung von Kommunikationsverkehr, Services (zum Beispiel 430 und 431), MEC-Apps oder anderen NFV-Instanzen, die der Kommunikation zwischen einer oder mehreren UE und anderen Netzwerkknoten innerhalb der MEC-Netzwerkarchitektur 400 zugeordnet sind, von einem Satz von Prozessorkerne zu einem anderen Satz von Prozessorkernen ausgelagert werden (sodass ausschließlich Kerne mit hoher Priorität, ausschließlich Kerne mit niedriger Priorität, oder eine Mischung von Kernen mit hoher und niedriger Priorität verwendet werden), basierend auf Informationen, die von dem Telemetriemodul 441 empfangen werden. In einigen Aspekten kann das Zuweisen eines spezifischen Prozessorkerns oder das Umschalten zwischen Prozessorkernen, die zum Verarbeiten von Netzwerkverkehr verwendet werden, der einem bestimmten Service, einer MEC-Anwendung oder einem anderen Netzwerkverkehr zugeordnet ist, auf der Teilnehmeridentität (das heißt der UE-spezifischen Zuweisung der Verarbeitung für Ressourcen) basieren, oder kann anwendungsspezifisch sein.
  • In einigen Aspekten kann die CPU 434 die Nutzung des Prozessorkernsatzes mit hoher Priorität überwachen, und kann basierend darauf, dass einer oder mehrere durch das Telemetriemodul 441 überwachte Parameter unter einen vorgegebenen Schwellenwert fallen, auf den Kernsatz mit niedriger Priorität herabstufen und auslagern. In ähnlicher Weise kann die CPU 434 die Verarbeitung von dem Kern mit niedriger Priorität zu dem Kern mit hoher Priorität auslagern, wenn überwachte Parameter (zum Beispiel eine Anzahl aktiver UE, die mit dem MEC-Host 402 kommunizieren) über einen vorgegebenen Schwellenwert ansteigen.
  • Der MEC-Plattformmanager 406 kann MEC-Plattformelement-Management-Modul 444, MEC-Anwendungsregel- und Anforderungs-Management-Modul 446 und MEC-Anwendungslebenszyklus-Management-Modul 448 beinhalten. Die verschiedenen Entitäten innerhalb der MEC-Architektur 400 können Funktionalitäten wie durch die ETSI GS MEC-003-Spezifikation offenbart ausführen.
  • In einigen Aspekten kann die UE 420 dazu ausgelegt sein, mit einem oder mehreren Core-Networks 482 über einen oder mehrere Netzwerk-Slices 480 zu kommunizieren. In einigen Aspekten können die Core-Networks 482 Slice-Management-Funktionen (zum Beispiel wie durch die Slice-Management-Funktion 162 bereitgestellt) verwenden, um die Slices 480 dynamisch zu konfigurieren, einschließlich dynamisches Zuweisen eines Slice zu einer UE, Neuzuweisen eines Slice zu einer UE, dynamisches Zuweisen oder Neuzuweisen von Ressourcen, die durch einen oder mehreren der Slices 480 oder andere Slice-bezogene Management-Funktionen verwendet werden. Eine oder mehrere der in Verbindung mit dem Slice-Management ausgeführten Funktionen können basierend auf Benutzeranforderungen (zum Beispiel über eine UE) oder einer Anforderung durch einen Service-Anbieter initiiert werden.
  • In einigen Aspekten kann die Edge-Server-CPU 434 auch in anderen Netzwerkknoten der MEC-Architektur 400, einschließlich des zum Implementieren des MEC-Plattform-Managers 406 verwendeten Netzwerkknotens, implementiert werden. Eine zusätzliche dynamische deterministische Skalierung von Prozessorressourcen und Anwendungsfälle sind in Verbindung mit 11-20 veranschaulicht.
  • 4B veranschaulicht MEC-Referenzarchitektur 400B in einer Network-Function-Virtualization (NFV) -Umgebung durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel. Die MEC-Architektur 400B kann dazu ausgelegt sein, Funktionalitäten gemäß der ETSI GR MEC-017-Spezifikation bereitzustellen.
  • In einigen Aspekten kann ETSI MEC in einer wie 4B veranschaulichten NFV-Umgebung eingesetzt werden. In einigen Aspekten wird die MEC-Plattform als eine Virtualized-Network-Function (VNF) eingesetzt. Die ME-Anwendungen können in Richtung der ETSI-NFV-Management-and-Orchestration (MANO) - Komponenten wie VNF erscheinen. Dies ermöglicht die Wiederverwendung der ETSI-NFV-MANO-Funktionalität. In einigen Aspekten kann der gesamte Satz von MANO-Funktionalität nicht verwendet werden, und bestimmte zusätzliche Funktionalität kann erforderlich sein. Eine solche spezifische ME-Anwendung wird durch den hierin diskutierten Namen „ME-App (VNF)“ bezeichnet. In einigen Aspekten wird die Virtualisierungsinfrastruktur als eine NFVI eingesetzt, und ihre virtualisierten Ressourcen werden durch den Virtualized-Infrastructure-Manager (VIM) verwaltet. Zu diesem Zweck können eine oder mehrere der durch ETSI-NFV-Infrastrukturspezifikationen definierten Prozeduren, das heißt ETSI GS NFV-INF 003, ETSI GS NFV-INF 004 und ETSI GS NFV-INF 005, verwendet werden.
  • In einigen Aspekten werden die ME-Anwendungen (oder VNF) wie einzelne VNF verwaltet, wodurch es ermöglicht wird, das ein MEC-in-NFV-Einsatz bestimmte Orchestrierungs- und Life-Cycle-Management (LCM) -Aufgaben an die NFVO- und VNFM-Funktionsblöcke delegieren kann, wie durch ETSI NFV MANO definiert.
  • In einigen Aspekten kann der Mobile-Edge-Platform-Manager (MEPM) in eine „Mobile-Edge-Platform-Manager - NFV“ (MEPM-V) umgewandelt werden, die den LCM-Teil an einen oder mehrere Virtual-Network-Function-Manager (VNFM) delegiert. Der Mobile-Edge-Orchestrator (MEO), wie in der MEC-Referenzarchitektur ETSI GS MEC-003 definiert, kann in einen „Mobile-Edge-Application-Orchestrator“ (MEAO) umgewandelt werden, der den NFVO für die Ressourcen-Orchestrierung und für die Orchestrierung des Satzes von ME-App-VNF als einen oder mehrere NFV-Network-Services (NS) verwendet.
  • In einigen Aspekten können die Mobile-Edge-Platform-VNF, die MEPM-V und der VNFM (ME-Plattform-LCM) als ein einzelnes Paket gemäß dem Ensemble-Konzept in 3GPP TR 32.842 bereitgestellt werden, oder die VNFM ist eine generische VNFM gemäß ETSI GS NFV-IFA 009, und die Mobile-Edge-Platform-VNF und MEPM-V werden durch einen einzelnen Anbieter bereitgestellt.
  • In einigen Aspekten kann der Mp1-Referenzpunkt zwischen einer ME-Anwendung und der ME-Plattform für die ME-Anwendung optional sein, es sei denn, es ist eine Anwendung, die einen ME-Service bereitstellt und/oder verbraucht.
  • In einigen Aspekten basiert der Mm3*-Referenzpunkt zwischen MEAO und MEPM-V auf dem Mm3-Referenzpunkt, wie durch ETSI GS MEC-003 definiert. An diesem Referenzpunkt können Änderungen konfiguriert werden, um die Aufteilung zwischen MEPM-V und VNFM (ME-Applications-LCM) zu berücksichtigen.
  • In einigen Aspekten werden die folgenden neuen Referenzpunkte (Mv1, Mv2 und Mv3) zwischen Elementen der ETSI-MEC-Architektur und der ETSI-15-NFV-Architektur eingeführt, um das Management von ME-App-VNF zu unterstützen. Die folgenden Referenzpunkte beziehen sich auf existierende NFV-Referenzpunkte, es kann jedoch nur ein Untersatz der Funktionalität für ETSI MEC verwendet werden, und es können Erweiterungen erforderlich sein: Mv1 (dieser Referenzpunkt verbindet MEAO und NFVO; er bezieht sich auf den Os-Ma-nfvo-Referenzpunkt, wie in ETSI NFV definiert); Mv2 (dieser Referenzpunkt verbindet den VNF-Manager, der LCM der ME-App-VNF ausführt, mit MEPM-V, um den Austausch von LCM-bezogenen Benachrichtigungen zwischen diesen Entitäten zu ermöglichen; er bezieht sich auf den wie in ETSI NFV definierten Ve-Vnfm-em-Referenzpunkt, kann aber möglicherweise Ergänzungen beinhalten, und könnte nicht alle durch Ve-Vnfm-em angebotenen Funktionalitäten verwenden); Mv3 (dieser Referenzpunkt verbindet den VNF-Manager mit der ME-App-VNF-Instanz, um den Austausch von Nachrichten, zum Beispiel bezüglich LCM der ME-Anwendung oder der anfänglichen einsatzspezifischen Konfiguration, zu ermöglichen; er bezieht sich auf den wie in ETSI NFV definierten Ve-Vnfm-vnf-Referenzpunkt, kann jedoch Ergänzungen beinhalten, und könnte nicht die gesamte durch Ve-Vnfmvnf angebotene Funktionalität verwenden.
  • In einigen Aspekten werden die folgenden durch ETSI NFV definierten Referenzpunkte verwendet: Nf-Vn (dieser Referenzpunkt verbindet jede ME-App-VNF mit NFVI); Nf-Vi (dieser Referenzpunkt verbindet NFVI und VIM); Os-Mangfvo (dieser Referenzpunkt verbindet OSS und NFVO. Er wird hauptsächlich zum Verwalten von NS verwendet, das heißt einer Anzahl von VNF, die verbunden und orchestriert sind, um einen Service zu liefern); Or-Vnfm (dieser Referenzpunkt verbindet NFVO und VNFM; er wird hauptsächlich verwendet, damit NFVO VNF-LCM-Operationen aufruft); Vi-Vnfm (dieser Referenzpunkt verbindet VIM und VNFM; er wird hauptsächlich durch VNFM zum Aufrufen von Ressourcen-Management-Operationen zum Management der durch VNF benötigten Cloud-Ressourcen verwendet; es wird in einer NFV-basierten MEC-Bereitstellung vorausgesetzt, dass dieser Bezugspunkt 1:1 Mm6 entspricht); und Or-Vi (dieser Referenzpunkt verbindet NFVO und VIM; er wird hauptsächlich durch NFVO zum Management der Cloud-Ressourcenkapazität verwendet).
  • In einigen Aspekten können einer oder mehrere der Netzwerkknoten innerhalb der MEC-Architektur 400B (zum Beispiel Netzwerkknoten 402B, der zum Ausführen der Mobile-Edge-Plattform oder VNF verwendet wird) Edge-Server-CPU 404B und Edge-Server-Telemetriemodul 406B implementieren. Die Edge-Server-CPU 404B und das Telemetriemodul 406B können Funktionalitäten ausführen, die ähnlich der in Verbindung mit 4A diskutierten Edge-Server-CPU 434 oder dem Telemetriemodul 441 sind.
  • Obwohl hierin offenbarte Techniken für das Netzwerk-Slicing und das Ressourcenmanagement im Zusammenhang mit MEC-bezogenen Architekturen, bei denen mindestens eine MEC-Entität vorhanden ist, diskutiert werden, ist die Offenbarung in dieser Hinsicht nicht beschränkt, und die offenbarten Techniken können in Architekturen verwendet werden, die keine MEC-Entitäten verwenden. Zum Beispiel können dem Netzwerk-Slicing und dem Ressourcenmanagement zugeordnete Techniken (einschließlich des Managements und der Skalierung von Prozessorkernressourcen) in Nicht-MEC-Architekturen ausgeführt werden.
  • Obwohl hierin offenbarte Techniken in Verbindung mit einer MEC-Architektur und 5G-Architektur beschrieben sind, ist die Offenbarung in dieser Hinsicht nicht beschränkt, und die offenbarten Techniken können mit anderen Typen von drahtlosen Architekturen (zum Beispiel 2G, 3G, 4G, usw.), die eine oder mehrere MEC-Entitäten verwenden, sowie gemäß jeglichem Spektral-Management-Schema verwendet werden. Zusätzlich können die hierin beschriebenen Funkverbindungen gemäß jeglichen Funkkommunikationstechnologien und/oder -Standards arbeiten. Darüber hinaus können die hierin beschriebenen Aspekte in dem Zusammenhang mit jeglichem Spektrums-Management-Schema verwendet werden, einschließlich eines fest zugeordneten lizenzierten Spektrums, eines nicht lizenzierten Spektrums, eines (lizenzierten) gemeinsam genutzten Spektrums (wie zum Beispiel Licensed-Shared-Access (LSA) in 2,3-2,4 GHz, 3,4-3,6 GHz 3,6-3,8 GHz und weiteren Frequenzen, und Spectrum-Access-System (SAS)/Citizen-Broadband-Radio-System (CBRS) mit 3,55-3,7 GHz und weiteren Frequenzen).
  • Hierin beschriebene Aspekte können auch auf unterschiedliche Single-Carrier- oder OFDM-Varianten (CP-OFDM, SC-FDMA, SC-OFDM, Filter-Bank-Based-Multicarrier (FBMC), OFDMA, usw.) und insbesondere 3GPP NR (NewRadio) angewendet werden, durch Zuweisen der OFDM-Trägerdatenbitvektoren zu den entsprechenden Symbolressourcen. Einige der Merkmale in diesem Dokument sind für die Netzwerkseite definiert, zum Beispiel Zugangspunkte, eNodeB, New Radio (NR) oder next-generation-Node-B (gNodeB oder gNB), wie sie in dem Zusammenhang mit 3GPP-Kommunikationssystemen der fünften Generation (5G) verwendet werden, usw. Dennoch kann eine Benutzerausrüstung (UE) diese Rolle ebenfalls übernehmen und als Zugangspunkte, eNodeB, gNodeB, usw., agieren. Dementsprechend können einige oder alle für Netzwerkausrüstung definierten Merkmale durch eine UE oder ein mobiles Computing-Gerät implementiert werden.
  • In weiteren Beispielen können die vorhergehenden Beispiele von Netzwerkkommunikationen und -Operationen in IoT und ähnlichen gerätebasierten Netzwerkarchitekturen integriert sein. 5 zeigt eine beispielhafte Domänentopologie für jeweilige IoT-Netzwerke, die durch Verbindungen mit jeweiligen Gateways gekoppelt sind. Das IoT ist ein Konzept, bei dem eine große Anzahl von Computing-Geräten miteinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung auf sehr niedrigen Niveaus bereitzustellen. Somit kann, wie hierin verwendet, ein Edge-/IoT-Verarbeitungsgerät ein halbautonomes Gerät beinhalten, das eine Funktion, wie zum Beispiel unter anderem das Erfassen oder Steuern, in Kommunikation mit anderen Edge-/IoT-Verarbeitungsgeräten und einem breiteren Netzwerk, wie zum Beispiel dem Internet, ausführt.
  • MEC-Anwendungsfälle waren vorgesehen, in eine Reihe von Netzwerk- und Anwendungseinstellungen integriert zu werden, einschließlich solcher zur Unterstützung von Netzwerkanordnungen von IoT-Einsätzen. Edge-/IoT-Verarbeitungsgeräte sind physikalische oder virtualisierte Objekte, die in einem Netzwerk (normalerweise an dem Rand oder Endpunkt eines Netzwerks) kommunizieren können, und können Sensoren, Aktuatoren und andere Eingabe-/Ausgabekomponenten beinhalten, wie zum Beispiel um Daten zu sammeln oder Aktionen von einer realen Umgebung auszuführen. Zum Beispiel können Edge-/IoT-Verarbeitungsgeräte Geräte mit geringem Leistungsverbrauch beinhalten, die in alltägliche Dinge, wie zum Beispiel Gebäude, Fahrzeuge, Pakete, usw., eingebettet oder an diesen befestigt sind, um Erfassungs-, Daten- oder Verarbeitungsfunktionalität bereitzustellen. In letzter Zeit sind Edge-/IoT-Verarbeitungsgeräte populärer geworden, und somit haben Anwendungen und Anwendungsfälle, die diese Geräte verwenden, zugenommen.
  • Es wurden verschiedene Standards vorgeschlagen, um Edge-/IoT-Verarbeitungsgeräte und IoT-Netzwerkanwendungsfälle, einschließlich solcher mit MEC- und Mobilfunknetzwerkarchitekturen, effektiver miteinander zu verbinden und zu betreiben. Einige der relevanten Kommunikations- und Netzwerkarchitekturstandards beinhalten diejenigen, die durch Gruppen, wie zum Beispiel ETSI, 3rd-Generation-Partnership-Project (3GPP), Institute-of-Electricaland-Electronics-Engineers (IEEE), verteilt werden, zusätzlich zu spezialisierten IoT-Anwendungsinteraktionsarchitektur- und Konfigurationsstandards, die durch Arbeitsgruppen, wie zum Beispiel die Open-Connectivity-Foundation (OCF), verteilt werden.
  • Oft sind Edge-/IoT-Verarbeitungsgeräte in Speicher, Größe oder Funktionalität beschränkt, sodass größere Stückahlen zu ähnlichen Kosten wie für kleinere Stückzahlen größerer Geräte eingesetzt werden können. Ein Edge-/IoT-Verarbeitungsgerät kann jedoch ein Smartphone, einen Laptop, ein Tablet, einen PC oder ein anderes größeres Gerät sein. Ferner kann ein Edge-/IoT-Verarbeitungsgerät ein virtuelles Gerät sein, wie zum Beispiel eine Anwendung auf einem Smartphone oder einem anderen Computing-Gerät. Edge-/IoT-Verarbeitungsgeräte können IoT-Gateways beinhalten, die zum Koppeln von Edge-/IoT-Verarbeitungsgeräten mit anderen Edge-/IoT-Verarbeitungsgeräten und Cloud-Anwendungen, zur Datenspeicherung, Prozesssteuerung und dergleichen verwendet werden.
  • Netzwerke von Edge-/IoT-Verarbeitungsgeräten können kommerzielle und Heimautomatisierungsgeräte beinhalten, wie zum Beispiel Wasserverteilungssysteme, Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Auf die Edge-/IoT-Verarbeitungsgeräte kann zum Beispiel über entfernt angeordnete Computer, Server und andere Systeme zugegriffen werden, um Systeme zu steuern oder auf Daten zuzugreifen.
  • Das zukünftige Wachstum des Internets und ähnlicher Netzwerke kann eine sehr große Anzahl von Edge-/IoT-Verarbeitungsgeräten einbeziehen. Dementsprechend wird in dem Zusammenhang mit den hierin diskutierten Techniken eine Anzahl von Innovationen für eine solche zukünftige Vernetzung die Notwendigkeit ansprechen, dass alle diese Schichten ungehindert wachsen, dass verbundene Ressourcen entdeckt und zugänglich gemacht werden, und dass die Fähigkeit unterstützt wird, verbundene Ressourcen zu verbergen und aufzugliedern. Es kann jegliche Anzahl von Netzwerkprotokollen und Kommunikationsstandards verwendet werden, wobei jedes Protokoll und jeder Standard so entworfen ist, dass spezifische Ziele angesprochen werden. Ferner sind die Protokolle Teil der Struktur, die für Menschen zugängliche Services unterstützt, die unabhängig von Standort, Zeit oder Raum arbeiten. Die Innovationen beinhalten die Service-Lieferung und die damit verbundene Infrastruktur, wie zum Beispiel Hardware und Software; Sicherheitsverbesserungen; und die Bereitstellung von Services basierend auf Quality-of-Service (QoS) - Bedingungen, die in Service-Level- und Service Delivery-Vereinbarungen spezifiziert sind. Es versteht sich, dass die Verwendung von Edge-/IoT-Verarbeitungsgeräten und -Netzwerken eine Anzahl neuer Herausforderungen in einem heterogenen Konnektivitätsnetzwerk darstellt, das eine Kombination aus drahtgebundenen und drahtlosen Technologien umfasst.
  • 5 stellt speziell eine vereinfachte Zeichnung einer Domänentopologie bereit, die für eine Anzahl von IoT-Netzwerken verwendet werden kann, die Edge-/IoT-Verarbeitungsgeräte 504 umfassen, wobei IoT-Netzwerke 556, 558, 560, 562 über Backbone-Verbindungen 502 mit jeweiligen Gateways 554 gekoppelt sind. Zum Beispiel kann eine Anzahl von Edge-/IoT-Verarbeitungsgeräten 504 mit einem Gateway 554 und miteinander durch das Gateway 554 kommunizieren. Um die Zeichnung zu vereinfachen, ist nicht jedes Edge-/IoT-Verarbeitungsgerät 504 oder jede Kommunikationsverbindung (zum Beispiel Verbindung 516, 522, 528 oder 532) beschriftet. Die Backbone-Verbindungen 502 können jegliche Anzahl von drahtgebundenen oder drahtlosen Technologien, einschließlich optischer Netzwerke, beinhalten, und können Teil eines Local-Area-Network (LAN), eines Wide-Area-Network (WAN), oder des Internets sein. Zusätzlich erleichtern solche Kommunikationsverbindungen optische Signalpfade zwischen sowohl den Edge-/IoT-Verarbeitungsgeräten 504 als auch den Gateways 554, einschließlich der Verwendung von MUXing/deMUXing-Komponenten, die die Verbindung der verschiedenen Geräte erleichtern.
  • Die Netzwerktopologie kann jegliche Anzahl von Typen von IoT-Netzwerken beinhalten, wie zum Beispiel ein Mesh-Netzwerk, das mit dem Netzwerk 556 durch Verwenden von Bluetooth-Low-Energy (BLE) - Verbindungen 522 bereitgestellt wird. Andere Typen von IoT-Netzwerken, die vorhanden sein können, beinhalten Wireless-Local-Area-Network (WLAN) 558, das zur Kommunikation mit Edge-/IoT-Verarbeitungsgeräten 504 über IEEE 802.11 (Wi-Fi®) -Verbindungen 528 verwendet wird, Mobilfunknetzwerk 560, das zur Kommunikation mit Edge-/IoT-Verarbeitungsgeräten 504 durch ein LTE/LTE-A-(4G) oder 5G-Mobilfunknetzwerk verwendet wird, und Low-Power-Wide-Area (LPWA) -Netzwerk 562, zum Beispiel ein LPWA-Netzwerk, das mit der durch die LoRa-Allianz veröffentlichten LoRaWan-Spezifikation kompatibel ist, oder ein IPv6- über Low-Power-Wide-Area-Networks (LPWAN) -Netzwerk, das mit einer durch die Internet-Engineering-Task-Force (IETF) veröffentlichten Spezifikation kompatibel ist. Ferner können die jeweiligen IoT-Netzwerke mit einem externen Netzwerkanbieter (zum Beispiel einem Tier 2- oder Tier 3-Anbieter) durch Verwenden jeglicher Anzahl von Kommunikationsverbindungen, wie zum Beispiel einer LTE-Mobilfunkverbindung, einer LPWA-Verbindung oder einer auf dem IEEE 802.15.4-Standard, wie zum Beispiel Zigbee®, basierenden Verbindung, kommunizieren. Die jeweiligen IoT-Netzwerke können auch unter Verwendung einer Vielzahl von Netzwerk- und Internetanwendungsprotokollen, wie zum Beispiel dem Constrained-Application-Protocol (CoAP) arbeiten. Die jeweiligen IoT-Netzwerke können auch in Koordinatorgeräte integriert werden, die eine Kette von Verbindungen bereitstellen, die den Cluster-Baum verbundener Geräte und Netzwerke bilden.
  • Jedes dieser IoT-Netzwerke kann Möglichkeiten für neue technische Merkmale, wie zum Beispiel die hierin beschriebenen, bereitstellen. Die verbesserten Technologien und Netzwerke können das exponentielle Wachstum von Geräten und Netzwerken, einschließlich der Verwendung von IoT-Netzwerken in Fog-Geräte oder -Systeme, ermöglichen. Mit zunehmender Verwendung solcher verbesserter Technologien können die IoT-Netzwerke für Selbstmanagement, Funktionsentwicklung und Zusammenarbeit entwickelt werden, ohne dass ein direktes menschliches Eingreifen erforderlich ist. Verbesserte Technologien können es IoT-Netzwerken sogar ermöglichen, ohne zentral gesteuerte Systeme zu funktionieren. Dementsprechend können die hierin beschriebenen verbesserten Technologien verwendet werden, um Netzwerkmanagement- und Betriebsfunktionen weit über aktuelle Implementierungen hinaus zu automatisieren und zu verbessern.
  • In einem Beispiel kann die Kommunikation zwischen Edge-/IoT-Verarbeitungsgeräten 504, wie zum Beispiel über die Backbone-Verbindungen 502, durch ein dezentrales System zur Authentifizierung, Autorisierung und Abrechnung (AAA) geschützt werden. In einem dezentralen AAA-System können verteilte Zahlungs-, Kredit-, Audit-, Autorisierungs- und Authentifizierungssysteme über die verbundene heterogene Netzwerkinfrastruktur hinweg implementiert werden. Dies ermöglicht es Systemen und Netzwerken, sich in Richtung autonomer Operationen zu bewegen. Bei diesen Typen von autonomen Operationen können Maschinen sogar Personalverträge abschließen und Partnerschaften mit anderen Maschinennetzwerken verhandeln. Dies kann die Erreichung gemeinsamer Ziele und ausgewogener Service-Lieferung gegen dargelegte, geplante Service-Level-Vereinbarungen ermöglichen, sowie Lösungen erreichen, die Zählung, Messungen, Rückverfolgbarkeit und Nachvollziehbarkeit ermöglichen. Die Erzeugung neuer Lieferkettenstrukturen und Methoden kann es ermöglichen, eine Vielzahl von Services ohne jegliche menschliche Beteiligung zu erzeugen, nach Wert abzubauen und zusammenbrechen zu lassen .
  • Solche IoT-Netzwerke können durch die Integration von Sensortechnologien, wie zum Beispiel Ton, Licht, elektronischer Verkehr, Gesichts- und Mustererkennung, Geruch, Vibration, in die autonomen Organisationen unter den Edge-/IoT-Verarbeitungsgeräten weiter verbessert werden. Die Integration sensorischer Systeme kann eine systematische und autonome Kommunikation und Koordination von Service-Lieferung gegen vertragliche Service-Ziele, Orchestrierung und QoS-basiertes Ausschwärmen und Zusammenführen von Ressourcen ermöglichen. Einige der individuellen Beispiele netzwerkbasierter Ressourcenverarbeitung beinhalten die folgenden.
  • Das Mesh-Netzwerk 556 kann beispielsweise durch Systeme verbessert werden, die Inline-Daten-zu-Informationen-Umwandlungen ausführen. Zum Beispiel können sich selbst bildende Ketten von Verarbeitungsressourcen, die ein Mehrfachverbindungsnetzwerk umfassen, die Umwandlung von Rohdaten in Informationen, und die Fähigkeit, zwischen Aktivposten und Ressourcen und dem damit verbundenen Management von jedem zu unterscheiden, auf eine effiziente Weise verteilen. Darüber hinaus können die richtigen Komponenten der infrastruktur- und ressourcenbasierten Vertrauens- und Service-Indizes eingefügt werden, um die Datenintegrität, -Qualität,-Sicherheit zu verbessern, und eine Metrik des Datenvertrauens zu liefern.
  • Das WLAN-Netzwerk 558 kann beispielsweise Systeme verwenden, die eine Standardkonvertierung ausführen, um eine Multi-Standard-Konnektivität bereitzustellen, wodurch es den Edge-/IoT-Verarbeitungsgeräten 504 durch Verwenden unterschiedlicher Protokolle ermöglicht wird, zu kommunizieren. Ferner können Systeme eine nahtlose Interkonnektivität über eine Multi-Standard-Infrastruktur hinweg bereitstellen, die sichtbare Internetressourcen und versteckte Internetressourcen umfasst.
  • Die Kommunikation in dem Mobilfunknetzwerk 560 kann beispielsweise durch Systeme verbessert werden, die Daten auslagern, Kommunikation auf entfernter angeordnete Geräte ausweiten, oder beides. Das LPWA-Netzwerk 562 kann Systeme beinhalten, die Nicht-Internetprotokoll (IP)- zu IP-Verbindungen, Adressierung und Weiterleitung ausführen. Ferner kann jedes der Edge-/IoT-Verarbeitungsgeräte 504 den geeigneten Transceiver für Wide-Area-Kommunikationen mit diesem Gerät beinhalten. Ferner kann jedes Edge-/IoT-Verarbeitungsgerät 504 andere Transceiver für Kommunikationen durch Verwenden zusätzlicher Protokolle und Frequenzen beinhalten. Dies wird in Bezug auf die Kommunikationsumgebung und Hardware eines in 7 dargestellten IoT-Verarbeitungsgeräts weiter diskutiert.
  • Schließlich können Cluster von Edge-/IoT-Verarbeitungsgeräten für die Kommunikation mit anderen Edge-/IoT-Verarbeitungsgeräten sowie mit einem Cloud-Netzwerk ausgestattet sein. Dies kann es den Edge-/IoT-Verarbeitungsgeräten ermöglichen, ein Ad-hoc-Netzwerk zwischen den Geräten zu bilden, wodurch es ihnen ermöglicht wird, als ein einzelnes Gerät zu funktionieren, das als ein Fog-Gerät, eine Fog-Plattform oder ein Fog-Netzwerk bezeichnet werden kann. Diese Konfiguration wird in Bezug auf 6 unten weiter diskutiert.
  • 6 veranschaulicht ein Cloud-Computing-Netzwerk in Kommunikation mit einem Mesh-Netzwerk von Edge-/IoT-Verarbeitungsgeräten (Geräte 602), die als Fog- Geräte an dem Rand des Cloud-Computing-Netzwerks arbeiten, gemäß einem Beispiel. Das Mesh-Netzwerk von Edge-/IoT-Verarbeitungsgeräten kann als Fog-Netzwerk 620 bezeichnet werden, das von einem Netzwerk von Geräten eingerichtet wird, die an dem Rand von Cloud 600 arbeiten. Zur Vereinfachung des Diagramms ist nicht jedes Edge-/IoT-Verarbeitungsgerät 602 beschriftet.
  • Das Fog-Netzwerk 620 kann als ein massiv verbundenes Netzwerk betrachtet werden, wobei eine Anzahl von Edge-/IoT-Verarbeitungsgeräten 602 in Kommunikationen miteinander sind, zum Beispiel durch Funkverbindungen 622. Das Fog-Netzwerk 620 kann eine horizontale, physikalische oder virtuelle Ressourcenplattform einrichten, von der angenommen werden kann, dass sie sich zwischen IoT-Edge-Geräten und Cloud- oder Datenzentren befindet. In einigen Beispielen kann ein Fog-Netzwerk vertikal isolierte, latenzempfindliche Anwendungen durch geschichtete, vereinigte oder verteilte Computing-, Speicherungs- und Netzwerkkonnektivitätsoperationen unterstützen. Ein Fog-Netzwerk kann jedoch auch verwendet werden, um Ressourcen und Services an dem Rand und zwischen Rand und Cloud zu verteilen. Somit sind Verweise in dem vorliegenden Dokument auf den „Rand“, „Fog“ und „Cloud“ nicht notwendigerweise speziell oder sich gegenseitig ausschließend.
  • Als ein Beispiel kann das Fog-Netzwerk 620 durch Verwenden einer durch die Open-Connectivity-Foundation™ (OCF) herausgegebenen Verbindungsspezifikation erleichtert werden. Dieser Standard ermöglicht es Geräten, sich gegenseitig zu entdecken und Kommunikationen für Verbindungen einzurichten. Es können auch andere Verbindungsprotokolle verwendet werden, einschließlich zum Beispiel unter anderem das Optimized-Link-State-Routing (OLSR) -Protokoll, das Better-Approach-To-Mobile-Ad-hoc-Networking (B.A.T.M.A.N) Routing-Protokoll, oder das OMA-Lightweight-M2M (LWM2M)-Protokoll.
  • In diesem Beispiel sind drei Typen von Edge-/IoT-Verarbeitungsgeräten 602 gezeigt, Gateways 604, Datenaggregatoren 626 und Sensoren 628, obwohl jegliche Kombinationen von Edge-/IoT-Verarbeitungsgeräten 602 und Funktionalität verwendet werden können. Die Gateways 604 können Edge-Geräte sein, die Kommunikationen zwischen der Cloud 600 und dem Fog 620 bereitstellen, und können auch die Backend-Prozessfunktion für Daten bereitstellen, die von den Sensoren 628 erhalten werden, wie zum Beispiel Bewegungsdaten, Flussdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren 626 können Daten von jeglicher Anzahl der Sensoren 628 sammeln und die Backend-Verarbeitungsfunktion für die Analyse ausführen. Die Ergebnisse, Rohdaten, oder beides können durch die Gateways 604 an die Cloud 600 weitergegeben werden. Die Sensoren 628 können zum Beispiel vollständige Edge-/IoT-Verarbeitungsgeräte 602 sein, die dazu geeignet sind, sowohl Daten zu sammeln als auch die Daten zu verarbeiten. In einigen Fällen können die Sensoren 628 zum Beispiel in ihrer Funktionalität eingeschränkter sein, indem sie die Daten sammeln und es den Datenaggregatoren 626 oder Gateways 604 ermöglichen, die Daten zu verarbeiten.
  • Kommunikationen von jeglichen der Edge-/IoT-Verarbeitungsgeräte 602 können entlang eines zweckmäßigen Pfades (zum Beispiel eines zweckmäßigsten Pfades) zwischen jeglichen der Edge-/IoT-Verarbeitungsgeräte 602 weitergegeben werden, um die Gateways 604 zu erreichen. In diesen Netzwerken stellt die Anzahl von Verbindungen eine erhebliche Redundanz bereit, die es ermöglicht, die Kommunikationen selbst bei dem Verlust einer Anzahl von Edge-/IoT-Verarbeitungsgeräten 602 aufrechtzuerhalten. Ferner kann die Verwendung eines Mesh-Netzwerks die Verwendung von Edge-/IoT-Verarbeitungsgeräten 602 ermöglichen, die sehr wenig Leistung benötigen oder in einem Abstand von Infrastrukturen platziert sind, da der Bereich zum Verbinden mit anderen Edge-/IoT-Verarbeitungsgeräten 602 viel geringer sein kann als der Bereich zum Verbinden mit den Gateways 604.
  • Das von diesen Edge-/IoT-Verarbeitungsgeräten 602 bereitgestellte Fog-Netzwerk 620 kann Geräten in der Cloud 600, wie zum Beispiel Server 606, als ein einzelnes an dem Rand der Cloud 600 platziertes Gerät, zum Beispiel ein Fog-Gerät, präsentiert werden. In diesem Beispiel können die von dem Fog-Gerät kommenden Warnmeldungen gesendet werden, ohne dass sie als von einem spezifischen Edge-/ToT-Verarbeitungsgerät 602 innerhalb des Fog 620 kommend identifiziert werden. Auf diese Weise kann der Fog 620 als eine verteilte Plattform betrachtet werden, die Computing- und Speicherungsressourcen bereitstellt, um unter anderem verarbeitende oder datenintensive Aufgaben, wie zum Beispiel Datenanalyse, Datenaggregation und maschinelles Lernen, auszuführen.
  • In einigen Beispielen können die Edge-/IoT-Verarbeitungsgeräte 602 durch Verwenden eines zwingenden Programmierstils konfiguriert sein, wobei zum Beispiel jedes Edge-/IoT-Verarbeitungsgerät 602 eine spezifische Funktion und Kommunikationspartner hat. Die das Fog-Gerät bildenden Edge-/IoT-Verarbeitungsgeräte 602 können jedoch in einem deklarativen Programmierstil konfiguriert sein, der es den Edge-/IoT-Verarbeitungsgeräten 602 ermöglicht, ihre Operationen und Kommunikationen neu zu konfigurieren, um zum Beispiel die erforderlichen Ressourcen als Reaktion auf Bedingungen, Abfragen und Gerätefehler zu bestimmen. Als ein Beispiel kann eine Abfrage eines Benutzers, der sich an einem Server 606 befindet, über die Operationen eines Untersatzes von Ausrüstung, die durch die Edge-/IoT-Verarbeitungsgeräte 602 überwacht wird, darin resultieren, dass das Fog-Gerät 620 die zur Beantwortung der Anfrage benötigten Edge-/IoT-Verarbeitungsgeräte 602, wie zum Beispiel bestimmte Sensoren 628, auswählt. Die Daten von diesen Sensoren 628 können dann durch jegliche Kombination der Sensoren 628, Datenaggregatoren 626 oder Gateways 604 aggregiert und analysiert werden, bevor sie durch das Fog-Gerät 620 an den Server 606 weitergesendet werden, um die Anfrage zu beantworten. In diesem Beispiel können Edge-/IoT-Verarbeitungsgeräte 602 in dem Fog 620 die verwendeten Sensoren 628 basierend auf der Abfrage, wie zum Beispiel das Hinzufügen von Daten von Durchflusssensoren oder Temperatursensoren, auswählen. Wenn ferner einige der Edge-/IoT-Verarbeitungsgeräte 602 nicht in Betrieb sind, können andere Edge-/IoT-Verarbeitungsgeräte 602 in dem Fog-Gerät 620 analoge Daten bereitstellen, falls verfügbar.
  • In anderen Beispielen können die oben beschriebenen Operationen und Funktionalitäten durch eine Edge-/IoT-Verarbeitungsgerätemaschine in der beispielhaften Form eines elektronischen Verarbeitungssystems ausgeführt werden, innerhalb dessen ein Satz oder eine Folge von Anweisungen ausgeführt werden kann, um das elektronische Verarbeitungssystem dazu zu veranlassen, jegliche der hierin diskutierten Methoden auszuführen, gemäß einem Beispiel. Die Maschine kann ein Edge-/IoT-Verarbeitungsgerät oder ein IoT-Gateway sein, einschließlich einer Maschine, die durch Aspekte eines Personalcomputers (PC), eines Tablet-PC, eines Personal-Digital-Assistant (PDA), eines Mobiltelefons oder Smartphones oder jeglicher Maschine verkörpert ist, die dazu geeignet ist, Anweisungen (sequentiell oder anderweitig) auszuführen, die Aktionen spezifizieren, die durch diese Maschine ergriffen werden sollen.
  • Ferner sollen diese und ähnliche Beispiele für ein prozessorbasiertes System jeglichen Satz von einer oder mehreren Maschinen beinhalten, die durch einen Prozessor, einen Satz von Prozessoren oder eine Verarbeitungsschaltung (zum Beispiel eine Maschine in der Form eines Computers, einer UE, eines MEC-Verarbeitungsgeräts, eines IoT-Verarbeitungsgeräts, usw.) gesteuert oder betrieben werden, um Anweisungen einzeln oder gemeinsam auszuführen, um jegliche eine oder mehrere der hierin diskutierten Methoden auszuführen. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Verarbeiten (zum Beispiel Verarbeiten, Steuern, Erzeugen, Beurteilen, usw.) durch eine solche Verarbeitungsschaltung verkörpert sein.
  • 7 veranschaulicht ein Blockdiagramm eines Cloud-Computing-Netzwerks, oder Cloud 700, in Kommunikation mit einer Anzahl von Edge-/IoT-Verarbeitungsgeräten, gemäß einem Beispiel. Das Cloud-Computing-Netzwerk (oder „Cloud“) 700 kann das Internet darstellen, oder kann ein Local-Area-Network (LAN) oder ein Wide-Area-Network (WAN), wie zum Beispiel ein proprietäres Netzwerk für ein Unternehmen, sein. Die Edge-/IoT-Verarbeitungsgeräte können jegliche Anzahl unterschiedlicher Gerätetypen beinhalten, die in verschiedenen Kombinationen gruppiert sind. Zum Beispiel kann Verkehrssteuerungsgruppe 706 Edge-/IoT-Verarbeitungsgeräte entlang von Straßen in einer Stadt beinhalten. Diese Edge-/IoT-Verarbeitungsgeräte können Ampeln, Verkehrsflussüberwacher, Kameras, Wettersensoren und dergleichen beinhalten. Die Verkehrssteuerungsgruppe 706 oder andere Untergruppen können über drahtgebundene oder drahtlose Verbindungen 708, wie zum Beispiel LPWA-Verbindungen, optische Verbindungen und dergleichen, mit der Cloud 700 in Kommunikation sein. Ferner kann drahtgebundenes oder drahtloses Unternetzwerk 712 es den Edge-/IoT-Verarbeitungsgeräten ermöglichen, miteinander zu kommunizieren, wie zum Beispiel durch ein Local-Area-Network, ein drahtloses Local-Area-Network und dergleichen. Die Edge-/IoT-Verarbeitungsgeräte können ein anderes Gerät verwenden, wie zum Beispiel Gateway 710 oder 728, um mit entfernt angeordneten Standorten, wie zum Beispiel der Cloud 700 zu kommunizieren; die Edge-/IoT-Verarbeitungsgeräte können auch einen oder mehrere Server 730 verwenden, um die Kommunikation mit der Cloud 700 oder mit dem Gateway 710 zu erleichtern. Zum Beispiel können der eine oder die mehreren Server 730 als ein Zwischennetzwerkknoten arbeiten, um eine lokale Edge-Cloud- oder Fog-Implementierung zwischen einem lokalen Netzwerk zu unterstützen. Ferner kann das dargestellte Gateway 728 in einer Cloud-zu-Gateway-zuvielen-Edge-Gerätekonfiguration arbeiten, zum Beispiel wenn verschiedene Edge-/IoT-Verarbeitungsgeräte 714, 720, 724 auf eine Zuweisung und Verwendung von Ressourcen in der Cloud 700 beschränkt oder dynamisch sind.
  • Andere beispielhafte Gruppen von Edge-/IoT-Verarbeitungsgeräten können unter vielen anderen entfernt angeordnete Wetterstationen 714, lokale Informationsterminals 716, Alarmsysteme 718, Geldautomaten 720, Alarmtafeln 722 oder sich bewegende Fahrzeuge, wie zum Beispiel Notfallfahrzeuge 724 oder andere Fahrzeuge 726, beinhalten. Jedes dieser Edge-/IoT-Verarbeitungsgeräte kann mit anderen Edge-/IoT-Verarbeitungsgeräten, mit Servern 704, mit einer anderen IoT-Fog-Plattform oder einem anderen IoT-Fog-System oder einer Kombination darin in Kommunikation sein. Die Gruppen von Edge-/IoT-Verarbeitungsgeräten können in verschiedenen Wohn-, Geschäfts- und Industrieumgebungen (einschließlich sowohl in privaten als auch öffentlichen Umgebungen) eingesetzt werden.
  • Wie aus 7 gesehen werden kann, kann eine große Anzahl von Edge-/IoT-Verarbeitungsgeräten durch die Cloud 700 kommunizieren. Dies kann es unterschiedlichen Edge-/IoT-Verarbeitungsgeräten ermöglichen, autonom Informationen anzufordern oder anderen Geräten bereitzustellen. Zum Beispiel kann eine Gruppe von Edge-/IoT-Verarbeitungsgeräten (zum Beispiel die Verkehrssteuerungsgruppe 706) eine aktuelle Wettervorhersage von einer Gruppe von entfernt angebrachten Wetterstationen 714 anfordern, die die Vorhersage ohne menschliches Eingreifen bereitstellen können. Ferner kann ein Notfallfahrzeug 724 durch einen Geldautomaten 720 alarmiert werden, dass gerade ein Einbruch stattfindet. Wenn das Notfallfahrzeug 724 in Richtung des Geldautomaten 720 fährt, kann es auf die Verkehrssteuerungsgruppe 706 zugreifen, um eine Freigabe für den Standort anzufordern, zum Beispiel, indem Ampeln auf Rot geschaltet werden, um Querverkehr an einer Kreuzung für eine genügend lange Zeit zu blockieren, damit das Notfallfahrzeug 724 ungehinderten Zugang zu der Kreuzung hat.
  • Cluster von Edge-/IoT-Verarbeitungsgeräten, wie zum Beispiel die entfernt angebrachten Wetterstationen 714 oder die Verkehrssteuerungsgruppe 706, können ausgestattet sein, um mit anderen Edge-/IoT-Verarbeitungsgeräten sowie mit der Cloud 700 zu kommunizieren. Dies kann es den Edge-/IoT-Verarbeitungsgeräten erlauben, ein Ad-hoc-Netzwerk zwischen den Geräten zu bilden, wodurch es ihnen erlaubt wird, als ein einzelnes Gerät zu funktionieren, was als ein Fog-Netzwerk oder -System bezeichnet werden kann.
  • 8 stellt einen Überblick über Schichten verteilter Berechnungen bereit, die in einem Edge-Computing-System eingesetzt werden, gemäß einem Beispiel. Insbesondere stellt 8 allgemein ein Edge-Computing-System zum Bereitstellen von Edge-Services und Anwendungen für Entitäten mehrerer Interessengruppen dar, wie auf einen oder mehrere Client-Rechenknoten 802, einen oder mehrere Edge-Gateway-Knoten 812, einen oder mehrere Edge-Aggregationsknoten 822, einen oder mehrere Kerndatenzentren 832 und globale Netzwerk-Cloud 842 verteilt, die über Schichten des Netzwerks hinweg verteilt sind. Die Implementierung des Edge-Computing-Systems kann bei einem oder im Auftrag eines Telecommunication-Service-Provider („Telco“ oder „TSP“), Internet-of-Things-Service-Provider, Cloud-Service-Provider (CSP), einer Unternehmensentität oder jeglicher anderen Anzahl von Entitäten bereitgestellt werden.
  • Jeder Knoten oder jedes Gerät des Edge-Computing-Systems ist auf einer bestimmten Schicht platziert, die Schichten 810, 820, 830, 840 und 850 entsprechen. Zum Beispiel sind die Client-Rechenknoten 802 jeder auf einer Endpunktschicht 810 platziert, während jeder der Edge-Gateway-Knoten 812 auf einer Edge-Geräteschicht 820 (lokale Ebene) des Edge-Computing-Systems platziert ist. Zusätzlich ist jeder der Edge-Aggregationsknoten 822 (und/oder Fog-Geräte 824, wenn mit oder unter Fog-Netzwerkkonfiguration 826 angeordnet oder betrieben) auf Netzwerkzugangsschicht 830 (einer Zwischenstufe) platziert. Fog-Computing (oder „Fogging“) bezieht sich im Allgemeinen auf Erweiterungen des Cloud-Computing bis zu dem Rand eines Unternehmensnetzwerks, typischerweise in einem koordinierten verteilten Netzwerk oder Mehrknotennetzwerk. Einige Formen des Fog-Computing stellen den Einsatz von Rechen-, Speicherungs- und Netzwerk-Services zwischen Endgeräten und Cloud-Computing-Datenzentren im Auftrag der Cloud-Computing-Standorte bereit. Solche Formen des Fog-Computing stellen Operationen bereit, die mit dem hierin diskutierten Edge-Computing übereinstimmen; viele der hierin diskutierten Edge-Computing-Aspekte sind auf Fog-Netzwerke, Fogging und Fog-Konfigurationen anwendbar. Ferner können Aspekte der hierin diskutierten Edge-Computing-Systeme als ein Fog konfiguriert sein, oder Aspekte von Fog können in eine Edge-Computing-Architektur integriert sein.
  • Das Kerndatenzentrum 832 ist auf einer Core-Network-Schicht 840 (einer regionalen oder geografisch zentralen Ebene) platziert, während die globale Netzwerk-Cloud 842 auf einer Cloud-Datenzentrumsschicht 850 (einer nationalen oder globalen Schicht) platziert ist. Die Verwendung von „Kern“ wird als ein Begriff für einen zentralisierten Netzwerkstandort - tiefer in dem Netzwerk-bereitgestellt, auf den mehrere Edge-Knoten oder Komponenten zugreifen können; ein „Kern“ bezeichnet jedoch nicht unbedingt das „Zentrum“ oder den tiefsten Standort des Netzwerks. Dementsprechend kann das Kerndatenzentrum 832 innerhalb, an oder nahe der Edge-Cloud 170 platziert sein.
  • Obwohl eine veranschaulichende Anzahl von Client-Rechenknoten 802, Edge-Gateway-Knoten 812, Edge-Aggregationsknoten 822, Kerndatenzentren 832 und globalen Netzwerk-Clouds 842 in 8 gezeigt sind, ist darauf hinzuweisen, dass das Edge-Computing-System mehr oder weniger Geräte oder Systeme auf jeder Schicht beinhalten kann. Zusätzlich nimmt, wie in 8 gezeigt, die Anzahl der Komponenten jeder Schicht 810, 820, 830, 840 und 850 im Allgemeinen auf jeder niedrigeren Ebene (das heißt wenn sie sich näher an Endpunkte bewegen) zu. Als solches kann ein Edge-Gateway-Knoten 812 mehrere Client-Rechenknoten 802 bedienen, und ein Edge-Aggregationsknoten 822 kann mehrere Edge-Gateway-Knoten 812 bedienen.
  • In Übereinstimmung mit den hierin bereitgestellten Beispielen kann jeder Client-Rechenknoten 802 als jeglicher Typ von Endpunktkomponente, Gerät, Hilfsmittel oder „Ding“ verkörpert sein, das dazu geeignet ist, als ein Produzent oder Konsument von Daten zu kommunizieren. Ferner bedeutet das Etikett „Knoten“ oder „Gerät“, wie in dem Edge-Computing-System 800 verwendet, nicht notwendigerweise, dass ein solcher Knoten oder ein solches Gerät in einer Client- oder Slave-Rolle arbeitet; vielmehr beziehen sich jegliche der Knoten oder Geräte in dem Edge-Computing-System 800 auf einzelne Entitäten, Knoten oder Subsysteme, die spezielle oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 170 zu erleichtern oder zu verwenden.
  • Als solches wird die Edge-Cloud 170 von Netzwerkkomponenten und Funktionsmerkmalen gebildet, die durch die und innerhalb der Edge-Gateway-Knoten 812 und der Edge-Aggregationsknoten 822 der Schichten 820 bzw. 830 betrieben werden. Die Edge-Cloud 170 kann als jeglicher Netzwerktyp ausgeführt sein, der Edge-Computing- und/oder Speicherungsressourcen bereitstellt, die in der Nähe von Radio-Access-Network (RAN) -fähigen Endpunktgeräten (zum Beispiel mobilen Computing-Geräten, IoT-Geräten, Smart-Geräten, usw.) platziert sind, die in 8 als der Client-Rechenknoten 802 gezeigt sind. Mit anderen Worten kann die Edge-Cloud 170 als ein „Rand“ betrachtet werden, der die Endpunktgeräte und herkömmlichen Zugangspunkte für Mobilfunknetze verbindet, die als ein Eintrittspunkt in Core-Networks von Service-Anbietern dienen, einschließlich Trägernetzwerken (zum Beispiel Global-System-for-Mobile-Communikations (GSM)-Netzwerke, Long-Term-Evolution (LTE) -Netzwerke, 5G-Netzwerke, usw.), während sie gleichzeitig Speicherungs- und/oder Rechenfähigkeiten bereitstellen. Anstelle von oder in Kombination mit solchen 3GPP-Trägernetzwerken können auch andere Typen und Formen des Netzwerkzugangs (zum Beispiel Wi-Fi, drahtlose Netzwerke mit großer Reichweite) verwendet werden.
  • In einigen Beispielen kann die Edge-Cloud 170 einen Abschnitt einer Fog-Netzwerkkonfiguration 826 (zum Beispiel ein Netzwerk von Fog-Geräten 824, nicht im Detail gezeigt) bilden oder auf andere Weise einen Eintrittspunkt in diese hinein oder darüber hinweg bereitstellen, die als eine horizontale und verteilte Architektur auf Systemebene verkörpert werden kann, die Ressourcen und Services verteilt, um eine spezifische Funktion auszuführen. Beispielsweise kann ein koordiniertes und verteiltes Netzwerk von Fog-Geräten 824 Computing-, Speicherungs-, Steuerungs- oder Netzwerkaspekte in dem Zusammenhang mit einer IoT-Systemanordnung ausführen. Andere vernetzte, aggregierte und verteilte Funktionen können in der Edge-Cloud 170 zwischen der Kerndatenzentrumsschicht 850 und den Client-Endpunkten (zum Beispiel Client-Rechenknoten 802) existieren. Einige von diesen werden in den folgenden Abschnitten in dem Zusammenhang mit Netzwerkfunktionen oder Service-Virtualisierung diskutiert, einschließlich der Verwendung von virtuellen Rändern und virtuellen Services, die für mehrere Interessenvertreter orchestriert werden.
  • Wie unten detaillierter diskutiert, arbeiten die Edge-Gateway-Knoten 812 und die Edge-Aggregationsknoten 822 zusammen, um den Client-Rechenknoten 802 verschiedene Edge-Services und Sicherheit bereitzustellen. Darüber hinaus kann, da jeder Client-Rechenknoten 802 stationär oder mobil sein kann, jeder Edge-Gateway-Knoten 812 mit anderen Edge-Gateway-Geräten zusammenarbeiten, um gegenwärtig bereitgestellte Edge-Services und Sicherheit zu verbreiten, wie sich der entsprechende Client-Rechenknoten 802 um einen Bereich bewegt. Um dies zu tun, kann jeder der Edge-Gateway-Knoten 812 und/oder Edge-Aggregationsknoten 822 mehrere Mandanten und mehrere Interessenvertretungs-Konfigurationen unterstützen, bei denen Services von (oder gehostet für) mehreren Serviceanbietern und mehreren Verbrauchern über einzelne oder mehrere Rechengeräte hinweg unterstützt und koordiniert werden können.
  • In weiteren Beispielen können jegliche der unter Bezugnahme auf die vorliegenden Edge-Computing-Systeme und -Umgebung diskutierten Rechenknoten oder Geräte basierend auf den in 8- 10 dargestellten Komponenten erfüllt werden. Jeder Edge-Computing-Knoten kann als ein Typ von Gerät, Hilfsmittel, Computer oder anderes „Ding“ verkörpert sein, das dazu geeignet ist, mit einer anderen Edge-, Netzwerk- oder Endpunktkomponente zu kommunizieren. Zum Beispiel kann ein Edge-Computing-Gerät als ein Smartphone, ein mobiles Rechengerät, ein intelligentes Hilfsmittel, ein fahrzeuginternes Rechensystem (zum Beispiel ein Navigationssystem) oder ein anderes Gerät oder System verkörpert sein, das dazu geeignet ist, die beschriebenen Funktionen auszuführen.
  • 9 stellt einen Überblick über beispielhafte Komponenten für die Berechnung bereit, die an einem Rechenknoten in einem Edge-Computing-System eingesetzt werden, gemäß einem Beispiel. 10 stellt einen weiteren Überblick über beispielhafte Komponenten innerhalb eines Computing-Geräts in einem Edge-Computing-System zum Implementieren der hierin beschriebenen Techniken (zum Beispiel Operationen, Prozesse, Verfahren und Methoden) bereit, gemäß einem Beispiel. In dem vereinfachten in 9 dargestellten Beispiel beinhaltet Edge-Rechenknoten 900 Rechenmaschine (hierin auch bezeichnet als „Rechenschaltung“) 902, Input/Output (I/O) -Subsystem 908, Datenspeicherung 910, Kommunikationsschaltungssubsystem 912 und optional ein oder mehrere Peripheriegeräte 914. In anderen Beispielen kann jedes Rechengerät andere oder zusätzliche Komponenten beinhalten, wie zum Beispiel solche, die in Personal- oder Server-Computing-Systemen verwendet werden (zum Beispiel eine Anzeige, Peripheriegeräte, usw.). Zusätzlich können in einigen Beispielen eine oder mehrere der veranschaulichenden Komponenten in einer anderen Komponente enthalten sein, oder andernfalls einen Bereich davon bilden.
  • Der Rechenknoten 900 kann als jeglicher Typ von Maschine, Gerät oder Sammlung von Geräten verkörpert sein, die dazu geeignet sind, verschiedene Rechenfunktionen auszuführen. In einigen Beispielen kann der Rechenknoten 900 als ein einzelnes Gerät, wie zum Beispiel eine integrierte Schaltung, ein eingebettetes System, ein Field-Programmable-Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder Gerät verkörpert sein. In dem veranschaulichenden Beispiel beinhaltet der Rechenknoten 900 Prozessor 904 und Speicher 906, oder ist als diese verkörpert. Der Prozessor 904 kann als jeglicher Prozessortyp verkörpert sein, der dazu geeignet ist, die hierin beschriebenen Funktionen auszuführen (zum Beispiel Ausführen einer Anwendung). Zum Beispiel kann der Prozessor 904 als Multicore-Prozessor(en), Mikrocontroller oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerungsschaltung verkörpert sein. In einigen Beispielen kann der Prozessor 904 als ein FPGA, ein Application-Specific-Integrated-Circuit (ASIC), eine rekonfigurierbare Hardware oder Hardware-Schaltung oder eine andere spezialisierte Hardware verkörpert sein, diese beinhalten oder damit gekoppelt sein, um die Ausführung der hierin beschriebenen Funktionen zu erleichtern.
  • Der Hauptspeicher 906 kann als jeglicher Typ von flüchtigem (zum Beispiel Dynamic-Random-Access-Memory (DRAM), usw.) oder nichtflüchtigem Speicher oder Datenspeicherung verkörpert sein, die dazu geeignet ist, die hierin beschriebenen Funktionen auszuführen. Der flüchtige Speicher kann ein Speicherungsmedium sein, das Leistung benötigt, um den Status der durch das Medium gespeicherten Daten aufrechtzuerhalten. Nicht beschränkende Beispiele von flüchtigem Speicher können verschiedene Typen von Random-Access-Memory (RAM), wie zum Beispiel DRAM oder Static-Random-Access-Memory (SRAM), beinhalten. Ein bestimmter DRAM-Typ, der in einem Speichermodul verwendet werden kann, ist der Synchronous-Dynamic-Random-Access-Memory (SDRAM).
  • In einem Beispiel ist das Speichergerät ein blockadressierbares Speichergerät, wie zum Beispiel jene, die auf NAND- oder NOR-Technologien basieren. Ein Speichergerät kann auch ein dreidimensionales Kreuzungspunktspeichergerät (zum Beispiel Intel 3D XPoint™-Speicher) oder ein anderes byte-adressierbares nichtflüchtiges Write-in-Place-Speichergerät beinhalten. Das Speichergerät kann sich auf den Chip selbst und/oder auf ein gepacktes Speicherprodukt beziehen. In einigen Beispielen kann der 3D-Kreuzungspunktspeicher (zum Beispiel Intel 3D XPoint™-Speicher) eine transistorlose stapelbare Kreuzungspunktarchitektur umfassen, in der Speicherzellen an dem Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind, und in der Bit-Speicherung auf einer Änderung des Hauptmassenwiderstands basiert. In einigen Beispielen kann der gesamte oder ein Abschnitt des Hauptspeichers 906 in den Prozessor 904 integriert sein. Der Hauptspeicher 906 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie zum Beispiel eine oder mehrere Anwendungen, durch die Anwendung(en) bearbeitete Daten, Bibliotheken und Treiber.
  • Die Rechenschaltung 902 ist über das I/O-Subsystem 908 kommunizierend mit anderen Komponenten des Rechenknotens 900 gekoppelt, die als Schaltung und/oder Komponenten zur Erleichterung von Eingabe-/Ausgabeoperationen mit der Rechenschaltung 902 (zum Beispiel mit dem Prozessor 904 und/oder dem Hauptspeicher 906) und andere Komponenten der Rechenschaltung 902 verkörpert sein können. Zum Beispiel kann das I/O-Subsystem 908 als Speichersteuerungs-Hubs, Eingabe-/Ausgabesteuerungs-Hubs, integrierte Sensor-Hubs, Firmware-Geräte, Kommunikationsverbindungen (zum Beispiel Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterplattenspuren, usw.) und/oder andere Komponenten und Subsysteme zur Erleichterung der Eingabe-/Ausgabeoperationen verkörpert sein, oder diese andernfalls beinhalten. In einigen Beispielen kann das I/O-Subsystem 908 einen Abschnitt eines System-on-a-Chip (SoC) bilden, und kann zusammen mit einem oder mehreren des Prozessors 904, dem Hauptspeicher 906 und anderen Komponenten der Rechenschaltung 902 in der Rechenschaltung 902 enthalten sein.
  • Das eine oder die mehreren veranschaulichenden Datenspeicherungsgeräte 910 können als jeglicher Typ von Gerät verkörpert sein, das für Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert ist, wie zum Beispiel Speichergeräte und - Schaltungen, Speicherkarten, Festplattenlaufwerke , Solid-State-Laufwerke oder andere Datenspeicherungsgeräte. Jedes Datenspeicherungsgerät 910 kann eine Systempartition beinhalten, die Daten und Firmware-Code für das Datenspeicherungsgerät 910 speichert. Jedes Datenspeicherungsgerät 910 kann auch eine oder mehrere Betriebssystempartitionen beinhalten, die Datendateien und ausführbare Dateien für Betriebssysteme speichern, abhängig zum Beispiel von dem Typ des Rechenknotens 900.
  • Das Kommunikationsschaltungssubsystem 912 kann als jegliche Kommunikationsschaltung, -Gerät oder Sammlung davon verkörpert sein, die dazu geeignet ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltung 902 und einem anderen Rechengerät (zum Beispiel einem Edge-Gateway-Knoten 812 des Edge-Computing-Systems 800) zu ermöglichen. Das Kommunikationsschaltungssubsystem 912 kann dazu ausgelegt sein, jegliche eine oder mehrere Kommunikationstechnologien (zum Beispiel drahtgebundene oder drahtlose Kommunikationen) und zugehörige Protokolle (zum Beispiel ein zellulares Netzwerkprotokoll, wie zum Beispiel einen 3GPP 4G- oder 5G-Standard, ein drahtloses Local-Area-Network-Protokoll, wie zum Beispiel IEEE 802.11/Wi-Fi®, ein drahtloses Wide-Area-Network-Protokoll, Ethernet, Bluetooth® usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
  • Das veranschaulichende Kommunikationsschaltungssubsystem 912 beinhaltet Network-Interface-Controller (NIC) 920, der auch als ein Host-Fabric-Interface (HFI) bezeichnet werden kann. Der NIC 920 kann als eine oder mehrere Add-In-Platten, Tochterkarten, Netzwerkschnittstellenkarten, Controller-Chips, Chipsätze oder andere Geräte verkörpert sein, die durch den Rechenknoten 900 verwendet werden können, um eine Verbindung mit einem anderen Rechengerät (zum Beispiel einem Edge-Gateway-Knoten 812) herzustellen. In einigen Beispielen kann der NIC 920 als Teil eines System-on-a-Chip (SoC) verkörpert sein, der einen oder mehrere Prozessoren beinhaltet, oder kann in einem Multichip-Paket enthalten sein, das auch einen oder mehrere Prozessoren enthält. In einigen Beispielen kann der NIC 920 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide für den NIC 920 lokal sind. In solchen Beispielen kann der lokale Prozessor des NIC 920 dazu geeignet sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltung 902 auszuführen. Zusätzlich oder alternativ kann in solchen Beispielen der lokale Speicher des NIC 920 in eine oder mehrere Komponenten des Client-Rechenknotens auf der Plattenebene, Socket-Ebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
  • Zusätzlich kann in einigen Beispielen jeder Rechenknoten 900 ein oder mehrere Peripheriegeräte 914 beinhalten. Solche Peripheriegeräte 914 können jeglichen Typ von Peripheriegerät beinhalten, der in einem Rechengerät oder Server zu finden ist, wie zum Beispiel Audioeingabegeräte, eine Anzeige, andere Eingabe-/Ausgabegeräte, Schnittstellengeräte und/oder andere Peripheriegeräte, abhängig von dem bestimmten Typ des Rechenknotens 900. In weiteren Beispielen kann der Rechenknoten 900 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Computing-System (zum Beispiel Client-Rechenknoten 802, Edge-Gateway-Knoten 812, Edge-Aggregationsknoten 822) oder in ähnlichen Formen von Hilfsmitteln, Computern, Subsystemen, Schaltkreisen, oder andere Komponenten verkörpert sein.
  • In einem detaillierteren Beispiel veranschaulicht 10 ein Blockdiagramm eines Beispiels von Komponenten, die in Edge-Computing-Knoten 1050 vorhanden sein können, um die hierin beschriebenen Techniken (zum Beispiel Operationen, Prozesse, Verfahren und Methoden) zu implementieren. Der Edge-Computing-Knoten 1050 kann jegliche Kombinationen der oben genannten Komponenten beinhalten, und er kann jegliches Gerät beinhalten, das mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendet werden kann. Die Komponenten können als IC, Abschnitte davon, spezielle elektronische Geräte, oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 1050 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems enthalten sind, implementiert sein.
  • Der Edge-Computing-Knoten 1050 kann eine Verarbeitungsschaltung in der Form von Prozessor 1052 beinhalten, der ein Mikroprozessor, ein Multicore-Prozessor, ein Multithread-Prozessor, ein Ultra-Niederspannungsprozessor, ein eingebetteter Prozessor oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 1052 kann ein Teil eines System-on-a-Chip (SoC) sein, in dem der Prozessor 1052 und andere Komponenten zu einer einzelnen integrierten Schaltung oder einem einzelnen Paket, wie zum Beispiel den Edison™ oder Galileo™-SoC-Platten der Intel Corporation, Santa Clara, Kalifornien, gebildet sind. Als ein Beispiel kann der Prozessor 1052 einen Intel® Architecture Core™ -basierten Prozessor, wie zum Beispiel einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7- oder einen MCU-Klassen-Prozessor, oder einen anderen solchen von Intel® erhältlichen Prozessor beinhalten. Es kann jedoch jegliche Anzahl von anderen Prozessoren verwendet werden, wie zum Beispiel verfügbar von Advanced-Micro-Devices, Inc. (AMD) aus Sunnyvale, Kalifornien, einem MIPS-basierten Design von MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, einem ARM-basierten Design, lizenziert von ARM Holdings, Ltd., oder einem Kunden davon oder deren Lizenznehmern oder Anwendern. Die Prozessoren können Einheiten, wie zum Beispiel einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™ -Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™ -Prozessor von Texas Instruments, Inc., beinhalten.
  • Der Prozessor 1052 kann mit Systemspeicher 1054 über Verbindung 1056 (zum Beispiel einen Bus) kommunizieren. Es kann jegliche Anzahl von Speichergeräten verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher ein Random-Access-Memory (RAM) gemäß einem Design des Joint-Electron-Devices-Engineering-Council (JEDEC) sein, wie zum Beispiel die DDR- oder mobilen DDR-Standards (zum Beispiel LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Speicherkomponente einem von JEDEC veröffentlichten DRAM-Standard entsprechen, wie zum Beispiel JESD79F für DDR SDRAM, JESD79-2F für DDR2 SDRAM, JESD79-3F für DDR3 SDRAM, JESD79-4A für DDR4 SDRAM, JESD209 für Low Power DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden, und Kommunikationsschnittstellen der Speicherungsgeräte, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichergeräte aus jeglicher Anzahl von unterschiedlichen Pakettypen, wie zum Beispiel Single-Die-Package (SDP), Dual-Die-Package (DDP) oder Quad-Die-Package (QDP), bestehen. In einigen Beispielen können diese Geräte direkt auf ein Motherboard gelötet sein, um eine Lösung mit niedrigerem Profil bereitzustellen, während in anderen Beispielen die Geräte als ein oder mehrere Speichermodule konfiguriert sind, die wiederum über ein gegebenes Verbindungselement mit dem Motherboard gekoppelt sind. Es kann jegliche Anzahl anderer Speicherimplementierungen verwendet werden, wie zum Beispiel andere Typen von Speichermodulen, zum Beispiel Dual-Inline-Memory-Modules (DIMM) unterschiedlicher Varianten, einschließlich, aber nicht beschränkt auf microDIMM oder MiniDIMM.
  • Um eine dauerhafte Speicherung von Informationen, wie zum Beispiel Daten, Anwendungen, Betriebssystemen, usw., bereitzustellen, kann Speicherung 1058 auch über die Verbindung 1056 mit dem Prozessor 1052 gekoppelt werden. In einem Beispiel kann die Speicherung 1058 über ein Solid-State-Disk-Drive (SSDD) implementiert werden. Andere Geräte, die für die Speicherung 1058 verwendet werden können, beinhalten Flash-Speicherkarten, wie zum Beispiel SD-Karten, microSD-Karten, XD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. In einem Beispiel kann das Speichergerät Speichergeräte sein oder beinhalten, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenwerten, NOR-Flash-Speicher, ein- oder mehrstufigen Phase-Change-Memory (PCM), einen resistiven Speicher, Nanodrahtspeicher, Ferroelectric-Transistor-Random-Access-Memory (FeTRAM), Anti-Ferroelektrischen Speicher, Magnetoresistive-Random-Access-Memory (MRAM), der Memristortechnologie enthält, Widerstandsspeicher einschließlich Metalloxidbasis, Sauerstoff-Leerstellenbasis und Conductive-Bridge-Random-Access-Memory (CB-RAM) oder Spin-Transfer-Torque (STT) -MRAM, ein auf Spintronic-Magnet-Junction-Memory basierendes Gerät, ein auf Magnetic Tunneling Junction (MTJ) basierendes Gerät, ein auf DW (Domain Wall) und SOT (Spin-Orbit-Transfer) basierendes Gerät, ein auf Thyristoren basierendes Speichergerät oder eine Kombination aus jeglichen der obigen, oder einen anderen Speicher verwenden.
  • In Implementierungen mit geringer Leistung kann die Speicherung 1058 ein On-Chip-Speicher oder Register sein, die dem Prozessor 1052 zugeordnet sind. In einigen Beispielen kann die Speicherung 1058 jedoch durch Verwenden eines Mikro-Hard-Disk-Drive (HDD) implementiert werden. Ferner kann jegliche Anzahl neuer Technologien für die Speicherung 1058 zusätzlich zu oder anstelle der beschriebenen Technologien, wie zum Beispiel unter anderem Widerstandsänderungsspeicher, Phasenänderungsspeicher, holographische Speicher oder chemische Speicher, verwendet werden.
  • Die Komponenten können über die Verbindung 1056 kommunizieren. Die Verbindung 1056 kann jegliche Anzahl von Technologien beinhalten, einschließlich Industry-Standard-Architecture (ISA), Extended-ISA (EISA), Peripheral-Component-Interconnect (PCI), Peripheral-Component-Interconnect-extended (PCIx), PCI-express (PCIe), oder jeglicher Anzahl anderer Technologien. Die Verbindung 1056 kann zum Beispiel ein in einem SoC-basierten System verwendeter proprietärer Bus sein. Es können andere Bussysteme enthalten sein, wie zum Beispiel unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
  • Die Verbindung 1056 kann den Prozessor 1052 mit Transceiver 1066 für Kommunikationen mit verbundenen Edge-Geräten 1062 koppeln. Der Transceiver 1066 kann jegliche Anzahl von Frequenzen und Protokollen verwenden, wie zum Beispiel unter anderem 2,4-Gigahertz (GHz) -Übertragungen unter dem IEEE 802.15.4-Standard durch Verwenden des Bluetooth®-Low-Energy (BLE) -Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Für die Verbindungen zu den verbundenen Edge-Geräten 1062 kann jegliche Anzahl von Funkgeräten verwendet werden, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind. Zum Beispiel kann eine Wireless-Local-Area-Network (WLAN) -Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem Standard 802.11 des Institute-of-Electrical-and-Electronics-Engineers (IEEE) zu implementieren. Zusätzlich kann eine drahtlose Wide-Area-Kommunikation, zum Beispiel gemäß einem Zellen- oder einem anderen drahtlosen Wide-Area-Protokoll, über eine Wireless-Wide-Area-Network (WWAN) -Einheit auftreten.
  • Der drahtlose Netzwerk-Transceiver 1066 (oder mehrere Transceiver) kann durch Verwenden mehrerer Standards oder Funkgeräte für die Kommunikation in einem unterschiedlichen Bereich kommunizieren. Zum Beispiel kann der Edge-Computing-Knoten 1050 mit nahen Geräten, zum Beispiel innerhalb von etwa 10 Metern, kommunizieren, wobei ein auf BLE basierender lokaler Transceiver oder ein anderes Funkgerät mit geringer Leistung verwendet wird, um Leistung zu sparen. Weiter entfernte verbundene Edge-Geräte 1062, zum Beispiel innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät bei unterschiedlichen Leistungsstufen oder über separate Transceiver, zum Beispiel einen lokalen Transceiver, der BLE verwendet, und einen separaten Mesh-Transceiver, der ZigBee verwendet, stattfinden.
  • Ein drahtloser Netzwerk-Transceiver 1066 (zum Beispiel ein Funk-Transceiver) kann enthalten sein, um mit Geräten oder Services in Edge-Cloud 1090 über Local- oder Wide-Area-Network-Protokolle zu kommunizieren. Der drahtlose Netzwerk-Transceiver 1066 kann ein LPWA-Transceiver sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 1050 kann über einen weiten Bereich durch Verwenden von LoRaWAN™ (Long-Range-Wide-Area-Network), entwickelt durch Semtech und die LoRa Alliance, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit jeglicher Anzahl anderer Cloud-Transceiver, die Kommunikationen mit großer Reichweite und geringer Bandbreite implementieren, wie zum Beispiel Sigfox, und anderen Technologien verwendet werden. Ferner können andere Kommunikationstechniken, wie zum Beispiel das in der IEEE 802.15.4e-Spezifikation beschriebene Zeitschlitzkanalspringen, verwendet werden.
  • Jegliche Anzahl anderer Funkkommunikationen und -Protokolle kann zusätzlich zu den für den drahtlosen Netzwerk-Transceiver 1066 erwähnten Systemen, wie hierin beschrieben, verwendet werden. Zum Beispiel kann der Transceiver 1066 einen zellularen Transceiver beinhalten, der Spread-Spectrum (SPA/SAS) -Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann jegliche Anzahl anderer Protokolle verwendet werden, wie zum Beispiel Wi-Fi®-Netzwerke für Kommunikationen mit mittlerer Geschwindigkeit und die Bereitstellung von Netzwerkkommunikationen. Der Transceiver 1066 kann Funkgeräte beinhalten, die mit jeglicher Anzahl von 3GPP-Spezifikationen (Third-Generation-Partnership-Project), wie zum Beispiel Long-Term-Evolution (LTE) und 5th-Generation (5G)-Kommunikationssystemen, die am Ende der vorliegenden Offenbarung detaillierter diskutiert werden, kompatibel sind. Es kann Network-Interface-Controller (NIC) 1068 enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 1090 oder zu anderen Geräten, wie zum Beispiel den verbundenen Edge-Geräten 1062 (die zum Beispiel in einem Mesh arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen, oder kann auf anderen Netzwerktypen, wie zum Beispiel unter anderem Controller-Area-Network (CAN), Local-Interconnect-Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET, basieren. Es kann ein zusätzlicher NIC 1068 enthalten sein, um die Verbindung zum Beispiel zu einem zweiten Netzwerk zu ermöglichen, wobei ein erster NIC 1068 Kommunikationen mit der Cloud über Ethernet bereitstellt, und ein zweiter NIC 1068 Kommunikationen mit anderen Geräten über einen anderen Netzwerktyp bereitstellt.
  • Angesichts der Vielzahl von Typen anwendbarer Kommunikationen von dem Gerät zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltung, die durch das Gerät verwendet wird, jegliche eine oder mehrere der Komponenten 1064, 1066, 1068 oder 1070 beinhalten oder durch diese verkörpert sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (zum Beispiel Empfangen, Übertragen, usw.) durch solche Kommunikationsschaltungen verkörpert sein.
  • Der Edge-Computing-Knoten 1050 kann Beschleunigungsschaltung 1064 beinhalten oder mit dieser gekoppelt sein, die durch einen oder mehrere AI-Beschleuniger, einen neuronalen Rechenstab, neuromorphe Hardware, ein FPGA, eine Anordnung von GPU, ein oder mehrere SoC, eine oder mehrere CPU, einen oder mehrere digitale Signalprozessoren, fest zugeordnete ASIC oder andere Formen spezialisierter Prozessoren oder Schaltungen, die zur Erfüllung einer oder mehrerer spezialisierter Aufgaben entworfen sind, verkörpert sein können. Diese Aufgaben können KI-Verarbeitung (einschließlich maschinelles Lernen, Training, Inferenzieren und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterkennung, Regelanalyse oder dergleichen beinhalten. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zur Beschleunigung durch eine solche Beschleunigungsschaltung verkörpert sein.
  • Die Verbindung 1056 kann den Prozessor 1052 mit einem Sensor-Hub oder externer Schnittstelle 1070, die zum Verbinden zusätzlicher Geräte oder Subsysteme verwendet wird, koppeln. Die Geräte können Sensoren 1072, wie zum Beispiel Beschleunigungsmesser, Füllstandssensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Global-Positioning-System (GPS) -Sensoren, Drucksensoren, Luftdrucksensoren und dergleichen, beinhalten. Der Hub oder die Schnittstelle 1070 kann ferner verwendet werden, um den Edge-Computing-Knoten 1050 mit Aktuatoren 1074, wie zum Beispiel Leistungsschaltern, Ventilaktuatoren, einem akustischen Klangerzeuger, einem visuellen Warngerät und dergleichen, zu verbinden.
  • In einigen optionalen Beispielen können verschiedene Eingabe-/Ausgabe- (I/O) -Geräte innerhalb des Edge-Computing-Knotens 1050 vorhanden sein oder mit diesem verbunden sein. Zum Beispiel kann Anzeige oder anderes Ausgabegerät 1084 enthalten sein, um Informationen, wie zum Beispiel Sensormesswerte oder Aktuatorpositionen, anzuzeigen. Eingabegerät 1086, wie zum Beispiel ein Touchscreen oder eine Tastatur, kann enthalten sein, um Eingaben zu akzeptieren. Ein Ausgabegerät 1084 kann jegliche Anzahl von Formen der Audio- oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie zum Beispiel binärer Statusanzeigen (zum Beispiel LED) und visueller Mehrzeichenausgaben oder komplexerer Ausgaben, wie zum Beispiel Anzeigebildschirme (zum Beispiel LCD-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimedia-Objekten und dergleichen von dem Betrieb des Edge-Computing-Knotens 1050 erzeugt oder produziert wird.
  • Batterie 1076 kann den Edge-Computing-Knoten 1050 mit Leistung versorgen, obwohl er in Beispielen, in denen der Edge-Computing-Knoten 1050 an einem festen Standort montiert ist, eine mit einem elektrischen Netz gekoppelte Leistungsversorgung haben kann. Die Batterie 1076 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie sein, wie zum Beispiel eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen.
  • Batterieüberwacher/Ladegerät 1078 kann in dem Edge-Computing-Knoten 1050 enthalten sein, um den Ladezustand (State-of-Charge - SoCh) der Batterie 1076 zu verfolgen. Der Batterieüberwacher/das Ladegerät 1078 kann verwendet werden, um andere Parameter der Batterie 1076 zu überwachen, um Fehlervorhersagen, wie zum Beispiel den Alterungszustand (State-of-Health-SoH) und den Funktionszustand (State-of-Function - SoF) der Batterie 1076, bereitzustellen. Der Batterieüberwacher/das Ladegerät 1078 kann eine integrierte Batterieüberwachungsschaltung, wie zum Beispiel LTC4020 oder LTC2990 von Linear Technologies, ADT7488A von ON Semiconductor aus Phoenix, Arizona, oder einen IC von der UCD90xxx-Familie von Texas Instruments aus Dallas, TX, beinhalten. Der Batterieüberwacher/das Ladegerät 1078 kann die Informationen über die Batterie 1076 über die Verbindung 1056 an den Prozessor 1052 kommunizieren. Der Batterieüberwacher/das Ladegerät 1078 kann auch einen Analog-zu-Digital (ADC) -Wandler beinhalten, der es dem Prozessor 1052 ermöglicht, die Spannung der Batterie 1076 oder den Stromfluss von der Batterie 1076 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Computing-Knoten 1050 ausführen kann, wie zum Beispiel Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Erfassungsfrequenz und dergleichen.
  • Leistungsblock 1080 oder eine andere mit einem Netz gekoppelte Leistungsversorgung kann mit dem Batterieüberwacher/Ladegerät 1078 gekoppelt sein, um die Batterie 1076 aufzuladen. In einigen Beispielen kann der Leistungsblock 1080 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu erhalten, zum Beispiel durch eine Rahmenantenne in dem Edge-Computing-Knoten 1050. Eine drahtlose Batterieladeschaltung, wie zum Beispiel ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in dem Batterieüberwacher/Ladegerät 1078 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1076 und somit auf dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem durch Verwenden des durch die Airfuel-Alliance veröffentlichten Airfuel-Standards, des durch das Wireless-Power-Consortium veröffentlichten Qi-Standards für drahtloses Laden oder des durch die Alliance-for-Wireless-Power veröffentlichten Rezence-Ladestandards ausgeführt werden.
  • Die Speicherung 1058 kann Anweisungen 1082 in der Form von Software-, Firmware- oder Hardware-Befehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl solche Anweisungen 1082 als in dem Speicher 1054 und der Speicherung 1058 enthaltene Codeblöcke gezeigt sind, versteht es sich, dass jeglicher der Codeblöcke durch zum Beispiel in einen Application-Specific-Integrated-Circuit (ASIC) eingebaute festverdrahtete Schaltungen ersetzt werden kann.
  • In einem Beispiel können die Anweisungen 1082, die über den Speicher 1054, die Speicherung 1058 oder den Prozessor 1052 bereitgestellt werden, als nicht flüchtiges maschinenlesbares Medium 1060 verkörpert sein, das Code beinhaltet, um den Prozessor 1052 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten 1050 auszuführen. Der Prozessor 1052 kann über die Verbindung 1056 auf das nicht flüchtige maschinenlesbare Medium 1060 zugreifen. Beispielsweise kann das nicht flüchtige maschinenlesbare Medium 1060 durch Geräte verkörpert sein, die für die Speicherung 1058 beschrieben sind, oder kann spezifische Speicherungseinheiten, wie zum Beispiel optische Platten, Flash-Laufwerke, oder jegliche Anzahl anderer Hardware-Geräte beinhalten. Das nicht flüchtige maschinenlesbare Medium 1060 kann Anweisungen beinhalten, um den Prozessor 1052 anzuweisen, eine spezifische Folge oder einen spezifischen Fluss von Aktionen auszuführen, zum Beispiel, wie in Bezug auf das Flussdiagramm (die Flussdiagramme) und das Blockdiagramm (die Blockdiagramme) oben dargestellter Operationen und Funktionalität beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
  • In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch jegliches materielle Medium, das dazu geeignet ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu codieren oder zu tragen, und das die Maschine dazu veranlasst, jegliche eine oder mehrere der Methoden der vorliegenden Offenbarung auszuführen, oder das dazu geeignet ist, Datenstrukturen, die durch solche Anweisungen verwendet werden oder mit diesen verbunden sind, zu speichern, zu codieren oder zu tragen. Ein „maschinenlesbares Medium“ kann somit Festkörperspeicher und optische und magnetische Medien beinhalten, ist jedoch nicht darauf beschränkt. Spezifische Beispiele von maschinenlesbaren Medien beinhalten nicht flüchtigen Speicher, einschließlich, aber nicht beschränkt auf beispielsweise Halbleiterspeichergeräte (zum Beispiel Electrically-Programmable-Read-Only-Memory (EPROM), Electrically-Erasable-Programmable-Read-Only-Memory (EEPROM)) und Flash-Speichergeräte; Magnetplatten, wie zum Beispiel interne Festplatten und Wechselplatten; magnetooptische Platten; und CD-ROM- und DVD-ROM-Platten. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk durch Verwenden eines Übertragungsmediums über ein Netzwerkschnittstellengerät durch Verwenden eines jeglichen einer Anzahl von Übertragungsprotokollen (zum Beispiel HTTP) gesendet oder empfangen werden.
  • Ein maschinenlesbares Medium kann durch ein Speicherungsgerät oder eine andere Vorrichtung bereitgestellt werden, das/die dazu geeignet ist, Daten in einem nicht flüchtigen Format zu hosten. In einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder andernfalls bereitgestellte Informationen repräsentativ für Anweisungen sein, wie zum Beispiel Anweisungen selbst oder ein Format, von dem die Anweisungen abgeleitet werden können. Dieses Format, von dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (zum Beispiel in komprimierter oder verschlüsselter Form), gepackte Anweisungen (zum Beispiel in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die für die Anweisungen in dem maschinenlesbaren Medium repräsentativen Informationen können durch Verarbeitungsschaltungen in die Anweisungen verarbeitet werden, um jegliche der hierin diskutierten Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen von den Informationen (zum Beispiel Verarbeiten durch die Verarbeitungsschaltung) Folgendes beinhalten: Kompilieren (zum Beispiel von Quellcode, Objektcode, usw.), Interpretieren, Laden, Organisieren (zum Beispiel dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Packen, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
  • In einem Beispiel kann die Ableitung der Anweisungen das Zusammenstellen, Kompilieren oder Interpretieren der Informationen (zum Beispiel durch die Verarbeitungsschaltung) beinhalten, um die Anweisungen von einem durch das maschinenlesbare Medium bereitgestellten Zwischen- oder vorverarbeiteten Format zu erzeugen. Wenn die Informationen in mehreren Teilen bereitgestellt werden, können sie kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Zum Beispiel können sich die Informationen in mehreren komprimierten Quellcode-Paketen (oder Objektcode oder ausführbarem Binärcode, usw.) auf einem oder mehreren entfernt angeordneten Servern befinden. Die Quellcode-Pakete können während des Übergangs über ein Netzwerk verschlüsselt werden, und entschlüsselt, dekomprimiert, bei Bedarf zusammengestellt (zum Beispiel verknüpft) werden, und an einer lokalen Maschine kompiliert oder interpretiert werden (zum Beispiel in eine Bibliothek, eine eigenständige ausführbare Datei, usw.), und durch die lokale Maschine ausgeführt werden.
  • Jedes der Blockdiagramme der 9 und 10 ist dazu beabsichtigt, eine Ansicht von Komponenten eines Geräte, Subsystems oder einer Anordnung eines Edge-Computing-Knotens auf hoher Ebene darzustellen. Es versteht sich jedoch, dass einige der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können, und dass eine unterschiedliche Anordnung der gezeigten Komponenten in anderen Implementierungen auftreten kann.
  • Es sollte klargestellt werden, dass die in dieser Spezifikation beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um insbesondere ihre Implementierungsunabhängigkeit zu betonen. Solche Komponenten können durch jegliche Anzahl von Software- oder Hardware-Formen verkörpert sein. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardware-Schaltung implementiert sein, die kundenspezifische Very-Large-Scale-Integration (VLSI) -Schaltungen oder Gate-Arrays, serienmäßige Halbleiter, wie zum Beispiel Logikchips, Transistoren, oder andere spezielle Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardware-Geräten, wie zum Beispiel Field-Programmable-Gate-Arrays, programmierbarer Array-Logik, programmierbaren Logikgeräten, oder dergleichen implementiert sein. Komponenten oder Module können auch in Software implementiert werden, um durch verschiedene Prozessortypen ausgeführt zu werden. Eine identifizierte Komponente oder ein Modul von ausführbarem Code kann beispielsweise einen oder mehrere physikalische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Dateien einer identifizierten Komponente oder eines Moduls nicht physikalisch zusammen platziert sein, sondern können verschiedenartige an unterschiedlichen Standorten gespeicherte Anweisungen umfassen, die, wenn logisch miteinander verbunden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.
  • In der Tat kann eine Komponente oder ein Modul von ausführbarem Code eine einzelne Anweisung oder viele Anweisungen sein, und kann sogar über mehrere unterschiedliche Codesegmente, zwischen unterschiedlichen Programmen und über mehrere Speichergeräte oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie zum Beispiel Neuschreiben von Code und Codeanalyse) auf einem unterschiedlichen Verarbeitungssystem (zum Beispiel in einem Computer in einem Datenzentrum) stattfinden, als auf dem, in dem der Code eingesetzt wird (zum Beispiel in einem Computer, der in einen Sensor oder Roboter eingebettet ist). In ähnlicher Weise können Betriebsdaten innerhalb von Komponenten oder Modulen hierin identifiziert und veranschaulicht werden, und können in jeglicher geeigneten Form verkörpert und innerhalb jeglichen geeigneten Typs von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einzelner Datensatz gesammelt oder über unterschiedliche Standorte, einschließlich über unterschiedliche Speicherungsgeräte, 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 zur Ausführung gewünschter Funktionen betrieben werden können.
  • In einigen Aspekten hängt die Einführung von 5G von der Fähigkeit ab, an Communication-Service-Provider (CoSP) die Fähigkeit bereitzustellen, mehrere virtuelle Netzwerke über einen gemeinsamen Satz physikalischer (drahtloser und drahtgebundener) Netzwerkinfrastruktur bereitzustellen, zu verwalten, anzupassen und zu betreiben, einschließlich des effizienten Managements von Prozessorkernressourcen bei gleichzeitiger Minimierung des Leistungsverbrauchs (zum Beispiel durch Verwenden einer oder mehrerer der in Verbindung mit 11-20 diskutierten Techniken).
  • 11 veranschaulicht 3GPP-basierte 5G-Systemarchitektur 1100 durch Verwenden einer Edge-Server-CPU mit dynamischer deterministischer Skalierung und Beispiele für die Abbildung von MEC-Entitäten zu einigen Komponenten des 5G-Systems (nämlich AF und UPF), gemäß einem Beispiel. Die-Architektur 1100 kann dazu ausgelegt sein, Funktionalitäten gemäß der ETSI GS MEC-003-Spezifikation und/oder der ETSI GR MEC-017-Spezifikation bereitzustellen.
  • Das betrachtete Kommunikationssystem enthält ein MEC-System, dessen Architektur in ETSI GS MEC-003 spezifiziert ist, das in einem 5G-Netzwerk eingesetzt wird, dessen Systemarchitektur in 3GPP TS 23.501 spezifiziert ist. Die Annahme ist, alle logischen Funktionen (das heißt Netzwerkfunktionen (NF) und auch Anwendungsfunktionen (AF)) als virtualisierte Funktionen zu betrachten. Die Abbildung von MEC-Entitäten in ein 5G-System ist in 11 dargestellt. Insbesondere: Eine MEC-Plattform ist als eine bestimmte Anwendungsfunktion (AF) in 3GPP implementiert; die Datenebene in der MEC-Architektur entspricht einer User-Plane-Function (UPF) in 3GPP, und die MEC-Apps werden zu dem lokalen DN (Datennetzwerk) in 3GPP abgebildet.
  • In einigen Aspekten ist es ein Ausgangspunkt, zu berücksichtigen, dass die Leistung des End-to-End (E2E) 5G-Systems nicht nur von der Leistung der Systemkomponenten des Radio-Access-Network (RAN) und des Core-Network (CN) allein abhängt, sondern auch von der Leistung der MEC-Funktionsentitäten.
  • Beispiel: Die E2E-Latenz (das heißt zwischen der UE und der MEC-Anwendung) besteht aus dem Packet-Delay-Budget (PDB) (definiert in 5G als die E2E-Verzögerung zwischen UE und UPF, mit einer Sicherheit von 98%) und der zusätzlichen Verzögerung zwischen UPF und dem lokalen DN (wo die MEC-Apps platziert sind). Diese zweite Latenzkomponente wird durch die 5G QoS Class-Identifier (5QI) -Eigenschaften in 3GPP nicht berücksichtigt, obwohl sie für die Leistungsoptimierung wichtig ist, da sie eng mit der Instanziierung der MEC-Anwendungen zusammenhängt. Infolgedessen reichen Netzwerk-Slice-relevante Leistungsmetriken (wie zum Beispiel PDB) nicht aus, um die E2E-Gesamtleistung zu beschreiben, da sich der Endpunkt für den Benutzerverkehr in der MEC-App befindet (platziert in dem DN). Stattdessen sollten die Instanziierung von MEC-Anwendungen und die zugehörige Zuweisung von virtuellen Maschinen (VM) sorgfältig betrachtet werden, um die gesamte E2E-Latenz gemäß den Slice-Anforderungen zu optimieren.
  • In einigen Aspekten können einer oder mehrere der Netzwerkknoten innerhalb der 5G-Systemarchitektur 1100 (zum Beispiel Netzwerkknoten 1102, der zum Ausführen der Mobile-Edge-Plattform oder VNF verwendet wird) Edge-Server-CPU 1104 und Edge-Server-Telemetriemodul 1106 implementieren. Die Edge-Server-CPU 1104 und das Telemetriemodul 1106 können Funktionalitäten ausführen, die ähnlich der Edge-Server-CPU 434 oder dem Telemetriemodul 441 sind, die in Verbindung mit 4A oder mit jeglicher der 11-20 diskutiert werden.
  • 12 veranschaulicht die Nutzung von Prozessorkernen mit derselben Basisfrequenz (auch bezeichnet als Mittenbasisfrequenz), gemäß einem Beispiel.
    Insbesondere veranschaulicht Diagramm 1200 mehrere Prozessorkerne, die mit derselben Basisfrequenz (zum Beispiel 2,1 GHz) konfiguriert sind. Eine CPU mit Prozessorkernen, die eine einzelne Basisfrequenz verwenden, kann als eine Legacy-CPU bezeichnet werden.
  • 13 veranschaulicht die Nutzung von zwei unterschiedlichen Sätzen von Prozessorkernen, wobei die zwei Sätze unterschiedliche Basisfrequenzen haben, gemäß einem Beispiel. Insbesondere veranschaulicht Diagramm 1300 mehrere Prozessorkerne, die mit unterschiedlichen Basisfrequenzen konfiguriert sind. Wie in 13 veranschaulicht, sind Prozessorkerne 2-4 mit einer höheren Basisfrequenz (zum Beispiel 2,6 GHz) konfiguriert, und Prozessorkerne 4-26 sind mit einer niedrigeren Basisfrequenz (zum Beispiel 1,9 GHz) konfiguriert. Die mit der niedrigeren Basisfrequenz konfigurierten Prozessorkerne können als Kerne mit niedriger Priorität oder als ein Prozessorkernsatz mit niedriger Priorität bezeichnet werden. Die mit der höheren Basisfrequenz konfigurierten Prozessorkerne können als Kerne mit hoher Priorität oder als ein Prozessorkernsatz mit hoher Priorität bezeichnet werden. Eine CPU mit Prozessorkernen, die unterschiedliche Prioritäten und unterschiedliche Basisfrequenzen verwenden, kann in Verbindung mit einer Edge-Server-CPU verwendet werden, die für die dynamische deterministische Skalierung von Verarbeitungsressourcen wie hierin diskutiert konfiguriert ist.
  • Obwohl 13 (und die Offenbarung hierin) die Verwendung von nur zwei unterschiedlichen Basisfrequenzen diskutiert, ist die Offenbarung in dieser Hinsicht nicht beschränkt, und stattdessen können mehrere deterministische Basisfrequenzen (zum Beispiel mehr als zwei Basisfrequenzen) verwendet werden. In dieser Hinsicht kann derselbe Prozessorkern dazu ausgelegt sein, mit minimaler Leistungsbelastung zwischen den mehreren Basisfrequenzen umzuschalten, wobei es den CPU ermöglicht wird, auf eine deterministische Leistung zu skalieren.
  • 14 veranschaulicht Host-Gerät 1400, das Edge-Server-CPU 1402 mit dynamischer Basisfrequenz und Kernnutzung verwendet, gemäß einem Beispiel. Bezugnehmend auf 14, kann das Host-Gerät 1400 als randnahes Multi-Access-Edge-Computing-Gerät 1410 oder als kernnahes (zum Beispiel 5G-Kern) Host-Gerät 1412 verwendet werden. In einigen Aspekten kann das Host-Gerät 1400 eine Edge-Server-CPU 1402 beinhalten, die für die dynamische Basisfrequenz- und Prozessorkernnutzung in Verbindung mit hierin offenbarten Techniken konfiguriert sein kann. Solche Techniken werden hierin auch als Prioritized-Base-Frequency (PBF) bezeichnet. Insbesondere kann die CPU 1402 mehrere Kerne 1404 beinhalten, die in zwei Prozessorkernsätze getrennt sein können (zum Beispiel einen Kernsatz mit niedriger Priorität, der als „L“ angezeigte Kerne beinhaltet, und einen Kernsatz mit hoher Priorität, der als „H“ angezeigte Kerne beinhaltet), Die mehreren Kerne 1404 können auf einem oder mehreren CPU-Sockets, wie zum Beispiel Sockets 1414 und 1416, platziert sein.
  • In einigen Aspekten ist die Edge-Server-CPU 1402 dazu ausgelegt, die Verarbeitung von Netzwerkverkehr, VNF (zum Beispiel NFV-Instanzen), MEC-Apps, Services oder anderer virtualisierter Funktionen (zum Beispiel eines virtualisierten Routers oder einer vRT-Funktion, einer virtualisierten Firewall oder vFW-Funktion, usw.) von dem Prozessorkernsatz mit niedriger Priorität zu dem Prozessorkernsatz mit hoher Priorität basierend auf einem oder mehreren Schwellenwerten in Verbindung mit Netzwerktelemetrieparametern (zum Beispiel wie durch ein Telemetriemodul wie oben diskutiert bereitgestellt) zu bewegen.
  • In einigen Aspekten können die Schwellenwerte durch Communication-Service-Provider (CoSP) basierend auf der Anzahl der zu berücksichtigenden UE-Teilnehmer (Latenz, Dichte, Datenmenge, Arbeitslast-CDN, Priorität des Verkehrs auf einer Aufwärtsverbindung von einer UE zu dem Netzwerk und umgekehrt, usw.) eingestellt werden. Orchestratoren (zum Beispiel Ericsson SDI-Controller, proprietäres oder Open Source-SDI, einfacher Linux-Befehl „top“, wobei ein Systemadministrator oder eine Person, die das Netzwerk überwacht, Entscheidungen bezüglich der Schwellenwerte basierend auf der Beobachtung der Last über den top-Befehl treffen kann) können dazu ausgelegt sein, die Virtual-Network-Function (VNF) basierend darauf, ob der vorgegebene Schwellenwert erreicht ist (zum Beispiel wie in Grafik 1406 zu sehen) zu bewegen.
  • In einigen Aspekten kann die Edge-Server-Telemetrie, einschließlich des Gesamtdurchsatzes, in Echtzeit verwendet werden, um Burst-Ereignisse zu erfassen, die einen vorgegebenen Schwellenwert weiter auslösen (zum Beispiel über eine Hardware- oder eine Software-Steuerung). In einigen Aspekten kann der Schwellenwert auf die relative Rechenkapazität des Servers für eine bestimmte Anzahl von Teilnehmern eingestellt werden, um einen Überlauf zu verhindern (das heißt UE-Teilnehmer fallen zu lassen). In einigen Aspekten können CoSP deterministische Service-Level-Agreements (SLA) anbieten, um Teilnehmer (UE) -Verkehrs-/Service-Bursts (zum Beispiel Messaging, CDN, usw.) zu handhaben. Die mobile Kern-/Edge-Virtual-Network-Function (Handhaben der Teilnehmerkapazität) kann dazu ausgelegt sein, in den Kernen mit hoher Priorität ausgeführt zu werden (wie in Grafik 1406 zu sehen).
  • In Aspekten, in denen der Teilnehmerverkehr niedrig ist, kann sich die VNF zu den Kernen mit niedriger Priorität bewegen, und dann, falls erforderlich, zurück zu den Kernen mit hoher Priorität, basierend auf einem vorgegebenen Schwellenwert. Die CPU kann die Entscheidung treffen, wie dieser Übergang auftritt. Zum Beispiel kann die CPU die Schwellenwertänderungen erkennen und das Kernprofil ändern, um auf die Schwellenwertänderungen zu reagieren, wodurch die VNF auf unterschiedliche Typen von Kernen „bewegt“ wird. In einigen Aspekten kann ein CoSP eine deterministische Spitzenanzahl der Teilnehmerkapazität spezifizieren, kann jedoch von einer geringeren Nutzung (Leistung) profitieren, wenn die Teilnehmernachfrage nach Mobilfunk-Services niedriger ist. Der Graph 1406 veranschaulicht die Bewegung der Teilnehmer-VNF zwischen Kernen mit unterschiedlicher Priorität basierend auf einem vorgegebenen Schwellenwert (zum Beispiel einer Schwellenwertanzahl von Teilnehmern, einem Schwellen-Durchsatzwert, einer Schwellen-Service-Auslastung für einen Netzwerk-Service, den die VNF bereitstellt, usw.).
  • Graph 1408 veranschaulicht das gleiche Konzept der Verwendung von Kernen mit unterschiedlicher Priorität, jedoch in Verbindung mit einer virtuellen Router (vRT) -App, einer virtuellen Firewall (vFW) -App und einer offenen virtuellen Switch (OVS) -App-Bewegung basierend auf einem vorgegebenen Schwellenwert. In einigen Aspekten kann ein solcher vorgegebener Schwellenwert einer Anzahl von aktuell mit dem Host-Gerät 1400 in Kommunikation stehenden Benutzern/UE, dem Netzwerkdurchsatz an dem Host-Gerät 1400, der Erkennung von Burst-Ereignissen, der Nutzung von Netzwerkressourcen durch VNF oder anderer virtueller Anwendungen, usw., zugeordnet sein. Wie durch den Graph 1408 veranschaulicht, können mehrere VNF auf dem Host-Gerät 1400 (zum Beispiel einem Edge-Server) eine Gruppe von Kernen mit hoher Priorität oder mit niedriger Priorität überspannen. Solche VNF können sich auch zwischen der Verwendung von Kernen mit niedriger Priorität und Kernen mit hoher Priorität „bewegen“, basierend auf einem vorgegebenen Schwellenwert, wie zum Beispiel dem Service-Nutzungsgrad (zum Beispiel basierend auf einer Anzahl von Teilnehmern an dem Service, einer Anzahl von durch den Service verwendeten aktiven Verbindungen, der Bandbreitennutzung, dem Durchsatz oder anderen Telemetrieparametern oder Konfigurationen, die von einem Telemetriemodul (zum Beispiel 406B) wieder abgerufen werden können).
  • Ein Beispiel für die CPU-Leistung von Effizienzeinsparungen ist in Tabelle 1 unten durch Verwenden einer Firewall-Anwendung veranschaulicht: TABELLE 1:
    CPU Frequenz (GHz) Kerne VM-Kerne Verschlüsselung Durchsatz CPU-Nutzung
    6130 2,1 16 2
    6230 2,1 20 2
    6230N 2,3 20 2 Sw 0,7 91%
    6230N 2,3 20 2 Qat 2 71%
    6230N-PBF 2,7 20 2 Sw 0,81 85%
    6230N-PBF 2,7 20 2 qat 2,3 64%
  • Wie in der obigen Tabelle 1 zu sehen, bringt die Verwendung einer Edge-Server-CPU mit dynamischer deterministischer Skalierung von Prozessorkernen (auch bezeichnet als Prioritized-Base-Frequency oder PBF) die Fähigkeit ein, differenzierte Basisfrequenzniveaus innerhalb des System-on-a-Chip (SoC) bereitzustellen, was in einer effizienteren Verwendung der Prozessorressourcen und einer Erhöhung des Durchsatzes resultiert. Bei Server-Einsätzen mit einer großen Anzahl von Kernen gibt es häufig eine Arbeitslast-Diversität, die unterschiedliche Leistungsniveaus für Kerne erfordert. Dies gilt insbesondere für Infrastructure-as-a-Service (IaaS)-Server-Einsätze, bei denen Mandanten eine Vielzahl von Arbeitslasten auf derselben CPU ausführen. Im Legacy-Verhalten, wenn der Prozessor leistungsbegrenzt wird, senkt Running-Average-Power-Limited (RAPL) die Prozessorfrequenz gleichmäßig über Kerne hinweg ab. Diese Technik kann zwar einfach sein, erlaubt dem Benutzer jedoch nicht die Flexibilität, einen Untersatz von Kernen auf einer höheren Frequenz als andere zu behalten.
  • In einigen Aspekten können hierin offenbarte PBF-Techniken durch die folgenden technischen Verbesserungen charakterisiert werden: im Wesentlichen der gleiche Leistungsverbrauch im Vergleich zu nicht PBF-fähigen CPU; verbesserte Systemleistung für asymmetrische Arbeitslasten; reduzierte Leistungsvariabilität für Kerne mit hoher Priorität; Flexibilität bei der Erzeugung von VM-Angeboten mit hoher Priorität; und insgesamt TCO- und Umsatzvorteil.
  • Mit PBF kann eine CPU (zum Beispiel 1402 in 14) -Stock-Keeping-Unit (SKU) mit spezifischen Kernen hergestellt werden, die als Kerne mit hoher Priorität (oder „H-Kerne“) bezeichnet werden, während andere Kerne als Kerne mit einer niedrigeren Priorität (oder „L-Kerne“) bezeichnet werden. In dieser Hinsicht kann PBF die Basisfrequenz auf Kernen mit niedriger Priorität gegen die Basisfrequenz auf den Kernen mit hoher Priorität austauschen. Die Basisfrequenz für die Kerne mit hoher/niedriger Priorität kann als P1Hi/Lo bezeichnet werden. Architektonisch ist der höchste Wert für P1Hi der Wert von P0n in der SKU, ohne TDP-Erhöhung oder Änderung der thermischen Plattformlösung für PBF. In einigen Aspekten kann PBF mit den folgenden Merkmalen implementiert werden, die über BIOS und Software aktiviert werden können.
  • In einigen Aspekten gibt es einen beschränkten Satz von Kernen, die H für eine bestimmte SKU sein können (zum Beispiel H-Bereich 6-12 H-Kerne). Die CPU-Konfiguration kann vom Start an entweder H oder L sein (obwohl einige Implementierungen eine ursprüngliche H-Kern-Einstellung erzwingen können). Die VNF (Virtual-Network-Function = Virtual-Application) kann abhängig von dem vorgegebenen Anzeiger (kann auch bezeichnet werden als „Beschäftigt-Anzeiger“) von H-auf L-Kerne bewegt werden. Der 2. Satz von Kernen kann mit niedriger Frequenz arbeiten. Die CPU-Konfiguration kann vom Start an entweder H oder L sein (obwohl einige Implementierungen eine ursprüngliche H-Kern-Einstellung erzwingen können).
  • 15 veranschaulicht Diagramm 1500 des Bewegens von Teilnehmeranwendungen zwischen Kernen mit niedrigerer Frequenz und Kernen mit höherer Frequenz, basierend auf einem vorgegebenen Schwellenwert, gemäß einem Beispiel. Eine hierin offenbarte Edge-Server-CPU kann mit einem CPU-Nutzungsschwellenwert, einschließlich Prioritäten von UE oder Netzwerkverkehr, konfiguriert sein. Insbesondere kann eine Überwachungsschaltung, wie zum Beispiel ein Server-Telemetriemodul oder ein anderer Typ von Überwachungsschaltung innerhalb der CPU oder außerhalb der CPU und innerhalb des Netzwerk-Hosts, die CPU-Nutzung überwachen und erkennen, wenn CPU-Ressourcen über dem Nutzungsschwellenwert verwendet werden. Ein solcher Nutzungsschwellenwert kann zum Beispiel bei einer durch die CPU in Verbindung mit der Handhabung des Kommunikationsverkehrs oder der Anwendungsverarbeitung ausgeführten Burst-Modusbezogenen Verarbeitung überschritten werden, wodurch es Server-Anwendungen ermöglicht wird, eine höhere Leistung, wie zum Beispiel eine Erhöhung der Verarbeitungsanzahl von UE, zu erreichen.
  • In einigen Aspekten kann eine CPU-Burst-Modus-bezogene Verarbeitung mit Erhöhung der Teilnehmerlast stattfinden, wie zum Beispiel erhöhte Verarbeitungsanforderungen, die mit einer gegebenen Anwendung verbunden sind, erhöhte Anzahl von UE-Teilnehmern, die die Anwendung verwenden, erhöhte Anzahl von UE-Teilnehmern, die unterschiedliche Anwendungen verwenden, die durch dieselbe CPU verarbeitet werden, usw. Wie in 15 veranschaulicht, sind Firewall- und Router-Anwendungen 1502 so veranschaulicht, dass sie die Kerne mit niedriger Frequenz verwenden, während unterschiedliche Anwendung 1504 von der Verwendung der Kerne mit niedriger Frequenz zu der Verwendung der Kerne mit hoher Frequenz basierend auf einer höheren Teilnehmerlast und/oder Erkennung der Burst-Modus-Verarbeitung bewegt wird. In dieser Hinsicht kann die Verwendung der Kerne mit niedriger Priorität und der Kerne mit hoher Priorität dynamisch angepasst werden (zum Beispiel kann die Ausführung der instanziierten NFV-Instanz für die App von hoch nach niedrig oder umgekehrt bewegt werden), zum Beispiel basierend auf der Nutzung eines der NFV zugeordneten Netzwerk-Services, wie durch Telemetrieparameter, wie zum Beispiel den der NFV zugeordneten Netzwerkverkehr, die Anzahl der Teilnehmer, die dem durch die NFV bereitgestellten Netzwerk-Service zugeordnet sind, eine Anzahl von Prozessorkernen, die zum Ausführen der NFV verwendet werden, Prozessorkernanforderungen für die NFV, und so weiter, angezeigt.
  • 16 veranschaulicht die Cloudifizierung eines Netzwerks durch Verwenden eines Edge-Servers mit einer Edge-Server-CPU mit dynamischer deterministischer Skalierung, gemäß einem Beispiel. Bezugnehmend auf 16, zeigt Diagramm 1600 Physical-Network-Functions (PNF) 1602, die auf fest zugeordneten Hilfsmitteln 1604 ausgeführt werden. In dieser Hinsicht werden Netzwerk-Services (die durch virtuelle Maschinen 1606 verwendet werden können) durch fest zugeordnete physikalische Systeme, wie zum Beispiel die fest zugeordneten Hilfsmittel 1604, einschließlich eines Load-Balancers, einer Firewall und eines VPN-Server-Rack, um einige zu nennen, bereitgestellt.
  • In einem Beispiel kann das veranschaulichte Kommunikationsnetzwerk durch Verwenden der PBF-Technologie, einschließlich einer Edge-Server-CPU mit dynamischer deterministischer Skalierung wie hierin beschrieben, cloudifiziert werden. Insbesondere können VNF 1608 verwendet werden, um die Netzwerk-Services (zum Beispiel über NVF-Instanzen, die auf virtuellen Maschinen ausgeführt werden) durch Verwenden von Standard-Servern zu liefern. In dieser Hinsicht findet die Cloudifizierung des Netzwerks statt, wenn physikalische Netzwerkfunktionen Übergänge zu virtuellen Netzwerkfunktionen sind. Die Prozessorkernnutzung des Standard-Servers (oder der Standard-Server), die die VNF ausführen, kann durch Verwenden der hierin diskutierten Techniken konfiguriert und verwaltet werden.
  • 17 veranschaulicht Vergleichsdiagramm 1700 zwischen einer Legacy-CPU mit fester Kernnutzung und einer Edge-Server-CPU mit dynamischer deterministischer Skalierung durch Verwenden mehrerer Sätze von Kernen, wobei jeder Satz eine unterschiedliche Basisfrequenz verwendet, gemäß einem Beispiel. Bezugnehmend auf 17, zeigt das Diagramm 1700 Legacy-CPU 1702, die mit einer festen Kernnutzung verbunden ist (alle Kerne arbeiten mit einer festen Basisfrequenz), ohne die Fähigkeit, die CPU-Verarbeitung für eine geringere Teilnehmeranforderung zu optimieren. In dieser Hinsicht kann die Legacy-CPU 1702 als eine einzelne CPU mit einer einzelnen garantierten Frequenz (F) für ihre Kerne charakterisiert werden.
  • Das Diagramm 1700 veranschaulicht ferner Edge-Server-CPU 1704 mit dynamischer deterministischer Skalierung, die durch eine flexible Kernnutzung und die Fähigkeit charakterisiert werden kann, die Basisfrequenz nach oben oder unten anzupassen, um Teilnehmer-Bursts (zum Beispiel wie sie basierend auf einem Service-Level-Agreement konfiguriert werden können) zu handhaben. In dieser Hinsicht beinhaltet die Edge-Server-CPU 1704 mindestens zwei Sätze von Prozessorkernen - einen ersten Satz, der mit einer garantierten höheren Frequenz (H), und einen zweiten Satz, der mit einer garantierten niedrigeren Frequenz (L) als ihre entsprechenden Basisfrequenzen konfiguriert ist. In einigen Aspekten können die H-Ebenen-Prozessorkerne verwendet werden, um Teilnehmerdaten-Bursts an dem Rand anzusprechen. In einigen Aspekten kann ein MEC-Orchestrator oder ein anderer Typ von MEC- oder 5G-Netzwerk-Entität Teilnehmer-VNF von der L-Ebene in die H-Ebene von Prozessorkernen bewegen, basierend auf einer oder mehreren Netzwerktelemetrieeigenschaften, die einen vorgegebene Schwellenwert überschreiten, und dann die VNF zurück nach unten auf die L-Schicht bewegen, wenn die eine oder die mehreren Netzwerktelemetrieeigenschaften unter den vorgegebenen Schwellenwert fallen. In dieser Hinsicht können die H-Kerne verwendet werden, um Teilnehmerdaten-Bursts an dem Rand anzusprechen.
  • 18 veranschaulicht einen 5G-Edge-Server und einen 5G-Core-Server, die mehrere Virtualized-Network-Functions (VNF) auf Kernen mit niedrigerer Frequenz (L) oder Kernen mit höherer Frequenz (H) ausführen, gemäß einem Beispiel. Bezugnehmend auf 18, sind 5G-Edge-Server 1802 und 5G-Core-Server 1810 veranschaulicht. In einigen Aspekten kann der 5G-Edge-Server 1802 ein MEC-Host zum Implementieren einer oder mehrerer MEC-Plattform-VNF oder anderer MEC-bezogener Funktionalitäten (zum Beispiel MEC-Plattformmanager, Orchestrator, usw.) innerhalb einer 5G-Kommunikationsarchitektur (zum Beispiel einer oder mehrerer der in Verbindung mit den 1A-11 veranschaulichten Architekturen) sein. Der 5G-Edge-Server 1802 kann physikalisch näher an Endbenutzern sein, und kann drahtlosen Verkehr beenden. Der 5G-Core-Server 1810 kann ein Host-Server sein, der eine oder mehrere dem 5G-Kern zugeordnete netzwerkbezogene Kernfunktionalitäten ausführt (zum Beispiel 5G-PCF, 5G-SMF, 5G-UPF, 5G-AF, usw.). Der 5G-Core-Server 1810 kann in einem Datenzentrum eines Telekommunikationsunternehmens oder eines Cloud-Service-Anbieters sein.
  • Der 5G-Edge-Server 1802 kann mehrere Prozessorkerne 1804 beinhalten, die L-Kerne und H-Kerne beinhalten können. In einigen Aspekten kann der 5G-Edge-Server 1802 eine oder mehrere VNF durch Verwenden der mehreren Prozessorkerne 1804 Instanziieren und ausführen. Zum Beispiel, und wie in 18 veranschaulicht, können VNF1, VNF2 und VNF4 durch Verwenden von L-Kernen 1806 instanziiert werden, und VNF3 kann durch Verwenden von H-Kernen 1808 instanziiert werden. In einigen Aspekten kann eine VNF durch Verwenden eines Kerntyps instanziiert werden, kann jedoch basierend auf der Netzwerkanforderung, der VNF-Ressourcennutzung, usw. auf einen unterschiedlichen Kerntyp bewegt werden (zum Beispiel durch Verwenden der hierin offenbarten Kern-Orchestrierungstechniken). Zum Beispiel wird VNF2 ursprünglich durch Verwenden der L-Kerne 1806 instanziiert, kann aber anschließend so verlagert werden, dass sie die H-Kerne 1808 verwendet.
  • Der 5G-Core-Server 1810 kann mehrere Prozessorkerne 1812 beinhalten, die L-Kerne und H-Kerne beinhalten können. In einigen Aspekten kann der 5G-Core-Server 1810 eine oder mehrere VNF durch Verwenden der mehreren Prozessorkerne 1812 instanziieren und ausführen. Zum Beispiel, und wie in 18 veranschaulicht, können VNF7 und VNF8 durch Verwenden von L-Kernen 1814 instanziiert werden, während VNF6 durch Verwenden von H-Kernen 1816 instanziiert werden kann. In einigen Aspekten kann eine VNF durch den 5G-Core-Server durch Verwenden eines Kerntyps instanziiert werden, kann jedoch basierend auf der Netzwerkanforderung, der VNF-Ressourcennutzung oder anderen Telemetrieparametern, die durch ein Telemetriemodul gesammelt und bereitgestellt werden können, auf einen unterschiedlichen Kerntyp bewegt werden. Zum Beispiel wird VNF9 ursprünglich durch den 5G-Core-Server 1810 durch Verwenden der L-Kerne 1814 instanziiert, kann aber anschließend so verlagert werden, dass sie die H-Kerne 1816 basierend auf der Nutzung oder anderen Faktoren verwendet. VNF9 kann sich anschließend zurück bewegen, wenn zum Beispiel die Nutzung (zum Beispiel Anzahl der durch die VNF verwendeten Kerne, Anzahl der Teilnehmer an dem durch die VNF bereitgestellten Service, durch die VNF verwendete Bandbreite, Anzahl der durch die VNF aufrechterhaltenen offenen Verbindungen, usw.) unter einen Schwellenwert fällt.
  • In einigen Aspekten können einer oder mehrere der Kerne 1804 (innerhalb des 5G-Edge-Servers 1802) und 1812 (innerhalb des 5G-Core-Servers 1810) durch Verwenden von Hardware-Beschleunigungs (oder HW-Beschleunigungs) -Techniken, die durch Beschleuniger 1805 bzw. 1813 bereitgestellt werden, beschleunigt werden. Eine VNF (zum Beispiel Fortinet FortiGate-VM-Anwendung) kann die HW-Beschleunigung durch Verwenden einer Gruppe von entweder H- oder L-Kernen verwenden. Eine Sicherheits-VNF kann die in Intel® QuickAssist-Technology (oder QAT) enthaltene Hardware-Sicherheitsbeschleunigung (das heißt https://www.intel.com/content/www/us/en/architectureand-technology/intel-quick- assist-technology-overview.html) verwenden. In einigen Aspekten werden VNF-Anwendungen beschleunigt, indem Intel® QAT zu einer softwaredefinierten Infrastruktur (SDI) -Umgebung hinzugefügt wird, die eine softwarefähige Grundlage für Sicherheit, Authentifizierung und Komprimierung bereitstellt und die Leistung und Effizienz von Standardplattformlösungen erheblich erhöht. In dieser Hinsicht verbessert die Verwendung von Hardware-Beschleunigung (wie zum Beispiel Intel® QAT) die Leistung über Anwendungen und Plattformen hinweg, einschließlich symmetrischer Verschlüsselung und Authentifizierung, asymmetrischer Verschlüsselung, digitaler Signaturen, Rivest-Shamir-Adleman (RSA)-Kryptografie und Diffie-Hellman-Schlüsselaustausch (DH), Elliptic-Curve-Cryptography (ECC) und verlustfreie Datenkomprimierung. Wie in 18 veranschaulicht, können L-Kerne 1806, die für VNF1 verwendet werden, und H-Kerne 1808, die für VNF2 verwendet werden, hardwarebeschleunigt werden, und andere Kerne können ebenfalls beschleunigt werden. In einigen Aspekten kann die Hardwarebeschleunigung durch Verwenden von Telemetrie- und Kernnutzungsinformationen sowie eines vorbestimmten Schwellenwerts wie hierin diskutiert aktiviert werden.
  • In einigen Aspekten kann eine ursprünglich auf dem 5G-Edge-Server 1802 instanziierte VNF auf den 5G-Core-Server 1810 verlagert werden und umgekehrt. Während der VNF-Bewegung zwischen dem 5G-Edge-Server und dem 5G-Core-Server kann sich auch die Nutzung des Kerntyps durch die VNF ändern. Zum Beispiel kann eine VNF, die auf dem 5G-Edge-Server 1802 durch Verwenden von L-Kernen instanziiert wurde, nach der Bewegung L-Kerne oder H-Kerne verwenden. In einigen Aspekten kann die VNF-Bewegung zwischen dem 5G-Edge-Server und dem 5G-Core-Server durch einen 5G-Core-Orchestrator oder einen 5G-Edge-/MEC-Orchestrator initiiert und verwaltet werden.
  • 19 veranschaulicht 5G-Edge-Server 1902 und 5G-Core-Server 1910, die VNF ausführen, die L-Kerne und H-Kerne umspannen können, gemäß einem Beispiel. Der 5G-Edge-Server 1902 kann ein MEC-Host zum Implementieren einer oder mehrerer MEC-Plattform-VNF oder anderer MEC-bezogener Funktionalitäten (zum Beispiel MEC-Plattformmanager, Orchestrator, usw.) innerhalb einer 5G-Kommunikationsarchitektur (zum Beispiel einer oder mehrerer der in Verbindung mit den 1A-11 veranschaulichten Architekturen) sein. Der 5G-Edge-Server 1902 kann physikalisch näher an Endbenutzern sein, und kann drahtlosen Verkehr beenden. Der 5G-Core-Server 1910 kann ein Host-Server sein, der eine oder mehrere dem 5G-Kern zugeordnete netzwerkbezogene Kernfunktionalitäten ausführt (zum Beispiel 5G-PCF, 5G-SMF, 5G-UPF, 5G-AF, usw.). Der 5G-Core-Server 1910 kann in einem Datenzentrum eines Telekommunikationsunternehmens oder eines Cloud-Service-Anbieters sein.
  • Der 5G-Edge-Server 1902 kann mehrere Prozessorkerne 1904 beinhalten, die L-Kerne 1906 und H-Kerne 1908 beinhalten können. In einigen Aspekten kann der 5G-Edge-Server 1902 eine oder mehrere VNF durch Verwenden der mehreren Prozessorkerne 1904 instanziieren und ausführen, wobei die VNF sowohl L-als auch H-Kerne verwendet. Zum Beispiel, und wie in 19 veranschaulicht, wird, während VNF2 ursprünglich die L-Kerne 1906 verwendet hat, VNF2 an einem späteren Zeitpunkt bewegt, um eine Kombination sowohl der L-Kerne 1906 als auch der H-Kerne 1908 zu verwenden. Zusätzlich kann in Aspekten, in denen eine VNF sowohl L- als auch H-Kerne innerhalb des 5G-Edge-Servers 1902 verwendet, einer oder mehrere der durch die VNF verwendeten L- und H-Kerne hardwarebeschleunigt sein.
  • Der 5G-Core-Server 1910 kann mehrere Prozessorkerne 1912 beinhalten, die L-Kerne 1914 und H-Kerne 1916 beinhalten können. In einigen Aspekten kann der 5G-Core-Server 1910 eine oder mehrere VNF durch Verwenden der mehreren Prozessorkerne 1912 instanziieren und ausführen, wobei die VNF sowohl L-als auch H-Kerne verwendet. Zum Beispiel, und wie in 19 veranschaulicht, wird, während VNF9 ursprünglich die L-Kerne 1914 verwendet hat, VNF9 an einem späteren Zeitpunkt bewegt, um eine Kombination sowohl der L-Kerne 1914 als auch der H-Kerne 1916 zu verwenden. Zusätzlich kann in Aspekten, in denen eine VNF sowohl L- als auch H-Kerne innerhalb des 5G-Core-Servers 1910 verwendet, einer oder mehrere der durch die VNF verwendeten L- und H-Kerne hardwarebeschleunigt sein.
  • 20 veranschaulicht 5G-Edge-/Core-Server, der VNF durch Verwenden von Prozessorkernen ausführt, die in einer Kernbasisfrequenz oder in einer Kombination von hohen und niedrigen Basisfrequenzen durch Verwenden von CPU mit dynamischer deterministischer Skalierung arbeiten können, gemäß einem Beispiel. 5G-Edge-/Core-Server 2002 kann ein MEC-Host zum Implementieren einer oder mehrerer MEC-Plattform-VNF oder anderer MEC-bezogener Funktionalitäten (zum Beispiel MEC-Plattformmanager, Orchestrator, usw.) innerhalb einer 5G-Kommunikationsarchitektur oder eines Host-Servers sein, der eine oder mehrere dem 5G-Kern zugeordnete netzwerkbezogene Kernfunktionalitäten ausführt (zum Beispiel 5G-PCF, 5G-SMF, 5G-UPF, 5G-AF usw.). 20 veranschaulicht zwei Betriebsszenarien (2001 und 2003) für den Server 2002.
  • Der Server 2002 beinhaltet mehrere Prozessorkerne auf CPU-Sockets 2004 und 2006, die (in dem Betriebsszenario 2003) mit derselben Basisfrequenz (auch bezeichnet als Mittenbasisfrequenz) konfiguriert sind. In dieser Hinsicht verwenden VNF 2012, die durch den Server 2002 ausgeführt werden, einen oder mehrere der Prozessorkerne von den CPU-Sockets 2004 und 2006, die mit derselben Basisfrequenz arbeiten. Tabelle 2 unten veranschaulicht Prozessorkerne (zum Beispiel die Kerne des Servers 2002), die alle dazu ausgelegt sind, mit derselben Basisfrequenz von 2,3 GHz zu arbeiten. TABELLE 2: Für alle Prozessorkerne ermöglichte Standardbasisfrequenz.
    PROZESSORKERN BASISFREQUENZ (Hz) MAX. FREQUENZ (Hz) MIN. FREQUENZ (Hz)
    0 2300 3600 1000
    1 2300 3600 1000
    2 2300 3600 1000
    3 2300 3600 1000
    4 2300 3600 1000
    5 2300 3600 1000
    6 2300 3600 1000
    7 2300 3600 1000
    8 2300 3600 1000
    9 2300 3600 1000
    10 2300 3600 1000
    11 2300 3600 1000
    12 2300 3600 1000
    13 2300 3600 1000
    14 2300 3600 1000
    15 2300 3600 1000
    16 2300 3600 1000
    17 2300 3600 1000
    18 2300 3600 1000
    19 2300 3600 1000
    20 2300 3600 1000
    21 2300 3600 1000
    22 2300 3600 1000
    23 2300 3600 1000
  • In einigen Aspekten (in Verbindung mit dem Betriebsszenario 2001) kann der Server 2002 dazu befähigt werden, eine dynamische Prozessorkernskalierung durch Verwenden der hierin diskutierten Techniken zu verwenden, sodass die Prozessorkerne auf den Sockets 2004 und 2006 dazu ausgelegt sind, mit unterschiedlichen Basisfrequenzen zu arbeiten (L-Kerne und H-Kerne, wie in 20 veranschaulicht). Einige der L-Kerne und/oder der H-Kerne können wie zuvor diskutiert hardwarebeschleunigt sein. VNF 2008 können durch Verwenden der L-Kerne instanziiert werden, und VNF 2010 können durch Verwenden der H-Kerne instanziiert werden. In einigen Aspekten können unterschiedliche Untersätze der H- und L-Kerne hardwarebeschleunigt sein. Zusätzlich können, wie in 20 veranschaulicht, die H- und L-Kerne innerhalb der Sockets basierend auf zum Beispiel einem Herstellungsprozess zufällig zugewiesen werden.
  • Tabelle 3 unten veranschaulicht eine beispielhafte Zuweisung einer hohen oder niedrigen Basisfrequenz für die Prozessorkerne des Servers 2002 unter dem Betriebsszenario 2001, wenn die dynamische Prozessorkernskalierung ermöglicht ist. Wie in Tabelle 3 veranschaulicht, sind die Prozessorkerne 0, 2, 11, 12 und 14-17 die H-Kerne, wie sie für den Betrieb mit einer hohen Basisfrequenz von 2,8 GHz konfiguriert sind, und die verbleibenden Prozessorkerne sind die L-Kerne, wie sie für den Betrieb mit einer niedrigen Basisfrequenz von 2,1 GHz konfiguriert sind. TABELLE 3: Für alle Prozessorkerne ermöglichte hohe oder niedrige Basisfrequenz
    PROZESSORKERN BASISFREQUENZ (Hz) MAX. FREQUENZ (Hz) MIN. FREQUENZ (Hz)
    0 2800 2800 2800
    1 2100 2100 2100
    2 2800 2800 2800
    3 2100 2100 2100
    4 2100 2100 2100
    5 2100 2100 2100
    6 2100 2100 2100
    7 2100 2100 2100
    8 2100 2100 2100
    9 2100 2100 2100
    10 2100 2100 2100
    11 2800 2800 2800
    12 2800 2800 2800
    13 2100 2100 2100
    14 2800 2800 2800
    15 2800 2800 2800
    16 2800 2800 2800
    17 2800 2800 2800
    18 2100 2100 2100
    19 2100 2100 2100
    20 2100 2100 2100
    21 2100 2100 2100
    22 2100 2100 2100
    23 2100 2100 2100
  • In einigen Aspekten kann eine VNF, um L- und/oder H-Kerne zu verwenden, an eine Gruppe von CPU-Kernen (zum Beispiel L-Kerne, H-Kerne oder eine Kombination von L- und H-Kernen) „pinnen“. Wie hierin verwendet, bezeichnet der Begriff „pinnen“ (oder „Pinnen“) einer VNF an Prozessorkerne die Zuweisung von CPU-Kernen, die zum Betreiben/Ausführen der VNF verwendet werden (zum Beispiel virtuelle CPU, die zum Ausführen der VNF verwendet werden), zu Prozessorkernen mit niedriger oder hoher Priorität eines Hardware-Geräts. In einigen Aspekten können einer VNF zu dem Zeitpunkt des Startens des der VNF zugeordneten VM spezifische H-Kerne oder L-Kerne, oder eine Kombination von sowohl H- als auch L-Kernen statisch zugewiesen werden. Zusätzlich kann eine VNF durch Verwenden eines Task-Set (oder eines ähnlichen) -Linux-Befehls dynamisch an H- oder L-Kerne „gepinnt“ werden. Innerhalb der VNF können Kerne nach Bedarf an unterschiedliche Funktionen verteilt/zugewiesen werden. Zum Beispiel stellt FortiGate-VNF den folgenden Befehl innerhalb der in Tabelle 4 unten aufgeführten VNF bereit, um einer Paketneuverteilungsfunktion einen Kern (Kernmaske 0xE) zuzuweisen: TABELLE 4
    config system affinity-packet-redistribution edit 1
    set interface portX
    set affinity-cpumask „0xE“ next
  • In einigen Aspekten kann der folgende in Tabelle 5 unten aufgeführte Pseudocode zum Pinnen (zum Beispiel Zuweisen) von L-Kernen oder H-Kernen des
    Figure DE102020202398A1_0001
    Servers 2002 als virtuelle CPU-Kerne verwendet werden, die der Ausführung einer VNF durch Verwenden von H-Kernen zugeordnet sind.
    TABELLE 5
  • Wie von dem obigen Code ersichtlich, sind virtuelle CPU 0-7 (zum Beispiel CPU, die einer die VNF ausführenden virtuellen Maschine zugeordnet sind) an die H-Kerne (0, 2, 11, 12 und 14-17) gepinnt. In einigen Aspekten können virtuelle CPU an eine Kombination von H- und L-Kernen gepinnt werden. In einigen Aspekten können virtuelle CPU basierend auf hierin diskutierten Telemetrieparametern dynamisch gepinnt und neu gepinnt werden.
  • Es sollte klargestellt werden, dass die in dieser Spezifikation beschriebenen funktionalen Einheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um insbesondere ihre Implementierungsunabhängigkeit zu betonen. Solche Komponenten können durch jegliche Anzahl von Software- oder Hardware-Formen verkörpert sein. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardware-Schaltung implementiert sein, die kundenspezifische Very-Large-Scale-Integration (VLSI)-Schaltungen oder Gate-Arrays, serienmäßige Halbleiter, wie zum Beispiel Logikchips, Transistoren, oder andere spezielle Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardware-Geräten, wie zum Beispiel Field-Programmable-Gate-Arrays, programmierbarer Array-Logik, programmierbaren Logikgeräten, oder dergleichen implementiert sein. Komponenten oder Module können auch in Software implementiert werden, um durch verschiedene Prozessortypen ausgeführt zu werden. Eine identifizierte Komponente oder ein Modul von ausführbarem Code kann beispielsweise einen oder mehrere physikalische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Dateien einer identifizierten Komponente oder eines Moduls nicht physikalisch zusammen platziert sein, sondern können verschiedenartige an unterschiedlichen Standorten gespeicherte Anweisungen umfassen, die, wenn logisch miteinander verbunden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.
  • In der Tat kann eine Komponente oder ein Modul von ausführbarem Code eine einzelne Anweisung oder viele Anweisungen sein, und kann sogar über mehrere unterschiedliche Codesegmente, zwischen unterschiedlichen Programmen und über mehrere Speichergeräte oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie zum Beispiel Neuschreiben von Code und Code-Analyse) auf einem unterschiedlichen Verarbeitungssystem (zum Beispiel in einem Computer in einem Datenzentrum) stattfinden, als auf dem, in dem der Code eingesetzt wird (zum Beispiel in einem Computer, der in einen Sensor oder Roboter eingebettet ist). In ähnlicher Weise können Betriebsdaten innerhalb von Komponenten oder Modulen hierin identifiziert und veranschaulicht werden, und können in jeglicher geeigneten Form verkörpert und innerhalb jeglichen geeigneten Typs von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einzelner Datensatz gesammelt oder über unterschiedliche Standorte, einschließlich über unterschiedliche Speicherungsgeräte, 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 zur Ausführung gewünschter Funktionen betrieben werden können.
  • Zusätzliche Beispiele der gegenwärtig beschriebenen Verfahrens-, System- und Geräteausführungsformen beinhalten die folgenden, nicht beschränkenden Konfigurationen. Jedes der folgenden nicht beschränkenden Beispiele kann für sich allein stehen, oder kann in jeglicher Permutation oder Kombination mit jeglichem einen oder mehreren der anderen unten oder über die gesamte vorliegende Offenbarung hinweg bereitgestellten Beispiele kombiniert werden.
  • Beispiel 1 ist eine Verarbeitungsschaltungsanordnung, die Folgendes umfasst: Verarbeitungsschaltung, wobei die Verarbeitungsschaltung mehrere Prozessorkerne umfasst, die mit einer Mittenbasisfrequenz arbeiten; und ein Speichergerät, das darauf verkörperte Anweisungen beinhaltet, wobei die Anweisungen, wenn durch die Verarbeitungsschaltung ausgeführt, die Verarbeitungsschaltung dazu auslegen, Operationen auszuführen, um: als Reaktion auf eine Anforderung für eine Mehrfrequenzkernoperation einen ersten Satz der mehreren Prozessorkerne dazu auszulegen, mit einer ersten modifizierten Basisfrequenz zu arbeiten, und einen zweiten Satz der mehreren Prozessorkerne dazu auszulegen, mit einer zweiten modifizierten Basisfrequenz zu arbeiten; Konfigurationsinformationen für mehrere virtuelle Central-Processing-Units (CPU) einer virtuellen Maschine wieder abzurufen, wobei die mehreren virtuellen CPU eine Network-Function-Virtualization (NFV) -Instanz ausführen, die als virtueller Service in einem Zugangsnetzwerk instanziiert ist; und Prozessorkerne von dem ersten Satz oder dem zweiten Satz als die mehreren virtuellen CPU zu pinnen (zum Beispiel zuzuweisen), um die NFV-Instanz basierend auf den wieder abgerufenen Konfigurationsinformationen auszuführen.
  • Beispiel 2 beinhaltet den Gegenstand von Beispiel 1, wobei die erste modifizierte Basisfrequenz niedriger als die Mittenbasisfrequenz ist, und die zweite modifizierte Basisfrequenz höher als die Mittenbasisfrequenz ist.
  • Beispiel 3 beinhaltet den Gegenstand der Beispiele 1-2, wobei die Konfigurationsinformationen eine Anzahl von virtuellen CPU der mehreren zum Ausführen der NFV-Instanz verwendeten virtuellen CPU und eine minimale Betriebsfrequenz für die Anzahl von virtuellen CPU beinhalten.
  • Beispiel 4 beinhaltet den Gegenstand der Beispiele 1-3, wobei das Pinnen der Prozessorkerne dynamisch ausgeführt wird, um eine Anzahl von gepinnten Prozessorkernen von dem ersten Satz oder dem zweiten Satz basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks anzupassen.
  • Beispiel 5 beinhaltet den Gegenstand der Beispiele 1-4, wobei das Pinnen der Prozessorkerne ferner darauf basiert, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über einem Nutzungsschwellenwert liegt.
  • Beispiel 6 beinhaltet den Gegenstand der Beispiele 2-5, wobei die Verarbeitungsschaltung ferner Operationen ausführt, um die Prozessorkerne von dem ersten Satz als die mehreren virtuellen CPU zu pinnen, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks unter einem Nutzungsschwellenwert liegt.
  • Beispiel 7 beinhaltet den Gegenstand von Beispiel 6, wobei die Verarbeitungsschaltung ferner Operationen ausführt, um die Prozessorkerne von dem ersten Satz zu dem zweiten Satz als die mehreren virtuellen CPU neu zu pinnen, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über dem Nutzungsschwellenwert liegt.
  • Beispiel 8 beinhaltet den Gegenstand der Beispiele 1-7, wobei das Pinnen der Prozessorkerne auf dem Netzwerkverkehr oder einer den virtuellen Service verwendenden Anzahl von UE basiert.
  • Beispiel 9 beinhaltet den Gegenstand der Beispiele 1-8, wobei die virtuellen Services mindestens einen virtuellen Firewall-Service, einen virtuellen Router-Service, einen virtuellen Load-Balancer-Service, einen virtuellen Analyse-Service, einen virtuellen Steuerungs-Service und einen virtuellen Management-Service beinhalten.
  • Beispiel 10 beinhaltet den Gegenstand der Beispiele 1-9, wobei die Verarbeitungsschaltung ferner Operationen ausführt, um einen Untersatz des ersten Satzes und einen Untersatz des zweiten Satzes als die mehreren den virtuellen Service ausführenden virtuellen CPU zu pinnen, basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks.
  • Beispiel 11 beinhaltet den Gegenstand der Beispiele 1-10, wobei mindestens einer des ersten Satzes von Prozessorkernen und mindestens einer des zweiten Satzes von Prozessorkernen während der Ausführung der NFV-Instanz hardwarebeschleunigt ist.
  • Beispiel 12 beinhaltet den Gegenstand der Beispiele 1-11, wobei der erste Satz und der zweite Satz der mehreren Prozessorkerne innerhalb von mindestens einem CPU-Socket zufällig verteilt sind, basierend auf einem CPU-Herstellungsprozess.
  • Beispiel 13 ist mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium, das Anweisungen beinhaltet, wobei die Anweisungen, wenn durch eine Verarbeitungsschaltung einer Service-Koordinierungsentität in einem Zugangsnetzwerk ausgeführt, die Verarbeitungsschaltung dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Konfigurieren eines ersten Satzes von mehreren Prozessorkernen der Verarbeitungsschaltung, um mit einer ersten modifizierten Basisfrequenz zu arbeiten, und eines zweiten Satzes der mehreren Prozessorkerne, um mit einer zweiten modifizierten Basisfrequenz zu arbeiten, als Reaktion auf eine Anforderung für eine Mehrfrequenzkernoperation; Wiederabrufen von Konfigurationsinformationen für mehrere virtuelle Central-Processing-Units (CPU) einer virtuellen Maschine, wobei die mehreren vCPU eine Network-Function-Virtualization (NFV) -Instanz ausführen, die als virtueller Service in dem Zugangsnetzwerk instanziiert ist; und Pinnen von Prozessorkernen von dem ersten Satz oder dem zweiten Satz als die mehreren virtuellen CPU, um die NFV-Instanz basierend auf den wieder abgerufenen Konfigurationsinformationen auszuführen.
  • Beispiel 14 beinhaltet den Gegenstand von Beispiel 13, wobei die erste modifizierte Basisfrequenz niedriger als die Mittenbasisfrequenz ist, und die zweite modifizierte Basisfrequenz höher als die Mittenbasisfrequenz ist.
  • Beispiel 15 beinhaltet den Gegenstand der Beispiele 13-14, wobei die Konfigurationsinformationen eine Anzahl von virtuellen CPU der mehreren zum Ausführen der NFV-Instanz verwendeten virtuellen CPU und eine minimale Betriebsfrequenz für die Anzahl von virtuellen CPU beinhalten.
  • Beispiel 16 beinhaltet den Gegenstand der Beispiele 13-15, wobei das Pinnen der Prozessorkerne dynamisch ausgeführt wird, um eine Anzahl von gepinnten Prozessorkernen von dem ersten Satz oder dem zweiten Satz basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks anzupassen.
  • Beispiel 17 beinhaltet den Gegenstand der Beispiele 13-16, wobei das Pinnen der Prozessorkerne ferner darauf basiert, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über einem Nutzungsschwellenwert liegt.
  • Beispiel 18 beinhaltet den Gegenstand der Beispiele 14-17, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Pinnen der Prozessorkerne von dem ersten Satz als die mehreren virtuellen CPU, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks unter einem Nutzungsschwellenwert liegt.
  • Beispiel 19 beinhaltet den Gegenstand von Beispiel 18, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: neues Pinnen der Prozessorkerne von dem ersten Satz zu dem zweiten Satz als die mehreren virtuellen CPU, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über dem Nutzungsschwellenwert liegt.
  • Beispiel 20 beinhaltet den Gegenstand der Beispiele 13-19, wobei das Pinnen der Prozessorkerne auf dem Netzwerkverkehr oder einer den virtuellen Service verwendenden Anzahl von UE basiert.
  • Beispiel 21 beinhaltet den Gegenstand der Beispiele 13-20, wobei die virtuellen Services mindestens einen virtuellen Firewall-Service, einen virtuellen Router-Service, einen virtuellen Load-Balancer-Service, einen virtuellen Analyse-Service, einen virtuellen Steuerungs-Service und einen virtuellen Management-Service beinhalten.
  • Beispiel 22 beinhaltet den Gegenstand der Beispiele 13-21, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Pinnen eines Untersatzes des ersten Satzes und eines Untersatzes des zweiten Satzes als die mehreren den virtuellen Service ausführenden virtuellen CPU, basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks.
  • Beispiel 23 beinhaltet den Gegenstand der Beispiele 13-22, wobei mindestens einer des ersten Satzes von Prozessorkernen und mindestens einer des zweiten Satzes von Prozessorkernen während der Ausführung der NFV-Instanz hardwarebeschleunigt ist.
  • Beispiel 24 beinhaltet den Gegenstand der Beispiele 13-23, wobei der erste Satz und der zweite Satz der mehreren Prozessorkerne innerhalb von mindestens einem CPU-Socket zufällig verteilt sind, basierend auf einem CPU-Herstellungsprozess.
  • Beispiel 25 ist ein Gerät einer Service-Koordinierungsentität, das Folgendes umfasst: Kommunikationsschaltung zum Kommunizieren mit einem ersten Zugangsnetzwerk von mehreren Zugangsnetzwerken; Verarbeitungsschaltung, wobei die Verarbeitungsschaltung mindestens einen ersten Satz und einen zweiten Satz von Prozessorkernen umfasst, die bei entsprechenden ersten und zweiten Basisfrequenzen arbeiten; und ein Speichergerät, das darauf verkörperte Anweisungen beinhaltet, wobei die Anweisungen, wenn durch die Verarbeitungsschaltung ausgeführt, die Verarbeitungsschaltung dazu auslegen, Operationen auszuführen, um: als Reaktion auf eine Anforderung zum Einrichten einer Verbindung mit einer oder mehreren Benutzerausrüstungen (UE) in dem ersten Zugangsnetzwerk mehrere Network-Function-Virtualization (NFV)-Instanzen durch Verwenden des ersten Satzes von Prozessorkernen zu instanziieren, um mit der einen oder den mehreren UE zu kommunizieren; den Netzwerkverkehr zwischen der Service-Koordinierungsentität und der einen oder den mehreren UE in dem ersten Zugangsnetzwerk zu überwachen; und als Reaktion darauf, dass der Netzwerkverkehr über einen ersten Schwellenwert ansteigt, die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen.
  • Beispiel 26 beinhaltet den Gegenstand von Beispiel 25, wobei der erste Satz von Prozessorkernen ein Satz von Prozessorkernen mit niedriger Priorität ist, die mit der ersten Basisfrequenz arbeiten, wobei die erste Basisfrequenz niedriger als die zweite Basisfrequenz ist.
  • Beispiel 27 beinhaltet den Gegenstand von Beispiel 26, wobei der zweite Satz von Prozessorkernen ein Satz von Prozessorkernen mit hoher Priorität ist, die mit der zweiten Basisfrequenz arbeiten, wobei die zweite Basisfrequenz höher als die erste Basisfrequenz ist.
  • Beispiel 28 beinhaltet den Gegenstand von Beispiel 27, wobei mindestens eine NFV-Instanz der mehreren NFV-Instanzen hardwarebeschleunigt ist.
  • Beispiel 29 beinhaltet den Gegenstand der Beispiele 27-28, wobei die Service-Koordinierungsentität ein 5G-Edge-Server oder ein 5G-Core-Server ist.
  • Beispiel 30 beinhaltet den Gegenstand der Beispiele 27-29, wobei mindestens eine NFV-Instanz der mehreren NFV-Instanzen ursprünglich durch Verwenden von mindestens einem des ersten Satzes von Prozessorkernen instanziiert wird, und anschließend zur Verwendung von mindestens einem des zweiten Satzes von Prozessorkernen verlagert wird.
  • Beispiel 31 beinhaltet den Gegenstand von Beispiel 30, wobei der mindestens eine des ersten Satzes von Prozessorkernen oder der mindestens eine des zweiten Satzes von Prozessorkernen hardwarebeschleunigt ist.
  • Beispiel 32 beinhaltet den Gegenstand der Beispiele 30-31, wobei die Verlagerung der mindestens einen NFV auf 5G-Netzwerkanforderungen basiert.
  • Beispiel 33 beinhaltet den Gegenstand der Beispiele 27-32, wobei mindestens eine NFV-Instanz der mehreren NFV-Instanzen durch Verwenden von mindestens einem des ersten Satzes von Prozessorkernen und mindestens einem des zweiten Satzes von Prozessorkernen instanziiert wird.
  • Beispiel 34 beinhaltet den Gegenstand von Beispiel 33, wobei der mindestens eine des ersten Satzes von Prozessorkernen oder der mindestens eine des zweiten Satzes von Prozessorkernen hardwarebeschleunigt ist.
  • Beispiel 35 beinhaltet Gegenstand der Beispiele 25-34, wobei die mehreren NFV-Instanzen als virtuelle Services instanziiert sind, und die eine oder die mehreren UE Teilnehmer an den virtuellen Services sind.
  • Beispiel 36 beinhaltet den Gegenstand von Beispiel 35, wobei die virtuellen Services mindestens einen virtuellen Firewall-Service, einen virtuellen Router-Service, einen virtuellen Load-Balancer-Service, einen virtuellen Analyse-Service, einen virtuellen Steuerungs-Service und einen virtuellen Management-Service beinhalten.
  • Beispiel 37 beinhaltet den Gegenstand der Beispiele 35-36, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist, die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen, basierend darauf, dass die Nutzung der virtuellen Services durch die eine oder die mehreren UE über einem Nutzungsschwellenwert liegt.
  • Beispiel 38 beinhaltet den Gegenstand der Beispiele 35-37, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von einem Untersatz des ersten Satzes von Prozessorkernen zu einem Untersatz des zweiten Satzes von Prozessorkernen zu übertragen, basierend darauf, dass die Nutzung der virtuellen Services durch die eine oder die mehreren UE über einem Nutzungsschwellenwert liegt, wobei mindestens einer der virtuellen Services auf mehreren Prozessorkernen innerhalb des ersten Satzes und des zweiten Satzes von Prozessorkernen instanziiert ist.
  • Beispiel 39 beinhaltet den Gegenstand der Beispiele 35-38, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, zwischen einem oder mehreren des ersten Satzes von Prozessorkernen zu einem oder mehreren des zweiten Satzes von Prozessorkernen dynamisch zu übertragen, basierend auf einem Nutzungsschwellenwert, der der Nutzung der virtuellen Services durch die eine oder die mehreren UE zugeordnet ist.
  • Beispiel 40 beinhaltet den Gegenstand der Beispiele 25-39, wobei der erste Satz von Prozessorkernen mit Frequenzen unter 1,9 GHz arbeitet, und der zweite Satz von Prozessorkernen mit Frequenzen unter 2,6 GHz arbeitet.
  • Beispiel 41 beinhaltet den Gegenstand der Beispiele 25-40, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: als Reaktion darauf, dass der Netzwerkverkehr unter einen zweiten Schwellenwert abfällt, die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen zu übertragen.
  • Beispiel 42 beinhaltet den Gegenstand der Beispiele 25-41, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: den Netzwerkverkehr in Echtzeit durch Verwenden einer Server-Telemetriefunktion zu überwachen.
  • Beispiel 43 beinhaltet den Gegenstand der Beispiele 25-42, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist, eine Anzahl der einen oder mehreren UE, die mit der Servicekoordinierungsentität über die NFV-Instanzen kommunizieren, zu überwachen; und als Reaktion darauf, dass die Anzahl der einen oder mehreren UE über einem dritten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen.
  • Beispiel 44 beinhaltet den Gegenstand von Beispiel 43, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: als Reaktion darauf, dass die Anzahl der einen oder mehreren UE unter einen vierten Schwellenwert abfällt, die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen zu übertragen.
  • Beispiel 45 beinhaltet den Gegenstand der Beispiele 25-44, wobei jede NFV-Instanz der mehreren NFV-Instanzen eine Multi-Access-Edge-Computing (MEC) -Anwendung ist, die auf einer Virtualisierungsinfrastruktur der Service-Koordinierungsentität ausgeführt wird.
  • Beispiel 46 beinhaltet den Gegenstand von Beispiel 45, wobei die MEC-Anwendung mindestens eine einer virtuellen Router (vRTR) -Anwendung, einer virtuellen Firewall (vFW) -Anwendung, einer virtuellen Load-Balancer (vLB) -Anwendung, einer virtuellen Steuerungs-Anwendung (vControl) und einer virtuellen Management-Anwendung (vMGMT) ist.
  • Beispiel 47 beinhaltet den Gegenstand der Beispiele 25-46, wobei die Service-Koordinierungsentität ein Multi-Access-Edge-Computing (MEC) -Host ist, der die mehreren NFV-Instanzen als entsprechende mehrere MEC-Anwendungen, die auf einer Virtualisierungsinfrastruktur der Service-Koordinierungsentität instanziiert sind, ausführt.
  • Beispiel 48 beinhaltet den Gegenstand von Beispiel 47, wobei der MEC-Host dazu ausgelegt ist, gemäß einem Standard von einer MEC-Standardfamilie des European-Telecommunications-Standards-Institute (ETSI) zu arbeiten.
  • Beispiel 49 beinhaltet den Gegenstand der Beispiele 25-48, wobei die mehreren Zugangsnetzwerke drahtlose Netzwerke sind, die gemäß einer 3GPP-Standardfamilie, einschließlich eines 5G-Kommunikationsstandards, arbeiten.
  • Beispiel 50 ist mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium, das Anweisungen beinhaltet, wobei die Anweisungen, wenn durch eine Verarbeitungsschaltung einer Service-Koordinierungsentität in einem ersten Zugangsnetzwerk von mehreren Zugangsnetzwerken ausgeführt, wobei die Verarbeitungsschaltungen mindestens einen ersten Satz und einen zweiten Satz von Prozessorkernen umfassen, die bei entsprechenden ersten und zweiten Basisfrequenzen arbeiten, die Verarbeitungsschaltung dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: als Reaktion auf eine Anforderung zum Einrichten einer Verbindung mit einer oder mehreren Benutzerausrüstungen (UE) in einem Zugangsnetzwerk von mehreren verfügbaren Zugangsnetzwerken mehrere Network-Function-Virtualization (NFV) -Instanzen durch Verwenden des ersten Satzes von Prozessorkernen oder des zweiten Satzes von Prozessorkernen zu instanziieren, um mit der einen oder den mehreren UE zu kommunizieren; den Netzwerkverkehr zwischen der Service-Koordinierungsentität und der einen oder den mehreren UE in dem ersten Zugangsnetzwerk zu überwachen; und als Reaktion darauf, dass der Netzwerkverkehr über einen ersten Schwellenwert ansteigt, die Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von einem ersten Satz von Prozessorkernen zu einem zweiten Satz von Prozessorkernen der Verarbeitungsschaltung zu übertragen. wobei der erste und der zweite Satz von Prozessorkernen unterschiedliche Basisfrequenzen verwenden.
  • Beispiel 51 beinhaltet den Gegenstand von Beispiel 50, wobei der erste Satz von Prozessorkernen ein Satz von Prozessorkernen mit niedriger Priorität ist, die mit der ersten Basisfrequenz arbeiten, wobei die erste Basisfrequenz niedriger als die zweite Basisfrequenz ist.
  • Beispiel 52 beinhaltet den Gegenstand der Beispiele 50-51, wobei der zweite Satz von Prozessorkernen ein Satz von Prozessorkernen mit hoher Priorität ist, die mit der zweiten Basisfrequenz arbeiten, wobei die zweite Basisfrequenz höher als die erste Basisfrequenz ist.
  • Beispiel 53 beinhaltet den Gegenstand der Beispiele 50-52, wobei der erste Satz von Prozessorkernen mit Frequenzen unter 1,9 GHz arbeitet, und der zweite Satz von Prozessorkernen mit Frequenzen unter 2,6 GHz arbeitet.
  • Beispiel 54 beinhaltet den Gegenstand der Beispiele 50-53, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: als Reaktion darauf, dass der Netzwerkverkehr unter einen zweiten Schwellenwert abfällt, Übertragen der Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen.
  • Beispiel 55 beinhaltet den Gegenstand der Beispiele 50-54, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Überwachen des Netzwerkverkehrs in Echtzeit durch Verwenden einer Server-Telemetriefunktion.
  • Beispiel 56 beinhaltet den Gegenstand der Beispiele 50-55, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Überwachen einer Anzahl der einen oder mehreren UE, die mit der Service-Koordinierungsentität über die NFV-Instanzen kommunizieren; und als Reaktion darauf, dass die Anzahl der einen oder mehreren UE über einem dritten Schwellenwert liegt, Übertragen der Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen.
  • Beispiel 57 beinhaltet den Gegenstand von Beispiel 56, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: als Reaktion darauf, dass die Anzahl der einen oder mehreren UE unter einen vierten Schwellenwert abfällt, Übertragen der Verarbeitung des Netzwerkverkehrs, der der einen oder den mehreren UE zugeordnet ist, von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen.
  • Beispiel 58 beinhaltet den Gegenstand der Beispiele 50-57, wobei jede NFV-Instanz der mehreren NFV-Instanzen eine Multi-Access-Edge-Computing (MEC) -Anwendung ist, die auf einer Virtualisierungsinfrastruktur der Service-Koordinierungsentität ausgeführt wird.
  • Beispiel 59 beinhaltet den Gegenstand der Beispiele 50-58, wobei die Service-Koordinierungsentität ein Multi-Access-Edge-Computing (MEC) -Host ist, der die mehreren NFV-Instanzen als entsprechende eine oder mehrere MEC-Anwendungen, die auf einer Virtualisierungsinfrastruktur der Service-Koordinierungsentität instanziiert sind, ausführt.
  • Beispiel 60 beinhaltet den Gegenstand von Beispiel 59, wobei der MEC-Host dazu ausgelegt ist, gemäß einem Standard von einer MEC-Standardfamilie des European-Telecommunications-Standards-Institute (ETSI) zu arbeiten.
  • Beispiel 61 ist ein Multi-Access-Edge-Computing (MEC) -Gerät, das Folgendes umfasst: Telemetrieschaltung, die dazu ausgelegt ist, den Netzwerkverkehr zwischen dem MEC-Gerät und mehreren Benutzerausrüstungen (UE) innerhalb eines Kommunikationsnetzwerks von mehreren Kommunikationsnetzwerken zu überwachen; Verarbeitungsschaltung, wobei die Verarbeitungsschaltung mindestens einen ersten Satz und einen zweiten Satz von Prozessorkernen umfasst, die mit entsprechenden ersten und zweiten Basisfrequenzen arbeiten, wobei die erste Basisfrequenz niedriger als die zweite Basisfrequenz ist; und ein Speichergerät, das mit der Telemetrieschaltung und der Verarbeitungsschaltung gekoppelt ist, wobei das Speichergerät darauf verkörperte Anweisungen beinhaltet, wobei die Anweisungen, wenn durch die Verarbeitungsschaltung ausgeführt, die Verarbeitungsschaltung dazu auslegen, Operationen auszuführen, um: über die Telemetrieschaltung zu erkennen, dass eine Anzahl der UE, die über mindestens eine Network- Function-Virtualization (NFV) -Instanz mit dem MEC-Gerät in Kommunikation sind, über einem ersten Schwellenwert liegt; und als Reaktion darauf, dass die Anzahl der UE, die mit dem MEC-Gerät in Kommunikation sind, über dem ersten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs, der der mindestens einen NFV-Instanz zugeordnet ist, von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen.
  • Beispiel 62 beinhaltet den Gegenstand von Beispiel 61, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: über die Telemetrieschaltung zu erkennen, dass die Anzahl der UE, die mit dem MEC-Gerät in Kommunikation sind, unter dem ersten Schwellenwert liegt; und als Reaktion darauf, dass die Anzahl der UE, die mit dem MEC-Gerät in Kommunikation sind, unter dem ersten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs, der der mindestens einen NFV-Instanz zugeordnet ist, von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen zu übertragen.
  • Beispiel 63 beinhaltet den Gegenstand der Beispiele 61-62, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist, über einen oder mehrere Telemetrieindikatoren, die durch die Telemetrieschaltung gemessen werden, zu erkennen, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät über einem zweiten Schwellenwert liegt; und als Reaktion darauf, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät über dem zweiten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen.
  • Beispiel 64 beinhaltet den Gegenstand von Beispiel 63, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist, über den einen oder die mehreren Telemetrieindikatoren, die durch die Telemetrieschaltung gemessen werden, zu erkennen, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät unter dem zweiten Schwellenwert liegt; und als Reaktion darauf, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät unter dem zweiten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen zu übertragen.
  • Beispiel 65 beinhaltet den Gegenstand der Beispiele 61-64, wobei die mindestens eine NFV-Instanz mindestens eine Multi-Access-Edge-Computing (MEC) -Anwendung ist, die auf einer Virtualisierungsinfrastruktur des MEC-Geräts ausgeführt wird.
  • Beispiel 66 beinhaltet den Gegenstand von Beispiel 65, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist, über die Telemetrieschaltung ein Prozessor-Burst-Ereignis zu erkennen, das dem Netzwerkverkehr der mindestens einen MEC-Anwendung zugeordnet ist; und als Reaktion auf das erkannte Prozessor-Burst-Ereignis die Verarbeitung des Netzwerkverkehrs der mindestens einen MEC-Anwendung zwischen dem ersten Satz von Prozessorkernen und dem zweiten Satz von Prozessorkernen zu übertragen.
  • Beispiel 67 ist mindestens ein maschinenlesbares Medium, das Anweisungen beinhaltet, die, wenn durch eine Verarbeitungsschaltung ausgeführt, die Verarbeitungsschaltung dazu veranlassen, Operationen zum Implementieren von jeglichem der Beispiele 1-66 auszuführen.
  • Beispiel 68 ist eine Vorrichtung, die Mittel zum Implementieren von jeglichem der Beispiele 1-66 umfasst.
  • Beispiel 69 ist ein System zum Implementieren von jeglichem der Beispiele 1-66.
  • Beispiel 70 ist ein Verfahren zum Implementieren von jeglichem der Beispiele 1-66.
  • Verschiedene Modifikationen und Änderungen können an offenbarten Aspekten gemacht werden, ohne von dem breiteren Umfang der vorliegenden Offenbarung abzuweichen. Dementsprechend sind die Spezifikation und Zeichnungen eher in einem veranschaulichenden als in einem beschränkenden Sinn zu betrachten. Die beigefügten Zeichnungen, die einen Teil hiervon bilden, zeigen zur Veranschaulichung, und nicht zur Beschränkung, spezifische Aspekte, in denen der Gegenstand praktiziert werden kann. Die veranschaulichten Aspekte werden ausreichend detailliert beschrieben, um es Fachleuten zu ermöglichen, die hierin offenbarten Lehren zu praktizieren. Andere Aspekte können verwendet und daraus abgeleitet werden, sodass strukturelle und logische Ersetzungen und Änderungen gemacht werden können, ohne von dem Umfang dieser Offenbarung abzuweichen. Diese detaillierte Beschreibung ist daher nicht in einem beschränkenden Sinne zu verstehen, und der Umfang verschiedener Aspekte wird nur durch die beigefügten Ansprüche zusammen mit dem gesamten Bereich der Äquivalente, für die solche Ansprüche berechtigt sind, definiert.
  • Auf solche Aspekte des erfindungsgemäßen Gegenstands kann hierin einzeln und/oder kollektiv nur der Einfachheit halber und ohne die Absicht, den Umfang dieser Anmeldung freiwillig auf einen einzelnen Aspekt oder ein erfinderisches Konzept zu beschränken, Bezug genommen werden, wenn mehr als eines tatsächlich offenbart wird. Somit sollte, obwohl spezifische Aspekte hierin veranschaulicht und beschrieben worden sind, klar sein, dass jegliche Anordnung, die kalkuliert war, um denselben Zweck zu erreichen, durch die gezeigten spezifischen Aspekte ersetzt werden kann. Diese Offenbarung soll jegliche und alle Anpassungen oder Variationen verschiedener Aspekte abdecken. Kombinationen der obigen Aspekte und anderer hierin nicht spezifisch beschriebener Aspekte werden für Fachleute nach Durchsicht der obigen Beschreibung offensichtlich.
  • Die Zusammenfassung der Offenbarung wird bereitgestellt, um es dem Leser zu ermöglichen, die Art der technischen Offenbarung schnell festzustellen. Sie wird mit dem Verständnis übermittelt, dass sie nicht dazu verwendet wird, den Umfang oder die Bedeutung der Ansprüche zu interpretieren oder zu beschränken. Zusätzlich ist in der vorstehenden detaillierten Beschreibung zu sehen, dass verschiedene Merkmale in einem einzelnen Aspekt zusammengefasst sind, mit dem Zweck, die Offenbarung zu straffen. Dieses Verfahren der Offenbarung ist nicht so zu interpretieren, dass es die Absicht widerspiegelt, dass die beanspruchten Aspekte mehr Merkmale erfordern, als in jedem Anspruch ausdrücklich angegeben sind. Vielmehr liegt, wie die folgenden Ansprüche widerspiegeln, der erfindungsgemäße Gegenstand in weniger als allen Merkmalen eines einzelnen offenbarten Aspekts. Somit werden die folgenden Ansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch für sich als ein einzelner Aspekt steht.

Claims (25)

  1. Verarbeitungsschaltungsanordnung, die Folgendes umfasst: Verarbeitungsschaltung, wobei die Verarbeitungsschaltung mehrere Prozessorkerne umfasst, die mit einer Mittenbasisfrequenz arbeiten; und ein Speichergerät, das darauf verkörperte Anweisungen beinhaltet, wobei die Anweisungen, wenn durch die Verarbeitungsschaltung ausgeführt, die Verarbeitungsschaltung konfigurieren, Operationen auszuführen, um: als Reaktion auf eine Anforderung für eine Mehrfrequenzkernoperation einen ersten Satz der mehreren Prozessorkerne zu konfigurieren, um mit einer ersten modifizierten Basisfrequenz zu arbeiten, und einen zweiten Satz der mehreren Prozessorkerne zu konfigurieren, um mit einer zweiten modifizierten Basisfrequenz zu arbeiten; Konfigurationsinformationen für mehrere virtuelle Central-Processing-Units (CPU) einer virtuellen Maschine wieder abzurufen, wobei die mehreren virtuellen CPU eine Network-Function-Virtualization (NFV) -Instanz, die als virtueller Service in einem Zugangsnetzwerk instanziiert ist, ausführen; und Prozessorkerne von dem ersten Satz oder dem zweiten Satz als die mehreren virtuellen CPU zu pinnen, um die NFV-Instanz basierend auf den wieder abgerufenen Konfigurationsinformationen auszuführen.
  2. Verarbeitungsschaltungsanordnung nach Anspruch 1, wobei die erste modifizierte Basisfrequenz niedriger als die Mittenbasisfrequenz ist, und die zweite modifizierte Basisfrequenz höher als die Mittenbasisfrequenz ist.
  3. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-2, wobei die Konfigurationsinformationen eine Anzahl von virtuellen CPU der mehreren zum Ausführen der NFV-Instanz verwendeten virtuellen CPU und eine minimale Betriebsfrequenz für die Anzahl von virtuellen CPU beinhalten.
  4. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-3, wobei das Pinnen der Prozessorkerne dynamisch ausgeführt wird, um eine Anzahl von gepinnten Prozessorkernen von dem ersten Satz oder dem zweiten Satz basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks anzupassen.
  5. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-4, wobei das Pinnen der Prozessorkerne ferner darauf basiert, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über einem Nutzungsschwellenwert liegt.
  6. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 2-5, wobei die Verarbeitungsschaltung ferner Operationen ausführt, um: die Prozessorkerne von dem ersten Satz als die mehreren virtuellen CPU zu pinnen, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks unter einem Nutzungsschwellenwert liegt.
  7. Verarbeitungsschaltungsanordnung nach Anspruch 6, wobei die Verarbeitungsschaltung ferner Operationen ausführt, um: die Prozessorkerne von dem ersten Satz zu dem zweiten Satz als die mehreren virtuellen CPU neu zu pinnen, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über dem Nutzungsschwellenwert liegt.
  8. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-7, wobei das Pinnen der Prozessorkerne auf dem Netzwerkverkehr oder einer den virtuellen Service verwendenden Anzahl von UE basiert.
  9. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-8, wobei die virtuellen Services mindestens einen von Folgenden beinhalten: einen virtuellen Firewall-Service; einen virtuellen Router-Service; einen virtuellen Load-Balancer-Service; einen virtuellen Analyse-Service; einen virtuellen Steuerungs-Service; und einen virtuellen Management-Service.
  10. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-9, wobei die Verarbeitungsschaltung ferner Operationen ausführt, um: einen Untersatz des ersten Satzes und einen Untersatz des zweiten Satzes als die mehreren den virtuellen Service ausführenden virtuellen CPU zu pinnen, basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks.
  11. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-10, wobei mindestens einer des ersten Satzes von Prozessorkernen und mindestens einer des zweiten Satzes von Prozessorkernen während der Ausführung der NFV-Instanz hardwarebeschleunigt ist.
  12. Verarbeitungsschaltungsanordnung nach einem der Ansprüche 1-11, wobei der erste Satz und der zweite Satz der mehreren Prozessorkerne innerhalb von mindestens einem CPU-Socket zufällig verteilt sind, basierend auf einem CPU-Herstellungsprozess.
  13. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium, das Anweisungen beinhaltet, wobei die Anweisungen, wenn durch eine Verarbeitungsschaltung einer Service-Koordinierungsentität in einem Zugangsnetzwerk ausgeführt, die Verarbeitungsschaltung dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Konfigurieren eines ersten Satzes von mehreren Prozessorkernen der Verarbeitungsschaltung, um mit einer ersten modifizierten Basisfrequenz zu arbeiten, und eines zweiten Satzes der mehreren Prozessorkerne, um mit einer zweiten modifizierten Basisfrequenz zu arbeiten, als Reaktion auf eine Anforderung für eine Mehrfrequenzkernoperation; Wiederabrufen von Konfigurationsinformationen für mehrere virtuelle Central-Processing-Units (CPU) einer virtuellen Maschine, wobei die mehreren virtuellen CPU eine Network-Function-Virtualization (NFV) -Instanz, die als virtueller Service in dem Zugangsnetzwerk instanziiert ist, ausführen; und Pinnen von Prozessorkernen von dem ersten Satz oder dem zweiten Satz als die mehreren virtuellen CPU, um die NFV-Instanz basierend auf den wieder abgerufenen Konfigurationsinformationen auszuführen.
  14. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium nach Anspruch 13, wobei die erste modifizierte Basisfrequenz niedriger als die Mittenbasisfrequenz ist, und die zweite modifizierte Basisfrequenz höher als die Mittenbasisfrequenz ist.
  15. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium nach einem der Ansprüche 13-14, wobei die Konfigurationsinformationen eine Anzahl von virtuellen CPU der mehreren zum Ausführen der NFV-Instanz verwendeten virtuellen CPU und eine minimale Betriebsfrequenz für die Anzahl von virtuellen CPU beinhalten.
  16. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium nach einem der Ansprüche 13-15, wobei das Pinnen der Prozessorkerne dynamisch ausgeführt wird, um eine Anzahl von gepinnten Prozessorkernen von dem ersten Satz oder dem zweiten Satz basierend auf der Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks anzupassen.
  17. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium nach einem der Ansprüche 13-16, wobei das Pinnen der Prozessorkerne ferner darauf basiert, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über einem Nutzungsschwellenwert liegt.
  18. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium nach einem der Ansprüche 14-17, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Pinnen der Prozessorkerne von dem ersten Satz als die mehreren virtuellen CPU, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks unter einem Nutzungsschwellenwert liegt.
  19. Mindestens ein nicht flüchtiges maschinenlesbares Speicherungsmedium nach Anspruch 18, wobei die Anweisungen die Verarbeitungsschaltung ferner dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Neu-Pinnen der Prozessorkerne von dem ersten Satz zu dem zweiten Satz als die mehreren virtuellen CPU, basierend darauf, dass die Nutzung des virtuellen Services innerhalb des Zugangsnetzwerks über dem Nutzungsschwellenwert liegt.
  20. Multi-Access-Edge-Computing (MEC) -Gerät, das Folgendes umfasst: Telemetrieschaltung, die dazu ausgelegt ist, den Netzwerkverkehr zwischen dem MEC-Gerät und mehreren Benutzerausrüstungen (UE) innerhalb eines Kommunikationsnetzwerks von mehreren Kommunikationsnetzwerken zu überwachen; Verarbeitungsschaltung, wobei die Verarbeitungsschaltung mindestens einen ersten Satz und einen zweiten Satz von Prozessorkernen umfasst, die mit entsprechenden ersten und zweiten Basisfrequenzen arbeiten, wobei die erste Basisfrequenz niedriger als die zweite Basisfrequenz ist; und ein Speichergerät, das mit der Telemetrieschaltung und der Verarbeitungsschaltung gekoppelt ist, wobei das Speichergerät darauf verkörperte Anweisungen beinhaltet, wobei die Anweisungen, wenn durch die Verarbeitungsschaltung ausgeführt, die Verarbeitungsschaltung dazu auslegen, Operationen auszuführen, um: über die Telemetrieschaltung zu erkennen, dass eine Anzahl der UE, die über mindestens eine Network-Function-Virtualization (NFV) -Instanz mit dem MEC-Gerät in Kommunikation sind, über einem ersten Schwellenwert liegt; und als Reaktion darauf, dass die Anzahl der UE, die mit dem MEC-Gerät in Kommunikation sind, über dem ersten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs, der der mindestens einen NFV-Instanz zugeordnet ist, von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen.
  21. MEC-Gerät nach Anspruch 20, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: über die Telemetrieschaltung zu erkennen, dass die Anzahl der UE, die mit dem MEC-Gerät in Kommunikation sind, unter dem ersten Schwellenwert liegt; und als Reaktion darauf, dass die Anzahl der UE, die mit dem MEC-Gerät in Kommunikation sind, unter dem ersten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs, der der mindestens einen NFV-Instanz zugeordnet ist, von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen zu übertragen.
  22. MEC-Gerät nach einem der Ansprüche 20-21, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: über einen oder mehrere Telemetrieindikatoren, die durch die Telemetrieschaltung gemessen werden, zu erkennen, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät über einem zweiten Schwellenwert liegt; und als Reaktion darauf, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät über dem zweiten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs von dem ersten Satz von Prozessorkernen zu dem zweiten Satz von Prozessorkernen zu übertragen.
  23. MEC-Gerät nach Anspruch 22, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: über den einen oder die mehreren Telemetrieindikatoren, die durch die Telemetrieschaltung gemessen werden, zu erkennen, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät unter dem zweiten Schwellenwert liegt; und als Reaktion darauf, dass der Netzwerkverkehr zwischen den mehreren UE und dem MEC-Gerät unter dem zweiten Schwellenwert liegt, die Verarbeitung des Netzwerkverkehrs von dem zweiten Satz von Prozessorkernen zu dem ersten Satz von Prozessorkernen zu übertragen.
  24. MEC-Gerät nach einem der Ansprüche 20-23, wobei die mindestens eine NFV-Instanz mindestens eine Multi-Access-Edge-Computing (MEC) -Anwendung ist, die auf einer Virtualisierungsinfrastruktur des MEC-Geräts ausgeführt wird.
  25. MEC-Gerät nach Anspruch 24, wobei die Verarbeitungsschaltung ferner dazu ausgelegt ist: über die Telemetrieschaltung ein Prozessor-Burst-Ereignis zu erkennen, das dem Netzwerkverkehr der mindestens einen MEC-Anwendung zugeordnet ist; und als Reaktion auf das erkannte Prozessor-Burst-Ereignis die Verarbeitung des Netzwerkverkehrs der mindestens einen MEC-Anwendung zwischen dem ersten Satz von Prozessorkernen und dem zweiten Satz von Prozessorkernen zu übertragen.
DE102020202398.0A 2019-04-01 2020-02-25 Edge-server-cpu mit dynamischer deterministischer skalierung Pending DE102020202398A1 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201962827494P 2019-04-01 2019-04-01
US62/827,494 2019-04-01
US201962830946P 2019-04-08 2019-04-08
US62/830,946 2019-04-08
US16/678,888 US11650851B2 (en) 2019-04-01 2019-11-08 Edge server CPU with dynamic deterministic scaling
US16/678,888 2019-11-08

Publications (1)

Publication Number Publication Date
DE102020202398A1 true DE102020202398A1 (de) 2020-10-01

Family

ID=70279591

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020202398.0A Pending DE102020202398A1 (de) 2019-04-01 2020-02-25 Edge-server-cpu mit dynamischer deterministischer skalierung

Country Status (3)

Country Link
US (1) US11650851B2 (de)
CN (1) CN111800757A (de)
DE (1) DE102020202398A1 (de)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3735006B1 (de) * 2019-05-03 2023-04-05 Nokia Solutions and Networks Oy Effiziente berechnung von anwendungsdaten in einem mobilen kommunikationsnetzwerk
US10856360B1 (en) * 2019-05-23 2020-12-01 Verizon Patent And Licensing Inc. System and method for sharing multi-access edge computing resources in a wireless network
US11900139B2 (en) * 2019-11-04 2024-02-13 Vmware, Inc. Multisite service personalization hybrid workflow engine
US11743325B1 (en) * 2019-11-29 2023-08-29 Amazon Technologies, Inc. Centralized load balancing of resources in cloud edge locations embedded in telecommunications networks
US11546208B2 (en) * 2019-12-31 2023-01-03 Vmware, Inc. Multi-site hybrid networks across cloud environments
KR20210108791A (ko) * 2020-02-26 2021-09-03 삼성전자주식회사 가상화된 네트워크 기능을 실행하는 방법 및 장치
US11284297B2 (en) * 2020-04-06 2022-03-22 Cisco Technology, Inc. Secure creation of application containers for fifth generation cellular network slices
US11533217B2 (en) 2020-07-31 2022-12-20 Hewlett Packard Enterprise Development Lp Systems and methods for predictive assurance
US20220050938A1 (en) * 2020-08-12 2022-02-17 Microsoft Technology Licensing, Llc Predictive modeling for cloud capacity management
US11963036B2 (en) * 2020-08-18 2024-04-16 Intel Corporation Computing workload transport over control plane in next generation cellular networks
EP4187879A4 (de) * 2020-09-24 2023-11-22 Samsung Electronics Co., Ltd. Verfahren und vorrichtung zum offload von hardware an ein softwarepaket
US11509715B2 (en) * 2020-10-08 2022-11-22 Dell Products L.P. Proactive replication of software containers using geographic location affinity to predicted clusters in a distributed computing environment
US11609794B2 (en) * 2020-11-10 2023-03-21 Oracle International Corporation Techniques for modifying cluster computing environments
CN112711468B (zh) * 2020-12-21 2021-10-15 北京航空航天大学 基于区块链的雾计算网络资源监控和任务管理方法及系统
US20210224128A1 (en) * 2020-12-24 2021-07-22 Intel Corporation Technologies for managing workloads in processor cores
CN112732343B (zh) * 2020-12-31 2022-04-22 中国电子科技网络信息安全有限公司 一种堆叠设备中业务子母板卡加载的方法
US12001366B2 (en) * 2021-02-04 2024-06-04 Harman Becker Automotive Systems Gmbh Interchangeable computing nodes
US11956150B1 (en) * 2021-05-24 2024-04-09 T-Mobile Innovations Llc Programmable networking device for packet processing and security
WO2023141506A1 (en) * 2022-01-19 2023-07-27 Commscope Technologies Llc System and method of cloud based congestion control for virtualized base station
US20230262791A1 (en) * 2022-02-17 2023-08-17 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Method of Setting Up Connections Between Edge Sites in a 5G Communications Network
US11606691B1 (en) * 2022-02-25 2023-03-14 Palo Alto Networks, Inc. Context-based security over interfaces in O-RAN environments in mobile networks
US11950144B2 (en) 2022-02-25 2024-04-02 Palo Alto Networks, Inc. Context-based security over interfaces in NG-RAN environments in mobile networks
WO2023195074A1 (ja) 2022-04-05 2023-10-12 三菱電機株式会社 オーケストレータ装置、通信システム、アプリケーション配置決定方法、制御回路および記憶媒体
US11843537B2 (en) * 2022-04-14 2023-12-12 Dish Wireless L.L.C. Telecommunication service provider controlling an underlay network in cloud service provider environment
DE102022205834A1 (de) * 2022-06-08 2023-12-14 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Durchführen von Datenverarbeitungsaufgaben
CN115843113A (zh) * 2023-02-14 2023-03-24 阿里巴巴（中国）有限公司 数据处理方法、无线接入网络、设备及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4804490B2 (ja) * 2008-02-18 2011-11-02 富士通株式会社 情報処理装置、情報処理方法、情報処理プログラム
WO2013169249A1 (en) * 2012-05-09 2013-11-14 Intel Corporation Scheduling tasks among processor cores
WO2015099035A1 (ja) * 2013-12-27 2015-07-02 株式会社Ｎｔｔドコモ 管理システム、仮想通信機能管理ノード及び管理方法
CN103744716B (zh) * 2014-01-15 2016-09-07 上海交通大学 一种基于当前vcpu调度状态的动态中断均衡映射方法
US10949233B2 (en) * 2016-06-22 2021-03-16 Ciena Corporation Optimized virtual network function service chaining with hardware acceleration
US10579093B2 (en) * 2018-03-01 2020-03-03 At&T Intellectual Property I, L.P. Workload prediction based CPU frequency scaling
US11940859B2 (en) * 2018-11-16 2024-03-26 Hewlett Packard Enterprise Development Lp Adjusting power consumption limits for processors of a server

Also Published As

Publication number Publication date
CN111800757A (zh) 2020-10-20
US20200125389A1 (en) 2020-04-23
US11650851B2 (en) 2023-05-16

Similar Documents

Publication Publication Date Title
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
US11711267B2 (en) 5G network slicing with distributed ledger traceability and resource utilization inferencing
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
US11121957B2 (en) Dynamic quality of service in edge cloud architectures
DE112018005693T5 (de) Multi-access edge computing (mec)-basierte mehrbetreiberunterstützung für cellular vehicle-to-everything (c-v2x) systeme
DE102022200847A1 (de) Bestärkendes lernen für mehrfachzugriffsverkehrsverwaltung
DE102022202872A1 (de) Neuronales graphennetzwerk und bestärkendes-lernen-techniken zur verbindungsverwaltung
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
US20230062253A1 (en) 5g network edge and core service dimensioning
DE102019217367A1 (de) VERWALTUNG DER DIENSTQUALITÄT (QoS) IN EDGE-COMPUTING-UMGEBUNGEN
DE102020201015A1 (de) Technologien zum verteilen iterativer berechnungen in heterogenen computerumgebungen
DE112020003766T5 (de) Linkleistungsprognose und Medienstreaming-Technologien
DE112020007003T5 (de) Multi-funkzugangstechnologie-verkehrsverwaltung
DE102019105398A1 (de) Inter-mec-systemkommunikation für v2x-services
DE102022211605A1 (de) Zuverlässigkeitsverbesserungen für mehrfachzugangsverkehrsverwaltung
DE112019002913T5 (de) Verwaltung von zuweisungen bevorzugter kanäle zwischendrahtloskommunikationsbändern
DE102022202963A1 (de) Verkehrsaufteilungs- und neuübertragungsmechanismen mit schichtübergreifender und zugangsübergreifender technologie
DE112018007463T5 (de) Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning
DE112018006701T5 (de) Multihardware-beschleunigte inferenz auf der basis von dienstgütevereinbarungen
DE112017006515T5 (de) Adaptive netztopologie
DE102023200988A1 (de) Dynamische latenz-responsive cache-verwaltung
DE102021210882A1 (de) Erweitertes peer-to-peer (p2p) mit edge-vernetzung