DE102021209988A1 - Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen - Google Patents

Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen Download PDF

Info

Publication number
DE102021209988A1
DE102021209988A1 DE102021209988.2A DE102021209988A DE102021209988A1 DE 102021209988 A1 DE102021209988 A1 DE 102021209988A1 DE 102021209988 A DE102021209988 A DE 102021209988A DE 102021209988 A1 DE102021209988 A1 DE 102021209988A1
Authority
DE
Germany
Prior art keywords
ppp
network
data unit
access
gma
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
DE102021209988.2A
Other languages
English (en)
Inventor
Jing Zhu
Shu-Ping Yeh
Menglei Zhang
Shilpa Talwar
Juan Fang
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 DE102021209988A1 publication Critical patent/DE102021209988A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/2878—Access multiplexer, e.g. DSLAM
    • H04L12/2887—Access multiplexer, e.g. DSLAM characterised by the offered subscriber services
    • H04L12/2889—Multiservice, e.g. MSAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/6215—Individual queue per QOS, rate or priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • 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/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • 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/0289—Congestion control
    • 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]

Landscapes

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

Abstract

Die vorliegende Offenbarung betrifft Mehrfachzugangsverwaltungsdienste (MAMS), wobei es sich um ein programmierbares Framework handelt, das Mechanismen für die flexible Auswahl von Netzwerkpfaden in einer Mehrfachzugangs-(MX-)Kommunikationsumgebung basierend auf den Bedürfnissen einer Anwendung bereitstellt. Funktionen für generischen Mehrfachzugang (GMA - Generic Multi-Access) sind ebenfalls in das MAMS-Framework integriert. Die vorliegende Offenbarung erörtert Pro-Paket-Priorisierung (PPP), Intraflussklassifizierung und Techniken aktiver Warteschlangenverwaltung (AQM - Active Queue Management) für MAMS/GMA-Systeme. Andere Ausführungsformen können beschrieben und/oder beansprucht sein.

Description

  • VERWANDTE ANMELDUNGEN
  • Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung. Nr. 63/077,495 , eingereicht am 11. September 2020 („[AC7128-Z]“), und der vorläufigen US-Anmeldung Nr. 63/078,782 , eingereicht am 15. September 2020 („[AD2388-Z]“), deren Inhalt hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen wird.
  • TECHNISCHES GEBIET
  • Die vorliegende Anmeldung betrifft allgemein Edge Computing, Netzwerkkommunikation und Kommunikationssystemimplementierungen und insbesondere Systeme/Netzwerke für Mehrfachzugangsverwaltungsdienste (MAMS - Multiple Access Management Services) und Frameworks für generischen Mehrfachzugang (GMA - Generic Multi-Access).
  • HINTERGRUND
  • MAMS (Multiple Access Management Services) ist ein programmierbares Framework, das Mechanismen zur flexiblen Auswahl von Netzwerkpfaden in einer Kommunikationsumgebung mit Mehrfachverbindung (-zugang) basierend auf Anwendungsbedürfnissen und/oder - anforderungen bereitstellt. Das MAMS-Framework kann durch ein Edge-Computing-System/- Netzwerk, wie etwa ETSI-MEC oder dergleichen, unterstützt werden. Zusätzlich dazu wurde die Systemarchitektur der fünften Generation (5G) des Partnerschaftsprojekts der dritten Generation (3GPP) erweitert, um eine Funktionalität ähnlich dem MAMS zu unterstützen, die als Vermittlung, Lenkung und Aufteilung von Zugriffsverkehr (ATSSS - Access Traffic Switching, Steering and Splitting) bezeichnet wird.
  • Figurenliste
  • In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Ziffern mit verschiedenen angehängten Buchstaben können verschiedene Instanzen ähnlicher Komponenten repräsentieren. Einige Implementierungen sind in den Figuren der beiliegenden Zeichnungen beispielhaft und nicht einschränkend veranschaulicht, wobei:
    • 1 ein beispielhaftes Mehrfachzugangsnetzwerk darstellt, das Mehrfachzugangsverwaltungsdienste (MAMS) nutzt. 2 veranschaulicht eine MAMS-Referenzarchitektur. 3 veranschaulicht ein beispielhaftes MX-Steuerebenenprotokoll und eine beispielhafte MX-Steuernachricht. 4 stellt ein Netzwerkmodell mit Konvergenzschicht dar. 5 stellt ein Beispiel für GMA-basierte Mehrfachzugangsverkehrsaufteilung für den Downlink dar.
    • 6 stellt beispielhafte GMA-Verkapselungsformate und ein auf einem generischen Paket-Typ (GPT) basierendes Paketformat dar. 7 stellt eine beispielhafte Prozedur für erweiterte MAMS-Steuernachrichten zur Pro-Paket-Priorisierung gemäß verschiedenen Ausführungsformen dar. 8 veranschaulicht ein beispielhaftes Internetprotokoll-(IP-)Paketkopfformat. 9 stellt einen GTP-basierten Intraflussklassifizierungsprotokollstapel dar. 10, 11, 12 und 13 zeigen beispielhafte Prozesse zum Durchführen von PPP-basierter aktiver Warteschlangenverwaltung (AQM).
    • 14 stellt eine Ende-zu-Ende-(e2e-)Netzwerkreferenzarchitektur mit generischem OTT-Mehrfachzugang (GMA - Generic Multi-Access) dar. 15 stellt ein Beispiel für GMA-Datenebenenfunktionalitäten dar. 16 veranschaulicht eine clientbasierte GMA-Datenverkehrssteuerungs-Zustandsmaschine. 17 stellt einen beispielhaften GMA-basierten Datenebenen-Protokollstapel für OTT-MAMS-Bereitstellungen und einen GMA-basierten MAMS-Datenebenen-Protokollstapel dar. 18 stellt ein Format einer GMA-Konvergenzprotokolldateneinheit (PDU) dar. 19 veranschaulicht verschiedene GMA-Paketformate.
    • 20 veranschaulicht eine beispielhafte Edge-Computing-Umgebung. 21 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge Computing. 22 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. 23 veranschaulicht einen beispielhaften Ansatz für Vernetzung und Dienste in einem Edge-Computing-System. 24 veranschaulicht eine Bereitstellung einer virtuellen Edge-Konfiguration in einem Edge-Computing-Systems, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. 25 veranschaulicht verschiedene Rechenanordnungen, die Container in einem Edge-Computing-System bereitstellen. 26 veranschaulicht einen Rechen- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System umfasst. 27 veranschaulicht eine MEC-Systemreferenzarchitektur. 28 veranschaulicht eine beispielhafte MEC-Dienstarchitektur. 29 veranschaulicht eine beispielhafte Softwareverteilungsplattform. 30 und 31 stellen beispielhafte Komponenten verschiedener Rechenknoten in einem oder mehreren Edge-Computing-System(en) dar.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die vorliegende Beschreibung betrifft allgemein Datenverarbeitungs-, Dienstverwaltungs-, Ressourcenzuweisungs-, Rechenverwaltungs-, Netzwerkkommunikations-, Anwendungspartitionierungs- und Kommunikationssystemimplementierungen, und insbesondere Techniken und Konfigurationen zum Anpassen verschiedener Edge-Computing-Vorrichtungen und -Entitäten, um mehrere Entitäten (z. B. mehrere Mandanten, Benutzer, Stakeholder, Dienstinstanzen, Anwendungen usw.) in einer verteilten Edge-Computing-Umgebung dynamisch zu unterstützen. Die folgende ausführliche Beschreibung bezieht sich auf die begleitenden Zeichnungen. Die gleichen Bezugsziffern können in unterschiedlichen Zeichnungen verwendet werden, um die gleichen oder ähnliche Elemente zu identifizieren. In der folgenden Beschreibung werden zum Zwecke der Erklärung und nicht Einschränkung spezifische Einzelheiten dargelegt, wie etwa spezielle Strukturen, Architekturen, Schnittstellen, Techniken usw., um ein umfassendes Verständnis der vorliegenden Offenbarung zu vermitteln. Für einen Fachmann mit Kenntnis der vorliegenden Offenbarung ist j edoch ersichtlich, dass die verschiedenen Aspekte der vorliegenden Offenbarung auf andere Arten und Weisen umgesetzt werden können, die von den hierin erörterten spezifischen Einzelheiten abweichen. In gewissen Fällen werden Beschreibungen allgemein bekannter Vorrichtungen, Schaltungen und Verfahren weggelassen, um die Beschreibung nicht mit unnötigen Einzelheiten zu verkomplizieren.
  • 1. MEHRFACHZUGANGSVERWALTUNGSDIENSTE (MAMS) UND GENERISCHER MEHRFACHZUGANG (GMA)
  • Heutzutage kann eine Vorrichtung (z. B. Mobilstationen, Benutzergeräte (UEs - User Equipment) usw.) basierend auf unterschiedlichen Technologieimplementierungen (einschließlich unterschiedlicher Funkzugangstechnologien (RATs - Radio Access Technologies) und Netzwerkarchitekturen gleichzeitig mit mehreren Kommunikationsnetzwerken verbunden werden. In solchen Multikonnektivitätsszenarien kann es wünschenswert sein, mehrere Zugangsnetzwerke zu kombinieren oder das beste auszuwählen, um Erfahrungsqualität (QoE) für einen Benutzer zu verbessern und die Gesamtnetzwerknutzung und -effizienz zu verbessern. Ein Zugangsnetzwerk ist das Segment in einem Netzwerk, das Benutzerdatenpakete über eine Zugangsverbindung, wie etwa eine WiFi-Luftverbindung, eine zellulare Luftverbindung oder DSL, an einen Client liefert. Durch intelligente Auswahl und Kombination der verwendeten Pfade für die Benutzerebene (UP - User Plane) können die von den Endbenutzern wahrgenommene Gesamt-QoE sowie die Nutzung der Ressourcen optimiert werden. Bei einer fortgeschrittenen Lösung können die Netzwerkpfade basierend auf der Kenntnis aktueller Bedingungen in den relevanten Zugangsnetzen dynamisch ausgewählt werden. Das MAMS-Framework (MAMS - Multiple Access Management Services) ermöglicht die intelligente Auswahl und flexible Kombination von Zugangs- und Kernnetzwerkpfaden basierend auf definierten Richtlinien. Durch die Verwendung aktueller Informationen aus verfügbaren Zugangsnetzwerken können die bestmögliche Netzwerkeffizienz und Endbenutzer-QoE-Wahrnehmung basierend auf Anwendungsbedürfnissen garantiert werden. Das MAMS-Framework kann verwendet werden, um flexibel die Kombination von Uplink-(UL-) und Downlink-(DL-)Zugangs- und - Kernnetzwerkpfaden mit einer optimalen Performance und einer UP-Behandlung zum Verbessern von Netzwerknutzung und -effizienz und verbesserter QoE für Benutzeranwendungen (Apps) auszuwählen. Mit dem MAMS-Framework können die optimalen Netzwerkpfade auf UP-Ebene ohne jegliche Auswirkung auf die Steuerebenensignalisierung der zugrundeliegenden Zugangsnetzwerke ausgewählt werden. Zusätzliche Aspekte des MAMS-Framework werden in Kanugovi et al., „Multi-Access Management Services (MAMS)“, Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (März 2020) („[RFC8743]“) erörtert, und ein beispielhaftes Mehrfachzugangs-(MA-)Netzwerk, welches das MAMS-Framework implementiert, ist durch die 1 und 2 dargestellt.
  • 1 stellt ein beispielhaftes Mehrfachzugangs-(„MX“- oder „MA“-)Netzwerk 100 dar, das MAMS-Technologie nutzt. Insbesondere zeigt 1B einen MAMS-e2e-UP-Protokollstapel im MX-Netzwerk 100, der sowohl WiFi als auch 3GPP-basierten Zugriff umfasst. In diesem Beispiel weist ein MX-Client 101 einen UP-Protokollstapel 102 auf, und ein Server 140 weist einen UP-Protokollstapel 142 auf.
  • Der MX-Client 101 ist eine Endbenutzervorrichtung, die Verbindungen mit einem oder mehreren Zugangsknoten unterstützt, möglicherweise über verschiedene Zugangstechnologien (oder RATs), und wird auch als eine Benutzerstation, eine Benutzervorrichtung, ein Benutzergerät (UE) oder ein Mehrfunk-UE 101 bezeichnet. Der Client 101 kann ein Multikonnektivitätsclient 101 sein, der mehrere Netzwerkverbindungen aufweist oder unterstützt.
  • Der MX-Server 140 (bzw. MAMS-Server 140) stellt MAMS-bezogene Benutzerebenen-(UP-)Funktionalitäten und/oder -Optimierungen im Netzwerk 100 bereit. Der MX-Server 140 behandelt Aggregation mehrerer Netzwerkpfade 105, 106, 107 und/oder das Weiterleiten von Benutzerdatenverkehr über mehrere Netzwerkpfade 105, 106, 107 hinweg. Der MX-Server 140 kann auch als MX-Gateway und/oder Netzwerk-Mehrfachzugangsdatenproxy (N-MADP - Network Multi Access Data Proxy) bezeichnet werden (siehe z. B. N-MADP 237 in 2). In der gesamten vorliegenden Offenbarung kann der MX-Server 140 als Server 140, MAMS-Server 140, MA-Server 140, Edge-Knoten 140, MEC-HOST 140, MAMS-MEC-System 140 oder dergleichen bezeichnet werden. Wenn der Client 101 Pakete an den Server 140 sendet, kann der Client 101 als „MAMS-Sender“, „MX-Sender“ oder dergleichen bezeichnet werden, und der Server 140 kann als „MAMS-Empfänger“, „MX-Empfanger“ oder dergleichen bezeichnet werden. Wenn der Client 101 Pakete vom Server 140 empfängt, kann der Client 101 als „MAMS-Empfänger“, „MX-Empfänger“ oder dergleichen bezeichnet werden, und der Server 140 kann als „MAMS-Sender“, „MX-Sender“ oder dergleichen bezeichnet werden.
  • Bei einigen Implementierungen läuft der MAMS-Server 140 in einem Edge-Computing-System/einer Edge-Computing-Plattform/einem Edge-Computing-Netzwerk (siehe z. B. 20-31) und/oder einem Cloud-Computing-System/einem Cloud-Computing-Dienst/einer Cloud-Computing-Plattform und kann Verkehr zwischen dem Client-Server über mehrere Verbindungen oder Pfade liefern. Bei einer beispielhaften Implementierung umfassen die Edge-Rechenknoten einen MEC-Host (oder MEC-Server). Zusätzlich oder alternativ dazu kann es sich beim MX-Server 140 um eine oder mehrere MEC-Anwendungen (Apps) handeln, die vom MEC-Server/Host betrieben werden (siehe z. B. 27-28). Verschiedene Aspekte von MEC-Hosts und MAMS-Servern werden im Folgenden ausführlicher erörtert.
  • Das MX-UE 101 (oder „Multifunk-UE 101“) greift über ein oder mehrere (Funk-)Zugangsnetze („(R)ANs“) 110 und den Server 140 auf ein Datennetzwerk (DN) 175 oder einen lokalen Dienst 170 (auch als lokales DN 170 bezeichnet) zu oder kommuniziert anderweitig mit diesem. Jedes (R)AN 110 ist ein Segment in einem Netzwerk, das Benutzerdatenpakete, die eine drahtgebundene Verbindung (z. B. Ethernet, DSL, Coax, USB und/oder dergleichen) oder eine drahtlose (Funk-)Verbindung (z. B. WiFi-Luftverbindung, 5G/NR-Luftverbindung, LTE-Luftverbindung und/oder dergleichen) sein kann, an den Client 101 und/oder Server 140 über Zugangsverbindung(en) 105 liefert. Jedes der (R)ANs 110 implementiert eine Zugangstechnologie („AT“), bei der es sich um den oder die zugrundeliegenden Mechanismus(en) handelt, der/die verwendet wird/werden, um auf ein entsprechendes Netzwerk zuzugreifen.
  • Bei einigen Implementierungen ist die AT eine Technologie mit festem (drahtgebundenem) Zugang, wie etwa Ethernet, Technologien digitaler Teilnehmerleitungen (DSL oder xDSL); G.hn; Koaxialkabelzugang („Koax“), wie etwa MoCA (Multimedia over Coax Alliance), DOCSIS (Data Over Cable Service Interface Specification), und/oder dergleichen; Powerline-Kommunikation („PLC“ oder „Powerline“) wie High-Definition-(HD-)PLC und/oder dergleichen; FTTX (Fiber to the x; auch als „Fiber in the Loop“ bezeichnet); ein passives optisches Netzwerk (PON); und/oder dergleichen. Hierbei kann (R)AN Knoten 111 ein Breitbandmodem (z. B. ein Kabelmodem, ein DSL-Modem, ein optisches Netzwerkendgerät (ONT - Optical Network Terminal) oder eine optische Netzwerkeinheit (ONU - Optical Network Unit), eine G.HN-Halbleitervorrichtung usw.) sein, das in Kombination mit Teilnehmerendgeräten (z. B. Heim-/Unternehmens-Router(n), Residential-/Unternehmens-Gateway(s), Mesh-Netzwerkvorrichtung(en), WiFi-Zugangspunkt(en) usw.) verwendet werden kann. Der feste AN-Knoten 111 verbindet den Client 101 mit dem Zugangsnetzwerk 110 über eine Zugangsverbindung 105, die gemäß einem Zugangsprotokoll (z. B. Ethernet, V.35, USB (Universal Serial Bus) und/oder Ethernet über USB, PPPoE (Point-to-Point Protocol over Ethernet), IPoE (Internet Protocol over Ethernet), G.hn, DOCSIS und/oder dergleichen) funktioniert. Hierbei kann die Zugangsverbindung 105 einen oder mehrere Drähte (z. B. Telefonverdrahtung, Koax, Stromleitungen, Kunststoff- und/oder Glasfasern und/oder dergleichen) umfassen, und die spezifischen verwendeten Drähte können von der zugrundeliegenden AT und/oder der zugrundeliegenden Infrastruktur abhängen.
  • Bei anderen Implementierungen kann die AT eine Funkzugangstechnologie (RAT) wie etwa 3GPP-Long Term Evolution (LTE), 3GPP-Fifth Generation (5G)/New Radio (NR), MulteFire, ETSI-Global System for Mobile Communications (GSM), WiFi®, WiMAX (Worldwide Interoperability for Microwave Access) (manchmal als „Drahtlosbreitband“ oder „WiBro“ bezeichnet) und/oder dergleichen sein. (R)ANs 110 könnten auch Technologien für persönliche Netzwerke wie etwa Bluetooth ® oder Bluetooth Low Energy (BLE), IEEE 802.15.4-basierte Protokolle (z. B. 6LoWPAN, WirelessHART, MiWi, Thread usw.), WiFi-direct und/oder dergleichen umfassen. Jedes (R)AN 110 umfasst einen oder mehrere (R)AN-Knoten 111, die Makrozellenbasisstationen, Remote Radio Heads (RRHs), Klein- und/oder Mikrozellenbasisstationen, Zugangspunkte (APs), Heim-Gateways (HGs) und/oder andere ähnliche Netzwerkelemente sein können. Eine Sammlung von (R)AN-Knoten 111 kann auch als ein „Zugangsebenen-Edge-Netzwerk“ oder „Zugangsebenen-Edge“ bezeichnet werden. Die (R)AN-Knoten 111 sind konfigurierbar oder betreibbar, um ein Setup von Transportressourcen (z. B. für CDN-Dienste und/oder andere Dienste der Anwendungsebene) sowie Planungssignalisierungsressourcen zum Bereitstellen eines Netzwerkdienstes des zugrundeliegenden Zugangsnetzwerks/der zugrundeliegenden RAT durchzuführen. Hierbei kann die Zugangsverbindung 105 Drahtlos- oder Luftschnittstellen basierend auf der zugrundeliegenden RAT (z. B. Uu-Schnittstelle für LTE- oder 5G/NR-RATs, PC5-Schnittstelle für LTE- oder 5G/NR-RATs, WiFi-Luftschnittstelle für WLAN-RATs, Millimeterwellen-(mmWave-)Schnittstelle, VLC-Schnittstelle (VLC - Visible Light Communication) und/oder dergleichen) umfassen.
  • Jedes (R)AN 110 a, 110 b umfasst einen oder mehrere jeweilige Netzwerkzugangsknoten (NANs) 111 a, 111 b, der/die kommunikativ mit einem jeweiligen Backend-Netzwerk gekoppelt ist/sind. Eine Möglichkeit, dieses Dienstmodell zu implementieren, besteht darin, eine Mehrwege-(Transport-)Schicht-4-Lösung wie etwa Multi-Path TCP (siehe z. B. IETF RFC 6824 (Januar 2013) („[rfc6824]“)) oder MultiPath QUIC (MPQUIC) (siehe z. B. De Coninck et al., „Multipath Extensions for QUIC (MP-QUIC)“,draft-deconinquic-multipath-07, IETA, QUIC Working Group (3. Mai 2021) („[MPQUIC]“)) zu verwenden. Solch eine Lösung ist in der Regel OS-abhängig und nur anwendungs-/verkehrsspezifisch anwendbar. Zudem arbeitet sie auf der individuellen Flussebene und leidet unter hoher Komplexität und geringer Effizienz. Kürzlich wurde eine neue Schicht-3-Lösung (siehe z. B. Zhu et al., „User-Plane Protocols for Multiple Access Management Service“, draft-zhu-intarea-mams-benutzerprotokoll-09, IETA, INTAREA (04-Mar-2020) („[UPMAMS]“)) vorgeschlagen, um Mehrwegemanagement ohne solche Einschränkungen und Nachteile zu unterstützen. Bei dieser Implementierung werden die zusätzlichen Steuerinformationen für das Mehrwegemanagement (z. B. Folgenummer usw.) als ein Anhänger am Ende des IP-Pakets angehängt.
  • Im Beispiel von 1 ist das (R)AN 110A ein 3GPP-basiertes Zugangsnetzwerk, wie etwa ein LTE-E-UTRAN, wobei der eine oder die mehreren (R)AN-Knoten 111A Evolved NodeBs (eNBs) sind, oder ein RAN der nächsten Generation (NG-RAN), wobei der eine oder die mehreren (R)AN Knoten 111 Next Generation NodeBs (gNBs) und/oder NG-Evolved-Node-Bs (NG-eNBs) sind. Zusätzlich dazu ist im Beispiel von 1 das (R)AN 110A ein WiFi-basiertes Zugangsnetzwerk, wobei die (R)AN-Knoten 111-B WiFi-Zugangspunkte (APs) sind. Die APs können zum Beispiel drahtlose Router, Straßenrand-ITS-Stationen oder Straßenrandeinheiten, Gateway-Geräte, zentrale Hubs oder dergleichen sein. Das Multifunk-UE 101 ist in der Lage, eine 3GPP-Zugangsverbindung 105A mit dem eNB/gNB 111A (z. B. Uu-Schnittstelle oder dergleichen) herzustellen, und in der Lage, eine WiFi-Zugangsverbindung 105B mit dem AP 111B herzustellen. Der eNB/gNB 111A kommuniziert mit dem Server 140 über eine 3GPP-Backhaul-Verbindung 106A, und der AP 111B kommuniziert mit dem Server 140 über eine WiFi-Backhaul-Verbindung 106B. Die 3GPP-Backhaul-Verbindung 106 A und die WiFi-Backhaul-Verbindung 106 B können eine geeignete drahtgebundene Verbindung sein, wie etwa Ethernet, USB, Data Highway Plus (DH+), PROFINET oder dergleichen. Außerdem ist der MX-Server 140 auch mit einem Kernnetzwerk 150A über die Backhaul-Schnittstelle 107A kommunikativ gekoppelt und mit einem Fixed-Access-(FA-)Gateway (GW) und/oder einem FA-Core-Netzwerk 150B über die Backhaul-Verbindung 107B kommunikativ gekoppelt. In diesem Beispiel kann das Kernnetzwerk 150A ein 3GPP-Kernnetzwerk sein, wie etwa ein 5G-Kernnetzwerk (5GC) oder ein LTE-Evolved Packet Core (EPC). Zusätzlich oder alternativ dazu kann das FA-GW ein Breitbandnetzwerk-Gateway (BNG) sein, und/oder der FA-Core kann ein Breitbandkern sein, der Transport bereitstellt, und verschiedene Ressourcen stellen Inhalt bereit (Anbieter-Rechenzentrum, Videokopfende usw.). Zusätzlich oder alternativ dazu kann das FA-GW/der FA-Core ein Residential Gateway (RG), ein 5G-RG, ein Fixed-Network(FN-)RG (FN-RG), ein FN Broadband RG (FN-BRG), ein FN Cable RG (FN-CRG), ein Wireline 5G Access Network (W-5GAN), ein Wireline 5G Cable Access Network (W-5GCAN), eine Wireline Access Gateway Function (W-AGF) und/oder ein anderes geeignetes Element/eine andere geeignete Entität sein.
  • Für Zwecke der vorliegenden Offenbarung können einzelne Verbindungen 105, 106 oder 107 als Zugangsnetzwerkverbindungen (ANCs) oder Zugangsnetzwerkpfade (ANPs) bezeichnet werden. Beispielsweise kann eine ANC oder ein ANP eine Funkverbindung 105 zwischen dem Client 101 und dem (R)AN-Knoten 111 in einer oder beiden Richtungen umfassen. Zusätzlich oder alternativ dazu kann eine ANC oder ein ANP sich auf eine Kombination einer Verbindung 105 und einer Verbindung 106 zwischen dem Client 101 und dem MX-Server 140 in einer oder beiden Richtungen beziehen. Zusätzlich oder alternativ dazu kann eine ANC oder ein ANP sich auf eine Kombination von Verbindungen/Pfaden 105, 106 und 107 zwischen dem Client 101 und dem lokalen Dienst 170 oder dem Datennetzwerk 175 in einer oder beiden Richtungen beziehen. Sofern nicht anders angegeben ist, können die Begriffe ANC, ANP, „Link“, „Kanal“, „Pfad“, „Verbindung“ und dergleichen in der gesamten vorliegenden Offenbarung austauschbar verwendet werden.
  • Zusätzlich dazu ist der Client 101 dazu konfiguriert, Funkinformationen für einen oder mehrere NANs 111 und/oder ein/e oder mehrere andere Entitäten/Elemente (z. B. Edge-Server, RAN(s) 110, Kernnetzwerkfunktion(en) (NF(s)), Anwendungsfunktion(en) (AF(s)), App-Server, Cloud-Dienst(e) und/oder dergleichen) bereitzustellen. Die Funkinformationen können in Form eines oder mehrerer Messberichte vorliegen und/oder zum Beispiel Signalstärkemessungen, Signalqualitätsmessungen und/oder dergleichen umfassen. Jeder Messbericht wird mit einem Zeitstempel und dem Ort der Messung (z. B. dem aktuellen Standort des Clients 101) markiert. Als Beispiele können die durch den Client 101 gesammelten und/oder in den Messberichten enthaltenen Messungen eines oder mehrere von Folgenden umfassen: Bandbreite (BW), Netzwerk- oder Zelllast, Latenz, Jitter, Umlaufzeit (RTT), Anzahl von Unterbrechungen, reihenfolgeveränderte Lieferung von Datenpaketen, Sendeleistung, Bitfehlerrate, Bitfehlerverhältnis (BER), Blockfehlerrate (BLER), Paketverlustrate, Paketempfangsrate (PRR), e2e-Verzögerung, Signal-Rausch-Verhältnis (SNR), Signal-Rausch-und-Störung-Verhältnis (SINR), Signal-plus-Rausch-plus-Verzerrung-zu-Rausch-plus-Verzerrung-Verhältnis (SINAD-Verhältnis), Träger-zu-Störung-plus-Rausch-Verhältnis (CINR), additives weißes Gaußsches Rauschen (AWGN), Energie-pro-Bit-zu-Rauschleistungsdichte-Verhältnis (Eb/No), Energie-pro-Bit-Störleistungsdichte-Verhältnis (Ec/I0), Spitzen-zu-Durchschnittsleistungs-Verhältnis (PAPR), Referenzsignalempfangsleistung (RSRP), Empfangssignalstärkeindikator (RSSI), Referenzsignalempfangsqualität (RSRQ), GNSS-Timing von Zellenrahmen zur UE-Positionsbestimmung für E-UTRAN oder 5G/NR (z. B. ein Timing zwischen einer AP- oder RAN-Knoten-Referenzzeit und einer GNSS-spezifischen Referenzzeit für ein gegebenes GNSS), GNSS-Codemessungen (z. B. die GNSS-Codephase (ganze Zahlen und Kommastellen) des Spreizcodes des i-ten GNSS-Satellitensignals), GNSS-Trägerphasenmessungen (z. B. die Anzahl von Trägerphasenzyklen (ganze Zahlen und Kommastellen) des i-ten GNSS-Satellitensignals, gemessen seit dem Einrasten auf das Signal; auch als Accumulated Delta Range (ADR) bezeichnet), Kanalstörungsmessung, Wärmerauschleistungsmessung, Empfangsstörleistungsmessung und/oder andere ähnliche Messungen. Die RSRP-, RSSI- und/oder RSRQ-Messungen können RSRP-, RSSI- und/oder RSRQ-Messungen zellspezifischer Referenzsignale, Kanalzustandsinformationsreferenzsignale (CSI-RS) und/oder Synchronisationssignale (SS) oder SS-Blöcke für 3GPP-Netzwerke (z. B. LTE oder 5G/NR) und RSRP-, RSSI- und/oder RSRQ-Messungen verschiedener Beacon-, Fast-Initial-Link-Setup-(FILS-)Erkennungsrahmen oder Sondierungsantwortrahmen für IEEE 802.11 WLAN/WiFi-Netze umfassen. Andere Messungen können zusätzlich oder alternativ verwendet werden, wie etwa jene, die in 3GPP TS 36.214 v16.2.0 (2021-03-31) („[TS36214]“), 3GPP TS 38.215 v16.4.0 (2020-12) („[TS38215]“), „IEEE 802.11-2020, IEEE Standard for Information Technology-Telecommunications and Information Exchange zwischen Systems - Local and Metropolitan Area Networks-Specific Requirements - Part 11:“ „Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications“ (2021-02-26) („[IEEE80211]“) und/oder dergleichen. Zusätzlich oder alternativ dazu kann jede der oben erwähnten Messungen (oder eine Kombination von Messungen) durch einen oder mehrere NANs 111 gesammelt werden.
  • Zusätzlich oder alternativ dazu kann jede der zuvor erwähnten Messungen (oder Kombination von Messungen) durch einen oder mehrere NANs 111 gesammelt und für eine geeignete Entität/Element (z. B. Edge-Server, (R)AN(s) 110, NF(s), AF(s), App-Server, Cloud-Dienst(e) und/oder dergleichen) bereitgestellt werden. Die Funkinformationen können in Abhängigkeit von einem Datentransfer, der stattfinden soll, und/oder anderen Informationen über den Datentransfer entweder mit einer niedrigen Periodizität oder einer hohen Periodizität gemeldet werden. Zusätzlich oder alternativ dazu kann das Element/die Entität die Messungen von den NANs 111 mit niedriger oder hoher Periodizität anfordern, oder die NANs 111 können die Messungen mit niedriger oder hoher Periodizität an das Element/die Entität liefern. Zusätzlich oder alternativ dazu kann das Element/die Entität andere relevante Daten (z. B. KPIs (Key Performance Indicators), KQIs (Key Quality Indicators) und/oder dergleichen) von anderen gleichen oder ähnlichen Elementen/Entitäten mit den Messberichten oder getrennt von den Messberichten erhalten.
  • MAMS ist ein programmierbares Framework, das Mechanismen für die flexible Auswahl von Netzwerkpfaden in einer MX-Kommunikationsumgebung 100 basierend auf den Anwendungsbedürfnissen und/oder -anforderungen bereitstellt und sich an dynamische Netzwerkbedingungen anpasst, wenn mehrere Netzwerkverbindungen eine Client-Vorrichtung 101 bedienen. Das MAMS-Framework nutzt Netzwerkintelligenz und -richtlinien, um die Verkehrsverteilung über ausgewählte Pfade und UP-Behandlungen (z. B. Verschlüsselung, die für den Transport über WiFi benötigt wird, oder Tunneln, das zum Überwinden einer Netzwerkadressübersetzung (NAT) zwischen dem Client 101 und einem Mehrwege-Proxy benötigt wird) dynamisch an sich ändernde Netzwerk-/Link-Bedingungen anzupassen. Netzwerkpfadauswahl- und -konfigurationsnachrichten werden als UP-Daten zwischen den Funktionselementen im MX-Netzwerk 100 B und dem Client 101 und somit mit geringem oder gar keinem Einfluss auf die Steuerebenen-(CP-)Signalisierungsschemata der zugrundeliegenden Zugangsnetze (z. B. WiFi- und 3GPP-Zugangsnetze in 1A-1B) übertragen. Im MX-Netzwerk 100 B mit 3GPP- und WiFi-Technologien werden zum Beispiel bestehende LTE- und WiFi-Signalisierungsprozeduren verwendet, um die LTE- bzw. WiFi-Verbindungen aufzubauen, und MAMS-spezifische CP-Nachrichten werden als LTE- oder WiFi-UP-Daten übertragen. Das in diesem Dokument definierte MAMS-Framework stellt die Fähigkeit bereit, eine intelligente Auswahl einer flexiblen Kombination von Zugangspfaden und Kernnetzwerkspfaden zu treffen, sowie die UP-Behandlung auszuwählen, wenn der Verkehr über die ausgewählten Pfade verteilt wird. Somit ist es ein umfassendes programmierbares Framework, das Funktionen über die einfache gemeinsame Nutzung von Netzwerkrichtlinien hinaus bereitstellt, wie etwa jenen, die durch die Access Network Discovery and Selection Function (ANDSF) bereitgestellt werden, die in 3GPP TS 24.312 v15.0.0 (2018-06-21) („[TS24312]“) erörtert wird und Richtlinien und Regeln zum Unterstützen von 3GPP-Clients bei der Erkennung und Auswahl verfügbarer Zugangsnetzwerke bietet. Ferner ermöglicht es die Auswahl und Konfiguration einer UP-Behandlung für den Verkehr über die Pfade in Abhängigkeit von den Erfordernissen der Anwendung.
  • Die MAMS-Framework-Mechanismen sind von keinen spezifischen Zugangsnetzwerktypen oder UP-Protokollen abhängig (z. B. TCP, UDP, Generic Routing Encapsulation (GRE), QUIC, Multipath TCP (MPTCP), SCTP, MultiPath QUIC (MPQUIC) usw.). Das MAMS-Framework koexistiert mit den bestehenden Protokollen und ergänzt diese, indem es eine Möglichkeit bereitstellt, diese Protokolle auszuhandeln und zu konfigurieren, um ihre Verwendung basierend auf Client- und Netzwerkfähigkeiten und den spezifischen Bedürfnissen jedes Zugangsnetzwerkpfads einem gegebenen MA-Szenario anzupassen. Ferner ermöglicht das MAMS-Framework Lastausgleich der Verkehrsflüsse über die ausgewählten Zugangsnetzwerkpfade und den Austausch von Netzwerkzustandsinformationen, die für Netzwerkintelligenz verwendet werden sollen, um die Performance solcher Protokolle zu optimieren.
  • Das MAMS-Framework basiert auf Prinzipien des UP-Interworking, das als Überlagerung bereitgestellt werden kann, ohne die darunterliegenden Netzwerke zu beeinflussen. MAMS koexistiert mit bestehenden Kommunikationsprotokollen und ergänzt diese, indem es eine Möglichkeit bereitgestellt, die Protokolle basierend auf Client- und Netzwerkfähigkeiten auszuhandeln und zu konfigurieren. Ferner ermöglicht es den Austausch von Netzwerkzustandsinformationen und die Nutzung der Netzwerkintelligenz, um die Performance solcher Kommunikationsprotokolle zu optimieren. MAMS weist eine minimale oder gar keine Abhängigkeit von der tatsächlichen Zugangstechnologie der beteiligten Verbindungen auf, was die Skalierbarkeit von MAMS zur Hinzufügung neuerer Zugangstechnologien und zur unabhängigen Entwicklung der bestehenden Zugangstechnologien ermöglicht.
  • 1 stellt auch einen MAMS-Datenebenen-Protokollstapel (DPPS) zum Transportieren von Benutzer-Nutzlasten, zum Beispiel einer IP-Protokolldateneinheit (PDU), die über die IP-Schicht übertragen wird, und/oder dergleichen dar. Der DPPS 102 und 142 weist den vom Client 101 implementierten clientseitigen MAMS-DPPS 102 und den vom Server 140 implementierten serverseitigen MAMS-DPPS 142 auf. Für Vorrichtungen, die mit mehreren Funkverbindungstechnologien (oder mehreren RAT-Schaltungsanordnungen) ausgestattet sind, wie etwa 5G/NR, LTE, WiFi usw., stellt MAMS [RFC8743] ein programmierbares Framework zum dynamischen Auswählen und gleichzeitigen Senden von Daten über mehrere Funkverbindungen für hohen Durchsatz, niedrige Latenz und verbesserte Zuverlässigkeit bereit. Der MAMS-DPPS 102, 142 umfasst die folgenden zwei (Teil-)Schichten: die Konvergenz-(Teil-)Schicht und die Anpassungs-(Teil-)Schicht. Die MX-Anpassungs-(Teil-)Schicht wird zu (oder auf) jeder RAT-Schaltungsanordnung hinzugefügt, und die MX-Konvergenz-(Teil-)Schicht verbindet die IP- und MX-Anpassungs-(Teil-)Schicht.
  • Die MX-Konvergenzschicht ist konfigurierbar und betreibbar, um MX-spezifische Aufgaben auf der UP durchzuführen. Die MX-Konvergenzschicht führt spezifische Mehrfachzugangsaufgaben/-funktionen durch, wie zum Beispiel Zugangs-(Pfad-)Auswahl, Multilink-(Pfad-)Aggregation, Aufteilen/Neuordnen, verlustloses Schalten, Keep-Alive, Sondierung, Fragmentierung und/oder Verkettung. Die MX-Konvergenzschicht kann durch Verwenden bestehender UP-Protokolle, wie etwa MPTCP, Multipath QUIC (MPQUIC), oder durch Anpassen von Header-/Trailer-Verkapselungsschemata, wie etwa GRE oder generischem Mehrfachzugang (GMA - Generic Multi-Access), implementiert sein. Bei einigen Implementierungen unterstützt die MX-Konvergenz GMA, MPTCP-Proxy, GRE-Aggregationsproxy und MPQUIC. Wie im Folgenden ausführlicher erörtert, kann das GMA-Protokoll verwendet werden, um zusätzliche Steuerinformationen (z. B. Schlüssel, Folgenummer, Zeitstempel usw.) auf dieser (Teil-)Schicht zu codieren.
  • Die MX-Anpassungsschicht ist konfigurierbar oder betreibbar zum Adressieren und/oder Handhaben von transportnetzwerkbezogenen Aspekten, wie beispielsweise Tunneln, Netzwerkschichterreichbarkeit und/oder -sicherheit und NAT. Die MX-Anpassungsschicht kann unter Verwendung bestehender Protokolle (z. B. TCP, UDP, IPSec, QUIC usw.) implementiert sein. Zusätzlich oder alternativ dazu kann die MX-Anpassungsschicht unter Verwendung von UDP-Tunneln, IPsec, DTLS (siehe z. B. Rescorla et al., „Datagram Transport Layer Security Version 1.2“, IETF, RFC 6347 (Januar 2012) und/oder Moriarty et al., „Deprecating TLS 1.0 und TLS 1.1“, IETF, RFC 8996 (März 2021) (zusammen „[DTLS]“) oder eine Client-NAT (z. B. eine Quell-NAT am Client mit umgekehrter Abbildung am Server 140 und/oder dem Network Multi-Access Data Proxy (N-MADP) 237 von 2) implementiert sein. Zusätzlich oder alternativ dazu ist das Anpassungsverfahren der MX-Anpassungsschicht UDP ohne DTLS, UDP mit DTLS, IPsec (siehe z. B. Huttunen et al., „UDP Encapsulation of IPsec ESP-PACKETS“, IETF, Network Working Group, RFC 3948 (Januar 2005) („[RFC3948]“)) oder Client-NAT.
  • Die MX-Anpassungsschicht kann unabhängig für jede der Zugangsverbindungen 105A und 105B konfiguriert sein. Insbesondere können UP-Pakete der Ankerverbindung in einem UDP-Tunnel einer Zustellverbindung zwischen dem N-MADP und C-MADP verkapselt werden (siehe z. B. N-MADP 237 und C-MADP 207 in 2), ein IPsec-Tunnel kann zwischen dem N-MADP und C-MADP (siehe z. B. N-MADP 237 und C-MADP 207 in 2) auf dem Netzwerkpfad aufgebaut werden, der als nicht vertrauenswürdig angesehen wird, und/oder es kann DTLS verwendet werden, wenn UDP-Tunneln auf dem Netzwerkpfad verwendet wird, der als „nicht vertrauenswürdig“ angesehen wird. Zum Beispiel kann in 1, die das 3GPP-(R)AN 110A (als sicher angenommen) und das WiFi-(R)AN 110B (als nicht sicher angenommen) umfasst, die MX-Anpassungsschicht für die 3GPP-Verbindung 105A weggelassen werden, ist aber mit IPsec konfiguriert, um die WiFi-Verbindung 105B zu sichern.
  • Die MX-Konvergenzschicht arbeitet auf der MX-Anpassungsteilschicht im Protokollstapel. Aus Sicht des Senders (Tx) wird eine Benutzer-Nutzlast (z. B. IP-PDU) zuerst von der MX-Konvergenzschicht und dann von der MX-Anpassungsschicht verarbeitet, bevor sie über eine Zustellzugangsverbindung transportiert wird. Aus Sicht des Empfängers (Rx) wird ein über eine Zustellverbindung empfangenes IP-Paket zuerst von der MX-Anpassungsunterschicht und dann von der MX-Konvergenzunterschicht verarbeitet.
  • Wenn GMA verwendet wird, kann die MX-Konvergenzschicht durch eine „GMA-Konvergenzschicht“ oder „GMA-Konvergenzteilschicht“ ersetzt werden. Hierbei sind mehrere Zugangsnetzwerke 110 zu einer einzigen IP-Verbindung zusammengefasst. Falls der NCM (siehe z. B. NCM 236 von 2) bestimmt, dass N-MADP (siehe z. B. N-MADP 237 von 2) mit GMA als dem MX-Konvergenzprotokoll instanziiert werden soll, tauscht er die Unterstützung der GMA-Konvergenzfähigkeit in den Erkennungs- und Fähigkeitsaustauschprozeduren aus.
  • Wenn MPTCP verwendet wird, kann die MX-Konvergenzschicht durch eine MPTCP-Schicht auf einzelnen TCP-Schichten ersetzt werden, wobei sich jede TCP-Schicht auf einer jeweiligen MX-Anpassungsschicht befindet. Hierbei wird MPTCP als das „MX Konvergenzteilschicht“-Protokoll wiederverwendet, und mehrere Zugangsnetzwerke werden zu einer einzigen MPTCP-Verbindung kombiniert. Somit wird in diesem Fall kein neues UP-Protokoll oder PDU-Format benötigt. Falls der NCM 236 bestimmt, dass der N-MADP mit MPTCP als dem MX-Konvergenzprotokoll instanziiert werden soll, tauscht er die Unterstützung der MPTCP-Fähigkeit während Erkennungs- und Fähigkeitsaustauschprozeduren aus. MPTCP-Proxyprotokolle können verwendet werden, um Verkehrslenkung und -aggregation über mehrere Zustellverbindungen zu verwalten.
  • Wenn GRE verwendet wird, kann die MX-Konvergenzschicht durch eine GRE-Schicht auf einer GRE-Delivery-Protocol-Schicht (z. B. IP) ersetzt werden. Hierbei wird GRE als das „MX-Konvergenzteilschicht“-Protokoll wiederverwendet, und mehrere Zugangsnetze werden zu einer einzigen GRE-Verbindung kombiniert. Somit wird in diesem Fall kein neues UP-Protokoll oder PDU-Format benötigt. Falls da NCM 236 bestimmt, dass der N-MADP mit GRE als dem MX-Konvergenzprotokoll instanziiert werden soll, tauscht er die Unterstützung der GRE-Fähigkeit in den Erkennungs- und Fähigkeitsaustauschprozeduren aus.
  • Das MAMS-Framework kann durch ein Edge-Computing-System/-Netzwerk, wie etwa ETSI Multi-access Edge Computing (MEC) (siehe z. B. 27-28) unterstützt werden, das die technischen Anforderungen für die Implementierung von MEC-Plattformen definiert. MEC ist eine Technologie, die es ermöglicht, dass Anwendungen an der Edge eines Zugangsnetzwerks instanziiert werden, und eine niedrige Latenz und eine Nahbereichsumgebung für Benutzergeräte (UEs) bereitstellt. Infolgedessen ist zu erwarten, dass vertikale Industrien erheblich von der Bereitstellung von MEC-Infrastruktur zusammen mit dem Bereitstellung von (R)ANs 110 profitieren. Diese RANs 110 können von verschiedenen Mobilfunknetzwerkbetreiber (MNOs) betrieben werden und/oder verschiedene RATs betreiben. MEC-Systeme sind zugangsunabhängig und können somit MAMS unterstützen. Bei einigen Implementierungen kann MAMS ein MEC-Dienst sein, der MEC-Anwendungen über die Mp1-Schnittstelle Dienste bereitstellt. Währenddessen kann die MEC-Plattform Dienste konsumieren, die durch NFs in einem 3GPP-Netzwerk über eine NEF oder eine PCF bereitgestellt werden, falls sich die AF in der vertrauenswürdigen Domäne befindet. Darüber hinaus wurde die 3GPP-5G-Systemarchitektur erweitert, um eine Funktionalität ähnlich dem MAMS zu unterstützen, die als ATSSS bezeichnet wird,.
  • 2 veranschaulicht eine beispielhafte MAMS-Referenzarchitektur 200 für ein Szenario eines Clients, der von n Netzwerken bedient wird (wobei n eine Zahl ist). Das MAMS-Framework ermöglicht dynamische Auswahl und flexible Kombination von Zugangs- und Kernnetzwerkpfaden als UL und DL für eine Vorrichtung, die mit mehreren Kommunikationsnetzwerken verbunden ist. Die mehreren Kommunikationsnetzwerke arbeiten auf der UP zusammen. Die Architektur ist erweiterbar, um eine beliebige Anzahl von Netzwerken sowie eine beliebige Auswahl von teilnehmenden Netzwerk-/Zugangstypen (z. B. LTE, WLAN, MuLTEfire, DSL, 5G/NR usw.) und Bereitstellungsarchitekturen (z. B. mit UP-Gateway-Funktion an der Zugangs-Edge und/oder dergleichen) zu kombinieren.
  • 2 veranschaulicht ein Szenario eines Clients 201, der von mehreren (1 bis n) Kernnetzen 241-1 bis 241-n bedient wird (wobei n eine Zahl ist). Die MAMS-Architektur 200 umfasst folgende Funktionselemente: einen Client 201 mit einem Client-Verbindungsmanager (CCM) 206 und einem Client-Mehrfachzugangsdatenproxy (C-MADP) 207; mehrere (1 bis n) Zugangsnetzwerke (ANs) 231 (einschließlich AN 231-1 bis AN 231-n); ein MAMS-System 235, das einen Netzwerkverbindungsmanager (NCM) 236 und einen Netzwerk-Mehrfachzugangsdatenproxy (N-MADP) 237 umfasst; und die mehreren (1 bis n) Kernnetzwerke 241-1 bis 241-n. Der CCM 206 und der NCM 236 handhaben CP-Aspekte und der C-MADP 207 und der N-MADP 237 handhaben UP-Aspekte. Die Kernnetzwerke (oder einfach „Kerne“) 241-1 bis 241-n sind Elemente, die die Netzwerkadresse des Clients 201 (z. B. IP-Adresse oder dergleichen) verankern, die zur Kommunikation mit Anwendungen über das Netzwerk verwendet wird. Einer oder mehrere der Kerne 241-1 bis 241-n können Cloud-Computing-Dienst(en), 5G-Kernnetzwerk(en) (5GCs), LTE-Kernnetzwerk(en) (z. B. Evolved Packet Core (EPC)), einem DSL/FIXED-Kern, einem WLAN-Kern, einem Rechenzentrum bzw. Rechenzentren und/oder einem anderen ähnlichen Backend-System entsprechen.
  • Der Client 201 ist eine Endbenutzervorrichtung, die Verbindungen mit mehreren Zugangsnetzwerken 231-1 bis 231-n (die gleich oder ähnlich wie die (R)ANs 110 und/oder (R)AN-Knoten 111 in 1 sein können) möglicherweise über verschiedene Zugangstechnologien unterstützt. Wenn der Client 201 in der Lage ist, mehrere Netzwerkverbindungen zu handhaben, kann der Client 201 als „Multikonnektivitätsclient“ oder dergleichen bezeichnet werden. Der Client 201 kann derselbe wie der in 1 dargestellte Client 101 oder diesem ähnlich sein.
  • Die ANs 231 sind Netzwerkelemente im Netzwerk, die Benutzerdatenpakete über jeweilige Punkt-zu-Punkt-Zugangsverbindungen 211-1 bis 211-n, die zum Beispiel WiFi-Verbindungen, zellulare LTE-Verbindungen, zellulare 5G/NR-Verbindungen, DSL-(Festzugangs-)Verbindungen und/oder dergleichen umfassen können, an den Client 201 liefern. Bei einigen Implementierungen können die Punkt-zu-Punkt-Zugangsverbindungen 211-1 bis 211-n zusätzlich oder alternativ Funkverbindungen mit kurzer Reichweite umfassen, wie beispielsweise Bluetooth® oder BLE, IEEE 802.15.4 basierte Protokolle (z. B. 6LoWPAN, WirelessHART, MiWi, Thread usw.), WiFi-direct und/oder dergleichen. Die ANs 231 können den (R)ANs 110 und/oder (R)AN-Knoten 111 von 1 entsprechen.
  • Ein Servermanager (z. B. NCM 236) ist eine funktionale Entität in einem Netzwerk 202 (z. B. Netzwerkelement, Netzwerkgerät, Gateway, Edge-Knoten, Cloud-Knoten usw.), die Steuernachrichten von einem Client-Manager (z. B. CCM 206) verarbeitet und Mehrfachzugangsoperationen auf der Serverseite 202 konfiguriert. Zusätzlich oder alternativ dazu ist der NCM 236 ein Funktionselement im Netzwerk, das MAMS-Steuernachrichten vom Client 201 verarbeitet und die Verteilung von Datenpaketen über die verfügbaren Zugangs- und Kernnetzwerkpfade konfiguriert und die UP-Behandlung (z. B. Tunneln, Verschlüsseln usw.) der Verkehrsflüsse verwaltet. Zusätzlich oder alternativ dazu stellt der NCM 236 die Intelligenz im Netzwerk bereit, um Netzwerkpfade und UP-Protokolle basierend auf Client-Verhandlung zu konfigurieren. Der NCM 236 fungiert auch als ein gemeinsames MA-Gateway für Netzwerkrichtlinieneingabe und Schnittstelle zu Anwendungsplattformen. Eine oder mehrere NCM-236-Instanzen können an der Zugangs-Edge (z. B. in einem oder mehreren Zugangsnetzwerken 110, an individuellen Zugangsnetzwerkknoten 111 und/oder in einem oder mehreren Edge-Rechenknoten) und/oder Kernnetzwerk-Gateways gehostet werden.
  • Der NCM 236 konfiguriert die Netzwerk-(N-MADP 237-) und Client-(C-MADP 207-)UP-Funktionen, wie etwa Verhandeln mit dem Client 201 zur Verwendung verfügbarer AN-Pfade 221-1 bis 221-n, Protokolle und Regeln zum Verarbeiten des UP-Verkehrs sowie Verbindungsüberwachungsprozeduren. Die CP-Nachrichten zwischen dem NCM 236 und dem CCM 206 werden als Überlagerung auf der UP transportiert, ohne die darunterliegenden Zugangsnetzwerke zu beeinflussen. Der NCM 236 verarbeitet MAMS-CP-Nachrichten vom Client 201 und konfiguriert die Verteilung von Datenpaketen über die mehreren verfügbaren Zugangspfade 221-1 bis 221-n, Zustellpfade 222-1 bis 222-n und/oder Kernnetzwerkpfade 223-1 bis 223-n sowie die UP-Behandlung von Verkehrsflüssen. Die zwischen dem NCM 236 und dem CCM 206 ausgetauschten CP-Nachrichten werden als Überlagerung auf der UP transportiert, ohne die darunterliegenden Ans 231 zu beeinflussen.
  • Der CP-Pfad 224 kann einem beliebigen UP-Zugangspfad überlagert sein. Ein „Pfad“ kann ein Fluss (z. B. ein IP-Fluss, ein UDP-Fluss usw.) zwischen zwei Hosts sein. Ein IP-Fluss oder ein UDP-Fluss kann durch ein 4-Tupel (z. B. IP-Quelladresse, IP-Zieladresse, Quellport, Zielport) bezeichnet werden. Zusätzlich oder alternativ dazu wird WebSocket zum Transportieren von Verwaltungs- und Steuernachrichten zwischen dem NCM 236 und dem CCM 206 verwendet, wobei MX-Steuernachrichten über (oder verkapselt in) einen WebSocket übertragen werden und der WebSocket über (oder verkapselt in) TCP/TLS übertragen wird.
  • Ein Client-Manager (z. B. CCM 206) ist eine funktionale Entität in der Client-Vorrichtung 201 (z. B. Desktop, Workstation, Laptop, Smartphone, Smartgerät, IoT-Vorrichtung usw.), die Steuernachrichten mit einem Server-Manager (z. B. NCM 236) austauscht, um Mehrfachzugangsoperationen auf der Client-Seite 201 zu konfigurieren. Zusätzlich oder alternativ ist der CCM 206 eine funktionale Entität im Client 201, die MAMS-Signalisierungsnachrichten mit dem NCM 236 austauscht und die Netzwerkpfade am Client 201 für den Transport von Benutzerdaten konfiguriert.
  • Der CCM 206 ist ein Peer-Funktionselement im Client 201 zur Handhabung von MAMS-CP-Prozeduren. Der CCM 206 verwaltet mehrere Netzwerkverbindungen 221-1 bis 221-n am Client 201 und konfiguriert die mehreren Netzwerkpfade 221-1 bis 221-n am Client 201 zum Transport von Benutzerdaten. Der CCM 206 tauscht MAMS-Signalisierung mit dem NCM 236 aus, um Funktionen wie die Konfiguration des UL- und DL-Benutzernetzwerkpfads zum Transportieren von Benutzerdatenpaketen und die adaptive Auswahl des Netzwerkpfads durch den NCM 236 durch Melden der Ergebnisse der Verbindungssondierung zu unterstützen. Verbindungssondierung und -meldung können verwendet werden, um adaptive Netzwerkpfadauswahl durch den NCM 236 zu unterstützen. Auf dem DL für Benutzerdaten, die durch den Client 201 empfangen werden, konfiguriert der CCM 206 den C-MADP 207 so, dass ein Anwendungsdatenpaket, das über einen beliebigen der Zugänge empfangen wird, die geeignete Anwendung auf dem Client 201 erreicht. Auf dem UL für die Daten, die vom Client 201 gesendet werden, konfiguriert der CCM 206 den C-MADP 207 zum Bestimmen der besten für UL-Daten zu verwendenden Zugangslinks 221 basierend auf einer Kombination von lokaler Richtlinie und Netzwerkrichtlinie, die durch den NCM 236 über den Link 224 geliefert werden.
  • Der C-MADP 207 ist eine funktionale Entität im Client 201, die Nutzdatenverkehrsweiterleitung über mehrere Netzwerkpfade abwickelt. Der C-MADP 207 ist für MAMS-spezifische UP-Funktionalitäten im Client 201 verantwortlich, wie etwa Verkapselung, Fragmentierung, Verkettung, Neuordnung, Neuübertragungen usw. Der C-MADP 207 wird durch den CCM 206 basierend auf Signalisierungsaustausch mit dem NCM 236 und lokalen Richtlinien am Client 201 konfiguriert. Der CCM 206 konfiguriert die Auswahl von Zustellverbindungen 222-1 bis 222-n und die für UL-Benutzerdatenverkehr zu verwendenden UP-Protokolle basierend auf der Signalisierung, die mit dem NCM 236 ausgetauscht wird.
  • Der N-MADP 237 ist eine funktionale Entität im Netzwerk 202, die die Weiterleitung von Nutzdatenverkehr über mehrere Netzwerkpfade abwickelt. Der N-MADP 237 ist für MAMS-bezogene UP-Funktionalitäten im Netzwerk 202 zuständig. Wie etwa Verkapselung, Fragmentierung, Verkettung, Neuordnung, Neuübertragung usw. Der N-MADP 237 ist der Verteilungsknoten, der den UL-UP-Verkehr zur geeigneten Ankerverbindung 223-1 bis 223-n zu einem jeweiligen Kernnetzwerk 241-1 bis 241-n und den DL-Benutzerverkehr über die geeignete(n) Zustellverbindung(en) 222-1 bis 222-n zum Client 201 leitet. Die Ankerverbindungen 223-1 bis 223-n sind Netzwerkpfade vom N-MADP 237 zum UP-Gateway (IP-Anker), das dem Client 201 eine Netzwerkadresse zugewiesen hat, und die Zustellverbindungen 222-1 bis 222-n sind Netzwerkpfade vom N-MADP 237 zum Client 201. Eine oder mehrere der N-MADP-237-Instanzen können an der Zugangs-Edge (z. B. in einem oder mehreren Zugangsnetzen 110 und/oder an individuellen Zugangsnetzwerkknoten 111) und/oder Kern-Gateways gehostet werden. Die N-MADP-237-Instanzen können mit oder getrennt von den NCM-236-Instanzen gehostet werden.
  • Auf dem DL konfiguriert der NCM 236 die Verwendung von Zustellverbindungen 222-1 bis 222-n und UP-Protokollen am N-MADP 237 zum Transportieren von Nutzdatenverkehr. Der N-MADP 237 kann Unterstützung für ECMP-Routing (ECMP - Equal-Cost Multipath) für den Downlink-Verkehr implementieren. Zusätzlich oder alternativ dazu kann der N-MADP 237 mit einem Router oder einem anderen ähnlichen Netzwerkelement (z. B. AP XE136 von Figur XE1) mit ECMP-Funktionalität verbunden sein. Der NCM 236 konfiguriert den N-MADP 237 mit einem Lastausgleichsalgorithmus basierend auf statischen und/oder dynamischen Netzwerkrichtlinien. Diese Netzwerkrichtlinien können Zuweisen von Zugangs- und Kernpfaden für spezifischen Benutzerdatenverkehrstyp, datenvolumenbasierte prozentuale Verteilung, Linkverfügbarkeit und Rückmeldeinformationen vom Austausch von MAMS-Signalisierung mit dem CCM 206 am Client 201 und/oder dergleichen umfassen. Der N-MADP 237 kann mit geeigneten UP-Protokollen konfiguriert sein, um sowohl eine Pro-Fluss- als auch eine Pro-Paket-Verkehrsverteilung über die Zustellverbindungen zu unterstützen.
  • Auf dem UL wählt der N-MADP 237 die geeignete Ankerverbindung 223-1 bis 223-n aus, über die der Benutzerdatenverkehr weiterzuleiten ist, der vom Client 201 über eine oder mehrere Zustellverbindungen 222-1 bis 222-n empfangen wird. Die Weiterleitungsregeln auf dem UL am N-MADP 237 werden vom NCM 236 basierend auf Anwendungsanforderungen (z. B. von einem Unternehmen gehostete Anwendungsflüsse über einen LAN- oder WLAN-Anker 241 (z. B. WiFi-, Cloud- und/oder Edge-Netzwerk), von einem Mobilbetreiber gehostete Anwendungen über ein zellulares Kernnetzwerk 241 und/oder dergleichen) konfiguriert.
  • Der NCM 236 und der N-MADP 237 können entweder ortsgleich miteinander angeordnet oder auf verschiedenen Netzknoten instanziiert sein. Der NCM 236 kann mehrere N-MADP-237-Instanzen im Netzwerk einrichten. Der NCM 236 steuert die Auswahl einer einzelnen N-MADP-237-Instanz durch den Client und die Regeln zur Verteilung von Benutzerverkehr über die N-MADP-237-Instanzen. Auf diese Weise können verschiedene N-MADP-237-Instanzen verwendet werden, um verschiedene Sätze von Clients für Lastausgleich über Clients zu handhaben. Zusätzlich dazu können die verschiedenen N-MADP-237-Instanzen für verschiedene Adressbereitstellungstopologien (z. B. N-MADP 237, der am UP-Knoten am Zugangs-Edge oder im Kernnetzwerk gehostet wird, während der NCM 236 am Zugangs-Edge-Knoten gehostet wird) sowie Adresszugangsnetzwerktechnologiearchitektur verwendet werden. Zum Beispiel kann eine N-MADP-237-Instanz an einem CN-Knoten 241 verwendet werden, um Verkehrsverteilung über LTE- und DSL-Netzwerke zu verwalten, und eine andere N-MADP-237-Instanz an einem (R)AN-Knoten 231-1, 231-n kann verwendet werden, um Verkehrsverteilung über LTE- und WiFi-Verkehr zu verwalten. Außerdem kann ein einzelner Client 201 dazu konfiguriert sein, mehrere N-MADP-237-Instanzen zu verwenden, die zum Adressieren verschiedener Anwendungsanforderungen verwendet werden können. Beispielsweise können einzelne N-MADP-237-Instanzen verwendet werden, um TCP- und UDP-Transport-basierten Verkehr zu handhaben.
  • Der CCM 206 und der NCM 236 tauschen Signalisierungsnachrichten aus, um die UP-Funktionen, den C-MADP 207 und den N-MADP 237 am Client bzw. dem Netzwerk zu konfigurieren. Der CCM 206 kann die CCM-236-Berechtigungsnachweise (FQDN oder Netzwerkadresse) zum Senden der anfänglichen Erkennungsnachrichten erhalten. Als ein Beispiel kann der Client 201 die NCM-236-Berechtigungsnachweise unter Verwendung von Verfahren wie Bereitstellung, DNS-Abfrage erhalten. Sobald der Erkennungsprozess erfolgreich ist, kann der (anfängliche) NCM 236 zusätzliche NCM-236-Adressen zum Beispiel basierend auf MCC/MNC-Tupelinformationen, die in der MX-Erkennungsnachricht empfangen werden, zum Senden nachfolgender CP-Nachrichten aktualisieren und zuweisen.
  • Der CCM 206 erkennt und tauscht Fähigkeiten mit dem NCM 236 aus. Der NCM 236 stellt die Berechtigungsnachweise des N-MADP-237-Endpunkts bereit und handelt die Parameter für UP mit dem CCM 206 aus. Der CCM 206 konfiguriert den C-MADP 207, um den UP-Pfad (z. B. MPTCP/UDP-Proxyverbindung) mit dem N-MADP 237 basierend auf den Berechtigungsnachweisen (z. B. (MPTCP/UDP-)Proxy-Netzwerkadresse (z. B. IP-Adresse und - Port), Associated Core Network Path) und den mit dem NCM 236 ausgetauschten Parametern einzurichten. Ferner tauschen der NCM 236 und der CCM 206 Verbindungszustandsinformationen aus, um Verkehrslenkung und UP-Behandlung mit dynamischen Netzwerkbedingungen anzupassen. Die wichtigsten Prozeduren sind in den folgenden Unterabschnitten detailliert beschrieben.
  • Eine UDP-(oder QUIC-)Verbindung kann zwischen dem C-MADP 207 und dem N-MADP 237 konfiguriert sein, um Steuernachrichten auszutauschen. Die Steuernachrichten können zum Beispiel Keep-Alive, Sondierungsanforderung (REQ)/Bestätigung (ACK), Paketverlustmeldung (PLR), erste Folgenummer (FSN), codierte MX-SDU (CMS), Verkehrsaufteilungsaktualisierung (TSU), Verkehrsaufteilungs-ACK-(TSA-)-Nachrichten und/oder Pfadqualitätsschätzungsinformationen sein oder umfassen. Die N-MADP-237-Endpunkt-Netzwerkadresse (z. B. IP-Adresse oder dergleichen) und -Portnummer (z. B. UDP-Portnummer der UDP-Verbindung) werden verwendet, um MX-Steuerungs-PDUs zu identifizieren.
  • Die verschiedenen Elemente, die im Beispiel von 2 dargestellt sind, können unter Verwendung einer Vielfalt verschiedener physischer und/oder virtualisierter Komponenten implementiert sein. Zum Beispiel können die Elemente innerhalb des MAMS-Netzwerks 202 unter Verwendung einer oder mehrerer Komponenten eines Edge-Knotens, wie etwa eines oder mehrerer LTE- oder 5G-RANs, oder des MEC-Systems 2700 von 27 oder dergleichen implementiert sein. Zusätzlich oder alternativ dazu kann das MAMS-System 235 durch einen einzelnen RAN-Knoten, wie etwa einen oder mehrere der RAN-Knoten 111 in 1A-1C, oder darin implementiert sein. In einem Beispiel ist das MAMS-System 235 als Teil des Schicht-3-(L3-)Protokollstapels (z. B. der RRC-Schicht oder dergleichen) implementiert. Bei einem anderen Beispiel ist das MAMS-System 235 als Teil einer Schicht über L3 implementiert, wie etwa des Netzwerkschicht(z. B. IP, UDP, QUIC, GTP-U usw.)-Datenebenen-Protokollstapels der RAN-Knoten. In einem anderen Beispiel kann das MAMS-System 235 als eine separate Schicht zwischen der L3 und den oberen Schichten implementiert sein. Bei einem anderen Beispiel kann das MAMS-System 235 in einer oder durch eine gNB-CU einer geteilten CU/DU-Architektur implementiert sein. Bei einem anderen Beispiel kann das MAMS-System 235 in einem oder durch einen vBBU-Pool oder in einem oder durch ein Cloud-RAN (C-RAN) implementiert sein. Zusätzlich oder alternativ dazu können die Funktionselemente innerhalb des MAMS-Netzwerks 202 durch eine oder mehrere Netzwerkfunktionen (oder als eine VNF) von CN 150A in 1 implementiert sein. Zum Beispiel kann der N-MADP 237 auf einem S-GW oder P-GW ausgeführt werden, wenn CN 150A ein EPC ist, oder der N-MADP 237 kann auf einer Benutzerebenenfunktion (UPF - User Plane Function) ausgeführt werden, wenn CN 150A ein 5GC ist.
  • Bei MEC-basierten Implementierungen (siehe z. B. 27-28) kann das MAMS-System 235 in einem oder durch einen MEC-Host/Server (z. B. MEC-Host 2702 in 27) implementiert sein, der sich in einem RAN 110 oder RAN-Knoten 111 befindet oder ortsgleich damit angeordnet ist. Die Funktionen, die sich auf der Netzwerkseite befinden (z. B. NCM 236 und N-MADP 237), können entweder an einem zentralen Ort oder an der Edge-Cloud (siehe z. B. Edge-Cloud 3163 von 31) gehostet werden. Sie können entweder als MEC-Anwendung (z. B. MEC-App(s) 2726 von 27) oder zusammen mit anderen Funktionen (z. B. MEC-Plattform 2732 von 27) bereitgestellt werden. Zusätzlich oder alternativ dazu können aktuelle Informationen von den Zugangsnetzwerken für den NCM 236 zur intelligenten Netzwerkpfadauswahl über APIs durch die MEC-Plattform (z. B. MEC-Plattform 2732 von 27) auf die gleiche Weise bereitgestellt werden, wie sie RNI über eine RNI-API, TMS über eine TMS-API und/oder BWMS über eine BWM-API verfügbar macht. Zusätzlich oder alternativ dazu können ähnliche Informationsebenen für 3GPP-Zugangsnetzwerke sowie für WiFi, MulteFire, DSL usw. definiert werden, entweder durch Ändern der bestehenden RNI/BWM-APIs oder durch Definieren neuer APIs, die für die neuen Zugangstechnologien spezifisch sind.
  • Bei zusätzlichen oder alternativen MEC-basierten Implementierungen (siehe z. B. 27-28) kann das NCM 236 auf einem MEC-Cloud-Server (z. B. MEC-Host 2702 und/oder MEC-App(s) 2726 in 27) gehostet werden, der sich im UP-Pfad an der Edge des Mehrfachtechnologie-Zugangsnetzwerks befindet. Der NCM 236 und der CCM 206 können die Netzwerkpfadkombinationen basierend auf den Bedürfnissen einer Anwendung und den notwendigen UP-Protokollen aushandeln, die über die mehreren Pfade verwendet werden sollen. Die vom CCM 206 an den NCM 236 gemeldeten Netzwerkbedingungen können durch eine Funkanalyseanwendung (siehe z. B. [MEC012]) ergänzt werden, die sich am MEC-Cloud-Server befindet, um die UL- und DL-Zugangspfade gemäß sich ändernden Funk- und Überlastungsbedingungen zu konfigurieren. Zusätzlich oder alternativ dazu kann das UP-Funktionselement (z. B. der N-MADP 237) entweder zusammen mit dem NCM 236 am MEC-Cloud-Server (z. B. MEC-gehostete Anwendungen usw.) untergebracht sein oder an einem separaten Netzwerkelement wie einem gemeinsamen UP-Gateway über die mehreren Netzwerke angeordnet sein. Selbst in Szenarien, in denen kein N-MADP 237 bereitgestellt wird, kann der NCM 206 verwendet werden, um die Verkehrslenkentscheidungen am Client 201 zu erweitern. Diese Erweiterungen dienen zum Verbessern der QoE des Endbenutzers, indem der beste Netzwerkpfad basierend auf den Bedürfnissen und Netzwerkbedingungen einer Anwendung genutzt wird und auf den Vorteilen einer wesentlich reduzierten Latenz und der dynamischen Offenbarung von an der MEC verfügbaren Funknetzwerkinformationen in Echtzeit aufgebaut wird.
  • Wie hier verwendet, kann ein „GMA-Empfänger“ eine N-MADP-237-Instanz oder eine C-MADP-207-Instanz (siehe z. B. 2) sein, die mit GMA als dem Konvergenzprotokoll instanziiert ist und Pakete empfängt, die gemäß GMA-Prozeduren verkapselt oder anderweitig erzeugt sind, und die empfangenen Pakete gemäß den Prozeduren verarbeitet, die in Zhu et al., „Generic Multi-Access (GMA) Convergence Encapsulation Protocols“, draft-zhu-intarea-gma-10, IETA, INTAREA/Network Working Group (21. Juni 2021) („[GMA10]“) erörtert werden, das hiermit durch Bezugnahme in seiner Gesamtheit hierin aufgenommen wird. Außerdem kann, wie hier verwendet, ein „GMA-Sender“ eine N-MADP-237-Instanz oder eine C-MADP-207-Instanz sein, die mit GMA als dem Konvergenzprotokoll instanziiert ist und Pakete/PDUs gemäß in [GMA10] erörterten GMA-Prozeduren verarbeitet und/oder verkapselt oder anderweitig erzeugt.
  • Wie bereits erwähnt, ist MAMS ein programmierbares Framework, das Mechanismen zur flexiblen Auswahl von Netzwerkpfaden in einer Mehrfachverbindungs-(zugangs-)Kommunikationsumgebung basierend auf Anwendungsbedürfnissen bereitstellt. Es nutzt Netzwerkintelligenz und -richtlinien, um Verkehrsverteilung über ausgewählte Pfade und Benutzerebenenbehandlung dynamisch an sich ändernde Netzwerk-/Verbindungsbedingungen anzupassen. Die Netzwerkpfadauswahl- und -konfigurationsnachrichten werden als Benutzerebenendaten zwischen den Funktionselementen im Netzwerk und der Endbenutzervorrichtung und somit ohne jegliche Auswirkung auf die Steuerebenen-Signalisierungsschemata des einzelnen Zugangsnetzwerks übertragen. Heutige MAMS-Lösungen erfordern die Bereitstellung von MAMS-Steuer- und -Datenebenen-Netzwerkfunktionen im Netzwerk [RFC8743]. Die vorliegende Offenbarung erweitert das MAMS-Framework, um OTT-MAMS (z. B. verlustloses Schalten, Aggregation usw.) ohne jegliche Änderung oder Abhängigkeit im Netzwerk zu unterstützen. Der OTT-MAMS kann als Teil eines MAMS ausgeführt werden, der auf einem Cloud-Computing-Dienst/einer Cloud-Computing-Plattform, einer Edge-Computing-Plattform/einem Edge-Computing-Dienst (z. B. ETSI-MEC und/oder dergleichen) und/oder unter Verwendung geeigneter virtueller Maschinen (VMs) und/oder Container gehostet wird, die durch solch einen Cloud-Computing-Dienst/solche eine Cloud-Computing-Plattform und/oder solche eine Edge-Computing-Plattform/solch einen Edge-Computing-Dienst bereitgestellt werden.
  • Außerdem wird klar, dass, wenn sich die Mobil- und/oder Drahtloszugangstechnologien und -netzwerke so weiterentwickeln, keine einzelne Funktechnologie alleine in der Lage sein wird, der Vielfalt von Anforderungen für Mensch- und Maschinenkommunikation gerecht zu werden. Andererseits wird das Treiben von mehr Daten durch ein knappes und endliches Funkspektrum zu einer echten Herausforderung, und die Spektrumeffizienz nähert sich einem Plateau und wird die erforderliche Zunahme der Bandbreitenverbesserung selbst nicht liefern. Zum Beispiel nutzt die zellulare 3GPP-5G-Technologie wahrscheinlich Frequenzen unter 6 Gigahertz (GHz) sowie Millimeterwellen („mmWave“ oder „MMW“) sowohl in lizenzierten als auch in unlizenzierten Bändern. Die vorliegende Offenbarung stellt außerdem eine Software-definierte, zugangsunabhängige High-Performance-Lösung für solche Probleme bereit, die hierin als generischer Mehrfachzugang (GMA - Generic Multi-Access) bezeichnet wird, um die Integration mehrerer (heterogener oder homogener) Funkzugangsnetzwerke und RATs an der Edge zu ermöglichen, ohne bestehende RAT-Protokollstapel (z. B. PDCP, RRC, Ethernet usw.) oder bestehende Netzwerkprotokolle (z. B. Internetprotokoll (IP), Transmission Control Protocol (TCP), User Data Gram Protocol (UDP), Quick UDP Internet Connections (QUIC) usw.) zu beeinflussen. GMA kann als Schicht-2,5-Protokoll angesehen werden. Die vorliegende Offenbarung beschreibt eine GMA-e2e-Netzwerkarchitektur und verschiedene Protokolle, Prozeduren, Algorithmen und Systemfunktionalitäten sowie Bereitstellungsimplementierungen.
  • 3 stellt einen beispielhaften MAMS-Steuerebenen-Protokollstapel (CPPS) 300 dar. Der CPPS 300 umfasst eine Mehrfachzugangs-(MX)-Steuernachrichtenschicht 303, eine WebSocket-Schicht und eine Transport-Control-Protocol-(TCP-)/Transport-Layer-Security-(TLS-)Schicht. Hierbei wird WebSocket (siehe z. B. IETF RFC 6455 (Dez. 2011) und IETF RFC 8441 (Sept. 2018))zum Transport von Verwaltungs- und Steuernachrichten (z. B. MX-Steuernachrichten 303) zwischen dem NCM 236 und dem CCM 206 verwendet. Jede MAMS-Steuernachricht 3003 kann eines oder mehrere der folgenden Felder enthalten: Version (gibt die Version des MAMS-Steuerprotokolls an); Nachrichtentyp (gibt den Typ der Nachricht an, z. B. MX Discover, MX-Fähigkeitsanforderung (REQ)/-antwort (RSP)); und Folgenummer (SN) (automatisch inkrementierte ganze Zahl zum eindeutigen Identifizieren eines bestimmten Nachrichtenaustauschs (z. B. MX-Fähigkeitsanforderung/-antwort).
  • 3 zeigt einen MAMS-Verwaltungsprotokollstapel 300m. Hierbei wird ein sicheres WebSocket über einen dritten Tunnels der Transportschicht (z. B. TCP, UDP, IP Security Protocol (IPSec) usw.) eingerichtet, der über eine virtuelle Netzwerkschicht-(Anker-)Verbindung (z. B. IP oder ein anderes geeignetes Netzwerkschichtprotokoll) zum Senden von MAMS-Verwaltungsnachrichten zwischen dem CCM 206 und dem NCM 236 aufgebaut wird. Die virtuelle (Anker-)Verbindung befindet sich auf einer Konvergenzschicht, die ein Konvergenzprotokoll (z. B. GMA oder dergleichen) implementiert, das die MAMS-Verwaltungsnachrichten in dem (den) virtuellen (Anker-)Verbindungspaket(en) (z. B. IP-Paketen) verkapselt. Die Konvergenz-(GMA-)Schicht befindet sich auf jeweiligen Transport-(z. B. UDP- oder IPSec-)Tunnelschichten für jeweilige Zugangsnetze (ANs) 1 und 2, die sich auf jeweiligen Netzwerkschichten (z. B. IP oder dergleichen) befinden, die sich auf Schicht 2 (L2) und Schicht 1 (L1) der jeweiligen Zugangsnetze/RATs 1 und 2 befinden.
  • Bei einigen Implementierungen kann der CCM 206, wenn die virtuelle Verbindung nicht aufgebaut wurde, das sichere WebSocket nur zuerst über eine der IP-Zustellverbindungen (z. B. RAT-1) einrichten. Nachdem die virtuelle IP-Verbindung hergestellt ist, schließt der CCM 206 sie und stellt eine neue über die virtuelle IP-(Anker-)Verbindung her, und die entsprechenden (virtuellen) IP-Pakete (die eine oder mehrere MAMS-Nachrichten mitführen) werden auf gleiche oder ähnliche Weise verkapselt wie Datenpakete (siehe z. B. 18).
  • 3 zeigt auch eine MAMS-Steuerebenen-(CP-)Prozedur 302 zur Pfadqualitätsschätzung. Pfadqualitätsabschätzungen können sowohl passiv als auch aktiv erfolgen. Verkehrsmessungen im Netzwerk können passiv durch Vergleichen des Echtzeitdatendurchsatzes des Clients 201 mit der im Netzwerk zur Verfügung stehenden Kapazität durchgeführt werden. Bei speziellen Bereitstellungen, bei denen der NCM 236 Schnittstellen 222 mit Zugangsknoten 231, 111 aufweist, können die direkten Schnittstellen verwendet werden, um Informationen bezüglich der Pfadqualität zu sammeln. Zum Beispiel könnte die Nutzung eines LTE-Zugangsknotens (eNB), an den der Client 201 angeschlossen ist, als Daten für die Schätzung der Pfadqualität verwendet werden, ohne zusätzlichen Verkehrsaufwand zu erzeugen. Aktive Messungen durch den Client 201 stellen eine alternative Möglichkeit zur Schätzung der Pfadqualität bereit.
  • Prozedur 302 beginnt bei Operation 302-1, wobei der NCM 236 eine MX-Pfadschätzungsanforderung an den CCM 206 sendet. Bei Operation 302-2 sendet der CCM 206 eine MX-Pfadschätzungsergebnisnachricht an den NCM 236. Der NCM 236 kann einen oder mehrere der folgenden Konfigurationsparameter in der MX-Pfadschätzungsanforderung (Operation 302-1) an den CCM 206 senden: Connection ID (Verbindungs-ID) (der Zustellverbindung 222, deren Pfadqualität geschätzt werden muss); Init Probe Test Duration (Initialisierungssondierungstestdauer) (ms); Init Probe Test Rate (Initialisierungssondierungstestrate) (Mbps); Init Probe Size (Initialisierungssondierungsgröße) (Byte); Init Probe-ACK Required (Initialisierungssondierungs-ACK erforderlich) (0 -> Nein / 1 - > Ja); Active Probe Frequency (Aktivsondierungsfrequenz) (ms); Active Probe Size (Aktivsondierungsgröße) (Byte) ; Active Probe Test Duration (Aktivsondierungstestdauer) (ms); Active Probe-ACK Required (Aktivsondierungs-ACK erforderlich) (0 -> Nein / 1 -> Ja).
  • Der CCM 226 konfiguriert den C-MADP 207 zum Sondierungsempfang basierend auf diesen Parametern und zum Sammeln der Statistiken der gemäß folgenden Konfiguration: Unique Session ID (Eindeutige Sitzungs-ID) (Sitzungskennung, die für den Client in einer MX-Fähigkeitsantwort bereitgestellt wird); Init Probe Results Configuration (Initialisierungssondierungsergebniskonfiguration) (z. B. einschließlich Lost Probes (verlorener Sondierungen) (Prozent) und/oder Probe Receiving Rate (Sondierungsempfangsrate) (Pakete pro Sekunde)); Active Probe Results Configuration (Aktivsondierungsergebniskonfiguration) (z. B. einschließlich des mittleren Durchsatzes in der letzten Sondierungsdauer).
  • Die UP-Sondierung gliedert sich in zwei Phasen: die Initialisierungsphase und die Aktivphase. Für die Initialisierungsphase gilt ein Netzwerkpfad, der vom N-MADP 237 nicht zur Übertragung von Benutzerdaten einbezogen wird, als in der Initialisierungsphase befindlich. Die Benutzerdaten können über andere verfügbare Netzwerkpfade übertragen werden. Für die Aktivphase gilt ein Netzwerkpfad, der vom N-MADP 237 zur Übertragung von Benutzerdaten einbezogen wird, als in der Aktivphase befindlich.
  • Während der Initialisierungsphase konfiguriert das NCM 236 den N-MADP 237 zum Senden einer Init-Probe-REQ-Nachricht. Der CCM 206 sammelt die Init-Probe-Statistiken vom C-MADP 207 und sendet die MX-Pfadschätzergebnisnachricht (Operation 302-2) an den NCM 236 gemäß der Initialization-Probe-Results-Konfiguration.
  • Während der Aktivphase konfiguriert der NCM 236 den N-MADP 237 zum Senden einer Active-Probe-REQ-Nachricht. Der C-MADP 207 berechnet die Metriken, wie durch die Active-Probe-Results-Konfiguration spezifiziert. Der CCM 206 sammelt die Aktive-Probe-Statistiken vom C-MADP 207 und sendet die MX-Pfadschätzergebnisnachricht gemäß der Active-Probe-Results-Konfiguration an den NCM 236 (Operation 302-2).
  • 3 zeigt auch ein MX-Steuernachrichtenformat 303. Wie dargestellt, weist die MX-Steuernachricht 303 einen IP-Header, einen UDP-Header und eine MX-Steuerungs-PDU-Nutzlast 313 auf. Die MX-Steuerung-PDU-Nutzlast 313 weist ein Typenfeld, ein CID-Feld und eine MX-Steuernachricht 310 auf. Die MX-Steuerungs-PDU 313 kann eines oder mehrere der folgenden Felder enthalten: Typ (1 Byte) zum Angeben des Typs der MX-Steuernachricht (ein Wert von „0“ zeigt einen Keep-Alive-Typ an, und ein Wert von „1“ zeigt einen Probe-REQ/ACK-Typ an; andere: reserviert); CID (1 Byte) zum Angeben einer Verbindungs-ID der Zustellverbindung zum Senden der MX-Steuernachricht 303; und eine MX-Steuernachricht 310 (variable Größe/Länge), welche die Nutzlast der MX-Steuernachricht 310 enthält. Die MX-Steuernachricht 303/PDU 310 wird als normales UP-Paket über die gewünschte Zustellverbindung gesendet, deren Qualität und Erreichbarkeit bestimmt werden muss.
  • Die Steuernachricht 303/PDU 310 kann als Keep-Alive- und/oder Probe-REQ/ACK-Nachrichten codiert sein, um eine Pfadqualitätsschätzung zu unterstützen. Das Feld „Typ“ wird für Keep-Alive-Nachrichten auf „0“ gesetzt. Der C-MADP 207 kann periodisch eine Keep-Alive-Nachricht über eine oder mehrere Zustellverbindungen 222-1 bis 222-n (z. B. ANCs 105, 106 und/oder 107) senden, insbesondere wenn UDP-Tunneln als das Anpassungsverfahren für die Zustellverbindung 222 mit NAT-Funktion auf dem Pfad verwendet wird. Eine Keep-Alive-Nachricht ist 2 Byte lang und enthält ein Keep-Alive-Folgenummernfeld (2 Byte) zur Angabe der Folgenummer (SN) der Keep-Alive-Nachricht. Das Feld „Typ“ wird für Probe-REQ/ACK-Nachrichten auf „1“ gesetzt. Der N-MADP 237 kann eine Sondierungsanforderungs-(Probe-REQ-)Nachricht zur Pfadqualitätsschätzung senden. Als Reaktion kann der C-MADP 207 eine Sondierungsbestätigungs-(Probe-ACK-)Nachricht zurücksenden.
  • Eine Probe-REQ-Nachricht kann eines oder mehrere der folgenden Felder enthalten: Probing Sequence Number (Sondierungsfolgenummer) (2 Bytes), um eine SN der Probe-REQ-Nachricht anzuzeigen; Probing Flag (Sondierungsflag) (1 Byte), wobei Bit 0 ein Probe-ACK-Flag ist, um anzuzeigen, ob die Probe-ACK-Nachricht erwartet wird (1) oder nicht (0), Bit 1 ein Probe-Type-Flag ist, um anzuzeigen, ob die Probe-REQ/ACK-Nachricht während der Initialisierungsphase (0), wenn der Netzwerkpfad nicht zur Übertragung von Benutzerdaten einbezogen wird, oder während der aktiven Phase (1), wenn der Netzwerkpfad zur Übertragung von Benutzerdaten einbezogen wird, gesendet wurde, Bit 2 ein Bit-Flag ist, um das Vorhandensein des Feldes „Reverse Connection ID“ (Rückwärtsverbindung-ID (R-CID) anzuzeigen, und die Bits 3 bis 7 reserviert sind; Reverse Connection ID (R-CID) (1 Byte), um die Verbindungs-ID der Zustellverbindung zum Senden der Probe-ACK-Nachricht auf dem Rückwärtspfad anzuzeigen; und Padding (Fülldaten) (Variable). Das Feld „Padding“ wird zum Steuern der Länge der Probe-REQ-Nachricht verwendet. Das Feld „R-CID“ ist nur dann vorhanden, wenn sowohl Bit 0 als auch Bit 2 des Feldes „Probing Flag“ auf 1 gesetzt sind. Darüber hinaus sollte Bit 2 des Feldes „Probing Flag“ auf „0“ gesetzt werden, falls Bit 0 „0“ ist, was angibt, dass die Probe-ACK-Nachricht nicht erwartet wird. Falls das Feld „R-CID“ nicht vorhanden ist, aber Bit 0 des Feldes „Probing Flag“ auf „1“ gesetzt ist, sollte die Probe-ACK-Nachricht über dieselbe Zustellverbindung wie die Probe-REQ-Nachricht gesendet werden.
  • Der C-MADP 207 sollte die Probe-ACK-Nachricht als Antwort auf eine Probe-REQ-Nachricht mit dem Probe-ACK-Flag auf „1“ gesetzt senden. Eine Probe-ACK-Nachricht ist 3 Byte lang und enthält ein Feld „Probing Acknowledgement Number“ (Sondierungsbestätigungsnummer) (2 Byte), um eine Folgenummer der entsprechenden Probe-REQ-Nachricht anzugeben/zu enthalten.
  • Der CCM 206 und der NCM 236 tauschen Signalisierungsnachrichten zum Konfigurieren der UP-Funktionen über den C-MADP 207 und den N-MADP 237 am Client bzw. dem Netzwerk aus. Die Mittel für den CCM 206 zum Erhalten der NCM-236-Berechtigungsnachweise (z. B. FQDN (Fully Qualified Domain Name) oder Netzwerkadresse (z. B. IP-Adresse oder dergleichen)) zum Senden der anfänglichen Erkennungsnachrichten liegen außerhalb des Umfangs für dieses Dokument. Als ein Beispiel kann der Client die NCM-236-Berechtigungsnachweise unter Verwendung von Verfahren wie Provisionieren oder DNS-Anfragen erhalten. Sobald der Erkennungsprozess erfolgreich ist, kann der (anfängliche) NCM 236 zusätzliche NCM-236-Adressen aktualisieren und zuweisen (z. B. basierend auf Mobil-Landeskennzahl-(MCC - Mobile Country Code-)/Mobilnetzwerkkennzahl-(MNC - Mobile Network Code-)Tupelinformationen, die in der MX-Erkennungsnachricht empfangen werden), um nachfolgende CP-Nachrichten zu senden.
  • Der CCM 206 erkennt und tauscht Fähigkeiten mit dem NCM 236 aus. Der NCM 236 stellt die Berechtigungsnachweise des N-MADP-237-Endpunkts bereit und handelt die Parameter für die Benutzerebene mit dem CCM aus. Der CCM 206 konfiguriert den C-MADP 207 zum Aufbauen des UP-Pfades (z. B. MPTCP/UDP-Proxy-Verbindung) mit dem N-MADP basierend auf den Berechtigungsnachweisen (z. B. (MPTCP /UDP-)Proxy-Netzwerkadresse (z. B. IP-Adresse oder dergleichen) und -Port, die mit dem Kernnetzwerkpfad assoziiert sind) und den mit dem NCM 236 ausgetauschten Parametern. Ferner tauschen der NCM 236 und der CCM 206 Verbindungszustandsinformationen aus, um Verkehrslenkung und UP-Behandlung an dynamische Netzwerkbedingungen anzupassen.
  • Nach dem Senden einer MAMS-Steuernachricht wartet der MAMS-CP-Peer (NCM 236 oder CCM 206) für eine Dauer von MAMS_TIMEOUT ms, bevor er in Fällen, in denen eine Antwort erwartet wurde, abläuft. Der Sender der Nachricht sendet die Nachricht für MAMS_RETRY-Male erneut, bevor er einen Fehler meldet, wenn keine Antwort empfangen wird. Ein Fehler impliziert, dass der MAMS-Peer inaktiv oder nicht erreichbar ist, und der Sender kehrt in den nativen Nicht-Mehrfachzugangs-/Einwegmodus zurück. Der CCM 206 kann die MAMS-Erkennungsprozedur zum Wiederaufbauen der MAMS-Sitzung initiieren.
  • MAMS-CP-Peers führen die Keep-Alive-Prozeduren zur Sicherstellung, dass die anderen Peers erreichbar sind, und Wiederherstellung aus Dead-Peer-Szenarien aus. Jeder MAMS-CP-Endpunkt unterhält einen Keep-Alive-Timer, der für eine Dauer von MAMS_KEEP_ALIVE_TIMEOUT eingestellt ist. Der Keep-Alive-Timer wird immer dann zurückgesetzt, wenn der Peer eine MAMS-Steuernachricht empfängt. Wenn der Keep-Alive-Timer abläuft, wird eine MX-Keep-Alive-Anforderung gesendet.
  • Die Werte für MAMS_RETRY- und MAMS_KEEP_ALIVE_TIMEOUT-Parameter, die in Keep-Alive-Prozeduren verwendet werden, sind bereitstellungsabhängig. Als ein Beispiel können der Client 201 und das Netzwerk die Werte unter Verwendung von Bereitstellung erhalten. Bei Empfang einer MX-Keep-Alive-Anforderung antwortet der Empfänger mit einer MX-Keep-Alive-Antwort. Falls der Sender keine MAMS-Steuernachricht in Reaktion auf MAMS RETRY-Wiederholungen der MX-Keep-Alive-Anforderung empfängt, deklariert der MAMS-Peer, dass der Peer inaktiv oder nicht erreichbar ist. Der CCM 206 kann die MAMS-Erkennungsprozedur zum Wiederaufbauen der MAMS-Sitzung initiieren.
  • Zusätzlich sendet der CCM 206 sofort eine MX-Keep-Alive-Anforderung an den NCM, wann immer er eine Übergabe von einem (R)AN-Knoten 111 an einen anderen (R)AN-Knoten 111 detektiert. Während dieser Zeit stoppt der Client 201 die Verwendung von MAMS-UP-Funktionalität in der UL-Richtung, bis er eine MX-Keep-Alive-Antwort vom NCM 236 empfängt.
  • Die MX Keep-Alive Request enthält folgende Informationen: Reason (Grund) (z. B. kann Timeout oder Handover sein. Handover soll vom CCM 206 nur bei Detektion eines Handovers verwendet werden); Unique Session ID (eindeutige Sitzungskennung für den CCM 206, der die Verbindung aufbaut. Besteht die Sitzung bereits, so wird die bestehende eindeutige Sitzungskennung zurückgegeben. Eine NCM-ID ist eine eindeutige Identität des NCM 236 im Betreibernetzwerk, und die Sitzungs-ID ist eine eindeutige Identität, die der CCM-206-Instanz durch diese NCM-236-Instanz zugewiesen ist); eine Connection ID (Verbindungs-ID) (falls der Grund ein Handover ist, kann die Einbeziehung dieses Feldes zwingend sein); und eine Delivery Node ID (Zustellknoten-ID) (Identität des Knotens, an den der Client angeschlossen ist. Im Falle von LTE ist dies eine globale E-UTRAN-Zellkennung (ECGI - E-UTRAN Cell Global Identifier). Im Fall von WiFi ist dies eine AP-ID oder eine Medienzugriffssteuerungs-(MAC-)Adresse. Ist der Grund „Handover“, kann die Einbeziehung dieses Feldes zwingend sein).
  • Die vorliegende Offenbarung stellt neue Mechanismen bereit, um dynamische Verkehrsaufteilung/-lenkung auf der Konvergenz-(Teil-)Schicht in MAMS zu unterstützen. Bestehende Lösungen umfassen verschiedene e2e-Protokolle, wie etwa Mehrwege-TCP (MPTCP), um mehrere Wege oder RATs zu nutzen, um einen höheren Durchsatz zu erreichen. Diese e2e-Protokolllösungen werden jedoch auf dem Server verwaltet, der weit von der Datenteilungsstelle entfernt ist, und führen daher zu einer relativ hohen Rückmeldungsverzögerung. Darüber hinaus können die bestehenden Lösungen nicht auf die Funkschichtinformationen zugreifen.
  • [GMA10] spezifiziert, wie Benutzerdatenverkehr dynamisch über mehrere Verbindungen auf der MX-Konvergenzteilschicht aufgeteilt werden soll. Die vorliegende Offenbarung stellt dynamische Verkehrsaufteilung für verschiedene Optimierungsziele bereit, wie etwa Reduzieren der e2e-Verzögerung (z. B. „geringe Verzögerung“) oder Minimieren der zellularen (z. B. 5G/NR, LTE usw.) Nutzung (z. B. „niedrige Kosten“). Die vorliegende Offenbarung umfasst GMA-basierte Verkehrsaufteilung, die in der Konvergenzschicht des MAMS-Framework funktioniert (siehe z. B. 1-3). Die GMA-basierten Verkehrsaufteilungsmechanismen sind für untere Schichten transparent und benötigen keine Informationen von diesen Schichten. Es werden zwei Mehrwegeverkehrsaufteilungsoptionen bereitgestellt, die eine Option mit geringer Verzögerung und eine mit niedrigen Kosten umfassen. Verschiedene Edge-Computing-Frameworks, wie etwa der hierin erörterte MEC-Framework, können verwendet werden, um die GMA-basierte Verkehrsaufteilung zu betreiben/zu implementieren. Eine beispielhafte Implementierung umfasst ein Verwenden der Smart-Edge/MEC-Plattform, die von Intel® bereitgestellt wird.
  • 4 stellt ein Netzwerkmodell (Protokollstapel) 400 mit einer Konvergenzschicht dar. In 4 befindet sich eine Anwendungsschicht (die eine oder mehrere Apps umfasst) auf einer Transportschicht (die mindestens ein Transportprotokoll umfasst), die sich auf einer Netzwerkschicht (die mindestens ein Netzwerkprotokoll umfasst) befindet, die sich auf der Konvergenzschicht befindet (die mindestens ein Konvergenzprotokoll umfasst, das in diesem Beispiel GMA ist), die sich auf einer Sicherungsschicht befindet (die 1 bis N RAT-Protokolle umfasst (wobei N eine Zahl ist)). Das Transportschichtprotokoll kann ein oder mehrere Transportprotokolle, wie beispielsweise TCP, UDP, QUIC und/oder jedes andere geeignete Transportprotokoll, wie etwa die hier erörterten, implementieren. Zusätzlich oder alternativ dazu kann das Netzwerkschichtprotokoll IP und/oder jedes andere geeignete Netzwerkprotokoll, wie etwa die hier erörterten, sein.
  • 5 zeigt ein Beispiel 500 für eine GMA-Mehrfachzugangsverkehrsaufteilung für eine Downlink-Richtung. Im Beispiel 500 werden Datenpakete 501 von dem oder den MAMS-Servern 140 über das DN 175 (z. B. Internet) an einen GMA-Sender (Tx) 510 gesendet. Die Datenpakete 501 können jedes geeignete Netzwerkprotokollformat aufweisen; zum Beispiel können die Datenpakete 501 IP-Pakete oder dergleichen sein. Der GMA-Tx 510 sendet ein oder mehrere Pakete an einen NAN 111A zur Lieferung an einen GMA-Empfänger (Rx) 511 (z. B. Client 101), und er sendet ein oder mehrere Pakete an einen NAN 111B zur Lieferung an den GMA-Rx 511 (z. B. Client 101). Die NANs 111A, 111B erzeugen verkapselte Pakete 502 aus den Paketen 501 durch Hinzufügen eines Headers (z. B. eines IP-Headers) und eines (im Folgenden ausführlicher erörtert) GMA-Trailers zu jedem Paket 501. Die verkapselten Pakete 502 werden dann über die jeweiligen Zugangsnetzwerkverbindungen 105 an den Client 101 gesendet. Die Verfahren zum Verkapseln der Pakete 501 werden in [GMA10] erörtert.
  • Die Hauptverantwortlichkeiten des Konvergenzprotokolls (siehe z. B. 4) beruhen darauf, ob die Entität als GMA-Tx-Entität 510 oder GMA-Rx-Entität 511 agiert. Die GMA-Tx-Entität 510 teilt oder dupliziert Verkehr über mehrere Funkverbindungen 105 und überträgt Pakete über eine andere Funkverbindung 105 basierend auf e2e-Messungen erneut. Die GMA-Rx-Entität 511 ordnet Pakete, die über verschiedene Funkverbindungen 105 empfangen werden, neu und leitet diese Pakete nacheinander an Entitäten der höheren Schichten weiter.
  • 1.1. PRO-PAKET-PRIORISIERUNG (PPP)
  • Neuerlich unter Bezugnahme auf 1 arbeitet die MX-Konvergenz-(Teil-)Schicht auf der MX-Anpassungs-(Teil-)Schicht in den Protokollstapeln 102 und 142. Aus der Sicht des Senders (Tx) wird eine Benutzer-Nutzlast (z. B. IP-PDU) zuerst von der Konvergenzteilschicht und dann von der Anpassungsteilschicht verarbeitet, bevor sie über eine Zustellzugangsverbindung (z. B. Verbindung 105A oder Verbindung 105B) transportiert wird. Aus der Sicht des Empfängers (Rx) wird ein über eine Zustellverbindung empfangenes Paket (z. B. IP-Paket) zunächst von der MX-Anpassungsteilschicht und dann von der MX-Konvergenzteilschicht verarbeitet (dies ist auch 14 dargestellt, auf die im Folgenden ausführlicher erörtert wird).
  • Bei der vorliegenden Offenbarung umfasst die Konvergenzschicht Pro-Paket-Priorisierungsmechanismen (PPP - Per Packet Prioritization). Ähnliche Konzepte wie PPP werden in Nädas, „Per Packet Value:,, „A Practical Concept for Network Resource Sharing “, 2016 IEEE Global Communications Conference (GLOBECOM), ff. 1-7 (4. Dez. 2016), verfügbar unter http://ppv.elte.hu/ („[NÁDAS01]“), „PPV - PER PACKET VALUE“, verfügbar unter: http://ppv.elte.hu/ („[PPV]“), die hiermit durch Bezugnahme in ihrer Gesamtheit hierin aufgenommen werden, zum Verbessern der Benutzererfahrung und der Fairness beschrieben.
  • [NÁDAS01] und [PPV] beschreiben ein Pro-Paketwert-Framework (PPV - Per Packet Value), das eine Vielfalt ausführlicher und flexibler Richtlinien unter verschiedenen Verkehrskombinationen implementiert und durchsetzt. Das PPV-Framework definiert Ressourcenteilungsrichtlinien für verschiedene Situationen durch Durchsatzpaketwert-(PV-)Funktionen. Im PPV-Framework wird ein Paketmarker an einem oder mehreren Rechenknoten (z. B. RAN-Knoten 111, MX-Server 140, Edge-Rechenknoten 2036 und/oder NANs 2031-2033, die im Folgenden mit Bezug auf 20 erörtert werden, Router, Switches, Hubs, Gateways, Netzwerkgeräte usw.) implementiert, der einen PV auf jedem Paket basierend auf einer Durchsatz-PV-Funktion dieses Flusses markiert. Das Netzwerk und Ressourcenknoten innerhalb des Netzwerks maximieren den Gesamt-PV übertragener Pakete unter Verwendung verfügbarer Ressourcen. Diese Maximierung führt zum Implementieren von Überlastungsrichtlinien, ohne dass ein Flussbewusstsein notwendig ist.
  • Das PPV-Framework ordnet Paketen zwei Werte oder Markierungen zu, einen Paketwert (PV) und einen Überlastungsschwellenwert (CTV - Congestion Threshold Value). Der PV stellt die Verstärkung des Betreibers dar, wenn das Paket geliefert wird; PVs drücken die relative Wichtigkeit von Paket zu Paket (d. h. den Grenznutzen) aus. PVs werden als Wert pro Bit [Wert/Bit] ausgedrückt, um einen direkten Vergleich zwischen Paketen unterschiedlicher Größen zu ermöglichen, wobei ein längeres Paket einen höheren Gesamtwert aufweist als ein kürzeres mit derselben Paketwertmarkierung, normalerweise aber im Verhältnis auch mehr Ressourcen benötigt, um übertragen zu werden. Der CTV gibt die Verzögerungsanforderungen des Flusses an, zu dem die Pakete gehören. Der CTV trennt die Pakete mit PVs, die von denjenigen übertragen werden, die an einem Ressourcenknoten verworfen werden. Der CTV basiert auf der Kombination von verfügbarer Kapazität, der Menge an angebotenem Verkehr und der PV-Zusammensetzung des angebotenen Verkehrs. Der CTV nimmt mit zunehmender bekannter oder überwachter Überlastung zu. Ressourcenknoten leiten Pakete gemäß der betreiberdefinierten maximalen Verzögerung für den CTV jedes Pakets weiter. Sowohl der PV als auch der CTV können in neu erstellten oder bestehenden Paket-Header-Feldern mitgeführt werden, wie etwa im Feld Differenzierte-Dienste-Codepunkt (DSCP - Differentiated Services Code Point) oder in einem MPLS-Etikett (MPLS - Multiprotocol Label Switching).
  • Der Paketmarker markiert oder enthält die PVs und CTVs in Paketen basierend auf der Durchsatz-PV-Funktion dieser Pakete. Bei einigen Implementierungen werden alle Pakete unter einem CTV verworfen, und der Durchsatz der verbleibenden Pakete wird durch die Durchsatz-PV-Funktion bei dieser Schwelle (z. B. dem CTV über dem Verwerfen-Regel-CTV) definiert. Eine beispielhafte Paketmarkierungsimplementierung (pro Fluss) ist wie folgt: (i) Quantisieren der durch Durchsatz-PV-Funktionen; (ii) Zuordnen eines Token-Bucket zu jedem quantisierten Bereich (PV wie definiert, die Rate eingehender Token ist der Durchsatz dieses Bereichs, und die Größe ist Tokenrate * typische Puffergröße von Ressourcenknoten); und, (iii) wenn ein Paket eines Flusses eintrifft, Auswählen des Token-Bucket mit dem höchsten PV, wo genügend Token (Paketgröße) vorhanden sind.
  • Jeder der Ressourcenknoten maximiert den übertragenen Gesamt-PV. Ressourcenknoten senden Pakete mit hohem PV auf Kosten von Paketen mit niedrigem PV. Bei einigen Implementierungen bedient jeder Ressourcenknoten Pakete in PV-Reihenfolge von PVs mit dem höchsten PV zuerst und so weiter. Für First-In-First-Out-(FIFO-)Implementierungen wird ein Paket mit dem kleinsten PV verworfen, wenn die FIFO-Warteschlange voll wird. Außerdem können Ressourcenknoten verschiedene Pakete, die verschiedene Ressourcen aufweisen, bei der Maximierung des übertragenen Gesamt-PV berücksichtigen. Bei einigen Implementierungen vergleichen die Ressourcenknoten PVs nicht direkt, sondern stattdessen normalisiert durch die Kosten ihrer Übertragung (r). Hierbei wird der effektive Paketwert (EPV) eines Pakets als sein PV geteilt durch seine Übertragungskosten (r). Ressourcenknoten können bei Bedarf auch dafür Sorge tragen, die Paketreihenfolge innerhalb eines Flusses beizubehalten.
  • Das PPV-Framework (und/oder die im Folgenden erörterte schichtübergreifende Architektur) (oder Anpassungen davon) kann für die hier erörterten PPP-Mechanismen verwendet werden. Bei einigen Implementierungen markieren der Edge-Rechenknoten (z. B. der MX-Server 140 und/oder der Edge-Rechenknoten 2036 in 20) oder der Client 101 jedes Datenpaket mit einem Prioritätswert, so dass einige Pakete verworfen werden können, wenn eine Überlastung an Zugangs-/Edge-Knoten (z. B. RAN-Knoten 111, MX-Server 140, Zugangs-/Edge-Knotenschicht 2030 in 20, die im Folgenden mit Bezug auf 20 erörtert wird, Router, Switches, Hubs, Gateways, Netzwerkgeräte usw.) auftritt.
  • Gegenwärtig unterstützen IP-Header Pro-Fluss-Klassifizierung und/oder -Priorisierung durch das Feld Differenzierte-Dienste-Codepunkt (DSCP) im IP-Header. DSCP kann jedoch nicht verwendet werden, um „Pro-Paket-Priorität“ zu übertragen, da es bereits verwendet wurde, um die Priorität oder Klasse eines Flusses zu spezifizieren. Bei verschiedenen Ausführungsformen wird das GMA-Verkapselungsprotokoll [GMA10] erweitert, um das Pro-Paket-Priorität-Feld ohne jegliche Auswirkung auf die bestehenden IP-Header-Felder zu übertragen. Folglich können Zwischenelemente (z. B. Zugangs-/Edge-Knoten) dementsprechend Warteschlangenverwaltung und Paketverwerfen in Reaktion auf Überlastung durchführen. Die Ausführungsformen hierin können in Edge-Computing-Frameworks, wie etwa den hierin erörterten, implementiert werden. In einem Beispiel können die Ausführungsformen unter Verwendung der von Intel® bereitgestellten Smart-Edge/MEC-Plattform implementiert werden.
  • 6 stellt beispielhafte GMA-Verkapselungsformate dar. 6 zeigt zwei GMA-Verkapselungsformate 601 und 602, wie in [GMA10] spezifiziert. Die GMA-Steuerfelder können dabei entweder am Ende der IP-Nutzlast als Trailer oder zu Beginn als Header hinzugefügt werden. Andere Aspekte der GMA-Formate werden im Folgenden mit Bezug auf 19 und in [GMA10] erörtert. In beiden Optionen verbleibt der ursprüngliche IP-Header nach der Verkapselung als der IP-Header, Abwärtskompatibilität zu bewahren. Das Protokolltypfeld des IP-Headers wird auf einen spezifischen Wert geändert, zum Beispiel „114“ (siehe z. B. [GMA10]), um das Vorhandensein eines GMA-Trailers (oder Headers) anzuzeigen. Die beiden GMA-Endpunkte (z. B. Mehrfachfunk-UE 101 und MX-Server 140 in 1) können aushandeln, welches GMA-Format (z. B. Trailer oder Header) durch die MAMS-Steuersignalisierung oder -Vorkonfiguration zu verwenden ist.
  • Gegenwärtig übertragen der GMA-Header und der GMA-Trailer Folgenummer, Zeitstempel, Flussidentifikation und andere Informationen, um verschiedene Mehrfachzugangsoptimierungen zu unterstützen. Bei einigen Implementierungen wird ein neues Steuerfeld Pro-Paket-Priorität (PPP) zum GMA-Verkapselungsheader oder zum GMA-Verkapselungstrailer hinzugefügt, um PPP anzugeben, was wie folgt sein kann:
    • • Pro-Paket-Priorität (PPP): eine vorzeichenlose ganze Zahl (0 ~ 255), um die Priorität des Pakets anzugeben.
  • Bei einigen Implementierungen gibt ein höherer PPP-Wert im PPP-Feld eine höhere Priorität an, und ein niedrigerer Wert im PPP-Feld gibt eine niedrigere Priorität an (z. B. gibt ein PPP-Wert von „0“ eine niedrigste Priorität an, und ein PPP-Wert von „255“ gibt eine höchste Priorität an). Bei anderen Implementierungen gibt ein niedrigerer Wert in dem PPP-Feld eine höhere Priorität an und gibt ein höherer Wert in dem PPP-Feld eine niedrigere Priorität an (z. B. gibt ein PPP-Wert von „255“ eine niedrigste Priorität an und gibt ein PPP-Wert von „0“ eine höchste Priorität an).
  • Bei verschiedenen Ausführungsformen können neue MAMS-Steuernachrichten verwendet werden, um dem MX-Server 140 und/oder dem MX-Client 101 zu ermöglichen, eine oder mehrere PPP-Zuordnungsregeln für UL-Verkehr am MX-Client 101 zu konfigurieren und/oder PPP-Zuordnungsregeln für UL- und/oder DL-Verkehr am MX-Server 140 zu konfigurieren. Zum Beispiel können die neuen MAMS-Steuernachrichten eine MX-PPP-Konfigurationsanforderungsnachricht (mx_ppp_config_req) und/oder eine MX-PPP-Konfigurationsantwortnachricht (mx_ppp_config_rsp) umfassen. Zusätzlich oder alternativ kann der PPP-Indikator zu MAMS-Fähigkeitsaustauschnachrichten (z. B. mx_capability_req und/oder mx_capability_rsp) hinzugefügt werden. Bei verschiedenen Implementierungen konfiguriert der PPP-Indikator einen MAMS/MX-Knoten mit einer oder mehreren PPP-Zuordnungsregeln, wobei die PPP-Zuordnungsregeln verwendet werden, um Pakete zu routen und/oder PPP-Indikatoren zu spezifischen Paketen zuzuordnen.
  • 6 zeigt auch ein GPT-Paket (GPT - Generic Payload Type) 603, das zu Paketklassifizierungszwecken verwendet wird. Das GPT-Paket 603 umfasst einen Netzwerkschicht-Header (z. B. einen IP-Header), einen Transportschicht-Header (z. B. UDP, TCP usw.) und einen Nutzlastabschnitt. Der Nutzlastabschnitt umfasst ein GPT-Feld, das ein generisches Feld in der Paketnutzlast ist. Das GPT-Feld umfasst einen GPT-Offset x, eine GPT-Länge y und einen GPT-Wert s. Der GPT-Offset x ist eine Anzahl von Bits oder Bytes vom Ende des Transportschicht-Headers zum Anfang des GPT-Feldes, das verwendet wird, um die Position des GPT-Feldes anzugeben. Die GPT-Länge y ist eine Länge des GPT-Feldes, ausgedrückt als eine Anzahl von Bits oder Bytes. Der GPT-Wert s ist ein Wert, der in das GPT-Feld aufgenommen werden soll. Der GPT-Wert s kann das Format einer vorzeichenlosen ganzen Zahl aufweisen. Der GPT-Wert s kann die PPP-Anzeige/der zuvor erörterte PPP-Wert sein. Andere Aspekte des GTP-Feldes / GPT-Pakets 603 werden im Folgenden erörtert.
  • 7 zeigt eine MAMS-Steuernachrichtenaustauschprozedur 700 für PPP. Die Prozedur 700 wird von zwei MX-Peers (z. B. MX-Peer 1 und MX-Peer 2 in 7) durchgeführt. Im Beispiel von 7 entspricht der MX-Peer 1 dem MX-Client 101 und der MX-Peer 2 entspricht dem MX-Server 140. Diese Rollen könnten jedoch bei anderen Implementierungen umgekehrt werden.
  • Prozedur 700 beginnt mit einem Fähigkeitsaustausch (der bei Operation 701 ein Senden von mx_capability_req von MX-Peer 2 an MX-Peer 1 und bei Operation 701 ein Senden von mx_capability_rsp von MX-Peer 1 an MX-Peer 2 umfasst). Der Fähigkeitsaustausch umfasst, dass der NCM (oder CCM) die Netzwerkadresse (z. B. IP-Adresse) und den Port von MX-Peer 1 (oder MX-Peer 2) aus einer MX-System-Infonachricht lernt, die während einer MX-Erkennungsprozedur erhalten wird, und bei Operation 701 eine mx_Fähigkeit_req an den MX-Peer 1 sendet. Als Reaktion erzeugt der CCM (oder NCM) (z. B. MX-Peer 1) eine eindeutige Identität für den NCM (oder CCM) -Sitzung und sendet bei Operation 702 die mx_capability_rsp.
  • Der Inhalt und andere Aspekte der mx_capability_req- und mx_capability_rsp-Nachrichten werden im Folgenden in Abschnitt 1.4 unterhalb erörtert. Bei verschiedenen Ausführungsformen umfassen mx_capability_req und/oder mx_capability_rsp einen PPP-Indikator (z. B. ein Datenfeld, ein Datenelement und/oder einen Parameter/Wert), um Unterstützung für PPP anzugeben. Falls beide MX-Peers 1 und 2 PPP unterstützen, sendet der NCM (z. B. implementiert durch den MX-Peer 2 (z. B. MX-Server 140)) in einigen Implementierungen eine mx_ppp_config_req-Nachricht bei Operation 703, die eine PPP-Konfiguration enthalten kann. Zusätzlich oder alternativ dazu initiiert der MX-Server 140 die PPP-Konfiguration, aktualisiert die PPP-Konfiguration und beendet/stoppt die Verwendung der PPP-Konfiguration. Bei einer beispielhaften Implementierung kann die PPP-Konfiguration einige oder alle der folgenden Informationen umfassen:
    • • Anzahl an PPP-Regeln (z. B. 1 bis N, wobei N eine Zahl wie etwa 4 ist)
    • • Für jede PPP-Regel wird Folgendes einbezogen:
      • o Flussklassifizierungsparameter: Parameter, der verwendet wird, um einen Fluss zu identifizieren, für den die PPP-Regel gilt. Die Flussklassifizierungsparameter können zum Beispiel auf Netzwerkschicht-Header-Feldern (z. B. IP-Quellen-(src-)Adresse (addr), IP-Ziel-(dst-)addr, Protokolltyp, src-Portnummer, dst-Portnummer) basieren.
      • ◯ Regeltyp:
        • ■ 0: Bestimmen von PPP basierend auf (App-)Paketgrößenbereich (ausgenommen TCP/IP-Header).
        • ■ 1: Bestimmen von PPP basierend auf Codierung von (App-)Paketgröße (PS).
        • ■ 2: Bestimmen von PPP basierend auf dem generischen Nutzlasttyp (GPT), wobei der GPT ein generisches Feld in der Paketnutzlast 603 ist, wie in 6 gezeigt.
        • ■ 3: Bestimmen von PPP basierend auf der eingehenden Rate (Last) des Verkehrsflusses (siehe z. B. [PPV]).
        • ■ Andere: reserviert.
      • ◯ Anzahl von Prioritätsstufen (z. B. L, wobei L eine Zahl ist).
    • • Für jede Prioritätsstufe werden die Informationen in Tabelle 1.1-1 einbezogen.
      Figure DE102021209988A1_0001
    Figure DE102021209988A1_0002
  • Im Beispiel von Tabelle 1.1-1 umfasst der (App-)Paketgrößenbereich in PPP-Regeltyp 0 eine minimale (min) und eine maximale (max) Größe oder eine Länge des zu übertragenden Pakets, die einem jeweiligen PPP-Wert entspricht. Zum Beispiel kann die PPP-Konfiguration einen ersten Paketgrößenbereich, der einem ersten PPP-Wert entspricht, einen zweiten Paketgrößenbereich, der einem zweiten PPP-Wert entspricht, und so weiter bis zu einem ersten PPP-Wert, einemL-ten Paketgrößenbereich angeben, der einem L-ten PPP-Wert entspricht.
  • Die (App-)Paketgrößencodierung des PPP-Regeltyps 1 bezieht sich auf einen bestimmten Code, der auf der Paketgröße basiert. Im Beispiel von Tabelle 1.1-1 basiert der Paketgrößencode auf einer Modulo-Operation unter Verwendung der Paketgröße PS und der Anzahl von Prioritätsstufen L, was einen Modul ergibt (wobei der Modul der Rest der euklidischen Teilung von PS durch L ist). Zusätzlich oder alternativ können andere Codierungsschemata verwendet werden, wie beispielsweise Exklusiv-ODER (XOR), Reed-Soloman-Codierung, Polarcodierung, Low-Density-Parity-Check-Codierung (LDPC), Tail-Biting-Faltungscodierung, Turbo-Codierung usw.). Eine zusätzliche oder alternative Regel kann auf einem bestimmten Modulations- und Codierungsschema einer zugrundeliegenden RAT basieren, die zum Übertragen des Pakets verwendet wird.
  • Die GPT-Parameter von PPP-Regeltyp 2 beziehen sich auf GPT-Offset (x), -Länge (y), - Wert (s) und/oder andere Parameter, die im Folgenden erörtert werden. Der Ratenbereich von PPP-Regeltyp 3 bezieht sich auf eine Datenrate, die zum Senden und/oder Empfangen von Paketen verwendet wird, und wird in diesem Beispiel in Kilobit pro Sekunde (Kbit/s) ausgedrückt.
  • Bei einigen Implementierungen sendet der MX-Peer 1 (z. B. MAMS-(GMA-)Client 101) bei Operation 704 eine mx_ppp_config_rsp-Nachricht. Die mx_ppp_config_rsp-Nachricht kann eine Bestätigung des Empfangs der mx_ppp_config_req-Nachricht enthalten, und/oder sie kann den gleichen oder einen ähnlichen Inhalt wie die mx_ppp_config_req-Nachricht umfassen.
  • Zusätzlich oder alternativ dazu kann die mx_ppp_config_req-Nachricht (oder die mx_ppp_config_rsp-Nachricht) einige oder alle der zuvor genannten Informationen enthalten. Zum Beispiel kann eine aktualisierte PPP-Konfiguration in der mx_ppp_config_req/rsp-Nachricht enthalten sein, die nur Werte/Regeln enthält, die in Bezug auf eine ursprüngliche (oder vorherige) PPP-Konfiguration aktualisiert werden sollen. Bei einigen Implementierungen aktualisiert der MX-Server 140 (oder Gs 1440) die PPP-Konfiguration immer dann, wenn der MX-Server 140 (oder Gs 1440) irgendwelche Änderungen detektiert, beispielsweise Detektieren eines neuen QoS-Flusses mit PPP, Detektieren bestehender Flüsse mit aktualisiertem PPP, Detektieren von Verkehrsüberlastungs- und/oder Überlastbedingungen am MX-Server 140 (oder Gs 1440), dem MX-Client 101 (oder Gc 1401) und/oder dem NAN 130, und/oder basierend auf anderen Bedingungen/Kriterien. Zusätzlich oder alternativ dazu können eine oder mehrere Schnittstellen/APIs zwischen den Anwendungen und dem MX-Server 140 (oder Gs 1440) verwendet werden, um die PPP-Konfiguration von einer Anwendung (z. B. Edge-App) für den MX-Server 140 (oder Gs 1440) bereitzustellen. Diese Schnittstelle/API könnte die im Folgenden mit Bezug auf 9 erörterte flussinterne Klassifizierungs-API sein. Zusätzlich oder alternativ dazu können die ETSI-MEC-Verkehrsverwaltungs-APIs (siehe z. B. 28) für diesen Zweck verwendet werden.
  • Nach der MX-PPP-Konfiguration führt der MX-Peer 1 (z. B. MAMS-Client 101) bei Operation 705 die PPP-Konfiguration eine PPP-Markierung basierend auf der/den bereitgestellten PPP-Zuordnungsregel(n) (z. B. basierend auf den in der mx_ppp_config_req enthaltenen Informationen) durch, und der MX-Peer 2 (z. B. MAMS-(GMA-)Server 140) führt eine PPP-Markierung für DL-Verkehr basierend auf der/den gleichen oder ähnlichen PPP-Zuordnungsregel(n) durch. Bei einigen Implementierungen wird die PPP-Markierung auf der GMA-Schicht jedes MX-Peers durchgeführt. Zusätzlich oder alternativ führt der Zwischenknoten (z. B. Zugangsnetzwerk (AN) 110, NAN 111, Router, Gateway usw.) PPP-basierte Warteschlangenverwaltung durch, wenn bei Operation 707 Überlastung auftritt. Wenn die PPP-Konfiguration eine Aktualisierung einer bestehenden oder vorherigen PPP-Konfiguration ist, wendet der MX-Peer 1 (z. B. MAMS-Client 101) zusätzlich oder alternativ die aktualisierte PPP-Konfiguration auf neuen oder bestehenden Verkehr/neue oder bestehende Flüsse (oder Teilflüsse innerhalb neuer oder bestehender Flüsse) an.
  • Bei Operation 706 sendet der CCM (oder NCM) (z. B. der MX-Peer 1 (z. B. MAMS-(GMA-)Client 101) eine Bestätigung (oder Ablehnung) in einer mx_capability_ack-Nachricht. Der Inhalt und andere Aspekte der mx_capability_ack-Nachricht werden im Folgenden in Abschnitt 1.4 unterhalb diskutiert.
  • Falls der NCM (oder CCM) eine MX_REJECT empfängt, wird die aktuelle MAMS-Sitzung beendet. Falls der CCM (oder NCM) nicht mehr mit den aktuellen Fähigkeiten fortfahren kann, kann er eine MX-Sitzungsbeendigungsanforderung senden, um die MAMS-Sitzung zu beenden. Als Reaktion kann der NCM (oder CCM) eine mx_session_termination_rsp senden, um die Beendigung zu bestätigen. Zusätzlich oder alternativ sendet der MX-Peer 1 (Client 101) eine mx_up_setup_conf_cnf-Nachricht. Diese Nachricht kann in der ACK-Nachricht umfasst sein oder als separate Nachricht gesendet werden.
  • Nach der/den (den) mx_capability_ack- und/oder mx_up_setup_conf_cnf-Nachricht(en) können Datentransfers zwischen den MX-Peers stattfinden, wobei PPP basierend auf dem Wert des PPP-Feldes in dem GMA-Trailer/-Header durchgeführt wird. Bei einigen Ausführungsformen kann die PPP ausgelöst oder initiiert werden, wenn eine Überlastung am MX-Peer 1 (Client 101), dem NAN 111 oder dem MX-Peer 2 (Server 140) detektiert wird.
  • 1.2. INTRAFLUSSKLASSIFIZIERUNGSMECHANISMEN
  • Kürzlich wurde die Notwendigkeit zur Verbesserung der Latenz für Echtzeitanwendungen, wie etwa Spiele, Robotik und industrielle Automatisierung, eingeführt. Paketklassifizierung und Dienstgüte-(QoS-)Markierung zwischen Flüssen gewinnen zunehmend an Bedeutung, um differenzierten Dienst und Unterstützung für diese zeitkritische Paketzustellung in drahtlosen Netzwerken bereitzustellen.
  • 8 zeigt eine logische Darstellung der Informationen, die auf der IP-Schicht verwendet werden, um die Lieferung elektronischer Daten (z. B. IP-Header 800) zu ermöglichen. Der Header 800 enthält Informationen, die zum Routen von Daten über ein Netzwerk (z. B. WLAN, Internet usw.) verwendet werden, und weist unabhängig von der Art der gesendeten Daten das gleiche Format auf. Die Felder im IP-Header und deren Beschreibungen sind wie folgt.
  • Version - Ein 4-Bit-Feld, das die verwendete IP-Version identifiziert (z. B. IPv4, IPv6 usw.); für Ipv4 ist der Wert in diesem Feld immer gleich 4.
  • Internet-Header-Länge (IHL) - Das IHL-Feld enthält die Größe des IPv4-Headers, er weist 4 Bits auf, welche die Anzahl von 32-Bit-Wörtern im Header spezifizieren. Der Minimalwert für dieses Feld ist 5, was eine Länge von 5 x 32 Bit = 160 Bit = 20 Byte angibt. Als ein 4-Bit-Feld ist der Maximalwert 15, dies bedeutet, dass die maximale Größe des IPv4-Headers 15 × 32 Bit = 480 Bit = 60 Byte ist.
  • Differenzierte-Dienste-Codepunkt (DSCP - Differentiated Services Code Point) - Ursprünglich als das Diensttypfeld (ToS - Type of Service ) definiert, spezifiziert dieses Feld differenzierte Dienste (DiffServ) gemäß Nichols et al., „Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Header“, IETF RFC 2474 (Dezember 1998) und/oder Fairhurst, „Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Code Points (DSCP) Registry“, IETF RFC 8436 (August 2018).
  • Explizite Überlastungsmeldung (ECN - Explizite Congestion Notification) - Dieses Feld ist in Ramakrishnan et al., „The Addition of Explicit Congestion Notification (ECN) to IP“, IETF RFC 3168 (September 2001) und/oder Black, „Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation“, IETF RFC 8311 (Januar 2018) definiert und erlaubt Endezu-Ende-Meldung einer Netzwerküberlastung ohne Verwerfen von Paketen. ECN ist ein optionales Merkmal, das verfügbar ist, wenn beide Endpunkte es unterstützen, und wirksam, wenn es auch durch das zugrundeliegende Netzwerk unterstützt wird.
  • Gesamtlänge - Dieses 16-Bit-Feld definiert die gesamte Paketgröße in Bytes, einschließlich Header und Daten. Die Mindestgröße beträgt 20 Byte (Header ohne Daten) und das Maximum 65.535 Byte. Alle Hosts müssen in der Lage sein, Datagramme mit einer Größe von bis zu 576 Byte wieder zusammenzusetzen, die meisten modernen Hosts bewältigen aber viel größere Pakete. Verbindungen können der Paketgröße weitere Einschränkungen auferlegen, in welchem Fall Datagramme fragmentiert werden müssen. Die Fragmentierung in IPv4 wird entweder im sendenden Host oder in Routern durchgeführt. Die Wiederzusammensetzung wird am empfangenden Host durchgeführt.
  • Identifikation - Dieses Feld ist ein Identifikationsfeld und dient primär zur eindeutigen Identifikation der Gruppe von Fragmenten eines einzigen IP-Datagramms.
  • Flags - Es folgt ein Drei-Bit-Feld, das zum Steuern oder Identifizieren von Fragmenten verwendet wird. Es handelt sich dabei um folgende (in der Reihenfolge von höchstwertig zu niedrigstwertig): Bit 0 (Reserviert; muss null sein); Bit 1 (Nicht fragmentieren (DF)); und Bit 2 (Mehr Fragmente (MF)). Wenn das DF-Flag gesetzt ist und Fragmentierung erforderlich ist, um das Paket zu routen, dann wird das Paket verworfen. Dies kann verwendet werden, wenn Pakete an einen Host gesendet werden, der keine Ressourcen aufweist, um eine Wiederzusammensetzung von Fragmenten durchzuführen. Es kann auch für Path Maximum Transmission Unit Discovery (PMTUD) verwendet werden, entweder automatisch durch die Host-IP-Software oder manuell unter Verwendung von Diagnosewerkzeugen wie Ping und/oder Traceroute. Für unfragmentierte Pakete wird das MF-Flag gelöscht. Für fragmentierte Pakete weisen alle Fragmente außer dem letzten das MF-Flag gesetzt auf. Das letzte Fragment weist ein Fragment-Offset-Feld ungleich Null auf, das es von einem unfragmentierten Paket unterscheidet.
  • Fragment-Offset - Dieses Feld gibt den Offset eines bestimmten Fragments in Bezug auf den Anfang des ursprünglichen unfragmentierten IP-Datagramms in Einheiten von Acht-Byte-Blöcken an. Das erste Fragment weist einen Offset von Null auf. Das 13-Bit-Feld ermöglicht einen maximalen Offset von (213 - 1) × 8 = 65.528 Byte, was mit der enthaltenen Headerlänge (65.528 + 20 = 65.548 Byte) Fragmentierung von Paketen unterstützt, welche die maximale IP-Länge von 65.535 Bytes überschreiten.
  • Time to Live (TTL) - Ein Acht-Bit-TTL-Feld begrenzt die Lebensdauer eines Datagramms, um einen Netzwerkausfall im Falle einer Routing-Schleife zu verhindern. Der TTL-Wert im TTL-Feld wird in Sekunden angegeben, und Zeitintervalle kleiner als 1 Sekunde werden auf 1 aufgerundet. In der Praxis wird das Feld als Hop-Zähler verwendet - wenn das Datagramm an einem Router ankommt, dekrementiert der Router das TTL-Feld um eins. Wenn das TTL-Feld Null erreicht, verwirft der Router das Paket und sendet typischerweise eine Internetsteuernachrichtenprotokoll-(ICMP-)Zeitüberschreitungsnachricht an den Sender. Das Programm Traceroute sendet Nachrichten mit angepassten TTL-Werten und verwendet diese ICMP-Zeitüberschreitungsnachrichten zum Identifizieren der Router, die von Paketen von der Quelle zum Ziel durchlaufen werden.
  • Protokoll - Dieses Feld definiert das im Datenteil des IP-Datagramms verwendete Protokoll.
  • Header-Prüfsumme - das 16-Bit-Header-Prüfsummenfeld wird zur Fehlerprüfung des Headers verwendet. Wenn ein Paket an einem Router ankommt, berechnet der Router die Prüfsumme des Headers und vergleicht sie mit dem Prüfsummenfeld. Falls die Werte nicht übereinstimmen, verwirft der Router das Paket. Fehler im Datenfeld müssen durch das verkapselte Protokoll behandelt werden. Sowohl UDP als auch TCP weisen separate Prüfsummen auf, die für ihre Daten gelten. Wenn ein Paket an einem Router ankommt, reduziert der Router das TTL-Feld im Header. Folglich muss der Router eine neue Header-Prüfsumme berechnen.
  • IP-Quelladresse - Dieses Feld enthält die IP-Adresse des Absenders des Pakets. Diese Adresse kann unterwegs durch eine Netzwerkadressübersetzungseinrichtung geändert werden.
  • IP-Zieladresse - Dieses Feld enthält die IP-Adresse des vorgesehenen Empfängers des Pakets. Diese Adresse kann unterwegs durch eine Netzwerkadressübersetzungseinrichtung geändert werden.
  • Optionen und Auffüllen - Ein Feld, das in der Länge von 0 bis zu einem Vielfachen von 32 Bit variiert. Falls die Optionswerte kein Vielfaches von 32 Bit sind, werden 0-en addiert oder aufgefüllt, um sicherzustellen, dass dieses Feld ein Vielfaches von 32 Bit enthält.
  • Allgemein umfassen QoS-Mechanismen Klassifizierungs- und Markierungsmechanismen, Richtlinien- und Formungsmechanismen, Überlastverwaltungsmechanismen und Überlastvermeidungsmechanismen. Die Klassifizierungs- und Markierungsmechanismen identifizieren eine einzelnen Paketen und/oder Flüssen zugeordnete Priorität. Üblicherweise werden Pakete nach Eintritt in ein System über eine Eingangsschnittstelle klassifiziert und markiert. Dann können die Richtlinien- und Formungsmechanismen einige der Pakete verwerfen. Dann werden die Pakete erneut nach ihren Markierungen kategorisiert. Die Überlastungsverwaltungs- und Überlastungsvermeidungsmechanismen geben unterschiedlichen Paket-Typen unterschiedliche Prioritäten, so dass die Pakete höherer Priorität das Gateway früher passieren können, wenn es zu einer Netzwerküberlastung kommt. Schließlich sendet das System Pakete, die durch QoS-Mechanismen verarbeitet wurden, von einer oder mehreren Ausgangsschnittstellen aus.
  • Zwischenfluss-Paketklassifizierung ist ein Mechanismus, der Anwendungen ermöglicht, die QoS-Klassifizierung für einen Fluss zum Beispiel durch das DSCP/ToS-Header-Feld im IP-Header 800 so zu spezifizieren, dass eine sendende (Tx) Vorrichtung ihre Zustellung entsprechend planen kann. Intraflussklassifizierungsmechanismen mangelt es jedoch an bestehenden Vernetzungstechnologien.
  • Eine frühere Lösung schlug ein Klassifizieren von flussinternen Paketen durch ein „Total Langt“-IP-Header-Feld (z. B. Paketgröße) vor. Aufgrund der Komplexität und Ressourcennutzung, die für solche Lösungen erforderlich sind, kann es jedoch für Anwendungen nicht möglich oder wünschenswert sein, die Paketgröße zum Zweck der Klassifizierung zu ändern.
  • Die vorliegende Offenbarung stellt Intraflussklassifizierungsmechanismen bereit. Bei Ausführungsformen können Anwendungen/Vorrichtungen Pakete im selben Fluss basierend auf den Nutzlastfeldern eines oder mehrerer Pakete klassifizieren. Die vorliegende Offenbarung definiert ein GTP-Feld (GTP - Generic Packet Type) in der Anwendungsnutzlast, so dass die Anwendung dieses neue Feld verwenden kann, um QoS-Anforderungen eines Pakets, Flusses, Stroms usw. (z. B. maximal tolerierbare Verzögerung, Priorität usw.) anzugeben. Die Ausführungsformen hierin stellen Paketformate und Protokolle für TSN-Technologien (TSN - Time Sensitive Networking) der nächsten Generation bereit, die verwendet werden können, um eine Lieferung mit niedriger Latenz für zeitempfindliche Anwendungen, wie etwa Spiele, Robotik, Drohnen und industrielle Automatisierung, bereitzustellen. Die hierin bereitgestellten Ausführungsformen ermöglichen außerdem eine zeitkritische Lieferung von Paketen, was Rechen- und Netzwerk-/Signalisierungsressourcennutzung (z. B. durch Reduzieren von Ressourcenverbrauch/Overhead) verbessert. Außerdem können die Ausführungsformen hierin in Edge-Computing-Frameworks implementiert werden, wie etwa beliebigen der hierin erörterten.
  • Es wird nun wieder Bezug genommen auf das GTP-Paket 603 von 6, das unter anderem einen Netzwerkschicht-Header (z. B. IP-Header und/oder dergleichen), einen Transportschicht-Header (z. B. TCP-Header, UDP-Header und/oder dergleichen) und einen Anwendungsnutzlastabschnitt umfasst. Der Anwendungsnutzlastabschnitt umfasst ein GTP-Feld. Üblicherweise können IP-Flüsse durch die folgenden fünf Parameter klassifiziert werden: IP-Quelladresse, IP-Zieladresse, Transportprotokolltyp (z. B. UDP, TCP usw.), UDP/TCP-Quellport und UDP/TCP-Zielport. Für IPv6-Pakete kann ein 3-Tupel eines Flussetikett-, eines Quelladress- und eines Zieladressfeldes zur Flussklassifizierung verwendet werden.
  • Bei Ausführungsformen wird das GPT-Feld verwendet, um Verkehr oder Pakete in einem Fluss weiter zu klassifizieren. Diese weitere Klassifizierung von Verkehr oder Paketen in einem Fluss kann als „flussinterne oder Intraflussklassifizierung“ bezeichnet werden, wobei der Verkehr oder die Pakete als zu Teilflüssen gehörig klassifiziert werden (d. h., wobei mehrere Teilflüsse einen Daten- oder Verkehrsfluss bilden). Das Format und die Wert(e) des GTP-Feldes sind nicht fest und können durch einzelne Anwendungen bestimmt werden. Bei einigen Implementierungen umfasst das GPT-Feld die folgenden Parameter:
    • • Offset (x): eine Anzahl von Bits/Bytes vom Ende eines Headers (z. B. Transportschicht-Header, wie in 6 dargestellt) bis zum Anfang des GPT-Feldes, das verwendet wird, um die Position des GPT-Feldes anzugeben;
    • • Länge (y): die Anzahl von Bits/Bytes des GPT-Feldes (z. B. eine Größe/Länge des GPT-Feldes);
    • • Wert (s): der Wert des GPT-Feldes im Format einer vorzeichenlosen ganzen Zahl; und
    • • QoS-Klasse (c): QoS-Klasse oder Paket-Typ des Pakets.
  • Hierbei kann eine Anwendung flexibel die Position des GPT-Feldes in der Nutzlast sowie die Länge des Feldes bestimmen. Die Anwendung kann auch die Zuordnung zwischen dem Wert des GTP-Feldes und der QoS-Klasse oder dem Paket bestimmen. Zum Beispiel kann die Anwendung ( × , y , s ) und ( s , c ) für das System/die Vorrichtung durch eine Anwendungsprogrammierungsschnittstelle (API), zum Beispiel eine GTP-Intraflussklassifizierungs-API, bereitstellen (siehe 9).
  • 9 stellt einen GTP-Intraflussklassifizierungsprotokollstapel 900 dar. Der Protokollstapel 900 kann durch eine Entität für aktive Warteschlangenverwaltung (AQM - Active Queue Management) eines MX-Rechenknotens, beispielsweise eines MX-Clients 101, eines Zugangsnetzwerks 110 (oder eines Rechenknotens darin), eines NAN 111, eines MX-Servers 140, eines Kernnetzwerks 150 A (oder eines Rechenknotens darin) und/oder eines FA-GW/Kerns 150 B (oder eines Rechenknotens darin) von 1; eines Clients 201, von Zugangsnetzwerken 231 (oder einem Rechenknoten darin), eines MAMS-Systems 235 (oder eines Rechenknotens darin) und/oder von Kernnetzwerken 241 (oder einem Rechenknoten darin) von 2; einer GMA-Tx-Entität 510 und/oder einer GMA-Rx 511 von 5; und/oder beliebiger anderer hierin erörterter Vorrichtungen/Systeme implementiert werden. Der Protokollstapel 900 basiert teilweise auf einer schichtübergreifenden Architektur, die in J. Zhu et al., „Improving QoE for Skype Video Call in Mobile Broadband Network“, IEEE Globecom (2012) („[ZHU01]“) erörtert wird, das hiermit durch Bezugnahme in seiner Gesamtheit aufgenommen wird.
  • Der Protokollstapel 900 umfasst eine Anwendungsschicht, eine Transportschicht (z. B. TCP, UDP, QUIC usw.), eine Netzwerkschicht (z. B. IP usw.) und eine Zugangsschicht. Die Transport- und Netzwerkschichten können gleich oder ähnlich wie zuvor erörtert sein. Die Zugangsschicht kann eine oder mehrere Teilschichten umfassen, und die Zugangsschicht kann spezifisch für eine bestimmte Zugangstechnologie und/oder Funkzugangstechnologie (RAT) sein, die implementiert wird (z. B. WiFi, WiMAX, LTE, 5G/NR, Ethernet usw.). Die Zugangsschicht kann zum Beispiel der Verbindungsschicht der Internetprotokollsuite entsprechen, und/oder sie kann der Datenverbindungsschicht und/oder der physischen (PHY) Schicht des OSI-Modells entsprechen. Zusätzlich oder alternativ dazu kann die Zugangsschicht die Konvergenzschicht und die Verbindungsschicht des Protokollstapels 400 von 4 umfassen. Zusätzlich oder alternativ dazu kann die Zugangsschicht eine Medienzugriffssteuerungs-(MAC-)Schicht und eine PHY-Schicht umfassen, die auf den unterschiedlichen RAT-Schaltungsanordnungen basieren können, die durch den MX-Rechenknoten implementiert werden. Zusätzlich oder alternativ dazu kann die Zugangsschicht eine GMA-Konvergenzschicht, die Transportschichten, Netzwerkschichten und die RAT-Schichten in den in 17 dargestellten Protokollstapeln 1700c, 1700d und/oder 1700e umfassen (hierbei entsprechen die Netzwerkschicht und die Transportschicht in 9 der Netz-3- und der Transport-3-Schicht des Protokollstapels 1700c oder 1700d, oder die Netzwerkschicht und die Transportschicht in 9 entsprechen der Netz-1- und der Transport-1-Schicht des Protokollstapels 1700e).
  • Der Protokollstapel 900 umfasst außerdem eine neue Schnittstelle, die zwischen der Anwendungsschicht und der Zugangsschicht eingefügt ist, um direkte Kommunikation zwischen der Anwendungsschicht und einer Zugangsschicht bereitzustellen. Diese Schnittstelle umfasst die Intraflussklassifizierungs-API und die Überlastungsmeldungs-API.
  • Die Überlastungsmeldungs-API überträgt Überlastungsmeldungen von der Zugangsschicht an die Anwendungsschicht. Bei einigen Implementierungen ist die Überlastungsmeldung ein binäres Flag, das angibt, ob das Zugangsnetzwerk Überlastung erfährt oder nicht. Die Überlastungsmeldungen werden von der Zugangsschicht für die Anwendungsschicht bereitgestellt. Die Anwendungsschicht verwendet die Überlastungsmeldung, um ihre Quellrate zu reduzieren, um eine Netzwerküberlastung zu mindern. Zusätzlich oder alternativ dazu verwendet die Anwendungsschicht die Überlastungsbenachrichtigungen, um AQM durchzuführen (z. B. wie im Folgenden erörtert).
  • Die Intraflussklassifizierungs-API überträgt Intraflussprioritäts-/- klassifizierungsinformationen von der Anwendungsschicht an die Zugangsschicht. Die Intraflussprioritäts-/-klassifizierungsinformationen können eine Kennung umfassen, die zu einem Paket hinzugefügt oder anderweitig darin enthalten ist und die einen Teilfluss identifiziert, in den es basierend auf seiner Priorität eingeordnet ist. Hier werden Pakete, die zum selben Fluss gehören, durch ihre Netzwerkschichtparameter (z. B. IP-Quelladresse, IP-Zieladresse, Quellportnummer, Zielportnummer und Protokolltyp für IP-Pakete eines IP-Flusses) eindeutig identifiziert und ferner basierend auf ihrer Priorität in Teilflüsse eingeordnet. Zusätzlich oder alternativ dazu werden Pakete, die zum selben Fluss gehören, durch andere Parameter des Flusses, wie beispielsweise Anwendungsparameter, Transportschichtparameter und/oder dergleichen, eindeutig identifiziert. Die Intraflussprioritäts-/-klassifizierungsinformationen werden von der Anwendungsschicht für die Zugriffsschicht bereitgestellt. Die Zugriffsschicht verwendet die Intraflussprioritäts-/- klassifizierungsinformationen zur besseren Planung von Paketen, wenn Überlastung auftritt (z. B. basierend auf einer Detektion eines Überlastungs- oder Überlastungsereignisses/-zustands). Zusätzlich oder alternativ dazu verwendet die Zugangsschicht die Intraflussprioritäts-/- klassifizierungsinformationen, um gewisse Pakete gegenüber anderen Paketen zu priorisieren und/oder AQM durchzuführen (wie z. B. im Folgenden erörtert).
  • Die Intraflussklassifizierungs-API kann eine GPT-Intraflussklassifizierungs-API sein, die es Anwendungen in der Anwendungsschicht ermöglicht, mit der Zugangsschicht zu kommunizieren, um nutzlastbasierte Klassifizierungsregeln/-richtlinien bereitzustellen. Die GPT-Intraflussklassifizierungs-API ist ein neues Outband-Signal oder eine neue Outband-Schnittstelle zwischen der Anwendungsschicht und Kommunikationsvorrichtungen in der Zugangsschicht, um die GPT-basierten Intraflussklassifizierungsregeln/-Richtlinien/-Konfigurationen bereitzustellen. Die GPT-Intraflussklassifizierungs-API ermöglicht es einzelnen Anwendungen, das Format des GPT-Feldes (siehe z. B. Paket 603 von 6) durch die Kombination von Bit/Byte-Offset (x) und -Länge ( y ) zu spezifizieren. Die Intraflussklassifizierungsregeln/-richtlinien können Flussklassifizierungsinformationen (z. B. für einen IP-Fluss oder Teilfluss), einen GPT-Offset (x), eine GPT-Länge (y) und eine GPT-QOS-Klassenzuordnung (c) umfassen.
  • Verschiedene QoS-Klassenwerte (c) können vordefiniert oder konfiguriert sein (z. B. unter Verwendung der zuvor erörterten PPP-Konfiguration und/oder einer separaten GPP-Konfiguration). Zum Beispiel kann „c = 0“ als die Standardklasse ohne irgendeine spezifische QoS-Anforderung definiert sein, und „c = 1“ kann als eine Klasse mit hoher Priorität mit einer maximal tolerierbaren Verzögerung von zum Beispiel 10 Millisekunden (ms) definiert sein. Dann kann die Anwendung durch die GPT-Intraflussklassifizierungs-API eine Karte (oder Konfiguration) bereitstellen, die s = „0^-100“ zu „c = 0“ zuordnet und s = " > 100" zu „c = 1“. Zusätzlich oder alternativ dazu können die QoS-Klassen gleich oder ähnlich wie die QoS-Fluss-IDs (QFIs) und/oder die 5G-QoS-Kennung (5QI) sein, wie für 3GPP-5G-Systeme definiert, wie in 3GPP TS 23.501 v 17.1.1 (2021-06-24) und/oder 3GPP TS 38.300 v16.6.0 (2021-07-06) erörtert. Zusätzlich oder alternativ können andere QoS-Klassen/-Klassifizierungen verwendet werden. Bei einer dieser Implementierungen kann die Anwendung wenigstens die folgenden Informationen über die GPT-Intraflussklassifizierungs-API umfassen (oder bereitstellen).
    • • Intraflussklassifizierungsinformationen: Informationen, die zum Identifizieren eines Flusses und/oder von Teilflüssen verwendet werden, die den Fluss bilden (z. B. Netzwerkadresse (z. B. IP-Adresse usw.), Protokolltyp, Portnummer(n), App-ID, Sitzungs-ID usw.)
    • • GPT-Offset (x)
    • • GPT-Länge (y)
    • • GPT-QoS-Zuordnung:
      • o Anzahl von QoS-Klassen
      • o Für jede QoS-Klasse werden einbezogen:
        • • Ein QoS-Klassenwert (c)
        • • Ein GPT-Wertebereich (s)
  • Einzelne Anwendungen können eine GTP-Konfiguration oder eine andere geeignete Datenstruktur mit den obigen Informationen über die GPT-Intraflussklassifizierungs-API für die Zugangsschicht bereitstellen. Zusätzlich oder alternativ dazu kann die GPT-Intraflussklassifizierungs-API verwendet werden, um die zuvor erörterte PPP-Konfiguration für die Zugangsschicht (z. B. von einer Anwendung in der Anwendungsschicht für Gc 1401 oder Gs 1440 in der Zugangsschicht) und/oder andere Entitäten (z. B. vom MX-Server 140 (oder Gs 1440) für den MX-Client 101 (oder Gc 1401)) bereitzustellen. Obwohl die vorstehenden Ausführungsformen zum Kennzeichnen von Flüssen und Teilflüssen beschrieben wurden, sind die Ausführungsformen hierin zusätzlich auch auf Datenströme und dergleichen anwendbar. Die Ausführungsformen von 9 können mit den zuvor in Abschnitt 1.1 erörterten PPP-Mechanismen und/oder den im Folgenden mit Bezug auf Abschnitt 1.3 erörterten Ausführungsformen verwendet werden.
  • 1.3. PPP-BASIERTE AKTIVE WARTESCHLANGENVERWALTUNG (AQM)
  • Moderne Anwendungen/Transportprotokolle, wie etwa QUIC, verkapseln mehrere Verkehrsströme in einem Fluss. Sprach- und Videoströme können zum Beispiel in einen Videokonferenzfluss gemultiplext werden. Traditionelle Verkehrsverwaltungstechniken, wie etwa IP-differenzierte Dienste basierend auf DSCP, sind ein beliebter Ansatz, um Netzwerkverkehr zu verwalten und QoS bereitzustellen. Die traditionellen Verkehrsverwaltungstechniken arbeiten jedoch auf der Fluss-Ebene und können daher die verschiedenen QoS-Anforderungen einzelner Ströme, die in einen Fluss gemultiplext werden, nicht erfüllen.
  • Die vorliegende Offenbarung stellt Techniken zur aktiven Warteschlangenverwaltung (AQM - Active Queue Management) für Verkehrsströme bereit, die in einen Fluss gemultiplext werden. AQM bezieht sich zumindest in einigen Ausführungsformen auf eine Richtlinie zum Verwerfen von Paketen innerhalb eines Puffers, der mit einer Zugangsschichtschaltungsanordnung (z. B. einer Netzwerkschnittstellensteuerung (NIC) und/oder einer Funksendeempfängerschaltungsanordnung für eine oder mehrere RATs) assoziiert ist, bevor dieser Puffer voll wird, oft mit dem Ziel, Netzwerküberlastung zu reduzieren oder Ende-zu-Ende-(e2e-)Latenz zu verbessern. Bei einigen Implementierungen werden AQM-Aufgaben durch einen Netzwerkplaner (auch als Paketplaner, Warteschlangenalgorithmus und/oder dergleichen bezeichnet) und/oder eine Konvergenzschichtentität durchgeführt (der Begriff „AQM-Entität“, wie hier verwendet, kann sich auf einen Netzwerkplaner, eine Konvergenzschichtentität und/oder eine andere ähnliche Entität beziehen, die AQM-Aufgaben durchführt/ausführt). Bei Ausführungsformen werden neue QoS-Metriken auf Paketebene Verkehrsströmen zugewiesen, die in einen Fluss gemultiplext werden. Diese QoS-Metriken umfassen Pro-Paket-Priorität (PPP) (z. B. wie zuvor erörtert) und/oder Verzögerungsgrenze, die durch den Sender oder die Netzwerk-Edge basierend auf dem Verkehrstyp bestimmt werden. Die QoS-Metriken können in einem geeigneten Feld eines Netzwerkpakets, wie etwa dem DSCP-Feld, übertragen werden oder in einem Steuerheader, wie etwa dem Konvergenzprotokoll von GMA, übertragen werden (siehe z. B. [GMA10]). Wenn Überlastung an einer Netzwerkvorrichtung (z. B. dem MX-Client 101, dem Zugangsnetzwerk 110 (oder einem Rechenknoten darin), dem NAN 111, dem MX-Server 140, dem Kernnetzwerk 150A (oder einem Rechenknoten darin) und/oder dem FA-GW/Kern 150 B (oder einem Rechenknoten darin) von 1 auftritt; dem Client 201, den Zugangsnetzwerken 231 (oder einem Rechenknoten darin), dem MAMS-System 235 (oder einem Rechenknoten darin) und/oder Kernnetze 241 (oder ein Rechenknoten darin) von 2; der GMA-Tx-Entität 510 und/oder dem GMA-Rx 511 von 5; dem GW 1420A-1420 B und/oder dem NAT/Firewall-Gateway 1450 von 14; den UEs 2011, 2021a, den NANs 2031-2033, den Edge-Rechenknoten 2036, CN 2042 (oder Rechenknoten) darin) und/oder Cloud 2044 (oder Rechenknoten) darin) von 20; der Zentrale 2120, dem NAN 2140, dem lokalen Verarbeitungshub 2150 und/oder den Datenquellen 2160 von 21; beliebigen der unter Bezugnahme auf 22-28 dargestellten und beschriebenen Vorrichtungen, den Prozessorplattform(en) 2900 und/oder der Verteilungsplattform 2905 von 29; dem Computerknoten 3000 von 30; und/oder beliebigen anderen hierin erörterten Vorrichtungen/Systemen) auftritt, verwirft eine AQM-Entität die Pakete mit niedrigerer Priorität (z. B. Video) zuerst, um wichtigere Pakete (z. B. Sprache) in demselben Fluss zu schützen. Auf diese Weise verbessern die neuen Paketebenen-QoS-Metriken die QoS für Endbenutzer.
  • Für Zwecke der vorliegenden Offenbarung können die folgenden Begriffe/Variablen verwendet werden:
    • • L - Anzahl der Prioritätsstufen (z. B. 3).
    • • P - Prioritätswert innerhalb des Bereichs von [0, L - 1]. Ein kleinerer P stellt zum Beispiel eine höhere Priorität dar, P = 0 ist die höchste Priorität, und P = 1 ist die niedrigste Priorität. Bei einigen Implementierungen kann der zuvor erwähnte PPP-Wert diesem Wert P entsprechen.
    • • W(P, L) - Gewichtungsfunktion basierend auf P und L. W (P, L) jede Funktion sein, die mit abnehmendem P zunimmt. Ein Beispiel ist eine lineare Funktion W(P, L) = 1 - (P/L).
    • • D - Warteschlangenverzögerung des aus der Warteschlange entfernten Pakets, was die Verzögerung einer aktuellen AQM-Entität/Netzwerkvorrichtung oder eine akkumulierte Verzögerung in einem Multi-Hop-Szenario sein könnte.
    • • T - Pro-Paket-Verzögerungsgrenze. Bei einigen Implementierungen kann eine Anwendung T = 0 als eine Standardeinstellung festgelegen, falls die Verzögerungsgrenze deaktiviert ist. Falls T gleich null oder größer als die Warteschlangenverzögerungsgrenze TDEV der AQM-Entität/Netzwerkvorrichtung ist, dann T = TDEV.
    • • N - Warteschlangengrößengrenze.
    • • Q - Aktuelle Warteschlangengröße. Zum Einreihen in die Warteschlange umfasst Q das neue Paket, das am Ende der Warteschlange eingefügt wird.
  • Die im Folgenden beschriebenen Warteschlangenverwaltungsmechanismen basieren auf Paketebenen-QoS-Metriken: Pro-Paket-Priorität P und (optional) einer Verzögerungsgrenze T. P und T können durch die Anwendung am Sender/Transmitter oder an der Netzwerk-Edge (z. B. dem Edge-Rechenknoten 2036) konfiguriert werden. In verschiedenen Ausführungsformen wird P standardmäßig auf null gesetzt und erhöht, wenn die Wichtigkeit dieses Pakets abnimmt. T ist gleich null, wenn die Verzögerungsgrenze deaktiviert ist. Andernfalls legt die Anwendung T basierend auf der Anforderung des Verkehrsstroms fest. Bei Überlastung in oder an einer Netzwerkvorrichtung verwirft die Netzwerkvorrichtung (bzw. ihre AQM-Entität) Pakete mit niedrigerer Priorität ab und stellt wichtigere (prioritätshöhere) Pakete zu. Zudem werden Pakete, die die Verzögerungsgrenze T verletzen, stets verworfen. Wenn ein Paket einen einzelnen Verkehrsstrom überträgt, basieren die Paketebenen-QoS-Metriken auf dem Verkehrstyp. Falls jedoch mehrere Verkehrsströme in ein Paket gemultiplext sind, ist P gleich dem niedrigsten P (höchste Priorität) aller Verkehrsströme, und T ist gleich der minimalen Verzögerung Grenze aller Verkehr Ströme.
  • 1.3.1. FRÜHZEITIGES VERWERFEN BASIEREND AUF GEWICHTETER WARTESCHLANGENGRÖßENGRENZE
  • Beim Einreihen/Entfernen eines Pakets wird eine gewichtete Warteschlangengrößengrenze basierend auf der Pro-Paket-PrioritätP berechnet. Das Paket wird fallengelassen, falls die aktuelle Warteschlangengröße größer als eine gewichtete Warteschlangengrößengrenze ist, was ausgedrückt werden kann, wie folgt: Q > W (P, L) X N. Bei Auftreten von Überlastung in oder an einer Netzwerkvorrichtung schützt die Netzwerkvorrichtung (oder ihre AQM-Entität) wichtige Pakete durch frühzeitiges Verwerfen von Paketen mit niedrigerer Priorität als andere Pakete in einer bestimmten Warteschlange. Mit anderen Worten werden Pakete mit niedrigerer Priorität selbst dann verworfen, wenn die Warteschlange nicht vollständig belegt ist. Wenn zum Beispiel eine Warteschlangengröße Q = W (P*, L) × N, werden Pakete mit P > P* verworfen. 10 zeigt beispielhafte Prozesse für AQM basierend auf einer gewichteten Warteschlangengrößengrenze, die einen beispielhaften Prozess zur Einreihung in eine Warteschlange 1000a und einen beispielhaften Prozess zur Entfernung aus einer Warteschlange 1000b umfassen. Die Prozesse 1000a und 1000b können von einer AQM-Entität einer Netzwerkvorrichtung, wie etwa der hier erörterten Vorrichtungen/Systeme, durchgeführt werden.
  • Unter Bezugnahme auf den Einreihungsprozess 1000a wird beim Einreihen eines neuen Pakets mit einer Priorität P dann, wenn bei Operation 1001 Q > W(P, L) × N, das neue Paket bei Operation 1002 verworfen. Andernfalls wird das neue Paket bei Operation 1003 am Ende der Warteschlange eingefügt.
  • Unter Bezugnahme auf den Prozess zur Entfernung aus der Warteschlange 1000b wird beim Entfernen eines neuen Pakets mit einer Priorität P, solange Q > W(P, L) × N (Operation 1005), das bei Operation 1006 aus der Warteschlange entfernte Paket verworfen, und bei Operation 1007 wird ein anderes Paket aus der Warteschlange entfernt und P aktualisiert; andernfalls wird das letzte aus der Warteschlange entfernte Paket bei Operation 1008 gesendet.
  • Ein beispielhafter Pseudocode für die Prozesse 1000a und 1000b ist durch Tabelle 1.3.1-1 dargestellt.
    Figure DE102021209988A1_0003
  • 1.3.2. FR17HZEITIGES VERWERFEN BASIEREND AUF GEWICHTETER WARTESCHLANGENVERZÖGERUNGSGRENZE
  • Einige Vorrichtungen, wie etwa WiFi-Stationen, stellen eine warteschlangenverzögerungsbasierte Verwerfungsrichtlinie bereit. Falls die Warteschlangenverzögerung eines aus der Warteschlange entfernten Pakets größer als eine Verzögerungsgrenze ist (z. B.D > TDEV), verwirft die Vorrichtung dieses Paket und entfernt ein neues aus der Warteschlange. Dieser Prozess kann mehrmals wiederholt werden, bis das aus der Warteschlange entfernte Paket die Verzögerungsanforderung TDEV erfüllt. Eine Beschränkung dieses Ansatzes besteht darin, dass die TDEV eine einzige Schwelle ist, die für alle Pakete in der Warteschlange festgelegt ist, die die einzelnen Anforderungen verschiedener Verkehrstypen nicht erfüllen können.
  • Hierin basiert eine verbesserte AQM auf der gewichteten Warteschlangenverzögerungsgrenze, die ausgedrückt wird, wie folgt: W (P, L) × T, wobei durch die Anwendung am Sender oder an der Netzwerk-Edge konfiguriert wird.T Falls T gleich null oder größer als die Verzögerungsgrenze einer Netzwerkvorrichtung TDEV ist, dann ist T gleich TDEV Wenn Überlastung auftritt, nimmt D zu, und Pakete mit niedrigerer Priorität werden zuerst verworfen. Mit zunehmender D werden auch Paketen mit höherer Priorität verworfen. Wenn D > T, werden schließlich alle Pakete verworfen. Wenn zum Beispiel die Warteschlangenverzögerung D = W(P*, L) × T, werden Pakete mit P > P* verworfen. Für Multi-Hop-Szenarien berücksichtigt die Warteschlangenverzögerung D die akkumulierte Warteschlangenverzögerung durchlaufener Hops. 11 zeigt beispielhafte Prozesse für AQM basierend auf einer gewichteten Warteschlangenverzögerungsgrenze, die einen beispielhaften Prozess zur Einreihung in eine Warteschlange 1100a und einen beispielhaften Prozess zur Entfernung aus einer Warteschlange 1100b umfassen. Die Prozesse 1100a und 1100b können von einer AQM-Entität einer Netzwerkvorrichtung, wie etwa der hier erörterten Vorrichtungen/Systeme, durchgeführt werden.
  • Unter Bezugnahme auf den Einreihungsprozess 1100a wird beim Einreihen eines neuen Pakets mit Priorität P dann, wenn bei Operation 1101 Q > N, das neue Paket bei Operation 1102 verworfen. Andernfalls wird das neue Paket bei Operation 1103 am Ende der Warteschlange eingefügt.
  • Unter Bezugnahme auf den Prozess zur Entfernung aus der Warteschlange 1100b beim Entfernen eines neuen Pakets mit P, solange Q > 0 und D > W(P, L) × T (Operation 1105), das aus der Warteschlange entfernte Paket bei Operation 1106 verworfen, und at Operation 1107 wird ein anderes Paket verworfen und P wird aktualisiert; andernfalls wird das letzte aus der Warteschlangen entfernte Paket bei Operation 1108 gesendet.
  • Ein beispielhafter Pseudocode für die Prozesse 1100a und 1100b ist durch Tabelle 1.3.2-1 dargestellt.
    Figure DE102021209988A1_0004
  • 1.3.3. FAIRNESS FÜR AQM MIT GEWICHTETER WARTESCHLANGENGRÖßE UND GEWICHTETER WARTESCHLANGENVERZÖGERUNG
  • Die in den Abschnitten 1.3.1 und 1.3.2 beschriebenen AQM-Techniken wenden frühzeitiges Verwerfen basierend auf Paketebenen-QoS-Metriken an. Falls Anwendungen jedoch unterschiedliche Algorithmen verwenden, um Paketen QoS-Metriken zuzuweisen, kann eine Netzwerkvorrichtung, die die eine gemeinsam genutzte FIFO-Warteschlange bereitstellt, Fairness-Probleme verursachen. Zum Beispiel erfährt eine Anwendung A, die allen Paketen P = 0 zuweist, weniger Paketverlust als eine andere Anwendung B, die P im Bereich von [0, L - 1] verteilt, da die Netzwerkvorrichtungen Pakete, die zur Anwendung B gehören, infolge der niedrigeren Priorität zuerst verwerfen.
  • Diesem Fairness-Problem kann auf vielfältige Weise begegnet werden. Zum Beispiel kann eine Netzwerkvorrichtung (oder ihre AQM-Entität) eine Pro-Fluss-FIFO-Warteschlange und einen einfachen Planungsalgorithmus, wie Round-Robin, bereitstellen. Zusätzlich oder alternativ dazu kann die Netzwerkvorrichtung (oder ihre AQM-Entität) auch eine gemeinsam genutzte Warteschlange mit einer Pro-Fluss-Warteschlangengrößengrenze N(i) und N ≥ Σi N(i) bereitstellen. Folglich puffert die Netzwerkvorrichtung (oder ihre AQM-Entität) trotz Verwendung einer gemeinsam genutzten Warteschlange eine faire Anzahl von Paketen pro Fluss, wenn es zu einer Überlastung kommt. Außerdem wird die Verwerfungsbedingung für die Technik der gewichteten Warteschlangengrößenbegrenzung auch mit den Pro-Fluss-Zuständen aktualisiert: Q(i) > W(P, L) × N(i), wobei Q(i) die aktuelle Warteschlangengröße von Fluss i ist.
  • 1.3.4. PRIORISIERTES VERWERFEN FÜR AQM
  • Die QoS-Metriken können auch verwendet werden, um bestehende AQMs zu verbessern, wie etwa zufällige Früherkennung (RED), adaptive RED (RED), robuste RED (Rred), stabilisierte RED (SRED), explizite Überlastungsmeldung (ECN), gesteuerte Verzögerung (CoDel), Packet First in First Out (PFIFO), Blue, Stochytic Fair Blue (SFB), Resilient SFB (RSFB), Random Exponential Marking (REM), Modified REM (M-REM),RED with Preferential Dropping (RED-PD), Common Applications Kept Enhanced (CAKE), intelligente Warteschlangenverwaltung (SQM), Proportional Rate based Control (PRC), Proportional-Integral-(PI-)Regler und/oder dergleichen. In diesen Ausführungsformen wählt die priorisierte AQM bei einem Paketverwerfungsereignis zufällig einen Fluss (z. B. den Fluss des ersten Pakets in der Warteschlange) aus, und innerhalb dieses Flusses wird das Paket mit der niedrigsten Priorität verworfen. Falls es mehrere Pakete gibt, die der niedrigsten Priorität zugewiesen sind, wird das Paket am nächsten zum Anfang der Warteschlange verworfen. Kann die bereitgestellte Warteschlange nur Pakete am Anfang der Warteschlange entfernen, wie etwa eine FIFO-Warteschlange, so wird das zu verwerfende Paket entsprechend markiert, und dieses Paket wird verworfen, wenn es aus der Warteschlange entfernt wird.
  • Ein Problem dieser Technik ist der hohe Rechenaufwand aus dem Vergleich der Priorität gepufferter Pakete, die zum ausgewählten Fluss gehört, wenn es zu einer Überlastung kommt. Die meisten der AQMs des Standes der Technik, wie etwa CoDel, verwerfen jedoch nur ein Paket oder ein paar Pakete pro Intervall; daher lösen sie nicht allzu oft ein Verlustereignis aus. Außerdem kann der Aufwand vernachlässigbar sein, falls die meisten der Pakete als eine niedrige Priorität aufweisend gekennzeichnet sind, da die Paketprioritätsprüfung beendet werden kann, wann immer ein Paket mit der niedrigsten Priorität (P = L - 1) gefunden wird. Schließlich verursacht die priorisierte AQM im Gegensatz zur ursprünglichen AQM keine Faimessprobleme, da sie einen Fluss, an dem das priorisierte Verwerfen durchgeführt werden soll, zufällig auswählt.
  • Die vorliegende Offenbarung stellt praktische Implementierungen des priorisierten AQM-Schemas bereit, das die zuvor erörterte Technik der gewichteten Warteschlangenverzögerungsgrenze verbessert, obwohl solche Implementierungen auch auf andere AQMs angewendet werden können, wie bereits erwähnt. Die Techniken der gewichteten Warteschlangengrößengrenze und der gewichteten Warteschlangenverzögerungsgrenze verwenden eine Gewichtungsfunktion, um Prioritätsstufen gewichteten Warteschlangengrößen-/- verzögerungsschwellen zuzuordnen, die es vorziehen, wenn L klein ist. Mit zunehmender L wird das Abstimmen der Gewichtungsfunktion jedoch zunehmend schwieriger. Die folgenden Verfahren/Techniken stellen eine bessere Performance und weniger konfigurierbare Parameter zum Abstimmen bereit. Die folgenden Verfahren/Techniken befähigen die Anwendung außerdem, L dynamisch zu ändern. Eine Liste der zusätzlichen Steuerparameter ist wie folgt (nur die Parameter T und C müssen abgestimmt werden):
    • • Zustandsvariable, die sich einige oder alle Flüsse teilen:
      • ◯ C - anfängliche Überlastdetektionsschwelle innerhalb eines Schwellenbereichs (wobei z. B. der Bereich [0,1, 0,9] ist, die anfängliche Schwelle C kann 0,6 sein). Die Schwelle C ist ein konfigurierbarer Wert.
      • ◯ A - hohe Überlastungsdetektionsschwelle innerhalb eines Bereichs (z. B. [m, C], wobei m der Minimalwert des Bereichs (z. B. 0,1)) ist, der am Anfang des Algorithmus auf C initialisiert wird. A kann auch als Obergrenzen-Überlastungsdetektionsschwelle bezeichnet werden.
      • ◯ B - eine untere Überlastungsdetektionsschwelle innerhalb eines Bereichs (z. B. [m, A], wobei m der Minimalwert des Bereichs (z. B. 0,1)) ist, der am Anfang des Algorithmus auf A initialisiert wird. B kann auch als eine Untergrenzen-Überlastungsdetektionsschwelle bezeichnet werden.
    • • Zustandsgrößen pro Fluss:
      • ◯ x(i) - die Anzahl von in die Warteschlange eingereihten Paketen mit Priorität P = i (wobei z.B. i = 2, ..., L - 1). Dabei wird die Paketanzahl (#) ausgehend von der Prioritätsstufe = 2 aufgezeichnet.
      • ◯ Y - die Anzahl von zu verwerfenden Paketen (ohne Pakete mit P = 0).
      • ◯ MAXD - die maximale (max) gemessene Warteschlangenverzögerung von aus der Warteschlange entfernten Paketen im letzten Zeitintervall (z. B. 100 ms).
  • Wenn ein Paket mit Priorität P > 1 in die Warteschlange eingereiht oder daraus entfernt wird, wird ein Anzahl von eingereihten Paketen mit derselben Priorität x(P) aktualisiert. Bei einem Ereignis geringer Überlastung: D > B × T, Pakete in der Warteschlange werden gemäß ihrer Prioritätsstufe verworfen (es ist zu beachten, dass Pakete mit P = 0 nicht verworfen werden). Bei einigen Implementierungen werden Pakete nicht sofort verworfen. Stattdessen versucht die Netzwerkvorrichtung (oder ihre AQM-Entität) (oder ihre AQM-Entität), die gleiche Anzahl von Paketen in der Warteschlange, aber mit niedrigerer Priorität zu verwerfen. Dies wird durch Verwalten der Zustandsvariablen Y (die als „Verwerfungsparameter“, „Verwerfungsdefizit“ oder dergleichen bezeichnet wird) erreicht. Mit anderen Worten, wenn es eine ausreichende Anzahl von Paketen mit niedriger Priorität in der Warteschlange gibt, wird der Verwerfungsparameter Y erhöht, und die aus der Warteschlange entfernten Paket(e) werden gesendet. Andernfalls wird der Verwerfungsparameter Y verringert, und die aus der Warteschlange entfernten Paket(e) werden verworfen. Bei einem Ereignis starker Überlastung: D > A × T, alle Pakete mit P > 0 werden verworfen, um die wichtigsten Pakete (d. h. Pakete mit P = 0) zu schützen. Wenn außerdem D > T, werden aus der Warteschlange entfernte Paket(e) ungeachtet ihrer Priorität verworfen. Außerdem wird, wann immer ein Paket verworfen wird, Y um 1 reduziert, bis Y = 0. Zusätzlich dazu werden die hohe und die niedrige Überlastungsschwelle A und B periodisch aktualisiert, derart dass die Schwellen A und B herabgesetzt werden, um früher mit dem Verwerfen zu beginnen, falls Pakete mit hoher Priorität verworfen werden. 12 zeigt einen beispielhaften Prozess 1200x für AQM-priorisiertes Verwerfen, der einen Aktualisierungsprozess 1200a mit niedriger Schwelle B und einen Aktualisierungsprozess 1200b mit hoher Schwelle A umfasst. Der Prozess 1200x kann durch eine AQM-Entität einer Netzwerkvorrichtung, wie etwa der hier erörterten Vorrichtungen/Systeme, durchgeführt werden.
  • Der Prozess 1200x beginnt bei der Operation 1201 mit offener Schleife, die für jedes Zeitintervall (z. B. 100 ms) das Aktualisieren von Überlastungsdetektionsschwellen A und B wiederholt, wie folgt. Die Schwellen A und B werden herabgesetzt (Operation 1203), und es wird zu Operation 1211 übergegangen, wann immer eine Paketverzögerungsverletzung detektiert wird (Operation 1202). In einigen Ausführungsformen kann die Schwelle A und/oder B , sobald sie herabgesetzt wird, im aktuellen Zeitintervall und dem folgenden Zeitintervall nicht erneut herabgesetzt werden. Dadurch werden wiederholte Herabsetzungen in relativ kurzer Zeit verhindert. Zusätzlich oder alternativ dazu werden die Schwellen A und B am Ende des Zeitintervalls hinaufgesetzt, falls die maximale Warteschlangenverzögerung relativ niedrig ist (z. B. bei oder unter einer vorbestimmten Schwelle oder dergleichen). Falls keine Paketverzögerungsverletzung detektiert wird (Operation 1202) und/oder die Schwellen A und B nicht herabgesetzt werden (Operation 1203), dann führt die AQM-Entität einen Aktualisierungsprozess für die Schwelle A (Prozess 1200a) und/oder einen Aktualisierungsprozess für die Schwelle B (Prozess 1200b) durch. Nach der Durchführung von Operation 1203 oder 1204 geht die AQM-Entität zu Operation 1205 über, um die maximale gemessene Warteschlangenverzögerung (z. B. auf MAXD = 0 gesetzt) zurückzusetzen, und geht dann zur Operation 1206 mit geschlossener Schleife über, um den Prozess 1200 für ein nächstes Zeitintervall zu wiederholen. Wenn es kein Zeitintervall mehr gibt, kann der Prozess 1200 enden.
  • Bezugnehmend auf den Niedrigschwellen-B-Aktualisierungsprozess 1200b setzt, wenn die Warteschlangenverzögerung des Warteschlangenpakets D höher als das Produkt der hohen Überlastungsdetektionsschwelle A und der Pro-Paket-Verzögerungsgrenze T (z. B. D > A × T) ist und B im aktuellen und/oder vorherigen Intervall nicht herabgesetzt wurde (1206), die AQM-Entität die niedrige Schwelle B herab, bis sie gleich einem Minimalwert m (z. B. m = 0.1) ist (1207). Falls zum Beispiel D > A × T und B im aktuellen und vorherigen Zeitintervall nicht herabgesetzt werden (1206), setzt die AQM-Entität die niedrige Schwelle B auf einen größeren von der Hälfte von B oder einem Minimalwert (z. B. B = max ( B 2 , m )
    Figure DE102021209988A1_0005
    wobei m der Minimalwert (z. B. 0,1)) ist (1207). Falls die Warteschlangenverzögerung D nicht höher als das Produkt der hohen Warteschlangendetektionsschwelle A und der Pro-Paket-Verzögerungsgrenze T (z. B.D ≤ A × T) ist und/oder B im aktuellen oder vorherigen Intervall und/oder am Ende des Zeitintervalls herabgesetzt wurde (1206), bestimmt die AQM-Entität, ob es eine geringe Verzögerung gibt oder nicht (1208). Die AQM-Entität bestimmt, ob es eine geringe Verzögerung gibt, auf der Basis dessen, ob die maximale gemessene Warteschlangenverzögerung von aus der Warteschlange entfernten Paketen im letzten Zeitintervall MAXD geringer als das Produkt der anfänglichen Schwelle C , der hohen Überlastungsdetektionsschwelle A , und der Pro-Paket-Verzögerungsgrenze T (z. B. MAXD < C × A × T) ist (1208). Falls die geringe Verzögerung nicht detektiert wird, kehrt die AQM-Entität zu Prozess 1200x zurück. Falls eine geringe Verzögerung detektiert wird (z. B. MAXD < C × A × T), dann setzt die AQM-Entität die niedrige Schwelle B um einen bestimmten Betrag bis zur hohen Schwelle A herauf. Falls zum Beispiel MAXD < C X A × T wahr ist, dann setzt die AQM-Entität B so, dass sie ein niedrigerer von B plus dem Minimalwert m (z. B. m = 0.1) oder der hohen Schwelle A (z. B. B = min(B + m,A)) ist.
  • Unter Bezugnahme auf den Niederschwellen-A-Aktualisierungsprozess 1200asetzt, wenn die Warteschlangenverzögerung des aus der Warteschlange entfernten Pakets D höher als eine Pro-Paket-Verzögerungsgrenze T (z. B. D > T) ist, und A im aktuellen und/oder vorherigen Intervall (1210) nicht herabgesetzt wurde, die AQM-Entität die hohen Schwelle A herab, bis sie gleich einem Minimalwert m (z. B. m = 0.1) ist (1211). Falls zum Beispiel D > T und A im aktuellen und vorherigen Intervall nicht herabgesetzt wird (1210), setzt die AQM-Entität die hohe Überlastungsschwelle A auf einen größeren von der Hälfte von A oder einen Minimalwert (z. B. A = max(-,m), 2 A wobei m der Minimalwert (z. B. 0,1)) ist (1211). Dann bestimmt die AQM-Entität, ob die hohe Überlastungsdetektionsschwelle A niedriger als die niedrige Überlastungsdetektionsschwelle B (z. B. B > A) ist (1212), und, falls ja, legt die AQM-Entität die untere Überlastungsschwelle B so fest, dass sie gleich der hohen Überlastungsschwelle A (z. B. B = A) ist (1213), und geht dann zu Operation 1214 über.
  • Als Nächstes bestimmt die AQM-Entität, ob es eine geringe Verzögerung gibt, basierend darauf, ob die maximale gemessene Warteschlangenverzögerung von aus der Warteschlange entfernten Paketen im letzten Zeitintervall MAXD niedriger als das Produkt der anfänglichen Schwelle C und der Pro-Paket-Verzögerungsgrenze T (z. B. MAXD < C x T) ist (1214). Falls die geringe Verzögerung detektiert wird, kehrt die AQM-Entität zu Prozess 1200x zurück. Falls eine geringe Verzögerung detektiert wird (z. B. MAXD < C × T),dann setzt die AQM-Entität die hohe Schwelle A um einen bestimmten Betrag bis zur anfänglichen Schwelle C herauf. Falls zum Beispiel MAXD < C X T wahr ist, dann setzt die AQM-Entität A so, dass sie niedriger als eine von B plus dem Minimalwert m (z. B. m = 0.1) oder der hohen Schwelle A (z. B. A = min(A + m, C), wobei m der Minimalwert (z. B 0,1) ist).
  • Ein beispielhafter Pseudocode für Prozess 1200x (der die Prozesse 1200A und 1200B umfasst) ist durch Tabelle 1.3.4-1 dargestellt.
    Figure DE102021209988A1_0006
  • Der Prozess 1200x stimmt die Schwellen A und B für verbesserte Performance ab. Bei einigen Implementierungen kann das Schwellenabstimmungsmerkmal jedoch deaktiviert werden, um Rechenkomplexität zu reduzieren, indem die Schwellen so festgelegt werden, dass sie feste Werte aufweisen (z. B. A und B als feste Werte festgelegt werden: A = C und B = c 2
    Figure DE102021209988A1_0007
    ). Zusätzlich oder alternativ dazu können der Schwellenabstimmungsprozess 1200x und/oder die Prozesse aus 10 und 11 mit dem Eingangsprozess 1300a und dem Ausgangsprozess 1300b von 13 verwendet werden.
  • Unter Bezugnahme auf den Eingangsprozess 1300a wird beim Einreihen eines neuen Pakets mit Priorität P bei Operation 1301 in die Warteschlange dann, wenn bei Operation 1302 P > 1, bei Operation 1303 x(P) inkrementiert (x(P) + +), und das Paket wird bei Operation 1304 in die Warteschlange eingefügt. Falls bei Operation 1302 P ≤ 1, dann geht die AQM-Entität zu Operation 1304 über, um das Paket in die Warteschlange einzufügen.
  • Unter Bezugnahme auf den Ausgangsprozess 1300b führt die AQM-Entität beim Entfernen eines neuen Pakets mit Priorität P aus der Warteschlange, solange die Warteschlangengröße höher als null ist (solange z. B. Q > 0) (1305), die verbleibenden Operationen von Prozess 1300b durch; andernfalls kehrt die AQM-Entität zurück, um zu prüfen, ob die Warteschlangengröße über null ist. Wenn die Warteschlangengröße über null ist, entfernt die AQM-Entität ein Paket aus der Warteschlange und aktualisiert P (1306) und bestimmt, ob P über eins ist (z. B. P > 1) (1307). Falls P über eins ist, dekrementiert die AQM-Entität die Anzahl von aus der Warteschlange entfernen Paketen mit Priorität (z. B. x(P) - -) (1308) und geht dann zu Operation 1309 über. Falls P nicht über eins ist, geht die AQM-Entität dazu über, zu bestimmen, ob die maximale gemessene Warteschlangenverzögerung der aus der Warteschlange entfernten Pakete im letzten Zeitintervall MAXD unter der gemessenen oder aktuellen Warteschlangenverzögerung der aus der Warteschlange entfernten Paket(e) D ist (z. B. MAXD < D) (1309). Falls MAXD < D, dann legt die AQM-Entität die maximale gemessene Warteschlangenverzögerung MAXD so fest, dass sie die gemessene oder aktuelle Warteschlangenverzögerung D ist (z. B. MAXD = D festlegt) (1310), und geht dann zu Operation 1311 über. Falls die maximale gemessene Warteschlangenverzögerung MAXD nicht unter der Warteschlangenverzögerung D liegt, dann geht die AQM-Entität dazu über, die Schwelle A und/oder B herabzusetzen, wie zuvor in Bezug auf 12 erörtert (1311). Bei einigen Implementierungen kann Operation 1311 weggelassen werden.
  • Als Nächstes bestimmt die AQM-Entität, ob eine Verzögerungsverletzung vorliegt, was darauf basiert, ob die Warteschlangenverzögerung des aus der Warteschlange entfernten Pakets D über der Pro-Paket-Verzögerungsgrenze liegt T (z.B. D > T) (1312). Falls eine Verzögerungsverletzung vorliegt, verwirft die AQM-Entität das aus der Warteschlange entfernte Paket und fährt bei Vorgang 1305 mit dem Entfernen des nächsten Pakets fort (1321); andernfalls bestimmt die AQM-Entität, ob ein Zustand hoher Überlastung vorliegt (1313). Die Detektion eines Zustands hoher Überlastung (1313) basiert darauf, ob die Warteschlangenverzögerung D über dem Produkt der hohen Überlastungsschwelle A und der Pro-Paket-Verzögerungsgrenze liegt T (z. B. D > A × T) (1313), und, falls ja, dann verwirft die AQM-Entität alle Pakete außer jenen mit der höchsten Priorität (z. B. Paketen mit Priorität P = 0). Mit anderen Worten verwirft die AQM-Entität, wenn die Warteschlangenverzögerung D über dem Produkt der Schwelle A und der Pro-Paket-Verzögerungsgrenze T ist, das Paket, wenn das Paket eine Priorität von über null hat (z. B. P > 0) (1314 → 1321), oder sendet das Paket, wenn das Paket keine Priorität über null hat (z. B. P == 0) (1314 → 1320).
  • Falls die Warteschlangenverzögerung D nicht über dem Produkt der Schwelle A und der - Pro-Paket-Verzögerungsgrenze T ist (1313), dann bestimmt die AQM-Entität, ob ein Zustand geringer Überlastung vorliegt (1315). Die Detektion eines Zustands geringer Überlastung (1315) basiert darauf, ob die Warteschlangenverzögerung D über der niedrigen Überlastungsschwelle B und der Pro-Paket-Verzögerungsgrenze ist T (z. B. D > B × T) (1315). Falls die Warteschlangenverzögerung D nicht über der niedrigen Überlastungsschwelle B und der Pro-Paket-Verzögerungsgrenze T liegt (z. B. D ≤ B × T), und Y größer als null ist, dann setzt die AQM-Entität die Anzahl von zu verwerfenden Pakete Y herab (1316) und sendet dann das aus der Warteschlange entfernte Paket (1320).
  • Falls die Warteschlangenverzögerung D über dem Produkt der niedrigen Überlastungsschwelle B und der Pro-Paket-Verzögerungsgrenze T ist (z. B. D > B × T) (1315), dann verwirft die AQM-Entität Pakete gemäß ihren jeweiligen Prioritäten (z. B. werden Pakete mit Priorität P = 0 nicht verworfen). Mit anderen Worten gibt es, wenn dem Paket keine höchste Priorität zugewiesen ist (z. B. P > 0), und die Anzahl von zu verwerfenden Paketen Y über der Anzahl von in der Warteschlange eingereihten Paketen ist, die eine niedrigere Priorität als die aus der Warteschlangen entfernten Pakete aufweisen (z. B. Y > ∑ i = P + 1 i = L − 1 x ( i )
    Figure DE102021209988A1_0008
    ) (1316), nicht genügend Pakete mit niedriger Priorität in der Warteschlange, und dann verwirft die AQM-Entität die aus der Warteschlange entfernen Pakete (1321). Andernfalls gibt es genügend Pakete mit niedriger Priorität in der Warteschlange (1316), und die AQM-Entität erhöht das Verwerfungsdefizit (z. B. Y + +) (1317) und sendet das aus der Warteschlange entfernte Paket (1320).
  • Falls die Warteschlangenverzögerung D nicht über der niedrigen Überlastungsschwelle B und der Pro-Paket-Verzögerungsgrenze T liegt (z. B. D > B × T) (1315), dann kann die AQM-Entität deklarieren, dass es keine Überlastung gibt. Hierbei reduziert die AQM-Entität das Verwerfungsdefizit, falls das Verwerfungsdefizit größer als null ist (13181319), und sendet das aus der Warteschlange entfernte Paket (1320). → Das Verwerfungsdefizit kann auf 0 gehalten werden, wenn es nicht größer als Null ist (1318).
  • Ein beispielhafter Pseudocode für die Prozesse 130 a und 1300b ist durch Tabelle 1.3.4-2 dargestellt.
    Figure DE102021209988A1_0009
    Figure DE102021209988A1_0010
  • 1.4. MAMS-VERWALTUNGSNACHRICHTEN
  • Das MAMS-System 100, 200 und das GMA-System 1400 (im Folgenden erörtert) können verschiedene MAMS-Verwaltungsnachrichten (z. B. Nachricht 1430 in 14) verwenden, um Datenebenenfunktionen (z. B. Gc 1401 und Gs 1440 in 14) zu konfigurieren. Diese MAMS-Verwaltungsnachrichten 1430 können eine oder mehrere der folgenden MAMS-Nachrichten umfassen:
  • MX-Erkennungsnachricht (mx_discover): Diese Nachricht ist die erste Nachricht, die vom CCM 206 gesendet wird, um das Vorhandensein von NCM 236 im Netzwerk zu erkennen. Sie enthält nur die Basisinformationen, wie sie in Anhang C.2.1 von [RFC8743] beschrieben ist, wobei message_type als mx_discover gesetzt wird).
  • MX-System-Info-Nachricht (mx_system_info): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um den Endpunkten mitzuteilen, dass der NCM 236 MAMS-Funktionalität unterstützt. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    • - NCM-Verbindung, beschrieben im Folgenden und in Anhang C.2.3 von [RFC8743].
  • MX-Fähigkeitsanforderung (mx_capability_req): Diese Nachricht wird vom CCM 206 an den NCM 236 gesendet, um die Fähigkeiten der für den NCM 236 verfügbaren CCM-206-Instanz anzugeben, die in der System-Info-Nachricht früher angegeben wurde. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Merkmale und ihre Aktivierungsstatus (siehe z. B. Anhang C.2.5 von [RFC8743]).
    2. (b) Anzahl von Ankerverbindungen: Die Anzahl von Ankerverbindungen (zum Kern), die vom NCM 236 unterstützt wird.
    3. (c) Ankerverbindungen (siehe z. B. Anhang C.2.6 von [RFC8743]).
    4. (d) Anzahl von Zustellverbindungen: Die Anzahl von Zustellverbindungen (zum Zugang), die vom NCM 236 unterstützt wird.
    5. (e) Zustellverbindungen (siehe z. B. Anhang C.2.7 von [RFC8743]).
    6. (f) Konvergenzverfahren (siehe z. B. Anhang C.2.9 von [RFC8743]).
    7. (g) Anpassungsverfahren (siehe z. B. Anhang C.2.10 von [RFC8743]).
  • Die mx_capability_req-Nachricht wird so erweitert, dass sie die folgenden neuen Parameter umfasst:
    • - last ip adress zum Angeben der virtuellen Netzwerkadresse (z. B. IP-Adresse oder dergleichen), die in der letzten MAMS-Sitzung verwendet wurde
    • - last_session_id zum Angeben der eindeutigen Sitzungs-ID der letzten MAMS-Sitzung
    • - device_type zum Angeben des Gerätetyps (z. B. 0: Android, 1: iOS, 2: Windows, 3: Linux usw.).
  • Außerdem werden die folgenden neuen Nachrichten in das GMA-System 1400 eingeführt: mx_session_resume_req/rsp (im Folgenden erörtert). Die mx_session_resume_req/rsp-Nachrichten dient/dienen zum Benachrichtigen des Servers, dass der Client den GMA-Betrieb wiederaufgenommen hat, und zur Zeitsynchronisation. Beide Nachrichten teilen sich das gleiche Format als mx_session_termination_req/rsp und führen eine unique_session_id mit.
  • MX-Fähigkeitsantwort (mx_capability_resp oder mx_capability_rsp): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um die Fähigkeiten der NCM-236-Instanz und die eindeutige Sitzungskennung für den CCM 206 anzugeben. Zusätzlich zu den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält die mx_capability_resp die folgenden Informationen:
    1. (a) Merkmale und ihre Aktivierungsstatus (siehe z. B. Anhang C.2.5 von [RFC8743]).
    2. (b) Anzahl von Ankerverbindungen: Die Anzahl von Ankerverbindungen (zum Kern), die vom NCM 236 unterstützt wird.
    3. (c) Ankerverbindungen (siehe z. B. Anhang C.2.6 von [RFC8743]).
    4. (d) Anzahl von Zustellverbindungen: Die Anzahl von Zustellverbindungen (zum Zugang), die vom NCM 236 unterstützt wird.
    5. (e) Zustellverbindungen (siehe z. B. Anhang C.2.7 von [RFC8743]).
    6. (f) Konvergenzverfahren (siehe z. B. Anhang C.2.9 von [RFC8743]).
    7. (g) Anpassungsverfahren (siehe z. B. Anhang C.2.10 von [RFC8743]).
    8. (h) Eindeutige Sitzungs-ID: Diese identifiziert eindeutig die Sitzung zwischen dem CCM 206 und dem NCM 236 in einem Netzwerk (siehe z. B. Anhang C.2.2 von [RFC8743]).
  • Falls der Parameter „Anzahl von Ankerverbindungen“ in der mx_capability_rsp-Nachricht auf „0“ gesetzt ist, gibt dies an, dass der Server die Anforderung des Clients abgelehnt hat, und der Client die Prozedur sofort stoppen und auf den neuerlichen Beginn des nächsten Ereignisses (z. B. WiFi-Anschluss) warten sollte.
  • MX-Fähigkeitsbestätigung (mx_capability_ack): Diese Nachricht wird vom CCM 206 an den NCM 236 gesendet, um die Annahme von Fähigkeiten anzugeben, die vom NCM 236 in einer früheren MX-Fähigkeitsantwort Nachricht angezeigt wurden. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Eindeutige Sitzungs-ID: Gleiche Kennung wie die in der MX-Fähigkeitsantwort bereitgestellte Kennung (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Fähigkeitsbestätigung: Gibt entweder Annahme oder Ablehnung der Fähigkeiten an, die vom CCM 206 gesendet werden. Kann entweder „MX_ACCEPT“ oder „MX_REJECT“ als akzeptable Werte verwenden.
  • MX-Benutzerebenen-Konfigurationsanforderung (mx_up_setup_conf_req): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um die Benutzerebene für MAMS zu konfigurieren. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Anzahl von Ankerverbindungen: Die Anzahl der Ankerverbindungen, die vom NCM 236 unterstützt wird.
    2. (b) Aufbau von Ankerverbindungen (siehe z. B. Anhang C.2.11 von [RFC8743]).
  • Die mx_up_setup_conf-Nachricht wird erweitert, um eine virtuelle IP-Schnittstelle auf dem Client 101 (darunter z. B. die Netzwerkadresse (z. B. IP-Adresse oder dergleichen), das Gateway, den dns-Server, die Netzwerkmaske oder dergleichen) zu konfigurieren.
  • MX-Benutzerebenen-Konfigurationsbestätigung (mx_up_setup_conf_cnf): Diese Nachricht ist die Bestätigung der vom CCM 206 gesendeten UP-Setup-Nachricht nach erfolgreicher Konfiguration der Benutzerebene auf dem Client. Diese Nachricht enthält die folgenden Informationen:
    1. (a) Eindeutige Sitzungs-ID: Gleiche Kennung wie die in der MX-Fähigkeitsantwort bereitgestellte Kennung (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) MX-Sondierungsparameter (wird einbezogen, wenn Sondierung unterstützt wird):
      • (1) Sondierungsport: UDP-Port zum Annehmen einer Sondierungsnachricht.
      • (2) Ankerverbindungs-ID: Kennung der für Sondierungsfunktion zu verwendenden Ankerverbindung. Bereitgestellt in der MX-Setup-Konfigurationsanforderung.
      • (3) MX-Konfiguration-ID: Dieser Parameter wird nur einbezogen, falls der MX-Konfigurations-ID-Parameter aus der UP-Setup-Konfiguration verfügbar ist. Er gibt die MX-Konfigurations-ID der Ankerverbindung an, die für Sondierungsfunktion verwendet werden soll.
    3. (c) Für jede Zustellverbindung werden die folgenden Informationen benötigt:
      • (1) Verbindungs-ID: Zustellverbindungs-ID, die vom Client unterstützt wird.
      • (2) Client-Anpassungsschichtparameter: Wenn die UDP-Anpassungsschicht verwendet wird, dann ist der UDP-Port auf der C-MADP-Seite zu verwenden.
  • Wie hier erörtert, wird die mx_up_setup_cnf-Nachricht erweitert, um eine virtuelle IP-Schnittstelle auf dem Client 101 (z. B. Netzwerkadresse (z. B. IP-Adresse oder dergleichen), Gateway, dns-Server, Netzwerkmaske oder dergleichen) zu konfigurieren, alle GMA-Client-Konfigurationsparameter für den Client 101 bereitzustellen und eine Liste von Anwendungen bereitzustellen, die GMA-Optimierungen verwenden dürfen. Sie enthält die folgenden Informationen: APP-Liste (z. B. com.google.android.youtube und/oder dergleichen).
  • MX-Rekonfigurationsanforderung (mx_reconf_req): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um die Benutzerebene für MAMS zu konfigurieren. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Eindeutige Sitzungs-ID: Identifikator für die Assoziation CCM 206 - NCM 236 (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Rekonfigurationsaktion: Der Rekonfigurationsaktionstyp kann eines von „Einrichten“, „Freigeben“ oder „Aktualisieren“ sein.
    3. (c) Verbindungs-ID: Verbindungs-ID, für die die Rekonfiguration erfolgt.
    4. (d) Netzwerkadresse (z. B. IP-Adresse oder dergleichen): Wird einbezogen, falls die Rekonfigurationsaktion entweder „Einrichten“ oder „Aktualisieren“ ist.
    5. (e) SSID: Ist der Verbindungstyp WiFi, so enthält dieser Parameter die SSID, an die der Client sich angebunden hat.
    6. (f) MTU der Verbindung: Die MTU des Zustellpfades, der am Kunden berechnet wird, um vom NCM 236 zum Konfigurieren von Fragmentierungs- und Verkettungsprozeduren am N-MADP zu verwendet zu werden.
    7. (g) Verbindungsstatus: Dieser Parameter gibt an, ob die Verbindung gegenwärtig „deaktiviert“, „aktiviert“ oder „verbunden“ ist. Standardeinstellung: „verbunden“.
    8. (h) Zustellknoten-ID: Identität des Knotens, an den der Client angeschlossen ist. Im Falle von LTE ist dies eine ECGI. Im Falle von WiFi ist dies eine AP-ID oder eine MAC-Adresse.
  • MX-Rekonfigurationsantwort (mx_reconf_rsp): Diese Nachricht wird vom NCM 236 als Bestätigung der empfangenen MX-Rekonfigurationsanforderung an den CCM 206 gesendet und enthält nur die Basisinformationen im Anhang C.2.1 von [RFC8743].
  • MX-Pfadschätzungsanforderung (mx_path_est_req): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um den CCM 206 zum Senden von MX-Pfadschätzungsergebnissen zu konfigurieren. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Verbindungs-ID: ID der Verbindung, für die der Pfadschätzungsbericht benötigt wird.
    2. (b) Init Probe Test Duration (Initialisierungssondierungstestdauer): Dauer des anfänglichen Sondierungstests, in Millisekunden.
    3. (c) Init Probe Test Rate (Initialisierungssondierungstestrate): Anfängliche Testrate, in Megabit pro Sekunde.
    4. (d) Init Probe Size (Initialisierungssondierungsgröße): Größe jedes Pakets für die anfängliche Sondierung, in Bytes.
    5. (e) Init Probe-ACK (Initialisierungssondierungs-ACK): Wenn eine Bestätigung für die Sondierung erforderlich ist. (Mögliche Werte: „Ja“, „Nein“)
    6. (f) Active Probe Frequency (Aktivsondierungsfrequenz): Frequenz, in Millisekunden, mit der die aktiven Sondierungen gesendet werden sollen.
    7. (g) Active Probe Size (Aktivsondierungsgröße): Größe der aktiven Sondierung, in Bytes.
    8. (h) Active Probe Test Duration (Aktivsondierungstestdauer): Dauer, in Sekunden, für die die aktive Sonde durchgeführt werden soll.
    9. (i) Active Probe-ACK (Aktivsondierungs-ACK): Wenn eine Bestätigung für die Sondierung erforderlich ist. (Mögliche Werte: „Ja“, „Nein“).
  • MX-Pfadschätzungsergebnisse (mx_path_est_results): Diese Nachricht wird vom CCM 206 an das NCM 236 gesendet, um über die durch das NCM 236 konfigurierte Sondierungsschätzung zu berichten. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Verbindungs-ID: ID der Verbindung, für die der Pfadschätzungsbericht benötigt wird (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Init Probe Test Duration (Initialisierungssondierungstestdauer): Dauer des anfänglichen Sondierungstests, in Millisekunden.
    3. (c) Init Probe Test Rate (Initialisierungssondierungstestrate): Anfängliche Testrate, in Megabit pro Sekunde (siehe z. B. Anhang C.2.12 von [RFC8743]).
    4. (d) InitProbe Size (Initialisierungssondierungsgröße): Größe jedes Pakets für eine anfängliche Probe in Byte (siehe z. B. Anhang C.2.13 von [RFC8743]).
  • MX-Verkehrslenkungsanforderung (mx_traffic_steering_req): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um Verkehrslenkung auf der Zustellseite in UL- und DL-Konfigurationen zu ermöglichen. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Verbindungs-ID: Ankerverbindungsnummer, für welche die Verkehrslenkung definiert wird.
    2. (b) MX-Konfiguration-ID: MX-Konfiguration, für welche die Verkehrslenkung definiert wird.
    3. (c) DL-Zustellung (siehe z. B. Anhang C.2.14 von [RFC8743]).
    4. (d) Standard-UL-Zustellung: Diese Standard-Zustellverbindung für die UL. Der gesamte Verkehr sollte auf dieser Verbindung in UL-Richtung zugestellt werden, und das Verkehrsflussvorlagen- oder TFT-Filter (TFT - Traffic Flow Template) sollte nur für den in der Uplink-Zustellung erwähnten Verkehr angewendet werden.
    5. (e) Uplink-Zustellung (siehe z. B. Anhang C.2.15 von [RFC8743]).
    6. (f) Merkmale und ihre Aktivierungsstatus (siehe z. B. Anhang C.2.5 von [RFC8743]).
  • MX-Verkehrslenkungsantwort (mx_traffic_steering_rsp): Diese Nachricht ist eine Antwort auf eine MX-Verkehrslenkungsanforderung vom CCM 206 an den NCM 236. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Eindeutige Sitzungs-ID: Gleiche Kennung wie die in der MX-Fähigkeitsantwort bereitgestellte Kennung (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Merkmale und ihre Aktivierungsstatus (siehe z. B. Anhang C.2.5 von [RFC8743]).
  • MX-SSID-Angabe (mx_ssid_indication): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um die Liste zulässiger SSIDs anzugeben, die von der MAMS-Instanz netzwerkseitig unterstützt werden. Sie enthält die Liste der SSIDs. Jede SSID umfasst den Typ der SSID (der einer von Folgenden sein kann: SSID, BSSID oder HESSID) und die SSID selbst.
  • MX-Keep-Alive-Anforderung (mx_keep_alive_req): Eine MX-Keep-Alive-Anforderung kann entweder vom NCM 236 oder dem CCM 206 nach Ablauf des Keep-Alive-Timers oder eines Handover-Ereignisses gesendet werden. Auf diese Anforderung soll der Peer mit einer MX Keep-Alive-Antwort antworten. Falls keine Antwort vom Peer vorliegt, soll angenommen werden, dass die MAMS-Verbindung unterbrochen ist, und der CCM 206 soll eine neue Verbindung durch Senden von MX-Erkennungsnachrichten herstellen. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Keep-Alive-Grund: Grund für das Senden dieser Nachricht (z. B. „Timeout“, „Handover“ oder dergleichen).
    2. (b) Eindeutige Sitzungs-ID: Kennung für die Assoziation CCM 206 - NCM 236 (siehe z. B. Anhang C.2.2 von [RFC8743]).
    3. (c) Verbindungs-ID: Verbindungs-ID, für die ein Handover detektiert wird, wenn der Grund ein „Handover“ ist.
    4. (d) Zustellknoten-ID: Die Zielzustellknoten-ID (z. B. NCGI, ECGI, WiFi-AP-ID/MAC-Adresse usw.), zu der das Handover ausgeführt wird.
  • MX-Keep-Alive-Antwort (mx_keep_alive_rsp): Bei Empfang einer MX-Keep-Alive-Anforderung von einem Peer antwortet der NCM 236/CCM 206 unverzüglich mit einer MX-Keep-Alive-Antwort auf demselben Zustellungspfad, auf dem die Anforderung eingetroffen ist. Zusätzlich zu den Basisinformationen enthält sie die eindeutige Sitzungskennung für die Assoziation CCM 206-NCM 236 (siehe z. B. Anhang C.2.2 von [RFC8743]).
  • MX-Messkonfiguration (mx_measurement_conf): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um den Periodenmessbericht an dem CCM 206 zu konfigurieren. Die Nachricht enthält eine Liste von Messkonfigurationen, wobei jedes Element die folgenden Informationen enthält:
    1. (a) Verbindungs-ID: Verbindungs-ID der Zustellverbindung, für welche die Meldung konfiguriert wird.
    2. (b) Verbindungstyp: Verbindungstyp, für den die Meldung konfiguriert wird (z. B. „LTE“, „WiFi“, „5G_NR“ usw.).
    3. (c) Messberichtskonfiguration: Tatsächliche Berichtskonfiguration basierend auf dem Verbindungstyp (siehe z. B. Anhang C.2.17 von [RFC8743]).
  • MX-Messbericht (mx_measurement_report): Diese Nachricht wird vom CCM 206 nach der Messkonfiguration periodisch an den NCM 236 gesendet. Sie enthält neben den Basisinformationen die folgenden Informationen:
    1. (a) Eindeutige Sitzungs-ID: Gleiche Kennung wie die in der MX-Fähigkeitsantwort bereitgestellte Kennung (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Ein Messbericht für jede Zustellverbindung wird vom Client gemessen (siehe z. B. Anhang C.2.18 von [RFC8743]).
  • MX-Sitzungsbeendigungsanforderung (mx_session_termination_req): Falls der NCM 236 oder der CCM 206 aus irgendeinem Grund MAMS nicht mehr handhaben kann, kann er eine MX-Sitzungsbeendigungsanforderung an den Peer senden. Sie enthält neben den Basisinformationen (MXBase) eine eindeutige Sitzungs-ID und den Grund für die Beendigung, wie beispielsweise „MX_NORMAL_RELEASE“, „MX_NO_RESPONSE“ oder „INTERNAL ERROR“.
  • MX-Sitzungsbeendigungsantwort (mx_session_termination_rsp): Bei Empfang einer MX-Sitzungsbeendigungsanforderung von einem Peer soll der NCM 236/CCM 206 mit einer MX-Sitzungsbeendigungsantwort auf demselben Zustellpfad antworten, auf dem die Anforderung angekommen ist, und die MAMS-bezogenen Ressourcen und Einstellungen bereinigen. Der CCM 206 soll eine neue Sitzung mit MX-Erkennungsnachrichten neu initiieren.
  • MX-Anwendung-MADP-Assoziationsanforderung (mx_app_madp_assoc_req): Diese Nachricht wird vom CCM 206 an den NCM 236 gesendet, um MADP-Instanzen, die früher in der MX-UP-Setup-Konfigurationsanforderung bereitgestellt wurden, basierend auf Anforderungen für die Anwendungen auszuwählen. Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Eindeutige Sitzungs-ID: Diese identifiziert eindeutig die Sitzung zwischen dem CCM 206 und dem NCM 236 in einem Netzwerk (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Liste von MX-Anwendung-MADP-Assoziationen, wobei jeder Eintrag ist, wie folgt:
      • (1) Verbindungs-ID: Stellt die Ankerverbindungsnummer der MADP-Instanz dar.
      • (2) MX-Konfigurations-ID: Identifiziert die MX-Konfiguration der MADP-Instanz.
      • (3) Verkehrsflussvorlage Uplink: Verkehrsflussvorlage, die in der UL-Richtung zu verwenden ist (siehe z. B. Anhang C.2.16 von [RFC8743]).
      • (4) Verkehrsflussvorlage Downlink: Verkehrsflussvorlage, die in der DL-Richtung zu verwenden ist (siehe z. B. Anhang C.2.16 von [RFC8743]).
  • MX-Anwendung-MADP-Assoziationsantwort (mx_app_madp_assoc_rsp): Diese Nachricht wird vom NCM 236 an den CCM 206 gesendet, um die ausgewählten MADP-Instanzen zu bestätigen, die vom CCM 206 in der MX-Anwendung-MADP-Assoziationsanforderung bereitgestellt werden. Zusätzlich zu den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie Informationen, ob die Anforderung erfolgreich war.
  • MX-Netzwerkanalyseanforderung (mx_network_analytics_req): Diese Nachricht wird vom CCM 206 an den NCM 236 gesendet, um Parameter wie Bandbreite, Jitter, Latenz und Signalqualität anzufordern, die von der Netzwerkanalysefunktion vorhergesagt werden. Sie enthält neben den Basisinformationen die folgenden Parameter:
    1. (a) Eindeutige Sitzungs-ID: Gleiche Kennung wie die in der MX-Fähigkeitsantwort bereitgestellte Kennung (siehe z. B. Anhang C.2.2 von [RFC8743]).
    2. (b) Parameterliste: Liste von Parametern, an denen der CCM 206 interessiert ist: eines oder mehrere von „Bandbreite“, „Jitter“, „Latenz“ und „signal_quality“.
  • MX-Netzwerkanalyseantwort (mx_network_analytics_rsp): Diese Nachricht wird vom NCM 236 in Reaktion auf die MX-Netzwerkanalyseanforderung an den CMM 206 gesendet. Für jede Zustellverbindung, die der Client hat, meldet da NCM 236 die angeforderten Parametervorhersagen und ihre jeweiligen Wahrscheinlichkeiten (zwischen 1 und 100 Prozent). Neben den in Anhang C.2.1 von [RFC8743] beschriebenen Basisinformationen enthält sie die folgenden Informationen:
    1. (a) Anzahl von Zustellverbindungen: Die Anzahl der Zustellverbindungen, die für den Client gegenwärtig konfiguriert ist.
    2. (b) Für jede Zustellverbindung sind die folgenden Informationen vorgesehen:
      • (1) Verbindungs-ID: Verbindungs-ID der Zustellverbindung, für welche die Parameter vorhergesagt werden.
      • (2) Verbindungstyp: Typ der Verbindung. Kann „WiFi“, „5G_NR“, „MulteFire“ oder „LTE“ sein.
      • (3) Liste von Parametern, für die eine Vorhersage angefordert wird, wobei jeder der vorhergesagten Parameter aus Folgendem besteht:
        1. (a) Parametername: Name des Parameters, der vorhergesagt wird (z. B. „Bandbreite“, „Jitter“, „Latenz“ und „signal_quality“ und/oder dergleichen).
        2. (b) Zusätzlicher Parameter: Falls der Parametername „signal_quality“ ist, dann bestimmt dies den Qualitätsparameter näher (z. B. „lte_rsrp“, „lte_rsrq“, „nr_rsrp“, „nr_rsrq“, „wifi_rssi“ und/oder dergleichen).
        3. (c) Vorhergesagter Wert: Stellt den vorhergesagten Wert des Parameters und gegebenenfalls den zusätzlichen Parameter bereit.
        4. (d) Wahrscheinlichkeit: Stellt eine stochastische Wahrscheinlichkeit für den Vorhersagewert bereit.
        5. (e) Gültigkeitszeit: Die Zeitdauer, für die die Vorhersagen gültig sind.
  • Zusätzlich zu den vorstehend erwähnten Nachrichten, wobei das MAMS-System das GMA-Protokoll implementiert (siehe z. B. 17 und 19), werden die folgenden neuen Nachrichten eingeführt:
  • MX-Sitzungsunterbrechungsanforderung (mx_session_suspend_req): Wird verwendet, um den Server 140 zu benachrichtigen, dass der Client 101 den MAMS/GMA-(Sitzungs-)Betrieb unterbrochen hat und zur Zeitsynchronisation verwendet werden kann, wie hierin erörtert. Die mx_session_suspend_req teilt sich das gleiche Format mit der mx_session_termination_req und führt eine unique_session_id mit.
  • MX-Sitzungsunterbrechungsantwort (mx_session_suspend_rsp): Wird verwendet, um den Client 101 zu benachrichtigen, dass der Server 140 den MAMS/GMA-(Sitzungs-)Betrieb unterbrochen hat und zur Zeitsynchronisation verwendet werden kann. Die mx_session_suspend_rsp teilt sich das gleiche Format mit der mx_session_termination_rsp und führt eine unique_session_id mit.
  • MX-Sitzungswiederaufnahmeanforderung (mx_session_resume_req): Wird verwendet, um den Server 140 zu benachrichtigen, dass der Client 101 den MAMS/GMA-(Sitzungs-)Betrieb wiederaufgenommen hat und/oder zur Zeitsynchronisation verwendet werden kann. Die mx_session_resume_req teilt sich das gleiche Format mit der mx_session_termination_req und/oder der mx_session_termination_rsp und führt eine unique_session_id mit. Der Grund für die Wiederaufnahme der Sitzung (z. B. MAMS- und/oder GMA-Betrieb) kann sich von jenen unterscheiden, die für die mx_session_termination_req aufgeführt sind. Der Grund für die Wiederaufnahme einer Sitzung kann zum Beispiel das Aufwachen einer Anwendung oder Vorrichtung aus dem Ruhe- oder Schlafzustand (z. B. „APP_ACTIVE“, „GC_ACTIVE“, „GS_ACTIVE“ usw.) sein, das Wieder(herstellen) einer Zustellverbindung (z. B. „MX_RESPONSE“), das Einschalten eines Bildschirms, das Senden eines oder mehrerer Pakete über eine Zustellverbindung, ein Gesamtdurchsatz bei oder über einem Schwellendurchsatzbetrag, eine Verbindungsqualität bei oder über einer Schwellenqualitätsmessung und/oder ein anderer Grund sein.
  • MX-Wiederaufnahmeantwort (mx_session_resume_rsp): Wird verwendet, um den Client 101 zu benachrichtigen, dass der Server 140 den MAMS/GMA-(Sitzungs-)Betrieb wiederaufgenommen hat und/oder zur Zeitsynchronisation verwendet werden kann. Die mx_session_resume_rsp teilt sich das gleiche Format mit der mx_session_termination_req und/oder der mx_session_termination_rsp und führt eine unique_session_id mit.
  • Die vorstehenden Nachrichten können während einer Unterbrechungs-/Wiederaufnahmeprozedur verwendet werden, was dem MAMS-Client 101 ermöglicht, den MAMS-Server 140 über temporäres Unterbrechen aller MAMS-Operationen zu benachrichtigen, um Ressourcen zu schonen und/oder Strom zu sparen. Ins Reaktion darauf bewahrt der MAMS-Server 140 alle MAMS-Kontextinformationen des Clients 101 und stoppt das Durchführen jeglicher MAMS-spezifischer Operationen (z. B. GMA-Konvergenz auf der Datenebene). Diese Prozedur verbessert das MAMS-Framework, um zum Beispiel die Client-Leistungseffizienz zu verbessern und den Ressourcenverbrauch zu reduzieren, wenn die Client-Vorrichtung 101 unbedient ist oder/und sehr wenig aktiven Verkehr aufweist.
  • Die zuvor beschriebenen MAMS-Steuer-/Verwaltungsnachrichten können die folgenden Datentypen umfassen.
  • Basisinformationen (MXBase): Bei diesem Datentyp handelt es sich um die Basisinformationen, die jeder Nachrichtenaustausch zwischen dem CCM 206 und dem NCM 236 aufweist und die die folgenden Informationen umfassen:
    1. (a) Version: MAMS-Version, die verwendet wird.
    2. (b) Nachrichtentyp: Nachrichtentyp, der gesendet wird, wobei die folgenden als gültige Werte gelten: „mx_discover“, „mx_system_info“, „mx_capability_req“, „mx_capability_rsp“, „mx_capability_ack“, „mx_up_setup_conf_req“, „mx__up_setup_cnf“, „mx_reconf_req“, „mx_reconf_rsp“, „mx_path_est_req“, „mx_path_est_results“, „mx_traffic_steering_req“, „mx_traffic_steering_rsp“, „mx_ssid_indication“, „mx_keep_alive_req“, „mx_keep_alive_rsp“, „mx_measurement_conf“, „mx_measurement_report“, „mx_session_termination_req“, „mx_session_termmation_rsp“, „mx_session_resume_req“, „mx_session_resume_rsp“, „mx_app_madp_assoc_req“, „mx_app_madp_assoc_rsp“, „mx_network_analytics_req“, „mx_network_analytics_rsp“
    3. (c) Folgenummer: Folgenummer zum eindeutigen Identifizieren eines bestimmten Nachrichtenaustauschs (z. B. MX-Fähigkeitsanforderung/-antwort/-bestätigung).
  • Eindeutige Sitzungs-ID: Dieser Datentyp stellt die eindeutige Sitzungs-ID zwischen einer CCM-206- und einer NCM-236-Entität dar. Sie enthält eine NCM-ID, die im Netzwerk eindeutig ist, und eine Sitzungs-ID, die vom NCM für diese Sitzung zugewiesen wird. Bei Empfang der MX-Erkennungsnachricht wird, falls die Sitzung existiert, die alte Sitzungs-ID in der MX-System-Info-Nachricht zurückgegeben; andernfalls weist der NCM 236 eine neue Sitzungs-ID für den CCM 206 zu und sendet die neue ID in der MX-System-Info-Nachricht.
  • NCM-Verbindungen: Dieser Datentyp stellt die am NCM 236 verfügbare Verbindung für MAMS-Konnektivität zum Client dar. Sie enthält eine Liste von verfügbaren NCM-236-Verbindungen, wobei jede Verbindung die folgenden Informationen aufweist:
    1. (a) Verbindungsinformationen, siehe Anhang C.2.4 von [RFC8743].
    2. (b) NCM-Endpunktinformationen: Enthält die Netzwerkadresse (z. B. IP-Adresse oder dergleichen) und den Port, der durch den NCM 236-Endpunkt für den CCM 206 verfügbar gemacht wird.
  • Verbindungsinformationen: Dieser Datentyp stellt die Zuordnung von Verbindungs-ID und Verbindungs-Typ bereit. Dieser Datentyp enthält die folgenden Informationen:
    1. (a) Verbindungs-ID: Eine eindeutige Nummer oder Zeichenfolge, welche die Verbindung identifiziert.
    2. (b) Verbindungstyp: Typ der RAT-Verbindung, die mit der Verbindungs-ID assoziiert ist.
    Beispiele für den Verbindungstyp umfassen „WiFi“, „5G_NR“, „MulteFire“, „LTE“, „DSL“ usw.
  • Merkmale und ihr Aktivierungsstatus: Dieser Datentyp stellt die Liste aller Merkmale mit ihres Aktivierungsstatus bereit. Jeder Merkmalsstatus enthält Folgendes:
    1. (a) Merkmalsname: Der Name des Merkmals kann einer der folgenden sein:
      • „lossless_switching“, „fragmentation“, „concatenation“, „uplink_aggregation“, „downlink_aggregation“ und „measurement“.
    2. (b) Aktiver Status: Aktivierungsstatus des Merkmals: „wahr“ bedeutet, dass das Merkmal aktiv ist, und „falsch“ bedeutet, dass das Merkmal inaktiv ist.
  • Ankerverbindungen: Dieser Datentyp enthält die Liste von Verbindungsinformationen (siehe z. B. Anhang C.2.4 von [RFC8743]), die ankerseitig (kernseitig) unterstützt werden.
  • Zustellverbindungen: Dieser Datentyp enthält die Liste von Verbindungsinformationen (siehe z. B. Anhang C.2.4 von [RFC8743]), die zustellseitig (zugangsseitig) unterstützt werden.
  • Verfahrensunterstützung: Dieser Datentyp unterstützt ein bestimmtes Konvergenz- oder Anpassungsverfahren. Er besteht aus Folgendem:
    1. (a) Verfahren: Name des Verfahrens.
    2. (b) Unterstützt: Ob das oben aufgeführte Verfahren unterstützt wird oder nicht. Mögliche Werte sind „wahr“ und „falsch“.
  • Konvergenzverfahren: Dieser Datentyp enthält die Liste aller Konvergenzverfahren und ihrer Unterstützungsstatus. Beispiele für die möglichen Konvergenzverfahren sind: „GMA“, „MPTCP_Proxy“, „GRE_Aggregation Proxy“ und „MPQUIC“.
  • Anpassungsverfahren: Dieser Datentyp enthält die Liste aller Adaptionsverfahren und ihrer Unterstützungsstatus. Beispiele für die möglichen Anpassungsverfahren sind:
    • „UDP_without_DTLS“, „UDP_with_DTLS“, „Ipsec“ und „Client_NAT“.
  • Aufbau von Ankerverbindungen: Dieser Datentyp stellt die Setup-Konfiguration fürjede clientseitig erforderliche Ankerverbindung dar. Er enthält neben der Verbindungs-ID und dem Typ der Ankerverbindung die folgenden Informationen:
    1. (a) Anzahl der aktiven MX-Konfigurationen: Ist mehr als eine aktive Konfiguration für diesen Anker vorhanden, so identifiziert dies die Anzahl solcher Verbindungen.
    2. (b) Für jede aktive Konfiguration sind die folgenden Konvergenzparameter vorgesehen:
      • (1) MX-Konfigurations-ID: Vorhanden, wenn mehrere aktive Konfigurationen vorliegen. Identifiziert die Konfiguration für diese MADP-Instanz-ID.
      • (2) Konvergenzverfahren: Ausgewähltes Konvergenzverfahren (siehe zuvor erörterte und/oder in Anhang C.2.9 von [RFC8743] beschriebene Konvergenzverfahren).
      • (3) Konvergenzverfahrensparameter werden in Anhang C.2.11.1 von [RFC8743] beschrieben.
      • (4) Anzahl von Zustellverbindungen: Die Anzahl der Zustellverbindungen (Zugangsseite), die für diesen Ankeranschluss unterstützt werden.
      • (5) Der Aufbau von Zustellverbindungen wird in Anhang C.2.11.2 von [RFC8743] beschrieben.
  • Konvergenzverfahrensparameter: Dieser Datentyp stellt die für das Konvergenzverfahren verwendeten Parameter dar und enthält Folgendes:
    1. (a) Proxy-IP: IP-ADRESSE des Proxys, die durch das ausgewählte Konvergenzverfahren bereitgestellt wird.
    2. (b) Proxy-Port: Port des Proxys, der durch das ausgewählte Konvergenzverfahren bereitgestellt wird.
  • Aufbau von Zustellverbindungen: Dies ist die Liste der auf dem Client zu konfigurierenden Zustellverbindungen und ihrer Parameter. Jede Zustellverbindung, die durch ihre Verbindungsinformationen definiert wird (siehe z. B. Anhang C.2.4 von [RFC8743]), enthält optional Folgendes:
    1. (a) Anpassungsverfahren: Name des ausgewählten Anpassungsverfahrens. Dies soll eines der in Anhang C.2.10 von [RFC8743] aufgeführten Verfahrenen sein.
    2. (b) Anpassungsverfahrensparameter: Je nach Anpassungsverfahren sollen einer oder mehrere der folgenden Parameter bereitgestellt werden:
      • (1) Tunnelnetzwerkadresse (z. B. IP-Adresse oder dergleichen).
      • (2) Tunnelportadresse.
      • (3) Gemeinsam genutzter Geheimschlüssel.
      • (4) MX-Header-Optimierung: Ist das Anpassungsverfahren UDP_without_DTLS oder UDP_with_DTLS und ist die Konvergenz GMA, so stellt dieses Flag dar, ob das Prüfsummenfeld und das Längenfeld im IP-Header einer MX-PDU durch die MX-Konvergenzschicht neu berechnet werden sollten oder nicht. Die möglichen Werte sind „wahr“ und „falsch“. Bei „wahr“ bleiben beide Felder unverändert, andernfalls sollten beide Felder neu berechnet werden. Falls dieses Feld nicht vorhanden ist, dann sollte die Standardeinstellung „falsch“ in Betracht gezogen werden.
  • Ergebnisse der Init-Sondierung: Dieser Datentyp liefert die Ergebnisse der vom NCM gestellten Init-Sondierungsanforderung. Er besteht aus den folgenden Informationen:
    1. (a) Verlorene Sondierungen: Prozentsatz der verlorenen Sondierungen.
    2. (b) Sondierungsverzögerung: Durchschnittliche Verzögerung der Sondierungsnachricht, in Mikrosekunden.
    3. (c) Sondierungsrate: Erzielte Sondierungsrate, in Megabit pro Sekunde.
  • Ergebnisse aktiver Sondierungen: Dieser Datentyp liefert die Ergebnisse der vom NCM gestellten Anforderung aktiver Sondierungen. Er besteht aus den folgenden Informationen:
    1. (a) Mittlerer Sondierungsdurchsatz: Mittlerer erzielter aktiver Sondierungsdurchsatz, in Megabit pro Sekunde.
  • Downlink-Zustellung: Dieser Datentyp stellt die Liste von Verbindungen dar, die zustellseitig in Downlink-Richtung genutzt werden können.
  • Uplink-Zustellung: Dieser Datentyp stellt die Liste der Verbindungen und Parameter dar, die für die Zustellseite in der UL-Richtung genutzt werden können. Die Uplink-Zustellung besteht aus mehreren Uplink-Zustellentitäten, wobei jede Entität aus einer TFT (siehe z. B. Anhang C.2.16 von [RFC8743]) und einer Liste von Verbindungs-IDs auf dem Uplink besteht, wobei Verkehr, der für solche eine TFT geeignet ist, umgeleitet werden kann.
  • Verkehrsflussvorlage: Die TFT folgt im Allgemeinen den in 3 GPP TS 23.060 v16.0.0 (2019-03-25) angegebenen Richtlinien. Die TFT in MAMS besteht aus einem oder mehreren von Folgendem:
    1. (a) Remote-Adresse und Maske: IP-Adresse und Subnetz für Remote-Adressen, die in der CIDR-Notation (CIDR - Classless Inter Domain Routing) dargestellt sind. Standardeinstellung: „0.0.0.0/0“.
    2. (b) Lokale Adresse und Maske: IP-Adresse und Subnetz für lokale Adressen, die in CIDR-Notation dargestellt sind. Standardeinstellung: „0.0.0.0/0“
    3. (c) Protokolltyp: IP-Protokollnummer der Nutzlast, die von einem IP-Paket (z. B. UDP, TCP) übergetragen wird. Standardeinstellung: 255.
    4. (d) Lokaler Portbereich: Bereich von Ports für lokale Ports, für welche die TFT anwendbar ist. Standardeinstellung: Start = 0, End = 65535.
    5. (e) Remote-Portbereich: Bereich von Ports für Remote-Ports, für welche die TFT anwendbar ist. Standardeinstellung: Start = 0, End = 65535.
    6. (f) Verkehrsklasse: Dargestellt durch Diensttyp in IPv4 und Verkehr Klasse in IPv6. Standardeinstellung: 255
    7. (g) Flow-Label: Flow-Label für IPv6, nur für IPv6-Protokolltyp anwendbar. Standardeinstellung: 0 (siehe z. B. Amante et al., „IPv6 Flow Label Specification“, IETF RFC 6437 (Nov. 2011).
  • Messberichtkonfiguration: Dieser Datentyp stellt die Konfiguration dar, die vom NCM 236 zum CCM 206 zum Melden von Messergebnissen vorgenommen wurde:
    1. (a) Messberichtparameter: Parameter, der gemessen und gemeldet werden soll. Abhängig vom Verbindungstyp:
      • (1) Für den Verbindungstyp von „WiFi“ sind die zulässigen Messtypparameter „WLAN-RSSI“, „WLAN_LOAD“, „UL_TPUT“, „DL_TPUT“, „EST_UL_TPUT“ und „EST_DL_TPUT“.
      • (2) Für den Verbindungstyp von „LTE“ sind die zulässigen Messtypparameter „LTE_RSRP“, „LTE_RSRQ“, „UL_TPUT“ und „DL_TPUT“.
      • (3) Für den Verbindungstyp von „5G_NR“ sind die zulässigen Messtypparameter „NR_RSR“, „NR_RSRQ“, „UL_TPUT“ und „DL_TPUT“.
    2. (b) Schwelle: Hohe und niedrige Schwelle für Meldung.
    3. (c) Zeitraum: Zeitraum für Meldung, in Millisekunden.
  • Messbericht: Dieser Datentyp stellt die vom CCM gemeldeten Messwerte für jedes gemessene Zugangsnetzwerk. Dieser Typ enthält die Verbindungsinformationen, die Zustellknoten-ID, die entweder die Zelle (ECGI) oder die WiFi-Zugangspunkt-ID oder die MAC-Adresse (oder eine äquivalente Kennung in anderen Technologien) identifiziert, und die tatsächliche Messung, die vom CCM in der letzten Messperiode durchgeführt wurde.
  • 1.5. GENERISCHES MEHRFACHZUGANGS-(GMA-) VERKAPSELUNGSPROTOKOLL
  • Wie bereits erwähnt, ist es für MX-Vorrichtungen wünschenswert, die Mehrfachzugangs-Netzwerkverbindungen nahtlos zu kombinieren, um die Erfahrungsqualität zu verbessern. Solch eine Optimierung kann zusätzliche Steuerinformationen, zum Beispiel Folgenummer (SN), in jedem Datenpaket (z. B. IP-Paket) erfordern. Das Verkapselungsprotokoll für generischen Mehrfachzugang (GMA - Generic Multi-Access) [GMA10] ist ein neues schlankes und flexibles Verkapselungsprotokoll für diesen Bedarf.
  • Wieder unter Bezugnahme auf 1 ist die Konvergenz-(Teil-)Schicht im MAMS-DPPS für Mehrfachzugangsoperationen zuständig, einschließlich Multilink-(Pfad-)Aggregation, Aufteilen/Neuordnen, verlustloses Schalten/Neuübertragen, Fragmentieren, Verketten usw. Sie arbeitet auf der Anpassungs-(Teil-)Schicht im Protokollstapel 102, 142. Aus der Tx-Perspektive wird eine Benutzer-Nutzlast (z. B. IP-Paket) zuerst von der Konvergenzschicht und dann von der Anpassungsschicht verarbeitet, bevor sie über eine Zustellverbindung transportiert wird; aus der Empfänger-Perspektive wird ein IP-Paket, das über eine Zustellverbindung empfangen wird, zuerst von der Anpassungsschicht und dann von der Konvergenzschicht verarbeitet.
  • Heutzutage wird Generic Routing Encapsulation (GRE) als das Verkapselungsprotokoll auf der Konvergenzschicht zum Codieren zusätzlicher Steuerinformationen (z. B. Schlüssel, Folgenummer) verwendet (siehe z. B. 3GPP TS 36.361 v15.0.0 (2018-07-09) („[LWIPEP]“), Dommety, G., „Key and Sequence Number Extensions to GRE“, IETF RFC 2890, (September 2000) („[GRE1]“), und Leymann et al., „Huawei 's GRE Tunnel Bonding Protocol“, IETF RFC 8157 (Mai 2017) („[GRE2]“). Es gibt jedoch zwei Hauptnachteile bei diesem Ansatz, die zum Beispiel umfassen, dass IP-über-IP-Tunneln (erforderlich für GRE) insbesondere für kleine Pakete zu höherem Overhead führt; und es schwierig ist, neue Steuerfelder einzuführen. Zum Beispiel beträgt der Overhead des IP-über-IP/GRE-Tunnelns sowohl mit Schlüssel als auch Folgenummer 32 Bytes (20 Bytes IP-Header + 12 Bytes GRE-Header), was 80 % eines 40-Byte-TCP-ACK-Pakets ausmacht.
  • Auf der Konvergenzschicht wird das GMA-Verkapselungsprotokoll implementiert. GMA unterstützt drei Verkapselungsverfahren/-formate: Trailer-basierte IP-Verkapselung, Header-basierte IP-Verkapselung und Nicht-IP-Verkapselung. Insbesondere vermeiden die IP-Verkapselungsverfahren IP-über-IP-Tunnel-Overhead (z. B. 20 Bytes), der 50 % eines 40-Byte-TCP-ACK-Pakets ausmacht. Darüber hinaus führt GMA neue Steuerfelder ein, um Fragmentierung und Verkettung zu unterstützen, die in herkömmlichen GRE-basierten Lösungen, wie etwa in [LWIPEP], [GRE1] und [GRE2], nicht verfügbar sind.
  • GMA arbeitet zwischen Endpunkten, die zum Arbeiten mit GMA durch zusätzliche Steuernachrichten und -prozeduren konfiguriert wurden (siehe z. B. [RFC8743]). Darüber hinaus kann UDP- oder IPSec-Tunneln auf der Anpassungsteilschicht verwendet werden, um den GMA-Betrieb vor Zwischenknoten (z. B. Zugangsknoten, Edge-Knoten usw.) zu schützen.
  • Wie in 1 gezeigt, kann eine Client-Vorrichtung 101 (z. B. ein Smartphone, Laptop, IoT-Vorrichtung usw.) über Mehrfachzugangs-Netzwerkverbindungen 105 eine Verbindung mit dem Internet herstellen. Eine dieser Verbindungen (z. B. Verbindung 105A) kann als Ankerverbindung fungieren, und die andere Verbindung (z. B. Verbindung 105B) kann als Zustellverbindung fungieren. Die Ankerverbindung stellt die Netzwerkadresse (z. B. IP-Adresse oder dergleichen) und Konnektivität für Ende-zu-Ende-(e2e-)Internetzugang bereit, und die Zustellverbindung stellt einen zusätzlichen Pfad zwischen dem Client 101 und dem MX-Gateway (z. B. MX-Server 140) für Mehrfachzugangsoptimierungen bereit. Bei einigen Implementierungen kann die Ankerverbindung, wenn GMA verwendet wird, eine virtuelle IP-Verbindung ähnlich der sein, die in einem VPN verwendet wird, und es kann bis zu zwei gleichzeitige Zustellverbindungen (z. B. 5G/NR, LTE, WiFi usw.) geben, von denen jede einen dedizierten UDP-Tunnel aufweist, der zur Datenübertragung aufgebaut ist.
  • Zum Beispiel ermöglicht Pro-Paket-Aggregation, dass ein einziger IP-Fluss die kombinierte Bandbreite der zwei Verbindungen verwendet. Bei einem anderen Beispiel können Pakete, die aufgrund eines temporären Verbindungsausfalls verloren gehen, erneut übertragen werden. Darüber hinaus können Pakete über mehrere Verbindungen dupliziert werden, um eine hohe Zuverlässigkeit und niedrige Latenz zu erreichen, und duplizierte Pakete sollten von der Empfangsseite eliminiert werden. Solch eine Mehrfachzugangsoptimierung erfordert zusätzliche Steuerinformationen (z. B. SN) in jedem IP-Datenpaket, die durch das hierin und/oder in [GMA10] beschriebene GMA-Verkapselungsprotokoll unterstützt werden können.
  • GMA wird üblicherweise verwendet, wenn mehrere Zugangsnetzwerkverbindungen verwendet werden, kann aber auch verwendet werden, wenn nur eine einzige Zugangsnetzwerkverbindung verwendet wird. In diesen Szenarien kann GMA für Verlustdetektions- und Wiederherstellungszwecke genutzt oder, zum Verketten mehrerer kleiner Pakete verwendet werden, um Pro-Paket-Overhead/-Ressourcenverbrauch zu reduzieren.
  • 14 stellt eine E2E-Netzwerkreferenzarchitektur mit OTT-GMA 1400 dar. In 14 umfasst der MA-Client 101 den CCM 206, der eine Steuerebenen-Funktionsentität im Client 101 ist, die MAMS-Steuernachrichten mit dem NCM 236 austauscht und mehrere Netzwerkpfade am Client zum Transport von Benutzerdaten konfiguriert. Der CCM 206 ist kommunikativ mit einem GMA-Client (Gc) 1401 im MA-Client 101 gekoppelt.
  • Der Gc 1401 ist eine Datenebenen-Funktionsentität im Client 101, die Benutzerdatenweiterleitung über mehrere Netzwerkpfade 105 und MA-Konvergenzoperationen (z. B. Aufteilen, Lenken, Duplizieren, Messen usw.) abwickelt. Der Gc 1401 betreibt seinen eigenen GMA-Protokollstapel, der die GMA-Datenebenenschicht umfasst, die sich auf jeweiligen Transportschichten Tms-1 und Tms-2 (z. B. TCP, UDP usw.) befindet, die sich auf jeweiligen Netzwerkschichten Net-1 und Net-2 (z. B. IP oder dergleichen) befinden. Die jeweiligen Netzwerkschichten interagieren mit jeweiligen Zugangsschichtentitäten RAT-1 und RAT-2. In diesem Beispiel ist RAT-A eine WiFi-Station (STA), und RAT-B ist ein LTE-UE.
  • Der MA-Server 140 umfasst den NCM 236, der eine Steuerebenen-Funktionsentität im Netzwerk ist, die MAMS-Steuernachrichten vom Client 101 verarbeitet und eine Verteilung von Datenpaketen über mehrere Netzwerkpfade und Benutzerebenenbehandlung der Verkehrsflüsse konfiguriert. Der NCM 236 ist kommunikativ mit einem GMA-Server (Gs) 1440 im MA-Server 140 gekoppelt. Die Gs 1440 ist eine Datenebenen-Funktionsentität im Netzwerk, die Benutzerdatenweiterleitung über mehrere Netzwerkpfade 107 und MA-Konvergenzoperationen (z. B. Aufteilen, Lenken, Duplizieren, Messen usw.) abwickelt. Der Gs 1440 umfasst einen GMA-Protokollstapel, der gleich oder ähnlich dem GMA-Protokollstapel im Gc 1401 ist. Außerdem können der MA-Server 140 und insbesondere der Gs 1440 kommunikativ mit einem NAT/Firewall-Gateway 1450 gekoppelt sein. Das NAT/Firewall-Gateway 1450 kann zwischen dem MA-Server 140 und einem DN 170, 175 (z. B. dem Internet, einem Unternehmensnetzwerk, einem Lokalbereichs-DN und/oder dergleichen) angeordnet sein.
  • Eine WebSocket-basierte (z. B. TCP, UDP usw.) sichere Verbindung wird zwischen dem CCM 206 und dem NCM 236 hergestellt, um MAMS-Verwaltungsnachrichten 1430 auszutauschen, die zum Konfigurieren der Datenebenenfunktionen (z. B. Gc 1401 und Gs 1440) verwendet werden. Die MAMS-Verwaltungsnachrichten 1430 werden im Folgenden ausführlicher erörtert.
  • In einem GMA-System 1400 gibt es zwei Typen von Verbindungen: Ankerverbindungen und Zustellverbindungen. Eine Ankerverbindung ist eine IP-Verbindung, die von Applikationen für e2e-Datentransfer verwendet wird. Eine Zustellverbindung ist eine Netzwerkverbindung (z. B. IP-Verbindung), die zum Zustellen von Benutzerdaten zwischen dem Gc 1401 und dem Gs 1440 verwendet wird. Die Ankerverbindung im OTA-GMA-System 1400 ist eine virtuelle Netzwerk-(z. B. IP-)Verbindung, die ähnlich ist wie die, die in virtuellen privaten Netzwerken (VPNs) verwendet wird. Bei einigen Implementierungen kann es bis zu zwei gleichzeitige Zustellverbindungen (z. B. 5G/NR, LTE, WiFi usw.) geben, von denen jede einen dedizierten Tunnel (z. B. UDP-Tunnel oder dergleichen) aufweist, der zur Datenübertragung eingerichtet ist.
  • Der Gc 1401 und/oder der Gs 1440 wählen die Zustellverbindung für MAMS-Nachrichten basierend auf einem aktuellen Zustand des Gc 1401 und/oder des Gs 1440 aus, was eines oder mehreres von Folgendem umfassen kann: Senden aller MAMS-Nachrichten über eine erste (bevorzugte) Zustellverbindung (z. B. WiFi) in Zustand 1 oder 3 (siehe z. B. 16); und Senden aller MAMS-Nachrichten über die zweite Zustellverbindung (z. B. zellenbasiert) in Zustand 2 oder 4 (siehe z. B. 16).
  • Bei einer beispielhaften Implementierung ist das NAN 111 A eine zellulare Basisstation, wie etwa ein 5G/NR-GNB, ein LTE-eNB und/oder dergleichen, und das GW 1420A umfasst einen oder mehrere Server, die als ein Evolved Packet Core (EPC) für LTE-Implementierungen oder ein 5G-System (5GS)/5G-Kernnetzwerk (5GC) für 5g/NR-Implementierungen arbeiten. Bei dieser beispielhaften Implementierung betreiben der eine oder die mehreren Server eine oder mehrere Netzwerkfunktionen (NFs), wie etwa eine UPF in 5G/NR-Implementierungen, ein bedienendes Gateway (S-GW) und/oder ein Paketdatennetzwerk-Gateway (P-GW) in LTE-Implementierungen oder dergleichen. Bei dieser beispielhaften Implementierung ist die Verbindung 106A ein/e N3-Referenzpunkt/-Schnittstelle für 5G/NR-Implementierungen oder ein/e S1-Referenzpunkt/- Schnittstelle für LTE-Implementierungen, und die Verbindung 107 A ist ein/e N6-Referenzpunkt/- Schnittstelle für 5G/NR-Implementierungen oder ein/e SGi-Referenzpunkt/-Schnittstelle für LTE-Implementierungen.
  • Bei einer anderen beispielhaften Implementierung (die mit der zuvor beschriebenen beispielhaften Implementierung kombiniert werden kann) ist das NAN 111B ein WLAN-Zugangspunkt (AP), wie etwa ein WiFi-AP, und das GW 1420B umfasst einen oder mehrere Server und/oder Netzwerkelemente, die als ein WLAN-(WiFi-)Zugangs-Gateway (WAG), ein Breitbandnetzwerk-Gateway (BNG) und/oder dergleichen arbeiten. Bei dieser beispielhaften Implementierung können sowohl die Verbindung 106B als auch die Verbindung 107B eine geeignete Tunnelschnittstelle/-verbindung sein, wie etwa ein GRE-Tunnel, ein Tunnel eines Tunnelprotokolls (GTP - GPRS Tunneling Protocol) des allgemeinen paketvermittelten Funkdienstes (GPRS - General Packet Radio Service), Mobile-IP (MIP), ein PMIP-Tunnel (PMIP - Proxy MIP), VPN-Tunnel und/oder dergleichen. Die Verbindung 106B und die Verbindung 107B können dieselben oder unterschiedliche Tunnelprotokolle und/oder Kommunikationstechnologien nutzen.
  • 15 zeigt Funktionalitäten einer GMA-Datenebenenentität 1500. Die GMA-Datenebenenentität 1500 entspricht dem Gs 1440 und/oder dem Gc 1401, die zuvor mit Bezug auf 14 erörtert wurden (oder sie entspricht der GMA-Datenebenenschicht innerhalb des Gs 1440 und/oder des Gc 1401). Die GMA-Datenebene fungiert dabei als generische Konvergenzschicht für ein beliebiges (Funk-)Zugangsnetzwerk und/oder eine beliebige (Funk-)Zugangstechnologie. Die GMA-Datenebenenentität 1500 führt verschiedene Funktionen durch, wie etwa Pfadqualitätsmessungen (QoS, Paketverlust, Latenz usw.), Multilink-Verkehrslenkung (z. B. Verkehrsaufteilung/-lenkung, Neuordnung, Neuübertragung, Duplizierung, Codierung, Fragmentierung, Verkettung usw.) und QoS-bewusste Verkehrsformung und Warteschlangenbildung (z. B. Prioritätswarteschlange (PQ), Strict Priority (SP), gewichtete Zeitscheibe (WRR - Weighted Round Robin) usw.).
  • Die GMA-Datenebenenentität 1500 an einem GMA-Tx bereitet Verkehr (z. B. IP, TCP, UDP usw.) zur Übertragung an einen GMA-Rx vor. Der GMA-Tx stellt Folgenummern für Pakete bereit, führt eine Fluss-(Verkehrs-)Aufteilung, wobei Pakete aufgeteilt oder an verschiedene Mehrfachzugangsnetzwerke (oder RATs) verteilt werden, gleichzeitig zur Zustellung an den GMA-Rx durch. Der GMA-Tx führt auch Verkettung durch, was das Platzieren mehrerer SDUs in einer PDU umfasst, um Paketverarbeitungs- und Tunnel-Overhead zu reduzieren, wodurch die Signalisierungs- und Verarbeitungseffizienz verbessert wird. Der GMA-Tx fügt außerdem einen GMA-Header oder -Trailer zu dem/den Paket(en) hinzu und führt Tunneln durch, indem das Paket zum Beispiel gemäß einem geeigneten GMA-Tunnelprotokoll neu verpackt wird. Das Paket bzw. die Pakete werden dann über ein geeignetes Zugangsnetzwerk (z. B. eines der verschiedenen (R)ANs/eine der verschiedenen (R)ATs, die hier erörtert werden) übertragen.
  • Der GMA-Rx empfängt das Paket bzw. die Pakete, entpackt das Paket bzw. die Pakete gemäß dem verwendeten Tunnelprotokoll und entfernt den GMA-Header/-Trailer. Der GMA-Rx setzt das oder die Pakete, die über Mehrfachzugangsnetze geliefert werden, basierend auf den Folgenummern, die vom GMA-Tx bereitgestellt werden, wieder zusammen und ordnet sie neu. Der GMA-Rx führt dann Duplikaterkennung durch, um Pakete zu identifizieren (und zu verwerfen) und zu duplizieren, und liefert dann der Reihe nach das/die wieder zusammengesetzte(n) und neu geordnete(n) Paket(e) an höhere Schichten.
  • Zusätzlich oder alternativ dazu stellt die GMA-Datenebenenentität 1500 verlustloses Schalten bereit, was die Neuübertragung und/oder Wiederherstellung von Paketen einbezieht, die verloren gehen können, wenn von einem Netzwerkzugangspfad auf einen anderen Netzwerkzugangspfad umgeschaltet wird. Zusätzlich oder alternativ führt die GMA-Datenebenenentität 1500 Pfadqualitätsmessungen, die passive und aktive Messungen von QoS-Parametern, wie beispielsweise Paketverlustrate, Umlaufzeit, unter vielen anderen umfassen (wie etwa die verschiedenen hierin erörterten Messungen), durch oder stellt solche bereit. Zusätzlich oder alternativ führt die GMA-Datenebenenentität 1500 andere Funktionen durch, wie etwa ARQähnliche Neuübertragung (ARQ - Automatic Repeat Request), Duplizierung, Netzwerkcodierung, Verkehrsformung/Warteschlangenbildung und/oder dergleichen.
  • 16 veranschaulicht eine clientbasierte GMA-Datenverkehrssteuerungs-Zustandsmaschine 1600. Die Datenverkehrssteuerungs-Zustandsmaschine 1600 umfasst die folgenden Zustände:
    • Zustand 0 (Ruhe): Die virtuelle (Anker-)Verbindung ist inaktiv.
    • Zustand 1 (nur RAT1): Der gesamte Datenverkehr (DL und UL) wird über die erste (bevorzugte) RAT-Verbindung (RAT1) geliefert.
    • Zustand 2 (nur RAT2): Der gesamte Datenverkehr wird über die zweite Verbindung
    • (RAT2) geliefert.
    • Zustand 3 (DL über RAT1 u. RAT2, UL über RAT2): DL-Verkehr wird über beide Verbindungen geliefert werden und UL-Verkehr über die zweite Verbindung (RAT2) geliefert wird.
  • Die Datenverkehrssteuerungs-Zustandsmaschine 1600 umfasst die folgenden Zustandsübergangsauslöser:
    • (1) Die virtuelle (Anker-)Verbindung wird erfolgreich hergestellt. Dieser Auslöser bewirkt einen Übergang vom Zustand 0 in den Zustand 1.
    • (2) Überlastung wird über den RAT1-DL detektiert, und RAT2-Verbindungserfolg wurde deklariert/detektiert, wobei die letzte Steuernachricht über RAT2 erfolgreich war. Dieser Auslöser bewirkt einen Übergang vom Zustand 1 in den Zustand 3. Bei einigen Implementierungen ist eine Überlastungsdetektion (basierend auf Paketverlust) nur anwendbar, falls das RAT1-Überlastungsdetektionsflag deaktiviert ist.
    • (3) Überlastung ist über die RAT1-DL nicht mehr vorhanden (trifft nur zu, wenn das RAT1-Überlastungserkennungsflag deaktiviert ist). Dieser Auslöser bewirkt einen Übergang vom Zustand 3 in den Zustand 1.
    • (4) Die RAT1-Empfangssignalqualität (oder Empfangssignalstärke) ist relativ schlecht (z. B. < -75 Dezibel-Milliwatt (dBm)), und/oder RAT1 hat einen Verbindungsausfall (oder Funkverbindungsausfall (RLF - Radio Link Failure)) deklariert oder detektiert. Der jeweilige Mechanismus zum Detektieren und/oder Deklarieren eines Verbindungsausfalls (oder RLF) ist durch die Standards/Spezifikationen von RAT1 definiert. Dieser Auslöser bewirkt einen Übergang vom Zustand 1 in den Zustand 2 oder einen Übergang vom Zustand 3 in den Zustand 2.
    • (5) Der GMA/MAMS-Betrieb wird beendet oder unterbrochen. Die Beendigung des GMA/MAMS-Betriebs kann umfassen, dass eine Zustellverbindung (RAT2 oder RAT1) für einen vordefinierten Zeitraum (z. B. 10 Minuten oder eine andere Zeitdauer) ausfällt und/oder der Gesamtdurchsatz relativ niedrig ist (z. B. < 10 Kilobit pro Sekunde (Kbit/s)). Ein unterbrochener GMA/MAMS-Betrieb kann umfassen, dass ein Bildschirm ausgeschaltet ist und/oder der Gesamtdurchsatz niedrig ist (z. B. < 10 Kbit/s). Dieser Auslöser bewirkt einen Übergang vom Zustand 1 in den Zustand 0 oder einen Übergang vom Zustand 2 in den Zustand 1.
    • (6) Die RAT1-Empfangssignalqualität ist relativ gut (z. B. >-70 dBm), und RAT1 hat einen Verbindungserfolg detektiert/deklariert. Dieser Auslöser bewirkt einen Übergang vom Zustand 2 in den Zustand 3.
    • (7) RAT2 hat einen Verbindungsausfall (oder RLF) detektiert/deklariert. Der jeweilige Mechanismus zum Detektieren und/oder Deklarieren eines Verbindungsausfalls (oder RLF) ist durch die Standards/Spezifikationen von RAT2 definiert. Dieser Auslöser bewirkt einen Übergang vom Zustand 3 in den Zustand 1 oder einen Übergang vom Zustand 2 in den Zustand 0.
  • Falls eine Verbindung als „Link Failure“ (Verbindungsausfall) deklariert wird, sollte sie mit Ausnahme von „Probe/ACK“ nicht zum Senden von Daten- oder Steuerpakete verwendet werden, und der „Link Failure“-Status kann nur nach erfolgreichem Senden einer Sondierungsnachricht über die Verbindung ausgeschaltet werden.
  • Für den Datenverkehr werden folgende drei Flüsse definiert:
    • Hohe Zuverlässigkeit (Fluss-ID = 1): Verkehr mit hoher Zuverlässigkeit wird durch Duplizierung sowohl über RAT1 als auch RAT2 in Zustand 1, 2 und 3 geliefert. Es ist anzumerken, dass der Empfänger für das Detektieren und Entfernen von duplizierten Paketen basierend auf ihrer Folgenummer (unter Verwendung des in 6.6.1 definierten Algorithmus) verantwortlich ist. Es ist anzumerken, dass ein Fluss mit hoher Zuverlässigkeit eine niedrige Datenrate (z. B. < 1 Mbit/s) aufweisen sollte.
    • Verzögerungsempfindlich (Fluss-ID = 2): Verzögerungsempfindlicher Verkehr wird nur in Zustand 1, 2 und 3 über RAT2 geliefert.
    • Hoher Durchsatz (Fluss-ID = 3): Verkehr mit hohem Durchsatz (z. B. DL) wird durch Aggregation sowohl über RAT1 als auch RAT2 in Zustand 3 geliefert, und der Empfänger (Gc) ist für das Neuordnen von Paketen unter Verwendung eines Algorithmus verantwortlich, der in 6.6.1 oder 6.6.2 definiert ist. UL-Verkehr wird von RAT1 in Zustand 1 und von RAT2 in Zustand 2 geliefert. In Zustand 3 wird UL-Verkehr durch RAT2 geliefert, falls das „UL-over-RAT2-Flag“ auf „1“ gesetzt ist, und andernfalls durch RAT1. Die Standardeinstellung von „UL-over-RAT2-Flag“ ist 0 (deaktiviert).
  • Im Beispiel von 16 kann RAT1 eine WLAN-RAT (z. B. WiFi) sein, und RAT2 kann eine zellenbasierte RAT (z. B. 5G/NR, LTE, GSM, GPRS, WiMAX usw.) sein. Die spezifischen RAT-Protokolle können die Mechanismen und/oder Parameter zum Bestimmen von Verbindungsfehlern und/oder Verbindungserfolgen definieren.
  • 17 stellt einen beispielhaften GMA-Konvergenzsteuerprotokollstapel 1700 c dar. Der GMA-Konvergenzsteuerungsprotokollstapel 1700 c umfasst eine GMA-Konvergenzsteuerungsschicht, die GMA/MAMS-Steuernachrichten umfasst. Zusätzlich wird ein dritter Transportschichttunnel (z. B. UDP- oder IP-Sicherheitsprotokoll (IPSec)) über eine virtuelle (Anker-)IP-Verbindung (IP-3) zum Senden von zeitempfindlichen Steuernachrichten (z. B. Sondierungen, Verkehrsaufteilungsaktualisierungen usw.) aufgebaut.
  • Die virtuelle (Anker-)IP-Verbindung befindet sich auf einer GMA-Konvergenzschicht (auch als „GMA-Verkapselungsschicht“ bezeichnet). Dies ermöglicht, dass die (virtuellen) IP-Pakete, die GMA-Steuernachricht(en) mitführen, mit einem GMA-Header verkapselt werden, der nur ein 2-B-Flag-Feld (im Folgenden erörtert) umfasst, wobei das Flag-Feld auf alles „0“-en gesetzt ist. Die GMA-Verkapselungsschicht befindet sich auf j eweiligen Transporttunnelschichten (z. B. UDP oder IPSec) für jeweilige Zugangsnetzwerke (ANs) 1 und 2, die sich auf jeweiligen IP-Schichten befinden, die sich auf Schicht 2 (L2) und Schicht 1 (L1) der jeweiligen ANs 1 und 2 befinden. Die Ankerverbindung ist nun virtuell und nicht mehr an ein spezifisches Zugangsnetzwerk (z. B. AN1 und AN2 im Beispiel der 17) gebunden.
  • 17 zeigt außerdem einen beispielhaften GMA-Konvergenzdatenprotokollstapel 1700d. Der GMA-Konvergenzdatenprotokollstapel 1700d ähnelt dem GMA-Konvergenzdatenprotokollstapel 1700c mit der Ausnahme, dass die GMA-Konvergenzsteuerschicht im Stapel 1700c durch eine Anwendungsschicht ersetzt ist.
  • In beiden Stapeln, Stapel 1700c, Stapel 1700d, wird eine neue Protokollschicht, die GMA-Konvergenzschicht (auch als Trailer-basierte MAMS-Konvergenz-[UPMAMS-]Schicht bezeichnet) eingeführt, um alle Operationen in Bezug auf Mehrwege(-Verwaltung) (z. B. Verkettung, Aufteilung, Neuordnung, Duplikation, Eliminierung, Messungen usw.) zu handhaben. Bei einigen Implementierungen verkapselt die GMA-Konvergenzschicht die Daten- und/oder Steuernachrichten unter Verwendung eines GMA-Header-basierten Verkapselungsformats, das verwendet wird, wie in 18 gezeigt ist. Das GMA-Konvergenzverkapselungsprotokoll wird in [GMA10] erörtert. Wenn ein Zugangsnetzwerk 110 keine MAMS-Netzwerkfunktionen unterstützt, wird die virtuelle Verbindung zwischen einer Endvorricht8ung (z. B. Client-Vorrichtung 101) und einem Cloud-Server oder Edge-Server hergestellt. Diese virtuelle Verbindung kann dann als Ankerverbindung für Cloud-Anwendungen oder Edge-Anwendungen verwendet werden. Bei den virtuellen Ankerverbindungen kann es sich um eine IP-Verbindung handeln, die von Anwendungen zur e2e-Datenübertragung genutzt wird. Die anderen Verbindungen (z. B. Zustellverbindungen) von AN1 und AN2 können IP-Verbindungen zum Zustellen von Benutzerdaten zwischen dem Client und dem Server sein. Zusätzlich können die bestehenden MAMS-Konvergenzteilschichtfunktionalitäten [UPMAMS] so wiederverwendet werden, wie sie sind. Zusätzlich oder alternativ dazu wird die virtuelle (Anker-)Verbindung zum Senden von zeitempfindlichen MAMS-Steuer-/Verwaltungsnachrichten (z. B. Sondierungen, Verkehrsaufteilungsaktualisierungen usw.) hergestellt. Die (virtuellen) Pakete, die GMA-Steuer-/Verwaltungsnachrichten mitführen, werden ebenfalls mit dem GMA-Header verkapselt, was auch im Folgenden ausführlicher erörtert wird.
  • 18 stellt ein Format einer GMA-Konvergenzprotokolldateneinheit (PDU) 1800 dar. Die PDU 1800 umfasst einen GMA-Header und ein IP-Paket. Der GMA-Header wird im Folgenden ausführlicher erörtert. In diesem Beispiel umfasst die PDU 1800 ein Flag-Feld (2 Bits (B), ein Client-ID-Feld (2 B), ein Fluss-ID-Feld (1 B), ein PPP-Feld (PPP - Per Packet Priority) (1 B), ein SN-Feld (SN - Folgenummer) (4 B) und ein Zeitstempelfeld (4 B) wie folgt, wobei Bit 0 das höchstwertige Bit (MSB - Most Significant Bit) ist, und Bit 15 das niedrigstwertige Bit (LSB - Least Significant Bit) ist:
    • • Bit Nr. 0 (MSB): Client-ID
    • • Bit Nr. 1: Fluss-ID
    • • Bit Nr. 2: PPP (Pro-Paket-Priorität)
    • • Bit Nr. 3: Folgenummer (B0: L-SN, B1-B3: G-SN).
    • • Bit Nr. 4: Zeitstempel
    • • Bit Nr. 13 - 15: GMA-Protokoll (z. B. „0x07“)
  • Das B0 des SN-Feldes ist ein L-SN-(Teil-)Feld, und bei B1-B3 des SN-Feldes ist ein G-SN-(Teil-)Feld. Die G-SN dient zur Neuordnung und die L-SN dient zur Paketverlustmessung.
  • Das (2-B-)Flag-Feld gibt an, welche zusätzlichen Felder im GMA-Header enthalten sind. Die folgenden Bits im Flag-Feld können einen ersten Wert, falls das Paket 1800 Downlink-Daten (z. B. „0xF807“) mitführt, einen zweiten Wert, falls das Paket Uplink-Daten mitführt (z. B. „0x7807“), einen dritten Wert, falls das Paket 1800 eine verschlüsselte Steuernachricht mitführt (z. B. „0x800F“), oder einen vierten Wert aufweisen, falls das Paket 1800 eine unverschlüsselte Steuernachricht mitführt (z. B. „0x0000“). Zusätzlich oder alternativ dazu ist, falls das Paket 1800 Uplink-Daten mitführt, das „Client-ID“-Feld nicht im GMA-Header enthalten. Zusätzlich oder alternativ dazu kann das Paket 1800, falls es eine verschlüsselte Steuernachrichtmitführt, die folgenden Felder umfassen:
    • • Bit Nr. 0 (MSB): Client-ID
    • • Bit Nr. 12: Verschlüsselung aktiviert
    • • Bit Nr. 13 ∼ 15: GMA-Protokoll (z. B. „0x07“).
  • Wie in den 3, 17 und 18 dargestellt, gibt es drei verschiedene Netzwerkadressen (z. B. IP-Adressen) und drei Transportverbindungen (z. B. UDP, TCP usw.) für jeden Client in einem GMA-System. Die Netzwerkadresse (z. B. IP-Adresse) jeder Zustellverbindung auf dem Client wird durch ein jeweiliges Zugangsnetzwerk konfiguriert. Alle anderen Netzwerkadressen (z. B. IP-Adresse) und Transportports (z. B. UDP, TCP-Ports oder dergleichen) werden im GMA-System entweder durch Client-Konfiguration oder MAMS-Nachrichten konfiguriert.
  • 1.5.1. GMA-VERKAPSELUNGSVERFAHREN UND -FORMATE
  • Das GMA-Verkapselungsprotokoll unterstützt die folgenden drei Verfahren: Trailer-basierte IP-Verkapselung; Header-basierte IP-Verkapselung; und (Header-basierte) Nicht-IP-Verkapselung. Solange es die Implementierung zulässt, sollte eine Trailer-basierte IP-Verkapselung verwendet werden. Eine Header-basierte Verkapselung sollte verwendet werden, falls eine Trailer-basierte Verkapselung aus irgendeinem Grund (z. B. Implementierungsbedingungen) nicht durchführbar ist. In diesem Fall sollte, falls die Anpassungsschicht (z. B. UDP-Tunneln) das Nicht-IP-Paketformat unterstützt, eine Header-basierte Nicht-IP-Verkapselung verwendet werden; ansonsten sollte eine Header-basierte IP-Verkapselung verwendet werden.
  • Wenn Nicht-IP-Verkapselung konfiguriert ist, sollte in jedem Paket immer ein GMA-Header vorhanden sein. Falls dagegen IP-Verkapselung konfiguriert ist, kann der GMA-Header oder -Trailer dynamisch paketweise hinzugefügt werden und gibt das Vorhandensein des GMA-Headers (oder -Trailers) an, um den Protokolltyp der GMA-PDU auf „114“ zu setzen.
  • Die GMA-Endpunkte können das Verkapselungsverfahren durch Steuersignalisierung (siehe z. B. 2) oder Vorkonfiguration konfigurieren. Zum Beispiel umfasst eine Nachricht „MX UP Setup Configuration Request“ (MX-UP-Setup-Konfigurationsanforderung), wie in [RFC8743] erörtert, die „MX Convergence Method Parameters“ (MX-Konvergenzverfahrensparameter), was die Liste von Parametern zum Konfigurieren der Konvergenzschicht bereitstellt, und kann erweitert werden, um das GMA-Verkapselungsverfahren anzugeben. Ein Parameter „GMA-Verkapselungsformat“ kann enthalten sein, um eines der drei GMA-Verkapselungsverfahren anzugeben.
  • 19 zeigt verschiedene Formate einer GMA-Protokolldateneinheit (PDU), die ein GMA-PDU-Format mit Trailer-basierter IP-Verkapselung 1901, ein GMA-PDU-Format mit Header-basierter IP-Verkapselung 1902 und ein GMA-PDU-Format mit Nicht-IP-Kapselung 1903 umfassen. Jede GMA-PDU kann (unabhängig vom jeweiligen verwendeten Format) ein oder mehrere IP-Pakete (auch als (GMA-)Dienstdateneinheiten (SDU - Service Data Unit) bezeichnet) oder ein Fragment eines IP-Pakets (oder (GMA-)SDU-Fragment) im Nutzlastabschnitt der PDU mitführen.
  • Die GMA-PDU 1901 weist einen IP-Header, IP-Nutzlast und einen GMA-Trailer 1910 auf. Die anderen GMA-PDUs 1902 und 1903 weisen einen GMA-Header 420 anstelle des GMA-Trailers 1910 auf. Der GMA-Trailer 1910 und der GMA-Header 1920 umfassen verschiedene GMA-Steuerfelder. Üblicherweise wird die Träger-basierte IP-Verkapselungs-GMA-PDU 1901 verwendet, solange eine Implementierung es erlaubt/zulässt. Die Header-basierten Verkapselungs-PDUs 1902 und 1903 können jedoch verwendet werden, falls die GMA-Steuerfelder am Ende der Pakete nicht hinzugefügt werden können.
  • 1.5.1.1. TRAILER-BASIERTE IP-VERKAPSELUNG
  • Für die Trailer-basierte GMA-PDU 1901 wird das Protokolltyp-Feld im IP-Header auf „114“ (ein beliebiges 0-Hop-Protokoll) geändert, um das Vorhandensein des GMA-Trailers 1910 anzugeben.
  • Ist das ursprüngliche IP-Paket IPv4, so können die folgenden drei IP-Header-Felder geändert werden:
    • • IP-Länge-Feld - Hinzufügen der Länge des „GMA-Trailers“ zur Länge des ursprünglichen IP-Pakets;
    • • Time to Live (TTL) - Setzen des TTL-Feldes auf „1“;
    • • IP-Prüfsummenfeld - IP-Prüfsumme nach Ändern des Feldes „Protokolltyp“, „TTL“ und „IP-Länge“ neu berechnen.
  • Ist das ursprüngliche IP-Paket Ipv6, so können die folgenden beiden IP-Header-Felder geändert werden:
    • • IP-Länge-Feld - Hinzufügen der Länge des „GMA-Trailers“ zur Länge des ursprünglichen IP-Pakets;
    • • Hop-Limit-(HL-)Feld - Setzen des HL-Feldes auf „0“.
  • Falls UDP-Tunneln an der Anpassungsschicht verwendet wird, um die GMA-PDU 1901, 1902 oder 1903 zu übertragen, können diese drei IP-Header-Felder unverändert bleiben und der Rx bestimmt die GMA-PDU-Länge basierend auf der UDP-Paketlänge.
  • 19 zeigt außerdem ein beispielhaftes Format des GMA-Trailers 1910, welches verschiedene vorhandene Steuerfelder zeigt. Der GMA-Trailer 1910 umfasst ein oder mehrere obligatorische Felder und null oder mehrere optionale Felder. Die obligatorischen Felder umfassen das Feld „Flags“ und das Feld „Nächster Header“, die die letzten 3 Bytes des GMA-Trailers 1910 sind. Das Nächster-Header-Feld (1 Byte) gibt den IP-Protokolltyp der (ersten) SDU in einer PDU an und speichert den Wert vor seinem Überschreiben in „114“. Für das Flags-Feld (2 Bytes) ist Bit 0 das höchstwertige Bit (MSB), und Bit 15 ist das niedrigstwertige Bit (LSB). Das Flags-Feld umfasst folgende Felder: Prüfsumme vorhanden (Bit 0): Falls das Prüfsummen-vorhanden-Bit auf 1 gesetzt ist, dann ist das Prüfsummenfeld vorhanden; Verkettung vorhanden (Bit 1): Falls das Verkettung-vorhanden-Bit auf 1 gesetzt ist, dann führt die PDU mehrere SDUs mit, und das erste SDU-Länge-Feld ist vorhanden; Verbindungs-ID vorhanden (Bit 2): Falls das Verbindungs-ID-vorhanden-Bit auf 1 gesetzt ist, dann ist das Verbindungs-ID-Feld vorhanden; Fluss-ID vorhanden (Bit 3): Falls das Fluss-ID-vorhanden-Bit auf 1 gesetzt ist, dann ist das Fluss-ID-Feld vorhanden; Fragmentierung vorhanden (Bit 4): Falls das Fragmentierung-vorhanden-Bit auf 1 gesetzt ist, dann führt die PDU ein Fragment der SDU mit, und das Fragmentierungssteuerfeld ist vorhanden; Zustell-SN vorhanden (Bit 5): Falls das Zustell-Folgenummer-(SN-)vorhanden-Bit auf 1 gesetzt ist, dann ist das Zustell-SN-Feld vorhanden und enthält die gültigen Informationen; Fluss-SN vorhanden (Bit 6): Falls das Fluss-SN-vorhanden-Bit auf 1 gesetzt ist, dann ist das Folgenummer-Feld vorhanden; Zeitstempel vorhanden (Bit 7): Falls das Zeitstempel-vorhanden-Bit auf 1 gesetzt ist, dann ist das Zeitstempel-Feld vorhanden; TTL vorhanden (Bit 8): Ist das TTL-vorhanden-Bit auf 1 gesetzt, so ist das TTL-Feld vorhanden; Reserviert (Bit 9-12): bei Empfang auf „0“ gesetzt und ignoriert; Version (Bit 13 ~ 15): GMA-Versionsnummer, die für das in [GMA10] spezifizierte GMA-Verkapselungsprotokoll auf 0 gesetzt ist. Das Flags-Feld befindet sich am Ende der PDU, und das Nächster-Header-Feld ist das vorletzte Feld. Der GMA-Rx kann das Flags-Feld zuerst decodieren, um die Länge des GMA-Trailers zu bestimmen, und dann das eine oder die mehreren optionalen Felder decodieren, die in der GMA-PDU enthalten sind (im Folgenden erörtert).
  • Der GMA-Trailer 1910 kann auch null oder mehrere der folgenden optionalen Felder umfassen: Prüfsumme (1 Byte), enthält die (Einerkomplement-)Prüfsummen-Summe aller 8 Bits in dem Trailer 1910 (zum Zwecke des Berechnens der Prüfsumme ist der Wert des Prüfsummenfeldes Null; dieses Feld ist nur vorhanden, falls das Prüfsumme-vorhanden-Bit auf eins gesetzt ist); Erste-SDU-Länge (2 Byte), gibt die Länge des ersten IP-Pakets in der PDU an, wenn eine PDU mehrere IP-Pakete enthält (dieses Feld ist z. B. nur vorhanden, wenn das Verkettung-vorhanden-Bit auf eins gesetzt ist); Verbindungs-ID (1 Byte), enthält eine vorzeichenlose ganze Zahl, um die Anker- und/oder Zustellverbindung der GMA-PDU zu identifizieren (dieses Feld ist z. B. nur vorhanden, wenn das Verbindungs-ID-vorhanden-Bit auf eins gesetzt ist): das Ankerverbindungs-ID-Datenelement/-Feld (MSB, 4 Bits des Verbindungs-ID-Feldes) ist eine vorzeichenlose ganze Zahl, um die Ankerverbindung zu identifizieren, und das Zustellverbindungs-ID-Datenelement/-Feld (LSB, 4 Bits des Verbindungs-ID-Feldes) ist eine vorzeichenlose ganze Zahl, um die Zustellverbindung zu identifizieren; die Fluss-ID (1 Byte), enthält eine vorzeichenlose ganze Zahl, um den IP-Fluss zu identifizieren, zu dem eine PDU gehört, zum Beispiel eine ID eines Datenfunkträgers (DRB - Data Radio Bearer) [LWIPEP] für eine zellulare (z. B. LTE-, 5G/NR- usw.) Verbindung (dieses Feld ist z. B. nur vorhanden, wenn das Fluss-ID-vorhanden-Bit auf eins gesetzt ist); Fragmentierungssteuerung (FC) (z. B. 1 Byte), zum Bereitstellen notwendiger Informationen für die Wiederzusammensetzung, die nur benötigt werden, wenn eine PDU Fragmente mitführt (dieses Feld ist z. B. nur vorhanden, wenn das Fragmentierungs-vorhanden-Bit auf eins gesetzt ist; siehe z. B. Abschnitt 5 in [GMA10]); Zustell-SN (1 Byte), enthält eine automatisch inkrementierte ganze Zahl, um die GMA-PDU-Übertragungsreihenfolge auf einer Zustellverbindung anzugeben (die Zustell-SN kann z. B. benötigt werden, um den Paketverlust jeder Zustellverbindung zu messen, und daher pro Zustellverbindung pro Fluss erzeugt werden; dieses Feld ist z. B. nur vorhanden, falls das Zustell-SN-vorhanden-Bit auf eins gesetzt ist); Fluss-SN (3 Bytes), enthält eine automatisch inkrementierte ganze Zahl, um die Reihenfolge von GMA-SDUs (z. B. IP-Paketen) eines Flusses anzugeben (die Fluss-SN wird z. B. möglicherweise für eine Neuübertragung Neuordnung und Fragmentierung benötigt; die Fluss-SN kann pro Fluss erzeugt werden; dieses Feld ist z. B. nur vorhanden, wenn das Fluss-SN-vorhanden-Bit auf eins gesetzt ist; Zeitstempel (4 Bytes), enthält den aktuellen Wert des Zeitstempeltakts des Tx in der Einheit von 1 Millisekunde. Dieses Feld ist nur vorhanden, wenn das Zeitstempel-vorhanden-Bit auf eins gesetzt ist; und TTL (1 Byte), enthält den TTL-Wert des ursprünglichen IP-Headers, wenn die GMA-SDU IPv4 ist, oder den Hop-Limit-Wert des IP-Headers, wenn die GMA-SDU IPv6 ist (dieses Feld ist z. B. nur vorhanden, wenn das TTL-vorhanden-Bit auf eins gesetzt ist). Die GMA-Steuerfelder folgen der Bitreihenfolge im Flags-Feld (z. B. ist Bit 0 (MSB) des Flags-Feldes das Prüfsummen-vorhanden-Bit, und das Prüfsummenfeld ist das letzte im Trailer 1910 mit Ausnahme der zwei obligatorischen Felder; Bit 1 ist das Verkettung-vorhanden-Bit und das FSL-Feld ist das zweitletzte usw.).
  • 1.5.1.2. HEADER-BASIERTE IP-VERKAPSELUNG
  • 19 zeigt außerdem das Header-basierte IP-Verkapselungsformat 1902. Hierbei wird der GMA-Header 1920 unmittelbar nach dem IP-Header der GMA-SDU eingefügt.
  • 19 zeigt auch ein beispielhaftes GMA-Header-(hdr-)Format 1920, das das Flags-Feld und die GMA-Steuerfelder umfasst. Im Vergleich zum GMA-Trailer 1910 besteht der einzige Unterschied darin, dass sich das Flags-Feld nun vorne befindet, so dass der Rx zuerst das Flags-Feld decodieren kann, um die GMA-Header-Länge zu bestimmen. Außerdem sollten die IP-Header-Felder der GMA-PDU in gleicher Weise geändert werden wie eine Trailer-basierte IP-Verkapselung (wie zuvor erörtert). Zusätzlich oder alternativ dazu werden die TTL-, FSL- und Nächster-Header-Felder aus den GMA-Steuerfeldern entfernt, da die IP-Header-Felder der GMA-SDU während der Verkapselung unverändert bleiben. Die Reihenfolge der anderen GMA-Steuerfelder ist gleich wie zuvor erörtert.
  • Bei einigen Implementierungen kann die GMA-PDU 1902 ohne Modifikation verwendet werden, falls die Anpassungsschicht (z. B. UDP-Tunneln oder dergleichen) ein Nicht-IP-Paketformat unterstützt. Falls die Anpassungsschicht (siehe z. B. 1B) nur das IP-Paketformat unterstützt, kann die Header-basierte IP-Verkapselungs-GMA-PDU 1903 verwendet werden. In der Header-basierten IP-Verkapselungs-PDU 1903 wird der IP-Header der GMA-SDU (z. B. IP-Nutzlast) zur Vorderseite des Pakets bewegt, so dass die GMA-PDU 1903 ein IP-Paket wird, und die IP-Header-Felder der GMA-PDU 1903 auf die gleiche Weise wie die Trailer-basierte IP-Verkapselungs-PDU 1901 geändert werden können.
  • Die Header- oder Trailer-basierten IP-Verkapselungs-PDUS 1902, 1901 können dynamisch paketweise verwendet werden, und das Setzen des Protokolltyps der GMA-PDU auf „114“ gibt das Vorhandensein des GMA-Headers 1920 in einem IP-Paket an.
  • 1.5.1.3. (HEADER-BASIERTE) NICHT-IP-VERKAPSELUNG
  • 19 stellt auch das Header-basierte Nicht-IP-Verkapselungsformat 1903 dar. Hierbei ist an der MX-Anpassungsschicht „UDP-Tunneln“ konfiguriert. Außerdem werden „TTL“, „FSL“ und „Nächster Header“ nicht mehr benötigt. Außerdem bleiben die IP-Header-Felder der GMA-SDU unverändert. Wenn eine Nicht-IP-Verkapselung konfiguriert ist, ist auch der GMA-Header 1920 vorhanden.
  • 1.5.2. FRAGMENTIERUNG
  • Die Konvergenzschicht kann Fragmentierung unterstützen, wenn eine Zustellverbindung eine kleinere maximale Übertragungseinheit (MTU) aufweist als das ursprüngliche IP-Paket (SDU). Die Fragmentierungsprozedur auf der Konvergenzteilschicht ähnelt prinzipiell der IP-Fragmentierung (siehe z. B. „DARPA Internet Program Protocol Specification“, IETF RFC 791 (September 1981)), weist jedoch die folgenden zwei Unterschiede für weniger Overhead auf: das Fragment-Offset-Feld wird in Anzahl von Fragmenten ausgedrückt; und die maximale Anzahl von Fragmenten pro SDU beträgt 2^7 (= 128).
  • Das Feld „Fragmentierungssteuerung“ (FC) in dem GMA-Trailer (oder -Header) enthält die folgenden Bits: Bit Nr. 7: ein Mehr-Fragmente-(MF-)Flag, zeigt an, ob das Fragment das letzte (0) ist oder nicht (1); und Bit Nr. 0 ~ Nr. 6: Fragment-Offset (in Einheiten von Fragmenten) zum Spezifizieren des Offsets eines bestimmten Fragments relativ zum Anfang der SDU.
  • Eine PDU führt eine ganze SDU ohne Fragmentierung mit, wenn das FC-Feld auf alles „0en“ gesetzt ist oder das FC-Feld nicht im Trailer vorhanden ist. Andernfalls enthält die PDU ein Fragment der SDU.
  • Das Fluss-SN-Feld im Trailer wird verwendet, um die Fragmente einer SDU von denen einer anderen zu unterscheiden. Das Fragment-Offset-(FO-)Feld gibt dem Empfänger die Position eines Fragments in der ursprünglichen SDU an. Das Mehr-Fragmente-(MF-)Flag zeigt das letzte Fragment an.
  • Um eine lange SDU zu fragmentieren, erzeugt der Tx n PDUs und kopiert den Inhalt der IP-Header-Felder aus der langen PDU in den IP-Header aller PDUs. Das Längenfeld im IP-Header der PDU sollte auf die Länge der PDU geändert werden, und der Protokolltyp sollte auf 114 geändert werden.
  • Die Daten der langen SDU werden basierend auf der MTU-Größe der Zustellverbindung in n Teile unterteilt. Der erste Teil der Daten wird in der ersten PDU platziert. Das MF-FLAG wird auf „1“ gesetzt, und das FO-Feld wird auf „0“ gesetzt. Der i-te Teil der Daten wird in der i-ten PDU platziert. Das MF-Flag wird auf „0“ gesetzt, wenn es das letzte Fragment ist, und andernfalls auf „1“ gesetzt. Das FO-Feld wird auf i - 1 gesetzt.
  • Um die Fragmente einer SDU zusammenzusetzen, kombiniert der Empfänger PDUs, die alle die gleiche Fluss-SN aufweisen. Die Kombination erfolgt durch Platzieren des Datenteils jedes Fragments in der relativen Reihenfolge, die durch den Fragment-Offset im GMA-Trailer (oder - Header) dieses Fragments angegeben wird. Das erste Fragment weist den Fragment-Offset auf „0“ gesetzt auf, und das letzte Fragment das Mehr-Fragmente-Flag auf „0“ auf.
  • Die GMA-Fragmentierung funktioniert oberhalb der IP-Schicht der individuellen Zugangsverbindung (z. B. RAT1, RAT2 usw.) und zwischen den beiden Endpunkten der Konvergenzschicht. Die Konvergenzschicht-Endpunkte (Client, Mehrfachzugangs-Gateway) sollten die MTU einer individuellen Verbindung entweder durch manuelle Konfiguration oder Implementieren von Pfad-MTU-Erkennung (PMTUD - Path MTU Discovery) erhalten, wie in Bonica et al., „IP Fragmentation Considered Fragile“, IETF RFC 8900 (September 2020) vorgeschlagen.
  • 1.5.3. VERKETTUNG
  • Die Konvergenzteilschicht kann Verkettung unterstützen, wenn eine Zustellverbindung eine größere maximale Übertragungseinheit (MTU) aufweist als das ursprüngliche IP-Paket (SDU). Nur die SDUs mit derselben Client-Netzwerkadresse (z. B. IP-Adresse oder dergleichen) und derselben Fluss-ID können verkettet werden. Falls das (Trailer- oder Header-basierte) IP-Verkapselungsverfahren verwendet wird, sollte das Feld der Erste-SDU-Länge (FSL) im GMA-Trailer (oder Header) enthalten sein, um die Länge der ersten SDU anzugeben. Andernfalls sollte das FSL-Feld nicht enthalten sein.
  • Um zwei oder mehr SDUs zu verketten, erzeugt der Tx eine PDU und kopiert den Inhalt des IP-Header Felds aus der ersten SDU in den IP-Header der PDU. Die Daten der ersten SDU werden im ersten Teil der Daten der PDU platziert. Die gesamte zweite SDU wird dann im zweiten Teil der Daten der PDU platziert. Die Prozedur wird fortgesetzt, bis die PDU-Größe die MTU der Zustellverbindung erreicht. Wenn das FSL-Feld vorhanden ist, sollte das IP-Längenfeld der PDU aktualisiert werden, um alle verketteten SDUs und den Trailer (oder Header) einzubeziehen, und das IP-Prüfsummenfeld sollte neu berechnet werden, wenn das Paket IPv4 ist.
  • Um eine PDU zu zerlegen, erhält der Empfänger, falls das (Header- oder Trailer-basierte) IP-Verkapselungsverfahren verwendet wird, zuerst die Länge der ersten SDU aus dem FSL-Feld und decodiert die erste SDU. Der Empfänger erhält dann die Länge der zweiten SDU basierend auf dem Längenfeld im zweiten SDU-IP-Header und decodiert die zweite SDU. Das Verfahren wird so lange fortgesetzt, bis kein Byte mehr in der PDU vorhanden ist. Falls das Nicht-IP-Verkapselungsverfahren verwendet wird, ändert sich der IP-Header der ersten SDU während des Verkapselungsprozesses nicht, und der Empfänger sollte die Länge der ersten SDU direkt aus ihrem IP-Header erhalten.
  • Falls eine PDU mehrere SDUs enthält, ist das Fluss-SN-Feld für die letzte SDU, und die Fluss-SN einer anderen SDU, die von derselben PDU mitgeführt wird, kann gemäß ihrer Reihenfolge in der PDU erhalten werden. Falls zum Beispiel das SN-Feld 6 ist und eine PDU 3 SDUs (IP-Pakete) enthält, ist die SN 4, 5 und 6 für die erste, die zweite bzw. die letzte SDU. Die GMA-Verkettung kann zum Packen kleiner Pakete einer einzigen Anwendung, z. B. TCP-ACKS, oder aus mehreren Anwendungen verwendet werden. Es ist anzumerken, dass ein einziger GMA-Fluss mehrere Anwendungsflüsse (TCP, UDP usw.) mitführen kann.
  • 1.5.4. GMA-PROTOKOLLSTAPEL
  • 17 zeigt außerdem einen (verankerten) integrierten GMA-Konvergenzprotokollstapel 1700e. Wie bereits erwähnt, können GMA-Datenebenenfunktionen (z. B. Gc und Gs) in eine oder mehrere bestehende Netzwerkfunktionen (z. B. ein Gateway (GW), MEC usw.) integriert sein, um die Verwendung einer virtuellen Netzwerkschnittstelle (z. B. IP Nr. 3) zu vermeiden. Der integrierte GMA-Datenebenen-Protokollstapel 1700e verwendet die RAT1-Verbindung als Ankerverbindung. Infolgedessen wird nur ein UDP-Tunnel zum Liefern von Verkehr über die Nicht-Ankerverbindung benötigt, die die RAT2-Verbindung ist.
  • In einem Beispiel ist die RAT1-Ankerverbindung eine zellulare Verbindung (z. B. 5G/NR, LTE usw.) und die RAT2-Nicht-Ankerverbindung ist eine WiFi-Verbindung. Wenn die 5G/LTE-Verbindung als Anker für Anwendungen und die WiFi-Verbindung als Zustellverbindung verwendet werden, kann UDP-Tunneln (oder IPSec) zum Liefern von 5G/LTE-IP-Verkehr über ein WiFi-Netzwerk verwendet werden. Die GMA-Konvergenzteilschicht (siehe z. B. auch 1A, 1B, 1C) ist für Mehrwege-Verwaltungsoperationen (z. B. verlustloses Schalten, Aggregation/Aufteilung usw.) verantwortlich. Bei einem anderen Beispiel kann eine virtuelle IP-Verbindung als der Anker verwendet werden, und der Server 140 stellt alle notwendigen Informationen durch MAMS-Signalisierung bereit, um die virtuelle IP-Verbindung auf der Client-Seite 101 zu konfigurieren. Im beispielhaften GMA-MAMS-DPPS 1700 e können die GMA-Datenebenenfunktionen (Gc 1401 und Gs 1440) in eine bestehende Netzwerkfunktion (z. B. Gateway, Edge-Server/Host wie etwa einen MEC-Server/Host usw.) integriert sein, um die Verwendung einer virtuellen Netzwerkschnittstelle zu vermeiden.
  • 1.5.5. GMA-KONFIGURATIONSPARAMETER
  • Einige beispielhafte GMA-Konfigurationsparameter sind, wie folgt:
    • • RAT1-Sondierungsintervall: 30 Sekunden
    • • RAT2-Sondierungsintervall in Zustand 1 und 2: 30 Sekunden
    • • RAT2-Sondierungsintervall in Zustand 3: 10 Sekunden
    • • RAT2-Wiederverbindungsintervall: 60 Sekunden
    • • Niedrige Durchsatzschwelle: 10 Kbit/s
    • • Verbindungstrennungs-Timer: 10 Minuten
    • • RAT1-Signalqualität niedrige Schwelle: -75 dBm
    • • RAT1-Signalqualität hohe Schwelle: - 70 dBm
    • • RAT1-Paketverlust niedrige Schwelle: 1 %
    • • RAT1-Paketverlust hohe Schwelle: 10 %
    • • Neuordnung der Warteschlangengröße für Hochdurchsatzfluss (Fluss-ID = 3): 1000 Pakete
    • • Neuordnungs-Timer für Hochdurchsatzfluss (Fluss-ID = 3): 100 ms
    • • Neuordnung der Warteschlangengröße für Fluss mit hoher Zuverlässigkeit (Fluss-ID = 1): 20 Pakete
    • • Neuordnungs-Timer für Fluss mit hoher Zuverlässigkeit (Fluss-ID = 1): 10 ms
    • • Messintervall (MI): 30 Sekunden
    • • Meldeintervall (RI): 50 (MIs)
    • • Standardfluss-ID (DFI): 3
    • • Steuernachrichten-Neuübertragungsgrenze: 3
    • • Virtuelle NIC-MTU-Größe: 1400 (Byte)
    • • Ruhe-Timer: 1 Minute
    • • Zeitstempeleinheit: 1000 (us)
    • • UL-over-LTE-Flag: 0 (deaktiviert, Standardeinstellung) / 1 (aktiviert)
    • • Wi-Fi-Überlastungsdetektions-Flag: 0 (deaktiviert, Standardeinstellung) / 1 (aktiviert)
    • • Energiespar-Flag: 0 (deaktiviert, Standardeinstellung) / 1 (aktiviert)
  • Sowohl Gc als auch Gs führen den/die folgenden (Pro-Client-)Parameter:
    • • Start_Time: die Dauer zwischen jetzt und nächstem „Zeitpunkt Null“, wenn Start_Time zurückgesetzt wird (in der Einheit von 1 ms).
    • • TX_timeStamp: Zeitstempel wann ein Paket übertragen wird.
    • • RX_timeStamp: Zeitstempel der Zeit, zu der ein Paket empfangen wird.
    • • Sync_Guard_Time: konfigurierbarer Parameter, der steuert, wie lange Gc oder Gs warten sollte, bevor Messungen gestartet werden (basierend auf Zeitstempelinfo in empfangenen Paket(en)).
  • Der Gc und der Gs setzen ihre jeweilige „Start- Time“ unmittelbar nach dem erfolgreichen Austausch von mx_session_resume_req/rsp zurück, und der (tx-) Zeitstempelparameter in einer Steuernachricht gibt die Dauer zwischen dem Senden der Nachricht und dem Rücksetzen von Start_Time an.
  • Bei dem obigen Beispiel ist RAT1 eine WLAN-Verbindung/-RAT (z. B. WiFi oder dergleichen), und RAT2 ist eine zellulare Verbindung/RAT (z. B. LTE, 5G/NR, GSM, WiMAX oder dergleichen).
  • 1.5.6. GMA-BEREITSTELLUNGSSZENARIEN
  • Einige beispielhafte GMA-basierte Bereitstellungen können sein, wie folgt:
  • In einer ersten GMA-Bereitstellung können GMA-Client-Module (z. B. GMA-Gc und/oder CCM 206) als „Multihome-VPN“-Anwendung implementiert werden und auf einem UE (z. B. Smartphone, Tablet, PC usw.) ohne jegliche Auswirkung auf die Plattform oder das Betriebssystem ausgeführt werden.
  • In einer zweiten GMA-Bereitstellung können die GMA-Servermodule (z. B. GMA-Gs und/oder NCM 236) als eine „Edge-/Cloud-Server“-Anwendung (z. B. MEC-APP oder dergleichen) implementiert sein und im Edge- oder Cloud-Server ohne jegliche Auswirkung auf die Plattform oder das Betriebssystem ausgeführt werden. Falls der GMA-Server an der Edge läuft, kann die Verkehrsroutingrichtlinie auf der Edge-Plattform so konfiguriert sein, dass die folgenden drei Flüsse lokal zu der Edge-Plattform geleitet werden:
    • - TCP-Fluss (für MAMS-Verwaltungsnachrichten): IP Nr. 1 (oder IP Nr. 2) + TCP Nr. 1
    • - UDP-Fluss (für Tunnelverkehr über die 1 Zustellverbindung)): IP Nr. 1 + UDP Nr. 1
    • - UDP-Fluss (für Tunnelverkehr über die zweite Zustellverbindung): IP Nr. 2 + UDP Nr. 2
  • Darüber hinaus kann eine DNS-Konfiguration zur Edge-Plattform hinzugefügt werden, so dass „gmaserver.mec.com“ über die zwei Zustellverbindungen zu IP Nr. 1 bzw. IP Nr. 2 zugeordnet wird.
  • 2. EDGE-COMPUTING-SYSTEM-KONFIGURATIONEN UND -ANORDNUNGEN
  • Edge Computing auf allgemeiner Ebene bezieht sich auf die Implementierung, Koordination und Verwendung von Datenverarbeitung und Ressourcen an Orten näher an der „Edge“ (Rand) oder einer Sammlung von „Edges“ des Netzwerks. Zweck dieser Anordnung ist es, die Gesamtkosten der Eigentümerschaft zu verbessern, Anwendungs- und Netzwerklatenz zu reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzvoraussetzungen (insbesondere gegenüber herkömmlichem Cloud-Computing) zu verbessern. Komponenten, die Edge-Computing-Operationen durchführen können („Edge-Knoten“), können sich an jedem Ort befinden, der von der Systemarchitektur oder einem Ad-hoc-Dienst benötigt wird (z. B. in einem Hochleistungsrechenzentrum oder einer Hochleistungs-Cloud-Installation; einem designierten Edge-Knotenserver, einem Unternehmensserver, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the-Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert).
  • Individuelle Rechenplattformen oder andere Komponenten, die Edge-Computing-Operationen ausführen können (als „Edge-Rechennoten“, „Edge-Knoten“ oder dergleichen bezeichnet), können sich an jedem Ort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird.. In vielen Edge-Computing-Architekturen werden Edge-Knoten an NANs, Gateways, Netzwerkroutern und/oder anderen Vorrichtungen bereitgestellt, die näher an Endpunktvorrichtungen (zum Beispiel UEs, IoT-Vorrichtungen usw.) liegen, die Daten produzieren und konsumieren. Als Beispiele können Edge-Knoten in einem Hochleistungsrechenzentrum oder einer Hochleistungs-Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmens server, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert, implementiert werden.
  • Edge-Rechenknoten können Ressourcen (zum Beispiel Speicher, CPU, GPU, Interrupt-Steuerungen, E/A-Steuerungen, Speichersteuervorrichtung, Bussteuerungen, Netzwerkverbindungen oder -sitzungen usw.) partitionieren, wobei jeweilige Partitionierungen Sicherheits- und/oder Integritätsschutzfähigkeiten enthalten können. Edge-Knoten können auch Orchestrierung mehrerer Anwendungen über isolierte Benutzerrauminstanzen, wie etwa Container, Partitionen, virtuelle Umgebungen (VEs), virtuelle Maschinen (VMs), FaaS-Engines (FaaS - Function-as-a-Service), Servlets, Server und/oder andere ähnliche Rechenabstraktionen bereitstellen. Container sind begrenzte einsetzbare Softwareeinheiten, die Code und benötigte Abhängigkeiten bereitstellen. Verschiedene Edge-Systemanordnungen/-architekturen behandeln VMs, Container und funktionieren gleichermaßen hinsichtlich der Anwendungszusammensetzung. Die Edge-Knoten werden basierend auf Edge-Bereitstellungsfunktionen koordiniert, während der Betrieb der verschiedenen Anwendungen mit Orchestrierungsfunktionen (zum Beispiel VM oder Container-Engine usw.) koordiniert wird. Die Orchestrierungsfunktionen können verwendet werden, um die isolierten Benutzerrauminstanzen einzusetzen, die Verwendung spezifischer Hardware, sicherheitsbezogene Funktionen (zum Beispiel Schlüsselverwaltung, Vertrauensankerverwaltung usw.) sowie andere Aufgaben im Zusammenhang mit der Bereitstellung und dem Lebenszyklus isolierter Benutzerräume zu identifizieren und zu planen.
  • Anwendungen, die für Edge Computing angepasst wurden, umfassen unter anderem Virtualisierung traditioneller Netzwerkfunktionen (um zum Beispiel Telekommunikations- oder Internetdienste zu betreiben) und die Einführung von Merkmalen und Diensten der nächsten Generation (um zum Beispiel 5G-Netzwerkdienste zu unterstützen). Geplante Anwendungsfälle zur umfangreichen Nutzung von Edge Computing umfassen verbundene selbstfahrende Autos, Überwachung, Internet-der-Dinge-(IoT-)Vorrichtungsdatenanalytik, Videocodierung und - analytik, standortbewusste Dienste, Vorrichtungserfassung in intelligenten Städten, unter vielen anderen Netzwerk- und rechenintensiven Diensten.
  • Edge Computing kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst anbieten oder hosten, um Orchestrierung und Verwaltung für Anwendungen und koordinierte Dienstinstanzen unter vielen Arten von Speicher- und Rechenressourcen anzubieten. Es ist zu erwarten, dass Edge Computing auch fest in existierende Anwendungsfälle und Technologien integriert wird, die für IoT- und Fog- sowie verteilte Netzwerkkonfigurationen entwickelt wurden, da Endpunktvorrichtungen, Clients und Gateways versuchen, auf Netzwerkressourcen und Anwendungen an Orten zuzugreifen, die näher an der Edge (Rand) des Netzwerks liegen.
  • Die vorliegende Offenbarung stellt spezifische Beispiele bereit, die für Edge-Computing-Konfigurationen relevant sind, die innerhalb von Multi-Access-Edge-Computing-(MEC-) und 5G-Netzwerkumsetzungen bereitgestellt werden. Viele andere Standards und Netzimplementierungen sind jedoch auf die hier erörterten Edge- und Dienstverwaltungskonzepte anwendbar. Zum Beispiel können viele andere Edge-Computing-/-Networking-Technologien auf die vorliegende Offenbarung in verschiedenen Kombinationen und Layouts von Vorrichtungen anwendbar sein, die sich am Rand eines Netzwerks befinden. Beispiele für solche anderen Edge-Computing-/- Netzwerktechnologien umfassen Content Delivery Networks (CDNs) (auch als „Content Distribution Networks“ oder dergleichen bezeichnet); Mobility-Service-Provider-(MSP)-Edge-Computing- und/oder Mobility-as-a-Service-(MaaS-)Anbietersysteme (z. B. verwendet in AECC-Architekturen); Nebula-Edge-Cloud-Systeme; Fog-Computing-Systeme; Cloudlet-Edge-Cloud-Systeme; Mobile-Cloud-Computing-Systeme; eine Vermittlungsstelle umgestaltet als Rechenzentrum (CORD), eine Mobile-CORD (M-CORD) und/oder Converged-Multi-Access-and-Core-(COMAC-)Systeme und/oder dergleichen. Ferner können sich die hier offenbarten Techniken auf andere IoT-Edge-Netzwerksysteme und -konfigurationen beziehen, und es können auch andere Zwischenverarbeitungsentitäten und Architekturen für Zwecke der vorliegenden Offenbarung verwendet werden.
  • 20 stellt eine beispielhafte Edge-Computing-Umgebung 2000 dar. 20 veranschaulicht insbesondere die unterschiedlichen Kommunikationsschichten, die innerhalb der Umgebung 2000 auftreten, ausgehend von einer Schicht von Endpunkt-Sensoren oder -Dingen 2010 (die z. B. in einer IoT-Netzwerktopologie (IoT - Internet of Things) arbeiten), die eine oder mehrere IoT-Vorrichtungen 2011 (auch als Edge-Endpunkte 2010 oder dergleichen bezeichnet) umfassen; über eine komplexere Schicht von Gateways oder Zwischenknoten 2020, die ein oder mehrere Benutzergeräte (UEs) 2021a und 2021b (auch als Zwischenknoten 2020 oder dergleichen bezeichnet) umfassen, die das Sammeln und Verarbeiten von Daten von Endpunkten 2010 erleichtern; hin zu einer Zugangsknotenschicht 2030 (oder „Edge-Knotenschicht 2030“) zunehmend komplexerer Verarbeitung und Konnektivität, die mehrere Netzwerkzugangsknoten (NANs) 2031a, 2031b und 2031c (zusammen als „NANs 2031-2033“ oder dergleichen bezeichnet) und mehrere Edge-Rechenknoten 2036a-c (zusammen als „Edge-Rechenknoten 2036“ oder dergleichen bezeichnet) innerhalb eines Edge-Computing-Systems 2035 umfasst; und zu einer Backend-Schicht 2010 mit einem Kernnetzwerk (CN) 20442 und einer Cloud 2044 noch komplexerer Konnektivität und Verarbeitung. Die Verarbeitung an der Backend-Schicht 2040 kann durch Netzwerkdienste, wie durch einen oder mehrere Remote-Anwendungs-(App-)Server 2050 durchgeführt, und/oder andere Cloud-Dienste verbessert werden. Einige oder alle dieser Elemente können mit einigen oder allen der hierin erörterten Merkmale und Funktionalitäten ausgestattet sein oder diese anderweitig implementieren..
  • Die Umgebung 2000 ist so dargestellt, dass sie Endbenutzervorrichtungen, wie etwa Zwischenknoten 2020 und Endpunkte 2010, umfasst, die konfiguriert sind, um basierend auf unterschiedlichen Zugangstechnologien (oder „Funkzugangstechnologien“) eine Verbindung zu einem oder mehreren Kommunikationsnetzwerken (auch als „Zugangsnetzwerke“, „Funkzugangsnetzwerke“ oder dergleichen bezeichnet) zum Zugreifen auf Anwendungsdienste herzustellen (oder sich kommunikativ daran anzukoppeln). Diese Zugangsnetzwerke können eines oder mehrere der NANs 2031, 2032 und/oder 2033 umfassen. Die NANs 2031-2033 sind dazu eingerichtet, Netzwerkkonnektivität für die Endbenutzervorrichtungen über jeweilige Verbindungen 2003, 2007 zwischen den einzelnen NANs und dem einen oder den mehreren UEs 2011, 2021 bereitzustellen.
  • Als Beispiele können die Kommunikationsnetzwerke und/oder Zugangstechnologien Mobilfunktechnologie, wie etwa LTE, MuLTEfire und/oder NR/5G (wie z. B. durch den Funkzugangsnetzwerk-(RAN-)Knoten 2031 und/oder RAN-Koten 2032 bereitgestellt), WiFi- oder WLAN-(Wireless Local Area Network-)Technologien (wie z. B. durch den Zugangspunkt (AP) 2033 und/oder RAN-Knoten 2032 bereitgestellt) und/oder dergleichen umfassen. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistung in unterschiedlichen Szenarien wird von der Auswahl der Zugangsnetze (z. B. WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokolle (z. B. Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) abhängig.
  • Die Zwischenknoten 2020 umfassen ein UE 2021a und ein UE 2021b (zusammen als „UE 2021“ oder „UEs 2021“ bezeichnet). In diesem Beispiel ist das UE 2021a als ein Fahrzeug-UE veranschaulicht, und das UE 2021b ist als ein Smartphone z. B. eine mobile Handrechenvorrichtung mit Berührungsbildschirm, die mit einem oder mehreren zellularen Netzwerken verbunden werden kann) veranschaulicht. Diese UEs 2021 können jedoch eine beliebige mobile oder nicht-mobile Rechenvorrichtung, wie etwa Tablet-Computer, Wearable-Vorrichtungen, PDAs, Pager, Desktop-Computer, Laptop-Computer, drahtlose Handapparate, unbemannte Fahrzeuge oder Drohnen, und/oder eine beliebige Art von Rechenvorrichtung mit einer drahtlosen Kommunikationsschnittstelle umfassen.
  • Die Endpunkte 2010 umfassen UEs 2011, die IoT-Vorrichtungen (auch als „IoT-Vorrichtungen 2011“ bezeichnet) sein können, die eindeutig identifizierbare eingebettete Rechenvorrichtungen (z. B. innerhalb der Internetinfrastruktur) sind, die eine Netzwerkzugangsschicht umfassen, die für IoT-Anwendungen mit niedriger Leistung ausgelegt ist, die kurzlebige UE-Verbindungen nutzen. Die IoT-Vorrichtungen 2011 sind beliebige physische oder virtualisierte Vorrichtungen, Sensoren oder „Dinge“, die mit Hardware- und/oder Softwarekomponenten eingebettet sind, welche die Objekte, Vorrichtungen, Sensoren oder „Dinge“ aktivieren, die in der Lage sind, mit einem Ereignis assoziierte Daten zu erfassen und/oder aufzuzeichnen, und in der Lage sind, solche Daten über ein Netzwerk mit wenig oder keinem Benutzereingriff mit einer oder mehreren anderen Vorrichtungen auszutauschen. Als Beispiele können IoT-Vorrichtungen 2011 abiotische Vorrichtungen sein, wie etwa autonome Sensoren, Messgeräte, Zähler, Bilderfassungsvorrichtungen, Mikrofone, lichtemittierende Vorrichtungen, audioemittierende Vorrichtungen, Audio- und/oder Videowiedergabevorrichtungen, elektromechanische Vorrichtungen (z. B. Schalter, Aktuator usw.), EEMS, ECUs, ECMs, eingebettete Systeme, Mikrocontroller, Steuermodule, vernetzte oder „intelligente“ Geräte, MTC-Vorrichtungen, M2M-Vorrichtungen und/oder dergleichen. Die IoT-Vorrichtungen 2011 können Technologien, wie etwa M2M oder MTC, zum Austauschen von Daten mit einem MTC-Server (z. B. einem Server 2050), einem Edge-Server 2036 und/oder einem Edge-Computing-System 2035 oder einer Vorrichtung über eine PLMN-, ProSe- oder D2D-Kommunikation, Sensornetzwerke oder IoT-Netzwerke nutzen. Der M2M- oder MTC-Austausch von Daten kann ein maschineninitiierter Austausch von Daten sein.
  • Die IoT-Vorrichtungen 2011 können Hintergrundanwendungen (z. B. Keep-Alive-Nachrichten, Statusaktualisierungen usw.) ausführen, um die Verbindungen des IoT-Netzwerks zu erleichtern. Wenn die IoT-Vorrichtungen 2011 Sensorvorrichtungen sind oder in diese eingebettet sind, kann das IoT-Netzwerk ein WSN sein. Ein IoT-Netzwerk beschreibt miteinander verbundene IoT-UEs, wie etwa die IoT-Vorrichtungen 2011, die über jeweilige direkte Verbindungen 2005 miteinander verbunden sind. Die IoT-Vorrichtungen können eine beliebige Anzahl von verschiedenen Typen von Vorrichtungen umfassen, die in verschiedenen Kombinationen gruppiert sind (als eine „IoT-Gruppe“ bezeichnet), die IoT-Vorrichtungen umfassen können, die einen oder mehrere Dienste für einen bestimmten Benutzer, Kunden, Organisationen usw. bereitstellen. Ein Dienstanbieter (z. B. ein Eigentümer/Betreiber des Servers 2050, des CN 2042 und/oder der Cloud 2044) kann die IoT-Vorrichtungen in der IoT-Gruppe in einem bestimmten Bereich (z. B. einer Geolokalisierung, einem Gebäude usw.) einsetzen, um den einen oder die mehreren Dienste bereitzustellen. Bei einigen Implementierungen kann das IoT-Netzwerk ein Mesh-Netzwerk von IoT-Vorrichtungen 2011 sein, die als Fog-Vorrichtung, Fog-System oder Fog bezeichnet werden kann, die am Rand der Cloud 2044 arbeiten. Der Fog umfasst Mechanismen, um Cloud-Computing-Funktionalität Datengeneratoren und -verbrauchern näher zu bringen, wobei verschiedene Netzwerkgeräte Cloud-Anwendungslogik auf ihrer nativen Architektur ausführen. Fog-Computing ist eine horizontale Architektur auf Systemebene, die Ressourcen und Dienste von Berechnung, Speicherung, Steuerung und Vernetzung überall entlang des Kontinuums von der Cloud 2044 zu Dingen (z. B. IoT-Vorrichtungen 2011) verteilt. Der Fog kann gemäß Spezifikationen festgelegt werden, die unter anderem von der OFC, der OCF, freigegeben werden. Zusätzlich oder alternativ dazu kann der Fog ein Tangle gemäß Definition der IOTA-Foundation sein.
  • Der Fog kann verwendet werden, um Berechnung/Aggregation mit niedriger Latenz an den Daten durchzuführen, während sie zu einem Edge-Cloud-Computing-Dienst (z. B. Edge-Knoten 2030) und/oder einem zentralen Cloud-Computing-Dienst (z. B. Cloud 2044) geleitet werden, um schwierige Berechnungen oder rechnerisch aufwändige Aufgaben durchzuführen. Andererseits konsolidiert Edge-Cloud-Computing von Menschen betriebene, freiwillige Ressourcen als Cloud. Diese freiwilligen Ressourcen können unter anderem Zwischenknoten 2020 und/oder Endpunkte 2010, Desktop-PCs, Tablets, Smartphones, Nano-Rechenzentren und dergleichen umfassen. Bei verschiedenen Implementierungen können sich Ressourcen in der Edge-Cloud ein bis zwei Hops von den IoT-Vorrichtungen 2011 entfernt sein, was zu einem Reduzieren von Overhead in Bezug auf die Verarbeitung von Daten führen und Netzwerkverzögerung reduzieren kann.
  • Zusätzlich oder alternativ dazu kann der Fog eine Konsolidierung von IoT-Vorrichtungen 2011 und/oder Vernetzungsvorrichtungen, wie etwa Routern und Switches, mit hohen Rechenfähigkeiten und der Fähigkeit sein, Cloud-Anwendungslogik auf ihrer nativen Architektur auszuführen. Fog-Ressourcen können von Cloud-Anbietern hergestellt, verwaltet und bereitgestellt werden, und sie können mittels zuverlässiger Hochgeschwindigkeitsverbindungen miteinander verbunden sein. Darüber hinaus liegen Fog-Ressourcen im Vergleich zu Edge-Systemen weiter vom Rand des Netzwerks entfernt, aber näher als eine zentrale Cloud-Infrastruktur. Fog-Vorrichtungen werden verwendet, um rechenintensive Aufgaben oder Arbeitslasten, die von Edge-Ressourcen abgeladen werden, effektiv zu handhaben.
  • Zusätzlich oder alternativ dazu kann der Fog am Rand der Cloud 2044 arbeiten. Der Fog, der am Rand der Cloud 2044 arbeitet, kann sich mit einem Edge-Netzwerk 2030 der Cloud 2044 überlappen oder darin aufgehen. Das Edge-Netzwerk der Cloud 2044 kann sich mit dem Fog überlappen oder ein Teil des Fogs werden. Außerdem kann der Fog ein Edge-Fog-Netzwerk sein, das eine Edge-Schicht und eine Fog-Schicht umfasst. Die Edge-Schicht des Edge-Fog-Netzwerks umfasst eine Sammlung lose gekoppelter, freiwilliger und von Menschen betriebener Ressourcen (z. B. die oben erwähnten Edge-Rechenknoten 2036 oder Edge-Vorrichtungen). Die Fog-Schicht befindet sich auf der Edge-Schicht und ist eine Konsolidierung von Vernetzungsvorrichtungen, wie etwa den Zwischenknoten 2020 und/oder den Endpunkten 2010 von 20.
  • Daten können zwischen den IoT-Vorrichtungen 2011 oder zum Beispiel zwischen den Zwischenknoten 2020 und/oder Endpunkten 2010, die direkte Verbindungen 2005 miteinander aufweisen, wie in 20 gezeigt, erfasst, gespeichert/aufgezeichnet und kommuniziert werden. Eine Analyse des Verkehrsflusses und der Steuerschemata kann durch Aggregatoren implementiert werden, die über ein Mesh-Netzwerk mit den IoT-Vorrichtungen 2011 und miteinander in Kommunikation stehen. Die Aggregatoren können ein Typ einer IoT-Vorrichtung 2011 und/oder eines Netzwerkgeräts sein. Im Beispiel von 20 können die Aggregatoren Edge-Knoten 2030 oder ein oder mehrere festgelegte Zwischenknoten 2020 und/oder Endpunkte 2010 sein.. Daten können über den Aggregator auf die Cloud 2044 hochgeladen werden, und Befehle können von der Cloud 2044 durch Gateway-Vorrichtungen empfangen werden, die mit den IoT-Vorrichtungen 2011 und den Aggregatoren durch das Mesh-Netzwerk in Kommunikation stehen. Im Gegensatz zum herkömmlichen Cloud-Computing-Modell kann die Cloud 2044 bei einigen Implementierungen geringe oder keine Rechenfähigkeiten aufweisen und dient nur als ein Repositorium zum Archivieren von Daten, die durch den Fog aufgezeichnet und verarbeitet werden. Bei diesen Implementierungen zentralisiert die Cloud 2044 das Datenspeicherungssystem und stellt Zuverlässigkeit und Zugriff auf Daten durch die Rechenressourcen in den Fog- und/oder Edge-Vorrichtungen bereit. Auf den im Kern der Architektur befindlichen Datenspeicher der Cloud 2044 kann sowohl von der Edge- als auch der Fog-Schicht des oben erwähnten Edge-Fog-Netzwerks zugegriffen werden.
  • Wie zuvor erwähnt, stellen die Zugangsnetzwerke Netzwerkkonnektivität über jeweilige NANs 2031-2033 für die Endbenutzervorrichtungen 2020, 2010 bereit. Die Zugangsnetzwerke können Funkzugangsnetzwerke (RANs) sein, wie etwa ein NG-RAN oder ein 5G-RAN für ein RAN, das in einem 5G/NR-Zellularnetzwerk arbeitet, ein E-UTRAN für ein RAN, das in einem LTE- oder 4G-Zellularnetzwerk arbeitet, oder ein Legacy-RAN, wie etwa ein UTRAN oder GERAN für GSM- oder CDMA-Zellularnetzwerke. Das Zugangsnetzwerk oder RAN kann für WiMAX-Implementierungen als Zugangsdienstnetzwerk bezeichnet werden. Zusätzlich oder alternativ dazu können die Gesamtheit oder Teile des RAN als eine oder mehrere Softwareentitäten implementiert sein, die auf Servercomputern als Teil eines virtuellen Netzwerks ausgeführt werden, das als Cloud-RAN (CRAN), Cognitive Radio (CR), Pool virtueller Basisbandeinheiten (vBBUP - Virtual Baseband Unit Pool) und/oder dergleichen bezeichnet werden kann. Zusätzlich oder alternativ dazu kann das CRAN, der CR oder der vBBUP eine RAN-Funktionsaufteilung implementieren, wobei eine oder mehrere Kommunikationsprotokollschichten vom CRAN/CR/vBBUP betrieben werden, und andere Kommunikationsprotokollinstanzen von einzelnen RAN-Knoten 2031, 2032 betrieben werden. Dieses virtualisierte Framework ermöglicht den freigegebenen Prozessorkernen der NANs 2031, 2032, andere virtualisierte Anwendungen durchzuführen, wie virtualisierte Anwendungen für verschiedene hierin erörterte Elemente.
  • Die UEs 2021, 2011 können jeweilige Verbindungen (oder Kanäle) 2003 nutzen, von denen jede(r) eine physikalische Kommunikationsschnittstelle oder -schicht umfasst. Die Verbindungen 2003 sind als eine Luftschnittstelle veranschaulicht, um eine kommunikative Kopplung im Einklang mit zellularen Kommunikationsprotokollen, wie etwa 3GPP-LTE, 5G/NR, Push-to-Talk (PTT) und/oder PTT over Cellular (POC), UMTS, GSM, CDMA und/oder beliebigen der anderen hier erörterten Kommunikationsprotokolle, zu ermöglichen. Zusätzlich oder alternativ kommunizieren (z. B. senden und empfangen) die UEs 2011, 2021 und die NANs 2031 bis 2033 Datenüber ein lizenziertes Medium (auch als das „lizenzierte Spektrum“ und/oder das „lizenzierte Band“ bezeichnet) und ein nicht lizenziertes gemeinsam genutztes Medium (auch als das „nicht lizenzierte Spektrum“ und/oder das „nicht lizenzierte Band“ bezeichnet). Um im unlizenzierten Spektrum zu arbeiten, können die UEs 2011, 2021 und NANs 2031-2033 unter Verwendung von LAA-, eLAA-(enhanced LAA-) und/oder feLAA-(further ELAA-)Mechanismen arbeiten. Die UEs 2021, 2011 können ferner Kommunikationsdaten über jeweilige direkte Verbindungen 2005 direkt austauschen, wobei es sich um LTE/NR-Proximity-Services-(ProSe-)Verbindungen oder PC5-Schnittstellen/-Verbindungen oder WiFi-basierte Verbindungen oder Verbindungen auf der Basis von persönlichen Netzwerken (PAN - Personal Area Network) (z. B. IEEE 802.15.4-basierte Protokolle, einschließlich der Protokolle ZigBee, 6LoWPAN (IPv6 over Low Power Wireless Personal Area Networks), WirelessHART, MiWi, Thread usw.; WiFidirect; Bluetooth-/Bluetooth Low Energy (BLE)) handeln kann.
  • Zusätzlich oder alternativ dazu liefern einzelne UEs 2021, 2011 Funkinformationen an ein oder mehrere NANs 2031-2033 und/oder einen oder mehrere Edge-Rechenknoten 2036 (z. B. Edge-Server/-Hosts usw.). Die Funkinformationen können in Form eines oder mehrerer Messberichte vorliegen und/oder zum Beispiel Signalstärkemessungen, Signalqualitätsmessungen und/oder dergleichen umfassen. Jeder Messbericht wird mit einem Zeitstempel und dem Ort der Messung markiert (z. B. dem aktuellen Standort der UEs 2021, 2011). Als Beispiele können die durch die UEs 2021, 2011 gesammelten und/oder in den Messberichten enthaltenen Messungen eines oder mehrere von Folgenden umfassen: Bandbreite (BW), Netzwerk- oder Zellenlast, Latenz, Jitter, Umlaufzeit (RTT), Anzahl von Unterbrechungen, reihenfolgeveränderte Lieferung von Datenpaketen, Übertragungsleistung, Bitfehlerrate, Bitfehlerverhältnis (BER), Blockfehlerrate (BLER), Paketverlustrate (PLR), Paketempfangsrate (PRR), e2e-Verzögerung, Signal-zu-Rausch-Verhältnis (SNR), Signal-zu-Rausch- und Interferenz-Verhältnis (SINR), Signal-plus-Rausch-plus-Verzerrung-zu Rausch-plus-Verzerrung-Verhältnis (SINAD), Trägerzu-Interferenz-plus-Rausch-Verhältnis (CINR), additives weißes Gaußsches Rauschen (AWGN), Energie-pro-Bit-zu-Rauschleistungsdichte-Verhältnis (Eb/N0), Energie-pro-Bit-zu-Störleistungsdichte-Verhältnis (Eb/10), Spitzen-zu-Durchschnittsleitungs-Verhältnis (PAPR), Referenzsignalempfangsleistung (RSRP), Empfangssignalstärkeindikator (RSSI), Referenzsignalempfangsqualität (RSRQ), GNSS-Timing von Zellenrahmen zur UE-Positionsbestimmung für E-UTRAN oder 5G/NR (z. B. Timing zwischen einer AP- oder RAN-Knoten-Referenzzeit und einer GNSS-spezifischen Referenzzeit für ein gegebenes GNSS), GNSS-Code-Messungen (z. B. die GNSS-Codephase (ganze Zahlen und Kommastellen) des Spreizcodes des i-ten GNSS-Satellitensignals), GNSS-Trägerphasenmessungen (z. B. die Anzahl von Trägerphasenzyklen (ganze Zahlen und Kommastellen) des i-ten GNSS-Satellitensignals, gemessen seit dem Einrasten auf das Signal; auch als ADR (Accumulated Delta Range) bezeichnet), Kanalstörungsmessung, Wärmerauschleistungsmessung, Empfangsstörleistungsmessung und/oder andere ähnliche Messungen. Die RSRP-, RSSI- und/oder RSRQ-Messungen können RSRP-, RSSI- und/oder RSRQ-Messungen zellspezifischer Referenzsignale, Kanalzustandsinformationsreferenzsignale (CSI-RS) und/oder Synchronisationssignale (SS) oder SS-Blöcke für 3GPP-Netzwerke (z. B. LTE oder 5G/NR) und RSRP-, RSSI- und/oder RSRQ-Messungen verschiedener Beacon-, Fast-Initial-Link-Setup-(FILS-)Erkennungsrahmen oder Sondierungsantwortrahmen für IEEE 802.11 WLAN/WiFi-Netze umfassen. Zusätzlich oder alternativ können andere Messungen verwendet werden, wie etwa jene, die in 3GPP TS 36.214 v16.2.0 (2021-03-31) („[TS36214]“), 3GPP TS 38.215 v16.4.0 (2020-12) („[TS38215]“), IEEE 802.11-2020, „IEEE Standard for Information Technology--Telecommunications and Information Exchange zwischen Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications“ (2021-02-26) („[IEEE80211]“) erörtert werden, und/oder dergleichen. Zusätzlich oder alternativ dazu kann jede der zuvor erwähnten Messungen (oder Kombination von Messungen) durch ein oder mehrere NANs 2031-2033 gesammelt und an den einen oder die mehreren Edge-Rechenknoten 2036 geliefert werden.
  • Die Funkinformationen können in Reaktion auf ein Auslöseereignis und/oder periodisch gemeldet werden. Zusätzlich oder alternativ melden einzelne UEs 2021, 2011 Funkinformationen entweder mit einer niedrigen Periodizität oder einer hohen Periodizität in Abhängigkeit von einem Datentransfer, der stattfinden soll, und/oder anderen Informationen über den Datentransfer.
  • Zusätzlich oder alternativ können der oder die Edge-Computing-Knoten 2036 die Messungen von den NANs 2031 bis 2033 mit niedriger oder hoher Periodizität anfordern, oder die NANs 2031 bis 2033 können die Messungen mit niedriger oder hoher Periodizität an den oder die Edge-Computing-Knoten 2036 liefern. Zusätzlich oder alternativ können der oder die Edge-Rechenknoten 2036 andere relevante Daten von anderen Edge-Rechenknoten 2036, Kernnetzwerkfunktionen (NFs), Anwendungsfunktionen (AFs) und/oder anderen UEs 2011, 2021, wie etwa Key Performance Indicators (KPIs), mit den Messberichten oder getrennt von den Messberichten erhalten.
  • Das UE 2021b ist do dargestellt, dass es dazu konfiguriert ist, über eine Verbindung 2007 auf einen Zugangspunkt (AP) 2033 zuzugreifen. In diesem Beispiel ist der AP 2033 so dargestellt, dass er mit dem Internet verbunden ist, ohne eine Verbindung mit dem CN 2042 des Drahtlossystems herzustellen. Die Verbindung 2007 kann eine lokale Drahtlosverbindung, wie etwa eine einem beliebigen IEEE-802.11-Protokoll entsprechende Verbindung, umfassen, wobei der AP 2033 einen Wireless-Fidelity(WiFi®)-Router umfassen würde. Zusätzlich oder alternativ können die UEs 2021 und die IoT-Vorrichtungen 2011 dazu konfiguriert sein, unter Verwendung geeigneter Kommunikationssignale miteinander oder mit einem beliebigen der AP 2033 über einen Einzel- oder Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie etwa unter anderem einer OFDM-Kommunikationstechnik (OFDM - Orthogonal Frequency Division Multiplexing), einer SC-FDMA-Kommunikationstechnik (SC-FDMA - Single Carrier Frequency Division Multiple Access) und/oder dergleichen, obwohl der Schutzbereich der vorliegenden Offenbarung in dieser Hinsicht nicht beschränkt ist. Die Kommunikationstechnik kann ein geeignetes Modulationsschema, wie etwa komplementäre Code-Umtastung (CCK); Phasenumtastung (PSK), wie etwa Binär-PSK (BPSK), Quadratur-PSK (QPSK), Differenz-PSK (DPSK) usw.; oder Quadratur-Amplitudenmodulation (QAM), wie etwa M-QAM; und/oder dergleichen umfassen..
  • Das eine oder die mehreren NANs 2031 und 2032, die Verbindungen 2003 aktivieren, können als „RAN-Knoten“ oder dergleichen bezeichnet werden. Die RAN-Knoten 2031, 2032 können Bodenstationen (z. B. terrestrische Zugangspunkte) oder Satellitenstationen umfassen, die Abdeckung innerhalb eines geografischen Gebiets (z. B. einer Zelle) bereitstellen. Die RAN-Knoten 2031, 2032 können als eine dedizierte physische Vorrichtung, wie etwa eine Makrozellenbasisstation, und/oder eine Niederleistungsbasisstation zum Bereitstellen von Femtozellen, Pikozellen oder anderen ähnlichen Zellen mit kleineren Abdeckungsbereichen, kleineren Benutzerkapazitäten oder höheren Bandbreiten im Vergleich zu Makrozellen implementiert sein. Bei diesem Beispiel ist der RAN-Knoten 2031 als ein NodeB, evolvierter NodeB (eNB) oder ein NodeB der nächsten Generation (gNB) ausgeführt, und die RAN-Knoten 2032 sind als Relaisknoten, verteilte Einheiten oder Straßenrandeinheiten (RSUs - Road Side Units) ausgeführt. Jede andere Art von NANs kann verwendet werden.
  • Jeder der RAN-Knoten 2031, 2032 kann das Luftschnittstellenprotokoll beenden und der erste Kontaktpunkt für die UEs 2021 und die IoT-Vorrichtungen XE111 sein. Zusätzlich oder alternativ dazu kann jeder der RAN-Knoten 2031, 2032 verschiedene logische Funktionen für das RAN erfüllen, einschließlich unter anderem RAN-Funktion(en) (z. B. Funknetzwerksteuerungs-(RNC-)Funktionen und/oder NG-RAN-Funktionen) für Funkressourcenverwaltung, Zulassungssteuerung, dynamische Uplink- und Downlink-Ressourcenzuweisung, Funkträgerverwaltung, Datenpaketplanung usw. Zusätzlich oder alternativ dazu können die UEs 2011, 2021 dazu konfiguriert sein, unter Verwendung von OFDM-Kommunikationssignalen miteinander oder mit einem beliebigen der NANs 2031, 2032 über einen Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie etwa unter anderem einer OFDMA-Kommunikationstechnik (z. B. für Downlink-Kommunikationen) und/oder einer SC-FDMA-Kommunikationstechnik (z. B. für Uplink- und ProSe- oder Sidelink-Kommunikationen), obwohl der Schutzbereich der vorliegenden Offenbarung in dieser Hinsicht nicht beschränkt ist.
  • Für die meisten zellularen Kommunikationssysteme organisieren die RAN-Funktion(en), die vom RAN oder den einzelnen NANs 2031-2032 betrieben werden, Downlink-Übertragungen (z. B. von einem der RAN-Knoten 2031, 2032 zu den UEs 2011, 2021) und Uplink-Übertragungen (zum Beispiel von den UEs 2011, 2021 zum RAN-Knoten 2031, 2032) in Funkrahmen (oder einfach „Rahmen“) mit einer Dauer von 10 Millisekunden (ms), wobei jeder Rahmen zehn 1-ms-Subrahmen umfasst.. Jede Übertragungsrichtung hat ihr eigenes Ressourcengitter, das physische Ressourcen in jedem Slot angibt, wobei jede Spalte und jede Zeile eines Ressourcengitters einem Symbol bzw. einem Unterträger entspricht. Die Dauer des Ressourcengitters in der Zeitdomäne entspricht einem Schlitz in einem Funkrahmen. Die Ressourcengitter umfassen eine Anzahl von Ressourcenblöcken (RBs), die die Abbildung bestimmter physikalischer Kanäle auf Ressourcenelemente (REs) beschreiben. Jeder RB kann ein physikalischer RB (PRB) oder ein virtueller RB (VRB) sein und umfasst eine Sammlung von REs. Ein RE ist die kleinste Zeit-Frequenz-Einheit in einem Ressourcengitter. Die RNC-Funktion(en) weist (weisen) Ressourcen (z. B. PRBs und Modulations- und Codierungsschemata (MCS)) jedem UE 2011, 2021 in jedem Übertragungszeitintervall (TTI) dynamisch zu. Ein TTI ist die Dauer einer Übertragung auf einer Funkverbindung 2003, 2005 und bezieht sich auf die Größe der Datenblöcke, die von höheren Netzwerkschichten an die Funkverbindungsschicht weitergeleitet werden.
  • Die NANs 2031/2032 können dazu konfiguriert sein, über jeweilige Schnittstellen oder Verbindungen (nicht dargestellt) miteinander zu kommunizieren, wie etwa eine X2-Schnittstelle für LTE-Implementierungen (z. B. wenn das CN 2042 ein Evolved Packet Core (EPC) ist), eine XN-Schnittstelle für 5G- oder NR-Implementierungen (z. B. wenn das CN 2042 ein Kern der fünften Generation (5GC) ist) oder dergleichen. Die NANs 2031 und 2032 sind auch kommunikativ mit dem CN 2042 gekoppelt. Zusätzlich oder alternativ kann das CN 2042 ein Evolved-Packet-Core-Netzwerk (EPC-Netzwerk), ein NextGen-Packet-Core-Netzwerk (NPC-Netzwerk), ein 5G-Kern (5GC) oder eine andere Art von CN sein. Das CN 2042 kann mehrere Netzwerkelemente umfassen, die dazu konfiguriert sind, Kunden/Teilnehmern (z. B. Benutzern von UEs 2021 und IoT-Vorrichtungen 2011), die über ein RAN mit dem CN 2042 verbunden sind, verschiedene Daten- und Telekommunikationsdienste anzubieten. Die Komponenten des CN 2042 können in einem physischen Knoten oder separaten physischen Knoten implementiert sein, einschließlich Komponenten zum Lesen und Ausführen von Anweisungen aus einem maschinenlesbaren oder computerlesbaren Medium (z. B. einem nichtflüchtigen maschinenlesbaren Speichermedium). Zusätzlich oder alternativ dazu kann Netzwerkfunktionsvirtualisierung (NFV) genutzt werden, um beliebige oder alle der oben beschriebenen Netzwerkknotenfunktionen über ausführbare Anweisungen zu virtualisieren, die in einem oder mehreren computerlesbaren Speichermedien gespeichert sind (im Folgenden ausführlicher beschrieben). Eine logische Instanziierung des CN 2042 kann als ein Netzwerk-Slice bezeichnet werden, und eine logische Instanziierung eines Teils des CN 2042 kann als ein Netzwerk-Sub-Slice bezeichnet werden. NFV-Architekturen und Infrastrukturen können verwendet werden, um eine oder mehrere Netzwerkfunktionen, die alternativ durch proprietäre Hardware ausgeführt werden, auf physischen Ressourcen zu virtualisieren, die eine Kombination von Industriestandardserverhardware, Speicherhardware oder Switches umfassen. Mit anderen Worten können NFV-Systeme verwendet werden, um virtuelle oder rekonfigurierbare Implementierungen einer oder mehrerer Komponenten/Funktionen des CN 2042 auszuführen.
  • Das CN 2042 ist als mit einem Anwendungsserver 2050 und einem Netzwerk 2050 über eine IP-Kommunikationsschnittstelle 2055 kommunikativ verbunden dargestellt. Der eine oder die mehreren Server 2050 umfassen ein oder mehrere physische und/oder virtualisierte Systeme zum Bereitstellen von Funktionalität (oder Diensten) für einen oder mehreren Clients (zum Beispiel UEs 2021 und IoT-Vorrichtungen 2011) über ein Netzwerk. Der eine oder die mehreren Server 2050 können verschiedene Computervorrichtungen mit Rack-Rechenarchitekturkomponente(n), Tower-Rechenarchitekturkomponente(n), Blade-Rechenarchitekturkomponente(n) und/oder dergleichen umfassen. Der eine oder die mehreren Server 2050 können einen Cluster von Servern, eine Serverfarm, einen Cloud-Computing-Dienst oder eine andere Gruppierung oder einen anderen Pool von Servern darstellen, die sich in einem oder mehreren Rechenzentren befinden können. Der eine oder die mehreren Server 2050 können auch mit einer oder mehreren (nicht gezeigten) Datenspeichervorrichtungen verbunden oder anderweitig mit diesen assoziiert sein. Zudem können der eine oder die mehreren Server 2050 ein Betriebssystem (OS) umfassen, das ausführbare Programmanweisungen für die allgemeine Verwaltung und den allgemeinen Betrieb der einzelnen Servercomputervorrichtungen bereitstellt, und sie können ein computerlesbares Medium umfassen, das Anweisungen speichert, die, wenn sie durch einen Prozessor der Server ausgeführt werden, den Servern ermöglichen können, ihre vorgesehenen Funktionen auszuführen. Geeignete Implementierungen für das OS und die allgemeine Funktionalität von Servern sind bekannt oder kommerziell erhältlich und sind vom Durchschnittsfachleuten leicht zu implementieren. Allgemein bieten der oder die Server 2050 Anwendungen oder Dienste an, die IP-/Netzwerkressourcen verwenden. Als Beispiele können der eine oder die mehreren Server 2050 Verkehrsverwaltungsdienste, Cloud-Analytik, Content-Streaming-Dienste, immersive Spielerfahrungen, soziales Netzwerken und/oder Mikroblogg-Dienste und/oder andere ähnliche Dienste bereitstellen. Zusätzlich dazu können die verschiedenen Dienste, die durch den einen oder die mehreren Server 2050 bereitgestellt werden, Initiieren und Steuern von Software- und/oder Firmware-Aktualisierungen für Anwendungen oder einzelne Komponenten umfassen, die durch die UEs 2021 und die IoT-Vorrichtungen 2011 implementiert werden. Der eine oder die mehreren Server 2050 können auch dazu konfiguriert sein, einen oder mehrere Kommunikationsdienste (zum Beispiel Voice-over-Internet-Protokoll-(VoIP-)Sitzungen, PTT-Sitzungen, Gruppenkommunikationssitzungen, soziale Networking-Dienste usw.) für die UEs 2021 und IoT-Vorrichtungen 2011 über das CN 2042 zu unterstützen.
  • Die Funkzugangstechnologien (RATs), die von den NANs 2031-2033, die UEs 2021, 2011 und die anderen Elemente in 20 bereitgestellt werden, können eine oder mehrere V2X-RATs umfassen, die diesen Elementen ermöglichen, direkt miteinander, mit Infrastrukturgeräten (z. B. NANs 2031-2033) und anderen Vorrichtungen zu kommunizieren. Eine beliebige Anzahl von V2X-RATs kann für V2X-Kommunikation verwendet werden. Bei einigen Implementierungen können mindestens zwei unterschiedliche V2X-RATs verwendet werden, darunter WLAN-V2X-(W-V2X-)RAT basierend auf IEEE V2X-Technologien (z. B. DSRC für die USA und ITS-G5 für Europa) und 3GPP-C-V2X-RAT (z. B. LTE, 5G/NR und darüber hinaus).
  • Die W-V2X-RATs umfassen zum Beispiel IEEE 1609.0-2019, „IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture“ (2019-04-10) („[IEEE16090]“), SAE Int '1, „V2X Communications Message Set Dictionary“ (früher „Dedicated Short Range Communication (DSRC) Message Set Dictionary“) (2020-07-23) („[J2735_202007]“), Intelligente Transport Systems im 5-GHz-Frequenzband (ITS-G5), das IEEE 802.11p-Protokoll (wobei es sich um den Schicht-1-(L1-) und Schicht-2-(L2-)Teil von WAVE, DSRC und ITS-G5 handelt) und manchmal IEEE 802.16-2017, „IEEE Standard for Air Interface for Broadband Wireless Access Systems“ (manchmal als „Worldwide Interoperability for Microwave Access“ oder „WiMAX“ bezeichnet) (2018-03-02) („[WiMAX]“). Der Begriff „DSRC“ bezieht sich auf Fahrzeugkommunikationen im 5,9-GHz-Frequenzband, das im Allgemeinen in den Vereinigten Staaten verwendet wird, während „ITS-G5“ sich auf Fahrzeugkommunikationen im 5,9-GHz-Frequenzband in Europa bezieht. Da eine beliebige Anzahl verschiedener RATs anwendbar ist (einschließlich IEEE 802.11p-basierter RATs), die in einem beliebigen geographischen oder politischen Gebiet verwendet werden können, können die Begriffe „DSRC“ (unter anderen Gebieten in den USA verwendet) und „ITS-G5“ (unter anderen Gebieten in Europa verwendet) durch diese Offenbarung hindurch austauschbar verwendet werden. Die Zugangsschicht für die ITS-G5-Schnittstelle ist in ETSI EN 302 663 V1.3.1 (2020-01) (im Folgenden „[EN302663]“) skizziert und beschreibt die Zugangsschicht der ITS-S-Referenzarchitektur. Die ITS-G5-Zugangsschicht umfasst [IEEE80211] (die jetzt IEEE 802.11p miteinbezieht) und IEEE 802.2 Logical Link Control (LLC) („[IEEE8022]“) und/oder IEEE/ISO/IEC 8802-2-1998-Protokolle sowie Merkmale für DCC-Verfahren (DCC - Decentralized Congestion Control), die in ETSI TS 102 687 V1.2.1 (2018-04) („[TS102687]“) erörtert werden. Die Zugangsschicht für 3GPP-LTE-V2X-basierte Schnittstelle(n) ist (sind) unter anderem in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS 23.285 v16.2.0 (2019-12) umrissen; und 3GPP 5G/NR-V2X ist unter anderem in 3GPP TR 23.786 v16.1.0 (2019-06) und 3GPP TS 23.287 v16.2.0 (2020-03) umrissen.
  • Die Cloud 2044 kann eine Cloud-Computing-Architektur/-Plattform darstellen, die einen oder mehrere Cloud-Computing-Dienste bereitstellt. Cloud-Computing bezieht sich auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Pool von gemeinsam nutzbaren Rechenressourcen mit Self-Service-Bereitstellung und -Verwaltung bei Bedarf und ohne aktive Verwaltung durch Benutzer. Bei Rechenressourcen (oder einfach „Ressourcen“) handelt es sich um jede physische oder virtuelle Komponente mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder -netzwerks oder die Verwendung solcher Komponenten. Beispiele für Ressourcen umfassen Nutzung von/Zugriff auf Server, Prozessor(en), Datenspeichergeräte, Arbeitsspeichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, (periphere) Eingabe-/Ausgabevorrichtungen, mechanische Vorrichtungen, Netzwerkverbindungen (z. B. Kanäle/Links, Ports, Netzwerkbuchsen usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen für eine Zeitdauer. Cloud-Computing stellt Cloud-Computing-Dienste (oder Cloud-Dienste) bereit, bei denen es sich um eine oder mehrere über Cloud-Computing angebotene Fähigkeiten handelt, die unter Verwendung einer definierten Schnittstelle (z. B. einer API oder dergleichen) aufgerufen werden. Einige Fähigkeiten der Cloud 2044 umfassen Anwendungsfähigkeitstyp, Infrastrukturfähigkeitstyp und Plattformfähigkeitstyp. Ein Cloud-Fähigkeitstyp ist eine Klassifizierung der Funktionalität, die für einen Cloud-Dienstkunden (z. B. einen Benutzer der Cloud 2044) durch einen Cloud-Dienst basierend auf den verwendeten Ressourcen bereitgestellt wird. Der Anwendungsfähigkeitstyp ist ein Cloud-Fähigkeitstyp, bei dem der Cloud-Dienstkunde die Anwendungen des Cloud-Dienstanbieters verwenden kann; der Infrastrukturfähigkeitstyp ist ein Cloud-Fähigkeitstyp, bei dem der Cloud-Dienstkunde Verarbeitungs-, Speicherungs- oder Vernetzungsressourcen bereitstellen und verwenden kann; und der Plattformfähigkeitstyp ist ein Cloud-Fähigkeitstyp ist, bei dem der Cloud-Dienstkunde vom Kunden erstellte oder vom Kunden erworbene Anwendungen unter Verwendung einer oder mehrerer Programmiersprachen und einer oder mehrerer Ausführungsumgebungen, die vom Cloud-Dienstanbieter unterstützt werden, bereitstellen, verwalten und ausführen kann. Cloud-Dienste können in Kategorien eingeteilt werden, die einen gemeinsamen Satz von Qualitäten besitzen. Einige Cloud-Dienstkategorien, die Cloud 2044 bereitstellen kann, umfassen zum Beispiel
  • Communications as a Service (CaaS), der eine Cloud-Dienstkategorie ist, die Echtzeitinteraktions- und Zusammenarbeitsdienste umfasst; Compute as a Service (CompaaS), der eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Verarbeitungsressourcen umfasst, die benötigt werden, um Software bereitzustellen und auszuführen; Database as a Service (DaaS), der eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Datenbanksystem-Verwaltungsdiensten umfasst; Data Storage as a Service (DSaaS), der eine Cloud-Dienstkategorie ist, die Bereitstellung und Verwendung von Datenspeicherung und verwandten Fähigkeiten umfasst; Firewall as a Service (FaaS), der eine Cloud-Dienstkategorie ist, die die Bereitstellung von Firewall und Netzwerkverkehrsverwaltungsdiensten umfasst; Infrastructure as a Service (IaaS), der eine Cloud-Dienstkategorie ist, die den Typ von Infrastrukturfähigkeiten umfasst; Network as a Service (NaaS), der eine Cloud-Dienstkategorie ist, die Transportkonnektivität und verwandte Netzwerkfähigkeiten umfasst; Platform as a Service (PaaS), der eine Cloud-Dienstkategorie ist, die den Typ von Plattformfähigkeiten umfasst; Software as a Service (SaaS), der eine Cloud-Dienstkategorie ist, die den Typ von Anwendungsfähigkeiten umfasst; Security as a Service, der eine Cloud-Dienstkategorie ist, die das Bereitstellen von Netzwerk- und Informationssicherheitsdiensten (Infosec) umfasst; und/oder andere ähnliche Cloud-Dienste.
  • Zusätzlich oder alternativ kann die Cloud 2044 ein Netzwerk darstellen, wie etwa das Internet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), ein drahtloses lokales Netzwerk (WLAN) oder ein drahtloses Weitverkehrsnetzwerk (WWAN), einschließlich proprietärer und/oder Unternehmensnetzwerke für eine Firma oder Organisation oder Kombinationen davon.
  • Hierbei umfasst die Cloud 2044 ein oder mehrere Netzwerke, die Computer, Netzwerkverbindungen zwischen den Computern und Softwareroutinen umfassen, um Kommunikation zwischen den Computern über Netzwerkverbindungen zu ermöglichen. In dieser Hinsicht umfasst die Cloud 2044 ein oder mehrere Netzwerkelemente, die einen oder mehrere Prozessoren, Kommunikationssysteme (die zum Beispiel Netzwerkschnittstellensteuerungen, einen oder mehrere Sender/Empfänger, die mit einer oder mehreren Antennen verbunden sind, usw. umfassen) und computerlesbare Medien umfassen können. Beispiele für solche Netzwerkelemente können drahtlose Zugangspunkte (WAPs), Heim-/Geschäftsserver (mit oder ohne HF-Kommunikationsschaltungsanordnung), Router, Switches, Hubs, Funkbaken, Basisstationen, Pikozellen- oder Kleinzellen-Basisstationen, Backbone-Gateways und/oder beliebige andere ähnliche Netzwerkvorrichtungen umfassen. Eine Verbindung mit der Cloud 2044 kann über eine drahtgebundene oder eine drahtlose Verbindung unter Verwendung der verschiedenen im Folgenden erörterten Kommunikationsprotokolle erfolgen. Mehr als ein Netzwerk kann an einer Kommunikationssitzung zwischen den veranschaulichten Vorrichtungen beteiligt sein. Eine Verbindung mit der Cloud 2044 kann erfordern, dass die Computer Softwareroutinen ausführen, die zum Beispiel die sieben Schichten des OSI-Modells eines Computernetzwerks oder eines Äquivalents in einem drahtlosen (zellularen) Telefonnetzwerk ermöglichen. Die Cloud 2044 kann verwendet werden, um Kommunikation mit relativ großer Reichweite, beispielsweise zwischen dem einen oder den mehreren Servern 2050 und einem oder mehreren UEs 2021 und einer oder mehreren IoT-Vorrichtungen 2011, zu ermöglichen. Zusätzlich oder alternativ kann die Cloud 2044 das Internet, ein oder mehrere zellulare Netzwerke, lokale Netzwerke oder Weitverkehrsnetzwerke, einschließlich proprietärer und/oder Unternehmensnetzwerke, ein TCP-/Internetprotokoll-basiertes (IP-basiertes) Netzwerk oder Kombinationen davon darstellen. Bei diesen Implementierungen kann die Cloud 2044 mit einem Netzwerkbetreiber assoziiert sein, der Geräte und andere Elemente besitzt oder steuert, die notwendig sind, um netzwerkbezogene Dienste bereitzustellen, wie etwa eine oder mehrere Basisstationen oder Zugangspunkte, einen oder mehrere Server zum Routen von digitalen Daten oder Telefonanrufen (z. B. ein Kernnetzwerk oder Backbone-Netzwerk) usw. Die Backbone-Verbindungen 2055 können eine beliebige Anzahl von drahtgebundenen oder drahtlosen Technologien umfassen und Teil eines LAN, eines WAN oder des Internets sein. In einem Beispiel sind die Backbone-Verbindungen 2055 Backbone-Faserverbindungen, die niedrigere Ebenen von Dienstanbietern mit dem Internet, wie etwa dem CN 2012 und der Cloud 2044, koppeln.
  • Zusätzlich oder alternativ können die verschiedenen Zugangstechnologien zellulare Technologie, wie LTE, MuLTEfire und/oder NR/5G (wie z. B. von Funkzugangsnetzwerkknoten (RAN-Knoten) 2031-2032 bereitgestellt), WLAN-(z. B. WiFi®-)Technologien (wie z.B. von einem Zugangspunkt (AP) 2033 bereitgestellt) und/oder dergleichen umfassen. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistung in unterschiedlichen Szenarien hängt von der Auswahl der Zugangsnetzwerke (z. B. WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokollen (z. B. Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) ab.
  • Die Edge-Rechenknoten 2036 können ein Edge-System 2035 (oder Edge-Netzwerk 2035) umfassen oder Teil davon sein. Die Edge-Rechenknoten 2036 können auch als „Edge-Hosts 2036“ oder „Edge-Server 2036“ bezeichnet werden. Das Edge-System 2035 umfasst eine Sammlung von Edge-Servern 2036 (z. B. MEC-Hosts/Servern 2036-1 und 2036-2 von Figur XP1) und Edge-Verwaltungssystemen (in 20 nicht dargestellt), die notwendig sind, um Edge-Computing-Anwendungen (z. B. MEC-Anwendungen XP136 von Figur XP1) innerhalb eines Betreibernetzwerks oder eines Teilsatzes eines Betreibernetzwerks auszuführen. Die Edge-Server 2036 sind physische Computersysteme, die eine Edge-Plattform (z. B. MEC-Plattform XP137 von Figur XP1) und/oder Virtualisierungsinfrastruktur umfassen und Rechen-, Speicher- und Netzwerkressourcen für Edge-Computing-Anwendungen bereitstellen können. Jeder der EdgeServer 2036 ist an einem Rand eines entsprechenden Zugangsnetzwerks angeordnet und dazu eingerichtet, Rechenressourcen und/oder verschiedene Dienste (z. B. Rechenaufgaben- und/oder Arbeitslastabladung, Cloud-Computing-Fähigkeiten, IT-Dienste und andere ähnliche Ressourcen und/oder Dienste, wie hierin erörtert) in relativ enger Nähe zu Zwischenknoten 2020 und/oder Endpunkten 2010 bereitzustellen Die VIs der Edge-Server 2036 stellen virtualisierte Umgebungen und virtualisierte Ressourcen für die Edge-Hosts bereit, und die Edge-Computing-Anwendungen können als VMs und/oder Anwendungscontainer auf der VI laufen. Eine beispielhafte Implementierung des Edge-Systems 2035 ist ein MEC-System 2035, das im Folgenden mit Bezug auf die Figuren XP1-XP2 ausführlicher erörtert wird. Es versteht sich, dass die offenbarten MEC-Systeme und Dienstbereitstellungsbeispiele nur ein veranschaulichendes Beispiel von Edge-Computing-Systemen/-Netzwerken 2035 sind, und dass die vorliegende Offenbarung auf viele andere Edge-Computing/-Netzwerktechnologien in verschiedenen Kombinationen und Layouts von Vorrichtungen anwendbar sein kann, die sich am Rand eines Netzwerks befinden, einschließlich der verschiedenen Edge-Computing-Netzwerke/-Systeme, die hier beschrieben sind. Ferner können sich die hier offenbarten Techniken auf andere IoT-Edge-Netzwerksysteme und -Konfigurationen beziehen, und es können auch andere Zwischenverarbeitungsentitäten und Architekturen auf die vorliegende Offenbarung anwendbar sein.
  • Wie durch 20 dargestellt, ist jeder der NANs 2031, 2032 und 2033 ortsgleich mit den Edge-Rechenknoten (oder Edge-Servern) 2036a, 2036b bzw. 2036c angeordnet. Diese Implementierungen können Kleinzellen-Clouds (SCCs - Small-Cell Clouds) sein, bei denen ein Edge-Rechenknoten 2036 ortsgleich mit einer Kleinzelle (z. B. Pikozelle, Femtozelle usw.) angeordnet ist, oder sie können mobile Mikro-Clouds (MCCs) sein, bei denen ein Edge-Rechenknoten 2036 ortsgleich mit einer Makrozelle (z. B. eNB, gNB usw.) angeordnet ist. Der Edge-Rechenknoten 2036 kann in einer Vielzahl von anderen Anordnungen als der in 1 gezeigten bereitgestellt werden. In einem ersten Beispiel sind mehrere NANs 2031-2033 ortsgleich mit einem Edge-Rechenknoten 2036 angeordnet oder anderweitig damit kommunikativ gekoppelt. In einem zweiten Beispiel können die Edge-Server 2036 ortsgleich angeordnet sein oder durch RNCs betrieben werden, was für Legacy-Netzwerkbereitstellungen, wie etwa 3G-Netzwerke, der Fall sein kann. In einem dritten Beispiel können die Edge-Server 2036 an Zellaggregationsstandorten oder an Multi-RAT-Aggregationspunkten bereitgestellt werden, die sich entweder innerhalb eines Unternehmens befinden oder in öffentlichen Abdeckungsbereichen verwendet werden können In einem vierten Beispiel können die Edge-Server 2036 am Rand des CN 2042 bereitgestellt werden. Diese Implementierungen können in Follow-Me-Clouds (FMC) verwendet werden, wobei Cloud-Dienste, die an verteilten Rechenzentren ausgeführt werden, den UEs 221 folgen, während sie durch das Netzwerk roamen.
  • In jeder der vorstehend erörterten Implementierungen stellen die Edge-Server 2036 eine verteilte Rechenumgebung für Anwendungs- und Diensthosting bereit, und sie stellen auch Speicher- und Verarbeitungsressourcen bereit, so dass Daten und/oder Inhalt in unmittelbarer Nähe zu Teilnehmern (z. B. Benutzern von UEs 2021, 2011) für schnellere Antwortzeiten verarbeitet werden können. Die Edge-Server 2036 unterstützen unter anderem auch Mehrmandantenfähigkeits-Laufzeit- und Hosting-Umgebung(en) für Anwendungen, einschließlich virtueller Geräteanwendungen, die als verpackte Bilder einer virtuellen Maschine (VM) geliefert werden können, Middleware-Anwendungs- und -Infrastrukturdienste, Inhaltslieferdienste einschließlich Inhalts-Caching, Mobile-Big-Data-Analytik und Abladen von Berechnungen. Das Abladen von Berechnungen umfasst das Abladen rechnerischer Aufgaben, Arbeitslasten, Anwendungen und/oder Dienste von den UEs 2011, 2021, dem CN 2042, der Cloud 2044 und/oder den Server(n) 2050 auf die Edge-Server 2036 oder umgekehrt. Zum Beispiel kann eine Vorrichtungsanwendung oder Client-Anwendung, die in einem UE 2021, 2011 betrieben wird, Anwendungsaufgaben oder Arbeitslasten auf einen oder mehrere Edge-Server 2036 abladen. In einem anderen Beispiel kann ein Edge-Server 136 Anwendungsaufgaben oder Arbeitslasten auf ein oder mehrere UEs 121, 111 abladen (z. B. für verteilte ML-Berechnung oder dergleichen).
  • 21 ist ein Blockdiagramm 2100, das einen Überblick über eine Konfiguration für Edge Computing zeigt, die eine Verarbeitungsschicht umfasst, die in vielen der folgenden Beispiele als „Edge-Cloud“ bezeichnet wird. Wie dargestellt, befindet sich die Edge-Cloud 2110 ortsgleich an einem Edge-Standort, beispielsweise an einem Netzwerkzugangsknoten (NAN) 2140 (z. B. einem Zugangspunkt oder einer Basisstation), einem lokalen Verarbeitungshub 2150 oder einer Zentrale 2120, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen umfassen. Die Edge-Cloud 2110 befindet sich viel näher an den Datenquellen 2160 (z. B. autonomen Fahrzeugen 2161, Benutzergeräte 2162, gewerblichen und industriellen Einrichtungen 163, Videoaufnahmevorrichtungen 2164, Drohnen 2165, Vorrichtungen intelligenter Städte und Gebäude 2166, Sensoren und IoT-Vorrichtungen 2167 usw.) der Endpunkte (Konsumenten und Erzeuger) als das Cloud-Rechenzentrum 2130. Rechen-, Arbeitsspeicher- und Datenspeicherressourcen, die an den Rändern in der Edge-Cloud 110 angeboten werden, sind entscheidend für das Bereitstellen von Antwortzeiten ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zum Cloud-Rechenzentrum 130, wodurch neben anderen Vorteilen Energieverbrauch und Gesamtnetzwerknutzung verbessert werden.
  • Rechen-, Arbeitsspeicher- und Datenspeicher- sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (z. B. geringere Verfügbarkeit von Verarbeitungsressourcen an Konsumentenendpunktvorrichtungen als an einer Basisstation als an einer Zentrale). Je näher der Edge-Standort sich jedoch zum Endpunkt (z. B. Benutzergerät (UE)) befindet, desto mehr sind Raum und Leistung oft eingeschränkt. Daher versucht Edge Computing, die Anzahl von Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sowohl geographisch als auch bezüglich netzwerkinterner Zugriffszeit näher angeordnet sind, zu reduzieren. Auf diese Weise versucht Edge Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
  • Im Folgenden werden Aspekte einer Edge-Cloud-Architektur beschrieben, die mehrere potentielle Bereitstellungen abdeckt und Einschränkungen behandelt, die einige Netzwerkbetreiber oder Dienstanbieter in ihren Infrastrukturen aufweisen können. Diese umfassen eine Vielfalt von Konfigurationen, die auf dem Edge-Standort basieren (da Edges auf einer Basisstationsebene zum Beispiel eine stärker eingeschränkte Performance und stärker eingeschränkte Fähigkeiten in einem Mehrmandantenszenario aufweisen können); Konfigurationen, die auf dem Typ von Rechen-, Arbeitsspeicher-, Datenspeicher-, Fabric-, Beschleunigungs- oder ähnlichen Ressourcen basieren, die für Edge-Standorte, Ebenen von Standorten oder Gruppen von Standorten zur Verfügung stehen; die Dienst-, Sicherheits-, Verwaltungs- und Orchestrierungsfähigkeiten; und damit verbundene Ziele zum Erreichen der Nutzbarkeit und Performance von Enddiensten. Diese Bereitstellungen können Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Timing-Charakteristiken als „Near-Edge“-, „Close-Edge“-, „Local-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten betrachtet werden können.
  • Edge Computing ist ein sich entwickelndes Paradigma, wobei Computing an oder näher zur „Edge“ (Rand) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z. B. x86-, ARM-, Nividia- oder eine andere CPU-/GPU-basierte Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert wird, die sich viel näher an Endpunktvorrichtungen befinden, die die Daten erzeugen und konsumieren. Edge-Gateway-Server können zum Beispiel mit Pools von Arbeitsspeicher- und Datenspeicherressourcen ausgestattet sein, um Berechnung für Anwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen in Echtzeit 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 weitere Daten über Backhaul-Netzwerke zu kommunizieren. Oder als ein anderes Beispiel kann Netzverwaltungshardware der Zentrale durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Konsumentenfunktionen für verbundene Vorrichtungen anbietet. Alternativ kann auch eine Anordnung mit Hardware kombiniert mit virtualisierten Funktionen, allgemein als Hybrid-Anordnung bezeichnet, erfolgreich implementiert werden. Innerhalb von Edge-Computing-Netzwerken kann es bei Diensten Szenarien, in welchen die Rechenressource zu den Daten „bewegt“ wird, sowie Szenarien geben, in welchen die Daten zur Rechenressource „bewegt“ werden. Oder als ein Beispiel können Rechen-, Beschleunigungs- und Netzwerkressourcen der Basisstation Dienste bereitstellen, um die Arbeitslastanforderungen auf Bedarfsbasis zu skalieren, indem ruhende Kapazität (Abonnement, Kapazität auf Abruf) aktiviert wird, um Ausnahme- und Notfälle zu handhaben oder Lebensdauer für bereitgestellte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
  • 22 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. Insbesondere stellt 22 Beispiele für Rechenanwendungsfälle 2205 dar, welche die Edge-Cloud 2110 unter mehreren veranschaulichenden Schichten von Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunktschicht (Vorrichtungen und Dinge) 200, die auf die Edge-Cloud 110 zugreift, um Datenerzeugungs-, Analyse- und Datenverbrauchsaktivitäten durchzuführen. Die Edge-Cloud 110 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Vorrichtungsschicht 210 mit Gateways, Vor-Ort-Servern oder Netzwerkgeräten (Knoten 215), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 220, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerkhubs, regionale Rechenzentren (RZ) oder lokale Netzwerkgeräte (Gerät 225); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 212, nicht im Detail veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 2110 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
  • Beispiele für Latenz, die aus Netzwerkkommunikationsentfernungs- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn inmitten der Endpunktschicht 2200, unter 5 ms an der Edge-Vorrichtungsschicht 2210, bis sogar zwischen 10 und 40 ms, wenn mit Knoten an der Netzwerkzugangsschicht 2220 kommuniziert, reichen. Jenseits der Edge-Cloud 2110 befinden sich Schichten des Kernnetzwerks 2230 und des Cloud-Datenzentrums 2240, jeweils mit zunehmender Latenz (z. B. zwischen 50-60 ms an der Kernnetzwerkschicht 2230 bis 100 oder mehr ms an der Cloud-Datenzentrumsschicht). Infolgedessen werden Operationen an einem Kernnetzwerk-Datenzentrum 2235 oder einem Cloud-Datenzentrum 2245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Verwendungsfälle 2205 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 Teile des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als „Close-Edge“-, „Local-Edge“-, „Near-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetzwerk-Datenzentrums 2235 oder eines Cloud-Datenzentrums 2245 eine Zentrale oder ein Inhaltsdatennetzwerk als innerhalb einer „Near-Edge“-Schicht („near“ (nahe) an der Cloud, mit hohen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Verwendungsfälle 2205 kommuniziert wird) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Vor-Ort-Server oder ein Netzwerk-Gateway als innerhalb einer „Far-Edge“-Schicht („far“ (fern) von der Cloud entfernt, mit niedrigen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Verwendungsfälle 2205 kommuniziert wird) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als ein „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 2200-2240 gemessen.
  • Die diversen Verwendungsfälle 2205 können aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, auf Ressourcen unter Nutzungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 2110 ausgeführt werden, variierende Voraussetzungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstqualität (QoS) (z. B. kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Reaktionszeitanforderung aufweisen; oder eine Performance-Empfindlichkeit/-Engpass kann je nach Anwendung an einer Rechen-/Beschleuniger-, Arbeitsspeicher-, Datenspeicher- oder Netzwerkressource existieren); (b) Zuverlässigkeit und Ausfallsicherheit (z. B. müssen einige Eingangsströme bearbeitet werden und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wohingegen einige andere Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physikalischer Beschränkungen (z. B. Leistung, Kühlung und Formfaktor).
  • Die Ende-zu-Ende-Dienstansicht für diese Verwendungsfälle umfasst das Konzept eines Dienstflusses und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstanforderungen für die Entität an, die den Dienst konsumiert, sowie die assoziierten Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Unternehmensfunktions- und Unternehmensebenenanforderungen. Die Dienste, die mit den beschriebenen „Begriffen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihr vereinbartes 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 das gesamte Transaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
  • Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge Computing innerhalb der Edge-Cloud 2110 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 2205 (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 (VNFs (Virtual Network Functions), FaaS (Function as a Service), Edge as a Service (EaaS), Standardprozesse usw.), die herkömmliches Cloud-Computing aufgrund von Latenz oder anderen Einschränkungen nicht nutzen können.
  • Mit den Vorteilen von 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 Pooling von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Die Edge kann leistungs- und kühlungseingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen berücksichtigt werden muss, die die meiste Leistung verbrauchen.. Es kann inhärente Leistung-Leistungsfähigkeits-Kompromisse in diesen gepoolten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen höhere Leistung eine größere Speicherbandbreite benötigt. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Rootof-Trust-Funktionen auch erforderlich, da Edge-Orte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (z. B. wenn sie an einem Drittparteistandort untergebracht sind). Solche Probleme werden in der Edge-Cloud 2110 in einem Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriff-Umfeld vergrößert, in dem Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Stakeholder, Verwendungsfälle und Dienste ändert.
  • Auf einer allgemeineren Ebene kann ein Edge-Computing-System so beschrieben werden, dass es eine beliebige Anzahl von Bereitstellungen auf den zuvor erörterten Schichten umfasst, die in der Edge-Cloud 2110 arbeiten (Netzwerkschichten 2200-2240) und die eine Koordination der Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kernrechenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Computing-Systems durch oder im Auftrag eines Telekommunikationsdienstanbieters („telco“) bereitzustellen, oder „TSP“), eines Internet-der-Dinge-Dienstanbieters, des 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 bei Orchestrierung, um Dienstziele zu erfüllen.
  • Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -vorrichtung, -gerät oder ein anderes zum Kommunizieren als ein Erzeuger oder Konsument von Daten fähiges Ding realisiert sein. Hier bezieht sich „Erzeuger“ auf eine Entität oder ein Element, die/das für andere Entitäten oder Elemente auf demselben Edge-Knoten oder auf verschiedenen Edge-Knoten einen Dienst bereitstellt, und „Konsument“ bezieht sich auf eine Entität oder ein Element, die/das Endbenutzerverkehr und/oder Benutzerdienste von einem Erzeuger auf denselben oder verschiedenen Edge-Knoten konsumieren kann. Zum Beispiel kann eine Erzeuger-App Standortdienste, Abbildungsdienste, Transcodierungsdienste, AI/ML-Dienste und/oder andere ähnliche Dienste bereitstellen. Zusätzlich oder alternativ dazu kann es sich bei einer Konsumenten-App um einen Content-Delivery-Network-(CDN-)Knoten, AR- oder VR-Apps, Spiele-Apps und/oder eine andere Art von App handeln. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie im Edge-Computing-System verwendet, nicht notwendigerweise, dass solch ein Knoten oder solch eine Vorrichtung in einer Client- oder einer Agenten-/Minion-/Follower-Rolle arbeitet; vielmehr bezieht sich jeder der Knoten oder jede der Vorrichtungen im Edge-Computing-System auf einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen umfassen, um die Edge-Cloud 2110 zu ermöglichen oder zu verwenden.
  • Daher ist die Edge-Cloud 2110 aus Netzwerkkomponenten und Funktionsmerkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 2210-2230 betrieben werden.. Die Edge-Cloud 2110 kann somit als eine beliebige Art von Netzwerk realisiert sein, die Edge-Computing- und/oder Speicherressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z. B. mobilen Rechenvorrichtungen, IoT-Vorrichtungen, intelligenten Vorrichtungen usw.) befinden, die hier erörtert werden. Mit anderen Worten kann die Edge-Cloud 2110 als eine „Edge“ gedacht werden, welche die Endpunktvorrichtungen und herkömmliche Netzwerkzugangspunkte verbindet, die als ein Eingangspunkt in Dienstanbieter-Kernnetzwerke dienen, einschließlich Mobilträgernetzwerken (z. B. GSM-Netzwerken (GSM - Global System for Mobile Communications), LTE-Netzwerken (LTE - Long-Term Evolution), 5G/6G-Netzwerken usw.), während auch Speicher- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (z. B. WiFi, drahtlose, drahtgebundene Weitverkehrsnetzwerke, einschließlich optischer Netze) können anstelle von oder in Kombination mit solchen 3GPP-Trägernetzwerken ebenfalls verwendet werden.
  • Die Netzwerkkomponenten der Edge-Cloud 2110 können Server, mandantenfähige Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 110 eine Geräterechenvorrichtung umfassen, die eine eigenständige elektronische Vorrichtung ist und ein Gehäuse, ein Chassis, einen Behälter oder eine Hülle umfasst. Unter Umständen kann das Gehäuse für Transportfähigkeit bemessen sein, so dass es von einem Menschen getragen und/oder versandt werden kann. Alternativ kann es sich um ein kleineres Modul handeln, das beispielsweise zum Einbau in ein Fahrzeug geeignet ist. Beispielhafte Gehäuse können Materialien umfassen, die eine oder mehrere Außenflächen bilden, die den Inhalt des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (z. B. EMI, Vibration, extreme Temperaturen) umfassen und/oder Tauchfähigkeit ermöglichen kann. Beispielhafte Gehäuse können Leistungsschaltungsanordnung umfassen, um Leistung für stationäre und/oder tragbare Implementierungen bereitzustellen, wie Wechselstromeingänge, Gleichstromeingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnung, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Kleinere, modulare Implementierungen können auch eine erweiterbare oder eingebettete Antennenanordnung für drahtlose Kommunikation umfassen. Beispielhafte Gehäuse und/oder Oberflächen davon können Montagehardware umfassen oder damit verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (z. B. Masten, Antennenstrukturen usw.) und/oder Racks (z. B. Server-Racks, Blade-Halterungen 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.) unterstützen. Ein oder mehrere solcher 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 Gehäuse 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 Fortsätze usw.). Unter einigen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen umfassen, wie etwa Benutzerschnittstellenhardware (z. B. Tasten, Schalter, Wählscheiben, Schieber usw.). Unter einigen Umständen umfassen beispielhafte Gehäuse 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-Anschlüsse (z. B. USB) usw. umfassen. Unter einigen Umständen sind Edge-Vorrichtungen Vorrichtungen, die im Netzwerk für einen spezifischen Zweck (z. B. eine Verkehrsampel) dargeboten werden, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Solche Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein, und sie können mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für ihren primären Zweck geeignet ist; aber dennoch für andere Rechenaufgaben verfügbar ist, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen umfassen Vorrichtungen des Internets der Dinge. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten umfassen, um lokale Belange, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Stromprobleme, physische und Netzwerksicherheit usw., zu handhaben. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 31 beschrieben. Die Edge-Cloud 2110 kann auch einen oder mehrere Server und/oder einen oder mehrere mandantenfähige Server umfassen. Solch ein Server kann ein Betriebssystem und eine virtuelle Rechenumgebung umfassen. Eine virtuelle Rechenumgebung kann einen Hypervisor umfassen, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (erzeugt, bereitstellt, zerstört usw.). Solche virtuellen Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, anderer Code oder andere Skripte ausgeführt werden können, während sie von einer oder mehreren anderer Anwendungen, anderer Software, anderen Codes oder anderer Skripten isoliert sind.
  • In 23 tauschen verschiedene Client-Endpunkte 2310 (in Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 2310 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anfragen und Antworten 2322 durch ein Vor-Ort-Netzwerksystem 2332 ausgetauscht werden. Einige Client-Endpunkte 2310, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 2324 durch einen Zugangspunkt (z. B. Mobilfunkturm) 2334 ausgetauscht werden. Einige Client-Endpunkte 2310, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anfragen und Antworten 2326 über ein drahtloses Fahrzeugnetzwerk durch ein an der Straße angeordnetes Netzwerksystem 2336 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 2342, 2344 innerhalb der Edge-Cloud 2110 bereitstellen, um Verkehr und Anforderungen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 2110 verschiedene Rechen- und Speicherungsressourcen einsetzen, wie etwa bei Edge-Aggregationsknoten 2340, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 2340 und andere Systeme der Edge-Cloud 2110 sind mit einer Cloud oder einem Datenzentrum 2360 verbunden, die/das ein Backhaul-Netzwerk 2350 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 2340 und der Aggregationspunkte 2342, 2344, einschließlich jener, die auf einem einzigen Server-Framework bereitgestellt werden, können auch innerhalb der Edge-Cloud 2110 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
  • 24 veranschaulicht Bereitstellung und Orchestrierung für virtualisierte und Container-basierte Edge-Konfigurationen über ein Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten (z. B. Benutzern, Anbietern) betrieben wird. Insbesondere stellt 24 die Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Computing-System 400 dar, um Anfragen und Antworten für verschiedene Client-Endpunkte 410 (z. B. Systeme intelligenter Städte/Gebäude, Mobilvorrichtungen, Rechenvorrichtungen, Geschäfts-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hierbei stellen die virtuellen Edge-Instanzen 2432, 2434 (oder virtuellen Edges) Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf ein Cloud/Rechenzentrum 440 für Anfragen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
  • In 24 umfassen diese virtuellen Edge-Instanzen: eine erste virtuelle Edge 2432, die einem ersten Mandanten (Mandant 1) angeboten wird, der die erste Kombination von Edge-Speicherung, -Computing und -Diensten anbietet; und eine zweite virtuelle Edge 2434, die eine zweite Kombination von Edge-Speicherung, -Computing und -Diensten anbietet. Die virtuellen Edge-Instanzen 2432, 2434 sind unter den Edge-Knoten 2422, 2424 verteilt und können Szenarien umfassen, in denen eine Anfrage und eine Antwort von den gleichen oder verschiedenen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 2422, 2424 zum Arbeiten auf eine verteilte, aber koordinierte Weise findet basierend auf Edge-Bereitstellungsfunktionen 2450 statt. Die Funktionalität der Edge-Knoten 2422, 2424 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten entsteht basierend auf Orchestrierungsfunktionen 2460.
  • Einige der Vorrichtungen in 2410 sind mandantenfähige Vorrichtungen, wobei Mandant 1 innerhalb eines Mandant-1-„Slice“ funktionieren kann, während ein Mandant 2 innerhalb eines Mandant-2-Slice funktionieren kann (und in weiteren Beispielen können zusätzliche oder Untermandanten existieren; und jeder Mandant kann sogar spezifisch zu einem spezifischen Satz von Merkmalen bis hin zu spezifischen Hardwaremerkmalen berechtigt und transaktionell daran gebunden sein). Eine vertrauenswürdige mandantenfähige Vorrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, so dass die Kombination aus Schlüssel und Slice als „Root of Trust“ (RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner unter Verwendung einer DICE-Architektur (DICE - Device Identity Composition Engine) dynamisch berechnet werden, so dass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein feldprogrammierbares Gate-Array (FPGA)) zu erstellen. Die RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um „Auffächerung“ (Fan-out) zu ermöglichen, das zum Unterstützen von Mandantenfähigkeit nützlich ist. Innerhalb einer mandantenfähigen Umgebung können die jeweiligen Edge-Knoten 2422, 2424 als Sicherheitsmerkmaldurchsetzungspunkte für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugewiesen sind. Zusätzlich dazu können Mandantenlaufzeit- und Anwendungsausführung (z. B. in den virtuellen Edge-Instanzen 2432, 2434) als ein Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 460 an einer Orchestrierungsentität als ein Sicherheitsmerkmal-Durchsetzungspunkt zum Marshallen von Ressourcen entlang Mandantengrenzen arbeiten.
  • Edge-Computing-Knoten können Ressourcen (Speicher, zentrale Verarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interrupt-Steuerung, Eingabe/Ausgabe-(E/A-)Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionierungen eine RoT-Fähigkeit enthalten können, und wobei Auffächerung und Schichtung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Computing-Knoten verwenden häufig Container, FaaS-Engines, Servlets, Server oder eine andere Berechnungsabstraktion, die gemäß einer DICE-Schichtungs- und -Auffächerungsstruktur partitioniert werden können, um für jede einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen Vorrichtungen bei 2410, 2422 und 2440, die RoTs überspannen, die Einrichtung einer verteilten vertrauenswürdige Rechenbasis (DTCB) koordinieren, so dass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal eingerichtet werden kann, der alle Elemente von Ende zu Ende verbindet.
  • Ferner versteht es sich, dass ein Container Daten oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuerung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Pod-Steuerung eines Ziel-Edge-Knotens erhalten, wobei der Migrationsschlüssel zum Verpacken der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zum Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuerung offenbart, die dann die verpackten Schlüssel entschlüsselt. Die Schlüssel können nun zur Durchführung von Operationen an Container-spezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt bestätigte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
  • In weiteren Beispielen wird ein Edge-Computing-System erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer geschlossenen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Umgebung mit mehreren Eigentümern und mehreren Eigentümern bereitzustellen. Ein mandantenfähiger Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensankerverwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen „Slice“-Konzepts in 24 durchzuführen. Beispielsweise kann ein Edge-Computing-System dazu konfiguriert sein, Anforderungen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Rechenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z. B. Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Abladung von Berechnungen) gleichzeitig unterstützen. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z. B. normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Networking-Anwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geographischen Orten (oder jeweilige Rechensysteme und Ressourcen, den mehreren Eigentümern gemeinsam gehören oder gemeinsam von diesen verwaltet werden) gespannt sein.
  • Beispielsweise kann jeder Edge-Knoten 2422, 2424 die Verwendung von Containern implementieren, wie unter Verwendung eines Container-„Pods“ 2426, 2428, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einem Szenario, das einen oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Pod-Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z. B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Slices virtueller Edges 2432, 2434 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
  • Bei der Verwendung Container-Pods beaufsichtigt eine Pod-Steuerung die Partitionierung und Zuordnung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (z. B. Orchestrator 2460), welche die Steuerung unterweisen, wie physische Ressourcen am besten zu partitionieren sind und für welche Dauer, wie etwa durch Empfangen von Performance-Indikator-Zielen (KPI-Zielen) basierend auf SLA-Verträgen. Die Pod-Steuerung bestimmt, welcher Container welche Ressourcen und wie lange benötigt, um die Arbeitslast abzuschließen und die SLA zu erfüllen Die Pod-Steuerung verwaltet auch Containerlebenszyklusoperationen, wie: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam an einer verteilten Anwendung arbeiten, Abbauen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung in einer Sicherheitsrolle dienen, welche die Zuordnung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Bestätigungsergebnis erfüllt ist.
  • Auch bei der Verwendung von Container-Pods können Mandantengrenzen dennoch existieren, aber im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, gibt es eine gemeinsam genutzte Pod-Steuerung, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um die Bestätigung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten Beispielsweise kann der Orchestrator 2460 für lokale Pod-Steuerungen, die eine Bestätigungsprüfung durchführen, eine Bestätigungsprüfungsrichtlinie bereitstellen. Falls eine Bestätigung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite POD zu einem anderen Edge-Knoten migriert werden, der sie erfüllt. Alternativ dazu kann dem ersten Pod erlaubt werden, ausgeführt zu werden, und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
  • 25 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Computing-System bereitstellen. Als ein vereinfachtes Beispiel stellen die Systemanordnungen 2510, 2520 Szenarien dar, in denen eine Pod-Steuerung (z. B. Containermanager 2511, 2521 und Container-Orchestrator 2531) dazu ausgelegt ist, containerisierte Pods, Funktionen und Funktionen-als-Dienst-Instanzen durch Ausführung über Rechenknoten (2515 in Anordnung 2510) oder separat containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (2523 in Anordnung 2520) auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in der Systemanordnung 2530 (unter Verwendung von Rechenknoten 2537) angepasst, wobei containerisierte Pods (z. B. Pods 2512), Funktionen (z. B. Funktionen 2513, VNFs 2522, 2536), und Funktionen-als-Dienst-Instanzen (z. B. FaaS-Instanz 2514) innerhalb virtueller Maschinen (z. B. VMs 2534, 2535 für Mandanten 2532, 2533) gestartet werden, die spezifisch für jeweilige Mandanten sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in der Systemanordnung 2540 ausgelegt, die Container 2542, 2543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 2544 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 2541 koordiniert.
  • Die in 25 dargestellten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleunigerkomponenten (FPGA, ASIC) als ein lokales Backend umfassen. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
  • Im Kontext von 25 können die Pod-Steuerung/der Containermanager, der Container-Orchestrator und die einzelnen Knoten einen Sicherheitsdurchsetzungspunkt bereitstellen. Die Mandantentrennung kann jedoch orchestriert werden, wobei sich die Ressourcen, die einem Mandanten zugewiesen sind, von Ressourcen unterscheiden, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass Ressourcenzuweisungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuweisungen könnten über Mandantengrenzen hinweg getrennt werden, da Mandanten eine Verwendung über eine Abonnement- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Zusammenhängen können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemen von Edge-Eigentümern verwendet werden, um die Mandanten zu vollziehen. Andere Isolationsumgebungen können umfassen: Bare-Metal-(dedizierte-)Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
  • Bei weiteren Beispielen können Aspekte von softwaredefinierter oder gesteuerter Siliziumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Computing-Systems integrieren. Softwaredefiniertes Silizium (SDSi - Software Defined Silicon) kann verwendet werden, um die Fähigkeit für gewisse Ressourcen- oder Hardwarebestandteile zum Erfüllen eines Vertrags oder einer Dienstgütevereinbarung basierend auf der Fähigkeit des Bestandteils zum Korrigieren eines Teil seiner selbst oder der Arbeitslast (z. B. durch ein Upgrade, eine Neukonfiguration oder eine Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst) sicherzustellen.
  • Die hier erörterten Edge-Computing-Systeme und -Anordnungen können bei verschiedenen Lösungen, Diensten und/oder Anwendungsfällen anwendbar sein, die Mobilität involvieren. 26 zeigt einen Fahrzeugberechnungs- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Computing-System 2600 involviert, das eine Edge-Cloud 2110 implementiert. In diesem Anwendungsfall können jeweilige Client-Rechenknoten 2610 als fahrzeuginterne Rechensysteme (z. B. fahrzeuginterne Navigations- und/oder Infotainmentsysteme) umgesetzt sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gateway-Knoten 2620 während des Befahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 2620 in einem Schrank am Straßenrand oder einer anderen Einhausung befinden, die in eine Struktur eingebaut ist, die einen anderen, separaten, mechanischen Nutzen aufweist und entlang der Straße, an Kreuzungen der Straße oder anderen Orten nahe der Straße platziert sein kann. Wenn jeweilige Fahrzeuge die Straße entlang fahren, kann sich die Verbindung zwischen ihrem Client-Rechenknoten 2610 und einer spezifischen Edge-Gateway-Vorrichtung 2620 ausbreiten, um eine konsistente Verbindung und einen konsistenten Kontext für den Client-Rechenknoten 2610 aufrechtzuerhalten. Gleichermaßen können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsanforderungen für den oder die zugrundeliegenden Dienste aggregieren (z. B. im Fall von Drohnen). Die jeweiligen Edge-Gateway-Vorrichtungen 2620 umfassen eine Menge an Verarbeitungs- und Speicherfähigkeiten, und daher können eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 2610 auf einer oder mehreren der Edge-Gateway-Vorrichtungen 2620 durchgeführt werden.
  • Die Edge-Gateway-Vorrichtungen 2620 können mit einem oder mehreren Edge-Ressourcenknoten 2640 kommunizieren, die veranschaulichend als Rechenserver, -geräte oder - komponenten umgesetzt sind, die sich an oder in einem Netzwerkzugangsknoten (NAN) 2642 (z. B. einer Basisstation eines zellularen Netzwerks) befinden. Wie oben erörtert, umfassen die jeweiligen Edge-Ressourcenknoten 2640 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, und somit können eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 2610 auf dem Edge-Ressourcenknoten 2640 durchgeführt werden. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den Edge-Ressourcenknoten 2640 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Vorrichtungen 2620 durchgeführt werden kann (zum Beispiel in Abhängigkeit von den Fähigkeiten jeder Komponente oder Informationen in der Anforderung, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenort oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Gleichermaßen können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (z. B. durch einen lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um dem neuen Bedarf gerecht zu werden (z. B. Anpassen der Rechenressourcen an die Arbeitslastdaten).
  • Der eine oder die mehreren Edge-Ressourcenknoten 2640 kommunizieren auch mit dem Kernrechenzentrum 2650, das Rechenserver, Geräte und/oder andere Komponenten umfassen kann, die sich an einem zentralen Standort (z. B. einer Zentrale eines zellularen Kommunikationsnetzwerks) befinden. Das Kernrechenzentrum 2650 kann ein Gateway zur globalen Netzwerk-Cloud 2660 (z. B. das Internet) für die Operationen der Edge-Cloud 2110 bereitstellen, die durch den einen oder die mehreren Edge-Ressourcenknoten 2640 und die Edge-Gateway-Vorrichtungen 2620 gebildet werden. Zusätzlich kann das Kernrechenzentrum 2650 in einigen Beispielen eine Menge an Verarbeitungs- und Speicherfähigkeiten umfassen, und daher kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kernrechenzentrum 2650 durchgeführt werden (z. B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
  • Die Edge-Gateway-Knoten 2620 oder die Edge-Ressourcenknoten 2640 können die Verwendung zustandsorientierter Anwendungen 2632 und einer geographisch verteilten Datenbank 2634 anbieten. Obwohl die Anwendungen 2632 und die Datenbank 2634 als horizontal auf einer Schicht der Edge-Cloud 2110 verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste, oder andere Komponenten der Anwendung vertikal über die gesamte Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, der am Client-Rechenknoten 2610 ausgeführt wird, anderer Teile an den Edge-Gateway-Knoten 2620 oder den Edge-Ressourcenknoten 2640 usw.). Zusätzlich dazu kann es, wie zuvor angegeben, Peer-Beziehungen auf einer beliebigen Ebene geben, um Dienstziele und Verpflichtungen zu erfüllen. Ferner können sich die Daten für einen spezifischen Client oder eine spezifische Anwendung basierend auf sich ändernden Bedingungen (z. B. basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.) von Edge zu Edge bewegen. Beispielsweise kann basierend auf der „Abklingrate“ des Zugangs eine Vorhersage zum Identifizieren des nächsten Besitzers, der weitermachen soll, oder dessen, wann die Daten oder der rechnerische Zugang nicht mehr praktikabel sein werden, getroffen werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die benötigt wird, um die Transaktion konform und verlustfrei zu halten.
  • In weiteren Szenarien kann ein Container 2636 (oder ein Pod von Containern) flexibel von einem Edge-Knoten 2620 zu anderen Edge-Knoten (z. B. 2620, 2640 usw.) migriert werden, so dass der Container mit einer Anwendung und Arbeitslast nicht rekonstituiert, rekompiliert, reinterpretiert werden muss, um migriert zu werden. In solchen Einstellungen kann es jedoch einige Abhilfe oder „Swizzling“ -Übersetzungsoperationen geben, die angewendet werden. Zum Beispiel kann sich die physische Hardware am Knoten 2640 vom Edge-Gateway-Knoten 2620 unterscheiden, und daher wird die Hardware-Abstraktionsschicht (HAL), die den unteren Rand des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann irgendeine Form einer späten Bindungstechnik umfassen, wie etwa binäre Übersetzung der HAL von dem nativen Containerformat in das physische Hardwareformat, oder kann Abbildungsschnittstellen und -operationen umfassen. Eine Pod-Steuerung kann verwendet werden, um die Schnittstellenabbildung als Teil des Container-Lebenszyklus anzusteuern, was Migration zu/von verschiedenen Hardwareumgebungen umfasst.
  • Die in 26 umfassten Szenarien können verschiedene Arten von mobilen Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Auto/Lastkraftwagen/Straßenbahn/Zug) gehostet ist, oder andere mobile Einheiten, da sich der Edge-Knoten entlang der Plattform, die ihn hostet, zu anderen geografischen Orten bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren ((z. B. zum Durchführen von Zwischenspeicherung, Berichterstattung, Datenaggregation usw.). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Szenarien verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunkteinrichtungen oder den Edge-Gateway-Knoten 2620, einigen anderen am Edge-Ressourcenknoten 2640 und anderen im Kernrechenzentrum 2650 oder der globalen Netzwerk-Cloud 2660.
  • Bei weiteren Konfigurationen kann das Edge-Computing-System FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen implementieren. In einem Beispiel schreibt ein Entwickler Funktionscode (hier z. B. „Computercode“), der eine oder mehrere Computerfunktionen darstellt, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel durch einen Edge-Knoten oder ein Rechenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstanwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
  • In einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (z. B. eine Anwendung, die durch einen Dritten bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit getrennter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernete-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Computing-Systems werden verschiedene Rechenzentrums-, Edge- und Endpunktvorrichtungen (einschließlich Mobilvorrichtungen) verwendet, um Funktionen „hochzufahren“ (z. B. Funktionsaktionen zu aktivieren und/oder zuzuweisen), die auf Anforderung skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (z. B. Edge-Computing-Knoten) und darunterliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container in Reaktion darauf, dass die Ausführung abgeschlossen ist, auf der Infrastruktur „heruntergefahren“ (z. B. deaktiviert und/oder freigegeben).
  • Weitere Aspekte von FaaS können Bereitstellung von Edge-Funktionen auf eine Dienstart ermöglichen, einschließlich Unterstützung jeweiliger Funktionen, die Edge-Computing als Dienst unterstützen (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können umfassen: eine granuläre Abrechnungskomponente, die Kunden (z. B. Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen einzelnen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits bereitgestellt oder betrieben werden, versus „kalter“ Container, die eine Initialisierung, Bereitstellung oder Konfiguration erfordern).
  • Das Edge-Computing-System 2600 kann einen Edge-Bereitstellungsknoten 2644 umfassen oder mit diesem in Kommunikation stehen. Der Edge-Bereitstellungsknoten 2644 kann Software, wie etwa die beispielhaften computerlesbaren Anweisungen 3182 von 31, an verschiedene empfangende Teilnehmer zum Implementieren eines beliebigen der hier beschriebenen Verfahren verteilen. Der beispielhafte Edge-Bereitstellungsknoten 2644 kann durch einen beliebigen Computerserver, einen beliebigen Heimserver, ein beliebiges Inhaltsübermittlungsnetzwerk, einen beliebigen virtuellen Server, ein beliebiges Softwareverteilungssystem, eine beliebige zentrale Einrichtung, eine beliebige Speichervorrichtung, einen beliebigen Speicherknoten, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, der bzw. das bzw. die in der Lage ist, Softwareanweisungen (z. B. Code, Skripte, ausführbare Binärdateien, Container, Pakete, komprimierte Dateien und/oder Ableitungen davon) zu speichern und/oder an andere Rechenvorrichtungen zu übertragen. Komponente(n) des beispielhaften Edge-Bereitstellungsknotens 644 können sich in einer Cloud, in einem lokalen Netzwerk, in einem Edge-Netzwerk, in einem Weitverkehrsnetzwerk, im Internet und/oder einem beliebigen anderen Standort befinden, der kommunikativ mit dem/den empfangenden Teilnehmer(n) gekoppelt ist. Die empfangenden Teilnehmer können Kunden, Clients, Mitarbeiter, Benutzer usw. der Entität sein, die den Edge-Bereitstellungsknoten 2644 besitzt und/oder betreibt. Beispielsweise kann die Entität, die den Edge-Bereitstellungsknoten 2644 besitzt und/oder betreibt, ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber (oder ein Kunde und/oder Konsument davon) von Softwareanweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 3182 von 31, sein. Die empfangenden Teilnehmer können Konsumenten, Dienstanbieter, Benutzer, Einzelhändler, OEMs usw. sein, die die Softwareanweisungen zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren.
  • In einem Beispiel umfasst der Edge-Bereitstellungsknoten 644 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen/-platten. Die Speichervorrichtungen und/oder Speicherplatten hosten computerlesbare Anweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 3182 von 31, wie unten beschrieben. Ähnlich den oben beschriebenen Edge-Gateway-Vorrichtungen 2620 stehen der eine oder die mehreren Server des Edge-Bereitstellungsknotens 2644 in Kommunikation mit einem NAN 2642 oder einer anderen Netzwerkkommunikationsentität. Bei einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Softwareanweisungen als Teil einer kommerziellen Transaktion zu einer anfordernden Teilnehmer zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Softwareanweisungen kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittpartei-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 3182 vom Edge-Bereitstellungsknoten 644 herunterzuladen. Zum Beispiel können die Softwareanweisungen, die den beispielhaften computerlesbaren Anweisungen 3182 von 31 entsprechen können, auf die beispielhafte Prozessorplattform/en heruntergeladen werden, die die computerlesbaren Anweisungen 3182 ausführen sollen, um die hier beschriebenen Verfahren zu implementieren.
  • In einigen Beispielen können sich die Prozessorplattform(en), die computerlesbaren Anweisungen 3182 ausführen, physisch an verschiedenen geografischen Standorten, in verschiedenen gesetzlichen Zuständigkeitsbereichen usw. befinden. In einigen Beispielen bieten, übertragen und/oder erzwingen ein oder mehrere Server des Edge-Bereitstellungsknotens 2644 periodisch Aktualisierungen der Softwareanweisungen (z. B. der beispielhaften computerlesbaren Anweisungen 3182 von 31), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Softwareanweisungen angewendet werden, die an den Endbenutzervorrichtungen implementiert sind. In einigen Beispielen können unterschiedliche Komponenten der computerlesbaren Anweisungen 3182 von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden; zum Beispiel können unterschiedliche Bibliotheken, Plug-ins, Komponenten und andere Typen von Rechenmodulen, ob kompiliert oder interpretiert, von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden. Zum Beispiel kann ein Teil der Softwareanweisungen (z. B. ein Skript, das an sich nicht ausführbar ist) von einer ersten Quelle verteilt werden, während ein Interpreter (der in der Lage ist, das Skript auszuführen) von einer zweiten Quelle verteilt werden kann.
  • 27 veranschaulicht eine MEC-Systemreferenzarchitektur (oder MEC-Architektur) 2700, die Funktionalitäten gemäß ETSI GS MEC 003 v2.1.1 (2019-01) („[MEC003]“); ETSI GS MEC 009 V2.1.1 (2019-01) („[MEC009]“); ETSI GS MEC 011 V1.1.1 (2017-07) („[MEC011]“); ETSI GS MEC 012 V2.1.1 (2019-12) („[MEC012]“); ETSI GS MEC 013 v2.1.1 (2019-09) („[MEC013]“); ETSI GS MEC 014 VI.1.1 (2018-02) („[MEC014]“); ETSI GS MEC 015 v2.1.1 (2020-06) („[MEC015]“); ETSI GS MEC 028 v2.1.1 (2020-06) („[MEC028]“); ETSI GS MEC 029 v2.1.1 (2019-07) („[MEC029]“); ETSI MEC GS 030 v2.1.1 (2020-04) („[MEC030]“); unter vielen anderen ETSI-MEC-Standards bereitstellt. MEC bietet Anwendungsentwicklern und Inhaltsanbietern Cloud-Computing-Fähigkeiten und eine IT-Dienstumgebung an der Edge des Netzwerks. Diese Umgebung zeichnet sich durch ultraniedrige Latenz und hohe Bandbreite sowie Echtzeitzugang auf Funknetzinformationen aus, die durch Anwendungen genutzt werden können. Die MEC-Technologie ermöglicht eine flexible und schnelle Bereitstellung innovativer Anwendungen und Dienste für Mobilteilnehmer, Unternehmen und vertikale Segmente. Insbesondere müssen, was den Automobilsektor betrifft, Anwendungen, wie etwa V2X (z. B. IEEE 802.11 p basierte Protokolle, wie etwa DSRC/ITS-G5- oder 3GPP-C-V2X-basierte Protokolle), Daten austauschen, Daten für Aggregationspunkte bereitstellen und auf Daten in Datenbanken zugreifen, die einen Überblick über die lokale Situation bereitstellen, die von einer Vielzahl von Sensoren (durch verschiedene Autos, Straßenrandeinheiten usw.) abgeleitet wird.
  • Die MEC-Architektur 2700 weist MEC-Hosts 2702, einen Virtualisierungsinfrastruktur-Manager (VIM) 2708, einen MEC-Plattform-Manager 2706, einen MEC-Orchestrator 2710, ein Operationsunterstützungssystem (OSS - Operations Support System) 2712, einen Benutzer-App-Proxy 2714, eine UE-App 2718, die auf dem UE 2720 ausgeführt wird, und ein CFS-Portal 2716 auf. Der MEC-Host 2702 kann eine MEC-Plattform 2732 mit Filterregelsteuerkomponente 2740, eine DNS-Handhabungskomponente 2742, ein Dienstregister 2738 und MEC-Dienste 2736 umfassen. Die MEC-Dienste 2736 können mindestens einen Scheduler umfassen, der verwendet werden kann, um Ressourcen zum Instanziieren von MEC-Apps (oder NFVs) 2726 auf der Virtualisierungsinfrastruktur (VI) 2722 auszuwählen. Die MEC-Apps 2726 können dazu konfiguriert sein, Dienste 2730 bereitzustellen, die Verarbeiten von Netzwerkkommunikationsverkehr unterschiedlicher Typen, die mit einer oder mehreren drahtlosen Verbindungen (z. B. Verbindungen zu einem oder mehreren RANs oder Kernnetzwerkfunktionen) assoziiert sind, und/oder einige anderen Dienste, wie etwa die hierin erörterten, umfassen können. Der andere MEC-Host 2702 kann eine gleiche oder eine ähnliche Konfiguration/Implementierung wie der MEC-Host 2702 aufweisen, und die andere MEC-App 2726, die innerhalb des anderen MEC-Hosts 2702 instanziiert ist, kann den MEC-Apps 2726, die innerhalb des MEC-Hosts 2702 instanziiert sind, ähnlich sein. Die VI 2722 umfasst eine Datenebene 2724, die über eine MP2-Schnittstelle mit der MEC-Plattform 2722 gekoppelt ist. Zusätzliche Schnittstellen zwischen verschiedenen Netzwerkentitäten der MEC-Architektur 2700 sind in 27 veranschaulicht.
  • Das MEC-System 2700 umfasst drei Gruppen von Referenzpunkten, die „Mp“-Referenzpunkte bezüglich der MEC-Plattformfunktionalität; „Mm“-Referenzpunkte, die Verwaltungsreferenzpunkte sind; und „Mx“-Referenzpunkte umfassen, die MEC-Entitäten mit externen Entitäten verbinden. Die Schnittstellen/Referenzpunkte im MEC-System 2700 können IP-basierte Verbindungen umfassen und verwendet werden, um Representational-State-Transfer-(REST- oder RESTful-)Dienste bereitzustellen, und die unter Verwendung der Referenzpunkte/Schnittstellen übermittelten Nachrichten können in XML, HTML, JSON oder einem anderen gewünschten Format, wie etwa jenen hierin erörterten, vorliegen. Ein geeignetes Authentifizierungs-, Autorisierungs- und Abrechnungsprotokoll (AAA), wie etwa das Radius- oder Diameter-Protokoll, kann ebenfalls zum Kommunizieren über die Referenzpunkte/Schnittstellen verwendet werden.
  • Die logischen Verbindungen zwischen verschiedenen Entitäten der MEC-Architektur 2700 können zugangsunabhängig sein und nicht von einer spezifischen Bereitstellung abhängen. MEC ermöglicht die Implementierung von MEC-Apps 2726 als Nur-Software-Entitäten, die auf einer VI 2722 ausgeführt werden, die sich in oder nahe der Netzwerk-Edge befindet. Eine MEC-App 2726 ist eine Anwendung, die auf einem MEC-Host 2702 innerhalb des MEC-Systems 2700 instanziiert werden kann und potentiell MEC-Dienste 2736 bereitstellen oder konsumieren kann.
  • Die in 27 dargestellten MEC-Entitäten können in eine MEC-Systemebene, MEC-Hostebene und Entitäten auf Netzwerkebene (nicht gezeigt) gruppiert werden. Die (nicht gezeigte) Netzwerkebene umfasst verschiedene externe Netzwerkebenenentitäten, wie etwa ein 3GPP-Netzwerk, ein lokales Netzwerk (z. B. ein LAN, WLAN, PAN, DN, LADN usw.) und ein oder mehrere externes Netzwerke. Die MEC-Systemebene umfasst MEC-Systemebenen-Verwaltungsentitäten und UE 2720 und wird im Folgenden ausführlicher erörtert. Die MEC-Host-Ebene umfasst einen oder mehrere MEC-Hosts 2702, 2704 und MEC-Verwaltungsentitäten, die Funktionalität bereitstellen, um MEC-Apps 2726 innerhalb eines Betreibernetzwerks oder eines Teilsatzes eines Betreibernetzwerks auszuführen. Die MEC-Verwaltungsentitäten umfassen verschiedene Komponenten, die die Verwaltung der MEC-spezifischen Funktionalität einer spezifischen MEC-Plattform 2732, eines MEC-Hosts 2702 und der MEC-Apps 2726 handhaben, die ausgeführt werden sollen.
  • Der MEC-Plattformmanager 2706 ist eine MEC-Verwaltungsentität, die eine MEC-Plattformelement-Verwaltungskomponente 2744, eine MEC-App-Regel- und - Anforderungsverwaltungskomponente 2746 und eine MEC-App-Lebenszyklusverwaltungskomponente 2748 umfasst. Die verschiedenen Entitäten innerhalb der MEC-Architektur 2700 können Funktionalitäten durchführen, wie in [MEC003] erörtert. Die Remote-App 2750 ist dazu konfiguriert, mit dem MEC-Host 2702 (z. B. mit den MEC-Apps 2726) über den MEC-Orchestrator 2710 und den MEC-Plattformmanager 2706 zu kommunizieren.
  • Der MEC-Host 2702 ist eine Entität, die eine MEC-Plattform 2732 und VI 2722 enthält, die Rechen-, Speicher- und Netzwerkressourcen zum Zweck des Ausführens der MEC-Anwendungen 2726 bereitstellt. Die VI 2722 umfasst eine Datenebene (DP) 2724, die Verkehrsregeln 2740 ausführt, die durch die MEC-Plattform 2732 empfangen werden, und den Verkehr zwischen MEC-Apps 2726, MEC-Diensten 2736, DNS-Server/Proxy (siehe z. B. über DNS-Handhabungsentität 2742), 3GPP-Netzwerk, lokalen Netzwerken und externen Netzwerken routet. Die MEC-DP 2724 kann mit den (R)AN-Knoten und dem 3GPP-Kernnetzwerk verbunden sein, und/oder sie kann mit einem Zugangspunkt über ein breiteres Netzwerk, wie etwa das Internet, ein Unternehmensnetzwerk oder dergleichen, verbunden sein.
  • Die MEC-Plattform 2732 ist eine Sammlung essentieller Funktionalität, die erforderlich ist, um MEC-Apps 2726 auf einer bestimmten VI 2722 auszuführen und ihnen zu ermöglichen, MEC-Dienste 2736 bereitzustellen und zu konsumieren, und die für sich selbst eine Anzahl von MEC-Diensten 937a bereitstellen kann. Die MEC-Plattform 2732 kann auch verschiedene Dienste und/oder Funktionen bereitstellen, wie etwa Anbieten einer Umgebung, in der die MEC-Apps 2726 MEC-Dienste 2736 (im Folgenden erörtert) erkennen, ankündigen, konsumieren und anbieten können, einschließlich MEC-Dienste 2736, die über andere Plattformen verfügbar sind, wenn sie unterstützt werden. Die MEC-Plattform 2732 kann in der Lage sein, autorisierten MEC-Apps 2726 zu ermöglichen, mit Drittservern zu kommunizieren, die sich in externen Netzwerken befinden. Die MEC-Plattform 2732 kann Verkehrsregeln von dem MEC-Plattformmanager 2706, Anwendungen oder Diensten empfangen und die Datenebene entsprechend anweisen (siehe z. B. Verkehrsregelsteuerung 2740). Die MEC-Plattform 2732 kann Anweisungen an die DP 2724 innerhalb der VI 2722 über den Mp2-Referenzpunkt senden. Der Mp2-Referenzpunkt zwischen der MEC-Plattform 2732 und der DP 2724 der VI 2722 kann verwendet werden, um die DP 2734 zu unterweisen, wie Verkehr zwischen Anwendungen, Netzwerken, Diensten usw. zu routen ist. Die MEC-Plattform 2732 kann Token, die UEs 2720, UE-Apps, individuelle Sitzungen und/oder individuelle Flüsse innerhalb einer Sitzung in den Verkehrsregeln darstellen, in spezifische Netzwerkadressen (z. B. IP-Adressen oder dergleichen) übersetzen. Die MEC-Plattform 2732 empfängt auch DNS-Aufzeichnungen vom MEC-Plattformmanager 2706 und konfiguriert einen DNS-Proxy/-Server entsprechend. Die MEC-Plattform 2732 hostet MEC-Dienste 2736 , einschließlich der nachstehend erörterten Multi-Access-Edge-Dienste, und stellt Zugriff auf Persistenzspeicher- und Tageszeitinformationen bereit. Außerdem kann die MEC-Plattform 2732 mit anderen MEC-Plattformen 2732 anderer MEC-Server 2702 über den Mp3-Referenzpunkt kommunizieren. Bei Empfang einer Aktualisierung, Aktivierung oder Deaktivierung von Verkehrsregeln von dem MEC-Plattformmanager 2706, Apps oder Diensten weist die MEC-Plattform 2732 die Datenebene 2724 entsprechend an. Die MEC-Plattform 2732 empfängt auch DNS-Aufzeichnungen vom MEC-Plattformmanager 2706 und verwendet sie zum Konfigurieren eines DNS-Proxys/-Servers 2742. Die Verkehrsregelsteuerung 2740 ermöglicht der MEC-Plattform 2732, Verkehrsrouting einschließlich Verkehrsregelaktualisierung, -aktivierung und - deaktivierung durchzuführen. Zusätzlich oder alternativ ermöglicht die Verkehrsregelsteuerung 2740 der MEC-Plattform 2732, Verkehrslenkung durchzuführen, indem zum Beispiel Datenpakete über eine oder mehrere Zugangsnetzwerkverbindungen in einer Mehrfachzugangsumgebung geleitet werden, die mehrere Zugangsnetzwerke umfasst, von denen jedes mehrere Zugangsnetzwerkverbindungen aufweisen und/oder unterschiedliche Zugangstechnologien implementieren kann.
  • Die VI 2722 stellt die Gesamtheit aller Hardware- und Softwarekomponenten dar, die die Umgebung aufbauen, in der die MEC-Apps 2726 und/oder die MEC-Plattform 2732 bereitgestellt, verwaltet und ausgeführt werden. Die VI 2722 kann sich über mehrere Standorte erstrecken, und das Netzwerk, das Konnektivität zwischen diesen Standorten bereitstellt, wird als Teil der VI 2722 angesehen. Die physischen Hardwareressourcen der VI 2722 umfassen Rechen-, Speicher- und Netzwerkressourcen, die Verarbeitung, Speicherung und Konnektivität für die MEC-Apps 2726 und/oder die MEC-Plattform 2732 durch eine Virtualisierungsschicht (z. B. einen Hypervisor, VM-Monitor (VMM) oder dergleichen) bereitstellen. Die Virtualisierungsschicht kann die physischen Hardwareressourcen des MEC-Server 2702 als eine Hardware-Abstraktionsschicht abstrahieren und/oder logisch partitionieren. Die Virtualisierungsschicht kann die Software, die die MEC-Apps 2726 und/oder die MEC-Plattform 2732 implementiert, befähigen, die zugrundeliegende VI 2722 zu verwenden, und sie kann virtualisierte Ressourcen für die MEC-Apps 2726 und/oder die MEC-Plattform 2732 bereitstellen, so dass die MEC-Apps 2726 und/oder die MEC-Plattform 2732 ausgeführt werden können.
  • Die MEC-Apps 2726 sind Anwendungen, die auf einem MEC-Host/-Server 2702 innerhalb des MEC-Systems 2700 instanziiert werden können und potentiell MEC-Dienste 2736 bereitstellen oder konsumieren können. Der Begriff „MEC-Dienst“ bezieht sich auf einen Dienst, der über eine MEC-Plattform 2732 entweder durch die MEC-Plattform 2732 selbst oder durch eine MEC-App 2726 bereitgestellt wird. Die MEC-Apps 2726 können als VM auf der VI 2722 ausgeführt werden, die durch den MEC-Server 2702 bereitgestellt wird, und sie können mit der MEC-Plattform 2732 interagieren, um die MEC-Dienste 2736 zu konsumieren und bereitzustellen. Der Mp1-Referenzpunkt zwischen der MEC-Plattform 2732 und den MEC-Apps 2726 wird zum Verbrauchen und Bereitstellen dienstspezifischer Funktionalität verwendet. Der Mp1 stellt Dienstregistrierung 2738, Diensterkennung und Kommunikationsunterstützung für verschiedene Dienste bereit, wie etwa die MEC-Dienste 2736, die durch den MEC-Host 2702 bereitgestellt werden. Der Mp1 kann auch Anwendungsverfügbarkeit, Prozeduren zur Unterstützung von Sitzungszustandsverlagerung, Verkehrsregel- und DNS-Regelaktivierung, Zugriff auf Persistenzspeicher- und Tageszeitinformationen und/oder dergleichen bereitstellen. Zusätzlich oder alternativ dazu können die MEC-Apps 2726 mit der MEC-Plattform 2732 unter Verwendung der MEC-APIs kommunizieren, die in ETSI GS MEC 011 V2.1.1 (2019-11) erörtert sind.
  • Die MEC-Apps 2726 werden auf der VI 2722 des MEC-Servers 2702 basierend auf einer Konfiguration oder Anforderungen instanziiert, die durch die MEC-Verwaltung (z. B. den MEC-Plattformmanager 2706) validiert werden. Die MEC-Apps 2726 können auch mit der MEC-Plattform 2732 interagieren, um gewisse Unterstützungsprozeduren in Bezug auf den Lebenszyklus der MEC-Apps 2726 durchzuführen, wie etwa Anzeigen von Verfügbarkeit, Vorbereiten einer Benutzerzustandsverlagerung usw. Die MEC-Apps 2726 können eine gewisse Anzahl von Regeln und Anforderungen aufweisen, die mit ihnen assoziiert ist, wie etwa erforderliche Ressourcen, maximale Latenz, erforderliche oder nützliche Dienste usw. Diese Anforderungen können durch die MEC-Verwaltung validiert und Standardwerten zugewiesen werden, falls sie fehlen. MEC-Dienste 2736 sind Dienste, die entweder durch die MEC-Plattform 2732 und/oder MEC-Apps 2726 bereitgestellt und/oder konsumiert werden. Die Dienstkonsumenten (z. B. MEC-Apps 2726 und/oder MEC-Plattform 2732) können mit bestimmten MEC-Diensten 2736 über einzelne APIs (einschließlich der MEC-V2X-API und den anderen hierin erörterten MEC-APIs) kommunizieren. Wenn durch eine Anwendung bereitgestellt, kann ein MEC-Dienst 2736 in einer Liste von Diensten in den Dienstregistern 2738 bei der MEC-Plattform 2732 über den Mp1-Referenzpunkt registriert werden. Zusätzlich dazu kann eine MEC-App 2726 einen oder mehrere Dienste 2730/2736 abonnieren, für die sie über den Mp1-Referenzpunkt autorisiert ist.
  • Beispiele für MEC-Dienste 2736 umfassen V2X-Informationsdienste (VIS), RNIS (siehe z. B. [MEC012], Standortdienste [MEC013], UE-Identitätsdienste [MEC014], Verkehrsverwaltungsdienste (TMS) und BWMS [MEC015], WLAN-Zugangsformations-(WAI- )Dienste [MEC028], Festzugangsinformations-(FAI-)Dienste [MEC029] und/oder andere MEC-Dienste. Der RNIS stellt, falls verfügbar, autorisierte MEC-Apps 2726 mit funknetzbezogenen Informationen bereit und macht für die MEC-Apps 2726 geeignete aktuelle Funknetzwerkinformationen verfügbar. Die RNI können unter anderem Funknetzwerkbedingungen, Mess- und Statistikinformationen in Bezug auf die UP, Informationen in Bezug auf UEs 2720, die durch den einen oder die mehreren Funkknoten bedient werden, die mit dem MEC-Host 2702 assoziiert sind (z. B. UE-Kontext und Funkzugangsträger), Änderungen an Informationen in Bezug auf UEs 2720, die durch den einen oder die mehreren Funkknoten bedient werden, die mit dem MEC-Host XE136 assoziiert sind, und/oder dergleichen umfassen. Die RNI können mit der relevanten Granularität (z. B. pro UE 2720, pro Zelle, pro Zeitperiode) bereitgestellt werden.
  • Die Dienstkonsumenten (z. B. MEC-Apps 2726, MEC-Plattform 2732 usw.) können mit dem RNIS über eine RNI-API kommunizieren, um Kontextinformationen von einem entsprechenden RAN zu erhalten. RNI können den Dienstkonsumenten über einen NAN (z. B. (R)AN-Knoten, RRH, AP usw.) bereitgestellt werden. Die RNI-API kann sowohl anfrage- als auch abonnementbasierte Mechanismen (z. B. einen Pub/Sub-basierten Mechanismus) unterstützen, die über eine Representational-State-Transfer-(RESTful-)API oder über einen Nachrichtenbroker der MEC-Plattform 2732 (nicht gezeigt) verwendet werden. Eine MEC-App 2726 kann Informationen über einen Nachrichtenbroker über eine Transportinformationsabfrageprozedur abfragen, wobei die Transportinformationen der MEC-App 2726 über einen geeigneten Konfigurationsmechanismus vorab bereitgestellt werden können. Die verschiedenen Nachrichten, die über die RNI-API kommuniziert werden, können in XML, JSON, Protobuf oder einem anderen geeigneten Format vorliegen.
  • Der VIS stellt verschiedene V2X-Anwendungen bereit, einschließlich der reisebewussten QoS-Vorhersagen unter vielen anderen. Die RNI können von den MEC-Apps 2726 und der MEC-Plattform 2732 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen über Funkbedingungen basieren. Als ein Beispiel kann eine MEC-App 2726 RNI verwenden, um aktuelle Dienste, wie etwa Videodurchsatzanleitung, zu optimieren. Bei der Durchsatzanleitung kann eine Funkanalyse-MEC-App 2726 MEC-Dienste verwenden, um einem Backend-Videoserver eine Nahechtzeitangabe über den Durchsatz bereitzustellen, von dem geschätzt wird, dass er an der DL-Funkschnittstelle zu einem nächsten Zeitpunkt verfügbar ist. Die Durchanleitungs-Funkanalyseanwendung berechnet Durchsatzanleitung basierend auf den erforderlichen Funknetzinformationen, die sie von einem Multi-Access-Edge-Dienst erhält, der auf dem MEC-Server 2702 ausgeführt wird. RNI können auch durch die MEC-Plattform 2732 verwendet werden, um die Mobilitätsprozeduren zu optimieren, die erforderlich sind, um Dienstkontinuität zu unterstützen, wie etwa wenn eine bestimmte MEC-App 2726 ein einzelnes Informationselement unter Verwendung eines einfachen Anforderung-Antwort-Modells (z. B. unter Verwendung von RESTful-Mechanismen) anfordert, während andere MEC-Apps 2726 mehrere verschiedene Benachrichtigungen bezüglich Informationsänderungen (z. B. unter Verwendung eines Pub/Sub-Mechanismus und/oder Nachrichtenbroker-Mechanismus) abonnieren.
  • Der LS kann, wenn verfügbar, autorisierte MEC-Apps 2726 mit standortsbezogenen Informationen versorgen und solche Informationen für die MEC-Apps 2726 verfügbar machen. Mit standortbezogenen Informationen führen die MEC-Plattform 2732 oder eine oder mehrere MEC-Apps 2726 aktive Vorrichtungsstandortverfolgung, standortbasierte Diensteempfehlungen und/oder andere ähnliche Dienste durch. Der LS unterstützt den Standortabrufmechanismus, z. B. wird der Standort nur einmal für jede Standortinformationsanforderung gemeldet. Der LS unterstützt zum Beispiel einen Standortteilnehmermechanismus, wobei der Standort mehrere Male für jede Standortanfrage periodisch oder basierend auf spezifischen Ereignissen, wie etwa Standortänderung, gemeldet werden kann. Die Standortinformationen können unter anderem den Standort spezifischer UEs 2720, die gegenwärtig von dem oder den Funkknoten(en) bedient werden, die mit dem MEC-Server 2702 assoziiert sind, Informationen über den Standort aller UEs 2720, die gegenwärtig von dem oder den Funkknoten(en) bedient werden, die mit dem MEC-Server XE136 assoziiert sind, Informationen über den Standort einer gewissen Kategorie von UEs 2720, die gegenwärtig durch den oder die Funkknoten bedient werden, die mit dem MEC-Server XE136 assoziiert sind, eine Liste von UEs 2720 an einem bestimmten Standort, Informationen über den Standort aller Funkknoten, die gegenwärtig mit dem MEC-Host 2702 assoziiert sind, und/oder dergleichen umfassen. Die Standortinformationen können in Form einer Geolokalisierung, einer GNSS-Koordinate (GNSS — Global Navigation Satellite Service), einer Zellenidentität (ID) und/oder dergleichen vorliegen. Der LS ist über die API zugänglich, die in der Spezifikation „RESTful-Network API for Zonal Presence“, OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C, von Open Mobile Alliance (OMA) definiert ist. Der Zonal-Presence-Dienst nutzt das Konzept einer „Zone“, wobei eine Zone verwendet werden kann, um alle Funkknoten, die mit einem MEC-Host 2702 assoziiert sind, oder eine Teilmenge davon, gemäß einer gewünschten Bereitstellung zu gruppieren. In dieser Hinsicht stellt die OMA-Zonal-Presence-API Mittel für MEC-Apps 2726 bereit, um Informationen über eine Zone, die Zugangspunkte, die mit den Zonen assoziiert sind, und die Benutzer, die mit den Zugangspunkten verbunden sind, abzurufen. Zusätzlich ermöglicht die OMA-Zonal-Presence-API, dass eine autorisierte Anwendung einen Benachrichtigungsmechanismus abonniert und über Benutzeraktivitäten innerhalb einer Zone berichtet. Ein MEC-Server 2702 kann unter Verwendung der OMA-Zonal-Presence-API auf Standortinformationen oder Zonenpräsenzinformationen einzelner UEs 2720 zugreifen, um den relativen Standort oder die relativen Positionen der UEs 2720 zu identifizieren.
  • Der TMS ermöglicht Edge-Anwendungen, über verschiedene Verkehrsverwaltungsfähigkeiten und Mehrfachzugangsnetzwerkverbindungsinformationen informiert zu werden, und ermöglicht Edge-Anwendungen, Anforderungen, z. B. Verzögerung, Durchsatz, Verlust, zum Beeinflussen von Verkehrsverwaltungsoperationen bereitzustellen. Bei einigen Implementierungen umfasst der TMS Mehrfachzugangsverkehrslenkung (MTS - Multi-Access Traffic Steering), die nahtlos Lenken, Aufteilen und Duplizieren von Anwendungsdatenverkehr über Mehrfachzugangsnetzwerkverbindungen durchführt. Der BWMS stellt die Zuweisung von Bandbreite zu einem gewissen Verkehr bereit, der zu und von MEC-Apps 2726 geroutet wird, und spezifiziert statische/dynamische Aufwärts/Abwärts-Bandbreitenressourcen, einschließlich Bandbreitengröße und Bandbreitenpriorität. Die MEC-Apps 2726 können den BWMS verwenden, um Bandbreiteninformationen zu/von der MEC-Plattform 2732 zu aktualisieren/zu empfangen. Verschiedenen MEC-Apps 2726, die auf demselben MEC-Server 2702 parallel ausgeführt werden, können spezifische statische, dynamische Aufwärts/Abwärts-Bandbreitenressourcen, einschließlich Bandbreitengröße und Bandbreitenpriorität, zugewiesen werden. Der BWMS umfasst eine Bandbreitenverwaltungs-API (BWMAPI), um registrierten Anwendungen zu ermöglichen, sich statisch und/oder dynamisch für spezifische Bandbreitenzuordnungen pro Sitzung/Anwendung zu registrieren. Die BWM-API umfasst HTTP-Protokollbindungen für BWM-Funktionalität unter Verwenden von RESTful-Diensten oder einem anderen geeigneten API-Mechanismus. Der BWM-Dienst dient zum Zuweisen/Anpassen von BW-Ressourcen für MEC-Apps und ermöglicht MEC-Apps, ihre BW-Anforderungen bereitzustellen.
  • Verschiedene MEC-Anwendungen (-Apps), die auf demselben MEC-Host parallel ausgeführt werden, können spezifische statische/dynamische Aufwärts-/Abwärtsbandbreitenressourcen (BW) erfordern, einschließlich BW-Größe und BW-Priorität. Teilweise können verschiedene Sitzungen, die auf derselben App parallel laufen, jeweils spezifische BW-Anforderungen aufweisen. Zusätzlich dazu können Sitzungen, die von Apps gesteuert werden, die näher an Endbenutzern (z. B. kürzere RTT) ausgeführt werden, einen unrichtigen Vorteil gegenüber Sitzungen empfangen, die von Apps gesteuert werden, die an entfernten Standorten (z. B. außerhalb des RAN) ausgeführt werden. Um potentielle Ressourcenkonflikte zwischen solchen konkurrierenden Anwendungen zu lösen, können BWM und/oder Mehrfachzugangsverkehrslenkungs-(MTS-)Dienste verwendet werden.
  • Die MTS-Dienste können als Teil des BWMS oder getrennt vom BWMS bereitgestellt werden. Der MTS-Dienst dient zum nahtlosen Lenken/Aufteilen/Duplizieren von App-Datenverkehr über Mehrfachzugangsnetzwerke. Der MTS-Dienst erlaubt es Apps/MEC-Apps, über verschiedene MTS-Fähigkeiten und MX-Netzwerkverbindungs-Info informiert zu werden. Die MTS erlaubt es MEC-Apps auch, Anforderungen (zum Beispiel Verzögerung, Durchsatz, Verlust usw.) zum Beeinflussen von Verkehrsverwaltungsoperationen bereitzustellen. Die spezifische Sitzung oder App/MEC-App kann unter Verwendung eines Satzes von Filtern und/oder Kennungen (IDs) innerhalb der Ressourcenanforderung identifiziert werden.
  • Der Zweck des UE-Identitätsmerkmals besteht darin, UE-spezifische Verkehrsregeln im MEC-System 2700 zuzulassen. Wenn das MEC-System 2700 das UE-Identitätsmerkmal unterstützt, stellt die MEC-Plattform 2732 die Funktionalität (z. B. UE-Identitäts-API) für eine MEC-APP 2726 bereit, um ein Tag, das ein UE 2720 darstellt, oder eine Liste von Tags, die jeweilige UEs 2720 darstellen, zu registrieren. Jedes Tag wird in ein spezifisches UE 2720 im System des MNO abgebildet, und die MEC-Plattform 2732 wird mit den Abbildungsinformationen versehen. Die UE-Identitäts-Tag-Registrierung löst die MEC-Plattform 2732 zum Aktivieren der entsprechende(n) Verkehrsregel(n) 2740 aus, die mit dem Tag verknüpft sind. Die MEC-Plattform 2732 stellt auch die Funktionalität (z. B. UE-Identitäts-API) für eine MEC-App 2726 bereit, um eine Abmeldeprozedur aufzurufen, um die Verwendung der Verkehrsregel für diesen Benutzer zu deaktivieren oder anderweitig zu stoppen.
  • Der WAIS ist ein Dienst, der Dienstkonsumenten innerhalb des MEC-Systems 2700 mit WLAN-zugangsbezogenen Informationen versieht. Der WAIS steht für autorisierte MEC-Apps 2726 zur Verfügung und wird über den Mp1-Referenzpunkt erkannt. Die Granularität der WLAN-Zugangsinformationen kann basierend auf Parametern, wie etwa Informationen pro Station, pro NAN/AP oder pro mehreren APs (Multi-AP), angepasst werden. Die WLAN-Zugangsinformationen können von den Dienstkonsumenten genutzt werden, um die bestehenden Dienste zu optimieren und neue Typen von Diensten bereitzustellen, die auf aktuellen Informationen von WLAN-APs basieren, möglicherweise kombiniert mit solchen Informationen wie RNI oder Festzugangsnetzwerkinformationen. Der WAIS definiert Protokolle, Datenmodelle und Schnittstellen in Form von RESTful-APIs. Informationen über die APs und Client-Stationen können entweder durch Abfragen oder durch Abonnieren von Benachrichtigungen angefordert werden, die jeweils Attribut-basierte Filterung und Attribut-Selektoren umfassen.
  • Der FAIS ist ein Dienst, der Festzugangsnetzwerkinformationen (oder FAI) für Dienstkonsumenten innerhalb des MEC-Systems 2700 bereitstellt. Der FAIS steht für die autorisierten MEC-Apps 2726 zur Verfügung und wird über den Mp1-Referenzpunkt erkannt. Der FAI kann durch MEC-Apps 2726 und die MEC-Plattform 2732 verwendet werden, um die bestehenden Dienste zu optimieren und neue Arten von Diensten bereitzustellen, die auf aktuellen Informationen vom festen Zugang (z. B. NANs) basieren, möglicherweise kombiniert mit anderen Informationen, wie etwa RNI oder WLAN-Informationen von anderen Zugangstechnologien. Dienstkonsumenten interagieren mit dem FAIS über die FAI-API, um Kontextinformationen vom Festzugangsnetzwerk zu erhalten. Sowohl die MEC-Apps 2726 als auch die MEC-Plattform 2732 können den FAIS konsumieren; und sowohl die MEC-Plattform 2732 als auch die MEC-Apps 2726 können die Anbieter der FAI sein. Die FAI-API unterstützt sowohl Anfragen als auch Abonnements (Pub/Sub-Mechanismus), die über die RESTful-PI oder über alternative Transporte wie einen Nachrichtenbus verwendet werden. Alternative Transporte können ebenfalls verwendet werden.
  • Die MEC-Verwaltung umfasst MEC-Systemebenenverwaltung und MEC-Hostebenenverwaltung. Die MEC-Verwaltung umfasst den MEC-Plattformmanager 2706 und den VI-Manager (VIM) 2708 und behandelt die Verwaltung der MEC-spezifischen Funktionalität eines bestimmten MEC-Servers 2702 und der darauf laufenden Anwendungen. Bei einigen Implementierungen können einige oder alle der Multi-Access-Edge-Verwaltungskomponenten durch einen oder mehrere Server, die sich in einem oder mehreren Rechenzentren befinden, implementiert werden und Virtualisierungsinfrastruktur verwenden, die mit NFV-Infrastruktur verbunden ist, die zum Virtualisieren von NFs verwendet wird, oder dieselbe Hardware wie die NFV-Infrastruktur verwenden.
  • Der MEC-Plattformmanager 2706 ist für das Verwalten des Lebenszyklus von Anwendungen verantwortlich, das Informieren des MEC-Orchestrators (MEC-O) 2710 über relevante anwendungsbezogene Ereignisse umfasst. Der MEC-Plattformmanager 2706 kann für die MEC-Plattform 2732 auch MEC-Plattformelementverwaltungsfunktionen 2744 bereitstellen, MEC-App-Regeln und Anforderungen 2746 einschließlich Dienstberechtigungen, Verkehrsregeln, DNS-Konfiguration und Auflösung von Konflikten verwalten und MEC-App-Lebenszyklusverwaltung 2748 handhaben. Der MEC-Plattformmanager 2706 kann auch virtualisierte Ressourcen, Fehlermeldungen und Leistungsfähigkeitsmessungen vom VIM 2708 zur Weiterverarbeitung empfangen. Der Mm5-Referenzpunkt zwischen dem MEC-Plattformmanager 2706 und der MEC-Plattform 2732 wird verwendet, um Plattformkonfiguration, Konfiguration der MEC-Plattformelementverwaltung 2744, MEC-App-Regeln und - Anforderungen 2746, MEC-App-Lebenszyklusverwaltung 2748 und Verwaltung der Anwendungsverlagerung durchzuführen.
  • Der VIM 2708 kann eine Entität sein, die virtualisierte (Rechen-, Speicher- und Vernetzungs-)Ressourcen der VI 2722 zuweist, verwaltet und freigibt und die VI 2722 zum Ausführen ein Softwareabbildes vorbreitet. Dazu kann der VIM 2708 mit der VI 2722 über den Mm7-Bezugspunkt zwischen dem VIM 2708 und der VI 2722 kommunizieren. Das Vorbereiten der VI 2722 kann Konfigurieren der VI 2722 und Empfangen/Speichern des Softwareabbildes umfassen. Wenn unterstützt, kann der VIM 2708 eine schnelle Bereitstellung von Anwendungen bereitstellen, wie etwa in „Openstack++ for Cloudlet Deployments“ beschrieben, verfügbar auf‘http://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf. Der VIM 2708 kann auch Performance- und Fehlerinformationen über die virtualisierten Ressourcen sammeln und melden und Anwendungsverlagerung durchführen, wenn unterstützt. Zur Anwendungsverlagerung von/zu externen Cloud-Umgebungen kann der VIM 2708 mit einem externen Cloud-Manager interagieren, um die Anwendungsverlagerung zum Beispiel unter Verwendung des in „Adaptive VM Handoff Across Cloudlets“ beschriebenen Mechanismus und/oder möglicherweise durch einen Proxy durchzuführen. Außerdem kann der VIM 2708 mit dem MEC-Plattformmanager 2706 über den Mm6-Referenzpunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen zu verwalten, um zum Beispiel die Anwendungslebenszyklusverwaltung zu realisieren. Darüber hinaus kann der VIM 2708 mit dem MEC-O 2710 über den Mm4-Referenzpunkt kommunizieren, der verwendet werden kann, um virtualisierte Ressourcen des MEC-Servers 2702 zu verwalten und Anwendungsabbilder zu verwalten. Das Verwalten der virtualisierten Ressourcen kann Verfolgen verfügbarer Ressourcenkapazität usw. umfassen.
  • Die MEC-Systemebenenverwaltung umfasst den MEC-O 2710, der einen Überblick über das vollständige MEC-System 2700 hat. Der MEC-O 2710 kann eine Gesamtansicht des MEC-Systems 2700 basierend auf bereitgestellten MEC-Hosts 2702, verfügbaren Ressourcen, verfügbaren MEC-Diensten 2736 und Topologie beibehalten. Der Mm3-Referenzpunkt zwischen dem MEC-O 2710 und dem MEC-Plattformmanager 2706 kann für die Verwaltung des Anwendungslebenszyklus, der Anwendungsregeln und -anforderungen und das Verfolgen verfügbarer MEC-Dienste 2736 verwendet werden. Der MEC-O 2710 kann mit dem Benutzeranwendungs-Lebenszyklusverwaltungsproxy (UALMP - User Application Lifecycle Management Proxy) 2714 über den Mm9-Referenzpunkt kommunizieren, um MEC-Apps 2726 zu verwalten, die von der UE-Anwendung 2718 angefordert werden.
  • Der MEC-O 2710 kann auch für das Eingliedern von Anwendungspaketen verantwortlich sein, einschließlich Überprüfen der Integrität und Authentizität der Pakete, Validieren von Anwendungsregeln und Anforderungen und nötigenfalls Anpassen derselben, um Betreiberrichtlinien zu erfüllen, Führen einer Aufzeichnung von eingegliederten Paketen und Vorbereiten des/der VIM(s) 2708 zum Handhaben der Anwendungen. Der MEC-O 2710 kann einen oder mehrere geeignete MEC-Hosts 901 zur Anwendungsinstanziierung basierend auf Einschränkungen, wie etwa Latenz, verfügbaren Ressourcen und verfügbaren Diensten, auswählen. Der MEC-O 2710 kann auch Anwendungsinstanziierung und -beendigung auslösen sowie Anwendungsverlagerung nach Bedarf und bei Unterstützung auslösen.
  • Das Operationsunterstützungssystem (OSS - Operations Support System) 2712 ist das OSS eines Betreibers, der Anfragen durch das Customer-Facing-Service-(CFS-)Portal 2716 über den Mx1-Referenzpunkt und von UE-APPS 2718 zur Instanziierung oder Beendigung von MEC-Apps 2726 empfängt. Das OSS 2712 entscheidet über die Bewilligung dieser Anfragen. Das CFS-Portal 2716 (und die Mx1-Schnittstelle) kann von Dritten verwendet werden, um das MEC-System 2700 aufzufordern, Apps 2718 im MEC-System 2700 auszuführen. Bewilligte Anfragen können an den MEC-O 2710 zur Weiterverarbeitung weitergeleitet werden. Wenn unterstützt, empfängt der OSS 2712 auch Anforderungen von UE-Apps 2718 zum Verlagern von Anwendungen zwischen externen Clouds und dem MEC-System 2700. Der Mm2-Referenzpunkt zwischen dem OSS 2712 und dem MEC-Plattformmanager 2706 wird zur Konfigurations-, Fehler- und Performance-Verwaltung des MEC-Plattformmanagers 2706 verwendet. Der Mm1-Referenzpunkt zwischen dem MEC-O 2710 und dem OSS 2712 wird zum Auslösen der Instanziierung und Beendigung von MEC-Apps 2726 im MEC-System 2700 verwendet.
  • Bei der/den UE-App(s) 2718 (auch als „Vorrichtungsanwendungen“ oder dergleichen bezeichnet) handelt es sich um eine oder mehrere Apps, die in einer Vorrichtung 2720 ausgeführt werden, die die Fähigkeit aufweist, mit dem MEC-System 2700 über den Benutzeranwendungs-Lebenszyklusverwaltungsproxy 2714 zu interagieren. Die UE-App(s) 2718 kann/können eine oder mehrere Client-Anwendungen sein, umfassen oder mit diesen interagieren, bei denen es sich im Kontext von MEC um Anwendungssoftware handelt, die auf der Vorrichtung 2718 ausgeführt wird und Funktionalität nutzt, die durch eine oder mehrere spezifische MEC-Apps 2726 bereitgestellt wird. Der Benutzer-App-LCM-Proxy 2714 kann Anforderungen von UE-Apps 2718 im UE 2720 autorisieren und interagiert mit dem OSS 2712 und dem MEC-O 2710 zur Weiterverarbeitung dieser Anforderungen. Der Begriff „Lebenszyklusverwaltung“ im Kontext von MEC bezieht sich auf einen Satz von Funktionen, der erforderlich ist, um die Instanziierung, Wartung und Beendigung einer Instanz der MEC-App 2726 zu verwalten. Der Benutzer-App-LCM-Proxy 2714 kann über den Mm8-Referenzpunkt mit dem OSS 2712 interagieren und wird verwendet, um Anforderungen des UE 2718 zum Ausführen von Anwendungen im MEC-System 2700 zu handhaben. Eine Benutzer-App kann eine MEC-App 2726 sein, die im MEC-System 2700 in Reaktion auf eine Anforderung eines Benutzers durch eine Anwendung instanziiert wird, die im UE 2720 ausgeführt wird (z. B. die UE-App 2718). Der Benutzer-App-LCM-Proxy 2714 ermöglicht es UE-Apps 2718, Eingliederung, Instanziierung, Beendigung von Benutzeranwendungen und, wenn unterstützt, Verlagerung von Benutzeranwendungen in das und aus dem MEC-System 2700 anzufordern. Er ermöglicht es auch, Benutzer-Apps über den Zustand der Benutzer-Apps zu informieren. Der Benutzer-App-LCM-Proxy 2714 ist nur von innerhalb des Mobilnetzwerks zugänglich und kann nur verfügbar sein, wenn er vom MEC-System 2700 unterstützt wird. Eine UE-App 2718 kann den Mx2-Referenzpunkt zwischen dem UE-App-LCM-Proxy 2714 und der UE-App 2718 verwenden, um das MEC-System 2700 aufzufordern, eine Anwendung im MEC-System 2700 auszuführen oder eine Anwendung in das oder aus dem MEC-System 2700 zu bewegen. Der Mx2-Referenzpunkt kann nur innerhalb des Mobilnetzwerks zugänglich sein und kann nur verfügbar sein, wenn er vom MEC-System 2700 unterstützt wird.
  • Um eine MEC-App 2726 im MEC-System 2700 auszuführen, empfängt der MEC-O 2710 Anforderungen, die durch das OSS 2712, einen Dritten oder eine UE-App 2718 ausgelöst werden. In Reaktion auf den Empfang solcher Anforderungen wählt der MEC-0 2710 einen MEC-Server/- Host 2702 aus, um die MEC-App 2726 zum Abladen von Berechnungen usw. zu hosten. Diese Anforderungen können Informationen über die auszuführende Anwendung und möglicherweise andere Informationen, wie etwa den Ort, an dem die Anwendung aktiv sein muss, andere Anwendungsregeln und -anforderungen sowie den Ort des Anwendungsabbildes umfassen, falls es noch nicht in das MEC-System 2700 eingegliedert ist.
  • Der MEC-O 2710 kann einen oder mehrere MEC-Server 2702 für rechenintensive Aufgaben auswählen. Der eine oder die mehreren ausgewählten MEC-Server XE136 können Rechenaufgaben einer UE-App 2718 basierend auf verschiedenen Betriebsparametern wie Netzwerkfähigkeiten und -bedingungen, Rechenfähigkeiten und -bedingungen, Anwendungsanforderungen und/oder anderen ähnlichen Betriebsparametern abladen. Die Anwendungsanforderungen können Regeln und Anforderungen sein, die mit einer oder mehreren MEC-Apps 2726 assoziiert sind, wie etwa ein Bereitstellungsmodell der Anwendung (z. B. ob es eine Instanz pro Benutzer, eine Instanz pro Host, eine Instanz auf jedem Host usw. gibt); erforderliche virtualisierte Ressourcen (z. B. Rechen-, Speicher-, Netzwerkressourcen, einschließlich spezifischer Hardwareunterstützung); Latenzanforderungen (z. B. maximale Latenz, wie streng die Latenzbeschränkungen sind, Latenzfairness zwischen Benutzern); Anforderungen hinsichtlich des Standorts; Multi-Access-Edge-Dienste, die erforderlich und/oder nützlich sind, damit die MEC-Apps 2726 ausgeführt werden können; Multi-Access-Edge-Dienste, die die MEC-Anwendungen 2726 nutzen können, falls verfügbar; Konnektivitäts- oder Mobilitätsunterstützung/-anforderungen (z. B. Anwendungszustandsverlagerung, Anwendungsinstanzverlagerung); erforderliche Multi-Access-Edge-Merkmale, wie etwa VM-Verlagerungsunterstützung oder UE-Identität; erforderliche Netzwerkkonnektivität (z. B. Konnektivität mit Anwendungen innerhalb des MEC-Systems 2700, Konnektivität mit lokalen Netzwerken oder mit dem Internet); Informationen über die Bereitstellung des MEC-System 2700 oder die Bereitstellung des Mobilnetzwerks des Betreibers (z. B. Topologie, Kosten); Anforderungen hinsichtlich des Zugriffs auf Benutzerverkehr; Anforderungen hinsichtlich persistenter Speicherung; Verkehrsregeln 2740; DNS-Regeln 2742; usw.
  • Der MEC-O 2710 berücksichtigt die oben aufgelisteten Anforderungen und Informationen sowie Informationen über die gegenwärtig im MEC-System 2700 verfügbaren Ressourcen, um einen oder mehrere MEC-Server 2702 zum Hosten von MEC-Apps 2726 und/oder zum Abladen von Berechnungen auszuwählen. Nachdem ein oder mehrere MEC-Server XE136 ausgewählt wurden, fordert der MEC-O 2710 den oder die ausgewählten MEC-Hosts 2702 auf, die Anwendung(en) oder Anwendungsaufgaben zu instanziieren. Der tatsächliche Algorithmus, der zum Auswählen der MEC-Server 2702 verwendet wird, hängt von der Implementierung, Konfiguration und/oder der Bedienerbereitstellung ab. Der eine oder die mehreren Auswahlalgorithmen können auf den Aufgabenabladekriterien/-parametern basieren, indem zum Beispiel Netzwerk-, Rechen- und Energieverbrauchsanforderungen zum Durchführen von Anwendungsaufgaben sowie Netzwerkfunktionalitäten, Verarbeitungs- und Abladecodierungen/Codierungen berücksichtigt werden oder Verkehr zwischen verschiedenen RATs unterschieden wird. Unter gewissen Umständen (z. B. UE-Mobilitätsereignissen, die zu einer erhöhten Latenz führen, Lastausgleichsentscheidungen usw.), und falls unterstützt, kann der MEC-O 2710 entscheiden, einen oder mehrere neue MEC-Hosts 2702 auszuwählen, die als ein Primär-/Quellknoten fungieren sollen, und die Übertragung einer Anwendungsinstanz oder anwendungsbezogener Zustandsinformationen von dem einen oder den mehreren Quell-MEC-Hosts 2702 zu dem einen oder den mehreren Ziel-MEC-Hosts 2702 initiiert.
  • Bei einer ersten Implementierung wird eine UPF des 5GS als die MEC-Datenebene 2724 in die MEC-Architektur 2700 abgebildet. Bei dieser Implementierung behandelt die UPF den UP-Pfad von PDU-Sitzungen. Zusätzlich stellt die UPF die Schnittstelle zu einem Datennetzwerk (z. B. DN 175 und/oder lokalen Dienst 170 in 1A-1B) bereit und unterstützt die Funktionalität eines PDU-Sitzungsankers.
  • Bei einer zweiten Implementierung wird eine Anwendungsfunktion (AF) des 5GS als die MEC-Plattform 2732 in die MEC-Architektur 2700 abgebildet. Bei diesen Implementierungen ist die AF konfigurierbar oder betreibbar, um einen Anwendungseinfluss auf Verkehrsrouting, Zugangsnetzwerkfähigkeitsoffenlegung durchzuführen und mit dem Richtlinien-Framework zur Richtliniensteuerung zu interagieren. Die zweite Implementierung kann mit der ersten Implementierung kombiniert werden, oder sie kann eine eigenständige Implementierung sein. Da Benutzerverkehr zum lokalen DN geleitet wird, können bei der ersten und/oder zweiten Implementierung die MEC-Apps 2726, 2727 und/oder 2728 in oder auf das DN des 5GS abgebildet werden.
  • Bei einer dritten Implementierung kann das RAN von 5GS ein virtuelles RAN basierend auf einer VNF sein, und die UPF ist konfigurierbar oder funktionsfähig, um als die MEC-Datenebene 2724 innerhalb einer NF-Virtualisierungsinfrastruktur (NFVI - NF Virtualization Infrastructure) (z. B. VI 2722) zu fungieren. Bei diesen Implementierungen kann die AF als MEC-Plattform-VNF mit MEC-APIs, MEC-App-Aktivierungsfunktionalität (siehe z. B. [MEC009]) und API-Prinzipienfunktionalität (siehe z. B. [MEC009]) konfiguriert sein. Außerdem umfasst das lokale DN MEC-Apps 2726, 2727 und/oder 2728, die als VNFs instanziiert sind. Diese Implementierung kann dazu konfiguriert sein, Funktionalitäten gemäß [MEC003] und/oder ETSI GR MEC 017 V1.1.1 (2018-02) („[MEC017]“) bereitzustellen. Die dritte Implementierung kann mit der ersten Implementierung und/oder der zweiten Implementierung kombiniert werden, oder sie kann eine eigenständige Implementierung sein.
  • Zusätzlich oder alternativ dazu kann der Zugangsebenen-Edge (z. B. die verschiedenen hier erörterten NANs und/oder (R)ANs) eine oder mehrere APIs verwenden, um mit Edge-Netzwerken auf lokaler/regionaler Ebene zu kommunizieren. Die Edge-Netzwerke auf lokaler/regionaler Ebene können Netzwerkknoten umfassen, die entsprechende Anwendungen verwenden, um mit einem Edge-Netzwerk auf nationaler Ebene zu kommunizieren. Die Edge auf nationaler Ebene kann verschiedene NANs umfassen, die Anwendungen zum Zugreifen auf eine oder mehrere entfernte Clouds innerhalb der Edge auf globaler Ebene verwenden. Die NANs sind auch für vertikale Segmentverwaltung und SLA-Einhaltung konfigurierbar oder betreibbar. Zusätzlich oder alternativ kann MEC-Bereitstellung auf der Definition von „Edge“ zum Bereitzustellen von Freiheitsgraden für MNOs basieren, insbesondere wenn MEC in einer NFV-Umgebung bereitgestellt wird (zum Beispiel können MEC-Entitäten als virtualisierte NFs (VNFs) instanziiert werden, somit mit hoher Flexibilität hinsichtlich der Bereitstellung für den Betreiber).
  • Zusätzlich oder alternativ dazu kann das MEC-System 2700 in Abhängigkeit vom Anwendungsfall/vertikalen Segment/zu verarbeitenden Informationen flexibel bereitgestellt werden. Einige Komponenten des MEC-Systems 2700 können ortsgleich mit anderen Elementen des Systems angeordnet sein. Als ein Beispiel muss eine MEC-App 2726 in bestimmten Anwendungsfällen (z. B. Unternehmen) einen MEC-Dienst lokal konsumieren, und es kann effizient sein, einen MEC-Host bereitzustellen, der lokal mit dem benötigten Satz von APIs ausgestattet ist. Bei einem anderen Beispiel kann das Bereitstellen eines MEC-Servers 2702 in einem Rechenzentrum (das vom Zugangsnetzwerk entfernt sein kann) nicht einige APIs wie die RNI-API (die zum Sammeln von Funknetzwerkinformationen von der Funkbasisstation verwendet werden kann) hosten müssen. Andererseits können RNI-Informationen in den Cloud-RAN-Umgebungen (CRAN-Umgebungen) am Aggregationspunkt entwickelt und bereitgestellt werden, wodurch die Ausführung geeigneter funkbewusster Verkehrsverwaltungsalgorithmen ermöglicht wird. Zusätzlich oder alternativ kann eine Bandbreitenverwaltungs-API sowohl auf der Zugangsebenen-Edge als auch an entfernteren Edge-Standorten vorhanden sein, um Transportnetzwerke (z. B. für CDN-basierte Dienste) aufzubauen.
  • 28 stellt eine beispielhafte MEC-Dienstarchitektur 2800 dar. Die MEC-Dienstarchitektur 2800 umfasst den MEC-Dienst 2805, die ME-Plattform 2810 (die der MEC-Plattform 2732 entspricht) und Anwendungen (Apps) 1 bis N (wobei N eine Zahl ist). Als ein Beispiel kann die App 1 ein/e CDN-App/-Dienst sein, die/der 1 bis n Sitzungen hostet (wobei n eine Zahl ist, die gleich oder verschieden von N ist), App 2 kann ein/e Spiele-App/-Dienst sein, die/der als zwei Sitzungen hostend dargestellt ist, und App N kann irgendeine andere App/irgendein anderer Dienst sein, die/der als eine einzelne Instanz (die z. B. keine Sitzungen hostet) dargestellt ist. Jede App kann eine verteilte Anwendung sein, die Aufgaben und/oder Arbeitslasten zwischen Ressourcenanbietern (z. B. Servern wie etwa der ME-Plattform 2810) und Konsumenten (z. B. UEs 101, Benutzer-Apps, die durch einzelne UEs 101 instanziiert werden, anderen Servern/Diensten, Netzwerkfunktionen, Anwendungsfunktionen usw.) partitioniert. Jede Sitzung stellt einen interaktiven Informationsaustausch zwischen zwei oder mehr Elementen, wie etwa einer clientseitigen App und ihrer entsprechenden serverseitigen App, einer durch ein UE 101 instanziierten Benutzer-App und einer durch die ME-Plattform 2810 instanziierten MEC-App und/oder dergleichen, dar. Eine Sitzung kann beginnen, wenn die App-Ausführung gestartet oder initiiert wird, und enden, wenn die App die Ausführung verlässt oder beendet. Zusätzlich oder alternativ kann eine Sitzung beginnen, wenn eine Verbindung hergestellt wird, und enden, wenn die Verbindung beendet wird. Jede App-Sitzung kann einer gegenwärtig laufenden App-Instanz entsprechen. Zusätzlich oder alternativ dazu kann jede Sitzung einer Protokolldateneinheits-(PDU- )Sitzung oder einer Mehrfachzugangs-(MA-)PDU-Sitzung entsprechen. Eine PDU-Sitzung ist eine Assoziation zwischen einem UE 101 und einem DN, das einen PDU-Konnektivitätsdienst bereitstellt, der ein Dienst ist, der den Austausch von PDUs zwischen einem UE 101 und einem Datennetzwerk 170, 175 bereitstellt. Eine MA-PDU-Sitzung ist eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der jeweils ein Zugangsnetzwerk oder gleichzeitig ein 3GPP-Zugangsnetzwerk 110A und ein Nicht-3GPP-Zugangsnetzwerk 110B verwenden kann. Außerdem kann jede Sitzung mit einer Sitzungskennung (ID) assoziiert sein, die Daten sind, die eine Sitzung eindeutig identifizieren, und jede App (oder App-Instanz) kann mit einer APP-ID (oder APP-Instanz-ID) assoziiert sein, wobei es sich um Daten handelt, die eine App (oder App-Instanz) eindeutig identifizieren.
  • Der MEC-Dienst 2805 stellt für MEC-Dienstkonsumenten (z. B. Apps 1 bis N) einen oder mehrere MEC-Dienste 2736 bereit. Der MEC-Dienst 2805 kann optional als Teil der Plattform (z. B. ME-Plattform 2810) oder als Anwendung (z. B. ME-App) ausgeführt werden. Verschiedene Anwendungen 1 bis N können unabhängig davon, ob sie eine einzelne Instanz oder mehrere Sitzungen verwalten (z. B. CDN), spezifische Dienstinfo pro Anforderung für die gesamte Anwendungsinstanz oder verschiedene Anforderungen pro Sitzung anfordern. Der MEC-Dienst 2805 kann alle Anforderungen aggregieren und auf eine Weise agieren, die hilft, die BW-Nutzung zu optimieren und Erfahrungsqualität (QoE) für Anwendungen zu verbessern.
  • Der MEC-Dienst 2805 stellt eine MEC-Dienst-API bereit, die sowohl Anfragen als auch Abonnements (z. B. Pub/Sub-Mechanismus) unterstützt, die über eine Representational-State-Transfer-(„REST“- oder „RESTful“-)API oder über alternative Transporte, wie etwa einen Nachrichtenbus, verwendet werden. Für das RESTful-Architekturmodell enthalten die MEC-APIs die HTTP-Protokollbindungen für Verkehrsverwaltungsfunktionalität.
  • Jede HTTP-Nachricht (HTTP - Hypertext Transfer Protocol) ist entweder eine Anforderung oder eine Antwort. Ein Server hört eine Verbindung auf eine Anforderung hin ab, parst jede empfangene Nachricht, interpretiert die Nachrichtensemantik in Bezug auf das identifizierte Anforderungsziel und antwortet auf diese Anforderung mit einer oder mehreren Antwortnachrichten. Ein Client erstellt Anforderungsnachrichten, um spezifische Absichten zu kommunizieren, untersucht empfangene Antworten, um zu sehen, ob die Absichten ausgeführt wurden, und bestimmt, wie die Ergebnisse zu interpretieren sind. Das Ziel einer HTTP-Anforderung wird als „Ressource“ bezeichnet. Zusätzlich oder alternativ ist eine „Ressource“ ein Objekt mit einem Typ, assoziierten Daten, einem Satz von Verfahren, die darauf arbeiten, und Beziehungen zu anderen Ressourcen, falls anwendbar. Jede Ressource wird durch mindestens einen URI (Uniform Resource Identifier) identifiziert, und ein Ressourcen-URI identifiziert höchstens eine Ressource. Ressourcen werden von der RESTful-API unter Verwendung von HTTP-Verfahren (zum Beispiel POST, GET, PUT, DELETE usw.) bearbeitet. Bei jedem HTTP-Verfahren wird eine Ressourcen-URI in der Anforderung zur Adressierung einer bestimmten Ressource durchlaufen. Operationen an Ressourcen beeinflussen den Zustand der entsprechenden verwalteten Entitäten.
  • In Anbetracht dessen, dass eine Ressource irgendetwas sein könnte, und dass die einheitliche Schnittstelle, die durch HTTP bereitgestellt wird, einem Fenster ähnlich ist, durch das man solch ein Ding nur durch die Kommunikation von Nachrichten an irgendeinen unabhängigen Akteur auf der anderen Seite beobachten und darauf einwirken kann, ist eine Abstraktion erforderlich, um den aktuellen oder gewünschten Zustand dieses Dings in unserer Kommunikation darzustellen („an seine Stelle zu treten“). Diese Abstraktion wird als Darstellung bezeichnet. Für die Zwecke von HTTP handelt es sich bei einer „Darstellung“ um Informationen, die einen vergangenen, aktuellen oder gewünschten Zustand einer gegebenen Ressource in einem Format widerspiegeln sollen, das leicht über das Protokoll kommuniziert werden kann. Eine Darstellung umfasst einen Satz von Darstellungsmetadaten und einen potentiell unbegrenzten Strom von Darstellungsdaten. Zusätzlich oder alternativ ist eine Ressourcendarstellung eine Serialisierung eines Ressourcenzustands in einem bestimmten Inhaltsformat.
  • Ein Ursprungsserver könnte mit mehreren Darstellungen versehen werden oder zum Erzeugen mehrerer Darstellungen in der Lage sein, die jeweils den aktuellen Zustand einer Zielressource widerspiegeln sollen. In solchen Fällen wird irgendein Algorithmus durch den Ursprungsserver verwendet, um eine dieser Darstellungen üblicherweise basierend auf Inhaltsverhandlung als am besten anwendbar für eine gegebene Anforderung auszuwählen. Diese „ausgewählte Darstellung“ wird verwendet, um die Daten und Metadaten zum Evaluieren bedingter Anforderungen bereitzustellen, die Nutzlast für Antwortnachrichten erstellen (z. B. 200-OK-, 304-Not-Modified-Antworten auf GET und dergleichen). Eine Ressourcendarstellung ist im Nutzlastkörper einer HTTP-Anforderung- oder Antwortnachricht enthalten. Ob eine Darstellung in einer Anforderung erforderlich ist oder nicht, hängt von dem verwendeten HTTP-Verfahren ab (siehe z. B. Fielding et al., „Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content“, IETF RFC 7231 (Juni 2014)).
  • Die MEC-API-Ressourcen-URIs (URI - Universal Resource Indicators) werden in verschiedenen ETSI-MEC-Standards, wie etwa den hier erwähnten, erörtert. Die MTS-API unterstützt zusätzliche anwendungsbezogene Fehlerinformationen, die in der HTTP-Antwort bereitgestellt werden sollen, wenn ein Fehler auftritt (siehe z. B. Klausel 6.15 von ETSI GS MEC 009 V2.1.1 (2019-01) („[MEC009]“)). Die Syntax jeder Ressourcen-URI folgt [MEC009] sowie Berners-Lee et al., „Uniform Resource Identifier (URI): Generic Syntax“, IETF Network Working Group, RFC 3986 (Januar 2005), und/oder Nottingham, „URI Design and Ownership“, IETF RFC 8820 (Juni 2020). In den RESTful-MEC-Dienst-APIs, einschließlich der VIS-API, weist die Ressourcen-URI-Struktur für jede API die folgende Struktur auf:
    • {apiRoot}/{apiName}/{apiVersion}/{apiSpecificSuffixes}
  • Hierbei umfasst „apiRoot“ das Schema („https“), den Host und den optionalen Port und eine optionale Präfixzeichenfolge. „apiName“ definiert den Namen der API (z. B. MTS-API, RNI-API usw.). „apiVersion“ stellt die Version der API dar, und „apiSpecificSuffixes“ definiert den Baum von Ressource-URIs in einer bestimmten API. Die Kombination von „apiRoot“, „apiName“ und „apiVersion“ wird als Stamm-URI bezeichnet. „apiRoot“ steht unter der Kontrolle Bereitstellung, während die übrigen Teile des URI unter der Kontrolle der API-Spezifikation stehen. Im obigen Stamm werden „apiRoot“ und „apiName“ unter Verwendung des Dienstregisters (siehe z. B. Dienstregister 2738 in 27) erkannt. Es umfasst das Schema („http“ oder „https“), den Host und den optionalen Port und eine optionale Präfixzeichenfolge. Für eine gegebene MEC-API kann „apiName“ auf „mec“ gesetzt werden und „apiVersion“ kann auf eine geeignete Versionsnummer gesetzt werden (z. B. „v1“ für Version 1). Die MEC-APIs unterstützen HTTP über TLS (auch als HTTPS bekannt). Alle Ressource-URIs in den MEC-API-Prozeduren sind relativ zum obigen Stamm-URI definiert.
  • Das JSON-Inhaltsformat kann auch unterstützt werden. Das JSON-Format wird durch den Inhaltstyp „application/json“ signalisiert. Die MTS-API kann den OAuth2.0-Client-Berechtigungsnachweiserteilungstyp mit Träger-Token verwenden (siehe z. B. [MEC009]). Der Token-Endpunkt kann als Teil der in [MEC009] definierten Dienstverfügbarkeitsabfrageprozedur erkannt werden. Die Client-Berechtigungsnachweise können unter Verwendung bekannter Bereitstellungsmechanismen in der MEC-APP bereitgestellt werden.
  • 3. HARDWAREKOMPONENTEN, KONFIGURATIONEN UND ANORDNUNGEN
  • 29 veranschaulicht eine Softwareverteilungsplattform 2905 zum Verteilen von Software 2960, wie etwa den beispielhaften computerlesbaren Anweisungen 3160 von 31, an eine oder mehrere Vorrichtungen, wie etwa beispielhafte Prozessorplattform(en) 2900 und/oder beispielhafte verbundene Edge-Vorrichtungen 3162 (siehe z. B. 31) und/oder beliebige der anderen hier erörterten Rechensysteme/Vorrichtungen. Die beispielhafte Softwareverteilungsplattform 2905 kann durch einen beliebigen Computerserver, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, die/der in der Lage ist, Software zu speichern und an andere Rechenvorrichtungen (z. B. Dritte, die beispielhaften verbundenen Edge-Vorrichtungen 3162 von 31) zu übertragen. Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (z. B. Server), Dritte (z. B. Kunden einer Entität sein, die die Softwareverteilungsplattform 2905 besitzt und/oder betreibt). Beispielhafte verbundene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. Bei einigen Beispielen ist eine dritte Partei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa den beispielhaften computerlesbaren Anweisungen 3160 von 31. Die Dritten können Konsumenten, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren. In einigen Beispielen veranlasst verteilte Software die Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs), um die eine oder die mehreren Vorrichtungen (z. B. verbundene Edge-Vorrichtungen) zu identifizieren, die geographisch und/oder logisch voneinander getrennt sind (z. B. physisch getrennte IoT-Vorrichtungen, die mit der Steuerung der Wasserverteilung (z. B. Pumpen), der Stromverteilung (z. B. Relais) usw. betraut sind).
  • In 29 umfasst die Softwareverteilungsplattform 2905 einen oder mehrere Server und eine oder mehrere Speichervorrichtungen. Die Speichervorrichtungen speichern die computerlesbaren Anweisungen 2960, die den beispielhaften computerlesbaren Anweisungen 3160 von 31 entsprechen können, wie oben beschrieben. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 2905 stehen in Kommunikation mit einem Netzwerk 2910, das einem oder mehreren des Internet und/oder der beispielhaften Netzwerke, wie hier beschrieben, entsprechen kann. Bei 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 Zustellung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Dritt-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 2960 von der Softwareverteilungsplattform 2905 herunterzuladen. Zum Beispiel kann die Software 2960, die den beispielhaften computerlesbaren Anweisungen 3160 von 31 entsprechen kann, auf die beispielhafte(n) Prozessorplattform(en) 2900 heruntergeladen werden, die die computerlesbaren Anweisungen 2960 ausführen soll/sollen, um Funk-Apps zu implementieren.
  • In einigen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 2905 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, die die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 2960 passieren müssen. In einigen Beispielen bieten ein oder mehrere Server der Softwareverteilungsplattform 1105 periodisch Aktualisierungen für die Software (z. B. die beispielhaften computerlesbaren Anweisungen 1032 von 10) an, übertragen und/oder erzwingen solche, um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewendet werden.
  • In 29 sind die computerlesbaren Anweisungen 2960 auf Speichervorrichtungen der Softwareverteilungsplattform 2905 in einem bestimmten Format gespeichert. Ein Format computerlesbarer Anweisungen umfasst unter anderem eine spezifische Codesprache (zum Beispiel Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen spezifischen Codezustand (zum Beispiel unkompilierter Code (zum Beispiel ASCII), interpretierter Code, verknüpfter Code, ausführbarer Code (zum Beispiel eine Binärdatei) usw.). Bei einigen Beispielen sind die computerlesbaren Anweisungen D182, die in der Softwareverteilungsplattform 2905 gespeichert sind, in einem ersten Format, wenn sie an die beispielhafte(n) Prozessorplattform(en) 2900 übertragen werden. In einigen Beispielen ist das erste Format eine ausführbare Binärdatei, in der bestimmte Typen der Prozessorplattform(en) 2900 ausführen 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 Ausführung auf der (den) beispielhaften Prozessorplattform(en) 2900 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 2900 die computerlesbaren Anweisungen 2960 möglicherweise im ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der in der Lage ist, auf der(den) Prozessorplattform(en) 2900 ausgeführt zu werden. In noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der Prozessorplattform(en) 2900 durch einen Interpreter interpretiert wird, um die Ausführung von Anweisungen zu ermöglichen.
  • 30 und 31 stellen weitere Beispiele für Edge-Computing-Systeme und -Umgebungen dar, die beliebige der hier erörterten Rechenknoten oder -vorrichtungen verwirklichen können. Jeweilige Edge-Rechenknoten können 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. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Computersystem (z. B. ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System umgesetzt sein, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen.
  • In 30 weist ein Edge-Rechenknoten 3000 eine Rechen-Engine (hier auch als „Rechenschaltungsanordnung“ bezeichnet) 3002, ein Eingabe-/Ausgabe-Subsystem (E/A-Subsystem) 3008, einen Datenspeicher 3010, ein Kommunikationsschaltungsanordnungs-Subsystem 3012 und optional eine oder mehrere Peripherievorrichtungen 3014 auf. Bei anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Komponenten umfassen, wie etwa jene, die typischerweise in einem Computer zu finden sind (z. B. einer Anzeige, Peripherievorrichtungen usw.). Zusätzlich dazu können bei einigen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderweitig einen Teil davon bilden.
  • Der Rechenknoten 3000 kann als ein beliebiger Typ von Engine, Vorrichtung, oder Sammlung von Vorrichtungen ausgeführt sein, die zum Durchführen verschiedener Rechenfunktionen in der Lage ist. Der Rechenknoten 3000 kann dem MX-Client 101, dem Zugangsnetzwerk 110 (oder einem Rechenknoten darin), dem NAN 111(oder einem Rechenknoten darin), dem MX-Server 140, dem Kernnetzwerk 150A (oder einem Rechenknoten darin) und/oder dem FA-GW/Kern 150B (oder einem Rechenknoten darin) von 1; dem Client 201, den Zugangsnetzwerken 231 (oder einem Rechenknoten darin), dem MAMS-System 235 (oder einem Rechenknoten darin) und/oder den Kernnetzwerken 241 (oder einem Rechenknoten darin) von 2; der GMA-Tx-Entität 510 und/oder dem GMA-Rx 511 von 5; den GWs 1420A-1420B und/oder dem NAT-/Firewall-Gateway 1450 von 14; den UEs 2011, 2021a, den NANs 2031-2033, den Edge-Rechenknoten 2036, dem CN 2042 (oder einem oder mehreren Rechenknoten darin), und/oder der Cloud 2044 (oder einem oder mehreren Rechenknoten darin) von 20; der Zentrale 2120, dem NAN 2140, dem lokalen Verarbeitungshub 2150 und/oder den Datenquellen 2160 von 21; beliebigen der in Bezug auf 22-28 dargestellten und beschriebenen Vorrichtungen; der oder den Prozessorplattform(en) 2900 und/oder der Verteilungsplattform 2905 von 29; und/oder beliebigen anderen Vorrichtungen/Systemen entsprechen, die hierin erörtert werden.
  • Bei einigen Beispielen kann der Rechenknoten 3000 als eine einzelne Vorrichtung umgesetzt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein FPGA, ein Systemchip (SoC - System-on-Chip) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. Der Rechenknoten 3000 weist einen Prozessor 3004 und einen Speicher 3006 auf oder ist als solcher ausgeführt. Der Prozessor 3004 kann als ein beliebiger Typ von Prozessor umgesetzt sein, der in der Lage ist, die hierin beschriebenen Funktionen durchzuführen (z. B. eine Anwendung auszuführen). Der Prozessor 3004 kann zum Beispiel als (ein) Mehrfachkernprozessor(en), ein Mikrocontroller oder ein anderer Prozessor oder Verarbeitungs-/Steuerschaltkreis ausgeführt sein.
  • Bei einigen Beispielen kann der Prozessor 3004 als FPGA, anwendungsspezifische integrierte Schaltung (ASIC), rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder andere spezialisierte Hardware umgesetzt sein, diese umfassen oder damit gekoppelt sein, um die Durchführung der hier beschriebenen Funktionen zu ermöglichen. In einigen Beispielen kann der Prozessor 704 auch als eine spezialisierte x-Verarbeitungseinheit (xPU) realisiert sein, die auch als Datenverarbeitungseinheit (DPU), Infrastrukturverarbeitungseinheit (IPU) oder Netzwerkverarbeitungseinheit (NPU) bekannt ist. Solch eine xPU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungspaket realisiert, in einen SoC integriert oder mit einer Vernetzungsschaltungsanordnung (z. B. einer SmartNIC oder erweiterten SmartNIC), einer Beschleunigungsschaltungsanordnung, Speichervorrichtungen oder einer KI-Hardware (z. B. GPUs, programmierten FPGAs) integriert sein. Solch eine xPU kann dazu ausgelegt sein, Programmierung zu empfangen, um außerhalb der CPU oder Allzweckverarbeitungshardware einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme durchzuführen (wie etwa Hosten von Mikrodiensten, Durchführen von Dienstverwaltung oder -orchestrierung, Organisieren oder Verwalten von Server- oder Rechenzentrum-Hardware, Verwalten von Dienstnetzen oder Sammeln und Verteilen von Telemetrie). Es versteht sich jedoch, dass eine xPU, ein SOC, eine CPU und andere Varianten des Prozessors 3004 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb des Rechenknotens 3000 oder für diesen auszuführen.
  • Der Speicher 3006 kann als ein beliebiger Typ flüchtiger (z. B. dynamischer Direktzugriffsspeicher (DRAM - Dynamic Random Access Memory) usw.) oder nichtflüchtiger Arbeitsspeicher oder Datenspeicher realisiert sein, der in der Lage ist, die hier beschriebenen Funktionen durchzuführen. Ein flüchtiger Speicher kann ein Speichermedium sein, das Leistung benötigt, um den Zustand von Daten aufrechtzuerhalten, die vom Medium gespeichert werden. Nicht einschränkende Beispiele für flüchtigen Speicher können diverse Typen von Direktzugriffsspeicher (RAM), wie DRAM oder statischen Direktzugriffsspeicher (SRAM), umfassen. Ein spezifischer Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM - Synchronous Dynamic Random Access Memory).
  • In einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung wie jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine dreidimensionale Kreuzpunkt-Speichervorrichtung (z. B. einen Intel® 3D XPoint™-Speicher) oder andere byteadressierbare nichtflüchtige In-Situ-Schreib-Speichervorrichtungen umfassen. Die Speichervorrichtung kann sich auf den Die selbst und/oder auf ein gehäustes Speicherprodukt beziehen. In einigen Beispielen kann der 3D-Kreuzpunktspeicher (z. B. Intel® 3D XPoint™-Speicher) eine transistorlose stapelbare Kreuzpunktarchitektur umfassen, wobei Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind, und wobei die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert. In einigen Beispielen kann die Gesamtheit oder ein Teil des Speichers 706 in den Prozessor 704 integriert sein. Der Hauptspeicher 3006 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 3002 ist über das E/A-Subsystem 3008, das als Schaltungsanordnung und/oder Komponenten realisiert sein kann, kommunikativ mit anderen Komponenten des Rechenknotens 3000 gekoppelt, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 3002 (z. B. mit dem Prozessor 3004 und/oder dem Hauptspeicher 3006) und anderen Komponenten der Rechenschaltungsanordnung 3002 zu ermöglichen. Das E/A-Subsystem 3008 kann zum Beispiel als Speichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmware-Vorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Subsysteme zum Ermöglichen der Eingabe/Ausgabe-Operationen realisiert sein oder diese anderweitig umfassen. In einigen Beispielen kann das E/A-Subsystem 3008 einen Teil eines SoC bilden und zusammen mit einem oder mehreren des Prozessors 3004, des Hauptspeichers 3006 und/oder anderer Komponenten der Rechenschaltungsanordnung 3002 in die Rechenschaltungsanordnung 3002 integriert sein.
  • Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen 3010 können als eine oder mehre von einer oder mehreren beliebigen Art(en) von physischen Vorrichtung(en) realisiert sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert ist/sind, wie zum Beispiel Speichervorrichtungen, Speicher, Schaltungsanordnung, Speicherkarten, Flash-Speicher, Festplattenlaufwerke, Festkörperlaufwerke (SSD - Solid-State Drive) und/oder andere Datenspeichervorrichtungen/-platten. Einzelne Datenspeichervorrichtungen/-platten 3010 können eine Systempartition umfassen, die Daten und Firmwarecode für die Datenspeichervorrichtung/-platte 3010 speichert. Einzelne Datenspeichervorrichtungen/-platten 3010 können auch eine oder mehrere Betriebssystempartitionen umfassen, die Datendateien und ausführbare Dateien für Betriebssysteme zum Beispiel in Abhängigkeit vom Typ des Rechenknotens 3000 speichern.
  • Die Kommunikationsschaltungsanordnung 3012 kann als eine beliebige Kommunikationsschaltung oder -vorrichtung oder eine Sammlung davon realisiert sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 3002 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway oder dergleichen) zu ermöglichen. Die Kommunikationsschaltungsanordnung 3012 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechniken (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein zellulares Vernetzungsprotokoll, wie etwa einen 3GPP-4G- oder -5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/Wi-Fi®, ein Wireless Wide Area Network)-Protokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, ein LPWAN (Low-Power Wide Area Network)- oder ein LPWA (Low-Power Wide Area)-Protokoll usw.) zu verwenden, um solch eine Kommunikation durchzuführen.
  • Die Kommunikationsschaltungsanordnung 3012 umfasst eine Netzwerkschnittstellensteuerung (NIC) 3020, die auch als Host-Fabric-Schnittstelle (HFI) bezeichnet werden kann. Die NIC 3020 kann als eine oder mehrere Add-in-Karten, Tochterkarten, Netzwerkschnittstellenkarten, Controllerchips, Chipsätze oder andere Vorrichtungen realisiert sein, die durch den Rechenknoten 3000 verwendet werden können, um eine Verbindung mit einer anderen Rechenvorrichtung herzustellen. In einigen Beispielen kann die NIC 3020 als Teil eines Systemchips (SoC) realisiert sein, der einen oder mehrere Prozessoren umfasst, oder in einem Mehrchipgehäuse enthalten sein, das auch einen oder mehrere Prozessoren umfasst. In einigen Beispielen kann die NIC 3020 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) umfassen, die beide lokal an der NIC 3020 sind. In solchen Beispielen kann der lokale Prozessor der NIC 3020 dazu in der Lage sein, eine oder mehrere der Funktionen der hier beschriebenen Rechenschaltungsanordnung 3002 durchzuführen. Zusätzlich oder alternativ dazu kann in solchen Beispielen der lokale Speicher der NIC 3020 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
  • Zusätzlich kann in einigen Beispielen ein jeweiliger Rechenknoten 3000 eine oder mehrere Peripherievorrichtungen 3014 umfassen. Solche Peripherievorrichtungen 3014 können eine beliebige Art von Peripherievorrichtung umfassen, die je nach der spezifischen Art des Rechenknotens 3000 in einer Rechenvorrichtung oder einem Server zu finden ist, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe-/Ausgabevorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen. In weiteren Beispielen kann der Rechenknoten 3000 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Computing-System (z. B. Client-Rechenknoten, Edge-Gateway-Knoten, Edge-Aggregationsknoten, V-ITS-Ss, die zuvor erörtert wurden, usw.) oder ähnliche Formen von Geräten, Computern, Subsystemen, Schaltungen oder anderen Komponenten umgesetzt sein.
  • 31 veranschaulicht ein Beispiel für Komponenten, die in einem Edge-Computing-Knoten 3150 zum Implementieren der hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methoden) vorhanden sein können. Der Edge-Computing-Knoten 3150 kann dem MX-Client 101, dem Zugangsnetzwerk 110 (oder einem Rechenknoten darin), dem NAN 111 (oder einem Rechenknoten darin), dem MX-Server 140, dem Kernnetzwerk 150A (oder einem Rechenknoten darin) und/oder dem FA-GW/Kern 150B (oder einem Rechenknoten darin) von 1; dem Client 201, den Zugangsnetzwerke 231 (oder einem Rechenknoten darin), dem MAMS-System 235 (oder einem Rechenknoten darin) und/oder den Kernnetzwerke 241 (oder einem Rechenknoten darin) von 2; der GMA-Tx-Entität 510 und/oder dem GMA-Rx 511 von 5; dem GW 1420A-1420B und/oder dem NAT/Firewall Gateway 1450 von 14; den UEs 2011, 2021a, NANs 2031-2033, den Edge-Rechenknoten 2036, dem CN 2042 (oder einem oder mehreren Rechenknoten darin) und/oder der Cloud 2044 (oder einem oder mehreren Rechenknoten darin) von 20; der Zentrale 2120, dem NAN 2140, den lokalen Verarbeitungshubs 2150, und/oder den Datenquellen 2160 von 21; beliebigen der Vorrichtungen, die mit Bezug auf 22-28 gezeigt und beschrieben sind; der oder den Prozessorplattform(en) 2900 und/oder der Verteilungsplattform 2905 von 29; dem Rechenknoten 3000 von 30; und/oder beliebigen anderen Vorrichtungen/Systemen entsprechen, die hierin erörtert werden. Dieser Edge-Computing-Knoten 3150 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 3000 bereit, wenn als Rechenvorrichtung (z. B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) oder als Teil davon implementiert. Der Edge-Computing-Knoten 3150 kann beliebige Kombinationen der hierin erwähnten Hardware oder logischen Komponenten umfassen, und er kann eine jede Vorrichtung, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendet werden kann, umfassen oder damit gekoppelt sein. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Anweisungssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 3150 angepasst sind, oder als Komponenten, die anderweitig in ein Chassis eines größeren Systems integriert sind, implementiert sein.
  • Der Edge-Computing-Knoten 3150 weist Verarbeitungsschaltungsanordnung in Form eines oder mehrerer Prozessoren 3152 auf. Die Prozessorschaltungsanordnung 3152 umfasst Schaltungen, wie etwa unter anderem einen oder mehrere Prozessorkerne und eines oder mehrere von Cache-Speicher, Low-Dropout-Spannungsreglern (LDOs), Interrupt-Steuerungen, seriellen Schnittstellen, wie etwa SPI, I2C oder einem universellen programmierbaren seriellen Schnittstellenmodul, einer Echtzeituhr (RTC), Timer-Zählern, einschließlich Intervall- und Watchdog-Timern, Allzweck-E/A, Speicherkartensteuerungen, wie etwa Secure Digital/MultiMediaCard (SD/MMC) oder dergleichen, Schnittstellen, MIPI(Mobile Industry Processor Interface)-Schnittstellen und JTAG(Joint Test Access Group)-Testzugangsports. Bei einigen Implementierungen kann die Prozessorschaltungsanordnung 3152 einen oder mehrere Hardwarebeschleuniger (z. B. gleich oder ähnlich der Beschleunigungsschaltungsanordnung 3164) umfassen, die Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen (z. B. FPGA, ASIC usw.) oder dergleichen sein können. Der eine oder die mehreren Beschleuniger können zum Beispiel Beschleuniger für Computervision und/oder tiefes Lernen umfassen. Bei einigen Implementierungen kann die Prozessorschaltungsanordnung 3152 eine On-Chip-Speicherschaltungsanordnung umfassen, die jeden geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flash-Speicher, Festkörperspeicher und/oder einen beliebigen anderen Typ von Speichervorrichtungstechnologie, wie etwa jene hierin erörterten, umfassen kann.
  • Bei der Prozessorschaltungsanordnung 3152 kann es sich zum Beispiel um einen oder mehrere Prozessorkerne (CPUs), Anwendungsprozessoren, GPUs, RISC-Prozessoren, Acorn-RISC-Machine-(ARM-)Prozessoren, CISC-Prozessoren, einen oder mehrere DSPs, ein oder mehrere FPGAs, eine oder mehrere PLDs, eine oder mehrere ASICs, einen oder mehrere Basisbandprozessoren, eine oder mehrere integrierte Hochfrequenzschaltungen (RFIC), einen oder mehrere Mikroprozessoren oder Mikrocontroller, einen Mehrkernprozessor, einen Multithread-Prozessor, einen Ultraniederspannungsprozessor, einen eingebetteten Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder beliebige andere bekannte Verarbeitungselemente oder jede geeignete Kombination davon handeln. Die Prozessoren (oder Kerne) 3152 mit einem Arbeitsspeicher/Datenspeicher gekoppelt sein oder diesen umfassen und dazu konfiguriert sein, Anweisungen auszuführen, die im Arbeitsspeicher/Datenspeicher gespeichert sind, um zu ermöglichen, dass verschiedene Anwendungen oder Betriebssysteme auf dem Knoten 3150 ausgeführt werden. Der Prozessor (oder die Kerne) 3152 ist dazu konfiguriert, Anwendungssoftware zu betreiben, um einen spezifischen Dienst für einen Benutzer des Knotens 3150 bereitzustellen. Zusätzlich oder alternativ dazu können der eine oder die mehreren Prozessoren 3152 Spezialprozessor(en)/- steuerung(en) sein, der (die) dazu konfiguriert (oder konfigurierbar) ist (sind), gemäß den hier erörterten Elementen, Merkmalen und Implementierungen zu arbeiten.
  • Als Beispiele können der eine oder die mehreren Prozessoren 3152 einen Intel® Architecture Core™-basierten Prozessor, wie etwa einen i3-, einen i5-, einen i7-, einen i9-basierten Prozessor; einen Mikrocontroller-basierten Intel®-Prozessor, wie etwa einen Quark™-, einen Atom™- oder einen anderen MCU-basierten Prozessor; einen oder mehrere Pentium®-Prozessor(en), Xeon®-Prozessor(en) oder einen anderen solchen Prozessor umfassen, der von der Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist. Es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie etwa einer oder mehrere von AMD (Advanced Micro Devices) Zen® Architecture, wie etwa Ryzen®- oder EPYC®-Prozessor(en), (APUs (Accelerated Processing Units), MxGPUs, Epyc®-Prozessor(en) oder dergleichen; A5-A12- und/oder S1-S4-Prozessor(en) von AppleⓇ Inc., Snapdragon™- oder Centriq™-Prozessor(en) von Qualcomm® Technologies, Inc., OMAP™-Prozessor(en) (OMAP - Open Multimedia Applications Platform) von Texas Instruments, Inc.®; ein MIPS-basiertes Design von MIPS Technologies, Inc., wie die Prozessoren Warrior M-class, Warrior 1-class und Warrior P-class von MIPS; ein ARM-basiertes Design, lizenziert von ARM Holdings, Ltd., wie die Cortex-A-, Cortex-R- und Cortex-M-Prozessorfamilie von ARM; das von Cavium™, Inc. bereitgestellte ThunderX2®; oder dergleichen. In einigen Implementierungen können der eine oder die mehreren Prozessoren 3152 ein Teil eines System-on-Chip (SoC), System-in-Package (SiP), eines Multi-Chip-Package (MCP) und/oder dergleichen sein, wobei der eine oder die mehreren Prozessoren 3152 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse, wie etwa den Edison™- oder Galileo™-SoC-Platinen von Intel® Corporation, ausgebildet sind. Andere Beispiele für den einen oder die mehreren Prozessoren 3152 sind an anderer Stelle der vorliegenden Offenbarung erwähnt.
  • Der eine oder die mehreren Prozessoren 3152 können über eine Zwischenverbindung (IX) 3156 mit dem Systemspeicher 3154 kommunizieren. Eine beliebige Anzahl an Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC - Joint Electron Devices Engineering Council) sein, wie etwa den Standards DDR oder Mobile DDDR (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). Bei bestimmten Beispielen kann eine Speicherkomponente einem Standard entsprechen, der durch JEDEC veröffentlicht ist, wie etwa ESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F fürDDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low-Power-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3, und JESD209-4 für LPDDR4. Andere RAM-Typen, wie etwa dynamischer RAM (DRAM), synchroner DRAM (SDRAM) und/oder dergleichen, können ebenfalls enthalten sein. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. Bei diversen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von verschiedenen Package-Typen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Vorrichtungen können bei einigen Beispielen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. DIMMs (Dual Inline Memory Modules) verschiedener Varianten, darunter microDIMMs oder MiniDIMMs.
  • Um eine persistente Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann ein Datenspeicher 3158 auch über die IX 3156 mit dem Prozessor 3152 gekoppelt sein. Bei einem Beispiel kann der Datenspeicher 3158 über ein Festkörperplattenlaufwerk (SSDD - Solid-State Disk Drive) und/oder einen elektrisch löschbaren Hochgeschwindigkeitsspeicher (allgemein als „Flash-Speicher“ bezeichnet) implementiert werden. Andere Vorrichtungen, die für den Datenspeicher 3158 verwendet werden können, umfassen Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, XD-Bildkarten XD - eXtreme Digital) und dergleichen, und USB-Flash-Laufwerke. In einem Beispiel kann die Speichervorrichtung eine Speichervorrichtung sein oder umfassen, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Phasenwechselspeicher (PCM - Phase Change Memory) mit einer oder mehreren Ebenen, einen resistiven Speicher, einen Nanodrahtspeicher, einen ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM - Ferroelectric Transistor Random Access Memory), einen antiferroelektrischen Speicher, einen magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristor-Technologie umfasst, einen Phasenwechsel-RAM (PRAM - Phase Change RAM), einen resistiven Speicher auf Metalloxidbasis, Sauerstoffleerstellenbasis und Conductive-Brige-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque-(STT-)MRAM, eine Vorrichtung auf der Basis eines Spintronik-Speichers mit magnetischem Übergang, eine Vorrichtung auf der Basis eines magnetischen Tunnelübergangs (MTJ - Magnetic Tunneling Junction), eine Vorrichtung auf Domänenwand- und SOT-(Spin Orbit Transfer-)Basis, eine Speichervorrichtung Thyristorbasis oder eine Kombination beliebiger der obigen oder anderen Speicher einsetzt. Die Arbeitsspeicherschaltungsanordnung 3154 und/oder die Datenspeicherschaltungsanordnung 3158 können auch dreidimensionale (3D) Crosspoint-(XPOINT-)Speicher von Intel® und Micron® umfassen.
  • In Niederleistungsimplementierungen kann es sich beim Datenspeicher 3158 um On-Die-Speicher oder Register handeln, die mit dem Prozessor 3152 assoziiert sind. In einigen Beispielen kann der Datenspeicher 3158 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für den Datenspeicher 3158 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandsänderungsspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher.
  • Die Komponenten der Edge-Computing-Vorrichtung 3150 können über eine Zwischenverbindung (IX) 3156 kommunizieren. Die IX 3156 kann eine beliebige Anzahl von Technologien umfassen, darunter ISA, erweiterte ISA, I2C, SPI, Punkt-zu-Punkt-Schnittstellen, PMBus (Power Management Bus), PCI, PCIe, PCIx, Intel® UPI, Intel® Accelerator Link, Intel® CXL, CAPI, OpenCAPI, Intel® QPI, UPI, Intel® OPA IX, RapidIO™ System IXs, CCIX, Gen-Z Consortium IXs, eine HyperTransport-Zwischenverbindung, NVLink, bereitgestellt durch NVIDIA®, ein TTP-(Time-Trigger Protocol-)System, ein FlexRay-System und/oder eine beliebige Anzahl anderer IX-Technologien. Die IX 3156 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
  • Die IX 3156 koppelt den Prozessor 3152 mit einer Kommunikationsschaltungsanordnung 3166 zur Kommunikation mit anderen Vorrichtungen, wie etwa einem Remoteserver (nicht gezeigt) und/oder den verbundenen Edge-Vorrichtungen 3162. Die Kommunikationsschaltungsanordnung 3166 ist ein Hardwareelement oder eine Sammlung von Hardwareelementen, das/die zum Kommunizieren über ein oder mehrere Netzwerke (z. B. Cloud 3163) und/oder mit anderen Vorrichtungen (z. B. Edge-Vorrichtungen 3162) verwendet wird/werden. Die Sammlung von Hardwareelementen umfasst Hardwarevorrichtungen, wie etwa Basisbandschaltungsanordnung 316x, Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen).
  • Der Sendeempfänger 3166 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z. B. 2,4-Gigahertz-(GHz-)Übertragungen nach dem IEEE-802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy-(BLE-)Standards, wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards unter anderem. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 3162 verwendet werden. Zum Beispiel kann eine WLAN-Einheit (WLAN - Wireless Local Area Network) verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronics Engineers (IEEE) zu implementieren. Außerdem können drahtlose Weitverkehrskommunikationen, z. B. gemäß einem zellularen oder anderen Drahtlos-Weitverkehrsprotokoll über eine Einheit eines drahtlosen Weitverkehrsnetzwerks (WWAN - Wireless Wide Area Network) stattfinden.
  • Die Kommunikationsschaltungsanordnung 3166 (oder die mehreren Sendeempfänger 3166) kann (können) unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen mit unterschiedlicher Reichweite kommunizieren. Zum Beispiel kann die Kommunikationsschaltungsanordnung 3166 eine Kurzstrecken-RAT-Schaltungsanordnung 316y umfassen, um mit relativ nahen Vorrichtungen (zum Beispiel innerhalb von etwa 10 Metern) basierend auf BLE oder einem anderen Niederleistungsfunkgerät zu kommunizieren, um Leistung zu sparen. Weiter entfernte verbundene Edge-Vorrichtungen 3162 (z. B. innerhalb von etwa 50 Metern) können über ZigBee®-Schaltungsanordnung 316y und/oder andere Zwischenleistungsfunkgeräte 316y erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät 316y mit unterschiedlichen Leistungspegeln stattfinden, oder sie können über separate Sendeempfänger 316 y stattfinden, zum Beispiel einen lokalen Sendeempfänger 316y, der BLE verwendet, und einen separaten Mesh-Sendeempfänger 316y, der ZigBee® verwendet.
  • Ein Drahtlosnetzwerk-Sendeempfänger 316z kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 3163 über Orts- oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 316 z kann ein LPWA-Sendeempfänger sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 3150 kann über einen weiten Bereich unter Verwendung des von Semtech und der LoRa Alliance entwickelten LoRaWAN™ (Long Range Wide Area Network) kommunizieren. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Transceivern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken, wie beispielsweise Kanalspringen mit Zeitschlitzen, das in der Spezifikation IEEE 802.15.4e beschrieben ist, verwendet werden.
  • Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerk-Sendeempfänger 316z erwähnten Systemen verwendet werden, wie hierin beschrieben. Der Sendeempfänger 316 z kann zum Beispiel einen zellularen Sendeempfänger umfassen, der Spreizspektrum-(SPA/SAS-)Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa WiFi®-Netzwerke für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzkommunikationen. Der Sendeempfänger 316z kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen kompatibel sind, wie etwa LTE- und 5G/NR-Kommunikationssysteme, die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden.
  • Eine Netzwerkschnittstellensteuerung (NIC) 3168 kann enthalten sein, um eine drahtgebundene Kommunikation mit Knoten der Edge-Cloud 3163 oder mit anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 3162 (z. B. die in einem Mesh arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen, oder sie kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway Plus (DH+), PROFIBUS oder PROFINET und vielen anderen. Eine zusätzliche NIC 3168 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 3168 Kommunikationen mit dem Cloud-over-Ethernet bereitstellt und eine zweite NIC 3168 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 durch die Vorrichtung verwendet wird, eine beliebige oder mehrere der Komponenten 3164, 3166, 3168 oder 3170 umfassen oder durch diese umgesetzt sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Senden usw.) durch solch eine Kommunikationsschaltungsanordnung realisiert sein.
  • Der Edge-Computing-Knoten 3150 kann eine Beschleunigungsschaltungsanordnung 3164 umfassen oder mit dieser gekoppelt sein, die durch einen oder mehrere KI-Beschleuniger, einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, einen oder mehrere SoCs (einschließlich programmierbarer SoCs), eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs (einschließlich programmierbarer ASICs), PLDs, wie etwa CPLDs oder HCPLDs, und/oder andere Formen spezialisierter Prozessoren oder Schaltungen umgesetzt ist, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen umfassen.. Bei FPGAbasierten Implementierungen kann die Beschleunigungsschaltungsanordnung 3164 Logikblöcke oder Logikstruktur und andere miteinander verbundene Ressourcen umfassen, die programmiert (konfiguriert) werden können, um verschiedene Funktionen durchzuführen, wie etwa die hierin erörterten Prozeduren, Verfahren, Funktionen usw. Bei solchen Implementierungen kann die Beschleunigungsschaltungsanordnung 3164 auch Speicherzellen (z. B. EPROM, EEPROM, Flash-Speicher, statischer Speicher (z. B. SRAM, Antifuse-Speicher usw.) umfassen, die zum Speichern von Logikblöcken, Logikstruktur, Daten usw. in LUTs und dergleichen verwendet werden.
  • Der IX 3156 koppelt auch den Prozessor 3152 mit einem Sensorhub oder einer externen Schnittstelle 3170, die zum Anschließen zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die zusätzlichen/externen Vorrichtungen können Sensoren 3172, Aktoren 3174 und Positionsbestimmungsschaltungsanordnungen 3175 umfassen.
  • Die Sensorschaltungsanordnung 3172 umfasst Vorrichtungen, Module oder Subsysteme, deren Zweck darin besteht, Ereignisse oder Änderungen in ihrer Umgebung zu detektieren und die Informationen (Sensordaten) über die detektierten Ereignisse an irgendwelche anderen Vorrichtungen, Module, Subsysteme usw. zu senden. Beispiele für solche Sensoren 3172 umfassen unter anderem Trägheitsmesseinheiten (IMU), die Beschleunigungsmesser, Gyroskope und/oder Magnetometer umfassen; mikroelektromechanische Systeme (MEMS) oder nanoelektromechanische Systeme (NEMS), die 3-Achs-Beschleunigungsmesser, 3-Achs-Gyroskope, und/oder Magnetometer umfassen; Füllstandssensoren; Durchflusssensoren; Temperatursensoren (z. B. Thermistoren); Drucksensoren; Luftdrucksensoren; Gravimeter; Höhenmesser; Bilderfassungsvorrichtungen (z. B. Kameras); Lichtdetektions- und Entfernungsmessungssensoren (LiDAR); Näherungssensoren (z. B. Infrarotstrahlungsdetektor und dergleichen); Tiefensensoren, Umgebungslichtsensoren; optische Lichtsensoren; Ultraschall-Sendeempfänger; Mikrofone; und dergleichen.
  • Die Aktuatoren 3174 ermöglichen der Plattform 3150, ihren Zustand, ihre Position und/oder ihre Orientierung zu ändern oder einen Mechanismus oder ein System zu bewegen oder zu steuern. Die Aktuatoren 3174 umfassen elektrische und/oder mechanische Vorrichtungen zum Bewegen oder Steuern eines Mechanismus oder Systems und wandeln Energie (z. B. elektrischen Strom oder sich bewegende Luft und/oder Flüssigkeit) in irgendeine Art von Bewegung um. Die Aktuatoren 3174 können eine oder mehrere elektronische (oder elektrochemische) Vorrichtungen umfassen, wie etwa piezoelektrische Biomorphe, Festkörperaktuatoren, Festkörperrelais (SSRs), Aktuatoren auf der Basis von Formgedächtnislegierungen, Aktuatoren auf der Basis von elektroaktiven Polymeren, integrierte Relaistreiberschaltungen (ICs) und/oder dergleichen. Die Aktuatoren 3174 können eine oder mehrere elektromechanische Vorrichtungen umfassen, wie etwa pneumatische Aktuatoren, hydraulische Aktuatoren, elektromechanische Schalter einschließlich elektromechanischer Relais (EMRs), Motoren (z. B. DC-Motoren, Schrittmotoren, Servomechanismen usw.), Leistungsschalter, Ventilaktuatoren, Räder, Schubdüsen, Propeller, Klauen, Klemmen, Haken, Generatoren hörbaren Schalls, optische Warnvorrichtungen und/oder andere ähnliche elektromechanische Komponenten. Die Plattform 3150 kann dazu konfiguriert sein, einen oder mehrere Aktoren 3174 basierend auf einem oder mehreren erfassten Ereignissen und/oder Anweisungen oder Steuersignalen zu betreiben, die von einem Dienstanbieter und/oder verschiedenen Clientsystemen empfangen werden.
  • Die Positionsbestimmungsschaltungsanordnung 3175 umfasst Schaltungsanordnung zum Empfangen und Decodieren von Signalen, die durch ein Positionsbestimmungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/gesendet werden. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) umfassen das Global Positioning System (GPS) der Vereinigten Staaten, das Global Positioning System (GLONASS) von Russland, das Galileo-System der Europäischen Union, das BeiDou Navigation Satellite System von China, ein regionales Navigationssystem oder GNSS-Erweiterungssystem (z. B. Navigation with Indian Constellation (NAVIC), das Quasi-Zenith Satellite System (QZSS) von Japan, das Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) von Frankreich usw.) oder dergleichen. Die Positionsbestimmungsschaltungsanordnung 3175 umfasst verschiedene Hardwareelemente (darunter z. B. Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen), um mit Komponenten eines Positionsbestimmungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren.. Zusätzlich oder alternativ dazu kann die Positionsbestimmungsschaltungsanordnung 3175 eine Mikrotechnologie zur Positionsbestimmungs-, Navigations- und Timing-IC (Micro-PNT) umfassen, die einen Hauptzeittakt verwendet, um eine Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen. Die Positionsbestimmungsschaltungsanordnung 3175 kann auch Teil der Kommunikationsschaltungsanordnung 3166 sein oder mit dieser interagieren, um mit den Knoten und Komponenten des Positionsbestimmungsnetzwerks zu kommunizieren. Die Positionsbestimmungsschaltungsanordnung 3175 kann auch Positionsdaten und/oder Zeitdaten für die Anwendungsschaltungsanordnung bereitstellen, welche die Daten verwenden kann, um Operationen mit diverser Infrastruktur (z. B. Funkbasisstationen) für Tum-by-Tum-Navigation oder dergleichen zu synchronisieren. Wenn kein GNSS-Signal verfügbar ist oder wenn eine GNSS-Positionsgenauigkeit für eine bestimmte Anwendung oder einen bestimmten Dienst nicht ausreicht, kann eine Positionsbestimmungserweiterungstechnologie verwendet werden, um erweiterte Positionsbestimmungsinformationen und -daten für die Anwendung oder den Dienst bereitzustellen. Solch eine Positionsbestimmungserweiterungstechnologie kann zum Beispiel satellitenbasierte Positionsbestimmungserweiterung (z. B. EGNOS) und/oder bodenbasierte Positionsbestimmungserweiterung (z. B. DGPS) umfassen. Bei einigen Implementierungen ist oder umfasst die Positionierungsschaltungsanordnung 3175 ein INS, das ein System oder eine Vorrichtung ist, das/die eine Sensorschaltungsanordnung 3172 (z. B. Bewegungssensoren, wie etwa Beschleunigungsmesser, Drehsensoren, wie etwa Gyroskope, und Höhenmesser, Magnetsensoren, und/oder dergleichen) verwendet, um ohne Notwendigkeit externer Referenzen kontinuierlich eine Position, Orientierung und/oder Geschwindigkeit (einschließlich Richtung und Geschwindigkeit der Bewegung) des Knotens 850 (z. B. unter Verwendung von Koppelnavigationsverfahren, Triangulation oder dergleichen) zu berechnen.
  • Bei einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe-(E/A-)Vorrichtungen innerhalb des Edge-Computing-Knotens 3150 vorhanden oder mit diesem verbunden sein, die in 31 als Eingabeschaltungsanordnung 3186 und Ausgabeschaltungsanordnung 3184 bezeichnet werden. Die Eingabeschaltungsanordnung 3186 und die Ausgabeschaltungsanordnung 3184 umfassen eine oder mehrere Benutzerschnittstellen, die dazu ausgelegt sind, eine Benutzerinteraktion mit der Plattform 3150 zu ermöglichen, und/oder Peripheriekomponentenschnittstellen, die dazu ausgelegt sind, eine Peripheriekomponenteninteraktion mit der Plattform 3150 zu ermöglichen. Die Eingabeschaltungsanordnung 3186 kann ein beliebiges physisches oder virtuelles Mittel zum Annehmen einer Eingabe umfassen, das unter anderem eine oder mehrere physische oder virtuelle Tasten (z. B. eine Rücksetztaste), eine physische Tastatur, ein Tastenfeld, eine Maus, ein Touchpad, einen Touchscreen, Mikrofone, einen Scanner, ein Headset und/oder dergleichen umfasst. Die Ausgabeschaltungsanordnung 3184 kann enthalten sein, um Informationen zu zeigen oder anderweitig Informationen zu übermitteln, wie etwa Sensorablesungen, Aktuatorposition(en) oder andere ähnliche Informationen. Daten und/oder Grafiken können auf einer oder mehreren Benutzeroberflächenkomponenten der Ausgabeschaltungsanordnung 3184 angezeigt werden. Die Ausgabeschaltungsanordnung 3184 kann eine beliebige Anzahl und/oder Kombinationen von Audio- oder visueller Anzeige umfassen, einschließlich unter anderem einer oder mehrerer einfacher visueller Ausgaben/Indikatoren (z. B. binäre Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigevorrichtungen oder Touchscreens (Flüssigkristallanzeigen (LCD), LED-Anzeigen, Quantenpunktanzeigen, Projektoren usw.) umfassen, wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen anhand des Betriebs der Plattform 3150 erzeugt oder erzeugt wird. Die Ausgabeschaltungsanordnung 3184 kann auch Lautsprecher oder andere Audioemissionsvorrichtungen, Drucker und/oder dergleichen umfassen. Zusätzlich oder alternativ dazu kann die Sensorschaltungsanordnung 3172 als die Eingabeschaltungsanordnung 3184 (z. B. eine Bilderfassungsvorrichtung, Bewegungserfassungsvorrichtung oder dergleichen) verwendet werden und können ein oder mehrere Aktoren 3174 als die Ausgabevorrichtungsschaltungsanordnung 3184 (z. B. ein Aktor zum Bereitstellen einer haptischen Rückmeldung oder dergleichen) verwendet werden. In einem anderen Beispiel kann eine Nahfeldkommunikation-(NFC-)Schaltungsanordnung, die eine NFC-Steuerung umfasst, die mit einem Antennenelement und einer Verarbeitungsvorrichtung gekoppelt ist, enthalten sein, um elektronische Tags zu lesen und/oder eine Verbindung mit einer anderen NFC-fähigen Vorrichtung herzustellen. Peripheriekomponentenschnittstellen können unter anderem einen nichtflüchtigen Speicheranschluss, einen USB-Anschluss, eine Audio-Buchse, eine Stromversorgungsschnittstelle usw. umfassen. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um Ausgaben bereitzustellen und Eingaben eines Edge-Computing-Systems zu empfangen; Komponenten oder Dienste eines Edge-Computing-Systems zu verwalten; einen Zustand einer Edge-Computing-Komponente oder eines Edge-Computing-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Management- oder Verwaltungsfunktionen oder Dienstanwendungsfällen durchzuführen.
  • Eine Batterie 3176 kann den Edge-Computing-Knoten 3150 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Computing-Knoten 3150 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Backup oder für temporäre Fähigkeiten verwendet werden kann. Die Batterie 3176 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
  • Eine Batterieüberwachungsvorrichtung/Ladevorrichtung 3178 kann in dem Edge-Computing-Knoten 3150 enthalten sein, um den Ladezustand (SoCh) der Batterie 3176, falls enthalten, zu verfolgen. Das Batterieüberwachungs-/-ladevorrichtung 3178 kann verwendet werden, um andere Parameter der Batterie 3176 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 3176. Die Batterieüberwachungs-/-ladevorrichtung 3178 kann eine integrierte Batterieüberwachungsschaltung umfassen, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor, Phoenix, Arizona, oder einen IC von der UCD90xxx Familie von Texas Instruments, Dallas, TX. Die Batterieüberwachungs-/- ladevorrichtung 3178 kann die Informationen über die Batterie 3176 über die IX 3156 an den Prozessor 3152 kommunizieren. Die Batterieüberwachungs-/-ladevorrichtung 3178 kann auch einen Analog-Digital-Wandler (ADC-Wandler) umfassen, der es dem Prozessor 3152 ermöglicht, die Spannung der Batterie 3176 oder den Stromfluss aus der Batterie 3176 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Computing-Knoten 3150 ausführen kann, wie etwa Übertragungsfrequenz, Maschennetzoperation, Erfassungsfrequenz und dergleichen.
  • Ein Leistungsblock 3180 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit der Batterieüberwachungs-/-ladevorrichtung 3178 gekoppelt sein, um die Batterie 3176 zu laden. Bei einigen Beispielen kann der Leistungsblock 3180 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel über eine Schleifenantenne im Edge-Computing-Knoten 3150, zu erhalten. Ein Drahtlosbatterieladeschaltschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in der Batterieüberwachungs-/-ladevorrichtung 3178 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 3176 und somit dem erforderlichen Strom ausgewählt werden. Das Aufladen kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
  • Der Datenspeicher 3158 kann Anweisungen 3182 in der Form von Software, Firmware oder Hardwarebefehlen zum Implementieren der hier beschriebenen Techniken umfassen. Obwohl solche Anweisungen 3182 als Codeblöcke gezeigt sind, die in dem Speicher 3154 und der Speicherung 3158 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC - Application Specific Integrated Circuit) eingebaut sind.
  • In einem Beispiel können die Anweisungen 3182, die über den Arbeitsspeicher 3154, den Datenspeicher 3158 oder den Prozessor 3152 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 3160 umgesetzt sein, das Code umfasst, um den Prozessor 3152 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten 3150 durchzuführen. Der Prozessor 3152 kann über den IX 3156 auf das nichtflüchtige maschinenlesbare Medium 3160 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 3160 durch Vorrichtungen umgesetzt sein, die für den Datenspeicher 3158 beschrieben sind, oder kann spezifische Speichereinheiten umfassen, wie etwa Speichervorrichtungen und/oder Speicherplatten, die optische Platten (z. B. DVD (Digital Versatile Disk), CD (Compact Disk), CD-ROM, Blu-Ray-Disk), Flash-Laufwerke, Floppy-Disks, Festplatten (z. B. SSDs) oder eine beliebige Anzahl anderer Hardware-Vorrichtungen, in denen Informationen für eine beliebige Dauer (z. B. für längere Zeiträume, dauerhaft, für kurze Momente, zum temporären Puffern und/oder Caching) gespeichert werden. Das nichtflüchtige, maschinenlesbare Medium 3160 kann Anweisungen umfassen, um den Prozessor 3152 anzuweisen, eine spezifische Folge oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ sind austauschbar. Der Begriff „nichtflüchtiges computerlesbares Medium“ ist ausdrücklich so definiert, dass er eine beliebige Art von computerlesbarer Speicherungsvorrichtung und/oder Speicherplatte umfasst und sich ausbreitende Signale ausschließt und Übertragungsmedien ausschließt.
  • In weiteren Beispielen umfasst ein maschinenlesbares Medium auch jedes dingliche Medium, das zum Speichern, Codieren oder Tragen 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 Tragen von Datenstrukturen imstande ist, die von solchen Anweisungen genutzt werden oder damit assoziiert sind. Ein „maschinenlesbares Medium“ kann somit Festkörperspeicher und optische und magnetische Medien umfassen, ist jedoch nicht darauf beschränkt. Spezifische Beispiele für maschinenlesbare Medien umfassen nichtflüchtigen Speicher, wie zum Beispiel Halbleiterspeichervorrichtungen (z. B. elektrisch programmierbaren Nur-Lese-Speicher (EPROM - Electrically Programmable Read-Only Memory), elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM - Electrically Erasable Programmable Read-Only Memory) und Flash-Speichervorrichtungen, Magnetplatten, wie zum Beispiel interne Festplatten und Wechselplatten, magnetooptische Platten und CD-ROM- und DVD-ROM-Disks, ohne jedoch darauf beschränkt zu sein. Die Anweisungen, die durch ein maschinenlesbares Medium verkörpert sind, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z. B. HTTP) nutzt.
  • Ein maschinenlesbares Medium kann durch eine Speicherungsvorrichtung oder eine andere Einrichtung bereitgestellt werden, die dazu in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Bei einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen die Anweisungen repräsentieren, wie etwa die 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 umfassen. Die die Anweisungen darstellenden Informationen im maschinenlesbaren Medium können durch eine Verarbeitungsschaltungsanordnung in die Anweisungen zum Implementieren beliebiger der hierin erörterten Operationen verarbeitet werden. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z. B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes umfassen: Kompilieren (z. B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Verarbeiten der Informationen in die Anweisungen.
  • In einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z. B. durch die Verarbeitungsschaltungsanordnung) umfassen, um die Anweisungen aus einem Zwischenformat oder vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Wenn die Informationen in mehreren Teilen bereitgestellt werden, können sie kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarer Binär-Code usw.) auf einem oder mehreren Fernservern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk übertragen werden, und können an einer lokalen Maschine falls notwendig entschlüsselt, dekomprimiert, zusammengesetzt (z. B. verknüpft) und kompiliert oder interpretiert (z. B. in eine Bibliothek, selbständige ausführbare Datei usw.) werden und durch die lokale Maschine ausgeführt werden.
  • Die Darstellungen von 30 und 31 sollen eine Ansicht auf hoher Ebene von Komponenten einer unterschiedlichen Vorrichtung, eines urschiedlichen Subsystems oder einer unterschiedlichen Anordnung eines Edge-Computing-Knotens veranschaulichen. Es versteht sich jedoch, dass einige der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können und in anderen Implementierungen eine andere Anordnung der gezeigten Komponenten auftreten kann. Ferner sind diese Anordnungen in einer Vielzahl von Anwendungsfällen und Umgebungen verwendbar, einschließlich jener, die unten erörtert werden (z. B. ein mobiles UE Industrial Compute für intelligente Städte oder intelligente Fabriken, unter vielen anderen Beispielen).
  • Die jeweiligen Rechenplattformen der 30 und 31 können mehrere Edge-Instanzen (z. B. Edge-Cluster) durch Verwenden von Mandanten-Containern unterstützen, die auf einer einzigen Rechenplattform ausgeführt werden. Gleichermaßen können mehrere Edge-Knoten als Unterknoten existieren, die auf Mandanten innerhalb derselben Rechenplattform ausgeführt werden. Dementsprechend kann basierend auf verfügbarer Ressourcenpartitionierung ein einzelnes System oder eine einzelne Rechenplattform in mehrere unterstützende Mandanten- und Edge-Knoteninstanzen partitioniert oder unterteilt werden, von denen jede mehrere Dienste und Funktionen unterstützen kann - selbst während sie potenziell in mehreren Rechenplattforminstanzen durch mehrere Besitzer betrieben oder gesteuert wird. Diese verschiedenen Arten von Partitionen können komplexe Multi-Mandanten und viele Kombinationen von Multi-Stakeholdern durch die Verwendung eines LSM oder einer anderen Implementierung einer Isolations-/Sicherheitsrichtlinie unterstützen. Hinweise auf die Verwendung eines LSM und Sicherheitsmerkmale, die solche Sicherheitsmerkmale verbessern oder implementieren, werden daher in den folgenden Abschnitten erwähnt. Gleichermaßen können Dienste und Funktionen, die auf diesen verschiedenen Typen von Mehrentitätspartitionen arbeiten, lastausgeglichen, migriert und orchestriert werden, um notwendige Dienstziele und Operationen zu erreichen.
  • Die 30 und 31 stellen Beispiele für Edge-Computing-Systeme und -Umgebungen dar, die beliebige der hier erörterten Rechenknoten oder Vorrichtungen verwirklichen können. Jeweilige Edge-Rechenknoten können 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. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen, umgesetzt sein.
  • 4. IMPLEMENTIERUNGSBEISPIELE
  • Zusätzliche Beispiele für die vorliegend beschriebenen Systeme, Vorrichtungen und Verfahren umfassen die folgenden, nicht einschränkenden Implementierungsbeispiele. Jedes der folgenden nicht einschränkenden Beispiele kann für sich allein stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen Beispiele, die unten oder in der gesamten vorliegenden Offenbarung bereitgestellt werden, kombiniert werden.
  • Beispiel 1 umfasst ein Verfahren zum Betreiben eines ersten Mehrfachzugangsrechenknotens zum Verwalten von Verkehr für Mehrfachzugangskommunikation in einer Mehrfachzugangskommunikationsumgebung, wobei das Verfahren umfasst: Bestimmen eines Pro-Paket-Priorisierungs-(PPP-)Wertes für eine Dateneinheit basierend auf einer oder mehreren konfigurierten PPP-Regeln; Erzeugen der Dateneinheit, die den bestimmten PPP-Wert umfasst; und Übertragen der erzeugten Dateneinheit an einen zweiten Mehrfachzugangsrechenknoten.
  • Beispiel 2 umfasst das Verfahren nach Beispiel 1 und/oder nach einem oder mehreren anderen Beispielen hierin, wobei die eine oder die mehreren konfigurierten PPP-Regeln in einer PPP-Konfiguration definiert sind.
  • Beispiel 3 umfasst das Verfahren nach Beispiel 2 und/oder einem oder mehreren anderen Beispielen hierin, wobei die eine oder mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einer Dateneinheitsgröße basiert, und das Bestimmen des PPP-Wertes umfasst: Bestimmen einer Größe der Dateneinheit; und Bestimmen, aus der PPP-Konfiguration, des PPP-Wertes, der einem Dateneinheitsgrößenbereich entspricht, der die bestimmte Größe der Dateneinheit umfasst.
  • Beispiel 4 umfasst das Verfahren nach Beispiel 2-3 und/oder einem oder mehreren anderen Beispielen hierin, wobei die eine oder mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einem Dateneinheitsgrößencode basiert, und das Bestimmen des PPP-Wertes umfasst: Bestimmen des PPP-Wertes unter Verwendung eines Codierungsschemas, das in der PPP-Konfiguration definiert ist.
  • Beispiel 5 umfasst das Verfahren nach Beispiel 4 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Codierungsschema eine Modulo-Operation ist, und das Bestimmen des PPP-Wertes ferner umfasst: Bestimmen einer Größe der Dateneinheit; und Bestimmen des PPP-Wertes als einen Modul von S Modulo K, wobei S die Größe der Dateneinheit ist und K eine Anzahl von Prioritätsstufen ist, die durch die PPP-Konfiguration angegeben ist.
  • Beispiel 6 umfasst das Verfahren nach Beispiel 2 bis 5 und/oder einem oder mehreren anderen Beispielen hierin, wobei die eine oder mehreren PPP-Regeln eine PPP-Regel umfasst, die auf einem generischen Nutzlasttyp (GPT) basiert, und das Bestimmen des PPP-Wertes umfasst: Bestimmen eines Satzes von GPP-Parametern; und Bestimmen des PPP-Wertes, der dem bestimmten Satz von GPP-Parametern entspricht, aus der PPP-Konfiguration.
  • Beispiel 7 umfasst das Verfahren nach Beispiel 6 und/oder einem oder mehreren anderen Beispielen hierin, wobei der Satz von GPT-Parametern einen GPT-Offset, eine GPT-Länge und einen GPT-Wert umfasst.
  • Beispiel 8 umfasst das Verfahren nach Beispiel 2-7 und/oder einem oder mehreren anderen Beispielen hierin, wobei die eine oder mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einer Flussrate basiert, und das Bestimmen des PPP-Wertes umfasst: Bestimmen einer Flussrate für die Dateneinheit; und Bestimmen, aus einer PPP-Konfiguration, des PPP-Wertes, der einem Flussratenbereich entspricht, der die bestimmte Flussrate umfasst.
  • Beispiel 9 umfasst das Verfahren nach Beispiel 2-8 und/oder einem oder mehreren anderen Beispielen hierin, wobei die PPP-Konfiguration ferner einen oder mehrere Flussklassifizierungsparameter, die verwendet werden sollen, um einen Fluss zu identifizieren, für den die eine oder mehreren PPP-Regeln anwendbar sind, und eine Anzahl von Prioritätsstufen umfasst.
  • Beispiel 10 umfasst das Verfahren nach Beispiel 1-9 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Senden einer ersten Steuernachricht an den zweiten Mehrfachzugangsrechenknoten, wobei die erste Steuernachricht Unterstützung einer PPP-Fähigkeit durch den ersten Mehrfachzugangsrechenknoten angibt; und Empfangen einer zweiten Steuernachricht vom zweiten Mehrfachzugangsrechenknoten.
  • Beispiel 11 umfasst das Verfahren nach Beispiel 10 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Erzeugen der Dateneinheit, sodass sie den PPP-Wert umfasst, wenn die zweite Steuernachricht Unterstützung der PPP-Fähigkeit durch den zweiten Mehrfachzugangsrechenknoten angibt.
  • Beispiel 12 umfasst das Verfahren nach Beispiel 1-11 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Empfangen einer oder mehrerer anderer Dateneinheiten, die jeweilige PPP-Werte umfassen.
  • Beispiel 13 umfasst das Verfahren nach Beispiel 1-12 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Übertragen der erzeugten Dateneinheit umfasst: Einreihen der Dateneinheit in eine Warteschlange; und Entfernen der Dateneinheit aus der Warteschlange zur Übertragung an den zweiten Mehrfachzugangsrechenknoten.
  • Beispiel 14 umfasst das Verfahren nach Beispiel 12-13 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Detektieren einer Verkehrsüberlastungsbedingung, und Durchführen einer PPP-basierten aktiven Warteschlangenverwaltung (AQM) in Reaktion auf das Detektieren der Verkehrsüberlastungsbedingung.
  • Beispiel 15 umfasst das Verfahren nach Beispiel 6-14 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Erzeugen der Dateneinheit ferner umfasst: Erzeugen der Dateneinheit, sodass sie ein GPP-Feld umfasst; und Einfügen des PPP-Wertes in das GPP-Feld.
  • Beispiel 16 umfasst das Verfahren nach Beispiel 15 und/oder eines oder mehrerer anderer Beispiele hierin, wobei das Erzeugen der Dateneinheit ferner umfasst: Erzeugen des GPT-Feldes innerhalb eines Nutzlastabschnitts der Dateneinheit gemäß einem GPT-Offset und einer GPT-Länge, wobei: der GPT-Offset eine Anzahl von Bits oder Bytes von einem Ende eines Header-Abschnitts der Dateneinheit bis zu einem Anfang des GPT-Feldes ist, und die GPT-Länge eine Anzahl von Bits oder Bytes des GPT-Feldes ist.
  • Beispiel 17 umfasst das Verfahren nach Beispiel 16 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Erzeugen der Dateneinheit ferner umfasst: Erzeugen des GPT-Feldes innerhalb der Dateneinheit ferner gemäß einer GPT-Dienstqualitäts-(QoS-)Klassenzuordnung, wobei die GPT-QoS-Klassenzuordnung eine Anzahl von QoS-Klassen und für jede QoS-Klasse der Anzahl von QoS-Klassen einen QoS-Klassenwert und einen GPT-Wertebereich anzeigt.
  • Beispiel 18 umfasst das Verfahren nach Beispiel 17 und/oder einem oder mehreren anderen Beispielen hierin, wobei der PPP-Wert ein QoS-Klassenwert ist, der einer QoS-Klasse der Anzahl von QoS-Klassen entspricht.
  • Beispiel 19 umfasst das Verfahren nach Beispiel 17-18, ferner umfassend: Identifizieren, aus einer GPT-Intraflussklassifizierungskonfiguration, des GPT-Offsets, der GPT-Länge, der GPT-QoS-Klassenzuordnung und von Intraflussklassifizierungsinformationen, wobei die Intraflussklassifizierungsinformationen Informationen umfassen, die zum Identifizieren von Teilflüssen verwendet werden, die einen Fluss bilden.
  • Beispiel 20 umfasst das Verfahren nach Beispiel 19 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Erhalten der GPT-Intraflussklassifizierungskonfiguration von einer Anwendung in einer Anwendungsschicht über eine Intraflussklassifizierungs-Anwendungsprogrammschnittstelle (API).
  • Beispiel 21 umfasst das Verfahren nach 14-20 und/oder einem oder mehreren anderen Beispielen hierin, wobei die GPT-Intraflussklassifizierungskonfiguration ferner eine Pro-Paket-Verzögerungsgrenze umfasst, und wobei die Pro-Paket-Verzögerungsgrenze auf einen Wert gesetzt wird, der einer QoS-Anforderung eines Verkehrsstroms entspricht, zu dem die Dateneinheit gehört.
  • Beispiel 22 umfasst das Verfahren nach Beispiel 21 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Durchführen von PPP-basierter AQM in Reaktion auf das Detektieren der Verkehrsüberlastungsbedingung umfasst: Verwerfen, wenn die Verkehrsüberlastungsbedingung detektiert wird, der Dateneinheit, wenn der PPP-Wert anzeigt, dass die Dateneinheit eine niedrigere Priorität als andere Dateneinheiten in einer Warteschlange aufweist; und Senden der erzeugten Dateneinheit an den zweiten Mehrfachzugangsrechenknoten, wenn die Dateneinheit nicht verworfen wird.
  • Beispiel 23 umfasst das Verfahren nach Beispiel 22 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Durchführen PPP-basierter AQM in Reaktion auf das Detektieren der Verkehrsüberlastungsbedingung umfasst: Verwerfen von Dateneinheiten, die die Pro-Paket-Verzögerungsgrenze verletzen.
  • Beispiel 24 umfasst das Verfahren nach Beispiel 22-23 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Verwerfen der Dateneinheit umfasst: Verwerfen der Dateneinheit, wenn eine aktuelle Warteschlangengröße der Warteschlange größer als eine gewichtete Warteschlangengröße ist, wobei die gewichtete Warteschlangengröße auf einer Gewichtung, die auf den PPP-Wert angewendet wird, und einer vordefinierten oder konfigurierten Warteschlangengrößengrenze basiert.
  • Beispiel 25 umfasst das Verfahren nach Beispiel 22-23 und/oder einigen anderen Beispielen hierin, wobei das Verwerfen der Dateneinheit umfasst: Verwerfen der Dateneinheit, wenn eine aktuelle Warteschlangenverzögerung der Dateneinheit größer als eine gewichtete Warteschlangenverzögerung ist, wobei die gewichtete Warteschlangenverzögerung auf einer Gewichtung basiert, die auf den PPP-Wert und die Pro-Paket-Verzögerungsgrenze angewendet wird.
  • Beispiel 26 umfasst das Verfahren nach Beispiel 22-23 und/oder einigen anderen Beispielen hierin, wobei das Verwerfen der Dateneinheit umfasst: Verwerfen der Dateneinheit und einer Anzahl von eingereihten Dateneinheiten mit demselben PPP-Wert wie die Dateneinheit, wenn die Anzahl von eingereihten Dateneinheiten mit demselben PPP-Wert wie die Dateneinheit größer oder gleich einem Verwerfungsparameter ist.
  • Beispiel 27 umfasst das Verfahren nach Beispiel 10-26 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Mehrfachzugangskommunikationsumgebung eine Mehrfachzugangsverwaltungsdienst-(MAMS-)Kommunikationsumgebung ist und die MAMS-Kommunikationsumgebung ein Mehrfachzugangsverwaltungsdienst-(MAMS-)Framework umfasst.
  • Beispiel 28 umfasst das Verfahren nach Beispiel 27 und/oder einem oder mehreren anderen Beispielen hierin, wobei der erste Mehrfachzugangs-(MX-)Rechenknoten eine Client-Vorrichtung ist, der zweite MX-Rechenknoten ein Server ist, die erste Steuernachricht eine MX-Fähigkeitsanforderungsnachricht (mx_ capability _req) ist, und die zweite Steuernachricht eine MX-Fähigkeitsantwortnachricht (mx_capability_rsp) ist.
  • Beispiel 29 umfasst das Verfahren nach Beispiel 28 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Empfangen einer MX-PPP-Konfigurationsanforderungsnachricht (mx_ppp_config_req), wenn mx_capability_rsp Unterstützung der PPP-Fähigkeit angibt, wobei mx_ppp_config_req die PPP-Konfiguration umfasst.
  • Beispiel 30 umfasst das Verfahren nach Beispiel 27 und/oder einem oder mehreren anderen Beispielen hierin, wobei der erste MX-Rechenknoten ein Server ist, der zweite MX-Rechenknoten eine Client-Vorrichtung ist, die erste Steuernachricht eine mx_capability_rsp ist, und die zweite Steuernachricht eine mx_capability _req ist.
  • Beispiel 31 umfasst das Verfahren nach Beispiel 30 und/oder einem oder mehreren anderen Beispielen hierin, ferner umfassend: Empfangen einer MX-PPP-Konfigurationsantwortnachricht (mx_ppp_config_rsp), wenn mx_capability_req Unterstützung der PPP-Fähigkeit angibt, wobei mx_ppp_config_rsp die PPP-Konfiguration umfasst.
  • Beispiel 32 umfasst das Verfahren nach Beispiel 27-31 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Verfahren durch eine Konvergenzschicht durchgeführt wird, die durch den ersten Mehrfachzugangsrechenknoten betrieben wird.
  • Beispiel 33 umfasst das Verfahren nach Beispiel 32 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Konvergenzschicht ein Mehrfachzugangs-(MX-)Konvergenzschichtteil eines MAMS-Protokollstapels ist.
  • Beispiel 34 umfasst das Verfahren nach Beispiel 33 und/oder einem oder mehreren anderen Beispielen hierin, wobei die MX-Konvergenzschicht ein MX-Konvergenzverfahren implementiert, wobei das MX-Konvergenzverfahren eines von einem generischen Mehrfachzugang (GMA - Generic Multi-Access), einem MultiPath-Transmission-Control-Protocol-(MPTCP-)Proxy, Generic-Routing-Encapsulation-(GRE-)Aggregationsproxy oder MultiPath QUIC (MPQUIC) umfasst.
  • Beispiel 35 umfasst das Verfahren nach Beispiel 33-34 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Intraflussklassifizierungs-API eine Schnittstelle zwischen einer Anwendungsschicht und der MX-Konvergenzschicht ist.
  • Beispiel 36 umfasst das Verfahren nach Beispiel 33-35 und/oder einem oder mehreren anderen Beispielen hierin, wobei die MX-Konvergenzschicht eine GMA-Entität implementiert, wenn das MX-Konvergenzverfahren das GMA-Konvergenzverfahren ist.
  • Beispiel 37 umfasst das Verfahren nach Beispiel 36 und/oder einem oder mehreren anderen Beispielen hierin, wobei der erste MX-Rechenknoten eine Client-Vorrichtung ist, die GMA-Entität eine GMA-Client-(Gc-)Entität ist, und der zweite MX-Rechenknoten ein Server ist.
  • Beispiel 38 umfasst das Verfahren nach Beispiel 37 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Client-Vorrichtung ferner einen Client-Verbindungsmanager (CCM) umfasst, der kommunikativ mit der Gc-Entität gekoppelt ist.
  • Beispiel 39 umfasst das Verfahren nach Beispiel 36 und/oder einem oder mehreren anderen Beispielen hierin, wobei der erste MX-Rechenknoten ein Server ist, die GMA-Entität eine GMA-Server-(Gs-)Entität ist und der zweite MX-Rechenknoten ein Server ist.
  • Beispiel 40 umfasst das Verfahren nach Beispiel 39 und/oder einem oder mehreren anderen Beispielen hierin, wobei der Server ferner einen Netzwerkverbindungsmanager (NCM) umfasst, der kommunikativ mit der Gc-Entität gekoppelt ist.
  • Beispiel 41 umfasst das Verfahren nach Beispiel 28-40 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Client-Vorrichtung ein Desktop-Computer, eine Workstation, ein Smartphone, ein Tablet-Computer, eine am Körper tragbare Vorrichtung, eine IoT-Vorrichtung (IoT - Internet of Things) oder ein intelligentes Gerät ist.
  • Beispiel 42 umfasst das Verfahren nach Beispiel 28-40 und/oder einem oder mehreren anderen Beispielen hierin, wobei der Server eine Gateway-Vorrichtung, ein Funkzugangsnetzwerkknoten, ein Netzwerkgerät, eine Netzwerkfunktion innerhalb eines Kernnetzwerks, ein Anwendungsserver, ein Edge-Server eines Edge-Computing-Netzwerks oder ein Server eines Cloud-Computing-Dienstes ist.
  • Beispiel 43 umfasst das Verfahren nach Beispiel 27-42 und/oder einem oder mehreren anderen Beispielen hierin, wobei die Dateneinheit ein Datenpaket ist.
  • Beispiel 44 umfasst das Verfahren nach Beispiel 43 und/oder einem oder mehreren anderen Beispielen hierin, wobei das Datenpaket eine Generic-Multi-Access-(GMA-)Protokolldateneinheit (PDU) ist, die einen GMA-Header oder einen GMA-Trailer umfasst.
  • Beispiel 45 umfasst das Verfahren nach Beispiel 43-44 und/oder einem oder mehreren anderen Beispielen hierin, wobei das GPT-Feld in einem Nutzlastabschnitt des Datenpakets enthalten ist.
  • Beispiel Z01 umfasst ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei die Ausführung der Anweisungen durch eine Prozessorschaltungsanordnung die Prozessorschaltungsanordnung zum Durchführen des Verfahrens nach Beispiel 1-45 und/oder einem oder mehreren anderen Beispielen hierin veranlasst.
  • Beispiel Z02 umfasst ein Computerprogramm, das die Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin umfasst.
  • Beispiel Z03 umfasst eine Anwendungsprogrammschnittstelle, die Funktionen, Verfahren, Variablen, Datenstrukturen und/oder Protokolle für das Computerprogramm nach Beispiel Z02 und/oder einem oder mehreren anderen Beispielen hierin definiert.
  • Beispiel Z04 umfasst eine Einrichtung, die eine Schaltungsanordnung umfasst, die mit den Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin geladen ist.
  • Beispiel Z05 umfasst eine Einrichtung, die eine Schaltungsanordnung umfasst, die dazu betreibbar ist, die Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin auszuführen.
  • Beispiel Z06 umfasst eine integrierte Schaltung, die eine oder mehrere der Prozessorschaltungsanordnung nach Beispiel Z01 und/oder des einen oder der mehreren computerlesbaren Medien nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin umfasst.
  • Beispiel Z07 umfasst ein Rechensystem, das das eine oder die mehreren computerlesbaren Medien und die Prozessorschaltungsanordnung nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin umfasst.
  • Beispiel Z08 umfasst eine Einrichtung, die Mittel zum Ausführen der Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin umfasst.
  • Beispiel Z09 umfasst ein Signal, das als Ergebnis des Ausführens der Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin erzeugt wird.
  • Beispiel Z10 umfasst eine Dateneinheit, die als Ergebnis des Ausführens der Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin erzeugt wird.
  • Beispiel Z11 umfasst die Dateneinheit nach Beispiel Z10 und/oder einem oder mehreren anderen Beispiele hierin, wobei die Dateneinheit ein Datagramm, ein Netzwerkpaket, ein Datenrahmen, ein Datensegment, eine PDU, eine Dienstdateneinheit (SDU), eine Nachricht oder ein Datenbankobj ekt ist.
  • Beispiel Z12 umfasst Signal, das mit der Dateneinheit nach Beispiel Z10-Z11 und/oder einem oder mehreren anderen Beispielen hierin codiert ist.
  • Beispiel Z13 umfasst ein elektromagnetisches Signal, das die Anweisungen nach Beispiel Z01 und/oder einem oder mehreren anderen Beispielen hierin trägt.
  • Beispiel Z14 umfasst eine Einrichtung, die Mittel zum Durchführen des Verfahrens nach Beispiel 1-45 und/oder einem oder mehreren anderen Beispielen hierin umfasst.
  • 5. TERMINOLOGIE
  • So wie sie hierin verwendet werden, sollen die Singularformen „ein“, „eine“ und „der/die/das“ auch Pluralformen umfassen, es sei denn, dass der Zusammenhang eindeutig etwas anderes angibt. Es versteht sich ferner, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn in dieser Patentschrift verwendet, das Vorhandensein aufgeführter Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten spezifiziert, aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon ausschließt. Der Ausdruck „A und/oder B“ bedeutet (A), (B) oder (A und B). Für die Zwecke der vorliegenden Offenbarung bedeutet der Ausdruck „A, B und/oder C“ (A), (B), (C), (A und B), (A und C), (B und C) oder (A, B und C). Die Beschreibung verwendet möglicherweise die Ausdrücke „in/bei einer Ausführungsform“ oder „in/bei einigen Ausführungsformen“, die sich jeweils auf eine oder mehrere derselben oder verschiedene Ausführungsformen beziehen können. Außerdem sind die Begriffe „umfassend“, „enthaltend“, „aufweisend“ und dergleichen, wie sie mit Bezug auf Ausführungsformen der vorliegenden Offenbarung verwendet werden, synonym.
  • Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“ gemeinsam mit Ableitungen davon werden hierin verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass sich zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander befinden, er kann bedeuten, dass zwei oder mehr Elemente indirekt miteinander in Kontakt stehen, aber immer noch miteinander zusammenwirken oder interagieren, und/oder er kann bedeuten, dass ein oder mehrere andere Elemente zwischen die Elemente gekoppelt oder geschaltet sind, die als miteinander gekoppelt bezeichnet werden.. Der Begriff „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt miteinander stehen. Der Begriff „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente durch ein Kommunikationsmittel, unter anderem durch einen Draht oder eine andere Zwischenverbindung, durch einen Drahtloskommunikationskanal oder eine Drahtloskommunikationstinte und/oder dergleichen miteinander in Kontakt stehen können.
  • Der Begriff „Schaltungsanordnung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Schaltung oder ein System mehrerer Schaltungen, die bzw. das dazu konfiguriert ist, eine spezielle Funktion in einer elektronischen Vorrichtung durchzuführen. Die Schaltung oder das System von Schaltungen kann Teil einer oder mehrerer Hardwarekomponenten sein oder diese umfassen, wie etwa eine Logikschaltung, ein Prozessor (gemeinsam genutzt, dediziert oder Gruppe) und/oder ein Speicher (gemeinsam genutzt, dediziert oder als Gruppe), eine ASIC, ein FPGA, eine programmierbare Logiksteuerung (PLC), ein SoC, ein SiP, ein Mehrchipgehäuse (MCP), einen DSP usw., die dazu konfiguriert sind, die beschriebene Funktionalität bereitzustellen Außerdem kann sich der Begriff „Schaltungsanordnung“ auch auf eine Kombination eines oder mehrerer Hardwareelemente mit dem Programmcode beziehen, der zum Ausführen der Funktionalität dieses Programmcodes verwendet wird. Einige Arten von Schaltungen können ein oder mehrere Software- oder Firmware-Programme ausführen, um wenigstens einen Teil der beschriebenen Funktionalität bereitzustellen. Solch eine Kombination von Hardwareelementen und Programmcode kann als ein bestimmter Schaltungstyp bezeichnet werden.
  • Es versteht sich, dass die in dieser Schrift beschriebenen funktionalen Einheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um insbesondere ihre Implementierungsunabhängigkeit hervorzuheben. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen verkörpert werden. Beispielsweise kann eine Komponente oder ein Modul als Hardware-Schaltung implementiert werden, die angepasste Very-Large-Scale-Integration-(VLSI-)Schaltungen oder Gate-Arrays, handelsübliche Halbleiter, wie etwa Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert werden, wie beispielsweise feldprogrammierbare Gatterarrays, programmierbare Arraylogik, programmierbare Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert werden. Eine identifizierte Komponente oder ein identifiziertes Modul aus ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Elemente einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen lokalisiert sein, sondern können ungleiche Anweisungen umfassen, die an verschiedenen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden sind, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erfüllen.
  • Tatsächlich kann eine Komponente oder ein Modul eines ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und sogar kann über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über einige Speichervorrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie etwa Codeumschreibung und Codeanalyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Datenzentrum) stattfinden als auf jenem, in dem der Code bereitgestellt wird (z. B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Auf ähnliche Weise können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und dargestellt werden und können in einer beliebigen geeigneten Form ausgeführt und in einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als einziger Datensatz gesammelt werden oder können über verschiedene Orte, einschließlich über verschiedene Speicherungsvorrichtungen, verteilt werden und können zumindest teilweise lediglich als elektronische Signale in einem System oder Netz existieren. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die dazu betreibbar sind, gewünschte Funktionen auszuführen.
  • Der Begriff „Prozessorschaltungsanordnung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Schaltungsanordnung, die zum sequenziellen und automatischen Ausführen einer Folge arithmetischer oder logischer Operationen oder Aufzeichnen, Speichern und/oder Übertragen digitaler Daten in der Lage ist, ist Teil davon oder umfasst eine solche. Der Begriff „Prozessorschaltungsanordnung“ bezieht sich zumindest in einigen Ausführungsformen auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische CPU, einen Einkernprozessor, einen Doppelkernprozessor, einen Dreikernprozessor, einen Vierkernprozessor und/oder jede andere Vorrichtung, die in der Lage ist, computerausführbare Anweisungen, wie etwa Programmcode, Softwaremodule und/oder Funktionsprozesse, auszuführen oder anderweitig zu betreiben. Die Begriffe „Anwendungsschaltungsanordnung“ und/oder „Basisbandschaltungsanordnung“ können als Synonyme für „Prozessorschaltungsanordnung“ angesehen und so bezeichnet werden.
  • Der Begriff „Speicher“ und/oder „Speicherschaltungsanordnung“ bezieht sich zumindest in einigen Ausführungsformen auf eine oder mehrere Hardwarevorrichtungen zum Speichern von Daten, einschließlich RAM, MRAM, PRAM, DRAM und/oder SDRAM, Kernspeicher, ROM, Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen oder andere maschinenlesbare Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann unter anderem Speicher, tragbare oder feste Speichervorrichtungen, optische Speichervorrichtungen und verschiedene andere Medien umfassen, die zum Speichern, Enthalten oder Tragen von Anweisungen in der Lage sind.
  • Der Begriff „Schnittstellenschaltungsanordnung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Schaltungsanordnung, die den Austausch von Informationen zwischen zwei oder mehr Komponenten oder Vorrichtungen ermöglicht, ist Teil davon oder umfasst eine solche. Der Begriff „Schnittstellenschaltungsanordnung“ bezieht sich zumindest in einigen Ausführungsformen auf eine oder mehrere Hardwareschnittstellen, zum Beispiel Busse, E/A-Schnittstellen, Peripheriekomponentenschnittstellen, Netzwerkschnittstellenkarten und/oder dergleichen.
  • Der Begriff „Element“ bezieht sich zumindest in einigen Ausführungsformen auf eine Einheit, die bei einem gegebenen Abstraktionsniveau unteilbar ist und eine klar definierte Grenze aufweist, wobei ein Element eine beliebige Art von Entität sein kann, die zum Beispiel eine oder mehrere Vorrichtungen, Systeme, Steuerungen, Netzwerkelemente, Module usw. oder Kombinationen davon umfasst. Der Begriff „Vorrichtung“ bezieht sich auf eine physische Entität, die innerhalb einer anderen physischen Entität in ihrer Nähe eingebettet oder an dieser angebracht ist, mit Fähigkeiten zum Übermitteln von digitalen Informationen von oder zu dieser physischen Entität. Der Begriff „Entität“ bezieht sich zumindest in einigen Ausführungsformen auf eine individuelle Komponente einer Architektur oder Vorrichtung oder als Nutzlast übertragene Informationen. Der Begriff „Steuerung“ bezieht sich zumindest in einigen Ausführungsformen auf ein Element oder eine Entität, das/die die Fähigkeit aufweist, eine physische Entität zu beeinflussen, wie etwa durch Ändern ihres Zustands oder Veranlassen der physischen Entität, sich zu bewegen.
  • Der Begriff „Edge Computing“ viele Implementierungen verteilter Berechnung, die in einem Bestreben, die Latenz zu reduzieren und den Durchsatz für Endpunktbenutzer (Client-Vorrichtungen, Benutzergeräte usw.) zu erhöhen, Verarbeitungsaktivitäten und -ressourcen (z. B. Rechen-, Speicher- Beschleunigungsressourcen) an die „Edge“ (den Rand) des Netzwerks bewegen. Solche Edge-Computing-Implementierungen umfassen typischerweise das Anbieten solcher Aktivitäten und Ressourcen in Cloud-ähnlichen Diensten, Funktionen, Anwendungen und Subsystemen von einem oder mehreren Orten, auf die über drahtlose Netzwerke zugegriffen werden kann. Somit sind die Verweise auf eine „Edge“ (einen Rand) eines Netzwerks, Clusters, einer Domäne, eines Systems oder einer Rechenanordnung, die hierin verwendet werden, Gruppen oder Gruppierungen funktioneller verteilter Rechenelemente und stehen daher im Allgemeinen nicht mit Kanten („Edges“) (Links oder Verbindungen) in Beziehung, wie sie in der Graphentheorie verwendet werden. Spezifische Anordnungen von Edge-Computing-Anwendungen und -Diensten, die über Mobilfunknetzwerke (z. B. zellulare und WiFi-Datennetzwerke) zugänglich sind, können als „Mobile Edge Computing“ oder „Multi-Access Edge Computing“ bezeichnet werden, worauf mit dem Akronym „MEC“ Bezug genommen werden kann. Die Verwendung von „MEC“ hierin kann sich auch auf eine standardisierte Implementierung beziehen, die vom European Telecommunications Standards Institute (ETSI) veröffentlicht und als „ETSI-MEC“ bezeichnet wird. Die in der ETSI-MEC-Spezifikation verwendete Terminologie wird hierin im Allgemeinen durch Bezugnahme aufgenommen, es sei denn, es wird hierin eine widersprüchliche Definition oder Verwendung angegeben.
  • Der Begriff „Rechenknoten“ oder „Rechenvorrichtung“ bezieht sich zumindest in einigen Ausführungsformen auf eine identifizierbare Entität, die einen Aspekt von Edge-Computing-Operationen implementiert, sei es als Teil eines größeren Systems, einer verteilten Sammlung von Systemen oder eine eigenständige Einrichtung In einigen Beispielen kann ein Rechenknoten als „Edge-Knoten“, „Edge-Vorrichtung“, „Edge-System“ bezeichnet werden, sei es im Einsatz als Client, Server oder Zwischenentität. Spezifische Implementierungen eines Rechenknotens können in einen Server, eine Basisstation, ein Gateway, eine Straßenrandeinheit, eine Vor-Ort-Einheit, ein UE oder eine Endverbrauchsvorrichtung oder dergleichen integriert sein.
  • Der Begriff „Computersystem“, bezieht sich zumindest in einigen Ausführungsformen auf jede Art von miteinander verbundenen elektronischen Vorrichtungen, Computervorrichtungen oder Komponenten davon. Außerdem beziehen sich die Begriffe „Computersystem“ und/oder „System“ zumindest in einigen Ausführungsformen auf verschiedene Komponenten eines Computers, die kommunikativ miteinander gekoppelt sind. Ferner bezieht sich der Begriff „Computersystem“ und/oder „System“ zumindest in einigen Ausführungsformen auf mehrere Computervorrichtungen und/oder mehrere Computersysteme, die kommunikativ miteinander gekoppelt und dazu konfiguriert sind, Rechen- und/oder Vernetzungsressourcen gemeinsam zu nutzen.
  • Der Begriff „Architektur“ bezieht sich zumindest in einigen Ausführungsformen auf eine Computerarchitektur oder eine Netzwerkarchitektur. Eine „Netzwerkarchitektur“ ist eine physische und logische Struktur oder Anordnung von Software- und/oder Hardwareelementen in einem Netzwerk mit Kommunikationsprotokollen, Schnittstellen und Medienübertragung. Eine „Computerarchitektur“ ist eine physische und logische Struktur oder Anordnung von Software- und/oder Hardwareelementen in einem Computersystem oder einer Computerplattform mit Technologiestandards für Interaktionen dazwischen.
  • Der Begriff „Gerät“, „Computergerät“ oder dergleichen bezieht sich zumindest in einigen Ausführungsformen auf eine Computervorrichtung oder ein Computersystem mit Programmcode (z. B. Software oder Firmware), der speziell zum Bereitstellen einer spezifischen Rechenressource konzipiert ist. Ein „virtuelles Gerät“ ist ein virtuelles Maschinenabbild, das durch eine mit einem Hypervisor ausgestattete Vorrichtung zu implementieren ist, die ein Computergerät virtualisiert oder emuliert oder anderweitig dazu bestimmt ist, eine spezifische Rechenressource bereitzustellen.
  • Der Begriff „Benutzergerät“ oder „UE“ bezieht sich zumindest in einigen Ausführungsformen auf eine Vorrichtung mit Funkkommunikationsfähigkeiten und kann einen entfernten Benutzer von Netzwerkressourcen in einem Kommunikationsnetzwerk beschreiben. Der Begriff „Benutzergerät“ oder „UE“ kann als Synonym für Client, Mobilteil, Mobilvorrichtung, Mobilendgerät, Benutzerendgerät, Mobileinheit, Station, Mobilstation, Mobilbenutzer, Teilnehmer, Benutzer, Remotestation, Zugriffsagent, Benutzeragent, Empfänger, Funkgerät, rekonfigurierbares Funkgerät, rekonfigurierbare Mobilvorrichtung usw. angesehen und als solche bezeichnet werden. Außerdem kann der Begriff „Benutzergerät“ oder „UE“ jede Art von drahtloser/drahtgebundener Vorrichtung oder jede Rechenvorrichtung mit einer drahtlosen Kommunikationsschnittstelle umfassen. Der Begriff „Station“ oder „STA“ bezieht sich zumindest in einigen Ausführungsformen auf eine logische Entität, die eine einzeln adressierbare Instanz einer Medienzugriffssteuerung-(MAC-) und einer Bitübertragungsschicht-(PHY-)Schnittstelle zum drahtlosen Medium (WM) ist. Der Begriff „drahtloses Medium“ oder „WM“ bezieht sich zumindest in einigen Ausführungsformen auf das Medium, das verwendet wird, um die Übertragung von Protokolldateneinheiten (PDUs) zwischen Peer-Bitübertragungsschicht-(PHY-)Entitäten eines drahtlosen lokalen Netzwerks (LAN) zu implementieren.
  • Der Begriff „Netzwerkelement“ bezieht sich zumindest in einigen Ausführungsformen auf physische oder virtualisierte Geräte und/oder Infrastruktur, die die zum Bereitstellen von drahtgebundenen oder drahtlosen Kommunikationsnetzdiensten verwendet werden. Der Begriff „Netzwerkelement“ kann als Synonym für einen vernetzten Computer, Networking-Hardware, ein Netzwerkgerät, einen Netzwerkknoten, einen Router, einen Switch, einen Hub, eine Brücke, eine Funknetzwerksteuerung, eine RAN-Vorrichtung, einen RAN-Knoten, ein Gateway, einen Server, eine virtualisierte VNF, eine NFVI und/oder dergleichen angesehen und/oder als solche bezeichnet werden.
  • Der Begriff „Zugangspunkt“ oder „AP“ bezieht sich zumindest in einigen Ausführungsformen auf eine Entität, die eine Station (STA) enthält und Zugriff auf die Verteilungsdienste für assoziierte STAs über das drahtlose Medium (WM) bereitstellt. Ein AP umfasst eine STA und eine Verteilsystemzugangsfunktion (DSAF).
  • Der Begriff „Basisstation“ bezieht sich zumindest in einigen Ausführungsformen auf ein Netzelement in einem Funkzugangsnetzwerk (RAN), wie etwa einem Mobilkommunikationsnetzwerk der vierten Generation (4G) oder der fünften Generation (5G), das für die Übertragung und den Empfang von Funksignalen in einer oder mehreren Zellen zu oder von einem Benutzergerät (UE) verantwortlich ist. Eine Basisstation kann eine integrierte Antenne aufweisen oder über Feeder-Kabel mit einem Antennenarray verbunden sein. Eine Basisstation verwendet spezialisierte digitale Signalverarbeitung und Netzwerkfunktionshardware. In einigen Beispielen kann die Basisstation für Flexibilität, Kosten und Performance in mehrere Funktionsblöcke aufgeteilt sein, die in Software arbeiten. In einigen Beispielen kann eine Basisstation einen evolvierten NodeB (eNB) oder einen NodeB der nächsten Generation (gNB) umfassen. In einigen Beispielen kann die Basisstation Rechenhardware betreiben oder umfassen, um als ein Rechenknoten zu arbeiten. In vielen der hierin erörterten Szenarien kann jedoch eine RAN-Basisstation durch einen Zugangspunkt (z. B. Drahtlosnetzwerkzugangspunkt) oder andere Netzwerkzugangshardware ersetzt werden.
  • Der Begriff „Residential Gateway“ oder „RG“ bezieht sich wenigstens in einigen Ausführungsformen auf eine Vorrichtung, die zum Beispiel Sprache, Daten, Rundfunkvideo, Video auf Abruf für andere Vorrichtungen in Kundenstandorten bereitstellt. Der Begriff „Wireline 5G Access Network“ oder „W-5GAN“ bezieht sich zumindest in einigen Ausführungsformen auf ein Wireline-AN, das über N2- und N3-Referenzpunkte mit einem 5GC verbunden ist. Das W-5GAN kann sowohl ein W-5GBAN als auch ein W-5GCAN sein. Der Begriff „Wireline 5G Cable Access Network“ oder „W-5GCAN“ bezieht sich zumindest in einigen Ausführungsformen auf ein Zugangsnetzwerk, das in/von CableLabs definiert ist. Der Begriff „Wireline BBF Access Network“ oder „W-5GBAN“ bezieht sich zumindest in einigen Ausführungsformen auf ein Zugangsnetzwerk, das in/vom Broadband Forum (BBF) definiert ist. Der Begriff „Wireline Access Gateway Function“ oder „W-AGF“ bezieht sich zumindest in einigen Ausführungsformen auf eine Netzwerkfunktion in W-5GAN, die Konnektivität zu einem 3GPP-5G-Kernnetzwerk (5GC) für 5G-RG und/oder FN-RG bereitstellt. Der Begriff „5G-RG“ bezieht sich zumindest in einigen Ausführungsformen auf ein RG, das in der Lage ist, eine Verbindung zu einem 5GC herzustellen, das die Rolle eines Benutzergeräts in Bezug auf das 5GC innehat; es unterstützt ein sicheres Element und tauscht N1-Signalisierung mit dem 5GC aus. Das 5G-RG kann entweder ein 5G-BRG oder ein 5G-CRG sein.
  • Der Begriff „Zentrale“ (oder CO) bezeichnet einen Aggregationspunkt für eine Telekommunikationsinfrastruktur innerhalb eines zugänglichen oder definierten geografischen Gebiets, in dem Telekommunikationsdienstanbieter traditioneller Weise häufig Vermittlungseinrichtungen für einen oder mehrere Typen von Zugangsnetzwerken angeordnet aufweisen. Die CO kann physisch ausgelegt sein, um Telekommunikationsinfrastrukturgeräte oder Rechen-, Datenspeicher- und Netzwerkressourcen unterzubringen. Die CO muss j edoch kein von einem Telekommunikationsdienstanbieter festgelegter Ort sein. Die CO kann eine beliebige Anzahl von Rechenvorrichtungen für Edge-Anwendungen und -Dienste oder sogar lokale Implementierungen von Cloud-ähnlichen Diensten hosten.
  • Der Begriff „Cloud-Computing“ oder „Cloud“ bezieht sich zumindest in einigen Ausführungsformen auf ein Paradigma zum Ermöglichen von Netzwerkzugriff auf einen skalierbaren und elastischen Pool von gemeinsam nutzbaren Rechenressourcen mit Self-Service-Bereitstellung und -Verwaltung bei Bedarf und ohne aktive Verwaltung durch Benutzer. Cloud-Computing stellt Cloud-Computing-Dienste (oder Cloud-Dienste) bereit, bei denen es sich um eine oder mehrere über Cloud-Computing angebotene Fähigkeiten handelt, die unter Verwendung einer definierten Schnittstelle (z. B. einer API oder dergleichen) aufgerufen werden. Der Begriff „Rechenressource“ oder einfach „Ressource“ bezieht sich zumindest in einigen Ausführungsformen auf eine beliebige physische oder virtuelle Komponente oder Verwendung solcher Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Rechenressourcen umfassen Nutzung von/Zugriff auf Server, Prozessor(en), Datenspeichergeräte, Arbeitsspeichervorrichtungen, Speicherbereiche, Netzwerke, elektrische Leistung, (periphere) Eingabe-/Ausgabevorrichtungen, mechanische Vorrichtungen, Netzwerkverbindungen (z. B. Kanäle/Links, Ports, Netzwerkbuchsen usw.), Betriebssysteme, virtuelle Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen für eine Zeitdauer. Eine „Hardwareressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die durch physisches Hardwareelement(e) bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die durch eine Virtualisierungsinfrastruktur für eine Anwendung, eine Vorrichtung, ein System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, auf die Computervorrichtungen/Systeme über ein Kommunikationsnetzwerk zugreifen können.. Der Begriff „Systemressourcen“ kann sich auf eine jede Art gemeinsam genutzter Entitäten zum Bereitstellen von Diensten beziehen und Rechen- und/oder Netzwerkressourcen umfassen. Systemressourcen können als ein Satz von kohärenten Funktionen, Netzwerkdatenobjekten oder Diensten betrachtet werden, auf die durch einen Server zugegriffen werden kann, wenn sich solche Systemressourcen auf einem einzigen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind.
  • Der Begriff „Arbeitslast“ bezieht sich zumindest in einigen Ausführungsformen auf eine Menge an Arbeit, die durch ein Computersystem, eine Vorrichtung, eine Entität usw. während eines Zeitraums oder zu einem bestimmten Zeitpunkt durchgeführt wird. Eine Arbeitslast kann als ein Benchmark dargestellt werden, wie etwa eine Reaktionszeit, ein Durchsatz (z. B. wie viel Arbeit über einen Zeitraum durchgeführt wird) und/oder dergleichen. Zusätzlich oder alternativ dazu kann die Arbeitslast als eine Speicherarbeitslast (z. B. eine Menge an Speicherplatz, die zur Programmausführung benötigt wird, um temporäre oder permanente Daten zu speichern und Zwischenberechnungen durchzuführen), eine Prozessorarbeitslast (z. B. eine Anzahl an Anweisungen, die von einem Prozessor während einer gegebenen Zeitspanne oder zu einem bestimmten Zeitpunkt ausgeführt wird), eine E/A-Arbeitslast (z. B. eine Anzahl von Ein- und Ausgaben oder Systemzugriffen während eines gegebenen Zeitraums oder zu einem bestimmten Zeitpunkt), Datenbankarbeitslasten (z. B. eine Anzahl von Datenbankabfragen während eines Zeitraums), eine netzwerkbezogene Arbeitslast (z. B. eine Anzahl von Netzwerkanbindungen, eine Anzahl von Mobilitätsaktualisierungen, eine Anzahl von Funkverbindungsfehlern, eine Anzahl von Handovers, eine Menge von über eine Luftschnittstelle zu übertragenden Daten usw.) und/oder dergleichen dargestellt werden. Verschiedene Algorithmen können verwendet werden, um eine Arbeitslast und/oder Arbeitslastcharakteristiken zu bestimmen, die auf einem beliebigen der zuvor genannten Arbeitslasttypen basieren können.
  • Der Begriff „Cloud-Dienstanbieter“ (oder CSP) bezeichnet eine Organisation, die typischerweise umfangreiche „Cloud“-Ressourcen betreibt, die zentralisierte, regionale und Edge-Rechenzentren (z. B. wie im Kontext der öffentlichen Cloud verwendet) umfassen. In anderen Beispielen kann ein CSP auch als Cloud-Dienstbetreiber (CSO - Cloud Service Operator) bezeichnet werden. Verweise auf „Cloud-Computing“ beziehen sich im Allgemeinen auf Rechenressourcen und -dienste, die von einem CSP oder einem CSO an entfernten Orten mit zumindest etwas erhöhter Latenz, Entfernung oder Beschränkung im Verhältnis zu Edge Computing angeboten werden.
  • Der Begriff „Rechenzentrum“ bezieht sich zumindest in einigen Ausführungsformen auf zweckbestimmte Struktur, die mehrere Hochleistungs-Rechen- und -Datenspeicherknoten beherbergen soll, so dass eine große Menge an Rechen-, Datenspeicher- und Netzwerkressourcen an einem einzigen Ort vorhanden ist. Dabei handelt es sich häufig um spezialisierte Rack- und Gehäusesysteme, geeignete Heiz-, Kühl-, Lüftungs-, Sicherheits-, Brandschutz- und Stromversorgungssysteme. Der Begriff kann sich in einigen Zusammenhängen auch auf einen Rechen- und Datenspeicherknoten beziehen. Ein Rechenzentrum kann im Maßstab zwischen einem (z. B. größten) zentralisierten oder Cloud-Rechenzentrum, einem regionalen Rechenzentrum und einem (z. B. kleinsten) Edge-Rechenzentrum variieren.
  • Der Begriff „Zugangs-Edge-Schicht“ bezeichnet die Unterschicht der Infrastruktur-Edge, die dem Endbenutzer oder Gerät am nächsten ist. Solch eine Schicht kann zum Beispiel von einem Edge-Rechenzentrum verwirklicht werden, das an einem zellularen Netzwerkstandort bereitgestellt wird. Die Zugriffs-Edge-Schicht fungiert als die vordere Linie der Infrastruktur-Edge und kann eine Verbindung mit einer Aggregations-Edge-Schicht herstellen, die in der Hierarchie höher ist.
  • Der Begriff Aggregations-Edge-Schicht bezeichnet die einen Sprung von der Zugangs-Edge-Schicht entfernte Schicht der Infrastruktur-Edge. Diese Schicht kann entweder als ein Rechenzentrum mittleren Maßstabs an einem einzigen Ort existieren oder aus mehreren miteinander verbundenen Mikrorechenzentren gebildet sein, um eine hierarchische Topologie mit der Zugangs-Edge-Schicht zu bilden, um bessere Zusammenarbeit, Arbeitslastausfallsicherung und Skalierbarkeit als die Zugangs-Edge-Schicht allein zu ermöglichen.
  • Der Begriff „Netzwerkfimktionsvirtualisierung“ (oder NFV) bezeichnet die Migration von NFs von eingebetteten Diensten innerhalb proprietärer Hardwaregeräte zu softwarebasierten virtualisierten NFs (oder VNFs), die auf standardisierten CPUs (z. B. innerhalb standardmäßiger x86®- und ARM®-Server wie etwa jenen, die Intel® Xeon™- oder AMD® Epyc™- oder Opteron™-Prozessoren umfassen) unter Verwendung von Virtualisierungs- und Cloud-Computing-Technologien nach Industriestandard ausgeführt werden. Zusätzlich oder alternativ finden NFV-Verarbeitung und Datenspeicherung an den Edge-Rechenzentren statt, die direkt mit dem lokalen zellularen Standort innerhalb der Infrastruktur-Edge verbunden sind.
  • Der Begriff „virtualisierte NF“ (oder VNF) bezeichnet eine softwarebasierte NF, die auf Multifunktions-Mehrzweck-Rechenressourcen (z. B. x86, ARM-Verarbeitungsarchitektur) arbeitet, die von NFV anstelle dedizierter physischer Ausrüstung verwendet werden. Zusätzlich oder alternativ arbeiten mehrere VNFs in einem Edge-Rechenzentrum an der Infrastruktur-Edge.
  • Der Begriff „Edge-Rechenknoten“ bezieht sich zumindest in einigen Ausführungsformen auf eine logische oder virtualisierte Implementierung eines rechenfähigen Elements der realen Welt in Form einer Vorrichtung, eines Gateways, einer Brücke, eines Systems oder eines Subsystems, einer Komponente, sei es dass es in einem Server-, Client-, Endpunkt- oder Peer-Modus arbeitet und sei es dass es sich an einer „Edge“ eines Netzwerks oder an einem verbundenen Ort weiter innerhalb des Netzwerks befindet. Bezugnahmen auf einen „Knoten“, die hierin verwendet werden, sind im Allgemeinen mit „Vorrichtung“, „Komponente“ und „Subsystem“ austauschbar; Bezugnahmen auf ein „Edge-Computing-System“ beziehen sich jedoch im Allgemeinen auf eine verteilte Architektur, Organisation oder Sammlung mehrerer Knoten und Vorrichtungen, die organisiert ist, um einen gewissen Aspekt von Diensten oder Ressourcen in einer Edge-Computing-Umgebung zu erreichen oder anzubieten.
  • Der Begriff „Cluster“ bezieht sich zumindest in einigen Ausführungsformen auf einen Satz oder eine Gruppierung von Entitäten als Teil eines Edge-Computing-Systems (oder von Edge-Computing-Systemen) in Form von physischen Entitäten (z. B. verschiedenen Computersystemen, Netzwerken oder Netzwerkgruppen), logischen Entitäten (z. B. Anwendungen, Funktionen, Sicherheitskonstrukten, Containern) und dergleichen. An einigen Stellen wird „Cluster“ auch als „Gruppe“ oder „Domäne“ bezeichnet. Die Zugehörigkeit zu einem Cluster kann basierend auf Bedingungen oder Funktionen modifiziert oder beeinflusst werden, darunter dynamische oder eigenschaftsbasierte Zugehörigkeit, Netzwerk- oder Systemverwaltungsszenarien oder verschiedene unten erörterte beispielhafte Techniken, die eine Entität in einem Cluster hinzufügen, modifizieren oder entfernen können. Cluster können auch mehrere Schichten, Ebenen oder Eigenschaften, die Variationen von Sicherheitsmerkmalen und Ergebnissen umfassen, die auf solchen Schichten, Ebenen oder Eigenschaften basieren, umfassen oder damit assoziiert sein.
  • Der Begriff „Funktechnologie“ bezieht sich zumindest in einigen Ausführungsformen auf eine Technologie zum drahtlosen Senden und/oder Empfangen elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugangstechnologie“ oder „RAT“ bezieht sich zumindest in einigen Ausführungsformen auf die Technologie, die für die zugrundeliegende physikalische Verbindung zu einem funkbasierten Kommunikationsnetzwerk verwendet wird. Der „RAT-Typ“ identifiziert die Übertragungstechnik, die in einem Zugangsnetzwerk verwendet wird, zum Beispiel New Radio (NR), Schmalband-IoT (NB-IOT), Untrustetd-Non-3GPP, Trusted-Non-3GPP, Trusted-IEEE 802.11, Non-3GPP-Zugang, Wireline, Wireline-Cable, Wireline-Broadband-Forum (wireline-BBF) usw.
  • Der Begriff „V2X“ bezieht sich zumindest in einigen Ausführungsformen auf Kommunikationen von Fahrzeug zu Fahrzeug (V2V), Fahrzeug zu Infrastruktur (V21), Infrastruktur zu Fahrzeug (I2V), Fahrzeug zu Netzwerk (V2N) und/oder Netzwerk zu Fahrzeug (N2V) und assoziierte Funkzugangstechnologien.
  • Der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) bezieht sich zumindest in einigen Ausführungsformen auf einen Satz standardisierter Regeln oder Anweisungen, die durch eine Kommunikationsvorrichtung und/oder ein Kommunikationssystem implementiert werden, um mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, und die Anweisungen zum Paketieren/Depaketieren von Daten, Modulieren/Demodulieren von Signalen, Implementieren von Protokollstapeln und/oder dergleichen umfassen. Beispiele für Drahtloskommunikationsprotokolle, die in verschiedenen Ausführungsformen verwendet werden können, umfassen eine GSM-Funkkommunikationstechnologie (GSM - Global System for Mobile Communications), eine GPRS-Funkkommunikationstechnologie (GPRS - General Packet Radio Service), eine EDGE-Funkkommunikationstechnologie (EDGE - Enhanced Data Rates for GSM Evolution) und/oder 3GPP-Funkkommunikationstechnologie (3GPP - Third Generation Partnership Project), darunter zum Beispiel 3GPP Fifth Generation (5 G) oder New Radio (NR), UMTS (Universal Mobile Telecommunications System), FOMA (Freedom of Multimedia Access), LTE (Long Term Evolution), LTE-Advanced (LTE Advanced), LTE Extra, LTE-A Pro, cdmaOne (2G), CDMA 2000 (Code Division Multiple Access 2000), CDPD (Cellular Digital Packet Data), Mobitex, CSD (Circuit Switched Data), HSCSD (High Speed CSD), UMTS (Universal Mobile Telecommunications System), W-CDM (Wideband Code Division Multiple Access), HSPA (High Speed Packet Access), HSPA+ (HSPA Plus), TD-CDMA (Time Division-Code Division Multiple Access), TD-SCDMA (Time Division-Synchronous Code Division Multiple Access), LTE LAA, MuLTEfire, UTRA (UMTS Terrestrial Radio Access), E-UTRA (Evolved UTRA), EV-DO (Evolution-Data Optimized oder Evolution-Data Only), AMPS (Advanced Mobile Phone System), D-AMPS (Digital AMPS), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), CDPD (Cellular Digital Packet Data), DataTAC, iDEN (Integrated Digital Enhanced Network), PDC (Personal Digital Cellular), PHS (Personal Handy Phone System), WiDEN (Wideband Integrated Digital Enhanced Network), iBurst, UMA (Unlicensed Mobile Access), auch als 3GPP-Generic Access Network oder GAN-Standard bezeichnet), Bluetooth ®, BLE (Bluetooth Low Energy), IEEE 802.15.4-basierte Protokolle (z. B. 6LoWPAN (IPv6 over Low Power Wireless Personal Area Networks), WirelessHART, MiWi, Thread, 802.11a usw.) WiFi-direct, ANT/ANT+, ZigBee, Z-Wave, 3GPP D2D (Device-to-Device) oder ProSe (Proximity Services), UPnP (Universal Plug and Play), LPWAN (Low-Power Wide-Area-Network), LoRA (Long Range Wide Area Network) oder LoRaWAN™, entwickelt von Semtech und LoRa Alliance, DECT (Digital Enhanced Cordless Telecommunications), DECT ULE (DECT Ultra Low Energy), DECT-2020, Sigfox, WiGig-Standard (WiGig - Wireless Gigabit Alliance), WiMAX (Worldwide Interoperability for Microwave Access), mmWave-Standards im Allgemeinen (z. B. Drahtlossysteme, die auf 10-300 GHz und darüber arbeiten, wie etwa WiGig, IEEE 802.1 1ad, IEEE 802.11ay usw.), V2X-Kommunikationstechnologien, darunter C-V2X, WAVE, 802.11bd, DSRC-Kommunikationssysteme (DSRC - Dedicated Short Range Communications), ITS (Intelligent Transport Systems), darunter European ITS-G5, ITS-G5B, ITS-G5C usw., Ultra-High-Frequency-(UHF-)Kommunikation, Very-High-Frequency-(VHF-)Kommunikation. Zusätzlich zu den oben aufgelisteten Standards kann eine beliebige Anzahl von Satelliten-Uplink-Technologien für Zwecke der vorliegenden Offenbarung verwendet werden, darunter zum Beispiel Funkgeräte, die unter anderem Standards entsprechen, die von der International Telecommunication Union (ITU) oder dem ETSI herausgegeben werden. Die hierin bereitgestellten Beispiele sind daher so zu verstehen, dass sie auf verschiedene andere, sowohl existierende als auch noch nicht formulierte Kommunikationstechnologien anwendbar sind.
  • Der Begriff „Kanal“ bezieht sich zumindest in einigen Ausführungsformen auf gegenständliche oder nichtgegenständliche Übertragungsmedium, das verwendet wird, um Daten oder einen Datenstrom zu kommunizieren. Der Begriff „Kanal“ kann synonym zu und/oder gleichbedeutend mit „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugriffskanal“, „Datenzugriffskanal“, „Link“, „Datenlink“, „Träger“, „Hochfrequenzträger“ und/oder jedem anderen ähnlichen Begriff sein, der einen Pfad oder ein Medium bezeichnet, über den/das Daten kommuniziert werden. Außerdem bezieht sich der Begriff „Link“, zumindest in einigen Ausführungsformen auf eine Verbindung zwischen zwei Vorrichtungen durch eine RAT zum Zweck des Sendens und Empfangens von Informationen.
  • Der Begriff „Dienstqualität“ oder „QoS“ bezieht sich zumindest in einigen Ausführungsformen auf eine Beschreibung oder Messung der Gesamt-Performance eines Dienstes (z. B. Telefonie und/oder zellularer Dienst, Netzwerkdienst, Drahtloskommunikations-/Konnektivitätsdienst, Cloud-Computing-Dienst usw.). In einigen Fällen kann die QoS aus der Perspektive der Benutzer dieses Dienstes beschrieben oder gemessen werden, und entsprechend kann QoS der kollektive Effekt der Dienst-Performance sein, die den Grad der Zufriedenheit eines Benutzers dieses Dienstes bestimmen. In anderen Fällen bezieht sich QoS zumindest in einigen Ausführungsformen auf Verkehrspriorisierungs- und Ressourcenreservierungssteuermechanismen anstelle der erreichten Wahrnehmung der Dienstqualität. In diesen Fällen ist QoS die Fähigkeit, für verschiedene Anwendungen, Benutzern oder Flüssen unterschiedliche Prioritäten bereitzustellen oder für einen Fluss ein gewisses Performanceniveau zu garantieren. In beiden Fällen ist QoS durch die kombinierten Aspekte von Performance-Faktoren gekennzeichnet, die auf einen oder mehrere Dienste anwendbar sind, wie beispielsweise Dienstoperabilitätsperformance, Dienstzugänglichkeitsperformance, Dienstbeibehaltungsfähigkeitsperformance, Dienstzuverlässigkeitsperformance, Dienstintegritätsperformance und andere Faktoren, die für jeden Dienst spezifisch sind. Mehrere verwandte Aspekte des Dienstes können berücksichtigt werden, wenn die QoS quantifiziert wird, einschließlich Paketverlustraten, Bitraten, Durchsatz, Übertragungsverzögerung, Verfügbarkeit, Zuverlässigkeit, Jitter, Signalstärke und/oder Qualitätsmessungen und/oder anderer Messungen, wie etwa der hierin erörterten.
  • Die Begriffe „Strahlformung“ und „Strahllenkung“ beziehen sich zumindest in einigen Ausführungsformen auf einen räumlichen Filtermechanismus, der an einem Sender (Tx) verwendet wird, um die Empfangssignalleistung, das Signal-Rauschverhältnis (SNR) oder irgendeine andere Signalisierungsmetrik an einem beabsichtigten Empfänger (Rx) zu verbessern. Der Begriff „Strahlformer“ bezieht sich zumindest in einigen Ausführungsformen auf eine STA, die eine Bitübertragungsschicht-PDU (PPDU - Physical layer PDU) unter Verwendung einer Strahlformungssteuermatrix überträgt. Der Begriff „Strahlformungssteuermatrix“ bezieht sich zumindest in einigen Ausführungsformen auf eine Matrix, die unter Verwendung von Kenntnis des Kanals zwischen einem Tx und einem beabsichtigten Rx bestimmt wird, der mit dem Ziel, die Signalleistung, SNR, und/oder irgendeine andere Signalisierungsmetrik am beabsichtigten Rx zu verbessern, aus Raum-Zeit-Strömen auf Sendeantennen abgebildet wird.
  • Der Begriff „Basisdienstsatz“ oder „BSS“ bezieht sich zumindest in einigen Ausführungsformen auf einen Satz von STAs, die sich erfolgreich unter Verwendung der JOIN-Dienstprimitive synchronisiert haben, und eine STA, die das START-Primitiv verwendet hat. Alternativ dazu spezifiziert ein Satz von STAs, die das START-Primitiv verwendet haben, übereinstimmende Mesh-Profile, wobei die Übereinstimmung der Mesh-Profile über die Scanprozedur verifiziert wurde. Die Mitgliedschaft bei einem BSS impliziert nicht, dass drahtlose Kommunikation mit allen anderen Mitgliedern des BSS möglich ist.
  • Der Begriff „Koordinationsfunktion“ bezieht sich zumindest in einigen Ausführungsformen auf eine logische Funktion, die bestimmt, wann eine STA PDUs über ein WM übertragen darf. Der Begriff „verteilte Koordinationsfunktion“ oder „DCF“ bezieht sich zumindest in einigen Ausführungsformen auf eine Klasse von Koordinationsfunktion(en), wobei in jeder STA in einem Basisdienstsatz (BSS) dieselbe Koordinationsfunktionslogik aktiv ist, wann immer das Netzwerk in Betrieb ist. Der Begriff „Verteilungsdienst“ bezieht sich zumindest in einigen Ausführungsformen auf einen Dienst, der unter Verwendung von Assoziationsinformationen Medienzugriffssteuerungs-(MAC-)Diensttupel innerhalb eines Verteilungssystems (DS) liefert. Der Begriff „Verteilungssystem“ oder „DS“ bezieht sich zumindest in einigen Ausführungsformen auf ein System, das verwendet wird, um einen Satz von Basisdienstsätzen (BSS) und integrierten lokalen Netzwerken (LANs) miteinander zu verbinden, um einen erweiterten Dienstsatz (ESS) zu erzeugen.
  • Der Begriff „Clear Channel Assessment-Funktion (CCA-Funktion)“ bezieht sich zumindest in einigen Ausführungsformen auf eine logische Funktion in der Bitübertragungsschicht (PHY), die den aktuellen Nutzungszustand eines WM bestimmt.
  • Die Begriffe „Instanziieren“, „Instanziierung“ und dergleichen beziehen sich zumindest in einigen Ausführungsformen auf die Erzeugung einer Instanz. Eine „Instanz“ bezieht sich zumindest in einigen Ausführungsformen auch auf ein konkretes Auftreten eines Objekts, das zum Beispiel während der Ausführung von Programmcode auftreten kann. Der Begriff „Informationselement“ bezieht sich zumindest in einigen Ausführungsformen auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff Feld bezieht sich zumindest in einigen Ausführungsformen auf individuelle Inhalte eines Informationselements oder eines Datenelements, das Inhalt enthält. Der Begriff „Datenbankobjekt“, „Datenstruktur“ oder dergleichen kann sich auf jede Darstellung von Informationen beziehen, die in Form eines Objekts, Attributwertepaars (AVP), Schlüsselwertepaars (KVP), Tupels usw. vorliegen, und kann Variablen, Datenstrukturen, Funktionen, Verfahren, Klassen, Datenbankaufzeichnungen, Datenbankfelder, Datenbankentitäten, Assoziationen zwischen Daten und/oder Datenbankentitäten (auch als „Beziehung“ bezeichnet), Blöcke und Verknüpfungen zwischen Blöcken in Blockchain-Implementierungen und/oder dergleichen umfassen. Der Begriff „Datenelement“ oder „DE“ bezieht sich zumindest in einigen Ausführungsformen auf einen Datentyp, der ein einziges Datenelement enthält. Der Begriff „Datenrahmen“ oder „DF“ bezieht sich zumindest in einigen Ausführungsformen auf einen Datentyp, der mehr als ein Datenelement in einer vordefinierten Reihenfolge enthält.
  • Der Begriff „Datagramm“ bezieht sich zumindest in einigen Ausführungsformen auf eine Basis-Übertragungseinheit, die mit einem paketvermittelten Netzwerk assoziiert ist; ein Datagramm kann strukturiert sein, um Header- und Nutzlastabschnitte aufzuweisen. Der Begriff „Datagramm“ kann zumindest in einigen Ausführungsformen als „Dateneinheit“ oder dergleichen bezeichnet werden.
  • Der Begriff „Unterrahmen“ bezieht sich zumindest in einigen Ausführungsformen auf ein Zeitintervall, in dem ein Signal signalisiert wird. Bei einigen Implementierungen ist ein Unterrahmen gleich 1 Millisekunde (ms). Der Begriff „Zeitschlitz“ bezieht sich zumindest in einigen Ausführungsformen auf ein ganzzahliges Vielfaches aufeinanderfolgender Unterrahmen. Der Begriff „Überrahmen“ bezieht sich zumindest in einigen Ausführungsformen auf ein Zeitintervall, das zwei Zeitschlitze umfasst.
  • Der Begriff „Interoperabilität“ bezieht sich zumindest in einigen Ausführungsformen auf die Fähigkeit von STAs, die ein Kommunikationssystem oder eine RAT nutzen, mit anderen STAs zu kommunizieren, die ein anderes Kommunikationssystem oder eine andere RAT nutzen. Der Begriff „Koexistenz“ bezieht sich zumindest in einigen Ausführungsformen auf das Teilen oder Zuweisen von Hochfrequenzressourcen unter STAs, die entweder ein Kommunikationssystem oder eine RAT verwenden.
  • Der Begriff „Zuverlässigkeit“ bezieht sich zumindest in einigen Ausführungsformen auf die Fähigkeit einer computerbezogenen Komponente (z. B. Software, Hardware oder Netzwerkelement/-entität), konsistent eine gewünschte Funktion durchzuführen und/oder gemäß einer Spezifikation zu arbeiten. Zuverlässigkeit im Kontext von Netzwerkkommunikationen (z. B. „Netzwerkzuverlässigkeit“) kann sich auf die Fähigkeit eines Netzwerks zum Durchführen einer Kommunikation beziehen. Netzwerkzuverlässigkeit kann auch die (oder ein Maß der) Wahrscheinlichkeit sein, dass eine spezifizierte Datenmenge von einer Quelle an ein Ziel (oder eine Senke) übermittelt wird.
  • Der Begriff „Benutzer“ im Kontext von rekonfigurierbaren Funkgeräten/-systemen bezieht sich zumindest in einigen Ausführungsformen auf eine abstrakte Darstellung einer beliebigen Instanz, die Befehlsanforderungen (z. B. unter Verwendung der Dienste) an den Multifunkcomputer ausgibt. Drei Arten von Benutzern werden basierend auf der Art der verwendeten Dienste unterschieden: Administrator für Multifunkverwaltungsebene, Mobilitätsrichtlinienmanager für Steuerungsebene und Netzwerkstapel für Benutzerebene.
  • Der Begriff „Anwendungsfall“ bezieht sich zumindest in einigen Ausführungsformen auf eine Beschreibung eines Systems aus der Perspektive eines Benutzers. Anwendungsfälle behandeln manchmal ein System als eine Blackbox, und die Interaktionen mit dem System, einschließlich Systemantworten, werden als von außerhalb des Systems wahrgenommen. Anwendungsfälle vermeiden typischerweise technisches Jargon, sondern bevorzugen stattdessen die Sprache des Endnutzers oder Domänenfachmanns.
  • Der Begriff „Anwendung“ kann sich auf eine vollständige und bereitstellbare Paketumgebung beziehen, um eine gewisse Funktion in einer Betriebsumgebung zu erreichen. Der Begriff „KI/ML-Anwendung“ oder dergleichen kann eine Anwendung sein, die einige KI/ML-Modelle und Beschreibungen auf Anwendungsebene enthält. Der Begriff „maschinelles Lernen“ oder „ML“ bezieht sich zumindest in einigen Ausführungsformen auf die Verwendung von Computersystemen, die Algorithmen und/oder statistische Modelle implementieren, um spezifische Aufgaben durchzuführen, wobei keine expliziten Anweisungen verwendet werden, sondern stattdessen auf Muster und Inferenzen gebaut wird. ML-Algorithmen erstellen oder schätzen mathematische Modell(e) (als „ML-Modelle“ oder dergleichen bezeichnet) basierend auf Sample-Daten (als „Trainingsdaten“, „Modelltrainingsinformationen“ oder dergleichen bezeichnet), um Vorhersagen oder Entscheidungen zu treffen, ohne zum Durchführen solcher Aufgaben explizit programmiert zu sein. Im Allgemeinen ist ein ML-Algorithmus ein Computerprogramm, das aus Erfahrung in Bezug auf irgendeine Aufgabe und irgendeine Performance-Maßnahme lernt, und ein ML-Modell kann ein beliebiges Objekt oder eine beliebige Datenstruktur sein, die erzeugt wird, nachdem ein ML-Algorithmus mit einem oder mehreren Trainingsdatensätzen trainiert wurde. Nach dem Training kann ein ML-Modell verwendet werden, um Vorhersagen über neue Datensätze zu treffen. Obwohl sich der Begriff „ML-Algorithmus“ sich zumindest in einigen Ausführungsformen auf andere Konzepte als der Begriff „ML-Modell“ bezieht, können diese Begriffe, wie hierin erörtert, für die Zwecke der vorliegenden Offenbarung austauschbar verwendet werden.
  • Der Begriff „Sitzung“ bezieht sich zumindest in einigen Ausführungsformen auf einen temporären und interaktiven Informationsaustausch zwischen zwei oder mehr Kommunikationsvorrichtungen, zwei oder mehr Anwendungsinstanzen, zwischen einem Computer und einem Benutzer oder zwischen zwei oder mehr beliebigen Entitäten oder Elementen.
  • Der Begriff „Datennetzwerk“ oder „DN“ bezieht sich zumindest in einigen Ausführungsformen auf ein Netzwerk, das datenzentrische Dienste hostet, wie beispielsweise Betreiberdienste, das Internet, Dienste Dritter oder Unternehmensnetzwerke. Zusätzlich oder alternativ bezieht sich ein DN zumindest in einigen Ausführungsformen auf Dienstnetzwerke, die zu einem Betreiber oder einem Dritten gehören, die einem Client oder Benutzergerät (UE) als ein Dienst angeboten werden. DNs werden manchmal als „Paketdatennetzwerke“ oder „PDNs“ bezeichnet. Der Begriff „Local Area Data Network“ oder „LADN“ bezieht sich zumindest in einigen Ausführungsformen auf ein DN, auf das das UE nur an spezifischen Orten zugreifen kann, das Konnektivität zu einem spezifischen DNN bereitstellt und dessen Verfügbarkeit für das UE bereitgestellt wird.
  • Der Begriff „PDU-Verbindungsdienst“ bezieht sich zumindest in einigen Ausführungsformen auf einen Dienst, der einen Austausch von Protokolldateneinheiten (PDUs) zwischen einem UE und einem DN bereitstellt. Der Begriff „PDU-Sitzung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Assoziation zwischen einem UE und einem DN, das einen PDU-Konnektivitätsdienst bereitstellt. Ein PDU-Sitzungstyp kann IPv4, IPv6, IPv4v6, Ethernet, Unstructured oder ein beliebiger anderer Netzwerk-/Verbindungstyp, wie etwa die hier erörterten, sein. Der Begriff „MA-PDU-Sitzung“ bezieht sich zumindest in einigen Ausführungsformen auf eine PDU-Sitzung, die einen PDU-Konnektivitätsdienst bereitstellt, der jeweils ein Zugangsnetzwerk oder mehrere Zugangsnetzwerke gleichzeitig verwenden kann.
  • Der Begriff „Kern“ bezieht sich zumindest in einigen Ausführungsformen auf ein Funktionselement, das eine Client-Netzwerkadresse (z. B. IP-Adresse) verankert, die zur Kommunikation mit Anwendungen über das Netzwerk verwendet wird. Der Begriff „Ankerverbindung“ bezieht sich zumindest in einigen Ausführungsformen auf den Netzwerkpfad von einem Netzwerkelement (z. B. einem N-MADP) zu einem UP-Gateway (z. B. IP-Anker), das einem Client eine Netzwerkadresse (z. B. IP-Adresse) zugewiesen hat. Der Begriff „Zustellverbindung“, wie hier verwendet, bezieht sich auf einen Netzwerkpfad von einem Netzwerkelement (z. B. einem N-MADP) zu einem Client.
  • Der Begriff „Verkehrsformung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Bandbreitenverwaltungstechnik, die eine Datenübertragung verwaltet, um einem gewünschten Verkehrsprofil oder einer gewünschten Dienstklasse zu entsprechen. Verkehrsformen stellt ausreichende Netzwerkbandbreite für zeitabhängige kritische Anwendungen unter Verwendung von Richtlinienregeln, Datenklassifizierung, Warteschlangen, QoS und anderen Techniken sicher. Der Begriff „Drosseln“ bezieht sich zumindest in einigen Ausführungsformen auf die Regelung von Flüssen in oder aus einem Netzwerk oder in oder aus einer spezifischen Vorrichtung oder einem spezifischen Element.
  • Der Begriff „Netzwerkadresse“ bezieht sich zumindest in einigen Ausführungsformen auf eine Kennung für einen Knoten oder Host in einem Computernetzwerk und kann eine eindeutige Kennung über ein Netzwerk hinweg und/oder für einen lokal verwalteten Teil des Netzwerks eindeutig sein. Beispiele für Netzwerkadressen umfassen eine Kennung einer geschlossenen Zugangsgruppe (CAG-ID - Closed Access Group Identifier), eine Bluetooth-Hardwarevorrichtungsadresse (BD_ADDR - Bluetooth Hardware Device Address), eine Zellenfunknetzwerkadresse (zum Beispiel APN (Access Point Name), eine AMF-Kennung (ID), eine AF-Dienstkennung, eine Edge-Anwendungsserverkennung (EAS - Edge Application Server ID), eine Datennetzwerkzugangskennung (DNAI - Data Network Access Identifier), einen Datennetzwerknamen (DNN - Data Network Name Name), eine EP S-Trägerkennung (EBI - EPS Bearer Identity), ein Gerätekennungsregister (EIR - Equipment Identity Register) und/oder 5G-EIR, eine erweiterte eindeutige Kennung (EUI - Extended Unique Identifier), einen Gruppen-ID zur Netzwerkauswahl (GIN - Group ID for Network Selection), eine generische öffentliche Teilnehmerkennung (GPSI - Generic Public Subscription Identifier), eine globale eindeutige AMF-Kennung (GUAMI - Global Unique AMF Identifier), eine globale eindeutige temporäre Kennung (GUTI - Global Unique Temporary Identifier) und/oder 5G-GUTI, eine internationale Mobilgerätekennung (IMEI - International Mobile Equipment Identity), einen IMEI-Typ-Zuweisungscode (IMEA/TAC - IMEI-Type Allocation Code), eine internationale Mobilteilnehmerkennung (IMSI - International Mobile Subscriber Identity), einen DNN eines lokalen Datennetzwerks (LADN - Local Area Data Network), eine Mobilteilnehmeridentitätsnummer (MSIN - Mobile Subscriber Identification Number), eine Mobilteilnehmer-/Mobilstations-ISDN-Nummer (MSISDN -Mobile Subscriber/Station ISDN Number), eine Netzwerkkennung (NID - Network Identifier), eine ID einer Netzwerk-Slice-Instanz (NSI - Network Slice Instance), eine permanente Gerätekennung (PEI - Permanent Equipment Identifier (PEI), eine ID eins öffentlichen Landfunknetzwerks (PLMN - Public Land Mobile Network), eine QoS-Fluss-ID (QFI) und/oder eine 5G-QoS-Kennung (5QI), eine RAN-ID, einen Routing-Indikator, eine ID einer SMS-Funktion (SMSF), eine ID eines unabhängigen nicht-öffentlichen Netzwerks (SNPN - Stand-alone Non-Public Network), eine SUCI (Subscription Concealed Identifier), eine SUPI (Subscription Permanent Identifier), eine temporäre Mobilteilnehmerkennung (TMSI - Temporary Mobile Subscriber Identity) und Varianten davon, UE-Zugangskategorie und -kennung und/oder andere mobilfunknetzwerkbezogene Kennungen), eine E-Mail-Adresse, eine Unternehmensanwendungsserver-ID, eine Endpunktadresse, einen Electronic Product Code (EPC), wie durch den EPCglobal Tag Data Standard definiert, einen FQDN (Fully Qualified Domain Name), eine IP-Adresse (Internet Protocol Address) in einem IP-Netzwerk, (zum Beispiel IP Version 4 (Ipv4), IP Version 6 (IPv6) etc.), eine IPX-Adresse (Internet Packet Exchange-Address), LAN-ID (Local Area Network ID), eine MAC-Adresse (Media Access Control Address), Personal Area Network-ID (PAN-ID), eine Portnummer (zum Beispiel Transmission-Control-Protocol-(TCP-)Portnummer, User-Datagram-Protocol-(UDP-)Portnummer), eine QUIC Connection ID, ein RFID-Tag, eine Dienstsatzkennung (SSID - Service Set Identifier) und Varianten davon, Telefonnummern in einem öffentlichen Telefonnetzwerk (PTSN), eine universell eindeutige Kennung (UUID - Universally Unique Identifier) (zum Beispiel wie in ISO/IEC 11578:1996 spezifiziert), einen Universal Resource Locator (URL) und/oder einen Universal Resource Identifier (URI), Virtual-LAN-ID (VLAN-ID), eine X.21-Adresse, eine X.25-Adresse, eine Zigbee®-ID, eine Zigbee®-Device Network-ID, und/oder eine beliebige andere geeignete Netzwerkadresse und Komponenten davon. Der Begriff „Anwendungskennung“, „Anwendungs-ID“ oder „App-ID“ bezieht sich zumindest in einigen Ausführungsformen auf eine Kennung, die auf eine spezifische Anwendung oder Anwendungsinstanz abgebildet werden kann; im Kontext von 3GPP-5G/NR-Systemen kann sich eine „Anwendungskennung“ auf eine Kennung beziehen, die auf eine spezifische Anwendungsverkehrsdetektionsregel abgebildet werden kann. Eine „Endpunktadresse“ kann sich auf eine Adresse beziehen, die verwendet wird, um den Host/Autoritätsteil eines Ziel-URI zu bestimmen, wobei der Ziel-URI zum Zugreifen auf einen NF-Dienst (z. B. zum Aufrufen von Dienstoperationen) eines NF-Diensterzeugers oder für Benachrichtigungen an einen NF-Dienstkonsumenten verwendet wird. Der Begriff „CAG-ID“ bezieht sich zumindest in einigen Ausführungsformen auf eine Kennung einer geschlossenen Zugangsgruppe (CAG), und der Begriff „geschlossene Zugangsgruppe“ oder „CAG“ bezieht sich zumindest in einigen Ausführungsformen auf eine Gruppe von Listen von Benutzern, denen es erlaubt ist, eine Verbindung mit einem spezifischen Netzwerk und/oder einem spezifischen Zugangsnetzwerk herzustellen und/oder darauf zuzugreifen und/oder sich an eine spezifische Zelle oder einen spezifischen Netzwerkzugangsknoten anzuschließen. Geschlossene Zugangsgruppen (CAGs) werden manchmal als Zugangskontrolllisten (ACLs - Access Control Lists), geschlossene Teilnehmergruppen (CSGs - Closed Subscriber Groups), geschlossene Benutzergruppen (CUGs - Closed User Groups) und dergleichen bezeichnet. Der Begriff „Port“, wie hierin (z. B. im Kontext von Computernetzen) verwendet, bezieht sich zumindest in einigen Ausführungsformen auf einen Kommunikationsendpunkt, eine virtuelle Datenverbindung zwischen zwei oder mehr Entitäten und/oder einen virtuellen Punkt, an dem Netzwerkverbindungen beginnen und enden; zusätzlich oder alternativ dazu ist ein „Port“ mit einem spezifischen Prozess oder Dienst assoziiert.
  • Der Begriff „Teilnetzwerk“ oder „Teilnetz“ bezieht sich zumindest in einigen Ausführungsformen auf eine logische Unterteilung eines Netzwerks, wie etwa eines IP-Netzwerks. Die Praxis, ein Netzwerk in zwei oder mehr Netzwerke aufzuteilen, wird als „Teilnetzbildung“ bezeichnet. Der Begriff „Netzmaske“ oder „Teilnetzmaske“ bezieht sich zumindest in einigen Ausführungsformen auf eine Bitmaske, die durch bitweise UND-Verknüpfungen auf eine Netzwerkadresse (z. B. eine IP-Adresse in einem IP-Netzwerk) angewendet wird, um ein Routing-Präfix zu erhalten, und/oder ist eine 32-Bit-„Maske“, die verwendet wird, um eine IP-Adresse in Teilnetze aufzuteilen und die verfügbaren Hosts des Netzwerks zu spezifizieren.
  • Der Begriff „kryptographische Hashfunktion“, „Hashfunktion“ oder „Hash“) bezieht sich zumindest in einigen Ausführungsformen auf einen mathematischen Algorithmus, der Daten beliebiger Größe (manchmal als eine „Nachricht“ bezeichnet) auf ein Bitarray einer festen Größe (manchmal als ein „Hashwert“, „Hash“ oder „Nachrichtendigest“ bezeichnet) abbildet. Eine kryptographische Hash-Funktion ist üblicherweise eine Einwegfunktion, die eine Funktion ist, die praktisch nicht invertierbar ist. Der Begriff „Integrität“ bezieht sich zumindest in einigen Ausführungsformen auf einen Mechanismus, der sicherstellt, dass Daten nicht ohne Genehmigung geändert wurden. Beispiele für kryptographische Mechanismen, die zum Integritätsschutz verwendet werden können, umfassen digitale Signaturen, Nachrichtenauthentifizierungscodes (MAC) und sichere Hashes.
  • Der Begriff „Fluss“ bezieht sich zumindest in einigen Ausführungsformen auf eine Folge von Daten und/oder Dateneinheiten (z. B. Datagramme, Pakete oder dergleichen) von einer Quellenentität/einem Quellenelement zu einer Zielentität/einem Zielelement. Zusätzlich oder alternativ beziehen sich die Begriffe „Fluss“ oder „Verkehrsfluss“ zumindest in einigen Ausführungsformen auf ein künstliches und/oder logisches Äquivalent zu einem Anruf, einer Verbindung oder einem Link. Zusätzlich oder alternativ beziehen sich die Begriffe „Fluss“ oder „Verkehrsfluss“ zumindest in einigen Ausführungsformen auf eine Folge von Paketen, die von einer bestimmten Quelle zu einem bestimmten Unicast-, Anycast- oder Multicastziel gesendet wird und die die Quelle als einen Fluss kennzeichnen möchte; vom Gesichtspunkt der oberen Schichten kann ein Fluss alle Pakete in einer spezifischen Transportverbindung oder einem Medienstrom umfassen, wobei ein Fluss allerdings nicht notwendigerweise 1:1 auf eine Transportverbindung abgebildet wird. Zusätzlich oder alternativ beziehen sich die Begriffe „Fluss“ oder „Verkehrsfluss“ zumindest in einigen Ausführungsformen auf einen Satz von Daten und/oder Dateneinheiten (z. B. Datagramme, Pakete oder dergleichen), die einen Beobachtungspunkt in einem Netzwerk während eines gewissen Zeitintervalls passieren. Zusätzlich oder alternativ bezieht sich der Begriff „Fluss“ zumindest in einigen Ausführungsformen auf einen Benutzerebenen-Datenlink, der an eine Assoziation angehängt ist. Beispiele sind leitungsvermittelter Telefonanruf, Voice-Over-IP-Anruf, Empfang einer SMS, Senden einer Kontaktkarte, PDP-Kontext für Internetzugang, Demultiplexen eines TV-Kanals aus einem Kanalmultiplex, Berechnung von Positionskoordinaten aus Geopositionsbestimmungssatellitensignalen usw. Für Zwecke der vorliegenden Offenbarung können die Begriffe „Verkehrsfluss“, „Daten-Fluss“, „Datenfluss“, „Paketfluss“, „Netzwerkfluss“ und/oder „Fluss“ austauschbar verwendet werden, obwohl sich diese Begriffe auf unterschiedliche Konzepte beziehen können..
  • Der Begriff „Strom“ bezieht sich zumindest in einigen Ausführungsformen auf eine Folge von Datenelementen, die im Zeitablauf zur Verfügung gestellt werden. Funktionen, die einen Strom bearbeiten, der einen anderen Strom erzeugen kann, werden zumindest in einigen Ausführungsformen als „Filter“ bezeichnet und können analog zur Funktionszusammensetzung in Pipelines verbunden sein. Filter können jeweils ein Element eines Stroms bearbeiten oder können ein Ausgabeelement auf mehreren Eingabeelementen basieren, wie etwa einem gleitenden Mittelwert.
  • Der Begriff „verteilte Berechnungen“ bezieht sich zumindest in einigen Ausführungsformen auf ein Modell, in dem Komponenten, die sich auf vernetzten Computern befinden, kommunizieren und ihre Aktionen koordinieren, indem sie Nachrichten weiterleiten, die miteinander interagieren, um ein gemeinsames Ziel zu erreichen.
  • Der Begriff „Mikrodienst“ bezieht sich zumindest in einigen Ausführungsformen auf einen oder mehrere Prozesse, die über ein Netzwerk kommunizieren, um ein Ziel unter Verwendung technologieunabhängiger Protokolle (z. B. HTTP oder dergleichen) zu erfüllen. Zusätzlich oder alternativ bezieht sich der Begriff „Mikrodienst“ zumindest in einigen Ausführungsformen auf Dienste, die relativ klein in der Größe, nachrichtenübermittlungsfähig, durch Kontexte begrenzt, autonom entwickelt, unabhängig einsetzbar, dezentral und/oder mit automatisierten Prozessen aufgebaut und freigegeben sind. Zusätzlich oder alternativ bezieht sich der Begriff „Mikrodienst“ zumindest in einigen Ausführungsformen auf ein in sich geschlossenes Funktionalitätselement mit klaren Schnittstellen und kann eine Schichtarchitektur durch ihre eigenen internen Komponenten implementieren. Der Begriff „Mikrodienstarchitektur“ bezieht sich zumindest in einigen Ausführungsformen auf eine Variante des Strukturmodells der diensteorientierten Architektur (SOA), wobei Anwendungen als eine Sammlung lose gekoppelter Dienste (z. B. feinkörniger Dienste) angeordnet sind und leichte Protokolle verwenden können.
  • Der Begriff „Time to Live“ (oder „TTL“) oder „Hop Limit“ bezieht sich zumindest in einigen Ausführungsformen auf einen Mechanismus, der die Lebensdauer oder Lebenszeit von Daten in einem Computer oder Netzwerk begrenzt. TTL kann als ein Zähler oder Zeitstempel implementiert sein, der an die Daten angehängt oder in diese eingebettet ist. Sobald die vorgeschriebene Ereigniszählung oder Zeitspanne abgelaufen ist, werden Daten verworfen oder revalidiert.
  • Der Begriff „Warteschlange“ bezieht sich zumindest in einigen Ausführungsformen auf eine Sammlung von Entitäten (z. B. Daten, Objekte, Ereignisse usw.), die gespeichert und gehalten werden, um später verarbeitet zu werden, die in einer Folge beibehalten werden und durch das Hinzufügen von Entitäten an einem Ende der Folge und das Entfernen von Entitäten vom anderen Ende der Folge modifiziert werden können; das Ende der Folge, an dem Elemente hinzugefügt werden, kann als „hinterer Teil“, „letzte Stelle“ oder „Schluss“ der Warteschlange bezeichnet werden, und das Ende, an dem Elemente entfernt werden, kann als „Kopf“ oder „Anfang“ der Warteschlange bezeichnet werden. Zusätzlich dazu kann eine Warteschlange die Funktion eines Puffers erfüllen und die Begriffe „Warteschlange“ und „Puffer“ können durch die vorliegende Offenbarung hindurch austauschbar verwendet werden. Der Begriff „Einreihen in eine Warteschlange“ bezieht sich zumindest in einigen Ausführungsformen auf eine oder mehrere Operationen des Hinzufügens eines Elements am Schluss einer Warteschlange. Der Begriff „Entfernen aus der Warteschlange“ bezieht sich zumindest in einigen Ausführungsformen auf eine oder mehrere Operationen zum Entfernen eines Elements vom Anfang einer Warteschlange.
  • Der Begriff „Warteschlangenverzögerung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Zeitdauer, in der ein Auftrag in einer Warteschlange wartet, bis dieser Auftrag ausgeführt werden kann. Zusätzlich oder alternativ bezieht sich der Begriff „Warteschlangenverzögerung“ zumindest in einigen Ausführungsformen auf eine Zeitdauer, in der ein Paket in einer Warteschlange wartet, bis es verarbeitet und/oder übertragen werden kann. Der Begriff „Paketverzögerung“ bezieht sich zumindest in einigen Ausführungsformen auf die Zeit, die benötigt wird, um ein beliebiges Paket von einem Punkt zu einem anderen zu übertragen. Zusätzlich oder alternativ bzieht sich der Begriff „Paketverzögerung“ oder „Pro-Paket-Verzögerung“ zumindest in einigen Ausführungsformen auf die Differenz zwischen einer Paketempfangszeit und einer Paketsendezeit. Zusätzlich oder alternativ dazu kann die „Paketverzögerung“ oder „Pro-Paket-Verzögerung“ gemessen werden, indem die Paketsendezeit von der Paketempfangszeit subtrahiert wird, wobei der Sender und der Empfänger zumindest etwas synchronisiert sind. Der Begriff „Verarbeitungsverzögerung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Zeitdauer, die benötigt wird, um ein Paket in einem Netzwerkknoten zu verarbeiten. Der Begriff „Übertragungsverzögerung“ bezieht sich zumindest in einigen Ausführungsformen auf eine Zeitdauer, die benötigt wird (oder notwendig ist), um ein Paket (oder alle Bits eines Pakets) in ein Übertragungsmedium zu schieben. Der Begriff „Propagationsverzögerung“ bezieht sich zumindest in einigen Ausführungsformen auf die Zeitdauer, die der Header eines Signals benötigt, um sich von einem Sender zu einem Empfänger zu bewegen. Der Begriff „Netzwerkverzögerung“ bezieht sich zumindest in einigen Ausführungsformen auf die Verzögerung einer Dateneinheit innerhalb eines Netzwerks (z. B. eines IP-Pakets innerhalb eines IP-Netzwerks).
  • Der Begriff „Verzögerungsgrenze“ bezieht sich zumindest in einigen Ausführungsformen auf einen vorbestimmten oder konfigurierten Betrag akzeptabler Verzögerung. Der Begriff „Pro-Paket-Verzögerungsgrenze“ bezieht sich zumindest in einigen Ausführungsformen auf einen vorbestimmten oder konfigurierten Betrag akzeptabler Paketverzögerung, wobei Pakete, die nicht innerhalb der Verzögerungsgrenze verarbeitet und/oder übertragen werden, als Lieferausfälle betrachtet werden und gelöscht oder verworfen werden.
  • Der Begriff „Paketverwerfungsrate“ bezieht sich zumindest in einigen Ausführungsformen auf einen Anteil von Paketen, der aufgrund einer hohen Verkehrslast oder Verkehrsverwaltung nicht an das Ziel gesendet wurde und als Teil der Paketverwerfungsrate angesehen werden sollte. Der Begriff „Paketverlustrate“ bezieht sich zumindest in einigen Ausführungsformen auf einen Anteil von Paketen, der nicht durch das Ziel empfangen werden konnte und der Pakete, die verworfen werden, Pakete, die bei der Übertragung verloren gehen, und Pakete umfasst, die im falschen Format empfangen werden. Der Begriff „Latenz“ bezieht sich zumindest in einigen Ausführungsformen auf die Zeitdauer, die benötigt wird, um eine erste/anfängliche Dateneinheit in einem Datenburst von einem Punkt zu einem anderen zu übertragen.
  • Obwohl viele der vorherigen Beispiele unter Verwendung spezieller zellularer/mobiler Netzwerkterminologie bereitgestellt wurden, einschließlich der Verwendung von 4G/5G-3GPP-Netzwerkkomponenten (oder erwarteten 6G/6G+ Technologien auf Terahertzbasis), versteht es sich, dass diese Beispiele auf viele andere Bereitstellungen von Weitverkehrs- und lokalen drahtlosen Netzwerken sowie die Integration von drahtgebundenen Netzwerken (einschließlich optischer Netzwerke und zugehöriger Fasern, Sendeempfänger usw.) angewendet werden können.
  • Obwohl diese Implementierungen unter Bezugnahme auf spezifische Beispiele beschrieben wurden, versteht es sich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzumfang der vorliegenden Offenbarung abzuweichen. Viele der hier beschriebenen Anordnungen und Prozesse können in Kombination oder in parallelen Implementierungen verwendet werden, um größere Bandbreite/Durchsatz bereitzustellen und Edge-Dienstauswahlmöglichkeiten zu unterstützen, die den bedienten Edge-Systemen zur Verfügung gestellt werden können. Entsprechend sind die Beschreibung und die Zeichnungen in einem veranschaulichenden und nicht in einem einschränkenden Sinne aufzufassen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen spezielle Aspekte, in denen der Gegenstand ausgeführt werden kann, als Veranschaulichung und nicht als Beschränkung. Die veranschaulichten Aspekte sind hinreichend detailliert beschrieben, um einen Fachmann zu befähigen, die hier offenbarten Lehren auszuüben. Andere Aspekte können genutzt und aus diesen abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne den Schutzumfang dieser Offenbarung zu verlassen. Diese ausführliche Beschreibung ist daher nicht in einem beschränkenden Sinn aufzufassen und der Schutzumfang verschiedener Aspekte ist nur durch die angehängten Ansprüche, zusammen mit dem vollen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigt sind, definiert.
  • Solche Aspekte des Erfindungsgegenstands können hierin lediglich der Einfachheit halber und ohne die Absicht, den Schutzumfang dieser Anmeldung willentlich auf einen einzigen Aspekt oder Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart sind, einzeln oder zusammen erwähnt sein. Obwohl spezielle Aspekte hierin veranschaulicht und beschrieben wurden, sollte man daher verstehen, dass eine beliebige Einrichtung, die berechnet ist, um denselben Zweck zu erfüllen, die gezeigten speziellen Ausführungsformen ersetzen kann. Diese Offenbarung soll jegliche Anpassungen oder Variationen verschiedener Aspekte abdecken. Kombinationen der obigen Aspekte und andere Aspekte, die hierin nicht speziell beschrieben sind, ergeben sich für Fachleute bei der Durchsicht der oben stehenden Beschreibung.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 63/077495 [0001]
    • US 63/078782 [0001]

Claims (25)

  1. Einrichtung, die als ein erster Mehrfachzugangsrechenknoten zum Verwalten von Verkehr für Mehrfachzugangskommunikation in einer Mehrfachzugangskommunikationsumgebung eingesetzt wird, wobei die Vorrichtung umfasst: eine Prozessorschaltungsanordnung, die dazu konfiguriert ist, eine Anwendung zum Erzeugen von Daten auszuführen, die an einen zweiten Mehrfachzugangsrechenknoten übermittelt werden sollen; und eine Kommunikationsschaltungsanordnung, die mit der Prozessorschaltungsanordnung gekoppelt ist, wobei die Kommunikationsschaltungsanordnung konfiguriert ist zum: Erhalten der Daten von der Anwendung; Bestimmen eines Pro-Paket-Priorisierungs-(PPP-)Wertes für eine Dateneinheit basierend auf einer oder mehreren PPP-Regeln, die in einer PPP-Konfiguration definiert sind, und Erzeugen der Dateneinheit einschließlich des bestimmten PPP-Wertes und der Daten von der Anwendung, und Übertragen der erzeugten Dateneinheit an den zweiten Mehrfachzugangsrechenknoten.
  2. Einrichtung nach Anspruch 1, wobei die eine oder die mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einer Dateneinheitsgröße basiert, und die Kommunikationsschaltungsanordnung zum Bestimmen des PPP-Wertes ausgelegt ist zum: Bestimmen einer Größe der Dateneinheit; und Bestimmen, aus der PPP-Konfiguration, des PPP-Wertes, der einem Dateneinheitsgrößenbereich entspricht, der die bestimmte Größe der Dateneinheit umfasst.
  3. Einrichtung nach Anspruch 1 oder 2, wobei die eine oder die mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einem Dateneinheitsgrößencode basiert, und die Kommunikationsschaltungsanordnung zum Bestimmen des PPP-Wertes ausgelegt ist zum: Bestimmen des PPP-Wertes unter Verwendung eines Codierungsschemas, das in der PPP-Konfiguration definiert ist.
  4. Einrichtung nach Anspruch 3, wobei das Codierungsschema eine Modulo-Operation ist, und die Kommunikationsschaltungsanordnung zum Bestimmen des PPP-Wertes ausgelegt ist zum: Bestimmen einer Größe der Dateneinheit; und Bestimmen des PPP-Wertes als einen Modul von S Modulo K, wobei S die Größe der Dateneinheit ist und K eine Anzahl von Prioritätsstufen ist, die in der PPP-Konfiguration definiert ist.
  5. Einrichtung nach Anspruch 1 bis 4, wobei die eine oder die mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einem generischen Nutzlasttyp (GPT) basiert, und die Kommunikationsschaltungsanordnung zum Bestimmen des PPP-Wertes ausgelegt ist zum: Bestimmen eines Satzes von GPT-Parametern; und Bestimmen, aus der PPP-Konfiguration, des PPP-Wertes, der dem bestimmten Satz von GPP-Parametern entspricht, wobei der Satz von GPT-Parametern einen GPT-Offset, eine GPT-Länge und einen GPT-Wert umfasst.
  6. Einrichtung nach Anspruch 1 bis 5, wobei die eine oder die mehreren PPP-Regeln eine PPP-Regel umfassen, die auf einer Flussrate basierend, und die Kommunikationsschaltungsanordnung zum Bestimmen des PPP-Wertes ausgelegt ist zum: Bestimmen einer Flussrate für die Dateneinheit; und Bestimmen, aus der PPP-Konfiguration, des PPP-Wertes, der einem Flussratenbereich entspricht, der die bestimmte Flussrate umfasst.
  7. Einrichtung nach Anspruch 1 bis 6, wobei die PPP-Konfiguration ferner einen oder mehrere Flussklassifizierungsparameter, die verwendet werden sollen, um einen Fluss zu identifizieren, für den die eine oder mehreren PPP-Regeln anwendbar sind, und eine Anzahl von Prioritätsstufen umfasst.
  8. Einrichtung nach Anspruch 1 bis 7, wobei die Kommunikationsschaltungsanordnung ferner ausgelegt ist zum: Senden einer ersten Steuernachricht an den zweiten Mehrfachzugangsrechenknoten, wobei die erste Steuernachricht Unterstützung einer PPP-Fähigkeit durch den ersten Mehrfachzugangsrechenknoten angibt; Empfangen einer zweiten Steuernachricht vom zweiten Mehrfachzugangsrechenknoten; und Erzeugen der Dateneinheit, so dass sie den PPP-Wert umfasst, wenn die zweite Steuernachricht Unterstützung der PPP-Fähigkeit durch den zweiten Mehrfachzugangsrechenknoten angibt.
  9. Einrichtung nach einem der Ansprüche 1 bis 8, wobei die Mehrfachzugangskommunikationsumgebung eine Mehrfachzugangsverwaltungsdienst-(MAMS-)Kommunikationsumgebung ist, die ein Mehrfachzugangsverwaltungsdienst-(MAMS-)Framework umfasst.
  10. Einrichtung nach Anspruch 9, wobei der erste Mehrfachzugangs-(MX-)Rechenknoten eine Client-Vorrichtung ist, der zweite MX-Rechenknoten ein Server ist, die erste Steuernachricht eine MX-Fähigkeitsanforderungsnachricht (mx_capability_req) ist, und die zweite Steuernachricht eine MX-Fähigkeitsantwortnachricht (mx_capability_rsp) ist, und die Kommunikationsschaltungsanordnung ferner konfiguriert ist zum: Empfangen einer MX-PPP-Konfigurationsanforderungsnachricht (mx_ppp_config_req), wenn mx_capability _rsp Unterstützung der PPP-Fähigkeit angibt, wobei mx_ppp_config_req die PPP-Konfiguration enthält.
  11. Einrichtung nach Anspruch 9, wobei der erste MX-Rechenknoten ein Server ist, der zweite MX-Rechenknoten eine Client-Vorrichtung ist, die erste Steuernachricht eine mx_capability_rsp ist und die zweite Steuernachricht eine mx_capability_req ist, und die Kommunikationsschaltungsanordnung ferner konfiguriert ist zum: Empfangen einer MX-PPP-Konfigurationsantwortnachricht (mx_ppp_config_rsp), wenn mx_capability_req Unterstützung der PPP-Fähigkeit angibt, wobei mx_ppp_config_rsp die PPP-Konfiguration umfasst.
  12. Zugangsschichtschaltungsanordnung eines ersten Mehrfachzugangsrechenknotens, die umfasst: Mittel zum Erhalten von Daten von einer Anwendung, die innerhalb einer Anwendungsschicht eines Protokollstapels arbeitet, der auch die Zugangsschicht umfasst; Mittel zum Bestimmen eines Pro-Paket-Priorisierungs-(PPP-)Wertes für eine Dateneinheit basierend auf einer oder mehreren PPP-Regeln, die in einer PPP-Konfiguration enthalten sind; Mittel zum Erzeugen der Dateneinheit, so dass sie ein Feld generischer Nutzlast (GPT) und die Daten von der Anwendung umfasst, wobei das GPT-Feld den bestimmten PPP-Wert umfasst; und Mittel zum Übertragen der erzeugten Dateneinheit an einen zweiten Mehrfachzugangsrechenknoten.
  13. Zugangsschichtschaltungsanordnung nach Anspruch 12, wobei das Mittel zum Erzeugen der Dateneinheit ferner ist zum: Erzeugen des GPT-Feldes innerhalb eines Nutzlastabschnitts der Dateneinheit gemäß einem GPT-Offset und einer GPT-Länge, der GPT-Offset eine Anzahl von Bits oder Bytes von einem Ende eines Header-Abschnitts der Dateneinheit bis zu einem Anfang des GPT-Feldes ist, und die GPT-Länge eine Anzahl von Bits oder Bytes des GPT-Feldes ist.
  14. Zugangsschichtschaltungsanordnung nach Anspruch 13, wobei das Mittel zum Erzeugen der Dateneinheit ferner ist zum: Erzeugen des GPT-Feldes innerhalb der Dateneinheit ferner gemäß einer GPT-Dienstqualitäts-(QoS-)Klassenzuordnung, wobei die QoS-Klassenzuordnung eine Anzahl von QoS-Klassen und für jede QoS-Klasse der Anzahl von QoS-Klassen einen QoS-Klassenwert und einen GPT-Wertebereich angibt, wobei der bestimmte PPP-Wert ein QoS-Klassenwert ist, der einer QoS-Klasse der Anzahl von QoS-Klassen entspricht.
  15. Zugangsschichtschaltungsanordnung nach Anspruch 14, ferner umfassend: Mittel zum Identifizieren, aus einer GPT-Intraflussklassifizierungskonfiguration, des GPT-Offsets, der GPT-Länge, der GPT-QoS-Klassenzuordnung und von Intraflussklassifizierungsinformationen, wobei die Intraflussklassifizierungsinformationen Informationen umfassen, die zum Identifizieren von Teilflüssen verwendet werden, die einen Fluss bilden, zu dem die Dateneinheit gehört.
  16. Zugangsschichtschaltungsanordnung nach Anspruch 15, ferner umfassend: Mittel zum Erhalten der GPT-Intraflussklassifizierungskonfiguration von der Anwendung über eine Intraflussklassifizierungs-Anwendungsprogrammierungsschnittstelle (API), wobei die GPT-Intraflussklassifizierungs-API eine Schnittstelle zwischen der Anwendungsschicht und der Zugangsschicht ist.
  17. Zugangsschichtschaltungsanordnung nach Anspruch 15 oder 16, wobei die GPT-Intraflussklassifizierungskonfiguration ferner eine Pro-Paket-Verzögerungsgrenze umfasst, wobei die Pro-Paket-Verzögerungsgrenze auf einen Wert gesetzt ist, der einer QoS-Anforderung eines Verkehrsstroms entspricht, zu dem die Dateneinheit gehört.
  18. Verfahren zur aktiven Warteschlangenverwaltung (AQM), wobei das Verfahren umfasst: Entfernen einer Dateneinheit aus einer Übertragungswarteschlange; Bestimmen eines Pro-Packet-Priorisierungs-(PPP)-Wertes für die aus der Warteschlange entfernte Dateneinheit basierend auf einer PPP-Markierung der aus der Warteschlange entfernten Dateneinheit; Verwerfen der aus der Warteschlange entfernten Dateneinheit in Reaktion auf die Detektion einer Verkehrsüberlastungsbedingung, wenn der PPP-Wert angibt, dass die Dateneinheit eine niedrigere Priorität als andere Dateneinheiten in der Übertragungswarteschlange aufweist; und Übertragen der aus der Warteschlange entfernten Dateneinheit an den zweiten Mehrfachzugangsrechenknoten, wenn die aus der Warteschlange entfernten Dateneinheit nicht verworfen wird.
  19. Verfahren nach Anspruch 18, ferner umfassend: Verwerfen der aus der Warteschlange entfernten Dateneinheit, wenn das Verwerfen der aus der Warteschlange entfernten Dateneinheit eine Pro-Paket-Verzögerungsgrenze verletzt, wobei die Pro-Paket-Verzögerungsgrenze in einer PPP-Konfiguration definiert ist.
  20. Verfahren nach Anspruch 19, wobei das Verwerfen der aus der Warteschlange entfernten Dateneinheit umfasst: Verwerfen der aus der Warteschlange entfernten Dateneinheit, wenn eine aktuelle Warteschlangenverzögerung der aus der Warteschlange entfernten Dateneinheit größer als eine gewichtete Warteschlangenverzögerung ist, wobei die gewichtete Warteschlangenverzögerung auf der Pro-Paket-Verzögerungsgrenze und einer Gewichtung basiert, die auf den PPP-Wert angewendet wird.
  21. Verfahren nach Anspruch 18 bis 20, wobei das Verwerfen der aus der Warteschlange entfernten Dateneinheit umfasst: Verwerfen der aus der Warteschlange entfernten Dateneinheit, wenn eine aktuelle Warteschlangengröße der Warteschlange größer als eine gewichtete Warteschlangengröße ist, wobei die gewichtete Warteschlangengröße auf einer vordefinierten oder konfigurierten Warteschlangengrößengrenze und einer Gewichtung basiert, die auf den PPP-Wert angewendet wird.
  22. Verfahren nach Anspruch 18 bis 21, wobei das Verwerfen der aus der Warteschlange entfernten Dateneinheit umfasst: Verwerfen der aus der Warteschlange entfernten Dateneinheit und einer Anzahl von aus der Warteschlange entfernten Dateneinheiten mit demselben PPP-Wert wie die aus der Warteschlange entfernte Dateneinheit, wenn die Anzahl von aus der Warteschlange entfernten Dateneinheiten mit demselben PPP-Wert wie die aus der Warteschlange entfernte Dateneinheit größer oder gleich einem Verwerfungsparameter ist.
  23. Verfahren nach Anspruch 18 bis 22, wobei die Mehrfachzugangskommunikationsumgebung eine Mehrfachzugangsverwaltungsdienst-(MAMS-)Kommunikationsumgebung ist, die ein Mehrfachzugangsverwaltungsdienst-(MAMS-)Framework umfasst.
  24. Verfahren nach Anspruch 18 bis 23, wobei der erste Mehrfachzugangsrechenknoten eines von einer Client-Vorrichtung, einem Netzwerkzugangsknoten, einem Edge-Rechenknoten oder einem Server ist; und der zweite Mehrfachzugangsrechenknoten eines von einer Client-Vorrichtung, einem Netzwerkzugangsknoten, einem Edge-Rechenknoten oder einem Server ist.
  25. Nichtflüchtiges computerlesbares Medium (NTCRM), das Anweisungen umfasst, wobei die Ausführung der Anweisungen durch einen oder mehrere Prozessoren eines Mehrfachzugangsrechenknotens den Mehrfachzugangsrechenknoten zum Durchführen des Verfahrens nach Anspruch 18 bis 24 veranlasst.
DE102021209988.2A 2020-09-11 2021-09-09 Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen Pending DE102021209988A1 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202063077495P 2020-09-11 2020-09-11
US63/077,495 2020-09-11
US202063078782P 2020-09-15 2020-09-15
US63/078,782 2020-09-15
US17/469,331 2021-09-08
US17/469,331 US20210409335A1 (en) 2020-09-11 2021-09-08 Multi-access management service packet classification and prioritization techniques

Publications (1)

Publication Number Publication Date
DE102021209988A1 true DE102021209988A1 (de) 2022-03-17

Family

ID=79030548

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021209988.2A Pending DE102021209988A1 (de) 2020-09-11 2021-09-09 Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen

Country Status (4)

Country Link
US (1) US20210409335A1 (de)
KR (1) KR20220034699A (de)
CN (1) CN114173374A (de)
DE (1) DE102021209988A1 (de)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10909866B2 (en) * 2018-07-20 2021-02-02 Cybernet Systems Corp. Autonomous transportation system and methods
KR20210075999A (ko) * 2018-10-17 2021-06-23 구글 엘엘씨 코어 네트워크 유형 선택
US11171843B2 (en) * 2019-11-29 2021-11-09 Amazon Technologies, Inc. Multi-carrier access to provider substrate extensions
US11190457B2 (en) * 2020-02-19 2021-11-30 At&T Intellectual Property I, L.P. Selectively bypassing a routing queue in a routing device in a fifth generation (5G) or other next generation network
US11246055B1 (en) * 2020-09-17 2022-02-08 Hewlett Packard Enterprise Development Lp Consistent quality of service policy in a software defined enterprise network
US11601533B1 (en) * 2020-09-28 2023-03-07 Amazon Technologies, Inc. Source port adaptive multi-path (SAM) protocol
US11606316B2 (en) * 2020-11-20 2023-03-14 Qualcomm Incorporated System and method for modem stabilization when waiting for AP-driven link recovery
US11382033B2 (en) * 2020-11-30 2022-07-05 Verizon Patent And Licensing Inc. Systems and methods for performance-aware energy saving in a radio access network
US11722561B2 (en) * 2020-12-22 2023-08-08 Telefonaktiebolaget Lm Ericsson (Publ) DTLS/SCTP enhancements for RAN signaling purposes
US11758460B1 (en) * 2021-02-02 2023-09-12 T-Mobile Usa, Inc. Managing local application connectivity in a multi-network environment
US20220248255A1 (en) * 2021-02-03 2022-08-04 Qualcomm Incorporated Group-based wireless communications
US11606317B1 (en) * 2021-04-14 2023-03-14 Xilinx, Inc. Table based multi-function virtualization
CN115529336A (zh) * 2021-06-25 2022-12-27 华为技术有限公司 数据传输的方法、系统、设备和存储介质
US20230028934A1 (en) * 2021-07-13 2023-01-26 Vmware, Inc. Methods and decentralized systems that employ distributed machine learning to automatically instantiate and manage distributed applications
US11610478B2 (en) * 2021-08-09 2023-03-21 Peltbeam Inc. Communication system and method for controlling cooperation between edge devices arranged in vehicle
US11606267B1 (en) * 2021-09-10 2023-03-14 Microsoft Technology Licensing, Llc Detecting and quantifying latency components in accessing cloud services
US11848909B2 (en) * 2021-09-21 2023-12-19 Nokia Technologies Oy Restricting onboard traffic
US20230093193A1 (en) * 2021-09-21 2023-03-23 Verizon Patent And Licensing Inc. Systems and methods for indicating the presence of a multi-access edge computing application
US20230198944A1 (en) * 2021-12-22 2023-06-22 Palo Alto Networks, Inc. Networking and security split architecture
US11606249B1 (en) * 2022-01-19 2023-03-14 Dell Products L.P. System and method for communication management in distributed system
CN114726767B (zh) * 2022-02-28 2024-01-02 深圳震有科技股份有限公司 一种web服务响应异常检测方法、装置及存储介质
TWI787095B (zh) * 2022-03-09 2022-12-11 緯創資通股份有限公司 調整無線接取網路資源的方法、裝置及相關無線接取網路
TWI795274B (zh) * 2022-04-21 2023-03-01 中華電信股份有限公司 基於傳輸控制協定封包標頭的雜湊值決定用戶平面功能服務模組的方法及系統
US20230362974A1 (en) * 2022-05-05 2023-11-09 At&T Intellectual Property I, L.P. Intelligent antenna adaptive directed beamforming based on totality of circumstances
CN114938244A (zh) * 2022-05-07 2022-08-23 重庆邮电大学 基于协作传输的室内vlc网络的时频资源分配方法
CN117240358A (zh) * 2022-06-07 2023-12-15 华为技术有限公司 光通信网络的上线方法及装置
US20240007407A1 (en) * 2022-07-04 2024-01-04 Morgen Technology Inc. Tunneling of short-range sensor data through long-range wireless technology
CN115208470A (zh) * 2022-07-07 2022-10-18 重庆邮电大学 基于模糊逻辑的混合多址接入vlc网络的资源分配方法
WO2024027917A1 (en) * 2022-08-04 2024-02-08 Huawei Technologies Co., Ltd. Application-level payload data processing at the user plane
US20240064555A1 (en) * 2022-08-19 2024-02-22 Nec Laboratories America, Inc. Lan-aware quality of service orchestration
US11729142B1 (en) * 2022-08-25 2023-08-15 Google Llc System and method for on-demand edge platform computing
CN115130929B (zh) * 2022-08-29 2022-11-15 中国西安卫星测控中心 基于机器学习分类的资源池智能生成方法
US20240073152A1 (en) * 2022-08-30 2024-02-29 Palo Alto Research Center Incorporated System and method using improved message queue and packing scheme for electronic device
US11792088B1 (en) * 2022-09-02 2023-10-17 Microsoft Technology Licensing, Llc Network management engine for a cloud computing system
CN115185667B (zh) * 2022-09-13 2022-12-20 天津市天河计算机技术有限公司 可视化应用的加速方法、装置、电子设备和存储介质
KR102516754B1 (ko) * 2022-10-28 2023-03-31 국방과학연구소 트리플-메트릭 우선순위 기반 트래픽 처리 방법 및 장치
CN118018625A (zh) * 2022-11-08 2024-05-10 中兴通讯股份有限公司 一种数据传输处理方法、装置、存储介质及电子装置
US11943328B1 (en) * 2022-11-29 2024-03-26 GM Global Technology Operations LLC Secure method and apparatus for mixed criticality services discovery in a vehicle
CN115907019B (zh) * 2023-01-09 2023-11-07 苏州浪潮智能科技有限公司 一种用于气象预测的量子计算机
CN116865952B (zh) * 2023-05-23 2024-02-20 江苏华存电子科技有限公司 一种数据的加密管理方法及系统
CN117176728A (zh) * 2023-07-04 2023-12-05 北京百星电子系统有限公司 基于云边协同技术的工业物联网调度方法及调度系统
CN117270007B (zh) * 2023-11-22 2024-01-30 北京凯芯微科技有限公司 卫星定位系统、嵌入式系统、芯片及嵌入式设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4549610B2 (ja) * 2001-11-08 2010-09-22 ソニー株式会社 通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラム
AU2003252736A1 (en) * 2002-07-30 2004-03-11 Nippon Telegraph And Telephone Corporation Re-challenge communication control method, system thereof, packet transfer enabled/disabled decision method, packet transfer device, packet transfer system, packet monitoring method, call control device, monitor device, and program
JP5197999B2 (ja) * 2007-06-18 2013-05-15 株式会社エヌ・ティ・ティ・ドコモ アクセス網切り替え方法、アクセス網切り替え装置及び移動機
WO2014110410A1 (en) * 2013-01-11 2014-07-17 Interdigital Patent Holdings, Inc. User-plane congestion management
JP6617769B2 (ja) * 2015-03-06 2019-12-11 ソニー株式会社 通信装置、通信方法およびプログラム
US11706657B2 (en) * 2016-05-26 2023-07-18 Parallel Wireless, Inc. End-to-end prioritization for mobile base station
US10735346B2 (en) * 2017-12-30 2020-08-04 Intel Corporation Data block prioritization for internet of things payloads
US11310161B2 (en) * 2019-08-12 2022-04-19 Verizon Patent And Licensing Inc. Method and system for packet size management
US11871273B2 (en) * 2019-11-07 2024-01-09 Huawei Technologies Co., Ltd. Systems and methods for user plane handling
KR20230050335A (ko) * 2020-08-11 2023-04-14 지티이 코포레이션 서비스 품질 흐름과의 전송 식별자의 연관
US20210385865A1 (en) * 2020-09-03 2021-12-09 Intel Corporation Intelligent transport system co-channel coexistence frame structure with asymmetric gap durations

Also Published As

Publication number Publication date
US20210409335A1 (en) 2021-12-30
KR20220034699A (ko) 2022-03-18
CN114173374A (zh) 2022-03-11

Similar Documents

Publication Publication Date Title
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
US20240163030A1 (en) Multi-access management services packet recovery mechanisms
US11627444B2 (en) Vehicle-to-everything session and service continuity in automotive edge computing systems
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE102022200847A1 (de) Bestärkendes lernen für mehrfachzugriffsverkehrsverwaltung
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
EP4203428A1 (de) Verbesserungen eines mehrfachzugangsverwaltungsdienstes für dienstqualität und zeitempfindliche anwendungen
DE102022211529A1 (de) Methoden zum einreihen und neuordnen für mehrfachzugangsverwaltungsdienste
DE102022202963A1 (de) Verkehrsaufteilungs- und neuübertragungsmechanismen mit schichtübergreifender und zugangsübergreifender technologie
DE112020003766T5 (de) Linkleistungsprognose und Medienstreaming-Technologien
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
DE112019002913T5 (de) Verwaltung von zuweisungen bevorzugter kanäle zwischendrahtloskommunikationsbändern
US20220174521A1 (en) Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
DE102020202398A1 (de) Edge-server-cpu mit dynamischer deterministischer skalierung
US20230353455A1 (en) Multi-access management service frameworks for cloud and edge networks
US20220150740A1 (en) Measuring the performance of a wireless communications network
DE102022211605A1 (de) Zuverlässigkeitsverbesserungen für mehrfachzugangsverkehrsverwaltung
EP3970408A1 (de) Technologien zur steuerung und verwaltung von mehreren verkehrssteuerdiensten
US20230006889A1 (en) Flow-specific network slicing
DE112020007003T5 (de) Multi-funkzugangstechnologie-verkehrsverwaltung
NL2033607B1 (en) Traffic steering and cross-layered and cross-link mobility management techniques for multi-access management services
DE102023200988A1 (de) Dynamische latenz-responsive cache-verwaltung
DE102021100660A1 (de) Netzwerkbasierte medienverarbeitung (nbmp) anwendungsunterstützung für netzwerkanalysedienste in 5g-systemen
US20240015569A1 (en) Quality of service management for 5g networks

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012700000

Ipc: H04L0045000000