Monitoring physical downlink control channel for small data transmission

Abstract

A method for a user equipment (UE) to monitor a physical downlink control channel (PDCCH) is provided. When the method includes, receiving, from a base station (BS), a radio resource control (RRC) release message when the UE is in an RRC_CONNECTED state, wherein the RRC release message includes a small data transmission (SDT) configuration. After receiving the RRC release message, the method transitions the UE from the RRC_CONNECTED state to an RRC_INACTIVE state in response to the received RRC release message. Then, the method initiates an SDT procedure according to the SDT configuration. The method further determines whether a search space set associated with an SDT search space is received from the BS. The method monitors the PDCCH by monitoring the search space set when the search space set is received from the BS in the SDT procedure.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of U.S. Provisional Application Serial No. 63 / 158,813, filed March 9, 2021, entitled “PDCCH MONITORING IN RRC_INACTIVE STATE”, Agent No. US84220; the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This application generally relates to wireless communication, and more specifically, to monitoring the Physical Downlink Control Channel (PDCCH) via User Equipment (UE). Background Technology

[0004] With the massive increase in the number of connected devices and the rapid rise in user / network traffic, various efforts have been made to improve all aspects of wireless communication in next-generation wireless communication systems (such as fifth-generation (5G) New Radio (NR)) by increasing data rates, latency, reliability, and mobility. 5G NR systems are designed to provide flexibility and configurability to optimize network services and types to adapt to various use cases, such as enhanced mobile broadband (eMBB), massive machine-type communication (mMTC), and ultra-reliable and low-latency communication (URLLC).

[0005] In the third-generation cooperation project (3 rdIn the Generation Partnership Project (3GPP), NR can support the Radio Resource Control (RRC) Inactive (RRC_INACTIVE) state, in which the network (NW) can maintain infrequent (e.g., periodic and / or aperiodic) data transmissions by user equipment. Data transmission in the RRC_INACTIVE state was not supported until 3GPP Release 16 (Rel-16). Therefore, prior to Rel-16, user equipment might have had to restore connectivity for any downlink (DL) data reception and / or uplink (UL) data transmission (e.g., move to the RRC_CONNECTED state). Regardless of how small and infrequent the data packets were, each data transmission involved connection setup and subsequent release to the RRC_INACTIVE state, which could result in unnecessary power consumption and signaling overhead.

[0006] However, the signaling overhead from UEs in the RRC_INACTIVE state due to the transmission of small data packets can be a common and critical issue, as the increased number of user equipments in NR networks impacts not only network performance and efficiency but also UE battery performance. Generally, any UE (e.g., device) with intermittent small data packets in the RRC_INACTIVE state can benefit from enabling small data transmission (SDT) in this state. Key enabling factors for small data transmission in NR, namely RRC_INACTIVE, two-step RACH, four-step RACH, and / or configuration authorization type 1, have been designated as part of the legacy protocol. Therefore, this application may improve the legacy protocol and enable UEs in the RRC_INACTIVE state to perform small data transmission in NR. Summary of the Invention

[0007] As described above, this application relates to a method for monitoring the PDCCH in the SDT to receive scheduling of data transmissions from the NW. This method may include determining how and when to monitor the PDCCH in the SDT to receive scheduling, for example, via Downlink Control Information (DCI).

[0008] In a first aspect of this application, a method for monitoring the PDCCH via a user equipment (UE) is provided. When the UE is in a Radio Resource Control (RRC_CONNECTED) state, the method receives an RRC release message from a base station (BS) including an SDT configuration. In response to receiving the RRC release message, the UE transitions from the RRC_CONNECTED state to the RRC_INACTIVE state. The method initiates an SDT procedure based on the SDT configuration, determines whether a search space set associated with the SDT search space is received from the base station (BS), and when it is determined that a search space set is received from the BS, monitors the PDCCH by monitoring the search space set during the SDT procedure.

[0009] In one embodiment of the first aspect, when the SDT procedure includes a Random Access (RA)-based SDT procedure and it is determined that no search space set is received from the base station, the method further includes monitoring the PDCCH by monitoring a common search space set associated with the RA search space during the SDT procedure.

[0010] In another implementation of the first aspect, when the SDT procedure includes a random access (RA) based SDT procedure, the search space set includes a common search space (CSS) set.

[0011] In another embodiment of the first aspect, when the search space set includes a CSS set, the SDT search space is configured via the PDCCH-ConfigCommon information element (IE). The PDCCH common configuration can be configured via system information and / or via SIB1.

[0012] In another embodiment of the first aspect, the method further includes monitoring the PDCCH, which includes monitoring the PDCCH after determining that the RA procedure has been successfully completed when the SDT procedure includes a random access (RA) based SDT procedure, and until the random access RA based SDT procedure terminates.

[0013] In another embodiment of the first aspect, the method further includes monitoring the PDCCH, which includes monitoring the PDCCH addressing to the Cell-Radio Network Temporary Identifier (C-RNTI) when the SDT procedure includes a Random Access (RA)-based SDT procedure.

[0014] In another implementation of the first aspect, when the SDT procedure includes a Configuration Grant (CG) based SDT procedure, the search space set includes a User Equipment-Specific Search Space (USS) set.

[0015] In another implementation of the first aspect, when the search space set includes the USS set, the SDT search space is configured via the PDCCH configuration (PDCCH-Config) information element (IE) received in the RRC release message. The PDCCH configuration can be configured via a BWP configuration dedicated to SDT.

[0016] In another embodiment of the first aspect, the method further includes monitoring the PDCCH, which includes monitoring the PDCCH after the initial transmission of the SDT procedure based on the configuration authorization (CG) when the SDT procedure includes the configuration authorization (CG) based SDT procedure, and until the SDT procedure based on the configuration authorization (CG) is terminated.

[0017] In another embodiment of the first aspect, the method further includes monitoring the PDCCH, which includes monitoring the PDCCH addressing to the Cell Radio Network Temporary Identifier (C-RNTI) and addressing to the Configuration Scheduling Radio Network Temporary Identifier (CS-RNTI) when the SDT procedure includes a Configuration Authorization (CG) based SDT procedure.

[0018] In a second aspect, a user equipment (UE) is provided. The UE includes one or more non-transitory computer-readable media storing computer-executable instructions for monitoring the PDCCH. The UE also includes at least one processor coupled to the one or more non-transitory computer-readable media and configured to execute the computer-executable instructions to receive an RRC release message from a base station (BS) including a Small Data Transmission (SDT) configuration when the UE is in a Radio Resource Control (RRC_CONNECTED) state. The UE is also configured to transition from the RRC_CONNECTED state to the RRC_INACTIVE state in response to receiving the RRC release message. The UE is further configured to initiate an SDT procedure based on the SDT configuration. The UE is also configured to determine whether a search space set associated with an SDT search space has been received from the base station (BS). The UE is further configured to monitor the PDCCH by monitoring the search space set during the SDT procedure when it is determined that a search space set has been received from the BS.

[0019] In one embodiment of the second aspect, at least one processor is further configured to execute computer-executable instructions to monitor the PDCCH by monitoring a common search space set associated with the random access (RA) search space during the SDT process when the SDT process includes a random access (RA) based SDT process and no search space set is received from the base station.

[0020] In another implementation of the second aspect, when the SDT procedure includes a random access (RA) based SDT procedure, the search space set includes a common search space (CSS) set.

[0021] In another implementation of the second aspect, when the search space set includes a CSS set, the SDT search space is configured via the PDCCH-ConfigCommon information element (IE). The PDCCH-ConfigCommon configuration can be configured via system information and / or via SIB1.

[0022] In another embodiment of the second aspect, at least one processor is further configured to execute computer-executable instructions to monitor the PDCCH, including monitoring the PDCCH after determining that the RA procedure has been successfully completed when the SDT procedure includes a random access (RA)-based SDT procedure, and until the random access RA-based SDT procedure terminates.

[0023] In another embodiment of the second aspect, at least one processor is further configured to execute computer-executable instructions to monitor the PDCCH, including monitoring the PDCCH addressing to the Cell-Radio Network Temporary Identifier (C-RNTI) when the SDT procedure includes a Random Access (RA)-based SDT procedure.

[0024] In another implementation of the second aspect, when the SDT process includes a Configuration Grant (CG) based SDT process, the search space set includes a User Equipment-Specific Search Space (USS) set.

[0025] In another implementation of the second aspect, when the search space set includes the USS set, the SDT search space is configured via the PDCCH configuration (PDCCH-Config) information element (IE) received in the RRC release message. The PDCCH configuration can be configured via a BWP configuration dedicated to the SDT.

[0026] In another embodiment of the second aspect, at least one processor is further configured to execute computer-executable instructions to monitor the PDCCH, including monitoring the PDCCH after the initial transmission of the configuration-granted CG-based SDT procedure when the SDT procedure includes a configuration-granted (CG)-based SDT procedure, and until the termination of the configuration-granted CG-based SDT procedure.

[0027] In another embodiment of the second aspect, at least one processor is further configured to execute computer-executable instructions to monitor the PDCCH, including monitoring the PDCCH addressing to the Cell Radio Network Temporary Identifier (C-RNTI) and addressing to the Configuration Scheduling Radio Network Temporary Identifier (CS-RNTI) when the SDT process includes a Configuration Grant (CG) based SDT procedure. Attached Figure Description

[0028] The various aspects of this exemplary disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. For clarity of discussion, the various features are not drawn to scale, and the dimensions of the various features may be arbitrarily increased or decreased.

[0029] Figure 1 This is a schematic flowchart illustrating an SDT procedure performed by a UE according to an exemplary embodiment of this application.

[0030] Figure 2 A schematic diagram of an RA-based SDT process according to one of the exemplary embodiments of this application is shown.

[0031] Figure 3 A schematic diagram of a CG-based SDT process according to one of the exemplary embodiments of this application is shown.

[0032] Figure 4A and Figure 4B A schematic diagram of an SDT cycle associated with an SDT process according to one of the exemplary embodiments of this application is shown.

[0033] Figure 5 A schematic diagram illustrating an alternative PDCCH monitoring scheme according to one of the exemplary embodiments of this application is shown.

[0034] Figure 6 A schematic diagram illustrating the overlapping period between different PDCCH monitoring times according to one of the exemplary embodiments of this application is shown.

[0035] Figure 7 A flowchart illustrating a method or process for monitoring PDCCH during an SDT process according to one of the exemplary embodiments of this application is shown.

[0036] Figure 8A block diagram of a node for wireless communication according to an exemplary embodiment of this application is shown. Detailed Implementation

[0037] The abbreviations used in this application are defined as follows, and unless otherwise stated, the abbreviations have the following meanings: full name of the abbreviation

[0038] Alternative (ALT)

[0039] Access Stratum (AS)

[0040] Acknowledgment (ACK)

[0041] Base Station (BS)

[0042] Buffer Status Request (BSR)

[0043] Bandwidth Part (BWP)

[0044] Contention Based Random Access (CBRA)

[0045] Common Control Channel (CCCH)

[0046] Control Element (CE)

[0047] Contention-Free Random Access (CFRA)

[0048] Configured Grant (CG)

[0049] Control Resource Set (CORESET)

[0050] Cell-Radio Network Temporary Identifier (C-RNTI)

[0051] Channel State Information (CSI)

[0052] Configured Scheduling RNTI (CS-RNTI)

[0053] Common Search Space (CSS)

[0054] Downlink Control Information (DCI)

[0055] Dynamic Grant (DG)

[0056] Downlink (DL)

[0057] Demodulation Reference Signal (DM-RS)

[0058] Data Radio Bearer (DRB)

[0059] Discontinuous Reception (DRX)

[0060] Frequency Range (FR)

[0061] Hybrid Automatic Repeat reQuest (HARQ)

[0062] Information Elements (IE)

[0063] Logical Channel (LCH)

[0064] Logical Channel Prioritization (LCP)

[0065] Medium Access Control (MAC)

[0066] Master Cell Group (MCG)

[0067] Master Information Block (MIB)

[0068] Message (Msg / MSG)

[0069] Negative Acknowledgment (NACK)

[0070] Non-Access Stratum (NAS)

[0071] New Radio (NR)

[0072] Network (NW)

[0073] Normal uplink (NUL)

[0074] Primacy Cell (PCell)

[0075] Physical Downlink Control Channel (PDCCH), Physical Downlink Shared Channel (PDSCH), Protocol Data Unit (PDU)

[0076] Physical Layer (PHY)

[0077] Physical Random Access Channel (PRACH)

[0078] Physical Uplink Control Channel (PUCCH)

[0079] Physical Uplink Shared Channel (PUSCH)

[0080] Quasi-co-location (QCL)

[0081] Random Access (RA)

[0082] Random Access Channel (RACH)

[0083] Random Access Response (RAR)

[0084] Release (Rel)

[0085] Radio Link Control (RLC)

[0086] Radio Network Temporary Identifier (RNTI) and Radio Resource Control (RRC)

[0087] Reference Signal (RS)

[0088] Reference Signal Received Power (RSRP)

[0089] Receive (Reception, Rx)

[0090] Secondary Cell (SCell)

[0091] Secondary Cell Group (SCG)

[0092] Subcarrier Spacing (SCS)

[0093] Small Data Transmission (SDT)

[0094] Service Data Unit (SDU)

[0095] System Information (SI)

[0096] System Information Block (SIB)

[0097] Semi-Persistent Schedule (SPS)

[0098] Signaling Radio Bearer (SRB)

[0099] Synchronization Signal (SS)

[0100] SS / PBCH Block (SSB)

[0101] Synchronization Signal-RSRP (SS-RSRP)

[0102] Supplementary Uplink (SUL)

[0103] Timing Advance (TA)

[0104] Timing Alignment Timer (TAT)

[0105] Transmission Configuration Indicator (TCI)

[0106] Technical Specification (TS)

[0107] Transmission (Tx)

[0108] Transport Block Size (TBS)

[0109] Transmission and Reception Point (TRP)

[0110] Uplink Control Information (UCI)

[0111] User Equipment (UE)

[0112] Uplink (UL)

[0113] UE-specific Search Space (USS)

[0114] The following description contains specific information relating to exemplary embodiments in this application. The accompanying drawings and detailed description are merely exemplary embodiments. However, this application is not limited to these exemplary embodiments. Other variations and embodiments of this application will occur to those skilled in the art. Unless otherwise stated, identical or corresponding parts in the drawings may be indicated by identical or corresponding reference numerals. Furthermore, the drawings and illustrations in this application are generally not drawn to scale and are not intended to correspond to actual relative dimensions.

[0115] For the purposes of consistency and ease of understanding, the same reference numerals are used to designate the same features in the exemplary drawings (although this is not the case in some examples). However, features in different embodiments may differ in other respects, and therefore should not be narrowly limited to the features shown in the drawings.

[0116] Descriptions using the phrases "one implementation" or "some implementations" can each be considered as one or more identical or different implementations. Descriptions using the phrases "one embodiment" or "some embodiments" can each be considered as one or more identical or different embodiments. The term "coupled" is defined as a direct or indirect connection via an intermediate component and is not necessarily limited to a physical connection. The term "comprising" when used means "including but not limited to"; it explicitly indicates members of an open-ended combination, group, series, and equivalent. The phrase "at least one of A, B, and C" or "at least one of A, B, and C" means "only A, or only B, or only C, or any combination of A, B, and C."

[0117] Any sentence, paragraph, (sub)item, point, action, behavior, term, alternative, aspect, example, or claim described in this application may be logically, reasonably, and appropriately combined to form a particular method. Any sentence, paragraph, (sub)item, point, action, behavior, term, alternative, aspect, example, or claim described in this application may be implemented independently and separately to form a particular method. Dependencies, such as “based on,” “more specifically,” “in some embodiments,” “in an alternative,” “in an example,” “in an aspect,” etc., are merely possible examples in this application and do not limit the particular method. One aspect of this application may be used, for example, in communications, communication devices (e.g., mobile phone devices, base station devices, wireless LAN devices, and / or sensor devices), integrated circuits (e.g., communication chips), and / or programs. According to any sentence, paragraph, (sub)item, point, action, behavior, term, alternative, aspect, example, implementation, or claim in this application, “X / Y” may include the meaning of “X or Y.” "X / Y" may also include the meaning of "X and / or Y" in any sentence, paragraph, (sub)item, point, action, behavior, term, alternative, aspect, example, implementation, or claim described in this application.

[0118] The following terms are defined, but not necessarily limited to, the meanings provided below, as long as they indicate an open inclusion or membership relationship in the foregoing meaning and its equivalents.

[0119] In some implementations, SDT can be UL data transmission performed by a UE in the RRC_INACTIVE state. In some such implementations, the packet size (or data volume) of the UL data can be below a specified threshold. In some implementations, the UL data of the SDT can be transmitted during the SDT process. In some implementations, the UL data of the SDT can be transmitted via Msg3 (e.g., based on a 4-step RA), via MsgA (e.g., based on a 2-step RA), and / or via CG resources (e.g., CG type 1). In some implementations, when the UE is in the RRC_INACTIVE state, the UL data of the SDT can be transmitted based on dynamic scheduling and / or semi-persistent scheduling.

[0120] In some implementations, NW can be a network node, TRP, cell (e.g., SpCell, PCell, PSCell and / or SCell), eNB, gNB and / or base station.

[0121] The terms “initiate,” “trigger,” and / or “start” may be used interchangeably in some embodiments of this application. The terms “terminate,” “stop,” “release,” “pause,” “discard,” “end,” “complete,” “abort,” and / or “cancel” may be used interchangeably in some embodiments of this application. The terms “cycle,” “process,” and / or “duration” may be used interchangeably in some embodiments of this application. The terms “resource” and / or “occasion” may be used interchangeably in some embodiments of this application. Additionally, the terms “in progress,” “running,” and / or “pending” may be used interchangeably in some embodiments of this application.

[0122] Furthermore, for purposes of explanation and non-limitation, specific details such as functional entities, technologies, protocols, and standards are elaborated to provide an understanding of the described technologies. In other examples, detailed descriptions of well-known methods, technologies, systems, architectures, etc., are omitted to avoid unnecessary detail that could obscure the description.

[0123] Those skilled in the art will readily recognize that any one or more network functions or algorithms described in this application can be implemented by hardware, software, or a combination of software and hardware. The described functions may correspond to modules, which may be software, hardware, firmware, or any combination thereof. Software implementations may include computer-executable instructions stored on a computer-readable medium such as memory or other types of storage devices. For example, one or more microprocessors or general-purpose computers with communication processing capabilities may be programmed with corresponding executable instructions to perform the described one or more network functions or algorithms. The microprocessor or general-purpose computer may be constructed from application-specific integrated circuits (ASICs), programmable logic arrays, and / or using one or more digital signal processors (DSPs). While the several exemplary embodiments described in this specification are for software installed and executed on computer hardware, alternative exemplary embodiments implemented as firmware or hardware or a combination of hardware and software are also within the scope of this application.

[0124] Computer-readable media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD-ROM), magnetic tape, magnetic tape, disk storage devices, or any other equivalent medium capable of storing computer-readable instructions.

[0125] Wireless communication network architectures (e.g., Long Term Evolution (LTE) systems, LTE-A systems, LTE-Pro systems, or 5G NR Radio Access Networks (RANs)) typically include at least one base station, at least one UE, and one or more optional network components that provide connectivity to the network. The UE communicates with the network (e.g., Core Network (CN), Evolved Packet Core (EPC) network, Evolved Universal Terrestrial Radio Access network (E-UTRAN), 5G Core (5GC), or the Internet) through the RAN established by one or more base stations.

[0126] It should be noted that in this application, the UE may include, but is not limited to, a mobile station, mobile terminal, device, or user communication radio terminal. For example, the UE may be a portable wireless device, including but not limited to mobile phones, tablet computers, wearable devices, sensors, vehicles, or personal digital assistants (PDAs) with wireless communication capabilities. In some embodiments, the UE may be referred to as a PHY / MAC / RLC / PDCP / SDAP / RRC entity. Similarly, a PHY / MAC / RLC / PDCP / SDAP / RRC entity may be referred to as a UE. The UE may be configured to receive and transmit signals to one or more cells in a radio access network via an air interface.

[0127] The base station is configured to provide communication services according to at least one of the following Radio Access Technologies (RATs): Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile Communications (GSM, commonly referred to as 2G), GSM Evolution with Enhanced Datarates for GSM Evolution (EDGE) Radio Access Network (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS, commonly referred to as 3G) based on Wideband Code Division Multiple Access (W-CDMA), High-Speed ​​Packet Access (HSPA), LTE, LTE-A, Evolved Long-Term Evolution (eLTE, e.g., LTE linked to 5GC), NR (commonly referred to as 5G), and / or LTE-A Pro. However, the scope of this application should not be limited to the aforementioned entities / protocols.

[0128] Base stations may include, but are not limited to, node Bs (NBs) in UMTS, evolved node Bs (eNBs) in LTE or LTE-A, radio network controllers (RNCs) in UMTS, base station controllers (BSCs) in GSM / GSM Enhanced Data Rates for GSM Evolution (EDGE) radio access networks (GERAN), next-generation eNBs (ng-eNBs) in evolved global terrestrial radio access (E-UTRA) BSs connected to 5GC, next-generation node Bs (gNBs) in 5G access networks (5G-AN), and any other devices capable of controlling radio communications and managing radio resources within the cell. A BS can connect to the network via a radio interface to serve one or more UEs.

[0129] A base station (BS) can be operable to provide radio coverage to a specific geographic area using multiple cells included in the RAN. The BS can support cell operation. Each cell can be operable to provide service to at least one UE within its radio coverage area. Specifically, each cell (typically referred to as the serving cell) can provide service to one or more UEs within its radio coverage area (e.g., each cell schedules downlink (DL) resources and optional uplink (UL) resources to at least one UE within its radio coverage area for DL ​​and optional UL packet transmissions). The BS can communicate with one or more UEs in a radio communication system through multiple cells.

[0130] Cells can be allocated sidelink (SL) resources to support Proximity Service (ProSe) or Vehicle to Everything (V2X) services. Each cell can have coverage areas overlapping with other cells. In the case of Multi-RAT Dual Connectivity (MR-DC), the master cell of the Master Cell Group (MCG) or Secondary Cell Group (SCG) can be referred to as a SpCell.

[0131] A cell or serving cell can include a primary cell (Pcell), a primary SCG cell (PSCell), or a secondary cell (Scell). A serving cell can be active or inactive. For dual-connectivity operations, the term "Special Cell" (SpCell) refers to a Pcell in the Master Cell Group (MCG) or a PSCell in the Secondary Cell Group (SCG), depending on whether the MAC entity is associated with the MCG or SCG respectively. Otherwise, "Special Cell" refers to a Pcell.

[0132] A Pcell can be a SpCell in an MCG. A PSCell can be a SpCell in an SCG. An MCG can be a set of serving cells associated with a Master Node (MN), including SpCells and one or more optional Scells. An SCG can be a set of serving cells associated with a Secondary Node (SN), including SpCells and one or more optional Scells.

[0133] As mentioned above, the NR frame structure supports flexible configuration to adapt to various next-generation (e.g., 5G) communication requirements, such as enhanced mobile broadband (eMBB), massive machine-type communication (mMTC), ultra-reliable and low-latency communication (URLLC), while simultaneously meeting the requirements of high reliability, high data rate, and low latency. As agreed in 3GPP, orthogonal frequency division multiplexing (OFDM) technology can be used as the baseline for NR waveforms. An expandable set of OFDM parameters, such as adaptive subcarrier spacing, channel bandwidth, and cyclic prefix (CP), can also be used. Additionally, two NR coding schemes are considered: (1) low-density parity-check (LDPC) codes and (2) polar codes. The adaptability of the coding scheme can be configured based on channel conditions and / or service applications.

[0134] Furthermore, it is also considered that the transmission time interval (TX) of a single NR frame should include at least downlink (DL) transmission data, guard interval, and uplink (UL) transmission data. The individual components of the DL transmission data, guard interval, and UL transmission data should also be configurable, for example, based on NR network dynamics. Additionally, sidelink resources can also be provided in the NR frame to support ProSe service, (E-UTRA / NR) sidelink service, or (E-UTRA / NR) V2X service.

[0135] Furthermore, the terms "system" and "network" are used interchangeably in this document. The term "and / or" is used only to describe the relationship between related objects and indicates that three relationships can exist. For example, A and / or B can indicate that A exists alone, A and B exist simultaneously, or B exists alone. Additionally, the character " / " in this document generally indicates that the former and the latter related objects are in an "or" relationship.

[0136] As mentioned above, next-generation (e.g., 5G NR) wireless networks will support more capacity, data, and services. UEs configured with multiple connectivity can connect to a master node (MN) acting as the anchor and one or more secondary nodes (SNs) for data transmission. Each of these nodes can be formed by a cell group comprising one or more cells. For example, a master cell group (MCG) can be formed by an MN, and a secondary cell group (SCG) can be formed by an SN. In other words, for a UE configured with dual connectivity (DC), an MCG is a group of one or more serving cells, including PCells and zero or more secondary cells. Conversely, an SCG is a group of one or more serving cells, including PSCells and zero or more secondary cells.

[0137] As described above, the Primary Cell (PCell) can be an MCG cell operating on the primary frequency, where the UE performs the initial connection establishment procedure or initiates a connection re-establishment procedure. In MR-DC mode, the PCell can belong to the MN. The Primary SCG Cell (PSCell) can be an SCG cell where the UE performs random access (e.g., when performing reconfiguration using a synchronization procedure). In MR-DC, the PSCell can belong to the SN. A Special Cell (SpCell) can refer to either the PCell of an MCG or the PSCell of an SCG, depending on whether the MAC entity is associated with an MCG or an SCG. Otherwise, the term Special Cell can refer to the PCell. Special Cells can support Physical Uplink Control Channel (PUCCH) transmission and contention-based Random Access (CBRA) and can always be active. Additionally, for a UE in the RRC_CONNECTED state without a configured CA / DC, it can communicate only with the serving cell (SCell) that is the primary cell. Conversely, for a UE in the RRC_CONNECTED state configured using CA / DC, a set of serving cells, including the special cell and all secondary cells, can communicate with the UE.

[0138] As described above, this application may improve upon traditional protocols and enable user equipment in the RRC_INACTIVE state to perform small data transmissions. This application relates to the scheduling of monitoring (e.g., when and where) the PDCCH in the SDT to receive (e.g., via DCI) data transmissions from / to the network.

[0139] Typically, a UE can monitor the Common Search Space (CSS) set for the PDCCH. In such an implementation, due to the use of the Common Search Space (SS), data transmission by the UE may conflict with data transmission by other UEs, and therefore, network congestion may be unavoidable.

[0140] To avoid such conflicts and subsequent network congestion, the network can configure a SDT-specific set of CSS for the UE. This CSS can be used only by the UE performing the SDT procedure. However, conventional (or regular) CSS can be used by all UEs (which may lead to network congestion and / or conflicts).

[0141] In some implementations, certain assumptions can be made regarding SDT. In some implementations, SDT can be supported as the basis for RA-based SDT and CG-based SDT schemes. The stored "configuration" in the UE can be used for RLC bearer configuration. A UE in the RRC_INACTIVE state can apply 2-step RACH or 4-step RACH to RA-based SDT. In some implementations, uplink small data can be transmitted in the MSGA of 2-step RACH and / or the MSG3 of 4-step RACH. SDT can be configured by the network based on each data DRB. In some implementations, the UE can use a data volume threshold to determine whether to perform (or select) an SDT (or non-SDT) procedure. In some implementations, the UE can support UL / DL transmission after UL SDT without transitioning to the RRC_CONNECTED state (e.g., switching from the RRC_INACTIVE state to the RRC_CONNECTED state). In some implementations, when the UE is in the RRC_INACTIVE state, multiple UL and DL packets can be sent as part of the same SDT procedure, and on dedicated authorization, there is no need to transition to the RRC_CONNECTED state (e.g., the UE can maintain its RRC_INACTIVE state during the SDT procedure).

[0142] In some implementations, further assumptions can be made about SDT. When a UE receives an RRC release message with a "Suspend" configuration, one or more of the following may occur: the MAC entity (of the UE) can be reset, and the default MAC cell group configuration can be released; the RLC entity (of the UE) for SRB1 can be re-established; and the SRB and / or DRB can be suspended (e.g., except for SRB0).

[0143] In some implementations, further assumptions can be made regarding SDT. For example, when initiating an SDT procedure (e.g., for the first small data transmission), the UE can at least re-establish the PDCP entity (e.g., for SDT) and restore the DRB (e.g., for SDT), such as SRB1. Depending on the size of the first UL message, the first UL message (e.g., MSG3 for a 4-step RACH, MSGA for a 2-step RACH, and CG transmission for CG) can contain at least one of the following: CCCH, DRB data from network configuration for one or more DRBs for SDT, MAC Ces (e.g., BSR), and padding bits. In some implementations, for the CCCH message, LCP can be used to determine the content priority.

[0144] In some implementations, further assumptions can be made regarding the SDT. For example, the CCCH message may include a ResumeMAC-I generated using a stored security key for RRC integrity protection. A new key can be generated using the stored security context, and the NCC value can be received in a previous RRC release message. The new key can be used to generate data in the DRBs configured for the SDT. In some implementations, for CG-based SDTs, the configuration of CG resources for uplink small data transmission can be included in the RRC release message. In some implementations, for CG-based SDTs, a new TA timer for TA maintenance can be introduced for CG-based small data transmission in the RRC_INACTIVE state. The TA timer can be configured together with the CG configuration in the RRC release message. In some implementations, for CG-based SDTs, the CG resource configuration for the UE's SDT can be valid only within the same serving cell. In some implementations, for CG-based SDTs, a UE can use CG-based small data transmission if at least one of the following criteria is met: user data is less than a data volume threshold, CG resources are configured and valid, and the UE has a valid TA. In some implementations, for CG-based SDTs, an association between CG resources and SSBs may be required.

[0145] In some implementations, further assumptions can be made regarding the SDT. For CG-based SDT, an SS-RSRP threshold for SSB selection can be configured. The UE can select one SSB from the SSBs, and the selected SSB has an SS-RSRP higher than the threshold. The UE can then select an associated CG resource for UL data transmission. In some implementations, for CG-based SDT, CG-SDT resources can be configured and provided to the UE in the RRC_CONNECTED state (e.g., via an RRC release message). In some implementations, for CG-based SDT, CG-PUSCH resources can be configured separately for NUL and / or SUL. In some implementations, for CG-based SDT, an RRC release message can be used to reconfigure or release CG-SDT resources when the UE is in the RRC_INACTIVE state. In some implementations, for CG-based SDT, subsequent data transmission can use CG or DG resources, for example, via dynamic authorization addressing the UE's C-RNTI. The C-RNTI can be the same as a previously stored C-RNTI in the UE or can be explicitly configured by the network. In some implementations, for CG-based SDT, the timing alignment timer (TAT) can be started upon receiving a TAT configuration from the gNB, for example via an RRC release message, and can be started or restarted upon receiving a TA command. In some implementations, for CG-based SDT, the UE may release CG resources when the TAT expires (e.g., when the UE is in the RRC_INACTIVE state).

[0146] In some implementations, further assumptions can be made regarding the SDT. For example, for RA-SDT, the network can be configured with up to two preamble groups (e.g., corresponding to two different payload sizes for MSGA / MSG3). In some implementations, if a RACH procedure is initiated for an SDT (e.g., RA-SDT initiation), the UE can first perform a RACH type selection as specified in the MAC (e.g., in Rel-16), and then the UE determines whether a threshold is specified for the SDT. In some implementations, for RA-based SDT, the UE can monitor the C-RNTI after successful contention resolution. In some implementations, for RA-based SDT, the RACH resources (e.g., the combination of RACH timing (RO) + preamble) between the SDT and non-SDT (e.g., in the RRC connection recovery message) can be different. In some implementations, if the Ros of the SDT and non-SDT are different, preamble partitioning between the SDT and non-SDT may not be necessary. In some implementations, if the Ros of the SDT and non-SDT are the same, preamble partitioning between the SDT and non-SDT may be necessary. In some implementations, for RA-based SDT, up to two preamble groups corresponding to two different payload sizes (MSGA / MSG3) can be configured by the network. In some implementations, for RA-based SDT, an RRC release message can be sent at the end to terminate the SDT process (e.g., from an RRC perspective). The RRC release message sent at the end of the SDT may contain CG resources. An RSRP threshold can be selected between SDT and non-SDT processes (e.g., during RRC connection recovery).

[0147] In some implementations, further assumptions can be made regarding SDT. For example, in SDT, the UE can perform UL carrier selection (e.g., UL selection and SUL selection). In some implementations, if CG-SDT resources are configured on the selected UL carrier and are valid, CG-based SDT can be selected for execution. Otherwise, if two-step RA resources (e.g., for SDT) are configured on the UL carrier and the conditions for selecting two-step RA (e.g., for SDT) are met, two-step RA (e.g., for SDT) can be selected. Otherwise, if four-step RA resources (e.g., for SDT) are configured on the UL carrier and the conditions for selecting four-step RA (e.g., for SDT) are met, four-step RA can be selected. Furthermore, in this case, the UE may not perform the SDT procedure (e.g., the UE can perform the RRC connection recovery procedure). In some implementations, if two-step RA (e.g., for SDT) and four-step RA resources (e.g., for SDT) are configured on the UL carrier, RA type selection (e.g., two-step RA type selection and four-step RA type selection) can be performed based on the RSRP threshold.

[0148] In some embodiments of this application, the purpose of the RRC connection recovery process may be to restore a suspended RRC connection, including restoring SRB(s)B and DRB(s) or performing an RNA update. In some embodiments, the UE may initiate the RRC connection recovery process when an upper layer or AS (e.g., in response to a RAN paging, or when an RNA update is triggered while the UE is in the RRC_INACTIVE state) requests the restoration of a suspended RRC. The suspension of the RRC connection may be initiated by the network. In some embodiments, when the RRC connection is suspended, the UE may store the UE inactive AS context and any configuration received from the network, and then transition to the RRC_INACTIVE state. In some embodiments, the RRC messages used to suspend the RRC connection may be fully protected and encrypted.

[0149] In some implementations, when a UE needs to transition from the RRC_INACTIVE state to the RRC_CONNECTED state, the upper layer can initiate a resumption of the suspended RRC connection, or the RRC layer can perform an RNA update, or the RAN can initiate a paging from the NG-RAN. When the RRC connection is restored, the network can configure the UE according to the stored UE inactive AS context and any RRC configuration received from the network, following the RRC connection restoration process. In some implementations, the RRC connection restoration process can reactivate AS security and re-establish SRB(s) and DRB(s).

[0150] In some implementations, in response to a request to resume a suspended RRC connection, the network may perform one of the following operations: the network may resume the suspended RRC connection and send the UE to the RRC_CONNECTED state; the network may reject the request to resume the suspended RRC connection and send the UE to the RRC_INACTIVE state (e.g., using a wait timer); the network may directly re-suspend the RRC connection and send the UE to the RRC_INACTIVE state; the network may directly release the RRC connection and send the UE to the RRC_IDLE state; or the network may instruct the UE to initiate a NAS-level recovery (e.g., in this case, the network may send an RRC establishment message to the UE). Further details on performing the RRC connection recovery procedure in response to receiving a recovery request can be found in 3GPP TS 38.331V16.3.1.

[0151] In some embodiments of this application, two types of RA procedures can be supported, for example, a four-step RA type with MSG1 and a two-step RA type with MSGA. In some embodiments, both types of RA procedures can support contention-based random access (CBRA) and contention-free random access (CFRA) procedures. The UE can select the RA type when the RA procedure is initiated based on network configuration. In some embodiments, when no CFRA resources are configured, the UE can use an RSRP threshold to select between the two-step and four-step RA types. In some embodiments, when CFRA resources are configured for the four-step RA type, the UE can perform the RA procedure using the four-step RA type. In some embodiments, when CFRA resources are configured for the two-step RA type, the UE can perform the RA procedure using the two-step RA type. In some embodiments, the network may not configure CFRA resources for both four-step and two-step RA types simultaneously for the Bandwidth Partial (BWP). In some embodiments, CFRA with the two-step RA type can only support handover procedures.

[0152] In some implementations, the MSG1 of a four-step RA type may include a preamble on the PRACH. After the MSG1 transmission, the UE can monitor responses from the network within a configured window. For CFRA, the network can allocate a dedicated preamble for the MSG1 transmission, and the UE can terminate the RA procedure upon receiving an RA response from the network. For CBRA, upon receiving an RA response, the UE can use the UL grant scheduled in the response to send MSG3 and monitor contention resolution. In some implementations, if contention resolution fails after the MSG3 transmission or retransmission, the UE can return to the MSG1 transmission.

[0153] In some implementations, a two-step RA type MSGA may include a preamble on the PRACH and a payload on the PUSCH. After the MSGA transmission, the UE can monitor the response from the network within a configured window. For CFRA, dedicated preamble and PUSCH resources can be configured for the MSGA transmission, and the UE can terminate the RA procedure upon receiving a network response. For CBRA, the UE can terminate the RA procedure if contention resolution is successful upon receiving a network response. Simultaneously, if a fallback indication is received in the MSGB, the UE can use the UL grant scheduled in the fallback indication to perform an MSG3 transmission and monitor contention resolution. In some implementations, if contention resolution is unsuccessful after an MSG3 transmission or retransmission, the UE can fall back to the MSGA transmission. In some implementations, if a two-step RA type RA procedure is not completed after a certain number of MSGA transmissions, the UE can be configured to switch to CBRA with a four-step RA type.

[0154] In some embodiments of this application, regarding configured grants (CGs), the gNB(s) can allocate uplink resources already used for the initial HARQ transmission to the UE. Two types of configured uplink grants are defined, such as type 1 and type 2. In some embodiments, regarding type 1 (e.g., CG type 1), the RRC directly provides the configured uplink grant (including the period). Regarding type 2 (e.g., CG type 2), the RRC defines the period of the configured uplink grant, and the PDCCH paging to the CS-RNTI can transmit signals to activate or deactivate the configured uplink grant. For example, the PDCCH addressing to the CS-RNTI indicates that the uplink grant can be implicitly reused according to the period defined by the RRC until it is deactivated.

[0155] In some implementations, when configuring CG type 1, NW and / or RRC can be configured with parameters such as CS-RNTI for retransmission, the period for configuring grant type 1, the offset of the resource relative to SFN=0 in the time domain (e.g., timeDomainOffset), the configuration of uplink grants including startSymbolAndLength (i.e., SLIV in 3GPP TS 38.214) in the time domain (e.g., timeDomainAllocation), and the number of HARQ processes to be granted (e.g., nrofHARQ-Processes).

[0156] In some implementations, when configuring CG type 1 for a serving cell via an upper layer, the UE (e.g., the UE's MAC entity) stores the uplink grant provided by the upper layer as a configured uplink grant (for the indicated serving cell SC) and / or initializes or reinitializes the configured uplink grant according to timeDomainOffset and S (e.g., derived from SLIV according to 3GPP TS 38.214) to start a symbol and reappears periodically.

[0157] Figure 1 This is a schematic diagram illustrating a process 100 performed by a UE to monitor the PDCCH during SDT process 108, according to an embodiment of this application. It should be noted that although actions in this and other diagrams are shown as separate actions represented as independent blocks, these individually depicted actions should not be construed as necessarily dependent on a specific order. The order in which actions are performed is not intended to be construed as limiting, and any number of the disclosed block diagrams can be combined in any order to implement the method or alternative methods. Furthermore, in this embodiment, one or more actions may be omitted.

[0158] In some implementations, when the UE begins procedure 100, the UE may be in the RRC_INACTIVE state. The UE may be configured with SDT configuration. In some implementations, the configuration for SDT can be configured via an RRC release message (e.g., using a pause configuration). In some implementations, the configuration for SDT may include RACH configuration, CG configuration, SRB / DRB configuration for SDT, etc. In some implementations, after starting procedure 100, the UE may receive UL data in action 104 for transmission (e.g., to a base station). In some implementations, the UL data may be associated with a specific DRB / SRB / LCH.

[0159] In some implementations, after receiving UL data, the UE can determine at action 106 whether to initiate an SDT procedure 108 or a non-SDT procedure, such as an RRC connection restoration procedure 120 (e.g., initiating a transmission associated with an RRC ResumeRequest message). In some implementations, if the UE determines to perform a non-SDT procedure at action 106, the UE can perform the RRC connection restoration procedure at action 120. Procedure 100 can then be terminated.

[0160] In some implementations, the UE may determine whether to initiate or trigger SDT procedure 108 or initiate RRC connection recovery procedure 120 based on one or more criteria (e.g., DRB / SRB, data volume, and / or RSRP, etc.). In some implementations, if one or more criteria for initiating an SDT procedure are not met, or if a non-SDT procedure is initiated, the UE may initiate RRC connection recovery procedure 120 (e.g., the UE may initiate data transmission related to the RRC Resume Request message).

[0161] As described above, after receiving UL data, the UE can determine to execute SDT procedure 108. In some embodiments, the UE can determine to initiate SDT procedure 108 when or after at least one of the LCH / DRB / SRB configured for SDT has data to be processed (e.g., when data is only available for SDT-enabled LCHs / DRB / SRB transmission). When the UE initiates SDT procedure 108, the LCH / DRB / SRB configured for SDT can be restored or re-established. In some embodiments, if the amount of data used for transmission (e.g., for SDT) is lower than a threshold configured for SDT, the UE can determine to initiate SDT procedure 108 at action 106. The data amount may include only the amount of data configured for SDT for LCH / DRB / SRB. In some embodiments, if the RSRP is greater than the RSRP threshold configured for SDT, the UE can determine to initiate SDT procedure 108.

[0162] In some implementations, if the UE determines to initiate SDT procedure 108 at action 106, the UE can also perform UL carrier selection (e.g., selecting UL or SUL) at action 110. In some implementations, if a supplementary uplink (SUL) is configured in the cell, the UL carrier can be selected based on an RSRP threshold. In some implementations, after UL carrier selection in action 110, the UE can perform SDT procedure 108 on the selected UL carrier (e.g., UL or SUL).

[0163] In some implementations, after performing SDT procedure 108 on the selected UL carrier, the UE may determine in action 112 whether to configure a valid CG to the UE and / or whether the configured CG resources are valid based on one or more criteria (e.g., during SDT procedure 108).

[0164] In some implementations, in action 112, one criterion for determining the existence of a valid CG is based on whether the associated beam / SSB is valid. In some implementations, the validity of the associated beam / SSB can be determined based on an RSRP threshold. The RSRP threshold can be configured in the RRC release message and / or CG configuration. The RSRP threshold can be indicated by IE cg-SDT-RSRP-ThresholdSSB. In some implementations, if at least one beam / SSB has an RSRP higher than the RSRP threshold, the UE can determine that the CG resource / configuration is valid. In some implementations, if no beam has an RSRP higher than the RSRP threshold, the UE can determine that the CG resource / configuration is invalid.

[0165] In some implementations, another criterion for determining whether a CG is valid may be based on whether timing advance / timing alignment (TA) is valid. For example, if TA is valid, the UE may determine that the CG resource / configuration is valid. In some implementations, if TA is invalid, the UE may consider the CG resource / configuration invalid. In some implementations, the validity of TA may be determined based on a TA timer. For example, if the TA timer is running, the UE may consider TA valid. Conversely, if the TA timer is not running, the UE may consider TA invalid. In some implementations, the TA timer (e.g., timer parameters) may be configured in the RRC release message and / or the CG configuration. In some implementations, the validity of TA may be determined based on the amount of RSRP change and / or a configured threshold (e.g., cg-SDT-RSRP-ChangeThreshold). For example, if the RSRP change is higher than a preset threshold, the UE may consider TA invalid. In some implementations, the threshold (e.g., for RSRP changes) may be configured in the RRC release message and / or the CG configuration. For example, if the RSRP has not increased / decreased by more than the threshold compared to the downlink path loss reference RSRP value at the time of the MAC entity's last reset, the UE may consider TA valid.

[0166] In some implementations, another criterion for determining whether a CG is valid may be whether the CG resource configuration is valid. In some implementations, a CG resource configuration may be considered valid when it is initialized or reinitialized. In some implementations, a CG resource configuration may be considered invalid when it is released or paused. In some implementations, the CG resource configuration may be configured in an RRC release message.

[0167] In some implementations, another criterion for determining whether a CG is valid may be whether the data is available for transmission, for example, only for DRBs / SRBs / LCHs with SDT enabled. In some implementations, the UE may configure one or more DRBs / SRBs / LCHs specifically for SDT.

[0168] In some implementations, another criterion for determining whether a CG is valid may be based on whether the RSRP is greater than the RSRP threshold configured for the SDT. In some implementations, the RSRP threshold may be configured in the RRC release message and / or the CG configuration.

[0169] In some implementations, another criterion for determining whether a CG is valid may be based on whether the amount of data used for transmission is below a configuration threshold for SDT. In some implementations, the configuration threshold may be configured in the RRC release message and / or the CG configuration.

[0170] In some implementations, another criterion for determining whether a CG is valid may be based on indication information received from the NW (e.g., explicit or implicit indication). In some implementations, this indication information may indicate whether the CG (e.g., associated with a beam) is valid or invalid. In some implementations, the indication information may indicate whether the beam associated with the CG is valid or invalid.

[0171] In some implementations, another criterion for determining whether a CG is valid may be based on whether a timer (e.g., T319 or a timer used for SDT) is running. In some implementations, the timer may be configured in the RRC release message and / or the CG configuration. In some implementations, the UE may determine whether the CG resource / configuration is valid if the timer is running. In some implementations, the UE may determine that the CG resource / configuration is invalid if the timer is not running or the timer expires. In some implementations, the timer can detect SDT failure. In some implementations, when the UE is in the RRC_INACTIVE state, the timer may start or restart when transmitting UL data.

[0172] In some implementations, the timer can be started or restarted when small data is transmitted. In some implementations, the timer can be started or restarted when an RRC recovery request is transmitted. In some implementations, the timer may stop counting upon receiving RRCResume, RRCSetup, RRCRelease, RRCRelease with a suspendConfig or RRCReject message, cell re-selection, and termination of upper-layer connection establishment. In some implementations, when the timer expires, the UE may decide whether to transition to the RRC_IDLE state (e.g., with a specific RRC recovery reason).

[0173] In some implementations, two types of SDT procedures 108 can be performed based on whether the CG is valid or invalid (in action 112): an RA-based SDT procedure and a CG-based SDT procedure. In some implementations, the UE can transmit small data during the SDT procedure 108 via MSG3, MSGA, CG resources, and / or PUSCH resources.

[0174] In some implementations, if the UE determines in action 112 that the CG is invalid, for example, when none of the above criteria for determining the validity of the CG are met, the UE may perform a RA-based SDT procedure in action 114. In some implementations, the UE may perform a transmission of the RA preamble, for example, via the preamble / RA resource / PRACH resource configured for the SDT. In some implementations, the UE may perform UL transmission via Msg3 / MsgA (e.g., for small data).

[0175] In some implementations, if the UE determines that the CG is valid in action 112, for example, when one or more of the above-described criteria for determining the validity of the CG are met, the UE may perform a CG-based SDT procedure in action 116. In some implementations, the UE may perform UL transmissions (e.g., for small data) using CG resources.

[0176] In some implementations, the SDT procedure 108 may end, terminate, stop, or complete when the UE performs a RA-based SDT procedure or a CG-based SDT procedure. In some implementations, the end / termination / stop / completion of the SDT procedure 108 may be indicated by an indication received from the NW (e.g., receiving an RRC release message), a timer (e.g., T319, SDT timer, etc.), a counter (e.g., a retransmission counter), and / or the occurrence of a specific event (e.g., when the UE performs cell selection or cell reselection). Figure 2This is a schematic diagram 200 illustrating a RA-based SDT process according to an example embodiment of this application. It is worth noting that although actions are represented as separate blocks as individual actions in this and other diagrams, these individually described actions should not be interpreted as necessarily depending on the order. The order in which actions are performed is not intended to be limiting, and any number of the disclosed blocks can be combined in any order to implement the method or alternative methods. Furthermore, one or more actions may be omitted in some embodiments of this application.

[0177] In some implementations, when the UE is in the RRC_INACTIVE state and has initiated an SDT procedure for transmitting UL data and / or has already initiated an RA-based SDT procedure, it may initiate an RA-based SDT procedure to transmit UL data (e.g., if the CG is deemed invalid). In some implementations, the UE may select a four-step RA type or a two-step RA type procedure. In some implementations, the preamble or PRACH resource used for the RA-based SDT procedure (e.g., an RA preamble / PRACH resource with small data indication) may differ from that of a normal RA procedure (e.g., an RA preamble without any small data indication). In action 202, when the UE is in the RRC_INACTIVE state, it may select a preamble or PRACH resource using an RA-based SDT procedure to send the preamble to the NW.

[0178] In some implementations, after sending the RA preamble to the NW, in action 204, the UE may send an RRC message, MACCE(s), and / or UL data to the network NW via MSG3 (e.g., when a four-step RA type is selected) or via MSGA (e.g., when a two-step RA type is selected). In some implementations, the RRC message may be an RRCResumeRequest message. In some implementations, in addition to the RRC message, MAC CE (e.g., BSR) and UL data (e.g., data related to the DRB of the SDT) may be included in MSG3 or MSGA.

[0179] In some implementations, once MSG3 / MSGA is sent, the UE may monitor MSG4 or MSGB, for example, a temporary C-RNTI, RA-RNTI, or MSGB-RNTI, where MSG4 or MSGB may carry a contention resolution ID. In some implementations, the NW may send an RRC message in MSG4 / MSGB to the UE in action 206. In some implementations, the RRC message may be an RRCRelease message (e.g., with a suspendConfig IE) or an RRCResume message. In some implementations, if the UE receives an RRCRelease message (e.g., with a suspendConfig IE), the UE may remain in the RRC_INACTIVE state, or if the UE receives an RRCResume message, the UE may enter the RRC_CONNECTED state.

[0180] In some implementations, once the RA procedure of the SDT is successfully completed and / or until the RA-based SDT is terminated / completed, the UE can monitor a specific RNTI (e.g., C-RNTI) to enable subsequent data transmission in action 208. In some implementations, subsequent data transmission may include the transmission of multiple UL and / or DL ​​packets as part of the SDT procedure, without transitioning to the RRC_CONNECTED state (e.g., while the UE is still in the RRC_INACTIVE state). In some implementations, the UE can monitor the PDCCH via a specific RNTI (e.g., C-RNTI) to receive dynamic scheduling of UL and / or new DL transmissions and / or corresponding retransmissions.

[0181] In some implementations, after monitoring any possible subsequent data transmissions, in action 210, the network NW may send an RRC release message (e.g., carrying a suspendconfig IE) to keep the UE in the RRC_INACTIVE state or move the UE to the RRC_IDLE state. In other implementations, in action 210, the NW may send an RRC recovery message to move the UE to the RRC_CONNECTED state. In some implementations, upon receiving an RRCRelease message (e.g., carrying a suspendConfig IE), the UE may terminate the SDT procedure based on the RRCRelease message, and / or stop monitoring C-RNTI, and / or remain in the RRC_INACTIVE state.

[0182] Figure 3A schematic diagram 300 illustrates a CG-based SDT process according to one of the exemplary embodiments of this application. It is worth noting that although actions are represented as separate blocks as individual actions in this and other diagrams, these individually described actions should not be interpreted as necessarily depending on the order. The order in which actions are performed is not intended to be limiting, and any number of the disclosed blocks can be combined in any order to implement the method or alternative methods. Furthermore, one or more actions may be omitted in some embodiments of this application.

[0183] In some implementations, when the UE is in the RRC_CONNECTED state and / or RRC_INACTIVE state, the UE can initiate a CG-based SDT procedure. In some implementations, a UE in the RRC_CONNECTED state may, in action 302, send a CG configuration request to the network NW to indicate UE preferences for small data transmission and / or for CG configuration in the RRC_INACTIVE state.

[0184] In some implementations, upon receiving a CG configuration request, in action 304, the network NW may move the UE to the RRC_INACTIVE state by sending an RRCRelease message (e.g., including a suspendconfig IE). In some implementations, the RRCRelease message may include at least one CG configuration to configure CG resources for the UE. In some implementations, the CG configuration may include, but is not limited to, the following information: CG period, TBS, the number of implicitly released CG resources, retransmission timers, the number of HARQ processes reserved for CG in the SDT, the RSRP threshold selected for the SSB, the association between the SSB and CG resources, and TA-related parameters (such as TA timers).

[0185] In some implementations, after receiving the RRCRelease message and transitioning to the RRC_INACTIVE state, in action 306, the UE can perform an SDT procedure via CG resources according to the CG configuration (e.g., configured in action 304). For example, the UE may transmit UL data (e.g., small data) via CG resources (e.g., during the SDT procedure).

[0186] In some implementations, after the initial transmission of the SDT procedure and / or the CG-based SDT procedure, and / or until the CG-based SDT procedure terminates or completes, the UE and network NW may perform subsequent data transmissions in action 308. In some implementations, subsequent data transmissions may be the transmission of multiple UL and / or DL ​​packets as part of the SDT mechanism and do not transition to the RRC_CONNECTED state (e.g., the UE remains in the RRC_INACTIVE state). In some implementations, the UE can monitor the PDCCH via specific RNTIs (e.g., C-RNTI, CS-RNTI, and / or specific RNTIs) to receive dynamic scheduling of new UL and / or DL ​​transmissions and / or corresponding retransmissions. In some implementations, the UE can monitor the PDCCH via UE-specific RNTIs (e.g., C-RNTI, CS-RNTI, and / or specific RNTIs) to receive dynamic scheduling of CG retransmissions. In some implementations, the UE can perform subsequent data transmissions via CG resources according to the CG configuration (e.g., configured in action 304).

[0187] In some implementations, after monitoring any possible subsequent data transmissions, the NW may send an RRC Resume message (e.g., carrying a suspendconfig IE) to keep the UE in the RRC_INACTIVE state or move the UE to the RRC_IDLE state. In other implementations, the NW may send an RRC Recovery message in action 310 to move the UE to the RRC_CONNECTED state. In some implementations, upon receiving an RRC Resume message (e.g., carrying a suspendconfig IE), the UE may terminate the SDT procedure based on the RRC Resume message, and / or stop monitoring C-RNTI, and / or remain in the RRC_INACTIVE state.

[0188] Figure 4A and Figure 4B This diagram illustrates an SDT cycle associated with an SDT process according to one of the exemplary embodiments of this application. The duration of the SDT transmission cycle (e.g., in some embodiments, it may also be referred to as a subsequent transmission cycle) can be achieved in the following ways. In some embodiments, the SDT / subsequent transmission cycle can be a time period within the SDT process (e.g., Figure 4A RA-based SDT process 400A and / or Figure 4BThe SDT procedure based on CG (400B) is described. In some implementations, the SDT / subsequent transmission period may be the time period during which the SDT procedure is in progress. In some implementations, the SDT / subsequent transmission period may begin when or after the UE initiates the SDT procedure. In some implementations, the RA procedure may be... Figure 4A The RA-based SDT procedure 400A. In some implementations, the RA procedure may be initiated for the SDT.

[0189] In some implementations, the SDT transmission period 402A in the RA-based SDT procedure 400A may begin after the UE considers the contention resolution of the RA procedure to be successful and / or after the UE considers the RA procedure to be successfully completed (e.g., the UE sends a UL message 404A, such as MSG3 or MSGA, to the NW and receives a response 406A, such as MSG4 or MSGB, from the NW).

[0190] In some implementations, the SDT transfer period may be the time period experienced during configuring or initiating a CG configuration (e.g., before the CG configuration is released). In some implementations, the SDT transfer period may begin after configuring / initializing / (re)initializing the CG configuration. In some implementations, the CG configuration may have specific indices, such as the lowest index among multiple configurations, the highest index among multiple configurations, and a specific index configured specifically for the SDT process. In some implementations, the CG configuration may include a parameter indicating SDT scheduling. In some implementations, the SDT transfer period may begin when or after the CG configuration is considered valid.

[0191] In some implementations, the SDT transmission period 402B in the CG-based SDT procedure 400B may begin when or after the UE sends a UL message (e.g., UL message 404B sent by the UE).

[0192] In some implementations, UL messages can be transmitted via MSG1 / MSG3 / MSGA / CG resources / UL resources scheduled by MSG2 / MSGB / MSG4 (e.g., during SDT), or via UL resources pre-configured or configured as part of the SDT configuration. In some implementations, UL messages may include RRC recovery request messages (e.g., RRCResumeRequest or RRCResumeRequest1). In some implementations, UL messages may contain small data (e.g., UL data associated with a specific SRB / DRB / LCH used for SDT). In some implementations, UL messages may contain a MAC CE (e.g., BSR MAC CE).

[0193] In some implementations, the SDT transmission cycle may begin when or after the UE receives a response from the NW. In some implementations, the response may be a response to Msg2 / Msg4 / MsgB and / or a UL transmission via CG resources. In some implementations, the response may be used for contention resolution (e.g., for the RA procedure). In some implementations, the response may include ACK / NACK (e.g., HARQ / RRC) messages, such as for a UL transmission via CG resources. In some implementations, the response may contain a UL grant / DL allocation for a new transmission / retransmission. In some implementations, the response may be a PDCCH addressed to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the response may represent a UL grant for a new transmission in a HARQ procedure for UL transmissions of small data (e.g., UL messages). In some implementations, the response may include specific instructions (e.g., TA instruction MAC CE). In some implementations, the response may include messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc.

[0194] In some implementations, the SDT transmission period may begin when or after the UE receives the NW indication. In some implementations, the indication (with a specific value, such as TRUE or FALSE) may be included in broadcast system information (e.g., SIB) to indicate support for CG transmission of UEs in the RRC_INACTIVE state within the cell.

[0195] In some implementations, the SDT transmission cycle and / or SDT process may be terminated / stopped when or after the SDT process terminates. In some implementations, the SDT transmission cycle and / or SDT process may be terminated / stopped after the CG configuration is released / paused / cleared. In some implementations, the SDT transmission cycle and / or SDT process may be terminated / stopped when the CG configuration is deemed invalid.

[0196] In some implementations, the SDT transmission period and / or SDT procedure can be terminated or stopped when the UE receives an indication from the NW. In some implementations, the indication may include messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc. The indication may be a PDCCH addressed to the RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the indication may instruct the UE to terminate the SDT procedure and / or SDT transmission period (e.g., based on fields of the indication). In some implementations, the indication may instruct the UE to initiate an RRC procedure (e.g., RRC connection restoration procedure, RRC establishment procedure, and / or RRC re-establishment procedure). In some implementations, the indication may indicate the type of UE handover / rollback SDT, for example, the type may be RA-based SDT, CG-based SDT, two-step RA, four-step RA, etc. In some implementations, an indication (with a specific value, such as TRUE or FALSE) may be included in system information (e.g., SIB) to indicate that CG transmission for a UE in the RRC_INACTIVE state is no longer supported in the cell. For example, when a UE receives an indication (with a specific value, such as TRUE or FALSE), the UE may release / suspend CG configuration.

[0197] In some implementations, the SDT transmission period and / or SDT procedure may terminate or stop upon timer / window expiration. In some implementations, the timer / window may be an SDT failure / problem detection timer. In some implementations, the timer / window may be specifically configured for SDT. In some implementations, the timer / window value can be configured via an RRC release message. In some implementations, the timer / window value can be configured via an RRC release message with a "pause" configuration. In some implementations, the timer / window value can be configured via SDT configuration. In some implementations, the timer / window value can be configured via SDT RACH configuration. In some implementations, the timer / window value can be configured via SDT CG configuration. In some implementations, the timer / window value can be configured via IE UE-TimersAndConstants. In some implementations, the timer / window value can be configured via system information (e.g., SIB).

[0198] In some implementations, the timer / window may be a TA timer, ra-ResponseWindow, msgB-ResponseWindow, ra-ContentionResolutionTimer, configuredGrantTimer, cg-RetransmissionTimer, drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, T300, T301, T302, T304, T310, T311, T312, T316, T319, T320, T321, T322, T325, T330, T331, T342, T345, and / or a new Tx. In some implementations, the timer / window may be used to monitor responses (e.g., for ACK / NACK). The timer / window may be a response window. In some implementations, the timer / window may be used to receive PDCCH from the network NW or for scheduling (e.g., for new transmissions or retransmissions).

[0199] In some implementations, the SDT transmission cycle may terminate / stop after the UE enters the RRC_IDLE state or the RRC_CONNECTED state (e.g., from the RRC_INACTIVE state to the RRC_IDLE or RRC_CONNECTED state). In some implementations, the SDT transmission cycle may terminate / stop / release during or after the UE performs cell selection / reselection. In some implementations, the SDT transmission cycle may terminate / stop when the upper layer terminates connection establishment. In some implementations, the SDT transmission cycle may terminate / stop due to RAN notification area (RNA) updates. In some implementations, the SDT transmission cycle may terminate / stop when the UE establishes / resumes an RRC connection from the RRC_INACTIVE state on a cell different from the one providing the CG configuration. In some implementations, the SDT transmission cycle may terminate / stop during or after the UE initiates an RRC re-establishment procedure. For example, the SDT transmission cycle may terminate / stop after the UE sends an RRCReestablishmentRequest to the network NW. In some implementations, the SDT transmission cycle may be terminated / stopped when or after the NW instructs the UE to perform a carrier handover (e.g., from NUL to SUL or vice versa). In some implementations, the SDT transmission cycle may be terminated / stopped when or after the NW instructs the UE to perform a BWP handover (e.g., UL / DL).

[0200] In some implementations, the UE may need to monitor the PDCCH during SDT transmission, for example, to receive possible scheduling (e.g., DL and / or UL) from the NW. In some implementations, the UE may monitor the PDCCH based on the Search Space (SS), CORESET, and / or RNTI (e.g., during the SDT procedure and / or SDT transmission). For example, after successfully completing the RA procedure of the SDT, the UE may monitor the PDCCH addressed to the C-RNTI.

[0201] In some embodiments, the search space (SS) in this application may include one or more of the following search spaces: In some embodiments, the SS may be a common SS (CSS). In some embodiments, the SS may be a CSS configured in IE PDCCH-ConfigCommon. In some embodiments, the SS may be a CSS configured in IE sdt-SearchSpace. In some embodiments, the SS may be a type 1 PDCCH CSS set configured by IEra-SearchSpace. In some embodiments, the SS may be a type 3 PDCCH CSS set. In some embodiments, the SS may be search space zero. In some embodiments, the SS may be a new common search space set configured via system information (e.g., SIB) or RRC release messages. In some embodiments, the SS may be an SS among SS(s) with configuration parameters in the initial BWP.

[0202] In some implementations, an SS may be a UE-specific SS set. In some implementations, an SS may be a UE-specific SS set configured via an RRC release message. In some implementations, an SS may be a UE-specific SS set configured via Msg4 / MsgB. In some implementations, an SS may be a UE-specific SS set configured via IE PDCCH-Config. In some implementations, an SS may be a USS(s) configured by IE sdt-CG-SearchSpace. In some implementations, an SS may be a USS(s) configured in the CG configuration of the SDT. In some implementations, an SS may be a USS(s) configured in a BWP specifically configured for the SDT. In some implementations, an SS may be a UE-specific SS set configured via the SDT configuration. In some implementations, an SS may be a search space for IDs other than 0-39. In some implementations, an SS may be an SS set identified as a specific search space set of the SDT.

[0203] In some implementations, the CORESET mentioned in this application may include one or more of the following CORESETs: In some implementations, the CORESET may be a public CORESET. In some implementations, the CORESET may be CORESET 0. In some implementations, the CORESET may be a CORESET other than CORESET 0. In some implementations, the CORESET may be a UE-specific CORESET configuration. In some implementations, the CORESET may be a UE-specific CORESET configured via an RRC release message. In some implementations, the CORESET may be a UE-specific CORESET configured via Msg4 / MsgB. In some implementations, the CORESET may be a UE-specific CORESET configured via SDT configuration. In some implementations, the CORESET may be a CORESET with an ID other than 0-14.

[0204] In some implementations, the RNTI mentioned in this application may be C-RNTI, CS-RNTI, RNTI for SDT, RNTI for CG, and / or new RNTIs other than SI-RNTI, RA-RNTI, MsgB-RNTI, TC-RNTI, P-RNTI, INT-RNTI, SFI-RNTI, TPC-PUSCH-RNTI, TPC-PUCCH-RNTI, TPC-SRS-RNTI, CI-RNTI, C-RNTI, MCS-C-RNTI, CS-RNTI(s), PS-RNTI, SL-RNTI, SL-CS-RNTI, and SL semi-persistent scheduling V-RNTI.

[0205] In some implementations, under different conditions, the UE can monitor the PDCCH based on different SSs, CORESETs, and / or RNTIs. Different SSs, CORESETs, and / or RNTIs can be configured through different configurations and / or signaling. In some implementations, different configurations can be configured for SDT, RA configuration, CG configuration, etc. In some implementations, different signaling may be system information (e.g., SIB), RRC release messages, RRC reconfiguration messages, etc. In some implementations, the UE can monitor the PDCCH based on a first SS (e.g., a common SS), a first CORESET, and a first RNTI based on an RA-based SDT. In some implementations, the UE can monitor the PDCCH based on a second SS (e.g., a UE-specific SS), a second CORESET, and a second RNTI based on a CG SDT. In some implementations, the UE can monitor the PDCCH based on a first SS, a first CORESET, and a first RNTI for new transmissions. In some implementations, the UE can monitor the PDCCH based on a second SS, a second CORESET, and a second RNTI for retransmissions.

[0206] In some implementations, PDCCH monitoring behavior for SDT is defined, such as how and / or when to monitor PDCCH during the SDT process. Figure 5 A schematic diagram of a PDCCH monitoring alternative 500 according to one of the exemplary embodiments of this application is shown. The PDCCH monitoring alternative can be applied during SDT processes and / or SDT transmissions based on the search space, CORESET, and / or RNTI. The alternatives can be implemented independently and / or separately to form a particular method. Any two or more of the following alternatives can be logically, reasonably, and / or appropriately combined to form a particular method.

[0207] In some implementations, during SDT transmission 508, an event-based PDCCH monitoring alternative 502 may be applied, wherein the UE may monitor the PDCCH during the SDT procedure (e.g., RA-based and / or CG-based SDT procedure) and / or during SDT transmission based on search space, CORESET, and / or RNTI. In some implementations, the UE may continuously monitor the PDCCH during the SDT procedure and / or SDT transmission based on search space, CORESET, and / or RNTI. In some implementations, the UE may not stop monitoring the PDCCH during the SDT procedure and / or SDT transmission based on search space, CORESET, and / or RNTI (e.g., until a condition for PDCCH monitoring termination is met).

[0208] In some implementations, the UE can monitor the PDCCH while an SDT procedure (e.g., an RA-based and / or CG-based SDT procedure) is in progress. More specifically, the UE can monitor the PDCCH while an RA procedure (e.g., for SDT) is in progress. In some implementations, the UE can monitor the PDCCH after configuring / initializing the CG configuration. For example, if the CG configuration is configured in an RRC release message, the UE can monitor the PDCCH after receiving the CG configuration in the RRC release message. In some implementations, the UE may monitor the PDCCH when or after the CG resource / configuration is deemed valid. In some implementations, the UE can monitor the PDCCH after initiating an SDT procedure.

[0209] In some implementations, the UE may monitor the PDCCH after the UE considers the contention resolution for the RA procedure to be successful and / or after the UE considers the RA procedure to have been successfully completed. In some implementations, the UE may monitor the PDCCH until the RA-SDT procedure ends. In some implementations, the RA procedure may be an RA-based SDT procedure.

[0210] In some implementations, an RA procedure can be initiated for SDT. In some implementations, the UE can monitor the PDCCH after sending a UL message. In some implementations, the UL message can be transmitted via MSG1 / MSG3 / MSGA / CG resources / UL resources scheduled by MSG2 / MSGB / MSG4 (e.g., during the SDT procedure). In some implementations, the UL message may include an RRC recovery request message (e.g., RRCResumeRequest or RRCResumeRequest1). In some implementations, the UL message may contain small data (e.g., UL data associated with a specific SRB / DRB / LCH used for SDT). In some implementations, the UL message may contain a MAC CE (e.g., BSR MAC CE). In some implementations, if RA-SDT is selected and the RA procedure is successfully completed, the UE can monitor the PDCCH addressed to C-RNTI until the RA-SDT procedure terminates. If CG-SDT is selected and after the initial transmission of CG-SDT is performed, the UE can monitor the PDCCH addressed to both C-RNTI and CS-RNTI until the CG-SDT procedure terminates.

[0211] In some implementations, the UE can monitor the PDCCH after sending the UL message. In some implementations, the UE can monitor the PDCCH for a specified duration after starting to transmit the UL message, or it can choose not to monitor the PDCCH. In some implementations, the duration may be determined by the UE's processing capabilities.

[0212] In some implementations, the UE may monitor the PDCCH after receiving a response from the NW. In some implementations, the response may be a response to Msg2 / Msg4 / MsgB and / or a UL transmission via CG resources. In some implementations, the response may be used for contention resolution, e.g., for the RA procedure. In some implementations, the response may include ACK / NACK, e.g., for a UL transmission via CG resources. In some implementations, the response may contain a UL grant / DL allocation for a new transmission / retransmission. In some implementations, the response may be a PDCCH addressed to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the response may represent a UL grant for a new transmission in a HARQ procedure for transmitting small data (e.g., UL messages) UL transmissions. In some implementations, the response may include specific instructions, e.g., a TA instruction MAC CE. In some implementations, the response may include messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc.

[0213] In some implementations, during SDT transmission period 508, a timer / window-based PDCCH monitoring replacement scheme 504 can be applied, in which the UE can monitor the PDCCH while the timer / window is running based on the search space, CORESET, and / or RNTI. In some implementations, the UE may continue monitoring the PDCCH while the timer / window is running based on the search space, CORESET, and / or RNTI. In some implementations, the UE may not stop monitoring the PDCCH while the timer / window is running based on the search space, CORESET, and / or RNTI. In some implementations, the UE can monitor the PDCCH while the timer / window is running, regardless of whether measurement gaps may occur.

[0214] In some implementations, the timer / window may be an SDT failure / problem detection timer. In some implementations, the timer / window may be specifically configured for the SDT. In some implementations, the timer / window value can be configured via an RRC release message. In some implementations, the timer / window value can be configured via an RRC release message with a "suspend" configuration. In some implementations, the timer / window value can be configured via the SDT configuration. In some implementations, the timer / window value can be configured via the SDT's RACH configuration. In some implementations, the timer / window value can be configured via the SDT's CG configuration. In some implementations, the timer / window value can be configured via IE UE-TimersAndConstants. In some implementations, the timer / window value can be configured via system information (e.g., SIB).

[0215] In some implementations, the timer / window may be a TA timer, ra-ResponseWindow, msgB-ResponseWindow, ra-ContentionResolutionTimer, configuredGrantTimer, cg-RetransmissionTimer, drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, T300, T301, T302, T304, T310, T311, T312, T316, T319, T320, T321, T322, T325, T330, T331, T342 and / or T345.

[0216] In some implementations, a timer / window can be used to monitor responses (e.g., for ACK / NACK). A timer / window may be a response window. In some implementations, a timer / window can be used to receive PDCCH / scheduling from the NW (e.g., for new transmissions or retransmissions). In some implementations, a timer / window may be started or restarted when the UE receives an RRC release message (e.g., with a pause configuration). The RRC release message may contain SDT configuration. In some implementations, a timer / window can be started or restarted when the SDT procedure is initiated. In some implementations, a timer / window can be started or restarted when the RA procedure is initiated. In some implementations, a timer / window (e.g., for one or more or all CG configurations) can be started or restarted when initializing the CG configuration (e.g., corresponding to a timer / window). In some implementations, a timer / window can be started or restarted at the start of the SDT transmission cycle.

[0217] In some implementations, a timer / window may be started or restarted when the UE sends or retransmits a UL message. In some implementations, the UL message may be transmitted via MSG1 / MSG3 / MSGA / CG resources / UL resources scheduled by MSG2 / MSGB / MSG4 (e.g., during SDT). In some implementations, the UL message may include an RRC recovery request message (e.g., RRCResumeRequest or RRCResumeRequest1). In some implementations, the UL message may contain small data (e.g., UL data associated with a specific SRB / DRB / LCH used for SDT). In some implementations, the UL message may contain a MAC CE (e.g., BSR MAC CE). In some implementations, if the UL message is transmitted or retransmitted based on CG resources / configurations, a timer / window corresponding to the CG configuration may be started or restarted. In some implementations, if the UL message is transmitted on dynamically authorized UL resources, and a HARQ process for retransmitting UL data transmitted via CG resources is dynamically authorized, a timer / window corresponding to the CG configuration may be started or restarted.

[0218] In some implementations, a timer / window may start or restart when the UE receives a response from the NW. In some implementations, the response may be a response to Msg2 / Msg4 / MsgB and / or a UL transmission via CG resources. In some implementations, the response may be used for contention resolution, e.g., for the RA procedure. In some implementations, the response may include ACK / NACK, e.g., a UL transmission via CG resources. In this case, the timer / window corresponding to the CG configuration of the CG resources may start or restart. In some implementations, the response may contain a UL grant / DL allocation for a new transmission / retransmission. In some implementations, the response may be a PDCCH addressed to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In this case, if the UL grant / DL allocation is a retransmission used to instruct a HARQ process for transmitting UL data via CG resources, the timer / window corresponding to the CG configuration may start or restart. In some implementations, the response may represent a UL authorization for a new transport by a HARQ process used for UL transports of small data (e.g., UL messages). In some implementations, the response may include specific instructions, such as the TA instruction MAC CE. In some implementations, the response may include messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc.

[0219] In some implementations, the timer / window may start or restart when the UE receives the PDCCH, for example, addressing to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the timer / window may start or restart when the UE receives a DL allocation, for example, on the PDCCH and / or DL ​​message / data (e.g., on the PDSCH). In some implementations, the timer / window may start or restart when another timer (e.g., a HARQ RTT timer) expires. This other timer may indicate the minimum duration prior to the DL allocation and / or UL HARQ retransmission authorization expected by the UE (e.g., the UE's MAC entity). In some implementations, the timer / window may start or restart with a delay after a configuration offset. The configuration offset may indicate the minimum duration prior to the DL allocation and / or UL HARQ retransmission authorization expected by the UE (e.g., the UE's MAC entity). In some implementations, the configuration offset may also be configured according to the CG configuration. In some implementations, the timer / window may stop when the SDT procedure terminates. In some implementations, the timer / window may stop when the RA process stops / aborts. In some implementations, the timer / window (e.g., one or more or all CG configurations) may stop when the corresponding CG configuration is released / paused / cleared. In some implementations, the timer / window (e.g., one or more or all CG configurations) may stop when the corresponding CG configuration is deemed invalid, for example, when the TAT of the CG configuration expires.

[0220] In some implementations, the timer / window may stop when the UE receives an indication from the NW. In some implementations, the indication may include messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc. The indication may be a PDCCH addressed to the RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the indication may instruct the UE to terminate the SDT procedure and / or the SDT transmission period (e.g., based on fields of the indication). In some implementations, the indication may instruct the UE to initiate an RRC procedure (e.g., RRC connection restoration procedure, RRC establishment procedure, and / or RRC re-establishment procedure). In some implementations, the indication may indicate the type of UE handover / rollback SDT (e.g., the type may be RA-based SDT, CG-based SDT, two-step RA, four-step RA, etc.).

[0221] In some implementations, the timer / window may stop when the UE receives a response from the NW. In some implementations, the response may be a response to Msg2 / Msg4 / MsgB and / or a UL transmission via CG resources. In some implementations, the response may be used for contention resolution, e.g., for the RA procedure. In some implementations, the response may include ACK / NACK, e.g., for a UL transmission via CG resources. In some implementations, the response may contain a UL grant / DL allocation for a new transmission / retransmission. In some implementations, the response may be a PDCCH addressed to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the response may indicate a UL grant for a new transmission in the HARQ procedure for transmitting small data (e.g., UL messages) UL transmissions. In some implementations, the response may include specific instructions (e.g., TA instruction MAC CE). In some implementations, the response may include messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc.

[0222] In some implementations, the timer / window may stop during cell selection or reselection. In some implementations, the timer / window may stop when upper-layer connection establishment terminates. In some implementations, the timer / window may stop during RAN notification area (RNA) updates. In some implementations, the timer / window may stop when the UE updates its serving cell to another cell or when the UE migrates to a new (e.g., suitable / acceptable) cell. For example, the timer / window may stop when or after the UE establishes / resumes an RRC connection from an RRC_INACTIVE state on a cell different from the one providing the CG configuration. In some implementations, the timer / window may stop when the UE initiates an RRC rebuild procedure. For example, the timer / window may stop when the UE sends an RRCReestablishmentRequest to the network NW. In some implementations, the timer / window may stop when the NW instructs the UE to perform a carrier handover (e.g., from NUL to SUL or vice versa). In some implementations, the timer / window may stop when the NW instructs the UE to perform a BWP handover (e.g., UL / DL).

[0223] In some implementations, the UE may enter the RRC_IDLE state when the timer / window expires. In some implementations, the UE may initiate an RRC establishment procedure, for example, via RRCSetupRequest, when the timer / window expires. In some implementations, the UE may initiate an RRC reconstruction procedure, for example, via RRCestablishmentRequest, when the timer / window expires. In some implementations, the UE may initiate an RRC connection recovery procedure, for example, via RRCResumeRequest, when the timer / window expires. In some implementations, the UE may release / suspend the CG configuration (e.g., the CG configuration corresponding to the timer / window) when the timer / window expires. In some implementations, the UE may perform retransmission based on CG resources / configuration (e.g., the CG resources / configuration corresponding to the timer / window) when the timer / window expires.

[0224] In some implementations, during SDT transmission, the SDT procedure can be used for DRX-based PDCCH monitoring, during which the UE (e.g., the UE's MAC entity) can be configured (e.g., by RRC) to have the function of controlling the UE's (e.g., the UE's MAC entity's) PDCCH monitoring activities (e.g., for the UE's (e.g., the UE's MAC entity's) RNTI, for the BWP and / or the serving cell) and / or the timing of PDCCH monitoring.

[0225] In some implementations, the RNTI mentioned in this application can be C-RNTI, CS-RNTI, RNTI for SDT, RNTI for CG, and / or a new RNTI other than SI-RNTI, RA-RNTI, MsgB-RNTI, TC-RNTI, P-RNTI, INT-RNTI, SFI-RNTI, TPC-PUSCH-RNTI, TPC-PUCCH-RNTI, TPC-SRS-RNTI, CI-RNTI, C-RNTI, MCS-C-RNTI, CS-RNTI(s), PS-RNTI, SL-RNTI, SL-CS-RNTI, and SL semi-persistent scheduling V-RNTI. In some implementations, the BWP mentioned in this application can be an initial (DL) BWP (e.g., BWP#0) and / or a dedicated (DL) BWP. A dedicated BWP can be configured for SDT with RA configuration. A dedicated BWP can be configured for SDT with CG configuration. The BWP ID of a dedicated BWP can be configured via an RRC message (e.g., an RRC release message).

[0226] In some implementations, during SDT transmission 508, the following can be applied: Figure 5The DRX-based PDCCH monitoring alternative scheme 506 is described. A UE can be configured to have a function (e.g., a DRX function) controlling the PDCCH monitoring activities of the UE (e.g., the UE's MAC entity) for the UE's RNTI, for the BWP, and / or for the serving cell. During the RRC_INACTIVE state, if the function (e.g., the DRX function) is configured, the UE is allowed to discontinuously use the DRX function to monitor the PDCCH (e.g., for the UE's RNTI, for the BWP, and / or the serving cell). In some implementations, this function can be configured. This configuration can be based on SDT configuration. In some implementations, the configuration can be configured via system information (e.g., SIB), RRC release messages (e.g., with pause configuration), and / or dedicated RRC messages (e.g., RRC reconfiguration). In some implementations, the configuration may be a DRX configuration. In some implementations, the configuration may include a DRX cycle. In some implementations, the configured and / or configured parameters / timers may, for example, be applied only when the UE is performing an SDT procedure and / or during an SDT transmission.

[0227] In some implementations, the configuration may include one or more parameters. In some implementations, RRC can control functionality (e.g., DRX functionality) by configuring one or more parameters. Examples include drx-onDurationTimer, drx-SlotOffset, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle, drx-ShortCycleTimer, drx-HARQ-RTT-TimerDL, drx-HARQ-RTT-TimerUL, and / or, etc. In some implementations, these parameters may be specifically for SDTs and / or UEs in the RRC_INACTIVE state. In some implementations, the parameters may be named drx-onDurationTimerSDT, drx-SlotOffsetSDT, drx-InactivityTimerSDT, drx-RetransmissionTimerDLSDT, drx-RetransmissionTimerULSDT, drx-LongCycleStartOffsetSDT, drx-ShortCycleSDT, drx-ShortCycleTimerSDT, drx-HARQ-RTT-TimerDLSDT, drx-HARQ-RTT-TimerULSDT, and / or, etc. In other implementations, the SDT in the UE may reuse the DRX configuration (e.g., DRX parameters) from the RRC_CONNECTED state in the RRC_INACTIVE state.

[0228] In some implementations, the RRC release message may include an indication that, after the UE enters the RRC_INACTIVE state, it can apply the DRX configuration (e.g., DRX parameters) in the RRC_CONNECTED state. In some implementations, at least one timer (e.g., the DRX timer) may stop when one or more of the following occurs: when the SDT procedure terminates, when the RA procedure stops / aborts, when the CG configuration is released / suspended / cleared, when the CG configuration is deemed invalid, when the UE receives an indication from the NW, and / or when the UE receives a response from the NW.

[0229] In some implementations, when a feature is configured (e.g., DRX), the activation time (e.g., for the BWP and / or serving cell) may include the time when one or more of the following occur. In some implementations, if the UE is considered to be in active time, the UE may monitor the PDCCH (e.g., via RNTI, on the BWP and / or serving cell). In some implementations, the activation time may include the time during which a timer / window is running. In some implementations, the timer / window may be a TA timer, ra-ResponseWindow, msgB-ResponseWindow, ra-ContentionResolutionTimer, configuredGrantTimer, cg-RetransmissionTimer, drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, T300, T301, T302, T304, T310, T311, T312, T316, T319, T320, T321, T322, T325, T330, T331, T342, and / or T345. In some implementations, the timer / window may be an SDT failure detection timer. In some implementations, the timer / window may be used to monitor responses (e.g., for ACK / NACK) and / or retransmission scheduling from NW. In some implementations, the timer / window may be used for SDT.

[0230] In some implementations, the UE can monitor one or more PDCCH timings for each configured period (e.g., DRX period). PDCCH monitoring timings may include multiple time slots (e.g., subframes or OFDM symbols) where PDCCH can be transmitted. In some implementations, the UE can configure one or more parameters (e.g., SS and / or CORESET) to derive the PDCCH monitoring timings. PDCCH monitoring timings can be derived according to a formula (e.g., specified in TS). The period can be configured via system information (e.g., SIB), RRC release messages (e.g., with pause configuration), and / or dedicated RRC messages (e.g., RRC reconfiguration).

[0231] In some implementations, other PDCCH monitoring behaviors for SDT are also defined, such as how to stop / terminate PDCCH monitoring. In some implementations, the UE may base its actions on at least one of the aforementioned PDCCH monitoring alternatives (e.g., Figure 5Actions 502, 504, and 506 in the process monitor the PDCCH until the SDT procedure terminates. In other words, if the SDT procedure terminates, the UE may stop monitoring the PDCCH. In some implementations, the UE may monitor at least one of the alternative schemes (e.g., ...) based on the above-described PDCCH monitoring. Figure 5 Actions 502, 504, and 506 in the protocol monitor the PDCCH until the RA process is completed / stopped / aborted. In other words, if the RA process is completed / stopped / aborted, the UE may stop monitoring the PDCCH. In some implementations, the UE may monitor the PDCCH based on at least one of the above-described PDCCH monitoring alternatives until the CG configuration is released / suspended / cleared. That is, if the CG configuration is released / suspended / cleared, the UE may stop monitoring the PDCCH. In some implementations, the UE may monitor the PDCCH based on at least one of the above-described PDCCH monitoring alternatives until the CG configuration is considered invalid (e.g., the TAT of the CG configuration may have expired). In other words, if the CG configuration is considered invalid, the UE may stop monitoring the PDCCH. In some implementations, the UE may monitor the PDCCH based on at least one of the above-described PDCCH monitoring alternatives until the CG configuration is dynamically de-prioritized by uplink scheduling (e.g., the uplink grant sent to the C-RNTI and the uplink grant sent to the CG resource represent the same resource).

[0232] In some implementations, the UE may monitor the PDCCH based on at least one of the above-described PDCCH monitoring alternatives until the UE receives a response from the network NW. In other words, the UE may stop monitoring the PDCCH after receiving a response from the network NW. In some implementations, the response may be a response to Msg2 / Msg4 / MsgB and / or a response to UL transmissions via CG resources. In some implementations, the response may be used for contention resolution (e.g., for the RA procedure). In some implementations, the response may include ACK / NACK (e.g., HARQ / RRC) messages, such as UL transmissions via CG resources. In some implementations, the response may contain UL grants / DL allocations for new transmissions / retransmissions. In some implementations, the response may be a PDCCH addressed to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the response may represent a UL grant for a new transmission in a HARQ procedure for UL transmissions of small data (e.g., UL messages). In some implementations, the response may include specific instructions (e.g., the TA instruction MACCE). In some implementations, the response may include messages such as RRCResume, RRCSetup, RRCRelease, RRCRelease with SuspendConfig, RRCReestablishment, and / or RRCReject, etc.

[0233] In some implementations, the UE can monitor at least one of the above-mentioned PDCCH alternative schemes (e.g., Figure 5Actions 502, 504, and 506 in the protocol monitor the PDCCH until the UE receives an indication from the network NW. In other words, if / after the UE receives an indication from the NW, the UE may stop monitoring the PDCCH. In some implementations, the indication may be received via messages such as RRCResume, RRCSetup, RRCRelease, RRCReestablishment with SuspendConfig, and / or RRCReject, etc. In some implementations, the indication may be a PDCCH addressed to an RNTI (e.g., C-RNTI, CS-RNTI, dedicated RNTI, RNTI for SDT, and / or RNTI for CG). In some implementations, the indication may instruct the UE to terminate the SDT procedure and / or SDT transmission cycle (e.g., based on the field parameters of the indication). In some implementations, the indication may instruct the UE to initiate an RRC procedure (e.g., RRC connection recovery procedure, RRC establishment procedure, and / or RRC re-establishment procedure). In some implementations, the indication can indicate the type of UE handover / fallback SDT (e.g., the type can be RA-based SDT, CG-based SDT, two-step RA, four-step RA, etc.).

[0234] In some implementations, the UE can monitor the PDCCH according to at least one of the above-described PDCCH monitoring alternatives until the timer / window expires and / or is not running. In other words, if the timer / window expires and / or is not running, the UE may stop monitoring the PDCCH. In some implementations, the timer / window may be a TA timer, ra-ResponseWindow, msgB-ResponseWindow, ra-ContentionResolutionTimer, configuredGrantTimer, cg-RetransmissionTimer, drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, T300, T301, T302, T304, T310, T311, T312, T316, T319, T320, T321, T322, T325, T330, T331, T342 and / or T345. In some implementations, the timer / window may be an SDT failure detection timer. In some implementations, the timer / window may be used to monitor responses (e.g., for ACK / NACK) and / or retransmission scheduling from NW. In some implementations, the timer / window may be used for SDT.

[0235] In some implementations, additional PDCCH monitoring behaviors of SDT are also defined, such as monitoring the PDCCH within a time period. In some implementations, within a time period (e.g., a measurement gap, a BWP handover period, and / or UE processing time), if one or more of the following monitoring conditions are met, the UE (e.g., the UE's MAC entity) may monitor the PDCCH (e.g., on SC(s) within the corresponding frequency range of the measurement gap configured by the IE measGapConfig specified in [TS 38.331]) if these conditions are met. In some implementations, the monitoring conditions may include whether the UE is in the RRC_INACTIVE state. In some implementations, another monitoring condition may be that the SDT procedure (based on RA and / or CG) is in progress. In some implementations, another monitoring condition may be after configuring / initiating CG configuration. In some implementations, another monitoring condition may be when or after the CG resource / configuration is considered valid. In some implementations, another monitoring condition may be after the UE initiates the SDT procedure. In some implementations, another monitoring condition may be after the UE considers the contention for the RA procedure to have been successfully resolved. In some implementations, another monitoring condition might be after the UE considers the RA procedure to have completed successfully. In some implementations, another monitoring condition might be after the UE sends a UL message. In some implementations, another monitoring condition might be after the UE receives a response from the NW. In some implementations, another monitoring condition might be that a timer / window is running.

[0236] In some implementations, the UE (e.g., the UE's MAC entity) may not monitor the PDCCH (e.g., on SC(s) within the corresponding frequency range of the measurement gap configured by the IE measGapConfig specified in [TS 38.331]) if one or more of the following monitoring conditions are met: In some implementations, a monitoring condition may be whether the UE is in the RRC_INACTIVE state. In some implementations, a monitoring condition may be that an SDT procedure (e.g., RA-based and / or CG-based SDT procedure) is in progress. In some implementations, a monitoring condition may be after configuring / initiating CG configuration. In some implementations, a monitoring condition may be when or after CG resources / configuration are considered valid. In some implementations, a monitoring condition may be after the UE initiates an SDT procedure. In some implementations, a monitoring condition may be after the UE considers the contention for the RA procedure to have been successfully resolved. In some implementations, a monitoring condition may be after the UE considers the RA procedure to have been successfully completed. In some implementations, a monitoring condition may be after the UE sends a UL message. In some implementations, a monitoring condition might occur after the UE receives a response from the NW. In other implementations, a monitoring condition might occur while a timer / window is running.

[0237] In some implementations, the UE may monitor the PDCCH if a timer / window (e.g., mentioned earlier in this application) is in operation, regardless of possible measurement gaps, BWP handover cycles, and / or UE processing time.

[0238] In some implementations, additional PDCCH monitoring behaviors are defined for SDT, such as PDCCH monitoring timing collisions. In some implementations, the UE (e.g., a UE in RRC_INACTIVE state) can configure different PDCCH monitoring timings for different purposes, such as for paging / SMS, for system information, for RA, etc. In some implementations, the PDCCH monitoring timing may be determined by SSs, CORESETs, and / or some parameters.

[0239] In some implementations, regarding paging / SMS, the PDCCH monitoring timing (e.g., paging timing) for paging can be determined based on ID pagingSearchSpace (e.g., specified in 3GPP TS 38.213) and IDs firstPDCCH-MonitoringOccasionOfPO and nrofPDCCH-MonitoringOccasionPerSSB-InPO (e.g., specified in 3GPP TS 38.331). In some implementations, the UE can monitor PDCCH SI change indications and / or Public Warning System (PWS) notifications (e.g., earthquake and tsunami warning system (ETWS) or commercial mobile alert service (CMAS)) based on the paging timing.

[0240] In some implementations, regarding system information, for example, for SIB1, the timing of PDCCH monitoring can be determined based on ID searchSpaceSIB1. For other SI and / or SI message collection, the timing of PDCCH monitoring can be determined based on ID searchSpaceOtherSystemInformation (e.g., searchSpaceSIB1).

[0241] In some implementations, for the purpose of RA, an ID ra-SearchSpace can be configured for the RA process (e.g., for monitoring RAR) to monitor PDCCH.

[0242] In some implementations, the configuration for the PDCCH monitoring timing for UE monitoring (e.g., when the UE is in the RRC_INACTIVE state) can be included in the PDCCH-ConfigCommon IE (e.g., as shown in Table 1 below). In some implementations, the configuration may include one or more of the following: controlResourceSetZero, commonControlResourceSet, searchSpaceZero, commonSearchSpaceList, searchSpaceSIB1, searchSpaceOtherSystemInformation, pagingSearchSpace, ra-SearchSpace, firstPDCCH-MonitoringOccasionOfPO, and / or commonSearchSpaceListExt-r16, etc.

[0243] In 3GPP TS 38.213, a set of candidate PDCCHs for UE monitoring of PDCCHs can be defined according to a PDCCH SS set. In some implementations, the SS set can be a CSS set or a USS set, and the UE can monitor one or more candidate PDCCHs from the following SS sets. In some implementations, the UE can monitor candidate PDCCHs in the Type0A-PDCCH CSS set, which is configured by IE pdcch-ConfigSIB1 in the MIB, or by IDsearchSpaceSIB1 in IE PDCCH-ConfigCommon, or by ID searchSpaceZero in IEPDCCH-ConfigCommon for DCI format of CRC perturbed by SI-RNTI on the MCG primary cell. In some implementations, the UE can monitor candidate PDCCHs in the Type0A-PDCCH CSS set, which is configured by ID searchSpaceOtherSystemInformation in IE PDCCH-ConfigCommon for DCI format of CRC perturbed by SI-RNTI on the MCG primary cell. In some implementations, the UE can monitor candidate PDCCHs in a Type 1-PDCCH CSS set, which is configured by the IRa-SearchSpace in the IE PDCCH-ConfigCommon of the DCI format for CRC scrambling using RA-RNTI, MsgB-RNTI, or TC-RNTI on the primary cell. In some implementations, the UE can monitor candidate PDCCHs in a Type 2-PDCCH CSS set, which is configured by the ID PagingSearchSpace in the IE PDCCH-ConfigCommon of the DCI format for CRC scrambling using P-RNTI on the primary cell of the MCG. In some implementations, the UE may monitor candidate PDCCHs in a Type 3-PDCCH CSS, which is configured by the ID SearchSpace in the IE PDCCH-Config. The IE PDCCH-Config carries ID searchSpaceType=common for CRCs scrambled by DCI formats including INT-RNTI, SFI-RNTI, TPC-PUSCH-RNTI, TPC-PUCCH-RNTI, TPC-SRS-RNTI, or CI-RNTI, as well as, only for the primary cell, a C-RNTI, MCS-C-RNTI, CS-RNTI(s), or PS-RNTI.In some implementations, the UE may monitor candidate PDCCHs in a USS set, where the USS set is configured by the ID SearchSpace in the IE PDCCH-Config, wherein the IE PDCCH-Config carries an ID searchSpaceType = ue-Specific for CRC scrambled by C-RNTI, MCS-C-RNTI, SP-CSI-RNTI, CS-RNTI(s), SL-RNTI, SL-CS-RNTI, or SL semi-persistent scheduling V-RNTI for DCI format.

[0244] In some implementations, with respect to SDT, the UE (e.g., in the RRC_INACTIVE state) can be configured with one or more SSs and / or one or more CORESETs for PDCCH monitoring (e.g., during SDT). In some implementations, the SS for SDT may be a common SS (e.g., a type 1A-PDCCH CSS configured by sdt-SearchSpace, a type 1 PDCCH CSS, a type 3 PDCCH CSS configured by ID ra-SearchSpace, and / or a new common SS configured from the system information / RRC release message). In some implementations, the SS for SDT may be a UE-specific SS (e.g., a UE-specific SS configured by sdt-CG-SearchSpace, a UE-specific SS configured from the RRC release message, and / or a UE-specific SS configured from Msg4 / MsgB).

[0245] In some implementations, the SDT's CORESET can be a common CORESET (e.g., CORESET 0, commonControlResourceSet). The SDT's CORESET can also be a UE-specific CORESET (e.g., a UE-specific CORESET configured from an RRC release message, and / or a UE-specific CORESET configured from Msg4 / MsgB).

[0246] In some implementations, different PDCCH monitoring times may partially or completely overlap / collide, for example, in the time domain (e.g., in the same symbol, time slot, subframe, system frame, etc.) and / or frequency domain. Figure 6 A schematic diagram illustrating the overlapping period between different PDCCH monitoring times according to one of the exemplary embodiments of this application is shown. Figure 6The overlap period 602 of the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606 in the time domain is shown. In some embodiments, the first PDCCH monitoring timing 604 can be configured for SDT. In some embodiments, the second PDCCH monitoring timing 606 can be configured for other purposes (e.g., for paging / SMS, for system information, for RA, etc.).

[0247] In some implementations, during the overlapping period, the UE may not be able to simultaneously monitor the first PDCCH monitoring opportunity 604 and the second PDCCH monitoring opportunity 606 (e.g., due to the UE's lack of capability).

[0248] In other implementations, the UE can simultaneously monitor the first PDCCH monitoring time 604 and the second PDCCH monitoring time 606. For example, assuming the UE is configured with at least two PDCCH monitoring times 604 and 606, wherein the first candidate PDCCH monitored in the first PDCCH monitoring time 604 can be configured for SDT, and the second candidate PDCCH monitored in the second PDCCH monitoring time 606 can be configured for other purposes (e.g., for paging / SMS, for system information, for RA, etc.), the first PDCCH candidate 604 (e.g., for SDT) can be configured by the first SS and / or the first CORESET.

[0249] - In some implementations, the first SS may be a common SS (e.g., a type 1 PDCCH CSS, a type 3 PDCCH CSS configured by IEra-SearchSpace e, and / or a new common SS configured from the System Information / RRC Release message). In some implementations, the first SS may be a CSS(s) configured in IE PDCCH-ConfigCommon.

[0250] - In some implementations, the first SS may be CSS(s) configured by IE sdt-SearchSpace.

[0251] - In some implementations, the first SS may be CSS(s) configured by IE sdt-CG-SearchSpace.

[0252] - In some implementations, the first SS may be a UE-specific SS (USS) (e.g., a specific UE SS configured from the RRC release message, and / or a specific UE SS configured from Msg4 / MsgB). In some implementations, the first SS may be a USS(s) configured in the CG configuration of the SDT.

[0253] - In some implementations, the first SS may be a USS(s) configured in a BWP dedicated to SDT.

[0254] In some implementations, the first SS may be a set of SSs configured via SDT (e.g., a UE-specific SS set). In some implementations, the first SS may be a set of SSs designated as a specific search space set of SDT. In some implementations, the first CORSET may be a common CORESET (e.g., CORESET 0, commonControlResourceSet). In some implementations, the first CORESET may be a UE-specific CORESET (e.g., a UE-specific CORESET configured from an RRC release message, and / or a UE-specific CORESET configured from Msg4 / MsgB). In some implementations, the second PDCCH monitoring timing (e.g., not used for SDT) may be configured by the second SS and / or the second CORESET. In some implementations, the second SS may be IE searchSpaceZero, commonSearchSpaceList, searchSpaceSIB1, searchSpaceOtherSystemInformation, pagingSearchSpace, ra-SearchSpace, commonSearchSpaceListExt-r16, etc. In some implementations, the second CORESET may be controlResourceSetZero, commonControlResourceSet, etc.

[0255] In some implementations, the second SS may be a public SS (e.g., a type 1 PDCCH CSS configured by IEra-SearchSpace, a type 3 PDCCH CSS, and / or a new public SS configured from a system message / RRC release message).

[0256] In some implementations, the second SS may be a CSS(s) configured in IE PDCCH-ConfigCommon.

[0257] In some implementations, the second SS can be a CSS(s) configured by IE sdt-SearchSpace.

[0258] In some implementations, the second SS can be a CSS(s) configured by IE sdt-CG-SearchSpace.

[0259] In some implementations, the UE is unlikely to be configured / provided (e.g., by the NW) with a first PDCCH monitoring timing 604 and / or a second PDCCH monitoring timing 606 that partially or completely overlap in the time domain (e.g., in the same symbol, time slot, subframe, system frame, etc.) and / or frequency domain. In other words, the NW may not configure the UE with a first PDCCH monitoring timing 604 and a second PDCCH monitoring timing 606 that partially or completely overlap in the time domain (e.g., in the same symbol, time slot, subframe, system frame, etc.) and / or frequency domain.

[0260] In some implementations, the UE can determine whether to monitor the PDCCH by monitoring the first SS, based on whether the first SS is configured / provided by the base station BS. If the first SS is configured / provided by the base station BS, the UE can monitor the PDCCH by monitoring the first SS. If the first SS is not configured / provided by the base station, the UE can monitor the PDCCH by monitoring the second SS.

[0261] In some implementations, it is unlikely that the UE will simultaneously monitor the first PDCCH monitoring timing 604 and / or the second PDCCH monitoring timing 606. For example, the NW may not be configured to completely or partially overlap the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606 in the time domain.

[0262] In some implementations, when the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606 partially or completely overlap / collide (e.g., in the same symbol, time slot, subframe, system frame, etc.), the UE can choose / prioritize monitoring one of the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606. In some implementations, the UE can choose / prioritize the first PDCCH monitoring timing 604. For example, if the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606 partially or completely overlap / collide (e.g., in the same symbol, time slot, subframe, system frame, etc.), the UE can monitor only the first PDCCH monitoring timing 604 and not the second PDCCH monitoring timing 606. In some implementations, the UE can choose / prioritize the second PDCCH monitoring timing 606. For example, if the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606 partially or completely overlap / collide (e.g., in the same symbol, time slot, subframe, system frame, etc.), the UE may monitor only the second PDCCH monitoring timing 606 and not the first PDCCH monitoring timing 604.

[0263] In some implementations, if the first PDCCH monitoring timing 604 and the second PDCCH monitoring timing 606 partially or completely overlap / collide (e.g., in the same symbol, time slot, subframe, system frame, etc.), the selection / priority of which PDCCH monitoring timing should be chosen / preferred can be determined by NW (e.g., via configuration / parameters) configuration (e.g., by the UE). In some implementations, if the UE configures a first parameter, the UE can select / prioritize the first PDCCH monitoring timing 604. For example, the UE can monitor only the first PDCCH monitoring timing 604 and not the second PDCCH monitoring timing 606. In some implementations, if the UE configures a second parameter, the UE can select / prioritize the second PDCCH monitoring timing 606. For example, the UE can monitor only the second PDCCH monitoring timing 606 and not the first PDCCH monitoring timing 604.

[0264] In some implementations, if the maximum number of non-overlapping CCEs per time slot and / or the maximum number of candidate PDCCHs monitored per time slot in RRC inactive state are determined, a first candidate PDCCH can be allocated before a second candidate PDCCH. In some implementations, if the DCI format associated with the first candidate PDCCH and the DCI format associated with the second candidate PDCCH have the same size, the UE can receive both the first and second candidate PDCCHs on the same set of CCEs, or / and if the first and second candidate PDCCHs have the same scrambling code, the UE can monitor only the first candidate PDCCH. In some implementations, the first candidate PDCCH may always correspond to the lowest SSID.

[0265] In some implementations, if the UE has configured a first PDCCH monitoring timing 604, the UE may monitor only the first PDCCH monitoring timing 604 if one or more of the following conditions are met. Otherwise, the UE may not monitor the first PDCCH monitoring timing 604. In some implementations, when the UE is in the RRC_INACTIVE state, the UE may monitor only the first PDCCH monitoring timing 604. In some implementations, when an SDT procedure (e.g., an RA-based and / or CG-based SDT procedure) is in progress, the UE may monitor only the first PDCCH monitoring timing 604. In some implementations, after configuring / starting a CG configuration, the UE may monitor only the first PDCCH monitoring timing 604. In some implementations, the UE may monitor only the first PDCCH monitoring timing 604 only after the start of the SDT transmission period. In some implementations, when the UE has at least one valid CG configuration, the UE may monitor only the first PDCCH monitoring timing 604. In some implementations, when a CG resource / configuration is considered valid, the UE may monitor only the first PDCCH monitoring timing 604.

[0266] In some implementations, after the UE initiates an SDT procedure (e.g., an SDT procedure based on RA and / or CG), the UE can only monitor the first PDCCH monitoring moment 604. In some implementations, after the UE determines that the contention for the RA procedure has been successfully resolved, the UE may only monitor the first PDCCH monitoring moment 604. In some implementations, after the UE determines that the RA procedure has been successfully completed, the UE may only monitor the first PDCCH monitoring moment 604. In some implementations, the UE may only monitor the first PDCCH monitoring moment 604 after the UE sends a UL message (e.g., after the UE performs an SDT on CG / DG resources, MSG3, MSGA, etc.). In some implementations, after the UE receives a response from the NW, the UE may only monitor the first PDCCH monitoring moment 604.

[0267] In some implementations, when the timer / window (e.g., from...) Figure 5 For example, in alternative solution 504, the timer / window used to control and monitor the PDCCH comes from... Figure 5For example, when the DRX timer used for SDT in alternative scheme 506 is running, the UE can only monitor the first PDCCH monitoring opportunity 604. In some implementations, regardless of whether CG configuration / PDCCH configuration is provided, the UE may only monitor the first PDCCH monitoring opportunity 604 before moving to another cell. In some implementations, for a UE in an RRC inactive state, the UE may only monitor the first PDCCH monitoring opportunity 604 when or after determining the maximum number of candidate PDCCHs monitored per time slot.

[0268] In some embodiments of this application, SDT transmission can be DL and / or UL data transmission. In some embodiments, DRB may be associated with LCH. DRB(s), LCH(s), and / or LCG(s) can be configured (specifically) for SDT. For example, the UE can receive configuration via RRC release message to indicate whether DRB(s), LCH(s), and / or LCH(s) can be used for SDT. In some embodiments, DRB / LCH configured for SDT may not be suspended when the UE is in RRC_INACTIVE state. In some embodiments, DRB / LCH configured for SDT may be resumed when the SDT procedure is initiated.

[0269] Figure 7 A flowchart illustrating a method or process for monitoring PDCCH during the SDT process according to one of the exemplary embodiments of this application is shown. Figure 7As shown, in action 704, when the UE is in the RRC_CONNECTED state, procedure 700 can be initiated by receiving an RRC release message containing SDT configuration from the BS. Upon receiving the RRC release message, in action 706, in response to the received RRC release message, the UE may transition to the RRC_INACTIVE state. In action 708, the UE can initiate an SDT procedure based on the SDT configuration. In some implementations, when the SDT procedure includes a Random Access (RA) based SDT procedure, the search space (SS) set may include a common search space (CSS) set. In some implementations, when the SS set includes a CSS set, the SDT SS can be configured via the PDCCH common configuration IE (e.g., PDCCH-ConfigCommon). In some implementations, when the SS set includes a CSS set, the SDT SS can be configured via the IE sdt-SearchSpace. In some implementations, when the SDT procedure includes a Configuration Authorization (CG) based SDT procedure, the SS set may include a UE-specific search space (USS) set. In some implementations, when the SS set includes a USS set, the SDT SS can be configured via the PDCCH configuration IE (e.g., PDCCH-config) received in the RRC release message. In some implementations, when the SDT procedure includes a CG-based SDT procedure, the SS may be a USS(s) configured by the IE sdt-CG-SearchSpace. In some implementations, when the SDT procedure includes a CG-based SDT procedure, the SS may be a USS(s) configured in the CG configuration of the SDT. In some implementations, when the SDT procedure includes a CG-based SDT procedure, the SS may be a USS(s) configured in a BWP specifically configured for the SDT.

[0270] After initiating the SDT procedure, in action 710, the UE can determine whether it has received the SS set associated with the SDT SS from the BS. In some implementations, if the UE determines in action 710 that it has not received the SS set associated with the SDT SS from the BS, then process 700 can subsequently terminate. However, in some implementations, after process 700 determines that it has not received the SS set associated with the SDT SS from the BS and determines that the SDT procedure includes an RA-based SDT procedure, the procedure can monitor the PDCCH by monitoring the common SS set associated with the RA SS during the SDT procedure.

[0271] In some implementations, after initializing the SDT procedure in action 708, if in action 710 the process determines that a set of SS associated with the SDT SS has been received from the base station BS, the UE can monitor the PDCCH in action 712, for example, by monitoring the set of SS associated with the SDT SS during the SDT procedure. The process may then end.

[0272] In some implementations, during the SDT process, after the UE monitors the SS set, the UE may need to further determine whether the SDT process includes a RA-based SDT process or a CG-based SDT process.

[0273] In some implementations, if the UE determines that the SDT procedure includes an RA-based SDT procedure, the UE may monitor the PDCCH, for example, after determining that the RA procedure has been successfully completed and until the RA-based SDT procedure terminates. In some implementations, if the UE determines that the SDT procedure includes an RA-based SDT procedure, the UE may monitor the PDCCH addressing the cell-radio network temporary identifier (C-RNTI).

[0274] In some implementations, if the UE determines that the SDT procedure includes a CG-based SDT procedure, the UE may monitor the PDCCH after the initial transmission for the CG-based SDT procedure until the CG-based SDT procedure terminates. In some implementations, if the UE determines that the SDT procedure includes a CG-based SDT procedure, the UE may monitor the PDCCH addressing the cell-radio network temporary identifier (C-RNTI).

[0275] In some embodiments of this application, reference is made to Figure 1-7 The methods and functions described can be implemented by nodes, such as Figure 8 Node 800 is shown in the diagram. Figure 8 A block diagram of a node 800 for wireless communication according to an exemplary embodiment of this application is shown. Figure 8 As shown, node 800 may include a transceiver 820, a processor 826, a memory 828, one or more presentation components 834, and at least one antenna 836. Node 800 may also include a radio frequency (RF) band module, a base station communication module, a network communication module and a system communication management module, input / output (I / O) ports, I / O components, and a power supply (not shown in the diagram). Figure 8 As clearly shown in the document, the components can communicate directly or indirectly with each other via one or more buses 838.

[0276] Transceiver 820 has a transmitter 822 and a receiver 824, and can be configured to transmit and / or receive time and / or frequency resource allocation information. In some embodiments, transceiver 820 can be configured to transmit in different types of subframes and time slots, including, but not limited to, available, unavailable, and flexibly usable subframe and time slot formats. Transceiver 820 can be configured to receive data and control signaling.

[0277] Node 800 may include a variety of computer-readable media. Computer-readable media may be any available media accessible by Node 800, and includes volatile and non-volatile media, removable and non-removable media. As a non-limiting example, computer-readable media may include computer storage media and communication media. Computer storage media may include volatile and non-volatile, removable and non-removable media, implemented in any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data.

[0278] Computer storage media may include RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Versatile Disk (DVD) or other optical disc storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Computer storage media does not include transmitted data signals. Communication media can generally be embodied as computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves or other transmission mechanisms), and includes any information transmission medium. The term "modulated data signal" can indicate that one or more characteristics of this signal are set or altered to encode data into this signal. By way of example and not limitation, communication media includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0279] Memory 828 may comprise a computer storage medium in the form of volatile and / or non-volatile memory. Memory 828 may be removable, non-removable, or a combination thereof. Exemplary memory may include solid-state memory, hard disk, optical disk drive, etc. As shown in Figure 8, memory 828 may store computer-readable, computer-executable instructions 832 (e.g., software code) configured to, when executed, cause processor 826 to perform various functions described herein, for example, referencing Figures 1 to 7 Alternatively, instruction 832 may not be executed directly by processor 826, but may be configured to cause node 800 (e.g., when compiled and executed) to perform the various functions described herein.

[0280] Processor 826 may include intelligent hardware devices, such as a central processing unit (CPU), microcontroller, ASIC, etc. Processor 826 may include memory. Processor 826 can process data 830 and instructions 832 received from memory 828, and information transmitted via transceiver 820, baseband communication module, and / or network communication module. Processor 826 can also process information to be transmitted to transceiver 820 for transmission via antenna 836, and to network communication module for transmission to the core network.

[0281] One or more presentation components 834 may present data indications to a person or other device. Exemplary one or more presentation components 834 include display devices, speakers, printing components, vibrating components, etc.

[0282] Based on the above description, various techniques can be used to implement the concepts described in this application without departing from the scope of these concepts. Furthermore, although these concepts have been specifically described with reference to certain embodiments, those skilled in the art will recognize that changes in form and detail can be made without departing from the scope of these concepts. Therefore, the embodiments are to be considered illustrative rather than restrictive in all respects. It should be understood that this application is not limited to the specific embodiments described above, and many rearrangements, modifications, and substitutions of these embodiments are possible without departing from the scope of this application.

Claims

1. A method for user equipment (UE) to monitor the physical downlink control channel (PDCCH), characterized in that, The method includes: When the UE is in the Radio Resource Control (RRC)_CONNECTED state, it receives an RRC release message from the base station (BS) including the Small Data Transmission (SDT) configuration. In response to receiving the RRC release message, the UE transitions from the RRC_CONNECTED state to the Radio Resource Control Inactive RRC_INACTIVE state; Initiate the SDT process based on the aforementioned SDT configuration; Determine whether a search space set associated with the SDT search space has been received from the BS; and When it is determined that the search space set is received from the BS, the PDCCH is monitored by monitoring the search space set during the SDT process.

2. The method as described in claim 1, characterized in that, The method further includes: When it is determined that the search space set has not been received from the BS and the SDT procedure includes an SDT procedure based on random access (RA), The PDCCH is monitored during the SDT process by monitoring the set of common search spaces associated with the random access RA search space.

3. The method as described in claim 1, characterized in that, When the SDT procedure includes an SDT procedure based on Random Access RA, the search space set includes a Common Search Space (CSS) set.

4. The method as described in claim 3, characterized in that, When the search space set includes the CSS set, the SDT search space is configured through the PDCCH-ConfigCommon IE element.

5. The method as described in claim 1, characterized in that, When the SDT procedure includes an SDT procedure based on random access (RA), monitoring the PDCCH includes: monitoring the PDCCH after determining that the RA procedure has been successfully completed, and until the SDT procedure based on random access (RA) is terminated.

6. The method as described in claim 1, characterized in that, When the SDT procedure includes an SDT procedure based on Random Access RA, monitoring the PDCCH includes: monitoring the PDCCH addressing to the Cell Radio Network Temporary Identifier (C-RNTI).

7. The method as described in claim 1, characterized in that, When the SDT procedure includes an SDT procedure based on a configuration authorization CG, the search space set includes a UE-specific search space (USS) set.

8. The method as described in claim 7, characterized in that, When the search space set includes the USS set, the SDT search space is configured by configuring the PDCCH-Config information element IE received in the RRC release message.

9. The method as described in claim 1, characterized in that, When the SDT process includes an SDT process based on a configuration authorization CG, monitoring the PDCCH includes: monitoring the PDCCH after the initial transmission of the SDT process based on the configuration authorization CG, and until the SDT process based on the configuration authorization CG is terminated.

10. The method as described in claim 1, characterized in that, When the SDT procedure includes an SDT procedure based on the Configuration Authorization Code (CG), monitoring the PDCCH includes: monitoring the PDCCH addressing to the Cell Radio Network Temporary Identifier (C-RNTI) and configuring the Scheduling Radio Network Temporary Identifier (CS-RNTI).

11. A user equipment (UE), characterized in that, include: One or more non-transitory computer-readable media, the one or more non-transitory computer-readable media storing computer-executable instructions for monitoring the physical downlink control channel (PDCCH); as well as At least one processor coupled to the one or more non-transitory computer-readable media, and the at least one processor being configured to execute the computer-executable instructions to: When the UE is in the Radio Resource Control (RRC)_CONNECTED state, it receives an RRC release message from the base station (BS) including the Small Data Transmission (SDT) configuration. In response to receiving the RRC release message, the UE transitions from the RRC_CONNECTED state to the Radio Resource Control Inactive RRC_INACTIVE state; Initiate the SDT process based on the aforementioned SDT configuration; Determine whether a search space set associated with the SDT search space has been received from the BS; as well as When it is determined that the search space set is received from the BS, the PDCCH is monitored by monitoring the search space set during the SDT process.

12. The UE as claimed in claim 11, characterized in that, The at least one processor is further configured to execute the computer-executable instructions to: When it is determined that the search space set has not been received from the BS and the SDT procedure includes an SDT procedure based on random access (RA), The PDCCH is monitored during the SDT process by monitoring the set of common search spaces associated with the random access RA search space.

13. The UE as claimed in claim 11, characterized in that, When the SDT procedure includes an SDT procedure based on Random Access RA, the search space set includes a Common Search Space (CSS) set.

14. The UE as claimed in claim 13, characterized in that, When the search space set includes the CSS set, the SDT search space is configured through the PDCCH-ConfigCommon IE element.

15. The UE as claimed in claim 11, characterized in that, When the SDT procedure includes an SDT procedure based on random access (RA), monitoring the PDCCH includes: monitoring the PDCCH after determining that the RA procedure has been successfully completed, and until the SDT procedure based on random access (RA) is terminated.

16. The UE as claimed in claim 11, characterized in that, When the SDT procedure includes an SDT procedure based on Random Access RA, monitoring the PDCCH includes: monitoring the PDCCH addressing to the Cell Radio Network Temporary Identifier (C-RNTI).

17. The UE as claimed in claim 11, characterized in that, When the SDT procedure includes an SDT procedure based on a configuration authorization CG, the search space set includes a UE-specific search space (USS) set.

18. The UE as claimed in claim 17, characterized in that, When the search space set includes the USS set, the SDT search space is configured by configuring the PDCCH-Config information element IE received in the RRC release message.

19. The UE as claimed in claim 11, characterized in that, When the SDT process includes an SDT process based on a configuration authorization CG, monitoring the PDCCH includes: monitoring the PDCCH after the initial transmission of the SDT process based on the configuration authorization CG, and until the SDT process based on the configuration authorization CG is terminated.

20. The UE as claimed in claim 11, characterized in that, When the SDT procedure includes an SDT procedure based on the Configuration Authorization Code (CG), monitoring the PDCCH includes: monitoring the PDCCH addressing to the Cell Radio Network Temporary Identifier (C-RNTI) and configuring the Scheduling Radio Network Temporary Identifier (CS-RNTI).

Images