Data transmission during inactivity

Abstract

The present application relates to methods, systems, and devices related to digital wireless communications, and more particularly, to techniques related to data transmission in an inactive state. In one exemplary aspect, a method for data communication is disclosed. The method includes identifying, by a terminal, that data transmission with a network node has failed while the terminal is in an inactive state. The method also includes transmitting, by the terminal, to the network node, a set of information related to the data transmission failure in response to the terminal transitioning to a connected state in which the terminal is connected to the network node.

Description

[Technical field]

[0001] This patent document is generally directed to wireless communications. [Background technology]

[0002] Mobile communication technologies are transforming the world into an increasingly connected and networked society. The rapid growth of mobile communication and technological advances are leading to further demands for capacity and connectivity. Other aspects such as energy consumption, device cost, spectrum efficiency, and latency are also important to meet the needs of various communication scenarios. Various technologies, including new ways to provide higher quality services, are being discussed. Summary of the Invention [Problem to be solved by the invention]

[0003] This document discloses methods, systems, and devices related to digital wireless communications, and more specifically, techniques related to data transmission during inactivity. [Means for solving the problem]

[0004] In one example aspect, a method for data communications is disclosed that includes identifying, by a terminal, that a data transmission with a network node has failed while the terminal is in an inactive state. The method also includes transmitting, by the terminal, to the network node, a set of information related to the data transmission failure in response to the terminal transitioning to a connected state in which the terminal is connected to the network node.

[0005] In another exemplary aspect, a wireless communication apparatus is disclosed comprising a processor configured to implement the methods described herein.

[0006] In yet another illustrative aspect, the various techniques described herein may be embodied as processor-executable code and stored on a computer-readable program medium.

[0007] Details of one or more implementations are set forth in the accompanying attachments, drawings, and description below. Other features will be apparent from the description and drawings, and from the attachments. The present invention further provides, for example, the following: (Item 1) 1. A method for wireless communication, the method comprising: identifying, by the terminal, that data transmission with a network node has failed while the terminal is in an inactive state; transmitting, by the terminal, to a network node, a set of information relating to the data transmission failure, in response to the terminal transitioning to a connected state in which the terminal is connected to the network node; A method comprising: (Item 2) 2. The method of claim 1, wherein the set of information related to the data transmission failure includes a failure cause for the data transmission failure. (Item 3) The method of claim 2, wherein the failure cause includes any of the following: a maximum number of radio link control (RLC) retransmissions, expiration of a t310 timer, a beam failure recovery failure, a random access failure with a random access objective of the data transmission in a radio resource control (RRC) inactive state, a configured grant (CG) based failure, an out-of-coverage failure, expiration of a t319 timer, expiration of an inactive data transmission timer, and expiration of a CG response check timer. (Item 4) 2. The method of claim 1, wherein the set of information related to the failure of the data transmission includes an indication of whether the terminal or the network node triggered the data transmission. (Item 5) The method according to item 1, wherein the set of information related to the data transmission failure includes any one of a threshold for a buffered data size and a current buffered data size, the threshold being per terminal, per data radio bearer (DRB), per logical channel, or per logical channel group, and the buffered data size being per terminal, per DRB, per logical channel, or per logical channel group. (Item 6) 2. The method of claim 1, wherein the set of information related to the data transmission failure includes one of a threshold value related to a tolerant time, information related to a supported solution, and information related to a selected solution. (Item 7) 2. The method of claim 1, wherein the set of information related to the data transmission failure includes any of the following: a radio resource status, information of configured radio resources for the data transmission, information of selected radio resources for the data transmission, information of an ongoing data service type, and an RLC status. (Item 8) The method of item 1, wherein the set of information related to the data transmission failure includes any of a configured area range, an indication that the terminal has buffered data in response to the terminal receiving a release message from the network node, an indication of whether a Buffer Status Report (BSR) in an inactive state or a data transmission request has been sent to the network node, an indication of whether data has been sent to the network node in Msg3 or MsgA, information on a fallback action, information on a configured fallback trigger condition, and information on beam management. (Item 9) Item 2. The method of item 1, wherein the set of information related to the data transmission failure includes an indication of whether a random access channel resource or a CG resource is enabled to be used, depending on which comes first, and a configured value for a CG response check timer. (Item 10) 2. The method according to claim 1, wherein the set of information related to the data transmission failure is stored by the terminal in one of a connection establishment failure (CEF) report, a radio link failure (RLF) report, and a random access report. (Item 11) 2. The method of claim 1, further comprising receiving, by the terminal, an updated data transmission configuration from the network node in response to transmitting the set of information related to the data transmission failure to the network node. (Item 12) 2. The method of claim 1, wherein the set of information related to the data transmission failure is included in an Inactivity Data Transmission Failure (IDTF) report sent to the network node in an IDTF report response message. (Item 13) 13. The method according to any of items 1 and 12, further comprising transmitting, by the terminal, an IDTF report available indication to the network node, the IDTF report available indication being included in any of an RRCResumeComplete message, an RRCReestablishmentComplete message, an RRCReconfigurationComplete message, or an RRCSetupComplete message. (Item 14) receiving, by the terminal, an IDTF report request from the network node in response to transmitting the IDTF report available indication, the IDTF report request being included in a UE Information Request message; In response to receiving the IDTF report request, transmitting an IDTF report response by the terminal to the network node, the IDTF report response being included in a UE Information Response message. 14. The method of any one of items 1, 12, and 13, further comprising: (Item 15) 2. The method of claim 1, further comprising: deriving, by the terminal, first statistics related to the data transmission, the statistics including any of an uplink data throughput for the terminal, a downlink data throughput for the terminal, an uplink Uu interface delay for the terminal, a downlink Uu interface delay for the terminal, an uplink data throughput for a 5G QoS identifier (5QI), a downlink data throughput for the 5QI, an uplink Uu interface delay for the 5QI, and a downlink Uu interface delay for the 5QI. (Item 16) 16. The method of any of items 1 and 15, wherein the network node is configured to derive second statistics, the second statistics including any of an uplink data throughput for a cell, a downlink data throughput for the cell, an uplink Uu interface delay for the cell, and a downlink Uu interface delay for the cell. (Item 17) 17. The method according to any one of items 1, 15 and 16, wherein the network node is configured to determine, based on the first statistics and / or the second statistics, whether the data transmission in an RRC inactive state is enabled for a data service type or a Quality of Service (QoS) flow, based on the first statistics related to the 5QI, and whether the data transmission in the RRC inactive state is enabled for a cell, based on the second statistics. (Item 18) 2. The method of claim 1, wherein the data transmission to the network node includes using a random access channel (RACH) resource or a configured grant (CG) resource that is first detected by the terminal. (Item 19) 2. The method of claim 1, further comprising starting, by the terminal, a CG response check timer in response to the data transmission to the network node, the CG response check timer being stopped upon receiving feedback from the network node, and the terminal being configured to determine the data transmission to the network node as a failed transmission in response to expiration of the CG response check timer. (Item 20) 2. The method of claim 1, further comprising starting, by the terminal, an out-of-coverage timer when the terminal is in an inactive state and out of coverage of the network node and the terminal should initiate the data transmission, the terminal initiating the data transmission in response to determining that the terminal is in coverage of the network node prior to expiration of the out-of-coverage timer. (Item 21) 2. The method of claim 1, further comprising: in response to determining that the terminal is out of coverage of the network node, the data transmission is ongoing, and the remaining time of the inactive data transmission timer is less than a value of the out-of-coverage timer, resetting, by the terminal, an inactive data transmission timer to a value of an out-of-coverage timer. (Item 22) Item 12. The method of item 11, wherein the updated data transmission configuration from the network node includes any of the following: a threshold on buffered data size, a threshold on tolerance time, information related to supported solutions, information of configured radio resources for the data transmission, an indication of whether RLC is allowed to be released when in an inactive state, a configured area range, a duration for which beam information derived based on the last RACH procedure is assumed to be valid, a threshold for deciding to use a CG-based or RACH-based solution, configured Sounding Reference Signal (SRS) resources for dealing with beam change issues during the data transmission in an RRC inactive state, a value of a CG response check timer, an indication of whether the data transmission in the RRC inactive state is allowed, and an indication of whether RACH resources or CG resources are allowed to be used depending on which comes first. (Item 23) 23. An apparatus for wireless communication comprising a processor, the processor being configured to perform the method according to any of items 1-22. (Item 24) 23. A non-transitory computer readable medium storing code that, when executed by a processor, causes the processor to implement a method according to any of items 1-22. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is an illustration of an example 5G network architecture.

[0009] [Diagram 2] FIG. 2 illustrates a signaling process of an exemplary inactive data transmission failure information reporting process.

[0010] [Diagram 3] FIG. 3 is a signaling process of an exemplary IDTF reporting process.

[0011] [Figure 4]FIG. 4 is signaling for handling an exemplary statistics reporting process.

[0012] [Diagram 5] FIG. 5 is a signaling process of an exemplary process for reporting nID.

[0013] [Figure 6] FIG. 6 illustrates a block diagram of an exemplary method for data transmission in an inactive state.

[0014] [Figure 7] FIG. 7 illustrates an example of a wireless communication system in which techniques according to one or more embodiments of the present technology may be applied.

[0015] [Figure 8] FIG. 8 is a block diagram representation of a portion of the hardware platform. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] The development of a new generation of wireless communication, namely 5G New Radio (NR) communication, is part of the continuous mobile broadband evolution process to meet the requirements of increasing network demand. NR will provide greater throughput to allow more users to be connected simultaneously. Other aspects such as energy consumption, device cost, spectrum efficiency, and latency are also important to meet the needs of various communication scenarios.

[0017] The present embodiment may relate to optimizing data transmission in an inactive state. The method for optimizing data transmission in an inactive state may be, for example, to avoid unnecessary signaling overhead and power consumption when implementing data transmission in an inactive state.

[0018] FIG. 1 is an illustration of an exemplary 5G network architecture 100. As shown in FIG. 1, the fifth generation (5G) network architecture may include a 5G core network (5GC) and a next-generation radio access network (NG-RAN). The 5GC may include any of an access mobility function (AMF), a session management function (SMF), and a user plane function (UPF). The NG-RAN may include base stations with different radio access technologies (RATs), such as an evolved 4G base station (ng-eNB), a 5G base station (gNB), etc. The NG-RAN base station may be connected to the 5GC through an NG interface, and multiple NG-RAN base stations may be connected through an Xn interface.

[0019] The RRC_INACTIVE state is introduced to provide an efficient state in which a UE can provide lower power consumption than the RRC_CONNECTED state and transition to the RRC_CONNECTED state with less control plane latency than the RRC_IDLE state.

[0020] However, for a UE in RRC_INACTIVE state, data transmission without state transition may not be supported in the current standard, so every time the UE has data to transmit, the UE may need to enter the RRC_CONNECTED state first and then start data transmission. This may be a problem if the data packets are small and infrequent, and the UE may not be in the RRC_CONNECTED state because the data packets are not very frequent, but the UE may need to be restored to the RRC_CONNECTED state regardless of the size of the data and then released to the inactive state for data transmission. This may result in unnecessary signaling overhead and power consumption, and may be serious, especially if the data frequency is not insignificant but not frequent enough to consider transitioning to the RRC_CONNECTED state.

[0021] Success factors for small data transmission in the inactive state in NR may include random access channel (RACH)-based and configured grant type-1 (CG)-based methods. (System Overview)

[0022] This embodiment relates to optimizing data transmission in an inactive state. When a failure is detected by the UE at the start of or during an inactive data transmission, various information types can be stored by the UE and reported to a network node after the UE transitions to a connected state. The inactive state can be, for example, an RRC_INACTIVE state described with respect to the 5G example herein.

[0023] The information may include failure causes for inactive data transmission including at least one of the following: rlc-MaxNumRetx (maximum number of RLC retransmissions), t310-Expiry, beamFailureRecoveryFailure, randomAccessProblem with raPurpose of inactive data transmission, CG based transmission failure, failure due to OOC (out of coverage), expiry of T319 timer, expiry of inactive data transmission timer (starts when initiating inactive data transmission and stops when a release message is received from the network or when it expires), expiry of CG response check timer (starts when initiating CG based inactive data transmission and stops when feedback for UL data, DL data or DL ​​signaling is received from the network or when it expires).

[0024] The information may also include an indication to indicate which entity (UE or network) triggered the inactive data transmission.

[0025] The information may also include a threshold value for buffered data size (inactive data transmission is allowed when the buffered data size is < or ≦ the threshold value), and the threshold value may be per UE, per DRB, per logical channel, or per logical channel group.

[0026] The information may also include a threshold value for the tolerant time (inactive data transmission is allowed when the tolerant time of the ongoing data service type is > or >= the threshold value).

[0027] The information may also include a current buffered data size, which may be per UE, per DRB, per logical channel, or per logical channel group.

[0028] The information may also include information of supported solutions (e.g., whether inactive data transmission is supported, whether a CG-based solution is supported, whether a CFRA (contention-free random access)-based solution is supported, whether a RACH-based solution is supported, whether an RRC-involved solution is supported, whether an RRC-involved solution is supported), and the information of supported solutions may be per UE, per DRB, per logical channel, per logical channel group, per QoS flow, or per PDU session.

[0029] The information may also include information of a selected solution (e.g., a CG based solution is selected, a CFRA based solution is selected, a RACH based solution is selected, a solution involving RRC is selected, a solution not involving RRC is selected).

[0030] The information may also include the status of radio resources (e.g., whether CG resources are valid, whether CFRA resources are valid, whether RACH resources with larger TB (Transport Block) size are valid, whether TA (Timing Advance) is valid).

[0031] The information may also include information of configured radio resources (i.e., valid radio resources) for inactive data transmission: for a RACH-based solution, a configured separate PRACH (Physical Random Access Channel) resource pool, a separate MsgA PUSCH (Physical Uplink Shared Channel) resource pool, a separate CORESET (Control Resource Set) / search space for Msg2 / MsgB reception; for a configured CFRA resource CG-based solution, the configured PUSCH CG resources, a configuration for DL ​​transmission, a configuration for beam management, configured resources for PUCCH (Physical Uplink Control Channel) / SRS (Sounding Reference Signal), a configured TA validity check timer, multiple sets of configured CG configurations.

[0032] The information may also include information of selected radio resources for inactive data transmission: a selected set of CG configurations.

[0033] The information may also include ongoing data service type information (eg, 5QI, DRB ID, logical channel ID, logical channel group ID, QoS flow ID, PDU session ID).

[0034] The information may include the status of the RLC, ie, whether the RLC is released or not (when in an inactive state, the RLC may be suspended or released).

[0035] The information may include a configured area range within which inactive data transmission is enabled, and the area range may be for all UEs or for a particular UE.

[0036] The information may also include an indication to indicate that the UE has buffered data when the UE receives a release message from the NW (Network).

[0037] The information may also include an indication to indicate whether information (e.g., a BSR or an inactive data transmission request indication) has been sent to the NW.

[0038] The information may also include an indication to indicate whether data is included within Msg3 / MsgA when the UE is not the trigger for the initial transmission type selection (i.e., the NW is the trigger) (e.g., to initiate an inactive data transmission or to restore to a connected state, the type of inactive data transmission to be performed, i.e., CG-based or RACH-based, whether RRC is involved).

[0039] The information may also include fallback action information (e.g., fallback from CG-based to RACH-based, from CFRA-based to CBRA-based, from RRC-involved to RRC-involved, fallback to normal recovery, i.e., recovery to connected state).

[0040] The information may also include information on configured fallback triggers: for example, N of N failures (fallback is triggered when N failures are reached).

[0041] The information may also include information on beam management: for RACH-based inactive data transmission, duration (with which the beam information derived based on the last RACH procedure is assumed to be valid), beam information of the last RACH procedure, beam information of the selected beam for inactive data transmission (duration can be per cell or per UE); for CG-based inactive data transmission, a pre-configured threshold (if any beam involves CG resources above which the UE may start CG-based, otherwise the UE starts RACH-based), information on maintained SRS resources (to address the issue of beam changes during inactive data transmission).

[0042] The information may also include an indication to indicate whether it is allowed to use the RACH resources or the CG resources, depending on which comes first.

[0043] The information may also include the configured value of the CG response check timer.

[0044] The above inactive data transmission failure information can be stored in an existing CEF (Connection Establishment Failure) report, RLF (Radio Link Failure) report, RA (Random Access) report or other defined report, or a new defined report (e.g., an inactive data transmission failure report, IDTF report).

[0045] When IDTF reporting is employed, an IDTF report available indication may be included in an RRCResumeComplete message, an RRCReestablishmentComplete message, an RRCReconfigurationComplete message, or an RRCSetupComplete message to indicate to the NW that the UE has a stored IDTF report.

[0046] After receiving the IDTF report available indication from the UE, the NW may send an IDTF report request to the UE, and after receiving the IDTF report request from the NW, the UE sends an IDTF report response carrying the IDTF report to the NW. The IDTF report request may be included in a UE Information Request message, and the IDTF report response may be included in a UE Information rmation Response message.

[0047] During inactive data transmission, the UE may derive statistics. The statistics may include at least one of the following: UL data throughput per UE, DL data throughput per UE, UL Uu interface delay per UE, DL Uu interface delay per UE, UL data throughput per 5QI, DL data throughput per 5QI, UL Uu interface delay per 5QI, DL Uu interface delay per 5QI. The statistical results may be reported to a network node (or NW).

[0048] During inactive data transmission, the NW may derive statistics including at least one of the following: UL data throughput per cell, DL data throughput per cell, UL Uu interface delay per cell, DL Uu interface delay per cell.

[0049] The NW may configure the UE whether inactive data transmission is enabled for the UE according to the per-UE statistical result.

[0050] The NW may configure the UE whether inactive data transmission is enabled for a data service type or QoS flow according to the statistical results for every 5QI.

[0051] The NW may configure the UE whether inactive data transmission is enabled in a cell according to the per-cell statistical results.

[0052] In some embodiments, when the UE initiates an inactive data transmission, the UE uses the RACH resource or the CG resource according to which comes first, i.e., if the RACH resource comes first, it initiates a RACH-based inactive data transmission, and if the CG resource comes first, it initiates a CG-based inactive data transmission.

[0053] In some embodiments, when the UE initiates a CG-based inactive data transmission, the UE initiates a CG response check timer. If the UE does not receive any feedback for UL data, DL data, or DL ​​signaling from the network before the CG response check timer expires, the UE may consider the CG-based inactive data transmission to have failed. The CG response check timer is started when initiating a CG-based inactive data transmission, and may be stopped or expired upon receiving feedback for UL data, DL data, or DL ​​signaling from the network.

[0054] In some embodiments, if the UE is in RRC_INACTIVE state and OOC, the UE may not start inactive data transmission when the UE has UL data for transmission, the UE may remain in RRC_INACTIVE state and start timer O, and the UE may wait until timer O expires or when it returns to normal coverage. If the UE returns to normal coverage before timer O expires, the UE may start inactive data transmission. If the UE is still in OOC when timer O expires, the UE may do at least one of the following: transition to RRC_IDLE state, inform higher layers that data transmission failed due to the UE being in OOC.

[0055] If an inactive data transmission is ongoing (e.g., the inactive data transmission timer is running) and the UE encounters OOC, the UE may reset the inactive data transmission timer to the value of timer O when the remaining time on the inactive data transmission timer is less than the value of timer O.

[0056] The value of timer O can be configured per cell, per data service type (e.g., per 5G Quality of Service Indicator (5QI)), per UE, per PDU session, per QoS flow, per DRB, per logical channel, or per logical channel group.

[0057] The value of timer O may be configured in the UE by the network, by system information or by dedicated signaling.

[0058] In some embodiments, MsgA PUSCH information used to define PUSCH allocation for MsgA in the 2-step RACH procedure is exchanged between RAN nodes or transmitted from DU to CU. When exchanged between RAN nodes, MsgA PUSCH information can be carried in XN Configuration Request, NG-RAN Node Configuration Update, XN Configuration Response, or NG-RAN Node Configuration Update Acknowledgement message or in a new message. When transmitted from DU to CU, MsgA PUSCH information can be carried in GNB-DU Configuration Update, or F1 Configuration Request message or in a new message. (Example embodiment 1)

[0059] 2 illustrates an example inactive data transmission failure information reporting process signaling process 200. At step 206, the UE 202 may store inactive data transmission failure information in response to detecting a data transmission failure.

[0060] The inactive data transmission failure information may include failure causes for inactive data transmission including at least one of the following: rlc-MaxNumRetx (maximum number of RLC retransmissions), t310-Expiry, beamFailureRecoveryFailure, randomAccessProblem with raPurpose of inactive data transmission, CG based transmission failure, failure due to OOC (out of coverage), expiry of T319 timer, expiry of inactive data transmission timer (starts when initiating inactive data transmission and stops upon receipt or expiration of a release message from the network), expiry of CG response check timer (starts when initiating CG based inactive data transmission and stops upon receipt or expiration of feedback for UL data, DL data, or DL ​​signaling from the network).

[0061] The inactive data transmission failure information may include an indication to indicate which entity (UE or network) to trigger the inactive data transmission.

[0062] The inactive data transmission failure information may include a threshold value for buffered data size (inactive data transmission is allowed when the buffered data size is < or ≦ the threshold value), and the threshold value may be per UE, per DRB, per logical channel, or per logical channel group.

[0063] The inactivity data transmission failure information may include a threshold value for the tolerant time (inactivity data transmission is allowed when the tolerant time of the ongoing data service type is > or >= the threshold value).

[0064] The inactive data transmission failure information may include a current buffered data size, where the current buffered data size may be per UE, per DRB, per logical channel, or per logical channel group.

[0065] The inactive data transmission failure information may include information of supported solutions (e.g., whether inactive data transmission is supported, whether a CG-based solution is supported, whether a CFRA (contention-free random access)-based solution is supported, whether a RACH-based solution is supported, whether an RRC-involved solution is supported, whether an RRC-involved solution is supported, whether an RRC-involved solution is supported), and the information of supported solutions may be per UE, per DRB, per logical channel, per logical channel group, per QoS flow, or per PDU session.

[0066] The inactive data transmission failure information may include information of a selected solution (e.g., a CG-based solution is selected, a CFRA-based solution is selected, a RACH-based solution is selected, a solution involving RRC is selected, or a solution not involving RRC is selected).

[0067] The inactive data transmission failure information may include the status of radio resources (e.g., whether a CG resource is valid, whether a CFRA resource is valid, whether a RACH resource with a larger TB (Transport Block) size is valid, whether a TA (Timing Advance) is valid).

[0068] The inactive data transmission failure information may include information of configured radio resources (i.e., valid radio resources) for inactive data transmission: for a RACH-based solution, a configured separate PRACH (Physical Random Access Channel) resource pool, a separate MsgA PUSCH (Physical Uplink Shared Channel) resource pool, a separate CORESET (Control Resource Set) / search space for Msg2 / MsgB reception, configured CFRA resources; for a CG-based solution, configured PUSCH CG resources, a configuration for DL ​​transmission, a configuration for beam management, configured resources for PUCCH (Physical Uplink Control Channel) / SRS (Sounding Reference Signal), a configured TA validity check timer, multiple sets of configured CG configurations.

[0069] The inactive data transmission failure information may include information of selected radio resources for inactive data transmission: a selected set of CG configurations.

[0070] The inactive data transmission failure information may include information of the ongoing data service type (eg, 5QI, DRB ID, logical channel ID, logical channel group ID, QoS flow ID, PDU session ID).

[0071] The inactivity data transmission failure information may include the status of the RLC, ie, whether the RLC is released (when in the inactive state, the RLC may be suspended or released).

[0072] The inactive data transmission failure information may include a configured area range within which the inactive data transmission is enabled, and the area range may be for all UEs or a specific UE.

[0073] The inactive data transmission failure information may include an indication to indicate that the UE has buffered data when the UE receives a release message from the NW (network).

[0074] The inactive data transmission failure information may include an indication to indicate whether information (e.g., a BSR or an inactive data transmission request indication) was sent to the NW.

[0075] The inactive data transmission failure information may include an indication to indicate whether data is included within Msg3 / MsgA when the UE is not the trigger for the initial transmission type selection (i.e., the NW is the trigger) (e.g., to initiate inactive data transmission or to recover to CONNECTED state, type of inactive data transmission to be performed: CG-based or RACH-based, whether RRC is involved).

[0076] The inactive data transmission failure information may include information on fallback actions (e.g., fallback from CG-based to RACH-based, CFRA-based to CBRA-based, fallback from RRC-involved to RRC-involved, fallback to normal recovery: recovery to CONNECTED state).

[0077] The inactive data transmission failure information may include information of a configured fallback trigger, for example, N of N failures (fallback is triggered when N failures are reached).

[0078] The inactive data transmission failure information may include beam management information: for RACH-based inactive data transmission, duration (with which the beam information derived based on the last RACH procedure is assumed to be valid), beam information of the last RACH procedure, beam information of the selected beam for inactive data transmission (duration can be per cell or per UE); for CG-based inactive data transmission, a pre-configured threshold (if any beam involves CG resources above it, the UE can start CG-based, otherwise the UE starts RACH-based), information of maintained SRS resources (to address the issue of beam change during inactive data transmission).

[0079] The inactive data transmission failure information may include an indication to indicate whether it is allowed to use the RACH resources or the CG resources depending on which comes first.

[0080] The inactive data transmission failure information may include a configured value of the CG response check timer.

[0081] The above inactive data transmission failure information can be stored in an existing CEF (Connection Establishment Failure) report, RLF (Radio Link Failure) report, RA (Random Access) report or other defined report, or a new defined report (e.g., an inactive data transmission failure report, IDTF report).

[0082] In step 208, the UE 202 may transmit inactive data transmission failure information to the network node 204 after the UE transitions to a CONNECTED state.

[0083] In step 210, the NW 204 may send an updated configuration to the UE 202 according to the received inactive data transmission failure information. The updated configuration may include, for example, a threshold for buffered data size (inactive data transmission is enabled when the buffered data size is < or ≦ threshold), a threshold for tolerance time (inactive data transmission is enabled when the tolerance time of the ongoing data service type is > or ≧ threshold), a supported solution (e.g., whether inactive data transmission is supported, whether a CG-based solution is supported, whether a CFRA-based solution is supported, whether a RACH-based solution is supported, whether an RRC-involved solution is supported, whether an RRC-involved solution is supported), configured radio resources for inactive data transmission (a configured separate PRACH resource pool, a separate MsgA PUSCH resource pool, a separate CORESET / search space for Msg2 / MsgB reception, configured CFRA resources, configured PUSCH resources ... may include CG resources, configuration for DL ​​transmission, configuration for beam management, configured resources for PUCCH / SRS, configured TA validity check timer, multiple sets of configured CG configurations, whether RLC is allowed to be released when in an inactive state, configured area range (within which inactive data transmission is allowed), duration (within which beam information derived based on the last RACH procedure is assumed to be valid), pre-configured threshold (if any beam involves CG resources above which the UE may start CG based, otherwise the UE starts RACH based), maintained SRS resources (to address issues of beam change during inactive data transmission), value of CG response check timer, whether inactive data transmission is allowed, whether to use RACH resources or CG resources depending on which comes first. (Example embodiment 2)

[0084] 3 is a signaling process 300 of an example IDTF reporting process. In step 306, if an IDTF report is adopted, the UE 302 can send an IDTF report available indication to the NW 304. This can be included in an RRC Resume Complete message, an RRC Reestablishment Complete message, an RRC Reconfiguration Complete message, or an RRC Setup Complete message, and the UE can indicate to the NW that it has a stored IDTF report.

[0085] In step 308, the NW 304 may send an IDTF report request to the UE after receiving the IDTF report available indication from the UE.

[0086] In step 310, after the UE 302 receives the IDTF report request from the NW, the UE 302 may send an IDTF report response carrying the IDTF report to the NW.

[0087] The IDTF reporting request may be included in a UE Information Request message, and the IDTF reporting response may be included in a UE Information Response message. Illustrative embodiment 3

[0088] 4 is a signaling process 400 for an example statistics reporting process. In step 406, during inactive data transmission, the UE 402 may derive at least one of the following statistics: UL data throughput per UE, DL data throughput per UE, UL Uu interface delay per UE, DL Uu interface delay per UE, UL data throughput per 5QI, DL data throughput per 5QI, UL Uu interface delay per 5QI, DL Uu interface delay per 5QI.

[0089] In step 408, the UE 402 may transmit the statistical results to the NW 404.

[0090] In step 410, the NW 404 may configure the UE according to the per-UE statistical result whether inactive data transmission is enabled for the UE, for example, if the per-UE UL data throughput is > or > threshold, or if the per-UE UL Uu interface delay is > or > threshold, data transmission is not enabled for the UE, or the NW may configure the UE according to the per-5QI statistical result whether inactive data transmission is enabled for a data service type or QoS flow. Illustrative embodiment 4

[0091] In some embodiments, the NW node may derive statistics. During inactive data transmission, the NW may derive at least one of the following statistics: UL data throughput per cell, DL data throughput per cell, UL Uu interface delay per cell, DL Uu interface delay per cell.

[0092] The NW may configure the UE whether inactive data transmission is enabled in a cell according to the per-cell statistical results. Illustrative Embodiment 5

[0093] In some embodiments, the NW may configure the UE to allow the UE to use RACH resources or CG resources depending on which comes first.

[0094] When the UE starts an inactive data transmission, the UE may be allowed to use the RACH resource or the CG resource according to which comes first, i.e., if the RACH resource comes first, it starts the RACH-based inactive data transmission, and if the CG resource comes first, it starts the CG-based inactive data transmission. Illustrative Embodiment 6

[0095] In some instances, when the UE initiates a CG-based inactive data transmission, the UE starts a CG response check timer.

[0096] If the UE does not receive any feedback for UL data, DL data, or DL ​​signaling from the network before the CG response check timer expires, the UE may consider the CG-based inactive data transmission to have failed. The CG response check timer is started when starting the CG-based inactive data transmission, and may be stopped or expire when feedback for UL data, DL data, or DL ​​signaling is received from the network. Illustrative Embodiment 7

[0097] In some embodiments, when the UE is in RRC_INACTIVE state and out of coverage (OOC), the UE may not initiate inactive data transmission when the UE has UL data for transmission; the UE remains in RRC_INACTIVE state and starts timer O, and the UE waits until timer O expires or when it returns to normal coverage.

[0098] If the UE returns to normal coverage before timer O expires, the UE may start inactive data transmission. If the UE is still in OOC when timer O expires, the UE may do at least one of the following: transition to RRC_IDLE state, inform higher layers that data transmission failed due to the UE being in OOC.

[0099] The value of Timer O can be configured per cell, per data service type (e.g., per 5QI), per UE, per PDU session, per QoS flow, per DRB, per logical channel, or per logical channel group. The value of Timer O can be configured in the UE by the network, by UE system information, or by dedicated signaling. Illustrative Embodiment 8

[0100] If an inactive data transmission is ongoing (e.g., the inactive data transmission timer is running) and the UE encounters OOC, the UE may reset the inactive data transmission timer to the value of timer O when the remaining time on the inactive data transmission timer is less than the value of timer O.

[0101] If the UE returns to normal coverage before timer O expires, the UE may start inactive data transmission. If the UE is still in OOC when timer O expires, the UE may do at least one of the following: transition to RRC_IDLE state, inform higher layers that data transmission failed due to the UE being in OOC. Illustrative Embodiment 9

[0102] 5 is a signaling process 500 of an example process for reporting nID. In step 508, RAN node 1 504 can send MsgA PUSCH information to RAN node 2 506. The MsgA PUSCH information can be carried in an XN configuration request, an NG-RAN node configuration update message, or a new message.

[0103] In step 510, RAN node 2 506 may send MsgA PUSCH information to RAN node 1 504. The MsgA PUSCH information may be carried in the XN configuration response, the NG-RAN node configuration update acknowledgement message, or a new message.

[0104] In step 512 and / or step 514, RAN node 1 504 and / or RAN node 2 506 may send updated MsgA PUSCH information to the UE for collision avoidance when the UE performs 2-step RACH.

[0105] The MsgA PUSCH information may be used to specify a PUSCH allocation for MsgA in the two-step RACH procedure and includes at least one of the following: nID, frequencyStartMsgA-PUSCH (offset of the lowest PUSCH opportunity in the frequency domain relative to PRB 0), msgA-HoppingBits (value of the hopping bits to indicate the frequency offset to be used for the second hop), msgA-IntraSlotFrequencyHopping (intra-slot frequency hopping per PUSCH opportunity), msgA-PUSCH-TimeDomainAllocation (indicates a combination of starting symbol, length, and PUSCH mapping type from the TDRA table), msgA-PUSCH-TimeDomainOffset (a single time offset for the start of each PRACH slot, counted as a number of slots), nrofMsgA-PO-FDM (number of MsgA PUSCH opportunities in one time instance), ...rofMsgA-PO-FDM (number of MsgA PUSCH opportunities in one time instance), nrofMsgA-PO-FDM (number of MsgA PUSCH opportunities in one time instance), nrofMs nrofPUSCH opportunities FDMed), nrofMsgA-PO-PerSlot (the number of time domain PUSCH opportunities in each slot), nrofPRBs-PerMsgA-PO (the number of PRBs per PUSCH opportunity), nrofSlotsMsgA-PUSCH (the number of slots containing one or more PUSCH opportunities), startSymbolAndLengthMsgA-PO (an index giving a valid combination of start symbol, length, and mapping type as the start and length indicator for the first MsgA PUSCH opportunity).

[0106] nID may include an identifier (i.e., C_init) used to initiate data scrambling for MsgA on the PUSCH. nID may include a cell-specific parameter (i.e., msgA-dataScramblingIndex) if configured, otherwise the PCI (physical cell ID) of the cell. When the nIDs of two neighboring cells (e.g., one belonging to RAN node 1 and another one belonging to RAN node 2) are different, relative collisions of 2-step RACH are avoided even when other resource configurations for 2-step RACH are the same, and thus flexibility can be improved. Illustrative Embodiment 10

[0107] In some embodiments, the DU may transmit MsgA PUSCH information to the CU. The MsgA PUSCH information may be carried in a GNB-DU Configuration Update or F1 Configuration Request message.

[0108] The CU can transmit the MsgA PUSCH information to other RAN nodes (e.g., gNB, gNB-CU). The MsgA PUSCH information can be carried in an XN Configuration Request, an NG-RAN Node Configuration Update, an XN Configuration Response, or an NG-RAN Node Configuration Update Acknowledgement message.

[0109] The MsgA PUSCH information may be used to specify a PUSCH allocation for MsgA in the two-step RACH procedure and includes at least one of the following: nID, frequencyStartMsgA-PUSCH (offset of the lowest PUSCH opportunity in the frequency domain relative to PRB 0), msgA-HoppingBits (value of the hopping bits to indicate the frequency offset to be used for the second hop), msgA-IntraSlotFrequencyHopping (intra-slot frequency hopping per PUSCH opportunity), msgA-PUSCH-TimeDomainAllocation (indicates a combination of starting symbol, length, and PUSCH mapping type from the TDRA table), msgA-PUSCH-TimeDomainOffset (a single time offset for the start of each PRACH slot, counted as a number of slots), nrofMsgA-PO-FDM (number of MsgA PUSCH opportunities in one time instance), ...rofMsgA-PO-FDM (number of MsgA PUSCH opportunities in one time instance), nrofMsgA-PO-FDM (number of MsgA PUSCH opportunities in one time instance), nrofMs nrofPUSCH opportunities FDMed), nrofMsgA-PO-PerSlot (number of time domain PUSCH opportunities in each slot), nrofPRBs-PerMsgA-PO (number of PRBs per PUSCH opportunity), nrofSlotMsgA-PUSCH (number of slots containing one or more PUSCH opportunities), startSymbolAndLengthMsgA-PO (index giving a valid combination of start symbol, length, and mapping type as start and length indicator for the first MsgA PUSCH opportunity).

[0110] nID may be an identifier (i.e., C_init) used to initiate data scrambling for MsgA on the PUSCH. nID is a cell-specific parameter (i.e., msgA-dataScramblingIndex) if configured, otherwise it is the PCI (Physical Cell ID) of the cell.

[0111] FIG. 6 illustrates a block diagram 600 of an example method for data transmission in an inactive state. The method may include identifying that a data transmission with a network node has failed while the terminal is in the inactive state (block 602). The terminal (or UE) may identify specific information related to the inactive data transmission while in the inactive state. The data transmission failure identified by the terminal may occur at the start of the inactive data transmission or during the inactive transmission. The data transmission may include an inactive data transmission as described herein.

[0112] The method may also include transmitting a set of information related to the data transmission failure to the network node in response to the terminal transitioning to a connected state (the terminal is connected to the network node) (block 604). The set of information related to the data transmission failure may include inactive data transmission failure information as described herein (e.g., an inactive data transmission failure information message 208 transmitted from the UE 202 to the NW 204 as described in FIG. 2).

[0113] In some embodiments, the set of information related to a data transmission failure includes a failure cause for the data transmission failure.

[0114] In some embodiments, the failure causes include any of the following: maximum number of radio link control (RLC) retransmissions, expiration of the t310 timer, beam failure recovery failure, random access failure with random access objective of data transmission in radio resource control (RRC) inactive state, configured grant (CG) based failure, out-of-coverage failure, expiration of the t319 timer, expiration of the inactive data transmission timer, and expiration of the CG response check timer.

[0115] In some embodiments, the set of information relating to a data transmission failure includes an indication of whether a terminal or a network node triggered the data transmission.

[0116] In some embodiments, the set of information related to data transmission failures includes any of a threshold for buffered data size and a current buffered data size, where the threshold is per terminal, per data radio bearer (DRB), per logical channel, or per logical channel group, and the buffered data size is per terminal, per DRB, per logical channel, or per logical channel group.

[0117] In some embodiments, the set of information related to data transmission failures includes any of a threshold value related to a tolerant time, information related to supported solutions, and information related to a selected solution.

[0118] In some embodiments, the set of information related to the data transmission failure includes any of the following: radio resource status, configured radio resource information for data transmission, selected radio resource information for data transmission, ongoing data service type information, and RLC status.

[0119] In some embodiments, the set of information related to the data transmission failure includes any of a configured area range, an indication that the terminal has buffered data in response to the terminal receiving a release message from the network node, an indication of whether a Buffer Status Report (BSR) or a data transmission request in an inactive state has been sent to the network node, an indication of whether data has been sent to the network node in Msg3 or MsgA, information on a fallback action, information on a configured fallback trigger condition, and information on beam management.

[0120] In some embodiments, the set of information related to the data transmission failure includes an indication of whether it is allowed to use random access channel resources or CG resources, depending on which comes first, and a configured value for the CG response check timer.

[0121] In some embodiments, the set of information related to the data transmission failure is stored by the terminal in any of a connection establishment failure (CEF) report, a radio link failure (RLF) report, and a random access report.

[0122] In some embodiments, the method includes receiving, by the terminal, an updated data transmission configuration from the network node in response to transmitting to the network node a set of information related to the data transmission failure.

[0123] In some embodiments, the set of information related to the data transmission failure is included in an Inactive Data Transmission Failure (IDTF) report sent to the network node in an IDTF Report Response message.

[0124] In some embodiments, the method includes transmitting, by the terminal, an IDTF report available indication to the network node, the IDTF report available indication being included in any of an RRCResumeComplete message, an RRCReestablishmentComplete message, an RRCReconfigurationComplete message, or an RRCSetupComplete message.

[0125] In some embodiments, the method includes receiving, by the terminal, an IDTF report request from the network node in response to transmitting the IDTF report available indication, the IDTF report request being included in a UE Information Request message, and transmitting, by the terminal, in response to receiving the IDTF report request, an IDTF report response to the network node, the IDTF report response being included in a UE Information Response message.

[0126] In some embodiments, the method includes deriving, by the terminal, first statistics related to the data transmission, the statistics including any of an uplink data throughput for the terminal, a downlink data throughput for the terminal, an uplink Uu interface delay for the terminal, a downlink Uu interface delay for the terminal, an uplink data throughput for a 5G QoS identifier (5QI), a downlink data throughput for the 5QI, an uplink Uu interface delay for the 5QI, and a downlink Uu interface delay for the 5QI.

[0127] In some embodiments, the network node is configured to derive a second statistic including any of an uplink data throughput for the cell, a downlink data throughput for the cell, an uplink Uu interface delay for the cell, and a downlink Uu interface delay for the cell.

[0128] In some embodiments, the network node is configured to determine any of the following: whether data transmission is enabled for the terminal based on the first statistics and / or the second statistics, whether data transmission in an RRC inactive state is enabled for a data service type or a Quality of Service (QoS) flow based on the first statistics related to the 5QI, and whether data transmission in an RRC inactive state is enabled for the cell based on the second statistics.

[0129] In some embodiments, the data transmission to the network node includes using a random access channel (RACH) resource or a configured grant (CG) resource that is first detected by the terminal.

[0130] In some embodiments, the method includes starting, by the terminal, a CG response check timer in response to a data transmission to the network node, the CG response check timer being stopped upon receiving feedback from the network node, and the terminal being configured to determine the data transmission to the network node as a failed transmission in response to expiration of the CG response check timer.

[0131] In some embodiments, the method includes starting, by the terminal, an out-of-coverage timer when the terminal is in an inactive state and out of coverage of the network node, and the terminal initiating data transmission in response to determining that the terminal is in coverage of the network node prior to expiration of the out-of-coverage timer.

[0132] In some embodiments, the method includes resetting, by the terminal, an inactive data transmission timer to an out-of-coverage timer value in response to determining that the terminal is out of coverage of the network node, data transmission is ongoing, and a remaining time on the inactive data transmission timer is less than a value of the out-of-coverage timer.

[0133] In some embodiments, the updated data transmission configuration from the network node includes any of the following: a threshold on buffered data size, a threshold on tolerance time, information related to supported solutions, information on configured radio resources for data transmission, an indication of whether RLC is allowed to be released when in an inactive state, a configured area range, a duration for which beam information derived based on the last RACH procedure is assumed to be valid, a threshold for deciding to use a CG-based or RACH-based solution, configured Sounding Reference Signal (SRS) resources to address beam change issues during data transmission in an RRC inactive state, a value for a CG response check timer, an indication of whether data transmission is allowed in an RRC inactive state, and an indication of whether RACH resources or CG resources are allowed to be used depending on which comes first. (Example Wireless System)

[0134] FIG. 11 illustrates an example of a wireless communication system to which techniques according to one or more embodiments of the present technology may be applied. The wireless communication system 1100 may include one or more base stations (BSs) 1105a, 1105b, one or more wireless devices or terminals 1110a, 1110b, 1110c, 1110d, and a core network 1125. The base stations 1105a, 1105b may provide wireless services to the wireless devices 1110a, 1110b, 1110c, and 1110d in one or more wireless sectors. In some implementations, the base stations 1105a, 1105b include directional antennas for generating two or more directional beams to provide wireless coverage in different sectors. The base stations may implement the functionality of a scheduling cell or a candidate cell as described herein.

[0135] The core network 1125 can communicate with one or more base stations 1105a, 1105b. The core network 1125 provides connectivity with other wireless communication systems and wired communication systems. The core network can include one or more service subscription databases to store information related to the subscribed wireless devices 1110a, 1110b, 1110c, and 1110d. The first base station 1105a can provide wireless services based on a first wireless access technology, while the second base station 1105b can provide wireless services based on a second wireless access technology. The base stations 1105a and 1105b can be co-located or installed separately at the site depending on the deployment scenario. The wireless devices 1110a, 1110b, 1110c, and 1110d can support multiple different wireless access technologies.

[0136] In some implementations, a wireless communication system may include multiple networks that use different wireless technologies. A dual-mode or multi-mode wireless device includes two or more wireless technologies that may be used to connect to different wireless networks.

[0137] FIG. 12 is a block diagram representation of a portion of a hardware platform. A hardware platform 1205, such as a network node or base station or terminal or wireless device (or UE), can include processor electronics 1210, such as a microprocessor, that implements one or more of the techniques presented herein. The hardware platform 1205 can include transceiver electronics 1215 for transmitting and / or receiving wired or wireless signals by one or more communication interfaces, such as an antenna 1220 or a wired interface. The hardware platform 1205 can implement other communication interfaces with defined protocols for transmitting and receiving data. The hardware platform 1205 can include one or more memories (not explicitly shown) configured to store information, such as data and / or instructions. In some implementations, the processor electronics 1210 can include at least a portion of the transceiver electronics 1215. In some embodiments, at least some of the techniques, modules, or functions disclosed are implemented using the hardware platform 1205. (Conclusion)

[0138] The disclosed and other embodiments, modules, and functional operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their structural equivalents, or in a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by or to control the operation of a data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition that produces a machine-readable propagated signal, or one or more combinations thereof. The term "data processing device" encompasses all apparatus, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. An apparatus can include, in addition to hardware, code that creates an execution environment for the computer program, such as code that constitutes a processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, such as a machine-generated electrical, optical, or electromagnetic signal, that encodes information for transmission to a suitable receiver device.

[0139] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple associated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer, or on multiple computers, located at one site, or distributed across multiple sites and interconnected by a communication network.

[0140] The processes and logic flows described herein may be implemented by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be implemented by, and an apparatus may also be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0141] Processors suitable for executing computer programs include, by way of example, both general purpose and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for carrying out instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices, such as magnetic disks, magneto-optical disks, or optical disks, for storing data, or be operatively coupled to receive data from or transfer data to, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include, by way of example, all forms of non-volatile memory, media, and memory devices, including semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices, magnetic disks, such as internal hard disks or removable disks, magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0142] Although this patent document contains many details, these should not be construed as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features that may be specific to certain embodiments of a particular invention. Certain features described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Also, although features may be described above as acting in a combination and even initially claimed as such, one or more features from a claimed combination can, in some cases, be deleted from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0143] Similarly, although operations are depicted in the figures in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown, or in a sequential order, or that all of the illustrated operations be performed, to achieve desirable results, nor should the separation of various system components in the embodiments described in this patent document be understood as requiring such separation in all embodiments.

[0144] Only some implementations and examples have been described; other implementations, improvements, and modifications can be made based on what is described and illustrated in this patent document.

Claims

1. 1. A method for wireless communication, the method comprising: a terminal performing a data transmission with a network node while the terminal is in an inactive state, the terminal starting an inactive data transmission timer when the data transmission starts in the inactive state; when the inactivity data transmission timer expires, the terminal determines a failure of the data transmission with the network node while the terminal was in the inactive state; The terminal stores a set of information regarding the failure of the data transmission with the network node, the set of information including (1) a failure cause for the failure of the data transmission indicating an expiration of the inactive data transmission timer; and in response to the terminal transitioning to a connected state in which the terminal is connected to the network node, the terminal transmitting the set of information regarding the failure of the data transmission to the network node; A method comprising:

2. The failure cause further includes any of the following: a maximum number of radio link control (RLC) retransmissions, expiration of a t310 timer, a beam failure recovery failure, a random access failure with a random access purpose of the data transmission in a radio resource control (RRC) inactive state, a configured grant (CG) based failure, an out-of-coverage failure, expiration of a t319 timer, or expiration of a CG response check timer; The set of information regarding the failure of the data transmission comprises: (2) an indication of whether the terminal or the network node triggered the data transmission; (3) Any of a threshold value for a buffered data size and a current buffered data size, the threshold value being per terminal, per data radio bearer (DRB), per logical channel, or per logical channel group, and the buffered data size being per terminal, per DRB, per logical channel, or per logical channel group; (4) any one of a threshold value for a tolerant time, information related to a supported solution, and information related to a selected solution; (5) any of the following: a status of radio resources, information of configured radio resources for the data transmission, information of selected radio resources for the data transmission, information of an ongoing data service type, and a status of an RLC; (6) Any of a configured area range, an indication that the terminal has buffered data in response to the terminal receiving a release message from the network node, an indication of whether a Buffer Status Report (BSR) or a data transmission request in an inactive state has been sent to the network node, an indication of whether data has been sent to the network node in Msg3 or MsgA, information on a fallback action, information on a configured fallback trigger condition, and information on beam management; or (7) An indication of whether to be enabled to use random access channel resources or CG resources, depending on which comes first, and any of the configured values ​​for the CG response check timer. The method of claim 1 , further comprising at least one of:

3. 3. The method of claim 1 or 2, wherein the set of information regarding the failure of the data transmission is stored by the terminal in one of a Connection Establishment Failure (CEF) report, a Radio Link Failure (RLF) report, or a Random Access report.

4. A method according to any one of claims 1 to 3, wherein the set of information relating to the failure of the data transmission is included in an inactivity data transmission failure report sent to the network node in an inactivity data transmission failure report response message.

5. The method comprises: The terminal transmits an inactivity data transmission failure reporting availability indication to the network node, the inactivity data transmission failure reporting availability indication being included in any of an RRCResumeComplete message, an RRCReestablishmentComplete message, an RRCReconfigurationComplete message, or an RRCSetupComplete message; and receiving, by the terminal, an inactive data transmission failure reporting request from the network node in response to transmitting the inactive data transmission failure reporting availability indication, the inactive data transmission failure reporting request being included in a UE Information Request message; In response to receiving the inactivity data transmission failure report request, the terminal transmits an inactivity data transmission failure report response to the network node, the inactivity data transmission failure report response being included in a UE Information Response message; The method of any one of claims 1 to 4, further comprising:

6. The method further includes the terminal deriving first statistics associated with the data transmission; The method according to any one of claims 1 to 5, wherein the statistics include any of an uplink data throughput for the terminal, a downlink data throughput for the terminal, an uplink Uu interface delay for the terminal, a downlink Uu interface delay for the terminal, an uplink data throughput for a 5G QoS identifier (5QI), a downlink data throughput for the 5QI, an uplink Uu interface delay for the 5QI, and a downlink Uu interface delay for the 5QI.

7. The network node is configured to derive a second statistic; 7. The method of claim 6, wherein the second statistic comprises any of an uplink data throughput for a cell, a downlink data throughput for the cell, an uplink Uu interface delay for the cell, and a downlink Uu interface delay for the cell.

8. 8. The method of claim 7, wherein the network node is configured to determine any of: whether the data transmission is enabled for the terminal based on the first statistics and / or the second statistics; whether the data transmission in an RRC inactive state is enabled for a data service type or a Quality of Service (QoS) flow based on the first statistics related to the 5QI; and whether the data transmission in the RRC inactive state is enabled for a cell based on the second statistics.

9. The method according to any of claims 1 to 8, wherein the data transmission to the network node comprises using a random access channel (RACH) resource or a configured grant (CG) resource first detected by the terminal.

10. The method further includes the terminal starting a CG response check timer in response to the data transmission to the network node; A method according to any one of claims 1 to 9, wherein the CG response check timer is stopped upon receiving feedback from the network node, and the terminal is configured to determine the data transmission to the network node as a failed transmission in response to expiry of the CG response check timer.

11. The method further includes the terminal starting an out-of-coverage timer when the terminal is in an inactive state, the terminal is out of coverage of the network node, and the terminal should start the data transmission; 11. A method according to claim 1, wherein the terminal initiates the data transmission in response to determining that the terminal is in coverage of the network node prior to expiry of the out-of-coverage timer.

12. 12. The method of claim 1, further comprising: in response to determining that the terminal is out of coverage of the network node and the data transmission is ongoing and the remaining time of the inactive data transmission timer is less than a value of an out-of-coverage timer, the terminal resetting an inactive data transmission timer to the value of the out-of-coverage timer.

13. The method further comprises the terminal receiving an updated data transmission configuration from the network node; The updated data transmission configuration from the network node may include a threshold on buffered data size, a threshold on tolerance time, information related to supported solutions, information on configured radio resources for the data transmission, an indication of whether RLC is allowed to be released when in an inactive state, a configured area range, a duration for which beam information derived based on the last RACH procedure is assumed to be valid, a threshold for deciding to use a CG based or RACH based solution, configured Sounding Reference Signal (SRS) resources to address beam change issues during the data transmission in an RRC inactive state, a value for a CG response check timer, an indication of whether the data transmission in the RRC inactive state is allowed to use RACH resources or CG resources depending on which comes first. The method of any of claims 1 to 12, further comprising: an indication of whether

14. An apparatus for wireless communication, said apparatus comprising a processor, said processor being configured to perform the method according to any of claims 1 to 13.

15. A non-transitory computer readable medium having stored thereon code, the code, when executed by a processor, causing the processor to perform a method according to any one of claims 1 to 13.

Images