DE102021118717A1 - Sidelink (sl) diskontinuierlicher empfang (drx) verfahren - Google Patents

Sidelink (sl) diskontinuierlicher empfang (drx) verfahren Download PDF

Info

Publication number
DE102021118717A1
DE102021118717A1 DE102021118717.6A DE102021118717A DE102021118717A1 DE 102021118717 A1 DE102021118717 A1 DE 102021118717A1 DE 102021118717 A DE102021118717 A DE 102021118717A DE 102021118717 A1 DE102021118717 A1 DE 102021118717A1
Authority
DE
Germany
Prior art keywords
drx
sidelink
drx cycle
cycle
network
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
DE102021118717.6A
Other languages
English (en)
Inventor
Ansab ALI
Rafia Malik
Sangeetha L. Bangolae
Youn Hyoung Heo
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 DE102021118717A1 publication Critical patent/DE102021118717A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • 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/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

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

Abstract

Vorrichtung für ein New Radio (NR)-Benutzergerät (UE) mit einer Hochfrequenz-(RF)-Schnittstelle und einem oder mehreren Prozessoren, die mit der RF-Schnittstelle gekoppelt sind und eingerichtet sind zum: Erzeugen einer Sidelink-(SL)-Informationsnachricht für diskontinuierlichen Empfang (DRX) auf der Grundlage eines SL-DRX-Zyklus des NR UE; Senden der SL-DRX-Informationsnachricht an eine Basisstation (BS); Empfangen einer Uu-DRX-Konfigurationsnachricht als Reaktion auf die SL-DRX-Informationsnachricht von der BS, wobei die Uu-DRX-Konfigurationsnachricht Anweisungen zum Ausrichten eines Uu-DRX-Zyklus mit dem SL-DRX-Zyklus enthält; und Rekonfigurieren des Uu-DRX-Zyklus auf der Grundlage der Uu-DRX-Konfigurationsnachricht, wobei eine Vielzahl aktiver Dauern des SL-DRX-Zyklus mit einer Vielzahl aktiver Dauern des Uu-DRX-Zyklus übereinstimmt.

Description

  • Querverweis auf verwandte Anmeldung
  • Diese Patentanmeldung beansprucht den Nutzen und die Priorität der U.S. Provisional Anm. Nr. 63/053,886 , eingereicht am 20. Juli 2020, und Nr. 63/094,737 , eingereicht am 21. Oktober 2020.
  • Technisches Gebiet
  • Diese Offenbarung kann allgemein das Gebiet der Drahtlos-Kommunikation betreffen.
  • Hintergrund
  • Das erhebliche Marktinteresse an Energieeinsparungen während des Nebenstellenbetriebs hat den Bedarf an der Definition effizienter Mechanismen zur Bereitstellung von DRX-Funktionalität über Neuer Funk (New Radio - NR) Nebenstellen geschaffen. In dieser Offenbarung werden Mechanismen erörtert, die eine nahtlose Ausrichtung für den Betrieb der SL-DRX-Kommunikation gewährleisten. Darüber hinaus werden in dieser Offenbarung die Auswirkungen des Designs auf den Abdeckungszustand eines Benutzergeräts (UE), der Bedarf an einem dienstqualitätsspezifischen DRX-Zyklus und die Auswirkungen von SL-Mess- und Berichterstattungsverfahren erörtert.
  • Figurenliste
  • In den Zeichnungen beziehen sich gleiche Bezugszeichen im Allgemeinen auf die gleichen Teile in den verschiedenen Ansichten. Die Zeichnungen sind nicht notwendigerweise maßstabsgetreu, wobei der Schwerpunkt im Allgemeinen auf der Veranschaulichung der beispielhaften Prinzipien der Offenbarung liegt. In der folgenden Beschreibung werden verschiedene Aspekte der Offenbarung mit Bezug auf die folgenden Zeichnungen beschrieben, in denen:
    • 1 einen beispielhaften Zyklus von SL DRX darstellt.
    • 2 ein beispielhaftes Netzwerk, das keinen physikalischen Downlink-Steuerungskanal (PDCCH) über Uu für die SL-Planung sendet, wenn sich das UE im DRX-Schlaf befindet, darstellt.
    • 3 einen beispielhaften Zeitplan für PDCCH für Uu und Physical Sidelink Control Channel (PSCCH) für SL, die zu den jeweiligen Aufwachzeiten ankommen, darstellt.
    • 4 ein Flussdiagramm zeigt für die Signalisierung über Uu und SL, um dem Netzwerk die bevorzugte DRX-Konfiguration anzuzeigen.
    • 5 eine beispielhafte Konfiguration von Uu- und SL-DRX-Zyklen mit unterschiedlichen Dauern, aber aufeinander abgestimmten Aufwachzeiten, darstellt.
    • 6 einen beispielhaften Signalisierungsfluss für den Abgleich der SL-DRX-Konfiguration zwischen gleichrangigen UEs über Unicast darstellt.
    • 7 ein beispielhaftes Diagramm für lange und kurze SL-DRX-Zyklen darstellt.
    • 8 die SL-Messberichterstattung mit DRX-Betrieb darstellt.
    • 9 ein Netzwerk darstellt.
    • 10 schematisch ein Drahtlos-Netzwerk zeigt.
    • 11 ein Blockdiagramm ist, das die Hardware-Ressourcen darstellt.
    • 12 ein Verfahren zur Erzeugung von DRX-Konfigurationsinformationen darstellt.
    • 13 ein Verfahren zum Empfang von DRX-Konfigurationsinformationen darstellt.
    • 14 eine Verfahrenskommunikation über einen SL-Kanal darstellt.
  • Detaillierte Beschreibung
  • Die folgende detaillierte Beschreibung bezieht sich auf die beigefügten Zeichnungen. Die gleichen Referenznummern können in verschiedenen Zeichnungen verwendet werden, um gleiche oder ähnliche Elemente zu identifizieren. In der folgenden Beschreibung werden zum Zwecke der Erläuterung und nicht der Einschränkung spezifische Details wie bestimmte Strukturen, Architekturen, Schnittstellen, Techniken usw. dargelegt, um ein umfassendes Verständnis zu ermöglichen. Dem Fachmann, der die vorliegende Offenbarung/Erfindung kennt, wird jedoch klar sein, dass verschiedene Aspekte der verschiedenen Ausführungsformen in anderen Beispielen verwirklicht werden können, die von diesen spezifischen Details abweichen. In bestimmten Fällen werden Beschreibungen bekannter Vorrichtungen, Schaltungen und Verfahren weggelassen, um die Beschreibung nicht durch unnötige Details zu verdunkeln. Für die Zwecke des vorliegenden Dokuments bedeuten die Ausdrücke „A oder B“ und „A/B“ (A), (B) oder (A und B).
  • Das erhebliche Marktinteresse an Energieeinsparungen während des SL-Betriebs hat die Notwendigkeit entstehen lassen, effiziente Mechanismen für die DRX-Funktionalität über NR-Sidelink zu definieren. Zu diesem Zweck werden in dieser Offenbarung Mechanismen erörtert, die einen nahtlosen Abgleich zwischen Uu- und SL-DRX-Zyklen und Aufwachzeiten (sowohl für den Intra- als auch den Inter-UE-Fall) sicherstellen, um einen energieeffizienten Betrieb zu gewährleisten.
  • Zum Beispiel kann die vorliegende Offenbarung gerichtet sein auf:
    • - Entwicklung von Mechanismen zur Angleichung der DRX-Zyklen für den Uu- und Sidelink-Betrieb, um maximale Energieeinsparungen durch Reduzierung des häufigen Aufwachens und Umschaltens von Hochfrequenz-Komponenten (RF) zu gewährleisten.
    • - Entwicklung von Mechanismen zur Angleichung der DRX-Aufwachzeiten zwischen Uu und Sidelink durch Definition neuer Hilfssignale zwischen UE und dem Netzwerk, um sicherzustellen, dass die Aufwachzeiten des UE für den PDCCH- und PSCCH-Empfang angeglichen werden.
    • - Entwicklung von Mechanismen zur Angleichung der SL-DRX-Aufwachzeiten zwischen gleichrangigen UEs in dem Sidelink für Unicast, Groupcast und Broadcast durch Austausch von DRX-Informationen unter Verwendung des Verfahrens zur Rekonfiguration des Sidelinks.
  • Ein Großteil der NR-Fahrzeug-zu-Allem (NR-Vehicle-to-Everything - V2X)-Anwendungsfälle, die in der Version 16 (Rel-16) des Dritte Generation Partnerschaftsprojekt (Third Generation Partnership Project - 3GPP) beschrieben sind, wie z.B. Platooning und fortgeschrittenes Fahren, sowie die bisher im 3GPP entwickelten Lösungen machen keine Annahmen über die Energiesparfähigkeiten der am SL-Betrieb beteiligten UEs. Die meisten der Systeme und Mechanismen, die zur Erfüllung der in der technischen Spezifikation (TS) 22.186, v. 16.2.0, 2019-06-14, festgelegten Hauptanforderungen definiert wurden, setzen voraus, dass die UEs immer Übertragungen über Sidelinks hören, wenn sie an einer bestimmten Gruppe von Diensten interessiert sind. In den meisten Fällen ist dies eine vernünftige Annahme, da es sich bei diesen Geräten in der Regel um Fahrzeuge wie Autos oder Lastwagen auf der Straße oder Road Side Units (RSUs) handelt, die physisch mit dem Netzwerk verbunden sind. In den meisten Fällen befindet sich das Mobilfunkmodem im Fahrzeug und nutzt die Batterie zur Stromversorgung. Daher ist Stromsparen (und bis zu einem gewissen Grad SL-Fähigkeit) in der Regel kein dringendes Problem. Dies steht im Gegensatz zum „normalen“ Mobilfunkbetrieb, bei dem der Stromverbrauch ein wesentlicher Aspekt ist, der berücksichtigt werden muss. Beim Uu-Betrieb überwacht das UE den Downlink-Kanal (DL) nicht kontinuierlich, sondern führt einen diskontinuierlichen Empfang durch, um das Funkgerät regelmäßig abzuschalten, vor allem um Batteriestrom zu sparen. Der DRX-Mechanismus wird schon seit geraumer Zeit in Mobilfunkstandards verwendet und hat sich im Laufe der Jahre erheblich weiterentwickelt.
  • Über die erste Gruppe von Anwendungsfällen hinaus, die die Grundlage für die gesamte 3GPP-Standardentwicklung in Rel-16 bildeten, müssen zusätzliche Überlegungen angestellt werden, sowohl in Bezug auf die Art der Anwendungen, die über NR-Sidelink betrieben werden müssen, als auch in Bezug auf die Art der Geräte, die für die Ausführung dieser Dienste vorgesehen sind. In Bezug auf erstere gibt es Bedenken, dass die Anforderungen und Betriebsszenarien für öffentliche Sicherheit und V2X-Dienste in den Rel-16- und Rel-17-Zielen zur Unterstützung fortgeschrittener V2X-Dienste und auf Nähe basierender Dienste im System der fünften Generation (5GS) nicht vollständig unterstützt werden. Darüber hinaus gibt es weitere kommerzielle Anwendungsfälle, die für Rel-17-Arbeiten in Betracht gezogen werden sollten:
  • - Netzwerkgesteuerter interaktiver Dienst (NCIS), der sich auf den Datenaustausch für interaktive Sitzungen (z.B. auf Virtual Reality (VR) basierende interaktive Dienste) zwischen Geräten konzentriert (sowohl in Proximity- als auch in Non-Proximity-Fällen);
  • - Gap Analysis for Railways (3GPP MONASTERYEND), mit strengen Anforderungen an Datenrate, Latenz und Zuverlässigkeit für Bahnkommunikationssysteme der nächsten Generation;
  • - Enhanced Relays for Energy eFficiency and Extensive Coverage (REFEC), wobei viele verschiedene Szenarien und vertikale Bereiche wie inHome, SmartFarming, SmartFactories, Public Safety in Betracht gezogen werden. Viele dieser Szenarien sind neu, während andere bereits von früheren Generationen von Mobilfunknetzwerken abgedeckt wurden. Im Vergleich zu früheren Generationen (3G, 4G) ist jedoch eine umfangreichere Abdeckung mit guter Energieeffizienz erforderlich.
  • - Audio-Visual Service Production (AVPROD), die sich auf Live-Audio- und Videopräsentationen und Streaming-Anwendungsfälle konzentriert.
  • Betrachtet man die oben genannten Anwendungsfälle, sollte es offensichtlich sein, dass die in Frage kommenden Geräte weit von den Fahrzeug-UEs (V-UEs) entfernt sind, die im Rel-16 SL-Design vorgesehen sind. Das bringt uns zum zweiten Punkt, z.B. den Gerätetypen. Wie aus den oben genannten Anwendungsfällen hervorgeht, sind die Geräte nicht nur auf Kraftfahrzeuge beschränkt, bei denen die Batterieleistung keine Rolle spielt. Stattdessen kann es sich um fest installierte Drahtlos-Geräte in Sportstadien, schnell fahrende Züge oder Handgeräte handeln, die einem Mobiltelefon sehr ähnlich sind. Kurz gesagt, die Annahmen bezüglich des Formfaktors und der Energieverbrauchsprofile in Rel-16 (und früher) NR-V2X-Arbeiten gelten nicht mehr. Um die Dienstanforderungen der oben genannten Anwendungsfälle zu erfüllen und auch die Vorteile der Energieeinsparungen für den Sidelink-Betrieb zu nutzen, wird in der Offenbarung die Einführung des DRX-Betriebs für Sidelinks vorgeschlagen, der sich eng an das Uu-Design anlehnt. Die vorliegende Offenbarung kann in Verbindung mit einer Vielzahl von SL-spezifischen Aspekten (z.B. Besetzungsart, Abdeckungsstatus, SL-Ressourcenpool-Konfigurationen usw.) funktionieren, die das Verhalten des UE vom typischen Uu-Fall unterscheiden. In dieser Offenbarung unterstützt ein typisches UE gleichzeitig Senden/Empfangen über Uu- und Sidelink-Schnittstellen. In der Offenbarung wird untersucht, wie die Interaktion zwischen Uu- und SL-DRX-Betrieb in einem solchen Szenario aussehen könnte, und es werden Mechanismen in Betracht gezogen, die eine gewisse Angleichung zwischen den Uu- und SL-DRX-Zyklen gewährleisten, um die Energieeinsparungsgewinne zu maximieren.
  • Für Sidelink kann der verallgemeinerte Betrieb von Uu übernommen werden, mit einigen wesentlichen Unterschieden in Bezug darauf, wie der Inaktivitäts-Timer in Bezug auf Sidelink-Kontrollinformationen der ersten und zweiten Stufe (SCI) gehandhabt wird und wie die relevante DRX-Konfiguration an das UE weitergegeben wird.
  • 1 zeigt einen typischen DRX-Betriebszyklus für SL 102. Der DRX-Zyklus 102 kann eine Zeitspanne 104 umfassen, in der das UE aktiv auf einem Nebenkanal hört. Der DRX-Zyklus 102 kann auch eine Aus-Dauer 106 enthalten, in der sich das UE in einem Schlafmodus befindet. Die Aus-Zeit 106 schafft eine Gelegenheit für DRX.
  • In früheren Diskussionen wurde der SL-DRX-Betrieb jedoch meist im luftleeren Raum diskutiert, z.B. unabhängig von laufenden Verfahren über die Uu-Verbindung. In der Praxis jedoch wäre ein typisches UE in der Abdeckung über seine Uu-Verbindung aktiv und könnte, abhängig vom Abdeckungsstatus, in Übertragung/Empfang mit dem Nächste Generation Node B (Next Generation Node B - gNB) involviert sein. Da das UE in der Regel den Uu-Stapel unabhängig von seinem SL-Status implementiert, ist es naheliegend, dass es am Uu-DRX-Betrieb beteiligt sein könnte, während es über den Sidelink aktiv ist. Die natürliche Frage, die sich in einem solchen Szenario stellt, ist, ob eine Interaktion zwischen den DRX-Operationen über die Uu- und die Sidelink-Schnittstelle in Betracht gezogen werden kann und ob dies im Hinblick auf Effizienz und Energieeinsparung von Vorteil sein kann. Insbesondere stellt sich die grundlegende Frage, ob es von Vorteil ist, wenn die Uu- und SL-DRX-Zyklen (bzw. die Aufwach- und Ruhezeiten) auf irgendeine Weise korreliert werden. Aus Sicht der Geräteentwicklung ist diese Frage wichtig, da die Kosten für die Implementierung mehrerer HF-Ketten zu hoch sind. Im Allgemeinen besteht eine typische HF-Kette aus einer Reihe von elektronischen Komponenten, die zur Abstimmung auf eine bestimmte Frequenz und zur Durchführung der erforderlichen Verarbeitung verwendet werden. Aufgrund der Komplexität der einzelnen Komponenten ist die Anzahl solcher Ketten in einem Gerät in der Regel ein kritischer Faktor bei der Bestimmung der Gerätekomplexität. In Bezug auf das oben beschriebene Szenario kann es zwei verschiedene Szenarien geben: Ein UE kann eine gemeinsame HF-Kette für Uu und SL haben (z.B. ein kostengünstiges/komplexes UE) oder es kann eine eigene HF-Kette für Sidelink haben (z.B. getrennt von Uu). Im ersten Fall ist es sinnvoll, die Uu- und SL-DRX-Zyklen gemeinsam zu betrachten, um sicherzustellen, dass die Aufwach- /Einschaltzeiten für beide aufeinander abgestimmt sind und der Geräteprozessor die HF-Kette abschalten kann, wenn die Ruhezeiten zusammenfallen. Im letzteren Fall kann der Geräteprozessor die HF-Ketten für Uu und SL unabhängig voneinander ein- und ausschalten, abhängig von den einzelnen DRX-Zyklen. Es ist jedoch anzumerken, dass selbst im Falle getrennter HF-Ketten das unabhängige Aus- und Einschalten der Ketten (für Uu und SL) einen höheren Stromverbrauch verursacht als im Falle einer Synchronisierung (aufgrund des erhöhten Stromverbrauchs durch häufiges Umschalten der HF-Komponenten). Daher gibt es genügend Gründe, eine gewisse Korrelation zwischen den Uu- und SL-DRX-Zyklen zu berücksichtigen, unabhängig davon, ob ein bestimmtes Gerät über gemeinsame oder getrennte HF-Ketten für Uu und Sidelink verfügt. Daher zielt diese Offenbarung darauf ab, Mechanismen zu entwickeln, die einen solchen Abgleich ermöglichen, wie in den folgenden Abschnitten erläutert wird.
  • Intra-UE-Abgleich von Uu- und SL-DRX-Aufwachzeiten: In Anbetracht der Hardwarebeschränkungen in einem typischen UE ist es vernünftig anzunehmen, dass erhebliche Energieeinsparungen erreicht werden können, indem sichergestellt wird, dass das UE das Funkgerät ausschalten kann, um Energie zu sparen, indem der Uu- und SL-Betrieb gleichzeitig berücksichtigt wird. Mit anderen Worten, es wäre aus Sicht der Energieeinsparung vorteilhaft, sowohl Uu- als auch SL-bezogene Übertragungen innerhalb derselben Zyklusdauer überwachen zu können und zu vermeiden, dass das Funkgerät wiederholt aufwacht. Diesbezüglich können zwei verschiedene Ansätze in Betracht gezogen werden.
  • Erstens überwacht das UE während der Aufwachzeit den PDCCH auf eingehende Downlink-Kontrollinformationen (DCI), die sich sowohl auf den Uu-Betrieb als auch auf die Planung über den Sidelink beziehen.
  • Zweitens überwacht das UE während der Aufwachzeit sowohl den PDCCH für Uu- und SL-Betrieb als auch den PSCCH für SL-Empfang. In diesem Fall kann das UE vernünftigerweise sicherstellen, dass alle Übertragungen für die Planung über den Kontrollkanal (Uu und SL) in seine aktive Zeit fallen, und folglich ist auch die Ruhezeit (z.B. die Zeit, in der es den Steuerkanal (CCH) nicht überwachen muss) für beide Kanäle aufeinander abgestimmt.
  • Der erste Ansatz ist nur für den Ressourcenzuweisungsmodus 1 anwendbar, bei dem der gNB für die Einplanung des UE sowohl über Uu (in Bezug auf eingehende DL-Übertragungen und/oder UL-Grant) als auch über SL (für die Übertragung über PC5) verantwortlich ist. So kann sichergestellt werden, dass der gNB das UE auf der Grundlage der für das UE bereitgestellten Konfiguration nur dann einplant, wenn es sich in der aktiven Zeit befinden soll. Es ist jedoch zu beachten, dass in diesem Fall keine direkte Auswirkung auf das Verhalten des UE (in Bezug auf Schlafen/Aufwachen) über Sidelink besteht, da das UE unabhängig vom Uu-Betrieb DRX über die Sidelink-Schnittstelle durchführen kann, um eingehende Planungsübertragungen von anderen UEs in der Nähe zu überwachen. Während es also über PDCCH kein Scheduling vom gNB erwartet, kann das Gleiche für den PSCCH-Empfang über den Sidelink nicht gesagt werden. Dies bedeutet, dass die Energieeinsparungen durch diesen Mechanismus (zumindest im Vergleich zu 3) begrenzt sind. Es ist jedoch erwähnenswert, dass dies keine Maßnahmen seitens des UE erfordert und eine intelligente Netzwerkimplementierung dieses Ziel erreichen kann.
  • 2 zeigt einen beispielhaften Schlaf/Wach-Zyklus 200 des UE, der auf dem ersten Ansatz basiert. Der Zyklus 200 umfasst den Uu DRX-Zyklus 202, der eine Wachdauer 204 und eine Schlafdauer 206 umfasst. Während der Wachdauer 204 kann ein UE den PDCCH für die SL-Planung sowie den PSCCH für den SL-Empfang überwachen.
  • Im zweiten Ansatz, möglicherweise in Kombination mit dem in 2 beschriebenen Mechanismus, können die Aufwachzeiten für das UE zur Überwachung von PDCCH über Uu und PSCCH über SL weiter angeglichen werden. Es hat sich wiederholt gezeigt, dass ein großer Teil der Leistung des UE im Modem, das aus der Hochfrequenzkette (HF) und der Basisbandeinheit (BB) besteht, durch die PDCCH/PSCCH-Überwachung ohne geplante Daten verbraucht wird. Um den größten Nutzen zu erzielen, ist es daher logisch, die beiden Bereiche gemeinsam zu behandeln. Im Wesentlichen muss sichergestellt werden, dass das UE aufwacht, um alle eingehenden Signale über PDCCH und PSCCH gemeinsam zu überwachen, ohne dazwischen in den Ruhezustand gehen zu müssen. Dies bedeutet, dass das UE beim Schlafengehen nicht erwartet, über PDCCH oder PSCCH eingeplant zu werden. Man beachte, dass dieser Fall für ein UE anwendbar ist, das entweder im Modus 1 oder im Modus 2 betrieben wird, da es nicht davon ausgeht, dass die Sidelink-Übertragung notwendigerweise vom gNB geplant wird.
  • Ein Problem hierbei ist, dass, da die Steuersignalisierung für die beiden Kanäle (PDCCH und PSCCH) von verschiedenen Instanzen (z.B. gNB vs. andere UE(s), die über SL arbeiten) stammen, es keine offensichtliche Koordination zwischen ihnen gibt.
  • 3 zeigt einen Uu-DRX-Zyklus 302 für einen PDCCH und einen SL-DRX-Zyklus 304 für einen PSCCH für dasselbe UE. Das UE kann eine PSCCH-Übertragung über Sidelink auch dann empfangen, wenn sich das UE nicht in der DRX-ON-Dauer für Uu befindet (und der umgekehrte Fall ist ebenfalls möglich).
  • Um dies zu erreichen, wird angenommen, dass die DRX-bezogene Konfiguration sowohl für Uu als auch für SL dem UE durch das Netz zur Verfügung gestellt werden kann. Insbesondere kann der gNB dem UE DRXConfig und sidelinkDRXConfig (über dedizierte oder Broadcast-Signalisierung) zur Verfügung stellen, die die Parameter enthalten, die das UE benötigt, um die Aufwach- und Schlafzeiten über Uu bzw. SL zu ermitteln. Da Unicast-, Groupcast- und Broadcast-Betrieb von der UE über Sidelink unterstützt werden, wird jeder der Cast-Typen einzeln behandelt:
  • Im Falle von Unicast, wenn eine PC5-Radio-Resource-Control (RRC)-Verbindung mit einem gleichrangigen UE aufgebaut wird, kann die Konfiguration der Zugangsschicht (AS) zwischen den UEs ausgetauscht werden. Die bevorzugte DRX-Konfiguration, die über die PC5-Verbindung verwendet werden soll, kann somit von den gleichrangigen UEs mit Hilfe des RRCReconfigurationSidelink-Verfahrens ausgetauscht werden. Diese bevorzugte DRX-Konfiguration kann dem gNB auch entweder über SidelinkUEInformationNR oder UEAssistanceInformation mitgeteilt werden, wenn die entsprechende Konfiguration für den Sidelink-Betrieb angefordert wird, entweder vor oder nach dem Aufbau der PC5-Verbindung (siehe weitere Einzelheiten unten). 4 zeigt einen Beispielablauf für die Signalisierung 400. Auf diese Weise kann die gNB 402 die Uu- und SL-DRX-Parameter so (neu) konfigurieren, dass die Zeiten, zu denen die UE 404 aufwachen muss, um sowohl den PDCCH als auch den PSCCH zu überwachen, aufeinander abgestimmt werden. In den Schritten 410 und 412 tauschen die UEs 404 und 406 die entsprechende SL DRX-Konfiguration aus. Anschließend kann das UE 404 den gNB 402 in Schritt 414 über diese Konfiguration informieren, und der gNB 402 kann das UE 404 in Schritt 416 zur Verwendung der angeforderten Konfiguration rekonfigurieren.
  • Ein weiteres Detail, das hier zu berücksichtigen ist, ist der Fall, dass das UE mehrere Unicast-Verbindungen über PC5 eingerichtet hat. In diesem Fall ist es möglich, dass alle diese Verbindungen potenziell unterschiedliche SL DRX-Zyklusparameter/Konfigurationen haben, die für die QoS-Eigenschaften der Anwendung über jede Verbindung repräsentativ sind. Da dies schnell zu einer komplexen Kombination potenzieller Ausrichtungen führen kann, können zwei verschiedene Optionen in Betracht gezogen werden:
  • Eine Möglichkeit besteht darin, die Informationen über bereits bestehende Unicast-Verbindungen und die DRX-Konfiguration(en) an den gNB weiterzuleiten. Dies kann entweder durch die Angabe spezifischer QoS-Flow-Informationen über diese Verbindungen oder spezifischer DRX-Parameter, wie oben beschrieben, erfolgen. In beiden Fällen kann der gNB diese dann bei der Bereitstellung der SL-DRX-Konfiguration für die neue Verbindung berücksichtigen.
  • Alternativ kann das UE selbst die „bevorzugte Konfiguration“ bestimmen und sie dem gNB unter Berücksichtigung der bestehenden Verbindungen mitteilen.
  • Im Falle von Groupcast gibt es zwar keine Interaktion auf AS-Ebene zwischen den Mitgliedern einer bestimmten Gruppe, wie es beim herkömmlichen V2X-Design der Fall ist, aber einige DRX-bezogene Informationen können dennoch von den Gruppenmitgliedern selbst an ihre jeweiligen gNBs übermittelt werden. Diese Informationen können von der Anwendung der oberen Schicht eingeholt werden und können dem Verkehrsmuster für einen bestimmten SL-Dienst entsprechen. Insbesondere kann die Anwendungsschicht das Verkehrsmuster und andere QoSbezogene Informationen an die AS-Schicht liefern, die dann an das Netzwerk gesendet werden können. Das Netzwerk kann dann die geeignete DRX-Konfiguration für jedes UE innerhalb der Gruppe bereitstellen, indem es die angeforderte Konfiguration berücksichtigt und versucht, den Abgleich zwischen der Uu- und SL-DRX-Aufwachzeit zu maximieren.
  • Da das UE aufgrund seines verbindungslosen Charakters das Muster für eingehenden Verkehr nicht kennt, kann es das Netzwerk einfach auf der Grundlage von Informationen der oberen Schicht oder der internen Implementierung informieren.
  • In allen oben genannten Fällen besteht das grundlegende Ziel darin, dass das UE dem Netzwerk seine bevorzugte DRX-Konfiguration sowohl für Uu als auch für SL mitteilt. Dies kann entweder durch die Einbeziehung der QoS-Informationen für seine interessierten Dienste oder durch die direkte Einbeziehung der bevorzugten DRX-Parameter auf der Grundlage seines erwarteten Verkehrsmusters erfolgen.
  • Die Einbeziehung der QoS-Informationen für den/die interessierten Dienst(e) beinhaltet die Periodizität des zugehörigen SL-Verkehrs, der voraussichtlich übertragen/empfangen wird, und kann durch die Verwendung von SidelinkUEInformationNR genutzt werden.
  • Die Einbeziehung der bevorzugten DRX-Parameter direkt auf der Grundlage des erwarteten Verkehrsmusters nutzt die SidelinkUEInformationNR und/oder UEAssistanceInformationNR. Die bevorzugte SL-DRX-Konfiguration kann die relevanten Parameter wie den Inaktivitäts-Timer, lange und kurze Zyklusdauern usw. enthalten, und ein Beispiel-Informationselement (IE) mit den potenziell anzugebenden Parametern ist nachstehend abgebildet:
    Figure DE102021118717A1_0001
  • In jedem Fall kann der gNB dann die DRX-Parameter für das UE so planen, dass die Aufwachzeiten und die Gelegenheit für den DRX-Schlaf für Uu und SL miteinander übereinstimmen. Wenn beispielsweise bei einem bestimmten SL-Dienst lange Inaktivitätsperioden zwischen den Übertragungen zu erwarten sind, kann das Netzwerk das UE entsprechend so einplanen, dass mehrere Uu-DRX-Zyklen innerhalb einer einzigen SL-DRX-Zyklusperiode stattfinden können. Darüber hinaus kann der Einschaltdauer-Timer für den Uu-DRX-Zyklus höher/anders sein als der für den SL-DRX konfigurierte (auch wenn der Startschlitzversatz angeglichen ist). Daher kann es je nach der genauen Konfiguration und den Szenarien mehrere Möglichkeiten geben.
  • 5 zeigt beispielhafte Ausrichtungen von Uu DRX-Zyklen und SL DRX-Zyklen. So ist beispielsweise der Uu-DRX-Zyklus 502 genau auf den SL-DRX-Zyklus 504 ausgerichtet, so dass ihre Aufwach- und Schlafzeiten aufeinander abgestimmt sind. Alternativ dazu umfasst der SL-DRX-Zyklus 508 eine doppelt so lange Dauer wie die Dauer des Uu-DRX-Zyklus 506. Der SL-DRX-Zyklus 508 und der Uu-DRX-Zyklus 506 sind so aufeinander abgestimmt, dass jede zweite Aufwachzeit des Uu-DRX-Zyklus 506 mit einer Aufwachzeit des SL-DRX-Zyklus 508 übereinstimmt.
  • In Anbetracht der Notwendigkeit einer Angleichung der Aufwachzeiten für Uu- und SL-DRX-Zyklen innerhalb eines UE und der eindeutigen Vorteile in Bezug auf Energieeinsparungen ist es sinnvoll, auch den Fall zwischen den UEs zu berücksichtigen. Angesichts des Ad-hoc-Charakters der Sidelink-Kommunikation zwischen UEs mit begrenzter Koordinierung durch eine zentrale Instanz für den Out-of-Coverage-Fall ist auch zu überlegen, wie ein gewisses Maß an Angleichung zwischen ihren DRX-Zyklen in Betracht gezogen werden kann. Betrachten wir die drei von Rel-16 V2X UEs unterstützten Besetzungsarten getrennt und schauen sie uns im Detail an.
  • Im Falle von Unicast wird davon ausgegangen, dass eine Unicast-Verbindung über PC5 zwischen den Peer-UEs hergestellt werden soll. Daher kann die bevorzugte SL DRX-Konfiguration zwischen den UEs unter Verwendung der RRCReconfigurationSidelink-Prozedur ausgetauscht werden. Es gibt jedoch einige wichtige Unterschiede zu beachten: Erstens besteht das Ziel hier darin, die Sidelink-Weckzeiten für die beiden UEs über Sidelink anzugleichen, ohne notwendigerweise den Uu-Betrieb zu berücksichtigen. Außerdem kann dies im Gegensatz zum vorherigen Szenario für jedes Abdeckungsszenario gelten, z.B. auch wenn die UEs außerhalb der Abdeckung sind, können sie diese Konfiguration austauschen und die SL-DRX-bezogenen Parameter neu konfigurieren, um eine solche Abstimmung zu erreichen.
  • 6 zeigt eine beispielhafte Signalisierung 600. Die Signalisierung 600 zeigt, wie UE 602 das UE 604 rekonfiguriert, indem es SL-DRX-Config in die RRCReconfigurationSidelink-Nachricht in Schritt 606 aufnimmt. Die beispielhafte Signalisierung 600 für SL-DRX-Config ist ebenfalls unten aufgeführt:
    Figure DE102021118717A1_0002
  • Schließlich kann, wie oben besprochen, im Falle eines UE, das mehrere Unicast-Verbindungen über Sidelink aufgebaut hat, während dieselben beiden Optionen, die oben in Bezug auf 2 und 3 besprochen wurden, in Betracht gezogen werden, die Weitergabe von Informationen über bereits bestehende Unicast-Verbindungen und ihre DRX-Konfiguration(en) an den gNB wie in Option 2A oben ist möglicherweise nicht immer möglich, da die UEs möglicherweise außerhalb der Abdeckung arbeiten und sich auf die vorkonfigurierte DRX-Konfiguration verlassen müssen. Da in diesem Fall der Abgleich aufgrund des Fehlens einer zentralen Instanz schwieriger zu bewerkstelligen sein könnte, kann eine explizite Angabe in die Vorkonfiguration aufgenommen werden, um das UE darüber zu informieren, ob es die bevorzugte SL-DRX-Konfiguration mit gleichrangigen UEs austauschen sollte, wenn es sich außerhalb des Versorgungsbereichs befindet.
  • Im Falle von Groupcast kann der Gruppenleiter vom gNB eine spezifische SL-DRX-Konfiguration erhalten, die auf dem gegebenen SL-Dienst und seinen QoS-Attributen basiert. Diese Konfiguration kann dann über den Konfigurationsaustausch auf der AS-Schicht (über SL RRC) an die UEs der Gruppe weitergegeben werden. Alternativ kann diese Konfiguration jedem UE vom Netzwerk einzeln mitgeteilt werden, wobei davon ausgegangen wird, dass keine Interaktion auf der AS-Schicht zwischen dem Gruppenleiter und anderen UEs stattfindet.
  • Bei Broadcast kann das Netzwerk den UEs eine spezifische SL DRX-Konfiguration über dedizierte oder Broadcast-Signalisierung zur Verfügung stellen, um die Angleichung ihrer jeweiligen Aufwachzeiten zu maximieren. Diese Konfiguration kann für alle SL-Dienste/QoS-Ströme gelten oder für einen bestimmten Dienst unterschiedlich sein.
  • Um dem erheblichen Marktinteresse an Energieeinsparungen während des Nebenstellenbetriebs gerecht zu werden, müssen außerdem Methoden zur Definition effizienter Mechanismen für die Bereitstellung diskontinuierlicher Empfangsfunktionen (DRX) über NR-Nebenstellen in Betracht gezogen werden. Zu diesem Zweck werden in dieser Offenlegung einige spezifische Details zum Betrieb eines solchen SL-DRX-Mechanismus bereitgestellt. Außerdem werden die Wechselwirkungen eines solchen Entwurfs mit dem Abdeckungsstatus des UE, die Notwendigkeit eines QoS-spezifischen DRX-Zyklus und die Auswirkungen von Sidelink-Mess- und Berichterstattungsverfahren berücksichtigt.
  • Die Beschreibung in dieser Offenlegung erörtert:
    • - Ein Vorschlag für die Verwendung eines einzelnen diskontinuierlichen Empfangsmechanismus (DRX) über NR-Sidelink in verschiedenen Versorgungsszenarien und wie dem UE eine geeignete Konfiguration vermittelt werden kann
    • - Die Auswirkungen der Verwendung langer und/oder kurzer DRX-Zyklen, um V2X und anderen SL-spezifischen Anwendungen und deren unterschiedlichen QoS-Anforderungen gerecht zu werden
    • - Die Notwendigkeit der Durchführung von Sidelink-Messungen und -Berichten sowie die Entwicklung von Lösungen, die sicherstellen, dass solche Messungen die Nützlichkeit von SL DRX und seine Rolle bei der Energieeinsparung für das UE nicht beeinträchtigen.
  • Da 5G-Netzwerke weltweit eingeführt werden und die erste Reihe von Standards für NR-Sidelink kurz vor der Fertigstellung steht, besteht auf dem Markt ein zunehmendes Interesse an der Weiterentwicklung und Verbesserung der bisherigen Arbeit. Im Bereich des selbstfahrenden und autonomen Automobils könnten die hier beschriebenen Lösungen wertvoll sein, um einen effizienten Sidelink-Betrieb von ferngesteuerten und/oder autonom fahrenden Fahrzeugen zu ermöglichen und energiesparende Funktionen für einen umweltfreundlicheren und effizienteren Betrieb auf dem Weg zu 6G und darüber hinaus zu bieten.
  • So wie sich die Mobilfunkstandards im Laufe der Jahre entwickelt haben, so haben sich auch die spezifischen Anwendungsfälle und ihre jeweiligen Anforderungen weiterentwickelt. Im Mobilfunkbereich haben sich mit der Entwicklung der NR-Standards die V2X-Anwendungsfälle im Vergleich zu ihren Pendants in LTE deutlich weiterentwickelt. In [1] sind einige der fortgeschrittenen Anwendungsfälle aufgeführt, die in der aktuellen Generation der 3GPP-Standards angestrebt werden. Es ist jedoch anzumerken, dass zwar viele Anforderungen für jeden der Anwendungsfälle in akribischer Detailarbeit aufgelistet wurden, eine wichtige Anforderung jedoch noch nicht berücksichtigt wurde: die Auswirkungen auf den Energieverbrauch. Dies ist insofern sinnvoll, als die meisten Schemata und Mechanismen, die zur Erfüllung der in [1] aufgeführten Hauptanforderungen definiert wurden, einfach voraussetzen, dass das Endgerät immer Übertragungen über Sidelink hört, wenn es an einer bestimmten Gruppe von Diensten interessiert ist. In den meisten Fällen ist dies eine vernünftige Annahme, da es sich bei diesen Geräten in der Regel um Fahrzeuge wie Autos oder Lastwagen auf der Straße oder Road Side Units (RSUs) handelt, die physisch mit dem Netz verbunden sind. In den meisten Fällen befindet sich das Mobilfunkmodem im Fahrzeug bzw. in der Struktur und nutzt die Batterie zur Stromversorgung. Daher ist die Energieeinsparung (und in gewissem Maße auch die Gerätekomplexität) in der Regel kein dringendes Problem. Dies ist anders als beim „normalen“ Mobilfunkbetrieb, bei dem der Stromverbrauch eine wesentliche Einschränkung darstellt, die berücksichtigt werden muss. Beim Uu-Betrieb überwacht das UE den DL-Kanal nicht kontinuierlich, sondern führt einen diskontinuierlichen Empfang durch, um das Funkgerät in regelmäßigen Abständen abzuschalten, in erster Linie um Batteriestrom zu sparen. Der DRX-Mechanismus wird schon seit geraumer Zeit in zellularen Standards eingesetzt und hat sich im Laufe der Jahre erheblich weiterentwickelt [4]. In [2] werden die Grundlagen des DRX-Mechanismus für den Nebenstellenbetrieb und einige der besonderen Aspekte des Nebenstellenbetriebs erläutert, die berücksichtigt werden müssen. In dieser Offenlegung werden einige der komplizierteren Details und Aspekte betrachtet, einschließlich, aber nicht beschränkt auf die Diskussion der Anwendbarkeit langer und kurzer DRX-Zyklen, weiterer Details zur Konfiguration relevanter Parameter und der Auswirkung von Sidelink-Messungen und - berichten auf den DRX-Betrieb. Eine allgemeine Beschreibung des SL-DRX-Betriebs findet sich in Referenz [2].
  • Zwei verschiedene DRX-Modi wurden in der Spezifikation [4] für den UE-Mobilitätsstatus im Uu-Betrieb definiert.
  • Erstens kann das UE im RRC_IDLE- und RRC INACTIVE-Zustand Discontinuous Reception (DRX) verwenden, um den Stromverbrauch zu reduzieren. In diesem Fall überwacht das UE einen Paging-Anlass (PO) pro DRX-Zyklus, wobei ein PO ein Satz von PDCCH-Überwachungsanlässen ist und aus mehreren Zeitschlitzen (z.B. Teilrahmen oder OFDM-Symbol) bestehen kann, in denen Paging-DCI gesendet werden können [5].
  • Zweitens gilt für den RRC_CONNECTED-Modus der „konventionelle“ Connected Mode-DRX-Modus (C-DRX), der dadurch gekennzeichnet ist, dass das UE PDCCH nur für die Einschaltdauer überwacht, und der durch die in der nachstehenden Beschreibung angegebenen Parameter bestimmt wird.
  • In jedem Fall läuft das UE-Verhalten letztlich darauf hinaus, PDCCH diskontinuierlich zu überwachen (wie der Name schon sagt), und der Hauptunterschied ist der Unterschied im RRC-Verbindungsstatus des UE. Bei der Betrachtung des Sidelink-Betriebs bestimmt der Uu-Verbindungsstatus des UE nicht direkt das UE-Verhalten im Vergleich zum Uu-Betrieb. So ist das UE beispielsweise immer noch in der Lage, den Sidelink-Verkehr zu überwachen, die relevante Konfiguration zu erfassen und eine Unicast-PC5-Verbindung aufzubauen, unabhängig davon, ob es sich im RRC_CONNECTED- oder RRC_IDLE-Modus befindet. Während die Erfassung der relevanten Konfiguration für SL DRX je nach UE-Verbindungsstatus unterschiedlich ist, muss die Sidelink-DRX-Funktionalität selbst nicht zwischen den verschiedenen Zuständen unterschieden werden. Insbesondere kann das UE die relevante DRX-Konfiguration unter Verwendung von dedizierter Signalisierung, SIB und/oder (Vor-)Konfiguration erwerben, je nachdem, ob es sich im RRC_CONNECTED-, RRC IDLE/RRCINACTIVE- oder Out-of-Coverage-Zustand befindet, und diese Konfiguration (einschließlich verschiedener DRX-Parameter) kann grundsätzlich unterschiedlich sein. Auf diese Weise können dem UE selbst bei einem einzigen DRX-Modus für verschiedene Versorgungszustände unterschiedliche Konfigurationen durch das Netzwerk zugewiesen werden. Daher kann ein einziger neuer DRX-Modus (und das entsprechende UE-Verhalten) für Sidelink definiert werden, unabhängig von seinem aktuellen Versorgungsstatus (wie in [2] näher erläutert).
  • Für den Sidelink-Betrieb kann der verallgemeinerte Betrieb von Uu angepasst werden, wobei der typische SL-DRX-Betrieb durch eine Reihe von Parametern charakterisiert werden kann, die von RRC konfiguriert werden, einschließlich der Einschaltdauer, Inaktivitäts- und Neuübertragungszeitgeber usw. Darüber hinaus hat LTE das Konzept der langen und kurzen DRX-Zyklen eingeführt, die individuell über die RRC-Konfiguration festgelegt werden können. Die Idee, beide Optionen zu haben, besteht möglicherweise darin, dem Netzwerk mehr Flexibilität bei der Konfiguration des UE mit unterschiedlichen QoS-Anforderungen usw. zu ermöglichen. Die vollständige Konfiguration in der RRC-Spezifikation für den Uu-DRX-Betrieb ist nachstehend als Referenz wiedergegeben:
    Figure DE102021118717A1_0003
    Figure DE102021118717A1_0004
    Figure DE102021118717A1_0005
  • Für den typischen Sidelink-Verkehr ist zu beachten, dass es eine größere Vielfalt an Diensten und zugehörigem Verkehr gibt (zumindest im Vergleich zu LTE), so dass sich natürlich die Frage stellt, ob der optionale kurze DRX-Zyklus wie bei Uu für den Sidelink immer noch nützlich ist oder nicht. Insbesondere können drei verschiedene Optionen in Frage kommen.
  • Erstens: Wiederverwendung des Uu-Verhaltens und der Uu-Konfiguration für Sidelink, z.B. kann das Netzwerk die Konfiguration für beide Zyklen für Sidelink bereitstellen, und wenn der kurze Zyklus konfiguriert ist, wird er vom UE bevorzugt verwendet.
  • Zweitens können sowohl kurze als auch lange DRX-Zyklen für die Nebenverbindung eingeführt werden, und das Netzwerk stellt die Konfiguration für beide zur Verfügung, bietet dem UE aber auch eine Zuordnung zu einer Reihe von Diensten (Typen) oder einem QoS-Profil. Die Bereitstellung des kurzen DRX-Zyklus hängt von den QoS-Merkmalen der Sidelink-Anwendungsdaten ab. Das UE kann dann den entsprechenden DRX-Zyklus für die bestimmte Verkehrsart auswählen, die es gerade empfangen möchte. Es ist zu beachten, dass dies bedeutet, dass das kurze DRX-Feld nicht mehr optional ist (was eine Abweichung vom Uu-Design darstellt, wo es optional konfiguriert werden kann). Dies ist in der ASN.1-Signalisierungsstruktur unten dargestellt, wo der wichtige Unterschied zum Uu-Design darin besteht, dass die Konfiguration des kurzen DRX-Zyklus nicht mehr optional ist und vom UE erwartet wird, dass es je nach DRB-Konfiguration/Zuordnung zur SL-Anwendung/QoS-Anforderung eines von beiden verwendet.
  • Drittens kann argumentiert werden, dass, da der gesamte Betrieb über Sidelink stattfindet, stattdessen ein einziger und aggressiverer DRX-Zyklus (z.B. weniger als normale Gelegenheiten zum Schlafen) in Betracht gezogen werden kann, der vom Netzwerk so konfiguriert werden kann, dass er allen Arten von Sidelink-Verkehr gerecht wird.
  • Es ist wichtig anzumerken, dass das Netzwerk in allen Fällen die Konfiguration (entsprechend der spezifischen QoS/PQI) durch Broadcast/SIB-Signalisierung oder dynamische/zweckgebundene Signalisierung bereitstellen kann, je nachdem, ob das UE RRC INACTIVE/IDLE oder RRC_CONNECTED ist. Die Peer-UEs können dann die PC5-RRC-Eins-zu-Eins-Kommunikation nutzen, um den konfigurierten Parametersatz weiter zu übermitteln. Auf die Vorkonfiguration muss zurückgegriffen werden, wenn sich das UE außerhalb der Netzwerkabdeckung befindet.
    Figure DE102021118717A1_0006
  • 7 zeigt ein Beispiel für einen Teilrahmen 700, in dem sowohl kurze DRX-Zyklen 704 als auch lange DRX-Zyklen 706 für Sidelink konfiguriert sind, wie zuvor beschrieben. Das UE arbeitet zunächst im langen DRX-Zyklus und schaltet dann auf den kurzen Zyklus um.
  • Einer der Schlüsselaspekte des Sidelink-Betriebs ist die Sidelink-Messung und das Berichtsverfahren. Von einem typischen V-UE wird erwartet, dass es mehrere SL-Messungen und Meldungen an das Netzwerk sowie an gleichrangige UEs durchführt. Daher stellt sich die logische Frage, wie solche SL-Messungen und -Berichte mit dem SL-DRX-Verfahren interagieren.
  • Ein wichtiger Aspekt, der hier zu berücksichtigen ist, ist, dass im Gegensatz zum Uu-Messrahmen die SL-Messungen derzeit recht begrenzt sind und es daher keine Messlückenfunktion für das UE über SL gibt. Die Meldung von Messungen über Sidelinks kann in zwei große Kategorien unterteilt werden.
  • Erstens: Messberichte über Sidelink an gleichrangige UE(s), hauptsächlich für Unicast-Betrieb. Dies besteht derzeit aus SL Channel State Information (CSI) Reporting und periodischem SL RSRP Reporting.
  • Zweitens: Messberichte über Uu an den gNB für den Sidelink-Betrieb. Zu den gängigsten Arten gehören Berichte mit konstanter Bitrate (CBR), die von der gNB für bestimmte SL-Ressourcenpools konfiguriert werden.
  • Es wird zwar erwartet, dass das Ausmaß der Messungsberichterstattung über Sidelink mit der Ausweitung von NR Sidelink über V2X hinaus zunehmen wird, aber es ist zu erwarten, dass es im Vergleich zum Uu-Pendant noch begrenzt sein wird. Insbesondere scheint der Nutzen einer solchen Messlücke für Sidelink-Messungen begrenzt zu sein, wenn man UEs mit inhärenter Komplexität und Einschränkungen beim Stromverbrauch betrachtet, wie z. B. Fußgänger-UEs (P-UEs). Dies liegt daran, dass solche UEs vom Netzwerk nicht für die Durchführung von Sidelink-Messungen konfiguriert werden dürften, vor allem weil sie nur eine einzige RX-Kette und begrenzte Verarbeitungsmöglichkeiten haben.
  • Was die DRX-Zeitpläne betrifft, so können die gleichrangigen UEs im Falle von Unicast die DRX-Konfigurationen während des Verbindungsaufbaus so abstimmen, dass sich die periodische Berichterstattung über die empfangene Referenzsignalleistung (RSRP) mit der DRX-Einschaltdauer überschneidet. In zukünftigen Versionen, wenn aperiodische/ereignisgesteuerte Berichterstattung definiert ist, kann eine zusätzliche Einschränkung definiert werden, so dass das UE nur Messberichte auslöst, wenn es sich im DRX auf Dauer befindet.
  • 8 zeigt die SL-Messungsberichterstattung während der Einschaltdauer eines DRX-Zyklus 800. Die periodische Berichterstattung 802 kann an der gleichen Stelle während der Einschaltdauer des DRX-Zyklus 800 erfolgen. Die ereignisgesteuerte Berichterstattung 804 kann zu jedem Zeitpunkt während der Einschaltdauer des DRX-Zyklus 800 erfolgen.
  • Ein zusätzlicher erwägenswerter Aspekt ist, dass, wenn die aktuelle SL-DRX-Konfiguration des UE so beschaffen ist, dass sie nicht mit den Messanforderungen des Peer-UE übereinstimmt (z.B. PDB-Latenz für die CSI-Berichterstattung), das UE die Präferenz einer Anpassung der DRX-Zykluslänge und anderer Parameterwerte unter Verwendung der bereits definierten UE Assistance Information-Nachricht über UL angeben kann. Dies kann im Allgemeinen immer dann geschehen, wenn das UE eine neue Unicast-Verbindung hat und den Sidelink-DRX-Zyklus an den Uu-DRX-Zyklus angleichen muss.
  • 9-11 illustrieren verschiedene Systeme, Geräte und Komponenten, die Aspekte der Offenbarung implementieren können.
  • 9 illustriert ein Netzwerk 900 gemäß der Offenbarung. Das Netzwerk 900 kann in einer Weise betrieben werden, die den technischen Spezifikationen des 3GPP für Long Term Evolution (LTE) oder Systeme der fünften Generation (5G)/NR entspricht. Die Beispiele sind jedoch in dieser Hinsicht nicht beschränkt, und die Beschreibungen können für andere Netzwerke gelten, die von den hier beschriebenen Prinzipien profitieren, wie z.B. zukünftige 3GPP-Systeme oder ähnliches.
  • Das Netzwerk 900 kann ein UE 902 umfassen, das ein beliebiges mobiles oder nichtmobiles Computergerät umfassen kann, das für die Kommunikation mit einem Funkzugangsnetzwerk (RAN) 904 über eine Über-die-Luft-Verbindung ausgelegt ist. Das UE 902 kann über eine Uu-Schnittstelle kommunikativ mit dem RAN 904 gekoppelt sein. Bei dem UE 902 kann es sich um ein Smartphone, einen Tablet-Computer, ein tragbares Computergerät, einen Desktop-Computer, einen Laptop-Computer, ein bordeigenes Infotainment- oder Unterhaltungsgerät, ein Kombiinstrument, ein Head-up-Display, ein Onboard-Diagnosegerät, ein mobiles Dashtop-Gerät oder ein mobiles Datenendgerät, elektronisches Motormanagementsystem, elektronisches/Motorsteuergerät, elektronisches/Motorsteuermodul, eingebettetes System, Sensor, Mikrocontroller, Steuermodul, Motormanagementsystem, vernetztes Gerät, maschinenartiges Kommunikationsgerät, Machine-to-Machine (M2M)- oder Device-to-Device (D2D)-Gerät, Internet-of-Things (IoT)-Gerät, usw. handeln, ist aber nicht darauf beschränkt.
  • Das Netzwerk 900 kann eine Vielzahl von UEs umfassen, die über eine Sidelink-Schnittstelle direkt miteinander verbunden sind. Die UEs können M2M/D2D-Geräte sein, die über physikalische Sidelink-Kanäle kommunizieren, wie z.B. (PSBCH), Physikalischer Sidelink-Downlink-Kanal (Physical Sidelink Downlink Channel - PSDCH), Physikalischer Sidelink-Geteilter-Kanal (Physical Sidelink Shared Channel - PSSCH), PSCCH, Physikalischer Sidelink-Rückkopplung-Kanal (Physical Sidelink Feedback Channel - PSFCH), etc.
  • Das UE 902 kann zusätzlich mit einem Zugangspunkt (Access Point - AP) 906 über eine Über-die-Luft-Verbindung kommunizieren. Der AP 906 kann eine WLAN-Verbindung (Wireless Local Area Network) verwalten, die dazu dienen kann, einen Teil/den gesamten Netzwerkverkehr vom RAN 904 zu entlasten. Die Verbindung zwischen dem UE 902 und dem AP 906 kann mit jedem IEEE 802.11-Protokoll (Institute of Electrical and Electronics Engineers) übereinstimmen, wobei der AP 906 ein Wireless Fidelity (Wi-Fi®) Router sein könnte. Das UE 902, das RAN 904 und der AP 906 können Mobilfunk-WLAN-Aggregation verwenden (z.B. LTE-WLAN-Aggregation (LWA)/ LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP)). Bei der Aggregation von Mobilfunk und WLAN kann das UE 902 vom RAN 904 so konfiguriert werden, dass sie sowohl Mobilfunk- als auch WLAN-Ressourcen nutzt.
  • Das RAN 904 kann einen oder mehrere Zugangsknoten enthalten, zum Beispiel den Zugangsknoten (AN) 908. AN 908 kann Luftschnittstellenprotokolle für das UE 902 beenden, indem er Zugriffsschichtprotokolle einschließlich RRC, Paketdatenkonvergenzprotokoll (PDCP), Funkverbindungssteuerung (RLC), Nachrichtenauthentifizierungscode (MAC) und Schicht 1 (L1)-Protokolle bereitstellt. Auf diese Weise kann der AN 908 Daten-/Sprachkonnektivität zwischen der Kanalnummer (CN) 920 und dem UE 902 ermöglichen. Der AN 908 kann in einem separaten Gerät oder als eine oder mehrere Softwareeinheiten implementiert werden, die auf Servercomputern als Teil eines virtuellen Netzwerks laufen, das als Cloud Radio Access Network (CRAN) oder virtueller Basisbandeinheitenpool bezeichnet werden kann. Der AN 908 kann als Basisstation (BS), gNB, RAN-Knoten, e-UTRAN NodeB (eNB), Next Generation-evolved NodeB (ng-eNB), NodeB, Road Side Unit (RSU), Transmission Reception Point (TRxP), Transmission Reception Point (TRP), usw. bezeichnet werden. Bei dem AN 908 kann es sich um eine Makrozellen-Basisstation oder eine Basisstation mit geringer Leistung zur Bereitstellung von Femtozellen, Pikozellen oder ähnlichen Zellen handeln, die im Vergleich zu Makrozellen kleinere Versorgungsbereiche, eine geringere Nutzerkapazität oder eine höhere Bandbreite aufweisen.
  • Das RAN 904 kann eine Vielzahl von ANs umfassen, die über eine X2-Schnittstelle (wenn das RAN 904 ein LTE-RAN ist) oder eine Xn-Schnittstelle (wenn das RAN 904 ein 5G-RAN ist) miteinander gekoppelt sein können. Die X2/Xn-Schnittstellen, die in Schnittstellen für die Steuerungs-/Nutzerebene unterteilt sein können, ermöglichen den ANs die Kommunikation von Informationen in Bezug auf Handover, Daten-/Kontextübertragung, Mobilität, Lastmanagement, Interferenzkoordination usw.
  • Die ANs des RAN 904 können jeweils eine oder mehrere Zellen, Zellgruppen, Komponententräger usw. verwalten, um dem UE 902 eine Luftschnittstelle für den Netzwerkzugang zur Verfügung zu stellen. Das UE 902 kann gleichzeitig mit einer Vielzahl von Zellen verbunden sein, die von denselben oder verschiedenen ANs des RAN 904 bereitgestellt werden. Beispielsweise können das UE 902 und das RAN 904 die Trägeraggregation nutzen, um dem UE 902 die Verbindung mit einer Vielzahl von Komponententrägern zu ermöglichen, die jeweils einer P-Zelle oder Scell entsprechen. In Dual-Connectivity-Szenarien kann ein erster AN ein Master-Knoten sein, der eine Master Cell Group (MCG) bereitstellt, und ein zweiter AN kann ein sekundärer Knoten sein, der eine Secondary Cell Group (SCG) bereitstellt. Die ersten/zweiten ANs können eine beliebige Kombination aus eNB, gNB, ng-eNB usw. sein.
  • Das RAN 904 kann die Luftschnittstelle über ein lizenziertes Spektrum oder ein nicht lizenziertes Spektrum bereitstellen. Für den Betrieb im unlizenzierten Spektrum können die Knoten einen lizenzunterstützten Zugang (LAA), einen erweiterten LAA (eLAA) und/oder einen weiter verbesserten LAA (feLAA)-Mechanismus auf der Grundlage der Trägeraggregations-Technologie (CA) mit PC-Zellen/Zellen verwenden. Vor dem Zugriff auf das unlizenzierte Spektrum können die Knoten Medien-/Trägererfassungsvorgänge durchführen, die beispielsweise auf einem Hören-vor-Sprechen (Listen-before-talk - LBT)-Protokoll basieren.
  • In V2X-Szenarien kann das UE 902 oder AN 908 eine RSU sein oder als RSU fungieren, was sich auf jede Verkehrsinfrastruktureinheit beziehen kann, die für V2X-Kommunikation verwendet wird. Eine RSU kann in oder durch ein geeignetes AN oder ein stationäres (oder relativ stationäres) UE implementiert werden. Eine RSU, die in oder durch ein UE implementiert ist, kann als „UE-type RSU“ bezeichnet werden; eine eNB kann als „eNB-type RSU“ bezeichnet werden; eine gNB kann als „gNB-type RSU“ bezeichnet werden; und dergleichen. In einem Beispiel handelt es sich bei einer RSU um eine Recheneinheit, die mit einer straßenseitigen Schaltung gekoppelt ist, die vorbeifahrenden UEs Konnektivität bietet. Die RSU kann auch eine interne Schaltung zur Datenspeicherung enthalten, um die Geometrie von Kreuzungen, Verkehrsstatistiken, Medien sowie Anwendungen/Software zur Erfassung und Steuerung des laufenden Fahrzeug- und Fußgängerverkehrs zu speichern. Die RSU kann eine Kommunikation mit sehr geringer Latenz ermöglichen, die für Hochgeschwindigkeitsereignisse wie Unfallvermeidung, Verkehrswarnungen und Ähnliches erforderlich ist. Zusätzlich oder alternativ kann die RSU andere Mobilfunk-/WLAN-Kommunikationsdienste bereitstellen. Die Komponenten der RSU können in einem wetterfesten Gehäuse untergebracht sein, das für die Installation im Freien geeignet ist, und sie können einen Netzwerkschnittstellen-Controller enthalten, um eine drahtgebundene Verbindung (z.B. Ethernet) zu einem Verkehrssignalsteuergerät oder einem Backhaul-Netzwerk herzustellen.
  • Das RAN 904 kann ein LTE-RAN 910 mit eNBs sein, zum Beispiel eNB 912. Das LTE RAN 910 kann eine LTE-Luftschnittstelle mit den folgenden Merkmalen bereitstellen: Unterträgerabstand (SCS) von 15 kHz; CP-OFD-Steuerebene (CP)-Orthogonal Frequency Division Multiplexing (OFDM)-Wellenform für DL und SC-FDM Single Carrier Frequency Division Multiple Access (SC-FDMA)-Wellenform für UL; Turbocodes für Daten und Tail Biting Convolutional Codes (TBCC) für die Steuerung; usw. Die LTE-Luftschnittstelle kann sich auf das CSI-Referenzsignal (RS) für die CSI-Erfassung und das Strahlmanagement stützen, auf das Demodulationsreferenzsignal (DMRS) für die PDSCH/PDCCH-Demodulation (Physical Downlink Shared Channel (PDSCH)/Physical Downlink Control Channel (PDCCH)) und auf das Zellenreferenzsignal (CRS) für die Zellensuche und die anfängliche Erfassung, die Messung der Kanalqualität und die Kanalschätzung für die kohärente Demodulation/Erkennung am UE. Die LTE-Luftschnittstelle kann in Bändern unter 6 GHz arbeiten.
  • Das RAN 904 kann ein Next Generation (NG)-RAN 914 mit gNBs, zum Beispiel gNB 916, oder ng-eNBs, zum Beispiel ng-eNB 918, sein. Der gNB 916 kann sich mit 5G-fähigen UEs über eine 5G-NR-Schnittstelle verbinden. Der gNB 916 kann mit einem 5G-Kern über eine NG-Schnittstelle verbunden sein, die eine N2-Schnittstelle oder eine N3-Schnittstelle umfassen kann. Der ng-eNB 918 kann ebenfalls über eine NG-Schnittstelle mit dem 5G-Kern verbunden sein, kann aber über eine LTE-Luftschnittstelle mit einem UE verbunden sein. Der gNB 916 und der ng-eNB 918 können über eine Xn-Schnittstelle miteinander verbunden sein.
  • Die NG-Schnittstelle kann in zwei Teile aufgeteilt werden, eine NG-U-Schnittstelle (NG-U), die Verkehrsdaten zwischen den Knoten des NG-RAN 914 und einer UPF-Funktion (Benutzerebenenfunktion (User Plane Function)) 948 (z.B. N3-Schnittstelle) überträgt, und eine NG-C-Schnittstelle (NG-Steuerebene (NG-Control Plane)), die eine Signalisierungsschnittstelle zwischen den Knoten des NG-RAN 914 und einer AMF-Funktion (Zugangs- und Mobilitäts-Funktion (Access and Mobility Management Function)) 944 (z.B. N2-Schnittstelle) ist.
  • Das NG-RAN 914 kann eine 5G-NR-Luftschnittstelle mit den folgenden Merkmalen bereitstellen: variable SCS; CP-OFDM für DL, CP-OFDM und diskrete Fourier-Transformations-Spreiz-OFDM (DFT-s-OFDM) für UL; Polar-, Repetitions-, Simplex- und Reed-Muller-Codes für die Steuerung und Low-Density-Parity-Check (LDPC) für Daten. Die 5G-NR-Luftschnittstelle kann ähnlich wie die LTE-Luftschnittstelle auf CSI-RS, PDSCH/PDCCH DMRS basieren. Die 5G-NR Luftschnittstelle kann kein CRS verwenden, sondern kann Physical Broadcast Channel (PBCH) DMRS für die PBCH-Demodulation, Phase Tracking Reference Signals (PTRS) für die Phasenverfolgung für PDSCH und Tracking Reference Signals für die Zeitverfolgung verwenden. Die 5G-NR-Luftschnittstelle kann in Frequenzbereich 1 (FR1), der Bänder unter 6 GHz umfasst, oder in Frequenzbereich 2 (FR2), der Bänder von 24,25 GHz bis 52,6 GHz umfasst, betrieben werden. Die 5G-NR-Luftschnittstelle kann einen Synchronisationssignalblock (SSB) enthalten, der ein Bereich eines Downlink-Ressourcenrasters ist, das Primärsynchronisationssignal (PSS)/Seitenband-Synchronisationssignal (SSS)/PBCH enthält.
  • Die 5G-NR-Luftschnittstelle kann Bandbreitenteile (BWP) für verschiedene Zwecke verwenden. Zum Beispiel kann BWP für die dynamische Anpassung des SCS verwendet werden. Zum Beispiel kann das UE 902 mit mehreren BWPs konfiguriert sein, wobei jede BWP-Konfiguration eine andere SCS hat. Wenn dem UE 902 eine BWP-Änderung angezeigt wird, wird auch die SCS der Übertragung geändert. Ein weiteres Anwendungsbeispiel für BWP bezieht sich auf die Energieeinsparung. Insbesondere können mehrere BWP für das UE 902 mit unterschiedlichen Frequenzressourcen (z.B. physikalische Ressourcenblöcke (PRB)) konfiguriert sein, um die Datenübertragung in verschiedenen Verkehrsszenarien zu unterstützen. Ein BWP, der eine geringere Anzahl von PRBs enthält, kann für die Datenübertragung mit geringer Verkehrslast verwendet werden und ermöglicht gleichzeitig Energieeinsparungen bei dem UE 902 und in einigen Fällen beim gNB 916. Ein BWP mit einer größeren Anzahl von PRBs kann für Szenarien mit höherer Verkehrslast verwendet werden.
  • Das RAN 904 ist kommunikativ mit dem CN 920 gekoppelt, das Netzwerkelemente enthält, um verschiedene Funktionen zur Unterstützung von Daten- und Telekommunikationsdiensten für Kunden/Teilnehmer (z.B. Benutzer des UE 902) bereitzustellen. Die Komponenten des CN 920 können in einem physischen Knoten oder in separaten physischen Knoten implementiert sein. Die Netzwerkfunktionsvisualisierung (NFV) kann genutzt werden, um einige oder alle von den Netzwerkelementen des CN 920 bereitgestellten Funktionen auf physische Rechen-/Speicherressourcen in Servern, Switches usw. zu virtualisieren. Eine logische Instanziierung des CN 920 kann als Netzwerk-Slice bezeichnet werden, und eine logische Instanziierung eines Teils des CN 920 kann als Netzwerk-Sub-Slice bezeichnet werden.
  • Das CN 920 kann ein LTE CN 922 sein, das auch als Evolved Packet Control (EPC) bezeichnet werden kann. Das LTE CN 922 kann die Mobility Management Entity (MME) 924, den Serving Gateway (SGW oder S-GW) 926, den Service General Packet Radio Service (GPRS) Support Node (SGSN) 928, den Home Subscriber Server (HSS) 930, den Packet Data Network (PDN) Gateway (PGW oder P-GW) 932 und die Policy Control and Charging Rules Function (PCRF) 934 umfassen, die über Schnittstellen (oder „Referenzpunkte“) miteinander gekoppelt sind, wie gezeigt. Die Funktionen der Elemente des LTE CN 922 können wie folgt kurz vorgestellt werden.
  • Die MME 924 kann Mobilitätsmanagementfunktionen implementieren, um einen aktuellen Standort des UE 902 zu verfolgen, um Paging, Trägeraktivierung/-deaktivierung, Handover, Gateway-Auswahl, Authentifizierung usw. zu erleichtern.
  • Das SGW 926 kann eine S1-Schnittstelle zum RAN abschließen und Datenpakete zwischen dem RAN und dem LTE CN 922 weiterleiten. Das SGW 926 kann ein lokaler Mobilitätsankerpunkt für Inter-RAN-Knoten-Handover sein und kann auch einen Anker für Inter-3GPP-Mobilität bereitstellen. Weitere Aufgaben können rechtmäßiges Abfangen, Gebührenerhebung und die Durchsetzung einiger Richtlinien sein.
  • Das SGSN 928 kann den Standort des UE 902 verfolgen und Sicherheitsfunktionen und Zugangskontrolle durchführen. Darüber hinaus kann der SGSN 928 die Signalisierung zwischen EPC-Knoten für die Mobilität zwischen verschiedenen Funkzugangstechnologien (RAT), die PDN- und S-GW-Auswahl gemäß MME 924, die MME-Auswahl für Handover usw. durchführen. Der S3-Referenzpunkt zwischen der MME 924 und dem SGSN 928 kann den Austausch von Benutzer- und Trägerinformationen für die Mobilität zwischen 3GPP-Zugangsnetzen im Ruhe-/Aktivzustand ermöglichen.
  • Der HSS 930 kann eine Datenbank für Netzwerknutzer enthalten, einschließlich abonnementbezogener Informationen zur Unterstützung der Handhabung von Kommunikationssitzungen durch die Netzeinheiten. Der HSS 930 kann Unterstützung für Routing/Roaming, Authentifizierung, Autorisierung, Namens-/Adressierungsauflösung, Standortabhängigkeiten usw. bieten. Ein S6a-Referenzpunkt zwischen dem HSS 930 und der MME 924 kann die Übertragung von Abonnement- und Authentifizierungsdaten zur Authentifizierung/Autorisierung des Benutzerzugangs zum LTE CN 920 ermöglichen.
  • Das PGW 932 kann eine SGi-Schnittstelle zu einem Datennetzwerk (DN) 936 abschließen, das einen Anwendungs-/Inhaltsserver 938 enthalten kann. Das PGW 932 kann Datenpakete zwischen dem LTE CN 922 und dem Datennetz 936 weiterleiten. Das PGW 932 kann mit dem SGW 926 über einen S5-Referenzpunkt gekoppelt sein, um das Tunneln der Benutzerebene und das Tunnelmanagement zu erleichtern. Das PGW 932 kann außerdem einen Knoten für die Durchsetzung von Richtlinien und die Erhebung von Gebührendaten enthalten (z.B. eine Funktion zur Durchsetzung von Richtlinien und Gebühren (PCEF)). Darüber hinaus kann der SGi-Bezugspunkt zwischen dem PGW 932 und dem Datennetzwerk 9 36 ein externes öffentliches, ein privates PDN oder ein betreiberinternes Paketdatennetzwerk sein, z.B. für die Bereitstellung von IP-Multimedia-Subsystem-Diensten (IMS). Das PGW 932 kann mit einem PCRF 934 über einen Gx-Referenzpunkt gekoppelt sein.
  • Die PCRF 934 ist das Regelungs- und Gebührenkontrollelement des LTE CN 922. Die PCRF 934 kann kommunikativ mit dem App-/Inhaltsserver 938 verbunden sein, um geeignete QoS- und Gebührenparameter für Dienstflüsse zu ermitteln. Die PCRF 932 kann zugehörige Regeln in einer PCEF (über einen Gx-Referenzpunkt) mit einer geeigneten Verkehrsflussvorlage (TFT) und einer QoS-Klassenkennung (QCI) bereitstellen.
  • Das CN 920 kann ein 5G-Kernnetzwerk (5GC) 940 sein. Das 5GC 940 kann eine Authentifizierungsserverfunktion (AUSF) 942, eine AMF 944, eine Sitzungsverwaltungsfunktion (SMF) 946, eine UPF 948, eine Netzwerk-Slice-Auswahlfunktion (NSSF) 950, eine Netzwerkexpositionsfunktion (NEF) 952, eine Netzwerkspeicherfunktion (NRF) 954, eine Richtlinienkontrollfunktion (PCF) 956, eine einheitliche Datenverwaltung (UDM) 958 und eine Anwendungsfunktion (AF) 960 umfassen, die über Schnittstellen (oder „Bezugspunkte“) miteinander gekoppelt sind, wie gezeigt. Die Funktionen der Elemente des 5GC 940 können wie folgt kurz vorgestellt werden.
  • Die AUSF 942 kann Daten für die Authentifizierung der UE 902 speichern und authentifizierungsbezogene Funktionen ausführen. Die AUSF 942 kann einen gemeinsamen Authentifizierungsrahmen für verschiedene Zugangsarten ermöglichen. Zusätzlich zur Kommunikation mit anderen Elementen des 5GC 940 über Referenzpunkte, wie gezeigt, kann das AUSF 942 eine Nausf-Service-basierte Schnittstelle aufweisen.
  • Die AMF 944 kann es anderen Funktionen des 5GC 940 ermöglichen, mit dem UE 902 und dem RAN 904 zu kommunizieren und Benachrichtigungen über Mobilitätsereignisse in Bezug auf das UE 902 zu abonnieren. Die AMF 944 kann für das Registrierungsmanagement (z.B. für die Registrierung des UE 902), das Verbindungsmanagement, das Erreichbarkeitsmanagement, das Mobilitätsmanagement, das rechtmäßige Abfangen von AMF-bezogenen Ereignissen und die Zugangsauthentifizierung und -autorisierung zuständig sein. Die AMF 944 kann den Transport von Sitzungsmanagement-Nachrichten (SM) zwischen dem UE 902 und der SMF 946 bereitstellen und als transparenter Proxy für die Weiterleitung von SM-Nachrichten fungieren. AMF 944 kann auch den Transport von SMS-Nachrichten (Kurznachrichtendienst (Short Message Service)) zwischen dem UE 902 und einer SMS-Funktion (SMSF) bereitstellen. AMF 944 kann mit der AUSF 942 und dem UE 902 interagieren, um verschiedene Sicherheitsanker- und Kontextmanagementfunktionen auszuführen. Darüber hinaus kann AMF 944 ein Abschlusspunkt einer RAN-CP-Schnittstelle sein, die einen N2-Referenzpunkt zwischen dem RAN 904 und AMF 944 enthalten oder sein kann; und AMF 944 kann ein Abschlusspunkt der Nicht-Zugangsschicht (NAS) (N1)-Signalisierung sein und NAS-Verschlüsselung und Integritätsschutz durchführen. AMF 944 kann auch NAS-Signalisierung mit der UE 902 über eine N3-Interworking-Funktion (IWF) Schnittstelle unterstützen.
  • Die SMF 946 kann verantwortlich sein für SM (z.B. Sitzungsaufbau, Tunnelmanagement zwischen UPF 948 und AN 908); Zuweisung und Verwaltung von UE-IP-Adressen (einschließlich optionaler Autorisierung); Auswahl und Kontrolle der UP-Funktion; Konfiguration der Verkehrslenkung bei UPF 948, um den Verkehr zum richtigen Ziel zu leiten; Beendigung von Schnittstellen zu Richtlinienkontrollfunktionen; Kontrolle von Teilen der Richtliniendurchsetzung, Gebührenerhebung und QoS; rechtmäßiges Abfangen (für SM-Ereignisse und die Schnittstelle zum LI-System); Beendigung von SM-Teilen von NAS-Nachrichten; Downlink-Datenbenachrichtigung; Initiierung AN-spezifischer SM-Informationen, die über AMF 944 über N2 an AN 908 gesendet werden; und Bestimmung des Sitzungs- und Dienstkontinuitätsmodus (SSC) einer Sitzung. SM kann sich auf die Verwaltung einer PDU-Sitzung beziehen, und eine PDU-Sitzung oder „Sitzung“ kann sich auf einen PDU-Konnektivitätsdienst beziehen, der den Austausch von PDUs zwischen dem UE 902 und dem Datennetzwerk 936 bereitstellt oder ermöglicht.
  • Die UPF 948 kann als Ankerpunkt für Intra-RAT- und Inter-RAT-Mobilität, als externer PDU-Sitzungs-Verbindungspunkt zum Datennetzwerk 936 und als Verzweigungspunkt zur Unterstützung von Multihomed-PDU-Sitzungen dienen. Die UPF 948 kann auch Paketrouting und -weiterleitung, Paketinspektion, Durchsetzung des Benutzerebenen-Teils von Richtlinienregeln, rechtmäßiges Abfangen von Paketen (Sammlung der Benutzerebene (UP)), Verkehrsnutzungsberichte, QoS-Behandlung für eine Benutzerebene (z.B., Paketfilterung, Gating, UL/DL-Ratenerzwingung), Verifizierung des Uplink-Verkehrs (z.B. Zuordnung von Dienstdatenflüssen (SDF) zu QoS-Flüssen), Markierung von Paketen auf Transportebene im Uplink und im Downlink sowie Pufferung von Paketen im Downlink und Auslösung von Datenbenachrichtigungen im Downlink. Die UPF 948 kann einen Uplink-Klassifikator enthalten, um die Weiterleitung von Verkehrsflüssen an ein Datennetzwerk zu unterstützen.
  • Die NSSF 950 kann einen Satz von Netzwerk-Slice-Instanzen auswählen, die das UE 902 bedienen. Die NSSF 950 kann auch zulässige NSSAI und die Zuordnung zu den abonnierten einzelnen NSSAI (S-NSSAI) ermitteln, falls erforderlich. Die NSSF 950 kann auch den AMF-Satz ermitteln, der zur Versorgung der UE 902 verwendet werden soll, oder eine Liste von AMF-Kandidaten auf der Grundlage einer geeigneten Konfiguration und möglicherweise durch Abfrage der NRF 954. Die Auswahl eines Satzes von Netzwerk-Slice-Instanzen für das UE 902 kann durch die AMF 944 ausgelöst werden, bei der das UE 902 durch Interaktion mit der NSSF 950 registriert ist, was zu einem Wechsel der AMF führen kann. Die NSSF 950 kann mit der AMF 944 über einen N22-Referenzpunkt interagieren und mit einer anderen NSSF in einem besuchten Netzwerk über einen N31-Referenzpunkt (nicht dargestellt) kommunizieren. Zusätzlich kann die NSSF 950 eine Nnssf-Dienst-basierte Schnittstelle aufweisen.
  • Die NEF 952 kann Dienste und Fähigkeiten, die von 3GPP-Netzwerkfunktionen bereitgestellt werden, für Dritte, interne Exposition/Re-Exposition, AFs (z.B. AF 960), Edge-Computing- oder Fog-Computing-Systeme usw. sicher offenlegen. Die NEF 952 kann die AFs authentifizieren, autorisieren oder drosseln. Die NEF 952 kann auch mit der AF 960 ausgetauschte Informationen und mit internen Netzwerkfunktionen ausgetauschte Informationen übersetzen. So kann die NEF 952 beispielsweise zwischen einem AF-Service-Identifier und einer internen 5GC-Information übersetzen. Die NEF 952 kann auch Informationen von anderen NFs empfangen, die auf den offengelegten Fähigkeiten anderer NFs basieren. Diese Informationen können in der NEF 952 als strukturierte Daten oder in einer Datenspeicher-NF unter Verwendung standardisierter Schnittstellen gespeichert werden. Die gespeicherten Informationen können dann von der NEF 952 an andere NFs und AFs weitergegeben oder für andere Zwecke, wie z.B. Analysen, verwendet werden. Darüber hinaus kann die NEF 952 eine Nnef-Dienst-basierte Schnittstelle aufweisen.
  • Die NRF 954 kann Service-Discovery-Funktionen unterstützen, NF-Discovery-Anfragen von NF-Instanzen empfangen und die Informationen der entdeckten NF-Instanzen an die NF-Instanzen weitergeben. Die NRF 954 verwaltet auch Informationen über verfügbare NF-Instanzen und deren unterstützte Dienste. Wie hierin verwendet, können sich die Begriffe „instanziieren“, „Instanziierung“ und dergleichen auf die Erstellung einer Instanz beziehen, und eine „Instanz“ kann sich auf ein konkretes Auftreten eines Objekts beziehen, das z.B. während der Ausführung von Programmcode auftreten kann. Zusätzlich kann das NRF 954 die Nnrf-Dienst-basierte Schnittstelle aufweisen.
  • Die PCF 956 kann Richtlinienregeln für Steuerebenenfunktionen bereitstellen, um diese durchzusetzen, und kann auch einen einheitlichen Richtlinienrahmen unterstützen, um das Netzwerkverhalten zu steuern. Die PCF 956 kann auch ein Front-End implementieren, um auf Abonnementinformationen zuzugreifen, die für Richtlinien-Entscheidungen in einem Unified Data Repository (UDR) des UDM 958 relevant sind. Zusätzlich zur Kommunikation mit Funktionen über Referenzpunkte, wie gezeigt, weist die PCF 956 eine Npcf-Dienst-basierte Schnittstelle auf.
  • Das UDM 958 kann abonnementbezogene Informationen verarbeiten, um die Verarbeitung von Kommunikationssitzungen durch die Netzwerkentitäten zu unterstützen, und kann Abonnementdaten des UE 902 speichern. Zum Beispiel können Abonnementdaten über einen N8-Referenzpunkt zwischen dem UDM 958 und der AMF 944 kommuniziert werden. Das UDM 958 kann zwei Teile umfassen, ein Anwendungs-Frontend und einen UDR. Das UDR kann Abonnementdaten und Richtliniendaten für das UDM 958 und die PCF 956 und/oder strukturierte Daten für die Exposition und Anwendungsdaten (einschließlich Paketflussbeschreibungen (PFD) für die Anwendungserkennung, Anwendungsanforderungsinformationen für mehrere UEs 902) für die NEF 952 speichern. Die auf dem Nudr-Dienst-basierte Schnittstelle kann vom UDR 221 ausgestellt werden, um dem UDM 958, PCF 956 und NEF 952 den Zugriff auf einen bestimmten Satz der gespeicherten Daten sowie das Lesen, Aktualisieren (z.B. Hinzufügen, Ändern), Löschen und Abonnieren von Benachrichtigungen über relevante Datenänderungen im UDR zu ermöglichen. Das UDM kann ein UDM-Frontend (FE) umfassen, das für die Verarbeitung von Anmeldeinformationen, die Standortverwaltung, die Abonnementverwaltung usw. zuständig ist. Mehrere verschiedene Frontends können denselben Benutzer in verschiedenen Transaktionen bedienen. Das UDM-FE greift auf die im UDR gespeicherten Abonnementinformationen zu und führt die Verarbeitung von Authentifizierungsnachweisen, die Handhabung der Benutzeridentifikation, die Zugangsberechtigung, die Verwaltung der Registrierung/Mobilität und die Abonnementverwaltung durch. Zusätzlich zur Kommunikation mit anderen NFs über Referenzpunkte, wie gezeigt, kann das UDM 958 die Nudm-Dienst-basierte Schnittstelle aufweisen.
  • Die AF 960 kann den Einfluss der Anwendung auf die Verkehrslenkung gewährleisten, Zugang zu NEF bieten und mit dem Richtlinien-Framework für die Richtlinien-Kontrolle interagieren.
  • Der 5GC 940 kann Edge Computing ermöglichen, indem er Dienste von Betreibern/Drittanbietern so auswählt, dass sie sich geografisch in der Nähe eines Punktes befinden, an dem das UE 902 mit dem Netzwerk verbunden ist. Dies kann die Latenzzeit und die Belastung des Netzes verringern. Um Edge-Computing-Implementierungen bereitzustellen, kann der 5GC 940 eine UPF 948 in der Nähe des UE 902 auswählen und eine Verkehrslenkung von der UPF 948 zum Datennetzwerk 936 über die N6-Schnittstelle durchführen. Dies kann auf der Grundlage der UE-Abonnementdaten, des UE-Standorts und der von der AF 960 bereitgestellten Informationen erfolgen. Auf diese Weise kann die AF 960 die UPF-(Neu-)Auswahl und die Verkehrslenkung beeinflussen. Wenn AF 960 als vertrauenswürdige Instanz betrachtet wird, kann der Netzwerkbetreiber AF 960 erlauben, direkt mit den relevanten NFs zu interagieren. Zusätzlich kann die AF 960 eine Naf-Dienst-basierte Schnittstelle aufweisen.
  • Das Datennetzwerk 936 kann verschiedene Dienste des Netzwerkbetreibers, Internetzugang oder Dienste von Drittanbietern darstellen, die von einem oder mehreren Servern bereitgestellt werden können, z.B. Anwendungs-/Inhaltsserver 938.
  • 10 zeigt schematisch ein Drahtlos-Netzwerk 1000 gemäß dieser Offenbarung. Das Drahtlos-Netzwerk 1000 kann ein UE 1002 in Drahtlos-Kommunikation mit AN 1004 umfassen. Das UE 1002 und AN 1004 können ähnlich und im Wesentlichen austauschbar mit gleichnamigen Komponenten sein, die an anderer Stelle hierin beschrieben sind.
  • Das UE 1002 kann über die Verbindung 1006 mit dem AN 1004 kommunikativ gekoppelt sein. Die Verbindung 1006 ist als Luftschnittstelle dargestellt, um eine kommunikative Kopplung zu ermöglichen, und kann mit zellularen Kommunikationsprotokollen wie einem LTE-Protokoll oder einem 5G NR-Protokoll, das bei mmWave- oder sub-6GHz-Frequenzen arbeitet, übereinstimmen.
  • Das UE 1002 kann eine Host-Plattform 1008 umfassen, die mit einer Modem-Plattform 1010 gekoppelt ist. Die Host-Plattform 1008 kann eine Verarbeitungsschaltung 1012 enthalten, die mit der Protokollverarbeitungsschaltung 1014 der Modem-Plattform 1010 gekoppelt sein kann. Die Verarbeitungsschaltung 1012 kann verschiedene Anwendungen für das UE 1002 ausführen, die Anwendungsdaten liefern/senden. Die Verarbeitungsschaltung 1012 kann darüber hinaus eine oder mehrere Schichtoperationen implementieren, um Anwendungsdaten an ein Datennetzwerk zu senden/von diesem zu empfangen. Diese Schichtoperationen können Transport- (z.B. User Datagram Protocol (UDP)) und Internet- (z. B. IP) Operationen umfassen
  • Die protokollverarbeitende Schaltung 1014 kann eine oder mehrere der Schichtoperationen implementieren, um die Übertragung oder den Empfang von Daten über die Verbindung 1006 zu erleichtern. Die von der protokollverarbeitenden Schaltung 1014 implementierten Schichtoperationen können z.B. MAC-, RLC-, PDCP-, RRC- und NAS-Operationen umfassen.
  • Die Modem-Plattform 1010 kann ferner eine digitale Basisbandschaltung 1016 enthalten, die eine oder mehrere Schichtoperationen implementieren kann, die „unterhalb“ von Schichtoperationen liegen, die von der Verarbeitungsschaltung 1014 in einem Netzwerkprotokollstapel ausgeführt werden. Diese Operationen können beispielsweise Operationen der physikalischen Schicht (PHY) umfassen, einschließlich einer oder mehrerer hybrider automatischer Wiederholungsanforderungs- (HARQ) und Rückbestätigungsfunktionen (ACK), Verschlüsselung/Descrambling, Kodierung/Dekodierung, Schichtabbildung/De-Abbildung, Modulationssymbolabbildung, Ermittlung der empfangenen Symbole/Bit-Metrik, Vorcodierung/Decodierung von Mehrantennenanschlüssen, die eine oder mehrere der folgenden Funktionen umfassen kann: Raum-Zeit-, Raum-Frequenz- oder räumliche Codierung, Erzeugung/Detektion von Referenzsignalen, Erzeugung und/oder Decodierung von Präambelsequenzen, Erzeugung/Detektion von Synchronisationssequenzen, Blinddecodierung von Steuerkanalsignalen und andere verwandte Funktionen.
  • Die Modem-Plattform 1010 kann ferner eine Sendeschaltung 1018, eine Empfangsschaltung 1020, eine HF-Schaltung 1022 und ein HF-Frontend (RFFE) 1024 umfassen, das eine oder mehrere Antennenfelder 1026 enthalten oder mit diesen verbunden sein kann. Kurz gesagt kann die Sendeschaltung 1018 einen Digital-Analog-Wandler, einen Mischer, Zwischenfrequenzkomponenten usw. umfassen. Die Empfangsschaltung 1020 kann einen Analog-Digital-Wandler, einen Mischer, ZF-Komponenten usw. enthalten; die HF-Schaltung 1022 kann einen rauscharmen Verstärker, einen Leistungsverstärker, Leistungsnachführungskomponenten usw. enthalten; die RFFE 1024 kann Filter (z.B. Oberflächen-/Bulk-Akustikwellenfilter), Schalter, Antennentuner, Strahlformungskomponenten (z.B. Phasengruppenantennenkomponenten) usw. enthalten. Die Auswahl und Anordnung der Komponenten der Sendeschaltung 1018, der Empfangsschaltung 1020, der HF-Schaltung 1022, der RFFE 1024 und der Antennenpaneele 1026 (allgemein als „Sende-/Empfangskomponenten“ bezeichnet) kann sich nach den Einzelheiten einer bestimmten Implementierung richten, z.B. ob die Kommunikation im Zeitmultiplexverfahren (TDM) oder im Frequenzmultiplexverfahren (FDM), in mmWave- oder Sub-6-GHz-Frequenzen erfolgt, usw. Die Sende-/Empfangskomponenten können in mehreren parallelen Sende- /Empfangsketten angeordnet sein, sie können in denselben oder in verschiedenen Chips/Modulen untergebracht sein, usw.
  • Die Verarbeitungsschaltung für das Protokoll 1014 kann eine oder mehrere Instanzen von Steuerschaltungen (nicht dargestellt) enthalten, um Steuerfunktionen für die Sende-/Empfangskomponenten bereitzustellen.
  • Ein UE-Empfang kann durch und über die Antennenfelder 1026, die RFFE 1024, die HF-Schaltung 1022, die Empfangsschaltung 1020, die digitale Basisbandschaltung 1016 und die Protokollverarbeitungsschaltung 1014 hergestellt werden. Die Antennenfelder 1026 können eine Übertragung von der AN 1004 durch Empfangsstrahlformung von Signalen empfangen, die von einer Vielzahl von Antennen/Antennenelementen des einen oder der mehreren Antennenfelder 1026 empfangen werden.
  • Eine UE-Übertragung kann durch und über die Protokollverarbeitungsschaltung 1014, die digitale Basisbandschaltung 1016, die Sendeschaltung 1018, die HF-Schaltung 1022, die RFFE 1024 und die Antennenfelder 1026 aufgebaut werden. Die Sendekomponenten der UE 1004 können einen räumlichen Filter auf die zu übertragenden Daten anwenden, um einen von den Antennenelementen der Antennenfelder 1026 ausgesandten Sendestrahl zu bilden.
  • Ähnlich wie das UE 1002 kann der AN 1004 eine Host-Plattform 1028 umfassen, die mit einer Modem-Plattform 1030 gekoppelt ist. Die Host-Plattform 1028 kann eine Verarbeitungsschaltung 1032 enthalten, die mit einer Protokollverarbeitungsschaltung 1034 der Modem-Plattform 1030 gekoppelt ist. Die Modem-Plattform kann ferner eine digitale Basisbandschaltung 1036, eine Sendeschaltung 1038, eine Empfangsschaltung 1040, eine HF-Schaltung 1042, eine RFFE-Schaltung 1044 und Antennenfelder 1046 umfassen. Die Komponenten des AN 1004 können den gleichnamigen Komponenten des UE 1002 ähnlich und im Wesentlichen mit ihnen austauschbar sein. Zusätzlich zur Durchführung von Datenübertragung/- empfang, wie oben beschrieben, können die Komponenten des AN 1008 verschiedene logische Funktionen ausführen, die zum Beispiel RNC-Funktionen wie Radio Bearer Management, Uplink- und Downlink Dynamic Radio Resource Management und Datenpaket-Scheduling umfassen.
  • 11 ist ein Blockdiagramm, das Komponenten veranschaulicht, die in der Lage sind, Befehle von einem maschinenlesbaren oder computerlesbaren Medium (z.B. einem nichttransitorischen maschinenlesbaren Speichermedium) zu lesen und eine oder mehrere der hier erörterten Methoden durchzuführen. 11 zeigt insbesondere eine schematische Darstellung von Hardwareressourcen 1100, einschließlich eines oder mehrerer Prozessoren (oder Prozessorkerne) 1110, eines oder mehrerer Speichergeräte 1120 und einer oder mehrerer Kommunikationsressourcen 1130, von denen jede über einen Bus 1140 oder eine andere Schnittstellenschaltung kommunikativ gekoppelt sein kann. Wenn Knotenvirtualisierung (z.B. NFV) verwendet wird, kann ein Hypervisor 1102 ausgeführt werden, um eine Ausführungsumgebung für eine oder mehrere Netzwerk-Slices/Sub-Slices bereitzustellen, um die Hardware-Ressourcen 1100 zu nutzen.
  • Die Prozessoren 1110 können zum Beispiel einen Prozessor 1112 und einen Prozessor 1114 umfassen. Bei den Prozessoren 1110 kann es sich beispielsweise um eine Zentraleinheit (CPU), einen RISC-Prozessor (Reduzierter Instruktionssatz-Rechnen - Reduced Instruction Set Computing), einen CISC-Prozessor (Komplexer Instruktionssatz-Rechnen - Complex Instruction Set Computing), eine Grafikverarbeitungseinheit (GPU), einen DSP wie einen Basisbandprozessor, eine anwendungsspezifische integrierte Schaltung (ASIC), ein FPGA (Field-Programmable Gate Array), eine integrierte Hochfrequenzschaltung (RFIC), einen anderen Prozessor (einschließlich der hierin erörterten) oder eine beliebige geeignete Kombination davon handeln.
  • Die Speicher-/Speichervorrichtungen 1120 können einen Hauptspeicher, einen Plattenspeicher oder eine beliebige geeignete Kombination davon umfassen. Die Speicher-/Speichervorrichtungen 1120 können jede Art von flüchtigem, nichtflüchtigem oder halbflüchtigem Speicher umfassen, sind aber nicht darauf beschränkt, wie z.B. dynamischer Direktzugriffsspeicher (DRAM), statischer Direktzugriffsspeicher (SRAM), löschbarer programmierbarer Festwertspeicher (EPROM), elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM), Flash-Speicher, Festkörperspeicher usw.
  • Die Kommunikationsressourcen 1130 können Verbindungs- oder Netzwerkschnittstellen-Controller, Komponenten oder andere geeignete Geräte umfassen, um mit einem oder mehreren Peripheriegeräten 1104 oder einer oder mehreren Datenbanken 1106 oder anderen Netzwerkelementen über ein Netzwerk 1108 zu kommunizieren. Beispielsweise können die Kommunikationsressourcen 1130 drahtgebundene Kommunikationskomponenten (z.B. zur Kopplung über Universal Serial Bus (USB), Ethernet usw.), Komponenten für die zellulare Kommunikation, Komponenten für die Nahfeldkommunikation (NFC), Bluetooth® (oder Bluetooth® Low Energy), Wi-Fi®-Komponenten und andere Kommunikationskomponenten umfassen.
  • Die Anweisungen 1150 können Software, ein Programm, eine Anwendung, ein Applet, eine App oder einen anderen ausführbaren Code enthalten, um mindestens einen der Prozessoren 1110 zu veranlassen, eine oder mehrere der hier besprochenen Methoden durchzuführen. Die Anweisungen 1150 können sich vollständig oder teilweise in mindestens einem der Prozessoren 1110 (z.B. im Cache-Speicher des Prozessors), in den Speichergeräten 1120 oder in einer geeigneten Kombination davon befinden. Darüber hinaus kann ein beliebiger Teil der Anweisungen 1150 von einer beliebigen Kombination aus den Peripheriegeräten 1104 oder den Datenbanken 1106 an die Hardwareressourcen 1100 übertragen werden. Dementsprechend sind der Speicher der Prozessoren 1110, die Speicher/Speichergeräte 1120, die peripheren Geräte 1104 und die Datenbanken 1106 Beispiele für computerlesbare und maschinenlesbare Medien.
  • Das/die elektronische(n) Gerät(e), Netzwerk(e), System(e), Chip(s) oder Komponente(n) oder Teile oder Implementierungen davon der 9-11 oder einer anderen Figur hierin können so konfiguriert sein, dass sie einen oder mehrere Prozesse, Techniken oder Methoden, wie hierin beschrieben, oder Teile davon durchführen. Ein solcher Prozess 1200 ist in 12 dargestellt, der von einem Benutzergerät (UE) oder einem Teil davon durchgeführt werden kann. Zum Beispiel kann der Prozess bei 1201 die Überwachung des gemeinsam genutzten physischen Steuerkanals (PSCCH) durch das UE während einer aktiven Zeitperiode für das UE auf Sidelink-Steuerinformationen (SCI) in Verbindung mit einer Sidelink-Übertragung (SL) durch das UE umfassen. Das Verfahren umfasst ferner bei 1202 die Codierung einer Nachricht zur Übertragung über SL auf der Grundlage der SCI. Der Prozess umfasst ferner bei 1203 die Ermittlung von Konfigurationsinformationen für diskontinuierlichen Empfang (DRx), die mit Unicast-, Broadcast- oder Groupcast-Betrieb verbunden sind. Der Prozess umfasst ferner bei 1204 die Codierung einer Konfigurationsnachricht, die die DRx-Konfigurationsinformationen zur Übertragung an einen NodeB der nächsten Generation (gNB) enthält.
  • Ein weiterer solcher Prozess 1300 ist in 13 dargestellt, der von einem NodeB der nächsten Generation (gNB) oder einem Teil davon durchgeführt werden kann. In diesem Beispiel umfasst der Prozess 1300 bei 1301 die Ermittlung von Sidelink-Kontrollinformationen (SCI), die mit einer Sidelink-Übertragung (SL) durch ein Benutzergerät (UE) verbunden sind. Der Prozess 1300 umfasst ferner bei 1302 das Codieren einer Nachricht, die die SCI enthält, zur Übertragung an das UE über den Physikalischer Geteilter-Steuerungskanal (Physical Shared Control Channel - PSCCH). Der Prozess 1300 umfasst ferner bei 1303 das Empfangen einer Konfigurationsnachricht von dem UE, die diskontinuierliche Empfangs(DRx)-Konfigurationsinformationen enthält, die mit Unicast-, Broadcast- oder Groupcast-Betrieb durch das UE verbunden sind.
  • Ein weiterer solcher Prozess 1400 ist in 14 dargestellt. Der Prozess 1400 kann von einer UE oder einem Teil davon durchgeführt werden. Der Prozess 1400 kann bei 1401 die Ermittlung einer diskontinuierlichen Empfangskonfiguration (DRX) für einen Sidelink-Kanal beinhalten. Die DRX-Konfiguration kann z.B. einen Einschaltdauer-Timer, einen Inaktivitäts-Timer und/oder einen Wiederübertragungs-Timer umfassen. Die DRX-Konfiguration kann für zwei oder mehr (z.B. alle) RRC-Verbindungszustände des UE identisch sein. Das UE kann die DRX-Konfiguration je nach RRC-Verbindungszustand aus einer anderen Quelle ermitteln.
  • Bei 1402 kann der Prozess 1400 weiterhin das Kommunizieren auf dem Sidelink-Kanal basierend auf der DRX-Konfiguration beinhalten. Zum Beispiel kann das UE auf einen PDCCH überwachen (z.B. in einer aktiven Periode eines DRX-Zyklus).
  • Mindestens eine der in einer oder mehreren der vorangehenden Figuren dargestellten Komponenten kann so konfiguriert sein, dass sie eine oder mehrere Operationen, Techniken, Prozesse und/oder Methoden durchführt, wie im folgenden Beispielabschnitt dargelegt. Zum Beispiel kann die Basisbandschaltung, wie oben in Verbindung mit einer oder mehreren der vorangehenden Figuren beschrieben, so konfiguriert werden, dass sie gemäß einem oder mehreren der unten aufgeführten Beispiele funktioniert. Als weiteres Beispiel kann die Schaltung, die mit einem UE, einer Basisstation, einem Netzwerkelement usw. verbunden ist, wie oben in Verbindung mit einer oder mehreren der vorangehenden Figuren beschrieben, so konfiguriert werden, dass sie gemäß einem oder mehreren der unten im Beispielabschnitt aufgeführten Beispiele funktioniert.
  • BEISPIELE
  • Beispiel 1 kann ein Verfahren zum Betrieb eines Drahtlos-Systems umfassen, das die Angleichung der aktiven Zeit des diskontinuierlichen Empfangs (DRX) über NR Sidelink und NR Uu für einen effizienten Energiesparbetrieb ermöglicht.
  • Beispiel 2 kann das Verfahren von Beispiel 1 oder ein anderes Beispiel hierin umfassen, bei dem die DRX-Aktivzeit für die Uu-Schnittstelle und die Sidelink-Schnittstelle aufeinander abgestimmt ist.
  • Beispiel 3 kann das Verfahren aus Beispiel 2 oder ein anderes Beispiel hierin beinhalten, wobei der Abgleich unter Verwendung eines oder beider der folgenden Ansätze durchgeführt wird:
    1. a) UE überwacht PDCCH für die DCI-Planung sowohl für die Uu- als auch für die Sidelink-Übertragung
    2. b) UE überwacht PSCCH für SCI für die Planung über Sidelink
  • Beispiel 4 kann das Verfahren von Beispiel 3a oder ein anderes Beispiel hierin beinhalten, wobei die DRX-Konfiguration/Parameter sowohl für Uu als auch für SL dem UE durch das Netzwerk bereitgestellt werden.
  • Beispiel 5 kann das Verfahren von Beispiel 3a oder ein anderes Beispiel hierin beinhalten, wobei der gNB nur die Planung über PDCCH für Uu- oder Sidelink-Betrieb während der aktiven Zeit des UE sendet, wie durch die dem UE bereitgestellte DRX-Konfiguration ermittelt (wie in Beispiel 4).
  • Beispiel 6 kann das Verfahren von Beispiel 3b oder ein anderes Beispiel hierin beinhalten, wobei für Sidelink-Betrieb:
    1. a) Im Fall von Unicast-Betrieb zeigen die UE(s) der Gegenstelle dem gNB die bevorzugte Sidelink-DRX-Konfiguration an, indem sie entweder SidelinkUEInformationNR oder UEAssistanceInformation verwenden
    2. b) Im Falle von Groupcast/Broadcast zeigen die UEs dem gNB einzeln die bevorzugte DRX-Konfiguration oder Sidelink-Verkehrsmusterinformationen an.
  • Beispiel 7 kann das Verfahren von Beispiel 6 oder ein anderes Beispiel hierin beinhalten, wobei zumindest bevorzugte Werte des SL DRX Inaktivitäts-Timers und der DRX-Zyklusdauern für kurzen und langen DRX dem gNB angezeigt werden können.
  • Beispiel 8 kann das Verfahren von Beispiel 3b oder ein anderes Beispiel hierin beinhalten, wobei der gNB anschließend Uu- und SL-DRX-Parameter einplant, um eine Angleichung zwischen aktiven Zeiten zu gewährleisten.
  • Beispiel 9 kann das Verfahren von Beispiel 1 oder ein anderes Beispiel hierin beinhalten, bei dem die SL DRX-Aktivzeiten für gleichrangige UEs über die Nebenstrecke abgeglichen werden:
    1. a) Für Unicast kann die RRCReconfigurationSidelink-Prozedur verwendet werden, um dem Peer UE die bevorzugte DRX-Konfiguration anzuzeigen, die anschließend dem verbundenen gNB angezeigt wird.
    2. b) Bei Groupcast kann der Gruppenleiter die spezifische DRX-Konfiguration angeben, die von den UEs der Gruppenmitglieder auf der Grundlage der SL-Verkehrseigenschaften verwendet werden soll.
    3. c) Bei Broadcast stellt das Netzwerk dem UE eine SL-DRX-Konfiguration zur Verfügung, die für den gesamten SL-Verkehr einheitlich oder spezifisch auf der Grundlage von QoS-Anforderungen für einen bestimmten Dienst sein kann.
  • Beispiel 10 umfasst ein Verfahren eines Benutzergeräts (UE), das Folgendes umfasst: Überwachen des physischen Abwärtsstrecken-Steuerkanals (PDCCH) durch das UE während einer aktiven Zeitperiode für das UE auf Abwärtsstrecken-Steuerinformationen (DCI), die mit einer Uu-Schnittstellenübertragung durch das UE oder einer Sidelink-(SL)-Übertragung durch das UE verbunden sind; und Codieren einer Nachricht zur Übertragung über die SL- oder Uu-Schnittstelle auf der Grundlage der DCI.
  • Beispiel 11 umfasst das Verfahren von Beispiel 10 oder eines anderen Beispiels hierin, wobei die DCI ferner eine Angabe von einem oder mehreren diskontinuierlichen Empfangsparametern (DRx) umfasst.
  • Beispiel 12 umfasst ein Verfahren, das Folgendes umfasst: Ermitteln von Abwärtsstrecken-Steuerinformationen (DCI), die mit einer Uu-Schnittstellen-Übertragung durch ein Benutzergerät (UE) oder einer Nebenstrecken-Übertragung (SL) durch das UE verbunden sind; und Codieren einer Nachricht zur Übertragung an das UE, die die DCI enthält.
  • Beispiel 13 umfasst das Verfahren von Beispiel 12 oder eines anderen Beispiels hierin, wobei die DCI ferner eine Anzeige von einem oder mehreren diskontinuierlichen Empfangsparametern (DRx) umfasst.
  • Beispiel 14 umfasst das Verfahren der Beispiele 12 oder 13 oder ein anderes Beispiel hierin, wobei das Verfahren von einem NodeB der nächsten Generation (gNB) oder einem Teil davon durchgeführt wird.
  • Beispiel 15 umfasst ein Verfahren eines Benutzergeräts (UE), das Folgendes umfasst:
  • Überwachen eines physikalischen gemeinsam genutzten Steuerkanals (PSCCH) durch das UE während einer aktiven Zeitperiode für das UE auf Sidelink-Steuerinformationen (SCI), die mit einer Sidelink-(SL)-Übertragung durch das UE verbunden sind; und Codieren einer Nachricht für die Übertragung über SL auf der Grundlage der SCI; Bestimmen von diskontinuierlichen Empfangs-(DRx)-Konfigurationsinformationen, die mit einem Unicast-, Broadcast- oder Groupcast-Betrieb verbunden sind; und Codieren einer Konfigurationsnachricht, die die DRx-Konfigurationsinformationen enthält, für die Übertragung an ein NodeB der nächsten Generation (gNB).
  • Beispiel 16 umfasst das Verfahren von Beispiel 15 oder ein anderes Beispiel hierin, wobei die DRx-Konfigurationsinformationen mit Unicast-Betrieb verbunden sind und in SidelinkUEInformationNR oder UEAssistanceInformation enthalten sind.
  • Beispiel 17 umfasst das Verfahren von Beispiel 16 oder ein anderes Beispiel hierin, wobei die DRx-Konfigurationsinformationen eine Anzeige eines SL-DRx-Inaktivitäts-Timers enthalten.
  • Beispiel 18 umfasst das Verfahren von Beispiel 16 oder ein anderes Beispiel hierin, wobei die DRx-Konfigurationsinformationen eine Angabe einer DRx-Zyklusdauer enthalten.
  • Beispiel 19 umfasst ein Verfahren, das Folgendes umfasst: Ermitteln von Sidelink-Steuerinformationen (SCI), die mit einer Sidelink-(SL)-Übertragung durch ein Benutzergerät (UE) verbunden sind; Codieren einer Nachricht, die die SCI enthält, zur Übertragung an das UE über einen gemeinsam genutzten physikalischen Steuerkanal (PSCCH); und Empfangen einer Konfigurationsnachricht von dem UE, die diskontinuierliche Empfangs-(DRx)-Konfigurationsinformationen enthält, die mit einem Unicast-, Broadcast- oder Groupcast-Betrieb durch das UE verbunden sind.
  • Beispiel 20 umfasst das Verfahren von Beispiel 19 oder ein anderes Beispiel hierin, wobei die DRx-Konfigurationsinformationen mit Unicast-Betrieb verbunden sind und in SidelinkUEInformationNR oder UEAssistanceInformation enthalten sind.
  • Beispiel 21 umfasst das Verfahren von Beispiel 20 oder ein anderes Beispiel hierin, wobei die DRx-Konfigurationsinformationen eine Anzeige eines SL-DRx-Inaktivitäts-Timers enthalten.
  • Beispiel 22 umfasst das Verfahren von Beispiel 20 oder ein anderes Beispiel hierin, wobei die DRx-Konfigurationsinformationen eine Angabe einer DRx-Zyklusdauer enthalten.
  • Beispiel 23 umfasst das Verfahren eines der Beispiele 16-22 oder eines anderen Beispiels hierin, wobei das Verfahren von einem NodeB der nächsten Generation (gNB) oder einem Teil davon durchgeführt wird.
  • Beispiel 24 kann ein Verfahren umfassen, das einen diskontinuierlichen Empfangsmechanismus (DRX) über NR-Sidelink für einen effizienten Energiesparbetrieb ermöglicht.
  • Beispiel 25 kann das Verfahren von Beispiel 24 oder ein anderes Beispiel hierin beinhalten, bei dem das UE denselben SL-DRX-Zyklus unabhängig von seinem Versorgungszustand (z. B. RRC_CONNECTED, RRC_IDLE/RRC_INACTIVE oder außerhalb der Versorgung) verwendet.
  • Beispiel 26 kann das Verfahren von Beispiel 25 oder ein anderes Beispiel hierin beinhalten, wobei das UE die relevante Konfiguration für SL DRX in Abhängigkeit von seinem Versorgungszustand erhält:
    1. a) Im Falle von RRC_CONNECTED erhält das UE die Konfiguration mittels dedizierter Signalisierung (durch RRCReconfiguration).
    2. b) Im Falle von RRC_IDLE/RRC_INACTIVE kann die UE die Konfiguration durch Lesen der entsprechenden SIB erhalten
    3. c) Im Falle von Out-of-Coverage kann sich das UE auf die (Vor-)Konfiguration verlassen, um die relevante Konfiguration zu erhalten.
  • Beispiel 27 kann das Verfahren von Beispiel 24 oder ein anderes Beispiel hierin beinhalten, wobei sowohl lange als auch kurze DRX-Zyklen für den SL-Betrieb entworfen und konfiguriert werden können:
    1. a) Das Uu-Verhalten und die Konfiguration für Sidelink können wiederverwendet werden, z.B. kann das Netzwerk eine Konfiguration für sowohl kurze als auch lange Zyklen für Sidelink bereitstellen, und wenn ein kurzer Zyklus konfiguriert ist, wird er von dem UE bevorzugt verwendet.
    2. b) Sowohl kurze als auch lange DRX-Zyklen für Sidelink werden definiert und einem Satz von Diensten (Typen) oder QoS-Profilen für SL-Verkehr zugeordnet. Die Auswahl des entsprechenden DRX-Zyklus wird der UE-Implementierung überlassen.
    3. c) Ein einziger und aggressiverer DRX-Zyklus (z. B. weniger als normale Schlafmöglichkeiten) kann vom Netz definiert und konfiguriert werden, um alle Arten von Sidelink-Verkehr zu bedienen.
  • Beispiel 28 kann das Verfahren von Beispiel 24 oder ein anderes hierin beschriebenes Beispiel umfassen, bei dem die Berichterstattung über Sidelink-Messungen mit dem SL-DRX-Zyklus abgestimmt werden kann, um sicherzustellen, dass das UE in der Lage ist, das Funkgerät auszuschalten, um die Funkleistung möglichst effizient zu erhalten.
  • Beispiel 29 kann das Verfahren von Beispiel 28 oder ein anderes Beispiel hierin beinhalten, wobei die Beschränkung auf jegliche periodische und ereignisgesteuerte Sidelink-Berichterstattung so definiert werden kann, dass sie nur innerhalb der EIN-Dauer des laufenden SL DRX-Zyklus durchgeführt werden kann
  • Beispiel 30 kann das Verfahren von Beispiel 28 oder ein anderes Beispiel hierin beinhalten, wobei das UE eine Modifikation der SL DRX-Zykluskonfiguration, einschließlich der DRX-Zykluslänge und anderer Parameter, anfordern kann, um sich besser an die QoS-Anforderungen des Peer-UE und/oder der Anwendung anzupassen.
  • Beispiel 31 kann ein Verfahren eines Benutzergeräts (UE) beinhalten, wobei das Verfahren Folgendes umfasst: Ermitteln einer diskontinuierlichen Empfangskonfiguration (DRX) für einen Sidelink-Kanal; und Kommunizieren auf dem Sidelink-Kanal basierend auf der DRX-Konfiguration.
  • Beispiel 32 kann das Verfahren von Beispiel 31 oder ein anderes Beispiel hierin beinhalten, wobei die Kommunikation auf dem Sidelink-Kanal basierend auf der DRX-Konfiguration die Überwachung für einen PDCCH beinhaltet.
  • Beispiel 33 kann das Verfahren aus Beispiel 31-32 oder ein anderes Beispiel hierin enthalten, wobei die DRX-Konfiguration einen DRX-Zyklus enthält.
  • Beispiel 34 kann das Verfahren von Beispiel 31-33 oder ein anderes Beispiel hierin umfassen, wobei die DRX-Konfiguration einen Einschaltdauer-Timer, einen Inaktivitäts-Timer und/oder einen Wiederübertragungs-Timer umfasst.
  • Beispiel 35 kann das Verfahren aus Beispiel 31-34 oder ein anderes Beispiel hierin beinhalten, wobei die DRX-Konfiguration für alle RRC-Verbindungszustände des UE gleich ist.
  • Beispiel 36 kann das Verfahren von Beispiel 31-34 oder ein anderes Beispiel hierin enthalten, wobei der DRX-Zustand auf der Grundlage eines RRC-Verbindungszustands des UE ermittelt wird.
  • Beispiel 37 kann das Verfahren von Beispiel 31-36 oder ein anderes Beispiel hierin enthalten, wobei, wenn sich das UE im RRC_CONNECTED-Zustand befindet, die DRX-Konfiguration auf der Grundlage von Konfigurationsinformationen bestimmt wird, die über dedizierte RRC-Signalisierung empfangen werden.
  • Beispiel 38 kann das Verfahren von Beispiel 31-37 oder ein anderes Beispiel hierin beinhalten, wobei, wenn sich das UE im Zustand RRC IDLE und/oder RRCINACTIVE befindet, die DRX-Konfiguration auf der Grundlage von Konfigurationsinformationen in einem Systeminformationsblock (SIB) ermittelt wird.
  • Beispiel 39 kann das Verfahren von Beispiel 31-38 oder ein anderes Beispiel hierin beinhalten, wobei, wenn das UE außerhalb der Abdeckung ist, die DRX-Konfiguration einer vorkonfigurierten DRX-Konfiguration entspricht.
  • Beispiel 40 kann das Verfahren von Beispiel 31-39 oder ein anderes Beispiel hierin umfassen, das ferner das Empfangen von Konfigurationsinformationen für einen langen DRX-Zyklus und einen kurzen DRX-Zyklus einschließt, wobei das Bestimmen der DRX-Konfiguration das Auswählen entweder des langen DRX-Zyklus oder des kurzen DRX-Zyklus einschließt.
  • Beispiel 41 kann das Verfahren von Beispiel 40 oder ein anderes Beispiel hierin umfassen, wobei der kurze DRX-Zyklus immer ausgewählt wird, wenn er konfiguriert ist.
  • Beispiel 42 kann das Verfahren von Beispiel 40 oder ein anderes Beispiel hierin umfassen, wobei der lange DRX-Zyklus oder der kurze DRX-Zyklus auf der Grundlage eines Diensttyps oder eines QoS-Profils des Sidelink-Verkehrs ausgewählt wird.
  • Beispiel 43 kann das Verfahren von Beispiel 40 oder 42 oder ein anderes Beispiel hierin umfassen, wobei der lange DRX-Zyklus und/oder der kurze DRX-Zyklus mit einem Satz von Diensttypen und/oder QoS-Profilen für Sidelink-Verkehr verbunden sind.
  • Beispiel 44 kann das Verfahren von Beispiel 31-43 oder ein anderes Beispiel hierin umfassen, das ferner das Ermitteln einer Sidelink-Messungs-Berichtskonfiguration einschließt, wobei Berichtsanlässe der Sidelink-Messungs-Berichtskonfiguration mit aktiven Perioden der DRX-Konfiguration ausgerichtet sind.
  • Beispiel 45 kann das Verfahren von Beispiel 44 oder ein anderes Beispiel hierin umfassen, wobei die Berichtsanlässe innerhalb einer Einschaltdauer der DRX-Konfiguration liegen.
  • Beispiel 46 kann das Verfahren aus Beispiel 44-45 oder ein anderes Beispiel hierin beinhalten, wobei die Berichtsanlässe periodische Anlässe und dynamisch ausgelöste Anlässe umfassen.
  • Beispiel 47 kann das Verfahren von Beispiel 31-46 oder ein anderes Beispiel hierin umfassen, das ferner die Codierung einer Anforderung zur Modifikation der DRX-Konfiguration beinhaltet.
  • Beispiel 48 kann das Verfahren von Beispiel 47 oder ein anderes Beispiel hierin beinhalten, wobei die Anforderung zur Modifikation auf einer DRX-Konfiguration eines anderen UE basiert.
  • Beispiel 49 kann das Verfahren aus Beispiel 47-48 oder ein anderes Beispiel hierin beinhalten, wobei die Änderungsanforderung auf einer oder mehreren QoS-Anforderungen basiert.
  • Beispiel 50 kann das Verfahren von Beispiel 47-49 oder ein anderes Beispiel hierin beinhalten, wobei die Anforderung einen oder mehrere angeforderte Parameter für die modifizierte DRX-Konfiguration enthält.
  • Beispiel 51 kann das Verfahren von Beispiel 50 oder ein anderes Beispiel hierin beinhalten, wobei der eine oder die mehreren angeforderten Parameter eine DRX-Zykluslänge beinhalten.
  • Beispiel 52 kann eine Vorrichtung mit Mitteln zur Durchführung eines oder mehrerer Elemente eines in einem der Beispiele 1-51 beschriebenen oder damit verbundenen Verfahrens oder eines anderen hierin beschriebenen Verfahrens oder Prozesses umfassen.
  • Beispiel 53 kann ein oder mehrere nicht-transitorische computerlesbare Medien umfassen, die Anweisungen enthalten, um eine elektronische Vorrichtung zu veranlassen, bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung ein oder mehrere Elemente eines Verfahrens durchzuführen, das in einem der Beispiele 1-51 beschrieben ist oder damit in Zusammenhang steht, oder ein beliebiges anderes hier beschriebenes Verfahren oder Prozess.
  • Beispiel 54 kann eine Vorrichtung umfassen, die Logik, Module oder Schaltungen enthält, um ein oder mehrere Elemente eines Verfahrens durchzuführen, das in einem der Beispiele 1-51 beschrieben ist oder damit in Zusammenhang steht, oder jedes andere hier beschriebene Verfahren oder Prozess.
  • Beispiel 55 kann ein Verfahren, eine Technik oder einen Prozess, wie in einem der Beispiele 1-51 beschrieben oder damit verwandt, oder Abschnitte oder Teile davon umfassen.
  • Beispiel 56 kann eine Vorrichtung umfassen, die Folgendes enthält: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen enthalten, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, das Verfahren, die Technik oder den Prozess, wie in einem der Beispiele 1-51 beschrieben oder damit verbunden, oder Teile davon durchzuführen.
  • Beispiel 57 kann ein Signal, wie in einem der Beispiele 1-51 beschrieben oder damit verbunden, oder Abschnitte oder Teile davon enthalten.
  • Beispiel 58 kann ein Datagramm, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht enthalten, wie in einem der Beispiele 1-51 beschrieben oder damit verbunden, oder Teile davon, oder anderweitig in der vorliegenden Offenbarung beschrieben.
  • Beispiel 59 kann ein Signal enthalten, das mit Daten kodiert ist, wie sie in den Beispielen 1-51 beschrieben sind oder sich auf diese beziehen, oder Teile davon, oder wie sie in der vorliegenden Offenbarung anderweitig beschrieben sind.
  • Beispiel 60 kann ein Signal enthalten, das mit einem Datagramm, einem Paket, einem Rahmen, einem Segment, einer Protokolldateneinheit (PDU) oder einer Nachricht kodiert ist, wie in den Beispielen 1-51 beschrieben oder damit verbunden, oder mit Abschnitten oder Teilen davon, oder anderweitig in der vorliegenden Offenbarung beschrieben.
  • Beispiel 61 kann ein elektromagnetisches Signal enthalten, das computerlesbare Anweisungen trägt, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren bewirkt, dass der eine oder die mehreren Prozessoren das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele 1-51 oder Teilen davon beschrieben oder damit verbunden, durchführen.
  • Beispiel 62 kann ein Computerprogramm mit Befehlen enthalten, wobei die Ausführung des Programms durch ein Verarbeitungselement das Verarbeitungselement veranlassen soll, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele 1-51 beschrieben oder damit verbunden, oder Teile davon auszuführen.
  • Beispiel 63 kann ein Signal in einem Drahtlos-Netzwerk enthalten, wie hier gezeigt und beschrieben.
  • Beispiel 64 kann ein Verfahren zur Kommunikation in einem Drahtlos-Netzwerk umfassen, wie hierin gezeigt und beschrieben.
  • Beispiel 65 kann ein System zur Bereitstellung von Drahtlos-Kommunikation umfassen, wie hierin gezeigt und beschrieben.
  • Beispiel 66 kann ein Gerät zur Bereitstellung von Drahtlos-Kommunikation umfassen, wie hier gezeigt und beschrieben.
  • Jedes der oben beschriebenen Beispiele kann mit jedem anderen Beispiel (oder jeder Kombination von Beispielen) kombiniert werden, sofern nicht ausdrücklich anders angegeben. Die vorstehende Beschreibung einer oder mehrerer Implementierungen dient der Veranschaulichung und Beschreibung, erhebt jedoch keinen Anspruch auf Vollständigkeit und beschränkt den Umfang dieser Offenbarung nicht auf die genaue offengelegte Form. Modifikationen und Variationen sind im Lichte der obigen Lehren möglich oder können aus der Praxis dieser Offenbarung erworben werden.
  • Sofern hier nicht anders verwendet, können Begriffe, Definitionen und Abkürzungen mit den in 3GPP TR 21.905 v16.0.0 (2019-06) definierten Begriffen, Definitionen und Abkürzungen übereinstimmen. Für die Zwecke des vorliegenden Dokuments können die folgenden Abkürzungen für die hier behandelte Offenbarung/Erfindung gelten.
  • Für die Zwecke des vorliegenden Dokuments gelten die folgenden Begriffe und Definitionen für die hier besprochenen Beispiele und Offenbarung/Erfindung.
  • Der Begriff „Schaltung“, wie er hier verwendet wird, bezieht sich auf Hardwarekomponenten wie eine elektronische Schaltung, eine Logikschaltung, einen Prozessor (gemeinsam, dediziert oder Gruppe) und/oder Speicher (gemeinsam, dediziert oder Gruppe), eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Bauelement (FPD) (z.B., ein feldprogrammierbares Gate-Array (FPGA), ein programmierbares Logikgerät (PLD), ein komplexes PLD (CPLD), ein Hochleistungs-PLD (HCPLD), ein strukturierter ASIC oder ein programmierbarer SoC), digitale Signalprozessoren (DSPs) usw., die so konfiguriert sind, dass sie die beschriebene Funktionalität bereitstellen. Die Schaltung kann ein oder mehrere Software- oder Firmware-Programme ausführen, um zumindest einige der beschriebenen Funktionen bereitzustellen. Der Begriff „Schaltung“ kann sich auch auf eine Kombination aus einem oder mehreren Hardwareelementen (oder einer Kombination von Schaltungen, die in einem elektrischen oder elektronischen System verwendet werden) mit dem Programmcode beziehen, der zur Ausführung der Funktionalität dieses Programmcodes verwendet wird. Die Kombination von Hardware-Elementen und Programmcode kann als eine bestimmte Art von Schaltung bezeichnet werden.
  • Der Begriff „Prozessorschaltung“, wie er hier verwendet wird, bezieht sich auf eine Schaltung, die in der Lage ist, sequentiell und automatisch eine Folge von arithmetischen oder logischen Operationen auszuführen oder digitale Daten aufzuzeichnen, zu speichern und/oder zu übertragen, oder ist Teil einer solchen Schaltung. Die Verarbeitungsschaltung kann einen oder mehrere Prozessorkerne zur Ausführung von Befehlen und eine oder mehrere Speicherstrukturen zur Speicherung von Programm- und Dateninformationen umfassen. Der Begriff „Verarbeitungsschaltung“ kann sich auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische Zentraleinheit (CPU), einen Single-Core-Prozessor, einen Dual-Core-Prozessor, einen Triple-Core-Prozessor, einen Quad-Core-Prozessor und/oder jede andere Vorrichtung beziehen, die in der Lage ist, computerausführbare Befehle, wie Programmcode, Softwaremodule und/oder funktionale Prozesse, auszuführen oder anderweitig zu betreiben. Die Verarbeitungsschaltung kann weitere Hardware-Beschleuniger umfassen, bei denen es sich um Mikroprozessoren, programmierbare Verarbeitungsgeräte oder Ähnliches handeln kann. Der eine oder die mehreren Hardware-Beschleuniger können beispielsweise Computer Vision (CV) und/oder Deep Learning (DL) Beschleuniger umfassen. Die Begriffe „Anwendungsschaltung“ und/oder „Basisbandschaltung“ können als Synonym für „Prozessorschaltung“ betrachtet und bezeichnet werden.
  • Der Begriff „Schnittstellenschaltung“, wie er hier verwendet wird, bezieht sich auf eine Schaltung, die den Austausch von Informationen zwischen zwei oder mehreren Komponenten oder Geräten ermöglicht, ist Teil davon oder umfasst eine solche. Der Begriff „Schnittstellenschaltung“ kann sich auf eine oder mehrere Hardwareschnittstellen beziehen, z.B. Busse, E/A-Schnittstellen, Schnittstellen für periphere Komponenten, Netzwerkschnittstellenkarten und/oder dergleichen.
  • Der Begriff „Benutzergerät“ oder „UE“, wie er hier verwendet wird, bezieht sich auf ein Gerät mit Funkkommunikationsfähigkeiten und kann einen entfernten Benutzer von Netzressourcen in einem Kommunikationsnetz beschreiben. Der Begriff „Benutzergerät“ oder „UE“ kann als Synonym für Client, Handy, mobiles Gerät, mobiles Endgerät, Benutzerendgerät, mobile Einheit, mobile Station, mobiler Benutzer, Teilnehmer, Benutzer, Gegenstelle, Zugangsagent, Benutzeragent, Empfänger, Funkgerät, rekonfigurierbares Funkgerät, rekonfigurierbares mobiles Gerät usw. betrachtet werden. Darüber hinaus kann der Begriff „Benutzergerät“ oder „UE“ jede Art von drahtlosem/verdrahtetem Gerät oder jedes Computergerät mit einer Schnittstelle für drahtlose Kommunikation umfassen.
  • Der Begriff „Netzwerkelement“, wie er hier verwendet wird, bezieht sich auf physische oder virtualisierte Ausrüstung und/oder Infrastruktur, die verwendet wird, um drahtgebundene oder Drahtlos-Kommunikationsnetzdienste bereitzustellen. Der Begriff „Netzwerkelement“ kann als Synonym für einen vernetzten Computer, Netzwerkhardware, Netzwerkausrüstung, Netzwerkknoten, Router, Switch, Hub, Bridge, Funknetzwerkcontroller, RAN-Gerät, RAN-Knoten, Gateway, Server, virtualisierte VNF, NFVI und/oder ähnliches betrachtet werden und/oder als solcher bezeichnet werden.
  • Der Begriff „Computersystem“, wie er hier verwendet wird, bezieht sich auf jede Art von miteinander verbundenen elektronischen Geräten, Computergeräten oder deren Komponenten. Außerdem kann sich der Begriff „Computersystem“ und/oder „System“ auf verschiedene Komponenten eines Computers beziehen, die kommunikativ miteinander verbunden sind. Darüber hinaus kann sich der Begriff „Computersystem“ und/oder „System“ auf mehrere Computergeräte und/oder mehrere Computersysteme beziehen, die kommunikativ miteinander verbunden und so konfiguriert sind, dass sie Computer- und/oder Netzwerkressourcen gemeinsam nutzen.
  • Der Begriff „Gerät“, „Computergerät“ oder ähnliches, wie er hier verwendet wird, bezieht sich auf ein Computergerät oder Computersystem mit Programmcode (z. B. Software oder Firmware), der speziell dafür ausgelegt ist, eine bestimmte Computerressource bereitzustellen. Ein „virtuelles Gerät“ ist ein Abbild einer virtuellen Maschine, das von einem mit einem Hypervisor ausgestatteten Gerät implementiert wird, das ein Computergerät virtualisiert oder emuliert oder anderweitig für die Bereitstellung einer bestimmten Computerressource bestimmt ist.
  • Der hier verwendete Begriff „Ressource“ bezieht sich auf ein physisches oder virtuelles Gerät, eine physische oder virtuelle Komponente innerhalb einer Computerumgebung und/oder eine physische oder virtuelle Komponente innerhalb eines bestimmten Geräts, wie z.B. Computergeräte, mechanische Geräte, Speicherplatz, Prozessor-/CPU-Zeit, Prozessor-/CPU-Nutzung, Prozessor- und Beschleunigerlasten, Hardware-Zeit oder -Nutzung, elektrische Leistung, Eingabe-/Ausgabeoperationen, Ports oder Netzwerkbuchsen, Kanal-/Link-Zuweisung, Durchsatz, Speichernutzung, Netzwerk, Datenbank und Anwendungen, Workload-Einheiten und/oder Ähnliches. Eine „Hardwareressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die von einem oder mehreren physischen Hardwareelementen bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die von einer Virtualisierungsinfrastruktur für eine Anwendung, ein Gerät, ein System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, auf die Computergeräte/-systeme über ein Kommunikationsnetz zugreifen können. Der Begriff „Systemressourcen“ kann sich auf jede Art von gemeinsam genutzten Einheiten zur Bereitstellung von Diensten beziehen und kann Computer- und/oder Netzwerkressourcen umfassen. Systemressourcen können als eine Reihe von kohärenten Funktionen, Netzwerkdatenobjekten oder Diensten betrachtet werden, auf die über einen Server zugegriffen werden kann, wobei sich solche Systemressourcen auf einem einzigen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind.
  • Der hier verwendete Begriff „Kanal“ bezieht sich auf ein materielles oder immaterielles Übertragungsmedium, das zur Übertragung von Daten oder eines Datenstroms verwendet wird. Der Begriff „Kanal“ kann synonym und/oder gleichbedeutend sein mit „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugangskanal“, „Datenzugangskanal“, „Verbindung“, „Datenverbindung“, „Träger“, „Hochfrequenzträger“ und/oder jedem anderen ähnlichen Begriff, der einen Pfad oder ein Medium bezeichnet, über den/das Daten übertragen werden. Darüber hinaus bezieht sich der Begriff „Link“, wie er hier verwendet wird, auf eine Verbindung zwischen zwei Geräten über ein RAT zum Zweck der Übertragung und des Empfangs von Informationen.
  • Die hier verwendeten Begriffe „instanziieren“, „Instanziierung“ und dergleichen beziehen sich auf die Erstellung einer Instanz. Eine „Instanz“ bezieht sich auch auf ein konkretes Auftreten eines Objekts, das z.B. während der Ausführung von Programmcode auftreten kann.
  • Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“ und deren Ableitungen werden hier verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander stehen, dass zwei oder mehr Elemente indirekt miteinander in Kontakt stehen, aber dennoch miteinander kooperieren oder interagieren, und/oder dass ein oder mehrere andere Elemente zwischen den Elementen, die miteinander gekoppelt sein sollen, gekoppelt oder verbunden sind. Der Begriff „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt zueinander stehen. Der Begriff „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente über ein Kommunikationsmittel miteinander in Kontakt stehen können, einschließlich über einen Draht oder eine andere Zwischenverbindung, über einen Drahtlos-Kommunikationskanal oder eine Drahtlos-Verbindung und/oder dergleichen.
  • Der Begriff „Informationselement“ bezieht sich auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff „Feld“ bezieht sich auf einzelne Inhalte eines Informationselements oder auf ein Datenelement, das Inhalte enthält.
  • Der Begriff „SMTC“ bezieht sich auf eine SSB-basierte Messzeitkonfiguration, die durch SSB-MeasurementTimingConfiguration konfiguriert wird.
  • Der Begriff „SSB“ bezieht sich auf einen SS/PBCH-Block.
  • Der Begriff „Primäre Zelle“ bezieht sich auf die MCG-Zelle, die auf der primären Frequenz betrieben wird und in der das UE entweder die anfängliche Verbindungsaufbauprozedur durchführt oder die Verbindungswiederaufbauprozedur einleitet.
  • Der Begriff „Primäre SCG-Zelle“ bezieht sich auf die SCG-Zelle, in der das UE einen wahlfreien Zugriff durchführt, wenn es die Rekonfigurationsprozedur mit Sync für den DC-Betrieb durchführt.
  • Der Begriff „Sekundäre Zelle“ bezieht sich auf eine Zelle, die zusätzliche Funkressourcen zusätzlich zu einer speziellen Zelle für ein mit CA konfiguriertes UE bereitstellt.
  • Der Begriff „Sekundärzellengruppe“ bezieht sich auf die Untergruppe der dienenden Zellen einschließlich der PSCell und null oder mehr Sekundärzellen für ein UE, das mit DC konfiguriert ist.
  • Der Begriff „Serving Cell“ bezieht sich auf die primäre Zelle für ein UE in RRC_CONNECTED, das nicht mit CA/DC konfiguriert ist, da es nur eine Serving Cell einschließlich der primären Zelle gibt.
  • Der Begriff „Serving Cell“ oder „Serving Cells“ bezieht sich auf den Satz von Zellen einschließlich der Spezialzelle(n) und aller sekundären Zellen für ein UE in RRC_CONNECTED mit CA/DC.
  • Der Begriff „Spezialzelle“ bezieht sich auf die PCell des MCG oder die PSCell des SCG für DC-Betrieb; ansonsten bezieht sich der Begriff „Spezialzelle“ auf die Pcell.
  • 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/053886 [0001]
    • US 63/094737 [0001]

Claims (10)

  1. Vorrichtung für ein New Radio (NR) User Equipment (UE) mit einer Radiofrequenz (RF)-Schnittstelle und einem oder mehreren Prozessoren, die mit der RF-Schnittstelle gekoppelt sind und eingerichtet sind zum: Erzeugen einer Sidelink (SL) Diskontinuierlicher Empfang (DRX) Informationsnachricht basierend auf einem SL DRX Zyklus des NR UE; Senden der SL-DRX-Informationsnachricht an eine Basisstation (BS); Empfangen einer Uu-DRX-Konfigurationsnachricht als Antwort auf die SL-DRX-Informationsnachricht von der BS, wobei die Uu-DRX-Konfigurationsnachricht Anweisungen zum Ausrichten eines Uu-DRX-Zyklus mit dem SL-DRX-Zyklus enthält; und Rekonfigurieren des Uu-DRX-Zyklus auf der Grundlage der Uu-DRX-Konfigurationsnachricht, wobei eine Mehrzahl von aktiven Dauern des SL-DRX-Zyklus mit einer Mehrzahl von aktiven Dauern des Uu-DRX-Zyklus ausgerichtet ist; optional ist die Vorrichtung ferner so konfiguriert, dass sie eine Uu DRX-Konfigurationsabschlussnachricht an die BS sendet.
  2. Die Vorrichtung nach Anspruch 1, ferner eingerichtet zum: Erkennen eines weiteren UE; Erzeugen einer Sidelink (SL) diskontinuierlichen Empfangs (DRX) Konfigurationsnachricht an das weitere UE, wobei die SL DRX Konfigurationsnachricht auf dem SL DRX Zyklus basiert; Senden der SL-DRX-Konfigurationsnachricht an das weitere UE; und Senden der SL DRX-Konfigurationsnachricht an das weitere UE; und Empfangen einer SL DRX-Konfigurationsabschlussnachricht von dem weiteren UE; wobei optional das NR UE und das weitere UE mit demselben SL DRX-Zyklus konfiguriert sind.
  3. Die Vorrichtung nach Anspruch 2, wobei die SL DRX-Konfigurationsnachricht eine SidelinkUEInformationNR ist, wie in Rel-16 definiert.
  4. Die Vorrichtung nach einem der Ansprüche 2 oder 3, wobei die SL DRX-Konfigurationsnachricht eine UEAssistanceInformation ist, wie in Rel-16 definiert.
  5. Die Vorrichtung nach einem der Ansprüche 1 bis 4, wobei eine Dauer des SL-DRX-Zyklus doppelt so lang ist wie eine Dauer des Uu-DRX-Zyklus; wobei optional jede zweite aktive Dauer der Vielzahl von aktiven Dauern des Uu-DRX-Zyklus mit jeder aktiven Dauer der Vielzahl von aktiven Dauern des SL-DRX-Zyklus übereinstimmt.
  6. Vorrichtung für ein New Radio (NR) User Equipment (UE), die eine Radiofrequenz-(RF)-Schnittstelle und einen oder mehrere Prozessoren umfasst, die mit der RF-Schnittstelle gekoppelt und eingerichtet sind zum: Ermitteln eines NR UE-Abdeckungszustands; Ermitteln eines Sidelink (SL) diskontinuierlichen Empfangs (DRX) Zyklus basierend auf dem NR UE Versorgungszustand; und Einrichten des NR UE so, dass es den ermittelten SL-DRX-Zyklus verwendet; wobei optional der NR UE-Abdeckungszustand einer der folgenden ist: ein verbundener Zustand, ein inaktiver oder ruhender Zustand oder ein Zustand außerhalb der Abdeckung.
  7. Die Vorrichtung nach Anspruch 6, wobei der SL-DRX-Zyklus ferner auf der Grundlage eines SL-Dienstqualitätsprofils (QoS) ermittelt wird.
  8. Die Vorrichtung nach einem der Ansprüche 6 oder 7, wobei der SL-DRX-Zyklus eine lange Dauer umfasst, die eine lange aktive Dauer und eine lange inaktive Dauer einschließt.
  9. Die Vorrichtung nach einem der Ansprüche 6 bis 8, ferner eingerichtet zum: Überwachen eines physikalischen Sidelink-Kontrollkanals (PSCCH) während einer aktiven Dauer des SL-DRX-Zyklus; Erzeugen einer Kanalzustandsinformation (CSI) basierend auf dem überwachten PSCCH; und Senden der CSI an eine Basisstation.
  10. Die Vorrichtung nach Anspruch 8, die ferner eingerichtet ist zum: Überwachen des PSCCH auf einen Verkehr; Ermitteln einer kurzen aktiven Dauer basierend auf dem Verkehr; und Modifizieren des SL DRX-Zyklus, um eine oder mehrere kurze aktive Dauern innerhalb der langen inaktiven Dauer einzuschließen.
DE102021118717.6A 2020-07-20 2021-07-20 Sidelink (sl) diskontinuierlicher empfang (drx) verfahren Pending DE102021118717A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202063053886P 2020-07-20 2020-07-20
US63/053,886 2020-07-20
US202063094737P 2020-10-21 2020-10-21
US63/094,737 2020-10-21

Publications (1)

Publication Number Publication Date
DE102021118717A1 true DE102021118717A1 (de) 2022-01-20

Family

ID=79021383

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021118717.6A Pending DE102021118717A1 (de) 2020-07-20 2021-07-20 Sidelink (sl) diskontinuierlicher empfang (drx) verfahren

Country Status (1)

Country Link
DE (1) DE102021118717A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220232665A1 (en) * 2021-01-14 2022-07-21 Lg Electronics Inc. Method and apparatus for operating a ue related to sidelink drx in a wireless communication system
US20230156853A1 (en) * 2021-11-15 2023-05-18 Qualcomm Incorporated Procedure and signaling for sidelink drx alignment

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220232665A1 (en) * 2021-01-14 2022-07-21 Lg Electronics Inc. Method and apparatus for operating a ue related to sidelink drx in a wireless communication system
US20230156853A1 (en) * 2021-11-15 2023-05-18 Qualcomm Incorporated Procedure and signaling for sidelink drx alignment

Similar Documents

Publication Publication Date Title
DE102020104357A1 (de) Sicherheitszertifikatverwaltung und Meldung von sich fehlverhaltenden Fahrzeugen in Fahrzeug-zu-Alles-Kommunikation (V2X-Kommunikation)
DE102021118717A1 (de) Sidelink (sl) diskontinuierlicher empfang (drx) verfahren
DE112020001628T5 (de) Benutzerausrüstung (ue) messfähigkeit in hochgeschwindigkeitsszenarien
DE102021108923A1 (de) Diskontinuierlicher empfangsbetrieb über nr sidelink
DE112018004135T5 (de) Framestruktur für unlizenziertes narrowband-internet-of-things-system
DE102021119772A1 (de) Vorrichtungen und verfahren zum austausch mehrerer kleiner datenübertragungen (sdt) im inaktiven zustand des benutzergeräts
DE102021109367A1 (de) Synchronisationssignal-multiplexing für drahtlos-systeme
DE102020119748A1 (de) Last verteilung-optimierung für selbstorganisierende netzwerke der fünften generation
DE102020120785A1 (de) Mechanismen zum betrieb von downlink-breitbandträgern im unlizensierten band
DE102021112311A1 (de) Unterstützung von bandbreitenbegrenzten benutzergeräten in neuer funk-systemen
DE102021120405A1 (de) Mechanismus für erweiterte leistungsmessfunktion (pmf) mit jittermessung und steering-modus-verfahren
DE102021113144A1 (de) Relais-(neu-)auswahl über sidelink in zellularen netzwerken
DE102021123163A1 (de) Mehrbenutzer-rts und cts-frames für eine subkanal-selektive sendestation
DE102021110736A1 (de) Netzwerkentität für ein mobiles Kommunikationssystem, Benutzergerät für ein mobiles Kommunikationssystem, Verfahren und Computerprogramm
DE102021113836A1 (de) Benutzergerät, Netzwerkeinheit, Verfahren und Computerprogramm für die Kommunikation zwischen Fahrzeugen und anderen Objekten auf der Nebenstrecke
DE102020110803A1 (de) Mobilfunk-kommunikationsschaltkreise und verfahren zum betreiben derselben
DE102020121330A1 (de) Handover-mechanismen in nicht-terrestrischen netzwerken
DE102021112480A1 (de) Verringerung der überwachung des physikalischen downlink-steuerungskanals für neuer funk-teilnehmergeräte
DE102021120547A1 (de) Mechanismen zur ermöglichung der dienstkontinuität für neuer-funk (nr) sidelink relaying
DE112017005578T5 (de) Bicasten von informationen zu einer teilnehmervorrichtung eines drahtlosen telekommunikationsnetzwerks
DE102021109966A1 (de) Verfahren zur übertragung im uplink mit der vollen leistung für vollkohärente benutzergeräte (ue) in neuer funk (nr)
DE102021112596A1 (de) Auslöschungsverbesserung für uplink-übertragungen mit slotaggregation
DE102021112466A1 (de) Unterstützung für erweiterte abdeckungsbeschränkung über die steuerebene (n2) schnittstelle
DE102021107953A1 (de) Slice-bewusste zellen-neuauswahl
DE102021103592A1 (de) Systeme, verfahren und geräte für sende- und empfangskanal (pdcch)