User equipment device and base station device

Abstract

User equipment (UE) apparatuses and base station apparatuses for wireless communications with base stations are provided. A UE apparatus includes a transceiver and a processor. The processor is configured to transmit, to a base station via the transceiver, at least one uplink (UL) data packet in a radio resource control (RRC) inactive state based on a preconfigured UL resource (PUR) configuration, wherein the PUR configuration is defined according to a set of PUR parameters, wherein the set of PUR parameters includes: a control resource set (CORESET) configuration including an aggregation level and a repetition type; a physical UL shared channel (PUSCH) repetition configuration including a frequency hopping pattern; or at least one of an UL narrow beam direction for frequency range 2 (FR2) or a transmission reception point (TRP) association, and wherein the set of PUR parameters is associated with new radio (NR).

Description

[0001] Cross-references to related applications

[0002] This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 056,931, filed July 27, 2020, and U.S. Patent Application No. 17 / 357,489, filed June 24, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to methods and apparatus for data transmission using pre-configured uplink resources, and in particular, to a user terminal apparatus and a base station apparatus. Background Technology

[0004] In some systems, particularly in degraded new radio (NR) equipment, a large number of user equipment (UEs) may use pre-configured resources. For example, industrial sensors or video surveillance sensors may use configured grant type 1 resources to generate persistent (or semi-persistent) periodic uplink (UL) traffic. Pre-configured resources from many degraded (RedCap) UEs may reduce the network's flexibility to accommodate / multiplex these pre-occupied / pre-configured resources (e.g., control resource sets / search space sets, semi-persistent scheduling (SPS) resources, or configured grant resources) for other UEs (e.g., enhanced mobile broadband (eMBB) users or ultra-reliable low latency communication (URLLC) users). Especially in frequency range 2 (FR2) (e.g., 24,250 MHz – 52,600 MHz), if two UEs use fifth-generation (5G) base stations (gNBs) where the transmit or receive beams point in different directions, the pre-emption of pre-configured resources can be complex and time-consuming.

[0005] Therefore, in the Radio Resource Control (RRC)_INACTIVE state, the activation / deactivation and reconfiguration of pre-configured resources are crucial for providing flexibility in scheduling other UEs, especially under congestion conditions. To optimize spectral efficiency and link-level performance, new, efficient mechanisms should be considered to adjust / update at least some parameters in the NR pre-configured UL parameters, particularly to address changing radio conditions and service patterns. SUMMARY

[0006] The present disclosure is to address the problems and disadvantages mentioned above, and to provide at least the advantages described below.

[0007] According to an aspect of the disclosure, a UE for wireless communication with a base station is provided. The UE includes a transceiver and a processor. The processor is configured to transmit, to the base station via the transceiver, at least one UL data packet in an RRC inactive state based on a preconfigured UL resource (PUR) configuration, wherein the PUR configuration is defined according to a set of PUR parameters, wherein the set of PUR parameters includes at least one of: a CORESET configuration including an aggregation level and a repetition type; a physical UL shared channel (PUSCH) repetition configuration including a frequency hopping pattern; or an UL narrow beam direction or a transmission reception point (TRP) association for FR2, and wherein the set of PUR parameters is associated with NR.

[0008] According to another aspect of the disclosure, a base station apparatus for wireless communication with a UE is provided. The base station apparatus includes a transceiver and a processor. The processor is configured to receive, from the UE via the transceiver, at least one UL data packet in an RRC inactive state based on a PUR configuration, wherein the PUR configuration is defined according to a set of PUR parameters, wherein the set of PUR parameters includes at least one of: a CORESET configuration including an aggregation level and a repetition type; a PUSCH repetition configuration including a frequency hopping pattern; or an UL narrow beam direction or a TRP association for FR2, and wherein the set of PUR parameters is associated with NR.

[0009] According to another aspect of the disclosure, a UE for wireless communication with a base station is provided. The UE includes a transceiver and a processor. The processor is configured to receive, via the transceiver, signaling information from the base station to reconfigure a PUR for transmitting at least one UL data packet to the base station in an RRC inactive state, wherein the PUR reconfiguration is defined according to a set of PUR parameters, wherein the set of PUR parameters includes at least one of resource allocation in a frequency domain, a time domain, or a spatial domain, PUR configuration including an aggregation level and a repetition type, PUSCH repetition configuration including a frequency hopping pattern, a periodicity of the PUR, a modulation and coding scheme (MCS), a transport block size (TBS), an UL narrow beam direction or TRP association for FR2, activation or deactivation of the PUR, a transmit (Tx) power adjustment or a time alignment (TA), and wherein the set of PUR parameters is associated with NR.

[0010] According to another aspect of the disclosure, a base station apparatus for wireless communication with a UE is provided. The base station apparatus includes a transceiver and a processor. The processor is configured to transmit, via the transceiver, signaling information to the UE to reconfigure a PUR for receiving at least one UL data packet from the UE in an RRC inactive state, wherein the PUR reconfiguration is defined according to a set of PUR parameters, wherein the set of PUR parameters includes at least one of resource allocation in a frequency domain, a time domain, or a spatial domain, PUR configuration including an aggregation level and a repetition type, PUSCH repetition configuration including a frequency hopping pattern, a periodicity of the PUR, a MCS, a TBS, an UL narrow beam direction or TRP association for FR2, activation or deactivation of the PUR, a Tx adjustment or a TA. BRIEF DESCRIPTION OF DRAWINGS

[0011] The above and other aspects, features, and advantages of certain embodiments of the disclosure will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0012] Figure 1 NR RRC connection state transitions according to embodiments are shown;

[0013] Figure 2 UL data transmission procedures according to embodiments are shown;

[0014] Figure 3A NR UL configured grant Type 1 providing UL grant by RRC transmission according to embodiments is shown;

[0015] Figure 3B NR UL configured grant Type 2 providing UL grant by RRC transmission according to embodiments is shown;

[0016] Figure 4 is a Layer 2 (L2) / Layer 3 (L3) solution for NR PUR reconfiguration according to an embodiment;

[0017] Figure 5 is a Layer 1 (L1) solution for NR PUR reconfiguration according to an embodiment;

[0018] Figure 6 shows a scenario according to an embodiment in which a RedCap UE is in half duplex (HD)-frequency division duplex (FDD) or time-division duplex (TDD) in frequency range 1 (FR1) (e.g., 410 MHz - 7,125 MHz) and coexists with eMBB traffic;

[0019] Figure 7 shows a scenario according to an embodiment in which a RedCap UE is in TDD in FR2 and coexists with eMBB traffic;

[0020] Figure 8 shows a scenario according to an embodiment in which a RedCap UE is in HD-FDD or TDD in FR1 and coexists with eMBB traffic;

[0021] Figure 9 is a flowchart showing a method of configuring PUR for UL data transmission according to an embodiment; and

[0022] Figure 10 shows an electronic device in a network environment according to an embodiment. DETAILED DESCRIPTION

[0023] Hereinafter, embodiments of the disclosure will be described in detail with reference to the accompanying drawings. It should be noted that although the same elements are shown in different drawings, they will be denoted by the same reference numerals. In the following description, specific details such as detailed configuration and components are provided only in order to assist in a thorough understanding of the embodiments of the disclosure. Therefore, it will be apparent to those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope of the disclosure. Also, descriptions of well-known functions and structures are omitted for clarity and conciseness. The terms described below are terms defined in consideration of the functions in the disclosure, and can differ according to users, user's intentions, or habits. Therefore, the definition of the terms should be determined according to the contents of the specification.

[0024] The present disclosure can have various modifications and various embodiments, wherein the embodiments will be described in detail below with reference to the accompanying drawings. However, it should be understood that the present disclosure is not limited to the embodiments, but includes all modifications, equivalents, and alternatives within the scope of the present disclosure.

[0025] Although terms including ordinal numbers such as first, second, or the like can be used to describe various elements, the structural elements are not limited by the terms. The terms are used only to distinguish one element from another element. For example, a first structural element can be referred to as a second structural element without departing from the scope of the present disclosure. Similarly, a second structural element can also be referred to as a first structural element. As used herein, the term "and / or" includes any and all combinations of one or more related items.

[0026] The terms used herein are only used to describe various embodiments of the present disclosure, and are not intended to limit the present disclosure. The singular form is intended to include the plural form, unless the context clearly dictates otherwise. In the present disclosure, it should be understood that the term "include" or "have" indicates the presence of a feature, number, step, operation, structural element, component, or a combination thereof, and does not exclude the presence or addition of one or more other features, numbers, steps, operations, structural elements, components, or combinations thereof.

[0027] Unless otherwise defined, all terms used herein have the same meaning as understood by those skilled in the art to which the present disclosure belongs. Terms such as those defined in generally used dictionaries will be interpreted as having the same meaning as the context in the relevant art, and unless explicitly defined in the present disclosure, will not be interpreted as having an ideal or excessively formal meaning.

[0028] The electronic device according to one embodiment can be one of various types of electronic devices. The electronic device can include, for example, a portable communication device (e.g., a smartphone), a computer, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. According to one embodiment of the present disclosure, the electronic device is not limited to those described above.

[0029] The terminology used in the disclosure is not intended to limit the disclosure, but is intended to encompass various changes, equivalents, or alternatives of corresponding embodiments. In the description of the drawings, like reference numerals can be used to refer to like or related elements. A singular form of a noun corresponding to an item can include one or more things, unless the relevant context clearly dictates otherwise. As used herein, each of such phrases as "A or B," "at least one of A and B," "at least one of A or B," "at least one of A, B, or C," and "at least one of A, B, or C" can include all possible combinations of the items enumerated together in a corresponding one of the phrases. As used herein, such terms as "first," "second," can be used to to distinguish one component from another component, but do not otherwise limit how the components are prioritized (e.g., in importance or order). It is intended that if a component (for example, a first component) is referred to or claimed as coupled or connected to another component (for example, a second component), that it can be directly coupled or connected to the other component or coupled or connected to the other component via a third component.

[0030] As used herein, the term "module" can include a unit implemented in hardware, software, or firmware, and can interchangeably be used with other terms, for example, "logic", "logic block", "part", and "circuitry". A module can be a single integral component, or a minimum unit or part thereof, adapted to perform one or more functions. For example, according to an embodiment, a module can be implemented in a form of an application-specific integrated circuit (ASIC).

[0031] Many narrow band (NB)-Internet of things (IoT) applications involve the transmission of small amounts of UL data that are infrequent, such as metering reports, alarms, or other types of information. Traditionally, this information can be transmitted inefficiently as UL data. For example, this UL data can have been sent while the UE is in an RRC_CONNECTED state, which requires a large amount of battery power and / or bandwidth. However, since the NB-IOT data is small and infrequently transmitted, new, more efficient transmission solutions are proposed.

[0032] Figure 1 NR RRC connection state transitions are shown in accordance with embodiments.

[0033] Different RRC states use different amounts of resources, so transitioning between RRC states is important for efficient use of network resources.

[0034] Referring toFigure 1 Three RRC states are shown: NR RRC CONNECTED (connected), NR RRC INACTIVE (inactive), and NR RRC IDLE (idle).

[0035] When a NR UE is powered off, it is in a disconnected mode and not in any of the three RRC states. Once the UE is powered on, it can first enter the RRC IDLE state. In the RRC IDLE state, the UE can attempt to establish a wireless connection with a base station (or other network node) and transition to the RRC CONNECTED state. After the transition, the UE can also be released from the RRC CONNECTED state to resume the RRC IDLE state.

[0036] However, after initially transitioning to the RRC CONNECTED state, the UE can transition to the RRC INACTIVE state to more efficiently use network resources, for example. The RRC INACTIVE state of the UE can be released, resumed, or suspended to transition back to the RRC CONNECTED state. In addition, the UE can be released from the RRC INACTIVE state and transition back to the RRC IDLE state.

[0037] The RRC INACTIVE state minimizes latency and reduces signaling load, thereby more efficiently using network resources and saving battery power of the UE when performing UL data transmission.

[0038] Figure 2 A UL data transmission procedure according to an embodiment is shown.

[0039] Reference Figure 2 A 4-step (4-step) random access channel (RACH) transmission procedure 201 includes sending four messages (Msgl, Msg2, Msg3, and Msg4) before sending UL data to the eNB. This is a relatively inefficient way of sending UL data because the UL data is sent after the four messages are sent.

[0040] In addition, the early data transmission (EDT) method 202 includes sending 2 messages (Msg1 and Msg2) before sending UL data to the eNB. That is, in the EDT state (or mode), the UE can send UL data in message 3 (Msg3), and the eNB can send DL (downlink) data in message 4 (Msg4) of the traditional 4-step RACH. This way of sending UL data is more efficient than the 4-step RACH transmission procedure 201.

[0041] In addition, when in RRC_IDLE or RRC_INACTIVE, the UE can continue to send UL data transmission or receive DL data transmission in the EDT state after message 4.

[0042] Similarly, the UE can send data in the RACH transmission state. In this case, the data transmission can occur after the traditional RACH procedure.

[0043] The UL transmission of preconfigured resources 203 can be used to send UL data to the eNB immediately. This way of sending UL data is more efficient than the transmission procedures 201 and 202. Rel-16 (e.g., UL transmission of preconfigured resources 203) is the first version to enable UL data transmission in the RRC_INACTIVE state.

[0044] Therefore, using the transmission procedures 201-203, UL data packets can be sent periodically or sporadically using information.

[0045] In addition to the above features provided in the REL-16 UL transmission 203, the present application also provides UL transmission features. As will be described below, NR PUR transmission parameters can be adjusted to more efficiently send UL data to better account for varying radio conditions and traffic patterns, thus providing improved functionality for NR UE transmission of small data packets in RRC_INACTIVE.

[0046] Transmission using PUR

[0047] PUR can be configured for UEs in enhanced coverage, bandwidth limited (BL) UEs, or NB-IoT UEs by the upper layer. When the upper layer configures PUR, the following information can be provided in the PUR-config, as specified in Section 5.4.7.1 of 3GPP TS 36.331:

[0048] PUR C - Radio Network Temporary Identifier (C-RNTI)

[0049] Duration of the PUR response window, PUR-ResponseWindowSize;

[0050] Number of preconfigured UL grants to skip before implicit release, pur-ImplicitReleaseAfter;

[0051] Time alignment timer for PUR, pur-TimeAlignmentTimer (if configured).

[0052] Periodicity of resources, pur-Periodicity; and

[0053] Offset indicating the PUR start time, pur-StartTime.

[0054] In addition, other information or configurations can also be included in the Pur-config, such as Pur-Numoccasion, which can be counted in medium access control (MAC) or RRC.

[0055] Additionally, the MAC entity can sequentially consider the Nth preconfigured UL grant can occur in a transmission time interval (TTI) based on pur-StartTime and (N*pur-Periodicity). Other calculations can also determine the Nth preconfigured UL grant.

[0056] When the upper layer releases the PUR configuration, the MAC entity can discard the corresponding preconfigured UL grant. If the MAC entity has a PUR C-RNTI, the pur-TimeAligmentTimer can be configured, and the TA is valid as specified in TS 36.331, then for each TTI with running pur-TimeAligmentTimer and preconfigured UL grant, the MAC entity can be in RRC_IDLE. The preconfigured UL grant and associated hybrid automatic repeat request (HARQ) information can be delivered (e.g., sent) to the HARQ entity for each respective TTI.

[0057] After a transmission using a preconfigured UL grant, the MAC entity can monitor a physical downlink control channel (PDCCH) identified by the PUR C-RNTI in the PUR response window using a timer pur-ResponseWindowTimer that starts from the subframe containing the end of the corresponding PUSCH transmission plus 4 subframes and has a length of pur-ResponseWindowSize. While the pur-ResponseWindowTimer is running, the MAC entity shall:

[0058] If an UL grant is received in the PDCCH for the PUR C-RNTI for retransmission, the pur-ResponseWindowTimer is restarted at the last subframe of the PUSCH transmission corresponding to the retransmission indicated by the UL grant plus 4 subframes (again, in this case, the window can or can not be restarted);

[0059] If the PDCCH indicates a L1 acknowledgment (ACK) for the PUR; or, if the PDCCH transmission is addressed to its C-RNTI and the MAC packet data unit (PDU) is successfully decoded:

[0060] The pur-ResponseWindowTimer is stopped;

[0061] Consider (e.g., determine) that the transmission using PUR was successful; and

[0062] Indicate to the upper layers that the PUR transmission was successful;

[0063] If the PDCCH indicates a fallback for the PUR:

[0064] The pur-ResponseWindowTimer is stopped;

[0065] Consider (e.g., determine) that the transmission using PUR transmission has failed; and

[0066] Indicate to the upper layers that a PUR fallback indication was received; and

[0067] If the pur-ResponseWindowTimer expires:

[0068] Consider (e.g., determine) that the preconfigured UL grant was skipped; and

[0069] Indicate to upper layers that the PUR transmission has failed.

[0070] Additionally, the MAC entity can consider the preconfigured UL grant skipped if no MAC PDU is generated for the preconfigured UL grant based on 3GPP TS 36.331 section 5.4.3.1.

[0071] In RRC_IDLE state, the MAC entity can discard the preconfigured UL grant immediately after pur-ImplicitReleaseAfter consecutive preconfigured UL grants have been skipped. When the preconfigured UL grant is discarded, the MAC entity can inform RRC to release the PUR configuration.

[0072] The PUR configuration can be defined as a configuration containing all information required for a dynamic PUR transmission. The configuration can include PUR search space configuration TA, time / frequency resource(s), repetition, MCS, TBS, periodicity, time offset, frequency hopping, RNTI, power control parameters, demodulation reference signal (DMRS) pattern, machine-type communication (MTC) physical downlink control channel (MPDCCH) frequency hopping configuration, and physical downlink shared channel (PDSCH) frequency hopping configuration.

[0073] The PUR allocation can be defined as a single time / frequency D-PUR resource allocation.

[0074] The PUR SS window can be defined as a time period associated with the UE monitoring the MPDCCH for PUR allocation.

[0075] For dedicated PUR in idle mode (e.g., in RRC_IDLE state), the PUR search space configuration can be included in the PUR configuration. The PUR search space can be a search space where the UE monitors the MPDCCH, and the PUR search space can be UE-specific.

[0076] In idle mode, after a PUR transmission, the following PUR configuration and PUR parameters can be updated: timing advance adjustment; UE TX (transmit) power adjustment; and repetition adjustment for PUSCH (for coverage extension (CE) mode A and B).

[0077] The above updates can be performed in L1 downlink control indicator (DCI). Additionally, L2 or L3 solutions are optional.

[0078] Additionally, in idle mode, the PUR search space configuration can include at least the following: MPDCCH narrowband location; MPDCCH repetition and aggregation level; MPDCCH starting subframe periodicity (variable G); or starting subframe location (alpha_offset).

[0079] The UE can monitor the MPDCCH for at least a time period after the PUR transmission.

[0080] For dedicated PUR, during PUR search space monitoring, the UE monitors for DCI scrambled with the RNTI, assuming the RNTI is not shared with any other UE.

[0081] The PUR configuration or PUR reconfiguration explicitly signals a CE mode, where the CE mode can only be changed via RRC signaling (i.e., not via L1 message). The dedicated PUR ACK DCI at least allows for implicit or explicit indication that the current PUR monitoring is terminated.

[0082] The repetition adjustment field in the PUR L1 ACK DCI can be represented by a 2-bit field, which is interpreted as the legacy repetition number field, in CE mode A (CE Mode A); or a 3-bit field, which is interpreted as the legacy repetition number field, in CE mode B.

[0083] In the dedicated PUR ACK DCI, the TA adjustment field can be 6 bits as legacy. The TA adjustment field can only be present if the dedicated PUR ACK DCI indicates successful decoding of the PUR transmission.

[0084] The radio layer 2 (RAN2) on downlink-PUR can include the following procedure steps:

[0085] • A valid TA can be a requirement to initiate a D-PUR transmission.

[0086] • The UE can use the D-PUR resource to send a RRCConnectionRequest or RRCConnectionResumeRequest to establish or resume an RRC connection.

[0087] • For control plane (CP) solution, the UL data can be encapsulated as non-access stratum (NAS) protocol data units (PDUs) in the UL RRC message sent in the common control channel (CCCH).

[0088] • For user plane (UP) solution, UL data can be sent in dedicated traffic channel (DTCH).

[0089] • After UL D-PUR transmission, UE can monitor PDCCH under the control of a timer:

[0090] o The timer can be started after PUR transmission.

[0091] o If a scheduling for D-PUR retransmission is received, the timer can be restarted.

[0092] o If the timer expires, the UE can consider the data transmission as failed.

[0093] o The timer can be stopped when the D-PUR procedure ends / succeeds.

[0094] • Downlink RRC response message for CP solution (if needed) can include the following optional information:

[0095] o Downlink data (downlink application layer response or pending data in mobile management entity (MME)) encapsulated as NAS PDU.

[0096] o Redirection information.

[0097] o D-PUR configuration / reconfiguration and release.

[0098] • Downlink RRC response message for UP solution can include the following optional information:

[0099] o Resume ID.

[0100] o Next hop (NH) parameter chaining counter (NCC) (mandatory) - Downlink RRC response message for UP solution can always be provided.

[0101] o Redirection information.

[0102] o D-PUR configuration / reconfiguration and release.

[0103] • MAC control element (CE) for TA update can be sent together with RRC transmission of downlink RRC response message for CP solution and UP solution.

[0104] • Upon reception of a D-PUR transmission, the eNB can move the UE to RRC connected by means of a RRCConnectionSetup message or a RRCConnectionResume message.

[0105] • It is not necessary to specify fallback upon unsuccessful D-PUR transmission (i.e. it is up to UE implementation to initiate legacy random access (RA), mobile originating (MO)-EDT or wait for next D-PUR occasion).

[0106] • The PUR update request can only be performed in RRC_CONNECTED (i.e. not included in the PUR transmission). This replaces the previous agreement on piggybacking the PUR request in the UP of the PUR transmission.

[0107] • In case the UE moves to RRC_CONNECTED, a new C-RNTI can be provided in the RRC. If not present, the UE can maintain the PUR-RNTI as the C-RNTI.

[0108] • The UE cannot be configured with more than one PUR configuration. Therefore, there is no need for a PUR config identity / index in the PUR configuration.

[0109] • If the paging and the PUR transmission opportunity collide, the PUR transmission is prioritized.

[0110] LTE PUR fallback

[0111] The UE can fallback from PUR to EDT or RACH based on network indication or based on UE own initiative.

[0112] For example, for a UE that is supposed to be a fixed or low mobility UE using PUR, upon a PUR transmission, it is possible to shorten the range of values used to update the TA (and thus reduce the number of bits). In addition to saving bits, the shortened TA update can be used as a way to control the distance that a UE allowed to move using PUR (i.e. if a large TA adjustment that would require a TA update outside the shortened TA range is needed, then this can imply that the UE has travelled a long distance since the last TA adjustment, and thus it is not a fixed or low mobility UE that is suitable to continue using PUR). If the eNodeB determines that the TA adjustment would result in a large path loss change, the eNodeB can indicate fallback to legacy RACH / EDT, as a UE that needs a TA update outside the shortened TA range is not suitable to continue using PUR resources.

[0113] Additionally, after data transmission on PUR, the UE can expect an explicit indication on MPDCCH for fallback to EDT or RACH. After data transmission on PUR, if the UE does not receive anything in the PUR search space window, the UE can fallback to the legacy RACH / EDT procedure.

[0114] For dedicated PUR in idle mode, the indication for fallback to EDT or RACH and PUR L1-ACK can be included in the same DCI, and if the UE receives the indication to fallback to EDT or RACH, the PUR transmission can be considered not acknowledged.

[0115] If the UE does not receive anything during the search space window after PUR retransmission(s), the UE can consider the PUR transmission not successfully received and can fallback to the legacy RACH / EDT procedure.

[0116] Furthermore, upon reception of the “PUR fallback indication”, the MAC can stop monitoring the PDCCH in the PUR response window. Upon identification of the PUR fallback indication from lower layers, the MAC can indicate PUR fallback and PUR failure to RRC separately.

[0117] NR configured grant Type 1

[0118] Figure 3A NR UL configured grant Type 1 is shown to provide UL grant by RRC transmission according to an embodiment.

[0119] NR configured grant Type I can use RRC signaling to set all transmission parameters of a possible UL transmission, including periodicity, time offset, frequency resources, and MCS.

[0120] Reference Figure 3A Upon reception of the RRC configuration 301, the UE device can start using the configured grant for PUSCH transmission at the time instant given by the periodicity and offset. The reason for the offset is to control the time instance at which the UE device is allowed to transmit information.

[0121] The RRC configuration can take effect immediately after being correctly received. The point in time at which the transmission is allowed (e.g., the configured periodicity) can vary, as this can depend on whether a radio link control (RLC) retransmission is needed to deliver the RRC command. To avoid this ambiguity, a time offset relative to the system frame number can be included in the configuration.

[0122] In addition, the configured grant Type 1 parameters can also include PUSCH repetition configuration, including frequency hopping, number of HARQ processes and retransmission timers, and power control parameters.

[0123] NR configured grant Type 2

[0124] Figure 3B NR UL configured grant Type 2 is shown to provide UL grant by RRC transmission according to an embodiment.

[0125] Reference Figure 3B , NR UL configured grant Type 2 can use PDCCH 302 to provide UL. Specifically, the transmission periodicity can be provided by RRC 303, and L1 / L2 control signaling can be used to activate / deactivate the transmission in a similar way as in downlink SPS. When receiving the activation command from gNB, the UE transmits according to the pre-configured periodicity if there is data in the buffer. If there is no data to transmit, similar to configured grant Type 1, the UE will not transmit anything.

[0126] Additionally, if there is data in the buffer, no time offset is needed since the activation time is well defined by the PDCCH transmission time instant. The UE can confirm the activation / deactivation of configured grant Type 2 by sending a MAC CE in UL. If there is no data waiting for transmission when receiving the activation, the network can not know whether the missing of transmission is due to empty transmission buffer. Therefore, ACK can help to resolve this ambiguity.

[0127] NR small data transmission in RRC_INACTIVE state

[0128] NR can support UEs with infrequent (periodic and / or aperiodic) data transmission in RRC_INACTIVE state maintained by the network. Until Rel-16, RRC_INACTIVE state does not support data transmission. Therefore, for any downlink mobile termination (MT) and UL mobile origination (MO) data, the UE has to resume the connection (i.e., move to RRC_CONNECTED state). For each data transmission, the connection is established and subsequently released to RRC_INACTIVE state, regardless of how small and infrequent the data packets are. This will result in unnecessary power consumption and signaling overhead.

[0129] Specific examples of small and infrequent data traffic can occur on smart phone applications (e.g., traffic from instant messaging services, traffic from heartbeat applications, traffic from email clients, push notifications, and information sent from other applications) and non-smart phone applications (e.g., traffic from wearable devices and video surveillance (e.g., periodic positioning information), sensors (e.g., industrial wireless sensor networks that periodically or event-triggered send temperature or pressure readings), and smart meters and smart meter networks that send periodic meter readings.

[0130] For example, the technical specifications for certain devices that can wirelessly communicate on an NR network are as follows:

[0131] • Industrial wireless sensors: Reference use cases and requirements are described in TR 22.832 and TS 22.104. The communication service availability is 99.99% and the end-to-end latency is less than 100 microseconds (ps). For all use cases, the reference bit rate is less than 2 megabits per second (Mbps) (potentially asymmetric, e.g., UL large traffic), and the devices are fixed. The battery should last at least a few years. For safety-related sensors, the latency requirement is lower, 5-10 milliseconds (TR 22.804).

[0132] • Video surveillance: The reference economic video bit rate is 2-4 Mbps, latency < 500 milliseconds, and reliability is 99%-99.9% as described in TR 22.804. High-end video, e.g., for agricultural video, requires 7.5-25 Mbps. Note that the traffic pattern is controlled by UL transmission.

[0133] • Wearable devices: The reference bit rate for smart wearable applications can be 5-50 Mbps in the downlink and 2-5 Mbps in the UL. The peak bit rate of the device can be higher, up to 150 Mbps for the downlink and 50 Mbps for the UL. The battery of the device should last for a few days (up to 1-2 weeks).

[0134] Therefore, as described in 3GPP TS 22.891, the NR system should be designed to be efficient and flexible for low throughput short data bursts to support efficient signaling mechanisms (e.g., signaling should be less than the payload) and generally reduce signaling overhead.

[0135] Signaling overhead in RRC_INACTIVE state is a general problem for UEs with small data packets, and there are more UEs in NR, not only for network performance and efficiency, but also for UE battery performance, which will be a key issue. In general, any device with intermittent small data packets sent in RRC_INACTIVE state will benefit from implementing small data transmission in RRC_INACTIVE state, as proposed in this application.

[0136] Key enablers for small data transmission in NR, i.e. RRC_INACTIVE state, 2-step RACH, 4-step RACH and configured grant Type 1, are specified as part of Rel-15 and Rel-16. Therefore, the solutions proposed in this application build on these building blocks to enable small data transmission for NR in RRC_INACTIVE state.

[0137] In RRC_INACTIVE state, when TA is valid, UL data can be transmitted on pre-configured PUSCH resources (e.g. reuse configured grant Type 1). Therefore, as described herein, RAN2 can be used in RRC_INACTIVE state to provide a general procedure for small data transmission on configured grant Type 1 resources. Additionally, configured grant Type 1 resources can be configured for UL small data transmission in RRC_INACTIVE state using RAN2.

[0138] Figure 4 L2 / L3 solution for NR PUR reconfiguration according to embodiments.

[0139] Reference Figure 4 L2 / L3 solution for NR PUR transmission is proposed. Additionally, since LTE has a similar framework, this embodiment can or can not be applied to LTE, depending on whether the content fields proposed in this application are supported by both the NR framework and the LTE framework.

[0140] Initial NR PUR configuration can include one resource allocation pattern in frequency domain and time domain, one repetition and frequency hopping pattern, MCS and / or TBS, one power control parameter, beam direction, UE-specific PUR RNTI and TA. The parameters of the initial PUR can be reconfigured for the UE based on UE request, based on radio network load or based on radio link performance.

[0141] For example, if the maximum TBS is less than the data to be transmitted, the UE can request reconfiguration of PUR and the gNB can indicate the available PUR configuration among a set of possible TBS values. The UE request can be piggybacked (e.g., via a MAC CE) in the PUR payload in one PUR occasion. Additionally or alternatively, when the radio network load is high, the network can reconfigure the resource allocation mode so that PUR occupies less resources than initially configured, or even deactivate some PURs.

[0142] The initial PUR configuration can comprise a RedCap UE specific CORESET configuration, where the UE monitors and decodes a DCI on the RedCap UE specific CORESET configuration, which can contain the location of the physical sidelink discovery channel (PSDCH) resources of a UE specific RRC signaling carrying PUR reconfiguration information that can comprise deactivation / activation of PUR.

[0143] Alternatively, the initial PUR configuration can further comprise a common CORESET configuration, where the UE monitors and decodes a DCI on the common CORESET configuration, which can contain the location of the PSDCH resources of a new broadcast system information block RRC signaling carrying PUR reconfiguration information that can comprise deactivation / activation of PUR.

[0144] According to an embodiment, the initial PUR configuration can comprise a RedCap UE specific and / or common CORESET configuration, where the UE monitors and decodes a DCI for PUR reconfiguration in RRC_INACTIVE state on the RedCap UE specific and / or common CORESET configuration.

[0145] For example, the CORESET configuration can comprise one or more of the following parameters:

[0146] • controlResourceSetld: This corresponds to the L1 parameter "CORESET-ID". The value 0 identifies the common CORESET configured in the master information block (MIB) and ServingCellConfigCommon. The values 1.. maxNrofControlResourceSets - 1 identify CORESETs configured by dedicated signaling. The controlResourceSetld is unique among the bandwidth parts (BWPs) of a ServingCell.

[0147] • frequencyDomainResource: The frequency domain resource defines the resource blocks within the BWP allocated to the UE. It corresponds to the L1 parameter "CORESET-freq-dom" with the following characteristics:

[0148] o Each bit corresponds to a group of 6 resource blocks (RBs), the grouping starting from physical resource block (PRB) 0, which is fully contained within the bandwidth part where the CORESET is configured.

[0149] o The most significant bit corresponds to the lowest frequency group, which is fully contained within the BWP where the CORESET is configured, and each subsequent less significant bit corresponds to the next lowest frequency group (if any) that is fully contained within the BWP where the CORESET is configured.

[0150] o Bits corresponding to groups not fully contained within the BWP where the CORESET is configured are set to zero.

[0151] • duration: This corresponds to the L1 parameter "CORESET-time-duration" and defines the contiguous duration in number of symbols of the CORESET.

[0152] • cce-reg-MappingType: This provides the selection of the mapping method of control channel elements (CCEs) to REGs.

[0153] • reg-BundleSize: This corresponds to the L1 parameter "CORESET-REG-bundle-Size" and provides the number of REGs in a REG bundle.

[0154] • interleave Size: This corresponds to the L1 parameter “CORESET-interleaver-size”.

[0155] • shiftIndex: This corresponds to CORESET-shift-index. If this parameter is not present, the UE applies the value of the physical cell ID configured for the serving cell.

[0156] • precoderGranularity: This corresponds to the L1 parameter “CORESET-precoder-granuality”. The precoder granularity is defined in the frequency domain.

[0157] • tci-StatesPDCCH: This is a reference to the configured transmission configuration indicator (TCI) states that provide the quasi co-location (QCL) configuration / indication for PDCCH.

[0158] • tci-PresentInDCI: This corresponds to the L1 parameter “TCI-PresentInDCI”. This field indicates whether the TCI field is present in the DL-related DCI.

[0159] • pdcch-DMRS-ScramblingID: This is the PDCCH demodulation reference signal (DMRS) scrambling initialization parameter corresponding to the L1 parameter “PDCCH-DMRS-scrambling-ID”. When this field is not present, the UE applies the value of the physical cell ID configured for the serving cell.

[0160] Referring again to Figure 4 , the RedCap UE can monitor for DCI 402 after each or a certain number of PUR transmissions (Tx) 401 and then decode the PUR response in the form of a UE-specific RRC message or a broadcast new system information block.

[0161] The DCI 402 can include ACK / NACK for the PUR Tx 401 and, in case of NACK, UL grant for HARQ retransmission. The ACK / NACK 404 and UL grant for HARQ retransmission can be transmitted on UE-specific or common search space. To decode the PUR response message 403, the UE can need to decode the UE-specific or common search space if the PUR response message 403 is in UE-specific RRC signaling, or the common search space if the PUR response message 403 is in new broadcast system information block.

[0162] Once the PUR is allocated to the UE, these configurations can be used for a while. However, the radio channel and UE traffic can change all the time, and thus the configuration can not be suitable for the UE after a while. Therefore, a reconfiguration mechanism for the PUR can be considered. The reconfiguration can be done via the PUR response message 403.

[0163] The PUR response message 403 can include ACK / NACK for the PUR Tx 401 (if not included in the DCI 402) and information for reconfiguring at least one or more of the following parameters:

[0164] • Resource allocation in frequency domain, time domain, and / or spatial domain.

[0165] • CORESET configuration, including aggregation level and repetition type.

[0166] • PUSCH repetition configuration, including frequency hopping pattern.

[0167] • Periodicity of the PUR.

[0168] • MCS and / or TBS.

[0169] • UL narrow beam direction (for FR2) and / or TRP association.

[0170] • Activation or deactivation of the PUR.

[0171] • Tx power adjustment.

[0172] • TA update.

[0173] Some or all of the above parameters can be used to configure the PUR in the 5G NR system for the UE to perform data transmission in RRC INACTIVE state. For example, the following parameters can be used to control the PUR configuration in the 5G NR system but not in the LTE system:

[0174] • CORESET configuration, including aggregation level and repetition type.

[0175] • PUSCH repetition configuration, including frequency hopping pattern.

[0176] • UL narrow beam direction (for FR2) and / or TRP association.

[0177] Thus, using NR parameters to control PUR configuration to enable data transmission in RRC_INACTIVE advantageously provides PUR configuration that can not be achievable in LTE or other existing legacy systems.

[0178] The PUR response can be UE-specific RRC signaling or a new broadcast system information block. In the case of a new broadcast system information block, a list of IDs of individual PUR entities to be reconfigured can be included in the system information block (i.e., PUR RNTI). For each PUR RNTI, a set of parameters to be updated can be included in the new system information block. The set of parameters can be, for example, PUR RNTI, TA update, Tx power adjustment, resource allocation, CORESET configuration, periodic PUR, UL beam direction, or activation / deactivation. Each parameter can have one or more assignments.

[0179] Resource allocation in frequency domain / time domain or spatial domain can be reconfigured based on how UE traffic pattern (e.g., maximum TBS or periodicity) varies over time, so resource allocation in frequency domain and time domain can adapt to it to improve spectral efficiency. Additionally or alternatively, resource allocation in frequency domain / time domain or spatial domain can be reconfigured based on preconfigured frequency domain / time domain / spatial domain resources, which can be pre-empted to accommodate other high priority traffic in the cell.

[0180] CORESET configuration (e.g., CORESET configuration parameters) including aggregation level and repetition type can adapt to channel conditions to increase capacity, allowing more users to be scheduled by improving efficiency of PDCCH usage. Because CCE utilization can be used more efficiently, capacity can be improved. For example, gNB can estimate DL channel conditions using UL reference signal received power (RSRP) / reference signal received quality (RSRQ) measurements or UL transmission success rate, to determine CORESET configuration in DL. For estimated good DL channel conditions, CORESET can be configured with small aggregation level and / or small number of repetitions. For estimated poor DL channel conditions, CORESET can be configured with large aggregation level and / or large number of repetitions.

[0181] The number of repetitions and frequency hopping pattern (e.g., PUSCH repetition parameters and / or frequency hopping parameters) are important parameters for RedCap UEs to compensate for the coverage loss due to reduced Rx antennas or bandwidth, thus, when selecting the repetition pattern (e.g., repetition type A or B), the number of repetitions, and the frequency hopping pattern, the coverage compensation, the level of enhancement, and / or the channel quality can be considered. For example, when the channel quality (i.e., the received PUSCH channel quality at the gNB) becomes worse, a larger number of repetitions can be reconfigured. Additionally or alternatively, the frequency hopping pattern can be updated according to the specific BWP or set of BWPs that the UE performs frequency hopping.

[0182] The periodicity of the occasion of the PUR transmission can be determined by the traffic data properties (e.g., arrival rate and packet size) and the available resources for transmission in PUR. Thus, the PUR periodicity can be repeatedly updated based on the latest traffic data properties and the available resources in the cell.

[0183] The gNB can update the MCS and / or TBS to maintain the link quality and maximize the spectral efficiency.

[0184] According to an embodiment, in case the beam failure is detected by the gNB in the previous PUR transmission, the UL beam direction (for FR2) and / or the TRP association (e.g., UL narrow beam direction parameters and / or TRP association parameters) can be reconfigured to recover from the beam failure. According to another embodiment, when one beam in one TRP has too many UEs associated with it, some of these UEs can be re-associated with other neighboring TRPs using other beam directions to balance the load across TRPs and mitigate the interference between the information related to too many UEs transmitted within the same beam.

[0185] The transmission power adjustment can be done by the gNB sending it in the RRC PUR response message. The set of Tx power adjustments can be based on the open loop power control of each candidate UL beam.

[0186] Thus, the TA parameters can be updated when the UE is moving slowly.

[0187] According to embodiments, since the traffic load of the cell can be relatively high, it can be beneficial for the base station to temporarily turn off the transmission in PUR for RedCap UEs. For example, the traffic load status of the cell can change from when PUR is configured. Although dedicated PUR can be efficient for a certain period of time, the gNB can prefer to take back and control the PUR for dynamic scheduling (e.g., the PUR can be deactivated). When the traffic load of the cell is relieved, the transmission using PUR can be turned on again (e.g., the PUR can be activated). Since the traffic load of the cell does not depend on a certain UE, taking back the PUR (e.g., activating or reactivating the PUR) can be used for all UEs with dedicated PUR provided by the cell. Thus, the gNB can use UE-specific unicast signaling via the PUR response message or broadcast signaling via new system information to turn on or off the function of transmission using PUR.

[0188] According to embodiments, in order to efficiently transmit data packets in RRC_INACTIVE state, the following parameters can be reconfigured in RRC UE-specific RRC response message or new broadcast system information block for PUR:

[0189] • Resource allocation in frequency domain, time domain and / or spatial domain.

[0190] • CORESET configuration including aggregation level and repetition type.

[0191] • PUSCH repetition configuration including frequency hopping pattern.

[0192] • Periodicity of PUR.

[0193] • MCS and / or TBS.

[0194] • UL narrow beam direction (for FR2) and / or TRP association.

[0195] • Activation or deactivation of PUR.

[0196] • Tx power adjustment.

[0197] • TA update.

[0198] Figure 5 is an L1 solution for NR PUR reconfiguration according to embodiments.

[0199] Reference Figure 5 A PUR Tx 501 can be transmitted from the UE to the gNB, and a DCI signal 502 transmitted from the gNB to the UE can include ACK / NACK and / or UL grant for HARQ retransmission.

[0200] Additionally, the DCI 502 can include information to reconfigure some of the aforementioned PUR parameters. That is, the DCI 502 can include information to configure at least one of the following:

[0201] • Resource allocation in frequency domain, time domain and / or spatial domain.

[0202] • CORESET configuration, including aggregation level and repetition type.

[0203] • PUSCH repetition configuration, including frequency hopping pattern.

[0204] • Periodicity of PUR.

[0205] • MCS and / or TBS.

[0206] • UL narrow beam direction (for FR2) and / or TRP association.

[0207] • Activation or deactivation of PUR.

[0208] • Tx power adjustment.

[0209] • TA update.

[0210] Additionally, other parameters can also be reconfigured through L2 / L3 UE-specific RRC signaling or through broadcast new system information block. In this case, the DCI can also include a bit indicating the UE to monitor the DCI to decode RRC signaling in the corresponding PDSCH.

[0211] In this regard, the information (e.g., signaling information) for reconfiguring the PUR parameters can take various forms. That is, the information to reconfigure the PUR parameters can be included in RRC signaling, PUR response message, system information block, and / or DCI information.

[0212] Accordingly, according to embodiments, data packets can be transmitted in RRC_INACTIVE state based on preconfigured UL resources, which can be updated and / or activated or deactivated by L1 DCI with the aforementioned parameters (e.g., resource allocation in frequency domain, time domain and / or spatial domain; CORESET configuration, including aggregation level and repetition type; PUSCH repetition configuration, including frequency hopping pattern; periodicity of PUR; MCS and / or TBS; UL narrow beam direction (for FR2) and / or TRP association; activation or deactivation of PUR; Tx power adjustment; and / or TA update).

[0213] Furthermore, once PURs are configured, they can be kept for a certain period of time. If there is no data packet transmission in the PUR, it can be beneficial for the user to release the PUR(s) to improve the spectral efficiency of the system.

[0214] According to embodiments, no transmission or sending of all “0” for more than one quantity of consecutive PURs can be used to indicate PUR release.

[0215] Additionally, UL transmission failures can occur due to, for example, inappropriate TA values, low transmit power, deep channel fading, and / or beam failure. When a transmission in PUR fails, a fallback can be needed to conserve power, reduce data packet loss, and avoid interfering with other UEs due to UL asynchrony.

[0216] Generally, traffic packets transmitted in PURs are small in size, and when a transmission in PUR fails, it is preferable for the UE to use EDT. However, if a large number of UEs use EDT, the transmission failures of EDT can increase (e.g., EDT is contention-based). Similarly, if a large number of users use RACH, then RACH failures can also increase.

[0217] Accordingly, according to embodiments, a gNB can indicate a UE to fallback to RACH or EDT to avoid an increase in contention for EDT or RACH.

[0218] For example, a gNB can indicate a UE to fallback to RACH or EDT based on the UE’s activity in EDT and RACH. The fallback indication can be designed together with the PUR deactivation / release mechanism. For example, PUR deactivation / release can also be used to indicate fallback.

[0219] In principle, the UE should fallback immediately upon receiving this fallback indication so that it is a network (NW) controlled fallback. After fallback to EDT, the UE can receive a PUR (activation) message again when the NW chooses to do so (i.e., after EDT, the UE continues to monitor the PUR search space for a PUR (activation) message), or the UE can receive a notification to do RACH. Thus, depending on the UE traffic pattern and NW conditions, the NW can flexibly reconfigure the NR UE among PUR, EDT, and RACH modes.

[0220] Further, when PUR is released and the UE is in EDT, the UE can need to be in RRC_CONNECTED state to receive a new PUR configuration.

[0221] However, according to embodiments, the UE can receive a new PUR configuration in a message 4 of EDT (e.g., a message indicating to resume a previous PUR configuration) without entering the RRC_CONNECTED state.

[0222] Additionally, UL resources can be cancelled via an enhanced UL cancellation indication (CI) sent by DCI.

[0223] Figure 6 A scenario according to an embodiment is shown, where a RedCap UE is in HD (Half Duple) -FDD or TDD in FR1 and coexists with eMBB traffic. Figure 7 A scenario according to an embodiment is shown, where a RedCap UE is in TDD in FR2 and coexists with eMBB traffic.

[0224] For each of the cases shown in Figures 6-7 After an ongoing configured grant PUR Tx, for each of the cases shown in

[0225] Figure 8 A scenario according to an embodiment is shown, where a RedCap UE is in HD-FDD or TDD in FR1 and coexists with eMBB traffic.

[0226] Referring to Figure 8 In the case where a RedCap UE is in HD-FDD or TDD in FR1 and coexists with eMBB traffic, the RedCap UE can be introduced to proactively send UL CI to the gNB using the configured grant / PUR resource without upcoming RedCap UE traffic to cancel some of the preconfigured reserved future UL resources of the RedCap UE to improve spectral efficiency.

[0227] Figure 9 is a flowchart illustrating a method of configuring a PUR for UL data transmission according to an embodiment.

[0228] Referring to Figure 9 In step 901, a PUR is configured for UL data packet transmission. In this case, parameters associated with the PUR transmission can be configured to enable data packets to be transmitted in the RRC inactive state.

[0229] In step 902, in the RRC inactive state, a DCI for PUR reconfiguration is monitored and decoded. For example, the UE can monitor and decode a DCI transmitted from a base station or another network node to detect a UE reconfiguration message.

[0230] At step 903, it is determined whether a PUR reconfiguration message is detected. If a PUR reconfiguration message is detected, at step 904, the PUR parameters can be reconfigured based on RRC signaling, NB system information block, or DCI.

[0231] At step 905, it is determined whether a fallback indication is detected. The fallback indication can be any signal indicating fallback. For example, the fallback indication can be an indication detected autonomously by the UE, such as detecting a beam failure or TA invalidation. At step 906, if the fallback indication is detected, the connection state falls back to an EDT or RACH state.

[0232] In the EDT or RACH state, small data transmission (SDT) can still occur periodically or occasionally.

[0233] Additionally, even after falling back to the RACH state, the base station can indicate to the UE to change from RACH-based SDT to configured grant-based SDT.

[0234] Furthermore, Figure 9 Some of the steps shown can be omitted, or performed in an order different than Figure 9 shown, as long as each step fulfills the function for which it was Figure 9 described, the embodiments shown can be implemented.

[0235] Figure 10 An electronic device in a network environment according to an embodiment is illustrated.

[0236] Referring to Figure 10The electronic device 1001 in the network environment 1000 can communicate with an electronic device 1002 via a first network 1098 (e.g., a short-range wireless communication network), or an electronic device 1004 or a server 1008 via a second network 1099 (e.g., a long-range wireless communication network). The electronic device 1001 can communicate with the electronic device 1004 via the server 1008. The electronic device 1001 can include a processor 1020, a memory 1030, an input device 1050, a sound output device 1055, a display device 1060, an audio module 1070, a sensor module 1076, an interface 1077, a haptic module 1079, a camera module 1080, a power management module 1088, a battery 1089, a communication module 1090, a subscriber identification module (SIM) 1096, or an antenna module 1097 including a GNSS antenna. In an embodiment, at least one (e.g., the display device 1060 or the camera module 1080) of the components can be omitted from the electronic device 1001, or one or more other components can be added in the electronic device 1001. In an embodiment, some of the components can be implemented as single integrated circuitry. For example, the sensor module 1076 (e.g., a fingerprint sensor, an iris sensor, or an illuminance sensor) can be embedded in the display device 1060 (e.g., a display).

[0237] The processor 1020 can execute, for example, software (e.g., a program 1040) to control at least one other component (e.g., a hardware or software component) of the electronic device 1001 coupled with the processor 1020 and can perform various data processing or computation. As at least a part of the data processing or computation, the processor 1020 can load a command or data received from another component (e.g., the sensor module 1076 or the communication module 1090) to a volatile memory 1032, process the command or the data stored in the volatile memory 1032, and store resulting data in a non-volatile memory 1034. The processor 1020 can include a main processor 1021 (e.g., a central processing unit (CPU) or an application processor) and an auxiliary processor 1023 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that is operable independently from, or in conjunction with, the main processor 1021. Additionally or alternatively, the auxiliary processor 1023 can be adapted to consume less power than the main processor 1021, or to operate a specific function. The auxiliary processor 1023 can be implemented as separate from or as part of the main processor 1021.

[0238] The auxiliary processor 1023, rather than the main processor 1021, can control at least some of the functions or states related to at least one component of the electronic device 1001 (e.g., the display device 1060, the sensor module 1076, or the communication module 1090), while the main processor 1021 is in an inactive (e.g., sleep) state, or the auxiliary processor 1023, in conjunction with the main processor 1021, can control at least some of the functions or states related to at least one component of the electronic device 1001 (e.g., the display device 1060, the sensor module 1076, or the communication module 1090), while the main processor 1021 is in an active state (e.g., executing an application). According to an embodiment, the auxiliary processor 1023 (e.g., an image signal processor or a communication processor) can be implemented as a part of another component (e.g., the camera module 1080 or the communication module 1090) functionally related to the auxiliary processor 1023.

[0239] The memory 1030 can store various data used by at least one component (e.g., the processor 1020 or the sensor module 1076) of the electronic device 1001, for example. The various data can include, for example, software (e.g., the program 1040) and input data or output data for commands related thereto. The memory 1030 can include the volatile memory 1032 or the non-volatile memory 1034.

[0240] The program 1040 can be stored in the memory 1030 as software, and can include, for example, the operating system (OS) 1042, middleware 1044, or an application 1046.

[0241] The input device 1050 can receive a command or data, which is used for another component (e.g., the processor 1020) of the electronic device 1001, from the outside (e.g., a user) of the electronic device 1001. The input device 1050 can include, for example, a microphone, a mouse, or a keyboard.

[0242] The sound output device 1055 can output sound signals to the outside of the electronic device 1001. The sound output device 1055 can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as playing multimedia or recording, and the receiver can be used for receiving an incoming call. According to an embodiment, the receiver can be implemented as separate from the speaker, or implemented as a part of the speaker.

[0243] The display device 1060 can visually provide information to the outside (e.g., a user) of the electronic device 1001. The display device 1060 can include, for example, a display, a hologram device, or a projector and a control circuit for controlling a corresponding one of the display, the hologram device, and the projector. According to an embodiment, the display device 1060 can include a touch circuit adapted to detect a touch or a sensor circuit (e.g., a pressure sensor) adapted to measure the intensity of force incurred by the touch.

[0244] The audio module 1070 can convert a sound into an electrical signal and vice versa. According to an embodiment, the audio module 1070 can obtain sound through the input device 1050 or output sound through the sound output device 1055 or an external electronic device 1002 (e.g., a speaker) directly (e.g., wirelessly) or wirely coupled with the electronic device 1001.

[0245] The sensor module 1076 can detect an operational state (e.g., power or temperature) of the electronic device 1001 or an environmental state (e.g., a state of a user) external to the electronic device 1001, and then generate electrical signals or data values corresponding to the detected state. The sensor module 1076 can include, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0246] The interface 1077 can support one or more specified protocols to be used for the electronic device 1001 to be coupled with the external electronic device 1002 directly (e.g., wiredly) or wirelessly. According to an embodiment, the interface 1077 can include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

[0247] The connection terminal 1078 can include a connector via which the electronic device 1001 can be physically connected with the external electronic device 1002. According to an embodiment, the connection terminal 1078 can include, for example, a HDMI connector, a USB connector, a SD card connector, or an audio connector (e.g., a headphone connector).

[0248] The haptic module 1079 can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that can be recognized by a user via his tactile sensation or kinesthetic sensation. According to an embodiment, the haptic module 1079 can include, for example, a motor, a piezoelectric element, or an electric stimulator.

[0249] The camera module 1080 can capture still images or moving images. According to one embodiment, the camera module 1080 can include one or more lenses, image sensors, image signal processors, or flashes.

[0250] The power management module 1088 can manage power supplied to the electronic device 1001. The power management module 1088 can be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

[0251] The battery 1089 can supply power to at least one component of the electronic device 1001. According to an embodiment, the battery 1089 can include, for example, a primary cell which is not rechargeable, a secondary cell which is rechargeable, or a fuel cell.

[0252] The communication module 1090 can support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 1001 and an external electronic device (e.g., the electronic device 1002, the electronic device 1004, or the server 1008) and performing communication between the established communication channel. The communication module 1090 can include one or more communication processors that are operable independently from the processor 1020 (e.g., an application processor) and supports a direct (e.g., wired) communication or a wireless communication. According to an embodiment, the communication module 1090 can include a wireless communication module 1092 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 1094 (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). A corresponding one of these communication modules can perform communication by using at least one of the first network 1098 (e.g., a short-range wireless communication network, such as Bluetooth (BT), wireless-fidelity (Wi-Fi), Bluetooth Low Energy (BLE), ZigBee, or infrared data association (IrDA)) or the second network 1099 (e.g., a long-range wireless communication network, such as a cellular network, the Internet, or a computer network (e.g., LAN or wide area network (WAN)). These various types of communication modules can be implemented as a single component (e.g., a single IC) or can be implemented as separate components (e.g., separate ICs) from each other. The wireless communication module 1092 can identify and authenticate the electronic device 1001 in a communication network, such as the first network 1098 or the second network 1099, using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module 1096. TM

[0253] The antenna module 1097 can transmit or receive a signal or power to or from an external electronic device (e.g., the external electronic device) of the electronic device 1001. According to an embodiment, the antenna module 1097 can include one or more antennas, and, accordingly, at least one antenna appropriate for a communication scheme used in a communication network, such as the first network 1098 or the second network 1099, can be selected and used by, for example, the communication module 1090 (e.g., the wireless communication module 1092). The signal or the power can then be transmitted or received between the communication module 1090 and the external electronic device via the selected at least one antenna.

[0254] ​At least some of the above-described components can be coupled via an inter-peripheral communication scheme (e.g., a bus, general-purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)) and communicate signals (e.g., commands or data) between them.

[0255] According to an embodiment, commands or data can be transmitted or received between the electronic device 1001 and the external electronic device 1004 via the server 1008 coupled with the second network 1099. Each of the electronic devices 1002 and 1004 can be a device of a same type as or different from the electronic device 1001. All or some of the operations that the electronic device 1001 performs can be performed at one or more of the external electronic devices 1002, 1004, or server 1008. For example, if the electronic device 1001 should perform a function or a service automatically, or in response to a request from a user or another device, the electronic device 1001, instead of, or in addition to, executing the function or the service, can request the one or more external electronic devices to perform at least part of the function or the service. The one or more external electronic devices receiving the request can perform the requested at least part of the function or the service, or an additional function or an additional service related to the request, and deliver the result to the electronic device 1001. The electronic device 1001 can provide the result, with or without further processing of the result, as at least part of a reply to the request. To that end, a cloud computing, distributed computing, or client-server computing technology can be used, for example.

[0256] One embodiment can be implemented as software (e.g., a program 1040) including one or more instructions stored in a storage medium (e.g., an internal memory 1036 or an external memory 1038) that is readable by a machine (e.g., the electronic device 1001). For example, a processor of the electronic device 1001 can invoke at least one instruction of the one or more instructions of the software, and operate according to the invoked instruction(s). Thus, the machine can be operated to perform at least one function according to the at least one instruction invoked. The one or more instructions can include a code generated by a complier or a code executable by an interpreter. The machine-readable storage medium can be provided in the form of a non-transitory storage medium. The term "non-transitory" indicates that the storage medium is tangible, but does not include a signal (e.g., an electromagnetic wave), but the term does not differentiate between where data is semi-permanently stored in the storage medium and where the data is temporarily stored in the storage medium.

[0257] According to an embodiment, a method according to the present disclosure can be included in a computer program product and provided to a user of the computer program product. The computer program product can be traded as a product between a seller and a buyer. The computer program product can be distributed in the form of a machine-readable storage medium (e.g., compact disc read only memory (CD-ROM)), or be distributed (e.g., downloaded or uploaded) online via an application store (e.g., PlayStore®), or between two user devices (e.g., smart phones) directly. If distributed online, at least part of the computer program product can be temporarily generated or at least temporarily stored in the memory of the manufacturer's server, an application store's server, or a relay server. TM ) online, or can be directly distributed (e.g., downloaded or uploaded) between two user devices (e.g., smart phones). If distributed online, at least part of the computer program product can be temporarily generated or at least temporarily stored in a machine-readable storage medium such as a manufacturer's server, an application store's server, or a relay server.

[0258] According to an embodiment, each component (e.g., a module or a program) of the above-described components can include a single entity or multiple entities. One or more of the above-described components can be omitted, or one or more other components can be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) can be integrated into a single component. In such a case, the integrated component can still perform one or more functions of the plurality of components in the same or similar manner as they are performed by the plurality of components before the integration. Operations performed by the module, the program, or another component can be carried out sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations can be executed in a different order or omitted, or one or more other operations can be added.

[0259] Accordingly, the present application provides a new function for NR to transmit small data using PUR in RRC inactive state. That is, the present application provides a solution for building a configured grant type 1 for NR to enable small data transmission in RRC_inactive state.

[0260] Additionally, the present application provides a solution for enabling the UE to release the PUR request and / or enabling the UE to fallback and continue with SDT.

[0261] Furthermore, the present application provides a UL solution for RedCap UE to cancel and / or reschedule PUR.

[0262] Although certain embodiments of the present disclosure have been described in the detailed description of the disclosure, the present disclosure can be modified in various forms without departing from the scope of the present disclosure. Accordingly, the scope of the present disclosure should not be determined only based on the described embodiments, but based on the appended claims and their equivalents.

Claims

1. A user equipment (UE) device for wirelessly communicating with a base station, the UE device comprising: transceiver; and The processor is configured as follows: Based on a pre-configured uplink UL resource (PUR) configuration, at least one UL data packet is transmitted to the base station via the transceiver during a Radio Resource Control (RRC) inactive state, wherein the PUR configuration is defined according to a set of PUR parameters. The set of PUR parameters includes at least one of the following: control resource set (CORESET) configuration, including aggregation level and repetition type; physical UL shared channel (PUSCH) repetition configuration, including frequency hopping mode; or UL narrow beam direction or transmit / receive point (TRP) association in frequency range 2FR2. The set of PUR parameters is associated with the new radio frequency (NR). The processor is further configured as follows: The transceiver receives downlink control indicator (DCI) information from the base station. The CORESET configuration includes UE-specific CORESET configuration or public CORESET configuration, enabling the UE to monitor and decode DCI information used to reconfigure the PUR configuration in the RRC inactive state.

2. The UE device according to claim 1, wherein, The processor is also configured to: Receive PUR response message from the base station via the transceiver. The PUR response message is a UE-specific RRC signaling or broadcast system information block, and Specifically, based on the PUR response message, the PUR configuration is reconfigured using at least one of the PUR parameters.

3. The UE device according to claim 1, wherein, The processor is also configured to: The transceiver receives downlink control indicator (DCI) information from the base station. Based on the DCI information, in the RRC inactive state, at least one of the PUR parameters is updated, activated, or deactivated.

4. The UE device according to claim 1, wherein, The processor is also configured to: In response to no UL data packets being transmitted in more than a predetermined number of consecutive PUR transmissions, a message indicating that the PUR configuration can be released is received from the base station via the transceiver.

5. The UE device according to claim 1, wherein, The processor is also configured to: In response to a UL transmission failure, the transceiver receives a message from the base station instructing the UE to fall back to Early Data Transmission (EDT) mode or Random Access Channel (RACH) transmission mode.

6. The UE device according to claim 5, wherein, The UL transmission failure is determined to occur based on at least one of time alignment (TA) value, low transmit power, deep channel fading, or beam failure.

7. The UE device according to claim 5, wherein, The processor is also configured to: After the UE falls back to the EDT mode or RACH transmission mode, it receives a signal from the base station via the transceiver based on at least one of the PUR parameters to reconfigure the UE to send UL data packets in the RRC inactive state.

8. The UE device according to claim 1, wherein, At least one of the PUR parameters is reconfigured based on at least one of the UE request, radio network load, or radio link performance.

9. A base station apparatus for wirelessly communicating with a user equipment (UE), the base station apparatus comprising: transceiver; and The processor is configured as follows: Based on a pre-configured uplink UL resource PUR configuration, at least one UL data packet is received from the UE via the transceiver during a Radio Resource Control (RRC) inactive state, wherein the PUR configuration is defined according to a set of PUR parameters. The set of PUR parameters includes at least one of the following: control resource set (CORESET) configuration, including aggregation level and repetition type; physical UL shared channel (PUSCH) repetition configuration, including frequency hopping mode; or UL narrow beam direction or transmit / receive point (TRP) association in frequency range 2FR2. The set of PUR parameters is associated with the new radio frequency (NR). The processor is further configured as follows: The transceiver sends downlink control indicator (DCI) information to the UE. The CORESET configuration includes UE-specific CORESET configuration or public CORESET configuration, enabling the UE to monitor and decode DCI information used to reconfigure the PUR configuration in the RRC inactive state.

10. The base station apparatus according to claim 9, wherein, The processor is also configured to: The transceiver sends a PUR response message to the UE. The PUR response message is a UE-specific RRC signaling or broadcast system information block, and Specifically, based on the PUR response message, the PUR configuration is reconfigured using at least one of the PUR parameters.

11. The base station apparatus according to claim 9, wherein, The processor is also configured to: The transceiver sends downlink control indicator (DCI) information to the UE. Based on the DCI information, in the RRC inactive state, at least one of the PUR parameters is updated, activated, or deactivated.

12. The base station apparatus according to claim 9, wherein, The processor is also configured to: In response to the failure to receive UL data packets for more than a predetermined number of consecutive PUR transmissions, a message indicating that the PUR configuration can be released is sent to the UE via the transceiver.

13. The base station apparatus according to claim 9, wherein, The processor is also configured to: In response to a UL transmission failure, a message instructing the UE to fall back to Early Data Transmission (EDT) mode or Random Access Channel (RACH) transmission mode is sent to the UE via the transceiver.

14. The base station apparatus according to claim 13, wherein, The UL transmission failure is determined to occur based on at least one of time alignment (TA) value, low transmit power, deep channel fading, or beam failure.

15. The base station apparatus according to claim 13, wherein, The processor is also configured to: After the UE falls back to the EDT mode or RACH transmission mode, a signal is sent to the UE via the transceiver based on at least one of the PUR parameters to reconfigure the UE to transmit UL data packets in the RRC inactive state.

16. The base station apparatus according to claim 9, wherein, At least one of the PUR parameters is reconfigured based on at least one of the UE request, radio network load, or radio link performance.

17. A base station apparatus for wirelessly communicating with a user equipment (UE), the base station apparatus comprising: transceiver; and The processor is configured as follows: The transceiver sends downlink control indicator (DCI) information to the UE to reconfigure a pre-configured UL resource (PUR) for receiving at least one uplink UL data packet from the UE in a Radio Resource Control (RRC) inactive state, wherein the PUR reconfiguration is defined based on a set of PUR parameters. The set of PUR parameters includes at least one of the following: Resource allocation in the frequency domain, time domain, or spatial domain. Control resource set CORESET configuration, including aggregation level and repeat type. Physical UL shared channel (PUSCH) reconfiguration, including frequency hopping modes. The period of the PUR, Modulation and coding scheme (MCS), Transport Block Size (TBS) UL narrow beam direction or transmit / receive point TRP association in frequency range 2FR2. The activation or deactivation of the PUR Send Tx power adjustment, or The timing is right for them, and The set of PUR parameters is associated with the new radio frequency (NR). The CORESET configuration includes UE-specific CORESET configuration or public CORESET configuration, enabling the UE to monitor and decode DCI information used to reconfigure the PUR configuration in the RRC inactive state.

Images