DE112020007134T5 - Edge-computing in satellitenkonnektivitätsumgebungen - Google Patents

Edge-computing in satellitenkonnektivitätsumgebungen Download PDF

Info

Publication number
DE112020007134T5
DE112020007134T5 DE112020007134.0T DE112020007134T DE112020007134T5 DE 112020007134 T5 DE112020007134 T5 DE 112020007134T5 DE 112020007134 T DE112020007134 T DE 112020007134T DE 112020007134 T5 DE112020007134 T5 DE 112020007134T5
Authority
DE
Germany
Prior art keywords
satellite
network
data
procedure
computing
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
DE112020007134.0T
Other languages
English (en)
Inventor
Marcos E. Carranza
Cesar Martinez-Spessot
Thijs Metsch
Srikathyayani Srikanteswara
Timothy Verrall
Yi Zhang
Weiqiang Ma
Atul Kwatra
Stephen T. Palermo
Francesc Guim Bernat
Kshitij Arun Doshi
Ned M. Smith
Rita H. Wouhaybi
Neelam Chandwani
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 DE112020007134T5 publication Critical patent/DE112020007134T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/1851—Systems using a satellite or space-based relay
    • H04B7/18513—Transmission in a satellite or space-based system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/1851—Systems using a satellite or space-based relay
    • H04B7/18517—Transmission equipment in earth stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • 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/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • 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
    • 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/082—Load balancing or load distribution among bearers or channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248—Connectivity information update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/1851—Systems using a satellite or space-based relay
    • H04B7/18519—Operations control, administration or maintenance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/06—Airborne or Satellite Networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Radio Relay Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verschiedene Ansätze für die Integration und Verwendung von Edge-Computing-Operationen in Satellitenkommunikationsumgebungen werden hier erörtert. Zum Beispiel werden Konnektivitäts- und Rechenansätze unter Bezugnahme auf Folgendes besprochen: Identifizieren von Satellitenabdeckung und Rechenoperationen, die in Leo(Low-Orbit)-Satelliten verfügbar sind, Einrichten von Verbindungsströmen über LEO-Satellitennetzwerke, Identifizieren und Implementieren von Geofences für LEO-Satelliten, Koordinieren und Planen von Datentransfers über ephemere satellitenverbundene Vorrichtungen, Dienstorchestrierung über LEO-Satelliten basierend auf Datenkosten, Handover von Rechen- und Datenoperationen in LEO-Satellitennetzwerken und Managen der Paketverarbeitung unter anderen Aspekten.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht die Priorität: der vorläufigen US-Patentanmeldung Nr. 63/077,320 , eingereicht am 11. September 2020; der vorläufigen US-Patentanmeldung Nr. 63/129,355 , eingereicht am 22. Dezember 2020; der vorläufigen US-Patentanmeldung Nr. 63/124,520 , eingereicht am 11. Dezember 2020; der vorläufigen US-Patentanmeldung Nr. 63/104,344 , eingereicht am 22. Oktober 2020; der vorläufigen US-Patentanmeldung Nr. 63/065,302 , eingereicht am 13. August 2020; und der vorläufigen US-Patentanmeldung Nr. 63/018,844 , eingereicht am 1. Mai 2020; die alle vollumfänglich durch Bezugnahme hierin aufgenommen werden.
  • TECHNISCHES GEBIET
  • Vorliegend beschriebene Ausführungsformen betreffen allgemein Datenverarbeitung, Netzwerkkommunikationsszenarien und terrestrische und nicht-terrestrische Netzwerkinfrastruktur, die an satellitenbasierter Vernetzung beteiligt sind, beispielsweise unter Verwendung des Einsatzes von Satelliten im niedrigen Erdorbit.
  • Figurenliste
  • In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Zeichen mit unterschiedlichen Buchstabensuffixen können verschiedene Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen werden in den Figuren der begleitenden Zeichnungen beispielhaft und nicht einschränkend dargestellt, wobei gilt:
    • 1 veranschaulicht Netzwerkkonnektivität in nicht-terrestrischen (Satelliten-) und terrestrischen (z.B. Mobilzellennetzwerk-) Settings gemäß einem Beispiel;
    • 2 veranschaulicht terrestrische und nicht-terrestrische Edge-Konnektivitätsarchitekturen gemäß einem Beispiel;
    • 3 veranschaulicht mehrere Arten von Satellitenkommunikationsnetzen gemäß einem Beispiel;
    • 4A und 4B veranschaulichen mehrere Arten von Satellitenkommunikationsverarbeitungsarchitekturen gemäß einem Beispiel;
    • 5 veranschaulicht Einzelheiten terrestrischer Kommunikation und Architektur in einem geosynchronen Satellitenkommunikationsnetzwerk gemäß einem Beispiel;
    • 6A und 6B veranschaulichen Einzelheiten terrestrischer Kommunikation und Architektur in einem LEO- (low earth orbit, niedriger Erdorbit) Satellitenkommunikationsnetzwerk gemäß einem Beispiel;
    • 7A und 7B veranschaulichen ein Netzwerkkonnektivitätsökosystem, das ein LEO-Satellitenkommunikationsnetzwerk implementiert, gemäß einem Beispiel;
    • 8 veranschaulicht einen Überblick über terrestrisch basierte LEO-Satelliten-Edge-Verarbeitung gemäß einem Beispiel;
    • 9 veranschaulicht ein Szenario einer geografischen Satellitenkonnektivität von LEO-Satellitenkommunikationsnetzwerken gemäß einem Beispiel;
    • 10A, 10B und 10C veranschaulichen terrestrisch basierte LEO-Satelliten-Edge-Verarbeitungsanordnungen gemäß einem Beispiel;
    • 11A, 11B, 11C und 11D zeigen verschiedene Anordnungen einer Funkzugangsnetzverarbeitung über ein Satellitenkommunikationsnetzwerk gemäß einem Beispiel;
    • 12 veranschaulicht ein Flussdiagramm eines Verfahrens zum Erhalten von Satellitenfahrzeugpositionen gemäß einem Beispiel;
    • 13 veranschaulicht eine Edge-Computing-Netzwerkplattform, die über Satellitenkommunikationen erweitert wird, gemäß einem Beispiel;
    • 14A und 14B veranschaulichen eine Gerätekonfiguration eines Verbindermoduls, das zur Verwendung mit Satellitenkommunikationen angepasst ist, gemäß einem Beispiel;
    • 15 veranschaulicht ein Flussdiagramm eines Verfahrens zum Verwenden eines Satellitenverbinders zur Koordination mit Edge-Computing-Operationen gemäß einem Beispiel;
    • 16 veranschaulicht eine weitere Architektur eines Verbindermoduls, das zur Verwendung mit Satellitenkommunikationen angepasst ist, gemäß einem Beispiel;
    • 17 veranschaulicht eine weitere Architektur eines Verbindermoduls, das zur Verwendung mit Satellitenkommunikationen angepasst ist, gemäß einem Beispiel;
    • 18 veranschaulicht ein Flussdiagramm eines Verfahrens zum Verwenden eines Satellitenverbinders zur Koordination mit Edge-Computing-Operationen gemäß einem Beispiel;
    • 19 veranschaulicht eine weitere Architektur eines Verbindermoduls, das zur Verwendung mit Speicherungsoperationen angepasst ist, gemäß einem Beispiel;
    • 20A und 20B veranschaulichen eine Netzwerkplattform, die über Satellitenkommunikationen für Inhalts- und Geofencing-Operationen erweitert wird, gemäß einem Beispiel;
    • 21 veranschaulicht eine Gerätekonfiguration für Satellitenkommunikationen, die über Satellitenkommunikationen für Inhalts- und Geofencing-Operationen erweitert wird, gemäß einem Beispiel;
    • 22 veranschaulicht ein Flussdiagramm eines Verfahrens zum Verwenden eines Satellitenverbinders für Satellitenkommunikationen unter Verwendung von Geofencing-Operationen gemäß einem Beispiel;
    • 23 veranschaulicht ein System zur Koordination einer Satellitenroamingaktivität gemäß einem Beispiel;
    • 24 veranschaulicht eine Konfiguration einer Benutzer-Edge-Kontextdatenstruktur zum Koordinieren von Satellitenroamingaktivität gemäß einem Beispiel;
    • 25 veranschaulicht ein Flussdiagramm eines Verfahrens zum Verwenden eines Benutzer-Edge-Kontexts zum Koordinieren von Satelliten-Roaming-Aktivität gemäß einem Beispiel;
    • 26 veranschaulicht die Verwendung von Satellitenkommunikationen in einer IoT- (internet of things, Internet der Dinge) Umgebung gemäß einem Beispiel;
    • 27 veranschaulicht ein Flussdiagramm eines Verfahrens zum Sammeln und Verarbeiten von Daten mit einer IoT- und Satellitennetzwerkbereitstellung gemäß einem Beispiel;
    • 28 veranschaulicht ein beispielhaftes Satellitenkommunikationsszenario, das einen Plan für ephemere verbundene Vorrichtungen beinhaltet, gemäß einem Beispiel;
    • 29 veranschaulicht ein Flussdiagramm eines Verfahrens zum Koordinieren von Satellitenkommunikationen mit ephemeren verbundenen Vorrichtungen gemäß einem Beispiel;
    • 30 veranschaulicht ein Satellitenkommunikationsszenario, das Berücksichtigung von Datenkosten beinhaltet, gemäß einem Beispiel;
    • 31 veranschaulicht ein Satelliten- und Boden-Edge-Verarbeitungsframework, das für Datenkostenfunktionen angepasst ist, gemäß einem Beispiel;
    • 32 veranschaulicht ein Flussdiagramm eines Verfahrens zur Dienstorchestrierung basierend auf Datenkosten, gemäß einem Beispiel;
    • 33 veranschaulicht eine Konfiguration eines ICN- (information centric networking, informationszentrierte Vernetzung) Netzwerks gemäß einem Beispiel;
    • 34 veranschaulicht eine Konfiguration eines ICN-Netzwerkknotens, der NDN-(named data networking, auf benannten Daten beruhende Vernetzung) Methoden implementiert, gemäß einem Beispiel;
    • 35 veranschaulicht einen beispielhaften Einsatz von ICN- und NDN-Methoden unter Satellitenverbindungsknoten gemäß einem Beispiel;
    • 36 veranschaulicht ein Satellitenverbindungsszenario zur Verwendung eines NDN-Daten-Handovers gemäß einem Beispiel;
    • 37 veranschaulicht einen Satellitenverbindungsoperationsfluss zum Koordinieren von NDN-Datenoperationen gemäß einem Beispiel;
    • 38 veranschaulicht ein Flussdiagramm eines Verfahrens, das in einem Satellitenkonnektivitätssystem zum Handover von Rechen- und Datendiensten durchgeführt wird, um eine Dienstkontinuität aufrechtzuerhalten, gemäß einem Beispiel;
    • 39 veranschaulicht eine Erkennungs- und Routingstrategie, die in einem Satellitenkonnektivitätssystem durchgeführt wird, gemäß einem Beispiel;
    • 40 veranschaulicht ein Flussdiagramm eines beispielhaften Verfahrens, das in einem Satellitenkonnektivitätssystem durchgeführt wird, um Dienstkontinuität von Datendiensten aufrechtzuerhalten, gemäß einem Beispiel;
    • 41A und 41B veranschaulichen einen Überblick über terrestrische und Satellitenszenarien zur Paketverarbeitung gemäß einem Beispiel;
    • 42 und 43 veranschaulichen Paketverarbeitungsarchitekturen, die für Edge-Computing verwendet werden, gemäß einem Beispiel;
    • 44 und 45 veranschaulichen eine vorlagenbasierte Netzwerkpaketverarbeitung gemäß einem Beispiel;
    • 46 veranschaulicht die Verwendung einer Befehlsvorlage mit Netzwerkverarbeitung gemäß einem Beispiel;
    • 47 veranschaulicht ein Flussdiagramm eines beispielhaften Paketverarbeitungsverfahrens unter Verwendung von Befehlsvorlagen gemäß einem Beispiel;
    • 48 veranschaulicht eine Übersicht über eine Edge-Cloud-Konfiguration für Edge-Computing gemäß einem Beispiel;
    • 49 veranschaulicht eine Übersicht über Schichten verteilten Rechnens, die in einem Edge-Computing-System eingesetzt werden, gemäß einem Beispiel;
    • 50 veanschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen;
    • 51 veranschaulicht einen beispielhaften Ansatz für Vernetzung und Dienste in einem Edge-Computing-System;
    • 52A veranschaulicht eine Übersicht über Beispielkomponenten, die in einem Rechenknotensystem eingesetzt werden, gemäß einem Beispiel;
    • 52B veranschaulicht eine weitere Übersicht über Beispielkomponenten innerhalb einer Rechenvorrichtung gemäß einem Beispiel; und
    • 53 veranschaulicht eine Softwareverteilungsplattform zum Verteilen von Softwareanweisungen und Ableitungen, gemäß einem Beispiel.
  • ÜBERSICHT
  • Die folgende Offenbarung befasst sich mit verschiedenen Aspekten von Konnektivität und Edge-Computing, die in einem nicht-terrestrischen Netzwerk (z.B. LEO-(niedriger Erdorbit), MEO- (medium earth orbit, mittlerer Erdorbit) bzw. ICO- (intermediate circular orbit, mittlere Umlaufbahn) oder VLEO- (very low earth orbit, sehr niedriger Erdorbit) Satellitenkonstellationen) relevant sind. In verschiedenen Sätzen von Beispielen wird dies durch neue Ansätze für terrestrische und satellitenfähige Edge-Architekturen, Edge-Verbinder für Satellitenarchitekturen, Dienstgüteverwaltung für satellitenbasierte Edges, satellitenbasierte Geofencing-Schemata, Content-Caching-Architekturen, IoT- (Internet-der-Dinge-) Sensor- und Vorrichtungsarchitekturen, die mit satellitenbasierten Edge-Bereitstellungen verbunden sind, Orchestrierungsoperationen in satellitenbasierten Edge-Einsätzen sowie andere zugehörige Verbesserungen und Ausgestaltungen ermöglicht.
  • Eines der vorliegend adressierten technischen Probleme beinhaltet die Berücksichtigung von Edge-„Mehrfachzugriffs-“ (multi-access) Konnektivität, die die vielen Permutationen von Netzwerkkonnektivität beinhaltet, die unter Satelliten, drahtlosen Bodennetzwerken und UEs bereitgestellt werden (einschließlich für UEs, die über direkten Satellitennetzwerkzugang verfügen). Szenarien können zum Beispiel eine Koordination zwischen verschiedenen Arten verfügbarer Satelliten-UE-Verbindungen, sei es in Form von nicht-geostationären Satellitensystemen (non-geostationary satellite systems, NGSO), Mittelorbit- oder Mittelumlaufbahn- Satellitensystemen, geostationären Satellitensystemen (GEO), terrestrischen Netzwerken (z.B. 4G/5G-Netzwerken), und direktem UE-Zugriff unter Berücksichtigung von Ausbreitungsverzögerungen, Frequenzstörung, Ausschlusszonen, Satellitenstrahllanderechten und Fähigkeiten von Boden- (oder In-Orbit-) Routing-Protokollen sowie anderen Problemen beinhalten. Gleichermaßen beinhalten solche Szenarien zudem die Berücksichtigung von Mehrfachzugriffs-Satellitenkonnektivität beim Durchführen von Erkennung und Routing, einschließlich, wie Daten in Mehrfachzugriffs-Satellitenverbindungen basierend auf Service-Level-Zielen (service level objectives, SLOs), Sicherheit, Vorschriften und dergleichen zu routen sind.
  • Ein anderes vorliegend adressiertes technisches Problem beinhaltet eine Koordination zwischen Edge-Rechenfähigkeiten, die an nicht-terrestrischen (Satellitenfahrzeug) und terrestrischen (Basisstation, Kernnetz) Standorten angeboten werden. Aus einer einfachen Perspektive kann dies eine Bestimmung beinhalten, ob Rechenoperationen zum Beispiel am Boden, an Bord eines Satelliten oder an verbundenen Benutzergerätvorrichtungen, an einer Basisstation, in einer satellitenverbundenen Cloud oder einem Kernnetz oder an entfernten Orten durchgeführt werden sollten. Rechenoperationen können vom Einrichten der gesamten Netzwerkroutingpfade unter terrestrischen und nicht-terrestrischen Netzwerkknoten (an denen fast jeder Knoten in der Netzwerkinfrastruktur beteiligt ist) bis zum Durchführen einzelner Edge- oder Knotenaktualisierungen (an denen nur ein Knoten oder Satellit beteiligt sein kann) reichen.
  • Um diese Bestimmung durchzuführen, kann ein System evaluieren, welche Art von Operation durchgeführt werden soll und wo die Rechenoperationen durchgeführt werden sollen oder Daten bezogen werden sollen, und zwar unter Berücksichtigung von intermittierender oder unterbrochener Satellitenkonnektivität, Bewegung und variablen Strahl-Footprints (Ausleuchtzonen) einzelner Satellitenfahrzeuge und der Satellitenkonstellation, Satelliteninterferenz- oder Ausschlussbereichen, begrenztem Übertragungsdurchsatz, Latenz, Kosten, gesetzlichen oder geografischen Einschränkungen, Service-Level-Agreement- (SLA-) Anforderungen, Sicherheit und anderen Faktoren. Vorliegend kann eine Bezugnahme auf eine „Ausschlusszone“ oder einen „Ausschlussbereich“ Beschränkungen für Satellitenrundsendung oder -Nutzung beinhalten, wie beispielsweise in Standards definiert, die von der Alliance for Telecommunications Industry Solutions (ATIS) oder anderen Standardisierungsorganisationen oder Jurisdiktionen veröffentlicht sind.
  • Ein vorliegend adressiertes technisches Problem beinhaltet Orchestrierung und Dienstgüte für Satellitenverbindungen und Edge-Rechenoperationen, die über solche Satellitenverbindungen angeboten werden. Insbesondere können Dienste basierend auf der Latenz, Durchsatzfähigkeiten und -anforderungen, der Art von Daten und Kostenerwägungen für Satellitenverbindungen orchestriert und auf Zuverlässigkeit garantiert werden, während unterschiedliche Überlegungen und Prioritäten angewendet werden, die für Cloud-Dienstanbieter (die Best-Effort-Dienste bereitstellen) gegenüber Telekommunikationsunternehmen/Kommunikationsdienstanbietern (die garantierte Dienste bereitstellen) anwendbar sind. Die Bewertung solcher Faktoren kann Überlegungen zu Risiken, Verwendungsfällen für einen verfügbaren Dienst, Verwendungsfällen für Satellitennetzwerke als „Bent Pipe“-Konnektivität, Bedingungen oder Beschränkungen darüber, wie und wann Daten abgerufen und verarbeitet werden können, unterschiedlichen Arten von Backhaul, die über Satellitendatenkommunikationen verfügbar sind, sowie zu weiteren Aspekten hinsichtlich Gebühren, Datenschutz und Sicherheit beinhalten, die bei Satellitendatenkommunikationen über mehrere Jurisdiktionen hinweg auftreten.
  • Ein anderes vorliegend adressiertes technisches Problem betrifft die Anpassung von Edge-Rechen- und Datendiensten in Satellitenkonnektivitätsumgebungen. Ein Aspekt hiervon beinhaltet die Implementierung von SDN- (software defined network, softwaredefiniertes Netzwerk) und vRAN- (virtual radio access network) Konzepten einschließlich terrestrischer und nicht-terrestrischer Netzwerkknoten, die mit im Orbit befindlichen Satellitenkonstellationen verbunden sind. Ein anderer Aspekt besteht darin, wie eine Datenverarbeitung mit IoT-Architekturen einschließlich Sensoren zu koordinieren ist, die Umgebungstelemetrie innerhalb terrestrischer Grenzen (z.B. Schiffscontainer, Drohnen) mit intermittierender Konnektivität (z.B. letzter bekannter Status, Verbindungen über Drohnen an entfernten Standorten usw.) überwachen. Weitere Aspekte in Bezug auf Content Data Networking (CDN), Geofencing und geografische Einschränkungen, Dienstorchestrierung, Konnektivität und Daten-Handover, Kommunikationspfade und Routing sowie Sicherheits- und Datenschutzerwägungen werden ebenfalls in verschiedenen Verwendungsfällen adressiert.
  • In verschiedenen Sätzen von Beispielen werden Satellitenkonnektivität und - koordination durch neue Ansätze für terrestrische und satellitenfähige Edge-Architekturen bereitgestellt, einschließlich der Verwendung von „Edge-Verbindern“ und Verbindungslogik innerhalb eines Rechensystems. Solche Edge-Verbinder werden verwendet, um Kommunikationsströme über ein Satellitennetzwerk zu erstellen und zu organisieren und trotz der intermittierenden und unvorhersehbaren Natur von LEO-Satellitennetzwerkverbindungen virtuelle Kanäle zu Edge-Computing- oder entfernten Dienststandorten einzurichten.
  • In weiteren Beispielen werden Satellitenkonnektivität und -koordination durch Dienstgüte- und Orchestrierungsverwaltungsoperationen in satellitenbasierten oder satellitengestützten Edge-Computing-Bereitstellungen bereitgestellt. Solche Verwaltungsoperationen können die variierenden Latenztypen, die für Netzwerk-Backhaul über ein Satellitennetzwerk benötigt werden, und die variierenden Bedingungen hinsichtlich Überlastung und Ressourcennutzung berücksichtigen. Diese Verwaltungsoperationen können eine effektive Vereinigung von bodenbasierten und satellitenbasierten Edge-Computing-Operationen und allen Ressourceneigenschaften ermöglichen, die mit einem relevanten Netzwerk oder Rechendienst assoziiert sind.
  • In weiteren Beispielen werden Konnektivität und Arbeitslastkoordination für satellitenbasierte Edge-Computing-Knoten und terrestrische Edge-Computing-Knoten bereitgestellt, die Inhalte an Endbenutzer liefern (wie etwa von einem Content Delivery Network (CDN)). Diese Konnektivitäts- und Arbeitslastkoordination kann Content-Caching-Architekturen verwenden, die für Satellitenkommunikationen angepasst sind, um Latenz zu verringern und eine Effizienz des Inhaltsabrufs und der Inhaltslieferung zu erhöhen. Eine solche Konnektivitäts- und Arbeitslastkoordination kann zudem satellitenbasierte Geofencing-Schemata verwenden, um die Einhaltung von Inhaltsanbieter- oder geopolitischen Regelungen und Anforderungen (häufig basierend auf geografischen Bereichen definiert) sicherzustellen.
  • In weiteren Beispielen werden Aspekte des Koordinierens von Satellitenkonnektivität und Edge-Computing-Operationen durch ein Handover-System für Rechen- und Datendienste bereitgestellt, wodurch der Übergang von Dienstdaten und Diensten innerhalb von Satellitenfahrzeugen bereitgestellt wird. Dieses Handover-System ermöglicht Dienstkontinuität und -koordination innerhalb einer Vielfalt von Satellitenkommunikationseinstellungen.
  • Zusätzlich werden in weiteren Beispielen verschiedene Aspekte des Erkennens und Routings zwischen Satelliten- und terrestrischen Links implementiert. Bei der Verwendung einer namensbasierten Adressierung in einer NDN- (named data network) Umgebung kann ein Satellitenkonnektivitätssystem dazu konfiguriert sein, Arbeitslastfunktionen durchzuführen, Daten abzurufen und von Knoten zu Knoten Handoff durchzuführen. Dieses Satellitenkonnektivitätssystem kann dazu konfiguriert sein, Erkennung durchzuführen sowie den besten Knoten/Pfad zum Durchführen des Dienstes (Routing und Weiterleiten) auszuwählen.
  • Übersicht über Satellitenkonnektivität
  • 1 veranschaulicht Netzwerkkonnektivität in nicht-terrestrischen (Satelliten-) und terrestrischen (z.B. Mobilzellennetzwerk-) Settings gemäß einem Beispiel. Wie gezeigt, kann eine Satellitenkonstellation 100 (die in 1 an Orbitalpositionen 100A und 100B gezeigte Konstellation) mehrere Satellitenfahrzeuge (SVs) 101, 102 beinhalten, die miteinander und mit einem oder mehreren terrestrischen Netzwerken verbunden sind. Die einzelnen Satelliten in der Konstellation 100 (jeweils ein SV) umlaufen orbital die Erde mit einer Orbitgeschwindigkeit, die mit Annäherung des SV an die Erde zunimmt. LEO-Konstellationen werden beinhalten allgemein SVs, die in einer Höhe zwischen 160 und 1000 km kreisen, in dieser Höhe umkreist jedes SV die Erde etwa alle 90 bis 120 Minuten.
  • Die Konstellation 100 beinhaltet einzelne SVs 101, 102 (und zahlreiche andere nicht gezeigte SVs) und verwendet mehrere SVs, um eine Kommunikationsabdeckung für ein geografisches Gebiet auf der Erde bereitzustellen. Die Konstellation 100 kann sich zudem mit anderen (nicht gezeigten) Satellitenkonstellationen und mit terrestrischen Netzwerken koordinieren, um selektiv Konnektivität und Dienste für einzelne Vorrichtungen (Benutzergeräte) oder terrestrische Netzwerksysteme (Netzwerkausrüstung) bereitzustellen.
  • In diesem Beispiel ist die Satellitenkonstellation 100 über einen Satelliten-Link 170 mit einem Backhaul-Netzwerk 160 verbunden, das wiederum mit einem 5G-Kernnetz 140 verbunden ist. Das SG-Kernnetz 140 wird verwendet, um 5G-Kommunikationsoperationen mit dem Satellitennetzwerk und an einem terrestrischen 5G-Funkzugangsnetz (RAN) 130 zu unterstützen. Das SG-Kernnetz 140 kann sich zum Beispiel an einem entfernten Ort befinden und die Satellitenkonstellation 100 als den exklusiven Mechanismus verwenden, um Weitbereichsnetze und das Internet zu erreichen. In anderen Szenarien kann das SG-Kernnetz 140 die Satellitenkonstellation 100 als einen redundanten Link verwenden, um auf die Weitverkehrsnetze und das Internet zuzugreifen. In weiteren Szenarien kann das SG-Kernnetz 140 die Satellitenkonstellation 100 als einen alternativen Pfad verwenden, um auf die Weitverkehrsnetze und das Internet zuzugreifen (z.B. um mit Netzwerken auf anderen Kontinenten zu kommunizieren).
  • 1 stellt zudem die Verwendung des terrestrischen 5G-RAN 130 dar, um einem Benutzergerät (UE), wie etwa einer Benutzervorrichtung 120 oder einem Fahrzeug 125 am Boden, über eine Massive-MIMO-Antenne 150 Funkkonnektivität bereitzustellen. Es versteht sich, dass eine Vielfalt von 5G- und anderen Netzwerkkommunikationskomponenten und - einheiten in 1 der Einfachheit halber nicht dargestellt sind. In einigen Beispielen kann jedes UE 120 oder 125 zudem eine eigene Satellitenkonnektivitätshardware (z.B. Empfängerschaltungsanordnung und Antenne) aufweisen, um sich über den Satelliten-Link 180 direkt mit der Satellitenkonstellation 100 zu verbinden. Wenngleich ein SG-Netzwerk-Aufbau in den folgenden Abschnitten ausführlich dargestellt und besprochen ist, versteht es sich, dass auch andere Variationen von 3GPP, O-RAN und anderen Netzwerkspezifikationen anwendbar sein können.
  • Andere Permutationen (nicht gezeigt) können eine direkte Verbindung des 5G-RAN 130 zu der Satellitenkonstellation 100 (z.B. mit dem 5G Kernnetz 140, auf das über einen Satelliten-Link zugegriffen werden kann); Koordination mit anderen drahtgebundenen (z.B. Faser), Laser- oder optischen und drahtlosen Links und Backhaul; Mehrfachzugriffsfunk zwischen dem UE, dem RAN und anderen UEs, und andere Permutationen terrestrischer und nicht-terrestrischer Konnektivität beinhalten. Satellitennetzwerkverbindungen können mit 5G-Netzwerkausrüstung und Benutzergeräten basierend auf Satellitenorbitabdeckung, verfügbaren Netzwerkdiensten und -ausrüstung, Kosten und Sicherheit und geografischen oder geopolitischen Erwägungen und dergleichen koordiniert werden. Unter Berücksichtigung dieser Grundentitäten und bei den sich ändernden Zusammensetzungen von Mobilbenutzern und In-Orbit-Satelliten beschreiben die folgenden Methoden Wege, auf denen terrestrische und Satellitennetzwerke für verschiedene Edge-Computing-Szenarien erweitert werden können.
  • 2 veranschaulicht terrestrische und nicht-terrestrische Edge-Konnektivitätsarchitekturen, die mit den vorliegenden Methoden erweitert sind. Edge-Cloud-Computing hat sich bereits als eine der nächsten Entwicklungen im Zusammenhang mit verteiltem Rechnen und einer Demokratisierung von Datenverarbeitung etabliert. Aktuelle Edge-Bereitstellungen beinhalten typischerweise einen Satz von Vorrichtungen 210 oder Benutzern, die mit Zugriffsdatenpunkten 220A (Basisstationen, Kleinzellen, drahtlose oder drahtgebundene Konnektivität) verbunden sind, die Zugriff auf einen Satz von Diensten (lokal auf den Zugangspunkten oder anderen Aggregationspunkten gehostet) über verschiedene Arten von Netzwerkfunktionen 230A (z.B. Virtual Evolved Packet Cores (vEPCs), User Plane Function (UPF, Benutzerebenenfunktion), virtual Broadband Network Gateway (vBNG), Control Plane and User Plane Separation (CUPS, Trennung von Steuer- und Benutzerebene), Multiprotocol Label Switching (MPLS), Ethernet usw.) bereitstellen.
  • Eine der Einschränkungen, die bei aktuellen Edge-Rechenarchitekturen auftreten, besteht jedoch darin, dass diese Architekturen auf die Netzwerkinfrastruktur angewiesen sind, die Kommunikationsdienstanbietern oder neutralen Trägern gehört. Falls ein bestimmter Anbieter daher einen neuen Dienst an einem bestimmten Standort bereitstellen will, muss er sich mit Betreibern abstimmen, um die erforderliche Konnektivität zu dem Standort bereitzustellen, an dem der Dienst gehostet wird (Dienstanbieter, der dem Kommunikationsdienstanbieter gehört oder von diesem bereitgestellt wird). Andererseits ist in vielen Fällen, wie etwa ländlichen Umgebungen oder Schwellenländern, eine Infrastruktur noch nicht eingerichtet. Zur Überwindung dieser Einschränkung blicken verschiedene Unternehmen (Tier-1 und darüber hinaus) auf die Satellitenkonnektivität, um diese Einschränkungen zu beseitigen.
  • Mehrere Konstellationen von Satelliten, die als unterschiedliche Organisationen fungieren, weisen einen erheblichen Bedarf auf, zusammenzuarbeiten, Ressourcen gemeinsam zu nutzen und Merkmale wie geografische Ausschlusszonen, Dienstgüte (QoS) und Lieferung von Inhalten und Diensten mit niedriger Latenz anzubieten. In diesem Zusammenhang stellen Zuverlässigkeit, QoS, Ressourcenteilung und Einschränkungen wie etwa Ausschlusszonen signifikante wechselseitige Anliegen dar, die von den folgenden Edge-Computing-Architekturen und Verarbeitungsansätzen adressiert werden.
  • In der Architektur von 2 sind Vorrichtungen 210 mit einem neuen Typ von Edge-Standort an einer Basisstation 220B verbunden, der Zugriffsfähigkeiten (wie etwa Funkantennennetzwerk), Netzwerkfunktionen (z.B. vEPC mit CUPS/UPF usw.) und eine erste Stufe von Edge-Diensten (wie etwa ein Content Delivery Network (CDN)) implementiert. Derartige Dienste erforderten herkömmlicherweise eine Konnektivität mit der Cloud 240A oder dem Kern des Netzwerks. Hier können in einem Satellitenkonnektivitäts-Setting derartige Inhalts- und Rechenoperationen an einer Basisstation 220B koordiniert werden, die RAN und verteilte Funktionen und Dienste anbietet. Die Basisstation 220B kann im Gegenzug Inhalte beziehen oder Verarbeitung an eine Cloud 240B oder einen anderen Dienst über Backhaul-Konnektivität 230B über Satellitenkommunikation auslagern (zum Beispiel in einem Szenario, in dem ein CDN, das sich an der Basisstation 220B befindet, nicht gecachten Inhalt beziehen muss). RAN-Funktionen können weiter in drahtlose und drahtgebundene Verarbeitung unterteilt werden, wie etwa RAN-Distributed-Unit- (DU-), L1/L2-, Verarbeitung und RAN-Centralized-Unit- (CU-), L3-, und höhere Verarbeitung.
  • Eine der Hauptherausforderungen jeder Art von Edge-Rechenarchitektur besteht darin, wie die höheren Latenzen überwunden werden können, die auftreten, wenn Dienste Konnektivität mit dem Backhaul des Netzwerks erfordern. Dieses Problem wird noch verschärft, wenn es mehrere Typen von Backhaul-Verbindungen (zum Beispiel zu unterschiedlichen Datenzentren in der Cloud 240B) mit unterschiedlichen Überlastungseigenschaften oder -niveaus gibt. Diese und andere Arten komplexer Szenarien werden unter den folgenden Operationen adressiert.
  • 3 veranschaulicht mehrere Arten von Satellitenkommunikationsnetzwerken. Hier sind mehrere Arten von Backhaul-Optionen veranschaulicht, darunter ein GEO-(geosynchrones) Satellitennetzwerk 301 (nachstehend unter Bezugnahme auf 4 behandelt), ein LEO- (Niedrigorbit-) Satellitennetzwerk 302 (nachstehend unter Bezugnahme auf 6A behandelt) und ein LEO-SG- (Niedrigorbit-5G-) Satellitennetzwerk 303 (nachstehend unter Bezugnahme auf 6B behandelt). In jedem dieser Fälle verwendet ein entfernter Edge-RAN-Zugangspunkt 311, der mit einem SG-Kernnetz verbunden ist, eines oder mehrere der Satellitennetzwerke 301, 302, 303, um Backhaul-Konnektivität an ein größeres Kommunikationsnetzwerk (z.B. das Internet) bereitzustellen. Die Verwendung von Satelliten-Backhaul kann zusätzlich zu anderen Arten von drahtgebundenem oder drahtlosem Backhaul erfolgen, einschließlich terrestrischem Backhaul zu anderen 5G-RAN-Drahtlosnetzwerken (z.B. Peer-to-Peer zum Drahtlosnetzwerk 304) oder Steuerinformationen, die über ein TTAC- (telemetry tracking and control, Telemetrieverfolgung und -steuerung) Netzwerk 305 kommuniziert oder bezogen werden. Das TTAC-Netzwerk 305 kann zum Beispiel für Betriebs- und Wartungsverkehr verwendet werden, wobei ein separater Link für Systemsteuerungs-Backhaul (zum Beispiel auf einem separaten Satellitenkommunikationsband) verwendet wird.
  • Am Zugangspunkt 311 können verschiedene Edge-Computing-Dienste 312 basierend auf einer Edge-Computing-Architektur 320 bereitgestellt werden, wie etwa jener, die in einem Server oder Rechenknoten enthalten ist. Diese Edge-Computing-Architektur 320 kann Folgendes beinhalten: UPF/vRAN-Funktionen; einen oder mehrere Edge-Server, die dazu konfiguriert sind, CDN, Dienste, Anwendungen und andere Verwendungsfälle bereitzustellen; und einen Satellitenverbinder (der in der Edge-Computing-Architektur 320 gehostet wird). Diese Architektur 320 kann durch eine Hochgeschwindigkeits-Switching-Fabric verbunden sein. Zusätzliche Einzelheiten zur Verwendung eines Satellitenverbinders und zur Koordination von Edge-Rechen- und Konnektivitätsoperationen für Satelliten-Settings werden nachstehend erörtert.
  • 4A und 4B veranschaulichen weitere Beispiele der Edge-Computing-Architektur 320. Zum Beispiel kann ein beispielhafter Edge-Server 322, der zu LTE/SG-Vernetzung in der Lage ist, verschiedene Kombinationen von FPGAs, nichtflüchtiger (nonvolatile memory, NVM) Speicherung, Prozessoren, GPUs und spezialisierten Verarbeitungseinheiten, Speicherung und Satellitenkommunikationsschalttechnik beinhalten. Ein beispielhafter Edge-Server 324, der in der Lage ist, Anwendungen zu betreiben, kann Rechenschalttechnik für künstliche Intelligenz (KI), NVM-Speicherung, Prozessoren und Speicherung beinhalten. Gleichermaßen sind die Dienste, die auf solchen Servern bereitgestellt werden, in 4B mit einem ersten Dienststapel 332 (der z.B. auf dem Edge-Server 322 arbeitet) und einem zweiten Dienststapel 334 (der z.B. auf dem Edge-Server 324 arbeitet) abgebildet. Verschiedene Anwendungsfälle (z.B. Banken, IoT, CDN) sind ebenfalls veranschaulicht, aber die Verwendungen der Architekturen sind nicht hierauf beschränkt.
  • 5 veranschaulicht Einzelheiten terrestrischer Kommunikation und Architektur in einem geosynchronen Satellitenkommunikationsnetzwerk. Hier verwendet eine beispielhafte IoT-Vorrichtung 511 eine 5G/LTE-Verbindung mit einem terrestrischen RAN 512, das ein Edge-Gerät 513 (zum Beispiel für anfängliche Edge-Computing-Verarbeitung) hostet. Das RAN 512 und das Edge-Gerät 513 sind unter Verwendung eines Satelliten-Links über eine vSAT- (very-small-aperture terminal, Endgerät mit sehr kleiner Strahleröffnung) Antenne mit einem geosynchronen Satelliten 501 verbunden. Der geosynchrone Satellit 501 kann zudem direkte Konnektivität zu anderen satellitenverbundenen Vorrichtungen, wie etwa der Vorrichtung 514, bereitstellen. Die Verwendung vorhandener 5G- und geosynchroner Satellitentechnologie macht diese Lösung bereits heute leicht einsetzbar.
  • In einem Beispiel wird 5G-Konnektivität in dem geosynchronen Satellitenkommunikationsszenario unter Verwendung einer verteilten UPF (z.B. über den Satelliten verbunden) oder eines eigenständigen Kerns (der sich z.B. an einem satellitenverbundenen Hub/einer Basisstation 515 befindet) oder direkt am Edge-Gerät 513 bereitgestellt. In jedem Fall kann Edge-Rechenverarbeitung durchgeführt und unter dem Edge-Gerät 513, der Bodenstation 515 oder einem verbundenen Datenzentrum 516 verteilt werden.
  • 6A und 6B veranschaulichen Einzelheiten der terrestrischen Kommunikation und der Architektur in einem Satellitenkommunikationsnetzwerk mit geringem Erdorbit, das durch die SVs 602A, 602B in der Konstellation 602 bereitgestellt wird. Diese Zeichnungen stellen ähnliche Vorrichtungen und Edge-Systeme wie 5 dar, mit einer IoT-Vorrichtung 611, einem Edge-Gerät 613 und einer Vorrichtung 614. Jedoch ermöglicht die Bereitstellung eines 5G-RAN von den SVs 602A, 602B und die erheblich reduzierte Latenz von Satelliten mit geringem Erdorbit viel robustere Verwendungsfälle, einschließlich der direkten Verbindung von Vorrichtungen (Vorrichtung 614) unter Verwendung von 5G-Satellitenantennen an der Vorrichtung 614 und Kommunikation zwischen dem Edge-Gerät 613 und der Satellitenkonstellation 602 unter Verwendung proprietärer Protokolle.
  • Als ein Beispiel kann in einigen LEO-Settings ein SG-LEO-Satellit alle 12 Stunden für 8 Minuten einen Radius von 500 km abdecken. Die Konnektivitätslatenz zu LEO-Satelliten kann nur eine Millisekunde betragen. Ferner hängt die Konnektivität zwischen der Satellitenkonstellation und der Vorrichtung 614 oder der Basisstation 612 von der Anzahl und den Fähigkeiten von Satellitenbodenstationen ab. In diesem Beispiel kommuniziert der Satellit 601 mit einer Bodenstation 618, die Edge-Computing-Verarbeitungsfähigkeiten hosten kann. Die Bodenstation 618 kann wiederum mit einem Datenzentrum 616 für weitere Verarbeitung verbunden sein. Mit der niedrigen Latenz, die durch 5G-Kommunikationen angeboten wird, können sich Datenverarbeitung, Berechnung und Speicherung an einer beliebigen Anzahl von Orten (an der Edge, im Satelliten, am Boden, im Kernnetz, in einem Datenzentrum mit niedriger Latenz) befinden.
  • 6B beinhaltet ein hinzugefügtes Edge-Gerät 603, das sich am SV 602A befindet. Hier können einige der Edge-Rechenoperationen direkt unter Verwendung von Hardware durchgeführt werden, die sich am SV befindet, wodurch die Latenz und Übertragungszeit reduziert werden, die ansonsten benötigt worden wären, um mit der Bodenstation 618 oder dem Datenzentrum 616 zu kommunizieren. Gleichermaßen kann in diesen Szenarien Edge-Berechnung unter spezialisierten Verarbeitungsschaltungsanordnungen (z.B. FPGAs) oder Allzweck-Verarbeitungsschaltungsanordnungen (z.B. x86-CPUs) implementiert oder koordiniert werden, die sich an dem Satelliten 601, der Bodenstation 618, den Vorrichtungen 614, die mit dem Edge-Gerät 613 verbunden sind, dem Edge-Gerät 613 selbst und Kombinationen aus diesen befinden.
  • Wenngleich dies in 6A und 6B nicht gezeigt ist, können andere Arten von orbitbasierter Konnektivität und Edge-Computing an diesen Architekturen beteiligt sein. Diese umfassen Konnektivität und Berechnung, die über Ballone, Drohnen, Luftschiffe und ähnliche Typen von nicht-terrestrischen Elementen bereitgestellt werden. Derartige Systeme stehen ähnlichen zeitlichen Einschränkungen und Konnektivitätsherausforderungen (wie etwa jenen, die in einem Satellitenorbit auftreten) gegenüber.
  • 7A veranschaulicht ein Netzwerkkonnektivitäts-Ökosystem, das ein Satellitenkommunikationsnetzwerk implementiert. Hier stellt ein Satellit 701, Teil der Satellitenkonstellation 700A, Abdeckung an ein „netzfernes“ (off-grid) drahtloses Netzwerk 720 (wie etwa einem geographisch isolierten Netzwerk ohne drahtgebundenen Backhaul) bereit. Dieses drahtlose Netzwerk 720 stellt wiederum Abdeckung für ein einzelnes Benutzergerät 710 bereit. Über die Satellitenverbindung kann eine Vielfalt anderer Verbindungen zu breiteren Netzwerken und Diensten hergestellt werden. Diese Verbindungen beinhalten eine Verbindung mit einem Träger 740 oder zu einem Cloud-Dienst 750 über eine Satellitenbodenstation 730. Am Cloud-Dienst 750 kann eine Vielfalt öffentlicher oder privater Dienste 760 gehostet werden. Zusätzlich können diese Dienste mit dem Einsatz von Edge-Computing-Architekturen basierend auf Koordination von Operationen im Netzwerk 720, der Satellitenkonstellation 700, der Bodenstation 730 oder dem Träger 740 viel näher an das Benutzergerät 710 verschoben werden.
  • 7B veranschaulicht ferner ein Netzwerkkonnektivitäts-Ökosystem, bei dem ein Satellit 702, Teil der Satellitenkonstellation 700B, unter Verwendung von 5G-Netzwerkkommunikationen Hochgeschwindigkeitskonnektivität (z.B. nahe 1ms einfache Latenz) bereitstellt. Eine solche Hochgeschwindigkeitskonnektivität ermöglicht Satellitenkonnektivität an mehreren Standorten 770, für mehrere Benutzer 780 und mehrere Arten von Vorrichtungen 790. Solche Konfigurationen sind besonders nützlich für die Verbindung von IoT-Industrievorrichtungen, Mobilitätsvorrichtungen (wie etwa Robotaxis, autonome Fahrzeuge) und das Gesamtkonzept des Anbietens von Konnektivität für „jedermann“ und „alles“.
  • Satellitennetzwerkabdeckung und -Abdeckungsidentifikation
  • Eine der allgemeinen Herausforderungen in Satellitenarchitekturen besteht darin, wie und wo die Berechnung einzusetzen ist, und allen erforderlichen Änderungen in der Gesamtarchitektur. Die vorliegenden Ansätze adressieren viele Aspekte darüber, wo die Berechnung platziert werden kann und wie satellitenbasierte Technologien mit Edge-Computing auf eine einzigartige Weise kombiniert und zusammengeführt werden können. Hierbei besteht das Ziel darin, das Potential von „Überall“-Berechnung (ob von der Vorrichtung, der Edge, dem Satelliten, der Bodenstation) zu nutzen.
  • Die Platzierung und Koordination von Edge-Computings mit Satelliten wird aufgrund der Tatsache, dass Satelliten zunehmend in Konstellationen im Orbit kreisen, viel komplexer. Das führt zu zwei signifikanten Herausforderungen: Erstens wird in Abhängigkeit von der Höhe und der Dichte einer Konstellation die Zeit, für die ein Edge-Ort abgedeckt wird, variieren. Ebenso können sich Latenz und Bandbreite im Zeitverlauf ändern. Zweitens werden sich Satelliten enthaltende Rechenknoten selbst im Orbit befinden und sich bewegen. Die Verwendung eines in Bewegung befindlichen Edge-Computing-Standorts, auf den von einem geografischen Standort nur zu unterschiedlichen Zeiten zugegriffen werden kann, muss in Betracht gezogen werden.
  • 8 veranschaulicht ein beispielhaftes vereinfachtes Szenario einer geografischen Satellitenkonnektivität von mehreren LEO-Satellitenkommunikationsnetzwerken, das die Bewegung der relevanten LEO-SVs relativ zu geografischen Bereichen abbildet. Hier arbeiten die Orbits 811, 812 jeweiliger Satellitenkonstellationen, um eine Netzwerkabdeckung in begrenzten geografischen Bereichen 821, 822 bereitzustellen. Im Gegensatz dazu ist im Bereich 831 kein Zugang bereitgestellt. Es versteht sich, dass die geografischen Positionen relevanter Satellitenabdeckungsbereiche eine wichtige Rolle bei der Bestimmung von Dienstcharakteristiken, Ausschlusszonen und Koordination der Satelliten-Bodenverarbeitung spielen können.
  • 9 veranschaulicht einen Überblick über terrestrische, satellitenfähige Edge-Verarbeitung. Wie gezeigt, bezieht eine terrestrische satellitenfähige EDGE-Bodenstation (Satelliten-NodeB, sNB) 920 Abdeckung von einer Satellitenkonstellation 900 und lädt einen Datensatz 930 herunter. Die Konstellation 900 kann Operationen zum Handoff des Downloads unter Verwendung von Inter-Satelliten-Links koordinieren (wie etwa in einem Szenario, bei dem der Datensatz 930 gestreamt wird oder nicht vollständig heruntergeladen werden kann, bevor sich die Satelliten-Ausleuchtzone bewegt).
  • Der Satelliten-Download 925 wird dem sNB 920 zur Verarbeitung bereitgestellt, beispielsweise mit einem Cloud-Upload 915 auf einen Server 910 (zum Beispiel ein CDN, das sich an oder nahe dem sNB 920 befindet). Sobald sie zum sNB 920 heruntergeladen sind (und auf den Server 910 hochgeladen wurden), können folglich die Nutzergeräte, die sich innerhalb der terrestrischen Abdeckungsfläche (zum Beispiel 5G-Abdeckungsfläche) des sNB 920 befinden, nun auf die Daten von dem Server 910 aus zugreifen.
  • 10A veranschaulicht eine terrestrische satellitenfähige Edge-Verarbeitungsanordnung, bei der Routing „am Boden“ durchgeführt wird und der Satellit als eine „Bent Pipe“ zwischen Edge-Verarbeitungsstandorten verwendet wird. Hierbei bezieht sich der Begriff „Bent Pipe“ auf die Verwendung eines Satelliten oder einer Satellitenkonstellation als ein Verbindungsrelais, um einfach Daten von einem terrestrischen Standort zu einem anderen terrestrischen Standort zu kommunizieren. Wie in dieser Figur gezeigt, weist ein Satellit 1000 in einer Konstellation einen Orbitalweg auf, der sich von Position 1001A zu 1001B bewegt und dabei zu jeweiligen Zeiten separate Abdeckungsbereiche 1002 und 1003 für Konnektivität bereitstellt.
  • Wenn sich hier ein satellitenfähiger Edge-Computing-Knoten 1031 (sNB) im Abdeckungsbereich 1002 befindet, bezieht er Konnektivität über den Satelliten 1000 (bei Position 1001A), um mit einem breiteren Netzwerk zu kommunizieren. Zusätzlich kann sich dieser Edge-Computing-Knoten sNB 1031 an einer Edge-Bodenstation 1020 befinden, die auch in weiterer Kommunikation mit einem Datenzentrum 1010A steht, um Rechenoperationen an einem terrestrischen Standort durchzuführen.
  • Gleichermaßen bezieht, wenn sich ein satellitenfähiger Edge-Computing-Knoten 1032 (sNB) im Abdeckungsbereich 1003 befindet, dieser Konnektivität über den Satelliten 1000 (bei Position 1001B), um mit einem breiteren Netzwerk zu kommunizieren. Auch hier werden Rechenoperationen (z.B. Dienste, Anwendungen usw.) an einem terrestrischen Standort, wie etwa der Edge-Bodenstation 1030 und dem Datenzentrum 1010B, verarbeitet.
  • 10B veranschaulicht eine andere terrestrische satellitenfähige Edge-Verarbeitungsanordnung. Ähnlich der in 10A gezeigten Anordnung zeigt diese Figur den Satelliten 1000 in einer Konstellation entlang eines Orbitalwegs, der sich von Position 1001A zu 1001B bewegt und dabei zu jeweiligen Zeiten separate Abdeckungsbereiche 1002 und 1003 bereitstellt. In diesem Beispiel wird der Satellit jedoch als ein Datenzentrum verwendet, um Edge-Computing-Operationen durchzuführen (z.B. Daten liefern, Daten berechnen, Daten weiterleiten usw.).
  • Insbesondere befindet sich an dem Satellitenfahrzeug die Edge-Computing-Hardware 1021 zum Verarbeiten von Rechen- oder Datenanfragen, die von den Bodenstations-sNBs 1031, 1032 in den Abdeckungsbereichen 1002, 1003 empfangen werden. Das kann den Vorteil einer Beseitigung der Kommunikationslatenz haben, die mit einem anderen Standort im Weitverkehrsnetz verbunden ist. Aufgrund von Verarbeitungs- und Speicherungseinschränkungen kann jedoch die Menge an Rechenleistung am Satelliten 1000 begrenzt sein und dementsprechend können einige Anfragen oder Operationen an die Bodenstationen 1031, 1032 verschoben werden.
  • Es versteht sich, dass Edge-Computing und Edge-Netzwerkkonnektivität verschiedene Aspekte von RAN- und softwaredefinierter Vernetzungsverarbeitung beinhalten können. Insbesondere kann in vielen dieser Szenarien in Abhängigkeit von verfügbaren Verarbeitungsressourcen zwischen Boden und Satellit drahtlose Termination verschoben werden. Ferner kann in diesen Szenarien eine URLCC- (ultra-reliable low latency connections, ultra-zuverlässige Verbindungen mit niedriger Latenz) Verarbeitung am Boden oder in Nutzdaten verwendenden Paketverarbeitungsansätzen, einschließlich mit den vorliegend weiter besprochenen Paketverarbeitungsvorlagen, und mit vRAN-DU- (verteilte Einheiten) Verarbeitung und Beschleunigung, durchgeführt werden.
  • 10C veranschaulicht weitere Vergleiche terrestrischer und nicht-terrestrischer Edge-Verarbeitungsanordnungen. Hier wird das Satellitennetzwerk 1005, das durch eine LEO-Konstellation bereitgestellt wird verwendet: a) auf der linken Seite, um Konnektivität und Edge-Verarbeitung für Millionen von Benutzervorrichtungen 1041 (z.B. UEs, IOT-Sensoren) bereitzustellen, die über keine drahtgebundene direkte Verbindung zum Kernnetz 1061 verfügen; b) in der Mitte, um Konnektivität und Edge-Verarbeitung über einen „Bent Pipe“-Edge-Server 1051 bereitzustellen, der eine drahtgebundene direkte Verbindung mit dem Kernnetz 1061 aufweist, der tausende von Edge-Servers auf dem Boden unterstützt; c) auf der rechten Seite, um die Verwendung eines bordinternen Edge-Servers 1081 bereitzustellen, der sich auch mit einem hybriden Edge-Server 1071 koordinieren kann, um hunderte von Servern für eine In-Orbit-Verarbeitung und hunderte Server für Bodenstationen zu unterstützen. Es versteht sich, dass auf die Server 1051, 1071 und 1081 zur Verwendung durch die verschiedenen UEs 1041 basierend auf Konnektivitäts- und Dienstorchestrierungserwägungen zugegriffen werden kann, wie sie beispielsweise nachstehend behandelt werden.
  • Zusätzliche Szenarien zur Netzwerkverarbeitung sind in 11A bis 11D abgebildet. 11A stellt zunächst eine Edge-Konnektivitätsarchitektur dar, die RAN-Aspekte am Boden beinhaltet und eine Satellitenverbindung (über den Satelliten 1101) als eine „Bent Pipe“ mit einer vRAN-DU 1140 als Edge am Boden verwendet. In diesem Szenario kommuniziert die Satelliten-Edge-Ausrüstung 1120A mit Up- und Downlinks über eine 5G-NR- (New-Radio-) Schnittstelle 1111 mit dem Satelliten 1101; der Satellit kommuniziert zudem mit Up- und Downlinks über eine NR-Schnittstelle 1112 mit einer RRU (remote radio unit, Fernfunkeinheit) 1130, die wiederum mit der vRAN-DU 1140 verbunden ist. Ferner befinden sich im Netz die vRAN-CU (Zentraleinheit) 1150 und das Kernnetz 1160.
  • Die Satelliten-Edge-Ausrüstung 1120A stellt eine Konfiguration einer beispielhaften Plattform dar, die dazu konfiguriert ist, Konnektivität und Edge-Verarbeitung für Satellitenkonnektivität bereitzustellen. Diese Ausrüstung 1120A beinhaltet insbesondere eine HF-phasengesteuerte Array-Antenne 1121, einen Speicher 1122, einen Prozessor 1123, eine Netzwerkschnittstelle (die z.B. Ethernet/Wi-Fi unterstützt) 1124, GPS 1125, einen Antennensteuermotor 1126 und Leistungskomponenten 1127. Andere Konfigurationen und Computerarchitekturen der Ausrüstung 1120A zur Edge-Verarbeitung werden vorliegend weiter behandelt.
  • 11B bis 11D zeigen eine vereinfachte Version einer Satellitenzugangsausrüstung 1120B, die für Netzwerkzugang verwendet wird. In der Anordnung aus 11B wird ein ähnliches Bent-Pipe-Konnektivitätsszenario bereitgestellt, wobei sich die vRAN-DU 1140 am Boden befindet. In der Anordnung aus 11C befindet sich die vRAN-DU 1141 an Bord des SV, wobei eine F1-Schnittstelle 1113 verwendet wird, um mit einer vRAN-CU 1150 und einem Kernnetz 1160 am Boden eine Verbindung herzustellen. In der Anordnung aus 11D schließlich befinden sich die vRAN-DU 1141 und die vRAN-CU 1151 an Bord des SV, wobei eine N1-3-Schnittstelle 1114 für die Verbindung mit dem Kernnetz am Boden verwendet wird.
  • In weiteren Beispielen können die vorstehend identifizierten Satelliten- und Bodenkonnektivitätsnetzwerke für eine Satelliten- und SG-Bodenstationsoptimierung unter Verwendung verschiedener KI- (künstliche Intelligenz) Verarbeitungsmethoden angepasst werden. In einem Beispiel kann Infrastrukturoptimierung in Bezug auf terrestrische 5G-Mastenplatzierung für optimale Performanz (Uplink, Downlink, Latenz) und Satellitenkonstellationskoexistenz analysiert werden, um verbesserte Netzwerkabdeckung zu unterstützen.
  • Einige Satellitenkonstellationen können begrenzte Bodenstationen aufweisen und dementsprechend kann die Satellitenkonnektivitätslatenz beeinflusst werden, wenn keine Sichtlinie zu Vorrichtungen am Boden besteht. Infolgedessen wird erwartet, dass Dienstanbieter ihr Netz für eine 5G-Mastenplatzierung optimieren, um durch Wetter verursachte Störungen zu vermeiden. Satellitenbilder können als Inferenzeingang in eine KI-Engine verwendet werden, was es einem Dienstanbieter ermöglicht, optimales Routing und 5G-Mastenplatzierung zu bestimmen, wobei neben anderen Erwägungen Faktoren wie etwa geografischer Standort, Bedarf, Latenz, Uplink, Downlink-Anforderungen, Wetteraussicht nach vorne genutzt werden.
  • Satellitenabdeckungskoordination
  • Die folgenden Methoden können verwendet werden, um eine Satellitenabdeckungs-Ausleuchtzone für LEO-Satellitennetzwerkkonnektivität zu erhalten. Eine Abdeckungs-Ausleuchtzone kann zu Zwecken eines Bestimmens verwendet werden, wann Satellitenkonnektivität an einem bestimmten Ort verfügbar ist (z.B. an einem UE oder einer Satelliten-Backhaul-Basisstation), sowie zur Koordination von Edge-Computing-Operationen zwischen terrestrischen und nicht-terrestrischen Standorten.
  • Bei der Betrachtung der Satellitenabdeckung von LEOs treten zwei Hauptherausforderungen auf. Erstens wird in Abhängigkeit von der Höhe und der Dichte einer Konstellation die Zeit, zu der ein bestimmter Edge-Standort mit Netzwerkzugang (und Rechenzugang) abgedeckt wird, variieren. Latenz und Bandbreite einer Satellitenverbindung können sich zudem im Zeitverlauf ändern. Zweitens befinden sich Satelliten, die Rechenressourcen hosten, ständig in Bewegung und koordinieren Berechnung mit anderen Satelliten und Bodensystemen. Daher sind Standort und Abdeckungsfähigkeiten eines Satelliten-Edge-Rechenknotens eine wichtige Überlegung, die ständig berücksichtigt werden muss.
  • Das Folgende stellt einen Befehlsmechanismus zum Identifizieren von Satellitenabdeckung und Positionen einzelner SVs zum Zweck des Koordinierens mit SVs zum Ausführen von Edge-Computing-Arbeitslasten oder zum Beziehen von Inhalten bereit. Mit diesen Abdeckungs- und Positionsinformationen können einzelne Edge-Endpunktvorrichtungen Operationen planen oder anpassen, um den Nutzen von LEO-Konnektivität zu maximieren.
  • In einem Beispiel kann ein Befehl mit einem Konnektivitätsdienst definiert werden, um zukünftige (Überflug-) Satellitenfahrzeugpositionen bezüglich eines Bodenstandorts zu erhalten. Dies kann durch einen „SV-Ausleuchtzone beziehen“-Befehl bereitgestellt werden, der durch das Netzwerk oder den Dienstanbieter angeboten wird. Im Folgenden können Bezugnahmen auf einen Boden (ground, GND) einer Bodenstation-Edge, Telemetrieverfolgung, UE- oder IoT-Sensorstandorten entsprechen. Für diesen beispielhaften „SV-Ausleuchtzone beziehen“-Befehl können die folgenden Parameter bereitgestellt werden: TABELLE 1
    Parameter Typ Anmerkungen
    SV.id GANZZAHL Eindeutige 10 Satellitenfahrzeug
    Id.GND.Iat GLEITKOMMA Breitengrad Bodenstandort für SV-Überflug (Fly-over)
    Id.GND.long GLEITKOMMA Längengrad Bodenstandort für SV-Überflug
    GND.alt GLEITKOMMA Höhe Bodenstandort % für Intensitätsschwellenberechnungen
    Id.GND.time GANZZAHL Zeitdauer zum Erhalten von SV-Flyover(s)
    Id.elevation.start GANZZAHL Horizonthöhe Grad.start
    Id.elevation.max GANZZAHL Horizonthöhe Grad.max
    Id.elevation.end GANZZAHL Horizonthöhe Grad.ende
    Id.di rection.start GANZZAHL Anflugrichtung Grad (N/S/O/W usw.)
  • Beispielsweise können die „Richtung“-Eigenschaften verwendet werden, um Überflugtelemetrie zu beziehen.
  • Zudem kann zum Beispiel eine Antwort auf diesen „SV-Ausleuchtzone beziehen“-Befehl definiert werden, um dem Anfragenden eine Antwort mit den folgenden Informationen bereitzustellen: TABELLE 2
    Parameter Typ Anmerkungen
    SV.id GANZZAHL Eindeutige 10 Satellitenfahrzeug
    SV.name ZEICHENFOLGE SV-Name
    SV.footprint.lat GLEITKOMMA Mittlerer Breitenpunkt der erwarteten Strahlausleuchtzone
    SV.footprint.long GLEITKOMMA Mittlerer Längengrad der erwarteten Strahlausleuchtzone
    SV.footprint.radius GLEITKOMMA Radius der erwarteten Strahlausleuchtzone
    SV.time GANZZAHL Erwartete Zeit der Bestrahlung durch Strahlausleuchtzone
    SV.min.intensity GLEITKOMMA Höhe der Strahlausleuchtzone für Intensitätsberechnungen
    SV.frequency.total GLEITKOMMA Frequenzband insgesamt
    SV.frequency.available GLEITKOMMA verfügbares Frequenzband
    SV.frequency.premium GLEITKOMMA Frequenz für Premium-SLA
    SV.frequency.besteffort GLEITKOMMA Frequenz für Best-Effort-SLA
    Id.intersatlink.right GANZZAHL Inter-Satelliten-Link-Verfügbarkeit.rechts
    Id.intersatlink.left GANZZAHL Inter-Satelliten-Link-Verfügbarkeit. links
    Id.intersatlink.fore GANZZAHL Inter-Satelliten-Link-Verfügbarkeit.vorne
    Id.intersatlink.aft GANZZAHL Inter-Satelliten-Link-Verfügbarkeit.hinten
  • Es versteht sich, dass sich die Verfügbarkeitseigenschaften auf Informationen über verfügbare Frequenzen und Inter-Satelliten-Links für Routing-Entscheidungen erstrecken können, einschließlich Entscheidungen, die die Edge-Computing-Standorte beinhalten, auf die am Satelliten, über eine Bent-Pipe-Verbindung oder beides zugegriffen werden kann.
  • 12 veranschaulicht ein Flussdiagramm 1200 eines Verfahrens zum Beziehen von Satellitenfahrzeugpositionen in Verbindung mit Edge-Rechenoperationen gemäß einem Beispiel. Bei Operation 1210 wird eine Anfrage gestellt, die zukünftigen Überflugpositionen eines Satellitenfahrzeugs bezüglich eines Bodenstandorts zu beziehen. In einem Beispiel, zusätzlich zu Tabelle 1 oben, beinhaltet diese Anfrage eine Identifikation von Breitengrad, Längengrad und (Meeres-) Höhe, die zum Satellitenempfang verwendet werden. Aspekte der Anfrage und des Befehls können zudem Authentifizierung beinhalten (z.B. um zu gewährleisten, dass das Kommunikationsprotokoll sicher ist und bereitgestellte Daten vertrauenswürdig sind und nicht gespooft werden können).
  • Bei Operation 1220 wird eine Antwort erhalten, die die zukünftigen Überflugpositionen des Satellitenfahrzeugs relativ zu dem Bodenstandort angibt. Beispielsweise können der „Beziehe SV-Ausleuchtzone“-Befehl und die vorstehend genannten Antworten verwendet werden.
  • Basierend auf diesen Ausleuchtzoneninformationen kann Operation 1230 durchgeführt werden, um die Netzwerkabdeckung und Abdeckungsänderungen bezüglich des Bodenstandorts zu identifizieren. Edge-Computing-Operationen können bei Operation 1240 basierend auf der identifizierten Netzwerkabdeckung und Abdeckungsänderungen angepasst oder optimiert werden.
  • Eine weitere Variation dieses Verfahrens und ähnlicher Verfahren wird durch die folgenden Beispiele bereitgestellt.
  • Beispiel A1 ist ein Verfahren zum Bestimmen einer Satellitennetzwerkabdeckung eines LEO- (Niedrigorbit-) Satellitensystems, das durch eine terrestrische Rechenvorrichtung durchgeführt wird, umfassend: Beziehen der Satellitenabdeckungsdaten für einen Breitengrad und Längengrad eines terrestrischen Bereichs, wobei die Satellitenabdeckungsdaten eine Angabe zu Zeit und Intensität einer erwarteten Strahlausleuchtzone am terrestrischen Bereich beinhalten; basierend auf den Satellitenabdeckungsdaten erfolgendes Identifizieren einer Satellitenabdeckung für Konnektivität mit einem Satellitennetzwerk unter Verwendung des LEO-Satellitensystems; Anpassen von Edge-Computing-Operationen an der terrestrischen Rechenvorrichtung basierend auf den Satellitenabdeckungsdaten.
  • In Beispiel A2 beinhaltet der Gegenstand des Beispiels A1 wahlweise einen Gegenstand, bei dem die Satellitendeckungsdaten eine Identifikation des Breitengrads, Längengrads und der Höhe beinhalten, die für Satellitenempfang an dem terrestrischen Bereich verwendet werden.
  • In Beispiel A3 beinhaltet der Gegenstand von Beispiel A2 wahlweise einen Gegenstand, bei dem die Satellitenabdeckungsdaten ferner einen Radius für die erwartete Strahlausleuchtzone, eine Zeit für eine erwartete Strahlausleuchtzone auf der Höhe und eine Mindestintensität für die erwartete Strahlausleuchtzone auf der Höhe beinhalten.
  • In Beispiel A4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A3 wahlweise einen Gegenstand, bei dem die Satellitenabdeckungsdaten ferner einen mittleren Breitenpunkt der erwarteten Strahlausleuchtzone und einen mittleren Längengrad der erwarteten Strahlausleuchtzone beinhalten.
  • In Beispiel A5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A4 wahlweise einen Gegenstand, bei dem die Satellitenabdeckungsdaten eine Kennung eines Satellitenfahrzeugs oder einer Satellitenkonstellation beinhalten.
  • In Beispiel A6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A5 wahlweise einen Gegenstand, bei dem eine Anfrage für die Satellitenabdeckungsdaten eine Zeitdauer beinhaltet, die benötigt wird, um Kommunikationsoperationen über das Satellitennetzwerk auszuführen, und die Satellitenabdeckungsdaten eine Zeitdauer beinhalten, die zum Durchführen der Kommunikationsoperationen über das Satellitennetzwerk verfügbar ist.
  • In Beispiel A7 beinhaltet der Gegenstand des Beispiels A6 wahlweise einen Gegenstand, bei dem die Satellitenabdeckungsdaten eine Kennung und einen Namen eines Satellitenfahrzeugs oder einer Satellitenkonstellation beinhalten, um die Kommunikationsoperationen über das Satellitennetzwerk durchzuführen.
  • In Beispiel A8 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A7 wahlweise einen Gegenstand, bei dem das Anpassen der Edge-Computing-Operationen Durchführen von Operationen lokal an einem terrestrischen Edge-Computing-Standort beinhaltet.
  • In Beispiel A9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A8 wahlweise einen Gegenstand, bei dem das Anpassen der Edge-Computing-Operationen Auslagern von Rechenoperationen von einem terrestrischen Rechenstandort an einen Standort umfasst, auf den über das Satellitennetzwerk zugegriffen werden kann.
  • In Beispiel A10 beinhaltet der Gegenstand des Beispiels A9 wahlweise einen Gegenstand, bei dem der Standort, auf den über das Satellitennetzwerk zugegriffen werden kann, einen Edge-Computing-Knoten umfasst, der sich innerhalb mindestens eines der Folgenden befindet: eines Satellitenfahrzeugs, das durch die Satellitenabdeckungsdaten angegeben wird, eine Satellitenkonstellation, die über eine durch die Satellitenabdeckungsdaten angegebene Verbindung verbindbar sind, oder ein Boden-Edge-Verarbeitungsstandort, der über eine durch die Satellitenabdeckungsdaten angegebene Verbindung verbindbar ist.
  • In Beispiel A11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A9 bis A10 wahlweise einen Gegenstand, bei dem der Standort, auf den über das Satellitennetzwerk zugegriffen werden kann, ein Cloud-Computing-System umfasst, das über einen Backhaul des Satellitennetzwerks zugänglich ist.
  • In Beispiel A12 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A11 wahlweise einen Gegenstand, bei dem das Anpassen der Edge-Computing-Operationen Auslagern von Dateninhaltsoperationen von einem terrestrischen Rechenstandort an einen Dateninhaltsspeicherungsstandort umfasst, auf den über das Satellitennetzwerk zugegriffen werden kann.
  • In Beispiel A13 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A12 wahlweise einen Gegenstand, bei dem das Anpassen von Edge-Computing-Operationen an der terrestrischen Rechenvorrichtung ferner auf Latenz- und Dienstinformationen basiert, die basierend auf den Satellitenabdeckungsdaten berechnet werden.
  • In Beispiel A14 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A13 wahlweise einen Gegenstand, bei dem das Beziehen der Satellitenabdeckungsdaten Übertragen einer Anfrage nach Satellitenabdeckungsdaten an einen Dienstanbieter umfasst, damit eine Satellitenabdeckung am Breiten- und Längengrad des terrestrischen Bereichs erfolgt.
  • In Beispiel A15 beinhaltet der Gegenstand eines oder mehrerer der Beispiele A1 bis A14 wahlweise einen Gegenstand, bei dem das Anpassen von Edge-Computing-Operationen Durchführen von Rechen- und Routing-Entscheidungsberechnungen basierend auf Informationen umfasst, die Folgendes angeben: verfügbare Satellitennetzwerkkommunikationsfrequenzen, Inter-Satelliten-Links, verfügbare Satellitennetzwerkkommunikationsintensität.
  • Verbinderrechenarchitektur für Satellitennetzwerkverbindungen
  • Wie vorstehend unter Bezugnahme auf 2 behandelt, können Vorrichtungen mit einem satellitenverbundenen Edge-Standort (z.B. einer Basisstation) verbunden sein, der duale Zugangsarten wie etwa ein Funkzugangsnetz (z.B. 3GPP-4G/SG, O-RAN Alliance Standard, IEEE 802.11 oder LoRa/LoRaWAN, der Netzwerkfunktionen wie vEPC mit CUPS/UPF usw. bereitstellt) und eine erste Ebene von Edge-Diensten (wie etwa ein CDN) implementiert. In den folgenden Beispielen erfolgt, sobald diese Dienste Konnektivität mit der Cloud oder dem Kern des Netzwerks erfordern, die Backhaul-Konnektivität über Satellitenkommunikation. Falls zum Beispiel der CDN-Cache an dem lokalen Edge-CDN einen Fehltreffer aufweist oder wenn eine Arbeitslast eine Ressource oder Hardware erfordert, die nicht an der Basisstation verfügbar ist, wird eine neue Verbindung diese Informationen über den Satellitennetzwerk-Backhaul beziehen oder bereitstellen.
  • Eine der Hauptherausforderungen solcher Boden-Satelliten-Architekturen besteht darin, wie die höheren Latenzen überwunden werden können, die auftreten, wenn Dienste Konnektivität mit dem Backhaul des Netzwerks erfordern. Dieses Problem verschärft sich weiter, wenn es mehrere Typen von Backhaul-Verbindungen (zum Beispiel zu unterschiedlichen Datenzentren) mit unterschiedlichen Überlastungseigenschaften oder - niveaus und zugehörigen Ressourcenteilungsbeschränkungen (zum Beispiel Bandbreitenbeschränkungen) gibt, die von solchen Verbindungen bereitgestellt werden. Ebenso verschärft sich dieses Problem angesichts der kleinen Zeitdauer, während der sich ein bestimmtes SV in Kommunikationsreichweite befindet, um Rechenoperationen durchzuführen oder einen Datentransfer mit einem Ursprungsstandort abzuschließen.
  • Der folgende Ansatz stellt einen „Satelliten-Edge-Verbinder“-Mechanismus zur Implementierung innerhalb eines Edge-Computing-Knotens, eines Geräts, einer Vorrichtung oder einer anderen Rechenplattform bereit. Mit diesem Mechanismus wird ein Telemetrie- und Verbindungsstatus vom Satelliten oder der Satellitenkonstellation bezogen, die Konnektivität zu einem bestimmten Edge-Computing-Standort, einer bestimmten Cloud oder einem bestimmten Datenzentrum aufweisen, und diese Statusinformationen werden genutzt, um intelligentere Netzwerkverkehrsgestaltung von der Ursprungs-Plattform zu implementieren. In einem Beispiel kann ein Satelliten-Edge-Verbinder implementiert werden, indem ein Netzwerkplattformmodul (z.B. eine diskrete oder integrierte Plattform/ein Paket) erweitert wird, das dafür zuständig ist, Kommunikationen für die Edge-Dienste zu handhaben. Dies kann an der Basisstation, dem Zugangspunkt, dem Gateway oder dem Aggregationspunkt bereitgestellt werden, die eine Netzwerkplattform als Vermittler zwischen der Endpunktvorrichtung (z.B. einem UE) und dem Satellitennetzwerk bereitstellen. Zum Beispiel kann ein Netzwerkplattformmodul am Vermittler auch dazu eingerichtet sein, QoS und Bandbreite, die mit den verschiedenen Datenströmen assoziiert sind - in die unterschiedlichen Dienste abgebildet - in Abhängigkeit von dem Backhaul-Konnektivitätszustand, der von dem Satelliten zu den verschiedenen Endpunkten verfügbar ist, dynamisch zu handhaben.
  • Zusätzlich kann in verschiedenen Edge-Computing-Settings jeder Mandant oder jede Gruppe von Mandanten unterschiedliche Sicherheits-, QoS- und datendynamische Datenschutzrichtlinien anwenden (oder anfragen), einschließlich Richtlinien, die von geografischen Standorten des Mandanten oder der Kommunikations- und Rechenhardware abhängen. In derartigen Settings kann sich eine Edge-Computing-Plattform automatisch selbst mit solchen Richtlinien basierend auf beteiligten geografischen Standorten konfigurieren, insbesondere wenn Kommunikationen durch transiente LEO-Satellitennetzwerke koordiniert werden. Ferner kann jeder Mandant oder jede Gruppe von Mandanten Regeln anwenden, die bestimmen, wie und wann spezifische QoS-, Sicherheits- und Datenrichtlinien für spezifische Rechenaufgaben oder kommunizierte Daten verwendet werden.
  • 13 veranschaulicht eine Netzwerkplattform (ähnlich der in 2), die über Satellitenkommunikationen für virtuelle Kanäle erweitert wird. In dieser Anordnung wird jeder Endpunkt (z.B. von einer anfragenden Edge-Vorrichtung) in einen virtuellen Satellitenendpunktkanal (satellite end point virtual channel, EPVC) abgebildet. Ein oder mehrere Dienstströme, die auf einen bestimmten Endpunkt (z.B. auf die Cloud A 1340A oder die Cloud B 1340B) abzielen, werden in einen Satellitenendpunkt-VC für den Satelliten 1330 abgebildet. Jeder der Dienstströme wird in einen bestimmten virtuellen Stromkanal (SVC) innerhalb dieses Satellitenendpunkt-VC abgebildet, und mehrere Ströme können in einen gleichen SVC abgebildet werden. In einem Beispiel wird ein Strom zudem unter Verwendung einer Prozessadressraum-ID (process address space ID, PASID) oder einer globalen Prozessadressen-ID (PASID) wie nachstehend bezeichnet auf einen Mandanten und Dienst abgebildet.
  • In diesem Setting kann die Netzwerklogik unter Verwendung von Telemetrie vom Satelliten 1330 (oder der Satellitenkonstellation) und einer jedem SVC zugehörigen Dienstgüte eine Bandbreite zwischen verschiedenen EPVCs dynamisch verlagern. Die Netzwerklogik kann auch aktive Rückmeldung in den Softwarestapel bereitstellen und Plattform-QoS anwenden, wie etwa um in einen EPVC abgebildete Dienste zu drosseln, wenn begrenzte Bandbreite oder andere Bedingungen (z.B. Leistung, Speicher usw.) an der Edge-Basisstation 1320, dem Satelliten 1330 oder einer der Clouds 1340A, 1340B vorliegen. Derartige Netzwerklogik kann an der Basisstation 1320 unter Verwendung der folgenden Architekturkonfiguration implementiert werden.
  • 14A und 14B veranschaulichen eine Rechensystemarchitekturkonfiguration, einschließlich eines Verbindermoduls, das zur Verwendung mit Satellitenkommunikationen angepasst ist. In 14A ist eine Architekturanordnung für ein Gerät mit einem sockelbasierten Prozessor (14A) oder mit einem Kugelgitterarray-Package-basierten Prozessor wie in 14B) gezeigt bereitgestellt. Zusätzlich zu den Prozessoren 1431, 1432 veranschaulicht die Architektur Speicherressourcen 1421, 1422, Beschleunigungsressourcen 1411, 1412, Plattformsteuerungen 1441, 1442 und Speicher-/Speicherungsressourcen 1451, 1452. Andere Rechenarchitekturen können ebenfalls zur Verwendung mit den nachstehenden Satellitenkonnektivitätsmodulen angepasst werden. Auch wenn dies nicht dargestellt ist, kann diese Architektur in einer Vielzahl von physischen Formfaktoren implementiert werden (in der Form von Servern, Boxen, Schlitten, Racks, Geräten usw.)
  • In beiden Architekturanordnungen identifizieren 14A und 14B ein Element (konkret eine Satelliten-5G-Backhaul-Karte 1461, 1462), das Konnektivität von der Plattform zu dem Satelliten als Verbinder bereitstellt. Dieses Element, als „Verbindermodul“ bezeichnet, kann in die Plattform integriert sein oder diskret als eine Vorrichtung (z.B. eine PCIE-, NVLink- oder CXL-Vorrichtung) verwendet werden.
  • In einem Beispiel wird das Verbindermodul 1461, 1462 dem Softwarestapel ausgesetzt und stellt eine ähnliche Schnittstelle wie eine Netzwerkschnittstellenkarte bereit, und kann Semantik zum Platzieren und Beziehen von Daten von einem Endpunkt (z.B. der nächsten Stufe (tier) des in einem Datenzentrum gehosteten Dienstes nach dem Satelliten, beispielsweise den Clouds 1340A, 1340B entsprechend) beinhalten. Das Verbindermodul 1461, 1462 beinhaltet logische Elemente, um zu verstehen, wie lokale Ströme nach dem Satelliten in einen oder mehrere Endpunktverbinder abgebildet werden, und zu überwachen, wie die Verbindungen zwischen den Satelliten und den Endpunktverbindern im Zeitverlauf arbeiten und wie ihre Konnektivität beeinflusst, wie viel Bandbreite Ströme effektiv erreichen können. Dies kann erreicht werden, indem Telemetrieinformationen verwendet werden, die ein Satellit der Logik bereitstellt. Zusätzliche Informationen über das Verbindermodul werden in 16 und 17 beschrieben.
  • Zusätzlich kann das Verbindermodul 1461, 1462 Dienstgüte- (QoS-) Richtlinien auf Ströme anwenden, die Verbindungen mit denselben Endpunkten mit unterschiedlichen Stufen von QoS-Agreements (z.B. mit Verbindungen, die unter verschiedenen Mandanten gemeinsam genutzt werden) gemeinsam nutzen. Das Verbindermodul 1461, 1462 kann zudem Bandbreitenlastausgleich auf die Satellitenkommunikation zwischen unterschiedlichen Strömen anwenden, die in unterschiedliche Endpunkte abgebildet werden, wenn Backhaul-Änderungen gelten. Ferner kann das Verbindermodul 1461, 1462 Ressourcen auf die Dienste herunterskalieren, die netzwerkgebunden sind, wenn die Telemetrie von dem Satelliten angibt, dass die Dienste nicht in der Lage sein werden, die gewünschte Performanz zu erreichen.
  • 15 veranschaulicht ein Flussdiagramm 1500 eines Verfahrens zum Verwenden eines Satellitenverbinders zur Koordination mit Edge-Computing-Operationen. Wie vorstehend angemerkt, können solche Operationen an einer Basisstation (wie etwa 1320) durchgeführt werden, aber es können auch andere Arten von Netzwerk-Gateways, Zugangspunkten, Aggregationspunkten oder Konnektivitätssystemen verwendet werden.
  • An einer terrestrischen Station (z.B. an der Edge-Basisstation 1320) werden aktuelle oder voraussichtliche Ströme in Operation 15 10 identifiziert und in Operation 1520 in virtuelle Kanäle (VCs) gruppiert, wie etwa durch Verwenden einer hierarchischen VC-Definition. Jeder Endpunkt wird basierend auf dem Endpunkt des Datenstroms in einen virtuellen Satellitenendpunktkanal (EPVC) abgebildet. Ein oder mehrere Dienstströme, die auf einen bestimmten Endpunkt abzielen, werden in einen Satellitenendpunkt-VC (z.B. Cloud A 1340) abgebildet. Jeder der Dienstströme wird in Operation 1530 in einen jeweiligen virtuellen Stromkanal (SVC) innerhalb dieses Satelliten-EPVC abgebildet. Somit kann ein EPVC mehrere SVCs enthalten, und jeder SVC wird in mehrere Dienste abgebildet, während er zudem auf einen Mandanten abgebildet wird, der einen assoziierten EPVC aufweist.
  • Unter Verwendung von Telemetrie von dem Satelliten und Dienstgüte, die jedem SVC angehängt ist, verlagert in Operation 1540 die Netzwerklogik die Bandbreite zwischen verschiedenen EPVCs dynamisch. Zusätzlich stellt die Netzwerklogik in Operation 1550 eine aktive Rückmeldung in den Softwarestapel bereit und wendet Plattform-QoS an, um in einen EPVC abgebildete Dienste zurückzudrosseln oder anzupassen, wenn begrenzte Bandbreite vorliegt (z.B. durch Anpassen von Leistung, Speicher oder anderen Ressourcen).
  • 16 veranschaulicht eine interne Architektur eines Verbindermoduls 1610, die an einem terrestrischen Standort (z.B. einem „Boden“-Edge-Computing-System) implementiert sein kann, der zur Verwendung mit Satellitenkommunikationen angepasst ist. Wie vorstehend angemerkt, unterstützt diese Architektur eine spezifische Weise zum Gruppieren von Datenströmen in virtuelle EPVC-Kanäle (z.B. unter Verwendung einer hierarchischen Definition virtueller Kanäle) und zum effizienten Kommunizieren über Satellitennetzwerke.
  • Die interne Architektur von 1610 ist auf ein Ende-zu-Ende-System mit positionierten LEO-Satelliten anwendbar, die mit einem am Boden befindlichen Edge-Gerät verbunden sind. Unter der Annahme, dass das am Boden befindliche Edge-Gerät nicht ständig volle Konnektivität und Verbindungen mit hoher Bandbreite aufweist (z.B. aufgrund eines entfernten Standorts), stellt das Folgende einen vorteilhaften Ansatz zum Koordinieren der Satelliten-Backhaul-Datentransfers und der nötigen Verarbeitungsaktionen bereit.
  • In einem Beispiel ermöglicht die Verwendung des Verbindermoduls 1610 eine Koordinierung von Datentransfers a) zwischen den Satelliten, die einen Cluster/eine Gruppierung/Konstellation bilden (z.B. um benötigten Datentransfer zu minimieren, einschließlich zum Senden von ausschließlich zusammengefassten Informationen oder zum Verhindern von Datentransferduplikaten, falls angemessen), und b) zwischen einem Cluster von Satelliten und den Bodenstationen (z.B. um zu bestimmen, wann welche Satelliten welche Daten kommunizieren, und um einen Handoff zu einer nächsten Bodenstation zu ermöglichen). Die Planung und Koordination hat für solche Übertragungen Schlüsselbedeutung - nicht nur für Datenverwaltung, Ressourcenzuteilung und Verwaltung, sondern auch vom Standpunkt der Verarbeitungsreihenfolge.
  • In einem Logistikanwendungsfall sei beispielsweise ein System betrachtet, das von einem Bodensteuersystem und einem Satellitenkonnektivitätsnetzwerk koordiniert wird, um einen gemeinsamen Plan zur Bewegung und Verfolgung einer physischen Ressource zu bestimmen, wie etwa eine Verfolgungsbewegung von Frachtschiffen auf einem Meer. Hier beinhaltet Koordination Identifizieren a) des relevanten Bereichs für Satellitenkonnektivität (z.B. basierend auf der geografischen Positionierung der Frachtschiffe), b) welche Art von Verarbeitung über das Satellitensystem benötigt wird (z.B. Bildverarbeitung zum Detektieren der Anzahl von Frachtschiffen) und c) wie viel Bandbreite, Ressourcen oder Verarbeitung erforderlich sind, um ein Datenergebnis über die Satellitenkonnektivität zurückzusenden (z.B. um nur die Anzahl von in den Bilddaten identifizierten Frachtschiffen zurückzuliefern und nicht alle Bilder).
  • Es versteht sich, dass eine Vielfalt herkömmlicher Netzwerkeinsätze Dienstgüte- und Service-Level-Agreements berücksichtigen. Bestehende Ansätze sind jedoch nicht in der Lage, vollständig auf Satellitensystemarchitekturen und die Konnektivitätserwägungen, die an solchen Architekturen beteiligt sind, zu reagieren. Des Weiteren wird das Konzept der Backhaul-Konnektivität durch ein Satellitennetzwerk nicht als Teil existierender Architekturen berücksichtigt. Infolgedessen stellen die gegenwärtig offenbarten Ansätze adaptive Ende-zu-Ende-QoS-Richtlinien für Satelliten-Edge bereit und stellen eine Ressourcenzuteilung basierend auf Mobilität und Multi-Satelliten-Telemetrie bereit.
  • Unter Bezugnahme auf die Verbindermodularchitektur aus 16 wird jeder Endpunkt der Kommunikation unter Verwendung von Stromkonfigurationslogik 1611 eines Boden-Edge-Verbindermoduls 1610 in einen virtuellen Satellitenendpunktkanal (EPVC) abgebildet. Ein oder mehrere Dienstströme, die auf einen bestimmten Endpunkt abzielen, werden in einen virtuellen Satellitenendpunktkanal (VC) (z.B. Cloud A) abgebildet, der die Verarbeitung (z.B. Bilddetektionsverarbeitung) durchführt. Ferner wird in einem Beispiel jeder der Dienstströme von innerhalb dieses Satellitenendpunkts VC in einen bestimmten virtuellen Stromkanal (SVC) abgebildet.
  • Die Stromkonfigurationslogik 1611 stellt zudem Schnittstellen zum Systemsoftwarestapel bereit, um die Kennung der verschiedenen Ströme (die in Form einer Prozessadressraumkennung (PASID), einer Anwendung/eines Dienstes, der durch eine PASID+Mandant-Kennung repräsentiert wird, oder eine beliebige ähnliche Art von Prozess- oder Dienstidentifikation vorliegen kann) in den entsprechenden EPVC und SVC abzubilden. In einem Beispiel ermöglicht die Logik 1611 zudem einem System, Folgendes bereitzustellen oder zu beziehen: eine Identifikation der Dienste, eine Identifikation des EPVC und SVC, die mit der PASID assoziiert sind (es wird angemerkt, dass verschiedene Ströme denselben SVC gemeinsam nutzen können); und eine Identifikation von Latenz- und Bandbreitenanforderungen, die mit dem Strom assoziiert sind. Eine weitere Erörterung dieser Eigenschaften und Ströme erfolgt nachstehend unter Bezugnahme auf 17.
  • Unter Verwendung von Telemetrie vom Satelliten und Dienstgüte, die jedem SVC beigefügt ist, verlagert die Netzwerklogik (z.B. Logik 1612-1615, in Koordination mit Satellitenkommunikationslogik 1616) dynamisch Bandbreite zwischen verschiedenen EPVCs, stellt aktive Rückmeldung über eine Plattform-RDT in den Softwarestapel bereit, und wendet Plattform-QoS an, um in einen EPVC abgebildete Dienste zurückzudrosseln, etwa wenn beschränkte Bandbreite vorhanden ist (z.B. Leistung, Speicher usw.). Derartige Logik kann zusätzlich zu bestehenden Formen von Satellitenkommunikationslogik 1618 und einer Plattformressourcenanweisungstechnologie 1619 arbeiten.
  • An einem Edge-Verbinder der Satelliten-Edge 1620 können satellitenseitige Fähigkeiten koordiniert werden, um die Operationen an der Boden-Edge 1610 zu ergänzen. Gleichermaßen ermöglicht die an der Satelliten-Edge 1620 implementierte Logik einem Satellitensystem, einen SVC mit speziellen Bandbreiten- und Latenzanforderungen zu erzeugen.
  • An der Satelliten-Edge 1620 können verschiedene Komponenten in den EPVC und SVC eingebunden werden, um die E2E-Richtlinien zu implementieren, die durch die Boden-Edge 1610 angegeben werden. Solche Satellitenfähigkeiten können eine Ende-zu-Ende-QoS-SVC-Abbildung 1621, eine prädiktive Routen- und QoS-Zuteilungsplanung 1622, Richtlinien für zukünftige Ende-zu-Ende-Ressourcenreservierung 1623 (die sowohl lokale (Satelliten-) als auch Bodenrichtlinien unterstützen), Telemetrieverarbeitung 1624 (die lokale (Satelliten-) Telemetrie, Bodentelemetrie und Peer-weitergeleitete Telemetrie unterstützt), und terrestrische Edge-Zonen und Up- und Down-Link-Agreement-Verarbeitung 1625 beinhalten.
  • 17 stellt zusätzliche Beispiele für Verarbeitungslogik bereit, die innerhalb einer Edge-Architektur des Edge-Verbinders 1610 an einer Boden-Edge verwendet wird, einschließlich Beispielen für Informationen, die für Ströme und Kanäle beibehalten werden. In einem Beispiel stellt die Stromkonfigurationslogik 1611 Schnittstellen zum Systemsoftwarestapel (nicht gezeigt) bereit, um verschiedene Strom-IDs (die in Form von PASID oder einer beliebigen ähnlichen Art von Identifikation vorliegen können, einschließlich wenn eine PASID auf einen Mandanten abgebildet wird) in den entsprechenden EPVC und SVC abzubilden. Die Stromkonfigurationslogik 1611 kann zum Beispiel einen Datensatz 1720 sammeln und beibehalten, der Folgendes bereitstellt: (1) eine Kennung der Dienste; (2) EPVC- und SVC-Kennungen, die mit der PASID assoziiert sind (es wird angemerkt, dass verschiedene Ströme denselben SVC gemeinsam nutzen können und somit mehrere PASIDs auf denselben SVC abgebildet werden); und (3) Latenz- und Bandbreiteninformationen (z.B. Anforderungen), die mit dem Strom assoziiert sind. Mit diesen Informationen ermöglicht die Stromkonfigurationslogik 1611 die Erstellung eines SVC mit bestimmten Bandbreiten- und Latenzanforderungen.
  • 18 veranschaulicht ein Flussdiagramm 1800 eines Verfahrens zum Verwenden eines Satellitenverbinders zur Koordination mit Edge-Computing-Operationen. Zusätzliche Operationen (nicht gezeigt) können andere Aspekte von Lastausgleich, QoS-Verwaltung, Ressourcenverwaltung und Stromaggregation in Übereinstimmung mit den vorliegend erörterten Methoden nutzen.
  • In Operation 1810 werden Datenströme unter Verwendung einer auf einen Mandanten abgebildeten Identifikation auf einen Endpunkt und einen virtuellen Kanal abgebildet. In einem Beispiel wird dies durch die Logik 1614 und 1615 durchgeführt. Die Endpunkt- (EP-) Telemetrielogik 1614 und die Endpunkt- (EP-) Projektionslogik 1615 sind dafür zuständig, zu verfolgen und vorherzusagen (z.B. unter Verwendung von neuronalen LSTM-Netzwerken), wie sich die Konnektivität von dem Satelliten zu den Endpunkten über den Zeitraum ändert. Mit dieser Abbildung werden in Operation 1810 Informationen für Anforderungen im Zusammenhang mit den Datenströmen und Telemetrie im Zusammenhang mit den Datenströmen 1820 gesammelt. Diese Logik kann zum Beispiel einen Datensatz 1730 sammeln, der den EPVC, die letzte bekannte Bandbreite und die letzte bekannte Latenz verfolgt. Eine derartige Logik legt dem Satelliten eine neue Schnittstelle offen, was die Berücksichtigung einer aktuellen Latenz und Bandbreite ermöglicht, die jedem der Endpunkte zur Verfügung stehen.
  • In einem Beispiel wird die Telemetrie, die durch die zwei vorstehend genannten Komponenten bereitgestellt wird, den SVC- und EPVC-Lastausgleichs-QoS-Logiken wie folgt bereitgestellt:
    • (1) In Operation 1840 wird die SVC-QoS-Lastausgleichslogik 1612 verwendet, um QoS und Ressourcenausgleich über alle in einen jeweiligen SVC abgebildeten Ströme hinweg in Abhängigkeit von ihren QoS-Anforderungen anzuwenden. In Reaktion auf eine Änderung der SVC-zugeteilten Logik ist diese Logik dafür zuständig, die bestehende Bandbreite in Abhängigkeit von ihren Anforderungen an die verschiedenen Ströme zu verteilen (z.B. Verteilung von Bandbreite in Abhängigkeit von der Priorität).
    • (2) In Operation 1850 wird die EPVC-QoS-Lastausgleichslogik 1613 verwendet, um Bandbreitenkonnektivität zwischen der Plattform und dem Satelliten in Abhängigkeit von der aktuellen oder vorhergesagten verfügbaren Bandbreite für jeden der Endpunkte zu verwalten. Jeder EPVC weist eine assoziierte gegebene Priorität auf. Die Bandbreite zum Satelliten wird proportional zur Priorität auf EPVC aufgeteilt. Falls ein bestimmter Endpunkt weniger verfügbare Bandbreite als die mit seinem entsprechenden EPVC assoziierte aufweist, wird die Bandbreite unter Verwendung der gleichen Prioritätskriterien unter den anderen EPVC aufgeteilt. Bei einer Änderung (Erhöhung oder Reduzierung) einer Bandbreite zu einem bestimmten Endpunkt wird die EPVC-assoziierte Bandbreite in Abhängigkeit von der Priorität dieses bestimmten Endpunkts proportional geändert. Die erhöhte oder reduzierte Bandbreite wird den anderen EPVC bereitgestellt, wie vorstehend angegeben. Die Logik kann einem EPVC auch proaktiv etwas mehr Bandbreite bereitstellen, indem Vorhersagelogik identifiziert, dass in naher Zukunft weniger Bandbreite für einen bestimmten EP verfügbar sein wird. Daher kann jeder EPVC eine globale Quote (basierend auf der Priorität) aufweisen, die basierend auf Vorhersage vorab beansprucht werden kann.
  • Es versteht sich, dass ein EPVC, der von Ende zu Ende eingerichtet wird, neu geroutet werden kann, um einen Lastausgleich durchzuführen. Beispielsweise sei angenommen, dass ein EPVC beinhaltet, dass Edgel → Sat1 → Sat2 → Sat3 → -Boden in EPVCx abgebildet wird; aber basierend auf der erforderlichen QoS stellt Sat 2 nicht genügend Bandbreite bereit. In Reaktion hierauf kann das System EPVCx neu auf
    Sat 1 → SatX → Sat3 → Boden abbilden.
  • (3) In Operation 1860 kann die SVC-QoS-Lastausgleichslogik 1612 Telemetrie an die Plattformressourcenanweisungslogik 1619 liefern (z.B. implementiert mit einer Ressourcenanweisungstechnologie), um die mit einem bestimmten SVC assoziierten Ressourcen in Abhängigkeit von der zugeteilten Bandbreite zu erhöhen oder zu reduzieren. Die Logik kann Bandbreite zum Erfüllen erforderlicher Ressourcen für eine spezielle Kennung (z.B. PASID) unter Verwendung von Regeln identifizieren (z.B. Abbilden einer PASID-ID; Liste der Bandbreite .{BB1,... BBn} mit den entsprechenden benötigten Ressourcen (Speicher, CPU, Leistung usw.).
  • Eine weitere Variation dieses Verfahrens und ähnlicher Verfahren wird durch die folgenden Beispiele bereitgestellt.
  • Beispiel B1 ist ein Verfahren zum Einrichten verwalteter Datenstromverbindungen unter Verwendung eines Satellitenkommunikationsnetzwerks, das an einem Rechensystem durchgeführt wird, umfassend: Identifizieren mehrerer Datenströme, die zwischen dem Rechensystem und mehreren Endpunkten über das Satellitenkommunikationsnetzwerk durchzuführen sind; Gruppieren von Sätzen der mehreren Datenströme in virtuelle Endpunktkanäle (EPVCs), wobei das Gruppieren auf einem jeweiligen Endpunkt der mehreren Endpunkte basiert, Abbilden jeweiliger Datenströme der EPVCs in virtuelle Stromkanäle (SVCs) basierend auf einer Art von Dienst, die an den jeweiligen Datenströmen beteiligt ist; Identifizieren von Änderungen an den jeweiligen Datenströmen basierend auf Dienstanforderungen und Telemetrie, die mit den jeweiligen Datenströmen der EPVCs assoziiert sind; und Implementieren der Änderungen an den jeweiligen Datenströmen basierend auf einem Diensttyp, der an den jeweiligen Datenströmen beteiligt ist.
  • In Beispiel B2 beinhaltet der Gegenstand des Beispiels B 1 wahlweise einen Gegenstand, bei dem die Dienstanforderungen QoS- (Dienstgüte-) Anforderungen beinhalten.
  • In Beispiel B3 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B2 wahlweise einen Gegenstand, bei dem die Dienstanforderungen eine Einhaltung mindestens einer Dienstgütevereinbarung (SLA) beinhalten.
  • In Beispiel B4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B3 wahlweise einen Gegenstand, bei dem die mehreren Endpunkte jeweilige Cloud-Datenverarbeitungssysteme umfassen, auf die über das Satellitenkommunikationsnetzwerk zugegriffen werden kann.
  • In Beispiel B5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B4 wahlweise einen Gegenstand, bei dem die Telemetrie Latenzinformationen beinhaltet, die basierend auf den EPVCs und den SVCs identifizierbar sind.
  • In Beispiel B6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B5 wahlweise einen Gegenstand, bei dem das Identifizieren der Änderungen an den jeweiligen Datenströmen auf Konnektivitätsbedingungen basiert, die mit dem Satellitenkommunikationsnetzwerk assoziiert sind.
  • In Beispiel B7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B6 wahlweise einen Gegenstand, bei dem die Änderungen an den jeweiligen Datenströmen aus Änderungen an mindestens einem der Folgenden bereitgestellt werden: Latenz, Bandbreite, Dienstfähigkeiten, Leistungsbedingungen, Ressourcenverfügbarkeit, Lastausgleich oder Sicherheitsmerkmale.
  • In Beispiel B8 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B1 bis B7 wahlweise, dass das Verfahren ferner umfasst: Sammeln der Dienstanforderungen, die mit den jeweiligen Datenströmen assoziiert sind; und Sammeln der Telemetrie, die mit den jeweiligen Datenströmen assoziiert ist.
  • In Beispiel B9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B8 wahlweise einen Gegenstand, bei dem die Änderungen an den jeweiligen Datenströmen Verlagern mindestens eines der SVCs von einem ersten EPVC zu einem zweiten EPVC beinhalten, um die Verwendung mindestens eines Dienstes von einem ersten Endpunkt zu einem zweiten Endpunkt zu ändern.
  • In Beispiel B 10 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B9 wahlweise einen Gegenstand, bei dem das Implementieren der Änderungen an den jeweiligen Datenströmen Anwenden von QoS und Ressourcenausgleich über die jeweiligen Datenströme hinweg umfasst.
  • In Beispiel B11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B1 bis B10 wahlweise einen Gegenstand, bei dem das Implementieren der Änderungen an den jeweiligen Datenströmen Anwenden eines Lastausgleichs zum Verwalten von Bandbreite über die jeweiligen Datenströme hinweg umfasst.
  • In Beispiel B 12 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B1 bis B 11 wahlweise, dass das Verfahren ferner umfasst: Bereitstellen von Rückmeldung in einen Softwarestapel des Rechensystems in Reaktion auf Identifizieren der Änderungen an den jeweiligen Datenströmen.
  • In Beispiel B13 beinhaltet der Gegenstand von Beispiel B12 wahlweise, dass das Verfahren ferner umfasst: Anpassen der Nutzung mindestens einer Ressource, die mit einem entsprechenden Dienst assoziiert ist, innerhalb des Softwarestapels basierend auf der Rückmeldung.
  • In Beispiel B 14 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B1 bis B13 wahlweise einen Gegenstand, bei dem das Abbilden der jeweiligen Datenströme der EPVCs in die SVCs ferner auf Identifikation eines Mandanten basiert, der mit den jeweiligen Datenströmen assoziiert ist.
  • In Beispiel B 15 beinhaltet der Gegenstand von Beispiel B 14 wahlweise , dass das Verfahren ferner umfasst: Erhöhen oder Reduzieren von Ressourcen, die mit mindestens einem SVC assoziiert sind, basierend auf der Identifikation.
  • In Beispiel B 16 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B1 bis B15 wahlweise einen Gegenstand, bei dem die jeweiligen Datenströme zwischen Client-Vorrichtungen und den mehreren Endpunkten eingerichtet werden, um Inhalt aus den mehreren Endpunkten abzurufen.
  • In Beispiel B 17 beinhaltet der Gegenstand des Beispiels B 16 wahlweise einen Gegenstand, bei dem das Rechensystem einen Content-Delivery- (Inhaltslieferungs-) Dienst bereitstellt, wobei der Inhalt von den mehreren Endpunkten unter Verwendung des Satellitenkommunikationsnetzwerks in Reaktion auf einen Cache-Fehltreffer am Inhaltslieferdienst abgerufen wird.
  • In Beispiel B18 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B1 bis B17 wahlweise einen Gegenstand, bei dem die jeweiligen Datenströme zwischen Client-Vorrichtungen und den mehreren Endpunkten eingerichtet werden, um Rechenoperationen an den mehreren Endpunkten durchzuführen.
  • In Beispiel B 19 beinhaltet der Gegenstand des Beispiels B 18 wahlweise einen Gegenstand, bei dem das Rechensystem ferner dazu konfiguriert ist, ein Funkzugangsnetz (RAN) an die Client-Vorrichtungen mit virtuellen Netzwerkfunktionen bereitzustellen.
  • In Beispiel B20 beinhaltet der Gegenstand des Beispiels B 19 wahlweise einen Gegenstand, bei dem das Funkzugangsnetz gemäß Standards einer 3GPP-5G-Standard-Familie bereitgestellt wird.
  • In Beispiel B21 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 19 bis B20 wahlweise einen Gegenstand, bei dem das Funkzugangsnetz gemäß Standards einer O-RAN-Alliance-Standard-Familie bereitgestellt wird.
  • In Beispiel B22 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 19 bis B21 wahlweise einen Gegenstand, bei dem das Rechensystem in einer Basisstation für das RAN gehostet wird.
  • In Beispiel B23 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B22 wahlweise einen Gegenstand, bei dem das Satellitenkommunikationsnetzwerk ein LEO-(Niedrigorbit-) Satellitenkommunikationsnetzwerk ist, das eine Vielzahl von Satelliten in mindestens einer Konstellation umfasst.
  • In Beispiel B24 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B23 wahlweise einen Gegenstand, bei dem das Satellitenkommunikationsnetzwerk als ein Backhaul-Netzwerk zwischen dem Rechensystem und den mehreren Endpunkten verwendet wird.
  • In Beispiel B25 beinhaltet der Gegenstand eines oder mehrerer der Beispiele B 1 bis B24 wahlweise einen Gegenstand, bei dem das Rechensystem eine Basisstation, einen Zugangspunkt, ein Gateway oder einen Aggregationspunkt umfasst, der/die/das eine Netzwerkplattform als Vermittler zwischen einer Client-Vorrichtung und dem Satellitenkommunikationsnetzwerk bereitstellt, um auf die mehreren Endpunkte zuzugreifen.
  • Satellitennetzwerk-Cache- und -Speicherungsverarbeitung
  • Bei der Verwendung von Satellitenkommunikationen besteht ebenfalls eine Reihe wichtiger Herausforderungen: (1) Wie höhere Latenzen und niedrige Bandbreite überwunden werden, die auftreten, wenn Edge-Computing-Dienste Konnektivität mit dem Backhaul des Netzwerks erfordern (2) wie Geofencing-Datenrichtlinien für Daten zu implementieren sind, die zwischen Edge-Vorrichtungen, Satelliten und Endpunkten gesendet (und empfangen) werden; und (3) Wie Ende-zu-Ende-Dienstgüterichtlinien bei der Konstellation wandernder Satelliten unter Berücksichtigung von Ausschlusszonen, Geofencing und variierenden Telemetrietypen (von Satelliten-Peers in der Konstellation, von lokalen Verarbeitungssystemen und von Bodenakteuren) zu implementieren sind.
  • Neben anderen Erwägungen werden diese Probleme noch verschärft, wenn es mehrere Typen von Backhaul-Verbindungen (zum Beispiel zu unterschiedlichen Datenzentren) mit unterschiedlichen Eigenschaften, Überlastungsniveaus, Edge-Basisstationen, die sich mit dem Satelliten verbinden, Richtlinien- oder Dienstanbieterbeschränkungen bezüglich Inhalt und Diensten gibt. Zusätzlich wird, wenn neue Wege entwickelt werden, um Daten in sich bewegenden Edge-Systemen zu speichern, die Verwendung von Ausschlusszonen und anderen intrinsischen Eigenschaften von Satelliten neue Ansätze in Form von Regeln, Richtlinien, Schnittstellen erfordern, die ermöglichen, dass sich bewegende Edge-Systeme autonom dynamische Datentransformation und -Räumung mit niedriger Latenz in Abhängigkeit von diesen Ansätzen und Metadaten implementieren.
  • Ein Ansatz, der erwartungsgemäß verwendet wird, um Genehmigungsprobleme im Kontext von Satellitenkommunikationen zu lösen, beinhaltet die Anwendung von Geofencing, wie etwa, um bestimmte Dienste oder Daten nur basierend auf einem geografischen Standort verfügbar zu machen (oder um solche Dienste oder Daten oder die Verwendung solcher Dienste oder Daten zu verbieten oder zu blockieren). Im Kontext des Geofencing können drei Stufen von Geofencing zwischen beliebigen der drei Entitäten benötigt werden: Endbenutzer/Inhaltsanbieter, Satellit und Content-/Dienstanbieter. Ferner kann Geofencing nicht nur in Bezug auf den Boden gelten (z.B. welches Land ein Satellit überfliegt), sondern als ein volumetrisches Feld innerhalb des Bereichs der Datenübertragung. Beispielsweise kann ein bestimmter Würfel oder ein bestimmtes Raumvolumen von einem bestimmten Land oder einer bestimmten Entität zugeteilt, reserviert oder verwaltet werden.
  • Wenn Inhaltslieferung über Satellitenkommunikationen betrachtet wird, stellen Geofencing und Beschränkungen aufgrund der Datenmenge und des erwarteten Volumens von Inhaltslieferkommunikationen, unterschiedlichen Stufen von Dienstgütevereinbarungen zum Liefern derartiger Daten, der Anzahl von Inhaltsanbietern und grundsätzlicher Bedenken hinsichtlich Datenschutz, Sicherheit und Datenbewegung über eine solch dynamische Umgebung hinweg eine große Herausforderung dar. Das Nachfolgende bietet einen Ansatz für Caching und Inhaltsverteilung, um diesen Herausforderungen zu begegnen.
  • 19 veranschaulicht eine Netzwerkplattform (ähnlich der in 13 und 2), die als eine Content-Catching-Architektur erweitert ist. Hier ist diese Architektur mit drei terrestrischen und Satelliteninhaltslieferungs-Cache-Stufen (tiers) konfiguriert, einschließlich Dienstgüte- und Geofencing-Regeln. Im Rahmen dieser dreistufigen Caching-Architektur (Basisstationen 1920, Satelliten- und Endinhaltsanbieter 1930 und 1940, die auf Edge-Vorrichtungsanfragen 1910 reagieren) werden die Verbesserungen an den folgenden Bestandteilen implementiert:
    • (a) Adaptives Satelliten-Inhalt-Caching von mehreren Endstandorten, bereitgestellt an mehrere Sätze von Basisstationen, die über mehrere Endstandorte verteilt sind. Dies beinhaltet QoS-Richtlinien basierend auf geografischen Bereichen, Teilnehmern und Datenanbietern, die an dem Satelliten verwaltet werden. Des Weiteren wird eine neue Art von Caching-Richtlinien an den Satelliten basierend auf Folgendem bereitgestellt: Geo-Fencing, Satelliten-Peer-Hinweisen und terrestrischen Datenzugriffstreffern.
    • (b) Adaptives terrestrisches Daten-Caching basierend auf Satellitendaten-Caching-Hinweisen vom Satelliten. In diesem Fall stellt der Satellit Informationen an jede Basisstation über Inhalte bereit, die potenziell vorab abgerufen werden sollen, etwa basierend darauf, wie Basisstationen in demselben geografischen Bereich auf Inhalte zugreifen.
    • (c) Adaptiver terrestrischer Inhaltsfluss basierend auf Endpunktbandbreitenverfügbarkeit. Hier ist das Ziel, in der Lage zu sein, adaptive Drosselung an der Inhalte anfragenden Basisstation in Abhängigkeit von der realen Bandbreitenverfügbarkeit zwischen dem Satelliten und dem Endinhaltsanbieter (z.B. für Inhalt, der auf dem Satelliten-Cache fehlt) durchführen zu können.
    • (d) Daten-Geofencing, angewendet mit zwei Fencing-Stufen: (1) in Abhängigkeit von der Geolokalisierung betreffender terrestrischer Datenkonsumenten und -produzenten; und (2) in Abhängigkeit von dem x-y-z-Standort des Satelliten (unter der Annahme, dass nicht alle Standorte gestattet werden können). Daten am Satelliten können mit Geofencing-Standorten markiert werden, die als Teil der Treffer- und Fehltreffer-Richtlinie verwendet werden. Daten können auch auf dynamische Sicherheits- und Datenschutzrichtlinien abgebildet werden, die für Mandanten, Gruppen von Mandanten, Dienstanbieter und andere teilnehmende Instanzen bestimmt werden.
  • 20A und 20B veranschaulichen eine Netzwerkplattform, die über Satellitenkommunikationen für Geofencing- und Daten-Caching-Operationen erweitert wird. Diese Plattform basiert auf einer Erweiterung der für 14 beschriebenen Merkmale. Es versteht sich jedoch, dass diese Architektur auf andere Aspekte des Daten-Caching, in Bezug auf spezifische Datenflüsse, Caching-Richtlinien, Caching-Hinweise usw. erweitert werden kann
  • Wie in 20A und 20B gezeigt, ist eine Architekturanordnung für ein Gerät mit einem sockelbasierten Prozessor (20A) oder mit einem Kugelgitterarray-Package-basierten Prozessor (20B) bereitgestellt. Zusätzlich zu den Prozessoren 2031, 2032 veranschaulicht die Architektur Speicherressourcen 2021, 2022, Beschleunigungsressourcen 2011, 2012, Plattformsteuerungen 2041, Und Speicher-/Speicherungsressourcen 2051, 2052.
  • Zusätzlich zu der Verwendung eines Verbindermoduls (zum Beispiel der Satelliten-5G-Backhaul-Karte 2061, 2062) können die Architekturen die Verwendung einer terrestrischen Logikkomponente für beschleunigtes Caching 2051 integrieren. In einem Beispiel implementiert diese Komponente eine zweistufige Caching-Logik, die dafür zuständig ist, zu bestimmen, wie der Inhalt zwischen den zwei Stufen (terrestrische und Satellitenstufe) zwischengespeichert werden muss. Beispielsweise wird terrestrische Caching-Logik (z.B. implementiert in der Komponente 2051) proaktiv die Menge an vorab abzurufender Inhaltslieferung basierend auf Folgendem erhöhen oder verringern:
    • (1) Telemetrie von jeder der EPVC-Bandbreiten. Daher kann höhere Verfügbarkeit von EPVC für einen bestimmten Inhaltsanbieter eine Zunahme der Menge an Vorabrufen verursachen. Die Logik kann zudem Vorhersagedaten nutzen, um mehr Inhalt vorab abzurufen, wenn eine Situation mit höherer Sättigung vorhergesehen wird.
    • (2) Hinweise, die durch die Satellitenlogik bereitgestellt werden, die in der Lage ist, Anfragen zu analysieren, die von mehreren terrestrischen Logiken kommen. Hinweise können eine Liste heißer Inhalte bereitstellen, die mit Folgendem markiert sind: Geolokalisierung oder Bereich, in dem der Inhalt aufgenommen wird; Endpunkte oder Inhaltslieferdienste, die mit dem Inhalt verbunden sind; oder letztes Mal, als auf den Inhalt zugegriffen wurde.
  • In einem Beispiel wird die Satellitenlogik (z.B. in den Komponenten 2061, 2062 implementiert) a) proaktiv Inhalt von mehreren EP-Inhaltsquellen cachen und unterschiedliche Arten von Caching-Richtlinien in Abhängigkeit von SLA, Daten-Geofencing, Ablauf der Daten usw. implementieren; und (b) proaktiv Telemetriehinweise an die terrestrische Caching-Logik 1611 senden, die als Teil einer in 21 dargestellten Boden-Edge 1610 bereitgestellt ist.
  • 21 veranschaulicht genauer eine Gerätekonfiguration für Satellitenkommunikationen, die über Satellitenkommunikationen für Inhalts- und Geofencing-Operationen erweitert wird, gemäß einem Beispiel. Den Konfigurationsbeispielen von 16 folgend kann Satellitenlogik an einem Satelliten-Edge-Computing-System 2120 Geo-bewusste Caching-Richtlinien für ein Speicherungssystem 2130 basierend auf den folgenden Funktionskomponenten implementieren:
  • Datenanbieterregeln 2121: Jeder Inhaltsanbieter, der am Satelliten-Edge 2120 zwischengespeichert wird, weist eine bestimmte SLA-Stufe auf, die in die Datenmenge übersetzt wird, die für diesen Anbieter am Satelliten zwischengespeichert wird. Falls der Satellit zum Beispiel 100 % Caching-Kapazität aufweist, können 6 % einem Streaming-Videoanbieter zugewiesen werden.
  • Datenanbieter-Geostandortregeln 2122: Anbieterregeln können erweitert werden, um unterschiedliche Prozentsätze für einen gegebenen Anbieter zu spezifizieren, falls es unterschiedliche Typen von Endpunktanbietern an unterschiedlichen geografischen Standorten gibt. Andere Aspekte der Datentransformation für einen Anbieter oder einen Geostandort können ebenfalls definiert werden.
  • Terrestrische Räumungen 2123: Jede der Basisstationen, die den Edge-Vorrichtungen Inhalt bereitstellt, liefert den heißen Inhalt und den kalten Inhalt zurück an den Satelliten. Inhalt für A und B, der kalt wird, wird am Satelliten für weitere N Zeiteinheiten gehostet und anschließend geräumt oder durch neuen Inhalt (z.B. vorabgerufenen Inhalt) ersetzt.
  • Gemeinsame Datennutzung zwischen Anbietern 2124. Unterschiedliche CDN-Anbieter können das gemeinsame Nutzen von Inhalt oder einigem Inhalt erlauben. Jeder Inhalt beinhaltet Metadaten, die identifizieren, welche anderen Inhaltsanbieter diese Daten gemeinsam nutzen.
  • Satelliten-Geostandort-Richtlinien 2125. In Abhängigkeit vom Geostandort des Ziels können terrestrische Daten eintreffen oder fehlschlagen. Jedes Datenelement weist eine Markierung (Tag) auf, die identifiziert, welche Geostandorte auf diese Daten zugreifen können (Liste von Bereichen oder ALLE). Falls die Edge-Basisstation diese Anforderungen nicht erfüllt, tritt ein Fehltreffer auf.
  • Satelliten-APIs und Daten 2126. Es werden Entleerungs- (Flushing-) Mechanismen bereitgestellt, die ermöglichen, dass bestimmte Daten basierend auf Geostandort und basierend auf dem Typ von Content-Marikierung für Entleerung für niedrige Latenz entleert werden. Daten müssen mit Metaschlüsseln (zum Beispiel Inhaltsanbieter, Mandant usw.) markiert werden, und ein Satellit kann Schnittstellen (APIs) bereitstellen, um die Verfügbarkeit dieser Daten zu steuern (zum Beispiel um Daten mit bestimmten Metaschlüsseln zu entleeren, wenn ein geografischer Bereich X überquert wird). Die Daten werden bei ihrer Erzeugung zudem mit Geo-Tags versehen, die als Teil der Entleerungs-APIs implementiert werden können. Zusätzlich können Datentransformationsregeln basierend auf der Verwendung von Schnittstellen angewendet werden, etwa falls Daten mit Metadaten oder einem Geo-Tag übereinstimmen, wird automatisch X angewendet (z.B. Anonymisieren der Daten). Das kann garantieren, dass für bestimmte Bereiche keine Verletzungen stattfinden.
  • Zusätzlich können Daten-Peer-Satellitenhinweise als Teil der Richtlinien 2125 implementiert werden. Inhalt kann proaktiv von heiß nach warm geräumt oder herabgestuft werden, falls eine Rückmeldung von Peer-Geostandorte abdeckenden Satelliten-Peers vorhanden ist, dass dieser Inhalt nicht mehr heiß ist. Inhalt wird nach X Zeiteinheiten als warm herabgestuft und kann nach Y Zeiteinheiten geräumt werden. Inhalt kann basierend auf ähnlicher Rückmeldung von Peer-Satelliten heiß werden.
  • Es versteht sich, dass ein CDN-Cache eine komplexere Treffer-/Fehltreffer-Logik einbinden kann, die unterschiedliche Kombinationen der vorherigen Elemente implementiert. Zusätzlich können diese Varianten für andere Aspekte von Inhaltslieferung, Geocaching und latenzsensitiven Anwendungen berücksichtigt werden.
  • Das Vorstehende definiert einen neuen Typ von Semantik bei der Datenspeicherung und -lieferung an den Satelliten-Edges. Es versteht sich jedoch, dass andere Inhaltsspeicherungs-, Zwischenspeicher- und Räumungsansätze ebenfalls zur Koordination zwischen Satelliten-Edges und Rechensystemen bereitgestellt werden können.
  • 22 veranschaulicht ein Flussdiagramm eines Verfahrens 2200 zum Abrufen von Inhalt unter Verwendung von Satellitenkommunikationen basierend auf Geofencing-Operationen.
  • In Operation 2210 wird Content-Caching an einem Satelliten-Edge-Computing-Standort durchgeführt, das einen Aspekt einer Satellitenfahrzeug-, Konstellations- oder einer nicht-terrestrischen koordinierte Speicherung beinhaltet. Die vorstehend erörterten Schnittstellen können verwendet werden, um die Eigenschaften eines solchen Caching, Einschränkungen des Daten-Caching, geografische Details usw. zu definieren
  • In Operation 2220 wird terrestrisches Daten-Caching basierend auf Satellitendaten-Caching-Hinweisen durchgeführt, die von dem Satellitennetzwerk empfangen werden. Wie vorstehend besprochen, können solche Hinweise mit der Relevanz oder dem Bedarf des Inhalts, der Nutzung oder den Richtlinien an dem Satellitennetzwerk, geografischen Einschränkungen und dergleichen zusammenhängen.
  • In Operation 2230 wird ein Inhaltsfluss zwischen dem terrestrischen und Satellitennetzwerk (und Cache-Speicherorten in einem solchen Netzwerk) basierend auf Ressourcenverfügbarkeit eingerichtet. Solche Ressourcenerwägungen können sich auf Bandbreite, Speicherung oder Inhaltsverfügbarkeit beziehen, wie durch Hinweise oder Vorhersagen angegeben.
  • In Operation 2240 werden eine oder mehrere Geofencing-Beschränkungen identifiziert und für bestimmten Inhalt angewendet. Zum Beispiel können basierend auf geografischen Orten eines Satellitennetzwerks, Datenerzeuger, Datenverbraucher und Regelungen und Richtlinien, die an solchen Orten involviert sind, Inhalte gemäß einem geografischen Bereich hinzugefügt, entsperrt, beschränkt, geräumt oder gesteuert werden.
  • In Operation 2250 kann der Standort zum Cachen von Inhalten zwischen einem Satelliten-Edge-Datenspeicher und einem terrestrischen Edge-Datenspeicher koordiniert werden. Eine solche Koordination kann auf Geofencing-Beschränkungen und -Regeln, Inhaltsfluss, Richtlinien und anderen vorstehend besprochenen Überlegungen basieren.
  • Eine weitere Variation dieses Verfahrens und ähnlicher Verfahren wird durch die folgenden Beispiele bereitgestellt.
  • Beispiel C1 ist ein Verfahren zur Inhaltsverteilung in einem Satellitenkommunikationsnetzwerk, umfassend: Zwischenspeichern von Daten an einem Satellitenrechenknoten, wobei der Satellitenrechenknoten über ein Satellitenkommunikationsnetzwerk zugänglich ist; Anwenden von Beschränkungen für Zugriff auf die zwischengespeicherten Daten an dem Satellitenrechenknoten gemäß einer Position des Satellitenrechenknotens, einem Standort, der mit einer Quelle der Daten assoziiert ist, und einem Standort eines Empfängers; und Empfangen einer Anfrage nach den zwischengespeicherten Daten von einem terrestrischen Rechenknoten basierend auf Ressourcenverfügbarkeit des terrestrischen Rechenknotens, wobei die Anfrage nach den Daten basierend auf einem Erfüllen der Beschränkungen für den Zugriff auf die zwischengespeicherten Daten erfüllt wird.
  • In Beispiel C2 beinhaltet der Gegenstand von Beispiel C1 wahlweise einen Gegenstand, bei dem der terrestrische Rechenknoten dazu konfiguriert ist, Zwischenspeichern zumindest eines Teils der Daten durchzuführen, wobei das Verfahren ferner Verwalten des Zwischenspeicherns der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten umfasst.
  • In Beispiel C3 beinhaltet der Gegenstand von Beispiel C2 wahlweise einen Gegenstand, bei dem das Zwischenspeichern der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf geografischen Beschränkungen in den Beschränkungen für den Zugriff auf die zwischengespeicherten Daten durchgeführt wird.
  • In Beispiel C4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C2 bis C3 wahlweise einen Gegenstand, bei dem das Zwischenspeichern der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf Bandbreitenverfügbarkeit an dem terrestrischen Rechenknoten durchgeführt wird.
  • In Beispiel C5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C2 bis C4 wahlweise einen Gegenstand, bei dem das Zwischenspeichern der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf Hinweisen durchgeführt wird, die von dem Satellitenrechenknoten an den terrestrischen Rechenknoten geliefert werden.
  • In Beispiel C6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C2 bis C5 wahlweise einen Gegenstand, bei dem das Zwischenspeichern der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf einer Bandbreite durchgeführt wird, die von virtuellen Kanälen verwendet wird, die zwischen dem terrestrischen Rechenknoten und einem anderen terrestrischen Rechenknoten unter Verwendung einer Satellitennetzwerkverbindung hergestellt wird.
  • In Beispiel C7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C1 bis C6 wahlweise einen Gegenstand, bei dem die Beschränkungen für Zugriff auf die Daten auf Sicherheits- oder Datenschutzrichtlinien basieren, die für Folgendes bestimmt sind: mindestens einen Mandanten, mindestens eine Gruppe von Mandanten oder mindestens einen Dienstanbieter, der mit dem terrestrischen Rechenknoten assoziiert ist.
  • In Beispiel C8 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C1 bis C7 wahlweise Verwalten der zwischengespeicherten Daten an dem Satellitenrechenknoten basierend auf Richtlinien, die innerhalb eines Satelliten oder einer Satellitenkonstellation implementiert sind, die den Satellitenrechenknoten beinhaltet.
  • In Beispiel C9 beinhaltet der Gegenstand des Beispiels C8 wahlweise Räumen der zwischengespeicherten Daten aus dem Satellitenrechenknoten basierend auf mindestens einem der Folgenden: geografischen Regeln, Datenanbieterregeln oder Satellitennetzwerkrichtlinien.
  • In Beispiel C10 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C1 bis C9 wahlweise einen Gegenstand, bei dem die Beschränkungen für Zugriff auf die Daten einen Geofence definieren, der Zugang zu den Daten ermöglicht, wenn sich der Satellitenrechenknoten und der terrestrische Rechenknoten gemeinsam innerhalb des Geofence befinden.
  • In Beispiel 11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele C1 bis C10 wahlweise, dass der Gegenstand durch eine Verarbeitungsschaltungsanordnung an dem Satellitenrechenknoten durchgeführt wird, die innerhalb eines Satellitenfahrzeugs gehostet wird.
  • In Beispiel C12 beinhaltet der Gegenstand des Beispiels C11 wahlweise einen Gegenstand, bei dem das Satellitenfahrzeug ein LEO- (Niedrigorbit-) Satellit ist, der als ein Mitglied einer Satellitenkonstellation betrieben wird.
  • Satellitenkonnektivitäts-Roaming-Architekturen
  • Es versteht sich, dass viele der vorherigen Szenarien die Verwendung mehrerer LEO-Satelliten beinhalten, was zu betreiberübergreifendem Roaming führen kann, wenn sich unterschiedliche Satellitenkonstellationen im Orbit und in die Abdeckung eines geografischen Standorts eines Benutzers bewegen. Auf eine ähnliche Weise, auf die sich ein Mobilbenutzer heutzutage mit einem Benutzergerät von Netzwerk zu Netzwerk bewegt und Roaming in andere Dientanbieternetzwerke durchführen kann, wird erwartet, dass sich Satellitenkonstellationen in eine Position und aus dieser heraus bewegen und somit Benutzern die Möglichkeit bieten, Roaming zwischen unterschiedlichen Dienstanbieternetzwerken durchzuführen. Im Kontext des Edge-Computing fügt ein solches Satellitenkonstellations-Roaming ein zusätzliches Komplexitätsniveau hinzu, da nicht nur Netzwerkkonnektivität, sondern auch Arbeitslasten und Inhalt koordiniert werden müssen.
  • 23 veranschaulicht eine Systemkoordination von Satellitenroamingaktivität zwischen Satellitenanbietern, zum Roaming zwischen verschiedenen geopolitischen Jurisdiktionen und Arten von Dienstbereichen. Insbesondere veranschaulicht dieses System, wie ein Teilnehmerbenutzer 2320, der eine Vereinbarung für Konnektivität und Dienste mit einem Primäranbieter C 2312 hat, eine Inter-LEO-Roaming-Vereinbarung 2330 verwendet, um auch auf die Netzwerke von Anbieter A, B und C zuzugreifen. Mit dieser Konfiguration kann Roaming zwischen Betreibern im Weltraum koordiniert werden, wo LEO-Satelliten mit denselben Raumorbit-Koordinaten die Roaming-Vereinbarung 2330 verwenden, um einen Lastausgleich zu liefern oder andere nützliche Resilienz-/Verfügbarkeitsziele zu erreichen.
  • Roaming-Vereinbarungen können dem Muster folgen, das gegenwärtig verwendet wird, bei dem Träger in benachbarten Regionen übereinstimmen (durch einen Rechtsvertrag), Verkehr zu dem Peer-Träger zu routen, wenn ein Peer-Netzwerk erkannt wird. Die SLA für den Benutzer 2320 spiegelt die im Voraus getroffenen Vertragsvereinbarungen wider. Dies kann alternative Raten für ähnliche Dienste beinhalten, die durch den Peer-Träger bereitgestellt werden. Zusätzlich zu herkömmlichen Roaming-Vereinbarung-Ansätzen kann LEO-Satelliten-Roaming verschiedene Formen von Lastausgleichs-, Redundanz- und Resilienzstrategien beinhalten. Satelliten unterschiedlicher Träger können unterschiedliche Hosting-Fähigkeiten oder Optimierungen aufweisen, eine für Berechnung, eine für Speicherung, eine für Funktionsbeschleunigung (Faas) usw. Die Roaming-Vereinbarung kann diese Unterschiede und Raten angeben, die bei Verwendung in einer Roaming-Konfiguration berechnet werden. Der Gesamtwert für den Benutzer ist, dass Latenz zwischen Inter-LEO-Satelliten in unmittelbarer Nähe im All bedeutet, dass ein größerer Teil der Arbeitslast im All abgeschlossen werden könnte - wodurch ein Umlauf zu einem terrestrischen Edge-Hosting-Knoten vermieden wird.
  • In einem Beispiel wird eine Roaming-Vereinbarung getroffen, um eine jurisdiktionsübergreifende gemeinsame Nutzung von Edge-Ressourcen zu autorisieren. Dies wird unter Verwendung einer Benutzer-Edge-Kontext-(User Edge Context, UEC-) Datenstruktur 2340 bereitgestellt. Der UEC 2340 betrifft mehrere Kontextinformationen, die dabei helfen, den effektiven Satellitenzugang über Roaming-Vereinbarungen einzurichten, die im All physisch zusammen und über eine beliebige Anzahl von Länder-Lufträumen hinweg angeordnet sein können. Solche Standorte der Satelliten können basierend auf Raumorbit-Koordinaten wie etwa den Koordinaten A 2350A und den Koordinaten B 2350B bestimmt werden.
  • Raumkoordinaten werden durch drei Faktoren bestimmt: (1) Orbitaltrajektorie, (2) Höhe über Meeresspiegel, (3) Geschwindigkeitsvektor. Im Allgemeinen stehen diese drei miteinander in Beziehung. Die Höhe bestimmt den Geschwindigkeitsvektor, der zum Beibehalten der Höhe erforderlich ist. Trajektorie und Geschwindigkeitsvektor bestimmen, wo die möglichen Kollisionspunkte auftreten können. Es wird erwartet, dass Träger, die daran arbeiten, Roaming-Vereinbarungen einzurichten, Raumkoordinaten auswählen, die die gleichen Faktoren aufweisen, und diese dann geringfügig anpassen, um einen Puffer zwischen ihnen zu erzeugen.
  • In weiteren Beispielen kann autonome Inter-Satelliten-Navigationstechnologie von jedem Satelliten verwendet werden, um zu detektieren, wann sich ein Roaming-Peer nahe oder innerhalb des Puffers befindet, wobei Verfeinerungen an den programmierten Raumkoordinaten dynamisch und autonom angewendet werden. Somit kann unter Verwendung dieses Frameworks auch die Inter-Satelliten-Roaming-Aktivität 2350A verfolgt und bewertet werden.
  • In einem weiteren Beispiel kann ein UEC dazu konfiguriert sein, Premium-Verwendungsfälle zu erfassen, die spezifischen SLA-Überlegungen folgen, wie etwa zur Verwendung mit ultrazuverlässigen Niedriglatenz-Kommunikations- (URLLC-) SLAs. Beispielsweise kann ein SLA-Abschnitt des UEC angepasst werden, um einen Prioritätsfaktor zu erfassen, um eine Prioritätsreihenfolge verfügbarer Netzwerke zu definieren. Falls ein UE (Vorrichtung) eine Sichtlinienkonnektivität aufweist und auf mehrere terrestrische und nicht-terrestrische Netze zugreifen darf, kann ein Satz vorbestimmter Faktoren dem UE helfen, zu priorisieren, welches Netz auszuwählen ist. Beispielsweise kann ein terrestrisches Telco-Netzwerk, in dem sich das UE befindet, eine erste Priorität aufweisen, möglicherweise gefolgt von lizenzierten Satellitennetzwerkoptionen. Einige Satellitenteilnehmer können für einen Premiumdienst bezahlen, wohingegen andere nur Standarddatenratenpläne haben können, die mit ihrem UE verbunden sind. Die UE-SIM-Karte würde diese Prioritätsinformationen aufweisen und mit dem UEC hinsichtlich der SLA-Priorität arbeiten. Ein ähnliches Beispiel kann einen Premium-Benutzer beinhalten, der die bestmögliche Latenz möchte und für diesen Zugriff in seiner UE-SIM bezahlt, die mit seiner UEC-SLA verbunden ist.
  • 24 veranschaulicht zusätzliche Informationen einer UEC-Datenstruktur zum Koordinieren von Satelliten-Roaming-Aktivität, wobei zusätzliche Einzelheiten für den vorstehend behandelten UEC 2340 bereitgestellt werden. Es versteht sich, dass die folgenden Datenfelder oder Eigenschaften zu Veranschaulichungszwecken bereitgestellt sind und dass auch zusätzliche oder ersetzende Datenfelder verwendet werden können.
  • Der UEC 2340 ist als Informationen gespeichert, die für einen Benutzerkontext für Edge-Computing relevant sind, einschließlich Benutzerberechtigungsnachweisen 2431, Orchestratorinformationen 2432, SLA-Informationen 2433, Dienstgüteziel- (SLO-) Informationen 2434, Arbeitslastinformationen 2435 und Benutzerdatenpoolinformationen 2436. In einem Beispiel ist die SLA an Roaming-Vereinbarungsinformationen 2437, LEO-Zugriffsinformationen 2438 und LEO-Rechnungserstellungsinformationen 2439 gebunden.
  • In einem weiteren Beispiel können die Roaming-Vereinbarungsinformationen 2437 zudem einen Benutzer-Nationalitäts-Kontext 2441, eine Handelsvereinbarungs- oder Vertragsinformationen 2442, politische Geofence-Richtlinieninformationen 2443 und Steuerinformationen (wie etwa in Bezug auf eine Mehrwertsteuersteuer (VAT) oder Gebühren) 2444 beinhalten oder mit diesen assoziiert sein. Mit einer Implementierung des UEC 2340 wird ein Geofence logisch so angewendet, dass existierende Verträge und geopolitische Richtlinien angewendet werden können.
  • Der UEC ist eine Datenstruktur 2340, die unabhängig von einer aktuell ausgeführten Arbeitslast existiert. Nichtsdestotrotz gibt es eine Bindungsphase 2420, die auf dem UEC 2340 beruht, um Ressourcen in Vorbereitung für eine bestimmte Arbeitslastausführung zuzuteilen oder zuzuweisen.
  • Beispielsweise sei ein Szenario betrachtet, bei dem eine assoziierte SLA 2433 Kontext über eine Steuerpflicht für ein gegebenes Anbieternetzwerk enthält. Die Roaming-Vereinbarung stellt zusätzlichen Kontext bereit, bei dem ein internationaler Vertrag oder eine Vereinbarung Mehrwertsteuern beinhalten kann. Der UEC 2340 beinhaltet Bezugnahmen auf anwendbare Geofence- und Mehrwertsteuer-Kontexte, so dass eine Roaming-Vereinbarung zwischen LEO-Satelliten aus verschiedenen Anbieternetzwerken zusammenwirken kann, um ein besseres (hochverfügbares) Benutzererlebnis zu liefern.
  • In weiteren Beispielen kann ein UEC Mehrwert innerhalb eines einzigen Anbieternetzwerks hinzufügen. In einem einzigen Anbieternetzwerk kann der UEC 2340 zusätzlichen Kontext zum Anwenden von Geofence-Richtlinien bereitstellen, die an das Ursprungsland, Nationalität, Handelsvereinbarungen, Steuerraten usw. gebunden sind. Ein einzelnes Anbieternetzwerk könnte Arbeitslaststatistiken in Bezug auf die verschiedenen Aspekte der Arbeitslastausführung bereitstellen, um Optimierungen zu identifizieren, wo Berechnung, Daten, Leistung, Latenz usw. möglich sind. Der Anbieter kann Raumkoordinaten anderer LEO-Satelliten in seinem Netzwerk modifizieren, um sich als eine Möglichkeit zum besseren Lastausgleich, verbesserter Verfügbarkeit und Resilienz oder zur Kapazitätenerhöhung mit einem Peer-Satelliten zu koppeln.
  • In weiteren Beispielen können die Daten der SLA 2433 des UEC 2340 verwendet werden, um einen Prioritätsfaktor zu erfassen. Beispielsweise helfen in einem Szenario, bei dem ein UE (Vorrichtung) eine Sichtlinie aufweist und auf mehrere terrestrische und nicht-terrestrische Netzwerke zugreifen darf, vorbestimmte Faktoren dem UE dabei, zu priorisieren, welches Netzwerk auszuwählen ist. Ein terrestrisches Telco-Netzwerk, in dem sich das UE befindet, kann eine erste Priorität aufweisen, und dann möglicherweise lizenzierte Satellitennetzwerkoptionen. Einige Satellitenteilnehmer können für einen Premiumdienst bezahlen, wohingegen andere nur Standarddatenratenpläne haben können, die mit ihrem UE verbunden sind. Die UE-SIM-Karte kann diese Priorität bereitstellen und mit dem UEC 2340 hinsichtlich der SLA-Priorität arbeiten. Bei einem derartigen Beispiel wird der Benutzerkontext in der SIM gespeichert, anstatt in einer zentralen Datenbank gespeichert zu werden, und der Edge-Knoten/Orchestrator kann direkt auf die SIM zugreifen, anstatt einen Kanal in ein Backend-Repository zu öffnen, um eine Arbeitslast zu verarbeiten.
  • Wie vorstehend angemerkt, kann ein anderes Beispiel sein, dass ein Premium-Benutzer die bestmögliche Latenz, ähnlich oder besser als terrestrische Faser, über das Satellitennetzwerk wünscht. Der Benutzer kann für diesen Zugriff bezahlen und diesen in seiner UE-SIM-Karte angeben, die mit seiner UEC-SLA verbunden ist. Die im Raum erwarteten Geschwindigkeiten können schneller sein als manche terrestrischen Netzwerke, sogar Glasfasernetzwerke, sodass die Verwendung des UEC 2440 eine schnellste Verbindung mit einer niedrigsten Latenz für Punkt-zu-Punkt bereitstellen kann (z.B. wenn Datenverbindungen zu Orten auf gegenüberliegenden Seiten der Erde hergestellt werden). Für diese und andere Szenarien kann die SLA 2433 so angepasst werden, dass sie eine bevorzugte Reihenfolge verfügbarer Netzwerke beinhaltet.
  • 25 veranschaulicht ein Flussdiagramm 2500 eines Verfahrens zum Verwenden eines Benutzer-Edge-Kontexts zum Koordinieren von Satelliten-Roaming-Aktivität. Die Operationen dieses Verfahrens können durch Operationen an Endbenutzervorrichtungen, Satellitenkonstellationen, Dienstanbietern und Netzwerkorchestratoren in Übereinstimmung mit den vorstehend bereitgestellten Beispielen durchgeführt werden.
  • In Operation 2510 wird auf einen Benutzer-Edge-Kontext zur Verwendung in einer Satellitenkommunikationsnetzwerkanordnung zugegriffen (oder dieser neu definiert). Dieser Benutzer-Edge-Kontext kann die unter Bezugnahme auf 23 und 24 beschriebenen Datenmerkmale und Eigenschaften beinhalten. In Operation 2520 wird dieser Benutzer-Edge-Kontext an einen ersten Dienstanbieter eines Satellitennetzwerks (z.B. einer Satellitenkonstellation) kommuniziert, wodurch der Endbenutzervorrichtung ermöglicht wird, Netzwerkoperationen durchzuführen, die mit dem abgerufenen oder definierten Kontext konsistent sind.
  • In Operation 2530 wird ein Roaming-Szenario angetroffen und identifiziert, und Informationen über verfügbare Dienstanbieter für Roaming werden ferner identifiziert. In einem Beispiel beinhaltet das Roaming-Szenario eine erste Satellitenkonstellation, die sich aus dem Bereich eines geografischen Gebiets bewegt, das die Endbenutzervorrichtung beinhaltet, und eine zweite Satellitenkonstellation, die sich in den Bereich der Endbenutzervorrichtung bewegt. Andere Szenarien (die Dienstunterbrechungen, Zugriff auf spezifische oder hochwertige Dienste, Präferenzen oder SLA-Überlegungen beinhalten) können ebenfalls Roaming verursachen.
  • In Operation 2540 wird ein zweiter Dienstanbieter (z.B. eine andere Satellitenkonstellation) basierend auf den Informationen im Benutzer-Edge-Kontext ausgewählt, um Satellitennetzwerkoperationen in einer Roaming-Anordnung fortzusetzen. In Operation 2550 wird der Benutzer-Edge-Kontext an den zweiten Dienstanbieter kommuniziert, und Netzwerkoperationen werden gemäß den Informationen im Benutzer-Edge-Kontext gestartet oder fortgesetzt.
  • Intemet-der-Dinge-Drone-Satellit-Kommunikationsarchitekturen
  • In bestimmten Anwendungsfällen kann ein Endbenutzer daran interessiert sein, Vorrichtungen zum Überwachen entfernter Bereiche auf Änderungen in der Umgebung zu verwenden oder sich mit solchen Vorrichtungen zum Bereitstellen einer Statusaktualisierung oder sogar von Softwarepatches zu verbinden. Die Verwendung von Satellitenkonnektivität ermöglicht eine robuste Verbesserung der Verwendung von IoT-Vorrichtungen und Endpunkten, die in solchen Fern-Anordnungen eingesetzt werden.
  • 26 veranschaulicht eine beispielhafte Verwendung von Satellitenkommunikationen in einer IoT- (Internet der Dinge) Umgebung. Diese Figur veranschaulicht eine Ölpipeline 2600, die in einer entfernten Umgebung über eine lange Distanz verläuft. Die Pipeline 2600 ist mit mehreren Sensoren (Sensoren S0-S5) ausgestattet, um ihren Zustand zu überwachen. Dies können physische Sensoren sein, die an der Pipeline angebracht sind, eine Kamera, die die Umgebung beobachtet, oder eine Kombination von Sensortechnologien. Diese Sensoren werden häufig mit einer hohen Rate an der Pipeline bereitgestellt. Zudem könnte der Bediener alle paar Meilen entscheiden, eine komplexere Überwachungsstation einzusetzen. Die Sensoren in der Pipeline weisen keine dedizierte Netzwerkkonnektivität auf, sondern nehmen ständig Daten ab. Die Sensoren (oder die Überwachungsstationen) können die Daten lokal zwischenspeichern und sogar eine Analyse durchführen, die vorhersagen kann, wann eine Wartung erforderlich ist.
  • 26 zeigt ferner die Platzierung der Sensoren S0 bis S5. In dieser Anordnung gibt es ein 5G/4G-Funkzugangsnetz 2610, in dem Informationen und Analysen an Sensordaten mit Edge-Computing durchgeführt werden. Hierbei werden durch die Sensoren gesammelte Daten in Analysen eingespeist, die einen Fehler detektieren und vorhersagen können. Beispielsweise kann ein Algorithmus zum Detektieren eines Pipeline-Ausfalls Sensordaten überwachen, die den Ölfluss in der Pipeline angeben. Allerdings ist die Flussrate zusätzlich zu anderen Faktoren wie etwa Wetterbedingungen wichtig für die Ausfallvorhersage. Extreme Wetterbedingungen, die in der Vergangenheit beobachtet wurden und für die Zukunft vorhergesagt werden, können eine wesentliche Rolle bei der Bestimmung spielen, wann die nächste Wartung stattfinden muss.
  • In einem Beispiel kann eine Drohne 2620, ein Ballon 2625 oder ein anderes unbemanntes Luftfahrzeug (UAV) mit Daten ausgestattet sein, die direkt über den Satelliten 2630 (oder das Satellitenfunkzugangsnetz 2630 über das Funkzugangsnetz 2610) erhalten werden, wie etwa eine Karte, die die Standorte der Sensoren hervorhebt. Die Drohne 2620 oder der Ballon 2625 kann sich fortbewegen, um die Daten von den Sensoren zu sammeln und sie dann zurück an das Funkzugangsnetz 2610 zur Verarbeitung zu kommunizieren. Ferner kann das Satellitenfunkzugangsnetz 2630 die Informationen zu anderen nicht gezeigten Standorten weiterleiten.
  • In dem beispielhaften Pipeline-Überwachungsszenario können die Daten beliebige oder alle der Folgenden beinhalten:
    • (a) Zuvor an diesem Sensor oder anderen Sensoren gesammelte Daten, die relevant sind,
    • (b) Wetterprognosedaten oder beliebige Daten, die für die Analyse wesentlich sind;
    • (c) Algorithmusaktualisierungen, falls nötig (um z.B. eine Aktualisierung eines Algorithmus zu ermöglichen, der eine lokale Vorhersage erzeugen kann);
    • (d) Softwareaktualisierungen, die Sicherheitspatches beinhalten;
    • (e) Daten von anderen Sensoren, die die Drohne auf ihrem Weg sammelt und die für den Edge-Knoten relevant sein könnten.
  • Jeder der Sensoren kann zudem mit einem lokalen Edge-Knoten (der sich z.B. am Funkzugangsnetz 2610 befindet, nicht abgebildet) gekoppelt sein, der die folgenden Zuständigkeiten aufweist:
    • (a) lokales Sammeln und Zwischenspeichern von Daten von dem Sensor oder einer Sammlung von Sensoren;
    • (b) Durchführen von Analysen an den Daten, die von dem Sensor gesammelt werden, um den Zustand der Pipeline und die zukünftige Wartung zu bestimmen;
    • (c) Kommunizieren eines Analyseresultats an andere Sensoren in ihrer Nähe/ihrem Konnektivitätsbereich;
    • (d) Patchen der eigenen Software von einer Modellaktualisierung zu Sicherheitspatches.
  • Betreiber können auf Satellitenkommunikation zu dem Funkzugangsnetz 2610 zurückgreifen, um Software zu liefern, Daten zu sammeln und an der Edge erzeugte Einsichten zu überwachen. Zusätzlich kann ein weiteres Verarbeitungssystem (z.B. in der Cloud, verbunden über einen Backhaul mit dem Satelliten 2630) zudem vorhersagen, wann sich die Sensoren nicht mehr in Reichweite befinden werden, und dementsprechend eine Drohne mit detaillierter Kartierung aussenden, die ihre Route optimiert, um Daten (zum Beispiel Wettervorhersage), Softwareaktualisierungen (z.B. Modellaktualisierung, Sicherheitspatch, ...) zu liefern. Solche Informationen können mit den nachstehend erläuterten Ansätzen für informationszentrierte Vernetzung (ICN) oder Named Data Networking (NDN) koordiniert werden.
  • Die von der Drohne 2620 oder dem Ballon 2625 verwendete Route kann zudem dazu optimiert sein, Daten von Sensoren zu sammeln, die außerhalb des Bereichs liegen und deren Daten wesentlich sind, um eine Erkenntnis zu generieren. S2 liegt zum Beispiel außerhalb der Reichweite von S0, die bei S2 gesammelten Daten werden jedoch von S0 benötigt, um dessen Wartungsplan vorherzusagen. Die Drohne 2620 wählt dann eine Route aus, die sie in Reichweite von S2 bringt, wodurch Daten von diesem Knoten und seinen Sensoren gesammelt werden. Die Drohne würde dann zu S1 übergehen und die Daten, die von S2 gesammelt wurden, und jede zusätzliche Lieferung, die für S0 bestimmt ist, bereitstellen. Jeder der Edge-Knoten (z.B. die Edge-Knoten an den Sensoren S0-S4) bezieht eine dedizierte Speicherungsreservierung an der Drohne, die mit Schlüsseln zur Authentifizierung und einer Richtlinie geschützt ist, um zu bestimmen, welchem der anderen Edge-Knoten Zugriff zum Lesen und/oder Schreiben erlaubt ist.
  • Für diesen Verwendungsfall können die Analysen, die auf dem Mobilknoten (zum Beispiel einem UAV, wie etwa einer Drohne 2620 oder einem Ballon 2625) ausgeführt werden, auf Routenauswahl und Zuordnen von Datensammlung und Übertragung fokussiert sein. Dieser Mobilknoten hat jedoch möglicherweise keine ausreichende Rechenleistung, um eigene prädiktive Analysen auszuführen. In diesem Szenario würde das UAV den auszuführenden Algorithmus tragen, die Daten von dem Edge-Knoten/Sensor sammeln, den Algorithmus ausführen, eine Erkenntnis erzeugen und sie zurück an die Cloud übertragen (z.B. über den Satelliten 2630), wo Aktionen empfohlen und durchgeführt werden können.
  • In einem anderen Beispiel kann das UAV Daten zum Verarbeiten an einem Edge-Computing-Knoten sammeln, der sich am Funkzugangsnetz 2610 befindet. Ein UAV kann zum Beispiel EPVC-Kanäle in Abhängigkeit von der Kritikalität der Daten verwenden und ICN- oder NDN-Methoden verwenden, falls das UAV nicht weiß, wer die Daten verarbeiten kann. Andere Kombinationen von mobilen, Satelliten- und Edge-Computing-Ressourcen können basierend auf den vorliegend erörterten Methoden verteilt und koordiniert werden.
  • In weiteren Beispielen kann, anstatt Zustandserhaltungsmethoden zu verwenden, der folgende prädiktive Wartungsansatz durch die Sammlung von Vorrichtungs- und Sensordaten durch Satellitenverbindungen koordiniert werden. Somit können die Satellitenverbindungen (direkt oder über eine Drohne oder ein Zugangsnetz) trotz der Entfernungen bei Sensoreinsätzen verwendet werden, um Daten an einen prädiktiven Datenanalysedienst zu liefern, der dann proaktiv Dienstoperationen planen kann.
  • Eine Kombination des Koordinierens der Satellitenkommunikationen zusammen mit einer anhaltenden Datensammlung unterstützt die Überwachung neuer Kritikalitätsstufen für reale Objekte, die am Boden zu überwachen sind. Die Sammlung von Daten kann durch eine Datenaggregationsvorrichtung, ein Gateway, eine Basisstation oder einen Zugangspunkt koordiniert werden. Gleichermaßen kann der Satellitennetzwerktyp eine oder mehrere Satellitenkonstellationen (und möglicherweise einen oder mehrere Cloud-Dienstanbieter, Dienste oder Plattformen, auf die über solche Konstellationen zugegriffen wird) beinhalten.
  • Auch in weiteren Beispielen kann Kritikalität über die IoT-Überwachungsdatenarchitektur identifiziert werden. Beispielsweise sei angenommen, dass ein Überwachungsdatenwert identifiziert wird, der kritisch ist und der erfordert, dass eine bestimmte Aktion oder weitere Verarbeitung erfolgt. Diese Kritikalität kann mit der Position oder Verfügbarkeit eines Satellitennetzwerks oder einer Konstellation korreliert werden, und welche Typen von Netzwerkzugang verfügbar sind. Falls eine kritische Aktion unternommen werden muss (wie etwa Kommunizieren wichtiger Datenwerte), dann können diese Aktionen gleichermaßen für den nächsten Zeitraum, in dem ein relevanter Satellit in die Abdeckung eintritt, priorisiert werden.
  • In weiteren Beispielen können ein UAV und andere assoziierte Fahrzeug- oder Mobilsysteme zudem in Verbindung mit prädiktiven Überwachungstechniken koordiniert werden. Ein Computersystem, das prädiktive Analysen und prädiktive Wartung ausführt, kann an der Drohne koordiniert oder betrieben werden, da eine Drohne Konnektivität sowie Rechenfähigkeiten bringen kann. Ebenso können die Drohnen direkt selbst mit Satelliten verbunden sein.
  • Die Konnektivität zwischen Sensoren, Drohnen, Basisstationen und Satelliten kann mit mehreren Verarbeitungsebenen und verschiedenen Formen von Verarbeitungsalgorithmen koordiniert werden. Beispielsweise sei angenommen, dass ein Sensor identifiziert hat, dass etwas nicht stimmt, aber nicht über ausreichend Rechenleistung oder die richtigen Algorithmen verfügt, um die nächste Verarbeitungsstufe zu erledigen. Dieser Sensor kann die Ressourcen verwenden, die er hat (wie etwa eine Kamera), um Daten zu erfassen, und diese Daten an eine zentrale Ressource kommunizieren, wenn ein Satellit für Konnektivität verfügbar ist. Jede dieser Konnektivitätspermutationen kann an eine Dienstgüte gebunden sein, die innerhalb eines Satellitenkommunikationsnetzwerks angeboten und verwaltet wird. Als ein ähnliches Beispiel können in Reaktion auf eine Sensorfehlfunktion Satellitenkommunikationen verwendet werden, um einen neuen Algorithmus bereitzustellen. (Selbst wenn der neue Algorithmus nicht so hochgenau ist wie der vorherige, kann der neue Algorithmus tolerant gegenüber dem Fehlen des ausgefallenen Sensors sein).
  • 27 veranschaulicht ein Flussdiagramm 2700 eines Verfahrens zum Sammeln und Verarbeiten von Daten mit einer IoT- und Satellitennetzwerkbereitstellung. Hier kann eine Abfolge von Operationen basierend auf der Art von Rechenoperation, verfügbaren Netzwerkkonfigurationen und Überlegungen zu Konnektivität und Latenz durchgeführt werden.
  • In Operation 2710 werden Operationen durchgeführt, um Daten unter Verwendung von Edge-Computing-Hardware an einem Endpunkt-Rechenknoten (der sich z.B. an einer IoT-Vorrichtung befindet) zu sammeln, zu verarbeiten und weiterzuleiten. In Operation 2720 werden Operationen durchgeführt, um Daten unter Verwendung von Edge-Computing-Hardware an einem mobilen Rechenknoten zu sammeln, zu verarbeiten und weiterzuleiten, beispielsweise mit einer Drohne, die einer IoT-Vorrichtung bereitgestellt wird. Bei Operation 2730 werden Operationen durchgeführt, um Daten unter Verwendung eines terrestrischen Netzwerks und eines assoziierten Edge-Rechenknotens, wie etwa an einem 5G-RAN, das über einen Satelliten-Backhaul verbunden ist, zu sammeln, zu verarbeiten und weiterzuleiten.
  • In Operation 2740 werden Operationen durchgeführt, um Daten unter Verwendung eines Satellitennetzwerks und eines assoziierten Edge-Rechenknotens zu sammeln, zu verarbeiten und weiterzuleiten, sei es an dem Satelliten- oder dem terrestrischen Edge-Rechenknoten, der mit dem Satelliten-Link verbunden ist. In Operation 2750 werden Operationen durchgeführt, um Daten unter Verwendung eines Weitverkehrsnetzes und eines assoziierten Rechenknotens zu sammeln, zu verarbeiten und weiterzuleiten (z.B. zu einem Cloud-Computing-System).
  • Es versteht sich, dass andere Hardwarekonfigurationen und Architekturen zum Durchführen der vorstehend erörterten Operationen verwendet werden können. Beispielsweise arbeiten einige IoT-Vorrichtungen (wie etwa Zählermessung) an Best-Effort-Versuchen, wohingegen andere IoT-Vorrichtungen/-Sensoren zuverlässige Benachrichtigungen mit niedriger Latenz benötigen (z.B. ein Frachtcontainer-Feuchtigkeitssensor, der in Echtzeit überwacht wird, um Diebstahl anzugeben). Somit können in Abhängigkeit von der Hardware- und der Anwendungsfallanwendung auch andere Operationen und Verarbeitung erfolgen.
  • Beliebige dieser Operationen können mit der Verwendung von vorliegend erörterten EPVC-Kanälen und ICN/NDN-Vernetzungsmethoden koordiniert werden. Gemäß weiteren Aspekten können Ansätze für IoT-Vorrichtungs-Berechnung über Satellitennetzwerkkonnektivität unter Verwendung der folgenden beispielhaften Implementierungen koordiniert werden.
  • Beispiel D1 ist ein Verfahren zur Sensordatensammlung und -verarbeitung unter Verwendung eines Satellitenkommunikationsnetzes, umfassend: Beziehen von Erfassungsdaten bezüglich einer beobachteten Bedingung von einer Sensorvorrichtung, wobei die Erfassungsdaten einer Zwischenentität unter Verwendung eines terrestrischen Drahtloskommunikationsnetzwerks bereitgestellt werden; Bewirken, dass die Zwischenentität die Erfassungsdaten an einen Edge-Computing-Standort überträgt, wobei die Erfassungsdaten unter Verwendung eines nicht-terrestrischen Satellitenkommunikationsnetzwerks an den Edge-Computing-Standort kommuniziert werden; und Beziehen von Ergebnissen eines Verarbeitens der Erfassungsdaten von dem Edge-Computing-Standort über das nichtterrestrische Satellitenkommunikationsnetzwerk.
  • In Beispiel D2 beinhaltet der Gegenstand von Beispiel D1 wahlweise einen Gegenstand, bei dem die Zwischenentität Netzwerkkonnektivität an die Sensorvorrichtung über das terrestrische Drahtloskommunikationsnetzwerk bereitstellt.
  • In Beispiel D3 beinhaltet der Gegenstand von Beispiel D2 wahlweise einen Gegenstand, bei dem die Zwischenentität eine Basisstation, ein Zugangspunkt oder ein Netzwerk-Gateway ist und wobei die Zwischenentität Netzwerkfunktionen für einen Betrieb des terrestrischen Drahtloskommunikationsnetzwerks bereitstellt.
  • In Beispiel D4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D2 bis D3 wahlweise einen Gegenstand, bei dem die Zwischenentität eine Drohne ist.
  • In Beispiel D5 beinhaltet der Gegenstand nach Beispiel 4 wahlweise einen Gegenstand, bei dem die Drohne dazu konfiguriert ist, Netzwerkkommunikationen zwischen der Sensorvorrichtung und einem Zugangspunkt, der auf das Satellitenkommunikationsnetzwerk zugreift, bereitzustellen.
  • In Beispiel D6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D4 bis D5 wahlweise einen Gegenstand, bei dem die Drohne eine Kommunikationsschaltungsanordnung zum direkten Zugreifen auf das Satellitenkommunikationsnetzwerk und Kommunizieren mit diesem beinhaltet.
  • In Beispiel D7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D6 wahlweise einen Gegenstand, bei dem das terrestrische Drahtloskommunikationsnetzwerk durch ein 4G-Long-Term-Evolution- (LTE-) oder 5G-Netzwerk bereitgestellt wird, das gemäß einem 3GPP-Standard arbeitet.
  • In Beispiel D8 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D7 wahlweise einen Gegenstand, bei dem der Edge-Computing-Standort für Verarbeitung basierend auf einer Latenz von Kommunikationen über das Satellitenkommunikationsnetzwerk und einer Zeit, die zum Verarbeiten an dem Edge-Computing-Standort benötigt wird, identifiziert wird.
  • In Beispiel D9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D8 wahlweise einen Gegenstand, bei dem das Satellitenkommunikationsnetzwerk ein LEO-(Niedrigorbit-) Satellitenkommunikationsnetzwerk ist, das aus einer Konstellation einer Vielzahl von LEO-Satelliten bereitgestellt wird.
  • In Beispiel D10 beinhaltet der Gegenstand des Beispiels D9 wahlweise einen Gegenstand, bei dem der Edge-Computing-Standort unter Verwendung von Verarbeitungsschaltungsanordnungen bereitgestellt wird, die sich an einem LEO-Satellitenfahrzeug der Konstellation befinden.
  • In Beispiel D11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D9 bis D10 wahlweise einen Gegenstand, bei dem der Edge-Computing-Standort unter Verwendung jeweiliger Verarbeitungsschaltungsanordnungen bereitgestellt wird, die sich an mehreren LEO-Satellitenfahrzeugen der Konstellation befinden.
  • In Beispiel D12 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D9 bis D 11 wahlweise einen Gegenstand, bei dem der Edge-Computing-Standort unter Verwendung eines Verarbeitungsdienstes bereitgestellt wird, auf den über das LEO-Satellitenkommunikationsnetzwerk zugegriffen werden kann.
  • In Beispiel D13 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D12 wahlweise einen Gegenstand, bei dem das Verarbeiten der Erfassungsdaten Identifizieren von Datenanomalien basierend auf einem Betriebszustand eines durch die Sensorvorrichtung überwachten Systems umfasst.
  • In Beispiel D14 beinhaltet der Gegenstand von Beispiel D 13 wahlweise einen Gegenstand, bei dem das System ein Industriesystem ist, wobei die beobachtete Bedingung mindestens eine Umgebungs- oder Betriebscharakteristik des Industriesystems betrifft.
  • In Beispiel D15 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D13 bis D14 wahlweise Übertragen eines Wartungsbefehls zur Wartung des Systems in Reaktion auf die Ergebnisse des Verarbeitens der Erfassungsdaten.
  • In Beispiel D16 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D15 wahlweise einen Gegenstand, bei dem die Erfassungsdaten Bilddaten umfassen, wobei die Ergebnisse des Verarbeitens der Erfassungsdaten Nichtbilddaten umfassen, die an dem Edge-Computing-Standort erzeugt werden.
  • In Beispiel D17 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D16 wahlweise einen Gegenstand, bei dem die Erfassungsdaten von einer Sensoraggregationsvorrichtung bezogen und zwischengespeichert werden, wobei die Sensoraggregationsvorrichtung mit einer Vielzahl von Sensorvorrichtungen verbunden ist, die die Sensorvorrichtung enthält.
  • In Beispiel D18 beinhaltet der Gegenstand des Beispiels D 17 wahlweise einen Gegenstand, bei dem die Erfassungsdaten an der Sensoraggregationsvorrichtung aus Rohdaten aggregiert werden, wobei die Rohdaten aus der Vielzahl von Sensorvorrichtungen bezogen werden, die die Sensorvorrichtung enthält.
  • In Beispiel D19 beinhaltet der Gegenstand des Beispiels D18 wahlweise einen Gegenstand, bei dem die Sensoraggregationsvorrichtung mindestens einen Algorithmus auf die Rohdaten anwendet, um die Erfassungsdaten zu erzeugen.
  • In Beispiel D20 beinhaltet der Gegenstand eines oder mehrerer der Beispiele D1 bis D19 wahlweise einen Gegenstand, bei dem das Verfahren durch die Zwischenentität durchgeführt wird.
  • Koordination und Planung von Datentransfers über ephemere Satellitenverbindungen
  • Eine der Herausforderungen bei neuen Generationen sich bewegender Satellitenkonstellationen besteht darin, dass die Menge an Rechen- und Datenübertragungskapazität, die von solchen Konstellationen angeboten wird, von einem Geostandort abhängt, den sie abdecken. Ein Ende-zu-Ende-System, das viele LEO-Satelliten im Orbit beinhaltet, führt daher zu einem Mangel an voller Konnektivität und Verbindungen mit hoher Bandbreite über die gesamte Zeit. Infolgedessen müssen zwei primäre Typen von Datentransfers und -verarbeitung koordiniert werden: a) zwischen den Satelliten, die einen Cluster/eine Gruppierung/Konstellation bilden (z.B. um benötigten Datentransfer zu minimieren - wie etwa wenn zusammengefasste Informationen gesendet werden können, und um sicherzustellen, dass Daten nicht dupliziert werden); und b) zwischen einem Cluster von Satelliten und den Bodenstationen (um zu identifizieren, wann welche Satelliten welche Daten kommunizieren) unter Berücksichtigung der Möglichkeit eines Handoff an einen anderen Satelliten oder eine andere Bodenstation.
  • In diesen Szenarien können zwei unterschiedliche Entscheidungen für Dienstkontinuität berücksichtigt werden: (1) eine Entscheidung darüber, ob einige Rechenarbeit lokal durchgeführt werden soll (mit längerer Dauer und Verwendung spärlicher Ressourcen) oder ob gewartet werden soll, um die Daten zum Boden zu transferieren und Rechenarbeit während der Zeit, in der ein Satellit eine Zone überfliegt, „auszulagern“; und (2) eine Entscheidung darüber, wann der beste Moment ist, um Daten vom Satelliten zum Boden zu transferieren. Beide Entscheidungen werden von zumindest den folgenden Aspekten abhängen: einer Dauer des Abdeckens einer jeweiligen Zone mit Konnektivität; eines erwarteten Up- und Downlink in dieser Zone; mögliche Daten- oder Geo-Einschränkungen; und mögliche Bandbreitendynamik in Abhängigkeit vom Konnektivitätsanbieter.
  • Das Folgende stellt adaptive und intelligente Mechanismen bereit, um die vorherigen Punkte zu adressieren und eine intelligente Architektur bereitzustellen, um durchzuführende Aktionen zu antizipieren. Auch wenn ferner die Ressourcen auf den einzelnen Satelliten ressourcenbeschränkt sein könnten (z.B. eine begrenzte Anzahl von verfügbaren GPUs, Leistungsbudget usw.), können solche Ressourcen ferner berücksichtigt werden, wenn ein effizienter und holistischer Plan erzeugt wird. Es gibt keine aktuellen Satellitenkonnektivitätsansätze, die die dynamischen Aspekte des Datentransfers an Geostandorten mit Bindung an eine robuste Dienstqualität vollständig berücksichtigen. Darüber hinaus wurde der Kompromiss von Auslagerung gegenüber lokaler Berechnung bei sich bewegenden Satelliten nicht vollständig untersucht.
  • Um diese Aspekte zu adressieren, stellt das Folgende Planung und Koordination bereit - nicht nur für Daten- und Verbindungsverwaltung, Ressourcenzuteilung und Ressourcenverwaltung, sondern auch aus Sicht einer Verarbeitungsreihenfolge. Betrachtet sei beispielsweise ein Bodensteuer- und Satellitenverarbeitungssystem, das einen gemeinsamen Plan erzeugt, um zu bestimmen, a) wo nach einer Datenaktion zu suchen ist (z.B. Positionsbestimmung von Frachtschiffen), b) welche Art von Verarbeitung (z.B. Detektieren einer Anzahl von Frachtschiffen), und c) wie viel Bandbreite/Speicherressourcen/Verarbeitung erforderlich sind, um Daten zurückzusenden (z.B. selbst wenn Bilder analysiert werden, um nur die Anzahl von Frachtschiffen zu bestimmen).
  • 28 veranschaulicht ein beispielhaftes Satellitenkommunikationsszenario, das einen Plan für ephemere verbundene Vorrichtungen implementiert. Hier definiert ein Plan 2801 einen Zeitplan für Kommunikations- und Verarbeitungsaktionen zwischen verschiedenen Satelliten 2811, 2812, 2813. In diesem Beispielszenario besteht das Ziel darin, einen Satz von Containerschiffen im Hafen zu beobachten, um Kapazität zu bestimmen, jeden Orbit, in dem die Satelliten 2811, 2812, 2813 überfliegen (wenn auch in einem leicht unterschiedlichen Winkel); die Bilder zu verarbeiten; und zusammengefasste Informationen zurückzusenden (wie etwa die Anzahl der Schiffe, ob ein Objekt identifiziert wurde usw.). Jede Entität in den Ende-zu-Ende-Systemen verfolgt den Plan/Zeitplan 2801 und ihre Rolle bei der Verarbeitung und Datenkommunikation.
  • In einem Beispiel kann der Plan/Zeitplan 2801 Folgendes beinhalten: Welches Experiment oder welches Szenario durchzuführen ist (z.B. worauf basierend auf der aktuellen Trajektorie geschaut werden soll; welche Sensoren (Bild, Radar, ...) zu verwenden sind; usw.); welche Daten zu verarbeiten/zu speichern sind; was an welche andere Entität zu übertragen ist; und dergleichen. Randbedingungen des Plans können von den Entitäten auf einer Bedarfsbasis gemeinsam genutzt werden. Beispielsweise können Satelliten, die zu derselben Entität gehören, alle Planungsdetails gemeinsam nutzen; eine anonyme Beschreibung kann mit Satelliten oder Rechenknoten von anderen Dienstanbietern gemeinsam genutzt werden.
  • Die Verwendung eines Plans und eines Zeitplans unterstützt eine Verhandlung/gemeinsame Nutzung von Einschränkungen, um einen effizientesten übergreifenden Plan zu erhalten (einschließlich aus Perspektive einer Ressourcennutzung, monetärer Kosten, einer Investitionsrendite (return on investment, ROI) oder Gesamtbetriebskosten (total cost of ownership, TCO)). Somit kann der Plan/der Zeitplan selbstoptimiert oder durch eine Entität wie etwa die Bodenstation/den Betreiber bereitgestellt werden. Ferner können Elemente in dem Plan gemischte Kritikalität aufweisen, einige Elemente können unverrückbar/nicht verhandelbar sein, andere können nach bestem Bemühen eingesetzt werden (z.B. „Aktionen durchführen, wann immer möglich“). Es versteht sich, dass eine Verhandlung zwischen den verschiedenen Systemsatelliten, Bodenstationen, Kunden und anderen Entitäten, um den Plan zu entwickeln und die Nutzung des Plans zu terminieren, einen einzigartigen und robusten Ansatz bereitstellt, der herkömmliche Methoden zur Planung weit übersteigt. Insbesondere kann durch Berücksichtigen mehrerer Akteure ein globaler optimaler Plan entwickelt werden, selbst wenn minimale erforderliche Informationen gemeinsam genutzt werden und der Datenschutz unter Systemen geschützt wird.
  • Beispielhafte Einschränkungen in dem Plan/Zeitplan 2801, die für Satellitenkonnektivität und Betrieb relevant sind, können beinhalten:
    • a) Standortinformationen, beispielsweise zum Bestimmen oder Begrenzen, welche Experimente und Aufgaben möglich sind (oder ob die Aufgabe auf den nächsten Orbit warten muss).
    • b) Reihenfolge der Aufgaben
    • c) Hardware-Grenzen (z.B. GPU-Grenzen, die eine Unfähigkeit angeben, zwei Jobs gleichzeitig zu verarbeiten)
    • d) Beschränkung der Anzahl von Mandanten oder verschiedenen Kunden zur gleichen Zeit (z.B. für Datenschutz)
    • e) Fristen zum Durchführen von Datentransfers
    • f) Konnektivitätsbedingungen (wie etwa wenn ein Uplink/Downlink nicht verfügbar ist; Koordination zwischen verschiedenen Typen von LEO/GEOBoden-Netzwerken)
    • g) Koordination von Satelliten- oder Verarbeitungstechnologien, die zusammenarbeiten (z.B. Overlay-Radar (erhalten von einem GEO-Satelliten) mit thermischer Bildgebung (erhalten von einem LEO-Satelliten))
    • h) Ressourcenbeschränkungen (z.B. Leistungs-/Speicherungs-/Temperatur-/Rechenbeschränkungen).
    • i) Geofencing oder geografische Einschränkungen.
  • In weiteren Beispielen kann der Plan verwendet werden, um Rechen- oder Kommunikationsressourcen in den Satelliten in Abhängigkeit davon, welche Nutzung erwartet wird, vorab zu reservieren. Eine solche Reservierung kann auch von den Kosten abhängen, die in Abhängigkeit von der aktuellen Reservierung berechnet werden.
  • 29 veranschaulicht ein Flussdiagramm 2900 eines Verfahrens zum Definieren und Planen von Satellitennetzwerkrechenoperationen in einer Bereitstellung eines im Orbit befindlichen transienten Satellitenkommunikationsnetzwerks. Hier kann eine Abfolge von Operationen basierend auf der Art von Rechenoperation, verfügbaren Netzwerkkonfigurationen und Überlegungen zu Konnektivität und Latenz durchgeführt werden.
  • In Operation 2910 werden ein Plan und seine Planeinschränkungen für die Koordination von Datentransfer und -verarbeitung zwischen mehreren Entitäten definiert (oder bezogen). In Operation 2920 wird ein Datenversuch, eine Aktion oder ein anderes Szenario, das den koordinierten Datentransfer und die Verarbeitung beinhaltet, aufgerufen. Dies kann zum Beispiel eine Anfrage zum Initiieren einer Arbeitslastverarbeitungsaktion sein.
  • In Operation 2930 werden Daten zwischen Entitäten des Satellitenkommunikationsnetzwerks basierend auf dem Plan und den Planeinschränkungen übertragen. Ebenso werden in Operation 2940 Daten an einer oder mehreren ausgewählten Entitäten unter Verwendung von Edge-Computing-Ressourcen des Satellitenkommunikationsnetzwerks basierend auf dem Plan und den Planeinschränkungen verarbeitet.
  • Das Flussdiagramm 2900 endet bei Operation 2950 mit Übertragen des Datenverarbeitungsergebnisses an eine terrestrische Entität oder unter Entitäten des Satellitenkommunikationsnetzwerks. Verschiedene Aspekte von Handover-, Verarbeitungs- und Datentransferkoordination und -kommunikationen zwischen Satelliten, Konstellationen und Bodenentitäten sind nicht dargestellt, können aber ebenfalls an den Operationen des Flussdiagramms 2900 beteiligt sein.
  • Gemäß weiteren Aspekten können Ansätze zum Terminieren und Planen von Satellitennetzwerkrechenoperationen unter Verwendung der folgenden beispielhaften Implementierungen koordiniert und ausgeführt werden. Gemäß weiteren Aspekten können zudem andere Aspekte von Ressourcenaufwand, die nicht mit monetären Erwägungen zusammenhängen, berücksichtigt werden (wie Einschränkungen und Nutzung von Batterielebensdauer, Speicher, Speicherung, Verarbeitungsressourcen sowie anderen Ressourcen).
  • Beispiel E1 ist ein Verfahren zum Koordinieren von Rechenoperationen in einem Satellitenkommunikationsnetzwerk, umfassend: an einem Rechenknoten eines Satellitenkommunikationsnetzwerks erfolgendes Beziehen eines Koordinationsplans zum Durchführen von Rechen- und Kommunikationsoperationen innerhalb des Satellitenkommunikationsnetzwerks, Durchführen einer Rechenaktion an Daten in dem Satellitenkommunikationsnetzwerk basierend auf dem Koordinationsplan, wobei die Rechenaktion ein Datenverarbeitungsergebnis erhalten soll; Durchführen einer Kommunikationsaktion mit den Daten über das Satellitenkommunikationsnetzwerk basierend auf dem Koordinationungsplan; und Übertragen des Datenverarbeitungsergebnisses vom Satellitenkommunikationsnetzwerk an eine terrestrische Entität.
  • In Beispiel E2 beinhaltet der Gegenstand von Beispiel E1 wahlweise einen Gegenstand, bei dem der Koordinationsplan zum Durchführen von Rechen- und Kommunikationsoperationen eine Vielzahl von Einschränkungen beinhaltet, wobei sich die Vielzahl von Einschränkungen bezieht auf Standortinformationen; Reihenfolge von Aufgaben; Hardwarebeschränkungen; Nutzungseinschränkungen; Nutzungsfristen; Konnektivitätsbedingungen; Ressourceninformationen; Ressourceneinschränkungen; oder geografische Einschränkungen.
  • In Beispiel E3 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E2 wahlweise Reservieren von Rechenressourcen an dem Rechenknoten basierend auf dem Koordinationsplan.
  • In Beispiel E4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E3 wahlweise einen Gegenstand, bei dem der Koordinationsplan zum Durchführen von Rechen- und Kommunikationsoperationen innerhalb des Satellitenkommunikationsnetzwerks bewirkt, dass das Satellitenkommunikationsnetzwerk eine Vielzahl von Rechenressourcen in dem Satellitenkommunikationsnetzwerk zum Durchführen der Rechenaktion mit den Daten reserviert.
  • In Beispiel E5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E4 wahlweise einen Gegenstand, bei dem das Kommunizieren der Daten Kommunizieren der Daten an einen terrestrischen Verarbeitungsstandort beinhaltet, wobei das Durchführen einer Aktion mit den Daten Beziehen des Datenverarbeitungsergebnisses von dem terrestrischen Verarbeitungsstandort beinhaltet.
  • In Beispiel E6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E5 wahlweise einen Gegenstand, bei dem das Kommunizieren der Daten Kommunizieren der Daten zu anderen Knoten in dem Satellitenkommunikationsnetzwerk beinhaltet.
  • In Beispiel E7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E6 wahlweise Identifizieren eines Timings zum Durchführen der Rechenaktion basierend auf dem Koordinationsplan.
  • In Beispiel E8 beinhaltet der Gegenstand des Beispiels E7 wahlweise einen Gegenstand, bei dem das Timing zum Durchführen der Rechenaktion auf einer Koordination von Verarbeitung zwischen einer Vielzahl von Satellitenknoten in einer Konstellation des Satellitenkommunikationsnetzwerks basiert.
  • In Beispiel E9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E8 wahlweise basierend auf dem Koordinationsplan erfolgendes Identifizieren eines Timings zum Übertragen des Datenverarbeitungsergebnisses von dem Satellitenkommunikationsnetzwerk an die terrestrische Entität.
  • In Beispiel E10 beinhaltet der Gegenstand des Beispiels E9 wahlweise einen Gegenstand, bei dem das Timing zum Übertragen des Datenverarbeitungsergebnisses auf einer Koordination von Verarbeitung unter einer Vielzahl von Satellitenknoten in einer Konstellation des Satellitenkommunikationsnetzwerks basiert.
  • In Beispiel E11 beinhaltet Gegenstand eines oder mehrerer der Beispiele E1 bis E10 wahlweise einen Gegenstand, bei dem ein Timing des Durchführens der Rechenaktion und ein Timing zum Übertragen des Datenverarbeitungsergebnisses auf Orbit-Positionen eines oder mehrerer Satellitenfahrzeuge des Satellitenkommunikationsnetzwerks basieren.
  • In Beispiel E12 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E11 wahlweise einen Gegenstand, bei dem der Koordinationsplan bewirkt, dass das Satellitenkommunikationsnetzwerk die Verarbeitung der Daten von einem ersten Rechenknoten an einen zweiten Rechenknoten abgibt, auf den innerhalb des Satellitenkommunikationsnetzwerks zugegriffen werden kann.
  • In Beispiel 13 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E12 wahlweise einen Gegenstand, bei dem die Rechenaktion an den Daten basierend auf Ressourcenverfügbarkeit innerhalb des Satellitenkommunikationsnetzwerks oder eines mit dem Satellitenkommunikationsnetzwerk verbundenen Netzwerks durchgeführt wird.
  • In Beispiel E14 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E13 wahlweise einen Gegenstand, bei dem die Kommunikationsaktion basierend auf Verbindungsverfügbarkeit innerhalb des Satellitenkommunikationsnetzwerks oder eines Netzwerks, das mit dem Satellitenkommunikationsnetzwerk verbunden ist, ausgeführt wird.
  • In Beispiel E15 beinhaltet der Gegenstand eines oder mehrerer der Beispiele E1 bis E14 wahlweise einen Gegenstand, bei dem die terrestrische Entität eine Client-Vorrichtung, ein terrestrischer Edge-Rechenknoten, ein terrestrischer Cloud-Computing-Knoten, ein anderer Rechenknoten einer Konstellation in dem Satellitenkommunikationsnetzwerk oder ein Rechenknoten einer anderen Satellitenkonstellation ist.
  • Satelliten- und Edge-Dienst-Orchestrierung basierend auf Datenkosten
  • Neue Digitaldienststeuern (Digital Services Taxes, DST), die von der Organisation für wirtschaftliche Zusammenarbeit und Entwicklung (OECD) und der Europäischen Kommission vorgeschlagen und implementiert werden, wurden definiert, um Dienste zu besteuern, die Daten verwenden, die aus Benutzeraktivitäten auf digitalen Plattformen von einem bestimmten Land erzeugt werden, die dann in anderen Ländern verwendet werden. Eine solche Steuer gilt zum Beispiel für Daten, die von Benutzern eines Dienstes in Frankreich gesammelt werden (z.B. Benutzerbindungsdaten), die dabei helfen, bessere Empfehlungen für Benutzer mit ähnlichem Profil in einem anderen Land bereitzustellen (z.B. für Video- oder Musikempfehlungen). Dies führt zu einem klaren Problem im Kontext von Satellitenkonnektivitätsnetzwerken: Jedes Land hat einen eigenen Steuersatz, daher ist es aus einer ökonomischen Perspektive wichtig, in der Lage zu sein, die geeignetsten für Dienste auszuwählen, die von einer Satelliteninfrastruktur bereitgestellt werden, die mehr geografische Abdeckung aufweist als herkömmliche statische Infrastrukturen.
  • Gleichermaßen muss Edge-Computing zunehmend sowohl mit der Mobilität von Datenproduzenten als auch mit der Mobilität von Datenkonsumenten umgehen, während zudem Caching, Sichern, Filtern, Umwandeln von Daten „on the fly“ und dynamisches Refaktorieren von Ressourcen und Diensten mobiler Produzenten zu berücksichtigen ist. Dies gilt insbesondere für Inhalte und Dienste, die an Satelliten sowohl in LEO/NEO- als auch GEO-Orbits gehostet/zwischengespeichert werden. Dementsprechend können mit den nachstehenden Methoden Datenkosten als zusätzliche Variable verwendet werden, während Dienste über Satellitenverbindungen orchestriert werden.
  • Basierend auf einer Ressourcennutzung, die an Geldkosten gebunden ist, und unter Berücksichtigung, dass die Satelliten die gesamte Zeit über mehrere geografische Standorte hinweg wandern, kann ein Dienstschema definiert werden, um Dienste, bei denen weniger Steuern oder Dienstgebühren anfallen, für jeden spezifischen Standort zu verwenden. Dienste, die spezifische Benutzerdatensätze verwenden, werden mit ihrem Standort und ihren Kosten gekennzeichnet, um die beste oder effektivste Option zu bestimmen, falls mehrere Dienste vorhanden sind, die denselben Dienst anbieten. Somit können Datenkonsumenten, Benutzer und Dienstanbieter Kompromisse zwischen Kosten, Dienstgüte usw. evaluieren, während sie Datenbesteuerungs- oder andere Kostenanforderungen erfüllen.
  • In einem Beispiel werden neue Komponenten zu LEO-Satelliten und Bodenstationen (z.B. Basisstationen) hinzugefügt, um einen neuen Typ von geo-bewussten Orchestrierungsrichtlinien zu implementieren. Dies beinhaltet eine Konfiguration des Systems, um die Aufnahme von Standort- und Datenkosten als neue Tags als Teil der Metadaten eines Dienstes zu ermöglichen, um kommerziell vorteilhafte Dienste, die in LEO-Satelliten laufen, unter Berücksichtigung ihrer geografischen Positionen zu identifizieren. Beispielsweise kann ein Systemorchestrator, der auf Bodenstationen läuft, diese Konfiguration verwenden, um einen optimalen Dienst unter Berücksichtigung finanzieller Kosten als Schlüsselelement auszuwählen, aber auch die Faktoren zu berücksichtigen, die für die Orchestrierung von Satelliten (z.B. Telemetrie, SLAs, Transferzeit, sichtbare Zeit, Verarbeitungszeit) erforderlich sind. Falls erwartet wird, dass ein kostengünstigerer Dienst (z.B. mit geringerer Steuer) in einem nächsten bevorstehenden Satelliten verfügbar wird (in Kürze in Reichweite; z.B. in 5 Minuten), und dieser nächste billigere Dienst eine SLA erfüllt, wartet der Orchestrator, um den nächsten Satelliten zu verwenden.
  • Ein einfaches Beispiel für einen nach Kosten ausgewählten Dienst ist ein CDN-Dienst, der Daten von spezifischen geografischen Ursprüngen anbietet, die mit bekannten Datenkosten und bekanntem Steuersatz assoziiert sind. Andere Arten von Datenarbeitslastverarbeitungsdiensten, Cloud-Diensten und interaktivem Datenaustausch können zwischen einem Datenkonsumenten und einem Datenanbieter auftreten. Dies ist mit dem beispielhaften Satellitenkommunikationsszenario aus 30 gezeigt, das eine Bodenstation GS1 3020 beinhaltet, die entscheidet, für Netzwerkkonnektivitäts-, Dateninhalts- oder Datenverarbeitungszwecke auf einen der Satelliten L1 3011, L2 3012, L3 3013 zuzugreifen.
  • In einem Beispielszenario sei angenommen, dass GS1 3020, die sich in Frankreich befindet, die Verwendung von Dienst A und B erfordert, und eine Verwendung des Dienstes in 5 Minuten erreichen muss (um eine SLA zu erfüllen). Ein Orchestrator (an der Bodenstation oder einer Steuereinheit der Bodenstation) evaluiert Satelliten, die sich während der maximal verfügbaren Zeit (5 Minuten) in Reichweite befinden, wie in der Evaluierungstabelle 3030 veranschaulicht. In dieser Situation sind die Satelliten L1 3011 und L2 3012 in den nächsten fünf Minuten die einzigen Satelliten in Reichweite und auch in der Lage, die Dienstanforderung zu erfüllen.
  • Danach wird eine Evaluierung der folgenden Dienste und Optionen unter Berücksichtigung der Kosten durchgeführt:
    • Option 1: L1 Dienst A + L1 Dienst B: $20; Zeit: - 2 sek
    • Option 2: L1 Dienst A + L2 Dienst B: $15; Zeit: ~3 min 49 sek
    • Option 3: L2 Dienst A + L1 Dienst B: $30; Zeit: ~3 min 49 sek
    • Option 4: L2 Dienst A + L2 Dienst B: $25; Zeit: ~3 min 49 sek
  • Aus dieser Evaluierung wird Konnektivität über die Option 2 (L 1 Dienst A und L2 Dienst B) ausgewählt, was niedrigste Kosten über die Verwendung mehrerer Satelliten und Dienste hinweg liefert. (Hinweis: Steuern werden häufig aus dem Gesamtumsatz berechnet, sind in der obigen Tabelle jedoch zur Vereinfachung als ein Betrag pro Transaktion dargestellt).
  • Ein Katalogdienst, der auf der Satelliten-Edge ausgeführt wird, wird eine neue API zum Empfangen von Aktualisierungen über Metadaten der Dienste einbeziehen. Für solche Aktualisierungen können Inter-Satelliten-Links verwendet werden, da Satelliten Aktualisierungen (Deltas) ankündigen, sodass Bodenstationen über diese Informationen vefügen können, bevor sich der Satellit in Reichweite befindet. Zusätzlich, und falls dies durch die SLA erlaubt wird, kann es möglich sein, Verarbeitungsaktionen an spezifische Standorte von Bodenstationen, wie etwa Stationen mit mehr Rechenleistung und niedrigeren Kosten, zu übertragen oder zu übergeben. Der Zugang zu solchen Bodenstationen und die Ergebnisse solcher Bodenstationen können durch einen beliebigen verfügbaren LEO-Satelliten transportiert werden, der sich gerade im Überflug befindet.
  • 31 stellt das Framework aus 16 dar, das zur Verwendung mit der vorliegend offenbarten Kostenbewertung erweitert wird. In einem Beispiel sind die Boden-Edge-Komponenten 1610 so erweitert, dass sie einen Dienstorchestrator 3111, eine Dienstplanungskomponente 3112 und eine Secure Enclave 3121 beinhalten. Am Dienstorchestrator 3111 empfängt jede Bodenstation 1610 kontinuierlich Informationen von Satelliten (z.B. Dienstinformationen, die in einem Dienstkatalog 3131 verwaltet werden, und Dienstnutzungsinformationen, die in einem Dienstverwendungsmetrik-Datenspeicher 3132 verwaltet werden), die erforderlich sind, um Dienste zu orchestrieren und Entscheidungen zu treffen, um die optimalen Ressourcenkosten (zum Beispiel monetäre Kosten) für das Zugreifen auf Dienste zu identifizieren. Der Dienstorchestrator 3111 kann die Nutzung von Diensten in Abhängigkeit von Standorten und verfügbarer Kapazität temporär aktivieren, deaktivieren oder anpassen. Die Dienstplanungskomponente 3112 stellt ein Hilfsmodul bereit, das API-Gateway-Konfigurationen erzeugt, die erforderlich sind, um eine Abbildung von Diensten pro Standort bereitzustellen (z.B. basierend auf Orchestrator-Analyse).
  • Die Secure Enclave 3121 ist zum Schutz sensibler oder privater Finanzinformationen konfiguriert. In einem Beispiel wird die Secure Enclave 3121 möglicherweise nicht durch einen Softwarestapel verwaltet, sondern wird nur durch autorisiertes Personal verwaltet oder zugänglich.
  • In einem Beispiel beinhalten die Satelliten-Edge-Komponenten 1620 ein API-Gateway 3124, das die Ausführung von Arbeitslasten 3125 verwaltet und zudem eine Abstraktion an Dienste basierend auf dem Standort bereitstellt. Dieses Gateway empfängt den Standort als ein Argument und gibt das Ergebnis des Dienstes mit reduzierten Ressourcenkosten (z.B. monetäre Kosten) zurück. Dies wird basierend auf der Konfiguration durchgeführt, die durch die Dienstplanungskomponente 3112 bereitgestellt wird, die von Edge-Vorrichtungen aufgerufen wird. Dieses Modul kann vom lokalen API-Cache 3126 abgedeckt werden. Die Satelliten-Edge-Komponenten 1620 beinhalten zudem eine Datenteilung 3121 zwischen Satelliten, die verwendet wird, um den Dienstkatalog 3122 an jedem Satelliten aktuell zu halten (etwa durch Übertragung von Daten-Delta-Änderungen) und Dienstnutzungsmetriken 3123 zu füllen.
  • 32 veranschaulicht ein Flussdiagramm 3200 eines Verfahrens zum Durchführen von Rechenoperationen in einer Satellitennetzwerkbereitstellung basierend auf Kosten. Hierbei kann eine Abfolge von Operationen mit im Orbit kreisenden Satelliten basierend auf der Art von Edge-Computing-Operation, Gesamt-Ende-zu-Ende-Dienstkosten, Dienstnutzungsbeschränkungen oder -Einschränkungen und Erwägungen zu Dienstgütezielsetzungen koordiniert werden.
  • In Operation 3210 werden verschiedene Aspekte von Dienstbedarfs- und Dienstnutzungsbedingungen in Verbindung mit möglichem Bedarf und Nutzung eines Satellitenkommunikationsnetzwerks (z.B. durch eine terrestrische Benutzergerätvorrichtung) identifiziert. Aus solchen Dienstbedarfs- und Dienstnutzungsbedingungen beinhaltet die Operation 3220 Identifizieren der Verfügbarkeit eines oder mehrerer Satellitennetzwerke, um einen oder mehrere Dienste bereitzustellen, die die Dienstnutzungsbedingungen erfüllen.
  • In Operation 3230 werden die mit einem oder mehreren verfügbaren Diensten von einem oder mehreren verfügbaren Satellitennetzwerken assoziierten Kosten identifiziert. Wie vorstehend angemerkt, kann dies eine Aufschlüsselung derartiger Kosten basierend auf geografischer Jurisdiktion, Zeit, Dienstanbieter, durchzuführenden Dienstaktionen usw. beinhalten. In Operation 3240 werden diese Informationen verwendet, um Kosten zum Erfüllen der Dienstanforderung zu berechnen.
  • In Operation 3250 werden ein oder mehrere Dienste zur Verwendung aus einem oder mehreren Satellitennetzwerken basierend auf berechneten Kosten und unter Berücksichtigung der verschiedenen Einschränkungen und Bedingungen ausgewählt. Zusätzliche Schritte, die zum Zwecke der Einfachheit nicht dargestellt sind, können Dienstorchestrierung, Berücksichtigung von Dienstnutzungsmetriken, Aufrufen eines Dienstkatalogs und von APIs und dergleichen umfassen.
  • Gemäß weiteren Aspekten können Ansätze für IoT-Vorrichtungs-Berechnung über Satellitennetzwerkkonnektivität unter Verwendung der folgenden beispielhaften Implementierungen koordiniert werden.
  • Beispiel F 1 ist ein Verfahren zum Orchestrieren von Rechenoperationen in einem Satellitenkommunikationsnetzwerk basierend auf einem Ressourcenaufwand, umfassend: Identifizieren eines Bedarfs für einen Rechendienst; Identifizieren von Bedingungen zur Nutzung des Rechendienstes, die den Bedarf erfüllen; Identifizieren einer Vielzahl verfügbarer Rechendienste, die über das Satellitenkommunikationsnetzwerk zugänglich sind, wobei die verfügbaren Rechendienste identifiziert werden, um die Bedingungen zur Nutzung zu erfüllen; Berechnen des Ressourcenaufwands zur Nutzung der jeweiligen Dienste der verfügbaren Rechendienste; Auswählen eines der Vielzahl verfügbarer Rechendienste basierend auf dem Ressourcenaufwand, und Durchführen von Datenoperationen mit dem ausgewählten Rechendienst über das Satellitenkommunikationsnetzwerk.
  • In Beispiel F2 beinhaltet der Gegenstand des Beispiels F1 wahlweise Auswählen eines zweiten der Vielzahl verfügbarer Rechendienste basierend auf dem Ressourcenaufwand, und Durchführen von Datenoperationen mit dem zweiten ausgewählten Rechendienst über das Satellitenkommunikationsnetzwerk.
  • In Beispiel F3 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F2 wahlweise einen Gegenstand, bei dem die Bedingungen zur Nutzung des Rechendienstes Bedingungen betreffen, die von einer Dienstgütevereinbarung benötigt werden.
  • In Beispiel F4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F3 wahlweise einen Gegenstand, bei dem die Bedingungen zur Nutzung des Rechendienstes eine maximale Zeit zur Nutzung des Rechendienstes bereitstellen.
  • In Beispiel F5 beinhaltet der Gegenstand des Beispiels 4 wahlweise einen Gegenstand, bei dem die verfügbaren Rechendienste basierend auf Satellitendeckung an einem geografischen Standort innerhalb der maximalen Zeit zur Nutzung des Rechendienstes identifiziert werden.
  • In Beispiel F6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F5 wahlweise Empfangen von Informationen, die die Vielzahl verfügbarer Rechendienste identifizieren und zumindest einen Teil des Ressourcenaufwands zur Nutzung der jeweiligen Dienste identifizieren.
  • In Beispiel F7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F6 wahlweise einen Gegenstand, bei dem die Vielzahl verfügbarer Rechendienste unter mehreren Satelliten bereitgestellt werden.
  • In Beispiel F8 beinhaltet der Gegenstand von Beispiel F7 wahlweise einen Gegenstand, bei dem die mehreren Satelliten zwischen mehreren Satellitenkonstellationen betrieben werden, die unter mehreren Satellitenkommunikationsdienstanbietern bereitgestellt werden.
  • In Beispiel F9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F8 wahlweise Abbilden der verfügbaren Rechendienste auf jeweilige geografische Jurisdiktionen, wobei sich der Ressourcenaufwand auf monetäre Kosten bezieht und wobei die monetären Kosten auf den jeweiligen geografischen Jurisdiktionen basieren.
  • In Beispiel F10 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F9 wahlweise einen Gegenstand, bei dem die monetären Kosten basierend auf mindestens einer Digitaldienststeuer berechnet werden, die mit einer geografischen Jurisdiktion assoziiert ist.
  • In Beispiel F11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F10 wahlweise einen Gegenstand, bei dem der Rechendienst ein CDN- (content data network) Dienst ist, der über das Satellitenkommunikationsnetzwerk bereitgestellt wird, wobei der Ressourcenaufwand auf Daten basiert, die über den CDN-Dienst abgerufen werden sollen.
  • In Beispiel F12 beinhaltet der Gegenstand eines oder mehrerer der Beispiele F1 bis F11 wahlweise, dass das Verfahren durch einen Orchestrator, eine Basisstation oder eine Benutzervorrichtung durchgeführt wird, der/die mit dem Satellitenkommunikationsnetzwerk verbunden ist.
  • Übersicht über informationszentrierte Netzwerke (ICN) und Named Data Networking (NDN)
  • 33 veranschaulicht eine beispielhafte ICN-Konfiguration gemäß einem Beispiel. Mit ICN implementierte Netzwerke arbeiten anders als herkömmliche hostbasierte (z.B. adressbasierte) Kommunikationsnetzwerke. ICN ist ein Oberbegriff für ein Vernetzungsparadigma, bei dem Informationen und/oder Funktionen selbst benannt und vom Netzwerk anstelle von Hosts (z.B. Maschinen, die Informationen bereitstellen) angefordert werden. In einem hostbasierten Vernetzungsparadigma, wie es etwa im Internetprotokoll (IP) verwendet wird, lokalisiert eine Vorrichtung einen Host und fragt Inhalt von dem Host an. Das Netzwerk versteht, wie Pakete basierend auf der in dem Paket spezifizierten Adresse zu routen sind (z.B. direkt). Im Gegensatz dazu beinhaltet ICN keine Anfrage für eine bestimmte Maschine und verwendet keine Adressen. Stattdessen fragt eine Vorrichtung 3305 (z.B. Teilnehmer), um Inhalt zu erhalten, benannten Inhalt von dem Netzwerk selbst an. Die Inhaltsanfrage kann als ein Interesse bezeichnet werden und über ein Interessenpaket 3330 übertragen werden. Während das Interessenpaket Netzwerkvorrichtungen (z.B. Netzwerkelemente, Router, Switches, Hubs usw.) - wie etwa Netzwerkelemente 3310, 3315 und 3320 - durchläuft, wird eine Aufzeichnung des Interesses zum Beispiel in einer Tabelle anhängiger Interessen (PIT) an jedem Netzwerkelement geführt. Somit führt das Netzwerkelement 3310 einen Eintrag in seiner PIT 3335 für das Interessenpaket 3330, führt das Netzwerkelement 3315 den Eintrag in seiner PIT und führt das Netzwerkelement 3320 den Eintrag in seiner PIT.
  • Wenn eine Vorrichtung, wie etwa der Publisher 3340, angetroffen wird, die Inhalt aufweist, der mit dem Namen in dem Interessenpaket 3330 übereinstimmt, kann diese Vorrichtung 3340 ein Datenpaket 3345 als Antwort auf das Interessenpaket 3330 senden. Typischerweise wird das Datenpaket 3345 durch das Netzwerk zu der Quelle (z.B. Vorrichtung 3305) zurückverfolgt, indem den Spuren des Interessenpakets 3330 gefolgt wird, die in den Netzwerkelement-PITs verbleiben. Somit legt die PIT 3335 an jedem Netzwerkelement einen Pfad zurück zum Teilnehmer 3305 fest, dem das Datenpaket 3345 folgt.
  • Das Abgleichen der genannten Daten in einer ICN-Implementierung kann mehreren Strategien folgen. Im Allgemeinen werden die Daten hierarchisch benannt, wie etwa mit einer universellen Ressourcenkennung (URI). Zum Beispiel kann ein Video www.somedomain.com oder Videos oder v8675309 genannt werden. Hier kann die Hierarchie als der Publisher „www.somedomain.com“, eine Unterkategorie „Videos“ und die kanonische Identifikation „v8675309“ gesehen werden. Wenn ein Interesse 3330 das ICN durchläuft, werden ICN-Netzwerkelemente im Allgemeinen versuchen, dass der Name zu einem größten Grad übereinstimmt. Falls also ein ICN-Element ein gecachtes Element oder eine gecachte Route sowohl für „www.somedomain.com oder Videos“ als auch für „www.somedomain.com oder Videos oder v8675309“ aufweist, stimmt das ICN-Element mit letzterem für ein Interessenpaket 3330 überein, das „www.somedomain.com oder Videos oder v8675309“ spezifiziert. In einem Beispiel kann ein Ausdruck beim Abgleich durch die ICN-Vorrichtung verwendet werden. Beispielsweise kann das Interessenpaket „www.somedomain.com oder Videos oder v8675*“ spezifizieren, wobei ‚*‘ ein Platzhalter ist. Somit wird ein beliebiges gecachtes Element oder eine beliebige gecachte Route, die die anderen Daten außer dem Platzhalter beinhalten, abgeglichen.
  • Der Elementabgleich beinhaltet Abgleichen des Interesses 3330 mit Daten, die im ICN-Element zwischengespeichert sind. Falls also zum Beispiel die im Interesse 3330 genannten Daten 3345 im Netzwerkelement 3315 gecacht sind, wird das Netzwerkelement 3315 die Daten 3345 über das Netzwerkelement 3310 an die Teilnehmervorrichtung 3305 zurückgeben. Falls die Daten 3345 jedoch nicht am Netzwerkelement 3315 zwischengespeichert sind, leitet das Netzwerkelement 3315 das Interesse 3330 weiter (z.B. an das Netzwerkelement 3320). Um Routing zu ermöglichen, können die Netzwerkelemente eine Weiterleitungsinformationsbasis 3325 (FIB) verwenden, um benannte Daten mit einer Schnittstelle (z.B. physischer Port) für die Route abzugleichen. Dementsprechend arbeitet die FIB 3325 ähnlich wie eine Routingtabelle in einer herkömmlichen Netzwerkvorrichtung.
  • In einem Beispiel können zusätzliche Metadaten an das Interessenpaket 3330, die zwischengespeicherten Daten oder die Route (z.B. in der FIB 3325) angehängt werden, um einen zusätzlichen Übereinstimmungsgrad bereitzustellen. Zum Beispiel kann der Datenname als „www.somedomain.com oder Videos oder v8675309“ spezifiziert sein, aber auch eine Versionsnummer - oder einen Zeitstempel, einen Zeitbereich, eine Bestätigung usw. - beinhalten. In diesem Beispiel kann das Interessenpaket 3330 den gewünschten Namen, die Versionsnummer oder den Versionsbereich spezifizieren. Der Abgleich kann dann Routen oder gecachte Daten lokalisieren, die mit dem Namen übereinstimmen, und den zusätzlichen Vergleich von Metadaten oder dergleichen durchführen, um zu einer endgültigen Entscheidung darüber zu gelangen, ob Daten oder eine Route mit dem Interessenpaket 3330 übereinstimmen, um jeweils mit dem Datenpaket 3345 auf das Interessenpaket 3330 zu antworten oder das Interessenpaket 3330 weiterzuleiten.
  • In weiteren Beispielen können Metadaten in einem ICN Merkmale von Dienstbedingungen oder Dienstgüte angeben, wie sie durch die Diensterwägungen mit den vorliegend erörterten Satellitenkommunikationsnetzwerken eingesetzt werden. Solche Metadaten können zum Beispiel angeben: den Geostandort, an dem Inhalt erzeugt wurde; ob der Inhalt in eine Ausschlusszone abgebildet wird; und ob der Inhalt an einem aktuellen oder einem bestimmten geografischen Standort gültig ist. Mit diesen Metadaten kann eine Vielfalt von Eigenschaften in geografischen Ausschluss und Dienstgüte eines Satellitenkommunikationsnetzwerks abgebildet werden, wie etwa unter Verwendung der vorliegend erörterten Methoden. Zudem kann das ICN-Netzwerk in Abhängigkeit von der in der PIT erforderlichen QoS einen jeweiligen Satellitenkommunikationsanbieter auswählen (oder einen ganz anderen Anbieter auswählen).
  • ICN hat Vorteile gegenüber hostbasierter Vernetzung, da die Datensegmente einzeln benannt werden. Dies ermöglicht aggressives Caching im gesamten Netzwerk, da ein Netzwerkelement ein Datenpaket 3330 in Reaktion auf ein Interesse 3330 so einfach wie ein Originalautor 3340 bereitstellen kann. Dementsprechend ist es weniger wahrscheinlich, dass dasselbe Segment des Netzwerks Duplikate derselben Daten übertragen wird, die durch unterschiedliche Vorrichtungen angefordert werden.
  • Eine feinkörnige Verschlüsselung ist ein weiteres Merkmal vieler ICN-Netzwerke. Ein typisches Datenpaket 3345 beinhaltet einen Namen für die Daten, der mit dem Namen in dem Interessenpaket 3330 übereinstimmt. Ferner beinhaltet das Datenpaket 3345 die angeforderten Daten und kann zusätzliche Informationen zum Filtern ähnlich benannter Daten (z.B. nach Erzeugungszeit, Ablaufzeit, Version usw.) beinhalten. Für den Umgang mit bösartigen Entitäten, die falsche Informationen unter demselben Namen bereitstellen, kann das Datenpaket 3345 zudem seine Inhalte mit einem Publisherschlüssel verschlüsseln oder einen kryptografischen Hash der Daten und des Namens bereitstellen. Somit ermöglicht die Kenntnis des Schlüssels (z.B. aus einem Zertifikat eines erwarteten Publisher 3340) dem Empfänger, festzustellen, ob die Daten von diesem Publisher 3340 stammen. Diese Technik ermöglicht zudem das aggressive Caching der Datenpakete 3345 im gesamten Netzwerk, da jedes Datenpaket 3345 in sich geschlossen und sicher ist. Im Gegensatz dazu beruhen viele hostbasierte Netzwerke auf dem Verschlüsseln einer Verbindung zwischen zwei Hosts, um Kommunikationen zu sichern. Dies kann die Latenzen erhöhen, während Verbindungen aufgebaut werden, und verhindert Daten-Caching durch Verbergen der Daten gegenüber den Netzwerkelementen.
  • In weiteren Beispielen können unterschiedliche ICN-Domänen getrennt sein, sodass unterschiedliche Domänen in unterschiedliche Arten von Mandanten, Dienstanbietern oder anderen Entitäten abgebildet werden. Die Trennung solcher Domänen kann eine Form von softwaredefinierter Vernetzung (z.B. SD-WAN) unter Verwendung von ICN ermöglichen, einschließlich in den vorliegend erörterten Satellitenkommunikationsumgebungen. Zusätzlich können sich ICN-Topologien, einschließlich dessen, welche Knoten von spezifischen Dienstanbietern, Mandanten usw. offengelegt werden, basierend auf einem Geostandort ändern, was insbesondere für Satellitenkommunikationsumgebungen relevant ist.
  • Beispielhafte ICN-Netzwerke beinhalten inhaltszentrierte Vernetzung (CCN), wie in den Spezifikationsentwürfen der IETF (Internet Engineering Task Force) für CCNx 0.x und CCN 1.x spezifiziert, und Named Data Networking (NDN), wie im NDN Technical Report DND-0001 spezifiziert.
  • NDN ist eine Art von ICN, die neue Möglichkeiten zum Liefern besserer Benutzererlebnisse in Szenarien bringt, die für die aktuelle IP-basierte Architektur eine Herausforderung darstellen. Wie ICN verwendet NDN, statt auf hostbasierte Konnektivität angewiesen zu sein, Interessenpakete, um ein spezifisches Datenelement direkt anzufordern (einschließlich Funktionen, die an bestimmten Daten durchgeführt werden). Ein Knoten, der diese Daten aufweist, sendet ihn als Antwort auf das Interessenpaket zurück.
  • 34 veranschaulicht eine Konfiguration eines ICN-Netzwerkknotens, der NDN-Methoden implementiert. NDN ist eine ICN-Implementierung, die eine Design- und Referenzimplementierung bereitstellt, die namensbasiertes Routing bietet und die Pullbasierte Inhaltsabruf- und Weiterleitungsmechanismen ermöglicht. Jeder Knoten oder jede Vorrichtung in dem Netzwerk, der/die Daten konsumiert (z.B. Inhalt, Berechnung oder ein Funktionsergebnis) oder irgendeine durchzuführende Funktion, sendet ein Interessenpaket an seine benachbarten Knoten aus, die durch physische Schnittstellen (z.B. Flächen) verbunden sind, die drahtgebunden oder drahtlos sein können. Der oder die Nachbarknoten, die die Datenanfrage empfangen (z.B. Interessenpaket), durchlaufen die in 34 (oben) gezeigte Sequenz, wobei ein Knoten seinen lokalen Inhaltsspeicher 3405 (z.B. Cache) zunächst nach einer Übereinstimmung mit dem Namen in dem Interessenpaket durchsucht. Ist dies erfolgreich, wird Inhalt an den anfragenden Knoten zurückgegeben. Falls der benachbarte Knoten den angeforderten Inhalt in dem Inhaltspeicher 3405 nicht aufweist, fügt er einen Eintrag hinzu, der den Namen aus dem Interessenpaket und die Fläche, auf der das Interessenpaket empfangen wurde, beinhaltet, an die Tabelle anhängiger Interessen (PIT) 3410 und wartet darauf, dass der Inhalt eingeht. Falls beispielsweise ein Eintrag für die Fläche und der Name bereits in der PIT 3410 vorhanden sind, kann der neue Eintrag den gegenwärtigen Eintrag überschreiben, oder der vorliegende Eintrag wird verwendet und es erfolgt kein neuer Eintrag.
  • Nachdem der PIT-Eintrag erstellt ist, erfolgt ein Nachschlagen in der FIB-Tabelle 3415, um die Informationen über den nächsten Sprung (z.B. die Nachbarknotenfläche) abzurufen, um dieses Interessenpaket weiterzuleiten. Falls kein FIB-Eintrag gefunden wird, kann diese Anfrage auf allen verfügbaren Flächen ausgesendet werden, außer derjenigen, auf der das Interessenpaket empfangen wurde, oder die Anfrage kann verworfen werden, und es wird keine Routen-NACK- (negative Bestätigung) Nachricht an den Anfragenden zurückgesendet. Falls andererseits der benachbarte Knoten einen Eintrag in der FIB-Tabelle 3415 für die angeforderten Informationen aufweist, leitet er das Interessenpaket weiter in das Netzwerk (z.B. an andere NDN-Verarbeitungsknoten 3420) und macht einen Eintrag in seiner Tabelle anhängiger Interessen (PIT).
  • Wenn das Datenpaket in Reaktion auf das Interesse ankommt, leitet der Knoten die Informationen zurück an den Teilnehmer, indem er dem Interessenpfad folgt (über den Eintrag in der PIT 3425, während zudem die Daten am Inhaltspeicher 3430 zwischengespeichert werden), wie in 34 unten gezeigt. Im Allgemeinen wird der PIT-Eintrag aus der PIT 3425 entfernt, nachdem das Datenpaket weitergeleitet wurde.
  • 35 veranschaulicht einen beispielhaften Einsatz von ICN- (z.B. NDN- oder NFN-) Methoden unter Satellitenverbindungsknoten. Hier verwendet ein Endpunktknoten 3505 ein Funkzugangsnetz 3510, um Daten oder Funktionen von einem ICN anzufordern. Eine ICN-Datenanforderung wird zunächst an einem Basisstations-Edge-Knoten 3515 verarbeitet, der den Inhaltsspeicher auf dem Basisstations-Edge-Knoten 3515 prüft, um zu bestimmen, ob die angefragten Daten lokal verfügbar sind. Wenn die Daten nicht lokal verfügbar sind, wird die Datenanfrage in der PIT 3514 protokolliert und durch das Netzwerk zu dem Satellitenkommunikationsnetzwerk gemäß der FIB 3512 weitergeleitet, wie etwa über einen Uplink 3525A, um eine Datenquelle 3530 am Satelliten 3502 zu prüfen (z.B. einen Inhaltsspeicher im Satelliten 3502). In dem abgebildeten Szenario aus 35 sind Daten 3540 ferner im Satellitennetzwerk, an einem Knoten 3540 (oder sogar an einem weiteren Datenknoten im Netzwerk, wie etwa am Bodenstandort 3550) verfügbar. Das NDN arbeitet, um einen Downlink 3525B vom Satelliten 3501 zu verwenden, um die Daten 3542 zurück zu dem Basisstations-Edge-Knoten 3515 und dann zurück an den Endpunktknoten 3505 bereitzustellen. Das NDN kann Domänen, Metadaten und andere Merkmale verwenden, die über das NDN kommuniziert werden, um Eigenschaften des Satellitenkommunikationsnetzwerks zu identifizieren und anzuwenden.
  • Satelliten-Handover zur Rechenarbeitslastverarbeitung
  • Wie vorstehend besprochen, wird mit der Verwendung vieler Knoten auf dem Boden, die mit vielen Satelliten und Satellitenkonstellationen verbunden sind, die die Erde umkreisen, eine Vielfalt von Konnektivitätsverwendungsfällen ermöglicht. Es wird erwartet, dass einige LEO-Satelliten Rechen- und Datendienste an Bodenknoten zusätzlich zu reiner Konnektivität bereitstellen, mit der zusätzlichen Herausforderung, dass LEO-Satelliten intermittierend für die Bodenknoten sichtbar sind. Falls sich ein Satellit in einem solchen Szenario noch mitten in der Bereitstellung eines Dienstes befindet, wenn er den Sichtkontakt zum Bodenknoten verliert, könnte dies zu einer Störung des Dienstes und einem Verlust von Zwischenergebnissen führen, die durch den ersten Satelliten berechnet wurden. Diese Störung kann mit den nachfolgenden Handover-Methoden abgemildert oder überwunden werden, um Datentransfers und Operationen zu koordinieren.
  • 36 veranschaulicht ein Satellitenverbindungsszenario, das unter Verwendung eines ICN-Daten-Handovers verbessert wurde. In diesem Szenario ist eine Anzahl von Vorrichtungen 3630 (z.B. IoT-Vorrichtungen) über ein drahtloses Netzwerk mit einer Basisstation 3620 verbunden, die ein Edge-Gerät 3622 zur Berechnung oder Datenverarbeitung aufweist. Die Vorrichtungen 3630 fragen die Durchführung einer bestimmten Edge-Rechenfunktion an einer Datenarbeitslast an, die nicht lokal an dem Gerät 3622 verarbeitet werden kann (z.B. aufgrund begrenzter Ressourcen an dem Gerät 3622, Nichtverfügbarkeit eines Verarbeitungsmodells usw.). In Reaktion hierauf koordiniert die Basisstation 3620 die Kommunikation mit einem Satelliten 3602 des LEO-Satellitenkommunikationsnetzwerks unter Verwendung der Verbindung 3611A, um eine Verarbeitung der Arbeitslast an einer weiter entfernten Schicht des Netzwerks anzufragen (z.B. am Satelliten 3602, an der Bodenstation 3650, am Datenzentrum 3660). In diesem Szenario wird der Satellit 3602 jedoch aufgrund der flüchtigen Natur von im Orbit kreisenden LEO-Satelliten nicht in der Lage sein, die Datenanfrage zu erfüllen, bevor er außer Reichweite gelangt.
  • Als eine zusätzliche Beschreibung eines solchen Szenarios sei ein Verwendungsfall betrachtet, bei dem sich der Satellit 3602 mitten im Senden von Daten an einen Bodenknoten 3622 befindet oder mitten in der Ausführung eines Rechendienstes befindet, aber die Abdeckung des Bodenknotens 3622 verliert, mit dem er kommuniziert. Irgendwann wird ein neuer Satellit 3601 in Sichtweite des Bodenknotens 3622 sein. Der neue Satellit 3601 weist jedoch möglicherweise nicht die Daten auf, die der Bodenknoten 3622 anfordert. Falls es sich ferner um einen Rechendienst handelt, existieren sämtliche Zustands- und Teilberechnungen, über die der alte Satellit verfügt, nicht in dem neuen System.
  • Ein Schätzen, wann sich der Satellit in Abdeckung oder außerhalb der Abdeckung befinden wird, und Koordinieren von Anfragen für eine solche Abdeckung unter verschiedenen Satelliten erfordert erheblichen Overhead. Daher schlägt das Folgende ein Schema, bei dem der in Sicht kommende neue Satellit fortfahren kann, wo der alte Satellit aufgehört hat, mit minimalem Overhead vor.
  • Das Folgende verwendet ein namensbasiertes Schema, wie andere ICN-Aktivitäten, wobei der Benutzer (z.B. Client) die Berechnung basierend auf dem Namen der Funktion (z.B. Softwarefunktion) und den Daten anfordert, mit denen er arbeiten muss. Dies kann in einigen Implementierungen als Named Function Networking (NFN) oder Named Data Networking (NDN) bezeichnet werden. Da die Anforderung namensbasiert ist, ist der Name nicht an irgendeinen spezifischen Knoten oder Ort gebunden. In diesem Fall wird, wenn sich der erste Satellit bewegt und ein zweiter Satellit in Reichweite kommt, die Rechenanforderung gerade an den zweiten Satelliten weitergeleitet. Statt jedoch alle Daten neu zu berechnen, wenn ein LEO-Satellit seine erste Rechenanforderung von einem neuen Ort empfängt, fragt er nach einer Datenmigration (z.B. „Kernabbild“ oder Container-Migration) aller relevanten Recheninformationen von dem alten Satelliten.
  • Das folgende stellt eine einfache und skalierbare Lösung zum Durchführen von Rechendiensten auf dem Satelliten bereit. Die Handover-Technik benötigt keinen Overhead zum Vorhersagen eines Abdeckungsverlusts. Stattdessen wird das System bei Empfang des ersten Recheninteressierungspakets ausgelöst. Das folgende stellt auch eine Entwicklung einer neuen Art von Interessenpaket bereit, das alle Materialien in Bezug auf Rechendienste anfordert. Dies erfolgt standardmäßig nicht, da, falls der neue Satellit keine Rechenanforderungen empfängt, er keine vorherigen Recheninformationen anfordert. Zusätzliche Sicherheits- und andere Einschränkungen können auch verknüpft werden, mit denen Satelliten vorherige Recheninformationen erhalten und Berechnung durchführen können.
  • 37 veranschaulicht einen beispielhaften Verbindungsfluss für einen Handoff in einem Satellitendatenverarbeitungsszenario, zwischen einer Benutzerrechenvorrichtung 3702, einem Masseknoten 3704 und Leos 3706, 3708. Obwohl dies nicht dargestellt ist, kann dieser Verbindungsfluss für das Abrufen oder Verarbeiten von Daten an anderen Orten, die sich weiter im Netzwerk befinden (wie etwa an einem Grundort, auf den über das Satellitenkommunikationsnetzwerk zugegriffen werden kann), erweitert werden.
  • Im Fluss von 37 stellt der Benutzer eine anfängliche Rechendienstanforderung (z.B. Interessenpaket) für eine Rechenaktion, eine Funktion oder Daten bereit, die in der Dienstanforderung bei Operation (1) benannt ist. Der Masseknoten 3704 leitet dies an den LEO1 3706 zur Verarbeitung weiter. Bei Operation (2) gibt das LEO1 3706 Zwischenergebnisse oder Teilergebnisse (z.B. ein Datenpaket mit einem Namen, der mit dem Namen aus dem Interessenpaket abgeglichen werden kann) zurück.
  • Zum Zeitpunkt 3712 bewegt sich der LEO1 3706 außerhalb des Bereichs, gefolgt von einer Bewegung der LEO2 3708 in den Bereich. Basierend auf diesem Übergang wird die erste Rechenanforderung zu LEO2 3708 zum Zeitpunkt 3714 weitergeleitet.
  • Der Benutzer stellt bei Operation (3) eine zweite Rechendienstanforderung für die Rechenaktion, die Funktion oder die Daten bereit. Der Bodenknoten 3704 leitet dies nun an den LEO2 3708 zur Verarbeitung weiter. Die LEO2 3708 stellt eine Anforderung an LEO1 3706 für ein Abbilden von Recheninformationen für eine gewisse Zeit oder eine andere Spezifikation (z.B. für die letzte Minute) bereit und erhält solche Informationen von LEO 3706. Die LEO2 3708 sendet dann verbleibende Ergebnisse an den Benutzer 3702 im Betrieb zurück (4).
  • In weiteren Beispielen kann die Auswahl von LEO2 3708 auf bestehenden Routing- und Kapazitätsplanungsregeln basieren. Falls LEO1 3706 beispielsweise mehrere Optionen dahingehend aufweist, was LEO2 3708 auswählen kann, kann es Folgendes verwenden: (1) wie viele Leistungsfähigkeiten bereitgestellt werden; (2) wie viele QoS-Merkmale bereitgestellt werden; und (3) ob EPVC-Kanäle gemäß einer SLA rückerstellt werden können. Diese Faktoren können in die FIB der LEO2 3708 eingeschlossen sein, um beim Bestimmen, an welcher Schnittstelle die Anforderungen gesendet werden, zu helfen.
  • Im Gegensatz zu dem in 1 dargestellten Handover-Ansatz. 37 stellen existierende Techniken keinen „reaktiven“ Dienst-Handover in einem Satelliten-Framework bereit. Ferner basieren sitzungsbasierte Dienste wie TCP/IP auf festen Endpunkten und sind nicht in der Lage, eine solche Funktionalität zu unterstützen.
  • Andere Erweiterungen der in 1 dargestellten Handover-Technik. 37 implementiert werden. Dies kann zum Beispiel eine Koordination von Ende-zu-Ende-QoS beinhalten, wie etwa QoS-Ansätze, die auf ICN(z.B. NDN oder NFN)-Netzwerke erweitert sind. Andere Überlegungen zu Leistungskennzahlen (KPIs: Key Performance Indicators) und anderen komplexen QoS-Überlegungen mit mehreren Einschränkungen können ebenfalls involviert sein. Andere Aspekte können Zuverlässigkeit als Teil der Koordination und Verarbeitungsauswahl berücksichtigen. Beispielsweise können Zuverlässigkeitsanforderungen oder -Informationen als Teil der NDN/ICN-Anforderung verwendet und mit Ressourcen- und Routenabbildung berücksichtigt werden.
  • Zusätzlich dazu können andere Netzwerkinformationen (wie etwa Mobilfunknetzsteuerebeneninformationen) für einen Verarbeitungs-Handover verwendet werden, unter Berücksichtigung, dass Satellitentechnologien als eine der Funkzugangstechnologien bei 5G und darüber hinaus geplant sind. Hier werden die Masseknoten (z.B. der Masseknoten 3704) als Teil des zellularen Netzwerks betrachtet und verbinden die zellularen Basisstationen durch entweder drahtgebundene (z.B. Xn-Schnittstelle) oder drahtlose Schnittstellen. Falls sich der Satellit bewegt, können die Bodenknoten die Bewegung detektieren und die Informationen mit Basisstationen austauschen, die die Anforderung der Verbraucher an den neuen Satelliten durch den neuen Bodenknoten intelligent weiterleiten können. Dementsprechend kann auch Koordination verwendet werden, um Datenverbraucher oder Nutzerbewegungen zu handhaben.
  • 38 veranschaulicht ein Flussdiagramm 3800 eines beispielhaften Verfahrens, das in einem Satellitenkonnektivitätssystem zum Handover von Rechen- und Datendiensten durchgeführt wird, um Dienstkontinuität unter Verwendung einer NDN/ICN-Architektur und Dienstanforderungen aufrechtzuerhalten. Aspekte dieses Verfahrens können durchgeführt werden durch: Ein Benutzergerät (z.B. Benutzergerät), das direkt oder indirekt mit einem Satellitenkommunikationsnetzwerk verbunden ist; einen Bodenknoten (z.B. Edge-Basisstation), der mit dem Satellitenkommunikationsnetzwerk verbunden oder indirekt verbunden ist; die Niedrigerdorbit-Satelliten des Satellitenkommunikationsnetzwerks; Oder andere Orchestratoren, Gateways oder Kommunikationsvorrichtungen (einschließlich Zwischenvorrichtungen, die an einem NDN/ICN-Betrieb beteiligt sind).
  • Bei Operation 3810 wird eine Rechendienstanforderung an dem ersten Satellitenknoten über die NDN/ICN-Architektur empfangen (oder an diesen bereitgestellt). Diese Dienstanforderung kann eine Anforderung für Rechenoperationen und/oder Funktionsleistungsfähigkeit und/oder Datenabrufoperationen über die NDN/ICN-Architektur beinhalten.
  • Bei Operation 3820 werden Zwischenergebnisse oder Teilergebnisse der Dienstanforderung von einem ersten Satellitenknoten an einen Benutzer/Verbraucher geliefert (oder von einem solchen Knoten empfangen). Beispielsweise kann die anfängliche Antwort auf die Dienstanforderung Teilergebnisse für die Dienstanforderung beinhalten, wie oben unter Bezugnahme auf 37. Diese Ergebnisse können als Ergebnis des Detektierens oder Vorhersagen ihres Austritts aus einem Georaum (Quadrat, Kreis, Sechseck,...) des ersten Satellitenmerkmals geliefert werden. Bereich, der für einen terrestrischen Benutzer optimal ist. Beispielsweise identifiziert der erste Satellitenknoten in einer NDN/ICN-Einstellung proaktiv den zweiten Satellitenknoten, der in den Georraum eintritt, und migriert seine PIT- und FIB-Einträge (einschließlich jener, die teilweise bedient werden).
  • Bei Operation 3830 wird eine aktualisierte (zweite) Dienstanforderung an einem zweiten Satellitenknoten als Reaktion auf Benutzer- oder Satellitenabdeckungsänderungen erhalten (oder an diesen kommuniziert). Wie oben angemerkt, kann dieses Handover automatisch innerhalb des Satellitennetzwerks stattfinden, wie etwa von einem ersten Satelliten zu einem zweiten Satelliten einer Konstellation, basierend auf geografischen Abdeckungsinformationen oder einem Zustand der Benutzerverbindung.
  • Bei Operation 3840 wird die aktualisierte Dienstanforderung an dem zweiten Satellitenknoten über die NDN-Architektur für das anfängliche oder die verbleibenden Verarbeitungsergebnisse empfangen. Hier vervollständigt der zweite Satellitenknoten die teilweise bediente Anforderung unter Verwendung des migrierten ersten Satellitenknotenknotenkontexts. In einigen Beispielen kennt der terrestrische Benutzer den Handoff an den zweiten Satellitenknoten nicht und dementsprechend bleiben die Operationen zum Durchführen des Handoffs für den Endbenutzer transparent.
  • Bei Operation 3850 arbeitet der zweite Satellitenknoten, um Ergebnisse der Berechnung oder Datenverarbeitung für die Dienstanforderung zu erhalten (basierend auf Zwischenergebnissen, Dienstbedingungen oder anderen Informationen vom ersten Satellitenknoten).
  • Bei Operation 3860 werden die verbleibenden Ergebnisse der Dienstanforderung (wie zutreffend) erzeugt, zugegriffen oder anderweitig erhalten und dann von dem ersten Satellitenknoten an den Endbenutzer/Verbraucher kommuniziert.
  • In weiteren Beispielen ist ein Bodenknoten involviert, um Daten als Teil der Dienstanforderung und der NDN-Operationen anzufordern, zu kommunizieren oder bereitzustellen. Beispielsweise kann der Bodenknoten als ein erster Sprung der NDN-Architektur beteiligt sein und die Dienstanforderung an das Satellitenkommunikationsnetzwerk weiterleiten, falls manche Daten oder ein Funktionsergebnis nicht von dem Bodenknoten bereitgestellt werden können.
  • Beispiel G1 ist ein Verfahren für koordiniertes Daten-Handover in einem Satellitenkommunikationsnetzwerk, das Folgendes umfasst: Übertragen, an ein Satellitenkommunikationsnetzwerk, das eine benannte Datennetzwerk(NDN)-Architektur implementiert, einer Dienstanforderung für die NDN-Architektur; Empfangen, von einem ersten Satelliten des Satellitenkommunikationsnetzwerks, einer anfänglichen Antwort auf die Dienstanforderung; Übertragen, zu dem Satellitenkommunikationsnetzwerk, einer aktualisierten Dienstanforderung für die NDN-Architektur als Reaktion darauf, dass sich der erste Satellit aus dem Kommunikationsbereich bewegt; Und Empfangen, von einem zweiten Satelliten des Satellitenkommunikationsnetzes, einer aktualisierten Antwort auf die aktualisierte Dienstanforderung basierend auf einem Handover der Dienstanforderung von dem ersten Satelliten zu dem zweiten Satelliten.
  • Bei Beispiel G2 beinhaltet der Gegenstand des Beispiels G1 optional einen Gegenstand, bei dem die Dienstanforderung eine Anforderung für rechenoperationen und/oder Funktionsleistung und/oder Datenabrufoperationen über die NDN-Architektur ist.
  • Bei Beispiel G3 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G2 optional einen Gegenstand, bei dem die anfängliche Antwort auf die Dienstanforderung Teilergebnisse für die Dienstanforderung umfasst, und wobei die aktualisierte Antwort auf die aktualisierte Dienstanforderung verbleibende Ergebnisse für die Dienstanforderung umfasst.
  • Bei Beispiel G4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G3 optional einen Gegenstand, bei dem das Handover der Dienstanforderung zwischen dem ersten Satelliten und dem zweiten Satelliten koordiniert wird, basierend auf dem Weiterleiten der Dienstanforderung von dem ersten Satelliten zu dem zweiten Satelliten, Und basierend darauf, dass der zweite Satellit Daten von dem ersten Satelliten erhält, die mit der anfänglichen Antwort auf die Dienstanforderung assoziiert sind.
  • Bei Beispiel G5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G4 optional einen Gegenstand, bei dem Operationen durch ein Benutzergerät durchgeführt werden, das direkt mit dem Satellitenkommunikationsnetzwerk verbunden ist.
  • Bei Beispiel G6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G5 optional einen Gegenstand, bei dem Operationen durch einen Bodenknoten durchgeführt werden, der mit dem Satellitenkommunikationsnetzwerk verbunden ist, wobei der Bodenknoten Daten der Dienstanforderungen und der Antworten mit einem verbundenen Benutzer kommuniziert.
  • Bei Beispiel G7 beinhaltet der Gegenstand des Beispiels G6 optional einen Gegenstand, bei dem der Bodenknoten die Dienstanforderung als Reaktion darauf aufruft, dass er nicht in der Lage ist, die Dienstanforderung an dem Bodenknoten zu erfüllen.
  • Bei Beispiel G8 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G7 optional einen Gegenstand, bei dem das Handover der Dienstanforderung Koordination der Rechenergebnisse beinhaltet, die von dem ersten Satelliten zu dem zweiten Satelliten kommuniziert werden.
  • Bei Beispiel G9 beinhaltet der Gegenstand von Beispiel G8 optional einen Gegenstand, bei dem die Rechenergebnisse Daten beinhalten, die für einen Zeitraum an dem ersten Satelliten ausgeführt werden.
  • Bei Beispiel G10 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G9 optional einen Gegenstand, bei dem die Dienstanforderung eine NDN-Anforderung basierend auf einem Namen einer Funktion und einen Datensatz zum Betreiben der Funktion beinhaltet.
  • Bei Beispiel G11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G10 optional einen Gegenstand, bei dem der erste Satellit oder der zweite Satellit konfiguriert sind, um die Dienstanforderung basierend auf zusätzlichen Rechenknoten, auf die von dem Satellitenkommunikationsnetzwerk zugegriffen werden kann, zu erfüllen.
  • Bei Beispiel G12 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G11 optional einen Gegenstand, bei dem der erste Satellit und der zweite Satellit Teil einer Niedrigerdorbit(LEO)-Satellitenkonstellation sind.
  • Bei Beispiel G13 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G12 optional einen Gegenstand, bei dem die Auswahl des ersten Satelliten oder des zweiten Satelliten zum Erfüllen der Dienstanforderung auf Netzwerkrouting oder Kapazitätsregeln basiert.
  • Bei Beispiel G14 beinhaltet der Gegenstand des Beispiels G13 optional einen Gegenstand, bei dem die Auswahl des ersten Satelliten oder des zweiten Satelliten zum Erfüllen der Dienstanforderung ferner auf Dienstgüte- und Dienstgüteanforderungen basiert.
  • Bei Beispiel G15 beinhaltet der Gegenstand eines oder mehrerer der Beispiele G1 bis G14 optional einen Gegenstand, bei dem die aktualisierte Dienstanforderung ferner basierend auf einer Bewegung einer mobilen Vorrichtung, die die Dienstanforderung erzeugt, koordiniert wird.
  • Erkennungs- und Routingalgorithmen für Satelliten- und terrestrische Verbindungen
  • Wie in den vorherigen Beispielen gezeigt, wird ein Infrastrukturknoten auf dem Boden mit (i) dem EINEN oder den mehreren LEO-Satelliten, (ii) Client-Vorrichtungen über eine Drahtlosverbindung, (iii) Client-Vorrichtungen über eine drahtgebundene Verbindung und (iv) anderen Infrastrukturvorrichtungen über drahtgebundene und/oder drahtlose Verbindungen verbunden sein. Jede dieser Links wird unterschiedliche Verzögerungen und Bandbreiten aufweisen. Bei der Datenanforderung ist die Entscheidung, welcher Link zu verwenden ist, einfacher. Der nächste Knoten mit einer kürzesten Verzögerung wird eine gute Wahl treffen. Falls es sich jedoch um eine Rechenanforderung handelt, muss die Entscheidung auch um den Typ der Rechenhardware handeln, die auf der Vorrichtung verfügbar ist, die QoS-Anforderungen, Sicherheitsanforderungen und so weiter.
  • Ausnutzen der namensbasierten Adressierung in ICN präsentiert das folgende Verbesserungen, die es dem System ermöglichen, eine Erkennung durchzuführen sowie den besten Knoten/Pfad zum Durchführen des Dienstes (Routing und Weiterleiten) auszuwählen. In einem Satelliten-Edge-Framework werden unterschiedliche Knoten unterschiedliche Rechenfähigkeiten und Ressourcen (Hardware, Software, Speicherung usw.) aufweisen, die Anwendung wird unterschiedliche QoS-Anforderungen und -Prioritäten aufweisen und es kann zusätzliche Richtlinien geben, die durch die Regierung oder andere Entitäten durchgesetzt werden.
  • Um ein Beispiel bereitzustellen, ist es möglich, dass bestimmte Satelliten Sicherheitsmerkmale implementiert haben, während andere dies nicht haben. Zum Beispiel können einige von ihnen Sicherheitsenklaven-/vertrauenswürdige Ausführungsumgebungsmerkmale aufweisen, während andere dies nicht tun. Infolgedessen muss die Basisstation, wenn ein Interessenpaket an der Basisstation eingeht, die Entscheidung darüber treffen, ob es an die Satellitenverbindung weiterzuleiten ist oder nicht. Es könnte leicht Situationen geben, in denen, obwohl die Verzögerung zum Satelliten groß ist, sie eine viel größere Rechenressource aufweist und eine bessere Wahl zum Ausführen eines Dienstes im Vergleich zu einem Bodenknoten treffen wird, der näher ist (und sogar eine hohe Bandbreite aufweist).
  • Das folgende schlägt eine Mehrschichtlösung vor, die entscheidet, wo die Rechenanforderungen weiterzuleiten sind und wie Ressourcen zum Zusammenstellen von Diensten zu verwenden sind. Dies ist auf die Verwendung von ICN oder NDN anwendbar, da es Routing- sowie Weiterleitungsentscheidungen gibt, die getroffen werden müssen. Die offenbarten Entdeckungsmechanismen können dabei helfen, die Routingtabellen oder die Weiterleitungsinformationsbasis (FIB: Forwarding Information Base) zu befüllen und eine Karte von Links zu verfügbaren Ressourcen zusammen mit Verzögerungen, Bandbreite usw. zu erzeugen
  • Da das Weiterleiten in einem ICN Hop ist, muss der Knoten jedes Mal, wenn ein Interessenpaket an einem Knoten ankommt, eine Entscheidung treffen, wo das Paket weiterzuleiten ist. Falls die FIB beispielsweise drei Orte oder Links angibt, die in der Lage sind, die Funktion durchzuführen, muss die Weiterleitungsstrategie entscheiden, welche der drei die beste Option ist.
  • 39 stellt eine Entdeckungs- und Routingstrategie dar, die in einem Satellitenkonnektivitätssystem durchgeführt wird, das eine zweistufige Hierarchie von Entscheidungsfaktoren bereitstellt, die zur Rechenressourcenauswahl und -Verwendung verwendet werden. Hier gibt es auf der ersten Ebene eine Anwendung, die ihre Anforderungen und Prioritäten als Anwendungsparameter 3910 bereitstellt. Die Anwendung kann diese Informationen in einem Feld „Anwendungsparametern“ des Interessenpakets angeben. Falls zum Beispiel Sicherheit die erste Priorität ist, dann wird die Masse/Basisstation das Paket nicht an den Satelliten weiterleiten, selbst wenn es die schnellste Berechnung aufweist, aber nicht die Sicherheitsmerkmale aufweist. Das Interessenpaket kann auch angeben, welche Parameter einen Spielraum und andere, die dies nicht tun, aufweisen. Falls beispielsweise ein Client identifiziert, dass alle Anforderungen erfüllt werden müssen, dann leitet die Basisstation das Paket nicht weiter (und kann in Abhängigkeit von der Implementierung eine NACK senden), falls sie davon ausgeht, dass es keine Knoten gibt, die alle Einschränkungen erfüllen können.
  • Auf der ersten Ebene gibt es auch Ressourcenentdeckungsinformationen 3920, die aus dem Identifizieren der relevanten Rechen-, Speicherungs- oder Datenressourcen erhalten werden. Informationen über solche Ressourcen und Ressourcenfähigkeiten können als Teil eines ICN/NDN-Netzwerks entdeckt und identifiziert werden, wie oben besprochen.
  • Außerdem kann es auf der ersten Schicht andere lokale Richtlinien geben, die durchgesetzt werden müssen, die sich nicht dynamisch ändern. Dies sind die Richtlinieninformationen 3930 in der oberen Schicht.
  • Die Weiterleitungsstrategieschicht 3950 verwendet Eingaben von allen drei Quellen 3910, 3920, 3930 und entscheidet dann über den besten Pfad zum Weiterleiten eines Interessenpakets. Auf der Strategie-Schicht überschreibt die Richtlinie Anwendungsanforderungen.
  • Sobald die Weiterleitungsstrategieschicht 3950 eine Entscheidung darüber trifft, wo das Interessenpaket weiterzuleiten ist, weist es die Option auf, auch „Weiterleitungshinweise“ an die anderen Knoten bereitzustellen. Falls beispielsweise eine bestimmte Gruppe von Routen vermieden werden muss, kann dies in dem Weiterleitungshinweis angeben. Obwohl das Weiterleiten Hop für Hop in ICN/NDN erfolgt, kann der Quellknoten somit eine Anleitung für das Routing für alle kommenden Knoten bereitstellen.
  • In weiteren Beispielen können Aspekte von Satellitenbereichs-Gefencing und QoS/Dienstebenenüberlegungen (die in diesem Dokument erörtert werden) als Teil einer Weiterleitungsstrategie integriert sein. Somit kann ein Routing Überlegungen nicht nur an einer SLA, sondern auch hinsichtlich der Interessen oder Beschränkungen für geografische Standorte beinhalten.
  • Die Verwendung dieses Ansatzes stellt eine umfassende Lösung zum Implementieren von QoS, Richtlinien, Sicherheit und dergleichen zusammen mit Erkennung und Routing bereit. Dieser Ansatz kann das dynamische Entdecken von Ressourcen unterstützen, die im Satellitenrand wichtig sind. Dieser Ansatz ermöglicht die Verwendung sicherer sowie nicht sicherer Satellitenknoten und anderer Rechenressourcen. Dieser Ansatz berücksichtigt auch Drahtlosverzögerungen und -Bandbreite auf eine umfassende Weise zusammen mit anderen Parametern, um Routing- und Weiterleitungsentscheidungen zu treffen. Im Gegensatz dazu beruhen bestehende Orchestrierungslösungen hauptsächlich auf statischem Routing und Ressourcen-Frameworks.
  • LEO-basiertes Routing kann angepasst werden, einen Pfad zu konstruieren, der die Ende-zu-Ende-SLA bereitstellt, einschließlich Faktoren, einschließlich bodenbasierter Knoten, aktiver satellitenbasierter Knoten, Hop-zu-Hop-Ausbreitungsverzögerungen, die Hops sicher sind, die Inter-Satelliten-Links ein/aus sind, und wo die Routingalgehen-Berechnungen durchgeführt werden. Bodenbasierte algorithmische Berechnungen solcher Routen können rechenintensiver als in-Orbit-Berechnungen sein; dementsprechend kann ein wichtiger Faktor Hops sein, die sicher sind/oder die Hops eine Komprimierung verwenden, um das beste Ergebnis in Abhängigkeit davon zu erhalten, wie schnell die Konstellation aktualisiert werden muss.
  • Dementsprechend kann selbst bei bodenbasierten Routing-Berechnungen eine breite Ansicht eines raumbasierten Netzwerks und Charakteristiken von Hops (sicher/Komprimierung/usw.) evaluiert werden, um SLA-Ergebnisse sicherzustellen. Auf dem Boden befindliche Routen können auch als Teil der potenziellen Route zum Erreichen des SLA-Ergebnisses betrachtet werden. (Beispielsweise wie etwa unter Verwendung von Glasfasernetzwerken und dedizierten Verbindungen auf Masse, die eine hohe Bandbreite und niedrige Latenz bereitstellen). Als ein Beispiel könnte eine Routenauswahl Sat1 → Sat2 → Sat3 → -4 sein, wohingegen eine andere Routenauswahl Sat1 → Sättigungs- 2 → der Erde-Route → -Satellite 4 sein könnte.
  • In weiteren Beispielen können Überlagerungen für unterschiedliche Mandanten und Sperrzonen erstellt werden. Um zum Beispiel unterschiedliche Organisationen oder Mandanten aufzuweisen, die unterschiedliche Vertrauensniveaus für unterschiedliche Typen von Routern oder Netzwerkanbietern aufweisen. Ferner können mit der Verwendung von Berechtigungsnachweisen Vertrauensniveaus für verschiedene Router eingerichtet werden (z.B. an unterschiedliche Interessenpakete gebunden). Gleichermaßen können in weiteren Beispielen Konzepte vertrauenswürdiger Leitungsführung angewendet werden.
  • 40 stellt ein Flussdiagramm 4000 eines beispielhaften Verfahrens zum Implementieren von Entdeckungs- und Routing-Ansätzen dar. Dieses Verfahren kann in den oben besprochenen ICN-Architekturen (z.B. NDN oder NFN) implementiert und angewendet werden; dieses Verfahren kann jedoch als Teil anderer Routing-Berechnungen für Satellitenkommunikationsnetzwerke implementiert werden.
  • Bei Operation 4010 wird eine Anforderung für Datenrouting empfangen, die eine Datenverbindung über ein Satellitenkommunikationsnetzwerk involviert. Diese Anfrage kann an und in den folgenden Schritten durch einen bodenbasierten Infrastrukturknoten, der mit dem Satellitenkommunikationsnetzwerk verbunden ist, durch ein Benutzergerät, das direkt oder indirekt mit dem Satellitenkommunikationsnetzwerk verbunden ist, oder durch einen Satellitenkommunikationsknoten selbst durchgeführt werden.
  • Bei Operation 4020 werden ein oder mehrere Anwendungsparameter (einschließlich Anwendungspräferenzen) identifiziert und angewendet, wobei ein solcher Anwendungsparameter Prioritäten unter den Anforderungen für die Datenverbindung definiert.
  • Bei Operation 4030 werden eine oder mehrere Ressourcenfähigkeiten identifiziert und angewendet, wobei sich diese Ressourcenfähigkeiten auf Ressourcen an Knoten beziehen, die zum Erfüllen der Datenverbindung verwendet werden.
  • Bei Operation 4040 werden eine oder mehrere Richtlinien identifiziert und angewendet, wobei derartige Richtlinien jeweils eine oder mehrere Beschränkungen zur Verwendung der Datenverbindung definieren
  • Bei Operation 4050 wird eine Routingstrategie (und ein Routingpfad) basierend auf Präferenzen, Fähigkeiten, Richtlinien identifiziert. Dies kann beispielsweise auf der Priorisierung unter den Prioritäten basieren: Den Prioritäten, die durch die Anwendungsparameter definiert werden, den Ressourcenfähigkeiten, die durch die Knoten bereitgestellt werden, und der Erfüllung der identifizierten Richtlinien.
  • Bei Operation 4060 wird die Routingstrategie angewendet (wie etwa bei einer ICN-Implementierung), einschließlich unter Verwendung des/der identifizierten Routingpfade(n), um einen nächsten Sprung eines Interessenpakets zu erzeugen oder eine FIB-Tabelle zu füllen. Andere Verwendungen und Variationen können zur Verwendung dieser Technik in einer nicht-ICN-Netzwerkarchitektur gelten.
  • Beispiel H1 ist ein Verfahren zum Datenrouting unter Verwendung eines Satellitenkommunikationsnetzwerks, das Folgendes umfasst: Empfangen einer Anforderung zum Datenrouting unter Verwendung einer Datenverbindung über das Satellitenkommunikationsnetzwerk; Identifizieren mindestens eines Anwendungsparameters zur Verwendung der Datenverbindung, wobei der Anwendungsparameter Prioritäten unter den Anforderungen für die Datenverbindung definiert; Identifizieren mindestens einer Ressourcenfähigkeit für die Verwendung der Datenverbindung, wobei sich die Ressourcenfähigkeit auf Ressourcen an Knoten bezieht, die zum Erfüllen der Datenverbindung verwendet werden; Identifizieren mindestens einer Richtlinie zur Verwendung der Datenverbindung, wobei die Richtlinie mindestens eine Einschränkung der Verwendung der Datenverbindung definiert; Bestimmen mindestens eines Routingpfads über mindestens einen Knoten des Satellitenkommunikationsnetzwerks basierend auf der Priorisierung unter: Die Prioritäten, die durch den Anwendungsparameter definiert werden, die Ressourcenfähigkeit, die durch den mindestens einen Knoten bereitgestellt wird, und Erfüllung der identifizierten Richtlinie durch den mindestens einen Knoten; und Angeben des Routingpfads zur Verwendung mit einer Datenverbindung auf dem Satellitenkommunikationsnetzwerk.
  • Bei Beispiel H2 beinhaltet der Gegenstand des Beispiels H1 optional einen Gegenstand, bei dem der Routing-Pfad in Datenkommunikationen verwendet wird, die innerhalb einer Architektur für benannte Datennetzwerke (NDN) bereitgestellt werden.
  • Bei Beispiel H3 beinhaltet der Gegenstand von Beispiel H2 optional einen Gegenstand, bei dem der Routingpfad verwendet wird, um einen nächsten Sprung eines Interessenpakets zu erzeugen, das in der NDN-Architektur verwendet wird.
  • Bei Beispiel H4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H2 bis H3 optional einen Gegenstand, bei dem der Routingpfad verwendet wird, um eine Weiterleitungsinformationsbasis (FIB) der NDN-Architektur zu befüllen.
  • Bei Beispiel H5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H4 optional einen Gegenstand, bei dem sich die Anforderungen für die durch den Anwendungsparameter bereitgestellte Datenverbindung auf Sicherheit und/oder Latenz und/oder Dienstgüte und/oder den Dienstanbieterort beziehen.
  • In Beispiel H6 umfasst der Gegenstand nach einem der Beispiele H1 bis H5 wahlweise einen Gegenstand, wo sich die Ressourcenfähigkeit, die von dem mindestens einen Knoten bereitgestellt wird, auf Sicherheit, Vertrauen, Hardware, Software oder Dateninhalt bezieht.
  • Bei Beispiel H7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H6 optional einen Gegenstand, bei dem das Identifizieren der Ressourcenfähigkeit ein Auffinden von Ressourcenfähigkeiten an mehreren Knoten umfasst, wobei sich die Ressourcenfähigkeiten auf Sicherheit und Vertrauen beziehen.
  • In Beispiel H8 umfasst der Gegenstand nach Beispiel H7 wahlweise einen Gegenstand, bei dem sich die Ressourcenfähigkeiten an der Vielzahl von Knoten ferner auf Dienstressourcen beziehen, die durch Rechen- und/oder Speicherungs- und/oder Dateninhaltsressourcen bereitgestellt werden.
  • Bei Beispiel H9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H8 optional einen Gegenstand, bei dem die mindestens eine Einschränkung der Richtlinie auf eine Satellitenausschlusszone, eine Satellitennetzwerkbeschränkung oder eine Vorrichtungskommunikationsbeschränkung betrifft.
  • Bei Beispiel H10 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H9 optional einen Gegenstand, bei dem der Routingpfad eine terrestrische Netzwerkverbindung beinhaltet.
  • Bei Beispiel H11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H10 optional einen Gegenstand, bei dem das Bestimmen des Routingpfads das Bestimmen einer Vielzahl von Routingpfaden, die die identifizierten Richtlinien erfüllen, und das Auswählen eines Pfades basierend auf dem Anwendungsparameter und der Ressourcenfähigkeit umfasst.
  • In Beispiel H12 beinhaltet der Gegenstand von Beispiel H11 optional Bestimmen einer Präferenz unter der Vielzahl von Routingpfaden und Bereitstellen von Weiterleitungshinweisen zur Verwendung der Vielzahl von Routingpfaden.
  • Bei Beispiel H13 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H12 optional einen Gegenstand, bei dem das Verfahren durch einen bodenbasierten Infrastrukturknoten durchgeführt wird, der mit dem Satellitenkommunikationsnetzwerk verbunden ist.
  • Bei Beispiel H14 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H13 optional einen Gegenstand, bei dem das Verfahren durch ein Benutzergerät, das direkt oder indirekt mit dem Satellitenkommunikationsnetzwerk verbunden ist, ausgeführt wird.
  • Bei Beispiel H15 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H14 optional einen Gegenstand, bei dem die Operationen durch einen Satellitenkommunikationsknoten durchgeführt werden, wobei das Satellitenkommunikationsnetzwerk Pfade zwischen einer Vielzahl von Satellitenkonstellationen beinhaltet, die mit mehreren Dienstanbietern betrieben werden.
  • Bei Beispiel H16 beinhaltet der Gegenstand eines oder mehrerer der Beispiele H1 bis H15 optional einen Gegenstand, bei dem das Satellitenkommunikationsnetzwerk potenzielle Pfade zwischen einer Vielzahl von Inter-Satelliten-Links beinhaltet.
  • Verbesserungen Der Satellitennetzwerkpaketverarbeitung
  • Die folgende Offenbarung adressiert verschiedene Aspekte der Konnektivität und Netzwerkdatenverarbeitung, die für eine Vielfalt von Netzwerkkommunikationseinstellungen relevant sind. Insbesondere sind manche der hier besprochenen Techniken für Paketverarbeitung relevant, die durch vereinfachte Hardware in einem transienten nicht-terrestrischen Netzwerk (z.B. Leo(Low-Orbit)- oder VLEO(Very-Low-Orbit)-Satellitenkonstellations-(VLEO)-Netzwerk durchgeführt wird. Andere der hier erörterten Techniken sind für eine Paketverarbeitung in terrestrischen Netzwerken relevant, wie etwa unter Verwendung von Netzwerkverarbeitungshardware an verschiedenen Netzwerkterminierungspunkten.
  • Im Kontext vieler Netzwerkeinsätze begrüßen Dienstanbieter die Verwendung von IPSec (Internet Protocol Security), um den Pfad von Infrastrukturverkehr von Edge zu Kern zu sichern. IPsec erfordert viele Paketmodifikationen für jeden Sitzungsfluss, was die Verwendung von Paketverarbeitungs-Engines erfordert, die Latenzen zwischen den IPSec-Terminationspunkten hinzufügen, was sich auf die Fähigkeit für Dienstanbieter auswirkt, erforderliche <1ms 5G Latenzen zu erfüllen.
  • In Netzwerkanwendungen, wie etwa IPSec, Datagramm-Transportschicht. Sicherheit (DTLS) usw. müssen Pakete vor der Paketübertragung oder nach dem Paketempfang modifiziert werden (z.B. Header hinzufügen oder entfernen, Felder hinzufügen oder entfernen, verschlüsselt oder entschlüsselt, authentifiziert). Zum Erreichen des hohen Durchsatzes, der von modernen Vernetzungsanwendungen benötigt wird, muss eine große Anzahl von dedizierten Netzwerkverarbeitungs-Engines parallel arbeiten. Die folgenden Systeme und Verfahren verbessern Latenz-, Leistungs- und die-Flächenbeschränkungen signifikant, indem sie einen befehlsvorlagenbasierten Mechanismus nutzen, der die Notwendigkeit beseitigt, dass mehrere Netzwerkverarbeitungs-Engines solche Pakete verarbeiten und modifizieren.
  • Das folgende stellt einen Ansatz zum Reduzieren der Latenzen bereit, die mit dem Sichern von 5G Edge-to-Core-Verkehr eingeführt werden, indem eine einzelne Engine mit vorbestimmten Paketvorlagen anstelle mehrerer Paket-Engines verwendet wird. Durch Reduzieren der Anzahl an Paket-Engines werden weniger arithmetisch-logische Einheiten (ALUs: Arithmetic Logic Units) verwendet, wodurch Netzwerkprozessdesignkomplexität reduziert wird, Schaltungsfläche reduziert wird, Leistung reduziert wird und letztendlich Dienstanbietern ermöglicht wird, 5G-Latenzanforderungen am Rand (bzw. Edge) zu erfüllen. Bei einer Implementierung wird die Alu-Zählung um 64 weniger ALUs reduziert, während die Leistungsfähigkeit derselben Paketoperationen zugelassen wird.
  • 41A und 41B stellen beispielhafte terrestrische und Satellitenszenarien für Paketverarbeitung dar. Insbesondere zeigt 41A IPSec-Aggregationspunkte 100A-D, die in typischen 4G/LTE und 5G-Netzwerken verwendet werden, und 41B zeigt beispielhafte Routingpunkte 150A-D, die in typischen Satellitenkommunikationsnetzwerken verwendet werden. Die folgenden Ansätze reduzieren die Gesamtkomplexität der Handhabung notwendiger dynamischer Paketmodifikationen, während die Standardmodifikationen vorlagisiert werden. Dieses Merkmal kann in smartNICs, Netzwerkprozessoren und in FPGA-Implementierungen verwendet werden und bietet erhebliche Vorteile für die Verwendung bei der Satellitennetzwerkverarbeitung.
  • Im Kontext von 41A dargestellt, tritt ohne die Verwendung eines Vorlagenpaketmodifikators eine höhere Latenz auf. Diese höhere Latenz beruht auf mehreren eindeutigen Paketverarbeitungs-Engines (z.B. bis zu 32 ALUs) und der Zeit, die jede Paketverarbeitungs-Engine benötigt, ihre jeweilige Operation durchzuführen. Somit kann es für IPSec, das in 5G Edge-to-Core aufgrund einer Modifikation pro Paket verwendet wird, ungefähr 64 Modifikationen pro ungefähr 30 Flüsse geben. Bei Verwendung des folgenden Vorlagen-PDT-Modifikators wird die Latenz reduziert, indem eine Einzelpaket-Engine mit Ersatzvorlagen verwendet wird, was nur die Verwendung einer gemeinsamen Engine (z.B. 1 Alu) erfordert.
  • Gleichermaßen ist in 41B eine latenzsensitive Umgebung dargestellt. Bei der Satellitenkonstellation kann ein LEO:FSA-Algorithmus (Finite State Automata - endliche Zustandsmaschinen) zum Bestimmen maximaler Effizienzen von Inter-Satelliten-Links verwendet werden, mit einem Explicit Load Balancing(ELB)-Algorithmus, der es benachbarten Satellitenentitäten ermöglicht, Informationen auszutauschen. Hier kann das LEO-Satellitennetzwerk auch prioritätsadaptives Routing (z.B. Verwenden eines Rasters für einen kürzesten Netzwerkpfad) bereitstellen.
  • Unterschiedliche Vorlagen können in Abhängigkeit von dem Ort oder der Art des durchzuführenden Routings verwendet werden. Vorlagen können beispielsweise Vorlagen für extreme Latenz und minimale Verarbeitungsfähigkeiten beinhalten, wie etwa unter Verwendung von nicht-terrestrischer in-Orbit-Hardwareverarbeitung mit begrenzten Hardwarefähigkeiten oder an anderer begrenzter Hardware, die sich an der Netzwerkgrenze, dem Netzwerkzugang oder in-Orbit befindet. Ohne einen Vorlagenpaketmodifikator kann eine höhere Latenz insbesondere für in-Orbit-Routingprotokolle erfahren werden. Im Gegensatz dazu gibt es mit dem folgenden Vorlagenpaketmodifikator weniger Latenz und weniger Hardwarekomponenten über die Verwendung einer Einzelpaket-Engine. Die Verwendung einer Einzelpaket-Engine mit Ersetzen-Vorlage verwendet eine gemeinsame Engine, die zum Routing basierend auf einem Standort anpassbar ist, sei es in terrestrischen oder Satellitennetzwerken.
  • 42 und 43 veranschaulichen Paketverarbeitungsarchitekturen, die für Edge-Computing verwendet werden, gemäß einem Beispiel. 42 veranschaulicht einen herkömmlichen Netzwerkprozessor 4200, der zum Durchführen von Operationen an Paketen für Netzwerkanwendungen, wie etwa IPSec oder DTLS, verwendet wird. Der Netzwerkprozessor 4200 beinhaltet eine ALU 202 mit einem Sonderzweckbefehlssatz. Die Alu 4202 bereitet Befehle zur Laufzeit vor, basierend auf Parametern, die aus den Eingangspaketen 4206 und der spezifischen Protokolleinstellung 4204 erhalten werden. Die Alu 4202 liefert die Befehle an die Modifikatorschaltung 4208 zum Durchführen der Modifikation an den Paketen. Ein typisches Paket durchläuft mehrere Stufen einer solchen Verarbeitung, wobei jede Stufe verschiedene Funktionen an den Paketen ausführt, bevor sie das Ende der Verarbeitungs-Pipeline erreichen.
  • Um einen hohen Durchsatz zu erreichen, werden mehrere Pakete parallel, im Wesentlichen gleichzeitig, verarbeitet, wobei jede Pipeline ihre eigene dedizierte Verarbeitungs-Engine benötigt. Die Verwendung von parallel angeordneten Netzwerkprozessoren zur Durchführung solcher Operationen an den Paketen ist in FEIGE. 43. Mehrere ALUs 4202A-4202M arbeiten auf Eingangspaketen. Die Pakete werden seriell durch Modifikatorschaltungen 4208A1-AN, 4208B1-BN, ..., 4208B1-BN verarbeitet. Eine solche Anforderung mehrerer Netzwerkverarbeitungselemente, bei denen jede Alu 4202 Befehle zur Laufzeit erzeugt, führt zu einem signifikanten Leistungsverbrauch und einer Siliciumfläche in einem typischen System.
  • Um den Nachteil zu überwinden, dass jede ALU Befehle zur Laufzeit in dem oben beschriebenen Netzwerkverarbeitungssystem erzeugt, ist in 44 ein befehlsvorlagenbasierter (CTB) Netzwerkprozessor 4400 vorgesehen. Die ausgeklügelte Alu in 43, die Befehle für die Modifikatorschaltung 208 zur Laufzeit erzeugt, wird durch eine einfache „Parameterersetzung“-Schaltungsanordnung 4400 in 44 , wobei Befehle für die Parameterersetzungsschaltungsanordnung 4402 von einem Befehlsvorlagenblock 4404 mit einer gewissen Parametermodifikation zur Laufzeit erhalten werden.
  • Der Netzwerkprozessor 4400 aus 44 implementiert ein befehlsvorlagenbasiertes Netzwerkverarbeitungsverfahren, das vor-vorbereitete Befehle mit Laufzeitparametern ersetzt, um Pakete in Vernetzungsanwendungen effizient zu verarbeiten. Dies führt zur Eliminierung mehrerer Paketverarbeitungs-Engines (z.B. Modifikatorschaltungsanordnung 4208) und deren Ersatz durch eine einzige Engine (z.B. CTB-Netzwerkprozessor 4400). Eine solche Lösung ist unter dem Gesichtspunkt von Latenzleistungsfähigkeits, Leistungs und Fläche stark optimiert.
  • Der Befehlsvorlagenblock 4404, der während der Initialisierung geladen wird, speichert Sätze von Befehlsvorlagen mit vor-vorbereiteten Befehlen. Jede Befehlsvorlage beinhaltet zwei Sätze von Befehlen: den Netzwerkbefehlssatz (NCS) und den Ersetzen-Befehlssatz (SCS). Der Netzwerkbefehlssatz beinhaltet Befehle, die durch den Modifikator 4406 in dem CTB-Netzwerkprozessor 4400 verwendet werden sollen, um das Paket zu modifizieren. Der Ersetzen-Befehlssatz beinhaltet Befehle, die durch den Parameterersetzungsblock 4402 verwendet werden, um die Netzwerkbefehle zu modifizieren, die gesetzt sind, bevor sie an den Modifikator 4406 gesendet werden, um Pakete zu modifizieren.
  • Der befehlsvorlagenbasierte Netzwerkprozessor 4400 wird basierend auf dem Protokoll eine Vorlage aus dem Befehlsvorlagenblock 4404 auswählen und der Parameterersetzungsblock 4402 wird den Ersetzen-Befehlssatz aus der ausgewählten Vorlage verwenden, um manche Felder in dem Netzwerkbefehlssatz unter Verwendung von Eingabeparametern zu ersetzen. Die Eingabeparameter werden von einer ALU 4408 empfangen. Der Netzwerkbefehlssatz wird dann an den Modifikator 4406 gesendet, um Modifikationen an den Paketen vorzunehmen.
  • Die Parameter, die dem Netzwerkprozessor 4400 bereitgestellt werden, liegen sowohl in einem festen Format als auch in den Vorlagen vor. Auf diese Weise arbeitet der Parameterersetzungsblock 4402 einfach zum Kopieren von Parametern in die Netzwerkbefehle, die basierend auf den Ersetzen-Befehlssätzen eingestellt sind. Der Befehlsvorlagenblock 4404 wird von allen Netzwerkprozessoren 4400 gemeinsam genutzt. Die Parameter werden durch die Alu 4408 zur Laufzeit für jedes Paket vorbereitet und werden Teil der von Stufe zu Stufe weitergeleiteten Paketmetadaten.
  • 45 stellt ein typisches System mit mehreren befehlsvorlagenbasierten Prozessoren dar, die dazu eingerichtet sind, Eingangspakete parallel zu verarbeiten. In jeder Stufe wird eine Vorlage verwendet, um den Ersetzen-Befehlssatz bereitzustellen, der verwendet wird, um den Netzwerkbefehlssatz basierend auf den Alu-Parametern zu modifizieren. ALU-Parameter werden in die Pipeline eingespeist und stehen jeder Stufe zur Verfügung. Eine einzige Vorlage kann weitergereicht und in jeder Stufe verwendet werden. Alternativ dazu kann eine Vorlage durch den Befehlsvorlagenblock 4404 für jede Stufe bereitgestellt werden. Die Vorlage kann eine sein, die für die bestimmte Stufe designt wurde.
  • 46 stellt ein weiteres Netzwerkverarbeitungsbeispiel bereit, um die Idee eines befehlsvorlagenbasierten Netzwerkverarbeitungsmechanismus zu veranschaulichen. In diesem Beispiel muss ein als „IV“ bezeichnetes Feld, das 16 Bytes aufweist, am Ortsversatz 52 in das Paket eingefügt werden. Ein Satz von Parametern 4600 wird durch eine ALU zugeliefert. Die Parameter 4600 beinhalten die 16-Byte IV-Daten, die IV-Länge, gemessen in Bytes (d. h. 16), und den IV-Ort in dem Paket von Versatz 52. Diese Werte für das IV-Feld befinden sich in den Parametern 4600, die sich an Adresse 20, 80 bzw. 90 befinden.
  • Eine Vorlage beinhaltet einen Netzwerkbefehl 4602. Der Netzwerkbefehl 4602 weist einen Einfügebefehl zum Einfügen des bei Versatz 10 befindlichen IV in den Netzwerkbefehlssatz 4602 auf. Der Einfügebefehl weist vier Felder auf, wobei jedes 1 Byte lang ist, außer dem pkt_Offset-Feld, das 4 Byte lang ist. Auf den Einfügebefehl folgen 32 Bytes, die zum Speichern von bis zu 32 Bytes an Daten verwendet werden. Der cmd_len ist die Länge des aktuellen Befehls, die für diesen Fall 40 Byte beträgt. valid_len ist die tatsächliche IV-Länge.. Der valid_len wird durch den Ersetzungsbefehl mit IV_len=16 aktualisiert. In dem Einfügebefehl ist der pkt_Offset die Stelle in dem Paket, an der die IV-Werte eingefügt werden, und in diesem Fall wird er durch den Ersetzen-Befehl mit einem Wert von 52 (pkt_IV_Offset-Wert in den Parametern 4600) aktualisiert.
  • Das Ersetzungsbefehlsformat ist einfach: Kopier, Quellversatz, Zielversatz, Länge. Dementsprechend, wie in 46 ist der erste KOPIER-Befehl „KOPIER 80, 11, 1“, was die Parameterersetzungsschaltungsanordnung anweist, den Parameter bei Versatz 80 aus den Parametern in den Versatz 11 in dem Netzwerkbefehlsteil der Vorlage mit einer Feldgröße (oder Länge) von 1 Byte zu kopieren. Gleichermaßen wird der KOPIER-Befehl „KOPIER 90, 12, 4“ den Inhalt des Parameters bei Versatz 90 zu Versatz 12 in dem Netzwerkbefehl kopieren, wodurch 4 Bytes Daten an diese Stelle in dem Netzwerkbefehl kopiert werden.
  • Der resultierende Netzwerkbefehl wird durch den Modifikator verwendet, der in diesem Fall 16 Bytes Daten am Paketversatz 52 einfügt und dann zum nächsten Befehl, der 40 Bytes entfernt ist, weitergeht.
  • Dementsprechend ersetzt dieser befehlsvorlagenbasierte Netzwerkverarbeitungsmechanismus effektiv vor-vorbereitete Befehle mit Laufzeitparametern, um Pakete in Hochleistungsvernetzungsanwendungen effizient zu verarbeiten. Dadurch entfallen mehrere Netzwerkverarbeitungs-Engines und nur eine gemeinsame Engine benötigt. Dies kann weit weniger ALUs erfordern und die Zeit zum Verarbeiten reduzieren.
  • Ähnlich den oben erörterten Ansätzen für IPSec kann diese Paketverarbeitungstechnik auf andere verschiedenste Routing-Protokolle zutreffen, einschließlich jenen, die in Satellitenkommunikationsnetzwerken verwendet werden. LEO-Satellitennetzwerkrouting kann „offline“ auf dem Boden durchgeführt werden und zum Einrichten der Pfade zwischen Satelliten- und Bodenknoten verwendet werden. Konstellationsknoten sind jedoch aufgrund von Orbitalverschiebungen, Offline-Knoten und/oder Sperrzonenbedienung dynamisch zeitvariabel. In Abhängigkeit davon, wie sich Anbieter diese Probleme annähern, können unterschiedliche Protokolle oder Satellit-zu-Satellit-Kommunikationstechnologien (z.B. Funk oder Laser) verwendet werden, um zum Beispiel die Verwendung von Inter-Satelliten-Links (ISLs) zu unterstützen oder Premium-Teilnehmer (wie etwa URLCC-ultra-zuverlässige Verbindungen mit niedriger Latenz) zu bedienen. Falls die Verarbeitung in einen Orbit verschoben wird, dann werden Latenz-, Leistungs- und simplistische Verarbeitung folglich zu einer wichtigen Überlegung, die mit dem oben erörterten befehlsvorlagenbasierten Netzwerkprozessor adressiert wird.
  • Ferner wird bei Verwendung minimaler Speicherdatenänderungen (um eine Verfälschung aufgrund von Weltraumsonnenstrahlung zu vermeiden) der Wert der Befehlsvorlagenverarbeitung ersichtlich. Dies ist insbesondere für diejenigen Protokolle, wie den asynchronen Transfermodus (ATM), von Vorteil, bei denen die virtuellen Knoten eingestellt sind und dynamisch auf kürzesten Weg eingestellt werden können. Unter Verwendung der vorliegenden Paketverarbeitungstechniken können somit dynamische Netzwerkverarbeitungsänderungen im Orbit - näher an dem tatsächlichen Pfad-Rerouting adressiert werden.
  • Zusätzlich dazu kann die Referenzarchitektur für die hier erörterte Paketverarbeitungsvorlage auch als Teil eines „regenerativen satellitenbefähigten NR-RAN mit verteiltem GNB“ als Teil eines verbesserten 5G-Netzwerks erweitert werden. Hier kann die gNB-DU (DU: distributed unit - verteilte Einheit) an einem Satelliten gehostet werden und daher werden manche der NR-Protokolle durch das An-Bord an dem Satelliten unter Verwendung einer in-Orbit-DU verarbeitet. Im Gegensatz dazu befinden sich existierende Einsätze für eine vRAN-DU am Boden. Man betrachte ein Beispiel dafür, dass Rerouting vorgenommen werden muss, wenn es eine plötzliche Änderung der Verkehrslast gibt, die eine Überlastung verursacht, und es keine Zeit gibt, darauf zu warten, dass bodengestütztes (Offline-) Routing stattfindet, sodass der Satellit einspringen muss. In dieser Situation können niedrige Latenz, begrenzte Verarbeitungsfähigkeit und unmittelbare Antwort durch die vorliegenden Paketvorlagenverarbeitungstechniken an der Satellitenkommunikationshardware bereitgestellt werden.
  • 47 liefert ein Flussdiagramm 4700 einer vorlagenbasierten Paketverarbeitungstechnik. Dieses Flussdiagramm beginnt bei Operation 4710 mit einem Anfangsschritt (in nachfolgenden Schritten optional) zum Konfigurieren und Erhalten der Vorlagen zur Datenverarbeitung, wie oben unter Bezugnahme auf den Befehlsvorlagenblock 4404 erörtert. Das Flussdiagramm fährt bei Operation 4720 mit dem Empfang eines oder mehrerer Pakete aus einem Paketstrom fort, die mit dem CTB-Netzwerkprozessor 4400 wie folgt verarbeitet werden.
  • Bei Operation 4730 arbeitet die Alu 4408 dazu, Parameter zur Modifikation des einen oder der mehreren Pakete zu erzeugen und bereitzustellen. Die Vorlage, die aus dem Befehlsvorlagenblock 4404 erhalten wird, wird dann bei Operation 4740 bereitgestellt und zur anfänglichen Parameterersetzung, wie zum Beispiel durch den Parameterersetzungsblock 4402, verwendet. Die anfängliche Parameterersetzung bei Operation 4740 stellt Ersetzungsbefehle bereit, die verwendet werden können zum Modifizieren der besonderen Art von Paket, das verarbeitet wird.
  • Bei Operation 4750 werden die Ersetzungsbefehle angewendet, um das eine oder die mehreren verarbeiteten Pakete basierend auf den in der Vorlage bereitgestellten ersetzten Parametern zu modifizieren. Diese Operation kann durch den Modifikator 4406 durchgeführt werden, wie oben erörtert wurde. Solche Ersetzungsbefehle können iterativ durchgeführt werden, um Pakete an mehreren Stufen zu modifizieren, wie dies in 1 gezeigt IST. 45. Schließlich können bei Operation 4760 modifizierte Pakete von dem Netzwerkprozessor ausgegeben und in dem Netzwerkszenario kommuniziert oder weiter verwendet werden.
  • Weitere beispielhafte Implementierungen beinhalten die folgende Vorrichtungskonfiguration und Verfahren, die durch die folgende Konfiguration und ähnliche Netzwerkverarbeitungsvorrichtungen durchgeführt werden.
  • Beispiel I1 ist eine Netzwerkpaketverarbeitungsvorrichtung, die Folgendes umfasst: Eine Netzwerkschnittstelle zum Empfangen eines Stroms von Paketen; eine arithmetische Logikeinheit (Alu); einen Befehlsvorlagenspeicher; und eine Schaltungsanordnung, die eine Vielzahl von Verarbeitungskomponenten umfasst, die mit der Alu und dem Befehlsvorlagenspeicher verbunden sind, Wobei die Vielzahl von Verarbeitungskomponenten in parallelen Gruppen serieller Pipelines angeordnet ist, wobei jede Pipeline eine erste Stufe und eine zweite Stufe beinhaltet, wobei Verarbeitungskomponenten in der ersten Stufe Parameter von der Alu empfangen und die Parameter zum Modifizieren von Befehlen in einer Vorlage verwenden, die von der Befehlsvorlagenablage empfangen wird, Die modifizierten Befehle, die zum Modifizieren eines Pakets in dem Strom von Paketen verwendet werden.
  • Bei Beispiel I2 beinhaltet der Gegenstand von Beispiel I1 optional einen Gegenstand, bei dem die von der Befehlsvorlagenablage empfangene Vorlage einen Netzwerkbefehl und einen entsprechenden Ersetzen-Befehl umfasst, wobei der Ersetzen-Befehl die von der Alu empfangenen Parameter verwendet, um den Netzwerkbefehl zu revidieren.
  • Bei Beispiel i3 beinhaltet der Gegenstand des Beispiels I2 optional einen Gegenstand, bei dem der Netzwerkbefehl eine verallgemeinerte Befehlsstruktur ist.
  • Bei Beispiel I4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I2 bis i3 optional einen Gegenstand, bei dem sich der Netzwerkbefehl auf eine Art von Paket bezieht, das aus dem Strom von Paketen verarbeitet wird.
  • Bei Beispiel i5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis I4 optional einen Gegenstand, bei dem die Alu die einzige Alu in der Netzwerkpaketverarbeitungsvorrichtung ist.
  • Bei Beispiel I6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis i5 optional einen Gegenstand, bei dem eine Verarbeitungskomponente in der ersten Stufe ein revidiertes Paket basierend auf den Befehlen in der Vorlage ausgibt, Und eine Verarbeitungskomponente in der zweiten Stufe empfängt das revidierte Paket und modifiziert es ferner basierend auf der Vorlage.
  • Bei Beispiel i7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis 16 optional einen Gegenstand, bei dem eine Verarbeitungskomponente in der ersten Stufe ein revidiertes Paket basierend auf den Befehlen in der Vorlage ausgibt, Und eine Verarbeitungskomponente in der zweiten Stufe empfängt das revidierte Paket und modifiziert es ferner basierend auf einer zweiten Vorlage, die von dem Vorlagenspeicher empfangen wird.
  • Bei Beispiel 18 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis i7 optional einen Gegenstand, bei dem jede der Verarbeitungskomponenten in der ersten Stufe auf einer gleichen Art von Paket arbeitet, das gemäß einem Netzwerkkommunikationsprotokoll bereitgestellt wird.
  • Bei Beispiel I9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis I8 optional einen Gegenstand, bei dem die Netzwerkpaketverarbeitungsvorrichtung in Netzwerkverarbeitungshardware eines Niedrigerdorbit-Satellitenfahrzeugs eingesetzt wird.
  • Bei Beispiel 110 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis I9 optional einen Gegenstand, bei dem der Strom von Paketen von einer ersten Art von Netzwerkkommunikationsprotokoll ist, Und die Vielzahl von Verarbeitungskomponenten dafür verwendet wird, den Strom von Paketen in eine zweite Art von Netzwerkkommunikationsprotokoll umzuwandeln.
  • Bei Beispiel I11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis 110 optional den Gegenstand, bei dem die Befehlsvorlagenablage eine oder mehrere Vorlagen für vorbestimmte Routingprotokolle bereitstellt, die mit satellitenbasierter Vernetzung verwendet werden.
  • Bei Beispiel 112 beinhaltet der Gegenstand eines oder mehrerer der Beispiele I1 bis 111 optional einen Gegenstand, bei dem die Schaltungsanordnung durch eine anwendungsspezifische integrierte Schaltung (ASIC) bereitgestellt wird.
  • Bei Beispiel 113 weist der Gegenstand eines oder mehrerer der Beispiele I1 bis 112 optional einen Gegenstand auf, bei dem die Vielzahl von Verarbeitungskomponenten eine Vielzahl von Netzwerkprozessoren umfasst.
  • Implementierung in Edge-Computing-Szenarien
  • Es versteht sich, dass die vorliegenden terrestrischen und nicht-terrestrischen Vernetzungsanordnungen mit vielen Aspekten von Edge-Computing-Strategien und Einsatzgebieten integriert sein können. Edge-Computing bezeichnet auf allgemeiner Ebene den Übergang von Rechen- und Speicherressourcen näher an Endpunktvorrichtungen (z. B. Endverbraucher-Rechenvorrichtungen, Endgeräte usw.), um die Gesamtbetriebskosten zu optimieren, eine Anwendungslatenz zu reduzieren, Dienstfunktionalitäten zu verbessern und eine Einhaltung von Sicherheits- oder Datenschutzanforderungen zu verbessern. Edge-Computing kann in einigen Szenarien einen cloudähnlichen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung von Anwendungen unter vielen Arten von Speicher- und Rechenressourcen bietet. Als Ergebnis wurden einige Implementierungen von Edge-Computing als die „Edge-Cloud“ oder der „Fog“ bezeichnet, wenn leistungsstarke Rechenressourcen, die vorher nur in großen entfernten Rechenzentren verfügbar waren, näher an Endpunkte bewegt werden und Endverbrauchern am „Rand“ des Netzwerks zur Verwendung zur Verfügung gestellt werden.
  • Im Kontext von Satellitenkommunikationsnetzwerken können Edge-Computing-Operationen, wie oben besprochen, auftreten durch: Bewegen von Arbeitslasten auf Rechenanlagen an Satellitenfahrzeugen; Verwenden von Satellitenverbindungen, um Backup- oder (redundante) Links und Verbindungen zu Diensten mit niedrigerer Latenz anzubieten; Koordinieren von Arbeitslastverarbeitungsoperationen an terrestrischen Zugangspunkten oder Basisstationen; Bereitstellen von Daten und Inhalt über Satellitennetzwerke; und dergleichen. Somit sind viele der gleichen Edge-Computing-Szenarien, die unten für Mobilnetzwerke und Mobilclientvorrichtungen beschrieben sind, gleichermaßen anwendbar, wenn ein nichtterrestrisches Netzwerk verwendet wird.
  • 48 ist ein Blockdiagramm 4800, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der aktuellen Beispiele als eine „Edge-Cloud“ bezeichnet wird. Diese Netzwerktopologie, die eine Anzahl herkömmlicher Vernetzungsschichten (einschließlich der hier nicht gezeigten) beinhalten kann, kann durch die Verwendung der hier erörterten Satelliten- und nicht-terrestrischen Netzwerkkommunikationsanordnungen erweitert werden.
  • Wie gezeigt, befindet sich die Edge-Cloud 4810 gemeinsam an einem Randort, wie etwa einem Satellitenfahrzeug 4841, einer Basisstation 4842, einem lokalen Verarbeitungs-Hub 4850 oder einer Zentrale 4820, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 4810 befindet sich viel näher an den Endpunkt(Verbraucher und Erzeuger)-Datenquellen 4860 (z.B. autonome Fahrzeuge 4861, Benutzergerät 4862, Geschäfts- und Industriegerät 4863, Videoaufnahmevorrichtungen 4864, Drohnen 4865, intelligente Städte und Gebäudevorrichtungen 4866, Sensoren und IoT-Vorrichtungen 4867 usw.). Als das Cloud-Datenzentrum 4830. Rechen-, Speicher und Speicherungsressourcen, die an den Rändern in der Edge-Cloud 4810 angeboten werden, sind kritisch für das Bereitstellen ultraniedriger oder verbesserter Latenzantwortzeiten für Dienste und Funktionen, die von den Endpunktdatenquellen 4860 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 4810 zu dem Cloud-Datenzentrum 4830, wodurch, unter anderen Nutzen, Energieverbrauch und Gesamtnetzwerknutzungen verbessert werden.
  • Rechenleistung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (z.B. sind weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen als an einer Basisstation oder an einer Zentralstelle verfügbar). Je näher jedoch der Edge-Standort am Endpunkt (z.B. UEs) liegt, desto mehr sind Platz und Leistung begrenzt. Somit versucht Edge-Computing als allgemeines Gestaltungsprinzip, die Menge der für Netzwerkdienste benötigten Ressourcen durch die Verteilung von mehr Ressourcen zu minimieren, die sowohl geografisch als auch in Bezug auf die Netzwerkzugriffszeit näher liegen. Bei dem Szenario des nicht-terrestrischen Netzwerks können Entfernung und Latenz weit zu dem und von dem Satelliten sein, aber Datenverarbeitung kann besser an der Edge-Computing-Hardware in dem Satellitenfahrzeug erreicht werden, anstatt zusätzliche Datenverbindungen und Netzwerkbackhaul zu und von der Cloud zu erfordern.
  • Bei einem Beispiel erstreckt sich eine Edge-Cloud-Architektur über typische Einsatzbeschränkungen hinaus auf Adressbeschränkungen, die manche Netzbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese umfassen:, Variationen von Konfigurationen basierend auf dem Edge-Standort (weil beispielsweise Ränder auf Basisstationsebene eine stärker eingeschränkte Leistungsfähigkeit aufweisen können); Konfigurationen basierend auf der Art von Rechenleistung, Speicher, Speicherung, Fabric, Beschleunigung oder ähnlichen Ressourcen, die für Edge-Standorte, Standortstufen oder Standortgruppen verfügbar sind; die Dienst-, Sicherheits- und Verwaltung- und Orchestrierungsfähigkeiten; und damit verbundene Ziele, um die Benutzerfreundlichkeit und Leistungsfähigkeit der Enddienste zu erreichen.
  • Edge-Computing ist ein sich entwickelndes Paradigma, bei dem die Berechnung an oder näher am „Rand“ eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform, die in Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die viel näher an Endpunktvorrichtungen sind, die die Daten produzieren und konsumieren. Edge-Gateway-Server können zum Beispiel mit Pools von Speicher- und Speicherungsressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Verwendungsfälle mit niedriger Latenz (z.B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Benutzergeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Oder als anderes Beispiel kann die Zentralstellennetzverwaltungshardware durch Rechenhardware ersetzt werden, die virtualisierte Netzfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen anbietet. Gleichermaßen kann es innerhalb von Edge-Computing-Einsätzen Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „bewegt“ wird, sowie Szenarien geben, in denen die Daten zu der Rechenressource „bewegt“ werden. Oder als ein Beispiel können Basisstations- (oder Satellitenfahrzeug-) Rechen-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf durch Aktivieren ruhender Kapazität (Abonnement, Kapazität auf Abruf) zu skalieren, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen signifikant längeren implementierten Lebenszyklus bereitzustellen.
  • Im Gegensatz zur Netzarchitektur von 48 sind herkömmliche Endpunkt-Anwendungen (z.B. UE, Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Alles (V2X) usw.) auf lokale Vorrichtungs- oder Remote-Cloud-Datenspeicherung und -verarbeitung angewiesen, um Informationen auszutauschen und zu koordinieren. Eine Cloud-Datenanordnung ermöglicht eine langfristige Datensammlung und -speicherung, ist jedoch für stark zeitvariable Daten, wie eine Kollision, einen Ampelwechsel usw. nicht optimal und kann beim Versuch fehlschlagen, Latenzherausforderungen zu erfüllen. Die Erweiterung von Satellitenfähigkeiten innerhalb eines Edge-Computing-Netzwerks stellt noch mehr mögliche Permutationen des Verwaltens von Rechnen, Daten, Bandbreite, Ressourcen, Dienstleistungen und dergleichen bereit.
  • Abhängig von den Echtzeitanforderungen in einem Kommunikationskontext kann eine hierarchische Struktur von Datenverarbeitungs- und Speicherungsknoten in einem Edge-Computing-Einsatz durch Einbeziehen von Satellitenkonnektivität definiert werden. Ein solcher Einsatz kann beispielsweise lokale Verarbeitung mit ultraniedriger Latenz, regionale Speicherung und Verarbeitung sowie auf einem abgesetzten Cloud-Datenzentrum basierende Speicherung und Verarbeitung umfassen. Leistungskennzahlen (KPIs: Key Performance Indicators) können dafür verwendet werden, zu identifizieren, wo Sensordaten am besten transferiert und wo sie verarbeitet oder gespeichert werden sollen. Dies hängt typischerweise von der ISO-Schicht-Abhängigkeit der Daten ab. Beispielsweise ändern sich Daten einer niedrigeren Schicht (PHY, MAC, Routing usw.) typischerweise schnell und werden besser lokal gehandhabt, um die Latenzanforderungen zu erfüllen. Daten höherer Schichten, wie Daten der Anwendungsschicht, sind typischerweise weniger zeitkritisch und können in einem abgesetzten Cloud-Datenzentrum gespeichert und verarbeitet werden.
  • 49 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen. Insbesondere stellt 49 Beispiele für Rechenverwendungsfälle 4905 dar, die die Edge-Cloud 4810 unter mehreren veranschaulichenden Schichten des Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunkt- (Vorrichtungen und Dinge) Schicht 4900, die auf die Edge-Cloud 4810 zugreift, um Datenerzeugungs-, Analyse- und Datenverbrauchsaktivitäten durchzuführen. Die Edge-Cloud 4810 kann mehrere Netzwerkschichten umspannen, wie etwa eine Edge-Vorrichtungsschicht 4910 mit Gateways, Servern vor Ort oder Netzwerkgeräten (Knoten 4915), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 4920, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionale Rechenzentren (DC) oder lokale Netzwerkgeräte (Geräte 4925); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 4912, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 4810 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
  • Beispiele für Latenz mit terrestrischen Netzwerken, die aus Netzwerkkommunikationsdistanz- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn unter der Endpunktschicht 4900, unter 5 ms an der Edge-Vorrichtungen-Schicht 4910, bis sogar zwischen 10 und 40 ms reichen, wenn mit Knoten in der Netzwerkzugangsschicht 4920 kommuniziert wird. (Eine Variation dieser Latenzen wird bei Verwendung von nicht-terrestrischen Netzwerken erwartet). Jenseits der Edge-Cloud 4810 befinden sich Schichten des Kernnetzwerks 4930 und des Cloud-Datenzentrums 4940, jeweils mit zunehmender Latenz (z.B. zwischen 50-60 ms an der Kernnetzwerkschicht 4930 bis 100 oder mehr ms an der Cloud-Datenzentrumsschicht). Infolgedessen werden Operationen in einem Kernnetz-Rechenzentrum 4935 oder einem Cloud-Rechenzentrum 4945 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Anwendungsfälle 4905 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. In einigen Beispielen können jeweilige Abschnitte des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als Schichten „Close Edge“, „Local Edge“, „Near Edge“, „Middle Edge“ oder „Far Edge“ kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetz-Rechenzentrums 4935 oder eines Cloud-Rechenzentrums 4945 ein Zentralen- oder Inhaltsdatennetzwerk als innerhalb einer „Near Edge“-Schicht („nahe“ an der Cloud, mit hohen Latenzwerten beim Kommunizieren mit den Vorrichtungen und Endpunkten der Anwendungsfälle 4905) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Server vor Ort oder ein Netzwerk-Gateway als innerhalb einer „Far Edge“-Schicht („fern“ von der Cloud entfernt, mit niedrigen Latenzwerten beim Kommunizieren mit den Vorrichtungen und Endpunkten der Anwendungsfälle 4905) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als eine „Close“, „Local“, „Near“, „Middle“ oder „Far“ Edge bildend auf Latenz, Entfernung, Anzahl von Netzwerksprüngen oder anderen messbaren Charakteristiken basieren können, wie von einer Quelle in einer beliebigen der Netzwerkschichten 4900-4940 gemessen.
  • Die diversen Anwendungsfälle 4905 können auf Ressourcen unter Nutzungsdruck von eingehenden Strömen aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 4810 ausgeführt werden, variierende Anforderungen in Bezug auf Folgendes aus: (A) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS) (z.B. kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Reaktionszeit aufweisen; oder eine Performanzempfindlichkeit/Engstelle kann je nach Anwendung an einer Rechen-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource existieren); (b) Zuverlässigkeit und Resilienz (z.B. manche Eingangsströme müssen bearbeitet werden und der Verkehr mit missionskritischer Zuverlässigkeit geroutet werden, wobei, wenn manche anderen Eingangsströme je nach Anwendung ein gelegentliche Ausfälle tolerieren können); und (c) physische Einschränkungen (z.B. Leistung, Kühlung und Formfaktor).
  • Die Ende-zu-Ende-Dienstansicht für diese Anwendungsfälle beinhaltet den Begriff eines Dienstflusses und ist einer Transaktion zugeordnet. Die Transaktion gibt die Gesamtdienstanforderung für die Entität an, die den Dienst verbraucht, sowie die zugehörigen Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Geschäftsfunktions- und Geschäftsebenenanforderungen. Die Dienste, die mit den beschriebenen „Bedingungen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihre vereinbarte SLA fehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten in dem System zu erweitern, um die gesamte Transaktions-SLA wiederaufzunehmen, Und (3) Implementieren von Schritten zur Behebung.
  • Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 4810 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 4905 (z. B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu versorgen und auf diese zu reagieren und Voraussetzungen für ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (virtuelle Netzwerkfunktionen (VNFs), Funktion als Dienst (FaaS), Edge als Dienst (EaaS) usw.), die herkömmliches Cloud-Computing aufgrund von Latenz- oder anderen Einschränkungen nicht ausnutzen können. Dies ist insbesondere für Anwendungen, die eine Verbindung mit der Cloud über Satellit erfordern, und die zusätzliche Latenz, die Umläufe über Satellit benötigen würden, relevant.
  • Mit den Vorteilen des Edge-Computing ergeben sich jedoch die folgenden Vorbehalte. Die am Edge befindlichen Vorrichtungen sind häufig ressourcenbeschränkt, sodass Druck auf die Nutzung von Edge-Ressourcen besteht. Typischerweise wird dies durch das Zusammenfassen von Arbeitsspeicher- und Massenspeicherressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Die Edge kann in Leistung und Kühlung eingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen, die die meiste Leistung verbrauchen, berücksichtigt werden muss. Es kann inhärente Leistungs-Leistungsfähigkeits-Kompromisse in diesen gebündelten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen für mehr Leistung eine größere Speicherbandbreite notwendig ist. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Root-of-Trust-Funktionen auch erforderlich, da Edge-Standorte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (z.B. wenn sie an einem Drittparteistandort untergebracht sind). Derartige Probleme werden in der Edge-Cloud 4810 in einer Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffssituation vergrößert, bei der Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere, da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Beteiligten, Anwendungsfälle und Dienste ändert.
  • Auf einer allgemeineren Ebene kann ein Edge-Rechensystem so beschrieben werden, dass es eine beliebige Anzahl von Bereitstellungen in den zuvor besprochenen Schichten umfasst, die in der Edge-Cloud 4810 arbeiten (Netzwerkschichten 4900-4940), die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gatewayknoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kernrechenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), eines Internet-der-Dinge-Dienstanbieters, eines Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Computing-Systems können dynamisch bereitgestellt werden, wie etwa, wenn orchestriert, um Dienstziele zu erfüllen.
  • Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -schaltungsanordnung, - vorrichtung, -gerät oder ein anderes zum Kommunizieren als ein Erzeuger oder Verbraucher von Daten fähiges Ding realisiert sein. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie in dem Edge-Rechensystem verwendet, nicht notwendigerweise, dass ein solcher Knoten oder eine derartige Vorrichtung in einer Client- oder Agenten-/Minion-/Folger-Rolle arbeitet; Stattdessen beziehen sich beliebige der Knoten oder Vorrichtungen in dem Edge-Computing-System auf einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 4810 zu ermöglichen oder zu verwenden.
  • Von daher ist die Edge-Cloud 4810 aus Netzwerkkomponenten und Funktionsmerkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 4910-4930 betrieben werden. Die Edge-Cloud 4810 kann somit als eine beliebige Art von Netzwerk ausgebildet sein, das Edge-Rechen- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z.B. Mobilrechenvorrichtungen, IoT-Vorrichtungen, Smartvorrichtungen usw.) befinden, die vorliegend besprochen sind. Anders ausgedrückt kann man sich die Edge-Cloud 4810 als ein „Rand“ vorstellen, der die Endpunktvorrichtungen und herkömmliche Netzwerkzugangspunkte verbindet, die als ein Zugriffspunkt zu Kernnetzen von Dienstanbietern dienen, einschließlich Netzwerken von mobilen Trägern (z.B. Netzwerke des Global System for Mobile Communications (GSM), Long-Term-Evolution(LTE)-Netzwerke, 5G/6G-Netzwerke usw.), während er auch Speicher- oder Rechenfunktionen bereitstellt. Andere Arten und Formen des Netzwerkzugriffs (z. B. WiFi, drahtlose, verdrahtete Langstreckennetze einschließlich optischer Netzwerke) können auch anstatt oder in Kombination mit derartigen 3GPP-Trägernetzen eingesetzt werden.
  • Die Netzwerkkomponenten der Edge-Cloud 4810 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann ein Knoten Edge-Cloud 4810 eine Geräte-Computing-Vorrichtung beinhalten, die eine eigenständige elektronische Vorrichtung ist und ein Gehäuse, ein Chassis, einen Behälter oder eine Einhausung beinhaltet. Unter Umständen kann das Gehäuse für Portabilität dimensioniert sein, so dass es von einem Menschen getragen und/oder versandt werden kann. Beispielhafte Gehäuse können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (z.B. EMI, Vibration, extreme Temperaturen) beinhalten kann und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Einhausungen können Leistungsschaltungsanordnungen beinhalten, um Leistung für stationäre und/oder tragbare Implementierungen bereitzustellen, wie etwa AC-Leistungseingänge, DC-Leistungseingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnungen, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Beispielhafte Einhausungen und/oder Oberflächen davon können Montagehardware beinhalten oder mit dieser verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (z.B. Masten, Antennenstrukturen usw.) und/oder Racks (z. B. Server-Racks, Bladebefestigungen usw.), zu ermöglichen. Beispielhafte Gehäuse und/oder Oberflächen davon können einen oder mehrere Sensoren (z.B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, Kapazitive Sensoren, Näherungssensoren usw.). Ein oder mehrere derartiger Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderweitig eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Einhausungen und/oder Oberflächen davon können mechanische Konnektivität unterstützen, wie etwa Antriebshardware (z.B. Räder, Propeller usw.) und/oder Gelenkhardware (z.B. Roboterarme, schwenkbare Anhänge usw.). Unter manchen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellenhardware (z.B. Tasten, Schalter, Wählscheiben, Schieber, Usw.). Unter manchen Umständen beinhalten beispielhafte Einhausungen Ausgabevorrichtungen, die darin enthalten sind, dadurch getragen werden, darin eingebettet und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Ports (z.B. USB) usw. beinhalten. Unter manchen Umständen sind Edge-Vorrichtungen Vorrichtungen, die im Netzwerk für einen spezifischen Zweck (z.B. eine Verkehrsampel) präsentiert werden, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Derartige Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und können mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für ihren primären Zweck geeignet ist; sie ist aber dennoch für andere Rechenaufgaben verfügbar, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Vorrichtungen des Internets der Dinge. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Probleme, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Stromprobleme, Physische und Netzwerksicherheit usw. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 52B. Die Edge-Cloud 4810 kann auch einen oder mehrere Server und/oder einen oder mehrere Multi-Mandanten-Server beinhalten. Ein solcher Server kann ein Betriebssystem beinhalten und eine virtuelle Rechenumgebung implementieren. Eine virtuelle Rechenumgebung kann einen Hypervisor beinhalten, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (z.B. erzeugt, einsetzt, zerstört usw.). Solche virtuellen Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, Code oder Skripte können ausgeführt werden, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
  • In 50 tauschen verschiedene Client-Endpunkte 5010 (in der Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 5010 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 5022 durch ein Vor-Ort-Netzwerksystem 5032 ausgetauscht werden. Manche Client-Endpunkte 5010, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 5024 durch einen Zugangspunkt (z. B. Mobilfunknetzturm) 5034 ausgetauscht werden. Manche Client-Endpunkte 5010, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anfragen und Antworten 5026 über ein drahtloses Fahrzeugnetzwerk durch ein auf Straßen angeordnetes Netzwerksystem 5036 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 5042, 5044 innerhalb der Edge-Cloud 4810 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 4810 verschiedene Rechen- und Speicherungsressourcen einsetzen, wie etwa an Edge-Aggregationsknoten 5040 (einschließlich jener, die sich auf Satellitenfahrzeugen befinden), um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 5040 und andere Systeme der Edge-Cloud 4810 sind mit einer Cloud oder einem Datenzentrum 5060 verbunden, das ein Backhaul-Netzwerk 5050 (wie etwa einen Satelliten-Backhaul) verwendet, um Anfragen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver, zu erfüllen. Usw. zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 5040 und der Aggregationspunkte 5042, 5044, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 4810 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
  • Auf einer generischeren Ebene kann ein Edge-Computing-System so beschrieben werden, dass es eine beliebige Anzahl von Einsätzen einschließt, die in der Edge-Cloud 4810 arbeiten, die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. 49 stellt zu Veranschaulichungszwecken einen weiteren abstrahierten Überblick über Schichten verteilter Berechnung bereit, die in einer Edge-Computing-Umgebung eingesetzt werden.
  • 51 stellt generisch ein Edge-Computing-System zum Bereitstellen von Edge-Diensten und Anwendungen an Multi-Stakeholder-Entitäten dar, wie sie unter einem oder mehreren Client-Rechenknoten 5102, einem oder mehreren Edge-Gateway-Knoten 5112, einem oder mehreren Edge-Aggregationsknoten 5122, einem oder mehreren Core-Datenzentren 5132 und einer globalen Netzwerk-Cloud 5142 verteilt sind, wie sie über Schichten des Netzwerks hinweg verteilt sind. Die Implementierung des Edge-Computing-Systems kann bei einem oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), Internet-der-Dinge-Dienstanbieters, Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitgestellt werden.
  • Jeder Knoten oder jede Vorrichtung des Edge-Computing-Systems befindet sich auf einer speziellen Schicht, die den Schichten 4900, 4910, 4920, 4930, 4940 entspricht. Zum Beispiel befinden sich die Client-Rechenknoten 5102 jeweils auf einer Endpunktschicht 4900, während sich jeder der Edge-Gateway-Knoten 5112 auf einer Edge-Vorrichtungsschicht 4910 (lokale Ebene) des Edge-Computing-Systems befindet. Zusätzlich dazu befindet sich jeder der Edge-Aggregationsknoten 5122 (und/oder Fog-Vorrichtungen 5124, falls sie mit oder unter einer Fog-Netzwerkkonfiguration 5126 angeordnet oder betrieben werden) auf einer Netzwerkzugangsschicht 4920 (einer Zwischenebene). Fog-Computing (oder „Fogging“) bezieht sich allgemein auf Erweiterungen von Cloud-Computing zum Rand eines Netzwerks eines Unternehmens, typischerweise in einem koordinierten verteilten oder Mehrknotennetzwerk. Einige Formen des Fog-Computing sehen den Einsatz von Rechen-, Speicher- und Netzwerkdiensten zwischen Endvorrichtungen und Cloud-Computing- Rechenzentren im Auftrag der Cloud-Computing-Standorte vor. Solche Formen von Fog-Computing stellen Operationen bereit, die mit Edge-Computing, wie hierin erörtert, konsistent sind; viele der hierin erörterten Edge-Computing-Aspekte sind auf Fog-Netzwerke, Fogging und Fog-Konfigurationen anwendbar. Ferner können Gesichtspunkte der hierin besprochenen Edge-Rechensysteme als ein Fog konfiguriert sein oder Gesichtspunkte eines Fogs können in eine Edge-Rechenarchitektur integriert sein.
  • Das Kerndatenzentrum 5132 befindet sich auf einer Kernnetzwerkschicht 4930 (z.B. einer regionalen oder geografisch zentralen Ebene), während sich die globale Netzwerk-Cloud 5142 auf einer Cloud-Datenzentrumschicht 4940 (z.B. einer nationalen oder globalen Schicht) befindet. Die Verwendung von „Kern“ ist als Begriff für einen zentralisierten Netzwerkort - tiefer im Netzwerk - vorgesehen, auf den mehrere Edge-Knoten oder Komponenten zugreifen können; ein „Kern“ bezeichnet jedoch nicht notwendigerweise den „Mittelpunkt“ oder den tiefsten Ort des Netzwerks. Dementsprechend kann das Kernrechenzentrum 5132 innerhalb, in oder nahe der Edge-Cloud 4810 angeordnet sein.
  • Obwohl eine veranschaulichende Anzahl von Client-Rechenknoten 5102, Edge-Gateway-Knoten 5112, Edge-Aggregationsknoten 5122, Kerndatenzentren 5132, globalen Netzwerk-Clouds 5142 in 51 versteht es sich, dass das Edge-Computing-System mehr oder weniger Vorrichtungen oder Systeme auf jeder Schicht beinhalten kann. Außerdem nimmt, wie in 51 gezeigt, die Anzahl von Komponenten jeder Schicht 4900, 4910, 4920, 4930, 4940 allgemein auf jeder niedrigeren Ebene zu (d. h. wenn man sich näher an Endpunkte bewegt). Von daher kann ein Edge-Gateway-Knoten 5112 mehrere Client-Rechenknoten 5102 bedienen und ein Edge-Aggregationsknoten 5122 kann mehrere Edge-Gateway-Knoten 5112 bedienen.
  • Im Einklang mit den hierin bereitgestellten Beispielen kann jeder Client-Rechenknoten 5102 als eine beliebige Art von Endpunktkomponente, -Vorrichtung, -Gerät oder „Ding“ umgesetzt sein, die in der Lage ist, als ein Produzent oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie in dem Edge-Rechensystem verwendet, nicht notwendigerweise, dass ein solcher Knoten oder eine derartige Vorrichtung in einer Client- oder Agenten-/Minion-/Folger-Rolle arbeitet; Stattdessen beziehen sich beliebige der Knoten oder Vorrichtungen in dem Edge-Computing-System auf einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 4810 zu ermöglichen oder zu verwenden.
  • Von daher ist die Edge-Cloud 4810 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die durch und innerhalb der Edge-Gateway-Knoten 5112 bzw. der Edge-Aggregationsknoten 5122 der Schichten 4920, 4930 betrieben werden. Die Edge-Cloud 4810 kann als ein beliebiger Typ von Netzwerk ausgebildet sein, der Edge-Computing- und/oder Speicherressourcen bereitstellt, die in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z. B. mobilen Rechenvorrichtungen, IdD-Vorrichtungen, intelligenten Vorrichtungen usw.) angeordnet sind, die in 49 als die Client-Rechenknoten 5102 gezeigt sind. Mit anderen Worten kann die Edge-Cloud 4810 als ein „Edge“ vorgesehen sein, der die Endpunktvorrichtungen und herkömmlichen Mobilnetzzugangspunkten verbindet, die als ein Eintrittspunkt in Dienstanbieterkernnetzwerke dienen, einschließlich Trägernetzwerken (z.B. Global System for Mobile Communications (GSM) -Netzwerke, Long Term Evolution (LTE) -Netzwerke, 5G Netzwerke usw.), während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (z.B. WiFi, drahtlose Netzwerke mit großer Reichweite) können auch anstelle von oder in Kombination mit solchen 3GPP Trägernetzwerken genutzt werden.
  • In einigen Beispielen kann die Edge-Cloud 4810 einen Abschnitt einer Fog-Netzwerkkonfiguration 5126 (z. B. eines Netzwerks der Fog-Vorrichtungen 5124, nicht im Detail gezeigt) bilden oder anderweitig einen Zugangspunkt in diese oder über diese hinweg bereitstellen, der als eine horizontale und verteilte Architektur auf Systemebene ausgebildet sein kann, die Ressourcen und Dienste verteilt, um eine bestimmte Funktion durchzuführen. Ein koordiniertes und verteiltes Netzwerk der Fog-Vorrichtungen 5124 kann beispielsweise Rechnen, Speicherung, Steuerung oder Netzwerkgesichtspunkte im Kontext einer IdD-Systemanordnung durchführen. Andere vernetzte, aggregierte und verteilte Funktionen können in der Edge-Cloud 4810 zwischen der Cloud-Datenzentrumschicht 4940 und den Client-Endpunkten (z.B. Client-Rechenknoten 5102) existieren. Einige dieser werden in den folgenden Abschnitten im Kontext von Netzwerkfunktionen oder Dienstvirtualisierung besprochen, einschließlich der Verwendung von virtuellen Rändern und virtuellen Diensten, die für mehrere Akteure orchestriert werden.
  • Die Edge-Gateway-Knoten 5112 und die Edge-Aggregationsknoten 5122 arbeiten zusammen, um den Client-Rechenknoten 5102 verschiedene Edge-Dienste und Sicherheit bereitzustellen. Weil jeder Client-Rechenknoten 5102 stationär oder mobil sein kann, kann ferner jeder Edge-Gateway-Knoten 5112 mit anderen Edge-Gateway-Vorrichtungen zusammenwirken, um gegenwärtig bereitgestellte Edge-Dienste und Sicherheit fortzubewegen, wenn sich der entsprechende Client-Rechenknoten 5102 in einer Region herumbewegt. Dazu kann jeder der Edge-Gateway-Knoten 5112 und/oder Edge-Aggregationsknoten 5122 Konfigurationen mit mehreren Mandanten und mehreren Stakeholdern unterstützen, in denen Dienste von (oder gehostet für) mehreren Dienstanbietern und mehreren Verbrauchern über eine einzelne oder mehrere Rechenvorrichtungen hinweg unterstützt und koordiniert werden können.
  • In weiteren Beispielen können beliebige der Rechenknoten oder Vorrichtungen, die unter Bezugnahme auf die vorliegenden Rechensysteme und die vorliegende Umgebung erörtert wurden, basierend auf den Komponenten, die in 52A und 52B beschrieben sind. Jeder Rechenknoten kann als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, das in der Lage ist, mit anderen Edge-, Netzwerk-oder Endpunktkomponenten zu kommunizieren.
  • In dem vereinfachten Beispiel, das in 52A weist ein Edge-Rechenknoten 5200 eine Rechen-Engine (hier auch als „Rechenschaltungsanordnung“ bezeichnet) 5202, ein Eingabe/Ausgabe(E/A)-Subsystem 5208, eine Datenspeicherung 5210, ein Kommunikationsschaltungsanordnungs-Subsystem 5212 und optional eine oder mehrere Peripherievorrichtungen 5214 auf. Bei anderen Beispielen kann jede Rechenvorrichtung andere oder zusätzliche Komponenten beinhalten, wie etwa jene, die in Personal- oder Server-Rechensystemen verwendet werden (z.B. eine Anzeige, Peripherievorrichtungen usw.). Zusätzlich dazu können in manchen Beispielen eine oder mehrere der veranschaulichenden Komponenten in einer anderen Komponente integriert sein oder anderweitig einen Teil davon bilden.
  • Der Rechenknoten 5200 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen ausgebildet sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. In einigen Beispielen kann der Rechenknoten 5200 als eine einzelne Vorrichtung umgesetzt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. In dem veranschaulichten Beispiel beinhaltet der Rechenknoten 5200 einen Prozessor 5204 und einen Speicher 5206 oder ist als diese realisiert. Der Prozessor 5204 kann als eine beliebige Art eines Prozessors realisiert sein, der in der Lage ist, die hierin beschriebenen Funktionen (z.B. ein Ausführen einer Anwendung) durchzuführen. Der Prozessor 5204 kann als ein oder mehrere Mehrkernprozessoren, ein Mikrocontroller oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerungsschaltung ausgebildet sein. Bei einigen Beispielen kann der Prozessor 5204 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), eine neu konfigurierbare Hardware oder Hardwareschaltungsanordnung oder eine andere spezialisierte Hardware ausgebildet sein, diese enthalten oder an diese gekoppelt sein, um eine Durchführung der hierin beschriebenen Funktionen zu ermöglichen.
  • Der Hauptspeicher 5206 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischem Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder Datenspeicherung ausgebildet sein, der bzw. fähig ist, die hierin beschriebenen Funktionen durchzuführen. Flüchtiger Speicher kann ein Speicherungsmedium sein, das Energie erfordert, um den Zustand von vom Medium gespeicherten Daten zu bewahren. Nichtbeschränkende Beispiele für flüchtigen Speicher können verschiedene Typen von Direktzugriffsspeicher (RAM), wie etwa DRAM oder statischer Direktzugriffsspeicher (SRAM), einschließen. Eine bestimmte Art von DRAM, die in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
  • In einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie diejenigen, die auf NAND - oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine dreidimensionale Kreuzungspunktspeichervorrichtung (z.B. Intel 3D XPoint™-Speicher, einen anderen Speicherungsklassenspeicher) oder andere byteadressierbare nichtflüchtige Speichervorrichtungen zum Schreiben an Ort und Stelle beinhalten. Die Speichereinrichtung kann sich auf den die selbst und/oder auf ein gekapseltes Speicherprodukt beziehen. In einigen Beispielen kann der 3D-Koppelpunkt-Speicher (z.B. Intel 3D XPoint™-Speicher) eine transistorlose stapelbare Koppelpunkt-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und individuell adressierbar sind, und bei der eine Bitspeicherung auf einer Änderung des Bulkwiderstands basiert. In einigen Beispielen kann der gesamte oder ein Teil des Hauptspeichers 5206 in den Prozessor 5204 integriert sein. Der Hauptspeicher 5206 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
  • Die Rechenschaltungsanordnung 5202 ist über das E/A-Subsystem 5208 kommunikativ an andere Komponenten des Rechenknotens 5200 gekoppelt, das als Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 5202 (z. B. mit dem Prozessor 5204 und/oder dem Hauptspeicher 5206) und anderen Komponenten der Rechenschaltungsanordnung 5202 zu ermöglichen. Das E/A-Subsystem 5208 kann beispielsweise als Speichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmwarevorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verknüpfungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Bahnen auf gedruckten Leiterplatten usw.) und/oder andere Komponenten und Subsysteme ausgebildet sein oder diese anderweitig enthalten, um die Eingabe/Ausgabe-Operationen zu ermöglichen. Bei einigen Beispielen kann das E/A-Subsystem 5208 einen Abschnitt eines Ein-Chip-Systems (SoC) bilden und zusammen mit einem oder mehreren des Prozessors 5204, des Hauptspeichers 5206 und anderer Komponenten der Rechenschaltungsanordnung 5202 in die Rechenschaltungsanordnung 5202 eingebunden sein.
  • Die eine oder mehreren veranschaulichenden Datenspeicherungsvorrichtungen 5210 können als ein beliebiger Typ von Vorrichtungen ausgebildet sein, die zur kurzfristigen oder langfristigen Speicherung von Daten, wie zum Beispiel Speichervorrichtungen und Schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeicherungsvorrichtungen konfiguriert sind. Jede Datenspeicherungseinrichtung 5210 kann eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungseinrichtung 5210 speichert. Jede Datenspeicherungsvorrichtung 5210 kann auch eine oder mehrere Betriebssystempartitionen beinhalten, die Datendateien und Ausführungsprogramme für Betriebssysteme in Abhängigkeit von zum Beispiel dem Typ des Rechenknotens 5200 speichern.
  • Die Kommunikationsschaltungsanordnung 5212 kann als eine beliebige Kommunikationsschaltung, -Vorrichtung oder -Sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 5202 und einer anderen Rechenvorrichtung (z.B. einem Edge-Gateway-Knoten 5112 eines Edge-Computing-Systems) zu ermöglichen. Die Kommunikationsschaltungsanordnung 5212 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (z.B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z.B. ein zellulares Vernetzungsprotokoll, wie einen 3GPP-4G- oder -5G-Standard, ein Local-Area-Network-Protokoll, wie z.B. IEEE 802.11/Wi-Fi®, ein Drahtlosweitverkehrsnetzprotokoll, Ethernet, Bluetooth® usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
  • Die veranschaulichende Kommunikationsschaltungsanordnung 5212 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 5220, die auch als eine Host-Fabric-Schnittstelle (HFI) bezeichnet werden kann. Die NIC 5220 kann als eine oder mehrere Erweiterungskarten, Tochterkarten, Netzwerkschnittstellenkarten, Controller-Chips, Chipsätze oder andere Vorrichtungen, die von dem Rechenknoten 5200 verwendet werden können, ausgeführt sein, um sich mit einer anderen Rechenvorrichtung (z.B. einem Edge-Gateway-Knoten 5112) zu verbinden. In einigen Beispielen kann die NIC 5220 als ein Teil eines Ein-Chip-Systems (SoC) ausgebildet sein, das einen oder mehrere Prozessoren beinhaltet, oder in einem Mehrchipgehäuse enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. In einigen Beispielen kann die NIC 5220 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) enthalten, die beide lokal zur NIC 5220 sind. In derartigen Beispielen kann der lokale Prozessor der NIC 5220 fähig sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltungsanordnung 5202 durchzuführen. Zusätzlich oder alternativ dazu kann in solchen Beispielen der lokale Speicher der NIC 5220 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
  • Zusätzlich dazu kann jeder Rechenknoten 5200 bei manchen Beispielen eine oder mehrere Peripherievorrichtungen 5214 beinhalten. Solche Peripherievorrichtungen 5214 können eine beliebige Art von Peripherievorrichtung beinhalten, die in einer Rechenvorrichtung oder einem Server gefunden wird, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe/Ausgabe-Vorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 5200. In weiteren Beispielen kann der Rechenknoten 5200 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Rechensystem (z.B. Client-Rechenknoten 5102, Edge-Gateway-Knoten 5112, Edge-Aggregationsknoten 5122) oder ähnliche Formen von Geräten, Computern, Subsystemen, Schaltungsanordnung oder andere Komponenten ausgeführt werden.
  • In einem ausführlicheren Beispiel 52b veranschaulicht ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Rechenknoten 5250 zum Implementieren der hierin beschriebenen Techniken (z.B. Operationen, Prozesse, Verfahren und Methodologien) vorhanden sein können. Der Edge-Computing-Knoten 5250 kann beliebige Kombinationen der oben genannten Komponenten umfassen, und er kann eine beliebige Vorrichtung umfassen, die mit einem Edge-Kommunikationsnetz oder einer Kombination solcher Netze verwendbar ist. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Logik, Hardware, Software, Firmware oder eine in dem Edge-Rechenknoten 5250 angepasste Kombination davon oder als Komponenten, die anderweitig innerhalb eines Gehäuses eines größeren Systems integriert sind, implementiert sein. Zum Unterstützen der hierin bereitgestellten Sicherheitsbeispiele eine Hardware-rot (z.B. gemäß einer DICE-Architektur bereitgestellt) Kann in jedem IP-Block des Edge-Rechenknotens 5250 implementiert werden, so dass ein beliebiger IP-Block in einen Modus booten könnte, in dem eine rot-Identität erzeugt werden könnte, der seine Identität und seine aktuelle gebootete Firmware einem anderen IP-Block oder einer externen Entität attestieren kann.
  • Der Edge-Rechenknoten 5250 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 5252 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 5252 kann ein Teil eines System-on-Chip (SoC) sein, in dem der Prozessor 5252 und andere Komponenten zu einer einzigen integrierten Schaltung oder einem einzigen Package gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien. Als ein Beispiel kann der Prozessor 5252 einen Intel®-Architecture-Core™-basierten Prozessor, wie etwa einen Quark™, einen Atom™, einen Xeon™, einen i3, einen i5, Einen Prozessor der Klasse i7, i9 oder MCU oder einen anderen derartigen Prozessor, der von Intel® erhältlich ist. Jedoch kann eine beliebige Anzahl anderer Prozessoren verwendet werden, wie etwa jene, die von Advanced Micro Devices, Inc. (AMD) in Sunnyvale, Kalifornien, USA, erhältlich sind, ein MIPS-basiertes Design von MIPS Technologies, Inc. in Sunnyvale, Kalifornien, USA, ein ARM-basiertes Design, das von ARM Holdings, Ltd. oder einem Kunden davon oder deren Lizenznehmern oder Einsetzenden lizenziert ist. Die Prozessoren können Einheiten beinhalten, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc. Oder einen OMAP™-Prozessor von Texas Instruments, Inc
  • Der Prozessor 5252 kann über eine Zwischenverbindung 5256 (z.B. einen Bus) mit einem Systemspeicher 5254 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder Mobil-DDDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Arbeitsspeicherkomponente einen von JEDEC veröffentlichten DRAM-Standard erfüllen, wie 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 Niedrigenergie-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 Speichervorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichereinrichtungen aus einer beliebigen Anzahl von verschiedenen Gehäusetypen sein, wie ein Ein-Rohchip-Gehäuse (SDP), Doppel-Rohchip-Gehäuse (DDP) oder Quad-Rohchip-Gehäuse (Q17P). Diese Vorrichtungen können bei manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die der Reihe nach durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z.B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
  • Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann eine Speicherung 5258 auch über die Zwischenverbindung 5256 mit dem Prozessor 5252 gekoppelt sein. Bei einem Beispiel kann der Datenspeicher 5258 über ein Solid-State-Plattenlaufwerk (SSDD) implementiert sein. Andere Vorrichtungen, die für die Speicherung 5258 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, XD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. Bei einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder beinhalten, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenebenen, NOR-Flash-Speicher, Einzel- oder Mehrebenen-Phasenwechselspeicher (PCM), einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), einen antiferroelektrischen Speicher, Magnetoresistiver-Direktzugriffsspeicher(MRAM)-Speicher, der eine Memristortechnologie, einen resistiven Speicher einschließlich der Metalloxidbasis, die Sauerstoffleerstellenbasis und den leitfähigen Brücken-Direktzugriffsspeicher (CB-RAM) beinhaltet, Oder Spintransferdrehmoment(STT)-MRAM, eine Spintronik-Magnetübergangsspeicher-basierte Vorrichtung, eine auf magnetischem Tunnelübergang(MTJ)-basierte Vorrichtung, eine DW(Domain Wall)- und SOT(Spin Orbit Transfer)-basierte Vorrichtung, eine auf einem Thyristor basierende Speichervorrichtung oder eine Kombination beliebiger des Obigen oder eines anderen Speichers.
  • Bei Niedrigleistungsimplementierungen kann die Speicherung 5258 ein chipinterner Speicher oder Register sein, die mit dem Prozessor 5252 assoziiert sind. In manchen Beispielen kann die Speicherung 5258 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 5258 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandsänderungsspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher.
  • Die Komponenten können über die Zwischenverbindung 5256 kommunizieren. Die Zwischenverbindung 5256 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), NVLink oder eine beliebige Anzahl anderer Technologien. Die Zwischenverbindung 5256 kann ein proprietärer Bus sein, der zum Beispiel in einem SoCbasierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
  • Die Zwischenverbindung 5256 kann den Prozessor 5252 mit einem Sendeempfänger 5266 zur Kommunikation mit den verbundenen Edge-Vorrichtungen 5262 koppeln. Der Sendeempfänger 5266 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa unter anderem Übertragungen auf 2,4 Gigahertz (GHz) unter dem IEEE 802.15.4-Standard unter Verwendung des Bluetooth®-Niederenergie(BLE)-Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen mit den verbundenen Edge-Vorrichtungen 5262 verwendet werden. Zum Beispiel kann eine Drahtlos-Lokalnetz(WLAN)-Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronic Engineers (IEEE) zu implementieren. Außerdem können Funkfernnetzkommunikationen, z. B. in Übereinstimmung mit einem Mobilfunk- oder anderen Funkfernnetzprotokoll über eine Funkfernnetz(WWAN)-Einheit stattfinden.
  • Der Drahtlosnetzwerk-Sendeempfänger 5266 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Beispielsweise kann der Edge-Rechenknoten 5250 mit nahen Vorrichtungen, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder einem anderen Niedrigleistungsfunkgerät kommunizieren, um Leistung zu sparen. Entferntere verbundene Edge-Vorrichtungen 5262, z.B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Mittelleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät mit unterschiedlichen Leistungspegeln oder über separate Sendeempfänger erfolgen, beispielsweise einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Maschensendeempfänger, der ZigBee verwendet.
  • Ein Drahtlosnetzwerk-Sendeempfänger 5266 (z.B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 5290 über Lokal- oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 5266 kann unter anderem ein LPWA-Sendeempfänger sein, der den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Rechenknoten 5250 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa Zeitschlitz-Kanalspringen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist.
  • Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerk-Sendeempfänger 5266 erwähnten Systemen verwendet werden, wie hierin beschrieben. Der Sendeempfänger 5266 kann zum Beispiel einen Mobilfunk-Sendeempfänger beinhalten, der Frequenzspreiz(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Sendeempfänger 5266 kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP Spezifikationen (Third Generation Partnership Project) kompatibel sind, wie etwa Long Term Evolution (LTE) und 5. Generation (5G) Kommunikationssysteme, die am Ende der vorliegenden Offenbarung ausführlicher besprochen werden. Eine Netzwerkschnittstellensteuerung (NIC) 5268 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 5290 oder zu anderen Vorrichtungen bereitzustellen, wie etwa den angebundenen Edge-Vorrichtungen 5262 (die
    z. B. in einem vermaschten Netz arbeiten). Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 5268 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 5268 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 5268 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
  • Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine beliebige oder mehrere beliebige der Komponenten 5264, 5266, 5268 oder 5270 beinhalten oder durch diese umgesetzt sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Übertragen usw.) durch eine derartige Kommunikationsschaltungsanordnung ausgebildet sein.
  • Der Edge-Computing-Knoten 5250 kann eine Beschleunigungsschaltungsanordnung 5264 umfassen oder mit dieser gekoppelt sein, die durch einen oder mehrere KI-Beschleuniger, einen neuronalen Computing-Stick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, ein oder mehrere SoCs, eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs oder andere Formen von spezialisierten Prozessoren oder spezialisierter Schaltungsanordnung verkörpert sein kann, die entworfen sind, um eine oder mehrere spezialisierte Aufgaben zu erfüllen. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zur Beschleunigung durch eine solche Beschleunigungsschaltungsanordnung verkörpert werden.
  • Die Zwischenverbindung 5256 kann den Prozessor 5252 mit einem Sensor-Hub oder einer externen Schnittstelle 5270 koppeln, die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die Vorrichtungen können Sensoren 5272 beinhalten, wie Beschleunigungsmesser, Niveausensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Positionierungssystems (GPS), Drucksensoren, Luftdrucksensoren und dergleichen. Der Hub oder die Schnittstelle 5270 kann ferner verwendet werden, um den Edge-Rechenknoten 5250 mit Aktuatoren 5274, wie etwa Leistungsschaltern, Ventilaktuatoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
  • In einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb des Edge-Rechenknotens 5250 vorhanden sein oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige oder eine andere Ausgabevorrichtung 5284 enthalten sein, um Informationen, wie etwa Sensorablesungen oder Aktorposition, zu zeigen. Eine Eingabevorrichtung 5286, wie beispielsweise ein Touchscreen oder ein Tastenfeld, kann enthalten sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 5284 kann eine beliebige Anzahl von Formen einer Audio- oder visuellen Anzeige aufweisen, einschließlich einfacher visueller Ausgaben, wie etwa binärer Statusindikatoren (z.B. LEDs) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigebildschirme (z.B. LCD-Bildschirme), mit der Ausgabe von Zeichen, Grafiken, Multimediaobjekten, Und dergleichen, die aus dem Betrieb des Edge-Rechenknotens 5250 erzeugt oder produziert werden.
  • Eine Batterie 5276 kann den Edge-Computing-Knoten 5250 mit Leistung versorgen, obwohl er bei Beispielen, bei denen der Edge-Computing-Knoten 5250 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist. Die Batterie 5276 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
  • Ein Batterieüberwachungsgerät/-ladegerät 5278 kann in dem Edge-Computing-Knoten 5250 enthalten sein, um den Ladungszustand (SoCh) der Batterie 5276 zu verfolgen. Die Batterieüberwachungs-/-Ladevorrichtung 5278 kann verwendet werden, um andere Parameter der Batterie 5276 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SOF) der Batterie 5276. Das Batterieüberwachungs-/-ladegerät 5278 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor in Phoenix, Arizona, oder ein IC aus der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Die Batterieüberwachungseinheit/Ladeeinheit 5278 kann die Informationen über die Batterie 5276 über die Zwischenverbindung 5256 an den Prozessor 5252 kommunizieren. Die Batterieüberwachungseinheit/Ladeeinheit 5278 kann auch einen Analog-digital-Wandler (ADC) beinhalten, der es dem Prozessor 5252 ermöglicht, die Spannung der Batterie 5276 oder den Stromfluss von der Batterie 5276 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu ermitteln, die der Edge-Rechenknoten 5250 durchführen kann, wie etwa Übertragungsfrequenz, vermaschten Netzbetrieb, Abtastfrequenz und dergleichen.
  • Ein Leistungsblock 5280 oder eine andere Leistungsversorgung, die an ein Netz gekoppelt ist, kann an die Batterieüberwachungsvorrichtung/Ladevorrichtung 5278 gekoppelt sein, um die Batterie 5276 zu laden. In einigen Beispielen kann der Leistungsblock 5280 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel über eine Schleifenantenne im Edge-Rechenknoten 5250 zu beziehen. Eine Drahtlosbatterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in der Batterieüberwachungs-/-Ladevorrichtung 5278 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 5276 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Standards Airfuel, des vom Wireless Power Consortium veröffentlichten Drahtlosladestandards Qi oder des von der Alliance for Wireless Power veröffentlichten Ladestandards Rezence durchgeführt werden.
  • Die Speicherung 5258 kann Anweisungen 5282 in Form von Software-, Firmware- oder Hardwarebefehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl derartige Anweisungen 5282 als Codeblöcke gezeigt sind, die in dem Speicher 5254 und der Speicherung 5258 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC) eingebaut sind.
  • Bei einem Beispiel können die Anweisungen 5282, die über den Speicher 5254, die Speicherung 5258 oder den Prozessor 5252 bereitgestellt werden, als ein nicht transitorisches maschinenlesbares Medium 5260 ausgebildet sein, das Code beinhaltet, um den Prozessor 5252 anzuweisen, elektronische Operationen im Edge-Rechenknoten 5250 durchzuführen. Der Prozessor 5252 kann über die Zwischenverbindung 5256 auf das nichtflüchtige maschinenlesbare Medium 5260 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 5260 durch Vorrichtungen ausgebildet sein, die für die Speicherung 5258 beschrieben sind, oder kann spezifische Speicherungseinheiten, wie etwa optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nicht transitorische, maschinenlesbare Medium 5260 kann Anweisungen beinhalten, um den Prozessor 5252 anzuweisen, eine spezifische Sequenz oder einen spezifischen Ablauf von Handlungen durchzuführen, wie zum Beispiel in Bezug auf das eine oder die mehreren oben gezeigten Ablaufdiagramme und Blockdiagramme von Operationen und Funktionalität beschrieben. Wie verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
  • In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch ein beliebiges greifbares Medium, das zum Speichern, Codieren oder Führen von Anweisungen zur Ausführung durch eine Maschine imstande ist und das bewirkt, dass die Maschine beliebige einer oder mehrerer der Methodologien der vorliegenden Offenbarung durchführt, oder das zum Speichern, Codieren oder Führen von Datenstrukturen, die von solchen Anweisungen genutzt werden oder mit diesen assoziiert sind. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Spezielle Beispiele für maschinenlesbare Medien beinhalten nichtflüchtigen Speicher, einschließlich unter anderem Halbleiterspeichervorrichtungen (z.B. elektrisch programmierbaren Nurlesespeicher (EPROM), elektrisch löschbaren programmierbaren Nurlesespeicher (EEPROM)) und Flash-Speichervorrichtungen; magnetische Platten, wie etwa interne Festplatten und entfernbare Platten; magnetooptische Platten; Und CD-ROM- und DVD-ROM-Disks. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstelleneinrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z.B. HTTP) nutzt.
  • Ein maschinenlesbares Medium kann durch eine Speichervorrichtung oder eine andere Einrichtung bereitgestellt sein, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. In einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen Anweisungen repräsentieren, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z.B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die Informationen, welche die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können durch eine Verarbeitungsschaltungsanordnung zu den Anweisungen verarbeitet werden, um beliebige der hier erörterten Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z.B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes beinhalten: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Linken), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
  • In einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Zum Beispiel können sich die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binärer ausführbarer Code usw.) auf einem oder mehreren entfernten Servern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk bewegt werden, und bei Bedarf entschlüsselt, entkomprimiert, zusammengesetzt (z.B. verlinkt) werden und in einer lokalen Maschine kompiliert oder interpretiert werden (z.B. in eine Bibliothek, eigenständige ausführbare Datei usw.) und von der lokalen Maschine ausgeführt werden.
  • Jedes der Blockdiagramme aus 52A und 52B soll eine Ansicht auf hoher Ebene von Komponenten einer Vorrichtung, eines Subsystems oder einer Anordnung eines Edge-Computing-Knotens darstellen. Es wird jedoch klar sein, dass einige der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können und eine andere Anordnung der gezeigten Komponenten in anderen Implementierungen stattfinden kann.
  • Figur 5310 veranschaulicht eine beispielhafte Softwareverteilungsplattform 5305 zum Verteilen von Software, wie etwa der beispielhaften computerlesbaren Anweisungen 5282 von 52B, an eine oder mehrere Vorrichtungen, wie etwa (eine) beispielhafte Prozessorplattform(en) 5310 und/oder beispielhafte verbundene Edge-Vorrichtungen, die hier erörtert werden. Die beispielhafte Softwareverteilungsplattform 5305 kann durch einen beliebigen Computerserver, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, der in der Lage ist, Software zu speichern und zu anderen Rechenvorrichtungen zu übertragen. Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (z.B. Server), Dritte (z.B. Kunden einer Entität, die die Softwareverteilungsplattform 5305 besitzt und/oder betreibt) sein. Beispielhafte verbundene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. Bei einigen Beispielen ist eine Drittpartei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa den beispielhaften computerlesbaren Anweisungen 5282 aus 52B. Die Dritten können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung kaufen und/oder lizenzieren und/oder wiederverkaufen und/oder sublizenzieren. In einigen Beispielen bewirkt verteilte Software, dass eine Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs) die eine oder die mehreren Vorrichtungen (z.B. verbundene Edge-Vorrichtungen) geografisch und/oder logisch voneinander getrennt (z.B. physisch getrennte IoT-Vorrichtungen, die mit der Verantwortung der Wasserverteilungsteuerung ausgekoppelt sind) identifiziert (Z. B. Pumpen), Elektrizitätsverteilungssteuerung (z.B. Relais) usw.).
  • In dem veranschaulichten Beispiel von 53 beinhaltet die Softwareverteilungsplattform 5305 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen, die die computerlesbaren Anweisungen 5282 speichern. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 5305 stehen in Kommunikation mit einem Netzwerk 5315, das einem beliebigen oder mehreren beliebigen des Internets und/oder beliebigen der oben beschriebenen beispielhaften Netzwerke entsprechen kann. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Software als Teil einer kommerziellen Transaktion an eine anfordernde Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittanbieter-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 5282 von der Softwareverteilungsplattform 5305 herunterzuladen. Zum Beispiel kann die Software, die beispielhaften computerlesbaren Anweisungen entsprechen kann, auf die beispielhafte(n) Prozessorplattform(en) heruntergeladen werden, die die computerlesbaren Anweisungen 5282 ausführen soll/sollen. In einigen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 5305 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 5282 passieren müssen. In einigen Beispielen bieten ein oder mehrere Server der Softwareverteilungsplattform 5305 periodisch Aktualisierungen für die Software (z.B. die beispielhaften computerlesbaren Anweisungen 5282 von 52b) um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewendet werden.
  • In dem veranschaulichten Beispiel aus 53 sind die computerlesbaren Anweisungen 5282 auf Speichervorrichtungen der Softwareverteilungsplattform 5305 in einem bestimmten Format gespeichert. Ein Format computerlesbarer Anweisungen beinhaltet unter anderem eine spezielle Codesprache (z.B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen speziellen Codezustand (z.B. unkompilierter Code (z.B. ASCII), interpretierter Code, verknüpfter Code, Ausführbarer Code (z.B. ein Binärzeichen) usw.). In einigen Beispielen befinden sich die computerlesbaren Anweisungen 5282, die in der Softwareverteilungsplattform 5305 gespeichert sind, in einem ersten Format, wenn sie an die beispielhafte(n) Prozessorplattform(en) 5310 übertragen werden. In einigen Beispielen ist das erste Format ein ausführbares Binärprogramm, in dem bestimmte Typen der Prozessorplattform(en) 5310 ausgeführt werden können. In einigen Beispielen ist das erste Format jedoch unkompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, um eine Ausführung auf der/den beispielhaften Prozessorplattform(en) 5310 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 5300 möglicherweise die computerlesbaren Anweisungen 5282 in dem ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der in der Lage ist, auf der (den) Prozessorplattform(en) 5310 ausgeführt zu werden. Bei noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der Prozessorplattform(en) 5310 durch einen Interpreter interpretiert wird, um die Ausführung von Anweisungen zu erleichtern.
  • Zusätzliche Implementierungsbeispiele und Anmerkungen
  • Eine beispielhafte Implementierung ist ein Verfahren, das durch einen Edge-Rechenknoten durchgeführt wird, wobei der Edge-Rechenknoten mit einem Satellitenkommunikationsnetzwerk verbunden ist, wobei ein Verfahren Folgendes umfasst: Empfangen, von einer Endpunktvorrichtung, einer Anforderung zur Rechenverarbeitung; Identifizieren eines Orts für die Rechenverarbeitung, wobei der Ort aus Folgendem ausgewählt ist: rechenressourcen, die lokal an dem Edge-Rechenknoten bereitgestellt sind, oder Rechenressourcen, die an einem entfernten Dienst bereitgestellt werden, auf den über das Satellitennetzwerk zugegriffen werden kann; und Veranlassen der Verwendung der Rechenverarbeitung an dem identifizierten Ort gemäß Dienstanforderungen der Rechenverarbeitung; Wobei das Satellitennetzwerk intermittierend verfügbar ist, wobei die Verwendung der Rechenverarbeitung basierend auf der Verfügbarkeit des Satellitennetzwerks koordiniert wird.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei das Satellitennetzwerk ein Leo(Low-Orbit)-Satellitennetzwerk ist, Wobei das LEO-Satellitennetzwerk eine Abdeckung an den Edge-Rechenknoten von mehreren Satellitenfahrzeugen basierend auf Orbit-Positionen der Satellitenfahrzeuge bereitstellt.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei das LEO-Satellitennetzwerk mehrere Konstellationen beinhaltet, wobei jede der mehreren Konstellationen jeweilige mehrere Satellitenfahrzeuge bereitstellt, Und wobei die Netzwerkabdeckung für den Edge-Rechenknoten auf einer Position der Vielzahl von Konstellationen basiert.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei der Edge-Rechenknoten an einer Basisstation bereitgestellt wird, wobei die Basisstation Drahtlosnetzwerkkonnektivität zu der Endpunkteinrichtung bereitstellen soll.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei die Drahtlosnetzwerkkonnektivität durch ein 4G-Long-Term-Evolution(LTE)- oder 5G-Netzwerk bereitgestellt wird, das gemäß einem 3GPP-Standard arbeitet, oder ein RAN, das gemäß einem O-RAN-Alliance-Standard arbeitet.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf einer Latenz von Kommunikationen über das Satellitennetzwerk und einer Zeit zum Verarbeiten an den Rechenressourcen identifiziert wird.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf einer Dienstgütevereinbarung identifiziert wird, die mit der Anforderung zur Rechenverarbeitung assoziiert ist.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf Anweisungen von einem Netzwerkorchestrator identifiziert wird, wobei der Netzwerkorchestrator Orchestrierung für mehrere Edge-Computing-Standorte bereitstellt, die den Edge-Rechenknoten aufweisen.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird und das zurückgibt von Ergebnissen der Rechenverarbeitung zu der Endpunkteinrichtung beinhaltet, wobei die Rechenverarbeitung eine Verarbeitung einer Arbeitslast beinhaltet.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch den Edge-Rechenknoten durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf (i) einer Art der Arbeitslast und (ii) Verfügbarkeit der Rechenressourcen an dem Edge-Rechenknoten identifiziert wird, um den Typ der Arbeitslast lokal zu verarbeiten.
  • Eine andere beispielhafte Implementierung ist ein Verfahren, das durch eine Endpunktclientvorrichtung durchgeführt wird, wobei die Endpunktclientvorrichtung zur Netzwerkkonnektivität mit einem ersten Satellitennetzwerk und mit einem zweiten terrestrischen Netzwerk in der Lage ist, wobei das Verfahren Folgendes umfasst: Identifizieren einer Arbeitslast zur Rechenverarbeitung; Bestimmen eines Orts für die Rechenverarbeitung der Arbeitslast, wobei der Ort aus Folgendem ausgewählt ist: rechenressourcen, die an einem Edge-Rechenknoten bereitgestellt werden, auf die über das zweite terrestrische Netzwerk zugegriffen werden kann, oder Rechenressourcen, die an einem entfernten Dienst bereitgestellt werden, auf den über das erste Satellitennetzwerk zugegriffen werden kann; Und Kommunizieren der Arbeitslast zu dem identifizierten Ort; wobei Netzwerkkonnektivität mit dem Satellitennetzwerk intermittierend basierend auf der Verfügbarkeit des Satellitennetzwerks bereitgestellt wird.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei das Satellitennetzwerk ein Leo(Low-Orbit)-Satellitennetzwerk ist, Wobei das LEO-Satellitennetzwerk eine Abdeckung an die Endpunkt-Client-Vorrichtung von mehreren Satellitenfahrzeugen basierend auf Orbit-Positionen der Satellitenfahrzeuge bereitstellt.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei das LEO-Satellitennetzwerk mehrere Konstellationen beinhaltet, wobei jede der mehreren Konstellationen jeweilige mehrere Satellitenfahrzeuge bereitstellt, Wobei die Netzwerkabdeckung für die Endpunkt-Client-Vorrichtung auf einer Position der mehreren Konstellationen basiert.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei der Edge-Rechenknoten an einer Basisstation des zweiten terrestrischen Netzwerks bereitgestellt wird, wobei die Basisstation Drahtlosnetzwerkkonnektivität an die Endpunktclientvorrichtung bereitstellt.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei die Drahtlosnetzwerkkonnektivität durch ein 4G-Long-Term-Evolution(LTE)- oder 5G-Netzwerk bereitgestellt wird, das gemäß einem 3GPP-Standard arbeitet, oder ein RAN, das gemäß einem O-RAN-Alliance-Standard arbeitet.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf einer Latenz von Kommunikationen über das erste Satellitennetzwerk und einer Zeit zum Verarbeiten an den Rechenressourcen bestimmt wird.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf einer mit der Arbeitslast assoziierten Dienstgütevereinbarung identifiziert wird.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf Anweisungen von einem Netzwerkorchestrator identifiziert wird, wobei der Netzwerkorchestrator Orchestrierung für mehrere Edge-Computing-Standorte bereitstellt, die den Edge-Computing-Knoten aufweisen.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, einschließlich Empfangen von Ergebnissen der Rechenverarbeitung der Arbeitslast.
  • Eine weitere beispielhafte Implementierung ist ein Verfahren, das durch die Endpunktclientvorrichtung durchgeführt wird, wobei der Ort für die Rechenverarbeitung basierend auf (i) einem Typ der Arbeitslast und (ii) Verfügbarkeit der Rechenressourcen an dem Edge-Rechenknoten identifiziert wird, um den Typ der Arbeitslast lokal zu verarbeiten.
  • Eine beispielhafte Implementierung ist ein Edge-Rechensystem, das über eine Niedrigerdorbit-Satellitenkonnektivität bereitgestellt wird, einschließlich jeweiliger Edge-Verarbeitungsvorrichtungen und Knoten zum Aufrufen oder Durchführen der Operationen der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Client-Endpunktknoten, betreibbar zum Verwenden von Niedrigerdorbit-Satellitenkonnektivität direkt oder über ein anderes Drahtlosnetzwerk, um die Operationen der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Aggregationsknoten, Netzwerkhubknoten, Gateway-Knoten oder Kerndatenverarbeitungsknoten, der Kommunikationen über Niedrigerdorbit-Satellitenkonnektivität durchführt und innerhalb oder mit einem Edge-Computing-System gekoppelt ist und dazu betreibbar ist, die Operationen der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Zugangspunkt, eine Basisstation, eine Straßenrandeinheit, eine Straßenrandeinheit oder eine vor-Ort-Einheit, Durchführen von Kommunikationen über eine Niedrigerdorbit-Satellitenkonnektivität, die sich innerhalb eines oder gekoppelt mit einem Edge-Computing-System befindet und dazu betreibbar ist, die Operationen der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Knoten, auf den über eine Niedrigerdorbit-Satellitenkonnektivität zugegriffen werden kann und als ein Edge-Bereitstellungsknoten, ein Dienstorchestrierungsknoten, ein Anwendungsorchestrierungsknoten arbeitet, Oder ein mandantenfähiger Verwaltungsknoten, innerhalb oder gekoppelt mit einem Edge-Computing-System, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Knoten, auf den über eine Niedrigerdorbit-Satellitenkonnektivität zugegriffen werden kann, der einen Edge-Bereitstellungsdienst, eine Anwendung oder einen Dienstorchestrierungsdienst, einen Virtuelle-Maschine-Einsatz, einen Container-Einsatz, einen Funktionseinsatz und eine Rechenverwaltung betreibt, Innerhalb oder gekoppelt mit einem Edge-Computing-System, betreibbar zum Aufrufen oder Durchführen der Operationen der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das über Low-Orbit-Satellitenkonnektivität bereitgestellt wird, einschließlich Aspekten von Netzwerkfunktionen, Beschleunigungsfunktionen, Beschleunigungshardware, Speicherhardware oder Berechnungshardwareressourcen, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Rechensystem, das über Niedrigerdorbit-Satellitenkonnektivität bereitgestellt wird und zum Unterstützen von Client-Mobilität, Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-alles (V2X) oder Fahrzeug-zu-Infrastruktur (V2I) -Szenarien ausgelegt ist, Und optional gemäß ETSI-MEC-Spezifikationen arbeiten, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das über eine Niedrigerdorbit-Satellitenkonnektivität bereitgestellt ist und mit Geräten gekoppelt ist, die mobile drahtlose Kommunikationen gemäß 3GPP 4G/LTE- oder 5G-Netzwerkfähigkeiten bereitstellen und dazu betreibbar sind, die hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das über eine Niedrigerdorbit-Satellitenkonnektivität bereitgestellt wird und mit Geräten gekoppelt ist, die mobile drahtlose Kommunikationen gemäß O-RAN-Alliance-Netzwerkfähigkeiten bereitstellen, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Rechenknoten, der in einer Schicht eines Edge-Computing-Netzwerks oder Edge-Rechensystems betreibbar ist, das über Niedrigerdorbit-Satellitenkonnektivität bereitgestellt wird, wobei der Edge-Rechenknoten als ein Aggregationsknoten, Netzwerkhubknoten, Gateway-Knoten betreibbar ist, Oder Kerndatenverarbeitungsknoten, betreibbar in einer nahen Edge, lokalen Edge, Unternehmensedge, vor-Ort-Edge, nahe Edge, Mittlere, Edge- oder Far-Edge-Netzwerkschicht, oder betreibbar in einem Satz von Knoten mit gemeinsamen Latenz-, Timing- oder Abstandscharakteristiken, betreibbar zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist Netzwerkhardware, Beschleunigungshardware, Speicherhardware, Oder Berechnungshardware mit darauf implementierten Fähigkeiten, die in einem Edge-Computing-System betrieben werden kann, das über Low-Orbit-Satellitenkonnektivität bereitgestellt wird, um die hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, aufzurufen oder durchzuführen, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist eine Einrichtung eines Edge-Rechensystems, die über eine Niedrigerdorbit-Satellitenkonnektivität bereitgestellt wird, die Folgendes umfasst: Einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, die hierin besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, aufzurufen oder durchzuführen. F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist einn oder mehrere computerlesbare Speicherungsmedien, die in einem Edge-Rechensystem betreibbar sind undüber eine Niedrigerdorbit-Satellitenkonnektivität bereitgestellt werden, wobei das computerlesbare Speicherungsmedium Anweisungen umfasst, um eine elektronische Vorrichtung zu Folgendem zu bewirken: Bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung, zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Ein anderes Implementierungsbeispiel ist eine Einrichtung eines Edge-Rechensystems, das über eine Niedrigerdorbit-Satellitenkonnektivität bereitgestellt ist und Mittel, Logik, Module oder Schaltungsanordnungen zum Aufrufen oder Durchführen der hier besprochenen Verwendungsfälle unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1 E15-D20, E1 umfasst, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • Eine andere beispielhafte Implementierung ist ein Edge-Computing-System, das über Low-Orbit-Satellitenkonnektivität bereitgestellt wird und dazu konfiguriert ist, Verwendungsfälle durchzuführen, die von einem oder mehreren von Folgendem bereitgestellt werden: rechen-Offload, Daten-Caching, Videoverarbeitung, Netzwerkfunktionsvirtualisierung, Funkzugangsnetzwerkverwaltung, Augmented Reality, Virtual Reality, industrielle Automatisierung, Einzelhandel-Dienste, Herstellungsoperationen, intelligente Gebäude, Energieverwaltung, autonomes Fahren, Fahrzeugassistenz, Fahrzeugkommunikationen, Internet-der-Dinge-Operationen, Objektdetektion, Spracherkennung, Gesundheitswesenanwendungen, Spielanwendungen, Oder beschleunigte Inhaltsverarbeitung unter Verwendung der Beispiele A1-A15, B1-B25, C1-C12, D1-D20, E1-E15, F1-F12, G1-G15, H1-H16, I1-I13, oder ein anderer hierin beschriebener Gegenstand.
  • In den obigen Beispielen wurden viele Bezugnahmen auf Niedrigerdorbit(LEO)-Satelliten und Konstellationen bereitgestellt. Es versteht sich jedoch, dass die obigen Beispiele auch für viele Formen von Mittelerdorbit-Satelliten und -Konstellationen, geosynchrone Orbit-Satelliten und -Konstellationen und andere Hochebenenkommunikationsplattformen, wie etwa Luftone, relevant sind. Somit versteht es sich, dass die für LEO-Netzwerkeinstellungen besprochenen Techniken auch auf viele andere Netzwerkeinstellungen anwendbar sind.
  • Obwohl diese Implementierungen unter Bezugnahme auf spezifische beispielhafte Aspekte beschrieben wurden, ist es offensichtlich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzumfang der vorliegenden Offenbarung abzuweichen. Viele der hier beschriebenen Anordnungen und Prozesse können in Kombination oder in parallelen Implementierungen verwendet werden, die terrestrische Netzwerkkonnektivität (soweit verfügbar) beinhalten, um Netzwerkbandbreite/-durchsatz zu erhöhen und zusätzliche Edge-Dienste zu unterstützen. Entsprechend sind die Patentschrift und die Zeichnungen in einem veranschaulichenden und nicht in einem einschränkenden Sinne aufzufassen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen spezielle Aspekte, in denen der Gegenstand ausgeführt werden kann, als Veranschaulichung und nicht als Beschränkung. Die veranschaulichten Aspekte sind hinreichend detailliert beschrieben, um einen Fachmann zu befähigen, die hier offenbarten Lehren in die Praxis umzusetzen. Andere Aspekte können genutzt und daraus abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Diese ausführliche Beschreibung ist daher nicht in einem beschränkenden Sinne aufzufassen und der Schutzumfang verschiedener Aspekte ist nur durch die angehängten Ansprüche, zusammen mit dem vollen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigt sind, definiert.
  • Auf solche Aspekte des erfindungsgemäßen Gegenstands kann hier einzeln und/oder kollektiv lediglich der Einfachheit halber Bezug genommen werden, und ohne zu beabsichtigen, den Schutzumfang dieser Anmeldung freiwillig auf einen beliebigen einzelnen Aspekt oder einen beliebigen einzelnen Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart ist. Obwohl hier spezielle Aspekte veranschaulicht und beschrieben wurden, versteht es sich daher, dass eine beliebige Anordnung, die berechnet wurde, um den gleichen Zweck zu erreichen, die gezeigten speziellen Aspekte ersetzen kann. Diese Offenbarung ist so zu verstehen, dass sie alle Anpassungen oder Variationen der zahlreichen Aspekte samt und sonders abdecken. Kombinationen der obigen Aspekte und anderer Aspekte, die hierin nicht speziell beschrieben sind, ergeben sich für Fachleute bei der Durchsicht der obigen Beschreibung.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 63/077320 [0001]
    • US 63/129355 [0001]
    • US 63/124520 [0001]
    • US 63/104344 [0001]
    • US 63/065302 [0001]
    • US 63/018844 [0001]

Claims (140)

  1. Verfahren zum Aufbauen von verwalteten Datenstromverbindungen unter Verwendung eines Satellitenkommunikationsnetzes, das in einem Rechensystem durchgeführt wird, umfassend: Identifizieren mehrerer Datenströme, die zwischen dem Rechensystem und mehreren Endpunkten über das Satellitenkommunikationsnetzwerk durchzuführen sind; Gruppieren von Sätzen der mehreren Datenströme in virtuelle Endpunktkanäle (EPVCs), wobei die Gruppierung auf einem jeweiligen Endpunkt der mehreren Endpunkte basiert; Abbilden jeweiliger Datenströme der EPVCs in virtuelle Stream-Kanäle (SVCs) basierend auf einer Art von Dienst, der an den jeweiligen Datenströmen beteiligt ist; Identifizieren von Änderungen an den jeweiligen Datenströmen basierend auf Dienstanforderungen und Telemetrie, die mit den jeweiligen Datenströmen der EPVCs assoziiert sind; und Implementieren der Änderungen an den jeweiligen Datenströmen basierend auf einem Diensttyp, der an den jeweiligen Datenströmen beteiligt ist.
  2. Verfahren nach Anspruch 1, wobei die Dienstanforderungen Dienstgüte(QoS)-Anforderungen beinhalten.
  3. Verfahren nach Anspruch 1, wobei die Dienstanforderungen eine Einhaltung mindestens einer Dienstgütevereinbarung (SLA) beinhalten.
  4. Verfahren nach Anspruch 1, wobei die mehreren Endpunkte jeweilige Cloud-Datenverarbeitungssysteme umfassen, auf die über das Satellitenkommunikationsnetzwerk zugegriffen werden kann.
  5. Verfahren nach Anspruch 1, wobei die Telemetrie Latenzinformationen beinhaltet, die basierend auf den EPVCs und den SVCs identifizierbar sind.
  6. Verfahren nach Anspruch 1, wobei das Identifizieren der Änderungen an den jeweiligen Datenströmen auf Konnektivitätsbedingungen basiert, die mit dem Satellitenkommunikationsnetzwerk assoziiert sind.
  7. Verfahren nach Anspruch 1, wobei die Änderungen an den jeweiligen Datenströmen von Änderungen an den Latenz und/oder der Bandbreite und/oder den Dienstfähigkeiten und/oder den Leistungsbedingungen und/oder der Ressourcenverfügbarkeit bereitgestellt werden, Lastausgleich oder Sicherheitsmerkmale.
  8. Verfahren nach Anspruch 1, wobei das Verfahren ferner Folgendes umfasst: Sammeln der Dienstanforderungen, die mit den jeweiligen Datenströmen assoziiert sind; und Sammeln der Telemetrie, die den jeweiligen Datenströmen zugeordnet ist.
  9. Verfahren nach Anspruch 1, wobei die Änderungen an den jeweiligen Datenströmen das Bewegen mindestens einer der SVCs von einem ersten EPVC zu einem zweiten EPVC beinhalten, um die Verwendung mindestens eines Dienstes von einem ersten Endpunkt zu einem zweiten Endpunkt zu ändern.
  10. Verfahren nach Anspruch 1, wobei das Implementieren der Änderungen an den jeweiligen Datenströmen Anwenden von QoS und Ressourcenausgleich über die jeweiligen Datenströme umfasst.
  11. Verfahren nach Anspruch 1, wobei das Implementieren der Änderungen an den jeweiligen Datenströmen Anwenden eines Lastausgleichs umfasst, um Bandbreite über die jeweiligen Datenströme hinweg zu verwalten.
  12. Verfahren nach Anspruch 1, wobei das Verfahren ferner Folgendes umfasst: Bereitstellen einer Rückmeldung in einen Softwarestapel des Rechensystems als Reaktion auf das Identifizieren der Änderungen an den jeweiligen Datenströmen.
  13. Verfahren nach Anspruch 12, wobei das Verfahren ferner Folgendes umfasst: Anpassen der Nutzung mindestens einer Ressource, die mit einem entsprechenden Dienst assoziiert ist, innerhalb des Softwarestapels basierend auf der Rückmeldung.
  14. Verfahren nach Anspruch 1, wobei die Abbildung der jeweiligen Datenströme der EPVCs in die SVCs ferner auf der Identifikation eines Mandanten basiert, der mit den jeweiligen Datenströmen assoziiert ist.
  15. Verfahren nach Anspruch 14, wobei das Verfahren ferner Folgendes umfasst: Erhöhen oder Reduzieren von Ressourcen, die mit mindestens einem SVC assoziiert sind, basierend auf der Identifikation.
  16. Verfahren nach Anspruch 1, wobei die jeweiligen Datenströme zwischen Client-Vorrichtungen und den mehreren Endpunkten eingerichtet werden, um Inhalt aus den mehreren Endpunkten abzurufen.
  17. Verfahren nach Anspruch 16, wobei das Rechensystem einen Inhaltslieferdienst bereitstellt und wobei der Inhalt von den mehreren Endpunkten unter Verwendung des Satellitenkommunikationsnetzwerks als Reaktion auf einen Cache-Fehltreffer am Inhaltslieferdienst abgerufen wird.
  18. Verfahren nach Anspruch 1, wobei die jeweiligen Datenströme zwischen Client-Vorrichtungen und den mehreren Endpunkten eingerichtet werden, um Rechenoperationen an den mehreren Endpunkten durchzuführen.
  19. Verfahren nach Anspruch 18, wobei das Rechensystem ferner dazu ausgelegt ist, den Client-Vorrichtungen ein Funkzugangsnetzwerk (RAN) mit virtuellen Netzwerkfunktionen bereitzustellen.
  20. Verfahren nach Anspruch 19, wobei das Funkzugangsnetzwerk gemäß Standards von einer 3GPP 5G oder einer O-RAN-Alliance-Standard-Familie bereitgestellt wird.
  21. Verfahren nach Anspruch 19, wobei das Rechensystem in einer Basisstation für das RAN gehostet wird.
  22. Verfahren nach Anspruch 1, wobei das Satellitenkommunikationsnetzwerk ein Leo(Low-Orbit)-Satellitenkommunikationsnetzwerk ist, das mehrere Satelliten in wenigstens einer Konstellation umfasst.
  23. Verfahren nach Anspruch 1, wobei das Satellitenkommunikationsnetzwerk als ein Backhaul-Netzwerk zwischen dem Rechensystem und den mehreren Endpunkten verwendet wird und wobei das Rechensystem eine Basisstation, einen Zugangspunkt, ein Gateway umfasst, Oder Aggregationspunkt, der eine Netzwerkplattform als ein Vermittler zwischen einer Client-Vorrichtung und dem Satellitenkommunikationsnetzwerk bereitstellt, um auf die mehreren Endpunkte zuzugreifen.
  24. Verfahren zur Inhaltsverteilung in einem Satellitenkommunikationsnetzwerk, das Folgendes umfasst: Cachen von Daten an einem Satellitenrechenknoten, wobei der Satellitenrechenknoten über das Satellitenkommunikationsnetzwerk zugänglich ist; Anwenden von Beschränkungen für den Zugriff auf die zwischengespeicherten Daten an dem Satellitenrechenknoten gemäß einer Position des Satellitenrechenknotens, eines Orts, der mit einer Quelle der Daten assoziiert ist, und eines Orts eines Empfängers; und Empfangen, von einem terrestrischen Rechenknoten, einer Anforderung für die zwischengespeicherten Daten basierend auf Ressourcenverfügbarkeit des terrestrischen Rechenknotens, wobei die Anforderung für die Daten basierend auf dem Erfüllen der Beschränkungen für den Zugriff auf die zwischengespeicherten Daten erfüllt wird.
  25. Verfahren nach Anspruch 24, wobei der terrestrische Rechenknoten dazu ausgelegt ist, Caching von mindestens einem Teil der Daten durchzuführen, wobei das Verfahren ferner Verwalten von Caching der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten umfasst.
  26. Verfahren nach Anspruch 25, wobei das Cachen der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf geografischen Einschränkungen in den Beschränkungen für den Zugriff auf die zwischengespeicherten Daten durchgeführt wird.
  27. Verfahren nach Anspruch 25, wobei das Cachen der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf Bandbreitenverfügbarkeit an dem terrestrischen Rechenknoten durchgeführt wird.
  28. Verfahren nach Anspruch 25, wobei das Cachen der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf Hinweisen durchgeführt wird, die dem terrestrischen Rechenknoten von dem Satellitenrechenknoten bereitgestellt werden.
  29. Verfahren nach Anspruch 25, wobei das Cachen der Daten zwischen dem Satellitenrechenknoten und dem terrestrischen Rechenknoten basierend auf einer Bandbreite durchgeführt wird, die von virtuellen Kanälen verwendet wird, die zwischen dem terrestrischen Rechenknoten und einem anderen terrestrischen Rechenknoten unter Verwendung einer Satellitennetzwerkverbindung aufgebaut werden.
  30. Verfahren nach Anspruch 24, wobei die Einschränkungen für den Zugriff auf die Daten auf Sicherheits- oder Datenschutzrichtlinien basieren, die bestimmt sind für: Mindestens einen Mandanten, mindestens eine Gruppe von Mandanten oder mindestens einen Dienstanbieter, der mit dem terrestrischen Rechenknoten assoziiert ist.
  31. Verfahren nach Anspruch 24, ferner umfassend: Verwalten der gecachten Daten an dem Satellitenrechenknoten basierend auf Richtlinien, die innerhalb eines Satelliten oder einer Satellitenkonstellation implementiert sind, die den Satellitenrechenknoten beinhaltet.
  32. Verfahren nach Anspruch 31, ferner umfassend: Entfernen der zwischengespeicherten Daten von dem Satelliten-Rechenknoten basierend auf geografischen Regeln und/oder Datenanbieterregeln und/oder Satellitennetzwerkrichtlinien.
  33. Verfahren nach Anspruch 24, wobei die Beschränkungen für den Zugriff auf die Daten ein Geofence definieren, das einen Zugriff auf die Daten bei einem Co-Standort des Satellitenrechenknotens und des terrestrischen Rechenknotens innerhalb des Geofence ermöglicht.
  34. Verfahren nach Anspruch 24, wobei das Verfahren durch eine Verarbeitungsschaltungsanordnung an dem Satellitenrechenknoten durchgeführt wird, die innerhalb eines Satellitenfahrzeugs gehostet wird.
  35. Verfahren nach Anspruch 34, wobei das Satellitenfahrzeug ein Leo(Low-Orbit)-Satelliten ist, der als ein Mitglied einer Satellitenkonstellation betrieben wird.
  36. Verfahren, das durch einen Edge-Rechenknoten durchgeführt wird, wobei der Edge-Rechenknoten mit einem Satellitenkommunikationsnetzwerk verbunden ist, wobei das Verfahren Folgendes umfasst: Empfangen, von einer Endpunkteinrichtung, einer Anforderung zur Rechenverarbeitung; Identifizieren eines Orts für die Rechenverarbeitung, wobei der Ort ausgewählt ist aus: rechenressourcen, die lokal an dem Edge-Rechenknoten bereitgestellt werden, oder Rechenressourcen, die an einem entfernten Dienst bereitgestellt werden, auf den über das Satellitennetzwerk zugegriffen werden kann; und Veranlassen der Verwendung der Rechenverarbeitung an dem identifizierten Ort gemäß Dienstanforderungen der Rechenverarbeitung; Wobei Satellitennetzwerk intermittierend verfügbar ist, wobei die Verwendung der Rechenverarbeitung basierend auf der Verfügbarkeit des Satellitennetzwerks koordiniert wird.
  37. Verfahren nach Anspruch 36, wobei das Satellitennetzwerk ein Leo(Low-Orbit)-Satellitennetzwerk ist, wobei das LEO-Satellitennetzwerk eine Abdeckung an den Edge-Rechenknoten von mehreren Satellitenfahrzeugen basierend auf Orbit-Positionen der Satellitenfahrzeuge bereitstellt.
  38. Verfahren nach Anspruch 37, wobei das LEO-Satellitennetzwerk mehrere Konstellationen beinhaltet, wobei jede der mehreren Konstellationen eine jeweilige Vielzahl von Satellitenfahrzeugen bereitstellt, und wobei Netzwerkabdeckung für den Edge-Rechenknoten auf einer Position der Vielzahl von Konstellationen basiert.
  39. Verfahren nach Anspruch 36, wobei der Edge-Rechenknoten an einer Basisstation bereitgestellt ist, wobei die Basisstation Drahtlosnetzwerkkonnektivität zu der Endpunkteinrichtung bereitstellen soll.
  40. Verfahren nach Anspruch 39, wobei die Drahtlosnetzwerkkonnektivität durch ein 4G-Long-Term-Evolution(LTE)- oder 5G-Netzwerk bereitgestellt wird, das gemäß einem 3GPP-Standard arbeitet.
  41. Verfahren nach Anspruch 36, wobei der Ort für die Rechenverarbeitung basierend auf einer Latenz von Kommunikationen über das Satellitennetzwerk und einer Zeit zum Verarbeiten an den Rechenressourcen identifiziert wird.
  42. Verfahren nach Anspruch 36, wobei der Ort für die Rechenverarbeitung basierend auf einer Dienstgütevereinbarung identifiziert wird, die mit der Anforderung zur Rechenverarbeitung assoziiert ist.
  43. Verfahren nach Anspruch 42, wobei der Ort für die Rechenverarbeitung basierend auf Anweisungen von einem Netzwerkorchestrator identifiziert wird, wobei der Netzwerkorchestrator Orchestrierung für mehrere Edge-Computing-Orte, einschließlich des Edge-Rechenknotens, bereitstellt.
  44. Verfahren nach Anspruch 36, ferner umfassend: Zurückgeben von Ergebnissen der Rechenverarbeitung an die Endpunkteinrichtung, wobei die Rechenverarbeitung eine Verarbeitung einer Arbeitslast beinhaltet.
  45. Verfahren nach Anspruch 44, wobei der Ort für die Rechenverarbeitung basierend auf (i) einem Typ der Arbeitslast und (ii) Verfügbarkeit der Rechenressourcen am Edge-Rechenknoten identifiziert wird, um den Typ der Arbeitslast lokal zu verarbeiten.
  46. Verfahren, das durch eine Endpunkt-Client-Vorrichtung durchgeführt wird, wobei die Endpunkt-Client-Vorrichtung zur Netzwerkkonnektivität mit einem ersten Satellitennetzwerk und mit einem zweiten terrestrischen Netzwerk in der Lage ist, wobei das Verfahren Folgendes umfasst: Identifizieren einer Arbeitslast zur Rechenverarbeitung; Bestimmen eines Orts für die Rechenverarbeitung der Arbeitslast, wobei der Ort aus Folgendem ausgewählt ist: rechenressourcen, die an einem Edge-Rechenknoten bereitgestellt werden, auf die über das zweite terrestrische Netzwerk zugegriffen werden kann, oder Rechenressourcen, die an einem entfernten Dienst bereitgestellt werden, auf den über das erste Satellitennetzwerk zugegriffen werden kann; und Kommunizieren der Arbeitslast zu dem identifizierten Ort; Wobei Netzwerkkonnektivität mit dem Satellitennetzwerk intermittierend basierend auf der Verfügbarkeit des Satellitennetzwerks bereitgestellt wird.
  47. Verfahren nach Anspruch 46, wobei das Satellitennetzwerk ein Leo(Low-Orbit)-Satellitennetzwerk ist, wobei das LEO-Satellitennetzwerk eine Abdeckung an die Endpunkt-Client-Vorrichtung von mehreren Satellitenfahrzeugen basierend auf Orbit-Positionen der Satellitenfahrzeuge bereitstellt.
  48. Verfahren nach Anspruch 47, wobei das LEO-Satellitennetzwerk mehrere Konstellationen beinhaltet, wobei jede der mehreren Konstellationen eine jeweilige Vielzahl von Satellitenfahrzeugen bereitstellt, wobei eine Netzwerkabdeckung für die Endpunktclientvorrichtung auf einer Position der Vielzahl von Konstellationen basiert.
  49. Verfahren nach Anspruch 46, wobei der Edge-Rechenknoten an einer Basisstation des zweiten terrestrischen Netzwerks bereitgestellt ist, wobei die Basisstation Drahtlosnetzwerkkonnektivität an die Endpunkt-Client-Vorrichtung bereitstellt.
  50. Verfahren nach Anspruch 49, wobei die Drahtlosnetzwerkkonnektivität durch ein 4G-Long-Term-Evolution(LTE)- oder 5G-Netzwerk bereitgestellt wird, das gemäß einem 3GPP-Standard arbeitet.
  51. Verfahren nach Anspruch 46, wobei der Ort für die Rechenverarbeitung basierend auf einer Latenz von Kommunikationen über das erste Satellitennetzwerk und einer Zeit zum Verarbeiten an den Rechenressourcen bestimmt wird.
  52. Verfahren nach Anspruch 46, wobei der Ort für die Rechenverarbeitung basierend auf einer mit der Arbeitslast assoziierten Dienstgütevereinbarung identifiziert wird.
  53. Verfahren nach Anspruch 52, wobei der Ort für die Rechenverarbeitung basierend auf Anweisungen von einem Netzwerkorchestrator identifiziert wird, wobei der Netzwerkorchestrator Orchestrierung für mehrere Edge-Computing-Orte, einschließlich des Edge-Rechenknotens, bereitstellt.
  54. Verfahren nach Anspruch 46, ferner umfassend: Empfangen von Ergebnissen der Rechenverarbeitung der Arbeitslast.
  55. Verfahren nach Anspruch 54, wobei der Ort für die Rechenverarbeitung basierend auf (i) einem Typ der Arbeitslast und (ii) Verfügbarkeit der Rechenressourcen am Edge-Rechenknoten identifiziert wird, um den Typ der Arbeitslast lokal zu verarbeiten.
  56. Verfahren zum Bestimmen einer Satellitennetzabdeckung von einem Leo(Low-Orbit)-Satellitensystem, das durch eine terrestrische Rechenvorrichtung durchgeführt wird, umfassend: Erhalten von Satellitenabdeckungsdaten für einen Breiten und Längen eines terrestrischen Bereichs, wobei die Satellitenabdeckungsdaten eine Angabe von Zeit und Intensität eines erwarteten Strahlgrundabdrucks am terrestrischen Bereich beinhalten; Identifizieren, basierend auf den Satellitenabdeckungsdaten, einer Satellitenabdeckung zur Konnektivität mit einem Satellitennetzwerk unter Verwendung des LEO-Satellitensystems; und Anpassen von Edge-Computing-Operationen an der terrestrischen Rechenvorrichtung basierend auf den Satellitenabdeckungsdaten.
  57. Verfahren nach Anspruch 56, wobei die Satellitenabdeckungsdaten eine Identifikation des Breitengrads, des Längengrads und der Meereshöhe beinhalten, die zum Satellitenempfang im terrestrischen Bereich verwendet werden.
  58. Verfahren nach Anspruch 57, wobei die Satellitenabdeckungsdaten ferner einen Radius für die erwartete Strahlgrundfläche, eine Zeit für eine erwartete Strahlgrundfläche in der Meereshöhe und eine minimale Intensität für die erwartete Strahlgrundfläche in der Meereshöhe beinhalten.
  59. Verfahren nach Anspruch 56, wobei die Satellitenabdeckungsdaten ferner einen mittleren Breitenpunkt des erwarteten Strahlgrundrisses und einen mittleren Längen des erwarteten Strahlgrundrisses beinhalten.
  60. Verfahren nach Anspruch 56, wobei eine Anforderung für die Satellitendeckungsdaten eine Kennung eines Satellitenfahrzeugs oder einer Satellitenkonstellation beinhaltet.
  61. Verfahren nach Anspruch 56, wobei eine Anforderung für die Satellitenabdeckungsdaten eine Zeitdauer beinhaltet, die benötigt wird, um Kommunikationsoperationen über das Satellitennetzwerk durchzuführen, Und die Satellitenabdeckungsdaten beinhalten eine Zeitmenge, die zum Durchführen der Kommunikationsoperationen über das Satellitennetzwerk verfügbar ist.
  62. Verfahren nach Anspruch 61, wobei die Satellitendeckungsdaten eine Kennung und einen Namen eines Satellitenfahrzeugs oder einer Satellitenkonstellation beinhalten, um die Kommunikationsoperationen über das Satellitennetzwerk durchzuführen.
  63. Verfahren nach Anspruch 56, wobei das Anpassen der Edge-Computing-Operationen das Durchführen von Operationen lokal an einem terrestrischen Edge-Computing-Ort umfasst.
  64. Verfahren nach Anspruch 56, wobei das Anpassen der Edge-Rechenoperationen Abladen von Rechenoperationen von einem terrestrischen Rechenort an einen Ort umfasst, auf den über das Satellitennetzwerk zugegriffen werden kann.
  65. Verfahren nach Anspruch 64, wobei der über das Satellitennetzwerk zugreifbare Ort einen Edge-Rechenknoten umfasst, der sich innerhalb mindestens eines der Folgenden befindet: Ein Satellitenfahrzeug, das durch die Satellitenabdeckungsdaten angegeben ist, eine Satellitenkonstellationsverbindungstabelle über eine Verbindung, die durch die Satellitenabdeckungsdaten angegeben wird, oder eine Masse-Edge-Verarbeitungsort, der über eine Verbindung verbindbar ist, die durch die Satellitenabdeckungsdaten angegeben ist.
  66. Verfahren nach Anspruch 64, wobei der über das Satellitennetzwerk zugreifbare Ort ein Cloud-Rechensystem umfasst, auf das über einen Backhaul des Satellitennetzwerks zugegriffen werden kann.
  67. Verfahren nach Anspruch 56, wobei das Anpassen der Edge-Computing-Operationen das Abladen von Dateninhaltsoperationen von einem terrestrischen Rechenort an einen Dateninhaltsspeicherort umfasst, auf den über das Satellitennetzwerk zugegriffen werden kann.
  68. Verfahren nach Anspruch 56, wobei das Anpassen von Edge-Computing-Operationen an der terrestrischen Rechenvorrichtung ferner auf Latenz- und Dienstinformationen basiert, die basierend auf den Satellitenabdeckungsdaten berechnet werden.
  69. Verfahren nach Anspruch 56, ferner umfassend Erhalten der Satellitenabdeckungsdaten durch Übertragen, an einen Dienstanbieter, einer Anforderung für Satellitenabdeckungsdaten, damit eine Satellitenabdeckung am Breiten- und Längengrad des terrestrischen Bereichs auftritt.
  70. Verfahren nach Anspruch 56, wobei das Anpassen von Edge-Computing-Operationen Durchführen von Rechen- und Routing-Entscheidungsberechnungen basierend auf Informationen umfasst, die angeben: Verfügbare Satellitennetzwerkkommunikationsfrequenzen, Inter-Satelliten-Links, verfügbare Satellitennetzwerkkommunikationsintensität.
  71. Verfahren zur Sensordatensammlung und -Verarbeitung unter Verwendung eines Satellitenkommunikationsnetzes, das Folgendes umfasst: Erhalten, von einer Sensorvorrichtung, von Erfassungsdaten bezüglich einer beobachteten Bedingung, wobei die Erfassungsdaten einer Zwischenentität unter Verwendung eines terrestrischen Drahtloskommunikationsnetzes bereitgestellt werden; Bewirken, dass die Zwischenentität die Erfassungsdaten an einen Edge-Computing-Ort überträgt, wobei die Erfassungsdaten unter Verwendung eines nicht-terrestrischen Satellitenkommunikationsnetzwerks an den Edge-Computing-Ort kommuniziert werden; und Erhalten von Ergebnissen der Verarbeitung der Erfassungsdaten von dem Edge-Computing-Ort über das nicht-terrestrische Satellitenkommunikationsnetzwerk.
  72. Verfahren nach Anspruch 71, wobei die Zwischenentität Netzwerkkonnektivität über das terrestrische Drahtloskommunikationsnetzwerk für die Sensorvorrichtung bereitstellt.
  73. Verfahren nach Anspruch 72, wobei die Zwischenentität eine Basisstation, ein Zugangspunkt oder ein Netzwerk-Gateway ist und wobei die Zwischenentität Netzwerkfunktionen zum Betrieb des terrestrischen Drahtloskommunikationsnetzwerks bereitstellt.
  74. Verfahren nach Anspruch 72, wobei die Zwischenentität eine Drohne ist.
  75. Verfahren nach Anspruch 74, wobei die Drohne dazu ausgelegt ist, Netzwerkkommunikationen zwischen der Sensorvorrichtung und einem Zugangspunkt, der auf das Satellitenkommunikationsnetzwerk zugreift, bereitzustellen.
  76. Verfahren nach Anspruch 74, wobei die Drohne eine Kommunikationsschaltungsanordnung zum direkten Zugreifen auf das Satellitenkommunikationsnetzwerk und Kommunizieren mit diesem beinhaltet.
  77. Verfahren nach Anspruch 71, wobei das terrestrische Drahtloskommunikationsnetz durch ein 4G-Long-Term-Evolution(LTE)- oder 5G-Netz bereitgestellt wird, das gemäß einem 3GPP-Standard arbeitet.
  78. Verfahren nach Anspruch 71, wobei der Edge-Computing-Ort zur Verarbeitung basierend auf einer Latenz von Kommunikationen über das Satellitenkommunikationsnetzwerk und einer Zeit, die zur Verarbeitung am Edge-Computing-Ort benötigt wird, identifiziert wird.
  79. Verfahren nach Anspruch 71, wobei das Satellitenkommunikationsnetzwerk ein Niedrigerdorbit(LEO)-Satellitenkommunikationsnetzwerk ist, das aus einer Konstellation mehrerer LEO-Satelliten bereitgestellt wird.
  80. Verfahren nach Anspruch 79, wobei der Edge-Computing-Ort unter Verwendung von Verarbeitungsschaltkreisen bereitgestellt wird, die sich an einem LEO-Satellitenfahrzeug der Konstellation befinden.
  81. Verfahren nach Anspruch 79, wobei der Edge-Computing-Ort unter Verwendung jeweiliger Verarbeitungsschaltkreise bereitgestellt wird, die sich an mehreren LEO-Satellitenfahrzeugen der Konstellation befinden.
  82. Verfahren nach Anspruch 79, wobei der Edge-Computing-Ort unter Verwendung eines Verarbeitungsdienstes bereitgestellt wird, auf den über das LEO-Satellitenkommunikationsnetzwerk zugegriffen werden kann.
  83. Verfahren nach Anspruch 71, wobei das Verarbeiten der Erfassungsdaten das Identifizieren von Datenanomalien basierend auf einem Betriebszustand eines Systems, das durch die Sensoreinrichtung überwacht wird, umfasst.
  84. Verfahren nach Anspruch 83, wobei das System ein Industriesystem ist und wobei die beobachtete Bedingung mindestens eine Umgebungs- oder Betriebscharakteristik des industriellen Systems betrifft.
  85. Verfahren nach Anspruch 83, ferner umfassend: Übertragen eines Wartungsbefehls zur Wartung des Systems als Reaktion auf die Ergebnisse der Verarbeitung der Erfassungsdaten.
  86. Verfahren nach Anspruch 71, wobei die Erfassungsdaten Bilddaten umfassen und wobei die Ergebnisse der Verarbeitung der Erfassungsdaten Nichtbilddaten umfassen, die an dem Edge-Computing-Ort erzeugt werden.
  87. Verfahren nach Anspruch 71, wobei die Erfassungsdaten von einer Sensoraggregationsvorrichtung erhalten und zwischengespeichert werden, wobei die Sensoraggregationsvorrichtung mit mehreren Sensorvorrichtungen einschließlich der Sensorvorrichtung verbunden ist.
  88. Verfahren nach Anspruch 87, wobei die Abtastdaten an der Sensoraggregationsvorrichtung aus Rohdaten aggregiert werden, wobei die Rohdaten aus der Vielzahl von Sensorvorrichtungen die Sensorvorrichtung beinhalten.
  89. Verfahren nach Anspruch 88, wobei die Sensoraggregationsvorrichtung mindestens einen Algorithmus auf die Rohdaten anwendet, um die Abtastdaten zu erzeugen.
  90. Verfahren nach Anspruch 71, wobei das Verfahren durch die Zwischenentität durchgeführt wird.
  91. Verfahren zum Koordinieren von Rechenoperationen in einem Satellitenkommunikationsnetz, das Folgendes umfasst: Erhalten, an einem Computerknoten des Satellitenkommunikationsnetzwerks, eines Koordinationsplans zum Durchführen von Rechen- und Kommunikationsoperationen innerhalb des Satellitenkommunikationsnetzwerks; Durchführen einer Rechenaktion an Daten in dem Satellitenkommunikationsnetzwerk basierend auf dem Koordinationsplan, wobei die Rechenaktion ein Datenverarbeitungsergebnis erhalten soll; Durchführen einer Kommunikationsaktion mit den Daten über das Satellitenkommunikationsnetzwerk basierend auf dem Koordinationungsplan; und Übertragen des Datenverarbeitungsergebnisses von dem Satellitenkommunikationsnetzwerk an eine terrestrische Entität.
  92. Verfahren nach Anspruch 91, wobei der Koordinationsplan zum Durchführen von Rechen- und Kommunikationsoperationen mehrere Einschränkungen beinhaltet, wobei sich die mehreren Einschränkungen auf Folgendes beziehen: Standortinformationen; Reihenfolge von Aufgaben; Hardwarebeschränkungen; Nutzungsbeschränkungen; Nutzungszeitraum; Konnektivitätsbedingungen; Ressourceninformationen; Ressourcenbeschränkungen; oder geografische Einschränkungen.
  93. Verfahren nach Anspruch 91, ferner umfassend: Reservieren von Rechenressourcen an dem Computerknoten basierend auf dem Koordinationsplan.
  94. Verfahren nach Anspruch 91, wobei der Koordinationsplan zum Durchführen von Rechen- und Kommunikationsoperationen innerhalb des Satellitenkommunikationsnetzwerks bewirkt, dass das Satellitenkommunikationsnetzwerk mehrere Rechenressourcen in dem Satellitenkommunikationsnetzwerk zum Durchführen der Rechenaktion mit den Daten reserviert.
  95. Verfahren nach Anspruch 91, wobei das Kommunizieren der Daten ein Kommunizieren der Daten an einen terrestrischen Verarbeitungsort beinhaltet und wobei das Durchführen einer Aktion mit den Daten ein Erhalten des Datenverarbeitungsergebnisses von dem terrestrischen Verarbeitungsort beinhaltet.
  96. Verfahren nach Anspruch 91, wobei das Kommunizieren der Daten ein Kommunizieren der Daten zu anderen Knoten in dem Satellitenkommunikationsnetzwerk beinhaltet.
  97. Verfahren nach Anspruch 91, ferner umfassend: Identifizieren, basierend auf dem Koordinationsplan, eines Timings zum Durchführen der Rechenaktion.
  98. Verfahren nach Anspruch 97, wobei das Timing zum Durchführen der Rechenaktion auf einer Koordination der Verarbeitung zwischen mehreren Satellitenknoten in einer Konstellation des Satellitenkommunikationsnetzwerks basiert.
  99. Verfahren nach Anspruch 91, ferner umfassend: Identifizieren, basierend auf dem Koordinationsplan, eines Timings zum Übertragen des Datenverarbeitungsergebnisses von dem Satellitenkommunikationsnetzwerk an die terrestrische Entität.
  100. Verfahren nach Anspruch 99, wobei das Timing zum Übertragen des Datenverarbeitungsergebnisses auf einer Koordination der Verarbeitung zwischen einer Vielzahl von Satellitenknoten in einer Konstellation des Satellitenkommunikationsnetzwerks basiert.
  101. Verfahren nach Anspruch 91, wobei ein Timing des Ausführens der Rechenaktion und ein Timing zum Übertragen des Datenverarbeitungsergebnisses auf Orbit-Positionen eines oder mehrerer Satellitenfahrzeuge des Satellitenkommunikationsnetzwerks basieren.
  102. Verfahren nach Anspruch 91, wobei der Koordinationsplan bewirkt, dass das Satellitenkommunikationsnetz die Verarbeitung der Daten von einem ersten Rechenknoten an einen zweiten Rechenknoten weitergibt, auf den innerhalb des Satellitenkommunikationsnetzes zugegriffen werden kann.
  103. Verfahren nach Anspruch 91, wobei die Rechenaktion auf den Daten basierend auf Ressourcenverfügbarkeit innerhalb des Satellitenkommunikationsnetzwerks oder eines Netzwerks, das mit dem Satellitenkommunikationsnetzwerk verbunden ist, durchgeführt wird.
  104. Verfahren nach Anspruch 91, wobei die Kommunikationsaktion basierend auf Verbindungsverfügbarkeit innerhalb des Satellitenkommunikationsnetzwerks oder eines mit dem Satellitenkommunikationsnetzwerk verbundenen Netzwerks durchgeführt wird.
  105. Verfahren nach Anspruch 91, wobei die terrestrische Entität eine Client-Vorrichtung, ein terrestrischer Edge-Rechenknoten, ein terrestrischer Cloud-Rechenknoten, ein anderer Rechenknoten einer Konstellation in dem Satellitenkommunikationsnetzwerk oder ein Rechenknoten einer anderen Satellitenkonstellation ist.
  106. Verfahren zum Orchestrieren von Rechenoperationen in einem Satellitenkommunikationsnetzwerk basierend auf einem Ressourcenaufwand, umfassend: Identifizieren einer Anforderung für einen Rechendienst; Identifizieren von Bedingungen zur Nutzung des Rechendienstes, die die Anforderung erfüllen; Identifizieren einer Vielzahl verfügbarer Rechendienste, die über das Satellitenkommunikationsnetzwerk zugänglich sind, wobei die verfügbaren Rechendienste identifiziert werden, um die Bedingungen zur Nutzung zu erfüllen; Berechnen des Ressourcenaufwands der Nutzung der jeweiligen Dienste der verfügbaren Rechendienste; Auswählen eines der mehreren verfügbaren Rechendienste basierend auf dem Ressourcenaufwand; und Durchführen von Datenoperationen mit dem ausgewählten Rechendienst über das Satellitenkommunikationsnetzwerk.
  107. Verfahren nach Anspruch 106, ferner umfassend: Auswählen eines zweiten der Vielzahl verfügbarer Rechendienste basierend auf dem Ressourcenaufwand; und Durchführen von Datenoperationen mit dem zweiten ausgewählten Rechendienst über das Satellitenkommunikationsnetzwerk.
  108. Verfahren nach Anspruch 106, wobei die Bedingungen zur Nutzung des Rechendienstes Bedingungen betreffen, die von einer Dienstgütevereinbarung erforderlich sind.
  109. Verfahren nach Anspruch 106, wobei die Bedingungen für die Nutzung des Rechendienstes eine maximale Zeit für die Nutzung des Rechendienstes bereitstellen.
  110. Verfahren nach Anspruch 109, wobei die verfügbaren Rechendienste basierend auf Satellitenabdeckung an einem geografischen Standort innerhalb der maximalen Zeit zur Nutzung des Rechendienstes identifiziert werden.
  111. Verfahren nach Anspruch 106, ferner umfassend: Empfangen von Informationen, die die Vielzahl verfügbarer Rechendienste identifizieren und zumindest einen Teil des Ressourcenaufwands der Nutzung der jeweiligen Dienste identifizieren.
  112. Verfahren nach Anspruch 106, wobei die mehreren verfügbaren Rechendienste unter mehreren Satelliten bereitgestellt werden.
  113. Verfahren nach Anspruch 112, wobei die mehreren Satelliten zwischen mehreren Satellitenkonstellationen betrieben werden, die von mehreren Satellitenkommunikationsdienstanbietern bereitgestellt werden.
  114. Verfahren nach Anspruch 106, ferner umfassend: Abbilden der verfügbaren Rechendienste auf jeweilige geografische Jurisdiktionen, wobei der Ressourcenaufwand Geldkosten ist, die auf den jeweiligen geografischen Jurisdiktionen basieren.
  115. Verfahren nach Anspruch 106, wobei die Kosten in Geld basierend auf mindestens einer digitalen Dienststeuer berechnet werden, die mit einem geografischen Gebiet assoziiert ist.
  116. Verfahren nach Anspruch 106, wobei der Rechendienst ein Content Data Network (CDN) -Dienst ist, der über das Satellitenkommunikationsnetzwerk bereitgestellt wird, und wobei der Ressourcenaufwand auf Daten basiert, die über den CDN-Dienst abgerufen werden sollen.
  117. Verfahren nach Anspruch 106, wobei das Verfahren durch einen Orchestrator, eine Basisstation oder eine Benutzervorrichtung durchgeführt wird, die/das mit dem Satellitenkommunikationsnetzwerk verbunden ist.
  118. Verfahren zum koordinierten Daten-Handover in einem Satellitenkommunikationsnetz, das Folgendes umfasst: Übertragen, an ein Satellitenkommunikationsnetzwerk, das eine benannte Datennetzwerk(NDN)-Architektur implementiert, einer Dienstanforderung für die NDN-Architektur; Empfangen, von einem ersten Satelliten des Satellitenkommunikationsnetzes, einer anfänglichen Antwort auf die Dienstanforderung; Übertragen, zu dem Satellitenkommunikationsnetzwerk, einer aktualisierten Dienstanforderung für die NDN-Architektur, als Reaktion darauf, dass sich der erste Satellit aus dem Kommunikationsbereich bewegt; und Empfangen, von einem zweiten Satelliten des Satellitenkommunikationsnetzes, einer aktualisierten Antwort auf die aktualisierte Dienstanforderung basierend auf einem Handover der Dienstanforderung von dem ersten Satelliten zu dem zweiten Satelliten.
  119. Verfahren nach Anspruch 118, wobei die Dienstanforderung eine Anforderung für rechenoperationen und/oder Funktionsleistungsfähigkeit und/oder Datenabrufoperationen über die NDN-Architektur ist.
  120. Verfahren nach Anspruch 118, wobei die anfängliche Antwort auf die Dienstanforderung Teilergebnisse für die Dienstanforderung umfasst und wobei die aktualisierte Antwort auf die aktualisierte Dienstanforderung verbleibende Ergebnisse für die Dienstanforderung umfasst.
  121. Verfahren nach Anspruch 118, wobei das Handover der Dienstanforderung zwischen dem ersten Satelliten und dem zweiten Satelliten basierend auf dem Weiterleiten der Dienstanforderung von dem ersten Satelliten zu dem zweiten Satelliten koordiniert wird, Und basierend darauf, dass der zweite Satellit Daten von dem ersten Satelliten erhält, die mit der anfänglichen Antwort auf die Dienstanforderung assoziiert sind.
  122. Verfahren nach Anspruch 118, wobei das Verfahren durch ein Benutzergerät durchgeführt wird, das direkt mit dem Satellitenkommunikationsnetzwerk verbunden ist.
  123. Verfahren nach Anspruch 118, wobei das Verfahren durch einen Masseknoten durchgeführt wird, der mit dem Satellitenkommunikationsnetzwerk verbunden ist, wobei der Bodenknoten Daten der Dienstanforderungen und die Antworten mit einem verbundenen Benutzer kommuniziert.
  124. Verfahren nach Anspruch 123, wobei der Bodenknoten die Dienstanforderung als Reaktion darauf aufruft, dass er nicht in der Lage ist, die Dienstanforderung an dem Bodenknoten zu erfüllen.
  125. Verfahren nach Anspruch 118, wobei das Handover der Dienstanforderung Koordination der Rechenergebnisse beinhaltet, die von dem ersten Satelliten zu dem zweiten Satelliten kommuniziert werden.
  126. Verfahren nach Anspruch 125, wobei die Rechenergebnisse Daten beinhalten, die für einen Zeitraum an dem ersten Satelliten durchgeführt werden.
  127. Verfahren nach Anspruch 118, wobei die Dienstanforderung eine NDN-Anforderung basierend auf einem Namen einer Funktion und einen Datensatz zum Betreiben der Funktion beinhaltet.
  128. Verfahren nach Anspruch 118, wobei der erste Satellit oder der zweite Satellit dazu konfiguriert sind, die Dienstanforderung basierend auf zusätzlichen Rechenknoten zu erfüllen, auf die von dem Satellitenkommunikationsnetzwerk zugegriffen werden kann.
  129. Verfahren nach Anspruch 118, wobei der erste Satellit und der zweite Satellit Teil einer Niedrigerdorbit(LEO)-Satellitenkonstellation sind.
  130. Verfahren nach Anspruch 118, wobei die Auswahl des ersten Satelliten oder des zweiten Satelliten zum Erfüllen der Dienstanforderung auf Netzwerkrouting- oder Kapazitätsregeln basiert.
  131. Verfahren nach Anspruch 130, wobei die Auswahl des ersten Satelliten oder des zweiten Satelliten zum Erfüllen der Dienstanforderung ferner auf Dienstgüte- und Dienstgüteanforderungen basiert.
  132. Verfahren nach Anspruch 118, wobei die aktualisierte Dienstanforderung ferner basierend auf einer Bewegung einer mobilen Vorrichtung, die die Dienstanforderung erzeugt, koordiniert wird.
  133. Vorrichtung, die Folgendes umfasst: eine Verarbeitungsschaltungsanordnung; und Speichervorrichtung, die darauf umgesetzte Anweisungen aufweist, wobei die Anweisungen, wenn sie von der Verarbeitungsschaltungsanordnung ausgeführt werden, die Verarbeitungsschaltungsanordnung konfigurieren, Operationen zum Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung durchzuführen, nach einem der Ansprüche 1 bis 132.
  134. Verfahren, umfassend eine Vielzahl von Operationen, die mit einem Prozessor und einem Speicher einer Vorrichtung ausgeführt werden, um das Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung durchzuführen, nach einem der Ansprüche 1 bis 132.
  135. Nichtflüchtiges maschinenlesbares Speicherungsmedium, das Anweisungen beinhaltet, wobei die Anweisungen, wenn sie von einer Verarbeitungsschaltungsanordnung einer Maschine ausgeführt werden, die Verarbeitungsschaltungsanordnung veranlassen, das Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung nach einem der Ansprüche 1 bis 132 durchzuführen.
  136. Vorrichtung, umfassend jeweilige Mittel zum Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung, nach einem der Ansprüche 1 bis 132.
  137. Satellitenfahrzeug, das eine Schaltungsanordnung zum Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung nach einem der Ansprüche 1 bis 132 umfasst.
  138. Benutzergerätkommunikationsvorrichtung, umfassend eine Schaltungsanordnung zum Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung nach einem der Ansprüche 1 bis 132.
  139. Kommunikationsnetzwerk 5G, das Netzwerkgerät umfasst, das zum Implementieren oder Einsetzen von Edge-Computing-Operationen in einer Satellitenkommunikationsumgebung konfiguriert ist, nach einem der Ansprüche 1 bis 132.
  140. Satellitensystem, das jeweilige Komponenten umfasst, die dazu eingerichtet oder konfiguriert sind, Operationen nach einem der Ansprüche 1 bis 132 durchzuführen.
DE112020007134.0T 2020-05-01 2020-12-24 Edge-computing in satellitenkonnektivitätsumgebungen Pending DE112020007134T5 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US202063018844P 2020-05-01 2020-05-01
US63/018,844 2020-05-01
US202063065302P 2020-08-13 2020-08-13
US63/065,302 2020-08-13
US202063077320P 2020-09-11 2020-09-11
US63/077,320 2020-09-11
US202063104344P 2020-10-22 2020-10-22
US63/104,344 2020-10-22
US202063124520P 2020-12-11 2020-12-11
US63/124,520 2020-12-11
US202063129355P 2020-12-22 2020-12-22
US63/129,355 2020-12-22
PCT/US2020/067007 WO2021221736A2 (en) 2020-05-01 2020-12-24 Edge computing in satellite connectivity environments

Publications (1)

Publication Number Publication Date
DE112020007134T5 true DE112020007134T5 (de) 2023-03-02

Family

ID=78332105

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020007134.0T Pending DE112020007134T5 (de) 2020-05-01 2020-12-24 Edge-computing in satellitenkonnektivitätsumgebungen

Country Status (7)

Country Link
US (1) US20230156826A1 (de)
EP (1) EP4143990A2 (de)
JP (1) JP2023523923A (de)
KR (1) KR20230006461A (de)
CN (1) CN115917991A (de)
DE (1) DE112020007134T5 (de)
WO (1) WO2021221736A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11777595B2 (en) * 2021-02-03 2023-10-03 Mangata Networks, Inc. Non-geostationary satellite communications network architectures with mesh network edge data centers

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11575512B2 (en) * 2020-07-31 2023-02-07 Operant Networks Configurable network security for networked energy resources, and associated systems and methods
US20210081271A1 (en) * 2020-09-25 2021-03-18 Intel Corporation Dynamic tracing control
CN112333796B (zh) * 2020-11-17 2022-04-05 重庆邮电大学 软件定义卫星网络系统中基于演化博弈的多用户切换方法
US11895508B1 (en) 2021-03-18 2024-02-06 Amazon Technologies, Inc. Demand-based allocation of ephemeral radio-based network resources
CN114051254B (zh) * 2021-11-08 2024-05-03 南京大学 一种基于星地融合网络的绿色云边协同计算卸载方法
CN114036103B (zh) * 2021-11-08 2022-05-03 成都天巡微小卫星科技有限责任公司 基于华为昇腾ai处理器的星载ai综合电子系统
CN114268357B (zh) * 2021-11-28 2023-04-25 西安电子科技大学 基于低轨卫星边缘计算任务卸载方法、系统、设备及应用
CN114499624B (zh) * 2021-12-08 2022-12-13 上海交通大学 天地一体化信息网络中多源数据融合处理方法及系统
CN114422423B (zh) * 2021-12-24 2024-02-20 大连大学 一种基于sdn与ndn的卫星网络多约束路由方法
CN114337783B (zh) * 2021-12-30 2023-11-17 中国电子科技集团公司电子科学研究院 一种空间分布式边缘计算装置及业务处理方法
KR20230105592A (ko) * 2022-01-04 2023-07-11 한국전자통신연구원 Icn 네트워크에서 가상 사설 네트워크 서비스 제공 장치 및 방법
US20230327754A1 (en) * 2022-04-08 2023-10-12 All.Space Networks Limited Method of operating a satellite communications terminal
CN114826383B (zh) * 2022-04-28 2022-10-25 军事科学院系统工程研究院网络信息研究所 基于数据映射的卫星通信频轨资源全任务周期管控方法
CN115361048B (zh) * 2022-07-01 2023-08-15 北京邮电大学 一种巨型低轨星座无服务器边缘计算任务编排方法及装置
US20240031254A1 (en) * 2022-07-20 2024-01-25 Wheel Health Inc. Scheduling method and system for middleware-mediated user-to-user service
CN115242295B (zh) * 2022-07-21 2023-04-21 中国人民解放军战略支援部队航天工程大学 一种卫星网络sdn多控制器部署方法及系统
US11995103B2 (en) 2022-10-28 2024-05-28 International Business Machines Corporation Data security in remote storage systems storing duplicate instances of data
US11888701B1 (en) * 2022-12-14 2024-01-30 Amazon Technologies, Inc. Self-healing and resiliency in radio-based networks using a community model
CN116260507B (zh) * 2023-05-16 2023-07-21 中南大学 一种双层卫星网络协同分簇方法、系统、设备及存储介质
CN117118495B (zh) * 2023-08-23 2024-05-28 中国科学院微小卫星创新研究院 天基通算一体化网络系统、遥感数据在轨处理方法
CN117835357A (zh) * 2024-03-05 2024-04-05 广东世炬网络科技有限公司 一种基于地理围栏的ntn连接的切换方法、装置、设备及介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8948081B2 (en) * 2012-04-13 2015-02-03 Intel Corporation Device, system and method of multiple-stream wireless communication
AU2014301422A1 (en) * 2013-06-28 2016-01-28 Nokia Solutions And Networks Oy Method and apparatus for offloading traffic from cellular to wlan using assistance information
US9538441B2 (en) * 2014-12-18 2017-01-03 At&T Mobility Ii Llc System and method for offload of wireless network
FR3060920B1 (fr) * 2016-12-20 2019-07-05 Thales Systeme et procede pour la transmission de donnees dans un systeme satellitaire
BR112019018025B1 (pt) * 2017-03-02 2021-07-13 Viasat, Inc Método para atribuição dinâmica de feixe em uma rede de comunicações de satélite geoestacionário, sistema para atribuição dinâmica de feixe em uma rede de comunicações de satélite geoestacionário, processador para atribuição dinâmica de feixe em uma rede de comunicações de satélite geoestacionário, e nó de processamento terrestre da rede de comunicações de satélite geoestacionário
US10419107B2 (en) * 2017-03-24 2019-09-17 Hughes Network Systems, Llc Channel bonding in an adaptive coding and modulation mode
US10686907B2 (en) * 2017-08-25 2020-06-16 Hughes Network Systems, Llc Reducing bandwidth consumption and latency in satellite communications
US10623995B2 (en) * 2017-12-15 2020-04-14 Gogo Llc Dynamic load balancing of satellite beams

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11777595B2 (en) * 2021-02-03 2023-10-03 Mangata Networks, Inc. Non-geostationary satellite communications network architectures with mesh network edge data centers

Also Published As

Publication number Publication date
CN115917991A (zh) 2023-04-04
KR20230006461A (ko) 2023-01-10
WO2021221736A2 (en) 2021-11-04
EP4143990A2 (de) 2023-03-08
US20230156826A1 (en) 2023-05-18
JP2023523923A (ja) 2023-06-08
WO2021221736A3 (en) 2022-02-10

Similar Documents

Publication Publication Date Title
DE112020007134T5 (de) Edge-computing in satellitenkonnektivitätsumgebungen
Guo et al. Enabling massive IoT toward 6G: A comprehensive survey
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
DE102020125219A1 (de) End-to-end -dienstqualität in edge-computing -umgebungen
DE102020131613A1 (de) Verfahren, system und produkt zum implementieren von deterministischem on-boarding und planen virtualisierter arbeitslasten für edge-computing.
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
DE102022203247A1 (de) Disintermedierte Attestierung in einem MEC-Service-MESH-Framework
NL2029044A (en) Intelligent data forwarding in edge networks
EP4155933A1 (de) Netzwerkunterstützte sicherheitsbasierte orchestration mit niedriger latenz
DE102021210882A1 (de) Erweitertes peer-to-peer (p2p) mit edge-vernetzung
DE102021209282A1 (de) Verfahren, einrichtungen und systeme zur gemeinsamen nutzung von rechenressourcen zwischen edge-rechenknoten unter verwendung eines overlay-managers
DE102022203249A1 (de) Mehrfachzugriff-edge-computing- (mec-) fahrzeug-zu-alles-(v2x-) interoperabilitätsunterstützung für mehrere v2x-nachrichtenbroker
DE102021207160A1 (de) Verfahren und einrichtung zur verwaltung der dienstgüte in bezug auf service-level-agreements in einer rechenvorrichtung
DE112020007229T5 (de) Föderiertes mec-framework für kraftfahrzeugdienste
US20230189319A1 (en) Federated learning for multiple access radio resource management optimizations
US20210320988A1 (en) Information centric network unstructured data carrier
DE102022203111A1 (de) Auf netzwerkfluss basierende hardwarezuweisung
US20210117697A1 (en) Edge automatic and adaptive processing activations
DE102022208684A1 (de) Verfahren und einrichtung für resilienz mithilfe digitaler zwillinge
DE102021209043A1 (de) Methods and apparatus to select a location of execution of a computation
DE102021121267A1 (de) Verfahren, Systeme, Vorrichtungen und Erzeugnisse zur Verwaltung des Zugriffs auf dezentrale Data Lakes
US20220345210A1 (en) Ultra-low latency inter-satellite communication links
US20210014203A1 (en) One-touch inline cryptographic data processing
DE102022121227A1 (de) Dynamische slice-rekonfiguration während fafo(fault-attack-failure-outage)-ereignissen
DE102022125180A1 (de) System und verfahren für den zugriff auf rechenressourcen verteilt auf eine gruppe von satelliten