DE102021112377A1 - Benutzergeräte mit reduzierter Leistungsfähigkeit für Systeme der fünften Generation - Google Patents

Benutzergeräte mit reduzierter Leistungsfähigkeit für Systeme der fünften Generation Download PDF

Info

Publication number
DE102021112377A1
DE102021112377A1 DE102021112377.1A DE102021112377A DE102021112377A1 DE 102021112377 A1 DE102021112377 A1 DE 102021112377A1 DE 102021112377 A DE102021112377 A DE 102021112377A DE 102021112377 A1 DE102021112377 A1 DE 102021112377A1
Authority
DE
Germany
Prior art keywords
circuit
designed
rnti
pusch
pdsch
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
DE102021112377.1A
Other languages
English (en)
Inventor
Debdeep CHATTERJEE
Gang Xiong
Toufiqul Islam
Yingyang Li
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 DE102021112377A1 publication Critical patent/DE102021112377A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • H04L1/0003—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate by switching between different modulation schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0016—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy involving special memory structures, e.g. look-up tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK

Landscapes

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

Abstract

Ein Benutzergerät (UE) mit reduzierten Fähigkeiten für drahtlose Kommunikationssysteme der fünften Generation (5G) des Third Generation Partnership Project (3GPP). Das UE mit reduzierter Kapazität kann eine Schaltung enthalten, die so ausgebildet ist, dass sie Aufwärtsübertragungen (UL) sendet und Abwärtsübertragungen (DL) empfängt, wobei die Schaltung so ausgebildet ist, dass sie eine maximale Bandbreite von 20 MHz in DL bzw. UL in 5G-Frequenzbereich 1 (FR1) Bändern und eine maximale Bandbreite von 100 MHz in DL bzw. UL in 5G-Frequenzbereich 2 (FR2) Bändern unterstützt. Der Schaltkreis kann so ausgebildet sein, dass er die in der 3GPP 5G-Spezifikation definierten obligatorischen Anforderungen für ein UE auf einem niedrigeren Niveau unterstützt. Die Schaltung kann so ausgebildet sein, dass sie 64-Quadratur-Amplitudenmodulation (64QAM) als höchste Modulationsordnung sowohl für einen gemeinsam genutzten physikalischen Downlink-Kanal (PDSCH) als auch für einen gemeinsam genutzten physikalischen Uplink-Kanal (PUSCH) unterstützt.

Description

  • Gebiet
  • Die Beispiele beziehen sich auf ein Benutzergerät (UE), insbesondere ein UE mit reduzierten Fähigkeiten für drahtlose Kommunikationssysteme der fünften Generation (5G).
  • Hintergrund
  • Die 5G-Spezifikationen (auch als New Radio (NR) bezeichnet) können eine Vielzahl von Branchen und Anwendungsfällen unterstützen, darunter erweitertes mobiles Breitband (eMBB), ultrazuverlässige Kommunikationsdienste mit geringer Latenz (URLLC) und Ähnliches. Die Unterstützung von Low-Power-Wide-Area-Netzen (LPWA) und Anwendungsfälle für Geräte mit extrem geringer Komplexität und geringen Kosten, die auf eine extreme Reichweite und eine extrem lange Batterielebensdauer abzielen, werden voraussichtlich durch Technologien für die maschinelle Kommunikation (MTC) (Kategorie M UEs) und das Schmalband-Internet der Dinge (NB-IoT) (Kategorie NB UEs) unterstützt.
  • Figurenliste
  • Nachfolgend werden einige Beispiele von Vorrichtungen und/oder Verfahren ausschließlich beispielhaft und Bezug nehmend auf die beiliegenden Figuren beschrieben, in denen gilt:
    • 1 ist ein Diagramm eines beispielhaften RedCap-UE für drahtlose 3GPP-5G-Kommunikationssysteme gemäß einem Beispiel;
    • 2 und 3 veranschaulichen verschiedene Systeme, Geräte und Komponenten, die Aspekte der offengelegten Beispiele umsetzen können; und
    • 4 ist ein Blockdiagramm, das Komponenten gemäß einigen Ausführungsbeispielen zeigt, die in der Lage sind, Anweisungen von einem maschinenlesbaren oder computerlesbaren Medium zu lesen und eine oder mehrere der hier beschriebenen Methoden durchzuführen.
  • Detaillierte Beschreibung
  • Verschiedene Beispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Zeichnungen beschrieben, in denen einige Beispiele dargestellt sind. In den Figuren können die Stärken von Linien, Schichten und/oder Regionen der Klarheit halber übertrieben dargestellt sein.
  • Entsprechend sind, obgleich weitere Beispiele zu verschiedenen Modifikationen und alternativen Formen in der Lage sind, manche bestimmten Beispiele davon in den Figuren gezeigt und werden anschließend ausführlich beschrieben. Allerdings beschränkt diese detaillierte Beschreibung weitere Beispiele nicht auf die beschriebenen bestimmten Formen. Weitere Beispiele können alle Modifikationen, Entsprechungen und Alternativen abdecken, die in den Schutzbereich der Offenbarung fallen. Gleiche Bezugszeichen beziehen sich in der gesamten Beschreibung der Figuren auf gleiche oder ähnliche Elemente, die bei einem Vergleich miteinander identisch oder in modifizierter Form implementiert sein können, während sie die gleiche oder eine ähnliche Funktionalität bereitstellen.
  • Es versteht sich, dass, wenn ein Element als mit einem anderen Element „verbunden“ oder „gekoppelt“ bezeichnet wird, die Elemente direkt, oder über ein oder mehrere Zwischenelemente, verbunden oder gekoppelt sein können. Wenn zwei Elemente A und B unter Verwendung eines „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart sind, d. h. nur A, nur B sowie A und B. Eine alternative Formulierung für die gleichen Kombinationen ist „zumindest eines von A und B“. Das Gleiche gilt für Kombinationen von mehr als 2 Elementen.
  • Die Terminologie, die hierin zum Beschreiben bestimmter Beispiele verwendet wird, soll nicht begrenzend für weitere Beispiele sein. Wenn eine Singularform, z. B. „ein, eine“ und „der, die, das“ verwendet wird und die Verwendung nur eines einzelnen Elements weder explizit noch implizit als verpflichtend definiert ist, können weitere Beispiele auch Pluralelemente verwenden, um die gleiche Funktion zu implementieren. Ähnlich, wenn eine Funktionalität nachfolgend als unter Verwendung mehrerer Elemente implementiert beschrieben ist, können weitere Beispiele die gleiche Funktionalität unter Verwendung eines einzelnen Elements oder einer einzelnen Verarbeitungsentität implementieren. Es versteht sich weiterhin, dass die Begriffe „umfasst“, „umfassend“, „aufweist“ und/oder „aufweisend“ bei Gebrauch das Vorhandensein der angegebenen Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Handlungen, Elemente und/oder Komponenten präzisieren, aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Handlungen, Elemente, Komponenten und/oder einer Gruppe derselben ausschließen.
  • Sofern nicht anderweitig definiert, werden alle Begriffe (einschließlich technischer und wissenschaftlicher Begriffe) hierin in ihrer üblichen Bedeutung des Gebiets verwendet, zu dem die Beispiele gehören.
  • Es wurde festgestellt, dass es vorteilhaft wäre, eine Klasse von NR-UEs mit geringerer Komplexität und geringerem Stromverbrauch im Vergleich zu den herkömmlichen NR-UEs (z. B. NR-UEs der Version 15 (Rel-15)) zu unterstützen, die für Anwendungsfälle wie industrielle drahtlose Sensornetzwerke (IWSN), bestimmte Klassen von Wearables, Videoüberwachung oder Ähnliches geeignet sind. Die Unterstützung dieser Anwendungsfälle kann wünschenswert sein, um die Lücke zwischen den herkömmlichen LPWA-Lösungen und den eMBB-Lösungen in NR zu schließen. Sie kann erforderlich sein, um einen reibungslosen Übergang von den Technologien der 3,5-Generation (3,5G) und der vierten Generation (4G) zur 5G-Technologie (NR) für die derzeit genutzten Frequenzbänder zu ermöglichen, die für die jeweiligen Anwendungsfälle relativ niedrige bis mittlere Referenz- (z. B. Median) und Spitzendurchsätze, eine geringe Gerätekomplexität, kleine Geräteformfaktoren und eine relativ lange Batterielebensdauer erfordern.
  • Um diese Ziele zu erreichen, kann eine Klasse von NR-UEs mit reduzierter Kapazität (RedCap) definiert werden, die mit dem derzeit spezifizierten 5G NR-Framework mit den notwendigen Anpassungen und Verbesserungen bedient werden können, um die Gerätekomplexität und den Stromverbrauch zu begrenzen und gleichzeitig die negativen Auswirkungen auf die Netzressourcennutzung, die spektrale Effizienz des Systems und die Betriebseffizienz zu minimieren. In Anbetracht der angestrebten Anwendungsfälle und Designziele bei der Definition der RedCap NR UEs können Vereinfachungen der Verfahren der physikalischen Schicht im Vergleich zu den Rel-15 NR-Spezifikationen sinnvolle Möglichkeiten zur Reduzierung der UE-Komplexität und der Kosten bieten.
  • 1 ist ein Diagramm eines beispielhaften RedCap UE 100 für 3GPP-5G-Mobilfunksysteme gemäß einem Beispiel. Das UE 100 ist so ausgebildet, dass es die im Folgenden offengelegten technischen Schemata und Verfahren implementieren kann. Das UE 100 umfasst Schaltkreise 110, die so ausgebildet sind, dass sie Aufwärtsübertragungen (UL; Uplink) senden und Abwärtsübertragungen (DL; Downlink) empfangen. Das UE 100 kann mit einer maximalen Bandbreitenanforderung für jeden 5G-Frequenzbereich ausgebildet sein. Die Trägerfrequenzbänder für 5G NR sind in zwei verschiedene Frequenzbereiche aufgeteilt, Frequenzbereich 1 (FR1) (unter 7,125 GHz) und Frequenzbereich 2 (FR2) (Millimeterwelle). Die Schaltung 110 kann so ausgebildet sein, dass sie eine maximale Bandbreite von 20 MHz in DL bzw. UL in 5G-Frequenzbereich 1 (FR1) Bändern und eine maximale Bandbreite von 100 MHz in DL bzw. UL in 5G-Frequenzbereich 2 (FR2) Bändern unterstützt.
  • NR-UEs (im Folgenden als „Nicht-RedCap-UEs“ bezeichnet) müssen die verbindlichen Anforderungen der 3GPP-NR-Spezifikationen (z. B. Rel-15-Spezifikation oder spätere Versionen der 3GPP-NR-Spezifikation) erfüllen. Die Schaltung 110 des RedCap-UE 100 kann so ausgebildet sein, dass sie die in der 3GPP 5G-Spezifikation definierten obligatorischen Anforderungen für Nicht-RedCap-UEs auf einem abgesenkten/reduzierten Niveau unterstützt. Die Schaltung kann so ausgebildet sein, dass sie die in der 5G-Spezifikation von 3GPP Release 15 oder Release 16 definierten obligatorischen Anforderungen für ein UE unterstützt, wobei eine oder mehrere der obligatorischen Anforderungen gelockert werden können. Wie oben beschrieben, kann die Schaltung beispielsweise so ausgebildet sein, dass sie für jeden 5G-Frequenzbereich eine geringere maximale Bandbreite in DL und UL unterstützt. Als weiteres Beispiel kann die Schaltung 110 so ausgebildet sein, dass sie 64-Quadratur-Amplitudenmodulation (64QAM) als höchste Modulationsordnung sowohl für einen gemeinsam genutzten physikalischen Downlink-Kanal (PDSCH) als auch für einen gemeinsam genutzten physikalischen Uplink-Kanal (PUSCH) unterstützt. Die Schaltung 110 kann so ausgebildet sein, dass sie eine 64-QAM-Modulations- und Kodierungsschema (MCS)-Tabelle mit niedriger spektraler Effizienz (SE) unterstützt, die in Tabelle 5.1.3.1-3 in 3GPP TS 38.214 für den PDSCH und den PUSCH bei Verwendung der CP-OFDM-Wellenform (cyclic prefix-orthogonal frequency division multiplex) bzw. in Tabelle 6.1.4.1-2 in 3GPP TS 38.214 für den PUSCH bei Verwendung von DFT-S-OFDM (discrete Fourier transform-spread-orthogonal frequency division multiplex) definiert ist. Die Schaltung 110 kann so ausgebildet sein, dass sie die in Tabelle 5.1.3.1-3 in 3GPP TS 38.214 und Tabelle 6.1.4.1-2 in 3GPP TS 38.214 definierte Low-SE-64-QAM-MCS-Tabelle als obligatorische Anforderung unterstützt.
  • Die Nicht-RedCap-UEs müssen sowohl eine CP-OFDM-Wellenform (Cyclic Prefix Orthogonal Frequency Division Multiplex) als auch eine DFT-S-OFDM-Wellenform (Discrete Fourier Transform-Spread Orthogonal Frequency Division Multiplex) unterstützen. Der Schaltkreis 110 kann so ausgebildet sein, dass er nur die DFT-S-OFDM-Wellenform für PUSCH-Übertragungen (Physical Uplink Shared Channel) unterstützt.
  • Der Trägerbandbreitenteil (BWP) ist ein zusammenhängender Satz physikalischer Ressourcenblöcke, der aus einer zusammenhängenden Teilmenge der gemeinsamen Ressourcenblöcke für eine bestimmte Numerologie auf einem bestimmten Träger ausgewählt wird. UEs können mit bis zu vier Träger-BWPs für UL und DL für jede Serving Cell ausgebildet werden. UEs können den BWP auf der Grundlage von Steuersignalen aus dem Netz dynamisch wechseln. BWP-basierte Operationen können dem Netzplaner Flexibilität bei der Bereitstellung von Verkehr innerhalb und zwischen UEs mit unterschiedlichen Anforderungen bieten.
  • Die Schaltung 110 kann so ausgebildet sein, dass sie nur die auf der Funkressourcensteuerung (RRC) basierende Anpassung des Bandbreitenteils (BWP) unterstützt und nicht erforderlich ist, um die auf der Kontrollsignalisierung der Schicht 1 oder 2 basierende Anpassung zu unterstützen. Die Schaltung 110 kann so ausgebildet sein, dass sie maximal einen UE-spezifisch ausgebildeten DL- oder UL-BWP zusätzlich zu einem anfänglichen DL- oder UL-BWP unterstützt. Das UE 100 kann von einer höheren Schicht (Schicht 3 oder höher) mit mehr als einem DL- oder UL-BWP ausgebildet sein, und die Schaltung 110 kann so ausgebildet sein, dass sie einen gemeinsamen Satz von Werten für alle Parameter, die als Teil der BWP-Konfigurationen ausgebildet sind, auf alle oder eine Teilmenge der ausgebildeten DL- oder UL-BWPs anwendet, mit Ausnahme von Werten für eine Mittenfrequenz und Bandbreite, BWP-Identität und Unterträgerabstand der ausgebildeten BWPs.
  • Wenn sich das UE 100 in den Modi RRC Connected, RRC Idle oder RRC Inactive befindet, kann die Schaltung 110 so ausgebildet sein, dass sie immer nur einen PDSCH decodiert. Die Schaltung 110 kann so ausgebildet sein, dass sie ein erstes PDSCH, das in einer bedienenden Zelle mit temporärer Zell-Funknetz-Identität (C-RNTI) oder temporärer Modulations- und Kodierungsschema-Zell-Funknetz-Identität (MCS-C-RNTI) geplant ist, und ein zweites PDSCH, das in der bedienenden Zelle mit konfigurierter temporärer Zeitplan-Funknetz-Identität (CS-RNTI) geplant ist, nicht dekodiert, wenn sich das erste und das zweite PDSCH zeitlich teilweise oder vollständig überlappen.
  • Die Schaltung 110 kann so ausgebildet sein, dass sie keine Aufwärtsstreckengewährung in einem Downlink-Kontrollinformationsformat (DCI) empfängt, das das UE 100 anweist, ein dynamisch gewährtes (DG) PUSCH zu übertragen, das sich zeitlich mit einem anderen PUSCH überschneidet, das dynamisch oder von einer höheren Schicht als Teil eines Typ 1 oder Typ 2 Configured Grant PUSCH gewährt wird.
  • Zwei PDSCH- und PUSCH-Zuordnungstypen (Typ A und Typ B) sind in Rel-15 NR definiert, und beide müssen von Nicht-RedCap-UEs zwingend unterstützt werden. Die Schaltung 110 des RedCap UE 100 kann so ausgebildet sein, dass sie nur PUSCH-Mapping Typ A unterstützt. Der Schaltkreis 110 kann so ausgebildet sein, dass er nur einen PDSCH-Empfang oder eine PUSCH-Übertragung in einem Slot unterstützt.
  • Ein Mechanismus zur Leistungsregelung im geschlossenen Regelkreis (CLPC) ist implementiert, um die Sendeleistung eines UE zu erhöhen oder zu verringern. Befehle zur Sendeleistungsregelung (TPC) werden über die Downlink-Kontrollinformationen (DCI) an die Endgeräte gesendet. Rel-15 NR-Spezifikationen schreiben vor, dass ein UE mindestens zwei CLPC-Schleifen für PUSCH- und PUCCH-Übertragungen unterstützen muss. Die Schaltung 110 des RedCap UE 100 kann so ausgebildet sein, dass sie eine CLPC-Schleife für die Leistungssteuerung in der Aufwärtsrichtung für einen PUSCH bzw. einen PUCCH unterstützt. In einem anderen Beispiel kann die Schaltung 110 so ausgebildet sein, dass sie eine CLPC-Schleife für die Uplink-Leistungssteuerung für PUSCH bzw. PUCCH in FR1-Bändern und mindestens zwei CLPC-Schleifen für die Uplink-Leistungssteuerung für PUSCH bzw. PUCCH in FR2-Bändern unterstützt.
  • Die Schaltung 110 kann so ausgebildet sein, dass sie einen PDSCH dekodiert, der durch einen PDCCH mit zyklischer Redundanzprüfung (CRC) geplant ist, der durch eine temporäre Systeminformations-Funknetzkennung (SI-RNTI) und einen auf 1 gesetzten Systeminformationsindikator in DCI verwürfelt ist, Radom Access-Radio Network Temporary Identifier (RA-RNTI), MsgB-RNTI, Paging-RNTI (P-RNTI), Temporary Cell RNTI (TC-RNTI), Cell-RNTI (C-RNTI), Modulation and coding scheme-cell-RNTI (MCS-C-RNTI), konfigurierte Scheduling-RNTI (CS-RNTI) oder PDSCHs mit semi-persistentem Scheduling (SPS), und die sich mit einer oder mehreren von Synchronisationssignal/Physical Broadcast Channel (SS/PBCH)-Blockübertragungsressourcen, semistatisch konfigurierten Ressourcensätzen, dynamisch angezeigten Ressourcensätzen, konfigurierten PDCCH-Kontrollressourcensätzen (CORESETs) oder Scheduling-PDCCH überlappen, indem angenommen wird, dass der PDSCH den überlappenden Ressourcen zugeordnet, aber nicht übertragen wird.
  • Der Schaltkreis 110 kann so ausgebildet sein, dass er maximal ein oder zwei halbstatisch ausgebildete, ratenangepasste Ressourcensätze mit einer Granularität auf der Ebene eines Ressourcenblocks (RB) und nicht mehr als zwei halbstatisch ausgebildete, ratenangepasste Ressourcensätze mit einer Granularität auf der Ebene eines Ressourcenelements (RE) unterstützt.
  • 5G NR unterstützt fünf PUCCH-Formate: 2 kurze PUCCH-Formate (Formate 0 und 2) und 3 lange PUCCH-Formate (Formate 1, 3 und 4). Die Schaltung 110 kann so ausgebildet sein, dass sie nur die PUCCH-Formate 0, 1 und 4 unterstützt. Die Schaltung 110 kann so ausgebildet sein, dass sie zwei PUCCH-Übertragungen, einschließlich des kurzen PUCCH-Formats und des langen PUCCH-Formats, oder zwei kurze PUCCH-Formate im Zeitmultiplexverfahren (TDM) multiplext. Die Schaltung 110 kann so ausgebildet sein, dass sie maximal einen PUCCH in einem Slot überträgt.
  • Im Folgenden werden Beispiele für Verfahren zur Verbesserung verschiedener Verfahren der physikalischen Schicht, einschließlich Verfahren und Anforderungen im Zusammenhang mit Scheduling und hybrider automatischer Wiederholungsanforderung (HARQ), die für RedCap NR UEs geeignet sind, sowie für Geräte, die für die Implementierung dieser Verfahren ausgebildet sind, im Detail offengelegt. Insbesondere beziehen sich die hier offengelegten Beispiele auf die unterstützte Modulationsreihenfolge und die Verwendung von Modulations- und Codierungsschemata (MCS) für RedCap NR UEs, UL-Wellenform-Anforderungen für RedCap NR UEs, BWP-Betrieb für RedCap NR UEs und verschiedene Scheduling- und HARQ-Verfahren für RedCap NR UEs.
  • RedCap NR UEs können als UE definiert werden, das die in der 3GPP NR-Spezifikation (z. B. 3GPP Rel-15-Spezifikation oder nachfolgende Releases) für UEs festgelegten obligatorischen Anforderungen auf einem reduzierten/verringerten Niveau unterstützt. Im Vergleich zu Nicht-RedCap-UEs können RedCap NR-UEs so definiert werden, dass sie eine reduzierte Bandbreite (BW) und/oder eine reduzierte Anzahl von Empfängerzweigen (Rx) für einen bestimmten Frequenzbereich (z. B. Frequenzbereich 1 (FR1) oder Frequenzbereich 2 (FR2)) und/oder Frequenzbänder in einem Frequenzbereich unterstützen. Konkret kann ein RedCap NR UE so definiert werden, dass er eine maximale UE BW in DL und UL von 20 MHz in FR1-Bändern unterstützt, verglichen mit 100 MHz, die für Nicht-RedCap UEs erforderlich sind, und eine maximale UE BW in DL und UL von 100 MHz in FR2-Bändern, verglichen mit 400 MHz, die für Nicht-RedCap UEs erforderlich sind.
  • Zusätzlich oder alternativ kann ein RedCap NR UE in Bezug auf eine Mindestanforderung an die Anzahl der Rx-Zweige definiert werden. Ein RedCap NR US muss möglicherweise mindestens einen Rx-Zweig in den Bändern FR1 und FR2 haben, während für Nicht-RedCap-UEs mindestens 2 Rx-Zweige und 4 Rx-Zweige für FR1 bzw. FR2 erforderlich sind.
  • Die für RedCap NR UEs in Frage kommenden Anwendungsfälle sind industrielle drahtlose Sensoren, Videoüberwachung, Wearables oder Ähnliches. Die Anforderungen an industrielle drahtlose Sensoren können eine Verfügbarkeit des Kommunikationsdienstes von 99,99 % und eine End-to-End-Latenzzeit von weniger als 100 ms umfassen. Die Referenzbitrate beträgt weniger als 2 Mbit/s (potenziell asymmetrisch, z. B. bei starkem UL-Verkehr) für alle Anwendungsfälle, und das Gerät ist stationär. Die Batterie muss unter Umständen lange halten, z. B. mindestens einige Jahre. Bei sicherheitsrelevanten Sensoren kann die geforderte Latenzzeit geringer sein, nämlich 5-10 ms.
  • Zu den Anforderungen an die Videoüberwachung gehören eine wirtschaftliche Referenz-Videobitrate von 2 bis 4 Mbit/s, eine Latenzzeit von weniger als 500 ms und eine Zuverlässigkeit von 99 % bis 99,9 %. Für High-End-Videos, z. B. in der Landwirtschaft, wären 7,5-25 Mbit/s erforderlich. In diesem Anwendungsfall wird das Verkehrsmuster von UL-Übertragungen dominiert.
  • Im Anwendungsfall von Wearables kann die Referenzbitrate für intelligente Wearable-Anwendungen 10-50 Mbit/s im Downlink (DL) und mindestens 5 Mbit/s im UL betragen, wobei die Spitzenbitrate des Geräts höher ist, nämlich 150 Mbit/s im Downlink und 50 Mbit/s im Uplink. Die Batterie des Geräts sollte z. B. mehrere Tage halten (bis zu 1-2 Wochen).
  • Aus den oben aufgeführten technischen Anforderungen geht hervor, dass ein hoher Durchsatz für diese Anwendungsfälle nicht erforderlich ist. Lockerungen anderer Anforderungen (z. B. geringe Anzahl von Empfangs- und Sendeantennen, möglicherweise geringe Antennenverstärkungen aufgrund eines kleinen Formfaktors, reduzierte Verarbeitungsmöglichkeiten usw.) können den Betrieb solcher Endgeräte mit sehr hoher spektraler Effizienz (SE) weiter einschränken. Die Einschränkung der Unterstützung von Modulationen höherer Ordnung sowohl im DL als auch im UL kann also dazu beitragen, die Anforderungen an die Funkfrequenz (RF) und das Basisband (BB) für die UE-Implementierung zu verringern, ohne die Referenz- oder Spitzendatenratenziele für die relevanten Anwendungsfälle zu beeinträchtigen.
  • In einem Beispiel muss ein RedCap NR UE nur die höchste Modulationsordnung von 64-QAM für den gemeinsam genutzten physikalischen Downlink-Kanal (PDSCH) unterstützen. Die in Tabelle 5.1.3.1-1 in 3GPP TS 38.214 definierte Standardtabelle für das 64-QAM-Modulations- und Kodierungsschema (MCS) kann von RedCap NR-UEs als obligatorisches Merkmal unterstützt werden. Ein RedCap NR UE muss die in Tabelle 5.1.3.1-2 in 3GPP TS 38.214 definierte MCS-Tabelle möglicherweise nicht unterstützen.
  • RedCap NR UEs können mit relativ niedrigen effektiven Coderaten geplant werden. Darüber hinaus macht es die erwartete Verschlechterung der Leistung auf Verbindungsebene aufgrund der reduzierten Fähigkeiten zwingend erforderlich, das erforderliche Signal-Störungs-Rausch-Verhältnis (SINR) so weit wie möglich zu reduzieren, um eine gute Versorgungsleistung von RedCap NR UEs zu gewährleisten. In diesem Zusammenhang kann ein RedCap NR UE beispielsweise die 64-QAM-MCS-Tabelle mit niedriger spektraler Effizienz (SE) unterstützen, die in Tabelle 5.1.3.1-3 in 3GPP TS 38.214 definiert ist (entweder als obligatorische oder optionale Anforderung), zusätzlich zur Standard-64-QAM-MCS-Tabelle (d. h. Tabelle 5.1.3.1-1 in 3GPP TS 38.214).
  • In einer anderen Ausführungsform kann ein RedCap NR UE eine modifizierte Version der in Tabelle 5.1.3.1-1 von 3GPP TS 38.214 definierten Standard-64-QAM-MCS-Tabelle unterstützen. In diesem Beispiel wird die standardmäßige 64-QAM-MCS-Tabelle geändert, um die MCS-Indizes 29, 30 und 31 umzufunktionieren, um niedrige SE-Werte mit Quadraturphasenumtastung (QPSK) anzuzeigen, die kleiner als 0,2344 sind. Daher kann ein RedCap NR UE im RRC-Verbindungsmodus von höheren Schichten so ausgebildet sein, dass er die geänderte Standard-64-QAM-MCS-Tabelle für die PDSCH-Planung verwendet. Diese Änderung impliziert, dass die implizite Bestimmung der Coderate für den Fall einer erneuten Übertragung unter Verwendung der MCS-Indizes 29, 30 und 31 mit der geänderten Standard-64-QAM-MCS-Tabelle möglicherweise nicht möglich ist. Bei RedCap NR UEs für die oben diskutierten Zielanwendungsfälle ist die Notwendigkeit einer variierenden Ressourcenzuweisung für erneute Übertragungen jedoch möglicherweise begrenzt, so dass eine explizite Angabe der Coderate (ähnlich den MCS-Indizes 0 bis 28) ausreichen kann. Für einen gemeinsam genutzten physikalischen Uplink-Kanal (PUSCH) können in einem Beispiel die MCS-Indizes 28, 29, 30 und 31 in Tabelle 6.1.4.1-1 von 3GPP TS 38.214 umfunktioniert werden, um niedrige SE-Werte mit einer oder beiden QPSK- oder pi/2-binären Phasenumtastungen (pi/2-BPSK) anzuzeigen (falls konfiguriert, z. B. über den Parameter tp-pi2BPSK der höheren Schicht).
  • Alle oben genannten Beispiele können auch auf ein PUSCH angewendet werden, mit den entsprechenden MCS-Tabellen für die Standard-64-QAM- und Low-SE-64-QAM-Tabellen, die in den Tabellen 5.1.3.1-1 und 5.1.3.1-3 in 3GPP TS 38.214, wenn ein PUSCH mit der CP-OFDM-Wellenform (Cyclic Prefix-Orthogonal Frequency Division Multiplex) geplant ist (wenn CP-OFDM vom RedCap NR UE unterstützt wird), und mit den entsprechenden MCS-Tabellen für die Standard-64-QAM- und Low-SE-64-QAM-Tabellen, die in den Tabellen 6.1.4.1-1 bzw. 6.1.4.1-2 in 3GPP TS 38.214 definierten MCS-Tabellen, wenn ein PUSCH mit OFDM-Wellenform mit Transformationsvorcodierung (auch als diskrete Fourier-Transformations-Spreizung-Orthogonal-Frequenzmultiplex-Wellenform (DFT-S-OFDM) bezeichnet) geplant ist.
  • In einem weiteren Beispiel kann von einem RedCap NR UE verlangt werden, dass es die Low-SE-MCS-Tabellen für PDSCH zwingend unterstützt, die Unterstützung der Low-SE-MCS-Tabelle für UL-Übertragungen kann jedoch optional sein. In einem anderen Beispiel kann die obligatorische Unterstützung der MCS-Tabelle mit niedrigem SE für PDSCH bedingt erforderlich sein, wenn das UE nur einen Empfangszweig (Rx) unterstützt, was dem Netz über die Angabe der Fähigkeit der maximalen DL-MIMO-Schicht (Multiple-Input Multiple-Output) angezeigt werden kann.
  • Wenn die Unterstützung von Low-SE-MCS-Tabellen für RedCap-NR-UEs vorgeschrieben ist, können die Low-SE-MCS-Tabellen auch für die Planung von PDSCH mit Paging-Informationen (d. h. PDSCH, das von einem PDCCH in einem gemeinsamen Suchraum (CSS) des Typs 2-PDCCH geplant wird) oder für die Planung von PDSCH mit wahlfreiem Zugriff (d. h. PDSCH mit Antwort auf wahlfreien Zugriff (RAR) oder Nachricht 4 (Msg4), das von einem PDCCH in einem CSS des Typs 1-PDCCH geplant wird) verwendet werden. So kann z. B. ein RedCap NR UE über die Systeminformationsblock (SIB)-Signalisierungskonfiguration, z. B. in pdsch-ConfigCommon, darüber informiert werden, ob die Standard-64-QAM-MCS-Tabelle oder die Low-SE-MCS-Tabelle für PDSCH verwendet werden soll. In einem anderen Beispiel kann ein RedCap NR UE über die Systeminformationsblock (SIB)-Signalisierungskonfiguration, z. B. in pusch-ConfigCommon für RedCap NR UEs, darüber informiert werden, ob die standardmäßige 64-QAM-MCS-Tabelle oder die Low-SE-MCS-Tabelle für PUSCH mit Nachricht 3 (Msg3) verwendet werden soll. Alternativ kann die Verwendung der Low-SE-MCS-Tabelle für PDSCH vor dem RRC-Verbindungsaufbau für RedCap-NR-UEs über SIB-Signalisierung aktiviert werden, und dann kann die tatsächliche Auswahl zwischen der Standard-64-QAM- und der Low-SE-MCS-Tabelle dynamisch über ein reserviertes Bit im DCI-Format 0_0 angezeigt werden, das zur Planung des PDSCH mit Random Access Response (RAR) oder Msg4 oder eines PDSCH mit einem Paging-Datensatz verwendet wird.
  • Rel-15 NR-Spezifikationen schreiben die Unterstützung sowohl von CP-OFDM als auch von DFT-S-OFDM-Wellenformen für PUSCH-Übertragungen vor. Die Beschränkung auf die DFT-S-OFDM-Wellenform kann dazu beitragen, die Anforderungen an die Komplexität des UE zu reduzieren, die durch die Unterstützung von zwei Wellenformen in der UL entstehen. Die Wahl von DFT-S-OFDM ist durch die zu erwartende Verschlechterung der Abdeckung und der Link-Performance für RedCap NR UEs begründet.
  • In einem Beispiel kann von einem RedCap NR UE verlangt werden, dass es nur eine DFT-S-OFDM-Wellenform für PUSCH-Übertragungen unterstützt. So erwartet ein RedCap NR UE zum Beispiel nicht, dass es über die System Information Block-Type 1 (SIB-1) Signalisierung (auch Remaining Minimum System Information (RMSI) genannt) mit CP-OFDM als Standard UL Wellenform konfiguriert wird.
  • Träger-BWP ist ein zusammenhängender Satz physikalischer Ressourcenblöcke, der aus einer zusammenhängenden Teilmenge der gemeinsamen Ressourcenblöcke für eine bestimmte Numerologie auf einem bestimmten Träger ausgewählt wird. Ein UE kann mit bis zu vier Träger-BWPs für UL und DL für jede bedienende Zelle ausgebildet werden. BWP-basierte Operationen können dem Netzplaner Flexibilität bei der Bereitstellung von Verkehr innerhalb und zwischen UEs mit unterschiedlichen Anforderungen bieten. Für RedCap-UEs kann der BWP-basierte Betrieb jedoch auf der Grundlage eines vereinfachten Rahmens unterstützt werden. In einem Beispiel kann von einem RedCap NR UE verlangt werden, dass es nur die auf RRC-Signalisierung basierende BWP-Anpassung unterstützt und nicht die dynamische BWP-Anpassung über Kontrollsignalisierung der Schicht 1. Darüber hinaus kann ein RedCap NR UE in einem Beispiel maximal einen UE-spezifisch ausgebildeten DL- oder UL-BWP zusätzlich zu dem ursprünglichen DL- oder UL-BWP unterstützen, der über den Master Information Block (MIB) oder SIB-1 ausgebildet werden kann.
  • In einem anderen Beispiel kann ein RedCap NR UE von einer höheren Schicht (z. B. einer RRC-Schicht) mit mehr als einem DL- oder UL-BWP ausgebildet werden und kann einen gemeinsamen Satz von Werten für alle Parameter, die als Teil von BWP-Konfigurationen ausgebildet sind, auf alle oder eine Teilmenge der DL- oder UL-BWPs anwenden, mit denen das RedCap NR UE ausgebildet ist, mit Ausnahme der Werte für die Mittenfrequenz und die Bandbreite des BWP (angegeben über den Parameter locationAndBandwidth), den BWP-Identifier (BWP Id) und/oder den Unterträgerabstand des BWP (angegeben über den Parameter subcarrierSpacing). Das heißt, andere Parameter, einschließlich eines oder mehrerer der Parameter BWP-DownlinkCommon, BWP-DownlinkDedicated, BWP-UplinkCommonund BWP-UplinkDedicated, können für alle oder die angegebene Teilmenge der konfigurierten BWPs gleich sein. BWP-DownlinkCommon wird verwendet, um die gemeinsamen (zellenspezifischen) Parameter eines Downlink-BWP zu konfigurieren. BWP-UplinkCommon wird verwendet, um die gemeinsamen (zellenspezifischen) Parameter eines Uplink-BWP zu konfigurieren. BWP-DownlinkDedicated wird verwendet, um die dedizierten (UE-spezifischen) Parameter eines Downlink-BWP zu konfigurieren. BWP-UplinkDedicated wird verwendet, um die dedizierten (UE-spezifischen) Parameter eines Uplink-BWP zu konfigurieren. Die Identifizierung der Untergruppe von BWPs kann dem UE über eine Signalisierung auf höherer Ebene bereitgestellt werden. In einem weiteren Beispiel kann ein RedCap-UE die auf dem DCI-Format (Downlink Control Information) basierende dynamische Umschaltung von BWPs nur aus dem Satz konfigurierter BWPs mit demselben Satz von Parametern unterstützen, mit Ausnahme der Mittenfrequenz und der BW (angegeben über locationAndBandwidth), der BWP-Kennung und möglicherweise des Unterträgerabstands der BWPs.
  • Verschiedene Vereinfachungen und damit verbundene Verbesserungen können für verschiedene Scheduling- und HARQ-Verfahren für RedCap NR UEs in Betracht gezogen werden.
  • Um Daten zu übertragen oder Sprachanrufe zu tätigen/empfangen, muss ein Endgerät eine Verbindung mit dem Netz herstellen, was über den Erstzugang mittels RRC-Verbindungsaufbauverfahren erfolgt. Sobald die RRC-Verbindung hergestellt ist, befindet sich das UE im RRC-Verbindungsmodus. Wenn für eine bestimmte Zeit keine Aktivität zum/vom Endgerät stattfindet, weist das Netz das Endgerät an, in den RRC-Idle-Status zu wechseln. Der Zustand RRC Inactive wird verwendet, um die Netzsignalisierungslast zu verringern und die Latenzzeit beim Übergang zum Zustand RRC Connected zu reduzieren.
  • In einem Beispiel kann ein RedCap NR UE in den Modi RRC Connected, RRC Idle oder RRC Inactive nicht verpflichtet sein, mehr als einen PDSCH gleichzeitig zu dekodieren. In einem anderen Beispiel muss ein RedCap NR UE im RRC-Idle- und RRC-Inactive-Modus möglicherweise nicht zwei PDSCHs dekodieren, die jeweils mit einer temporären Systeminformations-Funknetz-Identität (SI-RNTI), einer Paging-RNTI (P-RNTI), einer Random-Access-RNTI (RA-RNTI) oder einer Temporary-Cell-RNTI (TC-RNTI) geplant sind, wobei sich die beiden PDSCHs in nicht überlappenden physikalischen Ressourcenblöcken (PRBs) teilweise oder vollständig zeitlich überlappen.
  • In einem weiteren Beispiel muss ein RedCap NR UE in einer Zelle des Frequenzbereichs 1 oder 2 (FR1 oder FR2) ein PDSCH, das mit Zell-RNTI (C-RNTI), MCS-C-RNTI oder konfiguriertem Scheduling-RNTI (CS-RNTI) geplant ist, nicht dekodieren, wenn sich in derselben Zelle während eines Prozesses der P-RNTI-ausgelösten SI-Erfassung ein anderes PDSCH, das mit SI-RNTI geplant ist, teilweise oder vollständig zeitlich überlappt.
  • In einigen Beispielen muss ein RedCap NR UE ein PDSCH, das in einer Serving Cell mit C-RNTI oder MCS-C-RNTI (falls unterstützt) geplant ist, und ein anderes PDSCH, das in derselben Serving Cell mit CS-RNTI geplant ist, nicht dekodieren, wenn sich die PDSCHs teilweise oder vollständig zeitlich überschneiden. Dies bedeutet, dass die Priorisierung eines dynamisch eingeplanten PDSCH über eine DL semi-persistent scheduling (SPS) Gelegenheit von RedCap NR UEs nicht unterstützt werden kann.
  • In ähnlicher Weise ist es bei UL in einigen Beispielen nicht erforderlich, dass ein RedCap NR UE eine UL-Zuteilung in einem DCI-Format empfängt, die das UE anweist, ein dynamisch zugeteiltes (DG) PUSCH zu übertragen, das sich im Zeitbereich mit einem anderen PUSCH überschneiden kann, das dynamisch oder von höheren Schichten als Teil eines Typ 1 oder Typ 2 Configured Grant PUSCH (CG PUSCH) zugeteilt werden kann.
  • Zwei PDSCH- und PUSCH-Zuordnungstypen (Typ A und Typ B) sind in Rel-15 NR definiert, und beide müssen von allen Rel-15- und Rel-16-UEs (d.h. Nicht-RedCap-UEs) zwingend unterstützt werden. Die Notwendigkeit, beide PDSCH-Zuordnungstypen zu unterstützen, kann notwendig sein, um eine gemeinsame Zustellung von Systeminformationen, Paging und zugangsbezogenen gemeinsamen Kontrollnachrichten an RedCap- und Nicht-RedCap-Endgeräte in einer Zelle zu ermöglichen, doch können die Anforderungen für RedCap-Endgeräte bei einem PUSCH reduziert werden. Insbesondere kann in einigen Beispielen von einem RedCap NR UE verlangt werden, dass es nur PUSCH-Mapping Typ A unterstützt, so dass alle zugewiesenen PUSCHs bei Symbolindex 0 in einem Slot beginnen. Alternativ dazu kann von einem RedCap NR UE verlangt werden, dass er nur PUSCH-Mapping Typ B unterstützt. Bei beiden Optionen müsste das Netz in der Lage sein, RedCap NR UEs bei ihren Übertragungen auf dem physikalischen Random Access Channel (PRACH) zu identifizieren, um sicherzustellen, dass die Planung von Msg3-Übertragungen, die durch die UL-Zuteilung in der Random Access Response (RAR) ausgelöst werden, die entsprechende Einschränkung erfüllt (d. h. nur Typ-A- oder Typ-B-Zuordnung). So kann in einigen Beispielen ein RedCap NR UE durch SIB-Signalisierung ausgebildet werden, um ein PRACH auf PRACH-Ressourcen oder unter Verwendung von PRACH-Präambeln zu übertragen, die separat für RedCap NR UEs konfiguriert sind. In einem weiteren Beispiel können die Standard-A-Tabellen für die Zeitbereichsressourcenzuweisung (TDRA) für PUSCH, die in den Tabellen 6.1.2.1.1-2 und 6.1.2.1.1-3 in 3GPP TS38.214 definiert sind, so geändert werden, dass jede geänderte Tabelle nur Einträge mit PUSCH-Zuordnung des Typs A oder des Typs B enthält, je nach dem PUSCH-Zuordnungstyp, den ein RedCap NR UE unterstützen muss.
  • In einem weiteren Beispiel kann zumindest für normale zyklische Präfixe (CP) von einem RedCap NR UE nicht verlangt werden, PUSCH-Dauern zu unterstützen, die kürzer als 4, 6 oder 7 Symbole sind, weder für Mapping Typ A noch für Mapping Typ B.
  • In einem anderen Beispiel kann ein RedCap NR UE nicht mehr als einen PDSCH-Empfang oder mehr als eine PUSCH-Übertragung in einem Slot unterstützen.
  • Rel-15 NR-Spezifikationen schreiben vor, dass ein UE mindestens zwei CLPC-Schleifen (closed loop power control) für PUSCH- und PUCCH-Übertragungen (physical uplink control channel) unterstützen muss. Dabei geht es vor allem um die Unterstützung mehrerer Dienste mit unterschiedlichen Anforderungen an die Dienstgüte (QoS) oder um den Einsatz in einer Mehrstrahlumgebung bei höheren Frequenzen. Diese Anforderung kann jedoch für RedCap NR UEs vereinfacht werden, ohne dass es zu einer signifikanten Verschlechterung der Verbindungs- oder Systemleistung kommt. In einigen Beispielen kann es daher erforderlich sein, dass ein RedCap NR UE eine einzige CLPC-Schleife für die UL-Leistungssteuerung für PUSCH bzw. PUCCH unterstützt. Alternativ kann von einem RedCap NR UE verlangt werden, dass er eine einzige CLPC-Schleife für die UL-Leistungssteuerung für PUSCH bzw. PUCCH in FR1-Bändern und mindestens zwei CLPC-Schleifen für PUSCH bzw. PUCCH in FR2-Bändern unterstützt.
  • Rel-15 NR-Spezifikationen beauftragen ein UE, den Empfang eines PDSCH durch Ratenanpassung um Synchronisationssignal/Physical Broadcast Channel (SS/PBCH)-Blockübertragungsressourcen, halbstatisch konfigurierte Ressourcensätze, um konfigurierte PDCCH-Kontrollressourcensätze (CORESETs) oder um den Planungs-PDCCH-Kandidaten, der zur Planung eines PDSCH verwendet wird, zu unterstützen. Darüber hinaus kann ein Rel-15- oder Rel-16-NR-UE optional auch den Empfang von PDSCH durch Ratenanpassung um dynamisch angegebene Ressourcenmengen unterstützen.
  • Um die Komplexität des UE durch Ratenanpassungsoperationen zu vereinfachen, kann in einigen Beispielen von einem RedCap NR UE verlangt werden, einen PDSCH zu dekodieren, der von einem PDCCH mit zyklischer Redundanzprüfung (CRC) geplant ist, der durch SI-RNTI verwürfelt ist und dessen Systeminformationsindikator in DCI auf 1, RA-RNTI, MsgB-RNTI, P-RNTI, TC-RNTI, C-RNTI, MCS-C-RNTI, CS-RNTI oder PDSCHs mit SPS gesetzt ist, die sich mit einer oder mehreren SS/PBCH-Blockübertragungsressourcen, halbstatisch konfigurierten Ressourcensätzen, dynamisch angezeigten Ressourcensätzen, konfigurierten PDCCH-KORESETs oder Planungs-PDCCH überschneiden können, indem angenommen wird, dass der PDSCH auf die überlappenden Ressourcen abgebildet, aber nicht übertragen wird. Dieser Ansatz wird als „empfängerseitige Punktierung“ bezeichnet.
  • In einem anderen Beispiel muss ein RedCap NR UE nur ein PDSCH dekodieren, das von einem PDCCH mit durch SI-RNTI verwürfeltem CRC und einem auf 1 gesetzten Systeminformationsindikator in DCI, RA-RNTI, MsgB-RNTI, P-RNTI, TC-RNTI, C-RNTI, MCS-C-RNTI, CS-RNTI oder PDSCHs mit SPS geplant wird, die sich mit einer oder mehreren SS/PBCH-Blockübertragungsressourcen, halbstatisch konfigurierten Ressourcensätzen, konfigurierten PDCCH-CORESETs oder dem Planungs-PDCCH überschneiden können, entweder durch Ratenanpassung des PDSCH um solche überlappenden Ressourcen herum oder durch die Annahme, dass der PDSCH auf die überlappenden Ressourcen abgebildet, aber nicht übertragen wird.
  • In einem weiteren Beispiel muss ein RedCap NR UE nur maximal einen oder zwei halbstatisch konfigurierte Ratenanpassungs-Ressourcensätze unterstützen, die über den Parameter rateMatchPatternToAddModList der höheren Schicht auf der Granularität des Ressourcenblocks (RB) konfiguriert sind, und nicht mehr als zwei halbstatisch konfigurierte Ratenanpassungs-Ressourcensätze, die auf der Granularität der Ressourcenelement (RE)-Ebene konfiguriert sind. Die Dekodierung eines PDSCH im DCI-Format 1_1 oder 1_2, der sich mit einem dieser Ressourcensätze überschneidet („ratenangepasste Ressourcensätze“), kann auf der Grundlage der oben erläuterten „empfängerseitigen Punktierung“ erfolgen.
  • In einem Beispiel können semistatisch konfigurierte Ratenanpassungs-Ressourcensätze mit RE-Symbol-Granularität mindestens REs enthalten, die durch das RateMatchingPatternLTE-CRS in Ite-CRS-ToMatchAround in ServingCellConfig oder ServingCellConfigCommon angegeben sind und ein gemeinsames Referenzsignal (RS) konfigurieren, und die REs, die durch RateMatchingPatternLTE-CRS in Ite-CRS-PatternListr16 in ServingCellConfig angegeben sind und ein gemeinsames RS konfigurieren (falls unterstützt).
  • In einem anderen Beispiel kann ein RedCap NR UE innerhalb eines BWP mit einer oder mehreren ZP-Ressourcensatzkonfigurationen (CSI-RS) für aperiodisches, semipersistentes und periodisches Zeitbereichsverhalten konfiguriert werden (Parameter der höheren Schicht aperiodic-ZP-CSI-RS-ResourceSetsToAddModList, sp-ZP-CSI-RS-ResourceSetsToAddModList und p-ZP-CSI-RS-ResourceSet, die jeweils in PDSCH-Config enthalten sind), wobei jeder ZP-CSI-RS-Ressourcensatz aus höchstens „M“ ZP-CSI-RS-Ressourcen (Parameter der höheren Schicht ZP-CSI-RS-Resource) in der Numerologie des BWP besteht, wobei der Wert von „M“ kleiner als 16 ist, z.B. 4 oder 8.
  • In einer anderen Variante dieses Beispiels kann ein RedCap NR UE nicht mit einer oder mehreren ZP-CSI-RS-Ressourcensatzkonfiguration(en) für zumindest aperiodisches und möglicherweise auch nicht für semipersistentes Zeitbereichsverhalten konfiguriert werden (über die Parameter der höheren Schicht aperiodic-ZP-CSI-RS-ResourceSetsToAddModList und sp-ZP-CSI-RS-ResourceSetsToAddModList, die jeweils in PDSCH-Config enthalten sind).
  • 5G NR unterstützt fünf PUCCH-Formate: 2 kurze PUCCH-Formate (Formate 0 und 2) und 3 lange PUCCH-Formate (Formate 1, 3 und 4). Da die Trägeraggregation, wenn überhaupt, nur in begrenztem Umfang unterstützt wird, besteht möglicherweise keine Notwendigkeit, lange PUCCH-Formate, die für große Uplink-Kontrollinformationen (UCI) ausgelegt sind, oder kurze PUCCH-Formate (PUCCH Format 2) mit > 2 Bits UCI-Nutzlast zu unterstützen. So kann in einem Beispiel von einem RedCap NR UE verlangt werden, dass er nur die PUCCH-Formate 0, 1 und 4 unterstützt. In einem anderen Beispiel kann von einem RedCap NR UE verlangt werden, dass er nur die PUCCH-Formate 0, 1, 3 und 4 unterstützt.
  • In Anbetracht der Wahrscheinlichkeit kleinerer Nutzlasten für einen PUCCH können die Konfigurationen und Schwellenwerte für PUCCH-Ressourcen an die Rel-15-Spezifikationen angepasst werden. In einem Beispiel kann die Anzahl der PUCCH-Ressourcensätze auf zwei reduziert werden, wobei ein einziger UCI-Nutzlastschwellenwert für die Auswahl des PUCCH-Ressourcensatzes aus dem Rel-15-Wert von bis zu vier PUCCH-Ressourcensätzen definiert wird.
  • In Rel-15 können zwei PUCCH-Übertragungen, einschließlich des kurzen PUCCH-Formats und des langen PUCCH-Formats, oder zwei kurze PUCCH-Formate im Zeitmultiplex-Verfahren (TDM) gemultiplext werden. Um den Betrieb zu vereinfachen, kann ein RedCap NR UE in einigen Beispielen so konfiguriert werden, dass er maximal eine PUCCH in einem Slot überträgt.
  • In den 2 und 3 sind verschiedene Systeme, Geräte und Komponenten dargestellt, mit denen Aspekte der offengelegten Ausführungsformen umgesetzt werden können.
  • 2 zeigt ein Netz 200 in Übereinstimmung mit verschiedenen Ausführungsformen. Das Netz 200 kann in einer Weise betrieben werden, die den technischen Spezifikationen des 3GPP für LTE- oder 5G/NR-Systeme entspricht. Die Beispielausführungen sind jedoch in dieser Hinsicht nicht beschränkt, und die beschriebenen Ausführungsformen können auch für andere Netze gelten, die von den hier beschriebenen Grundsätzen profitieren, z. B. für künftige 3GPP-Systeme oder Ähnliches.
  • Das Netz 200 kann ein UE 202 umfassen, das ein mobiles oder nicht-mobiles Computergerät sein kann, das für die Kommunikation mit einem RAN 204 über eine Over-the-Air-Verbindung ausgelegt ist. Bei dem UE 202 kann es sich unter anderem um ein Smartphone, einen Tablet-Computer, ein tragbares Computergerät, einen Desktop-Computer, einen Laptop-Computer, ein Infotainment-Gerät im Fahrzeug, ein Unterhaltungsgerät im Fahrzeug, ein Kombiinstrument, ein Head-up-Display, ein Onboard-Diagnosegerät, ein mobiles Dashtop-Gerät, einen mobilen Datenterminal, ein elektronisches Motormanagementsystem, eine elektronische/Motorsteuereinheit, ein elektronisches/Motorsteuermodul, ein eingebettetes System, einen Sensor, einen Mikrocontroller, ein Steuermodul, ein Motormanagementsystem, ein vernetztes Gerät, ein maschinenartiges Kommunikationsgerät, ein M2M- oder D2D-Gerät, ein IoT-Gerät usw. handeln.
  • In einigen Ausführungsformen kann das Netzwerk 200 eine Vielzahl von UEs umfassen, die über eine Sidelink-Schnittstelle direkt miteinander verbunden sind. Bei den UEs kann es sich um M2M/D2D-Geräte handeln, die über physikalische Sidelink-Kanäle wie PSBCH, PSDCH, PSSCH, PSCCH, PSFCH usw. kommunizieren.
  • In einigen Ausführungsformen kann das UE 202 zusätzlich mit einem AP 206 über eine Over-the-Air-Verbindung kommunizieren. Der AP 206 kann eine WLAN-Verbindung verwalten, die dazu dienen kann, einen Teil oder den gesamten Netzverkehr vom RAN 204 zu entlasten. Die Verbindung zwischen dem UE 202 und dem AP 206 kann mit jedem IEEE 802.11-Protokoll erfolgen, wobei der AP 206 ein Wireless Fidelity (Wi-Fi®) Router sein könnte. In einigen Ausführungsformen können das UE 202, das RAN 204 und der AP 206 die Aggregation von Mobilfunk und WLAN (z. B. LWA/LWIP) nutzen. Bei der Aggregation von Mobilfunk- und WLAN-Ressourcen kann das UE 202 vom RAN 204 so konfiguriert werden, dass es sowohl Mobilfunk- als auch WLAN-Ressourcen nutzt.
  • Das RAN 204 kann einen oder mehrere Zugangsknoten, z. B. AN 208, umfassen. AN 208 kann Luftschnittstellenprotokolle für das UE 202 beenden, indem es Zugangsschichtprotokolle einschließlich RRC, PDCP, RLC, MAC und LI-Protokolle bereitstellt. Auf diese Weise kann der AN 208 eine Daten-/Sprachverbindung zwischen dem CN 220 und dem UE 202 ermöglichen. In einigen Ausführungsformen kann der AN 208 in einem separaten Gerät oder als eine oder mehrere Softwareeinheiten implementiert sein, die auf Servercomputern als Teil eines virtuellen Netzwerks laufen, das als CRAN oder virtueller Basisbandeinheiten-Pool bezeichnet werden kann. Der AN 208 kann als BS, gNB, RAN-Knoten, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, usw. bezeichnet werden. Bei dem AN 208 kann es sich um eine Makrozellen-Basisstation oder eine Basisstation mit geringer Leistung handeln, die Femtozellen, Pikozellen oder ähnliche Zellen mit kleineren Versorgungsbereichen, geringerer Nutzerkapazität oder höherer Bandbreite im Vergleich zu Makrozellen bereitstellt.
  • In Ausführungsformen, in denen das RAN 204 mehrere ANs umfasst, können diese über eine X2-Schnittstelle (wenn das RAN 204 ein LTE-RAN ist) oder eine Xn-Schnittstelle (wenn das RAN 204 ein 5G-RAN ist) miteinander gekoppelt sein. Über die X2/Xn-Schnittstellen, die in einigen Ausführungsformen in Steuerungs-/Nutzerebenen-Schnittstellen unterteilt sein können, können die ANs Informationen in Bezug auf Handover, Daten-/Kontextübertragung, Mobilität, Lastmanagement, Interferenzkoordinierung usw. übermitteln.
  • Die ANs des RAN 204 können jeweils eine oder mehrere Zellen, Zellgruppen, Komponententräger usw. verwalten, um dem UE 202 eine Luftschnittstelle für den Netzzugang bereitzustellen. Das UE 202 kann gleichzeitig mit einer Vielzahl von Zellen verbunden sein, die von denselben oder verschiedenen ANs des RAN 204 bereitgestellt werden. Beispielsweise können das UE 202 und das RAN 204 die Trägeraggregation nutzen, um dem UE 202 die Verbindung mit einer Vielzahl von Komponententrägern zu ermöglichen, die jeweils einer Pcell oder Scell entsprechen. In Dual-Connectivity-Szenarien kann ein erster AN ein Master-Knoten sein, der eine MCG bereitstellt, und ein zweiter AN kann ein sekundärer Knoten sein, der eine SCG bereitstellt. Bei den ersten/zweiten ANs kann es sich um eine beliebige Kombination aus eNB, gNB, ng-eNB usw. handeln.
  • Das RAN 204 kann die Luftschnittstelle über ein lizenziertes Spektrum oder ein unlizenziertes Spektrum bereitstellen. Für den Betrieb im unlizenzierten Spektrum können die Knoten LAA-, eLAA- und/oder feLAA-Mechanismen auf der Grundlage der CA-Technologie mit PCells/Scells verwenden. Vor dem Zugriff auf das unlizenzierte Spektrum können die Knoten eine Medien-/Trägererfassung durchführen, z. B. auf der Grundlage eines LBT-Protokolls (listen-before-talk).
  • In V2X-Szenarien kann das UE 202 oder der AN 208 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 einen geeigneten 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-Typ RSU“ bezeichnet werden; ein eNB kann als „eNB-Typ RSU“ bezeichnet werden; ein gNB kann als „gNB-Typ RSU“ bezeichnet werden; und dergleichen. In einem Beispiel ist eine RSU ein Computergerät, das mit einem Funkfrequenzschaltkreis gekoppelt ist, der sich am Straßenrand befindet und die Konnektivität für vorbeifahrende Fahrzeug-UEs unterstützt. Die RSU kann auch eine interne Datenspeicherungsschaltungsanordnung umfassen, um Kreuzungskartengeometrie, Verkehrsstatistiken, Medien sowie Anwendungen/Software zum Erfassen und Steuern des laufenden Fahrzeug- und Fußgänger-Verkehrs 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 auch andere zellulare/WLAN-Kommunikationsdienste anbieten. 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, der eine drahtgebundene Verbindung (z. B. Ethernet) zu einem Lichtsignalsteuergerät oder einem Backhaul-Netzwerk herstellt.
  • In einigen Ausführungsformen kann das RAN 204 ein LTE-RAN 210 mit eNBs, z. B. eNB 212, sein. Das LTE RAN 210 kann eine LTE-Luftschnittstelle mit den folgenden Merkmalen bereitstellen: SCS von 15 kHz; CP-OFDM-Wellenform für DL und SC-FDMA-Wellenform für UL; Turbo-Codes für Daten und TBCC für die Steuerung; usw. Die LTE-Luftschnittstelle kann CSI-RS für die CSI-Erfassung und das Strahlmanagement, PDSCH/PDCCH DMRS für die PDSCH/PDCCH-Demodulation und CRS für die Zellensuche und Anfangserfassung, Kanalqualitätsmessungen und Kanalschätzung für die kohärente Demodulation/Erkennung beim Endgerät nutzen. Die LTE-Luftschnittstelle kann in Bändern unter 6 GHz betrieben werden.
  • In einigen Ausführungsformen kann das RAN 204 ein NG-RAN 214 mit gNBs, zum Beispiel gNB 216, oder ng-eNBs, zum Beispiel ng-eNB 218, sein. Der gNB 216 kann sich mit 5G-fähigen UEs über eine 5G NR-Schnittstelle verbinden. Der gNB 216 kann mit einem 5G-Kern über eine NG-Schnittstelle verbunden sein, die eine N2-Schnittstelle oder eine N3-Schnittstelle umfassen kann. Der ng-eNB 218 kann auch über eine NG-Schnittstelle mit dem 5G-Kern verbunden sein, kann aber auch über eine LTE-Luftschnittstelle mit einem UE verbunden sein. Der gNB 216 und der ng-eNB 218 können über eine Xn-Schnittstelle miteinander verbunden sein.
  • In einigen Ausführungsformen kann die NG-Schnittstelle in zwei Teile aufgeteilt sein, eine NG-U-Schnittstelle (NG-U), die Verkehrsdaten zwischen den Knoten des NG-RAN 214 und einer UPF 248 (z. B. N3-Schnittstelle) überträgt, und eine NG-C-Schnittstelle (NG-C), die eine Signalisierungsschnittstelle zwischen den Knoten des NG-RAN 214 und einer AMF 244 (z. B. N2-Schnittstelle) ist.
  • Das NG-RAN 214 kann eine 5G-NR-Luftschnittstelle mit den folgenden Merkmalen bereitstellen: variable SCS; CP-OFDM für DL, CP-OFDM und DFT-s-OFDM für UL; Polar-, Repetitions-, Simplex- und Reed-Muller-Codes für die Steuerung und 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 verwendet möglicherweise kein CRS, sondern PBCH DMRS für die PBCH-Demodulation, PTRS für die Phasennachführung für PDSCH und ein Referenzsignal für die Zeitnachführung. Die 5G-NR-Luftschnittstelle kann in FR1-Bändern betrieben werden, die Bänder unter 6 GHz umfassen, oder in FR2-Bändern, die Bänder von 24,25 GHz bis 52,6 GHz umfassen. Die 5G-NR-Luftschnittstelle kann eine SSB enthalten, die ein Bereich eines Downlink-Ressourcenrasters ist, das PSS/SSS/PBCH enthält.
  • In einigen Ausführungsformen kann die 5G-NR-Luftschnittstelle BWPs für verschiedene Zwecke nutzen. So kann der BWP beispielsweise zur dynamischen Anpassung der SCS verwendet werden. Beispielsweise kann das UE 202 mit mehreren BWPs konfiguriert werden, wobei jede BWP-Konfiguration eine andere SCS hat. Wenn dem UE 202 eine BWP-Änderung angezeigt wird, wird auch die SCS der Übertragung geändert. Ein weiteres Anwendungsbeispiel für BWP ist die Energieeinsparung. Insbesondere können mehrere BWPs für das UE 202 mit einer unterschiedlichen Anzahl von Frequenzressourcen (z. B. PRBs) konfiguriert werden, um die Datenübertragung unter verschiedenen Verkehrsbelastungsszenarien 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 beim UE 202 und in einigen Fällen beim gNB 216. Ein BWP mit einer größeren Anzahl von PRBs kann für Szenarien mit höherem Verkehrsaufkommen verwendet werden.
  • Das RAN 204 ist kommunikativ mit dem CN 220 gekoppelt, das Netzelemente enthält, die verschiedene Funktionen zur Unterstützung von Daten- und Telekommunikationsdiensten für Kunden/Teilnehmer (z. B. Nutzer des UE 202) bereitstellen. Die Komponenten des CN 220 können in einem physischen Knoten oder in separaten physischen Knoten implementiert sein. In einigen Ausführungsformen kann NFV zur Virtualisierung aller oder eines Teils der von den Netzelementen des CN 220 bereitgestellten Funktionen auf physischen Rechen-/Speicherressourcen in Servern, Switches usw. verwendet werden. Eine logische Instanziierung des CN 220 kann als Netzwerk-Slice bezeichnet werden, und eine logische Instanziierung eines Teils des CN 220 kann als Netzwerk-Sub-Slice bezeichnet werden.
  • In einigen Ausführungsformen kann die CN 220 eine LTE CN 222 sein, die auch als EPC bezeichnet werden kann. Das LTE CN 222 kann MME 22, SGW 226, SGSN 228, HSS 230, PGW 232 und PCRF 234 umfassen, die über Schnittstellen (oder „Referenzpunkte“) miteinander gekoppelt sind, wie dargestellt. Die Funktionen der Elemente des LTE CN 222 können wie folgt kurz vorgestellt werden.
  • MME 224 kann Mobilitätsmanagementfunktionen implementieren, um einen aktuellen Standort des UE 202 zu verfolgen, um Paging, Trägeraktivierung/-deaktivierung, Handover, Gateway-Auswahl, Authentifizierung usw. zu erleichtern.
  • SGW 226 kann eine S1-Schnittstelle zum RAN abschließen und Datenpakete zwischen dem RAN und dem LTE CN 222 weiterleiten. SGW 226 kann ein lokaler Mobilitätsankerpunkt für Inter-RAN-Knoten-Handover sein und auch einen Anker für Inter-3GPP-Mobilität bieten. Weitere Zuständigkeiten können das legale Abfangen, Gebühren und die Durchsetzung einiger Richtlinien umfassen.
  • Der SGSN 228 kann den Standort des UE 202 verfolgen und Sicherheitsfunktionen und Zugangskontrolle durchführen. Darüber hinaus kann der SGSN 228 die Inter-EPC-Knoten-Signalisierung für die Mobilität zwischen verschiedenen RAT-Netzen, die PDN- und S-GW-Auswahl gemäß den Vorgaben der MME 224, die MME-Auswahl für Handover usw. durchführen. Der S3-Referenzpunkt zwischen der MME 224 und dem SGSN 228 kann den Austausch von Nutzer- und Trägerinformationen für die Mobilität zwischen 3GPP-Zugangsnetzen im Ruhe-/Aktivzustand ermöglichen.
  • HSS 230 kann eine Datenbank für Netznutzer enthalten, einschließlich abonnementbezogener Informationen zur Unterstützung der Abwicklung von Kommunikationssitzungen durch die Netzeinheiten. Der HSS 230 kann Unterstützung für Routing/Roaming, Authentifizierung, Autorisierung, Namens-/Adressierungsauflösung, Standortabhängigkeiten usw. bieten. Ein S6a-Referenzpunkt zwischen dem HSS 230 und der MME 224 kann die Übertragung von Abonnement- und Authentifizierungsdaten zur Authentifizierung/Autorisierung des Nutzerzugangs zum LTE CN 220 ermöglichen.
  • Der PGW 232 kann eine SGi-Schnittstelle zu einem Datennetz (DN) 236 abschließen, das einen Anwendungs-/Inhaltsserver 238 enthalten kann. Der PGW 232 kann Datenpakete zwischen dem LTE CN 222 und dem Datennetz 236 weiterleiten. Der PGW 232 kann über einen S5-Referenzpunkt mit dem SGW 226 gekoppelt sein, um das Tunneln der Benutzerebene und das Tunnelmanagement zu erleichtern. Der PGW 232 kann außerdem einen Knoten für die Durchsetzung von Richtlinien und die Erhebung von Gebührendaten enthalten (z. B. PCEF). Darüber hinaus kann der SGi-Referenzpunkt zwischen dem PGW 232 und dem Datennetz 236 ein externes öffentliches, ein privates PDN oder ein betreiberinternes Paketdatennetz sein, beispielsweise für die Bereitstellung von IMS-Diensten. Der PGW 232 kann über einen Gx-Referenzpunkt mit einer PCRF 234 gekoppelt sein
  • PCRF 234 ist das Regelungs- und Gebührenkontrollelement des LTE CN 222. PCRF 234 kann kommunikativ mit dem App-/Inhaltsserver 238 verbunden sein, um geeignete QoS- und Gebührenparameter für Dienstflüsse zu bestimmen. Der PCRF 232 kann zugehörige Regeln in einem PCEF (über den Gx-Referenzpunkt) mit entsprechendem TFT und QCI bereitstellen.
  • In einigen Ausführungsformen kann der CN 220 ein 5GC 240 sein. Der 5GC 240 kann eine AUSF 242, AMF 244, SMF 246, UPF 248, NSSF 250, NEF 252, NRF 254, PCF 256, UDM 258 und AF 260 umfassen, die über Schnittstellen (oder „Referenzpunkte“) miteinander gekoppelt sind, wie dargestellt. Die Funktionen der Elemente des 5GC 240 können wie folgt kurz vorgestellt werden
  • Die AUSF 242 kann Daten für eine Authentifizierung des UE 202 speichern und authentifizierungsbezogene Funktionalität handhaben. Die AUSF 242 kann einen gemeinsamen Authentifizierungsrahmen für verschiedene Zugriffstypen ermöglichen. Zusätzlich zur Kommunikation mit anderen Elementen des 5GC 240 über Referenzpunkte, wie dargestellt, kann die AUSF 242 eine Nausf-Service-basierte Schnittstelle aufweisen.
  • Die AMF 244 kann es anderen Funktionen des 5GC 240 ermöglichen, mit dem UE 202 und dem RAN 204 zu kommunizieren und Benachrichtigungen über Mobilitätsereignisse in Bezug auf den UE 202 zu abonnieren. Die AMF 244 kann für das Registrierungsmanagement (z. B. für die Registrierung der UE 202), das Verbindungsmanagement, das Erreichbarkeitsmanagement, das Mobilitätsmanagement, das rechtmäßige Abfangen von AMF-bezogenen Ereignissen und die Authentifizierung und Autorisierung des Zugangs zuständig sein. Die AMF 244 kann einen Transport für SM-Nachrichten zwischen dem UE 202 und der SMF 246 bereitstellen und als ein transparenter Proxy für ein Routing von SM-Nachrichten agieren. Die AMF 244 kann auch den Transport von SMS-Nachrichten zwischen dem UE 202 und einer SMSF ermöglichen. Die AMF 244 kann mit der AUSF 242 und dem UE 202 interagieren, um verschiedene Sicherheitsanker- und Kontextmanagementfunktionen auszuführen. Darüber hinaus kann die AMF 244 ein Abschlusspunkt einer RAN-CP-Schnittstelle sein, die einen N2-Bezugspunkt zwischen dem RAN 204 und der AMF 244 enthalten oder sein kann; und die AMF 244 kann ein Abschlusspunkt der NAS-(N1)-Signalisierung sein und NAS-Verschlüsselung und Integritätsschutz durchführen. Die AMF 244 kann auch NAS-Signalisierung mit dem UE 202 über eine N3 IWF-Schnittstelle unterstützen.
  • Die SMF 246 kann verantwortlich sein für SM (z. B. Sitzungsaufbau, Tunnelmanagement zwischen UPF 248 und AN 208); Zuweisung und Verwaltung von UE-IP-Adressen (einschließlich optionaler Autorisierung); Auswahl und Kontrolle der UP-Funktion; Konfiguration der Verkehrslenkung an der UPF 248, um den Verkehr zum richtigen Ziel zu leiten; Beendigung von Schnittstellen zu Policy-Control-Funktionen; Kontrolle eines Teils der Policy-Enforcement-, Gebühren- und QoS-Funktionen; rechtmäßiges Abfangen (für SM-Ereignisse und Schnittstelle zum LI-System); Beendigung von SM-Teilen von NAS-Nachrichten; Downlink-Datenbenachrichtigung; Initiierung AN-spezifischer SM-Informationen, die über AMF 244 über N2 an den AN 208 gesendet werden; und Bestimmung des SSC-Modus einer Sitzung. SM kann sich auf die Verwaltung einer PDU-Sitzung beziehen, und eine PDU-Sitzung oder „Sitzung“ kann sich auf einen PDU-Verbindungsdienst beziehen, der den Austausch von PDUs zwischen dem UE 202 und dem Datennetz 236 bereitstellt oder ermöglicht.
  • Die UPF 248 kann als Ankerpunkt für Intra-RAT- und Inter-RAT-Mobilität, als externer PDU-Sitzungspunkt zur Verbindung mit dem Datennetz 236 und als Verzweigungspunkt zur Unterstützung von Multihomed-PDU-Sitzungen dienen. Die UPF 248 kann auch Paketrouting und -Weiterleiten durchführen, Paketinspektion durchführen, den Benutzerebenen-Teil der Richtlinienregeln durchsetzen, Pakete rechtmäßig abfangen (UP-Sammlung), Verkehrsnutzungsberichten durchführen, QoS-Handhabung für eine Benutzerebene (z. B. Paketfilteren, Gating, UL/DL-Ratendurchsetzung) durchführen, Uplink-Verkehrsverifizierung (z. B. SDF-to-QoS-Flussabbildung) durchführen, Transportebenen-Paketmarkieren in dem Uplink und Downlink, und Downlink-Paketpuffern und Downlink-Datenbenachrichtigungs-Triggern durchführen. Die UPF 248 kann einen Uplink-Klassifizierer umfassen, um ein Routing von Verkehrsflüssen zu einem Datennetz zu unterstützen.
  • Die NSSF 250 kann einen Satz von Netzscheibeninstanzen, die das UE 202 bedienen, auswählen. Die NSSF 250 kann bei Bedarf auch die erlaubte NSSAI und das Abbilden auf die abonnierten S-NSSAIs bestimmen. Die NSSF 250 kann auch den AMF-Satz bestimmen, der zur Bedienung des UE 202 verwendet werden soll, oder eine Liste von AMF-Kandidaten auf der Grundlage einer geeigneten Konfiguration und möglicherweise durch Abfrage der NRF 254. Die Auswahl eines Satzes von Netzwerk-Slice-Instanzen für das UE 202 kann durch die AMF 244 ausgelöst werden, bei der das UE 202 durch Interaktion mit der NSSF 250 registriert ist, was zu einem Wechsel der AMF führen kann. Die NSSF 250 kann mit der AMF 244 über einen N22-Referenzpunkt interagieren und mit einer anderen NSSF in einem besuchten Netz über einen N31-Referenzpunkt (nicht dargestellt) kommunizieren. Zusätzlich kann die NSSF 250 eine Nnssf-dienstbasierte Schnittstelle aufweisen.
  • Die NEF 252 kann Dienste und Fähigkeiten, die von 3GPP-Netzfunktionen bereitgestellt werden, auf sichere Weise für Dritte, interne Exposition/Re-Exposition, AFs (z. B. AF 260), Edge-Computing- oder Fog-Computing-Systeme usw. zugänglich machen. In solchen Ausführungsformen kann die NEF 252 die AFs authentifizieren, autorisieren oder drosseln. Die NEF 252 kann auch Informationen, die mit der AF 260 ausgetauscht wurden, und Informationen, die mit internen Netzfunktionen ausgetauscht wurden, übersetzen. Zum Beispiel kann die NEF 252 zwischen einem AF-Dienst-Identifizierer und einer internen 5GC-Information übersetzen. Die NEF 252 kann auch Informationen von anderen NFs empfangen, die auf den exponierten Fähigkeiten anderer NFs basieren. Diese Informationen können an der NEF 252 als strukturierte Daten oder an einer Datenspeicherungs-NF unter Verwendung standardisierter Schnittstellen gespeichert werden. Die gespeicherten Informationen können dann vom NEF 252 an andere NFs und AFs weitergegeben oder für andere Zwecke, z. B. für Analysen, verwendet werden. Außerdem kann die NEF 252 eine dienstbasierte Schnittstelle aufweisen.
  • Die NRF 254 kann Dienstentdeckungsfunktionen unterstützen, NF-Entdeckungsanforderungen von NF-Instanzen empfangen und die Informationen der entdeckten NF-Instanzen den NF-Instanzen bereitstellen. Die NRF 254 erhält auch Informationen über verfügbare NF-Instanzen und ihre unterstützten Dienste. Nach hiesigem Gebrauch können sich die Begriffe „instanziieren“, „Instanziierung“ und Ähnliches auf die Erzeugung einer Instanz beziehen, und eine „Instanz“ kann sich auf ein konkretes Auftreten eines Objekts beziehen, das, zum Beispiel, während einer Ausführung eines Programmcodes auftreten kann. Zusätzlich kann die NRF 254 die dienstbasierte Schnittstelle Nnrf aufweisen.
  • Die PCF 256 kann den Funktionen der Steuerebene Regeln zu deren Durchsetzung zur Verfügung stellen und auch einen einheitlichen Richtlinienrahmen zur Steuerung des Netzverhaltens unterstützen. Die PCF 256 kann auch ein Frontend für den Zugriff auf Abonnementinformationen implementieren, die für politische Entscheidungen in einem UDR des UDM 258 relevant sind. Zusätzlich zur Kommunikation mit Funktionen über Referenzpunkte, wie dargestellt, verfügt das PCF 256 über eine dienstbasierte Npcf-Schnittstelle.
  • Das UDM 258 kann abonnementbezogene Informationen handhaben, um die Handhabung von Kommunikationssitzungen durch die Netzentitäten zu unterstützen, und kann Abonnementdaten des UE 202 speichern. So können beispielsweise Abonnementdaten über einen N8-Referenzpunkt zwischen dem UDM 258 und der AMF 244 übermittelt werden. Das UDM 258 kann zwei Teile umfassen, ein Anwendungs-Frontend und einen UDR. Das UDR kann Abonnementdaten und Richtliniendaten für das UDM 258 und die PCF 256 und/oder strukturierte Daten für Freigabe- und Anwendungsdaten (umfassend PFDs für Anwendungsdetektion, Anwendungsanforderungsinformationen für mehrere UEs 202) für die NEF 252 speichern. Die auf dem Nudr-Dienst basierende Schnittstelle kann vom UDR 221 genutzt werden, um dem UDM 258, der PCF 256 und NEF 252 den Zugriff auf einen bestimmten Satz gespeicherter 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-FE umfassen, das für ein Verarbeiten von Zugangsdaten, Standortmanagement, Abonnementmanagement und so weiter zuständig ist. Mehrere unterschiedliche Frontends können dem gleichen Benutzer in unterschiedlichen Transaktionen dienen. Das UDM-FE greift auf die in dem UDR gespeicherten Abonnementinformationen zu und führt ein Authentifizierungs-Zugangsdatenverarbeiten, ein Benutzeridentifikationshandhaben, eine Zugriffsautorisierung, Registrierungs-/Mobilitätsmanagement und Abonnementmanagement durch. Zusätzlich zur Kommunikation mit anderen NFs über Referenzpunkte, wie dargestellt, kann das UDM 258 die dienstbasierte Schnittstelle Nudm aufweisen
  • Die AF 260 kann die Verkehrslenkung durch die Anwendung beeinflussen, den Zugang zum NEF ermöglichen und mit dem Regelwerk für die Regelkontrolle interagieren.
  • In einigen Ausführungsformen kann der 5GC 240 Edge Computing ermöglichen, indem er Betreiber-/Drittanbieterdienste so auswählt, dass sie sich geografisch in der Nähe eines Punktes befinden, an dem das UE 202 mit dem Netz verbunden ist. Dies kann die Latenzzeit und die Belastung des Netzes verringern. Um Edge-Computing-Implementierungen bereitzustellen, kann der 5GC 240 eine UPF 248 in der Nähe des UE 202 auswählen und eine Verkehrssteuerung von der UPF 248 zum Datennetz 236 über die N6-Schnittstelle durchführen. Dies kann auf den UE-Abonnementdaten, dem UE-Standort und den durch die AF 260 bereitgestellten Informationen basieren. Auf diese Weise kann die AF 260 UPF (Neu-)Auswahl und Verkehrsrouting beeinflussen. Basierend auf Betreiberbereitstellung, wenn die AF 260 als vertrauenswürdige Entität betrachtet wird, kann der Netzbetreiber es der AF 260 erlauben, direkt mit relevanten NFs zu interagieren. Zusätzlich kann die AF 260 eine Naf-Service-basierte Schnittstelle aufweisen
  • Das Datennetz 236 kann verschiedene Netzbetreiberdienste, Internetzugang oder Dienste von Drittanbietern repräsentieren, die von einem oder mehreren Servern bereitgestellt werden können, z. B. dem Anwendungs-/Inhaltsserver 238.
  • 3 zeigt schematisch ein drahtloses Netzwerk 300 in Übereinstimmung mit verschiedenen Ausführungsformen. Das drahtlose Netzwerk 300 kann ein UE 302 enthalten, das in drahtloser Kommunikation mit einem AN 304 steht. Das UE 302 und das AN 304 können den an anderer Stelle beschriebenen gleichnamigen Komponenten ähneln und mit diesen im Wesentlichen austauschbar sein.
  • Das UE 302 kann über die Verbindung 306 mit dem AN 304 kommunizieren. Die Verbindung 306 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 302 kann eine Host-Plattform 308 umfassen, die mit einer Modem-Plattform 310 gekoppelt ist. Die Host-Plattform 308 kann eine Schaltung zur Anwendungsverarbeitung 312 enthalten, die mit einer Schaltung zur Protokollverarbeitung 314 der Modemplattform 310 gekoppelt sein kann. Die Schaltung für die Anwendungsverarbeitung 312 kann verschiedene Anwendungen für das UE 302 ausführen, die Anwendungsdaten liefern/empfangen. Die Anwendungsverarbeitungsschaltung 312 kann darüber hinaus eine oder mehrere Schichtoperationen implementieren, um Anwendungsdaten an ein Datennetz zu senden/von diesem zu empfangen. Diese Schichten können Transport- (z. B. UDP) und Internet- (z. B. IP) Operationen umfassen
  • Die Protokollverarbeitungsschaltung 314 kann eine oder mehrere der Schichtoperationen implementieren, um die Übertragung oder den Empfang von Daten über die Verbindung 306 zu erleichtern. Die von der Protokollverarbeitungsschaltung 314 implementierten Schichtoperationen können z. B. MAC-, RLC-, PDCP-, RRC- und NAS-Operationen umfassen.
  • Die Modemplattform 310 kann ferner digitale Basisbandschaltungen 316 enthalten, die eine oder mehrere Schichtoperationen implementieren können, die „unterhalb“ der Schichtoperationen liegen, die von den Protokollverarbeitungsschaltungen 314 in einem Netzwerkprotokollstapel ausgeführt werden. Diese Operationen können beispielsweise PHY-Operationen umfassen, einschließlich einer oder mehrerer HARQ-ACK-Funktionen, Scrambling/Decrambling, Codierung/Decodierung, Layer Mapping/De-Mapping, Modulationssymbol-Mapping, Bestimmung der empfangenen Symbole/Bit-Metrik, Vorcodierung/Decodierung von Mehrantennenanschlüssen, die eine oder mehrere Raum-Zeit- , Raum-Frequenz- oder räumliche Codierung(en) umfassen können, Referenzsignalerzeugung/- detektion, Erzeugung und/oder Decodierung von Präambelsequenzen, Erzeugung/Detektion von Synchronisationssequenzen, Blinddecodierung von Steuerkanalsignalen und andere verwandte Funktionen
  • Die Modemplattform 310 kann ferner einen Sendeschaltkreis 318, einen Empfangsschaltkreis 320, einen HF-Schaltkreis 322 und ein HF-Frontend (RFFE) 324 umfassen, das ein oder mehrere Antennenfelder 326 enthalten oder mit diesen verbunden sein kann. Der Sendeschaltkreis 318 kann einen Digital-Analog-Wandler, einen Mischer, Zwischenfrequenz-Komponenten usw. enthalten. Die Empfangsschaltung 320 kann einen Analog-Digital-Wandler, Mischer, ZF-Komponenten usw. enthalten; die HF-Schaltung 322 kann einen rauscharmen Verstärker, einen Leistungsverstärker, Leistungsnachführungskomponenten usw. enthalten; das RFFE 324 kann Filter (z. B. Oberflächen-/Bulk-Acoustic-Wave-Filter), Schalter, Antennentuner, Strahlformungskomponenten (z. B. Phase-Array-Antennenkomponenten) usw. enthalten. Die Auswahl und Anordnung der Komponenten des Sendeschaltkreises 318, des Empfangsschaltkreises 320, des HF-Schaltkreises 322, des RFFE 324 und der Antennenpaneele 326 (allgemein als „Sende-/Empfangskomponenten“ bezeichnet) kann sich nach den Einzelheiten einer bestimmten Implementierung richten, z. B. ob es sich um TDM- oder FDM-Kommunikation, um mmWave- oder Sub-6-GHz-Frequenzen handelt usw. In einigen Ausführungsformen können die Sende-/Empfangskomponenten in mehreren parallelen Sende-/Empfangsketten angeordnet sein, sie können sich in denselben oder in verschiedenen Chips/Modulen befinden, usw.
  • In einigen Ausführungsformen kann der Protokollverarbeitungsschaltkreis 314 eine oder mehrere Instanzen von Steuerschaltkreisen (nicht dargestellt) enthalten, um Steuerfunktionen für die Sende-/Empfangskomponenten bereitzustellen.
  • Ein UE-Empfang kann durch und über die Antennenfelder 326, das RFFE 324, die HF-Schaltung 322, die Empfangsschaltung 320, die digitale Basisbandschaltung 316 und die Protokollverarbeitungsschaltung 314 hergestellt werden. In einigen Ausführungsformen können die Antennenfelder 326 eine Übertragung von dem AN 304 durch Empfangsstrahlformung von Signalen empfangen, die von einer Vielzahl von Antennen/Antennenelementen des einen oder der mehreren Antennenfelder 326 empfangen werden.
  • Eine UE-Übertragung kann durch und über die Protokollverarbeitungsschaltung 314, die digitale Basisbandschaltung 316, die Sendeschaltung 318, die HF-Schaltung 322, das RFFE 324 und die Antennenfelder 326 hergestellt werden. In einigen Ausführungsformen können die Sendekomponenten des UE 304 einen räumlichen Filter auf die zu übertragenden Daten anwenden, um einen von den Antennenelementen der Antennenfelder 326 ausgesendeten Sendestrahl zu bilden.
  • Ähnlich wie das UE 302 kann das AN 304 eine Host-Plattform 328 umfassen, die mit einer Modem-Plattform 330 gekoppelt ist. Die Host-Plattform 328 kann eine Schaltung zur Anwendungsverarbeitung 332 enthalten, die mit einer Schaltung zur Protokollverarbeitung 334 der Modemplattform 330 gekoppelt ist. Die Modemplattform kann außerdem eine digitale Basisbandschaltung 336, eine Sendeschaltung 338, eine Empfangsschaltung 340, eine HF-Schaltung 342, eine RFFE-Schaltung 344 und Antennenfelder 346 umfassen. Die Komponenten des AN 304 können den gleichnamigen Komponenten des UE 302 ähnlich und im Wesentlichen mit ihnen austauschbar sein. Zusätzlich zur Durchführung der oben beschriebenen Datenübertragung/des Datenempfangs können die Komponenten des AN 308 verschiedene logische Funktionen ausführen, die beispielsweise RNC-Funktionen wie die Verwaltung von Funkträgern, die dynamische Verwaltung von Funkressourcen in Aufwärts- und Abwärtsrichtung und die Planung von Datenpaketen umfassen.
  • 4 ist ein Blockdiagramm, das gemäß einigen Ausführungsbeispielen Komponenten zeigt, die in der Lage sind, Anweisungen von einem maschinenlesbaren oder computerlesbaren Medium (z. B. einem nicht-transitorischen maschinenlesbaren Speichermedium) zu lesen und eine oder mehrere der hierin erörterten Methoden durchzuführen. 4 zeigt eine schematische Darstellung der Hardwareressourcen 400, einschließlich eines oder mehrerer Prozessoren (oder Prozessorkerne) 410, eines oder mehrerer Speichergeräte 420 und einer oder mehrerer Kommunikationsressourcen 430, die jeweils über einen Bus 440 oder andere Schnittstellenschaltungen kommunikativ gekoppelt sein können. Für Ausführungsbeispiele, bei denen Knotenvirtualisierung (z.B. NFV) verwendet wird, kann ein Hypervisor 402 ausgeführt sein, um eine Ausführungsumgebung für eine oder mehrere Netzscheiben/Teilscheiben bereitzustellen, um die Hardwareressourcen 400 zu verwenden.
  • Die Prozessoren 410 können zum Beispiel einen Prozessor 412 und einen Prozessor 414 umfassen. Der eine oder die mehreren Prozessoren 410 können zum Beispiel eine zentrale Verarbeitungseinheit (CPU; central processing unit), ein Reduzierter-Anweisungssatz-Rechen-(RISC; Reduced Instruction Set Computing) Prozessor, ein Komplexer-Anweisungssatz-Rechen- (CISC; Complex Instruction Set Computing) -Prozessor, eine Graphikverarbeitungseinheit (GPU; graphics processing unit), ein DSP, wie beispielsweise ein Basisbandprozessor, eine ASIC, ein FPGA, eine integrierte Radiofrequenzschaltung (RFIC; Radio Frequency Integrated Circuit), ein anderer Prozessor (umfassend diese, die hierin erörtert sind) oder irgendeine geeignete Kombination derselben sein.
  • Die Speicher-/Speicherungsvorrichtungen 420 können einen Hauptspeicher, eine Plattenspeicherung oder irgendeine geeignete Kombination davon umfassen. Zu den Speichergeräten 420 kann jede Art von flüchtigem, nichtflüchtigem oder halbflüchtigem Speicher gehören, 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., ohne darauf beschränkt zu sein.
  • Die Kommunikationsressourcen 430 können Verbindungs- oder Netzwerkschnittstellen-Controller, Komponenten oder andere geeignete Geräte zur Kommunikation mit einem oder mehreren Peripheriegeräten 404 oder einer oder mehreren Datenbanken 406 oder anderen Netzwerkelementen über ein Netzwerk 408 umfassen. Die Kommunikationsressourcen 430 können beispielsweise kabelgebundene Kommunikationskomponenten (z. B. für die Kopplung über USB, Ethernet usw.), Komponenten für die zellulare Kommunikation, NFC-Komponenten, Bluetooth®- (oder Bluetooth® Low Energy-) Komponenten, Wi-Fi®-Komponenten und andere Kommunikationskomponenten umfassen.
  • Die Anweisungen 450 können Software, ein Programm, eine Anwendung, ein Applet, eine App oder anderen ausführbaren Code umfassen, um zu verursachen, dass zumindest irgendeiner der Prozessoren 410 irgendeines oder mehrere der hierin erörterten Verfahren ausführt. Die Anweisungen 450 können vollständig oder teilweise innerhalb von zumindest einem der Prozessoren 410 (z.B. innerhalb des Cache-Speichers des Prozessors), den Speicher-/Speicherungsvorrichtungen 420 oder irgendeiner geeigneten Kombination davon vorliegen. Ferner kann irgendein Abschnitt der Anweisungen 450 von irgendeiner Kombination der Peripherievorrichtungen 404 oder der Datenbanken 406 auf die Hardware-Ressourcen 400 übertragen werden. Dementsprechend sind der Speicher der Prozessoren 410, die Speicher-/Speicherungsvorrichtungen 420, die Peripherievorrichtungen 404 und die Datenbanken 406 Beispiele für computerlesbare und maschinenlesbare Medien.
  • Ein anderes Beispiel ist ein Computerprogramm, das einen Programmcode zum Ausführen von zumindest einem der hierin beschriebenen Verfahren umfasst, wenn das Computerprogramm auf einem Computer, einem Prozessor oder einer programmierbaren Hardwarekomponente ausgeführt wird. Ein anderes Beispiel ist eine maschinenlesbare Speicherung, die maschinenlesbare Anweisungen umfasst, die bei Ausführung ein Verfahren implementieren oder eine Vorrichtung realisieren, wie hierin beschrieben ist. Ein weiteres Beispiel ist ein maschinenlesbares Medium, das einen Code umfasst, der bei Ausführung verursacht, dass eine Maschine irgendeines der hierin beschriebenen Verfahren ausführt.
  • Die Beispiele, wie sie hierin beschrieben sind, können wie folgt zusammengefasst werden:
  • Ein Beispiel (z. B. Beispiel 1) bezieht sich auf ein UE mit reduzierten Fähigkeiten für drahtlose 3GPP-5G-Kommunikationssysteme. Das UE mit eingeschränkten Fähigkeiten umfasst eine Schaltung, die so ausgebildet ist, dass sie UL-Übertragungen sendet und DL-Übertragungen empfängt, wobei die Schaltung so ausgebildet ist, dass sie die obligatorischen Anforderungen für ein UE unterstützt, die entweder in der 5G-Spezifikation von 3GPP Release 15 oder Release 16 definiert sind, wobei eine oder mehrere der obligatorischen Anforderungen gelockert sind.
  • Ein weiteres Beispiel (z.B. Beispiel 2) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. Beispiel 1), wobei die Schaltung so ausgebildet ist, dass sie eine maximale Bandbreite von 20 MHz in DL bzw. UL in 5G FR1-Bändern und eine maximale Bandbreite von 100 MHz in DL bzw. UL in 5G FR2-Bändern unterstützt.
  • Ein weiteres Beispiel (z.B. Beispiel 3) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. Beispiel 1 oder 2), wobei die Schaltung so ausgebildet ist, dass sie 64QAM als höchste Modulationsordnung sowohl für ein PDSCH als auch für ein PUSCH unterstützt.
  • Ein weiteres Beispiel (z.B. Beispiel 4) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. Beispiel 3), wobei die Schaltung so ausgebildet ist, dass sie eine Low-SE-64-QAM-MCS-Tabelle unterstützt, die in Tabelle 5.1.3.1-3 in 3GPP TS 38.214 für den PDSCH und den PUSCH bei Verwendung der CP-OFDM-Wellenform bzw. in Tabelle 6.1.4.1-2 in 3GPP TS 38.214 für den PUSCH bei Verwendung von DFT-S-OFDM definiert ist.
  • Ein weiteres Beispiel (z. B. Beispiel 5) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. Beispiel 4), wobei die Schaltung so ausgebildet ist, dass sie die in Tabelle 5.1.3.1-3 und Tabelle 6.1.4.1-2 in 3GPP TS 38.214 definierten Low-SE-64-QAM-MCS-Tabellen als zwingende Anforderung unterstützt.
  • Ein weiteres Beispiel (z. B. Beispiel 6) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. eines der Beispiele 1-5), wobei die Schaltung so ausgebildet ist, dass sie nur die DFT-S-OFDM-Wellenform für PUSCH-Übertragungen unterstützt.
  • Ein weiteres Beispiel (z.B. Beispiel 7) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-6), wobei die Schaltung so ausgebildet ist, dass sie nur RRC-Signalisierungs-basierte BWP-Anpassung unterstützt.
  • Ein weiteres Beispiel (z.B. Beispiel 8) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. Beispiel 7), bei dem die Schaltung so ausgebildet ist, dass sie maximal einen UE-spezifisch konfigurierten DL- oder UL-BWP zusätzlich zu einem anfänglichen DL- bzw. UL-BWP unterstützt.
  • Ein weiteres Beispiel (z.B. Beispiel 9) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-6), wobei das UE mit mehr als einem DL- oder UL-BWP durch eine höhere Schicht ausgebildet ist und die Schaltung so ausgebildet ist, dass sie einen gemeinsamen Satz von Werten für alle Parameter, die als Teil von BWP-Konfigurationen konfiguriert sind, auf alle oder eine Teilmenge von konfigurierten DL- oder UL-BWPs anwendet, mit Ausnahme von Werten für eine Mittenfrequenz und Bandbreite, BWP-Identität und Unterträgerabstand der konfigurierten BWPs.
  • Ein weiteres Beispiel (z.B. Beispiel 10) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-9), bei dem, wenn sich das UE in den Modi RRC Connected, RRC Idle oder RRC Inactive befindet, die Schaltung so ausgebildet ist, dass sie zu jedem Zeitpunkt nur einen PDSCH dekodiert.
  • Ein weiteres Beispiel (z.B. Beispiel 11) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-10), wobei die Schaltung so ausgebildet ist, dass sie einen ersten PDSCH, der in einer bedienenden Zelle mit C-RNTI oder MCS-C-RNTI geplant ist, und einen zweiten PDSCH, der in der bedienenden Zelle mit CS-RNTI geplant ist, nicht dekodiert, wenn sich der erste und der zweite PDSCH zeitlich teilweise oder vollständig überlappen.
  • Ein weiteres Beispiel (z.B. Beispiel 12) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-11), wobei die Schaltung so ausgebildet ist, dass sie keine Aufwärtsstreckenerlaubnis in einem DCI-Format empfängt, die das UE anweist, ein dynamisch erteiltes (DG) PUSCH zu übertragen, das sich zeitlich mit einem anderen PUSCH überschneidet, das dynamisch oder von einer höheren Schicht als Teil eines Typ 1 oder Typ 2 Configured Grant PUSCH erteilt wird.
  • Ein weiteres Beispiel (z.B. Beispiel 13) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-12), wobei die Schaltung so ausgebildet ist, dass sie nur PUSCH-Mapping Typ A unterstützt.
  • Ein weiteres Beispiel (z. B. Beispiel 14) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. eines der Beispiele 1-13), wobei die Schaltung so ausgebildet ist, dass sie nur einen PDSCH-Empfang oder eine PUSCH-Übertragung in einem Schlitz unterstützt.
  • Ein weiteres Beispiel (z. B. Beispiel 15) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. eines der Beispiele 1-14), bei dem die Schaltung so ausgebildet ist, dass sie eine CLPC-Schleife für die Leistungssteuerung in der Aufwärtsrichtung für PUSCH bzw. PUCCH unterstützt.
  • Ein weiteres Beispiel (z. B. Beispiel 16) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. eines der Beispiele 1-15), bei dem die Schaltung so ausgebildet ist, dass sie eine CLPC-Schleife für die Aufwärtsstrecken-Leistungssteuerung für PUSCH bzw. PUCCH in FR1-Bändern und mindestens zwei CLPC-Schleifen für die Aufwärtsstrecken-Leistungssteuerung für PUSCH bzw. PUCCH in FR2-Bändern unterstützt.
  • Ein weiteres Beispiel (z.B. Beispiel 17) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B., eines der Beispiele 1-16), wobei die Schaltung so ausgebildet ist, dass sie einen PDSCH dekodiert, der durch einen PDCCH mit durch SI-RNTI verwürfeltem CRC und einem auf 1 gesetzten Systeminformationsindikator in DCI, RA-RNTI, MsgB-RNTI, P-RNTI, TC-RNTI, C-RNTI, MCS-C-RNTI, CS-RNTI oder PDSCHs mit SPS geplant ist, und die sich mit einer oder mehreren SS/PBCH-Blockübertragungsressourcen, halbstatisch konfigurierten Ressourcensätzen, dynamisch angezeigten Ressourcensätzen, konfigurierten PDCCH-CORESETs oder Planungs-PDCCH überschneiden, wobei davon ausgegangen wird, dass der PDSCH auf die überlappenden Ressourcen abgebildet, aber nicht übertragen wird.
  • Ein weiteres Beispiel (z.B. Beispiel 18) bezieht sich auf ein zuvor beschriebenes Beispiel (z.B. eines der Beispiele 1-17), wobei die Schaltung so ausgebildet ist, dass sie maximal einen oder zwei halbstatisch konfigurierte Ratenanpassungs-Ressourcensätze unterstützt, die mit einer RB-Symbolgranularität konfiguriert sind, und nicht mehr als zwei halbstatisch konfigurierte Ratenanpassungs-Ressourcensätze, die mit einer RE-Symbolgranularität konfiguriert sind.
  • Ein weiteres Beispiel (z. B. Beispiel 19) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. eines der Beispiele 1-18), wobei die Schaltung so ausgebildet ist, dass sie nur die PUCCH-Formate 0, 1 und 4 unterstützt.
  • Ein weiteres Beispiel (z. B. Beispiel 20) bezieht sich auf ein zuvor beschriebenes Beispiel (z. B. eines der Beispiele 1-19), wobei die Schaltung so ausgebildet ist, dass sie maximal einen PUCCH in einem Schlitz überträgt.
  • Die Aspekte und Merkmale, die zusammen mit einem oder mehreren der vorangehend detaillierten Beispiele und Figuren erwähnt und beschrieben sind, können auch mit einem oder mehreren der anderen Beispiele kombiniert werden, um ein gleiches Merkmal des anderen Beispiels zu ersetzen oder um das Merkmal in das andere Beispiel zusätzlich einzuführen.
  • Beispiele können weiterhin ein Computerprogramm, das einen Programmcode zum Ausführen eines oder mehrerer der vorangehenden Verfahren aufweist, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird, sein oder sich auf ein solches beziehen. Schritte, Operationen oder Prozesse von verschiedenen, vorangehend beschriebenen Verfahren können durch programmierte Computer oder Prozessoren ausgeführt werden. Beispiele können auch Programmspeicherungsvorrichtungen, wie beispielsweise Digitaldatenspeicherungsmedien, abdecken, die maschinen-, prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme von Anweisungen codieren. Die Anweisungen führen einige oder alle der Schritte der vorangehend beschriebenen Verfahren aus oder verursachen deren Ausführung. Die Programmspeichervorrichtungen können z. B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren oder Steuereinheiten, die zum Ausführen der Schritte der vorangehend beschriebenen Verfahren programmiert sind, oder (feld-)programmierbare Logik-Arrays ((F)PLAs; (Field) Programmable Logic Arrays) oder (feld-)programmierbare Gate-Arrays ((F)PGA; (Field) Programmable Gate Arrays), die zum Ausführen der Schritte der vorangehend beschriebenen Verfahren programmiert sind, abdecken.
  • Die Beschreibung und Zeichnungen stellen nur die Grundsätze der Offenbarung dar. Weiterhin sollen alle hierin aufgeführten Beispiele grundsätzlich ausdrücklich nur Lehrzwecken dienen, um den Leser beim Verständnis der Grundsätze der Offenbarung und der durch den (die) Erfinder beigetragenen Konzepte zur Weiterentwicklung der Technik zu unterstützen. Alle hiesigen Aussagen über Grundsätze, Aspekte und Beispiele der Offenbarung sowie konkrete Beispiele derselben sollen deren Entsprechungen umfassen.
  • Ein als „Mittel für...“ bezeichneter Funktionsblock, der eine bestimmte Funktion ausführt, kann sich auf eine Schaltung beziehen, die zum Ausführen einer bestimmten Funktion ausgebildet ist. Somit kann ein „Mittel für etwas“ als ein „Mittel ausgebildet für oder geeignet für etwas“ implementiert sein, wie beispielsweise ein Bauelement oder eine Schaltung, ausgebildet für oder geeignet für die jeweilige Aufgabe.
  • Funktionen verschiedener in den Figuren gezeigter Elemente einschließlich jeder als „Mittel“, „Mittel zum Bereitstellen eines Sensorsignals“, „Mittel zum Erzeugen eines Sendesignals“, etc. bezeichneter Funktionsblöcke kann in Form dedizierter Hardware, z. B „eines Signalanbieters“, „einer Signalverarbeitungseinheit“, „eines Prozessors“, „einer Steuerung“ etc. sowie als Hardware fähig zum Ausführen von Software in Verbindung mit zugehöriger Software implementiert sein. Bei Bereitstellung durch einen Prozessor können die Funktionen durch einen einzelnen dedizierten Prozessor, durch einen einzelnen gemeinschaftlich verwendeten Prozessor oder durch eine Mehrzahl von individuellen Prozessoren bereitgestellt sein, von denen einige oder von denen alle gemeinschaftlich verwendet werden können. Allerdings ist der Begriff „Prozessor“ oder „Steuerung“ bei Weitem nicht auf ausschließlich zur Ausführung von Software fähige Hardware begrenzt, sondern kann Digitalsignalprozessor-Hardware (DSP-Hardware; DSP = Digital Signal Processor), Netzprozessor, anwendungsspezifische integrierte Schaltung (ASIC = Application Specific Integrated Circuit), feldprogrammierbares Logik-Array (FPGA = Field Programmable Gate Array), Nurlesespeicher (ROM = Read Only Memory) zum Speichern von Software, Direktzugriffsspeicher (RAM = Random Access Memory) und nichtflüchtige Speichervorrichtung (storage) umfassen. Sonstige Hardware, herkömmliche und/oder kundenspezifische, kann auch umfasst sein.
  • Ein Blockdiagramm kann zum Beispiel ein detailliertes Schaltdiagramm darstellen, das die Grundsätze der Offenbarung implementiert. Auf ähnliche Weise können ein Flussdiagramm, ein Ablaufdiagramm, ein Zustandsübergangsdiagramm, ein Pseudocode und dergleichen verschiedene Prozesse, Operationen oder Schritte repräsentieren, die zum Beispiel im Wesentlichen in einem computerlesbaren Medium dargestellt und so durch einen Computer oder Prozessor ausgeführt werden können, ungeachtet dessen, ob ein solcher Computer oder Prozessor explizit gezeigt ist. In der Beschreibung oder in den Patentansprüchen offenbarte Verfahren können durch eine Vorrichtung implementiert werden, die Mittel zum Ausführen eines jeden der jeweiligen Schritte dieser Verfahren aufweist.
  • Es versteht sich, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Handlungen, Prozesse, Operationen, Schritte oder Funktionen nicht als in der bestimmten Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht explizit oder implizit anderweitig, zum Beispiel aus technischen Gründen, angegeben ist. Daher werden diese durch die Offenbarung von mehreren Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt, es sei denn, dass diese Schritte oder Funktionen aus technischen Gründen nicht austauschbar sind. Ferner kann bei einigen Beispielen ein einzelner Schritt, Funktion, Prozess oder Operation mehrere Teilschritte, -funktionen, -prozesse oder -operationen einschließen und/oder in dieselben aufgebrochen werden. Solche Teilschritte können umfasst sein und Teil der Offenbarung dieses Einzelschritts sein, sofern sie nicht explizit ausgeschlossen sind.
  • Weiterhin sind die folgenden Ansprüche hiermit in die detaillierte Beschreibung aufgenommen, wo jeder Anspruch als getrenntes Beispiel für sich stehen kann. Während jeder Anspruch als getrenntes Beispiel für sich stehen kann, ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen beziehen kann - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hier explizit vorgeschlagen, sofern nicht angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt abhängig von dem unabhängigen Anspruch gemacht ist.

Claims (20)

  1. Ein Benutzergerät (UE) mit reduzierten Fähigkeiten für drahtlose Kommunikationssysteme der fünften Generation (5G) des Third Generation Partnership Project (3GPP), das Folgendes umfasst: eine Schaltung, die so ausgebildet ist, dass sie Aufwärtsübertragungen (UL) sendet und Abwärtsübertragungen (DL) empfängt, wobei die Schaltung so ausgebildet ist, dass sie obligatorische Anforderungen für ein UE unterstützt, die entweder in der 5G-Spezifikation von 3GPP Release 15 oder Release 16 definiert sind, wobei eine oder mehrere der obligatorischen Anforderungen gelockert sind.
  2. Das UE nach Anspruch 1, wobei die Schaltung so ausgebildet ist, dass sie eine maximale Bandbreite von 20 MHz in DL bzw. UL in 5G-Frequenzbereich 1 (FR1) Bändern und eine maximale Bandbreite von 100 MHz in DL bzw. UL in 5G-Frequenzbereich 2 (FR2) Bändern unterstützt.
  3. Das UE nach Anspruch 1 oder 2, wobei die Schaltung so ausgebildet ist, dass sie 64-Quadratur-Amplitudenmodulation (64QAM) als höchste Modulationsordnung sowohl für einen gemeinsam genutzten physikalischen Downlink-Kanal (PDSCH) als auch für einen gemeinsam genutzten physikalischen Uplink-Kanal (PUSCH) unterstützt.
  4. Das UE nach Anspruch 3, wobei die Schaltung so ausgebildet ist, dass sie eine 64-QAM-Modulations- und Kodierungsschema (MCS)-Tabelle mit niedriger spektraler Effizienz (SE) unterstützt, die in Tabelle 5.1.3.1-3 in 3GPP TS 38.214 für den PDSCH und den PUSCH definiert ist, wenn eine zyklische Präfix-orthogonale Frequenzmultiplex (CP-OFDM)-Wellenform verwendet wird, und Tabelle 6.1.4.1-2 in 3GPP TS 38.214 für den PUSCH, wenn eine diskretes Fourier-Transformation-orthogonales Frequenzmultiplexen (DFT-S-OFDM) verwendet wird.
  5. Das UE nach Anspruch 4, wobei die Schaltung so ausgebildet ist, dass sie die in Tabelle 5.1.3.1-3 und Tabelle 6.1.4.1-2 in 3GPP TS 38.214 definierten Low-SE-64-QAM-MCS-Tabellen als obligatorische Anforderung unterstützt.
  6. Das UE nach einem der Ansprüche 1 bis 5, wobei die Schaltung so ausgebildet ist, dass sie nur eine diskrete Fourier-Transformations-Spreizungs-Orthogonal-Frequenzmultiplex (DFT-S-OFDM)-Wellenform für Physical Uplink Shared Channel (PUSCH)-Übertragungen unterstützt.
  7. Das UE nach einem der Ansprüche 1 bis 6, wobei die Schaltung so ausgebildet ist, dass sie nur die auf RRC-Signalisierung basierende Anpassung des Bandbreitenteils (BWP) unterstützt.
  8. Das UE nach Anspruch 7, wobei die Schaltung so ausgebildet ist, dass sie maximal einen UE-spezifisch ausgebildeten DL- oder UL-BWP zusätzlich zu einem anfänglichen DL- bzw. UL-BWP unterstützt.
  9. Das UE nach Anspruch 1-6, wobei das UE mit mehr als einem DL- oder UL-BWP durch eine höhere Schicht ausgebildet ist und die Schaltung so ausgebildet ist, dass sie einen gemeinsamen Satz von Werten für alle Parameter, die als Teil von BWP-Konfigurationen ausgebildet sind, auf alle oder eine Untermenge von ausgebildeten DL- oder UL-BWPs anwendet, mit Ausnahme von Werten für eine Mittenfrequenz und Bandbreite, BWP-Identität und Unterträgerabstand der ausgebildeten BWPs.
  10. Das UE nach einem der Ansprüche 1 bis 9, wobei, wenn sich das UE in den Modi RRC Connected, RRC Idle oder RRC Inactive befindet, die Schaltung so ausgebildet ist, dass sie zu jedem Zeitpunkt nur einen gemeinsam genutzten physikalischen Abwärtskanal (PDSCH) decodiert.
  11. Das UE nach einem der Ansprüche 1-10, wobei die Schaltung so ausgebildet ist, dass sie einen ersten gemeinsam genutzten physikalischen Abwärtskanal (PDSCH), der in einer bedienenden Zelle mit temporärer Zell-Funknetz-Identität (C-RNTI) oder temporärer Modulations- und Kodierungsschema-Zell-Funknetz-Identität (MCS-C-RNTI) geplant ist, und einen zweiten PDSCH, der in der bedienenden Zelle mit konfigurierter temporärer Planungs-Funknetz-Identität (CS-RNTI) geplant ist, nicht dekodiert, wenn der erste und der zweite PDSCH sich zeitlich teilweise oder vollständig überlappen.
  12. Das UE nach einem der Ansprüche 1 bis 11, wobei die Schaltung so ausgebildet ist, dass sie keine Aufwärtsstreckengewährung in einem Abwärtsstrecken-Kontrollinformationsformat (DCI) empfängt, das das UE anweist, einen dynamisch gewährten (DG) physikalischen Aufwärtsstrecken-Shard-Kanal (PUSCH) zu übertragen, der sich zeitlich mit einem anderen PUSCH überschneidet, der dynamisch oder durch eine höhere Schicht als Teil eines Typ-1- oder Typ-2-konfigurierten gewährten PUSCH gewährt wird.
  13. Das UE nach einem der Ansprüche 1-12, wobei die Schaltung so ausgebildet ist, dass sie nur PUSCH-Mapping Typ A unterstützt.
  14. Das UE nach einem der Ansprüche 1-13, wobei die Schaltung so ausgebildet ist, dass sie nur einen PDSCH-Empfang oder eine PUSCH-Übertragung in einem Schlitz unterstützt.
  15. Das UE nach einem der Ansprüche 1 bis 14, wobei die Schaltung so ausgebildet ist, dass sie eine geschlossene Leistungsregelschleife (CLPC) für die Leistungsregelung in der Aufwärtsrichtung für PUSCH bzw. PUCCH unterstützt.
  16. Das UE nach einem der Ansprüche 1 bis 15, wobei die Schaltung so ausgebildet ist, dass sie eine geschlossene Leistungsregelschleife (CLPC) für die Aufwärtsleistungsregelung für PUSCH bzw. PUCCH in FR1-Bändern und mindestens zwei CLPC-Schleifen für die Aufwärtsleistungsregelung für PUSCH bzw. PUCCH in FR2-Bändern unterstützt.
  17. Das UE nach einem der Ansprüche 1-16, wobei die Schaltung so ausgebildet ist, dass sie einen PDSCH dekodiert, der durch einen PDCCH mit zyklischer Redundanzprüfung (CRC) geplant ist, der durch eine temporäre Systeminformations-Funknetz-Identität (SI-RNTI) und einen Systeminformationsindikator in der Abwärtsstrecken-Kontrollinformation (DCI) verwürfelt ist, die auf 1 gesetzt ist, Random Access-Radio Network Temporary Identifier (RA-RNTI), MsgB-RNTI, Paging-RNTI (P-RNTI), Temporary Cell RNTI (TC-RNTI), Cell-RNTI (C-RNTI), Modulations- und Kodierungsschema-Zellen-RNTI (MCS-C-RNTI), konfigurierte Scheduling-RNTI (CS-RNTI) oder PDSCHs mit semi-persistentem Scheduling (SPS), die sich mit einer oder mehreren Synchronisationssignal/Physical Broadcast Channel (SS/PBCH)-Blockübertragungsressourcen überschneiden, halbstatisch ausgebildete Ressourcensätze, dynamisch angezeigte Ressourcensätze, konfigurierte PDCCH-Kontrollressourcensätze (CORESETs) oder PDCCH-Planung, wobei davon ausgegangen wird, dass der PDSCH auf die überlappenden Ressourcen abgebildet, aber nicht übertragen wird.
  18. Das UE nach einem der Ansprüche 1-17, wobei die Schaltung so ausgebildet ist, dass sie maximal einen oder zwei halbstatisch konfigurierte Ratenanpassungs-Ressourcensätze unterstützt, die auf einer Ressourcenblock (RB) -Symbol-Granularität ausgebildet sind, und nicht mehr als zwei halbstatisch konfigurierte Ratenanpassungs-Ressourcensätze, die auf einer Ressourcenelement (RE) -Symbol-Granularität ausgebildet sind.
  19. Das UE nach einem der Ansprüche 1-18, wobei die Schaltung so ausgebildet ist, dass sie nur die PUCCH-Formate 0, 1 und 4 unterstützt.
  20. Das UE nach einem der Ansprüche 1-19, wobei die Schaltung so ausgebildet ist, dass sie maximal einen PUCCH in einem Schlitz überträgt.
DE102021112377.1A 2020-05-15 2021-05-12 Benutzergeräte mit reduzierter Leistungsfähigkeit für Systeme der fünften Generation Pending DE102021112377A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063025839P 2020-05-15 2020-05-15
US63/025,839 2020-05-15

Publications (1)

Publication Number Publication Date
DE102021112377A1 true DE102021112377A1 (de) 2021-11-18

Family

ID=78280808

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021112377.1A Pending DE102021112377A1 (de) 2020-05-15 2021-05-12 Benutzergeräte mit reduzierter Leistungsfähigkeit für Systeme der fünften Generation

Country Status (1)

Country Link
DE (1) DE102021112377A1 (de)

Similar Documents

Publication Publication Date Title
DE112018003906T5 (de) Verfahren und Vorrichtung zur flexiblen Aufteilung der physikalischen Fronthaul-Schicht für Cloud-Funkzugangsnetze
DE112018000204T5 (de) Design für physischen Kurzdauer- und Langdauer-Neufunk-Uplink-Steuerkanal (Kurzdauer- und Langdauer-NR-PUCCH)
DE112018000164T5 (de) System und verfahren für phasenrauschkompensation
DE112020000825T5 (de) Betrieb von Benutzerendgerät in 5G NR Kommunikationssystem
DE102021109367A1 (de) Synchronisationssignal-multiplexing für drahtlos-systeme
DE112021002593T5 (de) Ratenanpassungsressourcen für übertragungen auf einem physischen gemeinsam genutztem downlink-kanal (pdsch) und multiplexen von uplink-übertragungen mit verschiedenen timings
DE102021119772A1 (de) Vorrichtungen und verfahren zum austausch mehrerer kleiner datenübertragungen (sdt) im inaktiven zustand des benutzergeräts
DE102021108923A1 (de) Diskontinuierlicher empfangsbetrieb über nr sidelink
DE102021118717A1 (de) Sidelink (sl) diskontinuierlicher empfang (drx) verfahren
DE102021112407A1 (de) Verfahren und Vorrichtung zur Positionierung eines Benutzergerätes
DE102021112311A1 (de) Unterstützung von bandbreitenbegrenzten benutzergeräten in neuer funk-systemen
DE102021112377A1 (de) Benutzergeräte mit reduzierter Leistungsfähigkeit für Systeme der fünften Generation
DE112021002457T5 (de) Techniken für die steuerkanalübertragung für einen schlitzlosen betrieb und planung von datenübertragungen
DE102021113836A1 (de) Benutzergerät, Netzwerkeinheit, Verfahren und Computerprogramm für die Kommunikation zwischen Fahrzeugen und anderen Objekten auf der Nebenstrecke
DE102020112050A1 (de) Verfahren, Computerprogramme und Vorrichtungen zur Konfiguration von Zeitressourcen und zur Bestimmung von Latenzzeiten, Zentraleinheit, Teileinheit und Infrastrukturknoten
DE102021114232A1 (de) Verfahren und Vorrichtung zur frühzeitigen Beendigung von Gemeinschaftlich-Verwendeter-Physischer-Downlink- oder -Uplink- Kanal-, Übertragungen
DE102021110664A1 (de) Verfahren und Vorrichtung zum Senden und Empfangen eines physikalischen Abwärtsstrecken-Steuerkanals und eines physikalsichen Abwärtsstrecken-Gemeinschaftskanals in einem drahtlosen Kommunikationssystem
DE102021124321A1 (de) Verbesserter physischer-uplink-steuerkanal-entwurf
DE102021126171A1 (de) Verfahren und vorrichtung zur datenübertragung unter verwendung eines physischen downlink-steuerkanals
DE102021103547A1 (de) Verfahren, Computerprogramm, Vorrichtung, Benutzergerät und Zugangsknoten zur Kommunikation in einem drahtlosen Kommunikationssystem
DE102021112596A1 (de) Auslöschungsverbesserung für uplink-übertragungen mit slotaggregation
DE102021126536A1 (de) Ermittlung der zeitlinie zwischen steuerungskanal und datenkanal für nr-operationen
DE102021103592A1 (de) Systeme, verfahren und geräte für sende- und empfangskanal (pdcch)
DE102021125778A1 (de) Gemeinsame kanalbelegungszeit für systeme, die über 52,6 ghz arbeiten
DE102021112480A1 (de) Verringerung der überwachung des physikalischen downlink-steuerungskanals für neuer funk-teilnehmergeräte