Method and apparatus for small data transmission

Abstract

The disclosure relates to a communication method and system for converging a 5th-Generation (5G) communication system and an Internet of Things (IoT) technology beyond 4th-Generation (4G) systems supporting higher data rates. The disclosure can be applied to intelligent services based on 5G communication technologies and IoT-related technologies, such as smart home, smart building, smart city, smart car, car-to-car, health care, digital education, smart retail, security and safety services. A method and apparatus for small data transmission are provided.

Description

Technical Field

[0001] This disclosure relates to wireless communication systems. More specifically, this disclosure relates to apparatus, methods, and systems for small data transmission in wireless communication systems. Background Technology

[0002] To meet the demands for wireless data transmission since the deployment of fourth-generation (4G) communication systems, efforts have been made to develop improved fifth-generation (5G) or pre-5G communication systems. 5G or pre-5G communication systems are also referred to as 'super 4G networks' or 'post-Long Term Evolution (LTE) systems'. 5G communication systems are considered to be implemented on higher frequency (millimeter wave) bands (e.g., the 60GHz band) to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies have been discussed in 5G communication systems. Furthermore, in 5G communication systems, system network improvements are being developed based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receiver interference cancellation. In 5G systems, hybrid frequency shift keying (FSK), quadrature amplitude modulation (QAM) (FQAM), and sliding window superposition coding (SWSC) have been developed as advanced coding and modulation (ACM), as well as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as advanced access technologies.

[0003] The internet, a human-centric network of connections where information is generated and used, is now evolving into the Internet of Things (IoT), where distributed entities exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, a combination of IoT technology and big data processing technology connected to cloud servers. With the need for technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology in IoT implementation, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) have recently been studied. This IoT environment can provide intelligent internet technology services that create new value for human life by collecting and analyzing data generated between connected things. IoT can be applied to various fields through the convergence and combination of existing information technology (IT) and various industrial applications, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Correspondingly, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine-type communication (MTC), and machine-to-machine (M2M) communication can be implemented using beamforming, MIMO, and array antennas. Cloud radio access networks (RAN), as an application of the aforementioned big data processing technologies, can also be considered an example of the convergence between 5G and IoT technologies.

[0005] Meanwhile, there has been a lot of research recently on small data transmission (SDT) in 5G communication systems.

[0006] The above information is presented as background information only to aid in understanding this disclosure. No determination or assertion is made as to whether any of the above content can be applied to this disclosure as prior art. Summary of the Invention

[0007] Technical issues

[0008] The SDT process of wireless communication systems needs to be enhanced.

[0009] Solution to the problem

[0010] The aspects of this disclosure are intended to at least address the aforementioned problems and / or disadvantages, and to provide at least the following advantages. Therefore, one aspect of this disclosure is to provide a communication method and system for integrating fifth-generation (5G) communication systems that support higher data rates than fourth-generation (4G).

[0011] Additional aspects will be set forth in part in the description which follows, and in part will be apparent from the description, or may be learned by practice of the presented embodiments.

[0012] According to one aspect of this disclosure, a method performed by a terminal is provided. The method includes: receiving from a base station a Radio Resource Control (RRC) release message for at least one configured licensed uplink resource including Small Data Transmission (SDT); identifying an uplink carrier in a Normal Uplink (NUL) or Supplemental Uplink (SUL) based on an SDT procedure initiated when the terminal is in an RRC inactive state; identifying an SSB in a Synchronization Signal Block (SSB) associated with the configured licensed uplink resource for the SDT procedure on the identified uplink carrier; and transmitting uplink data in the uplink license corresponding to the identified SSB to the base station.

[0013] According to another aspect of this disclosure, a method performed by a base station is provided. The method includes: sending a Radio Resource Control (RRC) release message to a terminal for at least one configured licensed uplink resource including Small Data Transmission (SDT); and receiving uplink data from the terminal in an uplink license corresponding to a Synchronization Signal Block (SSB), based on an SDT procedure initiated when the terminal is in an RRC inactive state, wherein the SSB is one of a plurality of SSBs associated with the configured licensed uplink resource for an SDT procedure on an uplink carrier, and wherein the uplink carrier is an uplink carrier in a Normal Uplink (NUL) or Supplemental Uplink (SUL).

[0014] According to another aspect of this disclosure, a terminal is provided. The terminal includes: a transceiver; and at least one processor configured to: receive, via the transceiver, a radio resource control (RRC) release message from a base station for at least one configured licensed uplink resource including small data transmission (SDT); identify an uplink carrier in a normal uplink (NUL) or supplementary uplink (SUL) based on an SDT procedure initiated when the terminal is in an RRC inactive state; identify an SSB in a synchronization signal block (SSB) associated with the configured licensed uplink resource for the SDT procedure on the identified uplink carrier; and transmit, via the transceiver, uplink data in the uplink license corresponding to the identified SSB to the base station.

[0015] According to another aspect of this disclosure, a base station is provided. The base station includes: a transceiver; and at least one processor configured to: transmit via the transceiver to a terminal a Radio Resource Control (RRC) release message including at least one configured licensed uplink resource comprising Small Data Transmission (SDT); and, based on an SDT procedure initiated when the terminal is in an RRC inactive state, receive via the transceiver uplink data in an uplink license corresponding to a Synchronization Signal Block (SSB), wherein the SSB is one of a plurality of SSBs associated with the configured licensed uplink resource for an SDT procedure on an uplink carrier, and wherein the uplink carrier is an uplink carrier in a Normal Uplink (NUL) or Supplemental Uplink (SUL).

[0016] Other aspects, advantages, and key features of this disclosure will become apparent to those skilled in the art from the following detailed description of various embodiments disclosed in conjunction with the accompanying drawings.

[0017] Beneficial effects

[0018] According to various embodiments of this disclosure, the SDT process can be efficiently enhanced. Attached Figure Description

[0019] The above and other aspects, features, and advantages of specific embodiments of the present disclosure will become apparent from the following description taken in conjunction with the accompanying drawings, wherein:

[0020] Figure 1 An example of small data transmission using pre-configured uplink authorization is shown according to an embodiment of this disclosure;

[0021] Figure 2 An example illustrating the association between a synchronization signal block and an uplink grant according to an embodiment of this disclosure;

[0022] Figure 3 Another example illustrating the association between a synchronization signal block and an uplink grant according to embodiments of the present disclosure is shown;

[0023] Figure 4 A flowchart illustrating small data transmission using pre-configured uplink resources according to an embodiment of the present disclosure is shown;

[0024] Figure 5 A flowchart illustrating small data transmission using pre-configured uplink resources according to an embodiment of the present disclosure is shown;

[0025] Figure 6 A flowchart illustrating a Media Access Control (MAC) Protocol Data Unit (PDU) for generating small data according to an embodiment of the present disclosure is shown.

[0026] Figure 7 This is a flowchart of generating a MAC PDU for small data transmission according to an embodiment of the present disclosure;

[0027] Figure 8 A block diagram of a terminal according to an embodiment of the present disclosure; and

[0028] Figure 9 This is a block diagram of a base station according to an embodiment of the present disclosure.

[0029] Throughout the accompanying drawings, it should be noted that similar reference numerals are used to describe the same or similar elements, features, and structures. Detailed Implementation

[0030] The following description, taken with reference to the accompanying drawings, is intended to aid in a full understanding of the various embodiments of this disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of this disclosure. Furthermore, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0031] The terms and words used in the appended description and claims are not limited to their literal meaning, but are merely those used by the inventors to enable a clear and consistent understanding of this disclosure. Therefore, it will be apparent to those skilled in the art that the following description of various embodiments of this disclosure is for illustrative purposes only and not intended to limit the disclosure, which is defined by the appended claims and their equivalents.

[0032] It should be understood that, unless the context clearly specifies otherwise, the singular forms “a,” “its,” and “the” include plural references. Thus, for example, the reference to “a component surface” includes the reference to one or more such surfaces.

[0033] The term “substantially” means that the feature, parameter, or value mentioned does not need to be accurately realized, but rather deviations or variations (including, for example, tolerances, measurement errors, measurement accuracy limitations, and other factors known to those skilled in the art) may occur in a number that does not exclude the effects that the feature is intended to provide.

[0034] Those skilled in the art will understand that the blocks and combinations of flowcharts (or sequence diagrams) can be represented and executed by computer program instructions. These computer program instructions can be loaded onto a processor of a general-purpose computer, a special-purpose computer, or a programmable data processing device. When the loaded program instructions are executed by the processor, they create means for performing the functions described in the flowchart. Because computer program instructions can be stored in a computer-readable storage device that can be used with a special-purpose computer or a programmable data processing device, articles of manufacture that perform the functions described in the flowchart can also be created. Because computer program instructions can be loaded onto a computer or a programmable data processing device, when executed as processes, they can perform the operations of the functions described in the flowchart.

[0035] A flowchart's boxes may correspond to modules, segments, or code containing one or more executable instructions that implement one or more logical functions, or they may correspond to a portion thereof. In some cases, the functions described by the boxes may be executed in a different order than they are listed. For example, two boxes listed sequentially may be executed simultaneously or in reverse order.

[0036] In this specification, the terms "unit," "module," etc., can refer to software or hardware components capable of performing functions or operations, such as, for example, Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs). However, "unit," etc., is not limited to hardware or software. Units, etc., can be configured to reside in addressable storage media or drive one or more processors. Units, etc., can refer to software components, object-oriented software components, class components, task components, processes, functions, attributes, procedures, subroutines, program code snippets, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, or variables. The functionality provided by components and units can be a combination of smaller components and units, and can be combined with other components and units to form larger components and units. Components and units can be configured to drive devices in a secure multimedia card or one or more processors.

[0037] Before the detailed description, terms or definitions necessary for understanding this disclosure are described. However, these terms should be interpreted in a non-limiting manner.

[0038] A base station (BS) is an entity that communicates with user equipment (UE) and can be referred to as a BS, base transceiver station (BTS), node B (NB), evolved NB (eNB), access point (AP), 5G NB (5GNB), or next-generation node B (gNB).

[0039] A UE is an entity that communicates with a BS and can be referred to as a UE, device, mobile station (MS), mobile device (ME), or terminal.

[0040] In recent years, several broadband wireless technologies have been developed to meet the growing number of broadband users and provide more and better applications and services. Second-generation wireless communication systems have been developed to provide voice services while ensuring user mobility. Third-generation wireless communication systems support not only voice services but also data services. Fourth-generation wireless communication systems have also been developed in recent years to meet the demand for high-speed data services. However, currently, fourth-generation wireless communication systems lack the resources to meet the growing demand for high-speed data services. Therefore, fifth-generation wireless communication systems are under development to meet the growing demand for high-speed data services and support ultra-reliable and low-latency applications.

[0041] Fifth-generation (5G) wireless communication systems will be implemented not only in lower frequency bands but also in higher frequency (mmWave) bands (e.g., 10 GHz to 100 GHz) to achieve higher data rates. To mitigate radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies are being considered in the design of 5G wireless communication systems. Furthermore, 5G wireless communication systems are expected to address diverse use cases with significantly different requirements in terms of data rate, latency, reliability, and mobility. However, it is anticipated that the air interface design of 5G wireless communication systems will be flexible enough to serve UEs with considerably different capabilities, depending on the use case and market segment to which the UE serves the end customer. Several example use cases that 5G wireless communication systems are expected to address include enhanced mobile broadband (eMBB), massive machine-type communication (m-MTC), and ultra-reliable low-latency communication (URLL). eMBB requirements (such as data rates of tens of Gbps, low latency, and high mobility) target the segment representing traditional wireless broadband users who need internet connectivity anywhere, anytime, and anywhere. m-MTC requirements (such as very high connection density, infrequent data transmission, very long battery life, and low mobility) target the segment representing the Internet of Things (IoT) / Internet of Everything (IoE), which envisions connecting billions of devices. URLL requirements (such as very low latency, very high reliability, and variable mobility) target the segment representing industrial automation applications, where vehicle-to-vehicle / vehicle-to-infrastructure communication is expected to be one of the driving forces behind autonomous vehicles.

[0042] In fifth-generation wireless communication systems operating at higher frequency (mmWave) bands, UEs and gNBs use beamforming technology to communicate with each other. Beamforming is used to mitigate propagation path loss and increase the propagation distance for communication at higher frequency bands. Beamforming enhances the transmission and reception performance using high-gain antennas. Beamforming can be divided into transmit (TX) beamforming, performed at the transmitting end, and receive (RX) beamforming, performed at the receiving end. Generally, TX beamforming increases directivity by using multiple antennas to densely distribute the propagation area in a specific direction.

[0043] In this context, the aggregation of multiple antennas can be referred to as an antenna array, and each antenna included in the array can be called an array element. Antenna arrays can be configured in various forms, such as linear arrays, planar arrays, etc. Using TX beamforming technology increases the directivity of the signal, thereby increasing the propagation distance. Furthermore, since the signal is almost entirely transmitted in directions other than the directional direction, signal interference acting on the other receiver is significantly reduced. The receiver can perform beamforming on the RX signal by using an RX antenna array. RX beamforming increases the strength of the RX signal transmitted in a specific direction by allowing propagation to be concentrated in that specific direction, and excludes signals transmitted in directions other than the specific direction from the RX signal, thus providing a blocking effect against interfering signals.

[0044] By using beamforming technology, a transmitter can create multiple transmit beam patterns in different directions. Each of these transmit beam patterns can also be referred to as a TX beam. Wireless communication systems operating at high frequencies use multiple narrow TX beams to transmit signals within a cell because each narrow TX beam covers a portion of the cell. The narrower the TX beam, the higher the antenna gain, and therefore the greater the propagation distance of the signal transmitted using beamforming technology. Receivers can also create multiple RX beam patterns in different directions. Each of these receive patterns can also be referred to as an RX beam.

[0045] Fifth-generation wireless communication systems (also known as next-generation radio or NR) support standalone operating modes as well as dual connectivity (DC). In DC, a multi-Rx / Tx UE can be configured to utilize resources provided by two different nodes (or NBs) via a non-ideal backhaul connection. One node acts as the primary node (MN), and the other as the secondary node (SN). The MN and SN are connected via a network interface, and at least the MN is connected to the core network. NR also supports multi-RAT dual connectivity (MR-DC) operation, whereby a UE in a Radio Resource Control Connection (RRC_CONNECTED) is configured to utilize radio resources provided by two different schedulers located in two different nodes providing E-UTRA (Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access) (i.e., if the node is an ng-eNB) or NR access (i.e., if the node is a gNB) via a non-ideal backhaul connection. In NR, for a UE in an RRC_CONNECTED connection without configured carrier aggregation (CA) / DC, only one serving cell consists of the primary cell. For UEs configured with CA / DC in RRC_CONNECTED mode, the term "serving cell" refers to a set of cells consisting of a special cell and all secondary cells. In NR, the term Master Cell Group (MCG) refers to a group of serving cells associated with the master node, including the primary cell (PCell) and one or more optional secondary cells (SCells). In NR, the term Secondary Cell Group (SCG) refers to a group of serving cells associated with the secondary node, including the primary SCG cell (PSCell) and one or more optional SCells. In NR, a PCell is a serving cell in the MCG operating on the primary frequency, where the UE performs the initial connection establishment procedure or initiates a connection re-establishment procedure. In NR, for UEs configured with CA, an Scell ​​is a cell that provides additional radio resources above a special cell. A PSCell is a serving cell in the SCG where the UE performs random access during reconfiguration and synchronization procedures. For dual-connectivity operation, the term SpCell (i.e., special cell) refers to either the PCell of the MCG or the PSCell of the SCG; otherwise, the term special cell refers to the PCell.

[0046] In fifth-generation (or NR) wireless communication systems, the Physical Downlink Control Channel (PDCCH) is used to schedule downlink (DL) transmissions on the Physical Downlink Shared Channel (PDSCH) and uplink (UL) transmissions on the Physical Uplink Shared Channel (PUSCH). The downlink control information (DCI) on the PDCCH includes: downlink allocation, which at least contains modulation and coding schemes, resource allocation, and Hybrid Automatic Repeat Request (HARQ) information related to the Downlink Shared Channel (DL-SCH); and uplink scheduling grants, which at least contain modulation and coding schemes, resource allocation, and Hybrid ARQ information related to the Uplink Shared Channel (UL-SCH). In addition to scheduling, PDCCH can be used to activate and deactivate configured PUSCH transmissions with configuration authorization; activate and deactivate PDSCH semi-persistent transmissions; notify one or more UEs of slot formats; notify one or more UEs of physical resource blocks (PRBs) and orthogonal frequency division multiplexing (OFDM) symbols, where the UE may assume there are no transmissions intended for the UE; send transmission power control (TPC) commands for the physical uplink control channel (PUCCH) and PUSCH; send one or more TPC commands for sounding reference signal (SRS) transmissions for one or more UEs; switch the effective bandwidth portion of the UE; and initiate random access procedures.

[0047] The UE monitors a set of PDCCH candidates during monitoring times configured in one or more configured control resource sets (CORESETs) according to the corresponding search space configuration. A CORESET consists of a set of PRBs with a duration of 1 to 3 OFDM symbols. Resource units "Resource Element Groups (REGs)" and "Control Channel Elements (CCEs)" are defined within a CORESET, where each CCE consists of a set of REGs. Control channels are formed by aggregating CCEs. Different code rates for control channels are achieved by aggregating different numbers of CCEs. Interleaved and non-interleaved mappings from CCEs to REGs are supported in a CORESET. Polarity coding is used for the PDCCH. Each resource element group carrying the PDCCH carries its own demodulation reference signal (DMRS). Quadrature Phase Shift Keying (QPSK) modulation is used for the PDCCH.

[0048] In NR, the list of search space configurations for each bandwidth portion (BWP) is signaled by the gNB, where each search configuration is uniquely identified by an identifier. The identifiers for search space configurations used for specific purposes (such as paging reception, System Information (SI) reception, and Random Access Response (RAR) reception) are explicitly signaled by the gNB. In NR, the search space configuration includes the following parameters: Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot, and duration. The UE uses the parameters "PDCCH monitoring period (Monitoring-periodicity-PDCCH-slot), PDCCH monitoring offset (Monitoring-offset-PDCCH-slot), and PDCCH monitoring mode (Monitoring-symbols-PDCCH-within-slot)" to determine the timing of PDCCH monitoring within a time slot. PDCCH monitoring occurs during time slot 'x' to x+ duration, where time slot 'x' in radio frame 'y' satisfies the following equation 1:

[0049] [Equation 1]

[0050] (y*(number of time slots in radio frames)+x-Monitoring-offset-PDCCH-slot)mod(Monitoring-periodicity-PDCCH-slot)=0

[0051] The start symbol of the PDCCH monitoring time in each slot with a PDCCH monitoring time is given by Monitoring-symbols-PDCCH-within-slot. The length of the PDCCH monitoring time (in symbols) is given in the corset (CORESET) associated with the search space. The search space configuration includes an identifier for the CORESET configuration associated with it. The list of CORESET configurations for each BWP configuration is signaled by the gNB, where each CORESET configuration is uniquely identified by an identifier. Note that the duration of each radio frame is 10 ms. Radio frames are identified by radio frame number or system frame number. Each radio frame consists of several slots, where the number of slots in a radio frame and the duration of the slots depend on the subcarrier spacing. In NR, the number of slots in a radio frame and the duration of the slots are predefined for radio frames depending on each supported subcarrier spacing (SCS). Each CORESET configuration is associated with a list of TCI (Transmission Configuration Indicator) states. For each TCI state, a DL Reference Signal (RS) identifier (ID) is configured (SSB or Channel State Information Reference Signal (CSI-RS)). A list of TCI states corresponding to the CORESET configuration is signaled by the gNB via RRC signaling. One of the TCI states in the TCI state list is activated and indicated to the UE by the gNB. The TCI state indication is used by the GNB for PDCCH transmission during PDCCH monitoring in the search space (the DL TX beam is quasi-co-located (QCL) with the SSB / CSI RS of the TCI state).

[0052] In NR, bandwidth adaptation (BA) is supported. With BA, the UE's receive and transmit bandwidth does not need to be as large as the cell's bandwidth and can be adjusted: the bandwidth can be changed by command (e.g., reduced during periods of low activity to save power); the location can be moved in the frequency domain (e.g., to increase scheduling flexibility); and the subcarrier spacing can be changed by command (e.g., to allow different services). A subset of the cell's total bandwidth is called the bandwidth portion (BWP).

[0053] The BA (Balanced Access Controller) configures the BWP (Browser Window) for the RRC-connected UE and informs the UE which configured BWP is currently active. When the BA is configured, the UE only needs to monitor the PDCCH on one active BWP (i.e., the UE does not need to monitor the PDCCH on the entire DL (Deep Link) frequency of the serving cell). In RRC-connected state, for each configured serving cell (i.e., PCell or SCell), the UE is configured with one or more DL and UL BWPs. For an active serving cell, at any given time, one UL and DL BWP is always active. Serving cell BWP handover is used to activate inactive BWPs and deactivate active BWPs. BWP handover is controlled by the PDCCH indicating downlink allocation or uplink grant, by the bwp-InactivityTimer, by RRC signaling, or by the Media Access Control (MAC) entity itself when the random access procedure is initiated. When adding a SpCell or activating an SCell, the DL BWP and UL BWP, indicated by firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id respectively, are active if no PDCCH indicating downlink allocation or uplink grant is received. The active BWP of the serving cell is indicated by RRC or PDCCH. For unpaired spectrum, the DL BWP is paired with the UL BWP, and BWP handover is shared for both UL and DL. When the BWP inactivity timer expires, the UE switches from the active DL BWP to the default DL BWP or the initial DL BWP (if no default DL BWP is configured).

[0054] In 5G wireless communication systems, random access (RA) is supported. Random access (RA) is used to achieve uplink (UL) time synchronization. RA is used during initial access, handover, RRC connection re-establishment procedures, scheduling request transmissions, SCG addition / modification, beam fault recovery, and data or control information transmissions of asynchronous UEs in the RRC CONNECTED state within the UL. Several types of random access procedures are supported.

[0055] Contention-Based Random Access (CBRA): This is also known as 4-step CBRA. In this type of random access, the UE first sends a random access preamble (also known as Msg1) and then waits for the RAR in the random access response (RAR) window. The RAR is also known as Msg2. The next-generation node B (gNB) sends the RAR on the PDSCH. The PDCCH that schedules the PDSCH carrying the RAR is addressed by the RA Radio Network Temporary Identifier (RA-RNTI). The RA-RNTI identifies the time-frequency resource (also known as the Physical RA Channel (PRACH) timing, PRACH Transmission (TX) timing, or RA Channel (RACH) timing) at which the gNB detected the RA preamble. The RA-RNTI is calculated as follows: RA-RNTI = 1 + s_id + 14 * t_id + 14 * 80 * f_id + 14 * 80 * 8 * ul_carrier_id, where s_id is the index of the first Orthogonal Frequency Division Multiplexing (OFDM) symbol of the PRACH timing when the UE transmits Msg1 (i.e., the RA preamble) (0 ≤ s_id < 14); t_id is the index of the first time slot of the PRACH timing (0 ≤ t_id < 80); f_id is the index of the PRACH timing in the frequency domain within the time slot (0 ≤ f_id < 8), and ul_carrier_id is the UL carrier used for Msg1 transmission (0 represents a normal UL (NUL) carrier, and 1 represents a supplementary UL (SUL) carrier). Several RARs of various random access preambles detected by the gNB can be multiplexed by the gNB in ​​the same RAR MAC Protocol Data Unit (PDU). If the RAR in the MAC PDU includes the RA preamble identifier (RAPID) of the RA preamble sent by the UE, then the RAR corresponds to the UE's RA preamble transmission. If no RAR corresponding to its RA preamble transmission is received during the RAR window and the UE has not sent an RA preamble within a configurable number of times (configured by the gNB in ​​the RACH configuration), the UE returns to step one (i.e., selects random access resources (preamble / RACH timing)) and sends the RA preamble. A fallback may be applied before returning to step one.

[0056] If a RAR corresponding to its RA preamble is received, the UE sends message 3 (Msg3) in the UL grant received in the RAR. Msg3 includes messages such as RRC connection request, RRC connection re-establishment request, RRC handover confirmation, scheduling request, SI request, etc. Msg3 may also include the UE identification (i.e., Cell Radio Network Temporary Identifier (C-RNTI) or System Architecture Evolution (SAE) Temporary Mobile Subscriber Identifier (S-TMSI) or a random number). After sending Msg3, the UE starts a contention resolution timer. While the contention resolution timer is running, if the UE receives a PDCCH addressed to the C-RNTI included in Msg3, the contention resolution is considered successful, the contention resolution timer stops, and the RA procedure is completed. While the contention resolution timer is running, if the UE receives a contention resolution MAC control element (CE) including the UE's contention resolution identification (the first X bits of the Common Control Channel (CCCH) Service Data Unit (SDU) sent in Msg3), the contention resolution is considered successful, the contention resolution timer stops, and the RA procedure is completed. If the contention resolution timer expires and the UE has not sent the RA preamble within the configurable number of attempts, the UE returns to step one (i.e., selects random access resources (preamble / RACH timing)) and sends the RA preamble. A fallback can be applied before returning to step one.

[0057] Contention-Free Random Access (CFRA): This is also known as Traditional CFRA or 4-Step CFRA. The CFRA procedure is used for situations such as handovers requiring low latency and early timing setup of SCells. The evolved Node B (eNB) assigns a dedicated random access preamble to the UE. The UE sends the dedicated RA preamble. The eNB sends the RAR on the PDSCH addressed to the RA-RNTI. The RAR conveys the RA preamble identifier and timing alignment information. The RAR may also include UL authorization. The RAR is sent within the RAR window, similar to the CBRA procedure. CFRA is considered successfully completed upon receiving the RAR with the RAPID including the RA preamble sent by the UE. In the case of RA initiated for beam fault recovery, CFRA is considered successfully completed if a PDCCH addressed to the C-RNTI is received in the beam fault recovery search space. If the RAR window expires and the RA has not successfully completed and the UE has not sent the RA preamble within a configurable number of times (configured by the gNB in ​​the RACH configuration), the UE retransmits the RA preamble.

[0058] For specific events such as handover and beam failure recovery, if a dedicated preamble is allocated to the UE, the UE determines whether to send a dedicated or non-dedicated preamble in the first step of random access (i.e., during the random access resource selection during Msg1 transmission). A dedicated preamble is typically used for a subset of SSB / CSI-RS. If there are no SSB / CSI-RS whose DL reference signal received power (RSRP) exceeds a threshold among those provided by the gNB for its contention-free random access resources (i.e., dedicated preamble / RO), the UE selects a non-dedicated preamble. Otherwise, the UE selects a dedicated preamble. Therefore, during the RA procedure, one random access attempt can be a CFRA, while other random access attempts can be CBRA.

[0059] Two-Step Contention-Based Random Access (2-Step CBRA): In the first step, the UE transmits a random access preamble on the PRACH and a payload (i.e., a MAC PDU) on the PUSCH. The transmission of the random access preamble and payload is also referred to as MsgA. In the second step, after the MsgA transmission, the UE monitors for a response from the network (i.e., the gNB) within a configured window. This response is also referred to as MsgB. If a CCCH SDU is transmitted in the MsgA payload, the UE uses the contention resolution information in the MsgB to perform contention resolution. If the contention resolution identifier received in the MsgB matches the first 48 bits of the CCCH SDU transmitted in the MsgA, the contention resolution is successful. If a C-RNTI is transmitted in the MsgA payload, the contention resolution is successful if the UE receives a PDCCH addressed to the C-RNTI. If the contention resolution is successful, the random access procedure is considered successfully completed. MsgB may include fallback information corresponding to the random access preamble sent in MsgA, instead of contention resolution information corresponding to the sent MsgA. If fallback information is received, the UE sends Msg3 and performs contention resolution using Msg4, as in the CBRA procedure. If contention resolution is successful, the random access procedure is considered to have completed successfully. If contention resolution fails during fallback (i.e., when sending Msg3), the UE retransmits MsgA. If the configuration window for monitoring network responses expires after the UE sends MsgA and the UE does not receive MsgB including the aforementioned contention resolution or fallback information, the UE retransmits MsgA. If the random access procedure has not completed successfully even after a configurable number of MsgA transmissions, the UE falls back to the 4-step RACH procedure, i.e., the UE only sends the PRACH preamble.

[0060] The MsgA payload may include one or more of the following: CCCH SDU, Dedicated Control Channel (DCCH) SDU, Dedicated Flow Channel (DTCH) SDU, Buffer Status Report (BSR) MAC CE, Power Clearance Report (PHR) MAC CE, SSB information, C-RNTI MAC CE, or padding. In the first step, MsgA may include the UE ID (e.g., random ID, S-TMSI, C-RNTI, recovery ID, etc.) and a preamble. The UE ID may be included in the MAC PDU of the MsgA. UE IDs such as C-RNTI may be carried in the MAC CE, where the MAC CE is included in the MAC PDU. Other UE IDs (such as random ID, S-TMSI, C-RNTI, recovery ID, etc.) may be carried in the CCCH SDU. The UE ID may be one of the following: random ID, S-TMSI, C-RNTI, recovery ID, IMSI, idle mode ID, inactive mode ID, etc. The UE ID may differ in different scenarios in which the UE performs the RA procedure. When a UE performs a Re-Action (RA) after power-on (before it connects to the network), the UE ID is a random ID. When a UE performs an RA in IDLE state after being attached to the network, the UE ID is the S-TMSI. If the UE has an assigned C-RNTI (e.g., in connected state), the UE ID is the C-RNTI. When the UE is inactive, the UE ID is the recovery ID. In addition to the UE ID, several additional control information can be sent in the MsgA. This control information can be included in the MsgA's MAC PDU. This control information may include one or more of the following: connection request indication, connection restoration request indication, SI request indication, buffer status indication, beam information (e.g., one or more DLTX beam IDs or SSB IDs), beam failure recovery indication / information, data indicator, cell / BS / TRP handover indication, connection re-establishment indication, reconfiguration complete or handover complete message, etc.

[0061] Two-Step Contention-Free Random Access (2-Step CFRA): In this case, the gNB allocates dedicated random access preamble and PUSCH resources to the UE for MsgA transmission. The RO for preamble transmission can also be indicated. In the first step, the UE uses the contention-free random access resources (i.e., dedicated preamble / PUSCH resources / RO) to transmit the random access preamble on the PRACH and the payload on the PUSCH. In the second step, after the MsgA transmission, the UE monitors for responses from the network (i.e., the gNB) within a configured window. If the UE receives a PDCCH addressed to the C-RNTI, the random access procedure is considered successfully completed. If the UE receives fallback information corresponding to its transmitted preamble, the random access procedure is considered successfully completed.

[0062] For specific events such as handover and beam failure recovery, if dedicated preamble and PUSCH resources are allocated to the UE, during the first step of random access (i.e., during the random access resource selection during MsgA transmission), the UE determines whether to send a dedicated or non-dedicated preamble. A dedicated preamble is typically used for a subset of SSB / CSI-RS. If there are no SSB / CSI-RS whose DLRSRP exceeds a threshold among those provided by the gNB for its contention-free random access resources (i.e., dedicated preamble / RO / PUSCH resources), the UE selects a non-dedicated preamble. Otherwise, the UE selects a dedicated preamble. Therefore, during the RA procedure, one random access attempt can be a 2-step CFRA, while other random access attempts can be a 2-step CBRA.

[0063] When initiating a random access procedure, the UE first selects a carrier (SUL or NUL). If the carrier used for the random access procedure is explicitly signaled by the gNB, the UE selects the signaled carrier to perform the random access procedure. If the carrier used for the random access procedure is not explicitly signaled by the gNB, if the serving cell for the random access procedure is configured with a supplemental uplink, and if the downlink path loss reference RSRP is less than rsrp-ThresholdSSB-SUL, the UE selects the SUL carrier to perform the random access procedure. Otherwise, the UE selects the NUL carrier to perform the random access procedure. When selecting the UL carrier, the UE determines the UL and DL BWP for the random access procedure according to Section 5.15 of TS 38.321. Then, the UE determines whether to perform a 2-step or 4-step RACH for the random access procedure.

[0064] - If the random access procedure is initiated by a PDCCH command, and if the ra-PreambleIndex explicitly provided by the PDCCH is not 0b000000, then the UE selects a 4-step RACH.

[0065] Otherwise, if the two-step contention-free random access resources used for the random access procedure are signaled by the gNB, the UE selects a two-step RACH.

[0066] Otherwise, if the 4-step contention-free random access resources used for the random access procedure are signaled by the gNB, the UE selects a 4-step RACH.

[0067] - Otherwise, if the UL BWP selected for the random access procedure is only configured with 2-step RACH resources, the UE selects 2-step RACH.

[0068] Otherwise, if the UL BWP selected for the random access procedure is only configured with 4-step RACH resources, the UE selects 4-step RACH.

[0069] - Otherwise, if the UL BWP selected for this random access procedure is configured with 2-step and 4-step RACH resources,

[0070] - If the RSRP referenced for downlink path loss is lower than the configured threshold, the UE selects a 4-step RACH. Otherwise, the UE selects a 2-step RACH.

[0071] In fifth-generation wireless communication systems, the intra-cell broadcast synchronization signal and PBCH block (SSB) of a node B (gNB) or base station consists of a primary synchronization signal (PSS), a secondary synchronization signal (SSS), and system information. System information (SI) includes common parameters required for communication within the cell. In fifth-generation wireless communication systems (also known as next-generation radio or NR), SI is divided into a main information block (MIB) and several system information blocks (SIBs), wherein:

[0072] - The MIB is always transmitted on the BCH with a period of 80ms and a repetition within 80ms, and includes the parameters required to obtain System Information Block 1 (SIB1) from the cell.

[0073] SIB1 is transmitted on the DL-SCH with a period of 160ms and a variable number of transmission repetitions. The default transmission repetition period for SIB1 is 20ms, but the actual transmission repetition period is determined by the network implementation. The scheduling information in SIB1 includes the mapping between SIBs and SI messages, the period of each SI message, and the SI window length. The scheduling information in SIB1 includes an indicator for each SI message, indicating whether the associated SI message has been broadcast. If at least one SI message has not been broadcast, SIB1 may include random access resources (PRACH preamble and PRACH resources) for requesting the gNB to broadcast one or more SI messages.

[0074] - SIBs other than SIB1 are carried in SystemInformation (SI) messages, which are transmitted on the DL-SCH. Only SIBs with the same period can be mapped to the same SI message. Each SI message is transmitted within a periodically occurring time-domain window (called an SI-window in which all SI messages are of the same length). Each SI message is associated with an SI window, and the SI windows of different SI messages do not overlap. Within an SI window, only the corresponding SI message is transmitted. Any SIB other than SIB1 can be configured as cell-specific or area-specific using the indication in SIB1. Cell-specific SIBs are only applicable within the cell providing the SIB, while area-specific SIBs are applicable within an area called an SI area, which consists of one or more cells and is identified by the systemInformationAreaID.

[0075] In fifth-generation wireless communication systems, RRC can be in one of the following states: RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED. When an RRC connection is established, the UE is in the RRC_CONNECTED state or the RRC_INACTIVE state. If this is not the case (i.e., no RRC connection is established), the UE is in the RRC_IDLE state. RRC states can also be described as follows:

[0076] In RRC_IDLE, UE-specific discontinuities (DRX) can be configured by the upper layer. The UE monitors short messages sent on the DCI using paging RNTI (P-RNTI); monitors paging channels using CN paging with 5G-S-TMSI (5G-S-TMSI); performs neighboring cell measurements and cell (re)selection; acquires system information and can send SI requests (if configured); and performs recording of available measurements and recording of the UE's location and time configured by the recorded measurements.

[0077] In RRC_INACTIVE, UE-specific DRX can be configured by the upper layer or the RRC layer, the UE stores the UE inactive AS context, and the RAN-based notification area is configured by the RRC layer. The UE monitors short messages sent on the DCI using P-RNTI; monitors paging channels using CN paging with 5G-S-TMSI and RAN paging channels using fullI-RNTI; performs neighboring cell measurements and cell (re)selection; performs RAN-based notification area updates periodically and when moving outside the configured RAN-based notification area; acquires system information and can send SI requests (if configured); and performs recording of available measurements and recording of the UE's location and time configured by the recorded measurements.

[0078] In RRC_CONNECTED, the UE stores the AS context and the transmission of unicast data to / from the UE. The UE monitors short messages sent on the DCI using P-RNTI (if configured); monitors the control channel associated with the shared data channel to determine whether to schedule data for it; provides channel quality and feedback information; performs neighboring cell measurements and measurement reports; and acquires system information.

[0079] In RRC_CONNECTED, the network can initiate an RRC connection suspension by sending an RRCLease with a suspension configuration. When an RRC connection is suspended, the UE stores its inactive AS context and any configurations received from the network, and transitions to the RRC_INACTIVE state. If the UE is configured with an SCG, the UE releases the SCG configuration when initiating the RRC connection recovery procedure. The RRC message for suspending the RRC connection is integrity protected and encrypted.

[0080] The resumption of a suspended RRC connection is initiated by an upper layer when the UE needs to transition from the RRC_INACTIVE state to the RRC_CONNECTED state, or by the RRC layer performing a RAN-based Notification Area (RNA) update, or by a RAN paging from the NG-RAN. When the RRC connection is resumed, the network configures the UE according to the RRC connection resumption procedure based on the stored UE inactive AS context and any RRC configuration received from the network. The RRC connection resumption procedure reactivates AS security and re-establishes the Signaling Radio Bearer (SRB) and Data Radio Bearer (DRB). In response to a request to resume the RRC connection, the network may resume the suspended RRC connection and send RRC_CONNECTED to the UE, or reject the resumption request and send RRC_INACTIVE to the UE (and wait for a timer), or directly re-suspend the RRC connection and send RRC_INACTIVE to the UE, or directly release the RRC connection and send RRC_IDLE to the UE, or instruct the UE to initiate a NAS-level resumption (in which case the network sends an RRC setup message).

[0081] When initiating the recovery process, the UE:

[0082] - Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the parameters whose values ​​are provided in SIB1.

[0083] - Apply default MAC cell group configuration

[0084] - Apply CCCH configuration

[0085] - Start timer T319.

[0086] - The application includes timeAlignmentTimerCommon in SIB1.

[0087] - Apply default SRB1 configuration

[0088] - Set the variable pendingRNA-Update to false;

[0089] - Initiate the transmission of RRCResumeRequest message or RRCResumeRequest1.

[0090] - Restore RRC configuration, RoHC state, stored QoS flow to DRB mapping rules, and KgNB and K from the stored UE inactive AS context. RRCint Key, except for the following:

[0091] *masterCellGroup;

[0092] *mrdc-SecondaryCellGroup (if stored); and

[0093] *90*pdcp-Config;

[0094] - Set resumeMAC-I to the 16 least significant bits of MAC-I calculated as follows:

[0095] *On VarResumeMAC-Input encoded with ASN.1 according to 8 times (i.e., multiples of 8 bits);

[0096] *Use K in the UE inactive AS context RRCint The key and the previously configured integrity protection algorithm; and

[0097] *Among them, all input bits of COUNT, BEARER, and DIRECTION are set to binary;

[0098] - Use the stored nextHopChainingCount value to derive the KgNB key based on the current KgNB key or NH;

[0099] -Derivation of K RRCenc Key, K RRCint Key, K UPint Key and K UPenc Key;

[0100] -Use the configured algorithm and K RRCint Key and K UPintThe key configures the lower layer to apply integrity protection to all signaling radio bearers except SRB0; that is, integrity protection should be applied to all subsequent messages received and sent by the UE.

[0101] - Configure the lower layer to apply encryption to all signaling radio bearers except SRB0, and apply the configured encryption algorithm, resulting in K RRCenc Key and K UPenc The key, i.e., the encryption configuration, should be applied to all subsequent messages received and sent by the UE;

[0102] - Re-establish the PDCP entity of SRB1;

[0103] -Restore SRB1; and

[0104] - Send RRCResumeRequest or RRCResumeRequest1.

[0105] In a 4G wireless communication system, for small data transmissions in RRC_IDLE, the UE can be configured with pre-configured UL resources. The UE receives PUSCH resources (e.g., periodic UL grants) for small data transmissions in the RRC connection release message. If the UE has a small amount of data to send in RRC_IDLE, the UE camps in the same cell from which it received the UL grant in the RRC connection release message, and the UE has a valid TA. The UE then selects the earliest UL grant and sends a MAC PDU in the selected UL grant. The UE waits for a response from the network within the configured time interval. Upon a response, the UE monitors the PDCCH addressed to the RNTI allocated to the UE in the RRC connection release message. If no response is received, the small data transmission is considered a failure.

[0106] 5G wireless communication systems support a search space for multi-beam, multi-UL carrier, multi-BWP, and PDCCH surveillance. Current procedures do not consider all of these aspects. Small data transmission processes should be enhanced to support a search space for multi-beam, multi-UL carrier, multi-BWP, and PDCCH surveillance.

[0107] In 5G wireless communication systems, the Logical Channel Prioritization (LCP) process is used to generate MAC PDUs. The RRC controls the LCP process by configuring mapping constraints for each logical channel.

[0108] -allowedSCS-List, which sets the allowed subcarrier spacing for transmission;

[0109] -maxPUSCH-Duration sets the maximum PUSCH duration allowed for the transmission;

[0110] -configuredGrantType1Allowed sets whether the configured grant type 1 can be used for transport;

[0111] -allowedServingCells sets the allowed cells for transmission;

[0112] -allowedCG-List sets the allowed configuration authorization for transmission;

[0113] -allowedPHY-PriorityIndex sets the allowed PHY priority index for dynamic authorization of the transport;

[0114] For SDT, DRB is restored when RRC connection recovery is initiated. The question is whether the LCH limit in the AS-context stored during the generation of the MAC PDU for small data transfers is applied.

[0115] Example 1 - Operations during the recovery of an RRC connection in RRC_INACTIVE or during the initiation of a small data transfer process in RRC_INACTIVE

[0116] The UE is in the RRC_INACTIVE state. During the RRC_INACTIVE state, the UE initiates RRC connection restoration for small data transmission (if the criteria for performing small data transmission are met). RRC connection restoration for small data transmission can also be referred to as a small data transmission procedure. When initiating RRC connection restoration for small data transmission or initiating a small data transmission procedure, the UE performs the following operations:

[0117] - Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the parameters provided in SIB1;

[0118] - Apply default MAC cell group configuration

[0119] - Apply CCCH configuration

[0120] - Start the timer (T319 or a new timer configured by the gNB for small data transfer);

[0121] - The application includes timeAlignmentTimerCommon in SIB1.

[0122] - Apply default SRB1 configuration

[0123] - Set the variable pendingRNA-Update to false

[0124] - Initiate the transmission of RRCResumeRequest message or RRCResumeRequest1.

[0125] - If the useFullResumeID field is signaled in SIB1, then:

[0126] * Select RRCResumeRequest1 as the message to use.

[0127] Set resumeIdentity to the stored fullI-RNTI value;

[0128] -otherwise:

[0129] *Select RRCResumeRequest as the message to use.

[0130] Set resumeIdentity to the stored shortI-RNTI value;

[0131] - Restore RRC configuration, RoHC state, stored QoS flow to DRB mapping rules, and KgNB and K from the stored UE inactive AS context. RRCint Key, except for the following:

[0132] *masterCellGroup;

[0133] *mrdc-SecondaryCellGroup (if stored); and

[0134] *pdcp-Config;

[0135] - Set resumeMAC-I to the 16 least significant bits of MAC-I calculated as follows:

[0136] *On ASN.1 encoded VarResumeMAC-Input

[0137] *Use K in the UE inactive AS context RRCint The key and the previously configured integrity protection algorithm; and

[0138] *Among them, all input bits of COUNT, BEARER, and DIRECTION are set to binary;

[0139] - Use the stored nextHopChainingCount value to derive the KgNB key based on the current KgNB key or NH;

[0140] -Derivation of K RRCenc Key, KRRCint Key, K UPint Key and K UPenc Key;

[0141] -Use the configured algorithm and K RRCint Key and K UPint The key is configured at the lower layer to apply integrity protection to all radio bearers except SRB0; that is, integrity protection should be applied to all subsequent messages and user data received and transmitted by the UE; only DRBs with previously configured UP integrity protection should have their integrity protection restored.

[0142] - Configure the lower layer to apply encryption to all radio bearers except SRB0, and apply the configured encryption algorithm, resulting in K RRCenc Key and K UPenc The key, i.e., the encryption configuration, should be applied to all subsequent messages and data received and sent by the UE;

[0143] - Re-establish PDCP entities for all SRBs and all DRBs (or re-establish PDCP entities for SRB1 and all DRBs); Note that the UE applies the PDCP configuration from the stored AS context to the re-established PDCP entities for DRBs and SRB2. In the embodiment, whether to apply the PDCP configuration from the stored AS context or apply the default PDCP configuration can be indicated by the gNB in ​​the RRCReconfiguration message or the RRCReconfiguration message, and the UE accordingly applies the PDCP configuration from the stored AS context or applies the default PDCP configuration to the re-established PDCP entities for DRBs and SRB2.

[0144] - Re-establish the RLC entity of DRB (Note that the RLC entity of SRB1 is re-established when the UE enters an inactive state). Note that the UE applies the RLC configuration from the stored AS context to the re-established RLC entities of DRB and SRB2. In this embodiment, applying the RLC configuration from the stored AS context or applying the default RLC configuration can be indicated by the gNB in ​​the RRCReconfiguration message or the RRCReconfiguration message, and the UE accordingly applies the RLC configuration from the stored AS context or applies the default RLC configuration to the re-established RLC entities of DRB and SRB2.

[0145] - Restore all SRBs and all DRBs (or restore SRB 1 and all DRBs);

[0146] *When the connection is restored, the timing at which the PDCP will provide the DTCH SDU to the lower layer also needs to be specified. The RRC can indicate this to the PDCP when restoring the DRB.

[0147] *144 - Send RRCResumeRequest or RRCResumeRequest1. User data is encrypted and integrity protected (only for DRBs configured with UP integrity protection) and sent on a DTCH multiplexed with the RRCResumeRequest / RRRCResumeRequest1 message on the CCCH. Some auxiliary information may also be included, such as BSR (normal or truncated); DL data indicating that the UE has more UL data or that the UE expects in response to UL data and / or a new MAC CE including SS-RSRP or CQI; or an indication in the RRC message that the UE has more UL data or that the UE expects in response to UL data. Note that in the case of small data transmission based on RACH, this transmission is performed in Msg3 or MsgA, and in the case of small data transmission based on non-RACH, this transmission is performed in a pre-configured UL authorization.

[0148] - In the alternative embodiment, uplink data with integrity protection is sent instead of sending RRCResumeRequest or RRCResumeRequest1 along with uplink data. RRCResumeRequest or RRCResumeRequest1 messages are not sent. The gNB can authenticate the UE based on the received MAC-I and uplink data. It should be noted that in the case of RACH-based small data transmission, this transmission is performed in Msg3 or MsgA, and in the case of non-RACH-based small data transmission, this transmission is performed in a pre-configured UL grant.

[0149] The UE only restores and re-establishes those DRBs that allow small data transmission, instead of restoring all DRBs and re-establishing the PDCP / RLC entities of all DRBs in the above operation.

[0150] - DRBs that allow small data transfers can be signaled by the gNB (e.g., in an RRC Release message or any other RRC signaling message). One or more DRB identifiers that allow small data transfers can be included in an RRC Release message or any other RRC signaling message, such as an RRC Reconfiguration message. Alternatively, the DRB configuration may include an indicator (e.g., SDT Lowed is set to TRUE) that indicates that SDT is allowed for that DRB. If SDT Lowed is set to FALSE or is not included, the UE assumes that SDT is not allowed for that DRB.

[0151] - In an embodiment, a DRB is considered permitted for small data transmission if data from the LCH of the DRB is allowed to be transmitted in a UL grant for small data transmission according to LCH restrictions (allowedSCS-List, maxPUSCH-Duration, configuredGrantType1AAllowed, allowedServingCells, allowedCG-List, and allowedPHY-PriorityIndex). One or more LCH restrictions are configured in the LCH configuration of the LCH associated with the DRB. allowedSCS-List sets the subcarrier spacing allowed for transmission, including: maxPUSCH-Duration, which sets the maximum PUSCH duration allowed for transmission; configuredGrantType1Allowed, which sets whether the configured grant type 1 can be used for transmission; allowedServingCells, which sets the cells allowed for transmission; allowedCG-List, which sets the configured grant allowed for transmission; and allowedPHY-PriorityIndex, which sets the PHY priority index of the dynamic grant allowed for transmission. For example, if the UL-authorized SCS for small data transfer is SCS X, and the DRB's LCH is configured with an allowedSCS-List, where SCS X is not included in the allowedSCS-List, then the DRB is not considered for small data transfer.

[0152] Example 2 - Small data transmission using pre-configured UL-licensed technology

[0153] Figure 1 An example of small data transfer using a pre-configured uplink grant (also referred to as a CGtype 1PUSCH resource) is shown according to an embodiment of this disclosure.

[0154] refer to Figure 1In RRC_CONNECTED, the UE reports its capabilities to indicate whether it supports pre-configured PUSCH during RRC_INACTIVE. The UE may (e.g., in a UEAssistanceInformation message) report its preference for configuring pre-configured PUSCH. The gNB determines whether to configure pre-configured PUSCH in RRC_INACTIVE based on the following factors: UE capabilities, UE type, UE preferences, and UL traffic mode.

[0155] In operation 110, the UE receives pre-configured PUSCH resources (e.g., CG Type 1 resources) for Small Data Transmission (SDT) from the gNB in ​​dedicated signaling (RRCReconfiguration message or RRCRelease message).

[0156] *In this embodiment, these PUSCH resources of the SDT apply to cells from which the UE receives an RRCReconfiguration message or an RRCReconfiguration message that includes the SDT's PUSCH resources. In this embodiment, these resources of the SDT apply to multiple cells. Details regarding the association between the SDT's UL resources and cells will be described later.

[0157] These PUSCH resources are also mapped to SSBs. The mapping rules between PUSCH resources and SSBs will be described later.

[0158] *If multiple UL carriers are supported, pre-configured PUSCH resources for SDT are provided for SUL and NUL respectively.

[0159] *Configuration for pre-configured PUSCHs is provided in RCRelease. For example, configuration can be added when RCRelease is used to switch to RRC_INACTIVE. Configuration can be added to the SuspendConfig IE. Alternatively, ConfiguredGrantConfig on Type 1 is provided in RRCReconfiguration. Furthermore, an indicator is included in RCRelease to indicate whether the UE can continue using the configured Grant Type 1 during RRC_INACTIVE. Additionally, extra (pre-configured PUSCH-specific) configuration can be provided in RCRelease.

[0160] When the UE is in RRC_INACTIVE state, in operation 120, an SDT using pre-configured PUSCH resources is initiated. The standard for SDT using pre-configured PUSCH resources will be described later.

[0161] In operation 130, the UE selects the UL carrier.

[0162] If SUL is configured in the cell where the UE performs SDT (i.e., the cell camped in RRC_INACTIVE), and the RSRP of the downlink path loss reference (e.g., SSB) is less than RSRPThresholdSUL-SDT, the UE selects SUL. Otherwise, the UE selects NUL. RSRPThresholdSUL-SDT is received from the gNB. If RSRPThresholdSUL-SDT is not configured, the UE uses the RSRPThresholdSUL configured in the RACH configuration. It is important to note that RSRPThresholdSUL-SDT is a new parameter configured for selecting between SUL and NUL for small data transmissions. This parameter differs from the SUL and NUL carrier selection for random access preamble transmissions. This is because the UL information transmitted in the case of SDT is much larger than in the normal random access procedure for connection establishment / recovery, and stronger channel conditions are required to ensure reliable transmission.

[0163] Then, in operation 140, the UE selects an SSB whose SS-RSRP is higher than RSRPThresholdSSB-SDT from among the SSBs associated with the pre-configured PUSCH resources for the SDT on the selected UL carrier. RSRPThresholdSSB-SDT is received from the gNB. If RSRPThresholdSSB-SDT is not configured, the UE uses the RSRPThresholdSSB configured in the RACH configuration. It should be noted that on the selected UL carrier, the UE uses the pre-configured PUSCH resources for SDT on the UL BWP for small data transmission. The UL BWP for small data transmission using the pre-configured PUSCH resources will be described later.

[0164] In operation 150, the UE selects the earliest available UL grant corresponding to the selected SSB from the pre-configured PUSCH resources of the selected UL carrier.

[0165] In Operation 160, the UE generates a MAC PDU for small data transmission and sends it in the selected UL grant. The UE sends the small data using one of the following options:

[0166] *RRCResumeRequest (or a new RRC message) + uplink data (on the DTCH). The resumeIdentity, ResumeMAC-I, and resumeCause are in RRCResumeRequest / RRCResumeRequest1. A new resumeCause can be introduced to indicate small data transfers or small data transfers via a pre-configured PUSCH.

[0167] *RRCResumeRequest / RRCResumeRequest1 contains RRCResumeRequest (or a new RRC message), resumeIdentity, ResumeMAC-I, resumeCause, and the NAS container. The NAS container contains UL data.

[0168] *New MAC CE (resumeIdentity, ResumeMAC-I) + uplink data (on DTCH). resumeIdentity is used for UE identification. ResumeMAC-I is used for security.

[0169] Details of the pre-configured PUSCH resources in Example 2-1-SDT

[0170] Related communities

[0171] In an embodiment, the pre-configured PUSCH resource configuration of the SDT received in the dedicated signaling is valid in the cell from which the UE receives the configuration.

[0172] In an embodiment, the gNB can also signal the pre-configured PUSCH resources of the SDT of multiple cells in a dedicated signaling.

[0173] Signaling may include pre-configured PUSCH resource settings and associated identification of one or more cells.

[0174] One configuration can be mapped to multiple cells.

[0175] *For configurations associated with cells from which the RRRCRelease message is received, cell identification can be skipped.

[0176] Associated BWP

[0177] In an embodiment, the pre-configured PUSCH resource configuration of the SDT received in the dedicated signaling is applied to the initial UL BWP (or the pre-configured PUSCH resource configuration of the SDT is used for the initial UL BWP or the pre-configured PUSCH resource configuration of the SDT is signaled for the initial UL BWP).

[0178] In an alternative embodiment, the applicable BWP (one of the BWPs configured in the RRCReconfiguration message, whose BWP uses a pre-configured PUSCH resource configuration) can be informed in an RRC message (e.g., RRCRelease, RRCReconfiguration, or SI message). In this embodiment, the BWP configuration may include an indicator indicating that the BWP is applied to the SDT using the pre-configured PUSCH resource configuration. In this embodiment, the BWP using the pre-configured PUSCH resource configuration is the BWP whose configuration includes the pre-configured PUSCH resource configuration of the SDT. If no applicable BWP is informed, the pre-configured PUSCH resource configuration of the SDT received in the dedicated signaling will be applied to the initial UL BWP.

[0179] Alternatively, frequency domain information based on absolute values ​​can also be communicated using signals.

[0180] Associated UL carrier

[0181] In this embodiment, the pre-configured PUSCH resources of SDT are configured for NUL and SUL respectively.

[0182] To optimize signaling, if the SUL and NUL configurations are the same, the SUL configuration can be skipped, and if the SUL is configured in the cell, the UE will apply the NUL configuration to the SUL.

[0183] The connection between SSB and UL authorization

[0184] When the system is deployed at a higher frequency, the UE needs to know the relationship between SSB and configuration authorization (i.e., PUSCH timing / resources).

[0185] In the RRC_INACTIVE state, the UE can only measure the SSB, so the configured authorization is associated with the SSB.

[0186] In this disclosure, the following options are proposed for associating an authorization with an SSB:

[0187] - Option 1: Signaling includes an authorization configuration for the UL carrier used in SDT.

[0188] *1-1: A list of one or more SSB IDs associated with the authorization configuration (or PUSCH resource configuration) is signaled.

[0189] *1-2: The authorization configuration is associated with all transmitted SSBs in the cell, where the transmitted SSBs are determined by the parameter ssb-PositionsInBurst.

[0190] *In the embodiment, if i = [floor(CURRENT_symbol / periodicity)]modulo N1, then the UL authorization is associated with the i-th SSB, where,

[0191] **CURRENT_symbol = [SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + number of slots in the frame × numberOfSymbolsPerSlot + number of symbols in the slots]

[0192] **numberOfSlotsPerFrame and numberOfSymbolsPerSlot** refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively. numberOfSlotsPerFrame is specific to the SCS and is predefined for each SCS. An SCS is the SCS of the UL BWP associated with the configuration license.

[0193] **The cycle (in symbols) is the cycle in which UL authorization is configured and signaled.

[0194] **SFN is a system frame number assigned with configured UL authorization.

[0195] **The slot number is the starting slot for the configured UL authorization.

[0196] The symbol is the starting symbol for the configured UL authorization.

[0197] **N1 = Number of SSBs

[0198] **SSBs are mapped in ascending order of their SSB IDs.

[0199] Figure 2 An example illustrating the association between synchronization signal blocks and uplink grants (PUSCH timing / resources) according to embodiments of the present disclosure is shown.

[0200] refer to Figure 2 Each UL authorization / PUSCH timing is associated with a Service Stub (SSB). The time period on which each SSB maps to a UL authorization / PUSCH timing can be called the associated time period, where the associated time period is a multiple of the configured authorization cycle. Figure 2 In this context, the associated time periods include four time periods for configuration authorization. It's important to note that each UL authorization / PUSCH timing can be mapped to one or more SSBs. Figure 2 In this process, each UL authorization / PUSCH opportunity is mapped to an SSB.

[0201] - Option 2: Signaling includes multiple licensed configurations for the UL carrier.

[0202] *In this option, a list of one or more SSB IDs associated with the authorization configuration is signaled in the corresponding configuration. Each UL authorization in the authorization configuration is associated with an SSB in the list.

[0203] Figure 3 Another example illustrating the association between a synchronization signal block and an uplink grant according to an embodiment of this disclosure is shown.

[0204] refer to Figure 3 Each authorization configuration is mapped to one SSB. Therefore, all UL authorization / PUSCH events for that configuration's authorization configuration are mapped to the same SSB. If an authorization configuration is mapped to multiple SSBs, the SSBs can be like... Figure 2 In this way, the UL grant / PUSCH times are mapped sequentially. If the UL grant / PUSCH times in the grant configuration are also frequency-division multiplexed, the UL grant / PUSCH times can be mapped first by frequency, and then by time.

[0205] Example 2-2 - Standard for determining whether to use pre-configured PUSCH resources for SDT

[0206] The UE can perform SDT using pre-configured PUSCH resources (or CG resources) if the following conditions are met. In different embodiments, a subset of the following conditions may be applied.

[0207] Condition 1: The upper layer requests to restore the RRC connection, and the restoration request is for a mobile-originating call, and the establishment reason is mo-Data; or the upper layer requests to restore the RRC connection, and the restoration request is for a mobile-originating call; or the restoration request is for a mobile-originating call.

[0208] Condition 2: The UE supports SDT.

[0209] Condition 3: During the previous pause procedure, the pre-configured PUSCH resources were signaled with a pause indication in the RRCRelease message, and the UE is in the same cell from which it received the pre-configured PUSCH resources.

[0210] Condition 4: During the previous pause procedure, the UE had a stored value of nextHopChainingCount provided in the RRCRelease message with a pause indication. This condition can be skipped if nextHopChainingCount is always provided in the RRCRelease message.

[0211] Condition 5: If the LCH restrictions of LCP apply to SDT, and according to the LCH restrictions, all LCHs whose data can be used for transmission are allowed to be multiplexed in the MAC PDU of the pre-configured PUSCH resources of SDT.

[0212] It should be noted that the network can also indicate DRBs where SDT is allowed. In this case, the LCH corresponding to its SDT-allowed DRB is considered in condition 5. If data is available for transmission in DRBs other than its SDT-allowed DRBs, the UE should initiate connection restoration without SDT. In this embodiment, condition 5 is not used to determine whether SDT is allowed.

[0213] Condition 6: The UE has a valid TA value.

[0214] Configure the SDT-TimeAlignmentTimer on the network. The SDT-TimeAlignmentTimer starts when it receives the SDT-TimeAlignmentTimer configuration from the network. The SDT-TimeAlignmentTimer is restarted when it receives a timing advance command from the MAC control element or a timing advance adjustment indication from the PDCCH.

[0215] *If SDT-TimeAlignmentTimer is running; and

[0216] *If the SS-RSRP (SS reference signal received power is the linear average of the power contributions of the resource elements carrying the secondary synchronization signal) of the path loss reference (i.e., SSB) has not increased by more than rsrp-IncreaseThresh since the last SDT-TimeAlignmentTimer start; and

[0217] *If the SS-RSRP of the path loss reference (i.e., SSB) has not decreased by more than rsrp-DecreaseThresh since the last SDT-TimeAlignmentTimer start:

[0218] **TA is considered valid.** The SSB whose SS-RSRP is measured for TA authentication is either one of the SSBs transmitted in the camped cell, or one of the SSBs associated with a pre-configured PUSCH resource, or one of the SSBs associated with a pre-configured PUSCH resource that is also transmitted in the camped cell. In the presence of multiple such SSBs, the SS-RSRP of the best SSB (i.e., the one with the highest SS-RSRP value) can be used for TA authentication.

[0219] - Condition 7: The UE has at least one SSB whose SS-RSRP is higher than a threshold among the SSBs associated with the pre-configured PUSCH resources of the UL carrier / UL BWP selected for SDT using pre-configured PUSCH resources. If the RSRP of the downlink path loss reference is less than rsrp-ThresholdSSB-SUL, then SUL is selected for SDT using pre-configured PUSCH resources. Otherwise, NUL is selected for SDT using pre-configured PUSCH resources. In this embodiment, condition 7 is not used to determine whether SDT is used.

[0220] - Condition 8: If the size of the MAC PDU to be sent is less than or equal to the transport block size (TBS) of the pre-configured PUSCH resource, or the size of the available data is less than or equal to the data volume threshold (the data volume threshold is signaled by the gNB). One of the following options can be used to configure the TBS of the SDT using the pre-configured PUSCH resource and determine whether the pre-configured PUSCH resource is used for small data transfers or normal connection recovery.

[0221] Example 2-2-1 – Option 1: Single PUSCH configuration (for UL carrier of the camped cell) and threshold not based on signal quality

[0222] The gNB configures a single PUSCH configuration for the SDT (for the UL carrier of the camped cell). The TBS is not explicitly notified by signaling, but is determined based on the number of SCS, PRB, and OFDM symbols of the PUSCH resource. The TBS can also be explicitly notified by signaling.

[0223] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload configured according to the PUSCH on the selected UL carrier for transmission, then:

[0224] *The UE uses pre-configured PUSCH resources to initiate small data transmissions.

[0225] -otherwise

[0226] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0227] Example 2-2-2 – Option 2: Single PUSCH configuration (for UL carrier of the camped cell) and single RSRP threshold

[0228] The gNB configures the single PUSCH configuration of the SDT (for the UL carrier of the camped cell). The TBS is not explicitly signaled, but is determined based on the number of SCS, PRB, and OFDM symbols of the PUSCH resource. The TBS can also be explicitly signaled. The gNB also configures the parameter sdt-Threshold. Because the UL coverage of SUL and NUL is different, these parameters are configured separately for SUL and NUL.

[0229] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload configured according to the PUSCH on the selected UL carrier for transmission, and the RSRP of the downlink path loss reference is greater than or equal to sdt-Threshold, then:

[0230] *The UE uses pre-configured PUSCH resources to initiate small data transmissions.

[0231] -otherwise

[0232] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0233] Example 2-2-3-Option 3: Multiple [PUSCH Configuration, Threshold]

[0234] The gNB configures the SDT parameters PUSCH-Config-SDT-1 and PUSCH-Config-SDT-2 for PUSCH configuration (used for the UL carrier of the camped cell). The TBS is not explicitly signaled but determined based on the number of SCS, PRB, and OFDM symbols in the PUSCH resource. The TBS can also be explicitly signaled. sdt-Threshold-1 is also configured. Because SUL and NUL have different UL coverage, these parameters are configured separately for SUL and NUL.

[0235] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload in PUSCH-Config-SDT-1 based on the SDT selected for transmission on the UL carrier, then:

[0236] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-1 to initiate small data transmissions.

[0237] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-2 for the selected UL carrier, and the RSRP of the downlink path loss reference is greater than or equal to sdt-Threshold-2, then

[0238] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0239] -otherwise

[0240] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0241] This option is universal, where gNB configuration parameters PUSCH-Config-SDT-1 to PUSCH-Config-SDT-N; sdt-Threshold-2 to sdt-Threshold-N

[0242] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload in PUSCH-Config-SDT-1 based on the SDT selected for transmission on the UL carrier, then

[0243] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-1 to initiate small data transmissions.

[0244] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-2 for the selected UL carrier, and the RSRP of the downlink path loss reference is greater than or equal to sdt-Threshold-2, then

[0245] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0246] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is greater than the TB size of the payload according to PUSCH-Config-SDT-2, and (in one embodiment, 'greater than the TB size of the payload according to PUSCH-Config-SDT-2' can be removed) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-3 based on the SDT selected for transmission on the UL carrier, and the downlink path loss reference RSRP is greater than or equal to sdt-Threshold-3, then

[0247] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0248] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is greater than the TB size of the payload according to PUSCH-Config-SDT-N-1, and (in one embodiment, 'greater than the TB size of the payload according to PUSCH-Config-SDT-N-1' can be removed) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-N of the SDT selected for transmission on the UL carrier, and the downlink path loss reference RSRP is greater than or equal to sdt-Threshold-N, then

[0249] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-N to initiate small data transmissions.

[0250] -otherwise:

[0251] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0252] Example 2-2-3A-Option 3A

[0253] The gNB configures parameters PUSCH-Config-SDT-1 and PUSCH-Config-SDT-2 in the SDT PUSCH configuration (for the UL carrier of the camped cell). The TBS is not explicitly signaled, but determined based on the number of SCS, PRB, and OFDM symbols in the PUSCH resource. The TBS can also be explicitly signaled. sdt-Threshold-1 and sdt-Threshold-2 are also configured. Because SUL and NUL have different UL coverage, these parameters are configured separately for SUL and NUL.

[0254] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload in PUSCH-Config-SDT-1 based on the SDT selected for transmission on the UL carrier, and the RSRP of the downlink path loss reference is greater than or equal to sdt-Threshold-1, then:

[0255] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-1 to initiate small data transmissions.

[0256] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is greater than the TB size of the payload according to PUSCH-Config-SDT-1, and (in one embodiment, 'greater than the TB size of the payload according to PUSCH-Config-SDT-1' can be removed) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-2 based on the selected UL carrier, and the downlink path loss reference RSRP is greater than or equal to sdt-Threshold-2, then

[0257] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0258] -otherwise

[0259] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0260] This option is universal, where gNB configuration parameters PUSCH-Config-SDT-1 to PUSCH-Config-SDT-N; sdt-Threshold-1 to sdt-Threshold-N.

[0261] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload in PUSCH-Config-SDT-1 based on the SDT selected for transmission on the UL carrier, and the RSRP of the downlink path loss reference is greater than or equal to sdt-Threshold-1, then

[0262] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-1 to initiate small data transmissions.

[0263] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is greater than the TB size of the payload according to PUSCH-Config-SDT-1, and (in one embodiment, 'greater than the TB size of the payload according to PUSCH-Config-SDT-1' can be removed) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-2 based on the selected UL carrier, and the downlink path loss reference RSRP is greater than or equal to sdt-Threshold-2, then

[0264] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0265] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is greater than the TB size of the payload according to PUSCH-Config-SDT-N-1, and (in one embodiment, 'greater than the TB size of the payload according to PUSCH-Config-SDT-N-1' can be removed) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-N of the SDT selected for transmission on the UL carrier, and the downlink path loss reference RSRP is greater than or equal to sdt-Threshold-N, then

[0266] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-N to initiate small data transmissions.

[0267] -otherwise:

[0268] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0269] Example 2-2-4-Option 4: Multiple [TBS]

[0270] The gNB configures parameters PUSCH-Config-SDT-1 and PUSCH-Config-SDT-2 in the SDT PUSCH configuration (for the UL carrier of the camped cell). The TBS is not explicitly signaled, but determined based on the number of SCS, PRB, and OFDM symbols in the PUSCH resource. The TBS can also be explicitly signaled. Because SUL and NUL have different UL coverage, these parameters are configured separately for SUL and NUL.

[0271] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-1, then:

[0272] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-1 to initiate small data transmissions.

[0273] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-2, then

[0274] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0275] -otherwise

[0276] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0277] This option is universal, with gNB configuration parameters PUSCH-Config-SDT-1 and PUSCH-Config-SDT-N.

[0278] - If the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-1, then

[0279] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-1 to initiate small data transmissions.

[0280] Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-2, then

[0281] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-2 to initiate small data transmissions.

[0282] - Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-3, then

[0283] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-3 to initiate small data transmissions.

[0284] - Otherwise, if the message size (the UL data available for transmission plus the MAC header, and MAC control elements if necessary) is less than or equal to the TB size of the payload according to PUSCH-Config-SDT-N, then

[0285] * The UE uses the pre-configured PUSCH resources in PUSCH-Config-SDT-N to initiate small data transmissions.

[0286] -otherwise:

[0287] *The UE does not use pre-configured PUSCH resources to initiate small data transmissions. If the RACH-based standard for performing SDT is met, the UE can use RACH to initiate small data transmissions.

[0288] Example 2-3 - PDCCH Monitoring When Sending Small Data in Pre-configured PUSCH Resources

[0289] When sending uplink data in the pre-configured PUSCH resources, the UE needs to monitor the PDCCH to obtain a network response.

[0290] Search Space: The UE needs to know the search space for monitoring the PDCCH. One of the following options can be used to determine the search space for monitoring the PDCCH in the network response of the SDT using pre-configured PUSCH resources.

[0291] - Option 1: The sdt-SearchSpaceCG of the SDT using pre-configured PUSCH resources can be signaled by the network in the RRRCRelease message along with the pre-configured PUSCH resources.

[0292] *1-1:sdt-SearchSpaceCG indicates one of the search spaces in its BWP ID, which is the same as the initial DL BWP or DL ​​BWP selected for using the pre-configured PUSCH resources in the SDT's UL BWP or DL ​​BWP.

[0293] *1-2: sdt-SearchSpaceCG indicates one of the search spaces in its BWP ID and the PDCCH-Config IE of the initial DL BWP or DL ​​BWP that is the same as the UL BWP of the SDT selected to use the pre-configured PUSCH resources.

[0294] - Option 2: sdt-SearchSpaceCG can be signaled by the network in the initial DL BWP configuration (PDCCH-ConfigCommonIE or PDCCH-Config IE) or its BWP ID is the same as the UL BWP selected for using the pre-configured PUSCH resources in the DL BWP configuration.

[0295] -sdt-SearchSpaceCG indicates the search space ID (in the list of search space configurations) to be used for PDCCH monitoring.

[0296] - The UE uses the RX beam corresponding to the SSB associated with the UL license transmitted to the UE to monitor the search space.

[0297] RNTI: The UE needs to know the RNTI to monitor the PDCCH. The UE can monitor the PDCCH addressed to the C-RNTI, where the C-RNTI is the C-RNTI used by the UE in the cell from which it receives pre-configured PUSCH resources. Alternatively, the C-RNTI can be allocated along with the pre-configured PUSCH resources (e.g., in the RRCrease message).

[0298] Monitoring Time: The UE needs to know the time interval for monitoring responses. The timer can be configured by the network along with pre-configured PUSCH resources. The timer can start at the end of a PUSCH transmission, at the first PDCCH monitoring event after the PUSCH transmission ends, or at a fixed offset after the PUSCH transmission ends. The timer is stopped if the UE receives a PDCCH addressed to C-RNTI and the TB is successfully decoded.

[0299] Retransmission processing.

[0300] - Option 1: No retransmission. If the timer expires, SDT is considered to have failed.

[0301] Option 2: Timer-based retransmission: If the UE has not yet sent the MAC PDU the configurable number of times, the UE uses the pre-configured PUSCH resources to retransmit the generated MAC PDU. If the UE has already sent the MAC PDU the configurable number of times, the SDT is considered to have failed.

[0302] During a retransmission, the UE first selects an SSB (in this embodiment, the UE uses the same SSB selected during the first transmission); then, the UE selects a PUSCH resource corresponding to the selected SSB; then, the UE transmits in the selected PUSCH resource; the UE starts a watch timer and waits for a response (i.e., the PDCCH addressed to the C-RNTI). If UCI is supported, the UE can indicate a new transmission / retransmission in the UCI. Redundancy versions (RVs) can be predefined for each transmission / retransmission.

[0303] *During retransmission, a power boost can be performed on the PUSCH transmission. The power of the previous transmission can be increased through a power boost step. The power boost step is signaled by the gNB.

[0304] - Option 3: Retransmission triggered by the network:

[0305] *If the UE uses pre-configured PUSCH resources to receive the PDCCH of the C-RNTI addressed to the HARQ retransmission for the HARQ procedure used in SDT, the UE performs a HARQ retransmission. The PDCCH indicates the UL authorization for the retransmission. The HARQ procedure for SDT using pre-configured PUSCH resources can be signaled in the SDT configuration or can be predefined.

[0306] The UE restarts the monitoring timer and waits for a response.

[0307] *The UE continues to use the SSB selected during the initial transmission.

[0308] *During retransmissions, a power boost can be performed on the PUSCH transmission. The power of the previous transmission can be increased through a power boost step. The power boost step is signaled by the gNB.

[0309] In response to small data transmissions, the UE may receive signals (RRC messages or DCI) for the following purposes:

[0310] Release the pre-configured PUSCH or switch to the recovery process (i.e., RRC_CONNECTED).

[0311] Example 2-4 - Release of Pre-configured PUSCH Resources

[0312] Option 1: Timer-based release

[0313] - When a pre-configured PUSCH resource is received in a release message, the timer is (re)started. The pre-configured PUSCH resource is released after the timer expires.

[0314] Option 2: Release after the specified number of occurrences.

[0315] - The MAC entity should discard the immediately pre-configured PUSCH resources after 'N' consecutive associated time periods of unused authorization. The associated time period is equal to the period of the configured authorization * X, where X is the number of SSBs associated with the configured authorization.

[0316] Option 3: Receive RRRCRelease without any pre-configured PUSCH resources or any indication of using previously configured resources.

[0317] Option 4: Release when the cell changes

[0318] Option 5: Release when connection is restored

[0319] Option 6: The gNB may want to release the pre-configured PUSCH of inactive UEs. Then, RAN paging can be used. New fields can be introduced in the RAN paging. If the UE receives a RAN paging with the new fields, the UE releases the pre-configured PUSCH, but does not need to switch to RRC_CONNECTED.

[0320] Example 2-5 - Signaling Flow Without Context Acquisition

[0321] Figure 4 A flowchart illustrating small data transmission using pre-configured uplink resources according to an embodiment of the present disclosure is shown.

[0322] refer to Figure 4 In this case, it is assumed that the gNB has the context of the UE.

[0323] 0. Meets the criteria for initiating an SDT that uses pre-configured PUSCH resources.

[0324] 1. In operation 410, in the pre-configured PUSCH resource, the UE sends RRCResumeRequest / RRCRResumeRequest1 to the gNB on SRB 0 (the same as the last serving gNB). This request includes a full / short I-RNTI (resumeIdentity), a resume cause, and an authentication token (resumeMAC-I). The I-RNTI (short or full I-RNTI) is used for context identification, and its value should be the same as the I-RNTI received by the UE from the last serving gNB in ​​the RRCResume message with suspendConfig. ResumeMAC-I is a 16-bit message authentication token, which the UE should compute using an integrity algorithm (NIA or EIA) from the stored AS security context, negotiated between the UE and the last serving gNB, and KRRCint comes from the stored AS security context with the following inputs:

[0325] -KEY: Should be set to the current KRRCint.

[0326] -BEARER: All bits should be set to 1.

[0327] -DIRECTION: Should be set to 1.

[0328] -COUNT: All bits should be set to 1.

[0329] -MESSAGE: Should be set to VarResumeMAC-Input, which has the following inputs:

[0330] *Source PCI (set to the physical cell identification of the PCell to which the UE was connected before the RRC connection was suspended)

[0331] *Target Cell-ID (set as the cellIdentity of the first PLMN-Identity included in the PLMN-IdentityInfoList broadcast in SIB1 of the target cell (i.e., the cell in which the UE transmits small data))

[0332] *Source C-RNTI (set to the C-RNTI that the UE had in the PCell it was connected to before its RRC connection was suspended).

[0333] The UE restores all SRBs and DRBs, uses the NextHopChainingCount provided in the RRCLease message of the previous RRC connection to derive a new security key, and re-establishes AS security. User data is encrypted and integrity protected (only for DRBs configured with UP integrity protection) and transmitted on the DTCH multiplexed with the RRCResumeRequest / RRRCResumeRequest1 message on the CCCH.

[0334] Alternatively, the UE can send small data by using one of the following options:

[0335] -RRCResumeRequest (or a new RRC message). The NAS container is located in resumeIdentity, ResumeMAC-I, resumeCause, RRCResumeRequest / RRCResumeRequest1. The NAS container contains UL data.

[0336] - New MAC CE (resumeIdentity, ResumeMAC-I) + uplink data (on DTCH). resumeIdentity is used for UE identification purposes. ResumeMAC-I is used for security.

[0337] 2. In operation 420, the gNB verifies resumeMAC-I and delivers uplink data to the UPF.

[0338] 3. The gNB sends an RRCRelease message to keep the UE in the RRC_INACTIVE state. The PDCCH is addressed to the C-RNTI. The C-RNTI is the C-RNTI used by the UE in the cell from which it receives pre-configured PUSCH resources. Alternatively, the C-RNTI can be allocated along with pre-configured PUSCH resources. In operation 430, if downlink data is available, then in operation 440, the downlink data is transmitted on the DTCH multiplexed with the RRCRelease message with encryption and integrity protection (only for DRBs configured with UP integrity protection).

[0339] (Replacement 1) Considering the replacement signaling flow, the gNB can schedule UL grant (addressed to the C-RNTI's PDCCH) before RRRCrease. During the UL transmission, the UE can indicate whether it has more data to send. If the UE has more data to send, the gNB can schedule the UL grant. Otherwise, RRRCrease. During the UL transmission, if the SSB indicated by the PRACH preamble is no longer suitable, the UE can also include the SSB ID of an SSB above a threshold.

[0340] (Alternative 2) Alternatively, the gNB may send a PDCCH addressing to the RNTI (i.e., the RNTI is allocated by the gNB along with pre-configured resources; the RNTI can also be allocated to other UEs), and the scheduled DL TB includes the contention resolution identifier (which is the first X bits (e.g., 48 bits) of the recovery message) and the C-RNTI. If it matches the UE's contention resolution identifier, the UE stops monitoring the timer, and the UE can consider the small data transmission successful.

[0341] In the response to small data transmission, the UE may receive signals (RRC messages or DCI) for the following purposes:

[0342] Release the pre-configured PUSCH or switch to the recovery process (i.e., RRC_CONNECTED).

[0343] Example 2-6 – Sample Signaling Flow with Context Acquisition and Path Switching

[0344] Figure 5 A flowchart illustrating small data transmission using pre-configured uplink resources according to an embodiment of the present disclosure is shown.

[0345] refer to Figure 5 In this scenario, it is assumed that the gNB does not have the UE's context and obtains the UE's context from the last serving gNB. A path handover is performed, and the context is released from the last serving gNB. This situation only occurs if the UE uses pre-configured PUSCH resources to transmit in a cell other than the cell from which the UE last received the RRC release message.

[0346] 0. Meets the criteria for initiating an SDT that uses pre-configured PUSCH resources.

[0347] 1. In Operation 510, within the pre-configured PUSCH resources, the UE sends an RCResumeRequest / RRCResumeRequest1 to the gNB on SRB 0 (different from the last serving gNB). This request includes a full / short I-RNTI (resumeIdentity), a resume cause, and an authentication token (resumeMAC-I). The I-RNTI (short or full I-RNTI) is used for context identification, and its value should be the same as the I-RNTI received by the UE from the last serving gNB in ​​the RCRelease message with suspendConfig. ResumeMAC-I is a 16-bit message authentication token. The UE should use the integrity algorithm (NIA or EIA) in the stored AS security context to calculate ResumeMAC-I, which is negotiated between the UE and the last serving gNB, and KRRCint comes from the stored AS security context with the following inputs:

[0348] -KEY: Should be set to the current KRRCint.

[0349] -BEARER: All bits should be set to 1.

[0350] -DIRECTION: Should be set to 1.

[0351] -COUNT: All bits should be set to 1.

[0352] -MESSAGE: Should be set to VarResumeMAC-Input, which has the following inputs:

[0353] *Source PCI (set to the physical cell identification of the PCell to which the UE was connected before the RRC connection was suspended)

[0354] *Target Cell-ID (set as the cellIdentity of the first PLMN-Identity included in the PLMN-IdentityInfoList broadcast in SIB1 of the target cell (i.e., the cell the UE is trying to recover))

[0355] *Source C-RNTI (set to the C-RNTI that the UE had in the PCell it was connected to before its RRC connection was suspended).

[0356] The UE restores all SRBs and DRBs, uses the NextHopChainingCount provided in the RRCConnectionRelease message of the previous RRC connection to derive a new security key, and re-establishes AS security. User data is encrypted and integrity protected (only for DRBs configured with UP integrity protection), and transmitted on the DTCH multiplexed with the RRCResumeRequest / RRRCResumeRequest1 messages on the CCCH.

[0357] 2. The gNB (i.e., the target gNB) identifies the GNB of the last serving gNB (i.e., the source gNB) from the I-RNTI and requests the last serving gNB to provide the UE's context data by sending a Retrieve UE Context Request message including the following: I-RNTI, ResumeMAC-I, and Target Cell-ID, so that the source gNB can verify the UE request and retrieve the UE context in Operation 515.

[0358] 3. The last serving gNB (i.e., the source gNB) verifies resumeMAC-I and provides UE context data.

[0359] The source gNB uses I-RNTI to retrieve the stored UE context, including the UE 5G AS security context, from the database. The source gNB uses the current K stored in the retrieved UE 5G AS security context. RRCint The key is used to verify ResumeMAC-I (which is calculated in the same way as described above). If ResumeMAC-I verification is successful, the source gNB calculates K based on horizontal or vertical key derivation, using the target cell PCI, target ARFCN-DL, and KgNB / NH in the current UE 5G AS security context, depending on whether the source gNB has an unused pair {NCC, NH}. NG-RAN * The source gNB can obtain the target PCI and target ARFCN-DL from the cell configuration database using the target Cell-ID received from the target gNB. Then, in operation 520, the source gNB should respond to the target gNB with an Xn-AP UE context retrieval response message, which includes the UE context containing the UE 5G AS security context. The UE 5G AS security context sent to the target gNB should include the newly derived K NG-RAN *、and K NG-RAN * Associated NCC, UE 5G security capabilities, UP security policies, UP security activation status with corresponding PDU session ID, and encryption and integrity algorithms used by the UE and the source cell.

[0360] 4. If the loss of DL user data buffered in the last-served gNB should be prevented, then in operation 525, the gNB provides a forwarding address.

[0361] 5. In operations 530 and 535, gNB performs path switching.

[0362] 6. In operation 540, the gNB triggers the release of UE resources at the last served gNB.

[0363] 7. In operation 545, the gNB delivers uplink data to the UPF.

[0364] 8.gNB sends an RRCRelease message to keep the UE in the RRC_INACTIVE state. The PDCCH is addressed to the C-RNTI. The C-RNTI is the C-RNTI used by the UE in the cell from which it receives pre-configured PUSCH resources. Alternatively, the C-RNTI can be allocated along with pre-configured PUSCH resources. In operation 550, if downlink data is available, then in operation 555, the downlink data is transmitted on the DTCH multiplexed with the RRCRelease message with encryption and integrity protection (only for DRBs configured with UP integrity protection).

[0365] (Alternative 1) We can consider replacing the signaling flow, where the gNB can schedule UL grant (addressed to the C-RNTI's PDCCH) before RRRCRelease. During the UL transmission, the UE can indicate whether it has more data to send. If the UE has more data to send, the gNB can schedule the UL grant. Otherwise, RRRCRelease. During the UL transmission, if the SSB indicated by the PRACH preamble is no longer suitable, the UE can also include the SSB ID of an SSB above a threshold.

[0366] (Alternative 2) Alternatively, the gNB may send a PDCCH addressing to the RNTI (i.e., the RNTI is allocated by the gNB along with pre-configured resources; the RNTI can also be allocated to other UEs), and the scheduled DL TB includes the contention resolution identifier (which is the first X bits (e.g., 48 bits) of the recovery message) and the C-RNTI. If it matches the UE's contention resolution identifier, the UE stops monitoring the timer, and the UE can consider the small data transmission successful.

[0367] In the response to small data transmission, the UE may receive signals (RRC messages or DCI) for the following purposes:

[0368] Release the pre-configured PUSCH or switch to the recovery process (i.e., RRC_CONNECTED).

[0369] Example 2-7-SDT MAC PDU Generation

[0370] In one method of this disclosure, for small data transfers under RRC_INACTIVE using MsgA or Msg3 or pre-configured PUSCH resources, LCH restrictions are not applied when generating the MAC PDU.

[0371] Figure 6 A flowchart illustrating a Media Access Control (MAC) Protocol Data Unit (PDU) for generating small data transmissions according to an embodiment of the present disclosure is shown.

[0372] refer to Figure 6 If the UL grant is available for the new transmission in operation 610, then in operation 620 it is determined whether the UL grant is used for SDT. If the UL grant is used for SDT, then in operation 640, the UE selects all logical channels (i.e., the logical channels corresponding to the RBs recovered when initiating the small data transmission procedure) to generate a MAC PDU, and in operation 650, the UE applies the LCP procedure to the selected logical channels. Otherwise, in operation 630, the UE selects the logical channels allowed to be transmitted in the UL grant based on at least one of allowedSCS-List, maxPUSCH-Duration, configuredGrantType1Allowed, allowedServingCells, allowedCG-List, or allowedPHY-PriorityIndex used for MAC PDU generation (among the logical channels corresponding to the RBs recovered when initiating the small data transmission procedure).

[0373] Figure 7 A flowchart illustrating the generation of a MAC PDU for small data transmission according to an embodiment of the present disclosure is shown.

[0374] refer to Figure 7The allowedSCS-List and maxPUSCH-Duration are applied to the MAC PDU that generates the SDT. This means that if an LCH is configured with an allowedSCS-List, and the SCSs included in the allowedSCS-List are not UL-authorized SCSs for the SDT, then the LCH will not be selected for the SDT. Similarly, if an LCH is configured with a maxPUSCH-Duration, and the duration included in the allowedSCS-List is not a UL-authorized duration for the SDT, then the LCH will not be selected for the SDT. AllowedServingCells are not applied to the MAC PDU that generates the SDT. ConfiguredGrantType1Allowed is not applied to RACH-based small data transfers, but is allowed for non-RACH-based small data transfers. For non-RACH-based small data transfers, if the LCH is not configured with configuredGrantType1Allowed, then the LCH will not be selected for the SDT.

[0375] Specifically, if the UL grant is available for new transmission in operation 710, then in operation 720 it is determined whether the UL grant is for SDT. If the UL grant is not for SDT, then in operation 730, the UE selects the logical channel allowed to be transmitted in the UL grant based on the allowedSCS-List, maxPUSCH-Duration, configuredGrantType1Allowed, allowedServingCells, allowedCG-List, and allowedPHY-PriorityIndex generated for the MAC PDU. Otherwise, in operation 740, the UE determines whether the UL grant is a pre-configured UL grant. If the UL grant is a pre-configured UL grant, then in operation 770, the UE selects the logical channel allowed to be transmitted in the UL grant based on the allowedSCS-List, maxPUSCH-Duration, and configuredGrantType1Allowed (among the logical channels corresponding to the RBs recovered when initiating the small data transmission procedure), and in operation 760, the UE applies the LCP procedure to the selected logical channel. If the UL grant is not a pre-configured UL grant, then in operation 750, the UE selects a logical channel that is allowed to be transmitted in the UL grant based on the allowedSCS-List and maxPUSCH-Duration (among the logical channels corresponding to the RBs recovered when the small data transmission procedure is initiated), and in operation 760, the UE applies the LCP procedure to the selected logical channel.

[0376] In one method of this disclosure, the network indicates whether LCH restrictions are applied. This indication can be in the RACH configuration of RRCrease or SDT. If the network indicates that LCH restrictions are applied, all LCH restrictions are considered when selecting the LCH for SDT. In embodiments, the applicable restrictions can also be indicated by the network. In this case, the UE applies only the indicated LCH restrictions when selecting the LCH for SDT.

[0377] Figure 8 This is a block diagram of a terminal according to an embodiment of the present disclosure.

[0378] refer to Figure 8 The terminal includes a transceiver 810, a controller 820, and a memory 830. The controller 820 may refer to a circuit, an application-specific integrated circuit (ASIC), or at least one processor. The transceiver 810, controller 820, and memory 830 are configured to execute... Figures 1 to 7 The terminal operation is shown or described above. Although the transceiver 810, controller 820, and memory 830 are shown as separate entities, they can be implemented as a single entity, such as a single chip. Alternatively, the transceiver 810, controller 820, and memory 830 can be electrically connected or coupled to each other.

[0379] Transceiver 810 can send signals to and receive signals from other network entities (e.g., base stations).

[0380] The controller 820 can control the terminal to perform functions according to one of the above embodiments. For example, the controller 820 controls the transceiver 810 and / or the memory 830 to perform small data transmission and reception according to various embodiments of this disclosure.

[0381] In this embodiment, the operation of the terminal can be implemented using a memory 830 that stores the corresponding program code. The terminal may be equipped with a memory 830 to store program code that implements the desired operation. In order to perform the desired operation, the controller 820 may use at least one processor or CPU to read and execute the program code stored in the memory 830.

[0382] Figure 9 This is a block diagram of a base station according to an embodiment of the present disclosure.

[0383] refer to Figure 9 The base station includes a transceiver 910, a controller 920, and a memory 930. The controller 920 may refer to a circuit, an ASIC, or at least one processor. The transceiver 910, controller 920, and memory 930 are configured to perform... Figures 1 to 7The UE operation is shown or described above. Although the transceiver 910, controller 920, and memory 930 are shown as separate entities, they can be implemented as a single entity, such as a single chip. The transceiver 910, controller 920, and memory 930 can be electrically connected or coupled to each other.

[0384] Transceiver 910 can send signals to and receive signals from other network entities (e.g., terminals).

[0385] The controller 920 can control the base station to perform functions according to one of the above embodiments. For example, the controller 920 controls the transceiver 910 and / or the memory 930 to perform small data transmission and reception according to various embodiments of the present disclosure.

[0386] In this embodiment, the operation of the base station can be implemented using a memory 930 that stores the corresponding program code. The base station may be equipped with a memory 930 to store the program code that implements the desired operation. To perform the desired operation, the controller 920 can read and execute the program code stored in the memory 930 using at least one processor or CPU.

[0387] Although this disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made in this disclosure without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

[0388] Although this disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made in this disclosure without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: The base station receives an RRC release message to switch a terminal in the Radio Resource Control (RRC) connected state to the RRC inactive state. The RRC release message includes uplink resource configuration for Small Data Transmission Technique (SDT), where SDT is a data transmission procedure for when the terminal is in the RRC inactive state. The configuration includes a first configuration of uplink resources for at least one configuration of normal uplink NUL and a second configuration of uplink resources for at least one configuration of supplementary uplink SUL. The uplink carrier for SDT is selected between NUL and SUL based on the first reference signal received power (RSRP) threshold associated with the SUL selection. Based on a second RSRP threshold associated with the selection of a synchronization signal block SSB for SDT, an SSB is selected, wherein the SSB includes a primary synchronization signal PSS, a secondary synchronization signal SSS, and a physical broadcast channel PBCH block, and wherein the SSB is associated with at least one configured uplink resource for SDT; and Using the uplink resources configured with the selected SSB, uplink data is transmitted to the base station on the selected uplink carrier.

2. The method according to claim 1, wherein, The SSB is identified based on information about one or more SSB indices notified by the base station via signaling, or information about all received SSBs determined by the parameter ssb-PositionInBurst. Information about one or more SSB indices is associated with the configuration of uplink resources for at least one configuration of the selected uplink carrier.

3. The method according to claim 1, further comprising: The Physical Downlink Control Channel (PDCCH), addressed to the Cell Radio Network Temporary Identifier (C-RNTI), is monitored in response to the uplink data. Among them, information regarding the PDCCH configuration of the initial downlink bandwidth portion (BWP) of the selected uplink carrier is received from the base station, and The information regarding PDCCH configuration includes information about the SDT search space used to monitor PDCCH.

4. The method according to claim 1, in, The first reference RSRP threshold associated with SUL selection and the second reference RSRP threshold associated with SSB selection for SDT are configured from the base station.

5. A method performed by a base station in a wireless communication system, the method comprising: An RRC release message is sent to the terminal to switch the terminal from a Radio Resource Control (RRC) connected state to an RRC inactive state. The RRC release message includes uplink resource configuration for Small Data Transmission (SDT) configuration, where SDT is a data transmission procedure used when the terminal is in an RRC inactive state. The configuration includes a first configuration of uplink resources for at least one configuration of Normal Uplink (NUL) and a second configuration of uplink resources for at least one configuration of Supplemental Uplink (SUL). Based on the uplink resources configured with the synchronization signal block SSB, uplink data is received from the terminal on the uplink carrier used for SDT. The SSB includes the primary synchronization signal PSS, the secondary synchronization signal SSS, and the physical broadcast channel PBCH block. The uplink carrier used for SDT is selected from NUL and SUL based on a first reference signal received power (RSRP) threshold associated with SUL selection. Wherein, the SSB is selected from the SSBs based on a second RSRP threshold associated with the SSB selection used for SDT, and The SSB is associated with an uplink resource configured for at least one SDT.

6. The method according to claim 5, further comprising: in, Information regarding the physical downlink control channel (PDCCH) configuration of the initial downlink bandwidth portion (BWP) of the selected uplink carrier is sent to the terminal, and The information regarding PDCCH configuration includes information about the SDT search space used to monitor the PDCCH for responses to uplink data.

7. The method according to claim 5, in, The SSB is identified based on information about one or more SSB indices notified by the base station via signaling, or information about all transmitted SSBs determined by the parameter ssb-PositionInBurst. Information about one or more SSB indices is associated with the configuration of uplink resources for at least one configuration of the selected uplink carrier, and The first reference RSRP threshold associated with SUL selection and the second reference RSRP threshold associated with SSB selection for SDT are configured from the base station.

8. A terminal in a wireless communication system, the terminal comprising: transceiver; as well as The controller is configured as follows: The transceiver receives from the base station an RRC release message that switches a terminal in a Radio Resource Control (RRC) connected state to an RRC inactive state. The RRC release message includes uplink resource configuration for Small Data Transmission Techniques (SDT), where SDT is the data transmission procedure for a terminal in an RRC inactive state. The configuration includes a first configuration of uplink resources for at least one configuration of Normal Uplink (NUL) and a second configuration of uplink resources for at least one configuration of Supplemental Uplink (SUL). The uplink carrier for SDT is selected between NUL and SUL based on the first reference signal received power (RSRP) threshold associated with the SUL selection. Based on a second RSRP threshold associated with the selection of a synchronization signal block (SSB) for SDT, an SSB is selected, wherein the SSB includes a primary synchronization signal (PSS), a secondary synchronization signal (SSS), and a physical broadcast channel (PBCH) block, and wherein the SSB is associated with at least one configured uplink resource for SDT. Using the uplink resources configured with the selected SSB, uplink data is transmitted to the base station via a transceiver on the selected uplink carrier.

9. The terminal according to claim 8, wherein, The SSB is identified based on information about one or more SSB indices notified by the base station via signaling, or information about all received SSBs determined by the parameter ssb-PositionInBurst. Information about one or more SSB indices is associated with the configuration of uplink resources for at least one configuration of the selected uplink carrier.

10. The terminal according to claim 8, in, The controller is also configured to monitor the Physical Downlink Control Channel (PDCCH), addressed to the Cell Radio Network Temporary Identifier (C-RNTI), used in response to the uplink data. Among them, information regarding the PDCCH configuration of the initial downlink bandwidth portion (BWP) of the selected uplink carrier is received from the base station, and The information regarding PDCCH configuration includes information about the SDT search space used to monitor PDCCH.

11. The terminal according to claim 8, in, The first reference RSRP threshold associated with SUL selection and the second reference RSRP threshold associated with SSB selection for SDT are configured from the base station.

12. A base station in a wireless communication system, the base station comprising: transceiver; as well as The controller is configured as follows: An RRC release message is sent to the terminal via a transceiver to switch the terminal from a Radio Resource Control (RRC) connected state to an RRC inactive state. The RRC release message includes uplink resource configuration for Small Data Transmission (SDT) configuration, where SDT is a data transmission procedure for when the terminal is in an RRC inactive state. The configuration includes a first configuration of uplink resources for at least one configuration of Normal Uplink (NUL) and a second configuration of uplink resources for at least one configuration of Supplemental Uplink (SUL). Based on the uplink resources configured with the synchronization signal block SSB, uplink data is received from the terminal on the uplink carrier used for SDT. The SSB includes the primary synchronization signal PSS, the secondary synchronization signal SSS, and the physical broadcast channel PBCH block. The uplink carrier used for SDT is selected from NUL and SUL based on a first reference signal received power (RSRP) threshold associated with SUL selection. Wherein, the SSB is selected from the SSBs based on a second RSRP threshold associated with the SSB selection used for SDT, and The SSB is associated with an uplink resource configured for at least one SDT.

13. The base station according to claim 12, in, The SSB is identified based on information about one or more SSB indices notified by the base station via signaling, or information about all transmitted SSBs determined by the parameter ssb-PositionInBurst. Information about one or more SSB indices is associated with the configuration of uplink resources for at least one configuration of the selected uplink carrier.

14. The base station according to claim 12, in, Information regarding the physical downlink control channel (PDCCH) configuration of the initial downlink bandwidth portion (BWP) of the selected uplink carrier is sent to the terminal, and The information regarding PDCCH configuration includes information about the SDT search space used to monitor the PDCCH for responses to uplink data.

15. The base station according to claim 12, wherein, The first reference RSRP threshold associated with SUL selection and the second reference RSRP threshold associated with SSB selection for SDT are configured from the base station.

Images