Patent Description:
With the tremendous growth in the number of connected devices and the rapid increase in user/Network (NW) traffic volume, various efforts have been made to improve different aspects of wireless communication for next-generation wireless communication systems, such as the fifth-generation (<NUM>) New Radio (NR), by improving data rate, latency, reliability, and mobility.

The <NUM> NR system is designed to provide flexibility and configurability to optimize the NW services and types, accommodating various use cases such as Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC).

However, as the demand for radio access continues to increase, there is a need in the art to improve small data transmission.

<CIT> discusses a method for wireless communication by a base station, comprising: receiving a paging indication and at least an indication of a limited amount of data targeted for a user equipment (UE) that is not in a connected state with the base station transmitting a paging message to the UE with at least one of the data or an indication of the data; and monitoring for a physical random access channel (PRACH) transmission from the UE as an acknowledgment of receipt of the data.

<NPL>, discusses small data transmission, requirements, user cases and scenarios.

The above and other objects are achieved by a method performed by a User Equipment (UE) for small data transmission and a UE as defined in the independent claims, respectively.

Aspects of the present disclosure are best understood from the following when read with the accompanying figures. Various features are not drawn to scale. Dimensions of various features may be arbitrarily increased or reduced for clarity of discussion.

The following contains specific information pertaining to exemplary implementations in the present disclosure. The drawings and their accompanying detailed disclosure are directed to merely exemplary implementations. However, the present disclosure is not limited to merely these exemplary implementations. Other variations and implementations of the present disclosure will occur to those skilled in the art. Unless noted otherwise, like or corresponding elements among the figures may be indicated by like or corresponding reference numerals.

The following contains specific information pertaining to example implementations in the present disclosure. The drawings and their accompanying detailed disclosure are directed to merely example implementations. However, the present disclosure is not limited to merely these example implementations. Other variations and implementations of the present disclosure will occur to those skilled in the art. Unless noted otherwise, like or corresponding elements among the figures may be indicated by like or corresponding reference numerals.

For consistency and ease of understanding, like features are identified (although, in some examples, not illustrated) by numerals in the example figures. However, the features in different implementations may differ in other respects, and thus shall not be narrowly confined to what is illustrated in the figures.

References to "one implementation," "an implementation," "example implementation," "various implementations," "some implementations," "implementations of the present disclosure," etc., may indicate that the implementation(s) of the present disclosure may include a particular feature, structure, or characteristic, but not every possible implementation of the present disclosure necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase "in one implementation," "in an example implementation," or "an implementation," do not necessarily refer to the same implementation, although they may. Moreover, any use of phrases like "implementations" in connection with "the present disclosure" are never meant to characterize that all implementations of the present disclosure must include the particular feature, structure, or characteristic, and should instead be understood to mean "at least some implementations of the present disclosure" includes the stated particular feature, structure, or characteristic. The term "coupled" is defined as connected, whether directly or indirectly through intervening components, and is not necessarily limited to physical connections. The term "comprising," when utilized, means "including, but not necessarily limited to"; it specifically indicates open-ended inclusion or membership in the so-disclosed combination, group, series, and the equivalent.

The term "and/or" herein is only an association relationship for describing associated objects, and represents that three relationships may exist. For example, A and/or B may represent that: A exists alone, A and B exist at the same time, and B exists alone. "A and/or B and/or C" may represent that at least one of A, B and C exists. In addition, the character "/" used herein generally represents that the former and latter associated objects are in an "or" relationship.

Additionally, for the purpose of non-limiting explanation, specific details, such as functional entities, techniques, protocols, standards, and the like, are set forth for providing an understanding of the disclosed technology. In other examples, a detailed disclosure of well-known methods, technologies, systems, architectures, and the like are omitted in order not to obscure the present disclosure with unnecessary details.

Persons skilled in the art will immediately recognize that any NW function(s) or algorithm(s) in the present disclosure may be implemented by hardware, software, or a combination of software and hardware. Disclosed functions may correspond to modules that may be software, hardware, firmware, or any combination thereof. The software implementation may comprise computer-executable instructions stored on computer-readable media such as memory or other types of storage devices. For example, one or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and carry out the disclosed NW function(s) or algorithm(s). The microprocessors or general-purpose computers may be formed of Application-Specific Integrated Circuits (ASICs), programmable logic arrays, and/or using one or more Digital Signal Processor (DSPs). Although some of the example implementations in the present disclosure are directed to software installed and executing on computer hardware, alternative example implementations implemented as firmware, as hardware, or as a combination of hardware and software are well within the scope of the present disclosure.

The computer-readable medium includes but is 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 cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

A radio communication NW architecture (e.g., a Long Term Evolution (LTE) system, an LTE-Advanced (LTE-A) system, or an LTE-Advanced Pro system) typically includes at least one Base Station (BS), at least one user equipment (UE), and one or more optional NW elements that provide connection towards an NW. The UE communicates with the NW (e.g., a Core NW (CN), an Evolved Packet Core (EPC) NW, an Evolved Universal Terrestrial Radio Access NW (E-UTRAN), a Next-Generation Core (NGC), or an Internet), through a Radio Access NW (RAN) established by the BS.

It should be noted that, in the present disclosure, a UE may include, but is not limited to, a mobile station, a mobile terminal or device, or a user communication radio terminal. For example, a UE may be a portable radio equipment, which includes, but is not limited to, a mobile phone, a tablet, a wearable device, a sensor, or a Personal Digital Assistant (PDA) with wireless communication capability. The UE is configured to receive and transmit signals over an air interface to one or more cells in a RAN.

A BS may include, but not limited to, a Node B (NB) as in the Universal Mobile Telecommunication System (UMTS), an evolved Node B (eNB) as in the LTE-A, a Radio NW Controller (RNC) as in the UMTS, a Base Station Controller (BSC) as in the Global System for Mobile communications (GSM)/GSM EDGE Radio Access NW (GERAN), a Next Generation eNB (ng-eNB) as in an E-UTRA BS in connection with the 5GC, a next-generation Node B (gNB) as in the <NUM> Access NW (<NUM>-AN), and any other apparatus capable of controlling radio communication and managing radio resources within a cell. The BS may connect to serve the one or more UEs through a radio interface to the NW.

A BS may be configured to provide communication services according to at least one of the following Radio Access Technologies (RATs): Worldwide Interoperability for Microwave Access (WiMAX), GSM (often referred to as <NUM>), GERAN, General Packet Radio Service (GPRS), UMTS (often referred to as <NUM>) based on basic Wideband-Code Division Multiple Access (W-CDMA), High-Speed Packet Access (HSPA), LTE, LTE-A, enhanced LTE (eLTE), NR (often referred to as <NUM>), and LTE-A Pro. However, the scope of the present disclosure should not be limited to the protocols previously disclosed.

The BS may be operable to provide radio coverage to a specific geographical area using a plurality of cells included in the RAN. The BS may support the operations of the cells. More specifically, each cell (often referred to as a serving cell) may provide services to serve one or more UEs within its radio coverage, (e.g., each cell schedules the Downlink (DL) and optionally UL resources to at least one UE within its radio coverage for DL and optionally Uplink (UL) packet transmissions). The BS may communicate with one or more UEs in the radio communication system through the plurality of cells. A cell may allocate sidelink (SL) resources for supporting proximity service (ProSe). Each cell may have overlapped coverage areas with other cells. In Multi-RAT Dual Connectivity (MR-DC) cases, the primary cell of a Master Cell Group (MCG) or a Secondary Cell Group (SCG) may be called as a Special Cell (SpCell). A Primary Cell (PCell) may refer to the SpCell of an MCG. A PSCell may refer to the SpCell of an SCG. MCG refers to a group of serving cells associated with the Master Node (MN), including the SpCell and optionally one or more secondary cells (SCells). SCG refers to a group of serving cells associated with the Secondary Node (SN), including the SpCell and optionally one or more SCells.

As previously disclosed, the frame structure for NR is to support flexible configurations for accommodating various next-generation (e.g., <NUM>) communication requirements, such as eMBB, mMTC, and URLLC, while fulfilling high reliability, high data rate, and low latency requirements. The orthogonal frequency-division multiplexing (OFDM) technology, as agreed in the <NUM>rd Generation Partnership Project (3GPP), may serve as a baseline for an NR waveform. The scalable OFDM numerology, such as the adaptive sub-carrier spacing, the channel bandwidth, and the cyclic prefix (CP), may also be used. Additionally, two coding schemes are considered for NR: (<NUM>) low-density parity-check (LDPC) code and (<NUM>) polar code. The coding scheme adaption may be configured based on the channel conditions and/or service applications.

Moreover, it is also considered that in a transmission time interval of a single NR frame, at least DL transmission data, a guard period, and UL transmission data should be included, where the respective portions of the DL transmission data, the guard period, and the UL transmission data should also be configurable, for example, based on the NW dynamics of NR. In addition, SL resources may also be provided in an NR frame to support ProSe services.

Hereinafter, some descriptions are disclosed for specific terms presented in the following paragraphs:.

Specifically, small data transmission in an inactive state was approved to be a new Release <NUM> (Rel-<NUM>) work item (WI) for NR in RAN work group (WG) #<NUM>. It means that NR will support a UE with infrequent (periodic and/or aperiodic) data transmission in the RRC_INACTIVE state. More specifically, the UE doesn't move/switch to the RRC _CONNECTED state for UL data transmission. Therefore, the UE and/or gNB can avoid unnecessary power consumption and signaling overhead. For now, there are three features having been specified as part of Release <NUM> (Rel-<NUM>) and Release <NUM> (Rel-<NUM>), e.g., <NUM>-step, <NUM>-step RACH procedure and configured grant type-<NUM>. This WI builds on these features to enable small data transmission in the RRC_INACTIVE state for NR.

In some implementations, the gNB may not schedule any resources for devices in the RRC_IDLE or the RRC_INACTIVE state to avoid wasting resources. Therefore, in one implementation, when a device (e.g., UE) would like to connect to the gNB and initiate a data transfer, a RACH procedure may be used to connect to a cell (or a BS). Once the device has detected a cell (and camped on this cell), it may initiate the RACH procedure to access the cell. Conventionally, a four-step RACH procedure (or called <NUM>-step RACH procedure) is applied for LTE and NR, which is presented in the following <NUM> steps.

Once the RACH procedure is completed, the device is in the RRC_CONNECTED state and a gNB-device communication could start by using scheduling-based transmission.

In Rel-<NUM>, a two-step RACH procedure (or called <NUM>-step RACH procedure) is discussed in 3GPP to reduce the latency and the overhead of the conventional <NUM>-step RACH procedure. The <NUM>-step RACH procedure may also be beneficial for small data transmission. Please refer to <FIG>, which illustrates a <NUM>-step RACH procedure to be formed by a <NUM>-step RACH procedure according to an example implementation of the present disclosure. In some embodiments, as shown in <FIG>, some steps of the <NUM>-step RACH procedure are merged to form the <NUM>-step RACH procedure, so that it may efficiently save, e.g., the number of transmissions. Specifically, Msg-<NUM> may be combined with Msg-<NUM> to form the Msg-A in the <NUM>-step RACH procedure, and Msg-<NUM> may be combined with Msg-<NUM> to form the Msg-B in the <NUM>-step RACH procedure. Note that RA response(s) included in a Msg-B may be different from RA response(s) included in a Msg-<NUM>.

Since there are more and more small and infrequent types of data traffic, such as traffic from instant message services, traffic from wearables, traffic from smart meters, and so on, signaling overhead has become an important issue. It influences not only network performance/efficiency but also UE battery life, so it is required to support small data transmission for a UE being operated in the RRC_INACTIVE state before switching to the RRC_CONNECTED state.

In some embodiments, it is disclosed that small data transmission may be performed via <NUM>-step RACH procedure, <NUM>-step RACH procedure, or pre-configured PUSCH resources (e.g., by providing configured grant type1 configuration) for a UE in the RRC_INACTIVE state, rather than in the RRC_CONNECTED state, to avoid unnecessary signal overhead and power consumption. Accordingly, several fundamental problems need to be solved in order to support the small data transmission in the RRC_INACTIVE state.

For the first problem, if the small data transmission is infrequently performed via <NUM>-step RACH procedure, <NUM>-step RACH procedure, and/or configured grant type <NUM>, it may be important how the gNB can identify that the received data are the infrequent small data or other scheduled data (e.g., small data or an RRC message being carried in Msg-A and Msg-<NUM>).

In some embodiments, for the <NUM>-step RACH procedure and the <NUM>-step RACH procedure of NR, the UE may move/switch to the RRC_CONNECTED state after completing the RACH procedure. However, the main motivation of small data transmission is to have the UE transmit a small size payload in the RRC_INACTIVE state without switching to the RRC_CONNECTED state for reducing power consumption and signaling overhead. Under such motivation, it may be necessary for the NW to identify whether the current received data is for small data transmission or for a scheduled RACH procedure.

For the second problem, it may be important to determine a mechanism for informing the UE whether small data transmission has been successfully decoded at the gNB side. In some implementations, as performed by the common RACH procedure, the UE may be operated in the RRC _CONNECTED state when it receives successRAR in the <NUM>-step RACH procedure or Msg-<NUM> (contention resolution) in the <NUM>-step RACH procedure. Similarly, as being operated for the small data transmission, an indicator may also be needed to inform the UE that the transmission is successful. Thus, the mechanism may be introduced in the following paragraphs how to inform the UE that the small data transmission has been successfully decoded at the gNB side.

Therefore, there are two fundamental issues, e.g., (<NUM>) how to identify the RRC message (e.g., RACH transmission/data transmission) and the small data transmission, and (<NUM>) how to form the mechanism for informing the UE that the small data transmission has been completed, which is disclosed in the following paragraphs.

In some implementations, the NW may configure dedicated physical resources (e.g., time, frequency, code, preambles, RACH occasion (RO), or PUSCH occasion (PO), which is not limited to hereinafter) for small data transmission to UEs (e.g., via dedicated signaling or via broadcasting system information). In one implementation, the NW may schedule a dedicated RO for small data transmission to the UEs and inform the UEs that there is a dedicated RO for small data transmission via broadcasting system information (SI). Then the UE performing small data transmission may pick up the preamble in that dedicated RO used for small data transmission to send to the gNB, so as to start small data transmission.

In some implementations, the NW may configure dedicated preambles for small data transmission (e.g., via dedicated signaling or via broadcasting system information). In some implementations, dedicated RA resource(s) may be provided in the RRC Release message (e.g., an RRC Release message with/without suspend configuration) to the UE for transmitting (small) data in the RRC_INACTIVE state. The dedicated RA resource(s) may be dedicated preambles, dedicated ROs, and/or a dedicated PUSCH resource (e.g., the payload part of a Msg-A). For dedicated preambles, these preambles may be obtained from all used preambles in NR, and these preambles may only be used for small data transmission. In some implementations, preambles may be shared for different purposes, such as small data transmission, <NUM>-step RACH procedure, <NUM>-step RACH procedure, and so on. For example, the gNB may schedule some preambles, e.g., preamble#<NUM> to preamble#<NUM> in the <NUM> preambles, to be used for both <NUM>-step RACH procedure (e.g., for RRC connection setup or resume) and for small data transmission via <NUM>-step RACH procedure at the same RO. In some implementations, if a shared preamble is selected, the associated PUSCH may carry some information to assist the gNB for identifying whether the purpose is for small data transmission via <NUM>-step RACH procedure or RRC connection setup/resume via <NUM>-step RACH procedure. If a shared preamble is picked up to use for RRC connection setup/resume via <NUM>-step RACH procedure, <NUM>-step RACH procedure defined in Rel-<NUM> may be triggered (e.g., as introduced in 3GPP Technical Specification (TS) <NUM>).

In some implementations, a dedicated group of preambles may be configured for the purpose of small data transmission. A UE who intends to transmit small data in the RRC_INACTIVE state may use the dedicated group of preambles to indicate that the purpose of an initiated RACH procedure is for small data transmission.

In some implementations, the NW may provide pre-configured PUSCH resources for the UE to transmit small data in the RRC_INACTIVE state. In some implementations, the configured grant scheduled by the NW may only be used for small data transmission. In some implementations, the configured grant assigned by the NW is used for not only small data transmission but also for other data transmission (e.g., Ultra Reliable Low Latency Communication (URLLC) data transmission).

In some implementations, a unique UE identity (e.g., Inactive-RNTI (I-RNTI) or <NUM> S-Temporary Mobile Subscription Identifier (<NUM>-S-TMSI)) or related UE identity information may be used to identify whether the received data at the gNB side is associated with small data transmission or not. For example, if the gNB identifies that an I-RNTI is included in the content of received data, the current received data may be considered as small data. In some implementations, for (small) data transmission in the RRC_INACTIVE state via the <NUM>-step RACH procedure, a UE may include an I-RNTI MAC CE in the payload of a Msg-A. In some implementations, for (small) data transmission in the RRC_INACTIVE state via the <NUM>-step RACH procedure, a UE may include an I-RNTI MAC CE in a Msg-<NUM>. In some implementations, for (small) data transmission in the RRC_INACTIVE state via pre-configured PUSCH resources, a UE may include an I-RNTI MAC CE in the selected PUSCH resources for data transmission. In some implementations, an I-RNTI MAC CE may be identified by a MAC subheader with a specific Logical Channel Identifier (LCID). In some implementations, an I-RNTI MAC CE may have an ID field to indicate a UE's fullI-RNTI. In some implementations, an I-RNTI MAC CE may have an ID field to indicate a UE's shortI-RNTI. In some implementations, an I-RNTI MAC CE for fullI-RNTI may be identified by a MAC subheader with a specific LCID (e.g., <NUM>) and another I-RNTI MAC CE for shortI-RNTI may be identified by a MAC subheader with another LCID (e.g., <NUM>). In some implementations, whether to include an I-RNTI MAC CE for fullI-RNTI or an I-RNTI MAC CE for shortI-RNTI may be determined based on the NW's commands (e.g., via dedicated signaling or SI).

In some implementations, the gNB may send the Acknowledgement (ACK) indicator to the UE to inform the UE that the data transmitted in the RRC_INACTIVE state is decoded/received successfully. In some implementations, when the UE receives the ACK indicator associated with the small data transmitted in the RRC_INACTIVE state, the UE may consider that the (small) data transmission is successful and no re-transmission of the (small) data may be required. In some implementations, the gNB may send the ACK indicator and the new configurations (e.g., RRC Release with suspendConfig) to the UE to inform the UE that the data transmitted in the RRC_INACTIVE state is decoded/received successfully. In some implementations, when the UE receives the ACK indicator associated with the small data transmitted in the RRC_INACTIVE state and the new configurations, the UE may consider that the (small) data transmission is successful and apply the new configuration for the RRC_INACTIVE state.

In some implementations, the RRCResumeRequest message may be transmitted in Msg-A (of a <NUM>-step RACH procedure) or in Msg-<NUM> (of a <NUM>-step RACH procedure) with a new Resume Cause as small data transmission to inform the NW. The NW may send the RRC Release with suspendConfig to the UE if the Resume Cause is "small data transmission".

In some implementations, if the UE has one or more small data for transmitting to the gNB or the PUSCH resource cannot accommodate the small data, the UE may request an additional UL grant for another small data transmission or the remaining data transmission. For example, the UE may inform the NW that it has other incoming small data packets in the <NUM>-step RACH Msg-A PUSCH via MAC CE or RRC message.

In some implementations, in response to the request of an additional UL grant by the UE, the gNB may send an existing RAR with modification (e.g., using the reserved bits in the existing MAC RAR (or RAR payload) to inform the UE that the scheduled UL grant given to the UE via that MAC RAR (or RAR payload) is used for the new data transmission, the data retransmission, or the remaining data transmission of a small data transmission). In some implementations, the gNB may use a new MAC RAR (or RAR payload) for the UE to send another small data packet or the remaining data. Noticeably, in some implementations, a MAC Packet or Protocol Data Unit (PDU) (of Msg-B) may include one or more MAC subPDUs and optional padding. In one implementation, each MAC subPDU includes one of the following:.

In some implementations, the gNB may use fallbackRAR to schedule the additional UL grant for a UE, so as to transmit the next small data or the remining data. Please refer to <FIG>, which illustrates a fallback RAR format <NUM> according to an example implementation of the present disclosure. In one implementation, as shown in <FIG>, the fallback RAR format <NUM> may include the following fields:.

In some implementations, the reserved bit may be used to indicate the type of data transmitted in the UL grant (indicated in UL grant field). In some implementations, the type of data transmission may be the new data transmission (e.g., for next small data or other part of remaining data), previous small data retransmission, or common <NUM>-step/<NUM>-step RACH data transmission (e.g., Msg-A payload retransmission), which is not limited hereinafter.

In some implementations, the gNB may use successRAR to schedule the additional UL grant for a UE to transmit the next small data transmission or the remaining data of a small data transmission. Please refer to <FIG>, which illustrates a success RAR (successRAR) format <NUM> according to an example implementation of the present disclosure. In one implementation, as shown in <FIG>, the success RAR format <NUM> may include the following fields:.

In some implementations, the UL grant field may be included in a success RAR to schedule additional UL grant for new data transmission (e.g., for the next small data or the remaining data of a small data transmission). In some implementations, whether the UL grant field may be present in a success RAR may depend on the notification from the UE. For example, a UE who requests an additional UL grant in the first PUSCH resource (e.g., in the PUSCH of Msg-A or Msg-<NUM>) may determine that the UL grant field exists if the received UE Contention Resolution Identity field matches the CCCH SDU. In some implementations, the reserved bit(s) in the subheader of a success RAR may be utilized to indicate whether the associated success RAR includes a UL grant field. Please refer to <FIG>, which illustrates a success RAR MAC subheader format <NUM> according to an example implementation of the present disclosure. In one implementation, as shown in <FIG>, the success RAR MAC subheader format <NUM> may include the following fields:.

In some implementations, the gNB may provide the UL grant to the UE via a new DCI format (or an existing DCI format with different field descriptions) which may be scrambled with I-RNTI, <NUM>-S-TMSI, or the new RNTI related to small data transmission, but is not limited thereto. In some implementations, after receiving a success RAR associated with the sent preamble, a UE may start monitoring a Control Resource Set#<NUM> (CORESET#<NUM>) (or other configured CORESET) addressed to C-RNTI (or I-RNTI). If no DCI can be received in a timer period, the UE may determine that the <NUM>-step RACH procedure is finished and remains in the RRC_INACTIVE state. The UE may stop monitoring the CORESET#<NUM> (or other configured CORESET) addressed to C-RNTI (or I-RNTI).

In some implementations, if a UE has no more small data to transmit, the UE may send an indication or information (e.g., in an RRC message, a MAC CE, or a DCI) which is used to inform the gNB that the UE doesn't need further resources to transmit (small) data. In some implementations, the UE may set a new resumeCause in an RRC Resume Request message. For example, the UE may set the resumeCause as small data transmission, carried in the RRCResumeRequest or RRCResumeRequest1 to inform the gNB (or cell) that the transmission purpose is for small data transmission. In some implementations, the gNB may send the RRC Release with suspendConfig to the UE. In some implementations, the gNB may send the new configuration to the UE for the following (small) data transmission.

In some implementations, several new RRC parameters may be used for small data transmission. For example, the new RRC parameter may represent for the preamble group used for small data transmission, for the number of RO and PO used for small data transmission, or for the number of preambles used for small data transmission.

In some implementations, the transmitted small data may carry the I-RNTI of the UE for the purpose of UE/device identification, where the I-RNTI may include, e.g., fullI-RNTI and/or shortI-RNTI. In some implementations, fullI-RNTI may be used for small data transmission to identify the UE/device. In some implementations, shortI-RNTI may be used for small data transmission to identify the UE/device. In some implementations, if field useFullResumeID is signaled in SIB <NUM>, fullI-RNTI may be used for small data transmission to identify the UE/device; otherwise, shortI-RNTI may be used for small data transmission to identify the UE/device.

In some implementations, the NW may broadcast a threshold for the UE to determine whether it can transmit data in the RRC_INACTIVE state. In some implementations, the threshold may be Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Received Signal Strength Indication (RSSI), layer <NUM> buffer size, transmitted payload size, or type of radio bearer (e.g., signaling radio bearer, data radio bearer), but is not limited thereto. In some implementations, the UE may determine whether to perform small data transmission when a measured RSSI value is larger than a broadcast RSSI threshold value of a <NUM>-step RACH procedure.

At the UE side, the upper layer (e.g., MAC entity) of the UE may need to decide that the current transmission is for small data transmission via <NUM>-step/<NUM>-step RACH procedure or for connection setup/resume via <NUM>-step/<NUM>-step RACH procedure. In some implementations, the upper layer of the UE may decide whether the transmitted data is small data or not according to the transmitted bits in the PUSCH. If the transmitted data is not small data, the UE may need to ask for connection setup/resume to switch to RRC_CONNECTED state. For example, in some implementations, if the transmitted bits are smaller than K bits (e.g., the number K may be signaled to the UE via RRC message(s) (or dedicated signaling) or pre-configured/pre-defined, but is not limited thereto), it may be determined as small data transmission. If the number of transmitted bits is larger than K bits, the upper layer of the UE may trigger the <NUM>-step RACH procedure or <NUM>-step RACH procedure to have the UE switch to the RRC _CONNECTED state for the data transmission. For example, if K is pre-defined to be <NUM> and the UE needs to transmit <NUM> bits, the upper layer of the UE may determine the current transmission as small data transmission. The upper layer of the UE may pick up the dedicated preambles used for small data transmission to inform the lower layer (e.g., physical layer) to send to the gNB if there are dedicated preambles used for small data transmission. Next, the UE may start RACH-based small data transmission. If there are no dedicated preambles, the upper layer of UE may randomly select one preamble to require the lower layer to send to the gNB, and accordingly, the UE may put some information in Msg-A/Msg-<NUM> PUSCH to inform the gNB that the purpose of current transmission is for small data transmission. In some implementations, the NW may not allow the multiplexing between data radio bearer (DRB) and signal radio bearer (SRB) in the RRC_INACTIVE state. In some implementations, the NW may allow the multiplexing between data radio bearer (DRB) and signal radio bearer (SRB) in the RRC_INACTIVE state.

In some implementations, the upper layer may determine whether to trigger small data transmission based on the type of radio bearer (e.g., SRB or DRB) in the RRC_INACTIVE state if the multiplexing of signal radio bearer (SRB) and DRB is not allowed. For example, if the type of radio bearer is data radio bearer (DRB), the upper layer of UE may trigger small data transmission. In some implementations, the multiplexing between DRB and SRB is allowed in the RRC_INACTIVE state, and the upper layer of UE may trigger the small data transmission based on the number of transmitted bits. For example, if the number of transmitted bits is larger than Q bits (the number of Q may be signaled to the UE via RRC message(s) (or dedicated signaling) or be pre-configured/pre-defined, but is not limited thereto), the upper layer of UE may trigger small data transmission.

In some implementations, the NW may inform UEs whether the NW enables the capability of small data transmission. In some implementations, the NW may transmit the RRC message, dedicated signaling and/or broadcast SI to inform the UE whether the UE is allowed to transmit data in the RRC_INACTIVE state.

In the current invention, the RAR carries the ACK indicator to inform the UE that the gNB has successfully received the data. In some implementations, a new RAR may be used to indicate to the UE that the small data transmission is completed. Please refer to <FIG>, which illustrates a new RAR format <NUM> according to an example implementation of the present disclosure. In one implementation, the new RAR format for small data transmission ACK indicator may include the following fields:.

In some implementations, the existing RARs may be reused with some modification to indicate to the UE that the small data transmission is completed. For example, the successRAR may be reused to indicate to the UE that the small data transmission is completed by using one reserved bit to be the ACK indicator. Please refer to <FIG>, which illustrates a modified successRAR format <NUM> according to an example implementation of the present disclosure. In one implementation, the modified successRAR format <NUM> for small data transmission with ACK indicator may include the following fields:.

In some implementations, the RNTI, e.g., I-RNTI, RA-RNTI, TC-RNTI, or other new RNTI which is dedicatedly used for small data transmission, may be used to indicate whether the current procedure is for small data transmission. In some implementations, the NW may use the implicit way to inform the UE that the data is successfully received at the gNB side. For example, if the UE can successfully decode PDCCH by I-RNTI or the new RNTI that is dedicatedly used for small data transmission, the UE may consider that the gNB has successfully received the data.

In some implementations, the new RAR may be used to indicate to the UE to transmit previous data (e.g., retransmitted data) or new data (e.g., the other part of the full data that UE wants to send to the NW).

In some implementations, the existing RARs, e.g., fallbackRAR and/or successRAR, may be used for data re-transmission. In some implementations, the reserved bits of the existing RAR may be used for re-transmission indication. In some implementations, the reserved bits of the existing RAR may be used to indicate to the UE to transmit the other part of the full data that the UE wants to send to the NW.

In some implementations, the MAC CE of the transmitted data may carry index information for the transmitted data, which may be divided from a full data to be sent to the gNB. In some implementations, UE may use the MAC CE carried in the transmitted data to inform the gNB that the UE doesn't have another data for transmission.

In some implementations, when the UE receives the fallbackRAR, the UE may retransmit the same data (e.g., the same data of the previous small data transmission) or other new data (e.g., the new small data transmission).

In some implementations, the UE may carry the information to indicate that whether the UE needs other PUSCH resources to transmit data in the MAC CE of transmitted data. In some implementations, if the MAC CE in the transmitted data indicates that the UE needs other PUSCH resources, the gNB may send the fallbackRAR to the UE.

In some implementations, the MAC CE of the transmitted data may carry the information of the transmitted data, such as the size of the transmitted data, the index of the transmitted data, the total number of data that UE wants to send to the gNB, and so on.

In some implementations, if the UE informs the gNB that the UE has more than one data that needs to be transmitted in the on-going RACH-based small data transmission, the gNB may schedule the UL grant for the UE to send the data. In some implementations, the UL grant may be obtained from the PDCCH that is scrambled by the I-RNTI or other new RNTI used for small data transmission. In some implementations, the configured grant type1 may be scheduled to the UE via RRC messages sent by the gNB/cell if the UE informs the gNB that the UE has more than one data to be transmitted during the RACH-based small data transmission.

<FIG> illustrates a small data transmission procedure <NUM> performed by the UE according to an example implementation of the present disclosure. As illustrated in <FIG>, the small data transmission procedure <NUM> for the UE includes the following actions:.

Preferably, action <NUM> to action <NUM> of the small data transmission procedure <NUM> may be applied to the UE. Specifically, in some implementations, the UE may receive the configuration indicating a dedicated physical resource from the BS in action <NUM>. In one implementation, the dedicated physical resource may be obtained via the dedicated signaling or broadcast system information (SI). In one implementation, the dedicated physical resource may correspond to the RO, a preamble, or the PO. In one implementation, the dedicated physical resource may include the pre-configured PUSCH resource, the specific identifier, or the configured grant requested by the UE. In one implementation, the specific identifier may be the I-RNTI.

In the current invention, the small data transmission based on the dedicated physical resource in action <NUM>, where the UE is in the inactive state to perform the small data transmission. In one implementation, the UE may be in the inactive state to perform the <NUM>-step RACH procedure, the <NUM>-step RACH procedure, or a configured grant (CG) type <NUM> transmission. In one implementation, the UE may be in the connected state before receiving the pre-configured PUSCH resource.

In the current invention, the UE receives the ACK indicator indicating the successful reception of the small data transmission by the BS in action <NUM>. In the current invention, the ACK indicator is included in the RAR or may be decoded from a specific UE identifier on the PDCCH. In one implementation, the specific UE identifier may include one of the I-RNTI, the random access-RNTI (RA-RNTI) or a temporary cell-RNTI (TC-RNTI), and the RAR may include the fallbackRAR or the successRAR.

Please refer to <FIG>, which illustrates a block diagram of a node <NUM> for wireless communication according to an example implementation the present disclosure. As illustrated in <FIG>, the node <NUM> may include a transceiver <NUM>, a processor <NUM>, a memory <NUM>, one or more presentation components <NUM>, and at least one antenna <NUM>. The node <NUM> may also include a Radio Frequency (RF) spectrum band module, a BS communications module, an NW communications module, and a system communications management module, input/output (I/O) ports, I/O components, and power supply (not explicitly illustrated in <FIG>). Each of these components may be in communication with each other, directly or indirectly, over one or more buses <NUM>. In one implementation, the node <NUM> may be a UE or a BS that performs various functions disclosed herein, for example, with reference to <FIG>.

The transceiver <NUM> having a transmitter <NUM> (e.g., transmitting/transmission circuitry) and a receiver <NUM> (e.g., receiving/reception circuitry) may be configured to transmit and/or receive time and/or frequency resource partitioning information. In one implementation, the transceiver <NUM> may be configured to transmit in different types of subframes and slots, including, but not limited to, usable, non-usable and flexibly usable subframes and slot formats.

The node <NUM> may include a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by the node <NUM> and include both volatile (and non-volatile) media and removable (and non-removable) media. By way of example, and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media may include both volatile (and non-volatile) and removable (and non-removable) media implemented according to any method or technology for storage of information such as computer-readable.

Computer storage media includes RAM, ROM, EEPROM, flash memory (or other memory technology), CD-ROM, Digital Versatile Disks (DVD) (or other optical disk storage), magnetic cassettes, magnetic tape, magnetic disk storage (or other magnetic storage devices), etc. Computer storage media does not include a propagated data signal. Communication media may typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. The term "modulated data signal" may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired NW or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the previous disclosure should also be included within the scope of computer-readable media.

The memory <NUM> may include computer-storage media in the form of volatile and/or non-volatile memory. The memory <NUM> may be removable, non-removable, or a combination thereof. For example, the memory <NUM> may include solid-state memory, hard drives, optical-disc drives, etc. As illustrated in <FIG>, the memory <NUM> may store computer-executable (or readable) program <NUM> (e.g., software codes) that are configured to, when executed, cause the processor <NUM> to perform various functions disclosed herein, for example, with reference to <FIG>. Alternatively, the computer-executable program <NUM> may not be directly executable by the processor <NUM> but may be configured to cause the node <NUM> (e.g., when compiled and executed) to perform various functions disclosed herein.

The processor <NUM> (e.g., having processing circuitry) may include an intelligent hardware device, a Central Processing Unit (CPU), a microcontroller, an ASIC, etc. The processor <NUM> may include memory. The processor <NUM> may process the data <NUM> and the computer-executable program <NUM> received from the memory <NUM>, and information through the transceiver <NUM>, the baseband communications module, and/or the NW communications module. The processor <NUM> may also process information to be sent to the transceiver <NUM> for transmission through the antenna <NUM>, to the NW communications module for transmission to a CN.

One or more presentation components <NUM> may present data indications to a person or other device. Examples of presentation components <NUM> may include a display device, speaker, printing component, vibrating component, etc..

Claim 1:
A method performed by a User Equipment, UE, for small data transmission, the method comprising:
receiving (<NUM>), from a base station, BS, a configuration indicating a dedicated physical resource;
performing (<NUM>) the small data transmission based on the dedicated physical resource while the UE is in an inactive state; and
receiving (<NUM>), from the BS, an acknowledgement, ACK, indicator indicating a successful reception of the small data transmission by the BS,
wherein:
the ACK indicator is included in a random access response, RAR.