DE112021007893T5 - Systeme und verfahren für iab-mec - Google Patents

Systeme und verfahren für iab-mec Download PDF

Info

Publication number
DE112021007893T5
DE112021007893T5 DE112021007893.3T DE112021007893T DE112021007893T5 DE 112021007893 T5 DE112021007893 T5 DE 112021007893T5 DE 112021007893 T DE112021007893 T DE 112021007893T DE 112021007893 T5 DE112021007893 T5 DE 112021007893T5
Authority
DE
Germany
Prior art keywords
iab
data
layer
mec
node
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
DE112021007893.3T
Other languages
English (en)
Inventor
Sarma V. Vangala
Sudeep Manithara Vamanan
Fangli XU
Haijing Hu
Krisztian Kiss
Mona Agnel
Naveen Kumar R Palle Venkata
Ralf Rossbach
Sethuraman Gurumoorthy
Yuqin Chen
Zhibin Wu
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.)
Apple Inc
Original Assignee
Apple Inc
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 Apple Inc filed Critical Apple Inc
Publication of DE112021007893T5 publication Critical patent/DE112021007893T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/28—Cell structures using beam steering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components

Landscapes

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

Abstract

Hierin werden Systeme und Verfahren zum Verwenden von integrierten Zugangs- und Backhaul-Knoten (IAB-Knoten) offenbart, die konfiguriert sind, um eine Multi-Access Edge Computing (MEC)-Funktionalität) bereitzustellen. Ein IAB-Knoten schließt eine verteilte Einheit (DU) mit einer lokalen Anwendungsinstanz einer MEC-fähigen Anwendung ein. Die lokale Anwendungsinstanz ist für die Kommunikation mit einer ersten Benutzerausrüstung (UE) konfiguriert, die mit dem IAB-Knoten verbunden ist. Eine mobile Terminierungsfunktionalität (MT) des IAB-Knotens nutzt eine Packet Data Convergence Protocol (PDCP)-Schicht), um Daten der lokalen Anwendungsinstanz zwischen der MT und einem IAB-Donor zu transportieren. Ferner werden Daten der lokalen Anwendungsinstanz zwischen der UE und dem IAB-Knoten über eines von einer Vielzahl von Verfahren transportiert, einschließlich der Verwendung einer zweiten PDCP-Schicht an der DU (und optional der Verwendung von Service Data Adaptation Protocol (SDAP)-Schichten) sowohl an der DU als auch an der MT) und/oder über Sidelink.

Description

  • TECHNISCHES GEBIET
  • Diese Anmeldung bezieht sich allgemein auf drahtlose Kommunikationssysteme, einschließlich Systeme und Verfahren zum Verwenden von integrierten Zugangs- und Backhaul-Knoten (Integrated Access and Backhaul-Knoten, IAB-Knoten), die konfiguriert sind, um eine Multi-Access Edge Computing (MEC)-Funktionalität am IAB-Knoten bereitzustellen.
  • HINTERGRUND
  • Die drahtlose Mobilkommunikationstechnologie verwendet verschiedene Standards und Protokolle, um Daten zwischen einer Basisstation und einer drahtlosen Kommunikationsvorrichtung zu übertragen. Drahtlos-Kommunikationssystemstandards und -protokolle können zum Beispiel das 3. Generation Partnership Project (3GPP) Long Term Evolution (LTE) (z. B. 4G), 3GPP New Radio (NR) (z. B. 5G) und den IEEE 802.11-Standard für drahtlose lokale Netzwerke (WLAN) (in Branchengruppen allgemein bekannt als Wi-Fi®) einschließen.
  • Wie durch das 3GPP in Betracht gezogen, können unterschiedliche Standards für drahtlose Kommunikationssysteme und Protokolle verschiedene Funkzugangsnetze (RANs) zum Kommunizieren zwischen einer Basisstation des RAN(was auch manchmal allgemein als RAN-Knoten, Netzknoten oder einfach ein Knoten bezeichnet werden kann) und einer drahtlosen Kommunikationsvorrichtung, die als Benutzerausrüstung (UE) bekannt ist, verwenden. 3 GPP-RANs können zum Beispiel ein globales System für mobile Kommunikation (GSM), verbesserte Datenraten für GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN) und/oder ein Funkzugangsnetz der nächsten Generation (NG-RAN) einschließen.
  • Jedes RAN kann eine oder mehrere Funkzugangstechnologien (RATs) verwenden, um eine Kommunikation zwischen der Basisstation und der UE durchzuführen. Zum Beispiel implementiert GERAN GSM und/oder EDGE RAT, UTRAN implementiert Universal Mobile Telecommunication System (UMTS) RAT oder eine andere 3GPP RAT, E-UTRAN implementiert LTE RAT (manchmal einfach als LTE bezeichnet) und NG-RAN implementiert NR RAT (manchmal hierin als 5G RAT, 5G NR RAT oder einfach NR bezeichnet). In bestimmten Bereitstellungen kann E-UTRAN auch NR RAT implementieren. In bestimmten Bereitstellungen kann NG-RAN auch LTE RAT implementieren.
  • Eine Basisstation, die von einem RAN verwendet wird, kann diesem RAN entsprechen. Ein Beispiel für eine E-UTRAN-Basisstation ist ein Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN-Knoten B) (auch allgemein als entwickelter Knoten B, erweiterter Knoten B, eNodeB oder eNB bezeichnet). Ein Beispiel für eine NG-RAN-Basisstation ist ein Next Generation Node B (auch manchmal als ein oder g Node B oder gNB bezeichnet).
  • Ein RAN stellt seine Kommunikationsdienste mit externen Entitäten durch ihre Verbindung zu einem Kernnetz (CN) bereit. Zum Beispiel kann E-UTRAN einen Evolved Packet Core (EPC) verwenden, während NG-RAN ein 5G-Kernnetz (5GC) verwenden kann.
  • KURZBESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNGEN
  • Um die Erörterung eines bestimmten Elements oder einer bestimmten Aktion einfach zu identifizieren, beziehen sich die höchste Ziffer oder die höchsten Ziffern in einer Bezugsnummer auf die Figurennummer, in der dieses Element zuerst eingeführt wird.
    • 1 veranschaulicht ein IAB-Netzwerk gemäß einer Ausführungsform.
    • 2 veranschaulicht eine Benutzerebenenprotokollarchitektur für IAB gemäß einer Ausführungsform.
    • 3 veranschaulicht ein IAB-Netzwerk gemäß einer Ausführungsform.
    • 4 veranschaulicht ein IAB-Netzwerk gemäß einer Ausführungsform.
    • 5 veranschaulicht ein IAB-Netzwerk gemäß einer Ausführungsform.
    • 6 veranschaulicht ein IAB-Netzwerk gemäß einer Ausführungsform.
    • 7 veranschaulicht ein System zur Kommunikation zwischen einer lokalen Anwendungsinstanz auf einer IAB MEC und einem Anwendungsclient auf einer UE unter Verwendung einer Zugangsverbindung gemäß Sidelink (SL)-Gesichtspunkten gemäß einer Ausführungsform.
    • 8 veranschaulicht ein Verfahren eines IAB-Knotens gemäß einer Ausführungsform.
    • 9 veranschaulicht eine Beispielarchitektur eines drahtlosen Kommunikationssystems gemäß hierin offenbarten Ausführungsformen.
    • 10 veranschaulicht ein System zum Durchführen einer Signalisierung zwischen einer drahtlosen Vorrichtung und einer Netzwerkvorrichtung gemäß hierin offenbarten Ausführungsformen.
  • DETAILLIERTE BESCHREIBUNG
  • Verschiedene Ausführungsformen werden in Hinsicht auf eine UE beschrieben. Die Bezugnahme auf eine UE wird jedoch lediglich zu veranschaulichenden Zwecken bereitgestellt. Die Ausführungsbeispiele können mit jeder elektronischen Komponente genutzt werden, die eine Verbindung mit einem Netzwerk herstellen kann und mit der Hardware, Software und/oder Firmware konfiguriert ist, um Informationen und Daten mit dem Netzwerk auszutauschen. Deshalb wird die hierin beschriebene UE verwendet, um eine beliebige elektronische Komponente zu repräsentieren.
  • Ein drahtloses Millimeterwellen-Netz (mmWave) kann Glasfaser-Backhaul verwenden, um den Datenverkehr mit NR-Geschwindigkeiten zu übertragen. Es kann jedoch schwierig oder kostspielig sein, Glasfaser-Backhaul für die vielen Knoten bereitzustellen, die für die mmWave-Abdeckung verwendet werden. In bestimmten Systemen können integrierter Zugang und Backhaul (IAB) verwendet werden, um die Implementierungskosten von ultradichten NRmmWave-Netzen zu überwinden, indem drahtlose Backhaul-Verbindungen zur Weiterleitung des Zugangsverkehrs realisiert werden.
  • IAB-Architekturen ermöglichen Multi-Hop-Routing, bei dem jeder der hierarchisch angeordneten IAB-Knoten sowohl als Zugangsknoten für UEs dient als auch drahtlose Backhaul-Verbindungen zu anderen IAB-Knoten und/oder einem IAB-Donor bereitstellt, der mit einem CN verbunden ist. Auf den drahtlosen Backhauls kann eine BAP-Schicht (Backhaul Adaptation Protocol) das Routing über mehrere Hops durch das System ermöglichen. Der BAP ermöglicht es den IAB-Knoten und/oder dem IAB-Donor, miteinander zu kommunizieren, und stellt eine Anzahl von Funktionalitäten bereit, die zum Beispiel das Zuordnen von RLC-Kanälen (Radio Link Control) zum nächsten Hop, das Routing zum IAB-Knoten/IAB-Donor des nächsten Hop basierend auf Verkehrsdifferenzierung, das Angeben von Netzwerkereignissen (z. B. Ausfall der Funkverbindung (radio link failure (RLF)), Datenübertragung und/oder Flusssteuerungs-Rückkopplungssignalisierung usw.
  • 1 veranschaulicht ein IAB-Netzwerk 100 gemäß einer Ausführungsform. Das IAB-Netzwerk 100 schließt einen IAB-Donor 102 ein, der über einen Glasfaser-Backhaul 116 mit einem 5GC 104 kommunikativ verbunden ist. Diese Verbindung kann eine NG-Schnittstelle umfassen.
  • Der IAB-Donor 102 schließt eine Steuereinheit (control unit, CU) 118, eine oder mehrere verteilte Einheiten (distributed unit, DU) (z. B. die DU 1 120 und die DU 2 122) ein.
  • Das IAB-Netzwerk 100 schließt ferner einen IAB-Knoten 106 (gezeigt als IAB-Knoten 1-1), einen IAB-Knoten 108 (gezeigt als IAB-Knoten 2-1), einen IAB-Knoten 110 (gezeigt als IAB-Knoten 1-2), einen IAB-Knoten 112 (gezeigt als IAB-Knoten 2-2) und einen IAB-Knoten 114 (gezeigt als IAB-Knoten 2-3) ein. Ein IAB-Knoten kann eine mobile Terminierungsfunktionalität (MT) und eine DU einschließen. Wie in 1 veranschaulicht, schließt der IAB-Knoten 106 die MT 124 und die DU 126 ein, der IAB-Knoten 108 schließt die MT 128 und die DU 130 ein, der IAB-Knoten 110 schließt die MT 132 und die DU 134 ein, wobei der IAB-Knoten 112 schließt die MT 136 und die DU 138 ein und der IAB-Knoten 114 schließt die MT 140 und die DU 142 ein.
  • Innerhalb des IAB-Netzwerks 100 können die IAB-Knoten 106 bis 114 und der IAB-Donor 102 über einen oder mehrere drahtlose Backhauls zwischen einer DU und einer MT mit anderen der IAB-Knoten 106 bis 114 und/oder dem IAB-Donor 102 verbunden sein. Zum Beispiel sind der IAB-Donor 102 und der IAB-Knoten 106 über einen ersten drahtlosen Backhaul 144 zwischen der DU 1 120 des IAB-Donors 102 und der MT 124 des IAB-Knotens 106 verbunden, und der IAB-Donor 102 und der IAB-Knoten 110 sind über einen zweiten drahtlosen Backhaul 146 zwischen der DU 2 122 des IAB-Donors 102 und der MT 132 des IAB-Knotens 110 verbunden. Der IAB-Knoten 106 und der IAB-Knoten 108 sind über einen dritten drahtlosen Backhaul 148 zwischen der DU 126 des IAB-Knotens 106 und der MT 128 des IAB-Knotens 108 verbunden. Der IAB-Knoten 110 und der IAB-Knoten 112 sind über einen vierten drahtlosen Backhaul 150 zwischen der DU 134 des IAB-Knotens 110 und der MT 136 des IAB-Knotens 112 verbunden. Der IAB-Knoten 112 und der IAB-Knoten 114 sind über einen fünften drahtlosen Backhaul 152 zwischen der DU 138 des IAB-Knotens 112 und der MT 140 des IAB-Knotens 114 verbunden.
  • Schließlich schließt das IAB-Netzwerk 100 die UE 156 ein, die mit der DU 142 des IAB-Knotens 114 verbunden ist. Die DU 142 kann die Zugangsverbindung 154 bereitstellen, um diese Verbindung herzustellen. Dementsprechend funktioniert die UE 156 mit dem 5GC 104 über ein Kommunikationsrelais durch den IAB-Knoten 114, den IAB-Knoten 112, den IAB-Knoten 110 und den IAB-Donor 102. Fachleute werden aus der vorliegenden Offenbarung erkennen, dass jeder der IAB-Knoten 106 bis 114 und/oder der IAB-Donor 102 auch Zugang zu einer oder mehreren anderen UEs über eine Zugangsverbindung mit einer jeweiligen DU bereitstellen kann.
  • Die CU 118 des IAB-Donors 102 kann im gesamten IAB-Netzwerk 100 grundlegende Funktionen der Steuerungsebene bereitstellen. In bestimmten Ausführungsformen schließt die CU 118 des IAB-Donors 102 eine CU-Steuerebene (CU-CP), eine CU-Benutzerebene (CU-UP) und/oder eine andere Funktionalität ein.
  • Eine DU (z. B. DU 1 120, die DU 2 122, die DU 126, die DU 130, die DU 134, die DU 138 und/oder die DU 142) kann so konfiguriert sein, dass sie mit anderen Entitäten innerhalb des IAB-Netzwerks 100 (z. B. mit einem untergeordneten IAB-Knoten über einen drahtlosen Backhaul und/oder mit einer oder mehreren UE über eine Zugangsverbindung) auf die Weise kommuniziert.
  • Eine MT eines IAB-Knotens (z. B. die MT 124 von 106, die MT 128 des IAB-Knotens 108, die MT 132 des IAB-Knotens 110, die MT 136 des IAB-Knotens 112 und/oder die MT 140 des IAB-Knotens 114) umfasst Komponenten, die einen IAB-Knoten so konfigurieren, dass er sich ähnlich wie eine reguläre UE verhält. Zum Beispiel werden Protokolle, die typische UEs verwenden, um mit sich mit einem RAN zu verbinden, in der MT mit zusätzlichen Erweiterungen unterstützt, die in 3GPP Rel. 16 und Rel. 17 erörtert werden. Zum Beispiel ermöglicht eine MT in einem IAB-Knoten es dem IAB-Knoten, Signalisierungsfunkträger (signaling radio bearers, SRBs) und/oder Datenfunkträger (data radio bearers, DRBs) mit seinem Elternknoten einzurichten. Eine MT kann ferner eine Zellenauswahl durchführen, um zu ermitteln, welcher übergeordneten Entität sie beitreten soll, und eine oder mehrere Protokollschichten (z. B. einschließlich einer BAP-Schicht) einrichten und verwenden, die eine Funktionalität für das Routing von Daten für verschiedene UE-Träger über verschiedene Routen durch das Netzwerk bereitstellen.
  • Die IAB-Knoten 106 bis 114 können jeweils als „Elternteil“ und/oder „Kind“ für einen oder mehrere andere der IAB-Knoten 106 bis 114 wirken, mit denen sie verbunden sind. Ein IAB-Knoten, der auf einer Route (in Bezug auf die Anzahl der Hops über drahtlose Backhauls) näher am IAB-Donor 102 liegt als ein anderer IAB-Knoten, mit dem er verbunden ist, kann als „Eltern“-Knoten des anderen IAB-Knotens betrachtet werden. Zum Beispiel ist in 1 der IAB-Knoten 106 ein Elternknoten des IAB-Knotens 108. Ein IAB-Knoten, der auf einer Route (in Bezug auf die Anzahl der Hops über drahtlose Backhauls) weiter vom IAB-Donor 102 entfernt ist als ein anderer IAB-Knoten, mit dem er verbunden ist, kann als „Kind“-Knoten dieses anderen IAB-Knotens betrachtet werden. Zum Beispiel ist der IAB-Knoten 112 ein Kindknoten des IAB-Knotens 110. In ähnlicher Weise kann der IAB-Donor 102 als Elternknoten des IAB-Knotens 106 und des IAB-Knotens 110 (die jeweils Kindknoten des IAB-Donors 102 sind) verstanden werden.
  • Die Verwendung des IAB-Donors 102 und eines oder mehrerer der IAB-Knoten 106 bis 114 kann eine bessere Gesamtabdeckung für die UE in dem vom IAB-Netzwerk 100 abgedeckten geografischen Gebiet fördern als die Verwendung eines einzelnen Sendeempfangspunkts in einem geografischen Gebiet. Zum Beispiel kann in einem bebauten Gebiet die Verwendung der IAB-Knoten 106 bis 114 die Sichtlinienabdeckung (Line of Sight, LoS) um Ecken herum fördern. Ferner kann die Lage der IAB-Knoten 106 bis 114 abseits des IAB-Donors 102 den Abdeckungsbereich des IAB-Netzwerks 100 generell vergrößern.
  • 2 veranschaulicht eine Benutzerebenenprotokollarchitektur für IAB 200 gemäß einer Ausführungsform. Die Benutzerebenenprotokollarchitektur für IAB 200 zeigt verschiedene Protokollschichten für eine UE 202, einen ersten IAB-Knoten 208 (IAB-Knoten 1), einen zweiten IAB-Knoten 204 (IAB-Knoten 2) und einen IAB-Donor 206. Die verschiedenen Schichten können MT-, DU- oder CU-UP-Entitäten entsprechen, wie veranschaulicht. Die DU und die CU-UP des IAB-Donors 206 können über eine donorinterne F1-U-Schnittstelle 210 kommunizieren. In diesem Beispiel kommuniziert die UE 202 drahtlos mit dem zweiten IAB-Knoten 204 über einen dedizierten DRB auf einer Zugangsverbindung 216, der zweite IAB-Knoten 204 leitet den Uplink-Verkehr drahtlos über einen ersten drahtlosen Backhaul 214 an den ersten IAB-Knoten 208 weiter, und der erste IAB-Knoten 208 leitet den Uplink-Verkehr drahtlos über einen zweiten drahtlosen Backhaul 212 an den IAB-Donor 206 weiter. Die Protokollschichten schließen zum Beispiel Medium Access Control (MAC), RLC, Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), Internet Protocol (IP), User Datagram Protocol (UDP) und General Packet Radio Service (GPRS) Tunneling Protocol User Plane (GTP-U) ein.
  • Die Benutzerebenenprotokollarchitektur für IAB 200 schließt auch eine BAP-Schicht ein, die Funktionalität für das Routing von Daten für verschiedene UE-Träger über verschiedene Routen durch das Netzwerk bereitstellt. Dies kann durch einen Anpassungsschicht-Header erfolgen, der einige Informationen zur Identifizierung eines Trägers einschließt. Das Routing schließt das Zuordnen eingehender Daten zu einer ausgehenden Verbindung basierend auf der Trägerkennung ein.
  • 3 veranschaulicht ein IAB-Netzwerk 300 gemäß einer Ausführungsform. Das IAB-Netzwerk 300 kann den IAB-Donor 102, das 5GC 104, den IAB-Knoten 106, den IAB-Knoten 108, den IAB-Knoten 110, den IAB-Knoten 112 und den IAB-Knoten 114 von 1 (zusammen mit ihren Komponenten und Verbindungen zueinander auf die in 1 beschriebene Weise) einschließen.
  • In der Ausführungsform von 3 kann das 5GC 104 eine MEC-Funktionalität (Multi-Access Edge Computing) 302 einschließen. Die MEC-Funktionalität 302 kann eine oder mehrere Instanzen einer oder mehrerer netzwerkkommunikationsabhängiger Anwendungen bereitstellen (z. B. die Instanz 308 der Anwendung Nr. 1 und die Instanz 310 der Anwendung Nr. 2, obwohl in alternativen Ausführungsformen auch weniger oder mehr als diese bereitgestellt werden können), die von UEs des IAB-Netzwerks 300 verwendet werden. Jede von der Instanz 308 der Anwendung Nr. 1 und der Instanz 310 der Anwendung Nr. 2 kann jeweils mit der UE des IAB-Netzwerks 300 über eine Benutzerebenenfunktion (user plane function, UPF) des 5GC 104 kommunizieren. Gemäß der MEC-Funktionalität 302 kann jede der Instanz 308 der Anwendung Nr. 1 und/oder der Instanz 310 der Anwendung Nr. 2, sobald sie eingerichtet ist, von anderen externen Instanzen dieser Anwendung aktualisiert werden und/oder Aktualisierungen an diese senden (z. B. über das 5GC 104 und über das Internet), um die verschiedenen Instanzen der Anwendung über das IAB-Netzwerk 100 hinaus konsistent zu halten. Dann kann aufgrund der Nähe der Instanz 308 der Anwendung Nr. 1 bzw. der Instanz 310 der Anwendung Nr. 2 (innerhalb der MEC-Funktionalität 302 des 5GC 104) die jeweilige Anwendung schneller mit einer UE des IAB-Netzwerks 300 arbeiten als in einem Fall, in dem die Instanz der Anwendung, mit der die UE kommuniziert, nur außerhalb des 5GC 104 (z. B. über das Internet) verfügbar ist. Diese Beschleunigung kann auf eine reduzierte Latenz zurückzuführen sein, da die Informationen nicht so „weit“ reisen (z. B. über die relevanten Hops des IAB-Netzwerks 300 zurück zum 5GC 104).
  • Ferner schließt das IAB-Netzwerk 300 ein erstes nicht öffentliches Netzwerk (NPN) / ein eigenständiges nicht öffentliches Netzwerk (SNPN) 304 und ein zweites NPN/SNPN 306 ein. Jedes davon kann eine oder mehrere UE (nicht veranschaulicht) einschließen, die für die private Kommunikation entsprechend der Konfiguration des jeweiligen NPN/SNPN konfiguriert sind. Die UE des ersten NPN/SNPN 304 sind über die erste Vielzahl von Zugangsverbindungen 312 mit der DU 142 des IAB-Knotens 114 verbunden, und die UE des zweiten NPN/SNPN 306 sind über die zweite Vielzahl von Zugangsverbindungen 314 mit der DU 142 des IAB-Knotens 114 verbunden.
  • Die Verwendung von NPN/SNPN kann eine bessere Verwaltung von Netzwerken und den Aufbau privater Netze mit zusätzlichen Merkmalen wie Network-Slicing ermöglichen. Zum Beispiel kann es sein, dass die Instanz 308 der Anwendung Nr. 1 so konfiguriert ist, dass sie die UE des ersten NPN/SNPN 304 auf einem ersten Netzwerkscheibe bedient, und dass die Instanz 310 der Anwendung Nr. 2 so konfiguriert ist, dass sie die UE des zweiten NPN/SNPN 306 auf einer zweiten Netzwerkscheibe bedient.
  • In einigen Fällen kann das Network-Slicing gemäß Anwendung und NPN/SNPN dazu bestimmt sein, Übertragungen für die jeweilige Anwendung durch das IAB-Netzwerk 300 zu ermöglichen, bestimmte Anforderungen an die Dienstgüte (Quality of Service, QoS) zu erfüllen. Zum Beispiel kann es sein, dass eine Anwendung so konfiguriert ist, dass sie ultrazuverlässige Kommunikation mit niedriger Latenz (ultra-reliable low-latency communications, URLLC) mit ihren UEs nutzt, was bedeutet, dass zum Beispiel Daten der Anwendung zwischen einer UE des jeweiligen NPN/SNPN und einem 5GC innerhalb einer bestimmten Zeitspanne und/oder mit einer bestimmten Zuverlässigkeit zugestellt werden.
  • Es kann jedoch sein, dass diese Anforderungen an die Dienstgüte für die Anwendung(en) im IAB-Netzwerk 300 nicht garantiert werden können (selbst wenn sich die zugehörige Instanz 308 der Anwendung Nr. 1 und/oder die Instanz 310 der Anwendung Nr. 2 in dem 5GC 104 gemäß der MEC-Funktionalität 302 befinden). Dies kann auf den IAB-Charakter des IAB-Netzwerks 300 zurückzuführen sein. Zum Beispiel kann die Anzahl von Hops vom IAB-Knoten 114 zurück zum IAB-Donor 102 und zu dem 5GC 104 (das die Instanz 308 der Anwendung Nr. 1 und die Instanz 310 der Anwendung Nr. 2 einschließt) eine so große Latenz verursachen, dass die Dienstgüte-Anforderungen für die Anwendungsdaten nicht erfüllt werden. Ferner ist zu beachten, dass es zumindest in einigen Netzwerken keine Obergrenze für die Anzahl der IAB-Knoten bzw. die Anzahl von Hops im Netzwerk existiert, was bedeutet, dass diese Latenz aufgrund von Hopping theoretisch relativ hoch sein kann, wenn die UE über eine Route mit vielen IAB-Knoten mit dem 5GC 104 verbunden ist. Ferner kann es in einigen IAB-Architekturen einem IAB-Knoten freistehen, je nach Netzwerkbedingungen einen anderen IAB-Elternknoten auszuwählen (z. B. kann der IAB-Knoten 114, der den Zugang zur UE des ersten NPN/SNPN 304 und/oder des zweiten NPN/SNPN 306 bereitstellt, als Kind des IAB-Knotens 108 statt als Kind des IAB-Knotens 112 ausgewählt werden). In solchen Fällen kann die Geschwindigkeit, die auf der neuen Route zu dem 5GC (z. B. über den IAB-Knoten 108, den IAB-Knoten 106 und den IAB-Donor 102) möglich ist, nicht garantieren, dass die Dienstgüte-Anforderungen für die Anwendung erfüllt werden. Schließlich stellt jeder Hop durch das Netzwerk einen möglichen Fehlerpunkt für die Informationsübertragung dar, sodass Routen mit einer größeren Anzahl von Hops durch verschiedene IAB-Knoten eine geringere Gesamtzuverlässigkeit aufweisen können.
  • 4 veranschaulicht ein IAB-Netzwerk 400 gemäß einer Ausführungsform. Das IAB-Netzwerk 400 kann den IAB-Donor 102, das 5GC 104, den IAB-Knoten 106, den IAB-Knoten 108, den IAB-Knoten 110, den IAB-Knoten 112 und den IAB-Knoten 114 von 1 (zusammen mit ihren Komponenten und Verbindungen zueinander auf die in 1 beschriebene Weise) einschließen. Ferner kann das IAB-Netzwerk 400 auch das erste NPN/SNPN 304 mit der UE, die über die erste Vielzahl von Zugangsverbindungen 312 mit der DU 142 des IAB-Knotens 114 verbunden ist, und das zweite NPN/SNPN 306 mit der UE, die über die zweite Vielzahl von Zugangsverbindungen 314 mit der DU 142 des IAB-Knotens 114 verbunden ist, einschließen, wie in Bezug auf 3 beschrieben.
  • In 4 ist die MEC-Funktionalität 302 im IAB-Knoten 114 angeordnet (statt im 5GC 104 wie in 3). Die MEC-Funktionalität 302 schließt die Instanz 308 der Anwendung Nr. 1 und die Instanz 310 der Anwendung Nr. 2 ein, wie sie auch in Bezug auf 3 beschrieben sind. Ein IAB-Knoten, der in der Lage ist, als MEC-Randknoten zu fungieren, kann hierin als IAB-MEC beschrieben werden.
  • Die Anordnung der MEC-Funktionalität 302 innerhalb des IAB-Knotens 114 (z. B. die Verwendung einer IAB-MEC) ermöglicht eine relativ niedrigere Latenz und eine zuverlässigere Kommunikation zwischen der UE des ersten NPN/SNPN 304 und/oder zweiten NPN/SNPN 306 und der entsprechenden Instanz 308 der Anwendung Nr. 1 und/oder Instanz 310 der Anwendung Nr. 2 (da keine Notwendigkeit besteht, über die Hops zwischen dem IAB-Knoten 114 und dem IAB-Knoten 112, dem IAB-Knoten 112 und dem IAB-Knoten 110 und dem IAB-Knoten 110 und dem IAB-Donor 102 zurück zum 5GC 104 zu gelangen). Ferner kann die Anwendung durch Verwenden einer IAB-MEC mit der Instanz 308 der Anwendung Nr. 1 und der Instanz 310 der Anwendung Nr. 2 weiterhin mit der UE des ersten NPN/SNPN 304 und des zweiten NPN/SNPN 306 funktionieren, selbst wenn die Route vom IAB-Knoten 114 zurück zum 5GC 104 überlastet oder nicht funktionsfähig ist. Die Verwendung einer IAB-MEC kann auch eine feiner abgestimmtes Management von Vorrichtungen (UE) und Netzwerken (entsprechende NPN/SNPN) ermöglichen, während immer noch sichergestellt wird, dass Abrechnungs- und andere zentralisierte Managementfähigkeiten aus Sicht des Betreibers erhalten bleiben. Schließlich können die IAB-MECs neue Geschäftsmodelle ermöglichen. Zum Beispiel können IAB-MECs von Drittanbietern entwickelt werden, die für die Verwendung mit bestimmten Anwendungen angepasst sind (z. B. die konfiguriert sind, um bestimmte Anwendungsinstanzen bereitzustellen).
  • Es wird auch in Betracht gezogen, dass die Anordnung der MEC-Funktionalität 302 am IAB-Knoten 114 auch im Falle einer Anwendung für eine mit dem IAB-Knoten 114 verbundene UE von Vorteil sein kann, die z. B. der Instanz 308 der Anwendung Nr. 1 oder der Instanz 310 der Anwendung Nr. 2 entspricht, aber nicht (notwendigerweise) auf einem entsprechenden NPN/SNPN verwendet wird. Mit anderen Worten wird die Verwendung des ersten NPN/SNPN 304 und des zweiten NPN/SNPN 306 in der in 4 gezeigten Ausführungsform beispielhaft angegeben - es wird in Betracht gezogen, dass die Vorteile der Anordnung der MEC-Funktionalität auf einem IAB-Knoten, wie hierin beschrieben, nicht inhärent ein so eingerichtetes NPN/SNPN erfordern.
  • Verschiedene mögliche Anwendungsfälle für IAB-MECs werden in Betracht gezogen. Zum Beispiel können IAB-MECs dazu verwendet werden, Anwendungsinstanzen von Anwendungen für Augmented Reality (AR), Virtual Reality (VR) und/oder Vehicle-to-Everything (V2X)-Kommunikation, Industrial Internet of Things (IIOT)-Anwendungen oder andere Fälle zu hosten, die von der Fähigkeit profitieren, relativ strenge Dienstgüte-Anforderungen (z. B. niedrige Latenz und/oder hohe Zuverlässigkeit) im Kontext eines IAB-Netzwerks zu erfüllen.
  • Es wird in Betracht gezogen, dass in einigen Fällen mehrere IAB-MECs in einer Repeater-Konfiguration verwendet werden können. Es wird in Betracht gezogen, dass in einigen Fällen mehrere IAB-MECs verwendet werden können, um ein lokales Netzwerk zu bilden, das die IAB-MECs einschließt. Für jede dieser Optionen werden mindestens zwei Betriebsmodi in Betracht gezogen. In einem ersten Modus kann sich jede IAB-MEC in einem Sidelink-Relais-Modus befinden. In einem zweiten Modus wird jede IAB-MEC je nach benötigter Kapazität zentral von einem Makroknoten gesteuert.
  • Um IAB-MECs praktisch und kommerziell zu realisieren, müssen verschiedene Überlegungen berücksichtigt werden. Eine erste Kategorie dieser Überlegungen bezieht sich auf die 3 GPP-Kernfunktionen. Erstens sollte die Möglichkeit in Betracht gezogen werden, Vorrichtungen von Drittanbietern, die nicht in die Integrationsverfahren der Originalgerätehersteller (OEM) eingeweiht sind, in die Betreibernetzwerke zu integrieren. Dementsprechend können Rahmenregelungen für die Integration einer IAB-MEC eines Drittanbieters in ein bestehendes Trägernetzwerk von Vorteil sein.
  • Zweitens müsste eine IAB-MEC Techniken zur Zwischenspeicherung von Inhalten implementieren, die die CU durchlaufen und bei Bedarf geeignete Inhalte abrufen (z. B. zur Aktualisierung von Anwendungsinstanzen bei der IAB-MEC). Da IAB-Knoten möglicherweise keinen direkten Kontakt zwischen einem IAB-Knoten und dem 5GC bereitstellen, muss eine CU eines IAB-Donors diesen Vorgang möglicherweise aktivieren. Dementsprechend können vorhandene Mechanismen für IAB-Netzwerke innerhalb der RAN- und CN-Domänen aktualisiert werden, um dies zu berücksichtigen.
  • Drittens kann es in einigen Fällen erforderlich sein, eine UPF in die IAB-MEC zu verlegen. Dementsprechend können Mechanismen für verteilte UPF-Architekturen vorteilhaft sein.
  • Viertens kann die Sicherheit bei Relais von Drittanbietern ein Problem darstellen, insbesondere bei den zu erörternden Split-PDCP-Architekturen. In diesem Zusammenhang kann ein Rahmen von Lösungen für Interoperabilitätsprobleme (im Falle unterschiedlicher Anbieter für eine IAB-MEC und eine UE) entwickelt werden.
  • Eine zweite Kategorie dieser Überlegungen bezieht sich auf die 3GPP-Nutzung. Es sind Fälle zu erwarten, in denen aufgrund von Backhaul-Ausfällen in der IAB-MEC und/oder Backhaul- oder anderen Ausfällen in einem dem IAB-MEC übergeordneten Knoten einige Dienste einer Anwendung funktionieren, während andere offline sind (z. B. können Dienste der Anwendung, die den Zugang zum Internet über die ausgefallene Route nutzen, offline sein). Zum Beispiel kann bei einem Ausfall an einem Backhaul und/oder Knoten zwischen der IAB-MEC und der CU auf dem entsprechenden IAB-Donor der lokale Inhalt für die Anwendung, die in den Anwendungsinstanzen an der IAB-MEC verfügbar ist, weiterhin an die UE bereitgestellt werden. Dienste der Anwendung, die eine Echtzeitkonnektivität zum Internet benötigen, funktionieren jedoch möglicherweise nicht. Diese Kombination kann für den Benutzer eine verwirrende Benutzererfahrung bereitstellen, wenn diese Situation nicht geordnet gehandhabt wird. Dementsprechend können Anwendungen implementiert so werden, dass die Erfahrung in allen diesen Fällen einheitlich ist (oder dass geeignete Maßnahmen ergriffen werden, um sicherzustellen, dass der Benutzer die Gründe für die unterschiedlichen Erfahrungen versteht).
  • Eine dritte Kategorie dieser Überlegungen bezieht sich auf 3GPP RAN. Erstens gibt es bei einigen IAB-Knoten möglicherweise keine PDCP-Schicht, die in der Lage ist, den IAB-Knoten mit der auf dem 5GC vorhandenen MEC-Funktionalität zu verbinden. Zum Beispiel endet in einigen Fällen ein IAB-Knoten auf der RLC-Schicht, während die MEC-Funktionalität (die sich derzeit innerhalb des 3GPP-Kerns befinden kann) unter Verwendung der IP-Schicht kommuniziert. Ferner kann das Anordnen einer MEC an der CU des IAB-Donors (die über IP kommunizieren kann) den Zweck einer lokalisierten MEC zunichtemachen, da die UE, die einen Dienst benötigt, immer noch mehrere Hops von dem IAB-Donor entfernt sein könnte (und somit immer noch an Dienstgüte-Probleme gebunden ist, die sich aus der Notwendigkeit des Hoppings ergeben).
  • Zweitens kommunizieren in einigen Fällen (z. B. bei kommerziellen Bereitstellungen) ein IAB-Knoten und eine CU eines IAB-Donors unter Verwendung der F1-Schnittstelle. Es kann sein, dass die zugehörigen FlAP-Standards vom Hersteller bestimmt werden und von der Implementierung durch den Netzbetreiber und/oder die Anbieter von Netzknoten abhängen. Dementsprechend gibt es möglicherweise keine einfache Möglichkeit, eine F1-Schnittstelle zwischen einer CU eines IAB-Donors und einem IAB-Knoten eines Drittanbieters zu schaffen. Dementsprechend müssen im Falle einer IAB-MEC möglicherweise Alternativen zu F1-C-Schnittstellen in Betracht gezogen werden, um eine ordnungsgemäße Steuerung einer IAB-MEC durch die CU des IAB-Donors sicherzustellen.
  • Hierin beschriebene Systeme und Verfahren können Mechanismen beschreiben, die verwendet werden können, um IAB-MECs (einschließlich IAB-MECs von Drittanbietern) in Betreibernetze auf eine Weise zu integrieren, die sicher ist und ein nahtloses Onboarding der Dienste bereitstellt. Diese können unter anderem architektonische Auswirkungen auf solche Systeme berücksichtigen, CN-Funktionalitäten, die über einen IAB-Donor für den Zugang und die Verwaltung von IAB-MEC-Funktionen zur Verfügung stehen, erforderliche Modifikationen an Protokollstapeln in IAB-MECs und/oder anderen Knoten und/oder Modifikationen an Planungs- und Erteilungsanfrage-Prozeduren, die in IAB-MECs durchgeführt werden, beschreiben.
  • 5 veranschaulicht ein IAB-Netzwerk 500 gemäß einer Ausführungsform. Das IAB-Netzwerk 500 schließt eine IAB-MEC 502, einen IAB-Knoten 504, einen IAB-Donor 506, eine erste UE 508 und eine zweite UE 510 ein. Im Beispiel von 5 fungiert die IAB-MEC 502 sowohl als UE als auch als Zugangsknoten (access node, AN). In einigen Ausführungsformen kann die IAB-MEC 502 ein erweitertes Residential Gateway (eRG) sein.
  • Die IAB-MEC 502 schließt die DU 512 und die MT 514 ein. Wie veranschaulicht, wurde eine erste PDCP-Schicht 520 in der MT 514 der IAB-MEC 502 instanziiert. Diese erste PDCP-Schicht 520 kann eine Kommunikation durch die IAB-MEC 502 auf dem PDCP-Schicht-Niveau in Richtung IAB-Donor 506 ermöglichen/erlauben und kann dazu dienen, das PDCP für das gesamte IAB-Netzwerk 500 an der IAB-MEC 502 zu terminieren (z. B. einen Endpunkts dafür bereitzustellen)
  • Ferner ist die erste UE 508 über die erste Zugangsverbindung 526 mit der DU 512 der IAB-MEC 502 verbunden und die zweite UE 510 ist über die zweite Zugangsverbindung 528 mit der DU 512 der IAB-MEC 502 verbunden. Wie gezeigt, befinden sich diese Verbindungen auf der Ebene einer zweiten PDCP-Schicht 522, die an der DU 512 der IAB-MEC 502 instanziiert wurde. Die DU 512 des IAB-MEC 502 kann eine lokale Anwendungsinstanz 516 einschließen, die eine Instanz einer Anwendung auf der IAB-MEC 502 gemäß einer MEC-Funktionalität sein kann, wie vorstehend beschrieben. Hierin können Anwendungen, die solche lokalen Anwendungsinstanzen erzeugen können, als „MEC-fähige Anwendungen“ bezeichnet werden.
  • Die zweite PDCP-Schicht 522 in der DU 512 der IAB-MEC 502 kann verwendet werden, um Daten zu und von der ersten UE 508 und/oder der zweiten UE 510 über das IAB-Netzwerk 500 zu übertragen. Auf diese Weise kann ein PDCP-Hopping-Mechanismus durch das IAB-Netzwerk 500 eingerichtet werden (z. B. über die zweite PDCP-Schicht 522, die erste PDCP-Schicht 520 und weiter zu einer dritten PDCP-Schicht 524 des IAB-Donors 506). Ein solcher Hopping-Mechanismus, der die erste PDCP-Schicht 520 und die zweite PDCP-Schicht 522 über die IAB-MEC 502 zur Datenübertragung nutzt, kann hierin auch als ein Level-3-Relay (L3) bezeichnet werden. Unter solchen Umständen kann man davon ausgehen, dass das Daten-Hopping durch das IAB-Netzwerk 500 auf einer höheren Ebene durch den Protokollstapel der IAB-MEC 502 erfolgen kann als z. B. im Fall des zweiten IAB-Knotens 204 oder des ersten IAB-Knotens 208 von 2, wo das Hopping nur auf der PHY/MACH/RLC/BAP-Ebene erfolgt (was hierin als ein Level-2-(L2)-Hopping-Mechanismus bezeichnet werden kann).
  • Im Fall von 5 kann die Verwendung der zweiten PDCP-Schicht 522 den Protokollstapel der DU 512 der IAB-MEC 502 vervollständigen, sodass eine funktionale Route durch die DU 512 der IAB-MEC 502 zwischen der ersten UE 508 und/oder der zweiten UE 510 und der lokalen Anwendungsinstanz 516 fertiggestellt wird (z. B. kann der Transport von Daten zwischen der UE und der lokalen Anwendungsinstanz 516 innerhalb der IAB-MEC 502 erfolgen, ohne dass die IAB-MEC 502 solche Daten durch andere Elternknoten des IAB-Netzwerks 500 sendet). Da beispielsweise, wie veranschaulicht, die erste UE 508 und/oder die zweite UE 510 mit der DU 512 auf der Ebene der zweiten PDCP-Schicht 522 verbunden sind, sind PDCP-Protokolldateneinheiten (PDU) von diesen UE in der IAB-MEC 502 erkennbar (von denen Übertragungssteuerungsprotokoll/Internetprotokoll (TCP/IP) PDU durch eine TCP/IP-Schicht 530 der DU 512 erkennbar ist). Dementsprechend können die Daten von diesen UE von der zweiten PDCP-Schicht 522 zu der TCP/IP-Schicht 530 geleitet werden und von dort an die lokale Anwendungsinstanz 516 auf der DU 512 der IAB-MEC 502 geleitet werden. In der umgekehrten Richtung kann die zweite PDCP-Schicht 522 Daten von der lokalen Anwendungsinstanz 516, wie sie von der TCP/IP-Schicht 530 als TCP/IP-PDUs präsentiert werden, an die zweite PDCP-Schicht 522 weiterleiten, die dann PDCP-PDU, die den TCP/IP-PDUs entnommen werden, an die geeignete von der ersten UE 508 und der zweiten UE 510 weiterleiten kann (wiederum, ohne solche Daten zuerst durch andere Elternknoten des IAB-Netzwerks 500 zu senden). Wie hierin beschrieben, können Daten, die von einer lokalen Anwendungsinstanz (wie der lokale Anwendungsinstanz 516) gesendet werden, als „Daten der lokalen Anwendungsinstanz“ bezeichnet werden
  • Dementsprechend kann die UE durch die Terminierung des PDCP für das gesamte IAB-Netzwerk 500 an der IAB-MEC 502, wie beschrieben (z. B. gemäß der ersten PDCP-Schicht 520 und/oder der zweiten PDCP-Schicht 522 an der IAB-MEC 502) eine PDU-Sitzung für den Transport von Daten zu der lokalen Anwendungsinstanz 516 der IAB-MEC 502 aufbauen, die von einer PDU-Sitzung für den Transport durch das IAB-Netzwerk 500 zum CN oder darüber hinaus getrennt ist.
  • Ferner wird in Betracht gezogen, dass Trägeranfragen von UE (z. B. der ersten UE 508 und der zweiten UE 510) basierend auf Erteilungsanfragen in der IAB-MEC 502 (und auf der Verfügbarkeit von Anwendungsinstanzen in der IAB-MEC 502) aggregiert werden können. In einigen Fällen wird ein Träger der ersten UE 508 mit einem Träger einer zweiten UE innerhalb eines PDCP-Kanals zwischen der ersten PDCP-Schicht 520 und der dritten PDCP-Schicht 524 des IAB-Donors 506 aggregiert. Auf diese Weise kann eine doppelte PDCP-Hopping-Anordnung geschaffen werden. Zum Beispiel kann es in 5 einen ersten PDCP-Hop zwischen einer (oder beiden) von der ersten UE 508 und der zweiten UE 510 und der IAB-MEC 502 und einen zweiten PDCP-Hop zwischen der IAB-MEC 502 und dem IAB-Donor 506 geben.
  • Ferner kann durch die Terminierung des PDCP für das gesamte IAB-Netzwerk 500 an der IAB-MEC 502, wie beschrieben (z. B. gemäß mindestens der ersten PDCP-Schicht 520 in der IAB-MEC 502) der aktualisierte Inhalt für die lokale Anwendungsinstanz 516 dem IAB-Knoten 504 von der dritten PDCP-Schicht 524 (auf der CU 518 des IAB-Donors 506) über die erste PDCP-Schicht 520 (auf der MT 514) und weiter zur zweiten PDCP-Schicht 522 (auf der DU 512) bereitgestellt werden. Von der zweiten PDCP-Schicht 522 können diese Daten der TCP/IP-Schicht 530 und weiter bis zu der lokalen Anwendungsinstanz 516 bereitgestellt werden.
  • In einigen Fällen kann die beschriebene Handhabung der PDCP-Schicht (z. B. einschließlich eines PDCP-Hopping, wie beschrieben) für spezifische Dienste verwendet werden, wie zum Beispiel für URLLC-Daten (Ultra Reliable Low-Latency Communication). In solchen Fällen kann die IAB MEC 502 als ein Dual-Relay-(L3-Relais) für spezifische Anwendungsinstanzen fungieren, da diese Daten verwendet werden (so dass z. B. die URLLC-Daten zwischen der lokalen Anwendungsinstanz 516 und der ersten UE 508 oder der zweiten UE 510 transportiert werden können, ohne den/die Elternknoten der IAB-MEC 502 zu verwenden), und kann stattdessen andere Daten auf einer L2-Relay-Ebene behandeln (z. B. durch Weiterleiten dieser Daten an einen CN über das IAB-Netzwerk 500 unter Verwendung von BAP). In solchen Fällen kann eine PDU-Sitzung für die URLLC-Daten von der ersten PDCP-Schicht 520 der MT 514 aufgebaut werden, und Daten der lokalen Anwendungsinstanz 516 können entsprechend aktualisiert werden. Es wird ferner in Betracht gezogen, dass andere Dienste (außer URLLC-Datendienste) ähnlich behandelt werden können.
  • In einigen Ausführungsformen von 5 kann die IAB-MEC 502 eine erste SDAP-Schicht (Service Data Adaptation Protocol) 532 in der DU 512 und eine zweite SDAP-Schicht 534 in der MT 514 einschließen. Diese können in Verbindung mit einer dritten SDAP-Schicht 536 der CU 518 des IAB-Donors 506 arbeiten. Das Vorhandensein (oder Nichtvorhandensein) der ersten SDAP-Schicht 532 und der zweiten SDAP-Schicht 534 kann unterschiedliche Operationen der IAB-MEC 502 ermöglichen.
  • In Ausführungsformen, in denen keine erste SDAP-Schicht 532 oder zweite SDAP-Schicht 534 in der IAB-MEC 502 gibt, kann eine Eins-zu-Eins-Entsprechung zwischen DRBs zwischen einer UE und der IAB-MEC 502 und Daten für die lokale Anwendungsinstanz 516 bestehen (z. B. können Daten eines Dienstgütestroms (QoS), der der lokalen Anwendungsinstanz 516 entspricht, eindeutig in einem zugewiesenen/zugehörigen DRB vorhanden sein). In einem solchen Fall kann die zweite PDCP-Schicht 522 die Daten in die lokale Anwendungsinstanz 516 leiten, indem sie die zugehörigen DRB(s) an die lokale Anwendungsinstanz 516 routet.
  • In anderen Ausführungsformen, in denen es eine erste SDAP-Schicht 532 und eine zweite SDAP-Schicht 534 in der IAB-MEC 502 gibt, könnten ein oder mehrere der Dienstgüteströme für Daten für die lokale Anwendungsinstanz 516 durch/über die zweite SDAP-Schicht 534 auf denselben DRB abgebildet werden.
  • In anderen Ausführungsformen, in denen es die erste SDAP-Schicht 532 und eine zweite SDAP-Schicht 534 in der IAB-MEC 502 gibt, kann es keine Einschränkung für die Zuordnung von QoS-Strömen, die den Daten der lokalen Anwendungsinstanz 516 zugeordnet sind, zu einem bestimmten DRB geben. In solchen Fällen kann die zweite SDAP-Schicht 534 PDCP-PDUs, die zu QoS-Strömen für Daten für die lokale Anwendungsinstanz 516 gehören, an die lokale Anwendungsinstanz 516 weiterleiten und darüber hinaus PDCP-PDUs, die zu nicht relevanten (nicht für die lokale Anwendungsinstanz 516) QoS-Strömen gehören, an einen vorgelagerten IAB-Donor 506 zum Empfang an einem CN weiterleiten. In solchen Fällen wird die PDCP-Schicht für ein und denselben DRB sowohl lokal an der UE als auch an der IAB-MEC 502 instanziiert. Zwischen diesen Instanzen kann eine Steuerebenen-Signalisierung entlang einer E1'-Schnittstelle stattfinden, um eine Kohärenz zwischen den Protokollschichten der UE und der IAB-MEC 502 bereitzustellen.
  • 6 veranschaulicht ein IAB-Netzwerk 600 gemäß einer Ausführungsform. Das IAB-Netzwerk 600 schließt eine IAB-MEC 602, einen IAB-Knoten 604, einen IAB-Donor 606, eine erste UE 608 und eine zweite UE 610 ein. Im Beispiel von 6 fungiert die IAB-MEC 602 sowohl als UE als auch als Zugangsknoten (access node, AN). In einigen Ausführungsformen kann die IAB-MEC 602 ein eRG sein.
  • Die IAB-MEC 602 schließt die DU 612 und die MT 614 ein. Wie veranschaulicht, wurde eine erste PDCP-Schicht 620 in der MT 614 der IAB-MEC 602 instanziiert. Diese PDCP-Schicht kann eine Kommunikation durch die IAB-MEC 602 auf dem PDCP-Schicht-Niveau in Richtung IAB-Donor 606 ermöglichen/erlauben und kann dazu dienen, die PDCP-Schicht an der IAB-MEC 602 zu terminieren (z. B. einen Endpunkt dafür bereitzustellen).
  • Ferner ist die erste UE 608 über die erste Zugangsverbindung 622 mit der DU 612 der IAB-MEC 602 verbunden und die zweite UE 610 ist über die zweite Zugangsverbindung 624 mit der DU 612 der IAB-MEC 602 verbunden. Im Unterschied zur IAB-MEC 502 von 5 ist die IAB-MEC 602 von 6 ohne eine zweite PDCP-Schicht veranschaulicht, die in der DU 612 instanziiert ist. Dementsprechend befinden sich, wie gezeigt, die erste Zugangsverbindung 622 für die erste UE 608 und die zweite Zugangsverbindung 624 für die zweiten UE 610 auf der Ebene einer TCP/IP-Schicht 626, die in der DU 612 der IAB-MEC 602 instanziiert wurde. Die DU 612 der IAB-MEC 602 kann eine lokale Anwendungsinstanz 616 einschließen, die eine Instanz einer MEC-fähigen Anwendung sein kann.
  • In der veranschaulichten Konfiguration des IAB-Netzwerks 600 von 6 können die erste UE 608 und die zweite UE 610 mit der lokalen Anwendungsinstanz 616 über lokale IP-Zugangsmechanismen kommunizieren (wobei Daten der lokalen Anwendungsinstanz 616 on der ersten UE 608 und/oder der zweiten UE 610 an die TCP/IP-Schicht gesendet und/oder von dieser empfangen werden). Da, wie veranschaulicht, die erste UE 608 und/oder die zweite UE 610 mit der DU 612 auf der Ebene der TCP/IP-Schicht 626 verbunden sind, können Daten von der ersten UE 608 und/oder der zweiten UE 610 an die lokale Anwendungsinstanz 616 auf der DU 612 der IAB-MEC 602 weitergeleitet werden, ohne dass diese Daten zuerst durch andere Elternknoten des IAB-Netzwerks 600 gesendet werden müssen. In umgekehrter Richtung kann die TCP/IP-Schicht 626 Daten von der lokalen Anwendungsinstanz 616 an die entsprechende der ersten UE 608 und der zweiten UE 610 senden (wiederum, ohne solche Daten zuerst durch andere Elternknoten des IAB-Netzwerks 600 zu senden). Es wird darauf hingewiesen, dass die Trägerverwaltung in diesen Kontexten komplizierter sein kann als im Fall des IAB-Netzwerks 500 von 5 (z. B. wenn diese Trägerverwaltung eine Verwendung bestimmter PDCP-Funktionalität(en) auf der IAB-MEC 602 implizieren kann, die ein Duplikat analoger PDCP-Funktionalität(en) auf der CU 618 wäre, was zu einer Dezentralisierung der Steuerung weg von der CU 618 führen würde).
  • In Fällen, wie 6, in denen es keine PDCP-Schicht an der DU 612 gibt, die wie die erste PDCP-Schicht 520 der DU 512 von 5 funktioniert, kann es sein, dass die Kommunikation zwischen der TCP/IP-Schicht 626 und der ersten PDCP-Schicht 620 an der MT 514 gemäß Zuteilungen erfolgt, die von dem IAB-Donor 606 zugewiesen werden.
  • Aufgrund der Terminierung des PDCP für das gesamte IAB-Netzwerk 600 an der IAB-MEC 602 (z. B. gemäß der ersten PDCP-Schicht 620) kann die UE dementsprechend eine PDU-Sitzung für den Datentransport zur lokalen Anwendungsinstanz 616 der IAB-MEC 602 (unter Nutzung der beschriebenen Kommunikationen über die TCP/IP-Schicht 626) aufbauen, die von einer PDU-Sitzung für den Transport durch das IAB-Netzwerk 600 zum CN oder darüber hinaus getrennt ist.
  • Ferner kann durch die Terminierung des PDCP für das gesamte IAB-Netzwerk 600 an der IAB-MEC 602, wie beschrieben (z. B. gemäß der ersten PDCP-Schicht 520) der aktualisierte Inhalt für die lokale Anwendungsinstanz 616 dem IAB-Knoten 604 von der zweiten PDCP-Schicht 628 (auf der CU 618 des IAB-Donors 606) über die erste PDCP-Schicht 620 (auf der MT 614) und weiter zur TCP/IP-Schicht 626 (auf der DU 612) bereitgestellt werden. Von der TCP/IP-Schicht 626 können diese Daten bis zu der lokalen Anwendungsinstanz 516 bereitgestellt werden.
  • Für Daten, die nicht über solche IP-Zugangsmechanismen gesendet werden, kann die IAB-MEC 602 weiterhin als RLC-Relais (L2-Relais) fungieren, wobei die PDCP-Schicht für das L2-Relais stattdessen an der relevanten UE terminiert wird, um gegebenenfalls das R16/R17-Trägermanagement sicherzustellen. Zum Beispiel kann das IAB-Netzwerk 600 so konfiguriert sein, dass es Daten für spezielle Dienste (z. B. bestimmte Dienstgüte-Ströme) zwischen der ersten UE 608 oder der zweiten UE 610 und der lokalen Anwendungsinstanz 616 wie beschrieben über die TCP/IP-Schicht 626 weiterleitet, während andere Daten (z. B. zum Senden an ein CN) gemäß einem L2-Relais gesendet werden können. In einigen Fällen kann ein solches Routing über die TCP/IP-Schicht 626 für URLLC-Daten durchgeführt werden, während Nicht-URLLC-Daten gemäß einem L2-Relais gesendet werden.
  • 7 veranschaulicht ein System 700 zur Kommunikation zwischen einer lokalen Anwendungsinstanz 706 auf einer IAB-MEC 702 und einem Anwendungsclient 708 auf einer UE unter Verwendung einer Zugangsverbindung 710 gemäß Sidelink (SL)-Gesichtspunkten gemäß einer Ausführungsform. Wie veranschaulicht, schließt die IAB-MEC 702 eine MT 714 mit einer ersten PDCP-Schicht 718 und eine DU 712 mit einer zweiten PDCP-Schicht 720 ein (z. B. ähnlich der in 5 beschriebenen IAB-MEC 502, jedoch ist zu beachten, dass die Verwendung einer IAB-MEC nach dem Muster der IAB-MEC 602 von 6, der die zweite PDCP-Schicht 720 fehlen würde, oder einer anderen IAB-MEC ebenfalls in Betracht gezogen wird). In 7 veranschaulicht, schließt die IAB-MEC 702 ferner die PCS-Funktionalität 716 ein, über die die IAB-MEC 702 unter Verwendung von SL-Kommunikation mit einem SL-MEC-Server 722 betrieben werden kann, was als funktionales Hosting 724 der lokalen Anwendungsinstanz 706 auf der DU 712 verstanden werden kann. In einigen Ausführungsformen kann die IAB-MEC 702 ein eRG sein.
  • Jede der UE 704 und der IAB-MEC 702 können einen vollständigen PC5-Protokollstapel (wie veranschaulicht) umfassen, der es dem Anwendungsclient 708 ermöglicht, eine logische Schnittstelle zum SL-MEC-Server 722 herzustellen, um den Datentransport zwischen der lokalen Anwendungsinstanz 706 und dem Anwendungsclient 708 auf der UE 704 über SL zu erleichtern. Die PCS-Funktionalität 716 der IAB-MEC 702 kommuniziert dementsprechend die Daten an/von der DU 712 der IAB-MEC 702, die diesem Datenpfad entspricht (und die DU 712 kann dann Daten an/von der lokalen Anwendungsinstanz 706 transportieren, ohne dass diese Daten über einen oder mehrere vorgelagerten Elternknoten der IAB-MEC 702 eines IAB-Netzwerks (nicht veranschaulicht) laufen. Ferner können andere Daten von der UE 704 durch die DU 712 an die MT 714 der IAB-MEC 702 zur Kommunikation mit einem CN oder darüber hinaus weitergeleitet werden (z. B. gemäß einem L2-Relaisschema).
  • Durch die Verwendung von SL-Verfahren, wie beschrieben, kann vermieden werden, dass die UE 704 speziell für die lokale anwendungsinstanzspezifische PDCP-Kommunikation mit einer PDCP-Schicht der DU 712 der IAB-MEC 702 konfiguriert werden muss (und dass Sicherheitsaspekte, die infolge dieser Maßnahme auftreten können, nicht berücksichtigt werden). Es wird daher in Betracht gezogen, dass solche Vorteile durch die Verwendung der PCS-Funktionalität 716 der IAB-MEC 702 mit UE erreicht werden können, die SL unterstützen/mit einem PC5-Protokollstapel konfiguriert wurden, wie in der UE 704.
  • 8 veranschaulicht ein Verfahren 800 eines IAB-Knotens gemäß einer Ausführungsform. Das Verfahren 800 schließt das Instanziieren 802 einer lokalen Anwendungsinstanz einer MEC-fähigen Anwendung an einer DU des IAB-Knotens ein.
  • Das Verfahren 800 schließt ferner das Instanziieren 804 einer ersten PDCP-Schicht an einer MT des IAB-Knotens ein.
  • Das Verfahren 800 schließt ferner das Transportieren 806 von ersten Daten der lokalen Anwendungsinstanz zwischen einem IAB-Donor und der MT unter Verwendung der ersten PDCP-Schicht ein.
  • Das Verfahren 800 schließt ferner das Transportieren 808 von zweiten Daten der lokalen Anwendungsinstanz zwischen einer ersten UE, die mit dem IAB-Knoten verbunden ist, und dem IAB-Knoten ein.
  • Das Verfahren 800 schließt ferner optional das Instanziieren 810 einer zweiten PDCP-Schicht an der DU ein. In diesen Fällen kann es sein, dass die zweiten Daten zwischen der DU und der ersten UE unter Verwendung der zweiten PDCP-Schicht transportiert werden. In einigen dieser Fälle kann das Verfahren 800 ferner das Transportieren der ersten Daten zwischen der DU und der MT unter Verwendung der ersten PDCP-Schicht und der zweiten PDCP-Schicht einschließen.
  • Das Verfahren 800 schließt ferner optional das Instanziieren 812 einer ersten SDAP-Schicht an der MT ein. In diesen Fällen kann es sein, dass die ersten Daten zwischen den MT und dem IAB-Donor über die erste SDAP-Schicht transportiert werden.
  • Das Verfahren 800 schließt ferner optional das Instanziieren 814 einer zweiten SDAP-Schicht an der DU ein. In diesen Fällen kann es sein, dass die zweiten Daten zwischen der DU und der ersten UE über die zweite SDAP-Schicht transportiert werden.
  • In einigen Ausführungsformen des Verfahrens 800 umfassen die ersten Daten aktualisierten Inhalt für die lokale Anwendungsinstanz.
  • In einigen Ausführungsformen des Verfahrens 800 umfasst der IAB-Knoten ein eRG.
  • Einige Ausführungsformen des Verfahrens 800 schließen ferner das Aggregieren eines Trägers der ersten UE mit einem Träger einer zweiten UE ein, die mit dem IAB-Knoten innerhalb eines PDCP-Kanals zwischen der ersten PDCP-Schicht und einer zweiten PDCP-Schicht des IAB-Donors verbunden ist.
  • In einigen Ausführungsformen des Verfahrens 800 umfassen die zweiten Daten URLLC-Daten. In einigen dieser Ausführungsformen schließt das Verfahren 800 ferner das Transportieren dritter Daten zwischen dem IAB-Donor und der ersten UE gemäß einer L2-Relais-Funktionalität ein.
  • Einige Ausführungsformen des Verfahrens 800 schließen ferner das Transportieren der ersten Daten zwischen der DU und der MT unter Verwendung einer TCP/IP-Schicht der DU ein, die eine Schnittstelle mit der ersten PDCP-Schicht bildet. In einigen dieser Ausführungsformen werden die zweiten Daten unter Verwendung der TCP/IP-Schicht zu der ersten UE transportiert.
  • Einige Ausführungsformen des Verfahrens 800 schließen ferner ein Instanziieren eines Sidelink-Protokollstapels am IAB-Knoten ein, wobei die zweiten Daten zwischen dem IAB-Knoten und der ersten UE unter Verwendung des Sidelink-Protokollstapels transportiert werden.
  • Ausführungsformen, die hierin in Betracht gezogen werden, schließen eine Einrichtung ein, die Mittel zum Durchführen eines oder mehrerer Elemente des Verfahrens 800 umfasst. Diese Einrichtung kann zum Beispiel eine Einrichtung eines IAB-Knotens (wie eine drahtlose Netzwerkvorrichtung 1016, die ein IAB-Knoten ist, wie hierin beschrieben) sein.
  • Hierin in Betracht gezogene Ausführungsformen schließen ein oder mehrere nicht-transitorische computerlesbare Medien ein, die Anweisungen umfassen, um zu bewirken, dass eine elektronische Vorrichtung bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung eines oder mehrere Elemente des Verfahrens 800 durchführt. Dieses nicht-transitorische computerlesbare Medium kann zum Beispiel ein Speicher eines IAB-Knotens (wie ein Speicher 1020 einer drahtlosen Netzwerkvorrichtung 1016, die ein IAB-Knoten ist, wie hierin beschrieben) sein.
  • Ausführungsformen, die hierin in Betracht gezogen werden, schließen eine Einrichtung ein, die Logik, Module oder Schaltlogik umfasst, um eines oder mehrere Elemente des Verfahrens 800 durchzuführen. Diese Einrichtung kann zum Beispiel eine Einrichtung eines IAB-Knotens (wie eine drahtlose Netzwerkvorrichtung 1016, die ein IAB-Knoten ist, wie hierin beschrieben) sein.
  • Hierin in Betracht gezogene Ausführungsformen schließen eine Einrichtung ein, die einen oder mehrere Prozessoren und eines oder mehrere computerlesbare Medien umfasst, die Anweisungen umfassen, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eines oder mehrere Elemente des Verfahrens 800 durchzuführen. Diese Einrichtung kann zum Beispiel eine Einrichtung eines IAB-Knotens (wie eine drahtlose Netzwerkvorrichtung 1016, die ein IAB-Knoten ist, wie hierin beschrieben) sein.
  • Ausführungsformen, die hierin in Betracht gezogen werden, schließen ein Signal ein, wie es in einem oder mehreren Elementen des Verfahrens 800 beschrieben ist oder diese betrifft.
  • Ausführungsformen, die hierin in Betracht gezogen werden, schließen ein Computerprogramm oder ein Computerprogrammprodukt ein, das Anweisungen umfasst, wobei die Ausführung des Programms durch ein Verarbeitungselement dazu dient, das Verarbeitungselement zu veranlassen, eines oder mehrere Elemente des Verfahrens 800 auszuführen. Der Prozessor kann ein Prozessor eines IAB-Knotens sein (wie einer oder mehrere Prozessoren 1004 einer Netzwerkvorrichtung 1016, die ein IAB-Knoten ist, wie hierin beschrieben). Diese Anweisungen können zum Beispiel in dem Prozessor und/oder auf einem Speicher des IAB-Knotens (wie einem Speicher 1006 einer Netzwerkvorrichtung 1016, die ein IAB-Knoten ist, wie hierin beschrieben) angeordnet sein.
  • 9 veranschaulicht eine Beispielarchitektur eines drahtlosen Kommunikationssystems 900 gemäß hierin offenbarter Ausführungsformen. Die folgende Beschreibung wird für ein drahtloses Beispielkommunikationssystem 900 bereitgestellt, das in Verbindung mit den LTE-Systemstandards und 5G- oder NR-Systemstandards arbeitet, wie durch die technischen Spezifikationen von 3GPP bereitgestellt.
  • Wie von 9 gezeigt, schließt das drahtlose Kommunikationssystem 900 eine UE 902 und eine UE 904 ein (obwohl eine beliebige Anzahl von UEs verwendet werden kann). In diesem Beispiel sind die UE 902 und die UE 904 als Smartphones (z. B. handgehaltene mobile Touchscreen-Rechenvorrichtungen, die mit einem oder mehreren Mobilfunknetzen verbindbar sind) veranschaulicht, können aber auch eine beliebige mobile oder nicht mobile Rechenvorrichtung umfassen, die für drahtlose Kommunikation konfiguriert ist.
  • Die UE 902 und die UE 904 können konfiguriert sein, um mit einem RAN 906 kommunikativ gekoppelt zu werden. In Ausführungsformen kann das RAN 906 ein NG-RAN, e-UTRAN usw. sein. Die UE 902 und UE 904 benutzen Verbindungen (oder Kanäle) (gezeigt als Verbindung 908 bzw. Verbindung 910) mit dem RAN 906, von denen jede eine physische Kommunikationsschnittstelle umfasst. Das RAN 906 kann einen oder mehrere Knoten, wie eine Basisstation 912 und/oder den IAB-Knoten 914, einschließen, welche die Verbindung 908 und die Verbindung 910 ermöglichen.
  • In diesem Beispiel sind die Verbindung 908 und die Verbindung 910 Luftschnittstellen, um eine solche kommunikative Kopplung zu ermöglichen, und können mit einer oder mehreren RAT(s) konsistent sein, die von dem RAN 906 verwendet werden, wie zum Beispiel LTE und/oder NR.
  • In manchen Ausführungsformen können die UE 902 und die UE 904 Kommunikationsdaten auch direkt über eine Sidelink-Schnittstelle 916 austauschen. Die UE 904 ist so konfiguriert, dass sie über eine Verbindung 920 auf einen Zugangspunkt (als AP 918 gezeigt) zugreift.
  • Die Verbindung 920 kann beispielhaft eine lokale drahtlose Verbindung umfassen, wie eine Verbindung, die mit einem beliebigen IEEE-1002.11-Protokoll konsistent ist, wobei der AP 918 einen Wi-Fi®-Router umfassen kann. In diesem Beispiel kann der AP 918 mit einem anderen Netzwerk (zum Beispiel dem Internet) verbunden sein, ohne dass ein CN 924 durchlaufen wird.
  • In Ausführungsformen können die UE 902 und die UE 904 konfiguriert sein, um unter Verwendung von „Orthogonal Frequency Division Multiplexing“-Kommunikationssignalen (OFDM-Kommunikationssignalen) miteinander oder mit der Basisstation 912 und/oder dem IAB-Knoten 914 über einen Mehrträgerkommunikationskanal gemäß verschiedenen Kommunikationstechniken zu kommunizieren, wie, jedoch nicht beschränkt auf, eine „Orthogonal Frequency Division Multiplexing“-Kommunikationstechnik (OFDMA-Kommunikationstechnik) (z. B. für Downlink-Kommunikationen) oder eine „Single Carrier Frequency Division Multiple Access“-Kommunikationstechnik (SC-FDMA)-Kommunikationstechnik) (z. B. für Uplink- und ProSe- oder Sidelink-Kommunikationen), obwohl der Umfang der Ausführungsformen in dieser Hinsicht nicht beschränkt ist. Die OFDM-Signale können eine Vielzahl von orthogonalen Hilfsträgern umfassen.
  • In manchen Ausführungsformen können alle oder Teile der Basisstation 912 oder des IAB-Knotens 914 als eine oder mehrere Softwareentitäten implementiert sein, die auf Servercomputern als Teil eines virtuellen Netzwerks laufen. Zusätzlich oder in anderen Ausführungsformen kann die Basisstation 912 oder der IAB-Knoten 914 konfiguriert sein, um über eine Schnittstelle 922 miteinander zu kommunizieren. In Ausführungsformen, in denen das drahtlose Kommunikationssystem 900 ein LTE-System ist (z. B. wenn das CN 924 ein EPC ist), kann die Schnittstelle 922 eine X2-Schnittstelle sein. Die X2-Schnittstelle kann zwischen zwei oder mehr Basisstationen (z. B. zwei oder mehr eNBs und dergleichen), die mit einem EPC verbunden sind, und/oder zwischen zwei eNBs, die mit dem EPC verbunden sind, definiert sein. In Ausführungsformen, in denen das drahtlose Kommunikationssystem 900 ein NR-System ist (z. B. wenn das CN 924 ein 5GC ist), kann die Schnittstelle 922 eine Xn-Schnittstelle sein. Die Xn-Schnittstelle ist zwischen zwei oder mehr Basisstationen (z. B. zwei oder mehr gNBs und dergleichen), die mit 5GC verbunden sind, zwischen einer Basisstation 912 (z. B. einem gNB), die mit 5GC verbunden ist, und einem eNB und/oder zwischen zwei eNBs, die mit 5GC (z. B. dem CN 924) verbunden sind, definiert.
  • Der RAN 906 ist als kommunikativ mit dem CN 924 gekoppelt gezeigt. Das CN 924 kann ein oder mehrere Netzwerkelemente 926 umfassen, die konfiguriert sind, um Kunden/Teilnehmern (z. B. Benutzern der UE 902 und der UE 904), die mit dem CN 924 über das RAN 906 verbunden sind, verschiedene Daten- und Telekommunikationsdienste anzubieten. Die Komponenten des CN 924 können in einer physischen Vorrichtung oder separaten physischen Vorrichtungen implementiert sein, einschließlich Komponenten zum Lesen und Ausführen von Anweisungen von einem maschinenlesbaren oder computerlesbaren Medium (z. B. einem nicht-transitorischen maschinenlesbaren Speicherungsmedium).
  • In Ausführungsformen kann das CN 924 ein EPC sein und das RAN 906 kann über eine S1-Schnittstelle 928 mit dem CN 924 verbunden sein. In Ausführungsformen kann die S1-Schnittstelle 928 in zwei Teile aufgeteilt sein, eine S 1-Benutzerebenen-Schnittstelle (S1-U-Schnittstelle), die Verkehrsdaten zwischen der Basisstation 912 oder dem IAB-Knoten 914 und einem Serving Gateway (S-GW) trägt, und die S1-MME-Schnittstelle, die eine Signalisierungsschnittstelle zwischen der Basisstation 912 oder dem IAB-Knoten 914 und Mobilitätsverwaltungsentitäten (MMEs) ist.
  • In Ausführungsformen kann das CN 924 ein 5GC sein und das RAN 906 kann über eine NG-Schnittstelle 928 mit dem CN 924 verbunden sein. In Ausführungsformen kann die NG-Schnittstelle 928 in zwei Teile aufgeteilt sein, eine NG-Benutzerebenen-Schnittstelle (NG-U-Schnittstelle), die Verkehrsdaten zwischen der Basisstation 912 oder dem IAB-Knoten 914 und einer Benutzerebenenfunktion (UPF) trägt, und die S1-Steuerungsebenenschnittstelle (NG-C-Schnittstelle), die eine Signalisierungsschnittstelle zwischen der Basisstation 912 oder dem IAB-Knoten 914 und Zugangs- und Mobilitätsverwaltungsfunktionen (AMFs) ist.
  • Allgemein kann ein Anwendungsserver 930 ein Element sein, das Anwendungen bietet, die Internetprotokoll-Trägerressourcen (IP -Trägerressourcen) mit dem CN 924 (z. B. paketvermittelten Datendiensten) verwenden. Der Anwendungsserver 930 kann auch konfiguriert sein, um einen oder mehrere Kommunikationsdienste (z. B. VoIP-Sitzungen, Gruppenkommunikationssitzungen usw.) für die UE 902 und die UE 904 über das CN 924 zu unterstützen. Der Anwendungsserver 930 kann mit dem CN 924 über eine IP-Kommunikationsschnittstelle 932 kommunizieren.
  • 10 veranschaulicht ein System 1000 zum Durchführen einer Signalisierung 1032 zwischen einer drahtlosen Vorrichtung 1002 und einer Netzwerkvorrichtung 1016 gemäß hierin offenbarten Ausführungsformen. Das System 1000 kann ein Abschnitt eines drahtlosen Kommunikationssystems sein, wie hierin beschrieben. Die drahtlose Vorrichtung 1002 kann zum Beispiel eine UE eines drahtlosen Kommunikationssystems sein. Die Netzwerkvorrichtung 1016 kann zum Beispiel ein IAB-Knoten eines drahtlosen Kommunikationssystems sein.
  • Die drahtlose Vorrichtung 1002 kann einen oder mehrere Prozessoren 1004 einschließen. Der/die Prozessor(en) 1004 kann/können Anweisungen ausführen, so dass verschiedene Vorgänge der drahtlosen Vorrichtung 1002 durchgeführt werden, wie hierin beschrieben. Der/die Prozessor(en) 1004 kann/können einen oder mehrere Basisbandprozessoren einschließen, die zum Beispiel unter Verwendung einer zentralen Verarbeitungseinheit (CPU), eines digitalen Signalprozessors (DSP), einer anwendungsspezifischen integrierten Schaltung (ASIC), einer Steuerung, einer feldprogrammierbaren Gate-Array-Vorrichtung (FPGA-Vorrichtung), einer anderen Hardwarevorrichtung, einer Firmwarevorrichtung oder einer beliebigen Kombination davon implementiert sind, die konfiguriert sind, um die hierin beschriebenen Vorgänge durchzuführen.
  • Die drahtlose Vorrichtung 1002 kann einen Speicher 1006 einschließen. Der Speicher 1006 kann ein nicht-transitorisches computerlesbares Speicherungsmedium sein, das Anweisungen 1008 speichert (die zum Beispiel die Anweisungen einschließen können, die von dem/den Prozessor(en) 1004 ausgeführt werden). Die Anweisungen 1008 können auch als Programmcode oder Computerprogramm bezeichnet werden. Der Speicher 1006 kann auch Daten, die von dem/den Prozessor(en) 1004 verwendet werden, und Ergebnisse, die davon berechnet werden, speichern.
  • Die drahtlose Vorrichtung 1002 kann einen oder mehrere Transceiver 1010 einschließen, die Hochfrequenz (HF)-Sender- und/oder -Empfängerschaltlogik einschließen können, welche die Antenne(n) 1012 der drahtlosen Vorrichtung 1002 verwenden, um eine Signalisierung (z. B. die Signalisierung 1032) an und/oder von der drahtlosen Vorrichtung 1002 mit anderen Vorrichtungen (z. B. der Netzwerkvorrichtung 1016) gemäß entsprechenden RATs zu ermöglichen.
  • Die drahtlose Vorrichtung 1002 kann eine oder mehrere Antennen 1012 (z. B. eine, zwei, vier oder mehr) einschließen. Für Ausführungsformen mit mehreren Antennen 1012 kann die drahtlose Vorrichtung 1002 die räumliche Vielfalt solcher mehrerer Antennen 1012 nutzen, um mehrere unterschiedliche Datenströme auf die gleichen Zeit- und Frequenzressourcen zu senden und/oder zu empfangen. Dieses Verhalten kann zum Beispiel als „Multiple Input Multiple Output“-Verhalten (MIMO-Verhalten) bezeichnet werden (Bezug nehmend auf die mehreren Antennen, die jeweils an einer Übertragungsvorrichtung und einer Empfangsvorrichtung verwendet werden, die diesen Aspekt ermöglichen). MIMO-Übertragungen durch die drahtlose Vorrichtung 1002 können gemäß Vorcodieren (oder digitalem Strahlformen) erreicht werden, die an der drahtlosen Vorrichtung 1002 angewendet wird, die Datenströme über die Antenne(n) 1012 gemäß bekannten oder angenommenen Kanaleigenschaften multiplexiert, sodass jeder Datenstrom mit einer geeigneten Signalstärke relativ zu anderen Strömen und an einem gewünschten Ort in der räumlichen Domäne empfangen wird (z. B. der Standort eines Empfängers, der diesem Datenstrom zugeordnet ist). Bestimmte Ausführungsformen können Einzelbenutzer-MIMO-Verfahren (SU-MIMO-Verfahren) verwenden (wobei die Datenströme alle auf einen einzelnen Empfänger gerichtet sind) und/oder Mehrfachbenutzer-MIMO-Verfahren (MU-MIMO-Verfahren) (wobei einzelne Datenströme an einzelne (unterschiedliche) Empfänger an unterschiedlichen Standorten in der räumlichen Domäne gerichtet sein können).
  • In bestimmten Ausführungsformen, die mehrere Antennen aufweisen, kann die drahtlose Vorrichtung 1002 analoge Strahlformungstechniken implementieren, wobei Phasen der Signale, die von der/den Antenne(n) 1012 gesendet werden, relativ eingestellt sind, sodass die (gemeinsame) Übertragung der Antenne(n) 1012 gerichtet sein kann (dies wird manchmal als Strahlsteuerung bezeichnet).
  • Die drahtlose Vorrichtung 1002 kann auch eine oder mehrere Schnittstellen 1014 einschließen. Die Schnittstelle(n) 1014 kann/können verwendet werden, um eine Eingabe an oder eine Ausgabe von der drahtlosen Vorrichtung 1002 bereitzustellen. Zum Beispiel kann eine drahtlose Vorrichtung 1002, die eine UE ist, die Schnittstelle(n) 1014 einschließen, wie Mikrofone, Lautsprecher, einen Touchscreen, Tasten/Schaltflächen und dergleichen, um die Eingabe und/oder Ausgabe von einem Benutzer der UE an die UE zu ermöglichen. Andere Schnittstellen einer solchen UE können aus Überträgern, Empfängern und anderer Schaltlogik aufgebaut sein (z. B. anderen als den/die Transceiver 1010/Antenne(n) 1012, die bereits beschrieben sind), die eine Kommunikation zwischen der UE und anderen Vorrichtungen ermöglichen und gemäß bekannten Protokollen arbeiten können (z. B. Wi-Fi®, Bluetooth® und dergleichen).
  • Die Netzwerkvorrichtung 1016 kann einen oder mehrere Prozessoren 1018 einschließen. Der/die Prozessor(en) 1018 können Anweisungen ausführen, so dass verschiedene Vorgänge der Netzwerkvorrichtung 1016 durchgeführt werden, wie hierin beschrieben. Der/die Prozessor(en) 1004 können einen oder mehrere Basisbandprozessoren einschließen, die zum Beispiel unter Verwendung einer CPU, eines DSP, einer ASIC, einer Steuerung, einer FPGA-Vorrichtung, einer anderen Hardwarevorrichtung, einer Firmwarevorrichtung oder einer beliebigen Kombination davon implementiert sind, die konfiguriert sind, um die hierin beschriebenen Vorgänge durchzuführen.
  • Die Netzwerkvorrichtung 1016 kann einen Speicher 1020 einschließen. Der Speicher 1020 kann ein nicht-transitorisches computerlesbares Speicherungsmedium sein, das Anweisungen 1022 speichert (die zum Beispiel die Anweisungen einschließen können, die von dem/den Prozessor(en) 1018 ausgeführt werden). Die Anweisungen 1022 können auch als Programmcode oder Computerprogramm bezeichnet werden. Der Speicher 1020 kann auch Daten, die von dem/den Prozessor(en) 1018 verwendet werden, und Ergebnisse, die davon berechnet werden, speichern.
  • Die Netzwerkvorrichtung 1016 kann einen oder mehrere Transceiver 1024 einschließen, die HF-Überträger- und/oder Empfängerschaltlogik einschließen können, welche die Antenne(n) 1026 der Netzwerkvorrichtung 1016 verwenden, um eine Signalisierung (z. B. die Signalisierung 1032) an und/oder von der Netzwerkvorrichtung 1016 mit anderen Vorrichtungen (z. B. der drahtlosen Vorrichtung 1002) gemäß entsprechenden RATs zu ermöglichen.
  • Die Netzwerkvorrichtung 1016 kann eine oder mehrere Antennen 1026 (z. B. eine, zwei, vier oder mehr) einschließen. In Ausführungsformen mit mehreren Antenne(n) 1026 kann die Netzwerkvorrichtung 1016 MIMO, digitale Strahlformung, analoge Strahlformung, Strahlsteuerung usw. durchführen, wie beschrieben wurde.
  • Die Netzwerkvorrichtung 1016 kann eine oder mehrere Schnittstellen 1028 einschließen. Die Schnittstelle(n) 1028 können verwendet werden, um eine Eingabe oder Ausgabe von der Netzwerkvorrichtung 1016 bereitzustellen. Zum Beispiel kann eine Netzwerkvorrichtung 1016, die eine Basisstation ist, eine oder mehrere Schnittstellen 1028, die aus Überträgern, Empfängern und anderer Schaltlogik (z. B. anderen als den/die Transceiver 1024/Antenne(n) 1026, die bereits beschrieben sind) aufgebaut sind, einschließen, die es der Basisstation ermöglicht/ermöglichen, mit anderer Ausrüstung in einem Kernnetzwerk zu kommunizieren, und/oder die es der Basisstation ermöglicht/ermöglichen, mit externen Netzwerken, Computern, Datenbanken und dergleichen zu Zwecken von Vorgängen, Verwaltung und Wartung der Basisstation oder anderer Ausrüstung, die funktionsfähig damit verbunden sind, zu kommunizieren.
  • Die Netzwerkvorrichtung 1016 kann ein IAB-MEC-Modul 1030 einschließen. Das IAB-MEC-Modul 1030 kann über Hardware, Software oder Kombinationen davon implementiert werden. Zum Beispiel kann das IAB-MEC-Modul 1030 als Prozessor, Schaltung und/oder Anweisungen 1022 implementiert sein, die in dem Speicher 1020 gespeichert und von dem/den Prozessor(en) 1018 ausgeführt wird/werden. In manchen Beispielen kann das IAB-MEC-Modul 1030 innerhalb des/der Prozessors/Prozessoren 1018 und/oder des/der Transceiver(s) 1024 integriert sein. Zum Beispiel kann das IAB-MEC-Modul 1030 durch eine Kombination von Softwarekomponenten (z. B. ausgeführt durch einen DSP oder einen allgemeinen Prozessor) und Hardwarekomponenten (z. B. Logik-Gates und Schaltlogik) innerhalb des/der Prozessors/Prozessoren 1018 oder des/der Transceiver(s) 1024 implementiert werden.
  • Das IAB-MEC-Modul 1030 kann für verschiedene Gesichtspunkte der vorliegenden Offenbarung verwendet werden, zum Beispiel Gesichtspunkte von 5 bis 8. Zum Beispiel kann für eine Netzwerkvorrichtung 1016, die ein IAB-Knoten für MEC (eine IAB-MEC) ist, das IAB-MEC-Modul 1030 so konfiguriert sein, dass es den Transport von Daten einer lokalen Anwendungsinstanz der IAB-MEC zu einer oder mehreren UE, die mit der IAB-MEC verbunden sind, erleichtern, ohne diese Daten an oder durch einen vorgelagerten Elternknoten eines IAB-Netzwerks der IAB-MEC zu senden. Um dieses Verhalten zu erleichtern, kann das IAB-MEC-Modul 1030 so konfiguriert sein, dass es die TCP/IP-Schicht(en), die PDCP-Schicht(en), die SDAP-Schicht(en) und/oder einen PC5-Protokollstapel der IAB-MEC auf die vorstehend beschriebene Weise instanziiert und verwendet.
  • Für eine oder mehrere Ausführungsformen kann mindestens eine der Komponenten, die in einer oder mehreren der vorhergehenden Figuren dargelegt sind, konfiguriert sein, um einen oder mehrere Vorgänge, Techniken, Prozesse und/oder Verfahren durchzuführen, wie hierin dargelegt. Zum Beispiel kann ein Basisbandprozessor, wie hierin in Verbindung mit einer oder mehreren der vorhergehenden Figuren beschrieben, konfiguriert sein, um gemäß einem oder mehreren der hierin dargelegten Beispiele zu arbeiten. Für ein anderes Beispiel kann eine Schaltlogik, die einer UE, einer Basisstation, einem Netzwerkelement usw. zugeordnet ist, wie vorstehend in Verbindung mit einer oder mehreren der vorhergehenden Figuren beschrieben, konfiguriert sein, um gemäß einem oder mehreren der hierin dargelegten Beispiele zu arbeiten.
  • Jedes der oben beschriebenen Beispiele kann mit einer beliebigen anderen Ausführungsform (oder jeder Kombination von Ausführungsformen) kombiniert werden, sofern nicht explizit anders angegeben. Die vorstehende Beschreibung einer oder mehrerer Implementierungen stellt Veranschaulichung und Beschreibung bereit, erhebt jedoch keinen Anspruch auf Vollständigkeit und soll den Schutzumfang der Ausführungsformen nicht auf die präzise offenbarte Form beschränken. Modifikationen und Variationen sind angesichts der vorstehenden Lehren möglich oder können aus der Praxis verschiedener Ausführungsformen erlangt werden.
  • Ausführungsformen und Implementierungen der hierin beschriebenen Systeme und Verfahren können verschiedene Vorgänge einschließen, die in maschinenausführbaren Anweisungen verkörpert sein können, die von einem Computersystem auszuführen sind. Ein Computersystem kann einen oder mehrere Allzweck- oder Spezialcomputer (oder andere elektronische Vorrichtungen) einschließen. Das Computersystem kann Hardwarekomponenten einschließen, die eine spezifische Logik zum Durchführen der Operationen einschließen oder eine Kombination von Hardware, Software und/oder Firmware einschließen können.
  • Es sollte erkannt werden, dass die hierin beschriebenen Systeme Beschreibungen spezifischer Ausführungsformen einschließen. Diese Ausführungsformen können zu einzelnen Systemen kombiniert werden, teilweise zu anderen Systemen kombiniert, in mehrere Systeme aufgeteilt oder auf andere Weise aufgeteilt oder kombiniert werden. Zusätzlich wird in Betracht gezogen, dass Parameter, Attribute, Aspekte usw. einer Ausführungsform in einer anderen Ausführungsform verwendet werden können. Die Parameter, Attribute, Aspekte usw. werden lediglich in einer oder mehreren Ausführungsformen zur Klarheit beschrieben, und es wird anerkannt, dass die Parameter, Attribute, Aspekte usw. mit Parametern, Attributen, Aspekten usw. einer anderen Ausführungsform kombiniert oder ersetzt werden können, sofern nicht ausdrücklich hierin darauf verzichtet wird.
  • Es versteht sich von selbst, dass bei der Verwendung von personenbezogenen Daten Datenschutzrichtlinien und -praktiken befolgt werden sollten, die allgemein anerkannt sind und branchenspezifischen oder behördlichen Anforderungen zur Wahrung der Privatsphäre der Benutzer entsprechen oder diese übertreffen. Insbesondere sollten personenbezogene Daten so verwaltet und gehandhabt werden, dass das Risiko eines unbeabsichtigten oder unbefugten Zugriffs oder einer unbefugten Nutzung minimiert wird, und die Art der genehmigten Nutzung sollte den Benutzern klar angezeigt werden.
  • Obwohl das Vorstehende in einigen Details zu Zwecken der Klarheit beschrieben wurde, ist es offensichtlich, dass bestimmte Änderungen und Modifikationen vorgenommen werden können, ohne von den Prinzipien davon abzuweichen. Es sollte beachtet werden, dass es viele alternative Möglichkeiten gibt, sowohl die hierin beschriebenen Prozesse als auch Einrichtungen zu implementieren. Dementsprechend sind die vorliegenden Ausführungsformen als veranschaulichend und nicht einschränkend zu betrachten und die Beschreibung ist nicht auf die hierin angegebenen Details beschränkt, sondern kann innerhalb des Umfangs und der Äquivalente der beigefügten Ansprüche modifiziert werden.

Claims (26)

  1. Integrierter Zugangs- und Backhaul-Knoten (IAB-Knoten), der für Multi-Access Edge Computing (MEC) konfiguriert ist und Folgendes umfasst: eine verteilte Einheit (distributed unit, DU), umfassend: eine lokale Anwendungsinstanz einer MEC-fähigen Anwendung, wobei die lokale Anwendungsinstanz für die Kommunikation mit einer ersten Benutzerausrüstung (UE) konfiguriert ist, die mit dem IAB-Knoten verbunden ist; und eine mobile Terminierungsfunktionalität (MT), umfassend: eine erste Paket Data Convergence Protocol (PDCP)-Schicht, die konfiguriert ist, um erste Daten der lokalen Anwendungsinstanz zwischen den MT und einem IAB-Donor zu transportieren.
  2. IAB-Knoten nach Anspruch 1, wobei die ersten Daten aktualisierten Inhalt für die lokale Anwendungsinstanz umfassen.
  3. IAB-Knoten nach Anspruch 1, wobei der IAB-Knoten ein evolved Residential Gateway (eRG) umfasst.
  4. IAB-Knoten nach Anspruch 1, wobei der IAB-Knoten konfiguriert ist, um einen Träger der ersten UE mit einem Träger einer zweiten UE zu aggregieren, die mit dem IAB-Knoten innerhalb eines PDCP-Kanals zwischen der ersten PDCP-Schicht und einer zweiten PDCP-Schicht des IAB-Donors verbunden ist.
  5. IAB-Knoten nach Anspruch 1, wobei die DU ferner umfasst: eine zweite PDCP-Schicht, die konfiguriert ist, um zweite Daten der lokalen Anwendungsinstanz zwischen der DU und der ersten UE zu transportieren.
  6. IAB-Knoten nach Anspruch 5, wobei die erste PDCP-Schicht und die zweite PDCP-Schicht konfiguriert sind, um die ersten Daten zwischen der DU und der MT zu transportieren.
  7. IAB-Knoten nach Anspruch 5, wobei: die MT ferner eine erste Service Data Adaptation Protocol (SDAP)-Schicht umfasst, die konfiguriert ist, um die ersten Daten zwischen der MT und dem IAB-Donor zu transportieren; und die DU ferner eine zweite SDAP-Schicht umfasst, die konfiguriert ist, um die zweiten Daten zwischen der DU und der ersten UE zu transportieren.
  8. IAB-Knoten nach Anspruch 1, wobei: die DU ferner umfasst: eine Transmission Control Protocol/Internet Protocol (TCP/IP)-Schicht, die konfiguriert ist, um eine Schnittstelle mit der ersten PDCP-Schicht zu bilden, um die ersten Daten zwischen der DU und der MT zu transportieren.
  9. IAB-Knoten nach Anspruch 8, wobei die TCP/IP-Schicht ferner konfiguriert ist, um zweite Daten der lokalen Anwendungsinstanz zwischen der UE und der DU zu transportieren.
  10. IAB-Knoten nach Anspruch 9, wobei die zweiten Daten ultra-reliable low-latency communication (URLLC)-Daten umfassen.
  11. IAB-Knoten nach Anspruch 10, wobei: der IAB-Knoten ferner konfiguriert ist, um dritte Daten zwischen dem IAB-Donor und der ersten UE gemäß einer Schicht 2-(L2)-Relais-Funktionalität zu transportieren.
  12. IAB-Knoten nach Anspruch 1, ferner umfassend: einen Sidelink-Protokollstapel, der konfiguriert ist, um zweite Daten der lokalen Anwendungsinstanz zwischen der UE und dem IAB-Knoten zu transportieren.
  13. Verfahren eines integrierten Zugangs- und Backhaul-Knotens (IAB-Knotens), umfassend: Instanziieren einer lokalen Anwendungsinstanz einer Multi-Access Edge Computing (MEC)-fähigen Anwendung in einer verteilten Einheit (DU) des IAB-Knotens; Instanziieren einer ersten Packet Data Convergence Protocol (PDCP)-Schicht an einer mobilen Terminierungsfunktionalität (MT) des IAB-Knotens; Transportieren von ersten Daten der lokalen Anwendungsinstanz zwischen einem IAB-Donor und der MT unter Verwendung der ersten PDCP-Schicht; und Transportieren von zweiten Daten der lokalen Anwendungsinstanz zwischen einer ersten Benutzerausrüstung (UE), die mit dem IAB-Knoten verbunden ist, und dem IAB-Knoten.
  14. Verfahren nach Anspruch 13, wobei die ersten Daten aktualisierten Inhalt für die lokale Anwendungsinstanz umfassen.
  15. Verfahren nach Anspruch 13, wobei der IAB-Knoten ein evolved Residential Gateway (eRG) umfasst.
  16. Verfahren nach Anspruch 13, ferner umfassend: Aggregieren eines Trägers der ersten UE mit einem Träger einer zweiten UE, die mit dem IAB-Knoten innerhalb eines PDCP-Kanals zwischen der ersten PDCP-Schicht und einer zweiten PDCP-Schicht des IAB-Donors verbunden ist.
  17. Verfahren nach Anspruch 13, wobei die zweiten Daten ultra-reliable low-latency communication (URLLC)-Daten umfassen.
  18. Verfahren nach Anspruch 17, ferner umfassend: Transportieren von dritten Daten zwischen dem IAB-Donor und der ersten UE gemäß einer Schicht 2 (L2)-Relais-Funktionalität.
  19. Verfahren nach Anspruch 13, ferner umfassend: Instanziieren einer zweiten PDCP-Schicht an der DU; wobei: die zweiten Daten zwischen der DU und der ersten UE unter Verwendung der zweiten PDCP-Schicht transportiert werden.
  20. Verfahren nach Anspruch 19, ferner umfassend: Transportieren der ersten Daten zwischen der DU und der MT unter Verwendung der ersten PDCP-Schicht und der zweiten PDCP-Schicht.
  21. Verfahren nach Anspruch 19, ferner umfassend: Instanziieren einer ersten Service Data Adaptation Protocol (SDAP)-Schicht an der MT, wobei die ersten Daten zwischen der MT und dem IAB-Donor über die erste SDAP-Schicht transportiert werden; und Instanziieren einer zweiten SDAP-Schicht an der DU, wobei die zweiten Daten zwischen der DU und der ersten UE über die zweite SDAP-Schicht transportiert werden.
  22. Verfahren nach Anspruch 13, ferner umfassend: Transportieren der ersten Daten zwischen der DU und der MT unter Verwendung einer Transmission Control Protocol/Internet Protocol (TCP/IP)-Schicht der DU, die eine Schnittstelle zu der ersten PDCP-Schicht bildet.
  23. Verfahren nach Anspruch 22, wobei die zweiten Daten unter Verwendung der TCP/IP-Schicht zu der ersten UE transportiert werden.
  24. Verfahren nach Anspruch 13, ferner umfassend: Instanziieren eines Sidelink-Protokollstapels am IAB-Knoten; wobei: die zweiten Daten zwischen dem IAB-Knoten und der ersten UE unter Verwendung des Sidelink-Protokollstapels transportiert werden.
  25. Computerprogrammprodukt, umfassend Anweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, Schritte des Verfahrens nach einem der Ansprüche 13 bis Anspruch 24 implementieren.
  26. Einrichtung, die Mittel zum Implementieren von Schritten des Verfahrens nach einem der Ansprüche 13 bis Anspruch 24 umfasst.
DE112021007893.3T 2021-06-28 2021-06-28 Systeme und verfahren für iab-mec Pending DE112021007893T5 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/102762 WO2023272436A1 (en) 2021-06-28 2021-06-28 Systems and methods for iab mec

Publications (1)

Publication Number Publication Date
DE112021007893T5 true DE112021007893T5 (de) 2024-04-25

Family

ID=84690955

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021007893.3T Pending DE112021007893T5 (de) 2021-06-28 2021-06-28 Systeme und verfahren für iab-mec

Country Status (4)

Country Link
US (1) US20240049000A1 (de)
CN (1) CN117441356A (de)
DE (1) DE112021007893T5 (de)
WO (1) WO2023272436A1 (de)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112368988B (zh) * 2018-06-26 2023-09-22 上海诺基亚贝尔股份有限公司 在集成接入及回程系统中进行动态路由选择
US10708716B2 (en) * 2018-10-16 2020-07-07 Cisco Technology, Inc. Methods and apparatus for selecting network resources for UE sessions based on locations of multi-access edge computing (MEC) resources and applications
CN113422804A (zh) * 2018-11-23 2021-09-21 华为技术有限公司 一种应用实例迁移的方法及多接入边缘计算主机

Also Published As

Publication number Publication date
WO2023272436A1 (en) 2023-01-05
US20240049000A1 (en) 2024-02-08
CN117441356A (zh) 2024-01-23

Similar Documents

Publication Publication Date Title
Akyildiz et al. Wireless software-defined networks (W-SDNs) and network function virtualization (NFV) for 5G cellular systems: An overview and qualitative evaluation
US11375517B2 (en) End to end slicing in wireless communications systems
DE112006000662B4 (de) Mobilgerätübergabe unter Einsatz von Multicast in einem Multi-Protocol-Label-Switching-(MPLS)-Netzwerk
DE102014104197B4 (de) Kommunikationseinrichtung und Verfahren zum Ausführen von Funkkommunikation
DE112005001958B4 (de) Verfahren und System zur Netzverwaltung und Dienstbereitstellung für Breitband-Funknetze
DE112018003906T5 (de) Verfahren und Vorrichtung zur flexiblen Aufteilung der physikalischen Fronthaul-Schicht für Cloud-Funkzugangsnetze
DE112018000196T5 (de) Codebuch-teilmengen-einschränkung für csi
DE602005004744T2 (de) Kontrollvorrichtung, mobiles Endgerät und Kommunikationskontrollverfahren
CN104145526B (zh) 对多点传输进行无线承载管理的系统和方法
DE112018002337T5 (de) Kommunikationsvorrichtung, infrastrukturausrüstung, drahtloses kommunikationsnetzwerk und verfahren
CN108029037A (zh) Ip层的双连接和载波聚合
CN107925614A (zh) 制定和传播软件可编程无线网络中本地策略决策的系统和方法
CN105165087A (zh) 长期演进无线电接入网络
DE202004017122U1 (de) Vorrichtung für die zentrale Steuerung von Maschennetzen
CN106134245A (zh) 用于在移动通信系统中的蜂窝网络与无线局域网(lan)网络之间引导业务的方法和设备
US11700594B2 (en) Resource isolation in wireless communications systems
DE112014003704T5 (de) Verfahren zur Zellauswahl in einer Multi-RAT-Umgebung
DE112020006494T5 (de) Infrastrukturausrüstung, zentraleinheitsknoten und verfahren
EP3925190B1 (de) Computerimplementierte verfahren und verfahren zur durchführung von computerprogrammen zur bereitstellung von transportkontext und on-path-metadaten zur unterstützung 5g-fähiger netzwerke
DE112021007893T5 (de) Systeme und verfahren für iab-mec
DE112021007889T5 (de) Systeme und Verfahren zur Konfiguration von Kommunikation mit einer IAB MEC
DE102021113144A1 (de) Relais-(neu-)auswahl über sidelink in zellularen netzwerken
DE102021120645A1 (de) Verfahren zur Datenkommunikation zwischen einem Endsystem und einer zur V2X-Kommunikation fähigen Telekommunikationseinheit und ein System dafür
EP3677002B1 (de) Verfahren und anordnung zur paketvermittelten datenübertragung zwischen seeseitigen sende-empfangs-einrichtungen auf einem wasserfahrzeug und landseitigen sende-empfangs-einrichtungen über luftschnittstellen
DE102012102659B4 (de) Kommunikationsendgerät, Verfahren zum Austauschen von Daten, Kommunikationsvorrichtung und Verfahren zum Aufbauen einer Kommunikationsverbindung

Legal Events

Date Code Title Description
R012 Request for examination validly filed