DE102021119772A1 - Vorrichtungen und verfahren zum austausch mehrerer kleiner datenübertragungen (sdt) im inaktiven zustand des benutzergeräts - Google Patents

Abstract

Vorrichtung eines Benutzergeräts (UE), wobei die Vorrichtung eine Funkfrequenz-(RF)-Schnittstelle und einen oder mehrere Prozessoren enthält, die mit der RF-Schnittstelle gekoppelt und so konfiguriert sind, dass sie: Ressourcen und Konfigurationen zum Übertragen einer Vielzahl von kleinen Datenübertragungspaketen (SDT) an eine Basisstation (BS) in einer SDT-Sitzung ermitteln, während das UE RRC_INACTIVE bleibt; und in der SDT-Sitzung, während das UE RRC_INACTIVE bleibt, ein erstes SDT-Paket der Vielzahl von SDT-Paketen unter Verwendung der bestimmten Ressourcen und Konfigurationen an die BS senden oder von ihr empfangen.

Description

• QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
• Die vorliegende Anmeldung beansprucht Priorität für die vorläufige US-Patentanmeldung Ser. Nr. US 63/058,399 , eingereicht am 29. Juli 2020 (AD1344) und die vorläufige US-Patentanmeldung Ser. Nr. 63/058,415 , eingereicht am 29. Juli 2020 (AD1352).
• HINTERGRUND
• Verschiedene Ausführungsformen können allgemein den Bereich der Drahtlos-Kommunikation betreffen.
• Figurenliste
• Verschiedene Aspekte der vorliegenden Offenbarung/Erfindung werden im Folgenden anhand verschiedener Ausführungsformen unter Bezugnahme auf die folgenden Zeichnungen erläutert. Die Figuren sind nicht unbedingt maßstabsgetreu gezeichnet. In den Figuren sind gleiche oder ähnliche Komponenten mit den gleichen Bezugszeichen versehen.
• 1 zeigt ein Logik-Flussdiagramm, das kleine Datenübertragungen (SDT) in RRC_INACTIVE gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 2 veranschaulicht ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 1.
• 3 zeigt ein weiteres Logik-Flussdiagramm, das kleine Datenübertragungen (SDT) in RRC_INACTIVE gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 4 zeigt ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 3.
• 5 veranschaulicht ein Logik-Flussdiagramm, das mehrere kleine Datenübertragungen (SDT) in RRC_INACTIVE gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 6 veranschaulicht ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 5.
• 7 zeigt ein weiteres Logik-Flussdiagramm, das mehrere kleine Datenübertragungen (SDT) in RRC_INACTIVE gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 8 zeigt ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 7.
• 9 zeigt ein Logik-Flussdiagramm, das die Anforderung oder Freigabe einer vorkonfigurierten Uplink-Ressourcenkonfiguration (PUR) gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung darstellt.
• 10 veranschaulicht ein Logik-Flussdiagramm, das kleine Datenübertragungen (SDT) in RRC_INACTIVE unter Verwendung vorkonfigurierter Ressourcen gemäß einer oder mehrerer Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 11 zeigt ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 10.
• 12 zeigt ein weiteres Logik-Flussdiagramm, das kleine Datenübertragungen (SDT) in RRC _INACTIVE unter Verwendung vorkonfigurierter Ressourcen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 13 zeigt ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 12.
• 14 veranschaulicht ein Logik-Flussdiagramm, das mehrere kleine Datenübertragungen (SDT) in RRC_INACTIVE unter Verwendung vorkonfigurierter Ressourcen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 15 zeigt ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen der 14.
• 16 zeigt ein weiteres Logik-Flussdiagramm, das mehrere kleine Datenübertragungen (SDT) in RRC _INACTIVE unter Verwendung vorkonfigurierter Ressourcen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung bereitstellt.
• 17 zeigt ein vereinfachtes Verkehrsflussdiagramm des Sendens von zwei Uplink-Datenpaketen gemäß einer oder mehreren Ausführungsformen von 16.
• 18 veranschaulicht ein Netzwerk gemäß verschiedenen Ausführungsformen.
• 19 zeigt schematisch ein Drahtlos-Netzwerk gemäß verschiedenen Ausführungsformen.
• 20 ist ein Blockdiagramm, das Komponenten gemäß einigen Ausführungsbeispielen veranschaulicht, 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.
• DETAILLIERTE BESCHREIBUNG
• Die folgende detaillierte Beschreibung bezieht sich auf die beigefügten Zeichnungen. Die gleichen Referenznummern können in verschiedenen Zeichnungen verwendet werden, um gleiche oder ähnliche Elemente zu identifizieren. In der folgenden Beschreibung werden zum Zwecke der Erläuterung und nicht der Einschränkung spezifische Details wie bestimmte Strukturen, Architekturen, Schnittstellen, Techniken usw. dargelegt, um ein gründliches Verständnis der verschiedenen Aspekte der verschiedenen Ausführungsformen zu ermöglichen. Es wird jedoch für den Fachmann, der die Vorteile der vorliegenden Offenbarung/Erfindung kennt, offensichtlich sein, dass die verschiedenen Aspekte der verschiedenen Ausführungsformen in anderen Beispielen, die von diesen spezifischen Details abweichen, praktiziert werden können. In bestimmten Fällen werden Beschreibungen bekannter Vorrichtungen, Schaltungen und Verfahren weggelassen, um die Beschreibung der verschiedenen Ausführungsformen nicht durch unnötige Details zu verdunkeln. Für die Zwecke des vorliegenden Dokuments bedeuten die Ausdrücke „A oder B“ und „A/B“ (A), (B) oder (A und B).
• Das RRC-Protokoll (Funkressourcensteuerung) ist ein Protokoll der Schicht 3 (Netzwerkschicht), das vom Dritte Generation Partnerschaftsprojekt (3GPP) definiert wurde. Es wird in Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE) und 5G (oder Neuer Funk (NR)) an der Luftschnittstelle zwischen einem Benutzergerät (UE) (z.B. einem Smartphone) und einer Basisstation verwendet. Das RRC-Protokoll umfasst Funktionen für den Verbindungsaufbau und die Verbindungsfreigabe, die Übertragung von Systeminformationen, die Einrichtung, Rekonfiguration und Freigabe von Funkträgern, Verfahren für die RRC-Verbindungsmobilität, die Benachrichtigung über Funkrufe und deren Freigabe sowie die Steuerung der äußeren Schleifenleistung. Mit Hilfe der Signalisierungsfunktionen konfiguriert die RRC die Benutzer- und Steuerungsebene entsprechend dem Netzwerkstatus.
• Der Betrieb der RRC wird durch einen Zustandsautomaten gesteuert, der bestimmte Zustände eines UE definiert. Den verschiedenen Zuständen in diesem Zustandsautomaten sind unterschiedliche Mengen an Funkressourcen zugeordnet, die das UE nutzen kann, wenn es sich in einem bestimmten Zustand befindet. Da in den verschiedenen Zuständen unterschiedliche Mengen an Ressourcen zur Verfügung stehen, werden die Dienstqualität für den Benutzer und der Energieverbrauch des UE durch diesen Zustandsautomaten beeinflusst.
• Ein UE muss im Allgemeinen in einen RRC-Verbindungszustand (d.h. RRC_CONNECTED) übergehen, um Uplinkdaten (UL) zu senden. In einigen der neuesten Verbesserungen für LTE und der Diskussion in NR kann ein UE ein einzelnes Paket/Protokolldateneinheit (PDU) senden, während sich das UE in einem RRC-Idle-Zustand (d.h. RRC_IDLE) mit Suspend-Anzeige oder in RRC_IDLE befindet. Es gibt jedoch keinen definierten oder diskutierten Mechanismus für ein UE in einem RRC inaktiven Zustand (d.h. RRC_INACTIVE), mehrere Datenpakete/PDUs auszutauschen (z.B. ohne dass das UE immer in RRC_CONNECTED übergehen muss).
• Da sich neue NR-Anwendungsfälle entwickeln und weiterentwickeln, sollten Verbesserungen in Betracht gezogen werden, die über den ursprünglichen NR-Designrahmen hinausgehen. Insbesondere gibt es mehrere Anwendungsfälle, in denen ein UE mehrere kleine und seltene Datenübertragungen mit potenziell langen Inaktivitätsperioden dazwischen durchführen muss. Einige konkrete Beispiele sind:
• - Smartphone-Anwendungen:
  • ◯ Datenverkehr von Instant-Messaging-Diensten (Whatsapp, QQ, Wechat usw.)
  • ◯ Heartbeat-/Keep-alive-Datenverkehr von IM-/E-Mail-Clients und anderen Anwendungen
  • ◯ Push-Benachrichtigungen von verschiedenen Anwendungen
• - Nicht-Smartphone-Anwendungen:
  • ◯ Datenverkehr von Wearables (periodische Positionsdaten usw.)
  • ◯ Sensoren (industrielle Drahtlos-Sensornetzwerke, die regelmäßig oder ereignisgesteuert Temperatur- und Druckmesswerte übermitteln usw.)
  • ◯ intelligente Zähler und intelligente Zählernetze, die regelmäßig Zählerstände senden
• 3GPP Rel-15 definierte Frühe Datenübertragung (EDT) für LTE erweiterte MaschinenTyp-Kommunikation (eMTC) und Schmalband Internet der Dinge (NB-IoT). Dies ermöglicht eine UL-Datenübertragung, optional gefolgt von einer Downlink-Datenübertragung (DL) während des Random-Access-Verfahrens. Die S1-Verbindung wird beim Empfang der UL-Daten aufgebaut oder wieder aufgenommen und kann zusammen mit der Übertragung der DL-Daten freigegeben oder unterbrochen werden. EDT bezieht sich sowohl auf Steuerungsebene(CP)-EDT als auch auf Benutzerebene(UP)-EDT (wobei UP-EDT für Rel-17 NR SDT WI relevant ist). Der Rel-15 EDT-Mechanismus ist als Teil von TS 36.300 und TS 36.331 spezifiziert.
• 3GPP Rel-16 definierte Vorkonfigurierte-Uplink-Ressource (PUR) für LTE eMTC und NB-IoT. Die Übertragung unter Verwendung von PUR ermöglicht eine UL-Datenübertragung unter Verwendung vorkonfigurierter Uplink-Ressourcen aus dem RRC_IDLE-Modus. Die Übertragung mit PUR bezieht sich sowohl auf die CP-Übertragung mit PUR als auch auf die UP-Übertragung mit PUR (wobei die UP-Übertragung mit PUR für Rel-17 NR SDT WI relevant ist). Der Rel-16 PUR-Mechanismus ist als Teil von TS 36.300, 36.321 und 36.331 spezifiziert.
• Kleine Datenübertragungen (SDT) wurde während Rel-14 NR SI diskutiert. Lösungsdetails mit und ohne RRC-Signalisierung wurden in einigen E-Mail-Diskussionen (R2-1700626, R2-1700185 und R2-1701125) darüber diskutiert, wie SDT/Pakete von dem UE in RRC_INACTIVE ausgetauscht werden können, aber RAN2 hat dies in Rel-14/15/16 NR nicht weiter verfolgt. Anhang G von TR 38.804 enthält eine detaillierte Beschreibung eines Mechanismus, der die Übertragung kleiner UL-Daten in RRC_INACTIVE ermöglicht (dies bezieht sich auf eine Funktion, bei der ein UE in RRC _INACTIVE kleine UL-Daten übertragen kann, ohne notwendigerweise einen vollständigen Zustandsübergang zu RRC_CONNECTED durchzuführen).
• Die neue 3GPP Rel-17 enthält kleine Datenübertragungen (SDT) in RRC_INACTIVE als ein Arbeitselement (WI) zu NR. Das neue WID wurde im Dezember 2019 vereinbart (RP-193252) und soll im August 2020 starten. Die Begründung für SDT in RRC _INACTIVE als WI in Rel-17 umfasst: Reduzierung des Signalisierungs-Overheads und des Stromverbrauchs für kleinen und seltenen Datenverkehr, für Smartphone-Anwendungen (z.B. IM, Keep Alive, Push-Benachrichtigungen) und Nicht-Smartphone-Anwendungen (z.B. Wearables, Sensoren, Smart Meter). Die Ziele von SDT in RRC _INACTIVE als WI in Rel-17 beinhalten:
• ◯ UL-Kleindatenübertragungen für RACH-basierte Schemata (z.B. 2-Schritt und 4-Schritt RACH)
  • ▪ Verfahren zur Aktivierung der UP-Datenübertragung für kleine Datenpakete aus dem INACTIVE-Zustand (z.B. unter Verwendung von MSGA oder MSG3)
  • ▪ Ermöglichung flexibler Nutzdatengrößen, die größer sind als die Rel-16 CCCH-Nachrichtengröße, die derzeit für den INACTIVE-Zustand für MSGA und MSG3 möglich ist (die tatsächliche Nutzdatengröße kann von der Netzwerkkonfiguration abhängen)
  • ▪ Kontextabruf und Datenweiterleitung (mit und ohne Ankerverschiebung) im INACTIVE-Zustand für RACH-basierte Lösungen
• ◯ Übertragung von UL-Daten auf vorkonfigurierten Physikalischer-Uplink-Geteilter-Kanal(PUSCH)-Ressourcen (z.B. Wiederverwendung des konfigurierten Grant-Typs 1) - wenn TA gültig ist
  • ▪ Allgemeines Verfahren für die Übertragung kleiner Datenmengen über konfigurierte Grant-Typ-1-Ressourcen aus dem INACTIVE-Zustand
  • ▪ Konfiguration der konfigurierten Grant-Typ-1-Ressourcen für die Übertragung kleiner Datenmengen in UL im INACTIVE-Zustand
• Frühere Lösungen, wie oben erläutert, erlauben nicht die Übertragung mehrerer Pakete/PDUs, während sich das UE im RRC_INACTIVE-Zustand befindet, wodurch die Flexibilität einer solchen Funktion eingeschränkt wird.
• Die vorliegende Offenbarung bietet und definiert neue Mechanismen für ein UE im Zustand RRC_INACTIVE, um mehrere Daten- oder Signalisierungspakete/PDUs auszutauschen, ohne dass das UE in den Zustand RRC_CONNECTED übergehen muss. Einige der wichtigsten neuen Konzepte sind:
• - (1) Beibehaltung der Zustände und Konfigurationen der Benutzerebene in der Zugangsschicht, wenn sich das UE nicht im Verbindungszustand befindet (z.B. „RRC_CONNECTED“)
• - (2) Ein UE im Zustand RRC _INACTIVE kann u. a. dadurch gekennzeichnet sein, dass (a) der Zustand der Nutzerebene beibehalten wird, (b) der physikalische Downlink-Kontrollkanal (PDCCH) für den dedizierten Radio Network Temporary Identifier (RNTI) überwacht wird oder (c) ein Teil der Konfigurationen verwendet/fortgesetzt wird, die im UE konfiguriert wurden, während es zuvor RRC_CONNECTED war.
• - (3) Aufgrund der Änderungen im RRC_INACTIVE-Zustand kann ein neuer Zustand bereitgestellt werden, der hier als „RRC_INACTIVE plus“ bezeichnet wird. Weitere neue Aspekte werden im Folgenden beschrieben:
• - (4) Neue Bedingungen, die für ein UE in RRC _INACTIVE zu berücksichtigen sind, um festzustellen, ob die SDT-Funktion verwendet werden kann.
• - (5) Es werden neue UL-Benachrichtigungen für ein UE beschrieben, um dem Netzwerk anzuzeigen oder mitzuteilen, wenn mehrere SDT darauf warten, gesendet zu werden.
• - (6) Ermöglichung der Nutzung von konfigurierten Erteilt-Ressourcen, die in RRC_CONNECTED bereitgestellt werden, für SDT durch ein UE in RRCINACTIVE.
• - (7) Neue Möglichkeiten zur Rekonfiguration eines UE in RRC INACTIVE.
• - (8) Neuer Mechanismus ähnlich der RRC-Wiederherstellung, der es einem UE in RRC INACTIVE mit laufender SDT ermöglicht, den Verlust der Abdeckung zu behandeln.
• - (9) Meldung von UE-Messungen, während sich ein UE in RRC_INACTIVE befindet.
• Die hier beschriebenen Ausführungsformen ermöglichen es dem UE, ein größeres Datenpaket zu senden, als die Nachricht 3/msg A/PUR unterstützen kann, während es sich in RRC INACTIVE befindet und ohne Übergang zu RRC_CONNECTED. Die Vorteile der Zulassung dieser Mechanismen bestehen darin, dass sie eine vereinfachte Version des Wiederaufnahmeverfahrens ermöglichen, bei dem das UE nicht die gesamte ausgesetzte Konfiguration, die im AS-Kontext des UE gespeichert ist, wieder aufnehmen (oder sogar neu konfigurieren) muss. Das UE muss also nicht alle Funktionen und Konfigurationen unterstützen oder aktivieren, die mit einem UE in RRC_CONNECTED verbunden sind (z.B. Ausfall der Funkverbindung (RLF), Mobilität/Handover, Wiederherstellung, Trägeraggregation(Carrier Aggregation - CA)/Zweifach-Konnektivität (Dual Connectivity - DC), Mehrfach-Eingabe-Mehrfach-Ausgabe(Multiple-Input-Multiple-Output - MIMO), Meldung der Kanalqualität, Wechsel des Bandbreitenteils (BWP), Betrieb/Konfiguration usw.).
• Die folgenden allgemeinen Grundsätze gelten für die gesamte Offenbarung. Diese Grundsätze fassen Aspekte zusammen, die auf die in dieser Offenbarung beschriebenen Mechanismen anzuwenden sind:
• - Die Figuren oder Mechanismen gehen von einem 4-schrittigen Zufallszugriffskanal (RACH) aus, sie können jedoch auch auf einen 2-schrittigen RACH anwendbar sein. Wenn der zu übertragende SDT möglicherweise mehrere Pakete/PDUs erfordert (d.h. N > 1, N ist eine ganze Zahl), weiß der 2-Schritt-RACH dies bereits vor der ersten Übertragung, da das UE die für die MsgA zulässige Transportblockgröße (TBS) kennt. Daher weiß das UE, ob es N > 1 benötigt, wenn es die erste RRC-Nachricht (z.B. RRCResumeRequest) generiert, und daher kann das UE in seinem ersten SDT angeben, ob es N > 1 benötigt (z.B. über diese oder eine andere RRC-Nachricht oder durch Multiplexen eines Pufferstatusberichts (BSR) oder eine andere Form der Angabe). Im Gegensatz zu 4-Schritt-RACH hängt dies von der UL Grant Size ab, die dem UE von der Basisstation (z.B. gNB) über die Random Access Response (RAR) mitgeteilt wird.
• - Die Figuren bzw. der Mechanismus gehen davon aus, dass zunächst ein UL SDT ausgelöst wird, sie können jedoch auch anwendbar sein, wenn ein DL SDT die Initiierung auslöst.
• - Die hier beschriebenen neuen Mechanismen zielen darauf ab, nachfolgende N Übertragungen von UL SDT und M Übertragungen von DL SDT zu ermöglichen, während das UE im INAKTIV-Zustand verbleibt, wobei N und M eine beliebige ganze Zahl größer oder gleich 0 sein können, obwohl die Lösungen der Einfachheit halber N und M gleich 2 setzen können.
• - Die UL- oder DL-SDT bezieht sich sowohl auf Daten als auch auf die Signalisierung (einschließlich z.B. Mediumzugriffssteuerung(Medium Access Control - MAC) Steuerelemente (Control Elements - CEs) oder RRC-Nachrichten), die zwischen dem UE und dem Netzwerk ausgetauscht werden. Daher geht der SDT-Mechanismus davon aus, dass es möglich ist, jegliche Signalisierung (die über Signalisierungsfunkträger (SRB) einschließlich SRB0, SRB1 oder SRB2 gesendet wird) und/oder Daten (die über einen dedizierten Funkträger (DRB) gesendet werden) zu multiplexen.
• - Die Figuren oder Mechanismen gehen davon aus, dass der UE Access Stratum (AS)-Kontext erfolgreich zum neuen gNB verlagert wird, sie können jedoch auch anwendbar sein, wenn der UE AS-Kontext nicht verlagert werden muss. Darüber hinaus können in einigen Fällen die Interaktionen mit der vorherigen gNB und der Zugriff- und Mobilitäts-Management-Funktion (Access and Mobility Management Function - AMF) der Einfachheit halber nicht dargestellt werden, um sich auf die Aspekte der Funkschnittstelle zu konzentrieren.
• - Die hier beschriebenen neuen Mechanismen konzentrieren sich darauf, SDT zu ermöglichen, während sich das UE in RRC_INACTIVE befindet. Es sollte jedoch jederzeit möglich sein, dass das UE in RRC_CONNECTED übergeht, wenn es zurückfällt, um eine RRC-Verbindung wieder aufzunehmen und eine neue RRC-Verbindung aufzubauen. Das heißt, während des SDT-Betriebs kann das UE als immer noch in RRC _INACTIVE oder alternativ in einem anderen Zustand betrachtet werden, z.B. „RRC INACTIVE limbo“ oder „RRC_INACTIVE plus“ oder „PSEUDO-INACTIVE“ unter anderen, um den Übergangszustand darzustellen, wenn das UE nicht vollständig in RRC _INACTIVE oder in RRC_CONNECTED ist.
• - Die neuen Mechanismen gehen davon aus, dass RRC-Signalisierung (z.B. RRCResumeRequest und RRCRelease) beim Austausch der SDT beteiligt ist, jedoch könnten ähnliche Operationen auch ohne diese RRC-Signalisierung ermöglicht werden, z.B. wenn das UE auf die Zelle zugreift, in der das UE AS-Kontext gespeichert wurde (die hier als „letzte gNB“ bezeichnet wird, aber auch als „Anker-gNB“ bezeichnet werden kann). Der Zustand RRC INACTIVE ist ein Zustand, in dem ein UE in CM-CONNECTED verbleibt und sich innerhalb eines von NG-RAN konfigurierten Bereichs (der RNA) bewegen kann, ohne NG-RAN zu benachrichtigen. In RRC _INACTIVE behält der letzte versorgende gNB-Knoten den UE-Kontext und die UE-assoziierte NG-Verbindung mit der versorgenden AMF und UPF.
• - Wenn der letzte bedienende gNB-Knoten DL-Daten von der UPF oder DL-UE-assoziierte Signalisierung von der AMF (außer der UE Context Release Command-Nachricht) empfängt, während sich das UE in RRC_INACTIVE befindet, blättert er in den Zellen, die der RNA entsprechen, und kann XnAP RAN Paging an Nachbar-gNB(s) senden, wenn die RNA Zellen von Nachbar-gNB(s) umfasst.
• - Nach dem Empfang der UE Context Release Command-Nachricht, während sich das UE im RRC INACTIVE-Zustand befindet, kann die zuletzt versorgende gNB die Zellen, die dem RNA entsprechen, ausrufen und XnAP RAN Paging an die Nachbar-gNB(s) senden, wenn der RNA Zellen von Nachbar-gNB(s) enthält, um die UE explizit freizugeben.
• - Der UL/DL SDT gehört zu einem einzelnen Radio Bearer (RB), z.B. SRB1 (für Non-Access Stratum (NAS) PDU) oder DRB (für Daten-PDU), der bereits eingerichtet wurde (als das UE zuvor RRC_CONNECTED war) und ausgesetzt wird, während sich das UE in RRC INACTIVE befindet.
• - Die hier für RACH definierten Mechanismen sind auch auf den Mechanismus anwendbar, der für die Handhabung des Austauschs kleiner Daten durch ein UE in RRC_INACTIVE unter Berücksichtigung der Architektur der Zentralisierten Einhei (Centralized Unit - CU) Verteilten Einheit (Distributed Unit - DU) und für die Ermöglichung der mehrfachen UL- und DL-Small-Data-Transmission (SDT) unter Verwendung vorkonfigurierter UL-Ressourcen (PUR) während des INACTIVE-Zustands beschrieben ist, und umgekehrt. Das heißt, die vorgeschlagenen Lösungen, die es dem UE ermöglichen, Daten im RRC INACTIVE-Zustand auszutauschen, sollen auch dann funktionieren, wenn DU und CU sich an einem gemeinsamen Standort befinden oder nicht, und auch dann, wenn der AS-Kontext der UE für oder während des SDT-Betriebs verlagert werden kann oder nicht.
• In den folgenden Unterabschnitten werden neue Mechanismen beschrieben, die sowohl für die als Szenario (0-A) und (0-B) beschriebenen Szenarien als auch für die hier beschriebenen Szenarien (1) und (2) gelten könnten.
• Wie das UE in RRC _INACTIVE ermittelt, ob es SDT verwendet oder nicht
• Die Entscheidung, ob ein UE SDT auslöst oder ob es die RRC-Verbindung wieder aufnimmt/aufbaut, um RRC_CONNECTED zu erhalten (wie in den folgenden Szenarien erläutert), kann von der Entscheidung/Implementierung des UE abhängen. Damit ein UE die Verwendung von SDT in Erwägung ziehen kann, müssen jedoch bestimmte Bedingungen erfüllt sein, die das UE zumindest wie unten dargestellt erfüllen muss. Beachten Sie, dass es einige Bedingungen gibt, die bereits für LTE EDT ähnliche Funktion berücksichtigt wurden, und andere neue in dieser Offenbarung/Erfindung zu berücksichtigen sind.
1. 1. Das UE und das Netz müssen die Verwendung der SDT-Funktion unterstützen/erlauben.
2. 2. Das UE kann so konfiguriert (oder zugelassen) werden, dass es das SDT-Merkmal über eine entsprechende Anzeige oder Konfiguration verwendet, die vom Netz über dedizierte oder Broadcast-Signalisierung bereitgestellt wird. Daher kann das UE auf UE-Basis (d. h. über Unicast) aktiviert/deaktiviert werden. Dies könnte z. B. bei der Verwendung vorkonfigurierter UL-Ressourcen für SDT eine wünschenswerte Funktion sein. Wenn die SDT-Kriterien/Informationen von Zelle zu Zelle unterschiedlich wären, würde dies höchstwahrscheinlich über Broadcast bereitgestellt werden.
3. 3. Die Spezifikation könnte festlegen, welche Zugangskategorie für SDT verwendet werden kann (z. B. könnte LTE EDT nur für MO-Anrufe ausgelöst werden, deren Resume-Cause-Werte auf mo-Data oder mo-ExceptionData oder delayTolerantAccess gesetzt sind). Als mögliche neue Bedingung könnte eine neue Zugangskategorie speziell für SDT oder sogar zur Unterscheidung von Small Signalling Transmission (SST) definiert werden.
4. 4. Das UE muss sich in RRC_INACTIVE befinden und einen gültigen UE AS Context gespeichert haben.
5. 5. Die Größenbeschränkung bezieht sich auf die Verwendung der SDT-Funktion. Zum Beispiel definiert LTE EDT eine maximale TBS (edt-TBD broadcasted via SI), die den ersten SDT begrenzt.
• Als potenzielle neue Bedingung für NR kann eine zusätzliche Angabe der zulässigen maximalen Größe für den nachfolgenden SDT, der durchgeführt wird, während sich ein UE in RRC _INACTIVE befindet, oder der Anzahl der nachfolgenden SDT, die durchgeführt werden, während sich ein UE in RRC _INACTIVE befindet, erfolgen.
• 6. Bei der Durchführung von SDT sollte das Netz das UE nicht dazu veranlassen oder ihm angezeigt werden, zurückzufallen, um eine RRC-Verbindung wieder aufzunehmen oder aufzubauen.
• 7. Als mögliche neue Bedingung kann es für eine UE erforderlich sein, einen spezifischen DRB einzurichten/zu konfigurieren, der es der UE ermöglicht, SDT auszulösen und/oder zu differenzieren.
• Wie die UE in RRC INACTIVE dem Netz mitteilt oder anzeigt, dass mehrere SDTs darauf warten, ausgetauscht zu werden
• Wenn ein UE in RRC INACTIVE die Verwendung der SDT-Funktion auslösen möchte, gibt es verschiedene Möglichkeiten, wie ein UE dem Netzwerk anzeigen kann, dass mehr als eine Übertragung oder ein Austausch erforderlich ist. Im Folgenden sind einige der Möglichkeiten aufgeführt, wie ein UE dem Netzwerk die UL-Benachrichtigung über die Menge an UL-SDT anzeigen könnte (es ist zu beachten, dass einige Anzeigen bereits für LTE-EDT- oder PUR-Funktionen berücksichtigt wurden und andere in dieser Offenbarung neu sind).
1. 1. BSR-Wiederverwendung oder Aktualisierung bestehender BSR-Angaben.
2. 2. Als neue UL-Anzeige kann eine neue Form der SDT-bezogenen Anzeige über die Größe der Daten im Puffer des UE gespeichert werden
3. 3. Als neue UL-Angabe eine neue Form der SDT-bezogenen Angabe über die Anzahl der Teilpakete (oder SDT-Austausche), die das UE benötigt, um die im Puffer des UE gespeicherten Daten zu übertragen.
4. 4. Als neue UL-Anzeige eine neue Form der SDT-bezogenen Anzeige, die als allgemeiner Hinweis darauf definiert ist, dass in seinem UL-Puffer weitere Daten zum Senden bereitstehen.
• Jede der oben genannten Meldungen kann als Teil einer neuen oder bestehenden RRC-MSG, MAC-CE oder des Headers der Datennutzlast enthalten sein.
• Das Netzwerk kann anhand einer dieser verschiedenen Anzeigen ermitteln, ob ein UE
1. (a) mehrere SDT austauschen darf, während es sich in RRC_INACTIVE befindet, oder
2. (b) ob es in RRC_CONNECTED überführt werden darf oder (c) ob es den SDT-Betrieb nicht nutzen oder fortsetzen darf.
• Neue Eigenschaften eines UE in RRC INACTIVE, das SDT austauscht
• Ein UE in RRC_INACTIVE, das das SDT-Merkmal unterstützt, kann durch eines der folgenden neuen Verhaltensweisen gekennzeichnet sein:
1. 1. Um SDT auszutauschen, nimmt das UE nur einen Teil der gespeicherten Konfigurationen innerhalb des UE AS Context wieder auf. Welcher Teil der gespeicherten Konfiguration für SDT wiederaufgenommen wird, könnte in der Spezifikation festgelegt und/oder vom Netzwerk für das UE konfiguriert werden.
2. 2. Als neues Verhalten für den Austausch von SDT nimmt das UE Standardkonfigurationen oder vom Netzwerk vorkonfigurierte Konfigurationen wieder auf (die in der Spezifikation definiert oder dem UE z.B. über den SIB oder im Zustand RRC_CONNECTED oder bei der Freigabe bereitgestellt werden können).
3. 3. Ein neues Verhalten ist, dass die UE, wenn sie in den Zustand RRC_INACTIVE versetzt wird, den Zustand und/oder die Konfigurationen z.B. für RLC und/oder das Paketdatenkonvergenzprotokoll (PDCP) und/oder RRC und/oder Funkträger und/oder PHY beibehält. Beibehalten bedeutet, dass die UE sie nicht aussetzt, ähnlich wie es bei SRB0 der Fall ist.
• Szenario (RACH-0): UL/DL SDT durch eine UE in RRC INACTIVE als Basis auf der Grundlage von LTE/NR-bezogenen Arbeiten
• Das Szenario (RACH-0) dient als Hintergrund-/Basisreferenz unter Berücksichtigung ähnlicher, in NR und LTE diskutierter/spezifizierter Mechanismen.
• Szenario (RACH-0-A): UL/DL SDT durch ein UE in RRC INACTIVE
• 1 zeigt ein Flussdiagramm des Basisszenarios/Mechanismus von Szenario (0-A), das während der NR-Diskussionen in Betracht gezogen wurde, um kleine Datenübertragungen (SDT) in RRC _INACTIVE zu ermöglichen (ähnlich wie bei der LTE-EDT-Funktion).
• Die Details zu den Schritten des in 1 dargestellten Szenarios (RACH-0-A) werden im Folgenden beschrieben:
• - Schritt 101) Das UE 10 sollte in der Lage sein, das Netzwerk (z.B. gNB 20) zu informieren oder anzuzeigen, wenn sich das UE SDT austauschen möchte, z.B. durch Verwendung unterschiedlicher RACH-Präambeln und/oder RACH-Ressourcen (zeitlich und/oder frequenzmäßig).
• - Schritt 102) Das Netzwerk (z.B. gNB 20) sollte in der Lage sein, dem UE 10 mitzuteilen, ob der SDT mit der entsprechenden TBS-Größe für seinen folgenden UL-SDT akzeptiert wird. Dies kann durch die Erweiterung der bestehenden RAR (z.B. durch die Verwendung eines der reservierten Bits, die die Akzeptanz von SDT anzeigen, wie es bei LTE EDT der Fall war) oder durch andere Mittel, wie die Definition einer neuen RAR wie einer Nachricht für SDT, erfolgen.
• - Schritt 103) Eine RRC-Nachricht (wie z.B. RRCResumeRequest) wird von dem UE 10 über SRB0 unverschlüsselt oder mit Integritätsschutz gesendet und enthält mindestens die UE-ID (z.B. Resume-ID), MAC-I und möglicherweise den Ursachenwert. Diese RRC-Nachricht könnte mit anderen Signalen (die über SRB1/2 gesendet werden) oder Daten (die über DRB gesendet werden) gemultiplext werden, die jedoch chiffriert und mit den Sicherheitsschlüsseln geschützt werden, die vom Nächster-Sprung-Verkettungs-Zähler (Next hop Chaining Counter - NCC) generiert werden, der in einer früheren RRCRelease-Nachricht bereitgestellt wurde. Die Sicherheit muss vor der Dekodierung dieser UL-Daten oder Signalisierung hergestellt werden.
• Bei Bedarf ruft die gNB 20 den AS-Kontext des UE von dem gNB 30 ab, bei dem er gespeichert war (in der Figur als „letzter gNB“ bezeichnet). Bezugnehmend auf 1 ruft der aktuelle gNB 20 den UE AS-Kontext von dem letzten gNB 30 ab.
• - Schritt 104) Wenn UL SDT erfolgreich ist und die RRC-Verbindung nicht wieder aufgenommen werden muss, wird eine RRC-Nachricht (wie z.B. RRCRelease) von dem gNB verschlüsselt und integritätsgeschützt über SRB1 an das UE gesendet, um das UE in RRC _INACTIVE zu halten und gleichzeitig aktualisierte Informationen zu liefern, wie z.B. suspendConfig (die u.a. einen neuen nextHopChainingCount (NCC) enthält, der in Zukunft z.B. bei SDT oder bei der Wiederaufnahme verwendet werden kann). Diese RRC-Nachricht könnte mit anderen Signalen oder Daten, die gesendet werden, gemultiplext werden (wobei alle mit den Sicherheitsschlüsseln, die durch den in einer früheren RRCRelease-Nachricht bereitgestellten NCC generiert wurden, verschlüsselt und integer geschützt würden).
• Wenn mehr als ein UL(/DL) SDT über das Szenario (RACH-0-A) ausgetauscht werden muss, werden die zusätzlichen SDTs als aufeinanderfolgende unabhängige Übertragungen behandelt. 2 zeigt ein vereinfachtes Flussdiagramm des erwarteten Vorgangs zum Senden von 2 UL-Datenpaketen über den in Szenario (RACH-0-A) dargestellten Mechanismus. 2 zeigt die Schlüsseloperation des UE zum Senden von 2 UL-Datenpaketen über den in Szenario (RACH-0-A) dargestellten Mechanismus. Es ist wichtig zu betonen, dass dieser Ansatz keine Segmentierung zulässt (da die Funkverbindungssteuerung (RLC) wiederhergestellt wird, wenn das UE die RRC-Freigabe erhält), und das UE müsste für jede Datenpaketübertragung RACH durchführen (als unabhängigen SDT-Zugang). Alternativ könnte das UE eine BSR wie eine Anzeige im ersten SDT senden, gemultiplext mit RRCResumeRequest (oder einer anderen RRC-Nachricht, die zur Initiierung des EDT verwendet wird) und einem Teil der Daten (die nun segmentiert sind). Dadurch würde das Netzwerk erkennen, dass das UE in den Zustand RRC_CONNECTED versetzt werden muss, um die Folgedaten zu übertragen (in diesem Fall würde der gNB den Fallback-Mechanismus zur Wiederaufnahme der Verbindung auslösen, wie in Szenario (RACH-0-B) weiter unten erläutert).
• Unter Bezugnahme auf Szenario (RACH-0-A) in 1 kann auf einen UL SDT ein optionaler DL SDT durch ein UE in RRC_INACTIVE folgen (unter der Annahme eines erfolgreichen Abrufs des UE AS-Kontexts).
• Tabelle 1 fasst die betrieblichen Einzelheiten zusammen, die das Szenario (RACH-0-A) für einen UL SDT gefolgt von einem optionalen DL SDT durch ein UE in RRC_INACTIVE beschreiben. Tabelle 1 zeigt durch Unterstreichung und Sternchen am Anfang und Ende neue Informationen oder Mechanismen, die in Rel-15/16 NR nicht definiert sind (obwohl sie mit den in Rel-15/16 LTE definierten übereinstimmen) und die erforderlich sind, um das Szenario (RACH-0-A) zu ermöglichen. Tabelle 1. Betriebliche Details für Szenario (RACH-0-A) UL(/DL) SDT durch ein UE in RRC_INACTIVE

  Themen	Szenario (RACH-0-A): UL/DL SDT von einem UE in RRC INACTIVE
  Msg1 (PRACH)	Physikalischer RACH (PRACH) **Netzwerk kann RACH-Zusrif für SDT unterscheiden**
  Msg2 (RAR)	**Netzwerk informiert das UE über eine größere UL-Zuweisung, oder die Nutzung von Msg 3**
  Msg3	**RRCResumeRequest ähnlich (gesendet über SRBO) und UL Daten (gesendet über DRB) werden gemultiplexed. Mögliche andere Signalisierung (gesendet über SRB1 oder sogar SRB2) können ebenfalls gemultiplexed werden**
  Msg4	Release-Ereignis(*1)
  Msg5	N/A
  N UL SDT und N DL SDT	1 UL (und optional 1 DL) SDT
  RLC-Entität, verwendet für mehrere SDT	N/A
  Freigabe-Ereignis (*1)	Schritt als Msg4 ausgeführt (*1) **RRCRelease ähnlich (gesendet über SRB 1) und optional andere Signalisierung (gesendet über SRB 1 oder sogar SRB2) und/oder DL Daten (gesendet über DRB) können gemultiplexed werden.**
  Rekonfiguration	Beschränkt mittels RRCRelease
  PDCCH Überwachung	Kontinuierlich
  Zellenneuauswahl	Ähnlich anwendbar für ein Legacy-UE in RRC INACTIVE
  Messungen	Ähnlich anwendbar für ein Legacy-UE in RRC INACTIVE
  Messung berichten	N/A
  RNAU (periodisch oder nicht)	Ähnlich anwendbar für ein Legacy-UE in RRC _INACTIVE
  Kurz msg Überwachung für SI Notifizierung	Ähnlich anwendbar für ein Legacy-UE in RRC _INACTIVE
  Mobilitäts handling	Versagen von SDT (wobei sein Handlung der UE-Implementierung überlassen werden könnte)
  BSR ähnlich	N/A
  Paging Überwachung	Ähnlich anwendbar für ein Legacy-UE in RRC INACTIVE
  Handling of Abdeckungsverlust	Versagen von SDT (wobei sein Handlung der UE-Implementierung überlassen werden könnte)
  Aktualisierte NCC	NCC wird aktualisiert auf Empfang von RRCRelease hin
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	Nicht erlaubt
  UL oder DL Signalisierung	Beschränkt auf die Signalisierung, die verknüpft ist mit den Wiederaufnehmen/Beenden-Prozessen einschließlich Fallback-Betrieb in RRC CONNECTED

• Der SDT-RACH-Mechanismus muss möglicherweise während des Verfahrens abgebrochen werden (in diesem Fall kann das UE je nach Fall in RRC_INACTIVE oder RRC IDLE zurückkehren) oder zurückfallen (in diesem Fall kann das UE eine RRC-Verbindung wieder aufnehmen oder eine neue RRC-Verbindung aufbauen, die das UE in RRC_CONNECTED führt). Dies sind einige der möglichen Fälle, die zu berücksichtigen sind:
• - Fall 1) Nach dem Senden von SDT Msg. 1 empfängt das UE ein RAR wie in Msg.2, das das UE veranlasst, auf den alten Betrieb zurückzugreifen (wobei es dem UE überlassen bleibt, ob es RRCResumeRequest oder RRCSetupRequest sendet).
• - Fall 2) Nach dem Senden von SDT Msg. 1 muss das UE Msg. 1 erneut senden (es bleibt dem UE überlassen, ob es SDT Msg. 1 oder Legacy Msg1 sendet). Mögliche Gründe: (a) UE erhält keine RA-Antwort innerhalb des RAR-Fensters und die SDT-Bedingungen sind nicht erfüllt, (b) wenn während des RACH-Prozesses und der Wiederholungsversuche die gesamte MAC-PDU für Msg3 nicht in die maximal zulässige TBS-Größe für Msg.3 passt (z.B. für den Fall, dass die max. TBS während zukünftiger Wiederholungen während des RACH-Prozesses ändern kann)
• - Fall 3) Nach dem Senden von SDT Msg.3 empfängt das UE Msg.4 als RRCResume (mit dem Ziel, die unterbrochene Verbindung wieder aufzunehmen und das UE in RRC_CONNECTED zu überführen). Die in Msg.3 gemultiplexten UL-Daten werden als erfolgreich betrachtet.
• - Fall 4) Nach dem Senden von SDT Msg.3 empfängt das UE Msg.4 als RRCSetup (mit dem Ziel, eine neue Verbindung aufzubauen und das UE in RRC_CONNECTED zu überführen). Die in Msg.3 gemultiplexten UL-Daten werden als Fehler betrachtet.
• - Fall 5) Der SDT-Mechanismus kann abgebrochen werden bei: (5.a) T300 läuft ab, (5.b) Zellenneuwahl während T300 läuft, (5.c) UE empfängt RRCReject-Nachricht in Msg4, (5.d) Integritätsschutzprüfung der RRC-Nachricht in Msg4 schlägt fehl.
• Es ist zu beachten, dass die Fälle 1), 3) und 4) mit dem im nächsten Abschnitt beschriebenen Mechanismus über das Szenario (RACH-0-B) zusammenhängen würden.
• Der UL SDT gilt als nicht erfolgreich, wenn das UE nicht die erwartete DL-Bestätigung erhält, z.B. RRCRelease oder, im Falle der Wiederaufnahme, RRCResume. Es ist zu beachten, dass der UL SDT nicht als erfolgreich angesehen wird, wenn das Netzwerk einen Fallback auslöst, um eine neue RRC-Verbindung (über RRCSetup) aufzubauen (z.B. weil der gNB nicht über die Sicherheitsinformationen und/oder das UE nicht über die AS-Kontextinformationen verfügt, die zur Entschlüsselung erforderlich sind).
• Szenario (RACH-O-B): UL/DL SDT durch ein UE in RRC INACTIVE, das in RRC CONNECTED zurückfällt
• 3 zeigt ein Flussdiagramm des Basisszenarios von Szenario (RACH-0-B), das während der NR-Diskussionen in Betracht gezogen wurde, um kleine Datenübertragungen (SDT) in RRC _INACTIVE zu ermöglichen, wobei das UE zurückfällt, um die RRC-Verbindung wieder aufzunehmen und in RRC_CONNECTED zu gelangen (ähnlich wie bei der LTE-EDT-Funktion).
• Die Einzelheiten zu den Schritten des in 3 dargestellten Szenarios (RACH-0-B) werden im Folgenden beschrieben:
• - Schritt 201-203) Ähnlich wie die für Szenario (RACH-0-A) erläuterten Schritte 101-103, obwohl in Schritt 3 möglicherweise eine optionale Anzeige aufgenommen werden könnte, um dem Netzwerk anzuzeigen, dass größere UL-Daten darauf warten, gesendet zu werden (z.B. über BSR oder über eine neue SDT-bezogene Anzeige).
• - Schritt 204) Ähnlich wie bei der alten Wiederaufnahmeprozedur beim Senden der RRCResume-Nachricht, mit dem Vorbehalt, dass der gNB bereits DL-Daten und/oder Signalisierung verschlüsselt und integritätsgeschützt senden kann.
• Alternativ könnte RRCSetup auch vom Netzwerk gesendet werden, wenn stattdessen eine neue RRC-Verbindung aufgebaut werden muss, und in diesem Fall würde die zwischen gNB und dem letzten gNB und AMF ausgetauschte Nachricht anders lauten.
• - Schritt 205) Ähnlich wie bei der alten Wiederaufnahmeprozedur beim Senden der Nachricht RRCResumeComplete
• - Schritt 207(z.B. x) Ähnlich wie in Schritt 4) für Szenario (0-A) oder Legacy-Suspend-Verfahren erklärt.
• Wenn mehr als ein UL(/DL)-SDT über das Szenario (RACH-0-B) ausgetauscht werden muss, werden sie als ältere untergeordnete Datenübertragungen eines UE in RRC_CONNECTED behandelt. 4 ist ein vereinfachtes Flussdiagramm, das den erwarteten Betrieb zum Senden von 2 UL-Datenpaketen über den in Szenario (RACH-0-B) dargestellten Mechanismus veranschaulicht. 4 veranschaulicht die Schlüsseloperation des UE zum Senden von 2 UL-Datenpaketen über den in Szenario (RACH-0-B) dargestellten Mechanismus. Es ist wichtig hervorzuheben, dass dieser Ansatz jede Operation erlaubt, die von einem UE in RRC_CONNECTED möglich ist (z.B. Messungen einschließlich ihrer Berichterstattung, Handover, RRC-Rekonfiguration, Scheduling-Anforderung usw.), und dass das UE kontinuierlich PDCCH überwacht (es sei denn, das UE geht in C-(diskontinuierlicher Empfang)DRX).
• Unter Bezugnahme auf das Szenario (RACH-0-B) in 3 kann auf einen UL SDT eines UE in RRC _INACTIVE ein optionaler DL SDT folgen, während die RRC-Verbindung wieder aufgenommen wird, um das UE in RRC_CONNECTED zu überführen (unter der Annahme eines erfolgreichen Abrufs des UE AS-Kontexts).
• Tabelle 2 fasst die betrieblichen Details zusammen, die das Szenario (RACH-0-B) UL SDT durch ein UE in RRC_INACTIVE beschreiben, während die RRC-Verbindung wieder aufgenommen wird, um das UE in RRC_CONNECTED zu überführen. In Tabelle 2 sind die wichtigsten Änderungen für Szenario (RACH-0-B) im Vergleich zum SDT-Basisbetrieb (beschrieben in Szenario (RACH-O-A)) durch Unterstreichung und Sternchen am Anfang und Ende dargestellt. Tabelle 2. Betriebliche Details für Szenario (RACH-0-B) UL SDT durch ein UE in RRC_INACTIVE bei gleichzeitiger Wiederaufnahme der RRC-Verbindung zum Übergang des UE in RRC_CONNECTED

  Themen	Szenario (RACH-O-B): UL SDT durch ein UE in RRC_INACTIVE während der Wiederaufnahme der RRC-Verbindung, um das UE in RRC_CONNECTED zu überführen
  Msg1 (PRACH)	Gleich wie bei Szenario (0-A)
  Msg2 (RAR)	Wie bei Szenario (0-A)
  Msg3	Ähnlich wie Szenario (0-A) **und optional inklusive BSR wie für UE, um dem Netzwerk anzuzeigen, dass es mehr Daten zu senden hat (d.h. N > 1 SDT)**
  Msg4	Das Netzwerk löst einen Fallback aus, um die Verbindung wieder aufzunehmen, so dass das UE zusätzliche SDT senden kann, während es sich in RRC CONNECTED befindet. Msg.4 folgt der Legacy-Operation, d.h. RRCResume (gesendet über SRB1), möglicherweise gemultiplext mit DL-Daten oder Signalisierung
  Msg5	Legacy-Operation RRCResumeComplete (gesendet über SRB1), möglicherweise gemultiplext mit UL-Daten oder Signalisierung
  N UL SDT und N DL SDT	N > 1
  RLC-Einheit wird für mehrere SDT verwendet	Anwendbar wie für ein UE in RRC_CONNECTED
  Freigabe-Ereignis (*1)	Wie bei Szenario (0-A) (aber das Ereignis findet zu einem anderen Zeitpunkt statt)
  Rekonfiguration	Möglich über RRCResume oder RRCReconfiguraiton (bei RRC CONNECTED)
  PDCCH Überwachung	Kontinuierlich oder C-DRX (wie für ein altes UE in RRC CONNECTED)
  Zellenneuauswahl	N/A
  Messungen	Anwendbar wie für ein UE in CONNECTED
  Messbericht	Anwendbar wie für ein UE in CONNECTED
  RNAU (periodisch or nicht)	N/A
  Kurz msg Überwachung für SI Notifikation	Anwendbar wie für ein UE in CONNECTED
  Mobilitätshandling	Wie für ein UE in RRC_CONNECTED (d.h. Handover, RLF, Wiederherstellung)
  BSR ähnlich	Anwendbar ab Msg.3
  Paging Überwachung	Anwendbar wie für ein UE in CONNECTED
  Handling von Abdeckungsverlust	Wie für ein UE in RRC_CONNECTED (d.h. RLF, Wiederherstellung)
  Aktualisierter NCC	NCC wird beim Empfang von RRCRelease oder beim Handover aktualisiert
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	Erlaubt (wie für ein Legacy-UE in RRC_CONNECTED)
  UL oder DL Signalisierung	Erlaubt (wie für ein Legacy-UE in RRC_INACTIVE und RRC_CONNECTED)

• Szenario (RACH-1): mehrere UL/DL-SDTs durch ein UE in „RRC INACTIVE“ unter Verwendung desselben SDT-Wiederaufnahmeverfahrens
• Szenario (RACH-1) beschreibt einen neuen Mechanismus für ein UE in „RRC INACTIVE“, um mehrere Daten- oder Signalisierungspakete/PDUs auszutauschen, ohne dass das UE in RRC_CONNECTED übergehen muss, während es sich in der gleichen SDT-Wiederaufnahmeprozedur befindet. Ein Grund für die Verwendung dieses neuen Mechanismus anstelle des Übergangs eines UE in RRC_CONNECTED (wie in Szenario (RACH-0-B) erläutert) ist, dass die UL-Daten des UE nicht alle in die für Msg.3 angegebene Zuweisung passen, daher wird das UL-Datenpaket segmentiert, aber es gibt nicht viele Daten, und daher ist es vorzuziehen, das UE in RRC_INACTIVE zu halten. Die maximale Zunahme der Größe von Msg.3 könnte aufgrund der voraussichtlichen Zunahme der erneuten Übertragungen und der damit verbundenen Verzögerungen, die für NR-Anwendungsfälle möglicherweise nicht akzeptabel sind, begrenzt sein (dieser Aspekt war bei MTC/NB-IoT-Szenarien weniger umstritten, da sie auf UEs abzielten, die bestimmte/größere Verzögerungen tolerieren können). Die maximale Menge an kleinen Daten, die im RRC_INACTIVE-Modus gesendet werden können, kann durch die Übertragung eines Schwellenwerts durch den gNB begrenzt werden.
• Die Vorteile des Szenarios (RACH-1) liegen darin, dass (a) es eine vereinfachte Version des Wiederaufnahmeverfahrens ermöglicht, bei dem das UE nicht die gesamte ausgesetzte Konfiguration, die im UE-AS-Kontext gespeichert ist, wieder aufnehmen (oder sogar neu konfigurieren) muss, und (b) das UE nicht alle Funktionen und Konfigurationen unterstützen oder aktivieren muss, die mit einem UE in RRC_CONNECTED verbunden sind (z.B. RLF, Mobilität/Handover, Wiederherstellung, CA/DC, MIMO, Meldung der Kanalqualität, Änderung des BWP-Betriebs/der BWP-Konfiguration usw.).
• 5 ist ein Flussdiagramm, das einen neuen Mechanismus zusätzlich zum Basisszenario (RACH-0) veranschaulicht, der es dem UE ermöglicht, das Szenario/die Lösung (RACH-1) für ein UE in „RRC INACTIVE“ zu aktivieren, um mehrere DL/UL SDT auszutauschen (ohne in RRC_CONNECTED überzugehen). Während ein UE in „RRC INACTIVE“ SDT austauscht, kann das UE immer noch als in RRC _INACTIVE betrachtet werden. Zusätzlich oder alternativ kann ein Name verwendet werden, z.B. „RRC_INACTIVE limbo“ oder „RRC INACTIVE plus“, „PSEUDO-INACTIVE“ und andere, um den Übergangszustand darzustellen, wenn sich das UE nicht vollständig in RRC _INACTIVE oder in RRC CONNECTED befindet. Weitere Einzelheiten zu diesem Übergangszustand werden im Folgenden beschrieben.
• 5 zeigt ein Flussdiagramm des Szenarios (RACH-1), das mehrere N UL/DL SDT ermöglicht, während das UE in RRC_INACTIVE verbleibt und das gleiche SDT-Wiederaufnahmeverfahren verwendet.
• Die Einzelheiten zu den Schritten des in 5 dargestellten Szenarios (RACH-1) werden im Folgenden beschrieben:
• - Schritte 301-303) Ähnlich wie die für Szenario (RACH-0-A) erläuterten Schritte, jedoch mit einer optionalen Anzeige in Schritt 3, um dem Netzwerk mitzuteilen, dass größere UL-Daten zum Senden anstehen. Die UL-Benachrichtigung über die Menge der UL-SDT kann über RRC oder MAC CE oder im Kopffeld der Datennutzlast erfolgen, ähnlich wie bei Szenario (RACH-0-B), wobei die alten BSR wiederverwendet oder aktualisiert werden. Alternativ könnte eine neue Form der SDT-bezogenen Anzeige definiert werden, um diese UL-Benachrichtigung über (a) die Größe der zu sendenden Daten oder (b) die Menge der nachfolgenden Pakete oder (c) eine allgemeine Anzeige, dass mehr Daten in seinem UL-Puffer vorhanden sind, die über SDT gesendet werden sollen, bereitzustellen.
• Anschließend können UE und gNB mehrere UL- und DL-SDT austauschen, wie weiter unten erläutert.
• - Schritt 304) Ähnlich wie in Schritt 204) für das Szenario (RACH-0-A) oder das alte Suspend-Verfahren erläutert, um den Austausch mehrerer SDT abzuschließen und u.a. eine aktualisierte suspendConfig (z.B. einen neuen NCC) bereitzustellen.
• Wenn mehr als ein UL(/DL) SDT über das Szenario (RACH-1) ausgetauscht werden muss, kann der neue Mechanismus verwendet werden, bei dem das UE im Zustand „RRC INACTIVE“ verbleibt, mit einigen Unterschieden zum hier beschriebenen alten Zustand „RRC INACTIVE“, der Einfachheit halber wird er hier als „RRC_INACTIVE plus“ bezeichnet, obwohl es möglicherweise keine tatsächliche Zustandsänderung gibt. Während sich das UE im „RRC_INACTIVE plus“-Zustand befindet, wird eine UE-ID in dem UE und im Netzwerk beibehalten (z.B. die C-RNTI, die dem UE in Msg.2 zugewiesen wurde), das UE überwacht auch den PDCCH und nimmt die zu verwendende Konfiguration wieder auf. Je nachdem, welche Konfigurationen verwendet werden, werden zwei Optionen in Betracht gezogen:
• - Option (A): Das UE nimmt die Standardkonfigurationen oder die vom Netzwerk vorkonfigurierten Konfigurationen wieder auf (die in der Spezifikation definiert sein können oder dem UE z.B. über SIB oder im Zustand RRC_CONNECTED oder bei der Freigabe zur Verfügung gestellt werden).
• - Option (B): Die UE nimmt nur einen Teil der gespeicherten Konfigurationen innerhalb des UE-AS-Kontextes wieder auf. Welcher Teil der gespeicherten Konfiguration für SDT wiederaufgenommen wird, könnte in der Spezifikation festgelegt und/oder vom Netzwerk für die UE konfiguriert werden. Es ist zu beachten, dass das UE möglicherweise bereits einen Teil der gespeicherten Konfiguration für die in msg3/msg A gesendeten Daten verwendet.
• 6 veranschaulicht vereinfachte Flussdiagramme des erwarteten Vorgangs zum Senden von 2 UL-Datenpaketen über den in Szenario (RACH-1) dargestellten Mechanismus, einschließlich der beiden soeben beschriebenen Optionen A und B. 6 veranschaulicht die Schlüsseloperation des UE zum Senden von 2 UL-Datenpaketen über den Mechanismus von Szenario (RACH-1).
• Tabelle 3 fasst die betrieblichen Details zusammen, die das Szenario (RACH-1) beschreiben, das mehrere N UL/DL SDT ermöglicht, während das UE in „RRC INACTIVE“ verbleibt und das gleiche SDT-Wiederaufnahmeverfahren verwendet. In Tabelle 3 sind die wichtigsten Änderungen für Szenario/Lösung (RACH-1) im Vergleich zum Basis-SDT-Wiederaufnahme-/Suspend-Betrieb (beschrieben in Szenario (RACH-O-A)) durch Unterstreichung und Sternchen am Anfang und Ende dargestellt. Tabelle 3. Betriebliche Details für Szenario (RACH-1) Multiple N UL/DL SDT, während das UE in RRC_INACTIVE verbleibt und das gleiche SDT-Wiederaufnahmeverfahren verwendet

  Themen	Szenario (RACH-1): Mehrere N UL/DL SDT, während das UE in RRC INACTIVE bleibt
  Msg1 (PRACH)	Wie bei Szenario (0-A)
  Msg2 (RAR)	Wie bei Szenario (0-A)
  Msg3	Ähnlich wie Szenario (0-A) und optional mit BSR wie ** oder einer anderen neuen SDT-Anzeige für das UE, um dem Netzwerk anzuzeigen, dass es mehr Daten zu senden hat (d.h. N > 1 SDT). Diese Anzeige kann über RRC oder MAC oder sogar innerhalb des Datenkopffeldes erfolgen. Dabei kann es sich um eine explizite Angabe der zu sendenden Daten oder der Anzahl der erforderlichen Pakete oder SDT handeln oder einfach nur um die Angabe, dass weitere Daten oder Pakete über SDT ausgetauscht werden müssen oder nicht.
  Msg4	DL SDT für nachfolgende Daten/Steuerung-PDU
  Msg5	DL SDT für nachfolgende Daten/Steuerung-PDU
  N UL SDT und N DL SDT	N> 1
  RLC Entität verwndet für mehrere SDT	** Dieselbe RLC-Einheit, die verwendet wird, während sich das UE in „RRC INACTIVE plus“ befindet (d.h. kein NCC wird zwischen den subsequenten UL/DL SDT-PDUs aktualisiert)**
  Freigabe-Ereignis(*1)	Wie bei Szenario (0-A) (aber das Ereignis findet zu einem anderen Zeitpunkt statt)
  Rekonfiguration	Begrenzt über RRCRelease, es sei denn, es könnten zusätzliche Konfigurationen bereitgestellt werden. **Mögliche Wege zur Bereitstellung einer neuen Konfiguration sind: - (a) DL PDU trägt RRCReconfiguration, - (b) Definition neuer IEs bei RRCRelease, ** - (c) Auslösen eines Fallbacks, um das UE in RRC - CONNECTED zu versetzen. **Für (a) RRConfiguration braucht das UE möglicherweise nicht mit RRCReconfigurationComplete zu antworten, z.B. wenn es mit RRCRelease gemultiplext wird. **
  PDCCH Überwachung	**Kontinuierlich. Mögliche Erweiterungen für die diskontinuierliche Überwachung von PDCCH (während sich das UE im Zustand RRC _INACTIVE plus befindet) sind - a) wenn das Netzwerk die DL SDT sendet, zeigt es auch die zukünftige DL/UL SDT oder Zuweisung an, - b) das UE überwacht den PDCCH nur in seinem alten PF/PO, um mögliche zukünftige UL/DL-SDT oder Zuweisungen zu prüfen, - c) das UE folgt einem diskontinuierlichen Überwachungsmechanismus ähnlich wie C-DRX, um künftige DL/UL-SDT-Zuweisungen zu prüfen, - d) das UE ist mit Ressourcen für seinen zukünftigen UL/DL SDT oder die Überwachung des PDCCH (vor)konfiguriert. Für alle möglichen Optionen könnte die Überwachung von PDCCH oder Zuweisungen als ein einzelnes Ereignis oder als ein Ereignis definiert werden, auf das das UE während eines Zeitfensters prüft, das für das UE definiert/konfiguriert werden könnte. **
  Zellenneuauswahl	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messungen	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messungsbericht	Für „RRC_INACTIVE plus“ sind die Messungsberichte wie für ein altes UE in RRC_CONNECTED nicht anwendbar. **Mögliche Verbesserungen zur Ermöglichung von Messberichten sind (a) Berichte ähnlich den frühen Messberichten (basierend auf Messungen, die von einem UE in RRC INACTIVE durchgeführt wurden). Dies könnte für das Netzwerk von Vorteil sein, um das UE entsprechend zu rekonfigurieren, z.B. in den Konfigurationen, die für laufende/künftige SDT verwendet werden sollen (z.B. für DC/CA-Konfigurationen). **
  RNAU (periodisch oder nicht)	Anwendbar wie für ein altes UE in RRC INACTIVE
  Kurznachrichtüberwachung für SI Notifikation	Anwendbar wie für ein altes UE in RRC INACTIVE
  Mobilitätshandling	Anwendbar wie für ein altes UE in RRC _INACTIVE (d.h. Zellenneuwahl), in diesem Fall würde es einen Ausfall des laufenden SDT auslösen (es kann der UE-Implementierung überlassen werden, wie sie damit umgeht). **Mögliche Erweiterungen zur Handhabung der Mobilität sind: - a) Rückfall auf RRC - CONNECTED (um auf bestehende Mechanismen zurückgreifen zu können, z.B. Handover (HO), Ausfall der Funkverbindung (RLF), Wiederherstellung), oder - b) das UE oder das Netzwerk kann eine Anzeige auslösen, wenn es feststellt, dass das UE die Zelle verlässt, um die Freigabe zurück zu RRC _INACTIVE auszulösen, oder - c) sich auf RLF verlassen, oder - d) ein handover-ähnliches Verfahren im Zustand „RRC INACTIVE plus“ aktivieren. **
  BSR artig	Anwendbar, auch wenn sich das UE in RRC INACTIVE plus befindet
  Paging Überwachung	Anwendbar wie für ein altes UE in RRC _INACTIVE **Eine neue Behandlung kann erforderlich sein, wenn das UE gleichzeitig die P-RNTI und die C-RNTI im Zusammenhang mit dem laufenden SDT überwachen muss **.
  Handling von Abdeckungsverlust	Anwendbar wie für ein altes UE in RRC INACTIVE. In diesem Fall würde es einen Ausfall des laufenden SDT auslösen (es kann der UE-Implementierung überlassen werden, wie sie damit umgeht). **Mögliche Erweiterungen zur Behandlung eines Abdeckungsverlustes: (a) Wiederherstellungsprozedur, wenn sich das UE weiterhin in derselben Zelle aufhält, in der es seine SDT durchführt.**
  Aktualisierter NCC	NCC wird bei Empfang von RRCRelease aktualisiert
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	**Erlaubt ähnlich wie bei einem UE in RRC CONNECTED, aber während das UE in „RC INACTIVE plus ‟** ist
  UL oder DL Signalisierung	Zumindest die Signalisierung, die mit den Resume/Suspend-Verfahren verbunden ist, einschließlich des Fallback-Betriebs in RRC_CONNECTED. **Darüber hinaus könnte eine anwendbare RRC/MAC-Signalisierung von RRC CONNECTED von einem UE in RRC INACTIVE verwendet werden, wie z.B. RRC-Rekonfiguration, UE-Unterstützungsinformationen, um die Präferenz des UE zu übermitteln, in RRC IDLE überzugehen (anstatt in RRC_INACTIVE zu bleiben), PHR, BSR, TA, Kanalqualität oder SR, neben anderen.**

• Szenario (RACH-2): mehrere UL/DL SDTs durch ein UE in „RRC INACTIVE“ unter Verwendung von nachfolgenden SDT-Resumptions
• Szenario (RACH-2) beschreibt einen neuen Mechanismus für ein UE in „RRC INACTIVE“, um mehrere Daten- oder Signalisierungspakete/PDUs auszutauschen, ohne dass das UE in RRC_CONNECTED übergehen muss, während es verschiedene nachfolgende SDT-Wiederaufnahmeverfahren durchläuft. Ein Grund für die Verwendung dieses neuen Mechanismus ist, dass der für Szenario (RACH-1) diskutierte Übergangszustand, d.h. RRC _INACTIVE plus, nicht eingeführt werden muss. Anstatt den PDCCH zwischen den SDT-Übertragungen zu überwachen, verlässt sich das Netzwerk daher auf einen nahen RACH-Zugang für einen nachfolgenden UL-SDT (bei dem es sich um eine UL-PDU handeln könnte, die aus dem ursprünglichen Paket, das den SDT ausgelöst hat, segmentiert wurde). Der Nachteil dieses Szenarios (RACH-2) ist, dass es zu einer zusätzlichen Verzögerung führen würde (da das UE einen erneuten RACH-Zugriff benötigt).
• 7 zeigt einen neuen Mechanismus zusätzlich zum Basisszenario (RACH 0), der es dem UE ermöglicht, das Szenario/die Lösung (RACH-2) für ein UE in „RRC INACTIVE“ zu aktivieren, um mehrere DL/UL SDT auszutauschen (ohne in RRC_CONNECTED überzugehen). Unter Bezugnahme auf das Szenario (RACH-2) in 7 werden mehrere N UL/DL SDT ausgetauscht, während das UE in „RRC_INACTIVE“ verbleibt, wobei subsequente SDT-Resumptions verwendet werden. Während das UE in „RRC INACTIVE“ SDT austauscht, kann das UE immer noch als RRC _INACTIVE betrachtet werden, oder es kann ein Name verwendet werden, z.B. „RRC_INACTIVE limbo“ oder „RRC_INACTIVE plus“ „PSEUDO-INACTIVE“ und andere, um den Übergangszustand darzustellen, wenn das UE nicht vollständig in RRC INACTIVE oder in RRC_CONNECTED ist. Nach jedem UL/DL SDT stellt das Netzwerk einen aktualisierten NCC zur Verfügung und das UE bleibt im alten RRC INACTIVE. Daher werden dieselben RLC-Entitäten (Funkverbindungssteuerung) für jeden nachfolgenden UL/DL SDT verwendet. Weitere Einzelheiten zu diesem Übergangszustand werden im Folgenden beschrieben. Sollte das Netzwerk eine große Menge an DL-Daten vorhersehen, könnte das Netzwerk das UE in RRC_CONNECTED überführen, anstatt das UE in „RRC_INACTIVE plus“ zu halten.
• Die Einzelheiten zu den Schritten des in 7 dargestellten Szenarios (RACH-2) werden im Folgenden beschrieben:
• - Schritt 401-404) Ähnlich wie die für Szenario (RACH-0-A) erläuterten Schritte, mit dem Unterschied, dass das UE darüber informiert, dass weitere UL-SDT auf den Austausch über Subsequenz-SDT-Resume-Verfahren warten. Auf diese Weise wissen das UE und das Netzwerk, dass UP beibehalten werden muss (auch wenn sich das UE in RRC _INACTIVE befindet).
• Darüber hinaus müssen die RRCResumeRequest- und RRCRelease-Meldungen nicht bei jeder SDT-Subsequenz-Übertragung gesendet werden, wie weiter unten näher erläutert wird.
• Wenn mehr als eine UL(/DL)-SDT über das Szenario (RACH-2) ausgetauscht werden muss, werden die SDTs als untergeordnete unabhängige SDT-Wiederaufnahmeverfahren behandelt, bei denen der Sicherheitskontext aktualisiert wird, die Benutzerebene jedoch beibehalten wird. 8 zeigt ein vereinfachtes Flussdiagramm des erwarteten Vorgangs zum Senden von 2 UL-Datenpaketen über den Mechanismus von Scenario (RACH-2). 8 veranschaulicht die Schlüsseloperation des UE zum Senden von 2 UL-Datenpaketen über den Mechanismus des Szenarios (RACH-2). Es ist wichtig hervorzuheben, dass dieser Ansatz eine gewisse Form der Segmentierung ermöglichen würde, obwohl das UE für jede Datenpaketübertragung RACH verwenden müsste (als pseudounabhängiger SDT-Zugang). Daher könnte es möglich sein, RRCResumeRequest- oder RRCRelease-Nachrichten nicht für jede SDT-Übertragung zu senden. Stattdessen könnte es ausreichen, nur die RRCResumeRequest-Nachricht beim Start dieses SDT-Vorgangs und die RRCRelease-Nachricht beim Beenden des laufenden SDT-Vorgangs zu senden. Allerdings können die dazwischen liegenden Msg.3 und Msg.4 weiterhin einige der relevanten Informationen enthalten, wie z.B. die UE-ID für Msg.3 und den neuen NCC für Msg.4, während die SDT läuft.
• Tabelle 4 fasst die betrieblichen Details zusammen, die das Szenario (RACH-2) beschreiben, das mehrere N UL/DL SDTs ermöglicht, während das UE in RRC_INACTIVE verbleibt und nachfolgende SDT-Resumptions verwendet. In Tabelle 4 sind die wichtigsten Änderungen für Szenario/Lösung (RACH-2) im Vergleich zum SDT-Basisbetrieb (beschrieben in Szenario (RACH-O-A)) durch Unterstreichung und Sternchen am Anfang und Ende dargestellt.
• Tabelle 4. Betriebliche Einzelheiten für Szenario (2) Multiple N UL/DL SDT, während das UE in RRC INACTIVE verbleibt, unter Verwendung von subsequenten SDT-Wiederaufnahmen
• Table 4. Operational details for scenario (2) Multiple N UL/DL SDT while UE remains in RRC INACTIVE using sub-sequent SDT-resumptions

  Themen	Szenario (RACH-2) Mehrere N UL/DL SDT, während UE in RRC INACTIVE verbleibt, unter Verwendung von nachfolgenden SDT-Annahmen
  Msg1 (PRACH)	Wie bei Szenario (0-A)
  Msg2 (RAR)	Wie bei Szenario (0-A)
  Msg3	Wie Szenario (0-A) und optional mit BSR wie ** oder anderen neuen SDT-Angaben für das UE, um dem Netzwerk anzuzeigen, dass es mehr Daten zu senden hat (d.h. N > 1 SDT). RRCResumeRequest darf nur beim 1. Mal gesendet werden, wenn das UE das SDT initiiert.**
  Msg4	**Das Netzwerk teilt dem UE mit, dass der nachfolgende SDT akzeptiert wird (implizit oder explizit).** Für künftige SDT wird weiterhin ein neuer NCC bereitgestellt, und zwar über RRCRelease **oder einen anderen Mechanismus (z.B. RRCReconfiguration). Der Hauptunterschied besteht darin, dass das UE und das Netzwerk wissen, dass der Zustand der Nutzerebene aktiv gehalten wird, um in der anschließenden SDT verwendet zu werden. Solange die SDT-Subsequent-Übertragungen laufen, darf das Netzwerk kein RRCRelease senden. Dieses darf nur gesendet werden, wenn das Netzwerk die laufende SDT beenden will (d. h. das UE wieder in den alten Zustand RRC INACTIVE versetzen will)**.
  Msg5	N/A
  N UL SDT und N DL SDT	N > 1 mit 1 UL (und optional 1 DL) SDT in jeder SDT-Wiederaufnahme
  RLC Entität verwendet für mehrere SDT	**UP wird beibehalten, während sich das UE in „RRC INACTIVE plus“ befindet, einschließlich RLC- und PDCP-Entitäten, obwohl NCC für jedes UL(/DL)-SDT aktualisiert werden würde **
  Freigabe-Ereignis	Siehe Details in der Zeile Msg4
  Rekonfiguration	Begrenzt mittels RRCRelease
  PDCCH Überwachung	Kontinuierlich, aber nur beim Austausch jedes UL(/DL)-SDT (mit der entsprechenden anderen beteiligten Signalisierung)
  Zellenneuwahl	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messungen	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messbericht	N/A
  RNAU (periodisch oder nicht)	Anwendbar wie für ein altes UE in RRC INACTIVE
  Kurznachrichtüberwachung für SI Notifikation	Anwendbar wie für ein altes UE in RRC INACTIVE
  Mobilitätshandling	Ausfall von SDT (wobei die Handhabung der UE-Implementierung überlassen werden könnte)
  BSR artig	Potenziell anwendbar wie in Zeile Msg3 beschrieben
  Paging Überwachung	Anwendbar wie für ein altes UE in RRC INACTIVE
  Handling von Abdeckungsverlusten	Ausfall des SDT (wobei die Behandlung der UE-Implementierung überlassen werden könnte)
  Aktualisierter NCC	NCC wird beim Austausch jedes UL(/DL) SDT aktualisiert
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	**Erlaubt ähnlich wie bei einer UE in RRC - CONNECTED, aber während das UE in „RRC INACTIVE plus ‟** ist
  UL oder DL Signalisierung	Begrenzt auf die Signalisierung im Zusammenhang mit den Resume/Suspend-Verfahren, einschließlich des Fallback-Betriebs in RRC_CONNECTED und BSR

• Zusätzlich oder alternativ kann ein SDT-PUR-Mechanismus bereitgestellt werden, um kleine Datenübertragungen zu erleichtern.
• Bevor wir uns mit den Details des SDT-PUR-Mechanismus in NR befassen, lohnt sich ein Blick auf das Legacy/LTE-PUR-Design.
• Im Allgemeinen ermöglicht PUR eine einzelne UL-Übertragung von einem UE in RRC IDLE unter Verwendung vorkonfigurierter Ressourcen, ohne dass ein zufälliger Zugriff erfolgen muss (um zu RRC_CONNECTED zu wechseln). Optional kann sich eine einzelne DL-Übertragung anschließen. Die Übertragung mit PUR wird vom (ng-)eNB nur aktiviert, wenn das UE und der (ng-)eNB dies unterstützen. Es ist zu beachten, dass die Übertragung mit PUR in der Rel-16-LTE-Spezifikation nur für BL UEs, UEs mit erweiterter Abdeckung und NB-IoT UEs gilt.
• Unter der Annahme, dass die Bedingungen erfüllt sind, kann das UE im RRC_CONNECTED-Modus die Konfiguration mit PUR anfordern. Der (ng-)eNB entscheidet über die Konfiguration von PUR auf der Grundlage der Anforderung des UE, der Teilnehmerinformationen des UE und/oder der lokalen Richtlinie. 9 zeigt ein Flussdiagramm des Verfahrens zur Anforderung (oder Freigabe) einer gültigen PUR-Konfiguration, während sich das UE im RRC_CONNECTED-Modus befindet.
• Die Nachricht pur-ConfigurationRequest 901 enthält für den PUR-Betrieb relevante Informationen wie requestedNumOccasions und requestedPeriodicityAndOffset und requestedTBS sowie pur-ReleaseRequest IE. Als Antwort kann das Netzwerk die pur-Config 902 auf der Grundlage der vom UE angeforderten Konfiguration bereitstellen.
• Ein weiterer zu berücksichtigender Aspekt sind die spezifischen Bedingungen, unter denen das UE tatsächlich PUR-Übertragungen durchführen darf. In diesem Zusammenhang muss das UE nicht nur eine gültige PUR-Konfiguration vom Netzwerk haben, sondern auch einen gültigen Timing Alignment (TA)-Wert für die bedienende Zelle. Das UE kann den Zeitabgleich für PUR-Übertragungen auf der Grundlage der folgenden Bedingungen validieren:
• - wenn pur-TimeAlignmentTimer in pur-Config konfiguriert ist:
  • ◯ pur-TimeAlignmentTimer muss auf den unteren Schichten laufen
• - wenn pur-RSRP-ChangeThreshold konfiguriert ist
  • ◯ seit der letzten TA-Validierung hat sich das RSRP der bedienenden Zelle (a) nicht um mehr als increaseThresh erhöht und (b) nicht um mehr als decreaseThresh verringert;
• Die spezifischen Bedingungen für die Einleitung von PUR-Übertragungen sind wie folgt:
• - Das UE hat eine gültige PUR-Konfiguration für die bedienende Zelle (Serving Cell);
• - Das UE hat einen gültigen Wert für die zeitliche Abstimmung;
• - Die oberen Schichten fordern den Aufbau einer RRC-Verbindung an; oder die oberen Schichten fordern die Wiederaufnahme einer RRC-Verbindung an, und das UE hat einen gespeicherten Wert des nextHopChainingCount, der in der RRCConnectionRelease-Meldung mit Suspend-Indikation während des vorangegangenen Suspend-Vorgangs angegeben wurde;
• - die obige Aufbau- oder Wiederaufnahmeanforderung gilt für von Mobilgeräten ausgehende Anrufe und die Aufbauursache ist mo-Data oder mo-ExceptionData oder delayTolerantAccess; und
• - für die CP-Übertragung unter Verwendung von PUR wird erwartet, dass die Größe der resultierenden MAC-PDU einschließlich der gesamten UL-Daten kleiner als oder gleich der für PUR konfigurierten TBS ist.
• Das Datenübertragungsverfahren mit PUR in LTE unterscheidet sich geringfügig, je nachdem, ob CP- oder UP-Daten mit PUR gesendet werden. Die wesentlichen Unterschiede sind in Tabelle 5 aufgelistet. Tabelle 5 fasst einen Vergleich zwischen CP- und UP-basierten PUR-Lösungen für SDT in LTE zusammen. Tabelle 5 Vergleich zwischen CP- und UP-basierten PUR-Lösungen für SDT in LTE

  Steuerebene	Benutzerebene
  • Kein Übergang in RRC - CONNECTED	• Kein Übergang in RRC_CONNECTED und UE in RRC IDLE mit gültigen PUR-Ressourcen
  • Alle UL-Daten werden unter Verwendung der PUR-Ressource in einer NAS-Nachricht übertragen, die in der RRCEarlyDataRequest-Nachricht auf CCCH verkettet ist.
  	• UE hat einen NextHopChainingCount in der RRCConnectionRelease msg mit Suspend-Indikation erhalten
  • Wenn die UL-Daten zu groß für RRCEarlyDataRequest sind, kann das UE die PUR-Ressource verwenden, um RRCConnectionRequest zu übertragen, was einen Rückfall zu RRC CONNECTED auslöst.	• UL-Nutzdaten werden auf DTCH im Multiplex mit RRCConnectionResumeRequest msg auf CCCH übertragen
  	• Wenn UL-Nutzdaten zu groß für PUR sind, kann das UE über PUR RRCConnectionResumeRequest und einen Teil der Nutzdaten senden, was einen Rückfall zu RRC - CONNECTED auslöst
  • Alle DL-Nutzdaten werden in einer NAS-Nachricht übertragen, die mit der RRCEarlyDataComplete-Nachricht auf CCCH verkettet wird.
  • Wenn keine DL-Daten vorhanden sind, kann der (ng-)eNB das Verfahren durch Senden eines Layer 1 ACK (optional mit einem Time Advance Command), eines MAC Time Advance Command oder RRCEarlyDataComplete ohne Nutzdaten beenden	• Alle DL-Nutzdaten werden im Multiplex mit RRCConnectionRelease oder RRCConnectionResume msg auf DCCH übertragen
  	• DL- und UL-Nutzdaten werden unter Verwendung der mit NextHopChainingCount abgeleiteten Schlüssel verschlüsselt, die in RRCConnectionRelease msg der vorherigen RRC-Verbindung bereitgestellt wurden.
  • Wenn kein Layer 1 Ack, MAC Time Advance Command oder RRCEarlyDataComplete empfangen wird, betrachtet das UE die UL-Datenübertragung als nicht erfolgreich
  	• Der eNB kann auch auf den RRC-Verbindungsaufbau zurückgreifen, in diesem Fall betrachtet das UE die vorherige UL-Datenübertragung als nicht erfolgreich.

• Berücksichtigung von Mehrfach-SDT-PUR (N UL/DL-Übertragungen, wobei N > 1)
• Bei der Betrachtung des SDT-PUR-Betriebs in NR kann es, ähnlich wie beim SDT-RACHbasierten Betrieb, der UE-Implementierung überlassen bleiben, wann sie auf PUR-Übertragungen zurückgreift und wann sie in den RRC_CONNECTED-Modus wechselt. Es könnte eine Kombination von Lösungen definiert werden, die es dem UE und dem Netzwerk ermöglicht, mehrere kleine Datenübertragungen im RRC INACTIVE-Modus durchzuführen.
• In jedem Fall müssen die Bedingungen festgelegt werden, unter denen das UE PUR für Übertragungen nutzen kann. Die folgenden Bedingungen können unter Berücksichtigung von LTE/NR-bezogenen Funktionen/Diskussionen definiert werden:
1. 1. Sowohl das UE als auch das Netzwerk müssen die Nutzung der PUR-Funktion unterstützen/erlauben.
2. 2. Das UE verfügt über eine gültige Konfiguration, die die Nutzung des PUR-Merkmals vom Netzwerk erlaubt und für die aktuelle Serving Cell gültig ist. Diese Konfiguration kann entweder über eine dedizierte oder eine Broadcast-Signalisierung bereitgestellt werden und kann die vom UE angeforderte Konfiguration für die erstere berücksichtigen.
3. 3. Die PUR-Übertragung wird für die entsprechende Zugangskategorie ausgelöst (z.B. könnte LTE PUR nur für MO-Anrufe ausgelöst werden, deren Establishment- oder Resume-Cause-Werte auf mo-Data oder mo-ExceptionData oder delayTolerantAccess gesetzt sind). Als mögliche neue Bedingung für NR kann zusätzlich eine neue Zugangskategorie speziell für PUR definiert werden. Darüber hinaus kann diese neue Zugangskategorie zwischen einer unterschiedlichen Anzahl von N-Übertragungen oder zwischen verschiedenen Arten von PUR-Übertragungen unterscheiden, die mit bestimmten Arten von Verkehr und/oder Konfigurationen verbunden sein können.
4. 4. Das UE muss über einen gültigen Wert für die zeitliche Abstimmung verfügen.
5. 5. Die TBS-Größenbeschränkung bezieht sich auf die Verwendung der PUR-Funktion. Auf der Grundlage der vom UE in PURConfigurationRequest angeforderten TBS kann das Netzwerk dem UE eine Reihe von Parametern zur Verfügung stellen, die eine bestimmte TBS für die PUR-Übertragung vorschreiben.
• Als potenzielle neue Bedingung für NR kann es zusätzliche Anforderungen für TBS geben, die für nachfolgende PUR-Übertragungen zu verwenden sind, und dementsprechend könnte die zulässige maximale TBS-Größe für die nachfolgenden PUR-Übertragungen und/oder die zulässige Anzahl der nachfolgenden PUR-Übertragungen, die durchgeführt werden, während sich ein UE in RRC_INACTIVE befindet, definiert werden.
• 6. Als eine mögliche neue Bedingung kann ein UE verlangen, dass es einen bestimmten Funkträger oder DRB eingerichtet/konfiguriert hat, der es dem UE ermöglicht, PUR auszulösen und/oder zu unterscheiden.
• Wenn ein UE in RRC_INACTIVE die oben genannten Bedingungen erfüllt und die Verwendung der PUR-Funktion auslöst, stellt sich als nächstes die Frage, wie das UE das Netzwerk informieren oder ihm anzeigen kann, ob mehr als eine Übertragung oder ein Austausch erforderlich ist. Nachfolgend sind einige der Möglichkeiten aufgeführt, wie ein UE dem Netzwerk die Menge an UL SDT anzeigen könnte (beachten Sie, dass einige Anzeigen bereits für LTE EDT- oder PUR-Funktionen in Betracht gezogen wurden, während andere in dieser Offenbarung/Erfindung neu sind).
1. 1. BSR-Wiederverwendung oder Aktualisierung der alten BSR-Anzeige, wobei das UE die BSR zusammen mit dem RRCResumeRequest in die PUR-Übertragung aufnehmen könnte.
2. 2. Als mögliche neue UL-Anzeige eine neue Form der PUR-bezogenen Anzeige über die Größe der im Puffer des UE gespeicherten Daten.
3. 3. Als potenzielle neue UL-Angabe eine neue Form der PUR-bezogenen Angabe über die Anzahl der nachfolgenden Pakete (oder PUR-Austauschvorgänge), die das UE benötigt, um die im Puffer des UE gespeicherten Daten zu übertragen.
4. 4. Als mögliche neue UL-Anzeige eine neue Form der PUR-bezogenen Anzeige, die als allgemeine Anzeige definiert ist, dass in seinem UL-Puffer weitere Daten zum Senden bereitstehen.
• Es ist zu beachten, dass jede dieser Meldungen als Teil einer neuen oder bestehenden RRC-MSG, MAC-CE oder des Headers der Datennutzlast enthalten sein kann. Darüber hinaus kann dies auch vom UE bei der ersten Anforderung der PUR-Konfiguration vom Netzwerk angegeben werden, z.B. wenn das UE daran interessiert ist, mehrere SDT-PUR-Übertragungen zu senden. Das Netzwerk kann jede dieser verschiedenen Angaben verwenden, um zu ermitteln, ob ein UE eine der folgenden Aktionen durchführen darf:
1. (a) Austausch mehrerer SDT-PURs im Zustand RRC _INACTIVE oder
2. (b) Übertragung (oder Rückfall) in den Modus RRC_CONNECTED, oder
3. (c) Auslösung eines Fehlers bei der Nutzung oder Fortsetzung des SDT-PUR-Betriebs
• Verwendung von Configured Grant für SDT-PUR Übertragungen
• Configured Grant (CG) wurde für NR definiert, um das dynamische UL-Scheduling-Verfahren zu ergänzen und UE's mit (semi-)periodischem UL-Verkehr die Zuteilung von Ressourcen zu ermöglichen, ohne den zusätzlichen Signalisierungs-Overhead für die Anforderung von Ressourcen für einzelne Übertragungen auf sich nehmen zu müssen. Allerdings wird dieser Vorgang derzeit nur von RRC CONNECTED UEs unterstützt. In Anbetracht des SDT-PUR-Designs in LTE und der Verwendung von vorkonfigurierten Ressourcen für die Übertragung durch das UE im RRC_INACTIVE-Modus erscheint es sinnvoll zu prüfen, wie das konfigurierte Grant-Design erweitert werden kann, um die gleiche/ähnliche Funktionalität im RRC INACTIVE-Modus zu bieten. In diesem Zusammenhang können zumindest die folgenden Optionen in Betracht gezogen werden (es ist zu beachten, dass in allen Fällen davon ausgegangen wird, dass das UE ein gültiges Timing Alignment hat):
1. 1. Als erste Option können separate UL-Ressourcen für das UE (vor-)konfiguriert werden, das an einer UL-Übertragung im RRC INACTIVE-Modus interessiert ist. Diese können auf der von der UE angeforderten PUR-Konfiguration basieren. Das UE kann dann diese Ressourcen nutzen, um UL-Übertragung(en) im RRC INACTIVE-Modus durchzuführen. Dieses Design ist dem Legacy/LTE-PUR-Design sehr ähnlich, da die vorkonfigurierten Ressourcen, die in RRC_INACTIVE verwendet werden sollen (unter der Annahme eines gültigen Timing Alignments), und alle konfigurierten Grant-Ressourcen, die in RRC_CONNECTED verwendet werden sollen, unabhängig voneinander konfiguriert und verwendet werden.
2. 2. Als zweite Option kann das Netzwerk dem UE eine (vor-)konfigurierte Ressource zur Verfügung stellen (wie bei der ersten Option), aber nach der anfänglichen/ersten PUR-Übertragung in RRC _INACTIVE kann der NW das UE nach RRC_CONNECTED verschieben, basierend auf einem Hinweis in der ersten Übertragung, dass das UE mehr Daten zu senden hat. Dies kann eine der Optionen sein, die in Abschnitt 6.1.3 beschrieben sind. Sobald sich das UE in RRC_CONNECTED befindet, kann es die bereits konfigurierten Grant-Ressourcen nutzen, um die verbleibenden Übertragungen durchzuführen. In diesem Szenario kann das UE (optional) eine Konfigurationsanforderung senden, die vom NW genutzt werden kann, um die entsprechende Konfiguration für die vorkonfigurierten UL-Ressourcen sowie den konfigurierten Grant bereitzustellen. Alternativ kann die Konfiguration für den konfigurierten Grant aktualisiert werden, wenn das UE in den RRC_CONNECTED-Modus versetzt wird.
3. 3. Als dritte Option schließlich kann die dem UE in RRC_CONNECTED zur Verfügung gestellte CG-Konfiguration für die Übertragung in RRC _INACTIVE wiederverwendet werden, anstatt separate Ressourcen zuzuweisen, die vom UE in RRC _INACTIVE verwendet werden sollen. Grundsätzlich ist es dem UE erlaubt, denselben konfigurierten Grant sowohl im RRC _INACTIVE- als auch im RRC_CONNECTED-Modus zu verwenden. Das Netzwerk kann diesen Vorgang explizit steuern, z.B. durch eine explizite Angabe in ConfiguredGrantConfig, ob das UE die Erlaubnis hat, die Erlaubnis im RRC INACTIVE-Modus zu verwenden. Darüber hinaus kann in der Spezifikation auch eine implizite Bedingung definiert werden, die es dem UE erlaubt oder verbietet, die konfigurierten Grant-Ressourcen für die Übertragung in RRC_INACTIVE zu verwenden, z.B. wenn ein konfigurierter Timer (z.B. ConfiguredGrantTimer) abläuft oder wenn das UE nach einer bestimmten Anzahl von Übertragungen nichts mehr sendet. Darüber hinaus können weitere Konfigurationen speziell für RRC_INACTIVE-Szenarien vorgesehen werden, z.B. das Empfangsfenster des DL oder die Antwort auf das vorherige UL PUR
• Es ist zu beachten, dass die Optionen 1 und 2 größtenteils auf dem alten CG-Design basieren, während Option 3 einen neuen Betrieb hinsichtlich der Verwendung von CG für den SDT-Betrieb in RRC _INACTIVE ermöglicht.
• Zeitabgleich und andere MAC-Überlegungen
• Wenn das UE mit einer PUR-Konfiguration ausgestattet ist und die Übertragung mit PUR von RRC initiiert wird, stellt RRC dem MAC die relevanten Informationen zur Verfügung, z.B. die pur-RNTI, die Dauer des PUR-Antwortfensters pur-ResponseWindowSize und die UL-Grant-Informationen. Nachdem das UE die PUR-Übertragung durchgeführt hat, überwacht die MAC-Einheit den PDCCH auf die PUR-RNTI während des Antwortfensters. Je nachdem, was über PDCCH empfangen wird, kann das UE den oberen Schichten mitteilen, ob die Übertragung erfolgreich war, eine erneute Übertragung erforderlich war oder ein Fallback durchgeführt werden muss. Während das Antwortfenster läuft, führt der MAC die folgenden Operationen durch:
• - Wenn die PDCCH-Übertragung für die PUR-RNTI ist und eine UL-Erlaubnis für eine erneute Übertragung enthält:
  • o MAC startet pur-ResponseWindowTimer im letzten Subframe einer PUSCH-Übertragung neu, die der durch die UL-Grant angegebenen erneuten Übertragung plus 4 Subframes entspricht
• - Wenn L1 ACK für die PUR-Übertragung für die untere Schicht empfangen wird oder wenn die PDCCH-Übertragung für die PUR-RNTI erfolgt und die MAC-PDU erfolgreich dekodiert wird:
  • o pur-ResponseWindowTimer anhalten
  • o wenn L1 ACK für die PUR-Übertragung für die untere Schicht empfangen <wird oder die MAC-PDU nur das MAC-Kontrollelement „Timing Advance Command“ enthält:
• MAC zeigt den oberen Schichten an, dass die Übertragung mit PUR erfolgreich war;
• Wenn eine Wiederholungsanpassung für die PUR-Übertragung von den unteren Schichten empfangen wird, zeigt MAC diesen Wert den oberen Schichten an.
• - PUR-RNTI verwerfen.
  • ◯ sonst, wenn Fallback-Anzeige für PUR für untere Schicht empfangen wird:
    • ▪ Wenn die Wiederholungseinstellung für die PUR-Übertragung von den unteren Schichten empfangen wird, zeigt der MAC diesen Wert den oberen Schichten an.
  • - PUR-RNTI verwerfen.
  • - wenn der pur-ResponseWindowTimer abläuft:
    • ◯ zeigt er den oberen Schichten an, dass die PUR-Übertragung fehlgeschlagen ist; verwirft PUR-RNTI.
• Darüber hinaus ist MAC auch für die Aufrechterhaltung eines gültigen Zeitabgleichs für den PUR-Betrieb verantwortlich. Die MAC-Einheit kann durch den pur-TimeAlignmentTimer neben der PUR-Konfiguration durch die obere Schicht versorgt werden und ist für die Aufrechterhaltung des Timers gemäß dem folgenden Verfahren verantwortlich:
• Die MAC-Einheit muss:
• - wenn die pur-TimeAlignmentTimer-Konfiguration von den oberen Schichten empfangen wird:
  • ◯ den pur-TimeAlignmentTimer, starten, falls er nicht läuft.
• - wenn der pur-TimeAlignmentTimer von den oberen Schichten freigegeben wird:
  • ◯ Stoppen des pur-TimeAlignmentTimer, falls er läuft.
• - wenn ein Timing Advance Command MAC-Steuerelement empfangen wird oder PDCCH eine Zeitverschiebung anzeigt:
  • ◯ den Timing-Advance-Befehl oder die Timing-Advance-Anpassung anwenden;
  • ◯ Start oder Neustart des pur-TimeAlignmentTimer, falls konfiguriert.
• Das MAC-Verfahren ist in vielerlei Hinsicht dem bisherigen RACH-Betrieb sehr ähnlich und kann relativ einfach in das NR-Design übernommen werden, um den PUR-Betrieb zu ermöglichen. Insbesondere kann das oben beschriebene Verhalten dem UE in Bezug auf den Zeitabgleich und andere MAC-Vorgänge vom LTE-PUR-Betrieb auch auf den NR-SDT-Betrieb übertragen werden.
• Anwendbare Szenarien und Lösungen zur Ermöglichung von SDT-PUR-Übertragungen in NR Szenario (PUR-O-A): UL/DL PUR durch ein UE in RRC_INACTIVE
• 10 ist ein Flussdiagramm des Szenarios (PUR-0-A), das das Basisszenario für den Fall zeigt, dass ein UE in RRC_INACTIVE eine SDT-PUR-Übertragung unter Verwendung des LTE-Mechanismus in NR durchführt. Das Szenario (PUR-0-A) UL PUR für ein UE in RRC _INACTIVE basiert auf einem alten LTE-Mechanismus in NR.
• Die Einzelheiten zu den Schritten des in 10 dargestellten Szenarios (PUR-0-A) werden im Folgenden beschrieben:
• - Schritt 501) Das UE kann dem Netzwerk optional anzeigen, wann es SDT-PUR zu übertragen wünscht, indem es die entsprechende PUR-Konfiguration auf der Grundlage der jeweiligen Anwendung(en) der oberen Schicht anfordert.
• - Schritt 502) Das Netz zeigt dem UE an, ob der PUR akzeptiert wird oder verwendet werden kann, indem es die entsprechende PUR-Konfiguration bereitstellt (einschließlich z.B. der Periodizität und des Zeitversatzes für PUR-Anlässe, der TBS-Größe, die für die folgende UL-PUR-Übertragung gewährt wird, usw.).
• - Schritt 503) Eine RRC-Nachricht (z. B. RRCResumeRequest) wird von dem UE über SRB0 unverschlüsselt oder mit Integritätsschutz gesendet und enthält mindestens die UE-ID (z.B. Resume-ID), MAC-I und möglicherweise einen Ursachenwert (der speziell für SDT-PUR-Anwendungsfälle definiert werden kann). Diese RRC-Nachricht könnte mit anderen Signalen (die über SRB 1/2 gesendet werden) oder Daten (die über DRB gesendet werden) gemultiplext werden, die jedoch mit den Sicherheitsschlüsseln, die vom NCC in einer vorherigen RRCRelease-Nachricht generiert wurden, verschlüsselt und integritätsgeschützt werden können.
• - Schritt 504) Wenn UL SDT-PUR erfolgreich ist und die RRC-Verbindung nicht wieder aufgenommen werden muss, sendet der gNB eine RRC-Nachricht (wie z.B. RRCRelease) verschlüsselt und integritätsgeschützt über SRB1 an das UE, um das UE in RRC_INACTIVE zu halten und gleichzeitig aktualisierte Informationen zu liefern, wie z.B. suspendConfig (die u. a. einen neuen nextHopChainingCount (NCC) enthält), die für die künftige Verwendung, z.B. bei nachfolgenden SDT-PUR oder bei der Wiederaufnahme, bereitgestellt werden.) Diese RRC-Meldung könnte mit anderen Signalen oder Daten gemultiplext werden (z. B. Time Advance-Befehl), die alle ebenfalls verschlüsselt und mit den Sicherheitsschlüsseln geschützt werden, die durch den in einer früheren RRCRelease-Meldung bereitgestellten NCC erzeugt wurden.)
• Basierend auf der obigen Beschreibung würden, wenn mehr als eine UL(/DL) SDT-PUR-Nachricht über das Szenario (PUR-0-A) ausgetauscht werden muss, die SDTs als aufeinanderfolgende, unabhängige Übertragungen behandelt werden. 11 zeigt z.B. den erwarteten Vorgang zum Senden von 2 UL-Datenpaketen über den in Szenario (PUR-0-A) dargestellten Mechanismus. Es ist wichtig zu betonen, dass dieser Ansatz keine Segmentierung zulässt (da die RLC wiederhergestellt wird, wenn das UE die RRC-Freigabe erhält), und das UE die PUR-Übertragung für jedes Paket unabhängig durchführen muss. Alternativ könnte das UE bei der ersten PUR-Übertragung eine BSR-ähnliche Anzeige senden, die mit RRCResumeRequest (oder einer anderen RRC-Nachricht, die zur Initiierung der PUR verwendet wird) gemultiplext wird. Dadurch würde das Netzwerk erkennen, dass das UE in den Zustand RRC CONNECTED versetzt werden muss, um die verbleibenden Daten zu übertragen (in diesem Fall würde der gNB den Fallback-Mechanismus zur Wiederaufnahme der Verbindung auslösen, wie unten erläutert).
• Wie in 11 dargestellt, sendet das UE im Szenario (PUR-0-A) 2 (separate) UL-PUR-Übertragungen.
• Tabelle 6 fasst die betrieblichen Details zusammen, die das Szenario (PUR-0-A) beschreiben, das aus einer einzelnen UL-PUR-Übertragung gefolgt von einer optionalen DL-Übertragung durch ein UE in RRC _INACTIVE besteht. Alle neuen Informationen oder Mechanismen, die in Rel-15/16 NR nicht definiert sind (auch wenn sie mit den in Rel-15/16 LTE definierten übereinstimmen) und die erforderlich sind, um das Szenario (PUR-0-A) zu ermöglichen, sind unterstrichen und fett gedruckt. Tabelle 6 . Betriebliche Details für Szenario (PUR-0-A) UL(/DL) SDT-PUR durch ein UE in RRC_INACTIVE

  Themen	Szenario (PUR-0-A): UL/DL SDT durch ein UE in RRC_INACTIVE
  Ressourcennutzung	Netzwerk kann spezifische Ressourcen pro UE für PUR-Übertragung zuweisen
  UL Nachricht	RRCResumeRequest like (gesendet über SRB0) und UL-Daten (gesendet über DRB) werden gemultiplext. Potenziell können auch andere Signalisierungen (gesendet über SRB1 oder sogar SRB2) gemultiplext werden
  DL Nachricht	Freigabe-Ereignis (*1)
  Für jeden zukünftigen N th UL SDT-PUR	Für jede zukünftige N-te UL SDT-PUR k.A., da wir nur 1 UL (und optional 1 DL) Übertragung haben
  Für jeden zukünftigen N th DL SDT-PUR	Für jede zukünftige N-te UL SDT-PUR k.A., da wir nur 1 UL (und optional 1 DL) Übertragung haben
  RLC Entität verwendet für mehrere SDT	N/A
  Freigabe-Ereignis(*1)	RRCRelease artig (gesendet über SRB1) und optional andere Signalisierung (gesendet über SRB1 oder sogar SRB2) und/oder DL-Daten (gesendet über DRB) können gemultiplext werden.
  Freigabe von PUR	Kann implizit erfolgen, wenn die Ressource für eine konfigurierte Anzahl von aufeinanderfolgenden Gelegenheiten nicht genutzt wurde oder das UE in eine andere Zelle wechselt. Das UE kann die Freigabe auch explizit beantragen.
  Rekonfiguration von PUR oder anderen Konfig.	PURConfiguration kann verwendet werden, um die PUR-Konfiguration zu rekonfigurieren (z. B. innerhalb von RRCRelease, wenn das UE zu RRC INACTIVE wechselt)
  Time Alignment	Kann vom Netzwerk zusammen mit der RRCRelease-Nachricht (wie) als MAC CE bereitgestellt werden
  PDCCH Überwachung für ACK oder DL SDT-PUR	Für ACK oder DL SDT-PUR Überwachung von PDCCH, identifiziert durch PUR-RNTI im PUR-Antwortfenster unter Verwendung des Timers pur-ResponseWindowTimer für ACK oder UL Grant für Neuübertragung oder Rückfall
  Messungen	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messbericht	N/A
  RNAU (periodisch oder nicht)	Anwendbar wie für ein altes UE in RRC _INACTIVE
  Kurznachrichtüberwachung für SI Notifikation	Anwendbar wie für ein altes UE in RRC _INACTIVE
  BSR artig	N/A.
  Konfigurierte Grant Nutzung	Kann verwendet werden, wenn es vom Netzwerk bereitgestellt und erlaubt wird
  Paging Überwachung	Anwendbar wie für ein altes UE in RRC _INACTIVE Eine neue Handhabung könnte erforderlich sein, wenn das UE sowohl PUR-RNTI als auch P-RNTI im selben Zeitfenster überwacht
  Aktualisierter NCC	NCC wird bei Empfang von RRCRelease aktualisiert
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	Nicht erlaubt
  UL oder DL Signalisierung	Begrenzt auf die Signalisierung, die mit den Resume/Suspend-Prozeduren verbunden ist, einschließlich der Rückfalloperation in RRC CONNECTED

• Der UL SDT gilt als nicht erfolgreich, wenn das UE nicht die erwartete DL-Bestätigung erhält, z.B. RRCRelease oder, im Falle der Wiederaufnahme, RRCResume oder eine L1-Bestätigung oder einen Time Advance Command. Es ist zu beachten, dass, wenn das Netzwerk einen Rückfall auslöst, um eine neue RRC-Verbindung aufzubauen (über RRC Setup), der UL SDT nicht als erfolgreich angesehen wird (z.B. weil der gNB nicht über die Sicherheitsinformationen und/oder die UE AS-Kontextinformationen verfügt, die zur Entschlüsselung erforderlich sind).
• Szenario (PUR-O-B): UL/DL SDT durch ein UE in RRC INACTIVE, das in RRC CONNECTED zurückfällt
• 12 ist ein Flussdiagramm, das das Basisszenario/den Mechanismus (PUR-0-B) veranschaulicht, das/der in NR in Betracht gezogen werden kann, um kleine Datenübertragungen (SDT) unter Verwendung von PUR in RRC _INACTIVE zu ermöglichen, unter der Bedingung, dass das UE zurückfällt, um die RRC-Verbindung fortzusetzen und in RRC_CONNECTED zu gelangen (ähnlich wie bei der LTE EDT/PUR-Funktion).
• 12 zeigt das Szenario (PUR-0-B)UL SDT-PUR für ein UE in RRC_INACTIVE während der Wiederaufnahme der RRC-Verbindung.
• Die Details zu den Schritten des in 12 dargestellten Szenarios (PUR-0-B)sind wie folgt:
• - Schritt 601-603) Ähnlich wie die für Szenario (PUR-0-A) erläuterten Schritte, wobei jedoch in Schritt 3 möglicherweise eine optionale Angabe aufgenommen werden könnte, um dem Netzwerk anzuzeigen, dass größere UL-Daten zum Senden anstehen (z.B. über BSR oder über eine neue SDT-bezogene Angabe, wie in Abschnitt 6.1.3 erörtert).
• - Schritt 604) Ähnlich wie bei der alten Wiederaufnahme-Prozedur beim Senden der RRCResume-Nachricht, mit dem Vorbehalt, dass der gNB bereits DL-Daten und/oder Signalisierung verschlüsselt und integritätsgeschützt senden kann. Alternativ könnte RRCSetup auch vom Netzwerk gesendet werden, wenn stattdessen eine neue RRC-Verbindung aufgebaut werden muss; in diesem Fall würde die zwischen gNB und dem letzten gNB und AMF ausgetauschte Nachricht anders lauten.
• - Schritt 605) Ähnlich wie bei der alten Wiederaufnahmeprozedur beim Senden der RRCResumeComplete-Meldung
• - Schritt 607) Ähnlich wie in Schritt 4) für Szenario (PUR-0-A) oder Legacy-Suspend-Verfahren erläutert.
• Wenn mehr als ein UL(/DL)-SDT über Szenario (PUR-0-B) unter Verwendung von PUR ausgetauscht werden muss, würden sie als nachfolgende Legacy-Datenübertragungen eines UE in RRC_CONNECTED behandelt werden. 13 ist zum Beispiel ein vereinfachtes Flussdiagramm, das den erwarteten Vorgang zum Senden von 2 UL-Datenpaketen über den in Szenario (PUR-0-B) dargestellten Mechanismus zeigt. Es ist wichtig hervorzuheben, dass dieser Ansatz jede Operation erlaubt/erfordert, die von einem UE in RRC_CONNECTED möglich ist (z.B. Messungen einschließlich ihrer Berichterstattung, Handover, RRC-Rekonfiguration, Scheduling-Anfrage, Verwendung von konfiguriertem Grant usw.), und dass das UE kontinuierlich PDCCH überwachen würde (es sei denn, das UE geht in C-DRX).
• Tabelle 7 fasst die betrieblichen Details zusammen, die das Szenario (PUR-0-B) UL SDT mit PUR durch ein UE in RRC_INACTIVE und die Wiederaufnahme der RRC-Verbindung beschreiben, um das UE für weitere Datenübertragungen in RRC_CONNECTED zu überführen.
• Die wichtigsten Änderungen für Szenario/Lösung (PUR-0-B) im Vergleich zum SDT-Basisbetrieb (beschrieben in Szenario (PUR-O-A)) ist, dass es eine BSR-ähnliche Anzeige für das UE gibt, um anzuzeigen, dass es mehr Daten zu senden hat (z. B. N > 1) Tabelle 7 Betriebliche Details für Szenario (PUR-0-B) UL(/DL) SDT-PUR durch eine UE in RRC_INACTIVE.

  Themen	Szenario (PUR 0-B): UL SDT durch ein UE in RRC_INACTIVE bei Wiederaufnahme der RRC-Verbindung, um das UE in RRC CONNECTED zu überführen
  Ressourcennutzung	Netzwerk kann spezifische Ressourcen pro UE für die PUR-Übertragung zuweisen
  UL Nachricht	Wie RRCResumeRequest (gesendet über SRB0) und UL-Daten (gesendet über DRB) werden gemultiplext. **Optional kann eine BSR-ähnliche Anzeige für das UE enthalten, um anzuzeigen, dass es mehr Daten zu senden hat (z. B. N > 1)**
  DL Nachricht	Freigabe-Ereignis (siehe unten)
  Für jeden zukünftigen N th UL SDT-PUR	Kann erfolgen, wenn sich das UE im RRC CONNECTED-Modus befindet
  Für jeden zukünftigen N th DL SDT-PUR	Kann erfolgen, wenn sich das UE im RRC CONNECTED-Modus befindet
  RLC Entität verwendet für mehrere SDT	Anwendbar wie für ein UE im RRC CONNECTED-Modus
  Freigabe-Ereignis (*1)	RRCRelease wie (gesendet über SRB1) und optional andere Signalisierung (gesendet über SRB1 oder sogar SRB2) und/oder DL-Daten (gesendet über DRB) können gemultiplext werden.
  Freigabe von PUR	Kann implizit erfolgen, wenn die Ressource für eine konfigurierte Anzahl von aufeinanderfolgenden Gelegenheiten nicht genutzt wurde oder das UE in eine andere Zelle wechselt. Das UE kann die Freigabe auch explizit beantragen
  Rekonfiguration von PUR oder andere Konfig.	PUR-Konfiguration kann verwendet werden, um die PUR-Konfiguration zu rekonfigurieren (z.B. innerhalb von RRCRelease, wenn das UE zu RRC INACTIVE wechselt)
  Time Alignment	Kann vom Netzwerk zusammen mit der RRCRelease-Nachricht (wie) als MAC CE bereitgestellt werden
  PDCCH Überwachung für ACK oder DL SDT-PUR	Für ACK oder DL SDT-PUR Anfängliche Überwachung von PDCCH, identifiziert durch PUR-RNTI im PUR-Antwortfenster unter Verwendung des Timers pur-ResponseWindowTimer für ACK oder UL Grant für Neuübertragung oder Rückfall Nachdem die UE zu RRC CONNECTED wechselt, kontinuierlich oder C-DRX (wie bei einer alten RRC CONNECTED UE)
  Messungen	Anwendbar wie für ein UE in CONNECTED
  Messbericht	Anwendbar wie für ein UE in CONNECTED
  RNAU (periodisch oder nicht)	NA
  Kurznachrichtüberwachung für SI Notifikation	Anwendbar wie für ein altes UE in RRC - CONNECTED
  BSR artig	Anwendbar, nachdem das UE in RRC CONNECTED ist
  Konfigurierte Grant Nutzung	Anwendbar, nachdem das UE in RRC CONNECTED ist
  Paging Überwachung	Anwendbar wie für ein altes UE in RRC CONNECTED
  Aktualisierter NCC	NCC wird bei Empfang von RRCRelease aktualisiert
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	Erlaubt (wie in RRC CONNECTED)
  UL oder DL Signalisierung	Erlaubt (wie für ein altes UE in RRC_INACTIVE und RRC_CONNECTED)

• Szenario (PUR-1): Mehrere UL/DL-SDTs durch ein UE in RRC INACTIVE unter Verwendung eines Teils des Resume/Suspend-Verfahrens (RRC-basiertes SDT-PUR)
• Szenario (PUR-1) beschreibt einen neuen Mechanismus für ein UE in RRC - INACTIVE, um mehrere Daten- oder Signalisierungspakete/PDUs auszutauschen, ohne dass das UE in RRC_CONNECTED übergehen muss, während es sich in der gleichen SDT/PUR-Prozedur befindet. Ein Grund für die Verwendung dieses neuen Mechanismus anstelle des Übergangs des UE in RRC_CONNECTED (wie in Szenario (PUR-0-B)erläutert) ist, dass die UL-Daten des UE nicht alle in die zugewiesenen vorkonfigurierten Ressourcen passen, weshalb das UL-Datenpaket zwar segmentiert ist, aber nicht viele Daten enthält und es daher vorzuziehen ist, das UE in RRC INACTIVE zu halten.
• Die Vorteile des Szenarios (PUR-1) bestehen darin, dass a) es eine vereinfachte Version des Wiederaufnahmeverfahrens ermöglicht, bei dem das UE nicht die gesamte ausgesetzte Konfiguration, die im AS-Kontext des UE gespeichert ist, wieder aufnehmen (oder sogar neu konfigurieren) muss, und b) das UE nicht alle Funktionen und Konfigurationen unterstützen oder aktivieren muss, die mit einem UE in RRC_CONNECTED verbunden sind (z.B. RLF, Mobilität/Handover, Wiederherstellung, CA/DC, MIMO, Meldung der Kanalqualität, Änderung des BWP-Betriebs/der BWP-Konfiguration usw.). Zusätzlich kann das UE optional die konfigurierten Grant-Ressourcen nutzen, die zuvor im RRC_CONNECTED-Zustand bereitgestellt wurden, um SDT-PUR durchzuführen, was den Signalisierungs-Overhead eines vollständigen Übergangs zu RRC_CONNECTED reduzieren würde.
• 14 ist ein Flussdiagramm, das einen neuen Mechanismus zusätzlich zum Basisszenario (PUR-0) veranschaulicht, der es dem UE ermöglicht, das Szenario/die Lösung (PUR-1) für ein UE in „RRC INACTIVE“ zu aktivieren, um mehrere DL/UL-SDT (ohne Übergang zu RRC_CONNECTED) unter Verwendung vorkonfigurierter Ressourcen auszutauschen, vorausgesetzt, es verfügt über einen gültigen Zeitabgleich (es ist zu beachten, dass dies auch gilt, wenn das UE konfigurierte Grant-Ressourcen verwenden darf, während es sich in RRC _INACTIVE befindet). Während das UE in „RRC INACTIVE“ SDT austauscht, kann es immer noch als RRC _INACTIVE betrachtet werden, oder es kann ein neuer Name oder Zustand definiert werden, z. B. „RRC_INACTIVE limbo“ oder „RRC_INACTIVE plus“ oder „PSEUDO-INACTIVE“ unter anderen, um den Übergangszustand darzustellen, wenn das UE nicht vollständig in RRC _INACTIVE oder in RRC_CONNECTED ist. Weitere Einzelheiten zu diesem Übergangszustand werden im Folgenden beschrieben.
• 14 zeigt das Szenario (PUR-1), das mehrere N UL/DL SDT ermöglicht, während das UE in RRC _INACTIVE bleibt (RRC-basiertes SDT-PUR), wobei ein Teil des Resume/Suspend-Verfahrens verwendet wird.
• Die Einzelheiten zu den Schritten des in 14 dargestellten Szenarios (PUR-1) werden im Folgenden beschrieben:
• - Schritt 701-703) Ähnlich wie die für Szenario (PUR-0-A) erläuterten Schritte, aber zusätzlich mit einer optionalen Anzeige in Schritt 3, um das Netzwerk zu benachrichtigen, dass größere UL-Daten zum Senden anstehen. Diese UL-Benachrichtigung über die Menge der UL-SDT kann über RRC oder MAC CE oder innerhalb des Headers der Datennutzlast erfolgen, ähnlich wie bei Szenario (PUR-0-B), bei dem die alten BSR wiederverwendet oder aktualisiert werden. Alternativ könnte eine neue Form von SDT-bezogener Anzeige definiert werden, um diese UL-Benachrichtigung über (a) die Größe der zu sendenden Daten oder (b) die Menge der nachfolgenden Pakete oder (c) eine allgemeine Anzeige, dass mehr Daten in seinem UL-Puffer vorhanden sind, die über SDT gesendet werden sollen, bereitzustellen.
• - Danach könnten UE und gNB mehrere UL- und DL-SDT über vorkonfigurierte Ressourcen oder konfigurierte Grant-Ressourcen austauschen, wie weiter unten erläutert.
• - Schritt 705) Ähnlich wie in Schritt 4) für das Szenario (PUR-0-A) erläutert, oder altes Suspend-Verfahren zum Abschluss des Austauschs mehrerer SDT, z.B. Bereitstellung aktualisierter SuspendConfig (z. B. neuer NCC) und anderer.
• Wenn mehr als ein UL(/DL) SDT unter Verwendung des Mechanismus in Szenario (1) ausgetauscht werden muss, wird ein neuer Mechanismus verwendet, bei dem das UE in „RRC INACTIVE“ verbleibt, mit einigen Unterschieden zu dem hier beschriebenen Legacy-Verfahren; der Einfachheit halber wird es hier als „RRC_INACTIVE plus“ bezeichnet. Während sich das UE in „RRC_INACTIVE plus“ befindet, wird eine UE-ID auf UE- und Netzwerkseite beibehalten (z.B. die dem UE in pur-Config zugewiesene PUR-RNTI, C-RNTI oder I-RNTI), das UE überwacht auch die PDCCH und nimmt die zu verwendende Konfiguration wieder auf. Je nachdem, welche Konfigurationen verwendet werden, werden zwei Optionen in Betracht gezogen:
• - Option (A) Das UE nimmt die Standardkonfigurationen oder die vom Netzwerk vorkonfigurierten Konfigurationen wieder auf (die in der Spezifikation definiert sein können oder dem UE z.B. über SIB oder im Zustand RRC_CONNECTED oder bei der Freigabe zur Verfügung gestellt werden).
• - Option (B): Das UE nimmt nur einen Teil der gespeicherten Konfigurationen innerhalb des UE-AS-Kontextes wieder auf. Welcher Teil der gespeicherten Konfiguration für SDT wiederaufgenommen wird, könnte in der Spezifikation festgelegt und/oder vom Netzwerk für das UE konfiguriert werden. Es ist zu beachten, dass das UE möglicherweise bereits einen Teil der gespeicherten Konfiguration für die über PUR gesendeten Daten verwendet.
• Es sei darauf hingewiesen, dass bei dieser Lösung einige zusätzliche Aspekte zu berücksichtigen sind, wenn man die Aufteilung zwischen zentraler Einheit (CU) und verteilter Einheit (DU) im Netzwerk in Betracht zieht. Insbesondere kann es sein, dass die DU aufgrund dieser Aufteilung keine RLC-Instanz behält, während sich das UE in RRC_INACTIVE befindet. Damit der nachgeschaltete Anwender in der Lage ist, die UE-Daten zu verarbeiten, muss der relevante UE-Kontext entweder beibehalten oder vom nachgeschalteten Anwender beschafft werden. In diesem Fall gibt es eine Reihe zusätzlicher Schritte für den DU, um die relevante RB-Konfiguration als Teil des UE-Kontextes von der ZB zu erhalten, bevor eine nachfolgende Übertragung stattfindet.
• 15 zeigt den erwarteten Vorgang zum Senden von 2 UL-Datenpaketen über den in Szenario (PUR-1) dargestellten Mechanismus mit den beiden oben beschriebenen Optionen A und B. Es ist zu beachten, dass es mehrere Möglichkeiten gibt, wie die nachfolgenden DL-Übertragungen geplant werden können, z.B. durch einen UL-Grant für die Übertragung zusammen mit der L1-ACK, separat, nachdem die UE auf „RRC_INACTIVE plus“ wechselt, oder nachdem die UE explizit eine SR sendet, usw.:
• Siehe 15, die Schlüsseloperation des UE zum Senden von 2 UL-Datenpaketen über den Mechanismus von Szenario (PUR-1).
• Während der Schwerpunkt hier hauptsächlich auf der Ermöglichung mehrerer UL-SDT liegt, müssen wir darauf hinweisen, dass jede DL-SDT optional folgen kann, beispielsweise unter Berücksichtigung eines ähnlichen Ansatzes wie bei den alten LTE-PUR. Im Wesentlichen kann das UE durch Überwachung der PUR-RNTI innerhalb des pur-ResponseWindowTimer mit DL-Daten/Signalen sowie UL-Grant für die erneute Übertragung des gerade gesendeten UL-SDT versorgt werden. Darüber hinaus können untergeordnete UL(/DL)-SDT ausgetauscht werden, wie in den vorherigen 6 und 7 erläutert. In diesem Fall sind mehrere neue Optionen möglich, wie die nachfolgenden UL(/DL)-SDT von der UE geplant/ausgeführt werden können (der Einfachheit halber als „subsequent SDT operation“ bezeichnet):
1. 1. Das UE kann die nächste verfügbare PUR-Gelegenheit gemäß der zuvor empfangenen pur-Config nutzen
2. 2. Das UE kann den UL Grant, der mit dem vorherigen DL SDT vom Netzwerk angegeben wurde, für die weitere UL Datenübertragung nutzen.
3. 3. Das UE überwacht PUR-RNTI in einem erweiterten oder anderen Fenster, das für die UE konfiguriert oder vorkonfiguriert werden kann, um nach der ersten SDT-Übertragung verwendet zu werden. Diese Konfiguration kann dem UE zur Verfügung gestellt werden, wenn es zuvor RRC_CONNECTED über dedizierte Signalisierung war, oder während sich das UE in RRC_INACTIVE über Broadcast-Signalisierung befindet.
4. 4. Das UE sendet einen Scheduling Request (SR), um eine UL-Zuteilung über SR-Ressourcen zu erhalten, die nach der ersten Datenübertragung mit PUR aktiviert werden können.
5. 5. Das UE kann auf Random Access umschalten (über 2-Step oder 4-Step RACH), wenn es keine gültige SR-Konfiguration hat, um Ressourcen für SDT anzufordern. Dies kann auch als Grund für das Netzwerk definiert werden, den Rückfall zu RRC_CONNECTED auszulösen (anstatt das UE in RRC_INACTIVE plus zu halten). Alternativ kann das UE auch in RRC INACTIVE plus verbleiben, z.B. wenn 2-Schritt-RACH verwendet werden kann.
• Tabelle 8 fasst die betrieblichen Details zusammen, die das Szenario (PUR-1) beschreiben, in dem mehrere UL/DL SDT unter Verwendung von PUR übertragen werden können, während das UE in „RRC INACTIVE“ bleibt. Durch grüne Unterstreichung und Sternchen am Anfang und Ende werden die wichtigsten Änderungen für Szenario/Lösung (PUR1) im Vergleich zum Basis-SDT-Fortsetzungs-/Suspend-Betrieb (beschrieben in Szenario (PUR-0-A)) dargestellt. Tabelle 8: Betriebliche Details für Szenario (PUR-1), das mehrere N UL/DL SDT ermöglicht, während das UE in RRC_INACTIVE bleibt (RRC-basierter SDT-PUR), unter Verwendung eines Teils des Resume/Suspend-Verfahrens.

  Themen	Szenario (PUR-1): Mehrere UL/DL-SDT durch ein UE in RRC INACTIVE
  Ressourcennutzung	Wie in Option (0-A)
  UL Nachricht	Wie in Option (0-A) mit optionaler Einbeziehung von BSR ** oder einer anderen Form der Anzeige, um das Netzwerk zu informieren, dass das UE mehr Daten zu senden hat (z.B. N > 1 SDT). Diese Angabe kann über RRC oder MAC oder sogar innerhalb des Datenkopffeldes erfolgen. Dabei kann es sich um eine explizite Angabe der zu sendenden Daten oder der Anzahl der erforderlichen Pakete oder SDT handeln oder einfach um die Angabe, dass weitere Daten oder Pakete über SDT auszutauschen sind oder nicht. **
  DL Nachricht	Freigabe-Ereignis (siehe unten)
  Für jede zukünftige N th UL SDT-PUR	**Kann über PUR- und/oder CG-Ressourcen unter Verwendung desselben NCC erfolgen, der in der vorhergehenden Freigabenachricht bereitgestellt wurde. Es gelten die oben für den** „nachfolgenden SDT-Betrieb“ beschriebenen Optionen.
  Für jede zukünftige N th DL SDT-PUR	**Kann unter Verwendung derselben RLC-Einheit und desselben NCC, der in der vorhergehenden Freigabenachricht angegeben wurde, gesendet werden. Es gelten die für** „subsequent SDT operation“ oben beschriebenen Optionen.
  RLC Entität verwendet für mehrere SDT	**Dieselbe RLC-Einheit, die verwendet wird, während sich die UE in „RRC INACTIVE plus“ befindet (z.B. wird kein NCC zwischen den nachfolgenden UL/DL SDT-PDUs aktualisiert)**
  Freigabe-Ereignis (*1)	RRCRelease artig (gesendet über SRB1) und optional andere Signalisierung (gesendet über SRB1 oder sogar SRB2) und/oder DL-Daten (gesendet über DRB) können gemultiplext werden.
  Freigabe von PUR	Kann implizit erfolgen, wenn die Ressource für eine konfigurierte Anzahl von aufeinanderfolgenden Gelegenheiten nicht genutzt wurde oder das UE in eine andere Zelle wechselt. Das UE kann die Freigabe auch explizit beantragen
  Rekonfiguration von PUR oder andere Konfig.	PURConfiguration kann verwendet werden, um die PUR-Konfiguration zu rekonfigurieren (z.B. innerhalb von RRCRelease, wenn das UE zu RRC INACTIVE wechselt)
  	**Mögliche Wege zur Bereitstellung einer neuen Konfiguration sind:
  	a) DL PDU trägt RRCReconfiguration. Die Antwort des UE über RRCReconfigurationComplete ist möglicherweise nicht erforderlich, z.B. wenn sie im Multiplex mit RRCRelease gesendet wird.
  	b) Definition neuer IEs bei RRCRelease**
  	c) einen Rückfall auslösen, um das UE in RRC - CONNECTED zu bringen.
  Time Alignment	Kann vom Netzwerk zusammen mit der RRCRelease-Nachricht (wie) als MAC CE bereitgestellt werden.
  	**Kann auch bereitgestellt werden, während sich das UE in „RRC_INACTIVE plus“ befindet, z.B. mit den gesendeten Daten**
  PDCCH Überwachung für ACK oder DL SDT-PUR	Überwachung von PDCCH, identifiziert durch PUR-RNTI im PUR-Antwortfenster unter Verwendung des Timers pur-ResponseWindowTimer für ACK oder UL Grant für Neuübertragung oder Rückfall.
  	**Mögliche Erweiterungen zur diskontinuierlichen Überwachung von PDCCH (während sich die UE in RRC_INACTIVE plus befindet) sind:
  	a) Wenn das Netzwerk den DL SDT sendet, zeigt es auch die zukünftige DL/UL-Ressourcenzuweisung an.
  	b) Das UE überwacht PDCCH nur in seinem alten PF/PO, um mögliche zukünftige UL/DL SDT oder Zuweisungen zu prüfen.
  	c) Das UE folgt einem diskontinuierlichen Überwachungsmechanismus ähnlich wie C-DRX, um künftige DL/UL-SDT-Zuweisungen zu prüfen.
  	d) Das UE ist mit Ressourcen für seinen zukünftigen UL/DL SDT oder die Überwachung des PDCCH (vor)konfiguriert. Für alle möglichen Optionen könnte die Überwachung von PDCCH oder Zuweisungen als Einzelereignis oder als ein Ereignis definiert werden, auf das das UE während eines Zeitfensters prüft, das für das UE definiert/konfiguriert werden könnte**.
  Messungen	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messbericht	** Eine mögliche Erweiterung zur Ermöglichung der Berichterstattung über Messungen ist die Berichterstattung ähnlich der Berichterstattung über frühe Messungen (basierend auf Messungen, die von einem UE in RRC _INACTIVE durchgeführt wurden). Dies könnte für das Netzwerk von Vorteil sein, um das UE entsprechend zu rekonfigurieren, z.B. in den Konfigurationen, die für laufende/künftige SDT unter Verwendung von PUR verwendet werden sollen **.
  RNAU (periodisch oder nicht)	Anwendbar wie für ein altes UE in RRC INACTIVE
  Kurznachrichtüberwachung für SI Notifikation	Anwendbar wie für ein altes UE in RRC INACTIVE
  BSR artig	Ja
  Konfigurierte Grant Nutzung	**Kann vom Netzwerk für die Übertragung von SDT in RRC INACTIVE plus konfiguriert werden, wie zuvor erläutert**.
  Paging Überwachung	Überwachung Anwendbar wie für ein altes UE in RRC INACTIVE Eine neue Handhabung könnte erforderlich sein, wenn das UE sowohl PUR-RNTI als auch P-RNTI im gleichen Zeitfenster überwacht
  Aktualisierter NCC	NCC wird bei Empfang von RRCRelease aktualisiert
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	**Erlaubt, ähnlich wie bei einem UE in RRC CONNECTED**
  UL oder DL Signalisierung	Begrenzt auf die Signalisierung im Zusammenhang mit den Resume/Suspend-Verfahren einschließlich des Rückfall-Betriebs in RRC_CONNECTED.
  	**Darüber hinaus könnten anwendbare RRC/MAC-Signale von RRC_CONNECTED von einem UE in RRC_INACTIVE plus verwendet werden, z.B. RRC-Rekonfiguration, UE-Unterstützungsinformationen, um die Präferenz des UE zu übermitteln, in RRC_IDLE zu wechseln (anstatt in RRC INACTIVE zu bleiben), PHR, BSR, TA, Kanalqualität oder SR, neben anderen.**

• Szenario (PUR-2): Mehrere UL/DL SDTs durch ein UE in RRC INACTIVE unter Beibehaltung der Benutzerebene (nicht-RRC-basierte SDT-PUR)
• Szenario (PUR-2) beschreibt einen neuen Mechanismus für ein UE in RRC_INACTIVE, um mehrere Datenpakete/PDUs oder Signalisierung auszutauschen, ohne dass eine RRC-Signalisierung durchgeführt werden muss, während verschiedene nachfolgende SDTs durchlaufen werden. Die Verwendung von Wiederaufnahme/Suspend-ähnlichen Prozeduren beim Austausch von SDT über PUR könnte verwendet werden, wenn das UP beibehalten wird (z.B. RRC-basierter Ansatz), jedoch könnte es für dieses Szenario (PUR-2) noch vorteilhafter sein, wenn der gesamte SDT-Betrieb ohne RRC-Signalisierung ablaufen kann (z.B. nicht-RRC-basierter Ansatz). Im Vergleich zum letzten Szenario besteht eine Motivation zur Verwendung dieses neuen Mechanismus darin, den mit der RRCResumeRequest- und RRCRelease-Signalisierung verbundenen Signalisierungs-Overhead zu vermeiden. Hier kann sich das UE auf die Nutzung vorkonfigurierter Ressourcen verlassen, die für eine einzelne SDT-Übertragung zugewiesen wurden (wie im Altszenario (PUR_0-A)), und indem es dem Netzwerk im ersten SDT mitteilt, dass es weitere Daten zu senden hat, kann das Netzwerk wissen, dass das UE auch untergeordnete segmentierte Daten senden kann, möglicherweise ohne dass eine CP-Signalisierung erforderlich ist.
• 16 zeigt einen neuen Mechanismus zusätzlich zum Basisszenario (PUR_0), der es dem UE erlaubt, das Szenario/die Lösung (PUR-2) für ein UE in RRC _INACTIVE zu aktivieren, um mehrere DL/UL SDT auszutauschen. In Szenario (PUR-2) wird davon ausgegangen, dass das UE zunächst die geltenden SRB/DRBs und den Zustand der Benutzerebene beibehält (der zurückgesetzt wurde, als das UE in RRC_INACTIVE ging, z.B. vor der ersten SDT-PUR-Übertragung). Im Gegensatz zu früheren Lösungen sendet das UE also zunächst SDT und (optional) die UE-ID (weitere Einzelheiten zu möglichen Identitäten werden weiter unten erörtert) über PUR sowie optional einen Hinweis auf weitere zu sendende Daten. Da das Netzwerk die Identität des UE kennt und weiß, ob der Nutzer weitere Daten zu senden hat, kann es eine UL-Freigabe für die weitere Datenübertragung erteilen oder das UE kann auf andere Weise weitere SDT senden (Einzelheiten werden weiter unten erläutert). Besonders hervorzuheben ist, dass die Protokollkonfiguration der Benutzerebene wiederverwendet werden kann und dass in diesem Fall für jeden UL/DL-SDT dieselbe RLC-Einheit verwendet wird, möglicherweise mit demselben (oder sogar aktualisierten) NCC.
• 16 ist ein Flussdiagramm, das das Szenario (PUR-2) veranschaulicht, das mehrere UL/DL SDTs durch ein UE in der RRC_INACTIVE aufrechterhaltenden Benutzerebene ermöglicht (nicht-RRC-basiertes SDT-PUR)
• Die Details zu den Schritten des in 16 dargestellten Szenarios (2) werden im Folgenden beschrieben:
• - Schritt 801-804) Ähnlich wie die für Szenario (PUR-1) erläuterten Schritte, mit dem Unterschied, dass das UE keine RRC-Signalisierung austauschen muss, um mit dem Senden von SDT zu beginnen. Stattdessen sendet es die UE-Identität über UP, und der gNB kann antworten, um den Empfang zu bestätigen, sowie mit allen DL-Daten, die dem UE optional zur Verfügung gestellt werden können. Darüber hinaus kann der gNB auch einen UL Grant für weitere Datenübertragungen bereitstellen. Alternativ kann das UE eine der anderen Optionen für den „nachfolgenden SDT-Betrieb“ verwenden, die in Szenario (1) beschrieben sind.
• - Schritt 805) Nach einem „Burst“ von Datenübertragungen kann der gNB beschließen, den SDT-Betrieb freizugeben/auszusetzen, aber im Gegensatz zu einer herkömmlichen RRC-Freigabe behält das UE die anwendbaren RBs bei und darf den Zustand der Benutzerebene nicht zurücksetzen, so dass jede weitere Datenübertragung in der Zukunft auf ähnliche Weise und ohne RRC-Signalisierung erfolgen kann. Diese Freigabe-/Suspend-Anzeige kann über einen Header (z.B. in MAC, Daten), MAC CE oder sogar RRC-Signalisierung bereitgestellt werden.
• Bei diesem Szenario gibt es einige wichtige Aspekte, die weiter geklärt werden müssen. Erstens kann die Identität des UE ohne RRC-Signalisierung angegeben werden. Einige mögliche Optionen sind die Verwendung von MAC-Headern als Teil der UL-Daten oder die Definition eines neuen MAC-CE, das die UE-ID trägt. Zweitens könnte die UE-Identität auf der zugewiesenen RNTI basieren, die während des INAKTIV-Zustands zu verwenden ist (z.B. I-RNTI oder Resume-Identität), oder auf derjenigen, die mit dem PUR-Betrieb selbst verbunden ist (z.B. PUR-RNTI). Unter der Annahme, dass dem UE vorkonfigurierte Ressourcen konkurrenzfrei zugewiesen wurden, kann das Netzwerk alternativ die UE-Identität implizit aus der für die Übertragung verwendeten Ressource ermitteln, und es ist nicht erforderlich, die UE-ID in die erste UL-Nachricht aufzunehmen. Drittens können, wie in Szenario (1) ausführlich beschrieben, die UL-Ressourcen für künftige SDT jede der dort beschriebenen möglichen Optionen verwenden (z.B. PUR-Ressourcen, UL-Grant, der mit DL SDT empfangen wurde, erweiterte pur-ResponseWindowSize usw.). Viertens: Die Art und Weise, wie der NCC für jeden SDT aktualisiert wird, unterscheidet sich möglicherweise von den vorherigen Optionen. Da das UP beibehalten wird, gibt es für dieses Szenario zwei Optionen, wann der NCC aktualisiert wird:
• - Option a) Nach der Übertragung von N SDTs, wobei N vom Netzwerk gewählt wird und N eine beliebige ganze Zahl größer oder gleich 1 ist.
• - Option b) Der NCC wird nur aktualisiert, wenn das UE das nächste Mal in den Zustand RRC_CONNECTED wechselt (z.B. verwendet das UE den vom gNB bereitgestellten NCC, wenn es zuvor in den Zustand RRC_INACTIVE versetzt wurde, wenn es eine SDT durchführt).
• Wenn das Netz während der SDT eine große Menge an ankommendem Verkehr (z.B. DL-Daten) erwartet, kann es das UE jederzeit in den Zustand RRC CONNECTED versetzen, ohne eine RRCResumeRequest-Nachricht von dem UE erhalten zu haben. Dies ist ein neues Verhalten im Vergleich zum heutigen NR-Design und fügt sich in das Gesamtthema von Szenario (PUR_2) ein, bei dem jegliche RRC-Vereinzelung minimiert wird.
• Wie im Fall von Szenario (PUR_1) besprochen, müssen im Falle eines CU/DU-Splits zusätzliche Aspekte im Zusammenhang mit der Aufrechterhaltung/Erhaltung des UE-Kontextes und der Konfiguration zur Verarbeitung von Daten in RRC _INACTIVE durch den DU berücksichtigt werden.
• Wenn mehr als ein UL(/DL)-SDT über das Szenario (PUR-2) ausgetauscht werden muss, können sie als Teil desselben SDT-Verfahrens behandelt werden, bei dem die Benutzerebene durchgängig beibehalten wird. 17 zeigt zum Beispiel ein Beispiel für den erwarteten Vorgang zum Senden von 2 UL-Datenpaketen über den in Szenario (PUR-2) dargestellten Mechanismus. Wie bereits erwähnt, besteht die Idee nicht darin, RRCResumeRequest- oder RRCRelease-Nachrichten für jede SDT-Übertragung zu senden. Stattdessen werden die meisten der „üblichen“ Verfahren durch UP-Signalisierung durchgeführt. Es ist auch wichtig zu betonen, dass dies nur ein Beispiel dafür ist, wie die folgenden UL SDTs geplant werden können (z.B. PUR für den ersten SDT und SR-Verfahren für den zweiten SDT). Darüber hinaus gelten dieselben Optionen, die für DL SDT diskutiert wurden, auch für das Szenario (PUR-2).
• 17 ist ein vereinfachtes Flussdiagramm, das die Schlüsseloperation des UE zum Senden von 2 UL-Datenpaketen über den in Szenario (PUR-2) dargestellten Mechanismus zeigt.
• Tabelle 9 fasst die betrieblichen Details zusammen, die das Szenario (PUR-2) beschreiben, das mehrere N UL/DL SDT-PUR ermöglicht, während das UE im RRC _INACTIVE verbleibt und den Zustand der Benutzerebene beibehält. Die wichtigsten Änderungen für Szenario/Lösung (PUR-2) im Vergleich zum SDT-PUR-Basisbetrieb (beschrieben in Szenario (PUR-O-A)) sind durch Unterstreichung und Sternchen am Anfang und Ende gekennzeichnet. Tabelle 9 Betriebliche Details für Szenario (PUR-2) Mehrere UL/DL-SDTs durch ein UE in RRC INACTIVE aufrechterhaltender Benutzerebene (nicht-RRC-basierter SDT-PUR)

  Themen	Szenario (PUR-2): UL/DL SDT durch ein UE in RRC INACTIVE
  Ressourcennutzung	Gleich wie Szenario 0-A
  UL Nachricht	Wie Szenario 0-A, ** mit optionaler Einbeziehung von BSR oder einer anderen Form der Anzeige, um das Netzwerk zu informieren, dass das UE mehr Daten zu senden hat (z.B. N > 1 SDT). Dieser Hinweis kann über RRC oder MAC oder sogar innerhalb des Datenkopffeldes erfolgen. Dabei kann es sich um eine explizite Angabe der zu sendenden Daten oder der Anzahl der erforderlichen Pakete oder SDT handeln oder einfach um die Angabe, dass weitere Daten oder Pakete über SDT auszutauschen sind oder nicht.**
  DL Nachricht	Freigabe-Ereignis (siehe unten)
  Für jede zukünftige N th UL SDT-PUR	**Kann über PUR- und/oder CG-Ressourcen erfolgen, wobei entweder der nach N SDTs vom Netzwerk aktualisierte NCC oder der in der vorherigen Freigabenachricht angegebene verwendet wird. Die für den „nachfolgenden SDT-Betrieb“ in Szenario (1) beschriebenen Optionen sind ebenfalls anwendbar.**
  Für jede zukünftige N th DL SDT-PUR	**Kann über PUR- und/oder CG-Ressourcen erfolgen, wobei entweder die nach N SDTs vom Netzwerk aktualisierte NCC oder die in der vorherigen Freigabenachricht angegebene verwendet wird. Die für den „nachfolgenden SDT-Betrieb“ in Szenario (1) beschriebenen Optionen sind ebenfalls anwendbar.**
  RLC Entität verwendet für mehrere SDT	**UP wird beibehalten, während sich die UE in „RRC INACTIVE plus“ befindet, einschließlich RLC- und PDCP-Entitäten, obwohl NCC für UL(/DL)-SDTs aktualisiert werden kann oder nicht**
  Freigabe-Ereignis (*1)	**Das Netzwerk kann optional eine Freigabe-/Suspend-Anzeige nach einem „Burst“ von Daten senden und optional den NCC aktualisieren, aber der Zustand des UE auf der Benutzerebene wird nicht zurückgesetzt**
  Freigabe von PUR	Wie in Szenario 1
  Rekonfiguration von PUR oder andere Konfig.	PURConfiguration kann verwendet werden, um die PUR-Konfiguration zu rekonfigurieren (z.B. innerhalb von RRCRelease, wenn das UE zu RRC INACTIVE wechselt)
  	**Mögliche Wege zur Bereitstellung einer neuen Konfiguration sind:
  	a) DL PDU trägt RRCReconfiguration. Die Antwort des UE über RRCReconfigurationComplete ist möglicherweise nicht erforderlich, z.B. wenn sie im Multiplex mit RRCRelease gesendet wird.
  	b) Definition neuer IEs für RRCRelease
  	c) MAC CE z.B. für die Aktualisierung des Zeitabgleichs
  	d) L1-Anzeige** Alternativ kann der gNB einen Rückfall auslösen, um das UE in RRC_CONNECTED zu bringen, indem es die RRC-Verbindung wieder aufnimmt oder herstellt.
  Time Alignment	Kann vom Netzwerk bereitgestellt werden, während sich das UE in RRC _INACTIVE plus befindet, z.B. als MAC CE zu einem beliebigen Zeitpunkt, z.B. zusammen mit der RRCRelease-Nachricht (wie) oder beim Senden von Verkehr
  PDCCH Überwachung für ACK oder DL SDT-PUR	Wie in Szenario 1
  Messungen	Anwendbar wie für ein altes UE in RRC INACTIVE
  Messbericht	**Eine mögliche Verbesserung zur Ermöglichung der Messberichterstattung ist eine Berichterstattung ähnlich der frühen Messberichterstattung (basierend auf Messungen, die von einem UE in RRC_INACTIVE vorgenommen wurden). Dies könnte für das Netzwerk von Vorteil sein, um das UE entsprechend zu rekonfigurieren, z.B. in den Konfigurationen, die für laufende/künftige SDT unter Verwendung von PUR verwendet werden sollen **.
  RNAU (periodisch oder nicht)	Anwendbar wie für ein altes UE in RRC INACTIVE
  Kurznachrichtüberwachung für SI Notifikation	Anwendbar wie für ein altes UE in RRC INACTIVE
  BSR artig	N/A.
  Konfigurierte Grant Nutzung	**Kann vom Netzwerk für die Übertragung von SDT in RRC INACTIVE plus konfiguriert werden, wie zuvor erläutert**.
  Paging Überwachung	Anwendbar wie für ein altes UE in RRC INACTIVE Neue Handhabung könnte erforderlich sein, wenn das UE sowohl PUR-RNTI als auch P-RNTI im gleichen Zeitfenster überwacht
  Aktualisierter NCC	**NCC kann (a) optional aktualisiert werden, wenn alle N UL(/DL) SDTs ausgetauscht werden, während sie sich in RRC _INACTIVE befinden oder (b) wenn das UE das nächste Mal in RRC CONNECTED übergeht**
  NW Trigger Rückfall zum Wiederaufnehmen	Erlaubt
  NW Trigger Rückfall zum Aufbauen	Erlaubt
  Segmentierung	**Erlaubt, ähnlich wie bei einem UE in RRC_CONNECTED, aber während sich das UE in „RRC INACTIVE plus ‟** befindet
  UL oder DL Signalisierung	Begrenzt auf die Signalisierung im Zusammenhang mit den Resume/Suspend-Verfahren einschließlich des Rückfall-Betriebs in RRC CONNECTED.
  	**Zusätzlich könnten anwendbare RRC/MAC-Signale von RRC CONNECTED von einem UE in RRC_INACTIVE plus verwendet werden, wie z.B. RRC-Rekonfiguration, UE-Unterstützungsinformationen, um die Präferenz des UE zu übermitteln, in RRC_IDLE zu wechseln (anstatt in RRC INACTIVE zu bleiben), PHR, BSR, TA, Kanalqualität oder SR, neben anderen.**

• Abschließend möchten wir darauf hinweisen, dass alle hier beschriebenen Optionen mit eingeschränkter RRC-Signalisierung aktiviert werden können. Stattdessen könnten einige der auszutauschenden Signalisierungsinformationen z.B. als Teil der Paketkopffelder oder als MAC-CEs enthalten sein. Zum Beispiel können RRC Resume Request und RRC Release als Teil der ersten und der letzten Übertragung entfallen. Alternativ kann auch auf andere Weise angegeben werden, wann der SDT-PUR-Austausch beginnt und endet, ebenso wie die UE-ID und andere wichtige Informationen, die nicht unbedingt auf dem Austausch von RRC-Signalen beruhen.
• Auch wenn das UE die SDT mit einem nicht-RRC-basierten Ansatz beginnt, können UE und gNB jederzeit mit dem Senden von RRC-basierter Signalisierung beginnen. Dies kann z.B. hilfreich sein, wenn der gNB das UE in den Zustand RRC_CONNECTED überführen möchte (z.B. durch Senden der RRCResume- oder RRCSetup-Nachricht), oder wenn das UE dem Netzwerk seine Präferenz oder Anforderung für den Übergang in den Zustand RRC_CONNECTED mitteilen möchte (z.B. durch Senden der RRCResumeRequest- oder UEAssistanceInformation-Nachricht).
• SYSTEME UND IMPLEMENTIERUNGEN
• Die 18-19 veranschaulichen verschiedene Systeme, Geräte und Komponenten, die Aspekte der offenbarten Ausführungsformen implementieren können.
• 18 veranschaulicht ein Netzwerk 1800 gemäß verschiedenen Ausführungsformen. Das Netzwerk 1800 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 Netzwerke gelten, die von den hier beschriebenen Prinzipien profitieren, wie z.B. zukünftige 3GPP-Systeme oder ähnliches.
• Das Netzwerk 1800 kann ein UE 1802 umfassen, das ein beliebiges mobiles oder nichtmobiles Computergerät umfassen kann, das für die Kommunikation mit einem Funkzugangsnetzwerk (RAN) 1804 über eine Über-die-Luft-Verbindung ausgelegt ist. Das UE 1802 kann über eine Uu-Schnittstelle mit dem RAN 1804 kommunikativ gekoppelt sein. Bei dem UE 1802 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, ein mobiles 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 1800 eine Vielzahl von UEs umfassen, die über eine Sidelink-Schnittstelle direkt miteinander verbunden sind. Die UEs können M2M/D2D-Geräte sein, die über physikalische Sidelink-Kanäle wie PSBCH, PSDCH, PSSCH, PSCCH, PSFCH usw. kommunizieren.
• In einigen Ausführungsformen kann das UE 1802 zusätzlich mit einem AP 1806 über eine Über-die-Luft-Verbindung kommunizieren. Der AP 1806 kann eine WLAN-Verbindung verwalten, die dazu dienen kann, einen Teil/den gesamten Netzwerkverkehr vom RAN 1804 zu entlasten. Die Verbindung zwischen dem UE 1802 und dem AP 1806 kann mit jedem IEEE 802.11 Protokoll übereinstimmen, wobei der AP 1806 ein Wireless Fidelity (Wi-Fi®) Router sein könnte. In einigen Ausführungsformen können das UE 1802, das RAN 1804 und der AP 1806 eine Zell-WLAN-Aggregation verwenden (z.B. LWA/LWIP). Die Aggregation von Mobilfunk und WLAN kann bedeuten, dass das UE 1802 vom RAN 1804 so konfiguriert wird, dass sie sowohl Mobilfunkals auch WLAN-Ressourcen nutzt.
• Das RAN 1804 kann einen oder mehrere Zugangsknoten umfassen, zum Beispiel AN 1808. AN 1808 kann Luftschnittstellenprotokolle für das UE 1802 beenden, indem es Zugangsschichtprotokolle einschließlich RRC, PDCP, RLC, MAC und LI-Protokolle bereitstellt. Auf diese Weise kann das AN 1808 Daten-/Sprachkonnektivität zwischen CN 1820 und dem UE 1802 ermöglichen. In einigen Ausführungsformen kann das AN 1808 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. Das AN 1808 kann als BS, gNB, RAN-Knoten, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, usw. bezeichnet werden. Bei dem AN 1808 kann es sich um eine Makrozellen-Basisstation oder eine Basisstation mit geringer Leistung zur Bereitstellung von Femtozellen, Pikozellen oder ähnlichen Zellen mit kleineren Abdeckungsbereichen, geringerer Nutzerkapazität oder höherer Bandbreite im Vergleich zu Makrozellen handeln.
• In Ausführungsformen, in denen das RAN 1804 eine Vielzahl von ANs umfasst, können diese über eine X2-Schnittstelle (wenn das RAN 1804 ein LTE-RAN ist) oder eine Xn-Schnittstelle (wenn das RAN 1804 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, Interferenzkoordination usw. austauschen.
• Die ANs des RAN 1804 können jeweils eine oder mehrere Zellen, Zellengruppen, Komponententräger usw. verwalten, um dem UE 1802 eine Luftschnittstelle für den Netzwerkzugang bereitzustellen. Das UE 1802 kann gleichzeitig mit einer Vielzahl von Zellen verbunden sein, die von denselben oder verschiedenen ANs des RAN 1804 bereitgestellt werden. Beispielsweise können das UE 1802 und das RAN 1804 die Trägeraggregation nutzen, um dem UE 1802 die Verbindung mit einer Vielzahl von Komponententrägern zu ermöglichen, die jeweils einer P-Zelle oder Scell entsprechen. In Dual-Connectivity-Szenarien kann ein erster AN ein Master-Knoten sein, der einen MCG bereitstellt, und ein zweiter AN kann ein sekundärer Knoten sein, der einen SCG bereitstellt. Die ersten/zweiten ANs können eine beliebige Kombination aus eNB, gNB, ng-eNB usw. sein.
• Das RAN 1804 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 Operationen zur Erkennung des Mediums/Trägers durchführen, z.B. auf der Grundlage eines LBT-Protokolls (Hören-vor-Sprechen - listen-before-talk).
• In V2X-Szenarien kann das UE 1802 oder AN 1808 eine RSU sein oder als RSU fungieren, was sich auf jede Verkehrsinfrastruktureinheit beziehen kann, die für V2X-Kommunikation verwendet wird. Eine RSU kann in oder durch ein geeignetes AN oder ein stationäres (oder relativ stationäres) UE implementiert sein. Eine RSU, die in oder durch ein UE implementiert ist, kann als „UE-type RSU“ bezeichnet werden; ein eNB kann als „eNB-type RSU“ bezeichnet werden; ein gNB kann als „gNB-type RSU“ bezeichnet werden; und dergleichen. In einem Beispiel handelt es sich bei einer RSU um eine Recheneinheit, die mit einer straßenseitigen Schaltung gekoppelt ist, die vorbeifahrenden UEs Konnektivität bietet. Die RSU kann auch eine interne Schaltung zur Datenspeicherung enthalten, um die Geometrie von Kreuzungen, Verkehrsstatistiken, Medien sowie Anwendungen/Software zur Erfassung und Steuerung des laufenden Fahrzeug- und Fußgängerverkehrs zu speichern. Die RSU kann eine Kommunikation mit sehr geringer Latenz ermöglichen, die für Hochgeschwindigkeitsereignisse wie Unfallvermeidung, Verkehrswarnungen und Ähnliches erforderlich ist. Zusätzlich oder alternativ kann die RSU andere Mobilfunk-/WLAN-Kommunikationsdienste bereitstellen. Die Komponenten der RSU können in einem wetterfesten Gehäuse untergebracht sein, das für die Installation im Freien geeignet ist, und sie können einen Netzwerkschnittstellen-Controller enthalten, um eine kabelgebundene Verbindung (z.B. Ethernet) zu einem Verkehrssignalsteuergerät oder einem Backhaul-Netzwerk herzustellen.
• In einigen Ausführungsformen kann das RAN 1804 ein LTE RAN 1810 mit eNBs sein, zum Beispiel eNB 1812. Das LTE-RAN 1810 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; Turbocodes für Daten und TBCC für die Steuerung; usw. Die LTE-Luftschnittstelle kann sich auf 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 die anfängliche Erfassung, Kanalqualitätsmessungen und Kanalschätzung für die kohärente Demodulation/Erkennung am UE stützen. Die LTE-Luftschnittstelle kann in Bändern unter 6 GHz arbeiten.
• In einigen Ausführungsformen kann das RAN 1804 ein NG-RAN 1814 mit gNBs, zum Beispiel gNB 1816, oder ng-eNBs, zum Beispiel ng-eNB 1818, sein. Der gNB 1816 kann sich mit 5G-fähigen UEs über eine 5G-NR-Schnittstelle verbinden. Der gNB 1816 kann mit einem 5G-Kern über eine NG-Schnittstelle verbunden sein, die eine N2-Schnittstelle oder eine N3-Schnittstelle umfassen kann. Der ng-eNB 1818 kann ebenfalls über eine NG-Schnittstelle mit dem 5G-Kern verbunden sein, kann aber über eine LTE-Luftschnittstelle mit einem UE verbunden sein. Der gNB 1816 und der ng-eNB 1818 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 1814 und einer UPF 1848 (z. B. N3-Schnittstelle) überträgt, und eine NG-Kontrollschnittstelle (NG-C), die eine Signalisierungsschnittstelle zwischen den Knoten des NG-RAN 1814 und einer AMF 1844 (z.B. N2-Schnittstelle) ist.
• Das NG-RAN 1814 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 auf CSI-RS, PDSCH/PDCCH DMRS basieren, ähnlich wie die LTE Luftschnittstelle. Die 5G-NR-Luftschnittstelle verwendet möglicherweise kein CRS, sondern PBCH DMRS für die PBCH-Demodulation, PTRS für die Phasenverfolgung für PDSCH und ein Referenzsignal für die Zeitverfolgung. Die 5G-NR-Luftschnittstelle kann in FR1-Bändern arbeiten, 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 einen SSB enthalten, der ein Bereich eines Downlink-Ressourcenrasters ist, das PSS/SSS/PBCH enthält.
• In einigen Ausführungsformen kann die 5G-NR-Luftschnittstelle BWP für verschiedene Zwecke nutzen. Zum Beispiel können BWP für die dynamische Anpassung der SCS verwendet werden. Zum Beispiel kann das UE 1802 mit mehreren BWPs konfiguriert werden, wobei jede BWP-Konfiguration eine andere SCS hat. Wenn dem UE 1802 eine BWP-Änderung angezeigt wird, wird auch die SCS der Übertragung geändert. Ein weiteres Anwendungsbeispiel für BWP bezieht sich auf die Energieeinsparung. Insbesondere können für das UE 1802 mehrere BWP mit einer unterschiedlichen Anzahl von Frequenzressourcen (z.B. PRBs) konfiguriert werden, um die Datenübertragung unter verschiedenen Verkehrsbelastungsszenarien zu unterstützen. Ein BWP mit einer geringeren Anzahl von PRBs kann für die Datenübertragung mit geringer Verkehrslast verwendet werden und ermöglicht gleichzeitig Energieeinsparungen bei dem UE 1802 und in einigen Fällen beim gNB 1816. Ein BWP mit einer größeren Anzahl von PRBs kann für Szenarien mit höherer Verkehrslast verwendet werden.
• Das RAN 1804 ist kommunikativ mit dem CN 1820 gekoppelt, das Netzwerkelemente zur Bereitstellung verschiedener Funktionen zur Unterstützung von Daten- und Telekommunikationsdiensten für Kunden/Teilnehmer (z.B. Nutzer des UE 1802) enthält. Die Komponenten des CN 1820 können in einem physischen Knoten oder in separaten physischen Knoten implementiert sein. In einigen Ausführungsformen kann NFV verwendet werden, um einige oder alle Funktionen, die von den Netzwerkelementen des CN 1820 bereitgestellt werden, auf physischen Rechen-/Speicherressourcen in Servern, Switches usw. zu virtualisieren. Eine logische Instanziierung des CN 1820 kann als Netzwerk-Slice bezeichnet werden, und eine logische Instanziierung eines Teils des CN 1820 kann als Netzwerk-Sub-Slice bezeichnet werden.
• In einigen Ausführungsformen kann das CN 1820 ein LTE CN 1822 sein, die auch als EPC bezeichnet werden kann. Das LTE CN 1822 kann MME 1824, SGW 1826, SGSN 1828, HSS 1830, PGW 1832 und PCRF 1834 umfassen, die wie gezeigt über Schnittstellen (oder „Referenzpunkte“) miteinander verbunden sind. Die Funktionen der Elemente des LTE CN 1822 können wie folgt kurz vorgestellt werden.
• Die MME 1824 kann Mobilitätsmanagementfunktionen implementieren, um den aktuellen Standort des UE 1802 zu verfolgen, um Paging, Trägeraktivierung/-deaktivierung, Handover, Gateway-Auswahl, Authentifizierung usw. zu erleichtern.
• Das SGW 1826 kann eine S1-Schnittstelle zum RAN abschließen und Datenpakete zwischen dem RAN und dem LTE CN 1822 weiterleiten. Das SGW 1826 kann ein lokaler Mobilitätsankerpunkt für Inter-RAN-Knoten-Handover sein und kann auch einen Anker für Inter-3GPP-Mobilität bereitstellen. Weitere Aufgaben können rechtmäßiges Abfangen, Gebührenerhebung und die Durchsetzung einiger Richtlinien sein.
• Der SGSN 1828 kann den Standort des UE 1802 verfolgen und Sicherheitsfunktionen und Zugangskontrolle durchführen. Darüber hinaus kann der SGSN 1828 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 1824, die MME-Auswahl für Handover usw. durchführen. Der S3-Referenzpunkt zwischen der MME 1824 und dem SGSN 1828 kann den Austausch von Benutzer- und Trägerinformationen für die Mobilität zwischen 3GPP-Zugangsnetzwerken im Ruhe-/Aktivzustand ermöglichen.
• Der HSS 1830 kann eine Datenbank für Netzwerknutzer enthalten, einschließlich abonnementbezogener Informationen zur Unterstützung der Handhabung von Kommunikationssitzungen durch die Netzwerkeinheiten. Die HSS 1830 kann Unterstützung für Routing/Roaming, Authentifizierung, Autorisierung, Namens-/Adressierungsauflösung, Standortabhängigkeiten usw. bieten. Ein S6a-Referenzpunkt zwischen dem HSS 1830 und der MME 1824 kann die Übertragung von Abonnement- und Authentifizierungsdaten zur Authentifizierung/Autorisierung des Benutzerzugangs zum LTE CN 1820 ermöglichen.
• Das PGW 1832 kann eine SGi-Schnittstelle zu einem Datennetzwerk (DN) 1836 abschließen, das einen Anwendungs-/Inhaltsserver 1838 enthalten kann. Der PGW 1832 kann Datenpakete zwischen dem LTE CN 1822 und dem Datennetzwerk 1836 weiterleiten. Das PGW 1832 kann mit dem SGW 1826 über einen S5-Referenzpunkt gekoppelt sein, um das Tunneln der Benutzerebene und das Tunnelmanagement zu erleichtern. Das PGW 1832 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 1832 und dem Datennetzwerk 1836 ein betreiberexternes öffentliches, ein privates PDN oder ein betreiberinternes Paketdatennetz sein, z.B. für die Bereitstellung von IMS-Diensten. Der PGW 1832 kann mit einem PCRF 1834 über einen Gx-Referenzpunkt gekoppelt sein.
• Die PCRF 1834 ist das Regelungs- und Gebührenkontrollelement des LTE CN 1822. Die PCRF 1834 kann kommunikativ mit dem App-/Inhaltsserver 1838 gekoppelt sein, um geeignete QoS- und Gebührenparameter für Dienstflüsse zu ermitteln. Die PCRF 1832 kann zugehörige Regeln in einer PCEF (über den Gx-Referenzpunkt) mit geeigneten TFT und QCI bereitstellen.
• In einigen Ausführungsformen kann der CN 1820 ein 5GC 1840 sein. Das 5GC 1840 kann eine AUSF 1842, eine AMF 1844, eine SMF 1846, eine UPF 1848, eine NSSF 1850, eine NEF 1852, eine NRF 1854, eine PCF 1856, ein UDM 1858 und eine AF 1860 umfassen, die, wie gezeigt, über Schnittstellen (oder „Referenzpunkte“) miteinander verbunden sind. Die Funktionen der Elemente des 5GC 1840 können wie folgt kurz vorgestellt werden.
• Die AUSF 1842 kann Daten zur Authentifizierung des UE 1802 speichern und authentifizierungsbezogene Funktionen ausführen. Die AUSF 1842 kann einen gemeinsamen Authentifizierungsrahmen für verschiedene Zugangsarten ermöglichen. Zusätzlich zur Kommunikation mit anderen Elementen des 5GC 1840 über Referenzpunkte, wie dargestellt, kann das AUSF 1842 eine Nausf-Service-basierte Schnittstelle aufweisen.
• Die AMF 1844 kann es anderen Funktionen des 5GC 1840 ermöglichen, mit dem UE 1802 und dem RAN 1804 zu kommunizieren und Benachrichtigungen über Mobilitätsereignisse in Bezug auf das UE 1802 zu abonnieren. Die AMF 1844 kann für das Registrierungsmanagement (z.B. für die Registrierung des UE 1802), das Verbindungsmanagement, das Erreichbarkeitsmanagement, das Mobilitätsmanagement, das rechtmäßige Abfangen von AMFbezogenen Ereignissen und die Zugangsauthentifizierung und -autorisierung zuständig sein. Die AMF 1844 kann den Transport von SM-Nachrichten zwischen dem UE 1802 und der SMF 1846 bereitstellen und als transparenter Proxy für das Routing von SM-Nachrichten fungieren. Die AMF 1844 kann auch den Transport von SMS-Nachrichten zwischen dem UE 1802 und einer SMSF übernehmen. Die AMF 1844 kann mit der AUSF 1842 und dem UE 1802 interagieren, um verschiedene Sicherheitsanker- und Kontextmanagementfunktionen auszuführen. Darüber hinaus kann die AMF 1844 ein Endpunkt einer RAN-CP-Schnittstelle sein, die einen N2-Referenzpunkt zwischen dem RAN 1804 und der AMF 1844 enthalten oder sein kann; und die AMF 1844 kann ein Endpunkt der NAS-(N1)-Signalisierung sein und NAS-Chiffrierung und Integritätsschutz durchführen. Die AMF 1844 kann auch die NAS-Signalisierung mit dem UE 1802 über eine N3 IWF-Schnittstelle unterstützen.
• Die SMF 1846 kann verantwortlich sein für SM (z.B. Sitzungsaufbau, Tunnelmanagement zwischen UPF 1848 und AN 1808); Zuweisung und Verwaltung von UE-IP-Adressen (einschließlich optionaler Autorisierung); Auswahl und Kontrolle der UP-Funktion; Konfiguration der Verkehrslenkung an der UPF 1848, um den Verkehr zum richtigen Ziel zu leiten; Beendigung von Schnittstellen zu Richtliniensteuerung-Funktionen; Kontrolle eines Teils der Richtlinien-Durchsetzung-, 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 1844 über N2 an AN 1808 gesendet werden; und Ermittlung 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 1802 und dem Datennetzwerk 1836 bereitstellt oder ermöglicht.
• Die UPF 1848 kann als Ankerpunkt für Intra-RAT- und Inter-RAT-Mobilität, als externer PDU-Sitzungs-Verbindungspunkt zum Datennetzwerk 1836 und als Verzweigungspunkt zur Unterstützung von PDU-Sitzungen mit mehreren Teilnehmern dienen. Die UPF 1848 kann auch Paketrouting und -weiterleitung durchführen, Paketinspektion durchführen, den Teil der Richtlinienregeln für die Benutzerebene durchsetzen, Pakete rechtmäßig abfangen (UP-Sammlung), Verkehrsnutzungsberichte erstellen, QoS-Behandlung für eine Benutzerebene durchführen (z.B. Paketfilterung, Gating, UL/DL-Ratenerzwingung), Uplink-Verkehrsüberprüfung durchführen (z.B. SDF-zu-QoS-Flow-Mapping), Paketmarkierung auf Transportebene im Uplink und Downlink durchführen und Downlink-Paketpufferung und Downlink-Datenbenachrichtigungsauslösung durchführen. Die UPF 1848 kann einen Uplink-Klassifikator enthalten, um die Weiterleitung von Verkehrsflüssen an ein Datennetzwerk zu unterstützen.
• Die NSSF 1850 kann einen Satz von Netzwerk-Slice-Instanzen auswählen, die das UE 1802 bedienen. Die NSSF 1850 kann auch zulässige NSSAIs und die Zuordnung zu den abonnierten S-NSSAIs ermitteln, falls erforderlich. Die NSSF 1850 kann auch den AMF-Satz ermitteln, der verwendet werden soll, um das UE 1802 zu bedienen, oder eine Liste von AMF-Kandidaten auf der Grundlage einer geeigneten Konfiguration und möglicherweise durch Abfrage der NRF 1854. Die Auswahl eines Satzes von Netzwerk-Slice-Instanzen für das UE 1802 kann durch die AMF 1844 ausgelöst werden, bei der das UE 1802 durch Interaktion mit der NSSF 1850 registriert ist, was zu einem Wechsel der AMF führen kann. Die NSSF 1850 kann mit der AMF 1844 über einen N22-Referenzpunkt interagieren und kann mit einer anderen NSSF in einem besuchten Netzwerk über einen N31-Referenzpunkt (nicht dargestellt) kommunizieren. Darüber hinaus kann die NSSF 1850 eine dienstbasierte Nnssf-Schnittstelle aufweisen.
• Die NEF 1852 kann Dienste und Fähigkeiten, die von 3GPP-Netzfunktionen bereitgestellt werden, für Dritte, interne Exposure/Re-Exposure, AFs (z. B. AF 1860), Edge-Computing- oder Fog-Computing-Systeme usw. sicher bereitstellen. In solchen Ausführungsformen kann die NEF 1852 die AFs authentifizieren, autorisieren oder drosseln. Die NEF 1852 kann auch Informationen, die mit der AF 1860 ausgetauscht werden, und Informationen, die mit internen Netzwerkfunktionen ausgetauscht werden, übersetzen. Beispielsweise kann die NEF 1852 zwischen einem AF-Service-Identifier und einer internen 5GC-Information übersetzen. Die NEF 1852 kann auch Informationen von anderen NFs empfangen, die auf den offengelegten Fähigkeiten anderer NFs basieren. Diese Informationen können in der NEF 1852 als strukturierte Daten oder in einer Datenspeicher-NF unter Verwendung standardisierter Schnittstellen gespeichert werden. Die gespeicherten Informationen können dann von der NEF 1852 an andere NFs und AFs weitergegeben oder für andere Zwecke, wie z.B. Analysen, verwendet werden. Darüber hinaus kann die NEF 1852 eine dienstbasierte Schnittstelle aufweisen.
• Die NRF 1854 kann Dienst-Discovery-Funktionen unterstützen, NF-Discovery-Anfragen von NF-Instanzen empfangen und die Informationen der entdeckten NF-Instanzen an die NF-Instanzen weitergeben. Die NRF 1854 verwaltet auch Informationen über verfügbare NF-Instanzen und deren unterstützte Dienste. Wie hierin verwendet, können sich die Begriffe „instanziieren“, „Instanziierung“ und dergleichen auf die Erstellung einer Instanz beziehen, und eine „Instanz“ kann sich auf ein konkretes Auftreten eines Objekts beziehen, das z.B. während der Ausführung von Programmcode auftreten kann. Zusätzlich kann die NRF 1854 die dienstbasierte Nnrf-Schnittstelle aufweisen.
• Die PCF 1856 kann den Funktionen der Steuerebene Regeln zur Verfügung stellen, um diese durchzusetzen, und es kann auch ein einheitliches Regelwerk zur Steuerung des Netzwerkverhaltens unterstützen. Die PCF 1856 kann auch ein Frontend implementieren, um auf Abonnementinformationen zuzugreifen, die für Richtlinienentscheidungen in einem UDR des UDM 1858 relevant sind. Zusätzlich zur Kommunikation mit Funktionen über Referenzpunkte, wie dargestellt, weist die PCF 1856 eine dienstbasierte Npcf-Schnittstelle auf.
• Das UDM 1858 kann abonnementbezogene Informationen verarbeiten, um die Abwicklung von Kommunikationssitzungen durch die Netzwerkentitäten zu unterstützen, und kann Abonnementdaten des UE 1802 speichern. Zum Beispiel können Abonnementdaten über einen N8-Referenzpunkt zwischen dem UDM 1858 und der AMF 1844 kommuniziert werden. Das UDM 1858 kann zwei Teile umfassen, ein Anwendungs-Frontend und einen UDR. Das UDR kann Abonnementdaten und Richtliniendaten für das UDM 1858 und die PCF 1856 und/oder strukturierte Daten für die Exposition und Anwendungsdaten (einschließlich PFDs für die Anwendungserkennung, Anwendungsanforderungsinformationen für mehrere UEs 1802) für die NEF 1852 speichern. Die dienstbasierende Nudr-Schnittstelle kann vom UDR 221 verwendet werden, um dem UDM 1858, der PCF 1856 und der NEF 1852 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 enthalten, das für die Verarbeitung von Berechtigungsnachweisen, die Standortverwaltung, die Abonnementverwaltung usw. zuständig ist. Mehrere verschiedene Frontends können denselben Benutzer in verschiedenen Transaktionen bedienen. Die UDM-FE greift auf die im UDR gespeicherten Abonnementinformationen zu und führt die Verarbeitung von Authentifizierungsnachweisen, die Handhabung der Benutzeridentifikation, die Zugangsberechtigung, die Verwaltung der Registrierung/Mobilität und die Abonnementverwaltung durch. Zusätzlich zur Kommunikation mit anderen NFs über Referenzpunkte, wie dargestellt, kann das UDM 1858 die dienstbasierte Nudm-Schnittstelle aufweisen.
• Die AF 1860 kann den Einfluss der Anwendung auf die Verkehrslenkung gewährleisten, den Zugang zu NEF ermöglichen und mit dem Richtlinien-Framework für die Richtlinienkontrolle interagieren.
• In einigen Ausführungsformen kann die 5GC 1840 Edge Computing ermöglichen, indem sie Dienste von Betreibern/Drittanbietern so auswählt, dass sie sich geografisch in der Nähe eines Punktes befinden, an dem das UE 1802 mit dem Netzwerk verbunden ist. Dies kann die Latenzzeit und die Belastung des Netzwerks reduzieren. Um Edge-Computing-Implementierungen bereitzustellen, kann der 5GC 1840 eine UPF 1848 in der Nähe des UE 1802 auswählen und eine Verkehrslenkung von der UPF 1848 zum Datennetzwerk 1836 über die N6-Schnittstelle durchführen. Dies kann auf der Grundlage der UE-Abonnementdaten, des UE-Standorts und der von der AF 1860 bereitgestellten Informationen erfolgen. Auf diese Weise kann die AF 1860 die UPF-(Neu-)Auswahl und die Verkehrslenkung beeinflussen. Wenn die AF 1860 als vertrauenswürdige Einheit betrachtet wird, kann der Netzwerkbetreiber der AF 1860 erlauben, direkt mit den relevanten NFs zu interagieren. Zusätzlich kann die AF 1860 eine dienstbasierte Naf-Schnittstelle aufweisen.
• Das Datennetzwerk 1836 kann verschiedene Dienste des Netzwerkbetreibers, Internetzugang oder Dienste von Drittanbietern darstellen, die von einem oder mehreren Servern bereitgestellt werden können, z.B. einem Anwendungs-/Inhaltsserver 1838.
• 19 zeigt schematisch ein Drahtlos-Netzwerk 1900 gemäß verschiedenen Ausführungsformen. Das Drahtlos-Netzwerk 1900 kann ein UE 1902 in Drahtlos-Kommunikation mit einem AN 1904 umfassen. Das UE 1902 und das AN 1904 können ähnlich und im Wesentlichen austauschbar mit gleichnamigen Komponenten sein, die an anderer Stelle hierin beschrieben sind.
• Das UE 1902 kann über eine Verbindung 1906 mit dem AN 1904 kommunikativ gekoppelt sein. Die Verbindung 1906 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 1902 kann eine Host-Plattform 1908 umfassen, die mit einer Modem-Plattform 1910 gekoppelt ist. Die Host-Plattform 1908 kann eine Verarbeitungsschaltung 1912 enthalten, die mit der Protokollverarbeitungsschaltung 1914 der Modem-Plattform 1910 gekoppelt sein kann. Die Verarbeitungsschaltung 1912 kann verschiedene Anwendungen für das UE 1902 ausführen, die Anwendungsdaten senden/empfangen. Die Verarbeitungsschaltung 1912 kann darüber hinaus eine oder mehrere Schichtoperationen implementieren, um Anwendungsdaten an ein Datennetzwerk zu senden/von diesem zu empfangen. Diese Schichtoperationen können Transport-(z.B. UDP) und Internetoperationen (z.B. IP) umfassen
• Die protokollverarbeitende Schaltung 1914 kann eine oder mehrere der Schichtoperationen implementieren, um die Übertragung oder den Empfang von Daten über die Verbindung 1906 zu erleichtern. Die von der protokollverarbeitenden Schaltung 1914 implementierten Schichtoperationen können z.B. MAC-, RLC-, PDCP-, RRC- und NAS-Operationen umfassen.
• Die Modem-Plattform 1910 kann ferner eine digitale Basisbandschaltung 1916 enthalten, die eine oder mehrere Schichtoperationen implementieren kann, die „unterhalb“ der Schichtoperationen liegen, die von der Verarbeitungsschaltung 1914 in einem Netzwerkprotokollstapel ausgeführt werden. Diese Operationen können beispielsweise PHY-Operationen umfassen, einschließlich einer oder mehrerer HARQ-ACK-Funktionen, Scrambling/Decrambling, Kodierung/Dekodierung, Layer Mapping/De-Mapping, Modulationssymbol-Mapping, Ermittlung der empfangenen Symbole/Bit-Metrik, Vorcodierung/Dekodierung von Mehrantennenanschlüssen, die eine oder mehrere Raum-Zeit-, Raum-Frequenz- oder räumliche Kodierungen, Referenzsignalerzeugung/-detektion, Erzeugung und/oder Dekodierung von Präambelsequenzen, Erzeugung/Detektion von Synchronisationssequenzen, Blinddekodierung von Steuerkanalsignalen und andere verwandte Funktionen umfassen können.
• Die Modem-Plattform 1910 kann ferner eine Sendeschaltung 1918, eine Empfangsschaltung 1920, eine HF-Schaltung 1922 und ein HF-Frontend (RFFE) 1924 enthalten, das eine oder mehrere Antennenfelder 1926 enthalten oder mit diesen verbunden sein kann. Kurz gesagt kann die Sendeschaltung 1918 einen Digital-Analog-Wandler, einen Mischer, Zwischenfrequenzkomponenten usw. enthalten. Die Empfangsschaltung 1920 kann einen Analog-Digital-Wandler, Mischer, ZF-Komponenten usw. enthalten; die HF-Schaltung 1922 kann einen rauscharmen Verstärker, einen Leistungsverstärker, Leistungsnachführungskomponenten usw. enthalten; die RFFE 1924 kann Filter (z.B. Oberflächen-/Bulk-Akustikwellenfilter), Schalter, Antennentuner, Strahlformungskomponenten (z.B. Phasengruppenantennenkomponenten) usw. enthalten. Die Auswahl und Anordnung der Komponenten der Sendeschaltung 1918, der Empfangsschaltung 1920, der HF-Schaltung 1922, der RFFE 1924 und der Antennenpaneele 1926 (allgemein als „Sende-/Empfangskomponenten“ bezeichnet) kann spezifisch für die Details einer bestimmten Implementierung sein, wie z.B. ob die Kommunikation TDM oder FDM ist, in mmWave- oder sub-6 gHz-Frequenzen, 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 die Protokollverarbeitungsschaltung 1914 eine oder mehrere Instanzen von Steuerschaltungen (nicht dargestellt) enthalten, um Steuerfunktionen für die Sende-/Empfangskomponenten bereitzustellen.
• Ein UE-Empfang kann durch und über die Antennenfelder 1926, die RFFE 1924, die HF-Schaltung 1922, die Empfangsschaltung 1920, die digitale Basisbandschaltung 1916 und die Protokollverarbeitungsschaltung 1914 hergestellt werden. In einigen Ausführungsformen können die Antennenfelder 1926 eine Übertragung von der AN 1904 durch Empfangsstrahlformungssignale empfangen, die von einer Vielzahl von Antennen/Antennenelementen des einen oder der mehreren Antennenfelder 1926 empfangen werden.
• Eine UE-Übertragung kann durch und über die Protokollverarbeitungsschaltung 1914, die digitale Basisbandschaltung 1916, die Sendeschaltung 1918, die HF-Schaltung 1922, die RFFE 1924 und die Antennenfelder 1926 aufgebaut werden. In einigen Ausführungsformen können die Sendekomponenten des UE 1904 einen Raumfilter auf die zu übertragenden Daten anwenden, um einen von den Antennenelementen der Antennenfelder 1926 ausgesandten Sendestrahl zu bilden.
• Ähnlich wie das UE 1902 kann die AN 1904 eine Host-Plattform 1928 umfassen, die mit einer Modem-Plattform 1930 gekoppelt ist. Die Host-Plattform 1928 kann eine Verarbeitungsschaltung 1932 enthalten, die mit der Protokollverarbeitungsschaltung 1934 der Modem-Plattform 1930 gekoppelt ist. Die Modem-Plattform kann ferner eine digitale Basisbandschaltung 1936, eine Sendeschaltung 1938, eine Empfangsschaltung 1940, eine HF-Schaltung 1942, eine RFFE-Schaltung 1944 und Antennenfelder 1946 umfassen. Die Komponenten des AN 1904 können den gleichnamigen Komponenten des UE 1902 ä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 1908 verschiedene Logik-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.
• 20 ist ein Blockdiagramm, das gemäß einigen Ausführungsbeispielen Komponenten zeigt, die in der Lage sind, Befehle von einem maschinenlesbaren oder computerlesbaren Medium (z.B. einem nicht-transitorischen maschinenlesbaren Speichermedium) zu lesen und eine oder mehrere der hier erörterten Methoden durchzuführen. 20 zeigt insbesondere eine schematische Darstellung von Hardwareressourcen 2000 mit einem oder mehreren Prozessoren (oder Prozessorkernen) 2010, einem oder mehreren Speichergeräten 2020 und einer oder mehreren Kommunikationsressourcen 2030, die jeweils über einen Bus 2040 oder eine andere Schnittstellenschaltung kommunikativ gekoppelt sein können. Bei Ausführungsformen, in denen Knotenvirtualisierung (z.B. NFV) verwendet wird, kann ein Hypervisor 2002 ausgeführt werden, um eine Ausführungsumgebung für eine oder mehrere Netzwerk-Slices/Sub-Slices bereitzustellen, die die Hardwareressourcen 2000 nutzen.
• Die Prozessoren 2010 können z.B. einen Prozessor 2012 und einen Prozessor 2014 umfassen. Bei den Prozessoren 2010 kann es sich beispielsweise um eine Zentraleinheit (CPU), einen RISC-Prozessor (RISC = Reduzierter Instruktionssatz-Berechnen - Reduced Instruction Set Computing), einen CISC-Prozessor (CISC = Komplexer Instruktionssatz-Berechnen - Complex Instruction Set Computing), eine Grafikverarbeitungseinheit (GPU = Graphics Processing Unit), einen DSP wie einen Basisbandprozessor, einen ASIC, einen FPGA, eine integrierte Hochfrequenzschaltung (RFIC = Radio Frequency Integrated Circuit), einen anderen Prozessor (einschließlich der hierin erörterten) oder eine beliebige geeignete Kombination davon handeln.
• Die Speicher-/Speichervorrichtungen 2020 können Hauptspeicher, Plattenspeicher oder eine beliebige Kombination davon umfassen. Die Speicher/Speichervorrichtungen 2020 können jede Art von flüchtigem, nichtflüchtigem oder halbflüchtigem Speicher umfassen, sind aber nicht darauf beschränkt, wie z.B. dynamischer Direktzugriffsspeicher (DRAM), statischer Direktzugriffsspeicher (SRAM), löschbarer programmierbarer Festwertspeicher (EPROM), elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM), Flash-Speicher, Festkörperspeicher usw.
• Die Kommunikationsressourcen 2030 können Verbindungs- oder Netzwerkschnittstellen-Controller, Komponenten oder andere geeignete Geräte umfassen, um mit einem oder mehreren Peripheriegeräten 2004 oder einer oder mehreren Datenbanken 2006 oder anderen Netzwerkelementen über ein Netzwerk 2008 zu kommunizieren. Die Kommunikationsressourcen 2030 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 2050 können Software, ein Programm, eine Anwendung, ein Applet, eine App oder einen anderen ausführbaren Code umfassen, um mindestens einen der Prozessoren 2010 zu veranlassen, eine oder mehrere der hierin beschriebenen Verfahren durchzuführen. Die Anweisungen 2050 können sich vollständig oder teilweise in mindestens einem der Prozessoren 2010 (z.B. im Cache-Speicher des Prozessors), in den Speichergeräten 2020 oder in einer geeigneten Kombination davon befinden. Darüber hinaus kann ein beliebiger Teil der Anweisungen 2050 von einer beliebigen Kombination der Peripheriegeräte 2004 oder der Datenbanken 2006 an die Hardwareressourcen 2000 übertragen werden. Dementsprechend sind der Speicher der Prozessoren 2010, die Speicher/Speichergeräte 2020, die Peripheriegeräte 2004 und die Datenbanken 2006 Beispiele für computerlesbare und maschinenlesbare Medien.
• BEISPIEL VERFAHREN
• Bei einer oder mehreren Ausführungsformen kann mindestens eine der in einer oder mehreren der vorangehenden Figuren dargestellten Komponenten so konfiguriert sein, dass sie eine oder mehrere Operationen, Techniken, Prozesse und/oder Verfahren durchführt, wie im nachstehenden Beispielabschnitt dargelegt. Zum Beispiel kann die Basisbandschaltung, wie oben in Verbindung mit einer oder mehreren der vorangehenden Figuren beschrieben, so konfiguriert werden, dass sie gemäß einem oder mehreren der unten aufgeführten Beispiele funktioniert. Als weiteres Beispiel kann die Schaltung, die einem UE, einer Basisstation, einem Netzwerkelement usw. zugeordnet ist, wie oben in Verbindung mit einer oder mehreren der vorhergehenden Figuren beschrieben, so konfiguriert werden, dass sie gemäß einem oder mehreren der unten im Beispielabschnitt aufgeführten Beispiele arbeitet.
• BEISPIELE
• Beispiel 1 kann eine Vorrichtung eines Benutzergeräts (UE) sein, wobei die Vorrichtung eine Hochfrequenz (HF)-Schnittstelle und einen oder mehrere Prozessoren umfasst, die mit der HF-Schnittstelle gekoppelt und konfiguriert sind, Ressourcen und Konfigurationen zum Übertragen einer Vielzahl von kleinen Datenübertragungspaketen (SDT) an eine Basisstation (BS) in einer SDT-Sitzung zu ermitteln, während das UE RRC_INACTIVE bleibt; und in der SDT-Sitzung, während das UE RRC_INACTIVE bleibt, ein erstes SDT-Paket der Vielzahl von SDT-Paketen unter Verwendung der bestimmten Ressourcen und Konfigurationen an die BS zu übertragen oder von der BS zu empfangen.
• Beispiel 2 kann das Verfahren des Beispiels 1 oder eines anderen Beispiels hierin beinhalten, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, der BS ein nachfolgendes SDT-Paket der Vielzahl von zu übertragenden SDT-Paketen anzuzeigen, wobei die Vielzahl von SDT-Paketen Benutzerdaten und/oder Signalisierungsdaten enthalten.
• Beispiel 3 kann das Verfahren der Beispiele 1 oder 2 oder ein anderes Beispiel hierin beinhalten, wobei die Vielzahl von SDT-Paketen Segmente eines einzelnen größeren Pakets oder eine Vielzahl von einzelnen Paketen enthält.
• Beispiel 4 kann das Verfahren der Beispiele 1 bis 3 oder ein anderes Beispiel hierin beinhalten, wobei das erste SDT-Paket ein Uplink-SDT-Paket, ein Downlink-SDT-Paket und/oder beides ist.
• Beispiel 5 kann das Verfahren der Beispiele 2-4 oder ein anderes Beispiel hierin umfassen, wobei die Anzeige des nachfolgenden SDT-Pakets eine allgemeine Anzeige von mehr zu übertragenden SDT-Paketen, eine Anzahl von zu übertragenden SDT-Paketsegmenten oder eine Pufferanzeige, dass mehr SDT-Pakete in einem SDT-Puffer warten, umfasst.
• Beispiel 6 kann das Verfahren der Beispiele 2-5 oder ein anderes hierin beschriebenes Beispiel umfassen, wobei der eine oder die mehreren Prozessoren ferner so konfiguriert sind, dass sie: das nachfolgende SDT-Paket in der SDT-Sitzung an die BS senden oder von ihr empfangen, während die UE RRC INACTIVE bleibt.
• Beispiel 7 kann das Verfahren der Beispiele 1 bis 6 oder ein anderes Beispiel hierin umfassen, wobei das Ermitteln von Ressourcen und Konfigurationen zum Übertragen der mehreren kleinen Datenübertragungen die Verwendung vorbestimmter Standardressourcen und -konfigurationen, die Verwendung von Ressourcen und Konfigurationen, die in dem UE über dedizierte Signalisierung konfiguriert sind, oder die Verwendung von Ressourcen und Konfigurationen, die über Broadcast von der BS als Teil des RACH-Verfahrens signalisiert werden, umfasst.
• Beispiel 8 kann das Verfahren der Beispiele 1-7 oder ein anderes hierin beschriebenes Beispiel umfassen, wobei der eine oder die mehreren Prozessoren ferner so konfiguriert sind, dass sie einige oder alle Benutzerebenen-Zustände in der Zugriffsschicht während der SDT-Sitzung beibehalten und einige oder alle Konfigurationen in der Zugriffsschicht beibehalten, während die UE RRC INACTIVE ist.
• Beispiel 9 kann das Verfahren aus den Beispielen 1-8 oder ein anderes Beispiel hierin beinhalten, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, einen Teil der Konfigurationen, die zuvor in dem UE konfiguriert wurden, zu verwenden und/oder wieder aufzunehmen.
• Beispiel 10 kann das Verfahren aus den Beispielen 1-9 oder ein anderes Beispiel hierin beinhalten, wobei, während sich das UE in der SDT-Sitzung befindet, das UE über eine dedizierte Steuernachricht rekonfigurierbar ist.
• Beispiel 11 kann das Verfahren von Beispiel 7 oder ein anderes Beispiel hierin beinhalten, wobei die Verwendung von Ressourcen und Konfigurationen, die über Broadcast von der BS als Teil der RACH-Prozedur signalisiert werden, Folgendes beinhaltet: Senden einer PRACH-Nachricht an die BS, um mindestens eines der mehreren SDT-Pakete anzuzeigen; Empfangen einer RAR-Nachricht von der BS, die eine Zuteilungsgröße der Ressourcen enthält; Senden des ersten SDT-Pakets unter Verwendung der Ressourcen an die BS; und Senden einer Anzeige von weiteren SDT-Paketen an die BS.
• Beispiel 12 kann das Verfahren von Beispiel 7 oder eines anderen Beispiels hierin umfassen, wobei die Verwendung von Ressourcen und Konfigurationen, die über Rundsendung von der BS als Teil der RACH-Prozedur signalisiert werden, Folgendes umfasst: Senden einer PRACH-Nachricht an die BS, um mindestens eines der mehreren SDT-Pakete anzuzeigen; Empfangen einer Rundsendungsnachricht von der BS, die eine Zuteilungsgröße der Ressourcen enthält; Senden des ersten SDT-Pakets unter Verwendung der Ressourcen an die BS oder Empfangen des ersten SDT-Pakets von der BS; und Senden eines Hinweises auf weitere SDT-Pakete an die BS.
• Beispiel 13 kann das Verfahren von Beispiel 7 oder ein anderes Beispiel hierin umfassen, wobei die Verwendung von Ressourcen und Konfigurationen, die in dem UE konfiguriert wurden, während das UE RRC_CONNECTED war, die Verwendung von Ressourcen und Konfigurationen umfasst, die in einer konfigurierten Erlaubnis bereitgestellt werden, wobei die konfigurierte Erlaubnis eine Anzeige umfasst, dass es dem UE erlaubt ist, die darin bereitgestellten Ressourcen und Konfigurationen zu verwenden, während das UE RRC-INACTIVE ist.
• Beispiel 14 kann das Verfahren der Beispiele 11-13 oder ein anderes hierin beschriebenes Beispiel beinhalten, wobei der eine oder die mehreren Prozessoren weiterhin konfiguriert sind, mit der BS eines der mehreren SDT-Pakete auszutauschen.
• Beispiel 15 kann das Verfahren der Beispiele 1-14 oder ein anderes Beispiel hierin beinhalten, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, einen Physical Downlink Control Channel (PDCCH) auf einen dedizierten Radio Network Temporary Identifier (RNTI) zu überwachen.
• Beispiel 16 kann das Verfahren der Beispiele 1-15 oder ein anderes Beispiel hierin umfassen, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, zu ermitteln, dass Bedingungen für die Übertragung von SDT-Paketen erfüllt sind, wobei die Bedingungen umfassen: a. Identifizieren eines Auslösers für eine neue Zugangskategorie, die sich auf SDT bezieht, b. Ermitteln einer maximalen Anzahl von aufeinanderfolgenden SDT-Austauschen, die erlaubt sind, während sich ein UE in RRCINACTIVE befindet, oder c. Ermitteln, dass SDT über configured grant (CG) aktiviert ist.
• Beispiel 17 kann das Verfahren der Beispiele 1-16 oder ein anderes Beispiel hierin beinhalten, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind, nach einem Ausfall während der SDT-Sitzung die SDT-Sitzung durch ein Wiederherstellungsähnliches Verfahren fortzusetzen.
• Beispiel 18 kann eine Vorrichtung einer Basisstation (BS) sein, die für den Betrieb in einem Netzwerk der fünften Generation (5G) konfiguriert ist, wobei die Vorrichtung umfasst: eine Verarbeitungsschaltung; eine Steuerebenen-Schnittstelle, die von der Verarbeitungsschaltung konfiguriert ist, um Steuersignale zu übertragen; und eine Schnittstelle der Benutzerebene, die von der Verarbeitungsschaltung konfiguriert ist, um Verkehrsdaten zu übertragen, wobei die Verarbeitungsschaltung konfiguriert ist, Ressourcen und Konfigurationen zum Empfangen einer Vielzahl von kleinen Datenübertragungspaketen (SDT) von einem Benutzergerät (UE) in einer SDT-Sitzung zu ermitteln, während das UE RRC _INACTIVE bleibt; und in der SDT-Sitzung, während das UE RRC INACTIVE bleibt, ein erstes SDT-Paket der Vielzahl von SDT-Paketen unter Verwendung der ermittelten Ressourcen und Konfigurationen an das UE zu senden oder von ihm zu empfangen.
• Beispiel 19 kann das Verfahren von Beispiel 18 oder ein anderes Beispiel hierin beinhalten, wobei die Verarbeitungsschaltung ferner konfiguriert ist, einen Hinweis von dem UE auf ein nachfolgendes SDT-Paket der Mehrzahl von zu übertragenden SDT-Paketen zu empfangen, wobei die Mehrzahl von SDT-Paketen Nutzdaten und/oder Signalisierungsdaten enthält.
• Beispiel 20 kann das Verfahren der Beispiele 18-19 oder ein anderes Beispiel hierin beinhalten, wobei die Mehrzahl von SDT-Paketen Segmente eines einzelnen größeren Pakets oder eine Mehrzahl von einzelnen Paketen enthält.
• Beispiel 21 kann das Verfahren der Beispiele 18-20 oder ein anderes Beispiel hierin umfassen, wobei das erste SDT-Paket ein Uplink-SDT-Paket, ein Downlink-SDT-Paket und/oder beides ist.
• Beispiel 22 kann das Verfahren der Beispiele 19-21 oder ein anderes Beispiel hierin umfassen, wobei die Anzeige des nachfolgenden SDT-Pakets eine allgemeine Anzeige von mehr zu übertragenden SDT-Paketen, eine Anzahl von zu übertragenden SDT-Paketsegmenten oder eine Pufferanzeige, dass mehr SDT-Pakete in einem SDT-Puffer warten, umfasst.
• Beispiel 23 kann das Verfahren der Beispiele 20-22 oder ein anderes hierin beschriebenes Beispiel umfassen, wobei die Verarbeitungsschaltung ferner so konfiguriert ist, dass sie das nachfolgende SDT-Paket in der SDT-Sitzung an die BS sendet oder von ihr empfängt, während das UE RRC INACTIVE bleibt.
• Beispiel 24 kann das Verfahren der Beispiele 18-23 oder ein anderes Beispiel hierin umfassen, wobei das Ermitteln von Ressourcen und Konfigurationen zum Übertragen der Vielzahl von kleinen Datenübertragungen die Verwendung von vorbestimmten Standardressourcen und -konfigurationen, die Verwendung von Ressourcen und Konfigurationen, die in dem UE über dedizierte Signalisierung konfiguriert sind, oder die Verwendung von Ressourcen und Konfigurationen, die mittels Broadcast an das UE als Teil der RACH-Prozedur signalisiert werden, umfasst.
• Beispiel 25 kann das Verfahren der Beispiele 18-24 oder ein anderes hierin beschriebenes Beispiel umfassen, wobei die Verarbeitungsschaltung ferner so konfiguriert ist, dass sie einige oder alle Benutzerebenen-Zustände in der Zugriffsschicht während der SDT-Sitzung beibehält und einige oder alle Konfigurationen in der Zugriffsschicht beibehält, während das UE RRC INACTIVE ist.
• Beispiel 26 kann das Verfahren der Beispiele 18-25 beinhalten, wobei die Verarbeitungsschaltung ferner konfiguriert ist, einen Teil der Konfigurationen, die zuvor in dem UE konfiguriert wurden, zu verwenden und/oder wieder aufzunehmen.
• Beispiel 27 kann das Verfahren der Beispiele 18-26 oder ein anderes Beispiel hierin beinhalten, wobei die Verarbeitungsschaltung ferner konfiguriert ist, die Konfigurationen für das UE von einer anderen Basisstation abzurufen.
• Beispiel RACH1 kann beinhalten, dass es dem UE in „RRC INACTIVE“ erlaubt ist, mehrere untergeordnete Daten- oder Signalisierungspakete/PDUs auszutauschen, die Segmente des ersten Pakets sein können, ohne dass das UE über einen neuen Mechanismus, der als Small Data Transmission (SDT) bezeichnet werden kann, in RRC_CONNECTED übergehen muss.
• Beispiel RACH2 kann das Verfahren von Beispiel RACH1 oder ein anderes hierin beschriebenes Beispiel umfassen, wobei einige oder alle Zustände und Konfigurationen der Nutzungsebene in der Zugangsschicht beibehalten werden.
• Beispiel RACH3 kann das Verfahren von Beispiel RACH1 oder ein anderes Beispiel hierin beinhalten, wobei PDCCH für eine dedizierte RNTI überwacht wird.
• Beispiel RACH4 kann das Verfahren von Beispiel RACH1 oder ein anderes Beispiel hierin beinhalten, wobei Konfigurationen verwendet werden, die sowohl dem UE als auch dem gNB bekannt sind, wie z.B. ein Teil der Konfigurationen, die in dem UE konfiguriert wurden, während es zuvor RRC_CONNECTED war, oder vorkonfigurierte Konfigurationen über Broadcasting-Signalisierung oder Standardkonfigurationen, die in der Spezifikation definiert sein können.
• Beispiel RACH5 kann das Verfahren von Beispiel RACH1 oder ein anderes hierin beschriebenes Beispiel beinhalten, wobei sich das UE in einem neuen oder temporären RRC-Zustand befinden kann, während es die Daten austauscht, und kann mit anderen Namen bezeichnet werden, wie z.B. „RRC_INACTIVE plus“.
• Beispiel RACH6 kann das Verfahren von Beispiel RACH1 oder ein anderes Beispiel hierin beinhalten, wobei eine der folgenden Bedingungen verwendet werden kann, um zu ermitteln, ob das SDT-Merkmal verwendet werden kann: Auslöser für eine neue Zugangskategorie in Bezug auf SDT oder die Anzahl der nachfolgenden SDT-Vermittlungen, während sich ein UE in „RRC_INACTIVE plus“ befindet, oder ein SDT-spezifischer DRB muss zuvor eingerichtet werden,
• Beispiel RACH7 kann das Verfahren von Beispiel RACH1 oder ein anderes Beispiel hierin beinhalten, wobei eine der folgenden UL-Benachrichtigungen verwendet werden kann, um dem Netzwerk anzuzeigen, wenn mehrere nachfolgende Pakete darauf warten, über SDT gesendet zu werden: die Anzahl der untergeordneten Pakete (oder SDT-Austausche) oder die allgemeine Anzeige, dass mehr Daten in seinem UL-Puffer darauf warten, gesendet zu werden.
• Beispiel RACH8 kann das UE des Beispiels RACH1 oder eines anderen Beispiels hierin umfassen, wobei eine Neukonfiguration über eine spezielle Signalisierung erfolgen kann, die gesendet wird, während sich das UE im Zustand „RRC_INACTIVE plus“ befindet, z.B. über RRCReconfiguration oder RRCRelease, wobei eine Antwort des UE nicht erforderlich sein kann.
• Beispiel RACH9 kann das Verfahren von Beispiel RACH1 beinhalten, kann PDCCH diskontinuierlich überwachen, während sich UE in „RRC INACTIVE plus“ befindet, wie z.B.: (a) wenn das Netzwerk die DL SDT sendet, zeigt es auch zukünftige DL/UL SDT oder Zuweisung an, (b) das UE überwacht PDCCH nur in ihrem alten PF/PO, um mögliche zukünftige UL/DL-SDT oder Zuweisungen zu prüfen, (c) das UE folgt einem diskontinuierlichen Überwachungsmechanismus ähnlich C-DRX, um zukünftige DL/UL-SDT-Zuweisungen zu prüfen, oder (d) das UE ist (vor-)konfiguriert mit Ressourcen für ihre zukünftige UL/DL-SDT oder Überwachung des PDCCH.
• Beispiel RACH10 kann das Verfahren von Beispiel RACH1 oder eines anderen Beispiels hierin beinhalten, wobei Mobilität oder Zellenneuwahl behandelt werden können, um die laufenden Daten durch (a) Rückgriff auf RRC_CONNECTED (um sich auf ältere Mechanismen wie z.B. HO, RLF, Wiederherstellung), oder b) das UE oder das Netzwerk kann eine Anzeige auslösen, wenn erkannt wird, dass sich das UE aus der Zelle herausbewegt, um die Freigabe zurück zu RRC INACTIVE (oder den Übergang zu RRC CONNECTED) auszulösen, oder c) sich auf RLF stützen, oder d) ein handover-ähnliches Verfahren ermöglichen, während sie sich in „RRC_INACTIVE plus“ befindet.
• Beispiel RACH11 kann das Verfahren von Beispiel RACH1 oder ein anderes hierin beschriebenes Beispiel umfassen, bei dem der Verlust der Abdeckung durch Wiederverwendung des Wiederherstellungsverfahrens behandelt werden kann, während sich das UE in „RRC_INACTIVE plus“ befindet.
• Beispiel RACH12 kann das Verfahren von Beispiel RACH1 oder ein anderes Beispiel hierin beinhalten, wobei die von dem UE verwendete RRC/MAC-Signalisierung ausgetauscht werden kann, während sich das UE in „RRC_CONNECTED“ befindet, während das UE „RRC INACTIVE plus“ ist.
• Beispiel RACH13 kann ein Verfahren zum Implementieren eines UE sein, wobei das Verfahren umfasst: Identifizieren, ob sich das UE im „RRC_INACTIVE“-Zustand befindet; und wenn sich das UE im „RRC_INACTIVE“-Zustand befindet, Empfangen eines Signals oder Codieren eines Signals zur Übertragung, wobei das Signal mehrere untergeordnete Pakete/PDUs von Daten oder Signalisierung enthält.
• Beispiel RACH14 kann das Verfahren von Beispiel RACH13 beinhalten, wobei das UE nicht in den Zustand RRC_CONNECTED übergeht, um das Signal zu empfangen oder zu senden.
• Beispiel RACH15 kann das Verfahren von Beispiel RACH13 beinhalten, wobei die Kodierung eines Signals für die Übertragung ferner die Kodierung eines Signals für die Übertragung kleiner Daten beinhaltet.
• Beispiel RACH16 kann eine Vorrichtung umfassen, die Mittel zur Durchführung eines oder mehrerer Elemente eines Verfahrens, das in einem der Beispiele RACH1-15 beschrieben ist oder sich auf eines dieser Beispiele bezieht, oder jedes andere hier beschriebene Verfahren oder Prozesses umfasst.
• Beispiel RACH17 kann ein oder mehrere nichttransitorische computerlesbare Medien enthalten, die Befehle enthalten, um eine elektronische Vorrichtung zu veranlassen, bei Ausführung der Befehle durch einen oder mehrere Prozessoren der elektronischen Vorrichtung ein oder mehrere Elemente eines Verfahrens durchzuführen, das in einem der Beispiele RACH1-15 beschrieben ist oder damit in Zusammenhang steht, oder jedes andere hier beschriebene Verfahren oder Prozess.
• Beispiel RACH18 kann ein Gerät enthalten, das Logik, Module oder Schaltungen umfasst, um ein oder mehrere Elemente eines Verfahrens durchzuführen, das in einem der Beispiele RACH1-15 beschrieben ist oder damit in Zusammenhang steht, oder jedes andere hier beschriebene Verfahren oder Prozess.
• Beispiel RACH19 kann ein Verfahren, eine Technik oder einen Prozess, wie in einem der Beispiele PUR1-15 beschrieben oder damit verbunden, oder Abschnitte oder Teile davon umfassen.
• Beispiel RACH20 kann eine Vorrichtung enthalten, die Folgendes umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen enthalten, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele RACH1-15 beschrieben oder damit verbunden, oder Teile davon durchzuführen.
• Beispiel RACH21 kann ein Signal enthalten, wie in einem der Beispiele RACH1-15 beschrieben oder damit verbunden, oder Teile davon.
• Beispiel RACH22 kann ein Datagramm, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht enthalten, wie sie in den Beispielen RACH1-15 beschrieben sind oder sich auf diese beziehen, oder Teile davon, oder wie sie anderweitig in der vorliegenden Offenbarung/Erfindung beschrieben sind.
• Beispiel RACH23 kann ein Signal enthalten, das mit Daten kodiert ist, wie sie in den Beispielen RACH1-15 oder Teilen davon beschrieben sind oder sich auf diese beziehen, oder wie sie in der vorliegenden Offenbarung/Erfindung anderweitig beschrieben sind.
• Beispiel RACH24 kann ein Signal enthalten, das mit einem Datagramm, einem Paket, einem Rahmen, einem Segment, einer Protokolldateneinheit (PDU) oder einer Nachricht kodiert ist, wie es in den Beispielen RACH1-15 oder in Teilen davon beschrieben ist oder sich auf diese bezieht oder wie es anderweitig in der vorliegenden Offenbarung/Erfindung beschrieben ist.
• Beispiel RACH25 kann ein elektromagnetisches Signal enthalten, das computerlesbare Befehle trägt, wobei die Ausführung der computerlesbaren Befehle durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen soll, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele RACH1-15 oder Teilen davon beschrieben oder damit verbunden, durchzuführen.
• Beispiel RACH26 kann ein Computerprogramm enthalten, das Anweisungen umfasst, wobei die Ausführung des Programms durch ein Verarbeitungselement das Verarbeitungselement veranlassen soll, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele RACH1-15 beschrieben oder damit verbunden, oder Teile davon auszuführen.
• Beispiel RACH27 kann ein Signal in einem Drahtlos-Netzwerk enthalten, wie hier gezeigt und beschrieben.
• Beispiel RACH28 kann ein Verfahren zur Kommunikation in einem Drahtlos-Netzwerk beinhalten, wie hier gezeigt und beschrieben.
• Beispiel RACH29 kann ein System zur Bereitstellung von Drahtlos-Kommunikation beinhalten, wie hier gezeigt und beschrieben.
• Beispiel RACH30 kann ein Gerät zur Bereitstellung von Drahtlos-Kommunikation beinhalten, wie hier gezeigt und beschrieben.
• Beispiel PUR1 kann beinhalten, dass UE im „RRC_INACTIVE“-Modus mehrere Daten- oder Signalisierungspakete/PDUs austauschen kann, die Segmente des ersten Pakets sein können, ohne dass das UE in den RRC_CONNECTED-Modus über einen neuen Mechanismus übergehen muss, der als Small Data Transmission (SDT) bezeichnet werden kann.
• Beispiel PUR2 kann das Verfahren des Beispiels PUR1 oder eines anderen Beispiels hierin umfassen, bei dem das UE vorkonfigurierte Ressourcen und Konfiguration (PUR) anfordern kann, die in RRC_INACTIVE verwendet werden können, um Datenübertragung durchzuführen.
• Beispiel PUR3 kann das Verfahren des Beispiels PUR1 oder eines anderen Beispiels hierin umfassen, wobei sich das UE in einem neuen oder temporären RRC-Zustand befinden kann, während es die Daten austauscht, und durch andere Namen bezeichnet werden kann, wie „RRC INACTIVE plus“.
• Beispiel PUR4 kann das UE des Beispiels PUR1 oder eines anderen Beispiels hierin umfassen, wobei es einen der folgenden Faktoren (die netzwerkkonfiguriert sein können) verwenden kann, um zu ermitteln, ob die SDT-Funktion verwendet werden kann:
1. a. Auslöser für eine neue Zugangskategorie im Zusammenhang mit SDT
2. b. Die maximale Anzahl von aufeinanderfolgenden SDT-Vermittlungen, die erlaubt sind, während sich ein UE in RRC_INACTIVE oder „RRC INACTIVE plus“ befindet
3. c. Vorherige Einrichtung eines bestimmten DRB, der es dem UE erlaubt, SDT über PUR auszulösen
• Beispiel PUR5 kann das Verfahren von Beispiel PUR1 oder ein anderes Beispiel hierin beinhalten, wobei das UE Konfigurationen verwendet, die sowohl dem UE als auch dem gNB bekannt sind, wie z.B. ein Teil der Konfigurationen, die in dem UE konfiguriert wurden, während sie zuvor RRC_CONNECTED war, oder vorkonfigurierte Konfigurationen über Broadcasting-Signalisierung. Dies kann auch alle konfigurierten Grants beinhalten, die dem UE zur Verfügung gestellt werden, zusammen mit einer Anzeige, die es dem UE erlaubt, die Grant-Ressourcen für SDT zu nutzen, während es sich in RRC_INACTIVE befindet.
• Beispiel PUR6 kann das Verfahren von Beispiel PUR1 oder eines anderen Beispiels hierin beinhalten, wobei mit den vorherigen Zuständen der Protokollschichten fortgefahren wird, um nachfolgende Pakete in einem nachfolgenden PUR zu senden
• Beispiel PUR7 kann das Verfahren von Beispiel PUR1 oder ein anderes Beispiel hierin enthalten, wobei eine der folgenden UL-Benachrichtigungen verwendet werden kann, um das Netzwerk zu informieren, wenn mehrere nachfolgende Pakete darauf warten, über SDT gesendet zu werden:
1. a. Die Anzahl der Sub-Folge-Pakete (oder SDT-Austausche)
2. b. Größe der im SDT-Puffer gespeicherten Daten
3. c. Ein allgemeiner Hinweis darauf, dass weitere Daten darauf warten, über SDT gesendet zu werden
• Beispiel PUR8 kann das Verfahren des Beispiels PUR1 oder eines anderen Beispiels hierin umfassen, wobei das UE nach jeder Übertragung PDCCH für eine dedizierte RNTI überwacht und die zeitliche Ausrichtung auf die bedienende Zelle beibehält, um SDT über PUR durchzuführen
• Beispiel PUR9 kann das Verfahren von Beispiel PUR1 oder ein anderes Beispiel hierin beinhalten, wobei die Rekonfiguration über eine dedizierte Signalisierung erfolgen kann, die gesendet wird, während sich die UE im „RRC_INACTIVE plus“-Zustand befindet, wie z.B. über RRCReconfiguration oder RRCRelease, wobei eine Antwort des UE nicht erforderlich sein kann.
• Beispiel PUR10 kann das UE des Beispiels PUR1 oder eines anderen Beispiels hierin umfassen, wobei SDT unter Verwendung von PUR ohne die Notwendigkeit des Austauschs von RRC-Signalisierung mit dem gNB durchgeführt werden kann, indem der Zustand der Benutzerebene zwischen Übertragungen beibehalten wird.
• Beispiel PUR11 kann das UE des Beispiels PUR1 oder eines anderen Beispiels hierin enthalten, wobei die Mobilität oder die Zellenneuauswahl behandelt werden kann, um die laufenden Daten durch eines der folgenden Verfahren zu behandeln:
1. a. Rückfall zu RRC_CONNECTED (um sich auf die alten Mechanismen, z. B. HO, RLF, Wiederherstellung, zu verlassen)
2. b. Das UE oder das Netzwerk kann eine Anzeige auslösen, wenn es erkennt, dass sich das UE aus der Zelle herausbewegt, um die Freigabe zurück zu RRC_INACTIVE (oder den Übergang zu RRC_CONNECTED) auszulösen
3. c. Rückgriff auf das alte RLF-Verfahren
4. d. Aktivieren eines handover-ähnlichen Verfahrens im Zustand „RRC INACTIVE plus“.
• Beispiel PUR12 kann das Verfahren des Beispiels PUR1 oder eines anderen Beispiels hierin beinhalten, wobei der Verlust der Abdeckung durch Wiederverwendung der Wiederherstellungsprozedur behandelt werden kann, während sich das UE in „RRC INACTIVE plus“ befindet.
• Beispiel PUR13 kann das Netzwerk beinhalten, das die in PUR gesendeten Benutzerdaten verarbeiten kann, während das UE INAKTIV ist, ohne den CU-CP in einem disaggregierten gNB zu signalisieren, und die verarbeiteten Daten direkt an den CU-UP senden kann, basierend auf der Identifikation des UE, das die Daten sendet, und seinem zugehörigen Kontext.
• Beispiel PUR14 kann das Netzwerk in Beispiel PUR13 oder ein anderes Beispiel hierin beinhalten, wobei die Identifizierung des UE und des zugehörigen Kontexts und DRB auf Informationen basiert, die explizit vom UE im PUR bereitgestellt oder implizit vom Netzwerk abgeleitet werden.
• Beispiel PUR15 kann ein Verfahren zum Implementieren eines UE sein, wobei das Verfahren umfasst:
• Identifizieren, ob sich das UE in einem „RRC_INACTIVE“-Zustand befindet; und wenn sich das UE im „RRC_INACTIVE“-Zustand befindet, Empfangen eines Signals oder Kodieren eines Signals zur Übertragung, wobei das Signal mehrere Datenpakete/PDUs oder Signalisierung unter Verwendung von Small Data Transmission (SDT) enthält.
• Beispiel PUR16 kann das Verfahren von Beispiel PUR15 oder jedes andere Beispiel hierin umfassen, wobei das UE nicht in den Zustand RRC_CONNECTED übergeht, um das Signal zu empfangen oder zu senden.
• Beispiel PUR17 kann das Verfahren von Beispiel PUR15 oder jedes andere Beispiel hierin umfassen, wobei das Kodieren eines Signals für die Übertragung ferner das Kodieren eines Signals für die Übertragung kleiner Daten umfasst.
• Beispiel PUR18 kann das Verfahren des Beispiels PUR15 oder eines anderen Beispiels hierin umfassen, das außerdem Folgendes umfasst:
• Anfordern von vorkonfigurierten Ressourcen und Konfiguration (PUR); und
• Durchführen der Datenübertragung unter Verwendung der angeforderten PUR
• Beispiel PUR19 kann das Verfahren von Beispiel PUR15 oder eines anderen Beispiels hierin umfassen, wobei sich das UE in einem „RRC_INACTIVE plus“-Zustand befindet.
• Beispiel PUR20 kann das Verfahren von Beispiel PUR19 oder eines anderen Beispiels hierin beinhalten, wobei ein „RRC INACTIVE plus“-Zustand einen neuen oder temporären RRC-Zustand während des Empfangs des Signals oder der Kodierung des Signals für die Übertragung beinhaltet.
• Beispiel PUR21 kann das Verfahren des Beispiels PUR15 oder eines anderen Beispiels hierin umfassen, das ferner umfasst: Ermitteln, ob der SDT verfügbar ist.
• Beispiel PUR22 kann das Verfahren des Beispiels PUR21 oder eines anderen Beispiels hierin umfassen, wobei das Ermitteln, ob der SDT verfügbar ist, weiterhin eines oder mehrere der folgenden Elemente umfasst:
• Identifizieren eines Auslösers für eine neue Zugangskategorie in Bezug auf die SDT, Identifizieren einer maximalen Anzahl von aufeinanderfolgenden SDT-Vermittlungen, die erlaubt sind, während sich das UE in einem RRC INACTIVE oder „RRC_INACTIVE plus“-Zustand befindet, oder Aktivieren von SDT über PUR
• Beispiel PUR23 kann das Verfahren von Beispiel PUR22 oder eines anderen Beispiels hierin beinhalten, wobei das Aktivieren von SDT über PUR ferner das Identifizieren eines vorherigen Aufbaus eines DRB beinhaltet, der es dem UE erlaubt, SDT über PUR auszulösen.
• Beispiel PUR24 kann eine Vorrichtung umfassen, die Mittel zur Durchführung eines oder mehrerer Elemente eines Verfahrens, das in einem der Beispiele PUR1-23 beschrieben ist oder damit zusammenhängt, oder eines anderen hierin beschriebenen Verfahrens oder Prozesses umfasst.
• Beispiel PUR25 kann ein oder mehrere nicht-übertragbare computerlesbare Medien enthalten, die Anweisungen enthalten, um eine elektronische Vorrichtung zu veranlassen, bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung ein oder mehrere Elemente eines Verfahrens durchzuführen, das in einem der Beispiele PUR1-23 beschrieben ist oder damit in Zusammenhang steht, oder ein beliebiges anderes hier beschriebenes Verfahren oder Prozess.
• Beispiel PUR26 kann ein Gerät mit Logik, Modulen oder Schaltungen zur Durchführung eines oder mehrerer Elemente eines in den Beispielen PUR1-23 beschriebenen oder damit verbundenen Verfahrens oder eines anderen hierin beschriebenen Verfahrens oder Prozesses umfassen.
• Beispiel PUR27 kann ein Verfahren, eine Technik oder einen Prozess umfassen, wie in einem der Beispiele PUR1-23 beschrieben oder damit verbunden, oder Teile davon.
• Beispiel PUR28 kann eine Vorrichtung enthalten, die Folgendes umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen enthalten, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele PUR1-23 beschrieben oder damit verbunden, oder Teile davon durchzuführen.
• Beispiel PUR29 kann ein Signal, wie in einem der Beispiele PUR1-23 beschrieben oder damit verbunden, oder Abschnitte oder Teile davon enthalten.
• Beispiel PUR30 kann ein Datagramm, ein Paket, einen Rahmen, ein Segment, eine Protokolldateneinheit (PDU) oder eine Nachricht enthalten, wie sie in den Beispielen PUR1-23 beschrieben sind oder sich auf diese beziehen, oder Teile davon, oder wie sie anderweitig in der vorliegenden Offenbarung/Erfindung beschrieben sind.
• Beispiel PUR31 kann ein Signal enthalten, das mit Daten kodiert ist, wie sie in den Beispielen PUR1-23 oder in Teilen davon beschrieben sind, oder wie sie in der vorliegenden Offenbarung anderweitig beschrieben sind.
• Beispiel PUR32 kann ein Signal enthalten, das mit einem Datagramm, Paket, Rahmen, Segment, einer Protokolldateneinheit (PDU) oder einer Nachricht kodiert ist, wie es in den Beispielen PUR1-23 beschrieben ist oder sich auf diese bezieht, oder Teile davon, oder wie es anderweitig in der vorliegenden Offenbarung/Erfindung beschrieben ist.
• Beispiel PUR33 kann ein elektromagnetisches Signal enthalten, das computerlesbare Anweisungen trägt, wobei die Ausführung der computerlesbaren Anweisungen durch einen oder mehrere Prozessoren bewirkt, dass der eine oder die mehreren Prozessoren das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele PUR1-23 oder Teilen davon beschrieben oder damit verbunden, durchführen.
• Beispiel PUR34 kann ein Computerprogramm mit Befehlen enthalten, wobei die Ausführung des Programms durch ein Verarbeitungselement das Verarbeitungselement veranlassen soll, das Verfahren, die Techniken oder den Prozess, wie in einem der Beispiele PUR1-23 beschrieben oder damit verbunden, oder Teile davon auszuführen.
• Beispiel PUR35 kann ein Signal in einem Drahtlos-Netzwerk enthalten, wie hier gezeigt und beschrieben.
• Beispiel PUR36 kann ein Verfahren zur Kommunikation in einem Drahtlos-Netzwerk beinhalten, wie hier gezeigt und beschrieben.
• Beispiel PUR37 kann ein System zur Bereitstellung von Drahtlos-Kommunikation umfassen, wie hierin gezeigt und beschrieben.
• Beispiel PUR38 kann ein Gerät zur Bereitstellung von Drahtlos-Kommunikation umfassen, wie hier gezeigt und beschrieben.
• Jedes der oben beschriebenen Beispiele kann mit jedem anderen Beispiel (oder jeder Kombination von Beispielen) kombiniert werden, sofern nicht ausdrücklich anders angegeben. Die vorstehende Beschreibung einer oder mehrerer Ausführungsformen dient der Veranschaulichung und Beschreibung, erhebt jedoch keinen Anspruch auf Vollständigkeit oder Beschränkung des Umfangs der Ausführungsformen auf die genaue offengelegte Form. Modifikationen und Variationen sind im Lichte der obigen Lehren möglich oder können aus der Praxis der verschiedenen Ausführungsformen erworben werden.
• Abkürzungen
• Sofern hier nicht anders verwendet, stimmen die Begriffe, Definitionen und Abkürzungen mit den in 3GPP TR 21.905 v16.0.0 (2019-06) definierten Begriffen, Definitionen und Abkürzungen überein. Für die Zwecke des vorliegenden Dokuments können die folgenden Abkürzungen für die hier erörterten Beispiele und Ausführungsformen gelten.
• Terminologie
• Für die Zwecke des vorliegenden Dokuments gelten die folgenden Begriffe und Definitionen für die hier behandelten Beispiele und Ausführungsformen.
• Der Begriff „Schaltung“, wie er hier verwendet wird, bezieht sich auf Hardwarekomponenten wie eine elektronische Schaltung, eine Logikschaltung, einen Prozessor (gemeinsam, dediziert oder Gruppe) und/oder Speicher (gemeinsam, dediziert oder Gruppe), eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Bauelement (FPD) (z.B., ein feldprogrammierbares Gate-Array (FPGA), ein programmierbares Logikgerät (PLD), ein komplexes PLD (CPLD), ein Hochleistungs-PLD (HCPLD), ein strukturierter ASIC oder ein programmierbarer SoC), digitale Signalprozessoren (DSPs) usw., die so konfiguriert sind, dass sie die beschriebene Funktionalität bereitstellen. In einigen Ausführungsformen kann die Schaltung ein oder mehrere Software- oder Firmware-Programme ausführen, um zumindest einige der beschriebenen Funktionen bereitzustellen. Der Begriff „Schaltung“ kann sich auch auf eine Kombination aus einem oder mehreren Hardwareelementen (oder einer Kombination von Schaltungen, die in einem elektrischen oder elektronischen System verwendet werden) mit dem Programmcode beziehen, der verwendet wird, um die Funktionalität dieses Programmcodes auszuführen. In diesen Fällen kann die Kombination aus Hardwareelementen und Programmcode als eine bestimmte Art von Schaltung bezeichnet werden.
• Der Begriff „Prozessorschaltung“, wie er hier verwendet wird, bezieht sich auf eine Schaltung, die in der Lage ist, sequentiell und automatisch eine Folge von arithmetischen oder logischen Operationen auszuführen oder digitale Daten aufzuzeichnen, zu speichern und/oder zu übertragen, oder ist ein Teil davon. Die Verarbeitungsschaltung kann einen oder mehrere Prozessorkerne zur Ausführung von Befehlen und eine oder mehrere Speicherstrukturen zur Speicherung von Programm- und Dateninformationen umfassen. Der Begriff „Verarbeitungsschaltung“ kann sich auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische Zentraleinheit (CPU), einen Single-Core-Prozessor, einen Dual-Core-Prozessor, einen Triple-Core-Prozessor, einen Quad-Core-Prozessor und/oder jedes andere Gerät beziehen, das in der Lage ist, computerausführbare Befehle, wie Programmcode, Softwaremodule und/oder funktionale Prozesse, auszuführen oder anderweitig zu betreiben. Die Verarbeitungsschaltung kann weitere Hardware-Beschleuniger umfassen, bei denen es sich um Mikroprozessoren, programmierbare Verarbeitungsgeräte oder Ähnliches handeln kann. Der eine oder die mehreren Hardware-Beschleuniger können beispielsweise Computer Vision (CV) und/oder Deep Learning (DL) Beschleuniger umfassen. Die Begriffe „Anwendungsschaltungen“ und/oder „Basisbandschaltungen“ können als Synonyme für „Prozessorschaltungen“ betrachtet und als solche bezeichnet werden.
• Der Begriff „Schnittstellenschaltung“, wie er hier verwendet wird, bezieht sich auf eine Schaltung, die den Informationsaustausch zwischen zwei oder mehr Komponenten oder Geräten ermöglicht, oder ist Teil einer solchen Schaltung oder umfasst eine solche. Der Begriff „Schnittstellenschaltung“ kann sich auf eine oder mehrere Hardwareschnittstellen beziehen, z.B. Busse, E/A-Schnittstellen, Schnittstellen für periphere Komponenten, Netzwerkschnittstellenkarten und/oder dergleichen.
• Der hier verwendete Begriff „Benutzergerät“ oder „UE“ bezieht sich auf ein Gerät mit Funkkommunikationsfähigkeiten und kann einen entfernten Benutzer von Netzressourcen in einem Kommunikationsnetzwerk beschreiben. Der Begriff „Benutzergerät“ oder „UE“ kann als Synonym für Client, Mobilgerät, mobiles Gerät, mobiles Endgerät, Benutzerendgerät, mobile Einheit, mobile Station, mobiler Benutzer, Teilnehmer, Benutzer, Gegenstelle, Zugangsagent, Benutzeragent, Empfänger, Funkgerät, rekonfigurierbares Funkgerät, rekonfigurierbares mobiles Gerät usw. betrachtet werden und als solche bezeichnet werden. Darüber hinaus kann der Begriff „Benutzergerät“ oder „UE“ jede Art von drahtlosem/verdrahtetem Gerät oder jedes Computergerät mit einer Schnittstelle für drahtlose Kommunikation umfassen.
• Der hier verwendete Begriff „Netzwerkelement“ bezieht sich auf physische oder virtualisierte Geräte und/oder Infrastrukturen, die zur Bereitstellung von Netzdiensten für die drahtgebundene oder drahtlose Kommunikation verwendet werden. Der Begriff „Netzwerkelement“ kann als Synonym für einen vernetzten Computer, Netzwerkhardware, Netzwerkausrüstung, Netzwerkknoten, Router, Switch, Hub, Bridge, Funknetzwerkcontroller, RAN-Gerät, RAN-Knoten, Gateway, Server, virtualisierte VNF, NFVI und/oder Ähnliches betrachtet werden und/oder als solcher bezeichnet werden.
• Der Begriff „Computersystem“, wie er hier verwendet wird, bezieht sich auf jede Art von miteinander verbundenen elektronischen Geräten, Computergeräten oder deren Komponenten. Außerdem kann sich der Begriff „Computersystem“ und/oder „System“ auf verschiedene Komponenten eines Computers beziehen, die kommunikativ miteinander verbunden sind. Darüber hinaus kann sich der Begriff „Computersystem“ und/oder „System“ auf mehrere Computergeräte und/oder mehrere Computersysteme beziehen, die kommunikativ miteinander verbunden und so konfiguriert sind, dass sie Computer- und/oder Netzwerkressourcen gemeinsam nutzen.
• Der hier verwendete Begriff „Gerät“, „Computergerät“ oder ähnliches bezieht sich auf ein Computergerät oder Computersystem mit Programmcode (z. B. Software oder Firmware), das speziell für die Bereitstellung einer bestimmten Computerressource konzipiert ist. Ein „virtuelles Gerät“ ist ein Abbild einer virtuellen Maschine, das von einem mit einem Hypervisor ausgestatteten Gerät implementiert wird, das ein Computergerät virtualisiert oder emuliert oder anderweitig für die Bereitstellung einer bestimmten Computerressource bestimmt ist.
• Der hier verwendete Begriff „Ressource“ bezieht sich auf ein physisches oder virtuelles Gerät, eine physische oder virtuelle Komponente innerhalb einer Computerumgebung und/oder eine physische oder virtuelle Komponente innerhalb eines bestimmten Geräts, wie z.B. Computergeräte, mechanische Geräte, Speicherplatz, Prozessor-/CPU-Zeit, Prozessor-/CPU-Nutzung, Prozessor- und Beschleunigerlasten, Hardware-Zeit oder -Nutzung, elektrische Leistung, Eingabe-/Ausgabeoperationen, Ports oder Netzwerkbuchsen, Kanal-/Link-Zuweisung, Durchsatz, Speichernutzung, Netzwerk, Datenbank und Anwendungen, Workload-Einheiten und/oder dergleichen. Eine „Hardwareressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die von einem oder mehreren physischen Hardwareelementen bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicher- und/oder Netzwerkressourcen beziehen, die von einer Virtualisierungsinfrastruktur für eine Anwendung, ein Gerät, ein System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, auf die Computergeräte/- systeme über ein Kommunikationsnetz zugreifen können. Der Begriff „Systemressourcen“ kann sich auf jede Art von gemeinsam genutzten Einheiten zur Bereitstellung von Diensten beziehen und kann Computer- und/oder Netzwerkressourcen umfassen. Systemressourcen können als eine Reihe von kohärenten Funktionen, Netzwerkdatenobjekten oder Diensten betrachtet werden, auf die über einen Server zugegriffen werden kann, wobei sich diese Systemressourcen auf einem einzelnen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind.
• Der hier verwendete Begriff „Kanal“ bezieht sich auf ein materielles oder immaterielles Übertragungsmedium, das zur Übertragung von Daten oder eines Datenstroms verwendet wird. Der Begriff „Kanal“ kann synonym und/oder gleichbedeutend sein mit „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugangskanal“, „Datenzugangskanal“, „Verbindung“, „Datenverbindung“, „Träger“, „Hochfrequenzträger“ und/oder jedem anderen ähnlichen Begriff, der einen Weg oder ein Medium bezeichnet, über den/das Daten übertragen werden. Darüber hinaus bezieht sich der Begriff „Verbindung“, wie er hier verwendet wird, auf eine Verbindung zwischen zwei Geräten über ein RAT zum Zweck der Übertragung und des Empfangs von Informationen.
• Die hier verwendeten Begriffe „instanziieren“, „Instanziierung“ und dergleichen beziehen sich auf die Erstellung einer Instanz. Eine „Instanz“ bezieht sich auch auf ein konkretes Auftreten eines Objekts, das z.B. während der Ausführung von Programmcode auftreten kann.
• Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“ sowie deren Ableitungen werden hier verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander stehen, dass zwei oder mehr Elemente indirekt miteinander in Kontakt stehen, aber dennoch miteinander kooperieren oder interagieren, und/oder dass ein oder mehrere andere Elemente zwischen den Elementen, die als miteinander gekoppelt gelten, gekoppelt oder verbunden sind. Der Begriff „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt zueinander stehen. Der Begriff „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente über ein Kommunikationsmittel miteinander in Kontakt stehen können, z.B. über ein Kabel oder eine andere Verbindung, über einen Drahtlos-Kommunikationskanal oder eine Drahtlos-Verbindung und/oder Ähnliches.
• Der Begriff „Informationselement“ bezieht sich auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff „Feld“ bezieht sich auf einzelne Inhalte eines Informationselements oder auf ein Datenelement, das Inhalte enthält.
• Der Begriff „SMTC“ bezieht sich auf eine SSB-basierte Messzeitkonfiguration, die durch SSB-MeasurementTimingConfiguration konfiguriert wird.
• Der Begriff „SSB“ bezieht sich auf einen SS/PBCH-Block.
• Der Begriff „Primäre Zelle“ bezieht sich auf die MCG-Zelle, die auf der primären Frequenz betrieben wird und in der das UE entweder das anfängliche Verbindungsaufbauverfahren durchführt oder das Verfahren zum erneuten Verbindungsaufbau einleitet.
• Der Begriff „Primäre SCG-Zelle“ bezieht sich auf die SCG-Zelle, in der das UE einen wahlfreien Zugriff durchführt, wenn es die Rekonfigurationsprozedur mit Synchronisierung für den DC-Betrieb durchführt.
• Der Begriff „Sekundäre Zelle“ bezieht sich auf eine Zelle, die zusätzliche Funkressourcen zusätzlich zu einer speziellen Zelle für ein mit CA konfiguriertes UE bereitstellt.
• Der Begriff „Sekundärzellengruppe“ bezieht sich auf die Untergruppe von Serving Cells, die die PSCell und null oder mehr Sekundärzellen für ein mit DC konfiguriertes UE umfassen.
• Der Begriff „Serving Cell“ bezieht sich auf die primäre Zelle für ein UE in RRC_CONNECTED, das nicht mit CA/DC konfiguriert ist, da es nur eine Serving Cell gibt, die aus der primären Zelle besteht.
• Der Begriff „Serving Cell“ oder „Serving Cells“ bezieht sich auf den Satz von Zellen, der die Special Cell(s) und alle sekundären Zellen für ein UE in RRC_CONNECTED mit CA/DC umfasst.
• Der Begriff „Spezialzelle“ bezieht sich auf die PCell des MCG oder die PSCell des SCG für DC-Betrieb; ansonsten bezieht sich der Begriff „Spezialzelle“ auf die Pcell.
• Der Zustand RRC_CONNECTED ist ein Zustand, in dem eine 5GC - NG-RAN-Verbindung (beide C/U-Ebenen) für UE hergestellt wird. Der AS-Kontext des UE ist im NG-RAN und in dem UE gespeichert. NG-RAN kennt die Zelle, zu der das UE gehört. Die Übertragung von Unicast-Daten zum/vom UE ist bei netzwerkgesteuerter Mobilität einschließlich Messungen möglich.
• Der Begriff „gNB Central Unit (gNB-CU“) ist ein logischer Knoten, der RRC-, SDAP- und PDCP-Protokolle des gNB oder RRC- und PDCP-Protokolle des en-gNB hostet und den Betrieb einer oder mehrerer gNB-DUs steuert. Die gNB-CU schließt die mit der gNB-DU verbundene F1-Schnittstelle ab.
• Der Begriff „gNB Distributed Unit (gNB-DU)“ ist ein logischer Knoten, der die RLC-, MAC- und PHY-Schichten des gNB oder en-gNB beherbergt und dessen Betrieb teilweise von der gNB-CU gesteuert wird. Eine gNB-DU unterstützt eine oder mehrere Zellen. Eine Zelle wird von nur einer gNB-DU unterstützt. Die gNB-DU terminiert die mit der gNB-CU verbundene F1-Schnittstelle.
• Es sind zwei Arten von Random-Access-Verfahren definiert. Der 4-Schritt-RA-Typ mit MSG1 und der 2-Schritt-RA-Typ mit MSGA. Die MSGA des 2-Schritt-RA-Typs umfasst eine Präambel auf PRACH und eine Nutzlast auf PUSCH. Nach der MSGA-Übertragung wartet das UE innerhalb eines konfigurierten Zeitfensters auf eine Antwort aus dem Netzwerk.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• US 63/058399 [0001]
• US 63/058415 [0001]

Claims (10)

1. Eine Vorrichtung eines Benutzergeräts (UE), wobei die Vorrichtung eine Funkfrequenz-(RF)-Schnittstelle und einen oder mehrere Prozessoren enthält, die mit der RF-Schnittstelle gekoppelt und konfiguriert sind: Ressourcen und Konfigurationen zum Übertragen einer Vielzahl von kleinen Datenübertragungspaketen (SDT) zu einer Basisstation (BS) in einer SDT-Sitzung, während das UE RRC_INACTIVE bleibt, zu ermitteln; und in der SDT-Sitzung, während das UE RRC _INACTIVE bleibt, eines ersten SDT-Pakets der Vielzahl von SDT-Paketen unter Verwendung der bestimmten Ressourcen und Konfigurationen, an die BS zu senden oder von der BS zu empfangen.
2. Die Vorrichtung nach Anspruch 1, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind: der BS ein nachfolgendes SDT-Paket aus der Vielzahl von zu übertragenden SDT-Paketen anzuzeigen, wobei die Vielzahl von SDT-Paketen Benutzerdaten und/oder Signalisierungsdaten enthält, und wobei optional die Vielzahl von SDT-Paketen Segmente eines einzelnen größeren Pakets oder eine Vielzahl von einzelnen Paketen enthält, und wobei ferner optional das erste SDT-Paket ein Uplink-SDT-Paket, ein Downlink-SDT-Paket und/oder beides ist, wobei optional die Anzeige des nachfolgenden SDT-Pakets eine allgemeine Anzeige von mehr zu übertragenden SDT-Paketen, eine Anzahl von zu übertragenden SDT-Paketsegmenten oder eine Pufferanzeige, dass mehr SDT-Pakete in einem SDT-Puffer warten, enthält, und wobei optional der eine oder die mehreren Prozessoren weiter konfiguriert sind: das nachfolgende SDT-Paket in der SDT-Sitzung an die BS zu senden oder von ihr zu empfangen, während das UE RRC_INACTIVE bleibt.
3. Die Vorrichtung nach einem der Ansprüche 1 oder 2, wobei der eine oder die mehreren Prozessoren weiterhin konfiguriert sind: einige oder alle Benutzerebenen-Zustände im Access Stratum während der SDT-Sitzung aufrechtzuerhalten, und einige oder alle Konfigurationen im Access Stratum beizubehalten, während das UE RRC INACTIVE ist, und wobei optional der eine oder die mehreren Prozessoren weiter konfiguriert sind, einen Teil der Konfigurationen, die zuvor in dem UE konfiguriert wurden, zu verwenden und/oder wieder aufzunehmen.
4. Vorrichtung nach einem der Ansprüche 1 bis 3, wobei, während sich das UE in der SDT-Sitzung befindet, das UE über eine dedizierte Steuernachricht rekonfigurierbar ist.
5. Die Vorrichtung nach einem der Ansprüche 1-4, wobei das Ermitteln von Ressourcen und Konfigurationen zum Übertragen der Vielzahl von kleinen Datenübertragungen die Verwendung von vorbestimmten Standardressourcen und -konfigurationen, die Verwendung von Ressourcen und Konfigurationen, die in dem UE über dedizierte Signalisierung konfiguriert sind, oder die Verwendung von Ressourcen und Konfigurationen, die über Broadcast von der BS als Teil der RACH-Prozedur signalisiert werden, einschließt; wobei die optionale Verwendung von Ressourcen und Konfigurationen, die über Broadcast von der BS als Teil der RACH-Prozedur signalisiert werden, Folgendes umfasst Übertragen einer PRACH-Nachricht an die BS, um mindestens eines der mehreren SDT-Pakete anzuzeigen; Empfangen einer RAR-Nachricht von der BS, die eine Zuteilungsgröße der Ressourcen enthält; Übertragen des ersten SDT-Pakets unter Verwendung der Ressourcen an die BS; und Übertragen einer Anzeige von weiteren SDT-Paketen an die BS; oder Übertragen einer PRACH-Nachricht an die BS, um mindestens eines der mehreren SDT-Pakete anzuzeigen; Empfangen einer gesendeten Nachricht von der BS, die eine Zuteilungsgröße der Ressourcen enthält; Übertragen des ersten SDT-Pakets an die BS oder Empfangen des ersten SDT-Pakets von der BS unter Verwendung der Ressourcen; und Übertragen einer Anzeige weiterer SDT-Pakete an die BS; oder wobei die optionale Verwendung von Ressourcen und Konfigurationen, die in dem UE konfiguriert wurden, während das UE RRC_CONNECTED war, die Verwendung von Ressourcen und Konfigurationen einschließt, die in einer konfigurierten Zuteilung bereitgestellt werden, wobei die konfigurierte Zuteilung eine Anzeige einschließt, dass es dem UE gestattet ist, die darin bereitgestellten Ressourcen und Konfigurationen zu verwenden, während das UE RRC_ INACTIVE ist.
6. Vorrichtung nach Anspruch 5, wobei der eine oder die mehreren Prozessoren ferner konfiguriert sind: mit der BS eines der mehreren SDT-Pakete auszutauschen; und/oder einen Physical Downlink Control Channel (PDCCH) auf einen dedizierten Radio Network Temporary Identifier (RNTI) zu überwachen, wobei optional der eine oder die mehreren Prozessoren ferner konfiguriert sind: zu ermitteln, dass Bedingungen für die Übertragung von SDT-Paketen erfüllt sind, wobei die Bedingungen umfassen: a. Identifizieren eines Auslösers für eine neue Zugangskategorie, die sich auf SDT bezieht, b. Ermitteln einer maximalen Anzahl von aufeinanderfolgenden SDT-Austauschen, die erlaubt sind, während sich ein UE in RRC INACTIVE befindet, oder c. Ermitteln, dass SDT über configured grant (CG) aktiviert ist, und wobei ferner optional der eine oder die mehreren Prozessoren ferner so konfiguriert sind, dass sie nach einem Ausfall während der SDT-Sitzung die SDT-Sitzung durch ein Wiederaufbau-ähnliches Verfahren wiederherstellen, um sie fortzusetzen.
7. Eine Vorrichtung einer Basisstation (BS), die für den Betrieb in einem Netzwerk der fünften Generation (5G) konfiguriert ist, wobei die Vorrichtung umfasst: eine Verarbeitungsschaltung; eine Steuerebenen-Schnittstelle, die durch die Verarbeitungsschaltung konfiguriert ist, um Steuersignale zu übertragen; und eine Schnittstelle der Benutzerebene, die durch die Verarbeitungsschaltung konfiguriert ist, um Verkehrsdaten zu übertragen, wobei die Verarbeitungsschaltung konfiguriert ist: Ressourcen und Konfigurationen zum Empfangen einer Vielzahl von kleinen Datenübertragungspaketen (SDT) von einer Benutzereinrichtung (UE) in einer SDT-Sitzung zu ermitteln, während das UE RRC_INACTIVE bleibt; und während das UE RRC INACTIVE bleibt, ein erstes SDT-Paket der Vielzahl von SDT-Paketen unter Verwendung der ermittelten Ressourcen und Konfigurationen an das UE zu senden oder von dem UE zu empfangen.
8. Vorrichtung nach Anspruch 7, wobei die Verarbeitungsschaltung ferner konfiguriert ist: einen Hinweises von dem UE auf ein nachfolgendes SDT-Paket aus der Vielzahl von zu übertragenden SDT-Paketen zu empfangen, wobei die Vielzahl von SDT-Paketen Benutzerdaten und/oder Signalisierungsdaten enthält, wobei optional die Vielzahl von SDT-Paketen Segmente eines einzelnen größeren Pakets oder eine Vielzahl von einzelnen Paketen enthält, und wobei ferner optional das erste SDT-Paket ein Uplink-SDT-Paket, ein Downlink-SDT-Paket und/oder beides ist, wobei optional die Anzeige des nachfolgenden SDT-Pakets eine allgemeine Anzeige von mehr zu übertragenden SDT-Paketen, eine Anzahl von zu übertragenden SDT-Paketsegmenten oder eine Pufferanzeige, dass mehr SDT-Pakete in einem SDT-Puffer warten, enthält, und wobei optional die Verarbeitungsschaltung ferner so konfiguriert ist, dass sie das nachfolgende SDT-Paket in der SDT-Sitzung und während das UE RRC INACTIVE bleibt, an die BS sendet oder von ihr empfängt.
9. Vorrichtung nach einem der Ansprüche 7 bis 8, wobei das Ermitteln von Ressourcen und Konfigurationen zum Übertragen der mehreren kleinen Datenübertragungen die Verwendung vorbestimmter Standardressourcen und -konfigurationen, die Verwendung von Ressourcen und Konfigurationen, die in dem UE über dedizierte Signalisierung konfiguriert sind, oder die Verwendung von Ressourcen und Konfigurationen, die mittels Broadcast an das UE als Teil des RACH-Verfahrens signalisiert werden, umfasst.
10. Die Vorrichtung nach einem der Ansprüche 7 bis 9, wobei die Verarbeitungsschaltung weiterhin konfiguriert ist: einige oder alle Benutzerebenen-Zustände im Access Stratum während der SDT-Sitzung aufrechtzuerhalten, und einige oder alle Konfigurationen im Access Stratum beizubehalten, während das UE RRC INACTIVE ist, und/oder von einer anderen Basisstation die Konfigurationen für das UE abzurufen. wobei optional die Verarbeitungsschaltung ferner so konfiguriert ist, dass sie einen Teil der Konfigurationen, die zuvor in dem UE konfiguriert wurden, verwendet und/oder wieder aufnimmt.

Images